Has anyone noticed this affecting the RaspberryPi?

[Scribe]

http://jeffbastian.blogspot.com/2011/09 ... peeds.html

I happen to own a PandaBoard and right now on all kernel since 2.6.35 they\'re experiencing dire SD card speeds.

Has anyone with a RaspberryPi alpha noticed if this issue affects them?

Cheers

[abishur]

Yep yep Jamesh posted some speed results from transferring files to an SD card and noted that they were going a little slower than they should.

[Scribe]

*sigh* Looks like I\'ll be sticking with an old kernel for now! How could they let a big speed hit like those reported stay in the kernel for so long =(

[jamesh]

Interesting....

[asb]

[quote]Quote from abishur on October 8, 2011, 15:48
Yep yep Jamesh posted some speed results from transferring files to an SD card and noted that they were going a little slower than they should.[/quote]

But that blog post lists 2.6.35 as the \'good\' kernel, and the current images are using 2.6.35.7.

[abishur]

color me corrected then

[pepedog]

If the sd card is via usb systems, there is a patch, I applied it to my trimslice kernel (also arm7) 2.6.38.3 (and patch works on 3.1), speeds went up 5 fold.
http://www.trimslice.com/forum/viewtopic.php?f=36&t=277

[Scribe]

Hehe for me as long as this issue doesn\'t make it to one of the pre-built environments on release

[jamesh]

The SD card is connected directly to the SoC, not via USB.

[hippy]

I imagine these things happen all the time. Some change breaks something else, it gets investigated, gets fixed, and there\'s nothing to worry about, except perhaps if it doesn\'t get fixed. Worth noting and keeping an eye on but likely not worth fretting over.

[david13lt]

[quote]Quote from hippy on October 9, 2011, 19:18
I imagine these things happen all the time. Some change breaks something else, it gets investigated, gets fixed, and there\'s nothing to worry about, except perhaps if it doesn\'t get fixed. Worth noting and keeping an eye on but likely not worth fretting over.[/quote]

It happens that some problems are dragged over several kernel releases, e.g., power consumption problem. Sometimes updates to drivers are not pushed to mainstream kernel tree for months, even years, e.g. libertas_tf driver. The SDIO interface for this driver is developed by the driver author, but was never actually pushed to mainstream kernel even thought it is used by other people/projects. There other issues with companies and their kernel development, e.g. Broadcom refuses to support b43 driver (reverse-engineered driver with wide HW support). But they now developed their driver (actually two), but they are quite poor and community is not supporting their driver in the mainline, so they are still stuck in the staging (probably for a long time...).