From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1P1NK9-0000nZ-EV for mharc-grub-devel@gnu.org; Thu, 30 Sep 2010 13:53:41 -0400 Received: from [140.186.70.92] (port=37718 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P1NK3-0000mX-Tm for grub-devel@gnu.org; Thu, 30 Sep 2010 13:53:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P1NK2-00022W-L0 for grub-devel@gnu.org; Thu, 30 Sep 2010 13:53:35 -0400 Received: from smtp-out4.iol.cz ([194.228.2.92]:55702) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P1NK2-00021O-7W for grub-devel@gnu.org; Thu, 30 Sep 2010 13:53:34 -0400 Received: from antivir6.iol.cz (unknown [192.168.30.215]) by smtp-out4.iol.cz (Postfix) with ESMTP id D7FB45803C2 for ; Thu, 30 Sep 2010 17:53:31 +0000 (UTC) Received: from localhost (antivir6.iol.cz [127.0.0.1]) by antivir6.iol.cz (Postfix) with ESMTP id C2EE1720058 for ; Thu, 30 Sep 2010 19:53:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at iol.cz Received: from antivir6.iol.cz ([127.0.0.1]) by localhost (antivir6.iol.cz [127.0.0.1]) (amavisd-new, port 10224) with LMTP id Ko4ozYUx42Ld for ; Thu, 30 Sep 2010 19:53:30 +0200 (CEST) Received: from port4.iol.cz (unknown [192.168.30.94]) by antivir6.iol.cz (Postfix) with ESMTP id 9C14F72005A for ; Thu, 30 Sep 2010 19:53:29 +0200 (CEST) X-SBRS: None X-SBRS-none: None X-RECVLIST: MTA-OUT-IOL X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4MAFtrpExVRnXk/2dsb2JhbAAHhBnmQIVEBIUH Received: from 228.117.broadband3.iol.cz (HELO [192.168.6.160]) ([85.70.117.228]) by port4.iol.cz with ESMTP; 30 Sep 2010 19:53:29 +0200 From: =?UTF-8?Q?Ale=C5=A1?= Nesrsta To: The development of GNU GRUB In-Reply-To: <1284530302.6578.25.camel@pracovna> References: <4C7519E8.90907@gmail.com> <20100826230527.GA26246@pina.cat> <4C76F58D.6020304@gmail.com> <1282995082.14285.4.camel@pracovna> <4C7AF2BB.2040606@gmail.com> <4C7AF7E1.7020204@gmail.com> <1283551348.27688.89.camel@pracovna> <1283621655.4824.25.camel@pracovna> <1284312512.5714.83.camel@pracovna> <1284378479.13334.53.camel@pracovna> <1284401606.5929.3.camel@pracovna> <1284530302.6578.25.camel@pracovna> Content-Type: text/plain Date: Thu, 30 Sep 2010 19:53:27 +0200 Message-Id: <1285869208.6433.48.camel@pracovna> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) Subject: [RFC - Vladimir ?] USB/RS232 converter PL2303 small problem X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Sep 2010 17:53:38 -0000 Hi, I don't know who is developer/maintainer of USB serial drivers - I expect it is Vladimir, so this e-mail is addressed mainly to him. As I wrote in my older e-mail (Question: USB serial - device driver debugging), there is some problem with PL2303. Not with driver but with device itself (probably). What is the problem: If I put some stream of characters into PL2303, device stops accepting data and answers NAK indefinitely after some time / some amounts of character sent (256 exactly). It happens only if PL2303 is connected to another computer. If only null-modem cable is connected, it does not happen. (If no cable is connected, it happens also but in this case it is caused by missing handshaking signals which prevent sending -> output buffer overloading happens, i.e. it is in fact correct situation.) I discovered the reason - I forgot switch off "echo" on ttyS0 of PC where was cable connected. I.e. every character sent by GRUB was returned from connected PC back to input of PL2303 and input buffer was overloaded. But what is surprising for me - why stops PL2303 SENDING when INPUT buffer is full ??? ("Normal" serial port does not such thing in GRUB, it looks like it is PL2303 device speciality. I did not test FTDI, I don't have it.) Maybe such behavior can be prevented by some another pre-setting of PL2303 device - but there is no detailed documentation about PL2303 device USB interface. I thought also about some workaround - continuously check amount of characters in input buffer in device but there is problem how to do it - at least there is no related documentation of PL2303 as I mentioned above. Another possibility is periodical fetching characters from PL2303 but it should be disabled when PL2303 is used as input for terminal etc. - it looks too difficult to implement (and non-standard...). I.e. there is probably no simple way how to prevent this problem but such unexpected behavior of device should be known and probably documented somewhere - where ? Is there some place in source where to store HowTos, FAQs and some other more or less important notes ? Or should I write this information into driver source code ? Regards Ales