Dear hackers,
I couldn't find a up to date list for begning LOR reports. Since
ffs/vfs.. LORs, which I don't understand, diffused my attention over the
time, I'm not aware about the actual importance of them these days
(without panic).
Here's is one, happening on 11.1-BE
On 10/19/2016 06:39 PM, Pete Wright wrote:
>
> the issue you are seeing is most likely not related to the LOR from the
> original email and PR I filed. This looks like a media error with the
> disk device on your RAID controller. A quick google search turn's up
> quite a
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
>&
Apologies. The mail server is truncating the text.
Attached as a TXT.
On Tue, Feb 16, 2016 at 7:30 PM, Mahmoud Al-Qudsi wrote:
> Hello all,
>
> I'm including below a list of LORs that I experienced running an x86
> build of 10.2-RELEASE-p2.
>
> Some known LORs are also included for posterity's s
Hello all,
I'm including below a list of LORs that I experienced running an x86
build of 10.2-RELEASE-p2.
Some known LORs are also included for posterity's sake, as all are from
a single session and appear in chronological order, should this
information be of any additional use. I believe from a
= 0x81488010
tss = 0x81488000
This looks like a bug I started tracing down a while back with
the new enclosure services (r246437 and later). I added witness
into the kernel and received the following LOR:
Kernel page fault with the following non-sleepable locks held:
exclusive sleep
em seems to happen
> when the file's size has been truncated.)
>
> Herve Boulouis, if you want to see what r223054 changes, just go to
> http://svn.freebsd.org/viewvc/stable/8/sys/nfsclient
> and then click on nfs_bio.c.
> (The changes are small and could easily
Kostik Belousov wrote:
> On Tue, Jul 26, 2011 at 01:17:52PM +0200, Herve Boulouis wrote:
> > Le 26/07/2011 12:06, Kostik Belousov a Иcrit:
> > > On Tue, Jul 26, 2011 at 11:49:13AM +0200, Herve Boulouis wrote:
> > > > Le 25/07/2011 11:59, Kostik Belousov a ?crit:
> > > >
> > > > Ok the patched serve
On Tue, Jul 26, 2011 at 01:17:52PM +0200, Herve Boulouis wrote:
> Le 26/07/2011 12:06, Kostik Belousov a Иcrit:
> > On Tue, Jul 26, 2011 at 11:49:13AM +0200, Herve Boulouis wrote:
> > > Le 25/07/2011 11:59, Kostik Belousov a ?crit:
> > >
> > > Ok the patched server crashed this morning strangely
Le 26/07/2011 12:06, Kostik Belousov a ?crit:
> On Tue, Jul 26, 2011 at 11:49:13AM +0200, Herve Boulouis wrote:
> > Le 25/07/2011 11:59, Kostik Belousov a ?crit:
> >
> > Ok the patched server crashed this morning strangely : all httpd processes
> > were stuck in nfs or vmopar
> > and were unkil
On Tue, Jul 26, 2011 at 11:49:13AM +0200, Herve Boulouis wrote:
> Le 25/07/2011 11:59, Kostik Belousov a Иcrit:
>
> Ok the patched server crashed this morning strangely : all httpd processes
> were stuck in nfs or vmopar
> and were unkillable. Below is the full ps.
Please see the
http://www.fre
Le 25/07/2011 11:59, Kostik Belousov a ?crit:
Ok the patched server crashed this morning strangely : all httpd processes were
stuck in nfs or vmopar
and were unkillable. Below is the full ps.
When tried to reboot it got stuck after "All buffers synced" with LOR :
lock order reve
Le 25/07/2011 11:59, Kostik Belousov a ?crit:
> On Mon, Jul 25, 2011 at 12:21:07PM +0200, Herve Boulouis wrote:
> > Hi list,
> >
> > We have 2 freebsd 8.2-STABLE (cvsuped june 22) that keeps crashing in a bad
> > way :
> >
> > The are doing heavy apache / php4 web serving from a nfs mount and p
On Mon, Jul 25, 2011 at 12:21:07PM +0200, Herve Boulouis wrote:
> Hi list,
>
> We have 2 freebsd 8.2-STABLE (cvsuped june 22) that keeps crashing in a bad
> way :
>
> The are doing heavy apache / php4 web serving from a nfs mount and panic at
> least once a day
> with the following message (no
Hi list,
We have 2 freebsd 8.2-STABLE (cvsuped june 22) that keeps crashing in a bad way
:
The are doing heavy apache / php4 web serving from a nfs mount and panic at
least once a day
with the following message (no crash dump produced, hand copied from the
console) :
Sleeping on "vmopar" with
On 17 April 2010 00:53, Jack Vogel wrote:
> Why are you using ZERO_COPY_SOCKETS? And is this LOR happening on STABLE or
> CURRENT?
>
I got exactly this and another similar LORs with GENERIC on head.
The second:
login: lock order reversal:
1st 0xff0002539a18 em0:rx(0) (em0:rx(0)
Jack Vogel schrieb am 16.04.2010 22:58 (localtime):
No objection, I just wondered if it could somehow be involved in the
problem you are seeing.
What do you use that actually uses them?
I think fxp in the former times made use of ZERO_CPOY_SOCKETS. I also
have some private boxes arround with
>
> Why are you using ZERO_COPY_SOCKETS? And is this LOR happening on STABLE
>> or
>>
> > CURRENT?
>
> It's RELENG_8.
> I've alway been using ZERO_COPY_SOCKETS.
> Some time ago, AFAIR, I read that this doesn't affect em at all.
>
Jack Vogel schrieb am 16.04.2010 22:53 (localtime):
Why are you using ZERO_COPY_SOCKETS? And is this LOR happening on STABLE or
> CURRENT?
It's RELENG_8.
I've alway been using ZERO_COPY_SOCKETS.
Some time ago, AFAIR, I read that this doesn't affect em at all.
An
Why are you using ZERO_COPY_SOCKETS? And is this LOR happening on STABLE or
CURRENT?
Jack
On Fri, Apr 16, 2010 at 1:42 PM, Harald Schmalzbauer <
h.schmalzba...@omnilan.de> wrote:
> Jack Vogel schrieb am 16.04.2010 22:02 (localtime):
>
> Glad things are better. On the Hartw
Jack Vogel schrieb am 16.04.2010 22:02 (localtime):
Glad things are better. On the Hartwell, the 0x10D3 adapter, what is the
problem you are seeing?
I just did an MFC, would ask that you try that code, see if it changes
anything.
With latest MFCs I see em0:
but still this LOR:
login: lock
Glad things are better. On the Hartwell, the 0x10D3 adapter, what is the
problem you are seeing?
I just did an MFC, would ask that you try that code, see if it changes
anything.
Regards,
Jack
On Fri, Apr 16, 2010 at 11:07 AM, Harald Schmalzbauer <
h.schmalzba...@omnilan.de> wrote:
> Brandon Go
Brandon Gooch schrieb am 16.04.2010 17:32 (localtime):
...
Thanks Jack! Your work is very appreciated.
It's extremely appreciated!
I tried another semi-productive system and since that hadn't exposed any
peculiarity I also upgraded one not too important productive machine.
All have onboard 82
gt; some time I can open another ssh session which seems to stay without
>> > >> problems, but the first sessions is always dying a few seconds after
>> > >> login.
>> > >> here's a LOR:
>> > >> {snip}
>> > >
>> &g
; problems, but the first sessions is always dying a few seconds after
> > >> login.
> > >> here's a LOR:
> > >> {snip}
> > >
> > > The e1000/em driver was recently modified (heavily). I saw the large
> > > number of commits
> ssh connection stalled.
> >> With today's RELENG_8 it reproducably hangs at first login. After
> >> some time I can open another ssh session which seems to stay without
> >> problems, but the first sessions is always dying a few seconds after
> >> lo
ime I can open another ssh session which seems to stay without
problems, but the first sessions is always dying a few seconds after
login.
here's a LOR:
{snip}
The e1000/em driver was recently modified (heavily). I saw the large
number of commits come across in a csup a few weeks ago, and th
ich seems to stay without
> problems, but the first sessions is always dying a few seconds after
> login.
> here's a LOR:
> {snip}
The e1000/em driver was recently modified (heavily). I saw the large
number of commits come across in a csup a few weeks ago, and there's
even more
a few seconds after login.
here's a LOR:
lock order reversal:
1st 0xff0001801018 em0:rx(1) (em0:rx(1)) @
/usr/src/sys/dev/e1000/if_em.c:4057
2nd 0x80938908 udp (udp) @ /usr/src/sys/netinet/udp_usrreq.c:474
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wr
entry into vm subsystem
while zfs vnode lock is held.
If the buffer is backed by e.g. UFS vnode instead of anonymous
memory, you would get UFS/zfs LOR.
The problem is generic, I am working on the solution in collaboration
with Peter Holm, basing on the Jeff Roberson idea.
>
> lock order
I had the following crop up recently in 8-STABLE/amd64 from end of
November. It's been reported as kern/143184.
lock order reversal:
1st 0xff002f7fb270 zfs (zfs) @ /usr/src/sys/kern/vfs_vnops.c:533
2nd 0xff80803a26e0 bufwait (bufwait) @ /usr/src/sys/vm/vm_pager.c:311
KDB: stack backtrac
On Wednesday 13 January 2010 2:30:04 am pluknet wrote:
> 2010/1/13 Gardner Bell :
> > I got this lock order reversal while running a windows executable through
> > wine.
>
> I'm guess that is a regression w.r.t S/G pager, which uses kmem_alloc/free
> with vm_object locked and doesn't respect vm_ma
2010/1/13 Gardner Bell :
> I got this lock order reversal while running a windows executable through
> wine.
I'm guess that is a regression w.r.t S/G pager, which uses kmem_alloc/free
with vm_object locked and doesn't respect vm_map locks can sleep.
I'm curious it was back order before 5.1-R.
vm_
I got this lock order reversal while running a windows executable
through wine.
lock order reversal:
1st 0xc5e757f8 vm object (standard object) @
/usr/src/sys/vm/vm_object.c:482
2nd 0xc1c900e8 system map (system map) @ /usr/src/sys/vm/vm_map.c:2772
KDB: stack backtrace:
db_trace_self_wrapper
Just found a new LOR on 8-STABLE/amd64 from 30-Nov. It's possible that
it was associated with 'vmstat -m'. Reported as kern/142489
lock order reversal:
1st 0x807417c0 allproc (allproc) @ /usr/src/sys/vm/vm_meter.c:130
2nd 0xff002c263ba8 zfs (zfs) @ /usr/src/sys/
The system has two disks, one of them just a root partition and the
other one has two filesystems, one for /usr/src and the other for /usr/
obj
How to reproduce?
Right after boot, I have mounted /usr/src and /usr/obj.
Unmounting /usr/obj has given this LOR.
I can reproduce it easily, ple
A lot of these LORs were fixed in cxgb in FreeBSD 8. You can look at
cxgb_main.c in 8 for details. I'll also try and figure out if those
changes are easily MFC'able.
Regards,
Navdeep
On Mon, Sep 14, 2009 at 2:29 PM, Matthew Fleming
wrote:
> We got a cxgb LOR repor
We got a cxgb LOR report of:
1st 0xff8001e37be0 vlan_global (vlan_global) @
/build/mnt/src/sys/modules/if_vlan/../../net/if_vlan.c:1310
2nd 0xff80010892f0 cxgb port lock (cxgb port lock) @
/build/mnt/src/sys/modules/cxgb/../../dev/cxgb/cxgb_main.c:1956
KDB: stack backtrace
Hi,
in case you find a LOR, want to report it or want to see if it's known
or find out more about it... you can go and check "The LOR page"
again. It's up on a temporary setup (so in case it's not avail come
back a bit later) until I can finally move the web elsewher
2009/2/12 pluknet :
> Hello.
>
> I'm just curious if ufs_vnops.c#rev1.290 fixes this LOR (or not):
I found it was discussed already. Sorry for noise.
--
wbr,
pluknet
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/ma
Hello.
I'm just curious if ufs_vnops.c#rev1.290 fixes this LOR (or not):
lock order reversal:
1st 0xcc9d1b00 kqueue (kqueue) @
/usr/src/sys_uvmem_uip.6.2_RELEASE/kern/kern_event.c:1547
2nd 0xc6d6b854 struct mount mtx (struct mount mtx) @
/usr/src/sys_uvmem_uip.6.2_RELEASE/ufs/ufs/ufs_vn
rsal; I'd be
> >> interested in knowing if it also corrects the stability issue. This was
> >> r183753 in svn; I'm not sure it's hit CVS/cvsup yet but should do in a few
> >> minutes.
> >
> > Dear Vlad:
> >
> > Cou
n; I'm not sure it's hit CVS/cvsup yet but should do in a few
>> minutes.
>
> Dear Vlad:
>
> Could you confirm that with udp_usrreq.c:1.218.2.7 (or newer), the problem
> has gone away? CVS log excerpt below.
Hello Robert & all,
Yes, the LOR seems to have g
On Fri, 10 Oct 2008, Robert Watson wrote:
On Fri, 10 Oct 2008, Jeremy Chadwick wrote:
I'll see whether the system still locks up or not though..
Okay, I'm bringing rwatson@ into the thread since this is specific to UDP.
I've now fixed the bug leading to the lock order reversal; I'd be i
On Fri, 10 Oct 2008, Jeremy Chadwick wrote:
I'll see whether the system still locks up or not though..
Okay, I'm bringing rwatson@ into the thread since this is specific to UDP.
I've now fixed the bug leading to the lock order reversal; I'd be interested
in knowing if it also corrects th
d udp_init(), and this LOR is a side effect of that bug.
I'll see about creating a patch this evening.
Robert N M Watson
Computer Laboratory
University of Cambridge
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/l
On Fri, Oct 10, 2008 at 06:24:59PM +0300, Vlad GALU wrote:
> On Fri, Oct 10, 2008 at 6:21 PM, Jeremy Chadwick <[EMAIL PROTECTED]> wrote:
> > On Fri, Oct 10, 2008 at 06:11:25PM +0300, Vlad GALU wrote:
> >> On Fri, Oct 10, 2008 at 5:57 PM, Mike Tancsa <[EMAIL PROTECTED]> wrote:
> >> > At 08:40 AM 10/
On Fri, Oct 10, 2008 at 6:21 PM, Jeremy Chadwick <[EMAIL PROTECTED]> wrote:
> On Fri, Oct 10, 2008 at 06:11:25PM +0300, Vlad GALU wrote:
>> On Fri, Oct 10, 2008 at 5:57 PM, Mike Tancsa <[EMAIL PROTECTED]> wrote:
>> > At 08:40 AM 10/10/2008, Vlad GALU wrote:
>> >>
>> >> As my kernel had started to
On Fri, Oct 10, 2008 at 06:11:25PM +0300, Vlad GALU wrote:
> On Fri, Oct 10, 2008 at 5:57 PM, Mike Tancsa <[EMAIL PROTECTED]> wrote:
> > At 08:40 AM 10/10/2008, Vlad GALU wrote:
> >>
> >> As my kernel had started to lock up periodically and I don't have
> >> hands-on access to that machine, I ena
On Fri, Oct 10, 2008 at 5:57 PM, Mike Tancsa <[EMAIL PROTECTED]> wrote:
> At 08:40 AM 10/10/2008, Vlad GALU wrote:
>>
>> As my kernel had started to lock up periodically and I don't have
>> hands-on access to that machine, I enabled WITNESS.
>> So these started to pop up:
>
> Is this with a stock
At 08:40 AM 10/10/2008, Vlad GALU wrote:
As my kernel had started to lock up periodically and I don't have
hands-on access to that machine, I enabled WITNESS.
So these started to pop up:
Is this with a stock kernel and sysctl settings ? Or do you have any
custom kernel options ?
On Fri, Oct 10, 2008 at 5:42 PM, Jeremy Chadwick <[EMAIL PROTECTED]> wrote:
> On Fri, Oct 10, 2008 at 03:40:26PM +0300, Vlad GALU wrote:
>>As my kernel had started to lock up periodically and I don't have
>> hands-on access to that machine, I enabled WITNESS.
>> So these started to pop up:
>>
>
On Fri, Oct 10, 2008 at 03:40:26PM +0300, Vlad GALU wrote:
>As my kernel had started to lock up periodically and I don't have
> hands-on access to that machine, I enabled WITNESS.
> So these started to pop up:
>
> -- cut here --
> --- syscall (97, FreeBSD ELF64, socket), rip = 0x80070427c, rsp
As my kernel had started to lock up periodically and I don't have
hands-on access to that machine, I enabled WITNESS.
So these started to pop up:
-- cut here --
--- syscall (97, FreeBSD ELF64, socket), rip = 0x80070427c, rsp =
0x7fffe8c8, rbp = 0x516348 ---
uma_zalloc_arg: zone "16" with th
Hi!
Last week I discovered an LOR on 7-STABLE (last build: 2008-Aug-17,
RELENG_7).
I can easily recreate the problem when running a synproxy state rule for
incoming tcp connections and ssh'ing to my box.
W/o using synproxy state (keep'ing state instead), no LOR takes place.
On Friday 09 May 2008 10:53:15 pm Aristedes Maniatis wrote:
>
> On 23/04/2008, at 3:34 AM, John Baldwin wrote:
>
> >>> The
> >>> real problem at the bottom of the screen though is a real issue.
> >>> It's a LOR
> >>> of t
On 23/04/2008, at 3:34 AM, John Baldwin wrote:
The
real problem at the bottom of the screen though is a real issue.
It's a LOR
of two different sleepqueue chain locks. The problem is that when
setrunnable() encounters a swapped out thread it tries to wakeup
proc0, but
if proc0 is a
On Saturday 19 April 2008 07:38:27 am Aristedes Maniatis wrote:
>
> On 19/04/2008, at 3:14 AM, John Baldwin wrote:
> > On Thursday 10 April 2008 06:33:40 pm Aristedes Maniatis wrote:
> >>
> >>>> http://www.ish.com.au/s/LOR/1.jpg
> >>>
On 19/04/2008, at 3:14 AM, John Baldwin wrote:
On Thursday 10 April 2008 06:33:40 pm Aristedes Maniatis wrote:
http://www.ish.com.au/s/LOR/1.jpg
http://www.ish.com.au/s/LOR/2.jpg
http://www.ish.com.au/s/LOR/3.jpg (this overlaps with [2])
These are all garbage in kuickshow. :(
They work
On Thursday 10 April 2008 06:33:40 pm Aristedes Maniatis wrote:
>
> >> http://www.ish.com.au/s/LOR/1.jpg
> >> http://www.ish.com.au/s/LOR/2.jpg
> >> http://www.ish.com.au/s/LOR/3.jpg (this overlaps with [2])
> >
> > These are all garbage in kuickshow. :(
On 08/04/2008, at 6:06 PM, Aristedes Maniatis wrote:
LOR:
1st 0x807d3d90 sleepq chain (sleepq chain) @/usr/src/sys/kern/
subr_sleepqueue.c:773
2nd 0x807c8110 scrlock (scrlock) @/usr/src/sys/dev/syscons/syscons.c:
2526
Is there anything I can do at my end to assist in the debugging of
this
http://www.ish.com.au/s/LOR/1.jpg
http://www.ish.com.au/s/LOR/2.jpg
http://www.ish.com.au/s/LOR/3.jpg (this overlaps with [2])
These are all garbage in kuickshow. :(
They work fine for me in Firefox. But don't know what sort of jpegs
the Sony camera saves. Anyhow I've also n
bugging kernel (without INVARIANTS since that
> >> prevented the kernel from compiling at all) and obtained this LOR
> >> when
> >> it froze:
> >>
> >> LOR:
> >> 1st 0x807d3d90 sleepq chain (sleepq chain) @/usr/src/sys/kern/
> >> subr_sleepque
night not doing anything, everything locks up
including the console.
We then installed a debugging kernel (without INVARIANTS since that
prevented the kernel from compiling at all) and obtained this LOR
when
it froze:
LOR:
1st 0x807d3d90 sleepq chain (sleepq chain) @/usr/src/sys/kern/
subr_sleepqu
ng, everything locks up
> including the console.
>
> We then installed a debugging kernel (without INVARIANTS since that
> prevented the kernel from compiling at all) and obtained this LOR when
> it froze:
>
> LOR:
> 1st 0x807d3d90 sleepq chain (sleepq chain) @/usr/src/sys/kern/
&
thout INVARIANTS since that
prevented the kernel from compiling at all) and obtained this LOR when
it froze:
LOR:
1st 0x807d3d90 sleepq chain (sleepq chain) @/usr/src/sys/kern/
subr_sleepqueue.c:773
2nd 0x807c8110 scrlock (scrlock) @/usr/src/sys/dev/syscons/syscons.c:
2526
I have
On Thu, Oct 25, 2007 at 03:37:32PM +0400, pluknet wrote:
> Hi all.
>
> I am getting the following LOR on my 7.0-BETA1:
>
> lock order reversal: (sleepable after non-sleepable)
> 1st 0xc3c904d8 drm device (drm device) @
> /media/src/sys/modules/drm/drm/../../..
> /dev
On 25/10/2007, Kostik Belousov <[EMAIL PROTECTED]> wrote:
>
> The folowing patch should fix it. I tried to get review by Eric, but failed.
>
Thanks. It works for me.
For test case I use gnash playing adv flash banners.
wbr,
pluknet
___
freebsd-stable@fr
Hi all.
I am getting the following LOR on my 7.0-BETA1:
lock order reversal: (sleepable after non-sleepable)
1st 0xc3c904d8 drm device (drm device) @ /media/src/sys/modules/drm/drm/../../..
/dev/drm/drm_drv.c:907
2nd 0xc4135a3c user map (user map) @ vm/vm_glue.c:183
KDB: stack backtrace
On Sat, Sep 08, 2007 at 12:58:24AM -0700, Maxim Sobolev wrote:
> Kostik Belousov wrote:
> >On Fri, Sep 07, 2007 at 11:49:50AM -0700, Maxim Sobolev wrote:
> >>Hi,
> >>
> >>On my 6.2 system I am seeing LOR discussed almost 1 year ago here:
> >>
> >
Kostik Belousov wrote:
On Fri, Sep 07, 2007 at 11:49:50AM -0700, Maxim Sobolev wrote:
Hi,
On my 6.2 system I am seeing LOR discussed almost 1 year ago here:
http://lists.freebsd.org/pipermail/freebsd-stable/2006-November/031048.html
http://lists.freebsd.org/pipermail/freebsd-stable/2006
On Fri, Sep 07, 2007 at 11:49:50AM -0700, Maxim Sobolev wrote:
> Hi,
>
> On my 6.2 system I am seeing LOR discussed almost 1 year ago here:
>
> http://lists.freebsd.org/pipermail/freebsd-stable/2006-November/031048.html
> http://lists.freebsd.org/pipermail/freebsd-stable/20
Hi,
On my 6.2 system I am seeing LOR discussed almost 1 year ago here:
http://lists.freebsd.org/pipermail/freebsd-stable/2006-November/031048.html
http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/031197.html
lock order reversal:
1st 0xc52cb500 kqueue (kqueue) @ kern
which I had been using without
> problems until now.
...
> I had not set up dumpdev & large enough dumpdir at the time of
> above crap-shoot. I will update when I LOR happens again.
Ok, now that dumpd{ev,ir} have been set up, vmcore is available if
somebody serious wants to look; backtr
uration is ...
device.hints:
http://www103.pair.com/parv/comp/unix/freebsd/thinkpad-t42-2373-5tu/err/2007-04-19.ath-lor/boot.device.hints
loader.conf:
http://www103.pair.com/parv/comp/unix/freebsd/thinkpad-t42-2373-5tu/err/2007-04-19.ath-lor/boot.loader.conf
kernel (debug):
http://www103.pai
Kostik Belousov wrote:
In a previous (quite old) thread it was in fact suggested I might be
seeing some LOR, but only recently I activated all the debugging stuff.
The (usual) consequence of the LOR is lock up.
Mhh, yes, that's right. But I stopped having locks during file s
On Tue, Mar 06, 2007 at 10:44:37PM +0100, Andrea Venturoli wrote:
> Hello.
>
> I'm experiencing the above mentioned LOR on a 6.2p1/amd64 box (running
> gmirror and SMP if that matters).
>
> With reference to your question on
> http://lists.freebsd.org/pipermail/fr
Hello.
I'm experiencing the above mentioned LOR on a 6.2p1/amd64 box (running
gmirror and SMP if that matters).
With reference to your question on
http://lists.freebsd.org/pipermail/freebsd-stable/2006-November/031048.html:
What application you run that triggers the LOR ?
Bacu
0xc3dea090 inp (divinp) @
netinet/ip_divert.c:354
Feb 3 12:48:49 xor kernel: 2nd 0xc0892700 in_multi_mtx (in_multi_mtx) @
netinet/ip_output.c:306
I added this one with LOR ID 202 to the LOR page:
http://sources.zabbadoz.net/freebsd/lor.html#202
--
Bjoern A. Zeeb
On Sun, 28 Jan 2007, Peter Losher wrote:
lock order reversal:
1st 0xff00b79c3cc8 inp (raw6inp) @
/usr/src/sys/netinet6/raw_ip6.c:153
2nd 0xff00b79c3df8 inp (rawinp) @ /usr/src/sys/netinet6/raw_ip6.c:153
added with LOR ID 201 to the LOR page:
http://sources.zabbadoz.net
On Thu, Feb 08, 2007 at 09:49:23PM +0100, Frode Nordahl wrote:
> On 27. nov. 2006, at 10.21, Kostik Belousov wrote:
>
> >On Sun, Nov 26, 2006 at 09:30:39AM +0100, V??clav Haisman wrote:
> >>Hi,
> >>the attached lor.txt contains LOR I got this yesterday. It is
>
On 27. nov. 2006, at 10.21, Kostik Belousov wrote:
On Sun, Nov 26, 2006 at 09:30:39AM +0100, V??clav Haisman wrote:
Hi,
the attached lor.txt contains LOR I got this yesterday. It is
FreeBSD 6.1
with relatively recent kernel, from last week or so.
--
VH
+lock order reversal:
+ 1st
I get the following lock order reversals at boot on this 6.2 system.
Feb 3 14:47:28 xor kernel: lock order reversal:
Feb 3 14:47:28 xor kernel: 1st 0xc08422a0 cdev (cdev) @ kern/kern_conf.c:61
Feb 3 14:47:28 xor kernel: 2nd 0xc3a4510c sleep mtxpool (sleep mtxpool) @
kern/kern_prot.c:1877
Feb
FYI: saw this when upgrading one of my boxes (quad-cpu Opteron, 2GB of
RAM) to 6.2-RELEASE:
> Firewall logging enabled
> net.inet.ip.fw.enable: 1 -> 1
> lock order reversal:
> 1st 0xff00b79c3cc8 inp (raw6inp) @
/usr/src/sys/netinet6/raw_ip6.c:153
> 2nd 0xff00b79c3df8 inp (rawinp) @ /usr/
On Tuesday 12 December 2006 21:48, Bruce Evans wrote:
> > Memory barriers just specify ordering, they don't ensure a cache flush so
> > another CPU reads up to date values. You can use memory barriers in
> > conjunction with atomic operations on a variable to ensure that you can
> > safely read ot
On Wed, Dec 13, 2006 at 04:12:57AM +, Tor Egge wrote:
> > Hmm, may be, since vnode must be interlocked by ffs_sync() after
> > MNTK_SUSPENDED set, and before MNTK_SUSPEND, mount interlock is not
> > needed in ufs_itimes.
> >
> > Tor ?
> If neither IN_CHANGE nor IN_UPDATE is set then it might
> Hmm, may be, since vnode must be interlocked by ffs_sync() after
> MNTK_SUSPENDED set, and before MNTK_SUSPEND, mount interlock is not
> needed in ufs_itimes.
>
> Tor ?
If neither IN_CHANGE nor IN_UPDATE is set then it might be unsafe to set
IN_MODIFIED in ufs_itimes() since the file system mig
On Tue, 12 Dec 2006, John Baldwin wrote:
On Tuesday 12 December 2006 13:43, Suleiman Souhlal wrote:
Why is memory barrier usage not encouraged? As you said, they can be used to
reduce the number of atomic (LOCKed) operations, in some cases.
...
Admittedly, they are harder to use than atomic o
gt; >On Sun, Nov 26, 2006 at 09:30:39AM +0100, V??clav Haisman wrote:
> >> > >
> >> > >>Hi,
> >> > >>the attached lor.txt contains LOR I got this yesterday. It is
> >> FreeBSD 6.1
> >> > >>with relatively recent ker
06 at 09:30:39AM +0100, V??clav Haisman wrote:
>> > >
>> > >>Hi,
>> > >>the attached lor.txt contains LOR I got this yesterday. It is
>> FreeBSD 6.1
>> > >>with relatively recent kernel, from last week or so.
>> > >>
&g
Attilio Rao wrote:
2006/12/12, Kostik Belousov <[EMAIL PROTECTED]>:
On Tue, Dec 12, 2006 at 12:44:54AM -0800, Suleiman Souhlal wrote:
> Kostik Belousov wrote:
> >On Sun, Nov 26, 2006 at 09:30:39AM +0100, V??clav Haisman wrote:
> >
> >>Hi,
> >>the a
2006/12/12, Kostik Belousov <[EMAIL PROTECTED]>:
On Tue, Dec 12, 2006 at 12:44:54AM -0800, Suleiman Souhlal wrote:
> Kostik Belousov wrote:
> >On Sun, Nov 26, 2006 at 09:30:39AM +0100, V??clav Haisman wrote:
> >
> >>Hi,
> >>the attached lor.txt contains
s here (inefficient)
> call
> acquire mount interlock
> acquire vnode interlock
> test the flags; goto cleanup code if none set (usual case)
> do the work
> release vnode interlock
> release mount interlock
> return
>
f needed)
and it might become:
acquire vnode interlock in caller
call
test the flags; return if none set (usual case)
release vnode interlock // check that callers are aware of this
acquire mount interlock
acquire vnode interlock
do the work
On Tue, Dec 12, 2006 at 12:44:54AM -0800, Suleiman Souhlal wrote:
> Kostik Belousov wrote:
> >On Sun, Nov 26, 2006 at 09:30:39AM +0100, V??clav Haisman wrote:
> >
> >>Hi,
> >>the attached lor.txt contains LOR I got this yesterday. It is FreeBSD 6.1
> >>wit
Kostik Belousov wrote:
On Sun, Nov 26, 2006 at 09:30:39AM +0100, V??clav Haisman wrote:
Hi,
the attached lor.txt contains LOR I got this yesterday. It is FreeBSD 6.1
with relatively recent kernel, from last week or so.
--
VH
+lock order reversal:
+ 1st 0xc537f300 kqueue (kqueue) @ /usr
On Sun, 3 Dec 2006, Kostik Belousov wrote:
Please, try the patch
http://people.freebsd.org/~kib/kqueue-lor.1.patch
I had to manually apply the vnode_if.src portion. All the other
hunks applied to a today cvsup from RELENG_6.
Waiting for the compile to finish.
LER
--
Larry Rosenman
= 0x7fffffffdd08, rbp = 0x1e ---
Please, try the patch
http://people.freebsd.org/~kib/kqueue-lor.1.patch
pgppERiL5gxF7.pgp
Description: PGP signature
On Sun, 3 Dec 2006, Larry Rosenman wrote:
This may already be fixed, known, but...
yes it is known; see "The LOR page":
http://sources.zabbadoz.net/freebsd/lor.html#193
Dec 3 13:14:41 thebighonker kernel: lock order reversal:
Dec 3 13:14:41 thebighonker k
1 - 100 of 154 matches
Mail list logo
