Re: Where'd dz0 go?

[Johnny Billquist <bqt%softjar.se@localhost>]

Hans Rosenfeld wrote:
> Hi,
>
> On Fri, May 21, 2010 at 02:48:44AM -0400, Nathaniel W Filardo wrote:
> > I've got a uV3 running NetBSD 5.0.2 with something I don't quite understand.
> > dmesg says:
> >
> > > boot netbsd
> > 2388172+308476 [193664+183590]=0x2eea9c
> > Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
> >     2006, 2007, 2008, 2009
> >     The NetBSD Foundation, Inc.  All rights reserved.
> > Copyright (c) 1982, 1986, 1989, 1991, 1993
> >     The Regents of the University of California.  All rights reserved.
> >
> > NetBSD 5.0.2 (GENERIC) #0: Sat Feb  6 22:45:58 UTC 2010
> >         
> > builds%b8.netbsd.org@localhost:/home/builds/ab/netbsd-5-0-2-RELEASE/vax/201002061851Z-obj/home/builds/ab/netbsd-5-0-2-RELEASE/src/sys/arch/vax/compile/GENERIC
> > MicroVAX 3500/3600
> > total memory = 16328 KB
> > avail memory = 12480 KB
> > mainbus0 (root)
> > cpu0 at mainbus0: KA650, CVAX microcode rev 4 Firmware rev 83
> > lance at mainbus0 not configured
> > uba0 at mainbus0: Q22
> > dz1 at uba0 csr 160100 vec 344 ipl 17
> > ...
>
> from sys/arch/vax/conf/GENERIC:
> dz0             at vsbus0 csr 0x200a0000 # DC-367 DZ-11 lookalike ctlr
> dz0             at vsbus0 csr 0x25000000 # VS4000/90 and 4000/10x serial line
>
> Maybe we should change that to dz*.

Well, you did forget the third line, which actually is what he maps to:

dz*             at uba? csr 0160100     # DZ-11

I guess you could have multiple 'dz* ...' lines though.

But to explain to the op, since dz0 is explicitly mentioned in the 
config, nothing else will be allocated as dz0, so the first "free" dz, 
is dz1.

> > but the processor itself says
> >
> > > > > show qbus
> > Scan of Qbus I/O Space
> > -20000040 (760100) = 0000 (300) DZQ11/DZV11/DFA01
> > -20000042 (760102) = 0000
> > -20000044 (760104) = 0000
> > -20000046 (760106) = 0000
> > -20001468 (772150) = 0000 (154) RQDX3/KDA50/RRD50/RQC25/KFQSA-DISK
> > -2000146A (772152) = 0B00
> > -20001920 (774440) = FF08 (120) DELQA/DEQNA/DESQA
> > -20001922 (774442) = FF00
> > -20001924 (774444) = FF2B
> > -20001926 (774446) = FF03
> > -20001928 (774450) = FF73
> > -2000192A (774452) = FFBA
> > -2000192C (774454) = 03FC
> > -2000192E (774456) = 1030
> > -20001F40 (777500) = 0020 (004) IPCR
> >
> > Scan of Qbus Memory Space
> > so the question I have is: where'd dz0 go (it's never listed in dmesg, and
> > attempts to manipulate tty0[0-7] yield "device not configured") and why is
>
> You could try using tty08 (MAKEDEV it if it doesn't exist). Or you could
> build a custom kernel to make sure it is dz0.

Right.

> > dz1 reported as being on vec 344?  Checking the DIP switches I _think_ the
> > "show qbus" output is right and that the "dz1 at" line is wrong.
>
> Maybe the dz driver got it wrong. Try to test it with tty08 or a custom
> kernel.

The kernel tries to autodetect the vectors, by making them field an 
interrupts, and then see what vector it came through. If something else 
was causing interrupts, that could fool the system. But I'm not sure 
what that could be, by looking at this output.

Hans suggestion is easy to try, and should tell you wether NetBSD got it 
wrong or not.

However, also note that the "SHOW QBUS" command might not actually be 
probing the vectors, but just telling what they should be, based on the 
DEC autoconfiguration rules (that's a thing to implement a sunny day - 
autodetection and configuration of devices for Unibus/Qbus).

        Johnny