Re: nfblock vs udev
Tested this - when running the bootstrap from floppy as GEM program
(calling it as bootstrap.prg), the system reboots spontaneously (and will
run through a memtest after that, so it's really rather like a cold boot).
Changing the name of the bootstrap to bootstrap.tos succeeds ib booting
So it should be named bootstrap.tos or should that just be documented?
I guess it should just be renamed - you don't usually care whether the
bootstrap runs as GEM or TOS app (the screen output is cleaner in the TOS
One thing that struck me as odd: the decompression of the kernel image
went a hell of a lot faster when run as GEM program. The kernel should be
loaded to ST-RAm (-s flag) but it looked as though it wasn't.
What details does the bug report give? Kernel hang, or reboot? The kernel
hang was quite a common thing for me with Debian kernels due to the
botched keyboard init. If the bug reporter has old hardware extensions
that hang off the ACIAs, and reports a hang it may well be that my latest
patch to linux-m68k will fix that symptom.
300730 is a hang, sounds like we can probably close it.
We should close it with the next kernel upload... with any luck, I'll have
the SMC91C111 driver working by then (it did finally own up to detecting
the proper hardware, instead of stuffing up the ROM-port card or just
hanging the kernel).
(Apologies if I seem unresponsive at this time - the mail system at my old
lab is migrated to postfix by a new admin, and that often results in no
mail going out for a few days ...)
Bummer. Maybe when he's done we can get q650's mail working again.
Running a buildd with email is a total drag.
I guess I'll let him fix outgoing relay for the whole domain first, before
adding something like incoming relay :-)
I'll play with postfix some on my UUCP relay so I'll have a config snip
ready when the time comes.
Any news on the buildd front?