--On 10/12/00 00:24:48 +0200 Dewet Diener <[EMAIL PROTECTED]> wrote:
> Just experienced the following Oops: It's reproducible, the offender
> being netscape 4.75. Reverting back to 2.4.0-test9 fixes the
> problem. Both kernels were compiled with the same config.
>
Do you have highmem turne
Burnt a CD, compared the file with the original, and found out the
following. As you can see, the mismatch is the same depending on
the offset.
What's wrong? I'm using the ide-scsi patch Andre posted, btw.
07CEE45D: 63 73
0C96C5FF: 85 05
0D4B259A: B8 38
0FA3259A: DC 5C
1259745D: E1 F1
17CAA45D
On Thu, 12 Oct 2000, Keith Owens wrote:
> On Thu, 12 Oct 2000 12:56:09 +0100 (BST),
> Tigran Aivazian <[EMAIL PROTECTED]> wrote:
> >one correction -- it was "down and up the interface" that did the trick
> >and not deleting the 64M mtrr entry. I.e. the eepro100 problem is better
> >formulated as
Kernel test10-pre2, Dual Xeon PII(400 mhz), Mandrake 7.1, microde
updates enabled
Mounting my zipdrive(IMM) will result in something like this:
Sysrq does not work, machine is completely dead after 20-40 seconds.The
usual progession is CPU's lockup, modprobe dies, kflushed and syslogd
follow shor
Tim Waugh wrote:
>
> On Wed, Oct 11, 2000 at 11:01:20PM -0400, John Cavan wrote:
>
> > I don't if this is specifically a problem in the module or with modprobe
> > (2.3.17), but it doesn't happen with any other module. Unfortunately
> > parport_pc.c was as far as I traced before my work life suc
On Wed, Oct 11, 2000 at 11:01:20PM -0400, John Cavan wrote:
> I don't if this is specifically a problem in the module or with modprobe
> (2.3.17), but it doesn't happen with any other module. Unfortunately
> parport_pc.c was as far as I traced before my work life sucked me back
> in.
I think it'
On Fri, 13 Oct 2000, Richard Guenther wrote:
> On Fri, 13 Oct 2000, Rik van Riel wrote:
> > On Thu, 12 Oct 2000, Richard Guenther wrote:
> >
> > > I reported this BUG on a few days ago but got no response - happens
> > > on UP with only 32M ram, too. (see below). Also note the second
> > > BUG at
On Fri, 13 Oct 2000, Rik van Riel wrote:
> On Thu, 12 Oct 2000, Richard Guenther wrote:
>
> > I reported this BUG on a few days ago but got no response - happens
> > on UP with only 32M ram, too. (see below). Also note the second
> > BUG at vmscan.c:538 which I believe never saw reported again.
On Thu, 12 Oct 2000, Richard Guenther wrote:
> I reported this BUG on a few days ago but got no response - happens
> on UP with only 32M ram, too. (see below). Also note the second
> BUG at vmscan.c:538 which I believe never saw reported again.
> > Oct 11 16:05:26 hilbert36 kernel: kernel BUG at
Hi,
On Thu, Oct 12, 2000 at 02:19:27PM +0100, Tigran Aivazian wrote:
> Having done a few more reboots I got more info -- one of the eepro100
> interfaces is dead only in 4 out 5 cases. So, sometimes, doing ifdown eth0
> ; ifup eth0 does help.
Tigran, please check if you have any driver's message
} Hi,
}
} > How? If you compile with egcs-2.91.66 without frame pointers on ix86 then
} > __builtin_return_address() yields garbage. Does anybody have a generic
} > solution to this problem, other than "compile with frame pointers"? Or is
} > it fixed in newer versions of gcc?
}
} Are you sur
Hi,
> How? If you compile with egcs-2.91.66 without frame pointers on ix86 then
> __builtin_return_address() yields garbage. Does anybody have a generic
> solution to this problem, other than "compile with frame pointers"? Or is
> it fixed in newer versions of gcc?
Are you sure? I just I trie
PROTECTED]>
* SuSE Labs
--- /opt/kernel/linux-2.4.0-test10-pre1/drivers/scsi/sr_ioctl.c Mon Sep 11 02:49:27
2000
+++ drivers/scsi/sr_ioctl.c Thu Oct 12 19:01:09 2000
@@ -341,7 +341,7 @@
sr_cmd[7] = ti->cdti_trk1;
sr_cmd[8] = ti->cdti_ind1;
-
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
On Thu, 12 Oct 2000, Tigran Aivazian wrote:
> On 12 Oct 2000, David Wragg wrote:
> > Ok. I'll wait for feedback from Tigran, and if I don't get anything
> > negative I'll submit to Linus. The 2.2 version of my patch fixes
> > problems for other people, VA Linux have included it in their kernel
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 cas
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 that
all cpus should have the same MTRR se
On 12 Oct 2000, David Wragg wrote:
> Ok. I'll wait for feedback from Tigran, and if I don't get anything
> negative I'll submit to Linus. The 2.2 version of my patch fixes
> problems for other people, VA Linux have included it in their kernel
> for a while with no problems that have been reporte
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 rea
Hi,
Having done a few more reboots I got more info -- one of the eepro100
interfaces is dead only in 4 out 5 cases. So, sometimes, doing ifdown eth0
; ifup eth0 does help.
So, the latest status: all 6G of RAM work fast but the onboard eepro100
interface, often, doesn't work. This starts to look
Hello,
Ok, I despaired a bit about mtrrs on the Linux side and went into BIOS and
started playing with the cache settings there. The change that fixed the
problem was to disable all "area CXXX-> : cached". Now, I have a really
fast quad Xeon 6G RAM with consistently failing eepro100
interface. Do
On Thu, 12 Oct 2000 12:56:09 +0100 (BST),
Tigran Aivazian <[EMAIL PROTECTED]> wrote:
>one correction -- it was "down and up the interface" that did the trick
>and not deleting the 64M mtrr entry. I.e. the eepro100 problem is better
>formulated as "when highmem is enabled one or both eepro100 inte
s work fine but
> > the system is still 40x slower. This is the entire bootlog of
> > 2.4.0-test10-pre1 + lspci-vvx + /proc/interrupts + /proc/iomem + ifconfig
> > output
>
> one more finding -- deleting the strange 64M mtrr entry enabled the second
> eepro100 interface!
&
On Thu, 12 Oct 2000, Boszormenyi Zoltan wrote:
> 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"
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 w
On Thu, Oct 12, 2000 at 12:12:19PM +0200, Boszormenyi Zoltan wrote:
> 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? O
> 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
did you get base=0 and size=0x1 from? Shouldn't it be
base=0x10 and size=0xfccf according
On Thu, 12 Oct 2000 10:45:11 +0100 (BST),
Tigran Aivazian <[EMAIL PROTECTED]> wrote:
>It would be nice if /proc/mtrr showed eip of
>the caller who set up the entry :)
How? If you compile with egcs-2.91.66 without frame pointers on ix86 then
__builtin_return_address() yields garbage. Does anybo
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=0xfde0 size=0x10 type=unc
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" >/proc
bootlog of
> 2.4.0-test10-pre1 + lspci-vvx + /proc/interrupts + /proc/iomem + ifconfig
> output
one more finding -- deleting the strange 64M mtrr entry enabled the second
eepro100 interface!
# cat /proc/mtrr
reg00: base=0x001 (4096MB), size=2048MB: write-combining,
count=1
reg02:
On Thu, 12 Oct 2000, Boszormenyi Zoltan wrote:
> Look at the e820 map in the boot log, mark those areas
> as write-back and tell me what happens.
Here is e820 map:
BIOS-e820: 0009fc00 @ (usable)
BIOS-e820: 0400 @ 0009fc00 (reserved)
BIOS-e820:
nus Torvalds wrote:
> > What happens if MTRR support is entirely disabled?
>
> If MTRR support is disabled then both eepro100 interfaces work fine but
> the system is still 40x slower. This is the entire bootlog of
> 2.4.0-test10-pre1 + lspci-vvx + /proc/interrupts + /proc/iomem + ifco
Hi!
I reported this BUG on a few days ago but got no response - happens
on UP with only 32M ram, too. (see below). Also note the second
BUG at vmscan.c:538 which I believe never saw reported again.
Richard.
On Wed, 11 Oct 2000, Tigran Aivazian wrote:
> On Wed, 11 Oct 2000, Rik van Riel wrote:
On Thu, 12 Oct 2000, Matti Aarnio wrote:
> > CPU0: Intel Pentium III (Cascades) stepping 01
> > CPU1: Intel Pentium III (Cascades) stepping 01
> > CPU2: Intel Pentium III (Cascades) stepping 01
> > CPU3: Intel Pentium III (Cascades) stepping 01
> > Total of 4 processors activated (5606.60 BogoMIPS
On Thu, Oct 12, 2000 at 09:21:00AM +0100, Tigran Aivazian wrote:
> If MTRR support is disabled then both eepro100 interfaces work fine but
> the system is still 40x slower. This is the entire bootlog of
> 2.4.0-test10-pre1 + lspci-vvx + /proc/interrupts + /proc/iomem + ifconfig
> ou
On Wed, 11 Oct 2000, Linus Torvalds wrote:
> What happens if MTRR support is entirely disabled?
If MTRR support is disabled then both eepro100 interfaces work fine but
the system is still 40x slower. This is the entire bootlog of
2.4.0-test10-pre1 + lspci-vvx + /proc/interrupts + /proc/io
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=0xf
I managed to follow, with a number of debug statements, a problem that
appears to be in parport_pc that causes the following lockup on a dual
P3 500 with modprobe:
NMI Watchdog detected LOCKUP on CPU0, registers:
CPU:0
EIP:0010:[]
EFLAGS: 0086
eax: 0301 ebx: 0216 ecx:
I have adaptec 20160 scsi adapter and plextor 32x cdrom.
I played audio cd with gtcd(gnome app) and eject cdrom with gtcd(eject button)
, gtcd died and dmesg out...
--
kernel BUG at /usr/src/linux-2.4.0-test10/include/asm/pci.h:61!
invalid operand:
CPU:0
EIP:0010:[]
EFLAGS: 0021008
David Wragg writes:
> 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
Just experienced the following Oops: It's reproducible, the offender
being netscape 4.75. Reverting back to 2.4.0-test9 fixes the
problem. Both kernels were compiled with the same config.
I'm not on the list, so please CC me.
ksymoops 2.3.4 on i686 2.4.0-test10p1. Options used
-V (defau
On Wed, 11 Oct 2000 [EMAIL PROTECTED] wrote:
>Date: Wed, 11 Oct 2000 16:33:09 +0100 (BST)
>From: Tigran Aivazian <[EMAIL PROTECTED]>
>
>Maybe this is because I called this machine - hilbert, so now it gives me
>nothing but very interesting and exciting Problems... in fact too
On Wed, 11 Oct 2000, Rik van Riel wrote:
> On Wed, 11 Oct 2000, Tigran Aivazian wrote:
> > > On Wed, 11 Oct 2000, Rik van Riel wrote:
> > > > Could you send me the backtrace of one of the cases where
> > > > you hit the bug ?
> >
> > just to add -- I was following Alan Cox's suggestion of
> >
Would someone please look at this and see what might be going wrong?
Please tell me if additional information is needed.
Thanks,
Miles
Miles Lane wrote:
>
> ksymoops 0.7c on i686 2.4.0-test10. Options used
> -V (default)
> -k /proc/ksyms (default)
> -l /proc/modules (def
Date:Wed, 11 Oct 2000 16:33:09 +0100 (BST)
From: Tigran Aivazian <[EMAIL PROTECTED]>
Maybe this is because I called this machine - hilbert, so now it gives me
nothing but very interesting and exciting Problems... in fact too many of
them :)
There was a similar problem repo
On Wed, 11 Oct 2000, Tigran Aivazian wrote:
> it works fine then. Kernel compiles in 68 seconds as it should. Shall I
> keep incrementing mem= to see what happens next...
I suspect fixing the mtrrs on the machine will fix this problem, as a
38-40 times slowdown on a machine that isn't swapping i
On Wed, 11 Oct 2000, Tigran Aivazian wrote:
> > On Wed, 11 Oct 2000, Rik van Riel wrote:
> > > Could you send me the backtrace of one of the cases where
> > > you hit the bug ?
>
> just to add -- I was following Alan Cox's suggestion of
> incrementing "mem=N" and finding the value where the syste
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
On Wed, 11 Oct 2000, Tigran Aivazian wrote:
> On Wed, 11 Oct 2000, Rik van Riel wrote:
> > Could you send me the backtrace of one of the cases where
> > you hit the bug ?
>
> here you are:
> Oct 11 16:05:26 hilbert36 kernel: kernel BUG at page_alloc.c:221!
> Oct 11 16:05:27 hilbert36 kernel: Cal
> On Wed, 11 Oct 2000, Rik van Riel wrote:
> > Could you send me the backtrace of one of the cases where
> > you hit the bug ?
just to add -- I was following Alan Cox's suggestion of incrementing
"mem=N" and finding the value where the system stops working normally. It
was ok as high as "mem=3096
On Wed, 11 Oct 2000, Rik van Riel wrote:
> Could you send me the backtrace of one of the cases where
> you hit the bug ?
here you are:
Oct 11 16:05:26 hilbert36 kernel: kernel BUG at page_alloc.c:221!
Oct 11 16:05:26 hilbert36 kernel: invalid operand:
Oct 11 16:05:26 hilbert36 kernel: CPU:
On Wed, 11 Oct 2000, Tigran Aivazian wrote:
> On Wed, 11 Oct 2000, Rik van Riel wrote:
> > On Wed, 11 Oct 2000, Tigran Aivazian wrote:
> > > On Wed, 11 Oct 2000, Mark Hemment wrote:
> > > > On Wed, 11 Oct 2000, Tigran Aivazian wrote:
> > > >
> > > > > a) one of the eepro100 interfaces (the onboa
On Wed, 11 Oct 2000, Rik van Riel wrote:
> On Wed, 11 Oct 2000, Tigran Aivazian wrote:
> > On Wed, 11 Oct 2000, Mark Hemment wrote:
> > > On Wed, 11 Oct 2000, Tigran Aivazian wrote:
> > >
> > > > a) one of the eepro100 interfaces (the onboard one on the S2QR6 mb) is
> > > > malfunctioning, inte
On Wed, 11 Oct 2000, Tigran Aivazian wrote:
> On Wed, 11 Oct 2000, Mark Hemment wrote:
> > On Wed, 11 Oct 2000, Tigran Aivazian wrote:
> >
> > > a) one of the eepro100 interfaces (the onboard one on the S2QR6 mb) is
> > > malfunctioning, interrupts are generated but no traffic gets through (YES,
> On Wed, 11 Oct 2000, Alan Cox 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.
> >
> > What happens i
On Wed, 11 Oct 2000, Alan Cox 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.
>
> What happens if you boot a P
> 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.
What happens if you boot a PAE kernel with mem=512M on that box ?
-
To unsu
4-way 6G RAM machine becomes 38-40 times slower.
>
> Will you please try this patch? This is almost the same as I
> sent to you before, it is just against 2.4.0-test10-pre1 and
> it lacks the corrections to e.g. the frame buffer drivers.
Hi Zoltan,
I have tried your patch and although i
his patch? This is almost the same as I
sent to you before, it is just against 2.4.0-test10-pre1 and
it lacks the corrections to e.g. the frame buffer drivers.
I am now running test10-pre1 with this patch and:
-
[root@localhost /root]# cd /p
Hi,
Maybe this is because I called this machine - hilbert, so now it gives me
nothing but very interesting and exciting Problems... in fact too many of
them :)
Regards,
Tigran
Oct 11 16:05:26 hilbert36 kernel: kernel BUG at page_alloc.c:221!
Oct 11 16:05:26 hilbert36 kernel: invalid operand: 00
Hi Mark,
On Wed, 11 Oct 2000, Mark Hemment wrote:
> Hi Tigran,
>
> On Wed, 11 Oct 2000, Tigran Aivazian wrote:
>
> > a) one of the eepro100 interfaces (the onboard one on the S2QR6 mb) is
> > malfunctioning, interrupts are generated but no traffic gets through (YES,
> > I did plug it in corre
gt; eepro100 interfaces work fine. I will now test with plain highmem (4G) but
> no PAE... and see what happens
>
> On Wed, 11 Oct 2000, Tigran Aivazian wrote:
>
> > Hi,
> >
> > I have installed 2.4.0-test10-pre1 on a 4-way Xeon 700MHz 6G RAM machine
> > and obse
Hi Tigran,
On Wed, 11 Oct 2000, Tigran Aivazian wrote:
> a) one of the eepro100 interfaces (the onboard one on the S2QR6 mb) is
> malfunctioning, interrupts are generated but no traffic gets through (YES,
> I did plug it in correctly, this time, and I repeat 2.2.16 works!)
I saw this the oth
PAE... and see what happens
On Wed, 11 Oct 2000, Tigran Aivazian wrote:
> Hi,
>
> I have installed 2.4.0-test10-pre1 on a 4-way Xeon 700MHz 6G RAM machine
> and observe various problems, not present in
> 2.2.16-(redhat69's-number-17).
>
> a) one of the eepro100 inte
Hi,
I have installed 2.4.0-test10-pre1 on a 4-way Xeon 700MHz 6G RAM machine
and observe various problems, not present in
2.2.16-(redhat69's-number-17).
a) one of the eepro100 interfaces (the onboard one on the S2QR6 mb) is
malfunctioning, interrupts are generated but no traffic gets th
ksymoops 0.7c on i686 2.4.0-test10. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.0-test10/ (default)
-m /usr/src/linux/System.map (default)
agate login: Unable to handle null pointer dereference at virtual
address
Hi Linus
I just resend this patch (the first time I forgot to put the
[PATCH] field). It fixes a leak in swapon reported by marcelo
quite time ago.
Later, Juan.
> "marcelo" == Marcelo de Paula Bezerra <[EMAIL PROTECTED]> writes:
Hi
sorry for the delay (this problem has be
Every nit needs picking.
Index: 0-test10-pre1.1/Makefile
--- 0-test10-pre1.1/Makefile Tue, 03 Oct 2000 12:24:51 +1100 kaos
(linux-2.4/B/c/27_Makefile 1.1.2.2.2.4.1.7.1.3.1.5.2.5 644)
+++ 0-test10-pre1.1(w)/Makefile Tue, 10 Oct 2000 11:33:03 +1100 kaos
+(linux-2.4/B/c/27_Makefile 1.1.2.2.2.4.1.7
Largely VM balancing and OOM things (get rid of the VM livelock that
existed in test9), and USB fixes.
And a number of random driver fixes (SMP locking on network drivers, what
not).
Linus
-
- pre1:
- Roger Larsson: ">=" instead of ">" to make the VM not get stuck.
70 matches
Mail list logo
