On Sat, Oct 20, 2012 at 01:55:07AM -0500, J Sisson wrote:
> I was reading:
>
> http://www.openbsd.org/papers/eurobsdcon2011-kettenis.pdf
>
> and noted the section about vcc. I read the vcc man page, and saw FILES
> /dev/ttyV[0-9a-zA-Z]. Looking at an Ultra5, I noted that ttyV0 existed
> (fresh install of latest snapshot + build of -CURRENT checked out
> yesterday). I realize the Ultra5 (400 MHz UltraSparc IIi) is not a
> T1/2...but I couldn't resist running the following to see what it would do
> (non production machine, so if it breaks anything no worries):
>
> cu -l ttyV0
>
> It immediately panic'd the machine. I grabbed trace/ps from the panic
> (dmesg at bottom):
This is a bug. Please report to bugs@
-Otto
>
> # cu -l ttyV0
> panic: kernel data fault: pc=150db04 addr=0
> kdb breakpoint at 146d380
> Stopped at Debugger+0x4: nop
> RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
> DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
> ddb> trace
> data_access_fault(40008dfd600, 30, 150db04, 0, 0, 800809) at
> data_access_fault+
> 0x294
> trapbase_sun4v(0, 0, 0, 0, 0, 40008dfdc70) at trapbase_sun4v+0x8790
> VOP_UNLOCK(7f00, 7, 2000, 40004899d40, 40004882805, 20c044) at
> VOP_UNLOCK+0x20
> spec_open(181fcc0, 2180, 0, 0, 80, 400048ac500) at spec_open+0x270
> VOP_OPEN(40004787b30, 7, 400048ac500, 40004899d40, 1, 40008dfd980) at
> VOP_OPEN+
> 0x24
> vn_open(0, 7, 40004787b30, 93b8b03454, 0, 800005) at vn_open+0x110
> doopenat(0, ffffffffffffff9c, 0, 7, 40, 40008dfde00) at doopenat+0xb0
> syscall(40008dfded0, 405, 93b5705a38, 93b5705a3c, 0, 91afc0d230) at
> syscall+0x3
> 18
> softtrap(93b1aed5a0, 6, 40, 91b000f0e0, 0, 93b0f78000) at softtrap+0x19c
> ddb> ps
> PID PPID PGRP UID S FLAGS WAIT COMMAND
> *27403 26124 27403 0 7 0 cu
> 26124 1 26124 0 3 0x88 pause ksh
> 30887 1 30887 0 3 0x80 select cron
> 12040 1 12040 99 3 0x80 poll sndiod
> 9978 1 9978 0 3 0x80 select inetd
> 1775 1 1775 0 3 0x80 select sendmail
> 4950 1 4950 0 3 0x80 select sshd
> 15327 26460 13216 83 3 0x80 poll ntpd
> 26460 13216 13216 83 3 0x80 poll ntpd
> 13216 1 13216 0 3 0x80 poll ntpd
> 11569 31544 31544 74 3 0x80 bpf pflogd
> 31544 1 31544 0 3 0x80 netio pflogd
> 18240 8831 8831 73 3 0x80 poll syslogd
> 8831 1 8831 0 3 0x80 netio syslogd
> 27203 1 27203 77 3 0x80 poll dhclient
> 27706 1 9832 0 3 0x80 poll dhclient
> 11 0 0 0 3 0x100200 aiodoned aiodoned
> 10 0 0 0 3 0x100200 syncer update
> 9 0 0 0 3 0x100200 cleaner cleaner
> 8 0 0 0 3 0x100200 reaper reaper
> 7 0 0 0 3 0x100200 pgdaemon pagedaemon
> 6 0 0 0 3 0x100200 bored crypto
> 5 0 0 0 3 0x100200 pftm pfpurge
> 4 0 0 0 3 0x100200 bored syswq
> 3 0 0 0 3 0x40100200 idle0
> 2 0 0 0 3 0x100200 kmalloc kmthread
> 1 0 1 0 3 0x80 wait init
> 0 -1 0 0 3 0x200 scheduler swapper
>
>
> I guess the real question I have is: what purpose does ttyV0 serve on an
> Ultra5 if not for the vcc driver (that the Ultra5 doesn't support?)? Have
> I missed something, or do I need to go back to RTFM some more? A cursory
> grepping through /usr/src for ttyV shows etc/etc.sparc64/MAKEDEV{,.md},
> which doesn't appear to check for vcc before creating ttyV*.
>
>
> dmesg:
>
> Copyright (c) 1982, 1986, 1989, 1991, 1993
> The Regents of the University of California. All rights reserved.
> Copyright (c) 1995-2012 OpenBSD. All rights reserved.
> http://www.OpenBSD.org
>
> OpenBSD 5.2-current (GENERIC) #1: Thu Oct 18 20:37:09 CDT 2012
> root@:/usr/src/sys/arch/sparc64/compile/GENERIC
> real mem = 268435456 (256MB)
> avail mem = 251494400 (239MB)
> mainbus0 at root: Sun Ultra 5/10 UPA/PCI (UltraSPARC-IIi 400MHz)
> cpu0 at mainbus0: SUNW,UltraSPARC-IIi (rev 9.1) @ 400 MHz
> cpu0: physical 16K instruction (32 b/l), 16K data (32 b/l), 2048K external
> (64 b/l)
> psycho0 at mainbus0 addr 0xfffc4000: SUNW,sabre, impl 0, version 0, ign 7c0
> psycho0: bus range 0-2, PCI bus 0
> psycho0: dvma map c0000000-dfffffff
> pci0 at psycho0
> ppb0 at pci0 dev 1 function 1 "Sun Simba PCI-PCI" rev 0x13
> pci1 at ppb0 bus 1
> ebus0 at pci1 dev 1 function 0 "Sun PCIO EBus2" rev 0x01
> auxio0 at ebus0 addr 726000-726003, 728000-728003, 72a000-72a003,
> 72c000-72c003, 72f000-72f003
> power0 at ebus0 addr 724000-724003 ivec 0x25
> "SUNW,pll" at ebus0 addr 504000-504002 not configured
> sab0 at ebus0 addr 400000-40007f ivec 0x2b: rev 3.2
> sabtty0 at sab0 port 0: console
> sabtty1 at sab0 port 1
> comkbd0 at ebus0 addr 3083f8-3083ff ivec 0x29: no keyboard
> comms0 at ebus0 addr 3062f8-3062ff ivec 0x2a
> wsmouse0 at comms0 mux 0
> lpt0 at ebus0 addr 3043bc-3043cb, 30015c-30015d, 700000-70000f ivec 0x22:
> polled
> clock1 at ebus0 addr 0-1fff: mk48t59
> "flashprom" at ebus0 addr 0-fffff not configured
> audioce0 at ebus0 addr 200000-2000ff, 702000-70200f, 704000-70400f,
> 722000-722003 ivec 0x23 ivec 0x24: nvaddrs 0
> audio0 at audioce0
> hme0 at pci1 dev 1 function 1 "Sun HME" rev 0x01: ivec 0x7e1, address
> 08:00:20:fe:41:1e
> nsphy0 at hme0 phy 1: DP83840 10/100 PHY, rev. 1
> machfb0 at pci1 dev 2 function 0 "ATI Mach64" rev 0x5c
> machfb0: ATY,GT-C, 1152x900
> wsdisplay0 at machfb0 mux 1
> wsdisplay0: screen 0 added (std, sun emulation)
> pciide0 at pci1 dev 3 function 0 "CMD Technology PCI0646" rev 0x03: DMA,
> channel 0 configured to native-PCI, channel 1 configured to native-PCI
> pciide0: using ivec 0x7e0 for native-PCI interrupt
> wd0 at pciide0 channel 0 drive 0: <ST380013A>
> wd0: 16-sector PIO, LBA48, 76319MB, 156301488 sectors
> wd0(pciide0:0:0): using PIO mode 4, DMA mode 2
> pciide0: channel 1 disabled (no drives)
> ppb1 at pci0 dev 1 function 0 "Sun Simba PCI-PCI" rev 0x13
> pci2 at ppb1 bus 2
> de0 at pci2 dev 1 function 0 "DEC 21140" rev 0x22, 21140A pass 2.2: ivec
> 0x7d0, address 00:c0:f0:16:9f:e3
> vscsi0 at root
> scsibus0 at vscsi0: 256 targets
> softraid0 at root
> scsibus1 at softraid0: 256 targets
> bootpath: /pci@1f,0/pci@1,1/ide@3,0/disk@0,0
> root on wd0a (5c3fe176e8a9ff13.a) swap on wd0b dump on wd0b
>
>
> Jonathon
