This message contains a list of some regressions from 2.6.25, for which there
are no fixes in the mainline I know of. If any of them have been fixed already,
please let me know.
If you know of any other unresolved regressions from 2.6.25, please let me know
either and I'll add them to the list. Also, please let me know if any of the
entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2008-07-06 166 38 26
2008-06-29 158 43 31
2008-06-22 148 39 28
2008-06-14 130 37 28
2008-06-07 125 48 33
2008-05-31 115 52 31
2008-05-24 94 47 28
2008-05-18 80 51 37
2008-05-11 53 46 34
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11041
Subject : All 2.6.26-rcX hang immediately after loading ohci_hcd
Submitter : Andrey Borzenkov <[email protected]>
Date : 2008-07-05 7:08 (2 days old)
References : http://marc.info/?l=linux-kernel&m=121524504505805&w=4
Handled-By : Linus Torvalds <[email protected]>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11040
Subject : 2.6.26-rc: host can not shutdown: ata problem
Submitter : Alexander Beregalov <[email protected]>
Date : 2008-07-03 21:43 (4 days old)
References : http://marc.info/?l=linux-kernel&m=121512197225068&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11039
Subject : 2.6.28-rc8-git3 forcedeth WARNING (kills the interface)
Submitter : Brad Campbell <[email protected]>
Date : 2008-07-03 10:07 (4 days old)
References : http://marc.info/?l=linux-netdev&m=121508714430752&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11035
Subject : System hangs on 2.6.26-rc8
Submitter : Roman Mindalev <[email protected]>
Date : 2008-07-02 14:25 (5 days old)
References : http://marc.info/?l=linux-kernel&m=121500871414995&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11025
Subject : [problem] raid performance loss with 2.6.26-rc8 on 32-bit x86 (bisected)
Submitter : Dan Williams <[email protected]>
Date : 2008-07-01 1:57 (6 days old)
References : http://marc.info/?l=linux-kernel&m=121487749429883&w=4
Handled-By : Mel Gorman <[email protected]>
Andy Whitcroft <[email protected]>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11023
Subject : 2.6.26-rc8-git2 - kernel BUG at mm/page_alloc.c:585
Submitter : Kamalesh Babulal <[email protected]>
Date : 2008-07-02 11:55 (5 days old)
References : http://lkml.org/lkml/2008/7/2/32
Handled-By : Andrew Morton <[email protected]>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11009
Subject : No console on Riva TNT since 2.6.26-0.rc4
Submitter : Quel Qun <[email protected]>
Date : 2008-06-26 20:04 (11 days old)
References : http://marc.info/?l=linux-kernel&m=121451344229718&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10989
Subject : kernel oopses when wiggling the mouse to make it known to hidd
Submitter : Daniel Vetter <[email protected]>
Date : 2008-06-26 10:32 (11 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10985
Subject : backlight doesn't come on after resume with i915 video
Submitter : Jon Dowland <[email protected]>
Date : 2008-06-26 02:09 (11 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10984
Subject : MMC print trace information when resume from suspend
Submitter : Jie Luo <[email protected]>
Date : 2008-06-26 01:15 (11 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10971
Subject : radeonfb : radeon X800 family support (atombios)
Submitter : [email protected]
Date : 2008-06-23 14:35 (14 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10960
Subject : 2.6.26-rc: SPARC: Sun Ultra 10 can not boot
Submitter : Alexander Beregalov <[email protected]>
Date : 2008-06-19 14:07 (18 days old)
References : http://marc.info/?l=linux-kernel&m=121388456519637&w=4
Handled-By : David Miller <[email protected]>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10955
Subject : v2.6.26-rc7: BUG task_struct: Poison overwritten
Submitter : Vegard Nossum <[email protected]>
Date : 2008-06-21 19:24 (16 days old)
References : http://marc.info/?l=linux-kernel&m=121407641925121&w=4
Handled-By : Peter Zijlstra <[email protected]>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10954
Subject : hda_intel: azx_get_response timeout, switching to polling mode: last cmd=0x011f000c
Submitter : Justin Mattock <[email protected]>
Date : 2008-06-21 2:05 (16 days old)
References : http://marc.info/?l=linux-kernel&m=121401399622190&w=4
http://marc.info/?t=121416231700010&r=1&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10919
Subject : [regression] display dimming is slow and laggy - Acer Travelmate 661lci
Submitter : Maximilian Engelhardt <[email protected]>
Date : 2008-06-14 22:31 (23 days old)
References : http://marc.info/?l=linux-kernel&m=121348428828320&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10906
Subject : repeatable slab corruption with LTP msgctl08
Submitter : Andrew Morton <[email protected]>
Date : 2008-06-12 5:13 (25 days old)
References : http://marc.info/?l=linux-kernel&m=121324775927704&w=4
Handled-By : Pekka J Enberg <[email protected]>
Christoph Lameter <[email protected]>
Manfred Spraul <[email protected]>
Andi Kleen <[email protected]>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10872
Subject : x86_64 boot hang when CONFIG_NUMA=n
Submitter : Randy Dunlap <[email protected]>
Date : 2008-06-05 21:50 (32 days old)
References : http://marc.info/?l=linux-kernel&m=121270308607116&w=4
http://lkml.org/lkml/2008/6/11/355
http://lkml.org/lkml/2008/6/15/117
Handled-By : Yinghai Lu <[email protected]>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10865
Subject : Oops trying to mount an ntfs partition on thinkpad
Submitter : Alex Romosan <[email protected]>
Date : 2008-06-05 14:47 (32 days old)
References : http://marc.info/?l=linux-kernel&m=121267834421414&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10862
Subject : forcedeth: lockdep warning on ethtool -s
Submitter : Tobias Diedrich <[email protected]>
Date : 2008-06-01 8:37 (36 days old)
References : http://marc.info/?l=linux-kernel&m=121230964032247&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10861
Subject : 2.6.26-rc4-git2 - long pause during boot
Submitter : Chris Clayton <[email protected]>
Date : 2008-06-01 4:15 (36 days old)
References : http://marc.info/?l=linux-kernel&m=121229382917834&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10843
Subject : Display artifacts on XOrg logout with PAT kernel and VESA framebuffer
Submitter : Frans Pop <[email protected]>
Date : 2008-05-31 14:04 (37 days old)
References : http://lkml.org/lkml/2008/6/7/206
http://lkml.org/lkml/2008/6/15/119
http://lkml.org/lkml/2008/6/23/160
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10821
Subject : rt25xx: lock dependency warning, association failure, and kmalloc corruption
Submitter : Christian Casteyde <[email protected]>
Date : 2008-05-29 14:30 (39 days old)
Handled-By : Ivo van Doorn <[email protected]>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10786
Subject : parisc: 64bit SMP does not boot on J5600
Submitter : Domenico Andreoli <[email protected]>
Date : 2008-05-22 16:14 (46 days old)
References : http://marc.info/?l=linux-kernel&m=121147328028081&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10741
Subject : bug in `tty: BKL pushdown'?
Submitter : Johannes Weiner <[email protected]>
Date : 2008-05-18 2:16 (50 days old)
References : http://marc.info/?l=linux-kernel&m=121107706506181&w=4
http://lkml.org/lkml/2008/6/16/104
Handled-By : Alan Cox <[email protected]>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10714
Subject : powerpc: Badness seen on 2.6.26-rc2 with lockdep enabled
Submitter : Balbir Singh <[email protected]>
Date : 2008-05-14 12:57 (54 days old)
References : http://marc.info/?l=linux-kernel&m=121076917429133&w=4
Handled-By : Benjamin Herrenschmidt <[email protected]>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10629
Subject : 2.6.26-rc1-$sha1: RIP __d_lookup+0x8c/0x160
Submitter : Alexey Dobriyan <[email protected]>
Date : 2008-05-05 09:59 (63 days old)
References : http://lkml.org/lkml/2008/5/5/28
Handled-By : Paul E. McKenney <[email protected]>
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11042
Subject : build issue #477 for v2.6.26-rc8-290-gb8a0b6c : input_event" [drivers/media/dvb/ttpci/dvb-ttpci.ko] undefined!
Submitter : Toralf Förster <[email protected]>
Date : 2008-07-05 15:25 (2 days old)
References : http://marc.info/?l=linux-kernel&m=121527158632563&w=4
Handled-By : Oliver Endriss <[email protected]>
Patch : http://marc.info/?l=linux-kernel&m=121529790229531&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11024
Subject : 2.6.25 to 2.6.26-rc8 regression (related to ahci and acpi _GTF)
Submitter : Mathieu Bérard <[email protected]>
Date : 2008-07-01 9:39 (6 days old)
References : http://marc.info/?t=121490593600001&r=1&w=4
Handled-By : Tejun Heo <[email protected]>
Patch : http://marc.info/?l=linux-kernel&m=121514631317343&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11008
Subject : after laptop re-dock: usb-storage device no longer detected
Submitter : Lukas Hejtmanek <[email protected]>
Date : 2008-06-26 17:37 (11 days old)
References : http://lkml.org/lkml/2008/6/26/391
Handled-By : Alan Stern <[email protected]>
Patch : http://lkml.org/lkml/2008/6/30/305
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11006
Subject : 2.6.26-rc6: pcmcia stopped working
Submitter : Pavel Machek <[email protected]>
Date : 2008-06-22 22:40 (15 days old)
References : http://marc.info/?l=linux-kernel&m=121420740806363&w=4
http://marc.info/?t=121439185700001&r=1&w=4
Handled-By : Tejun Heo <[email protected]>
Bartlomiej Zolnierkiewicz <[email protected]>
Patch : http://marc.info/?l=linux-kernel&m=121526230022719&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10957
Subject : pata_pcmcia with Sandisk Extreme III 8GB
Submitter : Komuro <[email protected]>
Date : 2008-06-07 13:37 (30 days old)
References : http://marc.info/?l=linux-kernel&m=121284627119861&w=4
Handled-By : Tejun Heo <[email protected]>
Dominik Brodowski <[email protected]>
Komuro <[email protected]>
Patch : http://marc.info/?l=linux-kernel&m=121530861605673&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10860
Subject : total system freeze at boot with 2.6.26-rc
Submitter : Christian Casteyde <[email protected]>
Date : 2008-06-05 12:38 (32 days old)
Handled-By : Tejun Heo <[email protected]>
Patch : http://bugzilla.kernel.org/attachment.cgi?id=16556
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10815
Subject : 2.6.26-rc4: RIP find_pid_ns+0x6b/0xa0
Submitter : Alexey Dobriyan <[email protected]>
Date : 2008-05-27 09:23 (41 days old)
References : http://lkml.org/lkml/2008/5/27/9
http://lkml.org/lkml/2008/6/14/87
Handled-By : Oleg Nesterov <[email protected]>
Linus Torvalds <[email protected]>
Paul E. McKenney <[email protected]>
Patch : http://lkml.org/lkml/2008/5/28/16
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10726
Subject : x86-64 NODES_SHIFT compile failure.
Submitter : Dave Jones <[email protected]>
Date : 2008-05-16 12:54 (52 days old)
References : http://lkml.org/lkml/2008/5/16/312
Handled-By : Mike Travis <[email protected]>
Patch : http://lkml.org/lkml/2008/5/16/343
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10725
Subject : USB Mass storage mount fails: Write protect on
Submitter : Maciej Rutecki <[email protected]>
Date : 2008-05-16 14:55 (52 days old)
References : http://marc.info/?l=linux-kernel&m=121095168003572&w=4
Handled-By : Alan Stern <[email protected]>
Patch : http://marc.info/?l=linux-scsi&m=121433068314568&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10724
Subject : ACPI: EC: GPE storm detected, disabling EC GPE
Submitter : Justin Mattock <[email protected]>
Date : 2008-05-16 6:17 (52 days old)
References : http://marc.info/?l=linux-kernel&m=121091875711824&w=4
http://lkml.org/lkml/2008/5/18/168
http://lkml.org/lkml/2008/5/25/195
Patch : http://bugzilla.kernel.org/attachment.cgi?id=16364&action=view
http://bugzilla.kernel.org/attachment.cgi?id=16365&action=view
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10493
Subject : mips BCM47XX compile error
Submitter : Adrian Bunk <[email protected]>
Date : 2008-04-20 17:07 (78 days old)
References : http://lkml.org/lkml/2008/4/20/34
http://lkml.org/lkml/2008/5/12/30
http://lkml.org/lkml/2008/5/18/131
http://lkml.org/lkml/2008/5/31/202
http://lkml.org/lkml/2008/6/7/154
Patch : http://marc.info/?l=linux-kernel&m=120876451216558&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=9791
Subject : Clock is running too fast^Wslow using acpi_pm clocksource
Submitter : [email protected]
Date : 2008-05-03 05:09 (65 days old)
Handled-By : Maciej W. Rozycki <[email protected]>
Patch : http://bugzilla.kernel.org/attachment.cgi?id=16180
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions from 2.6.25,
unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=10492
Please let me know if there are any Bugzilla entries that should be added to
the list in there.
Thanks,
Rafael
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10493
Subject : mips BCM47XX compile error
Submitter : Adrian Bunk <[email protected]>
Date : 2008-04-20 17:07 (78 days old)
References : http://lkml.org/lkml/2008/4/20/34
http://lkml.org/lkml/2008/5/12/30
http://lkml.org/lkml/2008/5/18/131
http://lkml.org/lkml/2008/5/31/202
http://lkml.org/lkml/2008/6/7/154
Patch : http://marc.info/?l=linux-kernel&m=120876451216558&w=2
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10629
Subject : 2.6.26-rc1-$sha1: RIP __d_lookup+0x8c/0x160
Submitter : Alexey Dobriyan <[email protected]>
Date : 2008-05-05 09:59 (63 days old)
References : http://lkml.org/lkml/2008/5/5/28
Handled-By : Paul E. McKenney <[email protected]>
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10741
Subject : bug in `tty: BKL pushdown'?
Submitter : Johannes Weiner <[email protected]>
Date : 2008-05-18 2:16 (50 days old)
References : http://marc.info/?l=linux-kernel&m=121107706506181&w=4
http://lkml.org/lkml/2008/6/16/104
Handled-By : Alan Cox <[email protected]>
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10714
Subject : powerpc: Badness seen on 2.6.26-rc2 with lockdep enabled
Submitter : Balbir Singh <[email protected]>
Date : 2008-05-14 12:57 (54 days old)
References : http://marc.info/?l=linux-kernel&m=121076917429133&w=4
Handled-By : Benjamin Herrenschmidt <[email protected]>
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10821
Subject : rt25xx: lock dependency warning, association failure, and kmalloc corruption
Submitter : Christian Casteyde <[email protected]>
Date : 2008-05-29 14:30 (39 days old)
Handled-By : Ivo van Doorn <[email protected]>
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10786
Subject : parisc: 64bit SMP does not boot on J5600
Submitter : Domenico Andreoli <[email protected]>
Date : 2008-05-22 16:14 (46 days old)
References : http://marc.info/?l=linux-kernel&m=121147328028081&w=4
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10725
Subject : USB Mass storage mount fails: Write protect on
Submitter : Maciej Rutecki <[email protected]>
Date : 2008-05-16 14:55 (52 days old)
References : http://marc.info/?l=linux-kernel&m=121095168003572&w=4
Handled-By : Alan Stern <[email protected]>
Patch : http://marc.info/?l=linux-scsi&m=121433068314568&w=2
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10954
Subject : hda_intel: azx_get_response timeout, switching to polling mode: last cmd=0x011f000c
Submitter : Justin Mattock <[email protected]>
Date : 2008-06-21 2:05 (16 days old)
References : http://marc.info/?l=linux-kernel&m=121401399622190&w=4
http://marc.info/?t=121416231700010&r=1&w=4
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10906
Subject : repeatable slab corruption with LTP msgctl08
Submitter : Andrew Morton <[email protected]>
Date : 2008-06-12 5:13 (25 days old)
References : http://marc.info/?l=linux-kernel&m=121324775927704&w=4
Handled-By : Pekka J Enberg <[email protected]>
Christoph Lameter <[email protected]>
Manfred Spraul <[email protected]>
Andi Kleen <[email protected]>
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10919
Subject : [regression] display dimming is slow and laggy - Acer Travelmate 661lci
Submitter : Maximilian Engelhardt <[email protected]>
Date : 2008-06-14 22:31 (23 days old)
References : http://marc.info/?l=linux-kernel&m=121348428828320&w=4
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10955
Subject : v2.6.26-rc7: BUG task_struct: Poison overwritten
Submitter : Vegard Nossum <[email protected]>
Date : 2008-06-21 19:24 (16 days old)
References : http://marc.info/?l=linux-kernel&m=121407641925121&w=4
Handled-By : Peter Zijlstra <[email protected]>
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10984
Subject : MMC print trace information when resume from suspend
Submitter : Jie Luo <[email protected]>
Date : 2008-06-26 01:15 (11 days old)
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10960
Subject : 2.6.26-rc: SPARC: Sun Ultra 10 can not boot
Submitter : Alexander Beregalov <[email protected]>
Date : 2008-06-19 14:07 (18 days old)
References : http://marc.info/?l=linux-kernel&m=121388456519637&w=4
Handled-By : David Miller <[email protected]>
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10989
Subject : kernel oopses when wiggling the mouse to make it known to hidd
Submitter : Daniel Vetter <[email protected]>
Date : 2008-06-26 10:32 (11 days old)
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11008
Subject : after laptop re-dock: usb-storage device no longer detected
Submitter : Lukas Hejtmanek <[email protected]>
Date : 2008-06-26 17:37 (11 days old)
References : http://lkml.org/lkml/2008/6/26/391
Handled-By : Alan Stern <[email protected]>
Patch : http://lkml.org/lkml/2008/6/30/305
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11009
Subject : No console on Riva TNT since 2.6.26-0.rc4
Submitter : Quel Qun <[email protected]>
Date : 2008-06-26 20:04 (11 days old)
References : http://marc.info/?l=linux-kernel&m=121451344229718&w=4
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11025
Subject : [problem] raid performance loss with 2.6.26-rc8 on 32-bit x86 (bisected)
Submitter : Dan Williams <[email protected]>
Date : 2008-07-01 1:57 (6 days old)
References : http://marc.info/?l=linux-kernel&m=121487749429883&w=4
Handled-By : Mel Gorman <[email protected]>
Andy Whitcroft <[email protected]>
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11035
Subject : System hangs on 2.6.26-rc8
Submitter : Roman Mindalev <[email protected]>
Date : 2008-07-02 14:25 (5 days old)
References : http://marc.info/?l=linux-kernel&m=121500871414995&w=4
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11039
Subject : 2.6.28-rc8-git3 forcedeth WARNING (kills the interface)
Submitter : Brad Campbell <[email protected]>
Date : 2008-07-03 10:07 (4 days old)
References : http://marc.info/?l=linux-netdev&m=121508714430752&w=4
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11040
Subject : 2.6.26-rc: host can not shutdown: ata problem
Submitter : Alexander Beregalov <[email protected]>
Date : 2008-07-03 21:43 (4 days old)
References : http://marc.info/?l=linux-kernel&m=121512197225068&w=4
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=9791
Subject : Clock is running too fast^Wslow using acpi_pm clocksource
Submitter : [email protected]
Date : 2008-05-03 05:09 (65 days old)
Handled-By : Maciej W. Rozycki <[email protected]>
Patch : http://bugzilla.kernel.org/attachment.cgi?id=16180
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11023
Subject : 2.6.26-rc8-git2 - kernel BUG at mm/page_alloc.c:585
Submitter : Kamalesh Babulal <[email protected]>
Date : 2008-07-02 11:55 (5 days old)
References : http://lkml.org/lkml/2008/7/2/32
Handled-By : Andrew Morton <[email protected]>
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10865
Subject : Oops trying to mount an ntfs partition on thinkpad
Submitter : Alex Romosan <[email protected]>
Date : 2008-06-05 14:47 (32 days old)
References : http://marc.info/?l=linux-kernel&m=121267834421414&w=4
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10860
Subject : total system freeze at boot with 2.6.26-rc
Submitter : Christian Casteyde <[email protected]>
Date : 2008-06-05 12:38 (32 days old)
Handled-By : Tejun Heo <[email protected]>
Patch : http://bugzilla.kernel.org/attachment.cgi?id=16556
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11041
Subject : All 2.6.26-rcX hang immediately after loading ohci_hcd
Submitter : Andrey Borzenkov <[email protected]>
Date : 2008-07-05 7:08 (2 days old)
References : http://marc.info/?l=linux-kernel&m=121524504505805&w=4
Handled-By : Linus Torvalds <[email protected]>
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11042
Subject : build issue #477 for v2.6.26-rc8-290-gb8a0b6c : input_event" [drivers/media/dvb/ttpci/dvb-ttpci.ko] undefined!
Submitter : Toralf Förster <[email protected]>
Date : 2008-07-05 15:25 (2 days old)
References : http://marc.info/?l=linux-kernel&m=121527158632563&w=4
Handled-By : Oliver Endriss <[email protected]>
Patch : http://marc.info/?l=linux-kernel&m=121529790229531&w=4
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10815
Subject : 2.6.26-rc4: RIP find_pid_ns+0x6b/0xa0
Submitter : Alexey Dobriyan <[email protected]>
Date : 2008-05-27 09:23 (41 days old)
References : http://lkml.org/lkml/2008/5/27/9
http://lkml.org/lkml/2008/6/14/87
Handled-By : Oleg Nesterov <[email protected]>
Linus Torvalds <[email protected]>
Paul E. McKenney <[email protected]>
Patch : http://lkml.org/lkml/2008/5/28/16
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11024
Subject : 2.6.25 to 2.6.26-rc8 regression (related to ahci and acpi _GTF)
Submitter : Mathieu Bérard <[email protected]>
Date : 2008-07-01 9:39 (6 days old)
References : http://marc.info/?t=121490593600001&r=1&w=4
Handled-By : Tejun Heo <[email protected]>
Patch : http://marc.info/?l=linux-kernel&m=121514631317343&w=4
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10726
Subject : x86-64 NODES_SHIFT compile failure.
Submitter : Dave Jones <[email protected]>
Date : 2008-05-16 12:54 (52 days old)
References : http://lkml.org/lkml/2008/5/16/312
Handled-By : Mike Travis <[email protected]>
Patch : http://lkml.org/lkml/2008/5/16/343
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10985
Subject : backlight doesn't come on after resume with i915 video
Submitter : Jon Dowland <[email protected]>
Date : 2008-06-26 02:09 (11 days old)
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10957
Subject : pata_pcmcia with Sandisk Extreme III 8GB
Submitter : Komuro <[email protected]>
Date : 2008-06-07 13:37 (30 days old)
References : http://marc.info/?l=linux-kernel&m=121284627119861&w=4
Handled-By : Tejun Heo <[email protected]>
Dominik Brodowski <[email protected]>
Komuro <[email protected]>
Patch : http://marc.info/?l=linux-kernel&m=121530861605673&w=4
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10971
Subject : radeonfb : radeon X800 family support (atombios)
Submitter : [email protected]
Date : 2008-06-23 14:35 (14 days old)
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11006
Subject : 2.6.26-rc6: pcmcia stopped working
Submitter : Pavel Machek <[email protected]>
Date : 2008-06-22 22:40 (15 days old)
References : http://marc.info/?l=linux-kernel&m=121420740806363&w=4
http://marc.info/?t=121439185700001&r=1&w=4
Handled-By : Tejun Heo <[email protected]>
Bartlomiej Zolnierkiewicz <[email protected]>
Patch : http://marc.info/?l=linux-kernel&m=121526230022719&w=4
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10724
Subject : ACPI: EC: GPE storm detected, disabling EC GPE
Submitter : Justin Mattock <[email protected]>
Date : 2008-05-16 6:17 (52 days old)
References : http://marc.info/?l=linux-kernel&m=121091875711824&w=4
http://lkml.org/lkml/2008/5/18/168
http://lkml.org/lkml/2008/5/25/195
Patch : http://bugzilla.kernel.org/attachment.cgi?id=16364&action=view
http://bugzilla.kernel.org/attachment.cgi?id=16365&action=view
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10861
Subject : 2.6.26-rc4-git2 - long pause during boot
Submitter : Chris Clayton <[email protected]>
Date : 2008-06-01 4:15 (36 days old)
References : http://marc.info/?l=linux-kernel&m=121229382917834&w=4
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10862
Subject : forcedeth: lockdep warning on ethtool -s
Submitter : Tobias Diedrich <[email protected]>
Date : 2008-06-01 8:37 (36 days old)
References : http://marc.info/?l=linux-kernel&m=121230964032247&w=4
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10843
Subject : Display artifacts on XOrg logout with PAT kernel and VESA framebuffer
Submitter : Frans Pop <[email protected]>
Date : 2008-05-31 14:04 (37 days old)
References : http://lkml.org/lkml/2008/6/7/206
http://lkml.org/lkml/2008/6/15/119
http://lkml.org/lkml/2008/6/23/160
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.25. Please verify if it still should be listed.
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10872
Subject : x86_64 boot hang when CONFIG_NUMA=n
Submitter : Randy Dunlap <[email protected]>
Date : 2008-06-05 21:50 (32 days old)
References : http://marc.info/?l=linux-kernel&m=121270308607116&w=4
http://lkml.org/lkml/2008/6/11/355
http://lkml.org/lkml/2008/6/15/117
Handled-By : Yinghai Lu <[email protected]>
On Sun, Jul 06, 2008 at 01:39:47PM +0200, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.25. Please verify if it still should be listed.
yes
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10493
> Subject : mips BCM47XX compile error
> Submitter : Adrian Bunk <[email protected]>
> Date : 2008-04-20 17:07 (78 days old)
> References : http://lkml.org/lkml/2008/4/20/34
> http://lkml.org/lkml/2008/5/12/30
> http://lkml.org/lkml/2008/5/18/131
> http://lkml.org/lkml/2008/5/31/202
> http://lkml.org/lkml/2008/6/7/154
> Patch : http://marc.info/?l=linux-kernel&m=120876451216558&w=2
cu
Adrian
Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.25. Please verify if it still should be listed.
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11039
> Subject : 2.6.28-rc8-git3 forcedeth WARNING (kills the interface)
> Submitter : Brad Campbell <[email protected]>
> Date : 2008-07-03 10:07 (4 days old)
> References : http://marc.info/?l=linux-netdev&m=121508714430752&w=4
While it is certainly a problem I can't verify it as a regression. When I got the machine I ran it
with 2.6.25 but found SATA errors were locking the box.
The SATA issue is resolved with 2.6.26-rc and I'm not terribly keen to risk my data to go back and
check unless someone absolutely needs me to.
It does appear to be quite a problem though.
brad@srv:~$ dmesg | head -n5
[ 0.000000] Linux version 2.6.26-rc8-git4 (brad@srv) (gcc version 4.1.2 20061115 (prerelease)
(Debian 4.1.1-21)) #5 SMP Fri Jul 4 23:08:38 GST 2008
[ 0.000000] Command line: root=/dev/md1 ro
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000009d400 (usable)
[ 0.000000] BIOS-e820: 000000000009d400 - 00000000000a0000 (reserved)
brad@srv:~$ dmesg | grep 'eth1: tx_timeout' | wc -l
27
brad@srv:~$ uptime
17:40:25 up 1 day, 1:15, 5 users, load average: 0.73, 0.61, 0.49
Regards,
Brad
--
Dolphins are so intelligent that within a few weeks they can
train Americans to stand at the edge of the pool and throw them
fish.
* Rafael J. Wysocki <[email protected]> wrote:
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10726
> Subject : x86-64 NODES_SHIFT compile failure.
> Submitter : Dave Jones <[email protected]>
> Date : 2008-05-16 12:54 (52 days old)
> References : http://lkml.org/lkml/2008/5/16/312
> Handled-By : Mike Travis <[email protected]>
> Patch : http://lkml.org/lkml/2008/5/16/343
fixed by:
commit efac41894df57d32b483ac622d03541b5b2692c0
Author: Thomas Gleixner <[email protected]>
Date: Tue Jul 1 08:56:32 2008 +0200
x86: fix NODES_SHIFT Kconfig range
Ingo
On Sun, 2008-07-06 at 13:45 +0200, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.25. Please verify if it still should be listed.
Erm, this isn't a kernel regression, it's a udev rule problem.
The rule has been identified and fixed; the reporter confirms it fixes
the problem and the upstream maintainer of udev is putting out a release
with it in ... what more exactly needs to be done?
James
Hi,
"Rafael J. Wysocki" <[email protected]> writes:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.25. Please verify if it still should be listed.
Yes.
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10741
> Subject : bug in `tty: BKL pushdown'?
> Submitter : Johannes Weiner <[email protected]>
> Date : 2008-05-18 2:16 (50 days old)
> References : http://marc.info/?l=linux-kernel&m=121107706506181&w=4
> http://lkml.org/lkml/2008/6/16/104
> Handled-By : Alan Cox <[email protected]>
Hannes
On Sun, 6 Jul 2008, Rafael J. Wysocki wrote:
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11025
> Subject : [problem] raid performance loss with 2.6.26-rc8 on 32-bit x86 (bisected)
> Submitter : Dan Williams <[email protected]>
> Date : 2008-07-01 1:57 (6 days old)
> References : http://marc.info/?l=linux-kernel&m=121487749429883&w=4
> Handled-By : Mel Gorman <[email protected]>
> Andy Whitcroft <[email protected]>
Fixed by commit 494de90098784b8e2797598cefdd34188884ec2e: "Do not
overwrite nr_zones on !NUMA when initialising zlcache_ptr" by Mel.
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10919
> Subject : [regression] display dimming is slow and laggy - Acer Travelmate 661lci
> Submitter : Maximilian Engelhardt <[email protected]>
> Date : 2008-06-14 22:31 (23 days old)
> References : http://marc.info/?l=linux-kernel&m=121348428828320&w=4
I wonder if this one could be related. The 'nr_zones' overwriting bug
would result in kswapd not reclaiming any memory asynchronously, so the
kernel would basically be constantly under a low-memory situation, and
processes would be forced to do synchronous reclaim.
That, in turn, could easily explain laggy operation, especially if it is
something bigger that needs to allocate new memory (not that I know if X
dimming needs to, but I could imagine that it does some double buffering
or whatever).
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10872
> Subject : x86_64 boot hang when CONFIG_NUMA=n
> Submitter : Randy Dunlap <[email protected]>
> Date : 2008-06-05 21:50 (32 days old)
> References : http://marc.info/?l=linux-kernel&m=121270308607116&w=4
> http://lkml.org/lkml/2008/6/11/355
> http://lkml.org/lkml/2008/6/15/117
> Handled-By : Yinghai Lu <[email protected]>
This really doesn't sound like low memory, but the CONFIG_NUMA thing is
intriguing, since again, the 'nr_zones' thing depended on that. It would
break 'balance_pgdat()' entirely, and maybe some balancing operation can
get confused even before you actually run out of memory
Unlikely, but worth re-testing.
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11008
> Subject : after laptop re-dock: usb-storage device no longer detected
> Submitter : Lukas Hejtmanek <[email protected]>
> Date : 2008-06-26 17:37 (11 days old)
> References : http://lkml.org/lkml/2008/6/26/391
> Handled-By : Alan Stern <[email protected]>
> Patch : http://lkml.org/lkml/2008/6/30/305
This patch got merged: commit 1236edf1c70107a0d31b3fba0b2a8783615d0d24
("USB: don't lose disconnections during suspend").
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11006
> Subject : 2.6.26-rc6: pcmcia stopped working
> Submitter : Pavel Machek <[email protected]>
> Date : 2008-06-22 22:40 (15 days old)
> References : http://marc.info/?l=linux-kernel&m=121420740806363&w=4
> http://marc.info/?t=121439185700001&r=1&w=4
> Handled-By : Tejun Heo <[email protected]>
> Bartlomiej Zolnierkiewicz <[email protected]>
> Patch : http://marc.info/?l=linux-kernel&m=121526230022719&w=4
Ditto: commit 7cd95f56cb61f5348d062527c9d3653196f6e629 ("ide: fix
hwif->gendev refcounting")
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10860
> Subject : total system freeze at boot with 2.6.26-rc
> Submitter : Christian Casteyde <[email protected]>
> Date : 2008-06-05 12:38 (32 days old)
> Handled-By : Tejun Heo <[email protected]>
> Patch : http://bugzilla.kernel.org/attachment.cgi?id=16556
Fixed in commit 70a3143af87c6ca188107cbd49ab5eec2c86c456 ("sata_uli:
hardreset is broken")
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10815
> Subject : 2.6.26-rc4: RIP find_pid_ns+0x6b/0xa0
> Submitter : Alexey Dobriyan <[email protected]>
> Date : 2008-05-27 09:23 (41 days old)
> References : http://lkml.org/lkml/2008/5/27/9
> http://lkml.org/lkml/2008/6/14/87
> Handled-By : Oleg Nesterov <[email protected]>
> Linus Torvalds <[email protected]>
> Paul E. McKenney <[email protected]>
> Patch : http://lkml.org/lkml/2008/5/28/16
This one is the same thing that is reported as unresolved, and no, I don't
think that existing patch was ever really tested to fix anything. Paul?
I suspect SRCU will need to be simply marked BROKEN for now, because
nobody knows what the problem Alexey sees is. Apparently it's been seen by
a few other people too.
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10726
> Subject : x86-64 NODES_SHIFT compile failure.
> Submitter : Dave Jones <[email protected]>
> Date : 2008-05-16 12:54 (52 days old)
> References : http://lkml.org/lkml/2008/5/16/312
> Handled-By : Mike Travis <[email protected]>
> Patch : http://lkml.org/lkml/2008/5/16/343
Fixed in commit efac41894df57d32b483ac622d03541b5b2692c0 ("x86: fix
NODES_SHIFT Kconfig range").
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10725
> Subject : USB Mass storage mount fails: Write protect on
> Submitter : Maciej Rutecki <[email protected]>
> Date : 2008-05-16 14:55 (52 days old)
> References : http://marc.info/?l=linux-kernel&m=121095168003572&w=4
> Handled-By : Alan Stern <[email protected]>
> Patch : http://marc.info/?l=linux-scsi&m=121433068314568&w=2
Hmm. James?
Linus
On Sun, Jul 06, 2008 at 08:46:09AM -0700, Linus Torvalds wrote:
> On Sun, 6 Jul 2008, Rafael J. Wysocki wrote:
>...
> Fixed by commit 494de90098784b8e2797598cefdd34188884ec2e: "Do not
> overwrite nr_zones on !NUMA when initialising zlcache_ptr" by Mel.
>...
> This patch got merged: commit 1236edf1c70107a0d31b3fba0b2a8783615d0d24
> ("USB: don't lose disconnections during suspend").
>...
> Ditto: commit 7cd95f56cb61f5348d062527c9d3653196f6e629 ("ide: fix
> hwif->gendev refcounting")
>...
> Fixed in commit 70a3143af87c6ca188107cbd49ab5eec2c86c456 ("sata_uli:
> hardreset is broken")
>...
> Fixed in commit efac41894df57d32b483ac622d03541b5b2692c0 ("x86: fix
> NODES_SHIFT Kconfig range").
>...
Thanks, all closed.
(I do try to close fixed regression bugs immediately after a fix enters
your tree, but espicially for commits without a reference to a Bugzilla
entry I sometimes miss it.)
> Linus
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
"Rafael J. Wysocki" <[email protected]> writes:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.25. Please verify if it still should be listed.
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10865
> Subject : Oops trying to mount an ntfs partition on thinkpad
> Submitter : Alex Romosan <[email protected]>
> Date : 2008-06-05 14:47 (32 days old)
> References : http://marc.info/?l=linux-kernel&m=121267834421414&w=4
>
save behaviour with rc9.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
On Sun, 2008-07-06 at 08:46 -0700, Linus Torvalds wrote:
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10725
> > Subject : USB Mass storage mount fails: Write protect on
> > Submitter : Maciej Rutecki <[email protected]>
> > Date : 2008-05-16 14:55 (52 days old)
> > References : http://marc.info/?l=linux-kernel&m=121095168003572&w=4
> > Handled-By : Alan Stern <[email protected]>
> > Patch : http://marc.info/?l=linux-scsi&m=121433068314568&w=2
>
> Hmm. James?
Oh ... it was reported against 2.6.26-rc1, so the fix is actually
crrently queued for scsi-misc in my internal test rig. However, the
reason for the long QA is that there's a potential danger to the fix
which is clearing the buffer from the reported length to the actual
length will break a SCSI card that misreports the returned length. It
seems to be OK on my esoteric SCSI card collection, so I'll push it out
to scsi-rc-fixes. However, I think it still wants to run in linux-next
for a few days to see if anyone else can turn up a problem.
The true issue, of course, is that we won't see a problem until the
2.6.26 release because the hardware that triggers it isn't in the set
we're testing with. A less risky fix for 2.6.26-rc9 might be to move
the clearing into the affected subsystem (usbstorage).
James
* Linus Torvalds <[email protected]> wrote:
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10815
> > Subject : 2.6.26-rc4: RIP find_pid_ns+0x6b/0xa0
> > Submitter : Alexey Dobriyan <[email protected]>
> > Date : 2008-05-27 09:23 (41 days old)
> > References : http://lkml.org/lkml/2008/5/27/9
> > http://lkml.org/lkml/2008/6/14/87
> > Handled-By : Oleg Nesterov <[email protected]>
> > Linus Torvalds <[email protected]>
> > Paul E. McKenney <[email protected]>
> > Patch : http://lkml.org/lkml/2008/5/28/16
>
> This one is the same thing that is reported as unresolved, and no, I
> don't think that existing patch was ever really tested to fix
> anything. Paul?
>
> I suspect SRCU will need to be simply marked BROKEN for now, because
> nobody knows what the problem Alexey sees is. Apparently it's been
> seen by a few other people too.
I'm not sure it's directly related to SRCU - it can change timings and
freeing patterns enough to tickle other bugs. Since Alexey Dobriyan has
reported it - are perhaps namespaces in use during this stress-test?
Maybe it's some namespaces related bug that is more easily reproduced
under SRCU - namespaces is not a commonly tested feature.
Also, i've been running rcutorture stress-tests on a number of
test-systems ever since this got reported (and they are running
currently as well) and cannot see it - neither could Paul reproduce it.
( and Paul is very good in producing RCU related problems - he's
triggered and fixed many RCU related problems that no-one else saw
before. )
Ingo
On Sunday, 6 of July 2008, Adrian Bunk wrote:
> On Sun, Jul 06, 2008 at 08:46:09AM -0700, Linus Torvalds wrote:
> > On Sun, 6 Jul 2008, Rafael J. Wysocki wrote:
> >...
> > Fixed by commit 494de90098784b8e2797598cefdd34188884ec2e: "Do not
> > overwrite nr_zones on !NUMA when initialising zlcache_ptr" by Mel.
> >...
> > This patch got merged: commit 1236edf1c70107a0d31b3fba0b2a8783615d0d24
> > ("USB: don't lose disconnections during suspend").
> >...
> > Ditto: commit 7cd95f56cb61f5348d062527c9d3653196f6e629 ("ide: fix
> > hwif->gendev refcounting")
> >...
> > Fixed in commit 70a3143af87c6ca188107cbd49ab5eec2c86c456 ("sata_uli:
> > hardreset is broken")
> >...
> > Fixed in commit efac41894df57d32b483ac622d03541b5b2692c0 ("x86: fix
> > NODES_SHIFT Kconfig range").
> >...
>
> Thanks, all closed.
>
> (I do try to close fixed regression bugs immediately after a fix enters
> your tree, but espicially for commits without a reference to a Bugzilla
> entry I sometimes miss it.)
Also, in the next couple of days I'll be closing the bugs the reporters of
which have been totally unresponsive.
I'll post an updated report after that.
Thanks,
Rafael
On Sunday, 6 of July 2008, James Bottomley wrote:
> On Sun, 2008-07-06 at 13:45 +0200, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.25. Please verify if it still should be listed.
>
> Erm, this isn't a kernel regression, it's a udev rule problem.
>
> The rule has been identified and fixed; the reporter confirms it fixes
> the problem and the upstream maintainer of udev is putting out a release
> with it in ... what more exactly needs to be done?
Closed as "invalid".
Thanks,
Rafael
On Sun, Jul 6, 2008 at 11:45 AM, Rafael J. Wysocki <[email protected]> wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.25. Please verify if it still should be listed.
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10954
> Subject : hda_intel: azx_get_response timeout, switching to polling mode: last cmd=0x011f000c
> Submitter : Justin Mattock <[email protected]>
> Date : 2008-06-21 2:05 (16 days old)
> References : http://marc.info/?l=linux-kernel&m=121401399622190&w=4
> http://marc.info/?t=121416231700010&r=1&w=4
>
>
>
yes;
as an estimate(been busy with another bug), I'm going to say out of
100 reboots this message will
appear 2 times in a row, and then disappear.
regards;
--
Justin P. Mattock
On Sun, Jul 06, 2008 at 07:05:49PM +0200, Rafael J. Wysocki wrote:
>
> Also, in the next couple of days I'll be closing the bugs the reporters of
> which have been totally unresponsive.
>...
If no action by us gets combined with automated weekly emails then
no responses to the latter is not an unexpected event.
Such a submitter might be perfectly responsive to actual work on a bug
while really pissed off by getting the bug closed.
Look e.g. at #10865 that had a 1 month gap in submitter responses,
but the actual problem is that noone of us ever bothered to look at
this Oops...
I just did a run through all open 2.6.26-rc regressions, and I did not
find a single one where we seem to be waiting for some time for an
answer of the submitter. [1]
> Thanks,
> Rafael
cu
Adrian
[1] unless there was communication not linked from Bugzilla
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Sun, Jul 6, 2008 at 11:45 AM, Rafael J. Wysocki <[email protected]> wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.25. Please verify if it still should be listed.
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10724
> Subject : ACPI: EC: GPE storm detected, disabling EC GPE
> Submitter : Justin Mattock <[email protected]>
> Date : 2008-05-16 6:17 (52 days old)
> References : http://marc.info/?l=linux-kernel&m=121091875711824&w=4
> http://lkml.org/lkml/2008/5/18/168
> http://lkml.org/lkml/2008/5/25/195
> Patch : http://bugzilla.kernel.org/attachment.cgi?id=16364&action=view
> http://bugzilla.kernel.org/attachment.cgi?id=16365&action=view
>
>
>
yes;
>From what I can see so far, the reason for the gpe storm detector going off
is due to too many interrupts with the battery. As an example there was
a bug filed for the same issue with the macbook's:
https://bugzilla.novell.com/show_bug.cgi?id=301365#c10
using acpi_osi=Darwin does prevent the gpe storm detector from
going off, but you loose any info on the battery. If anybody has any ideas on
modifying any of the battery modules, or adjusting the DSDT it sure
would be appreciated.
regards;
--
Justin P. Mattock
On Sunday, 6 of July 2008, Adrian Bunk wrote:
> On Sun, Jul 06, 2008 at 07:05:49PM +0200, Rafael J. Wysocki wrote:
> >
> > Also, in the next couple of days I'll be closing the bugs the reporters of
> > which have been totally unresponsive.
> >...
>
> If no action by us gets combined with automated weekly emails then
> no responses to the latter is not an unexpected event.
>
> Such a submitter might be perfectly responsive to actual work on a bug
> while really pissed off by getting the bug closed.
>
> Look e.g. at #10865 that had a 1 month gap in submitter responses,
> but the actual problem is that noone of us ever bothered to look at
> this Oops...
>
> I just did a run through all open 2.6.26-rc regressions, and I did not
> find a single one where we seem to be waiting for some time for an
> answer of the submitter. [1]
The following are my candidates:
10629
10786
10815
10906 (the thread has apparently died)
11009
Thanks,
Rafael
On Sun, 6 Jul 2008 13:45:53 +0200 (CEST) Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.25. Please verify if it still should be listed.
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10872
> Subject : x86_64 boot hang when CONFIG_NUMA=n
> Submitter : Randy Dunlap <[email protected]>
> Date : 2008-06-05 21:50 (32 days old)
> References : http://marc.info/?l=linux-kernel&m=121270308607116&w=4
> http://lkml.org/lkml/2008/6/11/355
> http://lkml.org/lkml/2008/6/15/117
> Handled-By : Yinghai Lu <[email protected]>
This still happens with 2.6.26-rc9. Using CONFIG_NUMA=y boots OK.
The last lines from the (netconsole) log are:
calling early_fill_mp_bus_info+0x0/0x7b2
node 0 link 1: io port [1000, 3fff]
node 1 link 2: io port [4000, ffff]
TOM: 0000000080000000 aka 2048M
node 0 link 1: mmio [e8000000, fddfffff]
node 1 link 2: mmio [fde00000, fdffffff]
node 0 link 1: mmio [80000000, 83ffffff]
node 1 link 2: mmio [84000000, 8fffffff]
node 0 link 1: mmio [a0000, bffff]
TOM2: 0000000280000000 aka 10240M
bus: [00,3f] on node 0 link 1
bus: 00 index 0 io port: [0, 3fff]
bus: 00 index 1 mmio: [90000000, fddfffff]
bus: 00 index 2 mmio: [80000000, 83ffffff]
bus: 00 index 3 mmio: [a0000, bffff]
bus: 00 index 4 mmio: [fe000000, ffffffff]
bus: 00 index 5 mmio: [280000000, fcffffffff]
bus: [40,ff] on node 1 link 2
bus: 40 index 0 io port: [4000, ffff]
bus: 40 index 1 mmio: [fde00000, fdffffff]
---
~Randy
Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA
http://linuxplumbersconf.org/
On Sun, Jul 06, 2008 at 08:02:45PM +0200, Rafael J. Wysocki wrote:
> On Sunday, 6 of July 2008, Adrian Bunk wrote:
> > On Sun, Jul 06, 2008 at 07:05:49PM +0200, Rafael J. Wysocki wrote:
> > >
> > > Also, in the next couple of days I'll be closing the bugs the reporters of
> > > which have been totally unresponsive.
> > >...
> >
> > If no action by us gets combined with automated weekly emails then
> > no responses to the latter is not an unexpected event.
> >
> > Such a submitter might be perfectly responsive to actual work on a bug
> > while really pissed off by getting the bug closed.
> >
> > Look e.g. at #10865 that had a 1 month gap in submitter responses,
> > but the actual problem is that noone of us ever bothered to look at
> > this Oops...
> >
> > I just did a run through all open 2.6.26-rc regressions, and I did not
> > find a single one where we seem to be waiting for some time for an
> > answer of the submitter. [1]
>
> The following are my candidates:
>
> 10629
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10629
Subject : 2.6.26-rc1-$sha1: RIP __d_lookup+0x8c/0x160
Submitter : Alexey Dobriyan <[email protected]>
Date : 2008-05-05 09:59 (63 days old)
References : http://lkml.org/lkml/2008/5/5/28
Handled-By : Paul E. McKenney <[email protected]>
See below at #10815.
> 10786
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10786
Subject : parisc: 64bit SMP does not boot on J5600
Submitter : Domenico Andreoli <[email protected]>
Date : 2008-05-22 16:14 (46 days old)
References : http://marc.info/?l=linux-kernel&m=121147328028081&w=4
Submitter sent bug report, it seems no kernel developer ever bothered
to answer.
The unresponsive side is not the submitter.
> 10815
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10815
Subject : 2.6.26-rc4: RIP find_pid_ns+0x6b/0xa0
Submitter : Alexey Dobriyan <[email protected]>
Date : 2008-05-27 09:23 (41 days old)
References : http://lkml.org/lkml/2008/5/27/9
http://lkml.org/lkml/2008/6/14/87
Handled-By : Oleg Nesterov <[email protected]>
Linus Torvalds <[email protected]>
Paul E. McKenney <[email protected]>
Patch : http://lkml.org/lkml/2008/5/28/16
Linus just restarted discussing this one and #10629.
My impression of both bugs is that not that Alexey was unresponsive but
that noone else was able to reproduce it.
> 10906 (the thread has apparently died)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10906
Subject : repeatable slab corruption with LTP msgctl08
Submitter : Andrew Morton <[email protected]>
Date : 2008-06-12 5:13 (25 days old)
References : http://marc.info/?l=linux-kernel&m=121324775927704&w=4
Handled-By : Pekka J Enberg <[email protected]>
Christoph Lameter <[email protected]>
Manfred Spraul <[email protected]>
Andi Kleen <[email protected]>
Andrew Morton said [1]:
erk. It'll make me a week to bisect this. I suppose I can plod away
at it in the background, but I won't be able to do that until the end
of this month.
And "repeatable slab corruption" is not exactly a good regression
to ignore...
> 11009
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11009
Subject : No console on Riva TNT since 2.6.26-0.rc4
Submitter : Quel Qun <[email protected]>
Date : 2008-06-26 20:04 (11 days old)
References : http://marc.info/?l=linux-kernel&m=121451344229718&w=4
Submitter sent bug report, it seems no kernel developer ever bothered
to answer.
The unresponsive side is not the submitter.
> Thanks,
> Rafael
cu
Adrian
[1] http://lkml.org/lkml/2008/6/13/45
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Sun, 6 Jul 2008, Randy Dunlap wrote:
>
> This still happens with 2.6.26-rc9. Using CONFIG_NUMA=y boots OK.
Ok, then it wasn't the nr_zones thing.
Since it seems to be repeatable for you, can you bisect it?
Linus
On Sunday, 6 of July 2008, Adrian Bunk wrote:
> On Sun, Jul 06, 2008 at 08:02:45PM +0200, Rafael J. Wysocki wrote:
> > On Sunday, 6 of July 2008, Adrian Bunk wrote:
> > > On Sun, Jul 06, 2008 at 07:05:49PM +0200, Rafael J. Wysocki wrote:
> > > >
> > > > Also, in the next couple of days I'll be closing the bugs the reporters of
> > > > which have been totally unresponsive.
> > > >...
> > >
> > > If no action by us gets combined with automated weekly emails then
> > > no responses to the latter is not an unexpected event.
> > >
> > > Such a submitter might be perfectly responsive to actual work on a bug
> > > while really pissed off by getting the bug closed.
> > >
> > > Look e.g. at #10865 that had a 1 month gap in submitter responses,
> > > but the actual problem is that noone of us ever bothered to look at
> > > this Oops...
> > >
> > > I just did a run through all open 2.6.26-rc regressions, and I did not
> > > find a single one where we seem to be waiting for some time for an
> > > answer of the submitter. [1]
> >
> > The following are my candidates:
> >
> > 10629
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10629
> Subject : 2.6.26-rc1-$sha1: RIP __d_lookup+0x8c/0x160
> Submitter : Alexey Dobriyan <[email protected]>
> Date : 2008-05-05 09:59 (63 days old)
> References : http://lkml.org/lkml/2008/5/5/28
> Handled-By : Paul E. McKenney <[email protected]>
>
>
> See below at #10815.
>
>
> > 10786
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10786
> Subject : parisc: 64bit SMP does not boot on J5600
> Submitter : Domenico Andreoli <[email protected]>
> Date : 2008-05-22 16:14 (46 days old)
> References : http://marc.info/?l=linux-kernel&m=121147328028081&w=4
>
>
> Submitter sent bug report, it seems no kernel developer ever bothered
> to answer.
>
> The unresponsive side is not the submitter.
The report is 46 days old and the reporter has been sent a request to confirm
the presence of the problem every week. Since he hasn't responded to any
of those requests, I assume we're not going to hear from him. Thus, it's not
useful to track this any more.
Thanks,
Rafael
On Sun, Jul 06, 2008 at 11:04:06PM +0200, Rafael J. Wysocki wrote:
> On Sunday, 6 of July 2008, Adrian Bunk wrote:
> > On Sun, Jul 06, 2008 at 08:02:45PM +0200, Rafael J. Wysocki wrote:
> > > On Sunday, 6 of July 2008, Adrian Bunk wrote:
> > > > On Sun, Jul 06, 2008 at 07:05:49PM +0200, Rafael J. Wysocki wrote:
> > > > >
> > > > > Also, in the next couple of days I'll be closing the bugs the reporters of
> > > > > which have been totally unresponsive.
> > > > >...
> > > >
> > > > If no action by us gets combined with automated weekly emails then
> > > > no responses to the latter is not an unexpected event.
> > > >
> > > > Such a submitter might be perfectly responsive to actual work on a bug
> > > > while really pissed off by getting the bug closed.
> > > >
> > > > Look e.g. at #10865 that had a 1 month gap in submitter responses,
> > > > but the actual problem is that noone of us ever bothered to look at
> > > > this Oops...
> > > >
> > > > I just did a run through all open 2.6.26-rc regressions, and I did not
> > > > find a single one where we seem to be waiting for some time for an
> > > > answer of the submitter. [1]
> > >
> > > The following are my candidates:
> > >
> > > 10629
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10629
> > Subject : 2.6.26-rc1-$sha1: RIP __d_lookup+0x8c/0x160
> > Submitter : Alexey Dobriyan <[email protected]>
> > Date : 2008-05-05 09:59 (63 days old)
> > References : http://lkml.org/lkml/2008/5/5/28
> > Handled-By : Paul E. McKenney <[email protected]>
> >
> >
> > See below at #10815.
> >
> >
> > > 10786
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10786
> > Subject : parisc: 64bit SMP does not boot on J5600
> > Submitter : Domenico Andreoli <[email protected]>
> > Date : 2008-05-22 16:14 (46 days old)
> > References : http://marc.info/?l=linux-kernel&m=121147328028081&w=4
> >
> >
> > Submitter sent bug report, it seems no kernel developer ever bothered
> > to answer.
> >
> > The unresponsive side is not the submitter.
>
> The report is 46 days old and the reporter has been sent a request to confirm
> the presence of the problem every week. Since he hasn't responded to any
> of those requests, I assume we're not going to hear from him. Thus, it's not
> useful to track this any more.
Andrew Morton also never bothered to answer the automated emails you
sent him regarding the regression he reported...
Humans react differently to programs than to humans interacting with
them, and tons of automated mails without any actual efforts by humans
can easily be considered a non-friendly act.
But for this bug I now found the commit that fixed it back in May.
Is there any specific reason why your automated emails only go to the
submitters but not to the maintainers of the code in question? If you
had Cc'ed Kyle once during the last 46 days he might have remembered
that he already fixed this bug...
> Thanks,
> Rafael
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Sunday, 6 of July 2008, Adrian Bunk wrote:
> On Sun, Jul 06, 2008 at 11:04:06PM +0200, Rafael J. Wysocki wrote:
> > On Sunday, 6 of July 2008, Adrian Bunk wrote:
> > > On Sun, Jul 06, 2008 at 08:02:45PM +0200, Rafael J. Wysocki wrote:
> > > > On Sunday, 6 of July 2008, Adrian Bunk wrote:
> > > > > On Sun, Jul 06, 2008 at 07:05:49PM +0200, Rafael J. Wysocki wrote:
> > > > > >
> > > > > > Also, in the next couple of days I'll be closing the bugs the reporters of
> > > > > > which have been totally unresponsive.
> > > > > >...
> > > > >
> > > > > If no action by us gets combined with automated weekly emails then
> > > > > no responses to the latter is not an unexpected event.
> > > > >
> > > > > Such a submitter might be perfectly responsive to actual work on a bug
> > > > > while really pissed off by getting the bug closed.
> > > > >
> > > > > Look e.g. at #10865 that had a 1 month gap in submitter responses,
> > > > > but the actual problem is that noone of us ever bothered to look at
> > > > > this Oops...
> > > > >
> > > > > I just did a run through all open 2.6.26-rc regressions, and I did not
> > > > > find a single one where we seem to be waiting for some time for an
> > > > > answer of the submitter. [1]
> > > >
> > > > The following are my candidates:
> > > >
> > > > 10629
> > >
> > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10629
> > > Subject : 2.6.26-rc1-$sha1: RIP __d_lookup+0x8c/0x160
> > > Submitter : Alexey Dobriyan <[email protected]>
> > > Date : 2008-05-05 09:59 (63 days old)
> > > References : http://lkml.org/lkml/2008/5/5/28
> > > Handled-By : Paul E. McKenney <[email protected]>
> > >
> > >
> > > See below at #10815.
> > >
> > >
> > > > 10786
> > >
> > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10786
> > > Subject : parisc: 64bit SMP does not boot on J5600
> > > Submitter : Domenico Andreoli <[email protected]>
> > > Date : 2008-05-22 16:14 (46 days old)
> > > References : http://marc.info/?l=linux-kernel&m=121147328028081&w=4
> > >
> > >
> > > Submitter sent bug report, it seems no kernel developer ever bothered
> > > to answer.
> > >
> > > The unresponsive side is not the submitter.
> >
> > The report is 46 days old and the reporter has been sent a request to confirm
> > the presence of the problem every week. Since he hasn't responded to any
> > of those requests, I assume we're not going to hear from him. Thus, it's not
> > useful to track this any more.
>
> Andrew Morton also never bothered to answer the automated emails you
> sent him regarding the regression he reported...
>
> Humans react differently to programs than to humans interacting with
> them, and tons of automated mails without any actual efforts by humans
> can easily be considered a non-friendly act.
>
> But for this bug I now found the commit that fixed it back in May.
>
> Is there any specific reason why your automated emails only go to the
> submitters but not to the maintainers of the code in question?
Yes, there is. We'd have to add special annotations to bug reports for that
and I'm not always sure which list/maintainer combination is appropriate.
> If you had Cc'ed Kyle once during the last 46 days he might have remembered
> that he already fixed this bug...
He might have looked at the regression reports just as well.
Thanks,
Rafael
On Mon, 7 Jul 2008, Adrian Bunk wrote:
>
> Humans react differently to programs than to humans interacting with
> them, and tons of automated mails without any actual efforts by humans
> can easily be considered a non-friendly act.
Adrian - please just stop this.
*DEVELOPERS* are human too.
And if you cannot accept the fact that developers need feedback as well as
reporters - a simple "is it still a problem" report - then why the *hell*
do you then talk about reporters being human?
> But for this bug I now found the commit that fixed it back in May.
Exactly. A _lot_ of problems are fixed independently of a specific
bug-report, either because others reported the issue too (and people
didn't necessarily even realize that it was the same problem), or because
a developer found it independently and fixed it.
> Is there any specific reason why your automated emails only go to the
> submitters but not to the maintainers of the code in question?
Is there any specific reason that you have been complaining about this for
A HELL OF A LONG TIME, without ever actually listening to what people like
me tell you, over and over and over again?
And no, this email wasn't autogenerated. But you seem to never react to
this.
Bug-reports absolutely *have* to be closed if they don't get minimal
feedback, including just a "it's still a problem".
Just accept it, Adrian.
Linus
On Sun, 6 Jul 2008, Rafael J. Wysocki wrote:
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11041
> Subject : All 2.6.26-rcX hang immediately after loading ohci_hcd
> Submitter : Andrey Borzenkov <[email protected]>
> Date : 2008-07-05 7:08 (2 days old)
> References : http://marc.info/?l=linux-kernel&m=121524504505805&w=4
> Handled-By : Linus Torvalds <[email protected]>
The revert that was confirmed by Andrey to fix this regression is now
committed as 09ca8adbe9f724a7e96f512c0039c4c4a1c5dcc0.
Linus
On Sunday, 6 of July 2008, Rafael J. Wysocki wrote:
> On Sunday, 6 of July 2008, Adrian Bunk wrote:
> > On Sun, Jul 06, 2008 at 11:04:06PM +0200, Rafael J. Wysocki wrote:
> > > On Sunday, 6 of July 2008, Adrian Bunk wrote:
> > > > On Sun, Jul 06, 2008 at 08:02:45PM +0200, Rafael J. Wysocki wrote:
> > > > > On Sunday, 6 of July 2008, Adrian Bunk wrote:
> > > > > > On Sun, Jul 06, 2008 at 07:05:49PM +0200, Rafael J. Wysocki wrote:
> > > > > > >
> > > > > > > Also, in the next couple of days I'll be closing the bugs the reporters of
> > > > > > > which have been totally unresponsive.
> > > > > > >...
> > > > > >
> > > > > > If no action by us gets combined with automated weekly emails then
> > > > > > no responses to the latter is not an unexpected event.
> > > > > >
> > > > > > Such a submitter might be perfectly responsive to actual work on a bug
> > > > > > while really pissed off by getting the bug closed.
> > > > > >
> > > > > > Look e.g. at #10865 that had a 1 month gap in submitter responses,
> > > > > > but the actual problem is that noone of us ever bothered to look at
> > > > > > this Oops...
> > > > > >
> > > > > > I just did a run through all open 2.6.26-rc regressions, and I did not
> > > > > > find a single one where we seem to be waiting for some time for an
> > > > > > answer of the submitter. [1]
> > > > >
> > > > > The following are my candidates:
> > > > >
> > > > > 10629
> > > >
> > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10629
> > > > Subject : 2.6.26-rc1-$sha1: RIP __d_lookup+0x8c/0x160
> > > > Submitter : Alexey Dobriyan <[email protected]>
> > > > Date : 2008-05-05 09:59 (63 days old)
> > > > References : http://lkml.org/lkml/2008/5/5/28
> > > > Handled-By : Paul E. McKenney <[email protected]>
> > > >
> > > >
> > > > See below at #10815.
> > > >
> > > >
> > > > > 10786
> > > >
> > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10786
> > > > Subject : parisc: 64bit SMP does not boot on J5600
> > > > Submitter : Domenico Andreoli <[email protected]>
> > > > Date : 2008-05-22 16:14 (46 days old)
> > > > References : http://marc.info/?l=linux-kernel&m=121147328028081&w=4
> > > >
> > > >
> > > > Submitter sent bug report, it seems no kernel developer ever bothered
> > > > to answer.
> > > >
> > > > The unresponsive side is not the submitter.
> > >
> > > The report is 46 days old and the reporter has been sent a request to confirm
> > > the presence of the problem every week. Since he hasn't responded to any
> > > of those requests, I assume we're not going to hear from him. Thus, it's not
> > > useful to track this any more.
> >
> > Andrew Morton also never bothered to answer the automated emails you
> > sent him regarding the regression he reported...
> >
> > Humans react differently to programs than to humans interacting with
> > them, and tons of automated mails without any actual efforts by humans
> > can easily be considered a non-friendly act.
BTW, the automated emails I'm sending are to let the reporters know that I'm
interested in the current status of the bug. They are free not to reply to
them, but in that case I assume they don't really care whether or not I'm
tracking the bugs they reported.
Thanks,
Rafael
On Sunday, 6 of July 2008, Linus Torvalds wrote:
>
> On Sun, 6 Jul 2008, Rafael J. Wysocki wrote:
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11041
> > Subject : All 2.6.26-rcX hang immediately after loading ohci_hcd
> > Submitter : Andrey Borzenkov <[email protected]>
> > Date : 2008-07-05 7:08 (2 days old)
> > References : http://marc.info/?l=linux-kernel&m=121524504505805&w=4
> > Handled-By : Linus Torvalds <[email protected]>
>
> The revert that was confirmed by Andrey to fix this regression is now
> committed as 09ca8adbe9f724a7e96f512c0039c4c4a1c5dcc0.
Thanks, I have closed the bug.
Rafael
On Sun, Jul 06, 2008 at 11:47:58PM +0200, Rafael J. Wysocki wrote:
> On Sunday, 6 of July 2008, Adrian Bunk wrote:
>...
> > Is there any specific reason why your automated emails only go to the
> > submitters but not to the maintainers of the code in question?
>
> Yes, there is. We'd have to add special annotations to bug reports for that
> and I'm not always sure which list/maintainer combination is appropriate.
Then make a wild guess.
Long ago when I was doing regression tracking I sometimes added a dozen
addresses from 3 different MAINTAINERS entry for one bug report for
getting emails to all involved parties.
Not sure whether Bugzilla is the right place for maintaining this
information, but even if it takes a few minutes to add it to
all regression reports when sending the emails it's in my experience
worth it.
> > If you had Cc'ed Kyle once during the last 46 days he might have remembered
> > that he already fixed this bug...
>
> He might have looked at the regression reports just as well.
There is a huge difference between offering information for maintainers
that are actively searching for it and regularly annoying maintainers
that there's a regression they have forgotten about they should fix...
> Thanks,
> Rafael
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On 06-07-08 23:56, Rafael J. Wysocki wrote:
> BTW, the automated emails I'm sending are to let the reporters know
> that I'm interested in the current status of the bug. They are free
> not to reply to them, but in that case I assume they don't really
> care whether or not I'm tracking the bugs they reported.
I did/do wonder by the way when I get them if I should be replying if
the status is unchanged from my viewpoint...
I believe your automated emails say something like "please verify if
this problem is still relevant" but don't spell out what do after you
verified that it is. It's sort of natural to take that as "I need to
reply telling people it's fixed if it is but can remain silent if
nothing changed".
Being more explicit about liking a reporter to report "yes, nothing
changed" would probably be good if that IS what's wanted.
Rene.
On Sun, Jul 06, 2008 at 02:47:42PM -0700, Linus Torvalds wrote:
> On Mon, 7 Jul 2008, Adrian Bunk wrote:
>...
> > Is there any specific reason why your automated emails only go to the
> > submitters but not to the maintainers of the code in question?
>
> Is there any specific reason that you have been complaining about this for
> A HELL OF A LONG TIME, without ever actually listening to what people like
> me tell you, over and over and over again?
>...
When did you tell me that maintainers should not or cannot be Cc'ed on
regression reports?
Sorry, but I honestly don't remember this.
You did not complain when I did this when I was doing regression
tracking, and if you explained to me why it's now no longer wanted
I must have completely missed it.
What was the reason?
> Just accept it, Adrian.
>
> Linus
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Mon, 7 Jul 2008, Adrian Bunk wrote:
>
> When did you tell me that maintainers should not or cannot be Cc'ed on
> regression reports?
That is not what I'm complaining about.
I'm complaining about the fact that you *always* argue against closing
bugreports.
You have argued against it for over a YEAR now. And every single time I
tell you that you are wrong, and exactly *why* you are wrong.
If a reporter doesn't respond to say "it's still open", it needs to be
closed. It doesn't matter one whit whether there has been developer action
on it or not. We cannot keep old reports open - it's a total waste for
developers to even _look_ at anything that is more than roughly a month
old and hasn't been verified to be still be an issue.
Linus
On Monday, 7 of July 2008, Rene Herman wrote:
> On 06-07-08 23:56, Rafael J. Wysocki wrote:
>
> > BTW, the automated emails I'm sending are to let the reporters know
> > that I'm interested in the current status of the bug. They are free
> > not to reply to them, but in that case I assume they don't really
> > care whether or not I'm tracking the bugs they reported.
>
> I did/do wonder by the way when I get them if I should be replying if
> the status is unchanged from my viewpoint...
>
> I believe your automated emails say something like "please verify if
> this problem is still relevant" but don't spell out what do after you
> verified that it is. It's sort of natural to take that as "I need to
> reply telling people it's fixed if it is but can remain silent if
> nothing changed".
The exact wording is
"The following bug entry is on the current list of known regressions
from 2.6.25. ?Please verify if it still should be listed."
> Being more explicit about liking a reporter to report "yes, nothing
> changed" would probably be good if that IS what's wanted.
Well, I can change it to
"Please verify if it still should be listed and let me know."
if that's better.
Thanks,
Rafael
On 07-07-08 00:57, Rafael J. Wysocki wrote:
>> Being more explicit about liking a reporter to report "yes, nothing
>> changed" would probably be good if that IS what's wanted.
>
> Well, I can change it to
>
> "Please verify if it still should be listed and let me know."
>
> if that's better.
Or even "please verify that it should still be listed, and let me know
either way". Simple "yes" replies feel a little silly, to non-frequent
posters at least, without that kind of explicit encouragement so it
might make for a few more replies.
Rene.
On Sun, Jul 06, 2008 at 03:27:30PM -0700, Linus Torvalds wrote:
>
>
> On Mon, 7 Jul 2008, Adrian Bunk wrote:
> >
> > When did you tell me that maintainers should not or cannot be Cc'ed on
> > regression reports?
>
> That is not what I'm complaining about.
That is what I wrote in the part of my email you made this comment on.
> I'm complaining about the fact that you *always* argue against closing
> bugreports.
I'm not always against closing bugs, and e.g. during the last years I've
closed at about 500 bugs in the kernel Bugzilla due to submitters having
vanished.
> You have argued against it for over a YEAR now. And every single time I
> tell you that you are wrong, and exactly *why* you are wrong.
>
> If a reporter doesn't respond to say "it's still open", it needs to be
> closed. It doesn't matter one whit whether there has been developer action
> on it or not. We cannot keep old reports open - it's a total waste for
> developers to even _look_ at anything that is more than roughly a month
> old and hasn't been verified to be still be an issue.
We only differ on whether a human should ask this question once before
closing a bug or whether regular automated requests are enough.
E.g. although Andrew has't responded to Rafaels emails for nearly a
month whether the slab corruption he reported is still present I
wouldn't take this as a definitive indication that he won't answer when
someone has a question. I'd bet Andrew will answer if a human asks him
about the status of this regression.
A developer asking manually "Is this still present?" does cost nearly no
time and gives the submitter a much better feeling than only automated
emails and then a bug close.
> Linus
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Sunday 06 July 2008, you wrote:
> The following bug entry is on the current list of known regressions
> from 2.6.25. Please verify if it still should be listed.
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10843
> Subject : Display artifacts on XOrg logout with PAT kernel and VESA
> framebuffer
Yes.
On Monday, 7 of July 2008, Rene Herman wrote:
> On 07-07-08 00:57, Rafael J. Wysocki wrote:
>
> >> Being more explicit about liking a reporter to report "yes, nothing
> >> changed" would probably be good if that IS what's wanted.
> >
> > Well, I can change it to
> >
> > "Please verify if it still should be listed and let me know."
> >
> > if that's better.
>
> Or even "please verify that it should still be listed, and let me know
> either way".
Okay, I will do this.
Thanks,
Rafael
Hi,
Adrian Bunk <[email protected]> writes:
> On Sun, Jul 06, 2008 at 03:27:30PM -0700, Linus Torvalds wrote:
>>
>>
>> On Mon, 7 Jul 2008, Adrian Bunk wrote:
>> >
>> > When did you tell me that maintainers should not or cannot be Cc'ed on
>> > regression reports?
>>
>> That is not what I'm complaining about.
>
> That is what I wrote in the part of my email you made this comment on.
>
>> I'm complaining about the fact that you *always* argue against closing
>> bugreports.
>
> I'm not always against closing bugs, and e.g. during the last years I've
> closed at about 500 bugs in the kernel Bugzilla due to submitters having
> vanished.
>
>> You have argued against it for over a YEAR now. And every single time I
>> tell you that you are wrong, and exactly *why* you are wrong.
>>
>> If a reporter doesn't respond to say "it's still open", it needs to be
>> closed. It doesn't matter one whit whether there has been developer action
>> on it or not. We cannot keep old reports open - it's a total waste for
>> developers to even _look_ at anything that is more than roughly a month
>> old and hasn't been verified to be still be an issue.
>
> We only differ on whether a human should ask this question once before
> closing a bug or whether regular automated requests are enough.
I prefer being bugged regularly as a reporter. At the moment I have a
bug at a machine I do not use every day and if I get this email, it
reminds me to test the latest kernel on that machine (or try to
reproduce the bug if it happens in situations not common in my usual
workflow). Then I report back.
If these remainders weren't, it would be possible that I forget about a
bug and come back to it when it's a real pain to hunt it down by
change-history or when a possible cause for the bug has left the
developers mind a long time ago.
Hannes
On Sun, 2008-07-06 at 13:39 +0200, Rafael J. Wysocki wrote:
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10714
> Subject : powerpc: Badness seen on 2.6.26-rc2 with lockdep
> enabled
> Submitter : Balbir Singh <[email protected]>
> Date : 2008-05-14 12:57 (54 days old)
> References :
> http://marc.info/?l=linux-kernel&m=121076917429133&w=4
> Handled-By : Benjamin Herrenschmidt <[email protected]>
Still can't reproduce that one, waiting to get access to Balbir's
machine.
Cheers,
Ben.
Hi Rafael etc.
On Mon, 2008-07-07 at 00:57 +0200, Rafael J. Wysocki wrote:
> On Monday, 7 of July 2008, Rene Herman wrote:
> > On 06-07-08 23:56, Rafael J. Wysocki wrote:
> >
> > > BTW, the automated emails I'm sending are to let the reporters know
> > > that I'm interested in the current status of the bug. They are free
> > > not to reply to them, but in that case I assume they don't really
> > > care whether or not I'm tracking the bugs they reported.
> >
> > I did/do wonder by the way when I get them if I should be replying if
> > the status is unchanged from my viewpoint...
> >
> > I believe your automated emails say something like "please verify if
> > this problem is still relevant" but don't spell out what do after you
> > verified that it is. It's sort of natural to take that as "I need to
> > reply telling people it's fixed if it is but can remain silent if
> > nothing changed".
>
> The exact wording is
>
> "The following bug entry is on the current list of known regressions
> from 2.6.25. Please verify if it still should be listed."
>
> > Being more explicit about liking a reporter to report "yes, nothing
> > changed" would probably be good if that IS what's wanted.
>
> Well, I can change it to
>
> "Please verify if it still should be listed and let me know."
>
> if that's better.
>
I would suggest that you should assume it's still relevant until the
bugzilla entry gets closed. The person fixing the bug should be
responsible for modifying the report to say that a patch is available
and then has been merged (or for saying it's an invalid report etc).
This way, you're making the whole process less burdensome rather than
so.
Regards,
Nigel
* Linus Torvalds <[email protected]> wrote:
> > This still happens with 2.6.26-rc9. Using CONFIG_NUMA=y boots OK.
>
> Ok, then it wasn't the nr_zones thing.
>
> Since it seems to be repeatable for you, can you bisect it?
one guess would be:
| commit e8ee6f0ae5cd860e8e6c02807edfa3c1fa01bcb5
| Author: Yinghai Lu <[email protected]>
| Date: Sun Apr 13 01:41:58 2008 -0700
|
| x86: work around io allocation overlap of HT links
but ... since CONFIG_NUMA makes it work, i'm not sure about that.
Randy, could you post the full CONFIG_NUMA bootlog as well, does it show
any difference in resource allocations?
Ingo
* Randy Dunlap <[email protected]> wrote:
> This still happens with 2.6.26-rc9. Using CONFIG_NUMA=y boots OK.
one thing i dont see you having followed up on is whether tip/master
works fine:
http://lkml.org/lkml/2008/6/11/355
(or, whether linux-next works fine with the same !NUMA config.)
i.e. whether this is a genuine new problem or something we already
fixed. (just didnt realize the upstream relevance of)
( if tip/master works fine then it would be very useful to do an
'inverse bisection' for the fix. )
Ingo
On Sun, Jul 6, 2008 at 11:32 PM, Ingo Molnar <[email protected]> wrote:
>
> * Linus Torvalds <[email protected]> wrote:
>
>> > This still happens with 2.6.26-rc9. Using CONFIG_NUMA=y boots OK.
>>
>> Ok, then it wasn't the nr_zones thing.
>>
>> Since it seems to be repeatable for you, can you bisect it?
>
> one guess would be:
>
> | commit e8ee6f0ae5cd860e8e6c02807edfa3c1fa01bcb5
> | Author: Yinghai Lu <[email protected]>
> | Date: Sun Apr 13 01:41:58 2008 -0700
> |
> | x86: work around io allocation overlap of HT links
>
> but ... since CONFIG_NUMA makes it work, i'm not sure about that.
>
> Randy, could you post the full CONFIG_NUMA bootlog as well, does it show
> any difference in resource allocations?
>
l looked resource allocations in that bootlog.
all my AMD test servers work well with Randy's config (!NUMA)
( Linus tree or tip tree)
YH
On Sun, Jul 6, 2008 at 11:42 PM, Ingo Molnar <[email protected]> wrote:
>
> * Randy Dunlap <[email protected]> wrote:
>
>> This still happens with 2.6.26-rc9. Using CONFIG_NUMA=y boots OK.
>
> one thing i dont see you having followed up on is whether tip/master
> works fine:
>
> http://lkml.org/lkml/2008/6/11/355
in the response to me, he said tip/master has the same problem
YH
* Yinghai Lu <[email protected]> wrote:
> On Sun, Jul 6, 2008 at 11:42 PM, Ingo Molnar <[email protected]> wrote:
> >
> > * Randy Dunlap <[email protected]> wrote:
> >
> >> This still happens with 2.6.26-rc9. Using CONFIG_NUMA=y boots OK.
> >
> > one thing i dont see you having followed up on is whether tip/master
> > works fine:
> >
> > http://lkml.org/lkml/2008/6/11/355
>
> in the response to me, he said tip/master has the same problem
ok, so an unfixed problem.
Ingo
On Mon, Jul 07, 2008 at 01:55:15AM +0200, Johannes Weiner wrote:
> Hi,
>
> Adrian Bunk <[email protected]> writes:
>
> > On Sun, Jul 06, 2008 at 03:27:30PM -0700, Linus Torvalds wrote:
> >>
> >>
> >> On Mon, 7 Jul 2008, Adrian Bunk wrote:
> >> >
> >> > When did you tell me that maintainers should not or cannot be Cc'ed on
> >> > regression reports?
> >>
> >> That is not what I'm complaining about.
> >
> > That is what I wrote in the part of my email you made this comment on.
> >
> >> I'm complaining about the fact that you *always* argue against closing
> >> bugreports.
> >
> > I'm not always against closing bugs, and e.g. during the last years I've
> > closed at about 500 bugs in the kernel Bugzilla due to submitters having
> > vanished.
> >
> >> You have argued against it for over a YEAR now. And every single time I
> >> tell you that you are wrong, and exactly *why* you are wrong.
> >>
> >> If a reporter doesn't respond to say "it's still open", it needs to be
> >> closed. It doesn't matter one whit whether there has been developer action
> >> on it or not. We cannot keep old reports open - it's a total waste for
> >> developers to even _look_ at anything that is more than roughly a month
> >> old and hasn't been verified to be still be an issue.
> >
> > We only differ on whether a human should ask this question once before
> > closing a bug or whether regular automated requests are enough.
>
> I prefer being bugged regularly as a reporter. At the moment I have a
> bug at a machine I do not use every day and if I get this email, it
> reminds me to test the latest kernel on that machine (or try to
> reproduce the bug if it happens in situations not common in my usual
> workflow). Then I report back.
It often depends on the kind of bug.
E.g. if you reported "my main computer crashes twice a day" you would be
more interested to see some developer actually working on it before
reproducing it weekly.
> If these remainders weren't, it would be possible that I forget about a
> bug and come back to it when it's a real pain to hunt it down by
> change-history or when a possible cause for the bug has left the
> developers mind a long time ago.
You get me wrong.
I'm not saying the automated reminders should vanish.
But before closing a bug as "reported does not respond" IMHO a manual
request should be done first.
Otherwise we get people into the "I reported a bug, got only automated
emails, and the only action by the developers was to close the bug once
I got too annoyed to answer weekly that it's still present." situation.
> Hannes
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On (06/07/08 13:45), Rafael J. Wysocki didst pronounce:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.25. Please verify if it still should be listed.
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11025
> Subject : [problem] raid performance loss with 2.6.26-rc8 on 32-bit x86 (bisected)
> Submitter : Dan Williams <[email protected]>
> Date : 2008-07-01 1:57 (6 days old)
> References : http://marc.info/?l=linux-kernel&m=121487749429883&w=4
> Handled-By : Mel Gorman <[email protected]>
> Andy Whitcroft <[email protected]>
>
Fixed by commit 494de90098784b8e2797598cefdd34188884ec2e and should be
closed.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
Hi!
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10919
> > Subject : [regression] display dimming is slow and laggy - Acer Travelmate 661lci
> > Submitter : Maximilian Engelhardt <[email protected]>
> > Date : 2008-06-14 22:31 (23 days old)
> > References : http://marc.info/?l=linux-kernel&m=121348428828320&w=4
>
> I wonder if this one could be related. The 'nr_zones' overwriting bug
> would result in kswapd not reclaiming any memory asynchronously, so the
> kernel would basically be constantly under a low-memory situation, and
> processes would be forced to do synchronous reclaim.
>
> That, in turn, could easily explain laggy operation, especially if it is
> something bigger that needs to allocate new memory (not that I know if X
> dimming needs to, but I could imagine that it does some double buffering
> or whatever).
Hmm, but that would mean whole system is slow, right?
I'd bet this is ACPI EC problem...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Monday 07 July 2008, Pavel Machek wrote:
> Hi!
>
> > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10919
> > > Subject : [regression] display dimming is slow and laggy - Acer
> > > Travelmate 661lci Submitter : Maximilian Engelhardt
> > > <[email protected]>
> > > Date : 2008-06-14 22:31 (23 days old)
> > > References : http://marc.info/?l=linux-kernel&m=121348428828320&w=4
> >
> > I wonder if this one could be related. The 'nr_zones' overwriting bug
> > would result in kswapd not reclaiming any memory asynchronously, so the
> > kernel would basically be constantly under a low-memory situation, and
> > processes would be forced to do synchronous reclaim.
> >
> > That, in turn, could easily explain laggy operation, especially if it is
> > something bigger that needs to allocate new memory (not that I know if X
> > dimming needs to, but I could imagine that it does some double buffering
> > or whatever).
>
> Hmm, but that would mean whole system is slow, right?
>
> I'd bet this is ACPI EC problem...
I didn't notice anything that my system is slow. Also I think this patch got
included in 2.6.26-rc9 but I still have this problem with it.
Maxi
On Mon, 7 Jul 2008 08:32:18 +0200 Ingo Molnar wrote:
>
> * Linus Torvalds <[email protected]> wrote:
>
> > > This still happens with 2.6.26-rc9. Using CONFIG_NUMA=y boots OK.
> >
> > Ok, then it wasn't the nr_zones thing.
> >
> > Since it seems to be repeatable for you, can you bisect it?
>
> one guess would be:
>
> | commit e8ee6f0ae5cd860e8e6c02807edfa3c1fa01bcb5
> | Author: Yinghai Lu <[email protected]>
> | Date: Sun Apr 13 01:41:58 2008 -0700
> |
> | x86: work around io allocation overlap of HT links
>
> but ... since CONFIG_NUMA makes it work, i'm not sure about that.
>
> Randy, could you post the full CONFIG_NUMA bootlog as well, does it show
> any difference in resource allocations?
Good and bad boot logs are attached. There are several differences, but I don't
see any that are significant.
I've started bisecting with:
$ git bisect start
$ git bisect bad v2.6.26-rc1
$ git bisect good v2.6.25
That's only about 1.29M lines of changes.
---
~Randy
Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA
http://linuxplumbersconf.org/
On Monday, 7 of July 2008, Mel Gorman wrote:
> On (06/07/08 13:45), Rafael J. Wysocki didst pronounce:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.25. Please verify if it still should be listed.
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11025
> > Subject : [problem] raid performance loss with 2.6.26-rc8 on 32-bit x86 (bisected)
> > Submitter : Dan Williams <[email protected]>
> > Date : 2008-07-01 1:57 (6 days old)
> > References : http://marc.info/?l=linux-kernel&m=121487749429883&w=4
> > Handled-By : Mel Gorman <[email protected]>
> > Andy Whitcroft <[email protected]>
> >
>
> Fixed by commit 494de90098784b8e2797598cefdd34188884ec2e and should be
> closed.
Already closed.
Thanks,
Rafael
On Mon, 7 Jul 2008 11:39:17 -0700 Randy Dunlap wrote:
> On Mon, 7 Jul 2008 08:32:18 +0200 Ingo Molnar wrote:
>
> >
> > * Linus Torvalds <[email protected]> wrote:
> >
> > > > This still happens with 2.6.26-rc9. Using CONFIG_NUMA=y boots OK.
> > >
> > > Ok, then it wasn't the nr_zones thing.
> > >
> > > Since it seems to be repeatable for you, can you bisect it?
> >
> > one guess would be:
> >
> > | commit e8ee6f0ae5cd860e8e6c02807edfa3c1fa01bcb5
> > | Author: Yinghai Lu <[email protected]>
> > | Date: Sun Apr 13 01:41:58 2008 -0700
> > |
> > | x86: work around io allocation overlap of HT links
> >
> > but ... since CONFIG_NUMA makes it work, i'm not sure about that.
> >
> > Randy, could you post the full CONFIG_NUMA bootlog as well, does it show
> > any difference in resource allocations?
>
> Good and bad boot logs are attached. There are several differences, but I don't
> see any that are significant.
>
> I've started bisecting with:
>
> $ git bisect start
> $ git bisect bad v2.6.26-rc1
> $ git bisect good v2.6.25
>
> That's only about 1.29M lines of changes.
git bisect and normal rebooting did not find a problem.
I'll repeat this using kexec to boot the new kernel and see if that
locates any issues... since I normally use kexec to load/test new kernels
and that was how the failure occurred (occurs).
---
~Randy
Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA
http://linuxplumbersconf.org/
On Mon, Jul 7, 2008 at 3:40 PM, Randy Dunlap <[email protected]> wrote:
> On Mon, 7 Jul 2008 11:39:17 -0700 Randy Dunlap wrote:
>
>> On Mon, 7 Jul 2008 08:32:18 +0200 Ingo Molnar wrote:
>>
>> >
>> > * Linus Torvalds <[email protected]> wrote:
>> >
>> > > > This still happens with 2.6.26-rc9. Using CONFIG_NUMA=y boots OK.
>> > >
>> > > Ok, then it wasn't the nr_zones thing.
>> > >
>> > > Since it seems to be repeatable for you, can you bisect it?
>> >
>> > one guess would be:
>> >
>> > | commit e8ee6f0ae5cd860e8e6c02807edfa3c1fa01bcb5
>> > | Author: Yinghai Lu <[email protected]>
>> > | Date: Sun Apr 13 01:41:58 2008 -0700
>> > |
>> > | x86: work around io allocation overlap of HT links
>> >
>> > but ... since CONFIG_NUMA makes it work, i'm not sure about that.
>> >
>> > Randy, could you post the full CONFIG_NUMA bootlog as well, does it show
>> > any difference in resource allocations?
>>
>> Good and bad boot logs are attached. There are several differences, but I don't
>> see any that are significant.
>>
>> I've started bisecting with:
>>
>> $ git bisect start
>> $ git bisect bad v2.6.26-rc1
>> $ git bisect good v2.6.25
>>
>> That's only about 1.29M lines of changes.
>
> git bisect and normal rebooting did not find a problem.
>
> I'll repeat this using kexec to boot the new kernel and see if that
> locates any issues... since I normally use kexec to load/test new kernels
> and that was how the failure occurred (occurs).
>
same NON-NUMA kernel kexec NON-NUMA kernel?
or other kernel kexex it?
YH
* Randy Dunlap <[email protected]> wrote:
> > $ git bisect start
> > $ git bisect bad v2.6.26-rc1
> > $ git bisect good v2.6.25
> >
> > That's only about 1.29M lines of changes.
>
> git bisect and normal rebooting did not find a problem.
>
> I'll repeat this using kexec to boot the new kernel and see if that
> locates any issues... since I normally use kexec to load/test new
> kernels and that was how the failure occurred (occurs).
ah, so the hang only occurs if you kexec a post-v2.6.25 kernel? (from
any other kernel, or from a post-v2.6.25 kernel?)
Ingo
On Mon, 7 Jul 2008 17:24:16 -0700 Yinghai Lu wrote:
> On Mon, Jul 7, 2008 at 3:40 PM, Randy Dunlap <[email protected]> wrote:
> > On Mon, 7 Jul 2008 11:39:17 -0700 Randy Dunlap wrote:
> >
> >> On Mon, 7 Jul 2008 08:32:18 +0200 Ingo Molnar wrote:
> >>
> >> >
> >> > * Linus Torvalds <[email protected]> wrote:
> >> >
> >> > > > This still happens with 2.6.26-rc9. Using CONFIG_NUMA=y boots OK.
> >> > >
> >> > > Ok, then it wasn't the nr_zones thing.
> >> > >
> >> > > Since it seems to be repeatable for you, can you bisect it?
> >> >
> >> > one guess would be:
> >> >
> >> > | commit e8ee6f0ae5cd860e8e6c02807edfa3c1fa01bcb5
> >> > | Author: Yinghai Lu <[email protected]>
> >> > | Date: Sun Apr 13 01:41:58 2008 -0700
> >> > |
> >> > | x86: work around io allocation overlap of HT links
> >> >
> >> > but ... since CONFIG_NUMA makes it work, i'm not sure about that.
> >> >
> >> > Randy, could you post the full CONFIG_NUMA bootlog as well, does it show
> >> > any difference in resource allocations?
> >>
> >> Good and bad boot logs are attached. There are several differences, but I don't
> >> see any that are significant.
> >>
> >> I've started bisecting with:
> >>
> >> $ git bisect start
> >> $ git bisect bad v2.6.26-rc1
> >> $ git bisect good v2.6.25
> >>
> >> That's only about 1.29M lines of changes.
> >
> > git bisect and normal rebooting did not find a problem.
> >
> > I'll repeat this using kexec to boot the new kernel and see if that
> > locates any issues... since I normally use kexec to load/test new kernels
> > and that was how the failure occurred (occurs).
> >
>
> same NON-NUMA kernel kexec NON-NUMA kernel?
>
> or other kernel kexex it?
Ah. Good question. I hadn't noticed that.
NUMA kernel kexec-ing a non-NUMA kernel now fails, but it worked in 2.6.25.
---
~Randy
Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA
http://linuxplumbersconf.org/
On Mon, Jul 7, 2008 at 10:28 PM, Randy Dunlap <[email protected]> wrote:
> On Mon, 7 Jul 2008 17:24:16 -0700 Yinghai Lu wrote:
>
>> On Mon, Jul 7, 2008 at 3:40 PM, Randy Dunlap <[email protected]> wrote:
>> > On Mon, 7 Jul 2008 11:39:17 -0700 Randy Dunlap wrote:
>> >
>> >> On Mon, 7 Jul 2008 08:32:18 +0200 Ingo Molnar wrote:
>> >>
>> >> >
>> >> > * Linus Torvalds <[email protected]> wrote:
>> >> >
>> >> > > > This still happens with 2.6.26-rc9. Using CONFIG_NUMA=y boots OK.
>> >> > >
>> >> > > Ok, then it wasn't the nr_zones thing.
>> >> > >
>> >> > > Since it seems to be repeatable for you, can you bisect it?
>> >> >
>> >> > one guess would be:
>> >> >
>> >> > | commit e8ee6f0ae5cd860e8e6c02807edfa3c1fa01bcb5
>> >> > | Author: Yinghai Lu <[email protected]>
>> >> > | Date: Sun Apr 13 01:41:58 2008 -0700
>> >> > |
>> >> > | x86: work around io allocation overlap of HT links
>> >> >
>> >> > but ... since CONFIG_NUMA makes it work, i'm not sure about that.
>> >> >
>> >> > Randy, could you post the full CONFIG_NUMA bootlog as well, does it show
>> >> > any difference in resource allocations?
>> >>
>> >> Good and bad boot logs are attached. There are several differences, but I don't
>> >> see any that are significant.
>> >>
>> >> I've started bisecting with:
>> >>
>> >> $ git bisect start
>> >> $ git bisect bad v2.6.26-rc1
>> >> $ git bisect good v2.6.25
>> >>
>> >> That's only about 1.29M lines of changes.
>> >
>> > git bisect and normal rebooting did not find a problem.
>> >
>> > I'll repeat this using kexec to boot the new kernel and see if that
>> > locates any issues... since I normally use kexec to load/test new kernels
>> > and that was how the failure occurred (occurs).
>> >
>>
>> same NON-NUMA kernel kexec NON-NUMA kernel?
>>
>> or other kernel kexex it?
>
> Ah. Good question. I hadn't noticed that.
> NUMA kernel kexec-ing a non-NUMA kernel now fails, but it worked in 2.6.25.
>
can you resend out that two config?
YH
On Tue, 8 Jul 2008 07:16:29 +0200 Ingo Molnar wrote:
>
> * Randy Dunlap <[email protected]> wrote:
>
> > > $ git bisect start
> > > $ git bisect bad v2.6.26-rc1
> > > $ git bisect good v2.6.25
> > >
> > > That's only about 1.29M lines of changes.
> >
> > git bisect and normal rebooting did not find a problem.
> >
> > I'll repeat this using kexec to boot the new kernel and see if that
> > locates any issues... since I normally use kexec to load/test new
> > kernels and that was how the failure occurred (occurs).
>
> ah, so the hang only occurs if you kexec a post-v2.6.25 kernel? (from
> any other kernel, or from a post-v2.6.25 kernel?)
Host (first) kernel is 2.6.25 with NUMA=y.
kexec of 2.6.25 with NUMA=n works, kexec of 2.6.26-rc[123456789] with
NUMA=n fails/hangs. kexec of 2.6.26-rc* with NUMA=y works.
kernel configs will be in next email reply to YH.
---
~Randy
Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA
http://linuxplumbersconf.org/
On Tue, 8 Jul 2008 00:07:03 -0700 Yinghai Lu wrote:
> On Mon, Jul 7, 2008 at 10:28 PM, Randy Dunlap <[email protected]> wrote:
> > On Mon, 7 Jul 2008 17:24:16 -0700 Yinghai Lu wrote:
> >
> >> On Mon, Jul 7, 2008 at 3:40 PM, Randy Dunlap <[email protected]> wrote:
> >> > On Mon, 7 Jul 2008 11:39:17 -0700 Randy Dunlap wrote:
> >> >
> >> >> On Mon, 7 Jul 2008 08:32:18 +0200 Ingo Molnar wrote:
> >> >>
> >> >> >
> >> >> > * Linus Torvalds <[email protected]> wrote:
> >> >> >
> >> >> > > > This still happens with 2.6.26-rc9. Using CONFIG_NUMA=y boots OK.
> >> >> > >
> >> >> > > Ok, then it wasn't the nr_zones thing.
> >> >> > >
> >> >> > > Since it seems to be repeatable for you, can you bisect it?
> >> >> >
> >> >> > one guess would be:
> >> >> >
> >> >> > | commit e8ee6f0ae5cd860e8e6c02807edfa3c1fa01bcb5
> >> >> > | Author: Yinghai Lu <[email protected]>
> >> >> > | Date: Sun Apr 13 01:41:58 2008 -0700
> >> >> > |
> >> >> > | x86: work around io allocation overlap of HT links
> >> >> >
> >> >> > but ... since CONFIG_NUMA makes it work, i'm not sure about that.
> >> >> >
> >> >> > Randy, could you post the full CONFIG_NUMA bootlog as well, does it show
> >> >> > any difference in resource allocations?
> >> >>
> >> >> Good and bad boot logs are attached. There are several differences, but I don't
> >> >> see any that are significant.
> >> >>
> >> >> I've started bisecting with:
> >> >>
> >> >> $ git bisect start
> >> >> $ git bisect bad v2.6.26-rc1
> >> >> $ git bisect good v2.6.25
> >> >>
> >> >> That's only about 1.29M lines of changes.
> >> >
> >> > git bisect and normal rebooting did not find a problem.
> >> >
> >> > I'll repeat this using kexec to boot the new kernel and see if that
> >> > locates any issues... since I normally use kexec to load/test new kernels
> >> > and that was how the failure occurred (occurs).
> >> >
> >>
> >> same NON-NUMA kernel kexec NON-NUMA kernel?
> >>
> >> or other kernel kexex it?
> >
> > Ah. Good question. I hadn't noticed that.
> > NUMA kernel kexec-ing a non-NUMA kernel now fails, but it worked in 2.6.25.
> >
>
> can you resend out that two config?
The host/first kernel that loads the second/failing kernel uses
config-2625-work. The second kernel that hangs during boot uses
kconfig.numa.bad . (both attached)
---
~Randy
Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA
http://linuxplumbersconf.org/
On Tue, Jul 8, 2008 at 8:44 AM, Randy Dunlap <[email protected]> wrote:
> On Tue, 8 Jul 2008 00:07:03 -0700 Yinghai Lu wrote:
>
>> On Mon, Jul 7, 2008 at 10:28 PM, Randy Dunlap <[email protected]> wrote:
>> > On Mon, 7 Jul 2008 17:24:16 -0700 Yinghai Lu wrote:
>> >
>> >> On Mon, Jul 7, 2008 at 3:40 PM, Randy Dunlap <[email protected]> wrote:
>> >> > On Mon, 7 Jul 2008 11:39:17 -0700 Randy Dunlap wrote:
>> >> >
>> >> >> On Mon, 7 Jul 2008 08:32:18 +0200 Ingo Molnar wrote:
>> >> >>
>> >> >> >
>> >> >> > * Linus Torvalds <[email protected]> wrote:
>> >> >> >
>> >> >> > > > This still happens with 2.6.26-rc9. Using CONFIG_NUMA=y boots OK.
>> >> >> > >
>> >> >> > > Ok, then it wasn't the nr_zones thing.
>> >> >> > >
>> >> >> > > Since it seems to be repeatable for you, can you bisect it?
>> >> >> >
>> >> >> > one guess would be:
>> >> >> >
>> >> >> > | commit e8ee6f0ae5cd860e8e6c02807edfa3c1fa01bcb5
>> >> >> > | Author: Yinghai Lu <[email protected]>
>> >> >> > | Date: Sun Apr 13 01:41:58 2008 -0700
>> >> >> > |
>> >> >> > | x86: work around io allocation overlap of HT links
>> >> >> >
>> >> >> > but ... since CONFIG_NUMA makes it work, i'm not sure about that.
>> >> >> >
>> >> >> > Randy, could you post the full CONFIG_NUMA bootlog as well, does it show
>> >> >> > any difference in resource allocations?
>> >> >>
>> >> >> Good and bad boot logs are attached. There are several differences, but I don't
>> >> >> see any that are significant.
>> >> >>
>> >> >> I've started bisecting with:
>> >> >>
>> >> >> $ git bisect start
>> >> >> $ git bisect bad v2.6.26-rc1
>> >> >> $ git bisect good v2.6.25
>> >> >>
>> >> >> That's only about 1.29M lines of changes.
>> >> >
>> >> > git bisect and normal rebooting did not find a problem.
>> >> >
>> >> > I'll repeat this using kexec to boot the new kernel and see if that
>> >> > locates any issues... since I normally use kexec to load/test new kernels
>> >> > and that was how the failure occurred (occurs).
>> >> >
>> >>
>> >> same NON-NUMA kernel kexec NON-NUMA kernel?
>> >>
>> >> or other kernel kexex it?
>> >
>> > Ah. Good question. I hadn't noticed that.
>> > NUMA kernel kexec-ing a non-NUMA kernel now fails, but it worked in 2.6.25.
>> >
>>
>> can you resend out that two config?
>
> The host/first kernel that loads the second/failing kernel uses
> config-2625-work. The second kernel that hangs during boot uses
> kconfig.numa.bad . (both attached)
>
too bad, still can not dupicate here with your sequence.
YH
Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.25. Please verify if it still should be listed.
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11035
> Subject : System hangs on 2.6.26-rc8
> Submitter : Roman Mindalev <[email protected]>
> Date : 2008-07-02 14:25 (5 days old)
> References : http://marc.info/?l=linux-kernel&m=121500871414995&w=4
>
>
>
I have this problem with 2.6.25 too.
Unfortunately, I can't check 2.6.24. With config from 2.6.26-rc8 I got
error of compiling:
LD .tmp_vmlinux1
kernel/built-in.o: In function `timespec_add_ns':
/usr/src/kernels/linux-2.6.24/include/linux/time.h:179: undefined
reference to `__umoddi3'
kernel/built-in.o: In function `do_gettimeofday':
/usr/src/kernels/linux-2.6.24/kernel/time/timekeeping.c:131: undefined
reference to `__udivdi3'
/usr/src/kernels/linux-2.6.24/kernel/time/timekeeping.c:132: undefined
reference to `__umoddi3'
kernel/built-in.o: In function `timespec_add_ns':
/usr/src/kernels/linux-2.6.24/include/linux/time.h:174: undefined
reference to `__udivdi3'
/usr/src/kernels/linux-2.6.24/include/linux/time.h:179: undefined
reference to `__umoddi3'
/usr/src/kernels/linux-2.6.24/include/linux/time.h:174: undefined
reference to `__udivdi3'
/usr/src/kernels/linux-2.6.24/include/linux/time.h:179: undefined
reference to `__umoddi3'
/usr/src/kernels/linux-2.6.24/include/linux/time.h:174: undefined
reference to `__udivdi3'
/usr/src/kernels/linux-2.6.24/include/linux/time.h:179: undefined
reference to `__umoddi3'
make: *** [.tmp_vmlinux1] Error 1
I attached 3 configs, from 2.6.26-rc8 (where I in first time got hang of
system as result of SIGSEGV), from 2.6.25, and from 2.6.24
On Sun, Jul 06, 2008 at 01:45:52PM +0200, Rafael J. Wysocki wrote:
>
> The following bug entry is on the current list of known regressions
> from 2.6.25. Please verify if it still should be listed.
I am going to check it later. Last time I saw it was around 2.6.26-rc7/8.
Anyway the error message was not the same firstly reported there,
it could be another problem. More details will follow. Thank you.
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10786
> Subject : parisc: 64bit SMP does not boot on J5600
> Submitter : Domenico Andreoli <[email protected]>
> Date : 2008-05-22 16:14 (46 days old)
> References : http://marc.info/?l=linux-kernel&m=121147328028081&w=4
ciao,
Domenico
-----[ Domenico Andreoli, aka cavok
--[ http://www.dandreoli.com/gpgkey.asc
---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Em Thu, 10 Jul 2008 16:29:39 +0400
Roman Mindalev <[email protected]> escreveu:
| Rafael J. Wysocki wrote:
| > This message has been generated automatically as a part of a report
| > of recent regressions.
| >
| > The following bug entry is on the current list of known regressions
| > from 2.6.25. Please verify if it still should be listed.
| >
| >
| > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11035
| > Subject : System hangs on 2.6.26-rc8
| > Submitter : Roman Mindalev <[email protected]>
| > Date : 2008-07-02 14:25 (5 days old)
| > References : http://marc.info/?l=linux-kernel&m=121500871414995&w=4
| >
| >
| >
| I have this problem with 2.6.25 too.
| Unfortunately, I can't check 2.6.24. With config from 2.6.26-rc8 I got
| error of compiling:
|
| LD .tmp_vmlinux1
| kernel/built-in.o: In function `timespec_add_ns':
| /usr/src/kernels/linux-2.6.24/include/linux/time.h:179: undefined
| reference to `__umoddi3'
[...]
You're trying to compile with gcc 4.3, right? You can try the
attached fix or the following cherry-pick if you're compiling
from a git tree:
$ git cherry-pick 38332cb98772f5ea757e6486bed7ed0381cb5f98
But I can't tell whether the compiler and/or the fix will
change the behaivor of the bug you're reporting.
--
Luiz Fernando N. Capitulino
Luiz Fernando N. Capitulino wrote:
> Em Thu, 10 Jul 2008 16:29:39 +0400
> Roman Mindalev <[email protected]> escreveu:
>
> | Rafael J. Wysocki wrote:
> | > This message has been generated automatically as a part of a report
> | > of recent regressions.
> | >
> | > The following bug entry is on the current list of known regressions
> | > from 2.6.25. Please verify if it still should be listed.
> | >
> | >
> | > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11035
> | > Subject : System hangs on 2.6.26-rc8
> | > Submitter : Roman Mindalev <[email protected]>
> | > Date : 2008-07-02 14:25 (5 days old)
> | > References : http://marc.info/?l=linux-kernel&m=121500871414995&w=4
> | >
> | >
> | >
> | I have this problem with 2.6.25 too.
> | Unfortunately, I can't check 2.6.24. With config from 2.6.26-rc8 I got
> | error of compiling:
> |
> | LD .tmp_vmlinux1
> | kernel/built-in.o: In function `timespec_add_ns':
> | /usr/src/kernels/linux-2.6.24/include/linux/time.h:179: undefined
> | reference to `__umoddi3'
>
> [...]
>
> You're trying to compile with gcc 4.3, right?
Yes, GCC 4.3.1. With time.patch kernel compiled successfully. Thanks for
help!
Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.25. Please verify if it still should be listed.
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11035
> Subject : System hangs on 2.6.26-rc8
> Submitter : Roman Mindalev <[email protected]>
> Date : 2008-07-02 14:25 (5 days old)
> References : http://marc.info/?l=linux-kernel&m=121500871414995&w=4
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-testers" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Announce: It is long history, if you don't want to read it, go directly
to assumption ;)
Short description of problem: SIGSEGV on high I/O load (reading packages
database, kernel untaring) without any records in logs
Prehistory: 2.6.26-rc7 works, 2.6.26-rc8 buggy, configs very simular.
History: In last days I compiled some 2.6.25 kernels (took it, because
it is stable) with different configs (step-by-step disabling options,
not equals in -rc7 and -rc8) and got next results:
2.6.25 (preemtible, preempt rcu, 300 Hz, snd_sequencer, snd_seq_dummy,
snd_rtctimer, snd_seq_rtctimer_default, debug_preempt, rcu_tortune_test)
- bug
2.6.25 (preemtible, preempt rcu, 300 Hz, snd_sequencer, snd_seq_dummy,
debug_preempt, rcu_tortune_test) - bug
2.6.25 (preemtible, preempt rcu, 300 Hz, snd_sequencer, debug_preempt,
rcu_tortune_test) - bug
2.6.25 (preemtible, preempt rcu, 300 Hz, debug_preempt,
rcu_tortune_test) - bug
2.6.25 (preemtible, preempt rcu, 250 Hz, debug_preempt,
rcu_tortune_test) - bug
2.6.25 (preemtible, preempt rcu, 250 Hz, snd_rtctimer, debug_preempt,
rcu_tortune_test) - bug
2.6.25 (preemtible, preempt rcu, 100 Hz, debug_preempt,
rcu_tortune_test) - bug
2.6.25 (preemtible, 250 Hz, debug_preempt, rcu_tortune_test) - bug
2.6.25 (250 Hz, rcu_tortune_test) - bug
2.6.25 (250 Hz) - bug
And I understand - problem not (only?) in kernel, problem in GCC too (I
updated whole system in June).
2.6.24 - one kernel (I'm tested from it to latest rc), which (with
time.patch) works with GCC 4.3.1
2.6.25 and above (tested with 2.6.26-rc7, 2.6.26-rc8, 2.6.26-rc9) don't
works, if compiled with this compiler version.
Then I look on my (working) kernels - 2.6.26-rc6 was compiled with GCC
4.2.4, and 2.6.26-rc7 too...
In testing purposes I took some listed kernels and recompiled them with
other GCC version.
Common results in table:
GCC 4.3.1, kernel 2.6.24 - works
GCC 4.2.4, kernel 2.6.25 - works
GCC 4.3.1, kernel 2.6.25 - bug
GCC 4.2.4, kernel 2.6.26-rc7 - works
GCC 4.3.1, kernel 2.6.26-rc7 - bug
GCC 4.2.4, kernel 2.6.26-rc8 - works
GCC 4.3.1, kernel 2.6.26-rc8 - bug
Assumption: new features (or new bugs:)) in GCC 4.3 conflicts with some
commit(s), included in kernel between 2.6.24 and 2.6.25
Roman Mindalev wrote:
> Rafael J. Wysocki wrote:
>> This message has been generated automatically as a part of a report
>> of recent regressions.
>>
>> The following bug entry is on the current list of known regressions
>> from 2.6.25. Please verify if it still should be listed.
>>
>>
>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11035
>> Subject : System hangs on 2.6.26-rc8
>> Submitter : Roman Mindalev <[email protected]>
>> Date : 2008-07-02 14:25 (5 days old)
>> References : http://marc.info/?l=linux-kernel&m=121500871414995&w=4
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe kernel-testers" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
> Announce: It is long history, if you don't want to read it, go directly
> to assumption ;)
>
> Short description of problem: SIGSEGV on high I/O load (reading packages
> database, kernel untaring) without any records in logs
>
> Prehistory: 2.6.26-rc7 works, 2.6.26-rc8 buggy, configs very simular.
>
> History: In last days I compiled some 2.6.25 kernels (took it, because
> it is stable) with different configs (step-by-step disabling options,
> not equals in -rc7 and -rc8) and got next results:
>
> 2.6.25 (preemtible, preempt rcu, 300 Hz, snd_sequencer, snd_seq_dummy,
> snd_rtctimer, snd_seq_rtctimer_default, debug_preempt, rcu_tortune_test)
> - bug
> 2.6.25 (preemtible, preempt rcu, 300 Hz, snd_sequencer, snd_seq_dummy,
> debug_preempt, rcu_tortune_test) - bug
> 2.6.25 (preemtible, preempt rcu, 300 Hz, snd_sequencer, debug_preempt,
> rcu_tortune_test) - bug
> 2.6.25 (preemtible, preempt rcu, 300 Hz, debug_preempt,
> rcu_tortune_test) - bug
> 2.6.25 (preemtible, preempt rcu, 250 Hz, debug_preempt,
> rcu_tortune_test) - bug
> 2.6.25 (preemtible, preempt rcu, 250 Hz, snd_rtctimer, debug_preempt,
> rcu_tortune_test) - bug
> 2.6.25 (preemtible, preempt rcu, 100 Hz, debug_preempt,
> rcu_tortune_test) - bug
> 2.6.25 (preemtible, 250 Hz, debug_preempt, rcu_tortune_test) - bug
> 2.6.25 (250 Hz, rcu_tortune_test) - bug
> 2.6.25 (250 Hz) - bug
>
> And I understand - problem not (only?) in kernel, problem in GCC too (I
> updated whole system in June).
>
> 2.6.24 - one kernel (I'm tested from it to latest rc), which (with
> time.patch) works with GCC 4.3.1
> 2.6.25 and above (tested with 2.6.26-rc7, 2.6.26-rc8, 2.6.26-rc9) don't
> works, if compiled with this compiler version.
>
> Then I look on my (working) kernels - 2.6.26-rc6 was compiled with GCC
> 4.2.4, and 2.6.26-rc7 too...
>
> In testing purposes I took some listed kernels and recompiled them with
> other GCC version.
>
> Common results in table:
> GCC 4.3.1, kernel 2.6.24 - works
> GCC 4.2.4, kernel 2.6.25 - works
> GCC 4.3.1, kernel 2.6.25 - bug
> GCC 4.2.4, kernel 2.6.26-rc7 - works
> GCC 4.3.1, kernel 2.6.26-rc7 - bug
> GCC 4.2.4, kernel 2.6.26-rc8 - works
> GCC 4.3.1, kernel 2.6.26-rc8 - bug
>
> Assumption: new features (or new bugs:)) in GCC 4.3 conflicts with some
> commit(s), included in kernel between 2.6.24 and 2.6.25
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-testers" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
I done bisection.
Result below:
8f46924600e30b140445f5b84abe9b80d2fff5fb is first bad commit
commit 8f46924600e30b140445f5b84abe9b80d2fff5fb
Author: Ingo Molnar <[email protected]>
Date: Wed Jan 30 13:34:09 2008 +0100
x86: enable CONFIG_DEBUG_PAGEALLOC more widely
make CONFIG_DEBUG_PAGEALLOC universally available.
CONFIG_HIBERNATION and CONFIG_HUGETLBFS was disabling it, for no
particular reason.
If there are any unfixed bugs here we'll fix it, but do not disable
vital debugging facilities like that ..
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
:040000 040000 ea82c42d0972aabc1f34978dc9b9c73edbd7e508
446e8dd9bb2fcb1698d038b09800dc8aa8c335ab M arch
Commit body:
diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
index 2a859a7..347e33e 100644
--- a/arch/x86/Kconfig.debug
+++ b/arch/x86/Kconfig.debug
@@ -40,7 +40,7 @@ comment "Page alloc debug is incompatible with
Software Suspend on i386"
config DEBUG_PAGEALLOC
bool "Debug page memory allocations"
- depends on DEBUG_KERNEL && !HIBERNATION && !HUGETLBFS
+ depends on DEBUG_KERNEL
help
Unmap pages from the kernel linear mapping after free_pages().
This results in a large slowdown, but helps to find certain types
I applied it (reversed) to 2.6.25 source and compiled new kernel.
Hibernation enabled, hugetlbfs too. And difference between configs:
diff config-2.6.25-old config-2.6.25-new
4c4
< # Sat Jul 12 17:24:17 2008
---
> # Tue Jul 15 16:24:10 2008
1927d1926
< CONFIG_DEBUG_PAGEALLOC=y
I have no problems with this (new) config.
Seems conflict between new features in GCC 4.3.1 and pagealloc debug?
* Roman Mindalev <[email protected]> wrote:
> I done bisection.
> Result below:
>
> 8f46924600e30b140445f5b84abe9b80d2fff5fb is first bad commit
> commit 8f46924600e30b140445f5b84abe9b80d2fff5fb
> Author: Ingo Molnar <[email protected]>
> Date: Wed Jan 30 13:34:09 2008 +0100
>
> x86: enable CONFIG_DEBUG_PAGEALLOC more widely
>
> make CONFIG_DEBUG_PAGEALLOC universally available.
>
> CONFIG_HIBERNATION and CONFIG_HUGETLBFS was disabling it, for no
> particular reason.
as far as i can see you see a lockup under certain circumstances, right?
this debug option catches use-after-free and other types of invalid
memory accesses. When it catches a bug the kernel most likely crashes
and produces a backlog. Because you are in graphical mode that is not
visible.
This would possibly be debuggable if you set up netconsole logging to
another system on a local LAN - see
Documentation/networking/netconsole.txt.
Vegard - would it be possible to make DEBUG_PAGEALLOC faults single-shot
and non-fatal, just like kmemcheck does it? That way people would see a
nice kernel message instead of an immediate crash. That means we'd have
to find a reliable filter for DEBUG_PAGEALLOC-provoked pagefaults though
...
Ingo
Hi.
On Fri, 2008-07-18 at 09:11 +0200, Ingo Molnar wrote:
> * Roman Mindalev <[email protected]> wrote:
>
> > I done bisection.
> > Result below:
> >
> > 8f46924600e30b140445f5b84abe9b80d2fff5fb is first bad commit
> > commit 8f46924600e30b140445f5b84abe9b80d2fff5fb
> > Author: Ingo Molnar <[email protected]>
> > Date: Wed Jan 30 13:34:09 2008 +0100
> >
> > x86: enable CONFIG_DEBUG_PAGEALLOC more widely
> >
> > make CONFIG_DEBUG_PAGEALLOC universally available.
> >
> > CONFIG_HIBERNATION and CONFIG_HUGETLBFS was disabling it, for no
> > particular reason.
>
> as far as i can see you see a lockup under certain circumstances, right?
>
> this debug option catches use-after-free and other types of invalid
> memory accesses. When it catches a bug the kernel most likely crashes
> and produces a backlog. Because you are in graphical mode that is not
> visible.
>
> This would possibly be debuggable if you set up netconsole logging to
> another system on a local LAN - see
> Documentation/networking/netconsole.txt.
>
> Vegard - would it be possible to make DEBUG_PAGEALLOC faults single-shot
> and non-fatal, just like kmemcheck does it? That way people would see a
> nice kernel message instead of an immediate crash. That means we'd have
> to find a reliable filter for DEBUG_PAGEALLOC-provoked pagefaults though
> ...
Not that it matters now, but that original commit message was wrong -
CONFIG_HIBERNATION used to be incompatible with CONFIG_DEBUG_PAGEALLOC
because [u]swsusp didn't (until very recently) handle the fact that
DEBUG_SLAB unmaps empty pages on x86.
Regards,
Nigel
On Fri, Jul 18, 2008 at 9:11 AM, Ingo Molnar <[email protected]> wrote:
> Vegard - would it be possible to make DEBUG_PAGEALLOC faults single-shot
> and non-fatal, just like kmemcheck does it? That way people would see a
> nice kernel message instead of an immediate crash. That means we'd have
> to find a reliable filter for DEBUG_PAGEALLOC-provoked pagefaults though
> ...
Hm.. Yes, we could do it in a similar fashion using single-stepping.
It should take little effort; we already have most of the code to do
it; mmiotrace does the same thing too, after all.
These are some considerations:
1. If the page is kernel space but currently unmapped, does it point
to a valid page of RAM even though it is non-present?
2. Should we allow reading/writing of the underlying physical page (if
it exists), or should we prevent writes (i.e. allow the instruction to
proceed, but don't really write anything) and reads (i.e. allow the
instruction to read 0 or another magic number).
For the filter you mentioned, we could perhaps use one more bit in the
PTE. This is what we do for kmemcheck, and IIRC DEBUG_PAGEALLOC is
incompatible with kmemcheck anyway (I don't remember why exactly), so
we could reuse the same bit.
BTW, I didn't consider that argument (of continuing as far as
possible) before, but it's a good one; if we don't crash completely,
the user can still copy the log we have a better report of it. I guess
kerneloops.org is currently missing out a great deal of reports which
all shut down the machine immediately without a chance to go into the
log.
Vegard
--
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
-- E. W. Dijkstra, EWD1036
* Vegard Nossum <[email protected]> wrote:
> BTW, I didn't consider that argument (of continuing as far as
> possible) before, but it's a good one; if we don't crash completely,
> the user can still copy the log we have a better report of it. I guess
> kerneloops.org is currently missing out a great deal of reports which
> all shut down the machine immediately without a chance to go into the
> log.
yes. There are two techniques to improve the 'yield' of kerneloops.org:
1) make a better job of getting the logs off the box 2) make a better
job of not crashing the box when we can do better.
For example lockdep tries very hard to never crash the box. It is a
feature that warns about a chance of a lockup, not about a lockup itself
- so crashing the box at the point of the bug detection is
counter-productive.
The same applies to DEBUG_PAGEALLOC as well: technically nobody (but the
buggy code itself) is hurt by accessing already freed data. So we could
try and let it run.
(Btw., this might be a way to share a mechanism between kmemcheck and
DEBUG_PAGEALLOC, and make kmemcheck more useful to the general kernel as
a whole.)
Ingo
Hi,
On Thu, Jul 10, 2008 at 03:42:00PM +0200, Domenico Andreoli wrote:
> On Sun, Jul 06, 2008 at 01:45:52PM +0200, Rafael J. Wysocki wrote:
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.25. Please verify if it still should be listed.
>
> I am going to check it later. Last time I saw it was around 2.6.26-rc7/8.
I finally have the test result:
Linux version 2.6.26 (cavok@ska) (gcc version 4.1.3 20080623 (prerelease) (Debian 4.1.2-23)) #34 SMP Wed Jul 23 13:50:45 CEST 2008
FP[0] enabled: Rev 1 Model 16
The 64-bit Kernel has started...
console [ttyB0] enabled
Initialized PDC Console for debugging.
Determining PDC firmware type: System Map.
model 00005d10 00000491 00000000 00000002 77b406fc 100000f0 00000008 000000b2 000000b2
vers 00000300
CPUID vers 17 rev 10 (0x0000022a)
capabilities 0x3
model 9000/785/J5600
Total Memory: 3840 MB
LCD display at fffffff0f05d0008,fffffff0f05d0000 registered
SMP: bootstrap CPU ID is 0
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 969600
Kernel command line: root=/dev/sdb5 panic=60 HOME=/ console=ttyS0 TERM=vt102 palo_kernel=2/vmlinux.git
PID hash table entries: 4096 (order: 12, 32768 bytes)
Console: colour dummy device 160x64
Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
Memory: 3858944k/3932160k available (2967k kernel code, 73036k reserved, 1304k data, 240k init)
virtual kernel memory layout:
vmalloc : 0x0000000000008000 - 0x000000003f000000 (1007 MB)
memory : 0x0000000040000000 - 0x0000000130000000 (3840 MB)
.init : 0x00000000405c4000 - 0x0000000040600000 ( 240 kB)
.data : 0x00000000403e5d88 - 0x000000004052c000 (1304 kB)
.text : 0x0000000040100000 - 0x00000000403e5d88 (2967 kB)
Calibrating delay loop... <6>1101.00 BogoMIPS (lpj=5505024)
Security Framework initialized
Mount-cache hash table entries: 256
Brought up 1 CPUs
net_namespace: 1432 bytes
NET: Registered protocol family 16
EISA bus registered
Searching for devices...
Found devices:
1. Astro BC Runway Port at 0xfffffffffed00000 [10] { 12, 0x0, 0x582, 0x0000b }
2. Elroy PCI Bridge at 0xfffffffffed30000 [10/0] { 13, 0x0, 0x782, 0x0000a }
3. Elroy PCI Bridge at 0xfffffffffed32000 [10/1] { 13, 0x0, 0x782, 0x0000a }
4. Elroy PCI Bridge at 0xfffffffffed34000 [10/2] { 13, 0x0, 0x782, 0x0000a }
5. Elroy PCI Bridge at 0xfffffffffed38000 [10/4] { 13, 0x0, 0x782, 0x0000a }
6. Elroy PCI Bridge at 0xfffffffffed3c000 [10/6] { 13, 0x0, 0x782, 0x0000a }
7. Forte W+ 2w at 0xfffffffffffa0000 [32] { 0, 0x0, 0x5d1, 0x00004 }
8. Forte W+ 2w at 0xfffffffffffa2000 [34] { 0, 0x0, 0x5d1, 0x00004 }
9. Memory at 0xfffffffffed10200 [49] { 1, 0x0, 0x09e, 0x00009 }
Enabling regular chassis codes support v0.05
Releasing cpu 1 now, hpa=fffffffffffa2000
> Anyway the error message was not the same firstly reported there,
> it could be another problem. More details will follow. Thank you.
indeed
here is also the config file:
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.26
# Wed Jul 23 13:21:59 2008
#
CONFIG_PARISC=y
CONFIG_MMU=y
CONFIG_STACK_GROWSUP=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_TIME=y
CONFIG_TIME_LOW_RES=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_IRQ_PER_CPU=y
CONFIG_ARCH_SUPPORTS_AOUT=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=y
# CONFIG_IKCONFIG_PROC is not set
CONFIG_LOG_BUF_SHIFT=15
# CONFIG_CGROUPS is not set
# CONFIG_GROUP_SCHED is not set
CONFIG_SYSFS_DEPRECATED=y
CONFIG_SYSFS_DEPRECATED_V2=y
# CONFIG_RELAY is not set
CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
# CONFIG_IPC_NS is not set
# CONFIG_USER_NS is not set
# CONFIG_PID_NS is not set
# CONFIG_BLK_DEV_INITRD is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_SYSCTL_SYSCALL=y
CONFIG_SYSCTL_SYSCALL_CHECK=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_COMPAT_BRK=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_PROFILING is not set
# CONFIG_MARKERS is not set
CONFIG_HAVE_OPROFILE=y
# CONFIG_HAVE_KPROBES is not set
# CONFIG_HAVE_KRETPROBES is not set
# CONFIG_HAVE_DMA_ATTRS is not set
CONFIG_USE_GENERIC_SMP_HELPERS=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
# CONFIG_MODULE_FORCE_LOAD is not set
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_BLK_DEV_INTEGRITY is not set
CONFIG_BLOCK_COMPAT=y
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_CLASSIC_RCU=y
#
# Processor type and features
#
# CONFIG_PA7000 is not set
# CONFIG_PA7100LC is not set
# CONFIG_PA7200 is not set
# CONFIG_PA7300LC is not set
CONFIG_PA8X00=y
CONFIG_PA20=y
CONFIG_PREFETCH=y
CONFIG_64BIT=y
CONFIG_PARISC_PAGE_SIZE_4KB=y
# CONFIG_PARISC_PAGE_SIZE_16KB is not set
# CONFIG_PARISC_PAGE_SIZE_64KB is not set
CONFIG_SMP=y
CONFIG_HOTPLUG_CPU=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ARCH_DISCONTIGMEM_ENABLE=y
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_DISCONTIGMEM_DEFAULT=y
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_HZ_100=y
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=100
# CONFIG_SCHED_HRTICK is not set
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 is not set
# CONFIG_SPARSEMEM_VMEMMAP_ENABLE is not set
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_RESOURCES_64BIT=y
CONFIG_ZONE_DMA_FLAG=0
CONFIG_VIRT_TO_BUS=y
CONFIG_COMPAT=y
CONFIG_NR_CPUS=2
#
# Bus options (PCI, PCMCIA, EISA, GSC, ISA)
#
CONFIG_GSC=y
CONFIG_HPPB=y
CONFIG_IOMMU_CCIO=y
CONFIG_GSC_LASI=y
CONFIG_GSC_WAX=y
CONFIG_EISA=y
CONFIG_EISA_NAMES=y
CONFIG_ISA=y
CONFIG_PCI=y
# CONFIG_ARCH_SUPPORTS_MSI is not set
CONFIG_PCI_LEGACY=y
# CONFIG_PCI_DEBUG is not set
CONFIG_GSC_DINO=y
CONFIG_PCI_LBA=y
CONFIG_IOSAPIC=y
CONFIG_IOMMU_SBA=y
CONFIG_IOMMU_HELPER=y
# CONFIG_PCCARD is not set
# CONFIG_HOTPLUG_PCI is not set
#
# PA-RISC specific drivers
#
CONFIG_SUPERIO=y
CONFIG_CHASSIS_LCD_LED=y
CONFIG_PDC_CHASSIS=y
CONFIG_PDC_CHASSIS_WARN=y
CONFIG_PDC_STABLE=y
#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set
#
# Networking
#
CONFIG_NET=y
#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
# 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=m
# CONFIG_NET_IPGRE is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
CONFIG_INET_TUNNEL=m
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_BEET is not set
# CONFIG_INET_LRO is not set
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_IP_VS is not set
CONFIG_IPV6=m
# CONFIG_IPV6_PRIVACY is not set
# CONFIG_IPV6_ROUTER_PREF is not set
# CONFIG_IPV6_OPTIMISTIC_DAD is not set
# CONFIG_INET6_AH is not set
# CONFIG_INET6_ESP is not set
# CONFIG_INET6_IPCOMP is not set
# CONFIG_IPV6_MIP6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
CONFIG_INET6_TUNNEL=m
# CONFIG_INET6_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET6_XFRM_MODE_TUNNEL is not set
# CONFIG_INET6_XFRM_MODE_BEET is not set
# CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION is not set
CONFIG_IPV6_SIT=m
CONFIG_IPV6_NDISC_NODETYPE=y
CONFIG_IPV6_TUNNEL=m
# CONFIG_IPV6_MULTIPLE_TABLES is not set
# CONFIG_IPV6_MROUTE is not set
# CONFIG_NETLABEL is not set
# CONFIG_NETWORK_SECMARK is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_NETFILTER_ADVANCED=y
#
# Core Netfilter Configuration
#
CONFIG_NETFILTER_NETLINK=m
CONFIG_NETFILTER_NETLINK_QUEUE=m
CONFIG_NETFILTER_NETLINK_LOG=m
CONFIG_NF_CONNTRACK=m
# CONFIG_NF_CT_ACCT is not set
# CONFIG_NF_CONNTRACK_MARK is not set
# CONFIG_NF_CONNTRACK_EVENTS is not set
# CONFIG_NF_CT_PROTO_DCCP is not set
# CONFIG_NF_CT_PROTO_SCTP is not set
# CONFIG_NF_CT_PROTO_UDPLITE is not set
# CONFIG_NF_CONNTRACK_AMANDA is not set
CONFIG_NF_CONNTRACK_FTP=m
# CONFIG_NF_CONNTRACK_H323 is not set
CONFIG_NF_CONNTRACK_IRC=m
# CONFIG_NF_CONNTRACK_NETBIOS_NS is not set
# CONFIG_NF_CONNTRACK_PPTP is not set
# CONFIG_NF_CONNTRACK_SANE is not set
# CONFIG_NF_CONNTRACK_SIP is not set
# CONFIG_NF_CONNTRACK_TFTP is not set
CONFIG_NF_CT_NETLINK=m
CONFIG_NETFILTER_XTABLES=m
# CONFIG_NETFILTER_XT_TARGET_CLASSIFY is not set
# CONFIG_NETFILTER_XT_TARGET_CONNMARK is not set
# CONFIG_NETFILTER_XT_TARGET_DSCP is not set
# CONFIG_NETFILTER_XT_TARGET_MARK is not set
# CONFIG_NETFILTER_XT_TARGET_NFQUEUE is not set
# CONFIG_NETFILTER_XT_TARGET_NFLOG is not set
# CONFIG_NETFILTER_XT_TARGET_RATEEST is not set
# CONFIG_NETFILTER_XT_TARGET_TCPMSS is not set
# CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP is not set
# CONFIG_NETFILTER_XT_MATCH_COMMENT is not set
# CONFIG_NETFILTER_XT_MATCH_CONNBYTES is not set
# CONFIG_NETFILTER_XT_MATCH_CONNLIMIT is not set
# CONFIG_NETFILTER_XT_MATCH_CONNMARK is not set
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m
# CONFIG_NETFILTER_XT_MATCH_DCCP is not set
# CONFIG_NETFILTER_XT_MATCH_DSCP is not set
# CONFIG_NETFILTER_XT_MATCH_ESP is not set
# CONFIG_NETFILTER_XT_MATCH_HELPER is not set
# CONFIG_NETFILTER_XT_MATCH_IPRANGE is not set
# CONFIG_NETFILTER_XT_MATCH_LENGTH is not set
CONFIG_NETFILTER_XT_MATCH_LIMIT=m
# CONFIG_NETFILTER_XT_MATCH_MAC is not set
# CONFIG_NETFILTER_XT_MATCH_MARK is not set
# CONFIG_NETFILTER_XT_MATCH_OWNER is not set
# CONFIG_NETFILTER_XT_MATCH_MULTIPORT is not set
# CONFIG_NETFILTER_XT_MATCH_PKTTYPE is not set
# CONFIG_NETFILTER_XT_MATCH_QUOTA is not set
# CONFIG_NETFILTER_XT_MATCH_RATEEST is not set
# CONFIG_NETFILTER_XT_MATCH_REALM is not set
# CONFIG_NETFILTER_XT_MATCH_SCTP is not set
CONFIG_NETFILTER_XT_MATCH_STATE=m
# CONFIG_NETFILTER_XT_MATCH_STATISTIC is not set
# CONFIG_NETFILTER_XT_MATCH_STRING is not set
# CONFIG_NETFILTER_XT_MATCH_TCPMSS is not set
# CONFIG_NETFILTER_XT_MATCH_TIME is not set
# CONFIG_NETFILTER_XT_MATCH_U32 is not set
# CONFIG_NETFILTER_XT_MATCH_HASHLIMIT is not set
#
# IP: Netfilter Configuration
#
CONFIG_NF_CONNTRACK_IPV4=m
CONFIG_NF_CONNTRACK_PROC_COMPAT=y
# CONFIG_IP_NF_QUEUE is not set
CONFIG_IP_NF_IPTABLES=m
# CONFIG_IP_NF_MATCH_RECENT is not set
# CONFIG_IP_NF_MATCH_ECN is not set
# CONFIG_IP_NF_MATCH_AH is not set
# CONFIG_IP_NF_MATCH_TTL is not set
# CONFIG_IP_NF_MATCH_ADDRTYPE is not set
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_NF_NAT=m
CONFIG_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
# CONFIG_IP_NF_TARGET_REDIRECT is not set
# CONFIG_IP_NF_TARGET_NETMAP is not set
# CONFIG_NF_NAT_SNMP_BASIC is not set
CONFIG_NF_NAT_FTP=m
CONFIG_NF_NAT_IRC=m
# CONFIG_NF_NAT_TFTP is not set
# CONFIG_NF_NAT_AMANDA is not set
# CONFIG_NF_NAT_PPTP is not set
# CONFIG_NF_NAT_H323 is not set
# CONFIG_NF_NAT_SIP is not set
CONFIG_IP_NF_MANGLE=m
# CONFIG_IP_NF_TARGET_ECN is not set
# CONFIG_IP_NF_TARGET_TTL is not set
# CONFIG_IP_NF_TARGET_CLUSTERIP is not set
# CONFIG_IP_NF_RAW is not set
# CONFIG_IP_NF_SECURITY is not set
# CONFIG_IP_NF_ARPTABLES is not set
#
# IPv6: Netfilter Configuration
#
CONFIG_NF_CONNTRACK_IPV6=m
# CONFIG_IP6_NF_QUEUE is not set
CONFIG_IP6_NF_IPTABLES=m
# CONFIG_IP6_NF_MATCH_RT is not set
# CONFIG_IP6_NF_MATCH_OPTS is not set
# CONFIG_IP6_NF_MATCH_FRAG is not set
# CONFIG_IP6_NF_MATCH_HL is not set
# CONFIG_IP6_NF_MATCH_IPV6HEADER is not set
# CONFIG_IP6_NF_MATCH_AH is not set
# CONFIG_IP6_NF_MATCH_MH is not set
# CONFIG_IP6_NF_MATCH_EUI64 is not set
CONFIG_IP6_NF_FILTER=m
CONFIG_IP6_NF_TARGET_LOG=m
CONFIG_IP6_NF_TARGET_REJECT=m
# CONFIG_IP6_NF_MANGLE is not set
# CONFIG_IP6_NF_RAW is not set
# CONFIG_IP6_NF_SECURITY 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
# CONFIG_NET_SCHED is not set
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN 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
# CONFIG_NET_9P is not set
#
# Device Drivers
#
#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_CONNECTOR is not set
# CONFIG_MTD is not set
# CONFIG_PARPORT is not set
# CONFIG_PNP is not set
CONFIG_BLK_DEV=y
# 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=m
# 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=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=8192
# CONFIG_BLK_DEV_XIP is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_BLK_DEV_HD is not set
CONFIG_MISC_DEVICES=y
# CONFIG_PHANTOM is not set
# CONFIG_EEPROM_93CX6 is not set
CONFIG_SGI_IOC4=m
CONFIG_TIFM_CORE=m
CONFIG_TIFM_7XX1=m
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_HP_ILO is not set
CONFIG_HAVE_IDE=y
CONFIG_IDE=m
CONFIG_BLK_DEV_IDE=m
#
# Please see Documentation/ide/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_IDE_SATA is not set
CONFIG_BLK_DEV_IDEDISK=m
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=m
CONFIG_BLK_DEV_IDECD_VERBOSE_ERRORS=y
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
# CONFIG_BLK_DEV_IDESCSI is not set
# CONFIG_IDE_TASK_IOCTL is not set
# CONFIG_IDE_PROC_FS is not set
#
# IDE chipset support/bugfixes
#
# CONFIG_BLK_DEV_PLATFORM is not set
CONFIG_BLK_DEV_IDEDMA_SFF=y
#
# PCI IDE chipsets support
#
CONFIG_BLK_DEV_IDEPCI=y
# CONFIG_BLK_DEV_GENERIC is not set
# CONFIG_BLK_DEV_OPTI621 is not set
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX 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_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 is not set
# CONFIG_BLK_DEV_IT8213 is not set
# CONFIG_BLK_DEV_IT821X is not set
CONFIG_BLK_DEV_NS87415=m
# 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_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_BLK_DEV_IDEDMA=y
#
# SCSI device support
#
CONFIG_RAID_ATTRS=y
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
CONFIG_SCSI_TGT=y
# CONFIG_SCSI_NETLINK is not set
# CONFIG_SCSI_PROC_FS is not set
#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
# CONFIG_CHR_DEV_SG is not set
# CONFIG_CHR_DEV_SCH is not set
#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
# CONFIG_SCSI_SCAN_ASYNC is not set
CONFIG_SCSI_WAIT_SCAN=m
#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=y
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
CONFIG_SCSI_LOWLEVEL=y
# CONFIG_ISCSI_TCP is not set
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AHA1740 is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_AIC94XX is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_IN2000 is not set
# CONFIG_SCSI_ARCMSR is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
# CONFIG_SCSI_HPTIOP is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GENERIC_NCR5380 is not set
# CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_MVSAS is not set
# CONFIG_SCSI_NCR53C406A is not set
# CONFIG_SCSI_LASI700 is not set
# CONFIG_SCSI_STEX is not set
CONFIG_SCSI_SYM53C8XX_2=y
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1
CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16
CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64
CONFIG_SCSI_SYM53C8XX_MMIO=y
# CONFIG_SCSI_ZALON is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLA_FC is not set
# CONFIG_SCSI_QLA_ISCSI is not set
# CONFIG_SCSI_LPFC is not set
# CONFIG_SCSI_SIM710 is not set
# CONFIG_SCSI_SYM53C416 is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_T128 is not set
# CONFIG_SCSI_DEBUG is not set
# CONFIG_SCSI_SRP is not set
# CONFIG_SCSI_DH is not set
# CONFIG_ATA is not set
# CONFIG_MD is not set
# CONFIG_FUSION is not set
#
# IEEE 1394 (FireWire) support
#
#
# Enable only one of the two stacks, unless you know what you are doing
#
# CONFIG_FIREWIRE is not set
# CONFIG_IEEE1394 is not set
# CONFIG_I2O is not set
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_MACVLAN is not set
# CONFIG_EQUALIZER is not set
CONFIG_TUN=m
# CONFIG_VETH is not set
# CONFIG_ARCNET is not set
CONFIG_PHYLIB=m
#
# MII PHY device drivers
#
CONFIG_MARVELL_PHY=m
CONFIG_DAVICOM_PHY=m
CONFIG_QSEMI_PHY=m
CONFIG_LXT_PHY=m
CONFIG_CICADA_PHY=m
CONFIG_VITESSE_PHY=m
CONFIG_SMSC_PHY=m
CONFIG_BROADCOM_PHY=m
# CONFIG_ICPLUS_PHY is not set
# CONFIG_REALTEK_PHY is not set
# CONFIG_MDIO_BITBANG is not set
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_LASI_82596 is not set
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
CONFIG_NET_VENDOR_3COM=y
# CONFIG_EL1 is not set
# CONFIG_EL2 is not set
# CONFIG_EL16 is not set
# CONFIG_EL3 is not set
CONFIG_VORTEX=y
# CONFIG_TYPHOON is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set
CONFIG_NET_TULIP=y
# CONFIG_DE2104X is not set
CONFIG_TULIP=y
# CONFIG_TULIP_MWI is not set
CONFIG_TULIP_MMIO=y
CONFIG_TULIP_NAPI=y
CONFIG_TULIP_NAPI_HW_MITIGATION=y
# CONFIG_DE4X5 is not set
# CONFIG_WINBOND_840 is not set
# CONFIG_DM9102 is not set
# CONFIG_ULI526X is not set
# CONFIG_AT1700 is not set
# CONFIG_DEPCA is not set
# CONFIG_HP100 is not set
# CONFIG_NET_ISA is not set
# CONFIG_IBM_NEW_EMAC_ZMII is not set
# CONFIG_IBM_NEW_EMAC_RGMII is not set
# CONFIG_IBM_NEW_EMAC_TAH is not set
# CONFIG_IBM_NEW_EMAC_EMAC4 is not set
# CONFIG_NET_PCI is not set
# CONFIG_B44 is not set
# CONFIG_NETDEV_1000 is not set
# CONFIG_NETDEV_10000 is not set
# CONFIG_TR is not set
#
# Wireless LAN
#
# CONFIG_WLAN_PRE80211 is not set
# CONFIG_WLAN_80211 is not set
# CONFIG_IWLWIFI_LEDS 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 is not set
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_ISDN is not set
# CONFIG_PHONE is not set
#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
# CONFIG_INPUT_POLLDEV is not set
#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set
#
# Input Device Drivers
#
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE 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=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_GSCPS2 is not set
# CONFIG_HP_SDC is not set
# CONFIG_SERIO_PCIPS2 is not set
# 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_DEVKMEM is not set
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_NOZOMI is not set
#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_GSC=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_NR_UARTS=16
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
# CONFIG_SERIAL_8250_MANY_PORTS is not set
CONFIG_SERIAL_8250_SHARE_IRQ=y
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
# CONFIG_SERIAL_8250_RSA is not set
#
# Non-8250 serial port support
#
# CONFIG_SERIAL_MUX is not set
CONFIG_PDC_CONSOLE=y
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
# CONFIG_LEGACY_PTYS is not set
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=y
# CONFIG_GEN_RTC is not set
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_TCG_TPM is not set
CONFIG_DEVPORT=y
# CONFIG_I2C is not set
# CONFIG_SPI is not set
# CONFIG_W1 is not set
# CONFIG_POWER_SUPPLY is not set
# CONFIG_HWMON is not set
# CONFIG_THERMAL is not set
# CONFIG_THERMAL_HWMON is not set
# CONFIG_WATCHDOG is not set
#
# Sonics Silicon Backplane
#
CONFIG_SSB_POSSIBLE=y
# CONFIG_SSB is not set
#
# Multifunction device drivers
#
# CONFIG_MFD_SM501 is not set
# CONFIG_HTC_PASIC3 is not set
#
# Multimedia devices
#
#
# Multimedia core support
#
# CONFIG_VIDEO_DEV is not set
# CONFIG_DVB_CORE is not set
# CONFIG_VIDEO_MEDIA is not set
#
# Multimedia drivers
#
# CONFIG_DAB is not set
#
# Graphics support
#
# CONFIG_AGP is not set
# CONFIG_DRM is not set
# CONFIG_VGASTATE is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
# CONFIG_FB is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
#
# Display device support
#
# CONFIG_DISPLAY_SUPPORT is not set
#
# Console display driver support
#
CONFIG_DUMMY_CONSOLE=y
CONFIG_DUMMY_CONSOLE_COLUMNS=160
CONFIG_DUMMY_CONSOLE_ROWS=64
CONFIG_STI_CONSOLE=y
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
CONFIG_SOUND=m
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
# CONFIG_SND_SEQUENCER is not set
# CONFIG_SND_MIXER_OSS is not set
# CONFIG_SND_PCM_OSS is not set
# 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
CONFIG_SND_VMASTER=y
CONFIG_SND_AC97_CODEC=m
# CONFIG_SND_DRIVERS is not set
CONFIG_SND_PCI=y
CONFIG_SND_AD1889=m
# CONFIG_SND_ALS300 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_AW2 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_OXYGEN is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_CS46XX 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_HIFIER is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
# CONFIG_SND_INTEL8X0 is not set
# 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_VIRTUOSO is not set
# CONFIG_SND_VX222 is not set
# CONFIG_SND_YMFPCI is not set
# CONFIG_SND_USB is not set
# CONFIG_SND_GSC is not set
# CONFIG_SND_SOC is not set
# CONFIG_SOUND_PRIME is not set
CONFIG_AC97_BUS=m
# CONFIG_HID_SUPPORT is not set
CONFIG_USB_SUPPORT=y
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
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
CONFIG_USB_DEVICE_CLASS=y
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_OTG is not set
#
# USB Host Controller Drivers
#
# CONFIG_USB_C67X00_HCD is not set
CONFIG_USB_EHCI_HCD=m
# CONFIG_USB_EHCI_ROOT_HUB_TT is not set
# CONFIG_USB_EHCI_TT_NEWSCHED is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_ISP1760_HCD is not set
CONFIG_USB_OHCI_HCD=m
# CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set
# CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_UHCI_HCD=m
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set
#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set
# CONFIG_USB_WDM 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_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_DPCM is not set
# CONFIG_USB_STORAGE_USBAT is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_STORAGE_ALAUDA is not set
# CONFIG_USB_STORAGE_ONETOUCH is not set
# CONFIG_USB_STORAGE_KARMA is not set
# CONFIG_USB_STORAGE_CYPRESS_ATACB is not set
# CONFIG_USB_LIBUSUAL is not set
#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set
# CONFIG_USB_MON is not set
#
# USB port drivers
#
# 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
# CONFIG_USB_ISIGHTFW is not set
# CONFIG_USB_GADGET is not set
# CONFIG_MMC is not set
# CONFIG_MEMSTICK is not set
# CONFIG_NEW_LEDS is not set
# CONFIG_ACCESSIBILITY is not set
# CONFIG_INFINIBAND is not set
# CONFIG_RTC_CLASS is not set
# CONFIG_UIO is not set
#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
# CONFIG_EXT3_FS_XATTR is not set
# CONFIG_EXT4DEV_FS is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_REISERFS_FS=y
# CONFIG_REISERFS_CHECK is not set
# CONFIG_REISERFS_PROC_INFO is not set
# CONFIG_REISERFS_FS_XATTR 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_DNOTIFY is not set
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_QUOTA is not set
# 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_HUGETLB_PAGE is not set
CONFIG_CONFIGFS_FS=m
#
# 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_MINIX_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
# CONFIG_NETWORK_FILESYSTEMS is not set
#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
CONFIG_NLS=y
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 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ASCII=m
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
# CONFIG_DLM is not set
#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=0
CONFIG_MAGIC_SYSRQ=y
CONFIG_UNUSED_SYMBOLS=y
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
CONFIG_DETECT_SOFTLOCKUP=y
# CONFIG_SCHED_DEBUG is not set
# CONFIG_SCHEDSTATS is not set
# CONFIG_TIMER_STATS is not set
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_SPINLOCK_SLEEP=y
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_WRITECOUNT is not set
# CONFIG_DEBUG_LIST is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_SAMPLES is not set
# CONFIG_DEBUG_RODATA is not set
#
# Security options
#
# CONFIG_KEYS is not set
CONFIG_SECURITY=y
CONFIG_SECURITY_NETWORK=y
# CONFIG_SECURITY_FILE_CAPABILITIES is not set
CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR=0
CONFIG_CRYPTO=y
#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_MANAGER=y
# CONFIG_CRYPTO_GF128MUL is not set
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_CRYPTD is not set
# CONFIG_CRYPTO_AUTHENC is not set
# CONFIG_CRYPTO_TEST is not set
#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
# CONFIG_CRYPTO_SEQIV is not set
#
# Block modes
#
CONFIG_CRYPTO_CBC=y
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CTS is not set
CONFIG_CRYPTO_ECB=m
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_XTS is not set
#
# Hash modes
#
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_XCBC is not set
#
# Digest
#
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_MD4 is not set
# CONFIG_CRYPTO_MD5 is not set
CONFIG_CRYPTO_MICHAEL_MIC=m
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
# CONFIG_CRYPTO_SHA1 is not set
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_WP512 is not set
#
# Ciphers
#
CONFIG_CRYPTO_AES=m
# CONFIG_CRYPTO_ANUBIS is not set
CONFIG_CRYPTO_ARC4=m
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_DES is not set
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set
#
# Compression
#
# CONFIG_CRYPTO_DEFLATE is not set
# CONFIG_CRYPTO_LZO is not set
# CONFIG_CRYPTO_HW is not set
#
# Library routines
#
CONFIG_BITREVERSE=y
# CONFIG_GENERIC_FIND_FIRST_BIT is not set
# CONFIG_CRC_CCITT is not set
# CONFIG_CRC16 is not set
# CONFIG_CRC_T10DIF is not set
# CONFIG_CRC_ITU_T is not set
CONFIG_CRC32=y
# CONFIG_CRC7 is not set
# CONFIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=m
CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10786
> > Subject : parisc: 64bit SMP does not boot on J5600
> > Submitter : Domenico Andreoli <[email protected]>
> > Date : 2008-05-22 16:14 (46 days old)
> > References : http://marc.info/?l=linux-kernel&m=121147328028081&w=4
Regards,
Domenico
-----[ Domenico Andreoli, aka cavok
--[ http://www.dandreoli.com/gpgkey.asc
---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
On Sun, Jul 06, 2008 at 08:46:09AM -0700, Linus Torvalds wrote:
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10815
> > Subject : 2.6.26-rc4: RIP find_pid_ns+0x6b/0xa0
> > Submitter : Alexey Dobriyan <[email protected]>
> > Date : 2008-05-27 09:23 (41 days old)
> > References : http://lkml.org/lkml/2008/5/27/9
> > http://lkml.org/lkml/2008/6/14/87
> > Handled-By : Oleg Nesterov <[email protected]>
> > Linus Torvalds <[email protected]>
> > Paul E. McKenney <[email protected]>
> > Patch : http://lkml.org/lkml/2008/5/28/16
>
> This one is the same thing that is reported as unresolved, and no, I don't
> think that existing patch was ever really tested to fix anything. Paul?
Alexey tested the above patch, and it did not fix his failure
(http://lkml.org/lkml/2008/6/15/93). Neither did the patch
at http://lkml.org/lkml/2008/6/14/209. I was never able to
reproduce Alexey's failure, whether by running LTP in parallel
with 170 kernel builds or by running either in parallel with
rcutorture. Some enhancements to make rcutorture more vicious
were unable to provoke failures.
Alexey is able to provoke the failure on a maxcpus=1 configuration,
which should narrow things down quite a bit. I dug through
assembly, and found no issues at that level.
Alexey, would you be willing to send along your vmlinux or disassembly
of the RCU functions?
In any case, I am working up additional diagnostics.
> I suspect SRCU will need to be simply marked BROKEN for now, because
> nobody knows what the problem Alexey sees is. Apparently it's been seen by
> a few other people too.
PREEMPT_RCU is already marked "default n" with a "Say N if you are
unsure. Shouldn't that cover it?
I don't believe that SRCU is involved, please let me know if I missed
something.
Nick Piggin mentioned seeing failures similar to Alexey's, and I still
need his repeat-by. Nick?
Thanx, Paul
On Sun, Jul 06, 2008 at 06:58:10PM +0200, Ingo Molnar wrote:
>
> * Linus Torvalds <[email protected]> wrote:
>
> > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10815
> > > Subject : 2.6.26-rc4: RIP find_pid_ns+0x6b/0xa0
> > > Submitter : Alexey Dobriyan <[email protected]>
> > > Date : 2008-05-27 09:23 (41 days old)
> > > References : http://lkml.org/lkml/2008/5/27/9
> > > http://lkml.org/lkml/2008/6/14/87
> > > Handled-By : Oleg Nesterov <[email protected]>
> > > Linus Torvalds <[email protected]>
> > > Paul E. McKenney <[email protected]>
> > > Patch : http://lkml.org/lkml/2008/5/28/16
> >
> > This one is the same thing that is reported as unresolved, and no, I
> > don't think that existing patch was ever really tested to fix
> > anything. Paul?
> >
> > I suspect SRCU will need to be simply marked BROKEN for now, because
> > nobody knows what the problem Alexey sees is. Apparently it's been
> > seen by a few other people too.
>
> I'm not sure it's directly related to SRCU - it can change timings and
> freeing patterns enough to tickle other bugs. Since Alexey Dobriyan has
> reported it - are perhaps namespaces in use during this stress-test?
> Maybe it's some namespaces related bug that is more easily reproduced
> under SRCU - namespaces is not a commonly tested feature.
I have CONFIG_NAMESPACES=y. Should I also set one or more of
CONFIG_UTS_NS, CONFIG_IPC_NS, CONFIG_USER_NS, or CONFIG_PID_NS?
What the heck, I will just set them all and pound away on kernbenchx170
and rcutorture.
Thanx, Paul
> Also, i've been running rcutorture stress-tests on a number of
> test-systems ever since this got reported (and they are running
> currently as well) and cannot see it - neither could Paul reproduce it.
>
> ( and Paul is very good in producing RCU related problems - he's
> triggered and fixed many RCU related problems that no-one else saw
> before. )
>
> Ingo