USB hiba: unable to enumerate USB device

Fórumok

Helló!

Van itt egy USB-s DAC-om (link),ami az alábbi hibát produkálja és sehogy sem sikerül életre keltenem:

[ 38.410089] usb 1-1.5: new full-speed USB device number 4 using xhci_hcd
[ 38.483414] usb 1-1.5: device descriptor read/64, error -32
[ 38.663435] usb 1-1.5: device descriptor read/64, error -32
[ 38.843423] usb 1-1.5: new full-speed USB device number 5 using xhci_hcd
[ 38.916723] usb 1-1.5: device descriptor read/64, error -32
[ 39.096740] usb 1-1.5: device descriptor read/64, error -32
[ 39.276728] usb 1-1.5: new full-speed USB device number 6 using xhci_hcd
[ 39.690051] usb 1-1.5: device not accepting address 6, error -32
[ 39.763349] usb 1-1.5: new full-speed USB device number 7 using xhci_hcd
[ 40.176687] usb 1-1.5: device not accepting address 7, error -32
[ 40.176892] usb 1-1-port5: unable to enumerate USB device

Pár évvel ezelőtt gond nélkül működött,aztán egy ideig nem használtam, mostanában újra elővettem és nem akar működni. A "legjobb" az egészben,hogy Windows alatt gond nélkül megy azonnal minden,tehát maga az eszköz elvileg jó. Rengeteget kutakodtam a neten,eddig semmi sem segített, de hátha van valakinek egy újabb tippje?

Amiket eddig próbáltam sikertelenül:
- több különböző gép: custom desktop pc/up-to-date arch linux,lenovo laptop/up-to-date arch linux,hp brand gép/ubuntu 16.10, rpi3/libreelec - ezek közül egyiken sem ment. (2 különböző windows 7 pc,mindkettőn hiba nélkül működött.)
- 3 különböző usb kábel
- USB2-es porton, vagy letiltva az xhci modult ugyanezt a hibát generálja csak az ehci_hcd/ehci_pci modulokat használva
- az alaplap BIOS-ában az USB beállítások összes variációja
- BIOS update
- echo -1 | sudo tee /sys/module/usbcore/parameters/autosuspend és echo Y | sudo tee /sys/module/usbcore/parameters/old_scheme_first
- http://paulphilippov.com/articles/how-to-fix-device-not-accepting-addre…
- IOMMU bekapcsolása

Hozzászólások

Mennyi ennek a csodának az áramfelvétele? Ahogy nézem a logot, többször bejelentkezik, ami azért gyanús, mert olyan, mint amikor a bejelentkezést követően bekapcsol valami nagyobb áramú részt, a kábel ellenállásán eső feszültség miatt brown out reset lesz, s kezdődik minden elölről.

Amit mindenképp kipróbálnék: rövid, tehát mondjuk 50 cm-es USB kábellel, értelemszerűen nem HUB-ba dugva és nem elölre, hanem a gép hátulján lévő USB csatlakozóba, toldás, hosszabbítás nélkül, ha van kéznél "Y" kábel, amelyik képes a host két portjáról tápot felvenni, akkor azzal. Előbb a PC-be bedugni a két USB dugót, végül ebbe a DAC-ba a maradékot. Közben elmormolni egy imát, és reménykedni. Az USB az plug and pray eszköz, nem? ;)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az állítás szerint más rendszer viszi. Ebből következik, hogy driver hiba. Amikor a driver descriptorokat olvassa, akkor legfeljebb 44 Ohm||10uF lehet a terhelés, ugyanis a descriptorok alapján egyeznek meg a felvett teljesítményben. Addig meg nem szabad ennél többet felvennie.
Jobb híján Windows alatt kell kiolvasni a decriptorokat, aztán megnézni milyen driver bugot kellene javítani.

Itt egy hasonló hiba.

Ha jól értem, olyasmire gondolsz, hogy csak 100 mA-t enged meg a kernel, de az eszköznek több kell. Amúgy nem tudom, miért nem lehet a limit fixen 500 mA. Azt is jó volna tudni, melyik ez a kernel, s azt, esetleg a 4.11-gyel jobb-e a helyzet.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem a kernel, hanem az usb szabvány. Tudod, kettőnk közül én olvastam. ;)
A limit pl. azért nem lehet fix 500mA, mert
- az alaplapnak saját energiagazdákodása/port védelme van
- nekem meg 1,5A-es portom (ájfón töltéshez továbbfejlesztett bios :))

A kapacitás limit pl.: egy step-up konverternél akkor kapcsolom rá az 1000uF puffert, ha "megbeszéltük". Ha előtte, akkor meg a védelem túlterhelés miatt lekapcsolja a villanyt.

Az USB szabvány szerintem 500 mA-t enged meg, már ha annyi az igény. Nem értem, hogyan jön ide az alaplap saját port védelme? Legyen neki, csak ne 100 mA-es, hanem 500 mA-es limittel. Az a 1.5 A, amelyről beszélsz, biztos, hogy szabványos? Továbbra is az a kérdésem, miért értelmes ez a több féle limit? Attól, hogy valaki azt állítja magáról, hogy belefér 100 mA-be, ez még nem lesz igaz, ha mégse, s akkor lekonyul a táp, amitől meg szomorú a felhasználó. Nyertünk valamit? Egy gyomorfekélyben hamarabb elpatkoló felhasználót, akinek boldogabb is lehetett volna az élete.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Lelki szemeimmel látom: Ilyenkor jön az, hogy már megint személyeskedek. ;)
Hidd el, amit szerinted tud egy usb port az teljesen irreleváns! Nyilvánvalóan van interneted, be tudod írni az usb.org-ot és letölteni a szabványokat. Sőt, megírhatod nekik: Fingotok sincs semmiről, sőt nem is értetek semmmihez!
Biztosan díjaznák. :)

Megnyugtatlak, az 1,5A is szabványos. Főként a PD (portable device) elterjedése miatt növelték a terhelhetőséget. Már vagy 10 éve. Az usb 3 már akár 100W-ig tud teljesítmény biztosítani. Egy egyszerűbb usb 2 példa az usb dvd író vagy oszcilloszkóp. Ezek rövid, vastag Y kábellel csatlakoznak a régi 500mA-es limit miatt. Az egyik port kommunikál (is), a másik suspend állapotban van és csak az áramot biztosítja. Az utóbbihoz többnyire külön driver kell. Nálam a másodlagos driver nem szokott elindulni, mert megdumálják az áramigényt, a port power delivery class-t (2), és megegyeznek az egy kábeles működésben.

Egy számítógépben a teljesítmény nem csak az usb porton, de a pcie buszon is menedzselt. Bár ez utóbbi - néha kevés sikerrel - kikapcsolható. Az alaplap egyszerűen lekapcsolja a rakoncátlankodó kártyát.

A felhasználó meg olvasgasson! Nyilvánvalóan nem a 10mA fogyasztású pendrive lesz a kritikus elem. Viszont a szabvány részletesen leírja, hogy mit kell tenni, ha zárlatos akkus ájfónt dug fel a gyomorfekélyes felhasználód. Így aztán kevésbé füstöl a laptop, mindenki hepi! ;) Mert ilyenkor nem a táp konyulna le, hanem a kábel és az elektronika füstölne. Vagy legalább világítana. :)

Azon most legyünk túl, hogy így van ez, nem is a tényekkel szállok vitába. :) Nekem az fáj, hogy miért nem fix 500 mA a limit. Ekkora áram azért még nem félelmetes, fölötte meg vegye el a tápot és kész. De meg is fordíthatnám: ha meg annyira cizellálják ezt, akkor miért nem mondjuk 8 biten, 2 mA felbontással lehet megadni az áramkorlátot? Nyilván semmi értelme nem volna, de úgy érzem, annak se sok, hogy 100 mA-t meg lehet adni, s így legalább van esély elszúrni a driver-t, s egy 300 mA-es eszköztől elvenni a villanyt, mert szentül hisszük, hogy bele fog férni 100 mA-be az áramfelvétele.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Kívánságod teljesült. Itt a megfelelő sor a HID ConfigDescr0-ból:

			db			.30, 0					;MaxPower				- bus-powered draws 30*2 mA from the bus.

Nem tudom mi a problémád a biztosítékkal. Ha egy százas izzó max. 0,5A-t fogyaszt, miért ne tehetnél be egy megfelelő biztosítékot? Csak az usb-t nem olvadó, hanem elektronikus biztosíték védi. A technika mai állása mellett meg tudjad kiszámolni a maximális fogyasztást!

Ez igaz, csak a példa rossz. Csak annyit mondtál, hogy túlméretezett vezeték és hatszoros fogyasztás esetén miért ne működne. Csak nem érted. Az állítás (leíró) szerint a max. fogyasztás 0,5A lehet. Ha erre raktál 6x annyit, akkor nem működhetsz, mert hazudtál. Ha igazat mondtál, akkor jogos a fogyasztás.

A példálózások nem jók, mert konkrét eszközökről van szó. Akkor nem érdekes a "mi lehetne még?", hanem meg kell mondanod az egyes végpontokhoz tartozó konkrét (max) fogyasztást. Az usb esetén előírják a feszültség határértékeit is. Persze nem fontos mindent betartani. De azért nem volt probléma, amikor rövid vastag kábel helyett hosszú vékonyat alkalmazva füst/hibás mérés helyett hibakód jött. Ugyanennek az oka lehet az usb táp alsó határértéke is.

Az áramkorlát egy biztonsági funkció, így nem látom értelmét annak, hogy a tervezőnek pontosan meg kelljen határoznia a maximális áramfelvételt, majd a driverrel közölni, hogy ennél picivel nagyobb áram esetén vegye el a tápot. Minek? Ha itt tűzveszélyes volna a 0.5 A-es korlát, akkor hirtelenjében egy eleve nagyobb áramú perifériánál, amelyik 0.5 A-t kér, már nem is válik tűzveszélyessé ugyanaz?

Egész egyszerűen a 100 mA-es limitben csak egy lehetőséget látok az elszúrásra, semmiféle kézzelfogható előnyt nem érzékelek. Ha valaki rövidre zárja a cuccot, a 0.5 A-es korlát is leold. Ha valaki 220 mA-rel terhel, akkor egészségére, a host 0.5 A-ig állja a sarat.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Eredeti ötlet! :)
Szóval egér, kamera, szivargyújtó, lámpa ÁLLJ! Felpörgetem a diszket és bootolok egy jót. Van ilyen szoftver, pl. a NASA űrhajó flottánál alkalmazza (vagy akár harci drónok csapata is jó példa). Úgy hívják közös erőforrás és feladat menedzsment. Nekem elég régi az alaplapom, még nem fut rajta ilyen szoftver. Talán majd az usb 6 szabvány tud majd ilyet. ;) Addig meg ha túlterhelted a gépet, jöhet a külső táplálás. Meg aztán ott vannak az usb szabványok. Összességében az is jó néhány ezer oldalt tesz ki. Elég, ha azt betartod.

Nem azt mondom, hogy az áram mérése butaság volna, csak azt, hogy pusztán áram alapján különböző eszközöket különböző limitek alkalmazásával kikapcsolni. A logból az a gyanúm, a kérdező épp ezt szívta most meg.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az eszköz fogyasztása alapján ez nem valószínű. Nézegetve a hasonló hibákat már egy max. 20mA fogyasztású pic is előidézett hasonlót. Általában bios beállítás, driver beállítás, bios frissítés esetleg kábel csere a megoldás. Ráadásul 64bites linuxon tipikus ez a hiba.
Poénként: Elővettünk egy régi, saját fejlesztésű eszközt (nem én voltam! ;)), és meg se nyekkent. Az oka egy régi Mikroelektronika vid:pid. Windows frissítés után megjavult, mert éppen frissítette az usb adatbázist. Egyébként kedvelem a soros portot, i2c-t meg még hálózati kapcsolatot is. Az usb meg egy nagy katyvasz. Uff!

Túl időtállót, jót akartak csinálni, aztán annyira elbonyolították az egészet, hogy jóérzésű embernek az életkedve is elmegy tőle. A hőmérőm hibátlanul megy, de az USB stack nem az én érdemem, én csak addig szögeltem, amíg sikerült lefordítani és a saját assembly IT és alapszintű rutinokat beleintegrálni a környezetbe. Ettől még nem érzek ellenállhatatlan vonzalmat az USB iránt.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Imádkoztam már hozzá elég sokat, mégsem akar játszani :) (igen, amúgy plug and play)
Az "Y" kábel jó ötlet, megpróbálok majd egyet szerezni, meg egy rövidebb USB kábelt is, a jelenlegi 2,ami itt van, azok 1 méteresek (igaz az egyik még a hozzá adott "gyári" kábel).

probald meg a 4.11-es kernelt. abban javitottak az usb drivereket.
(pl az en dvb-c stickem is azzal javult meg)

vagy hasznalj egy regi 4.8-ast

Próbáltad úgy, hogy először rádugod USB-n és utána kapcsolod be a gépet?

UP

Sajnos úgy néz ki,hogy mégis az eszköz a hibás. Mivel 4.11 kernel még mindig nincs Arch-ban, így behoztam munkahelyre tesztelni és már a Windows-os gépek sem ismerik fel, pedig előtte 2 héttel még simán működött.
Esetleg tudtok ajánlani valakit Bp-n, aki ránézne (mondjuk pár kézműves sörért cserébe,vagy munkadíjért,ha nem szereti a sört), hogy hátha csak valami egyszerűbb, könnyen megoldható baja van (pl csak az USB csatlakozó hibás)? Mert nem feltétlenül dobnám ki.

Egyik IC sem melegszik nagyon? Nem állhat a probléma mögött a latch-up jelensége? A CMOS IC-kben egy rakás p-n átmenet rakódik egymásra gyártás során, ezek akaratlanul egy tirisztort képeznek, s ha egy pillanatra megemelkedik a tápfeszültség az absolute maximum paraméter fölé, begyújt, s rövidre zárja a tápfeszültséget. A kialakult nagy áram és disszipáció miatt pedig tönkremegy.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

UP
mivel közben lett 4.11-es kernel, behoztam megint kicsit játszani,hátha sikerül elérni valamit.

mégsem halt meg teljesen,azonban csak Dell brand gépeken hajlandó működni (Optiplex 3040 van itt kéznél). Azon viszont Windows 7-en, Windows 10-en és Linux (Ubuntu/openSuse) gond nélkül működik azonnal. Az összes többi gépen (Lenovo brand,HP brand, Lenovo laptop, többféle különböző custom összeállítás) nem működik. Windows alatt ismeretlen eszköz, Linux alatt a fent említett hibát generálja.

Szóval,bárkinek ötlet,hogy mit csinálhat rosszul a Dell? :)

Nem lehet, hogy táp probléma? Feltételezés: mi van akkor, ha az eszköz 100 mA-t kér bejelentkezéskor, de többet vesz fel valójában, így lekapcsolják a tápját, s a Dell gép valóban hibásan nem foglalkozik az üzenettel, csak 500 mA-nél korlátoz? Ez az a sajátságos helyzet lenne, amikor valóban a hiba okozná a helyes működést.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

passz, sajnos én ennyire nem értek a témához. de régebben akkor miért működött gond nélkül? (persze ez költői, mert nyilván a DAC oldalán lehet gond,csak azt nem tudom kideríteni,hogy valami egyszerűbb esetleg, vagy sem)

http://nwavguy.blogspot.hu/2012/04/odac-released.html
a tech section rész alatt vannak konkrét információk magáról a kütyüről. esetleg,ha van egy kis időd mátnéznéd? hátha van olyan rész benne, ami mond neked valamit,hogy mi lehet a hiba.

A hibák olyanok, hogy szinte bármi elképzelhető. Ha például nagyon rövid időre rántja meg a tápot, s kapacitásszegény a tápfeszültségen lévő kondenzátor, egy pillanatra lecsökkenhet annyira a tápfeszültség, hogy brown-out reset-et hajt végre a mikrokontrollere, s így eldobja az USB kommunikációt. Kernel meg nézi, hogy mire fel sértődött meg az eszköz, miért nem kommunikál, s ennek következtében a kernel is kidobja a maga részéről az eszközt. Ugyanakkor USB tápra tudtommal nem tehetsz túl nagy kapacitást sem.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nekem is van eszkozom, ami neha produkal ilyet. Tobbfele okokbol is tudja ezt hozni:

- Ha USB Serialkent jelentkezik, modemmanager hajlamos raugrani, es az tud problemat okozni. Az en eszkozom eseteben pont sikerult resetelnie, minden probanal, ujra es ujra. Itt a megoldas az volt, hogy megkertem modemmanagert, ne ugorjon ra.

- Volt, hogy az USB csatlakozo beporosodott. Fujkalas megoldotta.

- Volt, hogy meglazult a csatlakozo. Ezt forrasztas megoldana, de ahhoz nincs eszkozom. Ilyenkor picit megbizgeralom a kabelt, es tobbnyire megjavul.

Persze ezek egyike sem magyarazat arra, hogy miert a Dell-ek viszik csak...

--
|8]