Re: [systemd-devel] [EXT] [systemd‑devel] no log information about why machine is sleeping
On Fri, 13 Aug 2021 18:43:40 +0300, Andrei Borzenkov wrote: > > I don't think any actual person was logged in, but gdm was running. > > And apparently gdm starts gsd-power, the gnome-settings power demon. I > > haven't yet been able to find where gsd-power gets its settings, but > > maybe it's that, together with treating network activity as "activity" > > for the purposes of deciding when to sleep. Does anyone here know? > > > > https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/22 Thanks, that link is very helpful! pgpLlOty3cJ6a.pgp Description: OpenPGP digital signature
Re: [systemd-devel] [EXT] [systemd‑devel] no log information about why machine is sleeping
On 13.08.2021 15:13, George Avrunin wrote: > On Fri, 13 Aug 2021 08:05:29 +0200, Ulrich Windl wrote: > >>> I suppose that's possible, though I haven't been able to find anywhere >>> that's configured. (I'll ask again on the Fedora list to be sure.) In >>> the places where I know I've manually configured it (e.g., in the KDE >>> power settings), it's not supposed to sleep at all when it's on AC >>> power. >> >> Amazingly in my Leap 15 system it's GNOME that triggers it: If I'm not >> logged in, no suspend happens, but when I have a GNOME session suspend >> happens. > > I don't think any actual person was logged in, but gdm was running. And > apparently gdm starts gsd-power, the gnome-settings power demon. I > haven't yet been able to find where gsd-power gets its settings, but maybe > it's that, together with treating network activity as "activity" for the > purposes of deciding when to sleep. Does anyone here know? > https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/22 > If it was gsd-power that was putting the machine to sleep, it wasn't > putting anything in the log saying that. >
Re: [systemd-devel] [EXT] [systemd‑devel] no log information about why machine is sleeping
On Fri, 13 Aug 2021 08:05:29 +0200, Ulrich Windl wrote: > > I suppose that's possible, though I haven't been able to find anywhere > > that's configured. (I'll ask again on the Fedora list to be sure.) In > > the places where I know I've manually configured it (e.g., in the KDE > > power settings), it's not supposed to sleep at all when it's on AC > > power. > > Amazingly in my Leap 15 system it's GNOME that triggers it: If I'm not > logged in, no suspend happens, but when I have a GNOME session suspend > happens. I don't think any actual person was logged in, but gdm was running. And apparently gdm starts gsd-power, the gnome-settings power demon. I haven't yet been able to find where gsd-power gets its settings, but maybe it's that, together with treating network activity as "activity" for the purposes of deciding when to sleep. Does anyone here know? If it was gsd-power that was putting the machine to sleep, it wasn't putting anything in the log saying that. pgpiIbpwaxibC.pgp Description: OpenPGP digital signature
Re: [systemd-devel] no log information about why machine is sleeping
On Fri, 13 Aug 2021 at 08:05:29 +0200, Ulrich Windl wrote: > Amazingly in my Leap 15 system it's GNOME that triggers it: If I'm not logged > in, no suspend happens, but when I have a GNOME session suspend happens. If this is not what you want, change the logged-in user's GNOME settings (via gnome-control-center or the /org/gnome/settings-daemon/plugins/power dconf tree). While a user is logged in, their per-user settings take effect, unless systemd-logind is configured to forbid that. The default in GNOME is to suspend after 20 minutes, to comply with European and American energy-saving legislation. smcv
[systemd-devel] Antw: Re: [EXT] [systemd‑devel] no log information about why machine is sleeping
>>> George Avrunin schrieb am 12.08.2021 um 14:10 in Nachricht <20210812081008.4ca3ce4c@g.localdomain>: > On Thu, 12 Aug 2021 09:24:25 +0200, Ulrich Windl wrote: > >> > However, I haven't been able to figure out why the machine puts itself >> > to sleep when it can't reach the switch. I asked about this on the >> > Fedora >> >> I don't know, but caring about the earch climate my PC goes to STR >> (suspend to RAM) when there is no activity for a longer time. >> Maybe your PC uses a similar setting, and being constantly attacked >> keeps it busy, so when there is no switch connection your PC becomes >> actually idle ;‑) > > I suppose that's possible, though I haven't been able to find anywhere > that's configured. (I'll ask again on the Fedora list to be sure.) In > the places where I know I've manually configured it (e.g., in the KDE > power settings), it's not supposed to sleep at all when it's on AC power. Amazingly in my Leap 15 system it's GNOME that triggers it: If I'm not logged in, no suspend happens, but when I have a GNOME session suspend happens. > >> >> > users list (and included the log entries shown below), and Chris Murphy >> > noted that systemd doesn't normally insert the sleep request in the >> > log, so it's not possible to determine what caused the sleep request. >> > He suggested that I start a thread here to ask if at least a single >> > line of information about how the sleep is being initiated could be >> > dumped into the log by default. >> >> Mine logs a lot when suspending or resuming, bu tOI dn't run Fedora >> (Leap 15.3 instead). > > George
Re: [systemd-devel] no log information about why machine is sleeping
On Thu, 12 Aug 2021 08:25:03 +0300, Andrei Borzenkov wrote: > > Aug 06 17:47:32 ext.math.umass.edu kernel: > > Lockdown: systemd-logind: hibernation is restricted; see man > > kernel_lockdown.7 Aug 06 17:47:32 ext.math.umass.edu kernel: Lockdown: > > systemd-logind: hibernation is restricted; see man kernel_lockdown.7 > > Aug 06 17:47:32 ext.math.umass.edu NetworkManager[2111]: > > [1628286452.1872] manager: sleep: sleep requested (sleeping: no > > enabled: yes) Aug 06 17:47:32 ext.math.umass.edu NetworkManager[2111]: > > > > Anything before these entries? In my case I see > > авг 06 08:41:18 bor-Latitude-E5450 systemd-logind[1300]: Lid closed. > авг 06 08:41:18 bor-Latitude-E5450 systemd-logind[1300]: Suspending... > авг 06 08:41:18 bor-Latitude-E5450 kernel: Lockdown: systemd-logind: > hibernation is restricted; > see man kernel_lockdown.7 > авг 06 08:41:18 bor-Latitude-E5450 NetworkManager[1277]: > [1628228478.4162] manager: sle > ep: sleep requested (sleeping: no enabled: yes) > ... > > So here I see the reason for suspend in logs. No, nothing that looks relevant at all (to me or to Chris Murphy). This is a desktop and there don't seem to be any events in the logs that have anything to do with it until the one about lockdown. George pgpv1wTmDiMa0.pgp Description: OpenPGP digital signature
[systemd-devel] Antw: Antw: [EXT] Re: [systemd‑devel] no log information about why machine is sleeping
>>> "Ulrich Windl" schrieb am 12.08.2021 um 10:01 in Nachricht <6114d54802a100043...@gwsmtp.uni-regensburg.de>: George Avrunin schrieb am 12.08.2021 um 01:44 in > Nachricht <20210811194453.2dd47326@g.localdomain>: >> On Wed, 11 Aug 2021 15:24:25 ‑0700, Luis Chamberlain wrote: >> >>> On Wed, Aug 11, 2021 at 05:11:21PM ‑0400, George Avrunin wrote: >>> > Aug 07 14:09:22 ext.math.umass.edu kernel: ACPI: Preparing to enter >>> > system sleep state S3 >>> >>> That's suspend to ram. Depending on the distribution it may or not be a >>> a default after a period of time of idle. The idea is that moving a >>> mouse would resume it. For desktops this is stupid. Try: >>> >>> systemctl mask sleep.target suspend.target hibernate.target >>> hybrid‑sleep.targe >>> >>> To re‑enable: >>> >>> sudo systemctl unmask sleep.target suspend.target hibernate.target >>> hybrid‑sleep.target >>> >>> Luis >> >> Thanks, masking the sleep, etc., targets will presumably stop it. >> >> But I don't think it was a default setting to suspend after a period of >> being idle, at least not once the machine was back on AC power (unless >> something got reset somehow). This machine is used as a mail and web >> server, as well as for some computations that my students and postdoc run >> remotely, and it's never done this before when there was no activity at >> the console. (And during the pandemic, there's been very little activity >> at the console‑‑we've all mostly been working from home.) > > Considering my previos message, that may answer while it does not go to Sorry; the "while" above should read "why"... > sleep > while being connected. > >> >> So I'd still like to understand what caused it to start the suspend >> operation. If there's an easy way to get just a little bit more logging >> about that, it would help me and probably others. >> >> George
[systemd-devel] Antw: Antw: [EXT] [systemd‑devel] no log information about why machine is sleeping
>>> "Ulrich Windl" schrieb am 12.08.2021 um 09:24 in Nachricht <6114cca902a100043...@gwsmtp.uni-regensburg.de>: > Mine logs a lot when suspending or resuming, bu tOI dn't run Fedora (Leap It seems the keyboard driver does not like me: "... but I don't ..." > 15.3 instead).
[systemd-devel] Antw: [EXT] Re: [systemd‑devel] no log information about why machine is sleeping
>>> George Avrunin schrieb am 12.08.2021 um 01:44 in Nachricht <20210811194453.2dd47326@g.localdomain>: > On Wed, 11 Aug 2021 15:24:25 ‑0700, Luis Chamberlain wrote: > >> On Wed, Aug 11, 2021 at 05:11:21PM ‑0400, George Avrunin wrote: >> > Aug 07 14:09:22 ext.math.umass.edu kernel: ACPI: Preparing to enter >> > system sleep state S3 >> >> That's suspend to ram. Depending on the distribution it may or not be a >> a default after a period of time of idle. The idea is that moving a >> mouse would resume it. For desktops this is stupid. Try: >> >> systemctl mask sleep.target suspend.target hibernate.target >> hybrid‑sleep.targe >> >> To re‑enable: >> >> sudo systemctl unmask sleep.target suspend.target hibernate.target >> hybrid‑sleep.target >> >> Luis > > Thanks, masking the sleep, etc., targets will presumably stop it. > > But I don't think it was a default setting to suspend after a period of > being idle, at least not once the machine was back on AC power (unless > something got reset somehow). This machine is used as a mail and web > server, as well as for some computations that my students and postdoc run > remotely, and it's never done this before when there was no activity at > the console. (And during the pandemic, there's been very little activity > at the console‑‑we've all mostly been working from home.) Considering my previos message, that may answer while it does not go to sleep while being connected. > > So I'd still like to understand what caused it to start the suspend > operation. If there's an easy way to get just a little bit more logging > about that, it would help me and probably others. > > George
[systemd-devel] Antw: [EXT] [systemd‑devel] no log information about why machine is sleeping
>>> George Avrunin schrieb am 11.08.2021 um 23:11 in Nachricht <20210811171121.0e197883@g.localdomain>: > Hello, > > As a result of a major power outage and consequent issues with some > switches, my office workstation, a Dell Precision T1700 running > fully‑updated Fedora 34, was off the network for most of last weekend. As > our department IT staff detected and fixed the switch issues, they noticed > that my workstation was putting itself to sleep when it couldn't connect > to the switch for my floor. Right now, everything is back up and working, > but they will probably have to replace the switch. > > However, I haven't been able to figure out why the machine puts itself to > sleep when it can't reach the switch. I asked about this on the Fedora I don't know, but caring about the earch climate my PC goes to STR (suspend to RAM) when there is no activity for a longer time. Maybe your PC uses a similar setting, and being constantly attacked keeps it busy, so when there is no switch connection your PC becomes actually idle ;-) > users list (and included the log entries shown below), and Chris Murphy > noted that systemd doesn't normally insert the sleep request in the log, > so it's not possible to determine what caused the sleep request. He > suggested that I start a thread here to ask if at least a single line of > information about how the sleep is being initiated could be dumped into > the log by default. Mine logs a lot when suspending or resuming, bu tOI dn't run Fedora (Leap 15.3 instead). > > I will experiment with rebooting with systemd.log_level=debug when I know > the switch will be shut down for replacement. But it would be good to get > more information about what's initiating sleep by default. > > Thanks, > > George Avrunin > > > Here are the relevant log entries from one of the times the machine put > itself to sleep, apparently because it couldn't connect to the network. > If there's more information I can supply, please let me know. > > (This starts after power was restored to the building and the machine had > been manually rebooted just to be sure it would go online.) > > Aug 06 17:47:32 ext.math.umass.edu kernel: > Lockdown: systemd‑logind: hibernation is restricted; see man > kernel_lockdown.7 Aug 06 17:47:32 ext.math.umass.edu kernel: Lockdown: > systemd‑logind: hibernation is restricted; see man kernel_lockdown.7 > Aug 06 17:47:32 ext.math.umass.edu NetworkManager[2111]: > [1628286452.1872] manager: sleep: sleep requested (sleeping: no enabled: > yes) Aug 06 17:47:32 ext.math.umass.edu NetworkManager[2111]: > [1628286452.1876] manager: NetworkManager state is now ASLEEP > Aug 06 17:47:32 ext.math.umass.edu ModemManager[1954]: > [sleep‑monitor] system is about to suspend > Aug 06 17:47:32 ext.math.umass.edu gnome‑shell[4292]: Screen lock is > locked down, not locking > Aug 06 17:47:32 ext.math.umass.edu systemd[1]: Reached target Sleep. > Aug 06 17:47:32 ext.math.umass.edu systemd[1]: Starting System Suspend... But here is a sleep request logged! > Aug 06 17:47:32 ext.math.umass.edu systemd‑sleep[40504]: Suspending > system... > Aug 06 17:47:32 ext.math.umass.edu kernel: PM: suspend entry (deep) This log buffer is logged with the wrong time: Actually it the last part of suspend, logged at resume time. > Aug 07 14:09:22 ext.math.umass.edu kernel: Filesystems sync: 0.379 seconds > Aug 07 14:09:22 ext.math.umass.edu kernel: Freezing user space processes > ... (elapsed 0.002 seconds) done. > Aug 07 14:09:22 ext.math.umass.edu kernel: OOM killer disabled. > Aug 07 14:09:22 ext.math.umass.edu kernel: Freezing remaining freezable > tasks ... (elapsed 0.001 seconds) done. > Aug 07 14:09:22 ext.math.umass.edu kernel: printk: Suspending console(s) > (use no_console_suspend to debug) > Aug 07 14:09:22 ext.math.umass.edu kernel: serial 00:06: disabled > Aug 07 14:09:22 ext.math.umass.edu kernel: e1000e: EEE TX LPI TIMER: > 0011 > Aug 07 14:09:22 ext.math.umass.edu kernel: sd 0:0:0:0: [sda] Synchronizing > SCSI cache > Aug 07 14:09:22 ext.math.umass.edu kernel: sd 1:0:0:0: [sdb] Synchronizing > SCSI cache > Aug 07 14:09:22 ext.math.umass.edu kernel: sd 1:0:0:0: [sdb] Stopping disk > Aug 07 14:09:22 ext.math.umass.edu kernel: sd 0:0:0:0: [sda] Stopping disk > Aug 07 14:09:22 ext.math.umass.edu kernel: PM: suspend devices took 1.031 > seconds > Aug 07 14:09:22 ext.math.umass.edu kernel: ACPI: Preparing to enter system > sleep state S3 > Aug 07 14:09:22 ext.math.umass.edu kernel: PM: Saving platform NVS memory > Aug 07 14:09:22 ext.math.umass.edu kernel: Disabling non‑boot CPUs ... This is still the suspend part... > lines 835‑871 > etc.
Re: [systemd-devel] no log information about why machine is sleeping
On 12.08.2021 00:11, George Avrunin wrote: > Hello, > > As a result of a major power outage and consequent issues with some > switches, my office workstation, a Dell Precision T1700 running > fully-updated Fedora 34, was off the network for most of last weekend. As > our department IT staff detected and fixed the switch issues, they noticed > that my workstation was putting itself to sleep when it couldn't connect > to the switch for my floor. Right now, everything is back up and working, > but they will probably have to replace the switch. > > However, I haven't been able to figure out why the machine puts itself to > sleep when it can't reach the switch. I asked about this on the Fedora > users list (and included the log entries shown below), and Chris Murphy > noted that systemd doesn't normally insert the sleep request in the log, > so it's not possible to determine what caused the sleep request. He > suggested that I start a thread here to ask if at least a single line of > information about how the sleep is being initiated could be dumped into > the log by default. > > I will experiment with rebooting with systemd.log_level=debug when I know > the switch will be shut down for replacement. But it would be good to get > more information about what's initiating sleep by default. > > Thanks, > > George Avrunin > > > Here are the relevant log entries from one of the times the machine put > itself to sleep, apparently because it couldn't connect to the network. > If there's more information I can supply, please let me know. > > (This starts after power was restored to the building and the machine had > been manually rebooted just to be sure it would go online.) > > Aug 06 17:47:32 ext.math.umass.edu kernel: > Lockdown: systemd-logind: hibernation is restricted; see man > kernel_lockdown.7 Aug 06 17:47:32 ext.math.umass.edu kernel: Lockdown: > systemd-logind: hibernation is restricted; see man kernel_lockdown.7 > Aug 06 17:47:32 ext.math.umass.edu NetworkManager[2111]: > [1628286452.1872] manager: sleep: sleep requested (sleeping: no enabled: > yes) Aug 06 17:47:32 ext.math.umass.edu NetworkManager[2111]: Anything before these entries? In my case I see авг 06 08:41:18 bor-Latitude-E5450 systemd-logind[1300]: Lid closed. авг 06 08:41:18 bor-Latitude-E5450 systemd-logind[1300]: Suspending... авг 06 08:41:18 bor-Latitude-E5450 kernel: Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7 авг 06 08:41:18 bor-Latitude-E5450 NetworkManager[1277]: [1628228478.4162] manager: sle ep: sleep requested (sleeping: no enabled: yes) ... So here I see the reason for suspend in logs. > [1628286452.1876] manager: NetworkManager state is now ASLEEP > Aug 06 17:47:32 ext.math.umass.edu ModemManager[1954]: > [sleep-monitor] system is about to suspend > Aug 06 17:47:32 ext.math.umass.edu gnome-shell[4292]: Screen lock is > locked down, not locking > Aug 06 17:47:32 ext.math.umass.edu systemd[1]: Reached target Sleep. > Aug 06 17:47:32 ext.math.umass.edu systemd[1]: Starting System Suspend... > Aug 06 17:47:32 ext.math.umass.edu systemd-sleep[40504]: Suspending > system... > Aug 06 17:47:32 ext.math.umass.edu kernel: PM: suspend entry (deep) > Aug 07 14:09:22 ext.math.umass.edu kernel: Filesystems sync: 0.379 seconds > Aug 07 14:09:22 ext.math.umass.edu kernel: Freezing user space processes > ... (elapsed 0.002 seconds) done. > Aug 07 14:09:22 ext.math.umass.edu kernel: OOM killer disabled. > Aug 07 14:09:22 ext.math.umass.edu kernel: Freezing remaining freezable > tasks ... (elapsed 0.001 seconds) done. > Aug 07 14:09:22 ext.math.umass.edu kernel: printk: Suspending console(s) > (use no_console_suspend to debug) > Aug 07 14:09:22 ext.math.umass.edu kernel: serial 00:06: disabled > Aug 07 14:09:22 ext.math.umass.edu kernel: e1000e: EEE TX LPI TIMER: > 0011 > Aug 07 14:09:22 ext.math.umass.edu kernel: sd 0:0:0:0: [sda] Synchronizing > SCSI cache > Aug 07 14:09:22 ext.math.umass.edu kernel: sd 1:0:0:0: [sdb] Synchronizing > SCSI cache > Aug 07 14:09:22 ext.math.umass.edu kernel: sd 1:0:0:0: [sdb] Stopping disk > Aug 07 14:09:22 ext.math.umass.edu kernel: sd 0:0:0:0: [sda] Stopping disk > Aug 07 14:09:22 ext.math.umass.edu kernel: PM: suspend devices took 1.031 > seconds > Aug 07 14:09:22 ext.math.umass.edu kernel: ACPI: Preparing to enter system > sleep state S3 > Aug 07 14:09:22 ext.math.umass.edu kernel: PM: Saving platform NVS memory > Aug 07 14:09:22 ext.math.umass.edu kernel: Disabling non-boot CPUs ... > lines 835-871 > etc. >
Re: [systemd-devel] no log information about why machine is sleeping
On Wed, 11 Aug 2021 15:24:25 -0700, Luis Chamberlain wrote: > On Wed, Aug 11, 2021 at 05:11:21PM -0400, George Avrunin wrote: > > Aug 07 14:09:22 ext.math.umass.edu kernel: ACPI: Preparing to enter > > system sleep state S3 > > That's suspend to ram. Depending on the distribution it may or not be a > a default after a period of time of idle. The idea is that moving a > mouse would resume it. For desktops this is stupid. Try: > > systemctl mask sleep.target suspend.target hibernate.target > hybrid-sleep.targe > > To re-enable: > > sudo systemctl unmask sleep.target suspend.target hibernate.target > hybrid-sleep.target > > Luis Thanks, masking the sleep, etc., targets will presumably stop it. But I don't think it was a default setting to suspend after a period of being idle, at least not once the machine was back on AC power (unless something got reset somehow). This machine is used as a mail and web server, as well as for some computations that my students and postdoc run remotely, and it's never done this before when there was no activity at the console. (And during the pandemic, there's been very little activity at the console--we've all mostly been working from home.) So I'd still like to understand what caused it to start the suspend operation. If there's an easy way to get just a little bit more logging about that, it would help me and probably others. George pgpgqbcOjbGAO.pgp Description: OpenPGP digital signature
Re: [systemd-devel] no log information about why machine is sleeping
On Wed, Aug 11, 2021 at 05:11:21PM -0400, George Avrunin wrote: > Aug 07 14:09:22 ext.math.umass.edu kernel: ACPI: Preparing to enter system > sleep state S3 That's suspend to ram. Depending on the distribution it may or not be a a default after a period of time of idle. The idea is that moving a mouse would resume it. For desktops this is stupid. Try: systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.targe To re-enable: sudo systemctl unmask sleep.target suspend.target hibernate.target hybrid-sleep.target Luis
[systemd-devel] no log information about why machine is sleeping
Hello, As a result of a major power outage and consequent issues with some switches, my office workstation, a Dell Precision T1700 running fully-updated Fedora 34, was off the network for most of last weekend. As our department IT staff detected and fixed the switch issues, they noticed that my workstation was putting itself to sleep when it couldn't connect to the switch for my floor. Right now, everything is back up and working, but they will probably have to replace the switch. However, I haven't been able to figure out why the machine puts itself to sleep when it can't reach the switch. I asked about this on the Fedora users list (and included the log entries shown below), and Chris Murphy noted that systemd doesn't normally insert the sleep request in the log, so it's not possible to determine what caused the sleep request. He suggested that I start a thread here to ask if at least a single line of information about how the sleep is being initiated could be dumped into the log by default. I will experiment with rebooting with systemd.log_level=debug when I know the switch will be shut down for replacement. But it would be good to get more information about what's initiating sleep by default. Thanks, George Avrunin Here are the relevant log entries from one of the times the machine put itself to sleep, apparently because it couldn't connect to the network. If there's more information I can supply, please let me know. (This starts after power was restored to the building and the machine had been manually rebooted just to be sure it would go online.) Aug 06 17:47:32 ext.math.umass.edu kernel: Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7 Aug 06 17:47:32 ext.math.umass.edu kernel: Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7 Aug 06 17:47:32 ext.math.umass.edu NetworkManager[2111]: [1628286452.1872] manager: sleep: sleep requested (sleeping: no enabled: yes) Aug 06 17:47:32 ext.math.umass.edu NetworkManager[2111]: [1628286452.1876] manager: NetworkManager state is now ASLEEP Aug 06 17:47:32 ext.math.umass.edu ModemManager[1954]: [sleep-monitor] system is about to suspend Aug 06 17:47:32 ext.math.umass.edu gnome-shell[4292]: Screen lock is locked down, not locking Aug 06 17:47:32 ext.math.umass.edu systemd[1]: Reached target Sleep. Aug 06 17:47:32 ext.math.umass.edu systemd[1]: Starting System Suspend... Aug 06 17:47:32 ext.math.umass.edu systemd-sleep[40504]: Suspending system... Aug 06 17:47:32 ext.math.umass.edu kernel: PM: suspend entry (deep) Aug 07 14:09:22 ext.math.umass.edu kernel: Filesystems sync: 0.379 seconds Aug 07 14:09:22 ext.math.umass.edu kernel: Freezing user space processes ... (elapsed 0.002 seconds) done. Aug 07 14:09:22 ext.math.umass.edu kernel: OOM killer disabled. Aug 07 14:09:22 ext.math.umass.edu kernel: Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. Aug 07 14:09:22 ext.math.umass.edu kernel: printk: Suspending console(s) (use no_console_suspend to debug) Aug 07 14:09:22 ext.math.umass.edu kernel: serial 00:06: disabled Aug 07 14:09:22 ext.math.umass.edu kernel: e1000e: EEE TX LPI TIMER: 0011 Aug 07 14:09:22 ext.math.umass.edu kernel: sd 0:0:0:0: [sda] Synchronizing SCSI cache Aug 07 14:09:22 ext.math.umass.edu kernel: sd 1:0:0:0: [sdb] Synchronizing SCSI cache Aug 07 14:09:22 ext.math.umass.edu kernel: sd 1:0:0:0: [sdb] Stopping disk Aug 07 14:09:22 ext.math.umass.edu kernel: sd 0:0:0:0: [sda] Stopping disk Aug 07 14:09:22 ext.math.umass.edu kernel: PM: suspend devices took 1.031 seconds Aug 07 14:09:22 ext.math.umass.edu kernel: ACPI: Preparing to enter system sleep state S3 Aug 07 14:09:22 ext.math.umass.edu kernel: PM: Saving platform NVS memory Aug 07 14:09:22 ext.math.umass.edu kernel: Disabling non-boot CPUs ... lines 835-871 etc. pgpxrv8sRWHHG.pgp Description: OpenPGP digital signature
