YongHyeon PYUN wrote:
> Thanks a lot! Here is final version. The patch checks whether
> the controller is i82550C with server extension. If driver see
> server NIC like yours it would allow microcode loading.
> I guess later 82550C controllers fixed the bug since mine has no
> problems to handle
Hi Julian,
In `sys/netgraph/ng_base.c', there is the following:
static int
ng_generic_msg(node_p here, item_p item, hook_p lasthook)
{
case NGM_BINARY2ASCII:
{
int bufSize = 20 * 1024; /* XXX hard coded constant */
[...]
case NGM_ASCII2BINARY:
{
int bufSize
YongHyeon PYUN wrote:
On Thu, Mar 22, 2012 at 07:08:02PM +, Joe Holden wrote:
Joe Holden wrote:
YongHyeon PYUN wrote:
On Sat, Mar 17, 2012 at 03:18:19PM +, Joe Holden wrote:
Hi guys,
I've upgraded to 9.0-REL from RC3 (I think) and the previous
workarounds I've used for msk/Yukon II
Hello,
Is there a command or log message where I can find out the bus width and PCIe
version number on which my adapter is put on?
I did take a look at pciconf and devinfo and also the dmesg logs but could not
find anything.
I know it is visible on lspci on linux systems.
Thanks
Adarsh
Thanks Chuck.
For some reason, it says . Looks like a bug. I found a bug filed
for the same reason on Linux.
Handle 0x0900, DMI type 9, 17 bytes
System Slot Information
Designation: PCI1
Type: x16
Current Usage: In Use
Length: Long
Characteristics:
On Fri, Mar 9, 2012 at 4:30 AM, Gleb Smirnoff wrote:
> The following reply was made to PR kern/165863; it has been noted by GNATS.
>
> From: Gleb Smirnoff
> To: Eric van Gyzen ,
> Eric van Gyzen , ema...@freebsd.org
> Cc: bug-follo...@freebsd.org
> Subject: kern/165863
> Date: Fri, 9 Mar 2
On Tue, Mar 27, 2012 at 09:55:45AM -0700, Adarsh Joshi wrote:
> Hello,
>
> Is there a command or log message where I can find out the bus width and PCIe
> version number on which my adapter is put on?
>
> I did take a look at pciconf and devinfo and also the dmesg logs but could
> not find anyt
I'm pretty sure that pciconf can give you this information, but you need to
use the right flags,
not to mention that you look at the correct device.
Some drivers, like ixgbe, will report this information to you when loading.
Jack
On Tue, Mar 27, 2012 at 2:08 PM, Erik Trulsson wrote:
> On Tue,
On 3/27/12 9:58 AM, Arnaud Lacombe wrote:
Hi Julian,
In `sys/netgraph/ng_base.c', there is the following:
static int
ng_generic_msg(node_p here, item_p item, hook_p lasthook)
{
case NGM_BINARY2ASCII:
{
int bufSize = 20 * 1024; /* XXX hard coded constant */
[...]
c
On Tue, Mar 27, 2012 at 2:14 PM, Jack Vogel wrote:
> I'm pretty sure that pciconf can give you this information, but you need to
> use the right flags, not to mention that you look at the correct device.
Yeah, it does:
# pciconf -lc
...
igb1@pci0:2:0:1:class=0x02 card=0x10c915d9 chip
The following reply was made to PR kern/165863; it has been noted by GNATS.
From: Ryan Stone
To: Eric van Gyzen
Cc: Gleb Smirnoff , Eric van Gyzen
, ema...@freebsd.org,
bug-follo...@freebsd.org
Subject: Re: kern/165863
Date: Tue, 27 Mar 2012 17:24:37 -0400
2012/3/9 Eric van Gyzen :
When the kernel decides to respond with a RST to an incoming TCP
segment, it uses its ack# (if valid) as the seq# of the RST. See this
in tcp_dropwithreset:
if (th->th_flags & TH_ACK) {
tcp_respond(tp, mtod(m, void *), th, m, (tcp_seq)0,
th->th_ack, TH_
Old Synopsis: gre(4) when using a tunnel source address from carp(4) doesn't
honor the MASTER/BACKUP state
New Synopsis: [gre] gre(4) when using a tunnel source address from carp(4)
doesn't honor the MASTER/BACKUP state
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-B
On Tue, Mar 27, 2012 at 04:36:59PM -0400, Ryan Stone wrote:
R> > From: Gleb Smirnoff
R> > To: Eric van Gyzen ,
R> > Eric van Gyzen , ema...@freebsd.org
R> > Cc: bug-follo...@freebsd.org
R> > Subject: kern/165863
R> > Date: Fri, 9 Mar 2012 13:20:56 +0400
R> >
R> > --BXVAT5kNtrzKuDFl
R> > C
14 matches
Mail list logo
