Random BSOD in ntoskrnl.exe

OK, i might know what it is if it is indeed related to device error..

I have had a known problem with my supermicro sata controller, where is dismounts drives after idle,sometimes it wont even mount certain drives (seems to always be drives 5 and 10) on boot up,could this be the cause?

A lot of people over at limetech (unraid) have reported this problem with the supermicro card,and it is annoying as hell,however, they report one should refrain from updating the firmware on the card,as problem will get worse.

Since i also use 5x2 port sata asrock cards i can mix and match drives and try and find a configuration where there are no conflicts,however i have been unsuccesful in this endevaour..

Mind you it can run for days before this happens,and then a reboot usually fixes it.

Also,i have completely removed the intel gfx driver,as i have no use for it,usually i run server headless,so i will try and see if that fixes anything before i do anything else

Yes, now that I think about it, I have heard of some issues with unraid with Supermicro controllers, though I never gave it much thought since unraid did not fit what I was looking for in enterprise storage. Are you using the controller on a Supermicro mobo or a standalone PCI-E controller card? At least judging by the crashdumps it looks like you're using a controller card. What's the model for your mobo and/or card?

Either way, it looks like a conflict issue that's only going to be resolved by either Supermicro or limetech fixing the problem. There may even be the need to find another solution besides unraid/supermicro if this issue is going to persist.

Vir Gnarus said:

Yes, now that I think about it, I have heard of some issues with unraid with Supermicro controllers, though I never gave it much thought since unraid did not fit what I was looking for in enterprise storage. Are you using the controller on a Supermicro mobo or a standalone PCI-E controller card? At least judging by the crashdumps it looks like you're using a controller card. What's the model for your mobo and/or card?

Either way, it looks like a conflict issue that's only going to be resolved by either Supermicro or limetech fixing the problem. There may even be the need to find another solution besides unraid/supermicro if this issue is going to persist.

See "my system specs" for hardware i use,it is accurate and up to date.

However,i do NOT use unraid, but flexraid,same difference i guess when it comes down to it.. Problem is, i bought the asrock mb because it had so many pci-e expansion slots,as i figured i would gradually add to my server,but as it turns out,i have max´ed out the server capacity in just 4 months,so i should probably have bought different hardware,but it is what it is..

Problem is, short of buying brand new controllers and mainboard, there isn´t any other 8 port sata controller on the market that i could find,with my setup i have 4xsata ports on mb, 10xsata ports on 5xasrock sata controllers, and 8 ports on the supermicro, i could go for a different 6 port controller,but havent found one..

you see my predicament?

I havent had BSOD since i removed the intel gfx driver though, but as topic says,it is totally random when it occurs, and thus i might have to wait a few more days/weeks to see if removing the driver that is part of the crash has fixed it

Yes, I do. I've been reading more reviews on this particular Supermicro controller and it looks like it's very iffy especially with unRAID and flexRAID as well as poor Linux support (not that the Linux problem matters for you). If you wanted to go any higher it would mean getting an enterprise level card, which means getting an enterprise-level mobo and enterprise-level SATA drives. Obviously it can get quite more expensive.

People in the reviews were talking about unRAID and flexRAID and how it needed INT13 setting changed on the controller. I'm not sure if it involves your situation but I figured it'd be worth mentioning. Also some people were encouraging firmware update for the card, but if you said other were saying otherwise, then I'm not sure if it's worth the gamble. Worst case, though, would be replacing the card, so best to have a spare on hand in case the update bugs out this one.

I know you've been using CrystalDiskInfo and whatnot to keep a tab on your drives' health, but I do think it best to actually run some sort of diagnostics on em just in case. Not sure if Seatools would work but worth a shot. I am well aware of the odd behavior surfacing from a bad drive or two.

If you want you can give us that kernel dump and we can take a further look at it.

Thanks Vir

But buying another card of the same brand/make/model would be pure stupidity,as it is the card or firmware that is at fault,and no other affordable 8 port card is on the market (no way am i paying 300+$ for a controller),so i guess i will have to suffer until other manufacturers will make a similar card..

Also, it isn´t the disks,as it happens regardles of which of my 20 drives are connected to the supermicro,so unless all 20 drives including 4 brand new WD20EARX are faulty,it is the card.

Also, NO drives connected to the mb or to any of the 5 asrock sata controllers does ever exhibit this behavior..

In summary, i have deleted the gfx driver in question,and have uninstalled all non-essential software,i have just installed an older driver for the supermicro,as the one i was using wasnt specific for my card,but for the newer 2 card,although reports indicate that the driver i was using should work fine,and even allow 3+TB drives to be connected,but for the sake of trying everything,i installed the "correct" driver for my make/model for now.

I am gonna let it run a week and see if it BSOD,if not problem solved (removing the intel gfx driver),if it does indeed BSOD, i can make the dump files and upload them if need be

Last resort would be to remove all my WD20EARS (load cycle problem) drives from the supermicro,and either exchange them with blacks or the newer WD20EARX, which is NOT affected by the load cycle problem according to Western Digital customer service,and hope that will fix it..

Now i just need to be patient,and hope for the best

You may not see another card like that for a good while in the consumer market, since a consumer level card with that much isn't really something with large demand. Anyone who's going for such is usually going more of a business level, which means they'd be willing to shell out $300 for a solid controller. Supermicro is not to blame, as itself is one of the best in the business, and I know that just from expert opinions and my own personal experience. But like any brand, reputable or not, if you dip into the discount bin, you're going to get discount quality.

Now I've actually been giving this some extra thought and re-reviewing it, and it just dawned on me. The load cycle issue with idle drives would be exactly what may be causing this. You see, built into drives is a time limit to discern if a drive is inactive or not and will put it into a low idle power state. This is to conserve energy, but is contradictory to RAID controllers which are constantly checking for drives to see if they are alive or not as a health check. If the drive does not respond to the call in a designated time frame it will deem that drive as bad and unload it. This isn't a problem for drives usually, but when a drive decides to become idle, pulling it out of the idle state to respond to the heartbeat will take just enough time to miss the threshold. I've seen this happen often with people who mix consumer drives with business/enterprise class controllers because the consumer drives have a smaller idle threshold to place itself into a low power state, whereas enterprise class drives have a much longer or even nonexistent threshold. A lot of newer consumer drives are also going this route because they're seeing that people are using RAID controllers a lot more often which are asking for a much faster response time than what their inert drive can respond too.

Now, this seems to correspond with what I interpret is going on with the bugcheck. The system is ordering the removal of a disk device, most likely because of it missing the heartbeat, and the disk is saying, "You can't do that, I'm alive!" So it is rejecting the request. That sounds very much inline with what you're experiencing with the load cycle problem.

I say, if the BSODs continue, definitely try out those WD20EARX drives. That may very well be the answer we're looking for.

Thx m8, and yes,i am gradually exchanging to WD20EARS drives for WD20EARX drives anyways, but all of the problem drives, i have run WDIDLE on to disable the head parking completely, and i have windows set at 20 mins for harddrive sleep timer,so the drives shouldnt go into an idle state,however WD has shipped 2 types of WD20EARX and i know contrary to what WD says,that WD20EARX-008FB0 also suffers from the head park,so unfortunatly i only own 3 of the brand new type with NO idle park the WD20EARX-00PASB0,but i still have to exchange 6 of the problem EARS type,and this will free the asrock controllers,so i can move the idle problem EARX Drives to the asrock controller,and only use the brand new on the supermicro card.

That said,i only run snapshot raid,not real time,so the headparking again shouldnt be a problem, but i dont know

It doesn't matter what RAID or no RAID setup you have. You can even have a JBOD and it'll still bug out the controller if the heartbeat isn't responded too in quick fashion. Don't forget that the controller itself may be designed to expect enterprise drive configuration and not consumer, despite what the price and whatnot may seem (expected given that Supermicro is an enterprise hardware company).

I think i mght have fixed the problem, 2 days without a drive dismount,and no bsod.. which is much better than usual. i usually have at least 1 drive dismount a day,so none in 2 days is good.. However,too early to say if it is completely fixed..I will let it run a week and see if anything happens

What'd you accomplish, just moving the WD20EARS drives to the mobo storage controller?