devzero@web.de wrote:This is real hardware, it is a always on desktop MB machine, nothing too weird, right now I am putting 2.6.24.4 on it, and we will see in a few weeks if it does it again. I am getting it fairly consistently, so any ideas of what to turn on, or watch for in the next event would be useful. I did try collect several samples of information from /proc of things that looked useful, the most telling thing I found was that it appeared that in /proc/timer_list now at 7300171087468 nsecs (number was different). was actually looping similar to the time/date and not rising as it should have been, this is a 32 bit on an AMD Sempron(tm) Processor 3400+, it is 64bit capable. I did have files that containing several samples of /proc/timer_list, but apparently the alt-sysrq-s then u before the b failed to save the information or the general state of the machine was just so bad that it did not get written out to disk, the last 2 times I have had this happen, it completely failed to shutdown gracefully and s-u-b at least enabled me to force a reboot without having to go to the machine and power cycle it. From previous data, the shortest time is 14 days 11 hours, and the longest is about 23 days. Roger --
| Greg KH | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg Kroah-Hartman | [PATCH 005/196] Chinese: add translation of SubmittingDrivers |
| Adrian Bunk | [1/6] 2.6.21-rc2: known regressions |
| Paul Jackson | Re: cpuset-remove-sched-domain-hooks-from-cpusets |
git: | |
| Linus Torvalds | Re: [GIT]: Networking |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Andrew Morton | Re: [BUG] New Kernel Bugs |
