recent mips updates causes asc0 problems on pmax port

Deal all mips/pmax people:


When booting a pmax kernel on a DECStation 5000 with a kernel built
from sources current as of yesterday, I see several messages
apparently indicating SCSI or disk problems:

NetBSD 5.99.15 (SOCKDEV) #24: Tue Aug 11 05:02:19 CEST 2009
	[email protected]:/home/NetBSD/src/sys/arch/pmax/compile/SOCKDEV
DECstation 5000/133 (3MIN)
total memory = 32768 KB
avail memory = 29840 KB
mainbus0 (root)
cpu0 at mainbus0: MIPS R3000A CPU (0x230) Rev. 3.0 with MIPS R3010 FPC Rev. 4.0
cpu0: 64KB/4B direct-mapped Instruction cache, 64 TLB entries
cpu0: 128KB/4B direct-mapped write-through Data cache
tc0 at mainbus0: 12.5 MHz clock
ioasic0 at tc0 slot 3 offset 0x0
le0 at ioasic0 offset 0xc0000: address 08:00:2b:32:56:6f
le0: 32 receive buffers, 8 transmit buffers
zsc0 at ioasic0 offset 0x100000
vsms0 at zsc0 channel 0
wsmouse0 at vsms0 (mux ignored)
zstty0 at zsc0 channel 1
zsc1 at ioasic0 offset 0x180000
lkkbd0 at zsc1 channel 0
wskbd0 at lkkbd0 (mux ignored)
zstty1 at zsc1 channel 1 (console i/o)
mcclock0 at ioasic0 offset 0x200000: mc146818 or compatible
asc0 at ioasic0 offset 0x300000: NCR53C94, 25MHz, SCSI ID 7
scsibus0 at asc0: 8 targets, 8 luns per target
scsibus0: waiting 2 seconds for devices to settle...
sd0 at scsibus0 target 4 lun 0: <QUANTUM, QM39100TD-S, N1B0> disk fixed
sd0: 8683 MB, 8057 cyl, 10 head, 220 sec, 512 bytes/sect x 17783249 sectors
sd0: sync (200.00ns offset 15), 8-bit (5.000MB/s) transfers, tagged queueing
boot device: sd0
root on sd0a dumps on sd0b
root file system type: ffs
Fri Jan  1 01:00:27 CET 2010
ioasic_intr: xfer (-33552896) > req (2048)
asc0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 1, resid 800
asc0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 0
ioasic_intr: xfer (-33550848) > req (4096)
asc0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 1, resid 1000
asc0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 0
Starting root file system check:
/dev/rsd0a: file system is clean; not checking
swapctl: adding /dev/sd0b as swap device at priority 0
Starting file system checks:
/dev/rsd0a: file system is mounted read-write on /; not checking
Setting tty flags.
Setting sysctl variables:
Starting network.
Hostname: sockdev.h.erikb.net
Configuring network interfaces: le0.
Adding interface aliases:.
add net default: gateway 192.168.22.1
Building databases: devioasic_intr: xfer (-436206080) > req (8192)
asc0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 1, resid 4000
asc0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 0
, utmp, utmpx done
Starting syslogd.
ioasic_intr: xfer (-503315968) > req (8192)
asc0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 1, resid 4000
asc0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 0
[1]   Segmentation fault (core dumped) /usr/sbin/syslog...
Setting date via ntp.
Mounting all filesystems...
ioasic_intr: xfer (-502791680) > req (8192)
asc0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 0, resid 2000
Clearing temporary files.
Checking quotas: done.
Setting securelevel: kern.securelevel: 0 -> 1
Starting local daemons:.
Updating motd.
Starting sshd.
ioasic_intr: xfer (-503315968) > req (8192)
asc0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 1, resid 4000
asc0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 0
ioasic_intr: xfer (-503315968) > req (8192)
asc0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 1, resid 4000
asc0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 0
[1]   Segmentation fault (core dumped) /usr/sbin/sshd
ioasic_intr: xfer (-503315968) > req (8192)
asc0: !TC on DATA XFER [intr 10, stat 87, step 4] prevphase 1, resid 4000
asc0: !TC on DATA XFER [intr 10, stat 83, step 4] prevphase 1, resid 0
[1]   Segmentation fault (core dumped) ${postconf} -h a...
[1]   Segmentation fault (core dumped) ${postfix_comman...
Starting inetd.
Starting cron.
Tue Aug 11 07:26:34 CEST 2009

NetBSD/pmax (sockdev.h.erikb.net) (console)

login:


If I reboot using a kernel built on July 12th, I did not see this
problem. At the last attempt of booting a new kernel (the one with
the console output listed above), the file system was actually
damaged. A couple of previous attempts of booting a new kernel
also listed several asc0 error messages and several daemons could not
start, but apparently without hosing the file system.

I can now boot into single-user mode, but e.g. /usr/bin is damaged:

# ls usr/bin
ls: usr/bin: Bad file descriptor
# ls -l usr
ls: bin: Bad file descriptor
total 46
drwxr-xr-x   8 root  wheel    512 Feb 26  2007 X11R6
drwxr-xr-x   8 root  wheel    512 Apr  4  2005 X11R6.xf86
drwxr-xr-x   8 root  wheel    512 Oct  6  2008 X11R7
drwxr-xr-x   3 root  wheel   1024 Aug  8 23:35 games
drwxr-xr-x  47 root  wheel   4096 Aug  9 09:48 include
drwxr-xr-x   5 root  wheel  16384 Aug  9 10:01 lib
drwxr-xr-x   6 root  wheel    512 Oct 20  2008 libdata
drwxr-xr-x   5 root  wheel   1024 Aug  9 01:59 libexec
drwxr-xr-x   2 root  wheel    512 Aug  9 07:03 mdec
drwxr-xr-x   7 root  wheel    512 Aug  9 14:16 pkg
drwxr-xr-x   2 root  wheel   5632 Aug  9 01:58 sbin
drwxr-xr-x  29 root  wheel    512 Nov  1  2008 share
drwxr-xr-x  13 root  wheel    512 Jul 15 09:15 tests


Running fsck does not look promising:

# fsck
** /dev/rsd0a
** Last Mounted on /
** Root file system
** Phase 1 - Check Blocks and Sizes
UNKNOWN FILE TYPE I=882380
CLEAR? [yn] y

UNKNOWN FILE TYPE I=882382
CLEAR? [yn] y

UNKNOWN FILE TYPE I=882383
CLEAR? [yn] y

UNKNOWN FILE TYPE I=882384
CLEAR? [yn] y

UNKNOWN FILE TYPE I=882385
CLEAR? [yn] y

PARTIALLY ALLOCATED INODE I=882386
CLEAR? [yn] y

PARTIALLY ALLOCATED INODE I=882387


I'll leave the machine for now, but I'll probably have to run a fsck
-y to clear all these when I return.

Any explanations ??

- Erik