Abort on data transfer when using KVM

My KVM used to show the same problem: First time switching gave an “abort on data transfer” and after that everything was OK and it didn’t repeat itself after subsequent switching. My KVM is a ridiculously expensive thing (I wanted a dual head KVM switch and this was the only one I found back in 2012) called “ATEN MasterView CS1644A 4P DVI Dual Head” (see here ).

However it’s been in a drawer since october last year as I’ve moved house and although the house is bigger the office is smaller and I don’t think I’ll manage to have both the laptop-in-docking-station and the KVM on the desk. A bit problematic with the Titanium under it as well I suppose. I should try one of these days.

Once XHCIDriver has crashed, the KVM switched devices are useless and I need to plug in the separate ones.

Having removed the separate keyboard and mouse from my desk in anticipation, and being more than a little reluctant to put them back, I did a bit more digging. I’ve not found a fix, but have muddied the waters a bit more.

I wondered if plugging the KVM in via a hub on top of the desk might be an option, so that it could be connected after the KVM was switched to the Titanium’s output and removed before switching away. Not convenient, but worth it for the space regained. Sadly, no — the machine boots OK with the KVM plugged in and switched to that output, but switch away and back, and XHCIDriver crashes. Unplugging and replugging into the hub makes no difference. The KVM will only work once after the Titanium has booted, and then requires a reboot to work again.

No matter, I thought. I could live with only plugging in the second keyboard and mouse when I have the Titanium in use, and with a hub now on the desk top that would be a lot easier. Except that the keyboard and mouse which work fine when plugged direct into the motherboard sockets don’t work when plugged into the same sockets via a hub. That’s not “don’t work at boot up”; it’s “don’t work at any point, even if they’re plugged in well after the system is at the desktop”.

Meanwhile the Beagleboard on the other side of the desk doesn’t care if the keyboard and mouse are switched through the KVM. Is XHCIDriver still being worked on, or is this as good as it’s ever going to get?

Sadly, no — the machine boots OK with the KVM plugged in and switched to that output, but switch away and back, and XHCIDriver crashes. Unplugging and replugging into the hub makes no difference. The KVM will only work once after the Titanium has booted, and then requires a reboot to work again.

That is exactly my experience with the KVM I use.

Added in edit: It actually will work if the Titanium is booted with the KVM switched to another machine, and then switched to it, but switch away and back and the crash occurs. As I said previously, the KVM works fine with four other RISC OS hardware (ARMX6, IGEPv5, RaPi, ArmBook) and of course a Windows laptop. Such is life.