On Sat, Apr 6, 2019 at 10:24 PM Graham Menhennitt
wrote:
> Not that it's at all relevant to the question here, but...
>
> It does mostly work without em in the 12 kernel - I'm not sure how, but
> it does.
>
> I upgraded to 12-stable via source but didn't add em to my custom
> kernel. Most things
On Mon, Mar 4, 2019 at 5:29 PM Andriy Gapon wrote:
> On 04/03/2019 22:35, Nick Rogers wrote:
> > v_lock = {lock_object = {lo_name =
> > 0x8144af45 "zfs", lo_flags = 117112840, lo_data = 0, lo_witness =
> > 0x0}, lk_lock = 18446744073709551605, lk_exslpfai
On Sat, Mar 2, 2019 at 12:48 PM Andriy Gapon wrote:
> On 01/03/2019 17:00, Nick Rogers wrote:
> > 36704 101146 perl- mi_switch+0xe1
> > sleepq_wait+0x2c sleeplk+0x1c5 lockmgr_xlock_hard+0x19c
> VOP_LOCK1_APV+0x7e
> > _vn_lock+0x
wrote:
> On 01/03/2019 17:00, Nick Rogers wrote:
> > 36704 101146 perl- mi_switch+0xe1
> > sleepq_wait+0x2c sleeplk+0x1c5 lockmgr_xlock_hard+0x19c
> VOP_LOCK1_APV+0x7e
> > _vn_lock+0x40 zfs_znode_alloc+0x434 zfs_mknode+0xa9d
> > zfs_freeb
On Sat, Mar 2, 2019 at 5:27 PM Peter Avalos via freebsd-stable <
freebsd-stable@freebsd.org> wrote:
>
> > On Mar 1, 2019, at 7:00 AM, Nick Rogers wrote:
> >
> > I am hoping someone can help me figure out if this is a legitimate bug,
> or
> > something alread
Recently a number of my production 12.0 systems have experienced what I can
only gather is a ZFS deadlock related to vnodes. It seems similar to the
relatively recent FreeBSD-EN-18:18.zfs (ZFS vnode reclaim deadlock)
problem. Previously the same systems were running 11.1-RELEASE without
problem.
T
Hello,
I am not sure if this is the appropriate place to inquire about this, but I
am unable to update my 10.1-RELEASE machines to the latest releng branch
(10.1-RELEASE-p33) with the latest FreeBSD-SA-16:17.openssl advisory.
Here's what happens when I try freebsd-update.
# freebsd-version -ku
1
On Thu, Apr 16, 2015 at 6:52 PM, Glen Barber wrote:
> On Wed, Apr 15, 2015 at 02:44:44PM -0700, Nick Rogers wrote:
> > On Mon, Mar 9, 2015 at 9:19 AM, Nick Rogers wrote:
> > > Is anyone working on fixing this problem? It seems like this should
> have
> > > some ki
On Mon, Mar 9, 2015 at 9:19 AM, Nick Rogers wrote:
>
>
> On Tue, Feb 10, 2015 at 1:37 PM, Nick Rogers wrote:
>
>>
>>
>> On Mon, Feb 9, 2015 at 9:08 AM, Ian Lepore wrote:
>>
>>> On Mon, 2015-02-09 at 11:41 -0500, Kurt Lidl wrote:
>>> >
On Tue, Feb 10, 2015 at 1:37 PM, Nick Rogers wrote:
>
>
> On Mon, Feb 9, 2015 at 9:08 AM, Ian Lepore wrote:
>
>> On Mon, 2015-02-09 at 11:41 -0500, Kurt Lidl wrote:
>> > Joel wrote:
>> > > Hi,
>> > >
>> > > Just about every machine
On Sun, Jun 6, 2010 at 4:23 PM, Nick Rogers wrote:
>
>
> On Sat, Jun 5, 2010 at 11:54 PM, Garrett Cooper wrote:
>>
>>
>> I agree with Jeremy. I think that the problem that you've
>> discovered is the fact that it's using stdio-based buffered
On Tue, Jan 26, 2010 at 12:49 PM, Nick Rogers wrote:
> Thanks a lot. Thats a bummer. What are the chances of getting something
> like that worked into arp(8) permanently?
>
>
I recently noticed that arp(8) was changed a few months back to show when an
entry expires. T
On Sat, Jun 5, 2010 at 11:54 PM, Garrett Cooper wrote:
>
>
> I agree with Jeremy. I think that the problem that you've
> discovered is the fact that it's using stdio-based buffered output
> instead of buffering more of the contents in a string and punting it
> out in larger chunks.
> HTH,
> -G
On Mon, May 31, 2010 at 10:54 PM, Nick Rogers wrote:
>
> [root@ ~]# time arp -na > /dev/null
>
> real 0m12.761s
> user 0m2.959s
> sys 0m9.753s
> [root@ ~]#
>
>
> Notice that "arp -na" takes about 13s to execute even though there is no
> other loa
I have an 8.0-RELEASE system with 4000 "permanent" ARP entries due to having
a network interface (em(4)) configured with 4000 aliases. The "arp -na"
command takes what I consider to be an extremely long time to finish (up to
30s on an otherwise unloaded system). I am able to replicate this in a tes
ALTQ + RELENG_8 + em(4) will not work at the moment. It does not matter what
your PF ruleset looks like or how much traffic you are pushing. The packets
that transit the em interface simply never make it to the ALTQ queues (not
even the interface's root queue). Thus any kind of bandwidth rate limit
Yes, this was the first em(4) problem I ran into when upgrading from
7.2-RELEASE to 8.0-RELEASE. Yourself and others on another thread eventually
recommended turning off TSO and what not. I never had a chance to thoroughly
test this solution on this particular hardware because we had already
switch
I'm still having a problem where an em(4) interface mysteriously "hangs" and
mostly stops sending/receiving packets until I issue an ifconfig emX down
followed by an ifconfig emX up, which fixes the problem for some amount of
time. Traffic on the interface is about a consistent 3mb/s.
One interes
Second that. Daily panics using a Tyan board w/ BCM5704. Unfortunately
unable to provide crash dump and I was forced to use a different NIC. But
for what its worth here is the relevant pciconf -lv output.
b...@pci0:2:9:0: class=0x02 card=0x164814e4 chip=0x164814e4 rev=0x03
hdr=0x00
vendor
hw.bge.allow_asf: 0
On Mon, Feb 15, 2010 at 2:23 AM, Giacomo Olgeni wrote:
>
> Hello,
>
> Are you running with hw.bge.allow_asf enabled?
>
>
>
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsub
I'm having repeated kernel panic issues on 8.0-RELEASE/amd64. Can anyone
shed light on the below error? I unfortunately cannot provide a proper crash
dump. The pointer addresses are always the same. The only other thing I've
noticed that may be related is a watchdog timeout on bge0 error before the
Anyone else get a chance to review this?
On Fri, Feb 5, 2010 at 8:44 PM, Nick Rogers wrote:
> I applied drbr_altq.diff to the e1000 driver (sys/dev/e1000) from HEAD on
> top of 8.0-RELEASE kernel sources. It appears to have fixed the immediate
> problem where queues simply don
I applied drbr_altq.diff to the e1000 driver (sys/dev/e1000) from HEAD on
top of 8.0-RELEASE kernel sources. It appears to have fixed the immediate
problem where queues simply don't work on em interfaces. Thanks a bunch.
I suppose further review and testing by others would be greatly appreciated
f
On Fri, Feb 5, 2010 at 9:41 AM, Spas Karabelov wrote:
> Hello,
>
> I am trying to perform traffic redirection with PF on 7.2-RELEASE.
> The traffic is in the same subnet and I try doing that by using just one
> interface em0.
PF cannot redirect packets back out the interface they originated on.
On Tue, Feb 2, 2010 at 9:37 AM, Pyun YongHyeon wrote:
> On Tue, Feb 02, 2010 at 09:30:52AM -0800, Nick Rogers wrote:
> > > I guess the problem comes from multi-queue support. The drbr
> > > interface is implemented with inline function so em(4)/igb(4) may
> > > hav
> I guess the problem comes from multi-queue support. The drbr
> interface is implemented with inline function so em(4)/igb(4) may
> have to define ALTQ to the header. I have not tested the patch(no
> time at this moment) but would you give it try?
>
> I tried the patch and it did not work.
___
I'm having problems getting PF + ALTQ to work on em(4) interfaces under
8.0-RELEASE. Kernel was rebuilt with the additional options necessary for
ALTQ and what not. Same basic configuration works fine under 7.2-RELEASE.
Basically, the queues create successfully but running a pfctl -vsq shows a
zero
On Fri, Jan 29, 2010 at 5:43 PM, Jack Vogel wrote:
> You know, i know absolutely nothing about ALTQ :) This is the first I've
> heard
> about this problem, you should make sure the maintainer of the driver gets
> informed sooner :)
>
> Look like there is an old PR for it. See kern/138392.
___
of the driver gets
> informed sooner :)
>
> Would be happy to look into it as I have time.
>
> Jack
>
>
>
> On Fri, Jan 29, 2010 at 5:28 PM, Nick Rogers wrote:
>
>> Does any of this have anything to do with the fact that ALTQ seems to be
>> broken for
t; > get. Should be days rather then hours, but I'll make it asap.
> >
> > > If you have any problems or questions email me directly.
> >
> > Will do, thanks!
> >
> > Marco
> >
> >
> >
> >
> > > On Thu, Jan 28, 2010 at 4:17 AM, Ma
>
> > Hi,
> >
> > On 2010-1-25, at 19:38, Nick Rogers wrote:
> > >> On Mon, Jan 25, 2010 at 10:22 AM, Pyun YongHyeon
> > wrote:
> > >> I'm not sure you're seeing a checksum offload bug of em(4) but the
> > >> bug is easily repro
looks like the patch mentioned in kern/141843 has not been applied to the
tree?
On Tue, Jan 26, 2010 at 9:00 AM, Nick Rogers wrote:
> Is it advisable to patch 8.0-RELEASE kernel sources with the latest
> (CURRENT) em driver (i.e., src/sys/dev/e1000)? It looks like there are some
> u
Is it advisable to patch 8.0-RELEASE kernel sources with the latest
(CURRENT) em driver (i.e., src/sys/dev/e1000)? It looks like there are some
updates to the driver since 8.0-RELEASE that may fix some problems?
On Mon, Jan 25, 2010 at 8:31 PM, Joshua Boyd wrote:
> I've been having a similar pro
Thanks a lot. Thats a bummer. What are the chances of getting something like
that worked into arp(8) permanently?
On Tue, Jan 26, 2010 at 4:41 AM, Ruslan Ermilov wrote:
> On Mon, Jan 25, 2010 at 07:01:46PM -0800, Nick Rogers wrote:
> > Before 8.0-RELEASE, if I ran netstat -rn, it
Before 8.0-RELEASE, if I ran netstat -rn, it listed a separate route for
each host on the network, along with its MAC address. For example ...
172.20.172.17 00:02:b3:2f:64:6a UHLW1 105712 1500
vlan172595
172.20.172.20 00:1e:c9:bb:7c:a9 UHLW1 1002 1500
On Mon, Jan 25, 2010 at 10:22 AM, Pyun YongHyeon wrote:
> On Mon, Jan 25, 2010 at 08:25:43AM -0800, Nick Rogers wrote:
> > I have not tried toying with any tcp sysctl. I'm not having performance
> > problems so much as the interface just stops working entirely, which I
&
I have not tried toying with any tcp sysctl. I'm not having performance
problems so much as the interface just stops working entirely, which I would
think has nothing to do with the TCP stack when layer 2 is not functioning?
I'll give it a shot if I can. For the moment I have had to switch to a
di
I am having similar em interface problems with some of my production
machines running older intel 2-port cards, since upgrading from 7.2-RELEASE
to 8.0-RELEASE. The problem is basically, everything works fine, but
periodically the interface "hangs" (tcpdump shows no frames). A reboot or an
ifconfig
38 matches
Mail list logo
