netdev - Re: r8169 delay / segfault

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 18 Oct 2012 23:06:10 +0200
From:	Roland Stigge <stigge@...com.de>
To:	Francois Romieu <romieu@...zoreil.com>
CC:	nic_swsd@...ltek.com, netdev@...r.kernel.org,
	hayeswang <hayeswang@...ltek.com>
Subject: Re: r8169 delay / segfault

On 14/10/12 23:32, Francois Romieu wrote:
>> How can we force the device out of D3 power state?
>>
>> I also compared with kernel 3.5, and it seems like a regression to me,
>> With 3.5, it works and tells on resume:
> 
> Can you try both a 3.5 kernel with the 3.6 r8169 driver and a 3.6 kernel
> with the 3.5 r8169 driver ?

Sorry for the delay.

What makes the whole thing difficult is that on vanilla 3.6, the problem
happens always, while with vanilla 3.5 it also happens but much less
often - about every 10th suspend / resume cycle.

To test the 3.5 r8169 driver with a 3.6 kernel, and vice versa, I copied
over the r8169.c file, respectively.

The result is that the 3.6 kernel with the "old" driver shows the same
issue as the vanilla 3.6. On 3.5 I also see the same thing happen as
before - every 10th suspend / resume cycle the problem happens,
independent of the "old" or "new" driver.

So the difference comes from the kernel, but finally it is present
anyway. Maybe it is just triggered more efficiently in 3.6? ;-)

Remember that I don't encountered problems with other drivers'
suspend/resume, only with the r8169.

Thanks for considering. Please tell me how I can help further on this issue.

Roland
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html