NetBSD Problem Report #9679

Received: (qmail 29178 invoked from network); 26 Mar 2000 22:40:56 -0000
Message-Id: <200003262139.XAA17161@q700.hf.org>
Date: Sun, 26 Mar 2000 23:39:56 +0200 (CEST)
From: hauke@Espresso.Rhein-Neckar.DE
Reply-To: hauke@Espresso.Rhein-Neckar.DE
To: gnats-bugs@gnats.netbsd.org
Cc: hauke@Espresso.Rhein-Neckar.DE
Subject: Using scsi/libscsi lets mac68k sbc driver dump core
X-Send-Pr-Version: 3.95

>Number:         9679
>Category:       port-mac68k
>Synopsis:       Using scsi/libscsi lets mac68k sbc driver dump core
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-mac68k-maintainer
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Mar 26 14:42:00 +0000 2000
>Closed-Date:    Mon Nov 28 23:38:59 +0000 2011
>Last-Modified:  Mon Nov 28 23:38:59 +0000 2011
>Originator:     Hauke Fath
>Release:        1.4V
>Organization:
Einzeln auftretender Radfahrer
>Environment:
NetBSD 1.4V (CHUCK) #5: Thu Mar 23 00:27:26 CET 2000
    hauke@q700.hf.org:/usr/src/sys/arch/mac68k/compile/CHUCK
Apple Macintosh IIcx  (68030)

>Description:
I have ported the FreeBSD /sbin/scsi tool to NetBSD that sits on top 
of their libscsi (we have that as a package, and the man page even 
references scsi(8) =8> ). There wasn't much to do, and it works just fine 
on sparc (esp driver), on mac68k/esp and on mac68k/ncrscsi (although that 
has other problems with the DEC disk in question).

The mac68k/sbc driver, on the other hand, locks up hard in multiuser --
I cannot even drop into the kernel debugger. In single user, I get a panic.

-----------------------------------------------------------------------
# $Id: CHUCK,v 1.1 2000/03/19 22:00:01 hauke Exp hauke $
#
# Kernel definition for Macintosh IIcx (IIsi?) 
#
# derived from $NetBSD: GENERIC,v 1.98 2000/02/29 06:32:25 simonb Exp $

include	"arch/mac68k/conf/std.mac68k"

#ident 		"GENERIC-$Revision: 1.1 $"

maxusers	16		# estimated number of users

makeoptions	COPTS="-pipe -m68030"
makeoptions	DEBUG="-g"	# compile full symbol table

# CPU support.  At least one is REQUIRED.
options 	M68030

# Standard system options

options 	RTC_OFFSET=0	# hardware clock is this many mins. west of GMT
options 	NTP		# NTP phase/frequency locked loop

options 	KTRACE		# system call tracing via ktrace(1)

options 	SYSVMSG		# System V-like message queues
options 	SYSVSEM		# System V-like semaphores
options 	SYSVSHM		# System V-like memory sharing
#options 	SHMMAXPGS=1024	# 1024 pages is the default

# Diagnostic/debugging support options
options 	DIAGNOSTIC	# cheap kernel consistency checks
options 	DEBUG		# expensive debugging checks/support
options 	KMEMSTATS	# kernel memory statistics (vmstat -m)
options 	DDB		# in-kernel debugger
options 	DDB_HISTORY_SIZE=200	# enable history editing in DDB

# Compatibility options
options 	COMPAT_13	# NetBSD 1.3,
options 	COMPAT_14	# NetBSD 1.4,
options 	COMPAT_43	# and 4.3BSD

# File systems
file-system 	FFS		# UFS
file-system 	MFS		# memory file system
file-system 	NFS		# Network File System client
file-system 	KERNFS		# /kern
file-system 	PROCFS		# /proc

# File system options
options 	QUOTA		# UFS quotas
#options 	SOFTDEP		# FFS soft updates support.
#options 	NFSSERVER	# Network File System server

# Pull in config fragments for kernel crypto.  This is required for
# options IPSEC etc. to work. If you want to run with IPSEC, uncomment
# one of these, based on whether you use crypto-us or crypto-intl, and
# adjust the prefixes as necessary.

#prefix ../crypto-intl/sys
#cinclude "conf/files.crypto-intl"
#prefix

# Networking options
#options 	GATEWAY		# packet forwarding
options 	INET		# IP + ICMP + TCP + UDP

# These options enable verbose messages for several subsystems.
# Warning, these may compile large string tables into the kernel!
options 	SCSIVERBOSE	# human readable SCSI error messages

# wscons options
options 	WSEMUL_VT100		# VT100 / VT220 emulation
options 	WSDISPLAY_COMPAT_ITEFONT # use ite font (6x10)

# rcons options; note that 1-bit and 8-bit displays are supported by default.
options 	RCONS_2BPP		# Support for 2-bit display
options 	RCONS_4BPP		# Support for 4-bit display

# Mac-specific options
options 	GRF_COMPAT	# Include grf compatibility code
#options 	MRG_ADB		# Use ROM-based ADB driver
options 	NFS_BOOT_BOOTP

# Kernel root file system and dump configuration.
config		netbsd	root on ? type ffs

#
# Device configuration
#

mainbus0 at root

fpu0 at mainbus?			# Floating-Point Coprocessor support


# Basic Bus Support

# On-board I/O bus support
obio0 at mainbus?

# NuBus support
nubus0 at mainbus?


# Console Devices

# Apple Desktop Bus interface
adb0	at obio?
aed*	at adb?				# ADB event device
akbd*	at adb?				# ADB keyboard
ams*	at adb?				# ADB mouse

# Basic frame buffer support
intvid0	at obio?			# Internal video hardware
macvid*	at nubus?			# NuBus video card

# Device-independent frame buffer interface
macfb*	at intvid?
macfb*	at macvid?

# Workstation Console devices
wsdisplay0 at macfb? console ?
wskbd0	at akbd? console ?
wsmouse0 at ams?


# Serial Devices

# On-board serial interface
zsc0	at obio?
zstty*	at zsc? channel ?


# SCSI Controllers and Devices

options		SCSIDEBUG
options		SBC_DEBUG

# SCSI Controllers and Devices

# SBC_PDMA      0x01    /* Use PDMA for polled transfers */
# SBC_INTR      0x02    /* Allow SCSI IRQ/DRQ interrupts */
# SBC_RESELECT  0x04    /* Allow disconnect/reselect */
sbc0	at obio? flags 0x1		# MI SCSI NCR 5380

# Not with DEC DSP3107LS
#ncrscsi0 at obio?			# SCSI NCR 5380


# SCSI bus support
scsibus* at scsi?

# SCSI devices
sd*	at scsibus? target ? lun ?	# SCSI disk drives

# Miscellaneous mass storage devices

# IWM floppy disk controller
iwm0	at obio?			# Sony driver (800K GCR)
fd*	at iwm? drive ?


# Network Interfaces

# NuBus Ethernet controllers
ae*	at nubus?			# DP8390-based


# Audio Devices

# On-board audio hardware
asc0	at obio?			# ASC/EASC audio

# Pseudo-Devices

# network pseudo-devices
pseudo-device	bpfilter	12	# Berkeley packet filter
pseudo-device	loop			# network loopback

# miscellaneous pseudo-devices
pseudo-device	grf		2	# grf emulation for wscons
pseudo-device	ite		1	# ite emulation for wscons
pseudo-device	pty		64	# pseudo-terminals
pseudo-device	rnd			# /dev/random and in-kernel generator
-----------------------------------------------------------------------

>How-To-Repeat:
Install the devel/libscsi package, get scsi from
<http://www.tangro.de/~hf/macbsd/scsi.tar.gz>

Boot to single user, mount partitions read-only, 
try to read a mode page

# mount -r -a
# df
Filesystem  1K-blocks     Used    Avail Capacity  Mounted on
/dev/sd0a       29330    18096     9767    64%    /
mfs:14           9647        1     9163     0%    /tmp
/dev/sd0e      204263    13724   180325     7%    /var
/dev/sd0g      297871    89069   193908    31%    /usr
/dev/sd0f       93505    13927    74902    15%    /home
/dev/sd0h      251136    36000   202579    15%    /local
# whereis scsi
/usr/local/sbin/scsi
# scsi -f /dev/rsd1c -m8 -P3 -v
sd1(sbc0:2:0): sdopen: dev=0xd0a (unit 1 (of 4), partition 2)
sd1(sbc0:2:0): scsi_scsipi_cmd
sd1(sbc0:2:0): scsipi_get_xs
sd1(sbc0:2:0): calling pool_get
sd1(sbc0:2:0): returning
scsipi_exec_cmd: xs(0x3ec000): xs_control(0x000001c0)xs_status(0x00000000)sc_lin
k(0x3dd480)retr(0x4)timo(0x2710)cmd(0x3ec068)len(0x6)data(0x0)len(0x0)res(0x0)er
r(0x0)bp(0x0)sd1(sbc0:2:0): command: 0x0,0x0,0x0,0x0,0x0,0x0-[0 bytes]

sd1(sbc0:2:0): scsipi_done
sd1(sbc0:2:0): command: 0x0,0x0,0x0,0x0,0x0,0x0-[0 bytes]
sd1(sbc0:2:0): back in cmd()
sd1(sbc0:2:0): sc_err1,err = 0x0
sd1(sbc0:2:0): scsipi_free_xs
sd1(sbc0:2:0): calling private start()
sd1(sbc0:2:0): sdstart sd1(sbc0:2:0): scsi_scsipi_cmd
sd1(sbc0:2:0): scsipi_get_xs
sd1(sbc0:2:0): calling pool_get
sd1(sbc0:2:0): returning
scsipi_exec_cmd: xs(0x3ec000): xs_control(0x000001a0)xs_status(0x00000000)sc_lin
k(0x3dd480)retr(0x4)timo(0xea60)cmd(0x3ec068)len(0x6)data(0x0)len(0x0)res(0x0)er
r(0x0)bp(0x0)sd1(sbc0:2:0): command: 0x1b,0x0,0x0,0x0,0x1,0x0-[0 bytes]

sd1(sbc0:2:0): scsipi_done
sd1(sbc0:2:0): command: 0x1b,0x0,0x0,0x0,0x1,0x0-[0 bytes]
sd1(sbc0:2:0): back in cmd()
sd1(sbc0:2:0): sc_err1,err = 0x0
sd1(sbc0:2:0): scsipi_free_xs
sd1(sbc0:2:0): calling private start()
sd1(sbc0:2:0): sdstart sd1(sbc0:2:0): scsi_scsipi_cmd
sd1(sbc0:2:0): scsipi_get_xs
sd1(sbc0:2:0): calling pool_get
sd1(sbc0:2:0): returning
scsipi_exec_cmd: xs(0x3ec000): xs_control(0x00000180)xs_status(0x00000000)sc_lin
k(0x3dd480)retr(0x4)timo(0x1388)cmd(0x3ec068)len(0x6)data(0x0)len(0x0)res(0x0)er
r(0x0)bp(0x0)sd1(sbc0:2:0): command: 0x1e,0x0,0x0,0x0,0x1,0x0-[0 bytes]

sd1(sbc0:2:0): scsipi_done
sd1(sbc0:2:0): command: 0x1e,0x0,0x0,0x0,0x1,0x0-[0 bytes]
sd1(sbc0:2:0): back in cmd()
sd1(sbc0:2:0): sc_err1,err = 0x1
code 0x70 valid 0x0 seg 0x0 key 0x5 ili 0x0 eom 0x0 fmark 0x0
info: 0x0 0x0 0x0 0x0 followed by 10 extra bytes
extra: 0x0 0x0 0x0 0x0 0x20 0x0 0x0 0x0 0x0 0x0
sd1(sbc0:2:0): calling private err_handler()
sd1(sbc0:2:0): scsipi_interpret_sense returned 0
sd1(sbc0:2:0): scsipi_free_xs
sd1(sbc0:2:0): calling private start()
sd1(sbc0:2:0): sdstart sd1(sbc0:2:0): scsi_scsipi_cmd
sd1(sbc0:2:0): scsipi_get_xs
sd1(sbc0:2:0): calling pool_get
sd1(sbc0:2:0): returning
scsipi_exec_cmd: xs(0x3ec000): xs_control(0x00000820)xs_status(0x00000000)sc_lin
k(0x3dd480)retr(0x4)timo(0x1770)cmd(0x3ec068)len(0x6)data(0x71cd30)len(0x2c)res(
0x2c)err(0x0)bp(0x0)sd1(sbc0:2:0): command: 0x1a,0x0,0x4,0x0,0x20,0x0-[44 bytes]
------------------------------
000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
016: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
032: 00 00 00 00 00 00 00 00 00 00 00 00
------------------------------

sd1(sbc0:2:0): scsipi_done
sd1(sbc0:2:0): command: 0x1a,0x0,0x4,0x0,0x20,0x0-[44 bytes]
------------------------------
000: 1f 00 00 08 00 07 50 76 00 00 02 00 04 12 00 07
016: 1a 04 00 07 1a 00 07 1a 00 00 00 00 00 00 00 00
032: 00 00 00 00 00 00 00 00 00 00 00 00
------------------------------
sd1(sbc0:2:0): back in cmd()
sd1(sbc0:2:0): sc_err1,err = 0x0
sd1(sbc0:2:0): scsipi_free_xs
sd1(sbc0:2:0): calling private start()
sd1(sbc0:2:0): sdstart sd1(sbc0:2:0): 1818 cyls, 4 heads, 7 precomp, 7 red_write
, 0 land_zone
sd1(sbc0:2:0): scsi_scsipi_cmd
sd1(sbc0:2:0): scsipi_get_xs
sd1(sbc0:2:0): calling pool_get
sd1(sbc0:2:0): returning
scsipi_exec_cmd: xs(0x3ec000): xs_control(0x00000800)xs_status(0x00000000)sc_lin
k(0x3dd480)retr(0x4)timo(0x4e20)cmd(0x3ec068)len(0xa)data(0x71cd00)len(0x8)res(0
x8)err(0x0)bp(0x0)sd1(sbc0:2:0): command: 0x25,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0
x0-[8 bytes]
------------------------------
000: 00 11 70 2c 00 00 07 1a
------------------------------

sd1(sbc0:2:0): scsipi_done
sd1(sbc0:2:0): command: 0x25,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0-[8 bytes]
------------------------------
000: 00 07 50 75 00 00 02 00
------------------------------
sd1(sbc0:2:0): back in cmd()
sd1(sbc0:2:0): sc_err1,err = 0x0
sd1(sbc0:2:0): scsipi_free_xs
sd1(sbc0:2:0): calling private start()
sd1(sbc0:2:0): sdstart sd1(sbc0:2:0): Params loaded sd1(sbc0:2:0): sdstrategy sd
1(sbc0:2:0): 512 bytes @ blk 0
sd1(sbc0:2:0): sdstart sd1(sbc0:2:0): scsi_scsipi_cmd
sd1(sbc0:2:0): scsipi_get_xs
sd1(sbc0:2:0): calling pool_get
sd1(sbc0:2:0): returning
scsipi_exec_cmd: xs(0x3ec000): xs_control(0x00000809)xs_status(0x00000000)sc_lin
k(0x3dd480)retr(0x4)timo(0xea60)cmd(0x3ec068)len(0x6)data(0x1400000)len(0x200)re
s(0x200)err(0x0)bp(0x6e9ad4)sd1(sbc0:2:0): command: 0x8,0x0,0x0,0x0,0x1,0x0-[512
 bytes]
------------------------------
000: 50 4d 00 00 00 00 00 07 00 00 00 01 00 00 00 3f
016: 41 70 70 6c 65 00 00 00 00 00 00 00 00 00 00 00
032: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
048: 41 70 70 6c 65 5f 70 61 72 74 69 74 69 6f 6e 5f
------------------------------

sd1(sbc0:2:0): scsipi_done
sd1(sbc0:2:0): command: 0x8,0x0,0x0,0x0,0x1,0x0-[512 bytes]
------------------------------
000: 45 52 02 00 00 07 50 76 00 01 00 01 00 00 00 00
016: 00 01 00 00 00 40 00 13 00 01 00 00 00 00 00 00
032: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
048: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
------------------------------
sd1(sbc0:2:0): sc_err1,err = 0x0
sd1(sbc0:2:0): scsipi_free_xs
sd1(sbc0:2:0): calling private start()
sd1(sbc0:2:0): sdstart sd1(sbc0:2:0): sdstrategy sd1(sbc0:2:0): 16384 bytes @ bl
k 1
sd1(sbc0:2:0): sdstart sd1(sbc0:2:0): scsi_scsipi_cmd
sd1(sbc0:2:0): scsipi_get_xs
sd1(sbc0:2:0): calling pool_get
sd1(sbc0:2:0): returning
scsipi_exec_cmd: xs(0x3ec000): xs_control(0x00000809)xs_status(0x00000000)sc_lin
k(0x3dd480)retr(0x4)timo(0xea60)cmd(0x3ec068)len(0x6)data(0x1760000)len(0x4000)r
es(0x4000)err(0x0)bp(0x6eb4fc)sd1(sbc0:2:0): command: 0x8,0x0,0x0,0x1,0x20,0x0-[
16384 bytes]
------------------------------
000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
016: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
032: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
048: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
------------------------------

sd1(sbc0:2:0): scsipi_done
sd1(sbc0:2:0): command: 0x8,0x0,0x0,0x1,0x20,0x0-[16384 bytes]
------------------------------
000: 50 4d 00 00 00 00 00 07 00 00 00 01 00 00 00 3f
016: 41 70 70 6c 65 00 00 00 00 00 00 00 00 00 00 00
032: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
048: 41 70 70 6c 65 5f 70 61 72 74 69 74 69 6f 6e 5f
------------------------------
sd1(sbc0:2:0): sc_err1,err = 0x0
sd1(sbc0:2:0): scsipi_free_xs
sd1(sbc0:2:0): calling private start()
sd1(sbc0:2:0): sdstart sd1(sbc0:2:0): Disklabel loaded sd1(sbc0:2:0): open compl
ete
sd1(sbc0:2:0): sdioctl 0xc05e5101 sd1(sbc0:2:0): scsipi_do_ioctl(0xc05e5101)
sd1(sbc0:2:0): user_strategy
sd1(sbc0:2:0): scsi_scsipi_cmd
sd1(sbc0:2:0): scsipi_get_xs
sd1(sbc0:2:0): calling pool_get
sd1(sbc0:2:0): returning
scsipi_exec_cmd: xs(0x3ec000): xs_control(0x00000818)xs_status(0x00000000)sc_lin
k(0x3dd480)retr(0x0)timo(0x7d0)cmd(0x3ec068)len(0x6)data(0x2000c18)len(0xff)res(
0xff)err(0x0)bp(0x3f3808)sd1(sbc0:2:0): command: 0x1a,0x0,0xc8,0x0,0xff,0x0-[255
 bytes]
------------------------------
000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
016: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
032: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
048: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
------------------------------

trap type 0, code = 0x75d, v = 0x8c9003
kernel program counter = 0x119ef4
kernel: Bus error trap
pid = 22, pc = 00119EF4, ps = 2200, sfc = 1, dfc = 1
Registers:
             0        1        2        3        4        5        6        7
dreg: 00000000 00000000 0000007F 00002214 00000000 00000009 00000001 00000000
areg: 02000C1C 008C9000 008D3020 003F3808 0071CEAC 0005827E 0071CB40 FFFFCB70

Kernel stack (0071CA20):
71CA20: 0012EE50 0071CA7C 00000080 0000007F 00002214 008D3020 00002204 00002204
71CA40: 0071CA6C 001113A0 006EA500 00000000 00000000 00000000 00000000 00002204
71CA60: 00000000 006F3640 0071CB40 00003086 00000000 0000075D 008C9003 00000000
71CA80: 00000000 0000007F 00002214 00000000 00000009 00000001 00000000 02000C1C
71CAA0: 008C9000 008D3020 003F3808 0071CEAC 0005827E 0071CB40 FFFFCB70 00000000
71CAC0: 22000011 9EF4B008 1EEE075D 58AE0014 008C9003 02000C1C 02000C1C 20912091
71CAE0: 00119EFA 00119EF8 00119EF6 00000000 58AEFF04 000FF481 02000C1C 008C7002
71CB00: 00000048 00000048 20200000 0071CB38 00000000 00000818 0071CB14 00000001
71CB20: 00000078 00119DD8 00002214 00002214 000000FF 008D5000 008C9000 003E2800
71CB40: 0071CB70 00008374 003E2800 00000001 000000FF 02000C1C 00000007 003DD480
71CB60: 00000000 00000001 003EC000 003E28F6 0071CB9C 00008738 003E2800 00000001
71CB80: 00001E00 003DD480 002DC5AE 00000001 00000000 003EC000 003E28F6 0071CBCC
71CBA0: 00006FD8 003E2800 FFFFFFFF 003E28F6 003DD480 00000078 00000000 00000000
71CBC0: 00000002 003EC000 003E28F6 0071CC00 000067BA 003E2800 00000008 003F38AC
71CBE0: 000065DC 00002004 00000818 00000000 00000000 00002004 003E28F6 003E2800
71CC00: 0071CC28 001114D2 003EC000 00000000 003F38AC 003DD480 00000006 02000C18
panic: Bus error
Stopped in scsi at      _cpu_Debugger+0x6:      unlk    a6
db> t
_cpu_Debugger(71ca2c,100,71ca68,12ee7e,12e97d) + 6
_panic(12e97d) + 56
_trap(0,75d,8c9003) + 2b6
_sbc_pdma_in(3e2800,1,ff,2000c1c) + 11c
_ncr5380_data_xfer(3e2800,1) + 20c
_ncr5380_machine(3e2800) + 182
_ncr5380_sched(3e2800) + 40e
_ncr5380_scsi_cmd(3ec000) + 1da
_scsipi_execute_xs(3ec000) + 90
_scsi_scsipi_cmd(3dd480,3f38b4,6,2000c18,ff,0,7d0,3f3808,818) + 14a
_scsistrategy(3f3808) + 188
_physio(11249c,3f3808,d0a,100000,1c04c,3f3884) + 2fa
_scsipi_do_ioctl(3dd480,d0a,c05e5101,71ceac,3,6f3640) + 1d2
_sdioctl(d0a,c05e5101,71ceac,3,6f3640) + 552
_spec_ioctl(71cdc0) + 8c
_VOP_IOCTL(7100d0,c05e5101,71ceac,3,3ddf00,6f3640) + 5a
_vn_ioctl(70c060,c05e5101,71ceac,6f3640) + d4
_sys_ioctl(6f3640,71cf6c,71cf64) + 338
_syscall(36) + 1b4
_trap0() + e
db> ps
 PID             PPID       PGRP        UID S   FLAGS          COMMAND    WAIT
 >22                 5         22          0 2  0x4006             scsi
  14                 1         14          0 3    0x84        mount_mfs  mfsidl
  5                  1          5          0 3  0x4086               sh    wait
  4                  0          0          0 3 0x20204          ioflush  syncer
  3                  0          0          0 3 0x20204           reaper  reaper
  2                  0          0          0 3 0x20204       pagedaemon daemon_
  1                  0          1          0 3  0x4084             init    wait
  0                 -1          0          0 3 0x20204          swapper schedul
 db> x /i _sbc_pdma_in + 100
 _sbc_pdma_in+0x100:     beqb    <_sbc_pdma_in+0x106>    [addr:0x119ede ]
 _sbc_pdma_in+0x102:     braw    <_sbc_pdma_in+0x2fe>    [addr:0x11a0d6 ]
 _sbc_pdma_in+0x106:     moval   a6@(0x14),a0
 _sbc_pdma_in+0x10a:     moval   a6@(-0x8),a1
 _sbc_pdma_in+0x10e:     movl    a1@,a0@
 _sbc_pdma_in+0x110:     addql   #0x4,a6@(0x14)
 _sbc_pdma_in+0x114:     moval   a6@(0x14),a0
 _sbc_pdma_in+0x118:     moval   a6@(-0x8),a1
 _sbc_pdma_in+0x11c:     movl    a1@,a0@
 _sbc_pdma_in+0x11e:     addql   #0x4,a6@(0x14)
 _sbc_pdma_in+0x122:     moval   a6@(0x14),a0
 _sbc_pdma_in+0x126:     moval   a6@(-0x8),a1
 _sbc_pdma_in+0x12a:     movl    a1@,a0@
 _sbc_pdma_in+0x12c:     addql   #0x4,a6@(0x14)
 _sbc_pdma_in+0x130:     moval   a6@(0x14),a0
 db> c
 syncing disks... done
 NetBSD/mac68k does not trust itself to update the RTC on shutdown.

 dumping to dev 4,1 offset 142120
 dump sbc0: polled request aborting 2/0
 sbc0: no REQ while aborting, reset
 sbc0: reset SCSI bus for TID=2 LUN=0
 sd1(sbc0:2:0): scsipi_done
 sd1(sbc0:2:0): command: 0x1a,0x0,0xc8,0x0,0xff,0x0-[255 bytes]
 ------------------------------
 000: 17 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00
 016: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 032: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 048: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ------------------------------
 sd1(sbc0:2:0): calling user done()
 sd1(sbc0:2:0): user-done
 sd1(sbc0:2:0): timeout
 sd1(sbc0:2:0): returned from user done()
  sd1(sbc0:2:0): scsipi_free_xs
 sd1(sbc0:2:0): calling private start()
 sd1(sbc0:2:0): sdstart sd1(sbc0:2:0): returning to adapter
 1 2 3 4 5 6 7 succeeded
 rebooting...

 -- I can provide the coredump as well as the kernel image, but -current 
 mac68k gdb fails miserably on kcore.

 (available  in <http://www.tangro.de/~hf/macbsd/> )

 Note the kernel was built without optimization.

>Fix:
None.

>Release-Note:

>Audit-Trail:
From: Hauke Fath <hauke@Espresso.Rhein-Neckar.DE>
To: Chuck Silvers <chuq@chuq.com>
Cc: Hauke Fath <hauke@Espresso.Rhein-Neckar.DE>,
	gnats-bugs@netbsd.org
Subject: Re: port-mac68k/9679 -- Using scsi/libscsi lets mac68k sbc driver
 dump core
Date: Wed, 11 Jan 2006 22:07:55 +0100

 [cc'ed to gnats-bugs and subject adapted for inclusion into the PR]

 At 15:08 Uhr -0800 27.12.2005, Chuck Silvers wrote:
 >one more... do you still see this one?

 Still going strong. Mac IIsi, recent netbsd-2 snapshot:

 # ./scsi -f /dev/rsd0c -m8 -P3 -v
 No mode data bastrap type 0, code = 0x74d, v = 0x8fc000
 kernel program counter = 0x1c9274
 kernel: Bus error trap
 pid = 15, lid = 1, pc = 001C9274, ps = 2210, sfc = 1, dfc = 1
 Registers:
              0        1        2        3        4        5        6        7
 dreg: 00000048 00000048 00000000 00000049 00000000 01012210 000000FF 00908000
 areg: 00906070 00906050 02800AA0 008FC000 01018000 000000FF 00688AEC FFFFCA08

 Kernel stack (006889A4):
 6889A4: 001DD5D0 00688A24 00000080 00000000 00000049 00000000 01012210 000000FF
 6889C4: 00908000 02800AA0 008FC000 01018000 000000FF 01028000 006889FC 00000001
 6889E4: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 688A04: 00000000 00000000 00002200 00688AEC 00003090 00000000 0000074D 008FC000
 688A24: 00000048 00000048 00000000 00000049 00000000 01012210 000000FF 00908000
 688A44: 00906070 00906050 02800AA0 008FC000 01018000 000000FF 00688AEC FFFFCA08
 688A64: 00000000 2210001C 9274B008 1EEE074D 24D324D3 008FC000 02800A9C 0020003F
 688A84: 24D324D3 001C927A 001C9278 001C9276 FFFFFFFF 24D30070 000FF481 0020003F
 688AA4: 001D13AC 00000002 00000002 80120018 001C9268 00000000 00000065 0007E2FA
 688AC4: 00000001 00000000 00000000 01018064 00000008 00000008 01018000 0101816C
 688AE4: 01028000 01028000 00688B0C 0007DED8 01018000 00000001 000000FF 02800A84
 688B04: 00000001 01018000 00688B30 0007E304 01018000 00000001 00000000 00000000
 688B24: 01018000 0101816C 00000000 00688B54 0007D1F4 01018000 00000000 00002000
 688B44: 01018000 01028000 01048B00 001B9C82 00688B74 0007CF9C 01018000 00002000
 688B64: 00002200 01028000 01048B00 01018064 00688BA0 001BB17C 01018064 00000000
 688B84: 01028000 00000000 00000000 001BB06C 01028000 01048B00 001BAF56 00688BD4
 panic: Bus error
 Stopped in pid 15.1 (scsi) at   netbsd:cpu_Debugger+0x6:        unlk    a6
 db> t
 cpu_Debugger(2200,0,688a24,688a10,1dd5f0) + 6
 panic(21cc0b,0,49,0,1012210) + f8
 trap(0,74d,8fc000) + 24e
 sbc_pdma_in(1018000,1,ff,2800a84) + 12a
 ncr5380_data_xfer(1018000,1) + 5e
 ncr5380_machine(1018000) + 2dc
 ncr5380_sched(1018000) + 166
 ncr5380_scsipi_request(1018064,0,1028000) + 174
 scsipi_run_queue(1018064) + 10e
 scsipi_execute_xs(1028000) + 17a
 scsi_scsipi_cmd(1048b00,0,10498b8,6,2800a84) + 30
 scsipi_command(1048b00,0,10498b8,6,2800a84,ff,0,7d0,1049808,1018) + 60
 scsistrategy(1049808,1049808,ff) + 96
 physio(1bc1d4,1049808,d02,100000,11d396,1049888) + 27c
 scsipi_do_ioctl(1048b00,d02,c0605101,688e8c,3) + 168
 sdioctl(d02,c0605101,688e8c,3,58f990) + e6
 spec_ioctl(688d7c,208d5c,5e07ec,c0605101,688e8c) + 4e
 VOP_IOCTL(5e07ec,c0605101,688e8c,3,1006e00,58f990) + 44
 vn_ioctl(6a60e0,c0605101,688e8c,58f990) + 80
 sys_ioctl(660300,688f44,688f3c) + b4
 syscall_plain(36,660300,688fb4,b000,ffffca84) + 82
 syscall(36) + 4e
 trap0() + e
 db>

 I'll upgrade the Mac to netbsd-3 next and report how the bug is doing there.

 	hauke


 --
 "It's never straight up and down"     (DEVO)


From: Hauke Fath <hauke@Espresso.Rhein-Neckar.DE>
To: gnats-bugs@netbsd.org
Cc: hauke@Espresso.Rhein-Neckar.DE
Subject: Re: port-mac68k/9679 -- Using scsi/libscsi lets mac68k sbc driver
  dump core
Date: Wed, 11 Jan 2006 23:39:48 +0100

 At 21:35 Uhr +0000 11.1.2006, Hauke Fath wrote:
 > At 15:08 Uhr -0800 27.12.2005, Chuck Silvers wrote:
 > >one more... do you still see this one?
 >
 > Still going strong. Mac IIsi, recent netbsd-2 snapshot:
 >
 > # ./scsi -f /dev/rsd0c -m8 -P3 -v

 FTR: The FreeBSD 'scsi' tool sources used can be found under
 http://la.causeuse.org/hauke/macbsd/scsi.tar.gz

 	hauke

 --
 "It's never straight up and down"     (DEVO)


From: Dave Huang <khym@azeotrope.org>
To: gnats-bugs@netbsd.org
Cc: netbsd-bugs@netbsd.org, hauke@Espresso.Rhein-Neckar.DE
Subject: Re: port-mac68k/9679 -- Using scsi/libscsi lets mac68k sbc driver dump core
Date: Wed, 11 Jan 2006 18:24:43 -0600

 I wonder if the sbc driver has problems if it's asked to read more
 data than is actually available. The scsi utility is attempting to
 read 255 bytes, even though chances are that the mode page isn't that
 long.

From: Chuck Silvers <chuq@chuq.com>
To: Dave Huang <khym@azeotrope.org>
Cc: gnats-bugs@netbsd.org, netbsd-bugs@netbsd.org,
	hauke@Espresso.Rhein-Neckar.DE
Subject: Re: port-mac68k/9679 -- Using scsi/libscsi lets mac68k sbc driver dump core
Date: Sat, 14 Jan 2006 12:02:51 -0800

 --sdtB3X0nJg68CQEu
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline

 On Wed, Jan 11, 2006 at 06:24:43PM -0600, Dave Huang wrote:
 > I wonder if the sbc driver has problems if it's asked to read more
 > data than is actually available. The scsi utility is attempting to
 > read 255 bytes, even though chances are that the mode page isn't that
 > long.

 well, it's part of the problem.  the sbc_pdma_in() is expecting to read
 255 bytes, so is does the PDMA thing instead of PIO.  since datalen is
 more than 128, it tries to do the first 128 bytes using 4-byte reads.
 however, there are only 35 bytes of data, so when it tries to read the
 ninth 4-byte value it gets a bus error since there are only 3 bytes left.

 so unless there's some way to know ahead of time how many bytes will
 actually be read, it's not safe to use the 4-byte reads.  all of the
 other sbc PDMA data movers use the "nofault" hook to catch bus errors,
 and sbc_pdma_in() should too.  the attached patch will at least prevent
 the panic, though it will miss transferring the last bytes if the number
 of bytes transferred is not a multiple of 4.

 we could try falling back to the byte-by-byte loop after a bus error on
 the unrolled loop, does that seem likely to work?

 -Chuck

 --sdtB3X0nJg68CQEu
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: attachment; filename="diff.sbc"

 Index: arch/mac68k/dev/sbc.c
 ===================================================================
 RCS file: /cvsroot/src/sys/arch/mac68k/dev/sbc.c,v
 retrieving revision 1.48
 diff -u -p -r1.48 sbc.c
 --- arch/mac68k/dev/sbc.c	24 Dec 2005 23:24:00 -0000	1.48
 +++ arch/mac68k/dev/sbc.c	14 Jan 2006 19:42:40 -0000
 @@ -246,6 +246,7 @@ sbc_pdma_in(struct ncr5380_softc *ncr_sc
  	struct sbc_softc *sc = (struct sbc_softc *)ncr_sc;
  	volatile u_int32_t *long_data = (u_int32_t *)sc->sc_drq_addr;
  	volatile u_int8_t *byte_data = (u_int8_t *)sc->sc_nodrq_addr;
 +	label_t faultbuf;
  	int resid, s;

  	if (datalen < ncr_sc->sc_min_dma_len ||
 @@ -261,9 +262,22 @@ sbc_pdma_in(struct ncr5380_softc *ncr_sc
  	*ncr_sc->sci_mode |= SCI_MODE_DMA;
  	*ncr_sc->sci_irecv = 0;

 +	resid = datalen;
 +
 +	/*
 +	 * Setup for a possible bus error caused by SCSI controller
 +	 * switching out of DATA OUT before we're done with the
 +	 * current transfer.  (See comment before sbc_drq_intr().)
 +	 */
 +	nofault = &faultbuf;
 +	if (setjmp(nofault)) {
 +		printf("sbc_pdma_in: caught bus error\n");
 +		goto interrupt;
 +	}
 +
  #define R4	*((u_int32_t *)data)++ = *long_data
  #define R1	*((u_int8_t *)data)++ = *byte_data
 -	for (resid = datalen; resid >= 128; resid -= 128) {
 +	for (; resid >= 128; resid -= 128) {
  		if (sbc_ready(ncr_sc))
  			goto interrupt;
  		R4; R4; R4; R4; R4; R4; R4; R4;
 @@ -281,6 +295,7 @@ sbc_pdma_in(struct ncr5380_softc *ncr_sc
  #undef R1

  interrupt:
 +	nofault = NULL;
  	SCI_CLR_INTR(ncr_sc);
  	*ncr_sc->sci_mode &= ~SCI_MODE_DMA;
  	*ncr_sc->sci_icmd = 0;

 --sdtB3X0nJg68CQEu--

From: Hauke Fath <hauke@Espresso.Rhein-Neckar.DE>
To: Chuck Silvers <chuq@chuq.com>
Cc: Dave Huang <khym@azeotrope.org>, gnats-bugs@netbsd.org,
	hauke@Espresso.Rhein-Neckar.DE
Subject: Re: port-mac68k/9679 -- Using scsi/libscsi lets mac68k sbc driver
 dump core
Date: Sun, 15 Jan 2006 17:39:09 +0100

 At 12:02 Uhr -0800 14.1.2006, Chuck Silvers wrote:
 >On Wed, Jan 11, 2006 at 06:24:43PM -0600, Dave Huang wrote:
 >> I wonder if the sbc driver has problems if it's asked to read more
 >> data than is actually available. The scsi utility is attempting to
 >> read 255 bytes, even though chances are that the mode page isn't that
 >> long.
 >
 >well, it's part of the problem.  the sbc_pdma_in() is expecting to read
 >255 bytes, so is does the PDMA thing instead of PIO.  since datalen is
 >more than 128, it tries to do the first 128 bytes using 4-byte reads.
 >however, there are only 35 bytes of data, so when it tries to read the
 >ninth 4-byte value it gets a bus error since there are only 3 bytes left.
 >
 >so unless there's some way to know ahead of time how many bytes will
 >actually be read, it's not safe to use the 4-byte reads.  all of the
 >other sbc PDMA data movers use the "nofault" hook to catch bus errors,
 >and sbc_pdma_in() should too.  the attached patch will at least prevent
 >the panic, though it will miss transferring the last bytes if the number
 >of bytes transferred is not a multiple of 4.

 mirth# ./scsi -f /dev/rsd0c -m8 -P3 -v
 sbc_pdma_in: caught bus error
 IC:  0
 ABPF:  0
 CAP:  0
 DISC:  0
 SIZE:  0
 WCE:  0
 MF:  0
 RCD:  1
 Demand Retention Priority:  0
 Write Retention Priority:  0
 Disable Pre-fetch Transfer Length:  0
 Minimum Pre-fetch:  0
 Maximum Pre-fetch:  32
 Maximum Pre-fetch Ceiling:  63
 mirth#

 -- nice.  :)

 >we could try falling back to the byte-by-byte loop after a bus error on
 >the unrolled loop, does that seem likely to work?

 Meaning that after a bus error from the longword accesses, we pick one byte
 at a time until the next bus error tells us there is nothing more? Sounds
 good, although I wouldn't know how to write the code.

 From looking at mac68k/dev/mac68k5380.c, am I wrong in assuming that the
 ncrscsi driver would suffer from the same problem? (Test kernel is still a
 few hours from completion.)

 	hauke


 --
 "It's never straight up and down"     (DEVO)


From: Hauke Fath <hauke@Espresso.Rhein-Neckar.DE>
To: gnats-bugs@netbsd.org
Cc: port-mac68k-maintainer@netbsd.org, gnats-admin@netbsd.org,
	hauke@Espresso.Rhein-Neckar.DE, Chuck Silvers <chuq@chuq.com>,
	Dave Huang <khym@azeotrope.org>
Subject: Re: port-mac68k/9679 -- Using scsi/libscsi lets mac68k sbc driver
  dump core
Date: Mon, 16 Jan 2006 00:16:57 +0100

 At 17:05 Uhr +0000 15.1.2006, Hauke Fath wrote:
 > From looking at mac68k/dev/mac68k5380.c, am I wrong in assuming that the
 > ncrscsi driver would suffer from the same problem? (Test kernel is still a
 > few hours from completion.)

 Surprise -- the ncrscsi driver seems to handle this properly:

 mirth# ./scsi -f /dev/rsd0c -m8 -P3 -v
 IC:  0
 ABPF:  0
 CAP:  0
 DISC:  0
 SIZE:  0
 WCE:  0
 MF:  0
 RCD:  1
 Demand Retention Priority:  0
 Write Retention Priority:  0
 Disable Pre-fetch Transfer Length:  0
 Minimum Pre-fetch:  0
 Maximum Pre-fetch:  32
 Maximum Pre-fetch Ceiling:  63
 mirth# dmesg | grep scsi
 ncrscsi0 at obio0
 scsibus0 at ncrscsi0 channel 0: 8 targets, 8 luns per target
 scsibus0: waiting 2 seconds for devices to settle...
 sd0 at scsibus0 target 0 lun 0: <CONNER, CP30540 545MB3.5, B0BC> disk fixed
 sd1 at scsibus0 target 2 lun 0: <QUANTUM, FIREBALL_TM1280S, 300X> disk fixed
 mirth#

 	hauke

 --
 "It's never straight up and down"     (DEVO)


From: Chuck Silvers <chs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: PR/9679 CVS commit: src/sys/arch/mac68k/dev
Date: Tue, 17 Jan 2006 16:41:29 +0000 (UTC)

 Module Name:	src
 Committed By:	chs
 Date:		Tue Jan 17 16:41:29 UTC 2006

 Modified Files:
 	src/sys/arch/mac68k/dev: sbc.c

 Log Message:
 add fault-protection in sbc_pdma_in() like in all the other PDMA functions.
 fixes PR 9679.


 To generate a diff of this commit:
 cvs rdiff -r1.48 -r1.49 src/sys/arch/mac68k/dev/sbc.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: Chuck Silvers <chuq@chuq.com>
To: Hauke Fath <hauke@Espresso.Rhein-Neckar.DE>
Cc: Dave Huang <khym@azeotrope.org>, gnats-bugs@netbsd.org
Subject: Re: port-mac68k/9679 -- Using scsi/libscsi lets mac68k sbc driver dump core
Date: Tue, 17 Jan 2006 08:54:58 -0800

 I did more experiments and eventually realized that the mode-page data is
 actually a multiple of 4 bytes for all the pages that worked on my disk.
 there was a bug in your scsi.c program that confused me.  so what I checked
 in just applies the same fault-handling logic to sbc_pdma_in() that's in
 all the other places where we do PDMA in both drivers.

 -Chuck

From: Hauke Fath <hauke@Espresso.Rhein-Neckar.DE>
To: Chuck Silvers <chuq@chuq.com>
Cc: gnats-bugs@netbsd.org
Subject: Re: port-mac68k/9679 -- Using scsi/libscsi lets mac68k sbc driver
 dump core
Date: Tue, 17 Jan 2006 20:34:01 +0100

 At 8:54 Uhr -0800 17.1.2006, Chuck Silvers wrote:
 >I did more experiments and eventually realized that the mode-page data is
 >actually a multiple of 4 bytes for all the pages that worked on my disk.

 Ah, good.

 >there was a bug in your scsi.c program

 Not mine. It was a snapshot of the FreeBSD scsi(8) before they cvs rm'ed it
 and changed to CAM. Care to give me a hint?

 >that confused me.  so what I checked
 >in just applies the same fault-handling logic to sbc_pdma_in() that's in
 >all the other places where we do PDMA in both drivers.

 Cool. That was one of my older PRs... thanks for looking at it.  :)

 	hauke


 --
 "It's never straight up and down"     (DEVO)


From: Matthias Scheler <tron@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: PR/9679 CVS commit: [netbsd-3] src/sys/arch/mac68k/dev
Date: Mon, 30 Jan 2006 22:33:40 +0000 (UTC)

 Module Name:	src
 Committed By:	tron
 Date:		Mon Jan 30 22:33:40 UTC 2006

 Modified Files:
 	src/sys/arch/mac68k/dev [netbsd-3]: sbc.c

 Log Message:
 Pull up following revision(s) (requested by chs in ticket #1146):
 	sys/arch/mac68k/dev/sbc.c: revision 1.49
 add fault-protection in sbc_pdma_in() like in all the other PDMA functions.
 fixes PR 9679.


 To generate a diff of this commit:
 cvs rdiff -r1.45 -r1.45.8.1 src/sys/arch/mac68k/dev/sbc.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: open->feedback
State-Changed-By: wiz@NetBSD.org
State-Changed-When: Wed, 23 Nov 2011 19:03:04 +0000
State-Changed-Why:
I think this one is fixed, do you agree?


From: Hauke Fath <hauke@Espresso.Rhein-Neckar.DE>
To: gnats-bugs@NetBSD.org
Cc: port-mac68k-maintainer@NetBSD.org, gnats-admin@NetBSD.org, wiz@NetBSD.org
Subject: Re: port-mac68k/9679 (Using scsi/libscsi lets mac68k sbc driver
 dump core)
Date: Fri, 25 Nov 2011 09:17:37 +0100

 At 19:03 Uhr +0000 23.11.2011, wiz@NetBSD.org wrote:
 >Synopsis: Using scsi/libscsi lets mac68k sbc driver dump core
 >
 >State-Changed-From-To: open->feedback
 >State-Changed-By: wiz@NetBSD.org
 >State-Changed-When: Wed, 23 Nov 2011 19:03:04 +0000
 >State-Changed-Why:
 >I think this one is fixed, do you agree?

 Give me a few days to look at it. There's no hurry.  ;)

 	hauke

 --
 "It's never straight up and down"     (DEVO)


From: Hauke Fath <hauke@Espresso.Rhein-Neckar.DE>
To: gnats-bugs@NetBSD.org
Cc: port-mac68k-maintainer@NetBSD.org, netbsd-bugs@NetBSD.org,
        gnats-admin@NetBSD.org
Subject: Re: port-mac68k/9679 (Using scsi/libscsi lets mac68k sbc driver
 dump core)
Date: Mon, 28 Nov 2011 21:26:54 +0100

 At 19:03 Uhr +0000 23.11.2011, wiz@NetBSD.org wrote:
 >State-Changed-Why:
 >I think this one is fixed, do you agree?

 [root@mirth] /<3>sys/sbin.scsi # uname -a
 NetBSD mirth 5.99.57 NetBSD 5.99.57 (GENERICSBC) #0: Fri Nov 25 17:21:10
 CET 2011
 hf@Hochstuhl:/var/obj/netbsd-builds/developer/mac68k/sys/arch/mac68k/compile/GEN
 ERICSBC mac68k
 [root@mirth] ~ # scsi -f /dev/rsd1c -m8 -P3 -v
 IC:  0
 ABPF:  0
 CAP:  0
 DISC:  0
 SIZE:  0
 WCE:  0
 MF:  0
 RCD:  1
 Demand Retention Priority:  0
 Write Retention Priority:  0
 Disable Pre-fetch Transfer Length:  0
 Minimum Pre-fetch:  0
 Maximum Pre-fetch:  32
 Maximum Pre-fetch Ceiling:  63
 [root@mirth] ~ #

 -- yes, fixed - please close.

 Thanks,
 	hauke

 --
 "It's never straight up and down"     (DEVO)


State-Changed-From-To: feedback->closed
State-Changed-By: wiz@NetBSD.org
State-Changed-When: Mon, 28 Nov 2011 23:38:59 +0000
State-Changed-Why:
Confirmed fixed, thanks!


>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.