Created attachment 42442 [details] Output from lspci -vvv & lsmod Performed on Pismo G3 (PPC): modprobe yenta_socket The following message repeats for about 4 minutes: Jan 5 21:10:26 xxxx klogd: Machine check in kernel mode. Jan 5 21:10:26 xxxx klogd: Caused by (from SRR1=49030): Transfer error ack signal After these 4 minutes of flodding the kernel log, the modules seems to properly load. The kernel log then gives: Jan 5 21:10:26 xxxx klogd: yenta_cardbus 0001:10:1a.0: pcmcia: parent PCI bridge window: [mem 0xf3000000-0xf3ffffff] Jan 5 21:10:26 xxxx klogd: pcmcia_socket pcmcia_socket0: cs: memory probe 0xf3000000-0xf3ffffff: excluding 0xf3000000-0xf37fffff Jan 5 21:10:26 xxxx klogd: yenta_cardbus 0001:10:1a.0: pcmcia: parent PCI bridge window: [mem 0x80000000-0xafffffff] Jan 5 21:10:26 xxxx klogd: pcmcia_socket pcmcia_socket0: cs: memory probe 0x80000000-0xafffffff: excluding 0x80000000-0x807fffff 0xa0000000-0xa07fffff Jan 5 21:10:26 xxxx klogd: pcmcia_socket pcmcia_socket0: cs: IO port probe 0x100-0x3af: excluding nothing: probe failed. Jan 5 21:10:26 xxxx klogd: pcmcia_socket pcmcia_socket0: cs: IO port probe 0x3e0-0x4ff: excluding nothing: probe failed. Jan 5 21:10:26 xxxx klogd: pcmcia_socket pcmcia_socket0: cs: IO port probe 0x820-0x8ff: excluding nothing: probe failed. Jan 5 21:10:26 xxxx klogd: pcmcia_socket pcmcia_socket0: cs: IO port probe 0xc00-0xcf7: excluding nothing: probe failed. Jan 5 21:10:26 xxxx klogd: pcmcia_socket pcmcia_socket0: cs: memory probe 0x0c0000-0x0fffff: excluding 0xc0000-0xfffff Jan 5 21:10:26 xxxx klogd: pcmcia_socket pcmcia_socket0: cs: memory probe 0xa0000000-0xa0ffffff: excluding 0xa0000000-0xa00fffff Jan 5 21:10:26 xxxx klogd: pcmcia_socket pcmcia_socket0: cs: memory probe 0x60000000-0x60ffffff: excluding 0x60000000-0x60ffffff Jan 5 21:10:26 xxxx klogd: pcmcia_socket pcmcia_socket0: cs: IO port probe 0xa00-0xaff: excluding nothing: probe failed. Jan 5 21:10:26 xxxx klogd: pcmcia_socket pcmcia_socket0: pccard: PCMCIA card inserted into slot 0 Jan 5 21:10:26 xxxx klogd: pcmcia_socket pcmcia_socket0: cs: memory probe 0xf3800000-0xf3ffffff: clean. Jan 5 21:10:26 xxxx klogd: pcmcia 0.0: pcmcia: registering new device pcmcia0.0 (IRQ: 58) Jan 5 21:10:26 xxxx klogd: scsi6 : pata_pcmcia etc... Then everythings seems to work fine. My system: /proc/cpuinfo: processor : 0 cpu : 7410, altivec supported temperature : 14-16 C (uncalibrated) clock : 550.000000MHz revision : 1.4 (pvr 800c 1104) bogomips : 49.93 timebase : 24966218 platform : PowerMac model : PowerBook3,1 machine : PowerBook3,1 motherboard : PowerBook3,1 MacRISC2 MacRISC Power Macintosh detected as : 70 (PowerBook Pismo) pmac flags : 0000001f L2 cache : 1024K unified pmac-generation : NewWorld Memory : 640 MB /proc/ioports: 00000000-007fffff : /pci@f2000000 00000000-00000fff : Legacy IO 00001000-000011ff : PCI CardBus 0001:11 00001200-0000120f : pcmcia_socket0 00001200-0000120f : pcmcia0.0 00001400-000015ff : PCI CardBus 0001:11 00802000-01001fff : /pci@f0000000 00802400-008024ff : 0000:00:10.0 ff7fe000-ffffdfff : /pci@f4000000 ff7fe000-ff7fefff : Legacy IO The lspci and lsmod output is attached.
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