Oops with 2.4.23

Oops with 2.4.23

[Arnaud Fontaine]

[-- Attachment #1: Type: text/plain, Size: 11542 bytes --]

Hello,

I am using 2.4.23 kernel with no patchset. It was the first time i
install a linux distribution on this PC, so i can't tell you if it have
this Oops with an another version of the kernel. It looks to work fine 
during 1 or 2 days until i have an weird Oops. I have rebooted the machine 
after this but it appears again few days later and despite some reboot.

I haven't include the support for module loadable. I am using Debian
GNU/Linux Woody up to date.

Thanks for you help.
Arnaud Fontaine

-------------- ksymoops
 <1>Unable to handle kernel NULL pointer dereference at virtual address
00000000
c0138ff2
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0010:[vfs_follow_link+26/332]    Not tainted
EFLAGS: 00010217
eax: 00000000   ebx: caaf5f8c   ecx: cba98288   edx: caaf5f8c
esi: 00000000   edi: 00000000   ebp: cbafc0e0   esp: caaf5ee4
ds: 0018   es: 0018   ss: 0018
Process ps (pid: 800, stackpage=caaf5000)
Stack: caa3dc40 caaf4000 caaf5f8c cbafc0e0 c014add7 caaf5f8c 00000000
c0136dea 
       caa3dc40 caaf5f8c cbafc0e0 caaf5f8c cb57d000 00000000 00000001
00000001 
       00000001 cb57d00d caa3dc40 cb57d006 00000007 08733bbe c0136f56
c01370c7 
Call Trace:    [proc_follow_link+27/32] [link_path_walk+1794/2132]
[path_walk+26/28] [path_lookup+27/36] [open_namei+101/1244]
Code: 80 3e 2f 0f 85 a5 00 00 00 53 e8 b7 d4 ff ff ba 00 e0 ff ff 


>>ebx; caaf5f8c <END_OF_CODE+a840894/????>
>>ecx; cba98288 <END_OF_CODE+b7e2b90/????>
>>edx; caaf5f8c <END_OF_CODE+a840894/????>
>>ebp; cbafc0e0 <END_OF_CODE+b8469e8/????>
>>esp; caaf5ee4 <END_OF_CODE+a8407ec/????>

Code;  00000000 Before first symbol
00000000 <_EIP>:
Code;  00000000 Before first symbol
   0:   80 3e 2f                  cmpb   $0x2f,(%esi)
Code;  00000003 Before first symbol
   3:   0f 85 a5 00 00 00         jne    ae <_EIP+0xae> 000000ae Before
first symbol
Code;  00000009 Before first symbol
   9:   53                        push   %ebx
Code;  0000000a Before first symbol
   a:   e8 b7 d4 ff ff            call   ffffd4c6 <_EIP+0xffffd4c6>
ffffd4c6 <END_OF_CODE+3fd47dce/????>
Code;  0000000f Before first symbol
   f:   ba 00 e0 ff ff            mov    $0xffffe000,%edx

--------------

# lspci -vvv
00:00.0 Host bridge: Acer Laboratories Inc. [ALi] M1541 (rev 04)
	Subsystem: Acer Laboratories Inc. [ALi] ALI M1541 Aladdin V/V+
AGP System Controller
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort-
<TAbort- <MAbort+ >SERR- <PERR-
	Latency: 64
	Region 0: Memory at e6000000 (32-bit, non-prefetchable)
[size=16M]
	Capabilities: [b0] AGP version 1.0
		Status: RQ=28 SBA+ 64bit- FW- Rate=x1,x2
		Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>
	Capabilities: [e0] #00 [0000]

00:01.0 PCI bridge: Acer Laboratories Inc. [ALi] M5243 (rev 04) (prog-if
00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
	Latency: 64
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
	I/O behind bridge: 0000e000-0000dfff
	Memory behind bridge: e6000000-e5ffffff
	Prefetchable memory behind bridge: e8000000-e7ffffff
	BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-

00:02.0 USB Controller: Acer Laboratories Inc. [ALi] M5237 USB (rev 03)
(prog-if 10 [OHCI])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
	Latency: 0 (20000ns max)
	Interrupt: pin A routed to IRQ 5
	Region 0: Memory at e5800000 (32-bit, non-prefetchable)
[size=4K]

00:03.0 Bridge: Acer Laboratories Inc. [ALi] M7101 PMU
	Subsystem: Acer Laboratories Inc. [ALi] ALI M7101 Power
Management Controller
	Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-

00:07.0 ISA bridge: Acer Laboratories Inc. [ALi] M1533 PCI to ISA Bridge
[Aladdin IV] (rev c3)
	Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort+ <MAbort+ >SERR- <PERR-
	Latency: 0

00:0b.0 VGA compatible controller: Trident Microsystems TGUI 9440 (rev
e3) (prog-if 00 [VGA])
	Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop+
ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
	Interrupt: pin A routed to IRQ 12
	Region 0: Memory at e5000000 (32-bit, non-prefetchable)
[size=2M]
	Region 1: Memory at e4800000 (32-bit, non-prefetchable)
[size=64K]
	Expansion ROM at 000c0000 [disabled] [size=64K]

00:0f.0 IDE interface: Acer Laboratories Inc. [ALi] M5229 IDE (rev c1)
(prog-if fa)
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (500ns min, 1000ns max)
	Interrupt: pin A routed to IRQ 0
	Region 4: I/O ports at d800 [size=16]

-------------- dmesg

BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 0000000000f00000 (usable)
 BIOS-e820: 0000000000f00000 - 0000000001000000 (reserved)
 BIOS-e820: 0000000001000000 - 000000000bffc000 (usable)
 BIOS-e820: 000000000bffc000 - 000000000bfff000 (ACPI data)
 BIOS-e820: 000000000bfff000 - 000000000c000000 (ACPI NVS)
 BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
191MB LOWMEM available.
On node 0 totalpages: 49148
zone(0): 4096 pages.
zone(1): 45052 pages.
zone(2): 0 pages.
Kernel command line: BOOT_IMAGE=2.4.23 ro root=305 ether=0,0,eth0
ether=0,0,eth1
Initializing CPU#0
Detected 200.457 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 399.76 BogoMIPS
Memory: 191092k/196592k available (1049k kernel code, 4092k reserved,
246k data, 260k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode...
Ok.
Dentry cache hash table entries: 32768 (order: 6, 262144 bytes)
Inode cache hash table entries: 16384 (order: 5, 131072 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer cache hash table entries: 8192 (order: 3, 32768 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
CPU:     After generic, caps: 0080a135 00000000 00000000 00000004
CPU:             Common caps: 0080a135 00000000 00000000 00000004
CPU: Cyrix 6x86MX 3x Core/Bus Clock stepping 06
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au)
mtrr: detected mtrr type: Cyrix ARR
PCI: PCI BIOS revision 2.10 entry at 0xf0560, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
PCI: Using IRQ router ALI [10b9/1533] at 00:07.0
isapnp: Scanning for PnP cards...
isapnp: Card '3Com 3C509B EtherLink III'
isapnp: Card '3Com 3C509B EtherLink III'
isapnp: 2 Plug & Play cards detected total
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
Journalled Block Device driver loaded
parport0: PC-style at 0x378 (0x778) [PCSPP(,...)]
parport0: irq 7 detected
Detected PS/2 Mouse Port.
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ
SERIAL_PCI ISAPNP enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
lp0: using parport0 (polling).
lp0: console ready
FDC 0 is a post-1991 82077
eth0: 3c5x9 at 0x220, 10baseT port, address  00 60 97 7e 7e 0b, IRQ 10.
3c509.c:1.19 16Oct2002 becker@scyld.com
http://www.scyld.com/network/3c509.html
eth1: 3c5x9 at 0x230, 10baseT port, address  00 60 97 7e 92 55, IRQ 11.
3c509.c:1.19 16Oct2002 becker@scyld.com
http://www.scyld.com/network/3c509.html
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
PPP BSD Compression module registered
Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
ALI15X3: IDE controller at PCI slot 00:0f.0
ALI15X3: chipset revision 193
ALI15X3: not 100%% native mode: will probe irqs later
    ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:pio, hdd:pio
hda: ST320413A, ATA DISK drive
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: attached ide-disk driver.
hda: host protected area => 1
hda: 39102336 sectors (20020 MB) w/512KiB Cache, CHS=38792/16/63
Partition check:
 hda: hda1 hda3 < hda5 hda6 hda7 hda8 hda9 hda10 hda11 hda12 >
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 1024 buckets, 8Kbytes
TCP: Hash tables configured (established 16384 bind 16384)
ip_conntrack version 2.1 (1535 buckets, 12280 max) - 292 bytes per
conntrack
ip_tables: (C) 2000-2002 Netfilter core team
ipt_recent v0.3.1: Stephen Frost <sfrost@snowman.net>.
http://snowman.net/projects/ipt_recent/
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.

--------------

# cat /proc/ioports
0000-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
01f0-01f7 : ide0
0213-0213 : isapnp read
0220-022f : 3c509 PnP
0230-023f : 3c509 PnP
02f8-02ff : serial(set)
0378-037a : parport0
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial(set)
0a79-0a79 : isapnp write
0cf8-0cff : PCI conf1
5c20-5c3f : ALi Corporation M7101 PMU
d800-d80f : ALi Corporation M5229 IDE
  d800-d807 : ide0
  d808-d80f : ide1

--------------

# cat /proc/cpuinfo
processor	: 0
vendor_id	: CyrixInstead
cpu family	: 6
model		: 2
model name	: 6x86MX 3x Core/Bus Clock
stepping	: 6
cpu MHz		: 200.458
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: yes
fpu		: yes
fpu_exception	: yes
cpuid level	: 1
wp		: yes
flags		: fpu de tsc msr cx8 pge cmov mmx cyrix_arr ds_cpl est
cid
bogomips	: 399.76

--------------

# cat /proc/iomem
00000000-0009ffff : System RAM
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000f0000-000fffff : System ROM
00100000-00efffff : System RAM
  00100000-002066c9 : Kernel code
  002066ca-002440c7 : Kernel data
00f00000-00ffffff : reserved
01000000-0bffbfff : System RAM
0bffc000-0bffefff : ACPI Tables
0bfff000-0bffffff : ACPI Non-volatile Storage
e4800000-e480ffff : Trident Microsystems TGUI 9440
e5000000-e51fffff : Trident Microsystems TGUI 9440
e5800000-e5800fff : ALi Corporation USB 1.1 Controller
e6000000-e6ffffff : ALi Corporation M1541
ffff0000-ffffffff : reserved

--------------

-- 
Arnaud Fontaine <arnaud@andesi.org> - http://www.andesi.org/
GnuPG Public Key available on pgp.mit.edu
Fingerprint: D792 B8A5 A567 B001 C342 2613 BDF2 A220 5E36 19D3

--
Future looks spotty.  You will spill soup in late evening.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Oops with 2.4.23

[Marcelo Tosatti]

On Thu, 18 Dec 2003, Arnaud Fontaine wrote:

> Hello,
> 
> I am using 2.4.23 kernel with no patchset. It was the first time i
> install a linux distribution on this PC, so i can't tell you if it have
> this Oops with an another version of the kernel. It looks to work fine 
> during 1 or 2 days until i have an weird Oops. I have rebooted the machine 
> after this but it appears again few days later and despite some reboot.
> 
> I haven't include the support for module loadable. I am using Debian
> GNU/Linux Woody up to date.


Andrew, 

This is likely to be bad memory.

Can you try memtest86 on the box ? 

> Thanks for you help.
> Arnaud Fontaine
> 
> -------------- ksymoops
>  <1>Unable to handle kernel NULL pointer dereference at virtual address
> 00000000
> c0138ff2
> *pde = 00000000
> Oops: 0000
> CPU:    0
> EIP:    0010:[vfs_follow_link+26/332]    Not tainted
> EFLAGS: 00010217
> eax: 00000000   ebx: caaf5f8c   ecx: cba98288   edx: caaf5f8c
> esi: 00000000   edi: 00000000   ebp: cbafc0e0   esp: caaf5ee4
> ds: 0018   es: 0018   ss: 0018
> Process ps (pid: 800, stackpage=caaf5000)
> Stack: caa3dc40 caaf4000 caaf5f8c cbafc0e0 c014add7 caaf5f8c 00000000
> c0136dea 
>        caa3dc40 caaf5f8c cbafc0e0 caaf5f8c cb57d000 00000000 00000001
> 00000001 
>        00000001 cb57d00d caa3dc40 cb57d006 00000007 08733bbe c0136f56
> c01370c7 
> Call Trace:    [proc_follow_link+27/32] [link_path_walk+1794/2132]
> [path_walk+26/28] [path_lookup+27/36] [open_namei+101/1244]
> Code: 80 3e 2f 0f 85 a5 00 00 00 53 e8 b7 d4 ff ff ba 00 e0 ff ff 
> 
> 
> >>ebx; caaf5f8c <END_OF_CODE+a840894/????>
> >>ecx; cba98288 <END_OF_CODE+b7e2b90/????>
> >>edx; caaf5f8c <END_OF_CODE+a840894/????>
> >>ebp; cbafc0e0 <END_OF_CODE+b8469e8/????>
> >>esp; caaf5ee4 <END_OF_CODE+a8407ec/????>
> 

Re: Oops with 2.4.23

[Arnaud Fontaine]

[-- Attachment #1: Type: text/plain, Size: 997 bytes --]

On Thu, Dec 18, 2003 at 09:47:42AM -0200, Marcelo Tosatti wrote:
> 
> Andrew, 
> 
> This is likely to be bad memory.
> 
> Can you try memtest86 on the box ? 

Hello,

Before install Debian GNU/Linux Woody on this box, i have ran memtest
with a bootable media and have no error after 13 pass. But i have added
memory after. It comes from an other PC running perfectly with this. So
i think it could come from the memory but if you want i can launch
memtest again this night ;).

Thanks for your help.
Arnaud Fontaine

-- 
Arnaud Fontaine <arnaud@andesi.org> - http://www.andesi.org/
GnuPG Public Key available on pgp.mit.edu
Fingerprint: D792 B8A5 A567 B001 C342 2613 BDF2 A220 5E36 19D3

--
	"You have heard me speak of Professor Moriarty?"
	"The famous scientific criminal, as famous among crooks as --"
	"My blushes, Watson," Holmes murmured, in a deprecating voice.
	"I was about to say 'as he is unknown to the public.'"
		-- A. Conan Doyle, "The Valley of Fear"

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Oops with 2.4.23

[Mike Fedyk]

On Thu, Dec 18, 2003 at 02:06:01PM +0100, Arnaud Fontaine wrote:
> On Thu, Dec 18, 2003 at 09:47:42AM -0200, Marcelo Tosatti wrote:
> > 
> > Andrew, 
> > 
> > This is likely to be bad memory.
> > 
> > Can you try memtest86 on the box ? 
> 
> Hello,
> 
> Before install Debian GNU/Linux Woody on this box, i have ran memtest
> with a bootable media and have no error after 13 pass. But i have added
> memory after. It comes from an other PC running perfectly with this. So
> i think it could come from the memory but if you want i can launch
> memtest again this night ;).

There is a difference between memtest and memtest86.  memtest86 tests all of
your memory, and memtest can only test the userspace memory it can lock.

Re: Oops with 2.4.23

[Arnaud Fontaine]

[-- Attachment #1: Type: text/plain, Size: 993 bytes --]

On Thu, Dec 18, 2003 at 11:08:09AM -0800, Mike Fedyk wrote:
> > Hello,
> > 
> > Before install Debian GNU/Linux Woody on this box, i have ran memtest
> > with a bootable media and have no error after 13 pass. But i have added
> > memory after. It comes from an other PC running perfectly with this. So
> > i think it could come from the memory but if you want i can launch
> > memtest again this night ;).
> 
> There is a difference between memtest and memtest86.  memtest86 tests all of
> your memory, and memtest can only test the userspace memory it can lock.

Hello,

So i'll test memtest86 on my box this afternoon. I tell you if i find a
problem with the memory. Thank you for your explanations.

Arnaud Fontaine

-- 
Arnaud Fontaine <arnaud@andesi.org> - http://www.andesi.org/
GnuPG Public Key available on pgp.mit.edu
Fingerprint: D792 B8A5 A567 B001 C342 2613 BDF2 A220 5E36 19D3

--
You have the capacity to learn from mistakes.  You'll learn a lot today.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Oops with 2.4.23

[Xose Vazquez Perez]

Arnaud Fontaine wrote:

> So i'll test memtest86 on my box this afternoon. I tell you if i find a
> problem with the memory. Thank you for your explanations.

cpuburn [1] is faster detecting faults. It stress on the CPU itself, memory,
cooling system, motherboard (especially voltage regulators) and power supply.

[1] http://users.ev1.net/~redelm/

Re: Oops with 2.4.23

[Arnaud Fontaine]

[-- Attachment #1: Type: text/plain, Size: 1285 bytes --]

On Thu, Dec 18, 2003 at 11:08:09AM -0800, Mike Fedyk wrote:
> > On Thu, Dec 18, 2003 at 09:47:42AM -0200, Marcelo Tosatti wrote:
> > > 
> > > Andrew, 
> > > 
> > > This is likely to be bad memory.
> > > 
> > > Can you try memtest86 on the box ? 
> > 
> > Before install Debian GNU/Linux Woody on this box, i have ran memtest
> > with a bootable media and have no error after 13 pass. But i have added
> > memory after. It comes from an other PC running perfectly with this. So
> > i think it could come from the memory but if you want i can launch
> > memtest again this night ;).
> 
> There is a difference between memtest and memtest86.  memtest86 tests all of
> your memory, and memtest can only test the userspace memory it can lock.

Hello,

So i have just tested to run memtest86 on my box and i have had no error
with this. I have also tested cpuburn without any result. Have you some
others ideas ?

Thanks for your help.
Arnaud Fontaine

-- 
Arnaud Fontaine <arnaud@andesi.org> - http://www.andesi.org/
GnuPG Public Key available on pgp.mit.edu
Fingerprint: D792 B8A5 A567 B001 C342 2613 BDF2 A220 5E36 19D3

--
... A solemn, unsmiling, sanctimonious old iceberg who looked like he
was waiting for a vacancy in the Trinity.
		-- Mark Twain

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Oops with 2.4.23

[Maciej Zenczykowski]

> So i have just tested to run memtest86 on my box and i have had no error
> with this. I have also tested cpuburn without any result. Have you some
> others ideas ?

you did run memtest for a minimum dozen hours? sometimes it takes that 
long to find errors...

Cheers,
MaZe.

Re: Oops with 2.4.23

[Mike Fedyk]

On Sat, Dec 20, 2003 at 12:35:24AM +0100, Maciej Zenczykowski wrote:
> > So i have just tested to run memtest86 on my box and i have had no error
> > with this. I have also tested cpuburn without any result. Have you some
> > others ideas ?
> 
> you did run memtest for a minimum dozen hours? sometimes it takes that 
> long to find errors...

Has anyone noticed if several runs with the normal tests, or a single test
with all tests running catches more errors?

Re: Oops with 2.4.23

[Arnaud Fontaine]

[-- Attachment #1: Type: text/plain, Size: 1040 bytes --]

On Sat, Dec 20, 2003 at 12:35:24AM +0100, Maciej Zenczykowski wrote:
> > So i have just tested to run memtest86 on my box and i have had no error
> > with this. I have also tested cpuburn without any result. Have you some
> > others ideas ?
> 
> you did run memtest for a minimum dozen hours? sometimes it takes that 
> long to find errors...
> 
> Cheers,
> MaZe.
> 

Hello,

In fact, i have ran memtest86 for a long time and after 11 pass, i have
stopped it ;). It is enough ?

Thanks for your help.
Arnaud Fontaine

-- 
Arnaud Fontaine <arnaud@andesi.org> - http://www.andesi.org/
GnuPG Public Key available on pgp.mit.edu
Fingerprint: D792 B8A5 A567 B001 C342 2613 BDF2 A220 5E36 19D3

--
"Um, Mr. Anderson. You disappoint me."

"You can't scare me with this Gestapo crap. I know my rights. I want my
phone call."

"Tell me, Mr. Anderson, what good is a phone call if you're unable to
speak.... You're going to help us, Mr. Anderson whether you want to or not."

		-- Agent Smith and Neo, "The Matrix"

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Oops with 2.4.23

[Arnaud Fontaine]

[-- Attachment #1: Type: text/plain, Size: 766 bytes --]

On Sun, Dec 21, 2003 at 12:39:48PM -0200, Marcelo Tosatti wrote:
> >
> > Hello,
> >
> > In fact, i have ran memtest86 for a long time and after 11 pass, i have
> > stopped it ;). It is enough ?
> 
> It lists the regions of memory which it finds bad in the screen.
> 
> Did you see memtest86 report it?
> 

Sorry, i forgot to tell if i had error. So after 11 pass, i have had no 
error. I have also test with cpuburn which printed nothing after 30
minutes.

Thanks for your help.
Arnaud Fontaine

-- 
Arnaud Fontaine <arnaud@andesi.org> - http://www.andesi.org/
GnuPG Public Key available on pgp.mit.edu
Fingerprint: D792 B8A5 A567 B001 C342 2613 BDF2 A220 5E36 19D3

--
Think twice before speaking, but don't say "think think click click".

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Oops with 2.4.23

[Barry K. Nathan]

On Sat, Dec 20, 2003 at 12:35:24AM +0100, Maciej Zenczykowski wrote:
> you did run memtest for a minimum dozen hours? sometimes it takes that 
> long to find errors...

On one machine (with a bad power supply, as it turned out) it took
memtest86 almost 18 hours to report an error. So 12 hours isn't enough
either.

(On a related note, one machine that I tested with mprime's Torture Test
<http://www.mersenne.org/> took I think close to 43 hours to show a
failure. In that case I don't know if the failure was the CPU or the
motherboard, because in the end both failed on that system.)

-Barry K. Nathan <barryn@pobox.com>

Re: Oops with 2.4.23

[Marc Bevand]

Mike Fedyk wrote:
> 
> Has anyone noticed if several runs with the normal tests, or a single test
> with all tests running catches more errors?

Yes, I have already encountered such a situation. The box was an
Athlon 600 with 512 MB of SDRAM (partly defectuous). Running the
"normal tests" multiple times hasn't showed any error, but running
"all tests" one time has detected some errors (IIRC it has taken more
than 12 hours).

-- 
Marc Bevand

Re: Oops with 2.4.23

[Disconnect]

On Fri, 2003-12-19 at 18:55, Mike Fedyk wrote:
> On Sat, Dec 20, 2003 at 12:35:24AM +0100, Maciej Zenczykowski wrote:
> > > So i have just tested to run memtest86 on my box and i have had no error
> > > with this. I have also tested cpuburn without any result. Have you some
> > > others ideas ?
> > 
> > you did run memtest for a minimum dozen hours? sometimes it takes that 
> > long to find errors...
> 
> Has anyone noticed if several runs with the normal tests, or a single test
> with all tests running catches more errors?

I just did all this last weekend, and the basic operation I use is:
 - two passes at standard mode (this bombed for me at first, so adjust
timings/etc and repeat)
 - two passes at enhanced mode (this bombed on me once, so timings again
and restart from the beginning)
 - and (I skipped this) one pass at 'all' mode, just to be sure

Once it passes 2 standard and 2 enhanced, its a safe bet that it's
clean..

-- 
Disconnect <lkml@sigkill.net>

Re: Oops with 2.4.23

[Chris Frey]

On Sun, Dec 21, 2003 at 06:17:00PM -0800, Barry K. Nathan wrote:
> On Sat, Dec 20, 2003 at 12:35:24AM +0100, Maciej Zenczykowski wrote:
> > you did run memtest for a minimum dozen hours? sometimes it takes that 
> > long to find errors...
> 
> On one machine (with a bad power supply, as it turned out) it took
> memtest86 almost 18 hours to report an error. So 12 hours isn't enough
> either.
> 
> (On a related note, one machine that I tested with mprime's Torture Test
> <http://www.mersenne.org/> took I think close to 43 hours to show a
> failure. In that case I don't know if the failure was the CPU or the
> motherboard, because in the end both failed on that system.)

At what point do people start suspecting the kernel?

I mean, I would hope the linux kernel is not so badly written as to stress
the machine 24/7.  So after 12 hours of running memtest86 with clean
results, does that not begin to point to a software error rather than
hardware?

- Chris

Re: Oops with 2.4.23

[Xose Vazquez Perez]

Arnaud Fontaine wrote:

> Sorry, i forgot to tell if i had error. So after 11 pass, i have had no
> error. I have also test with cpuburn which printed nothing after 30
> minutes.

disable the SWAP, and run three burnMMX for 30 minutes:

# swapoff -a
$ ./burnMMX P || echo $? &

Re: Oops with 2.4.23

[Disconnect]

On Mon, 2003-12-22 at 12:05, Chris Frey wrote:
> At what point do people start suspecting the kernel?

Immediately. Maybe.  My problems seem to have been two-fold ('seem to'
because it could take up to a week to hit..).  First, the memory timings
listed by Kingston for this ram were way too aggressive for the ram+mobo
combo.  (FWIW, for anyone tracking this from the other thread, the epox
"if your motherboard sucks, use these" timings worked much better, and I
left cas at 2 instead of the epox-suggested 2.5. Oh, and memtest86
reported an -increase- in memory bandwidth with those settings.) And
second, the kernel didn't have erratta fixes and workarounds that MS
operating systems use to get io-apic running and stable, acpi stable,
etc...

> I mean, I would hope the linux kernel is not so badly written as to stress
> the machine 24/7.  So after 12 hours of running memtest86 with clean
> results, does that not begin to point to a software error rather than
> hardware?

Depends on the tests.  See my earlier results (and, if you want some
light reading, the memtest86 technical docs on the website) as an
example of why its important to run the full tests before fully
'certifying' a problem as software.  (Even though mine passed standard
tests, it failed extended.  And, for that matter, it passed both when I
first built it, before I put an OS on it.)

Evidently many people can look at an oops or crash path and be 90%
certain its bad/misperforming memory.  (How they do this I don't
know..)  I've noticed that 'check your ram' is not always given as the
answer, but it seems that most of the time when it is given its also
correct.

-- 
Disconnect <lkml@sigkill.net>

Re: Oops with 2.4.23

[Mike Fedyk]

On Mon, Dec 22, 2003 at 07:06:31PM +0100, Xose Vazquez Perez wrote:
> Arnaud Fontaine wrote:
> 
> > Sorry, i forgot to tell if i had error. So after 11 pass, i have had no
> > error. I have also test with cpuburn which printed nothing after 30
> > minutes.
> 
> disable the SWAP, and run three burnMMX for 30 minutes:

How does disabling swap help?

Re: Oops with 2.4.23

[Mike Fedyk]

On Mon, Dec 22, 2003 at 01:36:12PM -0500, Disconnect wrote:
> Evidently many people can look at an oops or crash path and be 90%
> certain its bad/misperforming memory.  (How they do this I don't
> know..)  I've noticed that 'check your ram' is not always given as the
> answer, but it seems that most of the time when it is given its also
> correct.

Single bit changes on high bits (especially when they're not used in any bit
tests), are usually suspect from what I see on the list...

Re: Oops with 2.4.23

[Xose Vazquez Perez]

Mike Fedyk wrote:

> How does disabling swap help?

It helps to not test the SWAP memory :-). Really the important
thing is 'P' flag in burnMMX. Otherwise it will test _only_
the cache memory of the processor.

Re: Oops with 2.4.23

[Barry K. Nathan]

On Mon, Dec 22, 2003 at 12:05:57PM -0500, Chris Frey wrote:
> On Sun, Dec 21, 2003 at 06:17:00PM -0800, Barry K. Nathan wrote:
> > On one machine (with a bad power supply, as it turned out) it took
> > memtest86 almost 18 hours to report an error. So 12 hours isn't enough
> > either.
> > 
> > (On a related note, one machine that I tested with mprime's Torture Test
> > <http://www.mersenne.org/> took I think close to 43 hours to show a
> > failure. In that case I don't know if the failure was the CPU or the
> > motherboard, because in the end both failed on that system.)
> 
> At what point do people start suspecting the kernel?
> 
> I mean, I would hope the linux kernel is not so badly written as to stress
> the machine 24/7.  So after 12 hours of running memtest86 with clean
> results, does that not begin to point to a software error rather than
> hardware?

It's not a matter of stressing the machine 24/7. It's a matter of
using (not necessarily stressing, either) the machine in *different*
ways than Windows. Some machines with broken hardware can run Linux with
no apparent problems but have lots of corruption under Windows, and some
seem fine under Windows but really flake out under Linux.

You can trip over hardware flaws with a split second of just the
unluckiest usage -- there doesn't need to be any stress. The purpose of
the stress-testing is to make latent faults show up more quickly and
more consistently than they might under real-world usage.

(Sometimes you even need to combine stress tests in order to make
problems trigger. One machine I tested, which had a bad motherboard,
could run mprime alone without failing for I think several days, but if
I left a shell script running in the background to repeatedly extract
and compare a tar file, then mprime would fail in well under 5 minutes.
The testing was in response to occasional waves of bluescreens under
both Win2K and WinXP, so the Linux kernel was already cleared of any
responsibility.)

The point of my last e-mail was to show that 12 hours is not enough to
point to a software error. I guess personally I try to aim for a minimum
of 18 hours for memtest and 48 hours for mprime. I usually let memtest
go to at least 24 hours if I can.

-Barry K. Nathan <barryn@pobox.com>

Re: Oops with 2.4.23

[Jesper Juhl]

On Mon, 22 Dec 2003, Chris Frey wrote:

> On Sun, Dec 21, 2003 at 06:17:00PM -0800, Barry K. Nathan wrote:
> > On Sat, Dec 20, 2003 at 12:35:24AM +0100, Maciej Zenczykowski wrote:
> > > you did run memtest for a minimum dozen hours? sometimes it takes that
> > > long to find errors...
> >
> > On one machine (with a bad power supply, as it turned out) it took
> > memtest86 almost 18 hours to report an error. So 12 hours isn't enough
> > either.
> >
> > (On a related note, one machine that I tested with mprime's Torture Test
> > <http://www.mersenne.org/> took I think close to 43 hours to show a
> > failure. In that case I don't know if the failure was the CPU or the
> > motherboard, because in the end both failed on that system.)
>
> At what point do people start suspecting the kernel?
>
> I mean, I would hope the linux kernel is not so badly written as to stress
> the machine 24/7.  So after 12 hours of running memtest86 with clean
> results, does that not begin to point to a software error rather than
> hardware?
>
Personally I expect my hardware to be able to survive being stressed 24/7.
I'm not saying the kernel does that, but if it did I would consider my
hardware broken if it didn't survive.

/Jesper Juhl

Re: Oops with 2.4.23

[Arnaud Fontaine]

[-- Attachment #1: Type: text/plain, Size: 801 bytes --]

On Mon, Dec 22, 2003 at 07:06:31PM +0100, Xose Vazquez Perez wrote:
> > Sorry, i forgot to tell if i had error. So after 11 pass, i have had no
> > error. I have also test with cpuburn which printed nothing after 30
> > minutes.
> 
> disable the SWAP, and run three burnMMX for 30 minutes:
> 
> # swapoff -a
> $ ./burnMMX P || echo $? &

Hello,

Do i ran burnMMX during more than 30 minutes and nothing reported. Do
you have an other idea ?

Thanks for your help.
Arnaud

-- 
Arnaud Fontaine <arnaud@andesi.org> - http://www.andesi.org/
GnuPG Public Key available on pgp.mit.edu
Fingerprint: D792 B8A5 A567 B001 C342 2613 BDF2 A220 5E36 19D3

--
Make sure input cannot violate the limits of the program.
            - The Elements of Programming Style (Kernighan & Plaugher)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Oops with 2.4.23

[Xose Vazquez Perez]

Arnaud Fontaine wrote:

> Do i ran burnMMX during more than 30 minutes and nothing reported. Do
> you have an other idea ?

next steps :

- run burnP5 for 30 min.
- try 2.4.24-pre2

Re: Oops with 2.4.23

[Arnaud Fontaine]

On Tue, Dec 23, 2003 at 09:21:39PM +0100, Xose Vazquez Perez wrote:
> next steps :
> 
> - run burnP5 for 30 min.
> - try 2.4.24-pre2

Hello,

So, i have compiled 2.4.24-pre2 as you say. In addition, i had this Oops
after every reboot on 2.4.23 (nothing with 2.4.18 which works fine).

Then, I reboot again on 2.4.24-pre2 and ran `burnP5` during 40 minutes
to be sure. I had nothing and no oops at the moment. If i see this Oops
with 2.4.24 (nothing now ;)), i'll run burnP5 on this and i'll say you
what i have.

Thanks for your help...
++ Arnaud

-- 
Arnaud Fontaine <arnaud@andesi.org> - http://www.andesi.org/
GnuPG Public Key available on pgp.mit.edu
Fingerprint: D792 B8A5 A567 B001 C342 2613 BDF2 A220 5E36 19D3

--
Be free and open and breezy!  Enjoy!  Things won't get any better so
get used to it.

Re: Oops with 2.4.23

[James Bourne]

On Sun, 28 Dec 2003, Arnaud Fontaine wrote:

> On Tue, Dec 23, 2003 at 09:21:39PM +0100, Xose Vazquez Perez wrote:
> > next steps :
> > 
> > - run burnP5 for 30 min.
> > - try 2.4.24-pre2
> 
> Hello,
> 
> So, i have compiled 2.4.24-pre2 as you say. In addition, i had this Oops
> after every reboot on 2.4.23 (nothing with 2.4.18 which works fine).
> 
> Then, I reboot again on 2.4.24-pre2 and ran `burnP5` during 40 minutes
> to be sure. I had nothing and no oops at the moment. If i see this Oops
> with 2.4.24 (nothing now ;)), i'll run burnP5 on this and i'll say you
> what i have.

Could you please try 2.4.23 with the patch at
http://www.hardrock.org/kernel/current-updates/linux-2.4.23-updates.patch

I would like to know if that helps or not.

Thanks and regards
James

> 
> Thanks for your help...
> ++ Arnaud
> 
> 

-- 
James Bourne                  | Email:            jbourne@hardrock.org          
Unix Systems Administrator    | WWW:           http://www.hardrock.org
Custom Unix Programming       | Linux:  The choice of a GNU generation
----------------------------------------------------------------------
 "All you need's an occasional kick in the philosophy." Frank Herbert