pcmcia - what is first place to look for bug?

[Pavel Roskin]

On Fri, 12 Mar 2004, Jerry Walden wrote:

> Okay - I rebuilt the kernel and made the modules pcmcia_core,
> yenta_socket, ds, ide_cs
> Below is the output from dmesg.  Output from /var/log/messages only
> happens after I run the cardmgr

It would be nice to have some information about the platform and the
kernel version.

> insmod yenta_socket:
> yenta 00:0c.1: Preassigned resource 0 busy, reconfiguring...
> yenta 00:0c.1: Preassigned resource 2 busy, reconfiguring...

That's one thing to debug.  I haven't seen this.  Maybe it has to do with
PCI configuration.  Print res->start, res->end and the result code of
request_resource(), try to understand why it fails.

> Yenta ISA IRQ mask 0x0000, PCI irq 1
> Socket status: 30000006
> Yenta ISA IRQ mask 0x0000, PCI irq 1
> Socket status: 30000006

Maybe irq 1 is OK for your architecture, but it looks strange.  "lspci -v"
lists the cards with the interrupts they want to use.  Check that it's
indeed 1.

> ismod ds:
> (no output from dmesg)
>
> insmod ide-cs:
> (no output)

Inserting ide-cs is not needed.  cardmgr should do it.

> /etc/rc.d/rc.pcmcia start:

You can just run cardmgr at this point for simplicity.

> aStarting PCMCIA services:
> cardmgr opts
> cardmgr[113]: watching 2 sockets
> cardmgr[113]: could not adjust resource: IO ports 0x1100-0x17ff: Invalid
> argument

Check if yenta_set_io_map() is called by adding a debug printk.

> cardmgr[113]: could not adjust resource: memory 0xc8000-0xcffff: Invalid
> argument

Same think with yenta_set_mem_map().

> cardmgr[113]: could not adjust resource: irq 4: Invalid argument

adjust_irq() in rsrc_mgr.c has failed.  Another thing to debug.  See where
it fails.

> I looked at /proc/iomem and /proc/ioports
>
> -bash-2.05b# cat /proc/iomem

You mean it's empty?  That's strange.  It means drivers are mot using
memory resources.  You need some memory for any card to read CIS.

> -bash-2.05b# cat /proc/ioports
> 02a41000-02a41007 : ide0
> 02a41206-02a41206 : ide0
> ad000000-ad003fff : ltxser
> b0400000-b0400fff : frontpanel
> b1100000-b1100007 : serial(auto)
> b1400000-b1400007 : serial(auto)
> b1500000-b150ffff : Au1x00 ENET
> b1510000-b151ffff : Au1x00 ENET

A good candidate would be b0401000-b0401fff.

> -bash-2.05b# cat /proc/interrupts
>            CPU0
>   1:          0    Au1000 Level  PCI device 104c:ac55, PCI device
> 104c:ac55

The ID is of TI PCI1250.  However, yenta_socket would use name "yenta", so
it didn't register the interrupt.  That's a problem that happens when
"yenta_socket" is loaded, before cardmgr is run, so it's another
interesting thing to debug.

> I'm not certain - given the output above - how to begin to guess an
> address for the port/mem.  Which one of the above modules would normally
> identify a card in the slot and return some form of ID - it seems that
> is the first thing that is not showing up

It looks like you have problems already before cardmgr is started, so you
can start with them.  When "yenta_socket" shows up in /proc/iomem and
"yenta" in /proc/interrupts, you can go further.

-- 
Regards,
Pavel Roskin