Hello kernel community, I'm reporting a bug, since recent kernel versions cause my laptop to hand during boot. Rendering it practically useless. Stable version 3.2.8 works. Stable version 3.2.9 fails. Mainline 3.3.0 fails as well. Reverting: [b4bc724e82e80478cba5fe9825b62e71ddf78757] genirq: Handle pending irqs in irq_startup() on top of 3.4-rc1 fixes the issue and makes the kernel boot again. I did a git bisect initially, which yielded this patch: [aa0eb3474beae8f6d9dcc2311dc02bea50cfd7b7] genirq: Unmask oneshot irqs when thread was not woken But that was wrong (probably my fault). I post the git bisect log here anyway, might be useful: [aa0eb3474beae8f6d9dcc2311dc02bea50cfd7b7] genirq: Unmask oneshot irqs when thread was not woken Charlie linux-git-stable # git bisect log # bad: [44fb3170ae46f8de964a4bb5b0504e865a6dd7da] Linux 3.2.9 # good: [1de504ea25617f701ac3a246a1c9dfd2246d4900] Linux 3.2.8 git bisect start 'v3.2.9' 'v3.2.8' # good: [4cc383ba35be70d24fb7d43dd67f15f6ec3c7ebc] USB: option: cleanup zte 3g-dongle's pid in option.c git bisect good 4cc383ba35be70d24fb7d43dd67f15f6ec3c7ebc # good: [758e4d3da5bc2a30a7618cb8f1710e096dac0e53] ARM: omap: fix oops in arch/arm/mach-omap2/vp.c when pmic is not found git bisect good 758e4d3da5bc2a30a7618cb8f1710e096dac0e53 # bad: [df9a5f8f94f3276aaa8c960a46f6838f7fdab974] davinci_emac: Do not free all rx dma descriptors during init git bisect bad df9a5f8f94f3276aaa8c960a46f6838f7fdab974 # bad: [37ef0e621b065f2d9e1c37ff42a37d6bd74bf039] genirq: Handle pending irqs in irq_startup() git bisect bad 37ef0e621b065f2d9e1c37ff42a37d6bd74bf039 # good: [72633f08ad74b93530b8e038041c450492a00ed5] ath9k: stop on rates with idx -1 in ath9k rate control's .tx_status git bisect good 72633f08ad74b93530b8e038041c450492a00ed5
I also just recently tested the latest git master (f4e52e7ffde). Same problem, same fix.
(from https://lkml.org/lkml/2012/4/12/46) I have attached my .config [1] and a photo of the latest hanging kernel [2] which is post 3.4 rc-2 by now (f549e088b80). I also attached a correctly working dmesg of current head (again f549e088b80) with the offending patch reverted [3]. [1] http://pastebin.com/fvWAqmqv [2] http://tinypic.com/view.php?pic=2uif21j&s=5 [3] http://pastebin.com/QmMA6hGS
Current head: 2300fd67b4f29eec19addb15a8571837228f63fc (post 3.4-rc4) I did a clean build of my kernel image with a x86_64 defconfig and eventually found out that this is a combination of: CONFIG_SND_MTPAV=y and commit b4bc724e82e8047 So: CONFIG_SND_MTPAV=y + commit b4bc724e82e8047 => Hang CONFIG_SND_MTPAV=y + revert commit b4bc724e => Works! CONFIG_SND_MTPAV=n + commit b4bc724e82e8047 => Works! So the combination of both causes the hang during boot.
I don't think you are testing with this device, right? If the commit above really matters, it must have to anything to do with the interrupt handler in mtpav.c, but the question is why the interrupt is kicked off at all. This is an old ISA-like device without the irq sharing.
I *do* have this device. I have no idea what 'ISA-like' implies, however over here it says: #1: MTPAV on parallel port at 0x378 Also had to supply these as bootparameters: snd_hda_intel.index=0 snd_mtpav.index=1 In order to prevent vlc playing PCM through this MIDI device ;)
Ah, I see. I thought you're testing just the kernel without the actual hardware (e.g. for QA), but you have the real one. Does the crash happen even if you don't connect the device? Or it's only with the device connected?
It's an internal device, I cannot disconnect it without a screwdriver I guess. I do not 'dock' it or something like that. These: [ 4.671773] ALSA device list: [ 4.673076] #0: HDA NVidia at 0xb0000000 irq 21 [ 4.674382] #1: MTPAV on parallel port at 0x378 Are all internal. However, doing lspci -v -v -v -v, I have a hard time finding the device that should correspond with the midi card (since I don't use the driver anymore I don't know 'where' it binds to). Will this info help you?
Hm? MTPAV is a device connected via a parallel port, as you see in the list. The driver controls the parallel port at 0x378, where the box over there has up to 8 MIDI I/O ports. Is this really what you have? I guess you are using a wrong driver at the very first place. MTPAV driver might work somehow, but it's no right choice. For a generic MPU401 interface on a mobo, snd-mpu401 (with proper parameters) is the correct one. Of course, this doesn't justify to keep the kernel crashing at boot, but we need to understand the test situation at first.
Seems to crash because the IRQ handler is enabled too early by mtpav_get_ISA.... which would explain the rest
As far as I see, all the necessary initialization has been done before mtpav_get_ISA(). I guess it's in the interrupt handler that assumes some special case. Maybe snd_mtpav_read_bytes() got stuck...
snd-mtpav must be a wrong driver.
Yes, I guess. How to find out? It's a Compaq Presario V6221eu.
As I mentioned, MTP-AV is an external MIDI box connected via a parallel port. If you're using a laptop, this cannot be it. The device has a fixed port and a fixed irq number like the old good ISA device. If you build the driver into kernel, it'd be started even if no device is actually connected, so it'll poke some ioports and handle the bogus irq.