Re: Problems with USB

Sir:

Lars Erdmann wrote:
William L. Hartzell schrieb:
Sir:

Lars Erdmann wrote:
Hallo,

If you are going to look into USBD.SYS driver, look for a place where the USBMON.EXE daemon would hook to find endpoints. Somewhere there abouts is a bug in that if an endpoint is active before the daemon is active, a wild pointer writes all over (in random locations) the kernel when the daemon attempts to hook the driver.

Hm, the USBD.SYS driver does not have any IOCTL Routine so USBMON.EXE certainly does not call into USBD.SYS directly. Maybe indirectly, via USBPRT.SYS and then, the USBD.SYS IDC entry point (the only USBMON.EXE that is executing here is the one in the \OS2 directory, which is the one to detect printer attach/detach).


I have two copies of USBMON.EXE running: one with USBPRT parameter and one without it. The one without any parameters is labeled 'Removable device monitor v1.1', and the other is labeled 'USBPRT auto monitor' (in the startup folder). Mine resides in /os2/boot. Where it hooks, I don't know. I assumed that the USBD.sys driver would know first about (all) devices (endpoints) being added or removed. BTW, the problem with the controller would be in OHCI driver, the one that is not being loaded(?) because the controller is not (working, found, has irq problems, etc.). Theseus4 under system info->device drivers should tell you if the driver is loaded. Of course, being loaded does not mean working as a driver may not be unloaded if it has failed (hooked irq chain).

1.) Straight eCS 1.2 MR installation: I have \OS2\USBMON.EXE running through start up (this is the Printer monitor) and then I have \ECS\BOOT\USBMSDD.EXE running through start up (this is the removable device monitor, called "Mount daemon").
If it resides in OS2\BOOT then you are probably using Warp 4 or eCS 1.1 (?).
Well in that case you mean the removable devices monitor. That probably communicates with USBMSD.ADD. USBMSD.ADD offers IOCTLs to register and deregister a status and an eject semaphore with USBMSD.ADD. So obviously, USBMSD.ADD can set event semaphores on a device eject or on a status change. But that code looks ok (it protects itself against a not yet registered semaphore where the semaphores have been initially created by the calling application).
However you haven't really described in detail what problem you have.
The system experiences lock up in that it stops. As far as I can tell these lock up happen after processing of config.sys. Some lockups only trash the WPS (ie the mouse can move). Other times nothing works (red switch time). It was pointed out to me by another that he has similar problem if his USB printer was powered on at boot time. I have an always on USB scanner (Epson Photoperfection 2400 PHOTO). So I disabled it (unplug the USB cable). My frequent crashes stopped (well, the crash with the requester still happens if I start anything else while the requester is initializing). Nothing in popuplog.os2 or any other log related to this USB crash. I assume that the problem is a wild pointer in some device driver running in kernel mode, a situation that is only triggered by the first call to find endpoints by the WPS daemon. Easy to test problem. Turn on your USB printer before you boot and see if the frequency of crashes at WPS load time increases(eg from seldom to more than you'd like).

2.) All driver instances load well, Theseus4 shows me 3 OHCI instances and 1 EHCI instance.

By the way: the host controller drivers as well as the class device drivers only direct calls towards USBD.SYS (well the host controller drivers also serve the real HW interrupt)
Which would be why they could not be unloaded if the controller is failed at Init Complete time.
.. But that's about it. So yes,
USBD.SYS knows about all the endpoints as is informed by the host controller drivers when a device is attached or detached. I don't really know what the class device drivers do (USBPRT.SYS, USBMSD.ADD, USBKBD.SYS) nor how the HID (human interface device) driver comes into play. I guess I will need to read the whole OS/2 USB spec from the OS/2 DDK.


All my DDK USB sources date from 1998. It is good to know that eCS 2.0 will be using a different daemon than the version in 1.0 (maybe the bug has been by-passed). The USB device chain is simple division of tasks so that one driver is handling only one task. The controller driver only handles the controllers. The class drivers handle only that class of endpoint equipment. The USBD driver is the glue driver. HID driver is just another class driver. What is hairy is the IDC hooks into legacy drivers to capture the command flow and to route the data flow. BTW, the class of endpoints follow the PCI class division scheme.
--
Bill
Thanks a Million!
.

Relevant Pages

  • Re: usbser.sys throughput problem
    ... The speeds are in kilo bits per seconds. ... The endpoints that I use for sending and receiving data are configured ... And there is no other USB device attached to the same host ... About writing my own driver, I'm trying to avoid that as much as ...
    (microsoft.public.development.device.drivers)
  • Re: Switching device types in a USB device
    ... Enumerate as V1.1 device with next to no endpoints. ... Having seen USB 2.0 systems wait for the USB V1.1 transfer to complete ... If it stays in sync (driver and device) it is fine, ...
    (comp.arch.embedded)
  • Re: Simtec USB driver examples
    ... > Is there any driver for a device, under the Simtec USB stack, that: ... not at all the fault of the device, but the stack has a huge amount ... > rather than as a guide to writing the low levels of a driver. ... > how to communicate with other endpoints. ...
    (comp.sys.acorn.programmer)
  • Re: WDK UMDF USB pipe api
    ... firmware for the device. ... device requests and a couple of my own requests (one read / one write ... I need to get a couple of endpoints defined / configured for bulk ... When I try to call SetPipePolicy, the driver mysteriously resets. ...
    (microsoft.public.development.device.drivers)
  • Re: AVStream Device - Isochronous or Bulk
    ... driver switch b/w the different endpts and the best solution would be to have ... is there a way to switch between the different endpoints? ...
    (microsoft.public.development.device.drivers)