linux-kernel - Re: [Stable-review] [20/98] atl1c:use common_task instead of reset_task and link_chg

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 for Android: free password hash cracker in your pocket

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

Date:	Sat, 30 Jan 2010 19:09:29 +0100
From:	Willy Tarreau <w@....eu>
To:	Greg KH <gregkh@...e.de>
Cc:	linux-kernel@...r.kernel.org, stable@...nel.org,
	Jie Yang <jie.yang@...eros.com>, stable-review@...nel.org,
	akpm@...ux-foundation.org, torvalds@...ux-foundation.org,
	"David S. Miller" <davem@...emloft.net>, alan@...rguk.ukuu.org.uk
Subject: Re: [Stable-review] [20/98] atl1c:use common_task instead of reset_task and link_chg_task

On Wed, Jan 27, 2010 at 06:25:31AM +0100, Willy Tarreau wrote:
> On Tue, Jan 26, 2010 at 03:33:46PM -0800, Greg KH wrote:
> > From: Jie Yang <jie.yang@...eros.com>
> > 
> > commit cb19054697e92a793f336380fd72c588521178ff upstream.
> > 
> > use common_task instead of reset_task and link_chg_task, so it fix "call cancel_work_sync
> > from the work itself".
> > 
> > Signed-off-by: Jie Yang <jie.yang@...eros.com>
> > Signed-off-by: David S. Miller <davem@...emloft.net>
> > Cc: Ben Hutchings <ben@...adent.org.uk>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@...e.de>
> 
> I'm going to test this one. I'm randomly seeing my ASUS 1005HA
> hanging after I replug the network cable. I noticed that the
> driver from the Atheros site doesn't have the issue at all. I
> spent a week-end trying to eliminate almost all of the diffs
> between the two drivers to try to spot the faulty code chunk,
> until I realized that I went past the failure point without
> noticing in time because the issue was too much random :-(
> 
> Clearly a non-bisectable issue. But with just this fix, I'll
> be able to tell if the problem is definitely over.

For the record, this patch has fixed my issue, the machine no
longer hangs when I plug the cable. However, now when I unplug
then replug the link, it normally takes 1 second to get back up,
until I suspend. After the first suspend/resume cycle, it always
takes 16 seconds to get the link up every time I unplug/replug
it. If I wait before replugging, it gets up later (by the amount
of time spent unplugged). Same if I unplug, wait a bit, then
replug/unplug then replug. It still takes 16 seconds after the
moment I last plugged the wire to get the link up. The link on
the switch goes up at the same time as the message appears.

It makes no difference whether I use S2R or S2D.

It's not dramatical, but I suspect it's a bug in the suspend/
resume code which maybe does not reinitialize a hardware timer,
though I have no idea where to look for.

Anyway, the most important is that it does not freeze anymore !

Thanks,
Willy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/