NoName problems [long]

Conor McCarthy (CONORMC@cclana.ucd.ie)
Sat, 24 Feb 1996 16:26:15 +0000 (GMT)

hi,
I am having curious problems with a 166MHz NoName board I'm trying to
install Blade 0.3 on...
AXPpci NoName 166MHz board. 16MB RAM
1GB Quantum Fireball EIDE drive Toshiba 4x SCSI II CDROM
8 bit Video 7 VGA card 1.44 MB floppy

I have flashed the Blade MILO, and that works fine, I can load MILO
from flash, and also directly from floppy without any problems. The
problems start when I try to load the kernel from floppy to install
BLADE. The following messages occur intermittently:

unable to send byte 7 to FDC status=c0

floppy0: timeout handler died: do_fd_request

floppy0 unexpected interrupt
sensei
1c0
10
sensei
1c1
10 [etc...]

while trying to load the kernel, and trying to load the root floppy
into memory.
I can start linux, but *only* if I leave the root fs on fd0 and not
in a ramdisk. Every time I try to use a ramdisk it hangs part way
though loading into memory (mostly between 5 and 20 seconds into
loading).

Also I get machine checks from time to time:
lca: machine check (la=0xffffffc0:00002084d0)
unknown error log size 408
PC=ffffffc0:00003f7e78 PS=0003

If I use fd0 for the root fs, I can run fdisk, but I get loads
of unaligned traps, for example hitting p causes 3/4 consecutive
traps about 50% of the time.
fdisk(33): unaligned trap at 00000001:20005d00:
00000001:40003906 2c21
Since I tried to partition the disk, from then on whenever MILO/kernel
does a partition check on hda, further traps occur.
I have tried newer MILO/kernels, same messages, except for when MILO
starts:
..
hda: Quantum Fireball 1080 ...
hda: IRQ probe failed (-4) << new error
ide0 at 0x1f0-0x1f7, 0x3f6 on IRQ 14

and trying ls fd0: while running MILO sometimes causes:
floppy0: timeout handler died: normal interrupt end.

I have tried 3 different floppy drives, and cables (including a
2.88MB drive, since my 1.44s are ageing a little), all of which
work fine with a DOS/386, and replaced the IDE cable. I had a
friend check the memory for parity errors running Checkit on his
DOS 486, all ok (though I believe that may not be conclusive).

Has anybody any idea what the cause of these errors can be?
In particular, I suspect the memory might not be happy in the
alpha, has anybody had trouble with any SIMMs that just plain
refuse to work?

regards,
Conor.



Feedback | Store | News | Support | Product Errata | About Us | Linux Info | Search | JumpWords
No Frames | Show Frames

Copyright © 1995-1997 Red Hat Software. Legal notices