PCMCIA lockups on HP Pavilion laptop

Hi all,

I have an HP pavilion ze4145 laptop running fedora core 1 with arjanv's 2.6.0-1.109 kernel. I have recently purchased an SMC 2532W-B 802.11b wireless card. I am not sure that this is supported under linux, but the problem I am having is rooted deeper than that:

when the redhat pcmcia script is run, the laptop locks up solid. sysrq is enabled but i have not tried it yet, i'd have to look up the keys and what they do. regardless, i have traced the problem to cardmgr itself, cardctl works alright though it can't provide much info on the card. I have pcmcia modularized as is most of the redhat kernel, and the modules pcmcia_core, yenta_socket and ds are loaded. when cardmgr runs, it locks the box up when it is inside the adjust_resources function in cardmgr.c - at least on this 2.6.0 kernel, though the pcmcia script also locks the box up on the 2.4 fedora kernels (2.4.22-1.2135.nptl and 2.4.22-1.2115.nptl, both fedora core 1 stock kernels).

the version of the pcmcia kernel stuff installed with fedora is 3.1.31 - i have also installed the 3.2.7 userspace utilities (not kernel side, the configuration process from pcmcia-cs-3.2.7 detected that pcmcia was already enabled in the kernel and only installed the userspace stuff.)

the way in which i determined that cardmgr was at fault was by running it by hand, simply cardmgr -v. I then traced it down further by adding fprintfs to stderr to cardmgr.c - the specific line from which my box never returns is

ret = ioctl(fd, DS_ADJUST_RESOURCE_INFO, &al->adj);

in adjust_resources() in cardmgr.c
the resource being adjusted is an io-range resource, and it's the second one in the linked list that crashes my box, the first one succeeds just fine

i also tried booting with noapic and acpi=off just to see if that had anything to do with it, but no luck. I have not yet tried a stock kernel.org kernel.

debugging this inside the ioctl is a bit out of my league, which is why i have written this mail - any insight anyone else has (even if it's just 'what the hell is wrong with you, you've screwed everything up by doing xxx') would be much appreciated. Not being a kernel-hacker but being a compsci major in school probably makes me too dangerous for my own good. ;-) so if i've totally made a mess of things just tell me so. I've attached the diff between my modified copy of cardmgr.c and the one from pcmcia-cs-3.2.7. First diff I've ever made, so it could be wrong - it's just fprintfs to see where it got while it was running. I'll study up on the format of adjust_list_t and see if i can figure out exactly which io range the code is trying to adjust and failing at.

thanks for any insights, all.

-aubin

@@ -1217,8 +1217,21 @@
     int fd = socket[0].fd;
     
     for (al = root_adjust; al; al = al->next) {
+	    fprintf( stderr, "calling ioctl to adjust resource info for a(n) ");
+	    switch( al->adj.Resource ) {
+		    case RES_MEMORY_RANGE:
+			    fprintf(stderr, "memory range resource\n");
+			    break;
+		    case RES_IO_RANGE:
+			    fprintf( stderr, "io range resource\n");
+			    break;
+		    case RES_IRQ:
+			    fprintf( stderr, "irq resource\n");
+	    }
 	ret = ioctl(fd, DS_ADJUST_RESOURCE_INFO, &al->adj);
+	fprintf( stderr, "made it back from ioctl resource adjust\n");
 	if (ret != 0) {
+		fprintf(stderr, "we failed to adjust a resource\n");
 	    switch (al->adj.Resource) {
 	    case RES_MEMORY_RANGE:
 		sprintf(tmp, "memory %#lx-%#lx",

@@ -1332,7 +1345,9 @@
 	syslog(LOG_INFO, "watching %d socket%s", sockets,
 	       (sockets != 1) ? "s" : "");
 
+    fprintf(stderr, "cardmgr calling adjust_resources()\n");
     adjust_resources();
+    fprintf( stderr, "cardmgr back from adjust_resources() call\n");
     return 0;
 }
 

@@ -1382,6 +1397,7 @@
 	    errflg = 1; break;
 	}
     }
+	fprintf(stderr, "cardmgr finished option parsing\n");
     if (errflg || (optind < argc)) {
 	fprintf(stderr, "usage: %s [-V] [-q] [-v] [-o] [-f] "
 		"[-c configpath] [-m modpath]\n               "

@@ -1414,12 +1430,15 @@
 	syslog(LOG_NOTICE, "cannot access %s: %m", modpath);
     /* We default to using modprobe if it is available */
     do_modprobe |= (access("/sbin/modprobe", X_OK) == 0);
-    
+    fprintf(stderr, "cardmgr calling load_config()\n");
     load_config();
-    
+    fprintf(stderr, "cardmgr calling init_sockets()\n");
     if (init_sockets() != 0)
-	exit(EXIT_FAILURE);
-
+	{
+		fprintf(stderr, "cardmgr init_sockets failed\n");
+		exit(EXIT_FAILURE);
+	}
+	fprintf( stderr, "cardmgr init_sockets() succeeded\n");
     closelog();
     close(0); close(1); close(2);
     if (!delay_fork && !one_pass)

@@ -1442,7 +1461,7 @@
     if (signal(SIGPWR, catch_signal) == SIG_ERR)
 	syslog(LOG_ERR, "signal(SIGPWR): %m");
 #endif
-
+	fprintf( stderr, "cardmgr finished sighandler setup\n");
     for (i = max_fd = 0; i < sockets; i++)
 	max_fd = (socket[i].fd > max_fd) ? socket[i].fd : max_fd;
 

@@ -1476,7 +1495,7 @@
 		syslog(LOG_INFO, "read(%d): %m\n", i);
 	    if (ret != 4)
 		continue;
-	    
+		fprintf(stderr, "cardmgr about to enter event switch\n");
 	    switch (event) {
 	    case CS_EVENT_CARD_REMOVAL:
 		socket[i].state = 0;

Alt-Sysrq-Space will give you a summary, if the system is still alive enough to accept sysrq.

I suspect it may be another case where the kernel resource subsystem doesn't actually know the full story of which ports are in use. Chances are you're hitting some sort of system management port which is then causing the system to lock up.

You could try finding out exactly which IO port(s) are causing the problem by tweaking your PCMCIA config.opts file, by doing a binary search in the affected IO region, and then reporting the result here. The output of dmidecode and lspci -vxxx may also be useful.

Note that PCMCIA performs IO probes using a granularity of 8 bytes, so there's no point going below that.

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

I have an HP nx9005 laptop which also hung quite badly during pcmcia startup. I found a website with a config.opts which seems to work around this problem. It may or may not work for you, but it might be worth a try. This is what I used:

http://www.consultmatt.co.uk/nx9005/config.php

- Peter.

I'll keep that one in mind as well, thanks Peter. Mathieu's reply (earlier in this thread) fixed it for me, i used the config he put in his mail. thanks to all of you for your help and insight!

Russell, would it be useful to you if I tracked it down more precisely anyway? the config mathieu posted worked for me so i didn't look too deep, but if you'd like me to try and narrow it down so that we know which io space causes problems on these machines i could do that.

-aubin

Personally, I don't care very much - it's useful to know the affected port range vs the machine, so when other people have the same problem we don't have to re-investigate.

I'd rather there was some way to automatically mark these pesky regions in the resource manager so we didn't have to do this, but I guess that's going to be too much.

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