> From: pekka <pekka.niira...@pp5.inet.fi> > Date: Tue, 28 May 2013 22:51:32 +0300 > > On 5/28/13 12:53 AM, slhac tivist wrote: > > If it's good when you hard boot, then maybe an rc.* script is causing > > problems? Maybe you could figure it by elimination. Reboot flushes the > > cache and then executes the rc.d scripts... > > I copied rc.conf as rc.conf.local and set all services except > sshd to NO. It did not help. > > I suspect it may be related to serial console because > when I attach USB keyboard before boot I lose the console > output as soon as I should get the logon prompt. > There are PROM settings for this combination which I have > to investigate. I have only XVR-2500 display cards which are > not supported and therefore I am stuck. To be continued...
Right. Might be a problem with the FIFO on the serial port: > >> com0 at ebus0 addr 80-87 ivec 0x7c8: ns16550a, 16 byte fifo > >> com0: console > >> com1 at ebus0 addr 0-7 ivec 0x7c8: ns16550a, 16 byte fifo > >> com1: probed fifo depth: 0 bytes The 2nd serial port is detected as an ns16550a compatible chip, which should provide a 16 byte FIFO, but then we pobe it and find that it doesn't work. We don't run the probe on the console since it typically generates some random garbage on the other end. But it is likely the FIFO doesn't work there either. And that might cause issues. Can you post the eeprom -p output for this machine? If your hacking skills are up to it, you could experiment with adding a line like: sc->sc_uarttype = COM_UART_16550; to sys/arch/sparc64/dev/com_ebus.c:com_ebus_attach.c, right before the com_attach_subr() call.
