[Bug 26142] yenta_socket causes Transfer error ack signal

2015-05-26 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=26142

Alan a...@lxorguk.ukuu.org.uk 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

2015-05-26 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=26142

--- Comment #10 from Helmut helmut.schla...@web.de ---
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

2015-02-19 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=26142

--- Comment #9 from Alan a...@lxorguk.ukuu.org.uk ---
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

2014-01-21 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=26142

--- Comment #8 from Helmut helmut.schla...@web.de ---

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

2014-01-19 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=26142

--- Comment #5 from Alan a...@lxorguk.ukuu.org.uk ---
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

2014-01-19 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=26142

--- Comment #6 from Helmut helmut.schla...@web.de ---
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

2014-01-19 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=26142

--- Comment #7 from Alan a...@lxorguk.ukuu.org.uk ---
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

2014-01-18 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=26142

--- Comment #4 from Helmut helmut.schla...@web.de ---

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

2014-01-17 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=26142

--- Comment #3 from Helmut helmut.schla...@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.

___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia


[Bug 26142] yenta_socket causes Transfer error ack signal

2014-01-10 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=26142

Alan a...@lxorguk.ukuu.org.uk 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

2014-01-09 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=26142

Helmut helmut.schla...@web.de changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|OBSOLETE|---

--- Comment #2 from Helmut helmut.schla...@web.de ---
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

2011-01-06 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=26142


Helmut helmut.schla...@web.de 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