Re: LOR panic on mount -uw

2017-10-13 Thread grarpamp
On Thu, Oct 12, 2017 at 11:15 AM, John Baldwin wrote: > In this case the panic is separate from the LOR, and > for a panic we really > need the panic message in addition to the stack trace. With release kernels stack trace appears with this message, then it sits in ddb, forget

Re: LOR panic on mount -uw

2017-10-13 Thread grarpamp
On Wed, Oct 11, 2017 at 5:18 PM, grarpamp wrote: > Let 12.0-current r324306 amd64 efi boot from usb to installer screen, Another way to trigger this one is boot snapshot install media single user verbose mdmfs -s 10m md /mnt umount -v /mnt [LOR stack backtrace, remains

Re: LOR panic on mount -uw

2017-10-12 Thread John Baldwin
On Wednesday, October 11, 2017 05:18:17 PM grarpamp wrote: > Let 12.0-current r324306 amd64 efi boot from usb to installer screen, > try to write zeroes to an unallocated part of ada0, mount -uw a > separate part of ada0 ... > > 1st 0xc5ce5f0 ufs kern/vfs_mount.c:1274 > 2nd 0xc565b78 devfs

LOR panic on mount -uw

2017-10-11 Thread grarpamp
Let 12.0-current r324306 amd64 efi boot from usb to installer screen, try to write zeroes to an unallocated part of ada0, mount -uw a separate part of ada0 ... 1st 0xc5ce5f0 ufs kern/vfs_mount.c:1274 2nd 0xc565b78 devfs ufs/ffs/ffs_vfsops.c:1414 db_trace_self_wrapper vpanic kassert_panic+0x126

Re: weird panic at mount

2017-02-20 Thread Chagin Dmitry
On Tue, Feb 21, 2017 at 07:58:23AM +0100, Mateusz Guzik wrote: > On Tue, Feb 21, 2017 at 09:51:25AM +0300, Chagin Dmitry wrote: > > 2527 * Remove a prison reference. If that was the last reference, > > remove the > > (kgdb) p *cred->cr_prison > > Cannot access memory at address

Re: weird panic at mount

2017-02-20 Thread Mateusz Guzik
On Tue, Feb 21, 2017 at 09:51:25AM +0300, Chagin Dmitry wrote: > 2527 * Remove a prison reference. If that was the last reference, remove > the > (kgdb) p *cred->cr_prison > Cannot access memory at address 0x100fe > (kgdb) p *cred > $1 = {cr_ref = 0x0, cr_uid = 0x0, cr_ruid =

weird panic at mount

2017-02-20 Thread Chagin Dmitry
Trying to mount root from ufs:/dev/gpt/rootfs [rw]... <118>Setting hostuuid: 6e6fa481-535f-11cb-9756-be6694d54790. <118>Setting hostid: 0xa94c64a9. <118>Starting file system checks: <118>/dev/gpt/rootfs: FILE SYSTEM CLEAN; SKIPPING CHECKS <118>/dev/gpt/rootfs: clean, 1877279 free (13871 frags,

Panic after mount() fail.

2003-11-17 Thread Pawel Jakub Dawidek
Hello. There is a problem with mount(2) failures. It can cause panics. How-to-repeat. # dd if=/dev/random of=/test.img bs=1m count=8 # mdconfig -a -t vnode -f /test.img -u 25 # mkdir -p /mnt/test # mount /dev/md25 /mnt/test (fail) # mount

Re: Panic after mount() fail.

2003-11-17 Thread Robert Watson
On Mon, 17 Nov 2003, Pawel Jakub Dawidek wrote: Hello. There is a problem with mount(2) failures. It can cause panics. How-to-repeat. # dd if=/dev/random of=/test.img bs=1m count=8 # mdconfig -a -t vnode -f /test.img -u 25 # mkdir -p /mnt/test # mount

Re: panic on mount

2001-09-25 Thread John Baldwin
On 25-Sep-01 Bill Fenner wrote: I also started getting this error with recent kernels (in the last day or so). It looks like the mutex is really held since the mtx_assert before witness_unlock didn't trigger. You can try turning witness off for the time being as a workaround. I'm not sure

Re: panic on mount

2001-09-25 Thread Ian Dowse
In message [EMAIL PROTECTED], John Baldwin writes: It looks like the mutex is really held since the mtx_assert before witness_unlock didn't trigger. You can try turning witness off for the time being as a workaround. I'm not sure why witness would be broken, however. Revision 1.41 of

Re: panic on mount

2001-09-24 Thread Bill Fenner
I also started getting this error with recent kernels (in the last day or so). Mounting root from ufs:/dev/ad0s1a panic: lock (sleep mutex) vnode interlock not locked @ /usr/src/sys/kern/vfs_default.c:460 Debugger(panic) Stopped at Debugger+0x44: pushl %ebx db t Debugger(c03c5bbb) at

Re: panic on mount

2001-09-24 Thread Julian Elischer
You could probably set teh device using DDB, but I just use a serial debug link On Mon, 24 Sep 2001, Bill Fenner wrote: I also started getting this error with recent kernels (in the last day or so). Mounting root from ufs:/dev/ad0s1a panic: lock (sleep mutex) vnode interlock not locked

Re: panic on mount

2001-09-24 Thread Peter Wemm
Julian Elischer wrote: You could probably set teh device using DDB, but I just use a serial debug link Not a good strategy. dev_t is a pointer in -current. We probably need a 'dumpon 13,0x00020001' ddb command that does something like what sysctl_kern_dumpdev() does.. On Mon, 24 Sep 2001,

panic on mount

2001-09-23 Thread Evan Sarmiento
Hello, After compiling a new kernel, installing it, when my laptop tries to mount its drive, it panics with this message: panic: lock (sleep mutex) vnode interlock not locked @ ../../../kern/vfs_default.c:460 which is: if (ap-a_flags LK_INTERLOCK)

Re: panic on mount

2001-09-23 Thread Mark Murray
After compiling a new kernel, installing it, when my laptop tries to mount its drive, it panics with this message: panic: lock (sleep mutex) vnode interlock not locked @ ../../../kern/vfs_default.c:460 which is: if (ap-a_flags LK_INTERLOCK)

Re: panic on mount

2001-09-23 Thread Peter Wemm
Mark Murray wrote: After compiling a new kernel, installing it, when my laptop tries to mount its drive, it panics with this message: panic: lock (sleep mutex) vnode interlock not locked @ ../../../kern/vfs_default.c:460 which is: if (ap-a_flags LK_INTERLOCK)