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. -- PawelReceived on Wed Jan 23 2008 - 20:35:15 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:26 UTC