В Sat, 18 Apr 2015 09:11:57 -0700
Matthew Garrett пишет:
> From: Matthew Garrett
>
> 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.rule
В Fri, 17 Apr 2015 14:04:18 -0600
Daniel Drake пишет:
> Hi,
>
> I'm investigating why "systemctl stop gdm; Xorg" usually fails. The
> new X process complains that X is still running.
>
> Here's what I think is happening:
>
> 1. systemd sends SIGTERM to gdm to stop the service
>
> 2. gdm exits
В Fri, 17 Apr 2015 16:47:58 +
Zbigniew Jędrzejewski-Szmek пишет:
> On Mon, Feb 16, 2015 at 04:19:47PM +0100, Christian Seiler wrote:
> > Am 2015-02-16 14:16, schrieb Lennart Poettering:
> > >On Mon, 16.02.15 14:13, Michael Biebl (mbi...@gmail.com) wrote:
> > >>Not quite. While you can use dro
В Sat, 18 Apr 2015 19:54:50 +0530
Praveen kumar R пишет:
> Yes it's a kernel command line arg, it is board specific token introduced
> to control the serial console.
> if defined serial console should not be enabled.
>
Sorry I do not understand this sentence. "define" what? Please give
exact ex
udevadm manual says:
A value of 0 will check if the queue is empty and always return
immediately.
However, currently we ignore the deadline if the value is 0, and wait
without any limit.
Zero timeout behaved according to the documentation until commit
ead7c62ab7 (udevadm: settle - kill a
When running udevadm settle --timeout=0, udev_ctrl_send_ping always
times out, and settle returns 0 without checking the queue.
Now we skip ping in this case, and return the queue state.
---
src/udev/udevadm-settle.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/udev/ude
When running udevadm settle --timeout=0, the ping always times out, and
udevadm will return 0 without checking the queue state.
Since zero timeout is considered as unlimited timeout, we use now
unlimited ping timeout.
---
src/udev/udevadm-settle.c | 4 +++-
1 file changed, 3 insertions(+), 1 dele
When udevadm settle times out, it exits with exit code 1. This make it
impossible for users to detect a timeout and handle real errors. Now we
use exit code 3 on timeouts.
---
src/udev/udevadm-settle.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/udev/udevadm-settl
(Resending from the correct address)
On Sat, Apr 18, 2015 at 07:51:26PM +0200, Kay Sievers wrote:
> It looks like an unconditional static assignment.
>
>
> Why should udev carry this? We generally do not want to do things like
> that. Udev can help if there is conditional policy or complex
> cr
On Sat, Apr 18, 2015 at 6:11 PM, Matthew Garrett wrote:
> From: Matthew Garrett
>
> 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.
> +ACTION=="add", SUBSYSTEM=="pci", ATTR{class}=="0x040300",
From: Matthew Garrett
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 insertions(+), 1 d
From: Matthew Garrett
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 deletion(-)
create
From: Matthew Garrett
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 transitions, but now we
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
Hello,
>> Why does systemd start this service before /var is mounted, though the
>> service should be executed after remote-fs.target, and remote-fs.target
>> comes after local-fs.target?
>>
>
> Because remote-fs.target is not part of initial transaction.
>
>> And why is this different in my inter
Hello!
Sometimes I'm seeing messages like this:
[ 5780.379921] systemd-resolved[685]: Assertion 'n > 0' failed at
/var/tmp/portage/sys-apps/systemd-219-
r2/work/systemd-219/src/resolve/resolved-dns-answer.c:28, function
dns_answer_new(). Aborting.
[ 5780.621865] systemd-resolved[7396]: Assertio
Yes it's a kernel command line arg, it is board specific token introduced
to control the serial console.
if defined serial console should not be enabled.
we have this in place for other system initializing system - sytemV , where
depending
On Fri, Apr 17, 2015 at 4:24 PM, Lennart Poettering > wro
On 04/18/2015 05:29 AM, Matt Hoosier wrote:
> On Fri, Apr 17, 2015 at 3:52 PM, Cristian Rodríguez
> mailto:crrodrig...@opensuse.org>> wrote:
> Did you watch this presentation ?
>
> https://www.youtube.com/watch?v=RFVlbaDqll8
>
> what part of systemd is taking 1.5 seconds to start, on
В Thu, 16 Apr 2015 17:10:57 +0200
"Christoph Pleger" пишет:
> Hello,
>
> I wrote:
>
> >> Sounds like you want to create intermediate.target, change
> >> default.target to point at it, boot all the way up to
> >> intermediate.target, and at that point isolate or start
> >> multi-user.target.
>
19 matches
Mail list logo
