Resource temporarily unavailable

[Rein Klazes]

On Wed, 5 Dec 2001 11:32:13 -0500 (EST), in
comp.emulators.ms-windows.wine lawson_whitney at juno.com wrote:

> On Wed, 5 Dec 2001, T REX wrote:
> 
> > Hmm well it is a posibilty, the weird thing here is that the Thinkboxx
> > does not use hardware flow controll, this i know since the serial cabel
> > suplied only has three pins where two are data and one is ground.
> 
> It is basically impossible for linux to transfer data over such a cable
> if hardware flow control (CRTSCTS) is enabled.  A write may succeed, but
> no data will go out the serial line until CTS comes up, and with only 3
> wires, there is none for it to come up on.
> 
> > I think that the lacking support may be conusing the error, but why does it
> > work under windows when hardware flow controll is not available.
> > The program must be relaying on software flow controll,
> > does windows use software flow controll that emulates DTS/DTR signals.
> 
> Seems I saw in a trace it asks for hardware flow control.  Unless there
> are 2 different comm devices in this piece, here it was:
> 
> | 0806d898:Call kernel32.SetCommState(00000060,406150ac) ret=0043e017
> | trace:comm:SetCommState handle 96, ptr 0x406150ac
> | trace:comm:SetCommState bytesize 8 baudrate 9600 fParity 0 Parity 0
> | stopbits 1
> | trace:comm:SetCommState ~IXON ~IXOFF
> | trace:comm:SetCommState CRTSCTS
> | warn:comm:SetCommState DSR/DTR flow control not supported
> | 0806d898:Ret  kernel32.SetCommState() retval=00000001 ret=0043e017
> 
> | 'flow control not supported'. This could be the reason.
> | I have no idea why it's not supported - I suspect a system-related
> | reason, if  there is no api available to managed this stuff in the
> | Linux Api, for example.
> 
> | Gerard
> _______________________________________________
> | /gp/pine/wine-users byte 430933/509199 84%
> 
> Flow control as practiced by linux (CRTSCTS) is supported and works.
> We don't know what DSR/DTR is 'spoze to do, so it isn't.  Most windose
> apps seem to ask for both, as this one does, even though the cable makes
> it impossible for either of them to work.  Maybe hardware flow control
> is a stub in windose?

Hmm, it is this snippet that does the warning.

	if (lpdcb->fDtrControl == DTR_CONTROL_ENABLE)
	  {
             WARN("DSR/DTR flow control not supported\n");
	  }

But in the preceding COMM_BuildOldCommDCB() call the default case is
selected:

	} else {
		lpdcb->fInX		= FALSE;
		lpdcb->fOutX		= FALSE;
		lpdcb->fOutxCtsFlow	= FALSE;
		lpdcb->fOutxDsrFlow	= FALSE;
		lpdcb->fDtrControl	= DTR_CONTROL_ENABLE;

I don't have the time right now to fully look at this, but I feel that
the first DTR_CONTROL_ENABLE should really be DTR_CONTROL_HANDSHAKE.
The latter specifies flowcontrol (flow is stopped if buffers get
full), the former just specifies to set the DTR line high.

Something similar a few lines above in the code where:

		lpdcb->fRtsControl == RTS_CONTROL_ENABLE
	)
	  {
	    port.c_cflag |= CRTSCTS;
	    TRACE("CRTSCTS\n");
	  }

perhaps the RTS_CONTROL_ENABLE should be RTS_CONTROL_HANDSHAKE? 

This would explain why in this case crtcts flowcontrol gets enabled on
a 3 wire serial link.

Rein.
-- 
Rein Klazes
rklazes at xs4all.nl