Unable to handle kernel paging request at virtual address e9042464

Unable to handle kernel paging request at virtual address e9042464

[Christopher S. Aker]

During testing of unstable as of a few minutes ago, starting a domU:

Unable to handle kernel paging request at virtual address e9042464
 printing eip:
c01362fe
*pde = ma 00000000 pa 55555000
 [<c013f244>] do_anonymous_page+0x1ab/0x1fc
 [<c013d654>] zap_pmd_range+0x57/0x75
 [<c013d6ac>] zap_pud_range+0x3a/0x5e
 [<c013d744>] unmap_page_range+0x74/0x8b
 [<c013d858>] unmap_vmas+0xfd/0x1ff
 [<c0141d7a>] unmap_region+0x7b/0xe5
 [<c0142025>] do_munmap+0xfd/0x14f
 [<c01420b5>] sys_munmap+0x3e/0x58
 [<c0109074>] syscall_call+0x7/0xb
Oops: 0000 [#1]
Modules linked in:
CPU:    0
EIP:    0061:[<c01362fe>]    Not tainted VLI
EFLAGS: 00010286   (2.6.11-xen0)
EIP is at set_page_dirty+0x1d/0x50
eax: e9042454   ebx: 00000000   ecx: c100dfe0   edx: c0257dfc
esi: c312f22c   edi: 086ff067   ebp: 00001000   esp: c098de50
ds: 007b   es: 007b   ss: 0069
Process python (pid: 1620, threadinfo=c098c000 task=c59b0020)
Stack: 00000061 c013d55b c1056520 c1056520 c013f244 00000010 c100dfe0 00000000
       b708b000 c044e71c b748b000 c00d9b74 b708c000 00000000 c013d654 c044e71c
       c00d9b70 b708b000 00001000 00000000 b708b000 c00d9b74 b708c000 00000000
Call Trace:
 [<c013d55b>] zap_pte_range+0x252/0x2f4
 [<c013f244>] do_anonymous_page+0x1ab/0x1fc
 [<c013d654>] zap_pmd_range+0x57/0x75
 [<c013d6ac>] zap_pud_range+0x3a/0x5e
 [<c013d744>] unmap_page_range+0x74/0x8b
 [<c013d858>] unmap_vmas+0xfd/0x1ff
 [<c0141d7a>] unmap_region+0x7b/0xe5
 [<c0142025>] do_munmap+0xfd/0x14f
 [<c01420b5>] sys_munmap+0x3e/0x58
 [<c0109074>] syscall_call+0x7/0xb
Code: 01 8b 44 24 08 89 44 24 04 e9 e1 fe ff ff 83 ec 04 89 c1 8b 50 10 8b 00 a9 00
00 01 00 75 38 f6 c2 01 75 17 85 d2 74 13 8b 42 30 <8b> 40 10 85 c0 74 19 89 0c 24 ff
d0 83 c4 04 c3 8b 01 a8 10 75

-Chris

Re: Unable to handle kernel paging request at virtual address e9042464

[Jacob Gorm Hansen]

Christopher S. Aker wrote:
> During testing of unstable as of a few minutes ago, starting a domU:

I am seeing the same thing here. Dom0 dies when a domU is created or 
shortly thereafter. This is on a P4 and true with and without the 'noht' 
option.

Jacob

Re: Unable to handle kernel paging request at virtual address e9042464

[Keir Fraser]

On 23 Apr 2005, at 07:08, Christopher S. Aker wrote:

> During testing of unstable as of a few minutes ago, starting a domU:
>
> Unable to handle kernel paging request at virtual address e9042464
>  printing eip:

Does anyone know more precisely when this bug first appeared?

Cheers,
Keir

Re: Unable to handle kernel paging request at virtual address e9042464

[Christopher S. Aker]

> On 23 Apr 2005, at 07:08, Christopher S. Aker wrote:
>
> > During testing of unstable as of a few minutes ago, starting a domU:
> >
> > Unable to handle kernel paging request at virtual address e9042464
> >  printing eip:
>
> Does anyone know more precisely when this bug first appeared?

During the last day's updates for me.

Apr 22 01:11 xeno-unstable.bk~ -- Booted fine, but crashed during domU shutdown
Apr 23 01:37 xeno-unstable.bk  -- Crashes with "Unable to handle kernel paging
request"

Times are EDT.

-Chris

Re: Unable to handle kernel paging request at virtual address e9042464

[Nivedita Singhvi]

Christopher S. Aker wrote:
> During testing of unstable as of a few minutes ago, starting a domU:

Might not be the same thing, but I ran into this on the
April 1 nightly snapshot on the 13th of April:

http://marc.theaimsgroup.com/?l=xen-devel&m=111341790309372&w=2

thanks,
Nivedita

> Unable to handle kernel paging request at virtual address e9042464
>  printing eip:
> c01362fe
> *pde = ma 00000000 pa 55555000
>  [<c013f244>] do_anonymous_page+0x1ab/0x1fc
>  [<c013d654>] zap_pmd_range+0x57/0x75
>  [<c013d6ac>] zap_pud_range+0x3a/0x5e
>  [<c013d744>] unmap_page_range+0x74/0x8b
>  [<c013d858>] unmap_vmas+0xfd/0x1ff
>  [<c0141d7a>] unmap_region+0x7b/0xe5
>  [<c0142025>] do_munmap+0xfd/0x14f
>  [<c01420b5>] sys_munmap+0x3e/0x58
>  [<c0109074>] syscall_call+0x7/0xb
> Oops: 0000 [#1]
> Modules linked in:
> CPU:    0
> EIP:    0061:[<c01362fe>]    Not tainted VLI
> EFLAGS: 00010286   (2.6.11-xen0)
> EIP is at set_page_dirty+0x1d/0x50
> eax: e9042454   ebx: 00000000   ecx: c100dfe0   edx: c0257dfc
> esi: c312f22c   edi: 086ff067   ebp: 00001000   esp: c098de50
> ds: 007b   es: 007b   ss: 0069
> Process python (pid: 1620, threadinfo=c098c000 task=c59b0020)
> Stack: 00000061 c013d55b c1056520 c1056520 c013f244 00000010 c100dfe0 00000000
>        b708b000 c044e71c b748b000 c00d9b74 b708c000 00000000 c013d654 c044e71c
>        c00d9b70 b708b000 00001000 00000000 b708b000 c00d9b74 b708c000 00000000
> Call Trace:
>  [<c013d55b>] zap_pte_range+0x252/0x2f4
>  [<c013f244>] do_anonymous_page+0x1ab/0x1fc
>  [<c013d654>] zap_pmd_range+0x57/0x75
>  [<c013d6ac>] zap_pud_range+0x3a/0x5e
>  [<c013d744>] unmap_page_range+0x74/0x8b
>  [<c013d858>] unmap_vmas+0xfd/0x1ff
>  [<c0141d7a>] unmap_region+0x7b/0xe5
>  [<c0142025>] do_munmap+0xfd/0x14f
>  [<c01420b5>] sys_munmap+0x3e/0x58
>  [<c0109074>] syscall_call+0x7/0xb
> Code: 01 8b 44 24 08 89 44 24 04 e9 e1 fe ff ff 83 ec 04 89 c1 8b 50 10 8b 00 a9 00
> 00 01 00 75 38 f6 c2 01 75 17 85 d2 74 13 8b 42 30 <8b> 40 10 85 c0 74 19 89 0c 24 ff
> d0 83 c4 04 c3 8b 01 a8 10 75
> 
> -Chris
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

Re: Unable to handle kernel paging request at virtual address e9042464

[Keir Fraser]

> During testing of unstable as of a few minutes ago, starting a domU:
> 
> Unable to handle kernel paging request at virtual address e9042464
>  printing eip:
> c01362fe

Possibly you need to install more recent tools into domain0.

 -- Keir

Re: Unable to handle kernel paging request at virtual address e9042464

[Andrew Theurer]

Keir Fraser wrote:

>>During testing of unstable as of a few minutes ago, starting a domU:
>>
>>Unable to handle kernel paging request at virtual address e9042464
>> printing eip:
>>c01362fe
>>    
>>
>
>Possibly you need to install more recent tools into domain0.
>  
>

I might be havig the same problem (since about last thursday-friday), 
but I have been able to start uniproessor domU's.  I'll see if I can 
track this down to a particular changeset.

-Andrew

Re: Unable to handle kernel paging request at virtual address e9042464

[Jacob Gorm Hansen]

Keir Fraser wrote:
>>During testing of unstable as of a few minutes ago, starting a domU:
>>
>>Unable to handle kernel paging request at virtual address e9042464
>> printing eip:
>>c01362fe
> 
> 
> Possibly you need to install more recent tools into domain0.

Hmm I was using the latest libxc, but with vmtools rather than xend. My 
scaled-down dom0 is not ready to host python at this point.

Jacob

Re: Unable to handle kernel paging request at virtual address e9042464

[Jacob Gorm Hansen]

Keir Fraser wrote:
>>During testing of unstable as of a few minutes ago, starting a domU:
>>
>>Unable to handle kernel paging request at virtual address e9042464
>> printing eip:
>>c01362fe
> 
> 
> Possibly you need to install more recent tools into domain0.

Do you know how the interface has changed, i.e. what I need to modify in 
vmtools (xend is not an option since I am running with my own userspace 
relinked above 0xf0000000 in dom0) to get this working again?

Thanks,
Jacob

Re: Unable to handle kernel paging request at virtual address e9042464

[Jacob Gorm Hansen]

Jacob Gorm Hansen wrote:

>> Possibly you need to install more recent tools into domain0.
> 
> 
> Do you know how the interface has changed, i.e. what I need to modify in 
> vmtools (xend is not an option since I am running with my own userspace 
> relinked above 0xf0000000 in dom0) to get this working again?

Or alternatively, can anyone point me to a tarball of xen-unstable which 
is known to work?

Thanks,
Jacob

Re: Unable to handle kernel paging request at virtual address e9042464

[Christopher S. Aker]

> > During testing of unstable as of a few minutes ago, starting a domU:
> >
> > Unable to handle kernel paging request at virtual address e9042464
> >  printing eip:
> > c01362fe
>
> Possibly you need to install more recent tools into domain0.

/usr/sbin/xcs and /usr/lib/python/xen all match timestamps for when I
compiled/installed that tree.  I've gotten into the habit of rm'ing
/usr/lib/python/xen before installing.

If there's something else I should try, I'm all ears.

-Chris

Re: Unable to handle kernel paging request at virtual address e9042464

[Jacob Gorm Hansen]

Christopher S. Aker wrote:

> If there's something else I should try, I'm all ears.
> 

Which linux version are you using, I am on 2.6.11.7.

Jacob

Re: Unable to handle kernel paging request at virtual address e9042464

[Christopher S. Aker]

> > If there's something else I should try, I'm all ears.
> > 
> 
> Which linux version are you using, I am on 2.6.11.7.

I'm just pulling down xeno-unstable at times, which includes 2.6.11, AFAIK.

-Chris

Re: Unable to handle kernel paging request at virtual address e9042464

[Keir Fraser]

On 25 Apr 2005, at 21:03, Jacob Gorm Hansen wrote:

> Do you know how the interface has changed, i.e. what I need to modify 
> in vmtools (xend is not an option since I am running with my own 
> userspace relinked above 0xf0000000 in dom0) to get this working 
> again?

I don't think this was the problem actually, but anyway: createdomain 
no longer takes memsize nor initial mem size. To pin to a cpu you now 
use DOM0_PINCPU. To set max mem reservation you use DOM0_SETMAXMEM. To 
actually reserve memory you use 
do_dom_mem_op(MEMOP_increase_reservation).

  -- Keir

Re: Unable to handle kernel paging request at virtual address e9042464

[Andrew Theurer]

On Monday 25 April 2005 16:54, Keir Fraser wrote:
> On 25 Apr 2005, at 21:03, Jacob Gorm Hansen wrote:
> > Do you know how the interface has changed, i.e. what I need to
> > modify in vmtools (xend is not an option since I am running with my
> > own userspace relinked above 0xf0000000 in dom0) to get this
> > working again?
>
> I don't think this was the problem actually, but anyway: createdomain
> no longer takes memsize nor initial mem size. To pin to a cpu you now
> use DOM0_PINCPU. To set max mem reservation you use DOM0_SETMAXMEM.
> To actually reserve memory you use
> do_dom_mem_op(MEMOP_increase_reservation).

FWIW, I think I am hitting an BUG on that very changeset (1.1367) by 
trying to start a smp domU.  I have narrowed it down the 1.1367, and I 
am going to remove that diff from very latest bk pull an see what 
happens.

-Andrew


BUG output:

Starting domain dom1
------------[ cut here ]------------

kernel BUG at <bad filename>:46733!
invalid operand: 0000 [#1]
PREEMPT
Modules linked in: ipt_MASQUERADE iptable_nat ip_conntrack ip_tables 
qla2300 qla2xxx scsi_transport_fc mptscsih mptbase
CPU:    0
EIP:    0061:[<c014c6e8>]    Not tainted VLI
EFLAGS: 00010286   (2.6.11-xen0-up)
EIP is at page_remove_rmap+0x3d/0x47
eax: ffffffff   ebx: 00000000   ecx: c04f771c   edx: c16fdfe0
esi: f48d5494   edi: 0feff067   ebp: 00001000   esp: f459de48
ds: 007b   es: 007b   ss: 0069
Process python (pid: 4300, threadinfo=f459c000 task=f76c3a80)
Stack: c1641640 f459c000 c0145244 c16fdfe0 0a3d5067 c01471fe 00000010 
c16fdfe0
       00000000 b7525000 c04f771c b7925000 f455fb78 b7526000 00000000 
c0145408
       c04f771c f455fb74 b7525000 00001000 00000000 b7525000 f455fb78 
b7526000
Call Trace:
 [<c0145244>] zap_pte_range+0x186/0x2f3
 [<c01471fe>] do_anonymous_page+0x169/0x210
 [<c0145408>] zap_pmd_range+0x57/0x75
 [<c0145460>] zap_pud_range+0x3a/0x5e
 [<c01454f8>] unmap_page_range+0x74/0x8b
 [<c014560c>] unmap_vmas+0xfd/0x223
 [<c0149ff4>] unmap_region+0x7b/0xe9
 [<c014a2c8>] do_munmap+0x122/0x191
 [<c014a37e>] sys_munmap+0x47/0x62
 [<c010965c>] syscall_call+0x7/0xb
Code: 0f 98 c0 84 c0 74 1c 8b 42 08 83 c0 01 78 1c c7 44 24 04 ff ff ff 
ff c7 04 24 10 00 00 00 e8 a3 ef fe ff 83 c4 08 c3 0f 0b eb d1 <0f> 0b 
8d b6 00 00 00 00 eb da 55 57 56 53 83 ec 1c 8b 4c 24 34
 <6>note: python[4300] exited with preempt_count 1
scheduling while atomic: python/0x00000001/4300
 [<c03ae564>] schedule+0x534/0x5d8
 [<c010980b>] hypervisor_callback+0x37/0x40
 [<c03af64d>] rwsem_down_read_failed+0x8d/0x18b
 [<c011da4b>] .text.lock.exit+0x27/0x8c
 [<c010a33f>] do_invalid_op+0x0/0xab
 [<c011c212>] do_exit+0x9d/0x36b
 [<c010a33f>] do_invalid_op+0x0/0xab
 [<c010a02d>] do_trap+0x0/0xd5
 [<c010a3e1>] do_invalid_op+0xa2/0xab
 [<c014c6e8>] page_remove_rmap+0x3d/0x47
 [<c013aa7e>] rmqueue_bulk+0x4a/0xd5
 [<c013a94a>] prep_new_page+0x72/0x77
 [<c013adfe>] buffered_rmqueue+0x153/0x2ba
 [<c01097cc>] error_code+0x38/0x40
 [<c014c6e8>] page_remove_rmap+0x3d/0x47
 [<c0145244>] zap_pte_range+0x186/0x2f3
 [<c01471fe>] do_anonymous_page+0x169/0x210
 [<c0145408>] zap_pmd_range+0x57/0x75
 [<c0145460>] zap_pud_range+0x3a/0x5e
 [<c01454f8>] unmap_page_range+0x74/0x8b
 [<c014560c>] unmap_vmas+0xfd/0x223
 [<c0149ff4>] unmap_region+0x7b/0xe9
 [<c014a2c8>] do_munmap+0x122/0x191
 [<c014a37e>] sys_munmap+0x47/0x62
 [<c010965c>] syscall_call+0x7/0xb

Re: Unable to handle kernel paging request at virtual address e9042464

[Bin Ren]

I've fixed this bug in the unstable repository. It's caused by two
improperly set memory-related parameters and an lack of initialization
of machine-to-phys mapping for newly allocated pages for the created
domains.

- Bin

On 4/25/05, Andrew Theurer <habanero@us.ibm.com> wrote:
> On Monday 25 April 2005 16:54, Keir Fraser wrote:
> > On 25 Apr 2005, at 21:03, Jacob Gorm Hansen wrote:
> > > Do you know how the interface has changed, i.e. what I need to
> > > modify in vmtools (xend is not an option since I am running with my
> > > own userspace relinked above 0xf0000000 in dom0) to get this
> > > working again?
> >
> > I don't think this was the problem actually, but anyway: createdomain
> > no longer takes memsize nor initial mem size. To pin to a cpu you now
> > use DOM0_PINCPU. To set max mem reservation you use DOM0_SETMAXMEM.
> > To actually reserve memory you use
> > do_dom_mem_op(MEMOP_increase_reservation).
> 
> FWIW, I think I am hitting an BUG on that very changeset (1.1367) by
> trying to start a smp domU.  I have narrowed it down the 1.1367, and I
> am going to remove that diff from very latest bk pull an see what
> happens.
> 
> -Andrew
> 
> BUG output:
> 
> Starting domain dom1
> ------------[ cut here ]------------
> 
> kernel BUG at <bad filename>:46733!
> invalid operand: 0000 [#1]
> PREEMPT
> Modules linked in: ipt_MASQUERADE iptable_nat ip_conntrack ip_tables
> qla2300 qla2xxx scsi_transport_fc mptscsih mptbase
> CPU:    0
> EIP:    0061:[<c014c6e8>]    Not tainted VLI
> EFLAGS: 00010286   (2.6.11-xen0-up)
> EIP is at page_remove_rmap+0x3d/0x47
> eax: ffffffff   ebx: 00000000   ecx: c04f771c   edx: c16fdfe0
> esi: f48d5494   edi: 0feff067   ebp: 00001000   esp: f459de48
> ds: 007b   es: 007b   ss: 0069
> Process python (pid: 4300, threadinfo=f459c000 task=f76c3a80)
> Stack: c1641640 f459c000 c0145244 c16fdfe0 0a3d5067 c01471fe 00000010
> c16fdfe0
>        00000000 b7525000 c04f771c b7925000 f455fb78 b7526000 00000000
> c0145408
>        c04f771c f455fb74 b7525000 00001000 00000000 b7525000 f455fb78
> b7526000
> Call Trace:
>  [<c0145244>] zap_pte_range+0x186/0x2f3
>  [<c01471fe>] do_anonymous_page+0x169/0x210
>  [<c0145408>] zap_pmd_range+0x57/0x75
>  [<c0145460>] zap_pud_range+0x3a/0x5e
>  [<c01454f8>] unmap_page_range+0x74/0x8b
>  [<c014560c>] unmap_vmas+0xfd/0x223
>  [<c0149ff4>] unmap_region+0x7b/0xe9
>  [<c014a2c8>] do_munmap+0x122/0x191
>  [<c014a37e>] sys_munmap+0x47/0x62
>  [<c010965c>] syscall_call+0x7/0xb
> Code: 0f 98 c0 84 c0 74 1c 8b 42 08 83 c0 01 78 1c c7 44 24 04 ff ff ff
> ff c7 04 24 10 00 00 00 e8 a3 ef fe ff 83 c4 08 c3 0f 0b eb d1 <0f> 0b
> 8d b6 00 00 00 00 eb da 55 57 56 53 83 ec 1c 8b 4c 24 34
>  <6>note: python[4300] exited with preempt_count 1
> scheduling while atomic: python/0x00000001/4300
>  [<c03ae564>] schedule+0x534/0x5d8
>  [<c010980b>] hypervisor_callback+0x37/0x40
>  [<c03af64d>] rwsem_down_read_failed+0x8d/0x18b
>  [<c011da4b>] .text.lock.exit+0x27/0x8c
>  [<c010a33f>] do_invalid_op+0x0/0xab
>  [<c011c212>] do_exit+0x9d/0x36b
>  [<c010a33f>] do_invalid_op+0x0/0xab
>  [<c010a02d>] do_trap+0x0/0xd5
>  [<c010a3e1>] do_invalid_op+0xa2/0xab
>  [<c014c6e8>] page_remove_rmap+0x3d/0x47
>  [<c013aa7e>] rmqueue_bulk+0x4a/0xd5
>  [<c013a94a>] prep_new_page+0x72/0x77
>  [<c013adfe>] buffered_rmqueue+0x153/0x2ba
>  [<c01097cc>] error_code+0x38/0x40
>  [<c014c6e8>] page_remove_rmap+0x3d/0x47
>  [<c0145244>] zap_pte_range+0x186/0x2f3
>  [<c01471fe>] do_anonymous_page+0x169/0x210
>  [<c0145408>] zap_pmd_range+0x57/0x75
>  [<c0145460>] zap_pud_range+0x3a/0x5e
>  [<c01454f8>] unmap_page_range+0x74/0x8b
>  [<c014560c>] unmap_vmas+0xfd/0x223
>  [<c0149ff4>] unmap_region+0x7b/0xe9
>  [<c014a2c8>] do_munmap+0x122/0x191
>  [<c014a37e>] sys_munmap+0x47/0x62
>  [<c010965c>] syscall_call+0x7/0xb
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

Re: Unable to handle kernel paging request at virtual address e9042464

[Andrew Theurer]

Excellent, thanks very much.  I'll bk pull and try asap.

-Andrew

Bin Ren wrote:

>I've fixed this bug in the unstable repository. It's caused by two
>improperly set memory-related parameters and an lack of initialization
>of machine-to-phys mapping for newly allocated pages for the created
>domains.
>
>- Bin
>
>On 4/25/05, Andrew Theurer <habanero@us.ibm.com> wrote:
>  
>
>>On Monday 25 April 2005 16:54, Keir Fraser wrote:
>>    
>>
>>>On 25 Apr 2005, at 21:03, Jacob Gorm Hansen wrote:
>>>      
>>>
>>>>Do you know how the interface has changed, i.e. what I need to
>>>>modify in vmtools (xend is not an option since I am running with my
>>>>own userspace relinked above 0xf0000000 in dom0) to get this
>>>>working again?
>>>>        
>>>>
>>>I don't think this was the problem actually, but anyway: createdomain
>>>no longer takes memsize nor initial mem size. To pin to a cpu you now
>>>use DOM0_PINCPU. To set max mem reservation you use DOM0_SETMAXMEM.
>>>To actually reserve memory you use
>>>do_dom_mem_op(MEMOP_increase_reservation).
>>>      
>>>
>>FWIW, I think I am hitting an BUG on that very changeset (1.1367) by
>>trying to start a smp domU.  I have narrowed it down the 1.1367, and I
>>am going to remove that diff from very latest bk pull an see what
>>happens.
>>
>>-Andrew
>>
>>BUG output:
>>
>>Starting domain dom1
>>------------[ cut here ]------------
>>
>>kernel BUG at <bad filename>:46733!
>>invalid operand: 0000 [#1]
>>PREEMPT
>>Modules linked in: ipt_MASQUERADE iptable_nat ip_conntrack ip_tables
>>qla2300 qla2xxx scsi_transport_fc mptscsih mptbase
>>CPU:    0
>>EIP:    0061:[<c014c6e8>]    Not tainted VLI
>>EFLAGS: 00010286   (2.6.11-xen0-up)
>>EIP is at page_remove_rmap+0x3d/0x47
>>eax: ffffffff   ebx: 00000000   ecx: c04f771c   edx: c16fdfe0
>>esi: f48d5494   edi: 0feff067   ebp: 00001000   esp: f459de48
>>ds: 007b   es: 007b   ss: 0069
>>Process python (pid: 4300, threadinfo=f459c000 task=f76c3a80)
>>Stack: c1641640 f459c000 c0145244 c16fdfe0 0a3d5067 c01471fe 00000010
>>c16fdfe0
>>       00000000 b7525000 c04f771c b7925000 f455fb78 b7526000 00000000
>>c0145408
>>       c04f771c f455fb74 b7525000 00001000 00000000 b7525000 f455fb78
>>b7526000
>>Call Trace:
>> [<c0145244>] zap_pte_range+0x186/0x2f3
>> [<c01471fe>] do_anonymous_page+0x169/0x210
>> [<c0145408>] zap_pmd_range+0x57/0x75
>> [<c0145460>] zap_pud_range+0x3a/0x5e
>> [<c01454f8>] unmap_page_range+0x74/0x8b
>> [<c014560c>] unmap_vmas+0xfd/0x223
>> [<c0149ff4>] unmap_region+0x7b/0xe9
>> [<c014a2c8>] do_munmap+0x122/0x191
>> [<c014a37e>] sys_munmap+0x47/0x62
>> [<c010965c>] syscall_call+0x7/0xb
>>Code: 0f 98 c0 84 c0 74 1c 8b 42 08 83 c0 01 78 1c c7 44 24 04 ff ff ff
>>ff c7 04 24 10 00 00 00 e8 a3 ef fe ff 83 c4 08 c3 0f 0b eb d1 <0f> 0b
>>8d b6 00 00 00 00 eb da 55 57 56 53 83 ec 1c 8b 4c 24 34
>> <6>note: python[4300] exited with preempt_count 1
>>scheduling while atomic: python/0x00000001/4300
>> [<c03ae564>] schedule+0x534/0x5d8
>> [<c010980b>] hypervisor_callback+0x37/0x40
>> [<c03af64d>] rwsem_down_read_failed+0x8d/0x18b
>> [<c011da4b>] .text.lock.exit+0x27/0x8c
>> [<c010a33f>] do_invalid_op+0x0/0xab
>> [<c011c212>] do_exit+0x9d/0x36b
>> [<c010a33f>] do_invalid_op+0x0/0xab
>> [<c010a02d>] do_trap+0x0/0xd5
>> [<c010a3e1>] do_invalid_op+0xa2/0xab
>> [<c014c6e8>] page_remove_rmap+0x3d/0x47
>> [<c013aa7e>] rmqueue_bulk+0x4a/0xd5
>> [<c013a94a>] prep_new_page+0x72/0x77
>> [<c013adfe>] buffered_rmqueue+0x153/0x2ba
>> [<c01097cc>] error_code+0x38/0x40
>> [<c014c6e8>] page_remove_rmap+0x3d/0x47
>> [<c0145244>] zap_pte_range+0x186/0x2f3
>> [<c01471fe>] do_anonymous_page+0x169/0x210
>> [<c0145408>] zap_pmd_range+0x57/0x75
>> [<c0145460>] zap_pud_range+0x3a/0x5e
>> [<c01454f8>] unmap_page_range+0x74/0x8b
>> [<c014560c>] unmap_vmas+0xfd/0x223
>> [<c0149ff4>] unmap_region+0x7b/0xe9
>> [<c014a2c8>] do_munmap+0x122/0x191
>> [<c014a37e>] sys_munmap+0x47/0x62
>> [<c010965c>] syscall_call+0x7/0xb
>>
>>
>>_______________________________________________
>>Xen-devel mailing list
>>Xen-devel@lists.xensource.com
>>http://lists.xensource.com/xen-devel
>>
>>    
>>
>
>  
>

Re: Unable to handle kernel paging request at virtual address e9042464

[Keir Fraser]

On 27 Apr 2005, at 10:49, Bin Ren wrote:

> I pulled the latest unstable bits, compiled xen, xen0, xenU and tools
> with my customized config files, run them on an AMD Sempron test
> machine, start xend (which is fine) but as soon as I try to create a
> domain with "xm create vmid=1 -c", kernel panics. My fix at least
> makes it work here. Hope this is helpful.

I don't want a patch in the tree until we understand why it fixes the 
problem. As far as I can see nothing depends on valid m2p entries 
before the domain boots, nor should rounding of mem_kb matter. 
Obviously one of these things *does* matter, because your patch fixes 
the crash. :-) But we should understand the bogus behaviour rather than 
obscure it.

This is all not helped by the fact that noone here in the lab can 
reproduce the problem. :-((

  -- Keir