2:41 a.m.
F27. I ran a new laptop battery down to 4% (as claimed by gnome) and my
laptop didn't auto-suspend, nor hibernate.
In settings / power, the only option for battery power these days seems to
be to automatically suspend after a set time period; not at a certain
battery level.
So
a) did I imagine it that earlier fedoras used to have this feature?
b) any way I can enable auto-suspect on low battery for F27?
--
print+qq&$}$"$/$s$,$a$d$g$s$@$.$q$,$:$.$q$^$,$@$a$~$;$.$q$m&if+map{m,^\d{0\,},,${$::{$'}}=chr($"+=$&||1)}q&10m22,42}6:17a2~2.3@3;^2dg3q/s"&=~m*\d\*.*g
2:54 a.m.
On 04/16/2018 12:41 AM, Dave Mitchell wrote:
F27. I ran a new laptop battery down to 4% (as claimed by gnome) and
my
laptop didn't auto-suspend, nor hibernate.
I was very surprised a few days ago when I left my laptop unplugged and
came back to find it powered off. I was expecting that it had just died
and I would have to restart everything again. But when I turned it on,
everything was there. I wasn't paying attention since I was expecting
to have to wait for it to boot, so I don't know if it hibernated or
suspended.
a) did I imagine it that earlier fedoras used to have this feature?
It used to. I searched in dconf and found a setting for that, but it is
labelled as "no schema found".
b) any way I can enable auto-suspect on low battery for F27?
Somehow it suddenly started working for me, but I have no idea what
triggered it.
3:03 a.m.
On 16/04/18 08:41, Dave Mitchell wrote:
F27. I ran a new laptop battery down to 4% (as claimed by gnome) and
my
laptop didn't auto-suspend, nor hibernate.
In settings / power, the only option for battery power these days seems to
be to automatically suspend after a set time period; not at a certain
battery level.
So
a) did I imagine it that earlier fedoras used to have this feature?
b) any way I can enable auto-suspect on low battery for F27?
Take a look at an earlier question I asked, 'Power settings wrong or
battery dying', particularly the answers from Robbi Nespu.
Might help you
6:55 a.m.
On Mon, 16 Apr 2018 08:41:56 +0100
Dave Mitchell <davem(a)iabyn.com> wrote:
F27. I ran a new laptop battery down to 4% (as claimed by gnome) and
my
laptop didn't auto-suspend, nor hibernate.
I'm not that familiar with power settings on Fedora (having F26 here).
But a look at upower.service might be useful - mine is disabled:
% systemctl status upower.service
● upower.service - Daemon for power management
Loaded: loaded (/usr/lib/systemd/system/upower.service; disabled; vendor pres
Active: active (running) since Tue 2018-04-17 03:11:58 CEST; 10h ago
Docs: man:upowerd(8)
Main PID: 2562 (upowerd)
Tasks: 3 (limit: 4915)
CGroup: /system.slice/upower.service
└─2562 /usr/libexec/upowerd
In settings / power, the only option for battery power these days seems to
be to automatically suspend after a set time period; not at a certain
battery level.
'Suspend' doesn't seem to be supported as an action for low battery
level on Gnome ...
But here, on F26: in
/etc/UPower/UPower.conf
I have a config option to set action (again: no suspend) according to
a battery percentage level. Excerpt:
----------------------------------------
UsePercentageForPolicy=true
# When UsePercentageForPolicy is true, the levels at which UPower will
# consider the battery low, critical, or take action for the critical
# battery level.
#
# This will also be used for batteries which don't have time information
# such as that of peripherals.
#
# If any value is invalid, or not in descending order, the defaults
# will be used.
#
# Defaults:
# PercentageLow=10
# PercentageCritical=3
# PercentageAction=2
PercentageLow=10
PercentageCritical=3
PercentageAction=2
----------------------------------------
Trying 'upower -d' here results in the display of current power
settings ...
HTH,
Wolfgang
12:53 p.m.
On 04/17/2018 04:55 AM, Wolfgang Pfeiffer wrote:
Trying 'upower -d' here results in the display of current
power
settings ...
So that's why mine works. The output includes this line:
critical-action: HybridSleep
I do wonder what starts it up. The service is disabled although the
default is enabled and I didn't manually start it.
3:26 p.m.
On Tue, 17 Apr 2018 10:53:09 -0700
Samuel Sieb <samuel(a)sieb.net> wrote:
On 04/17/2018 04:55 AM, Wolfgang Pfeiffer wrote:
> Trying 'upower -d' here results in the display of current power
> settings ...
So that's why mine works. The output includes this line:
critical-action: HybridSleep
I do wonder what starts it up. The service is disabled although the
default is enabled and I didn't manually start it.
I'm getting curious about your settings, if that's not too intrusive:
mine are, with comments removed:
----------------------------------------------------->
% grep -v '^#' /etc/UPower/UPower.conf
[UPower]
EnableWattsUpPro=false
NoPollBatteries=false
IgnoreLid=false
UsePercentageForPolicy=true
PercentageLow=10
PercentageCritical=3
PercentageAction=2
TimeLow=1200
TimeCritical=300
TimeAction=120
CriticalPowerAction=HybridSleep
<------------------------------------------
IIRC when the battery was 0 a few days ago, the battery LED (here: the
Power On/Off button) started blinking fast, but no sleep was started.
Weird ...
The documentation for upower seems technichally to be missing on F26 -
so I have to guess whether Time{Low,Critical,Action} values actually
mean minutes or seconds ...
Archlinux has some documentation:
https://wiki.archlinux.org/index.php/Power_management#Hybrid_sleep
And that looks really interesting:
https://www.kernel.org/doc/Documentation/admin-guide/pm/sleep-states.rst
This latter page - after a glance on it - seems to suggest that sleep
modes are organized by the kernel, via three files. Here, they look
like so:
--------------->
% cat /sys/power/mem_sleep
s2idle [deep]
% cat /sys/power/state
freeze mem disk
% cat /sys/power/disk
[platform] shutdown reboot suspend test_resume
<--------------
HTH,
Wolfgang
3:47 p.m.
On Tue, 17 Apr 2018 22:26:22 +0200
Wolfgang Pfeiffer <roto(a)gmx.net> wrote:
And that looks really interesting:
https://www.kernel.org/doc/Documentation/admin-guide/pm/sleep-states.rst
Forgot that one:
https://www.kernel.org/doc/Documentation/power/swsusp.txt
Sorry,
Wolfgang
4:38 p.m.
On Tue, Apr 17, 2018 at 10:26:22PM +0200, Wolfgang Pfeiffer wrote:
On Tue, 17 Apr 2018 10:53:09 -0700
Samuel Sieb <samuel(a)sieb.net> wrote:
> On 04/17/2018 04:55 AM, Wolfgang Pfeiffer wrote:
> > Trying 'upower -d' here results in the display of current power
> > settings ...
>
> So that's why mine works. The output includes this line:
> critical-action: HybridSleep
>
> I do wonder what starts it up. The service is disabled although the
> default is enabled and I didn't manually start it.
I'm getting curious about your settings, if that's not too intrusive:
mine are, with comments removed:
----------------------------------------------------->
% grep -v '^#' /etc/UPower/UPower.conf
[UPower]
EnableWattsUpPro=false
NoPollBatteries=false
IgnoreLid=false
UsePercentageForPolicy=true
PercentageLow=10
PercentageCritical=3
PercentageAction=2
OP here - my UPower settings are the same as yours, and when I found time
to risk my battery getting down to 2% (I only tried to 4% originally), it
did indeed hibernate. Although it then immediately resumed :-(
So I guess I now have a different issue. BIOS maybe?
--
If life gives you lemons, you'll probably develop a citric acid allergy.
1:12 p.m.
On Mon, May 28, 2018 at 10:38:58PM +0100, Dave Mitchell wrote:
On Tue, Apr 17, 2018 at 10:26:22PM +0200, Wolfgang Pfeiffer wrote:
> I'm getting curious about your settings, if that's not too intrusive:
> mine are, with comments removed:
>
> ----------------------------------------------------->
> % grep -v '^#' /etc/UPower/UPower.conf
>
> [UPower]
>
> EnableWattsUpPro=false
>
> NoPollBatteries=false
>
> IgnoreLid=false
>
> UsePercentageForPolicy=true
>
> PercentageLow=10
> PercentageCritical=3
> PercentageAction=2
OP here - my UPower settings are the same as yours, and when I found time
to risk my battery getting down to 2% (I only tried to 4% originally), it
did indeed hibernate. Although it then immediately resumed :-(
Resumed meaning it really "woke up", without your intervention like
pressing a key or so? If yes I'd check the journalctl logs, because
that seems a little strange to me.
I had a similar situation a few days ago: I ran down battery until
very low down. When the battery level was in what the system probably
saw as critical (45%, something like that), it started
sleep-hibernating (whatever the mix of these modes means), with
journalctl writing (excerpt):
Starting Hybrid Suspend+Hibernate...
and seconds later:
PM: Hibernation image created
and only woke up after I pressed the power button, IIRC.
So I guess I now have a different issue. BIOS maybe?
No idea: syslogs/journalctl might tell you what was going on:
The logs here are interesting anyways, and I'm still wondering where
the system actually saved the image: in /tmp, or swap partition? ...
HTH
Wolfgang
7:45 p.m.
Allegedly, on or about 29 May 2018, Wolfgang Pfeiffer sent:
The logs here are interesting anyways, and I'm still wondering
where
the system actually saved the image: in /tmp, or swap partition?
The usual method of hibernating is to dump the memory into the swap
partition. I do not know what will happen if your swap partition is
smaller than your RAM, though.
--
[tim@localhost ~]$ uname -rsvp
Linux 4.16.7-100.fc26.x86_64 #1 SMP Wed May 2 21:45:56 UTC 2018 x86_64
Boilerplate: All mail to my mailbox is automatically deleted.
There is no point trying to privately email me, I only get to see
the messages posted to the mailing list.
If you don't understand how e-mail threading works, then follow the
instructions given by those who do, and don't argue with them.
4:21 p.m.
On Wed, May 30, 2018 at 10:15:51AM +0930, Tim via users wrote:
Allegedly, on or about 29 May 2018, Wolfgang Pfeiffer sent:
> The logs here are interesting anyways, and I'm still wondering where
> the system actually saved the image: in /tmp, or swap partition?
The usual method of hibernating is to dump the memory into the swap
partition. I do not know what will happen if your swap partition is
smaller than your RAM, though.
Thanks for letting me know.
32 GB of RAM here, swap space is just ~16 GB: my guess is that as long
as the totally used memory (including buffers/cache) isn't bigger than
the swap partition, some hibernation image might be written
successfully ... not being sure, tho' ...
And swap space is rarely used here, IIRC ..
Wolfgang
5:13 p.m.
Allegedly, on or about 31 May 2018, sent:
> The usual method of hibernating is to dump the memory into the
swap
> partition. I do not know what will happen if your swap partition
> is smaller than your RAM, though.
Wolfgang Pfeiffer:
32 GB of RAM here, swap space is just ~16 GB: my guess is that as
long as the totally used memory (including buffers/cache) isn't
bigger than the swap partition, some hibernation image might be
written successfully ... not being sure, tho' ...
I believe it can also use a swap file, so you can add one to a
partition with space. However, when there's more than one swap, I
think you need to set a kernel parameter for the system to look in the
right place for its resuming data.
And swap space is rarely used here, IIRC ..
Generally speaking, the same here. But when I had a system with less
RAM, web browsers were terrible at wasting RAM. If you had enough tabs
open, or hit a badly coded website, the system would start paging and
never recover unless I managed to kill the web browser. Often I
couldn't, because the system was so unresponsive you couldn't use the
mouse or keyboard.
--
[tim@localhost ~]$ uname -rsvp
Linux 4.16.7-100.fc26.x86_64 #1 SMP Wed May 2 21:45:56 UTC 2018 x86_64
Boilerplate: All mail to my mailbox is automatically deleted.
There is no point trying to privately email me, I only get to see
the messages posted to the mailing list.
Programmers who can't take criticisms shouldn't release software that's
so crap it seriously pisses people off.
8:14 p.m.
OK so I've run into this also on Fedora 28. (This is with the "sick"
battery that Windows says is OK, and HP's battery checker says is OK.
And yet at 18% battery and 45 minutes remaining it goes into
"hibernation").
So what Fedora is doing is hybrid sleep.
Jun 02 15:11:33 f28h.local systemd[1]: Starting Hybrid Suspend+Hibernate...
It is really super easy to be less than precise with language when it
comes to power management, it's really complicated mostly because the
various strategies keep changing by hardware manufacturers and
Microsoft. So pretty much just accept that the only people who really
grok this are the very serious amateurs, and devs whose expertise this
is. And I'm neither, so you can take this with a grain of salt.
My understanding of hybrid sleep, is that the kernel will freeze the
memory state, write that image to the drive, and then go to
suspend-to-RAM (S3) mode. That way if you add power, you can
immediately wake up and the written hibernation image can just be
ignored. But if you don't add power, and the battery goes below a
certain point that suspend collapses into poweroff, the system state
is in the hibernation image.
The gotcha, at least for my system, is this should not happen because
it's UEFI with Secure Boot enabled. I asked the kernel team fairly
recently (about a year) and hibernation is not supported. A
non-encrypted hibernation image is an injection point to side step the
protection offered by Secure Boot. SUSE has a patch to do this, but we
aren't using it, and mainline hasn't accepted any of that including a
bunch of other Secure Boot related stuff - last I checked.
So... bugger.
And I'm experiencing the same effect where it immediately wakes up
after it suspends following the writing of the hibernation image. But
a non-hybrid suspend to RAM with laptop lid, or pressing power button
quickly, or holding alt while clicking on the GNOME upper right hand
menu power button (which with alt key has a pause symbol instead), all
of those work.
As for what checks logind does to know whether it can hibernate, it
looks like RAM must not be more than 98% of swap. DE's that use
Hibernate() bus call when RAM is bigger than free swap (that is, swap
could be used for swap and for hibernation image, but typically you
hope swap is little used or not used at all; but if a lot is used it
can mean Hibernate() fails because there isn't enough room for swap
and the hibernate image to be written in the available swap space and
that's why to really support hibernation, we need these rather
substantially larger swap partitions than we have now, just in case
swap is used for swap - haha, get it?) Anyway, if the DE calls
Hibernate() and it fails due to lack of space, it's up to the DE to
decide what to fallback on. And I haven't tested any of that. So I
don't know what happens.
There is also CanHibernate() which just does a check, rather than an attempt.
https://lists.freedesktop.org/archives/systemd-devel/2016-April/036330.html
Anyway, there's a bug here I think. The unprompted write from suspend
following the writing of the hibernation image is one bug. And the
very fact the system is trying to hibernate sounds like another unless
we now support hibernation - which quite frankly would surprise me a
lot.
Chris Murphy
10:22 p.m.
Huh. So when hybrid suspend+hibernate happened, I had a randomly
encrypted swap setup. So this obviously can't ever be recovered from,
because the key is lost. Well, actually the key is in the image on
encrypted swap. So the only copy of the key is encrypted. Ha.
Anyway, after setting up an ordinary plain partition swap, updating
fstab, and adding resume=UUID= boot param; plain hibernate with 'sudo
systemctl hibernate' enters and exits hibernation normally even
though Secure Boot is enabled. So something has changed. I've asked on
the kernel list.
I haven't tested hybrid sleep again yet, so I'm still not sure what
that immediate wake up is all about. Anyone looking to get more info
about this should add the 'no_console_suspend' boot param. It might
help give an idea what's going on, but there's also some chance this
ends up relating to ACPI (a very deep dark rabbit hole).
---
Chris Murphy
2:44 a.m.
On Tue, May 29, 2018 at 08:12:39PM +0200, Wolfgang Pfeiffer wrote:
On Mon, May 28, 2018 at 10:38:58PM +0100, Dave Mitchell wrote:
> On Tue, Apr 17, 2018 at 10:26:22PM +0200, Wolfgang Pfeiffer wrote:
> OP here - my UPower settings are the same as yours, and when I found time
> to risk my battery getting down to 2% (I only tried to 4% originally), it
> did indeed hibernate. Although it then immediately resumed :-(
Resumed meaning it really "woke up", without your intervention like
pressing a key or so? If yes I'd check the journalctl logs, because
that seems a little strange to me.
Yep. I get a 'critical alert' notification on the screen at 2%, then
the screen goes dark, followed by several seconds of disk activity light
flashing, then the screen turns on again, and I'm back where I was.
All without user intervention.
I had a similar situation a few days ago: I ran down battery until
very low down. When the battery level was in what the system probably
saw as critical (45%, something like that), it started
sleep-hibernating (whatever the mix of these modes means), with
journalctl writing (excerpt):
Starting Hybrid Suspend+Hibernate...
and seconds later:
PM: Hibernation image created
Here's a stripped-down log:
May 28 22:23:16 robin systemd[1]: Starting Hybrid Suspend+Hibernate...
May 28 22:23:16 robin systemd-sleep[18493]: Suspending system...
May 28 22:23:16 robin kernel: PM: hibernation entry
May 28 22:23:16 robin kernel: PM: Syncing filesystems ...
May 28 22:23:16 robin kernel: PM: done.
May 28 22:23:30 robin kernel: Freezing user space processes ... (elapsed 0.003 seconds)
done.
May 28 22:23:30 robin kernel: OOM killer disabled.
May 28 22:23:30 robin kernel: PM: Marking nosave pages: [mem 0x00000000-0x00000fff]
[...25 similar lines...]
May 28 22:23:31 robin kernel: PM: Preallocating image memory... done (allocated 627744
pages)
May 28 22:23:31 robin kernel: PM: Allocated 2510976 kbytes in 2.26 seconds (1111.05 MB/s)
May 28 22:23:31 robin kernel: Freezing remaining freezable tasks ... (elapsed 0.001
seconds) done.
May 28 22:23:31 robin kernel: Suspending console(s) (use no_console_suspend to debug)
May 28 22:23:31 robin kernel: ACPI: EC: interrupt blocked
May 28 22:23:31 robin kernel: Disabling non-boot CPUs ...
May 28 22:23:31 robin kernel: smpboot: CPU 1 is now offline
May 28 22:23:31 robin kernel: smpboot: CPU 2 is now offline
May 28 22:23:31 robin kernel: smpboot: CPU 3 is now offline
May 28 22:23:31 robin kernel: smpboot: CPU 4 is now offline
May 28 22:23:31 robin kernel: smpboot: CPU 5 is now offline
May 28 22:23:31 robin kernel: smpboot: CPU 6 is now offline
May 28 22:23:31 robin kernel: smpboot: CPU 7 is now offline
May 28 22:23:31 robin kernel: PM: Creating hibernation image:
May 28 22:23:31 robin kernel: PM: Need to copy 623696 pages
May 28 22:23:31 robin kernel: PM: Normal pages needed: 623696 + 1024, available pages:
1443975
May 28 22:23:31 robin kernel: PM: Hibernation image created (623696 pages copied)
May 28 22:23:31 robin kernel: Enabling non-boot CPUs ...
May 28 22:23:31 robin kernel: x86: Booting SMP configuration:
May 28 22:23:31 robin kernel: smpboot: Booting Node 0 Processor 1 APIC 0x2
May 28 22:23:31 robin kernel: cache: parent cpu1 should not be sleeping
May 28 22:23:31 robin kernel: CPU1 is up
[...]
May 28 22:23:31 robin kernel: smpboot: Booting Node 0 Processor 7 APIC 0x7
May 28 22:23:31 robin kernel: cache: parent cpu7 should not be sleeping
May 28 22:23:31 robin kernel: CPU7 is up
May 28 22:23:31 robin kernel: ACPI: EC: interrupt unblocked
May 28 22:23:31 robin kernel: ath: phy0: ASPM enabled: 0x42
May 28 22:23:31 robin kernel: ACPI: button: The lid device is not compliant to SW_LID.
May 28 22:23:31 robin kernel: ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[... more ata... and image saving progress lines ...]
May 28 22:23:31 robin kernel: PM: Image saving done
May 28 22:23:31 robin kernel: PM: Wrote 2499660 kbytes in 4.12 seconds (606.71 MB/s)
May 28 22:23:31 robin kernel: PM: S|
May 28 22:23:31 robin kernel: Suspending console(s) (use no_console_suspend to debug)
May 28 22:23:31 robin kernel: sd 0:0:0:0: [sda] Synchronizing SCSI cache
May 28 22:23:31 robin kernel: sd 0:0:0:0: [sda] Stopping disk
May 28 22:23:31 robin kernel: PM: suspend devices took 0.679 seconds
May 28 22:23:31 robin kernel: ACPI: EC: interrupt blocked
May 28 22:23:31 robin kernel: ACPI: Preparing to enter system sleep state S3
May 28 22:23:31 robin kernel: ACPI: EC: event blocked
May 28 22:23:31 robin kernel: ACPI: EC: EC stopped
May 28 22:23:31 robin kernel: PM: Saving platform NVS memory
May 28 22:23:31 robin kernel: Disabling non-boot CPUs ...
May 28 22:23:31 robin kernel: smpboot: CPU 1 is now offline
May 28 22:23:31 robin kernel: smpboot: CPU 2 is now offline
May 28 22:23:31 robin kernel: smpboot: CPU 3 is now offline
May 28 22:23:31 robin kernel: smpboot: CPU 4 is now offline
May 28 22:23:31 robin kernel: smpboot: CPU 5 is now offline
May 28 22:23:31 robin kernel: smpboot: CPU 6 is now offline
May 28 22:23:31 robin kernel: smpboot: CPU 7 is now offline
May 28 22:23:31 robin kernel: ACPI: Low-level resume complete
May 28 22:23:31 robin kernel: ACPI: EC: EC started
May 28 22:23:31 robin kernel: PM: Restoring platform NVS memory
May 28 22:23:31 robin kernel: Enabling non-boot CPUs ...
May 28 22:23:31 robin kernel: x86: Booting SMP configuration:
May 28 22:23:31 robin kernel: smpboot: Booting Node 0 Processor 1 APIC 0x2
May 28 22:23:31 robin kernel: cache: parent cpu1 should not be sleeping
May 28 22:23:31 robin kernel: CPU1 is up
NB - this laptop does a normal suspend/resume quite happily when closing
/opening lid.
--
That he said that that that that is is is debatable, is debatable.
3:46 p.m.
On Wed, May 30, 2018 at 08:44:36AM +0100, Dave Mitchell wrote:
On Tue, May 29, 2018 at 08:12:39PM +0200, Wolfgang Pfeiffer wrote:
>
> On Mon, May 28, 2018 at 10:38:58PM +0100, Dave Mitchell wrote:
> > On Tue, Apr 17, 2018 at 10:26:22PM +0200, Wolfgang Pfeiffer wrote:
> > OP here - my UPower settings are the same as yours, and when I found time
> > to risk my battery getting down to 2% (I only tried to 4% originally), it
> > did indeed hibernate. Although it then immediately resumed :-(
>
> Resumed meaning it really "woke up", without your intervention like
> pressing a key or so? If yes I'd check the journalctl logs, because
> that seems a little strange to me.
Yep. I get a 'critical alert' notification on the screen at 2%, then
the screen goes dark, followed by several seconds of disk activity light
flashing, then the screen turns on again, and I'm back where I was.
All without user intervention.
> I had a similar situation a few days ago: I ran down battery until
> very low down. When the battery level was in what the system probably
> saw as critical (45%, something like that), it started
> sleep-hibernating (whatever the mix of these modes means), with
> journalctl writing (excerpt):
>
> Starting Hybrid Suspend+Hibernate...
>
> and seconds later:
> PM: Hibernation image created
Here's a stripped-down log:
[ ... ]
May 28 22:23:31 robin kernel: ACPI: Low-level resume complete
May 28 22:23:31 robin kernel: ACPI: EC: EC started
May 28 22:23:31 robin kernel: PM: Restoring platform NVS memory
May 28 22:23:31 robin kernel: Enabling non-boot CPUs ...
May 28 22:23:31 robin kernel: x86: Booting SMP configuration:
May 28 22:23:31 robin kernel: smpboot: Booting Node 0 Processor 1 APIC 0x2
May 28 22:23:31 robin kernel: cache: parent cpu1 should not be sleeping
May 28 22:23:31 robin kernel: CPU1 is up
From these logs I cannot see why this did not work ..
NB - this laptop does a normal suspend/resume quite happily when
closing
/opening lid.
Same here: the only time this machine refuses to sleep (S3 sleep,
different from the emergency hibernation from above, it seems) is when
an external monitor is connected to the computer, via HDMI cable. You
sure that there was nothing similar on your machine that might have
prevented the emergency hibernate, by resuming immediately again?
HTH
Wolfgang
2147
days inactive
2195
days old
15 comments
6 participants
participants (6)
-
Chris Murphy -
Danny Horne -
Dave Mitchell -
Samuel Sieb -
Tim -
Wolfgang Pfeiffer