Date: Fri, 13 Nov 1998 09:30:00 -0800 (PST) From: "Kenneth D. Merry" <ken@plutotech.com> To: freebsd-bugs@FreeBSD.ORG Subject: Re: kern/8671: sd0->da0 change breaks change of media and MSDOS removeable disks (Zip) Message-ID: <199811131730.JAA00980@freefall.freebsd.org>
index | next in thread | raw e-mail
The following reply was made to PR kern/8671; it has been noted by GNATS.
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
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199811131730.JAA00980>