Description of problem: I opened the lid of my PowerBook G4 to wake it up, and immediately inserted a pcmcia compact flash adapter card. The machine printed an error message on the screen (over X) and locked up. The error message did not look like the usuall error messages (maybe apple openfirmware or something?). I powered off the machine and rebooted, leaving the card in. Another lockup. Took the card out and rebooted ok. Unfortunately, very little usefull information was written to syslog: Jun 30 10:57:09 spx kernel: pccard: PCMCIA card inserted into slot 0 Jun 30 10:57:10 spx kernel: pcmcia: registering new device pcmcia0.0 Jun 30 10:57:10 spx kernel: ata3: PATA max PIO0 cmd 0xfce31000 ctl 0xfce3100e bmdma 0x00000000 irq 53 Jun 30 10:57:10 spx kernel: scsi2 : pata_pcmcia Jun 30 10:57:10 spx kernel: ata3.00: CFA: SAMSUNG CF/ATA, 04/05/06, max PIO2 Jun 30 10:57:10 spx kernel: ata3.00: 2041200 sectors, multi 0: LBA Jun 30 10:57:10 spx kernel: ata3.00: configured for PIO0 Jun 30 10:57:10 spx kernel: scsi 2:0:0:0: Direct-Access ATA SAMSUNG CF/ATA 04/0 PQ: 0 ANSI: 5 Jun 30 10:57:10 spx kernel: SCSI device sda: 2041200 512-byte hdwr sectors (1045 MB) Jun 30 10:57:10 spx kernel: sda: Write Protect is off Jun 30 10:57:10 spx kernel: SCSI device sda: write cache: disabled, read cache: enabled, doesn't support DPO or FUA Jun 30 10:57:10 spx kernel: SCSI device sda: 2041200 512-byte hdwr sectors (1045 MB) Jun 30 10:57:10 spx kernel: sda: Write Protect is off Jun 30 10:57:10 spx kernel: SCSI device sda: write cache: disabled, read cache: enabled, doesn't support DPO or FUA Jun 30 10:57:10 spx kernel: sda: sda1 Jun 30 10:57:10 spx kernel: sd 2:0:0:0: Attached scsi removable disk sda Jun 30 10:57:10 spx kernel: sd 2:0:0:0: Attached scsi generic sg0 type 0 Jun 30 10:57:10 spx kernel: pcmcia: registering new device pcmcia0.1 Jun 30 10:57:10 spx kernel: 0.1: GetNextTuple: No more items Jun 30 10:57:10 spx kernel: pata_pcmcia: probe of 0.1 failed with error -12 Jun 30 10:57:11 spx kernel: 0.1: GetNextTuple: No more items Jun 30 10:57:11 spx kernel: pata_pcmcia: probe of 0.1 failed with error -12 Jun 30 10:57:11 spx kernel: 0.1: GetNextTuple: No more items Jun 30 10:57:11 spx kernel: pata_pcmcia: probe of 0.1 failed with error -12 Jun 30 11:05:33 spx syslogd 1.4.2: restart. Version-Release number of selected component (if applicable): pcmciautils-014-9.fc7 (from testing, as I needed fix from https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=244420) How reproducible: After the initial update to the testing rpm, I used my pcmcia compact flash card at least twice with no issues. I haven't tried again since the crash.. Steps to Reproduce: unsure, but.. 1. Open powerbook lid of sleeping machine with one hand, insert CF card with other hand 2. 3. Actual results: crash/lockup Expected results: card appears as sda Additional info:
Created attachment 160760 [details] syslog of bugs/machin checks still having lots of problems, now with kernel 2.6.22.1-33.fc7 #1 Mon Jul 23 16:50:49 EDT 2007 ppc ppc ppc GNU/Linux. here are some syslog excerpts, one 'it worked', followed by the more common case of 'it barfed'... same card is working fine on fc6...
Hello, I'm reviewing this bug as part of the kernel bug triage project, an attempt to isolate current bugs in the fedora kernel. http://fedoraproject.org/wiki/KernelBugTriage I am CC'ing myself to this bug and will try and assist you in resolving it if I can. There hasn't been much activity on this bug for a while. Could you tell me if you are still having problems with the latest kernel? If the problem no longer exists then please close this bug or I'll do so in a few days if there is no additional information lodged. Cheers Chris
Created attachment 198341 [details] syslog output yes, I'm still having problems with this. Tested this morning with 2.6.22.5-76.fc7. After inserting a pcmcia flash card, I get lots of stuff zipping by on the console (much more that what is in the attached syslog output), in 3 spurts... 2 almost immediately, and another a few seconds later. Same card works perfect in fc6, fc5 (all ppc).
Okay, re-assigning to the relevant maintainer. Please could you attach the output from lspci -vvxx as well as lsmod. You may wish to try some of the following to assist in the resolution of this bug: * If it's repeatable, hooking up a serial cable to a second box can be useful for capturing kernel messages that may get printed just before the lockup. Configure the machine being debugged to boot with console=ttyS0,115200 console=tty0 and run a terminal program such as minicom on the other end. Configure the remote end to talk at the same baud rate (115200). (In minicom ctrl-a, p, i, enter. More info on setting up a serial terminal can be found at http://searchenterpriselinux.techtarget.com/tip/0,289483,sid39_gci1118136,00.html * Hooking up serial console / netconsole can sometimes get debug info out of the machine. * If the hang happened whilst in X, the machine may still respond to ssh logins from other machines. Try this to get a dmesg. * The magic sysrq key might work. Enable it with sysctl kernel.sysrq=1 (or put kernel.sysrq = 1 in your /etc/sysctl.conf). This will allow you to hit ctrl-alt-sysrq and various keys to get debugging info. m will dump information about the current state of memory t will dump the state of every task the kernel knows about s will sync all data pending writeback to disk. (This is useful so that this debug info actually stands a chance of hitting the log files.) * You can also trigger magic sysrq functions by echo'ing the relevant one letter command to /proc/sysrq-trigger * booting with nmi_watchdog=2 may cause a backtrace to occur when the lockup happens. Cheers Chris
Seems to be an arch code issue but will keep an eye out for other related reports
Created attachment 200761 [details] lsmod
Created attachment 200771 [details] lspci
Can you try changing the cardbus IO and memory window sizes? Add this to the kernel options in the bootloader config: cbiosize=512 cbmemsize=128M If that doesn't work, try 1024 and 256M.
setting cb* didn't help with 2.6.22.5-76.fc7 or the subsequent kernel. However, with those set to 1024/256, 2.6.22.9-91.fc7 is working! I haven't tried removing those vars to see if they are required, as I rarely reboot this machine... Closing this bug as resolved.. thanks for all who looked into it..
Created attachment 224481 [details] syslog of machine checks, again I spoke too soon.. On a freshly booted system, it seems that a card can be inserted once or twice... but inserting a card again a few days later results in a machine check. This attachment shows the check from a system that's been up a few days, then the results of a few inserts after reboots... This is with the latest kernel, and the kernel params mentioned earlier set (cb*).
Hello, Whats the latest on this - are you still experiencing this issue? You might want to test with a development kernel if you are able using: # yum update kernel --enablerepo=development
This is still a problem with the latest f7 kernel. I did test the development kernel briefly, and it did appear to handle multiple insert/ejects of a card ok, though I didn't actually use the card. the f9 kernel worked with and without the cb* parameters mentioned earlier.
Okay, thanks for the update. You might therefore want to test the 2.6.24 kernel when it is released as this may fix the issue for you.
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists. Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs: http://docs.fedoraproject.org/release-notes/ The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. Fedora 7 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.