[laptop-mode] Wrong hdparm setting applied after resume

[Bart Samwel]

Hi Joss,

Joss Winn wrote:
> On Sat, Jul 12, 2008 at 10:16 PM, Bart Samwel <bart at samwel.tk> wrote:
[...]
>> In debian bug #473055 you find this file:
>>
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=70;filename=66LTM;att=1;bug=473055
>>
>> If you put that in /etc/pm/sleep.d under the name "66LTM" (and make it
>> executable, I think!), it may work for you.
>>
> 
> 
> Hi Bart,
> 
> Yes, that's fixed it. Thank you.

Great! That means I can safely submit it to the pm-utils maintainers. :-)

> I've a few other related comments...
> 
> 1). I've noticed that the default BATT_HD_POWERMGMT=180 in
> laptop-mode.conf produces:
> 
> Advanced power management level: 128
> 
> when hdparm -I /dev/sda is run.
> 
> If I change 180 to 254, then that command returns 254.  Do you know
> why the number 180 in the config file returns 128?

The effect of the hdparm -B command is defined by the hardware. It seems
like laptop-mode-tools does in fact write hdparm -B 180, but then the
hardware rounds that down to 128. That basically tells you that it
handles 180 the same as 128. Try 200 for a change -- my educated guess
would be that that will return 192 from hdparm -I.

>> In Ubuntu and Debian, there are also some cases in which the
>> acpi-support package handles suspend (for instance when you suspend
>> using a laptop's suspend button while not logged in to Gnome or KDE --
>> but the exact set of cases is a bit diffuse). In Debian, acpi-support
>> restarts laptop mode when resuming from suspend. I'm not sure about
>> Ubuntu though. If it so happens that you turn out to use acpi-support
>> for suspend, you may want to add a script to /etc/acpi/resume.d which
>> restarts the laptop-mode service (through the command "invoke-rc.d
>> laptop-mode-tools restart").
>>
> 
> The default for Ubuntu in /etc/default/acpi-support is ENABLE_LAPTOP_MODE=false
> 
> Changing that to 'true', seems to work for me without the additional
> script you mention above.

That's probably true. The option makes the acpi-support try to control
laptop mode, in a bad way which only sort-of works if you have the
Ubuntu version of laptop-mode-tools. One of the side effects is that it
tries to start or stop laptop mode when resuming, which MIGHT have the
desired effect.

> 2). The other thing I've done because it was mentioned here:
> https://wiki.ubuntu.com/PowerManagement
> 
> is to remove /usr/lib/pm-utils/power.d/laptop-tools. I don't know if
> that workaround still applies if using laptop-mode on Ubuntu. Your
> name is at the top of that file, so I guess you can tell me what I
> should do with it! :-)

Throw it out. This is the first I've heard of it, it's not my file,
they've taken some fragments of my package, incorrectly referenced the
package (laptop-tools which should have been laptop-mode-tools), forgot
to also add the error handling, and forgot to add a very crucial part
(remounting file systems). They should have asked me if this was the
right way to do it, and I'd have said NO. There's a good reason why
laptop-mode-tools is a pretty complex package. I'm very happy to find
that the Debian version of the package doesn't contain this file. :-)

> 3). I'm still finding that my HDD is spinning down way too frequently.
> smartmontools/smart-notifer still reports errors such as: 'Device:
> /dev/sda, ATA error count increased from 483 to 485'

Interestingly, that may mean anything. Most importantly, that line
doesn't mean that the drive spun up or down, it means that some *other*
I/O error occurred. Could you check your syslog for lines like:

"kernel: sda: dma_intr: status=0x51 { DriveReady SeekComplete Error }"

and surrounding lines? Those might give a hint at what's going on here.

> I get these often. The laptop is two weeks old.

Depending on the type of errors you may have a totally different problem
then! If your drive is dying already, you want to know about it...

> 4). I'm also finding that when I unplug AC power, the laptop freezes
> for 2-3 seconds and the CPU spikes. I can't find which process is
> doing this.
> 
> But syslog is showing:
> 
> Jul 13 11:09:56 joss-laptop kernel: [   32.610455] CPU0 attaching NULL
> sched-domain.
> Jul 13 11:09:56 joss-laptop kernel: [   32.610466] CPU1 attaching NULL
> sched-domain.
> Jul 13 11:09:56 joss-laptop kernel: [   32.636497] CPU0 attaching sched-domain:
> Jul 13 11:09:56 joss-laptop kernel: [   32.636506]  domain 0: span 03
> Jul 13 11:09:56 joss-laptop kernel: [   32.636510]   groups: 01 02
> Jul 13 11:09:56 joss-laptop kernel: [   32.636517] CPU1 attaching sched-domain:
> Jul 13 11:09:56 joss-laptop kernel: [   32.636521]  domain 0: span 03
> Jul 13 11:09:56 joss-laptop kernel: [   32.636524]   groups: 02 01
> Jul 13 11:09:58 joss-laptop anacron[13247]: Anacron 2.3 started on 2008-07-13
> Jul 13 11:09:58 joss-laptop anacron[13247]: Will run job `cron.daily' in 5 min.
> Jul 13 11:09:58 joss-laptop anacron[13247]: Jobs will be executed sequentially
> 
> the anacron script is not the cause of the freeze as it still freezes
> when this script is removed.
> 
> I don't suppose this is related to laptop-mode-tools but I thought I'd
> mention it as someone might have an idea.

Well, it might be related to something laptop-mode-tools is doing at
that point. Let's check it out. Could you try the following:

1. Set VERBOSE_OUTPUT=1 in laptop-mode.conf.

2. STOP the acpid service (so that laptop mode tools doesn't get kicked
automatically when the AC adapter is unplugged)

3. Unplug the AC adapter

4. Run (as root): /usr/sbin/laptop_mode auto

If you see a pause in the output of two seconds, try and remember the
last couple of lines in the output before the pause. That's the
interesting bit. Send me the entire output of the command, and mark
where the pause was. If there was no pause, then it's not laptop-mode-tools.

Cheers,
Bart