On Tue, Nov 5, 2019 at 8:33 AM Chris Murphy wrote:
>
> On Fri, Nov 1, 2019 at 2:31 PM Matthew Garrett wrote:
> >
> > The initrd already contains a UI stack in order to permit disk unlock
> > at boot time, so this really doesn't seem like a problem?
>
> It's a v
On Thu, Oct 31, 2019 at 5:06 PM Lennart Poettering
wrote:
> Paging doesn't allow that really. It's always ugly. You'd have to have
> your own UI stack in the initrd, i.e. basically have an alternative
> root disk, that possesses the screen exclusively as long as the system
> is up but not
On Tue, Jun 4, 2019 at 9:42 AM Steve Dickson wrote:
> AVC avc: denied { sys_chroot } for pid=2919 comm="rpc.mountd"
> capability=18 scontext=system_u:system_r:nfsd_t:s0
> tcontext=system_u:system_r:nfsd_t:s0 tclass=capability permissive=0
This is an SELinux policy violation, nothing to do
> The point I was trying to make was: "CPUID" and the model-specific registers
> (thus the name) depend very much on the CPU being used. While the kernel makes
> grat efforts to get things right, I wondered whether it's the best idea
> whether
> to repeat that effort in an application program.
On Sun, Apr 19, 2015 at 11:37:31PM +0200, Kay Sievers wrote:
On Sat, Apr 18, 2015 at 9:39 PM, Matthew Garrett mj...@srcf.ucam.org wrote:
1) having this in udev makes it easier for users to alter the
configuration - the kernel can then afford to be conservative until we
enable power
From: Matthew Garrett mj...@coreos.com
If a Bluetooth controller is built into the machine, it should be safe to
enable runtime power management on it. Let's do so.
---
Makefile.am | 3 ++-
rules/90-usb-bluetooth-pm.rules | 8
2 files changed, 10 insertions(+), 1
From: Matthew Garrett mj...@coreos.com
4.1 ports HDA codec power management to the standard runtime PM framework,
which means we have per-codec control over whether it's enabled or not.
We've traditionally left this disabled because on some codecs enabling it
causes popping noises on power
Modern hardware is very sensitive to peripheral power management state. While
the kernel supports runtime PM on a lot of hardware, it's mostly disabled by
default due to the risk of it breaking a subset of devices. Let's turn it on
on devices where we have reasonable confidence in it working, with
From: Matthew Garrett mj...@coreos.com
PCI power management seems to work fine on Intel HDA controllers, so let's
turn that on. We can expand this to other vendors based on user feedback.
---
Makefile.am | 3 ++-
rules/90-hda-controller-pm.rules | 3 +++
2 files changed, 5
to
find it here.
--
Matthew Garrett | mj...@srcf.ucam.org
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
From: Matthew Garrett mj...@coreos.com
We only care about whether our direct parent is removable, not whether any
further points up the tree are - the kernel will take care of policy for
those itself. This enables autosuspend on devices where the root hub reports
that its removable state
On Sun, Oct 13, 2013 at 10:09:28PM +0200, Bastien Nocera wrote:
On Sun, 2013-10-13 at 20:57 +0100, Matthew Garrett wrote:
On Sun, Oct 13, 2013 at 09:50:59PM +0200, Bastien Nocera wrote:
+r =
read_one_line_file(/sys/bus/acpi/devices/INT3392:00/wakeup_events, p);
/sys/bus
a
+ * critical level */
+if (p[0] == '3' p[1] == '\0')
+return true;
That seems a little harsh - not all firmware exposes the settings for
this. I think it's legitimate to just program it yourself.
--
Matthew Garrett | mj...@srcf.ucam.org
13 matches
Mail list logo
