Created attachment 24603 [details] screen_part1.jpg This issue can trigger for example compilation of boost. Appering screenshot. If is needed, can test patches.
Created attachment 24604 [details] screen_part2.jpg
Created attachment 24605 [details] dmesg dmesg, without panic
Created attachment 24606 [details] kernel_config Kernel configuration
and it's regression. Now I work on 2.6.32.3 and no problem.
Switched to email. Please reply to all instead of using the bugzilla interface. > --- Comment #4 from okias <d.okias@gmail.com> 2010-01-22 10:17:25 --- > and it's regression. Now I work on 2.6.32.3 and no problem. That's a really weird one. The system is 50 min up and running and out of the blue it crashes in clockevents_program_event(). This function has been called a couple of thousand times before that point. The only way to crash there is when *dev is pointing into nirwana. dev comes from int tick_program_event(ktime_t expires, int force) { struct clock_event_device *dev = __get_cpu_var(tick_cpu_device).evtdev; according to the callchain. At this point nothing fiddles with tick_cpu_device.evtdev, so I suspect some really nasty memory corruption going on. okias, can you please disable highmem support and verify whether the problem persists ? Thanks, tglx
Okey, I try without highmem soon. 2010/1/25, Thomas Gleixner <tglx@linutronix.de>: > Switched to email. Please reply to all instead of using the bugzilla > interface. > >> --- Comment #4 from okias <d.okias@gmail.com> 2010-01-22 10:17:25 --- >> and it's regression. Now I work on 2.6.32.3 and no problem. > > That's a really weird one. The system is 50 min up and running and out > of the blue it crashes in clockevents_program_event(). This function > has been called a couple of thousand times before that point. > > The only way to crash there is when *dev is pointing into nirwana. dev > comes from > > int tick_program_event(ktime_t expires, int force) > { > struct clock_event_device *dev = > __get_cpu_var(tick_cpu_device).evtdev; > > according to the callchain. At this point nothing fiddles with > tick_cpu_device.evtdev, so I suspect some really nasty memory > corruption going on. > > okias, can you please disable highmem support and verify whether the > problem persists ? > > Thanks, > > tglx >
Lastest git without HIGHMEM look good. If no problems occur, then I try use kernel with HIGHMEM and see what change... 2010/1/25, okias <d.okias@gmail.com>: > Okey, I try without highmem soon. > > 2010/1/25, Thomas Gleixner <tglx@linutronix.de>: >> Switched to email. Please reply to all instead of using the bugzilla >> interface. >> >>> --- Comment #4 from okias <d.okias@gmail.com> 2010-01-22 10:17:25 --- >>> and it's regression. Now I work on 2.6.32.3 and no problem. >> >> That's a really weird one. The system is 50 min up and running and out >> of the blue it crashes in clockevents_program_event(). This function >> has been called a couple of thousand times before that point. >> >> The only way to crash there is when *dev is pointing into nirwana. dev >> comes from >> >> int tick_program_event(ktime_t expires, int force) >> { >> struct clock_event_device *dev = >> __get_cpu_var(tick_cpu_device).evtdev; >> >> according to the callchain. At this point nothing fiddles with >> tick_cpu_device.evtdev, so I suspect some really nasty memory >> corruption going on. >> >> okias, can you please disable highmem support and verify whether the >> problem persists ? >> >> Thanks, >> >> tglx >> > > > -- > Jabber/XMPP: okias@isgeek.info > SIP VoIP: sip:17474537254@proxy01.sipphone.com >
I'm afraid it freezed even without HIGHMEM. I left computer run (compilation KDE 4.3.95) and when I come back, lcd was in dpms mode and led was blinking. So it look like same problem. Maybe without HIGHMEM it takes longer until problem appear. 2010/1/26, okias <d.okias@gmail.com>: > Lastest git without HIGHMEM look good. If no problems occur, then I > try use kernel with HIGHMEM and see what change... > > 2010/1/25, okias <d.okias@gmail.com>: >> Okey, I try without highmem soon. >> >> 2010/1/25, Thomas Gleixner <tglx@linutronix.de>: >>> Switched to email. Please reply to all instead of using the bugzilla >>> interface. >>> >>>> --- Comment #4 from okias <d.okias@gmail.com> 2010-01-22 10:17:25 --- >>>> and it's regression. Now I work on 2.6.32.3 and no problem. >>> >>> That's a really weird one. The system is 50 min up and running and out >>> of the blue it crashes in clockevents_program_event(). This function >>> has been called a couple of thousand times before that point. >>> >>> The only way to crash there is when *dev is pointing into nirwana. dev >>> comes from >>> >>> int tick_program_event(ktime_t expires, int force) >>> { >>> struct clock_event_device *dev = >>> __get_cpu_var(tick_cpu_device).evtdev; >>> >>> according to the callchain. At this point nothing fiddles with >>> tick_cpu_device.evtdev, so I suspect some really nasty memory >>> corruption going on. >>> >>> okias, can you please disable highmem support and verify whether the >>> problem persists ? >>> >>> Thanks, >>> >>> tglx >>> >> >> >> -- >> Jabber/XMPP: okias@isgeek.info >> SIP VoIP: sip:17474537254@proxy01.sipphone.com >> > > > -- > Jabber/XMPP: okias@isgeek.info > SIP VoIP: sip:17474537254@proxy01.sipphone.com >
On Monday 01 February 2010, okias wrote: > Still valid. But reproduction without HIGHMEM is minimal, but still annoying. > > 2010/2/1, Rafael J. Wysocki <rjw@sisk.pl>: > > 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.32. Please verify if it still should be listed and let me know > > (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15076 > > Subject : System panic under load with > clockevents_program_event > > Submitter : okias <d.okias@gmail.com> > > Date : 2010-01-17 13:03 (15 days old)
Is this still a problem on the current mainline kernel (3.2)?
Can't test, no longer using that machine.