[RFC v3] PCMCIA locking updates for 2.6.34

Dominik Brodowski linux at dominikbrodowski.net
Sat Feb 20 08:48:14 EST 2010


Hey,

thanks for testing!

On Sat, Feb 20, 2010 at 08:42:28PM +0900, Komuro wrote:
> pcmcia 0.0: trying to load CIS file cis/3CXEM556.cis
> pcmcia 0.0: firmware: requesting cis/3CXEM556.cis
> pcmcia_socket pcmcia_socket0: Using replacement CIS
> pcmcia_socket pcmcia_socket0: parse_uevents: events 00000010
> pcmcia 0.0: matched to 3c589_cs
> 3c589_cs 0.0: trying to bind to 3c589_cs
> pcmcia_socket pcmcia_socket0: trying to allocate resource 1
> pcmcia_socket pcmcia_socket0: allocating resources succeeded: 0
> pcmcia_socket pcmcia_socket0: pcmcia_write_cis_mem(1, 0x400, 1)
> adding device to 0, function 1
> pcmcia 0.1: devname is pcmcia0.1
> pcmcia 0.1: creating config_t
> pcmcia 0.1: pcmcia: registering new device pcmcia0.1
> pcmcia_socket pcmcia_socket0: parse_uevents: events 00000010
> pcmcia_socket pcmcia_socket0: pcmcia_write_cis_mem(1, 0x401, 1)
> pcmcia_socket pcmcia_socket0: pcmcia_write_cis_mem(1, 0x405, 1)
> pcmcia_socket pcmcia_socket0: pcmcia_write_cis_mem(1, 0x406, 1)
> eth0: 3Com 3c589, io 0x300, irq 3, hw_addr 00:00:86:xx:xx:xx
>   8K FIFO split 5:3 Rx:Tx, auto xcvr

Did you modify the hw_addr here, or is it reported wrongly here, compared to
-rc8? If it is indeed different, that'd be a good starting point to hunt the
regression down. Other than that, I see nothing suspicious at all... Well,
maybe except the patch below (which would expose some bad CIS behaviour).

Best,
	Dominik


diff --git a/drivers/pcmcia/cistpl.c b/drivers/pcmcia/cistpl.c
index 2f3622d..9e724e0 100644
--- a/drivers/pcmcia/cistpl.c
+++ b/drivers/pcmcia/cistpl.c
@@ -298,7 +298,7 @@ static int read_cis_cache(struct pcmcia_socket *s, int attr, u_int addr,
 			memcpy(ptr, s->fake_cis+addr, len);
 		else {
 			memset(ptr, 0xff, len);
-			ret = -EINVAL;
+			ret = 0;
 		}
 		mutex_unlock(&s->ops_mutex);
 		return ret;



More information about the linux-pcmcia mailing list