[Format recovered--see http://www.lemis.com/email/email-format.html]
On Monday, 28 June 1999 at 23:26:24 +0200, Niels Chr. Bank-Pedersen wrote:
> Since the latest patches for vinum were commited I am getting a panic
> immediately after vinum has started. This is on a UP -current (as of
> today).
>
> ---
> changing root device to da0s1a
> da0 at ahc0 bus 0 target 0 lun 0
> da0: <IBM DCAS-34330 S65A> Fixed Direct Access SCSI-2 device
> da0: 10.000MB/s transfers (10.000MHz, offset 15)
> da0: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C)
> da2 at ahc0 bus 0 target 8 lun 0
> da2: <IBM DCAS-32160W !# S69D> Fixed Direct Access SCSI-2 device
> da2: 20.000MB/s transfers (10.000MHz, offset 8, 16bit)
> da2: 2063MB (4226725 512 byte sectors: 255H 63S/T 263C)
> da1 at ahc0 bus 0 target 1 lun 0
> da1: <IBM DORS-32160W WA6A> Fixed Direct Access SCSI-2 device
> da1: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing
> Enabled
> da1: 2063MB (4226725 512 byte sectors: 255H 63S/T 263C)
> cd0 at ahc0 bus 0 target 4 lun 0
> cd0: <TOSHIBA CD-ROM XM-3601TA 0265> Removable CD-ROM SCSI-2 device
> cd0: 4.237MB/s transfers (4.237MHz, offset 15)
> cd0: Attempt to query device size failed: NOT READY, Medium not present
> vinum: loaded
> Can't open history file /var/tmp/vinum_history: Read-only file system
> (30)
>
>
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0x1
> fault code = supervisor read, page not present
> instruction pointer = 0x8:0xc017b954
> stack pointer = 0x10:0xc64c7d18
> frame pointer = 0x10:0xc64c7d34
> code segment = base 0x0, limit 0xfffff, type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags = interrupt enabled, resume, IOPL = 0
> current process = 17 (vinum)
> interrupt mask =
> kernel: type 12 trap, code=0
> Stopped at vn_lock+0x10: testb $0x1,0x1(%esi)
> db> trace
> vn_lock(0,20002,0,c09acc00,c09acce4) at vn_lock+0x10
> _end(c09acc00,c09acc00,c09d56e0,c5,0) at 0xc09ce85b
> _end(c09acc00,0,4000e600,c64c7d94,c09d4980) at 0xc09ce82f
> _end(c64c7dac,c09d3461,c64c7e08,4000e600,c5afa4c0) at 0xc09d4890
> _end(c64c7e08,4000e600,c5afa4c0,c64c7ecc,c64c7dd4) at 0xc09d4980
> _end(4000e600,465d,c64c7ecc,3,c5afa4c0) at 0xc09d3461
> spec_ioctl(c64c7e08,c64c7dec,c01e5d65,c64c7e08,c64c7e98) at spec_ioctl+0x40
> spec_vnoperate(c64c7e08,c64c7e98,c017b89d,c64c7e08,c09c2800) at spec_vnoperate+0x15
> ufs_vnoperatespec(c64c7e08,c09c2800,c09ad440,0,0) at ufs_vnoperatespec+0x15
> vn_ioctl(c09ad440,465d,c64c7ecc,c5afa4c0,c5afa4c0) at vn_ioctl+0xdd
> ioctl(c5afa4c0,c64c7f80,2,bfbfde00,bfbfde0c) at ioctl+0x1ef
> syscall(2f,2f,2f,bfbfde0c,bfbfde00) at syscall+0x182
> Xint0x80_syscall() at Xint0x80_syscall+0x30
> db> ps
> [omitted]
> db>
>
> Kernel configuration:
>
> [omitted]
>
> Any clues?
Yes, they're in vinum(4). They explain what information you should
supply if things go wrong. Basically, the information above wouldn't
normally be of much use.
Having said that, however, in this particular case I *do* recognize
the problem. As soon as we get over the lockmgr panics, I should be
able to commit a fix for it--hopefully later today.
Greg
--
See complete headers for address, home page and phone numbers
finger [EMAIL PROTECTED] for PGP public key
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
