On Thu, Jan 30, 2025 at 02:37:53AM +, Bjoern A. Zeeb wrote:
> Hi.
>
> I broke into the kernel debugger after some driver went haywire.
>
> Upon typing reset to restart the machine I got the below.
> How can we still report a LOR and panic on a lock when we
> are reset
Hi.
I broke into the kernel debugger after some driver went haywire.
Upon typing reset to restart the machine I got the below.
How can we still report a LOR and panic on a lock when we
are resetting the machine from ddb?
/bz
db> reset
lock order reversal: (sleepable after non-sleepable)
Shouldn't be a problem. The socket used for lookup is
AF_UNIX (uses unp_connectat) and the NFS socket
will always be UDP or TCP.
Different sockets imply different socket locks.
At least that's my interpretation, rick
On Wed, Apr 3, 2024 at 11:33 AM Bjoern A. Zeeb
wrote:
>
>
> NFS root boot of a
NFS root boot of a Lab machine; calling wpa_cli:
Thilock order reversal:
1st 0x0001d4e1c800 so_snd_sx (so_snd_sx, sx) @
/usr/src/sys/kern/uipc_socket.c:4020
2nd 0xa020cb20e930 nfs (nfs, lockmgr) @ /usr/src/sys/kern/vfs_lookup.c:1083
lock order nfs -> so_snd_sx established at:
#0 0xf
Hi All,
Seeing the below LOR in the 13.x kernel, is this a known issue ?
Could this cause vnode to max out and slow down the system.
Is there a patch available?(or can we ignore this ?)
kernel: Waiting (max 60 seconds) for system process `vnlru' to stop...done
kernel: Waiting (max 60 se
Hi,
I’ve seen following LOR in -CURRENT (3a46fe226193) on GENERIC arm64.aarch64:
lock order reversal:
1st 0x41af89e8 tcphash (tcphash, sleep mutex) @
/usr/src/sys/netinet/tcp_usrreq.c:1513
2nd 0x00f91648 in6_ifaddr_lock (in6_ifaddr_lock, rm) @
/usr/src/sys/netinet6/in6_src.c
I see this LOR on head r364364 while running the tcptestsuite
(ports/net/tcptestsuite). In fact, I interrupted a test with Ctrl-C,
and got a panic. I assume it's the same, since the test was twiddling
the MTU, but I haven't looked closely.
Eric
lock order reversal: (sleepable
Hi,
I am trying out 12.0-ALPHA6-amd64-20180914-r338675 vmdk with a VM with two
CPUs.
When doing "shutdown -h now" I get a lock order reversal, is this expected?
According to https://www.freebsd.org/doc/faq/troubleshoot.html#idp59076936 it
is possible to get false positives from witness.
Attachi
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 how
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 usa
amd64_syscall+0x79b/frame 0xfe0458a3a1b0
> Xfast_syscall+0xfb/frame 0xfe0458a31ab0
> syscall (378, FreeBSD ELF64, sys_nmount), rip = 0x800a88d6a, rsp =
> 0x7fffd428, rbp = 0x7fffd990
> kdb_enter+0x3b: movq $0,kdb_why
In this case the panic is separate from the LOR, and
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
g_
eck the links on this page to see if your LOR is already
> >>> listed:
> >>>
> >>> https://wiki.freebsd.org/LOR
> >> Thank you, I wasn't aware of this page. It turns out it's already listed:
> >> http://sources.zabbadoz.net/freebsd/lor/23
On 2017. 03. 09. 6:59, Benjamin Kaduk wrote:
On Wed, Mar 08, 2017 at 02:06:33PM +0100, Gergely Czuczy wrote:
On 2017. 03. 08. 13:06, Hans Petter Selasky wrote:
You might check the links on this page to see if your LOR is already
listed:
https://wiki.freebsd.org/LOR
Thank you, I wasn&#
On Wed, Mar 08, 2017 at 02:06:33PM +0100, Gergely Czuczy wrote:
> On 2017. 03. 08. 13:06, Hans Petter Selasky wrote:
> > You might check the links on this page to see if your LOR is already
> > listed:
> >
> > https://wiki.freebsd.org/LOR
> Thank you, I wasn'
On 2017. 03. 08. 13:06, Hans Petter Selasky wrote:
On 03/08/17 12:23, Gergely Czuczy wrote:
Hello,
I've built an image for RPi3 from -CURRENT checkout at r314894, and
while booting, I've noticed a LOR message:
http://czg.harmless.hu/aegir/LOR_1_1280.jpg
I don't know whether
On 03/08/17 12:23, Gergely Czuczy wrote:
Hello,
I've built an image for RPi3 from -CURRENT checkout at r314894, and
while booting, I've noticed a LOR message:
http://czg.harmless.hu/aegir/LOR_1_1280.jpg
I don't know whether this one is any concern, if so, I'm just let
Hello,
I've built an image for RPi3 from -CURRENT checkout at r314894, and
while booting, I've noticed a LOR message:
http://czg.harmless.hu/aegir/LOR_1_1280.jpg
I don't know whether this one is any concern, if so, I'm just letting
you know.
B
Since r307157 I'm bugged with sporadic reboots/crashes of all boxes running
CURRENT. That
is different CPU types (XEON C2D, XEON Haswell, XEON IvyBridge, mobile Haswell
and
desktop IvyBridge).
Below, you'll finde some messages I gathered from the console. I hope this is
of any use,
if not: I'm
On 10/19/16 8:10 AM, geoffroy desvernay wrote:
On 11/17/2015 21:43, Pete Wright wrote:
On 11/12/15 09:44, Pete Wright wrote:
Hi All,
Just wanted a sanity check before filing a PR. I am running r290688 and
am seeing a LOR being triggered in the mpr(4) device:
$ uname -ar
FreeBSD srd0013
On 11/17/2015 21:43, Pete Wright wrote:
>
>
> On 11/12/15 09:44, Pete Wright wrote:
>> Hi All,
>> Just wanted a sanity check before filing a PR. I am running r290688 and
>> am seeing a LOR being triggered in the mpr(4) device:
>>
>> $ uname -ar
>&
> On Jul 4, 2016, at 07:04, René Ladan wrote:
>
> Hi,
>
> I got this LOR today on a 11.0-ALPHA5 amd64 (FTP installation)
> instance running in Virtualbox 5.0.24 r108355 with Windows 10 as a
> host:
>
> 1st ufs (ufs) @ /usr/src/sys/ufs/ufs/ufs_vnops.c:1157
> 2n
Hi,
I got this LOR today on a 11.0-ALPHA5 amd64 (FTP installation)
instance running in Virtualbox 5.0.24 r108355 with Windows 10 as a
host:
1st ufs (ufs) @ /usr/src/sys/ufs/ufs/ufs_vnops.c:1157
2nd bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:263
3rd ufs (ufs) @ /usr/src/sys/kern
3272ca
It seems to happen on shutdown. I don't think I've seen it hang.
The log shows one involving ufs instead of zfs, unfortunately without a stack.
I'm not sure why that is, unless it was the installation memstick.
There's another, probably unrelated, LOR that I'll put in a
FreeBSD xx 11.0-ALPHA5 FreeBSD 11.0-ALPHA5 #0 r302164: Fri Jun 24 02:51:52 UTC
2016 r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
lock order reversal:
1st 0xf80003cff990 if_addr_lock (if_addr_lock) @
/usr/src/sys/netinet/igmp.c:1716
2nd 0x81d7b660 ifnet_rw (ifn
On Monday, April 25, 2016 07:27:00 PM Shawn Webb wrote:
> Here's the backtrace:
>
> lock order reversal: (sleepable after non-sleepable)
> 1st 0xf8002a914840 vm object (vm object) @ /usr/src/sys/vm/vm_fault.c:361
> 2nd 0x822bf9c8 (&nm_mem)->nm_mtx ((&nm_mem)->nm_mtx) @
> /usr/src/sy
Here's the backtrace:
lock order reversal: (sleepable after non-sleepable)
1st 0xf8002a914840 vm object (vm object) @ /usr/src/sys/vm/vm_fault.c:361
2nd 0x822bf9c8 (&nm_mem)->nm_mtx ((&nm_mem)->nm_mtx) @
/usr/src/sys/dev/netmap/netmap_mem2.c:490
stack backtrace:
#0 0x80bb379
On Mon, 14 Mar 2016 16:13:22 -0700 "Chris H" wrote
> On Mon, 14 Mar 2016 15:16:06 -0700 "Robison, Dave"
> wrote
>
> > Hope this is the right place to take this. I can provide more info as
> > requested.
> Hello, Dave.
> I reported nearly identical LOR's last week, and was
> told they're, ahem.
On Mon, 14 Mar 2016 15:16:06 -0700 "Robison, Dave"
wrote
> Hope this is the right place to take this. I can provide more info as
> requested.
Hello, Dave.
I reported nearly identical LOR's last week, and was
told they're, ahem... "normal" see; harmless.
My suggestion; rebuild your kernel, and re
Hope this is the right place to take this. I can provide more info as requested.
lock order reversal:
1st 0xfe03e1823700 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3488
2nd 0xf80005286200 dirhash (dirhash) @
/usr/src/sys/ufs/ufs/ufs_dirhash.c:281
stack backtrace:
#0 0x80a
Is this a known LOR:
lock order reversal:
1st 0xf801d20ea5f0 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1222
2nd 0xf801d2fe6418 syncer (syncer) @
/usr/src/sys/kern/vfs_subr.c:2618
stack backtrace:
#0 0x80a7f810 at witness_debugger+0x70
#1 0x80a7f711 at
On 2/12/16 12:50 AM, Poul-Henning Kamp wrote:
I don't recall seeing this one before:
FreeBSD critter.freebsd.dk 11.0-CURRENT FreeBSD 11.0-CURRENT #31 r293468: Sat
Jan 9 11:50:09 UTC 2016
r...@critter.freebsd.dk:/freebsd/obj/freebsd/svn_src/head/sys/GENERIC amd64
+taskqueue_drain with
I don't recall seeing this one before:
FreeBSD critter.freebsd.dk 11.0-CURRENT FreeBSD 11.0-CURRENT #31 r293468: Sat
Jan 9 11:50:09 UTC 2016
r...@critter.freebsd.dk:/freebsd/obj/freebsd/svn_src/head/sys/GENERIC amd64
+taskqueue_drain with the following non-sleepable locks held:
+exclusive
Closing the loop on this for the archives - I am no longer seeing this
LOR as of r291998.
-pete
On 12/08/15 11:36, Pete Wright wrote:
> Hey All,
> I am seeing a repeated LOR on r291495 that is pretty reproducible. This
> happens right after the system boots:
>
> lock order r
Hey All,
I am seeing a repeated LOR on r291495 that is pretty reproducible. This
happens right after the system boots:
lock order reversal:
1st 0xfe03e37fa920 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3476
2nd 0xf80024c72200 dirhash (dirhash) @
/usr/src/sys/ufs/ufs/ufs_dirhash.c
0468 2483484 1725698413%/usr/src
>> sys/var 17358024 101040 17256984 1%/var
>> root@ton-96: zfs set mountpoint=/usr/obj.4 sys/obj.4
>>
>> I got a LOR (new to me, at any rate) on the console:
>> lock order reversal:
>> 1st 0xf8000612
; sys/obj.3 19588636 2331652 1725698412%/usr/obj.3
> sys/ports 17257080 96 17256984 0%/usr/ports
> sys/src 19740468 2483484 1725698413%/usr/src
> sys/var 17358024 101040 17256984 1%/var
> root@ton-96: zfs set mountpoi
rc
> sys/var 17358024 101040 17256984 1%/var
> root@ton-96: zfs set mountpoint=/usr/obj.4 sys/obj.4
>
> I got a LOR (new to me, at any rate) on the console:
> lock order reversal:
> 1st 0xf8000612da38 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1224
> 2nd
/src 19740468 2483484 1725698413%/usr/src
sys/var 17358024 101040 17256984 1%/var
root@ton-96: zfs set mountpoint=/usr/obj.4 sys/obj.4
I got a LOR (new to me, at any rate) on the console:
lock order reversal:
1st 0xf8000612da38 zfs (zfs) @ /usr/src/sys/kern
On 11/12/15 09:44, Pete Wright wrote:
> Hi All,
> Just wanted a sanity check before filing a PR. I am running r290688 and
> am seeing a LOR being triggered in the mpr(4) device:
>
> $ uname -ar
> FreeBSD srd0013 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r290688: Wed Nov 11
&
Hi All,
Just wanted a sanity check before filing a PR. I am running r290688 and
am seeing a LOR being triggered in the mpr(4) device:
$ uname -ar
FreeBSD srd0013 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r290688: Wed Nov 11
21:28:26 PST 2015 root@srd0013:/usr/obj/usr/src/sys/GENERIC amd64
lock
Hoi,
Looked at:
http://sources.zabbadoz.net/freebsd/lor.html#howtoreportalor
But did not find any reference to ffs_vnops, so it might be a new one?
I got this from running 'make installworld' of todays HEAD IN a bhyveVM
which was already running thismornings kernel.
So it was not the Dom0 ser
fast_syscall+0xfb/frame 0xfe022ed8fab0
>>>>> --- syscall (133, FreeBSD ELF64, sys_sendto), rip = 0x80126c5a, rsp =
>>>>> 0x7fffdf1e9df8, rbp = 0x7fffdf1e9e40 ---
>>
>>>> This is plain fault, in network stack, in the tcp send path. It has
>&g
), rip = 0x80126c5a, rsp =
> >>> 0x7fffdf1e9df8, rbp = 0x7fffdf1e9e40 ---
>
> >> This is plain fault, in network stack, in the tcp send path. It has
> >> nothing to do with sound at all, and the LOR between DRM device lock and
> >> send buffer socket
xfe022ed8fab0
>>> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe022ed8fab0
>>> --- syscall (133, FreeBSD ELF64, sys_sendto), rip = 0x80126c5a, rsp =
>>> 0x7fffdf1e9df8, rbp = 0x7fffdf1e9e40 ---
>> This is plain fault, in network stack, in the tcp send pa
Hi,
I got that LOR few minutes ago:
lock order reversal:
1st 0xf800094f4990 if_addr_lock (if_addr_lock) @
/usr/src/sys/netinet/igmp.c:1716
2nd 0x818800d0 ifnet_rw (ifnet_rw) @ /usr/src/sys/net/if.c:243
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b
p = 0x80126c5a, rsp =
>> 0x7fffdf1e9df8, rbp = 0x7fffdf1e9e40 ---
>>
>> Please note that this is the last one, but at least another one, almost
>> identical to this one, was scrolled up. I've been unable to recover
>> their data, since, as I said the system is hard loc
irtualbox VM with Windows 7, the system locked up
> just after the startup sound was played in the VM, X11 disappeared and
> the system locked hard and a LOR data on screen.
>
> (I already tested recompiling the virtualbox kmod and the bug shows up
> with and without 3d/2d acceleratio
s 7, the system locked up
> just after the startup sound was played in the VM, X11 disappeared and
> the system locked hard and a LOR data on screen.
>
> (I already tested recompiling the virtualbox kmod and the bug shows up
> with and without 3d/2d acceleration enabled in the VM)
>
, X11 disappeared and
the system locked hard and a LOR data on screen.
(I already tested recompiling the virtualbox kmod and the bug shows up
with and without 3d/2d acceleration enabled in the VM)
I copied (by hand, so sorry for any typos) the LOR data:
Lock order reversal: (sleepable after non-sleepable)
On Wed, 5 Nov 2014 13:38:01 -0500 (EST) Benjamin Kaduk wrote
> On Wed, 5 Nov 2014, Chris H wrote:
>
> > Greetings,
> > a fresh install off the 2014-10-26 bootonly iso, generates the
> > following LOR:
> >
> > lock order reversal:
> > 1st 0xfe00
On Wed, 5 Nov 2014, Chris H wrote:
> Greetings,
> a fresh install off the 2014-10-26 bootonly iso, generates the
> following LOR:
>
> lock order reversal:
> 1st 0xfe00f7626b48 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3093
> 2nd 0xf8000404aa00 dirhash (dirh
Greetings,
a fresh install off the 2014-10-26 bootonly iso, generates the
following LOR:
lock order reversal:
1st 0xfe00f7626b48 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3093
2nd 0xf8000404aa00 dirhash (dirhash) @
/usr/src/sys/ufs/ufs/ufs_dirhash.c:2
84
KDB: stack backtrace
> Hi Chris,
>
> On Mon, Aug 25, 2014 at 1:19 PM, Chris H wrote:
>> Greetings, all.
>> I'm testing 11 current, and booting && installing from the
>> 2014-08-11-r269824-disc1.iso
>> returns the following, via dmesg(8):
>>
>> kernel: lock order reversal:
>> kernel: 1st 0xf80002fa37c8 isofs (isofs
Hi Chris,
On Mon, Aug 25, 2014 at 1:19 PM, Chris H wrote:
> Greetings, all.
> I'm testing 11 current, and booting && installing from the
> 2014-08-11-r269824-disc1.iso
> returns the following, via dmesg(8):
>
> kernel: lock order reversal:
> kernel: 1st 0xf80002fa37c8 isofs (isofs) @
> /usr/
Greetings, all.
I'm testing 11 current, and booting && installing from the
2014-08-11-r269824-disc1.iso
returns the following, via dmesg(8):
kernel: lock order reversal:
kernel: 1st 0xf80002fa37c8 isofs (isofs) @
/usr/src/sys/kern/vfs_mount.c:1219
kernel: 2nd 0xf80002fe7240 devfs (devfs)
FYI: Just saw this today after a fresh install of 266923 - GENERIC kernel:
root@darkstor:/ # uname -a
FreeBSD darkstor 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r266923: Sat May 31
10:21:54 CDT 2014 root@darkstor:/usr/obj/usr/src/sys/GENERIC amd64
lock order reversal:
1st 0xf8029cfe79a0
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mounted a drive with -o sync this morning on r266123 and got a LOR I
had not seen before (ufs/soft updates)
lock order reversal:
1st 0xf8005904db78 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2101
2nd 0xfe00efe72080 bufwait (bufwait) @
/usr
I encountered three LOR in head r264695.
The 1st and 2nd are the same and it does not seem to be in
http://sources.zabbadoz.net/freebsd/lor.html ,
though similar LORs exist.
The 3rd seems to be LOR #276
did not look into further detail.
lock order reversal:
1st 0xc6d3b7f8 ufs (ufs) @
/usr/local
On Mon, 17 Feb 2014, Dennis Glatting wrote:
Decided to try clang 3.4 under CURRENT and got a LOR under ESXi:
Feb 17 14:13:10 Head kernel: lock order reversal:
Feb 17 14:13:10 Head kernel: 1st 0xfe00f6868548 bufwait (bufwait)
@ /usr/src/sys/kern/vfs_bio.c:3081
Feb 17 14:13:10 Head kernel
Decided to try clang 3.4 under CURRENT and got a LOR under ESXi:
Feb 17 14:13:10 Head kernel: lock order reversal:
Feb 17 14:13:10 Head kernel: 1st 0xfe00f6868548 bufwait (bufwait)
@ /usr/src/sys/kern/vfs_bio.c:3081
Feb 17 14:13:10 Head kernel: 2nd 0xf800035d3c00 dirhash (dirhash)
@ /usr
I tried searching the list and google and could not find a
reference which seemed to apply. Neither LOR dropped to the debugger.
This happens when under heavy load poudreire 16 processes. If its been
reported or nothing to worry about sorry for the noise.
No sysctl,
make, loader changes
Hi,
Is this real LoR or is it known to be invalid?
lock order reversal:
1st 0xf800323725f0 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1237
2nd 0xf8010e9cdb78 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2210
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b
Hi,
these represent machine lockups, if not false positives.
http://www.freebsd.org/cgi/query-pr.cgi?pr=182139&cat=
jb
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail
Hi current,
I have FreeBSD 10.0-CURRENT #5 r254404 on my laptop. During reboot,
I get the following LOR. Could someone please fix this?
Thanks!
Ke Sun
Syncing disks, vnodes remaining...0 0 0 0 0 0 done
All buffers synced.
lock order reversal:
1st 0xfe00094bd5f0 zfs (zfs) @ /usr/src/sys
On Mon, 5 Aug 2013, Davide Italiano wrote:
The LOR is a false positive.
See the comment in sys/ufs/ufs/ufs_dirhash.c
Also, switching motherboards is not related to this in any way. You'll
eventually hit that LOR report, unless you disabled WITNESS.
Ah, thank you Davide; sorry for the
15312: the secondary GPT table is corrupt or
> invalid.
> GEOM: diskid/DISK-MDT-MCANKK515312: using the primary only -- recovery
> suggested.
> Root mount waiting for: usbus8 usbus5 usbus3
> Root mount waiting for: usbus8 usbus5 usbus3
> uhub7: 4 ports with 4 removable, self powere
I am going to respond to this before I forget
I had the SAME exact LOR's with ath 9300 and I reported them,
however I have since switched out motherboards and the LOR's have strangely
diapered
here is a full dmesg for a perfectly working system
FreeBSD clang version 3.3 (tags/RELEASE_33/fin
Not sure if this is a known issue since I don't usually use UFS.
Yesterday I put current on an acer laptop with an i3 processor/4GB RAM
with UFS file system on a OCZ vertex 2 SSD and trim enabled via tunefs.
Below is the dmesg along with the LOR message at the bottom. I can
provide
On Thursday, May 02, 2013 3:55:25 am Ian FREISLICH wrote:
> Hi
>
> I'm getting these two LORs at boot time, they don't seem to be known
> on http://ipv4.sources.zabbadoz.net/freebsd/lor.html
>
> lock order reversal:
> 1st 0xff83e37ee938 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3070
>
Hi
I'm getting these two LORs at boot time, they don't seem to be known
on http://ipv4.sources.zabbadoz.net/freebsd/lor.html
lock order reversal:
1st 0xff83e37ee938 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3070
2nd 0xfe0030283800 dirhash (dirhash) @
/usr/src/sys/ufs/ufs/ufs_dirh
# dump -0aLuf - / | restore -rf -
produces this panic:
lock order reversal:
1st 0xa0009ca034f8 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2652
2nd 0xe0001163ebb0 snaplk (snaplk) @
/usr/src/sys/ufs/ffs/ffs_snapshot.c:2297
KDB: stack backtrace:
getenv with the following non-sleepab
Hi,
Getting this LOR every time I login via ssh after reboot, and it doesn't
seem to be reported previously. Running 10.0-CURRENT r230537.
lock order reversal:
1st 0xfe0160615490 so_snd_sx (so_snd_sx) @
/usr/src/sys/kern/uipc_sockbuf.c:148
2nd 0xfe0029ef1048 filedesc stru
On 19 August 2011 05:07, Garrett Cooper wrote:
> Hi,
> I've periodically seen the following LOR when trying to repro a
> panic after restarting my network configuration:
>
> :lock order reversal:
> 1st 0xc4142f1c rtentry (rtentry) @ /usr/src/sys/net/routec:362
>
On 8/23/2011 7:48 AM, Garrett Cooper wrote:
> On Tue, Aug 23, 2011 at 4:29 AM, Holger Kipp wrote:
>> Maybe already seen...
>> This is within Parallels 6.0 VM on a Mac with OS 10.6.8
>
> ...
>
> This is a well known LOR.
There are a lot of well-known LORs in HEA
On Tue, Aug 23, 2011 at 4:29 AM, Holger Kipp wrote:
> Maybe already seen...
> This is within Parallels 6.0 VM on a Mac with OS 10.6.8
...
This is a well known LOR.
Thanks,
-Garrett
___
freebsd-current@freebsd.org mailing list
http://lists.freeb
Maybe already seen...
This is within Parallels 6.0 VM on a Mac with OS 10.6.8
Aug 23 09:11:54 tramp kernel: lock order reversal:
Aug 23 09:11:54 tramp kernel: 1st 0xff803d3d08b8 bufwait (bufwait) @
/usr/src/sys/kern/vfs_bio.c:2658
Aug 23 09:11:54 tramp kernel: 2nd 0xfe0002b6c800 dirhash (
Hi,
I've periodically seen the following LOR when trying to repro a
panic after restarting my network configuration:
:lock order reversal:
1st 0xc4142f1c rtentry (rtentry) @ /usr/src/sys/net/routec:362
2nd 0xc3d08604 if_afdata (if_afdata) @ /usr/src/sys/netinet6/scope6.c:417
KDB:
Hello John,
These seem to be well-known, per
http://ipv4.sources.zabbadoz.net/freebsd/lor.html
On Tue, 16 Aug 2011, John wrote:
Hi folks,
I'm seeing 3 lock order reversals with an up-to-date -current
system. Stock system, GENERIC kernel. Let me know if this isn't
enough information. Just bo
Hi folks,
I'm seeing 3 lock order reversals with an up-to-date -current
system. Stock system, GENERIC kernel. Let me know if this isn't
enough information. Just booting the system and the dmesg.
Thanks,
John
lock order reversal:
1st 0xfe0289627db8 ufs (ufs) @
/usr/src.2011-08-14_10.53p
Hi Folks,
I just updated this particular systems to current as of this
evening (2011-07-05 7:22pm EDT) and am still seeing this LOR.
lock order reversal:
1st 0xfe003c893818 ufs (ufs) @
/usr/src.2011-07-05_7.22pm_EDT/sys/kern/vfs_lookup.c:501
2nd 0xff9f0c7eeef8 bufwait (bufwait
Hi folks,
I'm seeing the following LOR in dmesg after my latest update this evening.
# uname -a
FreeBSD zfscarp3p 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Fri Jun 17 22:36:45 EDT
2011 root@zfscarp3p/usr/obj/usr/src.2011-06-17_9.36pm_EDT/sys/GENERIC amd6
WARNING: WITNESS option en
On Mon, Jan 17, 2011 at 7:44 AM, Sergey Kandaurov wrote:
> On 20 February 2010 03:25, Garrett Cooper wrote:
>> Hi,
>> I came across the following LoR:
>>
>> lock order reversal:
>> 1st 0xc56aae04 if_afdata (if_afdata) @
>> /usr/home/garrcoop/ipcvs/free
On 20 February 2010 03:25, Garrett Cooper wrote:
> Hi,
> I came across the following LoR:
>
> lock order reversal:
> 1st 0xc56aae04 if_afdata (if_afdata) @
> /usr/home/garrcoop/ipcvs/freebsd/src/sys/net/if_llatbl.c:130
> 2nd 0xc58a1d80 radix node head (radix node head) @
ntr_event_execute_handlers()
> ithread_loop()
> fork_exit()
> fork_trampoline()
> --- trap 0, rip = 0, rsp = 0xff8123559cf0, rbp = 0 ---
>
AFAIK, this LOR is documented in siftr(4) as harmless.
--
wbr,
pluknet
___
freebsd-current@freebsd.org m
1st 0x80990308 PFil read/write mutex (PFil hook read/write
mutex @ /usr/src/head/sys/net/pfil.c:77
2nd 0x80991528 tcp (tcp)
@ /usr/src/head/sys/modules/siftr/../../netinet/siftr.c:702
KDB: stack backtrace:
db_trace_self_wrapper()
kdb_backtrace()
_witness_debugger()
witness_checkorde
$ uname -a
FreeBSD satanasso.local.net 9.0-CURRENT FreeBSD 9.0-CURRENT #1: Mon Oct 11 09:
10:51 CEST 2010 r...@satanasso.local.net:/usr/obj/usr/src/sys/SATANASSO
i386
lock order reversal:
1st 0xc68ec278 ufs (ufs) @ /usr/src/sys/kern/vfs_lookup.c:501
2nd 0xd995fc70 bufwait (bufwait) @ /usr/sr
$ uname -a
FreeBSD satanasso.local.net 9.0-CURRENT FreeBSD 9.0-CURRENT #1: Mon Oct 11 09:
10:51 CEST 2010 r...@satanasso.local.net:/usr/obj/usr/src/sys/SATANASSO
i386
lock order reversal:
1st 0xc6befdd0 process lock (process lock) @ /usr/src/sys/kern/kern_sig.c:3341
2nd 0xc19b60e4 system map
An LOR, which resembles another reported in:
http://lists.freebsd.org/pipermail/freebsd-current/2010-August/018986.html
but none that I noticed at:
http://sources.zabbadoz.net/freebsd/lor.html
lock order reversal:
1st 0xff0001696098 ufs (ufs) @ /mnt/disk2/usr/src/sys/kern/vfs_lookup.c:501
> new proc startup being equivalent to the LOR. I think that the wait
> > > is safe, because the task is executed in the context of
> > > the different process then the enqueue request.
> > > This might be worth noting in the comment or commit message.
> >
> > I
On Fri, Aug 20, 2010 at 03:35:48PM -0400, John Baldwin wrote:
> On Friday, August 20, 2010 3:19:53 pm Kostik Belousov wrote:
> > It seems nobody replied to the mdf@ objection against wait of the
> > new proc startup being equivalent to the LOR. I think that the wait
> > is s
; >> > Also, I'm not sure how this works as you don't actually wait for the
> > >> > task to
> > >> > complete. If the taskqueue_enqueue() doesn't preempt, then you may
> > >> > read
> > >> > ni_error as zero b
ly wait for the
> >> > task to
> >> > complete. If the taskqueue_enqueue() doesn't preempt, then you may read
> >> > ni_error as zero before the kproc has actually been created and return
> >> > success
> >> > even though an nfsiod hasn&
On 19 August 2010 17:34, John Baldwin wrote:
> On Thursday, August 19, 2010 5:29:25 am pluknet wrote:
>> On 19 August 2010 00:07, John Baldwin wrote:
>> > On Wednesday, August 18, 2010 3:17:56 pm pluknet wrote:
>> >> On 18 August 2010 23:11, pluknet wrote:
>> >> > On 18 August 2010 17:46, Kostik
On Thursday, August 19, 2010 5:29:25 am pluknet wrote:
> On 19 August 2010 00:07, John Baldwin wrote:
> > On Wednesday, August 18, 2010 3:17:56 pm pluknet wrote:
> >> On 18 August 2010 23:11, pluknet wrote:
> >> > On 18 August 2010 17:46, Kostik Belousov wrote:
> >> >> On Wed, Aug 18, 2010 at 02
On 19 August 2010 04:04, Rick Macklem wrote:
>> On 18 August 2010 12:07, pluknet wrote:
>> > On 17 August 2010 20:04, Kostik Belousov wrote:
>> >
>> >>
>> >> Also please take a note of the John' suggestion to use the taskqueue.
>> >
>> > I decided to go this road. Thank you both.
>> > Now I do n
On 19 August 2010 00:07, John Baldwin wrote:
> On Wednesday, August 18, 2010 3:17:56 pm pluknet wrote:
>> On 18 August 2010 23:11, pluknet wrote:
>> > On 18 August 2010 17:46, Kostik Belousov wrote:
>> >> On Wed, Aug 18, 2010 at 02:43:19PM +0400, pluknet wrote:
>> >>> On 18 August 2010 12:07, pl
> On 18 August 2010 12:07, pluknet wrote:
> > On 17 August 2010 20:04, Kostik Belousov wrote:
> >
> >>
> >> Also please take a note of the John' suggestion to use the taskqueue.
> >
> > I decided to go this road. Thank you both.
> > Now I do nfs buildkernel survive and prepare some benchmark resu
On Wednesday, August 18, 2010 3:17:56 pm pluknet wrote:
> On 18 August 2010 23:11, pluknet wrote:
> > On 18 August 2010 17:46, Kostik Belousov wrote:
> >> On Wed, Aug 18, 2010 at 02:43:19PM +0400, pluknet wrote:
> >>> On 18 August 2010 12:07, pluknet wrote:
> >>> > On 17 August 2010 20:04, Kosti
On 18 August 2010 23:11, pluknet wrote:
> On 18 August 2010 17:46, Kostik Belousov wrote:
>> On Wed, Aug 18, 2010 at 02:43:19PM +0400, pluknet wrote:
>>> On 18 August 2010 12:07, pluknet wrote:
>>> > On 17 August 2010 20:04, Kostik Belousov wrote:
>>> >
>>> >>
>>> >> Also please take a note of
1 - 100 of 336 matches
Mail list logo
