Re: syscons joy: reproduceable panic on resolution change

On Friday 15 April 2005 04:44 pm, Andre Guibert de Bruet wrote:
> On Fri, 15 Apr 2005, John Baldwin wrote:
> > On Apr 15, 2005, at 8:27 AM, Andre Guibert de Bruet wrote:
> >> (kgdb) bt
>
> <snip>
>
> >> #9  0xc0693a18 in trap_pfault (frame=0xe900c9d8, usermode=0, eva=0)
> >>     at /usr/src/sys/i386/i386/trap.c:724
> >> #10 0xc06935f8 in trap (frame=
> >>       {tf_fs = -1068433400, tf_es = -1056636888, tf_ds = 40, tf_edi =
> >> -1066508002, tf_esi = 295, tf_ebp = -385824200, tf_isp = -385824252,
> >> tf_ebx = 0, tf_edx = 7, tf_ecx = -385824056, tf_eax = -989770368,
> >> tf_trapno = 12, tf_err = 0, tf_eip = -1068379561, tf_cs = 32, tf_eflags
> >> = 66178, tf_esp = -1067131464, tf_ss = -1056600064}) at
> >> /usr/src/sys/i386/i386/trap.c:414 #11 0xc067f91a in calltrap () at
> >> /usr/src/sys/i386/i386/exception.s:139 #12 0xc0510008 in idle_setup
> >> (dummy=0x0) at
> >> /usr/src/sys/kern/kern_idle.c:89
> >> #13 0xc0645d6e in vm_fault (map=0xc1059000, vaddr=3222274048,
> >>     fault_type=2 '\002', fault_flags=0) at
> >> /usr/src/sys/vm/vm_fault.c:295
> >
> > You have a truly unique nested panic here that I haven't seen in a long
> > time. Somehow vm_map_lookup() is returning success, but it is setting
> > fs.first_object to NULL.
>
> This vm_map_lookup call would be performed before the callout that gets us
> here, right?

Yes. it's earlier in the vm_fault() function.

> >> #14 0xc06939c4 in trap_pfault (frame=0xe900cb9c, usermode=0,
> >> eva=3222274048)
> >>     at /usr/src/sys/i386/i386/trap.c:713
> >> #15 0xc06935f8 in trap (frame=
> >>       {tf_fs = -989790200, tf_es = 40, tf_ds = -1068302296, tf_edi =
> >> -1072693248, tf_esi = -955760640, tf_ebp = -385823744, tf_isp =
> >> -385823800, tf_ebx = -1072988160, tf_edx = 1572864, tf_ecx = 319488,
> >> tf_eax = -116932608, tf_trapno = 12, tf_err = 3, tf_eip = -1066853962,
> >> tf_cs = 32, tf_eflags = 66054, tf_esp = 0, tf_ss = -986200024}) at
> >> /usr/src/sys/i386/i386/trap.c:414
> >> #16 0xc067f91a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
> >> #17 0xc5010008 in ?? ()
> >> #18 0x00000028 in ?? ()
> >> #19 0xc0530028 in ogetkerninfo (td=0xc537c828, uap=0xc0100000)
> >>     at /usr/src/sys/kern/kern_sysctl.c:1440
> >> #20 0xc066da8c in vga_txtdraw (scp=0xc537c800, from=0, count=786432,
> >> flip=0)
> >>     at /usr/src/sys/dev/syscons/scvgarndr.c:196
> >
> > I'm not sure why you are bcopy'ing a bad KVA here.
>
> tf_eip in #15 points to i386/i386/support.s:490. This would seem to
> indicate that frame #16 is our call to generic_bcopy...

Oh, I know it's calling bcopy().  My point is that I don't see anything 
obviously wrong with the call to bcopy() in vga_txtdraw().

> How do we get from ogetkerninfo to generic_bcopy? I don't see ogetkerninfo
> getting called anywhere in the syscons driver. As you suggested, it looks
> like we're overlapping a vm fault over our humble syscons code path.

The ogetkerninfo is a red herring because gdb doesn't know how to handle trap 
frames correctly.

> Where to from here?

Well, if you can reproduce this you can start looking at what is being passed 
to bcopy() in the vga function to try and figure out what is happening.

-- 
John Baldwin <jhb_at_FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org