portability device driver !!!!!!

hi! eveyone.


some time ago, i was porting device driver for vxworks to qnx 6.30 and
thanks a your help voluntary or unvoluntary I obtained it .

mi ploblem is the following:

while i was porting and testing the device driver, it did on pentium
IV 2.80 Ghz and !!.

well all work ok!, but when changed it to an pc with pentium IV 3.Ghz
:frowning: with the same SO QNX 6.30 some functionalities do not work . i
was cheking what’s the problem and i found the following:

when process client want write on register of the “card or
device” this send a resquest to driver then the driver return
the physical addres, now the process client map this physical addres
to your virtual space and write directly, when write all ok, but
when read :frowning: return values bads :frowning:.


anyone can say me, what happen??

why in a pc work ok and another with more power no work ok.??


thansk for your help!!!

stjosuewrote:
hi! eveyone.
while i was porting and testing the device driver, it did on pentium
IV 2.80 Ghz and !!.

well all work ok!, but when changed it to an pc with pentium IV
3.Ghz > :frowning: > with the same SO QNX 6.30 some functionalities do not work

i was checking what’s the problem and i found the following:

when process client want write on register of the “card or
device” this send a resquest to driver then the driver return

the physical addres, now the process client map this physical addres
to your virtual space and write directly, when write all ok, but
when read :frowning: return values bads :frowning:.

anyone can say me, what happen??

Well your description of how your driver works is very odd. It seems
like you are returning to the client an address that has some
hardware meaning, either memory mapped I/O or just some memory shared
with the hardware device. This itself is usually bad design. When
you write a driver, you usually isolate the application from the
hardware code, but in your case, the client (if I understand you
properly) would write directly to hardware memory. Instead it would
make sense for the client to send any data to be written to the
hardware to the driver.


why in a pc work ok and another with more power no work ok.??

There are many possible reasons. The most obvious one to look for is
a race condition in the driver. You might also be making some
hardware assumptions in one machine, such as IRQ number, which is
only true on one piece of hardware. The obvious 1st step in
debugging is to find out where the internal results of the
non-working hardware differ from the results in the working hardware.
If you get halfway through a hardware transaction, then a race
condition becomes more likely. If the hardware doesn’t seem to
respond at all, maybe it isn’t (I/O ports, IRQ’s, DMA) where you
think it is.