but somewhat different features that some
other x86 CPUs implement. So while it may appear odd, it is correct.
David Wragg
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
suspect that the main reason is to limit the
amount of searching needed for kmap to find a free slot. Is this
right?)
David Wragg
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
there is a good
reason. Which is why I'm asking how significant the kmap limit is.
David Wragg
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
From: David Wragg [EMAIL PROTECTED]
Gcc: nnfolder:mail.sent
--text follows this line--
Roman Zippel [EMAIL PROTECTED] writes:
On Tue, 23 Jan 2001, Mark Mokryn wrote:
ioremap_nocache does the following:
return __ioremap(offset, size, _PAGE_PCD);
You have a point.
It would be nice
edence of
Cache Controls" in the fairly recent edition I have here).
For example, with PCD set, PWT clear, and the MTRRs saying WC, the
effective memory type is WC. In addition, there's a note saying this
may change in future models. So you have to set PCD | PWT if you want
to get uncached i
"Benjamin C.R. LaHaise" [EMAIL PROTECTED] writes:
On 24 Jan 2001, David Wragg wrote:
[EMAIL PROTECTED] (Eric W. Biederman) writes:
Why do you need such a large buffer?
ext2 doesn't guarantee sustained write bandwidth (in particular,
writing a page to an ext2 file can h
Timur Tabi [EMAIL PROTECTED] writes:
** Reply to message from David Wragg [EMAIL PROTECTED] on 24 Jan 2001
00:50:20 +
(x86 processors with PAT and IA64 can set write-combining through
page flags. x86 processors with MTRRs but not PAT would need a more
elaborate implementation for write
"Stephen C. Tweedie" [EMAIL PROTECTED] writes:
On Wed, Jan 24, 2001 at 12:35:12AM +0000, David Wragg wrote:
And why do the pages need to be kmapped?
They only need to be kmapped while data is being copied into them.
But you only need to kmap one page at a time durin
Tigran Aivazian [EMAIL PROTECTED] writes:
b) it detects all memory correctly but creates a write-back mtrr only for
the first 2G, is this normal?
mtrr.c is broken for machines with =4GB of memory (or less than 4GB,
if the chipset reserves an addresses range below 4GB for PCI).
The patch
Richard Gooch [EMAIL PROTECTED] writes:
David Wragg writes:
mtrr.c is broken for machines with =4GB of memory (or less than 4GB,
if the chipset reserves an addresses range below 4GB for PCI).
The patch against 2.4.0-test9 to fix this is below.
Richard: Is there a reason you haven't
settings. They also give
pseudo-code for how to update them on an SMP system, which mtrr.c
follows.
If the BIOS has set them up differently at boot time, mtrr.c will
complain and copy the MTRR settings of CPU0 to the others.
Regards,
David Wragg
-
To unsubscribe from this list: send the line
Boszormenyi Zoltan [EMAIL PROTECTED] writes:
The idea is that when it is sure that _only one_ (or some) CPU will access
a PCI card's mmio area then only that CPU's (those CPUs') MTRRs needs to
contain an entry for that area.
Although there are (must be) common MTRR entries for the main
Gregory Maxwell [EMAIL PROTECTED] writes:
If 2.96 is broken, I'd appreciate it if you would describe the breakage.
As in the RedHat 2.96? Try compiling the following on RedHat 7.0 x86
with "gcc -O2" and take a look at the generated code. Nice, isn't it?
#include sys/time.h
void foo(void)
Aaron Sethman [EMAIL PROTECTED] writes:
Try compiling the said code with -fno-strict-aliasing, and your problems
will be solved.
Yes, but I don't think I should have to give gcc flags to get it to
obey the C standard (my example can easily be turned into a
self-contained strictly conforming
uot;insertion sort": Keep the lists sorted, and
insert the item at the right place when you get the new item.
Easier? Yes. Slower? Yes. Does its being slow matter? Depends on
the context.
David Wragg
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel&q
[EMAIL PROTECTED] (Bob_Tracy) writes:
Unfortunately, when I execute
echo "base=0xd800 size=0x10 type=write-combining" | /proc/mtrr
I get a 2MB region instead of the 1MB region I expected...
Oops, it got broken by the MTRR 32-bit support in 2.4.0-testX. The
patch below should fix
Is multisession CDROM support broken in 2.4.x?
I have an "Enhanced CD" which has a bunch of audio tracks followed by
a data track (is this the same as CD-XA? I can't remember). Under
2.2, I can mount the iso9660 filesystem on the data track without
trouble, using the session option:
# mount -o
(IN, "/proc/interrupts") ; while (IN) { next unless /LOC:/;
($a, $b, $c) = split; } close(IN); print (($b - $c) . "\n"); sleep(1); }'
David Wragg
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTE
might make some sense. But currently,
I don't see why there would be any difference between "MTRR disabled"
and "MTRR enabled, but not used".
David Wragg
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAI
Steven Walter [EMAIL PROTECTED] writes:
On Sun, Dec 10, 2000 at 06:20:31PM +, David Wragg wrote:
If I understood why the MTRR driver was doing something on the K6-2,
then model-specific differences might make some sense. But currently,
I don't see why there would be any difference
; (or actually "with these PCI details"), and the
core code arranges the mapping, doing the MTRR stuff while it's at it.
David Wragg
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
://www.linuxcare.com/viewpoints/os-interviews/12-14-99.epl).
David Wragg
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
corruption. In tdfxfb mode or
regular vesafb it looks like a horizontal line of color pixels that
grows, in 'regular' text mode I get flashing characters or the font
degrades into unreadable mess. X is fine.
What does "lspci -v" give?
David Wragg
-
To unsubscribe from this list: sen
ly, either by implementing PAT support
(Zoltán Böszörményi said he was working on that), or by having a
user-space helper program to make more intelligent MTRR allocations,
or both.)
David Wragg
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMA
Since f_pos of struct file is a loff_t, on 32-bit architectures it
needs a lock to make accesses atomic (or some more sophisticated form
of protection). But looking in 2.4.0-test10, there doesn't seem to be
any such lock.
The llseek op is called with the Big Kernel Lock, but unlike in 2.2,
the
"David Schwartz" [EMAIL PROTECTED] writes:
Suppose you had a multithreaded program that used a
configuration file with a group of fixed-length blocks indicating what
work it had to do. Each thread read a block from the file and then did
the work. One might think that there's no need to
Rik van Riel [EMAIL PROTECTED] writes:
On Wed, 28 Mar 2001, Robert Suetterlin wrote:
reg00: base=0xfb00 (4016MB), size= 16MB: uncachable, count=1
reg01: base=0xfc00 (4032MB), size= 64MB: uncachable, count=1
reg02: base=0x ( 0MB), size=8192MB: write-back, count=1
Robert Suetterlin [EMAIL PROTECTED] writes:
2. I was not allowed to do `base=0 size=0x4
type=write-back`, because of the overlap with the memory range at
base=0x0fb00.
/proc/mtrr does allow overlapping regions in some cases, but the
conditions turned out to be stricter than I
.
This patch (against 2.6.19/2.6.19.1) adds the four context switch
values (voluntary context switches, involuntary context switches, and
the same values accumulated from terminated child processes) to the
end of /proc/*/stat, similarly to min_flt, maj_flt and the time used
values.
Signed-off-by: David
Benjamin LaHaise [EMAIL PROTECTED] writes:
On Mon, Dec 18, 2006 at 11:50:08PM +, David Wragg wrote:
This patch (against 2.6.19/2.6.19.1) adds the four context switch
values (voluntary context switches, involuntary context switches, and
the same values accumulated from terminated child
Albert Cahalan [EMAIL PROTECTED] writes:
On Mon, Dec 18, 2006 at 11:50:08PM +, David Wragg wrote:
This patch (against 2.6.19/2.6.19.1) adds the four context
switch values (voluntary context switches, involuntary
context switches, and the same values accumulated from
terminated child
Arjan van de Ven [EMAIL PROTECTED] writes:
if all you care is the number of context switches, you can use the
following system tap script as well:
http://www.fenrus.org/cstop.stp
Thanks, something similar to that might well have solved my original
problem.
(When I try the script, stap
Arjan van de Ven [EMAIL PROTECTED] writes:
On Wed, 2006-12-20 at 14:38 +, David Wragg wrote:
(When I try the script, stap complains about the lack of the kernel
debuginfo package, which of course doesn't exist for my self-built
kernel. After hunting around on the web for 10 minutes, I'm
Albert Cahalan [EMAIL PROTECTED] writes:
The cumulative ones are still not justified though, and I fear they
may be 64-bit even on i386.
All the context switch counts are unsigned long.
It turns out that an i386 procps spends
much of its time doing 64-bit division to parse the damn ASCII
ecs, as
opposed to the MTRR-like but somewhat different features that some
other x86 CPUs implement. So while it may appear odd, it is correct.
David Wragg
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
suspect that the main reason is to limit the
amount of searching needed for kmap to find a free slot. Is this
right?)
David Wragg
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
d operations
that have an uncertain cost into those paths unless there is a good
reason. Which is why I'm asking how significant the kmap limit is.
David Wragg
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
From: David Wragg <[EMAIL PROTECTED]>
Gcc: nnfolder:mail.sent
--text follows this line--
Roman Zippel <[EMAIL PROTECTED]> writes:
> On Tue, 23 Jan 2001, Mark Mokryn wrote:
> > ioremap_nocache does the following:
> > return __ioremap(offset, size, _PAGE_PCD);
e models. So you have to set PCD | PWT if you want
to get uncached in all cases.
David Wragg
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
"Benjamin C.R. LaHaise" <[EMAIL PROTECTED]> writes:
> On 24 Jan 2001, David Wragg wrote:
>
> > [EMAIL PROTECTED] (Eric W. Biederman) writes:
> > > Why do you need such a large buffer?
> >
> > ext2 doesn't guarantee sustained write bandwidth (
Timur Tabi <[EMAIL PROTECTED]> writes:
> ** Reply to message from David Wragg <[EMAIL PROTECTED]> on 24 Jan 2001
> 00:50:20 +
> > (x86 processors with PAT and IA64 can set write-combining through
> >page flags. x86 processors with MTRRs but not PAT
"Stephen C. Tweedie" <[EMAIL PROTECTED]> writes:
> On Wed, Jan 24, 2001 at 12:35:12AM +, David Wragg wrote:
> >
> > > And why do the pages need to be kmapped?
> >
> > They only need to be kmapped while data is being copied into them.
>
>
rgesort.)
> Isn't it easier to do "insertion sort": Keep the lists sorted, and
> insert the item at the right place when you get the new item.
Easier? Yes. Slower? Yes. Does its being slow matter? Depends on
the context.
David Wragg
-
To unsubscribe from this list: send the li
[EMAIL PROTECTED] (Bob_Tracy) writes:
> Unfortunately, when I execute
>
> echo "base=0xd800 size=0x10 type=write-combining" >| /proc/mtrr
>
> I get a 2MB region instead of the 1MB region I expected...
Oops, it got broken by the MTRR >32-bit support in 2.4.0-testX. The
patch below
Is multisession CDROM support broken in 2.4.x?
I have an "Enhanced CD" which has a bunch of audio tracks followed by
a data track (is this the same as CD-XA? I can't remember). Under
2.2, I can mount the iso9660 filesystem on the data track without
trouble, using the session option:
# mount -o
(IN, ") { next unless /LOC:/;
($a, $b, $c) = split; } close(IN); print (($b - $c) . "\n"); sleep(1); }'
David Wragg
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
n model-specific differences might make some sense. But currently,
I don't see why there would be any difference between "MTRR disabled"
and "MTRR enabled, but not used".
David Wragg
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bo
Steven Walter <[EMAIL PROTECTED]> writes:
> On Sun, Dec 10, 2000 at 06:20:31PM +0000, David Wragg wrote:
> > If I understood why the MTRR driver was doing something on the K6-2,
> > then model-specific differences might make some sense. But currently,
> > I don't
his physical address" (or actually "with these PCI details"), and the
core code arranges the mapping, doing the MTRR stuff while it's at it.
David Wragg
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Tigran Aivazian <[EMAIL PROTECTED]> writes:
> b) it detects all memory correctly but creates a write-back mtrr only for
> the first 2G, is this normal?
mtrr.c is broken for machines with >=4GB of memory (or less than 4GB,
if the chipset reserves an addresses range below 4GB for PCI).
The patch
Richard Gooch <[EMAIL PROTECTED]> writes:
> David Wragg writes:
> > mtrr.c is broken for machines with >=4GB of memory (or less than 4GB,
> > if the chipset reserves an addresses range below 4GB for PCI).
> >
> > The patch against 2.4.0-test9 to
e the same MTRR settings. They also give
pseudo-code for how to update them on an SMP system, which mtrr.c
follows.
If the BIOS has set them up differently at boot time, mtrr.c will
complain and copy the MTRR settings of CPU0 to the others.
Regards,
David Wragg
-
To unsubscribe from this list
Boszormenyi Zoltan <[EMAIL PROTECTED]> writes:
> The idea is that when it is sure that _only one_ (or some) CPU will access
> a PCI card's mmio area then only that CPU's (those CPUs') MTRRs needs to
> contain an entry for that area.
>
> Although there are (must be) common MTRR entries for the
Gregory Maxwell <[EMAIL PROTECTED]> writes:
> If 2.96 is broken, I'd appreciate it if you would describe the breakage.
As in the RedHat 2.96? Try compiling the following on RedHat 7.0 x86
with "gcc -O2" and take a look at the generated code. Nice, isn't it?
#include
void foo(void)
{
Aaron Sethman <[EMAIL PROTECTED]> writes:
> Try compiling the said code with -fno-strict-aliasing, and your problems
> will be solved.
Yes, but I don't think I should have to give gcc flags to get it to
obey the C standard (my example can easily be turned into a
self-contained strictly
se to some. See
http://www.linuxcare.com/viewpoints/os-interviews/12-14-99.epl>).
David Wragg
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
lon Tbird 800)
> I am experiencing text console video corruption. In tdfxfb mode or
> regular vesafb it looks like a horizontal line of color pixels that
> grows, in 'regular' text mode I get flashing characters or the font
> degrades into unreadable mess. X is fine.
What does &
cluttering up calls to mtrr_add, it would be
better to fix this properly, either by implementing PAT support
(Zoltán Böszörményi said he was working on that), or by having a
user-space helper program to make more intelligent MTRR allocations,
or both.)
David Wragg
-
To unsubscribe from this list: sen
Since f_pos of struct file is a loff_t, on 32-bit architectures it
needs a lock to make accesses atomic (or some more sophisticated form
of protection). But looking in 2.4.0-test10, there doesn't seem to be
any such lock.
The llseek op is called with the Big Kernel Lock, but unlike in 2.2,
the
"David Schwartz" <[EMAIL PROTECTED]> writes:
> Suppose you had a multithreaded program that used a
> configuration file with a group of fixed-length blocks indicating what
> work it had to do. Each thread read a block from the file and then did
> the work. One might think that there's no
Rik van Riel <[EMAIL PROTECTED]> writes:
> On Wed, 28 Mar 2001, Robert Suetterlin wrote:
> > reg00: base=0xfb00 (4016MB), size= 16MB: uncachable, count=1
> > reg01: base=0xfc00 (4032MB), size= 64MB: uncachable, count=1
> > reg02: base=0x ( 0MB), size=8192MB: write-back,
Robert Suetterlin <[EMAIL PROTECTED]> writes:
> 2. I was not allowed to do `base=0 size=0x4
> type=write-back`, because of the overlap with the memory range at
> base=0x0fb00.
/proc/mtrr does allow overlapping regions in some cases, but the
conditions turned out to be stricter than
.
This patch (against 2.6.19/2.6.19.1) adds the four context switch
values (voluntary context switches, involuntary context switches, and
the same values accumulated from terminated child processes) to the
end of /proc/*/stat, similarly to min_flt, maj_flt and the time used
values.
Signed-off-by: David
Benjamin LaHaise <[EMAIL PROTECTED]> writes:
> On Mon, Dec 18, 2006 at 11:50:08PM +0000, David Wragg wrote:
>> This patch (against 2.6.19/2.6.19.1) adds the four context switch
>> values (voluntary context switches, involuntary context switches, and
>> the same values
"Albert Cahalan" <[EMAIL PROTECTED]> writes:
> On Mon, Dec 18, 2006 at 11:50:08PM +, David Wragg wrote:
>> This patch (against 2.6.19/2.6.19.1) adds the four context
>> switch values (voluntary context switches, involuntary
>> context switches,
Arjan van de Ven <[EMAIL PROTECTED]> writes:
> if all you care is the number of context switches, you can use the
> following system tap script as well:
>
> http://www.fenrus.org/cstop.stp
Thanks, something similar to that might well have solved my original
problem.
(When I try the script,
Arjan van de Ven <[EMAIL PROTECTED]> writes:
> On Wed, 2006-12-20 at 14:38 +0000, David Wragg wrote:
>> (When I try the script, stap complains about the lack of the kernel
>> debuginfo package, which of course doesn't exist for my self-built
>> kernel. After hunti
"Albert Cahalan" <[EMAIL PROTECTED]> writes:
> The cumulative ones are still not justified though, and I fear they
> may be 64-bit even on i386.
All the context switch counts are unsigned long.
> It turns out that an i386 procps spends
> much of its time doing 64-bit division to parse the damn
68 matches
Mail list logo
