On 2012-01-23 13:46, Ctwx wrote:
>
> I have the same problem. I have an ASUS EeePC 1201T, 2 GB of RAM, 4 GB
> Swap, running 12.1. On 11.4 I didn’t had this problem. All I get is the
> snapshotting system info and then it’s frozen. I can’t even press
> SysRq+R+E+I+S+U+B.
If it worked in 11.4 and now does not, report in bugzilla.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)
Funny thing is, now my system is hibernating fine. I haven’t done anything to try resolve the issue yet so am not sure why it’s now working. Perhaps it has something to do with what apps were open at the time. I’ll have to monitor it more carefully now.
I do have to say that the whole hibernate / return from sleep is not very elegant. There is a lot of screen flicking going on, especially when coming out of hibernate. Lots of artifacts, flicking between a black screen with white stripes to the console screen then flashing the desktop for a split second then black screen until it finally pops up with the KDE locked screen login prompt.
On 2012-01-24 09:36, suse tpx60s wrote:
> I do have to say that the whole hibernate / return from sleep is not
> very elegant. There is a lot of screen flicking going on, especially
> when coming out of hibernate. Lots of artifacts, flicking between a
> black screen with white stripes to the console screen then flashing the
> desktop for a split second then black screen until it finally pops up
> with the KDE locked screen login prompt.
I hibernate from text mode if possible, and I disable the splash display.
No graphics at all in the process.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)
How do you disable the splash display? When you say you hibernate from text mode do you mean you switch to the console Alt-Ctrl-F1?
On 2012-01-24 13:56, suse tpx60s wrote:
> How do you disable the splash display? When you say you hibernate from
> text mode do you mean you switch to the console Alt-Ctrl-F1?
Yes, I switch to the console and type “pm-hibernate” as root. The splash is
controlled in “/etc/suspend.conf”
splash = n
That way I can see the messages, I see what its happening, instead of a
progress bar that doesn’t give a clue.
Graphics is one of the worst sources of problems with hibernation. A year
ago with the open source nvidia driver my system crashed on hibernation,
and it worked with the closed source. I use it every day, but eventually,
say after 15 days, it crashes badly. Inevitably.
In the laptop I have Intel graphics, and hibernation fails earlier, say
after five times. Sometimes I get the same crash without hibernation.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)
Hi Carlos, I just tried that.
I disabled splash and went into console mode and tried to hibernate.
But the only on-screen output was
s2disk: Snapshotting system
and nothing else. It froze like that.
Thanks!
Sergio
On 2012-01-25 15:16, sergiom99 wrote:
>
> Hi Carlos, I just tried that.
> I disabled splash and went into console mode and tried to hibernate.
> But the only on-screen output was
>> s2disk: Snapshotting system
>
> and nothing else. It froze like that.
That’s bad. You have to write a bugzilla and report. If it worked in 11.4
say so, it is a regression.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)
I already added my feedback to https://bugzilla.novell.com/show_bug.cgi?id=633491 several days ago.
B U M P . . .
I should say, I fixed my problems. Hibernate and Standby work now. I rebuilt the old Kernel 2.6.37 from openSUSE 11.4. This was the Kernel my notebook worked fine with. My notebook doesn’t freeze anymore.
On 02/06/2012 09:36 AM, Ctwx wrote:
>
> I should say, I fixed my problems. Hibernate and Standby work now. I
> rebuilt the old Kernel 2.6.37 from openSUSE 11.4. This was the Kernel my
> notebook worked fine with. My notebook doesn’t freeze anymore.
As this is a kernel problem that likely affects only a few machines, it is in
your best interests to find the problem. Unless it is reported so that it can be
fixed, future kernels will continue to fail.
Your next step would be to do a kernel bisection using a git tree. You know that
3.1 fails and that 2.6.37 works. Those would be the starting points. The end
point of bisection is the single commit that caused the regression. Once you
know that information and post it on linux-kernel@vger.kernel.org and
bugzilla.kernel.org, then the maintainer of the affected sub-system will work
with you on a patch.
Bisection will be a lot of work involving 20-30 kernel builds, but it is quite
efficient at finding this sort of problem.
I’d be glad to help to find the cause of this problem. By “bisection” you mean, I should try different (probably vanilla) kernels starting from 2.6.37? Hmm… And you say 20-30 kernel builds? ^^ My notebook needs over 2 hours to build one. That’ll be much fun, but that’s OK. 
I’ve just reported it in the Novell bugzilla.
This is a very old bug report from 2010-08-22 to the release openSUSE 11.3 kernels version ca. 2.6.34 - see: Archive:Product highlights 11.3 - openSUSE Wiki - and a ThinkPad X31 (also against kernel linux 2.6.37.1).
Even if the this old event would be connected to your actual problem - probably nobody from the developers will read a bug report to a version with an expired lifetime like 11.3.
So I guess it would be best to for you to open an new bugreport against openSUSE 12.1 with your kernel linux 3.1.0-… (at least if no specific suspend to disk/power management report is already existing against/for openSUSE 12.1) and leave a note at the old report with the number and/or a link to your new report (especially for the second user in this bugzilla thread with your problem actually).
Regards
Martin
P. S.
or/and directly against the kernel - like lwfinger (being a kernel developer) proposed…
The Bug report you linked isn’t mine (if your intention was to answer my last post). This is mine: https://bugzilla.novell.com/show_bug.cgi?id=732667
Thanks
I saw only the bugreport that the original poster sergiom99 linked in this forums’ thread. Probably he should add his report to the bugzilla thread you opened and liked above.
But reading your bugreport I guess it would be not the worst idea to add the information to your normally used kernels with problems from
uname -a
(flavor version bit etc.) to it. Maybe you shall also add some more information via edit to the name : “Bug 732667 - openSUSE freezes randomly” does not sound very informative to me. And if I understood lwfinger the right way (probably a kernel problem) - changing the component from “basesystem” to “kernel” (and linking to his comment here) may be a good idea also…
Regards
Martin
OK, I made the changes excapt for the topic. I can’t find any way to change the topic. Changing the component to “kernel” worked.
I’m not sure which exact kernel version caused my notebook to freeze but it was at least 3.0.
Thanks!
On 02/06/2012 10:06 AM, Ctwx wrote:
>
> I’d be glad to help to find the cause of this problem. By “bisection”
> you mean, I should try different (probably vanilla) kernels starting
> from 2.6.37? Hmm… And you say 20-30 kernel builds? ^^ My notebook needs
> over 2 hours to build one. That’ll be much fun, but that’s OK.
>
> I’ve just reported it in the Novell bugzilla.
Are you using the j switch on the build? If not, that will speed up the build.
The command should be ‘make -jX’, where X is 2 times the number of full CPU
cores - I exclude any hyper-threaded cores in the count.
The second reason your laptop takes so long is because you are probably using
the same configuration file as the distribution kernels, which need to support
the computers of everyone that might use openSUSE. In that configuration, over
2000 modules are built, whereas your system probably needs only about 150. To
get a reduced number, save your current configuration, and make sure that every
USB device that you will use has been plugged in to get its driver loaded, or
issue modprobe commands for every driver you will need… They start with ‘make
localmodconfig’, which will generate a configuration file that includes all the
kernel features of your current .config, but only those modules that are
currently loaded. With my dual-core AMD cpu running at 2 GHz, 3 GB RAM, and
10,000 RPM disk, such a build incorporates 105 modules and builds in just under
19 minutes, while using nearly 29.5 minutes of CPU time - it uses both CPUs more
than 75% of the time.
Oh, I didn’t saw your answer when I posted my last post.
My 2.6.37 kernel was build using the source files to build a RPM file. What mean is, that I had to set “MAKE_ARGS=-j2 rpmbuild -ba”. But it wasn’t faster. It’s only a single core AMD Athlon Neo processor MV-40 @ 1.60 GHz. Not that fast, I have to admit.
Yes. I wanted to make sure, that my kernel is as original as possible to find out if it was really the kernel that caused the freezes. Now I know it was and that 2.6.37 works great. So I could not create an own configuration.
OK, I’ll try that. I heard once “localmodconfig” won’t be sufficient but I didn’t try it out yet. So, I’ll give it a try and hope all required drivers will be inside. If not, I’ll have to find out what’s missing.
On my quad core AMD cpu @ 3.4 GHz with 8 GB RAM and a 7200 RPM disk ([OT]where did you get this fast disk?![/OT]) I need around 20 minutes to build a vanilla kernel using the “allyesconfig”. Don’t get me wrong! I don’t want to compare my machine to yours, but that reminds me, that I could build the kernels on my PC instead. But before I do so, I probably have to upgrade my openSUSE 11.4 to 12.1, and upgrade the software that I’ll have the same libraries on it to have a compatible kernel, do I?
Hmm… I’ll try out the localmodconfig now. I hope that’ll speed up the built time. ^^
Thanks for your answer.
On 02/06/2012 12:26 PM, Ctwx wrote:
>
> Oh, I didn’t saw your answer when I posted my last post.
>
> lwfinger;2437930 Wrote:
>> Are you using the j switch on the build? If not, that will speed up the
>> build.
>> The command should be ‘make -jX’, where X is 2 times the number of full
>> CPU
>> cores - I exclude any hyper-threaded cores in the count.
> My 2.6.37 kernel was build using the source files to build a RPM file.
> What mean is, that I had to set “MAKE_ARGS=-j2 rpmbuild -ba”. But it
> wasn’t faster. It’s only a single core AMD Athlon Neo processor MV-40 @
> 1.60 GHz. Not that fast, I have to admit.
>
> lwfinger;2437930 Wrote:
>> The second reason your laptop takes so long is because you are probably
>> using
>> the same configuration file as the distribution kernels, which need to
>> support
>> the computers of everyone that might use openSUSE.
> Yes. I wanted to make sure, that my kernel is as original as possible
> to find out if it was really the kernel that caused the freezes. Now I
> know it was and that 2.6.37 works great. So I could not create an own
> configuration.
>
> lwfinger;2437930 Wrote:
>> In that configuration, over
>> 2000 modules are built, whereas your system probably needs only about
>> 150. To
>> get a reduced number, save your current configuration, and make sure
>> that every
>> USB device that you will use has been plugged in to get its driver
>> loaded, or
>> issue modprobe commands for every driver you will need… They start
>> with ‘make
>> localmodconfig’, which will generate a configuration file that includes
>> all the
>> kernel features of your current .config, but only those modules that
>> are
>> currently loaded.
> OK, I’ll try that. I heard once “localmodconfig” won’t be sufficient
> but I didn’t try it out yet. So, I’ll give it a try and hope all
> required drivers will be inside. If not, I’ll have to find out what’s
> missing.
>
> lwfinger;2437930 Wrote:
>> With my dual-core AMD cpu running at 2 GHz, 3 GB RAM, and
>> 10,000 RPM disk, such a build incorporates 105 modules and builds in
>> just under
>> 19 minutes, while using nearly 29.5 minutes of CPU time - it uses both
>> CPUs more
>> than 75% of the time.
> On my quad core AMD cpu @ 3.4 GHz with 8 GB RAM and a 7200 RPM disk
> (where did you get this fast disk?!) I need around 20 minutes
> to build a vanilla kernel using the “allyesconfig”. Don’t get me wrong!
> I don’t want to compare my machine to yours, but that reminds me, that I
> could build the kernels on my PC instead. But before I do so, I probably
> have to upgrade my openSUSE 11.4 to 12.1, and upgrade the software that
> I’ll have the same libraries on it to have a compatible kernel, do I?
>
> Hmm… I’ll try out the localmodconfig now. I hope that’ll speed up the
> built time. ^^
I ordered that disk on-line and replaced the one in my laptop.
If you have such a fast system available, use it. It will not be necessary to
upgrade it. I use a dual-core 3.8 GHz AMD to build kernels for most of my really
slow machines - it runs openSUSE 11.2. I use NFS to export the file system with
the source. In addition, I never make an rpm, rather I run the make on the fast
computer, then mount that fs on the target, cd to the source directory, and run
‘sudo make modules_install install’. That adds the new kernel to the GRUB menu
and keeps the old one so that if it available if you make a mistake. I do have
to clean up /boot/grub/menu.list, /boot, and /lib/modules once in a while, but
it is safe. Note: my actual command on the server is ‘make -j4 ARCH=i386’ as I’m
building 32-bit kernels on a 64-bit host.