Very strange problem

[branquinho]

Friends

My program uses a graphical library to print on the screen. I use this library for over 3 years. But now, when i run the USBUHCIL driver, i saw something be printed randomically on different parts of the screen. Considering that i have no multithreading, and wihout the driver this problem do not occurs, can someone help me to know what might be happening? May be the driver has some interrupt routine that not saves all registers, flags or something like this ? Thank you very much.

[Bret]

Hard to say exactly what it might be. I kind of doubt that something isn't getting saved in an interrupt routine, or there would have been a problem reported before now. Based on the symptoms, though, my first guess is that you might have an "I=A000-A7FF" or similar option in your EMM (EMM386/JEMM/whatever in CONFIG.SYS)?

[branquinho]

Hi Bret

Understood... my program runs over the Causeway DOS Extender. Do you think it can influence this problem ? Are there some address your driver reserves to use ?

Thank you very much.

Fernando Branquinho
From Brazil.

[Bret]

Understood... my program runs over the Causeway DOS Extender. Do you think it can influence this problem ?

It could, though I know others are using various DOS extenders and have not reported any problems like this.

Are there some address your driver reserves to use ?

Not any specific addresses. I just uses standard DOS calls to allocate blocks in either conventional or upper memory.

Your problem sounds like a memory conflict -- maybe your extended memory isn't being locked like it's supposed to be or something like that? Have you tried forcing USBUHCIL into low memory (with a "/l:Y" option)?

[branquinho]

Hi Bret

I forced USBUHCIL into low memory but the problem remains.

Running the MSD i saw that the IRQ 0 is handled by your driver. My software also handles this IRQ, and i don´t call your interrupt handler after to run my interrupt handler. Even so your driver continues reading the USB.

What kind of use you do of IRQ 0 ?

Is normal your driver continues working well, even if i override your interrupt vector ?

Do you see any kind of correspondence of this with the problem related early ?

Thank you very much and sorry for many questions about.

Fernando Branquinho

[branquinho]

Bret

I post a screen shot of the problem. I was wrong saying the program prints on randomically parts of screen. I watch it with attention, and i saw that it prints always on the same positions (these two showed on the picture).

Still very strange to me.

Regards

Fernando Branquinho

[Bret]

Running the MSD i saw that the IRQ 0 is handled by your driver. My software also handles this IRQ, and i don´t call your interrupt handler after to run my interrupt handler. Even so your driver continues reading the USB.

What kind of use you do of IRQ 0 ?

Is normal your driver continues working well, even if i override your interrupt vector ?

It sounds like you've got a few things to learn about interrupts. IRQ 0 is the clock, and is ABSOLUTELY CRITICAL to the operations of the computer. You MUST chain to it either after or before it is handled by your program, even if it isn't used by my programs. Some IRQ's must be chained, some must not be chained, and with others it depends on the situation. IRQ 0 must ALWAYS be chained.

You can look at the source code for my programs to see exactly what happens inside the IRQ 0 handler. Many, if not most, TSR's and device drivers will intercept IRQ 0, and you shouldn't even question why a TSR would do it. You just need to chain to it.

A question for you would be why do you intercept IRQ 0 in a foreground application, anyway? I can't think of a legitimate reason to do that. There are other easier ways to determine when the hardware has generated an IRQ 0 in a foreground application that don't involve manipulating the IVT.

However, I don't know if that's related to your particular problem or not. It could be.

I was wrong saying the program prints on randomically parts of screen. I watch it with attention, and i saw that it prints always on the same positions (these two showed on the picture).

You'll need to do some more troubleshooting on your end to figure out exactly when and why this extra data gets written to the screen. E.g., does this happen all the time, or just when you issue a call-back request to the USB driver? Does it do it with the USB driver installed but no USB devices plugged in? What kind of USB device(s) are you trying to control?

[branquinho]

Hi Bret

A question for you would be why do you intercept IRQ 0 in a foreground application, anyway? I can't think of a legitimate reason to do that. There are other easier ways to determine when the hardware has generated an IRQ 0 in a foreground application that don't involve manipulating the IVT.

I intercept it because my software needs to be precisally deterministic, so I increase the timer interrupt frequency (from 18.2Hz to 100 Hz). In this case the timer clock will remain stoped, so i read the hour, minutes and seconds from the Real Time Clock (RTC). I will try do not intercept the IRQ 0 and to see if the problem stops.

E.g., does this happen all the time, or just when you issue a call-back request to the USB driver?

All the time, even when i do not request anything to the driver. But only when the driver is loaded. I´m installing the driver only on the controller number 3 (USBUHCIL /Index 3). I didn´t post any code here, because the problem occurs also when no specific code about USB exist. I ran a older program, and the problem also occurs. Occurs just when the driver is loaded.

Does it do it with the USB driver installed but no USB devices plugged in?

I will try it.

What kind of USB device(s) are you trying to control?

I´m reading a touch screen device. It´s working very well. My problem is only this strange behaviour.

Bret, you can not imagine how grateful I am for your help until now. I feel that i´m very closer to find this problem. I will do the tests.

Thank you very much.

Fernando Branquinho

[branquinho]

Bret

I pluged-out all devices on controller #3, and the problem remains.

I take-off the IRQ0 interceptation, and the problem remains.

I installed the driver only on controller #2, and the problem remains.

I installed the driver only on controller #1, and the problem remains.

I didn´t install the driver on controller #0, because my USB keyboard use it.

I´m using the Causeway DOS Extender with the Open Watcom compiler.

Regards

Fernando Branquinho

[branquinho]

Bret

I pluged-out all USB devices, and the problem remains.

I wrote related informations above.

Regards

Branquinho

[Bret]

I intercept it because my software needs to be precisally deterministic, so I increase the timer interrupt frequency (from 18.2Hz to 100 Hz). In this case the timer clock will remain stoped, so i read the hour, minutes and seconds from the Real Time Clock (RTC). I will try do not intercept the IRQ 0 and to see if the problem stops.

Even if you change the rate of IRQ 0, you still need to pass control of the IRQ handler down the chain to the old handler(s) 18.2 times a second. You can't just take control of IRQ 0 and not let it ever get passed to the old handlers. IRQ 0 affects more than just what time the computer thinks it is.

Also, there are ways other than reprogramming IRQ 0 to measure 10 ms increments in a foreground application.

[branquinho]

Hi Bret

Ok. I understood. Thank you. But now i took off my IRQ 0 interrupt handler (only for test) and the problem remains.

Would you have any more ideas how to figure out what is causing this problem?

Thank you very much.

Fernando Branquinho

[Bret]

I would go through your program one step at a time, removing/modifying code to figure out exactly when and why the problem occurs. You seem to think it might be related to your graphics library, so I would start there. Does the extra stuff appear on the screen immediately after you call the graphics library to write your number to the screen, or is there a delay? What happens when you write a new number -- does the extra stuff on the screen change right away as well? What happens if you bypass your graphics library and issue an INT 10h call directly to write the number to the screen?

[branquinho]

Does the extra stuff appear on the screen immediately after you call the graphics library to write your number to the screen, or is there a delay?

There is a randomically delay (many seconds), and the extra stuff do not appears all at once , it display one digit a time. On other page where i print a bargraph, sometime the bargraph also appears on the wrong place. I told you that problem is on the graphic library, because is where i get to see. May be also we have problems on other places (i don´t know). The graphical library isn´t mine, but we have the source code. But i still suspicious about some memory conflict (like you told me).

What happens when you write a new number -- does the extra stuff on the screen change right away as well?

No. While my software write the number tens times on the right position, part of the extra stuff is wrote few times (one at 5 or 6 seconds). Example: I write 12345 on the right position. Some times appears a 4, then a 2 then a 1 and so on, until show a complete number "12345" on the wrong position.

The driver is using the interrupt 10. Is there a way to cancel this interrupt handler ?

Regards

Fernando Branquinho

[Bret]

The driver is using the interrupt 10. Is there a way to cancel this interrupt handler ?

Which driver are you talking about -- I assume USBUHCIL? Do you mean IRQ 10 (INT 72h) or INT 10h (Video BIOS Services)? If IRQ 10 and USBUHCIL, the answer is probably no -- IRQ 10 must be what the USB host controller is using. You can try changing it to a different IRQ (with the /IRQ option when you load USBUHCIL into memory), but not all USB host controllers will let you actually change it.

****************

If I understand correctly, this program works OK if you don't use the DOS extender?