There are two angles of attack to focus on when trying to debug something like this. I believe we've covered some of it near the start of this thread, but rather than you or I try to sort through the above, here's what I'd do:

1) The s2 script creates its own log (check near the beginning of the script, read the comments, as there are items that you can configure by adjusting some lines of the script) and tosses a few details of its own into it; but the majority of what ends up in the suspend2.log file, is merely CC'd from your kernel.log file, because that file is where the kernel itself will log anything it has to say while suspending. So for now, the section you will be interested in in the script, is here:
I have highlighted in bold the line which sets the name of the kernel.log file; please look in /var/log on your machine, and check the exact name of your kernel log file. Make sure that on the bold line above in your script, it is the same filename.

Next, the red parts above.. That is where you can set which type of debugging you want. How it works below:

/sys/power/pm_test is a virtual file, used for configuring debugging of power management features in the kernel. In the red code in the script above, the default contents of this file is the word "none", which means "no debugging, really do the suspend". If you wish to debug the suspend/hibernate operation, you need to comment out the "echo none" line, and uncomment one of the next lines below, to debug either one of the subsystems "freezer", "devices", "platform", "processors", or "core". Only one line at a time can be uncommented. So, let's say you have commented out the "none" line, and uncommented the next line to debug "freezer"; save the script, issue a suspend command, and when it's done, examine the log file. Repeat for each of the possible subsystems you can debug.
I can't remember exactly what sort of things get written to the logs during PM debugging, so if you get stuff you don't understand but it looks like it might be indicating a problem, post the log(s) for us, only including the timeframe from when you hit suspend, to when it was all done suspending. Note that the machine will not actually suspend when you're debugging - it only pretends to suspend.
When you are all done debugging, remember to put the script back the way it is - only the "none" line should be uncommented.

Other details/questions:

1) You are now using nvidia instead of ATI? Did you "uninstall" maybe an ATI proprietary driver, or did you simply stop using it? If the former, then maybe you should re-install your Xorg server package and Mesa packages, to make sure they're not damaged or corrupted by the driver removal.

2) What nvidia driver are you using? The blob (from nVidia) or the opensource one? Or maybe you're using Nouveau? Please tell us which one you are using.

That's all I have for now.
Good luck!

Lol!

Anyways, I am reading your previous post (not the one above!) and I have some questions:

I couldnt find such log in /var/log/ ... All I have in there:

I changed the kernel_log=/var/log/kernel to kernel_log=/var/log/kernel.log (big deal!) Is it normal? if not what should I do? The only "log" I can find is the suspend2.log ion bold above..

***********************************************************************

Also, I tried the debug level thing in your script. I commented out the

and uncommented

But the machine really goes to suspend (and then shutdown as I described earlier today..). It does not simulate a suspend to ram like you said. Am I missing something?

***********************************************************************

Yes!

I was using a proprietary ATI driver. The procedure to install the drivers are pretty different from Nvidia (in my experience). You download the driver tarball from ATI and its companion script that will convert the binary package into slackware packages (.txz). It is documented on the ATI wiki. I ended up with 2 fireglx_blablabla.txz packages to install. TO uninstall, the wiki simply said to REMOVEPKG the packages.

Do you think I should reinstall X and MESA? This htpc is 2 fingers away from the landfill so I dont want to push my luck...

I am using the blob from nvidia (downloaded from their driver ftp). AFAIK, lsmod will say "nvidia" in the loaded modules so I believe I am using nvidia not nouveau,

lpallard ->

It seems you have to reinstall xorg-server and mesa after uninstalling fglrx driver. The reason being: when you install fglrx, it changes xorg-server and mesa files, but these files are not changed back when you uninstall fglrx.

OK sounds good, your post fits perfectly in time! I just discovered that to install the nvidia drivers, you need to run init 3 or the drivers wont install (if X is running -> normal)

Entering init 3 the driver install script says "you appear to be running a X server.. setup cannot continue"

So I tried init 1 ( to kill everything) and the driver said "running in init1 can cause problems with improperly detected devices and .... and can cause future problems" or something like that.

How can I shutdown the x server while being in init3??

Should I reinstall X and mesa BEFORE the nvidia driver? If so, should I uninstall the nvidia driver first?

Once those 2 questions get answers I might be rolling!

IMO it should look like that:

1. Uninstall nvidia driver (I assume it's nvidia closed driver)
2. Reinstall xorg-server and mesa
3. Reboot and go to init 3 - easiest to do that is by pressing tab in lilo and adding "init 3" to your kernel name
4. Install nvidia driver again.

I'm not nvidia expert now and didn't read all the topic, but I think it's safe to blacklist nv and nouveau in /etc/modprobe.d/blacklist.conf.

Yep, this looks pretty accurate/close enough to get the nvidia driver installed properly. For me, I would say that step #1 is optional or unnecessary; and I would move step #3 up and make it step #2. So, note the numbers:

1. Reboot and/or go to init 3 (you could also just open a terminal, become root, and tell it `init 3` and it will work.
2. Reinstall xorg-server and mesa
3. Install nvidia driver again.

Yes, should be fine, and actually *should* be done, especially with the nouveau; the `nv` should not be an issue either way.

I've installed while in init 1, and not had any problems. However, in your case, we have enough uncertainties already, so init 3 is recommended.
Going from init4 to init3 on Slackware (if I remember right) will kill X automatically. If it does not, then once you are in init 3 (it may log you out on the virtual terminal, just log back in as root) give the command `killall X` as root, and X will be stopped.

Yes.
No matter. I wouldn't bother.

I remember that a long time ago, I changed my log files naming convention so that it either had a .log extension on all the logfiles, or I got *rid* of the .log extension - I can't remember which I did, nor which is the default.
Secondly: if I remember right (heh, again: my memory sucks!), there was some issue with the syslogger a while back, where it was not actually creating/logging all the logs we usually would have expected it to be.
You might want to investigate whether your syslogger is configured right, and that it is actually logging all the stuff it is supposed to be.
The config file for the syslogger should be /etc/syslog.conf - so make sure it's set up appropriately.

If you have no "kernel.log" or "kernel" logfile in /var/log, something is amiss. You should have one.
changing that line in the script, will only have some benefit/purpose, if your system has a kernel log. If the system has no kernel log being logged, OR the name you give on that line in the script is not the same filename, then your suspend2.log file will be missing most of its contents.

Umm, yes, you're missing something, and it's at least 1/2 my fault as I neglected to point it out:
In order to use the debug features, your kernel must already have the "Enable PM Debug" feature enabled in its compilation, or you can't debug power management. "PM Debug" is a compile-time kernel build option. I'm not sure if it can be enabled via a boot-line switch - I doubt it - you likely would need to rebuild your kernel to enable it. I remember another user of my script wanted to use the debug features too, but that person also was in the same boat. In that thread, I believe I posted a fairly complete procedure for doing the rebuild, if you're interested. In a moment, I'll try to locate that thread.

Please see this thread, beginning with the linked post here:

http://www.linuxquestions.org/questi...7/#post3910001

Just to finish with that nvidia stuff, I couldnt install the driver in init3... trying to issue killall X will result in "no process killed". I have no idea whats going on. I had to enter init 1 to install the driver. I blacklisted the bad modules (nv & nouveau) and it seems to have installed fine. I am back to the beginning again...

The only issue I have is an overscan compensation issue.. Every time I reboot or restart, I have to launch the nvidia control panel and without even touching anything, the picture re-scales back to normal... bug for sure... there is bugs everywhere...

I'll look at your link some time... Honestly, the list of problems I faced in building this htpc under linux is unbelievable... from driver problems to application problems, visual bugs, audio problems, remote controller problems, etc you name it... 7 weeks after the start of that project I worked on this pretty much everyday and I still cant use the machine to watch a movie.

I'll have to think about all that and decide where should I go.

I'll post back.

thanks!

Hmm.. Well, if it says "no process killed", then either:

1) you're using the wrong process name, i.e. "x" rather than "X" for example.. Or:
2) X is already not running.

When in init3, you could run `top` or `htop` and look at the process tree, to make sure there's no X or Xorg process running.

Aside from the overscan issue, do you now have the suspend/resume working properly again? You did get the driver installed somehow? Or no...

LOL. That is a lot of fiddling, and you *still* can't use it to watch a movie? Hmmmm.. Time for a cost analysis - maybe a newer machine is in order soon..

Well, good luck - I hope you get this machine or another one, working as your movie machine soon!

Cheers.

Funny you talk about a new machine, this one is 7 weeks old!

The thing is that I worked too much on this machine just to let it go and install windowz...

Do you think slackware might be just too "primitive" for a htpc build?

Oops! I must have your machines mixed up - I thought this was a rather old machine.
But, if it is physically a "shiny new machine" that was just recently purchased, it is *possible* that there are features of the motherboard or onboard hardware (video, audio..) that are better addressed in very new(er) linux kernels; depending on how old your kernel is, it's worth considering upgrading it for extremely new hardware.

I agree- regardless how much you've worked on it, I'd not install Windows; but that's just me..
No, not really; and 'primitive' is not the word you were looking for. :-)

You could conceivably be running into the very same problems, and/or very different problems - maybe more, or maybe less - with any distro. Some distros may have workarounds patched into their kernels or their applications (Ubuntu for example) for various reasons & issues, but not necessarily the same issues that you are having. (which we don't actually know precisely what-all issues you have had since starting this project; maybe a new thread summarizing your project's goal, the machine & hardware involved, and all the issues you've had, would be beneficial?). And some distros may make it easier/faster (using repos for example) to get loads of not-included software with a couple clicks, if you need it. But in short, do I think that using Slackware puts you at a disadvantage for making an HTPC? No. Might it involve more work to set up? *** Ehhh, maybe-- but I'd think that might have more to do with wanting to install apps/things that Slack doesn't come with by default, so you need to find & compile some stuff.

*** Having said the above - I have never set up an HTPC using my Slackware boxes - though we have used the main machine for watching movies on the TV - so, I would probably not be acquainted with the common pitfalls or issues of trying to do so, but with my current machine, I would not *expect* to encounter any problems if I were wanting to make an HTPC out of it. Every machine is different too, so problems specific to my machine may not be happening on your machine, and vice-versa. But maybe there are other Slackware HTPC users around here, who can provide some more help - again, perhaps a reason to make a dedicated thread in /Slackware forum, about your HTPC?

I'd like to see this work great in the end, on Slackware, so Good Luck, and don't give up!!