Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #197987 > unrolled thread

Problems with kernel 4.17.0-1-amd64

Back to article view | Back to linux.debian.user

Contents

  Problems with kernel 4.17.0-1-amd64 Nicolas George <george@nsup.org> - 2018-07-25 16:00 +0200
    Re: Problems with kernel 4.17.0-1-amd64 rv riveravaldez <riveravaldezmail@gmail.com> - 2018-07-26 08:00 +0200
      Re: Problems with kernel 4.17.0-1-amd64 Nicolas George <george@nsup.org> - 2018-08-11 16:50 +0200
    Re: Problems with kernel 4.17.0-1-amd64 Nicolas George <george@nsup.org> - 2018-08-11 16:50 +0200
      Re: Problems with kernel 4.17.0-1-amd64 Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-08-12 10:30 +0200
    Re: Problems with kernel 4.17.0-1-amd64 deloptes <deloptes@gmail.com> - 2018-08-12 09:00 +0200

#197987 — Problems with kernel 4.17.0-1-amd64

[Multipart message — attachments visible in raw view] — view raw

Hi.

I am running testing on a fairly normal i3-based PC. Since yesterday, it
is using the 4.17.0-1-amd64 kernel instead of 4.16.0-2-amd64, and I am
experiencing the following two issues:

The device for the audio controller takes about 0.3 seconds to open. I
have just rebooted on 4.16, and with it the delay is imperceptible. (And
yes, 0.3 seconds for that is a problem for me.) The audio device is
listed as "ALC892 Analog".

More severe: from time to time, process doing disk access go into D
state but the disk stays idle; the kernel reports nothing at all (in
particular: no reset of the ATA bus). They can stay like that for a few
seconds, a few dozens seconds, and I had a firefox freeze for several
minutes until I got fed up and pressed the power button; the shutdown
was clean. I had no such problem with 4.16.0-2-amd64, and I will be
careful to see if they happen now that I have rebooted with the oldest
kernel.

Does anyone experience the same problems?


(To test the audio delay issue, you can use the following commands:
ffmpeg -lavfi sine=d=0.5 sine.wav
aplay sine.wav
The beep sound should be instantaneous, except possibly on the first run
if aplay and libraries are not yet loaded from disk.)

Regards,

-- 
  Nicolas George

[toc] | [next] | [standalone]

#198008

On Wed, Jul 25, 2018 at 10:55 AM, Nicolas George <george@nsup.org> wrote:
> Hi.
>
> I am running testing on a fairly normal i3-based PC. Since yesterday, it
> is using the 4.17.0-1-amd64 kernel instead of 4.16.0-2-amd64, and I am
> experiencing the following two issues:
>
> The device for the audio controller takes about 0.3 seconds to open. I
> have just rebooted on 4.16, and with it the delay is imperceptible. (And
> yes, 0.3 seconds for that is a problem for me.) The audio device is
> listed as "ALC892 Analog".
>
> More severe: from time to time, process doing disk access go into D
> state but the disk stays idle; the kernel reports nothing at all (in
> particular: no reset of the ATA bus). They can stay like that for a few
> seconds, a few dozens seconds, and I had a firefox freeze for several
> minutes until I got fed up and pressed the power button; the shutdown
> was clean. I had no such problem with 4.16.0-2-amd64, and I will be
> careful to see if they happen now that I have rebooted with the oldest
> kernel.
>
> Does anyone experience the same problems?
>
>
> (To test the audio delay issue, you can use the following commands:
> ffmpeg -lavfi sine=d=0.5 sine.wav
> aplay sine.wav
> The beep sound should be instantaneous, except possibly on the first run
> if aplay and libraries are not yet loaded from disk.)
>
> Regards,
>
> --
>   Nicolas George

I'm having an audio issue with this same kernel: there's a permanent
buzz that starts at soon as the system has loaded and only stops when
I play some sound (any audio or video) or starts JACK (via qjackctl).

I remember something similar in an old version of antiX (a
debian-testing based distro) some time ago.

Any recomendation?

Thanks!

[toc] | [prev] | [next] | [standalone]

#198624

[Multipart message — attachments visible in raw view] — view raw

rv riveravaldez (2018-07-26):
> I'm having an audio issue with this same kernel: there's a permanent
> buzz that starts at soon as the system has loaded and only stops when
> I play some sound (any audio or video) or starts JACK (via qjackctl).

A lost interrupt like I suspected initially would not have had that
result. On the other hand, power saving on the sound controller can:
when it is powered down, interferences from the DC power supply can seep
in.

It could be that option power_save=0 to snd-hda-intel or whichever
module your particular sound controller helps.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#198623

[Multipart message — attachments visible in raw view] — view raw

Hi.

An update on this:

Nicolas George (2018-07-25):
> The device for the audio controller takes about 0.3 seconds to open. I
> have just rebooted on 4.16, and with it the delay is imperceptible. (And
> yes, 0.3 seconds for that is a problem for me.) The audio device is
> listed as "ALC892 Analog".

This was documented in the ChangeLog (not in so many words), and the fix
is a module option:

options snd-hda-intel power_save=0

> More severe: from time to time, process doing disk access go into D
> state but the disk stays idle; the kernel reports nothing at all (in
> particular: no reset of the ATA bus). They can stay like that for a few
> seconds, a few dozens seconds, and I had a firefox freeze for several
> minutes until I got fed up and pressed the power button; the shutdown
> was clean. I had no such problem with 4.16.0-2-amd64, and I will be
> careful to see if they happen now that I have rebooted with the oldest
> kernel.

This one was fixed by adding this on the kernel command-line:

dm_mod.use_blk_mq=0 scsi_mod.use_blk_mq=0

It is possible that "ahci.mobile_lpm_policy=0" helps too, it was
suggested to me as a fix too and I have not yet tested without it, nor
with use_blk_mq in modprobe.d instead of the kernel command-line.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#198655

Le 11/08/2018 à 16:43, Nicolas George a écrit :
> 
> This one was fixed by adding this on the kernel command-line:
> 
> dm_mod.use_blk_mq=0 scsi_mod.use_blk_mq=0
> 
> It is possible that "ahci.mobile_lpm_policy=0" helps too, it was
> suggested to me as a fix too and I have not yet tested without it, nor
> with use_blk_mq in modprobe.d instead of the kernel command-line.

It would probably work too, but my advice is to stick with the kernel 
command line for the following reasons :

- it is more visible (/proc/cmdline, dmesg...) than an obscure file in 
/etc/modprobe.d/ and possibly the initramfs

- is can be easily edited at runtime in the boot loader

- it works even if the driver is built in the kernel image, while 
/etc/modprobe.d/ works only with modules

- if the module is included in and loaded by the initramfs, you must 
rebuild the initramfs after any change in /etc/modprobe.d/

[toc] | [prev] | [next] | [standalone]

#198653

Nicolas George wrote:

> I am running testing on a fairly normal i3-based PC. Since yesterday, it
> is using the 4.17.0-1-amd64 kernel instead of 4.16.0-2-amd64, and I am
> experiencing the following two issues:
> 
> The device for the audio controller takes about 0.3 seconds to open. I
> have just rebooted on 4.16, and with it the delay is imperceptible. (And
> yes, 0.3 seconds for that is a problem for me.) The audio device is
> listed as "ALC892 Analog".

Hi,
I am using debian stable with self compiled kernel. With 4.16.4 I had a
terrible experience with audio devices. I went back to 4.15.8 and just
recently installed 4.17.13. With 4.17.13 everything is fine.
I usually download the source and do 
        cp <old_config> .config
        make oldconfig
        make deb-pkg 
to produce the binaries.

You can check the kernel change log. IMO there must have been some work on
audio stack, but I did not look into the detail.

regards

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web