Bug 15505 - No more b43 wireless interface since 2.6.34-rc1
Summary: No more b43 wireless interface since 2.6.34-rc1
Status: CLOSED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: PCI (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_pci@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks: 15310
  Show dependency tree
 
Reported: 2010-03-10 06:59 UTC by Christian Casteyde
Modified: 2010-05-16 19:22 UTC (History)
6 users (show)

See Also:
Kernel Version: 2.6.34-rc1
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
dmesg output after boot on 34-rc1 (which fails) (31.98 KB, text/plain)
2010-03-10 18:11 UTC, Christian Casteyde
Details
lspci -v for 2.6.33 (which works) (6.44 KB, text/plain)
2010-03-10 18:13 UTC, Christian Casteyde
Details
dmesg output for 2.6.33, to compare with 34-rc1 (26.75 KB, text/plain)
2010-03-10 18:14 UTC, Christian Casteyde
Details
Bisection log (2.25 KB, text/plain)
2010-03-11 19:41 UTC, Christian Casteyde
Details

Description Christian Casteyde 2010-03-10 06:59:35 UTC
Acer Aspire 1511Lmi
Athlon 64 3000 in 64bits mode
1.2 GB RAM
Bluewhite63 13 (64bits port of Slackware)

Since 2.6.34-rc1, my wireless chip is not recognized anymore by the b43 driver. I therefore cannot scan any AP, neither use it in any way.

I append dmesg, lspci, etc.
Comment 1 John W. Linville 2010-03-10 14:07:16 UTC
Don't forget the attachments!
Comment 2 Larry Finger 2010-03-10 15:49:31 UTC
On my i386 system with a Cardbus version of the BCM4318, I built both mainline 2.6.34-rc1 and wireless-testing 2.6.343-rc1. B43 worked on both of them.

Whatever the problem, it is not generic.
Comment 3 Christian Casteyde 2010-03-10 18:11:42 UTC
Created attachment 25455 [details]
dmesg output after boot on 34-rc1 (which fails)

Sorry, I couldn't post because bugzilla was broken today.
Here is the first attachement: dmesg, the chip doesn't seem to be recognized.
Comment 4 Christian Casteyde 2010-03-10 18:13:25 UTC
Created attachment 25456 [details]
lspci -v for 2.6.33 (which works)
Comment 5 Christian Casteyde 2010-03-10 18:14:14 UTC
Created attachment 25458 [details]
dmesg output for 2.6.33, to compare with 34-rc1
Comment 6 John W. Linville 2010-03-10 18:47:21 UTC
Eeek!  The PHY versioning code looks almost unchanged (except for addition of LP- and N-phy cases) since the driver was introduced in 2007.  Perhaps some SSB (or other) code change is causing your device to not be properly initialized?

Can you do a git bisect between 2.6.33 and 2.6.34-rc1?  What is the earliest failing commit?
Comment 7 Larry Finger 2010-03-10 19:33:48 UTC
The dmesg output from 2.6.34-rc1 (Comment #3), shows "b43-phy0 ERROR: FOUND UNSUPPORTED PHY (Analog 15, Type 15, Revision 255)". This is the result obtained from a failing read of a register - all ones are returned.

I would guess the problem to be in the bus setup, rather than a problem with ssb or b43. Please do the bisection as it may not be possible to reproduce the result on another system.
Comment 8 Christian Casteyde 2010-03-11 19:40:25 UTC
Here is the bisection results:

977d17bb1749517b353874ccdc9b85abc7a58c2a is first bad commit
commit 977d17bb1749517b353874ccdc9b85abc7a58c2a
Author: Yinghai Lu <yinghai@kernel.org>
Date:   Fri Jan 22 01:02:24 2010 -0800

    PCI: update bridge resources to get more big ranges in PCI assign unssigned

    BIOS separates IO ranges between several IOHs, and on some slots, BIOS assigns
    resources to a bridge, but stops assigning resources to the device under that
    bridge, because the device needs a big resource.

    So:
      1. allocate resources and record the failed device resources
      2. clear the BIOS assigned resources of the parent bridge of failing device
      3. go back and call pci assign unassigned
      4. if it still fails, go up the tree, clear more bridges. and try again

    Signed-off-by: Yinghai Lu <yinghai@kernel.org>
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>

:040000 040000 539c8e7c3f8603f8d12db226db01c4a58e554976 d3498fc9a544d49aa18cd4f6c62073a11f38211f M drivers

I append the bisect log.
Comment 9 Christian Casteyde 2010-03-11 19:41:21 UTC
Created attachment 25478 [details]
Bisection log
Comment 10 Larry Finger 2010-03-11 21:09:23 UTC
This result from bisection is pretty much what I expected. I have added the bad patch committer (yinghai@kernel.org) and the appropriate maintainer (jbarnes@virtuousgeek.org) to the Cc list. I'm certain that they will be in contact with test patches.
Comment 11 Yinghai Lu 2010-03-11 21:50:32 UTC
On 03/11/2010 01:09 PM, bugzilla-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=15505
> 

please try:

[PATCH] pci: disable pci trying to reallocate pci bridge by default.

it broken Linus's Nouveau

bisected:to commit 977d17bb17
| PCI: update bridge resources to get more big ranges in PCI assign unssigned

so try disable it by default.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 Documentation/kernel-parameters.txt |    6 ++++++
 drivers/pci/pci.c                   |    4 ++++
 drivers/pci/pci.h                   |    2 ++
 drivers/pci/setup-bus.c             |   14 +++++++++-----
 4 files changed, 21 insertions(+), 5 deletions(-)

Index: linux-2.6/Documentation/kernel-parameters.txt
===================================================================
--- linux-2.6.orig/Documentation/kernel-parameters.txt
+++ linux-2.6/Documentation/kernel-parameters.txt
@@ -1979,6 +1979,12 @@ and is between 256 and 4096 characters.
 				for broken drivers that don't call it.
 		skip_isa_align	[X86] do not align io start addr, so can
 				handle more pci cards
+		try=n		set the pci_try_num to reallocate the pci bridge resource
+				1: default
+				2: will set the num to max_depth, and try to reallocate res
+				   to get big range for the bridge. assume the pci peer root
+				   resource is right from _CRS or from hostbridge pci reg
+				   reading out.
 		firmware	[ARM] Do not re-enumerate the bus but instead
 				just use the configuration from the
 				bootloader. This is currently used on
Index: linux-2.6/drivers/pci/pci.c
===================================================================
--- linux-2.6.orig/drivers/pci/pci.c
+++ linux-2.6/drivers/pci/pci.c
@@ -3017,6 +3017,10 @@ static int __init pci_setup(char *str)
 				pci_no_aer();
 			} else if (!strcmp(str, "nodomains")) {
 				pci_no_domains();
+			} else if (!strncmp(str, "try=", 4)) {
+				int try_num = memparse(str + 4, &str);
+				if (try_num > 0)
+					pci_try_num = try_num;
 			} else if (!strncmp(str, "cbiosize=", 9)) {
 				pci_cardbus_io_size = memparse(str + 9, &str);
 			} else if (!strncmp(str, "cbmemsize=", 10)) {
Index: linux-2.6/drivers/pci/pci.h
===================================================================
--- linux-2.6.orig/drivers/pci/pci.h
+++ linux-2.6/drivers/pci/pci.h
@@ -212,6 +212,8 @@ static inline int pci_ari_enabled(struct
 	return bus->self && bus->self->ari_enabled;
 }
 
+extern int pci_try_num;
+
 #ifdef CONFIG_PCI_QUIRKS
 extern int pci_is_reassigndev(struct pci_dev *dev);
 resource_size_t pci_specified_resource_alignment(struct pci_dev *dev);
Index: linux-2.6/drivers/pci/setup-bus.c
===================================================================
--- linux-2.6.orig/drivers/pci/setup-bus.c
+++ linux-2.6/drivers/pci/setup-bus.c
@@ -926,6 +926,7 @@ static int __init pci_get_max_depth(void
  * second  and later try will clear small leaf bridge res
  * will stop till to the max  deepth if can not find good one
  */
+int pci_try_num = 1;
 void __init
 pci_assign_unassigned_resources(void)
 {
@@ -936,14 +937,17 @@ pci_assign_unassigned_resources(void)
 	unsigned long type_mask = IORESOURCE_IO | IORESOURCE_MEM |
 				  IORESOURCE_PREFETCH;
 	unsigned long failed_type;
-	int max_depth = pci_get_max_depth();
-	int pci_try_num;
 
 	head.next = NULL;
 
-	pci_try_num = max_depth + 1;
-	printk(KERN_DEBUG "PCI: max bus depth: %d pci_try_num: %d\n",
-		 max_depth, pci_try_num);
+	if (pci_try_num > 1) {
+		int max_depth = pci_get_max_depth();
+
+		if (max_depth + 1 > pci_try_num)
+			pci_try_num = max_depth + 1;
+		printk(KERN_DEBUG "PCI: max bus depth: %d pci_try_num: %d\n",
+			 max_depth, pci_try_num);
+	}
 
 again:
 	/* Depth first, calculate sizes and alignments of all
Comment 12 Christian Casteyde 2010-03-12 12:28:42 UTC
This patch fixes the bug, I got the wireless interface and could connect to my AP with it.
Thanks !
Comment 13 Rafael J. Wysocki 2010-03-19 19:15:20 UTC
Handled-By : Yinghai Lu <yinghai@kernel.org>
Patch : https://bugzilla.kernel.org/show_bug.cgi?id=15505#c11
Comment 14 Christian Casteyde 2010-03-22 18:33:20 UTC
Update : Still present in 2.6.34-rc2
Comment 15 Christian Casteyde 2010-03-31 20:36:22 UTC
Update: Still present in 2.6.34-rc3
Comment 16 Christian Casteyde 2010-04-13 22:00:17 UTC
  
Update: Still present in 2.6.34-rc4
Comment 17 Rafael J. Wysocki 2010-04-20 18:46:55 UTC
On Tuesday 20 April 2010, Christian Casteyde wrote:
> Yes, this bug is still present with 2.6.34-rc5.
> 
> Bonjour,
> Le mardi 20 avril 2010, vous avez écrit :
> > This message has been generated automatically as a part of a summary report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.33.  Please verify if it still should be listed and let the
> > tracking team know (either way).
> >
> >
> > Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=15505
> > Subject             : No more b43 wireless interface since 2.6.34-rc1
> > Submitter   : Christian Casteyde <casteyde.christian@free.fr>
> > Date                : 2010-03-10 06:59 (41 days old)
> > Handled-By  : Yinghai Lu <yinghai@kernel.org>
> > Patch               : https://bugzilla.kernel.org/show_bug.cgi?id=15505#c11
Comment 18 Christian Casteyde 2010-04-30 07:56:53 UTC
Update: Still present in 2.6.34-rc6
Comment 19 Jesse Barnes 2010-05-14 22:36:13 UTC
Should be fixed in Linus's tree now.
Comment 20 Christian Casteyde 2010-05-16 10:26:01 UTC
Fixed with 2.6.34-rc7-git9

Note You need to log in before you can comment on or make changes to this bug.