Open GoogleCodeExporter opened 8 years ago
Also, this was with DML r46, compiled with devkitARM r36.
Original comment by gerbilsoft
on 19 Feb 2012 at 6:37
The loader I used was USB Loader GX r1154. I have no idea if that might be
what's causing the problem. I'll test it again with both USB Loader GX and
NeoGamma (R9b56).
Original comment by gerbilsoft
on 19 Feb 2012 at 6:53
Can you format your card, and then repeat whatever corrupted your sd card? The
log file DML creates in this case might be helpful.
And which game did corrupt your sd card?
Original comment by nintendo...@kaffeeschluerfer.com
on 19 Feb 2012 at 10:37
r47 might fix this problem, maybe not.
Original comment by nintendo...@kaffeeschluerfer.com
on 19 Feb 2012 at 2:24
I repaired the filesystem (recovered files with TestDisk and reformatted). I'll
try again with both r46 and r47.
The games I tested were Mario Party 7, Sonic Adventure DX, Sonic Adventure 2
Battle, and Super Smash Bros. Melee. The most obvious corruption was when
BootMii's files were trashed. This either resulted in the BootMii menu not
showing up, or in the disc LED flashing twice on startup, indicating BootMii
couldn't find the boot files at all.
(Notably, starting SADX seemed to be the most unreliable, and it once resulted
in the BootMii files being trashed.)
Original comment by gerbilsoft
on 19 Feb 2012 at 8:27
Test results with Mario Kart: Double Dash:
- r46: Corrupts some files.
- r47: Same issue.
I thought the problem may have been related to shutting down the console from
the interrupt handler instead of simply setting a flag to let the main function
know it needs to shut down, but this doesn't appear to be the case. It still
gets corrupted. (Using the flag is still a good idea, and I'll submit patches
for that once I figure out what's going on here.)
I'm going to try disabling SD writes and see if that fixes anything. I'm
suspecting something is misbehaving in the FAT32 code. (Of note, it didn't even
try to boot the game if the SD card wasn't partitioned with DOS compatibility;
that is, the first sector of the partition == sector 63; and it corrupted the
filesystem anyway.)
Original comment by gerbilsoft
on 26 Feb 2012 at 2:39
With r47, I'm now getting this problem in fsck:
/DM.LOG
File size is 3 bytes, cluster chain length is 0 bytes.
Truncating file to 0 bytes.
It doesn't appear to be corrupting anything else right now. I'm suspecting that
the FAT filesystem module doesn't like some aspect of my 1GB SD card, because
with my 16GB SDHC card, logging worked fine.
Disabling SD write support did prevent the corruption, but it also obviously
prevents logs from being written.
(On another note: DML Installer v1.1 doesn't properly update both FATs, which
resulted in some filesystem corruption earlier. This was easily fixed by
running fsck after using DML Installer.)
Original comment by gerbilsoft
on 26 Feb 2012 at 2:53
With NMM r44 if you save Luigi Mansion after turn of wii and turn on again load
Luigi Mansion, press start and gives: The save file are corrupted.
Original comment by ilyassta...@gmail.com
on 26 Feb 2012 at 11:47
I'd be very happy if you do something to save super mario sunshine in NMM in
real nand.
Please
Thanks
Original comment by igordima...@bol.com.br
on 26 Feb 2012 at 3:06
I have tried to save super mario sunshine in NMM in pal realnand but it gives:
The device in Slot A is not supported" error.
Original comment by ilyassta...@gmail.com
on 26 Feb 2012 at 5:08
And how can I fix super mario sunshine save.
Original comment by ilyassta...@gmail.com
on 26 Feb 2012 at 5:10
and there is no way to fix the problem "The device in Slot A is not supported"
of super mario sunshine?
Original comment by igordima...@bol.com.br
on 26 Feb 2012 at 5:18
I'd like to point out that the specific issue I'm having has nothing to do with
NMM. It happens with plain DML without memory card emulation.
Original comment by gerbilsoft
on 26 Feb 2012 at 7:26
ok,
thanks a lot
Original comment by igordima...@bol.com.br
on 26 Feb 2012 at 7:54
I tried installing a clean MIOS and then reinstalling r47, and here's what I
get with my 1GB SD card after running MKDD:
Formatted as FAT32, 4 KB clusters:
gs_laptop /home/david/Wii/Homebrew # fsck /dev/sdb1
fsck from util-linux 2.19.1
dosfsck 3.0.9, 31 Jan 2010, FAT32, LFN
/DM.LOG
Contains a free cluster (120321). Assuming EOF.
/DM.LOG
File size is 3 bytes, cluster chain length is 0 bytes.
Truncating file to 0 bytes.
Leaving file system unchanged.
/dev/sdb1: 25 files, 120318/249484 clusters
Formatted as FAT16, 32 KB clusters: ..actually, the corruption "disappears",
but the beginning of DM.LOG shows garbage.
So it seems like there's two problems:
- Using clusters smaller than 32 KB is completely broken.
- With 32 KB clusters, DM.LOG shows data corruption.
My 16 GB SDHC card used 32 KB clusters, so it must have overwritten some other
area as well. This might be fixed in r47; I'll have to test it again.
================================================================
dm.log from the first run using FAT16 with 32 KB clusters:
���'[�ߌ��D8{p������������,�p�=\����
��.�7������q��5p?�u>�ne�-;XOޝ#����
g\P�����ܦW�u*����w*(��w�`�ܝ����|�̲|dž#a���%1-�趨��P�����#�I�>!8����%�ӻ��.��u{m-Ĵ�qю?�s���Q�i�K�\�[)��n��X����Ǩ�k�+���;�5�m���ӣ���+�Zq�����a���1������A>Z�Z"6+�<�{R7����~@g��KC��ɦ\㹺9br�z;�Sls����|1����9��$��l�}����_bg���1�I$�y1�7��8H$|D)��������Yo�0�yLzu�U��e�Xf;)�S}���O������יB��ϻ!�>�Mz1�@G�<��/n=�FI�8�S�uns����;�#�+07�j�"|��R��S����]J^�;+ܗv����H`�s�Nu�Kۇe{����▒kK�I�(][1�`p|�pyW�▒��uAT�Ӊ{���O���8
\Q�r�?���dnX�>�W{���v�v?�V�J���q�x
¼���������~�{�o���Z`�����������
����{����{��콭����w���O�Kߟ�o�{W���
wy���t������7yS�g~s���?:�nw��Z�z�S����
����������������������w�������
���f���������w�W�y����������{���
���ԋ���{��g3����������e���_����
|��������������g^���|���������
����1�i������������������}�]_���
���������������������۩����s��
��i������k��~���?w��U?���������o
y��R'm��켭����kyg��������ʷ��������
�������]�~~����^����[�[��?����r���
�{����v������}?����4��ˊ���Ɲ�����
����yk�x��u��}�����_|�~������}����
'������~}�����<��?��
7!�V��{��\ns����x�P���f�0�NTsP@tP%H���4����D�tP%H���4�����#rZM�@��`�tP%H���4����#�yB�"rZ0eyBw��YyS7�g����������������h$���gPatch:Found [SetInterruptMask]: 0x800E8ABC
Patch:Found [__OSDispatchInterrupt]: 0x800E8CDC 0x800E8E84
Patch:[Hook:OSSleepThread] at 800EC188
Using entry:0 to alloc 128 bytes...
Patch:Failed to open/find cheat file:"/games/GM4E01/GM4E01.gct"
Patch:Found [DVDLowReadAudio]: 0x800AB20C
Patch:Found [DVDLowAudioStatus]: 0x800AB2A4
Patch:Found [DVDLowAudioConfig]: 0x800AB330
Patch:Found [DVDInquiryAsync]: 0x800ADD38
Patch:Found [AIResetStreamSampleCount]: 0x800B0B9C
Patch:Found [__GXSetVAT]: 0x800BCF2C
Patch:Found [__fwrite B]: 0x801024F0
ask]: 0x800E8ABC
Patch:Found [__OSDispatchInterrupt]: 0x800E8CDC 0x800E
Game Name ... GM4E
Company ..... 01
Disk # ...... 0
Game ver .... 0
Streaming ... OFF
Country ..... US
Banner ...... Available
================================================================
dm.log from the second run using FAT16 with 32 KB clusters:
_B�DIOS-MIOS Lite
Built: Feb 27 2012 20:17:59
This software is licensed under GPLv3, for more details visit:
http://code.google.com/p/dios-mios-lite-source-project
DVD:Error:04020400
Using entry:0 to alloc 1024 bytes...
Using entry:1 to alloc 32 bytes...
;�5�m���ӣ���+�Zdx賱�Ԇ���,Dl��٘N遹T6���d
�$$vn#riSRAM:Mode:0(0) EURGB60:0 Prog:1
SRAM:Mode:0(0) EURGB60:0 Prog:1
ɦ\㹺9br�z;�Sls����|1����9��$��l�}����_bg
���1�I$�y1�7��8H$|D)������<< RVL_SDK - SI
release build: Jun 23 2006 16:12:58 (0x4200_60422) >>
Revolution OS
Kernel built : Jun 23 2006 16:12:26
Console Type : Retail 2
Firmware : 0.0.0 (0/0/2000)
Memory 24 MB
MEM1 Arena : 0x1338480 - 0x1700000
MEM2 Arena : 0x7fffffff - 0x0
<< RVL_SDK - OS release build: Jun 23 2006 16:12:26 (0x4200_60422) >>
Now in compatible mode.
<< RVL_SDK - VI release build: Jun 23 2006 16:13:04 (0x4200_60422) >>
Bus Clock = 162000000 Hz
Core Clock = 486000000 Hz
<< RVL_SDK - PAD release build: Jun 23 2006 16:12:54 (0x4200_60422) >>
<< RVL_SDK - DVD release build: Jul 6 2007 16:34:22 (0x4199_60831) >>
--- GAMECUBE BOOTROM for REVOLUTION v1.1 ---
Loading....DOLPHIN LAYOUT FORMAT
4 MB
MEM1 Arena : 0x1338480 - 0x appLoaderFunc1 ...... 0x1200258
xApploader Initialized. $Revision: 32 $.
This Apploader built Apr 17 2003 12:46:20
Apploader Initialized
K - VI release build: Jun 23 2006 16:13:04 (0x4200_60422) >>
Bus Clock = 162000000 Hz
Core Clock = 486000Patch:Found [__DVDIntrruptHandler]: 0x800AA768
Patch:[__DVDInterruptHandler] 800AA784
Patch:[__DVDInterr�x�P���f�0�NTsP@tP%H���4����D�tP
%H���4�����#rZM�@��`�tP%H���4����#�yB�
"rZ0eyBw��YyS7�g����������������h$����
�gPatch:Found [SetInterruptMask]: 0x800E8ABC
Patch:Found [__OSDispatchInterrupt]: 0x800E8CDC 0x800E8E84
Patch:[Hook:OSSleepThread] at 800EC188
Using entry:0 to alloc 128 bytes...
Patch:Failed to open/find cheat file:"/games/GM4E01/GM4E01.gct"
Patch:Found [DVDLowReadAudio]: 0x800AB20C
Patch:Found [DVDLowAudioStatus]: 0x800AB2A4
Patch:Found [DVDLowAudioConfig]: 0x800AB330
Patch:Found [DVDInquiryAsync]: 0x800ADD38
Patch:Found [AIResetStreamSampleCount]: 0x800B0B9C
Patch:Found [__GXSetVAT]: 0x800BCF2C
Patch:Found [__fwrite B]: 0x801024F0
ask]: 0x800E8ABC
Patch:Found [__OSDispatchInterrupt]: 0x800E8CDC 0x800E
Game Name ... GM4E
Company ..... 01
Disk # ...... 0
Game ver .... 0
Streaming ... OFF
Country ..... US
Banner ...... Available
Original comment by gerbilsoft
on 28 Feb 2012 at 1:45
Some more test results:
- With 16 KB clusters, DML won't start at all; the left side of the screen has
a few vertical purple bars.
- With 64 KB clusters, it seems to work, and dm.log is generated (2417 bytes),
but it's all 00 bytes.
- I noticed that vsprintf.c uses vsprintf() / sprintf(), which are unsafe
functions because they don't do bounds checking. I converted them to
vsnprintf() / snprintf(), but unfortunately that didn't fix the corruption
problems. I'll post these patches later this week.
Original comment by gerbilsoft
on 29 Feb 2012 at 4:03
Today I was going over the DML code, and I noticed that the bounce-buffer used
for SDHCI transfers to the Starlet SRAM uses a buffer at 0x1000. This is
actually used by the Dolphin OS. I moved the buffer to 0x2D00 (which reduced
the patch code area by 512 bytes), and it works a little better.
The overall issue seems to be that dbgprintf() is being called simultaneously
from two different points, since I see some overlapping writes from the Dolphin
OS and from DML. How is the Dolphin OS fwrite handler implemented? If it's an
interrupt, that may be what's causing the issue.
The better question, of course, is why does it seem like I'm the only one who's
hitting SD card corruption in DML :(
================================================================
Current DM.LOG file:
DIOS-MIOS Lite
Built: Feb 29 2012 21:11:13
This software is licensed under GPLv3, for more details visit:
http://code.google.com/p/dios-mios-lite-source-project
DVD:Error:04020400
Using entry:0 to alloc 1024 bytes...
Using entry:1 to alloc 32 bytes...
SRAM:Mode:0(0) EURGB60:0 Prog:1
SRAM:Mode:0(0) EURGB60:0 Prog:1
<< RVL_SDK - SI release build: Jun 23 2006 16:12:58 (0x4200_60422) >>
Revolution OS
Kernel built : Jun 23 2006 16:12:26
Console Type : Retail 2
Firmware : 0.0.0 (0/0/2000)
Memory 24 MB
MEM1 Arena : 0x1338480 - 0x1700000
MEM2 Arena : 0x7fffffff - 0x0
<< RVL_SDK - OS release build: Jun 23 2006 16:12:26 (0x4200_60422) >>
Now in compatible mode.
<< RVL_SDK - VI release build: Jun 23 2006 16:13:04 (0x4200_60422) >>
Bus Clock = 162000000 Hz
Core Clock = 486000000 Hz
<< RVL_SDK - PAD release build: Jun 23 2006 16:12:54 (0x4200_60422) >>
<< RVL_SDK - DVD release build: Jul 6 2007 16:34:22 (0x4199_60831) >>
--- GAMECUBE BOOTROM for REVOLUTION v1.1 ---
Loading....DOLPHIN LAYOUT FORMAT
4 MB
MEM1 Arena : 0x1338480 - 0x appLoaderFunc1 ...... 0x1200258
xApploader Initialized.
Original comment by gerbilsoft
on 1 Mar 2012 at 3:12
Bah, that log got truncated.
DIOS-MIOS Lite
Built: Feb 29 2012 21:11:13
This software is licensed under GPLv3, for more details visit:
http://code.google.com/p/dios-mios-lite-source-project
DVD:Error:04020400
Using entry:0 to alloc 1024 bytes...
Using entry:1 to alloc 32 bytes...
SRAM:Mode:0(0) EURGB60:0 Prog:1
SRAM:Mode:0(0) EURGB60:0 Prog:1
<< RVL_SDK - SI release build: Jun 23 2006 16:12:58 (0x4200_60422) >>
Revolution OS
Kernel built : Jun 23 2006 16:12:26
Console Type : Retail 2
Firmware : 0.0.0 (0/0/2000)
Memory 24 MB
MEM1 Arena : 0x1338480 - 0x1700000
MEM2 Arena : 0x7fffffff - 0x0
<< RVL_SDK - OS release build: Jun 23 2006 16:12:26 (0x4200_60422) >>
Now in compatible mode.
<< RVL_SDK - VI release build: Jun 23 2006 16:13:04 (0x4200_60422) >>
Bus Clock = 162000000 Hz
Core Clock = 486000000 Hz
<< RVL_SDK - PAD release build: Jun 23 2006 16:12:54 (0x4200_60422) >>
<< RVL_SDK - DVD release build: Jul 6 2007 16:34:22 (0x4199_60831) >>
--- GAMECUBE BOOTROM for REVOLUTION v1.1 ---
Loading....DOLPHIN LAYOUT FORMAT
4 MB
MEM1 Arena : 0x1338480 - 0x appLoaderFunc1 ...... 0x1200258
xApploader Initialized. $Revision: 32 $.
This Apploader built Apr 17 2003 12:46:20
Apploader Initialized
K - VI release build: Jun 23 2006 16:13:04 (0x4200_60422) >>
Bus Clock = 162000000 Hz
Core Clock = 486000Patch:Found [__DVDIntrruptHandler]: 0x800AA768
Patch:[__DVDInterruptHandler] 800AA784
Patch:[__DVDInterruptHandler] 800AA79C
Patch:[__DVDInterruptHandler] 800AA7C4
Patch:Found [DVDLowRead]: 0x800AAB28
Patch:[cbForStateBusy] 800AD55C
MB
MEM1 Arena : 0x1338480 - 0x appLoaderFuPatch:Found [__OSDispatchInterrupt]:
0x800E8CDC 0x800E8E84
Patch:[Hook:OSSleepThread] at 800EC188
Using entry:0 to alloc 128 bytes...
Patch:Failed to open/find cheat file:"/games/GM4E01/GM4E01.gct"
Patch:Found [DVDLowReadAudio]: 0x800AB20C
Patch:Found [DVDLowAudioStatus]: 0x800AB2A4
Patch:Found [DVDLowAudioConfig]: 0x800AB330
Patch:Found [DVDInquiryAsync]: 0x800ADD38
Patch:Found [AIResetStreamSampleCount]: 0x800B0B9C
Patch:Found [__GXSetVAT]: 0x800BCF2C
Patch:Found [__fwrite B]: 0x801024F0
- 0x appLoaderFuPatch:Found [__OSDispatchInterrupt]: 0x800E8CDC 0x800E
Game Name ... GM4E
Company ..... 01
Disk # ...... 0
Game ver .... 0
Streaming ... OFF
Country ..... US
Banner ...... Available
Original comment by gerbilsoft
on 1 Mar 2012 at 3:12
Okay, I have an initial set of patches that should help a bit, but they don't
seem to fix the corruption issues.
Patch 1: Convert (v)sprintf() to (v)snprintf() - prevents buffer overflows if
the formatted data exceeds 127 bytes.
Patch 2: memcpy()'s second parameter should be const void*, not void*.
Patch 3: sdmmc_write()'s third parameter should be const void*, not void*.
Patch 4: vsprintf.c: Allocate the buffer on the stack instead of on the heap.
Patch 5: Patches.c: Cleaned up memory allocation values for the cheathook.
Patch 1 is the most important, since it prevents buffer overflows.
Patches 2 and 3 fix some gcc warnings, and aren't too important.
Patch 4 may fix some reentrancy issues if dbgprintf() is called from an
interrupt handler while dbgprintf() is already running. (This seems to be the
actual problem, since I'm seeing the mixed-up dbgprintf() stuff; however, I
can't pinpoint the exact issue.)
Patch 5 cleans up all the values for CheatHook and uses macros instead of
"magic" numbers, which should make it easier to update in the future.
(The patches were stored in my local git-svn repository, which uses my Verizon
email address instead of git. You don't need to include the email info in the
svn commits.)
Original comment by gerbilsoft
on 5 Mar 2012 at 1:00
Attachments:
Forgot to add patches 3, 4, and 5.
Original comment by gerbilsoft
on 5 Mar 2012 at 1:00
Attachments:
I found a minor error in patch 5 regarding the cheathook code length, so I
fixed that in another patch. (The code length was off by 8 bytes.)
Original comment by gerbilsoft
on 5 Mar 2012 at 2:57
Attachments:
Any word on applying these patches? (At least the first four should be
applied...)
If there's any issues applying them because of recent commits, let me know so I
can rebase them.
Original comment by gerbilsoft
on 6 Mar 2012 at 5:32
I'm seeing CHKDSK report errors on my FAT32 w/ 64KB clusters 32GB SDHC card as
well:
"Convert lost chains to files (Y/N)? Y
64 KB in 1 recovered files.
Windows has made corrections to the file system."
It looks like the cluster was all zeroes. (This is a new card though, so it may
be that it was never written to rather than something writing all zeroes to it).
I'm not totally sure if this is related to DML or not though. Nothing actually
seems to be broken. I'll post again if I see any further errors.
I did notice dm.log has no modified timestamp, is that intentional?
Original comment by ssj4andr...@gmail.com
on 21 Mar 2012 at 11:52
Looks like the FAT driver (ff.c) is not re-entrant.
The "#define _FS_REENTRANT 0" could be changed to "#define _FS_REENTRANT 1".
However it looks like long file names must also be disabled then. It may break
other things as well since the FS calls just fail if there's already an
operation in progress.
The easiest thing to do would be to disable writes to the SD card while in an
interrupt handler. I'm assuming there's some way to detect if we're in an
interrupt?
I suppose the proper way to do it would be to write a buffering mechanism for
log output, only flushing it to file when not in an interrupt.
BTW, do you happen to know if any other FS calls are made from interrupts?
Original comment by ssj4andr...@gmail.com
on 22 Mar 2012 at 1:27
I rebased the patches to r56, and managed to "fix" the corruption by disabling
logging to SD entirely. Obviously this isn't the best solution, but it works
for now.
Here's the updated vsnprintf() patches. I didn't include a patch to disable
logging to SD, but it's easy enough to do that by editing vsprintf.c:
diff --git a/DML/vsprintf.c b/DML/vsprintf.c
index 317fa67..054115a 100644
--- a/DML/vsprintf.c
+++ b/DML/vsprintf.c
@@ -495,7 +495,7 @@ int dbgprintf( const char *fmt, ...)
GeckoSendBuffer( buffer );
}
- if (dbgprintf_sd_access)
+ if (0 && dbgprintf_sd_access)
{
// Write all debug output to the log file, independent from the usb gecko output
// Only fwrite output from games won't be logged to sd card
Original comment by gerbilsoft
on 25 Mar 2012 at 3:16
Attachments:
Original issue reported on code.google.com by
gerbilsoft
on 19 Feb 2012 at 6:37