[Bug 26142] "yenta_socket" causes "Transfer error ack signal"
bugzilla-daemon at bugzilla.kernel.org
bugzilla-daemon at bugzilla.kernel.org
Fri Jan 17 17:08:52 EST 2014
https://bugzilla.kernel.org/show_bug.cgi?id=26142
--- Comment #3 from Helmut <helmut.schlattl at web.de> ---
I think I found the cause of the error: it is not caused by yenta_socket.c
itself, but in do_io_probe of rsrc_nonstatic.c, when it calls 'inb()':
2.6.33.6, line 218f:
for (i = base, most = 0; i < base+num; i += 8) {
res = claim_region(NULL, i, 8, IORESOURCE_IO, "PCMCIA ioprobe");
if (!res)
continue;
2.6.34.1, line 216f:
for (i = base, most = 0; i < base+num; i += 8) {
res = claim_region(s, i, 8, IORESOURCE_IO, "PCMCIA ioprobe");
if (!res)
continue;
(Similarly the subsequent loop around line 232)
I.e., in 2.6.34.1 claim_region is called with the pcmcia_socket 's' as
argument, which makes sense. In contrast to 2.6.33.6 this leads to a defined
'res', and thus a call to 'inb' (asm-generic/io.h) , which then causes the ack
signal error
Tests performed in 2.6.33.6:
1) Added some additional lines to see what goes on:
- 'res' is never defined
- thus, in the subsequent loop (starting at line 232), 'bad' and 'any'
remain false
- thus, do_io_probe finishes successful (without actually performing any
tests, if the memory is readable at all!)
2) Additionally, forced a call to inb() for 0x0-0x7, which resulted in the ack
signal error for port 0 to 7
Using 'probe_io=0' when inserting rsrc_nonstatic in 2.6.34.1 solved the problem
for this kernel version, again pointing for a problem in 'do_io_probe'.
Unfortunately, this does not solve the problem in 3.12.6, but I did not examine
this further.
Bug 743275 of Red Hat Bugzilla seems to be a duplicate of this bug.
Is it possible that accessing this address range is forbidden by the
Openfirmware? Or any other ideas?
--
You are receiving this mail because:
You are the assignee for the bug.
More information about the linux-pcmcia
mailing list