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.
Don't forget the attachments!
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.
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.
Created attachment 25456 [details] lspci -v for 2.6.33 (which works)
Created attachment 25458 [details] dmesg output for 2.6.33, to compare with 34-rc1
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?
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.
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.
Created attachment 25478 [details] Bisection log
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.
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
This patch fixes the bug, I got the wireless interface and could connect to my AP with it. Thanks !
Handled-By : Yinghai Lu <yinghai@kernel.org> Patch : https://bugzilla.kernel.org/show_bug.cgi?id=15505#c11
Update : Still present in 2.6.34-rc2
Update: Still present in 2.6.34-rc3
Update: Still present in 2.6.34-rc4
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
Update: Still present in 2.6.34-rc6
Should be fixed in Linus's tree now.
Fixed with 2.6.34-rc7-git9