Re: Intel 82550 Pro/100 Ethernet and Microcode
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 fragmented UDP datagrams. Ok, your final patch workes as expected, all my fxp's can load microcode and run without hangs od SCB timeouts. I think the PR's kern/103332 and kern/118909 can be closed now. Thank you again for investigate in this problem. Andreas Longwitz ___ 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"
Netgraph message size limitation.
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 = 2000; /* XXX hard coded constant */
I put on the side the reasoning behind archie@ bump of one value and
not the other 12 years ago. What I would like to know is why use
harcoded, undocumented, limits. It seems to me that there is no way
the code can do anything clever at this point wrt. size of the data
coming in or out. All the allocation and buffer management should be
done by the parser. If my type specify a 512 32bits array, I should be
to pass this array. Thought ?
Thanks,
- Arnaud
___
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"
Re: msk/Yukon issues since 9.0-REL
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 problems don't seem to work anymore: rc.conf: ifconfig_msk0="inet 192.168.201.2/30 -lro -tso -vlanhwfilter -vlanhwtag" msk(4) does not support VLAN hardware filter and LRO. However I don't understand how this affects stability of driver. pciconf: mskc0@pci0:7:0:0: class=0x02 card=0x81e6104d chip=0x435111ab rev=0x15 hdr=0x00 vendor = 'Marvell Technology Group Ltd.' device = '88E8036 PCI-E Fast Ethernet Controller' class = network subclass = ethernet I seem to get the usual error: msk0: watchdog timeout msk0: prefetch unit stuck? msk0: initialization failed: no memory for Rx buffers There was a related change after 9.0-RELEASE. The change already merged to stable/9(r229874) So would you try latest stable/9 or apply the change to 9.0-RELEASE? http://svnweb.freebsd.org/base/stable/9/sys/dev/msk/if_msk.c?r1=229524&r2=229874&view=patch Well that's cute reboot during boot, no panic or errors on the console ... MSI(-X) is disabled but it doesn't seem to make any difference Is there anything I can try to either debug or "fix" it? If you've upgraded from somewhat old FreeBSD releases, make sure to cold boot your box(i.e. completely remove power cord for several minutes before booting). Thanks, J Ok so after removing sound from GENERIC it boots but the problem still Not sure how audio devices can affect msk(4). Unrelated, when the HDA device was probed it caused a reset/panic - but nothing to do with msk This wasn't present in RC3 though, hence my comment about regressions occurs - the flags I used before did work (whether some didn't have any msk(4) had a long standing bug for some Yukon controllers that use 88E1149 PHY. The bug showed various problems depending on PHY configuration. See r19 for more details. Due to unknown reason GPHY configuration is preserved until it's cold-booted. effect I don't know, but once I found a combination that prevented the problem I left it at that) Rather a concerning amount of regressions in 9... Thanks, J ___ 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" ___ 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"
bus width and PCIe version
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 This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message. ___ 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"
RE: bus width and PCIe version
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: 3.3 V is provided PME signal is supported Bus Address: :01:00.0 Adarsh -Original Message- From: Chuck Swiger [mailto:cswi...@mac.com] Sent: Tuesday, March 27, 2012 10:31 AM To: Adarsh Joshi Cc: freebsd-net@freebsd.org Subject: Re: bus width and PCIe version On Mar 27, 2012, at 9:55 AM, Adarsh Joshi wrote: > 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? There's a dmidecode utility in the ports which should be able to figure out that info, IIRC. Regards, -- -Chuck This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message. ___ 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"
Re: kern/165863
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 2012 13:20:56 +0400 > > --BXVAT5kNtrzKuDFl > Content-Type: text/plain; charset=koi8-r > Content-Disposition: inline > > Hello, Eric and Ed. > > Can you look at this patch? I decided to utilize newer callout API, > that allows to delegate lock retrieval to the callout subsystem, and > this makes things simplier. Hope that should work. > > Patch is against head. > > Eric, can you please send me your test programs, that you use to > reproduce the bug? I tested this patch today on head and 8.2-RELEASE. I was unable to reproduce any crashes, whereas before I could crash the system within minutes. However it appears that in6_lltable_prefix_free is similarly broken. The only saving grace is that there does not appear to be a code path that can actually call it. ___ 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"
Re: bus width and PCIe version
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 anything. > > I know it is visible on lspci on linux systems. You can use lspci on FreeBSD as well. It is included in the sysutils/pciutils port. -- Erik Trulsson ertr1...@student.uu.se ___ 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"
Re: bus width and PCIe version
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, 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 anything. > > > > I know it is visible on lspci on linux systems. > > > You can use lspci on FreeBSD as well. It is included in the > sysutils/pciutils port. > > > > -- > > Erik Trulsson > ertr1...@student.uu.se > ___ > 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" > ___ 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"
Re: Netgraph message size limitation.
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 */
[...]
case NGM_ASCII2BINARY:
{
int bufSize = 2000; /* XXX hard coded constant */
I put on the side the reasoning behind archie@ bump of one value and
not the other 12 years ago. What I would like to know is why use
harcoded, undocumented, limits. It seems to me that there is no way
the code can do anything clever at this point wrt. size of the data
coming in or out. All the allocation and buffer management should be
done by the parser. If my type specify a 512 32bits array, I should be
to pass this array. Thought ?
I have no real thoughts because Archie did the parser and I didn't
really touch it.
However given that Netgraph was written for a specific set of jobs and
that since then
people seem to have found all sorts of other things to do with it, it
is quite possible that
we should revisit these limits.
regardless, they should probably be in the documentation..
I hope to get back to BSD work one of these years.. Until then,
"patches accepted"..
Thanks,
- Arnaud
___
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"
Re: bus width and PCIe version
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=0x10c98086 rev=0x01 hdr=0x00 cap 01[40] = powerspec 3 supports D0 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit, vector masks cap 11[70] = MSI-X supports 10 messages in map 0x1c enabled cap 10[a0] = PCI-Express 2 endpoint max data 128(512) link x4(x4) ... mps1@pci0:3:0:0:class=0x010700 card=0x040015d9 chip=0x00721000 rev=0x03 hdr=0x00 vendor = 'LSI Logic / Symbios Logic' device = 'SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon]' class = mass storage subclass = SAS cap 01[50] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 10[68] = PCI-Express 2 endpoint max data 128(4096) link x8(x8) cap 03[d0] = VPD cap 05[a8] = MSI supports 1 message, 64 bit cap 11[c0] = MSI-X supports 15 messages in map 0x14 enabled ... -- Freddie Cash fjwc...@gmail.com ___ 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"
Re: kern/165863
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 : > On 03/09/12 03:20, Gleb Smirnoff wrote: >> >> =A0 Hello, Eric and Ed. >> >> =A0 Can you look at this patch? I decided to utilize newer callout API, >> that allows to delegate lock retrieval to the callout subsystem, and >> this makes things simplier. Hope that should work. >> >> =A0 Patch is against head. > > > Doesn't arptimer() still need to acquire the if_afdata_lock in order to f= ree > the entry in the normal case (when the llentry is still in the hash bucke= t > list)? Oops, on reviewing the code I believe that this is correct. My test case wouldn't have had arp entries timing out so I wouldn't have hit this case. I'll try to come up with a test case for this. Unfortunately it's not as quite as simple just acquiring if_afdata_lock because of lock ordering problems. I think that we'll have to revert the usage of callout_init_rw so that arptimer can acquire the if_afdata_lock before acquiring the lock LLE_LOCK. ___ 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"
seq# of RST in tcp_dropwithreset
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_RST);
} else {
if (th->th_flags & TH_SYN)
tlen++;
tcp_respond(tp, mtod(m, void *), th, m, th->th_seq+tlen,
(tcp_seq)0, TH_RST|TH_ACK);
}
This can have some unexpected results. I observed this on a link with
a very high delay (B is FreeBSD, A could be anything).
1. There is a segment in flight from A to B. The ack# is X (all tx
from B to A is up to date and acknowledged).
2. socket is closed on B. B sends a FIN with seq# X.
3. The segment from A arrives and elicits a RST from B. The seq# of
this RST will again be X. A receives the FIN and then the RST with
identical sequence numbers. The situation resolves itself eventually,
when A retransmits and the retransmitted segment ACKs the FIN too and
so the next time around B sends a RST with the "correct" seq# (one
after the FIN).
If there is a local tcpcb for the connection with state >=
ESTABLISHED, wouldn't it be more accurate to use its snd_max as the
seq# of the RST?
Regards,
Navdeep
___
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"
Re: kern/166462: [gre] gre(4) when using a tunnel source address from carp(4) doesn't honor the MASTER/BACKUP state
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-By: linimon Responsible-Changed-When: Wed Mar 28 05:58:53 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=166462 ___ 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"
Re: kern/165863
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> > Content-Type: text/plain; charset=koi8-r R> > Content-Disposition: inline R> > R> > Hello, Eric and Ed. R> > R> > Can you look at this patch? I decided to utilize newer callout API, R> > that allows to delegate lock retrieval to the callout subsystem, and R> > this makes things simplier. Hope that should work. R> > R> > Patch is against head. R> > R> > Eric, can you please send me your test programs, that you use to R> > reproduce the bug? R> R> I tested this patch today on head and 8.2-RELEASE. I was unable to R> reproduce any crashes, whereas before I could crash the system within R> minutes. R> R> However it appears that in6_lltable_prefix_free is similarly broken. R> The only saving grace is that there does not appear to be a code path R> that can actually call it. Well, the patch I sent before definitely has problems. -- Totus tuus, Glebius. ___ 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"
