On Thu, 24 May 2007 21:56:16 +0200
"Uwe Bugla" <[email protected]> wrote:
> Hi everybody,
(added linux-wireless, others)
> The patch against b44.c contained in 2.6.22-rc2-mm1 has two consequences:
>
> 1. a tight binding to module ssb whose function or necessity I neither see through nor do comprehend
>
> 2. a breakdown (disfunctionality) of my onboard NIC.
>
> lspci -v looks like this:
>
> 00:00.0 Host bridge: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE DRAM Controller/Host-Hub Interface (rev 02)
> Subsystem: ASUSTeK Computer Inc. Unknown device 80b2
> Flags: bus master, fast devsel, latency 0
> Memory at f8000000 (32-bit, prefetchable) [size=64M]
> Capabilities: [e4] Vendor Specific Information
> Capabilities: [a0] AGP version 2.0
>
> 00:01.0 PCI bridge: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE Host-to-AGP Bridge (rev 02) (prog-if 00 [Normal decode])
> Flags: bus master, 66MHz, fast devsel, latency 64
> Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
> I/O behind bridge: 0000d000-0000dfff
> Memory behind bridge: f2000000-f27fffff
> Prefetchable memory behind bridge: f3f00000-f7ffffff
>
> 00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 02) (prog-if 00 [UHCI])
> Subsystem: ASUSTeK Computer Inc. Unknown device 8089
> Flags: bus master, medium devsel, latency 0, IRQ 17
> I/O ports at b800 [size=32]
>
> 00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 02) (prog-if 00 [UHCI])
> Subsystem: ASUSTeK Computer Inc. Unknown device 8089
> Flags: bus master, medium devsel, latency 0, IRQ 20
> I/O ports at b400 [size=32]
>
> 00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 02) (prog-if 00 [UHCI])
> Subsystem: ASUSTeK Computer Inc. Unknown device 8089
> Flags: bus master, medium devsel, latency 0, IRQ 16
> I/O ports at b000 [size=32]
>
> 00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 02) (prog-if 20 [EHCI])
> Subsystem: ASUSTeK Computer Inc. Unknown device 8089
> Flags: bus master, medium devsel, latency 0, IRQ 18
> Memory at f1800000 (32-bit, non-prefetchable) [size=1K]
> Capabilities: [50] Power Management version 2
> Capabilities: [58] Debug port
>
> 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 82) (prog-if 00 [Normal decode])
> Flags: bus master, fast devsel, latency 0
> Bus: primary=00, secondary=02, subordinate=02, sec-latency=32
> Memory behind bridge: f1000000-f17fffff
> Prefetchable memory behind bridge: f2800000-f3efffff
>
> 00:1f.0 ISA bridge: Intel Corporation 82801DB/DBL (ICH4/ICH4-L) LPC Interface Bridge (rev 02)
> Flags: bus master, medium devsel, latency 0
>
> 00:1f.1 IDE interface: Intel Corporation 82801DB (ICH4) IDE Controller (rev 02) (prog-if 8a [Master SecP PriP])
> Subsystem: ASUSTeK Computer Inc. Unknown device 8089
> Flags: bus master, medium devsel, latency 0, IRQ 16
> I/O ports at 01f0 [size=8]
> I/O ports at 03f4 [size=1]
> I/O ports at 0170 [size=8]
> I/O ports at 0374 [size=1]
> I/O ports at f000 [size=16]
> Memory at 30000000 (32-bit, non-prefetchable) [size=1K]
>
> 00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 02)
> Subsystem: ASUSTeK Computer Inc. Unknown device 8089
> Flags: medium devsel, IRQ 19
> I/O ports at e800 [size=32]
>
> 00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 02)
> Subsystem: ASUSTeK Computer Inc. Unknown device 80b0
> Flags: bus master, medium devsel, latency 0, IRQ 19
> I/O ports at a800 [size=256]
> I/O ports at a400 [size=64]
> Memory at f0800000 (32-bit, non-prefetchable) [size=512]
> Memory at f0000000 (32-bit, non-prefetchable) [size=256]
> Capabilities: [50] Power Management version 2
>
> 01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 PF/PRO AGP 4x TMDS (prog-if 00 [VGA])
> Subsystem: ATI Technologies Inc Rage Fury Pro/Xpert 2000 Pro
> Flags: bus master, stepping, 66MHz, medium devsel, latency 64, IRQ 17
> Memory at f4000000 (32-bit, prefetchable) [size=64M]
> I/O ports at d800 [size=256]
> Memory at f2000000 (32-bit, non-prefetchable) [size=16K]
> Expansion ROM at f3fe0000 [disabled] [size=128K]
> Capabilities: [50] AGP version 2.0
> Capabilities: [5c] Power Management version 2
>
> 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 255
> Memory at f1000000 (32-bit, non-prefetchable) [disabled] [size=8K]
> Capabilities: [40] Power Management version 2
>
> 02:0b.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11)
> Subsystem: Pinnacle Systems Inc. PCTV Sat (DBC receiver)
> Flags: bus master, medium devsel, latency 32, IRQ 18
> Memory at f3000000 (32-bit, prefetchable) [size=4K]
> Capabilities: [44] Vital Product Data
> Capabilities: [4c] Power Management version 2
>
> 02:0b.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11)
> Subsystem: Pinnacle Systems Inc. PCTV Sat (DBC receiver)
> Flags: bus master, medium devsel, latency 32, IRQ 18
> Memory at f2800000 (32-bit, prefetchable) [size=4K]
> Capabilities: [44] Vital Product Data
> Capabilities: [4c] Power Management version 2
>
> Please note:
>
> 1. IRQ 255 looks very idiotic, doesn't it? It does not exist at all, does it?
>
> Questions:
>
> 1. What is the technical need / progress of module ssb please?
>
> 2. If Andrew Morton's guidelines clearly say: "Do test your patches on three different machines" and this guideline seems to be strictly ignored by some sparetime hackers:
>
> What is the master plan then to avoid the fact that such a crap is being sent in to Andrew?
>
> Yours sincerely
>
> Uwe
>
> P. S.: There is an important saying going like this:
>
> Too many cooks do mess up the pap.
>
> Regarding the patch in mm-tree I can see SIX (!) Copyright owners.
> The last one of them (i. e. the one of 2007) obviuosly does not seem to understand what he is doing (see that nonsense interrupt please, just incredible!) :(
>
> In so far I would deeply appreciate Andrew Morton to throw that b44.c patch into the trashbox as soon as possible :)
>
The code presumably worked for the developer. The reason for merging it
into -mm is to allow others to identify problems such as these before the
code hits mainline.
Having bugs in -mm is normal, natural and expected. What I _do_ very much
prefer to see is that these bugs get fixed promptly and, critically, that
the code doesn't go into Linus's tree until all the known bugs are
repaired.
Also, it's really bad when a bug makes the entire -mm release unusable for
testers. Because this means that all the _other_ people who have code
being tested in -mm just lost a tester. And it can cause people to just
not bother testing -mm kernels at all, which means that more badness will
get into mainline.
On Friday 25 May 2007 17:59:29 Uwe Bugla wrote:
> Am Freitag, 25. Mai 2007 16:52 schrieben Sie:
> > 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?
>
> First of all, what is an ssb device please? AFAICS it looks like an extension
> of b44.c as far as module selection is concerned in kernel configuration.
>
> What it's function / purpose?
> Does its function / purpose apply to every platform?
The Sonics Silicon Backplane (ssb) is _part_ of the b44 device.
It ALWAYS has been.
In earlier drivers the ssb code was included in the b44 driver.
> >
> > > 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?
>
> Should I? My broadcom 4401 is broken, but only in that specific mm1-tree.
> It's not broken in 2.6.22-rc2 for instance. So that's your patch that breaks
> it.
I doubt that very much.
In the wireless-dev tree, which includes the _exactly_ same ssb abd b44
version as -mm, it works fine. I just verified this.
I'm almost 100% sure that your kernel is broken in a completely different
way unrelated to ssb.
In the initial mail you said that the IRQ output of lspci says that
the IRQ was 255? If lspci is really saying IRQ 255 this is _NOT_ a ssb
bug, but some bug in either the PCI subsystem or some other IRQ related
subsystem (APIC, ACPI or something else).
> > > 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.
>
> I do not state that ssb is wrong, but I state that the ATTACHMENT of ssb to
> b44.c is wrong. That's a big difference.
> In all earlier kernels that b44 device has been fine, and ssb has never been
> seen.
The ssb code was included in the b44 driver module.
> > So, now I count the machines (not that this number matters AT ALL):
> > One, two, three. Oh, there we go. What a surprise...
>
> Nice for you, but on my machine it is broken, the broadcom 4401 onboard NIC
> controller is unusable.
And you are not even TRYING to resolve it.
What should I do, in your opinion?? It works for me. W.t.f. should I do?
> Do you mean to build a kernel without any ACPI functions?
There are kernel commandline options for this.
I think (don't remember 100%) they are noapic and noacpi
--
Greetings Michael.
On Thursday 24 May 2007 22:06:59 Andrew Morton wrote:
> On Thu, 24 May 2007 21:56:16 +0200
> "Uwe Bugla" <[email protected]> wrote:
>
> > Hi everybody,
>
> (added linux-wireless, others)
>
> > The patch against b44.c contained in 2.6.22-rc2-mm1 has two consequences:
> >
> > 1. a tight binding to module ssb whose function or necessity I neither see through nor do comprehend
> >
> > 2. a breakdown (disfunctionality) of my onboard NIC.
> >
> > lspci -v looks like this:
> >
> > 00:00.0 Host bridge: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE DRAM Controller/Host-Hub Interface (rev 02)
> > Subsystem: ASUSTeK Computer Inc. Unknown device 80b2
> > Flags: bus master, fast devsel, latency 0
> > Memory at f8000000 (32-bit, prefetchable) [size=64M]
> > Capabilities: [e4] Vendor Specific Information
> > Capabilities: [a0] AGP version 2.0
> >
> > 00:01.0 PCI bridge: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE Host-to-AGP Bridge (rev 02) (prog-if 00 [Normal decode])
> > Flags: bus master, 66MHz, fast devsel, latency 64
> > Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
> > I/O behind bridge: 0000d000-0000dfff
> > Memory behind bridge: f2000000-f27fffff
> > Prefetchable memory behind bridge: f3f00000-f7ffffff
> >
> > 00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 02) (prog-if 00 [UHCI])
> > Subsystem: ASUSTeK Computer Inc. Unknown device 8089
> > Flags: bus master, medium devsel, latency 0, IRQ 17
> > I/O ports at b800 [size=32]
> >
> > 00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 02) (prog-if 00 [UHCI])
> > Subsystem: ASUSTeK Computer Inc. Unknown device 8089
> > Flags: bus master, medium devsel, latency 0, IRQ 20
> > I/O ports at b400 [size=32]
> >
> > 00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 02) (prog-if 00 [UHCI])
> > Subsystem: ASUSTeK Computer Inc. Unknown device 8089
> > Flags: bus master, medium devsel, latency 0, IRQ 16
> > I/O ports at b000 [size=32]
> >
> > 00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 02) (prog-if 20 [EHCI])
> > Subsystem: ASUSTeK Computer Inc. Unknown device 8089
> > Flags: bus master, medium devsel, latency 0, IRQ 18
> > Memory at f1800000 (32-bit, non-prefetchable) [size=1K]
> > Capabilities: [50] Power Management version 2
> > Capabilities: [58] Debug port
> >
> > 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 82) (prog-if 00 [Normal decode])
> > Flags: bus master, fast devsel, latency 0
> > Bus: primary=00, secondary=02, subordinate=02, sec-latency=32
> > Memory behind bridge: f1000000-f17fffff
> > Prefetchable memory behind bridge: f2800000-f3efffff
> >
> > 00:1f.0 ISA bridge: Intel Corporation 82801DB/DBL (ICH4/ICH4-L) LPC Interface Bridge (rev 02)
> > Flags: bus master, medium devsel, latency 0
> >
> > 00:1f.1 IDE interface: Intel Corporation 82801DB (ICH4) IDE Controller (rev 02) (prog-if 8a [Master SecP PriP])
> > Subsystem: ASUSTeK Computer Inc. Unknown device 8089
> > Flags: bus master, medium devsel, latency 0, IRQ 16
> > I/O ports at 01f0 [size=8]
> > I/O ports at 03f4 [size=1]
> > I/O ports at 0170 [size=8]
> > I/O ports at 0374 [size=1]
> > I/O ports at f000 [size=16]
> > Memory at 30000000 (32-bit, non-prefetchable) [size=1K]
> >
> > 00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 02)
> > Subsystem: ASUSTeK Computer Inc. Unknown device 8089
> > Flags: medium devsel, IRQ 19
> > I/O ports at e800 [size=32]
> >
> > 00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 02)
> > Subsystem: ASUSTeK Computer Inc. Unknown device 80b0
> > Flags: bus master, medium devsel, latency 0, IRQ 19
> > I/O ports at a800 [size=256]
> > I/O ports at a400 [size=64]
> > Memory at f0800000 (32-bit, non-prefetchable) [size=512]
> > Memory at f0000000 (32-bit, non-prefetchable) [size=256]
> > Capabilities: [50] Power Management version 2
> >
> > 01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 PF/PRO AGP 4x TMDS (prog-if 00 [VGA])
> > Subsystem: ATI Technologies Inc Rage Fury Pro/Xpert 2000 Pro
> > Flags: bus master, stepping, 66MHz, medium devsel, latency 64, IRQ 17
> > Memory at f4000000 (32-bit, prefetchable) [size=64M]
> > I/O ports at d800 [size=256]
> > Memory at f2000000 (32-bit, non-prefetchable) [size=16K]
> > Expansion ROM at f3fe0000 [disabled] [size=128K]
> > Capabilities: [50] AGP version 2.0
> > Capabilities: [5c] Power Management version 2
> >
> > 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 255
> > Memory at f1000000 (32-bit, non-prefetchable) [disabled] [size=8K]
> > Capabilities: [40] Power Management version 2
> >
> > 02:0b.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11)
> > Subsystem: Pinnacle Systems Inc. PCTV Sat (DBC receiver)
> > Flags: bus master, medium devsel, latency 32, IRQ 18
> > Memory at f3000000 (32-bit, prefetchable) [size=4K]
> > Capabilities: [44] Vital Product Data
> > Capabilities: [4c] Power Management version 2
> >
> > 02:0b.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11)
> > Subsystem: Pinnacle Systems Inc. PCTV Sat (DBC receiver)
> > Flags: bus master, medium devsel, latency 32, IRQ 18
> > Memory at f2800000 (32-bit, prefetchable) [size=4K]
> > Capabilities: [44] Vital Product Data
> > Capabilities: [4c] Power Management version 2
> >
> > Please note:
> >
> > 1. IRQ 255 looks very idiotic, doesn't it? It does not exist at all, does it?
> >
> > Questions:
> >
> > 1. What is the technical need / progress of module ssb please?
> >
> > 2. If Andrew Morton's guidelines clearly say: "Do test your patches on three different machines" and this guideline seems to be strictly ignored by some sparetime hackers:
> >
> > What is the master plan then to avoid the fact that such a crap is being sent in to Andrew?
> >
> > Yours sincerely
> >
> > Uwe
> >
> > P. S.: There is an important saying going like this:
> >
> > Too many cooks do mess up the pap.
> >
> > Regarding the patch in mm-tree I can see SIX (!) Copyright owners.
> > The last one of them (i. e. the one of 2007) obviuosly does not seem to understand what he is doing (see that nonsense interrupt please, just incredible!) :(
> >
> > In so far I would deeply appreciate Andrew Morton to throw that b44.c patch into the trashbox as soon as possible :)
> >
>
> The code presumably worked for the developer. The reason for merging it
> into -mm is to allow others to identify problems such as these before the
> code hits mainline.
>
> Having bugs in -mm is normal, natural and expected. What I _do_ very much
> prefer to see is that these bugs get fixed promptly and, critically, that
> the code doesn't go into Linus's tree until all the known bugs are
> repaired.
>
> Also, it's really bad when a bug makes the entire -mm release unusable for
> testers. Because this means that all the _other_ people who have code
> being tested in -mm just lost a tester. And it can cause people to just
> not bother testing -mm kernels at all, which means that more badness will
> get into mainline.
You are talking a _lot_ of bullshit, and I'd really like to tell
you to fuck off, because you have no clue how software development works.
But I (as the primary developer of ssb) like to resolve the issue, too.
Please provide more information on the actual _issue_.
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?
Which IRQ number do you get with the old b44 driver?
Thanks for your testing. That is why -mm exists.
Next time without bullshitting, please.
--
Greetings Michael.
Am Donnerstag, 24. Mai 2007 22:06 schrieben Sie:
> On Thu, 24 May 2007 21:56:16 +0200
>
> "Uwe Bugla" <[email protected]> wrote:
> > Hi everybody,
>
> (added linux-wireless, others)
>
> > The patch against b44.c contained in 2.6.22-rc2-mm1 has two consequences:
> >
> > 1. a tight binding to module ssb whose function or necessity I neither
> > see through nor do comprehend
> >
> > 2. a breakdown (disfunctionality) of my onboard NIC.
> >
> > lspci -v looks like this:
> >
> > 00:00.0 Host bridge: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE DRAM
> > Controller/Host-Hub Interface (rev 02) Subsystem: ASUSTeK Computer Inc.
> > Unknown device 80b2
> > Flags: bus master, fast devsel, latency 0
> > Memory at f8000000 (32-bit, prefetchable) [size=64M]
> > Capabilities: [e4] Vendor Specific Information
> > Capabilities: [a0] AGP version 2.0
> >
> > 00:01.0 PCI bridge: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE
> > Host-to-AGP Bridge (rev 02) (prog-if 00 [Normal decode]) Flags: bus
> > master, 66MHz, fast devsel, latency 64
> > Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
> > I/O behind bridge: 0000d000-0000dfff
> > Memory behind bridge: f2000000-f27fffff
> > Prefetchable memory behind bridge: f3f00000-f7ffffff
> >
> > 00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM
> > (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 02) (prog-if 00 [UHCI])
> > Subsystem: ASUSTeK Computer Inc. Unknown device 8089
> > Flags: bus master, medium devsel, latency 0, IRQ 17
> > I/O ports at b800 [size=32]
> >
> > 00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM
> > (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 02) (prog-if 00 [UHCI])
> > Subsystem: ASUSTeK Computer Inc. Unknown device 8089
> > Flags: bus master, medium devsel, latency 0, IRQ 20
> > I/O ports at b400 [size=32]
> >
> > 00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM
> > (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 02) (prog-if 00 [UHCI])
> > Subsystem: ASUSTeK Computer Inc. Unknown device 8089
> > Flags: bus master, medium devsel, latency 0, IRQ 16
> > I/O ports at b000 [size=32]
> >
> > 00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2
> > EHCI Controller (rev 02) (prog-if 20 [EHCI]) Subsystem: ASUSTeK Computer
> > Inc. Unknown device 8089
> > Flags: bus master, medium devsel, latency 0, IRQ 18
> > Memory at f1800000 (32-bit, non-prefetchable) [size=1K]
> > Capabilities: [50] Power Management version 2
> > Capabilities: [58] Debug port
> >
> > 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 82) (prog-if
> > 00 [Normal decode]) Flags: bus master, fast devsel, latency 0
> > Bus: primary=00, secondary=02, subordinate=02, sec-latency=32
> > Memory behind bridge: f1000000-f17fffff
> > Prefetchable memory behind bridge: f2800000-f3efffff
> >
> > 00:1f.0 ISA bridge: Intel Corporation 82801DB/DBL (ICH4/ICH4-L) LPC
> > Interface Bridge (rev 02) Flags: bus master, medium devsel, latency 0
> >
> > 00:1f.1 IDE interface: Intel Corporation 82801DB (ICH4) IDE Controller
> > (rev 02) (prog-if 8a [Master SecP PriP]) Subsystem: ASUSTeK Computer Inc.
> > Unknown device 8089
> > Flags: bus master, medium devsel, latency 0, IRQ 16
> > I/O ports at 01f0 [size=8]
> > I/O ports at 03f4 [size=1]
> > I/O ports at 0170 [size=8]
> > I/O ports at 0374 [size=1]
> > I/O ports at f000 [size=16]
> > Memory at 30000000 (32-bit, non-prefetchable) [size=1K]
> >
> > 00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M)
> > SMBus Controller (rev 02) Subsystem: ASUSTeK Computer Inc. Unknown device
> > 8089
> > Flags: medium devsel, IRQ 19
> > I/O ports at e800 [size=32]
> >
> > 00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM
> > (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 02) Subsystem: ASUSTeK
> > Computer Inc. Unknown device 80b0
> > Flags: bus master, medium devsel, latency 0, IRQ 19
> > I/O ports at a800 [size=256]
> > I/O ports at a400 [size=64]
> > Memory at f0800000 (32-bit, non-prefetchable) [size=512]
> > Memory at f0000000 (32-bit, non-prefetchable) [size=256]
> > Capabilities: [50] Power Management version 2
> >
> > 01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 PF/PRO
> > AGP 4x TMDS (prog-if 00 [VGA]) Subsystem: ATI Technologies Inc Rage Fury
> > Pro/Xpert 2000 Pro
> > Flags: bus master, stepping, 66MHz, medium devsel, latency 64, IRQ 17
> > Memory at f4000000 (32-bit, prefetchable) [size=64M]
> > I/O ports at d800 [size=256]
> > Memory at f2000000 (32-bit, non-prefetchable) [size=16K]
> > Expansion ROM at f3fe0000 [disabled] [size=128K]
> > Capabilities: [50] AGP version 2.0
> > Capabilities: [5c] Power Management version 2
> >
> > 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 255
> > Memory at f1000000 (32-bit, non-prefetchable) [disabled] [size=8K]
> > Capabilities: [40] Power Management version 2
> >
> > 02:0b.0 Multimedia video controller: Brooktree Corporation Bt878 Video
> > Capture (rev 11) Subsystem: Pinnacle Systems Inc. PCTV Sat (DBC receiver)
> > Flags: bus master, medium devsel, latency 32, IRQ 18
> > Memory at f3000000 (32-bit, prefetchable) [size=4K]
> > Capabilities: [44] Vital Product Data
> > Capabilities: [4c] Power Management version 2
> >
> > 02:0b.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture
> > (rev 11) Subsystem: Pinnacle Systems Inc. PCTV Sat (DBC receiver)
> > Flags: bus master, medium devsel, latency 32, IRQ 18
> > Memory at f2800000 (32-bit, prefetchable) [size=4K]
> > Capabilities: [44] Vital Product Data
> > Capabilities: [4c] Power Management version 2
> >
> > Please note:
> >
> > 1. IRQ 255 looks very idiotic, doesn't it? It does not exist at all, does
> > it?
> >
> > Questions:
> >
> > 1. What is the technical need / progress of module ssb please?
> >
> > 2. If Andrew Morton's guidelines clearly say: "Do test your patches on
> > three different machines" and this guideline seems to be strictly ignored
> > by some sparetime hackers:
> >
> > What is the master plan then to avoid the fact that such a crap is being
> > sent in to Andrew?
> >
> > Yours sincerely
> >
> > Uwe
> >
> > P. S.: There is an important saying going like this:
> >
> > Too many cooks do mess up the pap.
> >
> > Regarding the patch in mm-tree I can see SIX (!) Copyright owners.
> > The last one of them (i. e. the one of 2007) obviuosly does not seem to
> > understand what he is doing (see that nonsense interrupt please, just
> > incredible!) :(
> >
> > In so far I would deeply appreciate Andrew Morton to throw that b44.c
> > patch into the trashbox as soon as possible :)
>
> The code presumably worked for the developer. The reason for merging it
> into -mm is to allow others to identify problems such as these before the
> code hits mainline.
I am inclined to agree. But the obvious absence of knowledge about the PCI
interrupt table or perhaps the ACPI issue is really harsh, isn't it? (IRQ
255!!)
Above that, the commiter DID IGNORE your baselines of testing, but at the same
time got highly profile-neurotic regarding the copyright issue of 2007,
didn't he (Let's call this a basic instinct of our precedents: the apes:
shouting: I, I, I, more, more, more)?
>
> Having bugs in -mm is normal, natural and expected. What I _do_ very much
> prefer to see is that these bugs get fixed promptly and, critically, that
> the code doesn't go into Linus's tree until all the known bugs are
> repaired.
I do agree and I do confirm to that, as it makes deep sense.
>
> Also, it's really bad when a bug makes the entire -mm release unusable for
> testers. Because this means that all the _other_ people who have code
> being tested in -mm just lost a tester. And it can cause people to just
> not bother testing -mm kernels at all, which means that more badness will
> get into mainline.
You do response positive, and I thank you for that. Well done, Andrew! :)
But, apart from that, I am still hosting (or forking, if you may wish) a
couple of patches for the v4l-dvb area that do touch about seven files,
trying to make at least my system more effective (small is beautiful, isn't
it?).
Now, one of them will be part of the next mm-tree, while the future of all the
other ones is more than unclear or invisible.
And I have not been hosting those since yesterday but in fact I have been
hosting them for weeks and for months now.
And this situation is nothing but the product of some personal issues with
exactly FOUR (!) v4l-dvb-developers involved, who, due to their borders of
knowledge which they cannot and will not deal with in a constructive open
positive manner, seem to have lost every kind of touch to mother earth (I do
avoid to use the expression "responsibility", as it has been proven to be
senseless to tell them in the past).
In other words: The ego ellbow issues do rule and thus do block every kind of
constructive evolution that everyone would deeply appreciate.
More clear: You see at linuxtv.org a repository of 20 (!) developers, but
they neither do nor intend to be a functionable team :(
And one of them tries to solve that by playing the "big boss" without having
absolutely no idea about DVB issues at all.
PLUS: Nowhere in the worldwide linux community outside the v4l-dvb microcosmos
the situation is such disagreeable and ellbow-ego-issued (if not to say:
disgusting and counterproductive and simply discouraging) as at linuxtv.org!
Now, even if you offered me to post the other patches for testing reasons to
be implied into the mm-tree I can foresee the NACK of Manu Abraham or Mauro
Chehab, without expalining the what and why!
That does not mean that we should not try one more time to at least get them
into the mm-tree (which I would regard as positive attempt, definitely!), but
that only means that I am, proven by experience, more than hopeless, if not
to say: pessimistic! :(
And that's it definitely what they seem to want:
Keep on doing their ellbow-egoistic policy, without any criticism or critical
objections!
Andrew, would you call that situation acceptable or agreeable?
My answer you can easily guess!
I do detest people adding their copyrights into code of whatever kind, but, at
the same time, producing absolutely nothing but broken crap!
Those people are not, and will never be, a positive impact for the whole
worldwide linux community.
Basta!
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.
On Friday 25 May 2007 15:12:09 Michael Buesch wrote:
> On Thursday 24 May 2007 22:06:59 Andrew Morton wrote:
> > On Thu, 24 May 2007 21:56:16 +0200
> > "Uwe Bugla" <[email protected]> wrote:
> >
> > > Hi everybody,
> >
> > (added linux-wireless, others)
> >
> > > The patch against b44.c contained in 2.6.22-rc2-mm1 has two consequences:
> > >
> > > 1. a tight binding to module ssb whose function or necessity I neither see through nor do comprehend
> > >
> > > 2. a breakdown (disfunctionality) of my onboard NIC.
> > >
> > > lspci -v looks like this:
> > >
> > > 00:00.0 Host bridge: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE DRAM Controller/Host-Hub Interface (rev 02)
> > > Subsystem: ASUSTeK Computer Inc. Unknown device 80b2
> > > Flags: bus master, fast devsel, latency 0
> > > Memory at f8000000 (32-bit, prefetchable) [size=64M]
> > > Capabilities: [e4] Vendor Specific Information
> > > Capabilities: [a0] AGP version 2.0
> > >
> > > 00:01.0 PCI bridge: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE Host-to-AGP Bridge (rev 02) (prog-if 00 [Normal decode])
> > > Flags: bus master, 66MHz, fast devsel, latency 64
> > > Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
> > > I/O behind bridge: 0000d000-0000dfff
> > > Memory behind bridge: f2000000-f27fffff
> > > Prefetchable memory behind bridge: f3f00000-f7ffffff
> > >
> > > 00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 02) (prog-if 00 [UHCI])
> > > Subsystem: ASUSTeK Computer Inc. Unknown device 8089
> > > Flags: bus master, medium devsel, latency 0, IRQ 17
> > > I/O ports at b800 [size=32]
> > >
> > > 00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 02) (prog-if 00 [UHCI])
> > > Subsystem: ASUSTeK Computer Inc. Unknown device 8089
> > > Flags: bus master, medium devsel, latency 0, IRQ 20
> > > I/O ports at b400 [size=32]
> > >
> > > 00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 02) (prog-if 00 [UHCI])
> > > Subsystem: ASUSTeK Computer Inc. Unknown device 8089
> > > Flags: bus master, medium devsel, latency 0, IRQ 16
> > > I/O ports at b000 [size=32]
> > >
> > > 00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 02) (prog-if 20 [EHCI])
> > > Subsystem: ASUSTeK Computer Inc. Unknown device 8089
> > > Flags: bus master, medium devsel, latency 0, IRQ 18
> > > Memory at f1800000 (32-bit, non-prefetchable) [size=1K]
> > > Capabilities: [50] Power Management version 2
> > > Capabilities: [58] Debug port
> > >
> > > 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 82) (prog-if 00 [Normal decode])
> > > Flags: bus master, fast devsel, latency 0
> > > Bus: primary=00, secondary=02, subordinate=02, sec-latency=32
> > > Memory behind bridge: f1000000-f17fffff
> > > Prefetchable memory behind bridge: f2800000-f3efffff
> > >
> > > 00:1f.0 ISA bridge: Intel Corporation 82801DB/DBL (ICH4/ICH4-L) LPC Interface Bridge (rev 02)
> > > Flags: bus master, medium devsel, latency 0
> > >
> > > 00:1f.1 IDE interface: Intel Corporation 82801DB (ICH4) IDE Controller (rev 02) (prog-if 8a [Master SecP PriP])
> > > Subsystem: ASUSTeK Computer Inc. Unknown device 8089
> > > Flags: bus master, medium devsel, latency 0, IRQ 16
> > > I/O ports at 01f0 [size=8]
> > > I/O ports at 03f4 [size=1]
> > > I/O ports at 0170 [size=8]
> > > I/O ports at 0374 [size=1]
> > > I/O ports at f000 [size=16]
> > > Memory at 30000000 (32-bit, non-prefetchable) [size=1K]
> > >
> > > 00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 02)
> > > Subsystem: ASUSTeK Computer Inc. Unknown device 8089
> > > Flags: medium devsel, IRQ 19
> > > I/O ports at e800 [size=32]
> > >
> > > 00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 02)
> > > Subsystem: ASUSTeK Computer Inc. Unknown device 80b0
> > > Flags: bus master, medium devsel, latency 0, IRQ 19
> > > I/O ports at a800 [size=256]
> > > I/O ports at a400 [size=64]
> > > Memory at f0800000 (32-bit, non-prefetchable) [size=512]
> > > Memory at f0000000 (32-bit, non-prefetchable) [size=256]
> > > Capabilities: [50] Power Management version 2
> > >
> > > 01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 PF/PRO AGP 4x TMDS (prog-if 00 [VGA])
> > > Subsystem: ATI Technologies Inc Rage Fury Pro/Xpert 2000 Pro
> > > Flags: bus master, stepping, 66MHz, medium devsel, latency 64, IRQ 17
> > > Memory at f4000000 (32-bit, prefetchable) [size=64M]
> > > I/O ports at d800 [size=256]
> > > Memory at f2000000 (32-bit, non-prefetchable) [size=16K]
> > > Expansion ROM at f3fe0000 [disabled] [size=128K]
> > > Capabilities: [50] AGP version 2.0
> > > Capabilities: [5c] Power Management version 2
> > >
> > > 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 255
> > > Memory at f1000000 (32-bit, non-prefetchable) [disabled] [size=8K]
> > > Capabilities: [40] Power Management version 2
> > >
> > > 02:0b.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11)
> > > Subsystem: Pinnacle Systems Inc. PCTV Sat (DBC receiver)
> > > Flags: bus master, medium devsel, latency 32, IRQ 18
> > > Memory at f3000000 (32-bit, prefetchable) [size=4K]
> > > Capabilities: [44] Vital Product Data
> > > Capabilities: [4c] Power Management version 2
> > >
> > > 02:0b.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11)
> > > Subsystem: Pinnacle Systems Inc. PCTV Sat (DBC receiver)
> > > Flags: bus master, medium devsel, latency 32, IRQ 18
> > > Memory at f2800000 (32-bit, prefetchable) [size=4K]
> > > Capabilities: [44] Vital Product Data
> > > Capabilities: [4c] Power Management version 2
> > >
> > > Please note:
> > >
> > > 1. IRQ 255 looks very idiotic, doesn't it? It does not exist at all, does it?
> > >
> > > Questions:
> > >
> > > 1. What is the technical need / progress of module ssb please?
> > >
> > > 2. If Andrew Morton's guidelines clearly say: "Do test your patches on three different machines" and this guideline seems to be strictly ignored by some sparetime hackers:
> > >
> > > What is the master plan then to avoid the fact that such a crap is being sent in to Andrew?
> > >
> > > Yours sincerely
> > >
> > > Uwe
> > >
> > > P. S.: There is an important saying going like this:
> > >
> > > Too many cooks do mess up the pap.
> > >
> > > Regarding the patch in mm-tree I can see SIX (!) Copyright owners.
> > > The last one of them (i. e. the one of 2007) obviuosly does not seem to understand what he is doing (see that nonsense interrupt please, just incredible!) :(
> > >
> > > In so far I would deeply appreciate Andrew Morton to throw that b44.c patch into the trashbox as soon as possible :)
> > >
> >
> > The code presumably worked for the developer. The reason for merging it
> > into -mm is to allow others to identify problems such as these before the
> > code hits mainline.
> >
> > Having bugs in -mm is normal, natural and expected. What I _do_ very much
> > prefer to see is that these bugs get fixed promptly and, critically, that
> > the code doesn't go into Linus's tree until all the known bugs are
> > repaired.
> >
> > Also, it's really bad when a bug makes the entire -mm release unusable for
> > testers. Because this means that all the _other_ people who have code
> > being tested in -mm just lost a tester. And it can cause people to just
> > not bother testing -mm kernels at all, which means that more badness will
> > get into mainline.
>
> You are talking a _lot_ of bullshit, and I'd really like to tell
> you to fuck off, because you have no clue how software development works.
>
> But I (as the primary developer of ssb) like to resolve the issue, too.
> Please provide more information on the actual _issue_.
> 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?
> Which IRQ number do you get with the old b44 driver?
>
> Thanks for your testing. That is why -mm exists.
> Next time without bullshitting, please.
Ok, people already call me that I am an idiot to tell Andrew to fuck off.
Well, I did not. ;)
My mail client just put him into the To: field. This mail was for
the original author of the bugreport.
--
Greetings Michael.
Am Freitag, 25. Mai 2007 18:56 schrieben Sie:
> On Fri, 25 May 2007 16:52:19 +0200 Michael Buesch <[email protected]> wrote:
> > 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.
>
> It wouldn't be the first time.
>
> Uwe, please generate the `dmesg -s 1000000' output for 2.6.22-rc2 and for
> 2.6.22-rc2-mm1, feed them through `diff -u' and see if you can spot any
> interesting-looking differences in the PCI/ACPI/IRQ area. Send both the
> files to me and I'll stick them on a server and then I'll see if we can
> hunt down the perpetrator.
>
> Thanks.
Hi everybody,
unfortunately Andrew's path can be proven to be wrong:
There is no bug in the ACPI area at all.
I reverted the following modules in 2.6.22-rc2-mm1:
--- linux-2.6.22-rc2/drivers/net/b44.c 2007-05-19 02:24:07.000000000 -0700
+++ devel/drivers/net/b44.c 2007-05-22 21:55:36.000000000 -0700
AND:
--- linux-2.6.22-rc2/drivers/net/b44.h 2007-04-25 23:42:17.000000000 -0700
+++ devel/drivers/net/b44.h 2007-05-22 21:55:36.000000000 -0700
AND:
--- linux-2.6.22-rc2/drivers/usb/host/ohci-hcd.c 2007-05-19
02:24:07.000000000 -0700
+++ devel/drivers/usb/host/ohci-hcd.c 2007-05-22 21:55:36.000000000 -0700
AND:
--- /dev/null 2007-05-07 19:14:32.301975000 -0700
+++ devel/drivers/usb/host/ohci-ssb.c 2007-05-22 21:55:36.000000000 -0700
RESULT:
Broadcom 4401 is working purrfectly! YUP!
Apart from that the kernel configuration menu of 2.6.22-rc2-mm1 is highly
confusing:
Kernel Config differences:
In kernel 2.6.21.2 you are bound to go:
EISA, VLB, PCI and onboard controllers Y
Broadcom 4400 ethernet support m
Whereas in Kernel 2.6.22-rc2-mm1 is completely confusing:
1. There is a menu called Sonics Silicon Backplane, which does not
exist in 2.6.21.2.
2. In Section Network device support Y
Ethernet (10 or 100Mbit) Y
you got 2 confusing choices:
Option A:
EISA, VLB, PCI and onboard controllers Y
Broadcom 4400 ethernet support m
Broadcom 4400 PCI device support y
This enables "Sonic Silicon Backplane support m"
OR, and this is in fact confusing:
Option B:
Leave OUT (!!!) EISA, VLB, PCI and onboard controllers Y
Simply: Broadcom 4400 ethernet support m
This enables "Sonic Silicon Backplane support m"
Option B is proved to be working with the patch against the b44.c module
reverted in 2.6.22-rc2-mm1.
If it is NOT reverted, Option B fails, but the confusion stays:
You do not get the idea whether
"Support for SSB on PCI bus host m" is necessary or not!
And above that, THIS ONE:
"Broadcom 4400 ethernet support m"
should never appear when THIS one:
"EISA, VLB, PCI and onboard controllers Y"
is DESELECTED, should it??
And that's it exactly what I meant when I mentioned that the ATTACHMENT of ssb
to b44 is highly buggy!
I hope, Michael, that you believe that now.
If you need lspci -v or / and dmesg to prove that I am right and you are
wrong:
Pleasure for me, just ask please!
Cheers
Uwe
P. S.: In clear words:
I higly suspect that simply the kernel config bindings are highly buggy and
chaotic.
On Thursday 24 May 2007 23:16:48 Uwe Bugla wrote:
> Above that, the commiter DID IGNORE your baselines of testing, but at the same
> time got highly profile-neurotic regarding the copyright issue of 2007,
> didn't he (Let's call this a basic instinct of our precedents: the apes:
> shouting: I, I, I, more, more, more)?
????
--
Greetings Michael.
Am Freitag, 25. Mai 2007 16:52 schrieben Sie:
> 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?
First of all, what is an ssb device please? AFAICS it looks like an extension
of b44.c as far as module selection is concerned in kernel configuration.
What it's function / purpose?
Does its function / purpose apply to every platform?
>
> > 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?
Should I? My broadcom 4401 is broken, but only in that specific mm1-tree.
It's not broken in 2.6.22-rc2 for instance. So that's your patch that breaks
it.
>
> > 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.
I do not state that ssb is wrong, but I state that the ATTACHMENT of ssb to
b44.c is wrong. That's a big difference.
In all earlier kernels that b44 device has been fine, and ssb has never been
seen.
>
> > 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...
Nice for you, but on my machine it is broken, the broadcom 4401 onboard NIC
controller is unusable.
>
> > 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.
But if APIC were broken all the other devices would not work too.
But they DO work!
Please correct me if I draw incorrect conclusions.
Do you mean to build a kernel without any ACPI functions?
>
>
> 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.
Fine! Why do I get then a whole sum of correct interrupts while the only
strange / false one (255) is exactly the one offered to b44.c?
And for what do I get that ssb module who's functionality I do not understand?
If you need futher info please ask. But the possibility that the whole APIC is
broken is rather small I think. To exclude that I would rather rip out any
APIC changes in 2.6.22-rc2-mm1, if there are any (didn't take a look for
that - only found out that the whole system works fine with the exception of
parts of the alsa architecture and this broken b44.c module.
Cheers
Uwe
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.
On Fri, 25 May 2007 16:52:19 +0200 Michael Buesch <[email protected]> wrote:
> 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.
It wouldn't be the first time.
Uwe, please generate the `dmesg -s 1000000' output for 2.6.22-rc2 and for
2.6.22-rc2-mm1, feed them through `diff -u' and see if you can spot any
interesting-looking differences in the PCI/ACPI/IRQ area. Send both the
files to me and I'll stick them on a server and then I'll see if we can
hunt down the perpetrator.
Thanks.
Am Freitag, 25. Mai 2007 15:12 schrieben Sie:
> On Thursday 24 May 2007 22:06:59 Andrew Morton wrote:
> > On Thu, 24 May 2007 21:56:16 +0200
> >
> > "Uwe Bugla" <[email protected]> wrote:
> > > Hi everybody,
> >
> > (added linux-wireless, others)
> >
> > > The patch against b44.c contained in 2.6.22-rc2-mm1 has two
> > > consequences:
> > >
> > > 1. a tight binding to module ssb whose function or necessity I neither
> > > see through nor do comprehend
> > >
> > > 2. a breakdown (disfunctionality) of my onboard NIC.
> > >
> > > lspci -v looks like this:
> > >
> > > 00:00.0 Host bridge: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE
> > > DRAM Controller/Host-Hub Interface (rev 02) Subsystem: ASUSTeK Computer
> > > Inc. Unknown device 80b2
> > > Flags: bus master, fast devsel, latency 0
> > > Memory at f8000000 (32-bit, prefetchable) [size=64M]
> > > Capabilities: [e4] Vendor Specific Information
> > > Capabilities: [a0] AGP version 2.0
> > >
> > > 00:01.0 PCI bridge: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE
> > > Host-to-AGP Bridge (rev 02) (prog-if 00 [Normal decode]) Flags: bus
> > > master, 66MHz, fast devsel, latency 64
> > > Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
> > > I/O behind bridge: 0000d000-0000dfff
> > > Memory behind bridge: f2000000-f27fffff
> > > Prefetchable memory behind bridge: f3f00000-f7ffffff
> > >
> > > 00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM
> > > (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 02) (prog-if 00
> > > [UHCI]) Subsystem: ASUSTeK Computer Inc. Unknown device 8089
> > > Flags: bus master, medium devsel, latency 0, IRQ 17
> > > I/O ports at b800 [size=32]
> > >
> > > 00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM
> > > (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 02) (prog-if 00
> > > [UHCI]) Subsystem: ASUSTeK Computer Inc. Unknown device 8089
> > > Flags: bus master, medium devsel, latency 0, IRQ 20
> > > I/O ports at b400 [size=32]
> > >
> > > 00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM
> > > (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 02) (prog-if 00
> > > [UHCI]) Subsystem: ASUSTeK Computer Inc. Unknown device 8089
> > > Flags: bus master, medium devsel, latency 0, IRQ 16
> > > I/O ports at b000 [size=32]
> > >
> > > 00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M)
> > > USB2 EHCI Controller (rev 02) (prog-if 20 [EHCI]) Subsystem: ASUSTeK
> > > Computer Inc. Unknown device 8089
> > > Flags: bus master, medium devsel, latency 0, IRQ 18
> > > Memory at f1800000 (32-bit, non-prefetchable) [size=1K]
> > > Capabilities: [50] Power Management version 2
> > > Capabilities: [58] Debug port
> > >
> > > 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 82)
> > > (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0
> > > Bus: primary=00, secondary=02, subordinate=02, sec-latency=32
> > > Memory behind bridge: f1000000-f17fffff
> > > Prefetchable memory behind bridge: f2800000-f3efffff
> > >
> > > 00:1f.0 ISA bridge: Intel Corporation 82801DB/DBL (ICH4/ICH4-L) LPC
> > > Interface Bridge (rev 02) Flags: bus master, medium devsel, latency 0
> > >
> > > 00:1f.1 IDE interface: Intel Corporation 82801DB (ICH4) IDE Controller
> > > (rev 02) (prog-if 8a [Master SecP PriP]) Subsystem: ASUSTeK Computer
> > > Inc. Unknown device 8089
> > > Flags: bus master, medium devsel, latency 0, IRQ 16
> > > I/O ports at 01f0 [size=8]
> > > I/O ports at 03f4 [size=1]
> > > I/O ports at 0170 [size=8]
> > > I/O ports at 0374 [size=1]
> > > I/O ports at f000 [size=16]
> > > Memory at 30000000 (32-bit, non-prefetchable) [size=1K]
> > >
> > > 00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M)
> > > SMBus Controller (rev 02) Subsystem: ASUSTeK Computer Inc. Unknown
> > > device 8089
> > > Flags: medium devsel, IRQ 19
> > > I/O ports at e800 [size=32]
> > >
> > > 00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM
> > > (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 02) Subsystem: ASUSTeK
> > > Computer Inc. Unknown device 80b0
> > > Flags: bus master, medium devsel, latency 0, IRQ 19
> > > I/O ports at a800 [size=256]
> > > I/O ports at a400 [size=64]
> > > Memory at f0800000 (32-bit, non-prefetchable) [size=512]
> > > Memory at f0000000 (32-bit, non-prefetchable) [size=256]
> > > Capabilities: [50] Power Management version 2
> > >
> > > 01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 PF/PRO
> > > AGP 4x TMDS (prog-if 00 [VGA]) Subsystem: ATI Technologies Inc Rage
> > > Fury Pro/Xpert 2000 Pro
> > > Flags: bus master, stepping, 66MHz, medium devsel, latency 64, IRQ 17
> > > Memory at f4000000 (32-bit, prefetchable) [size=64M]
> > > I/O ports at d800 [size=256]
> > > Memory at f2000000 (32-bit, non-prefetchable) [size=16K]
> > > Expansion ROM at f3fe0000 [disabled] [size=128K]
> > > Capabilities: [50] AGP version 2.0
> > > Capabilities: [5c] Power Management version 2
> > >
> > > 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 255
> > > Memory at f1000000 (32-bit, non-prefetchable) [disabled] [size=8K]
> > > Capabilities: [40] Power Management version 2
> > >
> > > 02:0b.0 Multimedia video controller: Brooktree Corporation Bt878 Video
> > > Capture (rev 11) Subsystem: Pinnacle Systems Inc. PCTV Sat (DBC
> > > receiver)
> > > Flags: bus master, medium devsel, latency 32, IRQ 18
> > > Memory at f3000000 (32-bit, prefetchable) [size=4K]
> > > Capabilities: [44] Vital Product Data
> > > Capabilities: [4c] Power Management version 2
> > >
> > > 02:0b.1 Multimedia controller: Brooktree Corporation Bt878 Audio
> > > Capture (rev 11) Subsystem: Pinnacle Systems Inc. PCTV Sat (DBC
> > > receiver)
> > > Flags: bus master, medium devsel, latency 32, IRQ 18
> > > Memory at f2800000 (32-bit, prefetchable) [size=4K]
> > > Capabilities: [44] Vital Product Data
> > > Capabilities: [4c] Power Management version 2
> > >
> > > Please note:
> > >
> > > 1. IRQ 255 looks very idiotic, doesn't it? It does not exist at all,
> > > does it?
> > >
> > > Questions:
> > >
> > > 1. What is the technical need / progress of module ssb please?
> > >
> > > 2. If Andrew Morton's guidelines clearly say: "Do test your patches on
> > > three different machines" and this guideline seems to be strictly
> > > ignored by some sparetime hackers:
> > >
> > > What is the master plan then to avoid the fact that such a crap is
> > > being sent in to Andrew?
> > >
> > > Yours sincerely
> > >
> > > Uwe
> > >
> > > P. S.: There is an important saying going like this:
> > >
> > > Too many cooks do mess up the pap.
> > >
> > > Regarding the patch in mm-tree I can see SIX (!) Copyright owners.
> > > The last one of them (i. e. the one of 2007) obviuosly does not seem to
> > > understand what he is doing (see that nonsense interrupt please, just
> > > incredible!) :(
> > >
> > > In so far I would deeply appreciate Andrew Morton to throw that b44.c
> > > patch into the trashbox as soon as possible :)
> >
> > The code presumably worked for the developer. The reason for merging it
> > into -mm is to allow others to identify problems such as these before the
> > code hits mainline.
> >
> > Having bugs in -mm is normal, natural and expected. What I _do_ very
> > much prefer to see is that these bugs get fixed promptly and, critically,
> > that the code doesn't go into Linus's tree until all the known bugs are
> > repaired.
> >
> > Also, it's really bad when a bug makes the entire -mm release unusable
> > for testers. Because this means that all the _other_ people who have
> > code being tested in -mm just lost a tester. And it can cause people to
> > just not bother testing -mm kernels at all, which means that more badness
> > will get into mainline.
>
> You are talking a _lot_ of bullshit, and I'd really like to tell
> you to fuck off, because you have no clue how software development works.
>
> But I (as the primary developer of ssb) like to resolve the issue, too.
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.
I think you cannot just bind ssb tightly to b44.c, can you?
In so far the way how ssb is attached is buggy and wrong, apart from the fact
that my controller is broken, disfunctional.
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.
Now see, if everybody would ignore Andrew's guidelines the mm-tree qwould be
nothing like an unusable chaos, wouldn't it.
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 am convinced that your solution runs on your machine, but the solution that
you provide looks very rude, doesn't it?
> 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?
> Which IRQ number do you get with the old b44 driver?
IRQ 17
>
> Thanks for your testing. That is why -mm exists.
> Next time without bullshitting, please.
Cheers
Uwe