Re: Why does printk helps PCMCIA card to initialise?

Re: Why does printk helps PCMCIA card to initialise?

[Vicente Feito]

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.

Why does printk helps PCMCIA card to initialise?

[Martin Drohmann]

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

Re: Why does printk helps PCMCIA card to initialise?

[Russell King]

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

Re: Why does printk helps PCMCIA card to initialise?

[Russell King]

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

Re: Why does printk helps PCMCIA card to initialise?

[Andrew Morton]

Russell King <rmk+lkml@arm.linux.org.uk> 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.

Re: Why does printk helps PCMCIA card to initialise?

[Linus Torvalds]

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) {

Re: Why does printk helps PCMCIA card to initialise?

[Martin Drohmann]

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.

Re: Why does printk helps PCMCIA card to initialise?

[David Hinds]

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