Hi Oliver,
On Tue, Jan 30, 2018 at 08:45:17AM +0100, Oliver Neukum wrote:
> Am Montag, den 29.01.2018, 19:21 +0100 schrieb Markus Demleitner:
> >
> > Any guess what might be behind this?
> >
> have you checked the persist attribute between the versions working
> well and working badly?
Persist is 1 in both cases. But persist was a good point anyway --
there's *probably* little point having an LTE card persist (I don't
think it could keep registered with the mobile network on 5..25 mW),
and so I tried
echo 0 > /sys/bus/usb/devices/1-4/power/persist
before suspending. Doing this three times before a suspend, the box
came back three out of three with 4.15.0. Suspending without the
intervening write immediately brought back the 10 s timeout. Then
again two fast resumes with an echo before it. And another one.
So -- I think I have a good workaround for me[1].
I'll try to get myself to git-bisecting the problem, because I see
it'd be better if we could figure out why persist hasn't been a
problem before 4.13.0 and has been causing the long resume delay from
then on. I'm not making actual promises, though (I'm a bit scared of
checkout sizes, build times, and lots of reboots; log(n) still rises
fairly steeply for low n...)
Thanks for providing the useful hint,
Markus
[1] For anyone who ended up here looking for a solution: I dumped
#!/bin/sh
case "$1" in
suspend|hibernate)
echo 0 > /sys/bus/usb/devices/1-4/power/persist
;;
esac
exit 0
into a file
/etc/pm/sleep.d/05sierra
(works with pm-utils, probably not with systemd)
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
