Re: Revert 9745cdb36da83aeec198650b410ca06304cf792 ("select: use freezable blocking call")?
On Tue, Oct 29, 2013 at 7:59 PM, Rafael J. Wysocki wrote:
> On Tuesday, October 29, 2013 07:39:23 PM Josh Boyer wrote:
>> On Tue, Oct 29, 2013 at 4:58 PM, Rafael J. Wysocki
>> wrote:
>> > On 10/29/2013 8:41 PM, Paul Bolle wrote:
>> >>
>> >> 0) Summary: ever since I tried running (release candidates of) v3.11 on
>> >> the two working i686s I still have lying around I ran into issues on
>> >> resuming from suspend. Reverting 9745cdb36da83aeec198650b410ca06304cf792
>> >> ("select: use freezable blocking call") resolves those issues.
>> >>
>> >> 1) Resuming from suspend on i686 on (release candidates of) v3.11 and
>> >> later triggers issues like:
>> >> traps: systemd[1] general protection ip:b738e490 sp:bf882fc0 error:0
>> >> in libc-2.16.so[b731c000+1b]
>> >>
>> >> and
>> >> traps: rtkit-daemon[552] general protection ip:804d6e5 sp:b6cb32f0
>> >> error:0 in rtkit-daemon[8048000+d000]
>> >>
>> >> Once I hit the systemd error I can only get out of the mess that the
>> >> system is at that point by power cycling it.
>> >>
>> >> 2) I bisected that issue to commit
>> >> 9745cdb36da83aeec198650b410ca06304cf792 ("select: use freezable blocking
>> >> call"). The, rather impressive, bisect log is pasted at the end of this
>> >> message. It took 23 builds to pinpoint this issue in the v3.10..v3.11
>> >> range! Sadly, I have no clue why that commit triggers this issue.
>> >>
>> >> 3) Reverting that commit on top of v3.12-rc7 gets me a system that
>> >> resumes without issues. (That revert needed one trivial context change.
>> >> Note that I haven't actually tried v3.12-rc7 plain. But v3.12-rc6 and
>> >> earlier also had this issue, so I'm sure the revert did the trick for
>> >> v3.12-rc7.)
>> >>
>> >> 4) Should this commit be reverted? Or is there a better fix?
>> >
>> >
>> > In short, yes, it should.
>> >
>> > I've already queued up a revert of something very similar and I'm going to
>> > revert this one too.
>>
>> To be clear, that's queued for 3.12 which is releasing really soon
>> now. Is that correct?
>
> Yes, it is. I'm going to send a pull request with that tomorrow if all goes
> well.
Excellent. Thanks for confirming.
josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Revert 9745cdb36da83aeec198650b410ca06304cf792 ("select: use freezable blocking call")?
On Tuesday, October 29, 2013 07:39:23 PM Josh Boyer wrote:
> On Tue, Oct 29, 2013 at 4:58 PM, Rafael J. Wysocki
> wrote:
> > On 10/29/2013 8:41 PM, Paul Bolle wrote:
> >>
> >> 0) Summary: ever since I tried running (release candidates of) v3.11 on
> >> the two working i686s I still have lying around I ran into issues on
> >> resuming from suspend. Reverting 9745cdb36da83aeec198650b410ca06304cf792
> >> ("select: use freezable blocking call") resolves those issues.
> >>
> >> 1) Resuming from suspend on i686 on (release candidates of) v3.11 and
> >> later triggers issues like:
> >> traps: systemd[1] general protection ip:b738e490 sp:bf882fc0 error:0
> >> in libc-2.16.so[b731c000+1b]
> >>
> >> and
> >> traps: rtkit-daemon[552] general protection ip:804d6e5 sp:b6cb32f0
> >> error:0 in rtkit-daemon[8048000+d000]
> >>
> >> Once I hit the systemd error I can only get out of the mess that the
> >> system is at that point by power cycling it.
> >>
> >> 2) I bisected that issue to commit
> >> 9745cdb36da83aeec198650b410ca06304cf792 ("select: use freezable blocking
> >> call"). The, rather impressive, bisect log is pasted at the end of this
> >> message. It took 23 builds to pinpoint this issue in the v3.10..v3.11
> >> range! Sadly, I have no clue why that commit triggers this issue.
> >>
> >> 3) Reverting that commit on top of v3.12-rc7 gets me a system that
> >> resumes without issues. (That revert needed one trivial context change.
> >> Note that I haven't actually tried v3.12-rc7 plain. But v3.12-rc6 and
> >> earlier also had this issue, so I'm sure the revert did the trick for
> >> v3.12-rc7.)
> >>
> >> 4) Should this commit be reverted? Or is there a better fix?
> >
> >
> > In short, yes, it should.
> >
> > I've already queued up a revert of something very similar and I'm going to
> > revert this one too.
>
> To be clear, that's queued for 3.12 which is releasing really soon
> now. Is that correct?
Yes, it is. I'm going to send a pull request with that tomorrow if all goes
well.
Thanks!
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Revert 9745cdb36da83aeec198650b410ca06304cf792 ("select: use freezable blocking call")?
On Tue, Oct 29, 2013 at 4:58 PM, Rafael J. Wysocki
wrote:
> On 10/29/2013 8:41 PM, Paul Bolle wrote:
>>
>> 0) Summary: ever since I tried running (release candidates of) v3.11 on
>> the two working i686s I still have lying around I ran into issues on
>> resuming from suspend. Reverting 9745cdb36da83aeec198650b410ca06304cf792
>> ("select: use freezable blocking call") resolves those issues.
>>
>> 1) Resuming from suspend on i686 on (release candidates of) v3.11 and
>> later triggers issues like:
>> traps: systemd[1] general protection ip:b738e490 sp:bf882fc0 error:0
>> in libc-2.16.so[b731c000+1b]
>>
>> and
>> traps: rtkit-daemon[552] general protection ip:804d6e5 sp:b6cb32f0
>> error:0 in rtkit-daemon[8048000+d000]
>>
>> Once I hit the systemd error I can only get out of the mess that the
>> system is at that point by power cycling it.
>>
>> 2) I bisected that issue to commit
>> 9745cdb36da83aeec198650b410ca06304cf792 ("select: use freezable blocking
>> call"). The, rather impressive, bisect log is pasted at the end of this
>> message. It took 23 builds to pinpoint this issue in the v3.10..v3.11
>> range! Sadly, I have no clue why that commit triggers this issue.
>>
>> 3) Reverting that commit on top of v3.12-rc7 gets me a system that
>> resumes without issues. (That revert needed one trivial context change.
>> Note that I haven't actually tried v3.12-rc7 plain. But v3.12-rc6 and
>> earlier also had this issue, so I'm sure the revert did the trick for
>> v3.12-rc7.)
>>
>> 4) Should this commit be reverted? Or is there a better fix?
>
>
> In short, yes, it should.
>
> I've already queued up a revert of something very similar and I'm going to
> revert this one too.
To be clear, that's queued for 3.12 which is releasing really soon
now. Is that correct?
josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Revert 9745cdb36da83aeec198650b410ca06304cf792 ("select: use freezable blocking call")?
On 10/29/2013 10:15 PM, Paul Bolle wrote: On Tue, 2013-10-29 at 21:58 +0100, Rafael J. Wysocki wrote: On 10/29/2013 8:41 PM, Paul Bolle wrote: 4) Should this commit be reverted? Or is there a better fix? In short, yes, it should. I've already queued up a revert of something very similar and I'm going to revert this one too. If you do, the revert should go into stable for v3.11+ too, shouldn't it? I'll ask stable to pick it up later (or you can do that too). Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Revert 9745cdb36da83aeec198650b410ca06304cf792 ("select: use freezable blocking call")?
On Tue, 2013-10-29 at 21:58 +0100, Rafael J. Wysocki wrote: > On 10/29/2013 8:41 PM, Paul Bolle wrote: > > 4) Should this commit be reverted? Or is there a better fix? > > In short, yes, it should. > > I've already queued up a revert of something very similar and I'm going > to revert this one too. If you do, the revert should go into stable for v3.11+ too, shouldn't it? Thanks, Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Revert 9745cdb36da83aeec198650b410ca06304cf792 ("select: use freezable blocking call")?
On 10/29/2013 8:41 PM, Paul Bolle wrote:
0) Summary: ever since I tried running (release candidates of) v3.11 on
the two working i686s I still have lying around I ran into issues on
resuming from suspend. Reverting 9745cdb36da83aeec198650b410ca06304cf792
("select: use freezable blocking call") resolves those issues.
1) Resuming from suspend on i686 on (release candidates of) v3.11 and
later triggers issues like:
traps: systemd[1] general protection ip:b738e490 sp:bf882fc0 error:0 in
libc-2.16.so[b731c000+1b]
and
traps: rtkit-daemon[552] general protection ip:804d6e5 sp:b6cb32f0 error:0
in rtkit-daemon[8048000+d000]
Once I hit the systemd error I can only get out of the mess that the
system is at that point by power cycling it.
2) I bisected that issue to commit
9745cdb36da83aeec198650b410ca06304cf792 ("select: use freezable blocking
call"). The, rather impressive, bisect log is pasted at the end of this
message. It took 23 builds to pinpoint this issue in the v3.10..v3.11
range! Sadly, I have no clue why that commit triggers this issue.
3) Reverting that commit on top of v3.12-rc7 gets me a system that
resumes without issues. (That revert needed one trivial context change.
Note that I haven't actually tried v3.12-rc7 plain. But v3.12-rc6 and
earlier also had this issue, so I'm sure the revert did the trick for
v3.12-rc7.)
4) Should this commit be reverted? Or is there a better fix?
In short, yes, it should.
I've already queued up a revert of something very similar and I'm going
to revert this one too.
Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Revert 9745cdb36da83aeec198650b410ca06304cf792 ("select: use freezable blocking call")?
0) Summary: ever since I tried running (release candidates of) v3.11 on
the two working i686s I still have lying around I ran into issues on
resuming from suspend. Reverting 9745cdb36da83aeec198650b410ca06304cf792
("select: use freezable blocking call") resolves those issues.
1) Resuming from suspend on i686 on (release candidates of) v3.11 and
later triggers issues like:
traps: systemd[1] general protection ip:b738e490 sp:bf882fc0 error:0 in
libc-2.16.so[b731c000+1b]
and
traps: rtkit-daemon[552] general protection ip:804d6e5 sp:b6cb32f0 error:0
in rtkit-daemon[8048000+d000]
Once I hit the systemd error I can only get out of the mess that the
system is at that point by power cycling it.
2) I bisected that issue to commit
9745cdb36da83aeec198650b410ca06304cf792 ("select: use freezable blocking
call"). The, rather impressive, bisect log is pasted at the end of this
message. It took 23 builds to pinpoint this issue in the v3.10..v3.11
range! Sadly, I have no clue why that commit triggers this issue.
3) Reverting that commit on top of v3.12-rc7 gets me a system that
resumes without issues. (That revert needed one trivial context change.
Note that I haven't actually tried v3.12-rc7 plain. But v3.12-rc6 and
earlier also had this issue, so I'm sure the revert did the trick for
v3.12-rc7.)
4) Should this commit be reverted? Or is there a better fix?
Paul Bolle
# bad: [6e4664525b1db28f8c4e1130957f70a94c19213e] Linux 3.11
# good: [8bb495e3f02401ee6f76d1b1d77f3ac9f079e376] Linux 3.10
git bisect start 'v3.11' 'v3.10'
# bad: [8b70a90cabafb6a6e1a0d3f838b38355fe48337e] Merge branch 'for-v3.11' of
git://git.linaro.org/people/mszyprowski/linux-dma-mapping
git bisect bad 8b70a90cabafb6a6e1a0d3f838b38355fe48337e
# good: [ab3d681e9d41816f90836ea8fe235168d973207f] Merge branch
'core-rcu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good ab3d681e9d41816f90836ea8fe235168d973207f
# bad: [862f0012549110d6f2586bf54b52ed4540cbff3a] Merge tag 'pci-v3.11-changes'
of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci
git bisect bad 862f0012549110d6f2586bf54b52ed4540cbff3a
# good: [60b5adffb4f3e4b4c1978959f24e8e531b2ef3cb] Merge tag 'gpio-for-v3.11-1'
of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
git bisect good 60b5adffb4f3e4b4c1978959f24e8e531b2ef3cb
# good: [fe489bf4505ae26d3c6d6a1f1d3064c2a9c5cd85] Merge tag 'for-linus' of
git://git.kernel.org/pub/scm/virt/kvm/kvm
git bisect good fe489bf4505ae26d3c6d6a1f1d3064c2a9c5cd85
# skip: [405a1086bdd091d2d55db0ac905cd6332b35cec1] Merge branch 'pm-cpufreq'
git bisect skip 405a1086bdd091d2d55db0ac905cd6332b35cec1
# good: [f4fd3797848aa04e72e942c855fd279840a47fe4] acpi-cpufreq: Add new sysfs
attribute freqdomain_cpus
git bisect good f4fd3797848aa04e72e942c855fd279840a47fe4
# bad: [2c843bd92ec276ecb68504b3b5ffa7066183f032] Merge branch 'pm-cpufreq'
git bisect bad 2c843bd92ec276ecb68504b3b5ffa7066183f032
# skip: [e8b6cb3947430d62538d88f615c007a51aeb23fe] Merge branch 'acpi-doc'
git bisect skip e8b6cb3947430d62538d88f615c007a51aeb23fe
# good: [1d1ea1b723d9f239f736b8cf284327cbbf9d15d1] ACPICA: Standardize all
switch() blocks
git bisect good 1d1ea1b723d9f239f736b8cf284327cbbf9d15d1
# skip: [e52cff8bdd4a30c40a7f65c7ea8f1f425f8a15eb] Merge branch 'pm-assorted'
git bisect skip e52cff8bdd4a30c40a7f65c7ea8f1f425f8a15eb
# good: [39688ce6facd63de796def41a0b9012882b5cc14] PM / devfreq: account
suspend/resume for stats
git bisect good 39688ce6facd63de796def41a0b9012882b5cc14
# good: [173a5a4c909789fcd57d00355d2237618a3824a4] ACPI / processor: Fix
potential NULL pointer dereference in acpi_processor_add()
git bisect good 173a5a4c909789fcd57d00355d2237618a3824a4
# skip: [207bc1181b1c03ab6ecb55bca5b307606dd1d6bc] Merge branch 'freezer'
git bisect skip 207bc1181b1c03ab6ecb55bca5b307606dd1d6bc
# good: [613f5d13b569859171f0896fbc73ee0bfa811fda] freezer: skip waking up
tasks with PF_FREEZER_SKIP set
git bisect good 613f5d13b569859171f0896fbc73ee0bfa811fda
# good: [9b5c7a5a977a330ffaf83c4d383ba247c74c800f] ACPI / PM: Fix possible NULL
pointer deref in acpi_pm_device_sleep_state()
git bisect good 9b5c7a5a977a330ffaf83c4d383ba247c74c800f
# good: [45f0a85c8258741d11bda25c0a5669c06267204a] PM / Runtime: Rework the
"runtime idle" helper routine
git bisect good 45f0a85c8258741d11bda25c0a5669c06267204a
# bad: [2cc6ced132f472b2bdb619960a650b9a85cdd34f] Merge branch 'pm-cpufreq'
git bisect bad 2cc6ced132f472b2bdb619960a650b9a85cdd34f
# good: [d24c2a4f919d17bd1ae4f4010a38ab07ece99cf7] PM / QoS: correct the valid
range of pm_qos_class
git bisect good d24c2a4f919d17bd1ae4f4010a38ab07ece99cf7
# bad: [2b15af6f953012aac49984ead3f8ec744d941540] af_unix: use freezable
blocking calls in read
git bisect bad 2b15af6f953012aac49984ead3f8ec744d941540
# good: [1c441e921201d523b5a6036aea22b0b426bf1af2] epoll: use freezable
blocking call
git bisect good 1c441e921201d523b5a6036aea22b0b426bf1af2
# bad: [56467c7697f5aef6974501fbe2c3e63674583549]
Revert 9745cdb36da83aeec198650b410ca06304cf792 (select: use freezable blocking call)?
0) Summary: ever since I tried running (release candidates of) v3.11 on the two working i686s I still have lying around I ran into issues on resuming from suspend. Reverting 9745cdb36da83aeec198650b410ca06304cf792 (select: use freezable blocking call) resolves those issues. 1) Resuming from suspend on i686 on (release candidates of) v3.11 and later triggers issues like: traps: systemd[1] general protection ip:b738e490 sp:bf882fc0 error:0 in libc-2.16.so[b731c000+1b] and traps: rtkit-daemon[552] general protection ip:804d6e5 sp:b6cb32f0 error:0 in rtkit-daemon[8048000+d000] Once I hit the systemd error I can only get out of the mess that the system is at that point by power cycling it. 2) I bisected that issue to commit 9745cdb36da83aeec198650b410ca06304cf792 (select: use freezable blocking call). The, rather impressive, bisect log is pasted at the end of this message. It took 23 builds to pinpoint this issue in the v3.10..v3.11 range! Sadly, I have no clue why that commit triggers this issue. 3) Reverting that commit on top of v3.12-rc7 gets me a system that resumes without issues. (That revert needed one trivial context change. Note that I haven't actually tried v3.12-rc7 plain. But v3.12-rc6 and earlier also had this issue, so I'm sure the revert did the trick for v3.12-rc7.) 4) Should this commit be reverted? Or is there a better fix? Paul Bolle # bad: [6e4664525b1db28f8c4e1130957f70a94c19213e] Linux 3.11 # good: [8bb495e3f02401ee6f76d1b1d77f3ac9f079e376] Linux 3.10 git bisect start 'v3.11' 'v3.10' # bad: [8b70a90cabafb6a6e1a0d3f838b38355fe48337e] Merge branch 'for-v3.11' of git://git.linaro.org/people/mszyprowski/linux-dma-mapping git bisect bad 8b70a90cabafb6a6e1a0d3f838b38355fe48337e # good: [ab3d681e9d41816f90836ea8fe235168d973207f] Merge branch 'core-rcu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip git bisect good ab3d681e9d41816f90836ea8fe235168d973207f # bad: [862f0012549110d6f2586bf54b52ed4540cbff3a] Merge tag 'pci-v3.11-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci git bisect bad 862f0012549110d6f2586bf54b52ed4540cbff3a # good: [60b5adffb4f3e4b4c1978959f24e8e531b2ef3cb] Merge tag 'gpio-for-v3.11-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio git bisect good 60b5adffb4f3e4b4c1978959f24e8e531b2ef3cb # good: [fe489bf4505ae26d3c6d6a1f1d3064c2a9c5cd85] Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm git bisect good fe489bf4505ae26d3c6d6a1f1d3064c2a9c5cd85 # skip: [405a1086bdd091d2d55db0ac905cd6332b35cec1] Merge branch 'pm-cpufreq' git bisect skip 405a1086bdd091d2d55db0ac905cd6332b35cec1 # good: [f4fd3797848aa04e72e942c855fd279840a47fe4] acpi-cpufreq: Add new sysfs attribute freqdomain_cpus git bisect good f4fd3797848aa04e72e942c855fd279840a47fe4 # bad: [2c843bd92ec276ecb68504b3b5ffa7066183f032] Merge branch 'pm-cpufreq' git bisect bad 2c843bd92ec276ecb68504b3b5ffa7066183f032 # skip: [e8b6cb3947430d62538d88f615c007a51aeb23fe] Merge branch 'acpi-doc' git bisect skip e8b6cb3947430d62538d88f615c007a51aeb23fe # good: [1d1ea1b723d9f239f736b8cf284327cbbf9d15d1] ACPICA: Standardize all switch() blocks git bisect good 1d1ea1b723d9f239f736b8cf284327cbbf9d15d1 # skip: [e52cff8bdd4a30c40a7f65c7ea8f1f425f8a15eb] Merge branch 'pm-assorted' git bisect skip e52cff8bdd4a30c40a7f65c7ea8f1f425f8a15eb # good: [39688ce6facd63de796def41a0b9012882b5cc14] PM / devfreq: account suspend/resume for stats git bisect good 39688ce6facd63de796def41a0b9012882b5cc14 # good: [173a5a4c909789fcd57d00355d2237618a3824a4] ACPI / processor: Fix potential NULL pointer dereference in acpi_processor_add() git bisect good 173a5a4c909789fcd57d00355d2237618a3824a4 # skip: [207bc1181b1c03ab6ecb55bca5b307606dd1d6bc] Merge branch 'freezer' git bisect skip 207bc1181b1c03ab6ecb55bca5b307606dd1d6bc # good: [613f5d13b569859171f0896fbc73ee0bfa811fda] freezer: skip waking up tasks with PF_FREEZER_SKIP set git bisect good 613f5d13b569859171f0896fbc73ee0bfa811fda # good: [9b5c7a5a977a330ffaf83c4d383ba247c74c800f] ACPI / PM: Fix possible NULL pointer deref in acpi_pm_device_sleep_state() git bisect good 9b5c7a5a977a330ffaf83c4d383ba247c74c800f # good: [45f0a85c8258741d11bda25c0a5669c06267204a] PM / Runtime: Rework the runtime idle helper routine git bisect good 45f0a85c8258741d11bda25c0a5669c06267204a # bad: [2cc6ced132f472b2bdb619960a650b9a85cdd34f] Merge branch 'pm-cpufreq' git bisect bad 2cc6ced132f472b2bdb619960a650b9a85cdd34f # good: [d24c2a4f919d17bd1ae4f4010a38ab07ece99cf7] PM / QoS: correct the valid range of pm_qos_class git bisect good d24c2a4f919d17bd1ae4f4010a38ab07ece99cf7 # bad: [2b15af6f953012aac49984ead3f8ec744d941540] af_unix: use freezable blocking calls in read git bisect bad 2b15af6f953012aac49984ead3f8ec744d941540 # good: [1c441e921201d523b5a6036aea22b0b426bf1af2] epoll: use freezable blocking call git bisect good 1c441e921201d523b5a6036aea22b0b426bf1af2 # bad: [56467c7697f5aef6974501fbe2c3e63674583549]
Re: Revert 9745cdb36da83aeec198650b410ca06304cf792 (select: use freezable blocking call)?
On 10/29/2013 8:41 PM, Paul Bolle wrote: 0) Summary: ever since I tried running (release candidates of) v3.11 on the two working i686s I still have lying around I ran into issues on resuming from suspend. Reverting 9745cdb36da83aeec198650b410ca06304cf792 (select: use freezable blocking call) resolves those issues. 1) Resuming from suspend on i686 on (release candidates of) v3.11 and later triggers issues like: traps: systemd[1] general protection ip:b738e490 sp:bf882fc0 error:0 in libc-2.16.so[b731c000+1b] and traps: rtkit-daemon[552] general protection ip:804d6e5 sp:b6cb32f0 error:0 in rtkit-daemon[8048000+d000] Once I hit the systemd error I can only get out of the mess that the system is at that point by power cycling it. 2) I bisected that issue to commit 9745cdb36da83aeec198650b410ca06304cf792 (select: use freezable blocking call). The, rather impressive, bisect log is pasted at the end of this message. It took 23 builds to pinpoint this issue in the v3.10..v3.11 range! Sadly, I have no clue why that commit triggers this issue. 3) Reverting that commit on top of v3.12-rc7 gets me a system that resumes without issues. (That revert needed one trivial context change. Note that I haven't actually tried v3.12-rc7 plain. But v3.12-rc6 and earlier also had this issue, so I'm sure the revert did the trick for v3.12-rc7.) 4) Should this commit be reverted? Or is there a better fix? In short, yes, it should. I've already queued up a revert of something very similar and I'm going to revert this one too. Thanks, Rafael -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Revert 9745cdb36da83aeec198650b410ca06304cf792 (select: use freezable blocking call)?
On Tue, 2013-10-29 at 21:58 +0100, Rafael J. Wysocki wrote: On 10/29/2013 8:41 PM, Paul Bolle wrote: 4) Should this commit be reverted? Or is there a better fix? In short, yes, it should. I've already queued up a revert of something very similar and I'm going to revert this one too. If you do, the revert should go into stable for v3.11+ too, shouldn't it? Thanks, Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Revert 9745cdb36da83aeec198650b410ca06304cf792 (select: use freezable blocking call)?
On 10/29/2013 10:15 PM, Paul Bolle wrote: On Tue, 2013-10-29 at 21:58 +0100, Rafael J. Wysocki wrote: On 10/29/2013 8:41 PM, Paul Bolle wrote: 4) Should this commit be reverted? Or is there a better fix? In short, yes, it should. I've already queued up a revert of something very similar and I'm going to revert this one too. If you do, the revert should go into stable for v3.11+ too, shouldn't it? I'll ask stable to pick it up later (or you can do that too). Thanks, Rafael -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Revert 9745cdb36da83aeec198650b410ca06304cf792 (select: use freezable blocking call)?
On Tue, Oct 29, 2013 at 4:58 PM, Rafael J. Wysocki rafael.j.wyso...@intel.com wrote: On 10/29/2013 8:41 PM, Paul Bolle wrote: 0) Summary: ever since I tried running (release candidates of) v3.11 on the two working i686s I still have lying around I ran into issues on resuming from suspend. Reverting 9745cdb36da83aeec198650b410ca06304cf792 (select: use freezable blocking call) resolves those issues. 1) Resuming from suspend on i686 on (release candidates of) v3.11 and later triggers issues like: traps: systemd[1] general protection ip:b738e490 sp:bf882fc0 error:0 in libc-2.16.so[b731c000+1b] and traps: rtkit-daemon[552] general protection ip:804d6e5 sp:b6cb32f0 error:0 in rtkit-daemon[8048000+d000] Once I hit the systemd error I can only get out of the mess that the system is at that point by power cycling it. 2) I bisected that issue to commit 9745cdb36da83aeec198650b410ca06304cf792 (select: use freezable blocking call). The, rather impressive, bisect log is pasted at the end of this message. It took 23 builds to pinpoint this issue in the v3.10..v3.11 range! Sadly, I have no clue why that commit triggers this issue. 3) Reverting that commit on top of v3.12-rc7 gets me a system that resumes without issues. (That revert needed one trivial context change. Note that I haven't actually tried v3.12-rc7 plain. But v3.12-rc6 and earlier also had this issue, so I'm sure the revert did the trick for v3.12-rc7.) 4) Should this commit be reverted? Or is there a better fix? In short, yes, it should. I've already queued up a revert of something very similar and I'm going to revert this one too. To be clear, that's queued for 3.12 which is releasing really soon now. Is that correct? josh -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Revert 9745cdb36da83aeec198650b410ca06304cf792 (select: use freezable blocking call)?
On Tuesday, October 29, 2013 07:39:23 PM Josh Boyer wrote: On Tue, Oct 29, 2013 at 4:58 PM, Rafael J. Wysocki rafael.j.wyso...@intel.com wrote: On 10/29/2013 8:41 PM, Paul Bolle wrote: 0) Summary: ever since I tried running (release candidates of) v3.11 on the two working i686s I still have lying around I ran into issues on resuming from suspend. Reverting 9745cdb36da83aeec198650b410ca06304cf792 (select: use freezable blocking call) resolves those issues. 1) Resuming from suspend on i686 on (release candidates of) v3.11 and later triggers issues like: traps: systemd[1] general protection ip:b738e490 sp:bf882fc0 error:0 in libc-2.16.so[b731c000+1b] and traps: rtkit-daemon[552] general protection ip:804d6e5 sp:b6cb32f0 error:0 in rtkit-daemon[8048000+d000] Once I hit the systemd error I can only get out of the mess that the system is at that point by power cycling it. 2) I bisected that issue to commit 9745cdb36da83aeec198650b410ca06304cf792 (select: use freezable blocking call). The, rather impressive, bisect log is pasted at the end of this message. It took 23 builds to pinpoint this issue in the v3.10..v3.11 range! Sadly, I have no clue why that commit triggers this issue. 3) Reverting that commit on top of v3.12-rc7 gets me a system that resumes without issues. (That revert needed one trivial context change. Note that I haven't actually tried v3.12-rc7 plain. But v3.12-rc6 and earlier also had this issue, so I'm sure the revert did the trick for v3.12-rc7.) 4) Should this commit be reverted? Or is there a better fix? In short, yes, it should. I've already queued up a revert of something very similar and I'm going to revert this one too. To be clear, that's queued for 3.12 which is releasing really soon now. Is that correct? Yes, it is. I'm going to send a pull request with that tomorrow if all goes well. Thanks! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Revert 9745cdb36da83aeec198650b410ca06304cf792 (select: use freezable blocking call)?
On Tue, Oct 29, 2013 at 7:59 PM, Rafael J. Wysocki r...@rjwysocki.net wrote: On Tuesday, October 29, 2013 07:39:23 PM Josh Boyer wrote: On Tue, Oct 29, 2013 at 4:58 PM, Rafael J. Wysocki rafael.j.wyso...@intel.com wrote: On 10/29/2013 8:41 PM, Paul Bolle wrote: 0) Summary: ever since I tried running (release candidates of) v3.11 on the two working i686s I still have lying around I ran into issues on resuming from suspend. Reverting 9745cdb36da83aeec198650b410ca06304cf792 (select: use freezable blocking call) resolves those issues. 1) Resuming from suspend on i686 on (release candidates of) v3.11 and later triggers issues like: traps: systemd[1] general protection ip:b738e490 sp:bf882fc0 error:0 in libc-2.16.so[b731c000+1b] and traps: rtkit-daemon[552] general protection ip:804d6e5 sp:b6cb32f0 error:0 in rtkit-daemon[8048000+d000] Once I hit the systemd error I can only get out of the mess that the system is at that point by power cycling it. 2) I bisected that issue to commit 9745cdb36da83aeec198650b410ca06304cf792 (select: use freezable blocking call). The, rather impressive, bisect log is pasted at the end of this message. It took 23 builds to pinpoint this issue in the v3.10..v3.11 range! Sadly, I have no clue why that commit triggers this issue. 3) Reverting that commit on top of v3.12-rc7 gets me a system that resumes without issues. (That revert needed one trivial context change. Note that I haven't actually tried v3.12-rc7 plain. But v3.12-rc6 and earlier also had this issue, so I'm sure the revert did the trick for v3.12-rc7.) 4) Should this commit be reverted? Or is there a better fix? In short, yes, it should. I've already queued up a revert of something very similar and I'm going to revert this one too. To be clear, that's queued for 3.12 which is releasing really soon now. Is that correct? Yes, it is. I'm going to send a pull request with that tomorrow if all goes well. Excellent. Thanks for confirming. josh -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
