Dear Alan, dear All,

+> > My mainboard is from MSI and I believe it's quite nice and stable, since even
+> > the notoriuos overclockers from Kryotech use it for their Highspeed-Athlons
+> > (up tp 900 MHz...).
+> 
+> The current MSI's should be fine. Check on the very early ones though.

How can I find out whether I got an elder one or a newer one?

I currently do have some difficulties to bring up the system at all. It's only
running partly.

Explanation: I use Loose'95 as a first stage bootloader via loadlin for Linux,
as well as for occasional gaming. (This is my private PC! :-)  )

I have quite a bunch of hardware in it:

- Intel EtherExpress 100 pro + (PCI) as NIC,
- 2 NCR/SYMBIOS SCSI Hostadaptors, 1 NCR 825 S, 1 875er from ASUS (2x PCI)
- Creative Labs Soundblaster Live! (PCI)
- Diamond Viper V770 - nVidia Riva TNT 2 Ultra with 32 MB RAM (AGP)

My problem is located somewhere in the PnP area. The system always
comes up with at least two cards sharing one IRQ, even though I disabled
my serial and parallel ports to give it a higher chance to find a different
one. I even tried to block this IRQ and set it in the BIOS as reserved for ISA.
This resulted in the same two cards jumping together (!) to the next free
IRQ. :-(((((

The MSI-Board has in the BIOS the possibility to select, whether the OS is
PnP-capable or not. - I've set this parameter to "OS is not PnP-capable" and
hoped that the BIOS would solve this problem for me. - Nada. Njet. Didn't work.

This results with my Loose'95 not accessing my CDROM correctly. Only when I
start it in "secured mode", I can *sometimes* get access to it.

OK. I can start Loose'95 on commandline level, so I can also use loadlin, right?

Right. - But here it seems I run into the next problem. My old machine was/is
a dual PPro (That's why I'm on this list...) which seem to run into some troubles
just the day before I got my new hardware. I took almost everything (cards) out of
my old box, as well as all the disks. So I thought it would run stable in the
new box as well. (The only new parts are the Intel EEPro 100+ and the TNT2-Ultra,
but I know, both are supported and good hardware. In fact my last graphic card
was a TNT with 16 MB RAM and PCI...)

Since my old machine was a PPro, I believed I could simply boot either the old
kernel or a new kernel, which I especially compiled with the Athlon in mind.

What happens now: I can boot BOTH kernels. - But: both seem to crash when they
want to access my root-disk for the first time. I remember, when I bootet last
time my PPro, it made an extensive fsck on the root disk which I found strange.

I couldn't make it boot again after that. And it seems the problem has followed
me to the new machine.

I guess, I have two choices: 
        - the fsck did something it shouldn't -> reinstall Linux /another fsck?
        - I may have some hardware problems -> buy a new disk ?! :-(

Does anybody have an idea if it could be something other than that?

Interestingly is, *how* the two kernels crash. The elder version just crashes
and I can only guess that it's because of the filesystem/disk. The newer is
more stable and does not crash _always_ but comes to a halt and tells me he
can't access the root disk.- Thus stopping.

Guys, I can only say I LOVE Linux! It's obvious that there is always an
real evolution from version to version and in this case, I guess, the "marketleader"
would only crash with either a BSOD or with an "general protection fault"
and not telling me what the problem really is. Keep up the good work! 
 
+> > Do I need a special Kernel-revision?
+> 
+> No. You need to avoid 2.2.7->2.2.11 because of a bug in Linux MTRR handling.

I have either the 2.2.5 or the 2.2.13 and I had also a 2.3.24 downloaded, but
the compiler did complain and I could not compile it.
 
+> > Or compiler?
+> 
+> Nope
+> 
+> > Or glibc ?
+> 
+> Nope. You could build a new glibc in theory and gain some speed.

I guess I'll do that. :-)  (Once it's up and running...)
 
+> > By the way, what chances do I have that the K7 is supported by the gcc, soon?
+> > Which compiler options should I use to get the best results?
+> 
+> With the 2.3.x kernel optimisations and egcs I'm using the following. I'll point
+> out right now some of these probably overlap and I'm not a gcc expert I just
+> tried and benched stuff

Thank you again, Alan! - Your optimizations should be good enough for me, too! :-)

If I only could make that thing run!

Best regards,

        Herbert

-------------------------------------------------------------------------------
In theory there's no difference between theory and practice, but in practice...

-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/dmentre/smp-howto/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]

Reply via email to