Issues with new-pxi branch with sdcard write support

[spike11302000]

im currently having a issue with the branch that enables read/write support for sd cards.
when ever i try executing something on the sd card it will randomly segfault or illegal instruction. but when the binary is built in the initrd it works just fine.

i checked the checksum of the files to see if the file got changed some how

i do noticed after i executed the file and try again it will sometimes executes but most of the time it causes a soft kernel panic

[  535.068000] 8<--- cut here ---
[  535.076000] Unhandled fault: page domain fault (0x81b) at 0xb6d60000
[  535.092000] pgd = cbda9092
[  535.104000] [b6d60000] *pgd=27ab3831, *pte=222d955f, *ppte=222d9c7e
[  535.124000] Internal error: : 81b [#1] SMP ARM
[  535.132000] CPU: 1 PID: 252 Comm: grep Not tainted 5.11.0-rc1-g601f87f61c77-dirty #11
[  535.152000] Hardware name: Nintendo 3DS/CTR (Device Tree)
[  535.172000] PC is at v6_coherent_kern_range+0x4/0x2c
[  535.192000] LR is at arm_syscall+0x160/0x2f0
[  535.200000] pc : [<c0113bf0>]    lr : [<c010a774>]    psr: 40000013
[  535.224000] sp : c7adff90  ip : 00c5787d  fp : 00000000
[  535.244000] r10: 00000000  r9 : c7ade000  r8 : c0100244
[  535.264000] r7 : c7ade000  r6 : b6d60134  r5 : b6d60134  r4 : 00000002
[  535.284000] r3 : 00000000  r2 : c11345c0  r1 : b6d60134  r0 : b6d60000
[  535.308000] Flags: nZcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[  535.328000] Control: 00c5787d  Table: 27a6800a  DAC: 00000051
[  535.348000] Process grep (pid: 252, stack limit = 0x6d49077e)
[  535.372000] Stack: (0xc7adff90 to 0xc7ae0000)
[  535.380000] ff80:                                     b6d60008 ea000000 b6d60134 000f0002
[  535.404000] ffa0: c0100244 c0100060 b6d60008 ea000000 b6d60008 b6d60134 00000000 0000012c
[  535.424000] ffc0: b6d60008 ea000000 b6d60134 000f0002 0167e098 be971350 00000000 00000000
[  535.444000] ffe0: 000003ff be97131c b6f361dc b6f5ea0c 60000010 b6d60008 00000000 00000000
[  535.468000] [<c0113bf0>] (v6_coherent_kern_range) from [<c010a774>] (arm_syscall+0x160/0x2f0)
[  535.488000] [<c010a774>] (arm_syscall) from [<c0100060>] (ret_fast_syscall+0x0/0x58)
[  535.508000] Exception stack(0xc7adffa8 to 0xc7adfff0)
[  535.532000] ffa0:                   b6d60008 ea000000 b6d60008 b6d60134 00000000 0000012c
[  535.552000] ffc0: b6d60008 ea000000 b6d60134 000f0002 0167e098 be971350 00000000 00000000
[  535.576000] ffe0: 000003ff be97131c b6f361dc b6f5ea0c
[  535.596000] Code: ee070f15 e12fff1e e12fff1e e3c0001f (ee070f3a) 
[  535.616000] ---[ end trace d309443f54c30c13 ]---

i have tried multiple different filesystems and formatting without change.
i switched back to the master branch of the linux and arm9linuxfw and i had no issues executing the file but didnt have write support

there is a current workaround that uses loopback devices to get around this issue

losetup /dev/loop0 /dev/dev/mmcblk0pX
mount /dev/loop0 /mnt

[Wolfvak]

tagging @iAmInActions because he's worked on this issue with us recently.

apparently buildroot needs a specific patch to enable multilib - exactly why I'm not sure yet, but it seems to fix this issue when executing programs off the SD card.

can you confirm this didn't happen with the old virtio-based driver? there might be some caching issue, but none of the other SD drivers have provisions for invalidation or SMP management, so idk

[spike11302000]

ya the old virtio based driver had no issues. i dont think its a multilib issue either as i didnt need to enable it to fix the issues. it does sound like a caching issue because after reading the executable with sha256sum or something else and try to execute it will run just fine. it seems to only cause issues on the first execution of the file.

[Wolfvak]

thinking about it again it might be the driver behaving incoherently within the instruction cache.

could you try building a version with disabled icache (check "System Type -> Disable I-Cache (I-bit)") and see if you can still trigger the bug? seems like a surefire way to determine this.

[spike11302000]

issue still persists after enabling "Disable I-Cache (I-bit)"

[Wolfvak]

well that rules out cache inconsistencies.

I'll keep investigating, if you find other ways to workaround the bug, post them here, it might be a clue about what's going wrong

[Wolfvak]

@spike11302000 I just pushed a new driver in the branch that uses DMA, can you test again?

[spike11302000]

it seems to work but im unable to write it just reports as a read only filesystem

[spike11302000]

hmmm
theres something weird going on

first i had to lock on the micro sd adapter but when i switch it to unlock the system will hang when mount and the last message i see is

3ds-sdhc 10100000.sdhc-controller: buffer error: 80000000

i have tried different microsd adapters but same thing. i dont have time to test other sd cards at the moment but i will try to do that tomorrow

[shokifrend007]

I have a regular sd card and I can try it in a few hours

[Wolfvak]

Yeah buffer error 0x80000000 basically means there's another transfer going on (ILA bit)... It's probably a bug regarding writes and the DMA engine system, I might be signaling end-of-request while it's still active and causing this bug. I'll just clean up that logic so that end of writes are signaled by DATAEND and end of reads are signaled by the DMA transfer finishing.

[Wolfvak]

Sorry for the slight delay but I just pushed a fix that should fix this: 1053381

Can anyone try it? Works for me