Re: dc(4) patch
On 19-Sep-2002 Vincent Poy wrote: I think the first card is a LinkSys PCMP200 and not the PCMP100 since the 100 is a 16bit PCMCIA and runs as a ed1 adapter in 4.6.2-RELEASE but doesn't get recognized at all under -current. I've tried both the LinkSys PCMP200 v2.0/PCMPC200 v2.0 and the NetGear FA511 Cardbus NICs but they don't get recognize under -current either. The SpeedStream SS1012 card is identical to the SMC Networks SMC8036TX card which is $US10 cheaper and comes with a lifetime warranty versus the SpeedStream 1 year warranty. However, I noticed that using either the SS1012 or the SMC8036TX which I am doing now is that there seems to be a lot of errors. Yes, it is a 200, actually, it is a PCMPC200 version 2. (The version number is down by the serial number though, not by the model number). I'm not really able to tell if I'm getting lots of errors with the SS card, but I prefer it to the LinkSys card since the SS card doesn't have a dongle and the dongle for the LinkSys card has a short in it. :) The only other cardbus NIC I have is a D-Link DFE-690TXD which uses a RealTek chip. It doesn't use a dongle, but it does periodically lock up the system. Ejecting the card unfreezes the system and I can insert it again, re-DHCP and everything is ok. A bit annoying though. :) -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: dc(4) patch
On Thursday, 19th September 2002, John Baldwin wrote:
--- if_dc.c 4 Sep 2002 18:14:17 - 1.77
+++ if_dc.c 19 Sep 2002 20:57:03 -
@@ -1366,7 +1370,8 @@
for (i = 0; i DC_TIMEOUT; i++) {
isr = CSR_READ_4(sc, DC_ISR);
if (isr DC_ISR_TX_IDLE
- (isr DC_ISR_RX_STATE) == DC_RXSTATE_STOPPED)
+ ((isr DC_ISR_RX_STATE) == DC_RXSTATE_STOPPED ||
+(isr DC_ISR_RX_STATE) == DC_RXSTATE_WAIT))
break;
DELAY(10);
}
Sadly this change is insufficient to satisfy all cards.
The PNIC 82c169 does not idle the transmitter (stays in DC_TXSTATE_WAITEND),
though the receiver goes idle OK. The Davicom DM9102 does not idle the
receiver when asked (seems to get stuck in DC_RXSTATE_ENDCHECK) though it
stops the transmitter OK. Your card does yet another thing.
I know these things through 3rd party reports, not because I have any
hardware to test.
So at this point I think the best idea is to do the checks only on Intel
hardware. At least I can verify that works on a real card I can see with
my own eyes.
Another valid option is to send me one of every dc(4) supported card,
except genuine Intel and the Macronix 98715AEC.
Stephen.
PS The Intel manual says that one should check bit 8, not the receiver
state bits, to see if the receiver is idle. That makes the test:
(isr DC_ISR_TX_IDLE isr DC_ISR_RX_READ)
It doesn't help though since the uncooperative cards don't set that bit
either. Also, I think DC_ISR_RX_READ should be spelled as DC_ISR_RX_IDLE.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: dc(4) patch
On 20-Sep-2002 Stephen McKay wrote:
On Thursday, 19th September 2002, John Baldwin wrote:
--- if_dc.c 4 Sep 2002 18:14:17 - 1.77
+++ if_dc.c 19 Sep 2002 20:57:03 -
@@ -1366,7 +1370,8 @@
for (i = 0; i DC_TIMEOUT; i++) {
isr = CSR_READ_4(sc, DC_ISR);
if (isr DC_ISR_TX_IDLE
- (isr DC_ISR_RX_STATE) == DC_RXSTATE_STOPPED)
+ ((isr DC_ISR_RX_STATE) == DC_RXSTATE_STOPPED ||
+(isr DC_ISR_RX_STATE) == DC_RXSTATE_WAIT))
break;
DELAY(10);
}
Sadly this change is insufficient to satisfy all cards.
Well. I think we can keep the check for TX going idle and just not do
the check for RX going idle. The original code basically did this until
you submitted a patch to wpaul@ that fixed a logic bug (used || above
instead of ) that effectively didn't do the RX idle check. Perhaps
we should do the same here? This would be similar to what we do in
dc_tx_underrun() where we only make sure the TX is idle.
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: dc(4) patch
On Friday, 20th September 2002, John Baldwin wrote: On 20-Sep-2002 Stephen McKay wrote: Sadly this change is insufficient to satisfy all cards. Well. I think we can keep the check for TX going idle and just not do the check for RX going idle. The original code basically did this until you submitted a patch to wpaul@ that fixed a logic bug (used || above instead of ) that effectively didn't do the RX idle check. Not quite. Davicom cards (and your card) fail to idle the receiver. PNIC cards fail to idle the transmitter. So it makes just as much sense as any other idea to check those bits only on cards that document that you have to check those bits. My documentation only covers Intel. :-) Perhaps we should do the same here? This would be similar to what we do in dc_tx_underrun() where we only make sure the TX is idle. Except that the documentation states you have to idle the TX and RX to change the full duplex bit, whereas you only have to idle the TX to change the transmit fifo threshold. And in dc_tx_underrun() only the genuine Intel chips are treated specially. Clones seem to work without idling the transmitter. Except the poor Davicom, which gets reset on every underrun (if anyone has one, and it gets underruns, you could try including it with the DC_IS_INTEL(sc) case and see what happens). Stephen. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: dc(4) patch
On 20-Sep-2002 Stephen McKay wrote: On Friday, 20th September 2002, John Baldwin wrote: On 20-Sep-2002 Stephen McKay wrote: Sadly this change is insufficient to satisfy all cards. Well. I think we can keep the check for TX going idle and just not do the check for RX going idle. The original code basically did this until you submitted a patch to wpaul@ that fixed a logic bug (used || above instead of ) that effectively didn't do the RX idle check. Not quite. Davicom cards (and your card) fail to idle the receiver. PNIC cards fail to idle the transmitter. So it makes just as much sense as any other idea to check those bits only on cards that document that you have to check those bits. My documentation only covers Intel. :-) Hmm, what if we went back then to waiting until at least one of either TX or RX went idle? Did only waiting for one actually break any 21143 cards? -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: dc(4) patch
On Friday, 20th September 2002, John Baldwin wrote: On 20-Sep-2002 Stephen McKay wrote: Not quite. Davicom cards (and your card) fail to idle the receiver. PNIC cards fail to idle the transmitter. So it makes just as much sense as any other idea to check those bits only on cards that document that you have to check those bits. My documentation only covers Intel. :-) Hmm, what if we went back then to waiting until at least one of either TX or RX went idle? Did only waiting for one actually break any 21143 cards? Well that's the funny thing. It's documented to be necessary on Intel 21143 chips, but I've never seen a non-zero delay between asking for the TX and RX to idle, and observing them to be idle. So we could probably delete the test-and-delay loop entirely. Waiting for just one of them to go idle, like we have in -stable, is just silly. Would you test for condition A and assume that means B is OK in any other part of the kernel? It's really hoping that idling the TX and RX take about the same time when there's no reason to believe that. I think the test in -stable is pretty much equivalent to having no test at all. The only solid documentation I've got demands *both* must be idle. But that's from Intel and describes the original chips. Hence, my view that we should test the bits on Intel chips and forget about it on the clones. Clones tend not to bother implementing all the limitations of the original anyway. If we find a clone that turns out to need the tests, we can enable them for that clone too. Stephen. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: dc(4) patch
On Fri, 20 Sep 2002, John Baldwin wrote: On 19-Sep-2002 Vincent Poy wrote: I think the first card is a LinkSys PCMP200 and not the PCMP100 since the 100 is a 16bit PCMCIA and runs as a ed1 adapter in 4.6.2-RELEASE but doesn't get recognized at all under -current. I've tried both the LinkSys PCMP200 v2.0/PCMPC200 v2.0 and the NetGear FA511 Cardbus NICs but they don't get recognize under -current either. The SpeedStream SS1012 card is identical to the SMC Networks SMC8036TX card which is $US10 cheaper and comes with a lifetime warranty versus the SpeedStream 1 year warranty. However, I noticed that using either the SS1012 or the SMC8036TX which I am doing now is that there seems to be a lot of errors. Yes, it is a 200, actually, it is a PCMPC200 version 2. (The version number is down by the serial number though, not by the model number). I'm not really able to tell if I'm getting lots of errors with the SS card, but I prefer it to the LinkSys card since the SS card doesn't have a dongle and the dongle for the LinkSys card has a short in it. :) The only other cardbus NIC I have is a D-Link DFE-690TXD which uses a RealTek chip. It doesn't use a dongle, but it does periodically lock up the system. Ejecting the card unfreezes the system and I can insert it again, re-DHCP and everything is ok. A bit annoying though. :) Interesting. I have tried both the PCM200 v2.0 (dongleless) and PCMPC200 v2.0 and both failed card initialization since it can't figure out who made the card. Perhaps, it's using a different chip than the one you have since I just bought it during the past few weeks. Ofcourse, I tried a 3Com 3CXFEM656C which works fine on a Dell Inspiron 8200 but not a IBM ThinkPad 770Z. Tried a Intel Pro100S CardBusII which uses the fxp driver even but no luck either. Wonder if it's because of the combo modem that's the issue. Haven't tried the Intel on the Dell yet but it seems Warner got Intel cards working as well. The D-Link was the next card I was going to try but thanks for the information on the RealTek. The Belkin seems to use the same RealTek chip too and doesn't work for me at all. Any other cards you have tried that works and actually do close to full 100Mbps wire speeds? :) Cheers, Vince - [EMAIL PROTECTED] - Vice President __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: dc(4) patch
Hi John, See the patch I've submitted last week or previous week. Topic was uncomitted dc0 PR's. I had a patch for this there. Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 061 826 93 00: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: dc(4) patch
Hi John, Your patch looks correct ! Thanks to finding this out. Can you commit this or do you wait for McKay ? Or should I ;-) ? Ps: the automatic TX underrun recovery still needs to be comitted. Without it no cvsup survives here. Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 061 826 93 00: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: dc(4) patch
On 19-Sep-2002 Martin Blapp wrote: Hi John, See the patch I've submitted last week or previous week. Topic was uncomitted dc0 PR's. I had a patch for this there. IIRC, yours completely disabled the check. It would seem to make good sense to still try to force the card idle before dinking with DC_NETCFG, but to allow that some cards may be reporting a status of WAIT instead of STOPPED when the receiver is idle. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: dc(4) patch
On Thu, 19 Sep 2002, John Baldwin wrote:
A while ago I started having problems with a dc(4) cardbus card that
I hadn't had before. Lots of failures to force tx and rx to idle
state resulting in the card eventually hanging under load and
basically being worthless until I ejected it and reinserted it.
ifconfig up/down, etc. didn't help. So I bought a new dc(4) cardbus
card and it had the same problems. First card:
dc0: Abocom FE2500 10/100BaseTX port 0x1100-0x11ff mem 0x88002000-0x880023ff irq
11 at device 0.0
on cardbus0
(really a LinkSys PCMP100 or some such)
Second card:
dc0: Accton EN2242 MiniPCI 10/100BaseTX port 0x1100-0x11ff mem
0x88002000-0x880023ff irq 11 at
device 0.0 on cardbus0
(really a SpeedStream SS1012). The patch below fixed the hangs
on both cards:
--- if_dc.c 4 Sep 2002 18:14:17 - 1.77
+++ if_dc.c 19 Sep 2002 20:57:03 -
@@ -1366,7 +1370,8 @@
for (i = 0; i DC_TIMEOUT; i++) {
isr = CSR_READ_4(sc, DC_ISR);
if (isr DC_ISR_TX_IDLE
- (isr DC_ISR_RX_STATE) == DC_RXSTATE_STOPPED)
+ ((isr DC_ISR_RX_STATE) == DC_RXSTATE_STOPPED ||
+(isr DC_ISR_RX_STATE) == DC_RXSTATE_WAIT))
break;
DELAY(10);
}
The automatic TX underrun recovery stuff didn't make a bit of difference
for the SpeedStream card FWIW. Also, unlike one of the PR's which claimed
that the SpeedStream SS1020 (PCI adapter rather than cardbus card), the
dc(4) driver read the right MAC address just fine w/o the need for any
changes.
I think the first card is a LinkSys PCMP200 and not the PCMP100
since the 100 is a 16bit PCMCIA and runs as a ed1 adapter in 4.6.2-RELEASE
but doesn't get recognized at all under -current. I've tried both the
LinkSys PCMP200 v2.0/PCMPC200 v2.0 and the NetGear FA511 Cardbus NICs but
they don't get recognize under -current either. The SpeedStream SS1012
card is identical to the SMC Networks SMC8036TX card which is $US10
cheaper and comes with a lifetime warranty versus the SpeedStream 1 year
warranty. However, I noticed that using either the SS1012 or the
SMC8036TX which I am doing now is that there seems to be a lot of errors.
root@bigbang [3:36pm][/usr/home/vince] netstat -s
tcp:
505575 packets sent
120454 data packets (143749591 bytes)
76 data packets (34453 bytes) retransmitted
6 data packets unnecessarily retransmitted
0 resends initiated by MTU discovery
276069 ack-only packets (1497 delayed)
0 URG only packets
0 window probe packets
106651 window update packets
2325 control packets
678552 packets received
67126 acks (for 143703608 bytes)
623 duplicate acks
0 acks for unsent data
612664 packets (686204656 bytes) received in-sequence
67 completely duplicate packets (48111 bytes)
0 old duplicate packets
19 packets with some dup. data (3318 bytes duped)
1262 out-of-order packets (1474923 bytes)
0 packets (0 bytes) of data after window
0 window probes
367 window update packets
8 packets received after close
0 discarded for bad checksums
0 discarded for bad header offset fields
0 discarded because packet too short
1823 connection requests
307 connection accepts
6 bad connection attempts
0 listen queue overflows
557 connections established (including accepts)
2305 connections closed (including 51 drops)
38 connections updated cached RTT on close
38 connections updated cached RTT variance on close
13 connections updated cached ssthresh on close
1564 embryonic connections dropped
66488 segments updated rtt (of 65063 attempts)
66 retransmit timeouts
1 connection dropped by rexmit timeout
0 persist timeouts
0 connections dropped by persist timeout
23 keepalive timeouts
23 keepalive probes sent
0 connections dropped by keepalive
45309 correct ACK header predictions
606682 correct data packet header predictions
309 syncache entries added
0 retransmitted
2 dupsyn
0 dropped
307 completed
0 bucket overflow
0 cache overflow
2 reset
0 stale
0 aborted
0 badack
0 unreach
0 zone failures
0 cookies sent
0 cookies
