Branch 4.1 does not boot on BeagleBone Black #68
Comments
|
r47 -> r48: |
|
are you doing anything different in the config? |
|
Hi RobertCNelson, I have not changed the configuration. Basically, I have followed the same procedure I always have to update the kernel (replace zImage, dtb and modules). Actually, just by restoring the r46 zImage the board boots again. I have tried different DTs but I think it is something related to the kernel itself, since kernel r46 with DT from r47 also boots, but kernels r47 and r48 freeze. Image sizes are nearly the same (just a few bytes of difference). It would be helpful if someone else with a BBB could confirm the bug or if it is something I am missing. Thanks. |
|
Could anyone confirm the problem? Has anyone got r48 working on BBB? Thanks. |
|
Sorry unable to confirm the problem: [test-bbb-3: 4.1.17-ti-rt-r48 (up 6 days, 12 hours, 42 minutes)] Regards, |
|
Hi RobertCNelson. I have updated U-Boot to 2016.01, just in case, but still not working. I have tried also booting from uSD instead of the onboard eMMC. Nothing. These are the steps I use to build the kernel: $INSTALL_MOD_PATH points to the root of my NFS exported filesystem. Then I use TFTP to load zImage and am335x-boneblack.dtb (as I always have). I have tried latest tag 4.1.18-ti-rt-r49, but no luck either. Any kernel newer than r46 fails. If your board is working fine, it must be something related to my set up, I just do not know what it may be. Could it be related to the board revision? I have a BBB rev B. Any help will be appreciated. |
|
Same problem here with BBB rev C. |
|
I tried the resultant .config from bb-kernel and 4.1.18-ti-rt-r49 boots fine. It seems the bb.org_defconfig provided in this repo is no longer valid for the BBB. Is this planned or is it a bug? Or was bb.org_defconfig never intended to work on BBB and it has been working until r46 just by chance? |
|
@jcdevel bb.org_defconfig is for the bbb.. btw, do you have earlyprink enabled, i just noticed: RobertCNelson/ti-linux-kernel-dev@7f0a67c ^^^ that was me debugging the x15, that should not be enabled.. if you have earlyprink as part of your bootargs, that might cause something.. REgards, |
|
Hi RobertCNelson. Yes, I had earlyprink enabled. After removing it from bootargs, kernel boots fine. |
|
@jcdevel, if you want the kernel to work with the CONFIG_EARLY_PRINTK you shoud enable CONFIG_DEBUG_AM33XXUART1. |
|
@printesoi it didn't help that i had it enabled for the x15's usart's by default ;) |
commit 213fa10 upstream. Below call chain causes system crash when OMAP device is removed by calling of_platform_depopulate()/device_del(): device_del() - blocking_notifier_call_chain(&dev->bus->p->bus_notifier, BUS_NOTIFY_DEL_DEVICE, dev); - _omap_device_notifier_call() - omap_device_delete() - od->pdev->archdata.od = NULL; kfree(od->hwmods); kfree(od); - bus_remove_device() - device_release_driver() - __device_release_driver() - pm_runtime_get_sync() - _od_runtime_resume() - omap_hwmod_enable() <- OOPS od's delted already Backtrace: Unable to handle kernel NULL pointer dereference at virtual address 0000000d pgd = eb100000 [0000000d] *pgd=ad6e1831, *pte=00000000, *ppte=00000000 Internal error: Oops: 17 [#1] PREEMPT SMP ARM CPU: 1 PID: 1273 Comm: modprobe Not tainted 4.4.15-rt19-00115-ge4d3cd3-dirty #68 Hardware name: Generic DRA74X (Flattened Device Tree) task: eb1ee800 ti: ec962000 task.ti: ec962000 PC is at omap_device_enable+0x10/0x90 LR is at _od_runtime_resume+0x10/0x24 [...] [<c00299dc>] (omap_device_enable) from [<c0029a6c>] (_od_runtime_resume+0x10/0x24) [<c0029a6c>] (_od_runtime_resume) from [<c04ad404>] (__rpm_callback+0x20/0x34) [<c04ad404>] (__rpm_callback) from [<c04ad438>] (rpm_callback+0x20/0x80) [<c04ad438>] (rpm_callback) from [<c04aee28>] (rpm_resume+0x48c/0x964) [<c04aee28>] (rpm_resume) from [<c04af360>] (__pm_runtime_resume+0x60/0x88) [<c04af360>] (__pm_runtime_resume) from [<c04a4974>] (__device_release_driver+0x30/0x100) [<c04a4974>] (__device_release_driver) from [<c04a4a60>] (device_release_driver+0x1c/0x28) [<c04a4a60>] (device_release_driver) from [<c04a38c0>] (bus_remove_device+0xec/0x144) [<c04a38c0>] (bus_remove_device) from [<c04a0764>] (device_del+0x10c/0x210) [<c04a0764>] (device_del) from [<c04a67b0>] (platform_device_del+0x18/0x84) [<c04a67b0>] (platform_device_del) from [<c04a6828>] (platform_device_unregister+0xc/0x20) [<c04a6828>] (platform_device_unregister) from [<c05adcfc>] (of_platform_device_destroy+0x8c/0x90) [<c05adcfc>] (of_platform_device_destroy) from [<c04a02f0>] (device_for_each_child+0x4c/0x78) [<c04a02f0>] (device_for_each_child) from [<c05adc5c>] (of_platform_depopulate+0x30/0x44) [<c05adc5c>] (of_platform_depopulate) from [<bf123920>] (cpsw_remove+0x68/0xf4 [ti_cpsw]) [<bf123920>] (cpsw_remove [ti_cpsw]) from [<c04a68d8>] (platform_drv_remove+0x24/0x3c) [<c04a68d8>] (platform_drv_remove) from [<c04a49c8>] (__device_release_driver+0x84/0x100) [<c04a49c8>] (__device_release_driver) from [<c04a4b20>] (driver_detach+0xac/0xb0) [<c04a4b20>] (driver_detach) from [<c04a3be8>] (bus_remove_driver+0x60/0xd4) [<c04a3be8>] (bus_remove_driver) from [<c00d9870>] (SyS_delete_module+0x184/0x20c) [<c00d9870>] (SyS_delete_module) from [<c0010540>] (ret_fast_syscall+0x0/0x1c) Code: e3500000 e92d4070 1590630c 01a06000 (e5d6300d) Hence, fix it by using BUS_NOTIFY_REMOVED_DEVICE event for OMAP device deletion which is sent when DD has finished processing of device deletion. Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
|
hi I have exactly same issue here. Anyone has any solution for this case? |
|
@nicholas-zww please include more details: git tag Regards, |
|
I used release "linux-4.4.49-ti-rt-r89", and without any change, just use bb.org_defconfig, and make. U-Boot SPL 2014.04-00014-g47880f5 (Apr 22 2014 - 13:23:54) U-Boot 2014.04-00014-g47880f5 (Apr 22 2014 - 13:23:54) I2C: ready Net: not set. Validating first E-fuse MAC Flattened Device Tree blob at 88000000Booting using the fdt blob at 0x88000000 Starting kernel ... |
|
Please re-open if still an issue. |
…tible() commit 9acf636 upstream. Using wait_event_interruptible() to wait for complete transmission, but do not check the result of wait_event_interruptible() which can be interrupted. It will result in TX buffer has multiple accessors and the later process interferes with the previous process. Following is one of the problems reported by syzbot. ============================================================= WARNING: CPU: 0 PID: 0 at net/can/isotp.c:840 isotp_tx_timer_handler+0x2e0/0x4c0 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.13.0-rc7+ #68 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1 04/01/2014 RIP: 0010:isotp_tx_timer_handler+0x2e0/0x4c0 Call Trace: <IRQ> ? isotp_setsockopt+0x390/0x390 __hrtimer_run_queues+0xb8/0x610 hrtimer_run_softirq+0x91/0xd0 ? rcu_read_lock_sched_held+0x4d/0x80 __do_softirq+0xe8/0x553 irq_exit_rcu+0xf8/0x100 sysvec_apic_timer_interrupt+0x9e/0xc0 </IRQ> asm_sysvec_apic_timer_interrupt+0x12/0x20 Add result check for wait_event_interruptible() in isotp_sendmsg() to avoid multiple accessers for tx buffer. Fixes: e057dd3 ("can: add ISO 15765-2:2016 transport protocol") Link: https://lore.kernel.org/all/10ca695732c9dd267c76a3c30f37aefe1ff7e32f.1633764159.git.william.xuanziyang@huawei.com Cc: stable@vger.kernel.org Reported-by: syzbot+78bab6958a614b0c80b9@syzkaller.appspotmail.com Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com> Acked-by: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Last working tag is 4.1.17-ti-rt-r46. Tags 4.1.17-ti-rt-r47 and 4.1.17-ti-rt-r48 do not boot. The boot process freezes right after jumping to Linux, then resets (presumably a watchdog reset). This is the serial output:
Has something changed after r46? I am using TFTP to load the kernel and the DT.
Thanks in advance.
The text was updated successfully, but these errors were encountered: