On Fri, 30 Sep 2011 09:52:53 +0200, "crsnet.pl" <crsnet_at_crsnet.pl> wrote: > On Wed, 28 Sep 2011 19:57:56 +0900, Taku YAMAMOTO > <taku_at_tackymt.homeip.net> wrote: >> On Tue, 27 Sep 2011 13:06:21 +0100 >> Gavin Atkinson <gavin.atkinson_at_ury.york.ac.uk> wrote: >> >>> On Tue, 2011-09-27 at 19:53 +0800, Adrian Chadd wrote: >>> > Hans, >>> > >>> > Why haven't those patches been committed? >>> >>> This patch is an absolute hack, and shouldn't be committed as it >>> is. >>> >>> I would, however, appreciate some help in determining the correct >>> solution. The solution may well involve not suspending/resuming >>> hpet(4) >>> or the other timers on the normal DEVICE_SUSPEND()/DEVICE_RESUME() >>> path >>> but instead doing them as the last thing to be suspended, or it may >> >> Like the attached patches do? >> >>> instead involve reworking the USB code (and potentially other code) >>> to >>> not need to sleep during suspend/resume. I don't know the right >>> solution, but would really like to work with somebody who does. >>> >>> Please also see the thread "Choosing between DELAY(useconds) and >>> pause()" on -current. >>> >>> Gavin Hello. After longer testing thouse patches. I must say, they dont resolve my problem in 100%. Suspend/Resume on short time (about 2-3 hours, meybye little longer) works fine. But when i suspend it for longer (8-10 hours) system freeze after resume. Any another idea why ? Best regards, Adrian.Received on Fri Sep 30 2011 - 18:00:33 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:18 UTC