Ok, the review is updated with the EBR. If you can update your tree to
r333466 or newer, apply the patch and retest, that would be great. It
seems to be working here.
On Thu, May 10, 2018 at 2:29 PM, Harry Schmalzbauer
wrote:
> Bezüglich Stephen Hurd's Nachricht vom 10.05.2018 20:07 (localtime
Hello,
if I pull the TP connection from my i217 Clarkville, HEAD still reports
media
1000Base-T status "active".
Doing the same with the other if_em(4) NIC in that box, a hartwell,
82574LM, the status correctly changes to "no carrier".
This is not iflib related, since it's reproducable with Fre
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227259
Jonathan T. Looney changed:
What|Removed |Added
Status|New |In Progress
--- Comment #12 f
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227259
--- Comment #11 from e...@free.fr ---
Hi,
Any news on this subject, please ?
Regards
Éric Masson
--
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-net@fre
Bezüglich Stephen Hurd's Nachricht vom 10.05.2018 20:07 (localtime):
> No need to test the latest revision unless/until you get a LOR or a
> panic (both should be possible with the revision you currently have).
> With the recent addition of a simple EBR API, mmacy@ is working on a
> better solutio
No need to test the latest revision unless/until you get a LOR or a panic
(both should be possible with the revision you currently have). With the
recent addition of a simple EBR API, mmacy@ is working on a better
solution. If possible, it would be great to have you re-test it once that
is up.
O
Bezüglich Harry Schmalzbauer's Nachricht vom 10.05.2018 19:54 (localtime):
…
> Please excuse that I'm not familar with the phabricator and just did
> "raw diff download" after briefly flying over the comments.
> According to st_mtime this was on May 9th, 08:14:02 UTC (10:14 local
> (CEST) time).
>
Bezüglich Stephen Hurd's Nachricht vom 08.05.2018 20:58 (localtime):
> Can you test the review here: https://reviews.freebsd.org/D15355
>
> It looks like there are two different locks protecting the same data
> everywhere but in lagg_ioctl(). This is a rough first-pass, and there may
> be some li
On 9/5/18 11:24 pm, Abdullah Tariq wrote:
a picture would do wonders to understand what he wants.
Apologies for being AWOL
Attaching an image link: https://ibb.co/nt1s4S
Ok so, it looks like there i a problem in concepts.
FreeBSD doesn't really know about tags inside the machine..
It
> -Original Message-
> From: Dries Michiels
> Sent: donderdag 10 mei 2018 16:58
> To: 'Andrey V. Elsukov' ; freebsd-net@freebsd.org
> Subject: RE: kernel: in6_delayed_cksum: delayed m_pullup
>
> > -Original Message-
> > From: Andrey V. Elsukov
> > Sent: donderdag 10 mei 2018 16:3
On 2018-05-10 10:21, Grzegorz Junka wrote:
On 08/05/2018 23:41, Justin Clift wrote:
That's probably a ConnectX (series 1) Mellanox card. Those can
operate in
either Infiniband mode, or Ethernet mode.
Which mode are you wanting it to run in? :)
As a thought, the FreeBSD wiki page has a bit
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228108
--- Comment #2 from bugs.freebsd@mx.zzux.com ---
And why ping is working ok?
ping -c 1 -S 192.168.233.1 192.168.233.2
PING 192.168.233.2 (192.168.233.2) from 192.168.233.1: 56 data bytes
64 bytes from 192.168.233.2: icmp_seq=0 ttl=64 tim
В Thu, 10 May 2018 16:56:38 +0200
"Dries Michiels" пишет:
> I had updated the day after to see if it was just a regression but
> the error message was not gone: May 1 22:19:51 vados kernel:
> in6_delayed_cksum: delayed m_pullup, m->len: 48 plen 68 off 56
> csum_flags=400 May 1 22:27:57 vados la
> -Original Message-
> From: Andrey V. Elsukov
> Sent: donderdag 10 mei 2018 16:34
> To: Dries Michiels ; freebsd-net@freebsd.org
> Subject: Re: kernel: in6_delayed_cksum: delayed m_pullup
>
> On 10.05.2018 17:25, Andrey V. Elsukov wrote:
> > On 29.04.2018 21:30, Dries Michiels wrote:
> >
> -Original Message-
> From: Tom Jones
> Sent: donderdag 10 mei 2018 15:48
> To: Dries Michiels
> Cc: freebsd-net@freebsd.org
> Subject: Re: kernel: in6_delayed_cksum: delayed m_pullup
>
> On Mon, Apr 30, 2018 at 09:54:48AM +0200, Dries Michiels wrote:
> >
> > Tom,
> >
> > I’m using the
On 10.05.2018 17:25, Andrey V. Elsukov wrote:
> On 29.04.2018 21:30, Dries Michiels wrote:
>> Dear mailing list,
>>
>> After upgrading my FreeBSD server from source from:
>> FreeBSD 11.1-STABLE (VADOS) #9 r331859: Sun Apr 1 12:09:18 CEST 2018
>> to
>> FreeBSD 11.2-PRERELEASE (VADOS) #10 r333091:
On 29.04.2018 21:30, Dries Michiels wrote:
> Dear mailing list,
>
> After upgrading my FreeBSD server from source from:
> FreeBSD 11.1-STABLE (VADOS) #9 r331859: Sun Apr 1 12:09:18 CEST 2018
> to
> FreeBSD 11.2-PRERELEASE (VADOS) #10 r333091: Sun Apr 29 16:48:44 CEST 2018
>
> My /var/log/messag
On Mon, Apr 30, 2018 at 09:54:48AM +0200, Dries Michiels wrote:
>
> Tom,
>
> I’m using the igb (intel I210) driver for my LAN interface and the em
> (intel I219-V) driver for the WAN interface. I use this FreeBSD box
> as my home server so I wouldn’t say that it has a heavy ipv6 workload.
>
Hi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228108
Andrey V. Elsukov changed:
What|Removed |Added
CC||a...@freebsd.org
--- Comment #
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228108
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--
You are receiv
On Thu, May 10, 2018 at 09:21:10AM +, Grzegorz Junka wrote:
>
> On 08/05/2018 23:41, Justin Clift wrote:
> > On 2018-05-08 21:59, Grzegorz Junka wrote:
> >> Hi All,
> >>
> >> pciconf -lv
> >>
> >> gives me
> >>
> >> none1@pci0:3:0:0: class=0x0c0600 card=0x000315b3
> >> chip=0x6340
On Thu, May 10, 2018 at 08:36:44AM +, Grzegorz Junka wrote:
>
> On 09/05/2018 00:39, Rodney W. Grimes wrote:
> >> On Tue, May 08, 2018 at 08:59:20PM +, Grzegorz Junka wrote:
> >>> Hi All,
> >>>
> >>> pciconf -lv
> >>>
> >>> gives me
> >>>
> >>> none1@pci0:3:0:0: class=0x0c0600
On 08/05/2018 23:41, Justin Clift wrote:
On 2018-05-08 21:59, Grzegorz Junka wrote:
Hi All,
pciconf -lv
gives me
none1@pci0:3:0:0: class=0x0c0600 card=0x000315b3 chip=0x634015b3
rev=0xa0 hdr=0x00
vendor = 'Mellanox Technologies'
device = 'MT25408 [ConnectX VPI - IB SDR
On 10/05/2018 09:06, Ben RUBSON wrote:
On 10 May 2018 10:36, Grzegorz Junka wrote:
Does it mean, that mlx4 is no longer compiled in the default kernel
It has never been, but I think modules have been added recently, I can
remember HPS did it :)
Right, I meant that they are not being build
On 10 May 2018 10:36, Grzegorz Junka wrote:
Does it mean, that mlx4 is no longer compiled in the default kernel
It has never been, but I think modules have been added recently, I can
remember HPS did it :)
Can I just compile the mlx4/en/ib kernel module without having to compile
the whol
On 09/05/2018 00:39, Rodney W. Grimes wrote:
On Tue, May 08, 2018 at 08:59:20PM +, Grzegorz Junka wrote:
Hi All,
pciconf -lv
gives me
none1@pci0:3:0:0: class=0x0c0600 card=0x000315b3 chip=0x634015b3
rev=0xa0 hdr=0x00
?? vendor = 'Mellanox Technologies'
??
26 matches
Mail list logo
