Jack Vogel wrote:
> The next driver I that I release via Intel channels is going to
> merge the code for 6 and 7. I was thinking that I could check that
> into the tip and it would make the most current version buildable
> on either RELEASE, was wondering if that is looked upon favorably
> or not?
Synopsis: [fxp] fxp looses ability to speak with traffic
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: remko
Responsible-Changed-When: Wed Jul 25 06:03:17 UTC 2007
Responsible-Changed-Why:
This seems more appropriate for the networking list, reassign.
http://www.
Synopsis: [gre][patch] gre(4) is not MPSAFE and does not support keys
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: remko
Responsible-Changed-When: Wed Jul 25 05:58:21 UTC 2007
Responsible-Changed-Why:
This looks something more networking specific, reassign.
http
On Fri, 20 Jul 2007, Peter Wemm wrote:
TCP: [127.0.0.1]:52446 to [127.0.0.1]:1128 tcpflags 0x10;
syncache_expand: Segment failed SYNCOOKIE authentication, segment
rejected (probably spoofed)
[...]
How on earth can localhost be spoofing itself? This is getting quite
absurd. :-(
Any extra ACK
The next driver I that I release via Intel channels is going to
merge the code for 6 and 7. I was thinking that I could check that
into the tip and it would make the most current version buildable
on either RELEASE, was wondering if that is looked upon favorably
or not? I have code ready to do tha
now available at: http://people.freebsd.org/~mlaier/PF41/ with
instructions how to build.
Please test if possible and provide me with feedback.
Again, this work can't be MFC'ed, but I'll try to keep up2date patches
available for RELENG_6 and release branches.
--
/"\ Best regards,
WOW, I want to really thank you for finding this Patrick.
In Febuary 2006 Gleb introduced a drastic rename of our
adapter struct, it introduced a HUGE amount of diffs, we (Intel)
did not want that change and eventually it was backed out,
however it was in that delta that the bang got lost in this
Hmmm, this looks like a bug, I will look more closely today.
Sorry I have not been able to be more active with your problem,
but things have been hectic with product launches and my own
internal bug fixing. I will try to get this turned around quickly
Patrick.
Jack
On 7/24/07, Patrick Oeschger
OK - found the problem
the driver in 6.2-RELEASE has different code in em_identify_hardware
my hardware needs the memory access and bus master bits getting set by
the driver
beginning with 6.2-RELEASE this gets only set if PCIM_CMD_BUSMASTEREN is
*not set* and PCIM_CMD_MEMEN is *set* - it seems the
