Yes, I get these as well by the truck load.
> > while trying to load the kernel, and trying to load the root floppy
> > into memory.
>
> 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.
>
And newer kernels seem to make it toleralble to so extent, but by no means is
it fixed. As you have said later, you can start the thing if you don't load
into ramdisk.
I managed to get a working system, but the floppy stuff causes these errors
so often, and hang the machine so often, that I could not use the BLADE_0.3
automated install (such as it is), and had to manually extract every little
piece, and reboot often.
This reminds of the troubles that some of us had with floppy support
back around 0.99-1.0 (I'm sure it's a different problem, though :-)
That got fixed, so I'm not concerend about it, really.
These machine checks are troubling me to a greater extent, and unlike a
buggy floppy driver that will get fixed, if there is something wrong with
my hardware, this does concern me.
MILO-1.3.57 reports a machine check for reason unknown, then goes on and
reports a write to unimplemented b-cache memory, and "lots of other
unrecoverable errors occured" This seems to have something to do with
allocating memory for unziping the kernel. MOST of the time, things
continue after this, but after a while the kernel may or may not have
another machine check, and if it does, the system often hangs.
My system configuration is like this...
Noname, with 166 MHz CPU
0 cache RAM
8Meg 36bit 60ns RAM (2 4Meg SIMMS, of course, tried both banks, just in case)
Is this a problematic configuration? Does MILO need cache RAM, or is it
just trying to find out if there is any to use?
BTW, I'm new to this channel, and since this reads rather negative, I
would like to thank everyone for their most excellent work on it, in
spite of my seeming negative, Linux/Alpha is one hell of a great system!
Thanks again,
Jeff Dionne,
Jeff@maribor.pfnet.com
>
> > 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
> -------------------------------------------------------------------------------
>
> --
> To unsubscribe: mail -s unsubscribe axp-list-request@redhat.com < /dev/null
>
Copyright © 1995-1997 Red Hat Software. Legal notices