From: Steve Holland <sdh4_no_spammers_throwaway_acct@cornell.edu>
To: linux-kernel@vger.kernel.org
Subject: x86-64 general protection fault in ioremap_nocache() possibly related to memory beyond 4GB
Date: Tue, 22 Jun 2004 20:08:24 -0500 [thread overview]
Message-ID: <1087952903.4010.132.camel@gavroche> (raw)
I'm having a memory/io mapping related problem with the 2.6 kernel
(as shipped with Fedora Core 2, tested with kernel-2.6.5-1.358
and kernel-2.6.6-1.435).
My system has a dual Opteron Tyan K8W with 4 GB of ram. Half of that
memory is mapped by the BIOS beyond 4GB, leaving plenty of address space
between 2GB and 4GB for pci devices.
If I tell the kernel (via mem=0x80000000) to only use the first 2GB, all
of these problems go away. There were also no problems doing any of
these things under a previous installation 2.4 x86-64 kernel.
Hence the problem seems to be related to the presence of memory beyond
the 4GB boundary.
I have seen three different symptoms of this one problem. These all
appear independent of each other:
1. Oops in ioremap_nocache() during modprobe of ohci-hcd.ko during
rc.sysinit.
2. X locks up on startup (Radeon driver) with general protection
fault (even with dri, etc. disabled):
Jun 22 17:28:41 eponine kernel: general protection fault: 0000 [1] SMP
Jun 22 17:28:41 eponine kernel: CPU 0
Jun 22 17:28:41 eponine kernel: Modules linked in: ipv6 parport_pc lp parport autofs4 tg3 ipt_REJECT ipt_state ip_conntrack iptable_filter ip_tables dm_mod ext3 jbd sata_sil libata sd_mod scsi_mod
Jun 22 17:28:41 eponine kernel: Pid: 2658, comm: X Not tainted 2.6.6-1.435smp
Jun 22 17:28:41 eponine kernel: RIP: 0010:[<ffffffff8015f3c8>] <ffffffff8015f3c8>{remap_page_range+407}
Jun 22 17:28:41 eponine kernel: Call Trace:<ffffffff801f85bc>{mmap_mem+224} <ffffffff80161f3f>{do_mmap_pgoff+1186}
Jun 22 17:28:41 eponine kernel: <ffffffff80117849>{sys_mmap+135} <ffffffff801112c6>{system_call+126}
Jun 22 17:28:41 eponine kernel: Code: 48 2b 82 f0 18 00 00 48 6b c0 38 48 03 82 e0 18 00 00 8b 00
3. A driver (with which I am very familiar with the internals) gets a general protection fault
during insmod. This driver starts by calling pci_set_dma_mask(), then calls request_mem_region() for several smallish
(a few kb or less) chunks found with pci_resource_start() and pci_resource_len(). It then calls
ioremap_nocache() on one of these chunks, but ioremap_nocache() fails with a general protection fault:
Jun 22 17:37:04 eponine kernel: general protection fault: 0000 [1] SMP
Jun 22 17:37:04 eponine kernel: CPU 0
Jun 22 17:37:04 eponine kernel: Modules linked in: pci_das4020_12 ipv6 parport_pc lp parport autofs4 tg3 ipt_REJECT ipt_state ip_conntrack iptable_filter ip_tables dm_mod ext3 jbd sata_sil libata sd_mod scsi_mod
Jun 22 17:37:04 eponine kernel: Pid: 2655, comm: insmod Not tainted 2.6.6-1.435smp
Jun 22 17:37:04 eponine kernel: RIP: 0010:[<ffffffff80122e38>] <ffffffff80122e38>{ioremap_nocache+197}
Jun 22 17:37:04 eponine kernel: Call Trace:<ffffffffa01081c5>{:pci_das4020_12:das4020_init_one+453}
Jun 22 17:37:04 eponine kernel: <ffffffff801d5a73>{pci_device_probe_static+47} <ffffffff801d5aa7>{__pci_device_probe+30}
Jun 22 17:37:04 eponine kernel: <ffffffff801d5ae1>{pci_device_probe+37} <ffffffff801d5abc>{pci_device_probe+0}
Jun 22 17:37:04 eponine kernel: <ffffffff80218831>{bus_match+57} <ffffffff80218938>{driver_attach+68}
Jun 22 17:37:04 eponine kernel: <ffffffff80218b7d>{bus_add_driver+112} <ffffffff80176590>{exact_match+0}
Jun 22 17:37:04 eponine kernel: <ffffffff801d5cd2>{pci_register_driver+111} <ffffffffa011004f>{:pci_das4020_12:das4020_init+79}
Jun 22 17:37:04 eponine kernel: <ffffffff8014ad48>{sys_init_module+264} <ffffffff801112c6>{system_call+126}
Jun 22 17:37:04 eponine kernel: Code: 48 8b 8f f0 18 00 00 76 10 48 b8 00 00 00 80 00 01 00 00 48
As I mentioned above, the problems only occur when using the 2GB of memory above 4GB.
Jun 22 20:05:40 eponine kernel: BIOS-provided physical RAM map:
Jun 22 20:05:40 eponine kernel: BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
Jun 22 20:05:40 eponine kernel: BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
Jun 22 20:05:40 eponine kernel: BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
Jun 22 20:05:40 eponine kernel: BIOS-e820: 0000000000100000 - 0000000080000000 (usable)
Jun 22 20:05:40 eponine kernel: BIOS-e820: 00000000ff7c0000 - 0000000100000000 (reserved)
Jun 22 20:05:40 eponine kernel: BIOS-e820: 0000000100000000 - 0000000180000000 (usable)
All these things worked normally under the 2.4 kernel of Fedora Core 1
Thanks,
Steve
ess dee h 4 at cornell dot edu
next reply other threads:[~2004-06-23 1:10 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-23 1:08 Steve Holland [this message]
2004-06-24 18:54 ` x86-64 general protection fault in ioremap_nocache() possibly related to memory beyond 4GB Steve Holland
[not found] <2a4AK-6Ww-11@gated-at.bofh.it>
2004-06-23 10:43 ` Andi Kleen
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=1087952903.4010.132.camel@gavroche \
--to=sdh4_no_spammers_throwaway_acct@cornell.edu \
--cc=linux-kernel@vger.kernel.org \
/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.