Hi there,
I noticed, that 'acpitool -e' doesn't work any longer sind I upgraded to 3.17.
The tool stalls at
Device S-state Status Sysfs node
---------------------------------------
1. LID S3 *enabled platform:PNP0C0D:00
2. SLPB S3 *enabled platform:PNP0C0E:0
Before there were 11 entries shown.
Can I help investigate it?
Thanks,
Marc
--
Marc Burkhardt
* Marc Burkhardt <[email protected]> [2014-10-09 21:04:06 +0200]:
Just another note: the process uses 100% CPU while 'waiting' for further data it
seems...
strace shows nothing suspicious.
Thanks,
Marc
> Hi there,
> I noticed, that 'acpitool -e' doesn't work any longer sind I upgraded to 3.17.
> The tool stalls at
>
> Device S-state Status Sysfs node
> ---------------------------------------
> 1. LID S3 *enabled platform:PNP0C0D:00
> 2. SLPB S3 *enabled platform:PNP0C0E:0
>
> Before there were 11 entries shown.
>
> Can I help investigate it?
>
> Thanks,
> Marc
>
> --
> Marc Burkhardt
--
Marc Burkhardt
Hi,
On Thu, Oct 9, 2014 at 9:04 PM, Marc Burkhardt <[email protected]> wrote:
> Hi there,
> I noticed, that 'acpitool -e' doesn't work any longer sind I upgraded to 3.17.
> The tool stalls at
>
> Device S-state Status Sysfs node
> ---------------------------------------
> 1. LID S3 *enabled platform:PNP0C0D:00
> 2. SLPB S3 *enabled platform:PNP0C0E:0
I see the same thing.
Frans
On Thu, Oct 9, 2014 at 9:25 PM, Frans Klaver <[email protected]> wrote:
> Hi,
>
> On Thu, Oct 9, 2014 at 9:04 PM, Marc Burkhardt <[email protected]> wrote:
>> Hi there,
>> I noticed, that 'acpitool -e' doesn't work any longer sind I upgraded to 3.17.
>> The tool stalls at
>>
>> Device S-state Status Sysfs node
>> ---------------------------------------
>> 1. LID S3 *enabled platform:PNP0C0D:00
>> 2. SLPB S3 *enabled platform:PNP0C0E:0
>
> I see the same thing.
With which kernel version did it last work properly for you?
I upgraded from 3.10 on that machine. 3.12 didn't work for me due to a hibernation bug. The rest was left out... :/
Thanks,
Marc
Am 9. Oktober 2014 21:31:52 MESZ, schrieb Frans Klaver <[email protected]>:
>On Thu, Oct 9, 2014 at 9:25 PM, Frans Klaver <[email protected]>
>wrote:
>> Hi,
>>
>> On Thu, Oct 9, 2014 at 9:04 PM, Marc Burkhardt <[email protected]>
>wrote:
>>> Hi there,
>>> I noticed, that 'acpitool -e' doesn't work any longer sind I
>upgraded to 3.17.
>>> The tool stalls at
>>>
>>> Device S-state Status Sysfs node
>>> ---------------------------------------
>>> 1. LID S3 *enabled platform:PNP0C0D:00
>>> 2. SLPB S3 *enabled platform:PNP0C0E:0
>>
>> I see the same thing.
>
>With which kernel version did it last work properly for you?
Hi,
Please put your replies below the relevant quote.
On Thu, Oct 9, 2014 at 9:42 PM, Marc Burkhardt <[email protected]> wrote:
> I upgraded from 3.10 on that machine. 3.12 didn't work for me due to a hibernation bug. The rest was left out... :/
If you still have the 3.12 kernel around, could you test if acpitool
-e worked there?
>On Thu, Oct 9, 2014 at 9:42 PM, Marc Burkhardt <[email protected]>
>wrote:
>> I upgraded from 3.10 on that machine. 3.12 didn't work for me due to
>a hibernation bug. The rest was left out... :/
>
>If you still have the 3.12 kernel around, could you test if acpitool
>-e worked there?
Let me ask you a question: does it make sense to test 3.12 again because you know there's something changed regarding /proc/acpi/... or because it's the kernel I broke up on upgrading?
I could compile one, sure. But I have no time to actually 'bisect' this... unfortunately.
Thanks for your support,
Marc
On Thu, Oct 9, 2014 at 9:58 PM, Marc Burkhardt <[email protected]> wrote:
>
>
>>On Thu, Oct 9, 2014 at 9:42 PM, Marc Burkhardt <[email protected]>
>>wrote:
>>> I upgraded from 3.10 on that machine. 3.12 didn't work for me due to
>>a hibernation bug. The rest was left out... :/
>>
>>If you still have the 3.12 kernel around, could you test if acpitool
>>-e worked there?
>
> Let me ask you a question: does it make sense to test 3.12 again because you know there's something changed regarding /proc/acpi/... or because it's the kernel I broke up on upgrading?
Never mind. It broke after 3.14. I'll bisect.
Frans
On Thu, 9 Oct 2014 22:16:11 +0200
Frans Klaver <[email protected]> wrote:
> On Thu, Oct 9, 2014 at 9:58 PM, Marc Burkhardt <[email protected]> wrote:
> >
> >
> >>On Thu, Oct 9, 2014 at 9:42 PM, Marc Burkhardt <[email protected]>
> >>wrote:
> >>> I upgraded from 3.10 on that machine. 3.12 didn't work for me due to
> >>a hibernation bug. The rest was left out... :/
> >>
> >>If you still have the 3.12 kernel around, could you test if acpitool
> >>-e worked there?
> >
> > Let me ask you a question: does it make sense to test 3.12 again because you know there's something changed regarding /proc/acpi/... or because it's the kernel I broke up on upgrading?
>
> Never mind. It broke after 3.14. I'll bisect.
>
The below patch fixes it for me. Looks like the line sizes changed
and some are now exactly the right length to make it loop forever
reading /proc/acpi/wakeup:
--- a/src/acpitool.cpp
+++ b/src/acpitool.cpp
@@ -417,7 +417,7 @@ int Do_Fan_Info(int verbose)
int Show_WakeUp_Devices(int verbose)
{
ifstream file_in;
- char *filename, str[40];
+ char *filename, str[80];
filename = "/proc/acpi/wakeup";
@@ -438,13 +438,13 @@ int Show_WakeUp_Devices(int verbose)
}
else
{
- file_in.getline(str, 40); // first line are just headers //
+ file_in.getline(str, 80); // first line are just headers //
cout<<" "<<str<<endl;
cout<<" ---------------------------------------"<<endl;
int t = 1;
while(!file_in.eof())
{
- file_in.getline(str, 40);
+ file_in.getline(str, 80);
if (strlen(str)!=0) // avoid printing last empty line //
{
cout<<" "<<t<<". "<<str<<endl;
On Thu, Oct 9, 2014 at 10:27 PM, Chuck Ebbert <[email protected]> wrote:
> On Thu, 9 Oct 2014 22:16:11 +0200
> Frans Klaver <[email protected]> wrote:
>
>> On Thu, Oct 9, 2014 at 9:58 PM, Marc Burkhardt <[email protected]> wrote:
>> >
>> >
>> >>On Thu, Oct 9, 2014 at 9:42 PM, Marc Burkhardt <[email protected]>
>> >>wrote:
>> >>> I upgraded from 3.10 on that machine. 3.12 didn't work for me due to
>> >>a hibernation bug. The rest was left out... :/
>> >>
>> >>If you still have the 3.12 kernel around, could you test if acpitool
>> >>-e worked there?
>> >
>> > Let me ask you a question: does it make sense to test 3.12 again because you know there's something changed regarding /proc/acpi/... or because it's the kernel I broke up on upgrading?
>>
>> Never mind. It broke after 3.14. I'll bisect.
>>
>
> The below patch fixes it for me. Looks like the line sizes changed
> and some are now exactly the right length to make it loop forever
> reading /proc/acpi/wakeup:
>
>
> --- a/src/acpitool.cpp
> +++ b/src/acpitool.cpp
> @@ -417,7 +417,7 @@ int Do_Fan_Info(int verbose)
> int Show_WakeUp_Devices(int verbose)
> {
> ifstream file_in;
> - char *filename, str[40];
> + char *filename, str[80];
>
> filename = "/proc/acpi/wakeup";
>
> @@ -438,13 +438,13 @@ int Show_WakeUp_Devices(int verbose)
> }
> else
> {
> - file_in.getline(str, 40); // first line are just headers //
> + file_in.getline(str, 80); // first line are just headers //
> cout<<" "<<str<<endl;
> cout<<" ---------------------------------------"<<endl;
> int t = 1;
> while(!file_in.eof())
> {
> - file_in.getline(str, 40);
> + file_in.getline(str, 80);
> if (strlen(str)!=0) // avoid printing last empty line //
> {
> cout<<" "<<t<<". "<<str<<endl;
Oh my. Why not use the std::string version of getline?
I doubt we should count this as "breaking userspace"..