PROBLEM: freeze when resuming from suspend-to-ram

PROBLEM: freeze when resuming from suspend-to-ram

[medhefgo]

Hello, 

When resuming from suspend-to-ram the kernel freezes. Git bisect output below. 
When removing the sis900 module or if eth0 hasn't yet been brought up with "ip 
link set eth0 up", resuming works fine.

This is happening on a up-to-date Arch installation with kernel 3.6.6 and is 
still present in 3.7-rc5. Reverting the patch is possible and fixes the 
freezing.

Please let me know if more info is requried to fix this.

Thanks,
Jan

57d6d456cfb89264f87d24f52640ede23fdf12bd is the first bad commit
commit 57d6d456cfb89264f87d24f52640ede23fdf12bd
Author: Francois Romieu <romieu@fr.zoreil.com>
Date:   Tue Mar 13 11:14:17 2012 +0100

    sis900: stop using net_device.{base_addr, irq} and convert to __iomem.
    
    - pci_resource_start() can be removed from sis900_get_mac_addr() because
      the IO range is maped and stored into the device private struct early
      in the device probe function.
    - the driver contains a few direct accesses to low IO ports that forbid
      to re(#)define the usual out{l, w, b} macros.
    
    Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
    Cc: Daniele Venzano <venza@brownhat.org>

:040000 040000 f328a3383c1ff9b9ed16de7272b4c8a302ae2812 
44c07bfe1bd23b381fd407dfaa9591ed26165afd M      drivers

Re: PROBLEM: freeze when resuming from suspend-to-ram

[Daniele Venzano]

On Sun, Nov 11, 2012 at 08:47:45PM +0100, medhefgo@web.de wrote:
> Hello, 
> 
> When resuming from suspend-to-ram the kernel freezes. Git bisect output below. 
> When removing the sis900 module or if eth0 hasn't yet been brought up with "ip 
> link set eth0 up", resuming works fine.
> 
> This is happening on a up-to-date Arch installation with kernel 3.6.6 and is 
> still present in 3.7-rc5. Reverting the patch is possible and fixes the 
> freezing.

The patch is big and, while by looking at it nothing jumps to my eyes as
clearly wrong, I currently do not have access to sis900 hardware to test
it. Francois Romieu (in CC), who did the patch, perhaps can shed some light.

Otherwise I cannot work on it before next month, when I'll be able to
put my hands on the hardware.

> 57d6d456cfb89264f87d24f52640ede23fdf12bd is the first bad commit
> commit 57d6d456cfb89264f87d24f52640ede23fdf12bd
> Author: Francois Romieu <romieu@fr.zoreil.com>
> Date:   Tue Mar 13 11:14:17 2012 +0100
> 
>     sis900: stop using net_device.{base_addr, irq} and convert to __iomem.
>     
>     - pci_resource_start() can be removed from sis900_get_mac_addr() because
>       the IO range is maped and stored into the device private struct early
>       in the device probe function.
>     - the driver contains a few direct accesses to low IO ports that forbid
>       to re(#)define the usual out{l, w, b} macros.
>     
>     Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
>     Cc: Daniele Venzano <venza@brownhat.org>
> 
> :040000 040000 f328a3383c1ff9b9ed16de7272b4c8a302ae2812 
> 44c07bfe1bd23b381fd407dfaa9591ed26165afd M      drivers

Thanks.

-- 
Daniele Venzano
http://www.brownhat.org

Re: PROBLEM: freeze when resuming from suspend-to-ram

[Francois Romieu]

Thanks for Cc:ing Daniele.

Daniele Venzano <venza@brownhat.org> :
> On Sun, Nov 11, 2012 at 08:47:45PM +0100, medhefgo@web.de wrote:
[...]
> The patch is big and, while by looking at it nothing jumps to my eyes as
> clearly wrong, I currently do not have access to sis900 hardware to test
> it. Francois Romieu (in CC), who did the patch, perhaps can shed some light.

Nothing here. I'll search harder but I won't mind some brute force approach
at the same time.

Jan, is it ok if I split this changeset in smaller chunks to identify
which part bugs / triggers the problem ? If so please specify a kernel
version - linusish or stable - I should work with.

-- 
Ueimor

Re: PROBLEM: freeze when resuming from suspend-to-ram

[Jan Janssen]

Hi,

On Saturday 17 November 2012 11:57:02 you wrote:
> Jan, is it ok if I split this changeset in smaller chunks to identify
> which part bugs / triggers the problem ? If so please specify a kernel
> version - linusish or stable - I should work with.
I'd be glad to help you with that. The bug happens with 3.6.6 and with 3.7-
rc6. Pick one that suits you best, I can work with both.

Jan

Re: PROBLEM: freeze when resuming from suspend-to-ram

[Francois Romieu]

Jan Janssen <medhefgo@web.de> :
[...]
> I'd be glad to help you with that. The bug happens with 3.6.6 and with 3.7-
> rc6. Pick one that suits you best, I can work with both.

/me slaps head.

Please try the patch below against v3.7-rc6

diff --git a/drivers/net/ethernet/sis/sis900.c b/drivers/net/ethernet/sis/sis900.c
index fb9f6b3..edf5edb 100644
--- a/drivers/net/ethernet/sis/sis900.c
+++ b/drivers/net/ethernet/sis/sis900.c
@@ -2479,7 +2479,7 @@ static int sis900_resume(struct pci_dev *pci_dev)
 	netif_start_queue(net_dev);
 
 	/* Workaround for EDB */
-	sis900_set_mode(ioaddr, HW_SPEED_10_MBPS, FDX_CAPABLE_HALF_SELECTED);
+	sis900_set_mode(sis_priv, HW_SPEED_10_MBPS, FDX_CAPABLE_HALF_SELECTED);
 
 	/* Enable all known interrupts by setting the interrupt mask. */
 	sw32(imr, RxSOVR | RxORN | RxERR | RxOK | TxURN | TxERR | TxIDLE);

Re: PROBLEM: freeze when resuming from suspend-to-ram

[Jan Janssen]

On Saturday 17 November 2012 20:20:36 Francois Romieu wrote:
> Jan Janssen <medhefgo@web.de> :
> [...]
> 
> > I'd be glad to help you with that. The bug happens with 3.6.6 and with
> > 3.7-
> > rc6. Pick one that suits you best, I can work with both.
> 
> /me slaps head.
> 
> Please try the patch below against v3.7-rc6
> 
> diff --git a/drivers/net/ethernet/sis/sis900.c
> b/drivers/net/ethernet/sis/sis900.c index fb9f6b3..edf5edb 100644
> --- a/drivers/net/ethernet/sis/sis900.c
> +++ b/drivers/net/ethernet/sis/sis900.c
> @@ -2479,7 +2479,7 @@ static int sis900_resume(struct pci_dev *pci_dev)
>  	netif_start_queue(net_dev);
> 
>  	/* Workaround for EDB */
> -	sis900_set_mode(ioaddr, HW_SPEED_10_MBPS, FDX_CAPABLE_HALF_SELECTED);
> +	sis900_set_mode(sis_priv, HW_SPEED_10_MBPS, FDX_CAPABLE_HALF_SELECTED);
> 
>  	/* Enable all known interrupts by setting the interrupt mask. */
>  	sw32(imr, RxSOVR | RxORN | RxERR | RxOK | TxURN | TxERR | TxIDLE);
This seems to fix it. I was able to repeatedly suspend and resume.

On my first resume try I did get a netdev watchdog timeout right after I got 
back to my shell prompt, but it wasn't reproducable. So, I'm assuming it's 
some unrelated rc or hardware issue. Thought I might better mention it.

Jan