[Bug 26142] "yenta_socket" causes "Transfer error ack signal"
https://bugzilla.kernel.org/show_bug.cgi?id=26142 Alan changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |CODE_FIX -- You are receiving this mail because: You are the assignee for the bug. ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
[Bug 26142] "yenta_socket" causes "Transfer error ack signal"
https://bugzilla.kernel.org/show_bug.cgi?id=26142 --- Comment #10 from Helmut --- 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 -- You are receiving this mail because: You are the assignee for the bug. ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
[Bug 26142] "yenta_socket" causes "Transfer error ack signal"
https://bugzilla.kernel.org/show_bug.cgi?id=26142 --- Comment #9 from Alan --- 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 -- You are receiving this mail because: You are the assignee for the bug. ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
[Bug 26142] "yenta_socket" causes "Transfer error ack signal"
https://bugzilla.kernel.org/show_bug.cgi?id=26142 --- Comment #8 from Helmut --- 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. -- You are receiving this mail because: You are the assignee for the bug. ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
[Bug 26142] "yenta_socket" causes "Transfer error ack signal"
https://bugzilla.kernel.org/show_bug.cgi?id=26142 --- Comment #7 from Alan --- 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 -- You are receiving this mail because: You are the assignee for the bug. ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
[Bug 26142] "yenta_socket" causes "Transfer error ack signal"
https://bugzilla.kernel.org/show_bug.cgi?id=26142 --- Comment #6 from Helmut --- 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. -- You are receiving this mail because: You are the assignee for the bug. ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
[Bug 26142] "yenta_socket" causes "Transfer error ack signal"
https://bugzilla.kernel.org/show_bug.cgi?id=26142 --- Comment #5 from Alan --- 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). -- You are receiving this mail because: You are the assignee for the bug. ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
[Bug 26142] "yenta_socket" causes "Transfer error ack signal"
https://bugzilla.kernel.org/show_bug.cgi?id=26142 --- Comment #4 from Helmut --- 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. -- You are receiving this mail because: You are the assignee for the bug. ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
[Bug 26142] "yenta_socket" causes "Transfer error ack signal"
https://bugzilla.kernel.org/show_bug.cgi?id=26142 --- Comment #3 from Helmut --- 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. ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
[Bug 26142] "yenta_socket" causes "Transfer error ack signal"
https://bugzilla.kernel.org/show_bug.cgi?id=26142 Alan changed: What|Removed |Added Kernel Version|2.6.36.2|3.12 -- You are receiving this mail because: You are the assignee for the bug. ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
[Bug 26142] "yenta_socket" causes "Transfer error ack signal"
https://bugzilla.kernel.org/show_bug.cgi?id=26142 Helmut changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|OBSOLETE|--- --- Comment #2 from Helmut --- 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. -- You are receiving this mail because: You are the assignee for the bug. ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
[Bug 26142] "yenta_socket" causes "Transfer error ack signal"
https://bugzilla.kernel.org/show_bug.cgi?id=26142 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC||a...@lxorguk.ukuu.org.uk Resolution|--- |OBSOLETE --- Comment #1 from Alan --- Closing as obsolete, if this is still seen on modern kernels please update -- You are receiving this mail because: You are the assignee for the bug. ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
[Bug 26142] "yenta_socket" causes "Transfer error ack signal"
https://bugzilla.kernel.org/show_bug.cgi?id=26142 Helmut changed: What|Removed |Added CC||helmut.schla...@web.de Platform|All |PPC-32 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia