Re: [Qemu-devel] i586 TCG: boot hangs intermittently on cryptomgr_test at doublefault_fn

[Avi Kivity <avi@redhat.com>]

Richard W.M. Jones wrote:
> I have this bug[1] apparently in qemu which I'm trying to track down:
>
> ----------------------------------------------------------------------
> apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac)
> apm: overridden by ACPI.
> audit: initializing netlink socket (disabled)
> type=2000 audit(1243614582.002:1): initialized
> HugeTLB registered 4 MB page size, pre-allocated 0 pages
> VFS: Disk quotas dquot_6.5.2
> Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
> msgmni has been set to 680
> BUG: unable to handle kernel NULL pointer dereference at 00000014
> IP: [<c041ddd9>] doublefault_fn+0xd/0x108
> *pde = 00000000 
> Oops: 0000 [#1] SMP 
> last sysfs file: 
> Modules linked in:
>
> Pid: 26, comm: cryptomgr_test Not tainted (2.6.30-0.91.rc7.git1.fc12.i586 #1) 
> EIP: 0060:[<c041ddd9>] EFLAGS: f8d8409e CPU: 0
> EIP is at doublefault_fn+0xd/0x108
> EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000
> ESI: 00000000 EDI: 00000000 EBP: c0be1e2c ESP: c0be1e18
>  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> Process cryptomgr_test (pid: 26, ti=c0be0000 task=d5418000 task.ti=d5b88000)
> Stack:
>  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> Call Trace:
> Code: c2 eb 00 ba b8 dd 41 c0 ff e2 8d 15 e4 61 99 c0 8b 0a 51 8d 15 e0 61 99
> c0 8b 0a 51 c3 90 55 89 e5 56 53 83 ec 0c 0f 1f 44 00 00 <65> a1 14 00 00 00 89
> 45 f4 31 c0 8d 45 ee 66 c7 45 ee 00 00 c7 
> EIP: [<c041ddd9>] doublefault_fn+0xd/0x108 SS:ESP 0068:c0be1e18
> CR2: 0000000000000014
> ---[ end trace 6d450e935ee1897c ]---
> cryptomgr_test used greatest stack depth: 7348 bytes left
> ----------------------------------------------------------------------
>
> It seems to be: i386 architecture only, software emulation, and
> intermittent, quite hard to reproduce reliably.
>
> So my questions are: Has anyone seen anything like this before?
> Is there anything I can set or enable to track down which instructions
> are failing?
>   

The faulting instruction accesses gs:0x14.  Can you expand the register 
printout code to include the full information for the segment cache 
(base, limit, type, etc.)?

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.