drivers/libusb{0,1}.c: {,nut_}libusb_open(): try to re-fetch curDevice->Vendor, Product, Serial if NULL, after claiming it by other criteria
#2571
Conversation
networkupstools#1925] Also handle "unknown 2000" assuming it is a mis-read "Eaton 9E 2000(i?)" which refused to tell libusb its vendor/product/serial strings. This may be the answer to such issues as networkupstools#1925, networkupstools#2380 (re-opened), networkupstools#2492 Signed-off-by: Jim Klimov <[email protected]>
…ools#2562] I did not find any actual mentions of plain "9E2000" without an "i", only these: https://www.eaton.com/tr/en-gb/skuPage.9E2000I.html Also prepared for "9E3000i" models while here. Signed-off-by: Jim Klimov <[email protected]>
…..}` check Signed-off-by: Jim Klimov <[email protected]>
…or, Product, Serial if NULL, after claiming it by other criteria [networkupstools#2562] Signed-off-by: Jim Klimov <[email protected]>
… check Signed-off-by: Jim Klimov <[email protected]>
…Product, Serial if NULL, after claiming it by other criteria [networkupstools#2562] Signed-off-by: Jim Klimov <[email protected]>
jimklimov
added
enhancement
USB
portability
|
Do I need to wait for checks befor compile? |
Not really, I hope. At least, if there are syntax nuances here that other OSes would complain about but your build succeeds - that would be good enough to check if the concept has merit. If there are some worse typos, a build would fail :) So far it survived a few scenarios, including on Slackware, so the likeliness of fatal typos is low :) |
|
If I not mistake 9E2000i, i - > mean: |
…networkupstools#2562] According to networkupstools#2571 (comment) Signed-off-by: Jim Klimov <[email protected]>
|
just some more info from document of 9E :
|
…ixl"/"ixlau" [networkupstools#2562] Per networkupstools#2571 (comment) Signed-off-by: Jim Klimov <[email protected]>
…networkupstools#2562] According to networkupstools#2571 (comment) Signed-off-by: Jim Klimov <[email protected]>
…ixl"/"ixlau" [networkupstools#2562] Per networkupstools#2571 (comment) Signed-off-by: Jim Klimov <[email protected]>
|
Converting to draft while this is being tested, so NUT CI won't rebuild it in vain against newer target branch as it evolves. |
|
@jimklimov Thanks for @desertwitch for compiling again , but still have |
|
i think The only change for this pr and old that now : |
|
@masterwishx : thanks, can you also get the Did you have a chance to try the idea with quirk configuration? |
I will try |
What does it mean? |
Per #2562 (comment) you could try
Maybe better google first for what such parameters do, their syntax, values, etc. |
In the plugin under "NUT Settings" set "UPS Driver Debug Level" to the highest level and then restart NUT, check the SYSLOG and post the results here. Ideally put in a text file with all the logs included. |
|
It's under /usr/libexec/nut/ on Unraid, but you don't need to call it directly if you set the debug level in the NUT Settings and restart from the GUI (then check SYSLOG). |
Thanks i got it. |
|
@jimklimov here the syslog from |
|
@desertwitch after made scan for device i think i got some more in config than in backup version , do i need this in config?
|
It doesn't matter, these are just GUI settings, you don't need to touch that configuration file. |
Thanks! So it confirms that the re-discovery of identification strings is attempted with the claimed device, but still fails: That At least, there are lots of reports named like ...which is probably the fallback in that ofter-referenced method that assigns "unknown" when nothing else helps (note the Later also I can see the likes of And, notably for your other concern, there is a ...so at least it mis-behaves consistently, whatever the root-cause :\ CC @arnaudquette-eaton : the posted log includes a HID dump with a number of "not found in lookup table" items. Would your team be able to fill in the blind spots to the mapping tables, please? |
For this, I can try it if @desertwitch can say how better to make it in unraid if it still needed? |
|
I think the code is definitely an enrichment for such situations where detection initially fails otherwise, in particular as some at first glance unimportant parameters may in fact be utilized for applying hot-fixes (see recent APC issue) as Jim pointed out. As to the issue at hand, even if not fully resolved, there's probably not too much more that can be done here. At least we did see some improvement, but it might also well be caused by the OS/other external factors that we're not getting much further here. |
@desertwitch do you think this can help? If so where in Unraid to add it for check? |
@arnaudquette-eaton can you please check it? |
|
Regarding quirks, Slackware manuals imply that to pass kernel cmdline arguments you'd have to edit them during boot (in loader): http://www.slackware.com/faq/do_faq.php?faq=installation For lilo or grub you can find a config file to edit ( Some systems that wrap initrd management with tools can have other config files that indirectly impact what the next kernel boot would use. |
Yes i found way to add it to Unrad but seems its not fixed the issue ... Then all seems same i got : |
|
Well, thanks for trying, and sorry it did not help. FWIW, do I think, in the time-frame I've had and with remote guess-work based development/debugging, this couple of PRs is about as much as I can do for this issue. A moderately poor follow-up hack could be to add platform-dependent optional blocks of code to call these tools or dig in sysfs, and parse the (meta)data findings from there. Arguably this is what libusb should have done for us, though. But as a stop-gap solution it might be useful. @desertwitch : another idea that I think we did not try lately is to bulid NUT against libusb-0.1 (preferably not compat, but the original different codebase), to check if it fares differently? I hope vendor representatives (wink @arnaudquette-eaton) with a more intimate knowledge of the USB stack, libusb per se, and the device behavior as not a black box for them, could figure out how NUT and |
Also like I said befor there is Unraid v7 beta2 that use newver version of lsusb but not shure if it will help... |
I can check it... |
Looks like same as was : |
|
|
Also seems no logs in usbhid-ups in this case: |
|
@jimklimov as I remember apcupsc for unraid native app for ups can show model etc and serial number: |
|
Thanks, those we have (in It does not seem that this PR would hurt, and the #2562 it includes does help with at least some aspects, so would merge. I do hope that Eaton experts would chime in after the vacation era... :) |
Yes, Sorry for my dumbing I saw libhid.c after I wrote. Also from from debug upshid in log I saw a lot of values my ups has also for eco mode etc... I also hope Eaton experts will help after vocation as @arnaudquette-eaton was already involved a little :) Also Thanks for your help in this case and your amazing work for this project and pr for 9E.
|
|
@jimklimov as I opened issue in libusb, they refer to hidapi instead libusb. Not sure what used here... |
Follow-up to #2562 so based on its code to facilitate testing right from github sources:
...otherwise same as discussed in that ticket.
It is still not clear why some devices (or libusb) fail to return this information initially, while tools like
lsusbandudevadm infosee it well; maybe permissions or something else. Either way, the guessing leap of faith for this change set is that "claiming" the USB device changes something, and we would be able to read those data points subsequently. Got only one way to find out :)CC @desertwitch @masterwishx @loso2255 @lemeshovich