Here is one I have found useful in my VIA processor bug hunting:
diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
index 3068388..2303d86 100644
--- a/arch/x86/kernel/head_32.S
+++ b/arch/x86/kernel/head_32.S
@@ -61,7 +61,7 @@
/* Enough space to fit pagetables for the low memory linear map */
MAPPING_BEYOND_END = \
- PAGE_TABLE_SIZE(((1<<32) - __PAGE_OFFSET) >> PAGE_SHIFT) << PAGE_SHIFT
+ PAGE_TABLE_SIZE((1<<20) - (__PAGE_OFFSET >> PAGE_SHIFT)) << PAGE_SHIFT
/*
* Worst-case size of the kernel mapping we need to make:
= = =
Before:
#5 [0000010000 - 0000011000] PGTABLE ==> [0000010000 - 0000011000]
#6 [0000011000 - 0000015000] BOOTMAP ==> [0000011000 - 0000015000]
After:
#5 [0000010000 - 000007d000] PGTABLE ==> [0000010000 - 000007d000]
#6 [000007d000 - 0000081000] BOOTMAP ==> [000007d000 - 0000081000]
Someone who knows mm check which is the reasonable value please.
Mike
"Michael S. Zick" <[email protected]> writes:
> Here is one I have found useful in my VIA processor bug hunting:
Could you please expand a bit what bug this is supposed to fix?
-Andi
--
[email protected] -- Speaking for myself only.
On Fri July 3 2009, Andi Kleen wrote:
> "Michael S. Zick" <[email protected]> writes:
>
> > Here is one I have found useful in my VIA processor bug hunting:
>
> Could you please expand a bit what bug this is supposed to fix?
>
I make no claims for it at the moment - too early in the test process.
Just the general observation that it takes 0.5M to describe 0.5G of ram.
Also,
the observation that (1<<32) drops the bit off the left end of a 32-bit value.
You can see the result in the portion of the post you snipped out. ;)
Mike
> -Andi
>
On 07/03/09 11:14, Michael S. Zick wrote:
> Here is one I have found useful in my VIA processor bug hunting:
>
> diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
> index 3068388..2303d86 100644
> --- a/arch/x86/kernel/head_32.S
> +++ b/arch/x86/kernel/head_32.S
> @@ -61,7 +61,7 @@
>
> /* Enough space to fit pagetables for the low memory linear map */
> MAPPING_BEYOND_END = \
> - PAGE_TABLE_SIZE(((1<<32) - __PAGE_OFFSET) >> PAGE_SHIFT) << PAGE_SHIFT
> + PAGE_TABLE_SIZE((1<<20) - (__PAGE_OFFSET >> PAGE_SHIFT)) << PAGE_SHIFT
>
>
These calculations are performed by the assembler, not the
preprocessor. I think this transformation looks correct (in that its an
identity with the original), but my understanding is that the assembler
does it calculations in arbitrary precision, so there's no need to worry
about limiting the arithmetic to 32-bits.
> /*
> * Worst-case size of the kernel mapping we need to make:
>
> = = =
>
> Before:
>
> #5 [0000010000 - 0000011000] PGTABLE ==> [0000010000 - 0000011000]
> #6 [0000011000 - 0000015000] BOOTMAP ==> [0000011000 - 0000015000]
>
> After:
>
> #5 [0000010000 - 000007d000] PGTABLE ==> [0000010000 - 000007d000]
> #6 [000007d000 - 0000081000] BOOTMAP ==> [000007d000 - 0000081000]
>
> Someone who knows mm check which is the reasonable value please.
>
The PGTABLE reservation seems much too big. I think 1 page should be
sufficient for a system with large pages. Even if not, 0x6d000 is way
too large. And they symptoms of failing to reserve the initial
pagetable are pretty non-subtle.
J
[ Missed some recipients. ]
On 07/03/09 11:14, Michael S. Zick wrote:
> Here is one I have found useful in my VIA processor bug hunting:
>
> diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
> index 3068388..2303d86 100644
> --- a/arch/x86/kernel/head_32.S
> +++ b/arch/x86/kernel/head_32.S
> @@ -61,7 +61,7 @@
>
> /* Enough space to fit pagetables for the low memory linear map */
> MAPPING_BEYOND_END = \
> - PAGE_TABLE_SIZE(((1<<32) - __PAGE_OFFSET) >> PAGE_SHIFT) << PAGE_SHIFT
> + PAGE_TABLE_SIZE((1<<20) - (__PAGE_OFFSET >> PAGE_SHIFT)) << PAGE_SHIFT
>
>
These calculations are performed by the assembler, not the
preprocessor. I think this transformation looks correct (in that its an
identity with the original), but my understanding is that the assembler
does it calculations in arbitrary precision, so there's no need to worry
about limiting the arithmetic to 32-bits.
> /*
> * Worst-case size of the kernel mapping we need to make:
>
> = = =
>
> Before:
>
> #5 [0000010000 - 0000011000] PGTABLE ==> [0000010000 - 0000011000]
> #6 [0000011000 - 0000015000] BOOTMAP ==> [0000011000 - 0000015000]
>
> After:
>
> #5 [0000010000 - 000007d000] PGTABLE ==> [0000010000 - 000007d000]
> #6 [000007d000 - 0000081000] BOOTMAP ==> [000007d000 - 0000081000]
>
> Someone who knows mm check which is the reasonable value please.
>
The PGTABLE reservation seems much too big. I think 1 page should be
sufficient for a system with large pages. Even if not, 0x6d000 is way
too large. And they symptoms of failing to reserve the initial
pagetable are pretty non-subtle.
J
On Fri July 3 2009, Jeremy Fitzhardinge wrote:
> [ Missed some recipients. ]
>
> On 07/03/09 11:14, Michael S. Zick wrote:
> > Here is one I have found useful in my VIA processor bug hunting:
> >
> > diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
> > index 3068388..2303d86 100644
> > --- a/arch/x86/kernel/head_32.S
> > +++ b/arch/x86/kernel/head_32.S
> > @@ -61,7 +61,7 @@
> >
> > /* Enough space to fit pagetables for the low memory linear map */
> > MAPPING_BEYOND_END = \
> > - PAGE_TABLE_SIZE(((1<<32) - __PAGE_OFFSET) >> PAGE_SHIFT) << PAGE_SHIFT
> > + PAGE_TABLE_SIZE((1<<20) - (__PAGE_OFFSET >> PAGE_SHIFT)) << PAGE_SHIFT
> >
> >
>
> These calculations are performed by the assembler, not the
> preprocessor. I think this transformation looks correct (in that its an
> identity with the original), but my understanding is that the assembler
> does it calculations in arbitrary precision, so there's no need to worry
> about limiting the arithmetic to 32-bits.
>
> > /*
> > * Worst-case size of the kernel mapping we need to make:
> >
> > = = =
> >
> > Before:
> >
> > #5 [0000010000 - 0000011000] PGTABLE ==> [0000010000 - 0000011000]
> > #6 [0000011000 - 0000015000] BOOTMAP ==> [0000011000 - 0000015000]
> >
> > After:
> >
> > #5 [0000010000 - 000007d000] PGTABLE ==> [0000010000 - 000007d000]
> > #6 [000007d000 - 0000081000] BOOTMAP ==> [000007d000 - 0000081000]
> >
> > Someone who knows mm check which is the reasonable value please.
> >
>
>
> The PGTABLE reservation seems much too big. I think 1 page should be
> sufficient for a system with large pages. Even if not, 0x6d000 is way
> too large. And they symptoms of failing to reserve the initial
> pagetable are pretty non-subtle.
>
Random system halts, deadlocks with interrupts disabled?
Yup, that sounds familiar.
If I ever get more than a stopped machine with a glowing power light;
I will be certain to share.
Mike
> J
>
>
On 07/03/09 11:38, Michael S. Zick wrote:
> I make no claims for it at the moment - too early in the test process.
> Just the general observation that it takes 0.5M to describe 0.5G of ram.
>
Only if you're using 4k pages. With large pages, 1 pte can map 2M, so
256 entries can map 512M, so you only need 1/2 a page of pagetable
(assuming PAE; if not a single entry can map 4M).
> Also,
> the observation that (1<<32) drops the bit off the left end of a 32-bit value.
> You can see the result in the portion of the post you snipped out. ;)
>
Those computations aren't done as 32-bit.
$ as << EOF
.data
.byte (1 << 100) >> 100
EOF
$ objdump -D a.out
a.out: file format elf64-x86-64
Disassembly of section .data:
0000000000000000 <.data>:
0: 01 .byte 0x1
J
On 07/03/09 12:03, Michael S. Zick wrote:
> Random system halts, deadlocks with interrupts disabled?
> Yup, that sounds familiar.
>
No, mostly memory corruption, with all sorts of indicative kernel
messages (esp if you have all the debugging options on).
But my point is that if there were something wrong in that particular
piece of code, it would have very widespread effects. It would not be
subtle in the sense of only affecting one or two people.
> If I ever get more than a stopped machine with a glowing power light;
> I will be certain to share.
>
Hm, well that does sound serious, but I think you're barking up the
wrong tree with this particular patch.
J
On Fri July 3 2009, Jeremy Fitzhardinge wrote:
> On 07/03/09 11:38, Michael S. Zick wrote:
> > I make no claims for it at the moment - too early in the test process.
> > Just the general observation that it takes 0.5M to describe 0.5G of ram.
> >
> Only if you're using 4k pages. With large pages, 1 pte can map 2M, so
> 256 entries can map 512M, so you only need 1/2 a page of pagetable
> (assuming PAE; if not a single entry can map 4M).
>
Ah, but you can't assume that - look at your VIA-C7M tech sheet - NO PAE.
Mike
> > Also,
> > the observation that (1<<32) drops the bit off the left end of a 32-bit value.
> > You can see the result in the portion of the post you snipped out. ;)
> >
>
> Those computations aren't done as 32-bit.
>
Try ending the filename in ".S" and passing it to gcc,
like the build system does.
And while your at it, thank A.K. for snipping off the before/after dmesg.
Mike
>
> $ as << EOF
> .data
> .byte (1 << 100) >> 100
> EOF
> $ objdump -D a.out
>
> a.out: file format elf64-x86-64
>
> Disassembly of section .data:
>
> 0000000000000000 <.data>:
> 0: 01 .byte 0x1
>
>
> J
>
>
Michael S. Zick wrote:
>>
>> The PGTABLE reservation seems much too big. I think 1 page should be
>> sufficient for a system with large pages. Even if not, 0x6d000 is way
>> too large. And they symptoms of failing to reserve the initial
>> pagetable are pretty non-subtle.
>>
>
> Random system halts, deadlocks with interrupts disabled?
> Yup, that sounds familiar.
>
> If I ever get more than a stopped machine with a glowing power light;
> I will be certain to share.
>
Let's see... on a non-PSE system we may need one PDE and one PTE page
per 4 MB, up to 1 GB, for a total of 256 pages or 1 MB of memory, so in
that sense 0x6d000 (109 pages) doesn't sound at all unreasonable
(non-PSE system with 512 MB of RAM?)
However, we shouldn't have to do this kind of hacks with
MAPPING_BEYOND_END, and we *certainly* shouldn't do it by implicitly
hard-coding the value of PAGE_SHIFT.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
Jeremy Fitzhardinge wrote:
>
> Hm, well that does sound serious, but I think you're barking up the
> wrong tree with this particular patch.
>
Well, if it changes behavior it's an indication that the version of gas
he's using is broken (or possibly very old.) What version is it?
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On 07/03/09 12:13, Michael S. Zick wrote:
> On Fri July 3 2009, Jeremy Fitzhardinge wrote:
>
>> On 07/03/09 11:38, Michael S. Zick wrote:
>>
>>> I make no claims for it at the moment - too early in the test process.
>>> Just the general observation that it takes 0.5M to describe 0.5G of ram.
>>>
>>>
>> Only if you're using 4k pages. With large pages, 1 pte can map 2M, so
>> 256 entries can map 512M, so you only need 1/2 a page of pagetable
>> (assuming PAE; if not a single entry can map 4M).
>>
>>
>
> Ah, but you can't assume that - look at your VIA-C7M tech sheet - NO PAE.
>
According to
http://www.via.com.tw/en/products/processors/c7-m/secure_by_design.jsp,
it supports NX, which means it must support PAE.
But even without PAE, it can still support PSE (large pages).
> Try ending the filename in ".S" and passing it to gcc,
> like the build system does.
>
It doesn't make any difference. After going through cpp the expression is:
# 62 "/home/jeremy/git/linux/arch/x86/kernel/head_32.S"
MAPPING_BEYOND_END = (((((1<<32) - 0xC0000000) >> 12) / 512) + 4) << 12
which will be evaluated by the assembler. The C preprocessor doesn't
evaluate expressions in the source; it only ever does substitutions and
leaves the results for the compiler/assembler to evaluate. (It evals
expressions on cpp # lines, of course, but that's not relevant here.)
J
On 07/03/09 12:03, Michael S. Zick wrote:
> Random system halts, deadlocks with interrupts disabled?
> Yup, that sounds familiar.
>
> If I ever get more than a stopped machine with a glowing power light;
> I will be certain to share.
>
Are you saying this patch does actually fix something, or that you still
see the same symptoms with it applied?
J
On Fri July 3 2009, H. Peter Anvin wrote:
> Michael S. Zick wrote:
> >>
> >> The PGTABLE reservation seems much too big. I think 1 page should be
> >> sufficient for a system with large pages. Even if not, 0x6d000 is way
> >> too large. And they symptoms of failing to reserve the initial
> >> pagetable are pretty non-subtle.
> >>
> >
> > Random system halts, deadlocks with interrupts disabled?
> > Yup, that sounds familiar.
> >
> > If I ever get more than a stopped machine with a glowing power light;
> > I will be certain to share.
> >
>
> Let's see... on a non-PSE system we may need one PDE and one PTE page
> per 4 MB, up to 1 GB, for a total of 256 pages or 1 MB of memory, so in
> that sense 0x6d000 (109 pages) doesn't sound at all unreasonable
> (non-PSE system with 512 MB of RAM?)
>
> However, we shouldn't have to do this kind of hacks with
> MAPPING_BEYOND_END, and we *certainly* shouldn't do it by implicitly
> hard-coding the value of PAGE_SHIFT.
>
Good point: (1<<(32-PAGE_SIFT)) would handle other than 4k pages.
I just hardcoded it as a working example of the change from setting
the page table size by design rather than numeric error.
And yes, it has 512Mbyte of ram, so 1/2Mbyte page table sounds right to me.
Mike
> -hpa
>
On Fri July 3 2009, H. Peter Anvin wrote:
> Jeremy Fitzhardinge wrote:
> >
> > Hm, well that does sound serious, but I think you're barking up the
> > wrong tree with this particular patch.
> >
>
> Well, if it changes behavior it's an indication that the version of gas
> he's using is broken (or possibly very old.) What version is it?
>
Whatever Gentoo was shipping with 4.1 - -
System and operator are down for lunch at the moment -
I'll look it up and reply soonest.
Scroll back up to my first post - it does make a difference
with this tool-chain - exactly difference expected if the
tool chain is doing 32-bit calculations.
And since it is a "*.S" file - I think cpp is doing it not gas/as.
Mike
> -hpa
>
Michael S. Zick wrote:
>
> Good point: (1<<(32-PAGE_SIFT)) would handle other than 4k pages.
>
> I just hardcoded it as a working example of the change from setting
> the page table size by design rather than numeric error.
>
As Jeremy pointed out, it's not wrong as written. gas by design uses
arbitrary-precision arithmetic, and even if it didn't, it would still be
correct: (1 << 32) would collapse to 0, so all the rest of the
calculations would still be right.
Any way you can dump out this value from the vmlinux file (nm vmlinux |
grep MAPPING_BEYOND_END) in both cases? What version of as/binutils do
you have installed?
> And yes, it has 512Mbyte of ram, so 1/2Mbyte page table sounds right to me.
/proc/cpuinfo, please?
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On Fri July 3 2009, Jeremy Fitzhardinge wrote:
> On 07/03/09 12:13, Michael S. Zick wrote:
> > On Fri July 3 2009, Jeremy Fitzhardinge wrote:
> >
> >> On 07/03/09 11:38, Michael S. Zick wrote:
> >>
> >>> I make no claims for it at the moment - too early in the test process.
> >>> Just the general observation that it takes 0.5M to describe 0.5G of ram.
> >>>
> >>>
> >> Only if you're using 4k pages. With large pages, 1 pte can map 2M, so
> >> 256 entries can map 512M, so you only need 1/2 a page of pagetable
> >> (assuming PAE; if not a single entry can map 4M).
> >>
> >>
> >
> > Ah, but you can't assume that - look at your VIA-C7M tech sheet - NO PAE.
> >
>
> According to
> http://www.via.com.tw/en/products/processors/c7-m/secure_by_design.jsp,
> it supports NX, which means it must support PAE.
>
Interesting - this *&^&^% technical datasheet contradicts itself (again).
It can't see to decide if it does or it doesn't - -
I guess I will have to ask the silicon - with my own code - I have a
hardware diagnostic here that claims it doesn't (but it is closed source...)
so I don't know if it is testing or guessing.
> But even without PAE, it can still support PSE (large pages).
>
> > Try ending the filename in ".S" and passing it to gcc,
> > like the build system does.
> >
>
> It doesn't make any difference. After going through cpp the expression is:
>
> # 62 "/home/jeremy/git/linux/arch/x86/kernel/head_32.S"
> MAPPING_BEYOND_END = (((((1<<32) - 0xC0000000) >> 12) / 512) + 4) << 12
>
>
> which will be evaluated by the assembler. The C preprocessor doesn't
> evaluate expressions in the source; it only ever does substitutions and
> leaves the results for the compiler/assembler to evaluate. (It evals
> expressions on cpp # lines, of course, but that's not relevant here.)
>
That is probably what I had in my mind - the "# line" case, sorry, my bad.
Mike
> J
> --
> 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
> Please read the FAQ at http://www.tux.org/lkml/
>
>
Michael S. Zick wrote:
> On Fri July 3 2009, H. Peter Anvin wrote:
>> Jeremy Fitzhardinge wrote:
>>> Hm, well that does sound serious, but I think you're barking up the
>>> wrong tree with this particular patch.
>>>
>> Well, if it changes behavior it's an indication that the version of gas
>> he's using is broken (or possibly very old.) What version is it?
>>
>
> Whatever Gentoo was shipping with 4.1 - -
> System and operator are down for lunch at the moment -
> I'll look it up and reply soonest.
>
> Scroll back up to my first post - it does make a difference
> with this tool-chain - exactly difference expected if the
> tool chain is doing 32-bit calculations.
>
> And since it is a "*.S" file - I think cpp is doing it not gas/as.
>
You're wrong. cpp will expand the constants, but as will actually do
the calculation.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On Fri, Jul 3, 2009 at 11:14 AM, Michael S. Zick<[email protected]> wrote:
> Here is one I have found useful in my VIA processor bug hunting:
>
> diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
> index 3068388..2303d86 100644
> --- a/arch/x86/kernel/head_32.S
> +++ b/arch/x86/kernel/head_32.S
> @@ -61,7 +61,7 @@
>
> ?/* Enough space to fit pagetables for the low memory linear map */
> ?MAPPING_BEYOND_END = \
> - ? ? ? PAGE_TABLE_SIZE(((1<<32) - __PAGE_OFFSET) >> PAGE_SHIFT) << PAGE_SHIFT
> + ? ? ? PAGE_TABLE_SIZE((1<<20) - (__PAGE_OFFSET >> PAGE_SHIFT)) << PAGE_SHIFT
>
> ?/*
> ?* Worst-case size of the kernel mapping we need to make:
>
> = = =
>
> Before:
>
> ?#5 [0000010000 - 0000011000] ? ? ? ? ?PGTABLE ==> [0000010000 - 0000011000]
> ?#6 [0000011000 - 0000015000] ? ? ? ? ?BOOTMAP ==> [0000011000 - 0000015000]
>
> After:
>
> ?#5 [0000010000 - 000007d000] ? ? ? ? ?PGTABLE ==> [0000010000 - 000007d000]
> ?#6 [000007d000 - 0000081000] ? ? ? ? ?BOOTMAP ==> [000007d000 - 0000081000]
>
that PGTABLE is from early resource. and it is filled by init_memory_mapping()
it mean preallocated pgtable to MAPPING_BEYOND_END is small now after
patch. and init_memory_mapping try to get more.
please send out whole dmesg. with and without your patch. it could
print out initial mapped before e820 allocation is involved for 32bit
printk(KERN_DEBUG "initial memory mapped : 0 - %08lx\n",
max_pfn_mapped<<PAGE_SHIFT);
your patch should be right. except to change that 12 to PAGE_SHIFT
YH
On Fri, Jul 3, 2009 at 1:07 PM, Yinghai Lu<[email protected]> wrote:
> On Fri, Jul 3, 2009 at 11:14 AM, Michael S. Zick<[email protected]> wrote:
>> Here is one I have found useful in my VIA processor bug hunting:
>>
>> diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
>> index 3068388..2303d86 100644
>> --- a/arch/x86/kernel/head_32.S
>> +++ b/arch/x86/kernel/head_32.S
>> @@ -61,7 +61,7 @@
>>
>> ?/* Enough space to fit pagetables for the low memory linear map */
>> ?MAPPING_BEYOND_END = \
>> - ? ? ? PAGE_TABLE_SIZE(((1<<32) - __PAGE_OFFSET) >> PAGE_SHIFT) << PAGE_SHIFT
>> + ? ? ? PAGE_TABLE_SIZE((1<<20) - (__PAGE_OFFSET >> PAGE_SHIFT)) << PAGE_SHIFT
>>
>> ?/*
>> ?* Worst-case size of the kernel mapping we need to make:
>>
>> = = =
>>
>> Before:
>>
>> ?#5 [0000010000 - 0000011000] ? ? ? ? ?PGTABLE ==> [0000010000 - 0000011000]
>> ?#6 [0000011000 - 0000015000] ? ? ? ? ?BOOTMAP ==> [0000011000 - 0000015000]
>>
>> After:
>>
>> ?#5 [0000010000 - 000007d000] ? ? ? ? ?PGTABLE ==> [0000010000 - 000007d000]
>> ?#6 [000007d000 - 0000081000] ? ? ? ? ?BOOTMAP ==> [000007d000 - 0000081000]
>>
>
> that PGTABLE is from early resource. and it is filled by init_memory_mapping()
>
> it mean preallocated pgtable to MAPPING_BEYOND_END is small now after
> patch. and init_memory_mapping try to get more.
>
> please send out whole dmesg. with and without your patch. it could
> print out initial mapped before e820 allocation is involved for 32bit
> ? ? ? ?printk(KERN_DEBUG "initial memory mapped : 0 - %08lx\n",
> ? ? ? ? ? ? ? ? ? ? ? ?max_pfn_mapped<<PAGE_SHIFT);
>
>
> your patch should be right. except to change that 12 to PAGE_SHIFT
>
mean
>> /* Enough space to fit pagetables for the low memory linear map */
>> MAPPING_BEYOND_END = \
>> - PAGE_TABLE_SIZE(((1<<32) - __PAGE_OFFSET) >> PAGE_SHIFT) << PAGE_SHIFT
>> + PAGE_TABLE_SIZE((1<<(32 - PAGE_SHIFT)) - (__PAGE_OFFSET >> PAGE_SHIFT)) << PAGE_SHIFT
YH
On Fri July 3 2009, H. Peter Anvin wrote:
> Michael S. Zick wrote:
> >
> > Good point: (1<<(32-PAGE_SIFT)) would handle other than 4k pages.
> >
> > I just hardcoded it as a working example of the change from setting
> > the page table size by design rather than numeric error.
> >
>
> As Jeremy pointed out, it's not wrong as written. gas by design uses
> arbitrary-precision arithmetic, and even if it didn't, it would still be
> correct: (1 << 32) would collapse to 0, so all the rest of the
> calculations would still be right.
>
> Any way you can dump out this value from the vmlinux file (nm vmlinux |
> grep MAPPING_BEYOND_END) in both cases?
>
Can't find it in either case, or with objdump.
(g)as reports itself as version 2.18
> What version of as/binutils do
> you have installed?
>
> > And yes, it has 512Mbyte of ram, so 1/2Mbyte page table sounds right to me.
>
> /proc/cpuinfo, please?
>
That takes a running machine - which is a bit of a challenge at the moment.
Well, for the past four months, if truth be told.
Anything in particular you are looking for?
I may have it in my notes and data captures.
Mike
> -hpa
>
Michael S. Zick wrote:
>
> That takes a running machine - which is a bit of a challenge at the moment.
> Well, for the past four months, if truth be told.
>
> Anything in particular you are looking for?
> I may have it in my notes and data captures.
>
The CPUID flags, in particular the pse flag.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On Fri July 3 2009, Yinghai Lu wrote:
> On Fri, Jul 3, 2009 at 11:14 AM, Michael S. Zick<[email protected]> wrote:
> > Here is one I have found useful in my VIA processor bug hunting:
> >
> > diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
> > index 3068388..2303d86 100644
> > --- a/arch/x86/kernel/head_32.S
> > +++ b/arch/x86/kernel/head_32.S
> > @@ -61,7 +61,7 @@
> >
> > ?/* Enough space to fit pagetables for the low memory linear map */
> > ?MAPPING_BEYOND_END = \
> > - ? ? ? PAGE_TABLE_SIZE(((1<<32) - __PAGE_OFFSET) >> PAGE_SHIFT) << PAGE_SHIFT
> > + ? ? ? PAGE_TABLE_SIZE((1<<20) - (__PAGE_OFFSET >> PAGE_SHIFT)) << PAGE_SHIFT
> >
> > ?/*
> > ?* Worst-case size of the kernel mapping we need to make:
> >
> > = = =
> >
> > Before:
> >
> > ?#5 [0000010000 - 0000011000] ? ? ? ? ?PGTABLE ==> [0000010000 - 0000011000]
> > ?#6 [0000011000 - 0000015000] ? ? ? ? ?BOOTMAP ==> [0000011000 - 0000015000]
> >
> > After:
> >
> > ?#5 [0000010000 - 000007d000] ? ? ? ? ?PGTABLE ==> [0000010000 - 000007d000]
> > ?#6 [000007d000 - 0000081000] ? ? ? ? ?BOOTMAP ==> [000007d000 - 0000081000]
> >
>
> that PGTABLE is from early resource. and it is filled by init_memory_mapping()
>
> it mean preallocated pgtable to MAPPING_BEYOND_END is small now after
> patch. and init_memory_mapping try to get more.
>
Ah, so - the labels are a bit misleading - but that makes since.
> please send out whole dmesg. with and without your patch. it could
>
Am having technical problems at the moment - maybe later today I
can get you the information you need.
> print out initial mapped before e820 allocation is involved for 32bit
> printk(KERN_DEBUG "initial memory mapped : 0 - %08lx\n",
> max_pfn_mapped<<PAGE_SHIFT);
>
>
>
> your patch should be right. except to change that 12 to PAGE_SHIFT
>
Not all pages are 4K, but as you point out, that can be fixed.
> YH
>
>
Mike
On Fri July 3 2009, Yinghai Lu wrote:
> On Fri, Jul 3, 2009 at 1:07 PM, Yinghai Lu<[email protected]> wrote:
> > On Fri, Jul 3, 2009 at 11:14 AM, Michael S. Zick<[email protected]> wrote:
> >> Here is one I have found useful in my VIA processor bug hunting:
> >>
> >> diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
> >> index 3068388..2303d86 100644
> >> --- a/arch/x86/kernel/head_32.S
> >> +++ b/arch/x86/kernel/head_32.S
> >> @@ -61,7 +61,7 @@
> >>
> >> ?/* Enough space to fit pagetables for the low memory linear map */
> >> ?MAPPING_BEYOND_END = \
> >> - ? ? ? PAGE_TABLE_SIZE(((1<<32) - __PAGE_OFFSET) >> PAGE_SHIFT) << PAGE_SHIFT
> >> + ? ? ? PAGE_TABLE_SIZE((1<<20) - (__PAGE_OFFSET >> PAGE_SHIFT)) << PAGE_SHIFT
> >>
> >> ?/*
> >> ?* Worst-case size of the kernel mapping we need to make:
> >>
> >> = = =
> >>
> >> Before:
> >>
> >> ?#5 [0000010000 - 0000011000] ? ? ? ? ?PGTABLE ==> [0000010000 - 0000011000]
> >> ?#6 [0000011000 - 0000015000] ? ? ? ? ?BOOTMAP ==> [0000011000 - 0000015000]
> >>
> >> After:
> >>
> >> ?#5 [0000010000 - 000007d000] ? ? ? ? ?PGTABLE ==> [0000010000 - 000007d000]
> >> ?#6 [000007d000 - 0000081000] ? ? ? ? ?BOOTMAP ==> [000007d000 - 0000081000]
> >>
> >
> > that PGTABLE is from early resource. and it is filled by init_memory_mapping()
> >
> > it mean preallocated pgtable to MAPPING_BEYOND_END is small now after
> > patch. and init_memory_mapping try to get more.
> >
> > please send out whole dmesg. with and without your patch. it could
> > print out initial mapped before e820 allocation is involved for 32bit
> > ? ? ? ?printk(KERN_DEBUG "initial memory mapped : 0 - %08lx\n",
> > ? ? ? ? ? ? ? ? ? ? ? ?max_pfn_mapped<<PAGE_SHIFT);
> >
> >
> > your patch should be right. except to change that 12 to PAGE_SHIFT
> >
> mean
>
Yes, want to get the 8K page machines correct also.
>
> >> /* Enough space to fit pagetables for the low memory linear map */
> >> MAPPING_BEYOND_END = \
> >> - PAGE_TABLE_SIZE(((1<<32) - __PAGE_OFFSET) >> PAGE_SHIFT) << PAGE_SHIFT
> >> + PAGE_TABLE_SIZE((1<<(32 - PAGE_SHIFT)) - (__PAGE_OFFSET >> PAGE_SHIFT)) << PAGE_SHIFT
>
You read my mind, thanks.
Mike
> YH
> --
> 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
> Please read the FAQ at http://www.tux.org/lkml/
>
>
On Fri July 3 2009, H. Peter Anvin wrote:
> Michael S. Zick wrote:
> >
> > That takes a running machine - which is a bit of a challenge at the moment.
> > Well, for the past four months, if truth be told.
> >
> > Anything in particular you are looking for?
> > I may have it in my notes and data captures.
> >
>
> The CPUID flags, in particular the pse flag.
>
I haven't touch anything that would have changed that -
so this should be representative (the *&^*% datasheet says yes to pse also)
processor : 0
vendor_id : CentaurHauls
cpu family : 6
model : 13
model name : VIA C7-M Processor 1200MHz
stepping : 0
cpu MHz : 600.024
cache size : 128 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
cmov pat clfl ush acpi mmx fxsr sse sse2 tm nx up pni est tm2 xtpr rng
rng_en ace ace_en ace2 ace2 _en phe phe_en pmm pmm_en
bogomips : 1201.11
clflush size : 64
That's from a 2.6.25 rescue disk - should be close enough.
At least until I get the machine running again.
Mike
> -hpa
>
On Fri July 3 2009, H. Peter Anvin wrote:
> Michael S. Zick wrote:
> >
> > That takes a running machine - which is a bit of a challenge at the moment.
> > Well, for the past four months, if truth be told.
> >
> > Anything in particular you are looking for?
> > I may have it in my notes and data captures.
> >
>
> The CPUID flags, in particular the pse flag.
>
> -hpa
>
OK - got the requested information - also can see that
this whole thing was a false alarm. . .
The before and after of the original post was the difference
between the PAE and non-PAE code path **NOT** the calculation!
My bad, wasn't careful enough in my testing.
I have in-lined the difference between with/without the patch;
and attached the "patched" dmesg output.
> --- dmesg-patched.txt 2009-07-03 16:08:44.000000000 -0500
> +++ dmesg-unpatched.txt 2009-07-03 16:46:38.000000000 -0500
> @@ -1,4 +1,4 @@
> -Linux version 2.6.30-ce1200v-09183 (root@gen2-32) (gcc version 4.1.2
> (Gentoo 4.1.2 p1.1)) #3 PREEMPT Fri Jul 3 12:27:32 CDT 2009 +Linux version
> 2.6.30-ce1200v-09183 (root@gen2-32) (gcc version 4.1.2 (Gentoo 4.1.2 p1.1))
> #4 PREEMPT Fri Jul 3 16:29:35 CDT 2009 KERNEL supported cpus:
> Intel GenuineIntel
> AMD AuthenticAMD
> @@ -59,7 +59,7 @@
> init_memory_mapping: 0000000000000000-000000001bee0000
> 0000000000 - 001bee0000 page 4k
> kernel direct mapping tables up to 1bee0000 @ 10000-83000
> -RAMDISK: 1b8d9000 - 1becf0cc
> +RAMDISK: 1b8d9000 - 1becf1bb
> ACPI: RSDP 000f8470 00014 (v00 PTLTD )
> ACPI: RSDT 1bee5663 00034 (v01 PTLTD RSDT 06040000 LTP 00000000)
> ACPI: FACP 1bee9a46 00074 (v01 CX700 PTLTW 06040000 PTL_ 000F4240)
> @@ -78,7 +78,7 @@
> (7 early reservations) ==> bootmem [0000000000 - 001bee0000]
> #0 [0000000000 - 0000001000] BIOS data page ==> [0000000000 -
> 0000001000] #1 [0000100000 - 0000733430] TEXT DATA BSS ==> [0000100000 -
> 0000733430] - #2 [001b8d9000 - 001becf0cc] RAMDISK ==>
> [001b8d9000 - 001becf0cc] + #2 [001b8d9000 - 001becf1bb] RAMDISK
> ==> [001b8d9000 - 001becf1bb] #3 [000009dc00 - 0000100000] BIOS reserved
> ==> [000009dc00 - 0000100000] #4 [0000734000 - 00007370f1] BRK
> ==> [0000734000 - 00007370f1] #5 [0000010000 - 000007d000] PGTABLE
> ==> [0000010000 - 000007d000] @@ -127,7 +127,7 @@
> NR_IRQS:288
> PID hash table entries: 2048 (order: 11, 8192 bytes)
> Fast TSC calibration using PIT
> -Detected 600.021 MHz processor.
> +Detected 599.982 MHz processor.
> Console: colour VGA+ 80x25
> console [tty0] enabled
> Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
> @@ -144,7 +144,7 @@
> .text : 0xc0100000 - 0xc050f40a (4157 kB)
> Checking if this processor honours the WP bit even in supervisor
> mode...Ok. SLUB: Genslabs=13, HWalign=64, Order=0-3, MinObjects=0, CPUs=1,
> Nodes=1 -Calibrating delay loop (skipped), value calculated using timer
> frequency.. 1200.04 BogoMIPS (lpj=2000070) +Calibrating delay loop
> (skipped), value calculated using timer frequency.. 1200.96 BogoMIPS
> (lpj=1999940) Security Framework initialized
> Smack: Initializing.
> Mount-cache hash table entries: 512
> @@ -163,7 +163,7 @@
> ....... works.
> net_namespace: 996 bytes
> regulator: core version 0.5
> -Time: 21:04:35 Date: 07/03/09
> +Time: 21:44:23 Date: 07/03/09
> NET: Registered protocol family 16
> ACPI: bus type pci registered
> PCI: MCFG configuration 0: base e0000000 segment 0 buses 3 - 3
> @@ -386,9 +386,6 @@
> serio: i8042 AUX2 port at 0x60,0x64 irq 12
> serio: i8042 AUX3 port at 0x60,0x64 irq 12
> mice: PS/2 mouse device common for all mice
> -ata2.00: ATA-7: ST730212DE, 3.01, max UDMA/66
> -ata2.00: 58605120 sectors, multi 16: LBA48
> -ata2.00: limited to UDMA/33 due to 40-wire cable
> rtc_cmos 00:03: RTC can wake from S4
> rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0
> rtc0: alarms up to one year, y3k, 242 bytes nvram
> @@ -406,10 +403,12 @@
> usbcore: registered new interface driver usbhid
> usbhid: v2.6:USB HID core driver
> Advanced Linux Sound Architecture Driver Version 1.0.20.
> +ata2.00: ATA-7: ST730212DE, 3.01, max UDMA/66
> +ata2.00: 58605120 sectors, multi 16: LBA48
> +ata2.00: limited to UDMA/33 due to 40-wire cable
> HDA Intel 0000:02:01.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
> HDA Intel 0000:02:01.0: setting latency timer to 64
> HDA Intel 0000:02:01.0: PCI: Disallowing DAC for device
> -input: AT Translated Set 2 keyboard as
> /devices/platform/i8042/serio0/input/input4 ata2.00: configured for UDMA/33
> scsi 1:0:0:0: Direct-Access ATA ST730212DE 3.01 PQ: 0 ANSI:
> 5 sd 1:0:0:0: Attached scsi generic sg0 type 0
> @@ -417,7 +416,8 @@
> sd 1:0:0:0: [sda] Write Protect is off
> sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00
> sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
> support DPO or FUA - sda: sda1 sda2 sda3 sda4
> + sda:<6>input: AT Translated Set 2 keyboard as
> /devices/platform/i8042/serio0/input/input4 + sda1 sda2 sda3 sda4
> sd 1:0:0:0: [sda] Attached SCSI disk
> ALSA device list:
> #0: HDA VIA VT82xx at 0xd1000000 irq 17
> @@ -442,8 +442,9 @@
> PM: Checking hibernation image.
> PM: Resume from disk failed.
> registered taskstats version 1
> - Magic number: 1:970:94
> -rtc_cmos 00:03: setting system clock to 2009-07-03 21:04:38 UTC
> (1246655078) + Magic number: 1:144:752
> +tty ttyS3: hash matches
> +rtc_cmos 00:03: setting system clock to 2009-07-03 21:44:26 UTC
> (1246657466) BIOS EDD facility v0.16 2004-Jun-25, 0 devices found
> EDD information not available.
> debug: unmapping init memory c0692000..c06f1000
Sorry about the fuss - really sorry.
Mike
Michael S. Zick wrote:
>>>
>> The CPUID flags, in particular the pse flag.
>>
>
> I haven't touch anything that would have changed that -
> so this should be representative (the *&^*% datasheet says yes to pse also)
>
Actually, come to think of it, we don't generate PSE page tables
initially -- we only later go in and reclaim the page tables if we
switch to PSE (and $DEITY knows if we're doing it correctly...)
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On Fri July 3 2009, H. Peter Anvin wrote:
> Michael S. Zick wrote:
> >>>
> >> The CPUID flags, in particular the pse flag.
> >>
> >
> > I haven't touch anything that would have changed that -
> > so this should be representative (the *&^*% datasheet says yes to pse also)
> >
>
> Actually, come to think of it, we don't generate PSE page tables
> initially -- we only later go in and reclaim the page tables if we
> switch to PSE (and $DEITY knows if we're doing it correctly...)
>
I am of that age range where senility has to be considered, but not this time:
"Via C7-M Datasheet", May 2008 (supposed to be most recent) -
page 22 - section 2.3.7 - Table 2-14 "CR4 Bits"
"<5> PAE: Enables address extensions; C7-M:<r>"
<quote>An "r" means that this bit is reserved. It appears as a 0 when read,
and a GP exception is signaled if an attemp is made to write a 1 to this bit.</quote>
Same document -
page 16 - section 2.3.2 - Table 2-3 "CPUID Feature Flag Values (EAX=1)"
<EDX:6> PAE: Physical address extensions; C7:<1>
So take your pick - it might be there or it might not - - -
If you like that one, read the MCE bit "Documentation" ;)
Note: When this bit is (attempted) to be set in head.S I think that the
GP fault is still "no-opted" by that dummy routine.
So we would never hear about it.
Also, according to H.W. the NX bit is a lie told to keep some OS's happy.
And then, of course, the silicon can have micro-code updates - -
All bets are off if mine works the same as yours does. ;)
Mike
> -hpa
>
Michael S. Zick wrote:
> On Fri July 3 2009, H. Peter Anvin wrote:
>> Michael S. Zick wrote:
>>>> The CPUID flags, in particular the pse flag.
>>>>
>>> I haven't touch anything that would have changed that -
>>> so this should be representative (the *&^*% datasheet says yes to pse also)
>>>
>> Actually, come to think of it, we don't generate PSE page tables
>> initially -- we only later go in and reclaim the page tables if we
>> switch to PSE (and $DEITY knows if we're doing it correctly...)
>>
>
> I am of that age range where senility has to be considered, but not this time:
>
> "Via C7-M Datasheet", May 2008 (supposed to be most recent) -
>
> page 22 - section 2.3.7 - Table 2-14 "CR4 Bits"
> "<5> PAE: Enables address extensions; C7-M:<r>"
> <quote>An "r" means that this bit is reserved. It appears as a 0 when read,
> and a GP exception is signaled if an attemp is made to write a 1 to this bit.</quote>
>
> Same document -
> page 16 - section 2.3.2 - Table 2-3 "CPUID Feature Flag Values (EAX=1)"
> <EDX:6> PAE: Physical address extensions; C7:<1>
Especially since I was talking about PSE and not PAE.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On Fri July 3 2009, H. Peter Anvin wrote:
> Michael S. Zick wrote:
> >>
> >> The PGTABLE reservation seems much too big. I think 1 page should be
> >> sufficient for a system with large pages. Even if not, 0x6d000 is way
> >> too large. And they symptoms of failing to reserve the initial
> >> pagetable are pretty non-subtle.
> >>
> >
> > Random system halts, deadlocks with interrupts disabled?
> > Yup, that sounds familiar.
> >
> > If I ever get more than a stopped machine with a glowing power light;
> > I will be certain to share.
> >
>
> Let's see... on a non-PSE system we may need one PDE and one PTE page
> per 4 MB, up to 1 GB, for a total of 256 pages or 1 MB of memory, so in
> that sense 0x6d000 (109 pages) doesn't sound at all unreasonable
> (non-PSE system with 512 MB of RAM?)
>
> However, we shouldn't have to do this kind of hacks with
> MAPPING_BEYOND_END, and we *certainly* shouldn't do it by implicitly
> hard-coding the value of PAGE_SHIFT.
>
The calculation was correct - this thread title is a false alarm.
The difference posted was caused by disabling the "has pae" in the
build configuration system.
So I just need to dig around in head.S a bit more - get rid of the
"Intel Only" hard coding, check if the pae bit is a hardwired zero
in cr4, make sure I have a usable stack before the testing - since
the test may generate a GP fault. . .
Get the in-memory copy of the cpu feature flags correct (some are
defined but not implemented on this processor). . .
Then find and fix everything that isn't using 'cpu_has(x, y)' -
That should keep me busy for a few weeks. ;)
Mike
> -hpa
>