Thanks. Expect to see a new kernel from me soon!dom wrote:lb has provided a clean set of sdcard patched here:
https://github.com/grigorig/rpi-linux/c ... rf-cleanup
I've picked up all the patches from this branch, so I'd think it sensible for you to do so to.
Careful, that branch doesn't apply cleanly, and it's missing an important patch. I've ported the changes over to the 3.2 kernel and added selsinork's fix for signaling voltage, it's in the rpi-3.2.19-sdhci branch.bootc wrote: Thanks. Expect to see a new kernel from me soon!
Thanks. I'll use your branch instead.lb wrote:Careful, that branch doesn't apply cleanly, and it's missing an important patch. I've ported the changes over to the 3.2 kernel and added selsinork's fix for signaling voltage, it's in the rpi-3.2.19-sdhci branch.
Recommendation is to update using https://github.com/Hexxeh/rpi-updateajack wrote:Is anybody maintaining a website or specific link for kernel update?
Yes, the patches were merged and the current build at github.com/raspberrypi/firmware includes them.ajack wrote:Is the kernel 3.1.9 going to be updated with the latest SD card patches? I know it has been done on a 3.2 kernel, but that breaks omxplayer.
Seriously ? lb's driver is much better than the original. Wider exposure to many more cards can only help improve it, but you can never deal with everything - especially a card that hasn't been designed yet and won't be in users hands until a year from now but has some behaviour that's different.rew wrote:lb, you're not programming for some cards some of the time, but for ALL cards ALL of the time.
Again, that's fine, up to a point. But sooner or later you need to decide the cards got itself confused, is actually dead, or the user has removed it, it's not going to talk to us again, ever, and timeout.rew wrote:All this is very unlikely. You can't cause it to happen. But in times of "difficulties" you should let the card do its thing and not timeout before it has has had a chance to fix things.
Go buy an 'enterprise' drive, they give up and timeout in seconds. They then return the error to the OS that actually has the smarts to do something about it instead of freezing the system for a minute. Google for people using desktop class drives in NAS devices with raid for lots of details on how pointless that minute long recovery procedure is. Then think about the manufacturer protecting the margins on it's expensive enterprise drives by a simple firmware mod to the otherwise identical desktop drive to prevent it's use for certain things.rew wrote:A harddisk having trouble will sometimes initiate a recovery procedure that takes more than a minute. Linux times out and resets the drive after 30 seconds. The manufacturer decided that it was useful to keep on trying that second half-minute. So why try to outsmart them??
The terrible thing is that currently the driver does busy-waiting until the timeout runs out, if the card is slow. Continually freezing the whole system for up to 3 seconds (in the worst case) wouldn't be a good idea. There's a better solution to this, but it isn't trivial. I'm already looking at it, though.rurwin wrote: It follows that hitting a timeout should be a last resort. There should be no conceivable chance that a situation is still recoverable when the timeout is triggered. Timeouts should not be set anywhere near the normal operating point. They should be as far away as practical.
So rather than 150 milliseconds, I would be asking what was so terrible about 1 second (or even 3). It will take at least that long to recover if the timeout triggers, and the user is not likely to notice any difference.
Today I upgraded to the Debian Wheezy Betalb wrote:lingon, what kernel and firmware version are you using for the UHS-1 card? How does booting fail (at what stage, and if applicable, what kinds of errors)?
If you used the Wheezy image as-is, a manual update of kernel and firmware might help.
I think it's harmless. CMD17 is a single-block read. This is seldom used, and maybe the command simply finishes too quickly for the controller.dom wrote: [ 21.317631] mmc0: missed completion of cmd 17 DMA (512/512 /) - ignoring it
[ 21.331364] mmc0: DMA IRQ 6 ignored - results were reset
Users browsing this forum: Yahoo [Bot] and 38 guests