Bug 175994

Summary: kernel removes marvel 88E8036 support
Product: [Fedora] Fedora Reporter: Davide Rossetti <davide.rossetti>
Component: kernelAssignee: John W. Linville <linville>
Status: CLOSED CANTFIX QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 4CC: davej, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-03-09 19:47:29 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Davide Rossetti 2005-12-17 00:41:31 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7

Description of problem:
it's a brand new Toshiba M40

it seems like this update kernel removes marvel 88E8036 (device 02:00.0) support from sk98lin driver:

00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller (rev 03)
00:01.0 PCI bridge: Intel Corporation Mobile 915GM/PM Express PCI Express Root Port (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 04)
00:1c.1 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 2 (rev 04)
00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 04)
00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 04)
00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 04)
00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 (rev 04)
00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 04)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev d4)
00:1e.2 Multimedia audio controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller (rev 04)
00:1e.3 Modem: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Modem Controller (rev 04)
00:1f.0 ISA bridge: Intel Corporation 82801FBM (ICH6M) LPC Interface Bridge (rev 04)
00:1f.2 IDE interface: Intel Corporation 82801FBM (ICH6M) SATA Controller (rev 04)
01:00.0 VGA compatible controller: ATI Technologies Inc M22 [Radeon Mobility M300]
02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8036 Fast Ethernet Controller (rev 10)
06:04.0 Network controller: Intel Corporation PRO/Wireless 2200BG (rev 05)
06:06.0 CardBus bridge: Texas Instruments PCIxx21/x515 Cardbus Controller
06:06.2 FireWire (IEEE 1394): Texas Instruments OHCI Compliant IEEE 1394 Host Controller
06:06.3 Mass storage controller: Texas Instruments PCIxx21 Integrated FlashMedia Controller
06:06.4 Class 0805: Texas Instruments PCI6411, PCI6421, PCI6611, PCI6621, PCI7411, PCI7421, PCI7611, PCI7621 Secure Digital (SD) Controller



Version-Release number of selected component (if applicable):
2.6.14-1.1653_FC4

How reproducible:
Always

Steps to Reproduce:
1.upgrade to 2.6.14-1.1653_FC4
2.reboot
3.no wired net
  

Additional info:

Comment 1 Dave Jones 2005-12-17 07:03:03 UTC
you're probably better off running the skge driver anyway, but its curious that
sk98lin stopped working. What was the last version that worked ?

The next update is a big rebase to 2.6.15, which is at
http://people.redhat.com/davej/kernels/Fedora/FC4 , which may fix it again.


Comment 2 Davide Rossetti 2005-12-19 15:48:43 UTC
(In reply to comment #1)
> you're probably better off running the skge driver anyway, but its curious that
> sk98lin stopped working. What was the last version that worked ?

my card is:
02:00.0 Class 0200: 11ab:4351 (rev 10)
        Subsystem: 1179:ff10
        Flags: bus master, fast devsel, latency 0, IRQ 11
        Memory at bc000000 (64-bit, non-prefetchable) [size=16K]
        I/O ports at a000 [size=256]
        Capabilities: <available only to root>

e.g. on /lib/modules/2.6.11-1.1369_FC4/modules.pcimap:

sk98lin              0x000011ab 0x00004320 0xffffffff 0xffffffff 0x00000000
0x00000000 0x0
....
sk98lin              0x000011ab 0x00004351 0xffffffff 0xffffffff 0x00000000
0x00000000 0x0
....
sk98lin              0x00001737 0x00001064 0xffffffff 0xffffffff 0x00000000
0x00000000 0x0

the sk98lin on 2.6.14-1.1644_FC4 is good as well.

then in 2.6.14-1.1653_FC4 someone removed the ids for Yukon2 chips from sk98lin,
I guess in preparation for debut of sky2 from -mm 

beware that sky2.c on -mm3 is working well for me, and that skge.c is not
intended for Yukon2 chips, only for Yukon1.

instead, sk98lin drives all chips.

> The next update is a big rebase to 2.6.15, which is at
> http://people.redhat.com/davej/kernels/Fedora/FC4 , which may fix it again.
> 

did't have a look at it yet, anyway I think that either you ship sky2.c from mm,
or you have to re-add Yukon2 PCI IDs to sk98lin, as skge is only for Yukon1 chip.

Comment 3 Dave Jones 2005-12-20 04:31:51 UTC
there aren't any sk98lin patches added between 1644_FC4 and 1653_FC5. Puzzling.

hmm, does booting with acpi=off make it come back to life?


Comment 4 Davide Rossetti 2005-12-20 21:26:08 UTC
sorry I made a mistake.
1644_FC4 is NOT working as well as 2.6.14-1.1653_FC4.

The removal of device 11ab:4351 happened before 1644_FC4.

My error has this history.
for 1644_FC4 I compiled the Marvel original driver (because sk98lin was NOT
handling my device), copied to /lib/modules/$(uname -r)/kernel/driver/net/, did
depmod -a.
But it was not functioning, and I guesses it was it's fault. then I discovered
that there was some interaction on irq11 between Texas UHCI1394 device (it's
bugzilla 175996). Then I mailed on fedora-list, and shemminger replayed
I could use sky2.c driver from rc3-mm1. But the net card started running only
when I removed the UHCI1394 driver from 1644_FC4 dir, with the side effect that
also sk98lin (the one downloaded from the Marvel site) was running as well as
sky2. So I forgot I have overwritten the sk98lin.ko driver and so I reported
that 1644_FC4 sk98lin is ok... but it's not. 

In fact, once I reinstalled the kernel rpm, I get:

$ fgrep 11ab /lib/modules/2.6.14-1.1644_FC4/mod*pci*
sk98lin    0x000011ab 0x00004320 0xffffffff 0xffffffff 0x00000000 0x00000000 0x0
sk98lin    0x000011ab 0x00005005 0xffffffff 0xffffffff 0x00000000 0x00000000 0x0
skge       0x000011ab 0x00004320 0xffffffff 0xffffffff 0x00000000 0x00000000 0x0
skge       0x000011ab 0x00005005 0xffffffff 0xffffffff 0x00000000 0x00000000 0x0

but my Yukon2 card has device id 4351

$ /sbin/lspci -n -s 2:0.0
02:00.0 Class 0200: 11ab:4351 (rev 10)



Comment 5 John W. Linville 2006-01-03 16:06:47 UTC
You may want to try the fedora-netdev kernels:  
  
   http://people.redhat.com/linville/kernels/fedora-netdev/ 
 
In particular, these include the sky2 driver.  Please give those a try and 
post the results...thanks!  

Comment 6 Davide Rossetti 2006-01-12 19:14:15 UTC
sky2 drivers from:
- 2.6.14-1.1656_FC4.netdev.7 (.8 downloaded but not tested yet)
- 2.6.15-rc5-mm3
have the same bug. as soon as I generate heavy I/O it starts slowing down to 1
or 0 pkt per sec.

ifdown, then ifup again to get back network access.

I'm using: rsync -v --progress /nfs_mounted_dir/FC4-i386-disc1.iso /local_dir
so it is nfs read traffic. it stops around 17MB transferred.
it stops after ~ 400KB going in the opposite direction.

network switch is a 3COM 10/100 SuperStack.
interface is configured via dhcp.



Comment 7 Dave Jones 2006-02-03 06:38:25 UTC
This is a mass-update to all currently open kernel bugs.

A new kernel update has been released (Version: 2.6.15-1.1830_FC4)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO_REPORTER state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

Thank you.


Comment 8 John W. Linville 2006-03-09 19:47:29 UTC
Closed due to lack of response...please reopen when the bug is verified  
against current kernels...thanks!