NetBSD Problem Report #7938

Received: (qmail 2285 invoked from network); 7 Jul 1999 10:11:52 -0000
Message-Id: <199907071011.DAA00416@biffvm1.biff.net>
Date: Wed, 7 Jul 1999 03:11:04 -0700 (PDT)
From: dogcow@isi.net
Reply-To: dogcow@isi.net
To: gnats-bugs@gnats.netbsd.org
Subject: kernel panic when accessing iomega HFS zip disk
X-Send-Pr-Version: 3.95

>Number:         7938
>Category:       port-mac68k
>Synopsis:       kernel panic when accessing iomega HFS zip disk
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    port-mac68k-maintainer
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Jul 07 03:20:00 +0000 1999
>Closed-Date:    Sun Feb 10 23:15:04 +0000 2002
>Last-Modified:  Sun Feb 10 23:15:04 +0000 2002
>Originator:     Tom Spindler
>Release:        1.4
>Organization:
BIFFSTERS INTERNATIONAL

>Environment:

System: NetBSD biffvm1.biff.net 1.4 NetBSD 1.4 (GENERICSBC) #0: Sat May 8 20:55:03 PDT 1999 root2@c610:/usr/src/sys/arch/mac68k/compile/GENERICSBC mac68k


>Description:

I have two SCSI devices on my system: a quantum 500M drive (ID 0), and
a ZIP disk (ID 5). When I attempted to use hfsutils (a userland
program) to mount the hfs volume on the zip drive, I invoked it as
'hmount /dev/sd1d'.  This caused the machine to go boom with the
message 'panic: getblk: block size invariant failed'.
(unfortunately, the corefile wasn't saved, due to lack of space)

>How-To-Repeat:

I suspect that putting in any zip disk and attempting to access
/dev/sd1d will panic the machine. I've not tested this yet, though.
>Fix:

>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: fair 
State-Changed-When: Sun Jan 20 04:26:24 PST 2002 
State-Changed-Why:  
It has been two years since this PR was filed, and NetBSD has been through 
many changes (and a few releases!) since then. 

Does this problem still occurr? 

Can you be more specific about the kind of system (which Mac model), 
and which SCSI driver are involved? an output from "dmesg" just after 
system boot, or the contents of /var/run/dmesg.boot would help. 

State-Changed-From-To: feedback->closed 
State-Changed-By: chs 
State-Changed-When: Sun Feb 10 15:14:51 PST 2002 
State-Changed-Why:  
fixed by rev. 1.78 to vfs_bio.c. 
>Unformatted:

Home	PR Database Search