Am 01.05.2015 um 08:36 schrieb Michael Biebl:
It's a workaround.
So it might still be worth a bug report against the linux kernel.
I did that:
Bug#783934: Acknowledgement (linux-image-3.16.0-4-amd64:
systemd-udev-settle waiting 50 s during boot for snd-usb-audio)
https://bugs.debian.org/cgi
Am 01.05.2015 um 07:09 schrieb Matthias Bodenbinder:
> Am 01.05.2015 um 00:00 schrieb Michael Biebl:
>> You could try blacklisting "snd-usb-audio" via
>> $ echo "blacklist snd-usb-audio" > /etc/modprobe.d/no-usb-audio.conf
>>
>> Maybe that helps (you might need to rebuild your initramfs as well)
>
Am 01.05.2015 um 00:00 schrieb Michael Biebl:
You could try blacklisting "snd-usb-audio" via
$ echo "blacklist snd-usb-audio" > /etc/modprobe.d/no-usb-audio.conf
Maybe that helps (you might need to rebuild your initramfs as well)
This did the trick. The sound is disabled, the boot is fast and
Am 30.04.2015 um 16:57 schrieb Matthias Bodenbinder:
> It is the keyboard! I tried a different one and the computer boots fast.
>
> The keyboard is not new. I had it running on the same computer for
> several years. All with debian wheezy. No problems. Why is that now? I
> doubt that this is a hw
On 04/30/2015 01:27 PM, Matthias Bodenbinder wrote:
Am 30.04.2015 um 16:57 schrieb Matthias Bodenbinder:
Am 30.04.2015 um 15:09 schrieb Michael Biebl:
As you can see above, systemd-udevd timeouts processing the events from
that device and is eventually killed. The internal timeout for udev is
9
Am 30.04.2015 um 16:57 schrieb Matthias Bodenbinder:
> Am 30.04.2015 um 15:09 schrieb Michael Biebl:
>> As you can see above, systemd-udevd timeouts processing the events from
>> that device and is eventually killed. The internal timeout for udev is
>> 90s. If you add the the remaining time to boot
Am 30.04.2015 um 15:09 schrieb Michael Biebl:
As you can see above, systemd-udevd timeouts processing the events from
that device and is eventually killed. The internal timeout for udev is
90s. If you add the the remaining time to boot the system, that would
explain the 2min boot times.
This loo
Am 30.04.2015 um 07:55 schrieb Matthias Bodenbinder:
> Apr 30 07:28:31 xxx systemd-udevd[175]: worker [196]
> /devices/pci:00/:00:12.2/usb1/1-4/1-4.4/1-4.4:1.0 timeout; kill it
> Apr 30 07:28:31 xxx systemd-udevd[175]: seq 1229
> '/devices/pci:00/:00:12.2/usb1/1-4/1-4.4/1-4.4:1.0' k
Am 29.04.2015 um 19:23 schrieb Christian Seiler:
Just for the purpose of debugging, could you increase RateLimitBurst to
1 or so (i.e. 10x the default value) in /etc/systemd/journald.conf
and reboot? (Set it back again after you're done deubgging, else your
logs might get flooded.)
The 1000
On 04/29/2015 06:53 PM, Matthias Bodenbinder wrote:
> Am 29.04.2015 um 10:32 schrieb Christian Seiler:
>> Just use journalctl (without -b) to see all messages (they are
>> still in RAM in the journal - as per the log you posted, journald
>> will use up to 80 MiB [2] which is more than enough to kee
Am 29.04.2015 um 10:32 schrieb Christian Seiler:
Just use journalctl (without -b) to see all messages (they are
still in RAM in the journal - as per the log you posted, journald
will use up to 80 MiB [2] which is more than enough to keep all
3000 or so messages). Just look through them (there are
Am 29.04.2015 um 15:28 schrieb Michael Biebl:
Am 29.04.2015 um 10:32 schrieb Christian Seiler:
Am 2015-04-29 07:15, schrieb Matthias Bodenbinder:
systemd-analyze blame:
56.397s systemd-udev-settle.service
Yeah, that shouldn't happen.
Matthias, do you have any custom udev rules in
Am 29.04.2015 um 10:32 schrieb Christian Seiler:
> Am 2015-04-29 07:15, schrieb Matthias Bodenbinder:
>> systemd-analyze blame:
>> 56.397s systemd-udev-settle.service
>
> Yeah, that shouldn't happen.
Matthias, do you have any custom udev rules in /etc/udev/rules.d/?
Is this an upgraded o
Am 2015-04-29 07:15, schrieb Matthias Bodenbinder:
systemd-analyze blame:
56.397s systemd-udev-settle.service
Yeah, that shouldn't happen.
But I am not really happy with the log since I find the following
statement when doing a journalctl -b:
start of log
Apr 29 06:51:55 xxx sy
Hello Christian,
first of all many thanks for your very detailed reply. This was excellent!
I activated systemd-udev-settle again and want to debug the situtation
according to your instructions (with udev.log-priority etc.).
Here is the time consumption:
systemd-analyze blame:
##
Hi,
Am 2015-04-28 07:48, schrieb Matthias Bodenbinder:
I installed debian 8 on one of my PCs and got into trouble with extra
long boot times of > 2 min. I found out that it due to
systemd-udev-settle.service. My PC is using lvm and that somehow
interferes with systemd-udev-settle.service. The we
16 matches
Mail list logo
