• Bug#1101195: linux-image-6.1.0-32-amd64: Dell Venue 11 Pro 7139 fails t

    From Salvatore Bonaccorso@1:229/2 to Patrick Hibbs on Sun Jun 15 15:40:02 2025
    XPost: linux.debian.bugs.dist
    From: [email protected]

    Control: tags -1 + moreinfo

    Hi Patrick

    On Mon, Mar 24, 2025 at 12:34:34PM -0400, Patrick Hibbs wrote:
    Package: src:linux
    Version: 6.1.129-1
    Severity: normal
    X-Debbugs-Cc: [email protected]

    Dear Maintainer,

    The Dell Venue 11 Pro 7139 has a dock (Dell K10a (proprietary)) that is used to
    provide additional I/O to the device. Most of that functionality works out of the box under linux, with the exception of the dock's ethernet port. (A ASIX AX88179 USB 3.0 Gigabit Ethernet chipset embedded in the dock itself.)

    That port only works if the Venue is booted without being connected to the dock
    during POST / initial kernel start. Otherwise linux will fail to detect the dock's ethernet port at all, (no dmesg output at all), despite everything else
    on the dock working. No amount of unplugging and replugging in the dock will fix it. (Even unplugging the dock from it's own separate power source does nothing to resolve the issue.) In this case the only solution is a full shutdown and reboot. (With the dock disconnected from the Venue during the reboot.)

    This puts a lot of repetitive strain on the dock's spring loaded connector as it means that everytime linux reboots, the Venue must be removed from the dock
    and then reattached for the ethernet port to continue working.

    No amount of tweaking settings in the Venue's BIOS / firmware seems to fix it.
    (Fastboot disabled, UEFI Secure boot disabled, Disable Legacy ROMs, etc.) And there is no option in the BIOS / firmware to disable network booting entirely.
    The BIOS / Firmware just seems to be putting the USB NIC into an unknown state
    that linux can't recover from, if it detects the card during POST. A state that
    is unique to the dock NIC itself. Plugging in a different USB ethernet device (even one with a similar chipset) works as expected even if that different non-
    dock NIC is connected during POST.

    I've attached some dmesg output from both a boot with the dock connected and without (and what booting without looks like after linux is booted and the dock
    attached.)

    As I understand your description this is *not* a regression from a
    previously working 6.1.y version correct?

    You could test please newer kernel versions either from backports or
    directly from trixie/unstable and can you report back if those fix the
    problem?

    Regards,
    Salvatore

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Patrick Hibbs@1:229/2 to Salvatore Bonaccorso on Mon Jun 16 14:10:02 2025
    XPost: linux.debian.bugs.dist
    From: [email protected]

    This is a multi-part message in MIME format.
    Hi Salvatore

    As I understand your description this is *not* a regression from a
    previously working 6.1.y version correct?
    Yes, to my knowledge it's never worked correctly, and I've not seen anyone else report the issue.

    You could test please newer kernel versions either from backports or
    directly from trixie/unstable and can you report back if those fix the problem?
    Testing with the current trixie kernel it's still broken, with the same behavior as the original bug report.

    I've attached the updated kernel dmesg outputs.

    The "reconnection" logs are the dmesg output after the dock is unplugged from the machine, and then reconnected.
    Only the disconnected_at_boot log shows the NIC being detected.

    On 6/15/25 09:34, Salvatore Bonaccorso wrote:
    Control: tags -1 + moreinfo

    Hi Patrick

    On Mon, Mar 24, 2025 at 12:34:34PM -0400, Patrick Hibbs wrote:
    Package: src:linux
    Version: 6.1.129-1
    Severity: normal
    X-Debbugs-Cc: [email protected]

    Dear Maintainer,

    The Dell Venue 11 Pro 7139 has a dock (Dell K10a (proprietary)) that is used to
    provide additional I/O to the device. Most of that functionality works out of
    the box under linux, with the exception of the dock's ethernet port. (A ASIX >> AX88179 USB 3.0 Gigabit Ethernet chipset embedded in the dock itself.)

    That port only works if the Venue is booted without being connected to the dock
    during POST / initial kernel start. Otherwise linux will fail to detect the >> dock's ethernet port at all, (no dmesg output at all), despite everything else
    on the dock working. No amount of unplugging and replugging in the dock will >> fix it. (Even unplugging the dock from it's own separate power source does >> nothing to resolve the issue.) In this case the only solution is a full
    shutdown and reboot. (With the dock disconnected from the Venue during the >> reboot.)

    This puts a lot of repetitive strain on the dock's spring loaded connector as
    it means that everytime linux reboots, the Venue must be removed from the dock
    and then reattached for the ethernet port to continue working.

    No amount of tweaking settings in the Venue's BIOS / firmware seems to fix it.
    (Fastboot disabled, UEFI Secure boot disabled, Disable Legacy ROMs, etc.) And
    there is no option in the BIOS / firmware to disable network booting entirely.
    The BIOS / Firmware just seems to be putting the USB NIC into an unknown state
    that linux can't recover from, if it detects the card during POST. A state that
    is unique to the dock NIC itself. Plugging in a different USB ethernet device
    (even one with a similar chipset) works as expected even if that different non-
    dock NIC is connected during POST.

    I've attached some dmesg output from both a boot with the dock connected and >> without (and what booting without looks like after linux is booted and the dock
    attached.)
    As I understand your description this is *not* a regression from a
    previously working 6.1.y version correct?

    You could test please newer kernel versions either from backports or
    directly from trixie/unstable and can you report back if those fix the problem?

    Regards,
    Salvatore
    [SoupGate killed MIME-encoded file boot_with_dock_connected_at_boot_debian_trixie_16-6-2025.txt (81092 bytes)]
    [SoupGate killed MIME-encoded file boot_with_dock_connected_at_boot_after_reconnection_debian_trixie_16-6-�L@ (85193 bytes)]
    [SoupGate killed MIME-encoded file boot_with_dock_disconnected_at_boot_after_reconnection_debian_trixie_16CA@ (82243 bytes)]
    [SoupGate killed MIME-encoded file \boot_with_dock_disconnected_at_boot_after_reconnection_debian_trixif_1 (0 bytes)]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)