[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.00.1005071028320.9849@pobox.suse.cz>
Date: Fri, 7 May 2010 10:29:25 +0200 (CEST)
From: Jiri Kosina <jkosina@...e.cz>
To: Alan Stern <stern@...land.harvard.edu>
Cc: Bruno Prémont <bonbons@...ux-vserver.org>,
Oliver Neukum <oneukum@...e.de>,
linux-pm@...ts.linux-foundation.org,
list <linux-usb@...r.kernel.org>,
Kernel development list <linux-kernel@...r.kernel.org>,
jslaby@...e.cz
Subject: Re: [linux-pm] s2ram slow (radeon) / failing (usb)
On Thu, 6 May 2010, Alan Stern wrote:
> On Thu, 6 May 2010, Bruno [UTF-8] Prémont wrote:
>
> > > Bruno, can you confirm that the hang occurs during one of those
> > > cancel_work_sync() calls?
> >
> > No, it's not one of the cancel_work_sync() that hangs but it's the
> > del_timer_sync() right before them that hangs!
> > (del_timer_sync() also hangs if I put it last, so the cancel_work_sync()
> > don't hang anything)
> >
> > static void hid_cancel_delayed_stuff(struct usbhid_device *usbhid)
> > {
> > del_timer_sync(&usbhid->io_retry); /* this one never returns */
> > cancel_work_sync(&usbhid->restart_work);
> > cancel_work_sync(&usbhid->reset_work);
> > }
>
> Okay, I see what the problem is. In usbhid_start() there's a bunch of
> statements initializing parts of the usbhid structure. When probing
> fails those statements don't get executed, so the timer and workqueue
> things aren't set up properly.
>
> This patch should fix it.
Indeed, good catch, thanks a lot Alan!
Could you please send to me with your Signed-off-by: line and short
changelog, so that I could apply it with proper credit being given to you?
And Bruno, thanks a lot for excellent testing efforts.
--
Jiri Kosina
SUSE Labs, Novell Inc.
--
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/
Powered by blists - more mailing lists