Ok, my immediate priority for tonight has been to just try the latest
kernel and see how things go:
ftp://ftp.netbsd.org/pub/NetBSD-daily/HEAD/200810310002Z/atari/binary/kernel/
Indeed I was able to boot the netbsd-BOOT kernel. (I haven't exercised it
enough yet to see if I'm hitting the panic I've been seeing.) Next I
tried netbsd-ATARITT but I found that this (and the original 4.0
netbsd-ATARITT kernel) fail on boot. There's garbled video that appears
immediately (the boot may succeed in the background, but it's not very
useful if I can't see anything). I just filed a PR on this
(port-atari/39849).
This is more or less a blocker for me right now because I install via
ethernet, and only the netbsd-ATARITT kernel has the built-in riebl
drivers.
Another interesting issue is that the size of the netbsd-ATARITT kernel
has just now exceeded the size of a 1.44MB floppy. :-) I was able to get
around this limitation using the really cool ghostlink app available here:
http://uml.darkspace.org.uk/mirrors/Atari/Internet_and_Comms/GhostLink-v1.02/
It works great in Windows 2000 and will essentially map a drive letter on
the Atari to a drive letter on the Windows PC over a serial link. In
fact, I could use this to copy all the netbsd 4.0 sets over to the Atari
and do an install w/o ethernet support. I'll probably try something like
this in the next few days, but it would be much better if the
netbsd-ATARITT kernel just worked, as it once did. :-)
David Ross
dross%pobox.com@localhost
----- Original Message -----
From: "David Brownlee" <abs%NetBSD.org@localhost>
To: "T. Makinen" <tjamaloo%gmail.com@localhost>
Cc: "David Ross" <dross%pobox.com@localhost>; <port-atari%netbsd.org@localhost>
Sent: Saturday, November 01, 2008 5:39 PM
Subject: Re: scsi freezing problem with NetBSD current
On Sat, 1 Nov 2008, T. Makinen wrote:
On Thu, Oct 30, 2008 at 9:13 AM, David Ross <dross%pobox.com@localhost> wrote:
Ok, I tried this one and it died on boot with the same mutex error, just
later in the boot process. The boot sequence leading up to the panic
was...
..
Mounting all filesystems...
Clearing /tmp.
Creating a.out runtime link editor directory cache.
Mutex error: mutex_vector_enter: locking against myself
..etc...
So I'm wondering now if this is a more or less intermittent issue and I
just
got lucky that first time I was successfully able to boot 4.0. Or it
could
be that this mutex issue is totally dependent on pmap.c being DEBUG.
I think it's probably not an issue of my userland being 1.6.1 because
the
first time I hit the panic it was so early on boot, but that's just a
hunch.
Strange that this happens with your TT, but not with my Falcon.
Are you able to boot with current kernel which has only SCSI fix ? If it
still
works, then it's probably DEBUG in pmap.c and/or some other possible
changes
that happened in NetBSD current source tree between SCSI fix kernel and
pmap.c
DEBUG kernel or I was lucky enough to boot DEBUG kernel two times with
Falcon :)
It would be helpful if we had a guaranteed way to reproduce
the crash on David's system, ideally without needing the
filesystem mounted read/write (so there would be no risk
of corruption and no need for fsck to check the filesyste,
after reboot).
David, if you have time could you maybe look at building
benchmarks/forkbomb or sysutils/crashme on your system (I
imagine under 1.6 would be fine), then booting your system
withe the test kernel into single user mode (so the
filesystems are mounted readonly) and running them to see
if they crash?
Alternatively if its related to disk IO you could try
booting into single user and running 'fsck -fn' which runs
fsck on all disks but disables any writing back (its a
quick way to generate a lot of non sequential disk reads)
Anyone know a reasonably priced source of Falcon or TT030
hardware? :) Someone wants £395 for a Falcon on eBay
at the moment... :/
--
David/absolute -- www.NetBSD.org: No hype required --