Bug 55601 - onboard AMD (pcnet32) RH 7.2 fails
onboard AMD (pcnet32) RH 7.2 fails
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-11-02 14:12 EST by Wendy Hung
Modified: 2007-04-18 12:37 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-02-25 06:23:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dmesg from an x350 with the AMD Onboard (14.92 KB, text/plain)
2001-11-06 18:05 EST, Leah R. M. Cunningham
no flags Details
dmesg from the IBM xSeries 350 8682-xxx (12.49 KB, text/plain)
2001-11-06 18:57 EST, Leah R. M. Cunningham
no flags Details
Ifconfig output from the IBM xSeries 350 8682-xxx (811 bytes, text/plain)
2001-11-06 18:58 EST, Leah R. M. Cunningham
no flags Details
'lspci -v' from the IBM xSeries 350 8682-xxx (2.70 KB, text/plain)
2001-11-06 18:59 EST, Leah R. M. Cunningham
no flags Details

  None (edit)
Description Wendy Hung 2001-11-02 14:12:37 EST
Description of Problem:
Systems w/onboard AMD Am79c975 ethernet (IBM xSeries 230, 240, 350, 250)
fail network stress tests. 

Failures with both RH7.2 (2.4.7-10) and kernel errata (2.4.9-7).

How Reproducible:
xSeries 240 passed testing on some instances. 

Error from server side from file log.smbd:
----------------------
[2001/10/31 07:49:36, 0] lib/util_sock.c:write_socket_data(541)
  write_socket_data: write failure. Error = Connection reset by peer
[2001/10/31 07:49:36, 0] lib/util_sock.c:write_socket(565)
  write_socket: Error writing 61440 bytes to socket 15: ERRNO = Connection 
reset by peer
[2001/10/31 07:49:36, 0] lib/util_sock.c:send_smb(729)
  Error writing 61440 bytes to client. -1. (Connection reset by peer)
[2001/10/31 07:49:37, 0] passdb/pampass.c:smb_pam_passcheck(830)
  smb_pam_passcheck: PAM: smb_pam_auth failed - Rejecting User 
administrator !
[2001/10/31 08:02:37, 0] passdb/pampass.c:smb_pam_passcheck(830)
  smb_pam_passcheck: PAM: smb_pam_auth failed - Rejecting User 
administrator !
[2001/10/31 08:03:09, 0] smbd/oplock.c:request_oplock_break(997)
  request_oplock_break: no response received to oplock break request to 
pid 6157 on port 32789 for dev = 803, inode = 1547645
  for dev = 803, inode = 1547645, tv_sec = 3bdff63a, tv_usec = 9e7a6
[2001/10/31 08:03:41, 0] smbd/oplock.c:request_oplock_break(997)
  request_oplock_break: no response received to oplock break request to 
pid 6157 on port 32789 for dev = 803, inode = 1547645
  for dev = 803, inode = 1547645, tv_sec = 3bdff63a, tv_usec = 9e7a6


NOTEs:
 PAM authentication is not a problem since share is readable&writable by   
 everyone.
 There are excessive "Connection reset by peer" errors.
 Not sure about oplock_break error.
Comment 1 Leah R. M. Cunningham 2001-11-06 18:05:47 EST
Created attachment 36701 [details]
dmesg from an x350 with the AMD Onboard
Comment 2 Leah R. M. Cunningham 2001-11-06 18:09:31 EST
Ignore the last attachment, I gave you the wrong dmesg output.
Comment 3 Leah R. M. Cunningham 2001-11-06 18:57:16 EST
Created attachment 36702 [details]
dmesg from the IBM xSeries 350 8682-xxx
Comment 4 Leah R. M. Cunningham 2001-11-06 18:58:18 EST
Created attachment 36703 [details]
Ifconfig output from the IBM xSeries 350 8682-xxx
Comment 5 Leah R. M. Cunningham 2001-11-06 18:59:06 EST
Created attachment 36704 [details]
'lspci -v' from the IBM xSeries 350 8682-xxx
Comment 6 Arjan van de Ven 2001-11-07 04:27:49 EST
Does the kernel give any useful input ?
Also since the machine has 2 ethernet cards, is it 100% sure it's the pcnet32
one that is being used ? (and is the routing table correct)
Comment 7 Wendy Hung 2001-11-08 13:44:43 EST
xSeries 250 has only the onboard AMD configured.
pcnet32 was loaded using 'insmod' w/full-duplex set.  
How can I verify that the onboard AMD is running at full-duplex?
Can the full-duplex setting be overridden by something and the AMD only runs at 
half-duplex?
Comment 8 Arjan van de Ven 2001-11-08 13:51:03 EST
forcing duplex is generally a bad idea; the driver/card will negotiate the best
setting based on the capability of the router/link; the overrides are present
because some VERY old cisco switches got this wrong ;(
Comment 9 Wendy Hung 2001-11-16 13:43:08 EST
Affected systems:
 x230
 x240
 x250
 x350

Chip:
 AMD79C975/on planar/10BaseT/100BaseTX/FullDuplex

Switch:
 IBM 10BaseT/100BaseTX switch
 FRU: 02L1321
 Type: 8271-712
 NOTE: switch was forced into 100M Full-duplex mode during testing because auto-
negotiate failed.

Driver:
 pcnet32 1.26p

The driver detected the chip correctly from the message log ("PCnet/FAST III 
79C975 @ 0x2000 ...").  However, "options" value for the chip is not correct.  
The value of 4 (PORT_ASEL) is set to lp->options in pcnet32_open function.  As 
a result, the card may or may not be loaded in full duplex mode, even 
when 'full_duplex' param is set to 1.

To correct this problem, "options" param could be specified as follow

insmod pcnet32 full_duplex=1,1,1,1,1,1,1,1 options=14,14,14,14,14,14,14,14

Note: option 14  = PORT_MII | PORT_100 | PORT_FD

Result from testing:
0 error after 24 hours on Redhat 7.2 on x240
Comment 10 Wendy Hung 2001-12-10 14:11:24 EST
The switch used is not a Cisco switch.  
It is an IBM 10BaseT/100BaseTX switch  FRU: 02L1321  Type: 8271-712

Running network tests again without any options parameters.  No failures after 
60 hours.  The tests will continue to run for another 20 hours.
Comment 11 Wendy Hung 2002-02-14 10:28:35 EST
Network tests without any options parameters still fails.  
Options param still needs to be used.
Comment 12 Arjan van de Ven 2002-02-25 06:23:14 EST
Driver is updated in 2.4.18; fixed in rawhide therefore

Note You need to log in before you can comment on or make changes to this bug.