Author Topic: Hardware Explorer  (Read 42367 times)

Digi

  • Jr. Member
  • **
  • Posts: 59
  • Karma: +3/-0
  • http://os2.snc.ru/
    • View Profile
    • OS/2 ports and applications
Re: Hardware Explorer
« Reply #30 on: February 06, 2020, 04:59:40 pm »
Executing the usbresm.exe locks my computer up big time  which also requiries a hard boot.

Perhaps this is due to usbresmg.sys driver problems on your system. Make sure that this driver and other USB drivers (USBEHCD.SYS ?) are from the same source (Lars Erdmann / eCS / ArcaNoae) and same version. You can use the bldlevel utility. Look in config.sys where USBRESMG.SYS is loaded from.

Digi

  • Jr. Member
  • **
  • Posts: 59
  • Karma: +3/-0
  • http://os2.snc.ru/
    • View Profile
    • OS/2 ports and applications
Re: Hardware Explorer
« Reply #31 on: February 06, 2020, 05:04:26 pm »
This is as much as I can get before it locks the computer.

Devices 3

Device 1   Resource Manager handle: 0x3757
Calc. length 102
Vendor device: release: 044D:C52B:1203

This tells me that the usbresmg driver hangs on an IOCTLF_ACQUIREDEVICE request.
« Last Edit: February 06, 2020, 05:16:45 pm by Digi »

David Graser

  • Hero Member
  • *****
  • Posts: 869
  • Karma: +84/-0
    • View Profile
Re: Hardware Explorer
« Reply #32 on: February 06, 2020, 05:13:45 pm »
Executing the usbresm.exe locks my computer up big time  which also requiries a hard boot.

Perhaps this is due to usbresmg.sys driver problems on your system. Make sure that this driver and other USB drivers (USBEHCD.SYS ?) are from the same source (Lars Erdmann / eCS / ArcaNoae) and same version. You can use the bldlevel utility. Look in config.sys where USBRESMG.SYS is loaded from.
There is only one USBRESMG.SYS on my system.  This is the bldlevel output.


Digi

  • Jr. Member
  • **
  • Posts: 59
  • Karma: +3/-0
  • http://os2.snc.ru/
    • View Profile
    • OS/2 ports and applications
Re: Hardware Explorer
« Reply #33 on: February 06, 2020, 05:21:51 pm »
Executing the usbresm.exe locks my computer up big time  which also requiries a hard boot.

Perhaps this is due to usbresmg.sys driver problems on your system. Make sure that this driver and other USB drivers (USBEHCD.SYS ?) are from the same source (Lars Erdmann / eCS / ArcaNoae) and same version. You can use the bldlevel utility. Look in config.sys where USBRESMG.SYS is loaded from.
There is only one USBRESMG.SYS on my system.  This is the bldlevel output.

Compare it with bldlevel data for ?:\OS2\BOOT\USBEHCD.SYS

David Graser

  • Hero Member
  • *****
  • Posts: 869
  • Karma: +84/-0
    • View Profile
hwmanager testing results
« Reply #34 on: February 06, 2020, 06:29:59 pm »
I am having to start another post because I have been locked out of responding to the hwmanager explorer topic.

I have 3 ArcaOS partitions.  Two of the partitions use Lars latest USB drivers.  USBresm.exe works fine on these two partitions.  So does hwmanager explorer.

It is only on the partition that uses ArcaOS latest USB 32 bit drivers does the problem occur of the usb testing tools locking up the system. 

This partition also has os4 kernel. I could be wrong, but I don't think this is the problem.

The build levels match for the USB 32 bit drivers.

Has anyone else tested USBresm.exe with ArcaOS's latest 32 bit drivers?

David
« Last Edit: February 06, 2020, 06:32:53 pm by David Graser »

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4775
  • Karma: +99/-1
    • View Profile
Re: hwmanager testing results
« Reply #35 on: February 06, 2020, 06:49:44 pm »
I was wondering why there was no way to reply to that thread :)
I'm getting similar results with the OS4 kernel, testing the regular OS/2 kernel gives me a trap 3 (debug point) in usbresmg.sys with USBresm.exe displaying one line similar to you then locking hard with the OS4 kernel and an instant trap 3 with the OS/2 kernel.
All drivers match,
Code: [Select]
D:\OS2\BOOT>bldlevel usbresmg.sys
Build Level Display Facility Version 6.12.675 Sep 25 2001
(C) Copyright IBM Corporation 1993-2001
Signature:       @#Arca Noae LLC:12.03#@##1## 15 Sep 2019 09:55:01     DAZAR1
 ::::::@@USBCALLS Driver (32 bit) for OS/2 (c) 2019 Arca Noae LLC
Vendor:          Arca Noae LLC
Revision:        12.03
Date/Time:       15 Sep 2019 09:55:01
Build Machine:   DAZAR1
File Version:    12.3
Description:     USBCALLS Driver (32 bit) for OS/2 (c) 2019 Arca Noae LLC

Can't remember testing with the previous version but assume I did.

Digi

  • Jr. Member
  • **
  • Posts: 59
  • Karma: +3/-0
  • http://os2.snc.ru/
    • View Profile
    • OS/2 ports and applications
Re: hwmanager testing results
« Reply #36 on: February 06, 2020, 06:55:19 pm »
The problem is already known. There is a ticket 0002740 on the AN bugtracker.
A fixed driver USBRESMG.SYS is attached to this ticket.

David Graser

  • Hero Member
  • *****
  • Posts: 869
  • Karma: +84/-0
    • View Profile
Re: hwmanager testing results
« Reply #37 on: February 06, 2020, 07:12:48 pm »
The problem is already known. There is a ticket 0002740 on the AN bugtracker.
A fixed driver USBRESMG.SYS is attached to this ticket.

Thanks Digi!

The fix worked.  Hwmanager is now working great with ArcaOS's 32 bit USB drivers.

David

Digi

  • Jr. Member
  • **
  • Posts: 59
  • Karma: +3/-0
  • http://os2.snc.ru/
    • View Profile
    • OS/2 ports and applications
Re: hwmanager testing results
« Reply #38 on: February 06, 2020, 07:27:04 pm »
The fix worked.  Hwmanager is now working great with ArcaOS's 32 bit USB drivers.

Hardware Explorer 0.0.5 ?

David Graser

  • Hero Member
  • *****
  • Posts: 869
  • Karma: +84/-0
    • View Profile
Re: hwmanager testing results
« Reply #39 on: February 06, 2020, 07:33:08 pm »
The fix worked.  Hwmanager is now working great with ArcaOS's 32 bit USB drivers.

Hardware Explorer 0.0.5 ?

Yes, it works fine.

Martin Iturbide

  • OS2World NewsMaster
  • Global Moderator
  • Hero Member
  • *****
  • Posts: 4696
  • Karma: +41/-1
  • Your Friend Wil Declares...
    • View Profile
    • Martin's Personal Blog
Re: Hardware Explorer
« Reply #40 on: February 07, 2020, 01:59:02 am »
Moderator's Note: I don't know what happened or why the first thread got locked. I had merged the two threads. Maybe it was a mistake but I will keep checking.
Martin Iturbide
OS2World NewsMaster
... just share the dream.

Wim Brul

  • Sr. Member
  • ****
  • Posts: 295
  • Karma: +25/-0
    • View Profile
    • Wim's home page
Re: Hardware Explorer
« Reply #41 on: February 09, 2020, 04:24:41 pm »
Hi Digi,

When I invoke Hardware Explorer 0.0.5 from System Setup then its tree view display is not stable. It sort of flashes every 2 seconds. I think it has to do with the new function "If the USB device is not found in the USB.IDS file, then the name consists of data taken from the device itself". The title of the Properties pages of such devices flash every 2 seconds too. I have several of such devices. I have attached 2 snapshots of my behringer umc204hd device. The 1st one is shown for about 2 seconds and the 2nd one (not easy to capture) is shown as a brief flash. It happens both on ArcaOS 5.0 and eComStation 2.0 with Lars Erdmann 10.232 drivers.

Wim   

Lars

  • Hero Member
  • *****
  • Posts: 1268
  • Karma: +65/-0
    • View Profile
Re: Hardware Explorer
« Reply #42 on: February 09, 2020, 07:39:12 pm »
I can say from my own experience that it is a bad idea in general to directly reread descriptors over and over again.
USBD.SYS caches the device and the configuration descriptor which can always be queried by USBRESMG.SYS.
If it is attempted to read a string descriptor (for example to get a manufacturer name or a device name), you need to be aware of that it often is unstable (don't ask me why) and also that there is a chance that either no string descriptor exists (string id = 0), or worse, the device descriptor reports string ids <> 0 but still has no string descriptors to offer. It's a mess, as everything else with USB.

I guess THAT is the reason why someone came up with the idea to create usb.ids and I would not be surprised if Linux ONLY uses this static info to return device and manufacturer name instead of querying string descriptors.

There is also a logical FLAW in USBRESMG.SYS in that it gets totally confused if two attached devices have the very same vendor and product id (yes, this happens, even with devices that look completely different !).
That typically leads to hangs/crashes when reading string descriptors. Would need to rewrite/change USBRESMG.SYS to also take the serial number into account (I think there even is a shitty Microsoft specific descriptor for that) to distinguish devices but oh well …

Lars

Digi

  • Jr. Member
  • **
  • Posts: 59
  • Karma: +3/-0
  • http://os2.snc.ru/
    • View Profile
    • OS/2 ports and applications
Re: Hardware Explorer
« Reply #43 on: February 10, 2020, 10:24:39 am »
I can say from my own experience that it is a bad idea in general to directly reread descriptors over and over again.

You already talked about this earlier and I took into account your advice by minimizing the use of USBRESMG. Description strings for each device in HwE are read only once and stored to avoid repeated calls. The USBRESM$ file handle also opens only once.
Thanks for the advice!

Lars

  • Hero Member
  • *****
  • Posts: 1268
  • Karma: +65/-0
    • View Profile
Re: Hardware Explorer
« Reply #44 on: February 10, 2020, 02:41:19 pm »
ok, caching is the correct thing to do.

That leaves us with the remaining problem: if you have 2 devices attached that happen to have the same vendor and product ids, then USBRESMG.SYS will fail on reading the string descriptor as it will then confuse one device with the other. This is true even if you only open USBRESMG.SYS once and even if you only access one USB device at a time.

These days it might also be valuable to have a look at reading string descriptor with special string id = 0xEE. That will return Microsoft specific info (an OS identifier string) and if that works, it will open the door to other Microsoft specific descriptors, amongst those also a serial number. I seem to remember. All manufacturers will be forced to go the Microsoft way anyway (it already started with WinXP and the latest service pack).

Please note that reading the string descriptor for "device serial number" (iSerialNumber value in device descriptor) will not be possible most of the times because there are a lot of devices that do not provide a serial number in a string format (iSerialNumber = 0 for these devices).