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>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199811131730.JAA00980>