kernel lockup

kernel lockup

[Peter Cordes]

 I'm running 2.4.4, rsynced from the benh tree.  I wanted to adjust my
keyboard key repeat stuff, so I ran (on the console)

bigfoot:~# kbdrate -h
kbdrate: invalid option -- h
Machine check in kernel mode.
Caused by (from SRR1=c9030): Unknown values in msr

 What do I do to debug this?

 The machine is totally locked, not even the SysRQ combination does
anything.  (control+command+power still resets though, since it is handled
in hardware on oldworlds.)

 More details: I'm running a quad PPC604 Mac clone from Daystar (the Genesis
MP).  The top line in /usr/src/linux-2.4-benh/ChangeSet is:
cort@ftsoj.fsmlabs.com|drivers/sound/dmasound/Config.in|20010106072831|13776|67da7753905f489
benh@zion.wanadoo.fr|drivers/sound/dmasound/Config.in|20010512181358|01477,
in case that helps :)

 I wasn't running X at the time of the crash.  I was using a framebuffer
console (ATI mach64 driver).

 This crash is repeatable.  I just did it again (after going to single user
mode and remounting my drives read-only :).  However, this time it prints an
infinity of newlines after the crash message.

--
#define X(x,y) x##y
Peter Cordes ;  e-mail: X(peter@llama.nslug. , ns.ca)

"The gods confound the man who first found out how to distinguish the hours!
 Confound him, too, who in this place set up a sundial, to cut and hack
 my day so wretchedly into small pieces!" -- Plautus, 200 BCE

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: kernel lockup

[Benjamin Herrenschmidt]

>bigfoot:~# kbdrate -h
>kbdrate: invalid option -- h
>Machine check in kernel mode.
>Caused by (from SRR1=c9030): Unknown values in msr
>
> What do I do to debug this?
>
> The machine is totally locked, not even the SysRQ combination does
>anything.  (control+command+power still resets though, since it is handled
>in hardware on oldworlds.)

Well, I guess that kbdrate is yet another dumb x86'ism that will
directly tap the hardware of a PC's keyboard controller...

Well, I may be wrong, but machine check usually means that you are
trying to access non-existing hardware.

There should be other informations displayed about the crash. Those
should allow you to lookup the location of it in System.map

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: kernel lockup

[Ethan Benson]

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

On Wed, May 16, 2001 at 11:21:54AM +0200, Benjamin Herrenschmidt wrote:
> 
> >bigfoot:~# kbdrate -h
> >kbdrate: invalid option -- h

thats interesting, kbdrate -h gives a usage message for me.. like it
should.  

> >Machine check in kernel mode.
> >Caused by (from SRR1=c9030): Unknown values in msr
> >
> > What do I do to debug this?
> >
> > The machine is totally locked, not even the SysRQ combination does
> >anything.  (control+command+power still resets though, since it is handled
> >in hardware on oldworlds.)
> 
> Well, I guess that kbdrate is yet another dumb x86'ism that will
> directly tap the hardware of a PC's keyboard controller...

according to the man page it trys to be portable:

[...]
       All this is very architecture dependent.  Nowadays kbdrate
       first tries the KDKBDREP and KIOCSRATE ioctls.  (The  for-
       mer  usually  works  on  an  m68k  machine, the latter for
       SPARC.)  When these ioctls fail an ioport interface as  on
       i386 is assumed.

FILES
       /etc/rc.local
       /dev/port

Linux 1.1.19               22 June 1994                         2

that fallback is probably the bugger though.  

> Well, I may be wrong, but machine check usually means that you are
> trying to access non-existing hardware.

-- 
Ethan Benson
http://www.alaska.net/~erbenson/

[-- Attachment #2: Type: application/pgp-signature, Size: 0 bytes --]

Re: kernel lockup

[Peter Cordes]

On Wed, May 16, 2001 at 11:21:54AM +0200, Benjamin Herrenschmidt wrote:
> >bigfoot:~# kbdrate -h
> >kbdrate: invalid option -- h
> >Machine check in kernel mode.
> >Caused by (from SRR1=c9030): Unknown values in msr
> >
> > What do I do to debug this?
> >
> > The machine is totally locked, not even the SysRQ combination does
> >anything.  (control+command+power still resets though, since it is handled
> >in hardware on oldworlds.)
>
> Well, I guess that kbdrate is yet another dumb x86'ism that will
> directly tap the hardware of a PC's keyboard controller...
>
> Well, I may be wrong, but machine check usually means that you are
> trying to access non-existing hardware.

 Ah, I remember that it sets your repeat rate and delay to something even
after you run it with options it doesn't recognize.  That would explain it.

> There should be other informations displayed about the crash. Those
> should allow you to lookup the location of it in System.map

 Well, there isn't :(  It seems to lock hard, and nothing does anything.

 I just noticed that on bootup, there's a message in the initial bootup
stuff from xmon saying that it will use "screen and keyboard".  If these are
the OpenFirmware devices, then might that be using my serial port instead?
(I still haven't gotten around to getting an adapter so I can look at what
OF is saying.)  My machine is a clone based on the Apple 9500.

 I just looked at my syslog, and there were logs from cron jobs after the
console locked up.  I tried running kbdrate on the console while I was
logged in through ssh from the other machine on my desk.  Well, the ssh
session stayed working completely, so I just su'ed and ran shutdown -r now.
I guess the thing to figure out now is why the console is totally locked
out, even though nothing else stops working.


--
#define X(x,y) x##y
Peter Cordes ;  e-mail: X(peter@llama.nslug. , ns.ca)

"The gods confound the man who first found out how to distinguish the hours!
 Confound him, too, who in this place set up a sundial, to cut and hack
 my day so wretchedly into small pieces!" -- Plautus, 200 BCE

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/