RE: 2.6.0-test5: intermittent crash on chvt to X; was console lost to Ctrl+Alt+F$n in 2.6.0-test5

RE: 2.6.0-test5: intermittent crash on chvt to X; was console lost to Ctrl+Alt+F$n in 2.6.0-test5

[Pat LaVarre]

> If it is specific to -test5, post (as tar.bz2)

Definitely not specific to 2.6.0-test5: I have
repeatedly seen 2.6.0-test4 crash this way too.

Whether I have had this vulnerability for days or
weeks or months or years I am not yet sure, I do not
customarily make a point of trying chvt much with each
new kernel.  

Unless I hear otherwise, hopefully within hours, when
next I manage to visit my console in person:

1) I will test to see if the script can crash:

2.6.0-test4 with my near default .config
2.4.22 with my near default .config
2.4.21-xfs Knoppix booted via cd

2) After the reboot following a crash of 2.6.0-test5 I
will sample:

lspci -v
/var/log/dmesg
X version and driver info from /var/log/XFree86.log 
.config

3) I will report back here, attaching (2) as .tar.bz2.

Pat LaVarre



__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Re: 2.6.0-test5: intermittent crash on chvt to X; was console lost to Ctrl+Alt+F$n in 2.6.0-test5

[Pat LaVarre]

[-- Attachment #1: Type: text/plain, Size: 1341 bytes --]


> qestion now is whether this is kernel or X related.

Oh.

> > echo ... | tee -a $log
> > sync
> > sleep $wait
> > chvt ...
> > sleep $wait
>
> the crash may (in your case does) happen later

In repeating those five commands, is there any purpose to the first
sleep?  I left the first sleep in place to match the original, but once
I assume sync leaves no writes unflushed then now I do not see what the
first sleep accomplishes, if anything.

> Have you had this problem with an earlier 2.6 or 2.4 kernel?

Today 2.4.21-xfs Knoppix booted via cd:
in over 75 cycles I saw no crash so I gave up.

Today 2.4.22 with a near default .config:
"in over 75 cycles I saw no crash so I gave up".

Today 2.6.0-test4 with a near default .config:
Counting cycles before crash per boot I saw: 3 2 16 ...

Yester/today 2.6.0-test5 with a near default .config:
"I saw: 1 18 20 20 ... 4 16 ..." 3 ...

> -test5, post (as tar.bz2) ...

After that last -test5 crash I rebooted and then produced the attached
via:

#!/bin/bash
# rm -r chvtx
mkdir chvtx

sudo /sbin/lspci -v >>chvtx/v.lspci
sudo cat /var/log/dmesg >>chvtx/var.log.dmesg
egrep -i 'version|release|driver' /var/log/XFree86.*.log >>chvtx/var.log.XFree86.log
# cp -ip /var/log/XFree86.*.log chvtx/
cp -ip .config chvtx/config

tar -c chvtx | bzip2 -zc >chvtx.2.6.0-test5.tar.bz2

# Pat LaVarre



[-- Attachment #2: chvtx.2.6.0-test5.tar.bz2 --]
[-- Type: application/x-bzip, Size: 12515 bytes --]

2.6.0-test5: intermittent crash on chvt to X; was console lost to Ctrl+Alt+F$n in 2.6.0-test5

[Michael Frank]

> I ended by running the third variant script quoted below. Now my logs
> comfortingly end with 'switching to X'. I presume I'm catching the
> crash in the last sleep $wait.

Makes sense because the crash may (in your case does) happen later 
in the switching sequence at which time the "new" log already made 
it to disk - I'll use your variant from now on ;)

The qestion now is whether this is kernel or X related.
Have you had this problem with an earlier 2.6 or 2.4 kernel?

If it is specific to -test5, post (as tar.bz2)

- lspci -v  
- /var/log/dmesg
- X version and driver info from /var/log/XFree86.log 
- .config

Regards
Michael