From owner-freebsd-bugs Thu Feb 4 07:30:08 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA01180 for freebsd-bugs-outgoing; Thu, 4 Feb 1999 07:30:08 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA01086 for ; Thu, 4 Feb 1999 07:30:01 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.2/8.9.2) id HAA79280; Thu, 4 Feb 1999 07:30:00 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from nobody@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA29908; Thu, 4 Feb 1999 07:25:28 -0800 (PST) (envelope-from nobody) Message-Id: <199902041525.HAA29908@hub.freebsd.org> Date: Thu, 4 Feb 1999 07:25:28 -0800 (PST) From: nb@geodesic.com To: freebsd-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: www-1.0 Subject: kern/9909: Writing incomplete blocks to /dev/nrst0 hangs the kernel Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 9909 >Category: kern >Synopsis: Writing incomplete blocks to /dev/nrst0 hangs the kernel >Confidential: no >Severity: critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Feb 4 07:30:00 PST 1999 >Closed-Date: >Last-Modified: >Originator: Nick Barnes >Release: 2.2.8 >Organization: Geodesic Systems >Environment: FreeBSD raven.ravenbrook.com 2.2.8-RELEASE FreeBSD 2.2.8-RELEASE #0: Fri Jan 15 15:02:41 GMT 1999 root@raven.ravenbrook.com:/usr/src/sys/compile/RAVEN-228 i386 >Description: If I write a file which is not a complete number of blocks to /dev/nrst0 (which in my case is an HP "C1554A DDS-3 SCSI DAT Drive", according to the printed documentation), the kernel seems to hang. No panic or other kernel messages. No response to console keyboard (including Alt-F), no response to ping. I have left it for around fifteen minutes in this state with no improvement It seems irrelevant what I use to do the writes (certainly both cat and dd break it). I can work around using "dd conv=osync". Here's my SCSI driver initializing (from dmesg): aic0 at 0x340-0x35f irq 11 on isa aic0 waiting for scsi devices to settle (aic0:1:0): "IBM DCAS-34330 S65A" type 0 fixed SCSI 2 sd0(aic0:1:0): Direct-Access 4134MB (8467200 512 byte sectors) (aic0:2:0): "HP C1537A L708" type 1 removable SCSI 2 st0(aic0:2:0): Sequential-Access density code 0x25, variable blocks, write-enabled My kernel is very nearly 2.2.8 GENERIC. Here are the config diffs: $ diff GENERIC RAVEN-228 2c2 < # GENERIC -- Generic machine with WD/AHx/NCR/BTx family disks --- > # RAVEN-228 -- Custom kernel for raven.ravenbrook.com, 4,14c4,5 < # For more information read the handbook part System Administration -> < # Configuring the FreeBSD Kernel -> The Configuration File. < # The handbook is available in /usr/share/doc/handbook or online as < # latest version from the FreeBSD World Wide Web server < # < # < # An exhaustive list of options and more detailed explanations of the < # device lines is present in the ./LINT configuration file. If you are < # in doubt as to the purpose or necessity of a line, check first in LINT. < # < # $Id: GENERIC,v 1.77.2.28 1998/09/26 17:36:14 wpaul Exp $ --- > # 1999-01-15 nb added ed1 and bpfilter > # 1999-01-15 nb copied from 2.2.8 GENERIC. 17d7 < cpu "I386_CPU" 19,21c9 < cpu "I586_CPU" < cpu "I686_CPU" < ident GENERIC --- > ident RAVEN 37a26 > options NETATALK #Appletalk communications protocols 150a140 > device ed1 at isa? port 0x300 net irq 5 iomem 0xd8000 vector edintr 165a156 > pseudo-device bpfilter 4 #Berkeley packet filter $ >How-To-Repeat: # cat > redfish one fish two fish red fish blue fish ^D # cat redfish > /dev/nrst0 Just the same if the last command is: # dd if=redfish of=/dev/nrst0 But if I do this instead, things work fine: # dd if=redfish of=/dev/nrst0 conv=osync >Fix: No idea. It seems reasonable that I might get an error message if the device driver requires whole blocks. But hanging the kernel is obviously unacceptable. >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message