This is also true on some x86 systems.
Dave Hansen wrote:
>On 04/14/2013 09:52 PM, HATAYAMA Daisuke wrote:
>> This sounds like there's no such issue on x86 cache mechanism. Is it
>> correct? If so, what is the difference between ia64 and x86 cache
>> mechanisms?
>
>I'm just going by the code
(2013/04/15 14:58), Dave Hansen wrote:
On 04/14/2013 09:52 PM, HATAYAMA Daisuke wrote:
This sounds like there's no such issue on x86 cache mechanism. Is it
correct? If so, what is the difference between ia64 and x86 cache
mechanisms?
I'm just going by the code comments:
drivers/char/mem.c
(2013/04/15 14:58), Dave Hansen wrote:
On 04/14/2013 09:52 PM, HATAYAMA Daisuke wrote:
This sounds like there's no such issue on x86 cache mechanism. Is it
correct? If so, what is the difference between ia64 and x86 cache
mechanisms?
I'm just going by the code comments:
drivers/char/mem.c
This is also true on some x86 systems.
Dave Hansen d...@sr71.net wrote:
On 04/14/2013 09:52 PM, HATAYAMA Daisuke wrote:
This sounds like there's no such issue on x86 cache mechanism. Is it
correct? If so, what is the difference between ia64 and x86 cache
mechanisms?
I'm just going by the
On 04/14/2013 09:52 PM, HATAYAMA Daisuke wrote:
> This sounds like there's no such issue on x86 cache mechanism. Is it
> correct? If so, what is the difference between ia64 and x86 cache
> mechanisms?
I'm just going by the code comments:
drivers/char/mem.c
> /*
>
(2013/04/13 7:17), Dave Hansen wrote:
On 04/12/2013 07:56 AM, H. Peter Anvin wrote:
On 04/12/2013 07:31 AM, Vivek Goyal wrote:
I also have to admit that I don't see the difference between /dev/mem
and /dev/oldmem, as the former allows access to memory ranges outside
the ones used by the
(2013/04/13 7:17), Dave Hansen wrote:
On 04/12/2013 07:56 AM, H. Peter Anvin wrote:
On 04/12/2013 07:31 AM, Vivek Goyal wrote:
I also have to admit that I don't see the difference between /dev/mem
and /dev/oldmem, as the former allows access to memory ranges outside
the ones used by the
On 04/14/2013 09:52 PM, HATAYAMA Daisuke wrote:
This sounds like there's no such issue on x86 cache mechanism. Is it
correct? If so, what is the difference between ia64 and x86 cache
mechanisms?
I'm just going by the code comments:
drivers/char/mem.c
/*
* On
Yes... That is one reason I think it is a real problem.
Dave Hansen wrote:
>On 04/12/2013 07:56 AM, H. Peter Anvin wrote:
>> On 04/12/2013 07:31 AM, Vivek Goyal wrote:
I also have to admit that I don't see the difference between
>/dev/mem
and /dev/oldmem, as the former allows access
On 04/12/2013 07:56 AM, H. Peter Anvin wrote:
> On 04/12/2013 07:31 AM, Vivek Goyal wrote:
>>> I also have to admit that I don't see the difference between /dev/mem
>>> and /dev/oldmem, as the former allows access to memory ranges outside
>>> the ones used by the current kernel, which is what the
On 04/12/2013 07:31 AM, Vivek Goyal wrote:
>>
>> I also have to admit that I don't see the difference between /dev/mem
>> and /dev/oldmem, as the former allows access to memory ranges outside
>> the ones used by the current kernel, which is what the oldmem device
>> seems to be intended to od.
>
On Thu, Apr 11, 2013 at 08:06:50AM -0700, H. Peter Anvin wrote:
> On 04/11/2013 07:55 AM, Yinghai Lu wrote:
> > On Thu, Apr 11, 2013 at 5:26 AM, Thomas Renninger wrote:
> >> Currently ranges are passed via kernel boot parameters:
> >> memmap=exactmap memmap=X#Y memmap=
> >>
> >> Pass them via
On Thursday, April 11, 2013 07:55:57 AM Yinghai Lu wrote:
> On Thu, Apr 11, 2013 at 5:26 AM, Thomas Renninger wrote:
> > Currently ranges are passed via kernel boot parameters:
> > memmap=exactmap memmap=X#Y memmap=
> >
> > Pass them via e820 table directly instead.
>
> how to address
On Thursday, April 11, 2013 07:55:57 AM Yinghai Lu wrote:
On Thu, Apr 11, 2013 at 5:26 AM, Thomas Renninger tr...@suse.de wrote:
Currently ranges are passed via kernel boot parameters:
memmap=exactmap memmap=X#Y memmap=
Pass them via e820 table directly instead.
how to address
On Thu, Apr 11, 2013 at 08:06:50AM -0700, H. Peter Anvin wrote:
On 04/11/2013 07:55 AM, Yinghai Lu wrote:
On Thu, Apr 11, 2013 at 5:26 AM, Thomas Renninger tr...@suse.de wrote:
Currently ranges are passed via kernel boot parameters:
memmap=exactmap memmap=X#Y memmap=
Pass them via e820
On 04/12/2013 07:31 AM, Vivek Goyal wrote:
I also have to admit that I don't see the difference between /dev/mem
and /dev/oldmem, as the former allows access to memory ranges outside
the ones used by the current kernel, which is what the oldmem device
seems to be intended to od.
I think
On 04/12/2013 07:56 AM, H. Peter Anvin wrote:
On 04/12/2013 07:31 AM, Vivek Goyal wrote:
I also have to admit that I don't see the difference between /dev/mem
and /dev/oldmem, as the former allows access to memory ranges outside
the ones used by the current kernel, which is what the oldmem
Yes... That is one reason I think it is a real problem.
Dave Hansen d...@sr71.net wrote:
On 04/12/2013 07:56 AM, H. Peter Anvin wrote:
On 04/12/2013 07:31 AM, Vivek Goyal wrote:
I also have to admit that I don't see the difference between
/dev/mem
and /dev/oldmem, as the former allows access
On 04/11/2013 07:55 AM, Yinghai Lu wrote:
> On Thu, Apr 11, 2013 at 5:26 AM, Thomas Renninger wrote:
>> Currently ranges are passed via kernel boot parameters:
>> memmap=exactmap memmap=X#Y memmap=
>>
>> Pass them via e820 table directly instead.
>
> how to address "saved_max_pfn" referring in
On Thu, Apr 11, 2013 at 5:26 AM, Thomas Renninger wrote:
> Currently ranges are passed via kernel boot parameters:
> memmap=exactmap memmap=X#Y memmap=
>
> Pass them via e820 table directly instead.
how to address "saved_max_pfn" referring in kernel?
kernel need to use saved_max_pfn from old
On Thu, Apr 11, 2013 at 5:26 AM, Thomas Renninger tr...@suse.de wrote:
Currently ranges are passed via kernel boot parameters:
memmap=exactmap memmap=X#Y memmap=
Pass them via e820 table directly instead.
how to address saved_max_pfn referring in kernel?
kernel need to use saved_max_pfn from
On 04/11/2013 07:55 AM, Yinghai Lu wrote:
On Thu, Apr 11, 2013 at 5:26 AM, Thomas Renninger tr...@suse.de wrote:
Currently ranges are passed via kernel boot parameters:
memmap=exactmap memmap=X#Y memmap=
Pass them via e820 table directly instead.
how to address saved_max_pfn referring in
22 matches
Mail list logo
