On Mon, 17 Oct 2011 22:08:47 -0700 John Jason Jordan <[email protected]> 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 _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
