Bug #1823
closed
panic after xdm is started
Added by Johannes.Hofmann about 14 years ago.
Updated about 14 years ago.
Description
Hi,
with recent kernel (v2.7.3.840.gf5f1b-DEVELOPMENT) I get a panic on my
UP laptop when I start xdm. Xorg without xdm works ok.
It seems that after xdm has been started a subsequent
kprintf() causes the panic. I've seen different kprintf()'s causing
this. The panic message is:
panic: Attempt to acquire token 0xc03dc800 not already held in hard
code section
A dump is on leaf.
Cheers,
Johannes
PS: With this new kernel the system (or is it X11?) feels a lot
snappier :-)
:Hi,
:
:with recent kernel (v2.7.3.840.gf5f1b-DEVELOPMENT) I get a panic on my
:UP laptop when I start xdm. Xorg without xdm works ok.
:It seems that after xdm has been started a subsequent
:kprintf() causes the panic. I've seen different kprintf()'s causing
:this. The panic message is:
:panic: Attempt to acquire token 0xc03dc800 not already held in hard
:code section
:A dump is on leaf.
:
:Cheers,
:Johannes
Very nice dump, I'm working on it. It looks like a tty token is being
improperly acquired in the kprintf() path.
:PS: With this new kernel the system (or is it X11?) feels a lot
: snappier :-)
Yes, for me too.
-Matt
Matthew Dillon
<dillon@backplane.com>
This should be fixed momentarily. I just have to test it. The
problem is the console intercept that X/xdm does. This causes
kprintf()'s to run through the constty and if the kprintf() is
made from a hard code section (which is a set of assertions that
I added recently) then Ka-Boom.
I'm changing it to only use the console tty if it can get the
tty_token non-blocking. Certainly this is not perfect, and if
it isn't good enough I'll remove the console intercept entirely
(which was a bad idea anyway, long ago).
-Matt
Matthew Dillon
<dillon@backplane.com>
Also available in: Atom
PDF