sky2 driver stalls

Bug #68338 reported by mestre.adamastor on 2006-10-26
44
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux-source-2.6.17 (Baltix)
Undecided
Unassigned
linux-source-2.6.17 (Ubuntu)
High
Unassigned
linux-source-2.6.20 (Ubuntu)
Undecided
Unassigned

Bug Description

Binary package hint: linux-image-2.6.17-10-generic

Hi,

In my sony vaio sz2hp, booting with 2.6.17-10 loads the sky2 driver, which stops transmitting after a relatively short time, even with a small load. My mileage varies...

However, if I boot with 2.6.17-7, the sk98lin driver is loaded instead and the network card works fine (or so I perceive).

Here goes the relevant section of lspci -vv, taken with 2.6.17-7 (with which I can actually access the network):

07:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8036 PCI-E Fast Ethernet Controller (rev 15)
        Subsystem: Sony Corporation Unknown device 81e6
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR+ <PERR-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 185
        Region 0: Memory at d8000000 (64-bit, non-prefetchable) [size=16K]
        Region 2: I/O ports at 3000 [size=256]
        Capabilities: [48] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=1 PME-
        Capabilities: [50] Vital Product Data
        Capabilities: [5c] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable-
                Address: 0000000000000000 Data: 0000
        Capabilities: [e0] Express Legacy Endpoint IRQ 0
                Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag-
                Device: Latency L0s unlimited, L1 unlimited
                Device: AtnBtn- AtnInd- PwrInd-
                Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
                Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
                Device: MaxPayload 128 bytes, MaxReadReq 2048 bytes
                Link: Supported Speed 2.5Gb/s, Width x1, ASPM unknown, Port 0
                Link: Latency L0s <256ns, L1 unlimited
                Link: ASPM Disabled RCB 128 bytes CommClk+ ExtSynch-
                Link: Speed 2.5Gb/s, Width x1
        Capabilities: [100] Advanced Error Reporting

This is also an issue with the 88E8053 chipset used in the Intel Macs:

01:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit Ethernet Controller (rev 22)

The sky2 driver dies periodically, requiring an `ifdown eth0; ifup eth0` to resume the network.

According to various sources, such as:

http://www.gnegg.ch/categories/11-Unix

this has been fixed in later versions of the kernel. Is this perhaps fixed in a later version of the 2.6.17 kernel, and if so can Edgy get a kernel update?? I also had this issue with Dapper on an Intel Mac Mini.

The sky2 driver in 2.6.18.2 corrects the issues with the fast ethernet sky2 variant found in quite a few laptops.

See '88E803X transmit lockup': http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.18.2

The sky2 v1.9 driver should be backported - I have two sky2 platforms, and v1.9 resolves all the stall, crash, etc issues I was finding before.

Can the importance of this bug be increased to high please? I can't find how to change this.

I experience network failure soon after using my sky2 interface on my Sony VGN-SZ240 without the mentioned patch. With the sky2 driver < v1.9, I get transmit failure some gigabytes of data transfer. With v1.9, no problem.

Chris Yoder (cyoder) wrote :

I have a gateway laptop that this happens to.

I can force it to happen if I try to move a lot of data at once.

Strangely enough, it also takes out the switch that the laptop is plugged into.

Changed in linux-source-2.6.17:
importance: Undecided → High
status: Unconfirmed → Confirmed
Kyle McMartin (kyle) wrote :

Backported v1.9 + 470ea7eba4aaa517533f9b02ac9a104e77264548 "sky2: 88E803X transmit lockup" to ubuntu-edgy-updates.git

Changed in linux-source-2.6.17:
status: Confirmed → Fix Committed
Sitsofe Wheeler (sitsofe) wrote :

If you want to compile the update by hand (when I checked there wasn't a new proposed kernel dpkg later than linux-image-2.6.17-10-generic 2.6.17.1-10.34
 out yet) you can find an HTTP accessible version of the updates tree carrying the above patch here:
http://kernel.org/git/?p=linux/kernel/git/kyle/ubuntu-edgy-updates.git;a=tree

From there it is a simple case of downloading sky2.c, sky2_compat.h, sky2.h, creating a module Makefile and compiling against the current kernel headers to build your own version of this update. All the hard work of backporting the patch and dealing with interface changes has already been done by some other kind soul.

zpro (cms01) wrote :

This bug, has been around since dapper.... that bad.,
please lets fix it for good before feisty fawn comes out.

and get the wifi fix as well broadcom 4318 would be nice.

Chris Yoder (cyoder) wrote :

This fix should be available in binary format for 6.10. Not everyone using 6.10 is capable of the download and compile fix mentioned above.

This network chipset seems to becoming far more common than it used to, which makes getting the binary in edgy the "right thing to do" ;)

Forest Bond (forest-bond) wrote :

I compiled the driver from the git tree mentioned above against the standard kernel packages. My machine froze twice with no log messages, each time after running for about 8 hours. There is likely an error or two in the porting of the driver.

-Forest

Albert Vilella (avilella) wrote :

has this backported to edgy kernel already? Does anyone has an example patch set and Makefile to compile this?

Albert Vilella (avilella) wrote :

I respond to myself (think so):

Version 2.6.17.1-50.50:

  * sky2: Backport v1.9
    - Fixes #68338
  * sky2: 88E803X transmit lockup
    - Fixes #68338

Kyle McMartin (kyle) wrote :

The version in edgy-proposed contains these fixes. (Sometimes it takes a little while for a package to go from uploaded to -proposed.) Please test and let me know if it improves things for you by replying to this bug.

On Fri, Jan 26, 2007 at 10:55:48AM -0000, Kyle McMartin wrote:
> The version in edgy-proposed contains these fixes. (Sometimes it takes a
> little while for a package to go from uploaded to -proposed.) Please
> test and let me know if it improves things for you by replying to this
> bug.

Currently installing; it can sometimes take up to a week or more for lock ups to
occur. I will try to force it with heavy traffic, and will report back.

-Forest

Forest: I reported (duplicate) Bug #81713 with this issue; the bug can be forced within 24-48 hours by running KTorrent: just fire up KTorrent and load some popular torrents like the Ubuntu CD+DVD images...

Is there a way to get stuff from edgy-proposed (the update manager currently only takes stuff from the 'official' repositories?

No need to touch that sources.list file.
'linux-image-2.6.17-50-386_2.6.17.1-50.50_i386.deb' or as appropriate
can be downloaded directly from:

http://gb.archive.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.17/

Then, just use 'dpkg -i <file>' and enjoy!

On 29/01/07, Anders <email address hidden> wrote:
> Forest: I reported (duplicate) Bug #81713 with this issue; the bug can
> be forced within 24-48 hours by running KTorrent: just fire up KTorrent
> and load some popular torrents like the Ubuntu CD+DVD images...
>
> Is there a way to get stuff from edgy-proposed (the update manager
> currently only takes stuff from the 'official' repositories?
--
Daniel J Blueman

Forest Bond (forest-bond) wrote :

Well, I've been pushing a little torrent and some multicast audio through, and everything seems to be dandy:

[~]
17:00 fab@storm$ uname -r
2.6.17-50-generic
[~]
17:00 fab@storm$ uptime
 17:00:54 up 5 days, 9:16, 9 users, load average: 0.96, 2.44, 3.47

I've upgraded to Ubuntu 7.04 (Feisty) and things seem to be working fine as well...

It appears I spoke too quickly - the bug (or a very similar one) reoccurred on Feisty just now. Computer was hung when I got back, but from the syslog file it appears it kept writing -- MARK -- entries while 'dead':

Feb 10 19:58:25 plasken -- MARK --
Feb 10 20:07:15 plasken kernel: [25996.296585] NETDEV WATCHDOG: eth0: transmit timed out
Feb 10 20:07:15 plasken kernel: [25996.296599] sky2 status report lost?
Feb 10 20:07:24 plasken kernel: [26005.771487] [softlockup_tick+156/240] softlockup_tick+0x9c/0xf0
Feb 10 20:07:24 plasken kernel: [26005.771503] [update_process_times+51/128] update_process_times+0x33/0x80
Feb 10 20:07:24 plasken kernel: [26005.771512] [smp_apic_timer_interrupt+112/128] smp_apic_timer_interrupt+0x70/0x80
Feb 10 20:07:24 plasken kernel: [26005.771519] [apic_timer_interrupt+40/48] apic_timer_interrupt+0x28/0x30
Feb 10 20:07:24 plasken kernel: [26005.771532] [_spin_lock_bh+15/32] _spin_lock_bh+0xf/0x20
Feb 10 20:07:24 plasken kernel: [26005.771541] [<f89f16f5>] sky2_tx_timeout+0xf5/0x1c0 [sky2]
Feb 10 20:07:24 plasken kernel: [26005.771558] [dev_watchdog+0/208] dev_watchdog+0x0/0xd0
Feb 10 20:07:24 plasken kernel: [26005.771564] [dev_watchdog+193/208] dev_watchdog+0xc1/0xd0
Feb 10 20:07:24 plasken kernel: [26005.771573] [run_timer_softirq+303/416] run_timer_softirq+0x12f/0x1a0
Feb 10 20:07:24 plasken kernel: [26005.771585] [__do_softirq+130/256] __do_softirq+0x82/0x100
Feb 10 20:07:24 plasken kernel: [26005.771596] [do_softirq+85/96] do_softirq+0x55/0x60
Feb 10 20:07:24 plasken kernel: [26005.771602] [smp_apic_timer_interrupt+117/128] smp_apic_timer_interrupt+0x75/0x80
Feb 10 20:07:24 plasken kernel: [26005.771609] [apic_timer_interrupt+40/48] apic_timer_interrupt+0x28/0x30
Feb 10 20:07:24 plasken kernel: [26005.771621] [mwait_idle_with_hints+70/96] mwait_idle_with_hints+0x46/0x60
Feb 10 20:07:24 plasken kernel: [26005.771629] [cpu_idle+73/208] cpu_idle+0x49/0xd0
Feb 10 20:07:24 plasken kernel: [26005.771636] [start_kernel+863/1056] start_kernel+0x35f/0x420
Feb 10 20:07:24 plasken kernel: [26005.771643] [unknown_bootoption+0/608] unknown_bootoption+0x0/0x260
Feb 10 20:07:24 plasken kernel: [26005.771654] =======================
Feb 10 20:18:25 plasken -- MARK --
Feb 10 20:38:25 plasken -- MARK --
Feb 10 20:44:31 plasken syslogd 1.4.1#20ubuntu3: restart. # my hard power off / on

Forest Bond (forest-bond) wrote :

On Sat, Feb 10, 2007 at 08:56:06PM -0000, Anders wrote:
> It appears I spoke too quickly - the bug (or a very similar one)
> reoccurred on Feisty just now. Computer was hung when I got back, but
> from the syslog file it appears it kept writing -- MARK -- entries while
> 'dead':
>
> Feb 10 19:58:25 plasken -- MARK --
> Feb 10 20:07:15 plasken kernel: [25996.296585] NETDEV WATCHDOG: eth0: transmit timed out
> Feb 10 20:07:15 plasken kernel: [25996.296599] sky2 status report lost?
> Feb 10 20:07:24 plasken kernel: [26005.771487] [softlockup_tick+156/240] softlockup_tick+0x9c/0xf0
> Feb 10 20:07:24 plasken kernel: [26005.771503] [update_process_times+51/128] update_process_times+0x33/0x80
> Feb 10 20:07:24 plasken kernel: [26005.771512] [smp_apic_timer_interrupt+112/128] smp_apic_timer_interrupt+0x70/0x80
> Feb 10 20:07:24 plasken kernel: [26005.771519] [apic_timer_interrupt+40/48] apic_timer_interrupt+0x28/0x30
> Feb 10 20:07:24 plasken kernel: [26005.771532] [_spin_lock_bh+15/32] _spin_lock_bh+0xf/0x20
> Feb 10 20:07:24 plasken kernel: [26005.771541] [<f89f16f5>] sky2_tx_timeout+0xf5/0x1c0 [sky2]
> Feb 10 20:07:24 plasken kernel: [26005.771558] [dev_watchdog+0/208] dev_watchdog+0x0/0xd0
> Feb 10 20:07:24 plasken kernel: [26005.771564] [dev_watchdog+193/208] dev_watchdog+0xc1/0xd0
> Feb 10 20:07:24 plasken kernel: [26005.771573] [run_timer_softirq+303/416] run_timer_softirq+0x12f/0x1a0
> Feb 10 20:07:24 plasken kernel: [26005.771585] [__do_softirq+130/256] __do_softirq+0x82/0x100
> Feb 10 20:07:24 plasken kernel: [26005.771596] [do_softirq+85/96] do_softirq+0x55/0x60
> Feb 10 20:07:24 plasken kernel: [26005.771602] [smp_apic_timer_interrupt+117/128] smp_apic_timer_interrupt+0x75/0x80
> Feb 10 20:07:24 plasken kernel: [26005.771609] [apic_timer_interrupt+40/48] apic_timer_interrupt+0x28/0x30
> Feb 10 20:07:24 plasken kernel: [26005.771621] [mwait_idle_with_hints+70/96] mwait_idle_with_hints+0x46/0x60
> Feb 10 20:07:24 plasken kernel: [26005.771629] [cpu_idle+73/208] cpu_idle+0x49/0xd0
> Feb 10 20:07:24 plasken kernel: [26005.771636] [start_kernel+863/1056] start_kernel+0x35f/0x420
> Feb 10 20:07:24 plasken kernel: [26005.771643] [unknown_bootoption+0/608] unknown_bootoption+0x0/0x260
> Feb 10 20:07:24 plasken kernel: [26005.771654] =======================

I belive this is a separate issue. My symptoms (which have gone away since
upgrading my kernel) involved the network interface itself locking up, and the
problem was restricted to that only. You are getting "softlockup..." and
whatnot, plus some message that indicate to me that you have acpi issues. Maybe
try booting with "acpi=off" or "acpi=force" or something like that ... ?

-Forest

Ben Collins (ben-collins) wrote :

Yes, the softlockup is a different issue. Please open a new bug about this.

Changed in linux-source-2.6.20:
status: Unconfirmed → Rejected
zpro (cms01) wrote :

This bug, is still here, even in 7.04 beta, please fix this issue with sky2 driver,
I need at least one of my WAN connection working, (and yes, my wireless is 43xx chip from broadcomm)

I got lock ups, and heavy downloads, and uploads... this problem has been around since,
6.0.6 version of ubuntu and has never been fix.. NEVER.

TKS -
Rich

Forest Bond (forest-bond) wrote :

On Sat, Apr 07, 2007 at 02:47:52PM -0000, zpro wrote:
> This bug, is still here, even in 7.04 beta, please fix this issue with sky2
> driver, I need at least one of my WAN connection working, (and yes, my
> wireless is 43xx chip from broadcomm)
>
> I got lock ups, and heavy downloads, and uploads... this problem has been
> around since, 6.0.6 version of ubuntu and has never been fix.. NEVER.

I suspect you may have a different issue, potentially even a hardware or BIOS
issue. The sky2 lock-ups are fixed for me and others who reported the problem.
Your lock-ups are probably not related to the original bug that was causing
everyone else's lock-ups.

You should file a separate support request on Launchpad. I sincerely hope your
situation does improve.

-Forest

zpro (cms01) wrote :

I suspect you may have a different issue, potentially even a hardware or BIOS
issue. The sky2 lock-ups are fixed for me and others who reported the problem.
Your lock-ups are probably not related to the original bug that was causing
everyone else's lock-ups.

You should file a separate support request on Launchpad. I sincerely hope your
situation does improve.

-Forest

----------------------

Nope, its not that, since I can run bsd with no problem, for networking,
and windows xp and vista, with no problems, as well, ONLY with the sky2 driver,
take a poll, to see how many are really fix ( without major hacking) not many..
search for sky2, in launch pad, you will see problems all over.

My laptop was brand new AMD 64bit gateway back in Feb 2006,
again, it has all the extras, and the dreaded broadcomm 43xx wireless driver.

in-fact, the only way for me to connect without issues, is using a nswrapper driver, and hacking the 43xx wireless. had no-download issue going wireless.

Regards-
Rich

Chris Yoder (cyoder) wrote :

I can still reproduce this at will, but it only happens when the link is close to saturated.

02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8038 PCI-E Fast Ethernet Controller (rev 14)
        Subsystem: Gateway 2000 Unknown device 0366
        Flags: bus master, fast devsel, latency 0, IRQ 17
        Memory at d4000000 (64-bit, non-prefetchable) [size=16K]
        I/O ports at 2000 [size=256]
        Capabilities: [48] Power Management version 2
        Capabilities: [50] Vital Product Data
        Capabilities: [5c] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable-
        Capabilities: [e0] Express Legacy Endpoint IRQ 0

Linux clam 2.6.20-15-generic #2 SMP Sun Apr 15 07:36:31 UTC 2007 i686 GNU/Linux

Chris,

What are your steps to reproduce this reliably?

Dan

On 07/05/07, Chris Yoder <email address hidden> wrote:
> I can still reproduce this at will, but it only happens when the link is
> close to saturated.
>
> 02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8038 PCI-E Fast Ethernet Controller (rev 14)
> Subsystem: Gateway 2000 Unknown device 0366
> Flags: bus master, fast devsel, latency 0, IRQ 17
> Memory at d4000000 (64-bit, non-prefetchable) [size=16K]
> I/O ports at 2000 [size=256]
> Capabilities: [48] Power Management version 2
> Capabilities: [50] Vital Product Data
> Capabilities: [5c] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable-
> Capabilities: [e0] Express Legacy Endpoint IRQ 0
>
> Linux clam 2.6.20-15-generic #2 SMP Sun Apr 15 07:36:31 UTC 2007 i686
> GNU/Linux
>
> --
> sky2 driver stalls
> https://bugs.launchpad.net/bugs/68338
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Daniel J Blueman

Chris Yoder (cyoder) wrote :

Using rsync, move lots of data from a Solaris box, to the local system. If I use bwlimit to limit rsync, it doesn't happen, but if I just let rsync rip, it will happen.

I don't know how much data needs to be moved to trigger it, as it doesn't seem consistent.

Chris Yoder (cyoder) wrote :

OK, here are some more details. If you want me to do anything specific while the interface is hung, please let me know.

I'm pretty comfortable with debuggers and such, given what I do IRL, I kinda wish someone would port mdb to linux though.

rsync in one window, netstat -i in another, every 60 seconds or so.

Starting netstat:

cyoder@clam:~$ netstat -i
Kernel Interface table
Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0 1500 0 44812 0 0 0 7414 0 0 0 BMRU
eth1 1500 0 0 0 2446 0 0 0 0 0 BMU
eth1: 1500 0 - no statistics available - BMU
lo 16436 0 30 0 0 0 30 0 0 0 LRU
cyoder@clam:~$ while true
> do
> sleep 60
> netstat -i
> done

Final netstat:

Kernel Interface table
Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0 1500 0 2057052 0 0 0 1044967 0 0 0 BMRU
eth1 1500 0 0 0 2509 0 0 0 0 0 BMU
eth1: 1500 0 - no statistics available - BMU
lo 16436 0 32 0 0 0 32 0 0 0 LRU
Kernel Interface table
Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0 1500 0 2057052 0 0 0 1044967 0 0 0 BMRU
eth1 1500 0 0 0 2525 0 0 0 0 0 BMU
eth1: 1500 0 - no statistics available - BMU
lo 16436 0 40 0 0 0 40 0 0 0 LRU

eth1 is a Intel 3945 unconfigured.

Final rsync output and recovery:

Lynyrd_Skynyrd/Christmas_Time_Again/02_Rudolph_the_Red-Nosed_Reindeer.mp3
     2425000 100% 2.36MB/s 0:00:00 (xfer#659, to-check=10334/15967)
Lynyrd_Skynyrd/Christmas_Time_Again/03_Christmas_Time_Again.mp3
     4386064 100% 2.21MB/s 0:00:01 (xfer#660, to-check=10333/15967)
Lynyrd_Skynyrd/Christmas_Time_Again/04_Greensleeves.mp3
rsync error: unexplained error (code 130) at rsync.c(271) [generator=2.6.9]
rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(271) [receiver=2.6.9]

real 10m20.775s
user 1m34.122s
sys 0m18.405s
cyoder@clam:/media/WD Passport$ ping mage

cyoder@clam:/media/WD Passport$ sudo rmmod sky2Password:
cyoder@clam:/media/WD Passport$ sudo modprobe sky2
cyoder@clam:/media/WD Passport$ ping mage
ping: unknown host mage
cyoder@clam:/media/WD Passport$ ping mage
PING mage(129..x) 56(84) bytes of data.
64 bytes from mage (129.x): icmp_seq=1 ttl=255 time=5.35 ms
64 bytes from mage (129..x): icmp_seq=2 ttl=255 time=0.345 ms

--- mage ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1004ms
rtt min/avg/max/mdev = 0.345/2.849/5.353/2.504 ms

Changed in linux-source-2.6.17:
assignee: nobody → ubuntu-kernel-team
Philipp Edelmann (tukss) wrote :

I had the same problem using the Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit Ethernet Controller (rev 22) in a MacBookPro C2Duo when copying large amounts of data via ssh. Sending empty packets via netcat didn't trigger the problem. I found out that plugging the two computers together directly instead of using a hub solved the problem. Still I don't think the problem is only related to the hub, because the other computers on this hub didn't have the same problem.
I'm using the gutsy kernel from git with mactel patches.

Sitsofe Wheeler (sitsofe) wrote :

Chris:
Is this any better on a Gutsy liveCD?

Chris Yoder (cyoder) wrote :

On Wed, Aug 29, 2007 at 05:50:21PM -0000, Sitsofe Wheeler wrote:
> Chris:
> Is this any better on a Gutsy liveCD?

I haven't tried it on a livecd, and haven't moved lots of data, since the
upgrade to gutsy.

I will do an apropriate test here in a few minutes, and let you know the
results though.

Anything specific you want me to watch?

eze80 (ezequiel-pozzo) wrote :

I'm having the same problem under feisty kernel 2.6.20-16-generic

Any ideas?

Sitsofe Wheeler (sitsofe) wrote :

Chris:
Sorry for the slow reply. The only thing to watch for is whether the stalls continue occurring and a note indicating which kernel version (uname -a) you were testing.

Chris Yoder (cyoder) wrote :

Sitsofe:

I have not been able to force it to happen since I've upgraded to gutsy.

telecon@clam:~$ uname -a
Linux clam 2.6.22-12-generic #1 SMP Thu Sep 20 18:51:18 GMT 2007 i686 GNU/Linux
telecon@clam:~$

I'll test every so often as gutsy gets closer to release, and see if it pops back up.

Sitsofe Wheeler (sitsofe) wrote :

Chris:
Thanks for reporting back. Whatever your conclusion do report back. I'm not sure what should be done with the 2.6.17 status though since it sounds like the problem was only really resolved in Gutsy's kernel...

Changed in linux-source-2.6.17:
status: New → Won't Fix
Changed in linux-source-2.6.17:
status: Fix Committed → Won't Fix
Mirar (launchpad-sort) wrote :

I still get "tx timeout" now and then. Sometimes the network manages to get back on track, sometimes it just leaves a complete mess and I have to reboot.

Mar 12 15:40:23 iris kernel: [162717.506822] NETDEV WATCHDOG: eth1: transmit timed out
Mar 12 15:40:23 iris kernel: [162717.506827] sky2 eth1: tx timeout
Mar 12 15:40:23 iris kernel: [162717.506833] sky2 eth1: transmit ring 2 .. 474 report=2 done=2
Mar 12 15:40:23 iris kernel: [162717.506862] sky2 eth1: disabling interface
Mar 12 15:40:23 iris kernel: [162717.507201] sky2 eth1: enabling interface
Mar 12 15:40:27 iris kernel: [162720.528273] sky2 eth1: Link is up at 1000 Mbps, full duplex, flow control both

Tried:
Ubuntu Gutsy 2.6.22-14
Ubuntu Hardy 2.6.24-11
kernel.org 2.6.22.1
kernel.org 2.6.24.3

I'm starting to suspect something is fishy with the hardware, actually. But how do I know?

[ 58.026424] ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -> IRQ
 17
[ 58.026523] PCI: Setting latency timer of device 0000:03:00.0 to 64
[ 58.027459] sky2 0000:03:00.0: v1.20 addr 0xf4000000 irq 17 Yukon-EC Ultra (0xb4) rev 2
[ 58.027882] sky2 eth0: addr 00:16:e6:8c:ec:d9

03:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8056 PCI-E Gigabit Ethernet Controller (rev 12)

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers