General serial communications issues

[James Courtier-Dutton]

Eric Pouech wrote:
>> The next time the app calls read, wine sets off a new (now making it 
>> two) FILE_AsyncReadService, but clears the buffer first, so all the 
>> characters received from the previous FILE_AsyncReadService get lost.
> 
> it seems the event to be signaled when something is done in the first 
> read is never set, hence the application not reading the content of the 
> buffer.
> 
> can you send me the trace generated with the latest patch ?
> A+
> 
> 

I attach 2 log files.
One is the latest wine cvs (before)
The other is after applying your comm.diff patch (after)

The setup now is: -
2 PCs. With serial link between them
Log taken with this command:
On PC 1:
WINEDEBUG="+comm,+file,+ntdll" wine ttermpro.exe 2>after-patch.txt
On PC 2:
kermit

kermit is a native linux app.
I type "test1" then press ENTER on the kermit terminal, so 6 chars sent.
Nothing appears on the destination terminal, although you can see the 
chars hitting wine. No chars are reaching the windows app.
trace:ntdll:FILE_AsyncReadService 0x43bdf8 0x43f080
trace:ntdll:FILE_AsyncReadService read 1 more bytes 1/1024 so far
trace:ntdll:FILE_AsyncReadService 0x43bdf8 0x43f080
trace:ntdll:FILE_AsyncReadService read 1 more bytes 2/1024 so far
trace:ntdll:FILE_AsyncReadService 0x43bdf8 0x43f080
trace:ntdll:FILE_AsyncReadService read 1 more bytes 3/1024 so far
trace:ntdll:FILE_AsyncReadService 0x43bdf8 0x43f080
trace:ntdll:FILE_AsyncReadService read 1 more bytes 4/1024 so far
trace:ntdll:FILE_AsyncReadService 0x43bdf8 0x43f080
trace:ntdll:FILE_AsyncReadService read 1 more bytes 5/1024 so far
trace:ntdll:FILE_AsyncReadService 0x43bdf8 0x43f080
trace:ntdll:FILE_AsyncReadService read 1 more bytes 6/1024 so far

I think that the results are almost identical, with and without your patch.

I think the problem is more due to wine/dlls/kernel/file.c:339 function 
ReadFile() and wine/dlls/ntdll/file.c:399 function NtReadFile()

With it calling at wine/dlls/ntdll/file.c:442
  if (!(ovp = RtlAllocateHeap(GetProcessHeap(), 0, sizeof(async_fileio))))
I think that it should only call this once the first time NtReadFile() 
is called, and then just remember it for future read calls.

And also setting
io_status->Information = 0;
in too many places.

io_status->Information  should be set to 0 initially, and then let 
FILE_AsyncReadService() increase it when chars are received.

Then, only let the NtReadFile() set io_status->Information=0; when it 
actually sends the chars to the application.

If NtReadFile() is called with io_status->Information > 0, i.e. some 
chars have arrived, it should return those chars to the application.
Instead it is just setting io_status->Information=0; which effectively 
gets it to forget all the chars that FILE_AsyncReadService() has 
buffered up.

So, I think that we should some how store the ovp details in the file 
handle structure, so that it is remembered in between NtReadFile calls.

If you can give me some pointers as to how best to remember the ovp 
state between NtReadFile calls, I could do some more tests.

Well, that is my diagnosis of the problem, you might have other ideas.

Cheers
James
-------------- next part --------------
A non-text attachment was scrubbed...
Name: comm-diff-logs.tar.bz2
Type: application/octet-stream
Size: 12637 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20040602/7d66fbf5/comm-diff-logs.tar.obj