Most recent kernel where this bug did not occur: _maybe_ 2.6.16 Distribution: Debian 'sid' Hardware Environment: IBM ThinkPad R51 Software Environment: Gnome 2.14.3 Problem Description: When reading or writing a CompactFlash card in a PCMCIA adapter sleeve, the system becomes sluggish to the point of X cursor movement becoming choppy. The problem goes away as soon as I/O to the card is finished. It does not seem to happen if the card is mount '-o sync' but I need to test this some more. This has been observed with various sizes and makes of CF card, and the CardBus controller bridge in this computer is identified as: 02:00.0 CardBus bridge: Texas Instruments PCI1510 PC card Cardbus Controller I reported this to the linux-thinkpad ML at the beginning of July and a month later someone else posted a 'me too': http://thread.gmane.org/gmane.linux.hardware.thinkpad/26547 You can disregard the bit about "disable_clkrun", I've not been using it and my cards are recognized. I don't recall this happening in the 2.6.16 kernel, but I am not for certain on this. Steps to reproduce: 1. Mount CompactFlash card 2. Do some I/O 3. During the operation, observe sluggish system response, cursor movement is choppy.
It would be good if you could confirm that this is or is not a regression relative to 2.6.16. And, if so, considering doing a git-bisect to find out what patch caused it? Thanks, Nish
I should revise my original report: this occurs with a specific CF card that I have, and it _does_ occur on 2.6.16. I cannot reproduce this with another 256MB CF card I have on any kernel version. On the "bad" card, running this command: dd if=/dev/urandom of=/media/hde1/file.out bs=1M count=50 and then syncing the buffers crashed my X server on 2.6.16, whereas on 2.6.18-rc4 it simply causes the machine to slow down significantly. Here is the result of 'hdparm -I /dev/hde' on that card: r51:~# hdparm -I /dev/hde /dev/hde: CompactFlash ATA device, with removable media Model Number: SanDisk SDCFB-256 Serial Number: X0716 20040310084412 Firmware Revision: Rev 0.00 Standards: Supported: 10 Likely used: 10 Configuration: Logical max current cylinders 695 695 heads 15 15 sectors/track 48 48 -- CHS current addressable sectors: 500400 LBA user addressable sectors: 500400 device size with M = 1024*1024: 244 MBytes device size with M = 1000*1000: 256 MBytes Capabilities: LBA, IORDY(may be)(cannot be disabled) Standby timer values: spec'd by Vendor R/W multiple sector transfer: Max = 1 Current = 0 DMA: not supported PIO: pio0 pio1 pio2 pio3 pio4 Cycle time: no flow control=120ns IORDY flow control=120ns I tried erasing the partition table and filesystem headers (dd if=/dev/zero of=/dev/hde bs=1k count=500), and repartitioning and formatting (VFAT) the card, but this makes no difference. I would say I have a defective or worn out card, but this has happened to at least one other person (see linux-thinkpad archive link), so I'm not so sure.
Well, phooey. This just showed up on a second card, different from the one I originally thought to be the culprit: /dev/hde: CompactFlash ATA device, with removable media Model Number: SAMSUNG CF/ATA Serial Number: Firmware Revision: S1.18.4 Standards: Likely used: 4 Configuration: Logical max current cylinders 992 992 heads 16 16 sectors/track 32 32 -- bytes/track: 0 bytes/sector: 512 CHS current addressable sectors: 507904 LBA user addressable sectors: 507904 device size with M = 1024*1024: 248 MBytes device size with M = 1000*1000: 260 MBytes Capabilities: LBA, IORDY(may be)(cannot be disabled) Buffer size: 1.0kB bytes avail on r/w long: 4 Standby timer values: spec'd by Vendor R/W multiple sector transfer: Max = 4 Current = 0 DMA: not supported PIO: pio0 pio1 pio2 It seems that this is not consistently reproducable, and if it is, I don't know what the parameters are. This card was in a digital camera and I took a number of photos (20-30 at least) and then tried to import them using the gThumb program from GNOME. Sure enough, as gThumb was reading the pictures to generate thumbnails the pointer motion became choppy and the compiz eyecandy animation stuff, which is normally smooth even under rather heavy system load (e.g. compiling software and running Firefox) became jerky and jumpy. As soon as I closed gThumb (e.g. stopped the reading) it was fine.
Maybe you don't have dma enabled on the device? Find out what device the card is given (on my Dell Precision M70 compact flash cards are /dev/hda_ # hdparm /dev/hda show that DMA is off. I am unable to enable dma on this device. I would expect the system to be sluggish if it were using PIO to write to the card.
As long as your CF card is using a 16-bit (passive) PCMCIA adapter sleeve, this will be the case, since PIO is the only access mode available. There are high performance CF adapters that support DMA; these are 32-bit devices. Google for "Delkin CF32A" for example. I don't know whether these work under Linux.
Any updates on the problem? Is this still the case with newer kernels? Thanks.
I'm getting the same issue with Kernel 2.6.23. Tested with both ide_cs and pata_pcmcia modules. However: What's weird is that I get this issue with 2 gig Kingston Elite Pro, 4 gig Sandisk Extreme III. However, I *don't* get this with an old 1 GB IBM Microdrive from 2001!. I'm using the PCMCIA adapter that I got with the microdrive all those years ago. Have to wonder what it does differently... Anyway, using -o sync does not help at least.
Are you still having this problem with current kernel? It sounds like some cards work well for you and some don't.
Its still around - it needs ata pio to be done with specific irq masking which is very very hard so won't happen for while
Yes, still around with 2.6.35. Using nice -20 for any processes accessing the CF makes things barely tolerable though.
This bug is against an obsolete kernel. Please test with newer kernel. Cheers Nick
Why bother? So that we can perhaps get this resolved and perhaps fixed in another 8 years? Anyway, at least I don't have the hardware (PCMCIA-CF adapter) anymore. Or even a laptop that has a PC card slot.
There is no point testing it. The underlying limitation is still present for ancient PIO devices on those configurations. It's extremely hard to fix and the devices are long gone. So why are you asking people to test it ?
I would recommend closing this then as there is no hardware like this any more. Cheers Nick
Will you please stop "recommending" and asking people to do things to bugs you clearly know nothing about. It's not fixed Now and then people working with old hardware hit it It's useful they can find this report
Here is an overview for CompactFlash for those who don't know https://www.everipedia.com/CompactFlash/