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
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
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
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
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
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 =
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,
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
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
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
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
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
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
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,
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)
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)
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)
17 matches
Mail list logo