For RAM, there is a memtest binary somewhere in the slackware64 distribution. It should be in this folder: ftp://ftp.slackware.com/pub/slackwar...rnels/memtest/. Download it, add it to the menu for your boot loader, and boot it like a kernel.

If you're confident that your RAM is good, though, worry about the software part while keeping hardware issues in the back of your mind. You'll be looking for a kernel that was made either a) before the problem was introduced or b) after the problem was fixed. How you go about doing that is up to you. Also, people like Pat and upstream developers can be helpful in pointing you in the right direction. However, upstream developers like to be shown that you've worked as hard to frustrate yourself as they will work to fix your problem. Sometimes, they also have mailing lists with archives to search without you having to send a single message. Sometimes, you'll be asked to search those archives before posting a new bug report.

Hmm.. Actually, I think this isn't about hardware or the kernel at all.. A quick search for "InnoDB: Warning: a long semaphore wait:" on google will show a lot of other similar situation, almost all related to a software problem.. More importantly, the software that is using the database..

Well, anything written to disk while the power supply was wonky could be corrupt. That includes any binaries that you installed during that time. I'd consider a re-install of any software that you've added.

I am 100% RAM is good. Tested using memtest86+ for 17 hours straight no errors.

Understood. It is my intention to

1. Get new PSU and reinstall slackware fresh (14.1). If issue persists..
2. Search the kernel maillists to see if a similar/identical bug has been reported, if not..
3. Contact the kernel upstream developpers to submit a new bug/oops report. If its not kernel related, then it must be distro specific then..
3. Contact the slackware developpers to submit a bug report (distro specific). If all else fails
4. Opt for a different OS for this server.
Or use fire

Several "softwares" are using the databases. I had 11 databases served by Percona MySQL. Most were PHP (Web) applications, some were php scripts and a few were used for remote applications to sync their app cache over a central DB. Which one(s) may be causing this issue? On a older server (Slackware 13.1) that was using non-server grade hardware (rather old 8 years old hardware), I never had these issues.

Absolutely! We're on the same page here! I get the new PSU, I wipe the HDD's , I reinstall Slackware64-14.1 fresh and restart fresh.

All I need to decide now is should I upgrade the storage subsystem with 15k SAS drives or not. I read a lot of places where SATA drives may be fine but are at best flaky when severely pushed to the edge...

Perhaps not the best thread to ask, but lets face the truth, we're all part of the great linux family (!) so what about CentOS instead of slackware for this server?

I am running Slack on ALL of my computers (no matter what the purpose of the machine is, media center, desktop machine, server, etc) because I know slackware better than any other distro and I love its KISS principle and the UNIX way of doing things. However, I have been disillusioned with rebuilding such system for a server because it requires tons of work installing packages, CPAN modules, building from scratch, configuring, tweaking, and there's always exceptions due to slackware (builds fails, because of.. apps not running because of...), etc...

I fould to have a working server OS, I had to spend SEVERAL hours on it, whereas, I hope, with CentOS or another server tailored OS, I would have this working state almost right after the initial OS installation.

There's a lot of other things but my intention is NOT to start a stupid flame war, there are enough out there and Im a slacker to start with so..

Im just wondering.. Extensively searching the web, I found only CentOS, RHEL & Ubuntu as recommended server OS'es (supported). Hell, Supermicro tech reps didnt even know what Slackware was!

If you look closely at my previous post, this is related to point #4: Opt for a different OS for this server.

Do what you need to do. Good luck!

Thats leaving me confused.. How should I interpret this answer?

You asked ...

The response from mlslk31 response says in essence - use CentOS if you want but since this is no longer about Slackware I won't be providing any more input on this topic.

At least that's how I read it.

(Interpretation service provided free of charge. )

I too have interpreted that the same way. Fine. Until I get a replacement PSU and do more testing, I understand that trying to initiate an actual conversation rather than a direct "There is a bug # 123ABC, please help" type of request wont bring me nowhere so I believe the topic is now obsolete.

A sincere thanks to all who have brought their fine advices and opinions!

You assume that folks that are answering your questions here are also knowledgeable on Centos/Ubuntu/Suse/whatever. Maybe they are, maybe they aren't. I'm not.

But I'm sure if you asked over in one of their forums, you'd get accurate and useful answers. Why not ask the experts?

Richard, i fully agree with you!

Like I said, as long as I am missing hardware components (namely the PSU) I will wait here.

When the machine is back operational (from a hardware POV), then I will post back here with slack questions!

In the meantime, I will try over to the Centos forums.

Just that. It wasn't loaded in any way. I simply have nothing to check right now because nothing has been settled, not even the operating system or disks that will be on the PC. There's a very high chance that the combination of fresh install and/or fresh disks and/or different kernel will cause bad issues to simply vanish. My only extra idea might be to restore / onto the old system as something not ext4 (preferably XFS), see if the issue still persists...then do all of that planned zeroing, disk installation, and so on. Even that would go better after a new PSU and another shot using ext4. Use what you're going to use, and if there's still a problem, I'll read about it then.

I've no worries about lpallard using another strain of Linux because I have uses for FreeBSD myself. I've no worries about lpallard going with RHEL or SLES because I couldn't argue paid Slackware support to my bosses even if Pat himself provided the support. I'm sure that lpallard would be just as happy (maybe happier) tweaking databases than tweaking servers, so if an easier path is seen, it doesn't hurt to look. My personal belief is that there is no free ride regarding Linux server configuration. In particular, if upstream is providing a hard security fix while the vendor is providing spelling corrections, I'm going to go upstream and take the security fix, not caring for a second what my package manager thinks of it. But that may continue for my own personal experience and not lpallard's experience.

In short, there was nothing better I could have posted than what I posted. Good luck. God bless you.

mlslk31, wow you're truly a gentleman!

I understand your response fully. Its just that in the past (not on this forum too much) but I've seen pretty nasty behaviors and replies from people who actually were taking it personally if you constructively criticized their favorite OS or piece of software... Sad!

You do not seem to be like that at all. Good to know!

Im also in alignment with what you said. Im waiting for IBM's response in regards to the compatibility of HGST's 15k600 Ultrastar SAS drives with their IBM M5016 ServeRAID controller, and if compatibility is not an issue, will get two of those fast SAS drives and reinstall the system from scratch.

Slackware is (and will remain for the forseeable future) my default and goto OS of choice. Not because its the best (I do not have the competencies, or experience or knowledge to be able to judge) but because its the OS that I became to fully understand and get used to the way things are done.

Centos is probably only a detour on a long road (after some time using it I will see). Stay tuned!