[PLUG] Bluetooth mouse dies after kernel upgrade

[Dale Snell]

On Mon, 17 Oct 2011 22:08:47 -0700
John Jason Jordan <johnxj at comcast.net> wrote:

> Except for a period about a year ago (resolved) it always worked
> perfectly, but after upgrading my Fedora 14 x86_64 computer to
> 2.6.35.14-97.fc14.x86_64 a week ago it dies periodically. To
> get it started again I have to (using the GUI) right-click on
> the mouse (Logitech Travel Mouse), select Input Service, and
> let it find the mouse again. Before doing so I have to put the
> mouse into locatable mode by pressing the button on the bottom.
> 
> Something is turning off the mouse after an apparently random
> period of inactivity. It does not die as long as I am using it.
> I say the period of inactivity is random; it may be a fixed
> time, but it is difficult to test to determine if that is the
> case. All I know for sure is that my screensaver is set to 30
> minutes of inactivity and the mouse is always dead after
> restoring from the screensaver (have to use the Esc key to
> restore). I suspect the mouse dies long before the screensaver
> kicks in.
> 
> The only other clue I have found is the following from
> Xorg.0.log, which appeared right after the last time I had to
> restart the Input Service:

(snip!)

I think all the X log file is telling you is that it's seen that
the mouse was connected, and X has recognized it.  A better
source of information would be dmesg or the system log.  Those
would be /var/log/dmesg and /var/log/messages, respectively.
You'll be wanting to look at the end of those files.
(/var/log/messages belongs to root, so you'll need to su to root,
or do a "sudo tail ..." to read it.  These are the files that
should give you a clue as to what's going on.

You say this started after last week's upgrade, have you tried
booting to a prior kernel?  If you've left your system stock, the
previous two kernels are still installed, all you have to do is
select one from the grub boot menu.

Another possibility is that your Bluetooth configuration has been
changed.  If you boot with a prior kernel and the problem
persists, that's probably where I'd start looking.  Or perhaps the
udev rules that govern these things.  Unfortunately, I don't have
anything Bluetooth, so I can't do any testing.  (And udev rules
are a black art.)  Did any of the Bluetooth programs get updated?
You can compare the current config files with your backups (you
_do_ make backups, don't you?), and restore the old one if
necessary.  It shouldn't be necessary; when a config file has to
be changed, it's given an ".rpmnew" extension, so you can make
sure any changes you've made are merged in.  You might scan
through /etc/* to see if there are any "tagged" files.

Hurrr...  I just checked with RedHat's Bugzilla for Bluez bugs,
and there's one that matches your problem exactly, except that the
author is running F15, with blues-4.87.  Since you're running F14,
I'm not sure that this isn't just a coincidence; still, it seems
odd.  <https://bugzilla.redhat.com/show_bug.cgi?id=716479>

I hope this helps.  (I'm going to sleep.  *yawn!*)

--Dale

--
A sad spectacle.  If they be inhabited, what a scope for misery and folly.
If they be not inhabited, what a waste of space.
		-- Thomas Carlyle, looking at the stars