cvs commit: src/sys/dev/syscons scmouse.c scvesactl.c scvgarndr.c scvidctl.c syscons.c syscons.h src/usr.sbin/vidcontrol vidcontrol.1 vidcontrol.c

[Peter Wemm]

On Friday 03 June 2005 12:09 am, Peter Wemm wrote:
> On Sunday 29 May 2005 01:43 am, Xin LI wrote:
> > delphij     2005-05-29 08:43:44 UTC
> >
> >   FreeBSD src repository
> >
> >   Modified files:
> >     sys/dev/syscons      scmouse.c scvesactl.c scvgarndr.c
> >                          scvidctl.c syscons.c syscons.h
> >     usr.sbin/vidcontrol  vidcontrol.1 vidcontrol.c
> >   Log:
> >   Add VESA mode support for syscons, which enables the support of
> > 15, 16, 24, and 32 bit modes.  To use that, syscons(4) must be
> > built with the compile time option 'options SC_PIXEL_MODE', and
> > VESA support (a.k.a. vesa.ko) must be either loaded, or be compiled
> > into the kernel.
>
> My AMD64 boxes are exploding with this:
>
> [...]
> Local package initialization:.
> Additional TCP options:.
>
> Fri Jun  3 00:06:29 PDT 2005
>
>
> Fatal trap 1: privileged instruction fault while in kernel mode
> cpuid = 3; apic id = 03
> instruction pointer     = 0x8:0xffffffff803828e6
> stack pointer           = 0x10:0xffffffffb19f8530
> frame pointer           = 0x10:0xffffffffb19f85f0
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                         = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags        = interrupt enabled, resume, IOPL = 0
> current process         = 1 (init)
> [thread pid 1 tid 100004 ]
> Stopped at      sc_term_remove+0x6:     aas
> db> trace
> Tracing pid 1 tid 100004 td 0xffffff007ba294c0
> sc_term_remove() at sc_term_remove+0x6
> sc_init_emulator() at sc_init_emulator+0x1b1
> alloc_scp() at alloc_scp+0x60
> scopen() at scopen+0x179
> devfs_open() at devfs_open+0x249
> VOP_OPEN_APV() at VOP_OPEN_APV+0xb1
> vn_open_cred() at vn_open_cred+0x477
> vn_open() at vn_open+0x17
> kern_open() at kern_open+0xe6
> open() at open+0x28
> syscall() at syscall+0x332
> Xfast_syscall() at Xfast_syscall+0xa8
> --- syscall (5, FreeBSD ELF64, open), rip = 0x40b14c, rsp =
> 0x7fffffffece8, rbp = 0x3 ---
>
> Is anybody else seeing this sort of thing?
>
> (The trap suggests a jump through an invalid pointer or something,
>  "aas" is a 32-bit only instruction and is illegal in 64 bit mode.)

This panic was caused here:
    scp->tsw = sw;
    scp->ts = p;
    scp->rndr = rndr;
    scp->rndr->init(scp);
    ^^^^^^^^^^^^^^^^^^
That's syscons.c line 3069.

However, even slight kernel changes are drastically changing the mode of
failure here.  Simply adding a printf of these values makes it panic 
differently during probe/attach instead of when getty starts up:

sc0: <System console> at flags 0x100 on isa0
rndr2 = 0xffffffff80526b20
rndr = 0xffffffff80526b20
rndr->init = 0xffffffff80382aa0

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x46
fault code              = supervisor write, page not present
instruction pointer     = 0x8:0xffffffff803826f2
...
Stopped at      scterm_default_attr+0x32:       movw    %dx,0x46(%rbx)
db> trace
Tracing pid 0 tid 0 td 0xffffffff80538540
scterm_default_attr() at scterm_default_attr+0x32
sc_init_emulator() at sc_init_emulator+0x1fd
alloc_scp() at alloc_scp+0x60
scinit() at scinit+0x2be
sc_attach_unit() at sc_attach_unit+0xcf
scattach() at scattach+0x2e
....

ie: adding the printfs changes things enough that it now gets to the 
next line.

It seems that things are really messed up somewhere.

Or even worse.. changing printfs causes this sometimes:

Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
rkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk[hang]


-- 
Peter Wemm - peter at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5