2021-05-12 16:03:06 |
Chris Chiu |
bug |
|
|
added bug |
2021-05-12 16:07:38 |
Chris Chiu |
bug task added |
|
linux-oem-5.10 (Ubuntu) |
|
2021-05-12 16:13:28 |
Chris Chiu |
nominated for series |
|
Ubuntu Focal |
|
2021-05-12 16:13:28 |
Chris Chiu |
bug task added |
|
linux (Ubuntu Focal) |
|
2021-05-12 16:13:28 |
Chris Chiu |
bug task added |
|
linux-oem-5.10 (Ubuntu Focal) |
|
2021-05-12 16:14:06 |
Chris Chiu |
nominated for series |
|
Ubuntu Hirsute |
|
2021-05-12 16:14:06 |
Chris Chiu |
bug task added |
|
linux (Ubuntu Hirsute) |
|
2021-05-12 16:14:06 |
Chris Chiu |
bug task added |
|
linux-oem-5.10 (Ubuntu Hirsute) |
|
2021-05-12 16:14:06 |
Chris Chiu |
nominated for series |
|
Ubuntu Groovy |
|
2021-05-12 16:14:06 |
Chris Chiu |
bug task added |
|
linux (Ubuntu Groovy) |
|
2021-05-12 16:14:06 |
Chris Chiu |
bug task added |
|
linux-oem-5.10 (Ubuntu Groovy) |
|
2021-05-12 16:14:39 |
Chris Chiu |
linux (Ubuntu Hirsute): assignee |
|
Chris Chiu (mschiu77) |
|
2021-05-12 16:14:43 |
Chris Chiu |
linux (Ubuntu Groovy): assignee |
|
Chris Chiu (mschiu77) |
|
2021-05-12 16:14:48 |
Chris Chiu |
linux (Ubuntu Focal): assignee |
|
Chris Chiu (mschiu77) |
|
2021-05-12 16:14:59 |
Chris Chiu |
linux (Ubuntu): assignee |
|
Chris Chiu (mschiu77) |
|
2021-05-12 16:15:07 |
Chris Chiu |
linux-oem-5.10 (Ubuntu Focal): assignee |
|
Chris Chiu (mschiu77) |
|
2021-05-12 16:15:18 |
Chris Chiu |
linux (Ubuntu): assignee |
Chris Chiu (mschiu77) |
|
|
2021-05-12 16:16:39 |
Chris Chiu |
linux-oem-5.10 (Ubuntu Focal): status |
New |
In Progress |
|
2021-05-12 16:16:45 |
Chris Chiu |
linux (Ubuntu Focal): status |
New |
In Progress |
|
2021-05-12 16:16:49 |
Chris Chiu |
linux (Ubuntu Groovy): status |
New |
In Progress |
|
2021-05-12 16:16:53 |
Chris Chiu |
linux (Ubuntu Hirsute): status |
New |
In Progress |
|
2021-05-12 16:18:35 |
Chris Chiu |
linux-oem-5.10 (Ubuntu Focal): status |
In Progress |
Confirmed |
|
2021-05-12 16:18:39 |
Chris Chiu |
linux (Ubuntu Hirsute): status |
In Progress |
Confirmed |
|
2021-05-12 16:18:42 |
Chris Chiu |
linux (Ubuntu Groovy): status |
In Progress |
Confirmed |
|
2021-05-12 16:18:44 |
Chris Chiu |
linux (Ubuntu Focal): status |
In Progress |
Confirmed |
|
2021-05-12 16:20:06 |
Chris Chiu |
linux (Ubuntu Focal): status |
Confirmed |
In Progress |
|
2021-05-12 16:20:09 |
Chris Chiu |
linux (Ubuntu Groovy): status |
Confirmed |
In Progress |
|
2021-05-12 16:20:11 |
Chris Chiu |
linux (Ubuntu Hirsute): status |
Confirmed |
In Progress |
|
2021-05-12 16:20:15 |
Chris Chiu |
linux-oem-5.10 (Ubuntu Focal): status |
Confirmed |
In Progress |
|
2021-05-12 16:26:19 |
Chris Chiu |
bug |
|
|
added subscriber Canonical Hardware Enablement |
2021-05-12 16:26:24 |
Chris Chiu |
tags |
|
oem-priority originate-from-1917005 somerville |
|
2021-05-12 16:30:10 |
Ubuntu Kernel Bot |
linux (Ubuntu): status |
New |
Incomplete |
|
2021-05-12 16:32:45 |
Chris Chiu |
tags |
oem-priority originate-from-1917005 somerville |
oem-priority originate-from-1917005 originate-from-1921742 somerville |
|
2021-05-12 16:39:00 |
Chris Chiu |
tags |
oem-priority originate-from-1917005 originate-from-1921742 somerville |
apport-collected focal oem-priority originate-from-1917005 originate-from-1921742 somerville |
|
2021-05-12 16:39:02 |
Chris Chiu |
description |
[SRU Justification]
[Impact]
All of 3 different WD19(TB/SC/DC) docks have 3 Type-A ports and 2 Type-C ports, and there're highspeed Hubs(0bda:5487 and its substream hub 0bda:5413) and Superspeed Hubs (0bda:0413 and its downstream hub 0bda:5413). In the bug description below, we will refer the 2 highspeed hubs as Hub A and Hub A.3, and the 2 superspeed hubs as Hub B and Hub B.3. All devices connected via either Type-A or Type-C ports will connect to either Hub A.3 or Hub B.3. If we connect a wakup enabled device (keyboard) to a Type-A port, the Hub A.3 will fail to activate after exiting s2idle and all downstream devices will not be detected. If we have a superspeed device connected to other Type-A port in addition to the keyboard, this superspeed device actually connects to Hub B.3, and the Hub B.3 will also fails to work after exiting s2idle. If the wakeup enabled device connects via Type-C port, there's no such problem.
As a summary, a wakeup enabled device connect to Type-A port will cause the failure of Hub A.3 and Hub B.3. Hub B.3 only fails when a wakeup enabled device and a superspeed device both connect via Type-A port.
[Fix]
Before the resume failure, the upstream hub(Hub A or B) will hit the timeout problem while doing SetPortFeature(PORT_SUSPEND) to the port of the downstream hub (Hub A.3 or Hub B.3). However, the PORT_SUSPEND bit of the wPortStatus is actually turned on for the Hub A.3, we simply need to make the kernel believe it's already suspended. Then the ClearPortFeature will be done during resume and the problem will go away.
The Hub B.3 will be tricky. The PORT_SUSPEND bit is not on after the suspend timeout, but we need to reset_resume the Hub B.3 to avoid resume failure. It's hard to create a generic fix for it. Because it only happens when timeout happens on suspending Hub A.3 and there's a superspeed device connecting to Type-A port. I can only reset_resume the problematic hub if the timeout happens during suspend and it happens to be a Realtek hub.
[Test]
1. Make sure that the WD19 connects to the laptop
2. Connect a USB keyboard and a superspeed USB stick to USB Type-A ports.
3. Suspend the system
4. Press the Enter key or power button to wake up the system
5. Check if the keyboard and USB stick are still working
Repeat 4 and 5 for > 10 times w/o losing any USB devices.
[Where problems could occur]
A wakeup enabled device (keyboard) connect to Type-A port will cause the failure of Hub A.3 and Hub B.3 during resume. Hub B.3 only fails when a wakeup enabled device and a superspeed device both connect via Type-A port. All devices connects to Hub A.3 (and B.3 if superspeed device connect via Type-A port) will be lost after resume.
[Regression Potential]
Minimum. The fix is only triggered when timeout happens during USB port suspend and it follows the standard USB protocol to do either resume or reset_resume.
========== Original Bug Description ==========
● Summary
Plug in USB mouse and USB keyboard to WD19/WD19DC USB ports near LAN port. Plug dock into SUT and check USB keyboard and mouse work. SUT enter suspend. After 1 min resume SUT, check USB keyboard/mouse function. Sometimes USB keyboard/mouse no function.
Isolation:
1. VP on UMA and Discrete
2. When issue occur, both front and back port on WD19 can't work using USB keyboard/mouse but USB Key.
● Reproduce Steps
1.Plug in USB mouse and USB keyboard to WD19/WD19DC USB ports near LAN port.
2.Plug dock into SUT and check USB keyboard and mouse work.
3. SUT enter suspend.
4.After 1 min, resume SUT and check USB keyboard/mouse function.
5.Sometimes USB keyboard/mouse no function.
● Results
○ Expected Result
USB mouse or keyboard on dock can use after suspend
○ Actual Result
USB mouse or keyboard on dock sometimes no function after suspend
● Additional Information
○ Test Vault ID:60943.011
○ SKU:Broadmoor Latitude5421
○ BIOS Version:0.3.21
○ Image/Manifest:
dell-bto-focal-fossa-pidgeot-14-X79-20210106-3.iso
dell-bto-focal-fossa-pidgeot-14-X81-20210121-6.iso
○ CPU:TGL ES
○ GPU:Intel pGFX 2020
○ Failure rate:F/R: 2/2 units, 1/10 times
○ WD19 dock, Dock DFU: 1.0.15 |
[SRU Justification]
[Impact]
All of 3 different WD19(TB/SC/DC) docks have 3 Type-A ports and 2 Type-C ports, and there're highspeed Hubs(0bda:5487 and its substream hub 0bda:5413) and Superspeed Hubs (0bda:0413 and its downstream hub 0bda:5413). In the bug description below, we will refer the 2 highspeed hubs as Hub A and Hub A.3, and the 2 superspeed hubs as Hub B and Hub B.3. All devices connected via either Type-A or Type-C ports will connect to either Hub A.3 or Hub B.3. If we connect a wakup enabled device (keyboard) to a Type-A port, the Hub A.3 will fail to activate after exiting s2idle and all downstream devices will not be detected. If we have a superspeed device connected to other Type-A port in addition to the keyboard, this superspeed device actually connects to Hub B.3, and the Hub B.3 will also fails to work after exiting s2idle. If the wakeup enabled device connects via Type-C port, there's no such problem.
As a summary, a wakeup enabled device connect to Type-A port will cause the failure of Hub A.3 and Hub B.3. Hub B.3 only fails when a wakeup enabled device and a superspeed device both connect via Type-A port.
[Fix]
Before the resume failure, the upstream hub(Hub A or B) will hit the timeout problem while doing SetPortFeature(PORT_SUSPEND) to the port of the downstream hub (Hub A.3 or Hub B.3). However, the PORT_SUSPEND bit of the wPortStatus is actually turned on for the Hub A.3, we simply need to make the kernel believe it's already suspended. Then the ClearPortFeature will be done during resume and the problem will go away.
The Hub B.3 will be tricky. The PORT_SUSPEND bit is not on after the suspend timeout, but we need to reset_resume the Hub B.3 to avoid resume failure. It's hard to create a generic fix for it. Because it only happens when timeout happens on suspending Hub A.3 and there's a superspeed device connecting to Type-A port. I can only reset_resume the problematic hub if the timeout happens during suspend and it happens to be a Realtek hub.
[Test]
1. Make sure that the WD19 connects to the laptop
2. Connect a USB keyboard and a superspeed USB stick to USB Type-A ports.
3. Suspend the system
4. Press the Enter key or power button to wake up the system
5. Check if the keyboard and USB stick are still working
Repeat 4 and 5 for > 10 times w/o losing any USB devices.
[Where problems could occur]
A wakeup enabled device (keyboard) connect to Type-A port will cause the failure of Hub A.3 and Hub B.3 during resume. Hub B.3 only fails when a wakeup enabled device and a superspeed device both connect via Type-A port. All devices connects to Hub A.3 (and B.3 if superspeed device connect via Type-A port) will be lost after resume.
[Regression Potential]
Minimum. The fix is only triggered when timeout happens during USB port suspend and it follows the standard USB protocol to do either resume or reset_resume.
========== Original Bug Description ==========
● Summary
Plug in USB mouse and USB keyboard to WD19/WD19DC USB ports near LAN port. Plug dock into SUT and check USB keyboard and mouse work. SUT enter suspend. After 1 min resume SUT, check USB keyboard/mouse function. Sometimes USB keyboard/mouse no function.
Isolation:
1. VP on UMA and Discrete
2. When issue occur, both front and back port on WD19 can't work using USB keyboard/mouse but USB Key.
● Reproduce Steps
1.Plug in USB mouse and USB keyboard to WD19/WD19DC USB ports near LAN port.
2.Plug dock into SUT and check USB keyboard and mouse work.
3. SUT enter suspend.
4.After 1 min, resume SUT and check USB keyboard/mouse function.
5.Sometimes USB keyboard/mouse no function.
● Results
○ Expected Result
USB mouse or keyboard on dock can use after suspend
○ Actual Result
USB mouse or keyboard on dock sometimes no function after suspend
● Additional Information
○ Test Vault ID:60943.011
○ SKU:Broadmoor Latitude5421
○ BIOS Version:0.3.21
○ Image/Manifest:
dell-bto-focal-fossa-pidgeot-14-X79-20210106-3.iso
dell-bto-focal-fossa-pidgeot-14-X81-20210121-6.iso
○ CPU:TGL ES
○ GPU:Intel pGFX 2020
○ Failure rate:F/R: 2/2 units, 1/10 times
○ WD19 dock, Dock DFU: 1.0.15
---
ProblemType: Bug
ApportVersion: 2.20.11-0ubuntu27.16
Architecture: amd64
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/controlC1: u 2632 F.... pulseaudio
/dev/snd/controlC0: u 2632 F.... pulseaudio
CasperMD5CheckResult: skip
CurrentDesktop: ubuntu:GNOME
DistributionChannelDescriptor:
# This is the distribution channel descriptor for the OEM CDs
# For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor
canonical-oem-somerville-focal-amd64-20200502-85+fossa-pidgey+X90
DistroRelease: Ubuntu 20.04
InstallationDate: Installed on 2021-04-20 (22 days ago)
InstallationMedia: Ubuntu 20.04 "Focal" - Build amd64 LIVE Binary 20200502-05:58
MachineType: Dell Inc. Precision 5560
Package: linux-oem-5.10
ProcFB: 0 i915drmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.10.0-1023-oem root=UUID=0a51d1e3-2a97-46b9-87cf-912821ab4aa0 ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 5.10.0-1023.24-oem 5.10.25
RelatedPackageVersions:
linux-restricted-modules-5.10.0-1023-oem N/A
linux-backports-modules-5.10.0-1023-oem N/A
linux-firmware 1.187.10
Tags: focal
Uname: Linux 5.10.0-1023-oem x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 04/01/2021
dmi.bios.release: 0.4
dmi.bios.vendor: Dell Inc.
dmi.bios.version: 0.4.4
dmi.board.vendor: Dell Inc.
dmi.chassis.asset.tag: 7654321
dmi.chassis.type: 10
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvr0.4.4:bd04/01/2021:br0.4:svnDellInc.:pnPrecision5560:pvr:rvnDellInc.:rn:rvr:cvnDellInc.:ct10:cvr:
dmi.product.family: Precision
dmi.product.name: Precision 5560
dmi.product.sku: 0A62
dmi.sys.vendor: Dell Inc. |
|
2021-05-12 16:39:04 |
Chris Chiu |
attachment added |
|
AlsaInfo.txt https://bugs.launchpad.net/bugs/1928242/+attachment/5496688/+files/AlsaInfo.txt |
|
2021-05-12 16:39:06 |
Chris Chiu |
attachment added |
|
CRDA.txt https://bugs.launchpad.net/bugs/1928242/+attachment/5496689/+files/CRDA.txt |
|
2021-05-12 16:39:09 |
Chris Chiu |
attachment added |
|
CurrentDmesg.txt https://bugs.launchpad.net/bugs/1928242/+attachment/5496690/+files/CurrentDmesg.txt |
|
2021-05-12 16:39:12 |
Chris Chiu |
attachment added |
|
IwConfig.txt https://bugs.launchpad.net/bugs/1928242/+attachment/5496691/+files/IwConfig.txt |
|
2021-05-12 16:39:14 |
Chris Chiu |
attachment added |
|
Lspci.txt https://bugs.launchpad.net/bugs/1928242/+attachment/5496692/+files/Lspci.txt |
|
2021-05-12 16:39:16 |
Chris Chiu |
attachment added |
|
Lspci-vt.txt https://bugs.launchpad.net/bugs/1928242/+attachment/5496693/+files/Lspci-vt.txt |
|
2021-05-12 16:39:19 |
Chris Chiu |
attachment added |
|
Lsusb.txt https://bugs.launchpad.net/bugs/1928242/+attachment/5496694/+files/Lsusb.txt |
|
2021-05-12 16:39:21 |
Chris Chiu |
attachment added |
|
Lsusb-t.txt https://bugs.launchpad.net/bugs/1928242/+attachment/5496695/+files/Lsusb-t.txt |
|
2021-05-12 16:39:24 |
Chris Chiu |
attachment added |
|
Lsusb-v.txt https://bugs.launchpad.net/bugs/1928242/+attachment/5496696/+files/Lsusb-v.txt |
|
2021-05-12 16:39:26 |
Chris Chiu |
attachment added |
|
ProcCpuinfo.txt https://bugs.launchpad.net/bugs/1928242/+attachment/5496697/+files/ProcCpuinfo.txt |
|
2021-05-12 16:39:28 |
Chris Chiu |
attachment added |
|
ProcCpuinfoMinimal.txt https://bugs.launchpad.net/bugs/1928242/+attachment/5496698/+files/ProcCpuinfoMinimal.txt |
|
2021-05-12 16:39:31 |
Chris Chiu |
attachment added |
|
ProcEnviron.txt https://bugs.launchpad.net/bugs/1928242/+attachment/5496699/+files/ProcEnviron.txt |
|
2021-05-12 16:39:33 |
Chris Chiu |
attachment added |
|
ProcInterrupts.txt https://bugs.launchpad.net/bugs/1928242/+attachment/5496700/+files/ProcInterrupts.txt |
|
2021-05-12 16:39:35 |
Chris Chiu |
attachment added |
|
ProcModules.txt https://bugs.launchpad.net/bugs/1928242/+attachment/5496701/+files/ProcModules.txt |
|
2021-05-12 16:39:38 |
Chris Chiu |
attachment added |
|
PulseList.txt https://bugs.launchpad.net/bugs/1928242/+attachment/5496702/+files/PulseList.txt |
|
2021-05-12 16:39:41 |
Chris Chiu |
attachment added |
|
RfKill.txt https://bugs.launchpad.net/bugs/1928242/+attachment/5496703/+files/RfKill.txt |
|
2021-05-12 16:39:44 |
Chris Chiu |
attachment added |
|
UdevDb.txt https://bugs.launchpad.net/bugs/1928242/+attachment/5496704/+files/UdevDb.txt |
|
2021-05-12 16:39:48 |
Chris Chiu |
attachment added |
|
WifiSyslog.txt https://bugs.launchpad.net/bugs/1928242/+attachment/5496705/+files/WifiSyslog.txt |
|
2021-05-12 16:39:54 |
Chris Chiu |
attachment added |
|
acpidump.txt https://bugs.launchpad.net/bugs/1928242/+attachment/5496706/+files/acpidump.txt |
|
2021-05-12 17:07:38 |
Chris Chiu |
linux (Ubuntu Focal): status |
In Progress |
Invalid |
|
2021-05-12 17:10:24 |
Chris Chiu |
nominated for series |
|
Ubuntu Impish |
|
2021-05-12 17:10:24 |
Chris Chiu |
bug task added |
|
linux (Ubuntu Impish) |
|
2021-05-12 17:10:24 |
Chris Chiu |
bug task added |
|
linux-oem-5.10 (Ubuntu Impish) |
|
2021-05-12 17:11:00 |
Chris Chiu |
linux-oem-5.10 (Ubuntu Groovy): status |
New |
Invalid |
|
2021-05-12 17:11:13 |
Chris Chiu |
linux-oem-5.10 (Ubuntu Hirsute): status |
New |
Invalid |
|
2021-05-12 17:11:29 |
Chris Chiu |
linux-oem-5.10 (Ubuntu Impish): status |
New |
Invalid |
|
2021-05-12 17:11:52 |
Chris Chiu |
linux (Ubuntu Impish): status |
Incomplete |
In Progress |
|
2021-05-13 07:49:18 |
Rex Tsai |
bug |
|
|
added subscriber Rex Tsai |
2021-05-16 02:33:32 |
Chris Chiu |
description |
[SRU Justification]
[Impact]
All of 3 different WD19(TB/SC/DC) docks have 3 Type-A ports and 2 Type-C ports, and there're highspeed Hubs(0bda:5487 and its substream hub 0bda:5413) and Superspeed Hubs (0bda:0413 and its downstream hub 0bda:5413). In the bug description below, we will refer the 2 highspeed hubs as Hub A and Hub A.3, and the 2 superspeed hubs as Hub B and Hub B.3. All devices connected via either Type-A or Type-C ports will connect to either Hub A.3 or Hub B.3. If we connect a wakup enabled device (keyboard) to a Type-A port, the Hub A.3 will fail to activate after exiting s2idle and all downstream devices will not be detected. If we have a superspeed device connected to other Type-A port in addition to the keyboard, this superspeed device actually connects to Hub B.3, and the Hub B.3 will also fails to work after exiting s2idle. If the wakeup enabled device connects via Type-C port, there's no such problem.
As a summary, a wakeup enabled device connect to Type-A port will cause the failure of Hub A.3 and Hub B.3. Hub B.3 only fails when a wakeup enabled device and a superspeed device both connect via Type-A port.
[Fix]
Before the resume failure, the upstream hub(Hub A or B) will hit the timeout problem while doing SetPortFeature(PORT_SUSPEND) to the port of the downstream hub (Hub A.3 or Hub B.3). However, the PORT_SUSPEND bit of the wPortStatus is actually turned on for the Hub A.3, we simply need to make the kernel believe it's already suspended. Then the ClearPortFeature will be done during resume and the problem will go away.
The Hub B.3 will be tricky. The PORT_SUSPEND bit is not on after the suspend timeout, but we need to reset_resume the Hub B.3 to avoid resume failure. It's hard to create a generic fix for it. Because it only happens when timeout happens on suspending Hub A.3 and there's a superspeed device connecting to Type-A port. I can only reset_resume the problematic hub if the timeout happens during suspend and it happens to be a Realtek hub.
[Test]
1. Make sure that the WD19 connects to the laptop
2. Connect a USB keyboard and a superspeed USB stick to USB Type-A ports.
3. Suspend the system
4. Press the Enter key or power button to wake up the system
5. Check if the keyboard and USB stick are still working
Repeat 4 and 5 for > 10 times w/o losing any USB devices.
[Where problems could occur]
A wakeup enabled device (keyboard) connect to Type-A port will cause the failure of Hub A.3 and Hub B.3 during resume. Hub B.3 only fails when a wakeup enabled device and a superspeed device both connect via Type-A port. All devices connects to Hub A.3 (and B.3 if superspeed device connect via Type-A port) will be lost after resume.
[Regression Potential]
Minimum. The fix is only triggered when timeout happens during USB port suspend and it follows the standard USB protocol to do either resume or reset_resume.
========== Original Bug Description ==========
● Summary
Plug in USB mouse and USB keyboard to WD19/WD19DC USB ports near LAN port. Plug dock into SUT and check USB keyboard and mouse work. SUT enter suspend. After 1 min resume SUT, check USB keyboard/mouse function. Sometimes USB keyboard/mouse no function.
Isolation:
1. VP on UMA and Discrete
2. When issue occur, both front and back port on WD19 can't work using USB keyboard/mouse but USB Key.
● Reproduce Steps
1.Plug in USB mouse and USB keyboard to WD19/WD19DC USB ports near LAN port.
2.Plug dock into SUT and check USB keyboard and mouse work.
3. SUT enter suspend.
4.After 1 min, resume SUT and check USB keyboard/mouse function.
5.Sometimes USB keyboard/mouse no function.
● Results
○ Expected Result
USB mouse or keyboard on dock can use after suspend
○ Actual Result
USB mouse or keyboard on dock sometimes no function after suspend
● Additional Information
○ Test Vault ID:60943.011
○ SKU:Broadmoor Latitude5421
○ BIOS Version:0.3.21
○ Image/Manifest:
dell-bto-focal-fossa-pidgeot-14-X79-20210106-3.iso
dell-bto-focal-fossa-pidgeot-14-X81-20210121-6.iso
○ CPU:TGL ES
○ GPU:Intel pGFX 2020
○ Failure rate:F/R: 2/2 units, 1/10 times
○ WD19 dock, Dock DFU: 1.0.15
---
ProblemType: Bug
ApportVersion: 2.20.11-0ubuntu27.16
Architecture: amd64
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/controlC1: u 2632 F.... pulseaudio
/dev/snd/controlC0: u 2632 F.... pulseaudio
CasperMD5CheckResult: skip
CurrentDesktop: ubuntu:GNOME
DistributionChannelDescriptor:
# This is the distribution channel descriptor for the OEM CDs
# For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor
canonical-oem-somerville-focal-amd64-20200502-85+fossa-pidgey+X90
DistroRelease: Ubuntu 20.04
InstallationDate: Installed on 2021-04-20 (22 days ago)
InstallationMedia: Ubuntu 20.04 "Focal" - Build amd64 LIVE Binary 20200502-05:58
MachineType: Dell Inc. Precision 5560
Package: linux-oem-5.10
ProcFB: 0 i915drmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.10.0-1023-oem root=UUID=0a51d1e3-2a97-46b9-87cf-912821ab4aa0 ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 5.10.0-1023.24-oem 5.10.25
RelatedPackageVersions:
linux-restricted-modules-5.10.0-1023-oem N/A
linux-backports-modules-5.10.0-1023-oem N/A
linux-firmware 1.187.10
Tags: focal
Uname: Linux 5.10.0-1023-oem x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 04/01/2021
dmi.bios.release: 0.4
dmi.bios.vendor: Dell Inc.
dmi.bios.version: 0.4.4
dmi.board.vendor: Dell Inc.
dmi.chassis.asset.tag: 7654321
dmi.chassis.type: 10
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvr0.4.4:bd04/01/2021:br0.4:svnDellInc.:pnPrecision5560:pvr:rvnDellInc.:rn:rvr:cvnDellInc.:ct10:cvr:
dmi.product.family: Precision
dmi.product.name: Precision 5560
dmi.product.sku: 0A62
dmi.sys.vendor: Dell Inc. |
[SRU Justification]
[Impact]
All of 3 different WD19(TB/SC/DC) docks have 3 Type-A ports and 2 Type-C ports, and there're highspeed Hubs(0bda:5487 and its substream hub 0bda:5413) and Superspeed Hubs (0bda:0487 and its downstream hub 0bda:0413). In the bug description below, we will refer the 2 highspeed hubs as Hub A and Hub A.3, and the 2 superspeed hubs as Hub B and Hub B.3. All devices connected via either Type-A or Type-C ports will connect to either Hub A.3 or Hub B.3. If we connect a wakup enabled device (keyboard) to a Type-A port, the Hub A.3 will fail to activate after exiting s2idle and all downstream devices will not be detected. If we have a superspeed device connected to other Type-A port in addition to the keyboard, this superspeed device actually connects to Hub B.3, and the Hub B.3 will also fails to work after exiting s2idle. If the wakeup enabled device connects via Type-C port, there's no such problem.
As a summary, a wakeup enabled device connect to Type-A port will cause the failure of Hub A.3 and Hub B.3. Hub B.3 only fails when a wakeup enabled device and a superspeed device both connect via Type-A port.
[Fix]
Before the resume failure, the upstream hub(Hub A or B) will hit the timeout problem while doing SetPortFeature(PORT_SUSPEND) to the port of the downstream hub (Hub A.3 or Hub B.3). However, the PORT_SUSPEND bit of the wPortStatus is actually turned on for the Hub A.3, we simply need to make the kernel believe it's already suspended. Then the ClearPortFeature will be done during resume and the problem will go away.
The Hub B.3 will be tricky. The PORT_SUSPEND bit is not on after the suspend timeout, but we need to reset_resume the Hub B.3 to avoid resume failure. It's hard to create a generic fix for it. Because it only happens when timeout happens on suspending Hub A.3 and there's a superspeed device connecting to Type-A port. I can only reset_resume the problematic hub if the timeout happens during suspend and it happens to be a Realtek hub.
[Test]
1. Make sure that the WD19 connects to the laptop
2. Connect a USB keyboard and a superspeed USB stick to USB Type-A ports.
3. Suspend the system
4. Press the Enter key or power button to wake up the system
5. Check if the keyboard and USB stick are still working
Repeat 4 and 5 for > 10 times w/o losing any USB devices.
[Where problems could occur]
A wakeup enabled device (keyboard) connect to Type-A port will cause the failure of Hub A.3 and Hub B.3 during resume. Hub B.3 only fails when a wakeup enabled device and a superspeed device both connect via Type-A port. All devices connects to Hub A.3 (and B.3 if superspeed device connect via Type-A port) will be lost after resume.
[Regression Potential]
Minimum. The fix is only triggered when timeout happens during USB port suspend and it follows the standard USB protocol to do either resume or reset_resume.
========== Original Bug Description ==========
● Summary
Plug in USB mouse and USB keyboard to WD19/WD19DC USB ports near LAN port. Plug dock into SUT and check USB keyboard and mouse work. SUT enter suspend. After 1 min resume SUT, check USB keyboard/mouse function. Sometimes USB keyboard/mouse no function.
Isolation:
1. VP on UMA and Discrete
2. When issue occur, both front and back port on WD19 can't work using USB keyboard/mouse but USB Key.
● Reproduce Steps
1.Plug in USB mouse and USB keyboard to WD19/WD19DC USB ports near LAN port.
2.Plug dock into SUT and check USB keyboard and mouse work.
3. SUT enter suspend.
4.After 1 min, resume SUT and check USB keyboard/mouse function.
5.Sometimes USB keyboard/mouse no function.
● Results
○ Expected Result
USB mouse or keyboard on dock can use after suspend
○ Actual Result
USB mouse or keyboard on dock sometimes no function after suspend
● Additional Information
○ Test Vault ID:60943.011
○ SKU:Broadmoor Latitude5421
○ BIOS Version:0.3.21
○ Image/Manifest:
dell-bto-focal-fossa-pidgeot-14-X79-20210106-3.iso
dell-bto-focal-fossa-pidgeot-14-X81-20210121-6.iso
○ CPU:TGL ES
○ GPU:Intel pGFX 2020
○ Failure rate:F/R: 2/2 units, 1/10 times
○ WD19 dock, Dock DFU: 1.0.15
---
ProblemType: Bug
ApportVersion: 2.20.11-0ubuntu27.16
Architecture: amd64
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/controlC1: u 2632 F.... pulseaudio
/dev/snd/controlC0: u 2632 F.... pulseaudio
CasperMD5CheckResult: skip
CurrentDesktop: ubuntu:GNOME
DistributionChannelDescriptor:
# This is the distribution channel descriptor for the OEM CDs
# For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor
canonical-oem-somerville-focal-amd64-20200502-85+fossa-pidgey+X90
DistroRelease: Ubuntu 20.04
InstallationDate: Installed on 2021-04-20 (22 days ago)
InstallationMedia: Ubuntu 20.04 "Focal" - Build amd64 LIVE Binary 20200502-05:58
MachineType: Dell Inc. Precision 5560
Package: linux-oem-5.10
ProcFB: 0 i915drmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.10.0-1023-oem root=UUID=0a51d1e3-2a97-46b9-87cf-912821ab4aa0 ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 5.10.0-1023.24-oem 5.10.25
RelatedPackageVersions:
linux-restricted-modules-5.10.0-1023-oem N/A
linux-backports-modules-5.10.0-1023-oem N/A
linux-firmware 1.187.10
Tags: focal
Uname: Linux 5.10.0-1023-oem x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 04/01/2021
dmi.bios.release: 0.4
dmi.bios.vendor: Dell Inc.
dmi.bios.version: 0.4.4
dmi.board.vendor: Dell Inc.
dmi.chassis.asset.tag: 7654321
dmi.chassis.type: 10
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvr0.4.4:bd04/01/2021:br0.4:svnDellInc.:pnPrecision5560:pvr:rvnDellInc.:rn:rvr:cvnDellInc.:ct10:cvr:
dmi.product.family: Precision
dmi.product.name: Precision 5560
dmi.product.sku: 0A62
dmi.sys.vendor: Dell Inc. |
|
2021-05-21 03:33:19 |
Chris Chiu |
description |
[SRU Justification]
[Impact]
All of 3 different WD19(TB/SC/DC) docks have 3 Type-A ports and 2 Type-C ports, and there're highspeed Hubs(0bda:5487 and its substream hub 0bda:5413) and Superspeed Hubs (0bda:0487 and its downstream hub 0bda:0413). In the bug description below, we will refer the 2 highspeed hubs as Hub A and Hub A.3, and the 2 superspeed hubs as Hub B and Hub B.3. All devices connected via either Type-A or Type-C ports will connect to either Hub A.3 or Hub B.3. If we connect a wakup enabled device (keyboard) to a Type-A port, the Hub A.3 will fail to activate after exiting s2idle and all downstream devices will not be detected. If we have a superspeed device connected to other Type-A port in addition to the keyboard, this superspeed device actually connects to Hub B.3, and the Hub B.3 will also fails to work after exiting s2idle. If the wakeup enabled device connects via Type-C port, there's no such problem.
As a summary, a wakeup enabled device connect to Type-A port will cause the failure of Hub A.3 and Hub B.3. Hub B.3 only fails when a wakeup enabled device and a superspeed device both connect via Type-A port.
[Fix]
Before the resume failure, the upstream hub(Hub A or B) will hit the timeout problem while doing SetPortFeature(PORT_SUSPEND) to the port of the downstream hub (Hub A.3 or Hub B.3). However, the PORT_SUSPEND bit of the wPortStatus is actually turned on for the Hub A.3, we simply need to make the kernel believe it's already suspended. Then the ClearPortFeature will be done during resume and the problem will go away.
The Hub B.3 will be tricky. The PORT_SUSPEND bit is not on after the suspend timeout, but we need to reset_resume the Hub B.3 to avoid resume failure. It's hard to create a generic fix for it. Because it only happens when timeout happens on suspending Hub A.3 and there's a superspeed device connecting to Type-A port. I can only reset_resume the problematic hub if the timeout happens during suspend and it happens to be a Realtek hub.
[Test]
1. Make sure that the WD19 connects to the laptop
2. Connect a USB keyboard and a superspeed USB stick to USB Type-A ports.
3. Suspend the system
4. Press the Enter key or power button to wake up the system
5. Check if the keyboard and USB stick are still working
Repeat 4 and 5 for > 10 times w/o losing any USB devices.
[Where problems could occur]
A wakeup enabled device (keyboard) connect to Type-A port will cause the failure of Hub A.3 and Hub B.3 during resume. Hub B.3 only fails when a wakeup enabled device and a superspeed device both connect via Type-A port. All devices connects to Hub A.3 (and B.3 if superspeed device connect via Type-A port) will be lost after resume.
[Regression Potential]
Minimum. The fix is only triggered when timeout happens during USB port suspend and it follows the standard USB protocol to do either resume or reset_resume.
========== Original Bug Description ==========
● Summary
Plug in USB mouse and USB keyboard to WD19/WD19DC USB ports near LAN port. Plug dock into SUT and check USB keyboard and mouse work. SUT enter suspend. After 1 min resume SUT, check USB keyboard/mouse function. Sometimes USB keyboard/mouse no function.
Isolation:
1. VP on UMA and Discrete
2. When issue occur, both front and back port on WD19 can't work using USB keyboard/mouse but USB Key.
● Reproduce Steps
1.Plug in USB mouse and USB keyboard to WD19/WD19DC USB ports near LAN port.
2.Plug dock into SUT and check USB keyboard and mouse work.
3. SUT enter suspend.
4.After 1 min, resume SUT and check USB keyboard/mouse function.
5.Sometimes USB keyboard/mouse no function.
● Results
○ Expected Result
USB mouse or keyboard on dock can use after suspend
○ Actual Result
USB mouse or keyboard on dock sometimes no function after suspend
● Additional Information
○ Test Vault ID:60943.011
○ SKU:Broadmoor Latitude5421
○ BIOS Version:0.3.21
○ Image/Manifest:
dell-bto-focal-fossa-pidgeot-14-X79-20210106-3.iso
dell-bto-focal-fossa-pidgeot-14-X81-20210121-6.iso
○ CPU:TGL ES
○ GPU:Intel pGFX 2020
○ Failure rate:F/R: 2/2 units, 1/10 times
○ WD19 dock, Dock DFU: 1.0.15
---
ProblemType: Bug
ApportVersion: 2.20.11-0ubuntu27.16
Architecture: amd64
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/controlC1: u 2632 F.... pulseaudio
/dev/snd/controlC0: u 2632 F.... pulseaudio
CasperMD5CheckResult: skip
CurrentDesktop: ubuntu:GNOME
DistributionChannelDescriptor:
# This is the distribution channel descriptor for the OEM CDs
# For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor
canonical-oem-somerville-focal-amd64-20200502-85+fossa-pidgey+X90
DistroRelease: Ubuntu 20.04
InstallationDate: Installed on 2021-04-20 (22 days ago)
InstallationMedia: Ubuntu 20.04 "Focal" - Build amd64 LIVE Binary 20200502-05:58
MachineType: Dell Inc. Precision 5560
Package: linux-oem-5.10
ProcFB: 0 i915drmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.10.0-1023-oem root=UUID=0a51d1e3-2a97-46b9-87cf-912821ab4aa0 ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 5.10.0-1023.24-oem 5.10.25
RelatedPackageVersions:
linux-restricted-modules-5.10.0-1023-oem N/A
linux-backports-modules-5.10.0-1023-oem N/A
linux-firmware 1.187.10
Tags: focal
Uname: Linux 5.10.0-1023-oem x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 04/01/2021
dmi.bios.release: 0.4
dmi.bios.vendor: Dell Inc.
dmi.bios.version: 0.4.4
dmi.board.vendor: Dell Inc.
dmi.chassis.asset.tag: 7654321
dmi.chassis.type: 10
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvr0.4.4:bd04/01/2021:br0.4:svnDellInc.:pnPrecision5560:pvr:rvnDellInc.:rn:rvr:cvnDellInc.:ct10:cvr:
dmi.product.family: Precision
dmi.product.name: Precision 5560
dmi.product.sku: 0A62
dmi.sys.vendor: Dell Inc. |
[SRU Justification]
[Impact]
All of 3 different WD19(TB/SC/DC) docks have 3 Type-A ports and 2 Type-C ports, and there're highspeed Hubs(0bda:5487 and its substream hub 0bda:5413) and Superspeed Hubs (0bda:0487 and its downstream hub 0bda:0413). In the bug description below, we will refer the 2 highspeed hubs as Hub A and Hub A.3, and the 2 superspeed hubs as Hub B and Hub B.3. All devices connected via either Type-A or Type-C ports will connect to either Hub A.3 or Hub B.3. If we connect a wakup enabled device (keyboard) to a Type-A port, the Hub A.3 will fail to activate after exiting s2idle and all downstream devices will not be detected. If we have a superspeed device connected to other Type-A port in addition to the keyboard, this superspeed device actually connects to Hub B.3, and the Hub B.3 will also fails to work after exiting s2idle. If the wakeup enabled device connects via Type-C port, there's no such problem.
As a summary, a wakeup enabled device connect to Type-A port will cause the failure of Hub A.3 and Hub B.3. Hub B.3 only fails when a wakeup enabled device and a superspeed device both connect via Type-A port.
[Fix]
Before the resume failure, the upstream hub(Hub A or B) will hit the timeout problem while doing SetPortFeature(PORT_SUSPEND) to the port of the downstream hub (Hub A.3 or Hub B.3). However, the PORT_SUSPEND bit of the wPortStatus is actually turned on for the Hub A.3, we simply need to make the kernel believe it's already suspended. Then the ClearPortFeature will be done during resume and the problem will go away.
The Hub B.3 will be tricky. The PORT_SUSPEND bit is not on after the suspend timeout, but it needs the ClearPortFeature(PORT_SUSPEND) for Hub B.3 to avoid resume failure. It doesn't comply with the USB spec so it's hard to create a generic fix for it. Because it only happens when timeout happens on suspending Hub A.3 and there's a superspeed device connecting to Type-A port, we choose to leave it as-is and try to address it in the future.
[Test Case]
1. Make sure that the WD19 connects to the laptop
2. Connect USB keyboard/mouse to USB Type-A ports.
3. Suspend the system
4. Press the Enter key or power button to wake up the system
5. Check if the USB keyboard/mouse are still working
Repeat 4 and 5 for > 10 times w/o losing any USB devices.
[Where problems could occur]
A wakeup enabled device (keyboard) connect to Type-A port will cause the failure of Hub A.3 and Hub B.3 during resume. Hub B.3 only fails when a wakeup enabled device and a superspeed device both connect via Type-A port. All devices connects to Hub A.3 (and B.3 if superspeed device connect via Type-A port) will be lost after resume.
[Regression Potential]
Minimum. The fix is only triggered when timeout happens during USB port suspend and it follows the standard USB protocol to do either resume or reset_resume.
========== Original Bug Description ==========
● Summary
Plug in USB mouse and USB keyboard to WD19/WD19DC USB ports near LAN port. Plug dock into SUT and check USB keyboard and mouse work. SUT enter suspend. After 1 min resume SUT, check USB keyboard/mouse function. Sometimes USB keyboard/mouse no function.
Isolation:
1. VP on UMA and Discrete
2. When issue occur, both front and back port on WD19 can't work using USB keyboard/mouse but USB Key.
● Reproduce Steps
1.Plug in USB mouse and USB keyboard to WD19/WD19DC USB ports near LAN port.
2.Plug dock into SUT and check USB keyboard and mouse work.
3. SUT enter suspend.
4.After 1 min, resume SUT and check USB keyboard/mouse function.
5.Sometimes USB keyboard/mouse no function.
● Results
○ Expected Result
USB mouse or keyboard on dock can use after suspend
○ Actual Result
USB mouse or keyboard on dock sometimes no function after suspend
● Additional Information
○ Test Vault ID:60943.011
○ SKU:Broadmoor Latitude5421
○ BIOS Version:0.3.21
○ Image/Manifest:
dell-bto-focal-fossa-pidgeot-14-X79-20210106-3.iso
dell-bto-focal-fossa-pidgeot-14-X81-20210121-6.iso
○ CPU:TGL ES
○ GPU:Intel pGFX 2020
○ Failure rate:F/R: 2/2 units, 1/10 times
○ WD19 dock, Dock DFU: 1.0.15
---
ProblemType: Bug
ApportVersion: 2.20.11-0ubuntu27.16
Architecture: amd64
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/controlC1: u 2632 F.... pulseaudio
/dev/snd/controlC0: u 2632 F.... pulseaudio
CasperMD5CheckResult: skip
CurrentDesktop: ubuntu:GNOME
DistributionChannelDescriptor:
# This is the distribution channel descriptor for the OEM CDs
# For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor
canonical-oem-somerville-focal-amd64-20200502-85+fossa-pidgey+X90
DistroRelease: Ubuntu 20.04
InstallationDate: Installed on 2021-04-20 (22 days ago)
InstallationMedia: Ubuntu 20.04 "Focal" - Build amd64 LIVE Binary 20200502-05:58
MachineType: Dell Inc. Precision 5560
Package: linux-oem-5.10
ProcFB: 0 i915drmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.10.0-1023-oem root=UUID=0a51d1e3-2a97-46b9-87cf-912821ab4aa0 ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 5.10.0-1023.24-oem 5.10.25
RelatedPackageVersions:
linux-restricted-modules-5.10.0-1023-oem N/A
linux-backports-modules-5.10.0-1023-oem N/A
linux-firmware 1.187.10
Tags: focal
Uname: Linux 5.10.0-1023-oem x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 04/01/2021
dmi.bios.release: 0.4
dmi.bios.vendor: Dell Inc.
dmi.bios.version: 0.4.4
dmi.board.vendor: Dell Inc.
dmi.chassis.asset.tag: 7654321
dmi.chassis.type: 10
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvr0.4.4:bd04/01/2021:br0.4:svnDellInc.:pnPrecision5560:pvr:rvnDellInc.:rn:rvr:cvnDellInc.:ct10:cvr:
dmi.product.family: Precision
dmi.product.name: Precision 5560
dmi.product.sku: 0A62
dmi.sys.vendor: Dell Inc. |
|
2021-05-21 06:02:40 |
Timo Aaltonen |
linux-oem-5.10 (Ubuntu Focal): status |
In Progress |
Fix Committed |
|
2021-05-26 06:45:06 |
Timo Aaltonen |
tags |
apport-collected focal oem-priority originate-from-1917005 originate-from-1921742 somerville |
apport-collected focal oem-priority originate-from-1917005 originate-from-1921742 somerville verification-needed-focal |
|
2021-05-27 01:23:48 |
Chris Chiu |
linux (Ubuntu Focal): status |
Invalid |
In Progress |
|
2021-05-27 01:29:36 |
Chris Chiu |
tags |
apport-collected focal oem-priority originate-from-1917005 originate-from-1921742 somerville verification-needed-focal |
apport-collected focal oem-priority originate-from-1917005 originate-from-1921742 somerville verification-done-focal |
|
2021-05-27 13:31:37 |
Kleber Sacilotto de Souza |
linux (Ubuntu Focal): status |
In Progress |
Fix Committed |
|
2021-05-27 13:31:46 |
Kleber Sacilotto de Souza |
linux (Ubuntu Groovy): status |
In Progress |
Fix Committed |
|
2021-05-27 13:31:49 |
Kleber Sacilotto de Souza |
linux (Ubuntu Hirsute): status |
In Progress |
Fix Committed |
|
2021-06-02 19:59:11 |
Ubuntu Kernel Bot |
tags |
apport-collected focal oem-priority originate-from-1917005 originate-from-1921742 somerville verification-done-focal |
apport-collected focal oem-priority originate-from-1917005 originate-from-1921742 somerville verification-done-focal verification-needed-hirsute |
|
2021-06-02 20:18:49 |
Launchpad Janitor |
linux-oem-5.10 (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
2021-06-02 20:18:49 |
Launchpad Janitor |
cve linked |
|
2021-33200 |
|
2021-06-05 17:23:02 |
Ubuntu Kernel Bot |
tags |
apport-collected focal oem-priority originate-from-1917005 originate-from-1921742 somerville verification-done-focal verification-needed-hirsute |
apport-collected focal oem-priority originate-from-1917005 originate-from-1921742 somerville verification-done-focal verification-needed-groovy verification-needed-hirsute |
|
2021-06-07 03:11:49 |
Chris Chiu |
tags |
apport-collected focal oem-priority originate-from-1917005 originate-from-1921742 somerville verification-done-focal verification-needed-groovy verification-needed-hirsute |
apport-collected focal oem-priority originate-from-1917005 originate-from-1921742 somerville verification-done-focal verification-done-groovy verification-done-hirsute |
|
2021-06-21 23:22:10 |
Launchpad Janitor |
linux (Ubuntu Impish): status |
In Progress |
Fix Released |
|
2021-06-21 23:22:10 |
Launchpad Janitor |
cve linked |
|
2020-24586 |
|
2021-06-21 23:22:10 |
Launchpad Janitor |
cve linked |
|
2020-24587 |
|
2021-06-21 23:22:10 |
Launchpad Janitor |
cve linked |
|
2020-24588 |
|
2021-06-21 23:22:10 |
Launchpad Janitor |
cve linked |
|
2020-26139 |
|
2021-06-21 23:22:10 |
Launchpad Janitor |
cve linked |
|
2020-26141 |
|
2021-06-21 23:22:10 |
Launchpad Janitor |
cve linked |
|
2020-26145 |
|
2021-06-21 23:22:10 |
Launchpad Janitor |
cve linked |
|
2020-26147 |
|
2021-06-21 23:22:10 |
Launchpad Janitor |
cve linked |
|
2021-20288 |
|
2021-06-21 23:22:10 |
Launchpad Janitor |
cve linked |
|
2021-3489 |
|
2021-06-21 23:22:10 |
Launchpad Janitor |
cve linked |
|
2021-3490 |
|
2021-06-22 16:01:10 |
Launchpad Janitor |
linux (Ubuntu Hirsute): status |
Fix Committed |
Fix Released |
|
2021-06-22 16:03:26 |
Launchpad Janitor |
linux (Ubuntu Groovy): status |
Fix Committed |
Fix Released |
|
2021-06-22 16:03:26 |
Launchpad Janitor |
cve linked |
|
2021-23133 |
|
2021-06-22 16:03:26 |
Launchpad Janitor |
cve linked |
|
2021-31440 |
|
2021-06-22 16:05:32 |
Launchpad Janitor |
linux (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
2021-06-30 04:54:17 |
Anthony Wong |
hwe-next: status |
New |
Fix Released |
|
2021-07-01 06:15:28 |
Anthony Wong |
linux (Ubuntu Impish): status |
Fix Released |
Confirmed |
|
2021-07-02 09:01:50 |
Timo Aaltonen |
bug task added |
|
linux-oem-5.13 (Ubuntu) |
|
2021-07-02 09:02:02 |
Timo Aaltonen |
linux-oem-5.13 (Ubuntu Groovy): status |
New |
Invalid |
|
2021-07-02 09:02:18 |
Timo Aaltonen |
linux-oem-5.13 (Ubuntu Focal): status |
New |
Fix Committed |
|
2021-07-02 09:02:31 |
Timo Aaltonen |
linux-oem-5.13 (Ubuntu Hirsute): status |
New |
Invalid |
|
2021-07-02 09:02:42 |
Timo Aaltonen |
linux-oem-5.13 (Ubuntu Impish): status |
New |
Invalid |
|
2021-07-20 16:27:05 |
Launchpad Janitor |
linux-oem-5.13 (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
2021-07-20 16:27:05 |
Launchpad Janitor |
cve linked |
|
2021-33909 |
|
2021-09-15 19:08:57 |
Launchpad Janitor |
linux (Ubuntu Impish): status |
Confirmed |
Fix Released |
|