Discussion:
Problems with USB
(too old to reply)
Lars Erdmann
2007-06-13 22:41:56 UTC
Permalink
Raw Message
Hallo,

I am no expert on USB so:

my system has 4 USB hubs, 3 being OHCI and 1 being EHCI. Therefore I
have loaded 3 instances of USBOHCD.SYS and 1 instance of USBEHCD.SYS in
config.sys in this sequence:
BASEDEV=USBEHCD.SYS
BASEDEV=USBOHCD.SYS
BASEDEV=USBOHCD.SYS
BASEDEV=USBOHCD.SYS
(BASEDEV=USBD.SYS)


The system has a built-in card reader (which I think hooks onto USB,
right ?), 3 USB jacks on the front and 2 USB jacks on the back.
The cardreader works, the 2 USB jacks on the back work but from the 3
front USB jacks, only 1 works while the others do not.

Question: How can I find out what USB jacks/card reader slots hook onto
what USB hub ? If I knew, that would give me a starting point if
USBOHCD.SYS is doing wrong or USBEHCD.SYS is doing wrong.


P.S: everything is working under Win XP.


Lars
Peter Brown
2007-06-14 14:47:12 UTC
Permalink
Raw Message
Hi Lars
Post by Lars Erdmann
Hallo,
my system has 4 USB hubs, 3 being OHCI and 1 being EHCI.
Possible confusion: You are actually talking about Controllers, not Hubs.


Therefore I
Post by Lars Erdmann
have loaded 3 instances of USBOHCD.SYS and 1 instance of USBEHCD.SYS in
BASEDEV=USBEHCD.SYS
BASEDEV=USBOHCD.SYS
BASEDEV=USBOHCD.SYS
BASEDEV=USBOHCD.SYS
(BASEDEV=USBD.SYS)
The system has a built-in card reader (which I think hooks onto USB,
right ?), 3 USB jacks on the front and 2 USB jacks on the back.
The cardreader works, the 2 USB jacks on the back work but from the 3
front USB jacks, only 1 works while the others do not.
Question: How can I find out what USB jacks/card reader slots hook onto
what USB hub ? If I knew, that would give me a starting point if
USBOHCD.SYS is doing wrong or USBEHCD.SYS is doing wrong.
I was going to ask if they were connected but the next line stops that
train of thought...
Post by Lars Erdmann
P.S: everything is working under Win XP.
Lars
Please tell me that this line shown above

(BASEDEV=USBD.SYS)

does not really look like that in the config.sys file. It is an entry
for the usb hub controller driver which handles all the hubs...

As you seem to have some working I guess that is not the answer though.


It may be an idea to post all config.sys usb entries.

It may help to use USBcfg to configure the usb bits
http://hobbes.nmsu.edu/pub/os2/system/usbcfgb7a.zip

The Hardware Manager in Tree View does not really give any answers as to
what ports are connected to which hubs; nor does SysInfo/2. I think the
answer may only be available by reading the circuit design of the mainboard.

Regards

Pete
Lars Erdmann
2007-06-15 16:56:53 UTC
Permalink
Raw Message
Post by Peter Brown
Hi Lars
Post by Lars Erdmann
Hallo,
my system has 4 USB hubs, 3 being OHCI and 1 being EHCI.
Possible confusion: You are actually talking about Controllers, not Hubs.
Correct. I was confused, I meant controllers.
Post by Peter Brown
Therefore I
Post by Lars Erdmann
have loaded 3 instances of USBOHCD.SYS and 1 instance of USBEHCD.SYS
BASEDEV=USBEHCD.SYS
BASEDEV=USBOHCD.SYS
BASEDEV=USBOHCD.SYS
BASEDEV=USBOHCD.SYS
(BASEDEV=USBD.SYS)
Please tell me that this line shown above
(BASEDEV=USBD.SYS)
does not really look like that in the config.sys file. It is an entry
for the usb hub controller driver which handles all the hubs...
It was just to indicate that I did not forget to specify USBD.SYS in
config.sys. But I don't consider USBD.SYS to be the problem but rather
USBxHCD.SYS. (in other words: forget about the brackets).
Post by Peter Brown
As you seem to have some working I guess that is not the answer though.
It may be an idea to post all config.sys usb entries.
...
DEVICE=D:\OS2\BOOT\USBPRT.SYS
REM DEVICE=D:\AMouse\USBMOUSE.SYS
DEVICE=D:\OS2\BOOT\USBMOUSE.SYS
DEVICE=D:\OS2\BOOT\USBKBD.SYS
DEVICE=D:\ECS\BOOT\USBRESMG.SYS
...
BASEDEV=USBEHCD.SYS
BASEDEV=USBOHCD.SYS
BASEDEV=USBOHCD.SYS
BASEDEV=USBOHCD.SYS
BASEDEV=USBD.SYS
BASEDEV=USBHID.SYS
...
BASEDEV=USBMSD.ADD /FLOPPIES:0 /REMOVABLES:4 /* I have a 4 slot card
reader */
REM BASEDEV=USBCDROM.ADD
Post by Peter Brown
It may help to use USBcfg to configure the usb bits
http://hobbes.nmsu.edu/pub/os2/system/usbcfgb7a.zip
Ok. I will try.
Post by Peter Brown
The Hardware Manager in Tree View does not really give any answers as to
what ports are connected to which hubs; nor does SysInfo/2. I think the
answer may only be available by reading the circuit design of the mainboard.
Hm, I can read a circuit diagram but it won't be able to track the hubs
to the controller via visual PCB board inspection.

Lars
James J. Weinkam
2007-06-15 22:30:27 UTC
Permalink
Raw Message
Post by Lars Erdmann
...
BASEDEV=USBMSD.ADD /FLOPPIES:0 /REMOVABLES:4 /* I have a 4 slot card
reader */
Are the 4 slots for different types of cards? If so, I seriously doubt you can
read more than one card at a time.
Lars Erdmann
2007-06-15 23:14:42 UTC
Permalink
Raw Message
Post by James J. Weinkam
Post by Lars Erdmann
...
BASEDEV=USBMSD.ADD /FLOPPIES:0 /REMOVABLES:4 /* I have a 4 slot card
reader */
Are the 4 slots for different types of cards? If so, I seriously doubt
you can read more than one card at a time.
Yes, it's 4 different types of cards. And yes it's possible that I
cannot read more than one at a time.
But that was not the question.

Lars
Peter Brown
2007-06-15 23:54:54 UTC
Permalink
Raw Message
Hi Lars
Post by Lars Erdmann
Post by Peter Brown
Hi Lars
Post by Lars Erdmann
Hallo,
my system has 4 USB hubs, 3 being OHCI and 1 being EHCI.
Possible confusion: You are actually talking about Controllers, not Hubs.
Correct. I was confused, I meant controllers.
Post by Peter Brown
Therefore I
Post by Lars Erdmann
have loaded 3 instances of USBOHCD.SYS and 1 instance of USBEHCD.SYS
BASEDEV=USBEHCD.SYS
BASEDEV=USBOHCD.SYS
BASEDEV=USBOHCD.SYS
BASEDEV=USBOHCD.SYS
(BASEDEV=USBD.SYS)
Please tell me that this line shown above
(BASEDEV=USBD.SYS)
does not really look like that in the config.sys file. It is an entry
for the usb hub controller driver which handles all the hubs...
It was just to indicate that I did not forget to specify USBD.SYS in
config.sys. But I don't consider USBD.SYS to be the problem but rather
USBxHCD.SYS. (in other words: forget about the brackets).
I don't know...

My knowledge of USB is fairly limited but I think the ports are
connected to the hubs and usbd.sys is the hub driver.

I think the hub passes control to whatever Controller is required for
the device that is plugged in ie if it is a 1.1 device it gets a 1.1
Controller, if a 2.0 device it gets the 2.0 Controller.

The question seems to be: Why does a USB hub that works with Windows not
work with the OS/2 USB hub driver when other hubs on the mainboard do?

What mainboard BIOS options are Enabled for USB?
Post by Lars Erdmann
Post by Peter Brown
As you seem to have some working I guess that is not the answer though.
It may be an idea to post all config.sys usb entries.
...
DEVICE=D:\OS2\BOOT\USBPRT.SYS
REM DEVICE=D:\AMouse\USBMOUSE.SYS
DEVICE=D:\OS2\BOOT\USBMOUSE.SYS
DEVICE=D:\OS2\BOOT\USBKBD.SYS
DEVICE=D:\ECS\BOOT\USBRESMG.SYS
...
BASEDEV=USBEHCD.SYS
BASEDEV=USBOHCD.SYS
BASEDEV=USBOHCD.SYS
BASEDEV=USBOHCD.SYS
BASEDEV=USBD.SYS
BASEDEV=USBHID.SYS
...
BASEDEV=USBMSD.ADD /FLOPPIES:0 /REMOVABLES:4 /* I have a 4 slot card
reader */
REM BASEDEV=USBCDROM.ADD
Nothing obviously wrong with the above.
Post by Lars Erdmann
Post by Peter Brown
It may help to use USBcfg to configure the usb bits
http://hobbes.nmsu.edu/pub/os2/system/usbcfgb7a.zip
Ok. I will try.
Well, at worst it will tell you the number of Controllers available and
how many are active and also the buildlevels of the drivers.

Might just be worth doublechecking the driver buildlevels; you should
see 10.162 against Controllers, usbd.sys, usbhid.sys and usbmsd.add if
you have the latest(last) drivers installed. If not I suspect you need
them :-)

Regards

Pete
Post by Lars Erdmann
Post by Peter Brown
The Hardware Manager in Tree View does not really give any answers as
to what ports are connected to which hubs; nor does SysInfo/2. I think
the answer may only be available by reading the circuit design of the
mainboard.
Hm, I can read a circuit diagram but it won't be able to track the hubs
to the controller via visual PCB board inspection.
Lars
William L. Hartzell
2007-06-17 02:03:35 UTC
Permalink
Raw Message
Post by Lars Erdmann
Hallo,
my system has 4 USB hubs, 3 being OHCI and 1 being EHCI. Therefore I
have loaded 3 instances of USBOHCD.SYS and 1 instance of USBEHCD.SYS in
BASEDEV=USBEHCD.SYS
BASEDEV=USBOHCD.SYS
BASEDEV=USBOHCD.SYS
BASEDEV=USBOHCD.SYS
(BASEDEV=USBD.SYS)
The system has a built-in card reader (which I think hooks onto USB,
right ?), 3 USB jacks on the front and 2 USB jacks on the back.
The cardreader works, the 2 USB jacks on the back work but from the 3
front USB jacks, only 1 works while the others do not.
Question: How can I find out what USB jacks/card reader slots hook onto
what USB hub ? If I knew, that would give me a starting point if
USBOHCD.SYS is doing wrong or USBEHCD.SYS is doing wrong.
P.S: everything is working under Win XP.
Please post the bldlevel of the above drivers. It may be that you need
to update them.
--
Bill
Thanks a Million!
Lars Erdmann
2007-06-18 19:02:32 UTC
Permalink
Raw Message
Post by William L. Hartzell
Please post the bldlevel of the above drivers. It may be that you need
to update them.
USBOHCD.SYS
USBEHCD.SYS
USBD.SYS
USBMSD.ADD
USBCDROM.ADD
USBKBD.SYS
USBHID.SYS
10.162

USBPRT.SYS
10.157

USBMOUSE.SYS
10.163


Lars
William L. Hartzell
2007-06-18 23:04:35 UTC
Permalink
Raw Message
Post by Lars Erdmann
Post by William L. Hartzell
Please post the bldlevel of the above drivers. It may be that you
need to update them.
USBOHCD.SYS
USBEHCD.SYS
USBD.SYS
USBMSD.ADD
USBCDROM.ADD
USBKBD.SYS
USBHID.SYS
10.162
USBPRT.SYS
10.157
USBMOUSE.SYS
10.163
It appears that you have the latest. Have you check the wire from the
front to the main board to see if it is still connected? On main board
a few years old would have an USB chip for some controllers and the
south bridge chip would also have an USB controller circuits. Newer
main boards all of this is in one chip, the south bridge chip, or AMD
the IO chip. Thus, checking the printed circuits is pointless. If some
ports don't work, swap around the wires to see if the problem can be
associated with pin ports on the main board (if yes, bad main board).
But if the problem follows the wires, then replace the wires. PS. have
you run the tool, hcimonit.exe, that checks how many controllers you
have and adjust the config.sys to match?
--
Bill
Thanks a Million!
Lars Erdmann
2007-06-18 23:32:30 UTC
Permalink
Raw Message
Post by William L. Hartzell
Post by Lars Erdmann
Post by William L. Hartzell
Please post the bldlevel of the above drivers. It may be that you
need to update them.
USBOHCD.SYS
USBEHCD.SYS
USBD.SYS
USBMSD.ADD
USBCDROM.ADD
USBKBD.SYS
USBHID.SYS
10.162
USBPRT.SYS
10.157
USBMOUSE.SYS
10.163
It appears that you have the latest. Have you check the wire from the
front to the main board to see if it is still connected? On main board
a few years old would have an USB chip for some controllers and the
south bridge chip would also have an USB controller circuits. Newer
main boards all of this is in one chip, the south bridge chip, or AMD
the IO chip. Thus, checking the printed circuits is pointless. If some
ports don't work, swap around the wires to see if the problem can be
associated with pin ports on the main board (if yes, bad main board).
But if the problem follows the wires, then replace the wires. PS. have
you run the tool, hcimonit.exe, that checks how many controllers you
have and adjust the config.sys to match?
[D:\]hcimonit
You have 3 PCI USB OHCI host controller(s)
You have 1 PCI USB EHCI host controller(s)

And I also had a look in WinXP.



Lars
William L. Hartzell
2007-06-19 03:41:16 UTC
Permalink
Raw Message
Sir:

Lars Erdmann wrote:
<snip>
Post by Lars Erdmann
[D:\]hcimonit
You have 3 PCI USB OHCI host controller(s)
You have 1 PCI USB EHCI host controller(s)
And I also had a look in WinXP.
FYI the ehci controller is just (or can be) a firmware (microcode)
update to the other controllers. It rides over the others. There is no
logical reason that your 2 ports should not be working under OS/2 as
they work under XP.
--
Bill
Thanks a Million!
Steve Wendt
2007-06-19 04:18:40 UTC
Permalink
Raw Message
Post by William L. Hartzell
Post by Lars Erdmann
You have 3 PCI USB OHCI host controller(s)
You have 1 PCI USB EHCI host controller(s)
FYI the ehci controller is just (or can be) a firmware (microcode)
update to the other controllers. It rides over the others.
Huh? EHCI is USB 2.0, OHCI and UHCI are USB 1.x.
William L. Hartzell
2007-06-19 06:12:18 UTC
Permalink
Raw Message
Post by Steve Wendt
Post by William L. Hartzell
Post by Lars Erdmann
You have 3 PCI USB OHCI host controller(s)
You have 1 PCI USB EHCI host controller(s)
FYI the ehci controller is just (or can be) a firmware (microcode)
update to the other controllers. It rides over the others.
Huh? EHCI is USB 2.0, OHCI and UHCI are USB 1.x.
And what does that have to do with how the effect (ehci) is implemented?
--
Bill
Thanks a Million!
Steve Wendt
2007-06-19 06:38:11 UTC
Permalink
Raw Message
Post by William L. Hartzell
Post by Steve Wendt
Post by William L. Hartzell
FYI the ehci controller is just (or can be) a firmware (microcode)
update to the other controllers. It rides over the others.
Huh? EHCI is USB 2.0, OHCI and UHCI are USB 1.x.
And what does that have to do with how the effect (ehci) is implemented?
Perhaps you meant to say that USB 2.0 is backwards-compatible with USB
1.x, but that isn't what you wrote. I don't think a USB 1.x controller
can be "upgraded" to USB 2.0 with a firmware update.
Lars Erdmann
2007-06-19 19:04:21 UTC
Permalink
Raw Message
Post by Steve Wendt
Post by William L. Hartzell
Post by Steve Wendt
Post by William L. Hartzell
FYI the ehci controller is just (or can be) a firmware (microcode)
update to the other controllers. It rides over the others.
Huh? EHCI is USB 2.0, OHCI and UHCI are USB 1.x.
And what does that have to do with how the effect (ehci) is implemented?
Perhaps you meant to say that USB 2.0 is backwards-compatible with USB
1.x, but that isn't what you wrote. I don't think a USB 1.x controller
can be "upgraded" to USB 2.0 with a firmware update.
That is not impossible. It is possible that the HW can remain unchanged
if most of USB is implemented in FW (for example FPGA).
Anyway, I have the latest FLASH update and it doesn't address the
problem that I have as everything works OK under WinXP.

Lars
Peter Brown
2007-06-20 15:15:36 UTC
Permalink
Raw Message
Hi Lars
Post by Lars Erdmann
Hallo,
my system has 4 USB hubs, 3 being OHCI and 1 being EHCI. Therefore I
have loaded 3 instances of USBOHCD.SYS and 1 instance of USBEHCD.SYS in
BASEDEV=USBEHCD.SYS
BASEDEV=USBOHCD.SYS
BASEDEV=USBOHCD.SYS
BASEDEV=USBOHCD.SYS
(BASEDEV=USBD.SYS)
The system has a built-in card reader (which I think hooks onto USB,
right ?), 3 USB jacks on the front and 2 USB jacks on the back.
The cardreader works, the 2 USB jacks on the back work but from the 3
front USB jacks, only 1 works while the others do not.
Question: How can I find out what USB jacks/card reader slots hook onto
what USB hub ? If I knew, that would give me a starting point if
USBOHCD.SYS is doing wrong or USBEHCD.SYS is doing wrong.
P.S: everything is working under Win XP.
Lars
As we seem to have established that those ports are not active when os/2
is loaded but work with windows could there be something non-standard,
"windows only", about them?

Can you get hold of a linux liveCD of some sort and see what that finds?

If the front ports are not useable when booted from the liveCD there is
a good chance that there is some "windows only" trickery involved...

What IRQs are used by the USB system under Windows? - anything on IRQ > 15?

Regards

Pete
Lars Erdmann
2007-06-20 19:41:44 UTC
Permalink
Raw Message
Hallo Peter,
Post by Peter Brown
As we seem to have established that those ports are not active when os/2
is loaded but work with windows could there be something non-standard,
"windows only", about them?
Can you get hold of a linux liveCD of some sort and see what that finds?
No, but I found out some things, see below.
Post by Peter Brown
If the front ports are not useable when booted from the liveCD there is
a good chance that there is some "windows only" trickery involved...
What IRQs are used by the USB system under Windows? - anything on IRQ > 15?
Under Windows:
4 Host Controllers:
OHCI 1: Mem: E2420000-E2420FFF, Irq 20
OHCI 2: Mem: E2421000-E2421FFF, Irq 21
OHCI 3: Mem: E2422000-E2422FFF, Irq 22
EHCI 1: Mem: E2423000-E2423FFF, Irq 23

3 Root Hubs (found out by permutation):
Root Hub 1: serves outer plug on PC back, middle plug on PC front
Root Hub 2: serves inner plug on PC back, Card Reader (all 4 slots)
Root Hub 3: serves lower plug on PC front, upper plug on PC front

Under OS/2:
OHCI 1: Mem: E2420000-E2420FFF, Irq 5
OHCI 2: Mem: E2421000-E2421FFF, Irq 12
OHCI 3: Mem: E2422000-E2422FFF, Irq 11
EHCI 1: Mem: E2423000-E2423FFF, Irq 9

4 Root Hubs (ROOT HUB DEVICES):
?

It is the lower plug on PC front, upper plug on PC front that do not
work under OS/2.

Since USBD.SYS is the hub controller, USBD.SYS is the culprit. I found
another USBD.SYS by Martin Kiewitz in package mmportv1.zip where Martin
claims it does the hub enumeration in "the Windows fashion".
Unfortunately his USBD.SYS does not work as it hangs the boot process
but that might be due to the fact that the source he included are older
than the latest available sources from IBM.

I guess if I could apply the fixes Martin did (mmportv1.zip comes with
the sources he changed) to the latest IBM source of USBD.SYS, I might
get the hub enumeration rectified and then maybe the hubs would all
work. Unfortunately I am far from being a USB expert.


By the way: the OS/2 HW Manager lists a "DEVICE" for the OHCI2,OCHI3 and
EHCI1 controller but not the OCHI1 controller. What are these "devices"
supposed to mean ? What are they compared to the "ROOT HUB DEVICE"s that
are listed under the hub controller (USBD.SYS) ? As far as I understand
the hubs should not be statically assigned to a controller as the
controllers are assigned dynamically to the hubs, depending on if I plug
in a USB1.1 (OCHI) or USB2.0 (EHCI) capable device ...




Lars
William L. Hartzell
2007-06-21 01:31:33 UTC
Permalink
Raw Message
Post by Lars Erdmann
Hallo Peter,
Post by Peter Brown
As we seem to have established that those ports are not active when
os/2 is loaded but work with windows could there be something
non-standard, "windows only", about them?
Can you get hold of a linux liveCD of some sort and see what that finds?
No, but I found out some things, see below.
Post by Peter Brown
If the front ports are not useable when booted from the liveCD there
is a good chance that there is some "windows only" trickery involved...
What IRQs are used by the USB system under Windows? - anything on IRQ
15?
OHCI 1: Mem: E2420000-E2420FFF, Irq 20
OHCI 2: Mem: E2421000-E2421FFF, Irq 21
OHCI 3: Mem: E2422000-E2422FFF, Irq 22
EHCI 1: Mem: E2423000-E2423FFF, Irq 23
Root Hub 1: serves outer plug on PC back, middle plug on PC front
Root Hub 2: serves inner plug on PC back, Card Reader (all 4 slots)
Root Hub 3: serves lower plug on PC front, upper plug on PC front
OHCI 1: Mem: E2420000-E2420FFF, Irq 5
OHCI 2: Mem: E2421000-E2421FFF, Irq 12
OHCI 3: Mem: E2422000-E2422FFF, Irq 11
EHCI 1: Mem: E2423000-E2423FFF, Irq 9
?
It is the lower plug on PC front, upper plug on PC front that do not
work under OS/2.
Since USBD.SYS is the hub controller, USBD.SYS is the culprit. I found
another USBD.SYS by Martin Kiewitz in package mmportv1.zip where Martin
claims it does the hub enumeration in "the Windows fashion".
Unfortunately his USBD.SYS does not work as it hangs the boot process
but that might be due to the fact that the source he included are older
than the latest available sources from IBM.
I guess if I could apply the fixes Martin did (mmportv1.zip comes with
the sources he changed) to the latest IBM source of USBD.SYS, I might
get the hub enumeration rectified and then maybe the hubs would all
work. Unfortunately I am far from being a USB expert.
By the way: the OS/2 HW Manager lists a "DEVICE" for the OHCI2,OCHI3 and
EHCI1 controller but not the OCHI1 controller. What are these "devices"
supposed to mean ? What are they compared to the "ROOT HUB DEVICE"s that
are listed under the hub controller (USBD.SYS) ? As far as I understand
the hubs should not be statically assigned to a controller as the
controllers are assigned dynamically to the hubs, depending on if I plug
in a USB1.1 (OCHI) or USB2.0 (EHCI) capable device ...
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.

BTW, it is queer that your machine fails to register one set of ports,
one root hub, and one controller. Maybe the controller is failing. Is
there a verbose switch that would report status?

When I look into my Hardware Manager, I see two Ehci, four ohci, & four
uhci controllers and eight root hubs. I have one add-in adapter with
half and the main board with the other half. All ports work. (I know
another not me comment.)
--
Bill
Thanks a Million!
Lars Erdmann
2007-06-23 12:45:28 UTC
Permalink
Raw Message
Hallo,
Post by William L. Hartzell
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).
Post by William L. Hartzell
BTW, it is queer that your machine fails to register one set of ports,
one root hub, and one controller. Maybe the controller is failing. Is
there a verbose switch that would report status?
Don't understand because I don't understand the difference between
ports, hubs and controllers. I don't think the controllers fail. I can
turn on the /V flags and see what I get but I am pretty sure that
USBD.SYS does not correctly enumerate the hubs or whatever (it does it
correctly according to USB spec but the "Windows" way, whatever that means).


Lars
William L. Hartzell
2007-06-23 14:42:37 UTC
Permalink
Raw Message
Post by Lars Erdmann
Hallo,
Post by William L. Hartzell
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).
Post by Lars Erdmann
Post by William L. Hartzell
BTW, it is queer that your machine fails to register one set of ports,
one root hub, and one controller. Maybe the controller is failing.
Is there a verbose switch that would report status?
Don't understand because I don't understand the difference between
ports, hubs and controllers. I don't think the controllers fail. I can
turn on the /V flags and see what I get but I am pretty sure that
USBD.SYS does not correctly enumerate the hubs or whatever (it does it
correctly according to USB spec but the "Windows" way, whatever that means).
--
Bill
Thanks a Million!
Lars Erdmann
2007-06-24 15:06:16 UTC
Permalink
Raw Message
Post by William L. Hartzell
Post by Lars Erdmann
Hallo,
Post by William L. Hartzell
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.
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). 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.

Lars
William L. Hartzell
2007-06-25 05:52:06 UTC
Permalink
Raw Message
Post by Lars Erdmann
Post by William L. Hartzell
Post by Lars Erdmann
Hallo,
Post by William L. Hartzell
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).
Post by Lars Erdmann
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,
Post by Lars Erdmann
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!
Lars Erdmann
2007-06-26 23:36:48 UTC
Permalink
Raw Message
Post by William L. Hartzell
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).
What is the loading sequence of your USB drivers, does USBD.SYS load
before the HCDs (USBOHCD.SYS,USBUHCD.SYS,USBEHCD.SYS) ?
If yes, change the order to have the HCDs load first and report results.

P.S: I have my Brother HL-5240 USB printer permanently attached and
never experienced any problems. On the other hand, the printer has a
power saving mode, it's maybe not powered on bootup ...

Lars
William L. Hartzell
2007-06-27 07:28:44 UTC
Permalink
Raw Message
Post by Lars Erdmann
Post by William L. Hartzell
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).
What is the loading sequence of your USB drivers, does USBD.SYS load
before the HCDs (USBOHCD.SYS,USBUHCD.SYS,USBEHCD.SYS) ?
If yes, change the order to have the HCDs load first and report results.
P.S: I have my Brother HL-5240 USB printer permanently attached and
never experienced any problems. On the other hand, the printer has a
power saving mode, it's maybe not powered on bootup ...
REM ******** USB ************
BASEDEV=USBOHCD.SYS
BASEDEV=USBOHCD.SYS
BASEDEV=USBOHCD.SYS
BASEDEV=USBUHCD.SYS
BASEDEV=USBUHCD.SYS
BASEDEV=USBUHCD.SYS
BASEDEV=USBEHCD.SYS
BASEDEV=USBEHCD.SYS
BASEDEV=USBD.SYS
BASEDEV=USBHID.SYS
BASEDEV=USBMSD.ADD /FLOPPIES:0 /A_USAGE:2 /REMOVABLES:5
DEVICE=C:\OS2\BOOT\USBPRT.SYS
DEVICE=D:\OA\TAME2\USBRESMG.SYS
DEVICE=D:\Ou\usb_direct\USBECD.SYS /D:051D:DDD2:0106 /N:UPS$
DEVICE=d:\ou\AMouse\USBMOUSE.SYS

Not that much different than yours. Wonder if main board's chip set or
adapter's chip set the cause?
--
Bill
Thanks a Million!
Loading...