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 <bunk@kernel.org> Date : 2008-06-06 09:24 (2 days old) References : http://lkml.org/lkml/2008/6/6/277 Handled-By : Adrian Bunk <bunk@kernel.org> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10872 Subject : x86_64 boot hang when CONFIG_NUMA=n Submitter : Randy Dunlap <randy.dunlap@oracle.com> Date : 2008-06-05 21:50 (3 days old) References : http://marc.info/?l=linux-kernel&amp;m=121270308607116&amp;w=4 Handled-By : Yinghai Lu <yhlu.kernel@gmail.com> 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 <awilliamson@mandriva.com> 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 <liodot@gmail.com> Date : 2008-06-05 15:04 (3 days old) References : ...
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 <adrian.bunk@movial.fi> 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&amp;m=120876451216558&amp;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 <nigel@suspend2.net> 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&amp;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 <parag.warudkar@gmail.com> 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 <peterz@infradead.org> 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 <zdenek.kabelac@gmail.com> 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 <adobriyan@gmail.com> Date : 2008-05-05 09:59 (34 days old) References : http://lkml.org/lkml/2008/5/5/28 Handled-By : Paul E. McKenney <paulmck@linux.vnet.ibm.com> --
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 <vegard.nossum@gmail.com> Date : 2008-05-06 16:09 (33 days old) References : http://marc.info/?l=linux-acpi&amp;m=121009034825514&amp;w=4 Handled-By : Lin Ming <ming.m.lin@intel.com> Ming Lin <ming.m.lin@intel.com> Patch : http://bugzilla.kernel.org/attachment.cgi?id=16199&amp;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 --
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 <lmctlx@gmail.com> Date : 2008-05-08 23:12 (31 days old) References : http://marc.info/?l=linux-kernel&amp;m=121028841527994&amp;w=4 http://lkml.org/lkml/2008/5/12/12 Handled-By : Henrique de Moraes Holschuh <hmh@hmh.eng.br> Patch : http://bugzilla.kernel.org/attachment.cgi?id=16153&amp;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 <len.brown@intel.com> Date : 2008-05-12 20:04 (27 days old) Handled-By : Robert Moore <Robert.Moore@intel.com> --
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 <zdenek.kabelac@gmail.com> 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 <balbir@linux.vnet.ibm.com> Date : 2008-05-14 12:57 (25 days old) References : http://marc.info/?l=linux-kernel&amp;m=121076917429133&amp;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 <maciej.rutecki@gmail.com> Date : 2008-05-16 14:55 (23 days old) References : http://marc.info/?l=linux-kernel&amp;m=121095168003572&amp;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 <justinmattock@gmail.com> Date : 2008-05-16 6:17 (23 days old) References : http://marc.info/?l=linux-kernel&amp;m=121091875711824&amp;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&amp;action=view http://bugzilla.kernel.org/attachment.cgi?id=16365&amp;action=view http://bugzilla.kernel.org/attachment.cgi?id=16364&amp;action=view http://bugzilla.kernel.org/attachment.cgi?id=16365&amp;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 <davej@codemonkey.org.uk> Date : 2008-05-16 12:54 (23 days old) References : http://lkml.org/lkml/2008/5/16/312 Handled-By : Mike Travis <travis@sgi.com> 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 <toralf.foerster@gmx.de> Date : 2008-05-16 17:06 (23 days old) References : http://marc.info/?l=linux-kernel&amp;m=121095777616792&amp;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 <hannes@saeurebad.de> Date : 2008-05-18 2:16 (21 days old) References : http://marc.info/?l=linux-kernel&amp;m=121107706506181&amp;w=4 Handled-By : Alan Cox <alan@lxorguk.ukuu.org.uk> --
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 <rmh3093@gmail.com> Date : 2008-05-19 17:47 (20 days old) References : http://marc.info/?l=linux-pci&amp;m=121121926401755&amp;w=2 Handled-By : Matthew Wilcox <matthew@wil.cx> --
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 --
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 <shahamit@gmail.com> 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 <yanmin_zhang@linux.intel.com> Date : 2008-05-20 8:09 (19 days old) References : http://marc.info/?l=linux-kernel&amp;m=121127121813708&amp;w=2 http://lkml.org/lkml/2008/6/2/10 Handled-By : Mike Galbraith <efault@gmx.de> --
The fingered patchlet and the code it touched were reverted, so I think this is a stale entry. -Mike --
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 <cavokz@gmail.com> Date : 2008-05-22 16:14 (17 days old) References : http://marc.info/?l=linux-kernel&amp;m=121147328028081&amp;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 <rmk+lkml@arm.linux.org.uk> Date : 2008-05-20 7:35 (19 days old) References : http://marc.info/?l=linux-kernel&amp;m=121126931810706&amp;w=2 Handled-By : Javier Herrero <jherrero@hvsistemas.es> Russell King <rmk+lkml@arm.linux.org.uk> --
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 <mingo@elte.hu> Date : 2008-05-24 16:58 (15 days old) References : http://marc.info/?l=linux-kernel&amp;m=121164842212038&amp;w=4 Handled-By : Ingo Molnar <mingo@elte.hu> Patch : http://marc.info/?l=linux-kernel&amp;m=121164842212038&amp;w=4 --
This is fixed (workaround for now) in 2.6.26-rc5. Thanks, Kenji Kaneshige --
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 <adrian.bunk@movial.fi> 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 <Nicolas.Mailhot@LaPoste.net> 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 <m.s.tsirkin@gmail.com> Date : 2008-05-20 22:46 (19 days old) Handled-By : Zhu Yi <yi.zhu@intel.com> Johannes Berg <johannes@sipsolutions.net> 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 <adobriyan@gmail.com> Date : 2008-05-27 09:23 (12 days old) References : http://lkml.org/lkml/2008/5/27/9 Handled-By : Oleg Nesterov <oleg@tv-sign.ru> Linus Torvalds <torvalds@linux-foundation.org> Paul E. McKenney <paulmck@linux.vnet.ibm.com> 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
--
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. --
Although I very much appreciate your confidence in my code, it is new One of them involved running LTP while doing 170 kernel builds in parallel. Thanx, Paul --
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. :-( --
Yep, running rcutorture in parallel with LTP, which didn't reproduce
for me either.
Assuming that the above patch didn't help... As a desperation measure,
I could suggest the following patch.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
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. */
--
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 --
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 --
If that is the right thing to do. I would feel better about it if I could reproduce the failure. Thanx, Paul --
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 --
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. --
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
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 ...
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 --
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. --
Good point!!! Would either you or Nick be willing to send me either the vmlinux or a disassembly of the relevant portions? --
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 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 --
And running rcutorture overnight on an Opteron system (9.7M updates) showed no failures. Thanx, Paul --
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 --
I also tried running LTP in parallel with rcutorture on POWER, and I cannot reproduce on that platform either. Thanx, Paul --
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 <thunder7@xs4all.nl> Date : 2008-05-27 19:33 (12 days old) References : http://marc.info/?l=linux-kernel&amp;m=121191733218735&amp;w=4 Handled-By : Jan Engelhardt <jengelh@medozas.de> Patch : http://marc.info/?l=linux-kernel&amp;m=121199453010047&amp;w=4 --
is upstream 774533b3e86fa52941c79aa80ab3f0cc511bba7f. --
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 <casteyde.christian@free.fr> 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
--
Sure, both issues should have been fixed in 2.6.26-rc5 :) Ivo --
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 <casteyde.christian@free.fr> 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 <justinmattock@gmail.com> Date : 2008-05-27 3:29 (12 days old) References : http://marc.info/?l=linux-kernel&amp;m=121185900618047&amp;w=4 http://lkml.org/lkml/2008/5/31/193 http://lkml.org/lkml/2008/5/31/193 Handled-By : Oliver Neukum <oliver@neukum.org> --
I'm not seeing appletouch react this way after applying the patches. regards; -- Justin P. Mattock --
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 --
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 --
With last week's patch or today's patch? Regards Oliver --
Last weeks patch. regards; -- Justin P. Mattock --
Could you also try today's patch? Regards Oliver --
Sure, where is it located. regards; -- Justin P. Mattock --
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 ...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 --
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 --
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 --
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 <davej@redhat.com> Date : 2008-05-27 19:04 (12 days old) References : http://marc.info/?l=linux-kernel&amp;m=121191548915522&amp;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 <davej@redhat.com> 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 <mingo@elte.hu> Date : 2008-05-26 11:56 (13 days old) References : http://marc.info/?l=linux-kernel&amp;m=121180311931349&amp;w=4 Handled-By : Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> --
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 =&gt; 2.6.26-rc1-git1] Xorg crash with xf86MapVidMem error Submitter : Rufus &amp; Azrael <rufus-azrael@numericable.fr> Date : 2008-05-04 10:24 (35 days old) References : http://lkml.org/lkml/2008/5/4/37 Handled-By : Ingo Molnar <mingo@elte.hu> H. Peter Anvin <hpa@zytor.com> Pallipadi, Venkatesh <venkatesh.pallipadi@intel.com> 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 <elendil@planet.nl> 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 <alejandro.riveira@gmail.com> Date : 2008-05-28 9:50 (11 days old) References : http://marc.info/?l=linux-kernel&amp;m=121196833026310&amp;w=4 Handled-By : Johannes Berg <johannes@sipsolutions.net> Andrew Morton <akpm@linux-foundation.org> Peter Zijlstra <a.p.zijlstra@chello.nl> 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 <casteyde.christian@free.fr> 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 --
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 --
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 <ranma+kernel@tdiedrich.de> Date : 2008-06-01 8:37 (7 days old) References : http://marc.info/?l=linux-kernel&amp;m=121230964032247&amp;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 <dave@linux.vnet.ibm.com> Date : 2008-06-02 22:30 (6 days old) References : http://marc.info/?l=linux-kernel&amp;m=121244588705277&amp;w=4 Handled-By : Avi Kivity <avi@qumranet.com> --
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 <nm127@freemail.hu> Date : 2008-06-03 5:18 (5 days old) References : http://marc.info/?l=linux-kernel&amp;m=121247101601790&amp;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 <bunk@kernel.org> Date : 2008-06-06 09:24 (2 days old) References : http://lkml.org/lkml/2008/6/6/277 Handled-By : Adrian Bunk <bunk@kernel.org> --
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 <bunk@kernel.org> Date : 2008-06-06 09:25 (2 days old) References : http://lkml.org/lkml/2008/6/6/278 Handled-By : Adrian Bunk <bunk@kernel.org> 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 <awilliamson@mandriva.com> 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 <randy.dunlap@oracle.com> Date : 2008-06-05 21:50 (3 days old) References : http://marc.info/?l=linux-kernel&amp;m=121270308607116&amp;w=4 Handled-By : Yinghai Lu <yhlu.kernel@gmail.com> --
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 <liodot@gmail.com> Date : 2008-06-05 15:04 (3 days old) References : http://marc.info/?l=linux-kernel&amp;m=121267834521432&amp;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
--
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. --
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 --
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 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 --
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 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 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 --
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
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 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, 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 --
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 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 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 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 --
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
--
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. --
That means the support for the PC RTC is disabled.
Honestly, I do not think we can handle all possible misconfigurations
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
--
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 <romosan@sycorax.lbl.gov> Date : 2008-06-05 14:47 (3 days old) References : http://marc.info/?l=linux-kernel&amp;m=121267834421414&amp;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 <chris2553@googlemail.com> Date : 2008-06-01 4:15 (7 days old) References : http://marc.info/?l=linux-kernel&amp;m=121229382917834&amp;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 : tosn00j02@sneakemail.com Date : 2008-05-03 05:09 (36 days old) --
