Re: re0: Unknown H/W revision: 0x28000000 device_attach: re0 attach returned 6
On Sun, Nov 30, 2008 at 11:18 AM, Andrew Tulloch <[EMAIL PROTECTED]> wrote: > I've just installed from the FreeBSD 7.1-BETA1 iso and get the > following when the re driver attempts to attach to the two onboard > NICs found on a Gigabyte GA-EX58-UD5 motherboard: > > re0: Ethernet> port 0x9e00-0x9eff mem > 0xfd3ff000-0xfd3f,0xfd3f8000-0xfd3fbfff irq 16 at device 0.0 on > pci8 > re0: Chip rev. 0x2800 It's 8168D, driver configuration should be same as 8168CP Best Regards, sephe -- Live Free or Die ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: vge driver does not work on a VIA EPIA EN12000EG
I tried the bootonly from: ftp://ftp.freebsd.org/pub/FreeBSD/ISO-IMAGES-i386/7.1 That didnt make any difference, any idea, anybody? Mam Mam Ruoc wrote: Pyun YongHyeon wrote: I think there was a similar report. Would you show me the output of "pciconf -lcv"? I'll try, unsure how to manage. Have tried to use Fixit in sysinstall to create a new shell, but Ghost-something did not have lspci, where can I find freebsd livecd? For a long time I wanted to clean up vge(4). Unfortunately the PCI NIC I have seem to broken so I guess it's hard to complete the cleanup. You can get a WIP(now stalled) in the following URL. Note, the driver may be chatty due to various debugging statements and it may not work at all for your controller. http://people.freebsd.org/~yongari/vge/if_vge.c http://people.freebsd.org/~yongari/vge/if_vgereg.h http://people.freebsd.org/~yongari/vge/if_vgevar.h As I said in the other mail, unsure how to do this because I actually ned the fix because pfSense 1.2.1RC2 have this problem and made my VIA useless as a firewall. Mam ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Window updates
David Malone wrote:
I've got an example extract tcpdump of this at the end of the mail
- here 6 ACKs are sent, 5 of which are pure window updates and
several are 2us apart!
I think the easy option is to delete the code that generates explicit
window updates if the window moves by 2*MSS. We then should be doing
something similar to Linux. The other easy alternative would be to
add a sysclt that lets us generate an window update every N*MSS and
by default set it to something big, like 10 or 100. That should
effectively eliminate the updates during bulk data transfer, but
may still generate some window updates after a loss.
The main problem of the pure window update test in tcp_output() is
its complete ignorance of delayed ACKs. Second is the strict 4.4BSD
adherence to sending an update for every window increase of >= 2*MSS.
The third issue of sending a slew of window updates after having
received a FIN (telling us the other end won't ever send more data)
I have already fixed some moons ago.
In my new-tcp work I've come across the window update logic some time
ago and backchecked with relevant RFCs and other implementations.
Attached is a compiling but otherwise untested backport of the new logic.
--
Andre
Normal ACKing for driving congestion control shouldn't be impacted
by either of these suggested changes.
David.
1227622713.276609 172.16.2.2.5002 > 172.16.1.51.39077: . ack 144097745 win 40798
(DF)
1227622713.276611 172.16.2.2.5002 > 172.16.1.51.39077: . ack 144097745 win 40830
(DF)
1227622713.276613 172.16.2.2.5002 > 172.16.1.51.39077: . ack 144097745 win 40862
(DF)
1227622713.276615 172.16.2.2.5002 > 172.16.1.51.39077: . ack 144097745 win 40894
(DF)
1227622713.276852 172.16.2.2.5002 > 172.16.1.51.39077: . ack 144097745 win 40926
(DF)
1227622713.276855 172.16.2.2.5002 > 172.16.1.51.39077: . ack 144097745 win 40958
(DF)
1227622713.296585 172.16.2.2.5002 > 172.16.1.51.39077: . ack 144100641 win 40956
(DF)
Index: tcp_output.c
===
RCS file: /home/ncvs/src/sys/netinet/tcp_output.c,v
retrieving revision 1.158
diff -u -p -r1.158 tcp_output.c
--- tcp_output.c27 Nov 2008 13:19:42 - 1.158
+++ tcp_output.c30 Nov 2008 22:58:46 -
@@ -539,14 +539,32 @@ after_sack_rexmit:
}
/*
-* Compare available window to amount of window
-* known to peer (as advertised window less
-* next expected input). If the difference is at least two
-* max size segments, or at least 50% of the maximum possible
-* window, then want to send a window update to peer.
+* Compare available window to amount of window known to peer
+* (as advertised window less next expected input) and decide
+* if we have to send a pure window update segment.
+*
+* When a delayed ACK is scheduled, do nothing. It will update
+* the window anyway in a few milliseconds.
+*
+* If the receive socket buffer has less than 1/4 of space
+* available and if the difference is at least two max size
+* segments, send an immediate window update to peer.
+*
+* Otherwise if the difference is 1/8 (or more) of the receive
+* socket buffer, or at least 1/2 of the maximum possible window,
+* then we send a window update too.
+*
* Skip this if the connection is in T/TCP half-open state.
* Don't send pure window updates when the peer has closed
* the connection and won't ever send more data.
+*
+* See RFC793, Section 3.7, page 43, Window Management Suggestions
+* See RFC1122: Section 4.2.3.3, When to Send a Window Update
+*
+* Note: We are less aggressive with sending window update than
+* recommended in RFC1122. This is fine with todays large socket
+* buffers and will not stall the peer. In addition we piggy back
+* window update on regular ACKs and sends.
*/
if (recwin > 0 && !(tp->t_flags & TF_NEEDSYN) &&
!TCPS_HAVERCVDFIN(tp->t_state)) {
@@ -554,14 +572,24 @@ after_sack_rexmit:
* "adv" is the amount we can increase the window,
* taking into account that we are limited by
* TCP_MAXWIN << tp->rcv_scale.
+*
+* NB: adv must be equal or larger than the smallest
+* unscaled window increment.
*/
long adv = min(recwin, (long)TCP_MAXWIN << tp->rcv_scale) -
(tp->rcv_adv - tp->rcv_nxt);
- if (adv >= (long) (2 * tp->t_maxseg))
- goto send;
- if (2 * adv >= (long) so->so_rcv.sb_hiwat)
- goto send;
+ if (!(tp->t_flags & TF_DELACK) &&
+ adv >= (long)0x1 << tp->rcv_scale) {
+ if (recwin <= (long)(so-
Re: FreeBSD Window updates
Andre Oppermann wrote:
David Malone wrote:
I've got an example extract tcpdump of this at the end of the mail
- here 6 ACKs are sent, 5 of which are pure window updates and
several are 2us apart!
I think the easy option is to delete the code that generates explicit
window updates if the window moves by 2*MSS. We then should be doing
something similar to Linux. The other easy alternative would be to
add a sysclt that lets us generate an window update every N*MSS and
by default set it to something big, like 10 or 100. That should
effectively eliminate the updates during bulk data transfer, but
may still generate some window updates after a loss.
The main problem of the pure window update test in tcp_output() is
its complete ignorance of delayed ACKs. Second is the strict 4.4BSD
adherence to sending an update for every window increase of >= 2*MSS.
The third issue of sending a slew of window updates after having
received a FIN (telling us the other end won't ever send more data)
I have already fixed some moons ago.
In my new-tcp work I've come across the window update logic some time
ago and backchecked with relevant RFCs and other implementations.
Attached is a compiling but otherwise untested backport of the new logic.
Slightly improved version attached.
--
Andre
Index: tcp_output.c
===
RCS file: /home/ncvs/src/sys/netinet/tcp_output.c,v
retrieving revision 1.158
diff -u -p -r1.158 tcp_output.c
--- tcp_output.c27 Nov 2008 13:19:42 - 1.158
+++ tcp_output.c30 Nov 2008 23:16:30 -
@@ -539,29 +539,56 @@ after_sack_rexmit:
}
/*
-* Compare available window to amount of window
-* known to peer (as advertised window less
-* next expected input). If the difference is at least two
-* max size segments, or at least 50% of the maximum possible
-* window, then want to send a window update to peer.
+* Compare available window to amount of window known to peer
+* (as advertised window less next expected input) and decide
+* if we have to send a pure window update segment.
+*
+* When a delayed ACK is scheduled, do nothing. It will update
+* the window anyway in a few milliseconds.
+*
+* If the receive socket buffer has less than 1/4 of space
+* available and if the difference is at least two max size
+* segments, send an immediate window update to peer.
+*
+* Otherwise if the difference is 1/8 (or more) of the receive
+* socket buffer, or at least 1/2 of the maximum possible window,
+* then we send a window update too.
+*
* Skip this if the connection is in T/TCP half-open state.
* Don't send pure window updates when the peer has closed
* the connection and won't ever send more data.
+*
+* See RFC793, Section 3.7, page 43, Window Management Suggestions
+* See RFC1122: Section 4.2.3.3, When to Send a Window Update
+*
+* Note: We are less aggressive with sending window update than
+* recommended in RFC1122. This is fine with todays large socket
+* buffers and will not stall the peer. In addition we piggy back
+* window update on regular ACKs and sends.
*/
- if (recwin > 0 && !(tp->t_flags & TF_NEEDSYN) &&
- !TCPS_HAVERCVDFIN(tp->t_state)) {
+ if (recwin > 0 && !(tp->t_flags & TF_DELACK) &&
+ !(tp->t_flags & TF_NEEDSYN) && !TCPS_HAVERCVDFIN(tp->t_state)) {
/*
* "adv" is the amount we can increase the window,
* taking into account that we are limited by
* TCP_MAXWIN << tp->rcv_scale.
+*
+* NB: adv must be equal or larger than the smallest
+* unscaled window increment.
*/
long adv = min(recwin, (long)TCP_MAXWIN << tp->rcv_scale) -
(tp->rcv_adv - tp->rcv_nxt);
- if (adv >= (long) (2 * tp->t_maxseg))
- goto send;
- if (2 * adv >= (long) so->so_rcv.sb_hiwat)
- goto send;
+ if (adv >= (long)0x1 << tp->rcv_scale) {
+ if (recwin <= (long)(so->so_rcv.sb_hiwat / 4) &&
+ adv >= (long)(2 * tp->t_maxseg))
+ goto send;
+ if (adv >= (long)(so->so_rcv.sb_hiwat / 8) &&
+ adv >= (long)tp->t_maxseg)
+ goto send;
+ if (2 * adv >= (long)so->so_rcv.sb_hiwat)
+ goto send;
+ }
}
/*
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to
panic from ifconfig in IFAREF
I got this panic on HEAD when trying to configure an IP address on an interface immediately after boot: > Fatal trap 9: general protection fault while in kernel mode > ccpuid = 4; xapic id = 04 > ginstruction pointer= 0x8:0x80494b42 > bstack pointer = 0x10:0x20938490 > 0frame pointe:r = 0x10:0x20938610 > code segment = base 0x0, limit 0xf, type 0x1b > link state changed to DOWN > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process = 1073 (ifconfig) > [thread pid 1073 tid 100250 ] > Stopped at strlen+0x2: cmpb$0,(%rdi) > db> wh > Tracing pid 1073 tid 100250 td 0xff00077ab720 > strlen() at strlen+0x2 > vsnprintf() at vsnprintf+0x2e > panic() at panic+0x1d8 > _mtx_lock_flags() at _mtx_lock_flags+0xd9 > rtrequest1_fib() at rtrequest1_fib+0x3e6 > rtinit() at rtinit+0x213 > in_ifinit() at in_ifinit+0x2bd > in_control() at in_control+0xe95 > ifioctl() at ifioctl+0xfa > kern_ioctl() at kern_ioctl+0x92 > ioctl() at ioctl+0xfd > syscall() at syscall+0x1bc > Xfast_syscall() at Xfast_syscall+0xab > --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x140a69dfc, rsp = 0x7fffe588, rbp = 0x7fffef7c --- > __func__.6541+0xfcb:mtx_lock() of spin mutex %s @ %s:%d The panic is here: /* * Note that we now have a reference to the ifa. * This moved from below so that rnh->rnh_addaddr() can * examine the ifa and ifa->ifa_ifp if it so desires. */ IFAREF(ifa); (net/route.c:1081) Kris ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: re0: Unknown H/W revision: 0x28000000 device_attach: re0 attach returned 6
On Sun, Nov 30, 2008 at 03:18:41AM +, Andrew Tulloch wrote:
> I've just installed from the FreeBSD 7.1-BETA1 iso and get the
> following when the re driver attempts to attach to the two onboard
> NICs found on a Gigabyte GA-EX58-UD5 motherboard:
>
> re0: Ethernet> port 0x9e00-0x9eff mem
> 0xfd3ff000-0xfd3f,0xfd3f8000-0xfd3fbfff irq 16 at device 0.0 on
> pci8
> re0: Chip rev. 0x2800
> re0: MAC rev. 0x0010
> re0: Unknown H/W revision: 0x2800
> device_attach: re0 attach returned 6
> pcib9: irq 17 at device 28.5 on pci0
> pci9: on pcib9
> re1: Ethernet> port 0x8e00-0x8eff mem
> 0xfd1ff000-0xfd1f,0xfd1f8000-0xfd1fbfff irq 17 at device 0.0 on
> pci9
> re1: Chip rev. 0x2800
> re1: MAC rev. 0x0010
> re1: Unknown H/W revision: 0x2800
> device_attach: re1 attach returned 6
>
> pciconf -lvc extract:
> [EMAIL PROTECTED]:8:0:0: class=0x02 card=0xe0001458 chip=0x816810ec
> rev=0x03 hdr=0x00
> vendor = 'Realtek Semiconductor'
> device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC'
> class = network
> subclass = ethernet
> cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0
> cap 05[50] = MSI supports 1 message, 64 bit
> cap 10[70] = PCI-Express 2 endpoint IRQ 0
> cap 11[ac] = MSI-X supports 4 messages in map 0x20
> cap 03[cc] = VPD
> [EMAIL PROTECTED]:9:0:0: class=0x02 card=0xe0001458 chip=0x816810ec
> rev=0x03 hdr=0x00
> vendor = 'Realtek Semiconductor'
> device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC'
> class = network
> subclass = ethernet
> cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0
> cap 05[50] = MSI supports 1 message, 64 bit
> cap 10[70] = PCI-Express 2 endpoint IRQ 0
> cap 11[ac] = MSI-X supports 4 messages in map 0x20
> cap 03[cc] = VPD
>
>
> Is there any simple patch I can apply to get the driver to attach,
> assuming it should work?
>
This controller seems to support MSI-X with 4 messages.
Unfortunately previous PCIe controllers from RealTek were notorious
for MSI issues so it's hard to know this revision really works with
MSI-X. I guess it was added to support RSS(receive-side scaling of
MS NDIS 6.0).
As sephe said if the controller configuration is the same as 8168C
family, the attached patch would make re(4) work as expected.
--
Regards,
Pyun YongHyeon
Index: sys/dev/re/if_re.c
===
--- sys/dev/re/if_re.c (revision 185504)
+++ sys/dev/re/if_re.c (working copy)
@@ -172,7 +172,7 @@
{ RT_VENDORID, RT_DEVICEID_8101E, 0,
"RealTek 8101E/8102E/8102EL PCIe 10/100baseTX" },
{ RT_VENDORID, RT_DEVICEID_8168, 0,
- "RealTek 8168/8168B/8168C/8168CP/8111B/8111C/8111CP PCIe "
+ "RealTek 8168/8168B/8168C/8168CP/8168D/8111B/8111C/8111CP PCIe "
"Gigabit Ethernet" },
{ RT_VENDORID, RT_DEVICEID_8169, 0,
"RealTek 8169/8169S/8169SB(L)/8110S/8110SB(L) Gigabit Ethernet" },
@@ -1225,6 +1225,7 @@
case RL_HWREV_8168C:
case RL_HWREV_8168C_SPIN2:
case RL_HWREV_8168CP:
+ case RL_HWREV_8168D:
sc->rl_flags |= RL_FLAG_INVMAR | RL_FLAG_PHYWAKE |
RL_FLAG_PAR | RL_FLAG_DESCV2 | RL_FLAG_MACSTAT;
/*
Index: sys/pci/if_rlreg.h
===
--- sys/pci/if_rlreg.h (revision 185504)
+++ sys/pci/if_rlreg.h (working copy)
@@ -157,6 +157,7 @@
#define RL_HWREV_8169_8110SB 0x1000
#define RL_HWREV_8169_8110SC 0x1800
#define RL_HWREV_8102EL0x2480
+#define RL_HWREV_8168D 0x2800
#define RL_HWREV_8168_SPIN10x3000
#define RL_HWREV_8100E 0x3080
#define RL_HWREV_8101E 0x3400
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
