Only somewhat related.. but not too far off.
When the USB MIDI driver was released, there were some reports of it failing, then working again, then failing. It was all quite curious.
I later found out that some other programs were causing the USB stack to stall, which obviously took the USB MIDI driver out too. As soon as the stall was corrected, the driver would automount the devices again.
I "solved" the problem by adding a requester whenever the USB driver would stall. This gave the end user a chance to understand what/why was causing the real problem. But only after experiencing it myself did I realize that I needed a timed requester, because if the USB stack has stalled, so has the keyboard and mouse...
Wow, that was a long story with a really boring ending. I'll have to work on that.
Have USBCtrl to work without a GUI
Re: Have USBCtrl to work without a GUI
You solved the problem...best ending i could imagineLyleHaze wrote: Wow, that was a long story with a really boring ending. I'll have to work on that.
People are dying.
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
Re: Have USBCtrl to work without a GUI
I don't have USB mouse/keyboard dropout like I did on my SAM but I still have a problem with USBCtrl RESTART. If I have a USB Flash drive plugged into a USB port when I use a USBCtrl RESTART, all my i/o is frozen and I have to use the reset button. The clock still runs so it's just USB that freezes. If they are going to add an argument to avoid the requester (or add keyboard shortcuts for the requester gadgets) the freeze problem when a Flash drive is plugged in should be fixed too.Raziel wrote:You solved the problem...best ending i could imagine
Sadly, this is one of the many bugs I've reported that haven't been fixed. I really expected that FE would fix most of the u6 bugs I reported but instead we have new features that have apparently added more bugs (judging by the reports here in these forums).
AmigaOne X1000 with 2GB memory - OS4.1 FE
Re: Have USBCtrl to work without a GUI
Well, thanks everybody for the input (no pun intended ).
Anyway, some Amigan bloke and X1000 owner that does not experience this kind of USB issue (but nevertheless felt a strong sense of solidarity) wrote a little C program that calls "USBCtrl Restart Force" and shuts down the GUI dialog without the need of a keyboard or mouse (using a system-friendly API call).
I did some tests, and guess what, no more USB freeze on boot.
Phase 1/ With this little program (invoked from the user-startup) : I did a series of 12 "reboot fast" and/or hard reboot, the keyboard & mouse are always there.
Phase 2/ Without this program : got a first USB Freeze after the 3rd reboot, then another USB Freeze after 2 more reboots (the average occurence of this issue is every ~5 boots).
Phase 3/ With this little program reinstated (just to be sure I wasn't dreaming) : not the single USB Freeze, even after a series of 30 reboots (reboot fast, hardware reboot and power off/on).
I know this is an horrible workaround from a system standpoint, but it works here (and I know for sure I'm not the only Sam owner that struggles with the USB devices on a frequent basis).
This little tool should be made available in a couple of days.
Anyway, some Amigan bloke and X1000 owner that does not experience this kind of USB issue (but nevertheless felt a strong sense of solidarity) wrote a little C program that calls "USBCtrl Restart Force" and shuts down the GUI dialog without the need of a keyboard or mouse (using a system-friendly API call).
I did some tests, and guess what, no more USB freeze on boot.
Phase 1/ With this little program (invoked from the user-startup) : I did a series of 12 "reboot fast" and/or hard reboot, the keyboard & mouse are always there.
Phase 2/ Without this program : got a first USB Freeze after the 3rd reboot, then another USB Freeze after 2 more reboots (the average occurence of this issue is every ~5 boots).
Phase 3/ With this little program reinstated (just to be sure I wasn't dreaming) : not the single USB Freeze, even after a series of 30 reboots (reboot fast, hardware reboot and power off/on).
I know this is an horrible workaround from a system standpoint, but it works here (and I know for sure I'm not the only Sam owner that struggles with the USB devices on a frequent basis).
This little tool should be made available in a couple of days.
Sam460|AOS4.1FE|fra.planet-d.net|www.emucamp.com
Re: Have USBCtrl to work without a GUI
"This little tool should be made available in a couple of days."
USBRecycle available on OS4Depot :
http://www.os4depot.net/index.php?funct ... ecycle.lha
I agree, it's a ugly workaround !
USBRecycle available on OS4Depot :
http://www.os4depot.net/index.php?funct ... ecycle.lha
I agree, it's a ugly workaround !
http://apps.amistore.net/zTools
X1000 - AmigaOS 4.1.6 / 4.1 FE
X1000 - AmigaOS 4.1.6 / 4.1 FE
Re: Have USBCtrl to work without a GUI
@astrofra:
Have you ever tried to move the "USBCtrl START" command just before the LoadWB command in the startup-sequence? Just a thought.
Have you ever tried to move the "USBCtrl START" command just before the LoadWB command in the startup-sequence? Just a thought.
Re: Have USBCtrl to work without a GUI
To me, all this reads like a problem I thought of some time before...
I believed that it is hid.usbfd, which is causing the problems. After reading this thread, I´m convinced of my presumption.
I have problems with my keyboard from time to time, too (I´m using a SAM440ep). Interestingly, the mouse is always alive, although the keyboard is dead then. Even more interstingly, the mouse is plugged into a hub integrated in the keyboard and works on every boot, even if the keyboard is dead.
The difference to your cases is, that the mouse is not driven by hid.usbfd nor by bootmouse.usbfd, it uses the XeroMouse driver.
In the meantime I replaced my keyboard (Logitech G11) by a Lenovo Business Enhanced keyboard. The keyboard freezes are fewer than they were for the G11, but the freezes still occur. But still my mouse is always alive after reboot.
I believed that it is hid.usbfd, which is causing the problems. After reading this thread, I´m convinced of my presumption.
I have problems with my keyboard from time to time, too (I´m using a SAM440ep). Interestingly, the mouse is always alive, although the keyboard is dead then. Even more interstingly, the mouse is plugged into a hub integrated in the keyboard and works on every boot, even if the keyboard is dead.
The difference to your cases is, that the mouse is not driven by hid.usbfd nor by bootmouse.usbfd, it uses the XeroMouse driver.
In the meantime I replaced my keyboard (Logitech G11) by a Lenovo Business Enhanced keyboard. The keyboard freezes are fewer than they were for the G11, but the freezes still occur. But still my mouse is always alive after reboot.