[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#463498: marked as done (b43: master mode doesn't work)

Your message dated Sun, 4 Jan 2009 22:04:05 +0100
with message-id <20090104210405.GB3701@galadriel.inutil.org>
and subject line Re: b43: Selects wrong driver?
has caused the Debian Bug report #463498,
regarding b43: master mode doesn't work
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
463498: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=463498
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: linux-2.6
Version: 2.6.24-1

Hi,

It seems that the kernel does not select the proper driver for me.  When
booting a 2.6.22 (and .23) kernel, I see:
bcm43xx driver
PCI: Enabling device 0000:02:00.0 (0000 -> 0002)
ACPI: PCI Interrupt 0000:02:00.0[A] -> Link [LNKA] -> GSI 10 (level,
low) -> IRQ 10
PCI: Setting latency timer of device 0000:02:00.0 to 64
bcm43xx: Chip ID 0x4306, rev 0x3
bcm43xx: Number of cores: 5
bcm43xx: Core 0: ID 0x800, rev 0x4, vendor 0x4243
bcm43xx: Core 1: ID 0x812, rev 0x5, vendor 0x4243
bcm43xx: Core 2: ID 0x80d, rev 0x2, vendor 0x4243
bcm43xx: Core 3: ID 0x807, rev 0x2, vendor 0x4243
bcm43xx: Core 4: ID 0x804, rev 0x9, vendor 0x4243
bcm43xx: PHY connected
bcm43xx: Detected PHY: Analog: 2, Type 2, Revision 2
bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2)
bcm43xx: Radio turned off
bcm43xx: Radio turned off
udev: renamed network interface eth1 to eth3
cs: IO port probe 0x100-0x4ff: excluding 0x4d0-0x4d7
cs: IO port probe 0x800-0x8ff: clean.
cs: IO port probe 0xc00-0xcff: clean.
cs: IO port probe 0xa00-0xaff: clean.
Adding 771080k swap on /dev/hda5.  Priority:-1 extents:1 across:771080k


b43-phy0: Broadcom 4306 WLAN found
phy0: Selected rate control algorithm 'simple'
udev: renamed network interface wmaster0 to eth3
Adding 771080k swap on /dev/hda5.  Priority:-1 extents:1 across:771080k
EXT3 FS on hda1, internal journal
Driver 'sr' needs updating - please
use bus_type methods
device-mapper: uevent: version 1.0.3
device-mapper: ioctl: 4.12.0-ioctl
(2007-10-02) initialised: dm-devel@redhat.com
input: b43-phy0 as /class/input/input8
Registered led device: b43-phy0:tx
Registered led device: b43-phy0:rx
Registered led device: b43-phy0:radio

But this b43 driver doesn't seem to be working for me.  I notice some
strange behaviours with this:
- After the "udev: renamed network interface wmaster0 to eth3" it hangs
  for several seconds before doing something else.  At that point
  something prints "done" on the screen which doesn't come from the
  kernel.  (Manual modprobing b43 doesn't seem to cause this problem.)
- When looking at the interface list I see a "eth3" that doesn't
  have wireless extentions, and a wlan0_rename that does.  I
  also have 1 more device than I should.

Reading http://linuxwireless.org/en/users/Drivers/b43 it says:
"4306 and 4309 cards with a MAC core revision of 4 or less should
also use b43legacy. [...] The kernel autoloader will automatically do
the right thing and load the correct driver for your device."

If I read the dmesg above right I have a 4306 with MAC core revision 3,
so I should use b43legacy.  It seems to me that it's not doing the right
thing here.

So I've tried rmmod b43 and modprobe b43legacy but that doesn't seem to
be doing much.


Kurt

--- End Message ---
--- Begin Message --- 
On Sun, Jan 04, 2009 at 06:35:01PM +0100, Kurt Roeckx wrote:
> On Sun, Jan 04, 2009 at 06:20:46PM +0100, Moritz Muehlenhoff wrote:
> > 
> > Is the kernel issue of detecting your card with the proper driver resolved
> > in the Lenny kernel? (Leaving the udev rename issue referenced later aside)
> 
> As far as I know, it was only the udev issue and never a kernel
> issue for me.  Atleast, with the proper udev rules I have no
> problem anymore.  But you could probably argue that the kernel
> shouldn't get into a wrong state because you did something on
> the wrong devicename.

Thanks, closing the bug then.

Cheers,
        Moritz

--- End Message ---
Reply to: