Hi!
I just wanted to let you know that I successfully ruined
a CD with 2.4.0 + sym-2.1.0-20001230. The system is a RH 7.0
with glibc-2.2-9, cdrecord-1.9.
When will it be really usable?
Regards,
Zoltan Boszormenyi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
Hi!
PF_RSSTRIM is not declared anywhere either in the linux-2.4.0 sources
or in the 2.4.0-vmbigpatch.
Regards,
Zoltan Boszormenyi
-
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
Hi!
PF_RSSTRIM is not declared anywhere either in the linux-2.4.0 sources
or in the 2.4.0-vmbigpatch.
Regards,
Zoltan Boszormenyi
-
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
On Tue, 12 Dec 2000, Petr Vandrovec wrote:
> That's wrong. They must first register MTRR and then split it to
> 24+8, as they cannot register 24MB range. They can split it
> 16+16, or (16+8)+8, but at cost of 1 (or 2) additional MTRR entries -
> and there is very limited number of possible MTRRs.
On Tue, 12 Dec 2000, Petr Vandrovec wrote:
That's wrong. They must first register MTRR and then split it to
24+8, as they cannot register 24MB range. They can split it
16+16, or (16+8)+8, but at cost of 1 (or 2) additional MTRR entries -
and there is very limited number of possible MTRRs.
On Wed, 29 Nov 2000, Tigran Aivazian wrote:
> Hi,
>
> Just to let people know that 2.4.0-test12-pre3 behaves much better than
> earlier versions on my 6G RAM machine. Not only /proc/mtrr is correctly
> showing all 6G cached for write-back but also I so far I never had to
> up/down one of the
On Wed, 29 Nov 2000, Tigran Aivazian wrote:
Hi,
Just to let people know that 2.4.0-test12-pre3 behaves much better than
earlier versions on my 6G RAM machine. Not only /proc/mtrr is correctly
showing all 6G cached for write-back but also I so far I never had to
up/down one of the eepro100
Hi, Linus!
Will you consider applying the following patchset? You will find it at
ftp://ftp.externet.hu/pub/people/zboszor/mtrr-new2.tar.gz
I know that you like plain text patches inlined in the mail
but I do not know how to get pine to inline the (plain text)
attachments...
Here is the README
Hi, Linus!
Will you consider applying the following patchset? You will find it at
ftp://ftp.externet.hu/pub/people/zboszor/mtrr-new2.tar.gz
I know that you like plain text patches inlined in the mail
but I do not know how to get pine to inline the (plain text)
attachments...
Here is the README
On Thu, 12 Oct 2000, James Simmons wrote:
>
> > > every CPU to avoid slowdowns. So that if you set that eth0's
> > > IRQ will be handled by CPU1, the MTRRs of CPU1 will be set
> > > accordingly, and the other CPUs will not care about eth0,
> > > so they do not need eth0's MTRR settings.
> >
>
On Thu, 12 Oct 2000, James Simmons wrote:
every CPU to avoid slowdowns. So that if you set that eth0's
IRQ will be handled by CPU1, the MTRRs of CPU1 will be set
accordingly, and the other CPUs will not care about eth0,
so they do not need eth0's MTRR settings.
A little
On 12 Oct 2000, David Wragg wrote:
> Boszormenyi Zoltan <[EMAIL PROTECTED]> writes:
> > I came up with an idea. The MTRRs are per-cpu things.
> > Ingo Molnar's IRQ affinity code helps binding certain
> > IRQ sources to certain CPUs.
>
> They are implemente
On Thu, 12 Oct 2000, Tigran Aivazian wrote:
> ok, doing it from the bottom up was fine (didn't lockup) but reaching the
> last (first in your list) entry was refused by mtrr:
>
> mtrr: 0x0,0x1 overlaps existing 0xfeafe000,0x2000
Try the attached patch, and the driver will accept some
On Thu, 12 Oct 2000, Tigran Aivazian wrote:
> > On Thu, 12 Oct 2000, Boszormenyi Zoltan wrote:
> >
> > > echo "base=0 size=0x1 type=write-back" >/proc/mtrr
>
> this line immediately locks up the machine. But I want to understand where
We just
I came up with an idea. The MTRRs are per-cpu things.
Ingo Molnar's IRQ affinity code helps binding certain
IRQ sources to certain CPUs.
What if the MTRR driver allows per-CPU settings, maybe only on
uncached areas? Of course the real memory should be cached in
every CPU to avoid slowdowns. So
On Thu, 12 Oct 2000, Boszormenyi Zoltan wrote:
> echo "base=0 size=0x1 type=write-back" >/proc/mtrr
> echo "base=0x1 size=0x8000 type=write-back" >/proc/mtrr
> echo "base=0xfe00 size=0x80 type=write-combining" >/proc
On Thu, 12 Oct 2000, Tigran Aivazian wrote:
> suggestions?
I looked at what you sent (e820 map and lspci output) and came up with
this.
Cover 6 GB with write-back, the VGA memory with write-combining, and
all the other PCI areas as uncached.
echo "base=0 size=0x1 type=write-back"
On Wed, 11 Oct 2000, Tigran Aivazian wrote:
> Hi Zoltan,
>
> I have tried your patch and although it works:
>
> # cat /proc/mtrr
> reg00: base=0x ( 0MB), size=4096MB: write-back, count=1
> reg01: base=0x001 (4096MB), size=2048MB: write-back,
> count=1
> reg02:
On Wed, 11 Oct 2000, Tigran Aivazian wrote:
Hi Zoltan,
I have tried your patch and although it works:
# cat /proc/mtrr
reg00: base=0x ( 0MB), size=4096MB: write-back, count=1
reg01: base=0x001 (4096MB), size=2048MB: write-back,
count=1
reg02: base=0xfc00
On Thu, 12 Oct 2000, Tigran Aivazian wrote:
suggestions?
I looked at what you sent (e820 map and lspci output) and came up with
this.
Cover 6 GB with write-back, the VGA memory with write-combining, and
all the other PCI areas as uncached.
echo "base=0 size=0x1 type=write-back"
On Thu, 12 Oct 2000, Boszormenyi Zoltan wrote:
echo "base=0 size=0x1 type=write-back" /proc/mtrr
echo "base=0x1 size=0x8000 type=write-back" /proc/mtrr
echo "base=0xfe00 size=0x80 type=write-combining" /proc/mtrr
echo "base=0xf
I came up with an idea. The MTRRs are per-cpu things.
Ingo Molnar's IRQ affinity code helps binding certain
IRQ sources to certain CPUs.
What if the MTRR driver allows per-CPU settings, maybe only on
uncached areas? Of course the real memory should be cached in
every CPU to avoid slowdowns. So
On Thu, 12 Oct 2000, Tigran Aivazian wrote:
On Thu, 12 Oct 2000, Boszormenyi Zoltan wrote:
echo "base=0 size=0x1 type=write-back" /proc/mtrr
this line immediately locks up the machine. But I want to understand where
We just shared an experience. :-( This is what I
On Thu, 12 Oct 2000, Tigran Aivazian wrote:
ok, doing it from the bottom up was fine (didn't lockup) but reaching the
last (first in your list) entry was refused by mtrr:
mtrr: 0x0,0x1 overlaps existing 0xfeafe000,0x2000
Try the attached patch, and the driver will accept some cases
On 12 Oct 2000, David Wragg wrote:
Boszormenyi Zoltan [EMAIL PROTECTED] writes:
I came up with an idea. The MTRRs are per-cpu things.
Ingo Molnar's IRQ affinity code helps binding certain
IRQ sources to certain CPUs.
They are implemented as per-cpu things but the Intel manuals say
On Wed, 11 Oct 2000, Tigran Aivazian wrote:
> I will continue to narrow down by removing some things (like mtrr) from
> the equation. Rik, the problem is that when one enables PAE (or just
> highmem-4G) support on a 4-way 6G RAM machine becomes 38-40 times slower.
Will you please try this patch?
On Wed, 11 Oct 2000, Tigran Aivazian wrote:
I will continue to narrow down by removing some things (like mtrr) from
the equation. Rik, the problem is that when one enables PAE (or just
highmem-4G) support on a 4-way 6G RAM machine becomes 38-40 times slower.
Will you please try this patch?
Hi!
How can I reexport a mount point through NFS without causing too much
surprise to the users? The mount point contains a removable media
which can be removed anytime since it is not locked and the gui user
can work the same way as in front of a Windows machine. The system is
Red Hat
Hi!
I was asked a question: Is there a driver for the Adaptec Array 1000U2
(ARO-1130U2)? If there is, is it a patch somewhere or which kernel
version has it?
Regards,
Zoltan Boszormenyi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Hi!
How can I reexport a mount point through NFS without causing too much
surprise to the users? The mount point contains a removable media
which can be removed anytime since it is not locked and the gui user
can work the same way as in front of a Windows machine. The system is
Red Hat
On Wed, 6 Sep 2000, Andrea Arcangeli wrote:
> The 2.2.18pre2aa1 patch is here:
>
>
>ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.2/2.2.18pre2aa2.bz2
It contains code in arch/i386/mtrr.c that looks pretty much like
my "64 bit MTRR" patch that was posted on lkml some
On Wed, 6 Sep 2000, Andrea Arcangeli wrote:
The 2.2.18pre2aa1 patch is here:
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.2/2.2.18pre2aa2.bz2
It contains code in arch/i386/mtrr.c that looks pretty much like
my "64 bit MTRR" patch that was posted on lkml some time
101 - 132 of 132 matches
Mail list logo
