Messages in this thread | | | From | Michael Buesch <> | Subject | Re: BUG in 2.6.22-rc2-mm1: NIC module b44.c broken (Broadcom 4400) | Date | Fri, 25 May 2007 16:52:19 +0200 |
| |
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |