Subject: ROM weirdness
To: None <port-alpha@netbsd.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: port-alpha
Date: 05/31/1999 16:49:39
We've got an AlphaPC 164 that's running NetBSD.  Until recently, due to
trouble laying our hands on a video card that would actually work, it's
been running with serial console (by the simple expedient of leaving
the keyboard unplugged), and everything's been pretty much fine; there
is one strangeness in that turning the machine off seems to convince it
the year is sometime well into the next century (not the end of the
epoch, though; that date I would recognize - it's sometime in 2019:
"clock gained 7305 days").

But today, I got my paws on a video card and tried it.  And, as you can
probably guess, there were some problems.

Everything appeared fine at first: I got a nice >>> prompt and told it
to "boot -flags s", and it did its thing with the twirler and spewed
autoconfig messages at me.  It still thought the year was 2019.  So I
did "date 19990531xxxx" (for a suitable value of xxxx) and told it to
"halt", expecting to reboot it.

Well, it came down normally, to the point of printing out "halted",
then locked up hard.  (At the point where it would normally print the
line about halting CPU 0.)  No blinking cursor on the display, even.  I
had to poke the hard-reset button on the front panel.  This brought it
back (still in 2019, though), at which point I set the date and told it
to reboot, instead of halting.  Then it went down and came back, though
without showing me any of the usual ROM-generated messages; however,
during boot, it didn't see the CD drive.  Instead of the usual

pciide0: secondary channel wired to compatibility mode
atapibus0 at pciide0 channel 1
cd0 at atapibus0 drive 1: <FX820S, , g01> type 5 cdrom removable
cd0: 32-bits data port
cd0: drive supports PIO mode 3, DMA mode 1
wd0(pciide0:0:0): using PIO mode 4, DMA mode 2 (using DMA data transfers)
cd0(pciide0:1:1): using PIO mode 3, DMA mode 1 (using DMA data transfers)
isa0 at sio0

I saw

pciide0: secondary channel wired to compatibility mode
atapibus0 at pciide0 channel 1
pciide0: disabling secondary channel (no drives)
wd0(pciide0:0:0): using PIO mode 4, DMA mode 2 (using DMA data transfers)
isa0 at sio0

with a very long pause (15 seconds?) after the "atapibus0 at pciide0"
line.  I then told it to reboot *again* and got

pciide0: secondary channel wired to compatibility mode
pciide0: secondary channel ignored (disabled)
wd0(pciide0:0:0): using PIO mode 4, DMA mode 2 (using DMA data transfers)
isa0 at sio0

with no long delay.

Upon (powering off and) unplugging the keyboard and going back to using
the serial console, everything went back to the way it worked before,
so it's not just a matter of having the video card in there.

I did save dmesg output under five circumstances:

1) Just after power-on reset, video console
2) After first "reboot", video console
3) After second "reboot", video console
4) Just after power-on reset, serial console
5) After (first) "reboot", serial console

The last two are identical except for the "clock gained 7305 days"
line.  I played a bit with diff and find some interesting things.  The
most interesting is what I see for the display card when diffing
version 4 and version 1.  Note both boots were done with exactly the
same kernel.

@@ -24,8 +24,7 @@
 de0: DEC DE500-AA 21140A [10-100Mb/s] pass 2.0
 de0: address 00:00:f8:06:29:15
 de0: enabling 100baseTX port
-vga0 at pci0 dev 7 function 0: Matrox MGA Millennium II 2164W (rev. 0x00)
-wsdisplay0 at vga0
+Matrox MGA Millennium II 2164W (VGA display) at pci0 dev 7 function 0 not configured
 sio0 at pci0 dev 8 function 0: Intel 82378ZB System I/O (SIO) (rev. 0x43)
 ncr0 at pci0 dev 9 function 0: ncr 53c810 fast10 scsi
 ncr0: interrupting at eb164 irq 3
@@ -53,15 +52,20 @@
 cd0(pciide0:1:1): using PIO mode 3, DMA mode 1 (using DMA data transfers)
 isa0 at sio0
 com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo
-com0: console
 com1 at isa0 port 0x2f8-0x2ff irq 3: ns16550a, working fifo
+vga0 at isa0 port 0x3b0-0x3df iomem 0xa0000-0xbffff
+wsdisplay0 at vga0: console (80x25, sun emulation)
 lpt0 at isa0 port 0x3bc-0x3bf irq 7
 pckbc0 at isa0 port 0x60-0x64
+pckbd0 at pckbc0 (kbd slot)
+pckbc0: using irq 1 for kbd slot
+wskbd0 at pckbd0: console keyboard
 pcppi0 at isa0 port 0x61
 spkr0 at pcppi0
 isabeep0 at pcppi0
 fdc0 at isa0 port 0x3f0-0x3f7 irq 6 drq 2
 mcclock0 at isa0 port 0x70-0x71: mc146818 or compatible
+wscons: wskbd0 glued to wsdisplay0 (console)
 root on sd0a dumps on sd0b
 ffs_mountfs: dev 0x800, rootpath nil
 ffs_mountfs returning success

(The last two lines, about ffs_mountfs, are debugging printfs from to
some unrelated ffs stuff I've done.)

The way the display moves from PCI to ISA, and the peculiar lack of ROM
console output to it when halting or rebooting, make me suspect the
console code is a bit wonky.  Is this a known problem, with either
NetBSD or some versions of the SRM console?  (Tomorrow, I'll be able to
check out the SRM console rev, but as I'm not at that site I can't do
that now.)

I can provide more detail if anyone has any suggestions for what might
be causing this.  One thing we're likely to try is an old ISA video
card, to see if it works at all....

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B