GA-X58A-UD3R - Random failure to wake from sleep after BIOS Update to FG1

[Nealeb]

Whether or not to hibernate or leave running - well, the fact that I'm chasing this problem indicates my view! In principle, I know that switching on and off can shorten the life of electronic components, although in a PC things are not as stressed as they were in my early days of electronics working on valve televisions (black and white, 405 line of course . I did measure PC power consumption once but have lost the bit of paper with the numbers written down but they did show that running a background high-CPU process (Folding@Home, in my case) measurably increased power consumption so I don't run one of those any more, and as a matter of principle I like to turn off things that I'm not using. I don't reckon to keep a PC long enough for the long-term reliability to be an issue, and I know that hibernate reduces my power bill. I have the PC on an intelligent mains adaptor which means that a bunch of external devices also get turned on/off automatically with the PC.

Couple of observations from looking through my notes taken over the last 4 months or so (since I realised that I was forgetting what fault-finding measures I had already taken and started recording all significant events):

• About 80-90% of hangs or BSODs happen before Windows has removed the old hibernate file (or marked it as used), even if the Windows desktop is showing. I know that because a reset allows you to re-resume, and this takes you back to where you wanted to be in the first place. In the other 10-20% of cases, it's a Windows restart.
• When a BSOD happens, I have Windows configured to take a crash dump. The last thing written to the BSOD screen says "initialising disk for crash dump, writing crash dump" (or words like that) but it has never, ever, written a crash file. I have tested the mechanism by using the documented "manually cause a crash" mechanism and I get a crash dump then. Does this mean that there is something funny about the state of the disk subsystem?
• Again, when checking after a hang/BSOD, the windows event log never seems to contain anything useful. Did the machine stop before Windows was ready to write, or is there a disk subsystem problem that stops it writing?
  

No idea what these observations add to the sum total of knowledge but when fault-finding, I always try to identify all observations, and look both for what they might imply and also whether any deduced failure mechanism is consistent with all the observations. In this case, we can't rule out the fact that there may be more than one thing happening here, but it would be good to come up with a theory that explains all these phenomena

[Aussie Allan]

  All good reading Nealab....some call it Gut feel (probably the subconscious kicking in ) some just experience .....either,iether the ..."In the other 10-20% of cases, it's a Windows restart" .... you quoted in the most resent post.... I would say this is where the UPS could reduce it 20% allowing one to concentrate on the real issue at hand....

  Because this has and is still effecting the X58, 67 and Z68 ....and some newish information has been posted in this one post/resource ..... could be an Idea to pull a few talented others in to the post to share there views.

  We all have our talents ..... some Very specific ...... other a smattering of most areas ...... if you want to combine talents and more resources ..... you could use the PM system we have here to contact/CC several people to this thread ...... heres a few people that I think could flesh out whats already been covered and hopefully some new ideas.

  "runn3R"

  "DarkMantis"

  "Absic"

  "Lsdmeasap"

  "Rolo42"

  "F5BJR"

  "oggmonster"

     And myself ...... if a panel of people were to be put together to "Crack a tough Nut" ..... these are the people on this site (that are active) that I would put together........they all don't get on like drinking buddy's ..... but all have a tested skill set applicable.

  Just a thought ........ Aussie Allan 

[Lsdmeasap]

Sleep issues on X58A should be solved long ago, and were last I tested, unless maybe a new BIOS broke it again(!)

FH is the latest BIOS
http://download.gigabyte.eu/FileList/BIOS/mb_bios_ga-x58a-ud3r_2.x_fh.exe

I do not have a UD3R ver 2.0 here, but I can test the above mentioned BIOS on aUD7 Rev 1.0 if you guys need me to.   That would verify the BIOS works fine for S3 sleep if it doesn't fail for me, but it would not rule out any specific issues with your particular boards or that model itself either since I'd be using a different board.

S3 sleep issues are so hard to diagnose, since they can be caused by incorrect windows settings, drivers, programs, ect and the list goes on (Including broken BIOS).   But I never have S3 sleep issues in any tests I run, once the BIOSes have been fixed for working S3 that is.  So I wouldn't need to rule out anything mentioned above, except for the BIOS.  

So if anyone needs me to test that BIOS I can just let me know, but keep in mind what I said above about not having this exact model.

[Aussie Allan]

  Thanks Lsdmeasap for stepping up to the plate ..... although personalty I don't use these advanced functions/features .....there are a lot who do ..... and this subject still continually reappear time and again.

  Any help given I'm sure will be greatly appreciated .....Like you I'm a a big advocate of "Update The BIOS" there's so many small changes that we are just not privy too ,....to not rule out adopting this simple procedure.

  Aussie Allan

 

[Lsdmeasap]

No problem, I'm always happy to help when I can!!

Ya, I don't use S3 either.   I shut off my computer when I'm not using it, and turn it on when I need it

But I'm always testing S3 for others, so I've tested plenty of boards and BIOSes, and the last I know and tested all X58A BIOSes had S3 fixed, but I haven't updated to any X58A BIOSes lately.   So I thought maybe it could have been broken again with a BIOS update, so I knew it was my time to test again, I always do and it's good to know which BIOSes have S3  broken if any so I can report it as well.

For sure, I always suggest the latest beta BIOSes actually, over finals posted on the board web pages, because they normally have many of the fixes people are waiting on and some people aren't even aware of too.   I never actually use a final BIOS, unless someone wants me to test something, other than that it's always latest beta for me.

As mentioned above, I can test any X58A BIOS (Any model), but I only have UD5 and UD7 boards here so any BIOS testing would be done on those two boards.  Mainly I'd test on the UD7 because it's already setup for testing, but just want everyone to know there could be specific board/model issues that might not show for me on UD7.   But I think if I test a BIOS on UD7 and it works no problem, then it should be working on the board the BIOS belongs to as well.  I suppose there is a slim chance something different between the boards might cause a BIOS to work for me but not the board it's supposed to be flashed on, but I doubt that would happen often since many of the boards are very similar aside from connectivity and add-ons

I have X58A-OC too, but S3 is OK on it last I checked and that wasn't too long ago.

[Aussie Allan]

   Lsdmeasap .... have you noticed in testing if Memory count/Population plays any part....... in any of the "S" states with the X58 platforms ?

  Aussie Allan

[Lsdmeasap]

No I haven't noticed anything like that, but I could imagine if the memory is not 100% stable it would fail to resume for sure because it'll do that even with a single module.   System has to be 100% tested stable, otherwise S3 can fail anytime simply due to instability.

The only S state I ever test is S3 though, so all my thoughts only apply to S3 sleep.

[Nealeb]

If I'm being strictly accurate, I guess that I should acknowledge that I'm not talking about S3 (STR or whatever) but S4 or S5 (depending on how you define those). That is, I am trying to resume from hibernate and a disk-stored memory image, so there are elements of the disk subsystem involved as well.

As far as memory is concerned, I do not see any difference between the 3x2GB OCZ memory I was using and the 3x4GB Corsair that's now in there. Same level of unreliability. In all cases, I have been running 1600MHz memory at 1066 but keeping memory timings at the recommended "1600" values so should be very conservative at 1066.

I have also been tracking the beta BIOSes; I believe that I'm running the latest from Tweaktown (FH5, with the latest Intel RAID firmware included) but I haven't seen any difference with any BIOS since the one that was delivered with the system originally. So to me that says that either it's not BIOS, or it's a BIOS issue that hasn't been fixed yet. I think that I've run FG, FH1, FH3, FH4, and now FH5. I ran some others earlier than that but I don't have my notes in front of me.

I can confirm that disabling ErP in the BIOS (to do with low-power behaviour in S5) doesn't help. Worked OK for a dozen or so hibernate/resume cycles over 2-3 days, then hung again.

Trouble is, of course, that we all have slightly different configurations. I run a GTX460, plus 4 disks on Intel RAID5, plus system disk on the JMB(?) controller.

If we're down to the comparing gut feel level , my money is on some kind of memory corruption, either during the writing of the memory image back from disk or maybe a hardware glitch during initialisation. This seems consistent with the various stopcodes that get thrown up, or hanging at various times during resume (e.g. while the "resuming..." window is displayed) or shortly afterwards. It depends on when the randomly-corrupted memory location concerned gets executed. Hence, sometimes, the hang or crash happens before the hibernate file-to-memory restore has finished so it is still valid (and that fact that I can usually resume from it suggests that the actual disk image is good) but occasionally the crash doesn't happen until after the restore is flagged as complete, so a Windows restart is needed. I really did like that idea of memory voltage issues but now that I'm still seeing the problem with genuine 1.5V-rated memory, I guess that that one is a non-starter.

I'm inclined to discount hardware initialisation as hangs sometime happen before the resume has finished, and presumably, then, before Windows has let the drivers reinitialise their respective hardware, but this is making rather a lot of assumptions about internal Windows driver behaviour that might not be valid.

Of course, the mechanism might be completely different for the case of S3 resume problems...

[Rolo42]

- Need to know what the BSODs are
- Are you using any USB devices, namely ones that routinely get plugged in/out (mobile phones, drives, etc.)?
- Run CHKDSK /R on the partition with hiberfil.sys, if you haven't already

[Lsdmeasap]

S4/S5 would indicate you'd have to have S1/hibernate enabled in the BIOS and not be using S3.   Normally there are never any issues with S1, only S3 and those are eventually addressed with BIOS updates.

Since you are having hibernate issues, I think it may have to do with how you have things setup.   We would need to know the BSOD codes (Filter windows, system event logs for ID 1001) and the driver named in those codes.   I am leaning towards it having something to do with your operating system being ran from the J.Micron ports because a setup like this is rarely used so if there was issues directly related we'd hardly ever hear about them.

Can you move your OS disk to SATAII_0 on the Intel port, or do you not have enough room?   If you do not have room, can you move it there if you also move your CD/DVD over to the J.Micron port instead, so you'd have your RAID and OS drive on the Intel ports (OS on SATAII_0 is best)?  YOu should have room to set it up this way since there are 6 Intel ports, OS on SATAII_0, followed by your four disk RAID array, and then CD/DVD either on the last Intel port or the J.Micron port.   

This may solve your issue instantly!

[Aussie Allan]

   Do agree Nealab with the "Gut Feeling" although mine also says it's not the root cause but an after effect of the initiator ..... If you have them ...Give Rolo those BSOD code he requested ..... All have our favorite areas we like to dabble in .... he might be able to uncover something else thats been misses so far. ....

                      I do not see any difference between the 3x2GB OCZ memory I was using and the 3x4GB Corsair

  I asked a question to Lsdmeasap in this area who has done extensive testing on the platforms (and others) and he concurred that memory populations and densities seem to have no bearing in his tests with hibernation or S3 states .

  Aussie Allan  

[Aussie Allan]

  Dam! .... .....gotta learn to type quicker.

  AA

[Lsdmeasap]

 

Ya, it shouldn't matter as long as whatever memory in use is 100% tested stable via a few programs at least.

[Nealeb]

There's some good ideas in those last few posts!

I'm not at home at the moment but I shall scroll back through the event logs and see what I can find. I know that a lot of the time the "hang" happens without anything being written to the event log - as far as Windows is concerned it might never have happened - but I'm not sure that I've looked at the log after a BSOD. I know that the "failing module" on the blue screen does not always have the same module name, and the stopcodes vary (most common have been, from memory, something like "data-in-page execution" and "secondary processor did not respond to clock tick", but because they have never been very consistent, I've tended not to write down the full details. Windows is configured to write a crash dump on BSOD but because the crash seems to happen before Windows is properly resumed, this has never actually happened. Straight hangs are much more common than BSOD as well.

I have a question on the BIOS S1/S3 setting. I have always had this set to "allow S3 (STR)" on the assumption that this was a good thing to do even though I don't actually use S3 in practice. I also have hybrid sleep disabled, so I should be using a pure hibernate with no retained memory image - at least, that's my understanding. If I'm using S4/S5, is it better to set the BIOS to S1?

As far as disk connections are concerned, it's set up the way it is mainly because that is the way that I did it on a previous motherboard which had a 4-port Intel RAID controller. I put the 4-disk RAID array on the new controller, and then used one other port for a DVD writer. I wasn't sure that I could mix and match (at that time) RAID and non-RAID drives on the same controller although I now see that you can. There was also a problem on the old machine that ran XP in that it was a real pain to install on a RAID system disk as the XP boot image did not have a RAID driver and the PC didn't have a floppy drive. None of which applies under Win7, of course, but I didn't realise that at the time. Anyway, it's not a big deal to swap a few SATA cables around and that's something that I can try very easily. I do have two DVD writers in the box but there will be enough SATA ports even without the Marvell SATA3 ports, which are currently disabled at BIOS level.

Thanks for the helpful comments to dates, guys, and sorry if this doesn't advance the "S3" issue at all. I'm at work at present so reconfig will have to wait until this evening, and then however long it takes to see something go wrong! I'll have a trawl for stopcodes in the event log this evening, though, and report back.

[Lsdmeasap]

Since you don't use S3 you'd want to set the BIOS to S1, that in itself may also be part of the issues here.  But I think the main thing that may be causing issues here is the current disk configuration as I mentioned above.   If you are sure your memory is 100% tested stable, then I lay my money on the disk layout.

I'd go ahead and test the disk moves I mentioned above, with and without setting BIOS to S1 in case that doesn't matter.  And then if the issue persists, test your memory again for at least 5 full passes or overnight using Memtest86+ just to be sure (If you haven't already recently).
http://www.memtest.org/#downiso

As for the stop codes, since you mention they always vary you are right, they probably wont be much help in this situation so go ahead and pass on trying to look them up until you're sure these latest suggestions don't help.