search

savagecyclopes / dop-mii

Automatically exported from code.google.com/p/dop-mii
GNU General Public License v3.0
0 stars 0 forks source link

syscheck crashes on 14.2 #61

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
What IOS did you use?
IOS 236 (IOS 36 with patches)

What is the first 4 digits of your Wii's Serial Number?
Before LU64...

What steps will reproduce the problem?
1. Running sysCheck crashed after hitting A to continue scanning.

What is the expected output? What do you see instead?
It did not continue to scan the remainder of IOS.

Please provide any additional information below.
Strange that it crashed when it did, after scanning all the 200's down to 28.

Original issue reported on code.google.com by JonesC52...@gmail.com on 23 Nov 2010 at 3:48

GoogleCodeExporter commented 8 years ago 
Forgot to add that it's not actually crashing, it's locked up, required holding 
down the power button to turn off.

Original comment by JonesC52...@gmail.com on 23 Nov 2010 at 3:50

GoogleCodeExporter commented 8 years ago 
So you got the same problem as me posted on:
http://code.google.com/p/dop-mii/issues/detail?id=60#c18

Mine stops on IOS 30 though, I guess i have more IOS installed.
So it seems like an error that doesn't have to do with a specific IOS, but with 
the second time you have to press A to continue.

Original comment by crazyrab...@gmail.com on 23 Nov 2010 at 4:00

GoogleCodeExporter commented 8 years ago 
There are a handful of IOSs that conventional probing methods just can't 
handle. These include older IOSs (syscheck wont check older IOSs with a 
revision less than 1000) and apparently severely hacked IOSs. If I remember 
correctly IOS 236 is a hacked Hermes/Waninkoko cIOS which also suffers from 
being unable to be read correctly. I will probably just disable it from being 
able to read in future releases.

Im also looking around the Internet for a version of syscheck that doesnt ceash 
when it reads these IOSs but I have yet to find one. If you do, let me know and 
I will try to merge it in with our version of syscheck.

Original comment by castleva...@yahoo.com on 23 Nov 2010 at 4:14

GoogleCodeExporter commented 8 years ago 
IOS 236 seems to be checked just fine the problem is later on.
PS: My IOS are updated and official.

Original comment by crazyrab...@gmail.com on 23 Nov 2010 at 4:21

GoogleCodeExporter commented 8 years ago 
So syscheck crashes on IOS 30 for you, correct crazyrabbit0?

Original comment by castleva...@yahoo.com on 23 Nov 2010 at 4:48

GoogleCodeExporter commented 8 years ago 
My IOS 236 is from TBR, installed to another slot, so it shouldn't be a 
Hermes/Waninkoko variant.  I'll be installing IOS 36 with patches to 236 
directly from DOP-Mii later for Gecko OS MOD.

If we were to have syscheck go through the IOSs backwards, do we know it would 
crash right away with the old IOS? Or would it be after entering A to continue 
as CrazyRabbit and I had happen?

Original comment by JonesC52...@gmail.com on 23 Nov 2010 at 5:01

GoogleCodeExporter commented 8 years ago 
Yes with old IOSs it would be crashing right away. I spent nearly 10 hours 
testing each IOS. It's actually not DOP-Mii that would fail when this happens, 
it was libogc's IOS_ReloadIOS() that would fail (according to each and every 
failure recorded by the USB Gecko).

Anyways, if either of you could give me the code dump you get, it would give me 
a lot more insight into the problem. Right now Im just making my best guess as 
I cant seem to be able to reproduce this myself.

Original comment by castleva...@yahoo.com on 23 Nov 2010 at 5:10

GoogleCodeExporter commented 8 years ago 
As i said before:
Mine stops (no crash just freeze) on IOS 30 but JonesC52124's stop on IOS 28, 
this must be because i have more IOS installed (80, and some more from SM 4.3 
-all official and updated though).

So it seems like an error that doesn't have to do with the IOS, but with the 
second time you have to press A to continue.

Original comment by crazyrab...@gmail.com on 23 Nov 2010 at 5:42

GoogleCodeExporter commented 8 years ago 
Well thats really interesting. have you tried using both a gamecube controller 
and a wii remote?

Original comment by castleva...@yahoo.com on 23 Nov 2010 at 5:48

GoogleCodeExporter commented 8 years ago 
Unfortunately i have no gamecube controller (if you were referring to me that 
is :P)

Original comment by crazyrab...@gmail.com on 23 Nov 2010 at 5:54

GoogleCodeExporter commented 8 years ago 
Either of you actually.

Original comment by castleva...@yahoo.com on 23 Nov 2010 at 5:58

GoogleCodeExporter commented 8 years ago 
Ok. I just ran through syscheck myself. I found the bug.

If you launch syscheck immediately after starting DOP-Mii from the initial 
menu, it works just fine. If you launch syscheck after reloading IOS or you try 
using syscheck a second time, it freezes.

I'm currently investigating the cause and will hopefully have this fixed soon.

Original comment by castleva...@yahoo.com on 23 Nov 2010 at 6:07

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
Now with the latest version (including the corrected meta), when I try to load 
with IOS 236 instead of AHBPROT it crashes (like before: 
http://code.google.com/p/dop-mii/issues/detail?id=60#c14), same happens if i 
try to syscheck with AHBPROT (no freeze after some time, just crash from the 
beginning).

Downloading is fine though.

EDIT: After removing no ios reload from meta:
It can load 236 successfully, but if i try to syscheck it still crashes from 
the beginning.
If i load AHBPROT and then do a syscheck (w/o no-ios-rl) it starts normally but 
crashes after 236 (like before: 
http://code.google.com/p/dop-mii/issues/detail?id=60#c4)

Original comment by crazyrab...@gmail.com on 23 Nov 2010 at 7:54

GoogleCodeExporter commented 8 years ago 
Well now Im extremely confused because now from what you're telling me it 
sounds like there's a separate issue relating uniquely to IOS 236. I have 
lukegb looking into this since he's braver than I am to put this stuff on his 
Wii and play with it. It might be awhile before we make any real progress on 
this.

Again, if you can find any versions of syscheck floating around the net that 
dont crash/freeze/have problems for you please let me know.

Original comment by castleva...@yahoo.com on 23 Nov 2010 at 8:03

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
Hate to say this, but WithOut the AHBPROT everything seems to be working better 
(ios loading fine and no crashes, even at syscheck it freezes with no crash).

EDIT: Sooo, as you suggested i tried to find a working syscheck online and i 
found this one: http://filetrip.net/f12865-sysCheck-2-0-1.html which is pretty 
neat at both the gui & the "inside" work, turns out that any version of IOS 30 
can't be read (will freeze) except the STUBbed one (so i changed to this one 
and the check ended successfully), this means that the freeze was in fact an 
IOS-based problem.

As for the crashes, they're definitely an AHBPROT problem since w/o it, the 
whole thing works just as it should (no crash & no freeze I checked it).

Original comment by crazyrab...@gmail.com on 23 Nov 2010 at 9:21

GoogleCodeExporter commented 8 years ago 
Hi,
With both versions (normal and brew) there is a code-dump during listing the 
IOS's.
The wiimote put the LED's to off as the first indication (any button pressed 
makes all LED blink) then after showing some more entries it crashes.
For normal (14.2) it happens in the second page (after continuing the listing).
For wiibrew (14.5) this is after showing the fifth entry.
I've tried with default IOS (36) and also changing the IOS - same trouble.

Original comment by DThe...@gmail.com on 25 Nov 2010 at 9:52

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
Hi everyone,

I have also just discovered this problem.  My tests were run on both SD and USB 
using ios36.  I did not reload the ios just went straight to syscheck.  The 
following results are the same for both.  Here are my findings...

V13 - works correctly identifying all 27 of my safe to test ios's.
V14 - only finds 20 ios's to test and locks up after ios28.
V14.1 - only finds 20 ios's to test and locks up after ios28.
V14.2 - only finds 20 ios's to test and locks up after ios28.
        Sometimes core dumps immediatley.

Castleva, Running syscheck immediately without an ios reload does not work for 
me.  The results above still stand.

Original comment by gsoud...@cox.net on 26 Nov 2010 at 3:35

GoogleCodeExporter commented 8 years ago 
Well yes, it is different for everyone which makes it so difficult. Whats most 
puzzling is that we didnt change any of the code from v13, just the build of 
libogc we are using to compile. Less "safe to test" IOSs are found because I've 
concluded that the new libogc crashes upon IOS_ReloadIOS() of older IOSs so it 
longer tests those. The other crashing issues and the freezing issues I've yet 
to find the cause of other than that I know it lies somewhere in the new libogc 
build.

If anyone wants to help, try finding a version of syscheck somewhere on the 
internet that compiles under libogc 1.8.5 and doesn't yield any problems so 
that I may port that over to DOP-Mii. As it stands, I haven't seen any so Im 
currently undergoing a massive rewrite of syscheck that I can only hope will 
work (in short: Reading IOSs from the NAND and doing hash comparisons for 
analysis instead of reloading IOS and then testing it)

Original comment by castleva...@yahoo.com on 26 Nov 2010 at 4:37

GoogleCodeExporter commented 8 years ago 
OK I built R149 against the latest libogc R4461.  The same problems exists.  I 
also confirm that the syscheck written by Double_A works and does not crash.  
Based on what castleva says about older ios's crashing with new libogc, I would 
guess that Double_A's app is compiled against an older version of libogc.

As for AHBPROT being a problem, I do not think this is the main problem.  Here 
is why.  If you are running HBC 1.0.8 under ios58, AHBPROT is enabled by 
default.  However when you launch an app from HBC, an ios_reload occurs.  When 
this happens, AHBPROT is no longer enabled.  This is why the addition of 
no_ios_reload was added to meta.xml to cancel the ios_reload when launching an 
app from HBC.  If I remove no_ios_reload from meta.xml, the freezing/crashing 
still occurs.

I think that it is important to note that the number of ios found to test will 
vary based on what you have installed.  This means that folks will freeze/crash 
after displaying a different ios.  In my case that is ios28. The interesting 
thing in my case is that all 20 ios's found safe to test are processed before 
the app freezes/crashes.  I am wondering if this is the case for others as well?

Castleva, I think you are correct in that libogc is your main problem.  However 
I will note that when I do have AHBPROT enabled, the app core dumps before it 
processes any of my 20 safe to test ios's.  I like your idea of rewriting 
syscheck to not use ios_reload.  It think that is the best way to go.  This way 
we get back processing of the older ios's.

Original comment by gsoud...@cox.net on 26 Nov 2010 at 8:23

GoogleCodeExporter commented 8 years ago 
Castleva, I have found the source for Double_A's syscheck.  I have compiled it 
against libogc 1.8.5.  The app runs fine with no problems.  Looking at the code 
it looks like he is using ios_reload in his code.  So I am not convinced that 
is your problem.  Here is the link to the source code...

http://www.mediafire.com/?cqqx348eu8qg33p

If you want to build it yourself you will need GRRLIB and Libwiilight as well.  
Here are those links...

http://code.google.com/p/grrlib/
http://wiibrew.org/wiki/Libwiilight

His latest build 2.0.1 was from September 2010.  I am not sure what version of 
libogc he built it against.  That is why I built it myself.  So I am attaching 
my build using libogc 1.8.5.  Hope this helps you to resolve this problem...

Original comment by gsoud...@cox.net on 26 Nov 2010 at 11:49

Attachments:

GoogleCodeExporter commented 8 years ago 
I'll get around to giving you a proper response once I get a chance to check it 
out but I have a quick questions for you: How does that source code handle with 
AHBPROT enabled ( <no_ios_reload/> )?

And thanks a bunch for all your help and support, you have no idea how much I 
appreciate all of it :)

Original comment by castleva...@yahoo.com on 27 Nov 2010 at 12:08

GoogleCodeExporter commented 8 years ago 
This app does not allow you to select an IOS to run under.  So for me the app 
runs under ios58. If 58 is not installed it would run under whatever ios HBC is 
running.  He does not have no_ios_reload in meta.xml so by default AHBPROT is 
not enabled.  However I just added it in to meta.xml and the app runs fine.  As 
I stated before all apps will run with AHBPROT if no_ios_reload is found in 
meta.xml.

BTW I like the output from his app.  It is very detailed.  Everything is listed 
about the console including the stubbed IOS's.  Perhaps you could borrow some 
code and make Dop-Mii's just as detailed.

You are welcome for my assistance in this matter.  For me that is what this 
stuff is all about...

Original comment by gsoud...@cox.net on 27 Nov 2010 at 12:37

GoogleCodeExporter commented 8 years ago 
Castleva, I had a look at RuntimeIOSPatch.cpp.  When I noticed the original 
author was Joe of Ftpii, I realized that he redesigned that code in his r306 
release.  Not sure if that will help but I think you should update your code to 
his latest as it much cleaner.  With that said, Joe's latest Ftpii is buggy and 
often locks up.  I know because I built and tested his latest which is R308.  
It is still under development and not ready for public use.  Just thought I 
would mention that.

Most users are running HBC 1.0.8 under ios58 which means that AHBPROT is 
enabled by default.  If you use the no_ios_reload in meta.xml then AHBPROT will 
remain enabled.  If enabled then is this not enough to patch/install ios's.  If 
not enabled then do things the old way using an already patched ios.  Perhaps I 
am not seeing the whole picture here.  Can you please explain?

Original comment by gsoud...@cox.net on 27 Nov 2010 at 3:01

GoogleCodeExporter commented 8 years ago 
I cant comment on syscheck yet as I ma still researching the issue but I can 
certainly respond to your most recent comment.

RuntimeIOSPatch.cpp uses code from FTPii but it was heavily modified by lukegb 
in order to be used in DOP-Mii. I am not aware of any bugs being found in it 
and as you've mentioned Joe's new version is quite buggy so I'm not sure if it 
would be worth spending time updating what little of Joe's code remains in 
DOP-Mii. lukegb would really be the best person to give an answer to this. I'll 
see if I can get him to make a response.

A note before I continue: You do not need any patches (or AHBPROT for that 
matter) for installing unpatched content signed by Nintendo (IOS, Channels, 
System Menu, ect.).

You're correct in saying that AHBPROT is all we need to install patched IOSs. 
However, AHBPROT disappears when IOS_ReloadIOS() is called (this is why we have 
an AHBPROT menu that pops up idiomatically whenever users are about to do 
something that can disable it). I believe it would be rather frustrating for 
users with AHBPROT and a patched IOS to run syscheck and then have to restart 
DOP-Mii via HBC because they need AHBPROT to patch an IOS. Thus, when patching 
IOS we first try to do it via AHBPROT and then via the loaded IOS if AHBPROT 
does not exist for user convenience.

So in short: Yes, we first try patching IOS via AHBPROT and then via the IOS 
loaded by the user if AHBPROT is not available.

I hope this helps to answer at least part of your questions.

Original comment by castleva...@yahoo.com on 27 Nov 2010 at 3:59

GoogleCodeExporter commented 8 years ago 
Castleva, Thanks for your reply.  Well I did compare Joe's iospatch.c r305 with 
Dop-Mii's RuntimeIOSPatch.cpp.  There are very few changes that result in the 
way that the ios is patched.  Giantpune gave Joe's code a negative stating 
"what a horrible way to patch and IOS".  After that Joe redesigned the code in 
r306.  Please ask lukegb to check out the differences in Joe's iospatch.c 
r305/r306.  I think he will agree that it should be changed for Dop-Mii.  BTW I 
do not think Joe's latest release being buggy has anything to do with his 
iospatch.c.

Thanks for your explanation on AHBPROT and IOS_ReloadIOS().  I now see that 
since IOS_ReloadIOS is used by syscheck then AHBPROT will become disabled.  I 
also did not think of forwarders.  According to Tantric forwarders do no use or 
look at meta.xml.  So if this is correct then AHBPROT will not be enabled when 
running an app from a forwarder.  Now I am really liking your idea of a 
syscheck rewrite to Reading IOSs from the NAND and eliminate the use of 
IOS_ReloadIOS().  The question is can it work?

Original comment by gsoud...@cox.net on 27 Nov 2010 at 5:48

GoogleCodeExporter commented 8 years ago 
It is a horrible way of patching it, yes. It was the only code available at the 
time, and I agree that having a pointer to change memory values is not great - 
read32/write32 is better, and loading a new IOS into memory, patching it and 
switching to that is even cleaner and less buggy.

However, the code works in all the tests I've run. If you want to make a point 
about RuntimeIOSPatch.cpp, can you please launch another ticket :P

Original comment by gb.luke on 27 Nov 2010 at 2:14

GoogleCodeExporter commented 8 years ago 
Hi gb.luke,

Hope I did not offend you.  With the current problems associated with this 
ticket, I thought that this code may be contributing to code dumps.  Perhaps 
this is incorrect.  I will not create another ticket because I have already 
informed you of Joe's updated code.  Your choice as to what to do with this.  
Thanks for all your hard work.  We all appreciate it...

Original comment by gsoud...@cox.net on 27 Nov 2010 at 3:53

GoogleCodeExporter commented 8 years ago 
OK I just built the latest source R154.  It appears that this has not solved 
the problem.  Syscheck now crashes consistently with a core dump.  I know this 
is a work in progress but I thought I would mention this for others considering 
building/testing the latest...

Original comment by gsoud...@cox.net on 29 Nov 2010 at 3:54

GoogleCodeExporter commented 8 years ago 
Arikado, gb.luke, this is Axel in wiibrew.org. I can confirm this is happening 
to me too. This is my setup:

SysMenu 4.3 (All IOS on their latest version)
HBC 1.0.8
IOS36 v3351 patched with DOP-Mii installed in slot 205
No other patched IOS/cIOS other than BootMii IOS in 254.

Syscheck on 14.2 crashes on me everytime with codedump. Most of the times at 
the very beginning of the check, and seldom after the first page when I press A 
to continue scanning. This occurs to me when using both IOS205 or AHBPROT flag.

Syscheck on v13 works flawlessly everytime. No crashes.

I am at work right now, but if you need I can send you a screenshot of the dump 
when I get home at night.

Thanks,

Original comment by axe...@gmail.com on 29 Nov 2010 at 4:06

GoogleCodeExporter commented 8 years ago 
Thanks for the offer but it's not necessary. lukegb and I have come up with an 
absolutely novel solution to this already. A bit hard to explain right now, but 
you should be able to see it in action very soon.

Original comment by castleva...@yahoo.com on 29 Nov 2010 at 6:30

GoogleCodeExporter commented 8 years ago 
i m using syscheck 2.1b3 (latest release of double a)
it shows without any issues ios4 (oldest version, not stub), ios16 v257, all 
cIOS 202/222-224, 236, 249/250 no crashes, no hangs

so also old revisions work fine with that code (b3 added detection of base IOS 
for cIOS)

Original comment by yvonne.m...@gmail.com on 29 Nov 2010 at 8:52

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
Castleva,

Just wondering if this is still being worked on.  I have tried R157 but it 
crashes with a code dump.

Original comment by gsoud...@cox.net on 14 Dec 2010 at 4:34

GoogleCodeExporter commented 8 years ago 
We found a fix. It's trivial in complexity. So lukegb is doing it. I dont have 
an ETA from him but I would like one. I'd do it myself but I'm very busy 
working on my other projects.

Original comment by castleva...@yahoo.com on 14 Dec 2010 at 6:31

GoogleCodeExporter commented 8 years ago 
This should be fixed in the SVN now as long as you compile under the new libogc 
1.8.6. I'm unable to get it to crash for me and I have received feedback from 
others also claiming that it no longer crashes. If you can wait and don't feel 
like compiling, I'll probably have a new binary out soon after some final 
testing to make sure there are no more issues with it.

Original comment by castleva...@yahoo.com on 27 Dec 2010 at 5:09

GoogleCodeExporter commented 8 years ago 
Still froze on me in v15.

Used AHRPROT or whatever it's called, looked at my IOS directly, then went to 
SysCheck.  After giving the prompt to continue after scanning the first few, I 
noticed that my Wiimote had timed out, so I pressed A to continue, it 
activated, read one more IOS and then froze.

Original comment by JonesC52...@gmail.com on 28 Dec 2010 at 4:26

GoogleCodeExporter commented 8 years ago 
What IOS does it freeze on? I can't reproduce (nor can anyone else who tests 
for me). Also, what version are you using? Main or WiiBrew Edition? 

Thanks!

Original comment by castleva...@yahoo.com on 28 Dec 2010 at 4:34

GoogleCodeExporter commented 8 years ago 
Using main version...

IOS 36 v3608 with patches from DOP-Mii.

Continue with AHBPROT (Old trucha fails, the rest are success)

Select IOS, BC, MIOS just to look, I didn't install/patch anything.

Back out, choose Syscheck (27 IOS to test)

Gets to IOS 31 and asks to continue or return to loader.  Wiimote is now OFF.

press A to reactivate, press A to continue, reads IOS 28 and crashes.

This time I have code dump instead of a freeze, would you like anything from 
there?

Original comment by JonesC52...@gmail.com on 28 Dec 2010 at 4:40

GoogleCodeExporter commented 8 years ago 
GPR00 00000068 GPR08 (etc for gprs) 8D8EFB7C 800BA00C 800B4788
GPR01 8016EA18 80145C60 800B4784 800D0000
GPR02 800C6090 00000001 800D0000 8014BB34
GPR03 20CD0B0C 933E0F90 800B4774 8036F938
GPR04 00000000 0000ED4E 800BA028 FFFFFFFC
GPR05 00000000 800D2920 00000016 00000000
GPR06 00000028 8016EADC 800B0000 800D2A20
GPR07 8D8EFB7C 8016EA88 800B0000 00000000

STACK DUMP:
8004eae0 -> 80055e98 80058cc0 80058f80
8002d918 -> 80026a44 800274e8 80028240
80028308

CODE DUMP:
8004eae0:  7CEB412E 600B0001 91630004 7D63012E
8004eaf0:  39630008 4800002C 61000001 5508003C
8004eb00:  7C0B412E 900B0004 810B0008 800B000C

Original comment by JonesC52...@gmail.com on 28 Dec 2010 at 4:56

GoogleCodeExporter commented 8 years ago 
For me personally it says X Number of IOS found that are safe to test. It tests 
each one. It doesnt prompt me until it's done and it asks me where I wish to 
save the report. Im interested in why it prompts you prior to that because it 
shouldn't. I don't honestly know what you could give me to help, sorry. But 
thank you, I'll just stare at the code and hope I see something.

Original comment by castleva...@yahoo.com on 28 Dec 2010 at 4:57

GoogleCodeExporter commented 8 years ago 
It doesn't prompt me to save, it prompts me to continue scanning IOS first (I 
think it is because the next set of lines will scroll down and the first IOS 
scanned will leave the screen.  That is when it crashes, after the prompt to 
continue scanning.

Original comment by JonesC52...@gmail.com on 29 Dec 2010 at 12:45

GoogleCodeExporter commented 8 years ago 
castleva,

This is definately not fixed!  The status needs to be changed on this thread.  
First of all I only get 21 IOS's to test.  This is wrong as version 13 tests 
27.  Secondly I get the same results as JonesC52124.  It is hit or miss with a 
freeze or code dump but it never completes.  For me it freezes or crashes after 
ios28.  However I do not think this is relevant.  JonesC52124 is correct about 
when it crashes.  It happens when the page is full and needs to continue.  For 
me I never get the prompt to continue scanning like JonesC52124. It freezes or 
crashes just before prompting.  Hope this helps to solve the problem...

Original comment by gsoud...@cox.net on 29 Dec 2010 at 3:38

GoogleCodeExporter commented 8 years ago 
My thinking is that the prompting is causing the issue. Something regarding 
reinitialization of the wiimote in the middle of syscheck. ALso, there are less 
IOSs found now not because you have less IOSs but because I've put in sanity 
checks to check a few less based on the feedback I've received here.

And issue reopened :)

Original comment by castleva...@yahoo.com on 29 Dec 2010 at 3:54

GoogleCodeExporter commented 8 years ago 
I suspected the prompting is causing the problem. As for the number of ios's 
checked, what do you mean sanity checks?  What feedback would tell you not to 
check an ios?  For me I want all ios's checked.  Otherwise the report is 
incomplete.  In fact I like what Double A has done with Syscheck in that he 
shows the stubbed ios's as well.  Just my opinion on the stubs but at least 
show all the others...

Original comment by gsoud...@cox.net on 29 Dec 2010 at 4:03

GoogleCodeExporter commented 8 years ago 
In order to check an IOS you have to load it in place of the existing IOS and 
run some tests. So you're calling libogc's IOS_ReloadIOS() to being doing this. 
If you use that to load a stub IOS, you're going to get a crash. Similarly, all 
crashes that occur away from the prompt cite IOS_ReloadIOS() as the culprit. In 
order to eliminate the chance of this happening and causing DOP-Mii to crash, I 
don't check stubbed IOSs in the report nor do I check IOSs with a revision 
number of less than 1000. 

Sure, I can list IOSs Im not going to bother checking in the report (and I plan 
to do this eventually), but in order to preserve my sanity I'd like to fix 
syscheck first before I mess with its report format.

Original comment by castleva...@yahoo.com on 29 Dec 2010 at 4:28