Linux: Continually disconnects the greaseweazle

Hi, @keirf I was messaging you before, but will make this a ticket so I can document the solution somewhere useful 😃

Something in Linux is grabbing the USB port before greaseweazle.

At first I tried fighting modemmanager, but ultimately I’ve uninstalled it, not before adding a few more rules to 49-greaseweazle.rules [1]

lsmod shows nothing using cdc_acm

$ lsmod
Module                  Size  Used by
cdc_acm                36864  0

When I run ./gw info it doesn’t see the GW the first time, this output is in the journal:

$ journalctl -b -f
Aug 31 17:54:40 computer kernel: usb 1-2.1: reset full-speed USB device number 112 using xhci_hcd
Aug 31 17:54:40 computer kernel: usb 1-2.1: USB disconnect, device number 112
Aug 31 17:54:40 computer kernel: usb 1-2.1: new full-speed USB device number 113 using xhci_hcd
Aug 31 17:54:41 computer kernel: usb 1-2.1: New USB device found, idVendor=1209, idProduct=4d69, bcdDevice= 1.00
Aug 31 17:54:41 computer kernel: usb 1-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Aug 31 17:54:41 computer kernel: usb 1-2.1: Product: Greaseweazle
Aug 31 17:54:41 computer kernel: usb 1-2.1: Manufacturer: Keir Fraser
Aug 31 17:54:41 computer kernel: usb 1-2.1: SerialNumber: GW135194C04205400002101705
Aug 31 17:54:41 computer kernel: cdc_acm 1-2.1:1.0: ttyACM0: USB ACM device
Aug 31 17:54:41 computer snapd[2144]: hotplug.go:199: hotplug device add event ignored, enable experimental.hotplug

gw info, returns before everything all the journal output completes.

If I run $ ./gw info; sleep 1; ./gw info I get output that looks similar, but the second time it connects:

Aug 31 17:56:43 computer kernel: usb 1-2.1: reset full-speed USB device number 114 using xhci_hcd
Aug 31 17:56:43 computer kernel: usb 1-2.1: USB disconnect, device number 114
Aug 31 17:56:43 computer kernel: usb 1-2.1: new full-speed USB device number 115 using xhci_hcd
Aug 31 17:56:43 computer kernel: usb 1-2.1: New USB device found, idVendor=1209, idProduct=4d69, bcdDevice= 1.00
Aug 31 17:56:43 computer kernel: usb 1-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Aug 31 17:56:43 computer kernel: usb 1-2.1: Product: Greaseweazle
Aug 31 17:56:43 computer kernel: usb 1-2.1: Manufacturer: Keir Fraser
Aug 31 17:56:43 computer kernel: usb 1-2.1: SerialNumber: GW135194C04205400002101705
Aug 31 17:56:43 computer kernel: cdc_acm 1-2.1:1.0: ttyACM0: USB ACM device
Aug 31 17:56:44 computer snapd[2144]: hotplug.go:199: hotplug device add event ignored, enable experimental.hotplug
[ end of call to ./gw info]

Aug 31 17:57:12 computer kernel: usb 1-2.1: reset full-speed USB device number 115 using xhci_hcd
Aug 31 17:57:12 computer kernel: usb 1-2.1: USB disconnect, device number 115
Aug 31 17:57:12 computer kernel: usb 1-2.1: new full-speed USB device number 116 using xhci_hcd
Aug 31 17:57:12 computer kernel: usb 1-2.1: New USB device found, idVendor=1209, idProduct=4d69, bcdDevice= 1.00
Aug 31 17:57:12 computer kernel: usb 1-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Aug 31 17:57:12 computer kernel: usb 1-2.1: Product: Greaseweazle
Aug 31 17:57:12 computer kernel: usb 1-2.1: Manufacturer: Keir Fraser
Aug 31 17:57:12 computer kernel: usb 1-2.1: SerialNumber: GW135194C04205400002101705
Aug 31 17:57:12 computer kernel: cdc_acm 1-2.1:1.0: ttyACM0: USB ACM device
Aug 31 17:57:13 computer snapd[2144]: hotplug.go:199: hotplug device add event ignored, enable experimental.hotplug

I guess the USB device reset, and the device number increasing every time is expected ?

70-snap.core.rules.d has some stuff about ttyACM0 in it, but it’s a bit hard to understand since it’s all the rules together.

So, stuck for now - but will come back to this and see what else comes up.

[1] -extra ModemManager rules, may be handy:

ATTRS{manufacturer}=="Keir Fraser", ATTRS{product}=="Greaseweazle", \
    ENV{ID_MM_TTY_BLACKLIST}="1"
ATTRS{manufacturer}=="Keir Fraser", ATTRS{product}=="Greaseweazle", \
    ENV{MTP_NO_PROBE}="1"
ATTRS{manufacturer}=="Keir Fraser", ATTRS{product}=="Greaseweazle", \
    ENV{ID_MM_PORT_IGNORE}="1"
ATTRS{manufacturer}=="Keir Fraser", ATTRS{product}=="Greaseweazle", \
    ENV{ID_MM_TTY_MANUAL_SCAN_ONLY}="1"

I also set the filtering-rules=paranoid in ModemManager, similar this: https://newbedev.com/udev-rules-seem-ignored-can-not-prevent-modem-manager-from-grabbing-device

[tdaede]

So I ran into this with one computer - in my case, I found the problem was actually the power draw of the floppy spinning up browning out the USB port and causing either the microcontroller or possibly the USB host to reset (probably the former as the latter usually gives a different dmesg message). It might be worth trying powering your floppy drive from an external 5V power supply and seeing if the problem persists.

In my case, I found that some USB ports would deliver slightly more power, and it was a bit random depending on the position of the spindle motor.

[stuaxo]

Cheers, no further updates as my greaseweazle is in storage so closing makes sense.

When it comes out of storage I’ll give try it and update here if it still doesn’t work.