I get the following messages upon loading the pcmcia_core, yenta_socket,
and ds modules:
PCI: Enabling device 01:09.1 (0000 -> 0002)
PCI: Enabling device 01:09.0 (0000 -> 0002)
Yenta IRQ list 0000, PCI irq5
Socket status: 30000010
Yenta IRQ list 0000, PCI irq5
Socket status: 30000006
cs: socket c79bb800 timed out during reset. Try increasing setup_delay.
Then, immediately after I start the cardmgr daemon, the system hangs
solidly (cannot switch consoles or scroll up). Upon closer inspection,
socket 0 is not attached to a physical PCMCIA slot, and is the one timing
out above. Socket 1 is the only real slot. As a workaround, I modified
cardmgr so that it only initializes socket 1, and avoids socket 0
completely. When I do this, everything works perfectly and I can use
cards in the socket. (It should be noted that the hang occurs even
without any cards in the socket). Also, I doubt this is an IRQ problem
because irq 5 (assigned above) is not used by another device as reported
by lspci.
Since the pcmcia-cs modules work (even with kernel 2.4.x) I know that it's
theoretically possible to have socket 0 fail gracefully rather than hang
the system when it's initialized, even though it doesn't really exist.
Any ideas how to fix this?
I have attached the output when debugging is enabled in yenta_socket (this
is with cardmgr loading the modules itself):
cb_readl: c88c6740 0008 30001818
exca_readb: c88c6740 0001 4c
exca_readb: c88c6740 0003 50
^-- these three lines repeat for a while....
cb_readl: c88c6740 0008 30001818
exca_readb: c88c6740 0001 4c
exca_readb: c88c6740 0003 50
cs: socket c79a3800 timed out during reset. Try increasing setup_delay.
cb_readl: c88c67c8 0008 30000086
exca_readb: c88c67c8 0001 00
exca_readb: c88c67c8 0003 50
exca_writeb: c88c6740 0040 a0
exca_writew: c88c6740 0010 0000
exca_writew: c88c6740 0012 8000
exca_writew: c88c6740 0014 4000
exca_writeb: c88c6740 0006 01 <------------------- hangs here
The last few lines look like they are from the mem_map function, but I'm
not sure if the hang occurs immediately at this point, or is caused by
code somewhere else.
Thanks for the help.
Best Regards,
David Moore
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/