Re: syscons joy: reproduceable panic on resolution change

From: Andre Guibert de Bruet <andy_at_siliconlandmark.com>
Date: Fri, 15 Apr 2005 21:48:02 -0400 (EDT)
On Fri, 15 Apr 2005, John Baldwin wrote:
> 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:
>>>> #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.

Fair enough.

>>>> #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.

I am currently 40 miles (64 km) away from this system so it is sort of 
hard to switch VTs. I do have ssh access to the machine and the corefile 
that I obtained. I can spend some time this weekend trying to figure out a 
SoE for this... Wish me luck!

Thanks John!
Andy

| Andre Guibert de Bruet | Enterprise Software Consultant >
| Silicon Landmark, LLC. | http://siliconlandmark.com/    >
Received on Fri Apr 15 2005 - 23:48:07 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:32 UTC