Subject: Re: No output display on DS3100 current kernel
To: Erik Bertelsen <erik@mediator.uni-c.dk>
From: Erik Bertelsen <erik@mediator.uni-c.dk>
List: port-pmax
Date: 04/18/2000 23:45:26
On Thu, Apr 06, 2000 at 09:09:34PM +0200, Erik Bertelsen wrote:
> To add to my problem: Using the older (1.4V) kernel makes the system boot normally,
> but a current kernel (up to yesterday's sup) shows two differences:
> 
>  - the console output stops about the time the kernel is about to start or has
>    started init. This has been observed by other persons as well.
>  - secondly rc processing starts, but stops prematurely. I did some experiments and
>    the result is that with no screen output the system ends up in single-user mode
>    and I can actually halt or reboot the system using the keyboard. Booting the
>    older kernel still works, so the difference is with the kernel.
> 

Following up to myself:

Todays kernel still does not show any /dev/console output on the screen, but only
kernel printf's (such as a sd1 has no disklabel).

But I've done another experiment: I've updated /etc/rc* and /etc/rc.d/* to today's
sup'ed versions and still observed that rc processing stopped somewhere down the
way. As the screen output is suspended I don't know exactly why and where.

Today it does not exit to single user  mode, but a CTRL/C will make it continue.

While it is hanging, the network interface is (partly) configured, ie. a telnet 
to the machine gets connection refused, thus indicating that IP is running, but
that inetd is not. 

Then I did two changes:

 - edited /etc/rc.d/sysdb to always kvm_mkdb /netbsd and never do the sysctl -n
   machdep.booted_kernel thing (which gives wrong results on pmax).
 - removed options INET6 from the kernel configuration before rebuilding it.

Now the machine boots fully to multi-user, but still without any /dev/console
output.

Actually I tend to suspect that it was hanging somewhere in the IPv6 dependent
part of /etc/rc.d/netstart and that the sysdb change was irrelevant.

This may also explain why only some people have observed the problems. Are the
other sufferers of pmaxes not completing rc.d processing also ipv6 users?

Maybe the problem also depends on which file systems are mounted by mountcritremote
and which are left to mountall?

- Erik