Bugzilla – Bug 105218
Strange PCMCIA behaviour between Suse 9.3 Pro and SuSE 10.0
Last modified: 2007-06-05 09:37:07 UTC
Hi, I don't know in which category to report thuis bug (kernel ? installation ? usability ?) so I put it in Yast2. Here is the bug. I have a Medion Laptop : the MD95257. This Medion is really capricious with the actual Linux distro. I have to disable PCMCIA in order to install it (and then, and just for info, with Ubuntu, PCMCIA is ok after install but hotplug freeze at boot, I have to make a CTRL+C to discard hotplug detection and the problem wa solved after compiling a driver for the marvel network card and installing some restricted kernel modules). On SuSE 9.3, I just install and boot the OS with NOPCMCIA=yes and all is perfect, even the ACPI. On SuSE 10.0, this is fun cause I can launch the first part of the install procedure without disabling PCMCIA. I have only a : activating PCMCIA devices... failed. No problem, I was happy that the install could run without disabling PCMCIA. But after the first reboot for completing the install (CD2, 3, 4) and even after to boot the system, the system freeze. NOPCMCIA=yes seems to have no effect and I was forced to disable ACPI in order to boot properly, but ACPI is 100% ok on the 9.3 Here is what I can say about it. I will see tomorrow with the beta2. If you need special informations (precise logs, ...) from the 10.0 or even the 9.3, just tell me and I will do it. Regards, Florent CHANTRET
"mobile devices" looks like the proper category.
Currently we don't have NOPCMCIA=yes, because PCMCIA has changed massively. I will readd it if neccessary. I'm interested in the exact reason for the freeze. So please do the following in beta_2_ (not beta1): (You can do all that at the end of the first part of installation. Stop the countdown before the reboot. All files are then in /mnt not in /) 0) Eneable ACPI again if it was disabled (Everything to default) 1) Add 'yenta_socket' to /etc/hotplug/blacklist 2) Copy the pcmcia_socket.agent, that i will attatch here, to /etc/hotplug/ 3) Set udev_log="info" in /etc/udev/udev.conf 4) Now reboot. It should not hang if pcmcia was the reason for the hang. You may now continue the installation first. 5) Make sure that sysrequest is enabled. 'cat /proc/sys/kernel/sysrq' should give you '1'; else 'echo 1 > /proc/sys/kernel/sysrq'. 6) Open a terminal and become root. Type the following: logger xxxxxxxxxxxxxxxxxxxxPCMCIAxxxxxxxxxxxxxxxxxxxxxxxx sync modprobe yenta_socket Now the system should freeze after a few seconds. You may reboot via sysrequest. Press [Alt]+[sysrq]+[s] Press [Alt]+[sysrq]+[u] Press [Alt]+[sysrq]+[b] After reboot extract the relevant part from /var/log/messages: sed -n /xPCMCIAx/,/syslog.*starting/p /var/log/messages > pcmcia.freeze.log Attach pcmcia.freeze.log to this bug. Hint: You may enable sysrq permanantly if you add sysrq=1 to the bootloader commandline before installation starts. Or set it in /etc/sysconfig/sysctl later. Maybe you know much of what i described, but i can't know if you know ... ;)
Created attachment 46451 [details] debug pcmcia socket agent Use this /etc/hotplug/pcmcia_socket.agent for the test.
Hi, The beta2 is worse for me. If I try a standard installation, the setup stop after telling : activating PCMCIA devices... failed. So, I've tried to add the boot param NOPCMCIA=yes and now it seems that PCMCIA detection is correctly skipped... ... but the setup stop on searching for info file... I've tried to install with the safe mode with and without NOPCMCIA=yes but the setup still stop. I would like to help more and try your suggestion but I can't go further with the beta2 :o(
I guess you have a SATA system. SATA cdrom support is unfortunatly broken in beta2. Remove yor cdrom and install via network. You can also use beta1 for the test, but you have to update the packages udev and hotplug.
Hi, First, it's funny cause I thought the SATA problem were already there in the beta 1 but I can install the beta1. But yes, I think my system is SATA as my drives as seen as SCSI ones (sda for the hard-drive and sr0 for the cdrom) and the kernel module is ata_piix. I haven't disconnect the CD-ROM and install via network the beta2 cause I have no other computer available for that. So I have installed the beta1 and I have update udev and hotplug with the RPM of beta2. I repeat that for the beta2 NOPCMCIA=yes seemed to work but we will see for a next beta when SATA will work again. Else, I've seen funny stuffs... With your included /etc/hotplug/pcmcia_socket.agent, I haven't got crashes anymore when I have modprobed yenta_socket. I don't know if it was the desired behaviour. yenta_socket is correcty loaded but I have no PCMCIA card to test (if necessary, I have a WIFI PC-Card in my wife's computer and I can make a test but it's quite boring cause it needs ndiswrapper so a little work to get it working (perhaps not with SuSE ?). So, in order to have a log trace, I have replaced the pcmcia_socket.agent bundled by you with the original one, rebooted the system and follow your procedure again. To answer to you, I'm a professional developper (but often PHP / MySQL, sometimes Java or C module (for proftpd)) but I'm not (yet ? ;o)) a Linux Guru so I don't know much as you on what you describe even if I perfectly understand it and it seems quite natural to blacklist a module for the hotplug ;o) So here it is and I'm waiting to help again for this problem. I will report another bugs now ;o)
Created attachment 46767 [details] Log trace of the freeze Here is the log trace of the freeze with the original /etc/hotplug/pcmcia_socket.agent
I did not see everything i wanted. I guess we have to play some rounds of try and error. I guess the problem is that pcmcia-socket-startup offer some io region to pcmcia, that is used by something else. Some steps to catch that. Please change step for step and try activating pcmcia in between (modprobe -r pcmcia yenta_socket; sleep 1; modprobe yenta_socket; or boot if crashed ;) ) 1) remove the pcmcia-socket-startup line from pcmcia.agent 2) Add it again and comment out all lines in /etc/pcmcia.config.opts 3) Add one line per try to find the culprit 4) If the bad line contains several io ranges, split it. 5) When you found the bad io range, divide that further and until you got the bad address range. May be that i'm completely wrong, but it's worth a try. BTW: If you go for beta3, pcmcia.agent is gone completely. It's now done from hwup, but the interesting function is in /etc/sysconfig/hardware/scripts/functions.pcmcia. /etc/pcmcia/config.opts is still there.
Unfortunately, still no news for this bug. I've begun to test your last suggestions but not successfully for the moment. But, it is interesting to notice that during the boot of the first setup CD, I see detecting PCMCIA devices... done This is not failed nor that it freezz the computer. Could the settings between the boot CD and the installed SuSE could be different ? Else, as I said early, your own pcmcia_agent didn't crashed and yenta_socket was loaded (almost with beta1), I could try with beta3.
Hi, Here is the informations. I've found the bad range in /etc/pcmcia/config.opts This is this one : 0x800-0x8ff I've tried to find the bad range but it's fun cause if I try this : include port 0x800-Ox80f include port 0x810-0x8ff It works even if this is the complete range splitted in two range. But this range crashed : include port 0x808-0x80f I don't know if splitting in 2 ranges as I've done when it works is correct (I'm still not an expert ;o)) else I suppose I must work on the crashing range 0x808 to extend or minimize it ? Just tell me and I will try. Else, I've tried for fun to uncomment this one : # High port numbers do not always work... include port 0x1000-0x17ff And it didn't crashed on mine.
I excluded this range from config.opts. Also readded boot parameter to skip pcmcia: pcmcia=off But NOPCMCIA=1 does also still work. See details in README.SUSE of next pcmciautils package.