Michael Buesch wrote: > On Sunday 23 November 2008 12:49:55 Yuval Hager wrote: > > [ 182.891400] ****** b43: B43_MMIO_MACCTL 0x840A0503 > > [ 182.891409] ****** b43: SSB_TMSLOW 0x20150000 > > [ 258.299027] irq 10: nobody cared (try booting with the "irqpoll" option) > > Does the kernel disable the PCI device, if it ignores the IRQ? The kernel disables the IRQ at least internally, maybe also by deconfiguring the interrupt register in any devices using it, which would explain the change in config register 0x3c (but not the changes in all the other bytes, could that be a freak chain reaction inside the hardware?) but I haven't heard/seen the kernel disable the PCI device itself. I don't know if it can. Why doesn't b43 care about this interrupt? Without APIC interrupt 10 is what both device and driver should be using (according to earlier lspci -x output). > > [ 258.299173] handlers: > > [ 258.299176] [<f7906455>] (b43_interrupt_handler+0x0/0x1b7 [b43]) > > [ 258.299212] Disabling IRQ #10 > > [ 258.315148] b43-phy0: Radio hardware status changed to DISABLED > > [ 258.315160] b43-phy0: ******** B43_B43_MMIO_RADIO_HWENABLED_HI 0xFFFFFFFF > > [ 258.342341] kobject: 'rfkill0' (f43b7d78): kobject_uevent_env > > [ 258.342367] kobject: 'rfkill0' (f43b7d78): fill_kobj_path: path = '/class/rfkill/rfkill0' > > [ 258.342418] kobject: 'ssb0:0' (f40dfcd8): fill_kobj_path: path = '/devices/pci0000:00/0000:00:02.0/0000:02:00.0/ssb0:0' Why does the radio hw status changes here? How is the change notified to the driver? > > [ 258.391951] > > [ 258.391956] ================================= > > [ 258.391964] [ INFO: inconsistent lock state ] > > [ 258.391971] 2.6.28-rc5 #15 > > [ 258.391975] --------------------------------- > > [ 258.391980] inconsistent {in-hardirq-W} -> {hardirq-on-W} usage. > > [ 258.391987] X/3965 [HC0[0]:SC1[1]:HE1:SE0] takes: > > [ 258.391993] (&irq_desc_lock_class){++..}, at: [<c0148c60>] try_one_irq+0x15/0xe8 > > [ 258.392016] {in-hardirq-W} state was registered at: > > [ 258.392021] [<c013bc07>] __lock_acquire+0x490/0x6bc > > [ 258.392034] [<c013be8d>] lock_acquire+0x5a/0x74 > > [ 258.392043] [<c01496f8>] handle_level_irq+0x12/0xba > > [ 258.392053] [<c03c4842>] _spin_lock+0x1c/0x45 > > [ 258.392066] [<c01496f8>] handle_level_irq+0x12/0xba > > [ 258.392076] [<c01496f8>] handle_level_irq+0x12/0xba > > [ 258.392085] [<c010564e>] do_IRQ+0x89/0x9f > > [ 258.392096] [<c0103ea8>] common_interrupt+0x28/0x30 > > [ 258.392105] [<c03c4cc2>] _spin_unlock_irqrestore+0x37/0x39 > > [ 258.392115] [<c01487e6>] __setup_irq+0x17a/0x1f3 > > [ 258.392124] [<c05ce79d>] start_kernel+0x285/0x2f1 > > [ 258.392140] [<ffffffff>] 0xffffffff > > [ 258.392159] irq event stamp: 1844456 > > [ 258.392164] hardirqs last enabled at (1844456): [<c03c4b6f>] _spin_unlock_irq+0x20/0x23 > > [ 258.392175] hardirqs last disabled at (1844455): [<c03c4ac3>] _spin_lock_irq+0xa/0x4b > > [ 258.392186] softirqs last enabled at (1844310): [<c0125406>] do_softirq+0x37/0x4d > > [ 258.392198] softirqs last disabled at (1844447): [<c0125406>] do_softirq+0x37/0x4d > > > That's a bit weird. Looks like another bug in the IRQ layer. Something happens with the hardware that confuses the kernel. It's triggered by software but I don't know where.. Like Michael, I'm not too convinced that it is in b43. :\ //Peter -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html