Crusoe's persistent translation on linux?

Hi,

I'm using 2.4.21 kernel on TM5800 Crusoe in Compaq TC1000 Tablet PC. Currently the performance is not very good but the more I learn about its architecture the more I'm obessesed about it (just like the days when I use 68000 Amiga). Too bad that there are very little information about the chip so I can't do anything much to improve the performance myself (like enlarge the translation cache? how?).

On later versions of CMS (Code Morphing Software), there's a piece of system software called "Persistent Translation service". It looks like the purpose of the service is to get the translations from the translation cache according to each user applications run during the session and save them as binary files using the same name with ".SYS.DB" appended, e.g. MOZILLA.EXE.SY.DB, NOTEPAD.EXE.SY.DB

I guess they are the native TM5800 code "essenses (very small part that really get executed)" of those software. If my linux has the service, I imagine that after using the system for a week, my system will be filled by tranlated binaries and the processor will spend more time with native application code than with the CMS. And no one will ask for native crusoe compiler anymore. The best compiler is CMS.

Is it possible to have persistent translation on linux?

Quoted 6 lines

I'm using 2.4.21 kernel on TM5800 Crusoe in Compaq TC1000 Tablet PC. Currently the performance is not very good but the more I learn about its architecture the more I'm obessesed about it (just like the days when I use 68000 Amiga). Too bad that there are very little information about the chip so I can't do anything much to improve the performance myself (like enlarge the translation cache? how?).

How much 'not very good' is the performance? I'm considering buying an Sharp Actius MM10 notebook, and so far I wasn't able to find ANY numbers on how fast a 1GHz Crusoe actually is, nevermind with Linux running on it ... and how much running Linux affects the expected battery life. Can you share your experience?

Quoted 7 lines · Vojtech Pavlik

Quoted 6 lines

I'm using 2.4.21 kernel on TM5800 Crusoe in Compaq TC1000 Tablet PC. Currently the performance is not very good but the more I learn about its architecture the more I'm obessesed about it (just like the days when I use 68000 Amiga). Too bad that there are very little information about the chip so I can't do anything much to improve the performance myself (like enlarge the translation cache? how?).

Quoted 5 lines

How much 'not very good' is the performance? I'm considering buying an Sharp Actius MM10 notebook, and so far I wasn't able to find ANY numbers on how fast a 1GHz Crusoe actually is, nevermind with Linux running on it ... and how much running Linux affects the expected battery life. Can you share your experience?

See http://www.tabletpcbuzz.com/forum/topic.asp?TOPIC_ID=4451
The guy make a real world benchmark and conclude that a 1 GHZ TM5800 with latest CMS and PTT should be comparable with 1 GHZ PIIIm. Normally TM5800 users will say it is comparable to 600-900 MHz PIII.

About running Linux on it. Application launch time is not good (18 sec. to launch GNOME Help, 7 sec. to relaunch). But after that it seems like linux GUI apps are more responsive. Building software projects seem to take longer than it should be. Building OpenOffice.org take more than 4 days while it take about 1-2 days on PIII. I guess the CMS has to translate 'gcc' on every invokation? If so, can the kernel help in any way?

Battery life and Linux should be Ok. You'll have 'longrun' utility to control cpu power consumption vs. performance. I understand that the CPU already control its power consumption itself, even without the help of the kernel, right?

This raises a new question. How about a port of Linux to the "VLIW" so that we can skip x86 "code morphing" interelly?

I'm sure that 1GHz would benefit from it. Is it possible, Linus?

Quoted 1 line · Nuno Silva

This raises a new question. How about a port of Linux to the "VLIW" so that we can skip x86 "code morphing" interelly?

The native crusoe code - even if it was documented and available - is not very conductive to general-purpose OS stuff. It has no notion of memory protection, and there's no MMU for code accesses, so things like kernel modules simply wouldn't work.

Quoted 1 line

I'm sure that 1GHz would benefit from it. Is it possible, Linus?

The translations are usually _better_ than statically compiled native code (because the whole CPU is designed for speculation, and the static compilers don't know how to do that), and thus going to native mode is not necessarily a performance improvement.

So no, it wouldn't really benefit from it, not to mention that it's not even an option since Transmeta has never released enough details to do it anyway. Largely for simple security concerns - if you start giving interfaces for mucking around with the "microcode", you could do some really nasty things.

Process startup is slightly slower due to the translation overhead, but that doesn't matter for the kernel anyway (so a native kernel wouldn't much help). And we do cache translations in memory, even across invocations. I suspect the reason large builds are slower are due to slow memory and/or occasionally overflowing the translation cache.

Linus

So no, it wouldn't really benefit from it, not to mention that it's not even an option since Transmeta has never released enough details to do it anyway. Largely for simple security concerns - if you start giving interfaces for mucking around with the "microcode", you could do some really nasty things.

Quoted 6 lines · Linus Torvalds

So no, it wouldn't really benefit from it, not to mention that it's not even an option since Transmeta has never released enough details to do it anyway. Largely for simple security concerns - if you start giving interfaces for mucking around with the "microcode", you could do some really nasty things.

Did you just write: "the Crusoe has special backdoors built-in which would allow a userspace program to takeover the machine, and Transmeta choose security through obscurity to avoid this problem" ? Nice call for crackers :)

Process startup is slightly slower due to the translation overhead, but that doesn't matter for the kernel anyway (so a native kernel wouldn't much help). And we do cache translations in memory, even across invocations. I suspect the reason large builds are slower are due to slow memory and/or occasionally overflowing the translation cache.

Did you just write: "the Crusoe has special backdoors built-in which would allow a userspace program to takeover the machine, and Transmeta choose security through obscurity to avoid this problem" ? Nice call for crackers :)

Did you just write: "the Crusoe has special backdoors built-in which would allow a userspace program to takeover the machine, and Transmeta choose security through obscurity to avoid this problem" ?

Hi, I'm having trouble running my dual AMD MP box in SMP mode. Runs fine in single CPU mode, but when I enable either RedHat 9.0's stock SMP kernel or my own brew, I don't have to wait long for crashes, oopses and other strange behavior. I've tried 2.4.19, 2.4.20 and 2.4.21 with same results. I can run SMP-enabled kernel with nosmp boot parameter just fine. Only SMP mode causes trouble. I've been doing research on the web for days, tried mem=nopentium, noapic, CONFIG_HIGHMEM4G and CONFIG_NOHIGHMEM.

Hardware:
Tyan S2466 motherboard
Two AMD MP 2000+ processors running at 1666MHz
ATI XPert 2000 Pro 32MB AGP video card
On-board 3Com 3c905C-TX ethernet controller
Promise SX6000 RAID controller, latest firmware, with 6 Maxtor 160GB drives connected to it. Running Promise's driver compiled from source as module as I couldn't get the i2o driver to cooperate.
1GB PC2100 Corsair DIMM
hda - 80 GB Maxtor drive
hdb - unused
hdc - Yamaha CDR/RW
hdd - open slot for another 80GB Maxtor

I will also put two Linksys Gigabit adaptors in the 64 bit slots once I figure out what's going on with SMP.

I am experiencing unstability regardless of whether Promise module is installed or not, so that's not the source of my problems.

I will need some hand-holding in producing documentation that might be needed to troubleshoot this. Please be patient with me, I'm not really a kernel hacker and only a wanna-be programmer :)

The log files attached below are from one of the few boot attempts where the system booted far enough to save log entries to files.

What can I try next?

Artur

Here's my grub.conf so that you know what parameters I start the kernel with:

title Red Hat Linux (2.4.20-030613a-smp)

    root (hd0,0)
    kernel /boot/vmlinuz-2.4.20-030613a-smp ro root=/dev/hda1 noapic nousb
hdc=ide-scsi ide2=noprobe ide3=noprobe ide4=noprobe ide5=noprobe
ide6=noprobe ide7=noprobe mem=nopentium
    initrd /boot/initrd-2.4.20-030613a-smp.img
title Red Hat Linux (2.4.20-8smp)
    root (hd0,0)
    kernel /boot/vmlinuz-2.4.20-8smp ro root=/dev/hda1 hdc=ide-scsi noapic
    initrd /boot/initrd-2.4.20-8smp.img
title Red Hat Linux-up (2.4.20-8)
    root (hd0,0)
    kernel /boot/vmlinuz-2.4.20-8 ro root=/dev/hda1 hdc=ide-scsi
    initrd /boot/initrd-2.4.20-8.img

And here's a sample /var/log/messages file with a nice kernel crash followed by a lockup after restart:

Jun 13 16:51:29 grail syslogd 1.4.1: restart.
Jun 13 16:51:29 grail syslog: syslogd startup succeeded
Jun 13 16:51:29 grail kernel: klogd 1.4.1, log source = /proc/kmsg started.
Jun 13 16:51:29 grail kernel: Linux version 2.4.20-030613a-smp (root@grail)
(gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #2 SMP Fri Jun 13
16:36:27 CDT 2003
Jun 13 16:51:29 grail kernel: BIOS-provided physical RAM map:
Jun 13 16:51:29 grail kernel:  BIOS-e820: 0000000000000000 -
000000000009e400 (usable)
Jun 13 16:51:29 grail kernel:  BIOS-e820: 000000000009e400 -
00000000000a0000 (reserved)
Jun 13 16:51:29 grail kernel:  BIOS-e820: 00000000000ce000 -
0000000000100000 (reserved)
Jun 13 16:51:29 grail kernel:  BIOS-e820: 0000000000100000 -
000000003ff80000 (usable)
Jun 13 16:51:29 grail kernel:  BIOS-e820: 000000003ff80000 -
0000000040000000 (reserved)
Jun 13 16:51:29 grail kernel:  BIOS-e820: 00000000fec00000 -
00000000fec04000 (reserved)
Jun 13 16:51:29 grail kernel:  BIOS-e820: 00000000fee00000 -
00000000fee01000 (reserved)
Jun 13 16:51:29 grail kernel:  BIOS-e820: 00000000fff80000 -
0000000100000000 (reserved)
Jun 13 16:51:29 grail kernel: 127MB HIGHMEM available.
Jun 13 16:51:29 grail kernel: 896MB LOWMEM available.
Jun 13 16:51:29 grail syslog: klogd startup succeeded
Jun 13 16:51:29 grail kernel: found SMP MP-table at 000f7170
Jun 13 16:51:29 grail kernel: hm, page 000f7000 reserved twice.
Jun 13 16:51:29 grail kernel: hm, page 000f8000 reserved twice.
Jun 13 16:51:29 grail kernel: hm, page 0009f000 reserved twice.
Jun 13 16:51:29 grail kernel: hm, page 000a0000 reserved twice.
Jun 13 16:51:29 grail kernel: On node 0 totalpages: 262016
Jun 13 16:51:29 grail kernel: zone(0): 4096 pages.
Jun 13 16:51:29 grail kernel: zone(1): 225280 pages.
Jun 13 16:51:29 grail kernel: zone(2): 32640 pages.
Jun 13 16:51:29 grail kernel: Intel MultiProcessor Specification v1.4
Jun 13 16:51:29 grail kernel:     Virtual Wire compatibility mode.
Jun 13 16:51:29 grail kernel: OEM ID: TYAN     Product ID: PAULANER    
APIC at: 0xFEE00000
Jun 13 16:51:29 grail kernel: Processor #1 Pentium(tm) Pro APIC version 16
Jun 13 16:51:29 grail kernel: Processor #0 Pentium(tm) Pro APIC version 16
Jun 13 16:51:29 grail kernel: I/O APIC #2 Version 17 at 0xFEC00000.
Jun 13 16:51:29 grail kernel: Processors: 2
Jun 13 16:51:29 grail kernel: Kernel command line: ro root=/dev/hda1
hdc=ide-scsi
Jun 13 16:51:29 grail kernel: ide_setup: hdc=ide-scsi
Jun 13 16:51:29 grail kernel: Initializing CPU#0
Jun 13 16:51:29 grail kernel: Detected 1666.731 MHz processor.
Jun 13 16:51:29 grail kernel: Console: colour VGA+ 80x25
Jun 13 16:51:29 grail kernel: Calibrating delay loop... 3329.22 BogoMIPS
Jun 13 16:51:29 grail kernel: Memory: 1032756k/1048064k available (1293k
kernel code, 14916k reserved, 329k data, 308k init, 130560k highmem)
Jun 13 16:51:29 grail kernel: Dentry cache hash table entries: 131072
(order: 8, 1048576 bytes)
Jun 13 16:51:29 grail kernel: Inode cache hash table entries: 65536 (order:
7, 524288 bytes)
Jun 13 16:51:29 grail kernel: Mount-cache hash table entries: 16384 (order:
5, 131072 bytes)
Jun 13 16:51:29 grail kernel: Buffer-cache hash table entries: 65536
(order: 6, 262144 bytes)
Jun 13 16:51:29 grail kernel: Page-cache hash table entries: 262144 (order:
8, 1048576 bytes)
Jun 13 16:51:29 grail kernel: CPU: L1 I Cache: 64K (64 bytes/line), D cache
64K (64 bytes/line)
Jun 13 16:51:29 grail kernel: CPU: L2 Cache: 256K (64 bytes/line)
Jun 13 16:51:29 grail kernel: Intel machine check architecture supported.
Jun 13 16:51:29 grail kernel: Intel machine check reporting enabled on
CPU#0.
Jun 13 16:51:29 grail kernel: Enabling fast FPU save and restore... done.
Jun 13 16:51:29 grail kernel: Enabling unmasked SIMD FPU exception
support... done.
Jun 13 16:51:29 grail kernel: Checking 'hlt' instruction... OK.
Jun 13 16:51:29 grail kernel: POSIX conformance testing by UNIFIX
Jun 13 16:51:29 grail kernel: mtrr: v1.40 (20010327) Richard Gooch
([email protected])
Jun 13 16:51:29 grail kernel: mtrr: detected mtrr type: Intel
Jun 13 16:51:29 grail kernel: CPU: L1 I Cache: 64K (64 bytes/line), D cache
64K (64 bytes/line)
Jun 13 16:51:29 grail kernel: CPU: L2 Cache: 256K (64 bytes/line)
Jun 13 16:51:29 grail kernel: Intel machine check reporting enabled on
CPU#0.
Jun 13 16:51:29 grail kernel: CPU0: AMD Athlon(tm) MP 2000+ stepping 02
Jun 13 16:51:29 grail kernel: per-CPU timeslice cutoff: 731.44 usecs.
Jun 13 16:51:29 grail kernel: masked ExtINT on CPU#0
Jun 13 16:51:29 grail portmap: portmap startup succeeded
Jun 13 16:51:29 grail kernel: ESR value before enabling vector: 00000000
Jun 13 16:51:29 grail kernel: ESR value after enabling vector: 00000000
Jun 13 16:51:29 grail kernel: Booting processor 1/0 eip 2000
Jun 13 16:51:29 grail kernel: Initializing CPU#1
Jun 13 16:51:29 grail kernel: masked ExtINT on CPU#1
Jun 13 16:51:29 grail kernel: ESR value before enabling vector: 00000000
Jun 13 16:51:29 grail kernel: ESR value after enabling vector: 00000000
Jun 13 16:51:29 grail kernel: Calibrating delay loop... 3329.22 BogoMIPS
Jun 13 16:51:29 grail kernel: CPU: L1 I Cache: 64K (64 bytes/line), D cache
64K (64 bytes/line)
Jun 13 16:51:29 grail kernel: CPU: L2 Cache: 256K (64 bytes/line)
Jun 13 16:51:29 grail kernel: Intel machine check reporting enabled on
CPU#1.
Jun 13 16:51:29 grail kernel: CPU1: AMD Athlon(tm) Processor stepping 02
Jun 13 16:51:29 grail kernel: Total of 2 processors activated (6658.45
BogoMIPS).
Jun 13 16:51:29 grail kernel: ENABLING IO-APIC IRQs
Jun 13 16:51:29 grail kernel: Setting 2 in the phys_id_present_map
Jun 13 16:51:29 grail kernel: ...changing IO-APIC physical APIC ID to 2 ...
ok.
Jun 13 16:51:29 grail kernel: ..TIMER: vector=0x31 pin1=2 pin2=0
Jun 13 16:51:30 grail kernel: testing the IO APIC.......................
Jun 13 16:51:30 grail kernel:
Jun 13 16:51:30 grail kernel: .................................... done.
Jun 13 16:51:30 grail kernel: Using local APIC timer interrupts.
Jun 13 16:51:30 grail kernel: calibrating APIC timer ...
Jun 13 16:51:30 grail kernel: ..... CPU clock speed is 1666.8222 MHz.
Jun 13 16:51:30 grail kernel: ..... host bus clock speed is 266.6915 MHz.
Jun 13 16:51:30 grail kernel: cpu: 0, clocks: 2666915, slice: 888971
Jun 13 16:51:30 grail kernel:
CPU0<T0:2666912,T1:1777936,D:5,S:888971,C:2666915>
Jun 13 16:51:30 grail kernel: cpu: 1, clocks: 2666915, slice: 888971
Jun 13 16:51:30 grail kernel:
CPU1<T0:2666912,T1:888960,D:10,S:888971,C:2666915>
Jun 13 16:51:30 grail kernel: checking TSC synchronization across CPUs:
passed.
Jun 13 16:51:30 grail kernel: Waiting on wait_init_idle (map = 0x2)
Jun 13 16:51:30 grail kernel: All processors have done init_idle
Jun 13 16:51:30 grail rpc.statd[412]: Version 1.0.1 Starting
Jun 13 16:51:30 grail kernel: mtrr: your CPUs had inconsistent fixed MTRR
settings
Jun 13 16:51:30 grail nfslock: rpc.statd startup succeeded
Jun 13 16:51:30 grail kernel: mtrr: probably your BIOS does not setup all
CPUs
Jun 13 16:51:30 grail kernel: PCI: PCI BIOS revision 2.10 entry at 0xfd7d0,
last bus=3
Jun 13 16:51:30 grail kernel: PCI: Using configuration type 1
Jun 13 16:51:30 grail kernel: PCI: Probing PCI hardware
Jun 13 16:51:30 grail kernel: PCI->APIC IRQ transform: (B1,I5,P0) -> 18
Jun 13 16:51:30 grail kernel: PCI->APIC IRQ transform: (B2,I0,P3) -> 19
Jun 13 16:51:30 grail kernel: PCI->APIC IRQ transform: (B2,I5,P0) -> 17
Jun 13 16:51:30 grail kernel: PCI->APIC IRQ transform: (B2,I8,P0) -> 19
Jun 13 16:51:30 grail kernel: BIOS failed to enable PCI standards
compliance, fixing this error.
Jun 13 16:51:30 grail kernel: isapnp: Scanning for PnP cards...
Jun 13 16:51:30 grail kernel: isapnp: No Plug & Play device found
Jun 13 16:51:30 grail kernel: Linux NET4.0 for Linux 2.4
Jun 13 16:51:30 grail kernel: Based upon Swansea University Computer
Society NET3.039
Jun 13 16:51:30 grail kernel: Initializing RT netlink socket
Jun 13 16:51:30 grail kernel: apm: BIOS version 1.2 Flags 0x03 (Driver
version 1.16)
Jun 13 16:51:30 grail kernel: apm: disabled - APM is not SMP safe.
Jun 13 16:51:30 grail keytable: Loading keymap:
Jun 13 16:51:30 grail kernel: Starting kswapd
Jun 13 16:51:30 grail kernel: allocated 32 pages and 32 bhs reserved for
the highmem bounces
Jun 13 16:51:30 grail kernel: VFS: Diskquotas version dquot_6.4.0
initialized
Jun 13 16:51:30 grail kernel: Journalled Block Device driver loaded
Jun 13 16:51:30 grail kernel: pty: 2048 Unix98 ptys configured
Jun 13 16:51:30 grail kernel: Serial driver version 5.05c (2001-07-08) with
MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI ISAPNP enabled
Jun 13 16:51:30 grail kernel: ttyS00 at 0x03f8 (irq = 4) is a 16550A
Jun 13 16:51:30 grail kernel: ttyS01 at 0x02f8 (irq = 3) is a 16550A
Jun 13 16:51:30 grail kernel: Real Time Clock Driver v1.10e
Jun 13 16:51:30 grail kernel: Uniform Multi-Platform E-IDE driver Revision:
6.31
Jun 13 16:51:30 grail kernel: ide: Assuming 33MHz system bus speed for PIO
modes; override with idebus=xx
Jun 13 16:51:30 grail kernel: AMD7441: IDE controller on PCI bus 00 dev 39
Jun 13 16:51:30 grail keytable:
Jun 13 16:51:30 grail kernel: AMD7441: chipset revision 4
Jun 13 16:51:30 grail keytable: Loading system font:
Jun 13 16:51:30 grail kernel: AMD7441: not 100%% native mode: will probe
irqs later
Jun 13 16:51:30 grail kernel: AMD7441: disabling single-word DMA support
(revision < C4)
Jun 13 16:51:30 grail kernel:     ide0: BM-DMA at 0xf000-0xf007, BIOS
settings: hda:DMA, hdb:pio
Jun 13 16:51:30 grail kernel:     ide1: BM-DMA at 0xf008-0xf00f, BIOS
settings: hdc:DMA, hdd:DMA
Jun 13 16:51:30 grail kernel: hda: MAXTOR 6L080J4, ATA DISK drive
Jun 13 16:51:30 grail kernel: hdc: YAMAHA CRW2200E, ATAPI CD/DVD-ROM drive
Jun 13 16:51:30 grail kernel: hdd: MAXTOR 6L080J4, ATA DISK drive
Jun 13 16:51:30 grail kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Jun 13 16:51:30 grail kernel: ide1 at 0x170-0x177,0x376 on irq 15
Jun 13 16:51:30 grail keytable:
Jun 13 16:51:30 grail kernel: blk: queue c034cd64, I/O limit 4095Mb (mask
0xffffffff)
Jun 13 16:51:30 grail kernel: hda: 156355584 sectors (80054 MB) w/1819KiB
Cache, CHS=155114/16/63, UDMA(100)
Jun 13 16:51:30 grail rc: Starting keytable:  succeeded
Jun 13 16:51:30 grail kernel: blk: queue c034d214, I/O limit 4095Mb (mask
0xffffffff)
Jun 13 16:51:30 grail kernel: hdd: 156355584 sectors (80054 MB) w/1819KiB
Cache, CHS=155114/16/63, UDMA(100)
Jun 13 16:51:30 grail kernel: Partition check:
Jun 13 16:51:30 grail kernel:  hda: hda1 hda2 hda3 hda4 < hda5 hda6 >
Jun 13 16:51:30 grail kernel:  hdd: hdd1 hdd2 hdd3 hdd4 < hdd5 hdd6 >
Jun 13 16:51:30 grail kernel: Floppy drive(s): fd0 is 1.44M
Jun 13 16:51:30 grail kernel: FDC 0 is a post-1991 82077
Jun 13 16:51:30 grail kernel: RAMDISK driver initialized: 16 RAM disks of
4096K size 1024 blocksize
Jun 13 16:51:30 grail kernel: md: md driver 0.90.0 MAX_MD_DEVS=256,
MD_SB_DISKS=27
Jun 13 16:51:30 grail kernel: md: Autodetecting RAID arrays.
Jun 13 16:51:30 grail kernel: md: autorun ...
Jun 13 16:51:30 grail kernel: md: ... autorun DONE.
Jun 13 16:51:30 grail kernel: NET4: Linux TCP/IP 1.0 for NET4.0
Jun 13 16:51:30 grail kernel: IP Protocols: ICMP, UDP, TCP
Jun 13 16:51:30 grail kernel: IP: routing cache hash table of 8192 buckets,
64Kbytes
Jun 13 16:51:30 grail kernel: TCP: Hash tables configured (established
262144 bind 65536)
Jun 13 16:51:30 grail kernel: NET4: Unix domain sockets 1.0/SMP for Linux
NET4.0.
Jun 13 16:51:30 grail kernel: RAMDISK: Compressed image found at block 0
Jun 13 16:51:30 grail kernel: Freeing initrd memory: 83k freed
Jun 13 16:51:30 grail kernel: VFS: Mounted root (ext2 filesystem).
Jun 13 16:51:30 grail kernel: kjournald starting.  Commit interval 5
seconds Jun 13 16:51:30 grail kernel: EXT3-fs: mounted filesystem with
ordered data mode.
Jun 13 16:51:30 grail kernel: Freeing unused kernel memory: 308k freed
Jun 13 16:51:30 grail kernel: usb.c: registered new driver usbdevfs
Jun 13 16:51:30 grail kernel: usb.c: registered new driver hub
Jun 13 16:51:30 grail kernel: usb-ohci.c: USB OHCI at membase 0xf8829000,
IRQ 19
Jun 13 16:51:30 grail kernel: usb-ohci.c: usb-02:00.0, Advanced Micro
Devices [AMD] AMD-768 [Opus] USB
Jun 13 16:51:30 grail kernel: usb.c: new USB bus registered, assigned bus
number 1
Jun 13 16:51:30 grail kernel: hub.c: USB hub found
Jun 13 16:51:30 grail kernel: hub.c: 4 ports detected
Jun 13 16:51:30 grail kernel: mice: PS/2 mouse device common for all mice
Jun 13 16:51:30 grail kernel: EXT3 FS 2.4-0.9.19, 19 August 2002 on
ide0(3,1), internal journal
Jun 13 16:51:30 grail random: Initializing random number generator:
succeeded
Jun 13 16:51:30 grail kernel: Adding Swap: 1048816k swap-space (priority
-1) Jun 13 16:51:30 grail kernel: kjournald starting.  Commit interval 5
seconds Jun 13 16:51:30 grail kernel: EXT3 FS 2.4-0.9.19, 19 August 2002 on
ide0(3,6), internal journal
Jun 13 16:51:30 grail kernel: EXT3-fs: mounted filesystem with ordered data
mode.
Jun 13 16:51:30 grail kernel: kjournald starting.  Commit interval 5
seconds Jun 13 16:51:30 grail kernel: EXT3 FS 2.4-0.9.19, 19 August 2002 on
ide0(3,5), internal journal
Jun 13 16:51:30 grail kernel: EXT3-fs: mounted filesystem with ordered data
mode.
Jun 13 16:51:30 grail kernel: kjournald starting.  Commit interval 5
seconds Jun 13 16:51:30 grail kernel: EXT3 FS 2.4-0.9.19, 19 August 2002 on
ide0(3,2), internal journal
Jun 13 16:51:30 grail kernel: EXT3-fs: mounted filesystem with ordered data
mode.
Jun 13 16:51:30 grail kernel: SCSI subsystem driver Revision: 1.00
Jun 13 16:51:30 grail kernel: scsi0 : SCSI host adapter emulation for IDE
ATAPI devices
Jun 13 16:51:30 grail kernel:   Vendor: YAMAHA    Model: CRW2200E
Rev: 1.0B
Jun 13 16:51:30 grail kernel:   Type:   CD-ROM
ANSI SCSI revision: 02
Jun 13 16:51:30 grail kernel: kernel BUG at page_alloc.c:100!
Jun 13 16:51:30 grail kernel: invalid operand: 0000
Jun 13 16:51:30 grail kernel: CPU:    0
Jun 13 16:51:30 grail kernel: EIP:    0010:[<c013b0c2>]    Not tainted
Jun 13 16:51:30 grail kernel: EFLAGS: 00010282
Jun 13 16:51:30 grail kernel: eax: c1a847ac   ebx: c1a84760   ecx: f7fe6270
edx: c1a842cc
Jun 13 16:51:30 grail kernel: esi: 000000b2   edi: 00000000   ebp: 000000b2
esp: f7861e3c
Jun 13 16:51:30 grail kernel: ds: 0018   es: 0018   ss: 0018
Jun 13 16:51:30 grail rc: Starting pcmcia:  succeeded
Jun 13 16:51:30 grail kernel: Process initlog (pid: 13, stackpage=f7861000)
Jun 13 16:51:30 grail kernel: Stack: c0281038 c1000020 c1a84820 c0280fa8
c1a80020 00000217 fffffffc 00000030
Jun 13 16:51:30 grail kernel:        00000003 000000b2 08105000 000000b2
c012eb6f c1a84760 f7862080 08051000
Jun 13 16:51:30 grail kernel:        000b4000 08451000 c02f6800 000000b2
08105000 f7862084 f78d0ac0 f78d2e00
Jun 13 16:51:30 grail kernel: Call Trace:    [<c012eb6f>] [<c0131b04>]
[<c011ce2b>] [<c012240c>] [<c0128fb3>]
Jun 13 16:51:30 grail kernel:   [<c01291b5>] [<c0108ee2>] [<c01554df>]
[<c0154b7a>] [<c0155823>] [<c0109238>]
Jun 13 16:51:30 grail kernel:
Jun 13 16:51:30 grail kernel: Code: 0f 0b 64 00 74 29 25 c0 8b 53 08 85 d2
74 08 0f 0b 66 00 74
Jun 13 16:51:30 grail kernel:  <6>parport0: PC-style at 0x378 (0x778)
[PCSPP,TRISTATE,EPP]
Jun 13 16:51:30 grail kernel: parport0: irq 7 detected
Jun 13 16:51:30 grail netfs: Mounting other filesystems:  succeeded
Jun 13 16:51:30 grail autofs: automount startup succeeded
Jun 13 16:51:30 grail sshd:  succeeded
Jun 13 16:51:29 grail sysctl: net.ipv4.ip_forward = 0
Jun 13 16:51:29 grail sysctl: net.ipv4.conf.default.rp_filter = 1
Jun 13 16:51:29 grail sysctl: kernel.sysrq = 0
Jun 13 16:51:29 grail sysctl: kernel.core_uses_pid = 1
Jun 13 16:51:29 grail network: Setting network parameters:  succeeded
Jun 13 16:51:29 grail ifup: grep: relocation error: grep: symbol , version
GLIBC_2.0 not defined in file libc.so.6 with link time reference
Jun 13 16:51:29 grail ifup: grep: relocation error: grep: symbol , version
GLIBC_2.0 not defined in file libc.so.6 with link time reference
Jun 13 16:51:29 grail network: Bringing up loopback interface:  succeeded
Jun 13 16:51:29 grail ifup: grep: relocation error: grep: symbol , version
GLIBC_2.0 not defined in file libc.so.6 with link time reference
Jun 13 16:51:29 grail network: Bringing up interface eth0:  succeeded
Jun 13 16:51:32 grail xinetd[522]: xinetd Version 2.3.10 started with
libwrap options compiled in.
Jun 13 16:51:32 grail xinetd[522]: Started working: 1 available service
Jun 13 16:51:34 grail xinetd: xinetd startup succeeded
Jun 13 16:51:34 grail sendmail: sendmail startup succeeded
Jun 13 16:51:34 grail sendmail: sm-client startup succeeded
Jun 13 16:51:34 grail gpm: gpm startup succeeded
Jun 13 16:51:35 grail crond: crond startup succeeded
Jun 13 16:51:36 grail kernel: parport0: PC-style at 0x378 (0x778)
[PCSPP,TRISTATE,EPP]
Jun 13 16:51:36 grail kernel: parport0: irq 7 detected
Jun 13 16:51:36 grail kernel: lp0: using parport0 (polling).
Jun 13 16:51:36 grail kernel: lp0: console ready
Jun 13 16:51:36 grail modprobe: modprobe: Can't locate module
char-major-188 Jun 13 16:51:36 grail last message repeated 15 times
Jun 13 16:51:37 grail cups: cupsd startup succeeded
Jun 13 16:51:37 grail xfs: xfs startup succeeded
Jun 13 16:51:37 grail anacron: anacron startup succeeded
Jun 13 16:51:37 grail atd: atd startup succeeded
Jun 13 16:51:37 grail xfs: ignoring font path element
/usr/X11R6/lib/X11/fonts/cyrillic (unreadable)
Jun 13 16:51:43 grail login(pam_unix)[668]: session opened for user root by
LOGIN(uid=0)
Jun 13 16:51:43 grail  -- root[668]: ROOT LOGIN ON tty1
Jun 13 16:54:47 grail kernel: kjournald starting.  Commit interval 5
seconds Jun 13 16:54:47 grail kernel: EXT3 FS 2.4-0.9.19, 19 August 2002 on
ide1(22,65), internal journal
Jun 13 16:54:47 grail kernel: EXT3-fs: mounted filesystem with ordered data
mode.
Jun 13 16:56:29 grail shutdown: shutting down for system reboot
Jun 13 16:56:29 grail init: Switching to runlevel: 6
Jun 13 16:56:29 grail login(pam_unix)[668]: session closed for user root
Jun 13 16:56:30 grail atd: atd shutdown succeeded
Jun 13 16:56:30 grail init: no more processes left in this runlevel
Jun 13 16:56:40 grail shutdown: shutting down for system reboot
Jun 13 17:00:09 grail syslogd 1.4.1: restart.
Jun 13 17:00:09 grail syslog: syslogd startup succeeded
Jun 13 17:00:09 grail kernel: klogd 1.4.1, log source = /proc/kmsg started.
Jun 13 17:00:09 grail kernel: Linux version 2.4.20-030613a-smp (root@grail)
(gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #2 SMP Fri Jun 13
16:36:27 CDT 2003
Jun 13 17:00:09 grail kernel: BIOS-provided physical RAM map:
Jun 13 17:00:09 grail kernel:  BIOS-e820: 0000000000000000 -
000000000009e400 (usable)
Jun 13 17:00:09 grail kernel:  BIOS-e820: 000000000009e400 -
00000000000a0000 (reserved)
Jun 13 17:00:09 grail kernel:  BIOS-e820: 00000000000ce000 -
0000000000100000 (reserved)
Jun 13 17:00:09 grail kernel:  BIOS-e820: 0000000000100000 -
000000003ff80000 (usable)
Jun 13 17:00:09 grail kernel:  BIOS-e820: 000000003ff80000 -
0000000040000000 (reserved)
Jun 13 17:00:09 grail kernel:  BIOS-e820: 00000000fec00000 -
00000000fec04000 (reserved)
Jun 13 17:00:09 grail kernel:  BIOS-e820: 00000000fee00000 -
00000000fee01000 (reserved)
Jun 13 17:00:09 grail kernel:  BIOS-e820: 00000000fff80000 -
0000000100000000 (reserved)
Jun 13 17:00:09 grail kernel: 127MB HIGHMEM available.
Jun 13 17:00:09 grail kernel: 896MB LOWMEM available.
Jun 13 17:00:09 grail kernel: found SMP MP-table at 000f7170
Jun 13 17:00:09 grail kernel: hm, page 000f7000 reserved twice.
Jun 13 17:00:09 grail kernel: hm, page 000f8000 reserved twice.
Jun 13 17:00:09 grail syslog: klogd startup succeeded
Jun 13 17:00:09 grail kernel: hm, page 0009f000 reserved twice.
Jun 13 17:00:09 grail kernel: hm, page 000a0000 reserved twice.
Jun 13 17:00:09 grail kernel: On node 0 totalpages: 262016
Jun 13 17:00:09 grail kernel: zone(0): 4096 pages.
Jun 13 17:00:09 grail kernel: zone(1): 225280 pages.
Jun 13 17:00:09 grail kernel: zone(2): 32640 pages.
Jun 13 17:00:09 grail kernel: Intel MultiProcessor Specification v1.4
Jun 13 17:00:09 grail kernel:     Virtual Wire compatibility mode.
Jun 13 17:00:09 grail kernel: OEM ID: TYAN     Product ID: PAULANER    
APIC at: 0xFEE00000
Jun 13 17:00:09 grail kernel: Processor #1 Pentium(tm) Pro APIC version 16
Jun 13 17:00:09 grail kernel: Processor #0 Pentium(tm) Pro APIC version 16
Jun 13 17:00:09 grail kernel: I/O APIC #2 Version 17 at 0xFEC00000.
Jun 13 17:00:09 grail kernel: Processors: 2
Jun 13 17:00:09 grail kernel: Kernel command line: ro root=/dev/hda1
mem=nopentium noapic nousb hdc=ide-scsi ide2=noprobe ide3=noprobe
ide4=noprobe ide5=noprobe ide6=noprobe ide7=noprobe
Jun 13 17:00:09 grail kernel: ide_setup: hdc=ide-scsi
Jun 13 17:00:09 grail kernel: ide_setup: ide2=noprobe
Jun 13 17:00:09 grail kernel: ide_setup: ide3=noprobe
Jun 13 17:00:09 grail kernel: ide_setup: ide4=noprobe
Jun 13 17:00:09 grail kernel: ide_setup: ide5=noprobe
Jun 13 17:00:09 grail kernel: ide_setup: ide6=noprobe
Jun 13 17:00:09 grail kernel: ide_setup: ide7=noprobe
Jun 13 17:00:09 grail kernel: Initializing CPU#0
Jun 13 17:00:09 grail kernel: Detected 1666.763 MHz processor.
Jun 13 17:00:09 grail kernel: Console: colour VGA+ 80x25
Jun 13 17:00:09 grail kernel: Calibrating delay loop... 3322.67 BogoMIPS
Jun 13 17:00:09 grail kernel: Memory: 1031860k/1048064k available (1293k
kernel code, 15812k reserved, 329k data, 308k init, 130560k highmem)
Jun 13 17:00:09 grail kernel: Checking if this processor honours the WP bit
even in supervisor mode... Ok.
Jun 13 17:00:09 grail kernel: Dentry cache hash table entries: 131072
(order: 8, 1048576 bytes)
Jun 13 17:00:09 grail kernel: Inode cache hash table entries: 65536 (order:
7, 524288 bytes)
Jun 13 17:00:09 grail kernel: Mount-cache hash table entries: 16384 (order:
5, 131072 bytes)
Jun 13 17:00:09 grail kernel: Buffer-cache hash table entries: 65536
(order: 6, 262144 bytes)
Jun 13 17:00:09 grail kernel: Page-cache hash table entries: 262144 (order:
8, 1048576 bytes)
Jun 13 17:00:09 grail kernel: CPU: L1 I Cache: 64K (64 bytes/line), D cache
64K (64 bytes/line)
Jun 13 17:00:09 grail kernel: CPU: L2 Cache: 256K (64 bytes/line)
Jun 13 17:00:09 grail kernel: Intel machine check architecture supported.
Jun 13 17:00:09 grail kernel: Intel machine check reporting enabled on
CPU#0.
Jun 13 17:00:09 grail kernel: Enabling fast FPU save and restore... done.
Jun 13 17:00:09 grail kernel: Enabling unmasked SIMD FPU exception
support... done.
Jun 13 17:00:09 grail kernel: Checking 'hlt' instruction... OK.
Jun 13 17:00:09 grail kernel: POSIX conformance testing by UNIFIX
Jun 13 17:00:09 grail kernel: mtrr: v1.40 (20010327) Richard Gooch
([email protected])
Jun 13 17:00:09 grail kernel: mtrr: detected mtrr type: Intel
Jun 13 17:00:09 grail kernel: CPU: L1 I Cache: 64K (64 bytes/line), D cache
64K (64 bytes/line)
Jun 13 17:00:09 grail portmap: portmap startup succeeded
Jun 13 17:00:09 grail kernel: CPU: L2 Cache: 256K (64 bytes/line)
Jun 13 17:00:09 grail kernel: Intel machine check reporting enabled on
CPU#0.
Jun 13 17:00:09 grail kernel: CPU0: AMD Athlon(tm) MP 2000+ stepping 02
Jun 13 17:00:09 grail kernel: per-CPU timeslice cutoff: 731.44 usecs.
Jun 13 17:00:09 grail kernel: masked ExtINT on CPU#0
Jun 13 17:00:09 grail kernel: ESR value before enabling vector: 00000000
Jun 13 17:00:09 grail kernel: ESR value after enabling vector: 00000000
Jun 13 17:00:09 grail kernel: Booting processor 1/0 eip 2000
Jun 13 17:00:09 grail kernel: Initializing CPU#1
Jun 13 17:00:09 grail kernel: masked ExtINT on CPU#1
Jun 13 17:00:09 grail kernel: ESR value before enabling vector: 00000000
Jun 13 17:00:09 grail kernel: ESR value after enabling vector: 00000000
Jun 13 17:00:09 grail kernel: Calibrating delay loop... 3329.22 BogoMIPS
Jun 13 17:00:09 grail kernel: CPU: L1 I Cache: 64K (64 bytes/line), D cache
64K (64 bytes/line)
Jun 13 17:00:09 grail kernel: CPU: L2 Cache: 256K (64 bytes/line)
Jun 13 17:00:09 grail kernel: Intel machine check reporting enabled on
CPU#1.
Jun 13 17:00:09 grail kernel: CPU1: AMD Athlon(tm) Processor stepping 02
Jun 13 17:00:09 grail kernel: Total of 2 processors activated (6651.90
BogoMIPS).
Jun 13 17:00:09 grail kernel: Using local APIC timer interrupts.
Jun 13 17:00:09 grail kernel: calibrating APIC timer ...
Jun 13 17:00:09 grail kernel: ..... CPU clock speed is 1666.8537 MHz.
Jun 13 17:00:09 grail kernel: ..... host bus clock speed is 266.6966 MHz.
Jun 13 17:00:09 grail kernel: cpu: 0, clocks: 2666966, slice: 888988
Jun 13 17:00:09 grail kernel:
CPU0<T0:2666960,T1:1777968,D:4,S:888988,C:2666966>
Jun 13 17:00:09 grail kernel: cpu: 1, clocks: 2666966, slice: 888988
Jun 13 17:00:09 grail kernel:
CPU1<T0:2666960,T1:888976,D:8,S:888988,C:2666966>
Jun 13 17:00:09 grail kernel: checking TSC synchronization across CPUs:
passed.
Jun 13 17:00:09 grail kernel: Waiting on wait_init_idle (map = 0x2)
Jun 13 17:00:09 grail kernel: All processors have done init_idle
Jun 13 17:00:09 grail kernel: mtrr: your CPUs had inconsistent fixed MTRR
settings
Jun 13 17:00:09 grail kernel: mtrr: probably your BIOS does not setup all
CPUs
Jun 13 17:00:09 grail kernel: PCI: PCI BIOS revision 2.10 entry at 0xfd7d0,
last bus=3
Jun 13 17:00:09 grail kernel: PCI: Using configuration type 1
Jun 13 17:00:09 grail kernel: PCI: Probing PCI hardware
Jun 13 17:00:09 grail kernel: BIOS failed to enable PCI standards
compliance, fixing this error.
Jun 13 17:00:09 grail kernel: isapnp: Scanning for PnP cards...
Jun 13 17:00:09 grail rpc.statd[459]: Version 1.0.1 Starting
Jun 13 17:00:09 grail kernel: isapnp: No Plug & Play device found
Jun 13 17:00:09 grail nfslock: rpc.statd startup succeeded
Jun 13 17:00:09 grail kernel: Linux NET4.0 for Linux 2.4
Jun 13 17:00:09 grail kernel: Based upon Swansea University Computer
Society NET3.039
Jun 13 17:00:09 grail kernel: Initializing RT netlink socket
Jun 13 17:00:09 grail kernel: apm: BIOS version 1.2 Flags 0x03 (Driver
version 1.16)
Jun 13 17:00:09 grail kernel: apm: disabled - APM is not SMP safe.
Jun 13 17:00:09 grail kernel: Starting kswapd
Jun 13 17:00:09 grail kernel: allocated 32 pages and 32 bhs reserved for
the highmem bounces
Jun 13 17:00:09 grail kernel: VFS: Diskquotas version dquot_6.4.0
initialized
Jun 13 17:00:09 grail kernel: Journalled Block Device driver loaded
Jun 13 17:00:09 grail kernel: pty: 2048 Unix98 ptys configured
Jun 13 17:00:09 grail kernel: Serial driver version 5.05c (2001-07-08) with
MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI ISAPNP enabled
Jun 13 17:00:09 grail kernel: ttyS00 at 0x03f8 (irq = 4) is a 16550A
Jun 13 17:00:09 grail kernel: ttyS01 at 0x02f8 (irq = 3) is a 16550A
Jun 13 17:00:09 grail kernel: Real Time Clock Driver v1.10e
Jun 13 17:00:09 grail kernel: Uniform Multi-Platform E-IDE driver Revision:
6.31
Jun 13 17:00:09 grail kernel: ide: Assuming 33MHz system bus speed for PIO
modes; override with idebus=xx
Jun 13 17:00:09 grail kernel: AMD7441: IDE controller on PCI bus 00 dev 39
Jun 13 17:00:09 grail kernel: AMD7441: chipset revision 4
Jun 13 17:00:09 grail keytable: Loading keymap:
Jun 13 17:00:09 grail kernel: AMD7441: not 100%% native mode: will probe
irqs later
Jun 13 17:00:09 grail kernel: AMD7441: disabling single-word DMA support
(revision < C4)
Jun 13 17:00:09 grail kernel:     ide0: BM-DMA at 0xf000-0xf007, BIOS
settings: hda:DMA, hdb:pio
Jun 13 17:00:09 grail kernel:     ide1: BM-DMA at 0xf008-0xf00f, BIOS
settings: hdc:DMA, hdd:pio
Jun 13 17:00:09 grail kernel: hda: MAXTOR 6L080J4, ATA DISK drive
Jun 13 17:00:09 grail kernel: hdc: YAMAHA CRW2200E, ATAPI CD/DVD-ROM drive
Jun 13 17:00:09 grail kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Jun 13 17:00:09 grail kernel: ide1 at 0x170-0x177,0x376 on irq 15
Jun 13 17:00:09 grail kernel: blk: queue c034cd64, I/O limit 4095Mb (mask
0xffffffff)
Jun 13 17:00:09 grail kernel: hda: 156355584 sectors (80054 MB) w/1819KiB
Cache, CHS=155114/16/63, UDMA(100)
Jun 13 17:00:09 grail kernel: Partition check:
Jun 13 17:00:09 grail kernel:  hda: hda1 hda2 hda3 hda4 < hda5 hda6 >
Jun 13 17:00:09 grail keytable:
Jun 13 17:00:09 grail kernel: Floppy drive(s): fd0 is 1.44M
Jun 13 17:00:09 grail keytable: Loading system font:
Jun 13 17:00:09 grail kernel: FDC 0 is a post-1991 82077
Jun 13 17:00:09 grail kernel: RAMDISK driver initialized: 16 RAM disks of
4096K size 1024 blocksize
Jun 13 17:00:09 grail kernel: md: md driver 0.90.0 MAX_MD_DEVS=256,
MD_SB_DISKS=27
Jun 13 17:00:09 grail kernel: md: Autodetecting RAID arrays.
Jun 13 17:00:09 grail kernel: md: autorun ...
Jun 13 17:00:09 grail kernel: md: ... autorun DONE.
Jun 13 17:00:09 grail kernel: NET4: Linux TCP/IP 1.0 for NET4.0
Jun 13 17:00:09 grail kernel: IP Protocols: ICMP, UDP, TCP
Jun 13 17:00:09 grail kernel: IP: routing cache hash table of 8192 buckets,
64Kbytes
Jun 13 17:00:09 grail kernel: TCP: Hash tables configured (established
262144 bind 65536)
Jun 13 17:00:09 grail keytable:
Jun 13 17:00:09 grail kernel: NET4: Unix domain sockets 1.0/SMP for Linux
NET4.0.
Jun 13 17:00:09 grail rc: Starting keytable:  succeeded
Jun 13 17:00:09 grail kernel: RAMDISK: Compressed image found at block 0
Jun 13 17:00:09 grail kernel: Freeing initrd memory: 83k freed
Jun 13 17:00:09 grail kernel: VFS: Mounted root (ext2 filesystem).
Jun 13 17:00:09 grail kernel: kjournald starting.  Commit interval 5
seconds Jun 13 17:00:09 grail kernel: EXT3-fs: mounted filesystem with
ordered data mode.
Jun 13 17:00:09 grail kernel: Freeing unused kernel memory: 308k freed
Jun 13 17:00:09 grail kernel: EXT3 FS 2.4-0.9.19, 19 August 2002 on
ide0(3,1), internal journal
Jun 13 17:00:09 grail kernel: Adding Swap: 1048816k swap-space (priority
-1) Jun 13 17:00:09 grail kernel: kjournald starting.  Commit interval 5
seconds Jun 13 17:00:09 grail kernel: EXT3 FS 2.4-0.9.19, 19 August 2002 on
ide0(3,6), internal journal
Jun 13 17:00:09 grail kernel: EXT3-fs: mounted filesystem with ordered data
mode.
Jun 13 17:00:09 grail kernel: kjournald starting.  Commit interval 5
seconds Jun 13 17:00:09 grail kernel: EXT3 FS 2.4-0.9.19, 19 August 2002 on
ide0(3,5), internal journal
Jun 13 17:00:09 grail kernel: EXT3-fs: mounted filesystem with ordered data
mode.
Jun 13 17:00:09 grail kernel: kjournald starting.  Commit interval 5
seconds Jun 13 17:00:10 grail kernel: EXT3 FS 2.4-0.9.19, 19 August 2002 on
ide0(3,2), internal journal
Jun 13 17:00:10 grail kernel: EXT3-fs: mounted filesystem with ordered data
mode.
Jun 13 17:00:10 grail kernel: SCSI subsystem driver Revision: 1.00
Jun 13 17:00:10 grail kernel: scsi0 : SCSI host adapter emulation for IDE
ATAPI devices
Jun 13 17:00:10 grail kernel:   Vendor: YAMAHA    Model: CRW2200E
Rev: 1.0B
Jun 13 17:00:10 grail kernel:   Type:   CD-ROM
ANSI SCSI revision: 02
Jun 13 17:00:10 grail kernel: usb.c: registered new driver usbdevfs
Jun 13 17:00:10 grail kernel: usb.c: registered new driver hub
Jun 13 17:00:10 grail kernel: usb-ohci.c: USB OHCI at membase 0xf88df000,
IRQ 10
Jun 13 17:00:10 grail kernel: usb-ohci.c: usb-02:00.0, Advanced Micro
Devices [AMD] AMD-768 [Opus] USB
Jun 13 17:00:10 grail kernel: usb.c: new USB bus registered, assigned bus
number 1
Jun 13 17:00:10 grail kernel: hub.c: USB hub found
Jun 13 17:00:10 grail kernel: hub.c: 4 ports detected
Jun 13 17:00:10 grail kernel: usb.c: USB disconnect on device 02:00.0-0
address 1
Jun 13 17:00:10 grail random: Initializing random number generator:
succeeded
Jun 13 17:00:10 grail kernel: usb.c: USB bus 1 deregistered
Jun 13 17:00:10 grail kernel: usb.c: deregistering driver usbdevfs
Jun 13 17:00:10 grail kernel: usb.c: deregistering driver hub
Jun 13 17:00:10 grail kernel: parport0: PC-style at 0x378 (0x778)
[PCSPP,TRISTATE,EPP]
Jun 13 17:00:10 grail kernel: parport0: irq 7 detected
Jun 13 17:00:10 grail kernel: Attached scsi CD-ROM sr0 at scsi0, channel 0,
id 0, lun 0
Jun 13 17:00:10 grail kernel: sr0: scsi3-mmc drive: 40x/40x writer cd/rw
xa/form2 cdda tray
Jun 13 17:00:10 grail kernel: Uniform CD-ROM driver Revision: 3.12
Jun 13 17:00:10 grail kernel: 3c59x: Donald Becker and others.
www.scyld.com/network/vortex.html
Jun 13 17:00:10 grail kernel: 02:08.0: 3Com PCI 3c905C Tornado at 0x3000.
Vers LK1.1.16
Jun 13 17:00:10 grail rc: Starting pcmcia:  succeeded
Jun 13 17:00:10 grail netfs: Mounting other filesystems:  succeeded
Jun 13 17:00:10 grail autofs: automount startup succeeded
Jun 13 17:00:10 grail sshd:  succeeded
Jun 13 17:00:07 grail network: Setting network parameters:  succeeded
Jun 13 17:00:07 grail network: Bringing up loopback interface:  succeeded
Jun 13 17:00:12 grail xinetd[569]: xinetd Version 2.3.10 started with
libwrap options compiled in.
Jun 13 17:00:12 grail xinetd[569]: Started working: 1 available service
Jun 13 17:00:13 grail xinetd: xinetd startup succeeded
Jun 13 17:00:14 grail sendmail: sendmail startup succeeded
Jun 13 17:00:14 grail sendmail: sm-client startup succeeded
Jun 13 17:00:14 grail gpm: gpm startup succeeded
Jun 13 17:00:15 grail crond: crond startup succeeded
Jun 13 17:00:16 grail kernel: parport0: PC-style at 0x378 (0x778)
[PCSPP,TRISTATE,EPP]
Jun 13 17:00:16 grail kernel: parport0: irq 7 detected
Jun 13 17:00:16 grail kernel: lp0: using parport0 (polling).
Jun 13 17:00:16 grail kernel: lp0: console ready
Jun 13 17:00:16 grail kernel: spurious 8259A interrupt: IRQ7.
Jun 13 17:00:16 grail modprobe: modprobe: Can't locate module
char-major-188 Jun 13 17:00:16 grail last message repeated 15 times
Jun 13 17:00:16 grail modprobe: modprobe: Can't locate module
char-major-180 Jun 13 17:00:16 grail last message repeated 15 times
Jun 13 17:00:16 grail cups: cupsd startup succeeded
Jun 13 17:00:17 grail xfs: xfs startup succeeded
Jun 13 17:00:17 grail anacron: anacron startup succeeded
Jun 13 17:00:17 grail atd: atd startup succeeded
Jun 13 17:00:17 grail xfs: ignoring font path element
/usr/X11R6/lib/X11/fonts/cyrillic (unreadable)
Jun 13 17:00:27 grail login(pam_unix)[731]: session opened for user root by
LOGIN(uid=0)
Jun 13 17:00:27 grail  -- root[731]: ROOT LOGIN ON tty1
Jun 13 17:00:36 grail kernel: Found PTI SuperTrak at mbase: 0xf0800000, irq
5.
Jun 13 17:00:36 grail kernel:  Timeout wait for IOP Status Get Ready!
Jun 13 17:00:36 grail last message repeated 2 times
Jun 13 17:00:36 grail kernel: scsi1 : PROMISE SuperTrak SX6000 Driver
Jun 13 17:00:36 grail kernel:   Vendor: PTI       Model: SuperTrak
Rev:
Jun 13 17:00:36 grail kernel:   Type:   Direct-Access
ANSI SCSI revision: 02
Jun 13 17:11:20 grail kernel: Attached scsi disk sda at scsi1, channel 0,
id 0, lun 0
Jun 13 17:11:20 grail kernel: SCSI device sda: 1273437184 512-byte hdwr
sectors (-447511 MB)
Jun 13 17:11:20 grail kernel:  sda: sda1
Jun 13 17:11:21 grail kernel: kjournald starting.  Commit interval 5
seconds Jun 13 17:11:21 grail kernel: EXT3 FS 2.4-0.9.19, 19 August 2002 on
sd(8,1), internal journal
Jun 13 17:11:21 grail kernel: EXT3-fs: mounted filesystem with ordered data
mode.
Jun 13 17:13:51 grail kernel: invalidate: busy buffer
Jun 13 17:19:42 grail syslogd 1.4.1: restart.
Jun 13 17:19:42 grail syslog: syslogd startup succeeded
Jun 13 17:19:42 grail syslog: ^[[60G[
Jun 13 17:19:42 grail rc: Starting syslog:  failed
Jun 13 17:19:42 grail portmap: Starting portmapper:

[SYSTEM HANGS HERE]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Jun 13 16:51:30 grail kernel: kernel BUG at page_alloc.c:100!
Jun 13 16:51:30 grail kernel: invalid operand: 0000
Jun 13 16:51:30 grail kernel: CPU:    0
Jun 13 16:51:30 grail kernel: EIP:    0010:[<c013b0c2>]    Not tainted
Jun 13 16:51:30 grail kernel: EFLAGS: 00010282
Jun 13 16:51:30 grail kernel: eax: c1a847ac   ebx: c1a84760   ecx: f7fe6270
edx: c1a842cc
Jun 13 16:51:30 grail kernel: esi: 000000b2   edi: 00000000   ebp: 000000b2
esp: f7861e3c
Jun 13 16:51:30 grail kernel: ds: 0018   es: 0018   ss: 0018

Jun 13 16:51:29 grail ifup: grep: relocation error: grep: symbol , version
GLIBC_2.0 not defined in file libc.so.6 with link time reference
Jun 13 16:51:29 grail ifup: grep: relocation error: grep: symbol , version
GLIBC_2.0 not defined in file libc.so.6 with link time reference
Jun 13 16:51:29 grail network: Bringing up loopback interface:  succeeded
Jun 13 16:51:29 grail ifup: grep: relocation error: grep: symbol , version

GLIBC_2.0 not defined in file libc.so.6 with link time reference

Could you a test just for me? Take vanilla 2.4.21 and then
make oldconfig; make dep; time make bzImage That's basically what I want to know how long will take, since it's one of the most common time consuming tasks the thing will
have to handle.

Quoted 5 lines · Vojtech Pavlik

Could you a test just for me? Take vanilla 2.4.21 and then make oldconfig; make dep; time make bzImage
That's basically what I want to know how long will take, since it's one of the most common time consuming tasks the thing will have to handle.

Done! Here're the results:-

Desktop - Pentium III 1 G Hz 754 MB -> 10.x min.
Tablet PC - Crusoe TM5800 1 GHz 731 MB -> 17.x min.

From freshdiagnos benchmack, the TPC has about 2x faster RAM.
I use tmpfs for the whole process so disk speed didn't count. Both test run without X or any foreground process using 2.4.21-ac1 and RedHat kernel.

What do you think?
Shouldn't TM5800 with 4-wide VLIW engine and 64 registers, working on a single task, run as fast as a Pentium III? Why it take 70% longer for such small process (make+gcc+as)! There must be something wrong.

Done! Here're the results:-

Desktop - Pentium III 1 G Hz 754 MB -> 10.x min.
Tablet PC - Crusoe TM5800 1 GHz 731 MB -> 17.x min.

From freshdiagnos benchmack, the TPC has about 2x faster RAM.

Quoted 5 lines · Vojtech Pavlik

Could you a test just for me? Take vanilla 2.4.21 and then make oldconfig; make dep; time make bzImage
That's basically what I want to know how long will take, since it's one of the most common time consuming tasks the thing will have to handle.

Done! Here're the results:-

Desktop - Pentium III 1 G Hz 754 MB -> 10.x min.
Tablet PC - Crusoe TM5800 1 GHz 731 MB -> 17.x min.

From freshdiagnos benchmack, the TPC has about 2x faster RAM.
I use tmpfs for the whole process so disk speed didn't count. Both test run without X or any foreground process using 2.4.21-ac1 and RedHat kernel.

What do you think?
Shouldn't TM5800 with 4-wide VLIW engine and 64 registers, working on a single task, run as fast as a Pentium III? Why it take 70% longer for such small process (make+gcc+as)! There must be something wrong.

Quoted 5 lines · Vojtech Pavlik

Could you a test just for me? Take vanilla 2.4.21 and then make oldconfig; make dep; time make bzImage
That's basically what I want to know how long will take, since it's one of the most common time consuming tasks the thing will have to handle.

Done! Here're the results:-

Desktop - Pentium III 1 G Hz 754 MB -> 10.x min.
Tablet PC - Crusoe TM5800 1 GHz 731 MB -> 17.x min.

From freshdiagnos benchmack, the TPC has about 2x faster RAM.
I use tmpfs for the whole process so disk speed didn't count. Both test run without X or any foreground process using 2.4.21-ac1 and RedHat kernel.

Quoted 6 lines · Samphan Raruenrom

Desktop - Pentium III 1 G Hz 754 MB -> 10.x min.
Tablet PC - Crusoe TM5800 1 GHz 731 MB -> 17.x min.
From freshdiagnos benchmack, the TPC has about 2x faster RAM. I use tmpfs for the whole process so disk speed didn't count. Both test run without X or any foreground process using 2.4.21-ac1 and RedHat kernel.

Desktop - 1.1 GHz Athlon Tbird 512M RAM, using disk -> 3.7 min This is with gcc 2.95.2, which may give it an unfair advantage, though. Or is something else wrong here?

Desktop - 1.1 GHz Athlon Tbird 512M RAM, using disk -> 3.7 min

This is with gcc 2.95.2, which may give it an unfair advantage, though. Or is something else wrong here?

Quoted 5 lines · Vojtech Pavlik

Could you a test just for me? Take vanilla 2.4.21 and then make oldconfig; make dep; time make bzImage
That's basically what I want to know how long will take, since it's one of the most common time consuming tasks the thing will have to handle.

Done! Here're the results:-

Desktop - Pentium III 1 G Hz 754 MB -> 10.x min.
Tablet PC - Crusoe TM5800 1 GHz 731 MB -> 17.x min.

From freshdiagnos benchmack, the TPC has about 2x faster RAM.
I use tmpfs for the whole process so disk speed didn't count. Both test run without X or any foreground process using 2.4.21-ac1 and RedHat kernel.

What do you think?
Shouldn't TM5800 with 4-wide VLIW engine and 64 registers, working on a single task, run as fast as a Pentium III? Why it take 70% longer for such small process (make+gcc+as)! There must be something wrong.

Desktop - Pentium III 1 G Hz 754 MB -> 10.x min.
Tablet PC - Crusoe TM5800 1 GHz 731 MB -> 17.x min.

From freshdiagnos benchmack, the TPC has about 2x faster RAM.

Shouldn't TM5800 with 4-wide VLIW engine and 64 registers, working on a single task, run as fast as a Pentium III?

Quoted 2 lines · Samphan Raruenrom

Desktop - Pentium III 1 G Hz 754 MB -> 10.x min.
Tablet PC - Crusoe TM5800 1 GHz 731 MB -> 17.x min.

but i'm really guessing you're causing excessive disk i/o by having a small memory system use a huge tmpfs... get rid of the tmpfs and

Quoted 3 lines

The time used to compile 2.4.21 kernel off the same .config
Desktop - Pentium III 1 G Hz 756 MB -> 10.x min.
Tablet PC - Crusoe TM5800 1 GHz 733 MB -> 17.x min.

how much real memory are in these boxes? the above don't look like any real memory sizes i'm aware of

So the result are real, no disk speed related. What do you think?

.config please

Did you compile this kernel yourself?
I think so, and I think there's something wrong with your compiler.

And here's something wrong with your glibc.........

To make sure that I have a clean environment I've reinstalled RedHat 9 workstation. This is supposed to give a complete set of tools for software development. It did not install kernel sources though, so I've installed that RPM. It installed sources for 2.4.20.

Then I've downloaded kernel 2.4.21 from vger. I placed the decompressed source in /home/linux2.4.21/. I based my configuration on RedHat's config for AMD SMP (included in kernel source RPM) and on linux-2.4.21/arch/i386/defconfig. Recompiled the kernel.

On first attempt to boot from that new kernel the machine started acting up and eventually froze. I've tried rebooting from RedHat installed non-SMP kernel a couple of times and kept getting stuck in various places during the boot.

I started suspecting the RAM. I replaced the Corsair PC2100 1GB module with a 512M module. The machine started working fine under RedHat kernel. Switched to my SMP kernel - it ran fine except for one time when it simply logged me out while I was in the middle of typing a bash command.

I've logged back in, recompiled Promise driver while running in SMP. This was the first time I was able to do that in SMP. I've loaded the driver, left machine running overnight. Came in this morning - machine was still up. I attempted to copy some files to Promise Raid volume. The machine locked up in the middle of transfer. I tried to reboot in SMP and it failed each time. I rebooted with RedHat's 2.4.20-8smp kernel but with nosmp boot parameter and it came up ok. Rebooted the same kernel without the nosmp parameter and it did this:

Checking root filesystem
/:clean, 24049/131328 files, 45328/262144 blocks
Remounting root filesystem in read-write mode [OK]
Activation swap partitions: [OK]
/etc/rc.d/rc.sysinit: line 349: [: command not found //the above message repeated for 12 more lines, not subsequent //though, e.g. 350, 356, 360.

mounting local filesystems: [OK]
Enabling local filesystem quotas: [OK]
malloc: make_cmd.c: 96: assertion blotched
malloc: block on free list clobbered
Stopping myself...

// FROZEN, rebooted from RH 2.4.20-8smp
checking for new hardware/etc/rc3.d/S05kudzu: line 93 211 segmentation
fault /usr/sbin/kudzu $KUDZU_ARGS -t 30 [FAILED]
Updating /etc/fstab [OK]
Setting network parameters [OK]
Bringing up loopback interface
//FROZEN, rebooted from RH 2.4.20-8smp with nosmp parameter - booted fine.

In my .config I tried to strip as much as possible, although I left some things in that I was not sure about.

Brian:

Quoted 1 line

.config please

See below

Bart:

Quoted 2 lines

Did you compile this kernel yourself?
I think so, and I think there's something wrong with your compiler.

Yes I did. To avoid possibility of poorly configured compiler, I've reinstalled a clean Red Hat 9 in workstation flavor. This is supposed to install all tools necessary for software development. As long as RedHat's installer didn't mess anything up, my compiler should be fine now, right?

Quoted 1 line

And here's something wrong with your glibc.........

Whatever glibc was used was installed from RH's distro. How can I make sure that I am using a good copy of it?

Any suggestions on what to try next?

Artur

CONFIG_X86=y
CONFIG_UID16=y
CONFIG_EXPERIMENTAL=y
CONFIG_MODULES=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y
CONFIG_MK7=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_HAS_TSC=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_USE_3DNOW=y
CONFIG_X86_PGE=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_F00F_WORKS_OK=y
CONFIG_X86_MCE=y
CONFIG_MICROCODE=m
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m
CONFIG_NOHIGHMEM=y
CONFIG_MTRR=y
CONFIG_SMP=y
CONFIG_X86_TSC=y
CONFIG_HAVE_DEC_LOCK=y
CONFIG_NET=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_PCI=y
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_ISA=y
CONFIG_PCI_NAMES=y
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
CONFIG_BINFMT_AOUT=m
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=m
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_PARPORT_PC_CML1=m
CONFIG_PARPORT_SERIAL=m
CONFIG_PARPORT_PC_FIFO=y
CONFIG_PARPORT_1284=y
CONFIG_PNP=y
CONFIG_ISAPNP=y
CONFIG_BLK_DEV_FD=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
CONFIG_MD=y
CONFIG_BLK_DEV_MD=m
CONFIG_MD_RAID0=m
CONFIG_MD_RAID1=m
CONFIG_MD_RAID5=m
CONFIG_BLK_DEV_LVM=m
CONFIG_PACKET=m
CONFIG_PACKET_MMAP=y
CONFIG_NETLINK_DEV=m
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_VLAN_8021Q=m
CONFIG_ATALK=m
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=y
CONFIG_BLK_DEV_IDETAPE=m
CONFIG_BLK_DEV_IDESCSI=m
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_BLK_DEV_GENERIC=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_AUTO=y
CONFIG_BLK_DEV_IDE_MODES=y
CONFIG_BLK_DEV_ATARAID=m
CONFIG_BLK_DEV_ATARAID_PDC=m
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_SD_EXTRA_DEVS=16
CONFIG_CHR_DEV_ST=m
CONFIG_CHR_DEV_OSST=m
CONFIG_BLK_DEV_SR=m
CONFIG_SR_EXTRA_DEVS=2
CONFIG_CHR_DEV_SG=m
CONFIG_SCSI_DEBUG_QUEUES=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_BLK_DEV_3W_XXXX_RAID=m
CONFIG_I2O=m
CONFIG_I2O_PCI=m
CONFIG_I2O_BLOCK=m
CONFIG_I2O_LAN=m
CONFIG_I2O_SCSI=m
CONFIG_I2O_PROC=m
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
CONFIG_NET_ETHERNET=y
CONFIG_NET_VENDOR_3COM=y
CONFIG_VORTEX=m
CONFIG_NS83820=m
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_SERIAL=y
CONFIG_SERIAL_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256
CONFIG_PRINTER=m
CONFIG_I2C=m
CONFIG_I2C_CHARDEV=m
CONFIG_I2C_PROC=m
CONFIG_MOUSE=m
CONFIG_PSMOUSE=y
CONFIG_IPMI_HANDLER=m
CONFIG_IPMI_DEVICE_INTERFACE=m
CONFIG_IPMI_KCS=m
CONFIG_IPMI_WATCHDOG=m
CONFIG_AMD_RNG=m
CONFIG_RTC=m
CONFIG_AGP=m
CONFIG_AGP_AMD=y
CONFIG_DRM=y
CONFIG_DRM_NEW=y
CONFIG_DRM_R128=m
CONFIG_QUOTA=y
CONFIG_AUTOFS4_FS=m
CONFIG_REISERFS_FS=m
CONFIG_HFS_FS=m
CONFIG_EXT3_FS=y
CONFIG_JBD=y
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_TMPFS=y
CONFIG_RAMFS=y
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
CONFIG_JFS_FS=m
CONFIG_NTFS_FS=m
CONFIG_PROC_FS=y
CONFIG_DEVPTS_FS=y
CONFIG_EXT2_FS=y
CONFIG_UDF_FS=m
CONFIG_NFS_FS=m
CONFIG_NFSD=m
CONFIG_SUNRPC=m
CONFIG_LOCKD=m
CONFIG_SMB_FS=m
CONFIG_PARTITION_ADVANCED=y
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
CONFIG_BSD_DISKLABEL=y
CONFIG_LDM_PARTITION=y
CONFIG_SMB_NLS=y
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_VGA_CONSOLE=y
CONFIG_VIDEO_SELECT=y
CONFIG_FB=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_VIDEO_SELECT=y
CONFIG_FB_ATY128=m
CONFIG_FBCON_CFB8=m
CONFIG_FBCON_CFB16=m
CONFIG_FBCON_CFB24=m
CONFIG_FBCON_CFB32=m
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
CONFIG_USB=m
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_UHCI_ALT=m
CONFIG_USB_OHCI=m
CONFIG_USB_STORAGE=m
CONFIG_USB_STORAGE_DPCM=y
CONFIG_USB_STORAGE_SDDR09=y
CONFIG_USB_STORAGE_SDDR55=y
CONFIG_USB_STORAGE_JUMPSHOT=y
CONFIG_USB_PRINTER=m

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

To make sure that I have a clean environment I've reinstalled RedHat 9 workstation. This is supposed to give a complete set of tools for software development. It did not install kernel sources though, so I've installed that RPM. It installed sources for 2.4.20.

Then I've downloaded kernel 2.4.21 from vger. I placed the decompressed source in /home/linux2.4.21/. I based my configuration on RedHat's config for AMD SMP (included in kernel source RPM) and on linux-2.4.21/arch/i386/defconfig. Recompiled the kernel.

On first attempt to boot from that new kernel the machine started acting up and eventually froze. I've tried rebooting from RedHat installed non-SMP kernel a couple of times and kept getting stuck in various places during the boot.

I started suspecting the RAM. I replaced the Corsair PC2100 1GB module with a 512M module. The machine started working fine under RedHat kernel. Switched to my SMP kernel - it ran fine except for one time when it simply logged me out while I was in the middle of typing a bash command.

I've logged back in, recompiled Promise driver while running in SMP. This was the first time I was able to do that in SMP. I've loaded the driver, left machine running overnight. Came in this morning - machine was still up. I attempted to copy some files to Promise Raid volume. The machine locked up in the middle of transfer. I tried to reboot in SMP and it failed each time. I rebooted with RedHat's 2.4.20-8smp kernel but with nosmp boot parameter and it came up ok. Rebooted the same kernel without the nosmp parameter and it did this:

Checking root filesystem
/:clean, 24049/131328 files, 45328/262144 blocks
Remounting root filesystem in read-write mode [OK]
Activation swap partitions: [OK]
/etc/rc.d/rc.sysinit: line 349: [: command not found //the above message repeated for 12 more lines, not subsequent //though, e.g. 350, 356, 360.

mounting local filesystems: [OK]
Enabling local filesystem quotas: [OK]
malloc: make_cmd.c: 96: assertion blotched
malloc: block on free list clobbered
Stopping myself...

// FROZEN, rebooted from RH 2.4.20-8smp
checking for new hardware/etc/rc3.d/S05kudzu: line 93 211 segmentation
fault /usr/sbin/kudzu $KUDZU_ARGS -t 30 [FAILED]
Updating /etc/fstab [OK]
Setting network parameters [OK]
Bringing up loopback interface
//FROZEN, rebooted from RH 2.4.20-8smp with nosmp parameter - booted fine.

In my .config I tried to strip as much as possible, although I left some things in that I was not sure about.

Brian:

Quoted 1 line

.config please

See below

Bart:

Quoted 2 lines

Did you compile this kernel yourself?
I think so, and I think there's something wrong with your compiler.

Yes I did. To avoid possibility of poorly configured compiler, I've reinstalled a clean Red Hat 9 in workstation flavor. This is supposed to install all tools necessary for software development. As long as RedHat's installer didn't mess anything up, my compiler should be fine now, right?

Quoted 1 line

And here's something wrong with your glibc.........

Whatever glibc was used was installed from RH's distro. How can I make sure that I am using a good copy of it?

Any suggestions on what to try next?

Artur

CONFIG_X86=y
CONFIG_UID16=y
CONFIG_EXPERIMENTAL=y
CONFIG_MODULES=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y
CONFIG_MK7=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_HAS_TSC=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_USE_3DNOW=y
CONFIG_X86_PGE=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_F00F_WORKS_OK=y
CONFIG_X86_MCE=y
CONFIG_MICROCODE=m
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m
CONFIG_NOHIGHMEM=y
CONFIG_MTRR=y
CONFIG_SMP=y
CONFIG_X86_TSC=y
CONFIG_HAVE_DEC_LOCK=y
CONFIG_NET=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_PCI=y
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_ISA=y
CONFIG_PCI_NAMES=y
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
CONFIG_BINFMT_AOUT=m
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=m
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_PARPORT_PC_CML1=m
CONFIG_PARPORT_SERIAL=m
CONFIG_PARPORT_PC_FIFO=y
CONFIG_PARPORT_1284=y
CONFIG_PNP=y
CONFIG_ISAPNP=y
CONFIG_BLK_DEV_FD=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
CONFIG_MD=y
CONFIG_BLK_DEV_MD=m
CONFIG_MD_RAID0=m
CONFIG_MD_RAID1=m
CONFIG_MD_RAID5=m
CONFIG_BLK_DEV_LVM=m
CONFIG_PACKET=m
CONFIG_PACKET_MMAP=y
CONFIG_NETLINK_DEV=m
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_VLAN_8021Q=m
CONFIG_ATALK=m
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=y
CONFIG_BLK_DEV_IDETAPE=m
CONFIG_BLK_DEV_IDESCSI=m
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_BLK_DEV_GENERIC=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_AUTO=y
CONFIG_BLK_DEV_IDE_MODES=y
CONFIG_BLK_DEV_ATARAID=m
CONFIG_BLK_DEV_ATARAID_PDC=m
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_SD_EXTRA_DEVS=16
CONFIG_CHR_DEV_ST=m
CONFIG_CHR_DEV_OSST=m
CONFIG_BLK_DEV_SR=m
CONFIG_SR_EXTRA_DEVS=2
CONFIG_CHR_DEV_SG=m
CONFIG_SCSI_DEBUG_QUEUES=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_BLK_DEV_3W_XXXX_RAID=m
CONFIG_I2O=m
CONFIG_I2O_PCI=m
CONFIG_I2O_BLOCK=m
CONFIG_I2O_LAN=m
CONFIG_I2O_SCSI=m
CONFIG_I2O_PROC=m
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
CONFIG_NET_ETHERNET=y
CONFIG_NET_VENDOR_3COM=y
CONFIG_VORTEX=m
CONFIG_NS83820=m
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_SERIAL=y
CONFIG_SERIAL_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256
CONFIG_PRINTER=m
CONFIG_I2C=m
CONFIG_I2C_CHARDEV=m
CONFIG_I2C_PROC=m
CONFIG_MOUSE=m
CONFIG_PSMOUSE=y
CONFIG_IPMI_HANDLER=m
CONFIG_IPMI_DEVICE_INTERFACE=m
CONFIG_IPMI_KCS=m
CONFIG_IPMI_WATCHDOG=m
CONFIG_AMD_RNG=m
CONFIG_RTC=m
CONFIG_AGP=m
CONFIG_AGP_AMD=y
CONFIG_DRM=y
CONFIG_DRM_NEW=y
CONFIG_DRM_R128=m
CONFIG_QUOTA=y
CONFIG_AUTOFS4_FS=m
CONFIG_REISERFS_FS=m
CONFIG_HFS_FS=m
CONFIG_EXT3_FS=y
CONFIG_JBD=y
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_TMPFS=y
CONFIG_RAMFS=y
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
CONFIG_JFS_FS=m
CONFIG_NTFS_FS=m
CONFIG_PROC_FS=y
CONFIG_DEVPTS_FS=y
CONFIG_EXT2_FS=y
CONFIG_UDF_FS=m
CONFIG_NFS_FS=m
CONFIG_NFSD=m
CONFIG_SUNRPC=m
CONFIG_LOCKD=m
CONFIG_SMB_FS=m
CONFIG_PARTITION_ADVANCED=y
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
CONFIG_BSD_DISKLABEL=y
CONFIG_LDM_PARTITION=y
CONFIG_SMB_NLS=y
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_VGA_CONSOLE=y
CONFIG_VIDEO_SELECT=y
CONFIG_FB=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_VIDEO_SELECT=y
CONFIG_FB_ATY128=m
CONFIG_FBCON_CFB8=m
CONFIG_FBCON_CFB16=m
CONFIG_FBCON_CFB24=m
CONFIG_FBCON_CFB32=m
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
CONFIG_USB=m
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_UHCI_ALT=m
CONFIG_USB_OHCI=m
CONFIG_USB_STORAGE=m
CONFIG_USB_STORAGE_DPCM=y
CONFIG_USB_STORAGE_SDDR09=y
CONFIG_USB_STORAGE_SDDR55=y
CONFIG_USB_STORAGE_JUMPSHOT=y
CONFIG_USB_PRINTER=m

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

I shipped out two machines last week using the Tyan 2466, 2.4.21 compiled for SMP on Debian Woody. My kernel includes support for promise, hpt, and 3ware ide raid cards. I shipped one unit with the 3ware 7000-2 and 2 WD-2000-JB

Forgot to mention -
I tried this board with PC2100 bought from the local computer store (don't know the name) and I got all kinds of weird problems like boot failure, file system corruption, everything except a memory error. I then tried a 512 mb stick of kingston pc2100 and it completely solved the problems.

Quoted 28 lines

To make sure that I have a clean environment I've reinstalled RedHat 9 workstation. This is supposed to give a complete set of tools for software development. It did not install kernel sources though, so I've installed that RPM. It installed sources for 2.4.20.

Then I've downloaded kernel 2.4.21 from vger. I placed the decompressed source in /home/linux2.4.21/. I based my configuration on RedHat's config for AMD SMP (included in kernel source RPM) and on linux-2.4.21/arch/i386/defconfig. Recompiled the kernel.

On first attempt to boot from that new kernel the machine started acting up and eventually froze. I've tried rebooting from RedHat installed non-SMP kernel a couple of times and kept getting stuck in various places during the boot.

I started suspecting the RAM. I replaced the Corsair PC2100 1GB module with a 512M module. The machine started working fine under RedHat kernel. Switched to my SMP kernel - it ran fine except for one time when it simply logged me out while I was in the middle of typing a bash command.

I've logged back in, recompiled Promise driver while running in SMP. This was the first time I was able to do that in SMP. I've loaded the driver, left machine running overnight. Came in this morning - machine was still up. I attempted to copy some files to Promise Raid volume. The machine locked up in the middle of transfer. I tried to reboot in SMP and it failed each time. I rebooted with RedHat's 2.4.20-8smp kernel but with nosmp boot parameter and it came up ok. Rebooted the same kernel without the nosmp parameter and it did this...

Yes, for SMP mode you absolutely need to use 'registered' RAM. Normal PC2100 ram will work OK with one processor but quickly fails with two (I had the same problems). Apparently, DDR RAM uses one clock edge to transfer in one direction and the opposite edge to transfer back again so the registers do synchronisation between one processor writing to the same location that the other one reads from. That's how it was explained to me anyway.

Quoted 9 lines · Edward Tandi

Yes, for SMP mode you absolutely need to use 'registered' RAM. Normal PC2100 ram will work OK with one processor but quickly fails with two (I had the same problems). Apparently, DDR RAM uses one clock edge to transfer in one direction and the opposite edge to transfer back again so the registers do synchronisation between one processor writing to the same location that the other one reads from. That's how it was explained to me anyway.

DDR memory works very much like single data rate, except that data is transferred (in whichever direction it's going) on both edges of the clock, thus doubling the transfer rate. The memory does not switch between reading and writing as you describe it.

I believe registering is for reliability. Data is transferred one clock cycle later but reduces signal loading.

Quoted 4 lines · Timothy Miller

DDR memory works very much like single data rate, except that data is transferred (in whichever direction it's going) on both edges of the clock, thus doubling the transfer rate. The memory does not switch between reading and writing as you describe it.

I believe registering is for reliability. Data is transferred one clock cycle later but reduces signal loading.

Thanks for the clarification. I do not profess to be an expert in the technology. Two writes or a read+write per clock cycle is close enough for the purpose of the discussion.

The point I was trying to make is that the registers are there to deal with an SMP race condition of some sort. Athlon MP motherboards fitted with two processors will not work properly without 'registered' RAM. I have hard experience of this and it this experience I am sharing with someone who is seeing the same symptoms.

It is my understanding that the registered memory requirement has nothing to do with SMP but instead with the amount of memory you have. The more memory chips you have, the greater the signal loading on the memory bus. More input drivers means more capacitance which means you need your output drivers to put out data sooner (relative to the clock edge, so registered delays by one clock) and stronger (greater drive strength).

In an SMP system (besides NUMA), multiple processors will talk to the same memory through a shared memory controller (like in a Northbridge), so although there are multiple processors, there is still only one memory bus. Pulling off one CPU isn't going to change that situation.

The point I was trying to make is that the registers are there to deal with an SMP race condition of some sort. Athlon MP motherboards fitted with two processors will not work properly without 'registered' RAM. I have hard experience of this and it this experience I am sharing with someone who is seeing the same symptoms.

Ed-T.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Quoted 15 lines · Edward Tandi

Quoted 8 lines · Timothy Miller

DDR memory works very much like single data rate, except that data is transferred (in whichever direction it's going) on both edges of the clock, thus doubling the transfer rate. The memory does not switch between reading and writing as you describe it.

I believe registering is for reliability. Data is transferred one clock cycle later but reduces signal loading.

Thanks for the clarification. I do not profess to be an expert in the technology. Two writes or a read+write per clock cycle is close enough for the purpose of the discussion.

Quoted 5 lines

The point I was trying to make is that the registers are there to deal with an SMP race condition of some sort. Athlon MP motherboards fitted with two processors will not work properly without 'registered' RAM. I have hard experience of this and it this experience I am sharing with someone who is seeing the same symptoms.

It is my understanding that the registered memory requirement has nothing to do with SMP but instead with the amount of memory you have.

The more memory chips you have, the greater the signal loading on the memory bus. More input drivers means more capacitance which means you need your output drivers to put out data sooner (relative to the clock edge, so registered delays by one clock) and stronger (greater drive strength).

In an SMP system (besides NUMA), multiple processors will talk to the same memory through a shared memory controller (like in a Northbridge), so although there are multiple processors, there is still only one memory bus. Pulling off one CPU isn't going to change that situation.

Quoted 8 lines · Timothy Miller

It is my understanding that the registered memory requirement has nothing to do with SMP but instead with the amount of memory you have. The more memory chips you have, the greater the signal loading on the memory bus. More input drivers means more capacitance which means you need your output drivers to put out data sooner (relative to the clock edge, so registered delays by one clock) and stronger (greater drive strength).

Quoted 5 lines

In an SMP system (besides NUMA), multiple processors will talk to the same memory through a shared memory controller (like in a Northbridge), so although there are multiple processors, there is still only one memory bus. Pulling off one CPU isn't going to change that situation.

Here's a URL:

http://www.simmtester.com/PAGE/memory/memfaq.asp?cat=6&subcat=&tableView=detail&faqId=15

Quoted 5 lines · Vojtech Pavlik

Could you a test just for me? Take vanilla 2.4.21 and then make oldconfig; make dep; time make bzImage
That's basically what I want to know how long will take, since it's one of the most common time consuming tasks the thing will have to handle.

Done! Here're the results:-

Desktop - Pentium III 1 G Hz 754 MB -> 10.x min.
Tablet PC - Crusoe TM5800 1 GHz 731 MB -> 17.x min.

From freshdiagnos benchmack, the TPC has about 2x faster RAM.
I use tmpfs for the whole process so disk speed didn't count. Both test run without X or any foreground process using 2.4.21-ac1 and RedHat kernel.

I have written a script to try to give a consistent compile benchmark; however, one still needs to make sure that DMA is turned on (hdparm -d /dev/hda); obviously, the compiler etc should not be on NFS.

Quoted 9 lines · Timothy Miller

Quoted 7 lines · Edward Tandi

Yes, for SMP mode you absolutely need to use 'registered' RAM. Normal PC2100 ram will work OK with one processor but quickly fails with two (I had the same problems). Apparently, DDR RAM uses one clock edge to transfer in one direction and the opposite edge to transfer back again so the registers do synchronisation between one processor writing to the same location that the other one reads from. That's how it was explained to me anyway.

Quoted 7 lines

DDR memory works very much like single data rate, except that data is transferred (in whichever direction it's going) on both edges of the clock, thus doubling the transfer rate. The memory does not switch between reading and writing as you describe it.

I believe registering is for reliability. Data is transferred one clock cycle later but reduces signal loading.

Thanks for the clarification. I do not profess to be an expert in the technology. Two writes or a read+write per clock cycle is close enough for the purpose of the discussion.

The point I was trying to make is that the registers are there to deal with an SMP race condition of some sort. Athlon MP motherboards fitted with two processors will not work properly without 'registered' RAM. I have hard experience of this and it this experience I am sharing with someone who is seeing the same symptoms.

Ed-T.

I am working on a Tyan 2466 SMP/Athlon server now and am getting tons of reiserf errors (see attached /var/log/syslog) that claim an i/o error, yet the log does not show any errors from the driver (should it?). Unfortunately, Reiser does not indicate which drive the error is produced from. My configuration is:
Tyan 2466 SMP 2 x AMD2400-MP
512 MB PC2100 DDR-> not registered!
Debian woody
2.4.21 reiser
system drive (os, swap) wd800-bb (80 gb ide)
data drives: 3ware 7200, 2 x wd2000 (200 gb ide) RAID-0

Is not this is one of those heavy-PCI loaded boxes that ocasionally corrupt data when PCI is overloaded?

The log you quoted shows that suddenly tree nodes have incorrect content (and the i/o error is because reiserfs does not know what to do with such nodes). (and we hope to push the patch that will print device where error have occured soon).

Bye,
Oleg

Quoted 23 lines · Timothy Miller

Quoted 20 lines · Edward Tandi

Quoted 8 lines · Timothy Miller

DDR memory works very much like single data rate, except that data is transferred (in whichever direction it's going) on both edges of the clock, thus doubling the transfer rate. The memory does not switch between reading and writing as you describe it.

I believe registering is for reliability. Data is transferred one clock cycle later but reduces signal loading.

Thanks for the clarification. I do not profess to be an expert in the technology. Two writes or a read+write per clock cycle is close enough for the purpose of the discussion.

The point I was trying to make is that the registers are there to deal with an SMP race condition of some sort. Athlon MP motherboards fitted with two processors will not work properly without 'registered' RAM. I have hard experience of this and it this experience I am sharing with someone who is seeing the same symptoms.

Quoted 2 lines

It is my understanding that the registered memory requirement has nothing to do with SMP but instead with the amount of memory you have.

Except if you go to the beginning of this thread, you will see that the machine appears to be running fine in Uniprocessor mode. This concurs with my experience. The only difference is that Artur switched the kernel whereas I pulled a CPU (and kept the SMP kernel).

Quoted 5 lines

The more memory chips you have, the greater the signal loading on the memory bus. More input drivers means more capacitance which means you need your output drivers to put out data sooner (relative to the clock edge, so registered delays by one clock) and stronger (greater drive strength).

I only have 2 x 256MB in the box.

Quoted 4 lines

In an SMP system (besides NUMA), multiple processors will talk to the same memory through a shared memory controller (like in a Northbridge), so although there are multiple processors, there is still only one memory bus. Pulling off one CPU isn't going to change that situation.

It appears to do the trick in practise though. How strange.

Ed-T.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Quoted 6 lines

Quoted 5 lines · Vojtech Pavlik

Could you a test just for me? Take vanilla 2.4.21 and then make oldconfig; make dep; time make bzImage
That's basically what I want to know how long will take, since it's one of the most common time consuming tasks the thing will have to handle.

Done! Here're the results:-

Quoted 6 lines

Desktop - Pentium III 1 G Hz 754 MB -> 10.x min.
Tablet PC - Crusoe TM5800 1 GHz 731 MB -> 17.x min.
From freshdiagnos benchmack, the TPC has about 2x faster RAM.
I use tmpfs for the whole process so disk speed didn't count. Both test run without X or any foreground process using 2.4.21-ac1 and RedHat kernel.

For what it's worth, we have been completely unable to reproduce these kinds of results at Transmeta; our results are in fact very consistent with the numbers reported by some people for the Sharp MM-10 "Kitty" which is also a 1 GHz TM5800; all of them have been in the 10 minute ballpark.

Is not this is one of those heavy-PCI loaded boxes that ocasionally corrupt
data when PCI is overloaded? The log you quoted shows that suddenly tree nodes have incorrect content (and the i/o error is because reiserfs does not know what to do with such nodes). (and we hope to push the patch that will print device where error have occured
soon).

The PCI spec doesn't allow more than four slots per bus. Some boards try to put on 5 or 6 slots anyhow, violating the spec. It's no wonder there are so many problems with those boards.

You can often get them to work anyhow, but it involves swapping cards around in slots until you find an arrangement that works, but it's still unreliable.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Quoted 6 lines · Oleg Drokin

Is not this is one of those heavy-PCI loaded boxes that ocasionally corrupt data when PCI is overloaded?
The log you quoted shows that suddenly tree nodes have incorrect content (and the i/o error is because reiserfs does not know what to do with such nodes). (and we hope to push the patch that will print device where error have occured soon).

The PCI spec doesn't allow more than four slots per bus. Some boards try to put on 5 or 6 slots anyhow, violating the spec. It's no wonder there are so many problems with those boards.

You can often get them to work anyhow, but it involves swapping cards around in slots until you find an arrangement that works, but it's still unreliable.

I shipped out two machines last week using the Tyan 2466, 2.4.21 compiled for SMP on Debian Woody. My kernel includes support for promise, hpt, and 3ware ide raid cards. I shipped one unit with the 3ware 7000-2 and 2 WD-2000-JB drives and 4 x bt878 frame-grabbers, and the 2nd with 3ware 8500 (8-channel) and 8 x WD1200-JB drives. Both machines went through their 48-hour heavy-load burn-in period without incident.

If the exact kernel tree and config would help, you can get it at:

wget http://www.briggsmedia.com/downloads/kernel-2.4.21.tz

Forgot to mention -
I tried this board with PC2100 bought from the local computer store (don't know the name) and I got all kinds of weird problems like boot failure, file system corruption, everything except a memory error. I then tried a 512 mb stick of kingston pc2100 and it completely solved the problems.

Joe,
Thanks for your suggestions. I've tried Kingston registered DIMMs and got the same result (crashes in SMP, runs ok with "nosmp" boot parameter)

I am currently trying to extract your kernel from .deb package, but am running into RPM hell of circular dependency while trying to install alien to access .deb archive.

Any chance I could bother you to put a tgz archive with kernel on your dowlnoads site?

I've also downloaded source archive from your site, but I am not sure if it is for the AMD mobo. The file linux-2.4.21.tz seems to be configured for Intel chips, judging from .config file.

I'd rather borrow your kernel source than use your ready-made kernel. I still have to compile Promise SX6000 drivers for it.

Thanks again

Artur

Quoted 18 lines

I shipped out two machines last week using the Tyan 2466, 2.4.21 compiled for SMP on Debian Woody. My kernel includes support for promise, hpt, and 3ware ide raid cards. I shipped one unit with the 3ware 7000-2 and 2 WD-2000-JB drives and 4 x bt878 frame-grabbers, and the 2nd with 3ware 8500 (8-channel) and 8 x WD1200-JB drives. Both machines went through their 48-hour heavy-load burn-in period without incident.

If the exact kernel tree and config would help, you can get it at:

wget http://www.briggsmedia.com/downloads/kernel-2.4.21.tz

Forgot to mention -
I tried this board with PC2100 bought from the local computer store (don't know the name) and I got all kinds of weird problems like boot failure, file system corruption, everything except a memory error. I then tried a 512 mb stick of kingston pc2100 and it completely solved the problems.

Hello,

I'm coming into this conversation a bit late, so I might be missing something and appologize if I am. But I have the same board and experienced some intersting weirdness with PC2100 NON ECC chips on this board as well. I was using High performance ram from Mushkin at the time. Now here's the interesting part, according to some small print in the manual, non ecc ram works up to 1.5Gb. Knowing this, I bought 1Gb of it, 2 512MB sticks. I put them both in, and the board only sees 512Mb. So I talk to Mushkin about it, apparently they've done some testing with this board. Non ECC memory is EXTREMELY flakey in this board. So flakey that Tyan, unofficially mind you, recommened to them that they not suggest to their customers to put non ecc memory in this board. So I got 1Gb of ECC Registered memory, and have yet to have a problem with it.

On 22 Jul 2003 00:02:39 -0400

Quoted 15 lines · Jason

Hello,

I'm coming into this conversation a bit late, so I might be missing something and appologize if I am. But I have the same board and experienced some intersting weirdness with PC2100 NON ECC chips on this board as well. I was using High performance ram from Mushkin at the time. Now here's the interesting part, according to some small print in the manual, non ecc ram works up to 1.5Gb. Knowing this, I bought 1Gb of it, 2 512MB sticks. I put them both in, and the board only sees 512Mb. So I talk to Mushkin about it, apparently they've done some testing with this board. Non ECC memory is EXTREMELY flakey in this board. So flakey that Tyan, unofficially mind you, recommened to them that they not suggest to their customers to put non ecc memory in this board. So I got 1Gb of ECC Registered memory, and have yet to have a problem with it.

Actually, your 2 dimm problem could have (probably) been solved by rearranging your dimms. I have the 2462ung (thunder k7) and the only way I could get 512 megs (give me a break I'm a porr college student) was to put one in slot 1 and one in slot 3 (numbering starting at 0).

Pat Erley--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/