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
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 to print panic
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 usable]
___
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 ufs/ffs
On Thu, Mar 09, 2017 at 07:01:07AM +0100, Gergely Czuczy wrote:
>
>
> 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 you
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't aware
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't aware of this page. It turns out it's
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 this one is any co
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 letting
you know.
Hi,
You
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 11
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 11.0-CURRENT FreeBSD 11.0-CURREN
> 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
> 2nd bufwait (bufwait) @ /usr/src/sys
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
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
> 21:28:26 PST 2015 ro
On 12/13/14 11:26, Konstantin Belousov wrote:
> On Sat, Dec 13, 2014 at 01:13:04AM +0100, Guido Falsi wrote:
>> On 12/10/14 09:58, Guido Falsi wrote:
>>> On 12/10/14 09:52, Konstantin Belousov wrote:
On Tue, Dec 09, 2014 at 11:39:57PM +0100, Guido Falsi wrote:
>> [...]
> --- trap 0xc,
On Sat, Dec 13, 2014 at 01:13:04AM +0100, Guido Falsi wrote:
> On 12/10/14 09:58, Guido Falsi wrote:
> > On 12/10/14 09:52, Konstantin Belousov wrote:
> >> On Tue, Dec 09, 2014 at 11:39:57PM +0100, Guido Falsi wrote:
> >>
> [...]
> >>> --- trap 0xc, tip = 0x8056834d, rsp = 0xfe022ed8f6b
On 12/10/14 09:58, Guido Falsi wrote:
> On 12/10/14 09:52, Konstantin Belousov wrote:
>> On Tue, Dec 09, 2014 at 11:39:57PM +0100, Guido Falsi wrote:
>>
[...]
>>> --- trap 0xc, tip = 0x8056834d, rsp = 0xfe022ed8f6b0, rbp =
>>> 0xfe022ed8f6e0 ---
>>> sbappendstream_locked() at sbappe
On 12/10/14 09:52, Konstantin Belousov wrote:
> On Tue, Dec 09, 2014 at 11:39:57PM +0100, Guido Falsi wrote:
>
>>
>> Lock order reversal: (sleepable after non-sleepable)
>> 1st 0xf8000874da90 so_snd (so_snd) @
>> /usr/src/sys/kern/uipc_sockbuf.c:666
>> 2nd 0xf80057ff20a0 drmslk (drmslk)
On Tue, Dec 09, 2014 at 11:39:57PM +0100, Guido Falsi wrote:
> Hi,
>
> I've experienced a hard lockup on head r275563, amd64.
>
> The hardware is a laptop with an intel graphics card.
>
> If any further info is required just ask.
>
> I had just launched a virtualbox VM with Windows 7, the syst
2014-12-09 23:39 GMT+01:00 Guido Falsi :
> Hi,
>
> I've experienced a hard lockup on head r275563, amd64.
>
> The hardware is a laptop with an intel graphics card.
>
> If any further info is required just ask.
>
> I had just launched a virtualbox VM with Windows 7, the system locked up
> just aft
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 0xfe00f7626b48 bufwait (bufwait) @
> > /usr/src/sys
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 (dirhash) @
This one is a ve
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: 2
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 noise ...
On Mon, Aug 5, 2013 at 4:24 PM, Sam Fourman Jr. wrote:
> 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 per
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
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
>
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
> 2nd 0xc3d08604 if_afdata (if_a
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 HEAD. This is a bug. They make
witnes
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.freebsd.org/m
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) @
/
On Friday, August 20, 2010 3:42:27 pm Kostik Belousov wrote:
> 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 equivale
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 safe, because the task is
On Friday, August 20, 2010 3:19:53 pm Kostik Belousov wrote:
> On Fri, Aug 20, 2010 at 08:55:08PM +0400, pluknet wrote:
> > 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 Wed
On Fri, Aug 20, 2010 at 08:55:08PM +0400, pluknet wrote:
> 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
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
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 the John' suggestion to use the taskqueue.
>> >
>
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 the John' suggestion to use the taskqueue.
> >
> > I decided to go this road. Thank you both.
> > Now I d
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 results.
>
So, I mo
On 17 August 2010 20:04, Kostik Belousov wrote:
> On Tue, Aug 17, 2010 at 07:42:41PM +0400, pluknet wrote:
>> 2010/8/16 Kostik Belousov :
>> > On Mon, Aug 16, 2010 at 09:07:24PM +0400, pluknet wrote:
>> >> On 16 August 2010 21:05, pluknet wrote:
>> >> > Hi.
>> >> >
>> >> > Seeing on mostly idle,
On Tue, Aug 17, 2010 at 4:04 PM, Kostik Belousov wrote:
> On Tue, Aug 17, 2010 at 07:42:41PM +0400, pluknet wrote:
>> 2010/8/16 Kostik Belousov :
>> > On Mon, Aug 16, 2010 at 09:07:24PM +0400, pluknet wrote:
>> >> On 16 August 2010 21:05, pluknet wrote:
>> >> > Hi.
>> >> >
>> >> > Seeing on mostl
On Tue, Aug 17, 2010 at 07:42:41PM +0400, pluknet wrote:
> 2010/8/16 Kostik Belousov :
> > On Mon, Aug 16, 2010 at 09:07:24PM +0400, pluknet wrote:
> >> On 16 August 2010 21:05, pluknet wrote:
> >> > Hi.
> >> >
> >> > Seeing on mostly idle, recently updated current, while closing a file.
> >> > Pr
2010/8/16 Kostik Belousov :
> On Mon, Aug 16, 2010 at 09:07:24PM +0400, pluknet wrote:
>> On 16 August 2010 21:05, pluknet wrote:
>> > Hi.
>> >
>> > Seeing on mostly idle, recently updated current, while closing a file.
>> > Presumably never reported on ML.
[...]
>>
> Both LORs are valid. The fork
On Monday, August 16, 2010 2:54:56 pm Kostik Belousov wrote:
> On Mon, Aug 16, 2010 at 09:07:24PM +0400, pluknet wrote:
> > On 16 August 2010 21:05, pluknet wrote:
> > > Hi.
> > >
> > > Seeing on mostly idle, recently updated current, while closing a file.
> > > Presumably never reported on ML.
>
On Mon, Aug 16, 2010 at 09:07:24PM +0400, pluknet wrote:
> On 16 August 2010 21:05, pluknet wrote:
> > Hi.
> >
> > Seeing on mostly idle, recently updated current, while closing a file.
> > Presumably never reported on ML.
> >
> > lock order reversal:
> > 1st 0xff00198199f8 nfs (nfs) @ /usr/s
On 16 August 2010 21:05, pluknet wrote:
> Hi.
>
> Seeing on mostly idle, recently updated current, while closing a file.
> Presumably never reported on ML.
>
> lock order reversal:
> 1st 0xff00198199f8 nfs (nfs) @ /usr/src/sys/kern/vfs_vnops.c:301
> 2nd 0xff000234a048 filedesc structure
On Fri, 21 May 2010, Erik Cederstrand wrote:
Den 12/05/2010 kl. 22.44 skrev Jeff Roberson:
I think Peter Holm also saw this once while we were testing SUJ and reproduced
~30 second hangs with stock sources. At this point we need to brainstorm ideas
for adding debugging instrumentation and
Den 12/05/2010 kl. 22.44 skrev Jeff Roberson:
>
> I think Peter Holm also saw this once while we were testing SUJ and
> reproduced ~30 second hangs with stock sources. At this point we need to
> brainstorm ideas for adding debugging instrumentation and come up with the
> quickest possible rep
2010/5/12 Jeff Roberson :
> On Wed, 12 May 2010, Ulrich Sp?rlein wrote:
>
>> On Mon, 10.05.2010 at 22:53:32 +0200, Attilio Rao wrote:
>>>
>>> 2010/5/10 Peter Jeremy :
On 2010-May-08 12:20:05 +0200, Ulrich Sp?rlein
wrote:
>
> This LOR also is not yet listed on the LOR page, s
On Wed, 12 May 2010, Ulrich Sp?rlein wrote:
On Mon, 10.05.2010 at 22:53:32 +0200, Attilio Rao wrote:
2010/5/10 Peter Jeremy :
On 2010-May-08 12:20:05 +0200, Ulrich Sp?rlein wrote:
This LOR also is not yet listed on the LOR page, so I guess it's rather
new. I do use SUJ.
lock order reversal:
On Mon, 10.05.2010 at 22:53:32 +0200, Attilio Rao wrote:
> 2010/5/10 Peter Jeremy :
> > On 2010-May-08 12:20:05 +0200, Ulrich Spörlein wrote:
> >>This LOR also is not yet listed on the LOR page, so I guess it's rather
> >>new. I do use SUJ.
> >>
> >>lock order reversal:
> >> 1st 0xc48388d8 ufs (uf
2010/5/10 Peter Jeremy :
> On 2010-May-08 12:20:05 +0200, Ulrich Spörlein wrote:
>>This LOR also is not yet listed on the LOR page, so I guess it's rather
>>new. I do use SUJ.
>>
>>lock order reversal:
>> 1st 0xc48388d8 ufs (ufs) @ /usr/src/sys/kern/vfs_lookup.c:502
>> 2nd 0xec0fe304 bufwait (bufw
On 2010-May-08 12:20:05 +0200, Ulrich Spörlein wrote:
>This LOR also is not yet listed on the LOR page, so I guess it's rather
>new. I do use SUJ.
>
>lock order reversal:
> 1st 0xc48388d8 ufs (ufs) @ /usr/src/sys/kern/vfs_lookup.c:502
> 2nd 0xec0fe304 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_s
2010/5/9 Jeff Roberson :
> On Sat, 8 May 2010, Ulrich Sp?rlein wrote:
>
>> On Sat, 08.05.2010 at 18:00:50 +0200, Attilio Rao wrote:
>>>
>>> 2010/5/8 Ulrich Sp?rlein :
On Sat, 08.05.2010 at 12:20:05 +0200, Ulrich Sp?rlein wrote:
>
> This LOR also is not yet listed on the LOR page,
On Sat, 8 May 2010, Ulrich Sp?rlein wrote:
On Sat, 08.05.2010 at 18:00:50 +0200, Attilio Rao wrote:
2010/5/8 Ulrich Sp?rlein :
On Sat, 08.05.2010 at 12:20:05 +0200, Ulrich Sp?rlein wrote:
This LOR also is not yet listed on the LOR page, so I guess it's rather
new. I do use SUJ.
lock order re
2010/5/8 Ulrich Spörlein :
> On Sat, 08.05.2010 at 18:00:50 +0200, Attilio Rao wrote:
>> 2010/5/8 Ulrich Spörlein :
>> > On Sat, 08.05.2010 at 12:20:05 +0200, Ulrich Spörlein wrote:
>> >> This LOR also is not yet listed on the LOR page, so I guess it's rather
>> >> new. I do use SUJ.
>> >>
>> >> lo
On Sat, 08.05.2010 at 18:00:50 +0200, Attilio Rao wrote:
> 2010/5/8 Ulrich Spörlein :
> > On Sat, 08.05.2010 at 12:20:05 +0200, Ulrich Spörlein wrote:
> >> This LOR also is not yet listed on the LOR page, so I guess it's rather
> >> new. I do use SUJ.
> >>
> >> lock order reversal:
> >> 1st 0xc483
On Sat, 08.05.2010 at 12:20:05 +0200, Ulrich Spörlein wrote:
> This LOR also is not yet listed on the LOR page, so I guess it's rather
> new. I do use SUJ.
>
> lock order reversal:
> 1st 0xc48388d8 ufs (ufs) @ /usr/src/sys/kern/vfs_lookup.c:502
> 2nd 0xec0fe304 bufwait (bufwait) @ /usr/src/sys/u
On Monday 12 April 2010 12:26:06 pm Jack Vogel wrote:
> On Mon, Apr 12, 2010 at 7:52 AM, John Baldwin wrote:
>
> > On Friday 09 April 2010 3:09:24 pm Jack Vogel wrote:
> > > Someone else also pointed this out. I'm dubious about its claim.
> > > This happens because there is an RX lock taken in rx
On Mon, Apr 12, 2010 at 7:52 AM, John Baldwin wrote:
> On Friday 09 April 2010 3:09:24 pm Jack Vogel wrote:
> > Someone else also pointed this out. I'm dubious about its claim.
> > This happens because there is an RX lock taken in rxeof, its held
> > thru the call into the stack, it then encounte
On Friday 09 April 2010 3:09:24 pm Jack Vogel wrote:
> Someone else also pointed this out. I'm dubious about its claim.
> This happens because there is an RX lock taken in rxeof, its held
> thru the call into the stack, it then encounters another lock there
> and hence this complaint. I've had the
What's disabled is the drbr stuff in the stack, that will not keep the 82574
from
initializing MSIX and multiple internal queues, if you have that adapter I
would
suggest you #define EM_MULTIQUEUE somewhere (Makefile, if_em.h or if_em.c)
since I believe its the one place where you will benefit. At
At 03:29 PM 4/10/2010, Jack Vogel wrote:
Added the missing locks around calls to rxeof and checked it in a minute ago.
Sorry guys!
Looks good for me now. BTW, I thought the multi-queue was supposed
to be disabled on the em nic ?
em0: port 0x3040-0x305f
mem 0xc1b0-0xc1b1,0xc1b250
Added the missing locks around calls to rxeof and checked it in a minute
ago.
Sorry guys!
Jack
On Sat, Apr 10, 2010 at 9:05 AM, Bjoern A. Zeeb <
bzeeb-li...@lists.zabbadoz.net> wrote:
> On Sat, 10 Apr 2010, Mike Tancsa wrote:
>
> Hi Mike,
>
>
> At 05:11 PM 4/9/2010, Jack Vogel wrote:
>>
>>> D
On Sat, 10 Apr 2010, Mike Tancsa wrote:
Hi Mike,
At 05:11 PM 4/9/2010, Jack Vogel wrote:
Don't know, but I would just ignore it, I think its a false warning anyway.
OK. I updated to HEAD as of this AM, but now I get a panic at bootup
...
Trying to mount root from nfs:
NFS ROOT: 10.255.25
At 05:11 PM 4/9/2010, Jack Vogel wrote:
Don't know, but I would just ignore it, I think its a false warning anyway.
OK. I updated to HEAD as of this AM, but now I get a panic at bootup
odule pci/rl failed to register: 17
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Core(TM
Don't know, but I would just ignore it, I think its a false warning anyway.
Jack
On Fri, Apr 9, 2010 at 2:05 PM, Mike Tancsa wrote:
> At 04:13 PM 4/9/2010, Pyun YongHyeon wrote:
>
>> On Fri, Apr 09, 2010 at 12:09:24PM -0700, Jack Vogel wrote:
>> > Someone else also pointed this out. I'm dubiou
At 04:13 PM 4/9/2010, Pyun YongHyeon wrote:
On Fri, Apr 09, 2010 at 12:09:24PM -0700, Jack Vogel wrote:
> Someone else also pointed this out. I'm dubious about its claim.
I can't reproduce the LOR with latest em(4)(r206429).
I still get it for some reason
1st 0xc5dc7610 em1:rx(1) (em1:rx(1)
On Fri, Apr 9, 2010 at 1:13 PM, Pyun YongHyeon wrote:
> On Fri, Apr 09, 2010 at 12:09:24PM -0700, Jack Vogel wrote:
> > Someone else also pointed this out. I'm dubious about its claim.
>
> I can't reproduce the LOR with latest em(4)(r206429).
>
>
Hmmm, wonder what changed that effected that, oh w
On Fri, Apr 09, 2010 at 12:09:24PM -0700, Jack Vogel wrote:
> Someone else also pointed this out. I'm dubious about its claim.
I can't reproduce the LOR with latest em(4)(r206429).
> This happens because there is an RX lock taken in rxeof, its held
> thru the call into the stack, it then encounte
Someone else also pointed this out. I'm dubious about its claim.
This happens because there is an RX lock taken in rxeof, its held
thru the call into the stack, it then encounters another lock there
and hence this complaint. I've had the RX hold as it is for a long
while and would rather not have t
On Sun, Nov 30, 2003 at 07:23:42AM +1100, Peter Jeremy wrote:
> On Thu, Nov 27, 2003 at 03:38:59PM -0800, Kris Kennaway wrote:
> >On Fri, Nov 28, 2003 at 12:27:53AM +0100, Artur Poplawski wrote:
> >
> >> > lock order reversal
> >> > 1st 0xc43d8ad4 vm object (vm object) @ /usr/src/sys/vm/swap_pager
On Thu, Nov 27, 2003 at 03:38:59PM -0800, Kris Kennaway wrote:
>On Fri, Nov 28, 2003 at 12:27:53AM +0100, Artur Poplawski wrote:
>
>> > lock order reversal
>> > 1st 0xc43d8ad4 vm object (vm object) @ /usr/src/sys/vm/swap_pager.c:1323
>> > 2nd 0xc098cf60 swap_pager swhash (swap_pager swhash) @ /us
On Fri, Nov 28, 2003 at 03:25:02PM +0100, Ruben de Groot wrote:
>
> This is on a machine running 5.2-BETA, compiled with last night's
> sources
Both problems are known and have been reported a number of times..the
second one should be fixed now.
Kris
pgp0.pgp
Description: PGP signature
On Fri, 28 Nov 2003, Ruben de Groot wrote:
> This is on a machine running 5.2-BETA, compiled with last night's
> sources
...
> Also, a repeatable panic when I run tcpdump on a gif interface.
> Without tcpdump, the tunnel is working as expected, but when tcpdump
> is listening on the gif0 interface
Hi,
> After seeing this commit message, I've upgraded -CURRENT installed on
> NetFinity 6000R(with ServeRAID 4H) to catch up with the recent changes.
> However, LOR or panic still persists. You can panic your -CURRENT machine
> by creating a log of files in a directory. You can do it with a simpl
On Fri, Nov 28, 2003 at 12:27:53AM +0100, Artur Poplawski wrote:
> > lock order reversal
> > 1st 0xc43d8ad4 vm object (vm object) @ /usr/src/sys/vm/swap_pager.c:1323
> > 2nd 0xc098cf60 swap_pager swhash (swap_pager swhash) @ /usr/src/sys/vm/swap_pag
> > er.c:1838
> > 3rd 0xc10368c4 vm object (v
On Thu, 27 Nov 2003 18:01:39 -0500
Jesse Guardiani <[EMAIL PROTECTED]> wrote:
> I got this LOR today after upgrading my IBM Thinkpad A30p from 5.1-RELEASE
> to 5.2-BETA:
>
> lock order reversal
> 1st 0xc43d8ad4 vm object (vm object) @ /usr/src/sys/vm/swap_pager.c:1323
> 2nd 0xc098cf60 swap_page
Am 24.11.2003 um 22:56 schrieb Kris Kennaway:
On Mon, Nov 24, 2003 at 10:52:54PM +0100, Stefan Bethke wrote:
Am 24.11.2003 um 22:19 schrieb Kris Kennaway:
On Mon, Nov 24, 2003 at 09:45:51PM +0100, Stefan Bethke wrote:
This is with a current from around two days ago, with a kernel not
much
differe
On Mon, Nov 24, 2003 at 10:52:54PM +0100, Stefan Bethke wrote:
>
> Am 24.11.2003 um 22:19 schrieb Kris Kennaway:
>
> >On Mon, Nov 24, 2003 at 09:45:51PM +0100, Stefan Bethke wrote:
> >>This is with a current from around two days ago, with a kernel not
> >>much
> >>different from GENERIC.
> >
> >
Am 24.11.2003 um 22:19 schrieb Kris Kennaway:
On Mon, Nov 24, 2003 at 09:45:51PM +0100, Stefan Bethke wrote:
This is with a current from around two days ago, with a kernel not
much
different from GENERIC.
Known problem.
I do follow -current quite closely, but none of the cvs lists. It
appears t
On Mon, Nov 24, 2003 at 09:45:51PM +0100, Stefan Bethke wrote:
> This is with a current from around two days ago, with a kernel not much
> different from GENERIC.
Known problem.
Kris
pgp0.pgp
Description: PGP signature
> > I am build freebsd-current w/ cvs snap on 2003.11.11
> > and have some problem:
> >
> > 2. kernel trap
> >
> > cpuid = 0 acic id = 00
>
> This has been fixed in later snaps.
Thanks, I now try 5.1-CURRENT FreeBSD 5.1-CURRENT #8: Fri Nov 21 23:12:09 MSK 2003.
This trap seems fixed.
And I no
On Tue, Nov 18, 2003 at 01:53:28PM -0600, Cosmin Stroe wrote:
> Here is the stack backtrace:
>
> lock order reversal
> 1st 0xc1da318c vm object (vm object) @ /usr/src/sys/vm/swap_pager.c:1323
> 2nd 0xc0724900 swap_pager swhash (swap_pager swhash) @
> /usr/src/sys/vm/swap_pager.c:1838
> 3rd 0xc
On Tue, 18 Nov 2003, Cosmin Stroe wrote:
> Here is the stack backtrace:
>
Thanks, this is known and is actually safe. We're pursuing ways to quiet
these warnings.
> lock order reversal
> 1st 0xc1da318c vm object (vm object) @ /usr/src/sys/vm/swap_pager.c:1323
> 2nd 0xc0724900 swap_pager swh
On Mon, Nov 10, 2003 at 02:43:11PM -0800, Sam Leffler wrote:
> On Monday 10 November 2003 02:27 pm, Steve Ames wrote:
> > On Mon, Nov 10, 2003 at 05:19:06PM -0500, Steve Ames wrote:
> > > New /usr/src from around 4:30PM EST:
> > >
> > > Mon Nov 10 17:16:14 EST 2003
> > > lock order reversal
> > > 1
On Monday 10 November 2003 02:27 pm, Steve Ames wrote:
> On Mon, Nov 10, 2003 at 05:19:06PM -0500, Steve Ames wrote:
> > New /usr/src from around 4:30PM EST:
> >
> > Mon Nov 10 17:16:14 EST 2003
> > lock order reversal
> > 1st 0xc6761890 rtentry (rtentry) @ /opt/src/sys/net/route.c:182
> > 2nd 0xc6
On Mon, Nov 10, 2003 at 05:19:06PM -0500, Steve Ames wrote:
>
> New /usr/src from around 4:30PM EST:
>
> Mon Nov 10 17:16:14 EST 2003
> lock order reversal
> 1st 0xc6761890 rtentry (rtentry) @ /opt/src/sys/net/route.c:182
> 2nd 0xc668687c radix node head (radix node head) @ /opt/src/sys/net/route
Hi,
I have been getting this LOR for a while,
and have been getting numerous kernel
panics related to running natd.
Sam Leffler is looking into it, but he is hard
at work fixing other problems in the networking
code as he strives to make it MPSAFE.
On Mon, Nov 03, 2003 at 09:24:14AM -0800, Maks
On Thursday 30 October 2003 10:30 am, othermark wrote:
> I'll me too this one..
>
> Another backtrace with a different call sequence (via ipv6), exact same LOR
>
> lock order reversal
> 1st 0xc2177c90 rtentry (rtentry) @ /usr/src/sys/net/route.c:182
> 2nd 0xc206537c radix node head (radix node he
I'll me too this one..
Another backtrace with a different call sequence (via ipv6), exact same LOR
lock order reversal
1st 0xc2177c90 rtentry (rtentry) @ /usr/src/sys/net/route.c:182
2nd 0xc206537c radix node head (radix node head) @ /usr/src/sys/net
route.c:544
Stack backtrace:
backtrace(c084
On Sat, Oct 25, 2003 at 02:18:41PM +0200, [EMAIL PROTECTED] wrote:
> Hello.
>
> Already reported?
Yeah, about once a day ;-)
~~~cut~~~
> panic: Hey partner, hold on there!
>
> syncing disks, buffers remaining... panic: sleeping thread (pid 25) owns
> a mutex
> Uptime: 50m30s
> panic: sleeping
On Fri, Oct 24, 2003 at 09:44:45AM +0200, Pawel Jakub Dawidek wrote:
> Hello.
>
> It was reported already?
Yes, n times.
Kris
pgp0.pgp
Description: PGP signature
1 - 100 of 170 matches
Mail list logo
