Hi,
After updating to a new kernel (>2.6.8) my PCMCIA ISDN did not work
anymore.
My test system now looks like this:
> uname -s -r -v -m
Linux 2.6.11-rc4 #5 Sun Feb 20 05:19:02 CET 2005 x86_64
> lspci | grep CardBus
0000:02:07.0 CardBus bridge: Texas Instruments PCI4510 PC card Cardbus
Controller (rev 02)
> cardctl info
cardctl info
PRODID_1="SEDLBAUER"
PRODID_2="ISDN-Adapter"
PRODID_3=" (c) 93-96 VK&CB"
PRODID_4="26.01.96"
MANFID=0000,0000
FUNCID=6
The initialisation of my ISDN always failed with the following error
messages:
...
kernel: HiSax: LinkLayer Revision 2.59.2.4
kernel: cs: pcmcia_socket0: read_cis_mem(1, 0x3f, 5)
kernel: cs: pcmcia_socket0: 0x01 0x07 0x00 0x02 ...
kernel: cs: pcmcia_socket0: read_cis_mem(1, 0x46, 13)
kernel: cs: pcmcia_socket0: 0xc1 0x81 0x19 0x01 ...
kernel: cs: pcmcia_socket0: odd IO request: base 0x260 align 0x8
kernel: cs: pcmcia_socket0: read_cis_mem(1, 0x55, 7)
kernel: cs: pcmcia_socket0: 0x02 0x08 0xaa 0x60 ...
kernel: cs: pcmcia_socket0: odd IO request: base 0x270 align 0x8
kernel: cs: pcmcia_socket0: read_cis_mem(1, 0x5e, 7)
kernel: cs: pcmcia_socket0: 0x03 0x08 0xaa 0x60 ...
kernel: cs: pcmcia_socket0: odd IO request: base 0x280 align 0x8
kernel: cs: pcmcia_socket0: read_cis_mem(1, 0x67, 7)
kernel: cs: pcmcia_socket0: 0x04 0x08 0xaa 0x60 ...
kernel: cs: pcmcia_socket0: odd IO request: base 0x2e8 align 0x8
kernel: cs: pcmcia_socket0: read_cis_mem(1, 0x70, 7)
kernel: cs: pcmcia_socket0: 0x05 0x08 0xaa 0x60 ...
kernel: cs: pcmcia_socket0: odd IO request: base 0x2f8 align 0x8
kernel: cs: pcmcia_socket0: read_cis_mem(1, 0x79, 7)
kernel: cs: pcmcia_socket0: 0x06 0x08 0xaa 0x60 ...
kernel: cs: pcmcia_socket0: odd IO request: base 0x350 align 0x8
kernel: cs: pcmcia_socket0: read_cis_mem(1, 0x82, 7)
kernel: cs: pcmcia_socket0: 0x07 0x08 0xaa 0x60 ...
kernel: cs: pcmcia_socket0: odd IO request: base 0x3e8 align 0x8
kernel: 0.0: GetNextTuple: No more items
...
So obviously, the kernel fails to allocate an io port window for the
PCMCIA adapter, and complains about a bad request for such a window.
However, if interprete these values as a request of an 8bit large IO
Window starting at base, I don't know what's so odd about it. Maybe,
this interpretation is wrong? Furthermore, /proc/ioports tells me that
the requested IO addresses are NOT used.
Well, I browsed the sources and added simple debug messages to the code
in order to find out, what function exactly returns an error and stops
the initialisation of my card. This debug led me to the function
"nonstatic_find_io_region" in drivers/pcmcia/rsrc_nonstatic.c that is
used by yenta_socket. To my very surprise, the ISDN card suppenly worked
after I added a "printk" that never executes. The file rsrc_nonstatic.c
then changed like this:
diff -u -U 7 /linux-2.6.11-rc4.changed/drivers/pcmcia/rsrc_nonstatic.c
../linux-2.6.11-rc4/drivers/pcmcia/rsrc_nonstatic.c
--- /linux-2.6.11-rc4.changed/drivers/pcmcia/rsrc_nonstatic.c
2005-02-20 11:37:39.000000000 +0100
+++ ../linux-2.6.11-rc4/drivers/pcmcia/rsrc_nonstatic.c 2005-02-20
02:16:48.000000000 +0100
@@ -623,15 +623,14 @@
down(&rsrc_sem);
#ifdef CONFIG_PCI
if (s->cb_dev) {
ret = pci_bus_alloc_resource(s->cb_dev->bus, res, num, 1,
min, 0, pcmcia_align, &data);
} else
#endif
- printk("This line will never be printed, but it helps!!!");
ret = allocate_resource(&ioport_resource, res, num, min,
~0UL,
1, pcmcia_align, &data);
up(&rsrc_sem);
if (ret != 0) {
kfree(res);
res = NULL;
Then sedlbauer_cs initialises with following debug messages:
...
kernel: HiSax: LinkLayer Revision 2.59.2.4
kernel: cs: pcmcia_socket0: read_cis_mem(1, 0x3f, 5)
kernel: cs: pcmcia_socket0: 0x01 0x07 0x00 0x02 ...
kernel: cs: pcmcia_socket0: read_cis_mem(1, 0x46, 13)
kernel: cs: pcmcia_socket0: 0xc1 0x81 0x19 0x01 ...
kernel: cs: pcmcia_socket0: odd IO request: base 0x260 align 0x8
kernel: cs: pcmcia_socket0: write_cis_mem(1, 0x100, 1)
kernel: cs: pcmcia_socket0: write_cis_mem(1, 0x101, 1)
kernel: sedlbauer: index 0x01: Vcc 5.0, irq 18, io 0x0260-0x0267
kernel: HiSax: Card 1 Protocol EDSS1 Id=HiSax (0)
kernel: HiSax: Sedlbauer driver Rev. 1.34.2.6
kernel: Sedlbauer: defined at 0x260-0x268 IRQ 18
kernel: Sedlbauer: testing IPAC version 0
kernel: Sedlbauer: speed star detected
...
So the io request stay odd, but now it works. If printk is not there,
allocate_resource returns with error code EBUSY. I do not understand
that at all. Maybe my printk irritates the semaphore that is set around
the allocate_resource? However, then my "solution" won't be very safe,
although my card works perfectly now. I have only a very basic
understanding of those kernel functions, and wonder if someone can tell
me, what this is all about.
Thanks,
Martin Drohmann
Hello
On Sunday 20 February 2005 11:44 am, you wrote:
>
> diff -u -U 7 /linux-2.6.11-rc4.changed/drivers/pcmcia/rsrc_nonstatic.c
> ../linux-2.6.11-rc4/drivers/pcmcia/rsrc_nonstatic.c
> --- /linux-2.6.11-rc4.changed/drivers/pcmcia/rsrc_nonstatic.c
> 2005-02-20 11:37:39.000000000 +0100
> +++ ../linux-2.6.11-rc4/drivers/pcmcia/rsrc_nonstatic.c 2005-02-20
> 02:16:48.000000000 +0100
> @@ -623,15 +623,14 @@
> down(&rsrc_sem);
> #ifdef CONFIG_PCI
> if (s->cb_dev) {
> ret = pci_bus_alloc_resource(s->cb_dev->bus, res, num, 1,
> min, 0, pcmcia_align, &data);
> } else
> #endif
> - printk("This line will never be printed, but it helps!!!");
> ret = allocate_resource(&ioport_resource, res, num, min,
What you're doing is forcing the execution of allocate_resource (&ioport... );
Cause adding the printk you're adding it's changing this:
else
ret = allocate_resource(...);
up(...);
by this:
else
printk(...);
/*This is not executing inside the else clause no more,
*so doesn't matter if s->cb_dev it's true or not, you're going with this*/
ret = allocate_resource(...);
up(...);
You're changing the block inside the else clause.
It's not about upsetting the sem afaik.
I could be wrong though, and that'll be a terrible tragedy.
Of course this is as long as CONFIG_PCI it's evaluating true, is it?
Vicente.
On Sun, Feb 20, 2005 at 12:44:25PM +0100, Martin Drohmann wrote:
> #ifdef CONFIG_PCI
> if (s->cb_dev) {
> ret = pci_bus_alloc_resource(s->cb_dev->bus, res, num, 1,
> min, 0, pcmcia_align, &data);
> } else
> #endif
> - printk("This line will never be printed, but it helps!!!");
If you added this, you've done much more than just adding it. Look
two lines above and realise that you've just changed what the "else"
clause conditionalises.
> ret = allocate_resource(&ioport_resource, res, num, min,
> ~0UL,
> 1, pcmcia_align, &data);
So, with your printk in place, we try pci_bus_alloc_resource. If that
succeeds or fails, we completely stomp on that with allocate_resource.
Bad. Very bad.
The first thing that needs solving is why you're getting the "odd IO
request" crap. That may explain why the resource can't be allocated.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
On Sun, Feb 20, 2005 at 12:38:17PM +0000, Russell King wrote:
> The first thing that needs solving is why you're getting the "odd IO
> request" crap. That may explain why the resource can't be allocated.
In cs.c, alloc_io_space(), find the line:
if (*base & ~(align-1)) {
delete the ~ and rebuild. This may resolve your problem.
This looks like a long standing bug in the PCMCIA code, going back to
2.4 kernels.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
Russell King <[email protected]> wrote:
>
> On Sun, Feb 20, 2005 at 12:38:17PM +0000, Russell King wrote:
> > The first thing that needs solving is why you're getting the "odd IO
> > request" crap. That may explain why the resource can't be allocated.
>
> In cs.c, alloc_io_space(), find the line:
>
> if (*base & ~(align-1)) {
>
> delete the ~ and rebuild. This may resolve your problem.
>
> This looks like a long standing bug in the PCMCIA code, going back to
> 2.4 kernels.
That looks right to me - I'll queue up a fix for after 2.6.11.
On Mon, 21 Feb 2005, Russell King wrote:
>
> In cs.c, alloc_io_space(), find the line:
>
> if (*base & ~(align-1)) {
>
> delete the ~ and rebuild. This may resolve your problem.
Unlikely. The code is too broken for words.
First off, setting align to zero makes no sense. An alignment cannot be
zero, although some other parts of the system seem to consider a zero
alignment to be the same as a maximum one (ie nonstatic_find_io_region()).
Something like the appended has at least a snowballs chance in hell of
being correct, although considering the amount of confusion in that single
function, I'm not very optimistic.
In particular, the initialization of "align" still has a case where it
sets alignment to 0:
align = (*base) ? (lines ? 1<<lines : 0) : 1;
(ie *base != 0 and lines == 0), and that one is _guaranteed_ to cause a
warning just a line later when we do a (corrected)
if (*base & (align-1))
and then set align to 1 again.
IOW, the whole function just does not make any sense. It didn't make sense
before, it doesn't make sense after it's partly fixed. Somebody who
understands what it is actually supposed to _do_, please explain it..
Linus
--
--- 1.124/drivers/pcmcia/cs.c 2005-01-25 13:50:25 -08:00
+++ edited/drivers/pcmcia/cs.c 2005-02-21 12:13:52 -08:00
@@ -748,14 +748,14 @@
if (*base) {
cs_dbg(s, 0, "odd IO request: num %#x align %#lx\n",
num, align);
- align = 0;
+ align = 1;
} else
while (align && (align < num)) align <<= 1;
}
- if (*base & ~(align-1)) {
+ if (*base & (align-1)) {
cs_dbg(s, 0, "odd IO request: base %#x align %#lx\n",
*base, align);
- align = 0;
+ align = 1;
}
if ((s->features & SS_CAP_STATIC_MAP) && s->io_offset) {
*base = s->io_offset | (*base & 0x0fff);
@@ -766,7 +766,7 @@
potential conflicts, just the most obvious ones. */
for (i = 0; i < MAX_IO_WIN; i++)
if ((s->io[i].NumPorts != 0) &&
- ((s->io[i].BasePort & (align-1)) == *base))
+ ((s->io[i].BasePort & ~(align-1)) == *base))
return 1;
for (i = 0; i < MAX_IO_WIN; i++) {
if (s->io[i].NumPorts == 0) {
Russell King wrote:
> On Sun, Feb 20, 2005 at 12:38:17PM +0000, Russell King wrote:
>
>>The first thing that needs solving is why you're getting the "odd IO
>>request" crap. That may explain why the resource can't be allocated.
>
>
> In cs.c, alloc_io_space(), find the line:
>
> if (*base & ~(align-1)) {
>
> delete the ~ and rebuild. This may resolve your problem.
>
> This looks like a long standing bug in the PCMCIA code, going back to
> 2.4 kernels.
>
I tried that, but it didn't work. Just the "odd IO request" is away. But
the error remains the same.
On Mon, 21 Feb 2005, Linus Torvalds wrote:
> On Mon, 21 Feb 2005, Russell King wrote:
> >
> > In cs.c, alloc_io_space(), find the line:
> >
> > if (*base & ~(align-1)) {
> >
> > delete the ~ and rebuild. This may resolve your problem.
>
> Unlikely. The code is too broken for words.
The original code is correct; you are misinterpreting the meaning of
the "align" variable here. PCMCIA cards can request a specific base
IO address, and can also specify how many IO address lines they
decode. The number of decoded lines determines a maximal alignment
restriction for a card; if it only decodes 3 lines, then it should not
reasonably ask for an IO region with more specificity than being on an
8 port boundary. The "align" variable here holds this alignment. The
"oddness" here is that the card is providing conflicting information,
that it needs IO ports at a specific address, but is only decoding 3
address lines (i.e. align=8).
The names of "base" and "align" have the expected meanings when a card
only specifies one or the other. It's only for the case where both
are specified that the meaning is complicated. Then, "base" is more
like an offset into a block that has "align" alignment
Given an "odd" request for a base=0x260 and align=8, the allocator
promotes this to align=0x400, and would allow addresses 0x260, 0x660,
0xa60, 0xe60, etc, subject to restrictions in /etc/pcmcia/config.opts.
The real problem here is that all the IO address ranges the card
claims to support were unavailable. I'd first try adding:
include port 0x0600-0x07ff
to /etc/pcmcia/config.opts to give the allocator more flexibility in
choosing port ranges.
-- Dave