Consoles: New Nintendo 3DS XL, Luma 8.1
Nintendo 3DS XL, Luma 8.1.
Both console firmware revisions: 11.5.0-38J/U
Entrypoint: boot9strap 1.2
Config: Set to
Enable Game Patching
Show NAND or User String in System Settings
Show GBA boot screen in patched AGB_FIRM
Explanation: Entering Sleep Mode simply occasionally (personally, multiple times daily) causes the console to never awaken and persist in Sleep Mode perpetually.
Unlike a a previous issue, the Rosalina menu was never opened while the device went to sleep, and putting magnets near the sensor also yields no results. There are no needed reproducible steps other than the obvious, no error, or a crash dump as the issue is simple. The only information I can provide is that it doesn't seem to depend on the length of time it is in Sleep. I know it definitely was also an issue in 8.0, but can't confirm if I experienced it in 7.1. or not. I know I didn't in 7.0.5.
I reproduced this on a newly modded o3DS XL and I have had the issue once since then. The only software on it are legit copies of Smash 3DS and Smash Selector, and FBI.
I used to have that problem on luma 8.0, but it was fixed for me on luma 8.1.
Try the latest commit. Compiled it myself with latest firmtool commit, latest armips commit, latest makerom commit, and latest ctrulib commit. Hopefully this helps you.
boot.zip
yeah....none of that matters.
I don't think this is a Luma issue, because if you look up that particular problem on Google you'll find results dating as far back as 2011-2012, when the 3DS was just coming out.
I doubt those people were having problems with their Luma CFW at the time ;p
It is indeed an issue of Luma as it only arises after using the >8.0 version of Luma. Many other people are also reporting this issue since then.
The other issue is similar but not the same, that one is occasionally normal on stock systems.
This issue happens every day without fail, even if the console is running a normal unmodified game. It also stopped occuring once I uninstalled cfw for a few weeks and continued once I reinstalled again.
Regardless, the only new info is that I never had the problem when on Luma 7.1.
As far as I'm concerned, this may well be a case of correlation does not imply causation (or confirmation bias, your pick.)
I've never had this issue when I wasn't using any CFW. I've never had this issue when I was running rxTools with menuhax. I've never had this issue when I was on Luma 6.6. I've never had this issue when I was on Luma 7.1. I've never had this issue when I was on Luma 8.0. I've never had this issue on 8.1. I've never had this issue when I was on Luma 8.1.1
I updated to 8.1.1-6b9b047 on August 10 2017 and have been running this version since then. I've not had that issue happen the whole time until now, where I've had it happen twice within a week.
I've been keeping my 3DS in sleep mode for weeks at a time; sometimes with a game running in background, sometimes just on Home Menu (and, more recently, Test Menu.)
If this were a Luma-specific problem, you'd think I would have run into it much sooner (especially from August 10 to now.)
"The other issue is similar but not the same, that one is occasionally normal on stock systems."
What are you basing this on? This issue thread has been marked as "needs more research/info" since August 23rd. If you had information that proves out of all doubt that this problem is definitely caused by Luma and definitely not the same issue that stock 3DS users have been having since 2011, why wouldn't you have posted it sooner? It seems to me like that would have been beneficial for everyone...
Maybe you've never had this issue when on Luma 7.1, and many others have never had this issue either until after having switched over to Luma.
On the other hand, many others have been having this exact issue since 2011, without being able to even just _think_ about hacks at the time. But of course, those many cases don't actually count, because of reasons.
There's no present way that I could send a precise cause of the error as it happens randomly; as I've stated, I own two 3DS consoles and the issue only arises while running over >8.0. I never implied and there is no statement which says it _will_ happen to you, on 8.0 or above. Your statement about "don't you think it would have happened sooner?" seriously doesn't make sense.
You noted that you, yourself, haven't had the issue until you started using a nightly of 8.1.1. This is just supporting this bug report. Even if you didn't get the issue on 8.0, you're getting it now, and not just one run-off-the-mill occurance. You got it twice, which implies that there is a recently arising conflict which is causing your console to malfunction. You can't just throw out this evidence as "maybe it would have happened anyway"; the fact is, it hasn't happened to you for years, and it's just now happening within the past month.
Tested different firmwares, different builds of the CFW, different entrypoints even. That's all I can do. Other people have massively reported the same issue in the same timeframe as I both here and elsewhere. I can only begin to think the cause is Rosalina, being a major addition in 8.0, and as similar issues have been opened regarding Rosa and BSoDs / freezes.
This is likely not the occasional stock freeze as:
a) there was a certain infamous update verison early on which also caused a BSoD during Sleep Mode for many users. If I recall correctly, slightly after the price drop.
There was also a bug on 1.0 where the console had a Sleep Mode button on the shut down prompt which was non-functional. Both of those times have passed.
b) the stock freezes won't happen as frequently as it does here. After years on stock, they personally never happened at all. After reverting my CFW setup completely to stock for weeks, they also ceased. Keep in mind this is normally a sub-daily occurance. Not much I can say here. Obviously, if this issue is as widespread on stock as is here, the issue would have been identified and fixed by Nintendo.
I also indeed posted it as soon as I could personally confirm it wasn't just a stock bug and replicable under Luma... There may be little evidence proving that this isn't just a stock freeze, but there's also significantly less which supports that Luma isn't the actual cause of it. Or, at the very least, magnifying whatever bug causes this issue on stock.
Why do you twist my words to fit your narrative?
I used 8.1.1 since it came out, then to 8.1.1-6b9b047 just a few days ago, on August 10.
I only started having this issue... pretty much a month and a half later.
How does any of this count as "I haven't had the issue until I "started using" a nightly of 8.1.1"...? You use these words, I do not think they mean what you think they mean.
Do you want to know what else I've been up to in the past week?
I use Test Menu. Have for a few months now; the reliable screenshot feature is very handy.
Guess what came out a week ago? Gold and Silver on VC.
I've been playing that, and taking a lot of screenshots during my play time. At the end of the day, or early into the next day, I'd exit out of the game and pull out my SD card without turning my 3DS off.
I use emunand. I take advantage of the fact Test Menu doesn't outright crash if you basically disconnect the nand, and you can reconnect it later and continue. It's useful, saves a few seconds of having to power off/power on.
Doing this does not crash my 3DS, and allows me to resume most activities. I take my SD card out and plug it into my PC, I convert the pictures I need to .png, and I spend an hour or so writing a journal post about my Pok茅mon Gold playthrough. The whole time, my 3DS is running on its own without crashing, but who knows if any less important background processes might be getting interrupted without crashing the 3DS, only causing issues later on.
You also conveniently ignore the fact that, no matter which version of Luma I've been using, I have had no issues with getting stuck in sleep mode despite leaving the 3DS in sleep for extended periods of time both on Home/Test Menu, and in-game. No issues, until I started doing things that my 3DS is most definitely _not_ designed for.
I've taken advantage of the ability to take out the emunand SD card on Test Menu very many times before last week, but every time I'd only leave it disconnected for a minute or two as I was backing up a save file and then re-inserting them. Only now have I started leaving it running for extended periods of time. Who knows if there might be any kind of background processes that can survive for a time, but start crashing if left for much longer.
For the record, I've also had issues with my 3DS not actually powering off when I pressed the Power button, and this always occurred shortly after I'd taken out the SD card while my 3DS was running and re-inserted it without restarting it. It would otherwise work perfectly, the only issue being that it would never finish powering off. This tells me _something_ happens from me taking out my SD card like this, but it doesn't immediately cause issues until later.
I'd never think to start blaming Luma for this until I'd at least stop doing what my 3DS is obviously not designed for.
Other people have massively reported the same issue in the same timeframe as I both here and elsewhere.
Obviously if you hang out on GBAtemp, you'd only be exposed to people who are also using Luma.
a) there was a certain infamous update verison early on which also caused a BSoD during Sleep Mode for many users. If I recall correctly, slightly after the price drop.
There was also a bug on 1.0 where the console had a Sleep Mode button on the shut down prompt which was non-functional. Both of those times have passed.
I said... you'll find results dating as far back as 2011-2012. Not, "You'll find results from 2011 and no later."
2014, unknown models, unknown firmwares
June 2011, O3DS, likely 1.1.0 or 2.0.0 (very few people actually have 1.0.0 stock, fwiw)
June 2014, 2DS, unknown firmware (the user also reports having had that issue with their other 3DS)
February 2015, N3DS XL, unknown firmware
Need I go on...?
b) the stock freezes won't happen as frequently as it does here. After years on stock, they personally never happened at all. After reverting my CFW setup completely to stock for weeks, they also ceased. Keep in mind this is normally a sub-daily occurance. Not much I can say here. Obviously, if this issue is as widespread on stock as is here, the issue would have been identified and fixed by Nintendo.
That's exactly what I'd call "anecdotal evidence."
"After years on stock, they personally never happened at all."
If you can compile valid data pointing towards a disproportionate amount of problems occuring on a large sample size of Luma users, compared to an equally large sample size of stock users, you are of course welcome to present it. Until then, you're only focusing on a subset of users who _are_ having this issue, all the meanwhile ignoring every other user who is _not_ having any issues whatsoever. In other words, confirmation bias.
For what it's worth, I am not particularly seeing any more reports from specifically google-searching for Luma-related sleep mode issues compared to people running stock 3DSes.
Obviously, if there was a very widespread issue on stock, then Nintendo would fix it... but that would imply it were actually a widespread issue. If it were, you'd find pages upon pages about it, and it would be well-documented. As it stands right now, Google search results become scarce past the third page, and beyond users posting that they have a problem, there aren't really many articles if any covering the subject. This indicates it's not actually a very widespread issue.
https://www.reddit.com/r/3DS/comments/2wv0le/new_3ds_xl_gets_stuck_in_sleep_mode/coueu0d/ <-- from a reddit thread I linked up above. They put it much better than I could have myself.
You are of course welcome to claim that most of those users were, unbeknownst to us, running Luma 3DS, but you would have no evidence to back that up. Keep in mind that outside of console hacking communities, modders and CFW users are a minority.
聽
All that being said, if there is a bug in the stock firmware, it's always possible for the Luma devs to fix it... if we can track down the cause, that is. Remember this commit?
I wouldn't _expect_ them to put in so much work and effort into figuring out the cause and fixing it, especially if they may not themselves be affected; they are doing this for free in their free time, after all, but I'm sure if somebody researched this and provided all the information on the subject, they'd be more than happy to help with it.
Says the one twisting my words yet again.
Mobile.
Test Menu, emuNAND, either way, under 8.1.1 period. Maybe you would get the bug either way, maybe not. If you do get it removing your SD Card on an emuNAND, that's obviously normal. I only opened the issue when I became certain Luma must be a factor. I am certain it's not "using my device for what it's not designed for", as when I reinstalled cfw, I kept everything as normal, untouched. Also worth noting, the devices are not region changed.
I haven't even checked the section of GBATemp. Either way, don't see the point of this statement. There was an issue opened here in the same timeframe as this one, issues reported in Nintendo Homebrew's server and personal clients whose consoles I've modded who never had this issue until recently. The chances of this being a coincidence seem to be astronomical.
I'll take a look at the videos later. Either way, it's a mere handful. And I don't even know what your statement about "most of these must be running Luma 8.0 unbeknownst to us." You know. A version of a customized firmware which hasn't existed until last month or so. Did I ever imply the issue never occurs on stock?
Not every user experiences this problem. A statement by which I've stated and you're ignoring. What I _am_ saying that it is an unusual amount of users are dealing with this in the last month or so while running Luma than on any other setup.
It's as simple as this. An issue is found. The issue is recurring. You test your setup. You isolate whatever seems to be the cause. You then look into and fix, or in this case, open an issue so a potential solution is found. Whether the evidence is anecdotal or not, also unknown and frankly near impossible to test without knowing the cause of the issue. This was opened so Luma developers could seek a cause if it exists.
I am able to reproduce this issue on the latest commit, both sys and emuNAND.
I too have been experiencing this issue. I'm not running NTR or anything like that. It mostly seems to happen inside of Homebrew apps, however, today it happened in Animal Crossing: New Leaf. It also seems to happen regardless of a cart is inserted. I don't use Rosilna Menu often and haven't used it for over a week. I don't recall having this issue on luma 7.1 and def didn't have it happen before I got CFW on version 11.3.0.
o3DS 11.6.0-39U
Entrypoint: boot9strap 1.2
Config:
Use EmuNAND FIRM if booting with R
Enable loading external FIRMs and modules
Show NAND or User String in System Settings
Show GBA boot screen in patched AGB_FIRM
Other Info:
I use an 8gb micro-to-sd adaptor. Luma is installed on both sysNAND and SD card. No hard mod. 3D is off. Wireless is always on. If there is any way I can help with research, I'd be happy to.
I am also still experiencing this issue.
O3DS 11.6.0-39
Entrypoint boot9strap 1.3
Config:
Use EmuNAND FIRM if booting with R
Enable loading external FIRMs and modules
Show NAND or User String in System Settings
Show GBA boot screen in patched AGB_FIRM
This issue started around the same time as when i updated from A9LH to B9 or when I started using Luma 8.0.
This happens to me as well, but oddly enough it stopped happening once the new update was downloaded.
n3DS XL, many versions, many different configs.
A few things I think could be useful to verify:
My wifi chip needs to be reseated so I can't enable wifi. Though I think it was happening even when I was still able to go online.
I only have luma but the issue wasn't happening before converting to B9S.
Still happens.
I can't do this as I don't have an SD card reader and no wifi access, sorry.
Feel free to collect data, test out, and contribute to a fix then.
Issue is it is so rare and next to no information can be collected because it isn't consistant, and nobody is being paid to fix it.