[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200705251652.19911.mb@bu3sch.de>
Date: Fri, 25 May 2007 16:52:19 +0200
From: Michael Buesch <mb@...sch.de>
To: Uwe Bugla <uwe.bugla@....de>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, linux-wireless@...r.kernel.org,
"John W. Linville" <linville@...driver.com>
Subject: 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.
> > 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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists