during a release cycle.
At most, TSO should be whitelisted for specific, thoroughly tested
PCI IDs but not the entire classes.
Marius
[Evilham]
On dt., des. 17 2019, Marius Halden wrote:
Hi,
We have som machines with Intel i350 NICs which after upgrading
from
11.2-RELEASE to 12.1-RELEASE has started to act up. They will
detect
link and come up initially when brought up, but they will not
detect
link down events when the
this behaviour, nor did disabling `vlanhwtag` which I found a bug report
for issues with when using these NICs.
Is this a known regression from 11.X? Any advise for how to debug this
further?
--
Marius Halden
___
freebsd-net@freebsd.org mailing list
On Fri, Aug 31, 2018, at 00:35, Navdeep Parhar wrote:
> On 8/30/18 3:14 PM, Navdeep Parhar wrote:
> > On 8/30/18 2:51 PM, Marius Halden wrote:
> >> On Thu, Aug 30, 2018, at 19:27, Navdeep Parhar wrote:
> >>> On 8/30/18 4:21 AM, Marius Halden wrote:
> >>&g
On Fri, Aug 31, 2018, at 00:22, Rodney W. Grimes wrote:
> > On 8/30/18 2:51 PM, Marius Halden wrote:
> > > On Thu, Aug 30, 2018, at 19:27, Navdeep Parhar wrote:
> > >> On 8/30/18 4:21 AM, Marius Halden wrote:
> > >>> I tried to downgrade to a
On Fri, Aug 31, 2018, at 00:14, Navdeep Parhar wrote:
> On 8/30/18 2:51 PM, Marius Halden wrote:
> > On Thu, Aug 30, 2018, at 19:27, Navdeep Parhar wrote:
> >> On 8/30/18 4:21 AM, Marius Halden wrote:
> >>> I tried to downgrade to a the previous bsdrp version we wer
On Thu, Aug 30, 2018, at 19:27, Navdeep Parhar wrote:
> On 8/30/18 4:21 AM, Marius Halden wrote:
> > I tried to downgrade to a the previous bsdrp version we were running based
> > on 11.1-RELEASE-p10, but it did not start working again. ifconfig output
> > and t5nex0 devlog
On Thu, Aug 30, 2018, at 13:21, Marius Halden wrote:
> On Wed, Aug 29, 2018, at 12:22, Marius Halden wrote:
> > On Wed, Aug 29, 2018, at 08:28, Navdeep Parhar wrote:
> > > > > > Provide the output of these commands when the link isn't up:
> > > > &
On Wed, Aug 29, 2018, at 12:22, Marius Halden wrote:
> On Wed, Aug 29, 2018, at 08:28, Navdeep Parhar wrote:
> > > > > Provide the output of these commands when the link isn't up:
> > > > > # ifconfig -mvvv
> > > > > # sysctl -n dev.t5nex.0
s working?
Sure, the output from when it works follows.
--
Marius Halden
# ifconfig -mvvv cxl0
cxl0: flags=8843 metric 0 mtu 1500
options=e800bb
capabilities=ecc7bb
ether 00:07:43:42:cb:30
hwaddr 00:07:43:42:cb:30
inet 1.2.3.4 netmask 0xfffc broadcast 1.2.3.4
inet6 fe8
On Wed, Aug 29, 2018, at 01:50, Kevin Oberman wrote:
> On Tue, Aug 28, 2018 at 1:14 PM Marius Halden wrote:
>
> > On Tue, Aug 28, 2018, at 21:34, Navdeep Parhar wrote:
> > > On 8/28/18 12:30 PM, Marius Halden wrote:
> > > > tx_frames does move, rx_frame
On Tue, Aug 28, 2018, at 21:34, Navdeep Parhar wrote:
> On 8/28/18 12:30 PM, Marius Halden wrote:
> > tx_frames does move, rx_frames is stuck at zero. The following counters are
> > non-zero and does increase when traffic is sent through the interface, all
> > ot
On Tue, Aug 28, 2018, at 20:32, Navdeep Parhar wrote:
> On 8/28/18 11:27 AM, Marius Halden wrote:
> > On Tue, Aug 28, 2018, at 20:06, Navdeep Parhar wrote:
> >> On 8/28/18 2:35 AM, Marius Halden wrote:
> >>> ...
> >>> media: Ethernet 1000baseSX
&g
On Tue, Aug 28, 2018, at 20:06, Navdeep Parhar wrote:
> On 8/28/18 2:35 AM, Marius Halden wrote:
> > ...
> > media: Ethernet 1000baseSX
> > status: active
> > supported media:
> > media 1000baseSX mediaopt full-duplex,rxpause,txpause
> >
On Mon, Aug 27, 2018, at 20:45, Marius Halden wrote:
> On Mon, Aug 27, 2018, at 17:13, Navdeep Parhar wrote:
> > On Mon, Aug 27, 2018 at 04:19:29PM +0200, Marius Halden wrote:
> > > Hi,
> > >
> > > We have some routers with Chelsio T540-CR NICs using 1Gb
On Mon, Aug 27, 2018, at 17:13, Navdeep Parhar wrote:
> On Mon, Aug 27, 2018 at 04:19:29PM +0200, Marius Halden wrote:
> > Hi,
> >
> > We have some routers with Chelsio T540-CR NICs using 1Gbps SFPs (1000
> > Base-LX IIRC) to connect to our ISPs. After upgrading them to
else observed this problem? Any suggestions for what can be done to
solve/work around this issue without actually going to the datacenter would be
great.
--
Marius Halden
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo
On Thu, Feb 1, 2018, at 15:17, Marius Halden wrote:
> Hi,
>
> We have two routers running FreeBSD r320487 (BSDRP) with bxe NICs, they
> are connected together with a twinax cable and to our ISP with 1Gbit
> fiber. The NICs in question are Broadcom BCM57840S (Supermicro AOC-STG-
&
bxe0: ELINK EVENT LOG (3)
This is not always limited to just one interface, but can include all
interfaces which are in use.
--
Marius Halden
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe,
says 10Gbase-SR. When we
connect any of the other SFPs we get no info in dmesg and ifconfig says no
carrier if we try to bring up the interface.
Do you have any suggestions for how we can try to figure out this does not work?
--
Marius Halden
On Thu, Jul 06, 2017 at 02:19:42PM -0700, Vincenzo Maffione wrote:
> Sure, can anyone commit this?
The addition of KASSERTs like the below one to if_handoff() and
if_start()? Sure.
Marius
>
> Il 5 lug 2017 4:05 AM, "Marius Strobl" ha scritto:
>
> > On Mon, Jul
method in order to not hurt the fast-path. Thus, if
anything at all, a KASSERT(ifp->if_start != NULL, "no if_start method")
should be added to if_handoff() and if_start().
Marius
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.
mugius.0x101.freebsd_gmail.com created this revision.
mugius.0x101.freebsd_gmail.com added a reviewer: network.
mugius.0x101.freebsd_gmail.com added a subscriber: freebsd-net-list.
mugius.0x101.freebsd_gmail.com set the repository for this revision to rS
FreeBSD src repository.
Herald added a subs
On Tue, Sep 15, 2015 at 07:04:53AM -0700, Sreenath Battalahalli wrote:
> Hi,
>
> Will you be submitting the patch upstream to support the new device revision?
>
Hi,
I committed in r287768 and will MFC it to stable/10 in a week or
; device_attach: re0 attach returned 6
>
> Looks like this hardware is not supported by the driver.
>
> Freebsd version is 10.2 amd64
>
> any help if getting this to work appreciated.
>
Please give the attached patch a try.
Marius
Index: re/if_re.c
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Martin Matuska committed this fix for PF:
> https://lists.freebsd.org/pipermail/svn-src-head/2014-April/057803.html
>
> So a lot of the stability problems with VIMAGE which were in PC-BSD 9.2 and
> FreeBSD 9.x have been slowly been fixed.
Marius
___
#x27;ll let you know if I find a clue.
>
Sorry for the late reply. I didn't hit any timeouts when testing the
changes making re(4) work with DS47, including not when benchmarking
performance. Unfortunately, that machine now is at a remote location
not allowing further tests.
Marius
re in addition
or instead of copper media (which are all examples from reality).
Saying that a specific MAC driver "supports" certain media is
just outright misleading in such cases.
Marius
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
On Sun, Apr 07, 2013 at 03:10:05PM +0100, Joe Holden wrote:
> Marius Strobl wrote:
> > On Sat, Apr 06, 2013 at 01:07:16AM +0100, Joe Holden wrote:
> >> Hi guys,
> >>
> >> I'm trying to make rarpd behave, but it doesn't seem to want to listen
p://svnweb.freebsd.org/base?view=revision&revision=238282
Marius
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
The following reply was made to PR kern/175734; it has been noted by GNATS.
From: Marius Strobl
To: bug-follo...@freebsd.org, m.sp...@meta-srl.com
Cc:
Subject: Re: kern/175734: no ethernet detected on system with EG20T PCH
chipset ATOM E6xx series
Date: Fri, 1 Feb 2013 18:21:34 +0100
On Fri, Jan 25, 2013 at 01:14:51PM -0600, Paul Keusemann wrote:
>
> On 01/25/13 10:19, Marius Strobl wrote:
> > On Thu, Jan 24, 2013 at 08:48:04PM -0600, Paul Keusemann wrote:
> >> On 01/24/13 15:50, Marius Strobl wrote:
> >>> On Thu, Jan 24, 2013 at 12:39
On Thu, Jan 24, 2013 at 08:48:04PM -0600, Paul Keusemann wrote:
>
> On 01/24/13 15:50, Marius Strobl wrote:
> > On Thu, Jan 24, 2013 at 12:39:44PM -0600, Paul Keusemann wrote:
> >> On 01/24/13 09:09, Marius Strobl wrote:
> >>> On Tue, Jan 22, 2013 at 02:46
On Thu, Jan 24, 2013 at 12:39:44PM -0600, Paul Keusemann wrote:
>
> On 01/24/13 09:09, Marius Strobl wrote:
> > On Tue, Jan 22, 2013 at 02:46:48PM -0600, Paul Keusemann wrote:
> >> Hi,
> >>
> >> I've got a Dell R200 which I'm trying to build into
reported as working before,
though. It also doesn't make much sense that attaching the devices
succeeds on the second attempt. Could you please use a if_cas.ko built
with the attached patch and report the debug output for one of the
interfaces in both the working an
actually rather
mixed experiences on x86 with it as the compiler doesn't necessarily
produce the small and efficient one would expect from code it. Such
a change certainly shouldn't be done just on the assumption that the
compiler has all hints required to produce good code from it but the
bcopy() calls, for !__NO_STRICT_ALIGNMENT
architectures these places probably should use memcpy()
instead as bcopy() additionally has to check for overlap
while the former does not. Overlaps unlikely are an issue
in these cases and at least NetBSD apparently has done the
switch to memcpy() 5.5 year
Synopsis: [mii] [patch] brgphy(4) is not used for BCM57780
State-Changed-From-To: open->closed
State-Changed-By: marius
State-Changed-When: Sat Feb 25 01:22:51 UTC 2012
State-Changed-Why:
close
http://www.freebsd.org/cgi/query-pr.cgi?pr=165
at work we use
a single MDIO master and switch it to different slave busses using
a multiplexer managed via GPIO ... not that I'd ever wanted to
support this via generic means in FreeBSD.
Marius
___
freebsd-net@freebsd.org mailing list
http://
On Sun, Jan 29, 2012 at 05:21:52PM +0100, Stefan Bethke wrote:
>
> Am 29.01.2012 um 17:19 schrieb Marius Strobl:
>
> >>> We really need
> >>> to find a proper way of dealing with the constraints of the embedded-
> >>> world rather than to sprinkle ha
On Sun, Jan 29, 2012 at 05:00:38PM +0100, Stefan Bethke wrote:
> Am 29.01.2012 um 16:31 schrieb Marius Strobl:
>
> > How about adding the MDIO provider via multi-pass probing? That idea
> > of that model was to attach things like drivers for interrupt controllers
> > befo
llers
before any other driver that requires that resource. This seems like a
perfect match here and requires neither a specific hack to the nexus
(the platform generally needs to be multi-pass aware though and the
thing enabled in subr_bus.c) nor a hack to miibus(4). We really need
to find a prop
2001:418:8006::1 prefixlen 64
> inet 198.180.150.2 netmask 0x broadcast 198.180.150.2
> nd6 options=21
> media: Ethernet 1000baseT (none)
> status: no carrier
>
Are you sure that the other end is also forced t
ored (which
generally might or might not work) into resulting what you see
now (the upper layers arguably shouldn't trigger a panic in this
case though). I can't remember a change to either bge(4) or
brgphy(4) between 8.2 and now which could trigger this though.
Have you tried to set
t something sucks in bge initialization at startup.
> insightful, i know. sorry.
>
Has that worked before with FreeBSD and if yes with which reversion?
Marius
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
On Sat, Jan 21, 2012 at 12:58:08AM +0100, Stefan Bethke wrote:
> Am 14.12.2011 um 02:16 schrieb Marius Strobl:
>
> > On Tue, Dec 13, 2011 at 10:53:48AM -0800, YongHyeon PYUN wrote:
> >> On Tue, Dec 13, 2011 at 11:04:51AM +0100, Stefan Bethke wrote:
> >>> Am 13.1
; >
> > After looking at the code a bit more, I think the common code just doesn't
> > set the BMCR_PDOWN (but clears it when bringing up the PHY).
> >
>
> Yes, and most PHYs could be powered down when BMCR_ISO is chosen.
> I'm not sure whether this could
ultiple MACs (as it isn't necessarily a MAC that the
MII bus in question is attached to, at least we use something
like that at $work).
Marius
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
wadays we also support more than 64 CPUs. I'm also
fine with just nuking the interrupt self-test altogether though.
Marius
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
On Mon, Oct 10, 2011 at 03:56:32PM +0800, dave jones wrote:
> On Mon, Oct 10, 2011 at 12:58 AM, Marius Strobl wrote:
> > On Fri, Oct 07, 2011 at 10:34:58AM +0800, dave jones wrote:
> >> Hi,
> >>
> >> Does FreeBSD have gpio bitbang api for MII? If not, any
On Tue, Oct 18, 2011 at 12:57:01PM +0300, andrew bliznak wrote:
> On Sun, 2011-10-16 at 03:08 +0200, Marius Strobl wrote:
> > On Sun, Oct 16, 2011 at 02:46:23AM +0200, Damien Fleuriot wrote:
> > >
> > >
> > > On 15 Oct 2011, at 22:56, Marius Strobl wrote:
>
On Sun, Oct 16, 2011 at 02:46:23AM +0200, Damien Fleuriot wrote:
>
>
> On 15 Oct 2011, at 22:56, Marius Strobl wrote:
>
> >
> > Could owners of nge(4), tl(4), wb(4) and rl(4) driven hardware (as for
> > rl(4) only 8129 need testing, 8139 don't) please gi
Could owners of nge(4), tl(4), wb(4) and rl(4) driven hardware (as for
rl(4) only 8129 need testing, 8139 don't) please give the following
patch a try in order to ensure it doesn't break anything?
for 9/head:
http://people.freebsd.org/~marius/mii_bitbang.diff
for 8:
http://people.f
On Fri, Oct 14, 2011 at 01:32:26PM -0700, YongHyeon PYUN wrote:
> On Thu, Oct 13, 2011 at 11:49:03PM +0200, Marius Strobl wrote:
> > On Wed, Oct 12, 2011 at 04:57:07PM -0700, YongHyeon PYUN wrote:
> > > On Wed, Oct 12, 2011 at 10:42:22PM +0200, Marius Strobl wrote:
> > >
On Wed, Oct 12, 2011 at 04:57:07PM -0700, YongHyeon PYUN wrote:
> On Wed, Oct 12, 2011 at 10:42:22PM +0200, Marius Strobl wrote:
> > On Tue, Oct 11, 2011 at 03:55:31PM -0700, YongHyeon PYUN wrote:
> > > On Tue, Oct 11, 2011 at 11:23:18PM +0200, Marius Strobl wrote:
> > >
On Tue, Oct 11, 2011 at 03:55:31PM -0700, YongHyeon PYUN wrote:
> On Tue, Oct 11, 2011 at 11:23:18PM +0200, Marius Strobl wrote:
> > On Mon, Oct 10, 2011 at 12:22:38PM -0700, YongHyeon PYUN wrote:
> > > On Sun, Oct 09, 2011 at 06:58:38PM +0200, Marius Strobl wrote:
> > >
On Mon, Oct 10, 2011 at 12:22:38PM -0700, YongHyeon PYUN wrote:
> On Sun, Oct 09, 2011 at 06:58:38PM +0200, Marius Strobl wrote:
> > On Fri, Oct 07, 2011 at 10:34:58AM +0800, dave jones wrote:
> > > Hi,
> > >
> > > Does FreeBSD have gpio bitbang api
> and it's useful for porting embedded devices.
>
If what you are referring to is their mii_bitbang.[c,h] then I've a patch
which (im)ports these and converts drivers to take advantage of it here:
http://people.freebsd.org/~marius/mii_bitbang.diff
You can also hook up that gener
Synopsis: [bce] bce driver shows "no carrier" on IBM blade (HS22 with BCM5709)
State-Changed-From-To: open->closed
State-Changed-By: marius
State-Changed-When: Tue Aug 23 14:51:51 UTC 2011
State-Changed-Why:
close
http://www.freebsd.org/cgi/query-pr.
The following reply was made to PR kern/158156; it has been noted by GNATS.
From: Marius Strobl
To: bug-follo...@freebsd.org, j...@ntu.edu.tw
Cc:
Subject: Re: kern/158156: [bce] bce driver shows "no carrier" on IBM blade
(HS22 with BCM5709)
Date: Mon, 8 Aug 2011 10:3
Synopsis: [re] re0 unknown hardware revision with onboard Realtek 8111E
State-Changed-From-To: open->closed
State-Changed-By: marius
State-Changed-When: Tue May 31 08:00:41 UTC 2011
State-Changed-Why:
Close; support was added in r217498 (MFC'ed to stable/8 in r218901 and to
stable/7 in
On Fri, Apr 22, 2011 at 10:07:11AM +, Bjoern A. Zeeb wrote:
> On Apr 21, 2011, at 8:33 PM, Marius Strobl wrote:
>
> Hi,
Hi
>
> I fear the change is too big for me to review currently.
Given that the majority of changes break backwards compatibility in
some way I intend to
I think now is actually a good time
to incorporate that work and commit any other ABI/API-breaking changes
to mii(4). I've prepared a patch which merges all relevant changes
from NetBSD I'm ware of and implements some other stuff I had in mind:
http://people.freebsd.org/~marius/mii_abi_br
On Wed, Apr 20, 2011 at 02:22:47PM +0100, Paul Thornton wrote:
> Hi,
>
> On 20/04/2011 14:16, Marius Strobl wrote:
> > Looks like brgphy(4) also needs to be taught about this hardware. Could
> > you please provide the corresponding part of a verbose dmesg?
>
> Hopef
10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
> 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow
Looks like brgphy(4) also needs to be taught about this hardware. Could
you please provide the corresponding part of a v
On Sun, Jan 16, 2011 at 03:42:47PM +0100, Marius Strobl wrote:
> On Fri, Jan 14, 2011 at 01:41:09PM +0300, Lev Serebryakov wrote:
> > Hello, Marius.
> > You wrote 14 ?? 2011 ?., 4:24:12:
> >
> > > found by ignoring the bits set in the "don't care ma
On Sun, Jan 16, 2011 at 05:55:06PM +, Bjoern A. Zeeb wrote:
> On Sun, 16 Jan 2011, Marius Strobl wrote:
>
> Hi,
>
> >On Fri, Jan 14, 2011 at 01:41:09PM +0300, Lev Serebryakov wrote:
> >>Hello, Marius.
> >>You wrote 14 ?? 2011 ?., 4:24:12:
> >&g
On Fri, Jan 14, 2011 at 01:41:09PM +0300, Lev Serebryakov wrote:
> Hello, Marius.
> You wrote 14 ?? 2011 ?., 4:24:12:
>
> > found by ignoring the bits set in the "don't care mask". I've
> > updated the patch at the above URL accordingly and based on m
On Thu, Jan 13, 2011 at 01:27:13PM -0800, Pyun YongHyeon wrote:
> On Thu, Jan 13, 2011 at 06:39:25PM +0100, Marius Strobl wrote:
> > On Wed, Jan 12, 2011 at 11:59:07PM +0100, Marius Strobl wrote:
> > > On Wed, Jan 12, 2011 at 01:32:08PM -0800, Pyun YongHyeon wrote:
> > >
On Thu, Jan 13, 2011 at 12:54:29PM +0300, Lev Serebryakov wrote:
> Hello, Marius.
> You wrote 13 ?? 2011 ?., 1:59:07:
>
> > Note that even the RealTek supplied driver always triggers an
> > auto-negotiation when manually setting the media though. However,
> > at
On Wed, Jan 12, 2011 at 11:59:07PM +0100, Marius Strobl wrote:
> On Wed, Jan 12, 2011 at 01:32:08PM -0800, Pyun YongHyeon wrote:
> > On Wed, Jan 12, 2011 at 07:20:09PM +0300, Lev Serebryakov wrote:
> > > Hello, Freebsd-net.
> > >
> > > Thanks to Pyun YongHyeo
uestion are amongst the ones that get patched so far.
In any case I don't think we can easily change this (default)
behavior after such a relatively long time as it would break POLA
for an unknown number of users, even if it probably shouldn't have
been made the default in the first place
magic for certain hardware versions when setting the
media manually but re(4) doesn't which might be relevant in this
scenario.
Marius
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
On Tue, Sep 28, 2010 at 11:58, dave jones wrote:
> Hello,
>
> In Linux, I can disconnect the socket using:
> sa.sin_family = AF_UNSPEC;
> val = connect(sockfd, (struct sockaddr *)&sa, sizeof(sa));
>
> the return value of val is 0; on freebsd, the return value of connect() is -1.
> According to Lin
On Tue, Feb 9, 2010 at 18:34, M. Warner Losh wrote:
> Greetings,
>
> I've found a few inconsistencies in the sockaddr stuff in the tree.
> I'm not sure where to go to get a definitive answer, so I thought I'd
> start here.
>
> I got here looking at the recent wake breakage on mips. It turns out
>
On Sat, Aug 1, 2009 at 04:52, Aragon Gouveia wrote:
> Hi,
>
> In sys/netinet/libalias/alias_db.c, SetStateIn() and SetStateOut() reference
> ALIAS_TCP_STATE_CONNECTED and ALIAS_TCP_STATE_DISCONNECTED. Does anyone know
> where/how these macros are defined?
>
>
> Thanks,
> Aragon
http://fxr.watson.o
On Mon, May 18, 2009 at 14:04, Sebastian Mellmann
wrote:
> Hi everyone!
>
> I've set the following parameters in rc.conf:
>
> gateway_enable="YES"
> firewall_enable="YES"
> firewall_type="OPEN"
> firewall_logging="YES"
>
> When I took a look at the ruleset I see:
>
> 00010 allow ip from any to any
with this simple change (and others to the
> > ed driver). I know that these cards are a little behind the leading
> > edge, but I'd like to get them working since I've put a few hours into
> > investigating things here.
> >
> > Comments?
> >
FYI, th
Synopsis: [bge] bge(4) transmit performance problem
State-Changed-From-To: open->closed
State-Changed-By: marius
State-Changed-When: Mon Mar 23 21:04:40 UTC 2009
State-Changed-Why:
close
http://www.freebsd.org/cgi/query-pr.cgi?pr=119361
___
free
Synopsis: [bge] Network packets corrupted when bge card is in 64-bit PCI slot
State-Changed-From-To: open->closed
State-Changed-By: marius
State-Changed-When: Mon Dec 15 21:08:02 UTC 2008
State-Changed-Why:
Close, a workaround for the hardware bug was committed to head (r185812),
stabl
The following reply was made to PR kern/128833; it has been noted by GNATS.
From: Marius Strobl <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
Subject: Re: kern/128833: [bge] Network packets corrupted when bge card is in
64-bit PCI
The following reply was made to PR kern/128833; it has been noted by GNATS.
From: Marius Strobl <[EMAIL PROTECTED]>
To: David Christensen <[EMAIL PROTECTED]>
Cc: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
Subject: Re: kern/128833: [bge] Network packets corrupted when bge
The following reply was made to PR kern/128833; it has been noted by GNATS.
From: Marius Strobl <[EMAIL PROTECTED]>
To: David Christensen <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: Re: kern/128833: [bge] Network packets corrupted when bge card is in
64-bit PCI slot
Date: Sun,
The following reply was made to PR kern/128833; it has been noted by GNATS.
From: Marius Strobl <[EMAIL PROTECTED]>
To: =?unknown-8bit?Q?Aur=E9lien_M=E9r=E9?= <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: Re: kern/128833: [bge] Network packets corrupted when bge card is in
64-
The following reply was made to PR kern/128833; it has been noted by GNATS.
From: Marius Strobl <[EMAIL PROTECTED]>
To: =?unknown-8bit?Q?Aur=E9lien_M=E9r=E9?= <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: Re: kern/128833: [bge] Network packets corrupted when bge card is in
64-
The following reply was made to PR kern/128833; it has been noted by GNATS.
From: Marius Strobl <[EMAIL PROTECTED]>
To: =?unknown-8bit?Q?Aur=E9lien_M=E9r=E9?= <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: Re: kern/128833: [bge] Network packets corrupted when bge card is in
64-
The following reply was made to PR kern/128833; it has been noted by GNATS.
From: Marius Strobl <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc:
Subject: Re: kern/128833: [bge] Network packets corrupted when bge card is in
64-bit PCI slot
Date: Thu, 13 Nov 2008 23:14:46
sc->dc_link = 0;
> }
> }
> - } else
> - mii_tick(mii);
> + }
>
> /*
>* When the init routine completes, we expect to be able to send
For the records, a more appropriate fix (the above pa
On Mon, May 12, 2008 at 01:55:34PM +0200, Volker wrote:
> On 05/12/08 13:19, Marius Strobl wrote:
> > On Mon, May 12, 2008 at 12:35:59PM +0200, Volker wrote:
> >> Hi!
> >>
> >> >From the bugbusting front, I'm often seeing network related issues with
&
n order to identifiy
the PHYs is to check the oui= and model= output of `devinfo -v`.
Otherwise boot verbose and check the OUI and model output of
ukphy(4).
Marius
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/fre
00baseTX-FDX, auto
> > ukphy1: PHY 0 on miibus1
> > ukphy1: OUI 0x080017, model 0x0002, rev. 1
> > ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
>
> That's odd. The OUI/Model number indicates NATSEMI(National
> Semiconductor), DP83815 PHY
Synopsis: [pcn] Kernel panic upon if_pcn module load on a Netfinity 5000
Responsible-Changed-From-To: freebsd-net->marius
Responsible-Changed-By: marius
Responsible-Changed-When: Wed Jan 23 21:53:19 UTC 2008
Responsible-Changed-Why:
grab
http://www.freebsd.org/cgi/query-pr.cgi?pr=112
The following reply was made to PR kern/112654; it has been noted by GNATS.
From: Marius Strobl <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: Andy Farkas <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Subject: Re: kern/112654: [pcn] Kernel panic upon if_pcn module load on a
Netfinity 5000
D
The following reply was made to PR kern/112654; it has been noted by GNATS.
From: Marius Strobl <[EMAIL PROTECTED]>
To: Nagy Keve <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
[EMAIL PROTECTED]
Cc:
Subject: Re: kern/112654: [pcn] Kernel panic upon if_pcn module load on a
Netfini
The following reply was made to PR kern/112654; it has been noted by GNATS.
From: Marius Strobl <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc:
Subject: Re: kern/112654: [pcn] Kernel panic upon if_pcn module load on a
Netfinity 5000
Date: Wed, 16 May 2007 19:59:01 +02
96 matches
Mail list logo
