Re: PANIC: double fault, error_code: 0x0 in 4.0.0-rc3-2, kvm related?

[Stefan Seyfried <stefan.seyfried@googlemail.com>]

Am 18.03.2015 um 21:51 schrieb Andy Lutomirski:
> On Wed, Mar 18, 2015 at 1:05 PM, Stefan Seyfried
> <stefan.seyfried@googlemail.com> wrote:

>>> The relevant thread's stack is here (see ti in the trace):
>>>
>>> ffff8801013d4000
>>>
>>> It could be interesting to see what's there.
>>>
>>> I don't suppose you want to try to walk the paging structures to see
>>> if ffff88023bc80000 (i.e. gsbase) and, more specifically,
>>> ffff88023bc80000 + old_rsp and ffff88023bc80000 + kernel_stack are
>>> present?  You'd only have to walk one level -- presumably, if the PGD
>>> entry is there, the rest of the entries are okay, too.
>>
>> That's all greek to me :-)
>>
>> I see that there is something at ffff88023bc80000:
>>
>> crash> x /64xg 0xffff88023bc80000
>> 0xffff88023bc80000:     0x0000000000000000      0x0000000000000000
>> 0xffff88023bc80010:     0x0000000000000000      0x0000000000000000
>> 0xffff88023bc80020:     0x0000000000000000      0x000000006686ada9
>> 0xffff88023bc80030:     0x0000000000000000      0x0000000000000000
>> 0xffff88023bc80040:     0x0000000000000000      0x0000000000000000
>> [all zeroes]
>> 0xffff88023bc801f0:     0x0000000000000000      0x0000000000000000
>>
>> old_rsp and kernel_stack seem bogus:
>> crash> print old_rsp
>> Cannot access memory at address 0xa200
>> gdb: gdb request failed: print old_rsp
>> crash> print kernel_stack
>> Cannot access memory at address 0xaa48
>> gdb: gdb request failed: print kernel_stack
>>
>> kernel_stack is not a pointer? So 0xffff88023bc80000 + 0xaa48 it is:
> 
> Yup.  old_rsp and kernel_stack are offsets relative to gsbase.
> 
>>
>> crash> x /64xg 0xffff88023bc8aa00
>> 0xffff88023bc8aa00:     0x0000000000000000      0x0000000000000000
> 
> [...]
> 
> I don't know enough about crashkernel to know whether the fact that
> this worked means anything.

AFAIK this just means that the memory at this location is included in
the dump :-)

> Can you dump the page of physical memory at 0x4779a067?  That's the PGD.

Unfortunately not, this is a partial dump (I think the default config in
openSUSE, but I might have changed it some time ago) and the dump_level
is 31 which means that the following are excluded:

                     |      |cache  |cache  |      |
                dump | zero |without|with   | user | free
               level | page |private|private| data | page
              -------+------+-------+-------+------+------
                  31 |  X   |   X   |   X   |  X   |  X

so this:
crash> x /64xg 0x4779a067
0x4779a067:     Cannot access memory at address 0x4779a067
gdb: gdb request failed: x /64xg

probably just means, that the PGD falls in one of the above excluded
categories.

Best regards,

	Stefan
-- 
Stefan Seyfried
Linux Consultant & Developer -- GPG Key: 0x731B665B

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537