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.
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
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?
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?
>
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
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
>
>
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
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" ? ;)
> 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.
Would it be possible, (with relevant documentation), to tune the code
morphing software for optimum performance of code generated by a
specific compiler, though?
If a particular version of GCC favours certain constructs and uses
particular sets of registers for a given piece of code, couldn't we
optimise for those cases, at the expense of others? Maybe a
particular compiler doesn't use certain X86 instructions at all, and
these could be eliminated altogether?
It's not unlikely that an entirely open source system could have all
code compiled with the same compiler, and so maybe we can use this to
avoid implementing expensive corner cases in the CPU, because we're
never going to trigger them.
John.
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?
Xavier Bestel <[email protected]> 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
[email protected] +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
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
John Bradford wrote:
>>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.
>
>
> Would it be possible, (with relevant documentation), to tune the code
> morphing software for optimum performance of code generated by a
> specific compiler, though?
>
> If a particular version of GCC favours certain constructs and uses
> particular sets of registers for a given piece of code, couldn't we
> optimise for those cases, at the expense of others? Maybe a
> particular compiler doesn't use certain X86 instructions at all, and
> these could be eliminated altogether?
>
> It's not unlikely that an entirely open source system could have all
> code compiled with the same compiler, and so maybe we can use this to
> avoid implementing expensive corner cases in the CPU, because we're
> never going to trigger them.
Hmm... basically you want to trim the x86 instruction set to get closer
to RISC mentality. Interesting. gcc may already do that to some extent
by not using the really complex instructions. If that is the case,
dropping those instructions might give some room for testing some of its
possible benefits. I doubt restricting the registers used by some
instructions would help... I've heard comments that the x86 is
register-starved enough already.
Have fun,
Eli
--------------------. "If it ain't broke now,
Eli Carter \ it will be soon." -- crypto-gram
eli.carter(a)inet.com `-------------------------------------------------
On Fri, Jun 20, 2003 at 11:49:22AM -0500, Eli Carter wrote:
> Hmm... basically you want to trim the x86 instruction set to get closer
> to RISC mentality. Interesting. gcc may already do that to some extent
> by not using the really complex instructions. If that is the case,
> dropping those instructions might give some room for testing some of its
> possible benefits. I doubt restricting the registers used by some
> instructions would help... I've heard comments that the x86 is
> register-starved enough already.
Newer CPUs do register renaming in an attempt to avoid the
register-starved ISA issue. I presume Xmeta would do something
similar...
Jeff
Hi, I'm having trouble running my dual AMD MP box in SMP mode. Runs fine in
single CPU mode, but when I enable either RedHat 9.0's stock SMP kernel or
my own brew, I don't have to wait long for crashes, oopses and other strange
behavior. I've tried 2.4.19, 2.4.20 and 2.4.21 with same results. I can run
SMP-enabled kernel with nosmp boot parameter just fine. Only SMP mode causes
trouble. I've been doing research on the web for days, tried mem=nopentium,
noapic, CONFIG_HIGHMEM4G and CONFIG_NOHIGHMEM.
Hardware:
Tyan S2466 motherboard
Two AMD MP 2000+ processors running at 1666MHz
ATI XPert 2000 Pro 32MB AGP video card
On-board 3Com 3c905C-TX ethernet controller
Promise SX6000 RAID controller, latest firmware, with 6 Maxtor 160GB drives
connected to it. Running Promise's driver compiled from source as module as
I couldn't get the i2o driver to cooperate.
1GB PC2100 Corsair DIMM
hda - 80 GB Maxtor drive
hdb - unused
hdc - Yamaha CDR/RW
hdd - open slot for another 80GB Maxtor
I will also put two Linksys Gigabit adaptors in the 64 bit slots once I
figure out what's going on with SMP.
I am experiencing unstability regardless of whether Promise module is
installed or not, so that's not the source of my problems.
I will need some hand-holding in producing documentation that might be
needed to troubleshoot this. Please be patient with me, I'm not really a
kernel hacker and only a wanna-be programmer :)
The log files attached below are from one of the few boot attempts where the
system booted far enough to save log entries to files.
What can I try next?
Artur
Here's my grub.conf so that you know what parameters I start the kernel
with:
title Red Hat Linux (2.4.20-030613a-smp)
root (hd0,0)
kernel /boot/vmlinuz-2.4.20-030613a-smp ro root=/dev/hda1 noapic nousb
hdc=ide-scsi ide2=noprobe ide3=noprobe ide4=noprobe ide5=noprobe
ide6=noprobe ide7=noprobe mem=nopentium
initrd /boot/initrd-2.4.20-030613a-smp.img
title Red Hat Linux (2.4.20-8smp)
root (hd0,0)
kernel /boot/vmlinuz-2.4.20-8smp ro root=/dev/hda1 hdc=ide-scsi noapic
initrd /boot/initrd-2.4.20-8smp.img
title Red Hat Linux-up (2.4.20-8)
root (hd0,0)
kernel /boot/vmlinuz-2.4.20-8 ro root=/dev/hda1 hdc=ide-scsi
initrd /boot/initrd-2.4.20-8.img
And here's a sample /var/log/messages file with a nice kernel crash followed
by a lockup after restart:
Jun 13 16:51:29 grail syslogd 1.4.1: restart.
Jun 13 16:51:29 grail syslog: syslogd startup succeeded
Jun 13 16:51:29 grail kernel: klogd 1.4.1, log source = /proc/kmsg started.
Jun 13 16:51:29 grail kernel: Linux version 2.4.20-030613a-smp (root@grail)
(gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #2 SMP Fri Jun 13
16:36:27 CDT 2003
Jun 13 16:51:29 grail kernel: BIOS-provided physical RAM map:
Jun 13 16:51:29 grail kernel: BIOS-e820: 0000000000000000 -
000000000009e400 (usable)
Jun 13 16:51:29 grail kernel: BIOS-e820: 000000000009e400 -
00000000000a0000 (reserved)
Jun 13 16:51:29 grail kernel: BIOS-e820: 00000000000ce000 -
0000000000100000 (reserved)
Jun 13 16:51:29 grail kernel: BIOS-e820: 0000000000100000 -
000000003ff80000 (usable)
Jun 13 16:51:29 grail kernel: BIOS-e820: 000000003ff80000 -
0000000040000000 (reserved)
Jun 13 16:51:29 grail kernel: BIOS-e820: 00000000fec00000 -
00000000fec04000 (reserved)
Jun 13 16:51:29 grail kernel: BIOS-e820: 00000000fee00000 -
00000000fee01000 (reserved)
Jun 13 16:51:29 grail kernel: BIOS-e820: 00000000fff80000 -
0000000100000000 (reserved)
Jun 13 16:51:29 grail kernel: 127MB HIGHMEM available.
Jun 13 16:51:29 grail kernel: 896MB LOWMEM available.
Jun 13 16:51:29 grail syslog: klogd startup succeeded
Jun 13 16:51:29 grail kernel: found SMP MP-table at 000f7170
Jun 13 16:51:29 grail kernel: hm, page 000f7000 reserved twice.
Jun 13 16:51:29 grail kernel: hm, page 000f8000 reserved twice.
Jun 13 16:51:29 grail kernel: hm, page 0009f000 reserved twice.
Jun 13 16:51:29 grail kernel: hm, page 000a0000 reserved twice.
Jun 13 16:51:29 grail kernel: On node 0 totalpages: 262016
Jun 13 16:51:29 grail kernel: zone(0): 4096 pages.
Jun 13 16:51:29 grail kernel: zone(1): 225280 pages.
Jun 13 16:51:29 grail kernel: zone(2): 32640 pages.
Jun 13 16:51:29 grail kernel: Intel MultiProcessor Specification v1.4
Jun 13 16:51:29 grail kernel: Virtual Wire compatibility mode.
Jun 13 16:51:29 grail kernel: OEM ID: TYAN Product ID: PAULANER APIC
at: 0xFEE00000
Jun 13 16:51:29 grail kernel: Processor #1 Pentium(tm) Pro APIC version 16
Jun 13 16:51:29 grail kernel: Processor #0 Pentium(tm) Pro APIC version 16
Jun 13 16:51:29 grail kernel: I/O APIC #2 Version 17 at 0xFEC00000.
Jun 13 16:51:29 grail kernel: Processors: 2
Jun 13 16:51:29 grail kernel: Kernel command line: ro root=/dev/hda1
hdc=ide-scsi
Jun 13 16:51:29 grail kernel: ide_setup: hdc=ide-scsi
Jun 13 16:51:29 grail kernel: Initializing CPU#0
Jun 13 16:51:29 grail kernel: Detected 1666.731 MHz processor.
Jun 13 16:51:29 grail kernel: Console: colour VGA+ 80x25
Jun 13 16:51:29 grail kernel: Calibrating delay loop... 3329.22 BogoMIPS
Jun 13 16:51:29 grail kernel: Memory: 1032756k/1048064k available (1293k
kernel code, 14916k reserved, 329k data, 308k init, 130560k highmem)
Jun 13 16:51:29 grail kernel: Dentry cache hash table entries: 131072
(order: 8, 1048576 bytes)
Jun 13 16:51:29 grail kernel: Inode cache hash table entries: 65536 (order:
7, 524288 bytes)
Jun 13 16:51:29 grail kernel: Mount-cache hash table entries: 16384 (order:
5, 131072 bytes)
Jun 13 16:51:29 grail kernel: Buffer-cache hash table entries: 65536 (order:
6, 262144 bytes)
Jun 13 16:51:29 grail kernel: Page-cache hash table entries: 262144 (order:
8, 1048576 bytes)
Jun 13 16:51:29 grail kernel: CPU: L1 I Cache: 64K (64 bytes/line), D cache
64K (64 bytes/line)
Jun 13 16:51:29 grail kernel: CPU: L2 Cache: 256K (64 bytes/line)
Jun 13 16:51:29 grail kernel: Intel machine check architecture supported.
Jun 13 16:51:29 grail kernel: Intel machine check reporting enabled on
CPU#0.
Jun 13 16:51:29 grail kernel: Enabling fast FPU save and restore... done.
Jun 13 16:51:29 grail kernel: Enabling unmasked SIMD FPU exception
support... done.
Jun 13 16:51:29 grail kernel: Checking 'hlt' instruction... OK.
Jun 13 16:51:29 grail kernel: POSIX conformance testing by UNIFIX
Jun 13 16:51:29 grail kernel: mtrr: v1.40 (20010327) Richard Gooch
([email protected])
Jun 13 16:51:29 grail kernel: mtrr: detected mtrr type: Intel
Jun 13 16:51:29 grail kernel: CPU: L1 I Cache: 64K (64 bytes/line), D cache
64K (64 bytes/line)
Jun 13 16:51:29 grail kernel: CPU: L2 Cache: 256K (64 bytes/line)
Jun 13 16:51:29 grail kernel: Intel machine check reporting enabled on
CPU#0.
Jun 13 16:51:29 grail kernel: CPU0: AMD Athlon(tm) MP 2000+ stepping 02
Jun 13 16:51:29 grail kernel: per-CPU timeslice cutoff: 731.44 usecs.
Jun 13 16:51:29 grail kernel: masked ExtINT on CPU#0
Jun 13 16:51:29 grail portmap: portmap startup succeeded
Jun 13 16:51:29 grail kernel: ESR value before enabling vector: 00000000
Jun 13 16:51:29 grail kernel: ESR value after enabling vector: 00000000
Jun 13 16:51:29 grail kernel: Booting processor 1/0 eip 2000
Jun 13 16:51:29 grail kernel: Initializing CPU#1
Jun 13 16:51:29 grail kernel: masked ExtINT on CPU#1
Jun 13 16:51:29 grail kernel: ESR value before enabling vector: 00000000
Jun 13 16:51:29 grail kernel: ESR value after enabling vector: 00000000
Jun 13 16:51:29 grail kernel: Calibrating delay loop... 3329.22 BogoMIPS
Jun 13 16:51:29 grail kernel: CPU: L1 I Cache: 64K (64 bytes/line), D cache
64K (64 bytes/line)
Jun 13 16:51:29 grail kernel: CPU: L2 Cache: 256K (64 bytes/line)
Jun 13 16:51:29 grail kernel: Intel machine check reporting enabled on
CPU#1.
Jun 13 16:51:29 grail kernel: CPU1: AMD Athlon(tm) Processor stepping 02
Jun 13 16:51:29 grail kernel: Total of 2 processors activated (6658.45
BogoMIPS).
Jun 13 16:51:29 grail kernel: ENABLING IO-APIC IRQs
Jun 13 16:51:29 grail kernel: Setting 2 in the phys_id_present_map
Jun 13 16:51:29 grail kernel: ...changing IO-APIC physical APIC ID to 2 ...
ok.
Jun 13 16:51:29 grail kernel: ..TIMER: vector=0x31 pin1=2 pin2=0
Jun 13 16:51:30 grail kernel: testing the IO APIC.......................
Jun 13 16:51:30 grail kernel:
Jun 13 16:51:30 grail kernel: .................................... done.
Jun 13 16:51:30 grail kernel: Using local APIC timer interrupts.
Jun 13 16:51:30 grail kernel: calibrating APIC timer ...
Jun 13 16:51:30 grail kernel: ..... CPU clock speed is 1666.8222 MHz.
Jun 13 16:51:30 grail kernel: ..... host bus clock speed is 266.6915 MHz.
Jun 13 16:51:30 grail kernel: cpu: 0, clocks: 2666915, slice: 888971
Jun 13 16:51:30 grail kernel:
CPU0<T0:2666912,T1:1777936,D:5,S:888971,C:2666915>
Jun 13 16:51:30 grail kernel: cpu: 1, clocks: 2666915, slice: 888971
Jun 13 16:51:30 grail kernel:
CPU1<T0:2666912,T1:888960,D:10,S:888971,C:2666915>
Jun 13 16:51:30 grail kernel: checking TSC synchronization across CPUs:
passed.
Jun 13 16:51:30 grail kernel: Waiting on wait_init_idle (map = 0x2)
Jun 13 16:51:30 grail kernel: All processors have done init_idle
Jun 13 16:51:30 grail rpc.statd[412]: Version 1.0.1 Starting
Jun 13 16:51:30 grail kernel: mtrr: your CPUs had inconsistent fixed MTRR
settings
Jun 13 16:51:30 grail nfslock: rpc.statd startup succeeded
Jun 13 16:51:30 grail kernel: mtrr: probably your BIOS does not setup all
CPUs
Jun 13 16:51:30 grail kernel: PCI: PCI BIOS revision 2.10 entry at 0xfd7d0,
last bus=3
Jun 13 16:51:30 grail kernel: PCI: Using configuration type 1
Jun 13 16:51:30 grail kernel: PCI: Probing PCI hardware
Jun 13 16:51:30 grail kernel: PCI->APIC IRQ transform: (B1,I5,P0) -> 18
Jun 13 16:51:30 grail kernel: PCI->APIC IRQ transform: (B2,I0,P3) -> 19
Jun 13 16:51:30 grail kernel: PCI->APIC IRQ transform: (B2,I5,P0) -> 17
Jun 13 16:51:30 grail kernel: PCI->APIC IRQ transform: (B2,I8,P0) -> 19
Jun 13 16:51:30 grail kernel: BIOS failed to enable PCI standards
compliance, fixing this error.
Jun 13 16:51:30 grail kernel: isapnp: Scanning for PnP cards...
Jun 13 16:51:30 grail kernel: isapnp: No Plug & Play device found
Jun 13 16:51:30 grail kernel: Linux NET4.0 for Linux 2.4
Jun 13 16:51:30 grail kernel: Based upon Swansea University Computer Society
NET3.039
Jun 13 16:51:30 grail kernel: Initializing RT netlink socket
Jun 13 16:51:30 grail kernel: apm: BIOS version 1.2 Flags 0x03 (Driver
version 1.16)
Jun 13 16:51:30 grail kernel: apm: disabled - APM is not SMP safe.
Jun 13 16:51:30 grail keytable: Loading keymap:
Jun 13 16:51:30 grail kernel: Starting kswapd
Jun 13 16:51:30 grail kernel: allocated 32 pages and 32 bhs reserved for the
highmem bounces
Jun 13 16:51:30 grail kernel: VFS: Diskquotas version dquot_6.4.0
initialized
Jun 13 16:51:30 grail kernel: Journalled Block Device driver loaded
Jun 13 16:51:30 grail kernel: pty: 2048 Unix98 ptys configured
Jun 13 16:51:30 grail kernel: Serial driver version 5.05c (2001-07-08) with
MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI ISAPNP enabled
Jun 13 16:51:30 grail kernel: ttyS00 at 0x03f8 (irq = 4) is a 16550A
Jun 13 16:51:30 grail kernel: ttyS01 at 0x02f8 (irq = 3) is a 16550A
Jun 13 16:51:30 grail kernel: Real Time Clock Driver v1.10e
Jun 13 16:51:30 grail kernel: Uniform Multi-Platform E-IDE driver Revision:
6.31
Jun 13 16:51:30 grail kernel: ide: Assuming 33MHz system bus speed for PIO
modes; override with idebus=xx
Jun 13 16:51:30 grail kernel: AMD7441: IDE controller on PCI bus 00 dev 39
Jun 13 16:51:30 grail keytable:
Jun 13 16:51:30 grail kernel: AMD7441: chipset revision 4
Jun 13 16:51:30 grail keytable: Loading system font:
Jun 13 16:51:30 grail kernel: AMD7441: not 100%% native mode: will probe
irqs later
Jun 13 16:51:30 grail kernel: AMD7441: disabling single-word DMA support
(revision < C4)
Jun 13 16:51:30 grail kernel: ide0: BM-DMA at 0xf000-0xf007, BIOS
settings: hda:DMA, hdb:pio
Jun 13 16:51:30 grail kernel: ide1: BM-DMA at 0xf008-0xf00f, BIOS
settings: hdc:DMA, hdd:DMA
Jun 13 16:51:30 grail kernel: hda: MAXTOR 6L080J4, ATA DISK drive
Jun 13 16:51:30 grail kernel: hdc: YAMAHA CRW2200E, ATAPI CD/DVD-ROM drive
Jun 13 16:51:30 grail kernel: hdd: MAXTOR 6L080J4, ATA DISK drive
Jun 13 16:51:30 grail kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Jun 13 16:51:30 grail kernel: ide1 at 0x170-0x177,0x376 on irq 15
Jun 13 16:51:30 grail keytable:
Jun 13 16:51:30 grail kernel: blk: queue c034cd64, I/O limit 4095Mb (mask
0xffffffff)
Jun 13 16:51:30 grail kernel: hda: 156355584 sectors (80054 MB) w/1819KiB
Cache, CHS=155114/16/63, UDMA(100)
Jun 13 16:51:30 grail rc: Starting keytable: succeeded
Jun 13 16:51:30 grail kernel: blk: queue c034d214, I/O limit 4095Mb (mask
0xffffffff)
Jun 13 16:51:30 grail kernel: hdd: 156355584 sectors (80054 MB) w/1819KiB
Cache, CHS=155114/16/63, UDMA(100)
Jun 13 16:51:30 grail kernel: Partition check:
Jun 13 16:51:30 grail kernel: hda: hda1 hda2 hda3 hda4 < hda5 hda6 >
Jun 13 16:51:30 grail kernel: hdd: hdd1 hdd2 hdd3 hdd4 < hdd5 hdd6 >
Jun 13 16:51:30 grail kernel: Floppy drive(s): fd0 is 1.44M
Jun 13 16:51:30 grail kernel: FDC 0 is a post-1991 82077
Jun 13 16:51:30 grail kernel: RAMDISK driver initialized: 16 RAM disks of
4096K size 1024 blocksize
Jun 13 16:51:30 grail kernel: md: md driver 0.90.0 MAX_MD_DEVS=256,
MD_SB_DISKS=27
Jun 13 16:51:30 grail kernel: md: Autodetecting RAID arrays.
Jun 13 16:51:30 grail kernel: md: autorun ...
Jun 13 16:51:30 grail kernel: md: ... autorun DONE.
Jun 13 16:51:30 grail kernel: NET4: Linux TCP/IP 1.0 for NET4.0
Jun 13 16:51:30 grail kernel: IP Protocols: ICMP, UDP, TCP
Jun 13 16:51:30 grail kernel: IP: routing cache hash table of 8192 buckets,
64Kbytes
Jun 13 16:51:30 grail kernel: TCP: Hash tables configured (established
262144 bind 65536)
Jun 13 16:51:30 grail kernel: NET4: Unix domain sockets 1.0/SMP for Linux
NET4.0.
Jun 13 16:51:30 grail kernel: RAMDISK: Compressed image found at block 0
Jun 13 16:51:30 grail kernel: Freeing initrd memory: 83k freed
Jun 13 16:51:30 grail kernel: VFS: Mounted root (ext2 filesystem).
Jun 13 16:51:30 grail kernel: kjournald starting. Commit interval 5 seconds
Jun 13 16:51:30 grail kernel: EXT3-fs: mounted filesystem with ordered data
mode.
Jun 13 16:51:30 grail kernel: Freeing unused kernel memory: 308k freed
Jun 13 16:51:30 grail kernel: usb.c: registered new driver usbdevfs
Jun 13 16:51:30 grail kernel: usb.c: registered new driver hub
Jun 13 16:51:30 grail kernel: usb-ohci.c: USB OHCI at membase 0xf8829000,
IRQ 19
Jun 13 16:51:30 grail kernel: usb-ohci.c: usb-02:00.0, Advanced Micro
Devices [AMD] AMD-768 [Opus] USB
Jun 13 16:51:30 grail kernel: usb.c: new USB bus registered, assigned bus
number 1
Jun 13 16:51:30 grail kernel: hub.c: USB hub found
Jun 13 16:51:30 grail kernel: hub.c: 4 ports detected
Jun 13 16:51:30 grail kernel: mice: PS/2 mouse device common for all mice
Jun 13 16:51:30 grail kernel: EXT3 FS 2.4-0.9.19, 19 August 2002 on
ide0(3,1), internal journal
Jun 13 16:51:30 grail random: Initializing random number generator:
succeeded
Jun 13 16:51:30 grail kernel: Adding Swap: 1048816k swap-space (priority -1)
Jun 13 16:51:30 grail kernel: kjournald starting. Commit interval 5 seconds
Jun 13 16:51:30 grail kernel: EXT3 FS 2.4-0.9.19, 19 August 2002 on
ide0(3,6), internal journal
Jun 13 16:51:30 grail kernel: EXT3-fs: mounted filesystem with ordered data
mode.
Jun 13 16:51:30 grail kernel: kjournald starting. Commit interval 5 seconds
Jun 13 16:51:30 grail kernel: EXT3 FS 2.4-0.9.19, 19 August 2002 on
ide0(3,5), internal journal
Jun 13 16:51:30 grail kernel: EXT3-fs: mounted filesystem with ordered data
mode.
Jun 13 16:51:30 grail kernel: kjournald starting. Commit interval 5 seconds
Jun 13 16:51:30 grail kernel: EXT3 FS 2.4-0.9.19, 19 August 2002 on
ide0(3,2), internal journal
Jun 13 16:51:30 grail kernel: EXT3-fs: mounted filesystem with ordered data
mode.
Jun 13 16:51:30 grail kernel: SCSI subsystem driver Revision: 1.00
Jun 13 16:51:30 grail kernel: scsi0 : SCSI host adapter emulation for IDE
ATAPI devices
Jun 13 16:51:30 grail kernel: Vendor: YAMAHA Model: CRW2200E
Rev: 1.0B
Jun 13 16:51:30 grail kernel: Type: CD-ROM
ANSI SCSI revision: 02
Jun 13 16:51:30 grail kernel: kernel BUG at page_alloc.c:100!
Jun 13 16:51:30 grail kernel: invalid operand: 0000
Jun 13 16:51:30 grail kernel: CPU: 0
Jun 13 16:51:30 grail kernel: EIP: 0010:[<c013b0c2>] Not tainted
Jun 13 16:51:30 grail kernel: EFLAGS: 00010282
Jun 13 16:51:30 grail kernel: eax: c1a847ac ebx: c1a84760 ecx: f7fe6270
edx: c1a842cc
Jun 13 16:51:30 grail kernel: esi: 000000b2 edi: 00000000 ebp: 000000b2
esp: f7861e3c
Jun 13 16:51:30 grail kernel: ds: 0018 es: 0018 ss: 0018
Jun 13 16:51:30 grail rc: Starting pcmcia: succeeded
Jun 13 16:51:30 grail kernel: Process initlog (pid: 13, stackpage=f7861000)
Jun 13 16:51:30 grail kernel: Stack: c0281038 c1000020 c1a84820 c0280fa8
c1a80020 00000217 fffffffc 00000030
Jun 13 16:51:30 grail kernel: 00000003 000000b2 08105000 000000b2
c012eb6f c1a84760 f7862080 08051000
Jun 13 16:51:30 grail kernel: 000b4000 08451000 c02f6800 000000b2
08105000 f7862084 f78d0ac0 f78d2e00
Jun 13 16:51:30 grail kernel: Call Trace: [<c012eb6f>] [<c0131b04>]
[<c011ce2b>] [<c012240c>] [<c0128fb3>]
Jun 13 16:51:30 grail kernel: [<c01291b5>] [<c0108ee2>] [<c01554df>]
[<c0154b7a>] [<c0155823>] [<c0109238>]
Jun 13 16:51:30 grail kernel:
Jun 13 16:51:30 grail kernel: Code: 0f 0b 64 00 74 29 25 c0 8b 53 08 85 d2
74 08 0f 0b 66 00 74
Jun 13 16:51:30 grail kernel: <6>parport0: PC-style at 0x378 (0x778)
[PCSPP,TRISTATE,EPP]
Jun 13 16:51:30 grail kernel: parport0: irq 7 detected
Jun 13 16:51:30 grail netfs: Mounting other filesystems: succeeded
Jun 13 16:51:30 grail autofs: automount startup succeeded
Jun 13 16:51:30 grail sshd: succeeded
Jun 13 16:51:29 grail sysctl: net.ipv4.ip_forward = 0
Jun 13 16:51:29 grail sysctl: net.ipv4.conf.default.rp_filter = 1
Jun 13 16:51:29 grail sysctl: kernel.sysrq = 0
Jun 13 16:51:29 grail sysctl: kernel.core_uses_pid = 1
Jun 13 16:51:29 grail network: Setting network parameters: succeeded
Jun 13 16:51:29 grail ifup: grep: relocation error: grep: symbol , version
GLIBC_2.0 not defined in file libc.so.6 with link time reference
Jun 13 16:51:29 grail ifup: grep: relocation error: grep: symbol , version
GLIBC_2.0 not defined in file libc.so.6 with link time reference
Jun 13 16:51:29 grail network: Bringing up loopback interface: succeeded
Jun 13 16:51:29 grail ifup: grep: relocation error: grep: symbol , version
GLIBC_2.0 not defined in file libc.so.6 with link time reference
Jun 13 16:51:29 grail network: Bringing up interface eth0: succeeded
Jun 13 16:51:32 grail xinetd[522]: xinetd Version 2.3.10 started with
libwrap options compiled in.
Jun 13 16:51:32 grail xinetd[522]: Started working: 1 available service
Jun 13 16:51:34 grail xinetd: xinetd startup succeeded
Jun 13 16:51:34 grail sendmail: sendmail startup succeeded
Jun 13 16:51:34 grail sendmail: sm-client startup succeeded
Jun 13 16:51:34 grail gpm: gpm startup succeeded
Jun 13 16:51:35 grail crond: crond startup succeeded
Jun 13 16:51:36 grail kernel: parport0: PC-style at 0x378 (0x778)
[PCSPP,TRISTATE,EPP]
Jun 13 16:51:36 grail kernel: parport0: irq 7 detected
Jun 13 16:51:36 grail kernel: lp0: using parport0 (polling).
Jun 13 16:51:36 grail kernel: lp0: console ready
Jun 13 16:51:36 grail modprobe: modprobe: Can't locate module char-major-188
Jun 13 16:51:36 grail last message repeated 15 times
Jun 13 16:51:37 grail cups: cupsd startup succeeded
Jun 13 16:51:37 grail xfs: xfs startup succeeded
Jun 13 16:51:37 grail anacron: anacron startup succeeded
Jun 13 16:51:37 grail atd: atd startup succeeded
Jun 13 16:51:37 grail xfs: ignoring font path element
/usr/X11R6/lib/X11/fonts/cyrillic (unreadable)
Jun 13 16:51:43 grail login(pam_unix)[668]: session opened for user root by
LOGIN(uid=0)
Jun 13 16:51:43 grail -- root[668]: ROOT LOGIN ON tty1
Jun 13 16:54:47 grail kernel: kjournald starting. Commit interval 5 seconds
Jun 13 16:54:47 grail kernel: EXT3 FS 2.4-0.9.19, 19 August 2002 on
ide1(22,65), internal journal
Jun 13 16:54:47 grail kernel: EXT3-fs: mounted filesystem with ordered data
mode.
Jun 13 16:56:29 grail shutdown: shutting down for system reboot
Jun 13 16:56:29 grail init: Switching to runlevel: 6
Jun 13 16:56:29 grail login(pam_unix)[668]: session closed for user root
Jun 13 16:56:30 grail atd: atd shutdown succeeded
Jun 13 16:56:30 grail init: no more processes left in this runlevel
Jun 13 16:56:40 grail shutdown: shutting down for system reboot
Jun 13 17:00:09 grail syslogd 1.4.1: restart.
Jun 13 17:00:09 grail syslog: syslogd startup succeeded
Jun 13 17:00:09 grail kernel: klogd 1.4.1, log source = /proc/kmsg started.
Jun 13 17:00:09 grail kernel: Linux version 2.4.20-030613a-smp (root@grail)
(gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #2 SMP Fri Jun 13
16:36:27 CDT 2003
Jun 13 17:00:09 grail kernel: BIOS-provided physical RAM map:
Jun 13 17:00:09 grail kernel: BIOS-e820: 0000000000000000 -
000000000009e400 (usable)
Jun 13 17:00:09 grail kernel: BIOS-e820: 000000000009e400 -
00000000000a0000 (reserved)
Jun 13 17:00:09 grail kernel: BIOS-e820: 00000000000ce000 -
0000000000100000 (reserved)
Jun 13 17:00:09 grail kernel: BIOS-e820: 0000000000100000 -
000000003ff80000 (usable)
Jun 13 17:00:09 grail kernel: BIOS-e820: 000000003ff80000 -
0000000040000000 (reserved)
Jun 13 17:00:09 grail kernel: BIOS-e820: 00000000fec00000 -
00000000fec04000 (reserved)
Jun 13 17:00:09 grail kernel: BIOS-e820: 00000000fee00000 -
00000000fee01000 (reserved)
Jun 13 17:00:09 grail kernel: BIOS-e820: 00000000fff80000 -
0000000100000000 (reserved)
Jun 13 17:00:09 grail kernel: 127MB HIGHMEM available.
Jun 13 17:00:09 grail kernel: 896MB LOWMEM available.
Jun 13 17:00:09 grail kernel: found SMP MP-table at 000f7170
Jun 13 17:00:09 grail kernel: hm, page 000f7000 reserved twice.
Jun 13 17:00:09 grail kernel: hm, page 000f8000 reserved twice.
Jun 13 17:00:09 grail syslog: klogd startup succeeded
Jun 13 17:00:09 grail kernel: hm, page 0009f000 reserved twice.
Jun 13 17:00:09 grail kernel: hm, page 000a0000 reserved twice.
Jun 13 17:00:09 grail kernel: On node 0 totalpages: 262016
Jun 13 17:00:09 grail kernel: zone(0): 4096 pages.
Jun 13 17:00:09 grail kernel: zone(1): 225280 pages.
Jun 13 17:00:09 grail kernel: zone(2): 32640 pages.
Jun 13 17:00:09 grail kernel: Intel MultiProcessor Specification v1.4
Jun 13 17:00:09 grail kernel: Virtual Wire compatibility mode.
Jun 13 17:00:09 grail kernel: OEM ID: TYAN Product ID: PAULANER APIC
at: 0xFEE00000
Jun 13 17:00:09 grail kernel: Processor #1 Pentium(tm) Pro APIC version 16
Jun 13 17:00:09 grail kernel: Processor #0 Pentium(tm) Pro APIC version 16
Jun 13 17:00:09 grail kernel: I/O APIC #2 Version 17 at 0xFEC00000.
Jun 13 17:00:09 grail kernel: Processors: 2
Jun 13 17:00:09 grail kernel: Kernel command line: ro root=/dev/hda1
mem=nopentium noapic nousb hdc=ide-scsi ide2=noprobe ide3=noprobe
ide4=noprobe ide5=noprobe ide6=noprobe ide7=noprobe
Jun 13 17:00:09 grail kernel: ide_setup: hdc=ide-scsi
Jun 13 17:00:09 grail kernel: ide_setup: ide2=noprobe
Jun 13 17:00:09 grail kernel: ide_setup: ide3=noprobe
Jun 13 17:00:09 grail kernel: ide_setup: ide4=noprobe
Jun 13 17:00:09 grail kernel: ide_setup: ide5=noprobe
Jun 13 17:00:09 grail kernel: ide_setup: ide6=noprobe
Jun 13 17:00:09 grail kernel: ide_setup: ide7=noprobe
Jun 13 17:00:09 grail kernel: Initializing CPU#0
Jun 13 17:00:09 grail kernel: Detected 1666.763 MHz processor.
Jun 13 17:00:09 grail kernel: Console: colour VGA+ 80x25
Jun 13 17:00:09 grail kernel: Calibrating delay loop... 3322.67 BogoMIPS
Jun 13 17:00:09 grail kernel: Memory: 1031860k/1048064k available (1293k
kernel code, 15812k reserved, 329k data, 308k init, 130560k highmem)
Jun 13 17:00:09 grail kernel: Checking if this processor honours the WP bit
even in supervisor mode... Ok.
Jun 13 17:00:09 grail kernel: Dentry cache hash table entries: 131072
(order: 8, 1048576 bytes)
Jun 13 17:00:09 grail kernel: Inode cache hash table entries: 65536 (order:
7, 524288 bytes)
Jun 13 17:00:09 grail kernel: Mount-cache hash table entries: 16384 (order:
5, 131072 bytes)
Jun 13 17:00:09 grail kernel: Buffer-cache hash table entries: 65536 (order:
6, 262144 bytes)
Jun 13 17:00:09 grail kernel: Page-cache hash table entries: 262144 (order:
8, 1048576 bytes)
Jun 13 17:00:09 grail kernel: CPU: L1 I Cache: 64K (64 bytes/line), D cache
64K (64 bytes/line)
Jun 13 17:00:09 grail kernel: CPU: L2 Cache: 256K (64 bytes/line)
Jun 13 17:00:09 grail kernel: Intel machine check architecture supported.
Jun 13 17:00:09 grail kernel: Intel machine check reporting enabled on
CPU#0.
Jun 13 17:00:09 grail kernel: Enabling fast FPU save and restore... done.
Jun 13 17:00:09 grail kernel: Enabling unmasked SIMD FPU exception
support... done.
Jun 13 17:00:09 grail kernel: Checking 'hlt' instruction... OK.
Jun 13 17:00:09 grail kernel: POSIX conformance testing by UNIFIX
Jun 13 17:00:09 grail kernel: mtrr: v1.40 (20010327) Richard Gooch
([email protected])
Jun 13 17:00:09 grail kernel: mtrr: detected mtrr type: Intel
Jun 13 17:00:09 grail kernel: CPU: L1 I Cache: 64K (64 bytes/line), D cache
64K (64 bytes/line)
Jun 13 17:00:09 grail portmap: portmap startup succeeded
Jun 13 17:00:09 grail kernel: CPU: L2 Cache: 256K (64 bytes/line)
Jun 13 17:00:09 grail kernel: Intel machine check reporting enabled on
CPU#0.
Jun 13 17:00:09 grail kernel: CPU0: AMD Athlon(tm) MP 2000+ stepping 02
Jun 13 17:00:09 grail kernel: per-CPU timeslice cutoff: 731.44 usecs.
Jun 13 17:00:09 grail kernel: masked ExtINT on CPU#0
Jun 13 17:00:09 grail kernel: ESR value before enabling vector: 00000000
Jun 13 17:00:09 grail kernel: ESR value after enabling vector: 00000000
Jun 13 17:00:09 grail kernel: Booting processor 1/0 eip 2000
Jun 13 17:00:09 grail kernel: Initializing CPU#1
Jun 13 17:00:09 grail kernel: masked ExtINT on CPU#1
Jun 13 17:00:09 grail kernel: ESR value before enabling vector: 00000000
Jun 13 17:00:09 grail kernel: ESR value after enabling vector: 00000000
Jun 13 17:00:09 grail kernel: Calibrating delay loop... 3329.22 BogoMIPS
Jun 13 17:00:09 grail kernel: CPU: L1 I Cache: 64K (64 bytes/line), D cache
64K (64 bytes/line)
Jun 13 17:00:09 grail kernel: CPU: L2 Cache: 256K (64 bytes/line)
Jun 13 17:00:09 grail kernel: Intel machine check reporting enabled on
CPU#1.
Jun 13 17:00:09 grail kernel: CPU1: AMD Athlon(tm) Processor stepping 02
Jun 13 17:00:09 grail kernel: Total of 2 processors activated (6651.90
BogoMIPS).
Jun 13 17:00:09 grail kernel: Using local APIC timer interrupts.
Jun 13 17:00:09 grail kernel: calibrating APIC timer ...
Jun 13 17:00:09 grail kernel: ..... CPU clock speed is 1666.8537 MHz.
Jun 13 17:00:09 grail kernel: ..... host bus clock speed is 266.6966 MHz.
Jun 13 17:00:09 grail kernel: cpu: 0, clocks: 2666966, slice: 888988
Jun 13 17:00:09 grail kernel:
CPU0<T0:2666960,T1:1777968,D:4,S:888988,C:2666966>
Jun 13 17:00:09 grail kernel: cpu: 1, clocks: 2666966, slice: 888988
Jun 13 17:00:09 grail kernel:
CPU1<T0:2666960,T1:888976,D:8,S:888988,C:2666966>
Jun 13 17:00:09 grail kernel: checking TSC synchronization across CPUs:
passed.
Jun 13 17:00:09 grail kernel: Waiting on wait_init_idle (map = 0x2)
Jun 13 17:00:09 grail kernel: All processors have done init_idle
Jun 13 17:00:09 grail kernel: mtrr: your CPUs had inconsistent fixed MTRR
settings
Jun 13 17:00:09 grail kernel: mtrr: probably your BIOS does not setup all
CPUs
Jun 13 17:00:09 grail kernel: PCI: PCI BIOS revision 2.10 entry at 0xfd7d0,
last bus=3
Jun 13 17:00:09 grail kernel: PCI: Using configuration type 1
Jun 13 17:00:09 grail kernel: PCI: Probing PCI hardware
Jun 13 17:00:09 grail kernel: BIOS failed to enable PCI standards
compliance, fixing this error.
Jun 13 17:00:09 grail kernel: isapnp: Scanning for PnP cards...
Jun 13 17:00:09 grail rpc.statd[459]: Version 1.0.1 Starting
Jun 13 17:00:09 grail kernel: isapnp: No Plug & Play device found
Jun 13 17:00:09 grail nfslock: rpc.statd startup succeeded
Jun 13 17:00:09 grail kernel: Linux NET4.0 for Linux 2.4
Jun 13 17:00:09 grail kernel: Based upon Swansea University Computer Society
NET3.039
Jun 13 17:00:09 grail kernel: Initializing RT netlink socket
Jun 13 17:00:09 grail kernel: apm: BIOS version 1.2 Flags 0x03 (Driver
version 1.16)
Jun 13 17:00:09 grail kernel: apm: disabled - APM is not SMP safe.
Jun 13 17:00:09 grail kernel: Starting kswapd
Jun 13 17:00:09 grail kernel: allocated 32 pages and 32 bhs reserved for the
highmem bounces
Jun 13 17:00:09 grail kernel: VFS: Diskquotas version dquot_6.4.0
initialized
Jun 13 17:00:09 grail kernel: Journalled Block Device driver loaded
Jun 13 17:00:09 grail kernel: pty: 2048 Unix98 ptys configured
Jun 13 17:00:09 grail kernel: Serial driver version 5.05c (2001-07-08) with
MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI ISAPNP enabled
Jun 13 17:00:09 grail kernel: ttyS00 at 0x03f8 (irq = 4) is a 16550A
Jun 13 17:00:09 grail kernel: ttyS01 at 0x02f8 (irq = 3) is a 16550A
Jun 13 17:00:09 grail kernel: Real Time Clock Driver v1.10e
Jun 13 17:00:09 grail kernel: Uniform Multi-Platform E-IDE driver Revision:
6.31
Jun 13 17:00:09 grail kernel: ide: Assuming 33MHz system bus speed for PIO
modes; override with idebus=xx
Jun 13 17:00:09 grail kernel: AMD7441: IDE controller on PCI bus 00 dev 39
Jun 13 17:00:09 grail kernel: AMD7441: chipset revision 4
Jun 13 17:00:09 grail keytable: Loading keymap:
Jun 13 17:00:09 grail kernel: AMD7441: not 100%% native mode: will probe
irqs later
Jun 13 17:00:09 grail kernel: AMD7441: disabling single-word DMA support
(revision < C4)
Jun 13 17:00:09 grail kernel: ide0: BM-DMA at 0xf000-0xf007, BIOS
settings: hda:DMA, hdb:pio
Jun 13 17:00:09 grail kernel: ide1: BM-DMA at 0xf008-0xf00f, BIOS
settings: hdc:DMA, hdd:pio
Jun 13 17:00:09 grail kernel: hda: MAXTOR 6L080J4, ATA DISK drive
Jun 13 17:00:09 grail kernel: hdc: YAMAHA CRW2200E, ATAPI CD/DVD-ROM drive
Jun 13 17:00:09 grail kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Jun 13 17:00:09 grail kernel: ide1 at 0x170-0x177,0x376 on irq 15
Jun 13 17:00:09 grail kernel: blk: queue c034cd64, I/O limit 4095Mb (mask
0xffffffff)
Jun 13 17:00:09 grail kernel: hda: 156355584 sectors (80054 MB) w/1819KiB
Cache, CHS=155114/16/63, UDMA(100)
Jun 13 17:00:09 grail kernel: Partition check:
Jun 13 17:00:09 grail kernel: hda: hda1 hda2 hda3 hda4 < hda5 hda6 >
Jun 13 17:00:09 grail keytable:
Jun 13 17:00:09 grail kernel: Floppy drive(s): fd0 is 1.44M
Jun 13 17:00:09 grail keytable: Loading system font:
Jun 13 17:00:09 grail kernel: FDC 0 is a post-1991 82077
Jun 13 17:00:09 grail kernel: RAMDISK driver initialized: 16 RAM disks of
4096K size 1024 blocksize
Jun 13 17:00:09 grail kernel: md: md driver 0.90.0 MAX_MD_DEVS=256,
MD_SB_DISKS=27
Jun 13 17:00:09 grail kernel: md: Autodetecting RAID arrays.
Jun 13 17:00:09 grail kernel: md: autorun ...
Jun 13 17:00:09 grail kernel: md: ... autorun DONE.
Jun 13 17:00:09 grail kernel: NET4: Linux TCP/IP 1.0 for NET4.0
Jun 13 17:00:09 grail kernel: IP Protocols: ICMP, UDP, TCP
Jun 13 17:00:09 grail kernel: IP: routing cache hash table of 8192 buckets,
64Kbytes
Jun 13 17:00:09 grail kernel: TCP: Hash tables configured (established
262144 bind 65536)
Jun 13 17:00:09 grail keytable:
Jun 13 17:00:09 grail kernel: NET4: Unix domain sockets 1.0/SMP for Linux
NET4.0.
Jun 13 17:00:09 grail rc: Starting keytable: succeeded
Jun 13 17:00:09 grail kernel: RAMDISK: Compressed image found at block 0
Jun 13 17:00:09 grail kernel: Freeing initrd memory: 83k freed
Jun 13 17:00:09 grail kernel: VFS: Mounted root (ext2 filesystem).
Jun 13 17:00:09 grail kernel: kjournald starting. Commit interval 5 seconds
Jun 13 17:00:09 grail kernel: EXT3-fs: mounted filesystem with ordered data
mode.
Jun 13 17:00:09 grail kernel: Freeing unused kernel memory: 308k freed
Jun 13 17:00:09 grail kernel: EXT3 FS 2.4-0.9.19, 19 August 2002 on
ide0(3,1), internal journal
Jun 13 17:00:09 grail kernel: Adding Swap: 1048816k swap-space (priority -1)
Jun 13 17:00:09 grail kernel: kjournald starting. Commit interval 5 seconds
Jun 13 17:00:09 grail kernel: EXT3 FS 2.4-0.9.19, 19 August 2002 on
ide0(3,6), internal journal
Jun 13 17:00:09 grail kernel: EXT3-fs: mounted filesystem with ordered data
mode.
Jun 13 17:00:09 grail kernel: kjournald starting. Commit interval 5 seconds
Jun 13 17:00:09 grail kernel: EXT3 FS 2.4-0.9.19, 19 August 2002 on
ide0(3,5), internal journal
Jun 13 17:00:09 grail kernel: EXT3-fs: mounted filesystem with ordered data
mode.
Jun 13 17:00:09 grail kernel: kjournald starting. Commit interval 5 seconds
Jun 13 17:00:10 grail kernel: EXT3 FS 2.4-0.9.19, 19 August 2002 on
ide0(3,2), internal journal
Jun 13 17:00:10 grail kernel: EXT3-fs: mounted filesystem with ordered data
mode.
Jun 13 17:00:10 grail kernel: SCSI subsystem driver Revision: 1.00
Jun 13 17:00:10 grail kernel: scsi0 : SCSI host adapter emulation for IDE
ATAPI devices
Jun 13 17:00:10 grail kernel: Vendor: YAMAHA Model: CRW2200E
Rev: 1.0B
Jun 13 17:00:10 grail kernel: Type: CD-ROM
ANSI SCSI revision: 02
Jun 13 17:00:10 grail kernel: usb.c: registered new driver usbdevfs
Jun 13 17:00:10 grail kernel: usb.c: registered new driver hub
Jun 13 17:00:10 grail kernel: usb-ohci.c: USB OHCI at membase 0xf88df000,
IRQ 10
Jun 13 17:00:10 grail kernel: usb-ohci.c: usb-02:00.0, Advanced Micro
Devices [AMD] AMD-768 [Opus] USB
Jun 13 17:00:10 grail kernel: usb.c: new USB bus registered, assigned bus
number 1
Jun 13 17:00:10 grail kernel: hub.c: USB hub found
Jun 13 17:00:10 grail kernel: hub.c: 4 ports detected
Jun 13 17:00:10 grail kernel: usb.c: USB disconnect on device 02:00.0-0
address 1
Jun 13 17:00:10 grail random: Initializing random number generator:
succeeded
Jun 13 17:00:10 grail kernel: usb.c: USB bus 1 deregistered
Jun 13 17:00:10 grail kernel: usb.c: deregistering driver usbdevfs
Jun 13 17:00:10 grail kernel: usb.c: deregistering driver hub
Jun 13 17:00:10 grail kernel: parport0: PC-style at 0x378 (0x778)
[PCSPP,TRISTATE,EPP]
Jun 13 17:00:10 grail kernel: parport0: irq 7 detected
Jun 13 17:00:10 grail kernel: Attached scsi CD-ROM sr0 at scsi0, channel 0,
id 0, lun 0
Jun 13 17:00:10 grail kernel: sr0: scsi3-mmc drive: 40x/40x writer cd/rw
xa/form2 cdda tray
Jun 13 17:00:10 grail kernel: Uniform CD-ROM driver Revision: 3.12
Jun 13 17:00:10 grail kernel: 3c59x: Donald Becker and others.
http://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]
.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
> ([email protected])
> Jun 13 16:51:29 grail kernel: mtrr: detected mtrr type: Intel
> Jun 13 16:51:29 grail kernel: CPU: L1 I Cache: 64K (64 bytes/line), D cache
> 64K (64 bytes/line)
> Jun 13 16:51:29 grail kernel: CPU: L2 Cache: 256K (64 bytes/line)
> Jun 13 16:51:29 grail kernel: Intel machine check reporting enabled on
> CPU#0.
> Jun 13 16:51:29 grail kernel: CPU0: AMD Athlon(tm) MP 2000+ stepping 02
> Jun 13 16:51:29 grail kernel: per-CPU timeslice cutoff: 731.44 usecs.
> Jun 13 16:51:29 grail kernel: masked ExtINT on CPU#0
> Jun 13 16:51:29 grail portmap: portmap startup succeeded
> Jun 13 16:51:29 grail kernel: ESR value before enabling vector: 00000000
> Jun 13 16:51:29 grail kernel: ESR value after enabling vector: 00000000
> Jun 13 16:51:29 grail kernel: Booting processor 1/0 eip 2000
> Jun 13 16:51:29 grail kernel: Initializing CPU#1
> Jun 13 16:51:29 grail kernel: masked ExtINT on CPU#1
> Jun 13 16:51:29 grail kernel: ESR value before enabling vector: 00000000
> Jun 13 16:51:29 grail kernel: ESR value after enabling vector: 00000000
> Jun 13 16:51:29 grail kernel: Calibrating delay loop... 3329.22 BogoMIPS
> Jun 13 16:51:29 grail kernel: CPU: L1 I Cache: 64K (64 bytes/line), D cache
> 64K (64 bytes/line)
> Jun 13 16:51:29 grail kernel: CPU: L2 Cache: 256K (64 bytes/line)
> Jun 13 16:51:29 grail kernel: Intel machine check reporting enabled on
> CPU#1.
> Jun 13 16:51:29 grail kernel: CPU1: AMD Athlon(tm) Processor stepping 02
> Jun 13 16:51:29 grail kernel: Total of 2 processors activated (6658.45
> BogoMIPS).
> Jun 13 16:51:29 grail kernel: ENABLING IO-APIC IRQs
> Jun 13 16:51:29 grail kernel: Setting 2 in the phys_id_present_map
> Jun 13 16:51:29 grail kernel: ...changing IO-APIC physical APIC ID to 2 ...
> ok.
> Jun 13 16:51:29 grail kernel: ..TIMER: vector=0x31 pin1=2 pin2=0
> Jun 13 16:51:30 grail kernel: testing the IO APIC.......................
> Jun 13 16:51:30 grail kernel:
> Jun 13 16:51:30 grail kernel: .................................... done.
> Jun 13 16:51:30 grail kernel: Using local APIC timer interrupts.
> Jun 13 16:51:30 grail kernel: calibrating APIC timer ...
> Jun 13 16:51:30 grail kernel: ..... CPU clock speed is 1666.8222 MHz.
> Jun 13 16:51:30 grail kernel: ..... host bus clock speed is 266.6915 MHz.
> Jun 13 16:51:30 grail kernel: cpu: 0, clocks: 2666915, slice: 888971
> Jun 13 16:51:30 grail kernel:
> CPU0<T0:2666912,T1:1777936,D:5,S:888971,C:2666915>
> Jun 13 16:51:30 grail kernel: cpu: 1, clocks: 2666915, slice: 888971
> Jun 13 16:51:30 grail kernel:
> CPU1<T0:2666912,T1:888960,D:10,S:888971,C:2666915>
> Jun 13 16:51:30 grail kernel: checking TSC synchronization across CPUs:
> passed.
> Jun 13 16:51:30 grail kernel: Waiting on wait_init_idle (map = 0x2)
> Jun 13 16:51:30 grail kernel: All processors have done init_idle
> Jun 13 16:51:30 grail rpc.statd[412]: Version 1.0.1 Starting
> Jun 13 16:51:30 grail kernel: mtrr: your CPUs had inconsistent fixed MTRR
> settings
> Jun 13 16:51:30 grail nfslock: rpc.statd startup succeeded
> Jun 13 16:51:30 grail kernel: mtrr: probably your BIOS does not setup all
> CPUs
> Jun 13 16:51:30 grail kernel: PCI: PCI BIOS revision 2.10 entry at 0xfd7d0,
> last bus=3
> Jun 13 16:51:30 grail kernel: PCI: Using configuration type 1
> Jun 13 16:51:30 grail kernel: PCI: Probing PCI hardware
> Jun 13 16:51:30 grail kernel: PCI->APIC IRQ transform: (B1,I5,P0) -> 18
> Jun 13 16:51:30 grail kernel: PCI->APIC IRQ transform: (B2,I0,P3) -> 19
> Jun 13 16:51:30 grail kernel: PCI->APIC IRQ transform: (B2,I5,P0) -> 17
> Jun 13 16:51:30 grail kernel: PCI->APIC IRQ transform: (B2,I8,P0) -> 19
> Jun 13 16:51:30 grail kernel: BIOS failed to enable PCI standards
> compliance, fixing this error.
> Jun 13 16:51:30 grail kernel: isapnp: Scanning for PnP cards...
> Jun 13 16:51:30 grail kernel: isapnp: No Plug & Play device found
> Jun 13 16:51:30 grail kernel: Linux NET4.0 for Linux 2.4
> Jun 13 16:51:30 grail kernel: Based upon Swansea University Computer
> Society NET3.039
> Jun 13 16:51:30 grail kernel: Initializing RT netlink socket
> Jun 13 16:51:30 grail kernel: apm: BIOS version 1.2 Flags 0x03 (Driver
> version 1.16)
> Jun 13 16:51:30 grail kernel: apm: disabled - APM is not SMP safe.
> Jun 13 16:51:30 grail keytable: Loading keymap:
> Jun 13 16:51:30 grail kernel: Starting kswapd
> Jun 13 16:51:30 grail kernel: allocated 32 pages and 32 bhs reserved for
> the highmem bounces
> Jun 13 16:51:30 grail kernel: VFS: Diskquotas version dquot_6.4.0
> initialized
> Jun 13 16:51:30 grail kernel: Journalled Block Device driver loaded
> Jun 13 16:51:30 grail kernel: pty: 2048 Unix98 ptys configured
> Jun 13 16:51:30 grail kernel: Serial driver version 5.05c (2001-07-08) with
> MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI ISAPNP enabled
> Jun 13 16:51:30 grail kernel: ttyS00 at 0x03f8 (irq = 4) is a 16550A
> Jun 13 16:51:30 grail kernel: ttyS01 at 0x02f8 (irq = 3) is a 16550A
> Jun 13 16:51:30 grail kernel: Real Time Clock Driver v1.10e
> Jun 13 16:51:30 grail kernel: Uniform Multi-Platform E-IDE driver Revision:
> 6.31
> Jun 13 16:51:30 grail kernel: ide: Assuming 33MHz system bus speed for PIO
> modes; override with idebus=xx
> Jun 13 16:51:30 grail kernel: AMD7441: IDE controller on PCI bus 00 dev 39
> Jun 13 16:51:30 grail keytable:
> Jun 13 16:51:30 grail kernel: AMD7441: chipset revision 4
> Jun 13 16:51:30 grail keytable: Loading system font:
> Jun 13 16:51:30 grail kernel: AMD7441: not 100%% native mode: will probe
> irqs later
> Jun 13 16:51:30 grail kernel: AMD7441: disabling single-word DMA support
> (revision < C4)
> Jun 13 16:51:30 grail kernel: ide0: BM-DMA at 0xf000-0xf007, BIOS
> settings: hda:DMA, hdb:pio
> Jun 13 16:51:30 grail kernel: ide1: BM-DMA at 0xf008-0xf00f, BIOS
> settings: hdc:DMA, hdd:DMA
> Jun 13 16:51:30 grail kernel: hda: MAXTOR 6L080J4, ATA DISK drive
> Jun 13 16:51:30 grail kernel: hdc: YAMAHA CRW2200E, ATAPI CD/DVD-ROM drive
> Jun 13 16:51:30 grail kernel: hdd: MAXTOR 6L080J4, ATA DISK drive
> Jun 13 16:51:30 grail kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> Jun 13 16:51:30 grail kernel: ide1 at 0x170-0x177,0x376 on irq 15
> Jun 13 16:51:30 grail keytable:
> Jun 13 16:51:30 grail kernel: blk: queue c034cd64, I/O limit 4095Mb (mask
> 0xffffffff)
> Jun 13 16:51:30 grail kernel: hda: 156355584 sectors (80054 MB) w/1819KiB
> Cache, CHS=155114/16/63, UDMA(100)
> Jun 13 16:51:30 grail rc: Starting keytable: succeeded
> Jun 13 16:51:30 grail kernel: blk: queue c034d214, I/O limit 4095Mb (mask
> 0xffffffff)
> Jun 13 16:51:30 grail kernel: hdd: 156355584 sectors (80054 MB) w/1819KiB
> Cache, CHS=155114/16/63, UDMA(100)
> Jun 13 16:51:30 grail kernel: Partition check:
> Jun 13 16:51:30 grail kernel: hda: hda1 hda2 hda3 hda4 < hda5 hda6 >
> Jun 13 16:51:30 grail kernel: hdd: hdd1 hdd2 hdd3 hdd4 < hdd5 hdd6 >
> Jun 13 16:51:30 grail kernel: Floppy drive(s): fd0 is 1.44M
> Jun 13 16:51:30 grail kernel: FDC 0 is a post-1991 82077
> Jun 13 16:51:30 grail kernel: RAMDISK driver initialized: 16 RAM disks of
> 4096K size 1024 blocksize
> Jun 13 16:51:30 grail kernel: md: md driver 0.90.0 MAX_MD_DEVS=256,
> MD_SB_DISKS=27
> Jun 13 16:51:30 grail kernel: md: Autodetecting RAID arrays.
> Jun 13 16:51:30 grail kernel: md: autorun ...
> Jun 13 16:51:30 grail kernel: md: ... autorun DONE.
> Jun 13 16:51:30 grail kernel: NET4: Linux TCP/IP 1.0 for NET4.0
> Jun 13 16:51:30 grail kernel: IP Protocols: ICMP, UDP, TCP
> Jun 13 16:51:30 grail kernel: IP: routing cache hash table of 8192 buckets,
> 64Kbytes
> Jun 13 16:51:30 grail kernel: TCP: Hash tables configured (established
> 262144 bind 65536)
> Jun 13 16:51:30 grail kernel: NET4: Unix domain sockets 1.0/SMP for Linux
> NET4.0.
> Jun 13 16:51:30 grail kernel: RAMDISK: Compressed image found at block 0
> Jun 13 16:51:30 grail kernel: Freeing initrd memory: 83k freed
> Jun 13 16:51:30 grail kernel: VFS: Mounted root (ext2 filesystem).
> Jun 13 16:51:30 grail kernel: kjournald starting. Commit interval 5
> seconds Jun 13 16:51:30 grail kernel: EXT3-fs: mounted filesystem with
> ordered data mode.
> Jun 13 16:51:30 grail kernel: Freeing unused kernel memory: 308k freed
> Jun 13 16:51:30 grail kernel: usb.c: registered new driver usbdevfs
> Jun 13 16:51:30 grail kernel: usb.c: registered new driver hub
> Jun 13 16:51:30 grail kernel: usb-ohci.c: USB OHCI at membase 0xf8829000,
> IRQ 19
> Jun 13 16:51:30 grail kernel: usb-ohci.c: usb-02:00.0, Advanced Micro
> Devices [AMD] AMD-768 [Opus] USB
> Jun 13 16:51:30 grail kernel: usb.c: new USB bus registered, assigned bus
> number 1
> Jun 13 16:51:30 grail kernel: hub.c: USB hub found
> Jun 13 16:51:30 grail kernel: hub.c: 4 ports detected
> Jun 13 16:51:30 grail kernel: mice: PS/2 mouse device common for all mice
> Jun 13 16:51:30 grail kernel: EXT3 FS 2.4-0.9.19, 19 August 2002 on
> ide0(3,1), internal journal
> Jun 13 16:51:30 grail random: Initializing random number generator:
> succeeded
> Jun 13 16:51:30 grail kernel: Adding Swap: 1048816k swap-space (priority
> -1) Jun 13 16:51:30 grail kernel: kjournald starting. Commit interval 5
> seconds Jun 13 16:51:30 grail kernel: EXT3 FS 2.4-0.9.19, 19 August 2002 on
> ide0(3,6), internal journal
> Jun 13 16:51:30 grail kernel: EXT3-fs: mounted filesystem with ordered data
> mode.
> Jun 13 16:51:30 grail kernel: kjournald starting. Commit interval 5
> seconds Jun 13 16:51:30 grail kernel: EXT3 FS 2.4-0.9.19, 19 August 2002 on
> ide0(3,5), internal journal
> Jun 13 16:51:30 grail kernel: EXT3-fs: mounted filesystem with ordered data
> mode.
> Jun 13 16:51:30 grail kernel: kjournald starting. Commit interval 5
> seconds Jun 13 16:51:30 grail kernel: EXT3 FS 2.4-0.9.19, 19 August 2002 on
> ide0(3,2), internal journal
> Jun 13 16:51:30 grail kernel: EXT3-fs: mounted filesystem with ordered data
> mode.
> Jun 13 16:51:30 grail kernel: SCSI subsystem driver Revision: 1.00
> Jun 13 16:51:30 grail kernel: scsi0 : SCSI host adapter emulation for IDE
> ATAPI devices
> Jun 13 16:51:30 grail kernel: Vendor: YAMAHA Model: CRW2200E
> Rev: 1.0B
> Jun 13 16:51:30 grail kernel: Type: CD-ROM
> ANSI SCSI revision: 02
> Jun 13 16:51:30 grail kernel: kernel BUG at page_alloc.c:100!
> Jun 13 16:51:30 grail kernel: invalid operand: 0000
> Jun 13 16:51:30 grail kernel: CPU: 0
> Jun 13 16:51:30 grail kernel: EIP: 0010:[<c013b0c2>] Not tainted
> Jun 13 16:51:30 grail kernel: EFLAGS: 00010282
> Jun 13 16:51:30 grail kernel: eax: c1a847ac ebx: c1a84760 ecx: f7fe6270
> edx: c1a842cc
> Jun 13 16:51:30 grail kernel: esi: 000000b2 edi: 00000000 ebp: 000000b2
> esp: f7861e3c
> Jun 13 16:51:30 grail kernel: ds: 0018 es: 0018 ss: 0018
> Jun 13 16:51:30 grail rc: Starting pcmcia: succeeded
> Jun 13 16:51:30 grail kernel: Process initlog (pid: 13, stackpage=f7861000)
> Jun 13 16:51:30 grail kernel: Stack: c0281038 c1000020 c1a84820 c0280fa8
> c1a80020 00000217 fffffffc 00000030
> Jun 13 16:51:30 grail kernel: 00000003 000000b2 08105000 000000b2
> c012eb6f c1a84760 f7862080 08051000
> Jun 13 16:51:30 grail kernel: 000b4000 08451000 c02f6800 000000b2
> 08105000 f7862084 f78d0ac0 f78d2e00
> Jun 13 16:51:30 grail kernel: Call Trace: [<c012eb6f>] [<c0131b04>]
> [<c011ce2b>] [<c012240c>] [<c0128fb3>]
> Jun 13 16:51:30 grail kernel: [<c01291b5>] [<c0108ee2>] [<c01554df>]
> [<c0154b7a>] [<c0155823>] [<c0109238>]
> Jun 13 16:51:30 grail kernel:
> Jun 13 16:51:30 grail kernel: Code: 0f 0b 64 00 74 29 25 c0 8b 53 08 85 d2
> 74 08 0f 0b 66 00 74
> Jun 13 16:51:30 grail kernel: <6>parport0: PC-style at 0x378 (0x778)
> [PCSPP,TRISTATE,EPP]
> Jun 13 16:51:30 grail kernel: parport0: irq 7 detected
> Jun 13 16:51:30 grail netfs: Mounting other filesystems: succeeded
> Jun 13 16:51:30 grail autofs: automount startup succeeded
> Jun 13 16:51:30 grail sshd: succeeded
> Jun 13 16:51:29 grail sysctl: net.ipv4.ip_forward = 0
> Jun 13 16:51:29 grail sysctl: net.ipv4.conf.default.rp_filter = 1
> Jun 13 16:51:29 grail sysctl: kernel.sysrq = 0
> Jun 13 16:51:29 grail sysctl: kernel.core_uses_pid = 1
> Jun 13 16:51:29 grail network: Setting network parameters: succeeded
> Jun 13 16:51:29 grail ifup: grep: relocation error: grep: symbol , version
> GLIBC_2.0 not defined in file libc.so.6 with link time reference
> Jun 13 16:51:29 grail ifup: grep: relocation error: grep: symbol , version
> GLIBC_2.0 not defined in file libc.so.6 with link time reference
> Jun 13 16:51:29 grail network: Bringing up loopback interface: succeeded
> Jun 13 16:51:29 grail ifup: grep: relocation error: grep: symbol , version
> GLIBC_2.0 not defined in file libc.so.6 with link time reference
> Jun 13 16:51:29 grail network: Bringing up interface eth0: succeeded
> Jun 13 16:51:32 grail xinetd[522]: xinetd Version 2.3.10 started with
> libwrap options compiled in.
> Jun 13 16:51:32 grail xinetd[522]: Started working: 1 available service
> Jun 13 16:51:34 grail xinetd: xinetd startup succeeded
> Jun 13 16:51:34 grail sendmail: sendmail startup succeeded
> Jun 13 16:51:34 grail sendmail: sm-client startup succeeded
> Jun 13 16:51:34 grail gpm: gpm startup succeeded
> Jun 13 16:51:35 grail crond: crond startup succeeded
> Jun 13 16:51:36 grail kernel: parport0: PC-style at 0x378 (0x778)
> [PCSPP,TRISTATE,EPP]
> Jun 13 16:51:36 grail kernel: parport0: irq 7 detected
> Jun 13 16:51:36 grail kernel: lp0: using parport0 (polling).
> Jun 13 16:51:36 grail kernel: lp0: console ready
> Jun 13 16:51:36 grail modprobe: modprobe: Can't locate module
> char-major-188 Jun 13 16:51:36 grail last message repeated 15 times
> Jun 13 16:51:37 grail cups: cupsd startup succeeded
> Jun 13 16:51:37 grail xfs: xfs startup succeeded
> Jun 13 16:51:37 grail anacron: anacron startup succeeded
> Jun 13 16:51:37 grail atd: atd startup succeeded
> Jun 13 16:51:37 grail xfs: ignoring font path element
> /usr/X11R6/lib/X11/fonts/cyrillic (unreadable)
> Jun 13 16:51:43 grail login(pam_unix)[668]: session opened for user root by
> LOGIN(uid=0)
> Jun 13 16:51:43 grail -- root[668]: ROOT LOGIN ON tty1
> Jun 13 16:54:47 grail kernel: kjournald starting. Commit interval 5
> seconds Jun 13 16:54:47 grail kernel: EXT3 FS 2.4-0.9.19, 19 August 2002 on
> ide1(22,65), internal journal
> Jun 13 16:54:47 grail kernel: EXT3-fs: mounted filesystem with ordered data
> mode.
> Jun 13 16:56:29 grail shutdown: shutting down for system reboot
> Jun 13 16:56:29 grail init: Switching to runlevel: 6
> Jun 13 16:56:29 grail login(pam_unix)[668]: session closed for user root
> Jun 13 16:56:30 grail atd: atd shutdown succeeded
> Jun 13 16:56:30 grail init: no more processes left in this runlevel
> Jun 13 16:56:40 grail shutdown: shutting down for system reboot
> Jun 13 17:00:09 grail syslogd 1.4.1: restart.
> Jun 13 17:00:09 grail syslog: syslogd startup succeeded
> Jun 13 17:00:09 grail kernel: klogd 1.4.1, log source = /proc/kmsg started.
> Jun 13 17:00:09 grail kernel: Linux version 2.4.20-030613a-smp (root@grail)
> (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #2 SMP Fri Jun 13
> 16:36:27 CDT 2003
> Jun 13 17:00:09 grail kernel: BIOS-provided physical RAM map:
> Jun 13 17:00:09 grail kernel: BIOS-e820: 0000000000000000 -
> 000000000009e400 (usable)
> Jun 13 17:00:09 grail kernel: BIOS-e820: 000000000009e400 -
> 00000000000a0000 (reserved)
> Jun 13 17:00:09 grail kernel: BIOS-e820: 00000000000ce000 -
> 0000000000100000 (reserved)
> Jun 13 17:00:09 grail kernel: BIOS-e820: 0000000000100000 -
> 000000003ff80000 (usable)
> Jun 13 17:00:09 grail kernel: BIOS-e820: 000000003ff80000 -
> 0000000040000000 (reserved)
> Jun 13 17:00:09 grail kernel: BIOS-e820: 00000000fec00000 -
> 00000000fec04000 (reserved)
> Jun 13 17:00:09 grail kernel: BIOS-e820: 00000000fee00000 -
> 00000000fee01000 (reserved)
> Jun 13 17:00:09 grail kernel: BIOS-e820: 00000000fff80000 -
> 0000000100000000 (reserved)
> Jun 13 17:00:09 grail kernel: 127MB HIGHMEM available.
> Jun 13 17:00:09 grail kernel: 896MB LOWMEM available.
> Jun 13 17:00:09 grail kernel: found SMP MP-table at 000f7170
> Jun 13 17:00:09 grail kernel: hm, page 000f7000 reserved twice.
> Jun 13 17:00:09 grail kernel: hm, page 000f8000 reserved twice.
> Jun 13 17:00:09 grail syslog: klogd startup succeeded
> Jun 13 17:00:09 grail kernel: hm, page 0009f000 reserved twice.
> Jun 13 17:00:09 grail kernel: hm, page 000a0000 reserved twice.
> Jun 13 17:00:09 grail kernel: On node 0 totalpages: 262016
> Jun 13 17:00:09 grail kernel: zone(0): 4096 pages.
> Jun 13 17:00:09 grail kernel: zone(1): 225280 pages.
> Jun 13 17:00:09 grail kernel: zone(2): 32640 pages.
> Jun 13 17:00:09 grail kernel: Intel MultiProcessor Specification v1.4
> Jun 13 17:00:09 grail kernel: Virtual Wire compatibility mode.
> Jun 13 17:00:09 grail kernel: OEM ID: TYAN Product ID: PAULANER
> APIC at: 0xFEE00000
> Jun 13 17:00:09 grail kernel: Processor #1 Pentium(tm) Pro APIC version 16
> Jun 13 17:00:09 grail kernel: Processor #0 Pentium(tm) Pro APIC version 16
> Jun 13 17:00:09 grail kernel: I/O APIC #2 Version 17 at 0xFEC00000.
> Jun 13 17:00:09 grail kernel: Processors: 2
> Jun 13 17:00:09 grail kernel: Kernel command line: ro root=/dev/hda1
> mem=nopentium noapic nousb hdc=ide-scsi ide2=noprobe ide3=noprobe
> ide4=noprobe ide5=noprobe ide6=noprobe ide7=noprobe
> Jun 13 17:00:09 grail kernel: ide_setup: hdc=ide-scsi
> Jun 13 17:00:09 grail kernel: ide_setup: ide2=noprobe
> Jun 13 17:00:09 grail kernel: ide_setup: ide3=noprobe
> Jun 13 17:00:09 grail kernel: ide_setup: ide4=noprobe
> Jun 13 17:00:09 grail kernel: ide_setup: ide5=noprobe
> Jun 13 17:00:09 grail kernel: ide_setup: ide6=noprobe
> Jun 13 17:00:09 grail kernel: ide_setup: ide7=noprobe
> Jun 13 17:00:09 grail kernel: Initializing CPU#0
> Jun 13 17:00:09 grail kernel: Detected 1666.763 MHz processor.
> Jun 13 17:00:09 grail kernel: Console: colour VGA+ 80x25
> Jun 13 17:00:09 grail kernel: Calibrating delay loop... 3322.67 BogoMIPS
> Jun 13 17:00:09 grail kernel: Memory: 1031860k/1048064k available (1293k
> kernel code, 15812k reserved, 329k data, 308k init, 130560k highmem)
> Jun 13 17:00:09 grail kernel: Checking if this processor honours the WP bit
> even in supervisor mode... Ok.
> Jun 13 17:00:09 grail kernel: Dentry cache hash table entries: 131072
> (order: 8, 1048576 bytes)
> Jun 13 17:00:09 grail kernel: Inode cache hash table entries: 65536 (order:
> 7, 524288 bytes)
> Jun 13 17:00:09 grail kernel: Mount-cache hash table entries: 16384 (order:
> 5, 131072 bytes)
> Jun 13 17:00:09 grail kernel: Buffer-cache hash table entries: 65536
> (order: 6, 262144 bytes)
> Jun 13 17:00:09 grail kernel: Page-cache hash table entries: 262144 (order:
> 8, 1048576 bytes)
> Jun 13 17:00:09 grail kernel: CPU: L1 I Cache: 64K (64 bytes/line), D cache
> 64K (64 bytes/line)
> Jun 13 17:00:09 grail kernel: CPU: L2 Cache: 256K (64 bytes/line)
> Jun 13 17:00:09 grail kernel: Intel machine check architecture supported.
> Jun 13 17:00:09 grail kernel: Intel machine check reporting enabled on
> CPU#0.
> Jun 13 17:00:09 grail kernel: Enabling fast FPU save and restore... done.
> Jun 13 17:00:09 grail kernel: Enabling unmasked SIMD FPU exception
> support... done.
> Jun 13 17:00:09 grail kernel: Checking 'hlt' instruction... OK.
> Jun 13 17:00:09 grail kernel: POSIX conformance testing by UNIFIX
> Jun 13 17:00:09 grail kernel: mtrr: v1.40 (20010327) Richard Gooch
> ([email protected])
> Jun 13 17:00:09 grail kernel: mtrr: detected mtrr type: Intel
> Jun 13 17:00:09 grail kernel: CPU: L1 I Cache: 64K (64 bytes/line), D cache
> 64K (64 bytes/line)
> Jun 13 17:00:09 grail portmap: portmap startup succeeded
> Jun 13 17:00:09 grail kernel: CPU: L2 Cache: 256K (64 bytes/line)
> Jun 13 17:00:09 grail kernel: Intel machine check reporting enabled on
> CPU#0.
> Jun 13 17:00:09 grail kernel: CPU0: AMD Athlon(tm) MP 2000+ stepping 02
> Jun 13 17:00:09 grail kernel: per-CPU timeslice cutoff: 731.44 usecs.
> Jun 13 17:00:09 grail kernel: masked ExtINT on CPU#0
> Jun 13 17:00:09 grail kernel: ESR value before enabling vector: 00000000
> Jun 13 17:00:09 grail kernel: ESR value after enabling vector: 00000000
> Jun 13 17:00:09 grail kernel: Booting processor 1/0 eip 2000
> Jun 13 17:00:09 grail kernel: Initializing CPU#1
> Jun 13 17:00:09 grail kernel: masked ExtINT on CPU#1
> Jun 13 17:00:09 grail kernel: ESR value before enabling vector: 00000000
> Jun 13 17:00:09 grail kernel: ESR value after enabling vector: 00000000
> Jun 13 17:00:09 grail kernel: Calibrating delay loop... 3329.22 BogoMIPS
> Jun 13 17:00:09 grail kernel: CPU: L1 I Cache: 64K (64 bytes/line), D cache
> 64K (64 bytes/line)
> Jun 13 17:00:09 grail kernel: CPU: L2 Cache: 256K (64 bytes/line)
> Jun 13 17:00:09 grail kernel: Intel machine check reporting enabled on
> CPU#1.
> Jun 13 17:00:09 grail kernel: CPU1: AMD Athlon(tm) Processor stepping 02
> Jun 13 17:00:09 grail kernel: Total of 2 processors activated (6651.90
> BogoMIPS).
> Jun 13 17:00:09 grail kernel: Using local APIC timer interrupts.
> Jun 13 17:00:09 grail kernel: calibrating APIC timer ...
> Jun 13 17:00:09 grail kernel: ..... CPU clock speed is 1666.8537 MHz.
> Jun 13 17:00:09 grail kernel: ..... host bus clock speed is 266.6966 MHz.
> Jun 13 17:00:09 grail kernel: cpu: 0, clocks: 2666966, slice: 888988
> Jun 13 17:00:09 grail kernel:
> CPU0<T0:2666960,T1:1777968,D:4,S:888988,C:2666966>
> Jun 13 17:00:09 grail kernel: cpu: 1, clocks: 2666966, slice: 888988
> Jun 13 17:00:09 grail kernel:
> CPU1<T0:2666960,T1:888976,D:8,S:888988,C:2666966>
> Jun 13 17:00:09 grail kernel: checking TSC synchronization across CPUs:
> passed.
> Jun 13 17:00:09 grail kernel: Waiting on wait_init_idle (map = 0x2)
> Jun 13 17:00:09 grail kernel: All processors have done init_idle
> Jun 13 17:00:09 grail kernel: mtrr: your CPUs had inconsistent fixed MTRR
> settings
> Jun 13 17:00:09 grail kernel: mtrr: probably your BIOS does not setup all
> CPUs
> Jun 13 17:00:09 grail kernel: PCI: PCI BIOS revision 2.10 entry at 0xfd7d0,
> last bus=3
> Jun 13 17:00:09 grail kernel: PCI: Using configuration type 1
> Jun 13 17:00:09 grail kernel: PCI: Probing PCI hardware
> Jun 13 17:00:09 grail kernel: BIOS failed to enable PCI standards
> compliance, fixing this error.
> Jun 13 17:00:09 grail kernel: isapnp: Scanning for PnP cards...
> Jun 13 17:00:09 grail rpc.statd[459]: Version 1.0.1 Starting
> Jun 13 17:00:09 grail kernel: isapnp: No Plug & Play device found
> Jun 13 17:00:09 grail nfslock: rpc.statd startup succeeded
> Jun 13 17:00:09 grail kernel: Linux NET4.0 for Linux 2.4
> Jun 13 17:00:09 grail kernel: Based upon Swansea University Computer
> Society NET3.039
> Jun 13 17:00:09 grail kernel: Initializing RT netlink socket
> Jun 13 17:00:09 grail kernel: apm: BIOS version 1.2 Flags 0x03 (Driver
> version 1.16)
> Jun 13 17:00:09 grail kernel: apm: disabled - APM is not SMP safe.
> Jun 13 17:00:09 grail kernel: Starting kswapd
> Jun 13 17:00:09 grail kernel: allocated 32 pages and 32 bhs reserved for
> the highmem bounces
> Jun 13 17:00:09 grail kernel: VFS: Diskquotas version dquot_6.4.0
> initialized
> Jun 13 17:00:09 grail kernel: Journalled Block Device driver loaded
> Jun 13 17:00:09 grail kernel: pty: 2048 Unix98 ptys configured
> Jun 13 17:00:09 grail kernel: Serial driver version 5.05c (2001-07-08) with
> MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI ISAPNP enabled
> Jun 13 17:00:09 grail kernel: ttyS00 at 0x03f8 (irq = 4) is a 16550A
> Jun 13 17:00:09 grail kernel: ttyS01 at 0x02f8 (irq = 3) is a 16550A
> Jun 13 17:00:09 grail kernel: Real Time Clock Driver v1.10e
> Jun 13 17:00:09 grail kernel: Uniform Multi-Platform E-IDE driver Revision:
> 6.31
> Jun 13 17:00:09 grail kernel: ide: Assuming 33MHz system bus speed for PIO
> modes; override with idebus=xx
> Jun 13 17:00:09 grail kernel: AMD7441: IDE controller on PCI bus 00 dev 39
> Jun 13 17:00:09 grail kernel: AMD7441: chipset revision 4
> Jun 13 17:00:09 grail keytable: Loading keymap:
> Jun 13 17:00:09 grail kernel: AMD7441: not 100%% native mode: will probe
> irqs later
> Jun 13 17:00:09 grail kernel: AMD7441: disabling single-word DMA support
> (revision < C4)
> Jun 13 17:00:09 grail kernel: ide0: BM-DMA at 0xf000-0xf007, BIOS
> settings: hda:DMA, hdb:pio
> Jun 13 17:00:09 grail kernel: ide1: BM-DMA at 0xf008-0xf00f, BIOS
> settings: hdc:DMA, hdd:pio
> Jun 13 17:00:09 grail kernel: hda: MAXTOR 6L080J4, ATA DISK drive
> Jun 13 17:00:09 grail kernel: hdc: YAMAHA CRW2200E, ATAPI CD/DVD-ROM drive
> Jun 13 17:00:09 grail kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> Jun 13 17:00:09 grail kernel: ide1 at 0x170-0x177,0x376 on irq 15
> Jun 13 17:00:09 grail kernel: blk: queue c034cd64, I/O limit 4095Mb (mask
> 0xffffffff)
> Jun 13 17:00:09 grail kernel: hda: 156355584 sectors (80054 MB) w/1819KiB
> Cache, CHS=155114/16/63, UDMA(100)
> Jun 13 17:00:09 grail kernel: Partition check:
> Jun 13 17:00:09 grail kernel: hda: hda1 hda2 hda3 hda4 < hda5 hda6 >
> Jun 13 17:00:09 grail keytable:
> Jun 13 17:00:09 grail kernel: Floppy drive(s): fd0 is 1.44M
> Jun 13 17:00:09 grail keytable: Loading system font:
> Jun 13 17:00:09 grail kernel: FDC 0 is a post-1991 82077
> Jun 13 17:00:09 grail kernel: RAMDISK driver initialized: 16 RAM disks of
> 4096K size 1024 blocksize
> Jun 13 17:00:09 grail kernel: md: md driver 0.90.0 MAX_MD_DEVS=256,
> MD_SB_DISKS=27
> Jun 13 17:00:09 grail kernel: md: Autodetecting RAID arrays.
> Jun 13 17:00:09 grail kernel: md: autorun ...
> Jun 13 17:00:09 grail kernel: md: ... autorun DONE.
> Jun 13 17:00:09 grail kernel: NET4: Linux TCP/IP 1.0 for NET4.0
> Jun 13 17:00:09 grail kernel: IP Protocols: ICMP, UDP, TCP
> Jun 13 17:00:09 grail kernel: IP: routing cache hash table of 8192 buckets,
> 64Kbytes
> Jun 13 17:00:09 grail kernel: TCP: Hash tables configured (established
> 262144 bind 65536)
> Jun 13 17:00:09 grail keytable:
> Jun 13 17:00:09 grail kernel: NET4: Unix domain sockets 1.0/SMP for Linux
> NET4.0.
> Jun 13 17:00:09 grail rc: Starting keytable: succeeded
> Jun 13 17:00:09 grail kernel: RAMDISK: Compressed image found at block 0
> Jun 13 17:00:09 grail kernel: Freeing initrd memory: 83k freed
> Jun 13 17:00:09 grail kernel: VFS: Mounted root (ext2 filesystem).
> Jun 13 17:00:09 grail kernel: kjournald starting. Commit interval 5
> seconds Jun 13 17:00:09 grail kernel: EXT3-fs: mounted filesystem with
> ordered data mode.
> Jun 13 17:00:09 grail kernel: Freeing unused kernel memory: 308k freed
> Jun 13 17:00:09 grail kernel: EXT3 FS 2.4-0.9.19, 19 August 2002 on
> ide0(3,1), internal journal
> Jun 13 17:00:09 grail kernel: Adding Swap: 1048816k swap-space (priority
> -1) Jun 13 17:00:09 grail kernel: kjournald starting. Commit interval 5
> seconds Jun 13 17:00:09 grail kernel: EXT3 FS 2.4-0.9.19, 19 August 2002 on
> ide0(3,6), internal journal
> Jun 13 17:00:09 grail kernel: EXT3-fs: mounted filesystem with ordered data
> mode.
> Jun 13 17:00:09 grail kernel: kjournald starting. Commit interval 5
> seconds Jun 13 17:00:09 grail kernel: EXT3 FS 2.4-0.9.19, 19 August 2002 on
> ide0(3,5), internal journal
> Jun 13 17:00:09 grail kernel: EXT3-fs: mounted filesystem with ordered data
> mode.
> Jun 13 17:00:09 grail kernel: kjournald starting. Commit interval 5
> seconds Jun 13 17:00:10 grail kernel: EXT3 FS 2.4-0.9.19, 19 August 2002 on
> ide0(3,2), internal journal
> Jun 13 17:00:10 grail kernel: EXT3-fs: mounted filesystem with ordered data
> mode.
> Jun 13 17:00:10 grail kernel: SCSI subsystem driver Revision: 1.00
> Jun 13 17:00:10 grail kernel: scsi0 : SCSI host adapter emulation for IDE
> ATAPI devices
> Jun 13 17:00:10 grail kernel: Vendor: YAMAHA Model: CRW2200E
> Rev: 1.0B
> Jun 13 17:00:10 grail kernel: Type: CD-ROM
> ANSI SCSI revision: 02
> Jun 13 17:00:10 grail kernel: usb.c: registered new driver usbdevfs
> Jun 13 17:00:10 grail kernel: usb.c: registered new driver hub
> Jun 13 17:00:10 grail kernel: usb-ohci.c: USB OHCI at membase 0xf88df000,
> IRQ 10
> Jun 13 17:00:10 grail kernel: usb-ohci.c: usb-02:00.0, Advanced Micro
> Devices [AMD] AMD-768 [Opus] USB
> Jun 13 17:00:10 grail kernel: usb.c: new USB bus registered, assigned bus
> number 1
> Jun 13 17:00:10 grail kernel: hub.c: USB hub found
> Jun 13 17:00:10 grail kernel: hub.c: 4 ports detected
> Jun 13 17:00:10 grail kernel: usb.c: USB disconnect on device 02:00.0-0
> address 1
> Jun 13 17:00:10 grail random: Initializing random number generator:
> succeeded
> Jun 13 17:00:10 grail kernel: usb.c: USB bus 1 deregistered
> Jun 13 17:00:10 grail kernel: usb.c: deregistering driver usbdevfs
> Jun 13 17:00:10 grail kernel: usb.c: deregistering driver hub
> Jun 13 17:00:10 grail kernel: parport0: PC-style at 0x378 (0x778)
> [PCSPP,TRISTATE,EPP]
> Jun 13 17:00:10 grail kernel: parport0: irq 7 detected
> Jun 13 17:00:10 grail kernel: Attached scsi CD-ROM sr0 at scsi0, channel 0,
> id 0, lun 0
> Jun 13 17:00:10 grail kernel: sr0: scsi3-mmc drive: 40x/40x writer cd/rw
> xa/form2 cdda tray
> Jun 13 17:00:10 grail kernel: Uniform CD-ROM driver Revision: 3.12
> Jun 13 17:00:10 grail kernel: 3c59x: Donald Becker and others.
> http://www.scyld.com/network/vortex.html
> Jun 13 17:00:10 grail kernel: 02:08.0: 3Com PCI 3c905C Tornado at 0x3000.
> Vers LK1.1.16
> Jun 13 17:00:10 grail rc: Starting pcmcia: succeeded
> Jun 13 17:00:10 grail netfs: Mounting other filesystems: succeeded
> Jun 13 17:00:10 grail autofs: automount startup succeeded
> Jun 13 17:00:10 grail sshd: succeeded
> Jun 13 17:00:07 grail network: Setting network parameters: succeeded
> Jun 13 17:00:07 grail network: Bringing up loopback interface: succeeded
> Jun 13 17:00:12 grail xinetd[569]: xinetd Version 2.3.10 started with
> libwrap options compiled in.
> Jun 13 17:00:12 grail xinetd[569]: Started working: 1 available service
> Jun 13 17:00:13 grail xinetd: xinetd startup succeeded
> Jun 13 17:00:14 grail sendmail: sendmail startup succeeded
> Jun 13 17:00:14 grail sendmail: sm-client startup succeeded
> Jun 13 17:00:14 grail gpm: gpm startup succeeded
> Jun 13 17:00:15 grail crond: crond startup succeeded
> Jun 13 17:00:16 grail kernel: parport0: PC-style at 0x378 (0x778)
> [PCSPP,TRISTATE,EPP]
> Jun 13 17:00:16 grail kernel: parport0: irq 7 detected
> Jun 13 17:00:16 grail kernel: lp0: using parport0 (polling).
> Jun 13 17:00:16 grail kernel: lp0: console ready
> Jun 13 17:00:16 grail kernel: spurious 8259A interrupt: IRQ7.
> Jun 13 17:00:16 grail modprobe: modprobe: Can't locate module
> char-major-188 Jun 13 17:00:16 grail last message repeated 15 times
> Jun 13 17:00:16 grail modprobe: modprobe: Can't locate module
> char-major-180 Jun 13 17:00:16 grail last message repeated 15 times
> Jun 13 17:00:16 grail cups: cupsd startup succeeded
> Jun 13 17:00:17 grail xfs: xfs startup succeeded
> Jun 13 17:00:17 grail anacron: anacron startup succeeded
> Jun 13 17:00:17 grail atd: atd startup succeeded
> Jun 13 17:00:17 grail xfs: ignoring font path element
> /usr/X11R6/lib/X11/fonts/cyrillic (unreadable)
> Jun 13 17:00:27 grail login(pam_unix)[731]: session opened for user root by
> LOGIN(uid=0)
> Jun 13 17:00:27 grail -- root[731]: ROOT LOGIN ON tty1
> Jun 13 17:00:36 grail kernel: Found PTI SuperTrak at mbase: 0xf0800000, irq
> 5.
> Jun 13 17:00:36 grail kernel: Timeout wait for IOP Status Get Ready!
> Jun 13 17:00:36 grail last message repeated 2 times
> Jun 13 17:00:36 grail kernel: scsi1 : PROMISE SuperTrak SX6000 Driver
> Jun 13 17:00:36 grail kernel: Vendor: PTI Model: SuperTrak
> Rev:
> Jun 13 17:00:36 grail kernel: Type: Direct-Access
> ANSI SCSI revision: 02
> Jun 13 17:11:20 grail kernel: Attached scsi disk sda at scsi1, channel 0,
> id 0, lun 0
> Jun 13 17:11:20 grail kernel: SCSI device sda: 1273437184 512-byte hdwr
> sectors (-447511 MB)
> Jun 13 17:11:20 grail kernel: sda: sda1
> Jun 13 17:11:21 grail kernel: kjournald starting. Commit interval 5
> seconds Jun 13 17:11:21 grail kernel: EXT3 FS 2.4-0.9.19, 19 August 2002 on
> sd(8,1), internal journal
> Jun 13 17:11:21 grail kernel: EXT3-fs: mounted filesystem with ordered data
> mode.
> Jun 13 17:13:51 grail kernel: invalidate: busy buffer
> Jun 13 17:19:42 grail syslogd 1.4.1: restart.
> Jun 13 17:19:42 grail syslog: syslogd startup succeeded
> Jun 13 17:19:42 grail syslog: ^[[60G[
> Jun 13 17:19:42 grail rc: Starting syslog: failed
> Jun 13 17:19:42 grail portmap: Starting portmapper:
>
> [SYSTEM HANGS HERE]
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
OpenGFS -- http://opengfs.sourceforge.net
Home -- http://www.brianandsara.net
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
On Fri, 20 Jun 2003, John Bradford wrote:
> Would it be possible, (with relevant documentation), to tune the code
> morphing software for optimum performance of code generated by a
> specific compiler, though?
>
> If a particular version of GCC favours certain constructs and uses
> particular sets of registers for a given piece of code, couldn't we
> optimise for those cases, at the expense of others? Maybe a
> particular compiler doesn't use certain X86 instructions at all, and
> these could be eliminated altogether?
very little of the translation overhead is involed with deocding the x86
instructions... most of the translation overhead is in scheduling and
optimising for the VLIW.
there are some tricks which you can apply at the x86 level which favour
CMS much more than they favour other processors... specifically one
related to what jeff brought up:
On Fri, 20 Jun 2003, Jeff Garzik wrote:
> Newer CPUs do register renaming in an attempt to avoid the
> register-starved ISA issue. I presume Xmeta would do something
> similar...
yeah CMS does this internally.
one way you can exploit this for performance is within a basic block (or
within a code path that is most likely to be executed with a handful of
rarely/never taken branch outs) you can express every sub-expression
completely without worrying about its schedule -- which gives you access
to all the source x86 registers. CMS will reschedule it to fit onto the
pipeline for you, and rename to internal registers.
this can be a huge help for floating point code when you also unroll the
code. for example if you are doing a polynomial expansion, you can simply
write this:
f0 = a0 + x0*(a1 + x0*(a2 + x0*(a3 + x0*a4)));
f1 = b0 + x1*(a1 + x1*(a2 + x1*(a3 + x1*a4)));
you don't need to schedule the x87 code at all -- CMS will do it for you.
this example is pretty trivial, but if you have sequences which overflow
the x87 register set and require stack operations when scheduled for
a typical x86 processor you can mostly avoid the stack operations when
"scheduling" for CMS.
think of it as a huge reorder buffer.
-dean
> From [email protected] Fri Jun 20 20:22:12 2003
> Envelope-To: [email protected]
> Date: Fri, 20 Jun 2003 11:49:22 -0500
> From: Eli Carter <[email protected]>
> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003
> X-Accept-Language: en-us, en
> MIME-Version: 1.0
> To: John Bradford <[email protected]>
> CC: [email protected], [email protected],
> [email protected], [email protected], [email protected]
> Subject: Re: Crusoe's persistent translation on linux?
> References: <[email protected]>
> Content-Type: text/plain; charset=us-ascii; format=flowed
> Content-Transfer-Encoding: 7bit
> X-Scanned-By: MIMEDefang 2.29 (www . roaringpenguin . com / mimedefang)
>
> John Bradford wrote:
> >>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.
> >
> >
> > Would it be possible, (with relevant documentation), to tune the code
> > morphing software for optimum performance of code generated by a
> > specific compiler, though?
> >
> > If a particular version of GCC favours certain constructs and uses
> > particular sets of registers for a given piece of code, couldn't we
> > optimise for those cases, at the expense of others? Maybe a
> > particular compiler doesn't use certain X86 instructions at all, and
> > these could be eliminated altogether?
> >
> > It's not unlikely that an entirely open source system could have all
> > code compiled with the same compiler, and so maybe we can use this to
> > avoid implementing expensive corner cases in the CPU, because we're
> > never going to trigger them.
>
> Hmm... basically you want to trim the x86 instruction set to get closer
> to RISC mentality.
Yep, that's what I was thinking.
> Interesting. gcc may already do that to some extent
> by not using the really complex instructions. If that is the case,
> dropping those instructions might give some room for testing some of its
> possible benefits.
> I doubt restricting the registers used by some
> instructions would help... I've heard comments that the x86 is
> register-starved enough already.
Ah, no what I meant was something along the lines of the z80, (yeah,
it's been a while since I did assembler :-) ), where you had an
'accumulator', which you did all the complex operations in, and used
the BC, DE, HL, (you just have to love the name, it helped you
remember the endianness of the CPU), registers to do basic operations
in.
I was just thinking that if gcc favoured register BAR for operation
FOO, the CPU could do likewise, and if their was a performance hit for
using another register, we'd avoid it. Probably less applicable to a
software based CPU like Cruesoe, though, and like you mentioned, X86
is register starved anyway.
John.
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
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 [email protected]
> 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
http://www.briggsmedia.com
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 [email protected]
> 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
http://www.briggsmedia.com
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
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...
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.
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.
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.
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
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 [email protected]
> 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 [email protected]
-- 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"
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.
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.
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
http://www.briggsmedia.com
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
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
http://www.briggsmedia.com
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
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.
>
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.
> >
>
On 22 Jul 2003 00:02:39 -0400
Jason <[email protected]> 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--
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 <[email protected]> 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 [email protected]
> 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
http://www.briggsmedia.com