From: "Eitan Ben-Nun" <eitan@sangate.com>
To: <linux-kernel@vger.kernel.org>
Cc: "Eitan Ben-Nun" <eitan@sangate.com>, "Uri Lublin" <uri@sangate.com>
Subject: Adpter card read old memory value
Date: Tue, 1 Oct 2002 15:43:09 +0300 [thread overview]
Message-ID: <B71796881E0DF7409F066FE6656BDF2906F78A@beasley> (raw)
This seems like a cache coherency problem:
An adapter card on the pci bus send a message to pc i386 Linux to update a memory address.
Then it reads the address and sees an old value, even though the pc cpu have performed an update to this memory address.
Environment:
SKA4 - (koa board) with two Intel Pentium III Xeon processors, running Linux, kernel 2.4.18-5 SMP.
The Server has 1Giga Byte physical memory, but Linux operating system is aware of 512M only.
In lilo.conf it indicates to use only 512M (from lilo.conf: append="mem=512M, nousb").
The upper 512M is managed by specialized software,
and accessed from kernel using __io_remap(phsy_addr, PAGE_SIZE, _PAGE_PWT | PAGE_PCD) function.
I would have preferred not to have this memory as write through, and define this physical memory as snoop able, for PCI reads, at the memory bus controller. But i havn't figured out how to do that.
What done so for to debug this problem:
0. How did we verified this is the problem.
The adapter perform a read to this address, and save the value. It sends an update message to the pc. After an update reply message arrives it reads the value again and see the old value. The adapter developer have verified no caching is done at the adapter side.
1. Testing:
Run the machine with one cpu, and two cpu and we saw the problem.
Run the machine without cache: Cache was disabled at machine bios and we didn't see the problem.
2. Code changes:
At the beginning we used only ioremap, then we moved to ioremap_nocache, then to __ioremap with the above flags.
We have verified the adapter and pc has the same physical addresses, we have verified the pc actually performed to update to the virtual address which Linux allocated for the physical address the adapter is reading from.
3. investigations:
Searched and read items at the web: I've want over lkml FAQ, I've search the net for item regarding cache coherency problem, I read all the items on the linux-smp mailing list, I've reviewed the kernel code of _ioremap, vmalloc, get_pte etc..., I've read the three chapters in understanding the Linux kernel 2, 6, 13, and other books some on the web such as Linux kernel hacking, I've also searched and read at /usr/src/Documentation to seek help there, as you can see I'm pretty much desperate about this issue.
Regards,
Eitan.
next reply other threads:[~2002-10-01 12:37 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-01 12:43 Eitan Ben-Nun [this message]
2002-10-01 12:56 ` Arjan van de Ven
[not found] <B71796881E0DF7409F066FE6656BDF2906F78B@beasley>
2002-10-01 14:45 ` Arjan van de Ven
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=B71796881E0DF7409F066FE6656BDF2906F78A@beasley \
--to=eitan@sangate.com \
--cc=linux-kernel@vger.kernel.org \
--cc=uri@sangate.com \
/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
all inboxes | Powered by JetHome®