-----BEGIN PGP SIGNED MESSAGE-----
On 2012-06-29 16:53, Dave Howorth wrote:
Carlos E. R. wrote:
(S3) If I
understand correctly, your system (kernel) crashes? In
What I have discovered is that a call to ioctl() does not return. I
don't know if the function is part of libc or of the kernel.
ioctls are kernel entry points. If you think it might be crashing
before it gets to the kernel, you could single-step the application to
see exactly what fails.
What fails is the ioctl() function, that is proven already. See my code...
error = ioctl(dev, SNAPSHOT_CREATE_IMAGE, in_suspend);
The "1" prints, but not the "2", in hangs inside.
No possible, I
already asked in the bugzilla if this could be done.
s2disk doesn't output to serial port.
No, not the application's output. The kernel's log.
As I said, I asked if debugging while s2disk runs would be possible, and
I suggested using the serial port - see the bugzilla - and they said no.
phase there is only a text console working, messages are
printed there, and when the problem happens nothing prints any
message there. There is nothing nowhere.
I don't know how hibernation or s2disk work, but if the kernel is
still logging anything then you want to access it. It doesn't do any
harm to at least try does it?
I wanted to do it and they said "no".
So I invented the method of printing messages. I added printf() calls
directly in the code. They did not even tell me that trick.
Your alternative is to single-step the kernel, I
s2disk suspends all processes, nothing is running. And I don't know how
to use a debugger in Linux, even less with the kernel.
(b) increase the kernel's logging level to obtain
Not possible: writing to disk is disabled when hibernation starts
Logging to serial port or network does not require writing to disk.
They said "no".
There appears to be a specific parameter:
suspend loglevel u can specify the kernel console loglevel which the
s2disk/s2both and resume utilities will use to report progress. On a
stock kernel messages with level higher then 7 are usually not shown.
Where do I use that?
I have this in "/etc/sysconfig/syslog":
## Path: System/Logging
## Description: System logging
## Type: list(0,1,2,3,4,5,6,7)
## Default: 1
## Config: ""
## ServiceRestart: syslog
# Default loglevel for klogd
So it is 7 already.
Right now I edited "/etc/suspend.conf":
suspend loglevel = 255
I don't know what levels are valid, 255, as good a number as any.
As far as I know, the kernel logs to tty 10, which is the same one the
s2disk process uses. Nothing is written there, except s2disk own
messages, and my own added messages. If you know a way to tell the kernel
to be far more verbose and log what happens inside that ioctl call, tell
me, I'll do it. But what I think is needed is somebody to hack at the
kernel code and add printf() calls like I did inside the ioctl function.
Or tell me how to do that myself and I'll make that kernel here.
(Q4) Somewhere at the beginning, you mention nvidia.
mean you're running a tainted kernel? If so, can you reproduce the
problem with an untainted one?
The last time I tried with the open source driver, the machine would
not even hibernate except on runlevel 3. That's the reason I use
the proprietary nvidia driver.
OK, but as long as you use the nvidia driver, you will have to
isolate exactly what is failing in the kernel and provide a method to
reproduce the problem on hardware that can run an untainted kernel.
Then the devs will look at it.
Nobody looks at it, nobody answers at the bugzilla, nobody from the
kernel list where I wrote to answered my post. At the time I wrote a
bugzilla about the open driver not suspending
I want to try factory with the open driver, but I can not do because
factory is totally broken and no expectations of repair in sight.
Many machines do not even work with the open driver, and gnome people
want us to have 3D and hw accel... whom do I listen to?
also have problems hibernating as other people have
told me; but I'm the only one that has resorted to hacking at
s2disk, and I'm using 11.4.
The recent kernel problems were resolved by backing out a particular
faulty update. Thus they are a separate problem (unless your kernel
also has the faulty update?)
No, these people were having problems prior to that update.
But again, you should be testing with a recent kernel.
problem has already been fixed?
I doubt it. One person has tried 11.4, 12.1, tumbleweed. Same problem in all.
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 "Celadon" at Telcontar)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse+owner(a)opensuse.org