On Fri, 27 Sep 2013 05:57:45 +0200, Shane Ambler
wrote:
After booting from a 10-alpha2 disk I am seeing "lock order reversal"
messages show up from time to time. Current logs have 35 entries.
FreeBSD 10-ALPHA is still being build with kernel option WITNESS on. This
After booting from a 10-alpha2 disk I am seeing "lock order reversal"
messages show up from time to time. Current logs have 35 entries.
The machine normally is running 9.1 from zfs root and I have setup a
separate disk (eSATA case connected through backplane port to onboard
SATA po
2008/3/25, Max Laier <[EMAIL PROTECTED]>:
> Hi Alex,
>
> so it's basically back to square one. We only have LORs between the pfil
> R/W lock (read instance) and mutexes that don't have any lock order with
> the pfil R/W lock (write instance) at all. This means the deadlock can't
> be explaine
ole
> changing, no control-alt-esc to debugger) after about 41 minutes
> (timestamps in /var/log/all.log go from 19:12:57 to 19:53:40).
>
> I did get two LOR reports in dmesg, they are attached.
> lock order reversal:
> 1st 0x8096ebc8 PFil hook read/write mutex (PFil hook
ws
Alex
--
"Computer science is no more about computers
than astronomy is about telescopes" -- E. W. Dijkstra
lock order reversal:
1st 0x8096ebc8 PFil hook read/write mutex (PFil hook read/write mutex)
@ /usr/src/sys/net/pfil.c:73
2nd 0x8096f8e8 udp
Hi Alex,
On Saturday 22 March 2008 11:29:33 Alex Popa wrote:
> Sorry for the big delay, but here are the traces you requested.
don't worry, you are a great help!
Could you try the attached patch? I missed the fact that you are using
FASTROUTE in your setup. There is obviously a problem with i
On Sun, Mar 16, 2008 at 10:16:20PM +, ian j hart wrote:
> Keyboard LEDs are broken for me on 6.3 amd64 (kbdmux).
> I'd double check they work before you rely on this as a diagnostic tool.
>
> --
> ian j hart
Well, that was the most basic test.
I should have mentioned that, during the lockup
opa wrote:
> > > > [snip]
> > > > The LOR messages from dmesg of 7.0-STABLE are as follows:
> > > >
> > > > lock order reversal:
> > > > 1st 0xb19e0680 pf task mtx (pf task mtx) @
> > > > /usr/src/sys/modules/p
Attached are pf.conf and ipfw.txt. The former is loaded by the standard
means, and the latter is loaded via ipfw -q /path/to/ipfw.txt
Some comments: I've anonymized the files. Address in the 10.0.0.0/8
range stand for "internal" IP addresses, meaning one /27 and three /24
networks, and address
f 7.0-STABLE are as follows:
> > >
> > > lock order reversal:
> > > 1st 0xb19e0680 pf task mtx (pf task mtx) @
> > > /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:6729 2nd
> > > 0xff00042ea0f0 radix node head (radix node head) @
> &g
e head (radix node head) @
> > /usr/src/sys/net/route.c:147
I haven't seen this one before, can you obtain the trace for this, please?
You might need KDB & DDB for that - not sure.
> > lock order reversal:
> > 1st 0x80938508 PFil hook read/write mutex (PFil hook
&g
, but upgrading to 6.3-REL made it
lock up just like 7.0 (so we put 6.2 back and accepted the lower performance
for the time being).
The LOR messages from dmesg of 7.0-STABLE are as follows:
lock order reversal:
1st 0xb19e0680 pf task mtx (pf task mtx) @
/usr/src/sys/modules/pf/../../contr
Extra details: The machine shows no problems when running
6.2-RELEASE-p7 / i386.
Upgrading to 6.3-RELEASE / i386 caused the machine to start randomly
locking up, much faster than 7.0 (about 4 hours versus 12+)
Have tried 7.0-RELEASE/i386, 7.0-RELEASE/amd64, both with SMP support.
I've also tried
e 7.0 (so we put 6.2 back and accepted
the lower performance for the time being).
The LOR messages from dmesg of 7.0-STABLE are as follows:
lock order reversal:
1st 0xb19e0680 pf task mtx (pf task mtx) @
/usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:6729
2nd 0xff00042ea0f0 radix
This time I didn't get a LOR, but:
kdb_backtrace(0,1,c07328e8,c0732780,c0700d3c) at 0xc053f7e1 = kdb_backtrace+0x29
witness_checkorder(c6c33900,9,c06ce108,3d3) at 0xc0549180 =
witness_checkorder+0x544
_mtx_lock_flags(c6c33900,0,c06ce108,3d3,0) at 0xc052184b = _mtx_lock_flags+0x5b
in_pcblookup_loc
ufs:/dev/ar0s1a
WARNING: / was not properly dismounted
WARNING: /mnt/media was not properly dismounted
WARNING: /tmp was not properly dismounted
WARNING: /usr was not properly dismounted
WARNING: /usr/home was not properly dismounted
WARNING: /var was not properly dismounted
em0: Link is up 1000 Mb
kernel: lock order reversal
Apr 26 09:57:56 ram kernel: 1st 0xc162e3b4 em0 (network driver) @ /usr/src/sys/dev/em/if_em.c:980
Apr 26 09:57:56 ram kernel: 2nd 0xc0663d80 Giant (Giant) @ /usr/src/sys/vm/vm_contig.c:538
Apr 26 09:57:56 ram kernel: KDB: stack backtrace:
Apr 26 09:57:56 ram kernel
Hi,
FreeBSD 5.3-RELEASE-p5 on a Tyan Tiger LE with two PIII/733s an
Intel Pro/1000MT 64-bit NIC in a 66MHz PCI slot nets me these
repeatedly on boot immediately after the interface comes up:
Apr 26 09:57:56 ram kernel: em0: Link is up 1000 Mbps Full Duplex
Apr 26 09:57:56 ram kernel: lock order
On Tue, Mar 15, 2005 at 12:58:37AM +0100, Marc Olzheim wrote:
> Alas, no KDB builtin :-/
Hmmm...:
rave:/# sysctl debug.kdb.available | less
debug.kdb.available:
rave:/#
Is that supposed to happen ?
Marc
pgpu5P0fBvKKJ.pgp
Description: PGP signature
On Mon, Mar 14, 2005 at 07:34:21PM +, Bjoern A. Zeeb wrote:
> > lock order reversal
> > 1st 0xc5d4c900 inp (tcpinp) @ /usr/src/sys/netinet/tcp_usrreq.c:303
> > 2nd 0xc6a0cd10 so_rcv (so_rcv) @ /usr/src/sys/netinet/tcp_usrreq.c:304
> > 3rd 0xc68c1630 inp (tcpinp
On Mon, 14 Mar 2005, Marc Olzheim wrote:
Hi,
> lock order reversal
> 1st 0xc5d4c900 inp (tcpinp) @ /usr/src/sys/netinet/tcp_usrreq.c:303
> 2nd 0xc6a0cd10 so_rcv (so_rcv) @ /usr/src/sys/netinet/tcp_usrreq.c:304
> 3rd 0xc68c1630 inp (tcpinp) @ /usr/src/sys/netinet/in_pcb.c:971
d
lock order reversal
1st 0xc5d4c900 inp (tcpinp) @ /usr/src/sys/netinet/tcp_usrreq.c:303
2nd 0xc6a0cd10 so_rcv (so_rcv) @ /usr/src/sys/netinet/tcp_usrreq.c:304
3rd 0xc68c1630 inp (tcpinp) @ /usr/src/sys/netinet/in_pcb.c:971
kern.ostype: FreeBSD
kern.osrelease: 5.4-PRERELEASE
kern.osrevision
just after initializing the network (configuring the NIC's
for autoneg to a DLink GigE switch), console spits out this lock order
reversal:
-=-
Starting local daemons:bge1: gigabit link up
lock order reversal
1st 0xc5a65dec inp (rawinp) @ netinet/raw_ip.c:199
2nd 0xc5a65ea0 inp (raw6inp)
igE switch), console spits out this lock order
reversal:
-=-
Starting local daemons:bge1: gigabit link up
lock order reversal
1st 0xc5a65dec inp (rawinp) @ netinet/raw_ip.c:199
2nd 0xc5a65ea0 inp (raw6inp) @ netinet/raw_ip.c:199
KDB: stack backtrace:
kdb_backtrace(,c08fdb48,c08fdb70,c088f47
24 matches
Mail list logo
