From nobody  Thu Nov 12 14:11:33 1998
Received: (from nobody@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id OAA29476;
          Thu, 12 Nov 1998 14:11:33 -0800 (PST)
          (envelope-from nobody)
Message-Id: <199811122211.OAA29476@hub.freebsd.org>
Date: Thu, 12 Nov 1998 14:11:33 -0800 (PST)
From: bad@wireless.net
To: freebsd-gnats-submit@freebsd.org
Subject: sd0->da0 change breaks change of media and MSDOS removeable disks (Zip)
X-Send-Pr-Version: www-1.0

>Number:         8671
>Category:       kern
>Synopsis:       sd0->da0 change breaks change of media and MSDOS removeable disks (Zip)
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    gibbs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Nov 12 14:20:00 PST 1998
>Closed-Date:    Sun Dec 6 12:04:49 PST 1998
>Last-Modified:  Sun Dec  6 12:05:37 PST 1998
>Originator:     Bernie Doehner
>Release:        3.0-RELEASE
>Organization:
>Environment:
Not available - non networked machine, can supply if needed.. 

>Description:
Under 3.0-SNAP-19980821 Zip disks (Parallel port, but using SCSI protocol)
worked perfectly with the sd0 device driver.

However, in 3.0-RELEASE the major move from sd0 to {cam}/da0 was made, 
and now MSDOS Zip disks cannot be mounted/format, etc. 

The only access that works is with FFS Zip's, and ONLY if you boot up with
the disk inserted. If one mounts and then unmounts the Zip, removes it from
drive, and plugs in a new zip, the system is incapable of reading the
new disklabel, and subsequently crashes, with the dump stating it was
in {cam} at the time of crash.
>How-To-Repeat:
Compile custom kernel with ppbus, vpo0, scsi controller, and device da0.
Boot up with Zip disk in parallel port zip drive, mount, unmount, 
remove Zip, reinsert.. Subsequently watch system panic.
>Fix:
Temporary fix: Make a config option so that one can use the old sd0 
driver with Parallel port Zip disk, until {cam/da0} properly works
with removeable media.
>Release-Note:
>Audit-Trail:

From: "Kenneth D. Merry" <ken@plutotech.com>
To: bad@wireless.net
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: kern/8671: sd0->da0 change breaks change of media and MSDOS removeable disks (Zip)
Date: Thu, 12 Nov 1998 16:58:42 -0700 (MST)

 bad@wireless.net wrote...
 > >Description:
 > Under 3.0-SNAP-19980821 Zip disks (Parallel port, but using SCSI protocol)
 > worked perfectly with the sd0 device driver.
 > 
 > However, in 3.0-RELEASE the major move from sd0 to {cam}/da0 was made, 
 > and now MSDOS Zip disks cannot be mounted/format, etc. 
 > 
 > The only access that works is with FFS Zip's, and ONLY if you boot up with
 > the disk inserted. If one mounts and then unmounts the Zip, removes it from
 > drive, and plugs in a new zip, the system is incapable of reading the
 > new disklabel, and subsequently crashes, with the dump stating it was
 > in {cam} at the time of crash.
 > >How-To-Repeat:
 > Compile custom kernel with ppbus, vpo0, scsi controller, and device da0.
 > Boot up with Zip disk in parallel port zip drive, mount, unmount, 
 > remove Zip, reinsert.. Subsequently watch system panic.
 
 Please send a stack trace from the panic.  Without more information, it's
 going to be difficult to diagnose your problem.
 
 > >Fix:
 > Temporary fix: Make a config option so that one can use the old sd0 
 > driver with Parallel port Zip disk, until {cam/da0} properly works
 > with removeable media.
 
 The da driver does work with removable media.  Using the old sd driver with
 CAM would be extremely difficult to implement, and would probably not 
 be a very fruitful endeavor.
 
 Ken
 -- 
 Kenneth Merry
 ken@plutotech.com

From: "Justin T. Gibbs" <gibbs@plutotech.com>
To: bad@wireless.net
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: kern/8671: sd0->da0 change breaks change of media and MSDOS removeable disks (Zip) 
Date: Thu, 12 Nov 1998 16:55:33 -0700

 >Compile custom kernel with ppbus, vpo0, scsi controller, and device da0.
 >Boot up with Zip disk in parallel port zip drive, mount, unmount, 
 >remove Zip, reinsert.. Subsequently watch system panic.
 
 Stack trace?  None of the developers have a Zip disk here to test with,
 so you'll have to provide this kind of information.
 
 --
 Justin
 
 

From: Bernie Doehner <bad@wireless.net>
To: "Kenneth D. Merry" <ken@plutotech.com>
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: kern/8671: sd0->da0 change breaks change of media and MSDOS removeable disks (Zip)
Date: Fri, 13 Nov 1998 05:45:07 -0800 (PST)

 > Please send a stack trace from the panic.  Without more information, it's
 > going to be difficult to diagnose your problem.
 
 Is there an efficient way to save the stack trace on the filesystem, or do
 I have to write it down? Expect the stack trace on monday.
  
 > > >Fix:
 > > Temporary fix: Make a config option so that one can use the old sd0 
 > > driver with Parallel port Zip disk, until {cam/da0} properly works
 > > with removeable media.
 > 
 > The da driver does work with removable media.  Using the old sd driver with
 > CAM would be extremely difficult to implement, and would probably not 
 > be a very fruitful endeavor.
 
 Let me rephrase, temporary fix is to go back to sd0 WITHOUT Cam. I don't
 need CAM at all. 
 
 Btw, is your DTV video server in production yet?  I mentioned your product
 to the lead WXXI maintainance engineer and he's definitely interested.
 
 Best Regards,
 
 Bernie
 

From: "Kenneth D. Merry" <ken@plutotech.com>
To: bad@wireless.net (Bernie Doehner)
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: kern/8671: sd0->da0 change breaks change of media and MSDOS removeable disks (Zip)
Date: Fri, 13 Nov 1998 10:25:13 -0700 (MST)

 Bernie Doehner wrote...
 > > Please send a stack trace from the panic.  Without more information, it's
 > > going to be difficult to diagnose your problem.
 > 
 > Is there an efficient way to save the stack trace on the filesystem, or do
 > I have to write it down? Expect the stack trace on monday.
 
 There are two things you can do:
 
  - enable crashdumps (see section 22 of the handbook)
 	- you'll need to adjust the dumpon and savecore items in
 	  /etc/rc.conf.
 	- make sure you've got more space in /var/crash than you have RAM.
 	  (i.e. if you've got 128MB of RAM, you should have more space than
 	  that in /var/crash)
 
  - enable DDB in your kernel, and use a serial console to get the stack
    trace from DDB.
 
 The former would probably be the easiest.  Once your system crashes, and
 dumps everything to /var/crash, you should be able to get a stack trace
 from the kernel/core dump in /var/crash.
 
 I'm not sure if the gdb shipped in 3.0 understands both ELF and a.out.  If
 it does, you'd do something like:
 
 cd /var/crash
 gdb -k kernel.0 vmcore.0
 (kgdb) where
 [ ... ]
 
 If not, there's an a.out version of gdb here:
 
 ftp://ftp.lemis.com/pub/vinum/gdb-aout
 
 > > > >Fix:
 > > > Temporary fix: Make a config option so that one can use the old sd0 
 > > > driver with Parallel port Zip disk, until {cam/da0} properly works
 > > > with removeable media.
 > > 
 > > The da driver does work with removable media.  Using the old sd driver with
 > > CAM would be extremely difficult to implement, and would probably not 
 > > be a very fruitful endeavor.
 > 
 > Let me rephrase, temporary fix is to go back to sd0 WITHOUT Cam. I don't
 > need CAM at all. 
 
 Ahh.  Well, we'd like to find this problem so you can use CAM.
 
 > Btw, is your DTV video server in production yet?  I mentioned your product
 > to the lead WXXI maintainance engineer and he's definitely interested.
 
 Which one?  All of Pluto's machines do digital video.  Two are in
 production, a third is very close.  They are:
 
 VideoSpace -- uncompressed standard def video (525 or 625)
 HyperSpace -- compressed high def video (up to 1080i), or standard def
 AirSpace   -- multichannel server (up to 10) that does DV-25 or DV-50 video
                - this isn't shipping yet, but is very close
 
 See:
 
 http://www.plutotech.com
 
 or send me private mail if you want more info.
 
 Ken
 -- 
 Kenneth Merry
 ken@plutotech.com

From: Bernie Doehner <bad@wireless.net>
To: "Kenneth D. Merry" <ken@plutotech.com>
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: kern/8671: sd0->da0 change breaks change of media and MSDOS removeable disks (Zip)
Date: Fri, 13 Nov 1998 12:43:09 -0800 (PST)

 > I'm not sure if the gdb shipped in 3.0 understands both ELF and a.out.  If
 > it does, you'd do something like:
 > 
 > cd /var/crash
 > gdb -k kernel.0 vmcore.0
 > (kgdb) where
 > [ ... ]
 
 Can't I read the crash dump AFTER rebooting with the same machine using
 GDB instead of kgdb?  
 
 Thanks.
 
 Bernie
 
 P.S. Would yoou mind giving me a daytime/weekend phone number I could call
 you or someone else to get help with this over the weekend?
  
 > If not, there's an a.out version of gdb here:
 > 
 > ftp://ftp.lemis.com/pub/vinum/gdb-aout
 > 
 > > > > >Fix:
 > > > > Temporary fix: Make a config option so that one can use the old sd0 
 > > > > driver with Parallel port Zip disk, until {cam/da0} properly works
 > > > > with removeable media.
 > > > 
 > > > The da driver does work with removable media.  Using the old sd driver with
 > > > CAM would be extremely difficult to implement, and would probably not 
 > > > be a very fruitful endeavor.
 > > 
 > > Let me rephrase, temporary fix is to go back to sd0 WITHOUT Cam. I don't
 > > need CAM at all. 
 > 
 > Ahh.  Well, we'd like to find this problem so you can use CAM.
 > 
 > > Btw, is your DTV video server in production yet?  I mentioned your product
 > > to the lead WXXI maintainance engineer and he's definitely interested.
 > 
 > Which one?  All of Pluto's machines do digital video.  Two are in
 > production, a third is very close.  They are:
 > 
 > VideoSpace -- uncompressed standard def video (525 or 625)
 > HyperSpace -- compressed high def video (up to 1080i), or standard def
 > AirSpace   -- multichannel server (up to 10) that does DV-25 or DV-50 video
 >                - this isn't shipping yet, but is very close
 > 
 > See:
 > 
 > http://www.plutotech.com
 > 
 > or send me private mail if you want more info.
 > 
 > Ken
 > -- 
 > Kenneth Merry
 > ken@plutotech.com
 > 
 

From: "Kenneth D. Merry" <ken@plutotech.com>
To: bad@wireless.net (Bernie Doehner)
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: kern/8671: sd0->da0 change breaks change of media and MSDOS removeable disks (Zip)
Date: Fri, 13 Nov 1998 14:09:34 -0700 (MST)

 Bernie Doehner wrote...
 > > I'm not sure if the gdb shipped in 3.0 understands both ELF and a.out.  If
 > > it does, you'd do something like:
 > > 
 > > cd /var/crash
 > > gdb -k kernel.0 vmcore.0
 > > (kgdb) where
 > > [ ... ]
 > 
 > Can't I read the crash dump AFTER rebooting with the same machine using
 > GDB instead of kgdb?  
 
 Oops, I thought that was clear.  You do use 'gdb -k' (a.k.a. "kgdb") after
 the machine has dumped its ram and rebooted.
 
 Just make sure you have a dump device configured, and savecore enabled.
 (in your rc.conf file)
 
 > P.S. Would yoou mind giving me a daytime/weekend phone number I could call
 > you or someone else to get help with this over the weekend?
 
 I'd rather not.  I will answer email this weekend, though.
 
 Ken
 -- 
 Kenneth Merry
 ken@plutotech.com

From: Bernie Doehner <bad@wireless.net>
To: "Kenneth D. Merry" <ken@plutotech.com>
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: kern/8671: sd0->da0 change breaks change of media and MSDOS removeable disks (Zip)
Date: Fri, 13 Nov 1998 13:18:47 -0800 (PST)

 > 
 > Oops, I thought that was clear.  You do use 'gdb -k' (a.k.a. "kgdb") after
 > the machine has dumped its ram and rebooted.
 
 Understood!
  
 > Just make sure you have a dump device configured, and savecore enabled.
 > (in your rc.conf file)
 
 Understood!
 
 > > P.S. Would yoou mind giving me a daytime/weekend phone number I could call
 > > you or someone else to get help with this over the weekend?
 > 
 > I'd rather not.  I will answer email this weekend, though.
 
 No problem, but like I said, the machine with the Zip drive is not
 networked, and I am not really planning on going to work over the weekend-
 my only network connection (although this may change). 
 
 So it'll probably be monday before I can communicate with you again.
 
 Have a great weekend!
 
 Bernie
 
 
 

From: Bernie Doehner <bad@wireless.net>
To: "Kenneth D. Merry" <ken@plutotech.com>, gibbs@plutotech.com,
        buaas@wireless.net
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: kern/8671: sd0->da0 change breaks change of media and MSDOS removeable disks (Zip)
Date: Sun, 6 Dec 1998 11:51:19 -0800 (PST)

 Ken/Justin:
 
 Just got the replacement ZIP drive and it works flawlessly.. About 275 k/s
 on the parallel port with da0 driver. Even unmounting/mounting works, and
 this is with the 3.0-R stock driver. Not -current.
 
 Media change works flawlessly.
 
 It even locks the drive, so you can't eject a mounted zip disk without
 first unmounting it.. Ie, you press the eject button, it waits to eject
 the zip until you umount the zip.
 
 I like it muchly and it's much better than the old sd0 driver..
 
 Kudo's to the da0 coders..
 
 I appologize for having wasted your time with this wild goose chase.
 
 Best regards,
 
 Bernie
 
State-Changed-From-To: open->closed 
State-Changed-By: gibbs 
State-Changed-When: Sun Dec 6 12:04:49 PST 1998 
State-Changed-Why:  
Originator confirms that the cause of the problem was a defective device. 


Responsible-Changed-From-To: freebsd-bugs->gibbs 
Responsible-Changed-By: gibbs 
Responsible-Changed-When: Sun Dec 6 12:04:49 PST 1998 
Responsible-Changed-Why:  
CAM driver. 
>Unformatted:
