From: "John G. Heim" <jheim@math.wisc.edu>
To: <linux-kernel@vger.kernel.org>
Subject: speakup bug
Date: Sat, 3 Mar 2012 11:18:12 -0600 [thread overview]
Message-ID: <BFFDBC9B6BA14BE1AC8E266A3A456A63@hinkle> (raw)
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?
next reply other threads:[~2012-03-03 17:18 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-03 17:18 John G. Heim [this message]
2012-03-03 17:39 ` Alan Cox
2012-03-03 22:01 ` Ted Ts'o
2012-03-04 0:01 ` John G. Heim
2012-03-04 0:18 ` Samuel Thibault
2012-03-04 0:21 ` Samuel Thibault
2012-03-04 0:41 ` Ted Ts'o
2012-03-04 0:43 ` Samuel Thibault
2012-03-04 0:44 ` Samuel Thibault
2012-03-04 1:41 ` Ted Ts'o
2012-03-04 0:26 ` Ted Ts'o
2012-03-04 2:03 ` John G. Heim
2012-03-04 21:06 ` Alan Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BFFDBC9B6BA14BE1AC8E266A3A456A63@hinkle \
--to=jheim@math.wisc.edu \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®