On 7/19/23 8:53 AM, Rob H wrote:
> On 18/07/2023 15:20, Rob H wrote:
>> On 18/07/2023 12:57, Rob H wrote:
>>> On 18/07/2023 10:09, Paul wrote:
>>>> On 7/18/2023 3:07 AM, Rob H wrote:
>>>>> On 18/07/2023 03:48, Paul wrote:
>>>>>> On 7/17/2023 5:26 PM, Rob H wrote:
>>>>>>> On 17/07/2023 22:17, Big Al wrote:
>>>>>>>> On 7/17/23 14:02, this is what Rob H wrote:
>>>>>>>>> On 16/07/2023 23:07, Rob H wrote:
>>>>>>>>>> On 16/07/2023 21:04, Nic wrote:
>>>>>>>>>>> On 7/16/23 3:51 PM, Rob H wrote:
>>>>>>>>>>>> On 16/07/2023 20:48, Nic wrote:
>>>>>>>>>>>>> On 7/16/23 3:41 PM, Rob H wrote:
>>>>>>>>>>>>>> On 16/07/2023 20:26, Nic wrote:
>>>>>>>>>>>>>>> On 7/16/23 7:24 AM, Rob H wrote:
>>>>>>>>>>>>>>>> These last few weeks I have found that every now and
>>>>>>>>>>>>>>>> again, becoming more frequent now, my Mint system seems
>>>>>>>>>>>>>>>> to freeze, or at least my wired mouse does.
>>>>>>>>>>>>>>>> Sometimes if I leave it for a an hour or so,the mouse
>>>>>>>>>>>>>>>> becomes usable again, but this is not always
>>>>>>>>>>>>>>>> convenient, and I have to hard reboot the system.
>>>>>>>>>>>>>>>> If it helps , the mouse is a Kensigton wired mouse. I
>>>>>>>>>>>>>>>> have tried unplugging and plugging back in, and also
>>>>>>>>>>>>>>>> using a different usb port, but neither made any
>>>>>>>>>>>>>>>> difference.
>>>>>>>>>>>>>>>> I've had this same mouse for a long time now, maybe 7/8
>>>>>>>>>>>>>>>> years, and would it be time to get a new one, if it
>>>>>>>>>>>>>>>> would make any difference.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> thanks
>>>>>>>>>>>>>>> Is there some system log file that might say what is
>>>>>>>>>>>>>>> occurring? Do a search for the the most recent .log file
>>>>>>>>>>>>>>> after the hard reboot.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This is all I could find in the hardware section of logs:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> time: 12:05:17
>>>>>>>>>>>>>> Message: hid-generic 0003:1BCF:08A0.0001:
>>>>>>>>>>>>>> input,hiddev0,hidraw0: USB HID    v1.10 Mouse [HID
>>>>>>>>>>>>>> 1bcf:08a0] on usb-0000:00:14.0-5/input0
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Kernel Device: +hid:0003:1BCF:08A0.0001
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Priority: 6
>>>>>>>>>>>>> It looks like it is going to sleep. I thought you said you
>>>>>>>>>>>>> were using a wired mouse, this message has to do with a
>>>>>>>>>>>>> usb device.
>>>>>>>>>>>>
>>>>>>>>>>>> I am using a wired mouse which is plugged into a USB port
>>>>>>>>>>>> on the motherboard of my desktop machine
>>>>>>>>>>> So the message suggests to me the mouse is hibernating.
>>>>>>>>>>
>>>>>>>>>> Well that is weird as I've never known that before, but why
>>>>>>>>>> would it.
>>>>>>>>>> Also, as I don't know how long I'd have to wait before it
>>>>>>>>>> does respond to movement, it becomes a bit inconvenient.
>>>>>>>>>
>>>>>>>>> Well the replacement mouse has also locked up, and the
>>>>>>>>> keyboard didn't work either, o it must be something else which
>>>>>>>>> i causing it to happen.
>>>>>>>>>
>>>>>>>>> Time:    18:56:37
>>>>>>>>> Message:hid-generic 0003:04F2:0939.0003: input,hidraw0: USB
>>>>>>>>> HID v1.11 Mouse [PixArt USB Optical Mouse] on
>>>>>>>>> usb-0000:00:14.0-6/input0
>>>>>>>>> kernel Device : +hid:0003:04F2:0939.0003
>>>>>>>>> Priority 6
>>>>>>>>>
>>>>>>>> Looks like the 's' key is intermittently not working too.
>>>>>>>
>>>>>>> Hardware etc information:
>>>>>>> rob@rob-Z97:~$ inxi -Fxxxrz
>>>>>>> System:
>>>>>>>     Kernel: 5.15.0-76-generic x86_64 bits: 64 compiler: gcc v:
>>>>>>> 11.3.0
>>>>>>>       Desktop: Cinnamon 5.6.8 tk: GTK 3.24.33 wm: muffin vt: 7
>>>>>>> dm: LightDM 1.30.0
>>>>>>>       Distro: Linux Mint 21.1 Vera base: Ubuntu 22.04 jammy
>>>>>>
>>>>>> If you have the boot menu set up, and you haven't been purging all
>>>>>> the old kernels, you can temporarily revert back to a previous
>>>>>> kernel and test your USB ports again.
>>>>>>
>>>>>>      [Picture]
>>>>>>
>>>>>> https://i.postimg.cc/Tw3nfFsh/select-an-old-kernel-and-retest.gif
>>>>>>
>>>>>>     Paul
>>>>>
>>>>> Thanks Paul.
>>>>> I can't help thinking that the problem is being caused by a
>>>>> latest? update , ie a later version kernel.
>>>>> I have installed installed kernel version 5.19.0-41 from Update
>>>>> Manager/Linux Kernels.
>>>>>
>>>>> I don't know, so I will ask, does that mean that the system will
>>>>> always boot or use the said kernel version, or do I have to do
>>>>> something else as well.
>>>>
>>>> When no menu is present during the boot sequence, it
>>>> should follow the default (single OS offering) line, and
>>>> not the Advanced Option items.
>>>>
>>>> If you set up the Menu, then if you respond in time, you can
>>>> take control. If you instead, relax and just let it boot,
>>>> it chooses the Default line.
>>>>
>>>> Setting up the Menu, is part of preparing for broken-ness.
>>>> And this is especially the case, if you are accelerating the
>>>> kernel choices and choosing whizzy ones.
>>>>
>>>> This is why I'm recommending this step, as you can "join us
>>>> poor folk" with our old-kernels and see if your USB device
>>>> works better. I've partaken of whizzy kernels before, without
>>>> too much impact except for DKMS stuff no longer working.
>>>> (When stuff is added via DKMS, there is a kernel range
>>>> set of numbers and if your new kernel is outside the
>>>> DKMS item defined range, then the DKMS item cannot be applied.
>>>> Maybe this would include an NVidia driver, VirtualBox Additions,
>>>> and so on.)
>>>>
>>>>     Paul
>>>
>>> Thanks, but how do I setup the menu as I've never used one before.
>>
>> I googled how to do and found I had to edit grub.cfg timout from 0 to 5
>> Then the boot menu appeared and in Advanced options the kernel
>> version which I installed earlier was at the top of the list and
>> booted from or to it.
>> If the system still locks up, then I will have to install an earlier
>> version kernel, but we'll see how it goes
>
> Well that didn't last very long before it locked up again.
> After my system was not used for 3 hours or so, I went to check emails
> and then it locked up again after less than 5 minutes.
> This resulted in yet another hard restart.
>
> I don't know what else to do now.
A point of curiosity for me, when the lock up happens, and your mouse /
keyboard are not available, can you tell if there are any running
process, such as a video that was playing? If the video is playing and
the audio is playing, this would force me to look at the hardware end
for the problem. Is it safe to assume that your keyboard is also plugged
into a usb port?