Repository navigation
Issues with new-pxi branch with sdcard write support #63
Description
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
Activity
Wolfvak commentedon Oct 19, 2021
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 commentedon Oct 19, 2021
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 commentedon Oct 19, 2021
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 commentedon Oct 19, 2021
issue still persists after enabling "Disable I-Cache (I-bit)"
Wolfvak commentedon Oct 20, 2021
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 commentedon Dec 29, 2021
@spike11302000 I just pushed a new driver in the branch that uses DMA, can you test again?
spike11302000 commentedon Dec 30, 2021
it seems to work but im unable to write it just reports as a read only filesystem
spike11302000 commentedon Dec 30, 2021
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: 80000000i 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 commentedon Dec 30, 2021
I have a regular sd card and I can try it in a few hours
Wolfvak commentedon Dec 30, 2021
Yeah
buffer error 0x80000000basically 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 commentedon Oct 2, 2022
Sorry for the slight delay but I just pushed a fix that should fix this: 1053381
Can anyone try it? Works for me