* Re: remap_page_range problem on 2.3.x
@ 2000-03-13 19:16 Andy Henroid
0 siblings, 0 replies; 5+ messages in thread
From: Andy Henroid @ 2000-03-13 19:16 UTC (permalink / raw)
To: Thomas Sailer; +Cc: Jeff Garzik, Linux-MM
--- Thomas Sailer <sailer@ife.ee.ethz.ch> wrote:
> Andy Henroid wrote:
>
> > Yes, the remap_page_range is done indirectly
> > through mmap call to the /dev/mem driver.
>
> I think I saw this too some time ago.
>
> I tried to duplicate the kernel's view of the
> address space above 0xc0000000 at an offset in
> a usermode program. I ended up being able to
> read the correct data from /dev/mem, but reading
> from an mmaped page from /dev/mem returned
> completely bogus data (all zero).
Yes, the read through /dev/mem work for me too.
It looks like remap_page_range is doing the right
thing and it certainly works for other remapping.
I wonder what the problem is?
Oh well, low priority compared to the other things
that need to get fixed as we move into pre2.4
Thanks,
Andy
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: remap_page_range problem on 2.3.x
2000-03-09 17:51 Andy Henroid
@ 2000-03-13 13:19 ` Thomas Sailer
0 siblings, 0 replies; 5+ messages in thread
From: Thomas Sailer @ 2000-03-13 13:19 UTC (permalink / raw)
To: Andy Henroid; +Cc: Jeff Garzik, Linux-MM
Andy Henroid wrote:
> Yes, the remap_page_range is done indirectly
> through mmap call to the /dev/mem driver.
I think I saw this too some time ago.
I tried to duplicate the kernel's view of the
address space above 0xc0000000 at an offset in
a usermode program. I ended up being able to
read the correct data from /dev/mem, but reading
from an mmaped page from /dev/mem returned completely
bogus data (all zero).
My code is in usb.in.tum.de, module usbstress,
files uhcidump.c and kmem*
Tom
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: remap_page_range problem on 2.3.x
@ 2000-03-09 17:51 Andy Henroid
2000-03-13 13:19 ` Thomas Sailer
0 siblings, 1 reply; 5+ messages in thread
From: Andy Henroid @ 2000-03-09 17:51 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linux-MM
--- Jeff Garzik <jgarzik@mandrakesoft.com> wrote:
> Andy Henroid wrote:
> >
> > Name: mmtest.tar.gz
> > mmtest.tar.gz Type: Unix Tape Archive
> (application/x-tar)
> > Encoding: base64
> > Description: mmtest.tar.gz
>
> Are these the correct test files?
>
> rum:~/tmp/mmtest> grep -i remap *
> rum:~/tmp/mmtest>
Yes, the remap_page_range is done indirectly
through mmap call to the /dev/mem driver.
> I think you'll need to do something like
>
> init():
> dsdt = get_free_pages(...)
>
> chrdev mmap() op:
> remap_page_range(dsdt, ...)
OK, yes I bet that would work. I just don't see
any good reason why the remap_page_range doesn't
appear to be doing the right thing for a piece
of kmalloced memory.
> If you are going to present data via /proc, you
> might as well simply dump the raw data out to
> whoever is reading /proc/driver/acpi/dsdt...
It's actually a bit less wasteful, for systems
with large DSDTs, to do the mmap. But, right,
this is another possible work-around to my
current problem.
-Andy
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: remap_page_range problem on 2.3.x
2000-03-08 2:05 Andy Henroid
@ 2000-03-08 4:04 ` Jeff Garzik
0 siblings, 0 replies; 5+ messages in thread
From: Jeff Garzik @ 2000-03-08 4:04 UTC (permalink / raw)
To: Andy Henroid; +Cc: Linux-MM
Andy Henroid wrote:
>
> Name: mmtest.tar.gz
> mmtest.tar.gz Type: Unix Tape Archive (application/x-tar)
> Encoding: base64
> Description: mmtest.tar.gz
Are these the correct test files?
rum:~/tmp/mmtest> grep -i remap *
rum:~/tmp/mmtest>
I think you'll need to do something like
init():
dsdt = get_free_pages(...)
chrdev mmap() op:
remap_page_range(dsdt, ...)
If you are going to present data via /proc, you might as well simply
dump the raw data out to whoever is reading /proc/driver/acpi/dsdt...
--
Jeff Garzik | My to-do list is a function
Building 1024 | which approaches infinity.
MandrakeSoft, Inc. |
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [flat|nested] 5+ messages in thread
* remap_page_range problem on 2.3.x
@ 2000-03-08 2:05 Andy Henroid
2000-03-08 4:04 ` Jeff Garzik
0 siblings, 1 reply; 5+ messages in thread
From: Andy Henroid @ 2000-03-08 2:05 UTC (permalink / raw)
To: Linux-MM
[-- Attachment #1: Type: text/plain, Size: 305 bytes --]
Attached is a tiny kernel module and app to reproduce
the problem on 2.3.49. Or am I doing something stupid
here?
Thank you,
Andy Henroid
andy_henroid@yahoo.com
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
[-- Attachment #2: mmtest.tar.gz --]
[-- Type: application/x-gzip-compressed, Size: 1326 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2000-03-13 19:16 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-03-13 19:16 remap_page_range problem on 2.3.x Andy Henroid
-- strict thread matches above, loose matches on Subject: below --
2000-03-09 17:51 Andy Henroid
2000-03-13 13:19 ` Thomas Sailer
2000-03-08 2:05 Andy Henroid
2000-03-08 4:04 ` Jeff Garzik
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox