Fell victim to sendbug/Fwd. If this is sent multiple times, I apologize. Bug Report:
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): # 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 -- Computers are like air conditioners... They quit working when you open Windows.
