Bug#918042: WoL does not work on r8169 (regression since 4.18)

2021-05-30 Thread Marc Haber
On Sat, May 29, 2021 at 10:55:44AM +0200, Salvatore Bonaccorso wrote:
> Marc, ist this still something you can reproduce with a recent kernel?

No, I don't have the hardware in use any more. Current machine has an
Intel i211 which wakes up reliably.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421



Bug#918042: WoL does not work on r8169 (regression since 4.18)

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

On Wed, Jan 02, 2019 at 07:02:42PM +0100, Marc Haber wrote:
> Package: src:linux
> Version: 4.20-1~exp1
> Severity: normal
> 
> Hi,
> 
> I frequently send my desktop PC to sleep (suspend-to-ram) and wake it up
> from remote when I need to access it. To do so, I use a script on a
> banana pi which ends up calling etherwake 54:04:a6:82:21:00. This
> has worked reliably up to the last 4.18 release, including the Debian
> kernel linux-image-4.18.0-3-amd64 version 4.18.20-2.
> 
> In 4.19, this ceased to work and has remained that way up to the kernel
> I am reporting this issue on, linux-image-4.20.0-trunk-amd64 version
> 4.20-1~exp1. I have observed this behavior also on my "own", locally
> built kernels of various 4.19 releases and also 4.20. Sorry, I didn't
> try any Debian 4.19 kernels, I decided to pursue this issue further
> after the regression was also present in 4.20.
> 
> I am prepared to try kernel patches or follow other hints in debugging
> this. I acknowledge that this is most probably an upstream issue, but I
> don't have enough kernel foo to investigate this on an upstream level
> (and frankly, I am afraid of doing a bisect between 4.18 and 4.19).
> 
> Any hints will be appreciated.

Marc, ist this still something you can reproduce with a recent kernel?

Regards,
Salvatore



Bug#918042: WoL does not work on r8169 (regression since 4.18)

2019-01-02 Thread Marc Haber
Package: src:linux
Version: 4.20-1~exp1
Severity: normal

Hi,

I frequently send my desktop PC to sleep (suspend-to-ram) and wake it up
from remote when I need to access it. To do so, I use a script on a
banana pi which ends up calling etherwake 54:04:a6:82:21:00. This
has worked reliably up to the last 4.18 release, including the Debian
kernel linux-image-4.18.0-3-amd64 version 4.18.20-2.

In 4.19, this ceased to work and has remained that way up to the kernel
I am reporting this issue on, linux-image-4.20.0-trunk-amd64 version
4.20-1~exp1. I have observed this behavior also on my "own", locally
built kernels of various 4.19 releases and also 4.20. Sorry, I didn't
try any Debian 4.19 kernels, I decided to pursue this issue further
after the regression was also present in 4.20.

I am prepared to try kernel patches or follow other hints in debugging
this. I acknowledge that this is most probably an upstream issue, but I
don't have enough kernel foo to investigate this on an upstream level
(and frankly, I am afraid of doing a bisect between 4.18 and 4.19).

Any hints will be appreciated.

-- Package-specific info:
** Version:
Linux version 4.20.0-trunk-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.2.0 (Debian 8.2.0-13)) #1 SMP Debian 4.20-1~exp1 (2018-12-24)

** Command line:
BOOT_IMAGE=/vmlinuz-4.20.0-trunk-amd64 root=/dev/mapper/root ro splash 
console=ttyS0,57600n8 quiet

** Not tainted

** Kernel log:
[  225.803103] sd 4:0:0:0: [sdb] Synchronizing SCSI cache
[  225.803252] sd 1:0:0:0: [sda] Stopping disk
[  225.805950] sd 4:0:0:0: [sdb] Stopping disk
[  225.810535] sd 5:0:0:0: [sdc] Synchronizing SCSI cache
[  225.810750] sd 5:0:0:0: [sdc] Stopping disk
[  229.997427] ACPI: EC: interrupt blocked
[  230.015575] ACPI: Preparing to enter system sleep state S3
[  230.017796] ACPI: EC: event blocked
[  230.017797] ACPI: EC: EC stopped
[  230.017798] PM: Saving platform NVS memory
[  230.017802] Disabling non-boot CPUs ...
[  230.031585] IRQ 17: no longer affine to CPU1
[  230.031600] IRQ 19: no longer affine to CPU1
[  230.032656] smpboot: CPU 1 is now offline
[  230.052563] smpboot: CPU 2 is now offline
[  230.083457] IRQ 24: no longer affine to CPU3
[  230.083479] IRQ 37: no longer affine to CPU3
[  230.084506] smpboot: CPU 3 is now offline
[  230.107073] IRQ 33: no longer affine to CPU4
[  230.108097] smpboot: CPU 4 is now offline
[  230.131161] IRQ 29: no longer affine to CPU5
[  230.131171] IRQ 34: no longer affine to CPU5
[  230.132203] smpboot: CPU 5 is now offline
[  230.137594] ACPI: Low-level resume complete
[  230.137631] ACPI: EC: EC started
[  230.137632] PM: Restoring platform NVS memory
[  230.137646] PCI-DMA: Resuming GART IOMMU
[  230.137647] PCI-DMA: Restoring GART aperture settings
[  230.137652] LVT offset 1 assigned for vector 0x400
[  230.137662] LVT offset 1 assigned
[  230.137908] microcode: CPU0: new patch_level=0x01dc
[  230.137935] Enabling non-boot CPUs ...
[  230.137974] x86: Booting SMP configuration:
[  230.137975] smpboot: Booting Node 0 Processor 1 APIC 0x1
[  230.140530] TSC synchronization [CPU#0 -> CPU#1]:
[  230.140531] Measured 4350120160 cycles TSC warp between CPUs, turning off 
TSC clock.
[  230.140533] tsc: Marking TSC unstable due to check_tsc_sync_source failed
[  230.140536] TSC found unstable after boot, most likely due to broken BIOS. 
Use 'tsc=unstable'.
[  230.140537] sched_clock: Marking unstable (230135957339, 
2389616)<-(230439424037, -29477)
[  231.493902] process: Switch to broadcast mode on CPU1
[  231.494117]  cache: parent cpu1 should not be sleeping
[  231.494207] microcode: CPU1: patch_level=0x01dc
[  231.494380] clocksource: Switched to clocksource hpet
[  230.138878] CPU1 is up
[  230.138902] smpboot: Booting Node 0 Processor 2 APIC 0x2
[  230.142346] process: Switch to broadcast mode on CPU2
[  230.142346]  cache: parent cpu2 should not be sleeping
[  230.142346] microcode: CPU2: patch_level=0x01dc
[  230.142346] CPU2 is up
[  230.142346] smpboot: Booting Node 0 Processor 3 APIC 0x3
[  230.142346] process: Switch to broadcast mode on CPU3
[  230.142346]  cache: parent cpu3 should not be sleeping
[  230.142346] microcode: CPU3: patch_level=0x01dc
[  230.142346] CPU3 is up
[  230.142346] smpboot: Booting Node 0 Processor 4 APIC 0x4
[  230.142346] process: Switch to broadcast mode on CPU4
[  230.142346]  cache: parent cpu4 should not be sleeping
[  230.142346] microcode: CPU4: patch_level=0x01dc
[  230.142346] CPU4 is up
[  230.142346] smpboot: Booting Node 0 Processor 5 APIC 0x5
[  230.142346] process: Switch to broadcast mode on CPU5
[  230.142869]  cache: parent cpu5 should not be sleeping
[  230.142970] microcode: CPU5: patch_level=0x01dc
[  230.143185] CPU5 is up
[  230.149748] ACPI: Waking up from system sleep state S3
[  230.258927] ACPI: EC: interrupt unblocked
[  231.495557] ACPI: EC: event unblocked
[  231.496009] usb usb2: root hub lost power or was reset
[  231.496011] usb usb4: root hub lost power or