Signed-Off-By: Daniel Walker <[email protected]>
---
drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c | 30 ++++++++++++-------------
1 file changed, 15 insertions(+), 15 deletions(-)
Index: linux-2.6.23/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c
===================================================================
--- linux-2.6.23.orig/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c
+++ linux-2.6.23/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c
@@ -43,7 +43,7 @@
static struct bcm43xx_debugfs fs;
static char really_big_buffer[REALLY_BIG_BUFFER_SIZE];
-static DECLARE_MUTEX(big_buffer_sem);
+static DEFINE_MUTEX(big_buffer_mutex);
static ssize_t write_file_dummy(struct file *file, const char __user *buf,
@@ -75,7 +75,7 @@ static ssize_t devinfo_read_file(struct
u16 tmp16;
int i;
- down(&big_buffer_sem);
+ mutex_lock(&big_buffer_mutex);
mutex_lock(&bcm->mutex);
spin_lock_irqsave(&bcm->irq_lock, flags);
@@ -125,7 +125,7 @@ out:
spin_unlock_irqrestore(&bcm->irq_lock, flags);
mutex_unlock(&bcm->mutex);
res = simple_read_from_buffer(userbuf, count, ppos, buf, pos);
- up(&big_buffer_sem);
+ mutex_unlock(&big_buffer_mutex);
return res;
}
@@ -138,14 +138,14 @@ static ssize_t drvinfo_read_file(struct
size_t pos = 0;
ssize_t res;
- down(&big_buffer_sem);
+ mutex_lock(&big_buffer_mutex);
/* This is where the information is written to the "driver" file */
fappend(KBUILD_MODNAME " driver\n");
fappend("Compiled at: %s %s\n", __DATE__, __TIME__);
res = simple_read_from_buffer(userbuf, count, ppos, buf, pos);
- up(&big_buffer_sem);
+ mutex_unlock(&big_buffer_mutex);
return res;
}
@@ -160,7 +160,7 @@ static ssize_t spromdump_read_file(struc
ssize_t res;
unsigned long flags;
- down(&big_buffer_sem);
+ mutex_lock(&big_buffer_mutex);
mutex_lock(&bcm->mutex);
spin_lock_irqsave(&bcm->irq_lock, flags);
if (bcm43xx_status(bcm) != BCM43xx_STAT_INITIALIZED) {
@@ -175,7 +175,7 @@ out:
spin_unlock_irqrestore(&bcm->irq_lock, flags);
mutex_unlock(&bcm->mutex);
res = simple_read_from_buffer(userbuf, count, ppos, buf, pos);
- up(&big_buffer_sem);
+ mutex_unlock(&big_buffer_mutex);
return res;
}
@@ -191,7 +191,7 @@ static ssize_t tsf_read_file(struct file
unsigned long flags;
u64 tsf;
- down(&big_buffer_sem);
+ mutex_lock(&big_buffer_mutex);
mutex_lock(&bcm->mutex);
spin_lock_irqsave(&bcm->irq_lock, flags);
if (bcm43xx_status(bcm) != BCM43xx_STAT_INITIALIZED) {
@@ -207,7 +207,7 @@ out:
spin_unlock_irqrestore(&bcm->irq_lock, flags);
mutex_unlock(&bcm->mutex);
res = simple_read_from_buffer(userbuf, count, ppos, buf, pos);
- up(&big_buffer_sem);
+ mutex_unlock(&big_buffer_mutex);
return res;
}
@@ -222,7 +222,7 @@ static ssize_t tsf_write_file(struct fil
unsigned long long tsf;
buf_size = min(count, sizeof (really_big_buffer) - 1);
- down(&big_buffer_sem);
+ mutex_lock(&big_buffer_mutex);
if (copy_from_user(buf, user_buf, buf_size)) {
res = -EFAULT;
goto out_up;
@@ -247,7 +247,7 @@ out_unlock:
spin_unlock_irqrestore(&bcm->irq_lock, flags);
mutex_unlock(&bcm->mutex);
out_up:
- up(&big_buffer_sem);
+ mutex_unlock(&big_buffer_mutex);
return res;
}
@@ -265,7 +265,7 @@ static ssize_t txstat_read_file(struct f
struct bcm43xx_xmitstatus *status;
int i, cnt, j = 0;
- down(&big_buffer_sem);
+ mutex_lock(&big_buffer_mutex);
mutex_lock(&bcm->mutex);
spin_lock_irqsave(&bcm->irq_lock, flags);
@@ -312,7 +312,7 @@ static ssize_t txstat_read_file(struct f
}
spin_unlock_irqrestore(&bcm->irq_lock, flags);
mutex_unlock(&bcm->mutex);
- up(&big_buffer_sem);
+ mutex_unlock(&big_buffer_mutex);
return res;
}
@@ -326,7 +326,7 @@ static ssize_t restart_write_file(struct
unsigned long flags;
buf_size = min(count, sizeof (really_big_buffer) - 1);
- down(&big_buffer_sem);
+ mutex_lock(&big_buffer_mutex);
if (copy_from_user(buf, user_buf, buf_size)) {
res = -EFAULT;
goto out_up;
@@ -348,7 +348,7 @@ out_unlock:
spin_unlock_irqrestore(&(bcm)->irq_lock, flags);
mutex_unlock(&(bcm)->mutex);
out_up:
- up(&big_buffer_sem);
+ mutex_unlock(&big_buffer_mutex);
return res;
}
--
On Wednesday 12 December 2007 09:00:03 Daniel Walker wrote:
>
> Signed-Off-By: Daniel Walker <[email protected]>
>
> ---
> drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c | 30 ++++++++++++-------------
> 1 file changed, 15 insertions(+), 15 deletions(-)
>
> Index: linux-2.6.23/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c
> ===================================================================
> --- linux-2.6.23.orig/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c
> +++ linux-2.6.23/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c
> @@ -43,7 +43,7 @@
>
> static struct bcm43xx_debugfs fs;
> static char really_big_buffer[REALLY_BIG_BUFFER_SIZE];
> -static DECLARE_MUTEX(big_buffer_sem);
> +static DEFINE_MUTEX(big_buffer_mutex);
This driver is scheduled for removal, so I'd not touch it anymore
to avoid the possibility to introduce a lastminute regression.
The new drivers (b43 and b43legacy) have this fixed (in a different
way by completely removing it).
--
Greetings Michael.
On Dec 12, 2007 4:48 PM, Michael Buesch <[email protected]> wrote:
> This driver is scheduled for removal, so I'd not touch it anymore
> to avoid the possibility to introduce a lastminute regression.
> The new drivers (b43 and b43legacy) have this fixed (in a different
> way by completely removing it).
Uhm, hijacking the thread a bit here, but which driver is supposed to
be supporting my 4309? Neither b43 nor b43legacy found my wireless,
and I'm not seeing its PCI ID anywhere either of those...
$ lspci -s 02:02 -v; lspci -n -s 02:02 -v -x
02:02.0 Network controller: Broadcom Corporation BCM4309 802.11a/b/g (rev 03)
Subsystem: Hewlett-Packard Company Unknown device 12f9
Flags: bus master, fast devsel, latency 64, IRQ 22
Memory at d0010000 (32-bit, non-prefetchable) [size=8K]
02:02.0 0280: 14e4:4324 (rev 03)
Subsystem: 103c:12f9
Flags: bus master, fast devsel, latency 64, IRQ 22
Memory at d0010000 (32-bit, non-prefetchable) [size=8K]
00: e4 14 24 43 06 00 00 00 03 00 80 02 00 40 00 00
10: 00 00 01 d0 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 f9 12
30: 00 00 00 00 00 00 00 00 00 00 00 00 05 01 00 00
On Thu, 2007-12-13 at 01:48 +0100, Michael Buesch wrote:
> On Wednesday 12 December 2007 09:00:03 Daniel Walker wrote:
> >
> > Signed-Off-By: Daniel Walker <[email protected]>
> >
> > ---
> > drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c | 30 ++++++++++++-------------
> > 1 file changed, 15 insertions(+), 15 deletions(-)
> >
> > Index: linux-2.6.23/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c
> > ===================================================================
> > --- linux-2.6.23.orig/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c
> > +++ linux-2.6.23/drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c
> > @@ -43,7 +43,7 @@
> >
> > static struct bcm43xx_debugfs fs;
> > static char really_big_buffer[REALLY_BIG_BUFFER_SIZE];
> > -static DECLARE_MUTEX(big_buffer_sem);
> > +static DEFINE_MUTEX(big_buffer_mutex);
>
> This driver is scheduled for removal, so I'd not touch it anymore
> to avoid the possibility to introduce a lastminute regression.
> The new drivers (b43 and b43legacy) have this fixed (in a different
> way by completely removing it).
When is the removal scheduled?
Daniel
* Daniel Walker <[email protected]> wrote:
> > This driver is scheduled for removal, so I'd not touch it anymore to
> > avoid the possibility to introduce a lastminute regression. The new
> > drivers (b43 and b43legacy) have this fixed (in a different way by
> > completely removing it).
>
> When is the removal scheduled?
$ grep -i bcm Documentation/feature-removal-schedule.txt
$
might make sense to update this file.
Ingo
On Thursday 13 December 2007 11:13:27 Ingo Molnar wrote:
>
> * Daniel Walker <[email protected]> wrote:
>
> > > This driver is scheduled for removal, so I'd not touch it anymore to
> > > avoid the possibility to introduce a lastminute regression. The new
> > > drivers (b43 and b43legacy) have this fixed (in a different way by
> > > completely removing it).
> >
> > When is the removal scheduled?
>
> $ grep -i bcm Documentation/feature-removal-schedule.txt
> $
>
> might make sense to update this file.
Patches are on their way.
I think it's scheduled to be removed after 2.6.25 was released.
--
Greetings Michael.
On Thursday 13 December 2007 02:17:16 Ray Lee wrote:
> On Dec 12, 2007 4:48 PM, Michael Buesch <[email protected]> wrote:
> > This driver is scheduled for removal, so I'd not touch it anymore
> > to avoid the possibility to introduce a lastminute regression.
> > The new drivers (b43 and b43legacy) have this fixed (in a different
> > way by completely removing it).
>
> Uhm, hijacking the thread a bit here, but which driver is supposed to
> be supporting my 4309? Neither b43 nor b43legacy found my wireless,
> and I'm not seeing its PCI ID anywhere either of those...
>
> $ lspci -s 02:02 -v; lspci -n -s 02:02 -v -x
> 02:02.0 Network controller: Broadcom Corporation BCM4309 802.11a/b/g (rev 03)
> Subsystem: Hewlett-Packard Company Unknown device 12f9
> Flags: bus master, fast devsel, latency 64, IRQ 22
> Memory at d0010000 (32-bit, non-prefetchable) [size=8K]
>
> 02:02.0 0280: 14e4:4324 (rev 03)
The device is supported by b43.
The PCI ID is in the SSB PCI bridge code
static const struct pci_device_id b43_pci_bridge_tbl[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4301) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4307) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4311) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4312) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4318) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4319) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4320) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4321) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4324) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4325) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4328) },
{ 0, },
};
MODULE_DEVICE_TABLE(pci, b43_pci_bridge_tbl);
--
Greetings Michael.
On Thu, Dec 13, 2007 at 12:11:32PM +0100, Michael Buesch wrote:
> On Thursday 13 December 2007 11:13:27 Ingo Molnar wrote:
> >
> > * Daniel Walker <[email protected]> wrote:
> >
> > > > This driver is scheduled for removal, so I'd not touch it anymore to
> > > > avoid the possibility to introduce a lastminute regression. The new
> > > > drivers (b43 and b43legacy) have this fixed (in a different way by
> > > > completely removing it).
> > >
> > > When is the removal scheduled?
> >
> > $ grep -i bcm Documentation/feature-removal-schedule.txt
> > $
> >
> > might make sense to update this file.
>
> Patches are on their way.
> I think it's scheduled to be removed after 2.6.25 was released.
A patch w/ subject "bcm43xx: mark as obsolete and schedule for removal"
is queued in net-2.6.25 and waiting for the 2.6.25 merge window.
It includes this hunk:
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -333,3 +333,12 @@ Why: This driver has been marked obsolete for many years.
Who: Stephen Hemminger <[email protected]>
---------------------------
+
+What: bcm43xx wireless network driver
+When: 2.6.26
+Files: drivers/net/wireless/bcm43xx
+Why: This driver's functionality has been replaced by the
+ mac80211-based b43 and b43legacy drivers.
+Who: John W. Linville <[email protected]>
+
+---------------------------
Hth!
John
--
John W. Linville
[email protected]
On Dec 13, 2007 5:45 AM, Michael Buesch <[email protected]> wrote:
> On Thursday 13 December 2007 02:17:16 Ray Lee wrote:
> > Uhm, hijacking the thread a bit here, but which driver is supposed to
> > be supporting my 4309? Neither b43 nor b43legacy found my wireless,
> > and I'm not seeing its PCI ID anywhere either of those...
> >
> > 02:02.0 0280: 14e4:4324 (rev 03)
>
> The device is supported by b43.
> The PCI ID is in the SSB PCI bridge code
>
> static const struct pci_device_id b43_pci_bridge_tbl[] = {
...
> { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4324) },
Ah, thanks, so it is. Well, doing an `rmmod bcm43xx ; modprobe ssb
b43` gives me nothing in dmesg other than lines related to the bcm43xx
driver. iwconfig/ifconfig do not see the interface either.
<goes and reads bcm43xx-dev archives>
Okay, I had to modprobe rfkill-input and rfkill by hand, didn't
realize that. Hopefully that'll be automatic soon. Regardless, upon
doing so, and loading ssb and b43, it sees my card, but is still not
fully functional. iwconfig sees:
lo no wireless extensions.
eth0 no wireless extensions.
tun0 no wireless extensions.
eth1 no wireless extensions.
wlan0_rename IEEE 802.11g ESSID:""
Mode:Managed Channel:0 Access Point: Not-Associated
Tx-Power=0 dBm
Retry min limit:7 RTS thr:off Fragment thr=2346 B
Link Quality:0 Signal level:0 Noise level:0
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
(eth0 is ethernet, eth1 doesn't exist -- usually it's the wireless.)
`ifconfig` doesn't see eth1 or wlan0_rename.
What else might I be doing wrong? Regardless, perhaps scheduling
bcm43xx for removal in 2.6.26 is a bit premature.
On Friday 14 December 2007 01:05:00 Ray Lee wrote:
> Okay, I had to modprobe rfkill-input and rfkill by hand, didn't
> realize that. Hopefully that'll be automatic soon. Regardless, upon
> doing so, and loading ssb and b43, it sees my card, but is still not
> fully functional. iwconfig sees:
>
> lo no wireless extensions.
> eth0 no wireless extensions.
> tun0 no wireless extensions.
> eth1 no wireless extensions.
> wlan0_rename IEEE 802.11g ESSID:""
> Mode:Managed Channel:0 Access Point: Not-Associated
> Tx-Power=0 dBm
> Retry min limit:7 RTS thr:off Fragment thr=2346 B
> Link Quality:0 Signal level:0 Noise level:0
> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
> Tx excessive retries:0 Invalid misc:0 Missed beacon:0
>
> (eth0 is ethernet, eth1 doesn't exist -- usually it's the wireless.)
>
> `ifconfig` doesn't see eth1 or wlan0_rename.
>
> What else might I be doing wrong?
I don't know. Try ifconfig -a
Or tell udev to not crap up your device names.
> Regardless, perhaps scheduling
> bcm43xx for removal in 2.6.26 is a bit premature.
Oh come on. b43 is more than a year old now. How long should we wait?
Two or three? Forever?
--
Greetings Michael.
On Fri, 2007-12-14 at 01:43 +0100, Michael Buesch wrote:
> Oh come on. b43 is more than a year old now. How long should we wait?
> Two or three? Forever?
>
Any pointers to the advantages of b43?
Harvey
On Dec 13, 2007 4:43 PM, Michael Buesch <[email protected]> wrote:
> On Friday 14 December 2007 01:05:00 Ray Lee wrote:
> > Okay, I had to modprobe rfkill-input and rfkill by hand, didn't
> > realize that. Hopefully that'll be automatic soon. Regardless, upon
> > doing so, and loading ssb and b43, it sees my card, but is still not
> > fully functional. iwconfig sees:
> >
> > lo no wireless extensions.
> > eth0 no wireless extensions.
> > tun0 no wireless extensions.
> > eth1 no wireless extensions.
> > wlan0_rename IEEE 802.11g ESSID:""
> > Mode:Managed Channel:0 Access Point: Not-Associated
> > Tx-Power=0 dBm
> > Retry min limit:7 RTS thr:off Fragment thr=2346 B
> > Link Quality:0 Signal level:0 Noise level:0
> > Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
> > Tx excessive retries:0 Invalid misc:0 Missed beacon:0
> >
> > (eth0 is ethernet, eth1 doesn't exist -- usually it's the wireless.)
> >
> > `ifconfig` doesn't see eth1 or wlan0_rename.
> >
> > What else might I be doing wrong?
>
> I don't know. Try ifconfig -a
> Or tell udev to not crap up your device names.
Uhm, I haven't had to tell udev to not crap up any of my *other*
devices, why is b43 special? I'm using an up-to-date userspace, so I'm
not going to be the only one hitting this problem. And ifconfig -a
does indeed show it, sorry about that. But my understanding is that
udev renames interfaces based on MAC address, so I wouldn't suspect
udev to be at fault here.
Digging a little farther into it, it looks like b43 is barfing partway
through init as the firmware file it's looking for has changed names.
Perhaps that's the issue. I'll take a longer look at this all
tomorrow.
> > Regardless, perhaps scheduling
> > bcm43xx for removal in 2.6.26 is a bit premature.
>
> Oh come on. b43 is more than a year old now. How long should we wait?
> Two or three? Forever?
Well, it only hit the main kernel October 10th. That means no final
point release of the kernel.org kernel has even had it included! So
testing-wise, you still haven't hit the hordes yet. Scheduling a
removal of bcm43xx (as painful as that code is [*]), seems either
premature or very optimistic. So, how about scheduling the removal
once you get a feel for the bug reports that'll come in once 2.6.24 is
released.
[*] Yeah, even as a user the code is painful. It *still* locks my
keyboard if I happen to disable the wireless while it's scanning. The
sooner bcm43xx is dead, the better. But b43 is quite obviously not a
full replacement for everyone.
I don't mean to come off harsh, I know you put an amazing amount of
work into both b43 and bcm43xx, and I'm thankful for that. But
requiring the end-user to go scan bcm43xx-dev archives to find out
that the b43 module isn't correctly autoloading all of its
dependencies is a sign that the code still hasn't had a lot of
testing, no?
In the meantime I'll keep plugging away at trying to figure out what's wrong.
Ray
Michael Buesch wrote:
> On Friday 14 December 2007 01:05:00 Ray Lee wrote:
>> Okay, I had to modprobe rfkill-input and rfkill by hand, didn't
>> realize that. Hopefully that'll be automatic soon. Regardless, upon
>> doing so, and loading ssb and b43, it sees my card, but is still not
>> fully functional. iwconfig sees:
>>
>> lo no wireless extensions.
>> eth0 no wireless extensions.
>> tun0 no wireless extensions.
>> eth1 no wireless extensions.
>> wlan0_rename IEEE 802.11g ESSID:""
>> Mode:Managed Channel:0 Access Point: Not-Associated
>> Tx-Power=0 dBm
>> Retry min limit:7 RTS thr:off Fragment thr=2346 B
>> Link Quality:0 Signal level:0 Noise level:0
>> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
>> Tx excessive retries:0 Invalid misc:0 Missed beacon:0
>>
>> (eth0 is ethernet, eth1 doesn't exist -- usually it's the wireless.)
>>
>> `ifconfig` doesn't see eth1 or wlan0_rename.
>>
>> What else might I be doing wrong?
Your udev rules are screwed up. In /etc/udev/rules.d/70-persistent-net.rules, you should have a line
that looks like
SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:1a:73:6b:28:5a", ATTR{type}=="1", NAME="eth1"
with the MAC address for your device. You probably have the ATTR{type}=="1" clause missing.
Larry
On Friday 14 December 2007 01:55:50 Harvey Harrison wrote:
> On Fri, 2007-12-14 at 01:43 +0100, Michael Buesch wrote:
> > Oh come on. b43 is more than a year old now. How long should we wait?
> > Two or three? Forever?
> >
>
> Any pointers to the advantages of b43?
http://www.linuxwireless.org/en/users/Drivers/b43
--
Greetings Michael.
On Friday 14 December 2007 02:12:25 Ray Lee wrote:
> Digging a little farther into it, it looks like b43 is barfing partway
> through init as the firmware file it's looking for has changed names.
> Perhaps that's the issue. I'll take a longer look at this all
> tomorrow.
http://www.linuxwireless.org/en/users/Drivers/b43#firmwareinstallation
> Well, it only hit the main kernel October 10th. That means no final
> point release of the kernel.org kernel has even had it included! So
> testing-wise, you still haven't hit the hordes yet. Scheduling a
> removal of bcm43xx (as painful as that code is [*]), seems either
> premature or very optimistic. So, how about scheduling the removal
> once you get a feel for the bug reports that'll come in once 2.6.24 is
> released.
So you volunteer to maintain bcm43xx? Fine. Thanks a lot.
> [*] Yeah, even as a user the code is painful. It *still* locks my
> keyboard if I happen to disable the wireless while it's scanning. The
> sooner bcm43xx is dead, the better. But b43 is quite obviously not a
> full replacement for everyone.
I'm pretty sure it is.
Please carefully read the instructions on
http://www.linuxwireless.org/en/users/Drivers/b43
especially for firmware installation.
It will work very well.
--
Greetings Michael.
* Michael Buesch <[email protected]> wrote:
> > (eth0 is ethernet, eth1 doesn't exist -- usually it's the wireless.)
> >
> > `ifconfig` doesn't see eth1 or wlan0_rename.
> >
> > What else might I be doing wrong?
>
> I don't know. Try ifconfig -a Or tell udev to not crap up your device
> names.
>
> > Regardless, perhaps scheduling bcm43xx for removal in 2.6.26 is a
> > bit premature.
>
> Oh come on. b43 is more than a year old now. How long should we wait?
> Two or three? Forever?
possibly forever, if you dont get obvious regressions like "my wlan does
not work" (reported in this very thread), resolved. Pushing the blame to
udev (in a rather unfriendly way) wont give users a working system and
wont get you many new testers for the new driver either.
Ingo
* Michael Buesch <[email protected]> wrote:
> On Friday 14 December 2007 02:12:25 Ray Lee wrote:
> > Digging a little farther into it, it looks like b43 is barfing partway
> > through init as the firmware file it's looking for has changed names.
> > Perhaps that's the issue. I'll take a longer look at this all
> > tomorrow.
>
> http://www.linuxwireless.org/en/users/Drivers/b43#firmwareinstallation
>
> > Well, it only hit the main kernel October 10th. That means no final
> > point release of the kernel.org kernel has even had it included! So
> > testing-wise, you still haven't hit the hordes yet. Scheduling a
> > removal of bcm43xx (as painful as that code is [*]), seems either
> > premature or very optimistic. So, how about scheduling the removal
> > once you get a feel for the bug reports that'll come in once 2.6.24 is
> > released.
>
> So you volunteer to maintain bcm43xx? Fine. Thanks a lot.
it's sad that you are trying to force testers to upgrade to your new
driver by threatening to unsupport the old driver. The testers who did
nothing but reported that the new driver did not work on their hardware.
You can write new drivers but you must not break existing users. That's
true for every single piece of the kernel. It is _your_ responsibility
to get that rule right - and if it does not work out of box (no matter
whom to blame, udev or the driver) you dont get to remove the driver
from the upstream kernel.
Yes, you can then "unsupport it" in spite and be a prick about it in
general but that will only talk of your own personal qualities and will
sharply reduce your credibility as a maintainer (and eventually hinder
your ability to introduce new code) - users will still have the code
available and will have a chance to fix the driver that happens to work.
(and perhaps another, capable, but friendler maintainer arises.) And
that old code will be a clot to drag around, hindering your 'new'
wireless code all along.
I really dont know why it's so hard to understand: new is totally
useless if it does not work for old setups 100% of the time. And people
_WANT_ to use your new code, so it's not like you have to pull their
hairs to get your stuff tested. And YOU wrote the old code in large
part:
$ git-authors drivers/net/wireless/bcm43xx/ | tail -10
2 Sam Ravnborg
3 David Howells
3 David Woodhouse
3 Joe Perches
4 Jeff Garzik
5 Daniel Drake
6 Stefano Brivio
9 John W. Linville
48 Larry Finger
80 Michael Buesch
so it's not like "someone else messed it up" and that you would be
incapable of getting it all work nicely and make the migration of users
smoother. And if udev is a hindrance to you, reduce your driver's
dependence on udev breakages.
Ingo
On Friday 14 December 2007 12:15:34 Ingo Molnar wrote:
> > So you volunteer to maintain bcm43xx? Fine. Thanks a lot.
>
> it's sad that you are trying to force testers to upgrade to your new
> driver by threatening to unsupport the old driver.
I dropped maintainance for bcm43xx over a year ago.
So I am not going to catch it up again. b43 works fine.
I don't see a reason to support bcm43xx anymore.
Currently bcm43xx is orphaned, as Larry couldn't support it
anymore due to other issues.
> The testers who did
> nothing but reported that the new driver did not work on their hardware.
Which testers?
Ray Lee didn't even install the firmware. So it can't work by definition.
That is not my fault.
> You can write new drivers but you must not break existing users. That's
> true for every single piece of the kernel. It is _your_ responsibility
> to get that rule right - and if it does not work out of box (no matter
> whom to blame, udev or the driver) you dont get to remove the driver
> from the upstream kernel.
Ok. So we have to live with an orphaned driver. I am fine with that, too.
> Yes, you can then "unsupport it" in spite and be a prick about it in
> general but that will only talk of your own personal qualities and will
> sharply reduce your credibility as a maintainer (and eventually hinder
> your ability to introduce new code) - users will still have the code
> available and will have a chance to fix the driver that happens to work.
> (and perhaps another, capable, but friendler maintainer arises.) And
> that old code will be a clot to drag around, hindering your 'new'
> wireless code all along.
So new code is included in the Linux kernel based only on political
considerations instead on technical?
I'm not sure what's the matter. Show me _one_ person for whom
bcm43xx works and b43/legacy does not. And I will immediately stop
removal of that driver and fix b43.
> I really dont know why it's so hard to understand: new is totally
> useless if it does not work for old setups 100% of the time. And people
> _WANT_ to use your new code, so it's not like you have to pull their
> hairs to get your stuff tested. And YOU wrote the old code in large
> part:
>
> $ git-authors drivers/net/wireless/bcm43xx/ | tail -10
> 2 Sam Ravnborg
> 3 David Howells
> 3 David Woodhouse
> 3 Joe Perches
> 4 Jeff Garzik
> 5 Daniel Drake
> 6 Stefano Brivio
> 9 John W. Linville
> 48 Larry Finger
> 80 Michael Buesch
>
> so it's not like "someone else messed it up" and that you would be
> incapable of getting it all work nicely and make the migration of users
> smoother. And if udev is a hindrance to you, reduce your driver's
> dependence on udev breakages.
I'm not sure what you are talking about.
If udev renames the device to something stupid (like wlan0_rename)
that is not my fault. That is the fault of a big Linux Distribution
messing udev config up.
Let's summarise it:
I don't know a single user for whom bcm43xx works but b43 does not.
In most cases b43 does work a _lot_ better than bcm43xx.
If you show me one person for whom bcm43xx works but b43 does not I
will stop removal of the driver.
--
Greetings Michael.
* Michael Buesch <[email protected]> wrote:
> > The testers who did nothing but reported that the new driver did not
> > work on their hardware.
>
> Which testers?
right in this thread Ray Lee is reporting:
| | Digging a little farther into it, it looks like b43 is barfing
| | partway through init as the firmware file it's looking for has
| | changed names. Perhaps that's the issue. I'll take a longer look at
| | this all tomorrow.
you are really in denial of reality. Just re-read this thread. Upon
re-reading this thread, try to imagine that you are in place of Ray Lee
(might be hard), that you had a working bcm43xx driver and that now you
try to get b43 to work. You are not a kernel hacker who knows this
driver, just an advanced user who'd like to give you some more feedback
about your shiny new code. From that perspective, do you think your
replies were fine, constructive and involved the tester? I sure read
them as dismissive, they had an annoyed tone (i'm not sure why - he was
trying to get _YOUR_ code to work) and were borderline arrogant. Looking
at the replies from Ray Lee it sure seemed to me he had a similar
impression. In place of Ray Lee, would you report new bugs to the
maintainer of b43? I sure as hell would avoid it if i could. Do you
think such incidents help Linux in the long run?
and you even claim:
> Ray Lee didn't even install the firmware. So it can't work by
> definition. That is not my fault.
which questions your basic skills of reading or of empathy. Why is a
reasonable firmware blob not included in the kernel? If not, why doesnt
the b43 driver warn in the dmesg (where Ray Lee did look) that no
firmware was loaded? These are basic driver usability issues, and of
course they are your fault too.
> > Yes, you can then "unsupport it" in spite and be a prick about it in
> > general but that will only talk of your own personal qualities and
> > will sharply reduce your credibility as a maintainer (and eventually
> > hinder your ability to introduce new code) - users will still have
> > the code available and will have a chance to fix the driver that
> > happens to work. (and perhaps another, capable, but friendler
> > maintainer arises.) And that old code will be a clot to drag around,
> > hindering your 'new' wireless code all along.
>
> So new code is included in the Linux kernel based only on political
> considerations instead on technical?
huh? This is nothing "political". It's the basic rule of maintenance:
try to be a good maintainer, involve people, forgive their newbie
mistakes. It's like the driving principle of Intenret protocols: be
conservative at what you xmit and be liberal at what you rx.
Ingo
On Friday 14 December 2007 13:16:17 Ingo Molnar wrote:
>
> * Michael Buesch <[email protected]> wrote:
>
> > > The testers who did nothing but reported that the new driver did not
> > > work on their hardware.
> >
> > Which testers?
>
> right in this thread Ray Lee is reporting:
>
> | | Digging a little farther into it, it looks like b43 is barfing
> | | partway through init as the firmware file it's looking for has
> | | changed names. Perhaps that's the issue. I'll take a longer look at
> | | this all tomorrow.
>
> you are really in denial of reality. Just re-read this thread. Upon
> re-reading this thread, try to imagine that you are in place of Ray Lee
> (might be hard), that you had a working bcm43xx driver and that now you
> try to get b43 to work. You are not a kernel hacker who knows this
> driver, just an advanced user who'd like to give you some more feedback
> about your shiny new code.
This user did get the following messages in dmesg:
b43err(dev->wl, "Firmware file \"%s\" not found "
"or load failed.\n", path);
b43err(wl, "You must go to "
"http://linuxwireless.org/en/users/Drivers/b43#devicefirmware "
"and download the correct firmware (version 4).\n");
I'm not sure how I can improve that even more. There is a full URL
describing how to get the device workin in _full_ detail.
Yes. I know people don't read messages and immediately report
a "regression". But that is not my fault. Not in this case.
It's not rocket science to get b43 working. The way firmware is
installed did not change at all. (b43-fwcutter is still used).
So it's the very same procedure that user X already successfully
did when installing bcm43xx.
What should I do to improve the situation? Writing the message
all in uppercase? Maybe. I can do a patch, if people finally start reading
it then.
> > Ray Lee didn't even install the firmware. So it can't work by
> > definition. That is not my fault.
>
> which questions your basic skills of reading or of empathy. Why is a
> reasonable firmware blob not included in the kernel?
Because it's closed source.
> If not, why doesnt
> the b43 driver warn in the dmesg (where Ray Lee did look) that no
> firmware was loaded? These are basic driver usability issues, and of
> course they are your fault too.
This is a proven false statement.
> > So new code is included in the Linux kernel based only on political
> > considerations instead on technical?
>
> huh? This is nothing "political". It's the basic rule of maintenance:
> try to be a good maintainer, involve people, forgive their newbie
> mistakes. It's like the driving principle of Intenret protocols: be
> conservative at what you xmit and be liberal at what you rx.
That's not what my problem is here.
The problem is that every now and then people come up and say that
b43 is crap and doesn't work for them while bcm43xx does. In _every_
single case it was the user's fault. Mostly not reading the kernel
message I quoted above.
So I'm not sure what I have to do now? Defer removal of an obsolete
and unstable piece of junk because some people don't read kernel
logs in case something doesn't work?
--
Greetings Michael.
* Michael Buesch <[email protected]> wrote:
> This user did get the following messages in dmesg:
>
> b43err(dev->wl, "Firmware file \"%s\" not found "
> "or load failed.\n", path);
> b43err(wl, "You must go to "
> "http://linuxwireless.org/en/users/Drivers/b43#devicefirmware "
> "and download the correct firmware (version 4).\n");
>
> I'm not sure how I can improve that even more. There is a full URL
> describing how to get the device workin in _full_ detail.
well i dont have this hardware, but the following description in this
thread seems to contradict that:
|| Well, doing an `rmmod bcm43xx ; modprobe ssb b43` gives me nothing in
|| dmesg other than lines related to the bcm43xx driver.
|| iwconfig/ifconfig do not see the interface either.
Ingo
fre, 14 12 2007 kl. 13:31 +0100, skrev Michael Buesch:
> On Friday 14 December 2007 13:16:17 Ingo Molnar wrote:
> >
> > * Michael Buesch <[email protected]> wrote:
> >
> > > > The testers who did nothing but reported that the new driver did not
> > > > work on their hardware.
> > >
> > > Which testers?
> >
> > right in this thread Ray Lee is reporting:
> >
> > | | Digging a little farther into it, it looks like b43 is barfing
> > | | partway through init as the firmware file it's looking for has
> > | | changed names. Perhaps that's the issue. I'll take a longer look at
^^^^^^^^^^^^^^
Ray probably has version 3 of the firmware.
> > | | this all tomorrow.
> >
> > you are really in denial of reality. Just re-read this thread. Upon
> > re-reading this thread, try to imagine that you are in place of Ray Lee
> > (might be hard), that you had a working bcm43xx driver and that now you
> > try to get b43 to work. You are not a kernel hacker who knows this
> > driver, just an advanced user who'd like to give you some more feedback
> > about your shiny new code.
>
> This user did get the following messages in dmesg:
>
> b43err(dev->wl, "Firmware file \"%s\" not found "
> "or load failed.\n", path);
So the question seems to be why b43 needs version 4, when b43legacy and
bcm43x uses version 3?
Simon Holm Thøgersen
On Friday 14 December 2007 13:59:54 Simon Holm Thøgersen wrote:
> > This user did get the following messages in dmesg:
> >
> > b43err(dev->wl, "Firmware file \"%s\" not found "
> > "or load failed.\n", path);
>
> So the question seems to be why b43 needs version 4, when b43legacy and
> bcm43x uses version 3?
That's really a question, right?
Well. linux-2.4 doesn't work with the linux-2.6 modutils.
Windows Vista doesn't work with Windows 98 device drivers.
That leads to this assumption:
b43 doesn't work with version 3 firmware but needs version 4.
Newer drivers supporting newer hardware need newer firmware.
--
Greetings Michael.
On Friday 14 December 2007 13:53:27 Ingo Molnar wrote:
>
> * Michael Buesch <[email protected]> wrote:
>
> > This user did get the following messages in dmesg:
> >
> > b43err(dev->wl, "Firmware file \"%s\" not found "
> > "or load failed.\n", path);
> > b43err(wl, "You must go to "
> > "http://linuxwireless.org/en/users/Drivers/b43#devicefirmware "
> > "and download the correct firmware (version 4).\n");
> >
> > I'm not sure how I can improve that even more. There is a full URL
> > describing how to get the device workin in _full_ detail.
>
> well i dont have this hardware, but the following description in this
> thread seems to contradict that:
>
> || Well, doing an `rmmod bcm43xx ; modprobe ssb b43` gives me nothing in
> || dmesg other than lines related to the bcm43xx driver.
> || iwconfig/ifconfig do not see the interface either.
Let's quote another of Ray's statements:
"And ifconfig -a does indeed show it, sorry about that."
So if he did then try to initialize that device, that clearly
_did_ show up in a standard place where network devices are
expected to show up, he did see the message I quoted.
Well, what if he did not try to initialize the device by doing
an "ifconfig wlanX up"? That can hardly be my fault, right?
--
Greetings Michael.
On Fri, Dec 14, 2007 at 11:56:24AM +0100, Ingo Molnar wrote:
>
> * Michael Buesch <[email protected]> wrote:
> > Oh come on. b43 is more than a year old now. How long should we wait?
> > Two or three? Forever?
>
> possibly forever, if you dont get obvious regressions like "my wlan does
> not work" (reported in this very thread), resolved. Pushing the blame to
> udev (in a rather unfriendly way) wont give users a working system and
> wont get you many new testers for the new driver either.
It is true that Michael can be a little unpleasant at times.
The colloquialism that comes to mind is that he "does not suffer fools
lightly". Hopefully he will take your counseling to heart and learn
to be a bit more moderate in his tone. FWIW, he is still young. :-)
That said, it is also true that the b43[legacy] driver[s] do a more
than adequate job of replacing the old bcm43xx driver provided that
one (re-)installs the proper firmware. And I know of no other driver
that goes to more trouble to tell you how to get the proper firmware
installed than this one.
The bcm43xx driver will be added to the feature removal schedule
in 2.6.25. Proper judgment will be used in deciding the actual date
of its removal. In the meantime hopefully every distribution will
have or obtain a working udev configuration. If things don't work
out as planned then we will re-evaluate.
Let's stop this now please.
John
--
John W. Linville
[email protected]
"John W. Linville" <[email protected]> wrote:
> On Fri, Dec 14, 2007 at 11:56:24AM +0100, Ingo Molnar wrote:
>>
>> * Michael Buesch <[email protected]> wrote:
>
>> > Oh come on. b43 is more than a year old now. How long should we wait?
>> > Two or three? Forever?
>>
>> possibly forever, if you dont get obvious regressions like "my wlan does
>> not work" (reported in this very thread), resolved. Pushing the blame to
>> udev (in a rather unfriendly way) wont give users a working system and
>> wont get you many new testers for the new driver either.
>
> It is true that Michael can be a little unpleasant at times.
> The colloquialism that comes to mind is that he "does not suffer fools
> lightly". Hopefully he will take your counseling to heart and learn
> to be a bit more moderate in his tone. FWIW, he is still young. :-)
No way. He's just inhuman. :P
> That said, it is also true that the b43[legacy] driver[s] do a more
> than adequate job of replacing the old bcm43xx driver provided that
> one (re-)installs the proper firmware. And I know of no other driver
> that goes to more trouble to tell you how to get the proper firmware
> installed than this one.
>
> The bcm43xx driver will be added to the feature removal schedule
> in 2.6.25. Proper judgment will be used in deciding the actual date
> of its removal. In the meantime hopefully every distribution will
> have or obtain a working udev configuration. If things don't work
> out as planned then we will re-evaluate.
>
> Let's stop this now please.
Agreed. As a b43legacy maintainer, I'd be happy to know if Ingo
suggests other ways to smooth out the transition. I haven't read
proposals yet.
--
Ciao
Stefano
Hi all. Perhaps I can inject some facts into this?
On Dec 14, 2007 5:08 AM, Michael Buesch <[email protected]> wrote:
> > > This user did get the following messages in dmesg:
> > >
> > > b43err(dev->wl, "Firmware file \"%s\" not found "
> > > "or load failed.\n", path);
> > > b43err(wl, "You must go to "
> > > "http://linuxwireless.org/en/users/Drivers/b43#devicefirmware "
> > > "and download the correct firmware (version 4).\n");
> > >
> > > I'm not sure how I can improve that even more. There is a full URL
> > > describing how to get the device workin in _full_ detail.
Yes, but only if you load rfkill-input and rfkill by hand, prior.
Without those, dmesg is entirely silent, and nothing works even to the
stage that I got it to last night. I had to search the bcm43xx-dev
archives to find that out, and it was a message from Larry saying that
he'd finally tracked down why it was working for some people and not
others -- some of us build fully modular kernels.
That I'm one of the first people to hit that makes me think that your
testing base so far has been miniscule.
Once I did that, the dmesg after loading did indeed contain the URL,
and thank you for that.
> > well i dont have this hardware, but the following description in this
> > thread seems to contradict that:
> >
> > || Well, doing an `rmmod bcm43xx ; modprobe ssb b43` gives me nothing in
> > || dmesg other than lines related to the bcm43xx driver.
> > || iwconfig/ifconfig do not see the interface either.
See above. Without a modprobe of rfkill, rfkill-input that is the case.
> Let's quote another of Ray's statements:
> "And ifconfig -a does indeed show it, sorry about that."
>
> So if he did then try to initialize that device, that clearly
> _did_ show up in a standard place where network devices are
> expected to show up, he did see the message I quoted.
> Well, what if he did not try to initialize the device by doing
> an "ifconfig wlanX up"? That can hardly be my fault, right?
Heeeeellooooo? I tried that. It failed. What *I'm* talking about here
is that this everyone needs to be aware that this is *not* a drop in
replacement for bcm43xx, and if I'm having problems (not a kernel
hacker, but I make my living writing code), then sheesh, you're gonna
have a flood of people needing hand-holding on this.
I still don't understand why bcm43xx is sane enough to create an eth1
entry, and b43 needs more handholding, but I'm going to hold off on
commenting farther on that until I download the newer firmware. As it
stands, I haven't given b43 an honest test yet.
Please keep in mind that I'm really just trying to report my issues
with the code before others hit the same thing, and trying to do this
in a way that's productive for you all. I actually do understand what
an amazing amount of effort you've poured into bcm43xx and the b43's,
and again, I am thankful. I understand that bcm43xx is effectively
dead, and it has architectural problems (locking, at minimum), that
have been a problem for at least the past two years that *I've* been
using it, probably more.
The goal here is to make sure that your shiny new code will *work* for
everyone, okay? Not to attack you, as I don't think you in any way
deserve an attack. If I come off that way, I'm sorry. But likewise, if
you could give me the benefit of the doubt, this conversation would go
a lot smoother.
Thanks.
Ray
On Dec 14, 2007 6:40 AM, <[email protected]> wrote:
> Agreed. As a b43legacy maintainer, I'd be happy to know if Ingo
> suggests other ways to smooth out the transition. I haven't read
> proposals yet.
This isn't rocket science guys. Put a file in somewhere in your tree
called ReleaseAnnouncement or something, and ask Linus to adjust his
kernel release process to include the contents of `cat $( find . -name
ReleaseAnnouncement )` in the release message he sends out. Clear out
the file after the release.
Include things such as "bcm43xx is scheduled for removal. build both
b43 and b43legacy as a replacement. Be sure to download the latest
firmware from $URL and follow the instructions there to extract the
correct latest firmware necessary for your chip. There are known
incompatibilities with old udev versions, please ensure blah blah
blah."
Ray
On Dec 14, 2007 8:27 AM, Ray Lee <[email protected]> wrote:
> On Dec 14, 2007 6:40 AM, <[email protected]> wrote:
> > Agreed. As a b43legacy maintainer, I'd be happy to know if Ingo
> > suggests other ways to smooth out the transition. I haven't read
> > proposals yet.
>
> This isn't rocket science guys. Put a file in somewhere in your tree
> called ReleaseAnnouncement or something, and ask Linus to adjust his
> kernel release process to include the contents of `cat $( find . -name
> ReleaseAnnouncement )` in the release message he sends out. Clear out
> the file after the release.
>
> Include things such as "bcm43xx is scheduled for removal. build both
> b43 and b43legacy as a replacement. Be sure to download the latest
> firmware from $URL and follow the instructions there to extract the
> correct latest firmware necessary for your chip. There are known
> incompatibilities with old udev versions, please ensure blah blah
> blah."
Or even better, keep the history, and show the diff of the old versus
new in the release announcement, with an appropriate sed 's/+/ /' or
somesuch.
<shrug> I'm sure you all will figure something out. Regardless, my
point is a higher level changelog that is human readable would be
helpful. (There are thousands of per-commit changelog entries to read,
it's beyond what I have the time to do when testing a new kernel).
Also, it seems distributing the release announcement work would be as
helpful as distributing the code development work.
Ray
On Friday 14 December 2007 17:06:39 Ray Lee wrote:
> Hi all. Perhaps I can inject some facts into this?
>
> On Dec 14, 2007 5:08 AM, Michael Buesch <[email protected]> wrote:
> > > > This user did get the following messages in dmesg:
> > > >
> > > > b43err(dev->wl, "Firmware file \"%s\" not found "
> > > > "or load failed.\n", path);
> > > > b43err(wl, "You must go to "
> > > > "http://linuxwireless.org/en/users/Drivers/b43#devicefirmware "
> > > > "and download the correct firmware (version 4).\n");
> > > >
> > > > I'm not sure how I can improve that even more. There is a full URL
> > > > describing how to get the device workin in _full_ detail.
>
> Yes, but only if you load rfkill-input and rfkill by hand, prior.
I'm not sure what you are doing there.
Do you have module autoloading disabled?
This all works perfectly well on all of my systems. And I never heared
such a problem before.
If you have a PCI device probing works as follows:
The PCI table is in ssb. So as soon as your kernel detects the PCI device
it will load ssb. ssb will register the PCI device. That will trigger
an udev event for the contained 802.11 core to get probed. This will load
b43.
So, I'm not sure where's the issue with my code here.
> That I'm one of the first people to hit that makes me think that your
> testing base so far has been miniscule.
The driver is shipped by Fedora since quite some time.
> > > || Well, doing an `rmmod bcm43xx ; modprobe ssb b43` gives me nothing in
> > > || dmesg other than lines related to the bcm43xx driver.
> > > || iwconfig/ifconfig do not see the interface either.
>
> See above. Without a modprobe of rfkill, rfkill-input that is the case.
You can't do
modprobe ssb b43
This will be interpreted as modprobe of "ssb" with the module
parameter "b43". At least by my modutils.
If you do
modprobe b43
it will automatically load _all_ required modules.
It works perfectly well on my systems.
Try it. Simply type "modprobe b43". It will also work for you.
> Heeeeellooooo? I tried that. It failed. What *I'm* talking about here
> is that this everyone needs to be aware that this is *not* a drop in
> replacement for bcm43xx, and if I'm having problems (not a kernel
> hacker, but I make my living writing code), then sheesh, you're gonna
> have a flood of people needing hand-holding on this.
All problems so far were not related to the b43 sourcecode at all.
And I think I can not be held responsible for unrelated code or bugs
in the operating system scripts.
--
Greetings Michael.
On Friday 14 December 2007 17:45:52 Ray Lee wrote:
> On Dec 14, 2007 8:27 AM, Ray Lee <[email protected]> wrote:
> > On Dec 14, 2007 6:40 AM, <[email protected]> wrote:
> > > Agreed. As a b43legacy maintainer, I'd be happy to know if Ingo
> > > suggests other ways to smooth out the transition. I haven't read
> > > proposals yet.
> >
> > This isn't rocket science guys. Put a file in somewhere in your tree
> > called ReleaseAnnouncement or something, and ask Linus to adjust his
> > kernel release process to include the contents of `cat $( find . -name
> > ReleaseAnnouncement )` in the release message he sends out. Clear out
> > the file after the release.
> >
> > Include things such as "bcm43xx is scheduled for removal. build both
> > b43 and b43legacy as a replacement. Be sure to download the latest
> > firmware from $URL and follow the instructions there to extract the
> > correct latest firmware necessary for your chip. There are known
> > incompatibilities with old udev versions, please ensure blah blah
> > blah."
>
> Or even better, keep the history, and show the diff of the old versus
> new in the release announcement, with an appropriate sed 's/+/ /' or
> somesuch.
>
> <shrug> I'm sure you all will figure something out. Regardless, my
> point is a higher level changelog that is human readable would be
> helpful. (There are thousands of per-commit changelog entries to read,
> it's beyond what I have the time to do when testing a new kernel).
> Also, it seems distributing the release announcement work would be as
> helpful as distributing the code development work.
In my opinion this all is the work of the distributions and not the
work of the kernel developers. Distributions have to make sure that
everything works after a kernel update. Yes I know that this is difficult
with b43, as the firmware is closed source. But this can be worked
around by explicitely prompting the user when the kernel is updated.
This is all distribution stuff.
What if you want to compile your own kernel? Well, then you are on
your own anyway. You have to track kernel changes anyway.
And I am pretty sure that it really is simple to track kernel changes.
Get your favourite kernel news site. It will tell you the changes
without this magic ReleaseAnnouncement file stuff.
I mean. There are news sites (even not specific ones for the kernel)
that reported the bcm43xx->b43 change weeks ago. There must be some
place where they get this information from without magic files. ;)
--
Greetings Michael.
On Dec 14, 2007 8:59 AM, Michael Buesch <[email protected]> wrote:
> What if you want to compile your own kernel? Well, then you are on
> your own anyway. You have to track kernel changes anyway.
I'm trying to help you test your code before it goes out to the
unsuspecting masses. Do you think I do this for *fun*? Sheesh. No, fun
is leaving my system exactly as it is not putting my brain into ADD
(Attention Deficit Disorder) mode to track the latest rc and look for
bugs.
I'm trying to point out issues that are going to to come up once the
full release hits. Testing, you know? Because I guarantee you that I'm
a nicer and more competent tester than a lot of the people you'll have
to deal with if there's a bug. (I, at least, have been writing
software for 20+ years, and have been on all sides of the process.)
If you *don't* want testing of b43, then I'm happy to leave it alone
and go back to bcm43xx, and point out that it shouldn't be removed
from the tree. None of us want that, as bcm43xx is a pile of junk. (I
just tried rmmod'ing it twice. First time, it oopsed my system. I was
in X, so no backtrace, just a blinking caps lock LED. Second time was
a hard lock, no oops. Have I mentioned that I'm not doing this for
fun?)
> There are news sites (even not specific ones for the kernel)
> that reported the bcm43xx->b43 change weeks ago.
Perhaps so. It didn't hit kerneltrap or lwn, both of which I follow
via RSS, so not sure what I should have been looking at instead.
Regardless, I'm asking for three sentences to be added to the kernel
release announcement. Hell, maybe Linus would even *like* to have you
guys supply part of the release announcement. He's a nice guy, how
about we ask?
Look, this really isn't all that much about bcm43xx/b43 here. I'm
trying to say that there are things that can help get more testers. If
you don't care about that, then fine, ignore this message.
Ray
* Michael Buesch <[email protected]> wrote:
> In my opinion this all is the work of the distributions and not the
> work of the kernel developers. Distributions have to make sure that
> everything works after a kernel update. [...]
actually, not. The the task of kernel developers is to KEEP OLD
DISTRIBUTIONS WORKING WITH NEW DRIVERS. Or the "old" driver stays around
until eternity, because the new one is just BROKEN.
Take a look at CONFIG_COMPAT_VDSO for example - one single version of
glibc was released in a distro that depended on a kernel vDSO bug. So
we'll keep that aspect of the vDSO perhaps forever. Simple as that.
Stuff must just work. Whatever it takes. Best is if you add in new stuff
without the user noticing _ANYTHING_ but that the kernel version bumped.
If the maintainers of the other 7 million lines of kernel code can get
this right then the wireless code should be able to do it too. Ok?
all this "distributors will have to sort out the mess" talk is nonsense,
and i really hope you do not truly believe in that crap. If your
attitude is prevalent in the wireless development community then it's in
worse shape than i thought :-(
Ingo
On Dec 14, 2007 8:49 AM, Michael Buesch <[email protected]> wrote:
> On Friday 14 December 2007 17:06:39 Ray Lee wrote:
> > Hi all. Perhaps I can inject some facts into this?
> >
> > On Dec 14, 2007 5:08 AM, Michael Buesch <[email protected]> wrote:
> > > > > This user did get the following messages in dmesg:
> > > > >
> > > > > b43err(dev->wl, "Firmware file \"%s\" not found "
> > > > > "or load failed.\n", path);
> > > > > b43err(wl, "You must go to "
> > > > > "http://linuxwireless.org/en/users/Drivers/b43#devicefirmware "
> > > > > "and download the correct firmware (version 4).\n");
> > > > >
> > > > > I'm not sure how I can improve that even more. There is a full URL
> > > > > describing how to get the device workin in _full_ detail.
> >
> > Yes, but only if you load rfkill-input and rfkill by hand, prior.
>
> I'm not sure what you are doing there.
> Do you have module autoloading disabled?
No, I don't have module autoloading disabled. modprobe-ing b43
automatically loads ssb. Neither, however, will load rfkill or
rfkill-input. And if they aren't loaded, then b43/ssb are *completely*
silent during load. Nothing to dmesg at all.
> This all works perfectly well on all of my systems. And I never heared
> such a problem before.
WTF? Please read *YOUR OWN MESSAGE* to the bcm43xx-dev list:
https://lists.berlios.de/pipermail/bcm43xx-dev/2007-December/006456.html
I'm going to blame this on you being tired or something, okay? But in
the meantime, could you *PLEASE* start giving me the benefit of the
doubt?
> If you have a PCI device probing works as follows:
> The PCI table is in ssb. So as soon as your kernel detects the PCI device
> it will load ssb. ssb will register the PCI device. That will trigger
> an udev event for the contained 802.11 core to get probed. This will load
> b43.
>
> So, I'm not sure where's the issue with my code here.
There's a patch from Larry Finger to address this and other issues. It
hasn't made it's way fully upstream yet. Please read your message
here, in particular item number seven on Larry's list:
https://lists.berlios.de/pipermail/bcm43xx-dev/2007-December/006472.html
> > That I'm one of the first people to hit that makes me think that your
> > testing base so far has been miniscule.
>
> The driver is shipped by Fedora since quite some time.
<shrug> Well, then they've made changes to udev or something else to
make this work okay for mere mortals such as myself, and haven't
pushed those changes upstream so that others can benefit from it.
> > > > || Well, doing an `rmmod bcm43xx ; modprobe ssb b43` gives me nothing in
> > > > || dmesg other than lines related to the bcm43xx driver.
> > > > || iwconfig/ifconfig do not see the interface either.
> >
> > See above. Without a modprobe of rfkill, rfkill-input that is the case.
>
> You can't do
> modprobe ssb b43
> This will be interpreted as modprobe of "ssb" with the module
> parameter "b43". At least by my modutils.
Yes, I know. I'm sorry I was unclear.
> If you do
> modprobe b43
> it will automatically load _all_ required modules.
> It works perfectly well on my systems.
> Try it. Simply type "modprobe b43". It will also work for you.
As I've said multiple times earlier in this thread, I did try that and
it didn't work. Do you believe me now?
> > Heeeeellooooo? I tried that. It failed. What *I'm* talking about here
> > is that this everyone needs to be aware that this is *not* a drop in
> > replacement for bcm43xx, and if I'm having problems (not a kernel
> > hacker, but I make my living writing code), then sheesh, you're gonna
> > have a flood of people needing hand-holding on this.
>
> All problems so far were not related to the b43 sourcecode at all.
> And I think I can not be held responsible for unrelated code or bugs
> in the operating system scripts.
So, do you want a scorecard on this?
One problem related to b43 source code, patch exists, has yet to be
merged upstream.
One problem related to udev rules, that may or may not be fixed in the
latest udev. I have udev version 113, which is the latest shipped in
Ubuntu's nightly development snapshots (hardy heron). I see that
version 117 of udev is available on kernel.org, but mine is from the
end of June. One would think that wouldn't be so old as to be a
complete deal breaker. Especially as bcm43xx works fine with my udev.
The b43 code requires the latest firmware, something that isn't quite
obvious from skimming the changelogs. But is in dmesg, so thanks for
that.
With udev rules hand-edited to include the ATTRS{type}==1 Larry
pointed out (thanks Larry), b43 also seems to create an odd extra
device, wmaster0. Same MAC as eth1, my wireless. It's just an odd
thing that wasn't there before with bcm43xx. May be good, may be bad,
dunno.
And yeah, in my opinion, making the kernel play well with up-to-date
userspace actually *is* part of your job, but then again, what do I
know.
Michael, you're a good guy, I believe that. You're doing unglamorous
and mostly thankless work, and I am thankful for it. I'm afraid the
only way I could make it glamorous is to offer to send you a fancy
feathered outfit to wear while coding :-). But try to meet us testers
halfway, okay? Please keep in mind that I'm really only trying to
help.
Now I'm going to go off, sit in the sun, sip some coffee, and think
happy thoughts of kittens playing with yarn for a while.
Ray
* Ray Lee <[email protected]> wrote:
> Now I'm going to go off, sit in the sun, sip some coffee, and think
> happy thoughts of kittens playing with yarn for a while.
ok, and given the time-shift and apparent season-shift i'll sit in the
evening, watch the snowfall and think happy thoughts of kittens fetching
nuclear-tipped uzis and hunting ueber-elite wireless developers to beat
some humanity and compassion into them, ok? ;-)
Ingo
On Friday 14 December 2007 19:01:51 Ray Lee wrote:
> No, I don't have module autoloading disabled. modprobe-ing b43
> automatically loads ssb. Neither, however, will load rfkill or
> rfkill-input. And if they aren't loaded, then b43/ssb are *completely*
> silent during load. Nothing to dmesg at all.
That is a bug in your distribution. I cannot fix this.
Maybe the module is blacklisted or whatever. This is _not_ a b43 bug.
> > This all works perfectly well on all of my systems. And I never heared
> > such a problem before.
>
> WTF? Please read *YOUR OWN MESSAGE* to the bcm43xx-dev list:
>
> https://lists.berlios.de/pipermail/bcm43xx-dev/2007-December/006456.html
>
> I'm going to blame this on you being tired or something, okay? But in
> the meantime, could you *PLEASE* start giving me the benefit of the
> doubt?
The message you quote describes a _completely_ unrelated bug.
Besides that the bug described in the message does _not_ prevent
the device from working. It does _just_ prevent some random LED from
blinking. I'd not call that a big issue.
To say it again: This message was about loading "rfkill-input" _after_
b43 was loaded successfully.
Please carefully read the messages before using them to prove me wrong.
> > If you have a PCI device probing works as follows:
> > The PCI table is in ssb. So as soon as your kernel detects the PCI device
> > it will load ssb. ssb will register the PCI device. That will trigger
> > an udev event for the contained 802.11 core to get probed. This will load
> > b43.
> >
> > So, I'm not sure where's the issue with my code here.
>
> There's a patch from Larry Finger to address this and other issues. It
> hasn't made it's way fully upstream yet. Please read your message
> here, in particular item number seven on Larry's list:
>
> https://lists.berlios.de/pipermail/bcm43xx-dev/2007-December/006472.html
1) I sent this patch out today for inclusion in the kernel
2) This is a _completely_ unrelated issue.
It is about "rfkill-input" being not loaded. NOT about
"b43" or "rfkill" not being loaded.
> > If you do
> > modprobe b43
> > it will automatically load _all_ required modules.
> > It works perfectly well on my systems.
> > Try it. Simply type "modprobe b43". It will also work for you.
>
> As I've said multiple times earlier in this thread, I did try that and
> it didn't work. Do you believe me now?
Ok, Please find out why it doesn't work.
> > > Heeeeellooooo? I tried that. It failed. What *I'm* talking about here
> > > is that this everyone needs to be aware that this is *not* a drop in
> > > replacement for bcm43xx, and if I'm having problems (not a kernel
> > > hacker, but I make my living writing code), then sheesh, you're gonna
> > > have a flood of people needing hand-holding on this.
> >
> > All problems so far were not related to the b43 sourcecode at all.
> > And I think I can not be held responsible for unrelated code or bugs
> > in the operating system scripts.
>
> So, do you want a scorecard on this?
>
> One problem related to b43 source code, patch exists, has yet to be
> merged upstream.
Yeah. A problem preventing a LED from blinking.
That's a real regression.... Come on. Stop that bullshit.
> One problem related to udev rules, that may or may not be fixed in the
> latest udev. I have udev version 113, which is the latest shipped in
> Ubuntu's nightly development snapshots (hardy heron). I see that
> version 117 of udev is available on kernel.org, but mine is from the
> end of June. One would think that wouldn't be so old as to be a
> complete deal breaker. Especially as bcm43xx works fine with my udev.
How can I fix that?
> With udev rules hand-edited to include the ATTRS{type}==1 Larry
> pointed out (thanks Larry), b43 also seems to create an odd extra
> device, wmaster0.
That's not b43 specific. And it is not a bug. Ignore wmaster.
It is not useful for anything from userspace.
> Same MAC as eth1, my wireless. It's just an odd
> thing that wasn't there before with bcm43xx. May be good, may be bad,
> dunno.
Blame your distribution, please.
> And yeah, in my opinion, making the kernel play well with up-to-date
> userspace actually *is* part of your job, but then again, what do I
> know.
How the hell do I workaround broken udev scripts from within the kernel?
> Michael, you're a good guy, I believe that. You're doing unglamorous
> and mostly thankless work, and I am thankful for it. I'm afraid the
> only way I could make it glamorous is to offer to send you a fancy
> feathered outfit to wear while coding :-). But try to meet us testers
> halfway, okay? Please keep in mind that I'm really only trying to
> help.
Yeah. So PLEASE point out real bugs in MY code and do not bother
me with other peoples bugs that I simply can not fix.
In the list above there was exactly one bug for which I am responsible.
And I already sent a fix for this one.
> Now I'm going to go off, sit in the sun, sip some coffee, and think
> happy thoughts of kittens playing with yarn for a while.
Have fun.
--
Greetings Michael.
On Friday 14 December 2007 18:59:10 Ingo Molnar wrote:
>
> * Michael Buesch <[email protected]> wrote:
>
> > In my opinion this all is the work of the distributions and not the
> > work of the kernel developers. Distributions have to make sure that
> > everything works after a kernel update. [...]
>
> actually, not. The the task of kernel developers is to KEEP OLD
> DISTRIBUTIONS WORKING WITH NEW DRIVERS. Or the "old" driver stays around
> until eternity, because the new one is just BROKEN.
What exactly prevents an old distribution from using new b43
given that they fix their broken udev scripts first?
(I cannot fix their broken scripts from within the kernel.)
> Take a look at CONFIG_COMPAT_VDSO for example - one single version of
> glibc was released in a distro that depended on a kernel vDSO bug. So
> we'll keep that aspect of the vDSO perhaps forever. Simple as that.
> Stuff must just work. Whatever it takes. Best is if you add in new stuff
> without the user noticing _ANYTHING_ but that the kernel version bumped.
> If the maintainers of the other 7 million lines of kernel code can get
> this right then the wireless code should be able to do it too. Ok?
>
> all this "distributors will have to sort out the mess" talk is nonsense,
> and i really hope you do not truly believe in that crap. If your
> attitude is prevalent in the wireless development community then it's in
> worse shape than i thought :-(
Sorry if I didn't chose my wording correctly. But I was only talking
about the development of drivers. It is correct that userspace ABI has
to be preserved, but that is not an issue at all to drivers.
I was talking about things like installing the right firmware for
the new driver. It is the job of the distributors to install the new
firmware when they introduce a new driver. It is the job of the distributors
to test their userland scripts and configuration stuff with that driver
and fix their stuff. It is _not_ my job to fix random distribution
udev scripts or explaining over and over again to people how the firmware
is installed. Either distributions have to install it automatically
or people simply have to read one or two lines of documentation.
That's just what I wanted to say.
Of course it is _my_ job to preserve ABI. I did never want to question that.
--
Greetings Michael.
I've run out of time to donate to the kernel today, so I'll keep this short.
On Dec 14, 2007 10:22 AM, Michael Buesch <[email protected]> wrote:
> > > If you have a PCI device probing works as follows:
> > > The PCI table is in ssb. So as soon as your kernel detects the PCI device
> > > it will load ssb. ssb will register the PCI device. That will trigger
> > > an udev event for the contained 802.11 core to get probed. This will load
> > > b43.
> > >
> > > So, I'm not sure where's the issue with my code here.
> >
> > There's a patch from Larry Finger to address this and other issues. It
> > hasn't made it's way fully upstream yet. Please read your message
> > here, in particular item number seven on Larry's list:
> >
> > https://lists.berlios.de/pipermail/bcm43xx-dev/2007-December/006472.html
>
> 1) I sent this patch out today for inclusion in the kernel
> 2) This is a _completely_ unrelated issue.
> It is about "rfkill-input" being not loaded. NOT about
> "b43" or "rfkill" not being loaded.
[...]
> > So, do you want a scorecard on this?
> >
> > One problem related to b43 source code, patch exists, has yet to be
> > merged upstream.
>
> Yeah. A problem preventing a LED from blinking.
> That's a real regression.... Come on. Stop that bullshit.
I'm going to say this one last time. If rfkill and rfkill-input aren't
manually loaded before sb and b43, not one damn thing comes out in
dmesg. Nothing. Nada. Zilch. Zero. Bupkis. Zot. Null. The only way to
find out that those modules had to be loaded by hand was to go read
the bcm43xx-dev archives. Once those were loaded, messages came out in
dmesg pointing me to the URL for updated firmware.
I have complete current userspace as of yesterday's Ubuntu Hardy Heron
development archives.
One last thing. I've been nice to you. Please be nice to me. If you
can't manage that, then let another wireless developer take over.
You apparently think I'm an idiot. I'm not, and if necessary I could
supply a long list of credentials to prove I'm not an idiot. I'd
rather you just accepted my emails at face value and spent more effort
on trying to see how the bugs could be occurring rather than spending
effort on trying to prove that I'm an idiot.
Thanks.
Ray
On Dec 14, 2007 10:11 AM, Ingo Molnar <[email protected]> wrote:
> * Ray Lee <[email protected]> wrote:
>
> > Now I'm going to go off, sit in the sun, sip some coffee, and think
> > happy thoughts of kittens playing with yarn for a while.
>
> ok, and given the time-shift and apparent season-shift i'll sit in the
> evening, watch the snowfall and think happy thoughts of kittens
Heh :-). Sometimes I feel guilty living in coastal California. But our
seasons are more along the lines of fire, flood, earthquake, and riot
:-).
Ray
On Friday 14 December 2007 19:45:02 Ray Lee wrote:
> > > One problem related to b43 source code, patch exists, has yet to be
> > > merged upstream.
> >
> > Yeah. A problem preventing a LED from blinking.
> > That's a real regression.... Come on. Stop that bullshit.
>
> I'm going to say this one last time. If rfkill and rfkill-input aren't
> manually loaded before sb and b43, not one damn thing comes out in
> dmesg. Nothing. Nada. Zilch. Zero. Bupkis. Zot. Null. The only way to
> find out that those modules had to be loaded by hand was to go read
> the bcm43xx-dev archives. Once those were loaded, messages came out in
> dmesg pointing me to the URL for updated firmware.
I'm sorry. The patch that _you_ quoted fixes a blinking LED
and nothing else. It does _not_ fix loading of rfkill or b43 in any way.
It does, however, fix loading of rfkill-input. But the b43 module
operation does _not_ depend in any way on the rfkill-input module, except
the tiny LED that doesn't blink if it's not loaded.
I hope you understood now that the thread on bcm43xx-dev was NOT about
your requirement to load rfkill before b43.
> I have complete current userspace as of yesterday's Ubuntu Hardy Heron
> development archives.
Ok. I will install a copy of Ubuntu Hardy Heron and check if I can
reproduce this.
However the fact that this does not happen on older Ubuntu platforms
and does not happen on Fedora leads to the conclusion that it
is a bug in Hardy Heron that I am not responsible for.
And you also do realise that Hardy Heron is the current development
version of Ubuntu? Development versions have bugs.
> One last thing. I've been nice to you. Please be nice to me.
If you simply stop blaming bugs on me that I am not responsible for
at all, that is a deal. What about filing a bug at the ubuntu bugzilla?
PS:
Note that Ubuntu is known to break the broadcom driver every now and then.
But I can not change that.
--
Greetings Michael.
On Dec 14, 2007 11:05 AM, Michael Buesch <[email protected]> wrote:
> On Friday 14 December 2007 19:45:02 Ray Lee wrote:
> > > > One problem related to b43 source code, patch exists, has yet to be
> > > > merged upstream.
> > >
> > > Yeah. A problem preventing a LED from blinking.
> > > That's a real regression.... Come on. Stop that bullshit.
> >
> > I'm going to say this one last time. If rfkill and rfkill-input aren't
> > manually loaded before sb and b43, not one damn thing comes out in
> > dmesg. Nothing. Nada. Zilch. Zero. Bupkis. Zot. Null. The only way to
> > find out that those modules had to be loaded by hand was to go read
> > the bcm43xx-dev archives. Once those were loaded, messages came out in
> > dmesg pointing me to the URL for updated firmware.
>
> I'm sorry. The patch that _you_ quoted fixes a blinking LED
> and nothing else.
Well, you're wrong. Sorry, but that's just the way it is. See below.
> It does _not_ fix loading of rfkill or b43 in any way.
> It does, however, fix loading of rfkill-input. But the b43 module
> operation does _not_ depend in any way on the rfkill-input module, except
> the tiny LED that doesn't blink if it's not loaded.
> I hope you understood now that the thread on bcm43xx-dev was NOT about
> your requirement to load rfkill before b43.
*AGAIN*, please read your message here, in particular item number
seven on Larry's list:
https://lists.berlios.de/pipermail/bcm43xx-dev/2007-December/006472.html
For the last fscking time, if rfkill and rfkill-input are not loaded,
not one line comes out in dmesg when b43 and ssb are loaded. In
particular, your pretty little message about needing newer firmware
also does not print. So, yeah, not loading rfkill{,-input} *does*
cause issues with b43 working, as there's no damn way to find out
what's broken!
> > I have complete current userspace as of yesterday's Ubuntu Hardy Heron
> > development archives.
>
> Ok. I will install a copy of Ubuntu Hardy Heron and check if I can
> reproduce this.
I'm not asking you to do that, this particular bug will be fixed by
Larry's patch, whether you believe that or not.
> However the fact that this does not happen on older Ubuntu platforms
> and does not happen on Fedora leads to the conclusion that it
> is a bug in Hardy Heron that I am not responsible for.
The kernel does not exist in a vacuum. It's the kernel's job to make
sure it works with properly written userspace. Broken userspace, sure,
then we can talk about breaking it.
> And you also do realise that Hardy Heron is the current development
> version of Ubuntu? Development versions have bugs.
Oy vay. I'm not an idiot. Yes, it's the current develoment version.
But tracking the latest kernel.org kernel has in the past required the
latest develoment version of the distribution, so I upgrade it as
well.
> > One last thing. I've been nice to you. Please be nice to me.
>
> If you simply stop blaming bugs on me that I am not responsible for
> at all, that is a deal. What about filing a bug at the ubuntu bugzilla?
I'm not blaming it on you. I'm merely reporting a fucking
incompatibility. Read my messages again from the top, and stop taking
this all so damn personally, will you?
On Friday 14 December 2007 20:25:39 Ray Lee wrote:
> > I'm sorry. The patch that _you_ quoted fixes a blinking LED
> > and nothing else.
>
> Well, you're wrong. Sorry, but that's just the way it is. See below.
>
> > It does _not_ fix loading of rfkill or b43 in any way.
> > It does, however, fix loading of rfkill-input. But the b43 module
> > operation does _not_ depend in any way on the rfkill-input module, except
> > the tiny LED that doesn't blink if it's not loaded.
> > I hope you understood now that the thread on bcm43xx-dev was NOT about
> > your requirement to load rfkill before b43.
>
> *AGAIN*, please read your message here, in particular item number
> seven on Larry's list:
>
> https://lists.berlios.de/pipermail/bcm43xx-dev/2007-December/006472.html
>
> For the last fscking time, if rfkill and rfkill-input are not loaded,
> not one line comes out in dmesg when b43 and ssb are loaded. In
> particular, your pretty little message about needing newer firmware
> also does not print. So, yeah, not loading rfkill{,-input} *does*
> cause issues with b43 working, as there's no damn way to find out
> what's broken!
Guy... .
I KNOW what the patch above does.
What do you think does the following line?
err = request_module("rfkill-input");
Does it load the "rfkill-input" or the "rfkill" module.
That's the million dollar question. You only have one try.
This patch is NOT about the "rfkill" module. I don't know how
often I have to say that. It is _obvious_.
Let's also quote Larry's sevenths point here, that you referred to
now for the second time:
" (7) If rfkill-input is built as a module, it is not automatically loaded."
I am not sure how I can make this any more clear.
It does load the "rfkill-input" module from within b43.
It does NOT load "rfkill"
It does NOT load "rfkill-input" BEFORE b43 was loaded.
This patch does exactly ONE thing. It does make sure a LED does blink.
Nothing more.
I signed this patch off. So you can be 100% sure I know what it does.
I do NOT sign off patches for which I don't know what they do.
> > > I have complete current userspace as of yesterday's Ubuntu Hardy Heron
> > > development archives.
> >
> > Ok. I will install a copy of Ubuntu Hardy Heron and check if I can
> > reproduce this.
>
> I'm not asking you to do that, this particular bug will be fixed by
> Larry's patch, whether you believe that or not.
Did you try that?
How can b43 load get fixed by a patch that adds a request_module()
to the b43 module? That is a chicken and egg problem!
> > However the fact that this does not happen on older Ubuntu platforms
> > and does not happen on Fedora leads to the conclusion that it
> > is a bug in Hardy Heron that I am not responsible for.
>
> The kernel does not exist in a vacuum. It's the kernel's job to make
> sure it works with properly written userspace. Broken userspace, sure,
> then we can talk about breaking it.
yes properly written userspace.
> > And you also do realise that Hardy Heron is the current development
> > version of Ubuntu? Development versions have bugs.
>
> Oy vay. I'm not an idiot. Yes, it's the current develoment version.
> But tracking the latest kernel.org kernel has in the past required the
> latest develoment version of the distribution, so I upgrade it as
> well.
I am running wireless-2.6 on feisty. So the kernel does _not_ require
an update of the distribution.
q.e.d.
> I'm not blaming it on you. I'm merely reporting a fucking
> incompatibility. Read my messages again from the top, and stop taking
> this all so damn personally, will you?
You are telling me that I don't understand patches that I sign off
and I should not take this personally?
That is challenging.
--
Greetings Michael.
On Dec 14, 2007 11:38 AM, Michael Buesch <[email protected]> wrote:
> On Friday 14 December 2007 20:25:39 Ray Lee wrote:
> > > I'm sorry. The patch that _you_ quoted fixes a blinking LED
> > > and nothing else.
> >
> > Well, you're wrong. Sorry, but that's just the way it is. See below.
> >
> > > It does _not_ fix loading of rfkill or b43 in any way.
> > > It does, however, fix loading of rfkill-input. But the b43 module
> > > operation does _not_ depend in any way on the rfkill-input module, except
> > > the tiny LED that doesn't blink if it's not loaded.
> > > I hope you understood now that the thread on bcm43xx-dev was NOT about
> > > your requirement to load rfkill before b43.
> >
> > *AGAIN*, please read your message here, in particular item number
> > seven on Larry's list:
> >
> > https://lists.berlios.de/pipermail/bcm43xx-dev/2007-December/006472.html
> >
> > For the last fscking time, if rfkill and rfkill-input are not loaded,
> > not one line comes out in dmesg when b43 and ssb are loaded. In
> > particular, your pretty little message about needing newer firmware
> > also does not print. So, yeah, not loading rfkill{,-input} *does*
> > cause issues with b43 working, as there's no damn way to find out
> > what's broken!
>
> Guy... .
> I KNOW what the patch above does.
> What do you think does the following line?
> err = request_module("rfkill-input");
> Does it load the "rfkill-input" or the "rfkill" module.
> That's the million dollar question. You only have one try.
Oh. My. God.
Michael. I have a degree in Physics. I placed sixth in the world
finals of the ACM Collegiate programming contest in 1999, Cal Poly
Team Gold. ( http://icpc.baylor.edu/past/icpc99/Finals/Tour/Win/Win.html
, I'm the guy all the way to the right. ) I ported the 2.4 kernel to a
custom ppc platform, including writing drivers for various hardware on
it ( http://patinc.com ). I'm the guy who did all the software for a
linux-based Voice over IP call center (
http://broncocommunications.com/ ).
So, *now* do you believe I'm not an idiot?
To answer your question, it requests the rfkill-input module. But
under the version I'm trying, rfkill-input is not automatically
loaded. I've pointed to the mailing list URL that proves that. So, I
loaded rfkill and rfkill-input by hand. Perhaps rfkill wasn't
necessary, I don't know, and I don't care. But once I did that, *then
and only then* did your damn b43 driver start printing out any
messages to dmesg at all, which then let me download the latest
firmware, and continue moving forward.
> You are telling me that I don't understand patches that I sign off
> and I should not take this personally?
> That is challenging.
I'm saying the patch you signed off on has a side-effect that will fix
my issue. And even if I *were* saying that, the most you should take
from it is that you are human and sometimes may make mistakes, just
like the rest of us. There's nothing challenging in that statement.
I've provided the bug report as many ways as I can think to. If you
don't agree, then I guess you'll just have to get the bug report from
someone else who can figure out exactly how to sugar coat the message
so that you'll listen to it.
Me, I'm done.
On Friday 14 December 2007 20:55:43 Ray Lee wrote:
> Oh. My. God.
>
> Michael. I have a degree in Physics. I placed sixth in the world
> finals of the ACM Collegiate programming contest in 1999, Cal Poly
> Team Gold. ( http://icpc.baylor.edu/past/icpc99/Finals/Tour/Win/Win.html
> , I'm the guy all the way to the right. ) I ported the 2.4 kernel to a
> custom ppc platform, including writing drivers for various hardware on
> it ( http://patinc.com ). I'm the guy who did all the software for a
> linux-based Voice over IP call center (
> http://broncocommunications.com/ ).
Nice. I am one of the main b43 developers and I wrote most of the code.
I know most of the code from the top of my head.
Besides that my weiner is bigger than yours. :P
> To answer your question, it requests the rfkill-input module. But
> under the version I'm trying, rfkill-input is not automatically
> loaded.
It is not an issue. You can even rmmod rfkill-input in FULL operation.
It will not disturb the operation, except that an LED stops working.
Try it! (I _did_ try it).
> I've pointed to the mailing list URL that proves that. So, I
> loaded rfkill and rfkill-input by hand. Perhaps rfkill wasn't
> necessary, I don't know, and I don't care. But once I did that, *then
> and only then* did your damn b43 driver start printing out any
> messages to dmesg at all, which then let me download the latest
> firmware, and continue moving forward.
The b43 does print _nothing_ on modprobe. That is _correct_ behaviour.
b43 does print the firmware message after "ifconfig up".
Might it be possible that this was coincidence and you messed
with modprobe rfkill and ifconfig up and finally saw the message?
> > You are telling me that I don't understand patches that I sign off
> > and I should not take this personally?
> > That is challenging.
>
> I'm saying the patch you signed off on has a side-effect that will fix
> my issue. And even if I *were* saying that, the most you should take
Ok. So please revert that patch and try to reproduce the breakage.
Does that work?
> from it is that you are human and sometimes may make mistakes, just
I am inhuman. We all know that.
(That was a joke that you probably don't understand. But you can google
for "bcw vs. bcm43xx" :) )
Ray, I _do_ want to understand what is going on in your machine.
I _have_ to understand it. But I currently do not understand how the
quoted patch could fix modprobe of b43 or rfkill. I'd simply call that
impossible.
Impossible because the patch does change a few function called _inside_
of the b43 module. How could that fix load of the b43 module? (Note that
we are not changing some modprobe magic like the ID table).
So could you please try to reproduce the breakage by reverting that
patch again? Just to make really sure it is this patch fixing the issue
and not just some coincidence.
Thanks for your help.
--
Greetings Michael.
On Dec 14, 2007 12:13 PM, Michael Buesch <[email protected]> wrote:
> Ray, I _do_ want to understand what is going on in your machine.
> I _have_ to understand it. But I currently do not understand how the
> quoted patch could fix modprobe of b43 or rfkill. I'd simply call that
> impossible.
Then perhaps it is. Perhaps it's a race condition in my userspace
where something NetworkManager related is trying to up the interface,
I don't know. More below.
Regardless, I'm going to have to put off doing more debugging until
tomorrow. I've rebooted back into 2.6.23.0 as wireshark doesn't show
any packets using 2.6.24-rc3 (the version I've been testing), reported
elsewhere, and that's preventing me from doing actual work with my
system, as I'm in the middle of trying to enhance a network server for
a client.
Note, the wireshark issue is very much not a bcm43xx/b43 issue; I'm
not trying to lay that at your feet.
> So could you please try to reproduce the breakage by reverting that
> patch again? Just to make really sure it is this patch fixing the issue
> and not just some coincidence.
I don't have the patch applied, so that's at least part of the
misunderstanding here. All I have is my sequence of "load b43, ssb,
nothing happens, unload them, load rfkill, rfkill-input, ssb, b43 and
something happens." I could very well be wrong. But I'm at the limit
of what I care to know about the b43 driver, and this is where I'm
asking for your help.
Hopefully tomorrow, I'll be able to build current tip and try this all
again, and I'll also try to do it with NetworkManager killed in the
background in case it was trying to bring the interfaces up behind my
back.
> Thanks for your help.
Thanks for treating me like an adult.
On Friday, 14 of December 2007, Michael Buesch wrote:
> On Friday 14 December 2007 13:59:54 Simon Holm Thøgersen wrote:
> > > This user did get the following messages in dmesg:
> > >
> > > b43err(dev->wl, "Firmware file \"%s\" not found "
> > > "or load failed.\n", path);
> >
> > So the question seems to be why b43 needs version 4, when b43legacy and
> > bcm43x uses version 3?
>
> That's really a question, right?
>
> Well. linux-2.4 doesn't work with the linux-2.6 modutils.
> Windows Vista doesn't work with Windows 98 device drivers.
> That leads to this assumption:
> b43 doesn't work with version 3 firmware but needs version 4.
>
> Newer drivers supporting newer hardware need newer firmware.
Actually, can you explain why, from the technical point of view, the version 4
firware is better than version 3, please?
Rafael
Rafael J. Wysocki wrote:
>
> Actually, can you explain why, from the technical point of view, the version 4
> firware is better than version 3, please?
I will be very interested in Michael's answer to this question; however, my experience is that it
doesn't make much difference if your device is supported by both V3 and V4 firmware. This impression
was obtained by comparing BCM4318 and BCM4311/1 devices with b43 and b43legacy.
Note that 802.11b and early BCM4306 devices are not supported by V4 firmware. Similarly, with
BCM4311/2 and newer devices V3 firmware fails. As Michael said "newer drivers supporting newer
hardware need newer firmware".
Larry
On Friday, 14 of December 2007, Michael Buesch wrote:
> On Friday 14 December 2007 18:59:10 Ingo Molnar wrote:
> >
> > * Michael Buesch <[email protected]> wrote:
> >
> > > In my opinion this all is the work of the distributions and not the
> > > work of the kernel developers. Distributions have to make sure that
> > > everything works after a kernel update. [...]
> >
> > actually, not. The the task of kernel developers is to KEEP OLD
> > DISTRIBUTIONS WORKING WITH NEW DRIVERS. Or the "old" driver stays around
> > until eternity, because the new one is just BROKEN.
>
> What exactly prevents an old distribution from using new b43
> given that they fix their broken udev scripts first?
>
> (I cannot fix their broken scripts from within the kernel.)
Well, we talked about that some time ago, didn't we?
The rule is this: if one uses kernel 2.6.x from kernel.org _successfully_
with certain distribution (whatever it is), then one is supposed to be able to
take the kernel 2.6.(x+1), install it on that distribution and use it without
any major configuration changes. If this rule is not followed, people will
stop testing kernel.org kernels and we'll all suffer from that.
Now, in my not so humble opinion, switching from bcm43xx to b43 _is_ a major
configuration change (I did it, so please don't try to discuss with my
experience) and forcing users to do that breaks the rule above.
> > Take a look at CONFIG_COMPAT_VDSO for example - one single version of
> > glibc was released in a distro that depended on a kernel vDSO bug. So
> > we'll keep that aspect of the vDSO perhaps forever. Simple as that.
> > Stuff must just work. Whatever it takes. Best is if you add in new stuff
> > without the user noticing _ANYTHING_ but that the kernel version bumped.
> > If the maintainers of the other 7 million lines of kernel code can get
> > this right then the wireless code should be able to do it too. Ok?
> >
> > all this "distributors will have to sort out the mess" talk is nonsense,
> > and i really hope you do not truly believe in that crap. If your
> > attitude is prevalent in the wireless development community then it's in
> > worse shape than i thought :-(
>
> Sorry if I didn't chose my wording correctly. But I was only talking
> about the development of drivers. It is correct that userspace ABI has
> to be preserved, but that is not an issue at all to drivers.
> I was talking about things like installing the right firmware for
> the new driver. It is the job of the distributors to install the new
> firmware when they introduce a new driver.
Yes, as far as new distributions are concerned. However, we _want_ kernel.org
kernels to work with the old ones too. Yes, WE DO.
> It is the job of the distributors to test their userland scripts and
> configuration stuff with that driver and fix their stuff. It is _not_ my job
> to fix random distribution udev scripts or explaining over and over again to
> people how the firmware is installed.
Given specific software environment (it may be a home-made system compiled
from sources or whatever), if installing a new kernel forces me to reconfigure
it in any significant way to obtain the functionality that I previously had,
the problem is with the kernel. No less, no more.
> Either distributions have to install it automatically or people simply have
> to read one or two lines of documentation. That's just what I wanted to say.
It's not that simple. For example, regression testing will be a major PITA
if one needs to switch back and forth from the new driver to the old one in the
process.
> Of course it is _my_ job to preserve ABI. I did never want to question that.
Greetings,
Rafael
On Dec 14, 2007 7:58 PM, Larry Finger <[email protected]> wrote:
> Rafael J. Wysocki wrote:
> >
> > Actually, can you explain why, from the technical point of view, the version 4
> > firware is better than version 3, please?
>
> I will be very interested in Michael's answer to this question; however, my experience is that it
> doesn't make much difference if your device is supported by both V3 and V4 firmware. This impression
> was obtained by comparing BCM4318 and BCM4311/1 devices with b43 and b43legacy.
>
> Note that 802.11b and early BCM4306 devices are not supported by V4 firmware.
Could this be the reason my BCM94311MCG rev 1 receives such terrible
performance with b43 but works well with bcm43xx? The device is
802.11b/g but my router is 802.11b. I filed a report on this issue
here: https://bugzilla.redhat.com/show_bug.cgi?id=413291
I was told by Michael that I would have to fix it myself, and I am
trying, but the learning curve is a little steep. If this is relevant,
I might at least have some direction to go in.
[email protected] wrote:
>
> Could this be the reason my BCM94311MCG rev 1 receives such terrible
> performance with b43 but works well with bcm43xx? The device is
> 802.11b/g but my router is 802.11b. I filed a report on this issue
> here: https://bugzilla.redhat.com/show_bug.cgi?id=413291
No. On my BCM4311/1, my transfer rate peaked at about 12 Mbs with bcm43xx, but increased to 20 Mbs
with b43. These tests were done with iperf with a server running running on a second computer
connected by wire to my router. These rates are for 802.11g. When my interface was locked at 11 Mbs,
the transfer rate was the expected 5.3-5.5 Mbs with both drivers.
> I was told by Michael that I would have to fix it myself, and I am
> trying, but the learning curve is a little steep. If this is relevant,
> I might at least have some direction to go in.
I suspect that mac80211 is doing something that your router does not like. Do you have any chance to
capture the traffic between your computer and the router by using a second wireless computer running
kismet or wireshark? A look at the differences between b43 and bcm43xx should show the reason.
Larry
On Dec 14, 2007 9:27 PM, Larry Finger <[email protected]> wrote:
>
> I suspect that mac80211 is doing something that your router does not like. Do you have any chance to
> capture the traffic between your computer and the router by using a second wireless computer running
> kismet or wireshark? A look at the differences between b43 and bcm43xx should show the reason.
>
Hi Larry, thanks for replying.
I have to admit, I've never used either of these before, so I'm not
sure if I did this correctly.
I created two different packet dumps using kismet, one when my laptop
was using b43 and the other when it was using bcm43xx. While my
desktop was logging, I used my laptop to go to kernel.org and download
patch-2.6.23.11.bz2 (both times the browser started at
http://www.kernel.org/pub/linux/kernel/). Then I used tshark to parse
the dump files and create two new readable logs.
I'll attach these logs since I can't read much into them. The only
strange difference I noticed is that with b43, I got messages like
ICMP Destination unreachable (Host administratively prohibited), which
I didn't get with bcm43xx.
There's about 5 machines connected to this network -- the laptop with
the broadcom card has internal ip 192.168.0.3.
On Dec 14, 2007 11:37 PM, <[email protected]> wrote:
>
> I'll attach these logs since I can't read much into them.
I should do what I say...
[email protected] wrote:
> On Dec 14, 2007 11:37 PM, <[email protected]> wrote:
>> I'll attach these logs since I can't read much into them.
>
> I should do what I say...
>
It will take a while to finish looking over those logs, but are you using ipv6? If not, please
blacklist the ipv6 module to prevent it from loading - add the line 'blacklist ipv6' to file
/etc/modprobe.d/blacklist. In some cases, ipv6 can cause timeouts even though you do not have any
ipv6 routers.
Larry
On Saturday 15 December 2007 01:51:47 Rafael J. Wysocki wrote:
> On Friday, 14 of December 2007, Michael Buesch wrote:
> > On Friday 14 December 2007 13:59:54 Simon Holm Thøgersen wrote:
> > > > This user did get the following messages in dmesg:
> > > >
> > > > b43err(dev->wl, "Firmware file \"%s\" not found "
> > > > "or load failed.\n", path);
> > >
> > > So the question seems to be why b43 needs version 4, when b43legacy and
> > > bcm43x uses version 3?
> >
> > That's really a question, right?
> >
> > Well. linux-2.4 doesn't work with the linux-2.6 modutils.
> > Windows Vista doesn't work with Windows 98 device drivers.
> > That leads to this assumption:
> > b43 doesn't work with version 3 firmware but needs version 4.
> >
> > Newer drivers supporting newer hardware need newer firmware.
>
> Actually, can you explain why, from the technical point of view, the version 4
> firware is better than version 3, please?
version 4 is the new firmware released by broadcom. They obviously won't
support and write any version 3 firmware anymore. So we are forced to
switch to version 4 firmware to support the newest hardware (like N-PHY
in the future). It's really as simple as that.
The difference between v3 and v4 is basically the driver API. It changed
a lot and it is nontrivial to support both v3 and v4 in one driver.
So we decided to stay with v3 for legacy devices and take v4 for any newer
devices. We have to live with that crap until someone comes up
with an opensource firmware. :)
--
Greetings Michael.
On Dec 15, 2007 2:18 AM, Larry Finger <[email protected]> wrote:
>
> It will take a while to finish looking over those logs, but are you using ipv6? If not, please
> blacklist the ipv6 module to prevent it from loading - add the line 'blacklist ipv6' to file
> /etc/modprobe.d/blacklist. In some cases, ipv6 can cause timeouts even though you do not have any
> ipv6 routers.
I'll be gone all day today, so it may take me awhile to test. I tried
real quick to blacklist it, but fedora isn't making it easy,
apparently it's depended on by quite a few things and I can't even
force unload them. I'll build latest wireless git without ipv6 late
tonight. Also, the logs may be incomplete, they're probably missing
when the device first associates with the router. Not sure if I should
include that.
I'm thankful that at least we're moving in some direction to solve
this bug, thanks again.
On Sat, Dec 15, 2007 at 02:25:50AM +0100, Rafael J. Wysocki wrote:
> On Friday, 14 of December 2007, Michael Buesch wrote:
> > Either distributions have to install it automatically or people simply have
> > to read one or two lines of documentation. That's just what I wanted to say.
>
> It's not that simple. For example, regression testing will be a major PITA
> if one needs to switch back and forth from the new driver to the old one in the
> process.
Not really true -- a single system can easily have firmware installed
for b43, b43legacy, and bcm43xx at the same time and switch back and
forth between them.
Given a functioning udev configuration, the persistent naming even
works so that your device stays as 'eth1' when switching to and
fro bcm43xx. I really think everyone is overstating the problem.
John
--
John W. Linville
[email protected]
On Saturday, 15 of December 2007, Michael Buesch wrote:
> On Saturday 15 December 2007 01:51:47 Rafael J. Wysocki wrote:
> > On Friday, 14 of December 2007, Michael Buesch wrote:
> > > On Friday 14 December 2007 13:59:54 Simon Holm Thøgersen wrote:
> > > > > This user did get the following messages in dmesg:
> > > > >
> > > > > b43err(dev->wl, "Firmware file \"%s\" not found "
> > > > > "or load failed.\n", path);
> > > >
> > > > So the question seems to be why b43 needs version 4, when b43legacy and
> > > > bcm43x uses version 3?
> > >
> > > That's really a question, right?
> > >
> > > Well. linux-2.4 doesn't work with the linux-2.6 modutils.
> > > Windows Vista doesn't work with Windows 98 device drivers.
> > > That leads to this assumption:
> > > b43 doesn't work with version 3 firmware but needs version 4.
> > >
> > > Newer drivers supporting newer hardware need newer firmware.
> >
> > Actually, can you explain why, from the technical point of view, the version 4
> > firware is better than version 3, please?
>
> version 4 is the new firmware released by broadcom. They obviously won't
> support and write any version 3 firmware anymore. So we are forced to
> switch to version 4 firmware to support the newest hardware (like N-PHY
> in the future). It's really as simple as that.
I see, thanks.
> The difference between v3 and v4 is basically the driver API. It changed
> a lot and it is nontrivial to support both v3 and v4 in one driver.
> So we decided to stay with v3 for legacy devices and take v4 for any newer
> devices.
This is reasonable, yes.
> We have to live with that crap until someone comes up with an opensource
> firmware. :)
Well, the only problem with that is I suspect there are some "newer" cards that
work better with v3 firmware, although they are supposed to support both.
Greetings,
Rafael
On Saturday, 15 of December 2007, John W. Linville wrote:
> On Sat, Dec 15, 2007 at 02:25:50AM +0100, Rafael J. Wysocki wrote:
> > On Friday, 14 of December 2007, Michael Buesch wrote:
>
> > > Either distributions have to install it automatically or people simply have
> > > to read one or two lines of documentation. That's just what I wanted to say.
> >
> > It's not that simple. For example, regression testing will be a major PITA
> > if one needs to switch back and forth from the new driver to the old one in the
> > process.
>
> Not really true -- a single system can easily have firmware installed
> for b43, b43legacy, and bcm43xx at the same time and switch back and
> forth between them.
>
> Given a functioning udev configuration, the persistent naming even
> works so that your device stays as 'eth1' when switching to and
> fro bcm43xx.
Well, this last bit doesn't work on my openSUSE 10.3. Honest, guv. ;-)
> I really think everyone is overstating the problem.
You might be right.
Greetings,
Rafael
On Sunday 16 December 2007 00:18:43 Rafael J. Wysocki wrote:
> Well, the only problem with that is I suspect there are some "newer" cards that
> work better with v3 firmware, although they are supposed to support both.
And I suspect that you are wrong until you show me one. :)
--
Greetings Michael.
Michael Buesch wrote:
> On Sunday 16 December 2007 00:18:43 Rafael J. Wysocki wrote:
>> Well, the only problem with that is I suspect there are some "newer" cards that
>> work better with v3 firmware, although they are supposed to support both.
>
> And I suspect that you are wrong until you show me one. :)
The BCM4311/1 card used to work better with bcm43xx than it did with b43; however, since the power
control problem was "solved" in b43, there is very little difference. When I built my special system
to use the BCM4311 with b43legacy, there was no difference.
I don't know of any cards that work better with bcm43xx than with b43. Of course, that is comparing
SoftMAC with mac80211. There is, of course, no comparison.
Larry
On Sonntag, 16. Dezember 2007, Rafael J. Wysocki wrote:
> On Saturday, 15 of December 2007, John W. Linville wrote:
> > On Sat, Dec 15, 2007 at 02:25:50AM +0100, Rafael J. Wysocki wrote:
> > > On Friday, 14 of December 2007, Michael Buesch wrote:
> >
> > > > Either distributions have to install it automatically or people simply have
> > > > to read one or two lines of documentation. That's just what I wanted to say.
> > >
> > > It's not that simple. For example, regression testing will be a major PITA
> > > if one needs to switch back and forth from the new driver to the old one in the
> > > process.
> >
> > Not really true -- a single system can easily have firmware installed
> > for b43, b43legacy, and bcm43xx at the same time and switch back and
> > forth between them.
> >
> > Given a functioning udev configuration, the persistent naming even
> > works so that your device stays as 'eth1' when switching to and
> > fro bcm43xx.
>
> Well, this last bit doesn't work on my openSUSE 10.3. Honest, guv. ;-)
The persistent interface naming rules of udev, at least up to 0.114-2
(current debian unstable), seem to be easily confused if the driver names
change for the same MAC address. This issue seems not to be b43 specific,
it happens with zd1211rw --> zd1211rw_mac80211 (this one won't show up in
mainline kernels), prism54 --> p54pci/ p54usb, out-of-tree RaLink legacy/
serialmonkey (which ignore interface renames through udev completely) -->
rt2x00 just as well and I assume that it might also affect sk98lin -->
skge/ sky and the upcomming e1000 --> e1000e transitions and similar
situations.
> > I really think everyone is overstating the problem.
>
> You might be right.
It is of course confusing to the user and might affect remote updates, but
it's also easily fixed by removing the generated MAC address mappings and
letting udev generate new ones (+ post processing, if needed) during the
next boot.
> Greetings,
> Rafael
Regards
Stefan Lippers-Hollmann
* John W. Linville <[email protected]> wrote:
> > It's not that simple. For example, regression testing will be a
> > major PITA if one needs to switch back and forth from the new driver
> > to the old one in the process.
>
> Not really true -- a single system can easily have firmware installed
> for b43, b43legacy, and bcm43xx at the same time and switch back and
> forth between them.
as long as the version 4 firmware blob is present in the system, will
testers have a fully fluid test- and work-flow when migrating across
from bcm43xx to b43, without any other changes to an existing Linux
installation? (i.e. no udev tweaks, no forced upgrades of components,
etc.)
Will it Just Work in bisection as well, when a tester's kernel
flip/flops between bcm43xx and b43 - like it does for the other 3000+
drivers in the kernel?
Note that we are _NOT_ interested in "might" or "can" scenarios. We are
interested in preserving the _existing_ bcm43xx installed base and how
much of a seemless migration the b43 transition will be. _THAT_ is what
the "no regressions" upstream rule is about, not the "ideal distro"
scenario you outline above. It is YOUR total obligation as a kernel
maintainer to ensure that you dont break old installations. How hard is
that to understand? This is not rocket science.
Ingo
On Sunday 16 December 2007 03:30:16 Larry Finger wrote:
> Michael Buesch wrote:
> > On Sunday 16 December 2007 00:18:43 Rafael J. Wysocki wrote:
> >> Well, the only problem with that is I suspect there are some "newer" cards that
> >> work better with v3 firmware, although they are supposed to support both.
> >
> > And I suspect that you are wrong until you show me one. :)
>
> The BCM4311/1 card used to work better with bcm43xx than it did with b43; however, since the power
> control problem was "solved" in b43, there is very little difference. When I built my special system
> to use the BCM4311 with b43legacy, there was no difference.
>
> I don't know of any cards that work better with bcm43xx than with b43. Of course, that is comparing
> SoftMAC with mac80211. There is, of course, no comparison.
This was about version 3 firmware vs version 4 firmware.
I doubt the firmware makes any difference at all.
--
Greetings Michael.
On Sunday 16 December 2007 10:22:43 Ingo Molnar wrote:
>
> * John W. Linville <[email protected]> wrote:
>
> > > It's not that simple. For example, regression testing will be a
> > > major PITA if one needs to switch back and forth from the new driver
> > > to the old one in the process.
> >
> > Not really true -- a single system can easily have firmware installed
> > for b43, b43legacy, and bcm43xx at the same time and switch back and
> > forth between them.
>
> as long as the version 4 firmware blob is present in the system, will
> testers have a fully fluid test- and work-flow when migrating across
> from bcm43xx to b43, without any other changes to an existing Linux
> installation? (i.e. no udev tweaks, no forced upgrades of components,
> etc.)
>
> Will it Just Work in bisection as well, when a tester's kernel
> flip/flops between bcm43xx and b43 - like it does for the other 3000+
> drivers in the kernel?
>
> Note that we are _NOT_ interested in "might" or "can" scenarios. We are
> interested in preserving the _existing_ bcm43xx installed base and how
> much of a seemless migration the b43 transition will be. _THAT_ is what
> the "no regressions" upstream rule is about, not the "ideal distro"
> scenario you outline above. It is YOUR total obligation as a kernel
> maintainer to ensure that you dont break old installations. How hard is
> that to understand? This is not rocket science.
I see no reason for b43 to break, if the firmware is properly installed.
In fact, almost all installation related bugreports we receive are
caused by missing or incorrectly installed firmware.
I would really _like_ to make installing firmware easier or make the
whole need for it vanish, but I simply can not at this point.
But anyway, installing it is not rocket science, either. The only thing
you have to know is where your distribution stores the firmware image files.
If you know that it's a matter of invoking one b43-fwcutter command
to install it. This process can be automated in the distribution's rpm
or deb package scripts.
b43lagacy/ssb is completely featured with module autoload support.
So if you have firmware installed it will automatically load all required
modules and create the network device(s) for it without any user interaction.
If that doesn't work, then stupid distributions are shipping braindamaged
udev scripts that pin a mac address to a specific driver name (see another
mail in this thread). I can _not_ fix this from within the kernel and
I will absolutely shift all responsibility and blame for this to the
maintainers of the distribution's udev scripts.
That's not a b43 specific problem then. Other drivers do break with these
scripts, too.
--
Greetings Michael.
On Sun, 2007-12-16 at 00:27 +0100, Michael Buesch wrote:
> On Sunday 16 December 2007 00:18:43 Rafael J. Wysocki wrote:
> > Well, the only problem with that is I suspect there are some "newer" cards that
> > work better with v3 firmware, although they are supposed to support both.
Impossible. The firmware is only the MAC.
johannes
On Sunday, 16 of December 2007, Johannes Berg wrote:
>
> On Sun, 2007-12-16 at 00:27 +0100, Michael Buesch wrote:
> > On Sunday 16 December 2007 00:18:43 Rafael J. Wysocki wrote:
> > > Well, the only problem with that is I suspect there are some "newer" cards that
> > > work better with v3 firmware, although they are supposed to support both.
>
> Impossible. The firmware is only the MAC.
OK
Thanks,
Rafael
> > On Sun, 2007-12-16 at 00:27 +0100, Michael Buesch wrote:
> > > On Sunday 16 December 2007 00:18:43 Rafael J. Wysocki wrote:
> > > > Well, the only problem with that is I suspect there are some "newer" cards that
> > > > work better with v3 firmware, although they are supposed to support both.
> >
> > Impossible. The firmware is only the MAC.
>
> OK
I should probably mention though that of course it is (in theory!)
possible that the card works better with bcm43xx, it just never has
happened for all I know.
johannes
On Dec 15, 2007 7:38 AM, <[email protected]> wrote:
>
> I'll build latest wireless git without ipv6 late tonight.
Ok, built and tested, and it's actually faster! Although still not as
fast as bcm43xx or softmac or whatever the problem is, I was getting a
steady 200 kB/s (as opposed to 500 kB/s for bcm43xx with the same
file/server). I'm not sure if it was the absence of ipv6 or the
commits included in updating my git repository though. Either way, I'm
fairly happy that I'm out of dial-up speed territory.
It'd be nice to be able to fully shake loose whatever is causing the
speed drain - and I call it a drain since sometimes the connection
starts out much faster, but slowly throttles down to whatever speed
it'll stick at (used to be 40 kB/s, but now is 200 kB/s). It does seem
to be like a cap or limit, as in if I download two files, each one
will download at 100 kB/s.
If anyone can help I'd really appreciate it. I know that bcm43xx will
someday be dropped, and when that day comes, it'd be nice if people
with this hardware have at least similar performance with b43 (myself
especially).
Thanks again,
Rob
[email protected] wrote:
> On Dec 15, 2007 7:38 AM, <[email protected]> wrote:
>> I'll build latest wireless git without ipv6 late tonight.
>
> Ok, built and tested, and it's actually faster! Although still not as
> fast as bcm43xx or softmac or whatever the problem is, I was getting a
> steady 200 kB/s (as opposed to 500 kB/s for bcm43xx with the same
> file/server). I'm not sure if it was the absence of ipv6 or the
> commits included in updating my git repository though. Either way, I'm
> fairly happy that I'm out of dial-up speed territory.
>
> It'd be nice to be able to fully shake loose whatever is causing the
> speed drain - and I call it a drain since sometimes the connection
> starts out much faster, but slowly throttles down to whatever speed
> it'll stick at (used to be 40 kB/s, but now is 200 kB/s). It does seem
> to be like a cap or limit, as in if I download two files, each one
> will download at 100 kB/s.
>
> If anyone can help I'd really appreciate it. I know that bcm43xx will
> someday be dropped, and when that day comes, it'd be nice if people
> with this hardware have at least similar performance with b43 (myself
> especially).
One major difference between bcm43xx-SoftMAC and b43-mac80211 is that the former always used a fixed
rate; whereas mac80211 tries to adjust the bit rate according to the transmission conditions.
Perhaps it isn't working quite right in your case because of some peculiarity of your AP. IIRC, you
have an 802.11b AP. If so, you will get the same bit speed behavior for mac80211 as for bcdm43xx by
issuing a 'sudo iwconfig eth1 rate 11M' command.
Larry
On Dec 17, 2007 1:52 AM, Larry Finger <[email protected]> wrote:
>
> One major difference between bcm43xx-SoftMAC and b43-mac80211 is that the former always used a fixed
> rate; whereas mac80211 tries to adjust the bit rate according to the transmission conditions.
> Perhaps it isn't working quite right in your case because of some peculiarity of your AP. IIRC, you
> have an 802.11b AP. If so, you will get the same bit speed behavior for mac80211 as for bcdm43xx by
> issuing a 'sudo iwconfig eth1 rate 11M' command.
I don't know what happened before, but after a reboot, I can't repeat
the 200 kB/s speed. It's back down to 40 kB/s, just like originally. I
didn't move the laptop, or the ap, the only thing I can think of that
might have changed is the noise level. FWIW, link quality is
consistently the same or better with b43.
Anyway, I'd noticed before that the bit rate starts at 1 Mb/s and
quickly scales to 11 Mb/s, but I tried setting it manually anyway and
didn't see any change. In fact, I set the rate to 5.5 Mb/s as well as
1 Mb/s and the download speed was the same with all three (around
30-40 kB/s).
On Monday 17 December 2007 08:17:58 [email protected] wrote:
> On Dec 17, 2007 1:52 AM, Larry Finger <[email protected]> wrote:
> >
> > One major difference between bcm43xx-SoftMAC and b43-mac80211 is that the former always used a fixed
> > rate; whereas mac80211 tries to adjust the bit rate according to the transmission conditions.
> > Perhaps it isn't working quite right in your case because of some peculiarity of your AP. IIRC, you
> > have an 802.11b AP. If so, you will get the same bit speed behavior for mac80211 as for bcdm43xx by
> > issuing a 'sudo iwconfig eth1 rate 11M' command.
>
> I don't know what happened before, but after a reboot, I can't repeat
> the 200 kB/s speed. It's back down to 40 kB/s, just like originally. I
> didn't move the laptop, or the ap, the only thing I can think of that
> might have changed is the noise level. FWIW, link quality is
> consistently the same or better with b43.
>
> Anyway, I'd noticed before that the bit rate starts at 1 Mb/s and
> quickly scales to 11 Mb/s, but I tried setting it manually anyway and
> didn't see any change. In fact, I set the rate to 5.5 Mb/s as well as
> 1 Mb/s and the download speed was the same with all three (around
> 30-40 kB/s).
Are you working with wireless-2.6's #everything branch?
--
Greetings Michael.
On Dec 17, 2007 4:49 AM, Michael Buesch <[email protected]> wrote:
>
> Are you working with wireless-2.6's #everything branch?
I've been working with vanilla wireless-2.6, but I've also tried the
everything branch as well as other trees. Just for good measure, I
just rebuilt the everything branch and it shows the same behavior.
If this is a mac80211 related problem, then other systems connecting
to the same ap and using mac80211 would also be affected? Like I said
earlier, there are five machines connecting to this ap, and I just
realized one of them has a ralink card that uses the rt2x00 driver,
which I believe is mac80211. That system doesn't have this problem,
which leads me to believe it may not be mac80211 after all, although I
wouldn't rule it out.
On Dec 17, 2007 5:35 AM, <[email protected]> wrote:
> If this is a mac80211 related problem, then other systems connecting
> to the same ap and using mac80211 would also be affected? Like I said
> earlier, there are five machines connecting to this ap, and I just
> realized one of them has a ralink card that uses the rt2x00 driver,
> which I believe is mac80211. That system doesn't have this problem,
> which leads me to believe it may not be mac80211 after all, although I
> wouldn't rule it out.
>
This also doesn't seem to be related to firmware version. I forced my
device to use b43legacy, and the results were identical with the
version 3 firmware.
On Monday 17 December 2007 23:04:37 [email protected] wrote:
> On Dec 17, 2007 5:35 AM, <[email protected]> wrote:
> > If this is a mac80211 related problem, then other systems connecting
> > to the same ap and using mac80211 would also be affected? Like I said
> > earlier, there are five machines connecting to this ap, and I just
> > realized one of them has a ralink card that uses the rt2x00 driver,
> > which I believe is mac80211. That system doesn't have this problem,
> > which leads me to believe it may not be mac80211 after all, although I
> > wouldn't rule it out.
> >
>
> This also doesn't seem to be related to firmware version. I forced my
> device to use b43legacy, and the results were identical with the
> version 3 firmware.
Ehm, excuse me.
What are you doing exactly? In this thread you told me you have
a device which requires b43:
> I don't know what happened before, but after a reboot, I can't repeat
> the 200 kB/s speed. It's back down to 40 kB/s, just like originally. I
> didn't move the laptop, or the ap, the only thing I can think of that
> might have changed is the noise level. FWIW, link quality is
> consistently the same or better with b43.
How the hell can you now "force it to use b43legacy"??
--
Greetings Michael.
On Dec 17, 2007 5:45 PM, Michael Buesch <[email protected]> wrote:
>
> Ehm, excuse me.
> What are you doing exactly? In this thread you told me you have
> a device which requires b43:
>
Well, I'm not sure what you mean by "requires" b43, but I did say that
the device uses the b43 driver.
> > I don't know what happened before, but after a reboot, I can't repeat
> > the 200 kB/s speed. It's back down to 40 kB/s, just like originally. I
> > didn't move the laptop, or the ap, the only thing I can think of that
> > might have changed is the noise level. FWIW, link quality is
> > consistently the same or better with b43.
>
> How the hell can you now "force it to use b43legacy"??
>
Sorry, I should have been more specific. I figured since the device
could use bcm43xx, it could also use b43legacy, so I copied the
entries in b43_ssb_tbl[] to b43legacy_ssb_tbl[] and rebuilt the
b43legacy driver. I removed the b43 and ssb modules, and inserted the
b43legacy module. Afterwards, I noticed b43 had still been autoloaded,
so I removed it (I checked dmesg and only b43legacy had initialized
anyway) , and proceeded to use the b43legacy driver with the version 3
firmware. And like I said, it works exactly like the b43 driver with
the version 4 firmware.
I'm not sure if it was the best way to go about it, but it worked.
On Tuesday 18 December 2007 00:12:30 [email protected] wrote:
> On Dec 17, 2007 5:45 PM, Michael Buesch <[email protected]> wrote:
> >
> > Ehm, excuse me.
> > What are you doing exactly? In this thread you told me you have
> > a device which requires b43:
> >
>
> Well, I'm not sure what you mean by "requires" b43, but I did say that
> the device uses the b43 driver.
Requires means requires.
> Sorry, I should have been more specific. I figured since the device
> could use bcm43xx, it could also use b43legacy, so I copied the
> entries in b43_ssb_tbl[] to b43legacy_ssb_tbl[] and rebuilt the
> b43legacy driver. I removed the b43 and ssb modules, and inserted the
> b43legacy module. Afterwards, I noticed b43 had still been autoloaded,
> so I removed it (I checked dmesg and only b43legacy had initialized
> anyway) , and proceeded to use the b43legacy driver with the version 3
> firmware. And like I said, it works exactly like the b43 driver with
> the version 4 firmware.
I'm not sure what you are trying to show with this hack.
It's been said several times in this thread that the firmware has
nothing to do with the device radio.
So it won't affect the transmit rate or something like that.
Note that the difference between b43 and b43legacy is NOT that the
driver is "legacy". It is called legacy because it does _only_ support
legacy _devices_. So if you hack it to drive a new card it will only
work by luck (luck as in there might be some code left over which
is able to initialize the device somehow.). My point being, we removed
code for new devices from b43legacy and are probably going to remove
even more stuff in the future. So there is simply no point in testing
any new device with b43legacy.
--
Greetings Michael.
On Dec 17, 2007 6:18 PM, Michael Buesch <[email protected]> wrote:
> On Tuesday 18 December 2007 00:12:30 [email protected] wrote:
> >
> > Well, I'm not sure what you mean by "requires" b43, but I did say that
> > the device uses the b43 driver.
>
> Requires means requires.
>
Ok, noted.
> > Sorry, I should have been more specific. I figured since the device
> > could use bcm43xx, it could also use b43legacy, so I copied the
> > entries in b43_ssb_tbl[] to b43legacy_ssb_tbl[] and rebuilt the
> > b43legacy driver. I removed the b43 and ssb modules, and inserted the
> > b43legacy module. Afterwards, I noticed b43 had still been autoloaded,
> > so I removed it (I checked dmesg and only b43legacy had initialized
> > anyway) , and proceeded to use the b43legacy driver with the version 3
> > firmware. And like I said, it works exactly like the b43 driver with
> > the version 4 firmware.
>
> I'm not sure what you are trying to show with this hack.
> It's been said several times in this thread that the firmware has
> nothing to do with the device radio.
> So it won't affect the transmit rate or something like that.
>
> Note that the difference between b43 and b43legacy is NOT that the
> driver is "legacy". It is called legacy because it does _only_ support
> legacy _devices_. So if you hack it to drive a new card it will only
> work by luck (luck as in there might be some code left over which
> is able to initialize the device somehow.). My point being, we removed
> code for new devices from b43legacy and are probably going to remove
> even more stuff in the future. So there is simply no point in testing
> any new device with b43legacy.
>
At the start of my discussion with Larry, I asked if the firmware
could cause such a difference. Larry said no, and I believed him, but
I'm very lost as to what could be causing such a difference between
bcm43xx and b43. I figured it was at least worth testing, I mean, it
wasn't like I was recommending others do the same.
I'm actually still using the b43legacy driver right now, and it really
does work exactly the same as b43. If you're interested, here's the
relevant section of dmesg from when I loaded the b43legacy driver:
ssb: SPROM revision 2 detected.
ssb: Sonics Silicon Backplane found on PCI device 0000:05:00.0
b43legacy-phy1: Broadcom 4311 WLAN found
b43legacy-phy1 debug: Found PHY: Analog 4, Type 2, Revision 8
b43legacy-phy1 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2
b43legacy-phy1 debug: Radio initialized
phy1: Selected rate control algorithm 'simple'
b43legacy-phy1 debug: Loading firmware version 0x127, patch level 14
(2005-04-18 02:36:27)
Registered led device: b43legacy-phy1:tx
Registered led device: b43legacy-phy1:rx
b43legacy-phy1 debug: Chip initialized
b43legacy-phy1 debug: 32-bit DMA initialized
b43legacy-phy1 debug: Wireless interface started
b43legacy-phy1 debug: Adding Interface type 2
wlan0: Initial auth_alg=0
wlan0: authenticate with AP 00:09:5b:70:2d:68
wlan0: RX authentication from 00:09:5b:70:2d:68 (alg=0 transaction=2 status=0)
wlan0: authenticated
wlan0: associate with AP 00:09:5b:70:2d:68
wlan0: RX AssocResp from 00:09:5b:70:2d:68 (capab=0x5 status=0 aid=86)
wlan0: associated
b43legacy-phy1 debug: Removing Interface type 2
b43legacy-phy1 debug: Wireless interface stopped
b43legacy-phy1 debug: DMA-32 0x0200 (RX) max used slots: 1/64
b43legacy-phy1 debug: DMA-32 0x02A0 (TX) max used slots: 0/128
b43legacy-phy1 debug: DMA-32 0x0280 (TX) max used slots: 0/128
b43legacy-phy1 debug: DMA-32 0x0260 (TX) max used slots: 0/128
b43legacy-phy1 debug: DMA-32 0x0240 (TX) max used slots: 0/128
b43legacy-phy1 debug: DMA-32 0x0220 (TX) max used slots: 2/128
b43legacy-phy1 debug: DMA-32 0x0200 (TX) max used slots: 0/128
b43legacy-phy1 debug: Radio initialized
b43legacy-phy1 debug: Radio initialized
b43legacy-phy1 debug: Loading firmware version 0x127, patch level 14
(2005-04-18 02:36:27)
Registered led device: b43legacy-phy1:tx
Registered led device: b43legacy-phy1:rx
b43legacy-phy1 debug: Chip initialized
b43legacy-phy1 debug: 32-bit DMA initialized
b43legacy-phy1 debug: Wireless interface started
b43legacy-phy1 debug: Adding Interface type 2
wlan0: Initial auth_alg=0
wlan0: authenticate with AP 00:09:5b:70:2d:68
wlan0: RX authentication from 00:09:5b:70:2d:68 (alg=0 transaction=2 status=0)
wlan0: authenticated
wlan0: associate with AP 00:09:5b:70:2d:68
wlan0: RX AssocResp from 00:09:5b:70:2d:68 (capab=0x5 status=0 aid=86)
wlan0: associated
wlan0: disassociate(reason=3)
wlan0: Initial auth_alg=0
wlan0: authenticate with AP 00:09:5b:70:2d:68
wlan0: RX authentication from 00:09:5b:70:2d:68 (alg=0 transaction=2 status=0)
wlan0: authenticated
wlan0: associate with AP 00:09:5b:70:2d:68
wlan0: RX ReassocResp from 00:09:5b:70:2d:68 (capab=0x5 status=0 aid=87)
wlan0: associated
[email protected] wrote:
>
> I don't know what happened before, but after a reboot, I can't repeat
> the 200 kB/s speed. It's back down to 40 kB/s, just like originally. I
> didn't move the laptop, or the ap, the only thing I can think of that
> might have changed is the noise level. FWIW, link quality is
> consistently the same or better with b43.
>
> Anyway, I'd noticed before that the bit rate starts at 1 Mb/s and
> quickly scales to 11 Mb/s, but I tried setting it manually anyway and
> didn't see any change. In fact, I set the rate to 5.5 Mb/s as well as
> 1 Mb/s and the download speed was the same with all three (around
> 30-40 kB/s).
I hope that you have now convinced yourself that you should be using b43 and not messing around
forcing b43legacy to use a device for which it was not intended. I left that back door in the code
because I wanted to test b43legacy on a computer that could build a kernel in 20 minutes, as
compared to the 12 hours that my old laptop with the device that needs b43legacy. I forgot to clean
up the code as I should have.
You should concentrate on what in your environment changed when you rebooted. If you can get the 200
kBs rate back, please note the noise and signal levels as compared to the values when you are
restricted to 40 kBs.
Is it possible for you to test your laptop on another AP?
Larry
On Dec 17, 2007 8:16 PM, Larry Finger <[email protected]> wrote:
>
> I hope that you have now convinced yourself that you should be using b43 and not messing around
> forcing b43legacy to use a device for which it was not intended.
>
I was convinced the moment I realized it worked exactly the same as
b43 (if they work the same, I'd rather use the intended driver). The
b43legacy test was more out of desperation than anything serious. I
thought I should share though, since my original question was about
the firmware and because the difference between versions (or lack
thereof) had been discussed in this thread.
> You should concentrate on what in your environment changed when you rebooted. If you can get the 200
> kBs rate back, please note the noise and signal levels as compared to the values when you are
> restricted to 40 kBs.
>
Really, the only thing that might have changed is some things that may
have caused noise were turned off -- in other words, there should have
been more noise with the 200 kB/s, but of course that doesn't make
sense. It should be noted though that even at 200 kB/s, the b43 driver
was operating at less than half the speed of bcm43xx. That being said,
I've been trying very hard to repeat this, but cannot. I'll keep
trying though, and make sure to note everything possible if it ever
happens again.
> Is it possible for you to test your laptop on another AP?
>
Not currently, but I'll try to find a way to do so -- not sure how
long it'll take.
Larry, thanks for being so patient so far. Tomorrow I plan to take my
laptop to somewhere with coffee and a wireless network. For now
though, can you tell me if these messages could be related:
PCI: Cannot allocate resource region 7 of bridge 0000:00:05.0
PCI: Cannot allocate resource region 8 of bridge 0000:00:05.0
or could tsc being marked as unstable have anything to do with the
speed of network transfers?
[email protected] wrote:
> Larry, thanks for being so patient so far. Tomorrow I plan to take my
> laptop to somewhere with coffee and a wireless network. For now
> though, can you tell me if these messages could be related:
> PCI: Cannot allocate resource region 7 of bridge 0000:00:05.0
> PCI: Cannot allocate resource region 8 of bridge 0000:00:05.0
I don't know what these regions are, but I doubt if they have any relation to your problem.
>
> or could tsc being marked as unstable have anything to do with the
> speed of network transfers?
Absolutely not.
Larry
* Michael Buesch <[email protected]> wrote:
> On Wednesday 19 December 2007 09:11:02 Larry Finger wrote:
> > >
> > > or could tsc being marked as unstable have anything to do with the
> > > speed of network transfers?
> >
> > Absolutely not.
>
> Well, if the clocksource of the machine is unstable it _can_ cause all
> kinds of weird things. If you think something is broken in the tsc
> stuff, please switch to using another clocksource.
also, if it gets marked unstable (which is typical on laptops) then the
kernel switches to a more stable, non-TSC clocksource automatically.
(hpet or pit)
Ingo