Bug 1955536 - Request for USB hardware support (HP ProBook 450 G8) [NEEDINFO]
Summary: Request for USB hardware support (HP ProBook 450 G8)
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 34
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-04-30 10:42 UTC by jbbletterman
Modified: 2022-06-07 22:33 UTC (History)
21 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2022-06-07 22:33:00 UTC
Type: Bug
Embargoed:
jbbletterman: needinfo?


Attachments (Terms of Use)

Description jbbletterman 2021-04-30 10:42:05 UTC
Description of problem:
The HP ProBook 450 G8 works with Fedora 34 Workstation. However, we use Fedora kernels from Koji to create initrd's en vmlinuz's for PXE network boot images and USB mountable images. When doing this, using the latest kernels (5.11.1X), the PXE images work, but without audio. The USB images get kernel panics. The same images we generate work on 90% of our other systems, we know they are hardware/kernel specific.

The audio works for PXE when disabling DMIC detection with kernel parameters. We would like for this system to be properly supported for our clients, though.

Version-Release number of selected component (if applicable):
Fedora 34 Docker container
HP ProBook 450 G8
kernel 5.11.13, 5.11.16, 5.11.17

How reproducible:
100% of the time, when booting over USB.

Steps to Reproduce:
1. Generate initrd and vmlinuz using cpio and dracut.
2. Try to boot through USB.
3. Get a kernel panic.

Actual results:
Device never gets past a kernel panic. Therefore, there is no dmesg logging and kernel parameters can't be applied.

Expected results:
Boot properly into the kernel, without the need for extra parameters.

Additional info:
Our client owns hundreds of these systems, they would like to have our application working as soon as possible. There are other systems with similar issues (Intel NUC10i3FNH) but we would like to see this one fixed first.

Comment 1 Stephen Gallagher 2021-07-12 12:31:27 UTC
This was filed in the wrong project, so it hasn't been seen by the appropriate people. Reassigning to the kernel now (who will assign it to the USB subsystem team).

Comment 2 jbbletterman 2021-07-28 09:24:15 UTC
Hey guys, I was wondering if any developments had been made to improve USB support. 
I have a couple additional details that might help.


The PXE and USB images both contain the same kernel (vmlinuz) and ramdisk (initrd) files.
They are packed using CPIO and XZ.
Yet, results differ when booting over either USB or PXE. 
This is why I initially believed it to be a USB compatibility issue.
It may also depend on system settings, such as Legacy USB support in the UEFI/BIOS, but this has no effect for us.

However, one of our clients manually unpacked our initrd, and ran it on top of an Ext4 filesystem.
He claims that the images will boot after being unpacked, but with limited human interfacing (touchpad) support.
When we use identical Fedora kernels with official Fedora releases (Workstation 34), they will often boot just fine, as well.
The only vector between Fedora, our custom images and the unpacked Ext4 versions, is the use of initrd.
Our versions are built using Fedora containers with Docker.

All of this seems very strange to me, does anyone else have an idea?

Comment 3 Ben Cotton 2022-05-12 15:42:26 UTC
This message is a reminder that Fedora Linux 34 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '34'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 34 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 4 Ben Cotton 2022-06-07 22:33:00 UTC
Fedora Linux 34 entered end-of-life (EOL) status on 2022-06-07.

Fedora Linux 34 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.