4:33 a.m.
This is possibly a hardware issue rather than a Fedora problem, but I
thought I'd bring it up anyway:
I have a Bluetooth mouse connected via a BT dongle. The dongle normally
sits on the back of my cpu case on the floor beneath my desk, but I've
noticed this often produces lag in mouse movement, presumably caused by
interference from the desk's metal frame (BTW it took me months to
figure this out). I bought a USB extension cable (cheap Amazon Basics
model) and now have the dongle sitting above the desk and the lag
problems have gone.
So far so good. However now when I suspend the system and try to
restart it, nothing will happen until I physically remove the dongle
from the extension cable. The screen will then come back to life and I
can plug the dongle in again to get the mouse working. This never
happened when the dongle was directly connected to the cpu.
Do I need to get a better cable? If not, what can I do?
poc
5:03 a.m.
On Fri, 2016-04-01 at 10:33 +0100, Patrick O'Callaghan wrote:
Do I need to get a better cable? If not, what can I do?
If it used to work without plugging and unplugging, on the same port,
I'd suspect the cable.
--
tim@localhost ~]$ uname -rsvp
Linux 3.19.8-100.fc20.i686 #1 SMP Tue May 12 17:42:35 UTC 2015 i686
All mail to my mailbox is automatically deleted, there is no point trying
to privately email me, I will only read messages posted to the public lists.
George Orwell's '1984' was supposed to be a warning against tyranny, not
a set of instructions for supposedly democratic governments.
10:41 a.m.
On Fri, Apr 1, 2016 at 3:33 AM, Patrick O'Callaghan <pocallaghan(a)gmail.com>
wrote:
when I suspend the system and try to
restart it, nothing will happen until I physically remove the dongle
from the extension cable. The screen will then come back to life
At what point is the boot process when the screen comes back to life? Has
the system actually booted or does the grub2 screen come up when you remove
the dongle? If the latter, the system is probably trying to boot from USB.
I have had that problem when having certain USB devices plugged in. If you
don't ever need to boot from a USB device, you might be able to disable
that in BIOS/UEFI.
--Greg
11:01 a.m.
On Fri, 2016-04-01 at 09:41 -0600, Greg Woods wrote:
On Fri, Apr 1, 2016 at 3:33 AM, Patrick O'Callaghan
<pocallaghan@gmai
l.com>
wrote:
>
> when I suspend the system and try to
> restart it, nothing will happen until I physically remove the
> dongle
> from the extension cable. The screen will then come back to life
>
At what point is the boot process when the screen comes back to life?
Has
the system actually booted or does the grub2 screen come up when you
remove
the dongle? If the latter, the system is probably trying to boot from
USB.
I have had that problem when having certain USB devices plugged in.
If you
don't ever need to boot from a USB device, you might be able to
disable
that in BIOS/UEFI.
Perhaps I wasn't clear. This has nothing to do with booting. I'm
running an active session when I suspend it. System freezes, screen
goes off, cpu goes into minimum power state (with one light blinking on
the box). Note that at this stage the dongle still has a steady blue
light. On hitting the power button on the cpu box, everything should
wake up with the monitor showing the lock screen, and this is what
happens when I'm not using the extension cable. With the cable, I have
to remove the dongle (either before or after hitting the power button,
it doesn't matter) and only then will the screen come back (also the
keyboard, i.e. I can type my password to get past the lock screen even
before reinserting the dongle).
poc
11:09 a.m.
On Fri, Apr 1, 2016 at 10:01 AM, Patrick O'Callaghan <pocallaghan(a)gmail.com>
wrote:
Perhaps I wasn't clear.
I think you were, I just hadn't had my coffee yet :-)
I don't use suspend that much on my desktops, I normally just hibernate, in
which case it does go through the booting process when resuming, and if I
leave my flash drive plugged in, it hangs the boot.
Suspend gets used a lot more on the laptop, but there I don't normally have
external USB devices plugged in.
I have played around with suspend on the desktop, and I have encountered
similar problems with suspend/resume not working right when certain USB
devices are plugged in. I remember trying a number of different things I
found by Googling, but I never could get it to work reliably without
unplugging some of the devices before suspending. I think it involved udev
rules, /etc/systemd/system scripts, and so forth, but nothing really worked.
So I will be interested to hear if you find an answer for this.
--Greg
11:27 a.m.
On 04/01/2016 10:09 AM, Greg Woods wrote:
On Fri, Apr 1, 2016 at 10:01 AM, Patrick O'Callaghan
<pocallaghan(a)gmail.com <mailto:pocallaghan@gmail.com>> wrote:
Perhaps I wasn't clear.
I think you were, I just hadn't had my coffee yet :-)
I don't use suspend that much on my desktops, I normally just
hibernate, in which case it does go through the booting process when
resuming, and if I leave my flash drive plugged in, it hangs the boot.
Suspend gets used a lot more on the laptop, but there I don't normally
have external USB devices plugged in.
I have played around with suspend on the desktop, and I have
encountered similar problems with suspend/resume not working right
when certain USB devices are plugged in. I remember trying a number of
different things I found by Googling, but I never could get it to work
reliably without unplugging some of the devices before suspending. I
think it involved udev rules, /etc/systemd/system scripts, and so
forth, but nothing really worked.
So I will be interested to hear if you find an answer for this.
--Greg
I have had the same problem. So, what I do is unmount the plugin, remove
it, and then hibernate.
11:56 a.m.
On Fri, 2016-04-01 at 10:09 -0600, Greg Woods wrote:
On Fri, Apr 1, 2016 at 10:01 AM, Patrick O'Callaghan
<pocallaghan@gma
il.com>
wrote:
>
> Perhaps I wasn't clear.
I think you were, I just hadn't had my coffee yet :-)
I don't use suspend that much on my desktops, I normally just
hibernate, in
which case it does go through the booting process when resuming, and
if I
leave my flash drive plugged in, it hangs the boot.
Suspend gets used a lot more on the laptop, but there I don't
normally have
external USB devices plugged in.
I have played around with suspend on the desktop, and I have
encountered
similar problems with suspend/resume not working right when certain
USB
devices are plugged in. I remember trying a number of different
things I
found by Googling, but I never could get it to work reliably without
unplugging some of the devices before suspending. I think it
involved udev
rules, /etc/systemd/system scripts, and so forth, but nothing really
worked.
So I will be interested to hear if you find an answer for this.
Again, it all works when the dongle is plugged in directly. The problem
is when I'm using an extension cable, which one naively thinks should
be exactly the same, but in this case isn't. I doubt that udev etc. has
anything to do with it but of course I'm open to being corrected.
poc
12:22 p.m.
On Fri, 2016-04-01 at 10:09 -0600, Greg Woods wrote:
On Fri, Apr 1, 2016 at 10:01 AM, Patrick O'Callaghan
<pocallaghan@gma
il.com>
wrote:
> Perhaps I wasn't clear.
I think you were, I just hadn't had my coffee yet :-)
I don't use suspend that much on my desktops, I normally just
hibernate, in
which case it does go through the booting process when resuming, and
if I
leave my flash drive plugged in, it hangs the boot.
I've tried hibernate in the past but frankly don't see the point.
Restarting just gets me a full system reboot, as if I'd done a
shutdown. This isn't what I would expect, but maybe I'm not doing it
right ...
poc
12:23 p.m.
On 04/01/2016 09:59 AM, Patrick O'Callaghan wrote:
On Fri, 2016-04-01 at 10:27 -0600, jd1008 wrote:
> I have had the same problem. So, what I do is unmount the plugin,
> remove it, and then hibernate.
Not really feasible when the device is used by the mouse, and in any
case it wouldn't gain anything over what I'm doing now.
I think this has to do with the driver binding. I saw a script in one
of the ubuntu fora that looked like it might to the trick. The link is
http://askubuntu.com/a/549571
In a nutshell, he created a script that would be executed entering and
exiting sleep that would unbind the ehci or uhci module on sleep, and
rebind it on wake. He put the script in
/etc/pm/sleep.d/20_usb_suspend_fix
and here is the content:
---------------- CUT HERE ---------------------------------------
#!/bin/sh
LOGTAG=PwrUsbFix
UNDO=/var/run/pm-utils/pm-suspend/storage/rebind_usb.sh
# check am root
[ "$(id -u)" = 0 ] || {
echo "$LOGTAG : must be run as root!"
exit 1
}
case "${1}" in
hibernate|suspend)
: > ${UNDO}
find /sys/bus/pci/drivers -maxdepth 2 -path \*\[eu\]hci\* -name
unbind | cut -d\/ -f -6 | \
while read BUS ; do
find ${BUS} -maxdepth 1 -type l -name 00\* | \
while read DEVPATH ; do
DEVICE=`basename $DEVPATH`
echo "$LOGTAG : echo ${DEVICE} > ${BUS}/unbind"
echo -n "${DEVICE}" > ${BUS}/unbind
echo "echo \"${LOGTAG} ${DEVICE} >
${BUS}/bind\"" >> ${UNDO}
echo "echo -n \"${DEVICE}\" > ${BUS}/bind"
>>
${UNDO}
done
done
;;
resume|thaw)
. ${UNDO}
;;
esac
exit 0
---------------- CUT HERE ---------------------------------------
For Fedora use, I'd change the location defined in "UNDO" as that
directory isn't present on Fedora. I'd suggest something like:
UNDO=/usr/local/bin/rebind_usb.sh
I have NOT tested this but it might be something worth trying.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital ricks(a)alldigital.com -
- AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 -
- -
- The gene pool could use a little chlorine. -
----------------------------------------------------------------------
1:32 p.m.
On Fri, 2016-04-01 at 10:23 -0700, Rick Stevens wrote:
On 04/01/2016 09:59 AM, Patrick O'Callaghan wrote:
>
>
> On Fri, 2016-04-01 at 10:27 -0600, jd1008 wrote:
> >
> >
> > I have had the same problem. So, what I do is unmount the plugin,
> > remove it, and then hibernate.
> Not really feasible when the device is used by the mouse, and in
> any
> case it wouldn't gain anything over what I'm doing now.
I think this has to do with the driver binding. I saw a script in one
of the ubuntu fora that looked like it might to the trick. The link
is
http://askubuntu.com/a/549571
In a nutshell, he created a script that would be executed entering
and
exiting sleep that would unbind the ehci or uhci module on sleep, and
rebind it on wake. He put the script in
/etc/pm/sleep.d/20_usb_suspend_fix
and here is the content:
[...]Suspend
Thanks. I haven't tried it yet but it gave me some food for thought,
and the plot now thickens. It turns out that when I run "sudo pm-
suspend" from the command line, the issue does *not* arise, i.e. the BT
mouse is restored even when using the extension cable. What I've been
doing up to now (and didn't think to mention) is to use the Suspend
menu option from KDE, but that appears to be different.
I think I need to post a question on the KDE list.
poc
1:35 p.m.
On Fri, 2016-04-01 at 10:23 -0700, Rick Stevens wrote:
On 04/01/2016 09:59 AM, Patrick O'Callaghan wrote:
>
>
> On Fri, 2016-04-01 at 10:27 -0600, jd1008 wrote:
> >
> >
> > I have had the same problem. So, what I do is unmount the plugin,
> > remove it, and then hibernate.
> Not really feasible when the device is used by the mouse, and in
> any
> case it wouldn't gain anything over what I'm doing now.
I think this has to do with the driver binding. I saw a script in one
of the ubuntu fora that looked like it might to the trick. The link
is
http://askubuntu.com/a/549571
In a nutshell, he created a script that would be executed entering
and
exiting sleep that would unbind the ehci or uhci module on sleep, and
rebind it on wake. He put the script in
/etc/pm/sleep.d/20_usb_suspend_fix
and here is the content:
[...]Suspend
Thanks. I haven't tried it yet but it gave me some food for thought,
and the plot now thickens. It turns out that when I run "sudo pm-
suspend" from the command line, the issue does *not* arise, i.e. the BT
mouse is restored even when using the extension cable. What I've been
doing up to now (and didn't think to mention) is to use the Suspend
menu option from KDE, but that appears to be different.
I think I need to post a question on the KDE list.
poc
5:08 a.m.
On Fri, 2016-04-01 at 19:35 +0100, Patrick O'Callaghan wrote:
Thanks. I haven't tried it yet but it gave me some food for
thought,
and the plot now thickens. It turns out that when I run "sudo pm-
suspend" from the command line, the issue does *not* arise, i.e. the
BT
mouse is restored even when using the extension cable. What I've been
doing up to now (and didn't think to mention) is to use the Suspend
menu option from KDE, but that appears to be different.
I think I need to post a question on the KDE list.
It turns out that the KDE Suspend menu action invokes systemd-
suspend.service and that the pm-* utilities are no longer installed by
default. This would account for the different behaviour.
I still don't understand why using the extension cable makes a
difference.
poc
10:40 a.m.
On Sat, 2016-04-02 at 11:08 +0100, Patrick O'Callaghan wrote:
I still don't understand why using the extension cable makes a
difference.
I wonder if your motherboard only supplies low current to the USB ports
when in off/suspend modes, and that upsets the dongle. What happens
with a shutdown, mains power disconnect, wait a while, then boot?
Though I wouldn't expect a small dongle to use a lot of power, it may be
at the tipping point where a longer cable introduces a significant
supply voltage drop. Some USB cables only have very thin wires in them.
--
tim@localhost ~]$ uname -rsvp
Linux 3.19.8-100.fc20.i686 #1 SMP Tue May 12 17:42:35 UTC 2015 i686
All mail to my mailbox is automatically deleted, there is no point trying
to privately email me, I will only read messages posted to the public lists.
George Orwell's '1984' was supposed to be a warning against tyranny, not
a set of instructions for supposedly democratic governments.
4:20 a.m.
[snip]
I still don't understand why using the extension cable makes a
difference.
poc
--[snip]
If I were to take a guess...
Being serial data, vs. parallel, the port/devices only needs two
connections i.e. |..| to pass data and cables will tend to provide only
this. If the device requires the second pair i.e. |||| used typically for
power and such, to reactivate then the extension cable, if missing these
inner two wires, would not pass any charge and/or data. The device then
does not know to reactivate.
look on the inside of the ends of the extension cable and see if you can
see four contact leads and this should tell if you have all four or just
two contact leads for data only function.
Just a wag.
--
Fred
2:42 p.m.
On Mon, 2016-04-04 at 05:20 -0400, fred roller wrote:
>
>
> [snip]
>
> I still don't understand why using the extension cable makes a
> difference.
>
> poc
> --[snip]
>
If I were to take a guess...
Being serial data, vs. parallel, the port/devices only needs two
connections i.e. |..| to pass data and cables will tend to provide
only
this. If the device requires the second pair i.e. |||| used
typically for
power and such, to reactivate then the extension cable, if missing
these
inner two wires, would not pass any charge and/or data. The device
then
does not know to reactivate.
look on the inside of the ends of the extension cable and see if you
can
see four contact leads and this should tell if you have all four or
just
two contact leads for data only function.
The extension cable has four contacts. If it didn't, the dongle simply
wouldn't work at all.
poc
3:31 a.m.
On Fri, 2016-04-01 at 18:22 +0100, Patrick O'Callaghan wrote:
On Fri, 2016-04-01 at 10:09 -0600, Greg Woods wrote:
>
> On Fri, Apr 1, 2016 at 10:01 AM, Patrick O'Callaghan <pocallaghan@g
> ma
> il.com>
> wrote:
>
> >
> > Perhaps I wasn't clear.
>
> I think you were, I just hadn't had my coffee yet :-)
>
> I don't use suspend that much on my desktops, I normally just
> hibernate, in
> which case it does go through the booting process when resuming,
> and
> if I
> leave my flash drive plugged in, it hangs the boot.
I've tried hibernate in the past but frankly don't see the point.
Restarting just gets me a full system reboot, as if I'd done a
shutdown. This isn't what I would expect, but maybe I'm not doing it
right ...
In fact I wasn't doing it right, because it turns out you need to set
up a grub.conf line for this to work. This isn't clear from the man
pages on hibernate/suspend and isn't set up by default in Fedora, but
is not that hard to do. Those interested can Google it.
Having done that, hibernate/restore now works correctly, including the
BT dongle on the extension cable. Why it doesn't work with suspend must
remain a mystery but I no longer care enough to investigate it as it's
almost certainly hardware-related.
poc
2941
days inactive
2945
days old
16 comments
6 participants
participants (6)
-
fred roller -
Greg Woods -
JD -
Patrick O'Callaghan -
Rick Stevens -
Tim