[Kernel-packages] [Bug 1864284] Re: r8152 init may take up to 40 seconds at initialization with Dell WD19/WD19DC during hotplug

[You-Sheng Yang]

** Changed in: hwe-next
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-oem in Ubuntu.
https://bugs.launchpad.net/bugs/1864284

Title:
  r8152 init may take up to 40 seconds at initialization with Dell
  WD19/WD19DC during hotplug

Status in HWE Next:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in linux-oem package in Ubuntu:
  Fix Released
Status in linux-oem-osp1 package in Ubuntu:
  Fix Released
Status in linux source package in Bionic:
  Fix Released
Status in linux-oem source package in Bionic:
  Fix Released
Status in linux-oem-osp1 source package in Bionic:
  Fix Released
Status in linux source package in Eoan:
  Fix Released
Status in linux source package in Focal:
  Fix Released

Bug description:
  [SRU Justification]

  [Impact]
  USB devices attached to Dell WD19/WD19DC USB Type-C dock take up to nearly one
  minutes to be ready for use.

  [Fix]
  r8152 driver init process involves several for-loops that each may take up to 
14
  seconds to exit when USB port reset occurs during hotplug. This is still
  reproducible with latest v5.6-rc mainline kernel although the fail rate is 
much
  lower since v5.5-rc7.

  [Test Case]
  Verified on Dell WD19DC.

  [Regression Potential]
  Low. Just to exit the loop early when it should have been.

  == original bug description ==

  Dell USB Type C docking WD19/WD19DC attaches additional peripherals
  as:

    /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
    |__ Port 1: Dev 11, If 0, Class=Hub, Driver=hub/4p, 5000M
    |__ Port 3: Dev 12, If 0, Class=Hub, Driver=hub/4p, 5000M
    |__ Port 4: Dev 13, If 0, Class=Vendor Specific Class, 
Driver=r8152, 5000M

  where usb 2-1-3 is a hub connecting all USB Type-A/C ports on the
  dock.

  When hotplugging such dock with additional usb devices already
  attached on it, the probing process may reset usb 2.1 port, therefore
  r8152 ethernet device is also reset. However, in r8152 driver there
  are several  for-loops that may take up to 14 seconds during the
  initialization for each in practice, and that has to be completed
  before USB may re-enumerate devices on the bus. As a result, devices
  attached to the dock will only be available after nearly 1 minute
  after the dock is plugged in.

    [  216.388290] [250] r8152 2-1.4:1.0: usb_probe_interface
    [  216.388292] [250] r8152 2-1.4:1.0: usb_probe_interface - got id
    [  258.830410] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): PHY 
not ready
    [  258.830460] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): 
Invalid header when reading pass-thru MAC addr
    [  258.830464] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): Get 
ether addr fail

  This can be reproduced on all kernel versions up to latest v5.6-rc2,
  but after v5.5-rc7 the reproduce rate is dramatically lower to 1/30 or
  so while it was around 1/2.

  The time consuming for-loops are at:
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L3206
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L5400
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L5537

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: linux-image-5.0.0-1037-oem-osp1 5.0.0-1037.42
  ProcVersionSignature: Ubuntu 5.0.0-1037.42-oem-osp1 5.0.21
  Uname: Linux 5.0.0-1037-oem-osp1 x86_64
  ApportVersion: 2.20.9-0ubuntu7.11
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  u  2014 F pulseaudio
  CurrentDesktop: ubuntu:GNOME
  Date: Sat Feb 22 04:07:20 2020
  DistributionChannelDescriptor:
   # This is the distribution channel descriptor for the OEM CDs
   # For more information see 
http://wiki.ubuntu.com/DistributionChannelDescriptor
   canonical-oem-somerville-bionic-amd64-20180608-47+beaver-hodor+X95
  InstallationDate: Installed on 2020-01-16 (37 days ago)
  InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 
20180608-09:38
  IwConfig:
   enp1s0no wireless extensions.

   enxd8d090035306  no wireless extensions.

   lono wireless extensions.
  MachineType: Dell Inc. Latitude 3310
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-1037-oem-osp1 
root=UUID=1ad036ce-aa29-4d5e-8692-d980d1a7140f ro "dyndbg=file drivers/usb/* 
+pt" log_buf_len=32M ignore_loglevel usbcore.quirks=0bda:0487:k
  RelatedPackageVersions:
   linux-restricted-modules-5.0.0-1037-oem-osp1 N/A
   linux-backports-modules-5.0.0-1037-oem-osp1  N/A
   linux-firmware   1.173.15
  SourcePackage: linux-oem-osp1
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 01/07/2020
  dmi.bios.vendor: Dell Inc.
 

[Kernel-packages] [Bug 1864284] Re: r8152 init may take up to 40 seconds at initialization with Dell WD19/WD19DC during hotplug

[Launchpad Bug Tracker]

This bug was fixed in the package linux - 4.15.0-96.97

---
linux (4.15.0-96.97) bionic; urgency=medium

  * CVE-2020-8834
- KVM: PPC: Book3S HV: Factor fake-suspend handling out of
  kvmppc_save/restore_tm
- KVM: PPC: Book3S PR: Move kvmppc_save_tm/kvmppc_restore_tm to separate 
file
- KVM: PPC: Book3S PR: Add guest MSR parameter for
  kvmppc_save_tm()/kvmppc_restore_tm()

linux (4.15.0-94.95) bionic; urgency=medium

  * bionic/linux: 4.15.0-94.95 -proposed tracker (LP: #1868984)

  * Missing wireless network interface after kernel 5.3.0-43 upgrade with eoan
(LP: #1868442)
- iwlwifi: mvm: Do not require PHY_SKU NVM section for 3168 devices

linux (4.15.0-93.94) bionic; urgency=medium

  * bionic/linux: 4.15.0-93.94 -proposed tracker (LP: #1868764)

  * quotactl04 from ubuntu_ltp_syscalls failed with B (LP: #1868665)
- ext4: fix mount failure with quota configured as module

linux (4.15.0-92.93) bionic; urgency=medium

  * bionic/linux: 4.15.0-92.93 -proposed tracker (LP: #1867272)

  * Packaging resync (LP: #1786013)
- [Packaging] resync getabis
- [Packaging] update helper scripts

  * Introduce the new NVIDIA 440 series, and add 5.4 Linux compatibility to the
340 and 390 series (LP: #1854485)
- [Packaging] NVIDIA -- add support for the 435 and the 440 series

  * Stop using get_scalar_status command in Dell AIO uart backlight driver
(LP: #1865402)
- SAUCE: platform/x86: dell-uart-backlight: add get_display_mode command

  * Bionic update: upstream stable patchset 2020-03-12 (LP: #1867194)
- RDMA/core: Fix locking in ib_uverbs_event_read
- gpio: zynq: Report gpio direction at boot
- arm64: ptrace: nofpsimd: Fail FP/SIMD regset operations
- KVM: arm: Fix DFSR setting for non-LPAE aarch32 guests
- KVM: arm: Make inject_abt32() inject an external abort instead
- mtd: onenand_base: Adjust indentation in onenand_read_ops_nolock
- mtd: sharpslpart: Fix unsigned comparison to zero
- padata: fix null pointer deref of pd->pinst
- Input: synaptics - switch T470s to RMI4 by default
- Input: synaptics - enable SMBus on ThinkPad L470
- Input: synaptics - remove the LEN0049 dmi id from topbuttonpad list
- ALSA: hda/realtek - Fix silent output on MSI-GL73
- ALSA: usb-audio: Apply sample rate quirk for Audioengine D1
- arm64: cpufeature: Set the FP/SIMD compat HWCAP bits properly
- ALSA: usb-audio: sound: usb: usb true/false for bool return type
- ext4: don't assume that mmp_nodename/bdevname have NUL
- ext4: fix support for inode sizes > 1024 bytes
- ext4: fix checksum errors with indexed dirs
- ext4: add cond_resched() to ext4_protect_reserved_inode
- ext4: improve explanation of a mount failure caused by a misconfigured
  kernel
- Btrfs: fix race between using extent maps and merging them
- btrfs: ref-verify: fix memory leaks
- btrfs: print message when tree-log replay starts
- btrfs: log message when rw remount is attempted with unclean tree-log
- arm64: ssbs: Fix context-switch when SSBS is present on all CPUs
- perf/x86/amd: Add missing L2 misses event spec to AMD Family 17h's event 
map
- IB/hfi1: Close window for pq and request coliding
- IB/rdmavt: Reset all QPs when the device is shut down
- RDMA/rxe: Fix soft lockup problem due to using tasklets in softirq
- RDMA/core: Fix protection fault in get_pkey_idx_qp_list
- s390/time: Fix clk type in get_tod_clock
- perf/x86/intel: Fix inaccurate period in context switch for auto-reload
- hwmon: (pmbus/ltc2978) Fix PMBus polling of MFR_COMMON definitions.
- jbd2: move the clearing of b_modified flag to the journal_unmap_buffer()
- jbd2: do not clear the BH_Mapped flag when forgetting a metadata buffer
- KVM: x86/mmu: Fix struct guest_walker arrays for 5-level paging

  * Bionic update: upstream stable patchset 2020-03-09 (LP: #1866678)
- kernel/module: Fix memleak in module_add_modinfo_attrs()
- media: iguanair: fix endpoint sanity check
- x86/cpu: Update cached HLE state on write to TSX_CTRL_CPUID_CLEAR
- iwlwifi: mvm: fix NVM check for 3168 devices
- sparc32: fix struct ipc64_perm type definition
- cls_rsvp: fix rsvp_policy
- gtp: use __GFP_NOWARN to avoid memalloc warning
- l2tp: Allow duplicate session creation with UDP
- net: hsr: fix possible NULL deref in hsr_handle_frame()
- net_sched: fix an OOB access in cls_tcindex
- bnxt_en: Fix TC queue mapping.
- tcp: clear tp->total_retrans in tcp_disconnect()
- tcp: clear tp->delivered in tcp_disconnect()
- tcp: clear tp->data_segs{in|out} in tcp_disconnect()
- tcp: clear tp->segs_{in|out} in tcp_disconnect()
- rxrpc: Fix insufficient receive notification generation
- rxrpc: Fix NULL pointer deref due to call->conn being cleared on 
disconnect
- media: uvcvideo: Avoid cyclic entity chains due to malformed USB 
descriptors
- mfd: 

[Kernel-packages] [Bug 1864284] Re: r8152 init may take up to 40 seconds at initialization with Dell WD19/WD19DC during hotplug

[Launchpad Bug Tracker]

This bug was fixed in the package linux - 5.3.0-46.38

---
linux (5.3.0-46.38) eoan; urgency=medium

  * eoan/linux: 5.3.0-43.36 -proposed tracker (LP: #1867301)

  * Fix AMD Stoney Ridge screen flickering under 4K resolution (LP: #1864005)
- iommu/amd: Disable IOMMU on Stoney Ridge systems

  * Allow BPF tracing under lockdown (LP: #1868626)
- Revert "UBUNTU: SAUCE: (efi-lockdown) Lock down kprobes"
- Revert "bpf: Restrict bpf when kernel lockdown is in confidentiality mode"

  * Missing wireless network interface after kernel 5.3.0-43 upgrade with eoan
(LP: #1868442)
- iwlwifi: mvm: Do not require PHY_SKU NVM section for 3168 devices

  * Packaging resync (LP: #1786013)
- [Packaging] resync getabis
- [Packaging] update helper scripts

  * iSCSI-target: Deleting a LUN hangs in the kernel (LP: #1862682)
- scsi: Revert "target/core: Inline transport_lun_remove_cmd()"

  * Stop using get_scalar_status command in Dell AIO uart backlight driver
(LP: #1865402)
- SAUCE: platform/x86: dell-uart-backlight: add get_display_mode command

  * Eoan update: upstream stable patchset 2020-03-11 (LP: #1867051)
- Revert "drm/sun4i: dsi: Change the start delay calculation"
- ovl: fix lseek overflow on 32bit
- kernel/module: Fix memleak in module_add_modinfo_attrs()
- media: iguanair: fix endpoint sanity check
- ocfs2: fix oops when writing cloned file
- x86/cpu: Update cached HLE state on write to TSX_CTRL_CPUID_CLEAR
- udf: Allow writing to 'Rewritable' partitions
- printk: fix exclusive_console replaying
- iwlwifi: mvm: fix NVM check for 3168 devices
- sparc32: fix struct ipc64_perm type definition
- cls_rsvp: fix rsvp_policy
- gtp: use __GFP_NOWARN to avoid memalloc warning
- l2tp: Allow duplicate session creation with UDP
- net: hsr: fix possible NULL deref in hsr_handle_frame()
- net_sched: fix an OOB access in cls_tcindex
- net: stmmac: Delete txtimer in suspend()
- bnxt_en: Fix TC queue mapping.
- tcp: clear tp->total_retrans in tcp_disconnect()
- tcp: clear tp->delivered in tcp_disconnect()
- tcp: clear tp->data_segs{in|out} in tcp_disconnect()
- tcp: clear tp->segs_{in|out} in tcp_disconnect()
- rxrpc: Fix use-after-free in rxrpc_put_local()
- rxrpc: Fix insufficient receive notification generation
- rxrpc: Fix missing active use pinning of rxrpc_local object
- rxrpc: Fix NULL pointer deref due to call->conn being cleared on 
disconnect
- media: uvcvideo: Avoid cyclic entity chains due to malformed USB 
descriptors
- mfd: dln2: More sanity checking for endpoints
- ipc/msg.c: consolidate all xxxctl_down() functions
- tracing: Fix sched switch start/stop refcount racy updates
- rcu: Avoid data-race in rcu_gp_fqs_check_wake()
- brcmfmac: Fix memory leak in brcmf_usbdev_qinit
- usb: typec: tcpci: mask event interrupts when remove driver
- usb: gadget: legacy: set max_speed to super-speed
- usb: gadget: f_ncm: Use atomic_t to track in-flight request
- usb: gadget: f_ecm: Use atomic_t to track in-flight request
- ALSA: usb-audio: Fix endianess in descriptor validation
- ALSA: dummy: Fix PCM format loop in proc output
- mm/memory_hotplug: fix remove_memory() lockdep splat
- mm: move_pages: report the number of non-attempted pages
- media/v4l2-core: set pages dirty upon releasing DMA buffers
- media: v4l2-core: compat: ignore native command codes
- media: v4l2-rect.h: fix v4l2_rect_map_inside() top/left adjustments
- lib/test_kasan.c: fix memory leak in kmalloc_oob_krealloc_more()
- irqdomain: Fix a memory leak in irq_domain_push_irq()
- platform/x86: intel_scu_ipc: Fix interrupt support
- ALSA: hda: Add Clevo W65_67SB the power_save blacklist
- KVM: arm64: Correct PSTATE on exception entry
- KVM: arm/arm64: Correct CPSR on exception entry
- KVM: arm/arm64: Correct AArch32 SPSR on exception entry
- KVM: arm64: Only sign-extend MMIO up to register width
- MIPS: fix indentation of the 'RELOCS' message
- MIPS: boot: fix typo in 'vmlinux.lzma.its' target
- s390/mm: fix dynamic pagetable upgrade for hugetlbfs
- powerpc/xmon: don't access ASDR in VMs
- powerpc/pseries: Advance pfn if section is not present in 
lmb_is_removable()
- smb3: fix signing verification of large reads
- PCI: tegra: Fix return value check of pm_runtime_get_sync()
- mmc: spi: Toggle SPI polarity, do not hardcode it
- ACPI: video: Do not export a non working backlight interface on MSI 
MS-7721
  boards
- ACPI / battery: Deal with design or full capacity being reported as -1
- ACPI / battery: Use design-cap for capacity calculations if full-cap is 
not
  available
- ACPI / battery: Deal better with neither design nor full capacity not 
being
  reported
- alarmtimer: Unregister wakeup source when module get fails
- ubifs: don't trigger 

[Kernel-packages] [Bug 1864284] Re: r8152 init may take up to 40 seconds at initialization with Dell WD19/WD19DC during hotplug

[You-Sheng Yang]

Verified linux version 5.3.0-43.36 from eoan-proposed.

** Tags removed: verification-needed-eoan
** Tags added: verification-done-eoan

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-oem in Ubuntu.
https://bugs.launchpad.net/bugs/1864284

Title:
  r8152 init may take up to 40 seconds at initialization with Dell
  WD19/WD19DC during hotplug

Status in HWE Next:
  New
Status in linux package in Ubuntu:
  Fix Released
Status in linux-oem package in Ubuntu:
  Fix Released
Status in linux-oem-osp1 package in Ubuntu:
  Fix Released
Status in linux source package in Bionic:
  Fix Committed
Status in linux-oem source package in Bionic:
  Fix Released
Status in linux-oem-osp1 source package in Bionic:
  Fix Released
Status in linux source package in Eoan:
  Fix Committed
Status in linux source package in Focal:
  Fix Released

Bug description:
  [SRU Justification]

  [Impact]
  USB devices attached to Dell WD19/WD19DC USB Type-C dock take up to nearly one
  minutes to be ready for use.

  [Fix]
  r8152 driver init process involves several for-loops that each may take up to 
14
  seconds to exit when USB port reset occurs during hotplug. This is still
  reproducible with latest v5.6-rc mainline kernel although the fail rate is 
much
  lower since v5.5-rc7.

  [Test Case]
  Verified on Dell WD19DC.

  [Regression Potential]
  Low. Just to exit the loop early when it should have been.

  == original bug description ==

  Dell USB Type C docking WD19/WD19DC attaches additional peripherals
  as:

    /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
    |__ Port 1: Dev 11, If 0, Class=Hub, Driver=hub/4p, 5000M
    |__ Port 3: Dev 12, If 0, Class=Hub, Driver=hub/4p, 5000M
    |__ Port 4: Dev 13, If 0, Class=Vendor Specific Class, 
Driver=r8152, 5000M

  where usb 2-1-3 is a hub connecting all USB Type-A/C ports on the
  dock.

  When hotplugging such dock with additional usb devices already
  attached on it, the probing process may reset usb 2.1 port, therefore
  r8152 ethernet device is also reset. However, in r8152 driver there
  are several  for-loops that may take up to 14 seconds during the
  initialization for each in practice, and that has to be completed
  before USB may re-enumerate devices on the bus. As a result, devices
  attached to the dock will only be available after nearly 1 minute
  after the dock is plugged in.

    [  216.388290] [250] r8152 2-1.4:1.0: usb_probe_interface
    [  216.388292] [250] r8152 2-1.4:1.0: usb_probe_interface - got id
    [  258.830410] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): PHY 
not ready
    [  258.830460] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): 
Invalid header when reading pass-thru MAC addr
    [  258.830464] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): Get 
ether addr fail

  This can be reproduced on all kernel versions up to latest v5.6-rc2,
  but after v5.5-rc7 the reproduce rate is dramatically lower to 1/30 or
  so while it was around 1/2.

  The time consuming for-loops are at:
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L3206
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L5400
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L5537

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: linux-image-5.0.0-1037-oem-osp1 5.0.0-1037.42
  ProcVersionSignature: Ubuntu 5.0.0-1037.42-oem-osp1 5.0.21
  Uname: Linux 5.0.0-1037-oem-osp1 x86_64
  ApportVersion: 2.20.9-0ubuntu7.11
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  u  2014 F pulseaudio
  CurrentDesktop: ubuntu:GNOME
  Date: Sat Feb 22 04:07:20 2020
  DistributionChannelDescriptor:
   # This is the distribution channel descriptor for the OEM CDs
   # For more information see 
http://wiki.ubuntu.com/DistributionChannelDescriptor
   canonical-oem-somerville-bionic-amd64-20180608-47+beaver-hodor+X95
  InstallationDate: Installed on 2020-01-16 (37 days ago)
  InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 
20180608-09:38
  IwConfig:
   enp1s0no wireless extensions.

   enxd8d090035306  no wireless extensions.

   lono wireless extensions.
  MachineType: Dell Inc. Latitude 3310
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-1037-oem-osp1 
root=UUID=1ad036ce-aa29-4d5e-8692-d980d1a7140f ro "dyndbg=file drivers/usb/* 
+pt" log_buf_len=32M ignore_loglevel usbcore.quirks=0bda:0487:k
  RelatedPackageVersions:
   linux-restricted-modules-5.0.0-1037-oem-osp1 N/A
   linux-backports-modules-5.0.0-1037-oem-osp1  N/A
   linux-firmware   1.173.15
  SourcePackage: linux-oem-osp1
  UpgradeStatus: No upgrade log present (probably 

[Kernel-packages] [Bug 1864284] Re: r8152 init may take up to 40 seconds at initialization with Dell WD19/WD19DC during hotplug

[Launchpad Bug Tracker]

This bug was fixed in the package linux-oem-osp1 - 5.0.0-1043.48

---
linux-oem-osp1 (5.0.0-1043.48) bionic; urgency=medium

  * bionic/linux-oem-osp1: 5.0.0-1043.48 -proposed tracker (LP:
#1867111)

  * All PS/2 ports on PS/2 Serial add-in bracket are not working after S3
(LP: #1866734)
- SAUCE: Input: i8042 - Fix the selftest retry logic

  * r8152 init may take up to 40 seconds at initialization with Dell WD19/WD19DC
during hotplug (LP: #1864284)
- UBUNTU SAUCE: r8151: check disconnect status after long sleep

  * Miscellaneous Ubuntu changes
- [Config] Bump the GCC version

 -- Timo Aaltonen   Thu, 12 Mar 2020
11:14:40 +0200

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-oem in Ubuntu.
https://bugs.launchpad.net/bugs/1864284

Title:
  r8152 init may take up to 40 seconds at initialization with Dell
  WD19/WD19DC during hotplug

Status in HWE Next:
  New
Status in linux package in Ubuntu:
  Fix Released
Status in linux-oem package in Ubuntu:
  Fix Released
Status in linux-oem-osp1 package in Ubuntu:
  Fix Released
Status in linux source package in Bionic:
  Fix Committed
Status in linux-oem source package in Bionic:
  Fix Released
Status in linux-oem-osp1 source package in Bionic:
  Fix Released
Status in linux source package in Eoan:
  Fix Committed
Status in linux source package in Focal:
  Fix Released

Bug description:
  [SRU Justification]

  [Impact]
  USB devices attached to Dell WD19/WD19DC USB Type-C dock take up to nearly one
  minutes to be ready for use.

  [Fix]
  r8152 driver init process involves several for-loops that each may take up to 
14
  seconds to exit when USB port reset occurs during hotplug. This is still
  reproducible with latest v5.6-rc mainline kernel although the fail rate is 
much
  lower since v5.5-rc7.

  [Test Case]
  Verified on Dell WD19DC.

  [Regression Potential]
  Low. Just to exit the loop early when it should have been.

  == original bug description ==

  Dell USB Type C docking WD19/WD19DC attaches additional peripherals
  as:

    /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
    |__ Port 1: Dev 11, If 0, Class=Hub, Driver=hub/4p, 5000M
    |__ Port 3: Dev 12, If 0, Class=Hub, Driver=hub/4p, 5000M
    |__ Port 4: Dev 13, If 0, Class=Vendor Specific Class, 
Driver=r8152, 5000M

  where usb 2-1-3 is a hub connecting all USB Type-A/C ports on the
  dock.

  When hotplugging such dock with additional usb devices already
  attached on it, the probing process may reset usb 2.1 port, therefore
  r8152 ethernet device is also reset. However, in r8152 driver there
  are several  for-loops that may take up to 14 seconds during the
  initialization for each in practice, and that has to be completed
  before USB may re-enumerate devices on the bus. As a result, devices
  attached to the dock will only be available after nearly 1 minute
  after the dock is plugged in.

    [  216.388290] [250] r8152 2-1.4:1.0: usb_probe_interface
    [  216.388292] [250] r8152 2-1.4:1.0: usb_probe_interface - got id
    [  258.830410] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): PHY 
not ready
    [  258.830460] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): 
Invalid header when reading pass-thru MAC addr
    [  258.830464] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): Get 
ether addr fail

  This can be reproduced on all kernel versions up to latest v5.6-rc2,
  but after v5.5-rc7 the reproduce rate is dramatically lower to 1/30 or
  so while it was around 1/2.

  The time consuming for-loops are at:
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L3206
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L5400
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L5537

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: linux-image-5.0.0-1037-oem-osp1 5.0.0-1037.42
  ProcVersionSignature: Ubuntu 5.0.0-1037.42-oem-osp1 5.0.21
  Uname: Linux 5.0.0-1037-oem-osp1 x86_64
  ApportVersion: 2.20.9-0ubuntu7.11
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  u  2014 F pulseaudio
  CurrentDesktop: ubuntu:GNOME
  Date: Sat Feb 22 04:07:20 2020
  DistributionChannelDescriptor:
   # This is the distribution channel descriptor for the OEM CDs
   # For more information see 
http://wiki.ubuntu.com/DistributionChannelDescriptor
   canonical-oem-somerville-bionic-amd64-20180608-47+beaver-hodor+X95
  InstallationDate: Installed on 2020-01-16 (37 days ago)
  InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 
20180608-09:38
  IwConfig:
   enp1s0no wireless extensions.

   enxd8d090035306  no wireless extensions.

   lono wireless extensions.
  MachineType: Dell Inc. Latitude 3310
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   

[Kernel-packages] [Bug 1864284] Re: r8152 init may take up to 40 seconds at initialization with Dell WD19/WD19DC during hotplug

[Launchpad Bug Tracker]

This bug was fixed in the package linux-oem - 4.15.0-1076.86

---
linux-oem (4.15.0-1076.86) bionic; urgency=medium

  * bionic/linux-oem: 4.15.0-1076.86 -proposed tracker (LP: #1865200)

  [ Ubuntu: 4.15.0-91.92 ]

  * bionic/linux: 4.15.0-91.92 -proposed tracker (LP: #1865109)
  * CVE-2020-2732
- KVM: x86: emulate RDPID
- KVM: nVMX: Don't emulate instructions in guest mode
- KVM: nVMX: Refactor IO bitmap checks into helper function
- KVM: nVMX: Check IO instruction VM-exit conditions

linux-oem (4.15.0-1075.85) bionic; urgency=medium

  * bionic/linux-oem: 4.15.0-1075.85 -proposed tracker (LP: #1864730)

  * Packaging resync (LP: #1786013)
- [Packaging] resync dkms-build and family

  [ Ubuntu: 4.15.0-90.91 ]

  * bionic/linux: 4.15.0-90.91 -proposed tracker (LP: #1864753)
  * dkms artifacts may expire from the pool (LP: #1850958)
- [Packaging] autoreconstruct -- manage executable debian files
- [packaging] handle downloads from the librarian better

  [ Ubuntu: 4.15.0-90.90 ]

  * bionic/linux: 4.15.0-90.90 -proposed tracker (LP: #1864753)
  * vm-segv from ubuntu_stress_smoke_test failed on B (LP: #1864063)
- Revert "apparmor: don't try to replace stale label in ptrace access check"

linux-oem (4.15.0-1074.84) bionic; urgency=medium

  * bionic/linux-oem: 4.15.0-1074.84 -proposed tracker (LP: #1863312)

  * Root can lift kernel lockdown via USB/IP (LP: #1861238)
- Revert "UBUNTU: SAUCE: (efi-lockdown) Add a SysRq option to lift kernel
  lockdown"

  * r8152 init may take up to 40 seconds at initialization with Dell WD19/WD19DC
during hotplug (LP: #1864284)
- SAUCE: r8151: check disconnect status after long sleep

  * alsa/hda/realtek: fix a mute led regression on Lenovo X1 Carbon
(LP: #1864576)
- SAUCE: ALSA: hda/realtek - Fix a regression for mute led on Lenovo Carbon 
X1

  [ Ubuntu: 4.15.0-89.89 ]

  * bionic/linux: 4.15.0-89.89 -proposed tracker (LP: #1863350)
  * [SRU][B/OEM-B] Fix multitouch support on some devices (LP: #1862567)
- HID: core: move the dynamic quirks handling in core
- HID: quirks: move the list of special devices into a quirk
- HID: core: move the list of ignored devices in hid-quirks.c
- HID: core: remove the absolute need of hid_have_special_driver[]
  * [linux] Patch to prevent possible data corruption (LP: #1848739)
- blk-mq: silence false positive warnings in hctx_unlock()
  * Add bpftool to linux-tools-common (LP: #1774815)
- tools/bpftool: fix bpftool build with bintutils >= 2.9
- bpftool: make libbfd optional
- [Debian] Remove binutils-dev build dependency
- [Debian] package bpftool in linux-tools-common
  * Root can lift kernel lockdown via USB/IP (LP: #1861238)
- Revert "UBUNTU: SAUCE: (efi-lockdown) Add a SysRq option to lift kernel
  lockdown"
  * [Bionic] i915 incomplete fix for CVE-2019-14615 (LP: #1862840) //
CVE-2020-8832
- drm/i915: Use same test for eviction and submitting kernel context
- drm/i915: Define an engine class enum for the uABI
- drm/i915: Force the switch to the i915->kernel_context
- drm/i915: Move GT powersaving init to i915_gem_init()
- drm/i915: Move intel_init_clock_gating() to i915_gem_init()
- drm/i915: Inline intel_modeset_gem_init()
- drm/i915: Mark the context state as dirty/written
- drm/i915: Record the default hw state after reset upon load
  * Bionic update: upstream stable patchset 2020-02-12 (LP: #1863019)
- xfs: Sanity check flags of Q_XQUOTARM call
- mfd: intel-lpss: Add default I2C device properties for Gemini Lake
- powerpc/archrandom: fix arch_get_random_seed_int()
- tipc: fix wrong timeout input for tipc_wait_for_cond()
- mt7601u: fix bbp version check in mt7601u_wait_bbp_ready
- crypto: sun4i-ss - fix big endian issues
- drm/sti: do not remove the drm_bridge that was never added
- drm/virtio: fix bounds check in virtio_gpu_cmd_get_capset()
- ALSA: hda: fix unused variable warning
- apparmor: don't try to replace stale label in ptrace access check
- PCI: iproc: Remove PAXC slot check to allow VF support
- drm/hisilicon: hibmc: Don't overwrite fb helper surface depth
- IB/rxe: replace kvfree with vfree
- IB/hfi1: Add mtu check for operational data VLs
- ALSA: usb-audio: update quirk for B PX to remove microphone
- staging: comedi: ni_mio_common: protect register write overflow
- pwm: lpss: Release runtime-pm reference from the driver's remove callback
- drm/sun4i: hdmi: Fix double flag assignation
- mlxsw: reg: QEEC: Add minimum shaper fields
- NTB: ntb_hw_idt: replace IS_ERR_OR_NULL with regular NULL checks
- pcrypt: use format specifier in kobject_add
- exportfs: fix 'passing zero to ERR_PTR()' warning
- drm/dp_mst: Skip validating ports during destruction, just ref
- net: phy: Fix not to call phy_resume() if PHY is not attached
- IB/rxe: Fix incorrect cache cleanup in error flow

[Kernel-packages] [Bug 1864284] Re: r8152 init may take up to 40 seconds at initialization with Dell WD19/WD19DC during hotplug

[Launchpad Bug Tracker]

This bug was fixed in the package linux-oem-osp1 - 5.0.0-1043.48

---
linux-oem-osp1 (5.0.0-1043.48) bionic; urgency=medium

  * bionic/linux-oem-osp1: 5.0.0-1043.48 -proposed tracker (LP:
#1867111)

  * All PS/2 ports on PS/2 Serial add-in bracket are not working after S3
(LP: #1866734)
- SAUCE: Input: i8042 - Fix the selftest retry logic

  * r8152 init may take up to 40 seconds at initialization with Dell WD19/WD19DC
during hotplug (LP: #1864284)
- UBUNTU SAUCE: r8151: check disconnect status after long sleep

  * Miscellaneous Ubuntu changes
- [Config] Bump the GCC version

 -- Timo Aaltonen   Thu, 12 Mar 2020
11:14:40 +0200

** Changed in: linux-oem-osp1 (Ubuntu Bionic)
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-oem in Ubuntu.
https://bugs.launchpad.net/bugs/1864284

Title:
  r8152 init may take up to 40 seconds at initialization with Dell
  WD19/WD19DC during hotplug

Status in HWE Next:
  New
Status in linux package in Ubuntu:
  Fix Released
Status in linux-oem package in Ubuntu:
  New
Status in linux-oem-osp1 package in Ubuntu:
  New
Status in linux source package in Bionic:
  Fix Committed
Status in linux-oem source package in Bionic:
  Fix Released
Status in linux-oem-osp1 source package in Bionic:
  Fix Released
Status in linux source package in Eoan:
  Fix Committed
Status in linux source package in Focal:
  Fix Released

Bug description:
  [SRU Justification]

  [Impact]
  USB devices attached to Dell WD19/WD19DC USB Type-C dock take up to nearly one
  minutes to be ready for use.

  [Fix]
  r8152 driver init process involves several for-loops that each may take up to 
14
  seconds to exit when USB port reset occurs during hotplug. This is still
  reproducible with latest v5.6-rc mainline kernel although the fail rate is 
much
  lower since v5.5-rc7.

  [Test Case]
  Verified on Dell WD19DC.

  [Regression Potential]
  Low. Just to exit the loop early when it should have been.

  == original bug description ==

  Dell USB Type C docking WD19/WD19DC attaches additional peripherals
  as:

    /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
    |__ Port 1: Dev 11, If 0, Class=Hub, Driver=hub/4p, 5000M
    |__ Port 3: Dev 12, If 0, Class=Hub, Driver=hub/4p, 5000M
    |__ Port 4: Dev 13, If 0, Class=Vendor Specific Class, 
Driver=r8152, 5000M

  where usb 2-1-3 is a hub connecting all USB Type-A/C ports on the
  dock.

  When hotplugging such dock with additional usb devices already
  attached on it, the probing process may reset usb 2.1 port, therefore
  r8152 ethernet device is also reset. However, in r8152 driver there
  are several  for-loops that may take up to 14 seconds during the
  initialization for each in practice, and that has to be completed
  before USB may re-enumerate devices on the bus. As a result, devices
  attached to the dock will only be available after nearly 1 minute
  after the dock is plugged in.

    [  216.388290] [250] r8152 2-1.4:1.0: usb_probe_interface
    [  216.388292] [250] r8152 2-1.4:1.0: usb_probe_interface - got id
    [  258.830410] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): PHY 
not ready
    [  258.830460] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): 
Invalid header when reading pass-thru MAC addr
    [  258.830464] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): Get 
ether addr fail

  This can be reproduced on all kernel versions up to latest v5.6-rc2,
  but after v5.5-rc7 the reproduce rate is dramatically lower to 1/30 or
  so while it was around 1/2.

  The time consuming for-loops are at:
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L3206
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L5400
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L5537

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: linux-image-5.0.0-1037-oem-osp1 5.0.0-1037.42
  ProcVersionSignature: Ubuntu 5.0.0-1037.42-oem-osp1 5.0.21
  Uname: Linux 5.0.0-1037-oem-osp1 x86_64
  ApportVersion: 2.20.9-0ubuntu7.11
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  u  2014 F pulseaudio
  CurrentDesktop: ubuntu:GNOME
  Date: Sat Feb 22 04:07:20 2020
  DistributionChannelDescriptor:
   # This is the distribution channel descriptor for the OEM CDs
   # For more information see 
http://wiki.ubuntu.com/DistributionChannelDescriptor
   canonical-oem-somerville-bionic-amd64-20180608-47+beaver-hodor+X95
  InstallationDate: Installed on 2020-01-16 (37 days ago)
  InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 
20180608-09:38
  IwConfig:
   enp1s0no wireless extensions.

   enxd8d090035306  no wireless extensions.

   lono wireless extensions.
  MachineType: Dell Inc. Latitude 3310
  ProcEnviron:
   

[Kernel-packages] [Bug 1864284] Re: r8152 init may take up to 40 seconds at initialization with Dell WD19/WD19DC during hotplug

[Ubuntu Kernel Bot]

This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
eoan' to 'verification-done-eoan'. If the problem still exists, change
the tag 'verification-needed-eoan' to 'verification-failed-eoan'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-eoan

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-oem in Ubuntu.
https://bugs.launchpad.net/bugs/1864284

Title:
  r8152 init may take up to 40 seconds at initialization with Dell
  WD19/WD19DC during hotplug

Status in HWE Next:
  New
Status in linux package in Ubuntu:
  Fix Released
Status in linux-oem package in Ubuntu:
  New
Status in linux-oem-osp1 package in Ubuntu:
  New
Status in linux source package in Bionic:
  Fix Committed
Status in linux-oem source package in Bionic:
  Fix Released
Status in linux-oem-osp1 source package in Bionic:
  Fix Released
Status in linux source package in Eoan:
  Fix Committed
Status in linux source package in Focal:
  Fix Released

Bug description:
  [SRU Justification]

  [Impact]
  USB devices attached to Dell WD19/WD19DC USB Type-C dock take up to nearly one
  minutes to be ready for use.

  [Fix]
  r8152 driver init process involves several for-loops that each may take up to 
14
  seconds to exit when USB port reset occurs during hotplug. This is still
  reproducible with latest v5.6-rc mainline kernel although the fail rate is 
much
  lower since v5.5-rc7.

  [Test Case]
  Verified on Dell WD19DC.

  [Regression Potential]
  Low. Just to exit the loop early when it should have been.

  == original bug description ==

  Dell USB Type C docking WD19/WD19DC attaches additional peripherals
  as:

    /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
    |__ Port 1: Dev 11, If 0, Class=Hub, Driver=hub/4p, 5000M
    |__ Port 3: Dev 12, If 0, Class=Hub, Driver=hub/4p, 5000M
    |__ Port 4: Dev 13, If 0, Class=Vendor Specific Class, 
Driver=r8152, 5000M

  where usb 2-1-3 is a hub connecting all USB Type-A/C ports on the
  dock.

  When hotplugging such dock with additional usb devices already
  attached on it, the probing process may reset usb 2.1 port, therefore
  r8152 ethernet device is also reset. However, in r8152 driver there
  are several  for-loops that may take up to 14 seconds during the
  initialization for each in practice, and that has to be completed
  before USB may re-enumerate devices on the bus. As a result, devices
  attached to the dock will only be available after nearly 1 minute
  after the dock is plugged in.

    [  216.388290] [250] r8152 2-1.4:1.0: usb_probe_interface
    [  216.388292] [250] r8152 2-1.4:1.0: usb_probe_interface - got id
    [  258.830410] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): PHY 
not ready
    [  258.830460] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): 
Invalid header when reading pass-thru MAC addr
    [  258.830464] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): Get 
ether addr fail

  This can be reproduced on all kernel versions up to latest v5.6-rc2,
  but after v5.5-rc7 the reproduce rate is dramatically lower to 1/30 or
  so while it was around 1/2.

  The time consuming for-loops are at:
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L3206
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L5400
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L5537

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: linux-image-5.0.0-1037-oem-osp1 5.0.0-1037.42
  ProcVersionSignature: Ubuntu 5.0.0-1037.42-oem-osp1 5.0.21
  Uname: Linux 5.0.0-1037-oem-osp1 x86_64
  ApportVersion: 2.20.9-0ubuntu7.11
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  u  2014 F pulseaudio
  CurrentDesktop: ubuntu:GNOME
  Date: Sat Feb 22 04:07:20 2020
  DistributionChannelDescriptor:
   # This is the distribution channel descriptor for the OEM CDs
   # For more information see 
http://wiki.ubuntu.com/DistributionChannelDescriptor
   canonical-oem-somerville-bionic-amd64-20180608-47+beaver-hodor+X95
  InstallationDate: Installed on 2020-01-16 (37 days ago)
  InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 
20180608-09:38
  IwConfig:
   enp1s0no wireless extensions.

   enxd8d090035306  no wireless extensions.

   lono wireless extensions.
  MachineType: Dell Inc. Latitude 3310
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 inteldrmfb

[Kernel-packages] [Bug 1864284] Re: r8152 init may take up to 40 seconds at initialization with Dell WD19/WD19DC during hotplug

[Launchpad Bug Tracker]

This bug was fixed in the package linux-oem - 4.15.0-1076.86

---
linux-oem (4.15.0-1076.86) bionic; urgency=medium

  * bionic/linux-oem: 4.15.0-1076.86 -proposed tracker (LP: #1865200)

  [ Ubuntu: 4.15.0-91.92 ]

  * bionic/linux: 4.15.0-91.92 -proposed tracker (LP: #1865109)
  * CVE-2020-2732
- KVM: x86: emulate RDPID
- KVM: nVMX: Don't emulate instructions in guest mode
- KVM: nVMX: Refactor IO bitmap checks into helper function
- KVM: nVMX: Check IO instruction VM-exit conditions

linux-oem (4.15.0-1075.85) bionic; urgency=medium

  * bionic/linux-oem: 4.15.0-1075.85 -proposed tracker (LP: #1864730)

  * Packaging resync (LP: #1786013)
- [Packaging] resync dkms-build and family

  [ Ubuntu: 4.15.0-90.91 ]

  * bionic/linux: 4.15.0-90.91 -proposed tracker (LP: #1864753)
  * dkms artifacts may expire from the pool (LP: #1850958)
- [Packaging] autoreconstruct -- manage executable debian files
- [packaging] handle downloads from the librarian better

  [ Ubuntu: 4.15.0-90.90 ]

  * bionic/linux: 4.15.0-90.90 -proposed tracker (LP: #1864753)
  * vm-segv from ubuntu_stress_smoke_test failed on B (LP: #1864063)
- Revert "apparmor: don't try to replace stale label in ptrace access check"

linux-oem (4.15.0-1074.84) bionic; urgency=medium

  * bionic/linux-oem: 4.15.0-1074.84 -proposed tracker (LP: #1863312)

  * Root can lift kernel lockdown via USB/IP (LP: #1861238)
- Revert "UBUNTU: SAUCE: (efi-lockdown) Add a SysRq option to lift kernel
  lockdown"

  * r8152 init may take up to 40 seconds at initialization with Dell WD19/WD19DC
during hotplug (LP: #1864284)
- SAUCE: r8151: check disconnect status after long sleep

  * alsa/hda/realtek: fix a mute led regression on Lenovo X1 Carbon
(LP: #1864576)
- SAUCE: ALSA: hda/realtek - Fix a regression for mute led on Lenovo Carbon 
X1

  [ Ubuntu: 4.15.0-89.89 ]

  * bionic/linux: 4.15.0-89.89 -proposed tracker (LP: #1863350)
  * [SRU][B/OEM-B] Fix multitouch support on some devices (LP: #1862567)
- HID: core: move the dynamic quirks handling in core
- HID: quirks: move the list of special devices into a quirk
- HID: core: move the list of ignored devices in hid-quirks.c
- HID: core: remove the absolute need of hid_have_special_driver[]
  * [linux] Patch to prevent possible data corruption (LP: #1848739)
- blk-mq: silence false positive warnings in hctx_unlock()
  * Add bpftool to linux-tools-common (LP: #1774815)
- tools/bpftool: fix bpftool build with bintutils >= 2.9
- bpftool: make libbfd optional
- [Debian] Remove binutils-dev build dependency
- [Debian] package bpftool in linux-tools-common
  * Root can lift kernel lockdown via USB/IP (LP: #1861238)
- Revert "UBUNTU: SAUCE: (efi-lockdown) Add a SysRq option to lift kernel
  lockdown"
  * [Bionic] i915 incomplete fix for CVE-2019-14615 (LP: #1862840) //
CVE-2020-8832
- drm/i915: Use same test for eviction and submitting kernel context
- drm/i915: Define an engine class enum for the uABI
- drm/i915: Force the switch to the i915->kernel_context
- drm/i915: Move GT powersaving init to i915_gem_init()
- drm/i915: Move intel_init_clock_gating() to i915_gem_init()
- drm/i915: Inline intel_modeset_gem_init()
- drm/i915: Mark the context state as dirty/written
- drm/i915: Record the default hw state after reset upon load
  * Bionic update: upstream stable patchset 2020-02-12 (LP: #1863019)
- xfs: Sanity check flags of Q_XQUOTARM call
- mfd: intel-lpss: Add default I2C device properties for Gemini Lake
- powerpc/archrandom: fix arch_get_random_seed_int()
- tipc: fix wrong timeout input for tipc_wait_for_cond()
- mt7601u: fix bbp version check in mt7601u_wait_bbp_ready
- crypto: sun4i-ss - fix big endian issues
- drm/sti: do not remove the drm_bridge that was never added
- drm/virtio: fix bounds check in virtio_gpu_cmd_get_capset()
- ALSA: hda: fix unused variable warning
- apparmor: don't try to replace stale label in ptrace access check
- PCI: iproc: Remove PAXC slot check to allow VF support
- drm/hisilicon: hibmc: Don't overwrite fb helper surface depth
- IB/rxe: replace kvfree with vfree
- IB/hfi1: Add mtu check for operational data VLs
- ALSA: usb-audio: update quirk for B PX to remove microphone
- staging: comedi: ni_mio_common: protect register write overflow
- pwm: lpss: Release runtime-pm reference from the driver's remove callback
- drm/sun4i: hdmi: Fix double flag assignation
- mlxsw: reg: QEEC: Add minimum shaper fields
- NTB: ntb_hw_idt: replace IS_ERR_OR_NULL with regular NULL checks
- pcrypt: use format specifier in kobject_add
- exportfs: fix 'passing zero to ERR_PTR()' warning
- drm/dp_mst: Skip validating ports during destruction, just ref
- net: phy: Fix not to call phy_resume() if PHY is not attached
- IB/rxe: Fix incorrect cache cleanup in error flow

[Kernel-packages] [Bug 1864284] Re: r8152 init may take up to 40 seconds at initialization with Dell WD19/WD19DC during hotplug

[Launchpad Bug Tracker]

This bug was fixed in the package linux - 5.4.0-18.22

---
linux (5.4.0-18.22) focal; urgency=medium

  * focal/linux: 5.4.0-18.22 -proposed tracker (LP: #1866488)

  * Packaging resync (LP: #1786013)
- [Packaging] resync getabis
- [Packaging] update helper scripts

  * Add sysfs attribute to show remapped NVMe (LP: #1863621)
- SAUCE: ata: ahci: Add sysfs attribute to show remapped NVMe device count

  * [20.04 FEAT] Compression improvements in Linux kernel (LP: #1830208)
- lib/zlib: add s390 hardware support for kernel zlib_deflate
- s390/boot: rename HEAP_SIZE due to name collision
- lib/zlib: add s390 hardware support for kernel zlib_inflate
- s390/boot: add dfltcc= kernel command line parameter
- lib/zlib: add zlib_deflate_dfltcc_enabled() function
- btrfs: use larger zlib buffer for s390 hardware compression
- [Config] Introducing s390x specific kernel config option 
CONFIG_ZLIB_DFLTCC

  * [UBUNTU 20.04] s390x/pci: increase CONFIG_PCI_NR_FUNCTIONS to 512 in kernel
config (LP: #1866056)
- [Config] Increase CONFIG_PCI_NR_FUNCTIONS from 64 to 512 starting with 
focal
  on s390x

  * CONFIG_IP_MROUTE_MULTIPLE_TABLES is not set (LP: #1865332)
- [Config] CONFIG_IP_MROUTE_MULTIPLE_TABLES=y

  * Dell XPS 13 9300 Intel 1650S wifi [34f0:1651] fails to load firmware
(LP: #1865962)
- iwlwifi: remove IWL_DEVICE_22560/IWL_DEVICE_FAMILY_22560
- iwlwifi: 22000: fix some indentation
- iwlwifi: pcie: rx: use rxq queue_size instead of constant
- iwlwifi: allocate more receive buffers for HE devices
- iwlwifi: remove some outdated iwl22000 configurations
- iwlwifi: assume the driver_data is a trans_cfg, but allow full cfg

  * [FOCAL][REGRESSION] Intel Gen 9 brightness cannot be controlled
(LP: #1861521)
- Revert "USUNTU: SAUCE: drm/i915: Force DPCD backlight mode on Dell 
Precision
  4K sku"
- Revert "UBUNTU: SAUCE: drm/i915: Force DPCD backlight mode on X1 Extreme 
2nd
  Gen 4K AMOLED panel"
- SAUCE: drm/dp: Introduce EDID-based quirks
- SAUCE: drm/i915: Force DPCD backlight mode on X1 Extreme 2nd Gen 4K AMOLED
  panel
- SAUCE: drm/i915: Force DPCD backlight mode for some Dell CML 2020 panels

  * [20.04 FEAT] Enable proper kprobes on ftrace support (LP: #1865858)
- s390/ftrace: save traced function caller
- s390: support KPROBES_ON_FTRACE

  * alsa/sof: load different firmware on different platforms (LP: #1857409)
- ASoC: SOF: Intel: hda: use fallback for firmware name
- ASoC: Intel: acpi-match: split CNL tables in three
- ASoC: SOF: Intel: Fix CFL and CML FW nocodec binary names.

  * [UBUNTU 20.04] Enable CONFIG_NET_SWITCHDEV in kernel config for s390x
starting with focal (LP: #1865452)
- [Config] Enable CONFIG_NET_SWITCHDEV in kernel config for s390x starting
  with focal

  * Focal update: v5.4.24 upstream stable release (LP: #1866333)
- io_uring: grab ->fs as part of async offload
- EDAC: skx_common: downgrade message importance on missing PCI device
- net: dsa: b53: Ensure the default VID is untagged
- net: fib_rules: Correctly set table field when table number exceeds 8 bits
- net: macb: ensure interface is not suspended on at91rm9200
- net: mscc: fix in frame extraction
- net: phy: restore mdio regs in the iproc mdio driver
- net: sched: correct flower port blocking
- net/tls: Fix to avoid gettig invalid tls record
- nfc: pn544: Fix occasional HW initialization failure
- qede: Fix race between rdma destroy workqueue and link change event
- Revert "net: dev: introduce support for sch BYPASS for lockless qdisc"
- udp: rehash on disconnect
- sctp: move the format error check out of __sctp_sf_do_9_1_abort
- bnxt_en: Improve device shutdown method.
- bnxt_en: Issue PCIe FLR in kdump kernel to cleanup pending DMAs.
- bonding: add missing netdev_update_lockdep_key()
- net: export netdev_next_lower_dev_rcu()
- bonding: fix lockdep warning in bond_get_stats()
- ipv6: Fix route replacement with dev-only route
- ipv6: Fix nlmsg_flags when splitting a multipath route
- ipmi:ssif: Handle a possible NULL pointer reference
- drm/msm: Set dma maximum segment size for mdss
- sched/core: Don't skip remote tick for idle CPUs
- timers/nohz: Update NOHZ load in remote tick
- sched/fair: Prevent unlimited runtime on throttled group
- dax: pass NOWAIT flag to iomap_apply
- mac80211: consider more elements in parsing CRC
- cfg80211: check wiphy driver existence for drvinfo report
- s390/zcrypt: fix card and queue total counter wrap
- qmi_wwan: re-add DW5821e pre-production variant
- qmi_wwan: unconditionally reject 2 ep interfaces
- NFSv4: Fix races between open and dentry revalidation
- perf/smmuv3: Use platform_get_irq_optional() for wired interrupt
- perf/x86/intel: Add Elkhart Lake support
- perf/x86/cstate: Add Tremont 

[Kernel-packages] [Bug 1864284] Re: r8152 init may take up to 40 seconds at initialization with Dell WD19/WD19DC during hotplug

[You-Sheng Yang]

Verified linux version 5.4.0-18.22 from focal-proposed.

** Tags removed: verification-needed-bionic verification-needed-focal
** Tags added: verification-done-bionic verification-done-focal

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-oem in Ubuntu.
https://bugs.launchpad.net/bugs/1864284

Title:
  r8152 init may take up to 40 seconds at initialization with Dell
  WD19/WD19DC during hotplug

Status in HWE Next:
  New
Status in linux package in Ubuntu:
  In Progress
Status in linux-oem package in Ubuntu:
  New
Status in linux-oem-osp1 package in Ubuntu:
  New
Status in linux source package in Bionic:
  Fix Committed
Status in linux-oem source package in Bionic:
  Fix Committed
Status in linux-oem-osp1 source package in Bionic:
  Fix Committed
Status in linux source package in Eoan:
  Fix Committed
Status in linux source package in Focal:
  In Progress

Bug description:
  [SRU Justification]

  [Impact]
  USB devices attached to Dell WD19/WD19DC USB Type-C dock take up to nearly one
  minutes to be ready for use.

  [Fix]
  r8152 driver init process involves several for-loops that each may take up to 
14
  seconds to exit when USB port reset occurs during hotplug. This is still
  reproducible with latest v5.6-rc mainline kernel although the fail rate is 
much
  lower since v5.5-rc7.

  [Test Case]
  Verified on Dell WD19DC.

  [Regression Potential]
  Low. Just to exit the loop early when it should have been.

  == original bug description ==

  Dell USB Type C docking WD19/WD19DC attaches additional peripherals
  as:

    /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
    |__ Port 1: Dev 11, If 0, Class=Hub, Driver=hub/4p, 5000M
    |__ Port 3: Dev 12, If 0, Class=Hub, Driver=hub/4p, 5000M
    |__ Port 4: Dev 13, If 0, Class=Vendor Specific Class, 
Driver=r8152, 5000M

  where usb 2-1-3 is a hub connecting all USB Type-A/C ports on the
  dock.

  When hotplugging such dock with additional usb devices already
  attached on it, the probing process may reset usb 2.1 port, therefore
  r8152 ethernet device is also reset. However, in r8152 driver there
  are several  for-loops that may take up to 14 seconds during the
  initialization for each in practice, and that has to be completed
  before USB may re-enumerate devices on the bus. As a result, devices
  attached to the dock will only be available after nearly 1 minute
  after the dock is plugged in.

    [  216.388290] [250] r8152 2-1.4:1.0: usb_probe_interface
    [  216.388292] [250] r8152 2-1.4:1.0: usb_probe_interface - got id
    [  258.830410] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): PHY 
not ready
    [  258.830460] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): 
Invalid header when reading pass-thru MAC addr
    [  258.830464] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): Get 
ether addr fail

  This can be reproduced on all kernel versions up to latest v5.6-rc2,
  but after v5.5-rc7 the reproduce rate is dramatically lower to 1/30 or
  so while it was around 1/2.

  The time consuming for-loops are at:
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L3206
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L5400
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L5537

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: linux-image-5.0.0-1037-oem-osp1 5.0.0-1037.42
  ProcVersionSignature: Ubuntu 5.0.0-1037.42-oem-osp1 5.0.21
  Uname: Linux 5.0.0-1037-oem-osp1 x86_64
  ApportVersion: 2.20.9-0ubuntu7.11
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  u  2014 F pulseaudio
  CurrentDesktop: ubuntu:GNOME
  Date: Sat Feb 22 04:07:20 2020
  DistributionChannelDescriptor:
   # This is the distribution channel descriptor for the OEM CDs
   # For more information see 
http://wiki.ubuntu.com/DistributionChannelDescriptor
   canonical-oem-somerville-bionic-amd64-20180608-47+beaver-hodor+X95
  InstallationDate: Installed on 2020-01-16 (37 days ago)
  InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 
20180608-09:38
  IwConfig:
   enp1s0no wireless extensions.

   enxd8d090035306  no wireless extensions.

   lono wireless extensions.
  MachineType: Dell Inc. Latitude 3310
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-1037-oem-osp1 
root=UUID=1ad036ce-aa29-4d5e-8692-d980d1a7140f ro "dyndbg=file drivers/usb/* 
+pt" log_buf_len=32M ignore_loglevel usbcore.quirks=0bda:0487:k
  RelatedPackageVersions:
   linux-restricted-modules-5.0.0-1037-oem-osp1 N/A
   linux-backports-modules-5.0.0-1037-oem-osp1  N/A
   linux-firmware   1.173.15
  SourcePackage: linux-oem-osp1
  

[Kernel-packages] [Bug 1864284] Re: r8152 init may take up to 40 seconds at initialization with Dell WD19/WD19DC during hotplug

[You-Sheng Yang]

Verified linux-oem-osp1 version 5.0.0-1043, linux-oem version
4.15.0-1076 from bionic-proposed.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-oem in Ubuntu.
https://bugs.launchpad.net/bugs/1864284

Title:
  r8152 init may take up to 40 seconds at initialization with Dell
  WD19/WD19DC during hotplug

Status in HWE Next:
  New
Status in linux package in Ubuntu:
  In Progress
Status in linux-oem package in Ubuntu:
  New
Status in linux-oem-osp1 package in Ubuntu:
  New
Status in linux source package in Bionic:
  Fix Committed
Status in linux-oem source package in Bionic:
  Fix Committed
Status in linux-oem-osp1 source package in Bionic:
  Fix Committed
Status in linux source package in Eoan:
  Fix Committed
Status in linux source package in Focal:
  In Progress

Bug description:
  [SRU Justification]

  [Impact]
  USB devices attached to Dell WD19/WD19DC USB Type-C dock take up to nearly one
  minutes to be ready for use.

  [Fix]
  r8152 driver init process involves several for-loops that each may take up to 
14
  seconds to exit when USB port reset occurs during hotplug. This is still
  reproducible with latest v5.6-rc mainline kernel although the fail rate is 
much
  lower since v5.5-rc7.

  [Test Case]
  Verified on Dell WD19DC.

  [Regression Potential]
  Low. Just to exit the loop early when it should have been.

  == original bug description ==

  Dell USB Type C docking WD19/WD19DC attaches additional peripherals
  as:

    /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
    |__ Port 1: Dev 11, If 0, Class=Hub, Driver=hub/4p, 5000M
    |__ Port 3: Dev 12, If 0, Class=Hub, Driver=hub/4p, 5000M
    |__ Port 4: Dev 13, If 0, Class=Vendor Specific Class, 
Driver=r8152, 5000M

  where usb 2-1-3 is a hub connecting all USB Type-A/C ports on the
  dock.

  When hotplugging such dock with additional usb devices already
  attached on it, the probing process may reset usb 2.1 port, therefore
  r8152 ethernet device is also reset. However, in r8152 driver there
  are several  for-loops that may take up to 14 seconds during the
  initialization for each in practice, and that has to be completed
  before USB may re-enumerate devices on the bus. As a result, devices
  attached to the dock will only be available after nearly 1 minute
  after the dock is plugged in.

    [  216.388290] [250] r8152 2-1.4:1.0: usb_probe_interface
    [  216.388292] [250] r8152 2-1.4:1.0: usb_probe_interface - got id
    [  258.830410] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): PHY 
not ready
    [  258.830460] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): 
Invalid header when reading pass-thru MAC addr
    [  258.830464] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): Get 
ether addr fail

  This can be reproduced on all kernel versions up to latest v5.6-rc2,
  but after v5.5-rc7 the reproduce rate is dramatically lower to 1/30 or
  so while it was around 1/2.

  The time consuming for-loops are at:
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L3206
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L5400
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L5537

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: linux-image-5.0.0-1037-oem-osp1 5.0.0-1037.42
  ProcVersionSignature: Ubuntu 5.0.0-1037.42-oem-osp1 5.0.21
  Uname: Linux 5.0.0-1037-oem-osp1 x86_64
  ApportVersion: 2.20.9-0ubuntu7.11
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  u  2014 F pulseaudio
  CurrentDesktop: ubuntu:GNOME
  Date: Sat Feb 22 04:07:20 2020
  DistributionChannelDescriptor:
   # This is the distribution channel descriptor for the OEM CDs
   # For more information see 
http://wiki.ubuntu.com/DistributionChannelDescriptor
   canonical-oem-somerville-bionic-amd64-20180608-47+beaver-hodor+X95
  InstallationDate: Installed on 2020-01-16 (37 days ago)
  InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 
20180608-09:38
  IwConfig:
   enp1s0no wireless extensions.

   enxd8d090035306  no wireless extensions.

   lono wireless extensions.
  MachineType: Dell Inc. Latitude 3310
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-1037-oem-osp1 
root=UUID=1ad036ce-aa29-4d5e-8692-d980d1a7140f ro "dyndbg=file drivers/usb/* 
+pt" log_buf_len=32M ignore_loglevel usbcore.quirks=0bda:0487:k
  RelatedPackageVersions:
   linux-restricted-modules-5.0.0-1037-oem-osp1 N/A
   linux-backports-modules-5.0.0-1037-oem-osp1  N/A
   linux-firmware   1.173.15
  SourcePackage: linux-oem-osp1
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 01/07/2020
  

[Kernel-packages] [Bug 1864284] Re: r8152 init may take up to 40 seconds at initialization with Dell WD19/WD19DC during hotplug

[Timo Aaltonen]

osp1 kernel is in proposed, please test asap

** Tags added: verification-needed-bionic

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-oem in Ubuntu.
https://bugs.launchpad.net/bugs/1864284

Title:
  r8152 init may take up to 40 seconds at initialization with Dell
  WD19/WD19DC during hotplug

Status in HWE Next:
  New
Status in linux package in Ubuntu:
  In Progress
Status in linux-oem package in Ubuntu:
  New
Status in linux-oem-osp1 package in Ubuntu:
  New
Status in linux source package in Bionic:
  Fix Committed
Status in linux-oem source package in Bionic:
  Fix Committed
Status in linux-oem-osp1 source package in Bionic:
  Fix Committed
Status in linux source package in Eoan:
  Fix Committed
Status in linux source package in Focal:
  In Progress

Bug description:
  [SRU Justification]

  [Impact]
  USB devices attached to Dell WD19/WD19DC USB Type-C dock take up to nearly one
  minutes to be ready for use.

  [Fix]
  r8152 driver init process involves several for-loops that each may take up to 
14
  seconds to exit when USB port reset occurs during hotplug. This is still
  reproducible with latest v5.6-rc mainline kernel although the fail rate is 
much
  lower since v5.5-rc7.

  [Test Case]
  Verified on Dell WD19DC.

  [Regression Potential]
  Low. Just to exit the loop early when it should have been.

  == original bug description ==

  Dell USB Type C docking WD19/WD19DC attaches additional peripherals
  as:

    /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
    |__ Port 1: Dev 11, If 0, Class=Hub, Driver=hub/4p, 5000M
    |__ Port 3: Dev 12, If 0, Class=Hub, Driver=hub/4p, 5000M
    |__ Port 4: Dev 13, If 0, Class=Vendor Specific Class, 
Driver=r8152, 5000M

  where usb 2-1-3 is a hub connecting all USB Type-A/C ports on the
  dock.

  When hotplugging such dock with additional usb devices already
  attached on it, the probing process may reset usb 2.1 port, therefore
  r8152 ethernet device is also reset. However, in r8152 driver there
  are several  for-loops that may take up to 14 seconds during the
  initialization for each in practice, and that has to be completed
  before USB may re-enumerate devices on the bus. As a result, devices
  attached to the dock will only be available after nearly 1 minute
  after the dock is plugged in.

    [  216.388290] [250] r8152 2-1.4:1.0: usb_probe_interface
    [  216.388292] [250] r8152 2-1.4:1.0: usb_probe_interface - got id
    [  258.830410] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): PHY 
not ready
    [  258.830460] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): 
Invalid header when reading pass-thru MAC addr
    [  258.830464] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): Get 
ether addr fail

  This can be reproduced on all kernel versions up to latest v5.6-rc2,
  but after v5.5-rc7 the reproduce rate is dramatically lower to 1/30 or
  so while it was around 1/2.

  The time consuming for-loops are at:
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L3206
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L5400
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L5537

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: linux-image-5.0.0-1037-oem-osp1 5.0.0-1037.42
  ProcVersionSignature: Ubuntu 5.0.0-1037.42-oem-osp1 5.0.21
  Uname: Linux 5.0.0-1037-oem-osp1 x86_64
  ApportVersion: 2.20.9-0ubuntu7.11
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  u  2014 F pulseaudio
  CurrentDesktop: ubuntu:GNOME
  Date: Sat Feb 22 04:07:20 2020
  DistributionChannelDescriptor:
   # This is the distribution channel descriptor for the OEM CDs
   # For more information see 
http://wiki.ubuntu.com/DistributionChannelDescriptor
   canonical-oem-somerville-bionic-amd64-20180608-47+beaver-hodor+X95
  InstallationDate: Installed on 2020-01-16 (37 days ago)
  InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 
20180608-09:38
  IwConfig:
   enp1s0no wireless extensions.

   enxd8d090035306  no wireless extensions.

   lono wireless extensions.
  MachineType: Dell Inc. Latitude 3310
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-1037-oem-osp1 
root=UUID=1ad036ce-aa29-4d5e-8692-d980d1a7140f ro "dyndbg=file drivers/usb/* 
+pt" log_buf_len=32M ignore_loglevel usbcore.quirks=0bda:0487:k
  RelatedPackageVersions:
   linux-restricted-modules-5.0.0-1037-oem-osp1 N/A
   linux-backports-modules-5.0.0-1037-oem-osp1  N/A
   linux-firmware   1.173.15
  SourcePackage: linux-oem-osp1
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 01/07/2020
  dmi.bios.vendor: Dell 

[Kernel-packages] [Bug 1864284] Re: r8152 init may take up to 40 seconds at initialization with Dell WD19/WD19DC during hotplug

[Khaled El Mously]

** Changed in: linux (Ubuntu Bionic)
   Status: In Progress => Fix Committed

** Changed in: linux (Ubuntu Eoan)
   Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-oem in Ubuntu.
https://bugs.launchpad.net/bugs/1864284

Title:
  r8152 init may take up to 40 seconds at initialization with Dell
  WD19/WD19DC during hotplug

Status in HWE Next:
  New
Status in linux package in Ubuntu:
  In Progress
Status in linux-oem package in Ubuntu:
  New
Status in linux-oem-osp1 package in Ubuntu:
  New
Status in linux source package in Bionic:
  Fix Committed
Status in linux-oem source package in Bionic:
  Fix Committed
Status in linux-oem-osp1 source package in Bionic:
  Fix Committed
Status in linux source package in Eoan:
  Fix Committed
Status in linux source package in Focal:
  In Progress

Bug description:
  [SRU Justification]

  [Impact]
  USB devices attached to Dell WD19/WD19DC USB Type-C dock take up to nearly one
  minutes to be ready for use.

  [Fix]
  r8152 driver init process involves several for-loops that each may take up to 
14
  seconds to exit when USB port reset occurs during hotplug. This is still
  reproducible with latest v5.6-rc mainline kernel although the fail rate is 
much
  lower since v5.5-rc7.

  [Test Case]
  Verified on Dell WD19DC.

  [Regression Potential]
  Low. Just to exit the loop early when it should have been.

  == original bug description ==

  Dell USB Type C docking WD19/WD19DC attaches additional peripherals
  as:

    /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
    |__ Port 1: Dev 11, If 0, Class=Hub, Driver=hub/4p, 5000M
    |__ Port 3: Dev 12, If 0, Class=Hub, Driver=hub/4p, 5000M
    |__ Port 4: Dev 13, If 0, Class=Vendor Specific Class, 
Driver=r8152, 5000M

  where usb 2-1-3 is a hub connecting all USB Type-A/C ports on the
  dock.

  When hotplugging such dock with additional usb devices already
  attached on it, the probing process may reset usb 2.1 port, therefore
  r8152 ethernet device is also reset. However, in r8152 driver there
  are several  for-loops that may take up to 14 seconds during the
  initialization for each in practice, and that has to be completed
  before USB may re-enumerate devices on the bus. As a result, devices
  attached to the dock will only be available after nearly 1 minute
  after the dock is plugged in.

    [  216.388290] [250] r8152 2-1.4:1.0: usb_probe_interface
    [  216.388292] [250] r8152 2-1.4:1.0: usb_probe_interface - got id
    [  258.830410] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): PHY 
not ready
    [  258.830460] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): 
Invalid header when reading pass-thru MAC addr
    [  258.830464] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): Get 
ether addr fail

  This can be reproduced on all kernel versions up to latest v5.6-rc2,
  but after v5.5-rc7 the reproduce rate is dramatically lower to 1/30 or
  so while it was around 1/2.

  The time consuming for-loops are at:
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L3206
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L5400
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L5537

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: linux-image-5.0.0-1037-oem-osp1 5.0.0-1037.42
  ProcVersionSignature: Ubuntu 5.0.0-1037.42-oem-osp1 5.0.21
  Uname: Linux 5.0.0-1037-oem-osp1 x86_64
  ApportVersion: 2.20.9-0ubuntu7.11
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  u  2014 F pulseaudio
  CurrentDesktop: ubuntu:GNOME
  Date: Sat Feb 22 04:07:20 2020
  DistributionChannelDescriptor:
   # This is the distribution channel descriptor for the OEM CDs
   # For more information see 
http://wiki.ubuntu.com/DistributionChannelDescriptor
   canonical-oem-somerville-bionic-amd64-20180608-47+beaver-hodor+X95
  InstallationDate: Installed on 2020-01-16 (37 days ago)
  InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 
20180608-09:38
  IwConfig:
   enp1s0no wireless extensions.

   enxd8d090035306  no wireless extensions.

   lono wireless extensions.
  MachineType: Dell Inc. Latitude 3310
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-1037-oem-osp1 
root=UUID=1ad036ce-aa29-4d5e-8692-d980d1a7140f ro "dyndbg=file drivers/usb/* 
+pt" log_buf_len=32M ignore_loglevel usbcore.quirks=0bda:0487:k
  RelatedPackageVersions:
   linux-restricted-modules-5.0.0-1037-oem-osp1 N/A
   linux-backports-modules-5.0.0-1037-oem-osp1  N/A
   linux-firmware   1.173.15
  SourcePackage: linux-oem-osp1
  UpgradeStatus: No upgrade log present 

[Kernel-packages] [Bug 1864284] Re: r8152 init may take up to 40 seconds at initialization with Dell WD19/WD19DC during hotplug

[Ubuntu Kernel Bot]

This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
focal' to 'verification-done-focal'. If the problem still exists, change
the tag 'verification-needed-focal' to 'verification-failed-focal'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-focal

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-oem in Ubuntu.
https://bugs.launchpad.net/bugs/1864284

Title:
  r8152 init may take up to 40 seconds at initialization with Dell
  WD19/WD19DC during hotplug

Status in HWE Next:
  New
Status in linux package in Ubuntu:
  In Progress
Status in linux-oem package in Ubuntu:
  New
Status in linux-oem-osp1 package in Ubuntu:
  New
Status in linux source package in Bionic:
  In Progress
Status in linux-oem source package in Bionic:
  Fix Committed
Status in linux-oem-osp1 source package in Bionic:
  Fix Committed
Status in linux source package in Eoan:
  In Progress
Status in linux source package in Focal:
  In Progress

Bug description:
  [SRU Justification]

  [Impact]
  USB devices attached to Dell WD19/WD19DC USB Type-C dock take up to nearly one
  minutes to be ready for use.

  [Fix]
  r8152 driver init process involves several for-loops that each may take up to 
14
  seconds to exit when USB port reset occurs during hotplug. This is still
  reproducible with latest v5.6-rc mainline kernel although the fail rate is 
much
  lower since v5.5-rc7.

  [Test Case]
  Verified on Dell WD19DC.

  [Regression Potential]
  Low. Just to exit the loop early when it should have been.

  == original bug description ==

  Dell USB Type C docking WD19/WD19DC attaches additional peripherals
  as:

    /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
    |__ Port 1: Dev 11, If 0, Class=Hub, Driver=hub/4p, 5000M
    |__ Port 3: Dev 12, If 0, Class=Hub, Driver=hub/4p, 5000M
    |__ Port 4: Dev 13, If 0, Class=Vendor Specific Class, 
Driver=r8152, 5000M

  where usb 2-1-3 is a hub connecting all USB Type-A/C ports on the
  dock.

  When hotplugging such dock with additional usb devices already
  attached on it, the probing process may reset usb 2.1 port, therefore
  r8152 ethernet device is also reset. However, in r8152 driver there
  are several  for-loops that may take up to 14 seconds during the
  initialization for each in practice, and that has to be completed
  before USB may re-enumerate devices on the bus. As a result, devices
  attached to the dock will only be available after nearly 1 minute
  after the dock is plugged in.

    [  216.388290] [250] r8152 2-1.4:1.0: usb_probe_interface
    [  216.388292] [250] r8152 2-1.4:1.0: usb_probe_interface - got id
    [  258.830410] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): PHY 
not ready
    [  258.830460] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): 
Invalid header when reading pass-thru MAC addr
    [  258.830464] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): Get 
ether addr fail

  This can be reproduced on all kernel versions up to latest v5.6-rc2,
  but after v5.5-rc7 the reproduce rate is dramatically lower to 1/30 or
  so while it was around 1/2.

  The time consuming for-loops are at:
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L3206
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L5400
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L5537

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: linux-image-5.0.0-1037-oem-osp1 5.0.0-1037.42
  ProcVersionSignature: Ubuntu 5.0.0-1037.42-oem-osp1 5.0.21
  Uname: Linux 5.0.0-1037-oem-osp1 x86_64
  ApportVersion: 2.20.9-0ubuntu7.11
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  u  2014 F pulseaudio
  CurrentDesktop: ubuntu:GNOME
  Date: Sat Feb 22 04:07:20 2020
  DistributionChannelDescriptor:
   # This is the distribution channel descriptor for the OEM CDs
   # For more information see 
http://wiki.ubuntu.com/DistributionChannelDescriptor
   canonical-oem-somerville-bionic-amd64-20180608-47+beaver-hodor+X95
  InstallationDate: Installed on 2020-01-16 (37 days ago)
  InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 
20180608-09:38
  IwConfig:
   enp1s0no wireless extensions.

   enxd8d090035306  no wireless extensions.

   lono wireless extensions.
  MachineType: Dell Inc. Latitude 3310
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 

[Kernel-packages] [Bug 1864284] Re: r8152 init may take up to 40 seconds at initialization with Dell WD19/WD19DC during hotplug

[Timo Aaltonen]

** Changed in: linux-oem-osp1 (Ubuntu Bionic)
   Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-oem in Ubuntu.
https://bugs.launchpad.net/bugs/1864284

Title:
  r8152 init may take up to 40 seconds at initialization with Dell
  WD19/WD19DC during hotplug

Status in HWE Next:
  New
Status in linux package in Ubuntu:
  In Progress
Status in linux-oem package in Ubuntu:
  New
Status in linux-oem-osp1 package in Ubuntu:
  New
Status in linux source package in Bionic:
  In Progress
Status in linux-oem source package in Bionic:
  Fix Committed
Status in linux-oem-osp1 source package in Bionic:
  Fix Committed
Status in linux source package in Eoan:
  In Progress
Status in linux source package in Focal:
  In Progress

Bug description:
  [SRU Justification]

  [Impact]
  USB devices attached to Dell WD19/WD19DC USB Type-C dock take up to nearly one
  minutes to be ready for use.

  [Fix]
  r8152 driver init process involves several for-loops that each may take up to 
14
  seconds to exit when USB port reset occurs during hotplug. This is still
  reproducible with latest v5.6-rc mainline kernel although the fail rate is 
much
  lower since v5.5-rc7.

  [Test Case]
  Verified on Dell WD19DC.

  [Regression Potential]
  Low. Just to exit the loop early when it should have been.

  == original bug description ==

  Dell USB Type C docking WD19/WD19DC attaches additional peripherals
  as:

    /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
    |__ Port 1: Dev 11, If 0, Class=Hub, Driver=hub/4p, 5000M
    |__ Port 3: Dev 12, If 0, Class=Hub, Driver=hub/4p, 5000M
    |__ Port 4: Dev 13, If 0, Class=Vendor Specific Class, 
Driver=r8152, 5000M

  where usb 2-1-3 is a hub connecting all USB Type-A/C ports on the
  dock.

  When hotplugging such dock with additional usb devices already
  attached on it, the probing process may reset usb 2.1 port, therefore
  r8152 ethernet device is also reset. However, in r8152 driver there
  are several  for-loops that may take up to 14 seconds during the
  initialization for each in practice, and that has to be completed
  before USB may re-enumerate devices on the bus. As a result, devices
  attached to the dock will only be available after nearly 1 minute
  after the dock is plugged in.

    [  216.388290] [250] r8152 2-1.4:1.0: usb_probe_interface
    [  216.388292] [250] r8152 2-1.4:1.0: usb_probe_interface - got id
    [  258.830410] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): PHY 
not ready
    [  258.830460] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): 
Invalid header when reading pass-thru MAC addr
    [  258.830464] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): Get 
ether addr fail

  This can be reproduced on all kernel versions up to latest v5.6-rc2,
  but after v5.5-rc7 the reproduce rate is dramatically lower to 1/30 or
  so while it was around 1/2.

  The time consuming for-loops are at:
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L3206
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L5400
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L5537

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: linux-image-5.0.0-1037-oem-osp1 5.0.0-1037.42
  ProcVersionSignature: Ubuntu 5.0.0-1037.42-oem-osp1 5.0.21
  Uname: Linux 5.0.0-1037-oem-osp1 x86_64
  ApportVersion: 2.20.9-0ubuntu7.11
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  u  2014 F pulseaudio
  CurrentDesktop: ubuntu:GNOME
  Date: Sat Feb 22 04:07:20 2020
  DistributionChannelDescriptor:
   # This is the distribution channel descriptor for the OEM CDs
   # For more information see 
http://wiki.ubuntu.com/DistributionChannelDescriptor
   canonical-oem-somerville-bionic-amd64-20180608-47+beaver-hodor+X95
  InstallationDate: Installed on 2020-01-16 (37 days ago)
  InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 
20180608-09:38
  IwConfig:
   enp1s0no wireless extensions.

   enxd8d090035306  no wireless extensions.

   lono wireless extensions.
  MachineType: Dell Inc. Latitude 3310
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-1037-oem-osp1 
root=UUID=1ad036ce-aa29-4d5e-8692-d980d1a7140f ro "dyndbg=file drivers/usb/* 
+pt" log_buf_len=32M ignore_loglevel usbcore.quirks=0bda:0487:k
  RelatedPackageVersions:
   linux-restricted-modules-5.0.0-1037-oem-osp1 N/A
   linux-backports-modules-5.0.0-1037-oem-osp1  N/A
   linux-firmware   1.173.15
  SourcePackage: linux-oem-osp1
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 01/07/2020
  dmi.bios.vendor: Dell 

[Kernel-packages] [Bug 1864284] Re: r8152 init may take up to 40 seconds at initialization with Dell WD19/WD19DC during hotplug

[You-Sheng Yang]

Applied to upstream at
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=d64c7a08034b32c285e576208ae44fc3ba3fa7df

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-oem in Ubuntu.
https://bugs.launchpad.net/bugs/1864284

Title:
  r8152 init may take up to 40 seconds at initialization with Dell
  WD19/WD19DC during hotplug

Status in HWE Next:
  New
Status in linux package in Ubuntu:
  In Progress
Status in linux-oem package in Ubuntu:
  New
Status in linux-oem-osp1 package in Ubuntu:
  New
Status in linux source package in Bionic:
  In Progress
Status in linux-oem source package in Bionic:
  Fix Committed
Status in linux-oem-osp1 source package in Bionic:
  In Progress
Status in linux source package in Eoan:
  In Progress
Status in linux source package in Focal:
  In Progress

Bug description:
  [SRU Justification]

  [Impact]
  USB devices attached to Dell WD19/WD19DC USB Type-C dock take up to nearly one
  minutes to be ready for use.

  [Fix]
  r8152 driver init process involves several for-loops that each may take up to 
14
  seconds to exit when USB port reset occurs during hotplug. This is still
  reproducible with latest v5.6-rc mainline kernel although the fail rate is 
much
  lower since v5.5-rc7.

  [Test Case]
  Verified on Dell WD19DC.

  [Regression Potential]
  Low. Just to exit the loop early when it should have been.

  == original bug description ==

  Dell USB Type C docking WD19/WD19DC attaches additional peripherals
  as:

    /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
    |__ Port 1: Dev 11, If 0, Class=Hub, Driver=hub/4p, 5000M
    |__ Port 3: Dev 12, If 0, Class=Hub, Driver=hub/4p, 5000M
    |__ Port 4: Dev 13, If 0, Class=Vendor Specific Class, 
Driver=r8152, 5000M

  where usb 2-1-3 is a hub connecting all USB Type-A/C ports on the
  dock.

  When hotplugging such dock with additional usb devices already
  attached on it, the probing process may reset usb 2.1 port, therefore
  r8152 ethernet device is also reset. However, in r8152 driver there
  are several  for-loops that may take up to 14 seconds during the
  initialization for each in practice, and that has to be completed
  before USB may re-enumerate devices on the bus. As a result, devices
  attached to the dock will only be available after nearly 1 minute
  after the dock is plugged in.

    [  216.388290] [250] r8152 2-1.4:1.0: usb_probe_interface
    [  216.388292] [250] r8152 2-1.4:1.0: usb_probe_interface - got id
    [  258.830410] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): PHY 
not ready
    [  258.830460] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): 
Invalid header when reading pass-thru MAC addr
    [  258.830464] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): Get 
ether addr fail

  This can be reproduced on all kernel versions up to latest v5.6-rc2,
  but after v5.5-rc7 the reproduce rate is dramatically lower to 1/30 or
  so while it was around 1/2.

  The time consuming for-loops are at:
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L3206
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L5400
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L5537

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: linux-image-5.0.0-1037-oem-osp1 5.0.0-1037.42
  ProcVersionSignature: Ubuntu 5.0.0-1037.42-oem-osp1 5.0.21
  Uname: Linux 5.0.0-1037-oem-osp1 x86_64
  ApportVersion: 2.20.9-0ubuntu7.11
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  u  2014 F pulseaudio
  CurrentDesktop: ubuntu:GNOME
  Date: Sat Feb 22 04:07:20 2020
  DistributionChannelDescriptor:
   # This is the distribution channel descriptor for the OEM CDs
   # For more information see 
http://wiki.ubuntu.com/DistributionChannelDescriptor
   canonical-oem-somerville-bionic-amd64-20180608-47+beaver-hodor+X95
  InstallationDate: Installed on 2020-01-16 (37 days ago)
  InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 
20180608-09:38
  IwConfig:
   enp1s0no wireless extensions.

   enxd8d090035306  no wireless extensions.

   lono wireless extensions.
  MachineType: Dell Inc. Latitude 3310
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-1037-oem-osp1 
root=UUID=1ad036ce-aa29-4d5e-8692-d980d1a7140f ro "dyndbg=file drivers/usb/* 
+pt" log_buf_len=32M ignore_loglevel usbcore.quirks=0bda:0487:k
  RelatedPackageVersions:
   linux-restricted-modules-5.0.0-1037-oem-osp1 N/A
   linux-backports-modules-5.0.0-1037-oem-osp1  N/A
   linux-firmware   1.173.15
  SourcePackage: linux-oem-osp1
  UpgradeStatus: No upgrade log present (probably fresh install)
  

[Kernel-packages] [Bug 1864284] Re: r8152 init may take up to 40 seconds at initialization with Dell WD19/WD19DC during hotplug

[AceLan Kao]

** Changed in: linux-oem (Ubuntu Bionic)
   Status: In Progress => Fix Committed

** No longer affects: linux-oem (Ubuntu Eoan)

** No longer affects: linux-oem (Ubuntu Focal)

** No longer affects: linux-oem-osp1 (Ubuntu Eoan)

** No longer affects: linux-oem-osp1 (Ubuntu Focal)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-oem in Ubuntu.
https://bugs.launchpad.net/bugs/1864284

Title:
  r8152 init may take up to 40 seconds at initialization with Dell
  WD19/WD19DC during hotplug

Status in HWE Next:
  New
Status in linux package in Ubuntu:
  In Progress
Status in linux-oem package in Ubuntu:
  New
Status in linux-oem-osp1 package in Ubuntu:
  New
Status in linux source package in Bionic:
  In Progress
Status in linux-oem source package in Bionic:
  Fix Committed
Status in linux-oem-osp1 source package in Bionic:
  In Progress
Status in linux source package in Eoan:
  In Progress
Status in linux source package in Focal:
  In Progress

Bug description:
  [SRU Justification]

  [Impact]
  USB devices attached to Dell WD19/WD19DC USB Type-C dock take up to nearly one
  minutes to be ready for use.

  [Fix]
  r8152 driver init process involves several for-loops that each may take up to 
14
  seconds to exit when USB port reset occurs during hotplug. This is still
  reproducible with latest v5.6-rc mainline kernel although the fail rate is 
much
  lower since v5.5-rc7.

  [Test Case]
  Verified on Dell WD19DC.

  [Regression Potential]
  Low. Just to exit the loop early when it should have been.

  == original bug description ==

  Dell USB Type C docking WD19/WD19DC attaches additional peripherals
  as:

    /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
    |__ Port 1: Dev 11, If 0, Class=Hub, Driver=hub/4p, 5000M
    |__ Port 3: Dev 12, If 0, Class=Hub, Driver=hub/4p, 5000M
    |__ Port 4: Dev 13, If 0, Class=Vendor Specific Class, 
Driver=r8152, 5000M

  where usb 2-1-3 is a hub connecting all USB Type-A/C ports on the
  dock.

  When hotplugging such dock with additional usb devices already
  attached on it, the probing process may reset usb 2.1 port, therefore
  r8152 ethernet device is also reset. However, in r8152 driver there
  are several  for-loops that may take up to 14 seconds during the
  initialization for each in practice, and that has to be completed
  before USB may re-enumerate devices on the bus. As a result, devices
  attached to the dock will only be available after nearly 1 minute
  after the dock is plugged in.

    [  216.388290] [250] r8152 2-1.4:1.0: usb_probe_interface
    [  216.388292] [250] r8152 2-1.4:1.0: usb_probe_interface - got id
    [  258.830410] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): PHY 
not ready
    [  258.830460] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): 
Invalid header when reading pass-thru MAC addr
    [  258.830464] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): Get 
ether addr fail

  This can be reproduced on all kernel versions up to latest v5.6-rc2,
  but after v5.5-rc7 the reproduce rate is dramatically lower to 1/30 or
  so while it was around 1/2.

  The time consuming for-loops are at:
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L3206
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L5400
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L5537

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: linux-image-5.0.0-1037-oem-osp1 5.0.0-1037.42
  ProcVersionSignature: Ubuntu 5.0.0-1037.42-oem-osp1 5.0.21
  Uname: Linux 5.0.0-1037-oem-osp1 x86_64
  ApportVersion: 2.20.9-0ubuntu7.11
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  u  2014 F pulseaudio
  CurrentDesktop: ubuntu:GNOME
  Date: Sat Feb 22 04:07:20 2020
  DistributionChannelDescriptor:
   # This is the distribution channel descriptor for the OEM CDs
   # For more information see 
http://wiki.ubuntu.com/DistributionChannelDescriptor
   canonical-oem-somerville-bionic-amd64-20180608-47+beaver-hodor+X95
  InstallationDate: Installed on 2020-01-16 (37 days ago)
  InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 
20180608-09:38
  IwConfig:
   enp1s0no wireless extensions.

   enxd8d090035306  no wireless extensions.

   lono wireless extensions.
  MachineType: Dell Inc. Latitude 3310
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-1037-oem-osp1 
root=UUID=1ad036ce-aa29-4d5e-8692-d980d1a7140f ro "dyndbg=file drivers/usb/* 
+pt" log_buf_len=32M ignore_loglevel usbcore.quirks=0bda:0487:k
  RelatedPackageVersions:
   linux-restricted-modules-5.0.0-1037-oem-osp1 N/A
   linux-backports-modules-5.0.0-1037-oem-osp1  N/A
   

[Kernel-packages] [Bug 1864284] Re: r8152 init may take up to 40 seconds at initialization with Dell WD19/WD19DC during hotplug

[You-Sheng Yang]

** Also affects: linux (Ubuntu Focal)
   Importance: Undecided
   Status: Confirmed

** Also affects: linux-oem-osp1 (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: linux (Ubuntu Eoan)
   Importance: Undecided
   Status: New

** Also affects: linux-oem-osp1 (Ubuntu Eoan)
   Importance: Undecided
   Status: New

** Also affects: linux (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: linux-oem-osp1 (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: linux-oem (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: linux (Ubuntu Bionic)
   Status: New => In Progress

** Changed in: linux (Ubuntu Bionic)
 Assignee: (unassigned) => You-Sheng Yang (vicamo)

** Changed in: linux (Ubuntu Eoan)
   Status: New => In Progress

** Changed in: linux (Ubuntu Eoan)
 Assignee: (unassigned) => You-Sheng Yang (vicamo)

** Changed in: linux (Ubuntu Focal)
   Status: Confirmed => In Progress

** Changed in: linux (Ubuntu Focal)
 Assignee: (unassigned) => You-Sheng Yang (vicamo)

** Changed in: linux-oem (Ubuntu Bionic)
   Status: New => In Progress

** Changed in: linux-oem (Ubuntu Bionic)
 Assignee: (unassigned) => You-Sheng Yang (vicamo)

** Changed in: linux-oem-osp1 (Ubuntu Bionic)
   Status: New => In Progress

** Changed in: linux-oem-osp1 (Ubuntu Bionic)
 Assignee: (unassigned) => You-Sheng Yang (vicamo)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1864284

Title:
  r8152 init may take up to 40 seconds at initialization with Dell
  WD19/WD19DC during hotplug

Status in HWE Next:
  New
Status in linux package in Ubuntu:
  In Progress
Status in linux-oem package in Ubuntu:
  New
Status in linux-oem-osp1 package in Ubuntu:
  New
Status in linux source package in Bionic:
  In Progress
Status in linux-oem source package in Bionic:
  In Progress
Status in linux-oem-osp1 source package in Bionic:
  In Progress
Status in linux source package in Eoan:
  In Progress
Status in linux-oem source package in Eoan:
  New
Status in linux-oem-osp1 source package in Eoan:
  New
Status in linux source package in Focal:
  In Progress
Status in linux-oem source package in Focal:
  New
Status in linux-oem-osp1 source package in Focal:
  New

Bug description:
  [SRU Justification]

  [Impact]
  USB devices attached to Dell WD19/WD19DC USB Type-C dock take up to nearly one
  minutes to be ready for use.

  [Fix]
  r8152 driver init process involves several for-loops that each may take up to 
14
  seconds to exit when USB port reset occurs during hotplug. This is still
  reproducible with latest v5.6-rc mainline kernel although the fail rate is 
much
  lower since v5.5-rc7.

  [Test Case]
  Verified on Dell WD19DC.

  [Regression Potential]
  Low. Just to exit the loop early when it should have been.

  == original bug description ==

  Dell USB Type C docking WD19/WD19DC attaches additional peripherals
  as:

    /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
    |__ Port 1: Dev 11, If 0, Class=Hub, Driver=hub/4p, 5000M
    |__ Port 3: Dev 12, If 0, Class=Hub, Driver=hub/4p, 5000M
    |__ Port 4: Dev 13, If 0, Class=Vendor Specific Class, 
Driver=r8152, 5000M

  where usb 2-1-3 is a hub connecting all USB Type-A/C ports on the
  dock.

  When hotplugging such dock with additional usb devices already
  attached on it, the probing process may reset usb 2.1 port, therefore
  r8152 ethernet device is also reset. However, in r8152 driver there
  are several  for-loops that may take up to 14 seconds during the
  initialization for each in practice, and that has to be completed
  before USB may re-enumerate devices on the bus. As a result, devices
  attached to the dock will only be available after nearly 1 minute
  after the dock is plugged in.

    [  216.388290] [250] r8152 2-1.4:1.0: usb_probe_interface
    [  216.388292] [250] r8152 2-1.4:1.0: usb_probe_interface - got id
    [  258.830410] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): PHY 
not ready
    [  258.830460] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): 
Invalid header when reading pass-thru MAC addr
    [  258.830464] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): Get 
ether addr fail

  This can be reproduced on all kernel versions up to latest v5.6-rc2,
  but after v5.5-rc7 the reproduce rate is dramatically lower to 1/30 or
  so while it was around 1/2.

  The time consuming for-loops are at:
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L3206
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L5400
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L5537

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: linux-image-5.0.0-1037-oem-osp1 5.0.0-1037.42
  

[Kernel-packages] [Bug 1864284] Re: r8152 init may take up to 40 seconds at initialization with Dell WD19/WD19DC during hotplug

[You-Sheng Yang]

Upstream: https://lore.kernel.org/linux-
usb/20200224071541.117363-1-vicamo.y...@canonical.com/

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1864284

Title:
  r8152 init may take up to 40 seconds at initialization with Dell
  WD19/WD19DC during hotplug

Status in HWE Next:
  New
Status in linux package in Ubuntu:
  Confirmed
Status in linux-oem-osp1 package in Ubuntu:
  New

Bug description:
  [SRU Justification]

  [Impact]
  USB devices attached to Dell WD19/WD19DC USB Type-C dock take up to nearly one
  minutes to be ready for use.

  [Fix]
  r8152 driver init process involves several for-loops that each may take up to 
14
  seconds to exit when USB port reset occurs during hotplug. This is still
  reproducible with latest v5.6-rc mainline kernel although the fail rate is 
much
  lower since v5.5-rc7.

  [Test Case]
  Verified on Dell WD19DC.

  [Regression Potential]
  Low. Just to exit the loop early when it should have been.

  == original bug description ==

  Dell USB Type C docking WD19/WD19DC attaches additional peripherals
  as:

    /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
    |__ Port 1: Dev 11, If 0, Class=Hub, Driver=hub/4p, 5000M
    |__ Port 3: Dev 12, If 0, Class=Hub, Driver=hub/4p, 5000M
    |__ Port 4: Dev 13, If 0, Class=Vendor Specific Class, 
Driver=r8152, 5000M

  where usb 2-1-3 is a hub connecting all USB Type-A/C ports on the
  dock.

  When hotplugging such dock with additional usb devices already
  attached on it, the probing process may reset usb 2.1 port, therefore
  r8152 ethernet device is also reset. However, in r8152 driver there
  are several  for-loops that may take up to 14 seconds during the
  initialization for each in practice, and that has to be completed
  before USB may re-enumerate devices on the bus. As a result, devices
  attached to the dock will only be available after nearly 1 minute
  after the dock is plugged in.

    [  216.388290] [250] r8152 2-1.4:1.0: usb_probe_interface
    [  216.388292] [250] r8152 2-1.4:1.0: usb_probe_interface - got id
    [  258.830410] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): PHY 
not ready
    [  258.830460] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): 
Invalid header when reading pass-thru MAC addr
    [  258.830464] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): Get 
ether addr fail

  This can be reproduced on all kernel versions up to latest v5.6-rc2,
  but after v5.5-rc7 the reproduce rate is dramatically lower to 1/30 or
  so while it was around 1/2.

  The time consuming for-loops are at:
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L3206
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L5400
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L5537

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: linux-image-5.0.0-1037-oem-osp1 5.0.0-1037.42
  ProcVersionSignature: Ubuntu 5.0.0-1037.42-oem-osp1 5.0.21
  Uname: Linux 5.0.0-1037-oem-osp1 x86_64
  ApportVersion: 2.20.9-0ubuntu7.11
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  u  2014 F pulseaudio
  CurrentDesktop: ubuntu:GNOME
  Date: Sat Feb 22 04:07:20 2020
  DistributionChannelDescriptor:
   # This is the distribution channel descriptor for the OEM CDs
   # For more information see 
http://wiki.ubuntu.com/DistributionChannelDescriptor
   canonical-oem-somerville-bionic-amd64-20180608-47+beaver-hodor+X95
  InstallationDate: Installed on 2020-01-16 (37 days ago)
  InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 
20180608-09:38
  IwConfig:
   enp1s0no wireless extensions.

   enxd8d090035306  no wireless extensions.

   lono wireless extensions.
  MachineType: Dell Inc. Latitude 3310
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-1037-oem-osp1 
root=UUID=1ad036ce-aa29-4d5e-8692-d980d1a7140f ro "dyndbg=file drivers/usb/* 
+pt" log_buf_len=32M ignore_loglevel usbcore.quirks=0bda:0487:k
  RelatedPackageVersions:
   linux-restricted-modules-5.0.0-1037-oem-osp1 N/A
   linux-backports-modules-5.0.0-1037-oem-osp1  N/A
   linux-firmware   1.173.15
  SourcePackage: linux-oem-osp1
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 01/07/2020
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 99.51.2[V2 AMI]
  dmi.board.vendor: Dell Inc.
  dmi.chassis.type: 10
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr99.51.2[V2AMI]:bd01/07/2020:svnDellInc.:pnLatitude3310:pvr:rvnDellInc.:rn:rvr:cvnDellInc.:ct10:cvr:
  dmi.product.family: Latitude
  dmi.product.name: Latitude 3310
  

[Kernel-packages] [Bug 1864284] Re: r8152 init may take up to 40 seconds at initialization with Dell WD19/WD19DC during hotplug

[You-Sheng Yang]

SRU: https://lists.ubuntu.com/archives/kernel-
team/2020-February/107726.html

** Description changed:

+ [SRU Justification]
+ 
+ [Impact]
+ USB devices attached to Dell WD19/WD19DC USB Type-C dock take up to nearly one
+ minutes to be ready for use.
+ 
+ [Fix]
+ r8152 driver init process involves several for-loops that each may take up to 
14
+ seconds to exit when USB port reset occurs during hotplug. This is still
+ reproducible with latest v5.6-rc mainline kernel although the fail rate is 
much
+ lower since v5.5-rc7.
+ 
+ [Test Case]
+ Verified on Dell WD19DC.
+ 
+ [Regression Potential]
+ Low. Just to exit the loop early when it should have been.
+ 
+ == original bug description ==
+ 
  Dell USB Type C docking WD19/WD19DC attaches additional peripherals as:
  
    /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
    |__ Port 1: Dev 11, If 0, Class=Hub, Driver=hub/4p, 5000M
    |__ Port 3: Dev 12, If 0, Class=Hub, Driver=hub/4p, 5000M
    |__ Port 4: Dev 13, If 0, Class=Vendor Specific Class, 
Driver=r8152, 5000M
  
  where usb 2-1-3 is a hub connecting all USB Type-A/C ports on the dock.
  
  When hotplugging such dock with additional usb devices already attached
  on it, the probing process may reset usb 2.1 port, therefore r8152
  ethernet device is also reset. However, in r8152 driver there are
  several  for-loops that may take up to 14 seconds during the
  initialization for each in practice, and that has to be completed before
  USB may re-enumerate devices on the bus. As a result, devices attached
  to the dock will only be available after nearly 1 minute after the dock
  is plugged in.
  
-   [  216.388290] [250] r8152 2-1.4:1.0: usb_probe_interface
-   [  216.388292] [250] r8152 2-1.4:1.0: usb_probe_interface - got id
-   [  258.830410] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): PHY 
not ready
-   [  258.830460] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): 
Invalid header when reading pass-thru MAC addr
-   [  258.830464] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): Get 
ether addr fail
+   [  216.388290] [250] r8152 2-1.4:1.0: usb_probe_interface
+   [  216.388292] [250] r8152 2-1.4:1.0: usb_probe_interface - got id
+   [  258.830410] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): PHY 
not ready
+   [  258.830460] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): 
Invalid header when reading pass-thru MAC addr
+   [  258.830464] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): Get 
ether addr fail
  
  This can be reproduced on all kernel versions up to latest v5.6-rc2, but
  after v5.5-rc7 the reproduce rate is dramatically lower to 1/30 or so
  while it was around 1/2.
  
  The time consuming for-loops are at:
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L3206
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L5400
  https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L5537
  
  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: linux-image-5.0.0-1037-oem-osp1 5.0.0-1037.42
  ProcVersionSignature: Ubuntu 5.0.0-1037.42-oem-osp1 5.0.21
  Uname: Linux 5.0.0-1037-oem-osp1 x86_64
  ApportVersion: 2.20.9-0ubuntu7.11
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  u  2014 F pulseaudio
  CurrentDesktop: ubuntu:GNOME
  Date: Sat Feb 22 04:07:20 2020
  DistributionChannelDescriptor:
   # This is the distribution channel descriptor for the OEM CDs
   # For more information see 
http://wiki.ubuntu.com/DistributionChannelDescriptor
   canonical-oem-somerville-bionic-amd64-20180608-47+beaver-hodor+X95
  InstallationDate: Installed on 2020-01-16 (37 days ago)
  InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 
20180608-09:38
  IwConfig:
   enp1s0no wireless extensions.
  
   enxd8d090035306  no wireless extensions.
  
   lono wireless extensions.
  MachineType: Dell Inc. Latitude 3310
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-1037-oem-osp1 
root=UUID=1ad036ce-aa29-4d5e-8692-d980d1a7140f ro "dyndbg=file drivers/usb/* 
+pt" log_buf_len=32M ignore_loglevel usbcore.quirks=0bda:0487:k
  RelatedPackageVersions:
   linux-restricted-modules-5.0.0-1037-oem-osp1 N/A
   linux-backports-modules-5.0.0-1037-oem-osp1  N/A
   linux-firmware   1.173.15
  SourcePackage: linux-oem-osp1
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 01/07/2020
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 99.51.2[V2 AMI]
  dmi.board.vendor: Dell Inc.
  dmi.chassis.type: 10
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr99.51.2[V2AMI]:bd01/07/2020:svnDellInc.:pnLatitude3310:pvr:rvnDellInc.:rn:rvr:cvnDellInc.:ct10:cvr:
  dmi.product.family: 

[Kernel-packages] [Bug 1864284] Re: r8152 init may take up to 40 seconds at initialization with Dell WD19/WD19DC during hotplug

[You-Sheng Yang]

** Description changed:

- TBD
+ Dell USB Type C docking WD19/WD19DC attaches additional peripherals as:
+ 
+   /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
+   |__ Port 1: Dev 11, If 0, Class=Hub, Driver=hub/4p, 5000M
+   |__ Port 3: Dev 12, If 0, Class=Hub, Driver=hub/4p, 5000M
+   |__ Port 4: Dev 13, If 0, Class=Vendor Specific Class, 
Driver=r8152, 5000M
+ 
+ where usb 2-1-3 is a hub connecting all USB Type-A/C ports on the dock.
+ 
+ When hotplugging such dock with additional usb devices already attached
+ on it, the probing process may reset usb 2.1 port, therefore r8152
+ ethernet device is also reset. However, in r8152 driver there are
+ several  for-loops that may take up to 14 seconds during the
+ initialization for each in practice, and that has to be completed before
+ USB may re-enumerate devices on the bus. As a result, devices attached
+ to the dock will only be available after nearly 1 minute after the dock
+ is plugged in.
+ 
+ This can be reproduced on all kernel versions up to latest v5.6-rc2, but
+ after v5.5-rc7 the reproduce rate is dramatically lower to 1/30 or so
+ while it was around 1/2.
+ 
+ The time consuming for-loops are at:
+ https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L3206
+ https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L5400
+ https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L5537
  
  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: linux-image-5.0.0-1037-oem-osp1 5.0.0-1037.42
  ProcVersionSignature: Ubuntu 5.0.0-1037.42-oem-osp1 5.0.21
  Uname: Linux 5.0.0-1037-oem-osp1 x86_64
  ApportVersion: 2.20.9-0ubuntu7.11
  Architecture: amd64
  AudioDevicesInUse:
-  USERPID ACCESS COMMAND
-  /dev/snd/controlC0:  u  2014 F pulseaudio
+  USERPID ACCESS COMMAND
+  /dev/snd/controlC0:  u  2014 F pulseaudio
  CurrentDesktop: ubuntu:GNOME
  Date: Sat Feb 22 04:07:20 2020
  DistributionChannelDescriptor:
-  # This is the distribution channel descriptor for the OEM CDs
-  # For more information see 
http://wiki.ubuntu.com/DistributionChannelDescriptor
-  canonical-oem-somerville-bionic-amd64-20180608-47+beaver-hodor+X95
+  # This is the distribution channel descriptor for the OEM CDs
+  # For more information see 
http://wiki.ubuntu.com/DistributionChannelDescriptor
+  canonical-oem-somerville-bionic-amd64-20180608-47+beaver-hodor+X95
  InstallationDate: Installed on 2020-01-16 (37 days ago)
  InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 
20180608-09:38
  IwConfig:
-  enp1s0no wireless extensions.
-  
-  enxd8d090035306  no wireless extensions.
-  
-  lono wireless extensions.
+  enp1s0no wireless extensions.
+ 
+  enxd8d090035306  no wireless extensions.
+ 
+  lono wireless extensions.
  MachineType: Dell Inc. Latitude 3310
  ProcEnviron:
-  TERM=xterm-256color
-  PATH=(custom, no user)
-  XDG_RUNTIME_DIR=
-  LANG=en_US.UTF-8
-  SHELL=/bin/bash
+  TERM=xterm-256color
+  PATH=(custom, no user)
+  XDG_RUNTIME_DIR=
+  LANG=en_US.UTF-8
+  SHELL=/bin/bash
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-1037-oem-osp1 
root=UUID=1ad036ce-aa29-4d5e-8692-d980d1a7140f ro "dyndbg=file drivers/usb/* 
+pt" log_buf_len=32M ignore_loglevel usbcore.quirks=0bda:0487:k
  RelatedPackageVersions:
-  linux-restricted-modules-5.0.0-1037-oem-osp1 N/A
-  linux-backports-modules-5.0.0-1037-oem-osp1  N/A
-  linux-firmware   1.173.15
+  linux-restricted-modules-5.0.0-1037-oem-osp1 N/A
+  linux-backports-modules-5.0.0-1037-oem-osp1  N/A
+  linux-firmware   1.173.15
  SourcePackage: linux-oem-osp1
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 01/07/2020
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 99.51.2[V2 AMI]
  dmi.board.vendor: Dell Inc.
  dmi.chassis.type: 10
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr99.51.2[V2AMI]:bd01/07/2020:svnDellInc.:pnLatitude3310:pvr:rvnDellInc.:rn:rvr:cvnDellInc.:ct10:cvr:
  dmi.product.family: Latitude
  dmi.product.name: Latitude 3310
  dmi.product.sku: 0A13
  dmi.sys.vendor: Dell Inc.

** Description changed:

  Dell USB Type C docking WD19/WD19DC attaches additional peripherals as:
  
-   /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
-   |__ Port 1: Dev 11, If 0, Class=Hub, Driver=hub/4p, 5000M
-   |__ Port 3: Dev 12, If 0, Class=Hub, Driver=hub/4p, 5000M
-   |__ Port 4: Dev 13, If 0, Class=Vendor Specific Class, 
Driver=r8152, 5000M
+   /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
+   |__ Port 1: Dev 11, If 0, Class=Hub, Driver=hub/4p, 5000M
+   |__ Port 3: Dev 12, If 0, Class=Hub, Driver=hub/4p, 5000M
+   |__ Port 4: Dev 13, If 0, Class=Vendor Specific Class, 
Driver=r8152, 5000M
  
  where usb 2-1-3 is a hub connecting all USB Type-A/C ports 

[Kernel-packages] [Bug 1864284] Re: r8152 init may take up to 40 seconds at initialization with Dell WD19/WD19DC during hotplug

[You-Sheng Yang]

PPA: https://launchpad.net/~vicamo/+archive/ubuntu/ppa-1864284

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1864284

Title:
  r8152 init may take up to 40 seconds at initialization with Dell
  WD19/WD19DC during hotplug

Status in HWE Next:
  New
Status in linux package in Ubuntu:
  Confirmed
Status in linux-oem-osp1 package in Ubuntu:
  New

Bug description:
  TBD

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: linux-image-5.0.0-1037-oem-osp1 5.0.0-1037.42
  ProcVersionSignature: Ubuntu 5.0.0-1037.42-oem-osp1 5.0.21
  Uname: Linux 5.0.0-1037-oem-osp1 x86_64
  ApportVersion: 2.20.9-0ubuntu7.11
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  u  2014 F pulseaudio
  CurrentDesktop: ubuntu:GNOME
  Date: Sat Feb 22 04:07:20 2020
  DistributionChannelDescriptor:
   # This is the distribution channel descriptor for the OEM CDs
   # For more information see 
http://wiki.ubuntu.com/DistributionChannelDescriptor
   canonical-oem-somerville-bionic-amd64-20180608-47+beaver-hodor+X95
  InstallationDate: Installed on 2020-01-16 (37 days ago)
  InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 
20180608-09:38
  IwConfig:
   enp1s0no wireless extensions.
   
   enxd8d090035306  no wireless extensions.
   
   lono wireless extensions.
  MachineType: Dell Inc. Latitude 3310
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-1037-oem-osp1 
root=UUID=1ad036ce-aa29-4d5e-8692-d980d1a7140f ro "dyndbg=file drivers/usb/* 
+pt" log_buf_len=32M ignore_loglevel usbcore.quirks=0bda:0487:k
  RelatedPackageVersions:
   linux-restricted-modules-5.0.0-1037-oem-osp1 N/A
   linux-backports-modules-5.0.0-1037-oem-osp1  N/A
   linux-firmware   1.173.15
  SourcePackage: linux-oem-osp1
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 01/07/2020
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 99.51.2[V2 AMI]
  dmi.board.vendor: Dell Inc.
  dmi.chassis.type: 10
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr99.51.2[V2AMI]:bd01/07/2020:svnDellInc.:pnLatitude3310:pvr:rvnDellInc.:rn:rvr:cvnDellInc.:ct10:cvr:
  dmi.product.family: Latitude
  dmi.product.name: Latitude 3310
  dmi.product.sku: 0A13
  dmi.sys.vendor: Dell Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1864284/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1864284] Re: r8152 init may take up to 40 seconds at initialization with Dell WD19/WD19DC during hotplug

[You-Sheng Yang]

** Also affects: linux (Ubuntu)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1864284

Title:
  r8152 init may take up to 40 seconds at initialization with Dell
  WD19/WD19DC during hotplug

Status in HWE Next:
  New
Status in linux package in Ubuntu:
  New
Status in linux-oem-osp1 package in Ubuntu:
  New

Bug description:
  TBD

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: linux-image-5.0.0-1037-oem-osp1 5.0.0-1037.42
  ProcVersionSignature: Ubuntu 5.0.0-1037.42-oem-osp1 5.0.21
  Uname: Linux 5.0.0-1037-oem-osp1 x86_64
  ApportVersion: 2.20.9-0ubuntu7.11
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  u  2014 F pulseaudio
  CurrentDesktop: ubuntu:GNOME
  Date: Sat Feb 22 04:07:20 2020
  DistributionChannelDescriptor:
   # This is the distribution channel descriptor for the OEM CDs
   # For more information see 
http://wiki.ubuntu.com/DistributionChannelDescriptor
   canonical-oem-somerville-bionic-amd64-20180608-47+beaver-hodor+X95
  InstallationDate: Installed on 2020-01-16 (37 days ago)
  InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 
20180608-09:38
  IwConfig:
   enp1s0no wireless extensions.
   
   enxd8d090035306  no wireless extensions.
   
   lono wireless extensions.
  MachineType: Dell Inc. Latitude 3310
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-1037-oem-osp1 
root=UUID=1ad036ce-aa29-4d5e-8692-d980d1a7140f ro "dyndbg=file drivers/usb/* 
+pt" log_buf_len=32M ignore_loglevel usbcore.quirks=0bda:0487:k
  RelatedPackageVersions:
   linux-restricted-modules-5.0.0-1037-oem-osp1 N/A
   linux-backports-modules-5.0.0-1037-oem-osp1  N/A
   linux-firmware   1.173.15
  SourcePackage: linux-oem-osp1
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 01/07/2020
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 99.51.2[V2 AMI]
  dmi.board.vendor: Dell Inc.
  dmi.chassis.type: 10
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr99.51.2[V2AMI]:bd01/07/2020:svnDellInc.:pnLatitude3310:pvr:rvnDellInc.:rn:rvr:cvnDellInc.:ct10:cvr:
  dmi.product.family: Latitude
  dmi.product.name: Latitude 3310
  dmi.product.sku: 0A13
  dmi.sys.vendor: Dell Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1864284/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp