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 RX
On Mon, Apr 12, 2010 at 7:52 AM, John Baldwin j...@freebsd.org 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
On Monday 12 April 2010 12:26:06 pm Jack Vogel wrote:
On Mon, Apr 12, 2010 at 7:52 AM, John Baldwin j...@freebsd.org 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
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)
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:
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:
Don't know,
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: Intel(R) PRO/1000 Network Connection 7.0.4 port
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.
While testing an i5 box with HEAD checked out from this morning,
bringing up the second NIC generated this LOR on the console
em1: link state changed to UP
lock order reversal:
1st 0xc5dc7c10 em1:rx(1) (em1:rx(1)) @
/usr/HEAD/src/sys/modules/em/../../dev/e1000/if_em.c:4089
2nd 0xc0f7e88c
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
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 encounters
On Fri, Apr 9, 2010 at 1:13 PM, Pyun YongHyeon pyu...@gmail.com 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
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)
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 m...@sentex.net 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.
14 matches
Mail list logo
