[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