Xen devel - May 2005 - [patch] convert page-l3.h macros to inlines

Avoid multiple evals as discussed in "double incrementing l2tab"
thread.

sRp

-- 
Scott Parish
Signed-off-by: srparish@us.ibm.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Fri, May 13, 2005 at 11:16:35AM +0000, Scott Parish
wrote:
> Avoid multiple evals as discussed in "double incrementing l2tab"
thread.
Oh, great, saves me some work ;)

Merged and uploaded with patchset #7 (it''s against cset 1.1445).
That one works fine for me, with both preempt on/off.  I''ll go
test it a bit more.

  Gerd

-- 
-mm seems unusually stable at present.
	-- akpm about 2.6.12-rc3-mm3

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Fri, May 13, 2005 at 02:12:19PM +0200, Gerd Knorr wrote:
> Merged and uploaded with patchset #7 (it''s against cset 1.1445).
> That one works fine for me, with both preempt on/off.  I''ll go
> test it a bit more.
That was fast! Unfortunately i''m still ending up with the same crash:

  http://srparish.net/tmp/2/xen-93 (.config/vmlinux/xen-syms)

sRp

-- 
Scott Parish
Signed-off-by: srparish@us.ibm.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Fri, May 13, 2005 at 01:36:43PM +0000, Scott Parish wrote:
> On Fri, May 13, 2005 at 02:12:19PM +0200, Gerd Knorr wrote:
> 
> > Merged and uploaded with patchset #7 (it''s against cset
1.1445).
> > That one works fine for me, with both preempt on/off.  I''ll
go
> > test it a bit more.
> 
> That was fast! Unfortunately i''m still ending up with the same
crash:
> 
>   http://srparish.net/tmp/2/xen-93 (.config/vmlinux/xen-syms)
preempt off didn''t help either.

sRp

-- 
Scott Parish
Signed-off-by: srparish@us.ibm.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> > That was fast! Unfortunately i''m still ending up with the
same crash:
> > 
> >   http://srparish.net/tmp/2/xen-93 (.config/vmlinux/xen-syms)
> 
> preempt off didn''t help either.
Seems to be the same very place.  Adding current->comm to the
printk next to the BUG() should show which process this is,
probably it is the same every time which triggers some bug.
If so, can you place the binary somewhere?

The system looks like Debian, correct?

Any difference when you move away /lib/tls (probably not, but
who knows ...) ?

Sticking some debug printk into mm_walk which triggers depending
on current->comm might help to see what is going on.

  Gerd

-- 
-mm seems unusually stable at present.
	-- akpm about 2.6.12-rc3-mm3

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Fri, May 13, 2005 at 06:25:44PM +0200, Gerd Knorr wrote:
> > preempt off didn''t help either.
> 
> Seems to be the same very place.  Adding current->comm to the
> printk next to the BUG() should show which process this is,
> probably it is the same every time which triggers some bug.
> If so, can you place the binary somewhere?
>
> The system looks like Debian, correct?
>
> Any difference when you move away /lib/tls (probably not, but
> who knows ...) ?
>
> Sticking some debug printk into mm_walk which triggers depending
> on current->comm might help to see what is going on.
I''m getting to a prompt now, although the system is still _very_ flaky
and crashes (same basic trace: mm_walk..)

/lib/tls didn''t seem to have any effect when it was crashing during
boot, and it still doesn''t seem to have any effect now that its
finishing boot.

somewhere along the lines i told debian to update itself, and this
might have been what got me to a prompt. (fwiw i''m running debian sid)

current->comm might have showed more consistancy earlier, but now its
as random as when i crash (which i haven''t been able to consistantly
reproduce or consistantly avoid reproducing). i''ve seen stuff like
"sshd" "bash" "rcX" so far.

the rest of this data is stuff i collected before moving to your 7th
patch release. i can reproduce it if needed, but it was kind of tedious
and nothing appears to have changed about the details of the crash..

+ the crash is always the last mm_walk_set_prot() in mm_walk(), that is
the one for ptes.

+ the crash is always when pte == 0x15555000 (where pte is type ''pte_t
*'')

+ the pmd (pmd_t *) always has the lowest bits of 0xd60

+ the pte == 0x15555000 will appear in the middle of a seemingly fine
  pmd. by "continue"ing if pte == 0x15555000, i found there''s
a cluster
  of them:

...
mw pmd: 0xcf49fd50 pte: 0xc007d000
mw pmd: 0xcf49fd58 pte: 0xc007c000
mw pmd: 0xcf49fd60 pte: 0x15555000
mw pmd: 0xcf49fd68 pte: 0x15555000
mw pmd: 0xcf49fda0 pte: 0x15555000
...
mw pmd: 0xcf49ff48 pte: 0x15555000
mw pmd: 0xcf49ff50 pte: 0x15555000
mw pmd: 0xcf49ff58 pte: 0x15555000
mw pmd: 0xcf49ff60 pte: 0xcf4a0000
mw pmd: 0xcf49ff68 pte: 0xcf4a1000
mw pmd: 0xcf49ff70 pte: 0xcf4b2000
mw pmd: 0xcf49ff78 pte: 0xcf49f000
mw pmd: 0xcf49ff80 pte: 0x15555000
mw pmd: 0xcf49ff88 pte: 0x15555000
mw pmd: 0xcf49ff90 pte: 0x15555000
mw pmd: 0xcf49ff98 pte: 0x15555000
mw pmd: 0xcf49ffa0 pte: 0xbffff000
mw pmd: 0xcf49ffa8 pte: 0x15555000
mw pmd: 0xcf49ffb0 pte: 0x15555000
mw pmd: 0xcf49ffb8 pte: 0x15555000
mw pmd: 0xcf49ffc0 pte: 0x15555000
mw pmd: 0xcf49ffc8 pte: 0x15555000
mw pmd: 0xcf49ffd0 pte: 0x15555000
mw pmd: 0xcf49ffd8 pte: 0x15555000
mw pmd: 0xcf49ffe0 pte: 0x15555000
mw pmd: 0xcf49ffe8 pte: 0x15555000
mw pmd: 0xcf49fff0 pte: 0x15555000
mw pmd: 0xcf49fff8 pte: 0x15555000
mw pmd: 0xc0536df8 pte: 0xcf276000
mw pmd: 0xc0536e00 pte: 0xcf277000
mw pmd: 0xc0536ff8 pte: 0xcece8000

that''s all i can think of right now that i found interesting

sRp

-- 
Scott Parish
Signed-off-by: srparish@us.ibm.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

fwiw, i''ve been temporarily moved to helping out with amd64

sRp

-- 
Scott Parish
Signed-off-by: srparish@us.ibm.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel