From: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
jbarnes@virtuousgeek.org
Subject: Re: [PATCH 2/4] x86: ioremap: fix physical address check
Date: Mon, 14 Jun 2010 10:54:23 +0900 [thread overview]
Message-ID: <4C158BCF.6000303@jp.fujitsu.com> (raw)
In-Reply-To: <4C1275BF.3070605@zytor.com>
(2010/06/12 2:43), H. Peter Anvin wrote:
> On 06/11/2010 02:20 AM, Kenji Kaneshige wrote:
>> If the physical address is too high to be handled by ioremap() in
>> x86_32 PAE (e.g. more than 36-bit physical address), ioremap() must
>> return error (NULL). However, current x86 ioremap try to map this too
>> high physical address, and it causes unexpected behavior.
>
> What unexpected behavior?
My expectation:
The ioremap() function returns NULL if the specified physical address
is too high to handle.
Actual result (unexpected behavior):
Kernel hangup. This happens even with [PATCH 1/4] applied. I'm attaching
the console log messages at the bottom of this e-mail.
> It is perfectly legitimately to map such a
> high address in PAE mode. We have a 36-bit kernel-imposed limit on
> *RAM* in 32-bit mode (because we can't manage more than that), but there
> is no reason it should apply to I/O.
>
Do you mean x86 linux can map physical address higher than 36-bit for I/O?
My understanding is as follows.
- Architectural limit of physical address in x86 32-bit mode is 40-bit
(depnds on processor version).
- The maximum physical address supported by current x86 linux kernel in
32-bit mode is 36-bit.
On my environment, physical address higher than 40-bit (ex. 0xfc00001c000)
is assigned to some PCI devices. I think there is no way to handle such
high physical address in 32-bit mode.
Thanks,
Kenji Kaneshige
======================================================================
Console Messages (2.6.34 + [PATCH 1/4] applied) after modprobe ioatdma
======================================================================
ioatdma: Intel(R) QuickData Technology Driver 4.00
ioatdma 0000:00:16.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
ioatdma 0000:00:16.0: setting latency timer to 64
modprobe:5619 freeing invalid memtype 1c000-20000
ioatdma 0000:00:16.0: PCI INT A disabled
ioatdma 0000:00:16.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
ioatdma 0000:00:16.1: setting latency timer to 64
ioatdma 0000:00:16.1: (26) exceeds max supported channels (4)
ioatdma 0000:00:16.1: channel enumeration error
ioatdma 0000:00:16.1: Intel(R) I/OAT DMA Engine init failed
modprobe:5619 freeing invalid memtype 18000-1c000
ioatdma 0000:00:16.1: PCI INT B disabled
ioatdma 0000:00:16.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
ioatdma 0000:00:16.2: setting latency timer to 64
ioatdma 0000:00:16.2: (20) exceeds max supported channels (4)
alloc irq_desc for 80 on node -1
alloc kstat_irqs on node -1
ioatdma 0000:00:16.2: irq 80 for MSI/MSI-X
BUG: soft lockup - CPU#0 stuck for 61s! [modprobe:5619]
Modules linked in: ioatdma(+) autofs4 sunrpc cpufreq_ondemand acpi_cpufreq ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 dm_mirror dm_region_hash dm_log dm_mod e1000e igb iTCO_wdt dca sg iTCO_vendor_support i2c_i801 i2c_core pcspkr ext4 mbcache jbd2 sd_mod crc_t10dif mptsas mptscsih lpfc scsi_transport_fc mptbase scsi_tgt scsi_transport_sas [last unloaded: microcode]
Modules linked in: ioatdma(+) autofs4 sunrpc cpufreq_ondemand acpi_cpufreq ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 dm_mirror dm_region_hash dm_log dm_mod e1000e igb iTCO_wdt dca sg iTCO_vendor_support i2c_i801 i2c_core pcspkr ext4 mbcache jbd2 sd_mod crc_t10dif mptsas mptscsih lpfc scsi_transport_fc mptbase scsi_tgt scsi_transport_sas [last unloaded: microcode]
Pid: 5619, comm: modprobe Not tainted 2.6.34-kk #20 SB/PRIMEQUEST 1800E
EIP: 0060:[<c07ed5e8>] EFLAGS: 00000202 CPU: 0
EIP is at _raw_spin_lock_bh+0x18/0x20
EAX: e3608000 EBX: e305fb5c ECX: 0000007d EDX: 00000001
ESI: 0000007d EDI: e305fa94 EBP: e3609d18 ESP: e3609ccc
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process modprobe (pid: 5619, ti=e3608000 task=e167fab0 task.ti=e3608000)
Stack:
e305fa94 fe577cc6 205f9002 00000000 c05e5377 000fffff 01000000 00000257
<0> e3f25240 fffff000 0000ffff 00000001 00000001 e3609dae 000fffff e305fb5c
<0> ffffe000 00000000 e305fa94 e3609dbc fe578512 205f9000 00000000 e34e0c00
Call Trace:
[<fe577cc6>] ? ioat2_alloc_and_lock+0x26/0x280 [ioatdma]
[<c05e5377>] ? __domain_mapping+0x177/0x260
[<fe578512>] ? ioat2_dma_prep_memcpy_lock+0x52/0x3c0 [ioatdma]
[<c05e7339>] ? __intel_map_single+0x169/0x230
[<c05e7456>] ? intel_map_page+0x56/0x70
[<fe575762>] ? dma_map_single_attrs.clone.1+0x62/0x80 [ioatdma]
[<fe57cd29>] ? ioat_dma_self_test+0xf4/0x248 [ioatdma]
[<c049c048>] ? devm_request_threaded_irq+0x78/0xa0
[<fe57da6c>] ? ioat3_dma_self_test+0x8/0x16 [ioatdma]
[<fe57cb1c>] ? ioat_probe+0x2d7/0x343 [ioatdma]
[<fe57d092>] ? ioat3_dma_probe+0x145/0x1d1 [ioatdma]
[<fe57c7e0>] ? ioat_pci_probe+0x14b/0x181 [ioatdma]
[<c05cd92b>] ? local_pci_probe+0xb/0x10
[<c05ce937>] ? pci_device_probe+0xc7/0xf0
[<c0672d17>] ? driver_probe_device+0x87/0x290
[<c05cd9d0>] ? pci_match_device+0x10/0xb0
[<c0672f99>] ? __driver_attach+0x79/0x80
[<c0672f20>] ? __driver_attach+0x0/0x80
[<c0672112>] ? bus_for_each_dev+0x52/0x80
[<c0672b06>] ? driver_attach+0x16/0x20
[<c0672f20>] ? __driver_attach+0x0/0x80
[<c06724bf>] ? bus_add_driver+0x1cf/0x320
[<c05ce810>] ? pci_device_remove+0x0/0x40
[<c0673223>] ? driver_register+0x63/0x120
[<fe584000>] ? ioat_init_module+0x0/0x79 [ioatdma]
[<c05ceb5d>] ? __pci_register_driver+0x3d/0xb0
[<fe584062>] ? ioat_init_module+0x62/0x79 [ioatdma]
[<c040112f>] ? do_one_initcall+0x2f/0x1c0
[<c047bb23>] ? sys_init_module+0xb3/0x220
[<c07ee2f0>] ? do_device_not_available+0x0/0x60
[<c07ee335>] ? do_device_not_available+0x45/0x60
[<c0402f1f>] ? sysenter_do_call+0x12/0x28
next prev parent reply other threads:[~2010-06-14 1:55 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-11 9:17 [RFC][PATCH 0/4] x86: ioremap() problem in X86_32 PAE Kenji Kaneshige
2010-06-11 9:18 ` [PATCH 1/4] x86: ioremap: fix wrong address masking Kenji Kaneshige
2010-06-11 9:20 ` [PATCH 2/4] x86: ioremap: fix physical address check Kenji Kaneshige
2010-06-11 17:43 ` H. Peter Anvin
2010-06-14 0:18 ` KAMEZAWA Hiroyuki
2010-06-14 8:59 ` KAMEZAWA Hiroyuki
2010-06-14 9:13 ` Kenji Kaneshige
2010-06-14 11:06 ` Kenji Kaneshige
2010-06-14 18:36 ` H. Peter Anvin
2010-06-15 2:21 ` Kenji Kaneshige
2010-06-14 20:16 ` Rolf Eike Beer
2010-06-15 2:33 ` Kenji Kaneshige
2010-06-14 1:54 ` Kenji Kaneshige [this message]
2010-06-14 6:38 ` Maciej W. Rozycki
2010-06-14 8:23 ` Kenji Kaneshige
2010-06-14 9:02 ` Kenji Kaneshige
2010-06-14 15:40 ` H. Peter Anvin
2010-06-14 15:11 ` H. Peter Anvin
2010-06-14 8:27 ` Kenji Kaneshige
2010-06-14 15:12 ` H. Peter Anvin
2010-06-11 9:20 ` [PATCH 3/4] x86: ioremap: remove physical address warning message Kenji Kaneshige
2010-06-11 17:44 ` H. Peter Anvin
2010-06-14 2:06 ` Kenji Kaneshige
2010-06-11 9:21 ` [PATCH 4/4] x86: ioremap: fix normal ram range check Kenji Kaneshige
2010-06-11 17:41 ` [RFC][PATCH 0/4] x86: ioremap() problem in X86_32 PAE H. Peter Anvin
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=4C158BCF.6000303@jp.fujitsu.com \
--to=kaneshige.kenji@jp.fujitsu.com \
--cc=hpa@zytor.com \
--cc=jbarnes@virtuousgeek.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox