All of lore.kernel.org
 help / color / mirror / Atom feed
From: TAKADA Yoshihito <takada@mbf.nifty.com>
To: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Cc: hpa@zytor.com, tglx@linutronix.de, mingo@redhat.com,
	linux-kernel@vger.kernel.org, matthew@wil.cx,
	macro@linux-mips.org, kamezawa.hiroyu@jp.fujitsu.com,
	eike-kernel@sf-tec.de, jeremy@goop.org,
	linux-pci@vger.kernel.org
Subject: Re: [BUG][PATCH 0/2 (v.3)] x86: ioremap() problem in X86_32 PAE
Date: Thu, 10 Feb 2011 23:11:24 +0900	[thread overview]
Message-ID: <AANLkTinhN1+bM6qABR28fR41T0+X_xSN8C4R2Ev1g-Gt@mail.gmail.com> (raw)
In-Reply-To: <4C1AE64C.6040609@jp.fujitsu.com>

Hi.
I faced same probrem, too. I use x86_64 kernel.
Your patch fix it. it's very effective.
Thanks!

2010年6月18日12:21 Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>:
> Hi,
>
> Here is a updated version (v.3) of patchset to fix ioremap() related
> problem found in x86 32-bit mode. The problem is that ioremap() maps
> wrong address for the device to which phisical addres higer than
> 32-bit is assigned (ioat device in my case).
>
> The v.3 patches are:
>
> - [PATCH 1/2] x86: ioremap: fix wrong physical address handling
> - [PATCH 2/2] x86: ioremap: fix normal ram range check
>
> Changelog
> ---------
> v.2=>v.3:
> - Matthew Wilcox suggested changing PAGE_MASK definition. But I think
>  it is a little risky. Instead of changing PAGE_MASK, v.3 patch uses
>  PHYSICAL_PAGE_MASK(*) to mask physical address again, as v.1 patch
>  did. The PHYSICAL_PAGE_MASK doesn't work for higher than 2^44
>  physical address because __PHYSICAL_MASK_SHIFT is 44 in x86_32
>  PAE(*). But this time, I focus on making 2^44 work correctly.
>
> (*) Current X86_32 PAE kernel would not work with physical address
>    higher than 2^44, because PFNs are handled using 32-bit variable
>    (unsigned long) probably in many places. This seems the reason why
>    __PHYSICAL_MASK_SHIFT is limited to 44 (=32+12 is the limit we can
>    fit into an unsigned long pfn). When x86 PAE linux becomes above
>    2^44 physical address capable in someday, __PHYSICAL_MASK_SHIFT
>    should become greater value than 44.
>
>
> v.1=>v.2:
> The v.1 patchset was based on my misunderstanding about architectural
> limit and linux memory management limit of physical address. So some
> patches in v.1 were totally wrong fixes and they are removed. Thanks
> to the feedbacks for v.1 patchset, it turned out that phsical address
> is handled improperly (higher 32-bits are cleared unexpectedly) also
> in the other places than where v.1 patchset fixed. Here are summary of
> changes.
>
> - Stop using PHYSICAL_PAGE_MASK to align physical address because
>  PHYSICAL_PAGE_MASK would not work if physical address is higher than
>  44-bit.
> - Fix remaining bugs of physical address handling in ioremap() code
>  path according to the feedbacks.
> - Fix s_show() in vmalloc.c to show high physical address properly.
> - Removed changes against phys_addr_valid() ([PATCH 2/4] in v.1).
> - Removed changes against warning message in ioremap() ([PATCH 3/4] in
>  v.1).
>
> Thanks,
> Kenji Kaneshige
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

  parent reply	other threads:[~2011-02-10 14:11 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-18  3:21 [BUG][PATCH 0/2 (v.3)] x86: ioremap() problem in X86_32 PAE Kenji Kaneshige
2010-06-18  3:22 ` [PATCH 1/2] x86: ioremap: fix wrong physical address handling Kenji Kaneshige
2010-06-18 11:07   ` Jeremy Fitzhardinge
2010-06-21  1:40     ` Kenji Kaneshige
2010-07-09 19:18   ` [tip:x86/mm] x86, ioremap: Fix incorrect physical address handling in PAE mode tip-bot for Kenji Kaneshige
2010-06-18  3:23 ` [PATCH 2/2] x86: ioremap: fix normal ram range check Kenji Kaneshige
2010-07-09 19:19   ` [tip:x86/mm] x86, ioremap: Fix " tip-bot for Kenji Kaneshige
2010-06-18  6:31 ` [BUG][PATCH 0/2 (v.3)] x86: ioremap() problem in X86_32 PAE H. Peter Anvin
2011-02-10 14:11 ` TAKADA Yoshihito [this message]
2011-02-11  7:55   ` Kenji Kaneshige

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AANLkTinhN1+bM6qABR28fR41T0+X_xSN8C4R2Ev1g-Gt@mail.gmail.com \
    --to=takada@mbf.nifty.com \
    --cc=eike-kernel@sf-tec.de \
    --cc=hpa@zytor.com \
    --cc=jeremy@goop.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kaneshige.kenji@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=macro@linux-mips.org \
    --cc=matthew@wil.cx \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.