Bug 51558 - 3c59x: complete failure with wake-on-lan (wol) enabled
Summary: 3c59x: complete failure with wake-on-lan (wol) enabled
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 7.3
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-08-12 11:45 UTC by giulioo
Modified: 2007-04-18 16:35 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2001-08-17 13:21:47 UTC
Embargoed:


Attachments (Terms of Use)

Description giulioo 2001-08-12 11:45:36 UTC
Description of problem:
loading 3c59x with enable_wol=1 cause 3c59x to fail to load properly.

How reproducible:
Always

Steps to Reproduce:
1. load 3c59x with enable_wol=1


Actual Results:  nic does not work (no ping), errors in log

Expected Results:  nic/network should work, and after poweroff wol should 
work

Additional info:

The system is i440ZX + 3c905CX-TXM  (note the CX), lspci at the end.
bios is "pnp os: no"

Using kernel 2.2.16-22 + 3c59x.c from 2.2.19 errata (which adds enable_wol 
module parm) with enable_wol=1, wol works perfectly: after linux poweroff, 
I can wake up the machine.
2.2.16 /proc/interrupts shows irq7 shared between eth0 and usb, network 
works, I don't use any usb device.

In roswell all works well until I use enable_wol=1. I tried putting nousb 
on command line so that irq7 is only for eth0 (verified 
in /proc/interrupts) but eth0 fails to work (no ping) with enable_wol=1. 
Don't want to swap pci slot since it works with previous kernel.

Using nousb (no usb module loaded) in roswell I get:
  7:         60          XT-PIC  eth0

roswell without enable_wol
PCI: Found IRQ 7 for device 00:09.0
PCI: Sharing IRQ 7 with 00:04.2     <=== why sharing if usb disabled???
3c59x.c:LK1.1.15 6 June 2001  Donald Becker and others. 
http://www.scyld.com/net
work/vortex.html
See Documentation/networking/vortex.txt
00:09.0: 3Com PCI 3c905C Tornado at 0xd000,  00:01:03:d6:01:18, IRQ 7
  product code 484e rev 00.3 date 02-15-01
  8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface.
  MII transceiver found at address 24, status 782d.
  Enabling bus-master transmits and whole-frame receives.
00:09.0: scatter/gather disabled. h/w checksums enabled
eth0: using NWAY device table, not 8

with enable_wol=1
PCI: Found IRQ 7 for device 00:09.0
PCI: Sharing IRQ 7 with 00:04.2
3c59x.c:LK1.1.15 6 June 2001  Donald Becker and others. 
http://www.scyld.com/net
work/vortex.html
See Documentation/networking/vortex.txt
00:09.0: 3Com PCI 3c905C Tornado at 0xd000,  00:01:03:d6:01:18, IRQ 7
  product code 484e rev 00.3 date 02-15-01
  8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface.
  MII transceiver found at address 24, status 782d.
  Enabling bus-master transmits and whole-frame receives.
00:09.0: scatter/gather disabled. h/w checksums enabled
eth0: using NWAY device table, not 8
eth0: command 0x5800 did not complete! Status=0xffff
eth0: command 0x2800 did not complete! Status=0xffff
eth0: command 0x3002 did not complete! Status=0xffff
eth0: command 0x3002 did not complete! Status=0xffff
eth0: command 0x3002 did not complete! Status=0xffff
eth0: command 0x3002 did not complete! Status=0xffff

network does not work, and poweroff switch off the light on the hub so wol 
does not work either.

I can boot without enable_wol and then unload 3c59x, reload it with 
enable_wol and problem shows up, this time dmesg is more messed up, 
typical eth0 hard addr not recognized.
PCI: Enabling device 00:09.0 (0000 -> 0003)
PCI: Found IRQ 7 for device 00:09.0
PCI: Sharing IRQ 7 with 00:04.2
3c59x.c:LK1.1.15 6 June 2001  Donald Becker and others. 
http://www.scyld.com/net
work/vortex.html
See Documentation/networking/vortex.txt
00:09.0: 3Com PCI 3c905C Tornado at 0xd000, PCI: Setting latency timer of 
device
 00:09.0 to 64
 ff:ff:ff:ff:ff:ff, IRQ 7
  product code ffff rev ffff.15 date 15-31-127
Full duplex capable
  1024K word-wide RAM 3:5 Rx:Tx split, autoselect/<invalid transceiver> 
interfac
e.
  Enabling bus-master transmits and early receives.
00:09.0: scatter/gather disabled. h/w checksums enabled
eth0: using NWAY device table, not 15
eth0: command 0x5800 did not complete! Status=0xffff
eth0: command 0x2800 did not complete! Status=0xffff
eth0: command 0x3002 did not complete! Status=0xffff
eth0: command 0x3002 did not complete! Status=0xffff
eth0: command 0x3002 did not complete! Status=0xffff
eth0: command 0x3002 did not complete! Status=0xffff


lspci
00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge 
(rev 03
)
00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge 
(rev 03)
00:04.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02)
00:04.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01)
00:04.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01)
00:04.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02)
00:09.0 Ethernet controller: 3Com Corporation 3c905C-TX [Fast Etherlink] 
(rev 78
)
01:00.0 VGA compatible controller: Trident Microsystems Blade 3D PCI/AGP 
(rev 3a
)

lspci -n
00:00.0 Class 0600: 8086:7190 (rev 03)
00:01.0 Class 0604: 8086:7191 (rev 03)
00:04.0 Class 0601: 8086:7110 (rev 02)
00:04.1 Class 0101: 8086:7111 (rev 01)
00:04.2 Class 0c03: 8086:7112 (rev 01)
00:04.3 Class 0680: 8086:7113 (rev 02)
00:09.0 Class 0200: 10b7:9200 (rev 78)
01:00.0 Class 0300: 1023:9880 (rev 3a)

Comment 1 Arjan van de Ven 2001-08-12 12:10:43 UTC
Thank you for the detailed report. The fact that the 2.2.19 driver does work
is a good datapoint and I'll check the differences between the roswell driver
and the 2.2.19 driver to see if there is anything suspicious.

Comment 2 Glen Foster 2001-08-13 19:10:48 UTC
This defect is considered SHOULD-FIX for Fairfax.

Comment 3 giulioo 2001-08-17 13:16:19 UTC
This patch
http://groups.google.com/groups?hl=it&safe=off&th=a96feda1d27ab2af,2
makes enable_wol work again (normal network works, pc is powered on remotely 
via wol).

Had to apply the pci.c part by hand since pci.c is a bit changed, so I don't 
know if the logic of the patch is still right. There's even that reply 
suggesting the patch should be changed.



Comment 4 Arjan van de Ven 2001-08-17 13:21:43 UTC
Thanks!
I've looked at his (the 2.2.19<->2.4.X patch is just WAAY too big to be useful)
and it appears our 2.4.7-2 kernel already has it. Could you try that (it's in
rawhide) ?

Comment 5 giulioo 2001-08-17 13:49:38 UTC
2.4.7-2 works ok.


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