is this a bug?

As you will see in the attached file (it's a dmesg from the boot)
I have an 1Ghz athlon cpu with a VIA KT133 on a gigabyte GA-7ZX motherboard with 100mhz SDRAM.When I compiled the kernel with cputype=Athlon I continiusly experienced this crash.When I compiled with cputype=i686 everything went smooth (OS is Redhat 7.1) Yours

Theodore Pitikaris

Linux version 2.4.8-pre4 ([email protected]) (gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-81)) #1 ��� ��� 7 13:28:12 EEST 2001 BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000000bff0000 (usable)
BIOS-e820: 000000000bff0000 - 000000000bff8000 (ACPI data)
BIOS-e820: 000000000bff8000 - 000000000c000000 (ACPI NVS)
BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
On node 0 totalpages: 49136
zone(0): 4096 pages.
zone(1): 45040 pages.
zone(2): 0 pages.
Kernel command line: auto BOOT_IMAGE=new ro root=306 BOOT_FILE=/boot/2.4.8 lba32
Initializing CPU#0
Detected 1002.302 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 1998.84 BogoMIPS

Memory: 191352k/196544k available (834k kernel code, 4804k reserved, 286k data, 188k init, 0k highmem)
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: 4096 (order: 3, 32768 bytes)
Buffer-cache hash table entries: 8192 (order: 3, 32768 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
CPU: Before vendor init, caps: 0183f9ff c1c7f9ff 00000000, vendor = 2
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After vendor init, caps: 0183f9ff c1c7f9ff 00000000 00000000
CPU:     After generic, caps: 0183f9ff c1c7f9ff 00000000 00000000
CPU:             Common caps: 0183f9ff c1c7f9ff 00000000 00000000
CPU: AMD Athlon(tm) Processor stepping 02

Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.40 (20010327) Richard Gooch ([email protected])
mtrr: detected mtrr type: Intel
PCI: PCI BIOS revision 2.10 entry at 0xfdb71, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Using IRQ router VIA [1106/0686] at 00:07.0
Applying VIA PCI latency patch (found VT82C686B).
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Starting kswapd v1.8
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
block: 128 slots per queue, batch=16
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci00:07.1

    ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:DMA
    ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:DMA

hda: QUANTUM FIREBALLlct08 17, ATA DISK drive
hdb: ST39140A, ATA DISK drive
hdc: ASUS DVD-ROM E608, ATAPI CD/DVD-ROM drive
hdd: SONY CDU4811, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 33906432 sectors (17360 MB) w/418KiB Cache, CHS=2110/255/63, UDMA(33)
hdb: 17803440 sectors (9115 MB) w/448KiB Cache, CHS=1108/255/63, UDMA(33)
hdc: ATAPI 40X DVD-ROM drive, 128kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.12
hdd: ATAPI 48X CD-ROM drive, 120kB Cache, UDMA(33)
Partition check:
hda: hda1 hda2 < hda5 hda6 >
hdb: hdb1
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
loop: loaded (max 8 devices)
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 149M
agpgart: Detected Via Apollo Pro KT133 chipset
agpgart: AGP aperture is 64M @ 0xe0000000
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 1024 buckets, 8Kbytes
TCP: Hash tables configured (established 16384 bind 16384)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 188k freed
Adding Swap: 248968k swap-space (priority -1)
memory.c:83: bad pmd c5e77b40.
memory.c:83: bad pmd c5e5e000.
memory.c:83: bad pmd c020ac74.
memory.c:83: bad pmd c117f59c.
memory.c:83: bad pmd c020ac98.
memory.c:83: bad pmd 00000001.
memory.c:83: bad pmd 00000002.
kernel BUG at page_alloc.c:73!

invalid operand: 0000
CPU:    0
EIP:    0010:[<c0129603>]
EFLAGS: 00010282
eax: 0000001f   ebx: c1324048   ecx: 00000001   edx: c02099e4
esi: c1324048   edi: 00000000   ebp: c675e1d8   esp: cbc2de7c
ds: 0018   es: 0018   ss: 0018
Process ifup-aliases (pid: 161, stackpage=cbc2d000)
Stack: c01d98a6 c01d997a 00000049 c01cbf4f c11b0ac8 c117f844 c011fc7c c65ce000 
       c1324048 c1324048 00048000 c675e1d8 c012a535 4015dcbc ffffffff 00000001 
       c13cd440 c1324048 0000004a c011ef04 c1324048 0000002c 00000000 000c0000 
Call Trace: [<c01cbf4f>] [<c011fc7c>] [<c012a535>] [<c011ef04>] [<c010fd50>] [<c010fec6>] [<c0121638>] 
       [<c01385ba>] [<c0111a66>] [<c0115832>] [<c01109a4>] [<c010fd50>] [<c0106ecb>] 

Code: 0f 0b 83 c4 0c 8b 46 08 85 c0 74 16 6a 4b 68 7a 99 1d c0 68 
kernel BUG at page_alloc.c:73!
invalid operand: 0000
CPU:    0
EIP:    0010:[<c0129603>]
EFLAGS: 00010282
eax: 0000001f   ebx: c1324048   ecx: 00000001   edx: c02099e4
esi: c1324048   edi: 00000000   ebp: c66fb1d8   esp: cbc2de7c
ds: 0018   es: 0018   ss: 0018
Process ifup-aliases (pid: 163, stackpage=cbc2d000)
Stack: c01d98a6 c01d997a 00000049 c01cbf4f c11d34e0 c117f844 c011fc7c c6df4000 
       c1324048 c1324048 00048000 c66fb1d8 c012a535 4015dcbc ffffffff 00000001 
       c13cd380 c1324048 0000004a c011ef04 c1324048 0000002c 00000000 000c0000 
Call Trace: [<c01cbf4f>] [<c011fc7c>] [<c012a535>] [<c011ef04>] [<c010fd50>] [<c010fec6>] [<c0121638>] 
       [<c01385ba>] [<c0111a66>] [<c0115832>] [<c01109a4>] [<c010fd50>] [<c0106ecb>] 

Code: 0f 0b 83 c4 0c 8b 46 08 85 c0 74 16 6a 4b 68 7a 99 1d c0 68 
kernel BUG at page_alloc.c:73!
invalid operand: 0000
CPU:    0
EIP:    0010:[<c0129603>]
EFLAGS: 00010286
eax: 0000001f   ebx: c1324048   ecx: 00000001   edx: c02099e4
esi: c1324048   edi: 00000000   ebp: c6f511d8   esp: c4ab5b80
ds: 0018   es: 0018   ss: 0018
Process ifup-post (pid: 170, stackpage=c4ab5000)
Stack: c01d98a6 c01d997a 00000049 c4ab5c88 cbfe56c0 c01398ac cbfe55c0 00000001 
       c1324048 c1324048 00048000 c6f511d8 c012a535 08054b88 00000001 40016000 
       c4ab4000 c1324048 0000004a c011ef04 c1324048 0000002c 00000000 000c0000 
Call Trace: [<c01398ac>] [<c012a535>] [<c011ef04>] [<c0142cba>] [<c0122c43>] [<c0121638>] [<c0122d10>] 
       [<c01375a3>] [<c0137710>] [<c01454ff>] [<c01c5507>] [<c01450c0>] [<c0137c6f>] [<c0137efb>] [<c0138dad>] 
       [<c0105b4d>] [<c0106ecb>] 

Code: 0f 0b 83 c4 0c 8b 46 08 85 c0 74 16 6a 4b 68 7a 99 1d c0 68 

exit_mmap: map count is 25
PCI: Found IRQ 10 for device 00:0d.0
3c59x.c:LK1.1.15 6 June 2001 Donald Becker and others. http://www.scyld.com/network/vortex.html
See Documentation/networking/vortex.txt
00:0d.0: 3Com PCI 3c905 Boomerang 100baseTx at 0xd400, 00:60:08:7e:13:4b, IRQ 10
product code 4b4b rev 00.0 date 01-25-98
8K word-wide RAM 3:5 Rx:Tx split, autoselect/MII interface.
MII transceiver found at address 24, status 786f.
Enabling bus-master transmits and whole-frame receives.
00:0d.0: scatter/gather enabled. h/w checksums disabled
eth0: first available media type: MII
kernel BUG at page_alloc.c:73!

invalid operand: 0000
CPU:    0
EIP:    0010:[<c0129603>]
EFLAGS: 00010286
eax: 0000001f   ebx: c1324048   ecx: 00000001   edx: c02099e4
esi: c1324048   edi: 00000000   ebp: c609a1d8   esp: cbbafb80
ds: 0018   es: 0018   ss: 0018
Process S10network (pid: 256, stackpage=cbbaf000)
Stack: c01d98a6 c01d997a 00000049 cbbafc88 cbfe56c0 c01398ac cbfe55c0 00000001 
       c1324048 c1324048 00048000 c609a1d8 c012a535 cbbae000 080c5dd4 c0144a2c 
       080c5dd4 c1324048 0000004a c011ef04 c1324048 0000002c 00000000 000c0000 
Call Trace: [<c01398ac>] [<c012a535>] [<c0144a2c>] [<c011ef04>] [<c0142cba>] [<c0122c43>] [<c0121638>] 
       [<c0122d10>] [<c01375a3>] [<c0137710>] [<c01454ff>] [<c0137caf>] [<c01450c0>] [<c0137c6f>] [<c0137efb>] 
       [<c0138dad>] [<c0105b4d>] [<c0106ecb>] 

Code: 0f 0b 83 c4 0c 8b 46 08 85 c0 74 16 6a 4b 68 7a 99 1d c0 68 
exit_mmap: map count is 25
kernel BUG at page_alloc.c:168!
invalid operand: 0000
CPU:    0
EIP:    0010:[<c0129a84>]
EFLAGS: 00010082
eax: 00000020   ebx: c11600a4   ecx: 00000001   edx: c02099e4
esi: c020ac98   edi: 00000001   ebp: 00000000   esp: c9f97e54
ds: 0018   es: 0018   ss: 0018
Process S85gpm (pid: 365, stackpage=c9f97000)
Stack: c01d98a6 c01d997a 000000a8 000042d5 00000286 00000000 c020ac74 c020ac74 
       c020ae00 00000000 000000d2 c0129c74 00000001 c020adfc bfffefe0 c1312168 
       0b8f6065 c13cda40 c011fc41 c020ac74 c020ac74 c020ade0 00000000 bfffefe0 
Call Trace: [<c0129c74>] [<c011fc41>] [<c01202f0>] [<c01cbe3d>] [<c010fd50>] [<c010fec6>] [<c0111d4a>] 
       [<c0112757>] [<c012ef22>] [<c010fd50>] [<c0106fbc>] 

Code: 0f 0b 83 c4 0c ff 74 24 04 9d c7 43 14 01 00 00 00 8b 44 24 

"Thodoris Pitikaris wrote:"

Try the newest -ac patches. They contain discussed on the list workaround for a VIA chipset bug.
VIA chipsets seem to be unstable when processing fast memory-to-memory copy.

It is definitely not an Athlon processor problem.

Andrzej

=======================================================================
  Andrzej M. Krzysztofowicz               [email protected]
  phone (48)(58) 347 14 61
Faculty of Applied Phys. & Math.,   Technical University of Gdansk

It's a bug in that screwed up compiler redhat shipped with 7.1. AFAIK, the only difference between an athlon-specific kernel and an i686-specific kernel are the options in the compiler command line when compiling the kernel.

Is gcc 3.0 binary compatible with the stupid redhat compiler? If it is, I would upgrade to that. I haven't, myself, because I simply don't know (and can't find any information one way or the other) if binaries from the two compilers are compatible. Someone who knows better, could you shed some light on the subject?

Kelsey Hudson [email protected]
Software Engineer
Compendium Technologies, Inc (619) 725-0771
---------------------------------------------------------------------------

Oh please, not this FUD again.....

jjs

Call it what you wish -- But, if I see something break when using a certain compiler option versus another compiler option that does not cause a break, chances are it's a bug in the compiler. After all, the Athlon support *is* a new feature, is it not?

I don't even know why I bothered replying. Don't feed the trolls... Gotta watch for those signs....

Kelsey Hudson [email protected]
Software Engineer
Compendium Technologies, Inc (619) 725-0771
---------------------------------------------------------------------------

Ah, but if you'd been observant you'd have noticed what kind of motherboard he has (a VIA) and if you have been reading your kernel-list lately, you'd have known that almost noone has been able to get a Athlon-optimized kernel to work in a stable manner on those; probably because of the Athlon-optimizations stressing the hardware too much.

I'd say flakey hardware is the problem here, not the compiler.

/David Weinehall
_ _
// David Weinehall <[email protected]> /> Northern lights wander \\

//  Project MCA Linux hacker        //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </

Please stop deliberately spreading misinformation. The last thing an end user with a problem needs is a bigot with an axe to grind lying to them to make a political point.

Its the classic 'bought the wrong VIA chipset mainboard' problem

Alan

RH has posted updates to many of the gcc-xxx tools, have you installed
the updated compilers and libraries ?

ron

I have the same motherboard, same chipset, same CPU and the same crash. No memory test cpu burn UDMA on/off, replace or remove of components did any good.
Then i replaced the 100mhz SDRAM with a 133mhz and it is 100 % stable since then. No matter which compiler, kernel version, cputype.
It simply works now.

Gerold

Do you happen to have the SDRAM timings of the two sets of DIMMS? It would be interesting to see what changed besides the clock speed on the DIMMS. I'm assuming your PC133 DIMMs are running at at 133Mhz, and you aren't over clocking anything.

Eric

Hi Eric

The CPU is a 1.1GHz tbird 200MHz FSB and i am running it this way. The motherboard can do 100 and 133 MHz but i run
the SDRAM at 100MHz from the beginning, since i have seen lot's of boards with memory problems and i wanted to be on the good side. Both, the old 128MB and the new 256MB SDRAM where sold as PC133. It is a single DIMM in both cases.

When i started to sue the SDRAM for the trouble i checked the SPD and found the 128MB-PC133 was actually a PC100 with a few steps towards PC66 (major brand). So i tried a new one that, at least from the SPD, is a real PC133 and suddenly ...

I have tried to kill it

kernel 2.4.7-xfs from cvs at the moment
athlon optimisations
UDMA on ide0 and ide1
2 harddrives, 1 cdrom, 1 cd/rw

since then, but it works, works, works.

This weekend does not see me at home.
I will send the timings on sunday/monday.

What do you expect to get out of this ?

Gerold

Mostly I am curious about what is going on. I work on linuxBIOS so
(a) I might just have to figure out if there are software work arounds if/when I port to this platform.
(b) I have written enough memory setup code that does SPD on the fly, to compute the DIMM timings, that understanding DIMMS and memory controllers is one of my areas of competence.

If the ram was really PC100 mislabeled, as PC133 and it was being run at 133Mhz I can see the problem. If it was only being run as PC100 I have a problem seeing, why you would have a problem.

Eric