Subject: NetBSD 1.1B (BOOTX) error report (was Re: help! Working falcon kernel would be nice...)
To: None <leo@ahwau.ahold.nl>
From: None <goettsch@informatik.tu-muenchen.de>
List: port-atari
Date: 06/17/1996 22:49:15
Hello Leo Weppelman
You wrote:
> 
> Hi,
> >
> >
> > Does anyone out there have a kernel which is a recent version _and_ Falcon
> > friendly? I would like a kernel for a Falcon with no FPU, 4Mb RAM and
> > preferably with only 2 views configured.. . .
> >
> > The main problem seems to be with the scsi driver somewhere - I keep
> > getting weird "some bytes stuck in fifo" and "dma-ready = 2" errors
> > then the system hangs irretrievably. In addition to this it now
> This is _bad_. If I am right, you are the fourth one complaining about
> this particular problem...

Now you got the fifth... :-(
I can agree Dan fully. I got exactly the same problems the last days:
the original BOOTX-kernel crashed all some minutes, especially when I 
perform large data transfer over the SCSI-bus (I'll report the commands
below in detail). Like Dan I wasn't even able only to save my /usr or 
/home partitions on another msdos-disk. So working with NetBSD makes no 
sense, but spends many senseless hours without fun :-(. A  


Now the error-reports:
----------------------


First a very little thing:
	the kernel read the wrong time (NOT date)
	from the clock chip of my Falcon

According to the time, when I boot GEMDOS the time in NetBSD1.1B is 
about 7 hours erlier. So the last 'date' command delivers
	Jun 17 13:04:18
and after that I reboot in MULTITOS and the time there is
	20:15 , 17.6.96
Strange ?


Next the boring messages of 
	"St-mem pool exhausted, binpatch 'st_pool_size'to get more"

It destroys the screen when appearing a hundreds of time on commnds like
'newfs' or 'fsck' and it seemed that it brakes the speed of the system
slow. You wrote a short explanation for the low value of _st_pool_size,
>> (cite from your FAQ)The default (BOOT) kernel supplied has a rather small St-mem pool. This
is done to enable it to boot in systems having only 4Mb of ram. In fact
it has a pool just big enough for 2 virtual consoles in ST-mode.
<< (cite end)
But if it is so, why has the delivered BOOTX kernel 3 (*three*) virtual
consoles, so this message MUST appear on any machines with any video
configurations ? (We have discussed that already one year ago, 
but anyway ... ;-)

So I had to follow your instructions in your FAQ (no man-page of
'binpatch' found on my system!) and issued the command
	binpatch -s _st_pool_size -o 8192 -r NNN <path to kernel>
with NNN = 3871296 
where I compute NNN from
	video-size 	= (1024x768x256col) x 3 ite's	= 2359296 byte
			   + 8 kB slack x 3 ite's	=   24000 byte
	bounce-buffer	=  16kB x 3 SCSI devices	=   48000 byte
	floppy		=  18kB x 80 tracks (???)	= 1440000 byte
							--------------
	SUM						= 3871296 byte
Is this correct ? Or is the value too big ?? 
(Then, IMHO you have to mention the most upper value for NNN in this FAQ.)
But anyway as I booted from this binpatched kernel I only got some lines
of pixel-dust ... :-(
So I had to change to the original kernel and to bear this messages ... ;)


3) GEMDOS-partions > 300 MB  don't work on NetBSD 1.1B
	==> panic: allocbuf: buffer larger than MAXBUFSIZE
	    when write access on this partition
Is this so ? Is this well-known ? Why does nobody write this in the FAQ
or anothe suitable place ?? It cost me two day of searching and musing
and nearly I reinstalled the system and destroyed my NetBSD-partitions
as I thoght before the netbsd partitions were destroyed. But then I found
an entry in my logbook about the same error I got last year ... ;)


4) the horrible instable kernel on large data transfers

All I want to do is to save my installed system (/ /usr and /home part.)
on another disk.
I tried this on the following two configurations:

Config A:  two SCSI disks:
Jun 15 11:50:34 falheg /netbsd: sd0 at scsibus0 targ 0 lun 0: 
	<IMPRIMIS, 94601-15, 0368> SCSI1 0/direct fixed
Jun 15 11:50:34 falheg /netbsd: sd0: 
	1002MB, 1931 cyl, 15 head, 70 sec, 512 bytes/sec
Jun 15 11:50:34 falheg /netbsd: sd1 at scsibus0 targ 1 lun 0: 
	<CDC, 94181-15, 5466> SCSI1 0/direct fixed
Jun 15 11:50:34 falheg /netbsd: sd1: 
	582MB, 1546 cyl, 15 head, 51 sec, 512 bytes/sec
the corresponding entries in '/etc/fstab':
	/dev/sd1a	/	ffs		# 55 MB
	/dev/sd1d	/tos1	msdos -G,rw	# 85 MB GEMDOS part.
	/dev/sd1e	/usr	ffs		# 80 MB
	/dev/sd1f	/home	ffs		# 300 MB
	/dev/sd0d	/tos2	msdos -G,rw	# 250 MB GEMDOS part.
	/dev/sd0e	/tos3	msdos -G,rw	# 250 MB GEMDOS part.

The following command delivers always and reproductable kernel crashes
like 'jump to zero' or 'MMU fault' or sometimes just kernel hanging with
no flash lights on both disks:
	cd /usr; tar -cvf /tos3/netbsd-u.tar *

Config B:  one SCSI disk and one removable media (ZIP)
Jun 17 13:03:33 falheg /netbsd: sd0 at scsibus0 targ 1 lun 0: 
	<CDC, 94181-15, 5466> SCSI1 0/direct fixed
Jun 17 13:03:33 falheg /netbsd: sd0: 
	582MB, 1546 cyl, 15 head, 51 sec, 512 bytes/sec
Jun 17 13:03:33 falheg /netbsd: sd1 at scsibus0 targ 6 lun 0: 
	<IOMEGA, ZIP 100, R.41> SCSI2 0/direct removable
Jun 17 13:03:33 falheg /netbsd: sd1: 
	sd1(ncrscsi0:6:0): illegal request, 
	data = ff fe 01 01 f1 00 00 00 00 00 00 00 00 00 00 00 00
Jun 17 13:03:33 falheg /netbsd: sd1: 
	could not mode sense (4); using fictitious geometry
Jun 17 13:03:33 falheg /netbsd: 
	96MB, 96 cyl, 64 head, 32 sec, 512 bytes/sec
the corresponding entries in '/etc/fstab':
	/dev/sd0a	/	ffs		# 55 MB
	/dev/sd0d	/tos1	msdos -G,rw	# 85 MB GEMDOS part.
	/dev/sd0e	/usr	ffs		# 80 MB
	/dev/sd0f	/home	ffs		# 300 MB
	/dev/sd1d	/zip1	msdos -G,rw	# 85 MB GEMDOS part.

Also on this configuration the tar command
	cd /usr; tar -cvf /zip1/netbsd-u.tar *
had the same effect as under Config A. But I will mention that tar-ing
the root-filesystem (/) had completed without errors on the ZIP-disk.
But when I tried to restore it or to have a look at it (tar -xvf or -tvf)
in both cases after some pages of output (restore/view abot 200 files)
the kernel crashed again.
But also there were more errors especially for the ZIP-drive. See next.


5)  ZIP-errors , ZIP drive don't work

On 3) above you see the kernel-error-messages at boot time, when 
inspecting the ZIP-drive.
Additional to that, when I issued the above tar-command
the following messages appear
May 28 20:22:28 falheg /netbsd: sd1(ncrscsi0:6:0): 
	Target requests too much data
May 28 20:22:28 falheg /netbsd: ncrscsi0 : 
	Trying to reach Message-out phase
May 28 20:22:29 falheg /netbsd: ncrscsi0 : 
	Trying to reach Message-out phase, now: 0
May 28 20:22:29 falheg /netbsd: ncrscsi0 : 
	Resetting SCSI-bus (Failure to abort command)
May 28 20:22:29 falheg /netbsd: sd1(ncrscsi0:6:0): unit attention, 
	data = 00 10 01 05 d2 00 00 00 00 00 00 00 00 02 00 01 86

This error-messages always appear, when I wrote "greater" data 
(= more than one file, ore files > 1 KB about) on ZIP.


Recapitulating I wasn't able in two configurations just to tar my 
partitions. I tried it the whole last evening on abot 20(!) hours 
(this is because my Falcon is yet rather slow and the many rebooting, 
fsck and so on cost much time) and to say with Dan's word I'm already 
frustrated ! And the many crashing is also not good for the filesystems,
today I loosed some files... :(.
I think it is time to reinstall from scratch; although I will loose 
some things in this case I'm ready for this -- but ONLY if someone
guarantees me at last a stable kernel, that the work which spends also
some time is not in vain.

So this completes my reports. I know this sounds negative.
I hope you understand that I'm angry, because I *want* to work with NetBSD
on my Falcon (to install good programs on Unix, there exist many 
posibilites, it seemed an interesting hobby for me)
BUT IT MUST WORK.
Dan wrote:
> > All I want is a stable kernel suitable for a basic 4Mb Falcon, no FPU.MY WORDS (but with FPU, 16 MB Falcon :-)

Unfortunately our anonymous ftp-server on my working-group is yet not
installed. but I hope in the next days we get it again. So mail
me if you want to put kernels (like before one year ago, you remember)
on it.
Best regards
Helmar
-- 
          ___   __   Helmar Goettsch (Admin HEG: Lehrstuhl III, Informatik)
  /   /  /     /  '  Orleansstr. 34, D-81667 Muenchen, Phone: 089/48095-190  
 /---/--/-----/--+   email: goettsch@informatik.tu-muenchen.de
/   /  /___  /__/    WWW:   http://www3.informatik.tu-muenchen.de/~goettsch