Date:	Fri, 09 Mar 2007 15:09:08 +0100
From:	"Uwe Bugla" <uwe.bugla@....de>
To:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
Cc:	torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org, Alan <alan@...rguk.ukuu.org.uk>,
	linux-ide@...r.kernel.org
Subject: Bugs in kernels 2.6.20 plus 2.6.21 rc1 and 2

Hello Bart, hello everybody,

As requested I applied the following patch with parameter -R against 2.6.20:
http://kernel.org/pub/linux/kernel/people/bart/ide-2.6.20.patch

Result: incompilable kernel! Reason is the following hunk:

99,113d98
< diff --git a/drivers/ide/ide-probe.c b/drivers/ide/ide-probe.c
< index dad9c47..5a5c565 100644
< --- a/drivers/ide/ide-probe.c
< +++ b/drivers/ide/ide-probe.c
< @@ -1000,10 +1000,6 @@ static int ide_init_queue(ide_drive_t *drive)
<  	/* needs drive->queue to be set */
<  	ide_toggle_bounce(drive, 1);
<  
< -	/* enable led activity for disk drives only */
< -	if (drive->media == ide_disk && hwif->led_act)
< -		blk_queue_activity_fn(q, hwif->led_act, drive);
< -
<  	return 0;
<  }
<  

Would you please care for proper patch sets in future, just for efficiency reasons?

Side note: One diode of my TEAC CDRW54 (/dev/hdd) flickers every 2 seconds.
That's normal and it does not do any harm.


I ripped out this hunk and applied the resulting patch
collection with parameter -R against 2.6.20.
Results:
a. compilable kernel 
b. SUCCESS after endless hours of testing!


3 conclusions from that:

1. The buggy code responsible for the horrible reinitialization
and drive seek errors with my TEAC CDRW54 as /dev/hdd
is proven to reside in the patch collection mentioned above.
In so far kernel 2.6.20 urgently needs another reversion (sigh)!


2. The crap code responsible for the terrible system hangups I
reported (no mouse, no keyboard, no screen - even more horrible
than a Windoze virus) definitely resides in kernel 2.6.21 rc1 or 2.


It needs 3 things to find that out:
a. lots of time
b. patience
c. a machine running about 10 hours as it does not happen immediately.
Fact is: This hangup does not happen working with 2.6.20.


3. Linus should slow down the kernel release speed for the following
3 reasons:
a. The speed is discouraging possible testers because things are going too fast
b. The output of that publishing speed is nothing but half mature crap
b. 2.6.20 has proven to be a never ending story as far as regressions
are concerned! Why? Almost every week a new release candidate - insane!
7 weeks for fixing regressions - and still no end in sight!
Proposal: 2 weeks per release candidate, 2,5 to 3 months for an official kernel.



To help you which hunks need to be reversed in official 2.6.20 please see
the 6 outline attachments: 2 dmesg, 2 lspci-vvvxxx, 2 diffs.
As the revised 2.6.20 kernel works without trouble I did not compile
2.6.19. The 6 texts should be helpful though to get this issue fixed.
And I hope that this is the definte last regression of that horrible kernel.

Thanks everybody

Uwe

P. S.: Andrew, if you want me to test 2.6.21-rc2-mm1 I have 2 questions:

1. When should I do this if I see myself running after endless regressions
in official kernel releases? All you can is demand!

2. Why aren't my linuxtv contributions at least part of the mm-tree?
Cooperation shouldn't be a one way street, should it?
And please stop telling me stories about some Mr. Chehab or anybody else,
as my two contributions are fine and I don't feel responsible for
some mismatch gatekeepers @ linuxtv.org! Fact is: I do my best to
contribute whatever I can and they simply ignore it, which is imbearable!

-- 
"Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ...
Jetzt GMX ProMail testen: www.gmx.net/de/go/mailfooter/promail-out

View attachment "diffdmesg.txt" of type "text/plain" (2978 bytes)

View attachment "difflspci.txt" of type "text/plain" (462 bytes)

View attachment "dmesg2620.txt" of type "text/plain" (15277 bytes)

View attachment "dmesgreverted.txt" of type "text/plain" (15279 bytes)

View attachment "lspci2620.txt" of type "text/plain" (21770 bytes)

View attachment "lspcireverted.txt" of type "text/plain" (21771 bytes)

Powered by blists - more mailing lists