From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1754453AbYKUQZo@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1754453AbYKUQZo (ORCPT <rfc822;w@1wt.eu>);
	Fri, 21 Nov 2008 11:25:44 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755384AbYKUQZZ
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Fri, 21 Nov 2008 11:25:25 -0500
Received: from mtiwmhc12.worldnet.att.net ([204.127.131.116]:36154 "EHLO
	mtiwmhc12.worldnet.att.net" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with ESMTP id S1754893AbYKUQZY (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 21 Nov 2008 11:25:24 -0500
Message-ID: <4926E0F2.5060200@lwfinger.net>
Date: Fri, 21 Nov 2008 10:25:22 -0600
From: Larry Finger <Larry.Finger@lwfinger.net>
User-Agent: Thunderbird 2.0.0.17 (X11/20080922)
MIME-Version: 1.0
To: LKML <linux-kernel@vger.kernel.org>
CC: Peter Stuge <peter@stuge.se>, wireless <linux-wireless@vger.kernel.org>,
       Broadcom Linux <bcm43xx-dev@lists.berlios.de>,
       Yuval Hager <yuval@avramzon.net>
Subject: BCM4312 Fails when xdm is started
References: <200811151801.02369.yuval@avramzon.net>	<491EFB9D.3040002@lwfinger.net>	<200811151907.05636.yuval@avramzon.net> <20081115174623.27321.qmail@stuge.se>
In-Reply-To: <20081115174623.27321.qmail@stuge.se>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

A problem was recently posted to the bcm43xx mailing list that I am unable to
solve. The machine in question is an HP Mini 2133 (HP product number FU346EA)
with a BCM4312 PCIe wireless card. This card is known to work with the b43
driver (I have one.) and it does work on this machine - at least initially.

A problem occurs when xdm/kde is started. Suddenly a read operation on device
hardware returns all ones as though the register does not exist, or if it were
suddenly mismapped. If the OP doesn't try to run xdm, the same problem will
eventually occur, it just takes longer.

This is a 32-bit system running 2.6.28-rc5, but I don't think this is a
regression from some earlier version as the problem was first reported with
kernel 2.6.27-gentoo-r2.

I have complete logs, but before spamming the list with them, I have a question
about the "Zone PFN" settings. On the problem machine, the following list occurs:

[    0.000000] Zone PFN ranges:
[    0.000000]   DMA      0x00000000 -> 0x00001000
[    0.000000]   Normal   0x00001000 -> 0x000373fe
[    0.000000]   HighMem  0x000373fe -> 0x0006feb0

On my 64-bit HP machine, I see:

Zone PFN ranges:
  DMA      0x00000000 -> 0x00001000
  DMA32    0x00001000 -> 0x00100000
  Normal   0x00100000 -> 0x00100000

Is it "normal" for there not to be a DMA32 range with a 32-bit version of Linux?
Certainly all the memory is available to 32-bit DMA. This card does 64-bit DMA,
but the driver falls back to a 32-bit mask for this system.

Is there some kind of memory mapping problem in the PCIe system? Should the
entire log be posted?

Thanks,

Larry

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1757881AbYKURmu@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1757881AbYKURmu (ORCPT <rfc822;w@1wt.eu>);
	Fri, 21 Nov 2008 12:42:50 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756929AbYKURmi
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Fri, 21 Nov 2008 12:42:38 -0500
Received: from bu3sch.de ([62.75.166.246]:44258 "EHLO vs166246.vserver.de"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1750818AbYKURmh (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Fri, 21 Nov 2008 12:42:37 -0500
From: Michael Buesch <mb@bu3sch.de>
To: bcm43xx-dev@lists.berlios.de
Subject: Re: BCM4312 Fails when xdm is started
Date: Fri, 21 Nov 2008 18:42:12 +0100
User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405)
Cc: Larry Finger <Larry.Finger@lwfinger.net>,
       LKML <linux-kernel@vger.kernel.org>,
       wireless <linux-wireless@vger.kernel.org>, Peter Stuge <peter@stuge.se>
References: <200811151801.02369.yuval@avramzon.net> <20081115174623.27321.qmail@stuge.se> <4926E0F2.5060200@lwfinger.net>
In-Reply-To: <4926E0F2.5060200@lwfinger.net>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200811211842.13099.mb@bu3sch.de>
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Friday 21 November 2008 17:25:22 Larry Finger wrote:
> A problem was recently posted to the bcm43xx mailing list that I am unable to
> solve. The machine in question is an HP Mini 2133 (HP product number FU346EA)
> with a BCM4312 PCIe wireless card. This card is known to work with the b43
> driver (I have one.) and it does work on this machine - at least initially.
> 
> A problem occurs when xdm/kde is started. Suddenly a read operation on device
> hardware returns all ones as though the register does not exist, or if it were
> suddenly mismapped. If the OP doesn't try to run xdm, the same problem will
> eventually occur, it just takes longer.

Can you dump PCI config space and SSB registers (TMSLOW, maybe others, too).
It looks like a random bus write disabled the device.

> [    0.000000] Zone PFN ranges:
> [    0.000000]   DMA      0x00000000 -> 0x00001000
> [    0.000000]   Normal   0x00001000 -> 0x000373fe
> [    0.000000]   HighMem  0x000373fe -> 0x0006feb0
> 
> On my 64-bit HP machine, I see:
> 
> Zone PFN ranges:
>   DMA      0x00000000 -> 0x00001000
>   DMA32    0x00001000 -> 0x00100000
>   Normal   0x00100000 -> 0x00100000
> 
> Is it "normal" for there not to be a DMA32 range with a 32-bit version of Linux?

Yeah, I think so.

-- 
Greetings Michael.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1757821AbYKUS2f@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1757821AbYKUS2f (ORCPT <rfc822;w@1wt.eu>);
	Fri, 21 Nov 2008 13:28:35 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756215AbYKUS2M
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Fri, 21 Nov 2008 13:28:12 -0500
Received: from mtiwmhc12.worldnet.att.net ([204.127.131.116]:64627 "EHLO
	mtiwmhc12.worldnet.att.net" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with ESMTP id S1755468AbYKUS2L (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 21 Nov 2008 13:28:11 -0500
Message-ID: <4926FDB3.2030701@lwfinger.net>
Date: Fri, 21 Nov 2008 12:28:03 -0600
From: Larry Finger <Larry.Finger@lwfinger.net>
User-Agent: Thunderbird 2.0.0.17 (X11/20080922)
MIME-Version: 1.0
To: Yuval Hager <yuval@avramzon.net>
CC: Michael Buesch <mb@bu3sch.de>, bcm43xx-dev@lists.berlios.de,
       LKML <linux-kernel@vger.kernel.org>,
       wireless <linux-wireless@vger.kernel.org>, Peter Stuge <peter@stuge.se>
Subject: Re: BCM4312 Fails when xdm is started
References: <200811151801.02369.yuval@avramzon.net> <20081115174623.27321.qmail@stuge.se> <4926E0F2.5060200@lwfinger.net> <200811211842.13099.mb@bu3sch.de>
In-Reply-To: <200811211842.13099.mb@bu3sch.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Yuval,

Michael Buesch wrote:
> 
> Can you dump PCI config space and SSB registers (TMSLOW, maybe others, too).
> It looks like a random bus write disabled the device.

Please incorporate the following patch and run your system. In addition, run the
following command when the wireless is working and after it fails:

sudo lspci -d 14e4:4312 -x

Post the results of the above commands and any entries in /var/log/messages that
dump registers. They should all be prefaced with ****


Index: linux-2.6/drivers/net/wireless/b43/phy_common.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/b43/phy_common.c
+++ linux-2.6/drivers/net/wireless/b43/phy_common.c
@@ -133,6 +133,11 @@ void b43_radio_lock(struct b43_wldev *de

 	macctl = b43_read32(dev, B43_MMIO_MACCTL);
 	B43_WARN_ON(macctl & B43_MACCTL_RADIOLOCK);
+	if (macctl & B43_MACCTL_RADIOLOCK) {
+		printk(KERN_INFO "****** b43: B43_MMIO_MACCTL 0x%X\n", macctl);
+		printk(KERN_INFO "****** b43: SSB_TMSLOW 0x%X\n",
+			ssb_read32(dev->dev, SSB_TMSLOW));
+	}
 	macctl |= B43_MACCTL_RADIOLOCK;
 	b43_write32(dev, B43_MMIO_MACCTL, macctl);
 	/* Commit the write and wait for the device
@@ -150,6 +155,11 @@ void b43_radio_unlock(struct b43_wldev *
 	/* unlock */
 	macctl = b43_read32(dev, B43_MMIO_MACCTL);
 	B43_WARN_ON(!(macctl & B43_MACCTL_RADIOLOCK));
+	if (macctl & B43_MACCTL_RADIOLOCK) {
+		printk(KERN_INFO "****** b43: B43_MMIO_MACCTL 0x%X\n", macctl);
+		printk(KERN_INFO "****** b43: SSB_TMSLOW 0x%X\n",
+			ssb_read32(dev->dev, SSB_TMSLOW));
+	}
 	macctl &= ~B43_MACCTL_RADIOLOCK;
 	b43_write32(dev, B43_MMIO_MACCTL, macctl);
 }
Index: linux-2.6/drivers/net/wireless/b43/rfkill.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/b43/rfkill.c
+++ linux-2.6/drivers/net/wireless/b43/rfkill.c
@@ -63,6 +63,8 @@ static void b43_rfkill_poll(struct input
 		report_change = 1;
 		b43info(wl, "Radio hardware status changed to %s\n",
 			enabled ? "ENABLED" : "DISABLED");
+		b43info(wl, "******** B43_B43_MMIO_RADIO_HWENABLED_HI 0x%X\n",
+			b43_read32(dev, B43_MMIO_RADIO_HWENABLED_HI));
 	}
 	mutex_unlock(&wl->mutex);




From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1755531AbYKVGnZ@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1755531AbYKVGnZ (ORCPT <rfc822;w@1wt.eu>);
	Sat, 22 Nov 2008 01:43:25 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751871AbYKVGnO
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sat, 22 Nov 2008 01:43:14 -0500
Received: from hapkido.dreamhost.com ([66.33.216.122]:40933 "EHLO
	hapkido.dreamhost.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751761AbYKVGnN (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Sat, 22 Nov 2008 01:43:13 -0500
From: Yuval Hager <yuval@avramzon.net>
To: Larry Finger <Larry.Finger@lwfinger.net>
Subject: Re: BCM4312 Fails when xdm is started
Date: Sat, 22 Nov 2008 08:39:24 +0200
User-Agent: KMail/1.9.9
Cc: Michael Buesch <mb@bu3sch.de>, bcm43xx-dev@lists.berlios.de,
       LKML <linux-kernel@vger.kernel.org>,
       wireless <linux-wireless@vger.kernel.org>, Peter Stuge <peter@stuge.se>
References: <200811151801.02369.yuval@avramzon.net> <200811211842.13099.mb@bu3sch.de> <4926FDB3.2030701@lwfinger.net>
In-Reply-To: <4926FDB3.2030701@lwfinger.net>
MIME-Version: 1.0
Content-Type: multipart/signed;
  boundary="nextPart1446152.EUCJFn6g4S";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <200811220839.32674.yuval@avramzon.net>
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

--nextPart1446152.EUCJFn6g4S
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Friday 21 November 2008, Larry Finger wrote:
> Yuval,
>
> Michael Buesch wrote:
> > Can you dump PCI config space and SSB registers (TMSLOW, maybe others,
> > too). It looks like a random bus write disabled the device.
>
> Please incorporate the following patch and run your system. In addition,
> run the following command when the wireless is working and after it fails:
>
> sudo lspci -d 14e4:4312 -x
>

When the wireless is working:
$ lspci -d 14e4:4312 -x
02:00.0 Network controller: Broadcom Corporation BCM4312 802.11a/b/g (rev 0=
2)
00: e4 14 12 43 06 01 10 00 02 00 80 02 08 00 00 00
10: 04 c0 ff fd 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 3c 10 71 13
30: 00 00 00 00 40 00 00 00 00 00 00 00 0a 01 00 00

After it fails:
$ lspci -d 14e4:4312 -x
02:00.0 Network controller: Broadcom Corporation BCM4312 802.11a/b/g (rev 0=
2)
00: e4 14 12 43 00 00 10 00 02 00 80 02 00 00 00 00
10: 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 3c 10 71 13
30: 00 00 00 00 40 00 00 00 00 00 00 00 00 01 00 00


> Post the results of the above commands and any entries in /var/log/messag=
es
> that dump registers. They should all be prefaced with ****
>

Sorry for the long time to reply, it took a while to recreate the problem.=
=20
According to the logs, it happened exactly when I checked the machine in th=
e=20
morning.
At the beginning, the register dumps look like this:

[   57.279984] ****** b43: B43_MMIO_MACCTL 0x840A0503
[   57.279992] ****** b43: SSB_TMSLOW 0x20150000
(these line repeat exactly the same. Skipping)

[31723.961262] ****** b43: B43_MMIO_MACCTL 0x840A0503
[31723.961275] ****** b43: SSB_TMSLOW 0x20150000
[31732.959490] b43-phy0: Radio hardware status changed to DISABLED
[31732.959505] b43-phy0: ******** B43_B43_MMIO_RADIO_HWENABLED_HI 0xFFFFFFFF
[31738.130551] wlan0: No ProbeResp from current AP 00:22:3f:18:89:5e - assu=
me=20
out of range
[31783.855931] ------------[ cut here ]------------
[31783.855944] WARNING: at drivers/net/wireless/b43/phy_common.c:135=20
b43_radio_lock+0x29/0x7e [b43]()
[31783.855955] Modules linked in: via drm rfkill_input hci_usb b43 led_clas=
s=20
input_polldev rtc snd_hda_intel snd_pcm snd_tim
er snd_page_alloc snd_hwdep snd soundcore ehci_hcd uhci_hcd usbcore sg ssb=
=20
video output via_agp agpgart
[31783.856023] Pid: 1220, comm: b43 Not tainted 2.6.28-rc5 #13
[31783.856032] Call Trace:
[31783.856055]  [<c011f4e9>] warn_on_slowpath+0x40/0x59
[31783.856102]  [<f7d93da3>] b43_gphy_op_write+0x25/0x29 [b43]
[31783.856143]  [<f7d90735>] b43_calc_nrssi_slope+0x103e/0x105a [b43]
[31783.856180]  [<f7cba429>] ssb_pci_write32+0x15/0x3f [ssb]
[31783.856209]  [<f7cba545>] ssb_pci_read16+0x31/0x3f [ssb]
[31783.856244]  [<f7d8854c>] __b43_shm_read16+0x79/0x81 [b43]
[31783.856272]  [<f7cba545>] ssb_pci_read16+0x31/0x3f [ssb]
[31783.856306]  [<f7d8854c>] __b43_shm_read16+0x79/0x81 [b43]
[31783.856334]  [<f7cba4eb>] ssb_pci_read32+0x12/0x3b [ssb]
[31783.856370]  [<f7d8dc77>] b43_radio_lock+0x29/0x7e [b43]
[31783.856408]  [<f7d91e92>] b43_gphy_op_adjust_txpower+0x111/0x138 [b43]
[31783.856446]  [<f7d8da06>] b43_phy_txpower_adjust_work+0x0/0x39 [b43]
[31783.856483]  [<f7d8da36>] b43_phy_txpower_adjust_work+0x30/0x39 [b43]
[31783.856500]  [<c012b2a4>] run_workqueue+0x6a/0xdf
[31783.856515]  [<c012b9ba>] worker_thread+0x0/0xbd
[31783.856527]  [<c012ba6d>] worker_thread+0xb3/0xbd
[31783.856545]  [<c012dc8c>] autoremove_wake_function+0x0/0x2d
[31783.856560]  [<c012dbc9>] kthread+0x38/0x5f
[31783.856573]  [<c012db91>] kthread+0x0/0x5f
[31783.856588]  [<c01040a7>] kernel_thread_helper+0x7/0x10
[31783.856598] ---[ end trace 7548c7ede66fa0d3 ]---
[31783.856607] ****** b43: B43_MMIO_MACCTL 0xFFFFFFFF
[31783.856616] ****** b43: SSB_TMSLOW 0xFFFFFFFF

And from now on, all reads are ones. I have the full logs if you need.

Cheers,

=2D-yuval

--nextPart1446152.EUCJFn6g4S
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEABECAAYFAkknqSQACgkQl7qmwPqEj98XHgCdHTuB1NotQMa1OZe/eaIwvG5o
tR0AoMJnmGJnmwF8oM9ZVtZbnKioECmj
=3Xyl
-----END PGP SIGNATURE-----

--nextPart1446152.EUCJFn6g4S--

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1758526AbYKVPNm@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1758526AbYKVPNm (ORCPT <rfc822;w@1wt.eu>);
	Sat, 22 Nov 2008 10:13:42 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1758267AbYKVPNe
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sat, 22 Nov 2008 10:13:34 -0500
Received: from bu3sch.de ([62.75.166.246]:41785 "EHLO vs166246.vserver.de"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1758250AbYKVPNd (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Sat, 22 Nov 2008 10:13:33 -0500
From: Michael Buesch <mb@bu3sch.de>
To: Yuval Hager <yuval@avramzon.net>
Subject: Re: BCM4312 Fails when xdm is started
Date: Sat, 22 Nov 2008 16:13:00 +0100
User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405)
Cc: Larry Finger <Larry.Finger@lwfinger.net>, bcm43xx-dev@lists.berlios.de,
       LKML <linux-kernel@vger.kernel.org>,
       wireless <linux-wireless@vger.kernel.org>, Peter Stuge <peter@stuge.se>
References: <200811151801.02369.yuval@avramzon.net> <4926FDB3.2030701@lwfinger.net> <200811220839.32674.yuval@avramzon.net>
In-Reply-To: <200811220839.32674.yuval@avramzon.net>
MIME-Version: 1.0
Content-Disposition: inline
Message-Id: <200811221613.00303.mb@bu3sch.de>
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Saturday 22 November 2008 07:39:24 Yuval Hager wrote:
> On Friday 21 November 2008, Larry Finger wrote:
> > Yuval,
> >
> > Michael Buesch wrote:
> > > Can you dump PCI config space and SSB registers (TMSLOW, maybe others,
> > > too). It looks like a random bus write disabled the device.
> >
> > Please incorporate the following patch and run your system. In addition,
> > run the following command when the wireless is working and after it fails:
> >
> > sudo lspci -d 14e4:4312 -x
> >
> 
> When the wireless is working:
> $ lspci -d 14e4:4312 -x
> 02:00.0 Network controller: Broadcom Corporation BCM4312 802.11a/b/g (rev 02)
> 00: e4 14 12 43 06 01 10 00 02 00 80 02 08 00 00 00
> 10: 04 c0 ff fd 00 00 00 00 00 00 00 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 3c 10 71 13
> 30: 00 00 00 00 40 00 00 00 00 00 00 00 0a 01 00 00
> 
> After it fails:
> $ lspci -d 14e4:4312 -x
> 02:00.0 Network controller: Broadcom Corporation BCM4312 802.11a/b/g (rev 02)
> 00: e4 14 12 43 00 00 10 00 02 00 80 02 00 00 00 00
                  ^^                      ^^
Somebody disabled MMIO and busmastering.
And somebody cleared the CACHE_LINE_SIZE register.

> 10: 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 3c 10 71 13
> 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 01 00 00

-- 
Greetings Michael.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1758557AbYKVPcZ@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1758557AbYKVPcZ (ORCPT <rfc822;w@1wt.eu>);
	Sat, 22 Nov 2008 10:32:25 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1758282AbYKVPcO
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sat, 22 Nov 2008 10:32:14 -0500
Received: from mtiwmhc13.worldnet.att.net ([204.127.131.117]:33295 "EHLO
	mtiwmhc13.worldnet.att.net" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with ESMTP id S1758267AbYKVPcN (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Sat, 22 Nov 2008 10:32:13 -0500
Message-ID: <492825F8.6020606@lwfinger.net>
Date: Sat, 22 Nov 2008 09:32:08 -0600
From: Larry Finger <Larry.Finger@lwfinger.net>
User-Agent: Thunderbird 2.0.0.17 (X11/20080922)
MIME-Version: 1.0
To: Michael Buesch <mb@bu3sch.de>
CC: Yuval Hager <yuval@avramzon.net>, bcm43xx-dev@lists.berlios.de,
       LKML <linux-kernel@vger.kernel.org>,
       wireless <linux-wireless@vger.kernel.org>, Peter Stuge <peter@stuge.se>
Subject: Re: BCM4312 Fails when xdm is started
References: <200811151801.02369.yuval@avramzon.net> <4926FDB3.2030701@lwfinger.net> <200811220839.32674.yuval@avramzon.net> <200811221613.00303.mb@bu3sch.de>
In-Reply-To: <200811221613.00303.mb@bu3sch.de>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Michael Buesch wrote:

> Somebody disabled MMIO and busmastering.
> And somebody cleared the CACHE_LINE_SIZE register.

Are these all the read/write bits in the configuration area? Should I conclude
that someone zeroed this area?

In case the kernel memory diagnostics don't help, is there any way to trap
writes to the configuration registers?

Larry

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1758716AbYKVPy6@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1758716AbYKVPy6 (ORCPT <rfc822;w@1wt.eu>);
	Sat, 22 Nov 2008 10:54:58 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1758544AbYKVPyi
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sat, 22 Nov 2008 10:54:38 -0500
Received: from bu3sch.de ([62.75.166.246]:48900 "EHLO vs166246.vserver.de"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1758531AbYKVPyh (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Sat, 22 Nov 2008 10:54:37 -0500
From: Michael Buesch <mb@bu3sch.de>
To: Larry Finger <Larry.Finger@lwfinger.net>
Subject: Re: BCM4312 Fails when xdm is started
Date: Sat, 22 Nov 2008 16:54:09 +0100
User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405)
Cc: Yuval Hager <yuval@avramzon.net>, bcm43xx-dev@lists.berlios.de,
       LKML <linux-kernel@vger.kernel.org>,
       wireless <linux-wireless@vger.kernel.org>, Peter Stuge <peter@stuge.se>
References: <200811151801.02369.yuval@avramzon.net> <200811221613.00303.mb@bu3sch.de> <492825F8.6020606@lwfinger.net>
In-Reply-To: <492825F8.6020606@lwfinger.net>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200811221654.09399.mb@bu3sch.de>
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Saturday 22 November 2008 16:32:08 Larry Finger wrote:
> Michael Buesch wrote:
> 
> > Somebody disabled MMIO and busmastering.
> > And somebody cleared the CACHE_LINE_SIZE register.
> 
> Are these all the read/write bits in the configuration area? Should I conclude
> that someone zeroed this area?

Yeah well. I'm not sure. It _looks_ like someone completely cut the physical
power line to the card and it reset its complete PCI config.
So well, X does poke with the PCI devices. But as you said it also happens if
X doesn't run, I'd rule that out.
But I would not rule out a fucked BIOS, yet.
Does the BIOS have any powersave options and/or spread-spectrum options for
the PCI-bus? Can you try to turn them all off?
I have a machine that has PCI-slot autodetect and turns of the PCI clock, if
it doesn't detect a card on that slot. Also turn that off, if you have it, too.

> In case the kernel memory diagnostics don't help, is there any way to trap
> writes to the configuration registers?

Well, if we have random memory corruption, that can hit memory and MMIO.
It doesn't hurt to turn on all debugging options. Often you get some hint
by doing so.

-- 
Greetings Michael.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1757064AbYKWHaI@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1757064AbYKWHaI (ORCPT <rfc822;w@1wt.eu>);
	Sun, 23 Nov 2008 02:30:08 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751999AbYKWH3z
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sun, 23 Nov 2008 02:29:55 -0500
Received: from sd-green-bigip-145.dreamhost.com ([208.97.132.145]:53711 "EHLO
	spunkymail-a2.g.dreamhost.com" rhost-flags-OK-OK-OK-FAIL)
	by vger.kernel.org with ESMTP id S1751772AbYKWH3y (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Sun, 23 Nov 2008 02:29:54 -0500
X-Greylist: delayed 89293 seconds by postgrey-1.27 at vger.kernel.org; Sun, 23 Nov 2008 02:29:54 EST
From: Yuval Hager <yuval@avramzon.net>
To: Michael Buesch <mb@bu3sch.de>
Subject: Re: BCM4312 Fails when xdm is started
Date: Sun, 23 Nov 2008 09:26:25 +0200
User-Agent: KMail/1.9.9
Cc: Larry Finger <Larry.Finger@lwfinger.net>, bcm43xx-dev@lists.berlios.de,
       LKML <linux-kernel@vger.kernel.org>,
       wireless <linux-wireless@vger.kernel.org>, Peter Stuge <peter@stuge.se>
References: <200811151801.02369.yuval@avramzon.net> <492825F8.6020606@lwfinger.net> <200811221654.09399.mb@bu3sch.de>
In-Reply-To: <200811221654.09399.mb@bu3sch.de>
MIME-Version: 1.0
Content-Type: multipart/signed;
  boundary="nextPart6376066.XXdu72Ki2y";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <200811230926.28948.yuval@avramzon.net>
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

--nextPart6376066.XXdu72Ki2y
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Saturday 22 November 2008, Michael Buesch wrote:
> On Saturday 22 November 2008 16:32:08 Larry Finger wrote:
> > Michael Buesch wrote:
> > > Somebody disabled MMIO and busmastering.
> > > And somebody cleared the CACHE_LINE_SIZE register.
> >
> > Are these all the read/write bits in the configuration area? Should I
> > conclude that someone zeroed this area?
>
> Yeah well. I'm not sure. It _looks_ like someone completely cut the
> physical power line to the card and it reset its complete PCI config.
> So well, X does poke with the PCI devices. But as you said it also happens
> if X doesn't run, I'd rule that out.
> But I would not rule out a fucked BIOS, yet.
> Does the BIOS have any powersave options and/or spread-spectrum options f=
or
> the PCI-bus? Can you try to turn them all off?
> I have a machine that has PCI-slot autodetect and turns of the PCI clock,
> if it doesn't detect a card on that slot. Also turn that off, if you have
> it, too.
>
> > In case the kernel memory diagnostics don't help, is there any way to
> > trap writes to the configuration registers?
>
> Well, if we have random memory corruption, that can hit memory and MMIO.
> It doesn't hurt to turn on all debugging options. Often you get some hint
> by doing so.

I've enabled all CONFIG*DEBUG I could find relevant, and ran the system wit=
h:
'debug memory_corruption_check=3D1 devres.log=3D1 debug_objects debugpat=20
acpi.debug_layer=3D0x00410002 acpi.debug_level=3D0xffffffff'
but no hint appears in the logs during the failure.

I did find that certain events recreate the problem immediately. if I 'xset=
=20
dpms force standby' it happens on wakeup. 'xset -dpms' causes this=20
immediately as well. If I load X without DPMS support, it still happens aft=
er=20
the monitor is waken up from (hardware?) blackness.

=2D-yuval

--nextPart6376066.XXdu72Ki2y
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEABECAAYFAkkpBaQACgkQl7qmwPqEj9+5xwCePVEdxd06VeZD/7J9W4W37qro
xN8AniPoNoQykUukczuFFu11P+zm8Mom
=RM4s
-----END PGP SIGNATURE-----

--nextPart6376066.XXdu72Ki2y--

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1758354AbYKWLxo@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1758354AbYKWLxo (ORCPT <rfc822;w@1wt.eu>);
	Sun, 23 Nov 2008 06:53:44 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757727AbYKWLxd
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sun, 23 Nov 2008 06:53:33 -0500
Received: from balanced.mail.policyd.dreamhost.com ([208.97.132.119]:36279
	"EHLO spunkymail-a5.g.dreamhost.com" rhost-flags-OK-OK-OK-FAIL)
	by vger.kernel.org with ESMTP id S1756559AbYKWLxa (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Sun, 23 Nov 2008 06:53:30 -0500
From: Yuval Hager <yuval@avramzon.net>
To: Michael Buesch <mb@bu3sch.de>
Subject: Re: BCM4312 Fails when xdm is started
Date: Sun, 23 Nov 2008 13:49:55 +0200
User-Agent: KMail/1.9.9
Cc: Larry Finger <Larry.Finger@lwfinger.net>, bcm43xx-dev@lists.berlios.de,
       LKML <linux-kernel@vger.kernel.org>,
       wireless <linux-wireless@vger.kernel.org>, Peter Stuge <peter@stuge.se>
References: <200811151801.02369.yuval@avramzon.net> <492825F8.6020606@lwfinger.net> <200811221654.09399.mb@bu3sch.de>
In-Reply-To: <200811221654.09399.mb@bu3sch.de>
MIME-Version: 1.0
Content-Type: multipart/signed;
  boundary="nextPart1293603.WXutiVnh8I";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <200811231350.00207.yuval@avramzon.net>
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

--nextPart1293603.WXutiVnh8I
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

> It doesn't hurt to turn on all debugging options. Often you get some hint
> by doing so.

I booted with 'root=3D/dev/sda3 debug memory_corruption_check=3D1 devres.lo=
g=3D1 debug_objects debugpat=20
acpi.debug_layer=3D0x00410002 acpi.debug_level=3D0xffffffff acpi=3Doff noap=
ic nolapic irqpoll pci=3Dnoacpi' and issued 'xset dpms force=20
standby'. After touching the mouse the system locked for about a minute, an=
d the wireless stopped working.=20
Here's the log portion, I hope it provides a hint of some sort:

[  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)
[  258.299038] Pid: 0, comm: swapper Not tainted 2.6.28-rc5 #15
[  258.299043] Call Trace:
[  258.299062]  [<c0148d9a>] __report_bad_irq+0x24/0x69
[  258.299071]  [<c0148da1>] __report_bad_irq+0x2b/0x69
[  258.299080]  [<c0148ec8>] note_interrupt+0xe9/0x12d
[  258.299090]  [<c014976d>] handle_level_irq+0x87/0xba
[  258.299101]  [<c010564e>] do_IRQ+0x89/0x9f
[  258.299109]  [<c0103ea8>] common_interrupt+0x28/0x30
[  258.299119]  [<c0125406>] do_softirq+0x37/0x4d
[  258.299127]  [<c0125301>] __do_softirq+0x62/0x130
[  258.299135]  [<c0125406>] do_softirq+0x37/0x4d
[  258.299142]  [<c0105653>] do_IRQ+0x8e/0x9f
[  258.299150]  [<c0103ea8>] common_interrupt+0x28/0x30
[  258.299161]  [<c0108682>] default_idle+0x2f/0x4c
[  258.299168]  [<c0101a20>] cpu_idle+0x63/0x77
[  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 =3D '/cl=
ass/rfkill/rfkill0'
[  258.342418] kobject: 'ssb0:0' (f40dfcd8): fill_kobj_path: path =3D '/dev=
ices/pci0000:00/0000:00:02.0/0000:02:00.0/ssb0:0'
[  258.391951]=20
[  258.391956] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
[  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_unlo=
ck_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
[  258.392208]=20
[  258.392209] other info that might help us debug this:
[  258.392215] no locks held by X/3965.
[  258.392219]=20
[  258.392220] stack backtrace:
[  258.392226] Pid: 3965, comm: X Not tainted 2.6.28-rc5 #15
[  258.392231] Call Trace:
[  258.392241]  [<c0139175>] print_usage_bug+0x13d/0x146
[  258.392249]  [<c013a2ff>] mark_lock+0x4b1/0x7c7
[  258.392257]  [<c013bc7e>] __lock_acquire+0x507/0x6bc
[  258.392266]  [<c013be8d>] lock_acquire+0x5a/0x74
[  258.392275]  [<c0148c60>] try_one_irq+0x15/0xe8
[  258.392283]  [<c03c4842>] _spin_lock+0x1c/0x45
[  258.392291]  [<c0148c60>] try_one_irq+0x15/0xe8
[  258.392300]  [<c0148c60>] try_one_irq+0x15/0xe8
[  258.392308]  [<c03c4b6f>] _spin_unlock_irq+0x20/0x23
[  258.392317]  [<c0148d33>] poll_spurious_irqs+0x0/0x43
[  258.392326]  [<c0148d55>] poll_spurious_irqs+0x22/0x43
[  258.392338]  [<c012874a>] run_timer_softirq+0x101/0x156
[  258.392346]  [<c0125321>] __do_softirq+0x82/0x130
[  258.392354]  [<c0125406>] do_softirq+0x37/0x4d
[  258.392362]  [<c0105653>] do_IRQ+0x8e/0x9f
[  258.392370]  [<c0103ea8>] common_interrupt+0x28/0x30
[  260.311944] wlan0: No ProbeResp from current AP 00:22:3f:18:89:5e - assu=
me out of range
[  304.082520] ------------[ cut here ]------------
[  304.082531] WARNING: at drivers/net/wireless/b43/phy_common.c:135 b43_ra=
dio_lock+0x29/0x7c [b43]()
[  304.082538] Modules linked in: rfkill_input b43 ssb led_class input_poll=
dev via drm rtc hci_usb snd_h
da_intel snd_pcm snd_timer snd_page_alloc snd_hwdep snd soundcore ehci_hcd =
uhci_hcd usbcore sg via_agp a
gpgart
[  304.082593] Pid: 5913, comm: b43 Not tainted 2.6.28-rc5 #15
[  304.082599] Call Trace:
[  304.082618]  [<c012171f>] warn_on_slowpath+0x40/0x59
[  304.082643]  [<f7901c94>] b43_shm_read16+0x20/0x42 [b43]
[  304.082666]  [<f7b9e4dc>] ssb_pci_read32+0x12/0x3b [ssb]
[  304.082686]  [<f7906ded>] b43_radio_lock+0x29/0x7c [b43]
[  304.082706]  [<f790b030>] b43_gphy_op_adjust_txpower+0x112/0x139 [b43]
[  304.082727]  [<f7906ba0>] b43_phy_txpower_adjust_work+0x32/0x3b [b43]
[  304.082740]  [<c012de6d>] run_workqueue+0xbf/0x192
[  304.082748]  [<c012de2f>] run_workqueue+0x81/0x192
[  304.082767]  [<f7906b6e>] b43_phy_txpower_adjust_work+0x0/0x3b [b43]
[  304.082778]  [<c012e72a>] worker_thread+0x0/0xbd
[  304.082786]  [<c012e7dd>] worker_thread+0xb3/0xbd
[  304.082796]  [<c0130bcc>] autoremove_wake_function+0x0/0x2d
[  304.082803]  [<c0130b10>] kthread+0x38/0x60
[  304.082810]  [<c0130ad8>] kthread+0x0/0x60
[  304.082820]  [<c01041c7>] kernel_thread_helper+0x7/0x10
[  304.082826] ---[ end trace 6ecefdf7cfe131b0 ]---
[  304.082832] ****** b43: B43_MMIO_MACCTL 0xFFFFFFFF
[  304.082837] ****** b43: SSB_TMSLOW 0xFFFFFFFF

=2D-yuval

--nextPart1293603.WXutiVnh8I
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEUEABECAAYFAkkpQ2gACgkQl7qmwPqEj9934ACYmd501gVpP6QRR0PlI9AkDTtR
oQCfQfd/gOh6Y3rLrDlQ9QT9b7q2PeY=
=qqgF
-----END PGP SIGNATURE-----

--nextPart1293603.WXutiVnh8I--

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1758856AbYKWMVl@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1758856AbYKWMVl (ORCPT <rfc822;w@1wt.eu>);
	Sun, 23 Nov 2008 07:21:41 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1758365AbYKWMVA
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sun, 23 Nov 2008 07:21:00 -0500
Received: from bu3sch.de ([62.75.166.246]:33953 "EHLO vs166246.vserver.de"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1756717AbYKWMU6 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Sun, 23 Nov 2008 07:20:58 -0500
From: Michael Buesch <mb@bu3sch.de>
To: Yuval Hager <yuval@avramzon.net>
Subject: Re: BCM4312 Fails when xdm is started
Date: Sun, 23 Nov 2008 13:20:30 +0100
User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405)
Cc: Larry Finger <Larry.Finger@lwfinger.net>, bcm43xx-dev@lists.berlios.de,
       LKML <linux-kernel@vger.kernel.org>,
       wireless <linux-wireless@vger.kernel.org>, Peter Stuge <peter@stuge.se>
References: <200811151801.02369.yuval@avramzon.net> <200811221654.09399.mb@bu3sch.de> <200811231350.00207.yuval@avramzon.net>
In-Reply-To: <200811231350.00207.yuval@avramzon.net>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200811231320.30289.mb@bu3sch.de>
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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?


> [  258.299038] Pid: 0, comm: swapper Not tainted 2.6.28-rc5 #15
> [  258.299043] Call Trace:
> [  258.299062]  [<c0148d9a>] __report_bad_irq+0x24/0x69
> [  258.299071]  [<c0148da1>] __report_bad_irq+0x2b/0x69
> [  258.299080]  [<c0148ec8>] note_interrupt+0xe9/0x12d
> [  258.299090]  [<c014976d>] handle_level_irq+0x87/0xba
> [  258.299101]  [<c010564e>] do_IRQ+0x89/0x9f
> [  258.299109]  [<c0103ea8>] common_interrupt+0x28/0x30
> [  258.299119]  [<c0125406>] do_softirq+0x37/0x4d
> [  258.299127]  [<c0125301>] __do_softirq+0x62/0x130
> [  258.299135]  [<c0125406>] do_softirq+0x37/0x4d
> [  258.299142]  [<c0105653>] do_IRQ+0x8e/0x9f
> [  258.299150]  [<c0103ea8>] common_interrupt+0x28/0x30
> [  258.299161]  [<c0108682>] default_idle+0x2f/0x4c
> [  258.299168]  [<c0101a20>] cpu_idle+0x63/0x77
> [  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'
> [  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.


> [  258.392208] 
> [  258.392209] other info that might help us debug this:
> [  258.392215] no locks held by X/3965.
> [  258.392219] 
> [  258.392220] stack backtrace:
> [  258.392226] Pid: 3965, comm: X Not tainted 2.6.28-rc5 #15
> [  258.392231] Call Trace:
> [  258.392241]  [<c0139175>] print_usage_bug+0x13d/0x146
> [  258.392249]  [<c013a2ff>] mark_lock+0x4b1/0x7c7
> [  258.392257]  [<c013bc7e>] __lock_acquire+0x507/0x6bc
> [  258.392266]  [<c013be8d>] lock_acquire+0x5a/0x74
> [  258.392275]  [<c0148c60>] try_one_irq+0x15/0xe8
> [  258.392283]  [<c03c4842>] _spin_lock+0x1c/0x45
> [  258.392291]  [<c0148c60>] try_one_irq+0x15/0xe8
> [  258.392300]  [<c0148c60>] try_one_irq+0x15/0xe8
> [  258.392308]  [<c03c4b6f>] _spin_unlock_irq+0x20/0x23
> [  258.392317]  [<c0148d33>] poll_spurious_irqs+0x0/0x43
> [  258.392326]  [<c0148d55>] poll_spurious_irqs+0x22/0x43
> [  258.392338]  [<c012874a>] run_timer_softirq+0x101/0x156
> [  258.392346]  [<c0125321>] __do_softirq+0x82/0x130
> [  258.392354]  [<c0125406>] do_softirq+0x37/0x4d
> [  258.392362]  [<c0105653>] do_IRQ+0x8e/0x9f
> [  258.392370]  [<c0103ea8>] common_interrupt+0x28/0x30

-- 
Greetings Michael.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1758949AbYKWPmo@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1758949AbYKWPmo (ORCPT <rfc822;w@1wt.eu>);
	Sun, 23 Nov 2008 10:42:44 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755487AbYKWPme
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sun, 23 Nov 2008 10:42:34 -0500
Received: from mtiwmhc11.worldnet.att.net ([204.127.131.115]:46777 "EHLO
	mtiwmhc11.worldnet.att.net" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with ESMTP id S1751072AbYKWPmd (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Sun, 23 Nov 2008 10:42:33 -0500
Message-ID: <492979E4.1070606@lwfinger.net>
Date: Sun, 23 Nov 2008 09:42:28 -0600
From: Larry Finger <Larry.Finger@lwfinger.net>
User-Agent: Thunderbird 2.0.0.17 (X11/20080922)
MIME-Version: 1.0
To: Michael Buesch <mb@bu3sch.de>
CC: Yuval Hager <yuval@avramzon.net>, bcm43xx-dev@lists.berlios.de,
       LKML <linux-kernel@vger.kernel.org>,
       wireless <linux-wireless@vger.kernel.org>, Peter Stuge <peter@stuge.se>
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>
In-Reply-To: <200811231320.30289.mb@bu3sch.de>
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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?

According to /proc/interrupts that Yuval posted earlier, IRQ 10 is not used.

# cat /proc/interrupts

           CPU0
  0:     271998   IO-APIC-edge      timer
  1:          8   IO-APIC-edge      i8042
  8:          2   IO-APIC-edge      rtc
  9:       2796   IO-APIC-fasteoi   acpi
 12:        132   IO-APIC-edge      i8042
 14:          0   IO-APIC-edge      ide0
 15:          0   IO-APIC-edge      ide1
 16:      29161   IO-APIC-fasteoi   eth0
 17:        503   IO-APIC-fasteoi   HDA Intel
 20:          0   IO-APIC-fasteoi   uhci_hcd:usb2
 21:      11085   IO-APIC-fasteoi   sata_via, ehci_hcd:usb1, uhci_hcd:usb3
 23:          0   IO-APIC-fasteoi   uhci_hcd:usb4
 24:      28003   IO-APIC-fasteoi   b43
NMI:          0   Non-maskable interrupts
LOC:       2098   Local timer interrupts
RES:          0   Rescheduling interrupts
CAL:          0   function call interrupts
TLB:          0   TLB shootdowns
TRM:          0   Thermal event interrupts
SPU:          0   Spurious interrupts
ERR:          0
MIS:          0

After the failure occurs, b43 has disappeared from the IRQ 24 list:

 24:      34154   IO-APIC-fasteoi


Larry

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1753896AbYKWRn2@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753896AbYKWRn2 (ORCPT <rfc822;w@1wt.eu>);
	Sun, 23 Nov 2008 12:43:28 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751130AbYKWRnR
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sun, 23 Nov 2008 12:43:17 -0500
Received: from bu3sch.de ([62.75.166.246]:33162 "EHLO vs166246.vserver.de"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751109AbYKWRnR (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Sun, 23 Nov 2008 12:43:17 -0500
From: Michael Buesch <mb@bu3sch.de>
To: Larry Finger <Larry.Finger@lwfinger.net>
Subject: Re: BCM4312 Fails when xdm is started
Date: Sun, 23 Nov 2008 18:42:46 +0100
User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405)
Cc: Yuval Hager <yuval@avramzon.net>, bcm43xx-dev@lists.berlios.de,
       LKML <linux-kernel@vger.kernel.org>,
       wireless <linux-wireless@vger.kernel.org>, Peter Stuge <peter@stuge.se>
References: <200811151801.02369.yuval@avramzon.net> <200811231320.30289.mb@bu3sch.de> <492979E4.1070606@lwfinger.net>
In-Reply-To: <492979E4.1070606@lwfinger.net>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200811231842.46775.mb@bu3sch.de>
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Sunday 23 November 2008 16:42:28 Larry Finger 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?
> 
> According to /proc/interrupts that Yuval posted earlier, IRQ 10 is not used.

Can you try booting with kernel parameters "noapic" and "noacpi"
and reproduce?

-- 
Greetings Michael.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1754005AbYKWSI5@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1754005AbYKWSI5 (ORCPT <rfc822;w@1wt.eu>);
	Sun, 23 Nov 2008 13:08:57 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750887AbYKWSIq
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sun, 23 Nov 2008 13:08:46 -0500
Received: from bu3sch.de ([62.75.166.246]:37864 "EHLO vs166246.vserver.de"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1750767AbYKWSIp (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Sun, 23 Nov 2008 13:08:45 -0500
From: Michael Buesch <mb@bu3sch.de>
To: Yuval Hager <yuval@avramzon.net>
Subject: Re: BCM4312 Fails when xdm is started
Date: Sun, 23 Nov 2008 19:08:17 +0100
User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405)
References: <200811151801.02369.yuval@avramzon.net> <200811231842.46775.mb@bu3sch.de> <200811231955.41722.yuval@avramzon.net>
In-Reply-To: <200811231955.41722.yuval@avramzon.net>
MIME-Version: 1.0
Content-Disposition: inline
Message-Id: <200811231908.17856.mb@bu3sch.de>
Cc: bcm43xx-dev@lists.berlios.de, LKML <linux-kernel@vger.kernel.org>,
       wireless <linux-wireless@vger.kernel.org>, Peter Stuge <peter@stuge.se>,
       Larry Finger <Larry.Finger@lwfinger.net>
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Sunday 23 November 2008 18:55:36 Yuval Hager wrote:
> On Sunday 23 November 2008, you wrote:
> > On Sunday 23 November 2008 16:42:28 Larry Finger 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?
> > >
> > > According to /proc/interrupts that Yuval posted earlier, IRQ 10 is not
> > > used.
> >
> > Can you try booting with kernel parameters "noapic" and "noacpi"
> > and reproduce?
> 
> The dump above was generated with "acpi=off noapic nolapic pci=noacpi" boot 
> parameters (see my last email). The /proc/interrupts output was from an 
> earlier occurence, without any of these parameters.
> Did you mean to reproduce and provide logs as well as the content 
> of /proc/interrupts before and after the failure?

No thanks.
Anyway, I cannot really help you with the issue.
I don't think this is a b43 bug, but either a hardware bug or a bug
in some code that controls the PCI bus.

-- 
Greetings Michael.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1752138AbYKWUxZ@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752138AbYKWUxZ (ORCPT <rfc822;w@1wt.eu>);
	Sun, 23 Nov 2008 15:53:25 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750862AbYKWUxP
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sun, 23 Nov 2008 15:53:15 -0500
Received: from foo.birdnet.se ([213.88.146.6]:39148 "HELO foo.birdnet.se"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP
	id S1750780AbYKWUxO (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Sun, 23 Nov 2008 15:53:14 -0500
X-Greylist: delayed 399 seconds by postgrey-1.27 at vger.kernel.org; Sun, 23 Nov 2008 15:53:13 EST
Message-ID: <20081123204631.21061.qmail@stuge.se>
Date: Sun, 23 Nov 2008 21:46:31 +0100
From: Peter Stuge <peter@stuge.se>
To: Michael Buesch <mb@bu3sch.de>
Cc: Yuval Hager <yuval@avramzon.net>, LKML <linux-kernel@vger.kernel.org>,
       wireless <linux-wireless@vger.kernel.org>, bcm43xx-dev@lists.berlios.de,
       Larry Finger <Larry.Finger@lwfinger.net>
Subject: Re: BCM4312 Fails when xdm is started
Mail-Followup-To: Michael Buesch <mb@bu3sch.de>,
	Yuval Hager <yuval@avramzon.net>,
	LKML <linux-kernel@vger.kernel.org>,
	wireless <linux-wireless@vger.kernel.org>,
	bcm43xx-dev@lists.berlios.de,
	Larry Finger <Larry.Finger@lwfinger.net>
References: <200811151801.02369.yuval@avramzon.net> <200811221654.09399.mb@bu3sch.de> <200811231350.00207.yuval@avramzon.net> <200811231320.30289.mb@bu3sch.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200811231320.30289.mb@bu3sch.de>
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1752816AbYKWVJx@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752816AbYKWVJx (ORCPT <rfc822;w@1wt.eu>);
	Sun, 23 Nov 2008 16:09:53 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751532AbYKWVJn
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sun, 23 Nov 2008 16:09:43 -0500
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
	<rfc822;linux-kernel@vger.kernel.org>);
	Sun, 23 Nov 2008 16:09:42 -0500
Message-ID: <4929C68E.6080401@lwfinger.net>
Date: Sun, 23 Nov 2008 15:09:34 -0600
From: Larry Finger <Larry.Finger@lwfinger.net>
User-Agent: Thunderbird 2.0.0.17 (X11/20080922)
MIME-Version: 1.0
To: Michael Buesch <mb@bu3sch.de>, Yuval Hager <yuval@avramzon.net>,
       LKML <linux-kernel@vger.kernel.org>,
       wireless <linux-wireless@vger.kernel.org>, bcm43xx-dev@lists.berlios.de,
       Larry Finger <Larry.Finger@lwfinger.net>
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
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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] [<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?

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: [<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. :\

>>From a config file posted earlier, the OP is using SLAB. Is there any point in
trying SLUB?

Larry


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1752369AbYKXIxN@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752369AbYKXIxN (ORCPT <rfc822;w@1wt.eu>);
	Mon, 24 Nov 2008 03:53:13 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751580AbYKXIw7
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 24 Nov 2008 03:52:59 -0500
Received: from sd-green-bigip-83.dreamhost.com ([208.97.132.83]:44428 "EHLO
	spunkymail-a10.g.dreamhost.com" rhost-flags-OK-OK-OK-FAIL)
	by vger.kernel.org with ESMTP id S1751506AbYKXIw6 (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 24 Nov 2008 03:52:58 -0500
From: Yuval Hager <yuval@avramzon.net>
To: Larry Finger <Larry.Finger@lwfinger.net>
Subject: Re: BCM4312 Fails when xdm is started
Date: Mon, 24 Nov 2008 10:49:38 +0200
User-Agent: KMail/1.9.9
Cc: Michael Buesch <mb@bu3sch.de>, LKML <linux-kernel@vger.kernel.org>,
       wireless <linux-wireless@vger.kernel.org>, bcm43xx-dev@lists.berlios.de
References: <200811151801.02369.yuval@avramzon.net> <20081123204631.21061.qmail@stuge.se> <4929C68E.6080401@lwfinger.net>
In-Reply-To: <4929C68E.6080401@lwfinger.net>
MIME-Version: 1.0
Content-Type: multipart/signed;
  boundary="nextPart4121756.b8sE6cYxkZ";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <200811241049.45734.yuval@avramzon.net>
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

--nextPart4121756.b8sE6cYxkZ
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Sunday 23 November 2008, Larry Finger wrote:
> From a config file posted earlier, the OP is using SLAB. Is there any poi=
nt
> in trying SLUB?

Another try, not sure what it means:

* Added CONFIG_SLUB and CONFIG_SLUB_DEBUG

* boot parameters: root=3D/dev/sda3 debug memory_corruption_check=3D1 devre=
s.log=3D1 debug_objects debugpat=20
acpi.debug_layer=3D0x00410002 acpi.debug_level=3D0xffffffff acpi=3Doff apic=
=3Ddebug nolapic irqpoll pci=3Dnoacpi slub_debug=3DFZPU

* cat /proc/interrupts is
           CPU0      =20
  0:      16658    XT-PIC-XT        timer
  1:        289    XT-PIC-XT        i8042
  2:          0    XT-PIC-XT        cascade
  3:         60    XT-PIC-XT        uhci_hcd:usb2, ehci_hcd:usb4
  5:       9163    XT-PIC-XT        sata_via, HDA Intel
  7:          0    XT-PIC-XT        uhci_hcd:usb3
  8:          2    XT-PIC-XT        rtc
 10:       1712    XT-PIC-XT        b43
 11:        131    XT-PIC-XT        uhci_hcd:usb1
 12:        706    XT-PIC-XT        i8042
 14:          0    XT-PIC-XT        ide0
 15:          0    XT-PIC-XT        ide1
NMI:          0   Non-maskable interrupts
LOC:          0   Local timer interrupts
RES:          0   Rescheduling interrupts
CAL:          0   Function call interrupts
TLB:          0   TLB shootdowns
TRM:          0   Thermal event interrupts
SPU:          0   Spurious interrupts
ERR:          0
MIS:          0

* lspci -d 14e4:4312 -x
02:00.0 Network controller: Broadcom Corporation BCM4312 802.11a/b/g (rev 0=
2)
00: e4 14 12 43 06 01 10 00 02 00 80 02 08 00 00 00
10: 04 c0 ff fd 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 3c 10 71 13
30: 00 00 00 00 40 00 00 00 00 00 00 00 0a 01 00 00

* xset dpms force standby
* wake up
* dmesg is virtually the same as before, complaining about nobody handling =
irq 10 and disabling it.
* /proc/interrupts now is
  0:      80987    XT-PIC-XT        timer
  1:       1027    XT-PIC-XT        i8042
  2:          0    XT-PIC-XT        cascade
  3:         60    XT-PIC-XT        uhci_hcd:usb2, ehci_hcd:usb4
  5:      10400    XT-PIC-XT        sata_via, HDA Intel
  7:          0    XT-PIC-XT        uhci_hcd:usb3
  8:          2    XT-PIC-XT        rtc
 10:     200000    XT-PIC-XT        b43
 11:        131    XT-PIC-XT        uhci_hcd:usb1
 12:       3059    XT-PIC-XT        i8042
 14:          0    XT-PIC-XT        ide0
 15:          0    XT-PIC-XT        ide1
NMI:          0   Non-maskable interrupts
LOC:          0   Local timer interrupts
RES:          0   Rescheduling interrupts
CAL:          0   Function call interrupts
TLB:          0   TLB shootdowns
TRM:          0   Thermal event interrupts
SPU:          0   Spurious interrupts
ERR:          0
MIS:          0

* Now check this out - the output of lspci -d 14e4:4312 -x
02:00.0 Network controller: Broadcom Corporation BCM4312 802.11a/b/g (rev f=
f)
00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

(I double checked this)

huh?

=2D-yuval

--nextPart4121756.b8sE6cYxkZ
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEABECAAYFAkkqaqkACgkQl7qmwPqEj9+KSgCcDDvJdZJG6I9bqeOZ+6wsx+Fh
1cUAniIl+yKJFmDIi/FRrfc+jUxZ/bgh
=95vG
-----END PGP SIGNATURE-----

--nextPart4121756.b8sE6cYxkZ--

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1752847AbYKXK4x@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752847AbYKXK4x (ORCPT <rfc822;w@1wt.eu>);
	Mon, 24 Nov 2008 05:56:53 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751918AbYKXK4n
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 24 Nov 2008 05:56:43 -0500
Received: from bu3sch.de ([62.75.166.246]:48794 "EHLO vs166246.vserver.de"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751025AbYKXK4m (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 24 Nov 2008 05:56:42 -0500
From: Michael Buesch <mb@bu3sch.de>
To: Yuval Hager <yuval@avramzon.net>
Subject: Re: BCM4312 Fails when xdm is started
Date: Mon, 24 Nov 2008 11:55:45 +0100
User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405)
Cc: Larry Finger <Larry.Finger@lwfinger.net>,
       LKML <linux-kernel@vger.kernel.org>,
       wireless <linux-wireless@vger.kernel.org>, bcm43xx-dev@lists.berlios.de
References: <200811151801.02369.yuval@avramzon.net> <4929C68E.6080401@lwfinger.net> <200811241049.45734.yuval@avramzon.net>
In-Reply-To: <200811241049.45734.yuval@avramzon.net>
MIME-Version: 1.0
Content-Disposition: inline
Message-Id: <200811241155.47079.mb@bu3sch.de>
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Monday 24 November 2008 09:49:38 Yuval Hager wrote:
> On Sunday 23 November 2008, Larry Finger wrote:
> > From a config file posted earlier, the OP is using SLAB. Is there any point
> > in trying SLUB?
> 
> Another try, not sure what it means:
> 
> * Added CONFIG_SLUB and CONFIG_SLUB_DEBUG
> 
> * boot parameters: root=/dev/sda3 debug memory_corruption_check=1 devres.log=1 debug_objects debugpat 
> acpi.debug_layer=0x00410002 acpi.debug_level=0xffffffff acpi=off apic=debug nolapic irqpoll pci=noacpi slub_debug=FZPU
> 
> * cat /proc/interrupts is
>            CPU0       
>   0:      16658    XT-PIC-XT        timer
>   1:        289    XT-PIC-XT        i8042
>   2:          0    XT-PIC-XT        cascade
>   3:         60    XT-PIC-XT        uhci_hcd:usb2, ehci_hcd:usb4
>   5:       9163    XT-PIC-XT        sata_via, HDA Intel
>   7:          0    XT-PIC-XT        uhci_hcd:usb3
>   8:          2    XT-PIC-XT        rtc
>  10:       1712    XT-PIC-XT        b43
>  11:        131    XT-PIC-XT        uhci_hcd:usb1
>  12:        706    XT-PIC-XT        i8042
>  14:          0    XT-PIC-XT        ide0
>  15:          0    XT-PIC-XT        ide1
> NMI:          0   Non-maskable interrupts
> LOC:          0   Local timer interrupts
> RES:          0   Rescheduling interrupts
> CAL:          0   Function call interrupts
> TLB:          0   TLB shootdowns
> TRM:          0   Thermal event interrupts
> SPU:          0   Spurious interrupts
> ERR:          0
> MIS:          0
> 
> * lspci -d 14e4:4312 -x
> 02:00.0 Network controller: Broadcom Corporation BCM4312 802.11a/b/g (rev 02)
> 00: e4 14 12 43 06 01 10 00 02 00 80 02 08 00 00 00
> 10: 04 c0 ff fd 00 00 00 00 00 00 00 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 3c 10 71 13
> 30: 00 00 00 00 40 00 00 00 00 00 00 00 0a 01 00 00
> 
> * xset dpms force standby
> * wake up
> * dmesg is virtually the same as before, complaining about nobody handling irq 10 and disabling it.

Actually, b43 _does_ use IRQ10 now.
I guess the card dies such a horrible death, that it also asserts the IRQ line forever.

> * /proc/interrupts now is
>   0:      80987    XT-PIC-XT        timer
>   1:       1027    XT-PIC-XT        i8042
>   2:          0    XT-PIC-XT        cascade
>   3:         60    XT-PIC-XT        uhci_hcd:usb2, ehci_hcd:usb4
>   5:      10400    XT-PIC-XT        sata_via, HDA Intel
>   7:          0    XT-PIC-XT        uhci_hcd:usb3
>   8:          2    XT-PIC-XT        rtc
>  10:     200000    XT-PIC-XT        b43
>  11:        131    XT-PIC-XT        uhci_hcd:usb1
>  12:       3059    XT-PIC-XT        i8042
>  14:          0    XT-PIC-XT        ide0
>  15:          0    XT-PIC-XT        ide1
> NMI:          0   Non-maskable interrupts
> LOC:          0   Local timer interrupts
> RES:          0   Rescheduling interrupts
> CAL:          0   Function call interrupts
> TLB:          0   TLB shootdowns
> TRM:          0   Thermal event interrupts
> SPU:          0   Spurious interrupts
> ERR:          0
> MIS:          0
> 
> * Now check this out - the output of lspci -d 14e4:4312 -x
> 02:00.0 Network controller: Broadcom Corporation BCM4312 802.11a/b/g (rev ff)
> 00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 
> (I double checked this)
> 
> huh?

Hah, interesting. I think your hardware may be faulty, in fact.
To me it really seems like the mainboard has power failures on the PCI bus.

This is a laptop, so you can't pull random hardware? Can you run some
hardware burn-in tests like mprime (http://mersenne.org/freesoft/) or memtest?
If that doesn't help, can you try with another operating system?

-- 
Greetings Michael.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1754506AbYKXQMN@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1754506AbYKXQMN (ORCPT <rfc822;w@1wt.eu>);
	Mon, 24 Nov 2008 11:12:13 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753404AbYKXQLz
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 24 Nov 2008 11:11:55 -0500
Received: from mtiwmhc13.worldnet.att.net ([204.127.131.117]:55745 "EHLO
	mtiwmhc13.worldnet.att.net" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with ESMTP id S1752935AbYKXQLy (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 24 Nov 2008 11:11:54 -0500
Message-ID: <492AD249.3020309@lwfinger.net>
Date: Mon, 24 Nov 2008 10:11:53 -0600
From: Larry Finger <Larry.Finger@lwfinger.net>
User-Agent: Thunderbird 2.0.0.17 (X11/20080922)
MIME-Version: 1.0
To: Yuval Hager <yuval@avramzon.net>
CC: Michael Buesch <mb@bu3sch.de>, LKML <linux-kernel@vger.kernel.org>,
       wireless <linux-wireless@vger.kernel.org>, bcm43xx-dev@lists.berlios.de
Subject: Re: BCM4312 Fails when xdm is started
References: <200811151801.02369.yuval@avramzon.net> <4929C68E.6080401@lwfinger.net> <200811241049.45734.yuval@avramzon.net> <200811241155.47079.mb@bu3sch.de>
In-Reply-To: <200811241155.47079.mb@bu3sch.de>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Michael Buesch wrote:
> On Monday 24 November 2008 09:49:38 Yuval Hager wrote:
>> * Now check this out - the output of lspci -d 14e4:4312 -x
>> 02:00.0 Network controller: Broadcom Corporation BCM4312 802.11a/b/g (rev ff)
>> 00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>
>> (I double checked this)
>>
>> huh?
> 
> Hah, interesting. I think your hardware may be faulty, in fact.
> To me it really seems like the mainboard has power failures on the PCI bus.
> 
> This is a laptop, so you can't pull random hardware? Can you run some
> hardware burn-in tests like mprime (http://mersenne.org/freesoft/) or memtest?
> If that doesn't help, can you try with another operating system?
> 

I also think you are seeing a hardware failure. Another test to try is
http://freshmeat.net/projects/cpuburn/?topic_id=146, which will exercise the system.

Larry

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1753615AbYKYFpm@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753615AbYKYFpm (ORCPT <rfc822;w@1wt.eu>);
	Tue, 25 Nov 2008 00:45:42 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751344AbYKYFpd
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 25 Nov 2008 00:45:33 -0500
Received: from sd-green-bigip-207.dreamhost.com ([208.97.132.207]:36023 "EHLO
	spunkymail-a6.g.dreamhost.com" rhost-flags-OK-OK-OK-FAIL)
	by vger.kernel.org with ESMTP id S1751281AbYKYFpc (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 25 Nov 2008 00:45:32 -0500
From: Yuval Hager <yuval@avramzon.net>
To: Larry Finger <Larry.Finger@lwfinger.net>
Subject: Re: BCM4312 Fails when xdm is started
Date: Tue, 25 Nov 2008 07:43:22 +0200
User-Agent: KMail/1.9.9
Cc: Michael Buesch <mb@bu3sch.de>, LKML <linux-kernel@vger.kernel.org>,
       wireless <linux-wireless@vger.kernel.org>, bcm43xx-dev@lists.berlios.de
References: <200811151801.02369.yuval@avramzon.net> <200811241155.47079.mb@bu3sch.de> <492AD249.3020309@lwfinger.net>
In-Reply-To: <492AD249.3020309@lwfinger.net>
MIME-Version: 1.0
Content-Type: multipart/signed;
  boundary="nextPart1314015.9U052YQoBR";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <200811250745.22487.yuval@avramzon.net>
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

--nextPart1314015.9U052YQoBR
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Monday 24 November 2008, Larry Finger wrote:
> Michael Buesch wrote:
> > On Monday 24 November 2008 09:49:38 Yuval Hager wrote:
> >> * Now check this out - the output of lspci -d 14e4:4312 -x
> >> 02:00.0 Network controller: Broadcom Corporation BCM4312 802.11a/b/g
> >> (rev ff) 00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >>
> >> (I double checked this)
> >>
> >> huh?
> >
> > Hah, interesting. I think your hardware may be faulty, in fact.
> > To me it really seems like the mainboard has power failures on the PCI
> > bus.
> >
> > This is a laptop, so you can't pull random hardware? Can you run some
> > hardware burn-in tests like mprime (http://mersenne.org/freesoft/) or
> > memtest? If that doesn't help, can you try with another operating syste=
m?
>
> I also think you are seeing a hardware failure. Another test to try is
> http://freshmeat.net/projects/cpuburn/?topic_id=3D146, which will exercise
> the system.
>
> Larry

I can't argue with what the bits mean, but I must say it doesn't "feel" lik=
e a=20
hardware problem. It is very consistent and deterministic.=20

I've been running mprime & burnBX & burnMMX for over 6 hours and it is all=
=20
fine (memtest not ran yet).

However, I have some few interesting findings.=20
=46irst, this is totally unrelated to b43, but to the PCI. I get the flawed=
 1's=20
read from lspci even without loading b43.

I played around with different video drivers and the results are:
* If using the 'via' driver, I lose the PCIe card immediately upon=20
initialization
* Using the 'openchrome' (trunk version), It works well in the beginning.=20
After first blanking the register reads are all 1's, and then when the scre=
en=20
is blank I get a different read (some registers are correct, some are wrong=
),=20
and when the screen is unblanked, I get 0xff's again. Very consistent and=20
predictabe (same read every time).
* Using the 'vesa' driver I could not recreate the problem. I could not get=
=20
the screen to blank for some reason, but closing the lid, going on=20
standby/hibernate, restarting X - all didn't matter much to the PCI and the=
=20
wireless card kept on working.

=2D-yuval

--nextPart1314015.9U052YQoBR
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEABECAAYFAkkrkPIACgkQl7qmwPqEj9+7dwCdHGvq6qzs4k0IfkfVjx5+JEVr
GSkAoMrmOEclPv9+7lYt8QK4btCwgEIn
=cjl+
-----END PGP SIGNATURE-----

--nextPart1314015.9U052YQoBR--

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1752307AbYKYHSf@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752307AbYKYHSf (ORCPT <rfc822;w@1wt.eu>);
	Tue, 25 Nov 2008 02:18:35 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751189AbYKYHSZ
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 25 Nov 2008 02:18:25 -0500
Received: from foo.birdnet.se ([213.88.146.6]:45490 "HELO foo.birdnet.se"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP
	id S1750910AbYKYHSY (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 25 Nov 2008 02:18:24 -0500
Message-ID: <20081125071818.9256.qmail@stuge.se>
Date: Tue, 25 Nov 2008 08:18:18 +0100
From: Peter Stuge <peter@stuge.se>
To: Yuval Hager <yuval@avramzon.net>
Cc: Larry Finger <Larry.Finger@lwfinger.net>,
       wireless <linux-wireless@vger.kernel.org>,
       LKML <linux-kernel@vger.kernel.org>, Michael Buesch <mb@bu3sch.de>,
       bcm43xx-dev@lists.berlios.de
Subject: Re: BCM4312 Fails when xdm is started
Mail-Followup-To: Yuval Hager <yuval@avramzon.net>,
	Larry Finger <Larry.Finger@lwfinger.net>,
	wireless <linux-wireless@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>, Michael Buesch <mb@bu3sch.de>,
	bcm43xx-dev@lists.berlios.de
References: <200811151801.02369.yuval@avramzon.net> <200811241155.47079.mb@bu3sch.de> <492AD249.3020309@lwfinger.net> <200811250745.22487.yuval@avramzon.net>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="lMM8JwqTlfDpEaS6"
Content-Disposition: inline
In-Reply-To: <200811250745.22487.yuval@avramzon.net>
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


--lMM8JwqTlfDpEaS6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Yuval Hager wrote:
> I played around with different video drivers and the results are:
> * If using the 'via' driver, I lose the PCIe card immediately upon=20
>   initialization
> * Using the 'openchrome' (trunk version), It works well in the
>   beginning.
>   After first blanking the register reads are all 1's, and then
>   when the screen is blank I get a different read (some registers
>   are correct, some are wrong), and when the screen is unblanked, I
>   get 0xff's again. Very consistent and predictabe (same read every
>   time).
> * Using the 'vesa' driver I could not recreate the problem. I could
>   not get the screen to blank for some reason, but closing the lid,
>   going on standby/hibernate, restarting X - all didn't matter much
>   to the PCI and the wireless card kept on working.

Good work! You have beyond any doubt established that the X graphics
driver can cause this problem.

Were you using a kernel framebuffer driver when you saw the problem
also without running X at all? If not, the cause of trouble then is
still unidentified.


//Peter

--lMM8JwqTlfDpEaS6
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFJK6a6hR3Q0dhIfEgRAuzFAJsE2hEB28Qq7hGhlGXnB3WDr2d5cwCgkn18
VaGfWMftljqwwjuAyDc/W/c=
=Bd8Y
-----END PGP SIGNATURE-----

--lMM8JwqTlfDpEaS6--

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1753406AbYKYLGb@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753406AbYKYLGb (ORCPT <rfc822;w@1wt.eu>);
	Tue, 25 Nov 2008 06:06:31 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752668AbYKYLGV
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 25 Nov 2008 06:06:21 -0500
Received: from bu3sch.de ([62.75.166.246]:39148 "EHLO vs166246.vserver.de"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751193AbYKYLGU (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 25 Nov 2008 06:06:20 -0500
From: Michael Buesch <mb@bu3sch.de>
To: Yuval Hager <yuval@avramzon.net>
Subject: Re: BCM4312 Fails when xdm is started
Date: Tue, 25 Nov 2008 12:05:49 +0100
User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405)
Cc: Larry Finger <Larry.Finger@lwfinger.net>,
       LKML <linux-kernel@vger.kernel.org>,
       wireless <linux-wireless@vger.kernel.org>, bcm43xx-dev@lists.berlios.de
References: <200811151801.02369.yuval@avramzon.net> <492AD249.3020309@lwfinger.net> <200811250745.22487.yuval@avramzon.net>
In-Reply-To: <200811250745.22487.yuval@avramzon.net>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200811251205.49929.mb@bu3sch.de>
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tuesday 25 November 2008 06:43:22 Yuval Hager wrote:
> However, I have some few interesting findings. 
> First, this is totally unrelated to b43, but to the PCI. I get the flawed 1's 
> read from lspci even without loading b43.
> 
> I played around with different video drivers and the results are:
> * If using the 'via' driver, I lose the PCIe card immediately upon 
> initialization
> * Using the 'openchrome' (trunk version), It works well in the beginning. 
> After first blanking the register reads are all 1's, and then when the screen 
> is blank I get a different read (some registers are correct, some are wrong), 
> and when the screen is unblanked, I get 0xff's again. Very consistent and 
> predictabe (same read every time).
> * Using the 'vesa' driver I could not recreate the problem. I could not get 
> the screen to blank for some reason, but closing the lid, going on 
> standby/hibernate, restarting X - all didn't matter much to the PCI and the 
> wireless card kept on working.

Ok, then you should report the stuff to the X guys. This is not a b43 problem
and I also don't think it's a kernel problem.

-- 
Greetings Michael.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1753923AbYLGJa0@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753923AbYLGJa0 (ORCPT <rfc822;w@1wt.eu>);
	Sun, 7 Dec 2008 04:30:26 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752981AbYLGJaN
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sun, 7 Dec 2008 04:30:13 -0500
Received: from balanced.mail.policyd.dreamhost.com ([208.97.132.119]:55720
	"EHLO spunkymail-a12.g.dreamhost.com" rhost-flags-OK-OK-OK-FAIL)
	by vger.kernel.org with ESMTP id S1752443AbYLGJaL (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Sun, 7 Dec 2008 04:30:11 -0500
From: Yuval Hager <yuval@avramzon.net>
To: Peter Stuge <peter@stuge.se>
Subject: Re: BCM4312 Fails when xdm is started
Date: Sun, 7 Dec 2008 11:29:27 +0200
User-Agent: KMail/1.9.9
Cc: Larry Finger <Larry.Finger@lwfinger.net>,
       wireless <linux-wireless@vger.kernel.org>,
       LKML <linux-kernel@vger.kernel.org>, Michael Buesch <mb@bu3sch.de>,
       bcm43xx-dev@lists.berlios.de
References: <200811151801.02369.yuval@avramzon.net> <200811250745.22487.yuval@avramzon.net> <20081125071818.9256.qmail@stuge.se>
In-Reply-To: <20081125071818.9256.qmail@stuge.se>
MIME-Version: 1.0
Content-Type: multipart/signed;
  boundary="nextPart4664892.LXOuEnOpdx";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <200812071129.32113.yuval@avramzon.net>
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

--nextPart4664892.LXOuEnOpdx
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Tuesday 25 November 2008, Peter Stuge wrote:
> Yuval Hager wrote:
> > I played around with different video drivers and the results are:
> > * If using the 'via' driver, I lose the PCIe card immediately upon
> >   initialization
> > * Using the 'openchrome' (trunk version), It works well in the
> >   beginning.
> >   After first blanking the register reads are all 1's, and then
> >   when the screen is blank I get a different read (some registers
> >   are correct, some are wrong), and when the screen is unblanked, I
> >   get 0xff's again. Very consistent and predictabe (same read every
> >   time).
> > * Using the 'vesa' driver I could not recreate the problem. I could
> >   not get the screen to blank for some reason, but closing the lid,
> >   going on standby/hibernate, restarting X - all didn't matter much
> >   to the PCI and the wireless card kept on working.
>
> Good work! You have beyond any doubt established that the X graphics
> driver can cause this problem.
>

This issue has been tracked down to be at the openchrome driver. It appears=
=20
that somehow it corrupted the PCI bus, and damaged the device right after t=
he=20
video card - the wireless card.=20

The current workaround for this is here -=20
http://wiki.openchrome.org/pipermail/openchrome-devel/2008-November/000139.=
html -=20
but this is just a quick hack, not a fix, although it works great for me. T=
he=20
openchrome team is working on a patch based on this.

Thanks for all the help - I am a very happy HP2133 user, and a very happy=20
community member. This was an amazing opensource support experience, which=
=20
I'll remember for a long time. Thank you all!

Cheers,

=2D-=20
Yuval Hager
[@] yuval@avramzon.net

--nextPart4664892.LXOuEnOpdx
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEABECAAYFAkk7l3wACgkQl7qmwPqEj9/YZgCaA52S5eURCyNoRQZWKSgL4dXD
1M4AnR1Dcr/XB0c2qfLRZR0anmb9r7K4
=Y056
-----END PGP SIGNATURE-----

--nextPart4664892.LXOuEnOpdx--

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1755170AbYLGQPv@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1755170AbYLGQPv (ORCPT <rfc822;w@1wt.eu>);
	Sun, 7 Dec 2008 11:15:51 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754279AbYLGQPm
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sun, 7 Dec 2008 11:15:42 -0500
Received: from mtiwmhc12.worldnet.att.net ([204.127.131.116]:61588 "EHLO
	mtiwmhc12.worldnet.att.net" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with ESMTP id S1754206AbYLGQPl (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Sun, 7 Dec 2008 11:15:41 -0500
Message-ID: <493BF6AA.7030602@lwfinger.net>
Date: Sun, 07 Dec 2008 10:15:38 -0600
From: Larry Finger <Larry.Finger@lwfinger.net>
User-Agent: Thunderbird 2.0.0.18 (X11/20081112)
MIME-Version: 1.0
To: Yuval Hager <yuval@avramzon.net>
CC: Peter Stuge <peter@stuge.se>, wireless <linux-wireless@vger.kernel.org>,
       LKML <linux-kernel@vger.kernel.org>, Michael Buesch <mb@bu3sch.de>,
       bcm43xx-dev@lists.berlios.de
Subject: Re: BCM4312 Fails when xdm is started
References: <200811151801.02369.yuval@avramzon.net> <200811250745.22487.yuval@avramzon.net> <20081125071818.9256.qmail@stuge.se> <200812071129.32113.yuval@avramzon.net>
In-Reply-To: <200812071129.32113.yuval@avramzon.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Yuval Hager wrote:
> 
> This issue has been tracked down to be at the openchrome driver. It appears 
> that somehow it corrupted the PCI bus, and damaged the device right after the 
> video card - the wireless card. 
> 
> The current workaround for this is here - 
> http://wiki.openchrome.org/pipermail/openchrome-devel/2008-November/000139.html - 
> but this is just a quick hack, not a fix, although it works great for me. The 
> openchrome team is working on a patch based on this.
> 
> Thanks for all the help - I am a very happy HP2133 user, and a very happy 
> community member. This was an amazing opensource support experience, which 
> I'll remember for a long time. Thank you all!

Thanks for the feedback. The community may struggle a bit on some problems, and
the approach to a solution may look like a drunken sailor's walk, but we usually
get there.

Larry


