M. Warner Losh wrote: > : Problem was solved by increasing the number of answer read attempts in mmc_send_app_op_cond(). With attached patch (against latest driver version) card is recognized properly on ~ 190th attempt (while in original driver there are only 100 attempts). > : > : Furthermore, non-mine SDHC card is now also recognized in this cardreader (it doesn't even under Windows). In this case, it takes about 400 attempts to read answer. > > I think I bumped the number of iterations to 100 when I found that 10 > wasn't enough. 25 different cards worked just fine, but I got use of > a 16MB SD card at BSDcan that needed like 65. Bumping it from 100 to > 1000, however, makes the timeout go from 1s to 10s. That opens up > window for insertion races, but that's the only downside I see... Of > course, we want to fix those races, but this may expose them a little > more.. > > I can't believe that you had a card that took 4s to become active! > > Can you confirm the elapsed time is really 4s for that card? > Otherwise, this may be pointing out a bug in another area of the > code... Completely fortunate I have noticed that number of iterations depends on my laptop power source. After small investigation I have found that it actually depends on dev.cpu.0.freq value. With default value 2400 I have only several iterations. But every double frequency decrease doubles iteration count. With minimum value 100MHz I have more then 100 iterations. Same time it doesn't looks like this time is a real wall time. It looks like DELAY() used in a loop has some problems with time counting. -- Alexander MotinReceived on Wed Oct 15 2008 - 18:25:14 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:36 UTC