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 d
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
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/
7;while(1) { open(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/
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 conforming
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 r
[EMAIL PROTECTED] writes:
> This looks like it's a bug to me although if you have multiple
> threads hitting a file descriptor at the same time, you're pretty much
> asking for trouble.
Yes, I haven't been able to come up with an example that might trigger
this that wasn't dubious to begin w
"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 nee
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
t
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&#
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/
OSIX may be a surprise 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/
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 a
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
d have 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
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
plicit stack also works for
mergesort.)
> 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 unsu
[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 shoul
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
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
HMEM case, so I 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/
n my code fast, I didn't want to add 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);
You
ote saying this
may change in future 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 bandwi
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.
>
>
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 +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
"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 AS
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,
35 matches
Mail list logo
