From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from s-out-001.smtp25.com (s-out-001.smtp25.com [67.228.91.90]) by befuddled.reisers.ca (Postfix) with ESMTPS id C6FBC1EF08B for ; Wed, 1 May 2013 14:28:24 -0400 (EDT) Received: from ccs.covici.com (ccs.covici.com [70.109.53.110]) by s-out-001.smtp25.com (8.14.2/8.14.2) with ESMTP id r41ISIWa005438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 1 May 2013 14:28:19 -0400 Received: from ccs.covici.com (localhost [127.0.0.1]) by ccs.covici.com (8.14.6/8.14.5) with ESMTP id r41ISIlI024712 for ; Wed, 1 May 2013 14:28:18 -0400 To: "Speakup is a screen review system for Linux." Subject: Re: Any News on cut-and-paste bug? In-reply-to: <51815963.2030500@math.wisc.edu> 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> <51815963.2030500@math.wisc.edu> Comments: In-reply-to "John G. Heim" message dated "Wed, 01 May 2013 13:05:23 -0500." X-Mailer: MH-E 8.2; nmh 1.3; GNU Emacs 23.4.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Wed, 01 May 2013 14:28:18 -0400 Message-ID: <24711.1367432898@ccs.covici.com> From: covici@ccs.covici.com X-SpamH-OriginatingIP: 70.109.53.110 X-SpamH-Filter: s-out-001.smtp25.com-r41ISIWa005438 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:28:26 -0000 What I mean is that the error code is there for some reason -- its trying to warn you of something, so investigation is needed and a real solution found. I would look at the 8250 module and see how it does the registration/release itself. However, maybe we need to go to a different way of doing this -- this is some of what I want to discuss on the call. John G. Heim wrote: > 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? >=20 > You can say nothing. Say you're too busy or whatever. But don't just say = no. >=20 > 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 =C3=A9crit : > >>>> All I wanted to do was get rid of what I suspected was a call to a f= unction > >>>> that apparently did nothing and the subsequent erroring out. But nob= ody > >>>> seemed to know what the function did or if they did, they weren't sh= aring. > >>>> They did, however, take the time to criticize the speakup code itsel= f. > >>> > >>> 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 =3D "ltlk"; > >>> tmps.start =3D 0x3F8; > >>> tmp.end =3D 0x3FF; > >>> tmp.flags =3D IORESOURCE_BUSY; > >>> error =3D 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 err= ors > >>> 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 l= ive > >>> 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 offici= al > >>> 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 in= to > >>> 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 > > > _______________________________________________ > Speakup mailing list > Speakup@linux-speakup.org > http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup --=20 Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici covici@ccs.covici.com