SD Card performance in R-Pi onboard slot


280 posts   Page 6 of 12   1 ... 3, 4, 5, 6, 7, 8, 9 ... 12
by texy » Thu Jun 14, 2012 7:03 pm
dmesg | less

will show the boot up log, use q to exit.

Texy
"2.8inch TFT LCD + Touch screen" add-on boards for sale here :
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=93&t=65566
50p goes to the Foundation ;-)
Moderator
Moderator
Posts: 2204
Joined: Sat Mar 03, 2012 10:59 am
Location: Berkshire, England
by Lob0426 » Thu Jun 14, 2012 8:54 pm
I need the storage location of the last boot log. I cannot enter commands on that card. It will not go to a prompt.

I am pretty sure the card has had a failure that is not letting it act as a boot device. I get the same error even though I reimaged it. I can see files in the root when I put into my netbook with Ubuntu. I would be interested if there is a utility that could recover this card.
Back-powered 256MB as WordPress Server
Motorola Lapdock with 512MB
Modded Rev 1.0 with pin headers at USB

http://rich1.dyndns.tv/
(RS)Allied ships old stock to reward its Customers for long wait!
User avatar
Posts: 1868
Joined: Fri Aug 05, 2011 4:30 pm
Location: Susanville CA.
by AndrewS » Fri Jun 15, 2012 1:51 am
Lob0426 wrote:I need the storage location of the last boot log. I cannot enter commands on that card. It will not go to a prompt.

/var/log/ on the ext4 partition (partition 3 on the standard Debian image).

Can you backup your current kernel.img and then try renaming kernel_emergency.img to kernel.img and see if that gets a successful boot?
User avatar
Posts: 2193
Joined: Sun Apr 22, 2012 4:50 pm
Location: Cambridge, UK
by AndrewS » Fri Jun 15, 2012 1:56 am
stevethesimtec wrote:
I'm fairly sure there's no need to run rpi-update multiple times - just running it once followed by a reboot should be enough.

I've run through the process twice now, and in both cases, I had to run rpi-update 3 times. You must run it until it's clean i.e. no errors reported else you risk boot failure

Sorry to split hairs, but are you sure that's true? i.e. if you run rpi-update just once (ignoring any errors) and then reboot, do you get a boot failure? :(
The only reason I ask is because there's nothing different rpi-update does on the 3rd time it's run than the first time it's run :?
User avatar
Posts: 2193
Joined: Sun Apr 22, 2012 4:50 pm
Location: Cambridge, UK
by asb » Fri Jun 15, 2012 7:22 am
AndrewS wrote:
asb wrote:It should be safe to do rpi-update. However, the wheezy image now has the firmware packaged as .debs meaning you will be able to apt-get update && apt-get upgrade.

If the firmware can now be updated by rpi-update or by apt-get, will apt-get get confused/upset if the two are intermixed, i.e. if you apt-get the firmware and then later on rpi-update overwrites it?
Would it make sense to tweak rpi-update to just print "use apt-get instead" if it detects that the firmware .deb is installed :?:


Either one should happily just overwrite files installed by the other as far as I know. rpi-update is always going to give you the latest "bleeding edge" build, while the latest firmware available from the Foundation apt repository may be a little older (e.g. we would wait for a few days of testing before pushing out the firmware version with SD changes). I intend to have a 'bleeding edge' apt repository though, which will update whenever the firmware repo is pushed to. You can use whichever you prefer.
Moderator
Moderator
Posts: 757
Joined: Fri Sep 16, 2011 7:16 pm
by AndrewS » Fri Jun 15, 2012 9:31 am
asb wrote:
AndrewS wrote:Either one should happily just overwrite files installed by the other as far as I know. You can use whichever you prefer.

Great! :)
User avatar
Posts: 2193
Joined: Sun Apr 22, 2012 4:50 pm
Location: Cambridge, UK
by lingon » Fri Jun 15, 2012 10:08 pm
I upgraded the Wheezy image to the new firmware and kernel.
It runs great on a Transcend 8 GB Class 6 150X card.

/dev/mmcblk0p1:
Timing cached reads: 288 MB in 2.01 seconds = 143.27 MB/sec
Timing buffered disk reads: 56 MB in 2.91 seconds = 19.26 MB/sec

/dev/mmcblk0p1:
Timing O_DIRECT cached reads: 44 MB in 2.03 seconds = 21.66 MB/sec
Timing O_DIRECT disk reads: 56 MB in 2.59 seconds = 21.66 MB/sec

Starting applications is now significantly faster than what it is with the Debian image from the 19th of April.

Unfortunately the very same image copied to a SanDisk Extreme Pro 16 GB UHS-I 45 MB/s card will not boot. Has anyone been able to get a UHS-I SD-card working with the new firmware?
Posts: 101
Joined: Fri Aug 26, 2011 7:31 am
by lb » Fri Jun 15, 2012 10:37 pm
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.
Posts: 191
Joined: Sat Jan 28, 2012 8:07 pm
by Lob0426 » Sat Jun 16, 2012 12:04 am
@lb I have a SanDisk ultra 8GB class 6 that quit working after the new kernel. The kernel is 3.2.19+ 3. From Chris' site. No matter what I did it would fail just after the keyboard loaded. Then it times out waiting for interrupt. Hope this helps. It is a brand new card.
Back-powered 256MB as WordPress Server
Motorola Lapdock with 512MB
Modded Rev 1.0 with pin headers at USB

http://rich1.dyndns.tv/
(RS)Allied ships old stock to reward its Customers for long wait!
User avatar
Posts: 1868
Joined: Fri Aug 05, 2011 4:30 pm
Location: Susanville CA.
by dom » Sat Jun 16, 2012 12:22 am
@lob0426
Does adding:
sdhci-bcm2708.allow_highspeed=0
to cmdline.txt help?
Moderator
Moderator
Posts: 3861
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by Lob0426 » Sat Jun 16, 2012 12:50 am
I emptied the card to perform a complete and full format. I will reset it up and give that a try. I knew I should have rebuilt it last night ;)
Back-powered 256MB as WordPress Server
Motorola Lapdock with 512MB
Modded Rev 1.0 with pin headers at USB

http://rich1.dyndns.tv/
(RS)Allied ships old stock to reward its Customers for long wait!
User avatar
Posts: 1868
Joined: Fri Aug 05, 2011 4:30 pm
Location: Susanville CA.
by Lob0426 » Sat Jun 16, 2012 1:43 am
@dom
I pasted this:
sdhci-bcm2708.allow_highspeed=0
at the end of the lines in cmdline.txt after placing a space at the end. No boot. No "waiting for interrupt" message now either.
Back-powered 256MB as WordPress Server
Motorola Lapdock with 512MB
Modded Rev 1.0 with pin headers at USB

http://rich1.dyndns.tv/
(RS)Allied ships old stock to reward its Customers for long wait!
User avatar
Posts: 1868
Joined: Fri Aug 05, 2011 4:30 pm
Location: Susanville CA.
by dom » Sat Jun 16, 2012 8:59 am
@Lob0426
How exactly does it not boot? Rainbow of death?
(http://elinux.org/R-Pi_Troubleshooting# ... ash_screen)
Moderator
Moderator
Posts: 3861
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by lanlafi » Sat Jun 16, 2012 9:00 am
I have a Raspbian image installed on a Samsung MicroSDHC 8GByte Class 10 card. It provided 4.5 MByte/sec read and write sec before the update.
I did rpi-update Today, and now it goes so much faster:

root@pisces:~# hdparm -tT /dev/mmcblk0

/dev/mmcblk0:
Timing cached reads: 232 MB in 2.01 seconds = 115.40 MB/sec
Timing buffered disk reads: 46 MB in 3.07 seconds = 14.99 MB/sec
root@pisces:~# hdparm --direct -tT /dev/mmcblk0

/dev/mmcblk0:
Timing O_DIRECT cached reads: 42 MB in 2.02 seconds = 20.84 MB/sec
Timing O_DIRECT disk reads: 64 MB in 3.07 seconds = 20.85 MB/sec
root@pisces:~# uname -a
Linux pisces 3.1.9+ #110 PREEMPT Wed Jun 13 11:41:58 BST 2012 armv6l GNU/Linux

raspbian@pisces:~$ dd if=/dev/zero of=100mb.bin bs=1M count=100 oflag=direct
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 7.11826 s, 14.7 MB/s

So, basicly both read and write is 3 times faster than it was before the update. I am quite happy with this now.

Sometimes I get in dmesg:

[ 268.499090] mmc0: missed completion of cmd 17 DMA (512/512 [1]/[1]) - ignoring it
[ 268.506638] mmc0: DMA IRQ 6 ignored - results were reset

But this happened with the old firmware/kernel also. Can someone tell me what does it mean?
Posts: 16
Joined: Sat Jun 02, 2012 9:15 am
by lb » Sat Jun 16, 2012 10:16 am
Lob0426 wrote:@lb I have a SanDisk ultra 8GB class 6 that quit working after the new kernel. The kernel is 3.2.19+ 3. From Chris' site. No matter what I did it would fail just after the keyboard loaded. Then it times out waiting for interrupt. Hope this helps. It is a brand new card.


Well, bootc's kernel doesn't contain the fixes (yet). Just use the 3.1 kernel for now, or compile a kernel with these sources.

If you no video output at all, it's unlikely to help, though.
Posts: 191
Joined: Sat Jan 28, 2012 8:07 pm
by rgh » Sat Jun 16, 2012 2:56 pm
I ran rpi-update today for the first time in about 3 weeks and it has broken the sdcard interface for me... I now get frequent pauses when writing and this in the dmesg output:

[ 810.440790] mmc0: final write to SD card still running
[ 820.428004] mmc0: Timeout waiting for hardware interrupt - cmd12.
[ 820.429186] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900

I never saw those messages before running rpi-update. This is with a SanDisk Ultra class 6 8GB card.

Something like this: "dd if=/dev/zero of=16MB bs=4096 count=4096; sync" seems to trigger one occurrence of those messages pretty reliably (though not every time).
Posts: 219
Joined: Fri Nov 25, 2011 3:53 pm
by dom » Sat Jun 16, 2012 3:03 pm
@rgh
Can you grab the previous kernel.img (https://github.com/raspberrypi/firmware ... kernel.img)
and add:
init_emmc_clock=80000000
to config.txt, and report if the errors go away.
Moderator
Moderator
Posts: 3861
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by lb » Sat Jun 16, 2012 3:05 pm
CMD12 is used to stop a multiblock transfer, in your case a multiblock write. Maybe your card happens to be extraordinarily slow at this, or something like that. Does it help if you add "sdhci-bcm2708.allow_highspeed=0" to /boot/cmdline.txt? That slows down the SD interface (which shouldn't be needed) and might help.

EDIT: Note that this only works with the newest kernel. Please try out dom's advice first, this is independent of it.
Posts: 191
Joined: Sat Jan 28, 2012 8:07 pm
by NickT » Sat Jun 16, 2012 3:24 pm
rgh wrote:I ran rpi-update today for the first time in about 3 weeks and it has broken the sdcard interface for me... I now get frequent pauses when writing and this in the dmesg output:

[ 810.440790] mmc0: final write to SD card still running
[ 820.428004] mmc0: Timeout waiting for hardware interrupt - cmd12.
[ 820.429186] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900

I never saw those messages before running rpi-update. This is with a SanDisk Ultra class 6 8GB card.

Something like this: "dd if=/dev/zero of=16MB bs=4096 count=4096; sync" seems to trigger one occurrence of those messages pretty reliably (though not every time).


I did report similar problems a couple of days ago, over in this threadhttp://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=8342&sid=9a5f15ec0ebe43b32f79bf91fb9fedbe. (It may not have had the best title) . I originally thought that it was down to my building of the kernel. However acting on the suggestion in the thread I did install a stock kernel which I rpi-updated. The errors remained. That thread didn't seem to get much of a response, so rather than posting it all again, you might find it useful to read it through. It does confirm what you are experiencing. For the reasons explained in my last post in that thread, I'm not able to do any more testing on the issue.
User avatar
Posts: 91
Joined: Mon May 21, 2012 10:43 am
by rgh » Sat Jun 16, 2012 3:26 pm
@dom
The previous kernel works fine.

@lb
It writes at about 4MB/s with the previous kernel, and it's a SanDisk Ultra class 6, so I don't think it is extraordinarily slow. Here's me timing a 64MB write with the previous kernel:

richard@raspberrypi:~/Panalyzer$ time /bin/bash -c 'dd if=/dev/zero of=zz bs=1024k count=64; sync'
64+0 records in
64+0 records out
67108864 bytes (67 MB) copied, 13.2856 s, 5.1 MB/s

real 0m15.805s
user 0m0.010s
sys 0m1.540s
richard@raspberrypi:~/Panalyzer$


I also tried "sdhci-bcm2708.allow_highspeed=0" with the new kernel and it did not help.

Thanks..
Posts: 219
Joined: Fri Nov 25, 2011 3:53 pm
by lb » Sat Jun 16, 2012 3:33 pm
I think there might be something wrong with timeout calculations. I'd like to debug this, are you willing to test a new kernel image?
Posts: 191
Joined: Sat Jan 28, 2012 8:07 pm
by dom » Sat Jun 16, 2012 3:37 pm
@lb
I believe we used to hit this failure mode, and this was the commit that cured it:
https://github.com/raspberrypi/linux/co ... a53dbbc1a0

Your change does revert much of that commit, which I guess is why this problem has returned.
Any idea what might be needed to get the high speed and long erase times handled?
Moderator
Moderator
Posts: 3861
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by lb » Sat Jun 16, 2012 3:41 pm
@dom

Maybe get_timeout_clock needs to be restored, that's what I meant with my last post. I'll post a patch and kernel image for testing in a minute.
Posts: 191
Joined: Sat Jan 28, 2012 8:07 pm
by rgh » Sat Jun 16, 2012 3:44 pm
@lb
sure, I can test kernels for you
Posts: 219
Joined: Fri Nov 25, 2011 3:53 pm
by lb » Sat Jun 16, 2012 7:22 pm
@rgh

I think I found the problem. I forgot to properly raise the timeout counter when I reduced the poll interval in commit d64b84. I've now raised the counter to wait a maximum of 150ms, which is hopefully enough even for very slow cards. The old maximum was 100ms, and my error lead to a maximum of 30ms. Please try this kernel image or this patch if you want to compile yourself.

I have also added some debugging output that'll report if cards react slowly, but this should be removed later. Please tell what it reports for your card.

BTW: the kernel itself uses a downright insane write timeout (3000 ms), it looks like there are some cards that are just unbelievably crappy.
Posts: 191
Joined: Sat Jan 28, 2012 8:07 pm