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

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. 

quoted

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>

quoted

In this whole mail you basically only state that:

quoted

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.

quoted

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.