Bug#600846: The problem also exists in 2.6.32-27 version of linux-image-2.6.32-5-amd64 package.
hu...@online.de
linux-image-2.6.32-5-amd64 package.
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
maximilian attems
> The problem also exists in 2.6.32-27 version of
> linux-image-2.6.32-5-amd64 package.
please name the latest good 2.6.32-XX linux-image, which didn't show
the error, so that the regression can be bisected. all images should
be available on snapshot.debian.org.
thank you.
maximilian attems
> As far as I remember there was no good 2.6.32-XX linux-image which
> didn't show
> the error - all of them did.
> If my memory serves me well the last good kernel that didn't show the
> error was
> 2.6.30-1 , and the error came up in 2.6.30-2 . (If you want I could test
> this kernel version
> again on my system - just tell me how to add a valid public key so that
> synaptic accepts
> the snapshot repository).
oh well you probably mean abi number above and not version number,
so the regression is really old and most probably either due to
switch to libata or to KMS intel drivers.
in that case it be more useful to know if newer linux-2.6 is fixed,
by any chance tried anything newer from experimental?
current 2.6.36 linux-image installs just fine in testing.
can you reproduce it there?
> The problem is that I did not make any notes about this - I didn't
> intend to write
> a bug report at this time but expected the problem to vanish anyway with
> the update
> next week or so (but it didn't - for a lot of weeks now).
> So I am not sure about all of this - not even if the problem is caused
> by the kernel or by
> another component like Xserver or KDE - I must leave it to you linux
> professionals to
> make this decision.
> The only thing I am sure about is that every second or third
> Suspend-To-RAM hangs.
I see, thanks a lot for the quick responsiveness.
P.S.: please keep bug report on cc, to keep record of it, thanks.
hu...@online.de
xserver.xorg 7.5+8 .
maximilian attems
> The problem also exists with linux-image-2.6.36-rc6-amd64 and
> xserver.xorg 7.5+8 .
oh well, please double check with 2.6.36-trunk-amd64.
In the likely case of failure please report it upstream in
bugzilla.kernel.org and let us know the bug nr so that we
can track it.
thank you very much.
--
maks
hu...@online.de
But before putting something into bugzilla I'd like to tell you about
another
interesting detection I made now during testing:
For 6 times in follow the system showed the following absolute constant
behavior:
After booting, the first Suspend-To-RAM allways worked very fine and the
second Suspend-To-RAM allways constantly hung.
And after the first Suspend-To-RAM there existed some additional
processes in
the process list that did not exist after booting:
> root 3105 2 0 11:40 ? 00:00:00 [migration/1]
> root 3106 2 0 11:40 ? 00:00:00 [ksoftirqd/1]
> root 3107 2 0 11:40 ? 00:00:00 [watchdog/1]
> root 3108 2 0 11:40 ? 00:00:00 [kconservative/1]
> root 3109 2 0 11:40 ? 00:00:00 [radeon/1]
> root 3110 2 0 11:40 ? 00:00:00 [ext4-dio-unwrit]
> root 3111 2 0 11:40 ? 00:00:00 [ata/1]
> root 3112 2 0 11:40 ? 00:00:00 [crypto/1]
> root 3113 2 0 11:40 ? 00:00:00 [aio/1]
> root 3114 2 0 11:40 ? 00:00:00 [kondemand/1]
> root 3115 2 0 11:40 ? 00:00:00 [kblockd/1]
> root 3116 2 0 11:40 ? 00:00:00 [kintegrityd/1]
> root 3117 2 0 11:40 ? 00:00:00 [events/1]
> root 3119 500 0 11:40 ? 00:00:00 udevd --daemon
> root 3120 500 0 11:40 ? 00:00:00 udevd --daemon
For me it now looks like one (or some) of them might cause the problem.
hu...@online.de
the first Suspend-To-RAM, but the result was the same: hanging second
Suspend-To-RAM
root 2932 2 0 11:33 ? 00:00:00 [kworker/u:1]
root 2933 2 0 11:33 ? 00:00:00 [kworker/u:2]
root 2934 2 0 11:33 ? 00:00:00 [kworker/u:4]
root 2935 2 0 11:33 ? 00:00:00 [kworker/u:5]
root 2936 2 0 11:33 ? 00:00:00 [kworker/u:6]
root 2937 2 0 11:33 ? 00:00:00 [kworker/u:7]
root 2938 2 0 11:33 ? 00:00:00 [kworker/u:8]
root 2939 2 0 11:33 ? 00:00:00 [kworker/u:9]
root 2940 2 0 11:33 ? 00:00:00 [kworker/u:10]
root 2941 2 0 11:33 ? 00:00:00 [kworker/u:11]
root 2942 2 0 11:33 ? 00:00:00 [kworker/u:12]
root 2943 2 0 11:33 ? 00:00:00 [kworker/u:13]
root 2946 2 0 11:33 ? 00:00:00 [migration/1]
root 2947 2 0 11:33 ? 00:00:00 [kworker/1:3]
root 2948 2 0 11:33 ? 00:00:00 [ksoftirqd/1]
root 2949 2 0 11:33 ? 00:00:00 [watchdog/1]
root 2950 2 0 11:33 ? 00:00:00 [kworker/u:14]
root 2951 2 0 11:33 ? 00:00:00 [kworker/u:15]
root 2952 2 0 11:33 ? 00:00:00 [kworker/u:16]
root 2953 2 0 11:33 ? 00:00:00 [kworker/u:17]
root 2954 2 0 11:33 ? 00:00:00 [kworker/u:18]
root 2955 2 0 11:33 ? 00:00:00 [kworker/u:19]
root 2956 2 0 11:33 ? 00:00:00 [kworker/u:20]
root 2957 2 0 11:33 ? 00:00:00 [kworker/u:21]
root 2958 2 0 11:33 ? 00:00:00 [kworker/u:22]
root 2959 2 0 11:33 ? 00:00:00 [kworker/u:23]
root 2960 2 0 11:33 ? 00:00:00 [kworker/1:0]
root 2961 2 0 11:33 ? 00:00:00 [kworker/0:2]
root 2962 2 0 11:33 ? 00:00:00 [kworker/1:1]
root 2963 2 0 11:33 ? 00:00:00 [kworker/1:2]
root 2965 495 0 11:33 ? 00:00:00 udevd --daemon
root 2966 495 0 11:33 ? 00:00:00 udevd --daemon
hu...@online.de
and installed them on my notebook - without doing any other changes to
the system.
And the Suspend-To-RAM of all of the three 2.6.30 kernels worked
perfectly well !
So from my point of view the problem started definitely with the 2.6.32
kernel version.
The 2.6.30 kernel packages were:
linux-image-2.6.30-1-amd64_2.6.30-1_amd64.deb
linux-image-2.6.30-2-amd64_2.6.30-7_amd64.deb
linux-image-2.6.30-2-amd64_2.6.30-8squeeze1_amd64.deb (the latest I found)
With the 2.6.30 kernel there is the same effect of additional processes
coming up
after the first Suspend-To-RAM . These are:
> root 3092 2 0 20:22 ? 00:00:00 [migration/1]
> root 3093 2 0 20:22 ? 00:00:00 [ksoftirqd/1]
> root 3094 2 0 20:22 ? 00:00:00 [watchdog/1]
> root 3095 2 0 20:22 ? 00:00:00 [kconservative/1]
> root 3096 2 0 20:22 ? 00:00:00 [ata/1]
> root 3097 2 0 20:22 ? 00:00:00 [crypto/1]
> root 3098 2 0 20:22 ? 00:00:00 [aio/1]
> root 3099 2 0 20:22 ? 00:00:00 [kondemand/1]
> root 3100 2 0 20:22 ? 00:00:00 [kblockd/1]
> root 3101 2 0 20:22 ? 00:00:00 [kintegrityd/1]
> root 3102 2 0 20:22 ? 00:00:00 [events/1]
> root 3103 718 0 20:22 ? 00:00:00 udevd --daemon
> root 3104 718 0 20:22 ? 00:00:00 udevd --daemon
As can be seen the 2 processes
> root 3109 2 0 11:40 ? 00:00:00 [radeon/1]
> root 3110 2 0 11:40 ? 00:00:00 [ext4-dio-unwrit]
coming up in kernel 2.6.32 are missing.
maximilian attems
On Wed, Nov 03, 2010 at 08:41:54PM +0100, hu...@online.de wrote:
> I downloaded three versions of the 2.6.30 kernel from snapshot.debian.org
> and installed them on my notebook - without doing any other changes to
> the system.
>
> And the Suspend-To-RAM of all of the three 2.6.30 kernels worked
> perfectly well !
so other datapoints would be 2.6.31-* and the first 2.6.32-[1-4]-amd64
linux packages.
thanks.
hu...@online.de
linux-image-2.6.31-1-amd64_2.6.31-1_amd64.deb
and comes up in the first 2.6.32 kernel
linux-image-2.6.32-1-amd64_2.6.32-6_amd64.deb .
I have also filed a bug report to bugzilla.kernel.org, bug id is 22022 .
Thanks and regards
Rolf
maximilian attems
> The problem not exists in the one and only 2.6.31 kernel
>
> linux-image-2.6.31-1-amd64_2.6.31-1_amd64.deb
ok.
> and comes up in the first 2.6.32 kernel
>
> linux-image-2.6.32-1-amd64_2.6.32-6_amd64.deb .
>
> I have also filed a bug report to bugzilla.kernel.org, bug id is 22022 .
thanks, marked as forwarded.
please add dmesg output and lscpi -nnvv output to aboves.
devs usually don't like to follow html links to maybe find them.
also the "Other" "Other" seems a wrong product/ component nobody will look at.
has power a section with suspend?
Jonathan Nieder
maximilian attems wrote:
> also the "Other" "Other" seems a wrong product/ component nobody will look at.
> has power a section with suspend?
From bugzilla I see that you still have suspend trouble with v3.0.
Please follow the instructions from [1] to narrow down which subsystem
is responsible.
Thanks much,
Jonathan
[1] http://www.kernel.org/doc/Documentation/power/basic-pm-debugging.txt