On Saturday 26 May 2007, Michael Buesch wrote: > On Friday 25 May 2007 21:40, Uwe Bugla wrote: > > Am Freitag, 25. Mai 2007 20:48 schrieben Sie: > > > On Fri, 25 May 2007 17:59:29 +0200, Uwe Bugla wrote: > > > > Perhaps someone reading this could try to reproduce that problem on > > > > his machine. > > > > Now who of the readers owes a Broadcom 4401 NIC and can please try to > > > > test kernel 2.6.22-rc2-mm1? > > > > > > > > Those NICs have been used very very often as onboard controllers, > > > > especially on ASUS boards. > > > > > > I've been using 2.6.22-rc2 for some time and now I compiled 2.6.22-rc2- > > > mm1 and both work fine with the BCM4401 in my laptop. > > > > > > Maxi > > > > Hello Maxi, > > > > That may be true for your Laptop, but it unfortunately isn't true for my > > ASUS mainboard onboard controller. > > > > Unfortunately I cannot confirm this: > > > > My broadcom 4401 driver is not part of a notebook, but instead part of an > > ASUS P4PE mainboard. > > > > At my second attempt I went the conventional path (i. e. ignoring the > > fact that > > "Broadcom 4400 ethernet support appears twice in section "Network device > > support": > > > > Whether you leave out "EISA, VLB, PCI and on board controllers" or not it > > simply appears twice in kernel config! This is bug number 1. > > No it is NOT a bug. > It simply shows again that you don't know how b44, ssb or anything related > works. > > Would you _please_ take a look at the code, before calling features bugs. > And yes, this IS a feature. It is a feature to get b44 running on an > OpenWRT embedded device. These devices don't have a PCI bus. So b44 MUST > NOT depend on "EISA, VLB, PCI and on board controllers". > "Broadcom 4400 PCI device support" does depend on "EISA, VLB, PCI and on > board controllers". > > Everything is correct. > Bug number 1 is solved. > qed > > > This time I do get a "good" interrupt: IRQ 21 for the the device. > > > > BUT: > > > > Trying to ping another machine fails saying: > > > > "destination host unreachable" > > > > > > That means, Although the interrupt is fine now, the device is still not > > functionable. > > And it's completely impossible that you did a mistake when configuring > the device? Typo in the IP? Typo in the gateway or DNS entries? > Try it again, please. > And please try with current wireless-dev tree. > > And I simply do not get it why you suddenly get a good IRQ number, like > everybody else does, without fixing The Bug (tm). I did run my 2.6.22-rc2-mm1 kernel a bit longer and noticed that I was wrong in my first mail. The driver does work with my 4401 and network traffic seem to get out and in fine, but it has huge performance problems. If I do some pings and traceroutes I sometimes get response times of only a few ms but I also get times of a few seconds. Also trying to play games is totally impossible. This doesn't happen with 2.6.22-rc2 and 2.6.22-rc3. Maxi
Attachment:
signature.asc
Description: This is a digitally signed message part.
- References:
- BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
- From: "Uwe Bugla" <[email protected]>
- Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
- From: Uwe Bugla <[email protected]>
- Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
- From: Michael Buesch <[email protected]>
- BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
- Prev by Date: Re: fs periodic check (was Re: 2.6.22-rc1 killed my ext3 filesystem cleanly unmounted)
- Next by Date: Re: software suspend doesn't work with 2.6.22-rc3
- Previous by thread: Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
- Next by thread: Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)
- Index(es):