Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400)

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

 



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).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux