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

Groups > linux.debian.kernel > #90405 > unrolled thread

Bug#1120831: Acknowledgement (eslinux-image-6.17.8+deb14-amd64: failed command: READ FPDMA QUEUED after boot)

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1120831: Acknowledgement (eslinux-image-6.17.8+deb14-amd64: failed command: READ FPDMA QUEUED after boot) Wolf <snow.wolf.29@proton.me> - 2025-12-09 07:40 +0100
    Bug#1120831: Acknowledgement (eslinux-image-6.17.8+deb14-amd64: failed command: READ FPDMA QUEUED after boot) Salvatore Bonaccorso <carnil@debian.org> - 2025-12-17 11:20 +0100
      Bug#1120831: Acknowledgement (eslinux-image-6.17.8+deb14-amd64: failed command: READ FPDMA QUEUED after boot) Salvatore Bonaccorso <carnil@debian.org> - 2025-12-20 13:50 +0100
      Bug#1120831: Acknowledgement (eslinux-image-6.17.8+deb14-amd64: failed command: READ FPDMA QUEUED after boot) Salvatore Bonaccorso <carnil@debian.org> - 2026-01-07 10:50 +0100
        Bug#1120831: Acknowledgement (eslinux-image-6.17.8+deb14-amd64: failed command: READ FPDMA QUEUED after boot) Salvatore Bonaccorso <carnil@debian.org> - 2026-01-11 21:20 +0100
          Bug#1120831: Acknowledgement (eslinux-image-6.17.8+deb14-amd64: failed command: READ FPDMA QUEUED after boot) Wolf <snow.wolf.29@proton.me> - 2026-01-14 10:20 +0100
            Bug#1120831: Acknowledgement (eslinux-image-6.17.8+deb14-amd64: failed command: READ FPDMA QUEUED after boot) Wolf <snow.wolf.29@proton.me> - 2026-01-14 12:20 +0100

#90405 — Bug#1120831: Acknowledgement (eslinux-image-6.17.8+deb14-amd64: failed command: READ FPDMA QUEUED after boot)

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

Found in linux 6.17.11

I tested module_blacklist=nvidia,nvidia_modeset,nvidia_drm
with no effect.

#lsmod|grep nv

nvme 65536 4
nvme_core 249856 5 nvme
nvme_keyring 20480 1 nvme_core
nvme_auth 32768 1 nvme_core#

Sent with [Proton Mail](https://proton.me/mail/home) secure email.

[toc] | [next] | [standalone]

#90502

Control: tags -1 + moreinfo

Hi Wolf,

On Wed, Dec 10, 2025 at 05:12:57PM +0000, Wolf wrote:
> The error still appears with nvidia blacklisted.

Ok that is actually "great" now. Given you can reproduce the issue,
can you do the bisect work between the known good kernel and first bad
one? 

Do you need instructions on how to do it?

Regards,
Salvatore

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

#90545

Hi Wolf,

On Sat, Dec 20, 2025 at 08:46:43AM +0000, Wolf wrote:
> 
> On Thursday, 18 December 2025 at 21:18, Salvatore Bonaccorso <carnil@debian.org> wrote:
> 
> > 
> 
> > 
> 
> > Hi Wolf,
> > 
> 
> > On Wed, Dec 17, 2025 at 10:57:21AM +0000, Wolf wrote:
> > 
> 
> > > On Wednesday, 17 December 2025 at 11:57, Salvatore Bonaccorso carnil@debian.org wrote:
> > > 
> 
> > > > Control: tags -1 + moreinfo
> > > 
> 
> > > > Hi Wolf,
> > > 
> 
> > > > On Wed, Dec 10, 2025 at 05:12:57PM +0000, Wolf wrote:
> > > 
> 
> > > > > The error still appears with nvidia blacklisted.
> > > 
> 
> > > > Ok that is actually "great" now. Given you can reproduce the issue,
> > > > can you do the bisect work between the known good kernel and first bad
> > > > one?
> > > 
> 
> > > > Do you need instructions on how to do it?
> > > 
> 
> > > > Regards,
> > > > Salvatore
> > > 
> 
> > > Hi, Salvatore,
> > > 
> 
> > > Last good kernel I know is 6.16.12-1, which I'm using now (installed at 2025-10-13).
> > > 
> 
> > > All others are bad, starting with 6.17.6-1 (from 2025-11-02).
> > > 
> 
> > > I reported the bug only after I found 6.17.6-1, 6.17.7-1 and 6.17.8-1 bugged.
> > 
> 
> > 
> 
> > Is the issue present as well in 6.17.2-1~exp1 which was in
> > experimental? If yes then I suggest to do the following as next steps:
> > 
> 
> > Check upstream v6.16 directly and v6.17. The procedure can be as
> > follows:
> > 
> 
> > git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> > cd linux
> > git checkout v6.16
> > cp /boot/config-$(uname -r) .config
> > yes '' | make localmodconfig
> > make savedefconfig
> > mv defconfig arch/x86/configs/my_defconfig
> > 
> 
> > # test 6.16 to ensure this is "good"
> > make my_defconfig
> > make -j $(nproc) bindeb-pkg
> > ... install the resulting .deb package and confirm it successfully boots / problem does not exist
> > 
> 
> > # test 6.17 to ensure this is "bad"
> > git checkout v6.17
> > make my_defconfig
> > make -j $(nproc) bindeb-pkg
> > ... install the resulting .deb package and confirm it fails to boot / problem exists
> > 
> 
> > With that confirmed, the bisection can start:
> > 
> 
> > git bisect start
> > git bisect good v6.16
> > git bisect bad v6.17
> > 
> 
> > In each bisection step git checks out a state between the oldest
> > known-bad and the newest known-good commit. In each step test using:
> > 
> 
> > make my_defconfig
> > make -j $(nproc) bindeb-pkg
> > ... install, try to boot / verify if problem exists
> > 
> 
> > and if the problem is hit run:
> > 
> 
> > git bisect bad
> > 
> 
> > and if the problem doesn't trigger run:
> > 
> 
> > git bisect good
> > 
> 
> > . Please pay attention to always select the just built kernel for
> > booting, it won't always be the default kernel picked up by grub.
> > 
> 
> > Iterate until git announces to have identified the first bad commit.
> > 
> 
> > Then provide the output of
> > 
> 
> > git bisect log
> > 
> 
> > In the course of the bisection you might have to uninstall previous
> > kernels again to not exhaust the disk space in /boot. Also in the end
> > uninstall all self-built kernels again.
> > 
> 
> > This prodecure will lead us to a single commit ideally where the
> > problem starts. This would be needed to properly report the issue
> > upstream and together with upstream people understand what the problem
> > is.
> > 
> 
> > Regards,
> > Salvatore
> 
> Hi, Salvatore,
> 
> 6.17.2-1~exp1 is not yet available in SID.

No, it was a version in experimental, but those versions are
superseeded already, so the version need to be fetched from the
snapshot.debian.org service:

It can be fetched from https://snapshot.debian.org/package/linux-signed-amd64/6.17.2%2B1~exp1/

But once we have the more close range of versions the next step is the
bisect. I realize this is asking involving a couple of kernel
versions, but the above proceure should make it efficient enough.

Regards,
Salvatore

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

#90727

Hi,

On Wed, Jan 07, 2026 at 04:41:21AM +0000, Wolf wrote:
> Hi Salvatore,
> 
> I did a new test against v6.17-rc1, which is the first bugged version after v6.16.
> 
> root@gdeltop# git bisect log
> git bisect start
> # status: waiting for both good and bad commits
> # good: [038d61fd642278bab63ee8ef722c50d10ab01e8f] Linux 6.16
> git bisect good 038d61fd642278bab63ee8ef722c50d10ab01e8f
> # status: waiting for bad commit, 1 good commit known
> # bad: [8f5ae30d69d7543eee0d70083daf4de8fe15d585] Linux 6.17-rc1
> git bisect bad 8f5ae30d69d7543eee0d70083daf4de8fe15d585

Yes, but now according to the outlined procedure you need to continue
with the commits as described until you get the first bad commit.

Regards,
Salvatore

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

#90769

Hi,

So there is a similar (but not identical, and different disks) report
at https://bugzilla.kernel.org/show_bug.cgi?id=220693 pointing at the
same commit 9b8b84879d4a ("block: Increase BLK_DEF_MAX_SECTORS_CAP") .

That particular one was fixed with 2e9832713631 ("ata: libata-core:
Quirk DELLBOSS VD max_sectors").

Let's see if your report rings something to upstream.

Regards,
Salvatore

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

#90801

On Sunday, 11 January 2026 at 22:15, Salvatore Bonaccorso <carnil@debian.org> wrote:

>
>
> Hi,
>
> So there is a similar (but not identical, and different disks) report
> at https://bugzilla.kernel.org/show_bug.cgi?id=220693 pointing at the
> same commit 9b8b84879d4a ("block: Increase BLK_DEF_MAX_SECTORS_CAP") .
>
> That particular one was fixed with 2e9832713631 ("ata: libata-core:
> Quirk DELLBOSS VD max_sectors").
>
> Let's see if your report rings something to upstream.
>
> Regards,
> Salvatore

Hi,

Workaround: add the rule

ACTION=="add|change", SUBSYSTEM=="block", KERNEL=="sda", ATTR{queue/max_sectors_kb}="1280"

in /etc/udev/rules.d/99-sda-max-sectors.rules.

It works on linux/6.18.3+deb14-amd64.


Source: https://whoisnian.com/2025/12/23/%E4%BA%91%E6%9C%8D%E5%8A%A1%E5%99%A8%E7%B3%BB%E7%BB%9F%E6%9B%B4%E6%96%B0%E5%90%8E%E5%87%BA%E7%8E%B0-IO-error/


Regards,
Wolf

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

#90802

On Wednesday, 14 January 2026 at 12:14, Salvatore Bonaccorso <carnil@debian.org> wrote:

>
>
> Hi Wolf,
>
> On Wed, Jan 14, 2026 at 09:17:27AM +0000, Wolf wrote:
>
> > On Sunday, 11 January 2026 at 22:15, Salvatore Bonaccorso carnil@debian.org wrote:
> >
> > > Hi,
> > >
> > > So there is a similar (but not identical, and different disks) report
> > > at https://bugzilla.kernel.org/show_bug.cgi?id=220693 pointing at the
> > > same commit 9b8b84879d4a ("block: Increase BLK_DEF_MAX_SECTORS_CAP") .
> > >
> > > That particular one was fixed with 2e9832713631 ("ata: libata-core:
> > > Quirk DELLBOSS VD max_sectors").
> > >
> > > Let's see if your report rings something to upstream.
> > >
> > > Regards,
> > > Salvatore
> >
> > Hi,
> >
> > Workaround: add the rule
> >
> > ACTION=="add|change", SUBSYSTEM=="block", KERNEL=="sda", ATTR{queue/max_sectors_kb}="1280"
> >
> > in /etc/udev/rules.d/99-sda-max-sectors.rules.
> >
> > It works on linux/6.18.3+deb14-amd64.
>
>
> I think we will need a similar quirk as in the above bug for your
> device. Can you please test the following patch?
>
> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
> index 09d8c035fcdf..8434110a4962 100644
> --- a/drivers/ata/libata-core.c
> +++ b/drivers/ata/libata-core.c
> @@ -4108,6 +4108,7 @@ static const struct ata_dev_quirks_entry __ata_dev_quirks[] = {
> /
> { "LITEON CX1-JB-HP", NULL, ATA_QUIRK_MAX_SEC_1024 },
> { "LITEON EP1-", NULL, ATA_QUIRK_MAX_SEC_1024 },
> + { "INTEL SSDSC2KG480G8", "XCV10120", ATA_QUIRK_MAX_SEC_1024 },
>
> /
> * These devices time out with higher max sects.
>
> I will forward the bug upstream and keep you in the loop, but would be
>
> Regards,
> Salvatore

Hi,

The patch fixed the bug in linux/6.16.0-rc4+


Regards,
Wolf

[toc] | [prev] | [standalone]

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

csiph-web