Bug#895378: sky2: sky2: did not recover correctly after waking up from S3

2021-05-23 Thread Salvatore Bonaccorso
Control: tags -1 + moreinfo

Hi,

On Sun, Oct 14, 2018 at 11:21:32AM +0200, Laurent Bigonville wrote:
> Source: linux
> Version: 4.18.10-2
> Followup-For: Bug #895378
> 
> Hi,
> 
> I can confirm this (and it's quite annoying).
> 
> It worked fine in 4.14 and it's broken since 4.15.
> 
> I'm trying to bissect the kernel but it is not even booting ("32-bits
> relocation outside of the kernel) and I'm not too sure how to fix that.

Is this still an issue with a recent kernel?

Regards,
Salvatore



Bug#895378: sky2: sky2: did not recover correctly after waking up from S3

2021-05-23 Thread Manuel Bilderbeek
Yes, it is. Just had it yesterday with an updated testing.

Op zo 23 mei 2021 14:58 schreef Salvatore Bonaccorso :

> Control: tags -1 + moreinfo
>
> Hi,
>
> On Sun, Oct 14, 2018 at 11:21:32AM +0200, Laurent Bigonville wrote:
> > Source: linux
> > Version: 4.18.10-2
> > Followup-For: Bug #895378
> >
> > Hi,
> >
> > I can confirm this (and it's quite annoying).
> >
> > It worked fine in 4.14 and it's broken since 4.15.
> >
> > I'm trying to bissect the kernel but it is not even booting ("32-bits
> > relocation outside of the kernel) and I'm not too sure how to fix that.
>
> Is this still an issue with a recent kernel?
>
> Regards,
> Salvatore
>


Bug#895378: sky2: sky2: did not recover correctly after waking up from S3

2018-04-10 Thread Manuel Bilderbeek
Package: src:linux
Version: 4.15.11-1
Severity: normal
File: sky2

Dear Maintainer,

   * What led up to the situation?

I started up my PC and didn't do anything. The system went into S3.

After I woke it up, all worked, except networking.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

The system told me that the cable was unplugged, but it wasn't.
After I remember the system woke up from S3, I removed the sky2 module and
modprobed it again. After that, networking started to work again immediately.

   * What was the outcome of this action?
   * What outcome did you expect instead?

I expected that networking would just work after waking up from S3.

Here's the sky2 story:

Boot:
[0.961316] sky2: driver version 1.30
[0.961442] sky2 :02:00.0: Yukon-2 EC Ultra chip revision 3
[0.966930] sky2 :02:00.0 eth0: addr 00:22:15:0f:99:ab
[7.370976] sky2 :02:00.0 eth0: enabling interface
[9.036080] sky2 :02:00.0 eth0: Link is up at 100 Mbps, full duplex, 
flow control both

Auto-suspend to S3 due to inactivity:
[ 1214.668015] sky2 :02:00.0 eth0: disabling interface

Waking up:
[ 1219.713183] sky2 :02:00.0 eth0: enabling interface

That's all. No message that the link is up. In fact:
[ 1219.716325] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

Me, trying to recover by rmmod and modprobing:
[ 6711.523687] sky2 :02:00.0 eth0: disabling interface
[ 6714.918429] sky2: driver version 1.30
[ 6714.918573] sky2 :02:00.0: Yukon-2 EC Ultra chip revision 3
[ 6714.919025] sky2 :02:00.0 eth0: addr 00:22:15:0f:99:ab
[ 6714.939691] sky2 :02:00.0 eth0: enabling interface
[ 6716.623117] sky2 :02:00.0 eth0: Link is up at 100 Mbps, full duplex, 
flow control both

-- Package-specific info:
** Version:
Linux version 4.15.0-2-amd64 (debian-kernel@lists.debian.org) (gcc version 
7.3.0 (Debian 7.3.0-12)) #1 SMP Debian 4.15.11-1 (2018-03-20)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.15.0-2-amd64 
root=UUID=8efc387d-cdc0-496d-8f3c-03cc7f4ac8a5 ro quiet

** Tainted: PO (4097)
 * Proprietary module has been loaded.
 * Out-of-tree module has been loaded.

** Kernel log:
[ 1216.216183] smpboot: Booting Node 0 Processor 1 APIC 0x1
[ 1216.223242]  cache: parent cpu1 should not be sleeping
[ 1216.223320] microcode: sig=0x10677, pf=0x10, revision=0x703
[ 1216.227607] microcode: updated to revision 0x70a, date = 2010-09-29
[ 1216.227817] CPU1 is up
[ 1216.227846] smpboot: Booting Node 0 Processor 2 APIC 0x2
[ 1216.230620]  cache: parent cpu2 should not be sleeping
[ 1216.235237] CPU2 is up
[ 1216.235255] smpboot: Booting Node 0 Processor 3 APIC 0x3
[ 1216.238015]  cache: parent cpu3 should not be sleeping
[ 1216.242645] CPU3 is up
[ 1216.247339] ACPI: Waking up from system sleep state S3
[ 1216.405572] usb usb3: root hub lost power or was reset
[ 1216.405591] usb usb4: root hub lost power or was reset
[ 1216.405627] usb usb5: root hub lost power or was reset
[ 1216.405688] usb usb6: root hub lost power or was reset
[ 1216.405734] usb usb7: root hub lost power or was reset
[ 1216.405760] usb usb8: root hub lost power or was reset
[ 1216.405818] rtc_cmos 00:01: Alarms can be up to one month in the future
[ 1216.406434] serial 00:06: activated
[ 1216.417931] sd 2:0:0:0: [sda] Starting disk
[ 1216.424886] sd 5:0:0:0: [sdf] Starting disk
[ 1216.760886] usb 3-1: reset full-speed USB device number 2 using uhci_hcd
[ 1216.787119] ata5: SATA link down (SStatus 0 SControl 300)
[ 1216.787136] ata2: SATA link down (SStatus 0 SControl 300)
[ 1216.908871] usb 8-2: reset low-speed USB device number 3 using uhci_hcd
[ 1216.948872] ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 1216.948885] ata6: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 1216.949120] ata6.00: supports DRM functions and may not be fully accessible
[ 1216.953581] ata6.00: supports DRM functions and may not be fully accessible
[ 1216.958405] ata6.00: configured for UDMA/133
[ 1216.958457] ata6.00: Enabling discard_zeroes_data
[ 1217.001936] ata4.00: configured for UDMA/100
[ 1217.172872] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 1217.175606] ata1.00: configured for UDMA/66
[ 1217.476878] usb 8-1: reset low-speed USB device number 2 using uhci_hcd

[ 1219.548864] floppy driver state
[ 1219.548864] ---
[ 1219.548871] now=4295197184 last interrupt=4294892540 diff=304644 last called 
handler=reset_interrupt [floppy]
[ 1219.548872] timeout_message=lock fdc
[ 1219.548872] last output bytes:
[ 1219.548873]  8 80 4294892535
[ 1219.548874]  8 80 4294892535
[ 1219.548875]  8 90 4294892535
[ 1219.548875]  8 80 4294892539
[ 1219.548876]  8 90 4294892539
[ 1219.548877]  8 80 4294892539
[ 1219.548877]  8 90 4294892539
[ 1219.548878]  e 80 4294892539
[ 1219.548879] 13 90 4294892539
[ 1219.548879]  0 90 4294892539
[ 1219.548880] 1a 90 4294892539
[ 1219.548881]  0 90 4294892539
[ 1219.548881] 12 90 4294892539
[ 1219.548882]  0 90 4294892539
[ 1219.548883] 14 90 4

Bug#895378: sky2: sky2: did not recover correctly after waking up from S3

2018-10-14 Thread Laurent Bigonville
Source: linux
Version: 4.18.10-2
Followup-For: Bug #895378

Hi,

I can confirm this (and it's quite annoying).

It worked fine in 4.14 and it's broken since 4.15.

I'm trying to bissect the kernel but it is not even booting ("32-bits
relocation outside of the kernel) and I'm not too sure how to fix that.


-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy



Bug#895378: sky2: sky2: did not recover correctly after waking up from S3

2019-03-10 Thread computer.enthusiastic
I have the same issue with the current Debian Buster kernel using an
Acer Aspire 5930G both with suspension and the hibernation; I'm using
the following kernel:
$uname -a
Linux debian 4.19.0-2-amd64 #1 SMP Debian 4.19.16-1 (2019-01-17)
x86_64 GNU/Linux

After suspension or hibernation, the network connection is not
re-established with a NO-CARRIER error. A first work-around is to
unload and reload the sky2 kernel driver with the folllowing commands:
modprobe -r sky2
modprobe sky2

It seems a kernel bug and it is discussed, for example, in this Ubuntu
bug report: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1798921

In this message
(https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1798921/comments/28)
the author suggests (on Debian) to start  the kernel with the
following parameters to work-around the bug:
pci=nomsi,noaer

I have tried and it works.



Bug#895378: sky2: sky2: did not recover correctly after waking up from S3

2019-03-12 Thread Achille M. Luongo
Hi,

just an update about my previous post. The "pci=nomsi,noaer"
workaround is effective for resume after suspend, but it locks my
computer in resume after hibernation (the computer resumes, but it
locks on resume with a black screen when it should instead show the
login dialog; this probably happens for an interaction between "nomsi"
kernel option and the nvidia proprietary  driver, I suppose).

So that, I opted for the following simpler workaround: I created an
hook in  /lib/systemd/system-sleep (acording to
systemd-suspend.service manual page) containing the following bash
script:

#!/bin/sh
## This file (or a link to it) must be in /lib/systemd/system-sleep/
modprobe -r sky2
modprobe sky

When systemd resumes from hibernation or suspend the script is
executed and the sky2 network card driver is reset.

I hope this kernel bug would be solved soon.



Processed: Re: Bug#895378: sky2: sky2: did not recover correctly after waking up from S3

2021-05-23 Thread Debian Bug Tracking System
Processing control commands:

> tags -1 + moreinfo
Bug #895378 [src:linux] sky2: sky2: did not recover correctly after waking up 
from S3
Added tag(s) moreinfo.

-- 
895378: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895378
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems