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

Michael Buesch
2007-05-25T14:52:59Z

On Friday 25 May 2007 15:59:49 Uwe Bugla wrote:
> Well if you're so clever in software development then please provide an
> exception handling for the ssb module which is specifically NOT needed by my
> onboard controller, OK?
> Just provide compatibility to non-wireless NICs, i. e. to non-ssb devices.

What are you talking about?

> I think you cannot just bind ssb tightly to b44.c, can you?

You have no clue about how the b44 hardware works, do you?

> In so far the way how ssb is attached is buggy and wrong, apart from the fact
> that my controller is broken, disfunctional.

Please explain in detail how ssb is wrong.

> That's how I understand Andrew Morton's guideline: "Test your patches on three
> different machines before sending them in."
> In so far I do expect that you at least take the effort of testing your stuff
> with a PCI NIC or onboard NIC of the BCM4401 class of NICs before you send
> your stuff in.

> In so far you just cannot delegate the testing to other people before you are
> sending in that stuff.
> That's what Andrew tried to explain to you.

I tested this code on _all_ of my machines. These include:
Big-Endian powerpc machine.
Little-Endian i386 machine.
OpenWRT router device (ssb is capable of booting this device,
with some additional code, which is in the OpenWRT tree).

So, now I count the machines (not that this number matters AT ALL):
One, two, three. Oh, there we go. What a surprise...

> I am convinced that your solution runs on your machine, but the solution that
> you provide looks very rude, doesn't it?

No, explain why.
In fact, it's considered to be a very elegant solution by various
developers who actually have a clue about how the hardware works.
ssb scales from a small MIPS embedded device to real big machines.

> > Please provide more information on the actual _issue_.
>
> Sure, no problem:
>
> 02:05.0 Ethernet controller: Broadcom Corporation BCM4401 100Base-T (rev 01)
> Subsystem: ASUSTeK Computer Inc. A7V8X motherboard
> Flags: bus master, fast devsel, latency 32, IRQ 17
> Memory at f1000000 (32-bit, non-prefetchable) [size=8K]
> Capabilities: <access denied>
>
> >
> > In this whole mail you basically only state that:
> > > IRQ 255 looks very idiotic, doesn't it?
> >
> > Explain that in detail, please. Why do you think it's wrong?
>
> The "traditional" IRQ table provides TWO cascaded blocks of 8 interrupt
> numbers.
> Gives a spectrum from 0 to 15, doesn't it?
>
> The ACPI system enlarges that, and on at least my system the highest interrupt
> number is 21. Now if there were some more cards installed the maximum number
> would perhaps amount to 25.
>
> In so far an IRQ value of 255 looks a bit very very strange, doesn't it?

On your architecture, perhaps. I don't know.

> > Which IRQ number do you get with the old b44 driver?
>
> IRQ 17

Ok, now I show you the code which determines the IRQ number in ssb:

sdev->irq = bus->host_pci->irq;

That's simple, isn't it?
It simply copies the IRQ number from the original PCI device.

I bet your bug is _not_ caused by ssb, but by some other breakage
in another subsystem. Maybe ACPI or APIC is broken? Try to boot
the machine without ACPI and/or APIC.

I just downloaded latest -mm to test it on my machine, but the machine
keeps freezing with that kernel. But I get IRQ 21 for the b44 device.

--
Greetings Michael.