From kolhapur@mah.nic.in Thu Jun 3 06:57:13 1999
Date: Thu Jun 3 06:57:13 1999
From: NIC, Kolhapur kolhapur@mah.nic.in
Subject: Linux Driver for Ethernet Express Card.
This is a multi-part message in MIME format.
------=_NextPart_000_0005_01BEADDC.D40106C0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Dear Sir,
We are having Intel 8255x-based PCI Ethernet Adapter (10/100) =
connected
in Redhat Linux 5.2 on Intel Pentium II. Along with this card we are =
using another=20
Ethernet Card DEC 21041. In linux only eth0 is recognised ( DEC 21041 =
E-net Card).
But eth1 is not detected (which is 8255x-based PCI Ethernet Adapter.
We are requestng to provide a solution with Driver software for =
Redhat Linux 5.2
for Intel 8255x-based PCI ethrnet Card.
With regards,
District Informatics Officer,
National Informatics Centre,
Kolhapur, STATE Maharashtra
INDIA.
------=_NextPart_000_0005_01BEADDC.D40106C0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Dear Sir,
We are having =
Intel=20
8255x-based PCI Ethernet Adapter (10/100) connected
in Redhat Linux 5.2 on Intel Pentium II. Along with =
this card=20
we are using another
Ethernet Card DEC 21041. In linux only eth0 is =
recognised (=20
DEC 21041 E-net Card).
But eth1 is not detected (which is 8255x-based PCI =
Ethernet=20
Adapter.
We are =
requestng to=20
provide a solution with Driver software for Redhat Linux =
5.2
for Intel 8255x-based PCI ethrnet Card.
With regards,
District Informatics Officer,
National Informatics Centre,
Kolhapur, STATE Maharashtra
INDIA.
------=_NextPart_000_0005_01BEADDC.D40106C0--
From Mark@Eraze.nl Thu Jun 3 11:26:14 1999
Date: Thu Jun 3 11:26:14 1999
From: Mark Raming Mark@Eraze.nl
Subject: Intel EtherExpress Proo 100B
This is a multi-part message in MIME format.
------=_NextPart_000_0015_01BEADE6.262D2A10
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_000E_01BEADE6.25AE5D20"
------=_NextPart_000_000E_01BEADE6.25AE5D20
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
I have a Pentium 90 system with two Intel EtherExpress 100B ethernet
adapters. I use the system as a router. Regularly, I get the following
error messages (once a second or so) on the console:
eth1: Transmit timed out: status 7048 0000 at 2476/2491 command 000ch000
eth1: Trying to restart the transmitter...
After that, this interface is dead. This also happens for the eth0 device.
Now, I guess you want relevant system information.
I'll start with the kernel version: 2.0.36
The eepro100.c driver version is: v1.08 5/3/99
Initially, I was using the v0.99B 4/7/98 version which had the same
problem.
What else is there to say: I'll give you the output of the eepro-diag
program while both cards are in ok state:
eepro-diag -a -v -e -f -m
eepro100-diag.c:v0.07 2/25/98 Donald Becker (becker@cesdis.gsfc.nasa.gov)
Index #1: Found a Intel 82557 EtherExpressPro100B adapter at 0x4000.
i82557 chip registers at 0x4000:
00000050 02e09904 00000000 00080002 18250081 00000600
No interrupt sources are pending.
The transmit unit state is 'Suspended'.
The receive unit state is 'Ready'.
Intel EtherExpress Pro 10/100 EEPROM contents:
Station address 00:90:27:34:93:1E.
Receiver lock-up bug exists. (The driver work-around *is* implemented.)
Board assembly 689661-004, Physical connectors present: RJ45
Primary interface chip i82555 PHY #1.
MII PHY #1 transceiver registers:
3000 782d 02a8 0150 05e1 0081 0000 ffff
ffff ffff ffff ffff ffff ffff ffff ffff
0a02 0000 0001 0000 0000 0000 0000 0000
0000 0000 3ecb 0000 ffff ffff ffff ffff.
MII PHY #1 transceiver registers:
3000 782d 02a8 0150 05e1 0081 0000 ffff
ffff ffff ffff ffff ffff ffff ffff ffff
0a02 0000 0001 0000 0000 0000 0000 0000
0000 0000 3ecb 0000 ffff ffff ffff ffff.
Basic mode control register 0x3000: Auto-negotiation enabled.
Basic mode status register 0x782d ... 782d.
Link status: established.
Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
Able to perform Auto-negotiation, negotiation complete.
Vendor ID is 00:aa:00:--:--:--, model 21 rev. 0.
No specific information is known about this transceiver type.
I'm advertising 05e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD
10baseT
Advertising no additional info pages.
IEEE 802.3 CSMA/CD protocol.
Link partner capability is 0081: 100baseTx.
Negotiation did not complete.
Index #2: Found a Intel 82557 EtherExpressPro100B adapter at 0x4020.
i82557 chip registers at 0x4020:
00000050 02e0910c 00000000 00080002 182540a1 00000600
No interrupt sources are pending.
The transmit unit state is 'Suspended'.
The receive unit state is 'Ready'.
Intel EtherExpress Pro 10/100 EEPROM contents:
Station address 00:90:27:34:98:52.
Receiver lock-up bug exists. (The driver work-around *is* implemented.)
Board assembly 689661-004, Physical connectors present: RJ45
Primary interface chip i82555 PHY #1.
MII PHY #1 transceiver registers:
3000 782d 02a8 0150 05e1 40a1 0001 ffff
ffff ffff ffff ffff ffff ffff ffff ffff
0a02 0000 0001 0000 0000 0000 0000 0000
0000 0000 b1d9 0000 ffff ffff ffff ffff.
MII PHY #1 transceiver registers:
3000 782d 02a8 0150 05e1 40a1 0001 ffff
ffff ffff ffff ffff ffff ffff ffff ffff
0a02 0000 0001 0000 0000 0000 0000 0000
0000 0000 b1d9 0000 ffff ffff ffff ffff.
Basic mode control register 0x3000: Auto-negotiation enabled.
Basic mode status register 0x782d ... 782d.
Link status: established.
Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
Able to perform Auto-negotiation, negotiation complete.
Vendor ID is 00:aa:00:--:--:--, model 21 rev. 0.
No specific information is known about this transceiver type.
I'm advertising 05e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD
10baseT
Advertising no additional info pages.
IEEE 802.3 CSMA/CD protocol.
Link partner capability is 40a1: 100baseTx 10baseT.
Negotiation completed.
Don't know what else to tell you, except that this is a problem that I
need to solve QUICKLY. Any help is more than appreciated!
Best regards,
Mark
------=_NextPart_000_000E_01BEADE6.25AE5D20
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
I have a Pentium 90 system with two Intel EtherExpress =
100B ethernet adapters. I use the system as a router. Regularly, I get =
the following error messages (once a second or so) on the =
console:
eth1: Transmit timed out: status 7048 0000 at =
2476/2491 command 000ch000
eth1: Trying to restart the transmitter...
After that, this interface is dead. This also happens =
for the eth0 device.
Now, I guess you want relevant system =
information.
I'll start with the kernel version: 2.0.36
The eepro100.c driver version is: v1.08 5/3/99
Initially, I was using the v0.99B 4/7/98 version =
which had the same problem.
What else is there to say: I'll give you the output of =
the eepro-diag program while both cards are in ok state:
eepro-diag -a -v -e -f -m
eepro100-diag.c:v0.07 2/25/98 Donald Becker =
(becker@cesdis.gsfc.nasa.gov)
Index #1: Found a Intel 82557 EtherExpressPro100B =
adapter at 0x4000.
i82557 chip registers at 0x4000:
00000050 02e09904 00000000 00080002 18250081 =
00000600
No interrupt sources are pending.
The transmit unit state is =
'Suspended'.
The receive unit state is =
'Ready'.
Intel EtherExpress Pro 10/100 EEPROM contents:
Station address 00:90:27:34:93:1E.
Receiver lock-up bug exists. (The driver =
work-around *is* implemented.)
Board assembly 689661-004, Physical connectors =
present: RJ45
Primary interface chip i82555 PHY #1.
MII PHY #1 transceiver registers:
3000 782d 02a8 0150 05e1 0081 0000 ffff
ffff ffff ffff ffff ffff ffff ffff ffff
0a02 0000 0001 0000 0000 0000 0000 0000
0000 0000 3ecb 0000 ffff ffff ffff =
ffff.
MII PHY #1 transceiver registers:
3000 782d 02a8 0150 05e1 0081 0000 =
ffff
ffff ffff ffff ffff ffff ffff ffff =
ffff
0a02 0000 0001 0000 0000 0000 0000 =
0000
0000 0000 3ecb 0000 ffff ffff ffff =
ffff.
Basic mode control register 0x3000: =
Auto-negotiation enabled.
Basic mode status register 0x782d ... =
782d.
Link status: established.
Capable of 100baseTx-FD 100baseTx =
10baseT-FD 10baseT.
Able to perform Auto-negotiation, =
negotiation complete.
Vendor ID is 00:aa:00:--:--:--, model 21 rev. =
0.
No specific information is known about =
this transceiver type.
I'm advertising 05e1: Flow-control 100baseTx-FD =
100baseTx 10baseT-FD 10baseT
Advertising no additional info =
pages.
IEEE 802.3 CSMA/CD protocol.
Link partner capability is 0081: =
100baseTx.
Negotiation did not complete.
Index #2: Found a Intel 82557 EtherExpressPro100B =
adapter at 0x4020.
i82557 chip registers at 0x4020:
00000050 02e0910c 00000000 00080002 182540a1 =
00000600
No interrupt sources are pending.
The transmit unit state is =
'Suspended'.
The receive unit state is =
'Ready'.
Intel EtherExpress Pro 10/100 EEPROM contents:
Station address 00:90:27:34:98:52.
Receiver lock-up bug exists. (The driver =
work-around *is* implemented.)
Board assembly 689661-004, Physical connectors =
present: RJ45
Primary interface chip i82555 PHY #1.
MII PHY #1 transceiver registers:
3000 782d 02a8 0150 05e1 40a1 0001 ffff
ffff ffff ffff ffff ffff ffff ffff ffff
0a02 0000 0001 0000 0000 0000 0000 0000
0000 0000 b1d9 0000 ffff ffff ffff =
ffff.
MII PHY #1 transceiver registers:
3000 782d 02a8 0150 05e1 40a1 0001 =
ffff
ffff ffff ffff ffff ffff ffff ffff =
ffff
0a02 0000 0001 0000 0000 0000 0000 =
0000
0000 0000 b1d9 0000 ffff ffff ffff =
ffff.
Basic mode control register 0x3000: =
Auto-negotiation enabled.
Basic mode status register 0x782d ... =
782d.
Link status: established.
Capable of 100baseTx-FD 100baseTx =
10baseT-FD 10baseT.
Able to perform Auto-negotiation, =
negotiation complete.
Vendor ID is 00:aa:00:--:--:--, model 21 rev. =
0.
No specific information is known about =
this transceiver type.
I'm advertising 05e1: Flow-control 100baseTx-FD =
100baseTx 10baseT-FD 10baseT
Advertising no additional info =
pages.
IEEE 802.3 CSMA/CD protocol.
Link partner capability is 40a1: 100baseTx =
10baseT.
Negotiation completed.
Don't know what else to tell you, except that this is =
a problem that I need to solve QUICKLY. Any help is more than =
appreciated!
Best regards,
Mark
------=_NextPart_000_000E_01BEADE6.25AE5D20--
------=_NextPart_000_0015_01BEADE6.262D2A10
Content-Type: application/x-pkcs7-signature;
name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="smime.p7s"
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIH1TCCAy4w
ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFy
eSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTla
MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0
d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk
dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFLuUgTVi3H
COGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9q
JJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0g
BEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9z
aXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GB
AIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKe
wz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiS
xVhqwY0DPOvDzQWikK5uMIIEnzCCBAigAwIBAgIQVhqyfVOrj4Y2+bDy50l1jTANBgkqhkiG9w0B
AQQFADCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw
LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5k
aXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw05OTA0MTYwMDAwMDBa
Fw05OTA2MTUyMzU5NTlaMIH/MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy
aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5
L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3Qg
VmFsaWRhdGVkMScwJQYDVQQLEx5EaWdpdGFsIElEIENsYXNzIDEgLSBNaWNyb3NvZnQxFDASBgNV
BAMUC01hcmsgUmFtaW5nMRwwGgYJKoZIhvcNAQkBFg1tYXJrQGVyYXplLm5sMFwwDQYJKoZIhvcN
AQEBBQADSwAwSAJBAPSoadB1xNffTomauYHotieQqK9wDE6QanJV4su1vIMKeH02WQ1vf4TUaQBC
aAy9Ko0uYLHiRCg/dopVXHqjMe8CAwEAAaOCAY8wggGLMAkGA1UdEwQCMAAwgawGA1UdIASBpDCB
oTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv
bS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQ
UyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG
+EIBAQQEAwIHgDCBhgYKYIZIAYb4RQEGAwR4FnZkNDY1MmJkNjNmMjA0NzAyOTI5ODc2M2M5ZDJm
Mjc1MDY5YzczNTliZWQxYjA1OWRhNzViYzRiYzk3MDE3NDdkYTVjOGVkMTQxYmVhZGIyYmQyZmE4
NDE0YTQ3Yjg5YjMxMTQ5OTdhM2JkNDVmZmYzZWE0NTY0MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6
Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAdmMZGcmVRdJI
moXpsZNngDdX6fsnx+frBDo5m6yt577tnkM+klZaAD9n0Xs27jedv8X38mB80w1e2lvYwvZpBGI6
NXYsoCnaZgwsnIyqgTZbgyHO0nglJRozoU79/EvHAZoiPHRtWBedI+oYCq4M1zvfHrJgdOkOnooa
giAO010xggLSMIICzgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT
FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np
dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQ
VhqyfVOrj4Y2+bDy50l1jTAJBgUrDgMCGgUAoIIBhzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB
MBwGCSqGSIb3DQEJBTEPFw05OTA2MDMxNTI2MDBaMCMGCSqGSIb3DQEJBDEWBBSi8N5hRwSNo/zv
7wbLbDTjTLj3ZTAzBgkqhkiG9w0BCQ8xJjAkMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG
SIb3DQIFMIHyBgkrBgEEAYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxp
ZGF0ZWQCEFYasn1Tq4+GNvmw8udJdY0wDQYJKoZIhvcNAQEBBQAEQNM+JhcuD8V+5AO5PYHD38OO
MghXsI1fFClip5SE8h2Vz/DNwSwFdsq4rOTO3WIoz5DImeLaqejTZBJyZtaclCgAAAAAAAA=
------=_NextPart_000_0015_01BEADE6.262D2A10--
From Mark@Eraze.nl Thu Jun 3 11:30:28 1999
Date: Thu Jun 3 11:30:28 1999
From: Mark Raming Mark@Eraze.nl
Subject: FW: Intel EtherExpress Pro 100B problem: Transmit timed out: status 7048 0000 at 2476/2491 command 000ch000
This is a multi-part message in MIME format.
------=_NextPart_000_0037_01BEADE6.C084BB00
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0030_01BEADE6.C019C430"
------=_NextPart_000_0030_01BEADE6.C019C430
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
I have a Pentium 90 system with two Intel EtherExpress 100B ethernet
adapters. I use the system as a router. Regularly, I get the following
error messages (once a second or so) on the console:
eth1: Transmit timed out: status 7048 0000 at 2476/2491 command 000ch000
eth1: Trying to restart the transmitter...
After that, this interface is dead. This also happens for the eth0 device.
Now, I guess you want relevant system information.
I'll start with the kernel version: 2.0.36
The eepro100.c driver version is: v1.08 5/3/99
Initially, I was using the v0.99B 4/7/98 version which had the same
problem.
What else is there to say: I'll give you the output of the eepro-diag
program while both cards are in ok state:
eepro-diag -a -v -e -f -m
eepro100-diag.c:v0.07 2/25/98 Donald Becker (becker@cesdis.gsfc.nasa.gov)
Index #1: Found a Intel 82557 EtherExpressPro100B adapter at 0x4000.
i82557 chip registers at 0x4000:
00000050 02e09904 00000000 00080002 18250081 00000600
No interrupt sources are pending.
The transmit unit state is 'Suspended'.
The receive unit state is 'Ready'.
Intel EtherExpress Pro 10/100 EEPROM contents:
Station address 00:90:27:34:93:1E.
Receiver lock-up bug exists. (The driver work-around *is* implemented.)
Board assembly 689661-004, Physical connectors present: RJ45
Primary interface chip i82555 PHY #1.
MII PHY #1 transceiver registers:
3000 782d 02a8 0150 05e1 0081 0000 ffff
ffff ffff ffff ffff ffff ffff ffff ffff
0a02 0000 0001 0000 0000 0000 0000 0000
0000 0000 3ecb 0000 ffff ffff ffff ffff.
MII PHY #1 transceiver registers:
3000 782d 02a8 0150 05e1 0081 0000 ffff
ffff ffff ffff ffff ffff ffff ffff ffff
0a02 0000 0001 0000 0000 0000 0000 0000
0000 0000 3ecb 0000 ffff ffff ffff ffff.
Basic mode control register 0x3000: Auto-negotiation enabled.
Basic mode status register 0x782d ... 782d.
Link status: established.
Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
Able to perform Auto-negotiation, negotiation complete.
Vendor ID is 00:aa:00:--:--:--, model 21 rev. 0.
No specific information is known about this transceiver type.
I'm advertising 05e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD
10baseT
Advertising no additional info pages.
IEEE 802.3 CSMA/CD protocol.
Link partner capability is 0081: 100baseTx.
Negotiation did not complete.
Index #2: Found a Intel 82557 EtherExpressPro100B adapter at 0x4020.
i82557 chip registers at 0x4020:
00000050 02e0910c 00000000 00080002 182540a1 00000600
No interrupt sources are pending.
The transmit unit state is 'Suspended'.
The receive unit state is 'Ready'.
Intel EtherExpress Pro 10/100 EEPROM contents:
Station address 00:90:27:34:98:52.
Receiver lock-up bug exists. (The driver work-around *is* implemented.)
Board assembly 689661-004, Physical connectors present: RJ45
Primary interface chip i82555 PHY #1.
MII PHY #1 transceiver registers:
3000 782d 02a8 0150 05e1 40a1 0001 ffff
ffff ffff ffff ffff ffff ffff ffff ffff
0a02 0000 0001 0000 0000 0000 0000 0000
0000 0000 b1d9 0000 ffff ffff ffff ffff.
MII PHY #1 transceiver registers:
3000 782d 02a8 0150 05e1 40a1 0001 ffff
ffff ffff ffff ffff ffff ffff ffff ffff
0a02 0000 0001 0000 0000 0000 0000 0000
0000 0000 b1d9 0000 ffff ffff ffff ffff.
Basic mode control register 0x3000: Auto-negotiation enabled.
Basic mode status register 0x782d ... 782d.
Link status: established.
Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
Able to perform Auto-negotiation, negotiation complete.
Vendor ID is 00:aa:00:--:--:--, model 21 rev. 0.
No specific information is known about this transceiver type.
I'm advertising 05e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD
10baseT
Advertising no additional info pages.
IEEE 802.3 CSMA/CD protocol.
Link partner capability is 40a1: 100baseTx 10baseT.
Negotiation completed.
Don't know what else to tell you, except that this is a problem that I
need to solve QUICKLY. Any help is more than appreciated!
Best regards,
Mark
------=_NextPart_000_0030_01BEADE6.C019C430
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
I have a Pentium 90 system with two Intel EtherExpress =
100B=20
ethernet adapters. I use the system as a router. Regularly, I get the =
following=20
error messages (once a second or so) on the console:
eth1: Transmit timed out: status 7048 0000 at =
2476/2491=20
command 000ch000
eth1: Trying to restart the=20
transmitter...
After that, this interface is dead. This also happens =
for the=20
eth0 device.
Now, I guess you want relevant system =
information.
I'll start with the kernel version: 2.0.36 =
The eepro100.c driver version is: v1.08 5/3/99
Initially, I was using the v0.99B 4/7/98 version which had the =
same=20
problem.
What else is there to say: I'll give you the output of =
the=20
eepro-diag program while both cards are in ok state:
eepro-diag -a -v -e -f -m
eepro100-diag.c:v0.07 2/25/98 Donald Becker=20
(becker@cesdis.gsfc.nasa.gov)
Index #1: Found =
a Intel=20
82557 EtherExpressPro100B adapter at 0x4000.
i82557 chip=20
registers at 0x4000:
00000050 02e09904 =
00000000=20
00080002 18250081 00000600
No interrupt =
sources=20
are pending.
The transmit unit =
state is=20
'Suspended'.
The receive unit =
state is=20
'Ready'.
Intel EtherExpress Pro 10/100 EEPROM=20
contents:
Station address=20
00:90:27:34:93:1E.
Receiver lock-up bug =
exists.=20
(The driver work-around *is* implemented.)
Board=20
assembly 689661-004, Physical connectors present: RJ45
Primary interface chip i82555 PHY #1.
MII PHY #1 transceiver registers:
=20
3000 782d 02a8 0150 05e1 0081 0000 ffff
=
ffff ffff=20
ffff ffff ffff ffff ffff ffff
0a02 0000 =
0001 0000=20
0000 0000 0000 0000
0000 0000 3ecb 0000 =
ffff ffff=20
ffff ffff.
MII PHY #1 transceiver=20
registers:
3000 782d 02a8 0150 =
05e1 0081=20
0000 ffff
ffff ffff ffff ffff =
ffff ffff=20
ffff ffff
0a02 0000 0001 0000 =
0000 0000=20
0000 0000
0000 0000 3ecb 0000 =
ffff ffff=20
ffff ffff.
Basic mode control register =
0x3000:=20
Auto-negotiation enabled.
Basic mode =
status=20
register 0x782d ... 782d.
Link =
status:=20
established.
Capable of =
100baseTx-FD=20
100baseTx 10baseT-FD 10baseT.
=
Able to=20
perform Auto-negotiation, negotiation complete.
Vendor ID is 00:aa:00:--:--:--, model 21 rev. 0. =
No specific information is known about this =
transceiver=20
type.
I'm advertising 05e1: Flow-control =
100baseTx-FD 100baseTx 10baseT-FD 10baseT
=20
Advertising no additional info pages.
IEEE=20
802.3 CSMA/CD protocol.
Link partner =
capability is=20
0081: 100baseTx.
Negotiation did =
not=20
complete.
Index #2: Found a Intel 82557=20
EtherExpressPro100B adapter at 0x4020.
i82557 =
chip=20
registers at 0x4020:
00000050 02e0910c =
00000000=20
00080002 182540a1 00000600
No interrupt =
sources=20
are pending.
The transmit unit =
state is=20
'Suspended'.
The receive unit =
state is=20
'Ready'.
Intel EtherExpress Pro 10/100 EEPROM=20
contents:
Station address=20
00:90:27:34:98:52.
Receiver lock-up bug =
exists.=20
(The driver work-around *is* implemented.)
Board=20
assembly 689661-004, Physical connectors present: RJ45
Primary interface chip i82555 PHY #1.
MII PHY #1 transceiver registers:
=20
3000 782d 02a8 0150 05e1 40a1 0001 ffff
=
ffff ffff=20
ffff ffff ffff ffff ffff ffff
0a02 0000 =
0001 0000=20
0000 0000 0000 0000
0000 0000 b1d9 0000 =
ffff ffff=20
ffff ffff.
MII PHY #1 transceiver=20
registers:
3000 782d 02a8 0150 =
05e1 40a1=20
0001 ffff
ffff ffff ffff ffff =
ffff ffff=20
ffff ffff
0a02 0000 0001 0000 =
0000 0000=20
0000 0000
0000 0000 b1d9 0000 =
ffff ffff=20
ffff ffff.
Basic mode control register =
0x3000:=20
Auto-negotiation enabled.
Basic mode =
status=20
register 0x782d ... 782d.
Link =
status:=20
established.
Capable of =
100baseTx-FD=20
100baseTx 10baseT-FD 10baseT.
=
Able to=20
perform Auto-negotiation, negotiation complete.
Vendor ID is 00:aa:00:--:--:--, model 21 rev. 0. =
No specific information is known about this =
transceiver=20
type.
I'm advertising 05e1: Flow-control =
100baseTx-FD 100baseTx 10baseT-FD 10baseT
=20
Advertising no additional info pages.
IEEE=20
802.3 CSMA/CD protocol.
Link partner =
capability is=20
40a1: 100baseTx 10baseT.
=
Negotiation =20
completed.
Don't know what else to tell you, except that this is =
a problem=20
that I need to solve QUICKLY. Any help is more than =
appreciated!
Best regards,
Mark
------=_NextPart_000_0030_01BEADE6.C019C430--
------=_NextPart_000_0037_01BEADE6.C084BB00
Content-Type: application/x-pkcs7-signature;
name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="smime.p7s"
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIH1TCCAy4w
ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFy
eSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTla
MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0
d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk
dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFLuUgTVi3H
COGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9q
JJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0g
BEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9z
aXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GB
AIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKe
wz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiS
xVhqwY0DPOvDzQWikK5uMIIEnzCCBAigAwIBAgIQVhqyfVOrj4Y2+bDy50l1jTANBgkqhkiG9w0B
AQQFADCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw
LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5k
aXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw05OTA0MTYwMDAwMDBa
Fw05OTA2MTUyMzU5NTlaMIH/MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy
aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5
L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3Qg
VmFsaWRhdGVkMScwJQYDVQQLEx5EaWdpdGFsIElEIENsYXNzIDEgLSBNaWNyb3NvZnQxFDASBgNV
BAMUC01hcmsgUmFtaW5nMRwwGgYJKoZIhvcNAQkBFg1tYXJrQGVyYXplLm5sMFwwDQYJKoZIhvcN
AQEBBQADSwAwSAJBAPSoadB1xNffTomauYHotieQqK9wDE6QanJV4su1vIMKeH02WQ1vf4TUaQBC
aAy9Ko0uYLHiRCg/dopVXHqjMe8CAwEAAaOCAY8wggGLMAkGA1UdEwQCMAAwgawGA1UdIASBpDCB
oTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv
bS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQ
UyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG
+EIBAQQEAwIHgDCBhgYKYIZIAYb4RQEGAwR4FnZkNDY1MmJkNjNmMjA0NzAyOTI5ODc2M2M5ZDJm
Mjc1MDY5YzczNTliZWQxYjA1OWRhNzViYzRiYzk3MDE3NDdkYTVjOGVkMTQxYmVhZGIyYmQyZmE4
NDE0YTQ3Yjg5YjMxMTQ5OTdhM2JkNDVmZmYzZWE0NTY0MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6
Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAdmMZGcmVRdJI
moXpsZNngDdX6fsnx+frBDo5m6yt577tnkM+klZaAD9n0Xs27jedv8X38mB80w1e2lvYwvZpBGI6
NXYsoCnaZgwsnIyqgTZbgyHO0nglJRozoU79/EvHAZoiPHRtWBedI+oYCq4M1zvfHrJgdOkOnooa
giAO010xggLSMIICzgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT
FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np
dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWdu
IENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQ
VhqyfVOrj4Y2+bDy50l1jTAJBgUrDgMCGgUAoIIBhzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB
MBwGCSqGSIb3DQEJBTEPFw05OTA2MDMxNTMwMTlaMCMGCSqGSIb3DQEJBDEWBBQIzxsgQbRnQYtG
C/cDVOGpCpmDZTAzBgkqhkiG9w0BCQ8xJjAkMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG
SIb3DQIFMIHyBgkrBgEEAYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W
ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxp
ZGF0ZWQCEFYasn1Tq4+GNvmw8udJdY0wDQYJKoZIhvcNAQEBBQAEQMcl7fGJXHVRj9ipRqOKBYN/
/eUAm1k3k/UevFAGenREkMcNDQLgQrZlFuocgvWrsEakJq4S46rIkZt1m6Dsb7sAAAAAAAA=
------=_NextPart_000_0037_01BEADE6.C084BB00--
From Mark@Eraze.nl Thu Jun 3 12:12:03 1999
Date: Thu Jun 3 12:12:03 1999
From: Mark Raming Mark@Eraze.nl
Subject: Intel EtherExpress Pro 100B problem: Transmit timed out: status 7048 0000 at 2476/2491 command 000ch000
This is a multi-part message in MIME format.
------=_NextPart_000_0011_01BEADEC.906F6860
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
What I forgot in my previous message, is the output of the eepro-diag
program after the problem started occuring. Here it comes:
eepro100-diag.c:v0.07 2/25/98 Donald Becker ( becker@cesdis.gsfc.nasa.gov)
Index #1: Found a Intel 82557 EtherExpressPro100B adapter at 0x4000.
i82557 chip registers at 0x4000:
00007048 02e099e4 00000000 00080002 18250081 000005c0
Interrupt sources are pending.
The transmit unit state is 'Suspended'.
The receive unit state is 'No Resources'.
Intel EtherExpress Pro 10/100 EEPROM contents:
Station address 00:90:27:34:93:1E.
Receiver lock-up bug exists. (The driver work-around *is* implemented.)
Board assembly 689661-004, Physical connectors present: RJ45
Primary interface chip i82555 PHY #1.
MII PHY #1 transceiver registers:
3000 782d 02a8 0150 05e1 0081 0000 ffff
ffff ffff ffff ffff ffff ffff ffff ffff
0a02 0000 0001 0000 0000 0000 0000 0000
0000 0000 f2d8 0000 ffff ffff ffff ffff.
MII PHY #1 transceiver registers:
3000 782d 02a8 0150 05e1 0081 0000 ffff
ffff ffff ffff ffff ffff ffff ffff ffff
0a02 0000 0001 0000 0000 0000 0000 0000
0000 0000 f2d8 0000 ffff ffff ffff ffff.
Basic mode control register 0x3000: Auto-negotiation enabled.
Basic mode status register 0x782d ... 782d.
Link status: established.
Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
Able to perform Auto-negotiation, negotiation complete.
Vendor ID is 00:aa:00:--:--:--, model 21 rev. 0.
No specific information is known about this transceiver type.
I'm advertising 05e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD
10baseT
Advertising no additional info pages.
IEEE 802.3 CSMA/CD protocol.
Link partner capability is 0081: 100baseTx.
Negotiation did not complete.
Index #2: Found a Intel 82557 EtherExpressPro100B adapter at 0x4020.
i82557 chip registers at 0x4020:
00007048 02e0928c 00000000 00080002 182540a1 00000508
Interrupt sources are pending.
The transmit unit state is 'Suspended'.
The receive unit state is 'No Resources'.
Intel EtherExpress Pro 10/100 EEPROM contents:
Station address 00:90:27:34:98:52.
Receiver lock-up bug exists. (The driver work-around *is* implemented.)
Board assembly 689661-004, Physical connectors present: RJ45
Primary interface chip i82555 PHY #1.
MII PHY #1 transceiver registers:
3000 782d 02a8 0150 05e1 40a1 0001 ffff
ffff ffff ffff ffff ffff ffff ffff ffff
0a02 0000 0001 0000 0000 0000 0000 0000
0000 0000 b8bd 0000 ffff ffff ffff ffff.
MII PHY #1 transceiver registers:
3000 782d 02a8 0150 05e1 40a1 0001 ffff
ffff ffff ffff ffff ffff ffff ffff ffff
0a02 0000 0001 0000 0000 0000 0000 0000
0000 0000 b8bd 0000 ffff ffff ffff ffff.
Basic mode control register 0x3000: Auto-negotiation enabled.
Basic mode status register 0x782d ... 782d.
Link status: established.
Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
Able to perform Auto-negotiation, negotiation complete.
Vendor ID is 00:aa:00:--:--:--, model 21 rev. 0.
No specific information is known about this transceiver type.
I'm advertising 05e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD
10baseT
Advertising no additional info pages.
IEEE 802.3 CSMA/CD protocol.
Link partner capability is 40a1: 100baseTx 10baseT.
Negotiation completed.
Best regards,
Mark Raming
I have a Pentium 90 system with two Intel EtherExpress 100B ethernet
adapters. I use the system as a router. Regularly, I get the following error
messages (once a second or so) on the console:
eth1: Transmit timed out: status 7048 0000 at 2476/2491 command 000ch000
eth1: Trying to restart the transmitter...
After that, this interface is dead. This also happens for the eth0 device.
Now, I guess you want relevant system information.
I'll start with the kernel version: 2.0.36
The eepro100.c driver version is: v1.08 5/3/99
Initially, I was using the v0.99B 4/7/98 version which had the same problem.
What else is there to say: I'll give you the output of the eepro-diag
program while both cards are in ok state:
eepro-diag -a -v -e -f -m
eepro100-diag.c:v0.07 2/25/98 Donald Becker (becker@cesdis.gsfc.nasa.gov)
Index #1: Found a Intel 82557 EtherExpressPro100B adapter at 0x4000.
i82557 chip registers at 0x4000:
00000050 02e09904 00000000 00080002 18250081 00000600
No interrupt sources are pending.
The transmit unit state is 'Suspended'.
The receive unit state is 'Ready'.
Intel EtherExpress Pro 10/100 EEPROM contents:
Station address 00:90:27:34:93:1E.
Receiver lock-up bug exists. (The driver work-around *is* implemented.)
Board assembly 689661-004, Physical connectors present: RJ45
Primary interface chip i82555 PHY #1.
MII PHY #1 transceiver registers:
3000 782d 02a8 0150 05e1 0081 0000 ffff
ffff ffff ffff ffff ffff ffff ffff ffff
0a02 0000 0001 0000 0000 0000 0000 0000
0000 0000 3ecb 0000 ffff ffff ffff ffff.
MII PHY #1 transceiver registers:
3000 782d 02a8 0150 05e1 0081 0000 ffff
ffff ffff ffff ffff ffff ffff ffff ffff
0a02 0000 0001 0000 0000 0000 0000 0000
0000 0000 3ecb 0000 ffff ffff ffff ffff.
Basic mode control register 0x3000: Auto-negotiation enabled.
Basic mode status register 0x782d ... 782d.
Link status: established.
Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
Able to perform Auto-negotiation, negotiation complete.
Vendor ID is 00:aa:00:--:--:--, model 21 rev. 0.
No specific information is known about this transceiver type.
I'm advertising 05e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD
10baseT
Advertising no additional info pages.
IEEE 802.3 CSMA/CD protocol.
Link partner capability is 0081: 100baseTx.
Negotiation did not complete.
Index #2: Found a Intel 82557 EtherExpressPro100B adapter at 0x4020.
i82557 chip registers at 0x4020:
00000050 02e0910c 00000000 00080002 182540a1 00000600
No interrupt sources are pending.
The transmit unit state is 'Suspended'.
The receive unit state is 'Ready'.
Intel EtherExpress Pro 10/100 EEPROM contents:
Station address 00:90:27:34:98:52.
Receiver lock-up bug exists. (The driver work-around *is* implemented.)
Board assembly 689661-004, Physical connectors present: RJ45
Primary interface chip i82555 PHY #1.
MII PHY #1 transceiver registers:
3000 782d 02a8 0150 05e1 40a1 0001 ffff
ffff ffff ffff ffff ffff ffff ffff ffff
0a02 0000 0001 0000 0000 0000 0000 0000
0000 0000 b1d9 0000 ffff ffff ffff ffff.
MII PHY #1 transceiver registers:
3000 782d 02a8 0150 05e1 40a1 0001 ffff
ffff ffff ffff ffff ffff ffff ffff ffff
0a02 0000 0001 0000 0000 0000 0000 0000
0000 0000 b1d9 0000 ffff ffff ffff ffff.
Basic mode control register 0x3000: Auto-negotiation enabled.
Basic mode status register 0x782d ... 782d.
Link status: established.
Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
Able to perform Auto-negotiation, negotiation complete.
Vendor ID is 00:aa:00:--:--:--, model 21 rev. 0.
No specific information is known about this transceiver type.
I'm advertising 05e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD
10baseT
Advertising no additional info pages.
IEEE 802.3 CSMA/CD protocol.
Link partner capability is 40a1: 100baseTx 10baseT.
Negotiation completed.
Don't know what else to tell you, except that this is a problem that I need
to solve QUICKLY. Any help is more than appreciated!
Best regards,
Mark
------=_NextPart_000_0011_01BEADEC.906F6860
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
What I forgot in my previous message, is the output of =
the=20
eepro-diag program after the problem started occuring. Here it=20
comes:
eepro100-diag.c:v0.07 2/25/98 Donald Becker =
(becker@cesdis.gsfc.nasa.gov)
Index=20
#1: Found a Intel 82557 EtherExpressPro100B adapter at =
0x4000.
i82557 chip=20
registers at 0x4000:
00007048 02e099e4 00000000 00080002 =
18250081=20
000005c0
Interrupt sources are pending.
The =
transmit=20
unit state is 'Suspended'.
The receive unit state is =
'No=20
Resources'.
Intel EtherExpress Pro 10/100 EEPROM =
contents:
=20
Station address 00:90:27:34:93:1E.
Receiver lock-up bug =
exists. (The=20
driver work-around *is* implemented.)
Board assembly =
689661-004,=20
Physical connectors present: RJ45
Primary interface chip =
i82555 PHY=20
#1.
MII PHY #1 transceiver registers:
3000 782d =
02a8 0150=20
05e1 0081 0000 ffff
ffff ffff ffff ffff ffff ffff ffff=20
ffff
0a02 0000 0001 0000 0000 0000 0000 0000
0000 =
0000=20
f2d8 0000 ffff ffff ffff ffff.
MII PHY #1 transceiver=20
registers:
3000 782d 02a8 0150 05e1 0081 0000=20
ffff
ffff ffff ffff ffff ffff ffff ffff =
ffff
=20
0a02 0000 0001 0000 0000 0000 0000 0000
0000 0000 f2d8 =
0000=20
ffff ffff ffff ffff.
Basic mode control register 0x3000:=20
Auto-negotiation enabled.
Basic mode status register 0x782d =
...=20
782d.
Link status: established.
=
Capable=20
of 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
=
Able to=20
perform Auto-negotiation, negotiation complete.
Vendor ID is=20
00:aa:00:--:--:--, model 21 rev. 0.
No specific =
information is=20
known about this transceiver type.
I'm advertising 05e1: =
Flow-control=20
100baseTx-FD 100baseTx 10baseT-FD 10baseT
Advertising =
no=20
additional info pages.
IEEE 802.3 CSMA/CD=20
protocol.
Link partner capability is 0081: =
100baseTx.
=20
Negotiation did not complete.
Index #2: Found a Intel 82557=20
EtherExpressPro100B adapter at 0x4020.
i82557 chip registers at=20
0x4020:
00007048 02e0928c 00000000 00080002 182540a1=20
00000508
Interrupt sources are pending.
The =
transmit=20
unit state is 'Suspended'.
The receive unit state is =
'No=20
Resources'.
Intel EtherExpress Pro 10/100 EEPROM =
contents:
=20
Station address 00:90:27:34:98:52.
Receiver lock-up bug =
exists. (The=20
driver work-around *is* implemented.)
Board assembly =
689661-004,=20
Physical connectors present: RJ45
Primary interface chip =
i82555 PHY=20
#1.
MII PHY #1 transceiver registers:
3000 782d =
02a8 0150=20
05e1 40a1 0001 ffff
ffff ffff ffff ffff ffff ffff ffff=20
ffff
0a02 0000 0001 0000 0000 0000 0000 0000
0000 =
0000=20
b8bd 0000 ffff ffff ffff ffff.
MII PHY #1 transceiver=20
registers:
3000 782d 02a8 0150 05e1 40a1 0001=20
ffff
ffff ffff ffff ffff ffff ffff ffff =
ffff
=20
0a02 0000 0001 0000 0000 0000 0000 0000
0000 0000 b8bd =
0000=20
ffff ffff ffff ffff.
Basic mode control register 0x3000:=20
Auto-negotiation enabled.
Basic mode status register 0x782d =
...=20
782d.
Link status: established.
=
Capable=20
of 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
=
Able to=20
perform Auto-negotiation, negotiation complete.
Vendor ID is=20
00:aa:00:--:--:--, model 21 rev. 0.
No specific =
information is=20
known about this transceiver type.
I'm advertising 05e1: =
Flow-control=20
100baseTx-FD 100baseTx 10baseT-FD 10baseT
Advertising =
no=20
additional info pages.
IEEE 802.3 CSMA/CD=20
protocol.
Link partner capability is 40a1: 100baseTx=20
10baseT.
Negotiation =
completed.
Best=20
regards,
Mark=20
Raming
I have =
a Pentium=20
90 system with two Intel EtherExpress 100B ethernet adapters. I use =
the system=20
as a router. Regularly, I get the following error messages (once a =
second or=20
so) on the console:
eth1: Transmit timed out: status 7048 0000 at =
2476/2491=20
command 000ch000
eth1: Trying to restart the =
transmitter...
After that, this interface is dead. This also =
happens for the=20
eth0 device.
Now, I guess you want relevant system =
information.
I'll start with the kernel version: 2.0.36 =
The eepro100.c driver version is: v1.08 5/3/99 =
Initially, I was using the v0.99B 4/7/98 version which had =
the same=20
problem.
What else is there to say: I'll give you the output =
of the=20
eepro-diag program while both cards are in ok state:
eepro-diag -a -v -e -f -m
eepro100-diag.c:v0.07 2/25/98 Donald Becker=20
(becker@cesdis.gsfc.nasa.gov)
Index #1: =
Found a Intel=20
82557 EtherExpressPro100B adapter at 0x4000.
i82557=20
chip registers at 0x4000:
00000050 =
02e09904=20
00000000 00080002 18250081 00000600
=
No=20
interrupt sources are pending.
=
The=20
transmit unit state is 'Suspended'.
The=20
receive unit state is 'Ready'.
Intel =
EtherExpress Pro=20
10/100 EEPROM contents:
Station =
address=20
00:90:27:34:93:1E.
Receiver lock-up =
bug exists.=20
(The driver work-around *is* implemented.)
=20
Board assembly 689661-004, Physical connectors present: RJ45 =
Primary interface chip i82555 PHY #1.
MII PHY #1 transceiver registers:
=20
3000 782d 02a8 0150 05e1 0081 0000 ffff
ffff=20
ffff ffff ffff ffff ffff ffff ffff
=
0a02 0000=20
0001 0000 0000 0000 0000 0000
0000 =
0000 3ecb=20
0000 ffff ffff ffff ffff.
MII PHY #1 =
transceiver=20
registers:
3000 782d 02a8 0150 =
05e1 0081=20
0000 ffff
ffff ffff ffff ffff =
ffff ffff=20
ffff ffff
0a02 0000 0001 0000 =
0000 0000=20
0000 0000
0000 0000 3ecb 0000 =
ffff ffff=20
ffff ffff.
Basic mode control register =
0x3000:=20
Auto-negotiation enabled.
Basic mode =
status=20
register 0x782d ... 782d.
Link =
status:=20
established.
Capable of =20
100baseTx-FD 100baseTx 10baseT-FD 10baseT.
Able to perform Auto-negotiation, negotiation=20
complete.
Vendor ID is =
00:aa:00:--:--:--, model=20
21 rev. 0.
No specific =
information is=20
known about this transceiver type.
I'm =
advertising 05e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD=20
10baseT
Advertising no =
additional info=20
pages.
IEEE 802.3 CSMA/CD=20
protocol.
Link partner capability is =
0081:=20
100baseTx.
Negotiation did not=20
complete.
Index #2: Found a Intel 82557=20
EtherExpressPro100B adapter at 0x4020.
i82557 chip=20
registers at 0x4020:
00000050 =
02e0910c 00000000=20
00080002 182540a1 00000600
No =
interrupt sources=20
are pending.
The transmit unit =
state is=20
'Suspended'.
The receive unit =
state is=20
'Ready'.
Intel EtherExpress Pro 10/100 =
EEPROM=20
contents:
Station address=20
00:90:27:34:98:52.
Receiver lock-up =
bug exists.=20
(The driver work-around *is* implemented.)
=20
Board assembly 689661-004, Physical connectors present: RJ45 =
Primary interface chip i82555 PHY #1.
MII PHY #1 transceiver registers:
=20
3000 782d 02a8 0150 05e1 40a1 0001 ffff
ffff=20
ffff ffff ffff ffff ffff ffff ffff
=
0a02 0000=20
0001 0000 0000 0000 0000 0000
0000 =
0000 b1d9=20
0000 ffff ffff ffff ffff.
MII PHY #1 =
transceiver=20
registers:
3000 782d 02a8 0150 =
05e1 40a1=20
0001 ffff
ffff ffff ffff ffff =
ffff ffff=20
ffff ffff
0a02 0000 0001 0000 =
0000 0000=20
0000 0000
0000 0000 b1d9 0000 =
ffff ffff=20
ffff ffff.
Basic mode control register =
0x3000:=20
Auto-negotiation enabled.
Basic mode =
status=20
register 0x782d ... 782d.
Link =
status:=20
established.
Capable of =20
100baseTx-FD 100baseTx 10baseT-FD 10baseT.
Able to perform Auto-negotiation, negotiation=20
complete.
Vendor ID is =
00:aa:00:--:--:--, model=20
21 rev. 0.
No specific =
information is=20
known about this transceiver type.
I'm =
advertising 05e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD=20
10baseT
Advertising no =
additional info=20
pages.
IEEE 802.3 CSMA/CD=20
protocol.
Link partner capability is =
40a1:=20
100baseTx 10baseT.
=
Negotiation =20
completed.
Don't know what else to tell you, except that this =
is a=20
problem that I need to solve QUICKLY. Any help is more than=20
appreciated!
Best regards,
Mark
------=_NextPart_000_0011_01BEADEC.906F6860--
From david+nospam@kalifornia.com Fri Jun 4 13:34:19 1999
Date: Fri Jun 4 13:34:19 1999
From: David david+nospam@kalifornia.com
Subject: Intel EtherExpress Pro Transmitter crash with 2.2.9 (Ipv6 related?)
Alan Cox wrote:
> Try the current eepro100 driver not the one in the kernel. See if that
> helps
it doesn't. on my network it's particularly evil, every 15-30 seconds a 5-50
second storm erupts, thoroughly killing the entire segment.
ipv6 is -not- in use, only compiled in. until i get tulip cards, my solution
is to leave the cards in promiscuous mode.
-d
--
This is Linux Country. On a quiet night, you can hear Windows NT reboot!
Do you remember how to -think- ? Do you remember how to experiment? Linux
__ is an operating system that brings back the fun and adventure in computing.
\/ for linux-kernel: please read linux/Documentation/* before posting problems
From gplindstrom@exodus.nnc.edu Fri Jun 4 14:20:56 1999
Date: Fri Jun 4 14:20:56 1999
From: Lindstrom, Gary Paul gplindstrom@exodus.nnc.edu
Subject: Intel EtherExpress Pro Transmitter crash with 2.2.9 (Ipv6 re
David,
> Alan Cox wrote:
>
> > Try the current eepro100 driver not the one in the kernel. See if that
> > helps
>
> it doesn't. on my network it's particularly evil, every 15-30 seconds a 5-50
> second storm erupts, thoroughly killing the entire segment.
>
> ipv6 is -not- in use, only compiled in. until i get tulip cards, my solution
> is to leave the cards in promiscuous mode.
Yeah... You should have seen what it did to my entire network! My
novell servers were so busy processing multicast packets, they
stopped communicating with each other and doing their NDS sync, PCs
appeared to hang, linux boxes started crawling and displaying
messages about too much work on the interfaces, ... very bad
situation for over 500 computers!
However, fixed it by putting:
options eepro100 options=0x30 congenb=1 multicast_filter_limit=3
parameters in conf.modules and rebuilding initrd. I suppose the key
is the multicast_filter_limit=3. I don't really think it is ipv6
related as I did not compile it into the kernel nor did I even make a
module.
Gary
Gary Lindstrom (gplindstrom@exodus.nnc.edu)
Network/Systems/Security Manager
Northwest Nazarene College, Nampa, Idaho 83686
From alan@lxorguk.ukuu.org.uk Fri Jun 4 16:03:50 1999
Date: Fri Jun 4 16:03:50 1999
From: Alan Cox alan@lxorguk.ukuu.org.uk
Subject: Intel EtherExpress Pro Transmitter crash with 2.2.9 (Ipv6 re
> options eepro100 options=0x30 congenb=1 multicast_filter_limit=3
>
> parameters in conf.modules and rebuilding initrd. I suppose the key
> is the multicast_filter_limit=3. I don't really think it is ipv6
> related as I did not compile it into the kernel nor did I even make a
> module.
Set to default to 3 in my tree. The driver has to default to safety first.
I'll submit that on to Linus
From babydr@baby-dragons.com Fri Jun 4 16:25:25 1999
Date: Fri Jun 4 16:25:25 1999
From: Mr. James W. Laferriere babydr@baby-dragons.com
Subject: Intel EtherExpress Pro Transmitter crash with 2.2.9 (Ipv6 re
Hello Alan, Is this for builtin drivers as well
as modules ? Tia, JimL
On Fri, 4 Jun 1999, Alan Cox wrote:
> > options eepro100 options=0x30 congenb=1 multicast_filter_limit=3
> > parameters in conf.modules and rebuilding initrd. I suppose the key
> > is the multicast_filter_limit=3. I don't really think it is ipv6
> > related as I did not compile it into the kernel nor did I even make a
> > module.
> Set to default to 3 in my tree. The driver has to default to safety first.
> I'll submit that on to Linus
+-----------------------------------------------------------------+
| James W. Laferriere | System Techniques | Give me VMS |
| Network Engineer | 25416 22nd So | Give me Linux |
| babydr@baby-dragons.com | DesMoines WA 98198 | only on AXP |
+-----------------------------------------------------------------+
From wbtiny@iname.com Tue Jun 8 14:35:02 1999
Date: Tue Jun 8 14:35:02 1999
From: Andy Grundman wbtiny@iname.com
Subject: eepro100 under 2.2 = :(
Greetings,
I am experiencing the same poor network performance as some other users were
seeing. But my poor performance only goes in one direction. I am running a
100B card in a DEC Alpha SX164 on Linux 2.2.4. Sending downstream data to
the machine through this card is just as fast as any other computer on my
network, but trying to receive the same data from that card is horribly
slow.. in the range of 10-50K/sec. I originally thought it might be the hub
or the cable, but I've narrowed it down to the eepro100 driver not working
right with the 2.2 kernels. I'm recompiling/upgrading to 2.2.9 now to see
if that helps any. Does anyone know a workaround for this problem? Some of
my coworkers are complaining of the slow performance.
On another note, is there any support yet for the Pro/100+ Management
Adapter (82559)? I was going to swap out the 100B and this new card happens
to be the only spare network card around.
Thanks for any help,
-Andy Grundman
From simon@dcs.qmw.ac.uk Tue Jun 8 20:17:43 1999
Date: Tue Jun 8 20:17:43 1999
From: Simon Andrew Boggis simon@dcs.qmw.ac.uk
Subject: eepro100 under 2.2 = :(
>
> On another note, is there any support yet for the Pro/100+ Management
> Adapter (82559)? I was going to swap out the 100B and this new card happens
> to be the only spare network card around.
>
> Thanks for any help,
> -Andy Grundman
I am using 3 dual 82559's in an AMD K6400 Linux router (kernel 2.2.9) and the
(1.0.6?) eepro100.c driver. No problems (at least noone has complained) so
far, except the well known netatalk/eepro trouble which I worked around
by using the universal appletalk router (UAR) instead of netatalk - it
uses raw sockets instaed of kernel DDP support, and seems to route fine
(again, so far) without any need for tweaking module options.
Simon
Simon A. Boggis Systems Programmer
Department of Computer Science,
Queen Mary and Westfield College London, E1 4NS, UK. Telephone 0171 975 5234
From brown@osdsun1.nrl.navy.mil Fri Jun 11 09:29:41 1999
Date: Fri Jun 11 09:29:41 1999
From: Dan Brown brown@osdsun1.nrl.navy.mil
Subject: patch for i82559-based CardBus card
I recently purchased an Intel Pro/100 CardBus II pcmcia card for my
laptop. After a few days of hacking, I have created the attached patch to
eepro100.c (it's against the version included in kernel 2.3.5) which adds:
- CardBus support (via #ifdef CARDBUS)
- Some hacks which I found necessary for my card, but which I
suspect are more related to differences between the 82559 and previous
chips.
It works perfectly as a pcmcia module, and it's my hope that people with
non-cardbus (ie, PCI) i82559-based cards (do they exist?) will also find
it useful.
Since this is my first attempt at such a thing, I would greatly appreciate
it if people more familiar with this driver would take a look at this
patch.
I'm also sending this to the pcmcia folks.
---------patch follows---------
397c397,399
< static void speedo_found1(struct device *dev, long ioaddr, int irq,
---
> /* DBB: Make speedo_found1 return dev so that the pcmcia attach function can
> save it. This is a bit of a hack -- this should be cleaned up. */
> static struct device * speedo_found1(struct device *dev, long ioaddr, int irq,
495c497
< static void speedo_found1(struct device *dev, long ioaddr, int irq,
---
> static struct device * speedo_found1(struct device *dev, long ioaddr, int irq,
502c504,505
< u16 eeprom[0x40];
---
> #define EEPROM_SAVE 10
> u16 eeprom[EEPROM_SAVE];
521a525,530
> #ifdef CARDBUS
> /* DBB: the 8/6 bit test doesn't seem to work for my CardBus card,
> and it works if I force it to 8. Somebody with access to
> technical documentation should fix this :) */
> int addr_len = 8;
> #else
522a532,536
> #endif
> /* DBB: My EEPROM checksum doesn't work unless it's computed over
> the entire 256-word EEPROM. I suspect this is always true of
> cards with 8-bit EEPROMs. */
> #define EEPROM_SIZE (1< for (j = 0, i = 0; i < EEPROM_SIZE; i++) {
526c540,541
< eeprom[i] = value;
---
> if (i < EEPROM_SAVE)
> eeprom[i] = value;
563d577
< /* The self-test results must be paragraph aligned. */
565a580
> /* The self-test results must be paragraph aligned. */
645a661
>
647a664,666
> #ifndef CARDBUS
> /* DBB: this test seems to contradict the one in the 'kernel bloat' section
> above. Somebody who knows about this lock-up bug should fix this. */
651a671
> #endif
661c681
< return;
---
> return dev;
1580a1601,1653
> #ifdef CARDBUS
>
> #include
>
> static dev_node_t *speedo_attach(dev_locator_t *loc)
> {
> u8 irq;
> u32 io;
> u8 bus, devfn;
> struct device *dev;
>
> if (loc->bus != LOC_PCI) return NULL;
> bus = loc->b.pci.bus; devfn = loc->b.pci.devfn;
> printk(KERN_INFO "speedo_attach(bus %d, function %d)\n", bus, devfn);
> pcibios_read_config_dword(bus, devfn, PCI_BASE_ADDRESS_1, &io);
> pcibios_read_config_byte(bus, devfn, PCI_INTERRUPT_LINE, &irq);
> io &= ~3;
> dev = speedo_found1(NULL, io, irq, -1);
> if (dev) {
> dev_node_t *node = kmalloc(sizeof(dev_node_t), GFP_KERNEL);
> strcpy(node->dev_name, dev->name);
> node->major = node->minor = 0;
> node->next = NULL;
> MOD_INC_USE_COUNT;
> return node;
> }
> return NULL;
> }
>
> static void speedo_detach(dev_node_t *node)
> {
> struct device **devp, **next;
> printk(KERN_INFO "speedo_detach(%s)\n", node->dev_name);
> for (devp = &root_speedo_dev; *devp; devp = next) {
> next = &((struct speedo_private *)(*devp)->priv)->next_module;
> if (strcmp((*devp)->name, node->dev_name) == 0) break;
> }
> if (*devp) {
> unregister_netdev(*devp);
> kfree(*devp);
> *devp = *next;
> kfree(node);
> MOD_DEC_USE_COUNT;
> }
> }
>
> struct driver_operations speedo_ops = {
> "speedo_cb", speedo_attach, NULL, NULL, speedo_detach
> };
>
> #endif /* Cardbus support */
>
>
1592a1666
> /* DBB: Should this line be #ifndef CARDBUS? Probably not... */
1593a1668,1672
>
> #ifdef CARDBUS
> register_driver(&speedo_ops);
> return 0;
> #else
1595a1675
> #endif
1601a1682,1685
>
> #ifdef CARDBUS
> unregister_driver(&speedo_ops);
> #endif
From greg.tiller@ns.sympatico.ca Sun Jun 13 12:12:53 1999
Date: Sun Jun 13 12:12:53 1999
From: Greg Tiller greg.tiller@ns.sympatico.ca
Subject: timeout problems
I have noticed quite a few messages on the archives regarding timeouts. I
tried both an 82557 and 82559 and have the same problem. Intermittant
timeouts. dmesg shows:
eth0: Transmit timed out: status 0050 0000 at 3446815/3446829 command
000c0000.
eth0: Trying to restart the transmitter...
eth0: Transmit timed out: status 0050 0000 at 3466381/3466395 command
000c0000.
eth0: Trying to restart the transmitter...
repeats 4 or so times then comes back alive. Ususally resulting in a
disconnect. Any ideas? I am using the latest module driver from the ftp
site. Also tried an earlier one to no avail.
.
From mark@hjarding.dk Mon Jun 14 11:51:37 1999
Date: Mon Jun 14 11:51:37 1999
From: Mark Nyqvist Hjarding mark@hjarding.dk
Subject: Intel PRO/100+ Dual Port Server Adapter
This is a multi-part message in MIME format.
------=_NextPart_000_0023_01BEB68E.FC4145E0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi
Is it possible to use load balancing with an Intel PRO/100+ Dual Port =
Server Adapter under Linux?
Thank you in advance
Mark
------=_NextPart_000_0023_01BEB68E.FC4145E0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi
Is it possible to use load balancing =
with an Intel=20
PRO/100+ Dual Port Server Adapter under Linux?
Thank you in advance
Mark
------=_NextPart_000_0023_01BEB68E.FC4145E0--
From mark@hjarding.dk Mon Jun 14 12:27:51 1999
Date: Mon Jun 14 12:27:51 1999
From: Mark Nyqvist Hjarding mark@hjarding.dk
Subject: Intel PRO/100+ Dual Port Server Adapter
This is a multi-part message in MIME format.
------=_NextPart_000_0006_01BEB693.CA7D2740
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi
Is it possible to use load balancing with an Intel PRO/100+ Dual Port =
Server Adapter under Linux?
Thank you in advance
Mark
------=_NextPart_000_0006_01BEB693.CA7D2740
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi
Is it possible to use load balancing =
with an Intel=20
PRO/100+ Dual Port Server Adapter under Linux?
Thank you in advance
Mark
------=_NextPart_000_0006_01BEB693.CA7D2740--
From akuchlin@mems-exchange.org Thu Jun 17 14:04:07 1999
Date: Thu Jun 17 14:04:07 1999
From: Andrew M. Kuchling akuchlin@mems-exchange.org
Subject: eepro100 performance problems
A few weeks ago I asked about how to force an eepro100 card into
100baseT-FD mode, and got a helpful answer telling me how to do that.
However, we're still struggling to see any improvements in the card's
actual performance, for unknown reasons. netperf reports:
TCP STREAM TEST to hostname
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
65535 8192 8192 10.00 11.59
This is obviously much less performance than we're expecting to see.
Bruce, the network person who's trying to get this to work, wrote:
>Currently I am suspecting that the board is not setting itself to
>100 full duplex, possibly 100 half duplex.
>The switch is set to 100 full duplex and they are talking to each oter,
>but the speed is still piss poor. So they may be thrashing in
>negotiating full duplex or some such.
He's suggested it might be a defective board, saying:
>The reason I am
>saying this is because after setting the board to 100 FD, it was not able
>to autonegotiate with the switch, which was set to autonegotiate. After I
>switched the switch to 100 FD, it was able to make a connection. Usually
>when autonegotiation fails, it doesn't fail completely, it just keeps
>trying, the result being about 3mbs thruput.ie toggling on and off to 10
>mbs.
I've included the output of eepro100-diag, mii-diag, and the kernel
bootup below, and will happily run any other tests that are suggested.
Suggestions about how to solve this would be very welcome:
* How can we diagnose the cause of this problem?
* Is this due to a misconfiguration on our part? (Wouldn't
surprise me at all; this is all outside my past experience...)
* Could it really be a defective board?
* Is trying v1.08 of the driver likely to help, by fixing some
bug that would cause such behaviour? (The machine is located in a
clean room on the other side of the country from me, so I've been
reluctant to enter on a round of kernel recompiles.)
I can equally imagine that netperf is reporting incorrect results, or
the packet size used in the tests tickles some TCP misbehaviour in the
kernel that slows things down, but lack the experience to know whether
that's the case.
Heartfelt thanks in advance; this problem is driving us up the wall...
--
A.M. Kuchling http://starship.python.net/crew/amk/
Can't say I've ever been too fond of beginnings, myself. Messy little things.
Give me a good ending any time. You know where you are with an ending.
-- The eldest of the three Fates, in SANDMAN #57: "The Kindly Ones:1"
=========================
Kernel output on bootup (this is with kernel 2.0.35):
eepro100.c:v1.03 8/11/98 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html
eth0: OEM i82557/i82558 10/100 Ethernet at 0xb800, 00:A0:C9:EE:FA:9F, IRQ 10.
Board assembly 697680-001, Physical connectors present: RJ45
Primary interface chip i82555 PHY #1.
General self-test: passed.
Serial sub-system self-test: passed.
Internal registers self-test: passed.
ROM checksum self-test: passed (0x24c9f043).
Receiver lock-up workaround activated.
eepro100.c:v1.03 8/11/98 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html
[root@memscope scope]# ./mii-diag
Using the default interface 'eth0'.
MII PHY #1 transceiver registers:
2100 780d 02a8 0150 05e1 40a1 0001 ffff
ffff ffff ffff ffff ffff ffff ffff ffff
0a03 0000 0001 0000 0000 0000 0000 0000
0000 0000 c6e3 0000 ffff ffff ffff ffff.
Basic mode control register 0x2100: Auto-negotiation disabled!
Speed fixed at 100 mbps, full-duplex.
Basic mode status register 0x780d ... 780d.
Link status: established.
Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
Able to perform Auto-negotiation, negotiation not complete.
Vendor ID is 00:aa:00:--:--:--, model 21 rev. 0.
No specific information is known about this transceiver type.
I'm advertising 05e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT
Advertising no additional info pages.
IEEE 802.3 CSMA/CD protocol.
Link partner capability is 40a1: 100baseTx 10baseT.
Negotiation completed.
[root@memscope scope]#
I'm not sure why only 100baseTx and 10baseT are listed as the link
partner capability, but Bruce may have reconfigured the switch to
disable full-duplex mode as part of his efforts to solve this.
[root@memscope scope]# ./eepro100-diag -f -e -e
eepro100-diag.c:v0.07 2/25/98 Donald Becker (becker@cesdis.gsfc.nasa.gov)
Index #1: Found a Intel 82557 EtherExpressPro100B adapter at 0xb800.
EEPROM contents:
a000 eec9 9ffa 0100 0000 0201 4701 0000
6976 8001 4581 0009 8086 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 926e
The EEPROM checksum (should be 0xbaba) is 0xbaba.
Intel EtherExpress Pro 10/100 EEPROM contents:
Station address 00:A0:C9:EE:FA:9F.
Receiver lock-up bug exists. (The driver work-around *is* implemented.)
Board assembly 697680-001, Physical connectors present: RJ45
Primary interface chip i82555 PHY #1.
From myuen@mail.imake.com Thu Jun 17 15:31:34 1999
Date: Thu Jun 17 15:31:34 1999
From: Mark Yuen myuen@mail.imake.com
Subject: busy signals, what gives??
This is a multi-part message in MIME format.
------=_NextPart_000_00A0_01BEB8D6.6AE0EBB0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
i have a hp procurve switch 2223, connected to a single redhat 5.2 =
machine with
pro/100. once prowered up, the switch's activity light starts flashing =
nonstop. there
is no other machine or network connected to the switch. i've verified =
that there's no
problem with the network connection. when running tcpdump...nothing =
shows.
what's the card doing? how can i make the light go away?
thanks
mark
------=_NextPart_000_00A0_01BEB8D6.6AE0EBB0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
i have a hp procurve switch 2223, =
connected to a=20
single redhat 5.2 machine with
pro/100. once prowered up, the =
switch's=20
activity light starts flashing nonstop. there
is no other machine or network =
connected to the=20
switch. i've verified that there's no
problem with the network =
connection. when=20
running tcpdump...nothing shows.
what's the card doing? how can i =
make the=20
light go away?
thanks
mark
------=_NextPart_000_00A0_01BEB8D6.6AE0EBB0--
From peterm@langmuir.EECS.Berkeley.EDU Thu Jun 17 15:36:40 1999
Date: Thu Jun 17 15:36:40 1999
From: Peter Mardahl peterm@langmuir.EECS.Berkeley.EDU
Subject: eepro100 performance problems
>
> He's suggested it might be a defective board, saying:
> >The reason I am
> >saying this is because after setting the board to 100 FD, it was not abl
>e
> >to autonegotiate with the switch, which was set to autonegotiate. After
>I
> >switched the switch to 100 FD, it was able to make a connection. Usually
> >when autonegotiation fails, it doesn't fail completely, it just keeps
> >trying, the result being about 3mbs thruput.ie toggling on and off to 10
> >mbs.
Dear Andrew,
I've never had any luck getting things to autonegotiate when one
of the parties is "forced". In my case, the switch was "set" to
100MHz/FD, but my eepro100's all went to 100MHz/HD, which really
screws things up performance wise.
I don't think autonegotiation works properly when one of the parties
has been "forced".
Either set both to autonegotiate, or set both to 100MHz/FD: the
latter is the most reliable method.
The telltale for malfunction in our case was the contents of
/proc/net/dev
we had a lot of "carrier", which seemed to happen when the switch was 100MHz/FD
and the board was left to autonegotiate.
PeterM
From beckmanj@ix.netcom.com Thu Jun 17 21:06:49 1999
Date: Thu Jun 17 21:06:49 1999
From: Jack Beckman beckmanj@ix.netcom.com
Subject: eepro100 performance problems
I just gotta say, I have read all kinds of e-mails and FAQs on this card and
Linux, and I couldn't get the (*&(*& thing to work well ever (and sometimes
I managed to hang Linux solid). I swapped the board with a 3COM board in
the Win 98 client I was trying to talk to and BAM! Instant success. I think
the combo of this board and Linux is, at least for the moment, a big loser.
For the cost of cards nowadays, unless you've got a real reason to keep
these boards (or you have a ton of them) I'd get rid of them if you're
serious about using Linux.
Jack
========================================
Yes, I am an agent of Satan, but my duties are largely ceremonial.
========================================
From babydr@baby-dragons.com Thu Jun 17 23:11:47 1999
Date: Thu Jun 17 23:11:47 1999
From: Mr. James W. Laferriere babydr@baby-dragons.com
Subject: eepro100 performance problems
Hello Jack, I have three of them in -low- traffic conditions
(say workstation) that have served me very well for the last
2-1/2 yrs. there was some early difficulties with the driver
& my bios settings , not a burp since . Hth, JimL
PS: I am not saying that 3com or any other cards are bad .
I am also using 3coms & tulip based cards .
On Thu, 17 Jun 1999, Jack Beckman wrote:
> I just gotta say, I have read all kinds of e-mails and FAQs on this card and
> Linux, and I couldn't get the (*&(*& thing to work well ever (and sometimes
> I managed to hang Linux solid). I swapped the board with a 3COM board in
> the Win 98 client I was trying to talk to and BAM! Instant success. I think
> the combo of this board and Linux is, at least for the moment, a big loser.
> For the cost of cards nowadays, unless you've got a real reason to keep
> these boards (or you have a ton of them) I'd get rid of them if you're
> serious about using Linux.
>
> Jack
>
> ========================================
>
> Yes, I am an agent of Satan, but my duties are largely ceremonial.
>
> ========================================
>
>
>
>
>
>
>
>
>
+-----------------------------------------------------------------+
| James W. Laferriere | System Techniques | Give me VMS |
| Network Engineer | 25416 22nd So | Give me Linux |
| babydr@baby-dragons.com | DesMoines WA 98198 | only on AXP |
+-----------------------------------------------------------------+
From myoung@scaleable.com Fri Jun 18 10:20:00 1999
Date: Fri Jun 18 10:20:00 1999
From: Manfred Young myoung@scaleable.com
Subject: eepro100 performance problems
The original version of this card was definitely flaky at auto-negotiation.
The original card used a National Semiconductor DP83840 PHY chip; subsequent
revs of the card use an Intel 82555 PHY chip.
The 82555 does not have any auto-negotiation problems, however, as was
stated earlier, if you force one end of the cable to full-duplex, you should
force both ends.
----- Original Message -----
From: Jack Beckman
To:
Sent: Thursday, June 17, 1999 9:04 PM
Subject: RE: eepro100 performance problems
I just gotta say, I have read all kinds of e-mails and FAQs on this card and
Linux, and I couldn't get the (*&(*& thing to work well ever (and sometimes
I managed to hang Linux solid). I swapped the board with a 3COM board in
the Win 98 client I was trying to talk to and BAM! Instant success. I think
the combo of this board and Linux is, at least for the moment, a big loser.
For the cost of cards nowadays, unless you've got a real reason to keep
these boards (or you have a ton of them) I'd get rid of them if you're
serious about using Linux.
Jack
========================================
Yes, I am an agent of Satan, but my duties are largely ceremonial.
========================================
From esj@cs.fiu.edu Fri Jun 18 10:41:09 1999
Date: Fri Jun 18 10:41:09 1999
From: Eric S. Johnson esj@cs.fiu.edu
Subject: eepro100 performance problems
Make sure that your switch is also forced into FD mode. Ive basicly given up
all hope for autosensing, and force the mode on just about every device
on my network.
Also, for many tcp benchmarks you need to be carefull about the machines
you use to send and receive. Ive found that a P200 can drive 100Mbit
ether at line speed if it isn't doing anything else. Anything slower
and your are limited by CPU.
Also note that you will want to increase the socket buffers (hence the
TCP window) for these tests. Otherwise the window will constrain you.
See below.
Two identical tests. Sender is a P266 with eepro100 driver
("eepro100.c:v1.08 5/3/99 Donald Becker
http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html\n")
compiled into kernel (not module).
Receiver is a sparc ultra 2/300.
Both are full duplex on a Nortel/Bay 450T switch.
E
--
esj@vixen:/work/benchmarks/netperf 5% ./netperf.linux -H grads
TCP STREAM TEST to grads
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
8192 65535 65535 10.01 51.58
esj@vixen:~/work/benchmarks/netperf 6% ./netperf.linux -H grads -- -S 133000
-s 65536 -m 32768
TCP STREAM TEST to grads
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
133464 131070 32768 10.00 90.05
esj@vixen:~/work/benchmarks/netperf 7%
From federalstore@beer.com Sat Jun 19 19:54:19 1999
Date: Sat Jun 19 19:54:19 1999
From: federalstore@beer.com federalstore@beer.com
Subject: Welcome to federalstore.com
DO YOU NEED A TV, VCR, COMPUTER OR A STEREO?
HAVE YOU BEEN TOLD YOUR CREDIT ISN'T GOOD ENOUGH TO
FINANCE IT?
Welcome to=FederalStore.com
The New Government Employee Credit Superstore
IF YOU'RE IN THE MILITARY LONG ENOUGH TO PAY US BACK, OR
A CIVIL SERVICE = EMPLOYEE WITH AT LEAST FIVE YEARS ON THE JOB,
YOU'RE APPROVED!*
How about a SHARP 27" STEREO TELEVISION FOR $73 Per
Month (9 easy = payments)? Or maybe an AIWA 3-CD, PRO LOGIC,
STEREO HOME THEATRE SYSTEM =
FOR $88 Per Month (9 easy payments)?
We have everything you want. TVS, VCRS, COMPUTERS,
CAMCORDERS, ALL = MAJOR APPLIANCES. ALL ITEMS ARE BRAND NEW WITH
FULL FACTORY WARRANTIES = AND DELIVERED TO YOUR DOOR.
THIS IS NOT RENT TO OWN,YOU BUY IT.
sent by Email King and Associates
1790 Bonhill Rd
Mississauga, On
From akuchlin@mems-exchange.org Mon Jun 21 14:47:52 1999
Date: Mon Jun 21 14:47:52 1999
From: Andrew M. Kuchling akuchlin@mems-exchange.org
Subject: eepro100 performance problems
Manfred Young writes:
>The 82555 does not have any auto-negotiation problems, however, as was
>stated earlier, if you force one end of the cable to full-duplex, you should
>force both ends.
Thanks to everyone who's been making suggestions. They've been
helpful, and over the next week we're going to try some of them. I'll
let the list know if any of them succeed.
Most of the suggestions seem to agree that we should either force both
sides, or force neither of them. I'm assuming that it's OK to force
the card's mode using ./mii-diag -F after the card has been
initialized. Or is it better to use the options= setting? Does
setting the options require that the driver be compiled as a module?
(It's compiled into the kernel at the moment, and changing to a module
is iffy because of the machine's remote status; mess it up and it gets
annoying.)
--
A.M. Kuchling http://starship.python.net/crew/amk/
Man is a small thing, and the night is very large and full of wonders.
-- Lord Dunsany, _The Laughter of the Gods_
From keithp@ncd.com Tue Jun 22 02:39:28 1999
Date: Tue Jun 22 02:39:28 1999
From: Keith Packard keithp@ncd.com
Subject: Intel 82559 support with eepro100.c driver
This is a multi-part message in MIME format.
--------------E262E153CF25D81F40B7F9F5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I'm running an Intel 82559 ethernet chip and found a minor
problem with using the eepro100 driver; they apparently
now require the CU_CMD_BASE register to be configured
before issuing a CU_STATSADDR request; I don't know
if the CU_STATSADDR request is now an offset from
CU_CMD_BASE, but the result of *not* issuing this
command is that the 82559 locks up. The patch
is simple, move the sequence for initializing the CU_CMD_BASE
above the CU_STATSADDR command:
This diff is against 0.99B, but the same code sequence
occurs in 1.06.
Keith Packard
keithp@ncd.com
--------------E262E153CF25D81F40B7F9F5
Content-Type: text/plain; charset=us-ascii; name="eepro100.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="eepro100.diff"
--- eepro100.c Mon Jun 21 23:32:50 1999
+++ /local/src/linux300/linux/drivers/net/eepro100.c Thu Mar 25 11:11:50 1999
@@ -797,10 +797,6 @@
MOD_INC_USE_COUNT;
- wait_for_cmd_done(ioaddr + SCBCmd);
- outl(0, ioaddr + SCBPointer);
- outw(INT_MASK | CU_CMD_BASE, ioaddr + SCBCmd);
-
/* Load the statistics block address. */
wait_for_cmd_done(ioaddr + SCBCmd);
outl(virt_to_bus(&sp->lstats), ioaddr + SCBPointer);
@@ -833,6 +829,10 @@
sp->cur_tx = 1;
sp->dirty_tx = 0;
sp->tx_full = 0;
+
+ wait_for_cmd_done(ioaddr + SCBCmd);
+ outl(0, ioaddr + SCBPointer);
+ outw(INT_MASK | CU_CMD_BASE, ioaddr + SCBCmd);
dev->if_port = sp->default_port;
--------------E262E153CF25D81F40B7F9F5--
From kellyo@us.ibm.com Wed Jun 23 13:00:11 1999
Date: Wed Jun 23 13:00:11 1999
From: kellyo@us.ibm.com kellyo@us.ibm.com
Subject: 82559 Intel Chip and linux eepro100 driver
Donald,
I am getting the following error when using an IBM (actually Intel) 10/100
EtherJet PCI Management adapter with the eepro100 linux driver. Do you know of
any updated drivers for the 82559 chips? The card actually operates, but the
mac address is being misread and is showing up as the same value for every card
in the system, and in others that use the same card.
Thanks,
Kelly O'Brien
Jun 7 20:04:27 SGATT1 kernel: The PCI BIOS has not enabled this device! Upda
ting PCI command 0103->0107.
Jun 7 20:04:27 SGATT1 kernel: eepro100.c:v0.99B 4/7/98 Donald Becker linux-eepr
o100@cesdis.gsfc.nasa.gov
Jun 7 20:04:27 SGATT1 kernel: eth0: Invalid EEPROM checksum 0x21f5, check setti
ngs before activating this device!
Jun 7 20:04:27 SGATT1 kernel: eth0: Intel EtherExpress Pro 10/100 at 0x7c00, 00
:81:00:80:A6:9C, IRQ 9.
Jun 7 20:04:27 SGATT1 kernel: Receiver lock-up bug exists -- enabling work-ar
ound.
Jun 7 20:04:27 SGATT1 kernel: Board assembly 800080-000, Physical connectors
present:
Jun 7 20:04:27 SGATT1 kernel: Primary interface chip None PHY #0.
Jun 7 20:04:27 SGATT1 kernel: Forcing 10Mbs full-duplex operation.
Jun 7 20:04:27 SGATT1 kernel: General self-test: passed.
Jun 7 20:04:27 SGATT1 kernel: Serial sub-system self-test: passed.
Jun 7 20:04:27 SGATT1 kernel: Internal registers self-test: passed.
Jun 7 20:04:27 SGATT1 kernel: ROM checksum self-test: passed (0x04f4518b).
Jun 7 20:04:27 SGATT1 kernel: Receiver lock-up workaround activated.
Jun 7 20:04:27 SGATT1 kernel: The PCI BIOS has not enabled this device! Upda
ting PCI command 0103->0107.
Kelly O'Brien - AT&T Global Network Services
Spectrum 3446 Tampa, Florida
Office: 813-878-3817 (t/l 427)
Lotus Notes ID: kellyo@IBMUS
Internet: kellyo@us.ibm.com
VM: kellyo at ibmusm37
===========================================================================
"Don't let your knowledge be limited by what you already
know." - me
From kellyo@us.ibm.com Thu Jun 24 12:41:36 1999
Date: Thu Jun 24 12:41:36 1999
From: kellyo@us.ibm.com kellyo@us.ibm.com
Subject: 82559 Intel Chip and linux eepro100 driver
Donald,
I tried the new device driver as well and am still getting the following:
-----------------------------------------
Jun 23 14:36:00 SGUSTMPQA kernel: The PCI BIOS has not enabled this device!
Updating PCI command 0103->0107.
Jun 23 14:36:00 SGUSTMPQA kernel: eth0: Invalid EEPROM checksum 0x21f5, check
settings before activating this device!
Jun 23 14:36:00 SGUSTMPQA kernel: eth0: Intel PCI EtherExpress Pro100 at 0x7c40,
00:81:00:80:A6:9C, IRQ 11.
Jun 23 14:36:00 SGUSTMPQA kernel: Receiver lock-up bug exists -- enabling
work-around.
Jun 23 14:36:00 SGUSTMPQA kernel: Board assembly 800080-000, Physical
connectors present:
Jun 23 14:36:00 SGUSTMPQA kernel: Primary interface chip None PHY #0.
Jun 23 14:36:00 SGUSTMPQA kernel: Forcing 100Mbs full-duplex operation.
Jun 23 14:36:00 SGUSTMPQA kernel: General self-test: passed.
Jun 23 14:36:00 SGUSTMPQA kernel: Serial sub-system self-test: passed.
Jun 23 14:36:00 SGUSTMPQA kernel: Internal registers self-test: passed.
Jun 23 14:36:00 SGUSTMPQA kernel: ROM checksum self-test: passed (0x04f4518b).
Jun 23 14:36:00 SGUSTMPQA kernel: Receiver lock-up workaround activated.
---------------------------------------------------
I checked the driver code and it appears that it is still checking for a
checksum of 0xBABA. Is this checksum different for an 82559 than others? I
have another Intel card in it, and it is coming up with the correct mac addr,
etc. Following is it's output:
----------------------------------
Jun 23 14:36:00 SGUSTMPQA kernel: The PCI BIOS has not enabled this device!
Updating PCI command 0103->0107.
Jun 23 14:36:00 SGUSTMPQA kernel: eth1: Intel PCI EtherExpress Pro100 at 0x7c20,
00:90:27:17:B9:D2, IRQ 9.
Jun 23 14:36:00 SGUSTMPQA kernel: Board assembly 689661-004, Physical
connectors present: RJ45
Jun 23 14:36:00 SGUSTMPQA kernel: Primary interface chip i82555 PHY #1.
Jun 23 14:36:00 SGUSTMPQA kernel: Forcing 100Mbs full-duplex operation.
Jun 23 14:36:00 SGUSTMPQA kernel: General self-test: passed.
Jun 23 14:36:00 SGUSTMPQA kernel: Serial sub-system self-test: passed.
Jun 23 14:36:00 SGUSTMPQA kernel: Internal registers self-test: passed.
Jun 23 14:36:00 SGUSTMPQA kernel: ROM checksum self-test: passed (0x24c9f043).
Jun 23 14:36:00 SGUSTMPQA kernel: Receiver lock-up workaround activated.
---------------------------------
In the first one, the Primary interface chip is showing up as "NONE". Are there
any #defines that I have to set that may be affecting this?
Thanks,
Kelly O.
Kelly O'Brien - AT&T Global Network Services
Spectrum 3446 Tampa, Florida
Office: 813-878-3817 (t/l 427)
Lotus Notes ID: kellyo@IBMUS
Internet: kellyo@us.ibm.com
VM: kellyo at ibmusm37
===========================================================================
"Don't let your knowledge be limited by what you already
know." - me
Donald Becker on 06/23/99 02:19:02 PM
To: Kelly O'Brien/Tampa/IBM@IBMUS
cc: linux-eepro100@cesdis.gsfc.nasa.gov
Subject: Re: 82559 Intel Chip and linux eepro100 driver
On Wed, 23 Jun 1999 kellyo@us.ibm.com wrote:
> I am getting the following error when using an IBM (actually Intel) 10/100
> EtherJet PCI Management adapter with the eepro100 linux driver. Do you know
of
> any updated drivers for the 82559 chips? The card actually operates, but the
> mac address is being misread and is showing up as the same value for every
card
> in the system, and in others that use the same card.
...
> Jun 7 20:04:27 SGATT1 kernel: eth0: Invalid EEPROM checksum 0x21f5, check
setti
> ngs before activating this device!
One of the changes for the '559 was increasing the EEPROM size from 64 to
256 words. You'll need an updated driver to correctly read the larger
EEPROM.
http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html
ftp://cesdis.gsfc.nasa.gov/pub/linux/drivers/eepro100.c
Donald Becker becker@cesdis.gsfc.nasa.gov
USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771
301-286-0882 http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html
From kellyo@us.ibm.com Thu Jun 24 12:42:08 1999
Date: Thu Jun 24 12:42:08 1999
From: kellyo@us.ibm.com kellyo@us.ibm.com
Subject: 82559 Intel Chip and linux eepro100 driver
Donald,
Also, I ran the eepro100-diag util and am seeing the following. The first
one, which is failing as far as the eeprom readout goes, is the IBM 10/100
EtherJet PCI Management Adapter that has the 82559 chip. The second one is a
true Intel EtherExpress100 and is working fine. Both cards are functioning as
far as sending/receiving data, but the first one is not showing a correct MAC
address. It shows the same value for every box that it is installed in.
eepro100-diag.c:v0.07 2/25/98 Donald Becker (becker@cesdis.gsfc.nasa.gov)
Index #1: Found a Intel 82557 EtherExpressPro100B adapter at 0x5000.
EEPROM contents:
8100 8000 9ca6 8405 8000 8000 8000 8000
8000 8000 8000 8000 804a 8000 8000 8000
8000 8000 8000 8000 8000 8000 8000 8000
8000 8000 8000 8000 8000 8000 8000 8000
8000 8000 8000 8000 8000 8000 8000 8000
8000 8000 8000 8000 8000 8000 8000 8000
8000 8000 8000 8000 8000 8000 8000 8000
8000 8000 8000 8000 8000 8000 8000 8000
The EEPROM checksum (should be 0xbaba) is 0x21f5.
Intel EtherExpress Pro 10/100 EEPROM contents:
Station address 00:81:00:80:A6:9C.
Receiver lock-up bug exists. (The driver work-around *is* implemented.)
Board assembly 800080-000, Physical connectors present:
Primary interface chip None PHY #-1.
Index #2: Found a Intel 82557 EtherExpressPro100B adapter at 0x5040.
EEPROM contents:
9000 1727 d0b9 0000 0000 0201 4701 0000
6896 6104 4581 0009 8086 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 6a2e
The EEPROM checksum (should be 0xbaba) is 0xbaba.
Intel EtherExpress Pro 10/100 EEPROM contents:
Station address 00:90:27:17:B9:D0.
Receiver lock-up bug exists. (The driver work-around *is* implemented.)
Board assembly 689661-004, Physical connectors present: RJ45
Primary interface chip i82555 PHY #1.
Thanks,
Kelly O.
Kelly O'Brien - AT&T Global Network Services
Spectrum 3446 Tampa, Florida
Office: 813-878-3817 (t/l 427)
Lotus Notes ID: kellyo@IBMUS
Internet: kellyo@us.ibm.com
VM: kellyo at ibmusm37
===========================================================================
"Don't let your knowledge be limited by what you already
know." - me
---------------------- Forwarded by Kelly O'Brien/Tampa/IBM on 06/23/99 05:56 PM
---------------------------
Kelly O'Brien
06/23/99 03:02 PM
To: Donald Becker
cc:
From: Kelly O'Brien/Tampa/IBM@IBMUS
Subject: Re: 82559 Intel Chip and linux eepro100 driver (Document link not
converted)
Donald,
I tried the new device driver as well and am still getting the following:
-----------------------------------------
Jun 23 14:36:00 SGUSTMPQA kernel: The PCI BIOS has not enabled this device!
Updating PCI command 0103->0107.
Jun 23 14:36:00 SGUSTMPQA kernel: eth0: Invalid EEPROM checksum 0x21f5, check
settings before activating this device!
Jun 23 14:36:00 SGUSTMPQA kernel: eth0: Intel PCI EtherExpress Pro100 at 0x7c40,
00:81:00:80:A6:9C, IRQ 11.
Jun 23 14:36:00 SGUSTMPQA kernel: Receiver lock-up bug exists -- enabling
work-around.
Jun 23 14:36:00 SGUSTMPQA kernel: Board assembly 800080-000, Physical
connectors present:
Jun 23 14:36:00 SGUSTMPQA kernel: Primary interface chip None PHY #0.
Jun 23 14:36:00 SGUSTMPQA kernel: Forcing 100Mbs full-duplex operation.
Jun 23 14:36:00 SGUSTMPQA kernel: General self-test: passed.
Jun 23 14:36:00 SGUSTMPQA kernel: Serial sub-system self-test: passed.
Jun 23 14:36:00 SGUSTMPQA kernel: Internal registers self-test: passed.
Jun 23 14:36:00 SGUSTMPQA kernel: ROM checksum self-test: passed (0x04f4518b).
Jun 23 14:36:00 SGUSTMPQA kernel: Receiver lock-up workaround activated.
---------------------------------------------------
I checked the driver code and it appears that it is still checking for a
checksum of 0xBABA. Is this checksum different for an 82559 than others? I
have another Intel card in it, and it is coming up with the correct mac addr,
etc. Following is it's output:
----------------------------------
Jun 23 14:36:00 SGUSTMPQA kernel: The PCI BIOS has not enabled this device!
Updating PCI command 0103->0107.
Jun 23 14:36:00 SGUSTMPQA kernel: eth1: Intel PCI EtherExpress Pro100 at 0x7c20,
00:90:27:17:B9:D2, IRQ 9.
Jun 23 14:36:00 SGUSTMPQA kernel: Board assembly 689661-004, Physical
connectors present: RJ45
Jun 23 14:36:00 SGUSTMPQA kernel: Primary interface chip i82555 PHY #1.
Jun 23 14:36:00 SGUSTMPQA kernel: Forcing 100Mbs full-duplex operation.
Jun 23 14:36:00 SGUSTMPQA kernel: General self-test: passed.
Jun 23 14:36:00 SGUSTMPQA kernel: Serial sub-system self-test: passed.
Jun 23 14:36:00 SGUSTMPQA kernel: Internal registers self-test: passed.
Jun 23 14:36:00 SGUSTMPQA kernel: ROM checksum self-test: passed (0x24c9f043).
Jun 23 14:36:00 SGUSTMPQA kernel: Receiver lock-up workaround activated.
---------------------------------
In the first one, the Primary interface chip is showing up as "NONE". Are there
any #defines that I have to set that may be affecting this?
Thanks,
Kelly O.
Kelly O'Brien - AT&T Global Network Services
Spectrum 3446 Tampa, Florida
Office: 813-878-3817 (t/l 427)
Lotus Notes ID: kellyo@IBMUS
Internet: kellyo@us.ibm.com
VM: kellyo at ibmusm37
===========================================================================
"Don't let your knowledge be limited by what you already
know." - me
Donald Becker on 06/23/99 02:19:02 PM
To: Kelly O'Brien/Tampa/IBM@IBMUS
cc: linux-eepro100@cesdis.gsfc.nasa.gov
Subject: Re: 82559 Intel Chip and linux eepro100 driver
On Wed, 23 Jun 1999 kellyo@us.ibm.com wrote:
> I am getting the following error when using an IBM (actually Intel) 10/100
> EtherJet PCI Management adapter with the eepro100 linux driver. Do you know
of
> any updated drivers for the 82559 chips? The card actually operates, but the
> mac address is being misread and is showing up as the same value for every
card
> in the system, and in others that use the same card.
...
> Jun 7 20:04:27 SGATT1 kernel: eth0: Invalid EEPROM checksum 0x21f5, check
setti
> ngs before activating this device!
One of the changes for the '559 was increasing the EEPROM size from 64 to
256 words. You'll need an updated driver to correctly read the larger
EEPROM.
http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html
ftp://cesdis.gsfc.nasa.gov/pub/linux/drivers/eepro100.c
Donald Becker becker@cesdis.gsfc.nasa.gov
USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771
301-286-0882 http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html
From myoung@scaleable.com Thu Jun 24 15:36:21 1999
Date: Thu Jun 24 15:36:21 1999
From: Manfred Young myoung@scaleable.com
Subject: 82559 Intel Chip and linux eepro100 driver
I'm not running Linux on my machine that has an Intel EtherExpress PRO/100+
card (82559 based) but the contents of the EEPROM on that machine are:
9000 3827 DD83 0303 0000 0201 4701 0000
7270 9504 40A2 000C 8086 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
002C 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0037
These contents are completely consistent with 82557 and 82558 based cards. I
can only assume that the EEPROM contents of the IBM card are not compatible
with Intel.
----- Original Message -----
From:
To:
Sent: Thursday, June 24, 1999 12:44 PM
Subject: Re: 82559 Intel Chip and linux eepro100 driver
>
>
> Donald,
> Also, I ran the eepro100-diag util and am seeing the following. The
first
> one, which is failing as far as the eeprom readout goes, is the IBM 10/100
> EtherJet PCI Management Adapter that has the 82559 chip. The second one
is a
> true Intel EtherExpress100 and is working fine. Both cards are
functioning as
> far as sending/receiving data, but the first one is not showing a correct
MAC
> address. It shows the same value for every box that it is installed in.
>
> eepro100-diag.c:v0.07 2/25/98 Donald Becker (becker@cesdis.gsfc.nasa.gov)
> Index #1: Found a Intel 82557 EtherExpressPro100B adapter at 0x5000.
> EEPROM contents:
> 8100 8000 9ca6 8405 8000 8000 8000 8000
> 8000 8000 8000 8000 804a 8000 8000 8000
> 8000 8000 8000 8000 8000 8000 8000 8000
> 8000 8000 8000 8000 8000 8000 8000 8000
> 8000 8000 8000 8000 8000 8000 8000 8000
> 8000 8000 8000 8000 8000 8000 8000 8000
> 8000 8000 8000 8000 8000 8000 8000 8000
> 8000 8000 8000 8000 8000 8000 8000 8000
> The EEPROM checksum (should be 0xbaba) is 0x21f5.
> Intel EtherExpress Pro 10/100 EEPROM contents:
> Station address 00:81:00:80:A6:9C.
> Receiver lock-up bug exists. (The driver work-around *is* implemented.)
> Board assembly 800080-000, Physical connectors present:
> Primary interface chip None PHY #-1.
>
> Index #2: Found a Intel 82557 EtherExpressPro100B adapter at 0x5040.
> EEPROM contents:
> 9000 1727 d0b9 0000 0000 0201 4701 0000
> 6896 6104 4581 0009 8086 0000 0000 0000
> 0000 0000 0000 0000 0000 0000 0000 0000
> 0000 0000 0000 0000 0000 0000 0000 0000
> 0000 0000 0000 0000 0000 0000 0000 0000
> 0000 0000 0000 0000 0000 0000 0000 0000
> 0000 0000 0000 0000 0000 0000 0000 0000
> 0000 0000 0000 0000 0000 0000 0000 6a2e
> The EEPROM checksum (should be 0xbaba) is 0xbaba.
> Intel EtherExpress Pro 10/100 EEPROM contents:
> Station address 00:90:27:17:B9:D0.
> Receiver lock-up bug exists. (The driver work-around *is* implemented.)
> Board assembly 689661-004, Physical connectors present: RJ45
> Primary interface chip i82555 PHY #1.
>
>
> Thanks,
> Kelly O.
>
>
> Kelly O'Brien - AT&T Global Network Services
> Spectrum 3446 Tampa, Florida
> Office: 813-878-3817 (t/l 427)
> Lotus Notes ID: kellyo@IBMUS
> Internet: kellyo@us.ibm.com
> VM: kellyo at ibmusm37
>
>
===========================================================================
> "Don't let your knowledge be limited by what you already
> know." - me
>
>
> ---------------------- Forwarded by Kelly O'Brien/Tampa/IBM on 06/23/99
05:56 PM
> ---------------------------
>
>
> Kelly O'Brien
> 06/23/99 03:02 PM
>
> To: Donald Becker
> cc:
> From: Kelly O'Brien/Tampa/IBM@IBMUS
> Subject: Re: 82559 Intel Chip and linux eepro100 driver (Document link
not
> converted)
>
> Donald,
> I tried the new device driver as well and am still getting the
following:
>
> -----------------------------------------
> Jun 23 14:36:00 SGUSTMPQA kernel: The PCI BIOS has not enabled this
device!
> Updating PCI command 0103->0107.
> Jun 23 14:36:00 SGUSTMPQA kernel: eth0: Invalid EEPROM checksum 0x21f5,
check
> settings before activating this device!
> Jun 23 14:36:00 SGUSTMPQA kernel: eth0: Intel PCI EtherExpress Pro100 at
0x7c40,
> 00:81:00:80:A6:9C, IRQ 11.
> Jun 23 14:36:00 SGUSTMPQA kernel: Receiver lock-up bug exists --
enabling
> work-around.
> Jun 23 14:36:00 SGUSTMPQA kernel: Board assembly 800080-000, Physical
> connectors present:
> Jun 23 14:36:00 SGUSTMPQA kernel: Primary interface chip None PHY #0.
> Jun 23 14:36:00 SGUSTMPQA kernel: Forcing 100Mbs full-duplex operation.
> Jun 23 14:36:00 SGUSTMPQA kernel: General self-test: passed.
> Jun 23 14:36:00 SGUSTMPQA kernel: Serial sub-system self-test: passed.
> Jun 23 14:36:00 SGUSTMPQA kernel: Internal registers self-test: passed.
> Jun 23 14:36:00 SGUSTMPQA kernel: ROM checksum self-test: passed
(0x04f4518b).
> Jun 23 14:36:00 SGUSTMPQA kernel: Receiver lock-up workaround activated.
> ---------------------------------------------------
>
> I checked the driver code and it appears that it is still checking for a
> checksum of 0xBABA. Is this checksum different for an 82559 than others?
I
> have another Intel card in it, and it is coming up with the correct mac
addr,
> etc. Following is it's output:
>
> ----------------------------------
> Jun 23 14:36:00 SGUSTMPQA kernel: The PCI BIOS has not enabled this
device!
> Updating PCI command 0103->0107.
> Jun 23 14:36:00 SGUSTMPQA kernel: eth1: Intel PCI EtherExpress Pro100 at
0x7c20,
> 00:90:27:17:B9:D2, IRQ 9.
> Jun 23 14:36:00 SGUSTMPQA kernel: Board assembly 689661-004, Physical
> connectors present: RJ45
> Jun 23 14:36:00 SGUSTMPQA kernel: Primary interface chip i82555 PHY #1.
> Jun 23 14:36:00 SGUSTMPQA kernel: Forcing 100Mbs full-duplex operation.
> Jun 23 14:36:00 SGUSTMPQA kernel: General self-test: passed.
> Jun 23 14:36:00 SGUSTMPQA kernel: Serial sub-system self-test: passed.
> Jun 23 14:36:00 SGUSTMPQA kernel: Internal registers self-test: passed.
> Jun 23 14:36:00 SGUSTMPQA kernel: ROM checksum self-test: passed
(0x24c9f043).
> Jun 23 14:36:00 SGUSTMPQA kernel: Receiver lock-up workaround activated.
> ---------------------------------
>
> In the first one, the Primary interface chip is showing up as "NONE". Are
there
> any #defines that I have to set that may be affecting this?
>
> Thanks,
> Kelly O.
>
> Kelly O'Brien - AT&T Global Network Services
> Spectrum 3446 Tampa, Florida
> Office: 813-878-3817 (t/l 427)
> Lotus Notes ID: kellyo@IBMUS
> Internet: kellyo@us.ibm.com
> VM: kellyo at ibmusm37
>
>
===========================================================================
> "Don't let your knowledge be limited by what you already
> know." - me
>
>
>
>
> Donald Becker on 06/23/99 02:19:02 PM
>
> To: Kelly O'Brien/Tampa/IBM@IBMUS
> cc: linux-eepro100@cesdis.gsfc.nasa.gov
> Subject: Re: 82559 Intel Chip and linux eepro100 driver
>
>
>
>
>
> On Wed, 23 Jun 1999 kellyo@us.ibm.com wrote:
> > I am getting the following error when using an IBM (actually Intel)
10/100
> > EtherJet PCI Management adapter with the eepro100 linux driver. Do you
know
> of
> > any updated drivers for the 82559 chips? The card actually operates,
but the
> > mac address is being misread and is showing up as the same value for
every
> card
> > in the system, and in others that use the same card.
> ...
> > Jun 7 20:04:27 SGATT1 kernel: eth0: Invalid EEPROM checksum 0x21f5,
check
> setti
> > ngs before activating this device!
>
> One of the changes for the '559 was increasing the EEPROM size from 64 to
> 256 words. You'll need an updated driver to correctly read the larger
> EEPROM.
>
> http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html
> ftp://cesdis.gsfc.nasa.gov/pub/linux/drivers/eepro100.c
>
> Donald Becker becker@cesdis.gsfc.nasa.gov
> USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
> Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771
> 301-286-0882 http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html
>
>
>
>
>
>
>
>
From gbjerke@austin.polycom.com Thu Jun 24 21:29:35 1999
Date: Thu Jun 24 21:29:35 1999
From: Gary Bjerke gbjerke@austin.polycom.com
Subject: 8808 packets after a crash
Re: a post by Steve Wynne, Sun, 31 Jan 1999 13:15:44 -0500, subject
"8808-type Packets after Unrelated Crash", in the January list archive.
Steve, I just subscribed to the eepro100 mailing list, and noticed your
post in January about the 8808 packets. I couldn't find any useful
responses to it in subsequent posts.
I have seen this too, and I believe I can reproduce it at will (with a
little effort). I've ported eepro100.c to an embedded system running a
Phillips TM1100 multimedia processor. In that system, I noticed that if
the driver ran into an out-of-resource condition in the RX ring and
issued a transmit, the 82558 would start spewing 8808 frames. These are
802.3 pause frames for flow control, and they contain a timer value.
The receiving endpoint is assumed to be a switch port, which should stop
sending frames for the duration of the timeout. On my system the timer
value was about 40 seconds, and the frames were issued about every 40
seconds, thus continually renewing the timeout.
Since my test board was connected to a dumb 10BaseT hub, which by
definition is half-duplex, these frames should NEVER be issued. I tried
setting options which should disable flow control even in full duplex
mode, and still the problem occurred. My hub probably propagated the
pause frame all the way to the switch, through an intermediate hub which
was downlinked to several other hubs. The result was that a large
network segment was completely shutdown.
In your case, if your system crash resulted in the Rx ring not being
serviced (interrupts locked out by a spin loop, IP not servicing
delivered packets and so running you out of memory to refill the ring,
and so on), you would probably see this. I forced this to happen on a
Linux 2.0.34 kernel (Redhat 5.0) by no'oping the interrupt handler and
ping-flooding the ethernet controller. When I reported this to Intel,
their engineer told me that
A) I misunderstood full-duplex, and was only *assuming* that full-duplex
was disabled
B) My test was invalid, because real drivers service interrupts
C) Good drivers are written to never run out of resources
I avoided strangling the bugger, but gave up on trying to get useful
information from him. He obviously hadn't even read my email very
carefully.
From pacman-kernel@cqc.com Thu Jun 24 21:29:09 1999
Date: Thu Jun 24 21:29:09 1999
From: Alan Curry pacman-kernel@cqc.com
Subject: eepro100 frame errors with SMP
Two different machines, each with an eepro100, are racking up frame errors,
according to the statistics on the cisco switch they are connected to.
Swapping cards between these and another machine, and booting many different
kernels, leads us to believe that the problem only exists when more than one
processor is being used. This smells like a driver bug to me.
These errors show up as "TX overruns" from ifconfig on the Linux side and
frame/CRC errors from `show interfaces' on the cisco side.
We told cisco, and they're so concerned about their switch they currently
have a team trying to reproduce the problem, but as far as we know they are
still in the "how do we install RedHat?" stage.
What can I do to further track down this problem?
--
Alan Curry
From admin@intergrafix.net Thu Jun 24 21:29:03 1999
Date: Thu Jun 24 21:29:03 1999
From: System Administrator admin@intergrafix.net
Subject: eepro100 frame errors with SMP
i'm running the same driver, kernel 2.2.2..I get 1 overrun for about every
9300 good packets. on my other server it's like 1 for every 8200
-Cygnus
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Anthony J. Biacco Network Administrator/Engineer
admin@intergrafix.net Intergrafix Internet Services
"Dream as if you'll live forever, live as if you'll die today"
http://cygnus.ncohafmuta.com http://www.intergrafix.net
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
On Thu, 11 Mar 1999, Alan Curry wrote:
> Two different machines, each with an eepro100, are racking up frame errors,
> according to the statistics on the cisco switch they are connected to.
> Swapping cards between these and another machine, and booting many different
> kernels, leads us to believe that the problem only exists when more than one
> processor is being used. This smells like a driver bug to me.
>
> These errors show up as "TX overruns" from ifconfig on the Linux side and
> frame/CRC errors from `show interfaces' on the cisco side.
>
> We told cisco, and they're so concerned about their switch they currently
> have a team trying to reproduce the problem, but as far as we know they are
> still in the "how do we install RedHat?" stage.
>
> What can I do to further track down this problem?
> --
> Alan Curry
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
>
From richard.langis@intel.com Thu Jun 24 21:28:57 1999
Date: Thu Jun 24 21:28:57 1999
From: Langis, Richard richard.langis@intel.com
Subject: eepro100 frame errors with SMP
I'm no expert on anything, but I DO have a quad-processor system with one
Pro/100B and one Pro/100+, running kernel 2.2.0. ifconfig shows no TX (or
RX, for that matter) errors. cat /proc/pci shows latency at 128 for both
adapters. Unfortunately I don't have a Cisco switch hooked up to this
machine - I had to give up our 5500 temporarily - so I don't have any data
from there, but everything is working fine.
I also have a dual-processor system running 2.2.2 with one proB and it shows
very low errors/collisions (under 5).
It's probably not the driver.
-Richard
> Alan Cox wrote:
> > > >So what on your bus has a PCI latency set to 240/248 ? 8)
> > >
> > > I have no idea what that means. Is this something I can
> play with in /proc?
> >
> > cat /proc/pci look at the Latency values - its how long
> devices are allowed
> > to hog the PCI bus
>
> I suspect that it is the CPU (s) that is (are) hogging the system
> bus/memory.
>
> Roger.
From keithp@ncd.com Thu Jun 24 21:30:40 1999
Date: Thu Jun 24 21:30:40 1999
From: Keith Packard keithp@ncd.com
Subject: Intel 82559 support with eepro100.c driver
This is a multi-part message in MIME format.
--------------E262E153CF25D81F40B7F9F5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I'm running an Intel 82559 ethernet chip and found a minor
problem with using the eepro100 driver; they apparently
now require the CU_CMD_BASE register to be configured
before issuing a CU_STATSADDR request; I don't know
if the CU_STATSADDR request is now an offset from
CU_CMD_BASE, but the result of *not* issuing this
command is that the 82559 locks up. The patch
is simple, move the sequence for initializing the CU_CMD_BASE
above the CU_STATSADDR command:
This diff is against 0.99B, but the same code sequence
occurs in 1.06.
Keith Packard
keithp@ncd.com
--------------E262E153CF25D81F40B7F9F5
Content-Type: text/plain; charset=us-ascii; name="eepro100.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="eepro100.diff"
--- eepro100.c Mon Jun 21 23:32:50 1999
+++ /local/src/linux300/linux/drivers/net/eepro100.c Thu Mar 25 11:11:50 1999
@@ -797,10 +797,6 @@
MOD_INC_USE_COUNT;
- wait_for_cmd_done(ioaddr + SCBCmd);
- outl(0, ioaddr + SCBPointer);
- outw(INT_MASK | CU_CMD_BASE, ioaddr + SCBCmd);
-
/* Load the statistics block address. */
wait_for_cmd_done(ioaddr + SCBCmd);
outl(virt_to_bus(&sp->lstats), ioaddr + SCBPointer);
@@ -833,6 +829,10 @@
sp->cur_tx = 1;
sp->dirty_tx = 0;
sp->tx_full = 0;
+
+ wait_for_cmd_done(ioaddr + SCBCmd);
+ outl(0, ioaddr + SCBPointer);
+ outw(INT_MASK | CU_CMD_BASE, ioaddr + SCBCmd);
dev->if_port = sp->default_port;
--------------E262E153CF25D81F40B7F9F5--
From rsd@landofhaze.com Thu Jun 24 21:35:39 1999
Date: Thu Jun 24 21:35:39 1999
From: Rob Drummond rsd@landofhaze.com
Subject: EtherExpress Pro 100 Intelligent Server Adapter
Is there a plan in the future to add support to Linux for the Intel Pro100
Intelligent Server Adapter?
Rob
From R.E.Wolff@BitWizard.nl Fri Jun 25 04:39:31 1999
Date: Fri Jun 25 04:39:31 1999
From: Rogier Wolff R.E.Wolff@BitWizard.nl
Subject: eepro100 frame errors with SMP
Alan Curry wrote:
> Two different machines, each with an eepro100, are racking up frame errors,
> according to the statistics on the cisco switch they are connected to.
> Swapping cards between these and another machine, and booting many different
> kernels, leads us to believe that the problem only exists when more than one
> processor is being used. This smells like a driver bug to me.
>
> These errors show up as "TX overruns" from ifconfig on the Linux side and
> frame/CRC errors from `show interfaces' on the cisco side.
There are RX overruns, and TX underruns. I think you're seeing tx
underruns.
The eepro100 gets the data to be transmitted from main memory. TX
underrun happens when the main memory can't keep up with the sending
of the data onto the ethernet.
So, hardware-wise your machine is misconfigured: The eepro100 cannot
get 10Mbyte per second of throughput from main memory at times.
This is NOT a driver problem.
You could look into decreasing the "max_lat" value of all other
devices on the PCI bus, and increasing it on the eepro100.
> We told cisco, and they're so concerned about their switch they currently
> have a team trying to reproduce the problem, but as far as we know they are
> still in the "how do we install RedHat?" stage.
I suggest telling them not to worry. You've found the problem, and it
is your machine that is misconfigured....
> What can I do to further track down this problem?
/*
* perform_memcpy.c
*
*
*
* written by R.E.Wolff -- R.E.Wolff@BitWizard.nl
*
*
* date by what
* Written: Apr 23 1997 REW Initial revision.
* changes:
*
* $Log: perform_memcpy.c,v $
* Revision 1.2 1997/11/13 14:56:59 wolff
* Created RCS Log.
*
*
*
* who-is-who:
* initials full name Email address
* REW Roger E. Wolff R.E.Wolff@BitWizard.nl
*
* This program allows you to test wether the zoran chip is bothered
* by a rep; movsl instruction.
*
* */
#include
#include
#include
#include
#ifndef SIZE
#define SIZE 0x800000
#endif
unsigned char *makebuf (int size)
{
unsigned char *t;
t = malloc (size);
return t;
}
int main (int argc, char **argv)
{
unsigned char *p, *q, *r;
struct timeval start, stop;
int n=1;
int count=0;
if (argc > 1)
n = atoi (argv[1]);
p = makebuf (SIZE);
q = makebuf (SIZE);
while (n--) {
gettimeofday (&start, NULL);
__builtin_memcpy (p, q, SIZE);
gettimeofday (&stop, NULL);
printf ("Elapsed time %d: %d usecs.\n",
count++,
(stop.tv_sec - start.tv_sec) * 1000000 +
(stop.tv_usec - start.tv_usec));
r = p;
p = q;
q = r;
}
exit (0);
}
------------
Note: "SIZE" is not a parameter of the program, because it needs to
be a constant, for maximum effect.
I expect that even on single processor systems you will see the
problems. I expect that on dual processor systems you will be able to
halt almost all network activity by running two copies of this...
Roger.
--
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
------ Microsoft SELLS you Windows, Linux GIVES you the whole house ------
From myoung@scaleable.com Fri Jun 25 11:31:24 1999
Date: Fri Jun 25 11:31:24 1999
From: Manfred Young myoung@scaleable.com
Subject: eepro100 frame errors with SMP
These kind of symptoms are normally associated with NWAY negotiation
problems. Early eepro100 cards used the National Semiconductor DP83840 PHY
chip which is notoriously bad at negotiating. I suggest forcing the speed
and duplex setting on both the Linux machine and the router.
----- Original Message -----
From: Alan Curry
To: ;
Sent: Thursday, March 11, 1999 5:53 PM
Subject: eepro100 frame errors with SMP
> Two different machines, each with an eepro100, are racking up frame
errors,
> according to the statistics on the cisco switch they are connected to.
> Swapping cards between these and another machine, and booting many
different
> kernels, leads us to believe that the problem only exists when more than
one
> processor is being used. This smells like a driver bug to me.
>
> These errors show up as "TX overruns" from ifconfig on the Linux side and
> frame/CRC errors from `show interfaces' on the cisco side.
>
> We told cisco, and they're so concerned about their switch they currently
> have a team trying to reproduce the problem, but as far as we know they
are
> still in the "how do we install RedHat?" stage.
>
> What can I do to further track down this problem?
> --
> Alan Curry
>
From myoung@scaleable.com Fri Jun 25 12:21:21 1999
Date: Fri Jun 25 12:21:21 1999
From: Manfred Young myoung@scaleable.com
Subject: 8808 packets after a crash
82558 and 82559 based EtherExpress cards can be configured to send/receive
flow control frames.
eepro100.c always enables this flow control. Byte 19 of i82558_config_cmd is
used to enable/disable flow control. This byte is initialized to 0xBD; set
it to 0x80 to disable flow control.
I believe that there should be an option to control this setting.
----- Original Message -----
From: Gary Bjerke
To:
Cc:
Sent: Friday, April 09, 1999 12:06 PM
Subject: 8808 packets after a crash
> Re: a post by Steve Wynne, Sun, 31 Jan 1999 13:15:44 -0500, subject
> "8808-type Packets after Unrelated Crash", in the January list archive.
>
> Steve, I just subscribed to the eepro100 mailing list, and noticed your
> post in January about the 8808 packets. I couldn't find any useful
> responses to it in subsequent posts.
>
> I have seen this too, and I believe I can reproduce it at will (with a
> little effort). I've ported eepro100.c to an embedded system running a
> Phillips TM1100 multimedia processor. In that system, I noticed that if
> the driver ran into an out-of-resource condition in the RX ring and
> issued a transmit, the 82558 would start spewing 8808 frames. These are
> 802.3 pause frames for flow control, and they contain a timer value.
> The receiving endpoint is assumed to be a switch port, which should stop
> sending frames for the duration of the timeout. On my system the timer
> value was about 40 seconds, and the frames were issued about every 40
> seconds, thus continually renewing the timeout.
>
> Since my test board was connected to a dumb 10BaseT hub, which by
> definition is half-duplex, these frames should NEVER be issued. I tried
> setting options which should disable flow control even in full duplex
> mode, and still the problem occurred. My hub probably propagated the
> pause frame all the way to the switch, through an intermediate hub which
> was downlinked to several other hubs. The result was that a large
> network segment was completely shutdown.
>
> In your case, if your system crash resulted in the Rx ring not being
> serviced (interrupts locked out by a spin loop, IP not servicing
> delivered packets and so running you out of memory to refill the ring,
> and so on), you would probably see this. I forced this to happen on a
> Linux 2.0.34 kernel (Redhat 5.0) by no'oping the interrupt handler and
> ping-flooding the ethernet controller. When I reported this to Intel,
> their engineer told me that
>
> A) I misunderstood full-duplex, and was only *assuming* that full-duplex
> was disabled
> B) My test was invalid, because real drivers service interrupts
> C) Good drivers are written to never run out of resources
>
> I avoided strangling the bugger, but gave up on trying to get useful
> information from him. He obviously hadn't even read my email very
> carefully.
>
From jeffrey.hundstad@mankato.msus.edu Fri Jun 25 12:43:02 1999
Date: Fri Jun 25 12:43:02 1999
From: Jeffrey Hundstad jeffrey.hundstad@mankato.msus.edu
Subject: EtherExpress Pro 100 Intelligent Server Adapter
On 24 Jun, Rob Drummond wrote:
> Is there a plan in the future to add support to Linux for the Intel Pro100
> Intelligent Server Adapter?
>
>
>
>
> Rob
The FAQ suggest that there will NOT be.
http://cesdis.gsfc.nasa.gov/linux/drivers/index.html#PCI
Unsupported boards
No board with an on-board processor is supported, because these
invariably have a proprietary/undocumented interface. (EEPro Server
and Matrox multiport PCI switch cards fall into this category.)
From curtis_brune@workspot.com Fri Jun 25 14:14:07 1999
Date: Fri Jun 25 14:14:07 1999
From: Curtis Brune curtis_brune@workspot.com
Subject: SONY SuperSlim VIAO
Howdy,
I just bought a SONY PCG-Z505S notebook that comes with an integrated
Ethernet adapter. THe Windows98 system identifies the adapter as
Intel 8255x-based PCI Ethernet Adapter (10/100)
Is the eepro100 module the right network driver for this adapter?
Has anyone tried to make this adapter work on the VAIO before?
I plan to "try it anyway" and see what happens. I'll be using
Debian/GNU Linux 2.1 and kernel 2.2.6. I'll let you know how it goes.
Cheers,
Curt
From myoung@scaleable.com Fri Jun 25 15:24:58 1999
Date: Fri Jun 25 15:24:58 1999
From: Manfred Young myoung@scaleable.com
Subject: 8808 packets after a crash
I agree that a network card shouldn't send flow control packets when it's
running half-duplex, but the EtherExpress does if it's configured to do so.
eepro100.c could be modified to enable flow control only if the link is
running full-duplex.
----- Original Message -----
From: Gary Bjerke
To: Manfred Young
Sent: Friday, June 25, 1999 2:38 PM
Subject: Re: 8808 packets after a crash
> Manfred Young wrote:
>
> > 82558 and 82559 based EtherExpress cards can be configured to
send/receive
> > flow control frames.
> >
> > eepro100.c always enables this flow control. Byte 19 of
i82558_config_cmd is
> > used to enable/disable flow control. This byte is initialized to 0xBD;
set
> > it to 0x80 to disable flow control.
> >
> > I believe that there should be an option to control this setting.
>
> An endpoint connected to a half-duplex hub is never supposed to issue
> flow-control packets. The option byte is supposed to allow the 82558/9 to
use
> flow control on full-duplex links only. The programmer's manual uses the
> qualifying phrase "full-duplex" in more than one place in discussing flow
> control options. In any case, I've tried all possible settings that
explicitly
> disable full-duplex, and have still occasionally gotten transmit lockups
with
> PAUSE frames.
>
> Here is what it says on page 150 of "Gigabit Ethernet" by Kadambi,
Crayford,
> and Kalkunte:
>
> "The PAUSE frame is restricted to use within full-duplex 802.3 stations
only.
> By definition, a full-duplex Ethernet station has a single point-to-point
link
> to another single Ethernet station."
>
> This is a little misleading, as one link partner might be a full-duplex
switch
> port. The key issue is that, because the other partner is full-duplex and
> flow-control compliant, it does not propagate the packet. If an 82559
sprays
> PAUSE frames to a half-duplex hub, they propagate to every endpoint, and
> potentially cause all endpoints to lock up because one endpoint is having
> problems. The normal scenario for flow control would be, for example, a
single
> high-capacity server connected directly to a switch port. Throttling back
the
> server does not take a whole segment down - throttling back through a hub
does.
>
>
>
> >
> >
> > ----- Original Message -----
> > From: Gary Bjerke
> > To:
> > Cc:
> > Sent: Friday, April 09, 1999 12:06 PM
> > Subject: 8808 packets after a crash
> >
> > > Re: a post by Steve Wynne, Sun, 31 Jan 1999 13:15:44 -0500, subject
> > > "8808-type Packets after Unrelated Crash", in the January list
archive.
> > >
> > > Steve, I just subscribed to the eepro100 mailing list, and noticed
your
> > > post in January about the 8808 packets. I couldn't find any useful
> > > responses to it in subsequent posts.
> > >
> > > I have seen this too, and I believe I can reproduce it at will (with a
> > > little effort). I've ported eepro100.c to an embedded system running a
> > > Phillips TM1100 multimedia processor. In that system, I noticed that
if
> > > the driver ran into an out-of-resource condition in the RX ring and
> > > issued a transmit, the 82558 would start spewing 8808 frames. These
are
> > > 802.3 pause frames for flow control, and they contain a timer value.
> > > The receiving endpoint is assumed to be a switch port, which should
stop
> > > sending frames for the duration of the timeout. On my system the timer
> > > value was about 40 seconds, and the frames were issued about every 40
> > > seconds, thus continually renewing the timeout.
> > >
> > > Since my test board was connected to a dumb 10BaseT hub, which by
> > > definition is half-duplex, these frames should NEVER be issued. I
tried
> > > setting options which should disable flow control even in full duplex
> > > mode, and still the problem occurred. My hub probably propagated the
> > > pause frame all the way to the switch, through an intermediate hub
which
> > > was downlinked to several other hubs. The result was that a large
> > > network segment was completely shutdown.
> > >
> > > In your case, if your system crash resulted in the Rx ring not being
> > > serviced (interrupts locked out by a spin loop, IP not servicing
> > > delivered packets and so running you out of memory to refill the ring,
> > > and so on), you would probably see this. I forced this to happen on a
> > > Linux 2.0.34 kernel (Redhat 5.0) by no'oping the interrupt handler and
> > > ping-flooding the ethernet controller. When I reported this to Intel,
> > > their engineer told me that
> > >
> > > A) I misunderstood full-duplex, and was only *assuming* that
full-duplex
> > > was disabled
> > > B) My test was invalid, because real drivers service interrupts
> > > C) Good drivers are written to never run out of resources
> > >
> > > I avoided strangling the bugger, but gave up on trying to get useful
> > > information from him. He obviously hadn't even read my email very
> > > carefully.
> > >
>
From rsd@landofhaze.com Fri Jun 25 20:41:34 1999
Date: Fri Jun 25 20:41:34 1999
From: Rob Drummond rsd@landofhaze.com
Subject: EtherExpress Pro 100 Intelligent Server Adapter
Rats, cause I think it'd be a great thing if it did cause if it can work
wonders for windows NT, think of what it could do for Linux
-----Original Message-----
From: Jeffrey Hundstad
[mailto:jeffrey.hundstad@mankato.msus.edu]
Sent: Friday, June 25, 1999 1242
To: rsd@landofhaze.com
Cc: linux-eepro100@cesdis1.gsfc.nasa.gov
Subject: Re: EtherExpress Pro 100 Intelligent Server
Adapter
On 24 Jun, Rob Drummond wrote:
> Is there a plan in the future to add support to Linux for
the Intel Pro100
> Intelligent Server Adapter?
>
>
>
>
> Rob
The FAQ suggest that there will NOT be.
http://cesdis.gsfc.nasa.gov/linux/drivers/index.html#PCI
Unsupported boards
No board with an on-board processor is supported, because
these
invariably have a proprietary/undocumented interface. (EEPro
Server
and Matrox multiport PCI switch cards fall into this
category.)
From rsd@landofhaze.com Fri Jun 25 22:35:56 1999
Date: Fri Jun 25 22:35:56 1999
From: Rob Drummond rsd@landofhaze.com
Subject: EtherExpress Pro 100 Intelligent Server Adapter
I dunno, I guess it is personal preference.
-----Original Message-----
From: Donald Becker [mailto:becker@cesdis.gsfc.nasa.gov]
Sent: Friday, June 25, 1999 2239
To: Rob Drummond
Cc: 'Jeffrey Hundstad';
linux-eepro100@cesdis.gsfc.nasa.gov
Subject: RE: EtherExpress Pro 100 Intelligent Server
Adapter
On Fri, 25 Jun 1999, Rob Drummond wrote:
> Rats, cause I think it'd be a great thing if it did cause
if it can work
> wonders for windows NT, think of what it could do for
Linux
It's not clear how much an on-board processor can help vs.
hardware that
does IP/UDP/TCP checksumming in hardware, such as the
3c905B.
Donald Becker
becker@cesdis.gsfc.nasa.gov
USRA-CESDIS, Center of Excellence in Space Data and
Information Sciences.
Code 930.5, Goddard Space Flight Center, Greenbelt, MD.
20771
301-286-0882
http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html
From kellyo@us.ibm.com Sat Jun 26 08:11:04 1999
Date: Sat Jun 26 08:11:04 1999
From: kellyo@us.ibm.com kellyo@us.ibm.com
Subject: New version of eepro100-diag.c (ref: IBM 82559 board)
Here's the new output. We also powered off and unplugged the device (read
info about PnP devices giving this result) and
ran it again, but got the same results.
eepro100-diag.c:v0.08 6/25/99 Donald Becker (becker@cesdis.gsfc.nasa.gov)
Index #1: Found a Intel 82557 EtherExpressPro100B adapter at 0xf3eff000.
EEPROM address size probe returns 0xfffffff.
EEPROM contents:
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
The EEPROM checksum (should be 0xbaba) is 0xffc0.
Intel EtherExpress Pro 10/100 EEPROM contents:
Station address FF:FF:FF:FF:FF:FF.
Board assembly ffffff-255, Physical connectors present: RJ45 BNC AUI MII
Primary interface chip i82555 PHY #-1.
Secondary interface chip i82555, PHY -1.
Kelly O'Brien - AT&T Global Network Services
Spectrum 3446 Tampa, Florida
Office: 813-878-3817 (t/l 427)
Lotus Notes ID: kellyo@IBMUS
Internet: kellyo@us.ibm.com
VM: kellyo at ibmusm37
===========================================================================
"Don't let your knowledge be limited by what you already
know." - me
Donald Becker on 06/25/99 10:58:05 AM
To: Kelly O'Brien/Tampa/IBM@IBMUS
cc: linux-eepro100@cesdis.gsfc.nasa.gov
Subject: New version of eepro100-diag.c (ref: IBM 82559 board)
I've added code to eepro100-diag.c so that we may track this problem down.
ftp://cesdis.gsfc.nasa.gov/pub/linux/diag/eepro100-diag.c
http://cesdis.gsfc.nasa.gov/linux/diag/index.html
(Actually, I did a major restructuring, udpated it to work better with
2.2.* kernels, etc.)
Please run
eepro100-diag -ee
and report what the line
printf("EEPROM address size probe returns %#x.\n", ee_addr_size);
outputs.
On Thu, 24 Jun 1999 kellyo@us.ibm.com wrote:
> Subject: Re: 82559 Intel Chip and linux eepro100 driver
> I tried the new device driver as well and am still getting the following:
> eth0: Invalid EEPROM checksum 0x21f5, check settings before activating this
device!
> > I am getting the following error when using an IBM (actually Intel) 10/100
> > EtherJet PCI Management adapter with the eepro100 linux driver. Do you know
Donald Becker becker@cesdis.gsfc.nasa.gov
USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771
301-286-0882 http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html
From jc@rochester.rr.com Sat Jun 26 12:56:39 1999
Date: Sat Jun 26 12:56:39 1999
From: Jon Christiansen jc@rochester.rr.com
Subject: 82559 Intel Pro/100+ Management Adapter results.... plus Transmit timed out error message in messages file
Make sure you check the IO port address that the driver shows you for your
card is the same eepro-diag uses, mine wasn't and I was getting similar
results as you.
Below is my output from eepro100-diag.
My configuration is I have cable modem into RH6.0 Linux box (Dell Single
Pentium Pro 200) with 10Mbps 3Com card (eth0), then have Intel EtherExpress
Pro/100 Management Adapter in Linux box (eth1) with crossover cable
connection to identical card in Win98 machine.
Intel Windows control panel shows full duplex and 100Mbps.
At the bottom of this email, you can see the transmit time out error
messages I get occassionally.
eepro100-diag -fee (determines an incorrect port # for some reason)
-------------------------------------------------------------------
eepro100-diag.c:v0.08 6/25/99 Donald Becker (becker@cesdis.gsfc.nasa.gov)
Index #1: Found a Intel 82557 EtherExpressPro100B adapter at 0xcc000.
EEPROM address size probe returns 0xfffffff.
EEPROM contents:
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
The EEPROM checksum (should be 0xbaba) is 0xffc0.
Intel EtherExpress Pro 10/100 EEPROM contents:
Station address FF:FF:FF:FF:FF:FF.
Board assembly ffffff-255, Physical connectors present: RJ45 BNC AUI MII
Primary interface chip i82555 PHY #-1.
Secondary interface chip i82555, PHY -1.
eepro-diag -fee -p 0xfe80 (giving it the same port address the driver gives
during ifup)
----------------------------------------------------------------------------
------------
eepro100-diag.c:v0.08 6/25/99 Donald Becker (becker@cesdis.gsfc.nasa.gov)
Assuming a Intel 82557 EtherExpressPro100B adapter at 0xfe80.
EEPROM address size probe returns 0xffa4003.
EEPROM contents:
9000 4e27 9baa 0203 0000 0201 4701 0000
7213 8306 40a2 000c 8086 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0028 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 3f6f
The EEPROM checksum (should be 0xbaba) is 0xbaba.
Intel EtherExpress Pro 10/100 EEPROM contents:
Station address 00:90:27:4E:AA:9B.
Board assembly 721383-006, Physical connectors present: RJ45
Primary interface chip i82555 PHY #1.
mii-diag:
---------
Basic registers of MII PHY #1: 3000 782d 02a8 0154 05e1 45e1 0001 0000.
Basic mode control register 0x3000: Auto-negotiation enabled.
You have link beat, and everything is working OK.
Your link partner can do 45e1: Flow-control 100baseTx-FD 100baseTx
10baseT-FD 10baseT.
dmesg at boot:
--------------
eepro100.c:v1.08 5/3/99 Donald Becker
http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html
PCI latency timer (CFLT) is unreasonably low at 24. Setting to 32 clocks.
eth1: Intel PCI EtherExpress Pro100 at 0xfe80, 00:90:27:4E:AA:9B, IRQ 9.
Receiver lock-up bug exists -- enabling work-around.
Board assembly 721383-006, Physical connectors present: RJ45
Primary interface chip i82555 PHY #1.
General self-test: passed.
Serial sub-system self-test: passed.
Internal registers self-test: passed.
ROM checksum self-test: passed (0x04f4518b).
dmesg after awhile with my system running:
------------------------------------------
Jun 20 21:23:35 d185fcedb kernel: eth1: Transmit timed out: status 0050
0000 at 304632/304646 command 000c0000.
Jun 20 21:23:35 d185fcedb kernel: eth1: Trying to restart the transmitter...
Jun 20 21:27:05 d185fcedb kernel: eth1: Transmit timed out: status 0050
0000 at 304791/304805 command 000c0000.
Jun 20 21:27:05 d185fcedb kernel: eth1: Trying to restart the transmitter...
Jun 20 23:24:15 d185fcedb kernel: eth1: Transmit timed out: status 0050
0000 at 311895/311909 command 000c0000.
Jun 20 23:24:15 d185fcedb kernel: eth1: Trying to restart the transmitter...
From curtis_brune@workspot.com Sun Jun 27 04:39:15 1999
Date: Sun Jun 27 04:39:15 1999
From: Curtis Brune curtis_brune@workspot.com
Subject: SONY SuperSlim VAIO
Prelim results of using the internal ethernet adapter of the Sony VAIO
Z505S with Debian GNU/Linux.
1. booted Debian install off of CD-ROM drive; for examples of installing
linux on SONY super-slim VAIO check out
http://home.rochester.rr.com/specht/505/index.html and
http://www.joechiu.com/computing/vaio/linuxon505.html
though neither of these describes the Z505S model explicitly.
2. you have to add append="ide1=0x180,0x386" to the lilo boot parameters
to get the CD-ROM drive to work. See the above links for why.
3. This VAIO model uses USB to connect the floppy drive; nice under
windows since for the other VAIO models you have to reboot your machine
when you add the floppy drive.
4. install the base system and selected the "eepro100" during the
install. I did not add any additional parameters. The system said
"module installed successfully". Great.
5. reboot the sytem and boot linux from the hard drive. Listed below
is from my boot log. There's a bunch of errors from eth0. Any clues?
eepro100.c:v0.99B 4/7/98 Donald Becker ...
The PCI BIOS has not enabled this device! Updating PCI command
0013->0017.
eepro100.c:v0.99B 4/7/98 Donald Becker ...
eth0: Invalid EEPROM checksum 0xffc0, check settings before activating
this device!
eth0: OEM i82557/i82558 10/100 Ethernet at 0xfcc0, FF:FF:FF:FF:FF:FF,
IRQ 9.
Receiver lock-up bug exists -- enabling work-around
Board assembly ffffff-255, Physical connectors present: RJ45 BNC AUI
MII
Primary interface chip unknown-15 PHY #31.
Secondary interface chip i82557.
Verify that the card is a bus-master capable slot.
Self test failed, status ffffffff:
Failure to initialize the i82557.
Verify that the card is a bus-master capable slot.
After booting up I get the following two lines printed ot the console
every 10 seconds or so:
eth0: Transmit timed out: status ffff command ffff.
eth0: Trying to restart the transmitter...
Cheers,
Curt
Here /proc/pci and /proc/interrupts
0: 250912 timer
1: 1091 keyboard
2: 0 cascade
8: 3 + rtc
9: 0 Intel EtherExpress Pro 10/100 Ethernet
11: 0 + ide1
13: 1 math error
14: 2298 + ide0
...
Bus 0, device 6, function 0:
Ethernet controller: Intel 82557 (rev 8).
Medium devsel. Fast back-to-back capable. IRQ 9. Master Capable.
Latency=66. Min Gnt=8.Max Lat=56.
Non-prefetchable 32 bit memory at 0xfecff000.
I/O at 0xfcc0.
Non-prefetchable 32 bit memory at 0xfed00000.
Donald Becker wrote:
>
> On Fri, 25 Jun 1999, Curtis Brune wrote:
>
> > I just bought a SONY PCG-Z505S notebook that comes with an integrated
> > Ethernet adapter. THe Windows98 system identifies the adapter as
>
> I've been looking at the 505 for myself.
>
> > Intel 8255x-based PCI Ethernet Adapter (10/100)
>
> Read /proc/pci for the real chip type.
>
> > Is the eepro100 module the right network driver for this adapter?
>
> Yes.
>
> Please send me a report ASAP.
>
> Donald Becker becker@cesdis.gsfc.nasa.gov
> USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
> Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771
> 301-286-0882 http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html
From robin@takeover.wish.net Sun Jun 27 13:45:44 1999
Date: Sun Jun 27 13:45:44 1999
From: robin@takeover.wish.net robin@takeover.wish.net
Subject: restart transmitter
hi,
Could someone help me please:
Jun 27 19:04:44 grumpy kernel: eth0: Trying to restart the transmitter...
Jun 27 19:04:49 grumpy kernel: eth0: Transmit timed out: status 0050 0090 at
8539780/8539795 command 000c0000.
Jun 27 19:04:49 grumpy kernel: eth0: Trying to restart the transmitter...
Jun 27 19:04:54 grumpy kernel: eth0: Transmit timed out: status 0050 0090 at
8539780/8539795 command 000c0000.
Jun 27 19:04:54 grumpy kernel: eth0: Trying to restart the transmitter...
Jun 27 19:04:59 grumpy kernel: eth0: Transmit timed out: status 0050 0090 at
8539780/8539795 command 000c0000.
I'm using linux v2.2.10-ac3 and two Intel EEPRO 110 cards.
From Stephen.Rothwell@oak.sdc.nec.com.au Sun Jun 27 22:58:09 1999
Date: Sun Jun 27 22:58:09 1999
From: Stephen.Rothwell@oak.sdc.nec.com.au Stephen.Rothwell@oak.sdc.nec.com.au
Subject: Intel 82559
Hi all,
[I am not subscribed, so please cc me on answers, thanks.]
Will the eepro100 driver work with the 82559 chip?
Cheers,
Stephen
--
Stephen Rothwell Stephen.Rothwell@nec.com.au
NEC Australia Phone: +61-2-62508747
Information Systems Group Fax: +61-2-62508746
Canberra, Australia Mobile: +61-417-575843
From curtis_brune@workspot.com Sun Jun 27 23:08:43 1999
Date: Sun Jun 27 23:08:43 1999
From: Curtis Brune curtis_brune@workspot.com
Subject: SONY SuperSlim VAIO
Latest news. The ethernet adapter works! The trick was to turn off the
Plug-n-Play OS option from the BIOS. It was in the Ethernet-HOWTO
(excerpted)
3.7.3. PCI machine detects card but driver fails probe.
Newer PCI BIOSes may not enable all PCI cards at power-up, especially
if the BIOS option `PNP OS' is enabled. This mis-feature is to support
the next release of Windows which still uses some real-mode drivers.
Either disable this option, or try and upgrade to a newer driver which
has the code to enable a disabled card.
This was using the vanilla Debian/GNU Linux 2.1 distribution which uses
kernel 2.0.36 . Plan to upgrade to 2.2.10 as soon possible, because I
need USB support bad .... the floopy drive depends on it.
Cheers,
Curt
Curtis Brune wrote:
>
> Prelim results of using the internal ethernet adapter of the Sony VAIO
> Z505S with Debian GNU/Linux.
>
> 1. booted Debian install off of CD-ROM drive; for examples of installing
> linux on SONY super-slim VAIO check out
> http://home.rochester.rr.com/specht/505/index.html and
> http://www.joechiu.com/computing/vaio/linuxon505.html
>
> though neither of these describes the Z505S model explicitly.
>
> 2. you have to add append="ide1=0x180,0x386" to the lilo boot parameters
> to get the CD-ROM drive to work. See the above links for why.
>
> 3. This VAIO model uses USB to connect the floppy drive; nice under
> windows since for the other VAIO models you have to reboot your machine
> when you add the floppy drive.
>
> 4. install the base system and selected the "eepro100" during the
> install. I did not add any additional parameters. The system said
> "module installed successfully". Great.
>
> 5. reboot the sytem and boot linux from the hard drive. Listed below
> is from my boot log. There's a bunch of errors from eth0. Any clues?
>
> eepro100.c:v0.99B 4/7/98 Donald Becker ...
> The PCI BIOS has not enabled this device! Updating PCI command
> 0013->0017.
> eepro100.c:v0.99B 4/7/98 Donald Becker ...
> eth0: Invalid EEPROM checksum 0xffc0, check settings before activating
> this device!
> eth0: OEM i82557/i82558 10/100 Ethernet at 0xfcc0, FF:FF:FF:FF:FF:FF,
> IRQ 9.
> Receiver lock-up bug exists -- enabling work-around
> Board assembly ffffff-255, Physical connectors present: RJ45 BNC AUI
> MII
> Primary interface chip unknown-15 PHY #31.
> Secondary interface chip i82557.
> Verify that the card is a bus-master capable slot.
> Self test failed, status ffffffff:
> Failure to initialize the i82557.
> Verify that the card is a bus-master capable slot.
>
> After booting up I get the following two lines printed ot the console
> every 10 seconds or so:
>
> eth0: Transmit timed out: status ffff command ffff.
> eth0: Trying to restart the transmitter...
>
> Cheers,
> Curt
>
> Here /proc/pci and /proc/interrupts
> 0: 250912 timer
> 1: 1091 keyboard
> 2: 0 cascade
> 8: 3 + rtc
> 9: 0 Intel EtherExpress Pro 10/100 Ethernet
> 11: 0 + ide1
> 13: 1 math error
> 14: 2298 + ide0
>
> ...
> Bus 0, device 6, function 0:
> Ethernet controller: Intel 82557 (rev 8).
> Medium devsel. Fast back-to-back capable. IRQ 9. Master Capable.
> Latency=66. Min Gnt=8.Max Lat=56.
> Non-prefetchable 32 bit memory at 0xfecff000.
> I/O at 0xfcc0.
> Non-prefetchable 32 bit memory at 0xfed00000.
>
> Donald Becker wrote:
> >
> > On Fri, 25 Jun 1999, Curtis Brune wrote:
> >
> > > I just bought a SONY PCG-Z505S notebook that comes with an integrated
> > > Ethernet adapter. THe Windows98 system identifies the adapter as
> >
> > I've been looking at the 505 for myself.
> >
> > > Intel 8255x-based PCI Ethernet Adapter (10/100)
> >
> > Read /proc/pci for the real chip type.
> >
> > > Is the eepro100 module the right network driver for this adapter?
> >
> > Yes.
> >
> > Please send me a report ASAP.
> >
> > Donald Becker becker@cesdis.gsfc.nasa.gov
> > USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
> > Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771
> > 301-286-0882 http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html
From kellyo@us.ibm.com Mon Jun 28 09:56:42 1999
Date: Mon Jun 28 09:56:42 1999
From: kellyo@us.ibm.com kellyo@us.ibm.com
Subject: New version of eepro100-diag.c (ref: IBM 82559 board)
Over the weekend, we looked at the updated diag code and saw what we thought
might have been the reason that we were getting all x'ffff's. It appeared that
it was using an address of "pciaddr0" instead of "pciaddr1". We changed it and
recompiled and it now shows the output similar to the previous ones where the
macaddr is incorrect:
eepro100-diag.c:v0.08 6/25/99 Donald Becker (becker@cesdis.gsfc.nasa.gov)
Index #1: Found a Intel 82557 EtherExpressPro100B adapter at 0x7c40.
EEPROM address size probe returns 0xffe0400.
EEPROM contents:
8100 8000 9ca6 8405 8000 8000 8000 8000
8000 8000 8000 8000 808a 8000 8000 8000
8000 8000 8000 8000 8000 8000 8000 8000
8000 8000 8000 8000 8000 8000 8000 8000
8000 8000 8000 8000 8000 8000 8000 8000
8000 8000 8000 8000 8000 8000 8000 8000
8000 8000 8000 8000 8000 8000 8000 8000
8000 8000 8000 8000 8000 8000 8000 8000
The EEPROM checksum (should be 0xbaba) is 0x2235.
Intel EtherExpress Pro 10/100 EEPROM contents:
Station address 00:81:00:80:A6:9C.
Receiver lock-up bug exists. (The driver work-around *is* implemented.)
Board assembly 800080-000, Physical connectors present:
Primary interface chip None PHY #-1.
We also tried it with the old adapter that has always worked (85558 based IBM
EtherJet with WOL) and it still works with that one.
Thanks,
Kelly O.
Kelly O'Brien - AT&T Global Network Services
Spectrum 3446 Tampa, Florida
Office: 813-878-3817 (t/l 427)
Lotus Notes ID: kellyo@IBMUS
Internet: kellyo@us.ibm.com
VM: kellyo at ibmusm37
===========================================================================
"Don't let your knowledge be limited by what you already
know." - me
Donald Becker on 06/25/99 10:58:05 AM
To: Kelly O'Brien/Tampa/IBM@IBMUS
cc: linux-eepro100@cesdis.gsfc.nasa.gov
Subject: New version of eepro100-diag.c (ref: IBM 82559 board)
I've added code to eepro100-diag.c so that we may track this problem down.
ftp://cesdis.gsfc.nasa.gov/pub/linux/diag/eepro100-diag.c
http://cesdis.gsfc.nasa.gov/linux/diag/index.html
(Actually, I did a major restructuring, udpated it to work better with
2.2.* kernels, etc.)
Please run
eepro100-diag -ee
and report what the line
printf("EEPROM address size probe returns %#x.\n", ee_addr_size);
outputs.
On Thu, 24 Jun 1999 kellyo@us.ibm.com wrote:
> Subject: Re: 82559 Intel Chip and linux eepro100 driver
> I tried the new device driver as well and am still getting the following:
> eth0: Invalid EEPROM checksum 0x21f5, check settings before activating this
device!
> > I am getting the following error when using an IBM (actually Intel) 10/100
> > EtherJet PCI Management adapter with the eepro100 linux driver. Do you know
Donald Becker becker@cesdis.gsfc.nasa.gov
USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771
301-286-0882 http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html
From becker@cesdis1.gsfc.nasa.gov Mon Jun 28 20:02:28 1999
Date: Mon Jun 28 20:02:28 1999
From: Donald Becker becker@cesdis1.gsfc.nasa.gov
Subject: v1.00 of eepro100-diag.c released.
Source code
ftp://cesdis.gsfc.nasa.gov/pub/linux/diag/eepro100-diag.c
Instructions
http://cesdis.gsfc.nasa.gov/linux/diag/index.html
This is the first "designated release" version of the EEPro100 diagnostic/setup
program. It has the following changes from the earlier versions:
Supports /proc/bus/pci PCI detection available with the 2.2.* kernels.
Adjusts to the larger EEPROM size (e.g. the IBM branded board)
It also has an example of serial EEPROM write in the source code.
Donald Becker becker@cesdis.gsfc.nasa.gov
USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771
301-286-0882 http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html
From becker@cesdis1.gsfc.nasa.gov Mon Jun 28 21:59:22 1999
Date: Mon Jun 28 21:59:22 1999
From: Donald Becker becker@cesdis1.gsfc.nasa.gov
Subject: New test version of eepro100.c available
eepro100.c v1.09 of 6/28/99 is at
ftp://cesdis.gsfc.nasa.gov/pub/linux/drivers/test/eepro100.c
This version changes
Only use 802.3x Flow Control when it's negotiated (*)
Recognizes the larger EEPROM on the IBM board.
Better error reporting for Tx timeouts (**)
As usual, please send a report if any of these changes affect you.
* Flow control should never have been triggered when the interface was used a
repeater, unless full duplex was incorrectly forced. This patch makes
certain that it's not enabled unless it's negotiated.
** Send a report with the extra diagnostic output if you get a Tx timeout.
Donald Becker becker@cesdis.gsfc.nasa.gov
USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771
301-286-0882 http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html
From babydr@baby-dragons.com Mon Jun 28 23:52:50 1999
Date: Mon Jun 28 23:52:50 1999
From: Mr. James W. Laferriere babydr@baby-dragons.com
Subject: v1.00 of eepro100-diag.c released.
Hello Donald, It's nice that this supports linux-2.2 .
although what happended to 2.0 support . The below errors
occur on my 2.0.37 system . Tia, JimL
cc -O -Wall -o eepro100-diag eepro100-diag.c
In file included from /usr/include/gnu/types.h:78,
from /usr/include/unistd.h:96,
from eepro100-diag.c:24:
/usr/include/linux/posix_types.h:48: asm/posix_types.h: No such file or directory
In file included from /usr/include/sys/types.h:4,
from /usr/include/unistd.h:630,
from eepro100-diag.c:24:
/usr/include/linux/types.h:17: asm/types.h: No such file or directory
In file included from /usr/include/errno.h:27,
from /usr/include/stdlib.h:42,
from eepro100-diag.c:26:
/usr/include/linux/errno.h:4: asm/errno.h: No such file or directory
In file included from /usr/include/fcntl.h:29,
from eepro100-diag.c:27:
/usr/include/linux/fcntl.h:4: asm/fcntl.h: No such file or directory
In file included from eepro100-diag.c:30:
/usr/include/linux/in.h:120: asm/byteorder.h: No such file or directory
eepro100-diag.c:32: asm/io.h: No such file or directory
On Mon, 28 Jun 1999, Donald Becker wrote:
> Source code
> ftp://cesdis.gsfc.nasa.gov/pub/linux/diag/eepro100-diag.c
> Instructions
> http://cesdis.gsfc.nasa.gov/linux/diag/index.html
>
> This is the first "designated release" version of the EEPro100 diagnostic/setup
> program. It has the following changes from the earlier versions:
> Supports /proc/bus/pci PCI detection available with the 2.2.* kernels.
> Adjusts to the larger EEPROM size (e.g. the IBM branded board)
>
> It also has an example of serial EEPROM write in the source code.
>
> Donald Becker becker@cesdis.gsfc.nasa.gov
> USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
> Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771
> 301-286-0882 http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html
>
+-----------------------------------------------------------------+
| James W. Laferriere | System Techniques | Give me VMS |
| Network Engineer | 25416 22nd So | Give me Linux |
| babydr@baby-dragons.com | DesMoines WA 98198 | only on AXP |
+-----------------------------------------------------------------+
From becker@cesdis1.gsfc.nasa.gov Tue Jun 29 01:00:08 1999
Date: Tue Jun 29 01:00:08 1999
From: Donald Becker becker@cesdis1.gsfc.nasa.gov
Subject: v1.00 of eepro100-diag.c released.
On Mon, 28 Jun 1999, Mr. James W. Laferriere wrote:
> Hello Donald, It's nice that this supports linux-2.2 .
> although what happended to 2.0 support . The below errors
> occur on my 2.0.37 system . Tia, JimL
>
> cc -O -Wall -o eepro100-diag eepro100-diag.c
> In file included from /usr/include/gnu/types.h:78,
> from /usr/include/unistd.h:96,
> from eepro100-diag.c:24:
> /usr/include/linux/posix_types.h:48: asm/posix_types.h: No such file or directory
Hmmm, you must have something wrong with your include file structure.
It should always be safe to #include without having to include
anything else first.
Donald Becker becker@cesdis.gsfc.nasa.gov
USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771
301-286-0882 http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html
From zivago@ziff.net Tue Jun 29 01:10:03 1999
Date: Tue Jun 29 01:10:03 1999
From: Zivago 'Jaeman' Lee zivago@ziff.net
Subject: New test version of eepro100.c available
Donald,
I tried recompiling the kernel with the newer driver and I got this error
message:
--
eepro100.c: In function `speedo_tx_timeout':
eepro100.c:1009: `debug' undeclared (first use this function)
eepro100.c:1009: (Each undeclared identifier is reported only once
eepro100.c:1009: for each function it appears in.)
make[3]: *** [eepro100.o] Error 1
make[3]: Leaving directory `/usr/src/linux-2.2.9/drivers/net'
make[2]: *** [first_rule] Error 2
make[2]: Leaving directory `/usr/src/linux-2.2.9/drivers/net'
make[1]: *** [_subdir_net] Error 2
make[1]: Leaving directory `/usr/src/linux-2.2.9/drivers'
make: *** [_dir_drivers] Error 2
--
You know whats up? Thanks!
Z
On Mon, 28 Jun 1999, Donald Becker wrote:
> eepro100.c v1.09 of 6/28/99 is at
> ftp://cesdis.gsfc.nasa.gov/pub/linux/drivers/test/eepro100.c
>
> This version changes
> Only use 802.3x Flow Control when it's negotiated (*)
> Recognizes the larger EEPROM on the IBM board.
> Better error reporting for Tx timeouts (**)
>
> As usual, please send a report if any of these changes affect you.
>
> * Flow control should never have been triggered when the interface was used a
> repeater, unless full duplex was incorrectly forced. This patch makes
> certain that it's not enabled unless it's negotiated.
>
> ** Send a report with the extra diagnostic output if you get a Tx timeout.
>
> Donald Becker becker@cesdis.gsfc.nasa.gov
> USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
> Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771
> 301-286-0882 http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html
>
--
Zivago 'Jaeman' Lee
z@ziff.net
--
From becker@cesdis1.gsfc.nasa.gov Tue Jun 29 01:24:28 1999
Date: Tue Jun 29 01:24:28 1999
From: Donald Becker becker@cesdis1.gsfc.nasa.gov
Subject: New test version of eepro100.c available
On Mon, 28 Jun 1999, Zivago 'Jaeman' Lee wrote:
> I tried recompiling the kernel with the newer driver and I got this error
> message:
> eepro100.c: In function `speedo_tx_timeout':
> eepro100.c:1009: `debug' undeclared (first use this function)
Ooppsss, 'debug' is only valid when a module.
I should have used 'speedo_debug'
Fixed in v1.09a
> > eepro100.c v1.09 of 6/28/99 is at
> > ftp://cesdis.gsfc.nasa.gov/pub/linux/drivers/test/eepro100.c
Donald Becker becker@cesdis.gsfc.nasa.gov
USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771
301-286-0882 http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html
From zivago@ziff.net Tue Jun 29 11:04:58 1999
Date: Tue Jun 29 11:04:58 1999
From: Zivago 'Jaeman' Lee zivago@ziff.net
Subject: New test version of eepro100.c available
Donald,
I successfully compiled in the new driver but I still get these error
messages:
Jun 29 07:34:06 www19 kernel: eth0: Transmit timed out: status 0050 0080
at 8551737/8551751 command 000c0000.
Jun 29 07:34:06 www19 kernel: eth0: Trying to restart the transmitter...
Jun 29 07:34:11 www19 kernel: eth0: Transmit timed out: status 0050 0090
at 8551737/8551751 command 000c0000.
Anybody know what this means? Because after doing this, the server stops
pinging and has to be manually rebooted. Thanks...
This is on a Dual PII 400 and 2.2.9 kernel.
Z
On Tue, 29 Jun 1999, Donald Becker wrote:
> On Mon, 28 Jun 1999, Zivago 'Jaeman' Lee wrote:
> > I tried recompiling the kernel with the newer driver and I got this error
> > message:
> > eepro100.c: In function `speedo_tx_timeout':
> > eepro100.c:1009: `debug' undeclared (first use this function)
>
> Ooppsss, 'debug' is only valid when a module.
> I should have used 'speedo_debug'
>
> Fixed in v1.09a
>
> > > eepro100.c v1.09 of 6/28/99 is at
> > > ftp://cesdis.gsfc.nasa.gov/pub/linux/drivers/test/eepro100.c
>
> Donald Becker becker@cesdis.gsfc.nasa.gov
> USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
> Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771
> 301-286-0882 http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html
>
--
Zivago 'Jaeman' Lee
z@ziff.net
--
From babydr@baby-dragons.com Tue Jun 29 11:40:54 1999
Date: Tue Jun 29 11:40:54 1999
From: Mr. James W. Laferriere babydr@baby-dragons.com
Subject: v1.00 of eepro100-diag.c released.
Hello Donald, I'll look into it . But I haven't had -any-
problems before on this system compiling the other versions
or other packages ? Tnx, JimL
On Tue, 29 Jun 1999, Donald Becker wrote:
> On Mon, 28 Jun 1999, Mr. James W. Laferriere wrote:
> > Hello Donald, It's nice that this supports linux-2.2 .
> > although what happended to 2.0 support . The below errors
> > occur on my 2.0.37 system . Tia, JimL
> >
> > cc -O -Wall -o eepro100-diag eepro100-diag.c
> > In file included from /usr/include/gnu/types.h:78,
> > from /usr/include/unistd.h:96,
> > from eepro100-diag.c:24:
> > /usr/include/linux/posix_types.h:48: asm/posix_types.h: No such file or directory
>
> Hmmm, you must have something wrong with your include file structure.
> It should always be safe to #include without having to include
> anything else first.
+-----------------------------------------------------------------+
| James W. Laferriere | System Techniques | Give me VMS |
| Network Engineer | 25416 22nd So | Give me Linux |
| babydr@baby-dragons.com | DesMoines WA 98198 | only on AXP |
+-----------------------------------------------------------------+
From robin@takeover.wish.net Tue Jun 29 15:34:47 1999
Date: Tue Jun 29 15:34:47 1999
From: robin@takeover.wish.net robin@takeover.wish.net
Subject: New test version of eepro100.c available
--qMm9M+Fa2AknHoGS
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
The only problem with this is that if you use a Dual system (SMP) then you =
get
these messages. I've got the same problem here with our PII Dual 450. If I
compile it with a single proc. then it is alright.
Weird......
On Tue, Jun 29, 1999 at 08:04:55AM -0700, Zivago 'Jaeman' Lee wrote:
> Donald,
>=20
> I successfully compiled in the new driver but I still get these error
> messages:
>=20
> Jun 29 07:34:06 www19 kernel: eth0: Transmit timed out: status 0050 0080
> at 8551737/8551751 command 000c0000.=20
> Jun 29 07:34:06 www19 kernel: eth0: Trying to restart the transmitter...=
=20
> Jun 29 07:34:11 www19 kernel: eth0: Transmit timed out: status 0050 0090
> at 8551737/8551751 command 000c0000.=20
>=20
> Anybody know what this means? Because after doing this, the server stops
> pinging and has to be manually rebooted. Thanks...
>=20
> This is on a Dual PII 400 and 2.2.9 kernel.
>=20
> Z
>=20
>=20
> On Tue, 29 Jun 1999, Donald Becker wrote:
>=20
> > On Mon, 28 Jun 1999, Zivago 'Jaeman' Lee wrote:
> > > I tried recompiling the kernel with the newer driver and I got this e=
rror
> > > message:
> > > eepro100.c: In function `speedo_tx_timeout':
> > > eepro100.c:1009: `debug' undeclared (first use this function)
> >=20
> > Ooppsss, 'debug' is only valid when a module.
> > I should have used 'speedo_debug'
> >=20
> > Fixed in v1.09a
> >=20
> > > > eepro100.c v1.09 of 6/28/99 is at
> > > > ftp://cesdis.gsfc.nasa.gov/pub/linux/drivers/test/eepro100.c
> >=20
> > Donald Becker becker@cesdis.gsfc.nasa.gov
> > USRA-CESDIS, Center of Excellence in Space Data and Information Science=
s.
> > Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771
> > 301-286-0882 http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html
> >=20
>=20
> --
> Zivago 'Jaeman' Lee
> z@ziff.net
> --
--=20
--- - --- ------ - --- -- - - - -- - =20
R. Gruyters: System Manager/Web designer/B.O.F.H.
[ email : robin@wish.net ]
[ site : http://www.realm.wish.net ]
[ pgpkey : finger robin@realm.wish.net ]
"UNIX is user friendly. It's just selective about who its friends are."
--qMm9M+Fa2AknHoGS
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
iQCVAgUBN3kfu7QC55/euMmRAQEAOQP/QWnXez2VUTt8Ts2XdQf3zjMqEARqiol5
9cBC3JXuJtb1vkGPLAqClr18Ea0PHVxHrbyedGYfdcTKDM5lVvF4h6ifohnTkXfm
KT9XlcFM+jn7Vn4+P0dpWSbc/VS0LnroahZRsPAi7YPfMIKF1EGgU9oerf7gEhdk
h3tQyoSCe4k=
=F8xV
-----END PGP SIGNATURE-----
--qMm9M+Fa2AknHoGS--
From zivago@ziff.net Tue Jun 29 17:16:02 1999
Date: Tue Jun 29 17:16:02 1999
From: Zivago 'Jaeman' Lee zivago@ziff.net
Subject: New test version of eepro100.c available
That *is* very odd.. I also saw that some people who get these messages
have 2 of these NICs (I do too).
Donald: any thoughts?
Thanks!
Z
On Tue, 29 Jun 1999 robin@takeover.wish.net wrote:
> The only problem with this is that if you use a Dual system (SMP) then you get
> these messages. I've got the same problem here with our PII Dual 450. If I
> compile it with a single proc. then it is alright.
>
> Weird......
>
> On Tue, Jun 29, 1999 at 08:04:55AM -0700, Zivago 'Jaeman' Lee wrote:
> > Donald,
> >
> > I successfully compiled in the new driver but I still get these error
> > messages:
> >
> > Jun 29 07:34:06 www19 kernel: eth0: Transmit timed out: status 0050 0080
> > at 8551737/8551751 command 000c0000.
> > Jun 29 07:34:06 www19 kernel: eth0: Trying to restart the transmitter...
> > Jun 29 07:34:11 www19 kernel: eth0: Transmit timed out: status 0050 0090
> > at 8551737/8551751 command 000c0000.
> >
> > Anybody know what this means? Because after doing this, the server stops
> > pinging and has to be manually rebooted. Thanks...
> >
> > This is on a Dual PII 400 and 2.2.9 kernel.
> >
> > Z
> >
> >
> > On Tue, 29 Jun 1999, Donald Becker wrote:
> >
> > > On Mon, 28 Jun 1999, Zivago 'Jaeman' Lee wrote:
> > > > I tried recompiling the kernel with the newer driver and I got this error
> > > > message:
> > > > eepro100.c: In function `speedo_tx_timeout':
> > > > eepro100.c:1009: `debug' undeclared (first use this function)
> > >
> > > Ooppsss, 'debug' is only valid when a module.
> > > I should have used 'speedo_debug'
> > >
> > > Fixed in v1.09a
> > >
> > > > > eepro100.c v1.09 of 6/28/99 is at
> > > > > ftp://cesdis.gsfc.nasa.gov/pub/linux/drivers/test/eepro100.c
> > >
> > > Donald Becker becker@cesdis.gsfc.nasa.gov
> > > USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
> > > Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771
> > > 301-286-0882 http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html
> > >
> >
> > --
> > Zivago 'Jaeman' Lee
> > z@ziff.net
> > --
>
> --
> --- - --- ------ - --- -- - - - -- -
>
> R. Gruyters: System Manager/Web designer/B.O.F.H.
>
> [ email : robin@wish.net ]
> [ site : http://www.realm.wish.net ]
> [ pgpkey : finger robin@realm.wish.net ]
>
> "UNIX is user friendly. It's just selective about who its friends are."
>
--
Zivago 'Jaeman' Lee
z@ziff.net
--
From zivago@ziff.net Tue Jun 29 20:31:15 1999
Date: Tue Jun 29 20:31:15 1999
From: Zivago 'Jaeman' Lee zivago@ziff.net
Subject: New test version of eepro100.c available
Well, I tried disabling SMP and now it only stops pinging for about 10
seconds but it actually restarts the transmitter (unlike with SMP enabled,
you had to press ctrl-alt-del). But, this was kind of worse because it
would do this "restarting transmitter" about every 1 minute or so, whereas
with SMP enabled, it would do it about every 1.5 to 2 days...
Z
On Tue, 29 Jun 1999 robin@takeover.wish.net wrote:
> The only problem with this is that if you use a Dual system (SMP) then you get
> these messages. I've got the same problem here with our PII Dual 450. If I
> compile it with a single proc. then it is alright.
>
> Weird......
>
> On Tue, Jun 29, 1999 at 08:04:55AM -0700, Zivago 'Jaeman' Lee wrote:
> > Donald,
> >
> > I successfully compiled in the new driver but I still get these error
> > messages:
> >
> > Jun 29 07:34:06 www19 kernel: eth0: Transmit timed out: status 0050 0080
> > at 8551737/8551751 command 000c0000.
> > Jun 29 07:34:06 www19 kernel: eth0: Trying to restart the transmitter...
> > Jun 29 07:34:11 www19 kernel: eth0: Transmit timed out: status 0050 0090
> > at 8551737/8551751 command 000c0000.
> >
> > Anybody know what this means? Because after doing this, the server stops
> > pinging and has to be manually rebooted. Thanks...
> >
> > This is on a Dual PII 400 and 2.2.9 kernel.
> >
> > Z
> >
> >
> > On Tue, 29 Jun 1999, Donald Becker wrote:
> >
> > > On Mon, 28 Jun 1999, Zivago 'Jaeman' Lee wrote:
> > > > I tried recompiling the kernel with the newer driver and I got this error
> > > > message:
> > > > eepro100.c: In function `speedo_tx_timeout':
> > > > eepro100.c:1009: `debug' undeclared (first use this function)
> > >
> > > Ooppsss, 'debug' is only valid when a module.
> > > I should have used 'speedo_debug'
> > >
> > > Fixed in v1.09a
> > >
> > > > > eepro100.c v1.09 of 6/28/99 is at
> > > > > ftp://cesdis.gsfc.nasa.gov/pub/linux/drivers/test/eepro100.c
> > >
> > > Donald Becker becker@cesdis.gsfc.nasa.gov
> > > USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
> > > Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771
> > > 301-286-0882 http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html
> > >
> >
> > --
> > Zivago 'Jaeman' Lee
> > z@ziff.net
> > --
>
> --
> --- - --- ------ - --- -- - - - -- -
>
> R. Gruyters: System Manager/Web designer/B.O.F.H.
>
> [ email : robin@wish.net ]
> [ site : http://www.realm.wish.net ]
> [ pgpkey : finger robin@realm.wish.net ]
>
> "UNIX is user friendly. It's just selective about who its friends are."
>
--
Zivago 'Jaeman' Lee
z@ziff.net
--
From kellyo@us.ibm.com Wed Jun 30 11:50:58 1999
Date: Wed Jun 30 11:50:58 1999
From: kellyo@us.ibm.com kellyo@us.ibm.com
Subject: New version of eepro100-diag.c (ref: IBM 82559 board)
--0__=Sf7cZUUBW97RYKBaxvjxPRGMYfgh0M1591MOWYB9VZIld5utRmL8zipE
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Kelly O'Brien - AT&T Global Network Services
Spectrum 3446 Tampa, Florida
Office: 813-878-3817 (t/l 427)
Lotus Notes ID: kellyo@IBMUS
Internet: kellyo@us.ibm.com
VM: kellyo at ibmusm37
===========================================================================
"Don't let your knowledge be limited by what you already
know." - me
---------------------- Forwarded by Kelly O'Brien/Tampa/IBM on 06/28/99 05:12 PM
---------------------------
Dan DeVault
06/28/99 04:22 PM
To: becker@cesdis.gsfc.nasa.gov@internet
cc: Kelly O'Brien/Tampa/IBM@IBMUS
From: Dan DeVault/Tampa/IBM@IBMUS
Subject: Re: New version of eepro100-diag.c (ref: IBM 82559 board)
Donald,
I"ve been working with Kelly on this........... attached is
the output from using your latest diagnostic. It is now getting the mac address
correctly in the diagnostic. I looked at the code and while I could hack in a
change to the device driver itself I thought it best to defer to you........ as
I'm unsure from your comments if you are going to implement the do_eeprom_cmd
into the device driver as well......... and it makes no sense to have 10
different versions of your driver floating around. We really appreciate the
time you have spent on this and if we can repay the favor please let us know.
If you are pressed for time and want us to make changes to your driver for this
then we can do so and will forward the source back to you.
( Of course you realize that we being the phone company we will be required to
then charge 10 cents a minute for all data flowing through the driver.......
:-) just kidding...... )
Best regards,
Dan DeVault
(See attached file: Diag.txt)
---------------------- Forwarded by Dan DeVault/Tampa/IBM on 06/28/99 04:14 PM
---------------------------
Kelly O'Brien
06/28/99 02:14 PM
To: Dan DeVault/Tampa/IBM@IBMUS
cc:
From: Kelly O'Brien/Tampa/IBM@IBMUS
Subject: Re: New version of eepro100-diag.c (ref: IBM 82559 board)
Kelly O'Brien - AT&T Global Network Services
Spectrum 3446 Tampa, Florida
Office: 813-878-3817 (t/l 427)
Lotus Notes ID: kellyo@IBMUS
Internet: kellyo@us.ibm.com
VM: kellyo at ibmusm37
===========================================================================
"Don't let your knowledge be limited by what you already
know." - me
---------------------- Forwarded by Kelly O'Brien/Tampa/IBM on 06/28/99 02:14 PM
---------------------------
Donald Becker on 06/28/99 01:46:30 PM
To: Kelly O'Brien/Tampa/IBM@IBMUS
cc: linux-eepro100@cesdis.gsfc.nasa.gov
Subject: Re: New version of eepro100-diag.c (ref: IBM 82559 board)
On Mon, 28 Jun 1999 kellyo@us.ibm.com wrote:
> Over the weekend, we looked at the updated diag code and saw what we thought
> might have been the reason that we were getting all x'ffff's. It appeared
that
> it was using an address of "pciaddr0" instead of "pciaddr1". We changed it
and
Doh! That was in the new code to support /proc/bus/pci for 2.2.* rather
than /proc/pci from the older kernels.
Fixed.
> eepro100-diag.c:v0.08 6/25/99 Donald Becker (becker@cesdis.gsfc.nasa.gov)
> Index #1: Found a Intel 82557 EtherExpressPro100B adapter at 0x7c40.
> EEPROM address size probe returns 0xffe0400.
Exactly what I needed to know.
Please try v0.09 of 6/28/99
ftp://cesdis.gsfc.nasa.gov/pub/linux/diag/eepro100-diag.c
I expect this to become v1.00, perhaps after removing read_eeprom() in favor
of using do_eeprom_cmd() for both reading and writing.
Donald Becker becker@cesdis.gsfc.nasa.gov
USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771
301-286-0882 http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html
--0__=Sf7cZUUBW97RYKBaxvjxPRGMYfgh0M1591MOWYB9VZIld5utRmL8zipE
Content-type: application/octet-stream;
name="Diag.txt"
Content-Disposition: attachment; filename="Diag.txt"
Content-transfer-encoding: base64
Content-Description: Text - character set unknown
ZWVwcm8xMDAtZGlhZy5jOnYwLjA5IDYvMjgvOTkgRG9uYWxkIEJlY2tlciAoYmVja2VyQGNlc2Rp
cy5nc2ZjLm5hc2EuZ292KQpJbmRleCAjMTogRm91bmQgYSBJbnRlbCA4MjU1NyBFdGhlckV4cHJl
c3NQcm8xMDBCIGFkYXB0ZXIgYXQgMHg3YzQwLgpFRVBST00gYWRkcmVzcyBzaXplIHByb2JlIHJl
dHVybnMgMHhmZmUwNDAwLgpFRVBST00gY29udGVudHM6CiAgMDQwMCA1M2FjIDc1NmYgMDMxMyAw
MDAwIDAyMDEgNDcwMSAwMDAwCiAgNzI5OCA1NzA1IDQwYTIgMzA1YyAxMDE0IDAwMDAgMDAwMCAw
MDAwCiAgMDAwMCAwMDAwIDAwMDAgMDAwMCAwMDAwIDAwMDAgMDAwMCAwMDAwCiAgMDAwMCAwMDAw
IDAwMDAgMDAwMCAwMDAwIDAwMDAgMDAwMCAwMDAwCiAgMDAwMCAwMDAwIDAwMDAgMDAwMCAwMDAw
IDAwMDAgMDAwMCAwMDAwCiAgMDAwMCAwMDAwIDAwMDAgMDAwMCAwMDAwIDAwMDAgMDAwMCAwMDAw
CiAgMDIyOCAwMDAwIDAwMDAgMDAwMCAwMDAwIDAwMDAgMDAwMCAwMDAwCiAgMDAwMCAwMDAwIDAw
MDAgMDAwMCAwMDAwIDAwMDAgMDAwMCAwMDAwCiBUaGUgRUVQUk9NIGNoZWNrc3VtIChzaG91bGQg
YmUgMHhiYWJhKSBpcyAweDY2MDcuCkludGVsIEV0aGVyRXhwcmVzcyBQcm8gMTAvMTAwIEVFUFJP
TSBjb250ZW50czoKICBTdGF0aW9uIGFkZHJlc3MgMDA6MDQ6QUM6NTM6NkY6NzUuCiAgQm9hcmQg
YXNzZW1ibHkgNzI5ODU3LTAwNSwgUGh5c2ljYWwgY29ubmVjdG9ycyBwcmVzZW50OiBSSjQ1CiAg
UHJpbWFyeSBpbnRlcmZhY2UgY2hpcCBpODI1NTUgUEhZICMxLgo=
--0__=Sf7cZUUBW97RYKBaxvjxPRGMYfgh0M1591MOWYB9VZIld5utRmL8zipE--