Prev: x86: ioremap() problem in X86_32 PAE
Next: [PATCH] um: call free_irq() only on enabled channels
From: H. Peter Anvin on 14 Jun 2010 11:20
On 06/13/2010 11:38 PM, Maciej W. Rozycki wrote:
> On Mon, 14 Jun 2010, Kenji Kaneshige wrote:
>
>> - Architectural limit of physical address in x86 32-bit mode is 40-bit
>> (depnds on processor version).
>
> According to documentation I happen to have handy this limit is actually
> 52 bits (and space is currently available in the data structures used for
> a possible future extension up to 63 bits).
>

Yes. There are, however, very likely bugs in several classes due to
incorrect bitmasks as well as 32-bit PFNs.

We have made the decision based on data structure limitations (and just
usability) to not support more than 2^36 bytes of RAM on 32 bits, but
those data structures should not affect I/O. I;d like to track down and
fix the bugs instead of papering over the problem...

-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 14 Jun 2010 11:50
On 06/14/2010 02:02 AM, Kenji Kaneshige wrote:
>
> Now I guess there is a bug that doesn't handle physical address
> higher than 32-bit properly somewhere...
>

More than one bug, almost certainly.

Note that all this applies to PAE mode. Non-PAE mode has a 32-bit
limit, period.

-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 14 Jun 2010 14:40
On 06/14/2010 04:06 AM, Kenji Kaneshige wrote:
> Index: linux-2.6.34/include/linux/vmalloc.h
> ===================================================================
> --- linux-2.6.34.orig/include/linux/vmalloc.h
> +++ linux-2.6.34/include/linux/vmalloc.h
> @@ -30,7 +30,7 @@ struct vm_struct {
> unsigned long flags;
> struct page **pages;
> unsigned int nr_pages;
> - unsigned long phys_addr;
> + phys_addr_t phys_addr;
> void *caller;
> };

This really doesn't look right at all. If this was required then it
would seem that anything using high addresses would be broken... as such
I can only assume it matters only for lowmem pages...

-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Rolf Eike Beer on 14 Jun 2010 16:30
Kenji Kaneshige wrote:
> (2010/06/14 18:13), Kenji Kaneshige wrote:
> > Thank you Hiroyuki.
> >
> > So many bugs in ioremap()...
> >
> > Will try with those bugs fixed.
> >
> > Thanks,
> > Kenji Kaneshige
>
> The problem seems to be fixed by the following patch. This is still
> under testing. I will post the patch as v2 after testing.
>
> Thanks,
> Kenji Kaneshige
>
>
> Current x86 ioremap() doesn't handle physical address higher than
> 32-bit properly in X86_32 PAE mode. When physical address higher than
> 32-bit is passed to ioremap(), higher 32-bits in physical address is
> cleared wrongly. Due to this bug, ioremap() can map wrong address to
> linear address space.
>
> In my case, 64-bit MMIO region was assigned to a PCI device (ioat
> device) on my system. Because of the ioremap()'s bug, wrong physical
> address (instead of MMIO region) was mapped to linear address space.
> Because of this, loading ioatdma driver caused unexpected behavior
> (kernel panic, kernel hangup, ...).
>
> Signed-off-by: Kenji Kaneshige <kaneshige.kenji(a)jp.fujitsu.com>
>
> ---
> arch/x86/mm/ioremap.c | 11 +++++------
> include/linux/io.h | 4 ++--
> include/linux/vmalloc.h | 2 +-
> lib/ioremap.c | 10 +++++-----
> 4 files changed, 13 insertions(+), 14 deletions(-)
>
> Index: linux-2.6.34/arch/x86/mm/ioremap.c
> ===================================================================
> --- linux-2.6.34.orig/arch/x86/mm/ioremap.c
> +++ linux-2.6.34/arch/x86/mm/ioremap.c
> @@ -62,7 +62,8 @@ int ioremap_change_attr(unsigned long va
> static void __iomem *__ioremap_caller(resource_size_t phys_addr,
> unsigned long size, unsigned long prot_val, void *caller)
> {
> - unsigned long pfn, offset, vaddr;
> + u64 pfn, last_pfn;
> + unsigned long offset, vaddr;
> resource_size_t last_addr;
> const resource_size_t unaligned_phys_addr = phys_addr;
> const unsigned long unaligned_size = size;

Why do you use u64 and not resource_size_t for those? That way this would not
be needlessly big for "real" 32 bit platforms.

Eike
From: Kenji Kaneshige on 14 Jun 2010 22:30
(2010/06/15 3:36), H. Peter Anvin wrote:
> On 06/14/2010 04:06 AM, Kenji Kaneshige wrote:
>> Index: linux-2.6.34/include/linux/vmalloc.h
>> ===================================================================
>> --- linux-2.6.34.orig/include/linux/vmalloc.h
>> +++ linux-2.6.34/include/linux/vmalloc.h
>> @@ -30,7 +30,7 @@ struct vm_struct {
>> unsigned long flags;
>> struct page **pages;
>> unsigned int nr_pages;
>> - unsigned long phys_addr;
>> + phys_addr_t phys_addr;
>> void *caller;
>> };
>
> This really doesn't look right at all. If this was required then it
> would seem that anything using high addresses would be broken... as such
> I can only assume it matters only for lowmem pages...
>

Without this change, /pric/vmallocinfo doesn't display physcal address info
properly (need also to change s_show() in mm/vmalloc (%lx in seq_printf()).

Thanks,
Kenji Kaneshige

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: x86: ioremap() problem in X86_32 PAE
Next: [PATCH] um: call free_irq() only on enabled channels