IR Remote control for EmperoarTV does not work anymore with all of Lars' versions of USB drivers

[Grimus]

I use a "Microsoft Remote Control and Receiver 1.0A for Media Center PC with Windows (Philips)", an USB 1.1 device to IR remote control EmperoarTV. Used to work well with the original IBM drivers, but not at all with usbhcdxxx (any version up to recent version 176).

The device itself is seen fine in, e.g., USB Dock, also a red LED at the front indicates activity when I press buttons on the remote control, however nothing happens to EmperoarTV any more.

[Lars Erdmann]

1.) follow readme.txt in order to generate a trace and attach file here 2.) change order of USBUHCD.SYS and USBEHCD.SYS in config.sys and check if it makes a difference

[Lars Erdmann]

Also, revert back to the USBD.SYS 10.162 from IBM. The one I delivered is not ready for prime time.

[Lars Erdmann]

Get usbhcd177.zip from Hobbes

[Grimus]

PCI -D sniff output

[Grimus]

TRacing results

[Grimus]

Reverted back to the eCS USBD.SYS and updated to usbhcd177. no change - still no reaction of EmperoarTV to remote control commands.

[Lars Erdmann]

Can you get device report from USB Dock and attach here ? I would like to know if it is bulk device,interrupt device,isochronous device ...

[Grimus]

USB dock log for REmote control unit

[Lars Erdmann]

replace USBOHCD.SYS with original 10.162 IBM driver (but keep USBEHCD.SYS 10.177) and tell me if that fixes the problem.

[Grimus]

Replaced USBOHCD.SYS with the original eCS one -> no change. But I think EmperoarTV brought some version of its own. Will need to check.

[Grimus]

Actually there is an updated version of ETV/2 to increase compatibility with the new USB drivers. Now the remote control kind of works - however changing channels results in a trapd. Screenshot attached. Need to investigate further as ETV does not seem to work at all now...

[Grimus]

Trapd with new ETV/2 and using the remote control to change channels.

[Grimus]

Seems to work now. After 2 more traps and re-installs of ETV/2, remote control works again. Will observe what happens in the future but for the moment the problem seems gone with ETV/2 v 2.06c. Now have to rebuild my PMMail directory structure :-(

[Lars Erdmann]

I think I found the cause of the trap. Please try grimus.zip. I have not changed anything about the functionality. I just tried to fix the trap.

[Grimus]

Doesn't help. Trap is reproducible with changing channels quickly using the remote control. See trap screen attached. :-(

[Lars Erdmann]

Am I assuming correctly that you also experience the trap when you either use the original 10.162 IBM driver or the binary patched driver supplied by Rüdiger Ihle (the maker of EmperoarTV I believe) ?

For your info: I know where exactly it traps and I know why it traps. That's a good precondition to getting it fixed. If the original 10.162 version (and Rüdigers version for that matter) also traps it will just confirm my suspicion.

By the way: the very same error is in all 3 drivers: USBUHCD.SYS,USBOHCD.SYS,USBEHCD.SYS. The fix will therefore bring the solution to all 3 drivers.

[Lars Erdmann]

fixing a bug in IBM code: on "short packet compaction", increase phys addr. space to map to also cover src address

[Lars Erdmann]

I have updated. Please "stress test" as you already did.

[Grimus]

Looks very good so far. No traps. Can change channels, switch to full screen and back. Switch to VCR mode and to TV mode. No issues whatsoever. This is with EperoarTV 2.06c.

Let's wait a couple of days - but I think this particular issues has been solved!

[Lars Erdmann]

Ok, let's leave it open for a while. If you can provoke a "low memory/heavy swapping" situation I would like to know if everything still works ok. There is a small risk that memory gets swapped out where it shouldn't.

[Grimus]

That's hard I guess - 3.3 GB of memory are hardly ever used here. Or are you talking about shared memory?

[Lars Erdmann]

No, I am talking about forcing the system to start swapping out memory. If it's impossible - let's hope that it won't be a problem. Very maybe I can do some further analysis with the kernel debugger. Problem is, I don't have an environment where I would hit the code path were the bug showed up.

[Grimus]

OK. I can open a lot of high res pictures with PMView and see what happens then.

[Grimus]

Hi. Not yet 100% good. Now I experience traps in USBIRC.SYS, the EmperoarTV IR remote control driver. (see uploads) IS this possibly still related to the USB stack or do I need to raise this with Rudi now?

[Grimus]

Trap in USBIRC 01

[Grimus]

TRad d in USBIRC.SYS 02

[rudi]

The trap screen indicates, that a bogus data length (buffer1Length) is returned by the host controller driver. Therefore USBIRC tries to read beyond the end of it's data segment.

[Lars Erdmann]

Yes the traps are most likely related to USBOHCD.SYS (if you use an USB 1.x device which I think you do) or USBEHCD.SYS (if you use an USB 2.0 device). I understand the error but I am not yet sure why it occurs as I haven't changed anything with regard to computation of "buffer1Length". What HC driver is in use ? USBOHCD.SYS ?
Please try all combinations:
a.) USBOHCD.SYS 10.162 and USBEHCD.SYS 10.162
b.) USBOHCD.SYS 10.162 and my USBEHCD.SYS
c.) my USBOHCD.SYS and USBEHCD.SYS 10.162
d.) my USBOHCD.SYS and my USBEHCD.SYS

and tell me for each case if you experience the same trap or not.

[Lars Erdmann]

I seem to remember that EmperoarTV comes with a binary patched version of USBOHCD.SYS. If yes, use that instead of USBOHCD.SYS 10.162.

[Lars Erdmann]

reworked "FinishIO" for USBOHCD.SYS

[Lars Erdmann]

Try updated grimus2.zip. If you still get a trap it would be helpful to create a trap dump (see readme.txt in usbhcd178.zip). If it works it would still be helpful to have the tracefile (see readme.txt in usbhcd178.zip).

[Lars Erdmann]

I again updated just now. Use the latest version.

[Grimus]

So far so good - no more traps till now. Tested remote control heavily. Thanks a lot!!

[Lars Erdmann]

I am closing the ticket. When the next release comes out (usbhcd179, eventually), please retest with that new release (I just want to be sure I didn't break anything else in USBOHCD.SYS along the way. There are still other things to fix ...). I you again run into problems open a new ticket or reopen this ticket.

[Lars Erdmann]

reworked "FinishIO" for USBOHCD.SYS a second time

[Lars Erdmann]

On second thought: would you please do a final check with the newly uploaded driver ? I changed something that is not directly related to your traps but would lead to occasional hangs of USBOHCD.SYS on other occasions. I want to be sure it doesn't break anything for you.

[Grimus]

Seems to work well. Will test a little more tomorrow. But so far no traps.

[Lars Erdmann]

Forgot to mention: also test USBOHCD.SYS with memory sticks by opening large files (20 MB or bigger). For this to work you might need to disable USB 2.0 in your BIOS so that USBOHCD.SYS will be in use instead of USBEHCD.SYS.
If it is not too much hassle, also try all this (use in Emperoar TV + memory sticks) with the original IBM 10.162 USBOHCD.SYS and see if you experience the traps you have been reporting in the past.

[Grimus]

What do you mean by 'opening some 20MB files'? I can open a large movie - but the USB stick is too slow to play it smoothly. Also opened 300MB zip file with pictures while watching EmperoarTV. All with USB 2.0 disabled - works like a charm (except that USB 1.1 is slooooooow).

Will try to reproduce the traps with the original IBM driver next. BTW - now that USB 1 and 2 work very well here... what about USB 3? ;-)

[Lars Erdmann]

Replying to Grimus:

What do you mean by 'opening some 20MB files'? I can open a large movie - but the USB stick is too slow to play it smoothly. Also opened 300MB zip file with pictures while watching EmperoarTV. All with USB 2.0 disabled - works like a charm (except that USB 1.1 is slooooooow).

Want I meant was to open a large file from a USB stick. I have changed something in USBOHCD.SYS to prevent a hang when reading a large file from a USB stick. Therefore, if you have done exactly that and say that everything works OK without a hang I consider this bug closed. But a test with original USBOHCD.SYS 10.162 and the results would still be of help for me to determine if I really have nailed down the problem.

Will try to reproduce the traps with the original IBM driver next. BTW - now that USB 1 and 2 work very well here... what about USB 3? ;-)

Certainly a good idea. I haven't yet fully investigated but it might need changes in USBD.SYS and potentially in the USBxHCD.SYS drivers to still be compatible. It depends on if the new features of USB 3.0 need changes in the interfaces between the client drivers (USBMOUSE.SYS, USBKBD.SYS, USBPRT.SYS etc.), USBD.SYS and the HC drivers USBxHCD.SYS so that these new features can be exploited. And it needs new manpower as it is a new development.

[Grimus]

Tested with original IBM OHCI driver - USB 2 switched off in BIOS. Using the EmperoarTV remote control once - trap! Reverting back to the last version of your driver - everything working perfectly well.

So this particular bug is nailed! And the bug has obviously been there forever ;-)

However, I am not able to produce any trap opening big files. (with neither driver version).

Thanks a milliion times for this one!

BTW.: Teh drivers are still about 5 times the size of the release versions. I assume that they are still debug versions? Do you want me to test the release versions as well?

[Lars Erdmann]

Replying to Grimus:

Tested with original IBM OHCI driver - USB 2 switched off in BIOS. Using the EmperoarTV remote control once - trap! Reverting back to the last version of your driver - everything working perfectly well.

So this particular bug is nailed! And the bug has obviously been there forever ;-)

Ha, I knew it !

However, I am not able to produce any trap opening big files. (with neither driver version).

Good.

Thanks a milliion times for this one!

BTW.: Teh drivers are still about 5 times the size of the release versions. I assume that they are still debug versions? Do you want me to test the release versions as well?

In theory there is a small chance that the release version drivers won't work. But no, I don't see a need to explicitely test the release version. Of course I will place the release versions on Hobbes (tracing capability will nonetheless always be included but can be dynamically enabled/disabled as you most likely know).

[Grimus]

Just wanted to comment that all is well also with the new non-debug version. Thanks again!