Sinetek's Driver for Realtek "RTSX" SDHC Card Readers

lucatek · April 13, 2020

@cholonam can you help me with my card reader RTA522A please...

cholonam · April 14, 2020

@lucatek @carlinyos I have not even started with power management, so I am happy I'm not getting a kernel panic after wake up... PM will have to wait for next release, since it may take another weekend of work. For the time being you can either disable sleep or unload/load the kext after wakeup. Since it seems at least the code is not crashing or causing data corruption, I'll make a release on GitHub. This (or next) weekend I'll look into power management.

For those with chips other than RTS525A, I have made some changes, basically to disable the code added from the Linux driver for those chips (the code added applies only to 525A). That may solve the issues, but I can't promise anything. Those changes will be on the GitHub release, which I will do later today or tomorrow.

carlinyos · April 14, 2020

12 hours ago, cholonam said:

@lucatek @carlinyos I have not even started with power management, so I am happy I'm not getting a kernel panic after wake up... PM will have to wait for next release, since it may take another weekend of work. For the time being you can either disable sleep or unload/load the kext after wakeup. Since it seems at least the code is not crashing or causing data corruption, I'll make a release on GitHub. This (or next) weekend I'll look into power management.

For those with chips other than RTS525A, I have made some changes, basically to disable the code added from the Linux driver for those chips (the code added applies only to 525A). That may solve the issues, but I can't promise anything. Those changes will be on the GitHub release, which I will do later today or tomorrow.

Tried to unload, but kext says that there're still instances.

Edited April 14, 2020 by carlinyos
typo

lucatek · April 14, 2020

17 hours ago, cholonam said:

@lucatek @carlinyos I have not even started with power management, so I am happy I'm not getting a kernel panic after wake up... PM will have to wait for next release, since it may take another weekend of work. For the time being you can either disable sleep or unload/load the kext after wakeup. Since it seems at least the code is not crashing or causing data corruption, I'll make a release on GitHub. This (or next) weekend I'll look into power management.

For those with chips other than RTS525A, I have made some changes, basically to disable the code added from the Linux driver for those chips (the code added applies only to 525A). That may solve the issues, but I can't promise anything. Those changes will be on the GitHub release, which I will do later today or tomorrow.

Thanks @carlinyos I waiting you for your KEXT...

THANK YOU

cholonam · April 14, 2020

5 hours ago, carlinyos said:

Tried to unload, but kext says that there're still instances.

Just unloading doesn't work. I'm not sure if that's the expected behavior or something that's not being correctly freed, but what you have to do to unload the kext is to unload the Sinetek_rtsx class first, then the kext (check the "ku" script in the test folder on my github).

cholonam · April 15, 2020

2 hours ago, Hervé said:

@cholonam No change with kext v2.0 posted on Github earlier: same inability to access the card inserted in the RTS525a reader of my Latitude 7490. If the card's insertion and ejection are detected immediately and repeatedly, it just cannot be mounted therefore not read nor written to. Card reader not functional after wake as expected (contrary to behaviour with kext v1.0).

On card's insertion:

In Disk Utility, card visible but not mounted:

When attempting to mount the card in DU, the following error is returned:

-->

Here's what the log shows on inserting and ejecting the microSD card:

Hide contents

2020-04-15 11:10:34.770917+0200 0x475 Default 0x0 0 0 kernel: (Sinetek-rtsx) rtsx: Sinetek_rtsx::init : Writing is enabled

2020-04-15 11:10:34.770927+0200 0x475 Default 0x0 0 0 kernel: Sinetek_rtsx::probe(PXSX)

2020-04-15 11:10:34.771756+0200 0x475 Default 0x0 0 0 kernel: (Sinetek-rtsx) rtsx: rtsx_init : FORCE_CLKREQ_0 found

2020-04-15 11:10:34.772837+0200 0x475 Default 0x0 0 0 kernel: (Sinetek-rtsx) rtsx: Sinetek_rtsx::start : Driver started (release version)

2020-04-15 11:10:36.723267+0200 0x49d Default 0x0 0 0 kernel: (Sinetek-rtsx) rtsx: rtsx_init : FORCE_CLKREQ_0 found

2020-04-15 11:10:36.725204+0200 0x49d Default 0x0 0 0 kernel: (Sinetek-rtsx) rtsx: rtsx_init : FORCE_CLKREQ_0 found

2020-04-15 11:11:06.091786+0200 0x49d Default 0x0 0 0 kernel: (Sinetek-rtsx) rtsx: rtsx_init : FORCE_CLKREQ_0 found

2020-04-15 11:11:08.915162+0200 0x49d Default 0x0 0 0 kernel: (Sinetek-rtsx) rtsx: SDDisk::attach : SDDisk attaching...

2020-04-15 11:11:08.915172+0200 0x49d Default 0x0 0 0 kernel: (Sinetek-rtsx) rtsx: SDDisk::attach : SDDisk attached

2020-04-15 11:11:09.038410+0200 0x49d Error 0x0 0 0 kernel: (Sinetek-rtsx) rtsx: SDDisk::read_task_impl_ : Returning an IO Error! (error = 60)

2020-04-15 11:14:09.109603+0200 0x49d Error 0x0 0 0 kernel: (Sinetek-rtsx) rtsx: SDDisk::read_task_impl_ : Returning an IO Error! (error = 60)

2020-04-15 11:14:12.313922+0200 0x6f Default 0x0 0 0 kernel: (Sinetek-rtsx) rtsx: SDDisk::detach : SDDisk detaching...

2020-04-15 11:14:12.313958+0200 0x6f Default 0x0 0 0 kernel: (Sinetek-rtsx) rtsx: SDDisk::detach : SDDisk detached.

2020-04-15 11:14:12.315457+0200 0x49d Default 0x0 0 0 kernel: (Sinetek-rtsx) rtsx: rtsx_init : FORCE_CLKREQ_0 found

2020-04-15 11:14:14.237964+0200 0x49d Default 0x0 0 0 kernel: (Sinetek-rtsx) rtsx: SDDisk::attach : SDDisk attaching...

2020-04-15 11:14:14.238048+0200 0x49d Default 0x0 0 0 kernel: (Sinetek-rtsx) rtsx: SDDisk::attach : SDDisk attached

2020-04-15 11:14:14.499240+0200 0x49d Error 0x0 0 0 kernel: (Sinetek-rtsx) rtsx: SDDisk::read_task_impl_ : Returning an IO Error! (error = 60)

2020-04-15 11:14:14.649793+0200 0x49d Error 0x0 0 0 kernel: (Sinetek-rtsx) rtsx: SDDisk::read_task_impl_ : Returning an IO Error! (error = 60)

2020-04-15 11:14:17.227633+0200 0x6f Default 0x0 0 0 kernel: (Sinetek-rtsx) rtsx: SDDisk::detach : SDDisk detaching...

2020-04-15 11:14:17.227673+0200 0x6f Default 0x0 0 0 kernel: (Sinetek-rtsx) rtsx: SDDisk::detach : SDDisk detached.

2020-04-15 11:14:17.229080+0200 0x49d Default 0x0 0 0 kernel: (Sinetek-rtsx) rtsx: rtsx_init : FORCE_CLKREQ_0 found

2020-04-15 11:14:25.178356+0200 0x49d Default 0x0 0 0 kernel: (Sinetek-rtsx) rtsx: SDDisk::attach : SDDisk attaching...

2020-04-15 11:14:25.178377+0200 0x49d Default 0x0 0 0 kernel: (Sinetek-rtsx) rtsx: SDDisk::attach : SDDisk attached

2020-04-15 11:14:25.304280+0200 0x49d Error 0x0 0 0 kernel: (Sinetek-rtsx) rtsx: SDDisk::read_task_impl_ : Returning an IO Error! (error = 60)

2020-04-15 11:14:25.448277+0200 0x49d Error 0x0 0 0 kernel: (Sinetek-rtsx) rtsx: SDDisk::read_task_impl_ : Returning an IO Error! (error = 60)

2020-04-15 11:14:40.440735+0200 0x49d Error 0x0 0 0 kernel: (Sinetek-rtsx) rtsx: SDDisk::read_task_impl_ : Returning an IO Error! (error = 60)

2020-04-15 11:14:58.408258+0200 0x6f Default 0x0 0 0 kernel: (Sinetek-rtsx) rtsx: SDDisk::detach : SDDisk detaching...

2020-04-15 11:14:58.408302+0200 0x6f Default 0x0 0 0 kernel: (Sinetek-rtsx) rtsx: SDDisk::detach : SDDisk detached.

2020-04-15 11:14:58.409695+0200 0x49d Default 0x0 0 0 kernel: (Sinetek-rtsx) rtsx: rtsx_init : FORCE_CLKREQ_0 found

2020-04-15 11:15:06.135453+0200 0x49d Default 0x0 0 0 kernel: (Sinetek-rtsx) rtsx: SDDisk::attach : SDDisk attaching...

2020-04-15 11:15:06.135474+0200 0x49d Default 0x0 0 0 kernel: (Sinetek-rtsx) rtsx: SDDisk::attach : SDDisk attached

2020-04-15 11:15:06.260925+0200 0x49d Error 0x0 0 0 kernel: (Sinetek-rtsx) rtsx: SDDisk::read_task_impl_ : Returning an IO Error! (error = 60)

2020-04-15 11:15:06.402562+0200 0x49d Error 0x0 0 0 kernel: (Sinetek-rtsx) rtsx: SDDisk::read_task_impl_ : Returning an IO Error! (error = 60)

2020-04-15 11:15:33.452716+0200 0x6f Default 0x0 0 0 kernel: (Sinetek-rtsx) rtsx: SDDisk::detach : SDDisk detaching...

2020-04-15 11:15:33.452773+0200 0x6f Default 0x0 0 0 kernel: (Sinetek-rtsx) rtsx: SDDisk::detach : SDDisk detached.

2020-04-15 11:15:33.454206+0200 0x49d Default 0x0 0 0 kernel: (Sinetek-rtsx) rtsx: rtsx_init : FORCE_CLKREQ_0 found

2020-04-15 11:15:42.456926+0200 0x49d Default 0x0 0 0 kernel: (Sinetek-rtsx) rtsx: SDDisk::attach : SDDisk attaching...

2020-04-15 11:15:42.456941+0200 0x49d Default 0x0 0 0 kernel: (Sinetek-rtsx) rtsx: SDDisk::attach : SDDisk attached

2020-04-15 11:15:42.585082+0200 0x49d Error 0x0 0 0 kernel: (Sinetek-rtsx) rtsx: SDDisk::read_task_impl_ : Returning an IO Error! (error = 60)

2020-04-15 11:15:42.733017+0200 0x49d Error 0x0 0 0 kernel: (Sinetek-rtsx) rtsx: SDDisk::read_task_impl_ : Returning an IO Error! (error = 60)

2020-04-15 11:16:17.221558+0200 0x49d Error 0x0 0 0 kernel: (Sinetek-rtsx) rtsx: SDDisk::read_task_impl_ : Returning an IO Error! (error = 60)

I can only think the timeout I changed from 1 sec to 100 ms may be causing those timeouts. To make sure, could you send also the same log, but genertated with the debug version of the kext, right after boot (before any sleep)? For next release I may make the timeout configurable via a boot flag if that's the problem.

cholonam · April 15, 2020

17 minutes ago, Hervé said:

@cholonam

Here it is after 2 x microSD HD card insertion/ejection.

rtsx_dbg_log.txt

I see now.. the values you are getting from fetch_vendor_settings() are different from mine, which means there is some initialization that is being done to your chip that should not be done. What I'll do for next release is adding an option to disable the added initialization from the Linux driver, which is causing problems to anyone who does't have exactly the same chip as I do. That will also increase the timeout to the original 1 second value.

carlinyos · April 15, 2020

@cholonamTried your ku script, but I'm still getting the same error:

sudo kextunload -c Sinetek-rtsx
sudo kextunload Sinetek-rtsx.kext

(kernel) Can't unload kext com.sinet3k.Sinetek-rtsx; classes have instances:
(kernel)     Kext com.sinet3k.Sinetek-rtsx class SDDisk has 1 instance.
Failed to unload com.sinet3k.Sinetek-rtsx - (libkern/kext) kext is in use or retained (cannot unload).

cholonam · April 16, 2020

7 hours ago, carlinyos said:

@cholonamTried your ku script, but I'm still getting the same error:


sudo kextunload -c Sinetek-rtsx
sudo kextunload Sinetek-rtsx.kext

(kernel) Can't unload kext com.sinet3k.Sinetek-rtsx; classes have instances:
(kernel)     Kext com.sinet3k.Sinetek-rtsx class SDDisk has 1 instance.
Failed to unload com.sinet3k.Sinetek-rtsx - (libkern/kext) kext is in use or retained (cannot unload).

First, the class name is Sinetek_rtsx, not Sinetek-rtsx. Second, since it's telling you the SDDisk has 1 instance (did you eject the disk?), you can try unloading that class too:

sudo kextunload -c SDDisk
sudo kextunload -c Sinetek_rtsx [ <-- note the underscore here ]
sudo kextunload Sinetek-rtsx.kext [ to use this, the kext has to be in the test directory (copy it with ./c or ./kl) ]

carlinyos · April 16, 2020

15 hours ago, cholonam said:
First, the class name is Sinetek_rtsx, not Sinetek-rtsx. Second, since it's telling you the SDDisk has 1 instance (did you eject the disk?), you can try unloading that class too:
sudo kextunload -c SDDisk
sudo kextunload -c Sinetek_rtsx [ <-- note the underscore here ]
sudo kextunload Sinetek-rtsx.kext [ to use this, the kext has to be in the test directory (copy it with ./c or ./kl) ]

I'm trying to unload it without ejecting the disk. Not sure if that would be possible

Also, following your steps (and having ejected the disk).

cholonam · April 17, 2020

9 hours ago, carlinyos said:

I'm trying to unload it without ejecting the disk. Not sure if that would be possible

Also, following your steps (and having ejected the disk).

In my case (latest Catalina), I can unload the kext even with the card inserted and attached, just unloading the Sinetek_rtsx class before. In fact, if I unload SDDisk before Sinetek_rtsx, I get a kernel panic when unloading Sinetek_rtsx. No doubt more debugging is needed to get this kext stable enough for production..

carlinyos · April 17, 2020

I'm using macOS High Sierra 10.13. Not sure if that could be a problem.

cholonam · April 18, 2020

20 hours ago, carlinyos said:

I'm using macOS High Sierra 10.13. Not sure if that could be a problem.

It's the most likely reason I can think of. Hopefully I can get sleep/wakeup working and we don't need to unload/reload the kext anymore..

cholonam · April 19, 2020

I have uploaded a new release to my GitHub (here). Main changes:

Sleep/Wake implemented.
Read-write mode is enabled by default. The boot argument "-rtsx_rw" is removed and now "-rtsx_ro" is used to set the driver to read-only mode.
The compile-time define RTSX_MIMIC_LINUX has been removed and now the "-rtsx_mimic_linux" boot argument is used instead. (This change should make the kext work for those that were using syscl's, but card attach will take a bit longer).

For now, I am happy with how the kext works (at least on my machine) and will not be making any more changes apart from simple pull requests that may help people with other similar chips. The kext can definitely be improved (ADMA may improve the speed), but I have no more time to spend on this and I think it is usable/stable enough as it is. Hope it can help others

Sniki · April 19, 2020

6 hours ago, Hervé said:
Tried this version 2.1. Results are a little weird, so let me tell the story in details...

1) I 1st cached the debug version of the kext in /L/E and rebooted. On inserting my microSD card, same as with version 2.0: driver supports card's insertion/ejection and that's it. Failing to read & write the card.;
lat-7490:~ admin$ log show --last boot | grep rtsx
2020-04-19 12:34:13.846984+0200 0x410      Default     0x0                  0      0    kernel: Sinetek_rtsx::probe(PXSX)
2020-04-19 12:34:13.847980+0200 0x410      Default     0x0                  0      0    kernel: (Sinetek-rtsx) rtsx: Sinetek_rtsx::start                 : Driver started (debug version)
2020-04-19 12:34:15.098970+0200 0x422      Error       0x0                  0      0    kernel: (Sinetek-rtsx) rtsx:               sdmmc_dump_command    : sdmmc: cmd 52 (?) arg=0x80000c08 data=0x0 dlen=0 flags=0x1c01 proc="" (error 60)
2020-04-19 12:34:15.098975+0200 0x422      Error       0x0                  0      0    kernel: (Sinetek-rtsx) rtsx:               sdmmc_dump_command    : sdmmc: cmd 5 (?) arg=0 data=0x0 dlen=0 flags=0x1031 proc="" (error 45)
2020-04-19 12:34:16.105163+0200 0x422      Error       0x0                  0      0    kernel: (Sinetek-rtsx) rtsx:               sdmmc_dump_command    : sdmmc: cmd 8 (MMC_SEND_EXT_CSD/SD_SEND_IF_COND) arg=0x123 data=0x0 dlen=0 flags=0x1c31 proc="" (error 60)
2020-04-19 12:35:33.228293+0200 0x422      Error       0x0                  0      0    kernel: (Sinetek-rtsx) rtsx:               sdmmc_dump_command    : sdmmc: cmd 52 (?) arg=0x80000c08 data=0x0 dlen=0 flags=0x1c01 proc="" (error 60)
2020-04-19 12:35:33.228304+0200 0x422      Error       0x0                  0      0    kernel: (Sinetek-rtsx) rtsx:               sdmmc_dump_command    : sdmmc: cmd 5 (?) arg=0 data=0x0 dlen=0 flags=0x1031 proc="" (error 45)
2020-04-19 12:35:34.381311+0200 0x422      Error       0x0                  0      0    kernel: (Sinetek-rtsx) rtsx:               sdmmc_dump_command    : sdmmc: cmd 2 (MMC_ALL_SEND_CID) arg=0 data=0x0 dlen=0 flags=0x1631 proc="" (error 60)
2020-04-19 12:35:34.395540+0200 0x422      Default     0x0                  0      0    kernel: (Sinetek-rtsx) rtsx:       SDDisk::attach                : SDDisk attaching...
2020-04-19 12:35:34.395567+0200 0x422      Default     0x0                  0      0    kernel: (Sinetek-rtsx) rtsx:       SDDisk::attach                : SDDisk attached
2020-04-19 12:35:35.423339+0200 0x422      Error       0x0                  0      0    kernel: (Sinetek-rtsx) rtsx:               sdmmc_dump_command    : sdmmc: cmd 12 (MMC_STOP_TRANSMISSION) arg=0xaaaa0000 data=0x0 dlen=0 flags=0x1d01 proc="" (error 60)
2020-04-19 12:35:35.423377+0200 0x422      Error       0x0                  0      0    kernel: (Sinetek-rtsx) rtsx:       SDDisk::read_task_impl_       : Returning an IO Error! (error = 60)
Subsequent insertion/ejection would simply fail to detect the card, even after warm reboots; it was like it only sort of worked once! I thought I had damaged my card and/or reader but no, on checking things in Windows, they both proved to be 100% Ok.

2) I then decided to try the release version; so same treatment: cached the kext from /L/E and rebooted. Same dice, nothing. So I proceeded with a cold reboot and then the reader began to behave better: I did several insertion/ejection of the microSD card and all were detected and resulted in that same "disk not readable error". Hmm, strange...

3) I was about to abandon when I thought I'd give it a try after wake since @cholonam had mentioned he had included support for this in his kext. So I put the laptop to sleep and woke it after a few seconds. On waking the computer, BINGO!, to my surprise a "USB_16GO" USB disk logo appeared on my desktop! Card fully readable and writeable !!! It then worked perfectly!

Odd, isn't it?

So, the good news is that the kext does work so, great job cholonam. It just behaves a little strange on my machine at startup. Maybe it's because I use my microSD card as my Clover boot drive. I can live with this.

Try adding this line into the info.plist of the kext:

OSBundleRequired (string) Root like here:

https://github.com/acidanthera/VoodooInput/commit/be92196bd425196271e52b5f540e3177b563165b

And see if it works better

carlinyos · April 19, 2020

14 hours ago, cholonam said:

I have uploaded a new release to my GitHub (here). Main changes:

Sleep/Wake implemented.

Read-write mode is enabled by default. The boot argument "-rtsx_rw" is removed and now "-rtsx_ro" is used to set the driver to read-only mode.

The compile-time define RTSX_MIMIC_LINUX has been removed and now the "-rtsx_mimic_linux" boot argument is used instead. (This change should make the kext work for those that were using syscl's, but card attach will take a bit longer).

For now, I am happy with how the kext works (at least on my machine) and will not be making any more changes apart from simple pull requests that may help people with other similar chips. The kext can definitely be improved (ADMA may improve the speed), but I have no more time to spend on this and I think it is usable/stable enough as it is. Hope it can help others

Dear @cholonam

Having build your latest version (v2.1) from source in master and taking a look a the counter that the "kext unload" command provides (having slept the laptop), it seems that an instance a new SDDisk class is created after each attach / eject cycle. Not sure if that's the intended behaviour of the kext or not!

Let me know!

best!

carlinyos · April 19, 2020

Also @cholonam is your kext only valid for macOS 10.15? It seems that you're using methods that were implemented in the latest 10.15 sdk. (e.g: thread_set_thread_name)

cholonam · April 19, 2020

4 hours ago, carlinyos said:

Dear @cholonam

Having build your latest version (v2.1) from source in master and taking a look a the counter that the "kext unload" command provides (having slept the laptop), it seems that an instance a new SDDisk class is created after each attach / eject cycle. Not sure if that's the intended behaviour of the kext or not!

Let me know!

best!

That's interesting.. My understanding is an SDDisk should be created on attach and destroyed on detach, but it seems you have found some leak. I'll try to check the code again if I get some spare time. Thanks for the testing!

cholonam · April 19, 2020

3 hours ago, carlinyos said:

Also @cholonam is your kext only valid for macOS 10.15? It seems that you're using methods that were implemented in the latest 10.15 sdk. (e.g: thread_set_thread_name)

I had no idea that method is only available from 10.15, but I have the deployment target set to 10.12 (shouldn't xcode give me a warning or something?). Anyway, I'm not sure how important it is to set the thread name, maybe it's not even used and can be removed. I only have 10.15, so I cannot test other versions. Could you test removing that call and submit a pull request if that works? Thanks again.

Edited April 20, 2020 by cholonam

carlinyos · April 20, 2020

11 minutes ago, cholonam said:

I had no idea that method is only available from 10.15, but I have the deployment target set to 10.12 (shouldn't xcode give me a warning or something?). Anyway, I'm not sure how important it is to set the thread name, maybe it's not even used and can be removed. I only have 10.15, so I cannot test other versions. Could you test removing that call and submit a pull request if that works? Thanks again.

I'm not able to load your built kexts in High Sierra. I always build them based on the release tag.

cholonam · April 20, 2020

8 hours ago, carlinyos said:

I'm not able to load your built kexts in High Sierra. I always build them based on the release tag.

I'll remove that call, since the thread name is not used anyway. Also, regarding the multiple instances you are getting, are you using IOJones or IORegistryExplorer or similar? I can only reproduce that problem if one of those apps is open.

carlinyos · April 20, 2020

9 hours ago, cholonam said:

I'll remove that call, since the thread name is not used anyway. Also, regarding the multiple instances you are getting, are you using IOJones or IORegistryExplorer or similar? I can only reproduce that problem if one of those apps is open.

No, I have no apps opened during the testing. I updated to 10.15.4 and the issue still persists.

cholonam · April 20, 2020

5 hours ago, Hervé said:

One other thing I've noticed is the poor performance provided by the driver. Here's a sample of several Black Magic read/write tests I made with several cards. No matter the card, access hardly reaches 5MB/s. Better than nothing but very very poor.

Here is the results with a Class10 16GB SanDisk Ultra microSDHC advertised up to 100MB/s.

In Windows, the card returns a near 90/20 MB/s Read/Write performance:

Similar tests on my Latitude E6230 Hackintosh with the same card in an SD adapter gives this:

Other standard 2GB microSD cards I had lying around (from old cell phones) give the same 5MB/s test results. So, performance is somehow capped by the driver which could obviously benefit from further tuning on that front. Nevertheless, it works and that's the main thing for me.

Performance may improve after enabling ADMA, which is disabled now because it needs some changes in the compatibility layer. I won't be implementing it now because of lack of time, sorry. Also regarding the card being not accessible before sleep. Since you are booting from it, I suspect your BIOS (or whatever system you are using to boot from it) is initializing the reader, but the driver code (from OpenBSD) assumes the reader starts in an uninitialized state. After sleep/wake up, since the reader is turned off, then on, then initialized, it works (could you update tue github issue to mention the fact that you boot from the card? I think that's important).

cholonam · April 20, 2020

2 hours ago, carlinyos said:

No, I have no apps opened during the testing. I updated to 10.15.4 and the issue still persists.

That's weird.. without IOreg or IORE I never get any leak and SDDisk is always freed on detach. In the SDDisk class there are some commented-out functions (taggedRetain/taggedRelease) that may help you debug the problem, but I'm afraid fixing that is not going to be easy. Basically, something (we don't know yet what) is retaining SDDisk and not releasing it. In my case it's IOreg/IORE. In your case it must be something your setup has and mine does not.

cholonam · April 26, 2020

Dear all, I have uploaded a new release (2.2, here) that fixes a serious bug that could cause data corruption when reading and writing large data blocks. Everyone with version 2.0 or 2.1 should upgrade or risk corrupting the SD card. It also should load on Mojave and lower. Please let me know if it's working for you.

Sinetek's Driver for Realtek "RTSX" SDHC Card Readers

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites