Bugs in kernels 2.6.20 plus 2.6.21 rc1 and 2
From: Uwe Bugla <hidden>
Date: 2007-03-09 14:09:16
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