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

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

[Uwe Bugla]

Am Samstag, 26. Mai 2007 23:52 schrieben Sie:
> On Sat, 2007-05-26 at 23:32 +0200, Uwe Bugla wrote:
> > Am Samstag, 26. Mai 2007 21:49 schrieben Sie:
> > > On Saturday 26 May 2007 21:39:54 Uwe Bugla wrote:
> > > > Am Samstag, 26. Mai 2007 21:19 schrieben Sie:
> > > > > Uwe, please try the following patch:
> > > > >
> > > > > Index: bu3sch-wireless-dev/drivers/net/b44.c
> > > > > ===================================================================
> > > > > --- bu3sch-wireless-dev.orig/drivers/net/b44.c        2007-05-18
> > > > > 18:09:50.000000000 +0200 +++
> > > > > bu3sch-wireless-dev/drivers/net/b44.c 2007-05-26 21:18:28.000000000
> > > > > +0200 @@ -2201,10 +2201,12 @@ static int __devinit
> > > > > b44_init_one(struct printk("%2.2x%c", dev->dev_addr[i],
> > > > >                      i == 5 ? '\n' : ':');
> > > > >
> > > > > +#if 0
> > > > >       /* Initialize phy */
> > > > >       spin_lock_irq(&bp->lock);
> > > > >       b44_chip_reset(bp);
> > > > >       spin_unlock_irq(&bp->lock);
> > > > > +#endif
> > > > >
> > > > >       return 0;
> > > >
> > > > Against what kernel please?
> > > > Just try to be a bit more eloquent, man!
> > >
> > > Against a kernel which does not work for you, of course.
> > >
> > > Sometimes I wonder... (no better not say that).
> >
> > YES! And I wonder TOO, definitely!
> >
> > Quand meme (now, if you do not speak french: Above all that), I applied
> > your patch against 2.6.22-rc2-mm1. Just to show my cooperation willing to
> > get your "dream" being fulfilled!
> >
> > Result is: No change!
> > Non-functionable b44-device at all!
> >
> > Hint: Although being a "non-hacker" or "non-developer" I do have stepped
> > across some experienced developer people who at least added some code to
> > make their modules function in the following way:
> >
> > modprobe xyz debug=1 (or debug=2 or debug=3 or debug=4 or debug=5 or
> > debug=6)
> >
> > In so far, if you continue to state that debugging is nothing but
> > guessing around wildly you are definitely wrong, showing us all your
> > missing code hacker experience. If you DO continue like this every step
> > will be a torture not only for me but for the reading folks as well.
> >
> > But every human being is here to learn and develop: In so far I am very
> > optimistic!
> >
> > Apart from the Kconfig chaos that seems to be subordinate in your
> > personal rating scale, you at least could have added some functions like
> > the above mentioned functions.
> >
> > The fact that you simply ignored to imply those functions and continue to
> > call other people dumb shows exactly how small and humble you are.
> >
> > Apart from that:
> > The message that you rooted to my place was no "proof" at all for any
> > kind of disfunctionality or compatibility issue!
> >
> > In that message the lack of performance of the "enclosed" or "old"
> > or "complete" b44 module (i. e. PCI-only module) was criticised, NOT the
> > one ripped by you personally into two modules called b44 and ssb.
> >
> > In so far I would deeply appreciate you personally to stick to the facts
> > in your personal lack of knowledge about the b44 driver instead of
> > playing bad politics against other people like me and others.
> >
> >
> > Hello my dear Andrew Morton,
> >
> > Could you please do me and the rest of the world two favours?
> >
> > A. Rip Michael Buesches code out of the mm-tree
> >
> > B. Give Michael Buesch a fair chance to revise his disfunctionable code
> > outside the mm-tree and / or the vanilla mainline.
> >
> > Side note for the what and why:
> >
> > I like to help avoid dangers by testing the mm-tree.
> > BUT:
> >
> > If real debugging conforms to nothing but guessing around wildly let me
> > tell you that I do not appreciate to be part of that torture due to the
> > lack of experience of some German spare time hacker.
> >
> > A: proven by facts not knowing or even wanting to know how to imply
> > appropriate functionable debug parametres in his driver code
> >
> > B: non-cooperative as far as Kconfig help features are concerned (i. E.
> > help to understand the issues for users
> >
> > C: calling all people simply dumb who do not know about his personal
> > issues at all
> >
> > Thank you, Andrew Morton! You are real fine!
>
> Everyone just needs to cool down.  And you both (Uwe and Michael) just
> need to try debugging the problem.
>
> Abstracting the SSB code into a library is clearly the correct solution,
> rather than having the same code in two separate places.  The whole
> _point_ of having code in various trees (wireless, mm, etc) is to find
> these bugs before the patches hit mainline.  Even testing on > 3
> machines may not uncover subtle bugs (for example, different behavior on
> different silicon revisions, especially in reverse-engineered parts),

yes, and to simplify that you need additional commandline parametres 
(debug=1,2,3,4,5 f. ex.).
Those debug levels provide:
1. different verbose levels of printed output, sent to specific logs like 
kern.log for example
2. different hexadecimal outprints who show what sub-part of the driver is 
working as expected and what part is not
3. if the driver is loaded correctly but refuses to work as expected while 
the "traditional" one without "outsourced" ssb backplane works as expected 
there must be some technique to move the what and why into system logs, just 
to establish facts instead of guessing around.
4. If that technique is not provided by the author of the code then that is a 
proof for the author's lack of experience. As I said already: Too many cooks 
do spoil the pap.

If debugging is limited to dmesg, .config and guessing around, then I call 
such a code a real poor and crude one.

> it's only something Michael can test so far before other people have to
> pick it up and test it.

Theoretically: yes. Practically: No, due to the personal withdraws of the 
latest cook.

Michael in fact thinks that if he is producing code he can delegate everything 
else to other people, replying "for me it works" like a parrot.

In so far, not only the code itself is quite rude and crude, but the author of 
the code is too, transforming the testing procedure into a torture due to the 
author's (i. e. the latest cook's) proven personal and technical 
incompetence. 

> And that's where you come in, Uwe. 

Yes.

>
> So both of you should actually just stop the name-calling, suck it up,
> and debug the problem.  We're getting nothing done here.
>
> Dan

You cannot debug the problem for the reasons that I already described, and I 
will not spend my time with this crude stuff anymore.

My proposal is: Gary Zambrowski should revise that code (the only one Cced 
being employed at broadcom.com, the manufacturer).

Until the job is done by Gary Andrew Morton should rip this stuff out of the 
mm-tree for being rude, crude, immature.

Uwe

_______________________________________________________________
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192

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

[Kyle Moffett]

On May 27, 2007, at 06:46:51, Uwe Bugla wrote:
> [...insults and flamage...]

Uwe, when people ban you from posting to mailing lists it's  
incredibly rude to create a new email account and continue the same  
flamage that got you banned in the first place.  Why don't you go  
elsewhere until you can learn to be respectful and polite and keep a  
civil tone with people who are trying to help you?  At such time you  
may be welcome once more on these lists, but not until then.

Cheers,
Kyle Moffett

P.S: Don't bother replying since your new email address has already  
been placed adjacent to the old one in my killfile.

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

[Uwe Bugla]

Hi everybody,

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 :)

-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger

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

[Andrew Morton]

On Thu, 24 May 2007 21:56:16 +0200
"Uwe Bugla" <uwe.bugla@gmx.de> 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.

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

[Uwe Bugla]

Am Donnerstag, 24. Mai 2007 22:06 schrieben Sie:
> On Thu, 24 May 2007 21:56:16 +0200
>
> "Uwe Bugla" <uwe.bugla@gmx.de> 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!

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

[Michael Buesch]

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.

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

[Michael Buesch]

On Thursday 24 May 2007 22:06:59 Andrew Morton wrote:
> On Thu, 24 May 2007 21:56:16 +0200
> "Uwe Bugla" <uwe.bugla@gmx.de> 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.

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

[Michael Buesch]

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" <uwe.bugla@gmx.de> 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.

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

[Uwe Bugla]

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" <uwe.bugla@gmx.de> 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

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

[Michael Buesch]

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.

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

[Uwe Bugla]

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.

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

[Michael Buesch]

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.

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

[Maximilian Engelhardt]

[-- Attachment #1: Type: text/plain, Size: 492 bytes --]

On Fri, 25 May 2007 17:59:29 +0200, Uwe Bugla wrote:

> 
> 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.

I've been using 2.6.22-rc2 for some time and now I compiled 2.6.22-rc2-
mm1 and both work fine with the BCM4401 in my laptop.

Maxi

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Uwe Bugla]

Am Freitag, 25. Mai 2007 20:48 schrieben Sie:
> On Fri, 25 May 2007 17:59:29 +0200, Uwe Bugla wrote:
> > 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.
>
> I've been using 2.6.22-rc2 for some time and now I compiled 2.6.22-rc2-
> mm1 and both work fine with the BCM4401 in my laptop.
>
> Maxi

Hello Maxi,

That may be true for your Laptop, but it unfortunately isn't true for my ASUS 
mainboard onboard controller.

Unfortunately I cannot confirm this:

My broadcom 4401 driver is not part of a notebook, but instead part of an ASUS 
P4PE mainboard.

At my second attempt I went the conventional path (i. e. ignoring the fact 
that
"Broadcom 4400 ethernet support appears twice in section "Network device 
support":

Whether you leave out "EISA, VLB, PCI and on board controllers" or not it 
simply appears twice in kernel config! This is bug number 1.

Conventional path means:

EISA, VLB, PCI and on board controllers Y

Broadcom 4400 ethernet support m

Broadcom 4400 PCI device support Y

This configuration binds:

Sonics Silicon Backplane Support m

Support for SSB on PCI-bus host

SSB PCI core driver

This time I do get a "good" interrupt: IRQ 21 for the the device.

BUT:

Trying to ping another machine fails saying:

"destination host unreachable"


That means, Although the interrupt is fine now, the device is still not 
functionable.

This is bug number 2.

Cheers

Uwe

P. S.: Michael, Andrew, if you need additional information to resolve that 
issue please tell / ask me.

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

[Michael Buesch]

On Friday 25 May 2007 21:40, Uwe Bugla wrote:
> Am Freitag, 25. Mai 2007 20:48 schrieben Sie:
> > On Fri, 25 May 2007 17:59:29 +0200, Uwe Bugla wrote:
> > > 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.
> >
> > I've been using 2.6.22-rc2 for some time and now I compiled 2.6.22-rc2-
> > mm1 and both work fine with the BCM4401 in my laptop.
> >
> > Maxi
> 
> Hello Maxi,
> 
> That may be true for your Laptop, but it unfortunately isn't true for my ASUS 
> mainboard onboard controller.
> 
> Unfortunately I cannot confirm this:
> 
> My broadcom 4401 driver is not part of a notebook, but instead part of an ASUS 
> P4PE mainboard.
> 
> At my second attempt I went the conventional path (i. e. ignoring the fact 
> that
> "Broadcom 4400 ethernet support appears twice in section "Network device 
> support":
> 
> Whether you leave out "EISA, VLB, PCI and on board controllers" or not it 
> simply appears twice in kernel config! This is bug number 1.

No it is NOT a bug.
It simply shows again that you don't know how b44, ssb or anything related works.

Would you _please_ take a look at the code, before calling features bugs.
And yes, this IS a feature. It is a feature to get b44 running on an OpenWRT
embedded device. These devices don't have a PCI bus. So b44 MUST NOT depend
on "EISA, VLB, PCI and on board controllers".
"Broadcom 4400 PCI device support" does depend on "EISA, VLB, PCI and on board controllers".

Everything is correct.
Bug number 1 is solved.
qed

> This time I do get a "good" interrupt: IRQ 21 for the the device.
> 
> BUT:
> 
> Trying to ping another machine fails saying:
> 
> "destination host unreachable"
> 
> 
> That means, Although the interrupt is fine now, the device is still not 
> functionable.

And it's completely impossible that you did a mistake when configuring
the device? Typo in the IP? Typo in the gateway or DNS entries?
Try it again, please.
And please try with current wireless-dev tree.

And I simply do not get it why you suddenly get a good IRQ number, like everybody
else does, without fixing The Bug (tm).

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

[Maximilian Engelhardt]

[-- Attachment #1: Type: text/plain, Size: 3014 bytes --]

On Saturday 26 May 2007, Michael Buesch wrote:
> On Friday 25 May 2007 21:40, Uwe Bugla wrote:
> > Am Freitag, 25. Mai 2007 20:48 schrieben Sie:
> > > On Fri, 25 May 2007 17:59:29 +0200, Uwe Bugla wrote:
> > > > 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.
> > >
> > > I've been using 2.6.22-rc2 for some time and now I compiled 2.6.22-rc2-
> > > mm1 and both work fine with the BCM4401 in my laptop.
> > >
> > > Maxi
> >
> > Hello Maxi,
> >
> > That may be true for your Laptop, but it unfortunately isn't true for my
> > ASUS mainboard onboard controller.
> >
> > Unfortunately I cannot confirm this:
> >
> > My broadcom 4401 driver is not part of a notebook, but instead part of an
> > ASUS P4PE mainboard.
> >
> > At my second attempt I went the conventional path (i. e. ignoring the
> > fact that
> > "Broadcom 4400 ethernet support appears twice in section "Network device
> > support":
> >
> > Whether you leave out "EISA, VLB, PCI and on board controllers" or not it
> > simply appears twice in kernel config! This is bug number 1.
>
> No it is NOT a bug.
> It simply shows again that you don't know how b44, ssb or anything related
> works.
>
> Would you _please_ take a look at the code, before calling features bugs.
> And yes, this IS a feature. It is a feature to get b44 running on an
> OpenWRT embedded device. These devices don't have a PCI bus. So b44 MUST
> NOT depend on "EISA, VLB, PCI and on board controllers".
> "Broadcom 4400 PCI device support" does depend on "EISA, VLB, PCI and on
> board controllers".
>
> Everything is correct.
> Bug number 1 is solved.
> qed
>
> > This time I do get a "good" interrupt: IRQ 21 for the the device.
> >
> > BUT:
> >
> > Trying to ping another machine fails saying:
> >
> > "destination host unreachable"
> >
> >
> > That means, Although the interrupt is fine now, the device is still not
> > functionable.
>
> And it's completely impossible that you did a mistake when configuring
> the device? Typo in the IP? Typo in the gateway or DNS entries?
> Try it again, please.
> And please try with current wireless-dev tree.
>
> And I simply do not get it why you suddenly get a good IRQ number, like
> everybody else does, without fixing The Bug (tm).

I did run my 2.6.22-rc2-mm1 kernel a bit longer and noticed that I was wrong 
in my first mail. The driver does work with my 4401 and network traffic seem 
to get out and in fine, but it has huge performance problems. If I do some 
pings and traceroutes I sometimes get response times of only a few ms but I 
also get times of a few seconds. Also trying to play games is totally 
impossible. This doesn't happen with 2.6.22-rc2 and 2.6.22-rc3.

Maxi

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Uwe Bugla]

Am Samstag, 26. Mai 2007 07:00 schrieben Sie:
> On Friday 25 May 2007 21:40, Uwe Bugla wrote:
> > Am Freitag, 25. Mai 2007 20:48 schrieben Sie:
> > > On Fri, 25 May 2007 17:59:29 +0200, Uwe Bugla wrote:
> > > > 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.
> > >
> > > I've been using 2.6.22-rc2 for some time and now I compiled 2.6.22-rc2-
> > > mm1 and both work fine with the BCM4401 in my laptop.
> > >
> > > Maxi
> >
> > Hello Maxi,
> >
> > That may be true for your Laptop, but it unfortunately isn't true for my
> > ASUS mainboard onboard controller.
> >
> > Unfortunately I cannot confirm this:
> >
> > My broadcom 4401 driver is not part of a notebook, but instead part of an
> > ASUS P4PE mainboard.
> >
> > At my second attempt I went the conventional path (i. e. ignoring the
> > fact that
> > "Broadcom 4400 ethernet support appears twice in section "Network device
> > support":
> >
> > Whether you leave out "EISA, VLB, PCI and on board controllers" or not it
> > simply appears twice in kernel config! This is bug number 1.
>
> No it is NOT a bug.
> It simply shows again that you don't know how b44, ssb or anything related
> works.
>
> Would you _please_ take a look at the code, before calling features bugs.
> And yes, this IS a feature. It is a feature to get b44 running on an
> OpenWRT embedded device. These devices don't have a PCI bus. So b44 MUST
> NOT depend on "EISA, VLB, PCI and on board controllers".

Thanks for the descriptive lesson! But this explanation is displaced HERE.
It should be part of the Kconfig text instead, as the b44 running on an 
OpenWRT embedded device simply does not show up in Kernel configuration of 
2.6.21.2 and earlier kernels.
In so far there is a bug that I would call superficial and incomplete 
explanation of b44 features in Kconfig!

Just two or three explaining sentences at the appropriate place would do well 
instead of singing this aria again an again:

"It simply shows again that you don't know how b44, ssb or anything related 
works."

It's NOT MY task to be omnicient. Above that, the b44 modules have never been 
documented at all. So how can you expect me and others to know about the 
latest features of version 2? Very strange behaviour of yours ) :

> "Broadcom 4400 PCI device support" does depend on "EISA, VLB, PCI and on
> board controllers".

Thanks, now I know. But the dependencies chaos plus the PCI disfunctionality 
stays unfortunately!

>
> Everything is correct.
> Bug number 1 is solved.

NO! See above please and DO NOT IGNORE!

> qed
>
> > This time I do get a "good" interrupt: IRQ 21 for the the device.
> >
> > BUT:
> >
> > Trying to ping another machine fails saying:
> >
> > "destination host unreachable"
> >
> >
> > That means, Although the interrupt is fine now, the device is still not
> > functionable.
>
> And it's completely impossible that you did a mistake when configuring
> the device? Typo in the IP? Typo in the gateway or DNS entries?

Yes! This sort of mistakes is completely impossible, as I use to work with 
aliases rather than IP adresses. The machine I tried to ping (i. e. my 
router) is called Jerry (as a reminiscence to Mr. "Captan Trips" from 
Grateful Dead), and thus "ping jerry" returned the following:

"destination host unreachable"

Above that, I state for the second time now that I reverted your patches in 
2.6.22-rc2-mm1 with the effect that everything worked perfectly!
Maxi said something at least similar. So how many proofs do you need, Mister 
Buesch, to finally pick up patchworking now?? 

So, the ball has been in your court for two days now, and you simply keep on 
hesitating to take action now. Instead you are playing a 
nonsense "I-am-not-responsible-and-you-don't-know-Ping-Pong game"
ignoring every hint, criticism that you are offered.
REAL GREAT!

> Try it again, please.

NO!

> And please try with current wireless-dev tree.

A. I do not know where to download that wireless-dev tree.
B. I do not know how to implement it into mm or mainline
C. I have given enough sophisticated proof that your stuff in mm-tree is 
highly incomplete / buggy.

>
> And I simply do not get it why you suddenly get a good IRQ number, like
> everybody else does, without fixing The Bug (tm).

That consequence I already explained:
But it's a pleasure for me to repeat it once more:

When you are saying Y to "EISA, VLB, PCI and on board controllers"

you simply do get not only completely different interrupts for the b4401 
device, but you get also completely different module dependencies.

If the module dependencies are correct the IRQ number is also correct,
If the module dependencies are broken the IRQ number is also broken.

It's as easy as that simply!

In other words, UTMOST CLEAR:

Runningh a PCI B4401 NIC:

A. If you declare the b4401 device in Kconfig as a non PCI device (well, how 
should you know if there is neither documenatary nor appropriate kconfig 
text) you get a disfunctionable b44 PLUS a BROKEN interrupt number.

B. If you declare the b4401 device in Kconfig as a PCI device you get a 
disfunctionable b44 PLUS a CORRECT interrupt number.

The ball is in your court, Michael.

Instead of playing verbal ping pong you would better send me info about debug 
parameters for ssb AND b44 and tell me what specific log you need afterwards. 
If b44 misses debug printks or dprintks then please send me an appropriate 
patch to apply against the mm-tree.

But, this stuff in the current state IS PROVEN to be highly buggy / 
experimental / incomplete / bad described in Kconfig! It should NEVER be 
pulled into vanilla in the current state!

So, Michael, you got two choices now:

A. Either you offer debug parameters now / and / or appropriate patches OR

B. I will stop answering on that issue with the consequence that your stuff 
will never reach vanilla mainline. For this case I will ask Andrew to throw 
your stuff into the trashcan.

I've wasted enough time on that buggy crap now with output zero. It's enough 
now, Michael!

Cheers

Uwe

Hint: Broadcom 4401 is NOT equal to Broadcom 4401!

I got two nearly identical machines owing that onboard controller.

There in fact has been a buggy / incomplete driver who did well on the one 
machine, but did not work on the other one..... : (
Don't ask me which 2.6 kernel that was, I do not remember. Must have been 
2.6.9 or an earlier one.

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

[Michael Buesch]

On Saturday 26 May 2007 12:40:54 Uwe Bugla wrote:
> Yes! This sort of mistakes is completely impossible, as I use to work with 
> aliases rather than IP adresses. The machine I tried to ping (i. e. my 
> router) is called Jerry (as a reminiscence to Mr. "Captan Trips" from 
> Grateful Dead), and thus "ping jerry" returned the following:
> 
> "destination host unreachable"
> 
> Above that, I state for the second time now that I reverted your patches in 
> 2.6.22-rc2-mm1 with the effect that everything worked perfectly!
> Maxi said something at least similar. So how many proofs do you need, Mister 
> Buesch, to finally pick up patchworking now?? 

How about you stopping with your fucking aggressive wording??

> > Try it again, please.
> 
> NO!
> 
> > And please try with current wireless-dev tree.
> 
> A. I do not know where to download that wireless-dev tree.
> B. I do not know how to implement it into mm or mainline
> C. I have given enough sophisticated proof that your stuff in mm-tree is 
> highly incomplete / buggy.

Ok,

D. As you are not going to help me debugging, I am not going to fix.

> >
> > And I simply do not get it why you suddenly get a good IRQ number, like
> > everybody else does, without fixing The Bug (tm).
> 
> That consequence I already explained:
> But it's a pleasure for me to repeat it once more:
> 
> When you are saying Y to "EISA, VLB, PCI and on board controllers"
> 
> you simply do get not only completely different interrupts for the b4401 
> device, but you get also completely different module dependencies.

That is EXPECTED and I already explained that.
It is a feature. Not a bug.


-- 
Greetings Michael.

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

[Uwe Bugla]

Am Samstag, 26. Mai 2007 17:36 schrieben Sie:
> On Saturday 26 May 2007 12:40:54 Uwe Bugla wrote:
> > Yes! This sort of mistakes is completely impossible, as I use to work
> > with aliases rather than IP adresses. The machine I tried to ping (i. e.
> > my router) is called Jerry (as a reminiscence to Mr. "Captan Trips" from
> > Grateful Dead), and thus "ping jerry" returned the following:
> >
> > "destination host unreachable"
> >
> > Above that, I state for the second time now that I reverted your patches
> > in 2.6.22-rc2-mm1 with the effect that everything worked perfectly! Maxi
> > said something at least similar. So how many proofs do you need, Mister
> > Buesch, to finally pick up patchworking now??
>
> How about you stopping with your fucking aggressive wording??

If you stop repeating that you are not responsible for that buggy stuff then I 
will be friendlier. That's all.
So calm down and provide me some parametres to debug.
I will be cooperative and we're gonna fix it for sure, OK?

>
> > > Try it again, please.
> >
> > NO!
> >
> > > And please try with current wireless-dev tree.
> >
> > A. I do not know where to download that wireless-dev tree.
> > B. I do not know how to implement it into mm or mainline
> > C. I have given enough sophisticated proof that your stuff in mm-tree is
> > highly incomplete / buggy.
>
> Ok,
>
> D. As you are not going to help me debugging, I am not going to fix.

First of all, I need debugging parametres for both modules (b44 and ssb).
Second, I need to know which log you need after using those debug parametres.

This is the only chance to move forward, isn't it?

>
> > > And I simply do not get it why you suddenly get a good IRQ number, like
> > > everybody else does, without fixing The Bug (tm).
> >
> > That consequence I already explained:
> > But it's a pleasure for me to repeat it once more:
> >
> > When you are saying Y to "EISA, VLB, PCI and on board controllers"
> >
> > you simply do get not only completely different interrupts for the b4401
> > device, but you get also completely different module dependencies.
>
> That is EXPECTED and I already explained that.
> It is a feature. Not a bug.

Yes. But the features / extensions / different cases of b44 usage need to be 
explained in some small Kconfig text, making it easy for users to put the 
right selection for their specific NIC controller. But exactly this Kconfig 
leaves you in the dark. That's it what I critizise, nothing else. Just try to 
see through my eyes: Who would be happy with guessing around? Noone.

Cheers

Uwe

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

[Michael Buesch]

Andrew,

I am going to ignore Uwe from now on. It's simply impossible
to debug the problem the way he is responding.
Well, I'm not the first person in the Linux community adding
him to the killfile, ... .
I ask to try wireless-dev, as the driver works perfectly fine
for me there, but he refuses to try it, too. So I'm stuck.
I already tried your -mm kernel, but it crashes on my machine
for other reasons. (Yeah, I should look into them, too :P )

Andrew, is it possible that the breakage was introduced in the
merge process somehow? Didn't the patch apply cleanly? Are there
other changes to b44 I should know about in your tree?

If it is really impossible to debug this problem, I'd like to
suggest you to drop the b44-ssb port completely.
I'm not going to destroy my nerves any further with guys like
Uwe, so I'll include the b44-ssb port in the OpenWRT tree
and be done with it.
Although I would be very sad about it, as my longterm goal was
to make a vanilla kernel run on the OpenWRT devices... .

But maybe we can get another tester for -mm with similiar problems,
who is not bullshitting the whole time and is also going to
test wireless-dev to make sure it's not a merge bug.


-----------

And Uwe: Remember, I am not payed for this. I do _all_ this
in my free time.
So sentences like: "So, the ball has been in your court
for two days now, and you simply keep on hesitating
to take action now."
are _completely_ displaced in this discussion.

-- 
Greetings Michael.

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

[Andrew Morton]

On Sat, 26 May 2007 17:50:48 +0200 Michael Buesch <mb@bu3sch.de> wrote:

> Andrew,
> 
> I am going to ignore Uwe from now on. It's simply impossible
> to debug the problem the way he is responding.
> Well, I'm not the first person in the Linux community adding
> him to the killfile, ... .

Well yes, there are some personality issues here ;) But the main thing is
to struggle on and fix this bug, wherever it lies.

> I ask to try wireless-dev, as the driver works perfectly fine
> for me there, but he refuses to try it, too. So I'm stuck.

I don't think he knows how to obtain it.

Uwe, http://userweb.kernel.org/~akpm/git-wireless.patch.gz is the current
wireless tree.  That's a patch against 2.6.22-rc3.  Could you please test
that?  If that works then we know that the bug probably lies outside the
b44 driver (or it was subsequently fixed).

> I already tried your -mm kernel, but it crashes on my machine
> for other reasons. (Yeah, I should look into them, too :P )

err, please do.  Just the oops trace would be a start.

> Andrew, is it possible that the breakage was introduced in the
> merge process somehow? Didn't the patch apply cleanly? Are there
> other changes to b44 I should know about in your tree?

Only git-wireless.net modifies b44.c but if we're having IRQ assignment
problems then we'd need to look elsewhere.  I guess you could diff
rc2-mm1's b44.c against the expected version.


> If it is really impossible to debug this problem, I'd like to
> suggest you to drop the b44-ssb port completely.

Well we don't know if that'll fix it.

I believe that Uwe said that reverting the b44.c changes from rc2-mm1 fixes
things for him?  Odd, but it still doesn't rule out acip/pci/platform
changes as being the cause.

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

[Uwe Bugla]

Am Samstag, 26. Mai 2007 18:13 schrieben Sie:
> On Sat, 26 May 2007 17:50:48 +0200 Michael Buesch <mb@bu3sch.de> wrote:
> > Andrew,
> >
> > I am going to ignore Uwe from now on. It's simply impossible
> > to debug the problem the way he is responding.
> > Well, I'm not the first person in the Linux community adding
> > him to the killfile, ... .
>
> Well yes, there are some personality issues here ;) But the main thing is
> to struggle on and fix this bug, wherever it lies.
>
> > I ask to try wireless-dev, as the driver works perfectly fine
> > for me there, but he refuses to try it, too. So I'm stuck.
>
> I don't think he knows how to obtain it.
>
> Uwe, http://userweb.kernel.org/~akpm/git-wireless.patch.gz is the current
> wireless tree.  That's a patch against 2.6.22-rc3.  Could you please test
> that?  If that works then we know that the bug probably lies outside the
> b44 driver (or it was subsequently fixed).

Thank you, Andrew, just wait for a while. I am gonna try.....

>
> > I already tried your -mm kernel, but it crashes on my machine
> > for other reasons. (Yeah, I should look into them, too :P )
>
> err, please do.  Just the oops trace would be a start.
>
> > Andrew, is it possible that the breakage was introduced in the
> > merge process somehow? Didn't the patch apply cleanly? Are there
> > other changes to b44 I should know about in your tree?
>
> Only git-wireless.net modifies b44.c but if we're having IRQ assignment
> problems then we'd need to look elsewhere.  I guess you could diff
> rc2-mm1's b44.c against the expected version.
>
> > If it is really impossible to debug this problem, I'd like to
> > suggest you to drop the b44-ssb port completely.
>
> Well we don't know if that'll fix it.
>
> I believe that Uwe said that reverting the b44.c changes from rc2-mm1 fixes
> things for him?  Odd, but it still doesn't rule out acip/pci/platform
> changes as being the cause.

No, Andrew, not odd, but simply real! And Maximilian Engelhardt replied 
something similar on that.... : )

Cheers

Uwe

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

[Francois Romieu]

Uwe Bugla <uwe.bugla@gmx.de> :
> Am Samstag, 26. Mai 2007 18:13 schrieben Sie:
[...]
> > Uwe, http://userweb.kernel.org/~akpm/git-wireless.patch.gz is the current
> > wireless tree.  That's a patch against 2.6.22-rc3.  Could you please test
> > that?  If that works then we know that the bug probably lies outside the
> > b44 driver (or it was subsequently fixed).
> 
> Thank you, Andrew, just wait for a while. I am gonna try.....

Please post the .config and the dmesg for the kernels that you try too.

-- 
Ueimor

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

[Michael Buesch]

On Saturday 26 May 2007 18:13:09 Andrew Morton wrote:
> > I already tried your -mm kernel, but it crashes on my machine
> > for other reasons. (Yeah, I should look into them, too :P )
> 
> err, please do.  Just the oops trace would be a start.

Yes, I will look into it. I think it was related to my
onboard RTL networking chip. When trying to bring it down,
it oopses the machine. But I'm not sure what happens exactly, yet.
I'll take a look at it.

> > Andrew, is it possible that the breakage was introduced in the
> > merge process somehow? Didn't the patch apply cleanly? Are there
> > other changes to b44 I should know about in your tree?
> 
> Only git-wireless.net modifies b44.c but if we're having IRQ assignment
> problems then we'd need to look elsewhere.

I think we don't have IRQ assignment problems. Uwe simply disabled
b44-PCI support in his first bugreport (I guess). So there was
no b44-PCI driver loaded.
Later on he said that it does magically work now...

-- 
Greetings Michael.

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

[Uwe Bugla]

Am Samstag, 26. Mai 2007 18:21 schrieben Sie:
> On Saturday 26 May 2007 18:13:09 Andrew Morton wrote:
> > > I already tried your -mm kernel, but it crashes on my machine
> > > for other reasons. (Yeah, I should look into them, too :P )
> >
> > err, please do.  Just the oops trace would be a start.
>
> Yes, I will look into it. I think it was related to my
> onboard RTL networking chip. When trying to bring it down,
> it oopses the machine. But I'm not sure what happens exactly, yet.
> I'll take a look at it.
>
> > > Andrew, is it possible that the breakage was introduced in the
> > > merge process somehow? Didn't the patch apply cleanly? Are there
> > > other changes to b44 I should know about in your tree?
> >
> > Only git-wireless.net modifies b44.c but if we're having IRQ assignment
> > problems then we'd need to look elsewhere.
>
> I think we don't have IRQ assignment problems. Uwe simply disabled
> b44-PCI support in his first bugreport (I guess).

Yes!

> So there was 
> no b44-PCI driver loaded.

Well, not exactly: b44 plus ssb were in fact produced, but did not function, 
at least in that case, due to the misleading / superficial information in the 
Kconfig menu......

> Later on he said that it does magically work now...

NO!

Later on I said I did chose that b44-PCI driver, got the right dependencies,
and there was no interrupt problem at all. So the driver got loaded as 
expected but simply did not work at all......

Cheers

Uwe

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

[Michael Buesch]

On Saturday 26 May 2007 18:26:06 Uwe Bugla wrote:
> > I think we don't have IRQ assignment problems. Uwe simply disabled
> > b44-PCI support in his first bugreport (I guess).
> 
> Yes!
> 
> > So there was 
> > no b44-PCI driver loaded.
> 
> Well, not exactly: b44 plus ssb were in fact produced, but did not function, 
> at least in that case, due to the misleading / superficial information in the 
> Kconfig menu......
> 
> > Later on he said that it does magically work now...
> 
> NO!
> 
> Later on I said I did chose that b44-PCI driver, got the right dependencies,
> and there was no interrupt problem at all. So the driver got loaded as 
> expected but simply did not work at all......

One small sidenote:
If you did _not_ play around with the b44/ssb kconfig options at all,
it would have selected the right options _automatically_ for you.
That means:

cp ../old_kernel_without_ssb/.config .
make oldconfig
make
be done.

You intentionaly disabled PCI device support for b44 and you
still wonder why it doesn't work on your PCI device?
I'm not sure how to make the helptext any clearer on the b44-PCI
option. We have _lots_ of other drivers in the tree that work
EXACTLY the same way, regarding to kconfig. There are _lots_
of drivers where there are seperate options for a "bus-glue".
b44-ssb is no different. And additionally it automatically
selects the right options for 99.9% of the users (you included).

So I'm not sure why you keep bashing the kconfig implementation
here. It's common practice to have seperate config options for
bus-glues and it _automatically_ selects the right options for
you.

-- 
Greetings Michael.

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

[Uwe Bugla]

Am Samstag, 26. Mai 2007 18:40 schrieben Sie:
> On Saturday 26 May 2007 18:26:06 Uwe Bugla wrote:
> > > I think we don't have IRQ assignment problems. Uwe simply disabled
> > > b44-PCI support in his first bugreport (I guess).
> >
> > Yes!
> >
> > > So there was
> > > no b44-PCI driver loaded.
> >
> > Well, not exactly: b44 plus ssb were in fact produced, but did not
> > function, at least in that case, due to the misleading / superficial
> > information in the Kconfig menu......
> >
> > > Later on he said that it does magically work now...
> >
> > NO!
> >
> > Later on I said I did chose that b44-PCI driver, got the right
> > dependencies, and there was no interrupt problem at all. So the driver
> > got loaded as expected but simply did not work at all......
>
> One small sidenote:
> If you did _not_ play around with the b44/ssb kconfig options at all,
> it would have selected the right options _automatically_ for you.
> That means:
>
> cp ../old_kernel_without_ssb/.config .
> make oldconfig
> make
> be done.
>
> You intentionaly disabled PCI device support for b44 and you
> still wonder why it doesn't work on your PCI device?
> I'm not sure how to make the helptext any clearer on the b44-PCI
> option. 

A. Up to 2.6.21 there was only a b44 PCI driver. So you get used to it working 
with the same machine for years and compiling kernels for it.
B. Now there are obviously some changes due to the "bus-glue". OK so far!

But: The help text in both cases is exactly the same. And exactly that is the 
misleading point!
The best way to put up a very clear distinction is to use some examples to 
explain the different cases. Now if you can offer me enough info on that I 
can try to do write a patch for that.
So we got the Broadcom PCI b44 NIC driver (as card, as onboard device)
and we got additionally what please as a new extension??
Just two or three examples would do it!
Above that perhaps the dependencies could be a bit more precise:

Wouldn't you get confused if you deselcted the PCI or Ethernet option, but 
still retaining the same b44 driver selected as module with the identical 
help text?

Is that so hard to understand?

> We have _lots_ of other drivers in the tree that work 
> EXACTLY the same way, regarding to kconfig. There are _lots_
> of drivers where there are seperate options for a "bus-glue".
> b44-ssb is no different. And additionally it automatically
> selects the right options for 99.9% of the users (you included).

Yes, sure! But the help text is very unlucky and humble, and it is not clear 
enough in the sense of being distinctive enough, just clear and 
comprehensive.

>
> So I'm not sure why you keep bashing the kconfig implementation
> here. It's common practice to have seperate config options for
> bus-glues and it _automatically_ selects the right options for
> you.

Yes! But you need to EXPLAIN that "bus-glue" in the Kconfig help text in some 
two or three sentences. That shouldn't be that hard, should it?

And that is exactly the basic function of a Kconfig help text: To explain 
kernel compilation choices to users!

It is very very easy to simply ignore that fact and then, afterwards, call all 
people dumb who are not "omniscient" at all to see the differences through.
Where should they know from if they are not identical with your personality?

Cheers

Uwe

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

[Michael Buesch]

On Saturday 26 May 2007 19:04:04 Uwe Bugla wrote:
> Yes, sure! But the help text is very unlucky and humble, and it is not clear 
> enough in the sense of being distinctive enough, just clear and 
> comprehensive.

Why don't you simply submit a patch to change the helptext then?
I'm not sure why you refuse to DO anything about the "mess", but
instead keep poking me that I am responsible somehow to fix it up
for you...

> >
> > So I'm not sure why you keep bashing the kconfig implementation
> > here. It's common practice to have seperate config options for
> > bus-glues and it _automatically_ selects the right options for
> > you.
> 
> Yes! But you need to EXPLAIN that "bus-glue" in the Kconfig help text in some 
> two or three sentences. That shouldn't be that hard, should it?

Ok, go for it.

-- 
Greetings Michael.

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

[Uwe Bugla]

Am Samstag, 26. Mai 2007 19:18 schrieben Sie:
> On Saturday 26 May 2007 19:04:04 Uwe Bugla wrote:
> > Yes, sure! But the help text is very unlucky and humble, and it is not
> > clear enough in the sense of being distinctive enough, just clear and
> > comprehensive.
>
> Why don't you simply submit a patch to change the helptext then?
> I'm not sure why you refuse to DO anything about the "mess", but
> instead keep poking me that I am responsible somehow to fix it up
> for you...

I need exception examples for doing so. What are the exception examples?

Apart from that you have don nothing except than guessing around.

Now here comes the LAST proof that your code is buggy:

A. It's not mm-implementation
B. It's not user behaviour or fault
C. It's not an ACPI issue

BUT ONE AND ONLY:

D. It's your code that is buggy, without any doubt!

>
> > > So I'm not sure why you keep bashing the kconfig implementation
> > > here. It's common practice to have seperate config options for
> > > bus-glues and it _automatically_ selects the right options for
> > > you.
> >
> > Yes! But you need to EXPLAIN that "bus-glue" in the Kconfig help text in
> > some two or three sentences. That shouldn't be that hard, should it?
>
> Ok, go for it.
I need exception examples for doing so. What are the exception examples?

OK, went Andrew's path: patched 2.6.22-rc3 with wireless tree:

Result: The NIC driver b44 and ssb are loaded correctly, but refuse to work
(no network communication possible).

dmesg:

Linux version 2.6.22-rc3 (root@brian) (gcc version 4.1.2 20061115 (prerelease) 
(Debian 4.1.1-21)) #1 PREEMPT Sat May 26 18:53:23 CEST 2007
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000001ffec000 (usable)
 BIOS-e820: 000000001ffec000 - 000000001ffef000 (ACPI data)
 BIOS-e820: 000000001ffef000 - 000000001ffff000 (reserved)
 BIOS-e820: 000000001ffff000 - 0000000020000000 (ACPI NVS)
 BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
 BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
511MB LOWMEM available.
Entering add_active_range(0, 0, 131052) 0 entries of 256 used
Zone PFN ranges:
  DMA             0 ->     4096
  Normal       4096 ->   131052
early_node_map[1] active PFN ranges
    0:        0 ->   131052
On node 0 totalpages: 131052
  DMA zone: 32 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 4064 pages, LIFO batch:0
  Normal zone: 991 pages used for memmap
  Normal zone: 125965 pages, LIFO batch:31
DMI 2.3 present.
ACPI: RSDP 000F5360, 0014 (r0 ASUS  )
ACPI: RSDT 1FFEC000, 0030 (r1 ASUS   P4PE     42302E31 MSFT 31313031)
ACPI: FACP 1FFEC0C0, 0074 (r1 ASUS   P4PE     42302E31 MSFT 31313031)
ACPI: DSDT 1FFEC134, 2A43 (r1   ASUS P4PE         1000 MSFT  100000B)
ACPI: FACS 1FFFF000, 0040
ACPI: BOOT 1FFEC030, 0028 (r1 ASUS   P4PE     42302E31 MSFT 31313031)
ACPI: APIC 1FFEC058, 005A (r1 ASUS   P4PE     42302E31 MSFT 31313031)
ACPI: PM-Timer IO Port: 0xe408
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 15:2 APIC version 20
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl edge)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 22 low level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 30000000 (gap: 20000000:dec00000)
Built 1 zonelists.  Total pages: 130029
Kernel command line: root=/dev/hda1 ro vga=791
mapped APIC to ffffd000 (fee00000)
mapped IOAPIC to ffffc000 (fec00000)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
PID hash table entries: 2048 (order: 11, 8192 bytes)
Detected 1818.044 MHz processor.
Console: colour dummy device 80x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 517056k/524208k available (1330k kernel code, 6608k reserved, 480k 
data, 136k init, 0k highmem)
virtual kernel memory layout:
    fixmap  : 0xfffb8000 - 0xfffff000   ( 284 kB)
    vmalloc : 0xe0800000 - 0xfffb6000   ( 503 MB)
    lowmem  : 0xc0000000 - 0xdffec000   ( 511 MB)
      .init : 0xc02c8000 - 0xc02ea000   ( 136 kB)
      .data : 0xc024cb0a - 0xc02c4c90   ( 480 kB)
      .text : 0xc0100000 - 0xc024cb0a   (1330 kB)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 3637.55 BogoMIPS 
(lpj=1818777)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 3febfbff 00000000 00000000 00000000 
00000000 00000000 00000000
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: After all inits, caps: 3febfbff 00000000 00000000 0000b080 00000000 
00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU0: Intel P4/Xeon Extended MCE MSRs (12) available
CPU0: Thermal monitoring enabled
Compat vDSO mapped to ffffe000.
CPU: Intel(R) Pentium(R) 4 CPU 1.80GHz stepping 04
Checking 'hlt' instruction... OK.
ACPI: Core revision 20070126
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xf1e60, last bus=2
Setting up standard PCI resources
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
* The chipset may have PM-Timer Bug. Due to workarounds for a bug,
* this clock source is slow. If you are sure your timer does not have
* this bug, please use "acpi_pm_good" to disable the workaround
PCI quirk: region e400-e47f claimed by ICH4 ACPI/GPIO/TCO
PCI quirk: region ec00-ec3f claimed by ICH4 GPIO
PCI: Enabled i801 SMBus device
PCI: Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI2._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, 
disabled.
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, 
disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, 
disabled.
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, 
disabled.
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, 
disabled.
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
ACPI: bus type pnp registered
pnp: PnP ACPI: found 17 devices
ACPI: ACPI bus type pnp unregistered
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
pnp: 00:00: iomem range 0x0-0x9ffff could not be reserved
pnp: 00:00: iomem range 0xf0000-0xfffff could not be reserved
pnp: 00:00: iomem range 0x100000-0x1fffffff could not be reserved
pnp: 00:00: iomem range 0xfec00000-0xfec000ff could not be reserved
pnp: 00:02: ioport range 0xe400-0xe47f has been reserved
pnp: 00:02: ioport range 0xe800-0xe81f has been reserved
pnp: 00:02: ioport range 0xec00-0xec3f has been reserved
pnp: 00:02: ioport range 0x4d6-0x4d6 has been reserved
pnp: 00:02: iomem range 0xfff80000-0xffffffff could not be reserved
pnp: 00:02: iomem range 0xffb80000-0xffbfffff has been reserved
pnp: 00:10: ioport range 0x3f0-0x3f1 has been reserved
Time: tsc clocksource has been installed.
PCI: Bridge: 0000:00:01.0
  IO window: d000-dfff
  MEM window: f2000000-f27fffff
  PREFETCH window: f3f00000-f7ffffff
PCI: Bridge: 0000:00:1e.0
  IO window: disabled.
  MEM window: f1000000-f17fffff
  PREFETCH window: f2800000-f3efffff
PCI: Setting latency timer of device 0000:00:1e.0 to 64
NET: Registered protocol family 2
IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
TCP established hash table entries: 16384 (order: 5, 131072 bytes)
TCP bind hash table entries: 16384 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 16384 bind 16384)
TCP reno registered
Simple Boot Flag at 0x3a set to 0x80
io scheduler noop registered (default)
Boot video device is 0000:01:00.0
vesafb: framebuffer at 0xf4000000, mapped to 0xe0880000, using 3072k, total 
32768k
vesafb: mode is 1024x768x16, linelength=2048, pages=20
vesafb: protected mode interface info at c000:441b
vesafb: pmi: set display start = c00c4489, set palette = c00c44c3
vesafb: pmi: ports = d810 d816 d854 d838 d83c d85c d800 d804 d8b0 d8b2 d8b4 
vesafb: scrolling: redraw
vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
Console: switching to colour frame buffer device 128x48
fb0: VESA VGA frame buffer device
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH4: IDE controller at PCI slot 0000:00:1f.1
ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 16
ICH4: chipset revision 2
ICH4: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA
Probing IDE interface ide0...
hda: IC35L080AVVA07-0, ATA DISK drive
hda: selected mode 0x45
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hdc: HL-DT-STDVD-ROM GDR8163B, ATAPI CD/DVD-ROM drive
hdd: CD-W54E, ATAPI CD/DVD-ROM drive
hdc: selected mode 0x42
hdd: selected mode 0x22
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128KiB
hda: 160836480 sectors (82348 MB) w/1863KiB Cache, CHS=65535/16/63, UDMA(100)
hda: cache flushes supported
 hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 >
TCP cubic registered
Using IPI Shortcut mode
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 136k freed
NET: Registered protocol family 1
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
USB Universal Host Controller Interface driver v3.0
ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 16 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:00:1d.0 to 64
uhci_hcd 0000:00:1d.0: UHCI Host Controller
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:1d.0: irq 17, io base 0x0000b800
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 18
PCI: Setting latency timer of device 0000:00:1d.1 to 64
uhci_hcd 0000:00:1d.1: UHCI Host Controller
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:1d.1: irq 18, io base 0x0000b400
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
Floppy drive(s): fd0 is 1.44M
ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1d.2 to 64
uhci_hcd 0000:00:1d.2: UHCI Host Controller
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:1d.2: irq 16, io base 0x0000b000
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
FDC 0 is a post-1991 82077
parport_pc 00:09: reported by Plug and Play ACPI
parport0: PC-style at 0x378, irq 7 [PCSPP(,...)]
hdc: ATAPI 52X DVD-ROM drive, 256kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
Linux video capture interface: v2.00
hdd: ATAPI 32X CD-ROM CD-R/RW drive, 1280kB Cache, DMA
PCI: Enabling device 0000:00:1d.7 (0004 -> 0006)
ACPI: PCI Interrupt 0000:00:1d.7[D] -> GSI 23 (level, low) -> IRQ 19
PCI: Setting latency timer of device 0000:00:1d.7 to 64
ehci_hcd 0000:00:1d.7: EHCI Host Controller
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 4
ehci_hcd 0000:00:1d.7: debug port 1
PCI: cache line size of 128 is not supported by device 0000:00:1d.7
ehci_hcd 0000:00:1d.7: irq 19, io mem 0xf1800000
ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb4: configuration #1 chosen from 1 choice
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 6 ports detected
bttv: driver version 0.9.17 loaded
bttv: using 8 buffers with 2080k (520 pages) each for capture
ACPI: PCI Interrupt 0000:00:1f.3[B] -> GSI 17 (level, low) -> IRQ 20
PCI: Enabling device 0000:02:05.0 (0004 -> 0006)
ACPI: PCI Interrupt 0000:02:05.0[A] -> GSI 20 (level, low) -> IRQ 21
ssb: Core 0 found: Fast Ethernet (cc 0x806, rev 0x04, vendor 0x4243)
ssb: Core 1 found: V90 (cc 0x807, rev 0x01, vendor 0x4243)
ssb: Core 2 found: PCI (cc 0x804, rev 0x02, vendor 0x4243)
ssb: Switching to PCI core, index 2
ssb: Sonics Silicon Backplane found on PCI device 0000:02:05.0
b44.c:v2.0
ssb: Switching to Fast Ethernet core, index 0
ssb: Switching to PCI core, index 2
ssb: Switching to Fast Ethernet core, index 0
ssb: Switching to PCI core, index 2
ssb: Switching to Fast Ethernet core, index 0
eth0: Broadcom 44xx/47xx 10/100BaseT Ethernet 00:0c:6e:19:46:cf
bttv: Bt8xx card found (0).
PCI: Enabling device 0000:02:0b.0 (0004 -> 0006)
ACPI: PCI Interrupt 0000:02:0b.0[A] -> GSI 23 (level, low) -> IRQ 19
bttv0: Bt878 (rev 17) at 0000:02:0b.0, irq: 19, latency: 32, mmio: 0xf3000000
bttv0: detected: Pinnacle PCTV Sat [card=94], PCI subsystem ID is 11bd:001c
bttv0: using: Pinnacle PCTV Sat [card=94,autodetected]
bttv0: gpio: en=00000000, out=00000000 in=00df00fc [init]
bttv0: using tuner=-1
bttv0: registered device video0
bttv0: registered device vbi0
bttv0: PLL: 28636363 => 35468950 .. ok
bttv0: add subdevice "dvb0"
PCI: Enabling device 0000:00:1f.5 (0004 -> 0007)
ACPI: PCI Interrupt 0000:00:1f.5[B] -> GSI 17 (level, low) -> IRQ 20
PCI: Setting latency timer of device 0000:00:1f.5 to 64
bt878: AUDIO driver version 0.0.0 loaded
AC'97 0 analog subsections not ready
intel8x0_measure_ac97_clock: measured 50779 usecs
intel8x0: clocking to 48000
bt878: Bt878 AUDIO function found (0).
PCI: Enabling device 0000:02:0b.1 (0004 -> 0006)
ACPI: PCI Interrupt 0000:02:0b.1[A] -> GSI 23 (level, low) -> IRQ 19
bt878_probe: card id=[0x1c11bd],[ Pinnacle PCTV Sat ] has DVB functions.
bt878(0): Bt878 (rev 17) at 02:0b.1, irq: 19, latency: 32, memory: 0xf2800000
DVB: registering new adapter (bttv0).
DVB: registering frontend 0 (Conexant CX24110 DVB-S)...
Adding 1951856k swap on /dev/hda6.  Priority:-1 extents:1 across:1951856k
EXT3 FS on hda1, internal journal
input: Power Button (FF) as /class/input/input0
ACPI: Power Button (FF) [PWRF]
input: Power Button (CM) as /class/input/input1
ACPI: Power Button (CM) [PWRB]
ACPI: Invalid PBLK length [5]
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
NET: Registered protocol family 17
mice: PS/2 mouse device common for all mice
PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
loop: module loaded
input: AT Translated Set 2 keyboard as /class/input/input2
logips2pp: Detected unknown logitech mouse model 11
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda7, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda3, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda2, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda5, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
input: PS/2 Logitech Mouse as /class/input/input3
b44: eth0: Link is up at 100 Mbps, full duplex.
b44: eth0: Flow control is off for TX and off for RX.
mtrr: no MTRR for f4000000,2000000 found
Linux agpgart interface v0.102 (c) Dave Jones
[drm] Initialized drm 1.1.0 20060810
ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 17
[drm] Initialized r128 2.5.0 20030725 on minor 0


.config:

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.22-rc3
# Sat May 26 18:42:57 2007
#
CONFIG_X86_32=y
CONFIG_GENERIC_TIME=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_QUICKLIST=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_IPC_NS is not set
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
# CONFIG_TASKSTATS is not set
# CONFIG_UTS_NS is not set
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=m
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=14
CONFIG_SYSFS_DEPRECATED=y
# CONFIG_RELAY is not set
# CONFIG_BLK_DEV_INITRD is not set
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_EMBEDDED=y
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y

#
# Block layer
#
CONFIG_BLOCK=y
# CONFIG_LBD is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=m
CONFIG_IOSCHED_DEADLINE=m
CONFIG_IOSCHED_CFQ=m
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
CONFIG_DEFAULT_NOOP=y
CONFIG_DEFAULT_IOSCHED="noop"

#
# Processor type and features
#
# CONFIG_TICK_ONESHOT is not set
# CONFIG_NO_HZ is not set
# CONFIG_HIGH_RES_TIMERS is not set
# CONFIG_SMP is not set
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_PARAVIRT is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MCORE2 is not set
CONFIG_MPENTIUM4=y
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_MVIAC7 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_X86_XADD=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_MODEL=4
# CONFIG_HPET_TIMER is not set
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=m
CONFIG_X86_MCE_P4THERMAL=y
# CONFIG_VM86 is not set
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_X86_REBOOTFIXUPS is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
CONFIG_X86_CPUID=m

#
# Firmware Drivers
#
# CONFIG_EDD is not set
# CONFIG_DELL_RBU is not set
# CONFIG_DCDBAS is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
CONFIG_VMSPLIT_3G=y
# CONFIG_VMSPLIT_3G_OPT is not set
# CONFIG_VMSPLIT_2G is not set
# CONFIG_VMSPLIT_2G_OPT is not set
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_SPARSEMEM_STATIC=y
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_RESOURCES_64BIT is not set
CONFIG_ZONE_DMA_FLAG=1
CONFIG_NR_QUICK=1
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_EFI is not set
CONFIG_SECCOMP=y
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000
# CONFIG_KEXEC is not set
CONFIG_PHYSICAL_START=0x100000
# CONFIG_RELOCATABLE is not set
CONFIG_PHYSICAL_ALIGN=0x100000
CONFIG_COMPAT_VDSO=y

#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
# CONFIG_PM_LEGACY is not set
# CONFIG_PM_DEBUG is not set
# CONFIG_PM_SYSFS_DEPRECATED is not set
# CONFIG_SOFTWARE_SUSPEND is not set

#
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
# CONFIG_ACPI_SLEEP is not set
CONFIG_ACPI_PROCFS=y
# CONFIG_ACPI_AC is not set
# CONFIG_ACPI_BATTERY is not set
CONFIG_ACPI_BUTTON=m
CONFIG_ACPI_FAN=m
# CONFIG_ACPI_DOCK is not set
CONFIG_ACPI_PROCESSOR=m
CONFIG_ACPI_THERMAL=m
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_TOSHIBA is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
# CONFIG_ACPI_CONTAINER is not set
# CONFIG_ACPI_SBS is not set
# CONFIG_APM is not set

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
CONFIG_PCI_GOBIOS=y
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
# CONFIG_PCI_GOANY is not set
CONFIG_PCI_BIOS=y
# CONFIG_PCIEPORTBUS is not set
CONFIG_ARCH_SUPPORTS_MSI=y
# CONFIG_PCI_MSI is not set
CONFIG_HT_IRQ=y
CONFIG_ISA_DMA_API=y
# CONFIG_ISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set

#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set
# CONFIG_HOTPLUG_PCI is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=m
CONFIG_BINFMT_MISC=m

#
# Networking
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=m
# CONFIG_PACKET_MMAP is not set
CONFIG_UNIX=m
CONFIG_XFRM=y
CONFIG_XFRM_USER=m
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
# CONFIG_NET_KEY is not set
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
CONFIG_INET_XFRM_TUNNEL=m
CONFIG_INET_TUNNEL=m
CONFIG_INET_XFRM_MODE_TRANSPORT=m
CONFIG_INET_XFRM_MODE_TUNNEL=m
CONFIG_INET_XFRM_MODE_BEET=m
CONFIG_INET_DIAG=m
CONFIG_INET_TCP_DIAG=m
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IPV6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETFILTER is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set

#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set

#
# Wireless
#
# CONFIG_CFG80211 is not set
# CONFIG_WIRELESS_EXT is not set
# CONFIG_MAC80211 is not set
# CONFIG_IEEE80211 is not set
# CONFIG_RFKILL is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=m
# CONFIG_SYS_HYPERVISOR is not set

#
# Connector - unified userspace <-> kernelspace linker
#
# CONFIG_CONNECTOR is not set
# CONFIG_MTD is not set

#
# Parallel port support
#
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
# CONFIG_PARPORT_SERIAL is not set
# CONFIG_PARPORT_PC_FIFO is not set
# CONFIG_PARPORT_PC_SUPERIO is not set
# CONFIG_PARPORT_GSC is not set
# CONFIG_PARPORT_AX88796 is not set
# CONFIG_PARPORT_1284 is not set

#
# Plug and Play support
#
CONFIG_PNP=y
# CONFIG_PNP_DEBUG is not set

#
# Protocols
#
CONFIG_PNPACPI=y

#
# Block devices
#
CONFIG_BLK_DEV_FD=m
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=m
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
# CONFIG_BLK_DEV_RAM is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set

#
# Misc devices
#
# CONFIG_IBM_ASM is not set
# CONFIG_PHANTOM is not set
# CONFIG_SGI_IOC4 is not set
# CONFIG_TIFM_CORE is not set
# CONFIG_SONY_LAPTOP is not set
# CONFIG_THINKPAD_ACPI is not set
# CONFIG_BLINK is not set
# CONFIG_EEPROM_93CX6 is not set
CONFIG_IDE=y
CONFIG_IDE_MAX_HWIFS=4
CONFIG_BLK_DEV_IDE=y

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_IDE_SATA is not set
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
# CONFIG_IDEDISK_MULTI_MODE is not set
CONFIG_BLK_DEV_IDECD=m
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
# CONFIG_BLK_DEV_IDEACPI is not set
# CONFIG_IDE_TASK_IOCTL is not set
CONFIG_IDE_PROC_FS=y

#
# IDE chipset support/bugfixes
#
# CONFIG_IDE_GENERIC is not set
# CONFIG_BLK_DEV_CMD640 is not set
# CONFIG_BLK_DEV_IDEPNP is not set
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_IDEPCI_PCIBUS_ORDER=y
# CONFIG_BLK_DEV_OFFBOARD is not set
# CONFIG_BLK_DEV_GENERIC is not set
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_RZ1000 is not set
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
# CONFIG_IDEDMA_ONLYDISK is not set
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_BLK_DEV_ATIIXP is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5520 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_CS5535 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_JMICRON is not set
# CONFIG_BLK_DEV_SC1200 is not set
CONFIG_BLK_DEV_PIIX=y
# CONFIG_BLK_DEV_IT8213 is not set
# CONFIG_BLK_DEV_IT821X is not set
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
# CONFIG_BLK_DEV_PDC202XX_NEW is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_VIA82CXXX is not set
# CONFIG_BLK_DEV_TC86C001 is not set
# CONFIG_IDE_ARM is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
# CONFIG_BLK_DEV_HD is not set

#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
# CONFIG_SCSI is not set
# CONFIG_SCSI_NETLINK is not set
# CONFIG_ATA is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support
#
# CONFIG_FIREWIRE is not set
# CONFIG_IEEE1394 is not set

#
# I2O device support
#
# CONFIG_I2O is not set
# CONFIG_MACINTOSH_DRIVERS is not set

#
# Network device support
#
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_NET_SB1000 is not set
# CONFIG_ARCNET is not set
# CONFIG_PHYLIB is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=m
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
# CONFIG_NET_VENDOR_3COM is not set

#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
CONFIG_B44=m
CONFIG_B44_PCI=y
# CONFIG_FORCEDETH is not set
# CONFIG_DGRS is not set
# CONFIG_EEPRO100 is not set
# CONFIG_E100 is not set
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_8139CP is not set
# CONFIG_8139TOO is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_SC92031 is not set
# CONFIG_NET_POCKET is not set
CONFIG_NETDEV_1000=y
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
# CONFIG_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set
# CONFIG_BNX2 is not set
# CONFIG_QLA3XXX is not set
# CONFIG_ATL1 is not set
CONFIG_NETDEV_10000=y
# CONFIG_CHELSIO_T1 is not set
# CONFIG_CHELSIO_T3 is not set
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set
# CONFIG_MYRI10GE is not set
# CONFIG_NETXEN_NIC is not set
# CONFIG_MLX4_CORE is not set
# CONFIG_TR is not set

#
# Wireless LAN
#
# CONFIG_WLAN_PRE80211 is not set
# CONFIG_WLAN_80211 is not set
# CONFIG_RTL818X is not set

#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET_MII is not set
# CONFIG_USB_USBNET is not set
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PLIP is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=m
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=m
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=m
# CONFIG_MOUSE_PS2_ALPS is not set
CONFIG_MOUSE_PS2_LOGIPS2PP=y
# CONFIG_MOUSE_PS2_SYNAPTICS is not set
# CONFIG_MOUSE_PS2_LIFEBOOK is not set
# CONFIG_MOUSE_PS2_TRACKPOINT is not set
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_APPLETOUCH is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=m
CONFIG_SERIO_I8042=m
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PARKBD is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=m
# CONFIG_SERIO_RAW is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
# CONFIG_SERIAL_NONSTANDARD is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=m
CONFIG_SERIAL_8250_PCI=m
# CONFIG_SERIAL_8250_PNP is not set
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=m
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
# CONFIG_LEGACY_PTYS is not set
CONFIG_PRINTER=m
# CONFIG_LP_CONSOLE is not set
# CONFIG_PPDEV is not set
# CONFIG_TIPAR is not set

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set
# CONFIG_WATCHDOG is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_NVRAM is not set
# CONFIG_RTC is not set
# CONFIG_GEN_RTC is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set
CONFIG_AGP=m
# CONFIG_AGP_ALI is not set
CONFIG_AGP_ATI=m
# CONFIG_AGP_AMD is not set
# CONFIG_AGP_AMD64 is not set
# CONFIG_AGP_INTEL is not set
# CONFIG_AGP_NVIDIA is not set
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_SWORKS is not set
# CONFIG_AGP_VIA is not set
# CONFIG_AGP_EFFICEON is not set
CONFIG_DRM=m
# CONFIG_DRM_TDFX is not set
CONFIG_DRM_R128=m
# CONFIG_DRM_RADEON is not set
# CONFIG_DRM_MGA is not set
# CONFIG_DRM_SIS is not set
# CONFIG_DRM_VIA is not set
# CONFIG_DRM_SAVAGE is not set
# CONFIG_MWAVE is not set
# CONFIG_PC8736x_GPIO is not set
# CONFIG_NSC_GPIO is not set
# CONFIG_CS5535_GPIO is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HPET is not set
# CONFIG_HANGCHECK_TIMER is not set

#
# TPM devices
#
# CONFIG_TCG_TPM is not set
# CONFIG_TELCLOCK is not set
CONFIG_DEVPORT=y
CONFIG_I2C=m
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_CHARDEV=m

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=m
# CONFIG_I2C_ALGOPCF is not set
# CONFIG_I2C_ALGOPCA is not set

#
# I2C Hardware Bus support
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
CONFIG_I2C_I801=m
# CONFIG_I2C_I810 is not set
# CONFIG_I2C_PIIX4 is not set
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_PARPORT is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_PROSAVAGE is not set
# CONFIG_I2C_SAVAGE4 is not set
# CONFIG_I2C_SIMTEC is not set
# CONFIG_SCx200_ACB is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_TINY_USB is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set
# CONFIG_I2C_VOODOO3 is not set

#
# Miscellaneous I2C Chip support
#
# CONFIG_SENSORS_DS1337 is not set
# CONFIG_SENSORS_DS1374 is not set
# CONFIG_SENSORS_EEPROM is not set
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_SENSORS_PCA9539 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_MAX6875 is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set

#
# SPI support
#
# CONFIG_SPI is not set
# CONFIG_SPI_MASTER is not set

#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set
# CONFIG_HWMON is not set

#
# Sonics Silicon Backplane
#
CONFIG_SSB=m
CONFIG_SSB_PCIHOST=y
# CONFIG_SSB_SILENT is not set
CONFIG_SSB_DEBUG=y
CONFIG_SSB_DRIVER_PCICORE=y

#
# Multifunction device drivers
#
# CONFIG_MFD_SM501 is not set

#
# Multimedia devices
#
CONFIG_VIDEO_DEV=m
CONFIG_VIDEO_V4L1=y
CONFIG_VIDEO_V4L1_COMPAT=y
CONFIG_VIDEO_V4L2=y
CONFIG_VIDEO_CAPTURE_DRIVERS=y
# CONFIG_VIDEO_ADV_DEBUG is not set
# CONFIG_VIDEO_HELPER_CHIPS_AUTO is not set

#
# Encoders/decoders and other helper chips
#

#
# Audio decoders
#
# CONFIG_VIDEO_TVAUDIO is not set
# CONFIG_VIDEO_TDA7432 is not set
# CONFIG_VIDEO_TDA9840 is not set
# CONFIG_VIDEO_TDA9875 is not set
# CONFIG_VIDEO_TEA6415C is not set
# CONFIG_VIDEO_TEA6420 is not set
# CONFIG_VIDEO_MSP3400 is not set
# CONFIG_VIDEO_CS53L32A is not set
# CONFIG_VIDEO_TLV320AIC23B is not set
# CONFIG_VIDEO_WM8775 is not set
# CONFIG_VIDEO_WM8739 is not set

#
# Video decoders
#
# CONFIG_VIDEO_BT819 is not set
# CONFIG_VIDEO_BT856 is not set
# CONFIG_VIDEO_BT866 is not set
# CONFIG_VIDEO_KS0127 is not set
# CONFIG_VIDEO_OV7670 is not set
# CONFIG_VIDEO_SAA7110 is not set
# CONFIG_VIDEO_SAA7111 is not set
# CONFIG_VIDEO_SAA7114 is not set
# CONFIG_VIDEO_SAA711X is not set
# CONFIG_VIDEO_SAA7191 is not set
# CONFIG_VIDEO_TVP5150 is not set
# CONFIG_VIDEO_VPX3220 is not set

#
# Video and audio decoders
#
# CONFIG_VIDEO_CX25840 is not set

#
# MPEG video encoders
#
# CONFIG_VIDEO_CX2341X is not set

#
# Video encoders
#
# CONFIG_VIDEO_SAA7127 is not set
# CONFIG_VIDEO_SAA7185 is not set
# CONFIG_VIDEO_ADV7170 is not set
# CONFIG_VIDEO_ADV7175 is not set

#
# Video improvement chips
#
# CONFIG_VIDEO_UPD64031A is not set
# CONFIG_VIDEO_UPD64083 is not set
# CONFIG_VIDEO_VIVI is not set
CONFIG_VIDEO_BT848=m
# CONFIG_VIDEO_BT848_DVB is not set
# CONFIG_VIDEO_SAA6588 is not set
# CONFIG_VIDEO_BWQCAM is not set
# CONFIG_VIDEO_CQCAM is not set
# CONFIG_VIDEO_CPIA is not set
# CONFIG_VIDEO_CPIA2 is not set
# CONFIG_VIDEO_SAA5246A is not set
# CONFIG_VIDEO_SAA5249 is not set
# CONFIG_TUNER_3036 is not set
# CONFIG_VIDEO_STRADIS is not set
# CONFIG_VIDEO_ZORAN is not set
# CONFIG_VIDEO_SAA7134 is not set
# CONFIG_VIDEO_MXB is not set
# CONFIG_VIDEO_DPC is not set
# CONFIG_VIDEO_HEXIUM_ORION is not set
# CONFIG_VIDEO_HEXIUM_GEMINI is not set
# CONFIG_VIDEO_CX88 is not set
# CONFIG_VIDEO_IVTV is not set
# CONFIG_VIDEO_CAFE_CCIC is not set
CONFIG_V4L_USB_DRIVERS=y
# CONFIG_VIDEO_PVRUSB2 is not set
# CONFIG_VIDEO_EM28XX is not set
# CONFIG_VIDEO_USBVISION is not set
# CONFIG_USB_VICAM is not set
# CONFIG_USB_IBMCAM is not set
# CONFIG_USB_KONICAWC is not set
# CONFIG_USB_QUICKCAM_MESSENGER is not set
# CONFIG_USB_ET61X251 is not set
# CONFIG_VIDEO_OVCAMCHIP is not set
# CONFIG_USB_W9968CF is not set
# CONFIG_USB_OV511 is not set
# CONFIG_USB_SE401 is not set
# CONFIG_USB_SN9C102 is not set
# CONFIG_USB_STV680 is not set
# CONFIG_USB_ZC0301 is not set
# CONFIG_USB_PWC is not set
# CONFIG_USB_ZR364XX is not set
CONFIG_RADIO_ADAPTERS=y
# CONFIG_RADIO_GEMTEK_PCI is not set
# CONFIG_RADIO_MAXIRADIO is not set
# CONFIG_RADIO_MAESTRO is not set
# CONFIG_USB_DSBR is not set
CONFIG_DVB_CORE=m
CONFIG_DVB_CORE_ATTACH=y
CONFIG_DVB_CAPTURE_DRIVERS=y

#
# Supported SAA7146 based PCI Adapters
#
# CONFIG_DVB_AV7110 is not set
# CONFIG_DVB_BUDGET is not set
# CONFIG_DVB_BUDGET_CI is not set
# CONFIG_DVB_BUDGET_AV is not set

#
# Supported USB Adapters
#
# CONFIG_DVB_USB is not set
# CONFIG_DVB_TTUSB_BUDGET is not set
# CONFIG_DVB_TTUSB_DEC is not set
# CONFIG_DVB_CINERGYT2 is not set

#
# Supported FlexCopII (B2C2) Adapters
#
# CONFIG_DVB_B2C2_FLEXCOP is not set

#
# Supported BT878 Adapters
#
CONFIG_DVB_BT8XX=m

#
# TwinHan DST (CA) and clone cards
#
CONFIG_DVB_DST_CUSTOMISE=y
# CONFIG_DVB_DST is not set
# CONFIG_DVB_DST_CA is not set

#
# Supported Pluto2 Adapters
#
# CONFIG_DVB_PLUTO2 is not set

#
# Supported DVB Frontends
#

#
# Customise DVB Frontends
#
CONFIG_DVB_FE_CUSTOMISE=y

#
# DVB-S (satellite) frontends
#
# CONFIG_DVB_STV0299 is not set
CONFIG_DVB_CX24110=m
# CONFIG_DVB_CX24123 is not set
# CONFIG_DVB_TDA8083 is not set
# CONFIG_DVB_MT312 is not set
# CONFIG_DVB_VES1X93 is not set
# CONFIG_DVB_S5H1420 is not set
# CONFIG_DVB_TDA10086 is not set

#
# DVB-T (terrestrial) frontends
#
# CONFIG_DVB_SP8870 is not set
# CONFIG_DVB_SP887X is not set
# CONFIG_DVB_CX22700 is not set
# CONFIG_DVB_CX22702 is not set
# CONFIG_DVB_L64781 is not set
# CONFIG_DVB_TDA1004X is not set
# CONFIG_DVB_NXT6000 is not set
# CONFIG_DVB_MT352 is not set
# CONFIG_DVB_ZL10353 is not set
# CONFIG_DVB_DIB3000MB is not set
# CONFIG_DVB_DIB3000MC is not set
# CONFIG_DVB_DIB7000M is not set
# CONFIG_DVB_DIB7000P is not set

#
# DVB-C (cable) frontends
#
# CONFIG_DVB_VES1820 is not set
# CONFIG_DVB_TDA10021 is not set
# CONFIG_DVB_TDA10023 is not set
# CONFIG_DVB_STV0297 is not set

#
# ATSC (North American/Korean Terrestrial/Cable DTV) frontends
#
# CONFIG_DVB_NXT200X is not set
# CONFIG_DVB_OR51211 is not set
# CONFIG_DVB_OR51132 is not set
# CONFIG_DVB_BCM3510 is not set
# CONFIG_DVB_LGDT330X is not set

#
# Tuners/PLL support
#
# CONFIG_DVB_PLL is not set
# CONFIG_DVB_TDA826X is not set
# CONFIG_DVB_TDA827X is not set
# CONFIG_DVB_TUNER_QT1010 is not set
# CONFIG_DVB_TUNER_MT2060 is not set

#
# Miscellaneous devices
#
# CONFIG_DVB_LNBP21 is not set
# CONFIG_DVB_ISL6421 is not set
# CONFIG_DVB_TUA6100 is not set
CONFIG_VIDEO_TUNER=m
CONFIG_VIDEO_BUF=m
CONFIG_VIDEO_BTCX=m
CONFIG_VIDEO_IR=m
CONFIG_VIDEO_TVEEPROM=m
# CONFIG_DAB is not set

#
# Graphics support
#
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set

#
# Display device support
#
# CONFIG_DISPLAY_SUPPORT is not set
# CONFIG_VGASTATE is not set
CONFIG_FB=y
# CONFIG_FIRMWARE_EDID is not set
# CONFIG_FB_DDC is not set
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_SYS_FILLRECT is not set
# CONFIG_FB_SYS_COPYAREA is not set
# CONFIG_FB_SYS_IMAGEBLIT is not set
# CONFIG_FB_SYS_FOPS is not set
CONFIG_FB_DEFERRED_IO=y
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
# CONFIG_FB_MODE_HELPERS is not set
# CONFIG_FB_TILEBLITTING is not set

#
# Frame buffer hardware drivers
#
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not set
CONFIG_FB_VESA=y
# CONFIG_FB_HECUBA is not set
# CONFIG_FB_HGA is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_I810 is not set
# CONFIG_FB_LE80578 is not set
# CONFIG_FB_INTEL is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON is not set
CONFIG_FB_ATY128=m
# CONFIG_FB_ATY128_BACKLIGHT is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_S3 is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_VT8623 is not set
# CONFIG_FB_CYBLA is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_ARK is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_GEODE is not set
# CONFIG_FB_VIRTUAL is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_VGACON_SOFT_SCROLLBACK is not set
CONFIG_VIDEO_SELECT=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
CONFIG_LOGO=y
# CONFIG_LOGO_LINUX_MONO is not set
# CONFIG_LOGO_LINUX_VGA16 is not set
CONFIG_LOGO_LINUX_CLUT224=y

#
# Sound
#
CONFIG_SOUND=m

#
# Advanced Linux Sound Architecture
#
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_SEQUENCER=m
# CONFIG_SND_SEQ_DUMMY is not set
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_PCM_OSS_PLUGINS=y
CONFIG_SND_SEQUENCER_OSS=y
# CONFIG_SND_DYNAMIC_MINORS is not set
# CONFIG_SND_SUPPORT_OLD_API is not set
# CONFIG_SND_VERBOSE_PROCFS is not set
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set

#
# Generic devices
#
CONFIG_SND_MPU401_UART=m
CONFIG_SND_AC97_CODEC=m
# CONFIG_SND_DUMMY is not set
# CONFIG_SND_VIRMIDI is not set
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_MTS64 is not set
# CONFIG_SND_SERIAL_U16550 is not set
CONFIG_SND_MPU401=m
# CONFIG_SND_PORTMAN2X4 is not set

#
# PCI devices
#
# CONFIG_SND_AD1889 is not set
# CONFIG_SND_ALS300 is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_BT87X is not set
# CONFIG_SND_CA0106 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_CS5535AUDIO is not set
# CONFIG_SND_DARLA20 is not set
# CONFIG_SND_GINA20 is not set
# CONFIG_SND_LAYLA20 is not set
# CONFIG_SND_DARLA24 is not set
# CONFIG_SND_GINA24 is not set
# CONFIG_SND_LAYLA24 is not set
# CONFIG_SND_MONA is not set
# CONFIG_SND_MIA is not set
# CONFIG_SND_ECHO3G is not set
# CONFIG_SND_INDIGO is not set
# CONFIG_SND_INDIGOIO is not set
# CONFIG_SND_INDIGODJ is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_EMU10K1X is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_FM801 is not set
# CONFIG_SND_HDA_INTEL is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_HDSPM is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
CONFIG_SND_INTEL8X0=m
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_PCXHR is not set
# CONFIG_SND_RIPTIDE is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VIA82XX_MODEM is not set
# CONFIG_SND_VX222 is not set
# CONFIG_SND_YMFPCI is not set
# CONFIG_SND_AC97_POWER_SAVE is not set

#
# USB devices
#
# CONFIG_SND_USB_AUDIO is not set
# CONFIG_SND_USB_USX2Y is not set
# CONFIG_SND_USB_CAIAQ is not set

#
# System on Chip audio support
#
# CONFIG_SND_SOC is not set

#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set
CONFIG_AC97_BUS=m

#
# HID Devices
#
# CONFIG_HID is not set

#
# USB Input Devices
#
# CONFIG_USB_HID is not set

#
# USB HID Boot Protocol drivers
#
# CONFIG_USB_KBD is not set
# CONFIG_USB_MOUSE is not set

#
# USB support
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=m
# CONFIG_USB_DEBUG is not set

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_DEVICE_CLASS is not set
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_SUSPEND is not set
# CONFIG_USB_OTG is not set

#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=m
# CONFIG_USB_EHCI_SPLIT_ISO is not set
# CONFIG_USB_EHCI_ROOT_HUB_TT is not set
# CONFIG_USB_EHCI_TT_NEWSCHED is not set
# CONFIG_USB_EHCI_BIG_ENDIAN_MMIO is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_OHCI_HCD is not set
CONFIG_USB_UHCI_HCD=m
# CONFIG_USB_SL811_HCD is not set

#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set

#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
#

#
# may also be needed; see USB_STORAGE Help for more information
#
# CONFIG_USB_LIBUSUAL is not set

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MON is not set

#
# USB port drivers
#
# CONFIG_USB_USS720 is not set

#
# USB Serial Converter support
#
# CONFIG_USB_SERIAL is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_BERRY_CHARGE is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_PHIDGET is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
# CONFIG_USB_TEST is not set

#
# USB DSL modem support
#

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set
# CONFIG_MMC is not set

#
# LED devices
#
# CONFIG_NEW_LEDS is not set

#
# LED drivers
#

#
# LED Triggers
#

#
# InfiniBand support
#
# CONFIG_INFINIBAND is not set

#
# EDAC - error detection and reporting (RAS) (EXPERIMENTAL)
#
# CONFIG_EDAC is not set

#
# Real Time Clock
#
# CONFIG_RTC_CLASS is not set

#
# DMA Engine support
#
CONFIG_DMA_ENGINE=y

#
# DMA Clients
#
CONFIG_NET_DMA=y

#
# DMA Devices
#
CONFIG_INTEL_IOATDMA=m

#
# Auxiliary Display support
#
# CONFIG_KS0108 is not set

#
# Virtualization
#
# CONFIG_KVM is not set

#
# File systems
#
CONFIG_EXT2_FS=m
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
# CONFIG_EXT3_FS_POSIX_ACL is not set
# CONFIG_EXT3_FS_SECURITY is not set
# CONFIG_EXT4DEV_FS is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_FS_POSIX_ACL is not set
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
# CONFIG_CONFIGFS_FS is not set

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
# CONFIG_NFS_FS is not set
# CONFIG_NFSD is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
# CONFIG_9P_FS is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
# CONFIG_EFI_PARTITION is not set
# CONFIG_SYSV68_PARTITION is not set

#
# Native Language Support
#
CONFIG_NLS=m
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=m
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=m
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
CONFIG_NLS_CODEPAGE_1250=m
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=m
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=m
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=m

#
# Distributed Lock Manager
#
# CONFIG_DLM is not set

#
# Instrumentation Support
#
# CONFIG_PROFILING is not set
# CONFIG_KPROBES is not set

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
# CONFIG_PRINTK_TIME is not set
# CONFIG_ENABLE_MUST_CHECK is not set
# CONFIG_MAGIC_SYSRQ is not set
# CONFIG_UNUSED_SYMBOLS is not set
# CONFIG_DEBUG_FS is not set
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_KERNEL is not set
# CONFIG_DEBUG_BUGVERBOSE is not set
CONFIG_EARLY_PRINTK=y
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
CONFIG_DOUBLEFAULT=y

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set

#
# Cryptographic options
#
CONFIG_CRYPTO=y
CONFIG_CRYPTO_ALGAPI=m
CONFIG_CRYPTO_BLKCIPHER=m
CONFIG_CRYPTO_HASH=m
CONFIG_CRYPTO_MANAGER=m
CONFIG_CRYPTO_HMAC=m
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=m
CONFIG_CRYPTO_SHA1=m
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_WP512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_GF128MUL is not set
# CONFIG_CRYPTO_ECB is not set
CONFIG_CRYPTO_CBC=m
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_CRYPTD is not set
CONFIG_CRYPTO_DES=m
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_TWOFISH_586 is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_AES is not set
# CONFIG_CRYPTO_AES_586 is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_ANUBIS is not set
CONFIG_CRYPTO_DEFLATE=m
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_TEST is not set

#
# Hardware crypto devices
#
# CONFIG_CRYPTO_DEV_PADLOCK is not set
# CONFIG_CRYPTO_DEV_GEODE is not set

#
# Library routines
#
CONFIG_BITREVERSE=y
# CONFIG_CRC_CCITT is not set
# CONFIG_CRC16 is not set
# CONFIG_CRC_ITU_T is not set
CONFIG_CRC32=y
# CONFIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=m
CONFIG_ZLIB_DEFLATE=m
CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_KTIME_SCALAR=y

Cheers

Uwe

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

[Michael Buesch]

On Saturday 26 May 2007 19:24:33 Uwe Bugla wrote:
> Am Samstag, 26. Mai 2007 19:18 schrieben Sie:
> > On Saturday 26 May 2007 19:04:04 Uwe Bugla wrote:
> > > Yes, sure! But the help text is very unlucky and humble, and it is not
> > > clear enough in the sense of being distinctive enough, just clear and
> > > comprehensive.
> >
> > Why don't you simply submit a patch to change the helptext then?
> > I'm not sure why you refuse to DO anything about the "mess", but
> > instead keep poking me that I am responsible somehow to fix it up
> > for you...
> 
> I need exception examples for doing so. What are the exception examples?
> 
> Apart from that you have don nothing except than guessing around.

Admit it. You don't know how debugging is done in the real world.
Debugging _IS_ guessing around.

> Now here comes the LAST proof that your code is buggy:
> 
> A. It's not mm-implementation
> B. It's not user behaviour or fault
> C. It's not an ACPI issue
> 
> BUT ONE AND ONLY:
> 
> D. It's your code that is buggy, without any doubt!

Blahblah. Did you even read the mail I CCed to you?
It "proves" (to use your wording) the exact opposite.

> OK, went Andrew's path: patched 2.6.22-rc3 with wireless tree:
> 
> Result: The NIC driver b44 and ssb are loaded correctly, but refuse to work
> (no network communication possible).

Ok, please take git and get my development tree and try with that:

git clone http://bu3sch.de/git/wireless-dev.git

It's based on 2.6.22-rc1 and it works fine for me.

> dmesg:
> 
...

Ok, config and dmesg looks OK to me, now.


-- 
Greetings Michael.

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

[Andrew Morton]

On Sat, 26 May 2007 20:03:17 +0200 Michael Buesch <mb@bu3sch.de> wrote:

> Ok, please take git and get my development tree and try with that:
> 
> git clone http://bu3sch.de/git/wireless-dev.git
> 
> It's based on 2.6.22-rc1 and it works fine for me.

Uwe has a slow connection, and getting the whole git thing
set up would be quite a lump of effort.

I prepared a diff of the above tree against 2.6.21-rc3.  It is at
http://userweb.kernel.org/~akpm/git-mb.patch.gz

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

[Uwe Bugla]

Am Samstag, 26. Mai 2007 20:19 schrieben Sie:
> On Sat, 26 May 2007 20:03:17 +0200 Michael Buesch <mb@bu3sch.de> wrote:
> > Ok, please take git and get my development tree and try with that:
> >
> > git clone http://bu3sch.de/git/wireless-dev.git
> >
> > It's based on 2.6.22-rc1 and it works fine for me.
>
> Uwe has a slow connection, and getting the whole git thing
> set up would be quite a lump of effort.
>
> I prepared a diff of the above tree against 2.6.21-rc3.  It is at
> http://userweb.kernel.org/~akpm/git-mb.patch.gz

OK, applied this one against 2.6.22-rc3, assuming a typo error by you, Andrew.

Result is: No change: non functionable b44 device!

Thank you for your help!

Uwe

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

[Larry Finger]

Uwe Bugla wrote:
> 
> OK, applied this one against 2.6.22-rc3, assuming a typo error by you, Andrew.
> 
> Result is: No change: non functionable b44 device!

Could you please send the following:

1. the output of lsmod from the non-functioning kernel

2. the output of dmesg from the non-functioning kernel

3. your .config used to create your non-functioning kernel.

Thanks,

Larry

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

[Francois Romieu]

Larry Finger <larry.finger@lwfinger.net> :
[...]
> 2. the output of dmesg from the non-functioning kernel
> 
> 3. your .config used to create your non-functioning kernel.

They are already in the thread.

-- 
Ueimor

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

[Uwe Bugla]

Am Samstag, 26. Mai 2007 21:57 schrieben Sie:
> Uwe Bugla wrote:
> > OK, applied this one against 2.6.22-rc3, assuming a typo error by you,
> > Andrew.
> >
> > Result is: No change: non functionable b44 device!
>
> Could you please send the following:
>
> 1. the output of lsmod from the non-functioning kernel

Nonsense!
As I stated already, both modules (i. e. b44 and ssb) are loaded correctly.
So please read the thread before you post that, not vice versa!

>
> 2. the output of dmesg from the non-functioning kernel
>
> 3. your .config used to create your non-functioning kernel.
>
They are already in the thread. So please leave me alone with those lazy 
hints! Read bfore you post, not vice versa!

> Thanks,
>
> Larry

Cheers

Uwe

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

[Michael Buesch]

On Saturday 26 May 2007 22:33:13 Uwe Bugla wrote:
> Am Samstag, 26. Mai 2007 21:57 schrieben Sie:
> > Uwe Bugla wrote:
> > > OK, applied this one against 2.6.22-rc3, assuming a typo error by you,
> > > Andrew.
> > >
> > > Result is: No change: non functionable b44 device!
> >
> > Could you please send the following:
> >
> > 1. the output of lsmod from the non-functioning kernel
> 
> Nonsense!
> As I stated already, both modules (i. e. b44 and ssb) are loaded correctly.
> So please read the thread before you post that, not vice versa!

Ok, Uwe. Now I show you some real life examples how you and how
someone who is polite answers to the same question:

You:
> Nonsense!
> As I stated already, both modules (i. e. b44 and ssb) are loaded correctly.
> So please read the thread before you post that, not vice versa!

> They are already in the thread. So please leave me alone with those lazy
> hints! Read bfore you post, not vice versa!


Someone who is polite:
> They are already in the thread.


So you see the difference? And do you see why everybody in this
thread is so pissed about you?

-- 
Greetings Michael.

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

[Benoit Boissinot]

On 5/26/07, Michael Buesch <mb@bu3sch.de> wrote:
> On Saturday 26 May 2007 19:04:04 Uwe Bugla wrote:
> > Yes, sure! But the help text is very unlucky and humble, and it is not clear
> > enough in the sense of being distinctive enough, just clear and
> > comprehensive.
>
> Why don't you simply submit a patch to change the helptext then?

Is that ok ?

Discourage people from deselecting B44_PCI

Signed-off-by: Benoit Boissinot <benoit.boissinot@ens-lyon.org>

--- kernel.orig/drivers/net/Kconfig	2007-05-26 20:38:02.000000000 +0200
+++ kernel/drivers/net/Kconfig	2007-05-26 20:38:15.000000000 +0200
@@ -1449,7 +1449,7 @@
 	help
 	  Support for b44 PCI devices.

-	  Say Y
+	  Unless you know what you are doing, say Y here.

 config FORCEDETH
 	tristate "nForce Ethernet support"

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

[Michael Buesch]

On Saturday 26 May 2007 20:41:09 Benoit Boissinot wrote:
> On 5/26/07, Michael Buesch <mb@bu3sch.de> wrote:
> > On Saturday 26 May 2007 19:04:04 Uwe Bugla wrote:
> > > Yes, sure! But the help text is very unlucky and humble, and it is not clear
> > > enough in the sense of being distinctive enough, just clear and
> > > comprehensive.
> >
> > Why don't you simply submit a patch to change the helptext then?
> 
> Is that ok ?
> 
> Discourage people from deselecting B44_PCI

To me this is ok. But I think I have no voting right here.
Uwe has to decide which helptext he would understand. ;)

> Signed-off-by: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
> 
> --- kernel.orig/drivers/net/Kconfig	2007-05-26 20:38:02.000000000 +0200
> +++ kernel/drivers/net/Kconfig	2007-05-26 20:38:15.000000000 +0200
> @@ -1449,7 +1449,7 @@
>  	help
>  	  Support for b44 PCI devices.
> 
> -	  Say Y
> +	  Unless you know what you are doing, say Y here.
> 
>  config FORCEDETH
>  	tristate "nForce Ethernet support"
> 
> 



-- 
Greetings Michael.

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

[Uwe Bugla]

Am Samstag, 26. Mai 2007 20:41 schrieben Sie:
> On 5/26/07, Michael Buesch <mb@bu3sch.de> wrote:
> > On Saturday 26 May 2007 19:04:04 Uwe Bugla wrote:
> > > Yes, sure! But the help text is very unlucky and humble, and it is not
> > > clear enough in the sense of being distinctive enough, just clear and
> > > comprehensive.
> >
> > Why don't you simply submit a patch to change the helptext then?
>
> Is that ok ?
>
> Discourage people from deselecting B44_PCI
>
> Signed-off-by: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
>
> --- kernel.orig/drivers/net/Kconfig	2007-05-26 20:38:02.000000000 +0200
> +++ kernel/drivers/net/Kconfig	2007-05-26 20:38:15.000000000 +0200
> @@ -1449,7 +1449,7 @@
>  	help
>  	  Support for b44 PCI devices.
>
> -	  Say Y
> +	  Unless you know what you are doing, say Y here.
>
>  config FORCEDETH
>  	tristate "nForce Ethernet support"

No, That is NOT OK! That's nothing but a joke, and if it is a joke : )
it hits well in Mister Buesches direction. In so far it's 
well-done : ) : ) : )

To be honest:

I expect at least TWO explained cases:

A. The case in which the b44 module is a PCI module (onboard, additional PCI 
card etc.).

B. At least one well described case in which the b44 module is a bus 
independent one.

Apart from that, it is Michael's task to explain the what and why, not mine 
and not yours! It is him that wants his stuff being pulled into mainline, and 
in so far he very well can do the "dirty work" of documentation, explanation.

But the issue is: He is not ready to DO that! Only if it fires back!

Cheers

Uwe

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

[Michael Buesch]

On Saturday 26 May 2007 20:58:37 Uwe Bugla wrote:
> Am Samstag, 26. Mai 2007 20:41 schrieben Sie:
> > On 5/26/07, Michael Buesch <mb@bu3sch.de> wrote:
> > > On Saturday 26 May 2007 19:04:04 Uwe Bugla wrote:
> > > > Yes, sure! But the help text is very unlucky and humble, and it is not
> > > > clear enough in the sense of being distinctive enough, just clear and
> > > > comprehensive.
> > >
> > > Why don't you simply submit a patch to change the helptext then?
> >
> > Is that ok ?
> >
> > Discourage people from deselecting B44_PCI
> >
> > Signed-off-by: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
> >
> > --- kernel.orig/drivers/net/Kconfig	2007-05-26 20:38:02.000000000 +0200
> > +++ kernel/drivers/net/Kconfig	2007-05-26 20:38:15.000000000 +0200
> > @@ -1449,7 +1449,7 @@
> >  	help
> >  	  Support for b44 PCI devices.
> >
> > -	  Say Y
> > +	  Unless you know what you are doing, say Y here.
> >
> >  config FORCEDETH
> >  	tristate "nForce Ethernet support"
> 
> No, That is NOT OK! That's nothing but a joke, and if it is a joke : )
> it hits well in Mister Buesches direction. In so far it's 
> well-done : ) : ) : )

See what I meant, Benoit?

> To be honest:
> 
> I expect at least TWO explained cases:
> 
> A. The case in which the b44 module is a PCI module (onboard, additional PCI 
> card etc.).
> 
> B. At least one well described case in which the b44 module is a bus 
> independent one.

You still didn't get it, right?
b44-ssb is a SSB device driver. No PCI, nothing. To get this working
on PCI you need to enable the PCI glue. Which is enabled by default.
It even includes the comment "Say Y". If you say N nevertheless it's
your fault.
What's so hard to understand about this? We have LOTS of drivers in the
kernel that work _exactly_ the same way. There is a base module to drive
the hardware and several glue drivers. If you de-select the glue driver
it doesn't work.
If you use your old config and do not DISABLE some option you will
not experience a regression (at least regarding to the kconfig stuff.
There's still your transmission bug left).

> Apart from that, it is Michael's task to explain the what and why, not mine 
> and not yours! It is him that wants his stuff being pulled into mainline, and 

My task is _nothing_. This is opensource. If you don't like
something about it, go and fix it. But don't say it's the _task_ of others
to fix things you don't like. I am not payed to do this for you.
Though, I'd like to resolve it.

> in so far he very well can do the "dirty work" of documentation, explanation.

I explained it several times now. I'm not sure what else I should
say about it.

-- 
Greetings Michael.

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

[Michael Buesch]

Uwe, please try the following patch:

Index: bu3sch-wireless-dev/drivers/net/b44.c
===================================================================
--- bu3sch-wireless-dev.orig/drivers/net/b44.c	2007-05-18 18:09:50.000000000 +0200
+++ bu3sch-wireless-dev/drivers/net/b44.c	2007-05-26 21:18:28.000000000 +0200
@@ -2201,10 +2201,12 @@ static int __devinit b44_init_one(struct
 		printk("%2.2x%c", dev->dev_addr[i],
 		       i == 5 ? '\n' : ':');
 
+#if 0
 	/* Initialize phy */
 	spin_lock_irq(&bp->lock);
 	b44_chip_reset(bp);
 	spin_unlock_irq(&bp->lock);
+#endif
 
 	return 0;
 

-- 
Greetings Michael.

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

[Uwe Bugla]

Am Samstag, 26. Mai 2007 21:19 schrieben Sie:
> Uwe, please try the following patch:
>
> Index: bu3sch-wireless-dev/drivers/net/b44.c
> ===================================================================
> --- bu3sch-wireless-dev.orig/drivers/net/b44.c	2007-05-18
> 18:09:50.000000000 +0200 +++
> bu3sch-wireless-dev/drivers/net/b44.c	2007-05-26 21:18:28.000000000 +0200
> @@ -2201,10 +2201,12 @@ static int __devinit b44_init_one(struct
>  		printk("%2.2x%c", dev->dev_addr[i],
>  		       i == 5 ? '\n' : ':');
>
> +#if 0
>  	/* Initialize phy */
>  	spin_lock_irq(&bp->lock);
>  	b44_chip_reset(bp);
>  	spin_unlock_irq(&bp->lock);
> +#endif
>
>  	return 0;

Against what kernel please?
Just try to be a bit more eloquent, man!

Uwe

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

[Michael Buesch]

On Saturday 26 May 2007 21:39:54 Uwe Bugla wrote:
> Am Samstag, 26. Mai 2007 21:19 schrieben Sie:
> > Uwe, please try the following patch:
> >
> > Index: bu3sch-wireless-dev/drivers/net/b44.c
> > ===================================================================
> > --- bu3sch-wireless-dev.orig/drivers/net/b44.c	2007-05-18
> > 18:09:50.000000000 +0200 +++
> > bu3sch-wireless-dev/drivers/net/b44.c	2007-05-26 21:18:28.000000000 +0200
> > @@ -2201,10 +2201,12 @@ static int __devinit b44_init_one(struct
> >  		printk("%2.2x%c", dev->dev_addr[i],
> >  		       i == 5 ? '\n' : ':');
> >
> > +#if 0
> >  	/* Initialize phy */
> >  	spin_lock_irq(&bp->lock);
> >  	b44_chip_reset(bp);
> >  	spin_unlock_irq(&bp->lock);
> > +#endif
> >
> >  	return 0;
> 
> Against what kernel please?
> Just try to be a bit more eloquent, man!

Against a kernel which does not work for you, of course.

Sometimes I wonder... (no better not say that).

-- 
Greetings Michael.

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

[Uwe Bugla]

Am Samstag, 26. Mai 2007 21:49 schrieben Sie:
> On Saturday 26 May 2007 21:39:54 Uwe Bugla wrote:
> > Am Samstag, 26. Mai 2007 21:19 schrieben Sie:
> > > Uwe, please try the following patch:
> > >
> > > Index: bu3sch-wireless-dev/drivers/net/b44.c
> > > ===================================================================
> > > --- bu3sch-wireless-dev.orig/drivers/net/b44.c	2007-05-18
> > > 18:09:50.000000000 +0200 +++
> > > bu3sch-wireless-dev/drivers/net/b44.c	2007-05-26 21:18:28.000000000
> > > +0200 @@ -2201,10 +2201,12 @@ static int __devinit b44_init_one(struct
> > > printk("%2.2x%c", dev->dev_addr[i],
> > >  		       i == 5 ? '\n' : ':');
> > >
> > > +#if 0
> > >  	/* Initialize phy */
> > >  	spin_lock_irq(&bp->lock);
> > >  	b44_chip_reset(bp);
> > >  	spin_unlock_irq(&bp->lock);
> > > +#endif
> > >
> > >  	return 0;
> >
> > Against what kernel please?
> > Just try to be a bit more eloquent, man!
>
> Against a kernel which does not work for you, of course.
>
> Sometimes I wonder... (no better not say that).

YES! And I wonder TOO, definitely!

Quand meme (now, if you do not speak french: Above all that), I applied your 
patch against 2.6.22-rc2-mm1. Just to show my cooperation willing to get 
your "dream" being fulfilled!

Result is: No change!
Non-functionable b44-device at all!

Hint: Although being a "non-hacker" or "non-developer" I do have stepped 
across some experienced developer people who at least added some code to make 
their modules function in the following way:

modprobe xyz debug=1 (or debug=2 or debug=3 or debug=4 or debug=5 or debug=6)

In so far, if you continue to state that debugging is nothing but guessing 
around wildly you are definitely wrong, showing us all your missing code 
hacker experience. If you DO continue like this every step will be a torture 
not only for me but for the reading folks as well.

But every human being is here to learn and develop: In so far I am very 
optimistic!

Apart from the Kconfig chaos that seems to be subordinate in your personal 
rating scale, you at least could have added some functions like the above 
mentioned functions.

The fact that you simply ignored to imply those functions and continue to call 
other people dumb shows exactly how small and humble you are.

Apart from that:
The message that you rooted to my place was no "proof" at all for any kind of 
disfunctionality or compatibility issue!

In that message the lack of performance of the "enclosed" or "old" 
or "complete" b44 module (i. e. PCI-only module) was criticised, NOT the one 
ripped by you personally into two modules called b44 and ssb.

In so far I would deeply appreciate you personally to stick to the facts in 
your personal lack of knowledge about the b44 driver instead of playing bad 
politics against other people like me and others.


Hello my dear Andrew Morton,

Could you please do me and the rest of the world two favours?

A. Rip Michael Buesches code out of the mm-tree

B. Give Michael Buesch a fair chance to revise his disfunctionable code 
outside the mm-tree and / or the vanilla mainline.

Side note for the what and why:

I like to help avoid dangers by testing the mm-tree.
BUT:

If real debugging conforms to nothing but guessing around wildly let me tell 
you that I do not appreciate to be part of that torture due to the lack of 
experience of some German spare time hacker.

A: proven by facts not knowing or even wanting to know how to imply 
appropriate functionable debug parametres in his driver code

B: non-cooperative as far as Kconfig help features are concerned (i. E. help 
to understand the issues for users

C: calling all people simply dumb who do not know about his personal issues at 
all

Thank you, Andrew Morton! You are real fine!

Sincerely

Uwe

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

[Dan Williams]

On Sat, 2007-05-26 at 23:32 +0200, Uwe Bugla wrote:
> Am Samstag, 26. Mai 2007 21:49 schrieben Sie:
> > On Saturday 26 May 2007 21:39:54 Uwe Bugla wrote:
> > > Am Samstag, 26. Mai 2007 21:19 schrieben Sie:
> > > > Uwe, please try the following patch:
> > > >
> > > > Index: bu3sch-wireless-dev/drivers/net/b44.c
> > > > ===================================================================
> > > > --- bu3sch-wireless-dev.orig/drivers/net/b44.c	2007-05-18
> > > > 18:09:50.000000000 +0200 +++
> > > > bu3sch-wireless-dev/drivers/net/b44.c	2007-05-26 21:18:28.000000000
> > > > +0200 @@ -2201,10 +2201,12 @@ static int __devinit b44_init_one(struct
> > > > printk("%2.2x%c", dev->dev_addr[i],
> > > >  		       i == 5 ? '\n' : ':');
> > > >
> > > > +#if 0
> > > >  	/* Initialize phy */
> > > >  	spin_lock_irq(&bp->lock);
> > > >  	b44_chip_reset(bp);
> > > >  	spin_unlock_irq(&bp->lock);
> > > > +#endif
> > > >
> > > >  	return 0;
> > >
> > > Against what kernel please?
> > > Just try to be a bit more eloquent, man!
> >
> > Against a kernel which does not work for you, of course.
> >
> > Sometimes I wonder... (no better not say that).
> 
> YES! And I wonder TOO, definitely!
> 
> Quand meme (now, if you do not speak french: Above all that), I applied your 
> patch against 2.6.22-rc2-mm1. Just to show my cooperation willing to get 
> your "dream" being fulfilled!
> 
> Result is: No change!
> Non-functionable b44-device at all!
> 
> Hint: Although being a "non-hacker" or "non-developer" I do have stepped 
> across some experienced developer people who at least added some code to make 
> their modules function in the following way:
> 
> modprobe xyz debug=1 (or debug=2 or debug=3 or debug=4 or debug=5 or debug=6)
> 
> In so far, if you continue to state that debugging is nothing but guessing 
> around wildly you are definitely wrong, showing us all your missing code 
> hacker experience. If you DO continue like this every step will be a torture 
> not only for me but for the reading folks as well.
> 
> But every human being is here to learn and develop: In so far I am very 
> optimistic!
> 
> Apart from the Kconfig chaos that seems to be subordinate in your personal 
> rating scale, you at least could have added some functions like the above 
> mentioned functions.
> 
> The fact that you simply ignored to imply those functions and continue to call 
> other people dumb shows exactly how small and humble you are.
> 
> Apart from that:
> The message that you rooted to my place was no "proof" at all for any kind of 
> disfunctionality or compatibility issue!
> 
> In that message the lack of performance of the "enclosed" or "old" 
> or "complete" b44 module (i. e. PCI-only module) was criticised, NOT the one 
> ripped by you personally into two modules called b44 and ssb.
> 
> In so far I would deeply appreciate you personally to stick to the facts in 
> your personal lack of knowledge about the b44 driver instead of playing bad 
> politics against other people like me and others.
> 
> 
> Hello my dear Andrew Morton,
> 
> Could you please do me and the rest of the world two favours?
> 
> A. Rip Michael Buesches code out of the mm-tree
> 
> B. Give Michael Buesch a fair chance to revise his disfunctionable code 
> outside the mm-tree and / or the vanilla mainline.
> 
> Side note for the what and why:
> 
> I like to help avoid dangers by testing the mm-tree.
> BUT:
> 
> If real debugging conforms to nothing but guessing around wildly let me tell 
> you that I do not appreciate to be part of that torture due to the lack of 
> experience of some German spare time hacker.
> 
> A: proven by facts not knowing or even wanting to know how to imply 
> appropriate functionable debug parametres in his driver code
> 
> B: non-cooperative as far as Kconfig help features are concerned (i. E. help 
> to understand the issues for users
> 
> C: calling all people simply dumb who do not know about his personal issues at 
> all
> 
> Thank you, Andrew Morton! You are real fine!

Everyone just needs to cool down.  And you both (Uwe and Michael) just
need to try debugging the problem.

Abstracting the SSB code into a library is clearly the correct solution,
rather than having the same code in two separate places.  The whole
_point_ of having code in various trees (wireless, mm, etc) is to find
these bugs before the patches hit mainline.  Even testing on > 3
machines may not uncover subtle bugs (for example, different behavior on
different silicon revisions, especially in reverse-engineered parts),
it's only something Michael can test so far before other people have to
pick it up and test it.  And that's where you come in, Uwe.

So both of you should actually just stop the name-calling, suck it up,
and debug the problem.  We're getting nothing done here.

Dan

> Sincerely
> 
> Uwe
> -
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Uwe Bugla]

Am Samstag, 26. Mai 2007 23:52 schrieben Sie:
> On Sat, 2007-05-26 at 23:32 +0200, Uwe Bugla wrote:
> > Am Samstag, 26. Mai 2007 21:49 schrieben Sie:
> > > On Saturday 26 May 2007 21:39:54 Uwe Bugla wrote:
> > > > Am Samstag, 26. Mai 2007 21:19 schrieben Sie:
> > > > > Uwe, please try the following patch:
> > > > >
> > > > > Index: bu3sch-wireless-dev/drivers/net/b44.c
> > > > > ===================================================================
> > > > > --- bu3sch-wireless-dev.orig/drivers/net/b44.c	2007-05-18
> > > > > 18:09:50.000000000 +0200 +++
> > > > > bu3sch-wireless-dev/drivers/net/b44.c	2007-05-26 21:18:28.000000000
> > > > > +0200 @@ -2201,10 +2201,12 @@ static int __devinit
> > > > > b44_init_one(struct printk("%2.2x%c", dev->dev_addr[i],
> > > > >  		       i == 5 ? '\n' : ':');
> > > > >
> > > > > +#if 0
> > > > >  	/* Initialize phy */
> > > > >  	spin_lock_irq(&bp->lock);
> > > > >  	b44_chip_reset(bp);
> > > > >  	spin_unlock_irq(&bp->lock);
> > > > > +#endif
> > > > >
> > > > >  	return 0;
> > > >
> > > > Against what kernel please?
> > > > Just try to be a bit more eloquent, man!
> > >
> > > Against a kernel which does not work for you, of course.
> > >
> > > Sometimes I wonder... (no better not say that).
> >
> > YES! And I wonder TOO, definitely!
> >
> > Quand meme (now, if you do not speak french: Above all that), I applied
> > your patch against 2.6.22-rc2-mm1. Just to show my cooperation willing to
> > get your "dream" being fulfilled!
> >
> > Result is: No change!
> > Non-functionable b44-device at all!
> >
> > Hint: Although being a "non-hacker" or "non-developer" I do have stepped
> > across some experienced developer people who at least added some code to
> > make their modules function in the following way:
> >
> > modprobe xyz debug=1 (or debug=2 or debug=3 or debug=4 or debug=5 or
> > debug=6)
> >
> > In so far, if you continue to state that debugging is nothing but
> > guessing around wildly you are definitely wrong, showing us all your
> > missing code hacker experience. If you DO continue like this every step
> > will be a torture not only for me but for the reading folks as well.
> >
> > But every human being is here to learn and develop: In so far I am very
> > optimistic!
> >
> > Apart from the Kconfig chaos that seems to be subordinate in your
> > personal rating scale, you at least could have added some functions like
> > the above mentioned functions.
> >
> > The fact that you simply ignored to imply those functions and continue to
> > call other people dumb shows exactly how small and humble you are.
> >
> > Apart from that:
> > The message that you rooted to my place was no "proof" at all for any
> > kind of disfunctionality or compatibility issue!
> >
> > In that message the lack of performance of the "enclosed" or "old"
> > or "complete" b44 module (i. e. PCI-only module) was criticised, NOT the
> > one ripped by you personally into two modules called b44 and ssb.
> >
> > In so far I would deeply appreciate you personally to stick to the facts
> > in your personal lack of knowledge about the b44 driver instead of
> > playing bad politics against other people like me and others.
> >
> >
> > Hello my dear Andrew Morton,
> >
> > Could you please do me and the rest of the world two favours?
> >
> > A. Rip Michael Buesches code out of the mm-tree
> >
> > B. Give Michael Buesch a fair chance to revise his disfunctionable code
> > outside the mm-tree and / or the vanilla mainline.
> >
> > Side note for the what and why:
> >
> > I like to help avoid dangers by testing the mm-tree.
> > BUT:
> >
> > If real debugging conforms to nothing but guessing around wildly let me
> > tell you that I do not appreciate to be part of that torture due to the
> > lack of experience of some German spare time hacker.
> >
> > A: proven by facts not knowing or even wanting to know how to imply
> > appropriate functionable debug parametres in his driver code
> >
> > B: non-cooperative as far as Kconfig help features are concerned (i. E.
> > help to understand the issues for users
> >
> > C: calling all people simply dumb who do not know about his personal
> > issues at all
> >
> > Thank you, Andrew Morton! You are real fine!
>
> Everyone just needs to cool down.  And you both (Uwe and Michael) just
> need to try debugging the problem.
>
> Abstracting the SSB code into a library is clearly the correct solution,
> rather than having the same code in two separate places.  The whole
> _point_ of having code in various trees (wireless, mm, etc) is to find
> these bugs before the patches hit mainline.  Even testing on > 3
> machines may not uncover subtle bugs (for example, different behavior on
> different silicon revisions, especially in reverse-engineered parts),
> it's only something Michael can test so far before other people have to
> pick it up and test it.  And that's where you come in, Uwe.
>
> So both of you should actually just stop the name-calling, suck it up,
> and debug the problem.  We're getting nothing done here.
>
> Dan

Yeah, Danny!
But if someone's simply ignoring to apply debug functions into his module code 
and thus reducing the essence of debugging to wild guessing around, 
transforming the whole testing situation into a torture / and  / or disaster 
then I am inclined to call exactly this someone to be nothing but a looser, 
not only on the human layer, but also on the technical layer.

And that's exactly the reason why I want his stuff to be ripped out of 
mm-tree.

Sincerely

Uwe

P. S.: Never DO show a humble and unexperienced Linux hacker that his 
experience is utmost limited! But if you do you earn nothing but the output 
of utmost primitive "Godzilla" drives (i. e. being flamed for example).

I. E.:
A. Not all linux developers are proven to be asocial ape-instinct-limited 
people (I do know a very long exception list and that's why I take part in 
that), but some of them are, proven by facts!

B. The "Godzillas" are not limited to people living in Germany, but instead 
they are in fact everywhere, as the capitalist bullshit system produces them 
like gnomes on an assembly line!

>
> > Sincerely
> >
> > Uwe
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> > in the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Michael Buesch]

On Saturday 26 May 2007 23:32:50 Uwe Bugla wrote:

> Hint: Although being a "non-hacker" or "non-developer" I do have stepped 
...
> In so far, if you continue to state that debugging is nothing but guessing 
> around wildly you are definitely wrong, showing us all your missing code 
> hacker experience. If you DO continue like this every step will be a torture 
> not only for me but for the reading folks as well.

You REALLY want to tell me, a developer and maintainer of several
big projects, how debugging is done, being a non-developer and non-hacker?
I can't believe what I am reading here.

> The fact that you simply ignored to imply those functions and continue to call 
> other people dumb shows exactly how small and humble you are.

Please quote me where I called someone dumb.
Ah, yes. I am inhuman and whatever. We know that already.

> Apart from that:
> The message that you rooted to my place was no "proof" at all for any kind of 
> disfunctionality or compatibility issue!
> 
> In that message the lack of performance of the "enclosed" or "old" 
> or "complete" b44 module (i. e. PCI-only module) was criticised, NOT the one 
> ripped by you personally into two modules called b44 and ssb.

Ah, no? I think you didn't completely understand the mail.
Steve reported a bug in b44 2.6.22. Please note that 2.6.22 does NOT include
ssb. But I'm sure you'll find a way to make me responsible for
this bug, anyway.
b44 is buggy and this is NOT caused by ssb. Re-read steve's mail.

> In so far I would deeply appreciate you personally to stick to the facts in 
> your personal lack of knowledge about the b44 driver instead of playing bad 
> politics against other people like me and others.

Oh, poor poor guy.
I lack knowledge about b44? Oh, I suppose that was a typo and you
meant yourself.

> Hello my dear Andrew Morton,
> 
> Could you please do me and the rest of the world two favours?
> 
> A. Rip Michael Buesches code out of the mm-tree
> 
> B. Give Michael Buesch a fair chance to revise his disfunctionable code 
> outside the mm-tree and / or the vanilla mainline.

Andrew, I see that you are in a bad situation now.
I respect every decision you make. But please still
consider that b44 works perfectly well for me. I tested it
today on _all_ kernels that did not work for Uwe in this thread.
On my device (BCM4401-B0) it works on all of these kernels.

I'd suggest we leave the code in the -mm tree and wait for
someone else to show up with a bugreport.
It's simply impossible to debug this problem with the help of Uwe.

> C: calling all people simply dumb who do not know about his personal issues at 
> all

Please quote this, Uwe.

> Thank you, Andrew Morton! You are real fine!
> 
> Sincerely
> 
> Uwe
> 
> 

Uwe, I just added you to my killfile.
Don't bother sending mail to me any longer. It will not arrive.
I'm not interested in your stupid "bugreports" anymore, as they are
useless and consist only of personal insults and
personal miscreditations.
Welcome to the killfile of yet another kernel developer.

-- 
Greetings Michael.

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

[Michael Buesch]

On Saturday 26 May 2007 18:13:09 Andrew Morton wrote:
> > I ask to try wireless-dev, as the driver works perfectly fine
> > for me there, but he refuses to try it, too. So I'm stuck.
> 
> I don't think he knows how to obtain it.
> 
> Uwe, http://userweb.kernel.org/~akpm/git-wireless.patch.gz is the current
> wireless tree.  That's a patch against 2.6.22-rc3.  Could you please test
> that?  If that works then we know that the bug probably lies outside the
> b44 driver (or it was subsequently fixed).

I just tried this patch on my BCM4401-B0 and it works there, too.

-- 
Greetings Michael.

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

[Michael Buesch]

On Saturday 26 May 2007 18:13:09 Andrew Morton wrote:
> > I already tried your -mm kernel, but it crashes on my machine
> > for other reasons. (Yeah, I should look into them, too :P )
> 
> err, please do.  Just the oops trace would be a start.

Sorry, I can't reproduce the crash anymore. :(

But now I could test that this kernel _also_ works perfectly
well on my BCM4401-B0.

-- 
Greetings Michael.

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

[Uwe Bugla]

Am Samstag, 26. Mai 2007 17:50 schrieben Sie:
> Andrew,
>
> I am going to ignore Uwe from now on. It's simply impossible
> to debug the problem the way he is responding.
> Well, I'm not the first person in the Linux community adding
> him to the killfile, ... .
> I ask to try wireless-dev, as the driver works perfectly fine
> for me there, but he refuses to try it, too. So I'm stuck.

A. Where can I get wireless-dev, please?
B. Against what kernel can I apply it?
C. How must this stuff be applied?

Three clear questions, three clear answers please, if we want get forward.

Apart from that I do not owe a wireless device, and i more and more get the 
impression that you simply do not want to rework your code.
You rather search hungrily for excuses to point to some voluntary other side 
as soon as your code does not seem to work as expected and as soon as 
responsibilty issues are concerned.

So what tester would enjoy such a stubborn behaviour?
And additionally: Without getting paid for all the time effort?

> I already tried your -mm kernel, but it crashes on my machine
> for other reasons. (Yeah, I should look into them, too :P )
>
> Andrew, is it possible that the breakage was introduced in the
> merge process somehow? Didn't the patch apply cleanly? Are there
> other changes to b44 I should know about in your tree?

I think you can easily compare your wireless-dev code (where can I download 
it?) with the patch in the mm-tree. A simple diff will do I suppose.

>
> If it is really impossible to debug this problem, I'd like to
> suggest you to drop the b44-ssb port completely.
> I'm not going to destroy my nerves any further with guys like
> Uwe, so I'll include the b44-ssb port in the OpenWRT tree
> and be done with it.

As I stated already, debugging is not impossible!
In fact your responses didn't even mention real debugging as a choice.
To debug the issue I need the debug command line parametres for both ssb and 
b44. I cannot guess them, as there is no documentation available, neither for 
b44 nor for ssb. So what are the debug parametres please?

> Although I would be very sad about it, as my longterm goal was
> to make a vanilla kernel run on the OpenWRT devices... .

It is not my primary goal to leave you alone with this......

>
> But maybe we can get another tester for -mm with similiar problems,
> who is not bullshitting the whole time and is also going to
> test wireless-dev to make sure it's not a merge bug.

No, we need simply friendlier code developers without that immense arrogance 
behaviour that you show. That's it.

>
>
> -----------
>
> And Uwe: Remember, I am not payed for this. I do _all_ this
> in my free time.
> So sentences like: "So, the ball has been in your court
> for two days now, and you simply keep on hesitating
> to take action now."
> are _completely_ displaced in this discussion.

Yes. And I am doing this in my spare time too. And what I do not like is 
simply guessing around (ACPI bug, typo errors at DNS and nonsense like that 
etc.) plus this gesture going: "You are dumb, you are not understanding 
anything etc."

Cheers and happy reflection

Uwe

P. S.: My door is open, although the whole issue starts to nerve me due to 
your behaviour.

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

[David Miller]

From: Uwe Bugla <uwe.bugla@gmx.de>
Date: Sat, 26 May 2007 12:40:54 +0200

> Am Samstag, 26. Mai 2007 07:00 schrieben Sie:
> > Try it again, please.
> 
> NO!

Your not a nice person, and consistently so, therefore you can't post
to the mailing lists I run any more.

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

[Andrew Morton]

On Fri, 25 May 2007 16:52:19 +0200 Michael Buesch <mb@bu3sch.de> 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.

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

[Uwe Bugla]

Am Freitag, 25. Mai 2007 18:56 schrieben Sie:
> On Fri, 25 May 2007 16:52:19 +0200 Michael Buesch <mb@bu3sch.de> 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.

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

[Denis Vlasenko]

On Thursday 24 May 2007 21:56, Uwe Bugla wrote:
> 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 :)

Uwe, you are an arrogant idiot and I think it's best
for everybody to just ignore all your mails, regardless
of their technical merits.

Even if your mail reports a real bug, added shitload of insults
to developers far outweights any possible useful info.

Developers can save a lot of time and nerver by just waiting for
someone else to hit the same bug, if it exists, and then debug it
as usual.
--
vda