1 |
Am Sonntag, 12. Oktober 2008 schrieb Alan McKinnon: |
2 |
> On Sunday 12 October 2008 13:12:20 Alexander Puchmayr wrote: |
3 |
> > > If it's a kernel panic you actually get debugging information on the |
4 |
> > > console. It's just hidden "behind" the X server. Maybe you can |
5 |
> > > reproduce the problem working without X (If you can do your work |
6 |
> > > purely from the VTs) |
7 |
> > |
8 |
> > I've tried, but unfortunately, the X-Driver on my laptop (i965) does |
9 |
> > also seem to have stability problems, after ca an hour it froze using |
10 |
> > 100% cpu-time, unable to kill (nither kill or kill -9 did work). I |
11 |
> > guess it didn't wakeup from DPMS :-( |
12 |
> |
13 |
> Here's a thought: if you have a spare machine, you could ssh in to your |
14 |
> desktop and continue to work normally. The ssh session would be tailing |
15 |
> an appropriate log, so even if the desktop goes south there's a good |
16 |
> chance the error log is visible |
17 |
> |
18 |
> For something more persistent, you could try temporarily sending all logs |
19 |
> to a remote log server. Remote logging is quite efficient, I usually find |
20 |
> the only thing that gets in it's way is a complete instant kernel halt |
21 |
> that brings the whole machine down without warning - this is extremely |
22 |
> rare on production kernels |
23 |
|
24 |
I really doubt that this works, the logger does not have the change to write |
25 |
anything as soon the kernel crashed, neither on a local disk or remote. It |
26 |
seems to be something you called the "instant kernel halt", and I have the |
27 |
luck to mess around with one of these rare cases :-( |
28 |
|
29 |
But to give it a chance, I'm running a "cat /proc/kmsg" on the desktop, |
30 |
started via ssh as you suggested. |
31 |
|
32 |
Alex |