Proxmox USB: Connect & Disconnect Loop

L

LipkeGu

New Member
Sep 21, 2022
5
0
1
Hey,
Ich habe seit Proxmox 7 das problem mit dem ständigen neuverbinden von USB-Geräten. Das neuverbinden der USB-Geräte tretet in Windows und VMWare jedoch nicht auf.

Lg LipkeGu
Code: 
...
[ 6874.432433] usb 1-1.3: USB disconnect, device number 5
[ 6874.661938] usb 1-1.3: new full-speed USB device number 6 using ehci-pci
[ 6874.772889] usb 1-1.3: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00
[ 6874.772898] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 6874.772901] usb 1-1.3: Product: ConBee II
[ 6874.772904] usb 1-1.3: Manufacturer: dresden elektronik ingenieurtechnik GmbH
[ 6874.772906] usb 1-1.3: SerialNumber: DE2490983
[ 6874.773597] cdc_acm 1-1.3:1.0: ttyACM0: USB ACM device
[ 6878.272409] usb 1-1.3: USB disconnect, device number 6
[ 6878.493908] usb 1-1.3: new full-speed USB device number 7 using ehci-pci
[ 6878.604864] usb 1-1.3: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00
[ 6878.604873] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 6878.604876] usb 1-1.3: Product: ConBee II
[ 6878.604878] usb 1-1.3: Manufacturer: dresden elektronik ingenieurtechnik GmbH
[ 6878.604881] usb 1-1.3: SerialNumber: DE2490983
...
 
Last edited:
Hatte das Problem vor einem Jahr und auch heute wieder, das einzige was geholfen hatte war Proxmox in die Tonne zu treten und was anderes zu nehmen. TrueNAS Scale installiert und das funktionierte ohne Probleme von Anfang an. Proxmox hat ein Problem und es gibt hier leider keinen der einem helfen möchte.

Das hatte ich auch gefunden, hat aber nichts gebracht: https://tgraeber.de/usb-autosuspend-unter-proxmox-deaktivieren/
 
Last edited:
Teberon said:
Hatte das Problem vor einem Jahr und auch heute wieder, das einzige was geholfen hatte war Proxmox in die Tonne zu treten und was anderes zu nehmen. TrueNAS Scale installiert und das funktionierte ohne Probleme von Anfang an. Proxmox hat ein Problem und es gibt hier leider keinen der einem helfen möchte.
Click to expand...
soweit ich weiß verwendet TrueNAS Scale auch nur debian + qemu + kvm für die virtuellen maschinen. Wir machen bei usb passthrough nichts spezielles, nur das was qemu macht. Wenn du weißt was TrueNAS Scale anders macht das solche probleme löst, dann teile uns es doch bitte mit. Wir versuchen immer zu helfen, bei hardware spezifischen dingen ist es leider oft schwer da wir solche hardware meistens nicht haben.
 
Es geht gar nicht um das Passthrough (welches am Ende nicht geht). Das Problem tritt schon auf wenn der USB- Stick angeschlossen wurde.
Oct 31 14:16:48 pve01 kernel: usb 2-1.2: USB disconnect, device number 31 Oct 31 14:16:49 pve01 kernel: usb 2-1.2: new full-speed USB device number 32 using ehci-pci Oct 31 14:16:49 pve01 kernel: usb 2-1.2: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00 Oct 31 14:16:49 pve01 kernel: usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Oct 31 14:16:49 pve01 kernel: usb 2-1.2: Product: ConBee II Oct 31 14:16:49 pve01 kernel: usb 2-1.2: Manufacturer: dresden elektronik ingenieurtechnik GmbH Oct 31 14:16:49 pve01 kernel: usb 2-1.2: SerialNumber: DE2423760 Oct 31 14:16:49 pve01 kernel: cdc_acm 2-1.2:1.0: ttyACM0: USB ACM device Oct 31 14:16:52 pve01 kernel: usb 2-1.2: USB disconnect, device number 32 Oct 31 14:16:53 pve01 kernel: usb 2-1.2: new full-speed USB device number 33 using ehci-pci Oct 31 14:16:53 pve01 kernel: usb 2-1.2: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00 Oct 31 14:16:53 pve01 kernel: usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Oct 31 14:16:53 pve01 kernel: usb 2-1.2: Product: ConBee II Oct 31 14:16:53 pve01 kernel: usb 2-1.2: Manufacturer: dresden elektronik ingenieurtechnik GmbH Oct 31 14:16:53 pve01 kernel: usb 2-1.2: SerialNumber: DE2423760 Oct 31 14:16:53 pve01 kernel: cdc_acm 2-1.2:1.0: ttyACM0: USB ACM device ... Oct 31 15:16:53 pve01 kernel: usb 2-1.2: USB disconnect, device number 33 Oct 31 15:16:53 pve01 kernel: usb 2-1.2: new full-speed USB device number 34 using ehci-pci Oct 31 15:16:53 pve01 kernel: usb 2-1.2: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00 Oct 31 15:16:53 pve01 kernel: usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Oct 31 15:16:53 pve01 kernel: usb 2-1.2: Product: ConBee II Oct 31 15:16:53 pve01 kernel: usb 2-1.2: Manufacturer: dresden elektronik ingenieurtechnik GmbH Oct 31 15:16:53 pve01 kernel: usb 2-1.2: SerialNumber: DE2423760 Oct 31 15:16:53 pve01 kernel: cdc_acm 2-1.2:1.0: ttyACM0: USB ACM device Oct 31 15:16:57 pve01 kernel: usb 2-1.2: USB disconnect, device number 34 Oct 31 15:16:57 pve01 kernel: usb 2-1.2: new full-speed USB device number 35 using ehci-pci Oct 31 15:16:57 pve01 kernel: usb 2-1.2: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00 Oct 31 15:16:57 pve01 kernel: usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Oct 31 15:16:57 pve01 kernel: usb 2-1.2: Product: ConBee II Oct 31 15:16:57 pve01 kernel: usb 2-1.2: Manufacturer: dresden elektronik ingenieurtechnik GmbH Oct 31 15:16:57 pve01 kernel: usb 2-1.2: SerialNumber: DE2423760 Oct 31 15:16:57 pve01 kernel: cdc_acm 2-1.2:1.0: ttyACM0: USB ACM device

Das passiert stündlich, warum ist eine gute Frage. Läuft dort nen interner Script, ist das verursacht durch Fehlermeldungen die nicht im Syslog angezeigt werden? Was kurze Zeit später passiert ist

Oct 31 14:17:01 pve01 CRON[345256]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
Oct 31 14:17:01 pve01 CRON[345257]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Oct 31 14:17:01 pve01 CRON[345256]: pam_unix(cron:session): session closed for user root

Hängt das zusammen?


Derzeit gibt es mit der Hardware und dem Stick keine Probleme, auch nicht in anderen Anfragen hier im Forum. VMWare, TrueNAS und Windows haben keine Probleme den Stick zu erkennen und zu nutzen, derzeit ist es nur Proxmox wo es diese Probleme mit Standardinstallationen gibt. Ich bin leider nicht so tief in der Linux/Kernel Materie um da Troubleshooting zu machen. Das ist nen Hobby für mich, kann aber gern Logs zur Verfügung stellen
 
Last edited:
Teberon said:
Das passiert stündlich, warum ist eine gute Frage. Läuft dort nen interner Script, ist das verursacht durch Fehlermeldungen die nicht im Syslog angezeigt werden? Was kurze Zeit später passiert ist

Oct 31 14:17:01 pve01 CRON[345256]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
Oct 31 14:17:01 pve01 CRON[345257]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Oct 31 14:17:01 pve01 CRON[345256]: pam_unix(cron:session): session closed for user root

Hängt das zusammen?
Click to expand...
unwahrscheinlich, wir machen grundsätzlich nichts was usb devices angreifen würde (die nicht für passthrough konfiguriert sind)

wurde schonmal ein usb hub mit externer stromversorgung versucht? manchmal liefern die onboard usb ports nicht genug strom

wie ich bereits in meinem vorigen post geschrieben habe, berichten immer wieder leute über diesen stick das er sich resettet auf deren github, und scheinbar hiflt es öfter neue firmware zu flashen:

https://github.com/dresden-elektronik/deconz-rest-plugin/issues/4029
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/3712
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/3262
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/3714
 
Das würde ja Sinn machen, wenn ich nicht schon die Firmware geflasht hätte und es auch Probleme anderswo gibt.
Es ist nur mit Proxmox als Hypervisor der Fall und nicht mit VMWare (ESXI 7+8), TrueNAS Scale, Windows 10 + 11 (Virtualbox) und Arch Linux. Nur Proxmox hat das Problem das eine VM mit HASS den Stick nicht benutzen kann. Er wird erkannt kann aber nicht mit den Zigbee Geräten kommunizieren. Stecke ich den Stick vom Proxmox Server an meine 3 Rechner wo VirtualBox dasselbe Image von HASS benutzt, dann funktioniert das. Und hier im Forum gibt es viele, die genau dasselbe berichten.

Es ist ein Softwareproblem bei Proxmox und ich würde mich freuen wenn da ein wenig mehr an dieser Theorie gearbeitet wird. Aber wahrscheinlich möchte man hier den Heimanwendern, die nicht tausende für ihr Hobby ausgeben wollen, eh nicht helfen
 
Teberon said:
Es ist ein Softwareproblem bei Proxmox und ich würde mich freuen wenn da ein wenig mehr an dieser Theorie gearbeitet wird. Aber wahrscheinlich möchte man hier den Heimanwendern, die nicht tausende für ihr Hobby ausgeben wollen, eh nicht helfen
Click to expand...

Etwas wenig motivierend, wenn sich neue Forummitglieder sich so der Proxmox Community vorstellen. Erst schreiben dass man sich nicht mit Linux auskennt und dann aber sicher sein, das es an Linux liegt ...

Und ja, solche Posts helfen eher gar nicht, das andere Proxmox User - meist in ihrer Freizeit - hier helfend zur Seite stehen.

=> Bitte nochmal nachdenken vor dem nächsten Post in unserer Community.
 
  • Like
Reactions: TomFIT
Das einzige was ich hier höre: Nicht unser Problem such woanders. Ich habe oben angeboten Logs herauszusuchen die hilfreich sind, wird aber nicht angenommen. Hier sind mal ein paar Einträge die ein Problem bei Proxmox aufzeigen und auch Workarounds, aber das sollte ja wohl dann kein Problem sein, mal dorthin zu arbeiten und das von Hause aus zu lösen

https://forum.proxmox.com/threads/passthrough-problem-with-conbee-2-on-pimox.107447/

https://github.com/pimox/pimox7/issues/48

"It appears that qemu can actually handle usb passthrough perfectly, but proxmox is unable to configure it properly.

Instead of adding the device by proxmox's hardware page, just edit the vm conf file and do the passthrough through args
args: -device qemu-xhci -device usb-host,vendorid=<0xVendorid>,productid=<0xProductid>
filling the vendor id and product id with the values obtained either from gui (you can see it when adding the usb passhtrough) or fromlsusb on host machine. Remember to prefix it with 0x."

https://forum.proxmox.com/threads/usb-device-keeps-disconnecting.100913/

https://forum.proxmox.com/threads/usb-device-pass-thru-not-working.109498/
 
Teberon said:
https://github.com/pimox/pimox7/issues/48

"It appears that qemu can actually handle usb passthrough perfectly, but proxmox is unable to configure it properly.

Instead of adding the device by proxmox's hardware page, just edit the vm conf file and do the passthrough through args
args: -device qemu-xhci -device usb-host,vendorid=<0xVendorid>,productid=<0xProductid>
filling the vendor id and product id with the values obtained either from gui (you can see it when adding the usb passhtrough) or fromlsusb on host machine. Remember to prefix it with 0x."
Click to expand...
nach solchen informationen hab ich doch gefragt:

dcsapak said:
Wir machen bei usb passthrough nichts spezielles, nur das was qemu macht. Wenn du weißt was TrueNAS Scale anders macht das solche probleme löst, dann teile uns es doch bitte mit.
Click to expand...

wenn du bei uns im gui usb passthrough konfigurierst, kanns du die ganze qemu commandline mit
Code: 
qm showcmd ID --pretty
sehen

und da sind dann folgende einträge:

Code: 
...
-device 'nec-usb-xhci,id=xhci,bus=pci.1,addr=0x1b' \
...
-device 'usb-host,bus=xhci.0,vendorid=0xVendorId,productid=0xProductId,id=usb0' \
...
was eigentlich das gleiche ist wie die angegebene lösung, (außer dass die ports/der bus explizit angegeben werden, sonst werden die von qemu automatisch vergeben)
mit ausnahme des xhci controllers. da verwenden wir den 'nec-usb-xhci' und die anleitung 'qemu-xhci'

den 'qemu-xhci' gab es nicht immer, daher der 'nec' nachdem ich aber ein bisschen gelesen habe vorallem https://www.kraxel.org/blog/2018/08/qemu-usb-tips/
scheint der qemu-xhci die bessere wahl für aktuelle gäste zu sein (> windows 7)

ich werde schauen ob wir den default controller ändern können (zumindest für neue gäste)
hab mal dafür einen bug aufgemacht:

https://bugzilla.proxmox.com/show_bug.cgi?id=4324
 
  • Like
Reactions: Neobin and fiona
FYI: mit PVE 7.3 wir verwenden den qemu-xhci controller (für neue machine types >= 7.1), dh. vielleicht mal upgraden, machine type aktualisieren und nochmal versuchen ?
 
dcsapak said:
FYI: mit PVE 7.3 wir verwenden den qemu-xhci controller (für neue machine types >= 7.1), dh. vielleicht mal upgraden, machine type aktualisieren und nochmal versuchen ?
Click to expand...
Ich weiß nicht wie umständlich es ist eine Auswahl im Webinterface einzufügen aber nett wär es schon.

Da mir gestern aufgefallen ist, dass nach dem Update auf 7.3 mein USB Festplatten passthrough nicht mehr funktioniert.

Sicher bin ich mir nicht ob es wirklich an der Änderung des Controllers liegt, aber dass werde ich heute Abend mal überprüfen.
 
wenn es tatsächlich daran liegt, könntest du bitte die vm config posten und schauen ob es wieder funktioniert mit machine type auf 7.0 gesetzt (geht auch im gui)
und vllt. ein dmesg von einem funktionierenden und nicht funktionierenden passthrough posten (sowohl gast als auch host)
 
Sorry für den späten Post. Es sieht so aus als wär die USB Controller Änderung wirklich das Problem gewesen, umstellung auf 7.0 hat es einwandfrei funktioniert :)

VM Config:
agent: 1 boot: order=scsi0;ide2;net0 cores: 4 ide2: none,media=cdrom machine: pc-i440fx-7.0 memory: 16384 meta: creation-qemu=6.1.0,ctime=1638071056 name: TrueNAS net0: virtio=FF:FF:FF:FF:FF:FF,bridge=vmbr1,firewall=1 net1: virtio=FF:FF:FF:FF:FF:FF,bridge=vmbr0,firewall=1 numa: 1 onboot: 1 ostype: l26 scsi0: OS-SSD-2:vm-1100-disk-0,size=32G,ssd=1 scsi1: /dev/disk/by-id/ata-CT250MX500SSD1_2136E5CF01FC,backup=0,size=244198584K scsihw: virtio-scsi-pci smbios1: uuid=********-****-****-****-************ sockets: 1 usb0: host=6-2.1 usb1: host=6-2.2 usb2: host=6-2.3 usb3: host=6-2.4 vmgenid: ********-****-****-****-************

Ich weiß nicht ob ich noch nen anderen dmesg Query versuchen soll, da "Host funktionierend" und "Host fehler" quasi identisch sind... Aber ich kenn mich leider noch nicht zu 100 % mit Linux aus :(

Aber die "Logs" sehen wie folgt aus:


Funktionierender Passthrough Host (Machine type 7.0):
root@pve:~# dmesg | grep -v "usb 1-2" | grep usb [60790.658540] usb 6-2.1: reset SuperSpeed Plus Gen 2x1 USB device number 8 using xhci_hcd [60791.018515] usb 6-2.2: reset SuperSpeed Plus Gen 2x1 USB device number 9 using xhci_hcd [60791.382502] usb 6-2.3: reset SuperSpeed Plus Gen 2x1 USB device number 10 using xhci_hcd [60791.494493] usb 6-2.4: reset SuperSpeed Plus Gen 2x1 USB device number 11 using xhci_hcd

Funktionierender Passthrough Client (Machine type 7.0):
root@NAS[~]# dmesg | grep usb usbus0 on uhci0 usbus0: 12Mbps Full Speed USB v1.0 usbus1 on uhci1 usbus1: 12Mbps Full Speed USB v1.0 usbus2 on uhci2 usbus2: 12Mbps Full Speed USB v1.0 usbus3 on uhci3 usbus3: 12Mbps Full Speed USB v1.0 usbus4: EHCI version 1.0 usbus4 on ehci0 usbus4: 480Mbps High Speed USB v2.0 ugen3.1: <Intel UHCI root HUB> at usbus3 ugen4.1: <Intel EHCI root HUB> at usbus4 uhub1: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus4 ugen1.1: <Intel UHCI root HUB> at usbus1 uhub2: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus1 uhub0: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus3 ugen2.1: <Intel UHCI root HUB> at usbus2 uhub3: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus2 ugen0.1: <Intel UHCI root HUB> at usbus0 uhub4: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0 Root mount waiting for: CAM usbus0 usbus1 usbus2 usbus3 usbus4 ugen0.2: <QEMU QEMU USB Tablet> at usbus0 uhid0: <QEMU QEMU USB Tablet, class 0/0, rev 2.00/0.00, addr 2> on usbus0 Root mount waiting for: usbus4 Root mount waiting for: usbus4 Root mount waiting for: usbus4 Root mount waiting for: usbus4 ugen4.2: <VIA Labs,Inc. USB3.1 SATA Bridge> at usbus4 umass0: <VIA Labs,Inc. USB3.1 SATA Bridge, class 0/0, rev 3.10/6.14, addr 2> onusbus4 ugen4.3: <VIA Labs,Inc. USB3.1 SATA Bridge> at usbus4 umass1: <VIA Labs,Inc. USB3.1 SATA Bridge, class 0/0, rev 3.10/6.14, addr 3> onusbus4 ugen4.4: <VIA Labs,Inc. USB3.1 SATA Bridge> at usbus4 umass2: <VIA Labs,Inc. USB3.1 SATA Bridge, class 0/0, rev 3.10/6.14, addr 4> onusbus4 ugen4.5: <VIA Labs,Inc. USB3.1 SATA Bridge> at usbus4 umass3: <VIA Labs,Inc. USB3.1 SATA Bridge, class 0/0, rev 3.10/6.14, addr 5> onusbus4

Fehlerhafter Passthrough Host (Machine type Latest):
root@pve:~# dmesg | grep -v "usb 1-2" | grep usb [60790.658540] usb 6-2.1: reset SuperSpeed Plus Gen 2x1 USB device number 8 using xhci_hcd [60791.018515] usb 6-2.2: reset SuperSpeed Plus Gen 2x1 USB device number 9 using xhci_hcd [60791.382502] usb 6-2.3: reset SuperSpeed Plus Gen 2x1 USB device number 10 using xhci_hcd [60791.494493] usb 6-2.4: reset SuperSpeed Plus Gen 2x1 USB device number 11 using xhci_hcd

Fehlerhafter Passthrough Client (Machine type Latest):
Query: root@NAS[~]# dmesg | grep usb
root@NAS[~]# dmesg | grep usb usbus0 on uhci0 usbus0: 12Mbps Full Speed USB v1.0 usbus1 on xhci0 usbus1: 5.0Gbps Super Speed USB v3.0 ugen0.1: <Intel UHCI root HUB> at usbus0 uhub0: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0 ugen1.1: <0x1b36 XHCI root HUB> at usbus1 uhub1: <0x1b36 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus1 Root mount waiting for: CAM usbus0 usbus1 Root mount waiting for: usbus0 usbus1 ugen0.2: <QEMU QEMU USB Tablet> at usbus0 uhid0: <QEMU QEMU USB Tablet, class 0/0, rev 2.00/0.00, addr 2> on usbus0 Root mount waiting for: usbus1 Root mount waiting for: usbus1 ugen1.2: <VIA Labs,Inc. USB3.1 SATA Bridge> at usbus1 umass0: <VIA Labs,Inc. USB3.1 SATA Bridge, class 0/0, rev 3.10/6.14, addr 1> onusbus1 Root mount waiting for: usbus1 CAM ugen1.3: <VIA Labs,Inc. USB3.1 SATA Bridge> at usbus1 umass1: <VIA Labs,Inc. USB3.1 SATA Bridge, class 0/0, rev 3.10/6.14, addr 2> onusbus1 Root mount waiting for: usbus1 CAM Root mount waiting for: usbus1 CAM ugen1.4: <VIA Labs,Inc. USB3.1 SATA Bridge> at usbus1 umass2: <VIA Labs,Inc. USB3.1 SATA Bridge, class 0/0, rev 3.10/6.14, addr 3> onusbus1 Root mount waiting for: usbus1 CAM Root mount waiting for: usbus1 CAM ugen1.5: <VIA Labs,Inc. USB3.1 SATA Bridge> at usbus1 umass3: <VIA Labs,Inc. USB3.1 SATA Bridge, class 0/0, rev 3.10/6.14, addr 4> onusbus1
Query: root@NAS[~]# dmesg | grep CAM
root@NAS[~]# dmesg | grep CAM Root mount waiting for: CAM usbus0 usbus1 Root mount waiting for: usbus1 CAM Root mount waiting for: usbus1 CAM Root mount waiting for: usbus1 CAM Root mount waiting for: usbus1 CAM Root mount waiting for: usbus1 CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM (probe2:umass-sim2:2:0:0): CAM status: CCB request completed with an error Root mount waiting for: CAM (probe3:umass-sim3:3:0:0): CAM status: CCB request completed with an error Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM (probe2:umass-sim2:2:0:0): CAM status: CCB request completed with an error Root mount waiting for: CAM (probe2:umass-sim2:2:0:0): CAM status: CCB request completed with an error Root mount waiting for: CAM Root mount waiting for: CAM ......... Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error Root mount waiting for: CAM Root mount waiting for: CAM (probe1:umass-sim1:1:0:0): CAM status: CCB request completed with an error Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error Root mount waiting for: CAM Root mount waiting for: CAM (probe1:umass-sim1:1:0:0): CAM status: CCB request completed with an error Root mount waiting for: CAM (probe2:umass-sim2:2:0:0): CAM status: CCB request completed with an error (probe2:umass-sim2:2:0:0): CAM status: CCB request completed with an error Root mount waiting for: CAM (probe3:umass-sim3:3:0:0): CAM status: CCB request completed with an error Root mount waiting for: CAM (probe3:umass-sim3:3:0:0): CAM status: CCB request completed with an error root@NAS[~]#
 
Last edited:
was ist denn das genau für ein gerät?

kannst du auch mal einen ungefilterten dmesg vom gast einmal funktionierend und einmal nicht funktionierend posten? (grep nach usb/cam ist ein bisschen wenig)
 
Ich haeng mich hier mal mit rein. Habe gestern eine neue APC USV (BX950MI) bekommen und habe das gleiche Problem, allerdings mit einem Unterschied. Ich reiche die USV an keine VM oder container durch.

Alle zwei Minuten bekomme ich einen disconnect.

[Dec 6 10:40] usb 1-12: USB disconnect, device number 22 [ +0.850188] usb 1-12: new full-speed USB device number 23 using xhci_hcd [ +0.150157] usb 1-12: New USB device found, idVendor=051d, idProduct=0002, bcdDevice= 1.06 [ +0.000003] usb 1-12: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ +0.000001] usb 1-12: Product: Back-UPS BX950MI FW:295202G -302202G [ +0.000001] usb 1-12: Manufacturer: American Power Conversion [ +0.000001] usb 1-12: SerialNumber: 9B2222A31162 [ +0.004722] hid-generic 0003:051D:0002.000A: hiddev1,hidraw1: USB HID v1.10 Device [American Power Conversion Back-UPS BX950MI FW:295202G -302202G ] on usb-0000:00:14.0-12/input0 [Dec 6 10:42] usb 1-12: USB disconnect, device number 23 [ +0.858600] usb 1-12: new full-speed USB device number 24 using xhci_hcd [ +0.150103] usb 1-12: New USB device found, idVendor=051d, idProduct=0002, bcdDevice= 1.06 [ +0.000003] usb 1-12: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ +0.000001] usb 1-12: Product: Back-UPS BX950MI FW:295202G -302202G [ +0.000001] usb 1-12: Manufacturer: American Power Conversion [ +0.000001] usb 1-12: SerialNumber: 9B2222A31162 [ +0.004610] hid-generic 0003:051D:0002.000B: hiddev1,hidraw1: USB HID v1.10 Device [American Power Conversion Back-UPS BX950MI FW:295202G -302202G ] on usb-0000:00:14.0-12/input0 [Dec 6 10:44] usb 1-12: USB disconnect, device number 24 [ +0.855623] usb 1-12: new full-speed USB device number 25 using xhci_hcd [ +0.150155] usb 1-12: New USB device found, idVendor=051d, idProduct=0002, bcdDevice= 1.06 [ +0.000003] usb 1-12: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ +0.000001] usb 1-12: Product: Back-UPS BX950MI FW:295202G -302202G [ +0.000001] usb 1-12: Manufacturer: American Power Conversion [ +0.000000] usb 1-12: SerialNumber: 9B2222A31162 [ +0.004687] hid-generic 0003:051D:0002.000C: hiddev1,hidraw1: USB HID v1.10 Device [American Power Conversion Back-UPS BX950MI FW:295202G -302202G ] on usb-0000:00:14.0-12/input0


Ich werde im Laufe des Tages noch ein BIOS update machen und in den Einstellungen nochmal nach USB power save zeugs gucken was das verursachen koennte. Ein Test der USV an meinem Laptop (arch) hatte keinen disconnect zur Folge. Ich hab allerdings auch den deconz stick angeschlossen, ich gucke mal nach einem Firmware update dafuer.

EDIT1: So, BIOS update auf die aktuelle Versio gemacht und nochmal im BIOS geschaut ob ich irgendwelche Optionen habe, die dafuer sorgen koennten; leider ohne Erfolg.

Selbst nur mit der USV als einzigem USB Geraet angeschlossen bekomme ich die disconnects. Anderen USB Port habe ich ebenfalls probiert, das USB Kabel kann es nicht sein, da es am Laptop funktioniert.

Naechster Schritt also: Mal ein ubuntu/debian live image booten und gucken was dann passiert. Ich werde den Post hier weiter editieren.
 
Last edited:
Meiner Guete, was ein Krampf das wieder mal war.

- Server mit nem arch live usb stick gestartet, USB verbindung bleibt bestehen, apcaccess status zeigt auch brav den status an
- Server mit nem debian live usb gestartet, gleiches Problem. alle zwei Minuten die USB disconnect Meldung.
- autosuspend fuer usbcore deaktiviert machte auch keinen Unterschied, was bei arch aber auch nicht der Fall war.

Die Loesung war letztendlich eine Aenderung an der apcupsd.conf fuer den DEVICE eintrag. Debian kommt mit "DEVICE /dev/ttyS0", arch hat hier "
DEVICE /dev/usb/hid/hiddev[0-9]". Den Eintrag auf nur DEVICE abgeaendert und schon ist das Problem behoben.

Warum ich allerdings den device disconnect und reconnect alle zwei Minuten bekommen habe OBWOHL apcupsd nicht lief; das erschliesst sich mir in keinster Weise. Aber ich hinterfrage das auch nicht mehr, das hat mich genug Nerven gekostet.

Vielleicht hilft die "Loesung" ja noch wem......
 
  • Like
Reactions: Keks95
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom
Back