Re: [PATCH 0 of 4] x86: some more patches

2008-01-16 Thread Andi Kleen
On Wednesday 16 January 2008 22:06:46 Ingo Molnar wrote: > > * Andi Kleen <[EMAIL PROTECTED]> wrote: > > > > truly stuck, or just an annoying message? > > > > Just annoying message; system works after that for simple login etc. > > (haven't run anything complicated) > > ok, if you see no

Re: [PATCH 0 of 4] x86: some more patches

2008-01-16 Thread Ingo Molnar
* Andi Kleen <[EMAIL PROTECTED]> wrote: > > truly stuck, or just an annoying message? > > Just annoying message; system works after that for simple login etc. > (haven't run anything complicated) ok, if you see no other failures and if you have some time it would be nice to figure out why

Re: [PATCH 0 of 4] x86: some more patches

2008-01-16 Thread Andi Kleen
> > truly stuck, or just an annoying message? Just annoying message; system works after that for simple login etc. (haven't run anything complicated) -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo

Re: [PATCH 0 of 4] x86: some more patches

2008-01-16 Thread Ingo Molnar
* Andi Kleen <[EMAIL PROTECTED]> wrote: > git-x86 upto a9f7faa5fd229a65747f02ab0f2d45ee35856760 boots, but gives > > VFS: Mounted root (nfs filesystem). > Freeing unused kernel memory: 264k freed > eth0: no IPv6 routers present > Clocksource tsc unstable (delta = 18747555652 ns) > > BUG: soft

Re: [PATCH 0 of 4] x86: some more patches

2008-01-16 Thread Andi Kleen
git-x86 upto a9f7faa5fd229a65747f02ab0f2d45ee35856760 boots, but gives VFS: Mounted root (nfs filesystem). Freeing unused kernel memory: 264k freed eth0: no IPv6 routers present Clocksource tsc unstable (delta = 18747555652 ns) BUG: soft lockup - CPU#2 stuck for 55s! [swapper:0] Pid: 0, comm:

Re: [PATCH 0 of 4] x86: some more patches

2008-01-16 Thread Andi Kleen
> Also, Andi, do you want to get rid of the PHYSICAL_MASK stuff? That would be fine, just all the accessors need to mask out NX explicitely. I didn't have plans to code that up myself though. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a

Re: [PATCH 0 of 4] x86: some more patches

2008-01-16 Thread Jeremy Fitzhardinge
Ingo Molnar wrote: * Jan Beulich <[EMAIL PROTECTED]> wrote: Yes, but if you cast to long the result will be 32bit again. Or do you rely on it being always used in 64bit signed context with sign extension? While that might work it would seem rather fragile to me, just asking for similar

Re: [PATCH 0 of 4] x86: some more patches

2008-01-16 Thread Ingo Molnar
* Ingo Molnar <[EMAIL PROTECTED]> wrote: > -#define PAGE_MASK(~(PAGE_SIZE-1)) > +#define PAGE_MASK(_AT(phys_addr_t, ~(PAGE_SIZE-1))) that should be: #define PAGE_MASK (_AT(phys_addr_t, PAGE_SIZE)-1) but still - PAGE_MASK is used in a lot of places so i'm nervous about this

Re: [PATCH 0 of 4] x86: some more patches

2008-01-16 Thread Ingo Molnar
* Jan Beulich <[EMAIL PROTECTED]> wrote: > > Yes, but if you cast to long the result will be 32bit again. Or do > > you rely on it being always used in 64bit signed context with sign > > extension? While that might work it would seem rather fragile to me, > > just asking for similar future

Re: [PATCH 0 of 4] x86: some more patches

2008-01-16 Thread Jan Beulich
>Yes, but if you cast to long the result will be 32bit again. Or do you >rely on it being always used in 64bit signed context with sign extension? >While that might work it would seem rather fragile to me, just asking >for similar future bugs. Even if conversion is to 64-bit unsigned, the value

Re: [PATCH 0 of 4] x86: some more patches

2008-01-16 Thread Andi Kleen
On Wednesday 16 January 2008 15:54:27 Ingo Molnar wrote: > > * Andi Kleen <[EMAIL PROTECTED]> wrote: > > > > #define PHYSICAL_PAGE_MASK (PAGE_MASK & __PHYSICAL_MASK) > > > > > > I haven't tested yet, but we looked at that one earlier and I thought > > it was ok because > > > > #define

Re: [PATCH 0 of 4] x86: some more patches

2008-01-16 Thread Ingo Molnar
today's x86.git now has all the fixes included - can you confirm that it boots fine on your box? Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at

Re: [PATCH 0 of 4] x86: some more patches

2008-01-16 Thread Ingo Molnar
* Andi Kleen <[EMAIL PROTECTED]> wrote: > > #define PHYSICAL_PAGE_MASK (PAGE_MASK & __PHYSICAL_MASK) > > > I haven't tested yet, but we looked at that one earlier and I thought > it was ok because > > #define __PHYSICAL_MASK _AT(phys_addr_t, (_AC(1,ULL) << > __PHYSICAL_MASK_SHIFT)

Re: [PATCH 0 of 4] x86: some more patches

2008-01-16 Thread Andi Kleen
> Index: linux-x86.q/include/asm-x86/page.h > === > --- linux-x86.q.orig/include/asm-x86/page.h > +++ linux-x86.q/include/asm-x86/page.h > @@ -11,7 +11,7 @@ > #ifdef __KERNEL__ > > #define PHYSICAL_PAGE_MASK (PAGE_MASK &

Re: [PATCH 0 of 4] x86: some more patches

2008-01-16 Thread Ingo Molnar
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote: > Ingo Molnar wrote: >> unfortunately they dont solve it: >> >> [ 92.042586] Freeing unused kernel memory: 328k freed >> [ 92.091838] khelper used greatest stack depth: 6244 bytes left >> [ 92.281738] init[1]: segfault at 0004 ip

Re: [PATCH 0 of 4] x86: some more patches

2008-01-16 Thread Ingo Molnar
* Jeremy Fitzhardinge [EMAIL PROTECTED] wrote: Ingo Molnar wrote: unfortunately they dont solve it: [ 92.042586] Freeing unused kernel memory: 328k freed [ 92.091838] khelper used greatest stack depth: 6244 bytes left [ 92.281738] init[1]: segfault at 0004 ip 49471cbb sp

Re: [PATCH 0 of 4] x86: some more patches

2008-01-16 Thread Andi Kleen
Index: linux-x86.q/include/asm-x86/page.h === --- linux-x86.q.orig/include/asm-x86/page.h +++ linux-x86.q/include/asm-x86/page.h @@ -11,7 +11,7 @@ #ifdef __KERNEL__ #define PHYSICAL_PAGE_MASK (PAGE_MASK

Re: [PATCH 0 of 4] x86: some more patches

2008-01-16 Thread Ingo Molnar
* Andi Kleen [EMAIL PROTECTED] wrote: #define PHYSICAL_PAGE_MASK (PAGE_MASK __PHYSICAL_MASK) I haven't tested yet, but we looked at that one earlier and I thought it was ok because #define __PHYSICAL_MASK _AT(phys_addr_t, (_AC(1,ULL) __PHYSICAL_MASK_SHIFT) - 1) and

Re: [PATCH 0 of 4] x86: some more patches

2008-01-16 Thread Ingo Molnar
today's x86.git now has all the fixes included - can you confirm that it boots fine on your box? Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0 of 4] x86: some more patches

2008-01-16 Thread Andi Kleen
On Wednesday 16 January 2008 15:54:27 Ingo Molnar wrote: * Andi Kleen [EMAIL PROTECTED] wrote: #define PHYSICAL_PAGE_MASK (PAGE_MASK __PHYSICAL_MASK) I haven't tested yet, but we looked at that one earlier and I thought it was ok because #define __PHYSICAL_MASK

Re: [PATCH 0 of 4] x86: some more patches

2008-01-16 Thread Jan Beulich
Yes, but if you cast to long the result will be 32bit again. Or do you rely on it being always used in 64bit signed context with sign extension? While that might work it would seem rather fragile to me, just asking for similar future bugs. Even if conversion is to 64-bit unsigned, the value

Re: [PATCH 0 of 4] x86: some more patches

2008-01-16 Thread Ingo Molnar
* Jan Beulich [EMAIL PROTECTED] wrote: Yes, but if you cast to long the result will be 32bit again. Or do you rely on it being always used in 64bit signed context with sign extension? While that might work it would seem rather fragile to me, just asking for similar future bugs.

Re: [PATCH 0 of 4] x86: some more patches

2008-01-16 Thread Ingo Molnar
* Ingo Molnar [EMAIL PROTECTED] wrote: -#define PAGE_MASK(~(PAGE_SIZE-1)) +#define PAGE_MASK(_AT(phys_addr_t, ~(PAGE_SIZE-1))) that should be: #define PAGE_MASK (_AT(phys_addr_t, PAGE_SIZE)-1) but still - PAGE_MASK is used in a lot of places so i'm nervous about this change.

Re: [PATCH 0 of 4] x86: some more patches

2008-01-16 Thread Jeremy Fitzhardinge
Ingo Molnar wrote: * Jan Beulich [EMAIL PROTECTED] wrote: Yes, but if you cast to long the result will be 32bit again. Or do you rely on it being always used in 64bit signed context with sign extension? While that might work it would seem rather fragile to me, just asking for similar

Re: [PATCH 0 of 4] x86: some more patches

2008-01-16 Thread Andi Kleen
Also, Andi, do you want to get rid of the PHYSICAL_MASK stuff? That would be fine, just all the accessors need to mask out NX explicitely. I didn't have plans to code that up myself though. -Andi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message

Re: [PATCH 0 of 4] x86: some more patches

2008-01-16 Thread Andi Kleen
git-x86 upto a9f7faa5fd229a65747f02ab0f2d45ee35856760 boots, but gives VFS: Mounted root (nfs filesystem). Freeing unused kernel memory: 264k freed eth0: no IPv6 routers present Clocksource tsc unstable (delta = 18747555652 ns) BUG: soft lockup - CPU#2 stuck for 55s! [swapper:0] Pid: 0, comm:

Re: [PATCH 0 of 4] x86: some more patches

2008-01-16 Thread Ingo Molnar
* Andi Kleen [EMAIL PROTECTED] wrote: git-x86 upto a9f7faa5fd229a65747f02ab0f2d45ee35856760 boots, but gives VFS: Mounted root (nfs filesystem). Freeing unused kernel memory: 264k freed eth0: no IPv6 routers present Clocksource tsc unstable (delta = 18747555652 ns) BUG: soft lockup -

Re: [PATCH 0 of 4] x86: some more patches

2008-01-16 Thread Andi Kleen
truly stuck, or just an annoying message? Just annoying message; system works after that for simple login etc. (haven't run anything complicated) -Andi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info

Re: [PATCH 0 of 4] x86: some more patches

2008-01-16 Thread Ingo Molnar
* Andi Kleen [EMAIL PROTECTED] wrote: truly stuck, or just an annoying message? Just annoying message; system works after that for simple login etc. (haven't run anything complicated) ok, if you see no other failures and if you have some time it would be nice to figure out why that

Re: [PATCH 0 of 4] x86: some more patches

2008-01-16 Thread Andi Kleen
On Wednesday 16 January 2008 22:06:46 Ingo Molnar wrote: * Andi Kleen [EMAIL PROTECTED] wrote: truly stuck, or just an annoying message? Just annoying message; system works after that for simple login etc. (haven't run anything complicated) ok, if you see no other failures and

Re: [PATCH 0 of 4] x86: some more patches

2008-01-15 Thread Ingo Molnar
* Andi Kleen <[EMAIL PROTECTED]> wrote: > [...] I found that Jan's ioremap fix also causes silent hangs here > during earlier bisecting (not sure why) please send a fuller bugreport - all these problems on your testbox might be interrelated. Jan's patch is undone in a later part of the

Re: [PATCH 0 of 4] x86: some more patches

2008-01-15 Thread Andi Kleen
On Wednesday 16 January 2008 00:28:23 Jeremy Fitzhardinge wrote: > Ingo Molnar wrote: > > unfortunately they dont solve it: > > > > [ 92.042586] Freeing unused kernel memory: 328k freed > > [ 92.091838] khelper used greatest stack depth: 6244 bytes left > > [ 92.281738] init[1]: segfault

Re: [PATCH 0 of 4] x86: some more patches

2008-01-15 Thread Jeremy Fitzhardinge
Ingo Molnar wrote: unfortunately they dont solve it: [ 92.042586] Freeing unused kernel memory: 328k freed [ 92.091838] khelper used greatest stack depth: 6244 bytes left [ 92.281738] init[1]: segfault at 0004 ip 49471cbb sp bff8dbb0 error 4 [ 92.288761] init[1]: segfault at

Re: [PATCH 0 of 4] x86: some more patches

2008-01-15 Thread Ingo Molnar
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote: > Hi Ingo, > > More patches: > > - rearrange paravirt.h to remove duplicate code, and to make it easy > to drop in 4th level pagetable functions. > - fix a warning I got from clear_bit in pgtable.h > - fix up some bogosity in pte_modify > -

[PATCH 0 of 4] x86: some more patches

2008-01-15 Thread Jeremy Fitzhardinge
Hi Ingo, More patches: - rearrange paravirt.h to remove duplicate code, and to make it easy to drop in 4th level pagetable functions. - fix a warning I got from clear_bit in pgtable.h - fix up some bogosity in pte_modify - mask NX from pte_pfn The last two may help with the problem that

[PATCH 0 of 4] x86: some more patches

2008-01-15 Thread Jeremy Fitzhardinge
Hi Ingo, More patches: - rearrange paravirt.h to remove duplicate code, and to make it easy to drop in 4th level pagetable functions. - fix a warning I got from clear_bit in pgtable.h - fix up some bogosity in pte_modify - mask NX from pte_pfn The last two may help with the problem that

Re: [PATCH 0 of 4] x86: some more patches

2008-01-15 Thread Ingo Molnar
* Jeremy Fitzhardinge [EMAIL PROTECTED] wrote: Hi Ingo, More patches: - rearrange paravirt.h to remove duplicate code, and to make it easy to drop in 4th level pagetable functions. - fix a warning I got from clear_bit in pgtable.h - fix up some bogosity in pte_modify - mask NX from

Re: [PATCH 0 of 4] x86: some more patches

2008-01-15 Thread Jeremy Fitzhardinge
Ingo Molnar wrote: unfortunately they dont solve it: [ 92.042586] Freeing unused kernel memory: 328k freed [ 92.091838] khelper used greatest stack depth: 6244 bytes left [ 92.281738] init[1]: segfault at 0004 ip 49471cbb sp bff8dbb0 error 4 [ 92.288761] init[1]: segfault at

Re: [PATCH 0 of 4] x86: some more patches

2008-01-15 Thread Andi Kleen
On Wednesday 16 January 2008 00:28:23 Jeremy Fitzhardinge wrote: Ingo Molnar wrote: unfortunately they dont solve it: [ 92.042586] Freeing unused kernel memory: 328k freed [ 92.091838] khelper used greatest stack depth: 6244 bytes left [ 92.281738] init[1]: segfault at 0004

Re: [PATCH 0 of 4] x86: some more patches

2008-01-15 Thread Ingo Molnar
* Andi Kleen [EMAIL PROTECTED] wrote: [...] I found that Jan's ioremap fix also causes silent hangs here during earlier bisecting (not sure why) please send a fuller bugreport - all these problems on your testbox might be interrelated. Jan's patch is undone in a later part of the series so