Bug 26142

Closing as obsolete, if this is still seen on modern kernels please update

The error is still apparent with kernel 3.12.6, maybe even worse, since the error did not disappear even after I waited about 5 min. 

I meanwhile figure out that the error appeared first in 2.6.34.1 (2.6.33.6 was OK)

Being an experienced programmer, I am willing to looker deeper for the cause. However, I am not familiar with the kernel code, so any help/hint about what routines are involved in inserting the yenta_socket-driver is welcomed.

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?

Noticed that the module rsrc_nonstatic is since 2.6.35 called pcmcia_rsrc.

Thus, the old behaviour of kernel 2.6.33 of effectively not probing the IO addresses can be achieved for all kernels since kernel 2.6.35 by

1) kernel boot option pcmcia_rsrc.probe_io=0 (when built-in)
2) or setting 'options pcmcia_rsrc probe_io=0' in modprobe.conf (when being module)

I leave it to the kernel developers, if this is just a bug-fix or the issue is resolved by this.

The kernel normally considers 0 to be "unallocated" and 0x00-0x07 seem to be odd addresses to be allocated for PCMCIA use.  On the PC we do scan ranges because for old style PCMCIA the PC platform resource handling is a bit crude if not near non existent.

Is CONFIG_PCMCIA_PROBE set on your platform as it looks like it should not be (your machine seems to abort any I/O to unallocated space).

0x00-0x07 was probably not the best example chosen, but it's also the same for 0x1200, where it eventually is inserted.

Yes, CONFIG_PCMCIA_PROBE is set. 

The question is, if it should be disabled not only for P3, but also for P4 (see Red Hat Bugzilla), where a similar problem appeared.

It is not a platform I know well enough to be sure - but it certainly looks like in your case at least it would be worth disabling it and checking

I unset CONFIG_PCMCIA_PROBE by editing drivers/pcmica/Kconfig for testing:
config PCMCIA_PROBE
        bool
        default y if ISA && !ARCH_SA1100 && !PARISC && !PPC_BOOK3S

There's no difference to be observed compared to setting 'options pcmcia_rsrc probe_io=0', also not for the interrupts. So disabling the PCMCIA probe appears to be an option.

Since before 2.6.34 do_io_probe was effectively not doing any tests, and they had been no problems until then, it is probably safe to unset CONFIG_PCMCIA_PROBE for (at least) G3 Powerbooks.

For pure PCI I've recently submitted some proposed patches that fix a ton of PCMCIA bugs and also add a pure PCI resource manager for more modern systems. Might be worth giving it a spin.

Alan

Great! 

Tried kernel-4.0.4 and it booted without problems.

So pcmcia_rsrc.probe_io=0 is not necessary anymore.

Thanks a lot!

  Helmut