From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mtiwmhc13.worldnet.att.net ([204.127.131.117]:46189 "EHLO mtiwmhc13.worldnet.att.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751178AbYKWVJm (ORCPT ); Sun, 23 Nov 2008 16:09:42 -0500 Message-ID: <4929C68E.6080401@lwfinger.net> (sfid-20081123_220947_137687_12A27B67) Date: Sun, 23 Nov 2008 15:09:34 -0600 From: Larry Finger MIME-Version: 1.0 To: Michael Buesch , Yuval Hager , LKML , wireless , bcm43xx-dev@lists.berlios.de, Larry Finger Subject: Re: BCM4312 Fails when xdm is started References: <200811151801.02369.yuval@avramzon.net> <200811221654.09399.mb@bu3sch.de> <200811231350.00207.yuval@avramzon.net> <200811231320.30289.mb@bu3sch.de> <20081123204631.21061.qmail@stuge.se> In-Reply-To: <20081123204631.21061.qmail@stuge.se> Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-wireless-owner@vger.kernel.org List-ID: Peter Stuge wrote: > 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). I think by this point the BCM43xx hardware is disabled. >>> [ 258.299173] handlers: >>> [ 258.299176] [] (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? By setting a bit in the appropriate register; however, device is disabled and all bits are set. This is a false indication. >>> [ 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: [] try_one_irq+0x15/0xe8 >>> [ 258.392016] {in-hardirq-W} state was registered at: >>> [ 258.392021] [] __lock_acquire+0x490/0x6bc >>> [ 258.392034] [] lock_acquire+0x5a/0x74 >>> [ 258.392043] [] handle_level_irq+0x12/0xba >>> [ 258.392053] [] _spin_lock+0x1c/0x45 >>> [ 258.392066] [] handle_level_irq+0x12/0xba >>> [ 258.392076] [] handle_level_irq+0x12/0xba >>> [ 258.392085] [] do_IRQ+0x89/0x9f >>> [ 258.392096] [] common_interrupt+0x28/0x30 >>> [ 258.392105] [] _spin_unlock_irqrestore+0x37/0x39 >>> [ 258.392115] [] __setup_irq+0x17a/0x1f3 >>> [ 258.392124] [] start_kernel+0x285/0x2f1 >>> [ 258.392140] [] 0xffffffff >>> [ 258.392159] irq event stamp: 1844456 >>> [ 258.392164] hardirqs last enabled at (1844456): [] _spin_unlock_irq+0x20/0x23 >>> [ 258.392175] hardirqs last disabled at (1844455): [] _spin_lock_irq+0xa/0x4b >>> [ 258.392186] softirqs last enabled at (1844310): [] do_softirq+0x37/0x4d >>> [ 258.392198] softirqs last disabled at (1844447): [] 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. :\ >>From a config file posted earlier, the OP is using SLAB. Is there any point in trying SLUB? Larry