Re: BCM4312 Fails when xdm is started

[Peter Stuge]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/