Re: panic in vinum

Tuesday, June 29, 2004, 1:10:20 AM, you wrote:

> On Monday, 28 June 2004 at 12:59:06 +0200, Divacky Roman wrote:
>> on a boot (todays current about hour old) it crashes - I am not able to
>> get crashdump but ddb trace shows this (hand written)

> ...

> Sorry, that's not enough.  If you're running -CURRENT, you should have
> at least remote gdb installed.  There's really not much anybody can do
> without a proper back trace (which, even for ddb, should include
> details of parameters and addresses, including resolution to line
> numbers in the code).

I sent a full backtrace a few days ago on list, and I still have the
crashdump somewhere on my test machine.  Didn't see an ack, though,
maybe it hasn't made it to the list ?

Here's the thing :

(kgdb) backtrace
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:236
#1  0xc04d9ff4 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:370
#2  0xc04da31f in panic () at /usr/src/sys/kern/kern_shutdown.c:548
#3  0xc0522235 in vfs_mount_destroy ()
#4  0xc0523b53 in getdiskbyname ()
#5  0xc480d962 in open_drive ()
   from /usr/obj/usr/src/sys/CRAGGANMORE/modules/usr/src/sys/modules/vinum/vinum.ko.debug
#6  0xc480dc98 in init_drive ()
   from /usr/obj/usr/src/sys/CRAGGANMORE/modules/usr/src/sys/modules/vinum/vinum.ko.debug
#7  0xc480e180 in read_drive_label ()
   from /usr/obj/usr/src/sys/CRAGGANMORE/modules/usr/src/sys/modules/vinum/vinum.ko.debug
#8  0xc480e2d0 in check_drive ()
   from /usr/obj/usr/src/sys/CRAGGANMORE/modules/usr/src/sys/modules/vinum/vinum.ko.debug
#9  0xc480ebec in vinum_scandisk ()
   from /usr/obj/usr/src/sys/CRAGGANMORE/modules/usr/src/sys/modules/vinum/vinum.ko.debug
#10 0xc480f750 in vinum_super_ioctl ()
   from /usr/obj/usr/src/sys/CRAGGANMORE/modules/usr/src/sys/modules/vinum/vinum.ko.debug
#11 0xc480f116 in vinumioctl ()
   from /usr/obj/usr/src/sys/CRAGGANMORE/modules/usr/src/sys/modules/vinum/vinum.ko.debug
#12 0xc04a61de in spec_ioctl ()
#13 0xc04a5963 in spec_vnoperate ()
#14 0xc0530a33 in vn_ioctl ()
#15 0xc04faa70 in ioctl ()
#16 0xc05faf3f in syscall ()
#17 0x4813a9bb in ?? ()
---Can't read userspace from dump, or kernel process---

If more info is needed, just ask, it's a test machine.

> Greg

Fred
-- 
Sysadmin (n): The untrained being underpaid for doing the impossible 
with the obsolete.
                                                       (Seen on the SDM)