Alpha floppy support in older MILOs and kernels was notoriously flakey,
at least in my experience. More recent MILOs and kernels seem to be better.
> 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).
Later (1.3.48+) kernels require different sytax for loading RAMdisk:
boot fd0:vmlinux.gz load_ramdisk=1 root=/dev/fd0
instead of the older:
boot fd0:vmlinux.gz root=/dev/fd0 ramdisk=1440
Try a recent kernel with the appropriate command, it may react better.
> 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
Do you "set MEMORY_SIZE 16" when MILO comes up? Or does MILO indicate that
it thinks there's only 16Mb of memory? If it thinks there's more, this can
often cause the above machine check message...
Also, if the memory SIMMS are x32 and *not* x36 (ie nonparity vs parity),
some Alpha lowest-level firmware is known to have real problems setting it
up...
> 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.
Unaligned traps are *NOT* indicative of hardware problems, but *software*
ones. FDISK, as a user of the MSDOS partition table and FS structures,
*will* do unaligned memory accesses (32 or 64 bit load/store on non-32 or
non-64 bit boundary, a no-no on the Alpha), because of the data structures
involved. These messages indicate simply that the kernel took an unaligned
access exception while running FDISK, and FIXED IT UP! Just ignore them...
> 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
Yeah, I noticed this recently as well, it didn't used to say that... :-(
However, things seem to work fine in spite of the message, on the boxes
where I've seen it.
> 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?
Well, the only things I can suggest:
1. try using the latest MILO from floppy, as well as the latest kernels,
in hopes that the floppy drivers will be more tolerant.
2. try using fresh floppies, with fresh low-level formatting and FS, maybe
even formatted and filled on the same floppy drive.
3, check out the SIMM types and sizes, as some combinations of type and size
seems to cause problems on certain boxes, NONAME being one such...
4. make sure MILO knows or has been told the correct total memory size.
Good luck, let us know how you make out.
--Jay++
-------------------------------------------------------------------------------
American Non Sequitur Society: we don't make sense, but we do like pizza...
Jay A Estabrook Alpha Migration Tools
Mailstop: TAY1-2 (DTN) 227-4202
Digital Equipment Corp. (external) (508) 952-4202
151 Taylor Street enet: jestabro@amt.tay1.dec.com
Littleton, MA 01460-1407 decnet: tallis::jestabro
-------------------------------------------------------------------------------
Copyright © 1995-1997 Red Hat Software. Legal notices