Bug 26142 - "yenta_socket" causes "Transfer error ack signal"
Summary: "yenta_socket" causes "Transfer error ack signal"
Status: RESOLVED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: PCMCIA (show other bugs)
Hardware: PPC-32 Linux
: P1 normal
Assignee: linux-pcmcia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-01-05 20:27 UTC by Helmut
Modified: 2015-05-26 22:39 UTC (History)
2 users (show)

See Also:
Kernel Version: 3.12
Subsystem:
Regression: No
Bisected commit-id:


Attachments
Output from lspci -vvv & lsmod (8.12 KB, text/plain)
2011-01-05 20:27 UTC, Helmut
Details

Description Helmut 2011-01-05 20:27:16 UTC
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.
Comment 1 Alan 2013-12-11 11:55:37 UTC
Closing as obsolete, if this is still seen on modern kernels please update
Comment 2 Helmut 2014-01-10 07:45:34 UTC
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.
Comment 3 Helmut 2014-01-17 22:08:52 UTC
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?
Comment 4 Helmut 2014-01-18 18:41:22 UTC
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.
Comment 5 Alan 2014-01-19 16:33:32 UTC
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).
Comment 6 Helmut 2014-01-19 17:23:06 UTC
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.
Comment 7 Alan 2014-01-19 17:24:56 UTC
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
Comment 8 Helmut 2014-01-21 19:57:35 UTC
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.
Comment 9 Alan 2015-02-19 16:13:36 UTC
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
Comment 10 Helmut 2015-05-26 15:50:02 UTC
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

Note You need to log in before you can comment on or make changes to this bug.