mmc_block module write failure

[Rocko]

Binary package hint: linux-image-2.6.24-19-generic

I consistently get write errors reported by mmc_block when writing to an SD card with the Ubuntu 8.04 amd64 kernel 2.6.24-19 amd64 kernel (it also was happening in earlier Hardy kernels).

The card is a 2GB card in the internal Ricoh card reader:

lspci |grep Ricoh
03:09.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 05)
03:09.1 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 22)
03:09.2 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 12)
03:09.3 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 12)

Steps to reproduce:

1. Format the card using gparted (to fat16 or fat32).

2. Copy almost 2GB of files to the card (no errors reported anywhere).

3. Delete the 2GB of files (ie completely).

4. Repeat step 2. This time errors are reported (see attached kernel.log).

5. Unmount the card, remount, check with diff. Diff reports differences in one or more of the files that was copied.

This is the same process as for bug #239647 but I filed that separately because that bug is to do with gnome-vfs not reporting the errors.

I also repeated steps 3-5 to generate a second kernel2.log, which shows an error from sdhci that might be related.

Note that reformatting with gparted seems to stop the errors from occurring until the card is 'filled' again.

[Rocko (rockorequin)]

This might be a duplicate of 247819.

I have noticed that I frequently get these I/O errors if I have a VM running under vmware-server (1.0.6), but they are rather more rare when no VM is running.

[Leann Ogasawara (leannogasawara)]

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

[Rocko (rockorequin)]

I tried the 2.6.27-2 kernel in alpha 5, and the bug is definitely still there. Although initially there seemed to be no problem, I found that if I am running a VM inside VirtualBox 2.0.2, I frequently get the write errors. This seems to match Hardy's kernel, where the write errors occur frequently if vmware or VBox is running, and less frequently otherwise.

One difference is that the copy in Intrepid seems to complete faster when there are errors (Hardy slows right down).

Just like in Hardy, nautilus in Intrepid did not warn that errors had occurred during the copy (it completed normally), even though the messages log showed the errors.

A subsequent diff reported differences between the files.

I installed the 2.6.27-3 kernel this morning to try it but virtualbox no longer ran so I gave up (temporarily!).

[Rocko (rockorequin)]

Confirmed in 2.6.27-3.

When I removed the card and reinserted it, nautilus hung while the mmc_block driver attempted to keep writing. It tries whether the card is there or not and stops all other disk operations - it's not even possible to open a new nautilus window. So I'll open another bug for this.

[Rocko (rockorequin)]

Still present in 2.6.27-4.

And gnome-vfs still doesn't let you know there was an error - if you are moving a file, you lose data.

[penalvch (penalvch)]

Rocko, thank you for reporting this and helping make Ubuntu better. Hardy desktop reached EOL on May 12, 2011.
Please see this document for currently supported Ubuntu releases:
https://wiki.ubuntu.com/Releases

We were wondering if this is still an issue in a supported release? If so, could you please test for this with the latest development release of Ubuntu? ISO CD images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Please do not test the kernel in the mainline kernels archive directory daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.7-rc1-quantal

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

If you are unable to test the mainline kernel, please comment as to why specifically you were unable to test it and add the following tags:
kernel-unable-to-test-upstream
kernel-unable-to-test-upstream-VERSION-NUMBER

Please let us know your results. Thank you for your understanding.

Helpful bug reporting tips:
https://help.ubuntu.com/community/ReportingBugs

[Rocko (rockorequin)]

Actually, I think this was fixed some time ago. I don't recall running into issues with Precise.

[penalvch (penalvch)]

Rocko, ok. Did you need a backport to a release prior to Precise or may this bug report be closed with Status Invalid?

[Rocko (rockorequin)]

No, that's fine, thanks for the offer, though.

[penalvch (penalvch)]

Rocko, this bug report is being closed due to your last comment https://bugs.launchpad.net/ubuntu/+source/linux/+bug/239649/comments/9 regarding this being fixed with an update. For future reference you can manage the status of your own bugs by clicking on the current status in the yellow line and then choosing a new status in the revealed drop down box. You can learn more about bug statuses at https://wiki.ubuntu.com/Bugs/Status. Thank you again for taking the time to report this bug and helping to make Ubuntu better. Please submit any future bugs you may find.