Hello Helmar,

> > 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 ... ;-)
I did understood you.... The above explanation was not aimed at you
specifically. The mess the kernel generated on some systems and the dataloss
some of you experienced made me write the above reminder.

[ Starnge date ]
> > 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).
The problem is that GEM doesn't know about timezones and NetBSD does. If
you use GEM often, maybe you should try to set your timezone to UTC. I know
that some ports allow to set the zone offset through config (TIMEZONE&DST),
this is no full solution because you will have to recompile the kernel
twice a year to get the right DST. 

[ My faulty calculation ]
> 
> 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.
You are right. The most clear calculation is:
	(width * heigth * 'depth') /8
Where 'depth' is the number of bits required to hold the amount of colors.
I'll update the FAQ again.

[ ... ]
> 
> 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 ?
2 is a result of 1. I don't know the cause of 1 though. Did you try specifying
every thing? Like: iteconfig -d 4 -h .... -w ....

> > > 3) GEMDOS-partions > 300 MB  don't work on NetBSD 1.1B
> > >       ==> panic: allocbuf: buffer larger than MAXBUFSIZE
> 
> Already something clear about that ?
According to the comments on sys/param.h, you can increase it to say 32Kb
(now 16Kb) without trouble. I didn't try this myself however. The cause is
clear: Because GEM uses a FAT of a limited size, it increases the block
(cluster) size on large filesystems. Very inefficient for small files, but
it works.....

> > >. . .
> > > 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.
Not yet, I'd better wait for your second tests to end ;-)

Leo.