On Fri, 24 Oct 2025 12:48:07 +0200 Dorian Büttner <[email protected]> wrote:
> mind sharing your dmesg to the list? Thank you for responding. Attached are four dmesg copies: 1. The original 7.7 fully working dmesg (7.7-dmesg.zst). 2. The first boot into 7.8 dmesg (7.8-dmesg.zst). 3. The testing boot after resetting the bios to defaults with other devices plugged into the usb ports to confirm they are functional (7.8-dmesg-bios-reset.zst) 4. A clean boot after bios reset in #3, and with only the GPS plugged into the usual usb ports (7.8-dmesg-bios-reset-clean.zst). > > On 10/24/25 08:11, [email protected] wrote: > > /bsd: uplcom0 at uhub1 port 1 configuration 1 interface 0 "Prolific > > Technology Inc. USB-Serial Controller" rev 2.00/1.05 addr 3 > > /bsd: ucom0 at uplcom0: usb0.2.00001.0 > > > This is a usb-to-serial converter, should normally work out of the > box. I successfully attach rev 1.10/3.00 of it on snapshot. A normal console cable does work fine, in fact everything I plug in appears as expected, except the GPS receiver. You can see in the 3rd dmesg I have a usb keyboard and usb flash drive plugged into the usb ports for testing. > What's that "no avail"? If the uplcom doesn't attach, it should error > out with 'cu: open("/dev/cuaU0"): Device not configured' This is correct. It gets more odd. Here's how my testing has proceeded: 1. I plug the GPS receiver[1] into a linux machine: kernel: usb 1-2: new full-speed USB device number 5 using xhci_hcd kernel: usb 1-2: New USB device found, idVendor=0403, idProduct=6001, bcdDevice= 6.00 kernel: usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 kernel: usb 1-2: Product: FT232R USB UART kernel: usb 1-2: Manufacturer: FTDI mtp-probe[3330]: checking bus 1, device 5: "/sys/devices/pci0000:00/0000:00:08.1/0000:04:00.3/usb1/1-2" mtp-probe[3330]: bus: 1, device: 5 was not an MTP device kernel: usbcore: registered new interface driver ftdi_sio kernel: usbserial: USB Serial support registered for FTDI USB Serial Device kernel: ftdi_sio 1-2:1.0: FTDI USB Serial Device converter detected kernel: usb 1-2: Detected FT232R kernel: usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB0 In linux, I attach picocom to /dev/ttyUSB0, I get nmea stanzas as expected, since the receiver is flashing red, indicating signal lock. 2. I attach the GPS device into the openbsd 7.8 machine: It now shows up as a USB hub: Controller /dev/usb0: addr 01: 8086:0000 Intel, xHCI root hub super speed, self powered, config 1, rev 1.00 driver: uhub0 addr 02: 1a40:0101 Terminus Technology, USB2.0 HUB high speed, self powered, config 1, rev 1.00 driver: uhub1 3. I boot into a live usb system running linux on the hardware which has obsd 7.8 installed, and it correctly sees the GPS reciever. I"m confused as to what is happening in openbsd 7.8. I notice in linux it has the correct idVendor/idProduct (0403/6001) as expected. In 7.8, it has a completely different vendor/product (1a40:0101) id. Confusingly, 7.7 and 7.8 both see the ""Terminus Technology USB2.0 HUB", but 7.7 sees the "Prolific Technology Inc. USB-Serial Controller" rev 2.00/1.05" which is the actual interface to the serial reciever for uplcom0. I have not disassembled the device to learn how it is built. Logically, it has a usb hub inside to handle the output from the serial data stream from the gnss signal receiver. I've been reading about the usb subsystem in openbsd to see if I can write some code to probe the usb hardware on the 7.8 system to see what's happening. A possible next step is to backup 7.8 and re-install 7.7 without changing the hardware/configuration just to see if it still works as it once did for years (from 7.4 through 7.7 releases). Happy to hear alternative opinions, theories, suggestions. Thanks for responding. deimos [1] https://www.globalsat.com.tw/en/product-282242/USB-GNSS-Receiver-BU-353N5.html
7.7-dmesg.zst
Description: application/zstd
7.8-dmesg.zst
Description: application/zstd
7.8-dmesg-bios-reset.zst
Description: application/zstd
7.8-dmesg-bios-reset-clean.zst
Description: application/zstd
