[Nut-upsuser] [POSSIBLE FRAUD] Re: [EXTERNAL] Re: Help with Tripp Lite Internet600U
Greg Oliver
oliver.greg at gmail.com
Sun May 24 05:08:07 BST 2020
On Fri, May 22, 2020 at 9:58 AM Larry Fahnoe <fahnoe at fahnoetech.com> wrote:
> The loss of communication to USB devices has been discussed before on this
> list.
>
It does not always help, but I frequently use:
usbcore.autosuspend=-1
on the kernel command line to keep devices from going to sleep on the USB
bus.
> I do not recall the particulars (& thus do not know if they're relevant to
> the situation at hand), but it seems to me that it was ultimately related
> to the USB libraries being used. Charles Lepple was instrumental in the
> thread I'm thinking of. Roger's suggestion of a more intelligent cron job
> sounds very beneficial for a short term work-around, but if it were my
> system I'd rather get the tools working properly which may involve research
> into the code and how it is built on the given platform. Sorry I don't have
> a more specific suggestion to offer!
>
> --Larry
>
> On Fri, May 22, 2020 at 8:08 AM Roger Price <roger at rogerprice.org> wrote:
>
>> On Fri, 22 May 2020, Tom Cooper wrote:
>>
>> > Sadly I am still seeing a loss of communication. I will check the
>> device number to see if it has changed.
>> > Not sure what else to look at. I guess I could create a corn job to
>> restart the driver multiple times a day.
>>
>> If there is a command such as upsc for which the output depends on the
>> driver
>> running correctly, then it might be better to run a cron job every three
>> minutes
>> checking that the driver is running, but only restarting when needed.
>>
>> Roger--
>>
>
> Larry Fahnoe, Fahnoe Technology Consulting, fahnoe at FahnoeTech.com
> Minneapolis, Minnesota www.FahnoeTech.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20200523/33f7109b/attachment.html>
More information about the Nut-upsuser
mailing list