* Crusoe's persistent translation on linux? @ 2003-06-19 16:37 Samphan Raruenrom 2003-06-19 18:03 ` Vojtech Pavlik 0 siblings, 1 reply; 52+ messages in thread From: Samphan Raruenrom @ 2003-06-19 16:37 UTC (permalink / raw) To: linux-kernel; +Cc: Samphan Raruenrom 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? Regards, Samphan Rareunrom, National Electronics and Computer Technology Center, Thailand. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Crusoe's persistent translation on linux? 2003-06-19 16:37 Crusoe's persistent translation on linux? Samphan Raruenrom @ 2003-06-19 18:03 ` Vojtech Pavlik 2003-06-19 19:51 ` Samphan Raruenrom 0 siblings, 1 reply; 52+ messages in thread From: Vojtech Pavlik @ 2003-06-19 18:03 UTC (permalink / raw) To: Samphan Raruenrom; +Cc: linux-kernel On Thu, Jun 19, 2003 at 11:37:33PM +0700, Samphan Raruenrom wrote: > 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?). 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? > 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? -- Vojtech Pavlik SuSE Labs, SuSE CR ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Crusoe's persistent translation on linux? 2003-06-19 18:03 ` Vojtech Pavlik @ 2003-06-19 19:51 ` Samphan Raruenrom 2003-06-20 0:02 ` Nuno Silva [not found] ` <20030619221126.B3287@ucw.cz> 0 siblings, 2 replies; 52+ messages in thread From: Samphan Raruenrom @ 2003-06-19 19:51 UTC (permalink / raw) To: Vojtech Pavlik; +Cc: linux-kernel Vojtech Pavlik wrote: >>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? 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? ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Crusoe's persistent translation on linux? 2003-06-19 19:51 ` Samphan Raruenrom @ 2003-06-20 0:02 ` Nuno Silva 2003-06-20 0:16 ` Linus Torvalds [not found] ` <20030619221126.B3287@ucw.cz> 1 sibling, 1 reply; 52+ messages in thread From: Nuno Silva @ 2003-06-20 0:02 UTC (permalink / raw) To: Samphan Raruenrom; +Cc: Vojtech Pavlik, linux-kernel, Linus Torvalds Hi! Samphan Raruenrom wrote: > Vojtech Pavlik wrote: > >>> 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? > > > 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? > 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? After googling a bit i went to http://216.239.57.100/search?q=cache:GCP2Ecz931UJ:www.icsi.berkeley.edu/~fleiner/research.html+crusoe+linux+native+port&hl=en&ie=UTF-8 ...But there isn't many more info. Is there any advantage? Sorry for the OT... :) Regards, Nuno Silva > 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? > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Crusoe's persistent translation on linux? 2003-06-20 0:02 ` Nuno Silva @ 2003-06-20 0:16 ` Linus Torvalds 2003-06-20 2:08 ` Nuno Silva ` (2 more replies) 0 siblings, 3 replies; 52+ messages in thread From: Linus Torvalds @ 2003-06-20 0:16 UTC (permalink / raw) To: Nuno Silva; +Cc: Samphan Raruenrom, Vojtech Pavlik, linux-kernel On Fri, 20 Jun 2003, Nuno Silva wrote: > > 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. > 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 ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Crusoe's persistent translation on linux? 2003-06-20 0:16 ` Linus Torvalds @ 2003-06-20 2:08 ` Nuno Silva 2003-06-20 9:08 ` Xavier Bestel 2003-06-20 12:05 ` Crusoe's persistent translation on linux? Samphan Raruenrom 2 siblings, 0 replies; 52+ messages in thread From: Nuno Silva @ 2003-06-20 2:08 UTC (permalink / raw) To: Linus Torvalds; +Cc: Samphan Raruenrom, Vojtech Pavlik, linux-kernel Hi! Linus Torvalds wrote: > On Fri, 20 Jun 2003, Nuno Silva wrote: > >>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. > > >>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. Authoritative answer received! :) Thanks, Nuno Silva > > 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 > > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Crusoe's persistent translation on linux? 2003-06-20 0:16 ` Linus Torvalds 2003-06-20 2:08 ` Nuno Silva @ 2003-06-20 9:08 ` Xavier Bestel 2003-06-20 9:33 ` Nick Piggin ` (2 more replies) 2003-06-20 12:05 ` Crusoe's persistent translation on linux? Samphan Raruenrom 2 siblings, 3 replies; 52+ messages in thread From: Xavier Bestel @ 2003-06-20 9:08 UTC (permalink / raw) To: Linus Torvalds Cc: Nuno Silva, Samphan Raruenrom, Vojtech Pavlik, Linux Kernel Mailing List Le ven 20/06/2003 à 02:16, Linus Torvalds a écrit : > 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 :) Xav ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Crusoe's persistent translation on linux? 2003-06-20 9:08 ` Xavier Bestel @ 2003-06-20 9:33 ` Nick Piggin 2003-06-20 14:08 ` Henning P. Schmiedehausen 2003-06-20 15:38 ` Linus Torvalds 2 siblings, 0 replies; 52+ messages in thread From: Nick Piggin @ 2003-06-20 9:33 UTC (permalink / raw) To: Xavier Bestel Cc: Linus Torvalds, Nuno Silva, Samphan Raruenrom, Vojtech Pavlik, Linux Kernel Mailing List Xavier Bestel wrote: >Le ven 20/06/2003 à 02:16, Linus Torvalds a écrit : > >>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 :) > > Hmm, did you just write: "Linus, I take you for an imbecile" ? ;) ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Crusoe's persistent translation on linux? 2003-06-20 9:08 ` Xavier Bestel 2003-06-20 9:33 ` Nick Piggin @ 2003-06-20 14:08 ` Henning P. Schmiedehausen 2003-06-20 15:38 ` Linus Torvalds 2 siblings, 0 replies; 52+ messages in thread From: Henning P. Schmiedehausen @ 2003-06-20 14:08 UTC (permalink / raw) To: linux-kernel Xavier Bestel <xavier.bestel@free.fr> writes: >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 :) God (and the NSA) gave you key signing protocols to avoid that. The Microcode upload for the Intel processors is even well documented. I have yet to see someone putting out "enhanced microcode files for the P<xxx> processor". Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/ Java, perl, Solaris, Linux, xSP Consulting, Web Services freelance consultant -- Jakarta Turbine Development -- hero for hire ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Crusoe's persistent translation on linux? 2003-06-20 9:08 ` Xavier Bestel 2003-06-20 9:33 ` Nick Piggin 2003-06-20 14:08 ` Henning P. Schmiedehausen @ 2003-06-20 15:38 ` Linus Torvalds 2003-06-20 16:51 ` AMD MP, SMP, Tyan 2466 kernel 2 siblings, 1 reply; 52+ messages in thread From: Linus Torvalds @ 2003-06-20 15:38 UTC (permalink / raw) To: Xavier Bestel Cc: Nuno Silva, Samphan Raruenrom, Vojtech Pavlik, Linux Kernel Mailing List On 20 Jun 2003, Xavier Bestel wrote: > > 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" ? No. Quite the reverse. I just effectively wrote "you _cannot_ do that". And we won't even tell the details of _how_ you cannot do that. In fact, even inside transmeta you cannot do that, without having a specially blessed version of the flash that allows upgrades. If you ever see a machine with a prominent notice saying "CMS upgraded to development version", then that's a hint that it's a machine that TMTA developers could change. But even then you'd have to know how to change it. Think of it like the Intel microcode update, except on steroids. Big steroids. Linus ^ permalink raw reply [flat|nested] 52+ messages in thread
* AMD MP, SMP, Tyan 2466 2003-06-20 15:38 ` Linus Torvalds @ 2003-06-20 16:51 ` kernel 2003-06-20 17:08 ` Bart SCHELSTRAETE 2003-06-20 17:09 ` Brian Jackson 0 siblings, 2 replies; 52+ messages in thread From: kernel @ 2003-06-20 16:51 UTC (permalink / raw) To: linux-kernel 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 (rgooch@atnf.csiro.au) 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 (rgooch@atnf.csiro.au) 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] ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: AMD MP, SMP, Tyan 2466 2003-06-20 16:51 ` AMD MP, SMP, Tyan 2466 kernel @ 2003-06-20 17:08 ` Bart SCHELSTRAETE 2003-06-20 17:09 ` Brian Jackson 1 sibling, 0 replies; 52+ messages in thread From: Bart SCHELSTRAETE @ 2003-06-20 17:08 UTC (permalink / raw) To: kernel; +Cc: linux-kernel kernel wrote: >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 > Did you compile this kernel yourself? I think so, and I think there's something wrong with your compiler. >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 > And here's something wrong with your glibc......... rgrds, Bart -- Schelstraete Bart DHL Aviation ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: AMD MP, SMP, Tyan 2466 2003-06-20 16:51 ` AMD MP, SMP, Tyan 2466 kernel 2003-06-20 17:08 ` Bart SCHELSTRAETE @ 2003-06-20 17:09 ` Brian Jackson 2003-06-25 17:37 ` Artur Jasowicz 1 sibling, 1 reply; 52+ messages in thread From: Brian Jackson @ 2003-06-20 17:09 UTC (permalink / raw) To: kernel, linux-kernel .config please On Friday 20 June 2003 11:51 am, kernel wrote: > 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 > (rgooch@atnf.csiro.au) > 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 > (rgooch@atnf.csiro.au) > 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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- OpenGFS -- http://opengfs.sourceforge.net Home -- http://www.brianandsara.net ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: AMD MP, SMP, Tyan 2466 2003-06-20 17:09 ` Brian Jackson @ 2003-06-25 17:37 ` Artur Jasowicz 2003-06-25 18:51 ` joe briggs 2003-06-25 19:01 ` joe briggs 0 siblings, 2 replies; 52+ messages in thread From: Artur Jasowicz @ 2003-06-25 17:37 UTC (permalink / raw) To: Brian Jackson, Bart SCHELSTRAETE, linux-kernel 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: > > .config please > See below Bart: > 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? > 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 ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: AMD MP, SMP, Tyan 2466 2003-06-25 17:37 ` Artur Jasowicz @ 2003-06-25 18:51 ` joe briggs 2003-06-25 18:16 ` Mike Dresser 2003-07-21 20:52 ` Artur Jasowicz 2003-06-25 19:01 ` joe briggs 1 sibling, 2 replies; 52+ messages in thread From: joe briggs @ 2003-06-25 18:51 UTC (permalink / raw) To: Artur Jasowicz, Brian Jackson, Bart SCHELSTRAETE, linux-kernel 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 good luck, Joe On Wednesday 25 June 2003 01:37 pm, Artur Jasowicz wrote: > 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: > > .config please > > See below > > Bart: > > 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? > > > 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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Joe Briggs Briggs Media Systems 105 Burnsen Ave. Manchester NH 01304 USA TEL 603-232-3115 FAX 603-625-5809 MOBILE 603-493-2386 www.briggsmedia.com ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: AMD MP, SMP, Tyan 2466 2003-06-25 18:51 ` joe briggs @ 2003-06-25 18:16 ` Mike Dresser 2003-07-21 20:52 ` Artur Jasowicz 1 sibling, 0 replies; 52+ messages in thread From: Mike Dresser @ 2003-06-25 18:16 UTC (permalink / raw) To: joe briggs; +Cc: linux-kernel On Wed, 25 Jun 2003, joe briggs wrote: > 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 Did you apply the fix from WDC for these drives? Mike ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: AMD MP, SMP, Tyan 2466 2003-06-25 18:51 ` joe briggs 2003-06-25 18:16 ` Mike Dresser @ 2003-07-21 20:52 ` Artur Jasowicz 2003-07-22 4:02 ` Jason 1 sibling, 1 reply; 52+ messages in thread From: Artur Jasowicz @ 2003-07-21 20:52 UTC (permalink / raw) To: joe briggs, Brian Jackson, Bart SCHELSTRAETE, linux-kernel 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 > > 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. > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: AMD MP, SMP, Tyan 2466 2003-07-21 20:52 ` Artur Jasowicz @ 2003-07-22 4:02 ` Jason 2003-07-23 12:19 ` paterley 0 siblings, 1 reply; 52+ messages in thread From: Jason @ 2003-07-22 4:02 UTC (permalink / raw) To: Artur Jasowicz, linux-kernel 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. That's just my $.02 and I hope it helps in some way. Oh yeah, and I am running 2.4.21 config'ed for AMD and SMP and still, no problems. On Mon, 2003-07-21 at 16:52, Artur Jasowicz wrote: > 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 > > > > > 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. > > > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: AMD MP, SMP, Tyan 2466 2003-07-22 4:02 ` Jason @ 2003-07-23 12:19 ` paterley 2003-07-23 20:03 ` Joe Briggs 0 siblings, 1 reply; 52+ messages in thread From: paterley @ 2003-07-23 12:19 UTC (permalink / raw) To: Jason; +Cc: linux-kernel On 22 Jul 2003 00:02:39 -0400 Jason <jason@project-lace.org> wrote: > 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-- ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: AMD MP, SMP, Tyan 2466 2003-07-23 12:19 ` paterley @ 2003-07-23 20:03 ` Joe Briggs 0 siblings, 0 replies; 52+ messages in thread From: Joe Briggs @ 2003-07-23 20:03 UTC (permalink / raw) To: paterley, Jason; +Cc: linux-kernel Tyan publishes a list of tested memory chips for this board on their website. I tried the AOPEN ECC memory and it did not work. On Wednesday 23 July 2003 08:19 am, paterley wrote: > On 22 Jul 2003 00:02:39 -0400 > > Jason <jason@project-lace.org> wrote: > > 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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Joe Briggs Briggs Media Systems 105 Burnsen Ave. Manchester NH 03104 USA TEL/FAX 603 232 3115 www.briggsmedia.com ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: AMD MP, SMP, Tyan 2466 2003-06-25 17:37 ` Artur Jasowicz 2003-06-25 18:51 ` joe briggs @ 2003-06-25 19:01 ` joe briggs 2003-06-25 18:56 ` Edward Tandi 1 sibling, 1 reply; 52+ messages in thread From: joe briggs @ 2003-06-25 19:01 UTC (permalink / raw) To: Artur Jasowicz, Brian Jackson, Bart SCHELSTRAETE, linux-kernel 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. On Wednesday 25 June 2003 01:37 pm, Artur Jasowicz wrote: > 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: > > .config please > > See below > > Bart: > > 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? > > > 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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Joe Briggs Briggs Media Systems 105 Burnsen Ave. Manchester NH 01304 USA TEL 603-232-3115 FAX 603-625-5809 MOBILE 603-493-2386 www.briggsmedia.com ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: AMD MP, SMP, Tyan 2466 2003-06-25 19:01 ` joe briggs @ 2003-06-25 18:56 ` Edward Tandi 2003-06-25 22:59 ` Timothy Miller 0 siblings, 1 reply; 52+ messages in thread From: Edward Tandi @ 2003-06-25 18:56 UTC (permalink / raw) To: joe briggs Cc: Artur Jasowicz, Brian Jackson, Bart SCHELSTRAETE, Kernel mailing list On Wed, 2003-06-25 at 20:01, joe briggs wrote: > 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. 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. Ed-T. > On Wednesday 25 June 2003 01:37 pm, Artur Jasowicz wrote: > > 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... ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: AMD MP, SMP, Tyan 2466 2003-06-25 18:56 ` Edward Tandi @ 2003-06-25 22:59 ` Timothy Miller 2003-06-25 23:17 ` Edward Tandi 0 siblings, 1 reply; 52+ messages in thread From: Timothy Miller @ 2003-06-25 22:59 UTC (permalink / raw) To: Edward Tandi Cc: joe briggs, Artur Jasowicz, Brian Jackson, Bart SCHELSTRAETE, Kernel mailing list Edward Tandi wrote: > > > 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. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: AMD MP, SMP, Tyan 2466 2003-06-25 22:59 ` Timothy Miller @ 2003-06-25 23:17 ` Edward Tandi 2003-06-25 23:26 ` Timothy Miller ` (2 more replies) 0 siblings, 3 replies; 52+ messages in thread From: Edward Tandi @ 2003-06-25 23:17 UTC (permalink / raw) To: Timothy Miller Cc: joe briggs, Artur Jasowicz, Brian Jackson, Bart SCHELSTRAETE, Kernel mailing list On Wed, 2003-06-25 at 23:59, Timothy Miller wrote: > Edward Tandi wrote: > > > > 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. 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. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: AMD MP, SMP, Tyan 2466 2003-06-25 23:17 ` Edward Tandi @ 2003-06-25 23:26 ` Timothy Miller 2003-06-25 23:39 ` Timothy Miller 2003-06-25 23:40 ` Edward Tandi 2003-06-25 23:35 ` Joel Jaeggli 2003-06-26 12:25 ` AMD MP, SMP, Tyan 2466, REISERFS I/O error joe briggs 2 siblings, 2 replies; 52+ messages in thread From: Timothy Miller @ 2003-06-25 23:26 UTC (permalink / raw) To: Edward Tandi Cc: joe briggs, Artur Jasowicz, Brian Jackson, Bart SCHELSTRAETE, Kernel mailing list Edward Tandi wrote: > On Wed, 2003-06-25 at 23:59, Timothy Miller wrote: > >> >>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. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: AMD MP, SMP, Tyan 2466 2003-06-25 23:26 ` Timothy Miller @ 2003-06-25 23:39 ` Timothy Miller 2003-06-26 0:29 ` Edward Tandi 2003-06-25 23:40 ` Edward Tandi 1 sibling, 1 reply; 52+ messages in thread From: Timothy Miller @ 2003-06-25 23:39 UTC (permalink / raw) To: Timothy Miller Cc: Edward Tandi, joe briggs, Artur Jasowicz, Brian Jackson, Bart SCHELSTRAETE, Kernel mailing list Timothy Miller wrote: > 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. > Here's a URL: http://www.simmtester.com/PAGE/memory/memfaq.asp?cat=6&subcat=&tableView=detail&faqId=15 ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: AMD MP, SMP, Tyan 2466 2003-06-25 23:39 ` Timothy Miller @ 2003-06-26 0:29 ` Edward Tandi 0 siblings, 0 replies; 52+ messages in thread From: Edward Tandi @ 2003-06-26 0:29 UTC (permalink / raw) To: Timothy Miller Cc: joe briggs, Artur Jasowicz, Brian Jackson, Bart SCHELSTRAETE, Kernel mailing list On Thu, 2003-06-26 at 00:39, Timothy Miller wrote: > Timothy Miller wrote: > > > 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. > > > Here's a URL: > > http://www.simmtester.com/PAGE/memory/memfaq.asp?cat=6&subcat=&tableView=detail&faqId=15 It does seem a bit out of date talking about PC100. But I found another source of information: http://www.memorysuppliers.com/memoryterms.html Registered Memory SDRAM memory that contains registers directly on the module. The registers re-drive the signals through the memory chips and allow the module to be built with more memory chips. Registered and unbuffered memory cannot be mixed. The design of the computer memory controller dictates which type of memory the computer requires. Regarding the last sentence, the Tyan 2466 appears to be able to support unbuffered memory in slots 1 and 2 only (and the type cannot be mixed of course). The earlier 2460 doesn't allow anything but registered. Ed-T. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: AMD MP, SMP, Tyan 2466 2003-06-25 23:26 ` Timothy Miller 2003-06-25 23:39 ` Timothy Miller @ 2003-06-25 23:40 ` Edward Tandi 2003-06-26 15:12 ` Herbert Poetzl 1 sibling, 1 reply; 52+ messages in thread From: Edward Tandi @ 2003-06-25 23:40 UTC (permalink / raw) To: Timothy Miller Cc: joe briggs, Artur Jasowicz, Brian Jackson, Bart SCHELSTRAETE, Kernel mailing list On Thu, 2003-06-26 at 00:26, Timothy Miller wrote: > Edward Tandi wrote: > > On Wed, 2003-06-25 at 23:59, Timothy Miller wrote: > >> > >>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. 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). > 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. > 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. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: AMD MP, SMP, Tyan 2466 2003-06-25 23:40 ` Edward Tandi @ 2003-06-26 15:12 ` Herbert Poetzl 0 siblings, 0 replies; 52+ messages in thread From: Herbert Poetzl @ 2003-06-26 15:12 UTC (permalink / raw) To: Edward Tandi; +Cc: Timothy Miller, linux-kernel On Thu, Jun 26, 2003 at 12:40:41AM +0100, Edward Tandi wrote: > On Thu, 2003-06-26 at 00:26, Timothy Miller wrote: > > Edward Tandi wrote: > > > On Wed, 2003-06-25 at 23:59, Timothy Miller wrote: > > >> > > >>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. > > 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). > > > 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). hmm, AFAIK, registered memory has an additional chip/device called a 'register' (a latch), which buffers/synchronizes the data going in and out. this processes, as mentioned, requires an additional clock cycle, but in turn improves signal strength and stability (by re-driving control/data signals) ... > I only have 2 x 256MB in the box. > > > 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. SMP systems do much more MIO (non sequential memory access) than UP systems ... so any issues regarding correctness of the signalling, will be amplified ... HTH, Herbert > Ed-T. > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: AMD MP, SMP, Tyan 2466 2003-06-25 23:17 ` Edward Tandi 2003-06-25 23:26 ` Timothy Miller @ 2003-06-25 23:35 ` Joel Jaeggli 2003-06-26 12:25 ` AMD MP, SMP, Tyan 2466, REISERFS I/O error joe briggs 2 siblings, 0 replies; 52+ messages in thread From: Joel Jaeggli @ 2003-06-25 23:35 UTC (permalink / raw) To: Edward Tandi Cc: Timothy Miller, joe briggs, Artur Jasowicz, Brian Jackson, Bart SCHELSTRAETE, Kernel mailing list registers simply buffer the address and control signals going to and from a module. On server boards the issue has more to do with trace length and electrical loading than anything else... One of the issues you encounter on server boards more than elsewere is larger more complicated memory modules things like 36 chip double stack ecc 1 and 2gb dimms, or a large number of dimm modules overall (like 4-8 slots rather than 1-4). joelja On 26 Jun 2003, Edward Tandi wrote: > > 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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- -------------------------------------------------------------------------- Joel Jaeggli Academic User Services joelja@darkwing.uoregon.edu -- PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -- In Dr. Johnson's famous dictionary patriotism is defined as the last resort of the scoundrel. With all due respect to an enlightened but inferior lexicographer I beg to submit that it is the first. -- Ambrose Bierce, "The Devil's Dictionary" ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: AMD MP, SMP, Tyan 2466, REISERFS I/O error 2003-06-25 23:17 ` Edward Tandi 2003-06-25 23:26 ` Timothy Miller 2003-06-25 23:35 ` Joel Jaeggli @ 2003-06-26 12:25 ` joe briggs 2003-06-26 11:55 ` Oleg Drokin 2 siblings, 1 reply; 52+ messages in thread From: joe briggs @ 2003-06-26 12:25 UTC (permalink / raw) To: Edward Tandi, Timothy Miller, reiser Cc: Artur Jasowicz, Brian Jackson, Bart SCHELSTRAETE, Kernel mailing list [-- Attachment #1: Type: text/plain, Size: 2266 bytes --] 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 On Wednesday 25 June 2003 07:17 pm, Edward Tandi wrote: > On Wed, 2003-06-25 at 23:59, Timothy Miller wrote: > > Edward Tandi wrote: > > > 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. > > 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. -- Joe Briggs Briggs Media Systems 105 Burnsen Ave. Manchester NH 01304 USA TEL 603-232-3115 FAX 603-625-5809 MOBILE 603-493-2386 www.briggsmedia.com [-- Attachment #2: reiserfs.txt --] [-- Type: text/plain, Size: 4336 bytes --] Jun 26 07:04:10 sentry kernel: vs-5150: search_by_key: invalid format found in block 266772. Fsck? Jun 26 07:04:10 sentry kernel: vs-5657: reiserfs_do_truncate: i/o failure occurred trying to truncate [22 154 0xfffffffffffffff DIRECT] Jun 26 07:04:10 sentry kernel: is_tree_node: node level 11226 does not match to the expected one 1 Jun 26 07:04:10 sentry kernel: vs-5150: search_by_key: invalid format found in block 266772. Fsck? Jun 26 07:04:10 sentry kernel: vs-5350: reiserfs_delete_solid_item: i/o failure occurred trying to delete [22 154 0x0 SD] Jun 26 07:04:10 sentry kernel: is_tree_node: node level 11226 does not match to the expected one 1 Jun 26 07:04:10 sentry kernel: vs-5150: search_by_key: invalid format found in block 266772. Fsck? Jun 26 07:04:10 sentry kernel: vs-13050: reiserfs_update_sd: i/o failure occurred trying to update [22 140 0x0 SD] stat datais_tree_node: node level 11226 does not match to the expected one 1 Jun 26 07:04:10 sentry kernel: vs-5150: search_by_key: invalid format found in block 266772. Fsck? Jun 26 07:04:10 sentry kernel: vs-5657: reiserfs_do_truncate: i/o failure occurred trying to truncate [22 140 0xfffffffffffffff DIRECT] Jun 26 07:04:10 sentry kernel: is_tree_node: node level 11226 does not match to the expected one 1 Jun 26 07:04:10 sentry kernel: vs-5150: search_by_key: invalid format found in block 266772. Fsck? Jun 26 07:04:10 sentry kernel: vs-5350: reiserfs_delete_solid_item: i/o failure occurred trying to delete [22 140 0x0 SD] Jun 26 07:04:10 sentry kernel: is_tree_node: node level 11226 does not match to the expected one 1 Jun 26 07:04:10 sentry kernel: vs-5150: search_by_key: invalid format found in block 266772. Fsck? Jun 26 07:04:10 sentry kernel: vs-13050: reiserfs_update_sd: i/o failure occurred trying to update [22 101 0x0 SD] stat datais_tree_node: node level 11226 does not match to the expected one 1 Jun 26 07:04:10 sentry kernel: vs-5150: search_by_key: invalid format found in block 266772. Fsck? Jun 26 07:04:10 sentry kernel: vs-5657: reiserfs_do_truncate: i/o failure occurred trying to truncate [22 101 0xfffffffffffffff DIRECT] Jun 26 07:04:10 sentry kernel: is_tree_node: node level 11226 does not match to the expected one 1 Jun 26 07:04:10 sentry kernel: vs-5150: search_by_key: invalid format found in block 266772. Fsck? Jun 26 07:04:10 sentry kernel: vs-5350: reiserfs_delete_solid_item: i/o failure occurred trying to delete [22 101 0x0 SD] Jun 26 07:04:10 sentry kernel: is_tree_node: node level 11226 does not match to the expected one 1 Jun 26 07:04:10 sentry kernel: vs-5150: search_by_key: invalid format found in block 266772. Fsck? Jun 26 07:04:10 sentry kernel: vs-13050: reiserfs_update_sd: i/o failure occurred trying to update [22 152 0x0 SD] stat datais_tree_node: node level 11226 does not match to the expected one 1 Jun 26 07:04:10 sentry kernel: vs-5150: search_by_key: invalid format found in block 266772. Fsck? Jun 26 07:04:10 sentry kernel: vs-5657: reiserfs_do_truncate: i/o failure occurred trying to truncate [22 152 0xfffffffffffffff DIRECT] Jun 26 07:04:10 sentry kernel: is_tree_node: node level 11226 does not match to the expected one 1 Jun 26 07:04:10 sentry kernel: vs-5150: search_by_key: invalid format found in block 266772. Fsck? Jun 26 07:04:10 sentry kernel: vs-5350: reiserfs_delete_solid_item: i/o failure occurred trying to delete [22 152 0x0 SD] Jun 26 07:04:10 sentry kernel: is_tree_node: node level 11226 does not match to the expected one 1 Jun 26 07:04:10 sentry kernel: vs-5150: search_by_key: invalid format found in block 266772. Fsck? Jun 26 07:04:10 sentry kernel: vs-13050: reiserfs_update_sd: i/o failure occurred trying to update [22 104 0x0 SD] stat datais_tree_node: node level 11226 does not match to the expected one 1 Jun 26 07:04:10 sentry kernel: vs-5150: search_by_key: invalid format found in block 266772. Fsck? Jun 26 07:04:10 sentry kernel: vs-5657: reiserfs_do_truncate: i/o failure occurred trying to truncate [22 104 0xfffffffffffffff DIRECT] Jun 26 07:04:10 sentry kernel: is_tree_node: node level 11226 does not match to the expected one 1 Jun 26 07:04:10 sentry kernel: vs-5150: search_by_key: invalid format found in block 266772. Fsck? Jun 26 07:04:10 sentry kernel: vs-5350: reiserfs_delete_solid_item: i/o failure occurred trying to delete [22 104 0x0 SD] ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: AMD MP, SMP, Tyan 2466, REISERFS I/O error 2003-06-26 12:25 ` AMD MP, SMP, Tyan 2466, REISERFS I/O error joe briggs @ 2003-06-26 11:55 ` Oleg Drokin 2003-06-26 13:37 ` joe briggs 2003-06-26 23:15 ` Timothy Miller 0 siblings, 2 replies; 52+ messages in thread From: Oleg Drokin @ 2003-06-26 11:55 UTC (permalink / raw) To: joe briggs Cc: Edward Tandi, Timothy Miller, reiser, Artur Jasowicz, Brian Jackson, Bart SCHELSTRAETE, Kernel mailing list Hello! On Thu, Jun 26, 2003 at 08:25:54AM -0400, joe briggs wrote: > 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 ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: AMD MP, SMP, Tyan 2466, REISERFS I/O error 2003-06-26 11:55 ` Oleg Drokin @ 2003-06-26 13:37 ` joe briggs 2003-06-26 23:15 ` Timothy Miller 1 sibling, 0 replies; 52+ messages in thread From: joe briggs @ 2003-06-26 13:37 UTC (permalink / raw) To: Oleg Drokin Cc: Edward Tandi, Timothy Miller, reiser, Artur Jasowicz, Brian Jackson, Bart SCHELSTRAETE, Kernel mailing list On Thursday 26 June 2003 07:55 am, Oleg Drokin wrote: > > Is not this is one of those heavy-PCI loaded boxes that ocasionally corrupt > data when PCI is overloaded? I was curious that I did not get a corresponding driver error such as "lost irq" or "interrupted dma" or something like that on the drive. BTW, it was the system (hda) drive that was corrupted. > 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 -- Joe Briggs Briggs Media Systems 105 Burnsen Ave. Manchester NH 01304 USA TEL 603-232-3115 FAX 603-625-5809 MOBILE 603-493-2386 www.briggsmedia.com ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: AMD MP, SMP, Tyan 2466, REISERFS I/O error 2003-06-26 11:55 ` Oleg Drokin 2003-06-26 13:37 ` joe briggs @ 2003-06-26 23:15 ` Timothy Miller 2003-06-26 23:48 ` Joel Jaeggli 2003-06-27 13:01 ` joe briggs 1 sibling, 2 replies; 52+ messages in thread From: Timothy Miller @ 2003-06-26 23:15 UTC (permalink / raw) To: Oleg Drokin Cc: joe briggs, Edward Tandi, reiser, Artur Jasowicz, Brian Jackson, Bart SCHELSTRAETE, Kernel mailing list Oleg Drokin wrote: > 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. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: AMD MP, SMP, Tyan 2466, REISERFS I/O error 2003-06-26 23:15 ` Timothy Miller @ 2003-06-26 23:48 ` Joel Jaeggli 2003-06-27 13:01 ` joe briggs 1 sibling, 0 replies; 52+ messages in thread From: Joel Jaeggli @ 2003-06-26 23:48 UTC (permalink / raw) To: Timothy Miller Cc: Oleg Drokin, joe briggs, Edward Tandi, reiser, Artur Jasowicz, Brian Jackson, Bart SCHELSTRAETE, Kernel mailing list On Thu, 26 Jun 2003, Timothy Miller wrote: > > 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. the amd 760mpx chipset has two pci buses... One, the Primary PCI 2.2 compliant 66-MHz/64-bit/32-bit PCI Bus is connected to the amd 762 north bridge, the Secondary PCI 2.2 compliant 33-MHz/32-bit PCI Bus is connected to the amd 768 south bridge. you won't find an mpx with more than 4 32 bit pci slots. > 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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- -------------------------------------------------------------------------- Joel Jaeggli Academic User Services joelja@darkwing.uoregon.edu -- PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -- In Dr. Johnson's famous dictionary patriotism is defined as the last resort of the scoundrel. With all due respect to an enlightened but inferior lexicographer I beg to submit that it is the first. -- Ambrose Bierce, "The Devil's Dictionary" ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: AMD MP, SMP, Tyan 2466, REISERFS I/O error 2003-06-26 23:15 ` Timothy Miller 2003-06-26 23:48 ` Joel Jaeggli @ 2003-06-27 13:01 ` joe briggs 1 sibling, 0 replies; 52+ messages in thread From: joe briggs @ 2003-06-27 13:01 UTC (permalink / raw) To: Timothy Miller, Oleg Drokin Cc: Edward Tandi, reiser, Artur Jasowicz, Brian Jackson, Bart SCHELSTRAETE, Kernel mailing list In this specific case of the Tyan S2466, it has 2 64/66 slots, and 4 32/33 slots. The chipset is the AMD 760MPX, AMD 762 system controller, and AMD 768 peripheral controller, and the Winbound 83627 super i/o asic. I thought that this chipset actually had 2 pci controllers - one for the 64-bit slots and the other for the 32-bit. Am I wrong? On Thursday 26 June 2003 07:15 pm, Timothy Miller wrote: > Oleg Drokin wrote: > > 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. -- Joe Briggs Briggs Media Systems 105 Burnsen Ave. Manchester NH 01304 USA TEL 603-232-3115 FAX 603-625-5809 MOBILE 603-493-2386 www.briggsmedia.com ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Crusoe's persistent translation on linux? 2003-06-20 0:16 ` Linus Torvalds 2003-06-20 2:08 ` Nuno Silva 2003-06-20 9:08 ` Xavier Bestel @ 2003-06-20 12:05 ` Samphan Raruenrom 2 siblings, 0 replies; 52+ messages in thread From: Samphan Raruenrom @ 2003-06-20 12:05 UTC (permalink / raw) To: Linus Torvalds; +Cc: Nuno Silva, Vojtech Pavlik, linux-kernel Linus Torvalds wrote: > 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. So how can I increase the size of the translation cache. I read from Transmeta's whitepaper that both BIOS and OS can do this. This mean that I should be able to insert a little piece of code in the kernel somewhere and experiment with the new setting. I guess it might be a PCI register? How about the persistent translation service on Linux? a) Transmeta will write it for us. b) Transmeta will open enough info. for us to write it our own. What do you think? ^ permalink raw reply [flat|nested] 52+ messages in thread
[parent not found: <20030619221126.B3287@ucw.cz>]
* Crusoe's performance on linux? [not found] ` <20030619221126.B3287@ucw.cz> @ 2003-06-23 3:58 ` Samphan Raruenrom 2003-06-23 5:22 ` H. Peter Anvin ` (6 more replies) 0 siblings, 7 replies; 52+ messages in thread From: Samphan Raruenrom @ 2003-06-23 3:58 UTC (permalink / raw) To: Vojtech Pavlik, linux-kernel Vojtech Pavlik wrote: > 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. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Crusoe's performance on linux? 2003-06-23 3:58 ` Crusoe's performance " Samphan Raruenrom @ 2003-06-23 5:22 ` H. Peter Anvin 2003-06-23 5:40 ` Grzegorz Jaskiewicz ` (5 subsequent siblings) 6 siblings, 0 replies; 52+ messages in thread From: H. Peter Anvin @ 2003-06-23 5:22 UTC (permalink / raw) To: linux-kernel Followup to: <3EF67AD4.4040601@thai.com> By author: Samphan Raruenrom <samphan@thai.com> In newsgroup: linux.dev.kernel > > Vojtech Pavlik wrote: > > 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. > Which version of gcc are you running on the two machines? -hpa -- <hpa@transmeta.com> at work, <hpa@zytor.com> in private! "Unix gives you enough rope to shoot yourself in the foot." Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64 ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Crusoe's performance on linux? 2003-06-23 3:58 ` Crusoe's performance " Samphan Raruenrom 2003-06-23 5:22 ` H. Peter Anvin @ 2003-06-23 5:40 ` Grzegorz Jaskiewicz 2003-06-23 8:10 ` Vojtech Pavlik ` (4 subsequent siblings) 6 siblings, 0 replies; 52+ messages in thread From: Grzegorz Jaskiewicz @ 2003-06-23 5:40 UTC (permalink / raw) To: Samphan Raruenrom, Vojtech Pavlik, linux-kernel -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 23 of June 2003 04:58, Samphan Raruenrom wrote: > 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. Real life example. I had to compile latest kopete (im KDE application). It takes 4h and some on my 600 Mhz crusoe (128MB of RAM). On 600 mhz p3 it takes 1.5h. And this is thing i just get used to, this processor is fast only for non complex operations, since it got to "emulate" x86. I know for some tablets You can download BIOS dedicated for Windows and sepearate one for Linux. I guess it was AQUA or simmilar. Well you can even buy this one with preinstalled linux on it (i belive it is midori linux, transmeta's embded linux distro). - -- Grzegorz Jaskiewicz K4 Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE+9pLsqu082fCQYIgRAgsXAJ9qeDF+QVEirpYA7YQfZd3uuCPhIACeJUt8 d4z2oU8v3ERkQSolV27/dxg= =RdSb -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Crusoe's performance on linux? 2003-06-23 3:58 ` Crusoe's performance " Samphan Raruenrom 2003-06-23 5:22 ` H. Peter Anvin 2003-06-23 5:40 ` Grzegorz Jaskiewicz @ 2003-06-23 8:10 ` Vojtech Pavlik 2003-06-23 8:26 ` Vojtech Pavlik ` (3 subsequent siblings) 6 siblings, 0 replies; 52+ messages in thread From: Vojtech Pavlik @ 2003-06-23 8:10 UTC (permalink / raw) To: Samphan Raruenrom; +Cc: Vojtech Pavlik, linux-kernel On Mon, Jun 23, 2003 at 10:58:12AM +0700, Samphan Raruenrom wrote: > Vojtech Pavlik wrote: > > 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. Same GCC version on both? Which? -- Vojtech Pavlik SuSE Labs, SuSE CR ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Crusoe's performance on linux? 2003-06-23 3:58 ` Crusoe's performance " Samphan Raruenrom ` (2 preceding siblings ...) 2003-06-23 8:10 ` Vojtech Pavlik @ 2003-06-23 8:26 ` Vojtech Pavlik 2003-06-23 18:58 ` Samphan Raruenrom 2003-06-23 23:46 ` H. Peter Anvin 2003-06-24 0:51 ` H. Peter Anvin ` (2 subsequent siblings) 6 siblings, 2 replies; 52+ messages in thread From: Vojtech Pavlik @ 2003-06-23 8:26 UTC (permalink / raw) To: Samphan Raruenrom; +Cc: Vojtech Pavlik, linux-kernel On Mon, Jun 23, 2003 at 10:58:12AM +0700, Samphan Raruenrom wrote: > Vojtech Pavlik wrote: > > 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. 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? -- Vojtech Pavlik SuSE Labs, SuSE CR ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Crusoe's performance on linux? 2003-06-23 8:26 ` Vojtech Pavlik @ 2003-06-23 18:58 ` Samphan Raruenrom 2003-06-24 1:43 ` dean gaudet 2003-06-23 23:46 ` H. Peter Anvin 1 sibling, 1 reply; 52+ messages in thread From: Samphan Raruenrom @ 2003-06-23 18:58 UTC (permalink / raw) To: Vojtech Pavlik; +Cc: linux-kernel Vojtech Pavlik wrote: > On Mon, Jun 23, 2003 at 10:58:12AM +0700, Samphan Raruenrom wrote: >>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? Both use gcc 3.2. The desktop pentium III is very old. Slow ram/bus may be the reason. Or this may be the fastest a pentium iii 1 MHz can perform?. Large RAM don't help pentium III. It doesn't need them here. Large RAM should help Cursoe a lot. CMS should use those RAM as traslation cache and put the entire processes (make, gcc, as) in it. I guess 17.x min kernel compile time result from CMS still taking time interpreting x86 code (because it decide to do so to conserve translation cache space?). I wish the linux kernel could hint CMS to do a better job, if possible, like when to interpret, translate or fully optimize and save-to-disk for later use. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Crusoe's performance on linux? 2003-06-23 18:58 ` Samphan Raruenrom @ 2003-06-24 1:43 ` dean gaudet 2003-06-24 4:33 ` dean gaudet 0 siblings, 1 reply; 52+ messages in thread From: dean gaudet @ 2003-06-24 1:43 UTC (permalink / raw) To: Samphan Raruenrom; +Cc: Vojtech Pavlik, linux-kernel On Mon, 23 Jun 2003, Samphan Raruenrom wrote: > Desktop - Pentium III 1 G Hz 754 MB -> 10.x min. > Tablet PC - Crusoe TM5800 1 GHz 731 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 (even if i try to guess if your M=10^6 or M=2^20). > From freshdiagnos benchmack, the TPC has about 2x faster RAM. you're mistaken if you believe marketing doodoo which says that DDR is "twice as fast" as SDR -- only data transfer is clocked at twice the bus speed. there's command bus costs which are identical between SDR and DDR -- and its these costs which dominate the bus in non-sequential benchmarks such as compilation (as opposed to excessively sequential benchmarks which are used for marketing purposes). expansion memory for the tablet PC is PC133 -- you can verify this by reading the part numbers off the SODIMM and doing a lookup on the manufacturer's website... if you don't have any expansion memory in your tablet PC then you've got only 256MB of RAM and i really don't think you should be using tmpfs. > Shouldn't TM5800 with 4-wide VLIW engine and 64 registers, > working on a single task, run as fast as a Pentium III? nope. you're assuming that the VLIW has 4 completely orthogonal processing units -- it doesn't. try measuring code sequences such as: add %eax,%ebx add %eax,%ecx add %eax,%edx add %eax,%edi add %eax,%ebx add %eax,%ecx add %eax,%edx add %eax,%edi ... you'll quickly figure out how many ALUs the machine has, plus you can figure out their latencies and throughputs (by increasing or decreasing the number of independent additions). if you do this you'll find that p3 and tm5800 are essentially just as "wide" as each other for ALU operations: a pair of 32-bit ALUs with single-cycle latency and single-cycle throughput. similar microarchitctural analysis of other aspects of the cores can help explain the differences you see. traditionally VLIW have been used for DSP and other such related tasks in which there are a large number of orthogonal units. in tm5800 you can think of the VLIW as a set of up to 4 micro-ops which feed the front of up to 4 pipelines in each cycle -- much like the decoded micro-ops in the p3 feed one of several pipelines in each cycle. 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 see what happens. and also consider doing i/o benchmarks while running something which soaks up idle cycles (i.e. a tight loop incrementing a counter) to see how the two architectures differ. -dean ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Crusoe's performance on linux? 2003-06-24 1:43 ` dean gaudet @ 2003-06-24 4:33 ` dean gaudet 2003-06-24 22:54 ` Samphan Raruenrom 0 siblings, 1 reply; 52+ messages in thread From: dean gaudet @ 2003-06-24 4:33 UTC (permalink / raw) To: Samphan Raruenrom; +Cc: linux-kernel On Mon, 23 Jun 2003, dean gaudet wrote: > On Mon, 23 Jun 2003, Samphan Raruenrom wrote: > > > 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 you know a few other things occured to me -- you should use "vmstat 5" to find out if any disk i/o is occuring (not that if longrun is doing its job then the "idle%" for cpu statistic is completely useless -- longrun should be making it as close to 100% as possible) . i'm guessing you've got a desktop disk drive in your p3 system -- which almost certainly outperforms the laptop disk in the tablet pc... not only for reasons like platter transfer speed, and seek latency, but it's also possible your tablet isn't using anything faster than UDMA33 -- and in fact it's entirely possible you're not even using UDMA33. do something like "grep hda /var/log/dmesg" to see what the bootup messages said. try "hdparm -d /dev/hda" to see if dma is active -- and if it isn't, try "hdparm -d1 /dev/hda" to enable it. if that doesn't work then it's most likely you don't have the IDE driver necessary for your tablet -- try "lspci -v" and try to find your southbridge IDE controller... i don't recall which southbridge is in the tablet, many crusoe boxes have ALi southbridges which have a kernel driver, but i think the tablet has something other than ALi... if in doubt post here and i'm sure someone can point you to the right driver. -dean ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Crusoe's performance on linux? 2003-06-24 4:33 ` dean gaudet @ 2003-06-24 22:54 ` Samphan Raruenrom 2003-06-24 23:06 ` dean gaudet 0 siblings, 1 reply; 52+ messages in thread From: Samphan Raruenrom @ 2003-06-24 22:54 UTC (permalink / raw) To: dean gaudet, Linus Torvalds; +Cc: linux-kernel, hpa, Tc1000-linux >>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 I copy the number from the 'total' column after free -m. They're about 256x3 with Crusoe gave about 24M to CMS (I guess). I tried the tests again with swapoff, on tmpfs, on disks, the result are approximately the same. The 'kernel' used for compilation and the setting are exactly the same (2.4.21-ac1). The 'kernel' used to run the test and the setting are about the same (2.4.21-ac1 vs ac2). The desktop is Red Hat 8, gcc 3.2. The TPC is Red Hat 9, gcc 3.2. So the result are real, no disk speed related. What do you think? I can't look at the running CMS or the translation cache so I don't know what it is doing but I guess that after several run of gcc+as+ld, the CMS still decide to interpret most part of their x86 code. Am I wrong? Or that TM5800 is already running as fast as possible? (from tcache) ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Crusoe's performance on linux? 2003-06-24 22:54 ` Samphan Raruenrom @ 2003-06-24 23:06 ` dean gaudet 0 siblings, 0 replies; 52+ messages in thread From: dean gaudet @ 2003-06-24 23:06 UTC (permalink / raw) To: Samphan Raruenrom; +Cc: Linus Torvalds, linux-kernel, hpa, Tc1000-linux On Wed, 25 Jun 2003, Samphan Raruenrom wrote: > So the result are real, no disk speed related. What do you think? did you verify that IDE DMA is in use on the tablet PC? -dean ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Crusoe's performance on linux? 2003-06-23 8:26 ` Vojtech Pavlik 2003-06-23 18:58 ` Samphan Raruenrom @ 2003-06-23 23:46 ` H. Peter Anvin 1 sibling, 0 replies; 52+ messages in thread From: H. Peter Anvin @ 2003-06-23 23:46 UTC (permalink / raw) To: linux-kernel Followup to: <20030623102623.A18000@ucw.cz> By author: Vojtech Pavlik <vojtech@suse.cz> In newsgroup: linux.dev.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? > gcc has been getting *massively* slower with every version since 2.7.2 or so, so it's important to compare the same gcc version. -hpa -- <hpa@transmeta.com> at work, <hpa@zytor.com> in private! "Unix gives you enough rope to shoot yourself in the foot." Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64 ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Crusoe's performance on linux? 2003-06-23 3:58 ` Crusoe's performance " Samphan Raruenrom ` (3 preceding siblings ...) 2003-06-23 8:26 ` Vojtech Pavlik @ 2003-06-24 0:51 ` H. Peter Anvin 2003-06-26 3:39 ` H. Peter Anvin [not found] ` <200306240051.RAA12097@cesium.transmeta.com> 6 siblings, 0 replies; 52+ messages in thread From: H. Peter Anvin @ 2003-06-24 0:51 UTC (permalink / raw) To: linux-kernel Followup to: <3EF67AD4.4040601@thai.com> By author: Samphan Raruenrom <samphan@thai.com> In newsgroup: linux.dev.kernel > > Vojtech Pavlik wrote: > > 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. > I just realized something ... newer kernels if you do "make oldconfig" without a .config file in the directory will look for one in /boot. This could greatly skew the result. Please create a .config and use it on both systems to make sure that it's not an issue of what is being compiled in. I'm not saying that's the problem, I'm just trying to figure out what the heck is going on here. -hpa -- <hpa@transmeta.com> at work, <hpa@zytor.com> in private! "Unix gives you enough rope to shoot yourself in the foot." Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64 ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Crusoe's performance on linux? 2003-06-23 3:58 ` Crusoe's performance " Samphan Raruenrom ` (4 preceding siblings ...) 2003-06-24 0:51 ` H. Peter Anvin @ 2003-06-26 3:39 ` H. Peter Anvin 2003-06-26 4:22 ` H. Peter Anvin [not found] ` <200306240051.RAA12097@cesium.transmeta.com> 6 siblings, 1 reply; 52+ messages in thread From: H. Peter Anvin @ 2003-06-26 3:39 UTC (permalink / raw) To: linux-kernel Followup to: <3EF67AD4.4040601@thai.com> By author: Samphan Raruenrom <samphan@thai.com> In newsgroup: linux.dev.kernel > > Vojtech Pavlik wrote: > > 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. > 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. 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. The timed portion (make -j3 bzImage) part of this script takes 10m15.035s real time (user 9m10.890s, sys 0m43.350s) on my 1067 MHz Crusoe prototype system (256MB SDR, 256MB DDR, ATA33 disk) -- don't have TC1000 Tablet PC numbers yet, but I have asked someone to run it -- running RedHat 9 including distro kernel and gcc 3.2.2. It produced a bzImage file that's 1151608 bytes long when I ran it. Note that it uses "make -j3" for the bzImage, and so aren't really comparable to your times listed above. You obviously need to point the KERNEL variable at a suitable copy of linux-2.4.21.tar.gz. The script needs to run as root in order to create the tmpfs. -hpa -- <hpa@transmeta.com> at work, <hpa@zytor.com> in private! "Unix gives you enough rope to shoot yourself in the foot." Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64 ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Crusoe's performance on linux? 2003-06-26 3:39 ` H. Peter Anvin @ 2003-06-26 4:22 ` H. Peter Anvin 0 siblings, 0 replies; 52+ messages in thread From: H. Peter Anvin @ 2003-06-26 4:22 UTC (permalink / raw) To: linux-kernel Followup to: <bddptk$gqc$1@cesium.transmeta.com> By author: "H. Peter Anvin" <hpa@zytor.com> In newsgroup: linux.dev.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. > Leave it to me to actually forget the script... #!/bin/bash -x KERNEL=/home/mirror/kernel.org/linux/kernel/v2.4/linux-2.4.21.tar.gz if [ -d /tmp/build ]; then umount /tmp/build > /dev/null 2>&1 rmdir /tmp/build fi mkdir -p /tmp/build mount -t tmpfs none /tmp/build cd /tmp/build tar xfz $KERNEL cd linux* cp -f arch/i386/defconfig .config yes "" | make oldconfig make dep start=`date` time bash -c 'make -j3 bzImage > build.log 2>&1' end=`date` echo "Started: $start Ended: $end" -hpa -- <hpa@transmeta.com> at work, <hpa@zytor.com> in private! "Unix gives you enough rope to shoot yourself in the foot." Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64 ^ permalink raw reply [flat|nested] 52+ messages in thread
[parent not found: <200306240051.RAA12097@cesium.transmeta.com>]
* Re: Crusoe's performance on linux? [not found] ` <200306240051.RAA12097@cesium.transmeta.com> @ 2003-06-26 19:09 ` Samphan Raruenrom 0 siblings, 0 replies; 52+ messages in thread From: Samphan Raruenrom @ 2003-06-26 19:09 UTC (permalink / raw) To: H. Peter Anvin, linux-kernel; +Cc: Samphan Raruenrom >> Vojtech Pavlik wrote: >> > 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. >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. :-( I'm sorry. It's really my false. So all the time everyone think that I do exactly as Vojtech told. For uncomprehensible reason, no, I took the chance to upgrade my kernel to 2.4.21-ac2 then I 'make menuconfig' instead of 'make ldconfig' so I have tc1000 specific kernel with e100, VIA EIDE/sound, usb, irda, bluetooth even ppp and netfilters so it really take 17 min to 'make modules bzImage' on tc1000 on tmpfs with DMA on. Sorry for making this confusion :~~ I've just try following exactly what Vojtech told and yes, it takes about 9.5 min. I'm happy now :-) But anyway, I use exactly the same source, the same .config (with crusoe setting) and build it the same way on my Pentium III, tmpfs with DMA on. So that 10 min vs. 17 min should still mean something, right? My comparison seem to be interesting (at least to me) because Crusoe is usually said to be comparable to Pentium III. I happend to have the desktop machine with equal ram so the comparison should be fair. as long as the benchmark doesn't use harddisk. You don't need me for this comparison though. Try to find a 1 GHz Pentium III and run that 2.4.21 kernel build benchmark. I guess it should take 5.5-5.7 min (if it scale that easy). Hope these didn't make you too busy. Tell me if you need a hand. I do love to help. Samphan Raruenrom, The Open Source Project, National Electronics and Computer Technology Center, Thailand. ^ permalink raw reply [flat|nested] 52+ messages in thread
end of thread, other threads:[~2003-07-23 20:11 UTC | newest]
Thread overview: 52+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-06-19 16:37 Crusoe's persistent translation on linux? Samphan Raruenrom
2003-06-19 18:03 ` Vojtech Pavlik
2003-06-19 19:51 ` Samphan Raruenrom
2003-06-20 0:02 ` Nuno Silva
2003-06-20 0:16 ` Linus Torvalds
2003-06-20 2:08 ` Nuno Silva
2003-06-20 9:08 ` Xavier Bestel
2003-06-20 9:33 ` Nick Piggin
2003-06-20 14:08 ` Henning P. Schmiedehausen
2003-06-20 15:38 ` Linus Torvalds
2003-06-20 16:51 ` AMD MP, SMP, Tyan 2466 kernel
2003-06-20 17:08 ` Bart SCHELSTRAETE
2003-06-20 17:09 ` Brian Jackson
2003-06-25 17:37 ` Artur Jasowicz
2003-06-25 18:51 ` joe briggs
2003-06-25 18:16 ` Mike Dresser
2003-07-21 20:52 ` Artur Jasowicz
2003-07-22 4:02 ` Jason
2003-07-23 12:19 ` paterley
2003-07-23 20:03 ` Joe Briggs
2003-06-25 19:01 ` joe briggs
2003-06-25 18:56 ` Edward Tandi
2003-06-25 22:59 ` Timothy Miller
2003-06-25 23:17 ` Edward Tandi
2003-06-25 23:26 ` Timothy Miller
2003-06-25 23:39 ` Timothy Miller
2003-06-26 0:29 ` Edward Tandi
2003-06-25 23:40 ` Edward Tandi
2003-06-26 15:12 ` Herbert Poetzl
2003-06-25 23:35 ` Joel Jaeggli
2003-06-26 12:25 ` AMD MP, SMP, Tyan 2466, REISERFS I/O error joe briggs
2003-06-26 11:55 ` Oleg Drokin
2003-06-26 13:37 ` joe briggs
2003-06-26 23:15 ` Timothy Miller
2003-06-26 23:48 ` Joel Jaeggli
2003-06-27 13:01 ` joe briggs
2003-06-20 12:05 ` Crusoe's persistent translation on linux? Samphan Raruenrom
[not found] ` <20030619221126.B3287@ucw.cz>
2003-06-23 3:58 ` Crusoe's performance " Samphan Raruenrom
2003-06-23 5:22 ` H. Peter Anvin
2003-06-23 5:40 ` Grzegorz Jaskiewicz
2003-06-23 8:10 ` Vojtech Pavlik
2003-06-23 8:26 ` Vojtech Pavlik
2003-06-23 18:58 ` Samphan Raruenrom
2003-06-24 1:43 ` dean gaudet
2003-06-24 4:33 ` dean gaudet
2003-06-24 22:54 ` Samphan Raruenrom
2003-06-24 23:06 ` dean gaudet
2003-06-23 23:46 ` H. Peter Anvin
2003-06-24 0:51 ` H. Peter Anvin
2003-06-26 3:39 ` H. Peter Anvin
2003-06-26 4:22 ` H. Peter Anvin
[not found] ` <200306240051.RAA12097@cesium.transmeta.com>
2003-06-26 19:09 ` Samphan Raruenrom
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).