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-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=10873
Subject : serial/bfin_5xx.c build error
Submitter : Adrian Bunk <[email protected]>
Date : 2008-06-06 09:24 (2 days old)
References : http://lkml.org/lkml/2008/6/6/277
Handled-By : Adrian Bunk <[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 (3 days old)
References : http://marc.info/?l=linux-kernel&m=121270308607116&w=4
Handled-By : Yinghai Lu <[email protected]>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10868
Subject : Oops on loading ipaq module since 2.6.26, prevents use of device
Submitter : Adam Williamson <[email protected]>
Date : 2008-06-05 17:39 (3 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10866
Subject : /dev/rtc was missing until I disabled CONFIG_RTC_CLASS
Submitter : Lior Dotan <[email protected]>
Date : 2008-06-05 15:04 (3 days old)
References : http://marc.info/?l=linux-kernel&m=121267834521432&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10865
Subject : i get the following oops trying to mount an ntfs partition on thinkpad
Submitter : Alex Romosan <[email protected]>
Date : 2008-06-05 14:47 (3 days old)
References : http://marc.info/?l=linux-kernel&m=121267834421414&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10864
Subject : [regression][bisected] ~90,000 wakeups as of 2.6.26-rc3
Submitter : Németh Márton <[email protected]>
Date : 2008-06-03 5:18 (5 days old)
References : http://marc.info/?l=linux-kernel&m=121247101601790&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10863
Subject : kvm causing memory corruption? now 2.6.26-rc4
Submitter : Dave Hansen <[email protected]>
Date : 2008-06-02 22:30 (6 days old)
References : http://marc.info/?l=linux-kernel&m=121244588705277&w=4
Handled-By : Avi Kivity <[email protected]>
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 (7 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 (7 days old)
References : http://marc.info/?l=linux-kernel&m=121229382917834&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 (3 days old)
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 (8 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10827
Subject : 2.6.26rc4 GFS2 oops.
Submitter : Dave Jones <[email protected]>
Date : 2008-05-27 15:44 (12 days old)
References : http://lkml.org/lkml/2008/5/27/297
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10826
Subject : NFS oops in 2.6.26rc4
Submitter : Dave Jones <[email protected]>
Date : 2008-05-27 19:04 (12 days old)
References : http://marc.info/?l=linux-kernel&m=121191548915522&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10825
Subject : appletouch after wakeup
Submitter : Justin Mattock <[email protected]>
Date : 2008-05-27 3:29 (12 days old)
References : http://marc.info/?l=linux-kernel&m=121185900618047&w=4
http://lkml.org/lkml/2008/5/31/193
http://lkml.org/lkml/2008/5/31/193
Handled-By : Oliver Neukum <[email protected]>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10823
Subject : stuck localhost TCP connections, v2.6.26-rc3+
Submitter : Ingo Molnar <[email protected]>
Date : 2008-05-26 11:56 (13 days old)
References : http://marc.info/?l=linux-kernel&m=121180311931349&w=4
Handled-By : Ilpo Järvinen <[email protected]>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10821
Subject : rt25xx: lock dependancy warning, association failure, and kmalloc corruption
Submitter : Christian Casteyde <[email protected]>
Date : 2008-05-29 14:30 (10 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10819
Subject : Fatal DMA error with b43 driver since 2.6.26
Submitter : Christian Casteyde <[email protected]>
Date : 2008-05-29 13:16 (10 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10799
Subject : sky2 general protection fault
Submitter : Nicolas Mailhot <[email protected]>
Date : 2008-05-26 11:05 (13 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10786
Subject : 2.6.26-rc3 64bit SMP does not boot on J5600
Submitter : Domenico Andreoli <[email protected]>
Date : 2008-05-22 16:14 (17 days old)
References : http://marc.info/?l=linux-kernel&m=121147328028081&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10764
Subject : some serial configurations are now broken
Submitter : Russell King <[email protected]>
Date : 2008-05-20 7:35 (19 days old)
References : http://marc.info/?l=linux-kernel&m=121126931810706&w=2
Handled-By : Javier Herrero <[email protected]>
Russell King <[email protected]>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10761
Subject : hackbench regression with 2.6.26-rc2 on tulsa machine
Submitter : Zhang, Yanmin <[email protected]>
Date : 2008-05-20 8:09 (19 days old)
References : http://marc.info/?l=linux-kernel&m=121127121813708&w=2
http://lkml.org/lkml/2008/6/2/10
Handled-By : Mike Galbraith <[email protected]>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10760
Subject : PCIEHP breakage in 2.6.26-rc1,2.6.26-rc2,2.6.26-rc3
Submitter : Ryan Hope <[email protected]>
Date : 2008-05-19 17:47 (20 days old)
References : http://marc.info/?l=linux-pci&m=121121926401755&w=2
Handled-By : Matthew Wilcox <[email protected]>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10748
Subject : dhclient fails to run; capabilities error
Submitter : Amit Shah <[email protected]>
Date : 2008-05-19 06:25 (20 days old)
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 (21 days old)
References : http://marc.info/?l=linux-kernel&m=121107706506181&w=4
Handled-By : Alan Cox <[email protected]>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10730
Subject : build issue #503 for v2.6.26-rc2-433-gf26a398 : undefined reference to `request_firmware'
Submitter : Toralf Förster <[email protected]>
Date : 2008-05-16 17:06 (23 days old)
References : http://marc.info/?l=linux-kernel&m=121095777616792&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10725
Subject : Write protect on on
Submitter : Maciej Rutecki <[email protected]>
Date : 2008-05-16 14:55 (23 days old)
References : http://marc.info/?l=linux-kernel&m=121095168003572&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10714
Subject : Badness seen on 2.6.26-rc2 with lockdep enabled
Submitter : Balbir Singh <[email protected]>
Date : 2008-05-14 12:57 (25 days old)
References : http://marc.info/?l=linux-kernel&m=121076917429133&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10711
Subject : BUG: unable to handle kernel paging request - scsi_bus_uevent
Submitter : Zdenek Kabelac <[email protected]>
Date : 2008-05-14 11:23 (25 days old)
References : http://lkml.org/lkml/2008/5/14/111
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10686
Subject : critical thermal shutdown regression 2.6.26-rc1 - HP Pavilion dv6700
Submitter : Len Brown <[email protected]>
Date : 2008-05-12 20:04 (27 days old)
Handled-By : Robert Moore <[email protected]>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10642
Subject : general protection fault: 0000 [1] PREEMPT SMP DEBUG_PAGEALLOC
Submitter : Zdenek Kabelac <[email protected]>
Date : 2008-05-07 16:03 (32 days old)
References : http://lkml.org/lkml/2008/5/7/48
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 (34 days old)
References : http://lkml.org/lkml/2008/5/5/28
Handled-By : Paul E. McKenney <[email protected]>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10614
Subject : WARNING: at include/linux/blkdev.h:431 blk_queue_init_tags+0x110/0x11f()
Submitter : J.A. Magallón <[email protected]>
Date : 2008-05-01 02:50 (38 days old)
References : http://lkml.org/lkml/2008/4/30/614
Handled-By : Nick Piggin <[email protected]>
Jens Axboe <[email protected]>
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 (36 days old)
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10874
Subject : blackfin drivers/net/smc91x.c build error
Submitter : Adrian Bunk <[email protected]>
Date : 2008-06-06 09:25 (2 days old)
References : http://lkml.org/lkml/2008/6/6/278
Handled-By : Adrian Bunk <[email protected]>
Patch : revert commit 099c736a470c8080a166e7a089f1e48e15f9947c
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10830
Subject : two different oopses with 2.6.26-rc4
Submitter : Alejandro Riveira Fernández <[email protected]>
Date : 2008-05-28 9:50 (11 days old)
References : http://marc.info/?l=linux-kernel&m=121196833026310&w=4
Handled-By : Johannes Berg <[email protected]>
Andrew Morton <[email protected]>
Peter Zijlstra <[email protected]>
Patch : http://lkml.org/lkml/2008/5/20/683
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10828
Subject : [2.6.25-git18 => 2.6.26-rc1-git1] Xorg crash with xf86MapVidMem error
Submitter : Rufus & Azrael <[email protected]>
Date : 2008-05-04 10:24 (35 days old)
References : http://lkml.org/lkml/2008/5/4/37
Handled-By : Ingo Molnar <[email protected]>
H. Peter Anvin <[email protected]>
Pallipadi, Venkatesh <[email protected]>
Patch : http://lkml.org/lkml/2008/5/29/371
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10816
Subject : vt/fbcon: fix background color on line feed
Submitter : thunder7 <[email protected]>
Date : 2008-05-27 19:33 (12 days old)
References : http://marc.info/?l=linux-kernel&m=121191733218735&w=4
Handled-By : Jan Engelhardt <[email protected]>
Patch : http://marc.info/?l=linux-kernel&m=121199453010047&w=4
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 (12 days old)
References : http://lkml.org/lkml/2008/5/27/9
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=10794
Subject : mips: CONF_CM_DEFAULT build error
Submitter : Adrian Bunk <[email protected]>
Date : 2008-05-25 10:11 (14 days old)
References : http://lkml.org/lkml/2008/5/25/168
Patch : http://lkml.org/lkml/2008/6/1/125
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10787
Subject : pcie hotplug bootup crash fix
Submitter : Ingo Molnar <[email protected]>
Date : 2008-05-24 16:58 (15 days old)
References : http://marc.info/?l=linux-kernel&m=121164842212038&w=4
Handled-By : Ingo Molnar <[email protected]>
Patch : http://marc.info/?l=linux-kernel&m=121164842212038&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10765
Subject : iwl3945/mac80211: association times out since 2.6.26-rc1
Submitter : Michael S. Tsirkin <[email protected]>
Date : 2008-05-20 22:46 (19 days old)
Handled-By : Zhu Yi <[email protected]>
Johannes Berg <[email protected]>
Patch : http://article.gmane.org/gmane.linux.kernel.wireless.general/15177
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 (23 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=10724
Subject : ACPI: EC: GPE storm detected, disabling EC GPE
Submitter : Justin Mattock <[email protected]>
Date : 2008-05-16 6:17 (23 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
http://lkml.org/lkml/2008/5/25/195
Patch : debug EC GPE
debug EC GPE
debug EC GPE
debug EC GPE
http://bugzilla.kernel.org/attachment.cgi?id=16364&action=view
http://bugzilla.kernel.org/attachment.cgi?id=16365&action=view
http://bugzilla.kernel.org/attachment.cgi?id=16364&action=view
http://bugzilla.kernel.org/attachment.cgi?id=16365&action=view
debug EC GPE</a>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10670
Subject : BUG: linux-2.6.26-rc1 oops at thinkpad_acpi:led_set_status
Submitter : Karol Lewandowski <[email protected]>
Date : 2008-05-08 23:12 (31 days old)
References : http://marc.info/?l=linux-kernel&m=121028841527994&w=4
http://lkml.org/lkml/2008/5/12/12
Handled-By : Henrique de Moraes Holschuh <[email protected]>
Patch : http://bugzilla.kernel.org/attachment.cgi?id=16153&action=view
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10669
Subject : ACPI: kmemcheck: Caught 16-bit read from freed memory (f7c12ec6)
Submitter : Vegard Nossum <[email protected]>
Date : 2008-05-06 16:09 (33 days old)
References : http://marc.info/?l=linux-acpi&m=121009034825514&w=4
Handled-By : Lin Ming <[email protected]>
Ming Lin <[email protected]>
Patch : http://bugzilla.kernel.org/attachment.cgi?id=16199&action=view
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10616
Subject : Horrendous Audio Stutter - current git
Submitter : Parag Warudkar <[email protected]>
Date : 2008-05-02 20:14 (37 days old)
References : http://lkml.org/lkml/2008/5/1/440
http://lkml.org/lkml/2008/5/11/230
http://lkml.org/lkml/2008/5/18/178
Handled-By : Peter Zijlstra <[email protected]>
Patch : http://lkml.org/lkml/2008/5/2/126
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10606
Subject : 2.6.26-rc1 regression: ACPI fails to load SDT. - Dell M1530
Submitter : NIgel Cunningham <[email protected]>
Date : 2008-05-05 18:11 (34 days old)
References : http://lkml.org/lkml/2008/5/18/328
http://lkml.org/lkml/2008/5/26/3
http://lkml.org/lkml/2008/6/2/524
Patch : http://bugzilla.kernel.org/attachment.cgi?id=16061&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 (49 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
Patch : http://marc.info/?l=linux-kernel&m=120876451216558&w=2
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 (49 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
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=10606
Subject : 2.6.26-rc1 regression: ACPI fails to load SDT. - Dell M1530
Submitter : NIgel Cunningham <[email protected]>
Date : 2008-05-05 18:11 (34 days old)
References : http://lkml.org/lkml/2008/5/18/328
http://lkml.org/lkml/2008/5/26/3
http://lkml.org/lkml/2008/6/2/524
Patch : http://bugzilla.kernel.org/attachment.cgi?id=16061&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=10616
Subject : Horrendous Audio Stutter - current git
Submitter : Parag Warudkar <[email protected]>
Date : 2008-05-02 20:14 (37 days old)
References : http://lkml.org/lkml/2008/5/1/440
http://lkml.org/lkml/2008/5/11/230
http://lkml.org/lkml/2008/5/18/178
Handled-By : Peter Zijlstra <[email protected]>
Patch : http://lkml.org/lkml/2008/5/2/126
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=10642
Subject : general protection fault: 0000 [1] PREEMPT SMP DEBUG_PAGEALLOC
Submitter : Zdenek Kabelac <[email protected]>
Date : 2008-05-07 16:03 (32 days old)
References : http://lkml.org/lkml/2008/5/7/48
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 (34 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=10669
Subject : ACPI: kmemcheck: Caught 16-bit read from freed memory (f7c12ec6)
Submitter : Vegard Nossum <[email protected]>
Date : 2008-05-06 16:09 (33 days old)
References : http://marc.info/?l=linux-acpi&m=121009034825514&w=4
Handled-By : Lin Ming <[email protected]>
Ming Lin <[email protected]>
Patch : http://bugzilla.kernel.org/attachment.cgi?id=16199&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=10670
Subject : BUG: linux-2.6.26-rc1 oops at thinkpad_acpi:led_set_status
Submitter : Karol Lewandowski <[email protected]>
Date : 2008-05-08 23:12 (31 days old)
References : http://marc.info/?l=linux-kernel&m=121028841527994&w=4
http://lkml.org/lkml/2008/5/12/12
Handled-By : Henrique de Moraes Holschuh <[email protected]>
Patch : http://bugzilla.kernel.org/attachment.cgi?id=16153&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=10686
Subject : critical thermal shutdown regression 2.6.26-rc1 - HP Pavilion dv6700
Submitter : Len Brown <[email protected]>
Date : 2008-05-12 20:04 (27 days old)
Handled-By : Robert Moore <[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=10711
Subject : BUG: unable to handle kernel paging request - scsi_bus_uevent
Submitter : Zdenek Kabelac <[email protected]>
Date : 2008-05-14 11:23 (25 days old)
References : http://lkml.org/lkml/2008/5/14/111
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 : Badness seen on 2.6.26-rc2 with lockdep enabled
Submitter : Balbir Singh <[email protected]>
Date : 2008-05-14 12:57 (25 days old)
References : http://marc.info/?l=linux-kernel&m=121076917429133&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 : Write protect on on
Submitter : Maciej Rutecki <[email protected]>
Date : 2008-05-16 14:55 (23 days old)
References : http://marc.info/?l=linux-kernel&m=121095168003572&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 (23 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
http://lkml.org/lkml/2008/5/25/195
Patch : debug EC GPE
debug EC GPE
debug EC GPE
debug EC GPE
http://bugzilla.kernel.org/attachment.cgi?id=16364&action=view
http://bugzilla.kernel.org/attachment.cgi?id=16365&action=view
http://bugzilla.kernel.org/attachment.cgi?id=16364&action=view
http://bugzilla.kernel.org/attachment.cgi?id=16365&action=view
debug EC GPE</a>
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 (23 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=10730
Subject : build issue #503 for v2.6.26-rc2-433-gf26a398 : undefined reference to `request_firmware'
Submitter : Toralf Förster <[email protected]>
Date : 2008-05-16 17:06 (23 days old)
References : http://marc.info/?l=linux-kernel&m=121095777616792&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=10741
Subject : bug in `tty: BKL pushdown'?
Submitter : Johannes Weiner <[email protected]>
Date : 2008-05-18 2:16 (21 days old)
References : http://marc.info/?l=linux-kernel&m=121107706506181&w=4
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=10760
Subject : PCIEHP breakage in 2.6.26-rc1,2.6.26-rc2,2.6.26-rc3
Submitter : Ryan Hope <[email protected]>
Date : 2008-05-19 17:47 (20 days old)
References : http://marc.info/?l=linux-pci&m=121121926401755&w=2
Handled-By : Matthew Wilcox <[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=10748
Subject : dhclient fails to run; capabilities error
Submitter : Amit Shah <[email protected]>
Date : 2008-05-19 06:25 (20 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=10761
Subject : hackbench regression with 2.6.26-rc2 on tulsa machine
Submitter : Zhang, Yanmin <[email protected]>
Date : 2008-05-20 8:09 (19 days old)
References : http://marc.info/?l=linux-kernel&m=121127121813708&w=2
http://lkml.org/lkml/2008/6/2/10
Handled-By : Mike Galbraith <[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 : 2.6.26-rc3 64bit SMP does not boot on J5600
Submitter : Domenico Andreoli <[email protected]>
Date : 2008-05-22 16:14 (17 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=10764
Subject : some serial configurations are now broken
Submitter : Russell King <[email protected]>
Date : 2008-05-20 7:35 (19 days old)
References : http://marc.info/?l=linux-kernel&m=121126931810706&w=2
Handled-By : Javier Herrero <[email protected]>
Russell King <[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=10787
Subject : pcie hotplug bootup crash fix
Submitter : Ingo Molnar <[email protected]>
Date : 2008-05-24 16:58 (15 days old)
References : http://marc.info/?l=linux-kernel&m=121164842212038&w=4
Handled-By : Ingo Molnar <[email protected]>
Patch : http://marc.info/?l=linux-kernel&m=121164842212038&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=10794
Subject : mips: CONF_CM_DEFAULT build error
Submitter : Adrian Bunk <[email protected]>
Date : 2008-05-25 10:11 (14 days old)
References : http://lkml.org/lkml/2008/5/25/168
Patch : http://lkml.org/lkml/2008/6/1/125
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=10799
Subject : sky2 general protection fault
Submitter : Nicolas Mailhot <[email protected]>
Date : 2008-05-26 11:05 (13 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=10765
Subject : iwl3945/mac80211: association times out since 2.6.26-rc1
Submitter : Michael S. Tsirkin <[email protected]>
Date : 2008-05-20 22:46 (19 days old)
Handled-By : Zhu Yi <[email protected]>
Johannes Berg <[email protected]>
Patch : http://article.gmane.org/gmane.linux.kernel.wireless.general/15177
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 (12 days old)
References : http://lkml.org/lkml/2008/5/27/9
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=10816
Subject : vt/fbcon: fix background color on line feed
Submitter : thunder7 <[email protected]>
Date : 2008-05-27 19:33 (12 days old)
References : http://marc.info/?l=linux-kernel&m=121191733218735&w=4
Handled-By : Jan Engelhardt <[email protected]>
Patch : http://marc.info/?l=linux-kernel&m=121199453010047&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=10821
Subject : rt25xx: lock dependancy warning, association failure, and kmalloc corruption
Submitter : Christian Casteyde <[email protected]>
Date : 2008-05-29 14:30 (10 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=10819
Subject : Fatal DMA error with b43 driver since 2.6.26
Submitter : Christian Casteyde <[email protected]>
Date : 2008-05-29 13:16 (10 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=10825
Subject : appletouch after wakeup
Submitter : Justin Mattock <[email protected]>
Date : 2008-05-27 3:29 (12 days old)
References : http://marc.info/?l=linux-kernel&m=121185900618047&w=4
http://lkml.org/lkml/2008/5/31/193
http://lkml.org/lkml/2008/5/31/193
Handled-By : Oliver Neukum <[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=10826
Subject : NFS oops in 2.6.26rc4
Submitter : Dave Jones <[email protected]>
Date : 2008-05-27 19:04 (12 days old)
References : http://marc.info/?l=linux-kernel&m=121191548915522&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=10827
Subject : 2.6.26rc4 GFS2 oops.
Submitter : Dave Jones <[email protected]>
Date : 2008-05-27 15:44 (12 days old)
References : http://lkml.org/lkml/2008/5/27/297
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=10823
Subject : stuck localhost TCP connections, v2.6.26-rc3+
Submitter : Ingo Molnar <[email protected]>
Date : 2008-05-26 11:56 (13 days old)
References : http://marc.info/?l=linux-kernel&m=121180311931349&w=4
Handled-By : Ilpo Järvinen <[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=10828
Subject : [2.6.25-git18 => 2.6.26-rc1-git1] Xorg crash with xf86MapVidMem error
Submitter : Rufus & Azrael <[email protected]>
Date : 2008-05-04 10:24 (35 days old)
References : http://lkml.org/lkml/2008/5/4/37
Handled-By : Ingo Molnar <[email protected]>
H. Peter Anvin <[email protected]>
Pallipadi, Venkatesh <[email protected]>
Patch : http://lkml.org/lkml/2008/5/29/371
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 (8 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=10830
Subject : two different oopses with 2.6.26-rc4
Submitter : Alejandro Riveira Fernández <[email protected]>
Date : 2008-05-28 9:50 (11 days old)
References : http://marc.info/?l=linux-kernel&m=121196833026310&w=4
Handled-By : Johannes Berg <[email protected]>
Andrew Morton <[email protected]>
Peter Zijlstra <[email protected]>
Patch : http://lkml.org/lkml/2008/5/20/683
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 (3 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=10862
Subject : forcedeth: lockdep warning on ethtool -s
Submitter : Tobias Diedrich <[email protected]>
Date : 2008-06-01 8:37 (7 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=10863
Subject : kvm causing memory corruption? now 2.6.26-rc4
Submitter : Dave Hansen <[email protected]>
Date : 2008-06-02 22:30 (6 days old)
References : http://marc.info/?l=linux-kernel&m=121244588705277&w=4
Handled-By : Avi Kivity <[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=10864
Subject : [regression][bisected] ~90,000 wakeups as of 2.6.26-rc3
Submitter : Németh Márton <[email protected]>
Date : 2008-06-03 5:18 (5 days old)
References : http://marc.info/?l=linux-kernel&m=121247101601790&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=10873
Subject : serial/bfin_5xx.c build error
Submitter : Adrian Bunk <[email protected]>
Date : 2008-06-06 09:24 (2 days old)
References : http://lkml.org/lkml/2008/6/6/277
Handled-By : Adrian Bunk <[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=10874
Subject : blackfin drivers/net/smc91x.c build error
Submitter : Adrian Bunk <[email protected]>
Date : 2008-06-06 09:25 (2 days old)
References : http://lkml.org/lkml/2008/6/6/278
Handled-By : Adrian Bunk <[email protected]>
Patch : revert commit 099c736a470c8080a166e7a089f1e48e15f9947c
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=10868
Subject : Oops on loading ipaq module since 2.6.26, prevents use of device
Submitter : Adam Williamson <[email protected]>
Date : 2008-06-05 17:39 (3 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=10872
Subject : x86_64 boot hang when CONFIG_NUMA=n
Submitter : Randy Dunlap <[email protected]>
Date : 2008-06-05 21:50 (3 days old)
References : http://marc.info/?l=linux-kernel&m=121270308607116&w=4
Handled-By : Yinghai Lu <[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=10866
Subject : /dev/rtc was missing until I disabled CONFIG_RTC_CLASS
Submitter : Lior Dotan <[email protected]>
Date : 2008-06-05 15:04 (3 days old)
References : http://marc.info/?l=linux-kernel&m=121267834521432&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=10865
Subject : i get the following oops trying to mount an ntfs partition on thinkpad
Submitter : Alex Romosan <[email protected]>
Date : 2008-06-05 14:47 (3 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=10861
Subject : 2.6.26-rc4-git2 - long pause during boot
Submitter : Chris Clayton <[email protected]>
Date : 2008-06-01 4:15 (7 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=9791
Subject : Clock is running too fast^Wslow using acpi_pm clocksource
Submitter : [email protected]
Date : 2008-05-03 05:09 (36 days old)
On Sat, Jun 7, 2008 at 10:42 PM, 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=10669
> Subject : ACPI: kmemcheck: Caught 16-bit read from freed memory (f7c12ec6)
> Submitter : Vegard Nossum <[email protected]>
> Date : 2008-05-06 16:09 (33 days old)
> References : http://marc.info/?l=linux-acpi&m=121009034825514&w=4
> Handled-By : Lin Ming <[email protected]>
> Ming Lin <[email protected]>
> Patch : http://bugzilla.kernel.org/attachment.cgi?id=16199&action=view
>
I'm sorry, I have no idea why this fix isn't going upstream. I tested
the patch and it's completely fine with regards to kmemcheck. And the
patch it fixes was already upstream so I don't see what's stopping it
from going back in + the fix.
So the question is if this should go in now, or whether it should wait
till 2.6.26. In either case, the regression itself was solved by the
means of a revert, and that's quite a long time ago, so the current
kernel should be fine in this regard, though I think the original
patch fixed some errors on its own.
Ming Lin, will you resubmit the original patch plus the fix for
re-inclusion in mainline? There's no point in having this regression
entry around when it has been fixed by either/both the revert or/and
the extra "fix" patch.
Thanks! :-)
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
On Saturday 2008-06-07 22:42, 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.
>
>
>Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10816
>Subject : vt/fbcon: fix background color on line feed
>Submitter : thunder7 <[email protected]>
>Date : 2008-05-27 19:33 (12 days old)
>References : http://marc.info/?l=linux-kernel&m=121191733218735&w=4
>Handled-By : Jan Engelhardt <[email protected]>
>Patch : http://marc.info/?l=linux-kernel&m=121199453010047&w=4
>
is upstream 774533b3e86fa52941c79aa80ab3f0cc511bba7f.
On Saturday 07 June 2008, 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.
Yes.
> 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 (8 days old)
On Sat, Jun 7, 2008 at 10:42 PM, 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=10860
> Subject : total system freeze at boot with 2.6.26-rc
> Submitter : Christian Casteyde <[email protected]>
> Date : 2008-06-05 12:38 (3 days old)
I looked at the bugzilla entry, but it said not to post any replies in
there. I hope it's okay to reply here, because I couldn't find the
original discussion on LKML.
Christian, did you try the nmi watchdog parameter on boot? It is
really quite simple -- add nmi_watchdog=1 to the kernel parameters.
When the machine freezes, leave it for a minute or two in that state.
The NMI watchdog code might be able to give us a backtrace and tell us
exactly where the machine is hanging. While waiting, you can prepare
the camera... ;-)
(BTW, why isn't this nmi watchdog trick the "standard" reply to hung
kernels? It seems that very few are actually aware of it, or using it
to debug these cases.)
Anyway, good luck with that! :-)
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
On Sat, Jun 7, 2008 at 8:42 PM, 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=10825
> Subject : appletouch after wakeup
> Submitter : Justin Mattock <[email protected]>
> Date : 2008-05-27 3:29 (12 days old)
> References : http://marc.info/?l=linux-kernel&m=121185900618047&w=4
> http://lkml.org/lkml/2008/5/31/193
> http://lkml.org/lkml/2008/5/31/193
> Handled-By : Oliver Neukum <[email protected]>
>
>
>
I'm not seeing appletouch react this way after applying the patches.
regards;
--
Justin P. Mattock
On Sat, 2008-06-07 at 22:42 +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.
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10761
> Subject : hackbench regression with 2.6.26-rc2 on tulsa machine
> Submitter : Zhang, Yanmin <[email protected]>
> Date : 2008-05-20 8:09 (19 days old)
> References : http://marc.info/?l=linux-kernel&m=121127121813708&w=2
> http://lkml.org/lkml/2008/6/2/10
> Handled-By : Mike Galbraith <[email protected]>
The fingered patchlet and the code it touched were reverted, so I think
this is a stale entry.
-Mike
On Sunday, 8 of June 2008, Frans Pop wrote:
> 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.
>
> This issue was traced to FAIR_GROUP_SCHED, which is no longer present
> in -rc5 as the patches that introduced it have been reverted:
>
> Commit: f9305d4a0968201b2818dbed0dc8cb0d4ee7aeb3
> Author: Ingo Molnar <[email protected]>
> Date: Thu May 29 11:23:17 2008 +0200
>
> revert ("sched: fair: weight calculations")
>
> commit 6363ca57c76b7b83639ca8c83fc285fa26a7880e
> Author: Ingo Molnar <[email protected]>
> Date: Thu May 29 11:28:57 2008 +0200
>
> revert ("sched: fair-group: SMP-nice for group scheduling")
>
> Therefore this issue can be removed from the regressions list.
Thanks, I've closed the bug.
Rafael
On Sunday, 8 of June 2008, Mike Galbraith wrote:
>
> On Sat, 2008-06-07 at 22:42 +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.
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10761
> > Subject : hackbench regression with 2.6.26-rc2 on tulsa machine
> > Submitter : Zhang, Yanmin <[email protected]>
> > Date : 2008-05-20 8:09 (19 days old)
> > References : http://marc.info/?l=linux-kernel&m=121127121813708&w=2
> > http://lkml.org/lkml/2008/6/2/10
> > Handled-By : Mike Galbraith <[email protected]>
>
> The fingered patchlet and the code it touched were reverted, so I think
> this is a stale entry.
Thanks, closed.
Rafael
On Sunday, 8 of June 2008, Jan Engelhardt wrote:
>
> On Saturday 2008-06-07 22:42, 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.
> >
> >
> >Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10816
> >Subject : vt/fbcon: fix background color on line feed
> >Submitter : thunder7 <[email protected]>
> >Date : 2008-05-27 19:33 (12 days old)
> >References : http://marc.info/?l=linux-kernel&m=121191733218735&w=4
> >Handled-By : Jan Engelhardt <[email protected]>
> >Patch : http://marc.info/?l=linux-kernel&m=121199453010047&w=4
> >
> is upstream 774533b3e86fa52941c79aa80ab3f0cc511bba7f.
Thanks, closed.
Rafael
On Sunday, 8 of June 2008, Justin Mattock wrote:
> On Sat, Jun 7, 2008 at 8:42 PM, 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=10825
> > Subject : appletouch after wakeup
> > Submitter : Justin Mattock <[email protected]>
> > Date : 2008-05-27 3:29 (12 days old)
> > References : http://marc.info/?l=linux-kernel&m=121185900618047&w=4
> > http://lkml.org/lkml/2008/5/31/193
> > http://lkml.org/lkml/2008/5/31/193
> > Handled-By : Oliver Neukum <[email protected]>
> >
> >
> >
>
> I'm not seeing appletouch react this way after applying the patches.
Still, have the patches reached the Linus' tree yet?
Rafael
On Sunday, 8 of June 2008, Vegard Nossum wrote:
> On Sat, Jun 7, 2008 at 10:42 PM, 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=10860
> > Subject : total system freeze at boot with 2.6.26-rc
> > Submitter : Christian Casteyde <[email protected]>
> > Date : 2008-06-05 12:38 (3 days old)
>
> I looked at the bugzilla entry, but it said not to post any replies in
> there. I hope it's okay to reply here, because I couldn't find the
> original discussion on LKML.
That was an Andrew's message targeted at the people who were on its CC list.
Of course you can update the Bugzilla entry. :-)
Thanks,
Rafael
On Sun, Jun 8, 2008 at 4:53 PM, Rafael J. Wysocki <[email protected]> wrote:
> On Sunday, 8 of June 2008, Justin Mattock wrote:
>> On Sat, Jun 7, 2008 at 8:42 PM, 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=10825
>> > Subject : appletouch after wakeup
>> > Submitter : Justin Mattock <[email protected]>
>> > Date : 2008-05-27 3:29 (12 days old)
>> > References : http://marc.info/?l=linux-kernel&m=121185900618047&w=4
>> > http://lkml.org/lkml/2008/5/31/193
>> > http://lkml.org/lkml/2008/5/31/193
>> > Handled-By : Oliver Neukum <[email protected]>
>> >
>> >
>> >
>>
>> I'm not seeing appletouch react this way after applying the patches.
>
> Still, have the patches reached the Linus' tree yet?
>
> Rafael
>
I'm not sure if they did or not, I think Oliver was working on that,
but am unsure.
regards;
--
Justin P. Mattock
I believe this was fixed in 2.6.26-rc5. Could anyone please confirm it?
Unfortunately, I don't have the reproduction environment.
Thanks,
Kenji Kaneshige
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=10760
> Subject : PCIEHP breakage in 2.6.26-rc1,2.6.26-rc2,2.6.26-rc3
> Submitter : Ryan Hope <[email protected]>
> Date : 2008-05-19 17:47 (20 days old)
> References : http://marc.info/?l=linux-pci&m=121121926401755&w=2
> Handled-By : Matthew Wilcox <[email protected]>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
This is fixed (workaround for now) in 2.6.26-rc5.
Thanks,
Kenji Kaneshige
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=10787
> Subject : pcie hotplug bootup crash fix
> Submitter : Ingo Molnar <[email protected]>
> Date : 2008-05-24 16:58 (15 days old)
> References : http://marc.info/?l=linux-kernel&m=121164842212038&w=4
> Handled-By : Ingo Molnar <[email protected]>
> Patch : http://marc.info/?l=linux-kernel&m=121164842212038&w=4
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
Am Samstag 07 Juni 2008 22:42:57 schrieb Rafael J. Wysocki:
> 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=10825
> Subject : appletouch after wakeup
> Submitter : Justin Mattock <[email protected]>
> Date : 2008-05-27 3:29 (12 days old)
> References : http://marc.info/?l=linux-kernel&m=121185900618047&w=4
> http://lkml.org/lkml/2008/5/31/193
> http://lkml.org/lkml/2008/5/31/193
> Handled-By : Oliver Neukum <[email protected]>
A patch is available but not yet in mainline.
Regards
Oliver
On Sat, 7 Jun 2008, 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=10823
> Subject : stuck localhost TCP connections, v2.6.26-rc3+
> Submitter : Ingo Molnar <[email protected]>
> Date : 2008-05-26 11:56 (13 days old)
> References : http://marc.info/?l=linux-kernel&m=121180311931349&w=4
> Handled-By : Ilpo J?rvinen <[email protected]>
This should still be listed. We have a potential patch but testing of it
might have hit another bug with similar symptoms. Also a known to working
revert exists. ...But neither is in mainline / net-2.6 yet.
--
i.
On Mon, Jun 9, 2008 at 9:07 AM, Oliver Neukum <[email protected]> wrote:
> Am Samstag 07 Juni 2008 22:42:57 schrieb Rafael J. Wysocki:
>> 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=10825
>> Subject : appletouch after wakeup
>> Submitter : Justin Mattock <[email protected]>
>> Date : 2008-05-27 3:29 (12 days old)
>> References : http://marc.info/?l=linux-kernel&m=121185900618047&w=4
>> http://lkml.org/lkml/2008/5/31/193
>> http://lkml.org/lkml/2008/5/31/193
>> Handled-By : Oliver Neukum <[email protected]>
>
> A patch is available but not yet in mainline.
>
> Regards
> Oliver
>
Cool; just an update, I've suspended the system numerous times it
seems appletouch is behaving correctly, in fact
I think better, why: when I start the system I have two finger scroll
functionality, then when suspending the system
after waking up the two finger scroll is still functional.
regards;
--
Justin P. Mattock
Am Montag 09 Juni 2008 18:18:19 schrieb Justin Mattock:
> On Mon, Jun 9, 2008 at 9:07 AM, Oliver Neukum <[email protected]> wrote:
> > Am Samstag 07 Juni 2008 22:42:57 schrieb Rafael J. Wysocki:
> >> 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=10825
> >> Subject : appletouch after wakeup
> >> Submitter : Justin Mattock <[email protected]>
> >> Date : 2008-05-27 3:29 (12 days old)
> >> References : http://marc.info/?l=linux-kernel&m=121185900618047&w=4
> >> http://lkml.org/lkml/2008/5/31/193
> >> http://lkml.org/lkml/2008/5/31/193
> >> Handled-By : Oliver Neukum <[email protected]>
> >
> > A patch is available but not yet in mainline.
> >
> > Regards
> > Oliver
> >
>
> Cool; just an update, I've suspended the system numerous times it
> seems appletouch is behaving correctly, in fact
> I think better, why: when I start the system I have two finger scroll
> functionality, then when suspending the system
> after waking up the two finger scroll is still functional.
> regards;
>
With last week's patch or today's patch?
Regards
Oliver
On Mon, Jun 9, 2008 at 7:53 PM, Oliver Neukum <[email protected]> wrote:
> Am Montag 09 Juni 2008 18:18:19 schrieb Justin Mattock:
>> On Mon, Jun 9, 2008 at 9:07 AM, Oliver Neukum <[email protected]> wrote:
>> > Am Samstag 07 Juni 2008 22:42:57 schrieb Rafael J. Wysocki:
>> >> 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=10825
>> >> Subject : appletouch after wakeup
>> >> Submitter : Justin Mattock <[email protected]>
>> >> Date : 2008-05-27 3:29 (12 days old)
>> >> References : http://marc.info/?l=linux-kernel&m=121185900618047&w=4
>> >> http://lkml.org/lkml/2008/5/31/193
>> >> http://lkml.org/lkml/2008/5/31/193
>> >> Handled-By : Oliver Neukum <[email protected]>
>> >
>> > A patch is available but not yet in mainline.
>> >
>> > Regards
>> > Oliver
>> >
>>
>> Cool; just an update, I've suspended the system numerous times it
>> seems appletouch is behaving correctly, in fact
>> I think better, why: when I start the system I have two finger scroll
>> functionality, then when suspending the system
>> after waking up the two finger scroll is still functional.
>> regards;
>>
>
> With last week's patch or today's patch?
>
> Regards
> Oliver
>
>
Last weeks patch.
regards;
--
Justin P. Mattock
Am Montag 09 Juni 2008 22:29:05 schrieb Justin Mattock:
> On Mon, Jun 9, 2008 at 7:53 PM, Oliver Neukum <[email protected]> wrote:
> > Am Montag 09 Juni 2008 18:18:19 schrieb Justin Mattock:
> >> Cool; just an update, I've suspended the system numerous times it
> >> seems appletouch is behaving correctly, in fact
> >> I think better, why: when I start the system I have two finger scroll
> >> functionality, then when suspending the system
> >> after waking up the two finger scroll is still functional.
> >> regards;
> >>
> >
> > With last week's patch or today's patch?
> >
> > Regards
> > Oliver
> >
> >
>
> Last weeks patch.
> regards;
>
Could you also try today's patch?
Regards
Oliver
On Mon, Jun 9, 2008 at 8:31 PM, Oliver Neukum <[email protected]> wrote:
> Am Montag 09 Juni 2008 22:29:05 schrieb Justin Mattock:
>> On Mon, Jun 9, 2008 at 7:53 PM, Oliver Neukum <[email protected]> wrote:
>> > Am Montag 09 Juni 2008 18:18:19 schrieb Justin Mattock:
>
>> >> Cool; just an update, I've suspended the system numerous times it
>> >> seems appletouch is behaving correctly, in fact
>> >> I think better, why: when I start the system I have two finger scroll
>> >> functionality, then when suspending the system
>> >> after waking up the two finger scroll is still functional.
>> >> regards;
>> >>
>> >
>> > With last week's patch or today's patch?
>> >
>> > Regards
>> > Oliver
>> >
>> >
>>
>> Last weeks patch.
>> regards;
>>
>
> Could you also try today's patch?
>
> Regards
> Oliver
>
>
Sure, where is it located.
regards;
--
Justin P. Mattock
Am Montag 09 Juni 2008 22:52:21 schrieb Justin Mattock:
> On Mon, Jun 9, 2008 at 8:31 PM, Oliver Neukum <[email protected]> wrote:
> > Am Montag 09 Juni 2008 22:29:05 schrieb Justin Mattock:
> >> On Mon, Jun 9, 2008 at 7:53 PM, Oliver Neukum <[email protected]> wrote:
> >> > Am Montag 09 Juni 2008 18:18:19 schrieb Justin Mattock:
> >
> >> >> Cool; just an update, I've suspended the system numerous times it
> >> >> seems appletouch is behaving correctly, in fact
> >> >> I think better, why: when I start the system I have two finger scroll
> >> >> functionality, then when suspending the system
> >> >> after waking up the two finger scroll is still functional.
> >> >> regards;
> >> >>
> >> >
> >> > With last week's patch or today's patch?
> >> >
> >> > Regards
> >> > Oliver
> >> >
> >> >
> >>
> >> Last weeks patch.
> >> regards;
> >>
> >
> > Could you also try today's patch?
> >
> > Regards
> > Oliver
> >
> >
>
> Sure, where is it located.
> regards;
>
Didn't I mail it to you? Anyway, here it is.
Regards
Oliver
----
--- linux-2.6.26-rc5/drivers/usb/core/quirks.c 2008-06-05 13:45:57.000000000 +0200
+++ linux-2.6.26-rc5-btusb/drivers/usb/core/quirks.c 2008-06-06 08:12:10.000000000 +0200
@@ -47,6 +47,9 @@ static const struct usb_device_id usb_qu
/* Edirol SD-20 */
{ USB_DEVICE(0x0582, 0x0027), .driver_info = USB_QUIRK_RESET_RESUME },
+ /* appletouch */
+ { USB_DEVICE(0x05ac, 0x021a), .driver_info = USB_QUIRK_RESET_RESUME },
+
/* Avision AV600U */
{ USB_DEVICE(0x0638, 0x0a13), .driver_info =
USB_QUIRK_STRING_FETCH_255 },
--- linux-2.6.26-rc5-btusb/drivers/input/mouse/appletouch.c.alt 2008-06-09 10:40:00.000000000 +0200
+++ linux-2.6.26-rc5-btusb/drivers/input/mouse/appletouch.c 2008-06-09 10:40:03.000000000 +0200
@@ -589,6 +589,20 @@ static void atp_close(struct input_dev *
dev->open = 0;
}
+static int handle_geyser(struct atp *dev)
+{
+ struct usb_device *udev = dev->udev;
+
+ if (!atp_is_fountain(dev)) {
+ /* switch to raw sensor mode */
+ if (atp_geyser_init(udev))
+ return -EIO;
+
+ printk(KERN_INFO "appletouch: Geyser mode initialized.\n");
+ }
+ return 0;
+}
+
static int atp_probe(struct usb_interface *iface, const struct usb_device_id *id)
{
struct atp *dev;
@@ -744,6 +758,20 @@ static void atp_disconnect(struct usb_in
printk(KERN_INFO "input: appletouch disconnected\n");
}
+static int recover_dev(struct atp *dev)
+{
+ int rv;
+
+ rv = handle_geyser(dev);
+ if (rv < 0)
+ return rv;
+
+ if (dev->open && usb_submit_urb(dev->urb, GFP_NOIO))
+ return -EIO;
+
+ return 0;
+}
+
static int atp_suspend(struct usb_interface *iface, pm_message_t message)
{
struct atp *dev = usb_get_intfdata(iface);
@@ -764,12 +792,20 @@ static int atp_resume(struct usb_interfa
return 0;
}
+static int atp_reset_resume(struct usb_interface *iface)
+{
+ struct atp *dev = usb_get_intfdata(iface);
+
+ return recover_dev(dev);
+}
+
static struct usb_driver atp_driver = {
.name = "appletouch",
.probe = atp_probe,
.disconnect = atp_disconnect,
.suspend = atp_suspend,
.resume = atp_resume,
+ .reset_resume = atp_reset_resume,
.id_table = atp_table,
};
On Mon, Jun 9, 2008 at 9:16 PM, Oliver Neukum <[email protected]> wrote:
> Am Montag 09 Juni 2008 22:52:21 schrieb Justin Mattock:
>> On Mon, Jun 9, 2008 at 8:31 PM, Oliver Neukum <[email protected]> wrote:
>> > Am Montag 09 Juni 2008 22:29:05 schrieb Justin Mattock:
>> >> On Mon, Jun 9, 2008 at 7:53 PM, Oliver Neukum <[email protected]> wrote:
>> >> > Am Montag 09 Juni 2008 18:18:19 schrieb Justin Mattock:
>> >
>> >> >> Cool; just an update, I've suspended the system numerous times it
>> >> >> seems appletouch is behaving correctly, in fact
>> >> >> I think better, why: when I start the system I have two finger scroll
>> >> >> functionality, then when suspending the system
>> >> >> after waking up the two finger scroll is still functional.
>> >> >> regards;
>> >> >>
>> >> >
>> >> > With last week's patch or today's patch?
>> >> >
>> >> > Regards
>> >> > Oliver
>> >> >
>> >> >
>> >>
>> >> Last weeks patch.
>> >> regards;
>> >>
>> >
>> > Could you also try today's patch?
>> >
>> > Regards
>> > Oliver
>> >
>> >
>>
>> Sure, where is it located.
>> regards;
>>
>
> Didn't I mail it to you? Anyway, here it is.
>
> Regards
> Oliver
>
> ----
>
> --- linux-2.6.26-rc5/drivers/usb/core/quirks.c 2008-06-05 13:45:57.000000000 +0200
> +++ linux-2.6.26-rc5-btusb/drivers/usb/core/quirks.c 2008-06-06 08:12:10.000000000 +0200
> @@ -47,6 +47,9 @@ static const struct usb_device_id usb_qu
> /* Edirol SD-20 */
> { USB_DEVICE(0x0582, 0x0027), .driver_info = USB_QUIRK_RESET_RESUME },
>
> + /* appletouch */
> + { USB_DEVICE(0x05ac, 0x021a), .driver_info = USB_QUIRK_RESET_RESUME },
> +
> /* Avision AV600U */
> { USB_DEVICE(0x0638, 0x0a13), .driver_info =
> USB_QUIRK_STRING_FETCH_255 },
> --- linux-2.6.26-rc5-btusb/drivers/input/mouse/appletouch.c.alt 2008-06-09 10:40:00.000000000 +0200
> +++ linux-2.6.26-rc5-btusb/drivers/input/mouse/appletouch.c 2008-06-09 10:40:03.000000000 +0200
> @@ -589,6 +589,20 @@ static void atp_close(struct input_dev *
> dev->open = 0;
> }
>
> +static int handle_geyser(struct atp *dev)
> +{
> + struct usb_device *udev = dev->udev;
> +
> + if (!atp_is_fountain(dev)) {
> + /* switch to raw sensor mode */
> + if (atp_geyser_init(udev))
> + return -EIO;
> +
> + printk(KERN_INFO "appletouch: Geyser mode initialized.\n");
> + }
> + return 0;
> +}
> +
> static int atp_probe(struct usb_interface *iface, const struct usb_device_id *id)
> {
> struct atp *dev;
> @@ -744,6 +758,20 @@ static void atp_disconnect(struct usb_in
> printk(KERN_INFO "input: appletouch disconnected\n");
> }
>
> +static int recover_dev(struct atp *dev)
> +{
> + int rv;
> +
> + rv = handle_geyser(dev);
> + if (rv < 0)
> + return rv;
> +
> + if (dev->open && usb_submit_urb(dev->urb, GFP_NOIO))
> + return -EIO;
> +
> + return 0;
> +}
> +
> static int atp_suspend(struct usb_interface *iface, pm_message_t message)
> {
> struct atp *dev = usb_get_intfdata(iface);
> @@ -764,12 +792,20 @@ static int atp_resume(struct usb_interfa
> return 0;
> }
>
> +static int atp_reset_resume(struct usb_interface *iface)
> +{
> + struct atp *dev = usb_get_intfdata(iface);
> +
> + return recover_dev(dev);
> +}
> +
> static struct usb_driver atp_driver = {
> .name = "appletouch",
> .probe = atp_probe,
> .disconnect = atp_disconnect,
> .suspend = atp_suspend,
> .resume = atp_resume,
> + .reset_resume = atp_reset_resume,
> .id_table = atp_table,
> };
>
>
>
You probably did, I'll apply this and let you know.
regards;
--
Justin P. Mattock
On Mon, Jun 9, 2008 at 10:04 PM, Justin Mattock <[email protected]> wrote:
> On Mon, Jun 9, 2008 at 9:16 PM, Oliver Neukum <[email protected]> wrote:
>> Am Montag 09 Juni 2008 22:52:21 schrieb Justin Mattock:
>>> On Mon, Jun 9, 2008 at 8:31 PM, Oliver Neukum <[email protected]> wrote:
>>> > Am Montag 09 Juni 2008 22:29:05 schrieb Justin Mattock:
>>> >> On Mon, Jun 9, 2008 at 7:53 PM, Oliver Neukum <[email protected]> wrote:
>>> >> > Am Montag 09 Juni 2008 18:18:19 schrieb Justin Mattock:
>>> >
>>> >> >> Cool; just an update, I've suspended the system numerous times it
>>> >> >> seems appletouch is behaving correctly, in fact
>>> >> >> I think better, why: when I start the system I have two finger scroll
>>> >> >> functionality, then when suspending the system
>>> >> >> after waking up the two finger scroll is still functional.
>>> >> >> regards;
>>> >> >>
>>> >> >
>>> >> > With last week's patch or today's patch?
>>> >> >
>>> >> > Regards
>>> >> > Oliver
>>> >> >
>>> >> >
>>> >>
>>> >> Last weeks patch.
>>> >> regards;
>>> >>
>>> >
>>> > Could you also try today's patch?
>>> >
>>> > Regards
>>> > Oliver
>>> >
>>> >
>>>
>>> Sure, where is it located.
>>> regards;
>>>
>>
>> Didn't I mail it to you? Anyway, here it is.
>>
>> Regards
>> Oliver
>>
>> ----
>>
>> --- linux-2.6.26-rc5/drivers/usb/core/quirks.c 2008-06-05 13:45:57.000000000 +0200
>> +++ linux-2.6.26-rc5-btusb/drivers/usb/core/quirks.c 2008-06-06 08:12:10.000000000 +0200
>> @@ -47,6 +47,9 @@ static const struct usb_device_id usb_qu
>> /* Edirol SD-20 */
>> { USB_DEVICE(0x0582, 0x0027), .driver_info = USB_QUIRK_RESET_RESUME },
>>
>> + /* appletouch */
>> + { USB_DEVICE(0x05ac, 0x021a), .driver_info = USB_QUIRK_RESET_RESUME },
>> +
>> /* Avision AV600U */
>> { USB_DEVICE(0x0638, 0x0a13), .driver_info =
>> USB_QUIRK_STRING_FETCH_255 },
>> --- linux-2.6.26-rc5-btusb/drivers/input/mouse/appletouch.c.alt 2008-06-09 10:40:00.000000000 +0200
>> +++ linux-2.6.26-rc5-btusb/drivers/input/mouse/appletouch.c 2008-06-09 10:40:03.000000000 +0200
>> @@ -589,6 +589,20 @@ static void atp_close(struct input_dev *
>> dev->open = 0;
>> }
>>
>> +static int handle_geyser(struct atp *dev)
>> +{
>> + struct usb_device *udev = dev->udev;
>> +
>> + if (!atp_is_fountain(dev)) {
>> + /* switch to raw sensor mode */
>> + if (atp_geyser_init(udev))
>> + return -EIO;
>> +
>> + printk(KERN_INFO "appletouch: Geyser mode initialized.\n");
>> + }
>> + return 0;
>> +}
>> +
>> static int atp_probe(struct usb_interface *iface, const struct usb_device_id *id)
>> {
>> struct atp *dev;
>> @@ -744,6 +758,20 @@ static void atp_disconnect(struct usb_in
>> printk(KERN_INFO "input: appletouch disconnected\n");
>> }
>>
>> +static int recover_dev(struct atp *dev)
>> +{
>> + int rv;
>> +
>> + rv = handle_geyser(dev);
>> + if (rv < 0)
>> + return rv;
>> +
>> + if (dev->open && usb_submit_urb(dev->urb, GFP_NOIO))
>> + return -EIO;
>> +
>> + return 0;
>> +}
>> +
>> static int atp_suspend(struct usb_interface *iface, pm_message_t message)
>> {
>> struct atp *dev = usb_get_intfdata(iface);
>> @@ -764,12 +792,20 @@ static int atp_resume(struct usb_interfa
>> return 0;
>> }
>>
>> +static int atp_reset_resume(struct usb_interface *iface)
>> +{
>> + struct atp *dev = usb_get_intfdata(iface);
>> +
>> + return recover_dev(dev);
>> +}
>> +
>> static struct usb_driver atp_driver = {
>> .name = "appletouch",
>> .probe = atp_probe,
>> .disconnect = atp_disconnect,
>> .suspend = atp_suspend,
>> .resume = atp_resume,
>> + .reset_resume = atp_reset_resume,
>> .id_table = atp_table,
>> };
>>
>>
>>
>
> You probably did, I'll apply this and let you know.
> regards;
>
> --
> Justin P. Mattock
>
O.K. This is smaller than last weeks? anyways I applied the patch, and
am not seeing appletouch freak out like it did, also
two finger scroll is still active upon wakeup(FWIW). Cool, and thanks
for the help.
regards;
--
Justin P. Mattock
Am Dienstag 10 Juni 2008 00:36:02 schrieb Justin Mattock:
> O.K. This is smaller than last weeks? anyways I applied the patch, and
That patch also saved some power, this just fixes bugs. It's indeed smaller.
> am not seeing appletouch freak out like it did, also
> two finger scroll is still active upon wakeup(FWIW). Cool, and thanks
Dmitry, Greg,
we have confirmation. Would you take the patch for 2.6.26 and stable?
Regards
Oliver
On Mon, Jun 9, 2008 at 10:40 PM, Oliver Neukum <[email protected]> wrote:
> Am Dienstag 10 Juni 2008 00:36:02 schrieb Justin Mattock:
>
>> O.K. This is smaller than last weeks? anyways I applied the patch, and
>
> That patch also saved some power, this just fixes bugs. It's indeed smaller.
>
>> am not seeing appletouch freak out like it did, also
>> two finger scroll is still active upon wakeup(FWIW). Cool, and thanks
>
> Dmitry, Greg,
>
> we have confirmation. Would you take the patch for 2.6.26 and stable?
>
> Regards
> Oliver
>
Please ignore the two finger scroll part(even though it seems to
work), I have been ignoring my xorg.conf for sometime and need to
configure it so I can have all functionality back, and then I'll let
you know what the status is.
regards;
--
Justin P. Mattock
On Tue, 10 Jun 2008, Justin Mattock wrote:
> Please ignore the two finger scroll part(even though it seems to work),
> I have been ignoring my xorg.conf for sometime and need to configure it
> so I can have all functionality back, and then I'll let you know what
> the status is. regards;
You can easily test with 'evtest' utility to see the data that are really
comming out of a kernel for your particular device, to filter out any
mangling that X does on these events.
--
Jiri Kosina
SUSE Labs
On Tue, Jun 10, 2008 at 12:06 AM, Jiri Kosina <[email protected]> wrote:
> On Tue, 10 Jun 2008, Justin Mattock wrote:
>
>> Please ignore the two finger scroll part(even though it seems to work),
>> I have been ignoring my xorg.conf for sometime and need to configure it
>> so I can have all functionality back, and then I'll let you know what
>> the status is. regards;
>
> You can easily test with 'evtest' utility to see the data that are really
> comming out of a kernel for your particular device, to filter out any
> mangling that X does on these events.
>
> --
> Jiri Kosina
> SUSE Labs
>
Cool; Thanks for the help.
--
Justin P. Mattock
On Sat, Jun 07, 2008 at 10:38:33PM +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 (49 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
> Patch : http://marc.info/?l=linux-kernel&m=120876451216558&w=2
cu
Adrian
On Sat, Jun 07, 2008 at 10:42:57PM +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=10794
> Subject : mips: CONF_CM_DEFAULT build error
> Submitter : Adrian Bunk <[email protected]>
> Date : 2008-05-25 10:11 (14 days old)
> References : http://lkml.org/lkml/2008/5/25/168
> Patch : http://lkml.org/lkml/2008/6/1/125
cu
Adrian
--- Original Message ---
> 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=10872
> Subject : x86_64 boot hang when CONFIG_NUMA=n
> Submitter : Randy Dunlap <[email protected]>
> Date : 2008-06-05 21:50 (3 days old)
> References : http://marc.info/?l=linux-kernel&m=121270308607116&w=4
> Handled-By : Yinghai Lu <[email protected]>
I'll try to test x86/tip today.
On Sat, Jun 07, 2008 at 10:42:57PM +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.
>
>
> 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 (12 days old)
> References : http://lkml.org/lkml/2008/5/27/9
> Handled-By : Oleg Nesterov <[email protected]>
> Linus Torvalds <[email protected]>
> Paul E. McKenney <[email protected]>
> Patch : http://lkml.org/lkml/2008/5/28/16
What happened with this issue?
It is currently listed as 2.6.26-rc regression.
Is this correct?
And if this patch is required it might not be a good idea to allow the
use to disable the new code.
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 Sat, Jun 07, 2008 at 10:42:57PM +0200, Rafael J. Wysocki wrote:
>...
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10821
> Subject : rt25xx: lock dependancy warning, association failure, and kmalloc corruption
> Submitter : Christian Casteyde <[email protected]>
> Date : 2008-05-29 14:30 (10 days old)
Ivo, can you look at this 2.6.26-rc regression?
TIA
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 Friday 13 June 2008, Adrian Bunk wrote:
> On Sat, Jun 07, 2008 at 10:42:57PM +0200, Rafael J. Wysocki wrote:
> >...
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10821
> > Subject : rt25xx: lock dependancy warning, association failure, and kmalloc corruption
> > Submitter : Christian Casteyde <[email protected]>
> > Date : 2008-05-29 14:30 (10 days old)
>
>
> Ivo, can you look at this 2.6.26-rc regression?
Sure, both issues should have been fixed in 2.6.26-rc5 :)
Ivo
On Sat, Jun 07, 2008 at 10:42:57PM +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.
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10866
> Subject : /dev/rtc was missing until I disabled CONFIG_RTC_CLASS
> Submitter : Lior Dotan <[email protected]>
> Date : 2008-06-05 15:04 (3 days old)
> References : http://marc.info/?l=linux-kernel&m=121267834521432&w=4
Where are we regarding this entry in the 2.6.26-rc regression list?
I'd agree with David that CONFIG_RTC_CLASS disabling CONFIG_RTC is a fix
and not a 2.6.26-rc regression.
Does anyone disagree with this?
I'm not sure whether this was Lior's problem or another issue I'm seeing
on my computer (static /dev, no udev):
/dev/rtc (major 10, minor 135) does not seem to exist, and I'd call this
a functional regression of the new drivers.
Could this be fixed?
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 Fri, Jun 13, 2008 at 10:33 PM, Adrian Bunk <[email protected]> wrote:
> On Sat, Jun 07, 2008 at 10:42:57PM +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.
>>
>>
>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10866
>> Subject : /dev/rtc was missing until I disabled CONFIG_RTC_CLASS
>> Submitter : Lior Dotan <[email protected]>
>> Date : 2008-06-05 15:04 (3 days old)
>> References : http://marc.info/?l=linux-kernel&m=121267834521432&w=4
>
> Where are we regarding this entry in the 2.6.26-rc regression list?
>
> I'd agree with David that CONFIG_RTC_CLASS disabling CONFIG_RTC is a fix
> and not a 2.6.26-rc regression.
>
> Does anyone disagree with this?
>
>
> I'm not sure whether this was Lior's problem or another issue I'm seeing
> on my computer (static /dev, no udev):
>
> /dev/rtc (major 10, minor 135) does not seem to exist, and I'd call this
> a functional regression of the new drivers.
>
> Could this be fixed?
>
>
> cu
> Adrian
>
> --
I don't know if it helps you to decide but the way I got to this
configuration is by copying my working 2.6.25 .config file and running
make oldconfig. I think this scenario is common when upgrading to a
newer version so you should make sure it doesn't generate an invalid
configuration.
Lior.
On Friday 13 June 2008, Lior Dotan wrote:
> I don't know if it helps you to decide but the way I got to this
> configuration is by copying my working 2.6.25 .config file and running
> make oldconfig. I think this scenario is common when upgrading to a
> newer version so you should make sure it doesn't generate an invalid
> configuration.
It doesn't! "No /dev/rtc" is a perfectly valid config. And it's
not uncommon that new kernels require config tweaks.
To repeat what's in the bug database: your old config didn't use
one of the valid RTC configs: legacy *OR* new style (else neither).
Mixing the two was never supported ... it caused various bugs, and
much confusion. You might not have observed with your old .config
on your hardware (or might have ignored it), but other folk did.
I'm not sure anyone would have wanted to merge any patches that
would have let the two frameworks coexist/overlap, but that's a
moot point since nobody (including you) submitted such patches.
What was submitted was a patch that rejected an invalid config.
- Dave
* David Brownell <[email protected]> wrote:
> On Friday 13 June 2008, Lior Dotan wrote:
> > I don't know if it helps you to decide but the way I got to this
> > configuration is by copying my working 2.6.25 .config file and running
> > make oldconfig. I think this scenario is common when upgrading to a
> > newer version so you should make sure it doesn't generate an invalid
> > configuration.
>
> It doesn't! "No /dev/rtc" is a perfectly valid config. [...]
The bug scenario is rather simple: /dev/rtc existed with that config in
prior kernels and now, after "make oldconfig" it does not exist, it's a
plain regression and must be fixed.
> And it's not uncommon that new kernels require config tweaks.
that's wrong - 'make oldconfig' must work smoothly and in an expected
way.
If you argue that the new kernel should come up with a non-existent
/dev/rtc, then you are wrong and you go against established regression
handling policies of the kernel. Smooth migration via "make oldconfig"
is a must, otherwise we'd lose testers and users.
The old /dev/rtc might indeed have been unbelievably "bad" in various
ways and you dont even want to think about that code now, but it's your
code now that is used so you might as well think about the other 98% of
users who used the old /dev/rtc with old kernels. (not because they
wanted to use bad code, but because simply that was the default)
Ingo
On Fri, Jun 13, 2008 at 10:55:38PM +0300, Lior Dotan wrote:
> On Fri, Jun 13, 2008 at 10:33 PM, Adrian Bunk <[email protected]> wrote:
> > On Sat, Jun 07, 2008 at 10:42:57PM +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.
> >>
> >>
> >> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10866
> >> Subject : /dev/rtc was missing until I disabled CONFIG_RTC_CLASS
> >> Submitter : Lior Dotan <[email protected]>
> >> Date : 2008-06-05 15:04 (3 days old)
> >> References : http://marc.info/?l=linux-kernel&m=121267834521432&w=4
> >
> > Where are we regarding this entry in the 2.6.26-rc regression list?
> >
> > I'd agree with David that CONFIG_RTC_CLASS disabling CONFIG_RTC is a fix
> > and not a 2.6.26-rc regression.
> >
> > Does anyone disagree with this?
> >
> >
> > I'm not sure whether this was Lior's problem or another issue I'm seeing
> > on my computer (static /dev, no udev):
> >
> > /dev/rtc (major 10, minor 135) does not seem to exist, and I'd call this
> > a functional regression of the new drivers.
> >
> > Could this be fixed?
>
> I don't know if it helps you to decide but the way I got to this
> configuration is by copying my working 2.6.25 .config file and running
> make oldconfig. I think this scenario is common when upgrading to a
> newer version so you should make sure it doesn't generate an invalid
> configuration.
What is the output of "grep RTC_ .config" on your old .config?
> Lior.
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 Friday 13 June 2008, Ingo Molnar wrote:
>
> Smooth migration via "make oldconfig"
> is a must, otherwise we'd lose testers and users.
Yes, but "smooth" doesn't mean there's never a need to cope
with kernel updates by running "xconfig" (or whatever).
In my own experience, several times a year I need to go back
and patch up a mess that "oldconfig" made. Things drop out,
things get added ... it's the things that get *added* without
even a by-your-leave which often seem hardest to fix.
> you might as well think about the other 98% of
> users who used the old /dev/rtc with old kernels. (not because they
> wanted to use bad code, but because simply that was the default)
They can continue working just fine with *only* the legacy RTC.
If they stuck with defaults, no problems appear. (Modulo the
fact that bitrot is setting in.)
The only thing that causes the least hiccup is someone who was
for a while using a bogus (and non-default) configuration.
Given a bogus configuration, how should it be fixed? There
can be several solutions, and the right answer for one system
will always be the right one for another. So any approach
that doesn't expect a human to select options sometimes will
be inherently wrong in various cases.
- Dave
On Fri, 13 Jun 2008 15:38:54 -0700
David Brownell <[email protected]> wrote:
>
> They can continue working just fine with *only* the legacy RTC.
> If they stuck with defaults, no problems appear. (Modulo the
> fact that bitrot is setting in.)
>
> The only thing that causes the least hiccup is someone who was
> for a while using a bogus (and non-default) configuration.
>
> Given a bogus configuration, how should it be fixed? There
> can be several solutions, and the right answer for one system
> will always be the right one for another. So any approach
> that doesn't expect a human to select options sometimes will
> be inherently wrong in various cases.
I agree with david. oldconfig cannot be made to fix every possible
manual misconfiguration that has been introduced by the user, even
those that, by chance, just worked.
The actual Kconfig will handle pretty well the transition from
a good config. where good is different from working-by-chance.
There are far too many people that just keep pressing Y
when a new kernel option appears without even considering what would
happen or reading the help.
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it
* David Brownell <[email protected]> wrote:
> On Friday 13 June 2008, Ingo Molnar wrote:
> >
> > Smooth migration via "make oldconfig"
> > is a must, otherwise we'd lose testers and users.
>
> Yes, but "smooth" doesn't mean there's never a need to cope with
> kernel updates by running "xconfig" (or whatever).
you are arguing against the facts - just look at the report - /dev/rtc
broke and that shouldnt have happened and should be fixed. No amount of
talking you do here will produce a working config.
> In my own experience, several times a year I need to go back and patch
> up a mess that "oldconfig" made. Things drop out, things get added
> ... it's the things that get *added* without even a by-your-leave
> which often seem hardest to fix.
i have hit 1400 kernel bugs in the past 6 months alone on my
testsystems. That does not mean kernel bugs are the norm and it does not
entitle me to ignore kernel bugs in the future?
> The only thing that causes the least hiccup is someone who was for a
> while using a bogus (and non-default) configuration.
uhm, there's no such thing as a "bogus configuration". The Kconfig rules
for RTC (authored by you too) allowed it. If it "makes no sense" it's
because you coded it so - deal with it, it's not hard. But instead of
solving it (it is trivial) you are trying to push the blame to the user
- and that is rather lame to do.
> Given a bogus configuration, how should it be fixed? [...]
this is not rocket science. The solution is to turn on the fine RTC
code, if the old config option is enabled too. I.e. be more careful
about compatibility. It's still possible to solve this problem and allow
the RTC code to be compiled out completely.
and note that you are hurting users who tried out _your_ RTC code (which
was default off in the past) previously. Yes, while experimenting with
your code they might have created the "wrong" mix of config options but
that's not a problem - this isnt some esoteric embedded platform where
only real men are allowed to configure the kernel and who are left out
in the cold if they mess up - this is Linux where we encourage (and beg)
actual user to test our kernels. So please show some basic respect
towards them and dont arbitrarily declare configs "broken" that were
working in the past.
Ingo
On Sat, Jun 14, 2008 at 11:35:35AM +0200, Alessandro Zummo wrote:
> On Fri, 13 Jun 2008 15:38:54 -0700
> David Brownell <[email protected]> wrote:
>
> > They can continue working just fine with *only* the legacy RTC.
> > If they stuck with defaults, no problems appear. (Modulo the
> > fact that bitrot is setting in.)
> >
> > The only thing that causes the least hiccup is someone who was
> > for a while using a bogus (and non-default) configuration.
> >
> > Given a bogus configuration, how should it be fixed? There
> > can be several solutions, and the right answer for one system
> > will always be the right one for another. So any approach
> > that doesn't expect a human to select options sometimes will
> > be inherently wrong in various cases.
>
> I agree with david. oldconfig cannot be made to fix every possible
> manual misconfiguration that has been introduced by the user, even
> those that, by chance, just worked.
>
> The actual Kconfig will handle pretty well the transition from
> a good config. where good is different from working-by-chance.
>
> There are far too many people that just keep pressing Y
> when a new kernel option appears without even considering what would
> happen or reading the help.
If Lior's problem was due to something like CONFIG_RTC_CLASS=y,
CONFIG_RTC_DRV_CMOS=n that's a kernel configuration that would
anyway break when the old driver gets removed, and it just broke
earlier.
Everyone seems to focus on this kconfig related case, what about my
point of no /dev/rtc with a static /dev ? When talking about existing
setups and embedded systems that's a real issue for some systems.
> Best regards,
>
> Alessandro Zummo,
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 Sat, 14 Jun 2008 14:18:06 +0300
Adrian Bunk <[email protected]> wrote:
>
> If Lior's problem was due to something like CONFIG_RTC_CLASS=y,
> CONFIG_RTC_DRV_CMOS=n that's a kernel configuration that would
> anyway break when the old driver gets removed, and it just broke
> earlier.
I haven't seen the .config, but CONFIG_RTC_CLASS=y
and CONFIG_RTC_DRV_CMOS=n is perfectly legal.
It just don't have to be put in the default x86 config maybe,
but it's legal..
> Everyone seems to focus on this kconfig related case, what about my
> point of no /dev/rtc with a static /dev ? When talking about existing
> setups and embedded systems that's a real issue for some systems.
the device node creation is yet another option of the
rtc class. it should be on by default in any defconfig, I'd guess.
But then you'll get /dev/rtc0 without any specific device node.
As I said in the past, I'd accept a patch to handle this special
case of having /dev/rtc with a specific major and minor, but I'm against
it.
It would be better to upgrade your userspace when such big changes
happens in the kernel. In fact, it the first time that the rtc
has been touched in the last.. 10 year? I think it's not unreasonable to
ask to upgrade userspace.
wrto embedded systems, having worked with them for years, you are expected
to check every detail of every new kernel you want to use before releasing
it or, say, uploading it to your lander on the moon :)
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it
On Fri, Jun 13, 2008 at 11:20 PM, Adrian Bunk <[email protected]> wrote:
> On Fri, Jun 13, 2008 at 10:55:38PM +0300, Lior Dotan wrote:
>> On Fri, Jun 13, 2008 at 10:33 PM, Adrian Bunk <[email protected]> wrote:
>> > On Sat, Jun 07, 2008 at 10:42:57PM +0200, Rafael J. Wysocki wrote:
>> >
>> > /dev/rtc (major 10, minor 135) does not seem to exist, and I'd call this
>> > a functional regression of the new drivers.
>> >
>> > Could this be fixed?
>>
>> I don't know if it helps you to decide but the way I got to this
>> configuration is by copying my working 2.6.25 .config file and running
>> make oldconfig. I think this scenario is common when upgrading to a
>> newer version so you should make sure it doesn't generate an invalid
>> configuration.
>
> What is the output of "grep RTC_ .config" on your old .config?
I don't have access to that machine right now so I'll post it tomorrow.
> cu
> Adrian
>
Cheers,
Lior
On Fri, Jun 13, 2008 at 04:52:55PM +0300, Adrian Bunk wrote:
> On Sat, Jun 07, 2008 at 10:42:57PM +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.
> >
> >
> > 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 (12 days old)
> > References : http://lkml.org/lkml/2008/5/27/9
> > Handled-By : Oleg Nesterov <[email protected]>
> > Linus Torvalds <[email protected]>
> > Paul E. McKenney <[email protected]>
> > Patch : http://lkml.org/lkml/2008/5/28/16
>
> What happened with this issue?
The patch listed above works for me, passes rcutorture, &c. However,
I never have been able to reproduce the original problem, so cannot say
whether it qualifies as a fix.
Thanx, Paul
> It is currently listed as 2.6.26-rc regression.
> Is this correct?
>
> And if this patch is required it might not be a good idea to allow the
> use to disable the new code.
On 06/14, Paul E. McKenney wrote:
>
> On Fri, Jun 13, 2008 at 04:52:55PM +0300, Adrian Bunk wrote:
> > On Sat, Jun 07, 2008 at 10:42:57PM +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.
> > >
> > >
> > > 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 (12 days old)
> > > References : http://lkml.org/lkml/2008/5/27/9
> > > Handled-By : Oleg Nesterov <[email protected]>
> > > Linus Torvalds <[email protected]>
> > > Paul E. McKenney <[email protected]>
> > > Patch : http://lkml.org/lkml/2008/5/28/16
> >
> > What happened with this issue?
>
> The patch listed above works for me, passes rcutorture, &c. However,
> I never have been able to reproduce the original problem, so cannot say
> whether it qualifies as a fix.
I doubt very much RCU was the reason of this problem.
Alexey, how did you trigger this problem?
Oleg.
On Sat, Jun 14, 2008 at 06:58:39PM +0400, Oleg Nesterov wrote:
> On 06/14, Paul E. McKenney wrote:
> >
> > On Fri, Jun 13, 2008 at 04:52:55PM +0300, Adrian Bunk wrote:
> > > On Sat, Jun 07, 2008 at 10:42:57PM +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.
> > > >
> > > >
> > > > 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 (12 days old)
> > > > References : http://lkml.org/lkml/2008/5/27/9
> > > > Handled-By : Oleg Nesterov <[email protected]>
> > > > Linus Torvalds <[email protected]>
> > > > Paul E. McKenney <[email protected]>
> > > > Patch : http://lkml.org/lkml/2008/5/28/16
> > >
> > > What happened with this issue?
> >
> > The patch listed above works for me, passes rcutorture, &c. However,
> > I never have been able to reproduce the original problem, so cannot say
> > whether it qualifies as a fix.
>
> I doubt very much RCU was the reason of this problem.
Although I very much appreciate your confidence in my code, it is new
code, so therefore under suspicion.
> Alexey, how did you trigger this problem?
One of them involved running LTP while doing 170 kernel builds in
parallel.
Thanx, Paul
On Sat, Jun 14, 2008 at 11:12:12AM -0700, Paul E. McKenney wrote:
> On Sat, Jun 14, 2008 at 06:58:39PM +0400, Oleg Nesterov wrote:
> > On 06/14, Paul E. McKenney wrote:
> > >
> > > On Fri, Jun 13, 2008 at 04:52:55PM +0300, Adrian Bunk wrote:
> > > > On Sat, Jun 07, 2008 at 10:42:57PM +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.
> > > > >
> > > > >
> > > > > 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 (12 days old)
> > > > > References : http://lkml.org/lkml/2008/5/27/9
> > > > > Handled-By : Oleg Nesterov <[email protected]>
> > > > > Linus Torvalds <[email protected]>
> > > > > Paul E. McKenney <[email protected]>
> > > > > Patch : http://lkml.org/lkml/2008/5/28/16
> > > >
> > > > What happened with this issue?
> > >
> > > The patch listed above works for me, passes rcutorture, &c. However,
> > > I never have been able to reproduce the original problem, so cannot say
> > > whether it qualifies as a fix.
> >
> > I doubt very much RCU was the reason of this problem.
>
> Although I very much appreciate your confidence in my code, it is new
> code, so therefore under suspicion.
>
> > Alexey, how did you trigger this problem?
>
> One of them involved running LTP while doing 170 kernel builds in
> parallel.
My gut feeling is that find_pid_ns oops, __d_lookup oops and
__call_for_each_cic oops are the same bug.
And rcutorture failures I've mentioned to Paul privately.
Oleg, debugging you've posted never triggered.
kerneloops suggests that I'm alone. :-(
On Sat, Jun 14, 2008 at 11:43:38PM +0400, Alexey Dobriyan wrote:
> On Sat, Jun 14, 2008 at 11:12:12AM -0700, Paul E. McKenney wrote:
> > On Sat, Jun 14, 2008 at 06:58:39PM +0400, Oleg Nesterov wrote:
> > > On 06/14, Paul E. McKenney wrote:
> > > >
> > > > On Fri, Jun 13, 2008 at 04:52:55PM +0300, Adrian Bunk wrote:
> > > > > On Sat, Jun 07, 2008 at 10:42:57PM +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.
> > > > > >
> > > > > >
> > > > > > 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 (12 days old)
> > > > > > References : http://lkml.org/lkml/2008/5/27/9
> > > > > > Handled-By : Oleg Nesterov <[email protected]>
> > > > > > Linus Torvalds <[email protected]>
> > > > > > Paul E. McKenney <[email protected]>
> > > > > > Patch : http://lkml.org/lkml/2008/5/28/16
> > > > >
> > > > > What happened with this issue?
> > > >
> > > > The patch listed above works for me, passes rcutorture, &c. However,
> > > > I never have been able to reproduce the original problem, so cannot say
> > > > whether it qualifies as a fix.
> > >
> > > I doubt very much RCU was the reason of this problem.
> >
> > Although I very much appreciate your confidence in my code, it is new
> > code, so therefore under suspicion.
> >
> > > Alexey, how did you trigger this problem?
> >
> > One of them involved running LTP while doing 170 kernel builds in
> > parallel.
>
> My gut feeling is that find_pid_ns oops, __d_lookup oops and
> __call_for_each_cic oops are the same bug.
>
> And rcutorture failures I've mentioned to Paul privately.
Yep, running rcutorture in parallel with LTP, which didn't reproduce
for me either.
Did the patch at http://lkml.org/lkml/2008/5/28/16 help?
> Oleg, debugging you've posted never triggered.
>
> kerneloops suggests that I'm alone. :-(
Assuming that the above patch didn't help... As a desperation measure,
I could suggest the following patch.
Signed-off-by: Paul E. McKenney <[email protected]>
---
rcupreempt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -urpNa -X dontdiff linux-2.6.26-rc4/kernel/rcupreempt.c linux-2.6.26-rc4-alexey/kernel/rcupreempt.c
--- linux-2.6.26-rc4/kernel/rcupreempt.c 2008-05-30 04:39:01.000000000 -0700
+++ linux-2.6.26-rc4-alexey/kernel/rcupreempt.c 2008-06-14 20:24:53.000000000 -0700
@@ -77,7 +77,7 @@
*
* GP in GP_STAGES stands for Grace Period ;)
*/
-#define GP_STAGES 2
+#define GP_STAGES 3
struct rcu_data {
spinlock_t lock; /* Protect rcu_data fields. */
long completed; /* Number of last completed batch. */
On Sat, Jun 14, 2008 at 12:20 AM, Adrian Bunk <[email protected]> wrote:
>
> What is the output of "grep RTC_ .config" on your old .config?
Here it is:
# CONFIG_HPET_RTC_IRQ is not set
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
# CONFIG_RTC_DEBUG is not set
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
# CONFIG_RTC_DRV_TEST is not set
# CONFIG_RTC_DRV_CMOS is not set
# CONFIG_RTC_DRV_DS1511 is not set
# CONFIG_RTC_DRV_DS1553 is not set
# CONFIG_RTC_DRV_DS1742 is not set
# CONFIG_RTC_DRV_STK17TA8 is not set
# CONFIG_RTC_DRV_M48T86 is not set
# CONFIG_RTC_DRV_M48T59 is not set
# CONFIG_RTC_DRV_V3020 is not set
Do note that my 2.6.25 kernel was from Gentoo but none of the patches
there seem related to RTC.
Lior.
On Sat, Jun 14, 2008 at 08:30:01PM -0700, Paul E. McKenney wrote:
> On Sat, Jun 14, 2008 at 11:43:38PM +0400, Alexey Dobriyan wrote:
> > On Sat, Jun 14, 2008 at 11:12:12AM -0700, Paul E. McKenney wrote:
> > > On Sat, Jun 14, 2008 at 06:58:39PM +0400, Oleg Nesterov wrote:
> > > > On 06/14, Paul E. McKenney wrote:
> > > > >
> > > > > On Fri, Jun 13, 2008 at 04:52:55PM +0300, Adrian Bunk wrote:
> > > > > > On Sat, Jun 07, 2008 at 10:42:57PM +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.
> > > > > > >
> > > > > > >
> > > > > > > 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 (12 days old)
> > > > > > > References : http://lkml.org/lkml/2008/5/27/9
> > > > > > > Handled-By : Oleg Nesterov <[email protected]>
> > > > > > > Linus Torvalds <[email protected]>
> > > > > > > Paul E. McKenney <[email protected]>
> > > > > > > Patch : http://lkml.org/lkml/2008/5/28/16
> > > > > >
> > > > > > What happened with this issue?
> > > > >
> > > > > The patch listed above works for me, passes rcutorture, &c. However,
> > > > > I never have been able to reproduce the original problem, so cannot say
> > > > > whether it qualifies as a fix.
> > > >
> > > > I doubt very much RCU was the reason of this problem.
> > >
> > > Although I very much appreciate your confidence in my code, it is new
> > > code, so therefore under suspicion.
> > >
> > > > Alexey, how did you trigger this problem?
> > >
> > > One of them involved running LTP while doing 170 kernel builds in
> > > parallel.
> >
> > My gut feeling is that find_pid_ns oops, __d_lookup oops and
> > __call_for_each_cic oops are the same bug.
> >
> > And rcutorture failures I've mentioned to Paul privately.
>
> Yep, running rcutorture in parallel with LTP, which didn't reproduce
> for me either.
>
> Did the patch at http://lkml.org/lkml/2008/5/28/16 help?
>
> > Oleg, debugging you've posted never triggered.
> >
> > kerneloops suggests that I'm alone. :-(
>
> Assuming that the above patch didn't help... As a desperation measure,
> I could suggest the following patch.
> --- linux-2.6.26-rc4/kernel/rcupreempt.c
> +++ linux-2.6.26-rc4-alexey/kernel/rcupreempt.c
> @@ -77,7 +77,7 @@
> *
> * GP in GP_STAGES stands for Grace Period ;)
> */
> -#define GP_STAGES 2
> +#define GP_STAGES 3
> struct rcu_data {
> spinlock_t lock; /* Protect rcu_data fields. */
> long completed; /* Number of last completed batch. */
Both patches (independently) do not help with rcutortures failures:
[ 58.968404] rcu-torture:--- Start of test: nreaders=4 nfakewriters=4 stat_interval=0 verbose=0 test_no_idle_hz=0 shuffle_interval = 5
[ 159.044524] rcu-torture: rtc: 0000000000000000 ver: 53859 tfle: 0 rta: 53859 rtaf: 18 rtf: 53797 rtmbe: 0
[ 159.044527] rcu-torture: !!! Reader Pipe: 65565142 4275 1 0 0 0 0 0 0 0 0
[ 159.044529] rcu-torture: Reader Batch: 65564196 5207 7 3 1 1 0 1 1 0 1
[ 159.044530] rcu-torture: Free-Block Circulation: 53858 53853 53846 53843 53834 53825 53816 53808 53803 53797 0
[ 159.044976] rcu-torture:--- End of test: FAILURE: nreaders=4 nfakewriters=4 stat_interval=0 verbose=0 test_no_idle_hz=0 shuffle_interval = 5
On Sun, Jun 15, 2008 at 08:21:50PM +0400, Alexey Dobriyan wrote:
> On Sat, Jun 14, 2008 at 08:30:01PM -0700, Paul E. McKenney wrote:
> > On Sat, Jun 14, 2008 at 11:43:38PM +0400, Alexey Dobriyan wrote:
> > > On Sat, Jun 14, 2008 at 11:12:12AM -0700, Paul E. McKenney wrote:
> > > > On Sat, Jun 14, 2008 at 06:58:39PM +0400, Oleg Nesterov wrote:
> > > > > On 06/14, Paul E. McKenney wrote:
> > > > > >
> > > > > > On Fri, Jun 13, 2008 at 04:52:55PM +0300, Adrian Bunk wrote:
> > > > > > > On Sat, Jun 07, 2008 at 10:42:57PM +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.
> > > > > > > >
> > > > > > > >
> > > > > > > > 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 (12 days old)
> > > > > > > > References : http://lkml.org/lkml/2008/5/27/9
> > > > > > > > Handled-By : Oleg Nesterov <[email protected]>
> > > > > > > > Linus Torvalds <[email protected]>
> > > > > > > > Paul E. McKenney <[email protected]>
> > > > > > > > Patch : http://lkml.org/lkml/2008/5/28/16
> > > > > > >
> > > > > > > What happened with this issue?
> > > > > >
> > > > > > The patch listed above works for me, passes rcutorture, &c. However,
> > > > > > I never have been able to reproduce the original problem, so cannot say
> > > > > > whether it qualifies as a fix.
> > > > >
> > > > > I doubt very much RCU was the reason of this problem.
> > > >
> > > > Although I very much appreciate your confidence in my code, it is new
> > > > code, so therefore under suspicion.
> > > >
> > > > > Alexey, how did you trigger this problem?
> > > >
> > > > One of them involved running LTP while doing 170 kernel builds in
> > > > parallel.
> > >
> > > My gut feeling is that find_pid_ns oops, __d_lookup oops and
> > > __call_for_each_cic oops are the same bug.
> > >
> > > And rcutorture failures I've mentioned to Paul privately.
> >
> > Yep, running rcutorture in parallel with LTP, which didn't reproduce
> > for me either.
> >
> > Did the patch at http://lkml.org/lkml/2008/5/28/16 help?
> >
> > > Oleg, debugging you've posted never triggered.
> > >
> > > kerneloops suggests that I'm alone. :-(
> >
> > Assuming that the above patch didn't help... As a desperation measure,
> > I could suggest the following patch.
>
> > --- linux-2.6.26-rc4/kernel/rcupreempt.c
> > +++ linux-2.6.26-rc4-alexey/kernel/rcupreempt.c
> > @@ -77,7 +77,7 @@
> > *
> > * GP in GP_STAGES stands for Grace Period ;)
> > */
> > -#define GP_STAGES 2
> > +#define GP_STAGES 3
> > struct rcu_data {
> > spinlock_t lock; /* Protect rcu_data fields. */
> > long completed; /* Number of last completed batch. */
>
> Both patches (independently) do not help with rcutortures failures:
>
> [ 58.968404] rcu-torture:--- Start of test: nreaders=4 nfakewriters=4 stat_interval=0 verbose=0 test_no_idle_hz=0 shuffle_interval = 5
> [ 159.044524] rcu-torture: rtc: 0000000000000000 ver: 53859 tfle: 0 rta: 53859 rtaf: 18 rtf: 53797 rtmbe: 0
> [ 159.044527] rcu-torture: !!! Reader Pipe: 65565142 4275 1 0 0 0 0 0 0 0 0
> [ 159.044529] rcu-torture: Reader Batch: 65564196 5207 7 3 1 1 0 1 1 0 1
> [ 159.044530] rcu-torture: Free-Block Circulation: 53858 53853 53846 53843 53834 53825 53816 53808 53803 53797 0
> [ 159.044976] rcu-torture:--- End of test: FAILURE: nreaders=4 nfakewriters=4 stat_interval=0 verbose=0 test_no_idle_hz=0 shuffle_interval = 5
And the repeat-by is simply running LTP in parallel with rcutorture?
This is a one-hour run of rcutorture or thereabouts?
Thanx, Paul
On Sun, 15 Jun 2008, Paul E. McKenney wrote:
> >
> > Both patches (independently) do not help with rcutortures failures:
> >
> > [ 58.968404] rcu-torture:--- Start of test: nreaders=4 nfakewriters=4 stat_interval=0 verbose=0 test_no_idle_hz=0 shuffle_interval = 5
> > [ 159.044524] rcu-torture: rtc: 0000000000000000 ver: 53859 tfle: 0 rta: 53859 rtaf: 18 rtf: 53797 rtmbe: 0
> > [ 159.044527] rcu-torture: !!! Reader Pipe: 65565142 4275 1 0 0 0 0 0 0 0 0
> > [ 159.044529] rcu-torture: Reader Batch: 65564196 5207 7 3 1 1 0 1 1 0 1
> > [ 159.044530] rcu-torture: Free-Block Circulation: 53858 53853 53846 53843 53834 53825 53816 53808 53803 53797 0
> > [ 159.044976] rcu-torture:--- End of test: FAILURE: nreaders=4 nfakewriters=4 stat_interval=0 verbose=0 test_no_idle_hz=0 shuffle_interval = 5
>
> And the repeat-by is simply running LTP in parallel with rcutorture?
> This is a one-hour run of rcutorture or thereabouts?
Should we mark PREEMPT_RCU as BROKEN for now? I don't know if anybody
really enables it, but it might be a good idea to make sure people don't
do so thinking it's good..
Linus
On Sun, Jun 15, 2008 at 11:17:10AM -0700, Paul E. McKenney wrote:
> On Sun, Jun 15, 2008 at 08:21:50PM +0400, Alexey Dobriyan wrote:
> > On Sat, Jun 14, 2008 at 08:30:01PM -0700, Paul E. McKenney wrote:
> > > On Sat, Jun 14, 2008 at 11:43:38PM +0400, Alexey Dobriyan wrote:
> > > > On Sat, Jun 14, 2008 at 11:12:12AM -0700, Paul E. McKenney wrote:
> > > > > On Sat, Jun 14, 2008 at 06:58:39PM +0400, Oleg Nesterov wrote:
> > > > > > On 06/14, Paul E. McKenney wrote:
> > > > > > >
> > > > > > > On Fri, Jun 13, 2008 at 04:52:55PM +0300, Adrian Bunk wrote:
> > > > > > > > On Sat, Jun 07, 2008 at 10:42:57PM +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.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > 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 (12 days old)
> > > > > > > > > References : http://lkml.org/lkml/2008/5/27/9
> > > > > > > > > Handled-By : Oleg Nesterov <[email protected]>
> > > > > > > > > Linus Torvalds <[email protected]>
> > > > > > > > > Paul E. McKenney <[email protected]>
> > > > > > > > > Patch : http://lkml.org/lkml/2008/5/28/16
> > > > > > > >
> > > > > > > > What happened with this issue?
> > > > > > >
> > > > > > > The patch listed above works for me, passes rcutorture, &c. However,
> > > > > > > I never have been able to reproduce the original problem, so cannot say
> > > > > > > whether it qualifies as a fix.
> > > > > >
> > > > > > I doubt very much RCU was the reason of this problem.
> > > > >
> > > > > Although I very much appreciate your confidence in my code, it is new
> > > > > code, so therefore under suspicion.
> > > > >
> > > > > > Alexey, how did you trigger this problem?
> > > > >
> > > > > One of them involved running LTP while doing 170 kernel builds in
> > > > > parallel.
> > > >
> > > > My gut feeling is that find_pid_ns oops, __d_lookup oops and
> > > > __call_for_each_cic oops are the same bug.
> > > >
> > > > And rcutorture failures I've mentioned to Paul privately.
> > >
> > > Yep, running rcutorture in parallel with LTP, which didn't reproduce
> > > for me either.
> > >
> > > Did the patch at http://lkml.org/lkml/2008/5/28/16 help?
> > >
> > > > Oleg, debugging you've posted never triggered.
> > > >
> > > > kerneloops suggests that I'm alone. :-(
> > >
> > > Assuming that the above patch didn't help... As a desperation measure,
> > > I could suggest the following patch.
> >
> > > --- linux-2.6.26-rc4/kernel/rcupreempt.c
> > > +++ linux-2.6.26-rc4-alexey/kernel/rcupreempt.c
> > > @@ -77,7 +77,7 @@
> > > *
> > > * GP in GP_STAGES stands for Grace Period ;)
> > > */
> > > -#define GP_STAGES 2
> > > +#define GP_STAGES 3
> > > struct rcu_data {
> > > spinlock_t lock; /* Protect rcu_data fields. */
> > > long completed; /* Number of last completed batch. */
> >
> > Both patches (independently) do not help with rcutortures failures:
> >
> > [ 58.968404] rcu-torture:--- Start of test: nreaders=4 nfakewriters=4 stat_interval=0 verbose=0 test_no_idle_hz=0 shuffle_interval = 5
> > [ 159.044524] rcu-torture: rtc: 0000000000000000 ver: 53859 tfle: 0 rta: 53859 rtaf: 18 rtf: 53797 rtmbe: 0
> > [ 159.044527] rcu-torture: !!! Reader Pipe: 65565142 4275 1 0 0 0 0 0 0 0 0
> > [ 159.044529] rcu-torture: Reader Batch: 65564196 5207 7 3 1 1 0 1 1 0 1
> > [ 159.044530] rcu-torture: Free-Block Circulation: 53858 53853 53846 53843 53834 53825 53816 53808 53803 53797 0
> > [ 159.044976] rcu-torture:--- End of test: FAILURE: nreaders=4 nfakewriters=4 stat_interval=0 verbose=0 test_no_idle_hz=0 shuffle_interval = 5
>
> And the repeat-by is simply running LTP in parallel with rcutorture?
> This is a one-hour run of rcutorture or thereabouts?
I also tried running LTP in parallel with rcutorture on POWER, and I
cannot reproduce on that platform either.
Thanx, Paul
On Sun, Jun 15, 2008 at 01:32:48PM -0700, Linus Torvalds wrote:
>
>
> On Sun, 15 Jun 2008, Paul E. McKenney wrote:
> > >
> > > Both patches (independently) do not help with rcutortures failures:
> > >
> > > [ 58.968404] rcu-torture:--- Start of test: nreaders=4 nfakewriters=4 stat_interval=0 verbose=0 test_no_idle_hz=0 shuffle_interval = 5
> > > [ 159.044524] rcu-torture: rtc: 0000000000000000 ver: 53859 tfle: 0 rta: 53859 rtaf: 18 rtf: 53797 rtmbe: 0
> > > [ 159.044527] rcu-torture: !!! Reader Pipe: 65565142 4275 1 0 0 0 0 0 0 0 0
> > > [ 159.044529] rcu-torture: Reader Batch: 65564196 5207 7 3 1 1 0 1 1 0 1
> > > [ 159.044530] rcu-torture: Free-Block Circulation: 53858 53853 53846 53843 53834 53825 53816 53808 53803 53797 0
> > > [ 159.044976] rcu-torture:--- End of test: FAILURE: nreaders=4 nfakewriters=4 stat_interval=0 verbose=0 test_no_idle_hz=0 shuffle_interval = 5
> >
> > And the repeat-by is simply running LTP in parallel with rcutorture?
> > This is a one-hour run of rcutorture or thereabouts?
>
> Should we mark PREEMPT_RCU as BROKEN for now? I don't know if anybody
> really enables it, but it might be a good idea to make sure people don't
> do so thinking it's good..
If that is the right thing to do. I would feel better about it if I
could reproduce the failure.
Thanx, Paul
On Sun, 15 Jun 2008, Paul E. McKenney wrote:
>
> If that is the right thing to do. I would feel better about it if I
> could reproduce the failure.
Is there some configuration thing that might make it happen for Alexey but
not for you? The only obvious one is the normal PREEMPT thing, but
PREEMPT_RCU obviously depends on that, so there must be something else.
CONFIG_SMP? CONFIG_NO_HZ? CONFIG_[RT|FAIR]_GROUP_SCHED? There's a number
of config options that change scheduling details..
Linus
On Sun, Jun 15, 2008 at 11:15:23AM +0300, Lior Dotan wrote:
> On Sat, Jun 14, 2008 at 12:20 AM, Adrian Bunk <[email protected]> wrote:
> >
> > What is the output of "grep RTC_ .config" on your old .config?
>
> Here it is:
Thanks.
>...
> CONFIG_RTC_CLASS=y
>...
> # CONFIG_RTC_DRV_CMOS is not set
>...
That means the support for the PC RTC is disabled.
Honestly, I do not think we can handle all possible misconfigurations
when switching to the new RTC drivers automatically.
> Lior.
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 Sun, Jun 15, 2008 at 04:38:24PM -0700, Linus Torvalds wrote:
> On Sun, 15 Jun 2008, Paul E. McKenney wrote:
> >
> > If that is the right thing to do. I would feel better about it if I
> > could reproduce the failure.
>
> Is there some configuration thing that might make it happen for Alexey but
> not for you? The only obvious one is the normal PREEMPT thing, but
> PREEMPT_RCU obviously depends on that, so there must be something else.
>
> CONFIG_SMP? CONFIG_NO_HZ? CONFIG_[RT|FAIR]_GROUP_SCHED? There's a number
> of config options that change scheduling details..
The only way I can "fix" rcutorture here is SMP=n (not maxcpus=1!).
Among things tried and do not matter are NO_HZ, HIGH_RES_TIMERS, turning off
debugging options (one by one and in bulk), DEBUG_PER_CPU_MAPS, HZ tweaks,
SCHED_MC.
All of this doesn't help, but SMP=n does.
On Mon, Jun 16, 2008 at 07:01:54AM +0400, Alexey Dobriyan wrote:
> On Sun, Jun 15, 2008 at 04:38:24PM -0700, Linus Torvalds wrote:
> > On Sun, 15 Jun 2008, Paul E. McKenney wrote:
> > >
> > > If that is the right thing to do. I would feel better about it if I
> > > could reproduce the failure.
> >
> > Is there some configuration thing that might make it happen for Alexey but
> > not for you? The only obvious one is the normal PREEMPT thing, but
> > PREEMPT_RCU obviously depends on that, so there must be something else.
> >
> > CONFIG_SMP? CONFIG_NO_HZ? CONFIG_[RT|FAIR]_GROUP_SCHED? There's a number
> > of config options that change scheduling details..
>
> The only way I can "fix" rcutorture here is SMP=n (not maxcpus=1!).
I am running SMP=y without seeing the problem.
> Among things tried and do not matter are NO_HZ, HIGH_RES_TIMERS, turning off
> debugging options (one by one and in bulk), DEBUG_PER_CPU_MAPS, HZ tweaks,
> SCHED_MC.
>
> All of this doesn't help, but SMP=n does.
Attached is the compressed config file I used for a run on a POWER
machine. I have used similar config files for x86. For this run, I built
LTP, installed it, started rcutorture, ran LTP, then ended rcutorture.
The only other thing I can think of is that Alexey's machines are
somehow managing to nest NMIs or something. I can produce a fix for
that, but have no way of testing it.
Thoughts?
Thanx, Paul
On Sun, Jun 15, 2008 at 08:31:26PM -0700, Paul E. McKenney wrote:
> On Mon, Jun 16, 2008 at 07:01:54AM +0400, Alexey Dobriyan wrote:
> > On Sun, Jun 15, 2008 at 04:38:24PM -0700, Linus Torvalds wrote:
> > > On Sun, 15 Jun 2008, Paul E. McKenney wrote:
> > > >
> > > > If that is the right thing to do. I would feel better about it if I
> > > > could reproduce the failure.
> > >
> > > Is there some configuration thing that might make it happen for Alexey but
> > > not for you? The only obvious one is the normal PREEMPT thing, but
> > > PREEMPT_RCU obviously depends on that, so there must be something else.
> > >
> > > CONFIG_SMP? CONFIG_NO_HZ? CONFIG_[RT|FAIR]_GROUP_SCHED? There's a number
> > > of config options that change scheduling details..
> >
> > The only way I can "fix" rcutorture here is SMP=n (not maxcpus=1!).
>
> I am running SMP=y without seeing the problem.
>
> > Among things tried and do not matter are NO_HZ, HIGH_RES_TIMERS, turning off
> > debugging options (one by one and in bulk), DEBUG_PER_CPU_MAPS, HZ tweaks,
> > SCHED_MC.
> >
> > All of this doesn't help, but SMP=n does.
>
> Attached is the compressed config file I used for a run on a POWER
> machine. I have used similar config files for x86. For this run, I built
> LTP, installed it, started rcutorture, ran LTP, then ended rcutorture.
>
> The only other thing I can think of is that Alexey's machines are
> somehow managing to nest NMIs or something. I can produce a fix for
> that, but have no way of testing it.
No NMIs here according to /proc/interrupts .
CPU0 CPU1
0: 42 0 IO-APIC-edge timer
1: 8 0 IO-APIC-edge i8042
8: 1 0 IO-APIC-edge rtc
9: 0 0 IO-APIC-fasteoi acpi
16: 0 0 IO-APIC-fasteoi ahci, uhci_hcd:usb1
17: 35 0 IO-APIC-fasteoi pata_jmicron, uhci_hcd:usb2
18: 0 0 IO-APIC-fasteoi ehci_hcd:usb3, uhci_hcd:usb6
19: 6238 0 IO-APIC-fasteoi ata_piix, ata_piix, uhci_hcd:usb5
22: 278 0 IO-APIC-fasteoi HDA Intel
23: 2802 0 IO-APIC-fasteoi uhci_hcd:usb4, ehci_hcd:usb7, eth1
319: 5126 0 PCI-MSI-edge eth0
NMI: 0 0 Non-maskable interrupts
LOC: 66777 66036 Local timer interrupts
RES: 3031 3403 Rescheduling interrupts
CAL: 17 62 function call interrupts
TLB: 671 900 TLB shootdowns
TRM: 0 0 Thermal event interrupts
THR: 0 0 Threshold APIC interrupts
SPU: 0 0 Spurious interrupts
ERR: 0
On Mon, Jun 16, 2008 at 3:24 AM, Adrian Bunk <[email protected]> wrote:
> On Sun, Jun 15, 2008 at 11:15:23AM +0300, Lior Dotan wrote:
>> On Sat, Jun 14, 2008 at 12:20 AM, Adrian Bunk <[email protected]> wrote:
>> >
>> > What is the output of "grep RTC_ .config" on your old .config?
>>
>> Here it is:
>
> Thanks.
>
>>...
>> CONFIG_RTC_CLASS=y
>>...
>> # CONFIG_RTC_DRV_CMOS is not set
>>...
>
> That means the support for the PC RTC is disabled.
>
> Honestly, I do not think we can handle all possible misconfigurations
> when switching to the new RTC drivers automatically.
In that case my configuration was indeed bogus and this bug can be closed.
> cu
> Adrian
>
Cheers,
Lior.
On Mon, Jun 16, 2008 at 5:01 AM, Alexey Dobriyan <[email protected]> wrote:
> On Sun, Jun 15, 2008 at 04:38:24PM -0700, Linus Torvalds wrote:
>> On Sun, 15 Jun 2008, Paul E. McKenney wrote:
>> >
>> > If that is the right thing to do. I would feel better about it if I
>> > could reproduce the failure.
>>
>> Is there some configuration thing that might make it happen for Alexey but
>> not for you? The only obvious one is the normal PREEMPT thing, but
>> PREEMPT_RCU obviously depends on that, so there must be something else.
>>
>> CONFIG_SMP? CONFIG_NO_HZ? CONFIG_[RT|FAIR]_GROUP_SCHED? There's a number
>> of config options that change scheduling details..
>
> The only way I can "fix" rcutorture here is SMP=n (not maxcpus=1!).
>
> Among things tried and do not matter are NO_HZ, HIGH_RES_TIMERS, turning off
> debugging options (one by one and in bulk), DEBUG_PER_CPU_MAPS, HZ tweaks,
> SCHED_MC.
>
> All of this doesn't help, but SMP=n does.
Maybe this is a stupid suggestion, but SLUB _is_ involved here (in
poisoning the object when it is freed). Do you have SLUB_DEBUG_ON=y or
did you check whether it matters if you have these options on or off?
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
On Mon, Jun 16, 2008 at 07:46:59AM +0400, Alexey Dobriyan wrote:
> On Sun, Jun 15, 2008 at 08:31:26PM -0700, Paul E. McKenney wrote:
> > On Mon, Jun 16, 2008 at 07:01:54AM +0400, Alexey Dobriyan wrote:
> > > On Sun, Jun 15, 2008 at 04:38:24PM -0700, Linus Torvalds wrote:
> > > > On Sun, 15 Jun 2008, Paul E. McKenney wrote:
> > > > >
> > > > > If that is the right thing to do. I would feel better about it if I
> > > > > could reproduce the failure.
> > > >
> > > > Is there some configuration thing that might make it happen for Alexey but
> > > > not for you? The only obvious one is the normal PREEMPT thing, but
> > > > PREEMPT_RCU obviously depends on that, so there must be something else.
> > > >
> > > > CONFIG_SMP? CONFIG_NO_HZ? CONFIG_[RT|FAIR]_GROUP_SCHED? There's a number
> > > > of config options that change scheduling details..
> > >
> > > The only way I can "fix" rcutorture here is SMP=n (not maxcpus=1!).
> >
> > I am running SMP=y without seeing the problem.
> >
> > > Among things tried and do not matter are NO_HZ, HIGH_RES_TIMERS, turning off
> > > debugging options (one by one and in bulk), DEBUG_PER_CPU_MAPS, HZ tweaks,
> > > SCHED_MC.
> > >
> > > All of this doesn't help, but SMP=n does.
> >
> > Attached is the compressed config file I used for a run on a POWER
> > machine. I have used similar config files for x86. For this run, I built
> > LTP, installed it, started rcutorture, ran LTP, then ended rcutorture.
> >
> > The only other thing I can think of is that Alexey's machines are
> > somehow managing to nest NMIs or something. I can produce a fix for
> > that, but have no way of testing it.
>
> No NMIs here according to /proc/interrupts .
>
> CPU0 CPU1
> 0: 42 0 IO-APIC-edge timer
> 1: 8 0 IO-APIC-edge i8042
> 8: 1 0 IO-APIC-edge rtc
> 9: 0 0 IO-APIC-fasteoi acpi
> 16: 0 0 IO-APIC-fasteoi ahci, uhci_hcd:usb1
> 17: 35 0 IO-APIC-fasteoi pata_jmicron, uhci_hcd:usb2
> 18: 0 0 IO-APIC-fasteoi ehci_hcd:usb3, uhci_hcd:usb6
> 19: 6238 0 IO-APIC-fasteoi ata_piix, ata_piix, uhci_hcd:usb5
> 22: 278 0 IO-APIC-fasteoi HDA Intel
> 23: 2802 0 IO-APIC-fasteoi uhci_hcd:usb4, ehci_hcd:usb7, eth1
> 319: 5126 0 PCI-MSI-edge eth0
> NMI: 0 0 Non-maskable interrupts
> LOC: 66777 66036 Local timer interrupts
> RES: 3031 3403 Rescheduling interrupts
> CAL: 17 62 function call interrupts
> TLB: 671 900 TLB shootdowns
> TRM: 0 0 Thermal event interrupts
> THR: 0 0 Threshold APIC interrupts
> SPU: 0 0 Spurious interrupts
> ERR: 0
OK, thank you for the information. Looking elsewhere...
Thanx, Paul
[rcutorture failures with PREEMPT_RCU]
Status update:
* bug is reproduced on another box with the very same symptoms:
SMP=y, maxcpus=1 kernel occasionally fails, SMP=n is fine.
Also Core 2 Duo, x86_64 [1]
Race is wide -- 60 seconds of rcutorture is enough.
So far tried without effect:
not doing SMP-alternatives
NO_HZ=y/n
HIGH_RES_TIMERS=y/n
compiling with gcc 3.4.6/4.1.2
different HZ
s/asm/asm volatile/g at percpu asm code and PDA asm code
turning on and off varying CONFIG_DEBUG_ options
CONFIG_DEBUG_PREEMPT
softlockup on/off
making x86_64 cpu_idle() same as 32-bit one wrt rcu_pending et al
sched_setaffinity() in __synchronize_sched doesn't fail
Probably forgot something, but not a single thing that can remove the
bug in SMP=y case.
Using SMP percpu stuff for UP case miserably failed because of some hard
hang due to incomplete patch, but I still leave this for doomsday.
I'm going to try 32-bit setup and reading rcupreempt disassembly with
microscope.
[1]
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz
stepping : 11
cpu MHz : 800.000
cache size : 4096 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm ida
bogomips : 4791.74
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz
stepping : 11
cpu MHz : 800.000
cache size : 4096 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm ida
bogomips : 4787.76
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
-----------------------------------------------------------------------------
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz
stepping : 2
cpu MHz : 2135.041
cache size : 2048 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm
bogomips : 4272.61
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz
stepping : 2
cpu MHz : 2135.041
cache size : 2048 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm
bogomips : 4270.14
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
On Tue, 24 Jun 2008, Alexey Dobriyan wrote:
>
> Status update:
> * bug is reproduced on another box with the very same symptoms:
> SMP=y, maxcpus=1 kernel occasionally fails, SMP=n is fine.
> Also Core 2 Duo, x86_64 [1]
>
> Race is wide -- 60 seconds of rcutorture is enough.
Very odd how you can reproduce it - now on two machines - but it doesn't
seem to happen for others. You've tried different compilers, you've tried
different config options, what the heck is left?
And it's not like Core 2 Duo is an "odd" setup. Even any timer differences
should have been largely flushed out with HIGH_RES_TIMERS=y/n.
Is there *anything* odd about those machines?
Linus
On Tuesday 24 June 2008 11:31, Linus Torvalds wrote:
> On Tue, 24 Jun 2008, Alexey Dobriyan wrote:
> > Status update:
> > * bug is reproduced on another box with the very same symptoms:
> > SMP=y, maxcpus=1 kernel occasionally fails, SMP=n is fine.
> > Also Core 2 Duo, x86_64 [1]
> >
> > Race is wide -- 60 seconds of rcutorture is enough.
>
> Very odd how you can reproduce it - now on two machines - but it doesn't
> seem to happen for others. You've tried different compilers, you've tried
> different config options, what the heck is left?
The PREEMPT_RCU thing? I've reproduced it. It hits lockless pagecache,
but I've also reproduced the same problem in dentry cache shrinking.
I'm sure it is a free-before-grace bug.
I've been using DEBUG_PAGEALLOC to make it easier to spot.
On Tue, Jun 24, 2008 at 04:50:53AM +0400, Alexey Dobriyan wrote:
> [rcutorture failures with PREEMPT_RCU]
>
> Status update:
> * bug is reproduced on another box with the very same symptoms:
> SMP=y, maxcpus=1 kernel occasionally fails, SMP=n is fine.
> Also Core 2 Duo, x86_64 [1]
>
> Race is wide -- 60 seconds of rcutorture is enough.
>
> So far tried without effect:
> not doing SMP-alternatives
> NO_HZ=y/n
> HIGH_RES_TIMERS=y/n
> compiling with gcc 3.4.6/4.1.2
> different HZ
> s/asm/asm volatile/g at percpu asm code and PDA asm code
> turning on and off varying CONFIG_DEBUG_ options
> CONFIG_DEBUG_PREEMPT
> softlockup on/off
> making x86_64 cpu_idle() same as 32-bit one wrt rcu_pending et al
> sched_setaffinity() in __synchronize_sched doesn't fail
>
> Probably forgot something, but not a single thing that can remove the
> bug in SMP=y case.
>
> Using SMP percpu stuff for UP case miserably failed because of some hard
> hang due to incomplete patch, but I still leave this for doomsday.
>
> I'm going to try 32-bit setup and reading rcupreempt disassembly with
> microscope.
Good point!!! Would either you or Nick be willing to send me either
the vmlinux or a disassembly of the relevant portions?
Thanx, Paul
> [1]
>
> processor : 0
> vendor_id : GenuineIntel
> cpu family : 6
> model : 15
> model name : Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz
> stepping : 11
> cpu MHz : 800.000
> cache size : 4096 KB
> physical id : 0
> siblings : 2
> core id : 0
> cpu cores : 2
> fpu : yes
> fpu_exception : yes
> cpuid level : 10
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm ida
> bogomips : 4791.74
> clflush size : 64
> cache_alignment : 64
> address sizes : 36 bits physical, 48 bits virtual
> power management:
>
> processor : 1
> vendor_id : GenuineIntel
> cpu family : 6
> model : 15
> model name : Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz
> stepping : 11
> cpu MHz : 800.000
> cache size : 4096 KB
> physical id : 0
> siblings : 2
> core id : 1
> cpu cores : 2
> fpu : yes
> fpu_exception : yes
> cpuid level : 10
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm ida
> bogomips : 4787.76
> clflush size : 64
> cache_alignment : 64
> address sizes : 36 bits physical, 48 bits virtual
> power management:
> -----------------------------------------------------------------------------
> processor : 0
> vendor_id : GenuineIntel
> cpu family : 6
> model : 15
> model name : Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz
> stepping : 2
> cpu MHz : 2135.041
> cache size : 2048 KB
> physical id : 0
> siblings : 2
> core id : 0
> cpu cores : 2
> fpu : yes
> fpu_exception : yes
> cpuid level : 10
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm
> bogomips : 4272.61
> clflush size : 64
> cache_alignment : 64
> address sizes : 36 bits physical, 48 bits virtual
> power management:
>
> processor : 1
> vendor_id : GenuineIntel
> cpu family : 6
> model : 15
> model name : Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz
> stepping : 2
> cpu MHz : 2135.041
> cache size : 2048 KB
> physical id : 0
> siblings : 2
> core id : 1
> cpu cores : 2
> fpu : yes
> fpu_exception : yes
> cpuid level : 10
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm
> bogomips : 4270.14
> clflush size : 64
> cache_alignment : 64
> address sizes : 36 bits physical, 48 bits virtual
> power management:
>
On Tue, Jun 24, 2008 at 05:04:04AM -0700, Paul E. McKenney wrote:
> On Tue, Jun 24, 2008 at 04:50:53AM +0400, Alexey Dobriyan wrote:
> > [rcutorture failures with PREEMPT_RCU]
> >
> > Status update:
> > * bug is reproduced on another box with the very same symptoms:
> > SMP=y, maxcpus=1 kernel occasionally fails, SMP=n is fine.
This is interesting. The bug occurs on a single CPU, so the bug cannot
involve memory ordering (because CPUs see their own accesses in order)
or preemptions from one CPU to another (as there is but one CPU).
It might involve ordering issues in __rcu_read_lock() or
__rcu_read_unlock(), though the code generated by gcc version 4.1.2 is
ordered correctly on x86.
The code for raw_smp_processor_id() differs in the two cases, but should
give zero in all cases either way, given that there is but one CPU.
Locking goes awayin SMP=n, but the grace-period code disables irqs,
which should act as a good and sufficient lock in the single-CPU case
either way.
> > Also Core 2 Duo, x86_64 [1]
> >
> > Race is wide -- 60 seconds of rcutorture is enough.
This is rcutorture by itself, or in parallel with LTP/kernbench?
(I have mostly been running on 4-CPU boxes without failure either way,
so will try a dual-CPU box.)
Thanx, Paul
> > So far tried without effect:
> > not doing SMP-alternatives
> > NO_HZ=y/n
> > HIGH_RES_TIMERS=y/n
> > compiling with gcc 3.4.6/4.1.2
> > different HZ
> > s/asm/asm volatile/g at percpu asm code and PDA asm code
> > turning on and off varying CONFIG_DEBUG_ options
> > CONFIG_DEBUG_PREEMPT
> > softlockup on/off
> > making x86_64 cpu_idle() same as 32-bit one wrt rcu_pending et al
> > sched_setaffinity() in __synchronize_sched doesn't fail
> >
> > Probably forgot something, but not a single thing that can remove the
> > bug in SMP=y case.
> >
> > Using SMP percpu stuff for UP case miserably failed because of some hard
> > hang due to incomplete patch, but I still leave this for doomsday.
> >
> > I'm going to try 32-bit setup and reading rcupreempt disassembly with
> > microscope.
>
> Good point!!! Would either you or Nick be willing to send me either
> the vmlinux or a disassembly of the relevant portions?
>
> Thanx, Paul
>
> > [1]
> >
> > processor : 0
> > vendor_id : GenuineIntel
> > cpu family : 6
> > model : 15
> > model name : Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz
> > stepping : 11
> > cpu MHz : 800.000
> > cache size : 4096 KB
> > physical id : 0
> > siblings : 2
> > core id : 0
> > cpu cores : 2
> > fpu : yes
> > fpu_exception : yes
> > cpuid level : 10
> > wp : yes
> > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm ida
> > bogomips : 4791.74
> > clflush size : 64
> > cache_alignment : 64
> > address sizes : 36 bits physical, 48 bits virtual
> > power management:
> >
> > processor : 1
> > vendor_id : GenuineIntel
> > cpu family : 6
> > model : 15
> > model name : Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz
> > stepping : 11
> > cpu MHz : 800.000
> > cache size : 4096 KB
> > physical id : 0
> > siblings : 2
> > core id : 1
> > cpu cores : 2
> > fpu : yes
> > fpu_exception : yes
> > cpuid level : 10
> > wp : yes
> > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm ida
> > bogomips : 4787.76
> > clflush size : 64
> > cache_alignment : 64
> > address sizes : 36 bits physical, 48 bits virtual
> > power management:
> > -----------------------------------------------------------------------------
> > processor : 0
> > vendor_id : GenuineIntel
> > cpu family : 6
> > model : 15
> > model name : Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz
> > stepping : 2
> > cpu MHz : 2135.041
> > cache size : 2048 KB
> > physical id : 0
> > siblings : 2
> > core id : 0
> > cpu cores : 2
> > fpu : yes
> > fpu_exception : yes
> > cpuid level : 10
> > wp : yes
> > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm
> > bogomips : 4272.61
> > clflush size : 64
> > cache_alignment : 64
> > address sizes : 36 bits physical, 48 bits virtual
> > power management:
> >
> > processor : 1
> > vendor_id : GenuineIntel
> > cpu family : 6
> > model : 15
> > model name : Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz
> > stepping : 2
> > cpu MHz : 2135.041
> > cache size : 2048 KB
> > physical id : 0
> > siblings : 2
> > core id : 1
> > cpu cores : 2
> > fpu : yes
> > fpu_exception : yes
> > cpuid level : 10
> > wp : yes
> > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm
> > bogomips : 4270.14
> > clflush size : 64
> > cache_alignment : 64
> > address sizes : 36 bits physical, 48 bits virtual
> > power management:
> >
* Paul E. McKenney <[email protected]> wrote:
> > > Also Core 2 Duo, x86_64 [1]
> > >
> > > Race is wide -- 60 seconds of rcutorture is enough.
>
> This is rcutorture by itself, or in parallel with LTP/kernbench?
>
> (I have mostly been running on 4-CPU boxes without failure either way,
> so will try a dual-CPU box.)
FYI, i've been running rcutorture for days on lots of testboxes ranging
all across the x86 spectrum from single CPU, through dual-core, to
dual-socket, dual-socket HT, 8-way and 16-way - both 32-bit and 64-bit
x86.
Not a single failure has been detected in thousands of bootups of random
kernels (rcu-preempt + rcutorture was a frequent combination tested). I
added a WARN_ON() to rcutorture failures so it should show up very
clearly.
This makes me suspect that it might be some special environment issue -
gcc for example. I'm using gcc 4.2.2 on most of the testboxes.
Ingo
On Tue, Jun 24, 2008 at 11:15:47PM +0200, Ingo Molnar wrote:
>
> * Paul E. McKenney <[email protected]> wrote:
>
> > > > Also Core 2 Duo, x86_64 [1]
> > > >
> > > > Race is wide -- 60 seconds of rcutorture is enough.
> >
> > This is rcutorture by itself, or in parallel with LTP/kernbench?
> >
> > (I have mostly been running on 4-CPU boxes without failure either way,
> > so will try a dual-CPU box.)
>
> FYI, i've been running rcutorture for days on lots of testboxes ranging
> all across the x86 spectrum from single CPU, through dual-core, to
> dual-socket, dual-socket HT, 8-way and 16-way - both 32-bit and 64-bit
> x86.
>
> Not a single failure has been detected in thousands of bootups of random
> kernels (rcu-preempt + rcutorture was a frequent combination tested). I
> added a WARN_ON() to rcutorture failures so it should show up very
> clearly.
>
> This makes me suspect that it might be some special environment issue -
> gcc for example. I'm using gcc 4.2.2 on most of the testboxes.
And running rcutorture overnight on an Opteron system (9.7M updates) showed
no failures.
Thanx, Paul
![[permalink]](https://linuxlists.cc/l/1/linux-kernel/permalink/%3CdCRO4tbfLzK.A.GIF.X5vSIB%40albercik%3E){kind=link}