From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1VM3Pd-0004zq-T2 for mharc-grub-devel@gnu.org; Tue, 17 Sep 2013 18:06:25 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52965) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VM3PW-0004yq-Ch for grub-devel@gnu.org; Tue, 17 Sep 2013 18:06:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VM3PQ-0000Yi-UM for grub-devel@gnu.org; Tue, 17 Sep 2013 18:06:18 -0400 Received: from smtp.volny.cz ([2001:4de8:71c:62::33]:49789) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VM3PQ-0000XF-NN for grub-devel@gnu.org; Tue, 17 Sep 2013 18:06:12 -0400 Received: from [192.168.6.11] (unknown [193.86.90.90]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: starous@volny.cz) by smtp.volny.cz (Postfix) with ESMTPSA id 757272609FA for ; Wed, 18 Sep 2013 00:06:10 +0200 (CEST) Message-ID: <5238D252.40804@volny.cz> Date: Wed, 18 Sep 2013 00:06:10 +0200 From: =?windows-1252?Q?Ale=9A_Nesrsta?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130806 Thunderbird/17.0.8 MIME-Version: 1.0 To: The development of GNU GRUB Subject: Re: [PATCH] Fix invalid USB descriptor endless loop. References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4de8:71c:62::33 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 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: Tue, 17 Sep 2013 22:06:24 -0000 Hi Christian, sorry for delay, I am too busy in last time. > Hi, > > I discovered that on some PC's the USB stack would produce an invalid > descriptor upon query without an error. > I don't know why this is the case, maybe broken hardware but I > seriously doubt it. > GRUB doesn't handle TT's at all, Clearing TT's or resetting them. > Maybe thats a case for stuck transactions? > The descriptor would contain 0 in length, or atleast the code would > think that offset was the length > and cause an endless loop. I have minimal practical experiences with TT's. Theoretically, AFAIK, it should normally work without special intervention - but of course the praxis could be different or I possibly missed something important... > Maybe this type of parsing is completely avoidable but for now I just added a break condition. > GRUB should not hang on faulty devices. I cannot comment it (mainly the first sentence) - I am not original author of the most of GRUB USB code and this part of usb.c I didn't touched/studied yet (with some small exceptions) - I believed it works fine...:-) I have no time currently to think about this situation more deeply, but from my point of view, if this situation can really happen and cannot be avoided by another way, this patch could be OK. But it will be very good to know also the reason why the broken descriptor is read from device and no another error is indicated. Which devices are affected? And which descriptor(s) exactly? Are these devices working well under Windows? Are affected still the same devices and in every case (at every connect)? And on every port of PC? Could you send detailed Linux lsusb output of "broken" devices? Or possibly whole detailed lsusb output, to be able to see the way how the device is connected to USB controller. BR, Ales > > BR, > Christian > > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel >