| 2021-05-09 22:30:11 |
Daniel LaSalle |
bug |
|
|
added bug |
| 2021-05-09 22:36:17 |
Daniel LaSalle |
description |
You are possibly one of the only person on Earth who can help me with this but would it be possible that there a traffic priority going on with USB controllers and they aren't perfectly tweaked?
My problem is that I have a keyboard servicing a USB 3.0 2 ports hub on it. I also have a wireless mouse with it's bluetooth's received plugged into one of those USB 3.0 ports. When I plug in a USB thumb drive on the keyboard and start copying: my mouse gets l-a-g-g-g-g-e-d up to the point that I would much rather use any other USB port on the system itself as none of those give me this problem.
(Same with the ones on my screens actually).
So, Doctor, what's your call?
<3 |
You are possibly one of the only person on Earth who can help me with this but would it be possible that there is some sort of "traffic priority" going on with USB controllers? Summing them up that some of them would need to have "bandwidth assignation profiles" based on what kind of device that they are physically plugged into?
The practical problem is that I have a keyboard hosting it's own USB 3.0 2 ports hub. I also have a wireless mouse with it's bluetooth's receiver plugged into one of these USB 3.0 ports. When I plug in a USB thumb drive on the remaining free ports on my keyboard and start moving data on it then my mouse gets really l-a-g-g-g-g-y. So much that I have totally stopped using this method of moving data as I simply cannot work in TTY7 when this happens. The solution has always been to plug my thumbdrive directly into any USB port direct on the system and move data that way if/when using a wireless bluetooth mouse.
(Point of interest: the USB hubs on my screens also have the same behavior as the ones directly on my system)
So, Doctor, what's your call? Do USB hubs need "traffic priority" therapy or do I??
;) |
|
| 2021-05-09 22:36:32 |
Daniel LaSalle |
description |
You are possibly one of the only person on Earth who can help me with this but would it be possible that there is some sort of "traffic priority" going on with USB controllers? Summing them up that some of them would need to have "bandwidth assignation profiles" based on what kind of device that they are physically plugged into?
The practical problem is that I have a keyboard hosting it's own USB 3.0 2 ports hub. I also have a wireless mouse with it's bluetooth's receiver plugged into one of these USB 3.0 ports. When I plug in a USB thumb drive on the remaining free ports on my keyboard and start moving data on it then my mouse gets really l-a-g-g-g-g-y. So much that I have totally stopped using this method of moving data as I simply cannot work in TTY7 when this happens. The solution has always been to plug my thumbdrive directly into any USB port direct on the system and move data that way if/when using a wireless bluetooth mouse.
(Point of interest: the USB hubs on my screens also have the same behavior as the ones directly on my system)
So, Doctor, what's your call? Do USB hubs need "traffic priority" therapy or do I??
;) |
You are possibly one of the only person on Earth who can help me with this but would it be possible that there is some sort of "traffic priority" going on with USB controllers? Summing them up that some of them would need to have "bandwidth assignation profiles" based on what kind of device that they are physically plugged into?
The practical problem is that I have a keyboard hosting it's own USB 3.0 2 ports hub. I also have a wireless mouse with it's bluetooth's receiver plugged into one of these USB 3.0 ports. When I plug in a USB thumb drive on the remaining free ports on my keyboard and start moving data on it then my mouse gets really l-a-g-g-g-g-y. So much that I have totally stopped using this method of moving data as I simply cannot work in TTY7 when this happens. The solution has always been to plug my thumbdrive directly into any USB port direct on the system and move data that way if/when using that wireless mouse of mine.
(Point of interest: the USB hubs on my screens also have the same behavior as the ones directly on my system)
So, Doctor, what's your call? Do USB hubs need "traffic priority" therapy or do I??
;) |
|
| 2021-05-26 15:11:04 |
Norbert |
tags |
|
hirsute |
|
| 2022-04-08 02:05:48 |
Martin Wimpress |
bug task added |
|
linux (Ubuntu) |
|
| 2022-04-08 02:05:52 |
Martin Wimpress |
bug task deleted |
ubuntu-mate |
|
|
| 2022-04-08 02:30:05 |
Ubuntu Kernel Bot |
linux (Ubuntu): status |
New |
Incomplete |
|
| 2022-04-08 21:43:01 |
Daniel LaSalle |
tags |
hirsute |
apport-collected hirsute impish |
|
| 2022-04-08 21:43:03 |
Daniel LaSalle |
description |
You are possibly one of the only person on Earth who can help me with this but would it be possible that there is some sort of "traffic priority" going on with USB controllers? Summing them up that some of them would need to have "bandwidth assignation profiles" based on what kind of device that they are physically plugged into?
The practical problem is that I have a keyboard hosting it's own USB 3.0 2 ports hub. I also have a wireless mouse with it's bluetooth's receiver plugged into one of these USB 3.0 ports. When I plug in a USB thumb drive on the remaining free ports on my keyboard and start moving data on it then my mouse gets really l-a-g-g-g-g-y. So much that I have totally stopped using this method of moving data as I simply cannot work in TTY7 when this happens. The solution has always been to plug my thumbdrive directly into any USB port direct on the system and move data that way if/when using that wireless mouse of mine.
(Point of interest: the USB hubs on my screens also have the same behavior as the ones directly on my system)
So, Doctor, what's your call? Do USB hubs need "traffic priority" therapy or do I??
;) |
You are possibly one of the only person on Earth who can help me with this but would it be possible that there is some sort of "traffic priority" going on with USB controllers? Summing them up that some of them would need to have "bandwidth assignation profiles" based on what kind of device that they are physically plugged into?
The practical problem is that I have a keyboard hosting it's own USB 3.0 2 ports hub. I also have a wireless mouse with it's bluetooth's receiver plugged into one of these USB 3.0 ports. When I plug in a USB thumb drive on the remaining free ports on my keyboard and start moving data on it then my mouse gets really l-a-g-g-g-g-y. So much that I have totally stopped using this method of moving data as I simply cannot work in TTY7 when this happens. The solution has always been to plug my thumbdrive directly into any USB port direct on the system and move data that way if/when using that wireless mouse of mine.
(Point of interest: the USB hubs on my screens also have the same behavior as the ones directly on my system)
So, Doctor, what's your call? Do USB hubs need "traffic priority" therapy or do I??
;)
---
ProblemType: Bug
ApportVersion: 2.20.11-0ubuntu71.1
Architecture: amd64
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/controlC1: dd 2393 F.... pulseaudio
/dev/snd/controlC0: dd 2393 F.... pulseaudio
CasperMD5CheckResult: unknown
CurrentDesktop: MATE
DistroRelease: Ubuntu 21.10
HibernationDevice: RESUME=UUID=88228def-1fb1-4fc3-964c-3106218355eb
InstallationDate: Installed on 2020-08-29 (587 days ago)
InstallationMedia: Ubuntu-MATE 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731)
IwConfig:
lo no wireless extensions.
enp7s0 no wireless extensions.
tun0 no wireless extensions.
MachineType: System manufacturer System Product Name
Package: linux (not installed)
ProcFB: 0 radeondrmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.13.0-39-generic root=/dev/mapper/vgubuntu--mate-root ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 5.13.0-39.44-generic 5.13.19
RelatedPackageVersions:
linux-restricted-modules-5.13.0-39-generic N/A
linux-backports-modules-5.13.0-39-generic N/A
linux-firmware 1.201.5
RfKill:
Tags: impish
Uname: Linux 5.13.0-39-generic x86_64
UpgradeStatus: Upgraded to impish on 2021-10-14 (176 days ago)
UserGroups: adm cdrom dip lpadmin lxd plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 12/02/2020
dmi.bios.release: 5.17
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 5809
dmi.board.asset.tag: Default string
dmi.board.name: TUF X470-PLUS GAMING
dmi.board.vendor: ASUSTeK COMPUTER INC.
dmi.board.version: Rev X.0x
dmi.chassis.asset.tag: Default string
dmi.chassis.type: 3
dmi.chassis.vendor: Default string
dmi.chassis.version: Default string
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr5809:bd12/02/2020:br5.17:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnTUFX470-PLUSGAMING:rvrRevX.0x:cvnDefaultstring:ct3:cvrDefaultstring:skuSKU:
dmi.product.family: To be filled by O.E.M.
dmi.product.name: System Product Name
dmi.product.sku: SKU
dmi.product.version: System Version
dmi.sys.vendor: System manufacturer |
|
| 2022-04-08 21:43:04 |
Daniel LaSalle |
attachment added |
|
AlsaInfo.txt https://bugs.launchpad.net/bugs/1927878/+attachment/5578358/+files/AlsaInfo.txt |
|
| 2022-04-08 21:43:05 |
Daniel LaSalle |
attachment added |
|
CRDA.txt https://bugs.launchpad.net/bugs/1927878/+attachment/5578359/+files/CRDA.txt |
|
| 2022-04-08 21:43:06 |
Daniel LaSalle |
attachment added |
|
CurrentDmesg.txt https://bugs.launchpad.net/bugs/1927878/+attachment/5578360/+files/CurrentDmesg.txt |
|
| 2022-04-08 21:43:08 |
Daniel LaSalle |
attachment added |
|
Lspci.txt https://bugs.launchpad.net/bugs/1927878/+attachment/5578361/+files/Lspci.txt |
|
| 2022-04-08 21:43:09 |
Daniel LaSalle |
attachment added |
|
Lspci-vt.txt https://bugs.launchpad.net/bugs/1927878/+attachment/5578362/+files/Lspci-vt.txt |
|
| 2022-04-08 21:43:10 |
Daniel LaSalle |
attachment added |
|
Lsusb.txt https://bugs.launchpad.net/bugs/1927878/+attachment/5578363/+files/Lsusb.txt |
|
| 2022-04-08 21:43:12 |
Daniel LaSalle |
attachment added |
|
Lsusb-t.txt https://bugs.launchpad.net/bugs/1927878/+attachment/5578364/+files/Lsusb-t.txt |
|
| 2022-04-08 21:43:13 |
Daniel LaSalle |
attachment added |
|
Lsusb-v.txt https://bugs.launchpad.net/bugs/1927878/+attachment/5578365/+files/Lsusb-v.txt |
|
| 2022-04-08 21:43:14 |
Daniel LaSalle |
attachment added |
|
PaInfo.txt https://bugs.launchpad.net/bugs/1927878/+attachment/5578366/+files/PaInfo.txt |
|
| 2022-04-08 21:43:15 |
Daniel LaSalle |
attachment added |
|
ProcCpuinfo.txt https://bugs.launchpad.net/bugs/1927878/+attachment/5578367/+files/ProcCpuinfo.txt |
|
| 2022-04-08 21:43:17 |
Daniel LaSalle |
attachment added |
|
ProcCpuinfoMinimal.txt https://bugs.launchpad.net/bugs/1927878/+attachment/5578368/+files/ProcCpuinfoMinimal.txt |
|
| 2022-04-08 21:43:18 |
Daniel LaSalle |
attachment added |
|
ProcEnviron.txt https://bugs.launchpad.net/bugs/1927878/+attachment/5578369/+files/ProcEnviron.txt |
|
| 2022-04-08 21:43:19 |
Daniel LaSalle |
attachment added |
|
ProcInterrupts.txt https://bugs.launchpad.net/bugs/1927878/+attachment/5578370/+files/ProcInterrupts.txt |
|
| 2022-04-08 21:43:20 |
Daniel LaSalle |
attachment added |
|
ProcModules.txt https://bugs.launchpad.net/bugs/1927878/+attachment/5578371/+files/ProcModules.txt |
|
| 2022-04-08 21:43:21 |
Daniel LaSalle |
attachment added |
|
PulseList.txt https://bugs.launchpad.net/bugs/1927878/+attachment/5578372/+files/PulseList.txt |
|
| 2022-04-08 21:43:23 |
Daniel LaSalle |
attachment added |
|
UdevDb.txt https://bugs.launchpad.net/bugs/1927878/+attachment/5578373/+files/UdevDb.txt |
|
| 2022-04-08 21:43:24 |
Daniel LaSalle |
attachment added |
|
WifiSyslog.txt https://bugs.launchpad.net/bugs/1927878/+attachment/5578374/+files/WifiSyslog.txt |
|
| 2022-04-08 21:43:26 |
Daniel LaSalle |
attachment added |
|
acpidump.txt https://bugs.launchpad.net/bugs/1927878/+attachment/5578375/+files/acpidump.txt |
|
| 2022-04-08 21:45:54 |
Daniel LaSalle |
linux (Ubuntu): status |
Incomplete |
Confirmed |
|
