Hi Leo,
On this weekend I got again time for my computer
and enough timespan was gone, after my last frustrating use of NetBSD :-)
Now I have time to answer your first mail. The last mail, the anouncenment
of the new kernels, I reply in a seperate mail.

But in the other mail, a reply on my error reports, I think we've got a
big misbehavior
You, Leo Weppelman wrote:
> 
> Hello Helmar,
> 
> > > > 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
> As you are definitely not the first one who has lost some files :-(, I think
> the following should be made clear to everyone:
> 
> Installing a new kernel is *never* without risk. It doesn't matter if it
> is a alpha/beta or 'official' release kernel. This is a fact of (software)
> life. It just means that *before* installing a new kernel, you should either
> make a backup or be prepared for data loss.

Hmm, IMHO you don't understood me. Just you see above, I wrote, that I have 
TRIED to make a backup, but it don't work ! HOW shall I make a backup of 
NetBSD-partitions, which only can be read by a NetBSD-kernel. And that kernel
definitly didn't work, (others I had, were too old and incompatibel).
BUT THIS WASN'T THE SENSE OF MY REPORT ! I only wanted to say that one was not
able to work in any way with that kernel and so I contributed to Dan's 
expierences. But anyway forget it ... ;-)
> >
> > 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 ?
> Indeed, please check if the symlink /etc/localtime points to
> /usr/share/zoneinfo/MET or CET (whatever you prefer). If it does, this
> must be looked into further.

It dose NOT : /etc/localtime -> /usr/share/zoneinfo/MST  (but WHY ??)
As I changed the link to .../MET  the time looks like better ;)
but isn't correct: the time is now exact 2 hours later than the clock
in TOS (and the actual time).

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

> >
> > 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
> I think the FAQ must be wrong here... I think the correct calculation
> should be: (width/8) * height * (color bytes/dot) This becomes:
>    (1024/8)*768*1 = 98304 == about 320Kb (including slack)
> Anyone has other ideas????

This must be WRONG ! 
If you compute it in BYTES then you have a line of [ 1024 Bits / 8 ] bytes,
but 256 colors mean a depth of 8 not 1 (you need 8 planes for every byte
to held one of 256 colors) = 1024 /8 * 8 ( * 768 lines) = 1024 * 768
or 
you compute it in PIXELS (as I do) then you have 1024 Pixel and for every
Pixel one byte for the 256 colors = 1024 * 1 ( * 768 lines) = 1024 * 768.

This told also my expierences: With your value of 350 KB I got after
the second 'iteconfig -w 1024 -h 768'  an error "Cant allocate memory" and
the well-known message to increase the st_pool_size. As I incresed it heavily
this messages dissapeard. But let it be ...  I hope I got the right value now.

But another thing (also to Thomas Gerstner) :
1) iteconfig -d 4 (or another value) don't work
   the screen does not change and 'iteconfig -i' prints always d: 1
2) colors don't work
   a value e.g. of  0x008080 does not make text dark cyan.
Did I anything wrong ?

> > 3) GEMDOS-partions > 300 MB  don't work on NetBSD 1.1B
> >       ==> panic: allocbuf: buffer larger than MAXBUFSIZE

Already something clear about that ?
> >. . .
> > Unfortunately our anonymous ftp-server on my working-group is yet not
> > installed. but I hope in the next days we get it again. The ftp-server now is ok. It's address is
	sunlight.informatik.tu-muenchen.de
	Dir:  /pub/heg/netbsd
if you have to put something in.

Greetings
-- 
          ___   __   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