page fault panic in scioctl and console-kit-daemon

Pawel Worach pawel.worach at
Wed Jan 23 13:35:15 PST 2008

Kostik Belousov wrote:
> On Wed, Jan 23, 2008 at 02:55:59PM -0500, Joe Marcus Clarke wrote:
>> On Wed, 2008-01-23 at 20:34 +0100, Pawel Worach wrote:
>>> Kostik Belousov wrote:
>>>> On Tue, Jan 22, 2008 at 07:26:53PM +0100, Pawel Worach wrote:
>>>>> Kostik Belousov wrote:
>>>>>> On Sun, Jan 20, 2008 at 04:42:36AM +0100, Pawel Worach wrote:
>>>>>>> Hi,
>>>>>>> While starting console-kit-daemon (sysutils/consolekit 0.2.3) during 
>>>>>>> boot or in single-user mode the system panics. If I start it post-boot 
>>>>>>> it runs fine. This is on 8.0-CURRENT from about 12 hours ago, another 
>>>>>>> user also reported the same on RELENG_7. Any other information I can 
>>>>>>> provide ?
>>>>>>> Fatal trap 12: page fault while in kernel mode
>>>>>>> fault virtual address	= 0x4
>>>>>>> fault code		= supervisor read, page not present
>>>>>>> instruction pointer	= 0x20:0xc04d2ab4
>>>>>>> stack pointer	        = 0x28:0xe6499b18
>>>>>>> frame pointer	        = 0x28:0xe6499b80
>>>>>>> code segment		= base 0x0, limit 0xfffff, type 0x1b
>>>>>>> 			= DPL 0, pres 1, def32 1, gran 1
>>>>>>> processor eflags	= interrupt enabled, resume, IOPL = 0
>>>>>>> current process		= 134 (console-kit-daemon)
>>>>>>> Physical memory: 1014 MB
>>>>>>> Dumping 43 MB: 28 12
>>>>>>> #8  0xc07a34a2 in trap (frame=0xe6499ad8) at 
>>>>>>> /usr/src/sys/i386/i386/trap.c:489
>>>>>>> #9  0xc079183b in calltrap () at /usr/src/sys/i386/i386/exception.s:146
>>>>>>> #10 0xc04d2ab4 in scioctl (dev=0xc3b20d00, cmd=537163270,
>>>>>>>    data=0xe6499c70 "\002", flag=1, td=0xc3d3c880)
>>>>>>>    at /usr/src/sys/dev/syscons/syscons.c:1073
>>>>>>> #11 0xc051ed1a in giant_ioctl (dev=0xc3b20d00, cmd=537163270,
>>>>>>>    data=0xe6499c70 "\002", fflag=1, td=0xc3d3c880)
>>>>>>>    at /usr/src/sys/kern/kern_conf.c:349
>>>>>>> #12 0xc0598194 in cnioctl (dev=0xc3b20d00, cmd=537163270,
>>>>>>>    data=0xe6499c70 "\002", flag=1, td=0xc3d3c880)
>>>>>>> ---Type <return> to continue, or q <return> to quit---
>>>>>>>    at /usr/src/sys/kern/tty_cons.c:521
>>>>>> Unless the virtual screen is opened, the screen state scr_stat structure
>>>>>> is not allocated. The following patch would fix the panic, but I do not
>>>>>> know how the console-kit would react to the ENXIO from the
>>>>>> VT_WAITACTIVE ioctl. Please, test it.
>>>>> Thanks! The patch works.
>>>> To clarify: do you see any problems with the console-kit after the patch ?
>>>> In particular, can you verify that the program functions correctly, esp.
>>>> on the virtual terminals 1, 2 ... , whatever this means ?
>>> The panic is of course gone, while chatting a bit with Marcus (CCd) it 
>>> looks like console-kit does not do any error handling at all. I've not 
>>> looked at what c-k does so maybe Marcus can answer the question better.
>> It tries to install a wait thread on each available VT.  That thread
>> sets the WAITACTIVE ioctl, and waits for its VT to become active.  When
>> it does, it sets the CK active VT accordingly, and reattaches the wait.
>> When an error occurs in the ioctl, no wait is attached, and CK will not
>> know when a particular VT becomes active.  This will essentially cripple
>> CK (assuming the VT really does become available at a later point).  
>> Now, admittedly, there is no error correction in CK for this situation.
>> It would be trivial to add something that periodically attempts to
>> reestablish a failed wait.  However, I am very curious why only a few
>> users are seeing this panic (me excluded on two different machines).  It
>> seems to me that the scp should be initialized when sc_attach_unit() is
>> called during device probing.  I don't see anything special in init(8)'s
>> code that would cause these VT devices to become initialized.  I would
>> assume that if one can open(2) them, then they should be available for
>> ioctls?
> From my reading of the code, scp would be non-NULL after the first open
> of the corresponding /dev/ttyvX. sc_attach_unit() creates the scp for
> the console and the consolectl devices.
> VT_WAITACTIVE ioctl is performed on arbitrary syscons /dev node, and
> can wait for any other screens, in particular, the screens that are
> not opened at the moment (the reason for the reported panic).
> The patch I posted may be improved by making the VT_WAITACTIVE ioctl
> to wait for the scp being allocated, and only then for the screen to be
> switched too. Please, test.

This patch also seems to work from the no-panic point of view.


More information about the freebsd-current mailing list