From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mta1.math.wisc.edu (mta1.math.wisc.edu [144.92.166.23]) by befuddled.reisers.ca (Postfix) with ESMTP id 3E9361EF08B for ; Wed, 1 May 2013 14:05:27 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mta1.math.wisc.edu (Postfix) with ESMTP id 08C7687E00A for ; Wed, 1 May 2013 13:05:25 -0500 (CDT) X-Virus-Scanned: Debian amavisd-new at mta1.math.wisc.edu Received: from mta1.math.wisc.edu ([127.0.0.1]) by localhost (charlie.math.wisc.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9GHLz86vtm6 for ; Wed, 1 May 2013 13:05:24 -0500 (CDT) Received: from mta1.math.wisc.edu (localhost [127.0.0.1]) by mta1.math.wisc.edu (Postfix) with ESMTP id 1861187E001 for ; Wed, 1 May 2013 13:05:24 -0500 (CDT) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on charlie.math.wisc.edu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=6.5 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.3.1 Received: from mailhost.math.wisc.edu (erdos.math.wisc.edu [144.92.166.25]) by mta1.math.wisc.edu (Postfix) with ESMTP for ; Wed, 1 May 2013 13:05:24 -0500 (CDT) Received: from [144.92.166.19] (vv507j.math.wisc.edu [144.92.166.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.math.wisc.edu (Postfix) with ESMTPSA id 167735400FA for ; Wed, 1 May 2013 13:05:24 -0500 (CDT) Message-ID: <51815963.2030500@math.wisc.edu> Date: Wed, 01 May 2013 13:05:23 -0500 From: "John G. Heim" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Speakup is a screen review system for Linux." Subject: Re: Any News on cut-and-paste bug? References: <51811C92.4020104@math.wisc.edu> <20130501135012.GA5940@type.youpi.perso.aquilenet.fr> <518137EF.1040502@math.wisc.edu> <20130501154545.GJ5940@type.youpi.perso.aquilenet.fr> <5181419A.2010909@math.wisc.edu> <8582.1367425859@ccs.covici.com> In-Reply-To: <8582.1367425859@ccs.covici.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: speakup@linux-speakup.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Speakup is a screen review system for Linux." List-Id: "Speakup is a screen review system for Linux." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 18:05:27 -0000 But that's no answer. This is the same problem I had with the responses I got on the linux-kernel list. I asked extremely specific questions below and just saying no isn't enough. Specifically, what is wrong with my patch? Does speakup need to call request_reggion at all? If so, why,? What does request_region do? It looks as if request_region always fails if you request a region at the address of the serial port even if the serial port is not in use? Why is that? If this behaviour is by design, what is the speakup code supposed to do instead? You can say nothing. Say you're too busy or whatever. But don't just say no. On 05/01/13 11:30, covici@ccs.covici.com wrote: > I would not accept that fix in the kernel, either -- nice workaround, > but its just hiding the real problem. > > John G. Heim wrote: > >> >> >> On 05/01/13 10:45, Samuel Thibault wrote: >>> John G. Heim, le Wed 01 May 2013 10:42:39 -0500, a écrit : >>>> All I wanted to do was get rid of what I suspected was a call to a function >>>> that apparently did nothing and the subsequent erroring out. But nobody >>>> seemed to know what the function did or if they did, they weren't sharing. >>>> They did, however, take the time to criticize the speakup code itself. >>> >>> Do you have a reference of the thread? (like the precise date when it >>> happened, or the subject, etc.) >> >> Here are 2 of the messages I posted. I haven't found an archive of the >> linux-kernel list. But I haven't looked too hard. But these messages >> show the exact date and subject line of the 2 threads on the list. >> >> On 03/03/12 11:18, John G. Heim wrote: >>> Subject: speakup bug >>> I need help fixing a bug in the driver for serial hardware speech >>> synths in the speakup screen reader. According to the comments in the >>> code, it is in a part of the code that is trying to "steal" the serial >>> port. >>> >>> First it calls request_region and when that fails (it always fails), it >>> calls __release_region(&then it calls release_region again to >>> see if __release_region worked. But it never works because the region >>> being requested is already taken. >>> >>> The code in question is in 2 source code files in >>> drivers/staging/speakup. It starts in serialio.c on line 38. Here it >>> calls a function named synth_request_region which in turn, calls >>> request_region. On line 41 it calls __release_region, and on line 42 it >>> calls synth_request_region again. The function synth_request_region >>> (which calls request_region) is in a file named synth.c. But this code >>> always fails. Here is a kind of simplified version of it... >>> >>> int error; >>> struct resource tmp; >>> tmp .name = "ltlk"; >>> tmps.start = 0x3F8; >>> tmp.end = 0x3FF; >>> tmp.flags = IORESOURCE_BUSY; >>> error = request_resource (&ioport_resource, &tmp); >>> >>> The error returned is always -16. I looked at the code in >>> kernel/resource.c where the request_region function is defined. It >>> builds a linked list of resources with start & end addresses. If you >>> request a region that is already within the start-end range of a >>> resource already in the list, it returns an error code. But it looks as >>> if the region for a serial port, 0x3f8 - 0x3ff, in ioport_resource >>> cannot be reserved because the entire range from 0x000 through 0xcf7 is >>> already taken by something named "PCI Bus 0000:00". Therefore calling >>> request_resource always fails and the driver for the speech synth errors >>> out. >>> >>> And therefore I can't use my hardware speech synth without modifying the >>> kernel code. If you comment out the line that checks the return code >>> from request_region, it works. So you have to modify the kernel code >>> and compile a custom kernel to use a hardware speech synth. That's not >>> such a problem for me but it is for a lot of people. Plus, the grml live >>> CD doesn't work with hardware speech. That is a problem for me. >>> >>> Can anyone tell me how to fix this so it can be patched in the official >>> kernel code? >>> >> >> >> On 05/11/12 10:36, John Heim wrote: >>> Subject: patch for speakup serial hardware synths >>> A few weeks ago I asked about a problem with the speakup screen reader >>> code. It does not work with serial hardware speech synthesizers. But I >>> managed to get it working. How can I submit my fix for integration into >>> the kernel code. The patch file can be downloaded here: >>> http://www.math.wisc.edu/~jheim/downloads/patch-2012-03-06.patch >>> >>> To install it you cd to the linux source directory and do this: >>> patch -i patch-2012-03-06.patch drivers/staging/speakup/serialio.c" >>> >> _______________________________________________ >> Speakup mailing list >> Speakup@linux-speakup.org >> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup >