RM1PE: Virtual Media freezes the target BIOS keyboard, drive never boots (same as #66265, logs attached)

Hi everyone, I'm new here.

I bought a Comet PoE (GL-RM1PE) so I could install operating systems on a lab machine remotely, which is what the "install OS remotely" tutorial describes. Video, keyboard and mouse all work beautifully and I've been really happy with the device. But I can't get the virtual drive to boot, and I've hit a wall.

I think I'm hitting the same bug as #66265. Same model. There, enabling Virtual Media with no ISO mounted killed HDMI output on a Dell OptiPlex 3000. Here it's an HP EliteDesk 705 G3 Mini and the symptom is different, the machine stops responding to the Comet's keyboard in BIOS, but the trigger is identical: simply having Virtual Media enabled, no image required. That thread was closed because the logs never got sent. I've attached mine, so hopefully this one can go further.

One thing up front, because I've seen it answered this way before: this doesn't look like "that BIOS can't be driven". This HP's BIOS takes the Comet's keyboard perfectly, I can open the Startup Menu and move around in it. It stops responding only when Virtual Media is on, and starts again the moment it's off, without a reboot.

Setup

  • Comet PoE (GL-RM1PE), firmware V1.10.1 release2

  • HP EliteDesk 705 G3 Mini, BIOS P26 Ver. 02.44, Secure Boot disabled, USB above the internal SSD in both boot orders, Fast Boot off

  • Single Type-C to the target, per the documentation

The test (screenshots attached)

One uninterrupted firmware session, parked at the HP Startup Menu, no reboot between steps. Only the Virtual Media function changed:

  1. Virtual Media off. Opened the Startup Menu by streaming Esc. Arrow Down works, the highlight moves.

  2. Virtual Media on (otg_functions?start_flash=1, image attached). Arrow Down and F9 now do nothing at all. Five consecutive screenshots are byte-identical to each other and to step 1.

  3. Virtual Media off again (otg_functions?start_flash=0), still with no reboot. The same Arrow Down works immediately, the highlight moves to "System Diagnostics".

There are only two screenshots below, and that is the point: the step 1 and step 2 screens are the same image file, byte for byte. The menu simply never changed while Virtual Media was on, so there was no second picture to take. The first screenshot is that unchanging screen, the second is the highlight finally moving once Virtual Media was switched off again.

The keyboard itself is never broken. In one failing boot I streamed ~1450 Esc presses through POST. The firmware ignored all of them, then every one appeared at once in the Linux console as ^[ the instant the OS took over.

In the Comet's own logs

From /api/upgrade/log (attached as comet-rm1pe-logs.zip, IPs and MACs redacted, happy to send the unredacted bundle privately), around the gadget restarts:


configfs-gadget.rockchip gadget.0: End Point Request ERROR: -108

configfs-gadget.rockchip gadget.0: End Point Request ERROR: -108

android_work: sent uevent USB_STATE=DISCONNECTED

dwc3 21500000.usb: device reset

android_work: sent uevent USB_STATE=CONNECTED

-108 is -ESHUTDOWN. There are also 198 occurrences of usb-gadget: usb-service is unavailable in the same log, which I don't know how to interpret but looks wrong.

Ruled out

  • Not the composite descriptor: a storage-only gadget (enable_keyboard=0, enable_mouse=0, enable_mouse_alt=0, start_flash=1) still didn't boot.

  • Not the image: start_flash=1 with no media connected breaks input identically.

  • Not CD-ROM vs USB disk, both behave the same.

  • Not target BIOS config, and raising Startup Delay 0 to 20 s changed nothing.

  • Not cabling: everything works on that cable whenever Virtual Media is off.

Once Linux is running, the target enumerates the device fine (Glinet Composite Device, usb-storage 2-3:1.3), so the gadget is well formed and only the pre-boot firmware rejects it. With Virtual Media on, POST also takes about 30 seconds longer, like an enumeration attempt timing out.

Question

In #62019 the fix was forcing the target to Full/Low Speed USB, because that BIOS wouldn't initialise GLKVM HID at High Speed. My HP has no USB speed setting. Can the Comet be made to advertise Full Speed instead of High Speed, by setting or API? If not, could it be added? Given #66265 and #62019 that looks like it would fix a class of machines rather than just mine.

Happy to run any test and send more logs, it's a lab machine so I can wipe it freely. Thanks for any pointers.

Logs
comet-rm1pe-logs.zip (38.9 KB)

Screens

Hi, thanks for the detailed information. Could you please try changing the Device Identity and see if that helps?

Thanks for troubleshooting with me!

I have now tried every Device Identity preset:
Logitech Unifying (046D:C526), Dell Multimedia Pro (413C:2011), Microsoft MultiMedia (045E:005F), Corsair Gaming RGB (6940:6973), and the web UI's GLKVM Default (1D6B:0104).

EDID stayed valid after each change. I ran the same A/B/A test at the parked HP Startup Menu for each one. The result is identical for all of them: the keyboard works with Virtual Media off, stops the moment start_flash is enabled, and works again when it's turned off. The one exception is 1D6B:0104: there the firmware keyboard didn't come back even with Virtual Media off, and the machine needed a power-button reset.

So the Device Identity doesn't seem to matter. As soon as the mass-storage function is present, this firmware stops reading input. Is there a way to make the gadget enumerate at Full Speed, or to bring up mass storage as a separate device instead of part of the composite?

Happy to test any build or setting.

Any further assistance would be highly appreciated.

Since my last message, I have tested the KVM on another HP computer (hp prodesk g7 i5 10500), with the exact same result, as soon as I attach virtual storage media, the keyboard/mouse is gone, which makes operation boot menu impossible.

I really need this to work for my workflow, for automated installation build testing.

Hi, please try this latest firmware and check if the issue has been resolved.

Thanks for the quick build! I flashed rm1pe_1.10.1_without_iad.img (signature check passed, upgrade completed, device rebooted into it) and re-ran the same tests. Unfortunately nothing changed on the HP EliteDesk 705 G3 (BIOS P26 Ver. 02.44), but I think I can now show where it fails.

What I tested

Same A/B/A as before, parked at the HP Startup Menu, no reboot between steps:

  • Virtual Media off: arrow keys work
  • start_flash on (no image needed): every key ignored
  • off again: arrow keys work immediately

start_cdrom behaves exactly the same.

Boot test with an image mounted as a flash drive:

  • USB first in the UEFI boot order, with a physical USB stick also plugged in: the BIOS booted the physical stick, so its USB storage stack still works. Once Linux was up, it listed the Comet's virtual drive as sdb.
  • Same again with the physical stick's boot entry disabled: the BIOS skipped the virtual drive and booted the internal SSD. The virtual drive never shows up as a boot option.

What the Comet's log shows

These are from the Comet's own dmesg (full log attached). Here are the three USB events from that session. Video lines are trimmed, timestamps are unchanged:

# 1. HP reboots into BIOS, Virtual Media OFF: configured normally
[  737.113472] dwc3 21500000.usb: device reset
[  737.114546] configfs-gadget.rockchip gadget.0: End Point Request ERROR: -108
[  743.845525] dwc3 21500000.usb: device reset
[  745.228087] dwc3 21500000.usb: device reset
[  745.543794] android_work: sent uevent USB_STATE=CONFIGURED

# 2. Virtual Media switched ON while in the Startup Menu
[  796.588340] configfs-gadget.rockchip gadget.0: End Point Request ERROR: -108
[  796.591555] android_work: sent uevent USB_STATE=DISCONNECTED
[  797.002185] dwc3 21500000.usb: device reset
[  797.312481] android_work: sent uevent USB_STATE=CONNECTED
               ... no CONFIGURED for the next 83 seconds (keyboard dead the whole time)

# 3. Virtual Media switched OFF again
[  880.611326] android_work: sent uevent USB_STATE=DISCONNECTED
[  880.970138] dwc3 21500000.usb: device reset
[  881.280768] android_work: sent uevent USB_STATE=CONNECTED
[  881.285153] android_work: sent uevent USB_STATE=CONFIGURED   <- 0.3 s later, keyboard works

So when the mass storage function is part of the gadget, the HP's BIOS resets the device but never sends SET_CONFIGURATION. The whole composite device stays unconfigured, and that's why the keyboard dies with it. Without mass storage it configures within a fraction of a second. Linux on the same machine configures the exact same gadget fine, so only the BIOS's USB stack gives up on it.

An idea, before I take more of your time

Since the BIOS seems to reject the descriptors themselves, I wonder whether this can be solved entirely in the kvmd layer, which is open source in gl-inet/glkvm. I'd do it together with an AI coding agent, which can drive the whole test loop on my lab machine unattended: change one gadget setting over SSH, park the HP in its Startup Menu, run the A/B/A, read the result. Reading kvmd/apps/otg/__init__.py, these are the things I'd try first, one at a time:

  1. bDeviceClass / SubClass / Protocol = 0xEF / 2 / 1. As far as I can tell add_camera() sets these on the whole gadget even when the camera is disabled. Is that what the without_iad build changes? I'd try 0 / 0 / 0.
  2. The os_desc link to configs/b.1, which is also created even with no NCM/RNDIS function.
  3. Mass storage with stall=1. kvmd sets stall=False, whereas the kernel default is on.
  4. Limiting the gadget to Full Speed via max_speed, which is the question from my first post.

If one of them works, I'd turn it into a proper option and open a PR. The SDK repo only covers the RM1 (kernel 4.19), not the RM1PE's rv1126b / kernel 6.1, so if the cause is in the kernel or UDC driver I can't go further on my own.

So my questions are:

  • Do you think that's worth an experiment, or is it a dead end for a reason I can't see from the outside?
  • Is there something better you'd suggest I try first, or a debug build or log setting that would show what the BIOS reads before it gives up?

Happy to flash more test builds too. It's a lab machine, so I can reboot it as often as needed.

Could you send us the syslog after reproducing the issue? Have you tried connecting it to another laptop to see if the issue persists?

Sure! I reproduced it again just now on the without_iad firmware and exported the logs straight after. Attached are syslog-logread.log (1010.9 KB)
The only changes I made are masking my LAN client IP and the CPU serial.

The machine was parked at the HP Startup Menu the whole time, with no image mounted and no reboot between steps. The toggles are my own API calls, so you can find them in the syslog by searching otg_functions:

  • Before 11:29: Virtual Media off, arrow keys work.
  • 11:29:26: POST /system/otg_functions?start_flash=1. Keys are ignored for the whole 84 s.
  • 11:30:50: POST /system/otg_functions?start_flash=0. Keys work again immediately.

The relevant lines:

11:29:24 kvmd: OTG functions changed, applying via kvmd-otgconf ...
11:29:25 kernel: [183828.616596] android_work: sent uevent USB_STATE=DISCONNECTED
11:29:26 kvmd: Current OTG functions from .../configs/b.1: ['hid.usb0', 'hid.usb1', 'hid.usb2', 'mass_storage.1']
11:29:26 kernel: [183829.208578] dwc3 21500000.usb: device reset
11:29:26 kernel: [183829.519143] android_work: sent uevent USB_STATE=CONNECTED
11:29:26 kvmd: HID-keyboard is busy/unplugged (write select) [1 times]
11:29:48 kvmd: HID-keyboard is busy/unplugged (write select) [128 times]
11:30:45 kvmd: HID-keyboard is busy/unplugged (write select) [512 times]
   ... no USB_STATE=CONFIGURED anywhere in this window ...
11:30:50 kvmd: Current OTG functions from .../configs/b.1: ['hid.usb0', 'hid.usb1', 'hid.usb2']
11:30:51 kernel: [183913.743307] android_work: sent uevent USB_STATE=CONNECTED
11:30:51 kernel: [183913.747503] android_work: sent uevent USB_STATE=CONFIGURED
11:30:51 kvmd: HID-keyboard write select recovered after 550 failures

So with mass_storage.1 in the configuration, the HP's BIOS resets the gadget and then never configures it. kvmd can't write to /dev/hidg0 the whole time. Without it, the BIOS configures it in 0.3 s.

About another computer: I've already tried two, both HP: this EliteDesk 705 G3 (BIOS P26 Ver. 02.44) and a ProDesk G7 (i5-10500). Same result on both. Also, once Linux has booted on the EliteDesk, it configures the exact same gadget fine (keyboard, mouse and usb-storage all bind, and the virtual drive shows up as sdb). So the cable and port are fine, and it's the HP BIOS's USB stack that rejects it.

I also ran the experiments from my last post, by rebuilding the live configfs gadget over SSH. I used the same full DWC3 unbind/bind as reset_uvc_udc, parked at the Startup Menu, and changed one thing per run:

The BIOS never configures the gadget (stuck at CONNECTED, keyboard dead):

  • 3× HID + mass_storage (the control)
  • the same with max_speed=full-speed
  • the same with stall=1
  • the same with mass storage linked first (interface 0)
  • the same with bmAttributes=0x80 and MaxPower=100
  • keyboard only + mass_storage

The BIOS configures it fine:

  • 3× HID (the normal gadget): keyboard works
  • keyboard + rndis (bulk + interrupt endpoints): keyboard works
  • mass_storage only
  • mass_storage × 2
  • rndis + mass_storage

On this firmware bDeviceClass is already 0 and os_desc/use is 0, so neither IAD nor the MS OS descriptors are involved. The HP's BIOS accepts storage on its own, and HID next to bulk endpoints, but never any HID together with mass storage in the same configuration. None of the descriptor settings I could reach changed that.

One more data point: with a storage-only gadget and the image attached, the BIOS configured it during POST, enumerated it a second time about 30 s later, and then sat on a dark screen. After that it never enumerated anything again, not even the plain HID gadget, so the machine needs a power cycle. I'll repeat that one from a cold boot before drawing conclusions.

Question: since this BIOS takes storage-only and HID-only fine, would a build that presents two USB configurations be feasible? For example b.1 = storage (what a BIOS selects) and b.2 = HID + storage. Linux skips a first configuration whose first interface is RNDIS, so b.1 = rndis + storage would make an OS pick b.2. Or is there a better approach you'd suggest?

Discourse only allowed me to post 1 link, so here is the follow-up: dmesg.log (217.6 KB)

Thanks for providing the logs. Please try this beta firmware.