Tree/branch: poky/1.2_M4 Commit: 4d9f4d6ac25f39fe6d5491d05c7a26195bab648b Image location: http://autobuilder.pokylinux.org/nightly/20120328-1/machines/beagleboard/ u-boot environment setting: ########### setenv bootcmd 'mmc rescan 0; fatload mmc 0:1 0x80300000 uImage; bootm 0x80300000' setenv bootargs ' console=ttyO2,115200n8 console=tty0 root=/dev/mmcblk0p2 rootwait rootfstype=ext3 ro' boot ########### Kernel version is 3.0.23 When I boot up beagleboard, There is no login prompt in minicom so I can not login via serial console. But the system boot success and work good. I can see the GUI in LCD. The keyboard and mouse in target can work. The messages in serial console would show: ########## ...... ...... hub 1-2:1.0: 7 ports detected mmc0: new SD card at address 1234 mmcblk0: mmc0:1234 SA02G 1.83 GiB usb 1-2.2: new low speed USB device number 3 using ehci-omap mmcblk0: p1 p2 EXT3-fs: barriers not enabled EXT3-fs (mmcblk0p2): mounted filesystem with ordered data mode kjournald starting. Commit interval 5 seconds VFS: Mounted root (ext3 filesystem) readonly on device 179:2. input: Logitech USB Optical Mouse as /devices/platform/usbhs-omap.0/ehci-omap.0/usb1/1-2/1-2.2/1-2.2:1.0/input/input0 generic-usb 0003:046D:C05A.0001: input: USB HID v1.11 Mouse [Logitech USB Optical Mouse] on usb-ehci-omap.0-2.2/input0 devtmpfs: mounted Freeing init memory: 320K usb 1-2.3: new low speed USB device number 4 using ehci-omap input: Dell Dell USB Entry Keyboard as /devices/platform/usbhs-omap.0/ehci-omap.0/usb1/1-2/1-2.3/1-2.3:1.0/input/input1 generic-usb 0003:413C:2107.0002: input: USB HID v1.10 Keyboard [Dell Dell USB Entry Keyboard] on usb-ehci-omap.0-2.3/input0 udev[63]: starting version 164 NET: Registered protocol family 10 EXT3-fs (mmcblk0p2): warning: maximal mount count reached, running e2fsck is recommended EXT3-fs (mmcblk0p2): using internal journal ip_tables: (C) 2000-2006 Netfilter Core Team nf_conntrack version 0.5.0 (3714 buckets, 14856 max) ############### I try to use an old kernel with this rootfs. The kernel version is 3.0.18 from 1.2 M3 (gitinfo: 320558f494c618f53e0c773db3ea0109476e8359). It works.
I'm putting Yang's name beside this, since it is likely related to our other beagleboard bugs.
The following commit has changed the irq handling logic, which will lead the serial driver of beagleboard not work fine. It's imported in v3.0.23~14 $ git name-rev b7f0787da3657100fe8fc8b3f0565b0bee341510 b7f0787da3657100fe8fc8b3f0565b0bee341510 tags/v3.0.23~14 $ git log b7f0787da3657100fe8fc8b3f0565b0bee341510 commit b7f0787da3657100fe8fc8b3f0565b0bee341510 Author: Thomas Gleixner <tglx@linutronix.de> Date: Tue Feb 7 17:58:03 2012 +0100 genirq: Unmask oneshot irqs when thread was not woken commit ac5637611150281f398bb7a47e3fcb69a09e7803 upstream. When the primary handler of an interrupt which is marked IRQ_ONESHOT returns IRQ_HANDLED or IRQ_NONE, then the interrupt thread is not woken and the unmask logic of the interrupt line is never invoked. This keeps the interrupt masked forever. This was not noticed as most IRQ_ONESHOT users wake the thread unconditionally (usually because they cannot access the underlying device from hard interrupt context). Though this behaviour was nowhere documented and not necessarily intentional. Some drivers can avoid the thread wakeup in certain cases and run into the situation where the interrupt line s kept masked. Handle it gracefully. Reported-and-tested-by: Lothar Wassmann <lw@karo-electronics.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> But in following commit, this bug has been fixed. It's imported in v3.0.24~49. $ git name-rev c847ac8e8e7447730aef70b94915f1c0880e6578 c847ac8e8e7447730aef70b94915f1c0880e6578 tags/v3.0.24~49 $ git log c847ac8e8e7447730aef70b94915f1c0880e6578 commit c847ac8e8e7447730aef70b94915f1c0880e6578 Author: Thomas Gleixner <tglx@linutronix.de> Date: Tue Mar 6 23:18:54 2012 +0100 genirq: Clear action->thread_mask if IRQ_ONESHOT is not set commit 52abb700e16a9aa4cbc03f3d7f80206cbbc80680 upstream. Xommit ac5637611(genirq: Unmask oneshot irqs when thread was not woken) fails to unmask when a !IRQ_ONESHOT threaded handler is handled by handle_level_irq. This happens because thread_mask is or'ed unconditionally in irq_wake_thread(), but for !IRQ_ONESHOT interrupts never cleared. So the check for !desc->thread_active fails and keeps the interrupt disabled. Keep the thread_mask zero for !IRQ_ONESHOT interrupts. Document the thread_mask magic while at it. Reported-and-tested-by: Sven Joachim <svenjoac@gmx.de> Reported-and-tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> So this bug does exist in tags/v3.0.23, but has been fixed in latest tree(tags/v3.0.24), we can just reject this bug now.
This is available in linux-yocto-3.0 as: commit c847ac8e8e7447730aef70b94915f1c0880e6578 Author: Thomas Gleixner <tglx@linutronix.de> Date: Tue Mar 6 23:18:54 2012 +0100 genirq: Clear action->thread_mask if IRQ_ONESHOT is not set commit 52abb700e16a9aa4cbc03f3d7f80206cbbc80680 upstream.
Marking this as resolved.
Verified with 1.2 rc3. Tree/branch: poky/1.2_M4 Commit: fae1c7a5fdcea199338b5f91efaafd7c72aec5dd