lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 19 Jul 2011 14:43:04 -0500 (CDT)
From:	Manoj Iyer <manoj.iyer@...onical.com>
To:	Chris Ball <cjb@...top.org>
cc:	Manoj Iyer <manoj.iyer@...onical.com>,
	Arnd Bergmann <arnd@...db.de>, linux-kernel@...r.kernel.org,
	jbarnes@...tuousgeek.org, matsumur@....ricoh.co.jp,
	linux-pci@...r.kernel.org, linux-mmc@...r.kernel.org
Subject: Re: [PATCH] mmc: Added quirks for Ricoh 1180:e823 lower base clock
 frequency


Here is flashbench data on Ricoh R5C822 for SanDisk SDSDXP1-016G-A75 16GB 
Extreme Pro SDHC Memory Card. Dell XPS 1330M (Ubuntu Natty).

manjo@...epy:~/Projects/flashbench$ sudo ./flashbench -a /dev/mmcblk0p1
[sudo] password for manjo:
align 4294967296        pre 1.91ms      on 1.92ms       post 1.92ms 
diff 4.46µs
align 2147483648        pre 1.99ms      on 1.99ms       post 1.99ms 
diff -642ns
align 1073741824        pre 1.99ms      on 1.99ms       post 1.99ms 
diff 435ns
align 536870912 pre 1.99ms      on 1.99ms       post 1.99ms     diff 
-1003ns
align 268435456 pre 1.99ms      on 1.99ms       post 1.99ms     diff 
-283ns
align 134217728 pre 1.99ms      on 1.99ms       post 1.99ms     diff 539ns
align 67108864  pre 1.92ms      on 1.91ms       post 1.91ms     diff 75ns
align 33554432  pre 1.97ms      on 2.01ms       post 1.97ms     diff 41µs
align 16777216  pre 1.98ms      on 2.02ms       post 1.97ms     diff 
43.9µs
align 8388608   pre 1.97ms      on 1.97ms       post 1.98ms     diff 
-3481ns
align 4194304   pre 2.22ms      on 2.39ms       post 1.97ms     diff 292µs
align 2097152   pre 2.29ms      on 2.29ms       post 2.3ms      diff 
-3058ns
align 1048576   pre 2.22ms      on 2.22ms       post 2.21ms     diff 100ns
align 524288    pre 2.22ms      on 2.21ms       post 2.21ms     diff 
-728ns
align 262144    pre 2.24ms      on 2.24ms       post 2.24ms     diff 
5.13µs
align 131072    pre 2.25ms      on 2.24ms       post 2.24ms     diff 275ns
align 65536     pre 2.23ms      on 2.23ms       post 2.23ms     diff 1.7µs
align 32768     pre 2.24ms      on 2.23ms       post 2.23ms     diff 
-2799ns

manjo@...epy:~/Projects/flashbench$ sudo ./flashbench -O --erasesize=$[4 * 
1024 * 1024] --blocksize=$[256 * 1024] /dev/mmcblk0p1 --open-au-nr=2
4MiB    9.96M/s
2MiB    11.2M/s
1MiB    11.2M/s
512KiB  11.2M/s
256KiB  11.2M/s
manjo@...epy:~/Projects/flashbench$


> Hi Manoj,
>
> On Mon, Jul 18 2011, Manoj Iyer wrote:
>> Right, without the patch I get..
>>
>> [   52.526665] mmc0: new SDHC card at address e624
>> [   52.571228] mmcblk0: mmc0:e624 SD16G 14.8 GiB
>> [   52.591071] mmcblk0: retrying using single block read
>> [   52.593105] mmcblk0: error -84 transferring data, sector 0, nr 8,
>> card status 0x900
>> [   52.593109] end_request: I/O error, dev mmcblk0, sector 0
>> [   52.594594] mmcblk0: error -84 transferring data, sector 1, nr 7,
>> card status 0x900
>> [   52.594604] end_request: I/O error, dev mmcblk0, sector 1
>> [   52.602893] quiet_error: 24 callbacks suppressed
>> [   52.602902] Buffer I/O error on device mmcblk0, logical block 0
>> [   52.605349] ldm_validate_partition_table(): Disk read failed.
>> [   52.605384] Dev mmcblk0: unable to read RDB block 0
>> [   52.607729]  mmcblk0: unable to read partition table
>> u@u:~$
>>
>> So, I cannot generate any comparison data with this SD card.
>
> I see, thanks.  So we're lacking any data on what speed the card would
> normally provide.  Perhaps you could try that card on a different
> controller, just so we're able to see whether it's usually possible
> to get closer to 45M/sec with it?
>
> I think I'll take your patch as-is for 3.1 -- since if there is a
> performance degradation, it's on cards that simply don't work at all
> right now -- and if you're able to work on a followup patch that only
> performs the clock-lowering after the first error, I think that'd be a
> handy patch to have around.  Does that sound good?
>
> Thanks!
>
> - Chris.
> -- 
> Chris Ball   <cjb@...top.org>   <http://printf.net/>
> One Laptop Per Child
>
>

--
====================
Manoj Iyer
Ubuntu/Canonical
Hardware Enablement
====================

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ