kernel/comm.c - page fault in thread
Uwe Bonnes
bon at elektron.ikp.physik.tu-darmstadt.de
Wed Nov 9 08:42:34 CST 2005
>>>>> "Cihan" == Cihan Altinay <cihan at uq.edu.au> writes:
Cihan> Uwe Bonnes wrote:
>>>>>>> "Cihan" == Cihan ALTINAY <cihan at uq.edu.au> writes:
>>
Cihan> Hi again, Sorry for the double post and the stupid default
Cihan> From-Header (not my machine). I replaced my modified comm.c with
Cihan> the latest CVS, made the changes as described below and still got
Cihan> communication errors (the device replies that commands are
Cihan> malformed). So I attempted to apply the changes I made one-by-one
Cihan> to see when the errors disappear. And the first (and easiest)
Cihan> change helped: When replacing both tcflush(fd,TCOFLUSH) by
Cihan> tcdrain(fd) in the PurgeComm function all errors disappear and
Cihan> the program works as expected. Now, I know that the two
Cihan> functions do different things and according to the API
Cihan> specification of PurgeComm tcflush seems more appropriate. So I
Cihan> wonder if this is not really a fix but only a workaround for a
Cihan> different problem (maybe a race condition as mentioned earlier?).
>>
Cihan> I know that G-Ware does some funny (stupid?) things and there are
Cihan> always at least 2 threads running that poll for input/output. One
Cihan> effect is that it still opens ~200 file handles to the port but,
Cihan> more importantly, maybe they interact in a way it shouldn't
Cihan> happen?
>> Obvious my WaitCommEvent implementation is not right for G-Ware
>> (b.t.w.: any pointers to a dwonloadable version?). Can you write test
>> case for to show where the current implementation is at fault? Maybe
>> the server needs to be involved...
Cihan> You can find G-Ware 5.0.6 here as posted in the first message:
Cihan> http://www.clearone.com/docs/downloads/G-Ware5.0.6.zip [20MB]
Cihan> However, without a suitable echo canceller device there is
Cihan> probably not much you can see. If you like I can send a short log
Cihan> of the input/output behaviour under windows and under wine to
Cihan> show the difference (basically the input seems to accumulate more
Cihan> under wine and it happens more often that we read >200 bytes at
Cihan> once whereas this doesn't happen under windows). I would like to
Cihan> write a test case but we don't have 'real' Windows [here at
Cihan> university]. Instead, we were using VMWare up till now just to
Cihan> get this program running (that's why it's so important for us to
Cihan> be able to use wine).
If tests show a difference in behaviour betweem Wine and VMWare, I guess
wine will be wrong. I can than test with my XP machine, if you send me the
test.
Cihan> In regards to this I found out something else today while
Cihan> testing: When I run the program under wine with the changes
Cihan> applied I mentioned before, then everything works fine. Starting
Cihan> vmware with a serial port enabled and closing it down again and
Cihan> trying to run G-Ware under wine again breaks things: I get
Cihan> 'Timeout' errors and the like. It took me a while to see the
Cihan> reason: Under wine I get extra bytes inserted in the data and a
Cihan> check of the serial parameters shows why - vmware enables the
Cihan> INPCK flag of the serial port when exiting (who knows why) and
Cihan> wine doesn't reset the the flags but only OR's and AND's it with
Cihan> flags needed. I would say vmware is not behaving correctly but
Cihan> on the other hand we never set the input flags to a fixed state
Cihan> which makes things unpredictable. Any comments?
Here the test would be: Open the port, set the INPCK flag. Then close it and
then try to provoke the error you observe.
I guess wine should reset the parity check flag...
Bye
--
Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
More information about the wine-devel
mailing list