[Kernel-packages] [Bug 2018687] Re: rm -r dir on USB disk locks up hdparm on different disk
Unfortunately, an unacceptable side-effect of "sysctl -w
vm.dirty_ratio=0" is that disk operations that move a lot of data are
taking much too long. An rsync that normally takes less than an hour of
real time was still running over 12 hours later (and hasn't finished
yet). I'm reverting the vm.dirty_ratio back up to 20 to see if that
clears out all the unfinished disk I/O.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-meta-hwe-5.15 in Ubuntu.
https://bugs.launchpad.net/bugs/2018687
Title:
rm -r dir on USB disk locks up hdparm on different disk
Status in linux-meta-hwe-5.15 package in Ubuntu:
New
Bug description:
Description:Ubuntu 20.04.6 LTS
Linux 5.15.0-72-generic #79~20.04.1-Ubuntu SMP Thu Apr 20 22:12:07 UTC 2023
x86_64 GNU/Linux
Intel(R) Xeon(R) CPU E5-1620 v4 @ 3.50GHz
Running a "rm -r dir" on a directory with millions of files that resides
on a disk in an external USB-3 hard drive dock locks up an unrelated
hdparm processes running on an internal disk such that the kernel says:
May 7 04:24:02 kernel: [163606.041862] INFO: task hdparm:1391162 blocked
for more than 120 seconds.
[...]
May 7 04:26:03 kernel: [163726.876357] INFO: task hdparm:1391162 blocked
for more than 241 seconds.
[...]
May 7 04:28:04 kernel: [163847.702980] INFO: task hdparm:1391162 blocked
for more than 362 seconds.
First a normal run of "hdparm -t /dev/sda" with the offending "rm -r"
SIGSTOPped so that
it doesn't affect anything:
# \time hdparm -t /dev/sda
/dev/sda:
Timing buffered disk reads: 1128 MB in 3.00 seconds = 375.50 MB/sec
0.01user 0.67system 0:06.21elapsed 11%CPU (0avgtext+0avgdata
4584maxresident)k
2312704inputs+8outputs (0major+664minor)pagefaults 0swaps
Elapsed time is about six seconds, as expected. /dev/sda is an
internal SSD drive.
I now run this loop to show the timings and process states below:
# while sleep 1 ; do date ; ps laxww | grep '[ ]D' | grep -v
refrig ; done
(I have some processes stopped in a freezer cgroup ("refrig") that I
don't want to see in the grep output.) I SIGCONT the offending "rm -r"
running on the drive in the USB3 drive dock and you see the rm appear
in uninterruptible sleep along with a couple of kernel processes:
Sun May 7 05:01:07 EDT 2023
Sun May 7 05:01:08 EDT 2023
Sun May 7 05:01:09 EDT 2023
Sun May 7 05:01:10 EDT 2023
Sun May 7 05:01:11 EDT 2023
1 0 447 2 20 0 0 0 usb_sg D? 3:17
[usb-storage]
4 0 1423283 11939 20 0 10648 580 wait_o D+ pts/28 0:00
rm -rf 15tb3
Sun May 7 05:01:12 EDT 2023
1 0 447 2 20 0 0 0 usb_sg D? 3:17
[usb-storage]
1 04016 1 20 0 161136 1900 usbhid Dsl ? 1:39
/sbin/apcupsd
4 0 1423283 11939 20 0 10648 580 wait_o D+ pts/28 0:00
rm -rf 15tb3
Sun May 7 05:01:13 EDT 2023
The above lines showing those processes in uninterruptible sleep repeat
over and over each second as the "rm -r" continues. I then start up
"hdparm -t /dev/sda" on the internal SSD disk, and it also appears in
uninterruptible sleep and doesn't finish even after minutes of waiting:
Sun May 7 05:01:25 EDT 2023
1 0 368 2 20 0 0 0 md_sup D? 2:57
[md0_raid5]
1 0 1366783 2 20 0 0 0 blk_mq D? 0:02
[kworker/u16:2+flush-8:144]
4 0 1423283 11939 20 0 11260 2544 wait_o D+ pts/28 0:00
rm -rf 15tb3
4 0 14235019975 20 0 4680 4584 wb_wai DL+ pts/4 0:00
hdparm -t /dev/sda
Sun May 7 05:01:26 EDT 2023
1 0 447 2 20 0 0 0 usb_sg D? 3:17
[usb-storage]
1 0 1366783 2 20 0 0 0 blk_mq D? 0:02
[kworker/u16:2+flush-8:144]
4 0 1423283 11939 20 0 11260 2544 wait_o D+ pts/28 0:00
rm -rf 15tb3
4 0 14235019975 20 0 4680 4584 wb_wai DL+ pts/4 0:00
hdparm -t /dev/sda
Sun May 7 05:01:27 EDT 2023
[...]
4 0 14235019975 20 0 4680 4584 wb_wai DL+ pts/4 0:00
hdparm -t /dev/sda
Sun May 7 05:01:35 EDT 2023
1 0 447 2 20 0 0 0 usb_sg D? 3:17
[usb-storage]
4 0 1423283 11939 20 0 11260 2544 blk_mq D+ pts/28 0:00
rm -rf 15tb3
4 0 14235019975 20 0 4680 4584 wb_wai DL+ pts/4 0:00
hdparm -t /dev/sda
Sun May 7 05:01:36 EDT 2023
1 0 447 2 20 0 0 0 usb_sg D? 3:17
[usb-storage]
1 04985 2 20 0 0 0 rq_qos D? 0:24
[jbd2/sdj1-8]
1 0 1366783 2 20 0 0 0 blk_mq D? 0:02
[Kernel-packages] [Bug 2018687] Re: rm -r dir on USB disk locks up hdparm on different disk
If I do this:
# sysctl -w vm.dirty_ratio=0
the hdparm no longer hangs. It has to be zero; anything non-zero, even
1, causes large delays in disk-related commands such as hdparm, sync,
smartctl, etc.
I got this idea from here:
https://serverfault.com/questions/405210/can-high-load-cause-server-
hang-and-error-blocked-for-more-than-120-seconds
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-meta-hwe-5.15 in Ubuntu.
https://bugs.launchpad.net/bugs/2018687
Title:
rm -r dir on USB disk locks up hdparm on different disk
Status in linux-meta-hwe-5.15 package in Ubuntu:
New
Bug description:
Description:Ubuntu 20.04.6 LTS
Linux 5.15.0-72-generic #79~20.04.1-Ubuntu SMP Thu Apr 20 22:12:07 UTC 2023
x86_64 GNU/Linux
Intel(R) Xeon(R) CPU E5-1620 v4 @ 3.50GHz
Running a "rm -r dir" on a directory with millions of files that resides
on a disk in an external USB-3 hard drive dock locks up an unrelated
hdparm processes running on an internal disk such that the kernel says:
May 7 04:24:02 kernel: [163606.041862] INFO: task hdparm:1391162 blocked
for more than 120 seconds.
[...]
May 7 04:26:03 kernel: [163726.876357] INFO: task hdparm:1391162 blocked
for more than 241 seconds.
[...]
May 7 04:28:04 kernel: [163847.702980] INFO: task hdparm:1391162 blocked
for more than 362 seconds.
First a normal run of "hdparm -t /dev/sda" with the offending "rm -r"
SIGSTOPped so that
it doesn't affect anything:
# \time hdparm -t /dev/sda
/dev/sda:
Timing buffered disk reads: 1128 MB in 3.00 seconds = 375.50 MB/sec
0.01user 0.67system 0:06.21elapsed 11%CPU (0avgtext+0avgdata
4584maxresident)k
2312704inputs+8outputs (0major+664minor)pagefaults 0swaps
Elapsed time is about six seconds, as expected. /dev/sda is an
internal SSD drive.
I now run this loop to show the timings and process states below:
# while sleep 1 ; do date ; ps laxww | grep '[ ]D' | grep -v
refrig ; done
(I have some processes stopped in a freezer cgroup ("refrig") that I
don't want to see in the grep output.) I SIGCONT the offending "rm -r"
running on the drive in the USB3 drive dock and you see the rm appear
in uninterruptible sleep along with a couple of kernel processes:
Sun May 7 05:01:07 EDT 2023
Sun May 7 05:01:08 EDT 2023
Sun May 7 05:01:09 EDT 2023
Sun May 7 05:01:10 EDT 2023
Sun May 7 05:01:11 EDT 2023
1 0 447 2 20 0 0 0 usb_sg D? 3:17
[usb-storage]
4 0 1423283 11939 20 0 10648 580 wait_o D+ pts/28 0:00
rm -rf 15tb3
Sun May 7 05:01:12 EDT 2023
1 0 447 2 20 0 0 0 usb_sg D? 3:17
[usb-storage]
1 04016 1 20 0 161136 1900 usbhid Dsl ? 1:39
/sbin/apcupsd
4 0 1423283 11939 20 0 10648 580 wait_o D+ pts/28 0:00
rm -rf 15tb3
Sun May 7 05:01:13 EDT 2023
The above lines showing those processes in uninterruptible sleep repeat
over and over each second as the "rm -r" continues. I then start up
"hdparm -t /dev/sda" on the internal SSD disk, and it also appears in
uninterruptible sleep and doesn't finish even after minutes of waiting:
Sun May 7 05:01:25 EDT 2023
1 0 368 2 20 0 0 0 md_sup D? 2:57
[md0_raid5]
1 0 1366783 2 20 0 0 0 blk_mq D? 0:02
[kworker/u16:2+flush-8:144]
4 0 1423283 11939 20 0 11260 2544 wait_o D+ pts/28 0:00
rm -rf 15tb3
4 0 14235019975 20 0 4680 4584 wb_wai DL+ pts/4 0:00
hdparm -t /dev/sda
Sun May 7 05:01:26 EDT 2023
1 0 447 2 20 0 0 0 usb_sg D? 3:17
[usb-storage]
1 0 1366783 2 20 0 0 0 blk_mq D? 0:02
[kworker/u16:2+flush-8:144]
4 0 1423283 11939 20 0 11260 2544 wait_o D+ pts/28 0:00
rm -rf 15tb3
4 0 14235019975 20 0 4680 4584 wb_wai DL+ pts/4 0:00
hdparm -t /dev/sda
Sun May 7 05:01:27 EDT 2023
[...]
4 0 14235019975 20 0 4680 4584 wb_wai DL+ pts/4 0:00
hdparm -t /dev/sda
Sun May 7 05:01:35 EDT 2023
1 0 447 2 20 0 0 0 usb_sg D? 3:17
[usb-storage]
4 0 1423283 11939 20 0 11260 2544 blk_mq D+ pts/28 0:00
rm -rf 15tb3
4 0 14235019975 20 0 4680 4584 wb_wai DL+ pts/4 0:00
hdparm -t /dev/sda
Sun May 7 05:01:36 EDT 2023
1 0 447 2 20 0 0 0 usb_sg D? 3:17
[usb-storage]
1 04985 2 20 0 0 0 rq_qos D? 0:24
[jbd2/sdj1-8]
1 0 1366783 2 20 0 0 0 blk_mq D? 0:02
[Kernel-packages] [Bug 2018687] Re: rm -r dir on USB disk locks up hdparm on different disk
I now have a Perl script running that is removing duplicate files by doing thousands of hard links on a different external USB3 disk and it is locking up or timing out many disk-related things on all my other disks. Both this USB3 external drive and the one above are plugged directly into the motherboard (HP Z440 Workstation). F UID PIDPPID PRI NIVSZ RSS WCHAN STAT TTYTIME COMMAND 4 0 2210112 2210111 20 0 53680 42588 blk_mq D+ pts/24 3:00 /usr/bin/perl [...] May 14 13:37:49 kernel: [259424.745462] INFO: task smartd:2719 blocked for more than 120 seconds. May 15 00:08:09 kernel: [297244.761855] INFO: task smartd:2719 blocked for more than 120 seconds. May 15 00:10:10 kernel: [297365.592485] INFO: task smartd:2719 blocked for more than 241 seconds. May 15 01:08:34 kernel: [300869.682961] INFO: task smartd:2719 blocked for more than 120 seconds. May 15 01:28:43 kernel: [302077.989582] INFO: task hdparm:2052842 blocked for more than 120 seconds. May 15 01:30:43 kernel: [302198.820278] INFO: task hdparm:2052842 blocked for more than 241 seconds. May 15 01:32:44 kernel: [302319.654907] INFO: task hdparm:2052842 blocked for more than 362 seconds. May 15 01:34:45 kernel: [302440.481601] INFO: task hdparm:2052842 blocked for more than 483 seconds. May 15 01:36:46 kernel: [302561.316237] INFO: task hdparm:2052842 blocked for more than 604 seconds. May 15 02:06:58 kernel: [304373.770194] INFO: task smartd:2719 blocked for more than 120 seconds. From one of the logged events: May 15 02:06:58 kernel: [304373.770194] INFO: task smartd:2719 blocked for more than 120 seconds. May 15 02:06:58 kernel: [304373.770209] Tainted: G O 5.15.0-72-generic #79~20.04.1-Ubuntu May 15 02:06:58 kernel: [304373.770215] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. May 15 02:06:58 kernel: [304373.770218] task:smartd state:D stack: 0 pid: 2719 ppid: 1 flags:0x May 15 02:06:58 kernel: [304373.770226] Call Trace: May 15 02:06:58 kernel: [304373.770230] May 15 02:06:58 kernel: [304373.770236] __schedule+0x2cd/0x890 May 15 02:06:58 kernel: [304373.770251] schedule+0x69/0x110 May 15 02:06:58 kernel: [304373.770260] schedule_preempt_disabled+0xe/0x20 May 15 02:06:58 kernel: [304373.770269] __mutex_lock.isra.0+0x20c/0x470 May 15 02:06:58 kernel: [304373.770276] ? iput.part.0+0x61/0x1e0 May 15 02:06:58 kernel: [304373.770287] __mutex_lock_slowpath+0x13/0x20 May 15 02:06:58 kernel: [304373.770294] mutex_lock+0x36/0x40 May 15 02:06:58 kernel: [304373.770299] blkdev_get_by_dev+0x11d/0x2d0 May 15 02:06:58 kernel: [304373.770309] ? blkdev_close+0x30/0x30 May 15 02:06:58 kernel: [304373.770318] blkdev_open+0x50/0x90 May 15 02:06:58 kernel: [304373.770325] do_dentry_open+0x169/0x3e0 May 15 02:06:58 kernel: [304373.770336] vfs_open+0x2d/0x40 May 15 02:06:58 kernel: [304373.770342] do_open.isra.0+0x20d/0x480 May 15 02:06:58 kernel: [304373.770351] path_openat+0x18e/0xe50 May 15 02:06:58 kernel: [304373.770361] ? put_device+0x13/0x20 May 15 02:06:58 kernel: [304373.770371] ? scsi_device_put+0x31/0x40 May 15 02:06:58 kernel: [304373.770380] ? sd_release+0x3b/0xb0 May 15 02:06:58 kernel: [304373.770388] do_filp_open+0xb2/0x120 May 15 02:06:58 kernel: [304373.770398] ? __check_object_size+0x14f/0x160 May 15 02:06:58 kernel: [304373.770408] do_sys_openat2+0x249/0x330 May 15 02:06:58 kernel: [304373.770418] do_sys_open+0x46/0x80 May 15 02:06:58 kernel: [304373.770424] __x64_sys_openat+0x20/0x30 May 15 02:06:58 kernel: [304373.770430] do_syscall_64+0x5c/0xc0 May 15 02:06:58 kernel: [304373.770440] ? do_syscall_64+0x69/0xc0 May 15 02:06:58 kernel: [304373.770448] entry_SYSCALL_64_after_hwframe+0x61/0xcb May 15 02:06:58 kernel: [304373.770458] RIP: 0033:0x7f9b0d188d3b May 15 02:06:58 kernel: [304373.770465] RSP: 002b:7ffd72a3caf0 EFLAGS: 0246 ORIG_RAX: 0101 May 15 02:06:58 kernel: [304373.770473] RAX: ffda RBX: 55f1346783c0 RCX: 7f9b0d188d3b May 15 02:06:58 kernel: [304373.770479] RDX: 0800 RSI: 55f1346783f8 RDI: ff9c May 15 02:06:58 kernel: [304373.770484] RBP: 55f1346783f8 R08: 0001 R09: May 15 02:06:58 kernel: [304373.770488] R10: R11: 0246 R12: 0800 May 15 02:06:58 kernel: [304373.770493] R13: R14: 55f1334c26a4 R15: 7f9b0cd17250 May 15 02:06:58 kernel: [304373.770500] -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-meta-hwe-5.15 in Ubuntu. https://bugs.launchpad.net/bugs/2018687 Title: rm -r dir on USB disk locks up hdparm on different disk Status in linux-meta-hwe-5.15 package in Ubuntu: New Bug description: Description:Ubuntu 20.04.6 LTS Linux 5.15.0-72-generic #79~20.04.1-Ubuntu SMP Thu Apr 20 22:12:07 UTC 2023 x86_64 GNU/Linux Intel(R) Xeon(R)
[Kernel-packages] [Bug 2018687] Re: rm -r dir on USB disk locks up hdparm on different disk
** Description changed:
Description:Ubuntu 20.04.6 LTS
Linux 5.15.0-72-generic #79~20.04.1-Ubuntu SMP Thu Apr 20 22:12:07 UTC 2023
x86_64 GNU/Linux
Intel(R) Xeon(R) CPU E5-1620 v4 @ 3.50GHz
Running a "rm -r dir" on a directory with millions of files that resides
on a disk in an external USB-3 hard drive dock locks up an unrelated
hdparm processes running on an internal disk such that the kernel says:
- May 7 04:24:02 kernel: [163606.041862] INFO: task hdparm:1391162 blocked
for more than 120 seconds.
+ May 7 04:24:02 kernel: [163606.041862] INFO: task hdparm:1391162 blocked
for more than 120 seconds.
+ [...]
+ May 7 04:26:03 kernel: [163726.876357] INFO: task hdparm:1391162 blocked
for more than 241 seconds.
+ [...]
+ May 7 04:28:04 kernel: [163847.702980] INFO: task hdparm:1391162 blocked
for more than 362 seconds.
[...]
- May 7 04:26:03 kernel: [163726.876357] INFO: task hdparm:1391162 blocked
for more than 241 seconds.
- [...]
- May 7 04:28:04 kernel: [163847.702980] INFO: task hdparm:1391162 blocked
for more than 362 seconds.
+ May 7 04:30:05 kernel: [163968.537842] INFO: task hdparm:1391162 blocked
for more than 483 seconds.
First a normal run of "hdparm -t /dev/sda" with the offending "rm -r"
SIGSTOPped so that
it doesn't affect anything:
- # \time hdparm -t /dev/sda
- /dev/sda:
- Timing buffered disk reads: 1128 MB in 3.00 seconds = 375.50 MB/sec
- 0.01user 0.67system 0:06.21elapsed 11%CPU (0avgtext+0avgdata
4584maxresident)k
- 2312704inputs+8outputs (0major+664minor)pagefaults 0swaps
+ # \time hdparm -t /dev/sda
+ /dev/sda:
+ Timing buffered disk reads: 1128 MB in 3.00 seconds = 375.50 MB/sec
+ 0.01user 0.67system 0:06.21elapsed 11%CPU (0avgtext+0avgdata
4584maxresident)k
+ 2312704inputs+8outputs (0major+664minor)pagefaults 0swaps
Elapsed time is about six seconds, as expected. /dev/sda is an internal
SSD drive.
I now run this loop to show the timings and process states below:
- # while sleep 1 ; do date ; ps laxww | grep '[ ]D' | grep -v refrig
+ # while sleep 1 ; do date ; ps laxww | grep '[ ]D' | grep -v refrig
; done
(I have some processes stopped in a freezer cgroup ("refrig") that I
don't want to see in the grep output.) I SIGCONT the offending "rm -r"
running on the drive in the USB3 drive dock and you see the rm appear
in uninterruptible sleep along with a couple of kernel processes:
- Sun May 7 05:01:07 EDT 2023
- Sun May 7 05:01:08 EDT 2023
- Sun May 7 05:01:09 EDT 2023
- Sun May 7 05:01:10 EDT 2023
- Sun May 7 05:01:11 EDT 2023
- 1 0 447 2 20 0 0 0 usb_sg D? 3:17
[usb-storage]
- 4 0 1423283 11939 20 0 10648 580 wait_o D+ pts/28 0:00
rm -rf 15tb3
- Sun May 7 05:01:12 EDT 2023
- 1 0 447 2 20 0 0 0 usb_sg D? 3:17
[usb-storage]
- 1 04016 1 20 0 161136 1900 usbhid Dsl ? 1:39
/sbin/apcupsd
- 4 0 1423283 11939 20 0 10648 580 wait_o D+ pts/28 0:00
rm -rf 15tb3
- Sun May 7 05:01:13 EDT 2023
+ Sun May 7 05:01:07 EDT 2023
+ Sun May 7 05:01:08 EDT 2023
+ Sun May 7 05:01:09 EDT 2023
+ Sun May 7 05:01:10 EDT 2023
+ Sun May 7 05:01:11 EDT 2023
+ 1 0 447 2 20 0 0 0 usb_sg D? 3:17
[usb-storage]
+ 4 0 1423283 11939 20 0 10648 580 wait_o D+ pts/28 0:00
rm -rf 15tb3
+ Sun May 7 05:01:12 EDT 2023
+ 1 0 447 2 20 0 0 0 usb_sg D? 3:17
[usb-storage]
+ 1 04016 1 20 0 161136 1900 usbhid Dsl ? 1:39
/sbin/apcupsd
+ 4 0 1423283 11939 20 0 10648 580 wait_o D+ pts/28 0:00
rm -rf 15tb3
+ Sun May 7 05:01:13 EDT 2023
The above lines showing those processes in uninterruptible sleep repeat
over and over each second as the "rm -r" continues. I then start up
"hdparm -t /dev/sda" on the internal SSD disk, and it also appears in
uninterruptible sleep and doesn't finish even after minutes of waiting:
- Sun May 7 05:01:25 EDT 2023
- 1 0 368 2 20 0 0 0 md_sup D? 2:57
[md0_raid5]
- 1 0 1366783 2 20 0 0 0 blk_mq D? 0:02
[kworker/u16:2+flush-8:144]
- 4 0 1423283 11939 20 0 11260 2544 wait_o D+ pts/28 0:00
rm -rf 15tb3
- 4 0 14235019975 20 0 4680 4584 wb_wai DL+ pts/4 0:00
hdparm -t /dev/sda
- Sun May 7 05:01:26 EDT 2023
- 1 0 447 2 20 0 0 0 usb_sg D? 3:17
[usb-storage]
- 1 0 1366783 2 20 0 0 0 blk_mq D? 0:02
[kworker/u16:2+flush-8:144]
- 4 0 1423283 11939 20 0 11260 2544 wait_o D+ pts/28 0:00
rm -rf
[Kernel-packages] [Bug 2018687] Re: rm -r dir on USB disk locks up hdparm on different disk
** Description changed:
Description:Ubuntu 20.04.6 LTS
Linux 5.15.0-72-generic #79~20.04.1-Ubuntu SMP Thu Apr 20 22:12:07 UTC 2023
x86_64 GNU/Linux
Intel(R) Xeon(R) CPU E5-1620 v4 @ 3.50GHz
Running a "rm -r dir" on a directory with millions of files that resides
on a disk in an external USB-3 hard drive dock locks up an unrelated
hdparm processes running on an internal disk such that the kernel says:
May 7 04:24:02 kernel: [163606.041862] INFO: task hdparm:1391162 blocked
for more than 120 seconds.
[...]
May 7 04:26:03 kernel: [163726.876357] INFO: task hdparm:1391162 blocked
for more than 241 seconds.
[...]
May 7 04:28:04 kernel: [163847.702980] INFO: task hdparm:1391162 blocked
for more than 362 seconds.
- [...]
- May 7 04:30:05 kernel: [163968.537842] INFO: task hdparm:1391162 blocked
for more than 483 seconds.
First a normal run of "hdparm -t /dev/sda" with the offending "rm -r"
SIGSTOPped so that
it doesn't affect anything:
# \time hdparm -t /dev/sda
/dev/sda:
Timing buffered disk reads: 1128 MB in 3.00 seconds = 375.50 MB/sec
0.01user 0.67system 0:06.21elapsed 11%CPU (0avgtext+0avgdata
4584maxresident)k
2312704inputs+8outputs (0major+664minor)pagefaults 0swaps
Elapsed time is about six seconds, as expected. /dev/sda is an internal
SSD drive.
I now run this loop to show the timings and process states below:
# while sleep 1 ; do date ; ps laxww | grep '[ ]D' | grep -v refrig
; done
(I have some processes stopped in a freezer cgroup ("refrig") that I
don't want to see in the grep output.) I SIGCONT the offending "rm -r"
running on the drive in the USB3 drive dock and you see the rm appear
in uninterruptible sleep along with a couple of kernel processes:
Sun May 7 05:01:07 EDT 2023
Sun May 7 05:01:08 EDT 2023
Sun May 7 05:01:09 EDT 2023
Sun May 7 05:01:10 EDT 2023
Sun May 7 05:01:11 EDT 2023
1 0 447 2 20 0 0 0 usb_sg D? 3:17
[usb-storage]
4 0 1423283 11939 20 0 10648 580 wait_o D+ pts/28 0:00
rm -rf 15tb3
Sun May 7 05:01:12 EDT 2023
1 0 447 2 20 0 0 0 usb_sg D? 3:17
[usb-storage]
1 04016 1 20 0 161136 1900 usbhid Dsl ? 1:39
/sbin/apcupsd
4 0 1423283 11939 20 0 10648 580 wait_o D+ pts/28 0:00
rm -rf 15tb3
Sun May 7 05:01:13 EDT 2023
The above lines showing those processes in uninterruptible sleep repeat
over and over each second as the "rm -r" continues. I then start up
"hdparm -t /dev/sda" on the internal SSD disk, and it also appears in
uninterruptible sleep and doesn't finish even after minutes of waiting:
Sun May 7 05:01:25 EDT 2023
1 0 368 2 20 0 0 0 md_sup D? 2:57
[md0_raid5]
1 0 1366783 2 20 0 0 0 blk_mq D? 0:02
[kworker/u16:2+flush-8:144]
4 0 1423283 11939 20 0 11260 2544 wait_o D+ pts/28 0:00
rm -rf 15tb3
4 0 14235019975 20 0 4680 4584 wb_wai DL+ pts/4 0:00
hdparm -t /dev/sda
Sun May 7 05:01:26 EDT 2023
1 0 447 2 20 0 0 0 usb_sg D? 3:17
[usb-storage]
1 0 1366783 2 20 0 0 0 blk_mq D? 0:02
[kworker/u16:2+flush-8:144]
4 0 1423283 11939 20 0 11260 2544 wait_o D+ pts/28 0:00
rm -rf 15tb3
4 0 14235019975 20 0 4680 4584 wb_wai DL+ pts/4 0:00
hdparm -t /dev/sda
Sun May 7 05:01:27 EDT 2023
[...]
4 0 14235019975 20 0 4680 4584 wb_wai DL+ pts/4 0:00
hdparm -t /dev/sda
Sun May 7 05:01:35 EDT 2023
1 0 447 2 20 0 0 0 usb_sg D? 3:17
[usb-storage]
4 0 1423283 11939 20 0 11260 2544 blk_mq D+ pts/28 0:00
rm -rf 15tb3
4 0 14235019975 20 0 4680 4584 wb_wai DL+ pts/4 0:00
hdparm -t /dev/sda
Sun May 7 05:01:36 EDT 2023
1 0 447 2 20 0 0 0 usb_sg D? 3:17
[usb-storage]
1 04985 2 20 0 0 0 rq_qos D? 0:24
[jbd2/sdj1-8]
1 0 1366783 2 20 0 0 0 blk_mq D? 0:02
[kworker/u16:2+flush-8:144]
4 0 1423283 11939 20 0 11260 2544 wait_o D+ pts/28 0:00
rm -rf 15tb3
4 0 14235019975 20 0 4680 4584 wb_wai DL+ pts/4 0:00
hdparm -t /dev/sda
Sun May 7 05:01:37 EDT 2023
I keep waiting. The above lines repeat over and over and the hdparm is
blocked and doesn't finish.
Sun May 7 05:03:32 EDT 2023
1 0 447 2 20 0 0 0 usb_sg D? 3:18
[usb-storage]
1 0 1366783 2 20
[Kernel-packages] [Bug 2018687] [NEW] rm -r dir on USB disk locks up hdparm on different disk
Public bug reported:
Description:Ubuntu 20.04.6 LTS
Linux 5.15.0-72-generic #79~20.04.1-Ubuntu SMP Thu Apr 20 22:12:07 UTC 2023
x86_64 GNU/Linux
Intel(R) Xeon(R) CPU E5-1620 v4 @ 3.50GHz
Running a "rm -r dir" on a directory with millions of files that resides
on a disk in an external USB-3 hard drive dock locks up an unrelated
hdparm processes running on an internal disk such that the kernel says:
May 7 04:24:02 kernel: [163606.041862] INFO: task hdparm:1391162 blocked
for more than 120 seconds.
[...]
May 7 04:26:03 kernel: [163726.876357] INFO: task hdparm:1391162 blocked
for more than 241 seconds.
[...]
May 7 04:28:04 kernel: [163847.702980] INFO: task hdparm:1391162 blocked
for more than 362 seconds.
First a normal run of "hdparm -t /dev/sda" with the offending "rm -r"
SIGSTOPped so that
it doesn't affect anything:
# \time hdparm -t /dev/sda
/dev/sda:
Timing buffered disk reads: 1128 MB in 3.00 seconds = 375.50 MB/sec
0.01user 0.67system 0:06.21elapsed 11%CPU (0avgtext+0avgdata
4584maxresident)k
2312704inputs+8outputs (0major+664minor)pagefaults 0swaps
Elapsed time is about six seconds, as expected. /dev/sda is an internal
SSD drive.
I now run this loop to show the timings and process states below:
# while sleep 1 ; do date ; ps laxww | grep '[ ]D' | grep -v refrig
; done
(I have some processes stopped in a freezer cgroup ("refrig") that I
don't want to see in the grep output.) I SIGCONT the offending "rm -r"
running on the drive in the USB3 drive dock and you see the rm appear
in uninterruptible sleep along with a couple of kernel processes:
Sun May 7 05:01:07 EDT 2023
Sun May 7 05:01:08 EDT 2023
Sun May 7 05:01:09 EDT 2023
Sun May 7 05:01:10 EDT 2023
Sun May 7 05:01:11 EDT 2023
1 0 447 2 20 0 0 0 usb_sg D? 3:17
[usb-storage]
4 0 1423283 11939 20 0 10648 580 wait_o D+ pts/28 0:00 rm
-rf 15tb3
Sun May 7 05:01:12 EDT 2023
1 0 447 2 20 0 0 0 usb_sg D? 3:17
[usb-storage]
1 04016 1 20 0 161136 1900 usbhid Dsl ? 1:39
/sbin/apcupsd
4 0 1423283 11939 20 0 10648 580 wait_o D+ pts/28 0:00 rm
-rf 15tb3
Sun May 7 05:01:13 EDT 2023
The above lines showing those processes in uninterruptible sleep repeat
over and over each second as the "rm -r" continues. I then start up
"hdparm -t /dev/sda" on the internal SSD disk, and it also appears in
uninterruptible sleep and doesn't finish even after minutes of waiting:
Sun May 7 05:01:25 EDT 2023
1 0 368 2 20 0 0 0 md_sup D? 2:57
[md0_raid5]
1 0 1366783 2 20 0 0 0 blk_mq D? 0:02
[kworker/u16:2+flush-8:144]
4 0 1423283 11939 20 0 11260 2544 wait_o D+ pts/28 0:00 rm
-rf 15tb3
4 0 14235019975 20 0 4680 4584 wb_wai DL+ pts/4 0:00
hdparm -t /dev/sda
Sun May 7 05:01:26 EDT 2023
1 0 447 2 20 0 0 0 usb_sg D? 3:17
[usb-storage]
1 0 1366783 2 20 0 0 0 blk_mq D? 0:02
[kworker/u16:2+flush-8:144]
4 0 1423283 11939 20 0 11260 2544 wait_o D+ pts/28 0:00 rm
-rf 15tb3
4 0 14235019975 20 0 4680 4584 wb_wai DL+ pts/4 0:00
hdparm -t /dev/sda
Sun May 7 05:01:27 EDT 2023
[...]
4 0 14235019975 20 0 4680 4584 wb_wai DL+ pts/4 0:00
hdparm -t /dev/sda
Sun May 7 05:01:35 EDT 2023
1 0 447 2 20 0 0 0 usb_sg D? 3:17
[usb-storage]
4 0 1423283 11939 20 0 11260 2544 blk_mq D+ pts/28 0:00 rm
-rf 15tb3
4 0 14235019975 20 0 4680 4584 wb_wai DL+ pts/4 0:00
hdparm -t /dev/sda
Sun May 7 05:01:36 EDT 2023
1 0 447 2 20 0 0 0 usb_sg D? 3:17
[usb-storage]
1 04985 2 20 0 0 0 rq_qos D? 0:24
[jbd2/sdj1-8]
1 0 1366783 2 20 0 0 0 blk_mq D? 0:02
[kworker/u16:2+flush-8:144]
4 0 1423283 11939 20 0 11260 2544 wait_o D+ pts/28 0:00 rm
-rf 15tb3
4 0 14235019975 20 0 4680 4584 wb_wai DL+ pts/4 0:00
hdparm -t /dev/sda
Sun May 7 05:01:37 EDT 2023
I keep waiting. The above lines repeat over and over and the hdparm is
blocked and doesn't finish.
Sun May 7 05:03:32 EDT 2023
1 0 447 2 20 0 0 0 usb_sg D? 3:18
[usb-storage]
1 0 1366783 2 20 0 0 0 blk_mq D? 0:02
[kworker/u16:2+flush-8:144]
4 0 1423283 11939 20 0 11260 2544 wait_o D+ pts/28 0:03 rm
-rf 15tb3
4 0 14235019975 20 0 4680 4584 wb_wai DL+ pts/4 0:00
hdparm -t /dev/sda
Sun May 7 05:03:34 EDT
[Kernel-packages] [Bug 1804592] Re: usb usb2: We don't know the algorithms for LPM for this host, disabling LPM.
Description:Ubuntu 20.04.4 LTS Linux linux 5.13.0-35-generic #40~20.04.1-Ubuntu SMP Mon Mar 7 09:18:32 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux Mar 11 10:43:28 linux kernel: [1.578010] usb usb6: We don't know the algorithms for LPM for this host, disabling LPM. Mar 11 10:43:28 linux kernel: [1.578061] usb usb6: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 5.13 Mar 11 10:43:28 linux kernel: [1.578066] usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1 Mar 11 10:43:28 linux kernel: [1.578070] usb usb6: Product: xHCI Host Controller Mar 11 10:43:28 linux kernel: [1.578074] usb usb6: Manufacturer: Linux 5.13.0-35-generic xhci-hcd Mar 11 10:43:28 linux kernel: [1.578077] usb usb6: SerialNumber: :08:00.0 Mar 11 10:43:28 linux kernel: [1.578207] hub 6-0:1.0: USB hub found Mar 11 10:43:28 linux kernel: [1.578223] hub 6-0:1.0: 4 ports detected -- 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/1804592 Title: usb usb2: We don't know the algorithms for LPM for this host, disabling LPM. Status in linux package in Ubuntu: Confirmed Bug description: [0.876087] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM. [0.876099] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 4.18 [0.876100] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [0.876101] usb usb2: Product: xHCI Host Controller [0.876102] usb usb2: Manufacturer: Linux 4.18.0-10-generic xhci-hcd [0.876103] usb usb2: SerialNumber: :15:00.0 [0.876206] hub 2-0:1.0: USB hub found [0.876215] hub 2-0:1.0: 4 ports detected To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1804592/+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 1586195] UdevDb.txt
apport information ** Attachment added: "UdevDb.txt" https://bugs.launchpad.net/bugs/1586195/+attachment/5327760/+files/UdevDb.txt -- 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/1586195 Title: Realtek 8153-based ethernet adapter on usb3 eventually stops working requiring unplug/replug Status in linux package in Ubuntu: Confirmed Status in linux source package in Xenial: Expired Bug description: Continued in Bug #1622322. Seems to be paired with dmesg entries like this on the trusty kernel: [24763.731054] usb 4-4.2: Disable of device-initiated U1 failed. [24763.734507] usb 4-4.2: Disable of device-initiated U2 failed. [24763.734594] r815x 4-4.2:2.0 eth3: unregister 'r815x' usb-:00:14.0-4.2, RTL8153 ECM Device [24763.802963] usb 4-4.2: Set SEL for device-initiated U1 failed. [24763.806450] usb 4-4.2: Set SEL for device-initiated U2 failed. [24763.809953] usb 4-4.2: usb_reset_and_verify_device Failed to disable LTM [24763.809953] . [24763.810579] usb 4-4.2: USB disconnect, device number 7 [24763.940765] userif-1: sent link down event. [24763.940769] userif-1: sent link up event. And like this on mainline: [ 259.731142] usb 4-3: new SuperSpeed USB device number 4 using xhci_hcd [ 259.752915] usb 4-3: New USB device found, idVendor=0bda, idProduct=8153 [ 259.752918] usb 4-3: New USB device strings: Mfr=1, Product=2, SerialNumber=6 [ 259.752920] usb 4-3: Product: USB 10/100/1000 LAN [ 259.752921] usb 4-3: Manufacturer: Realtek [ 259.752922] usb 4-3: SerialNumber: 0100 [ 259.909368] usb 4-3: reset SuperSpeed USB device number 4 using xhci_hcd [ 259.993254] r8152 4-3:1.0 eth0: v1.08.3 [ 260.079151] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 296.266600] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 300.785814] r8152 4-3:1.0 eth0: Stop submitting intr, status -71 [ 302.832697] usb 4-3: usb_reset_and_verify_device Failed to disable LTM [ 302.832697] . [ 302.833086] usb 4-3: USB disconnect, device number 4 Mainline version fyi: [0.00] Linux version 4.6.0-040600-generic (kernel@gomeisa) (gcc version 5.3.1 20160509 (Ubuntu 5.3.1-19ubuntu1) ) #201605151930 SMP Sun May 15 23:32:59 UTC 2016 I also get a similar message about 'Failed to disable LTM' if I just unplug the device before the breakage occurs. I've attached lsusb before the breakage occurs (so you can see the device) from the mainline kernel. Interestingly it appears the drivers on trusty and wily/mainline are different (r815x vs r8152) yet still exhibit similar troubles. I'm still digging around to try and figure out why this doesn't seem to be working, but I was wondering if you all had any idea what might be going pear-shaped here. Thanks! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1586195/+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 1586195] ProcModules.txt
apport information ** Attachment added: "ProcModules.txt" https://bugs.launchpad.net/bugs/1586195/+attachment/5327758/+files/ProcModules.txt -- 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/1586195 Title: Realtek 8153-based ethernet adapter on usb3 eventually stops working requiring unplug/replug Status in linux package in Ubuntu: Confirmed Status in linux source package in Xenial: Expired Bug description: Continued in Bug #1622322. Seems to be paired with dmesg entries like this on the trusty kernel: [24763.731054] usb 4-4.2: Disable of device-initiated U1 failed. [24763.734507] usb 4-4.2: Disable of device-initiated U2 failed. [24763.734594] r815x 4-4.2:2.0 eth3: unregister 'r815x' usb-:00:14.0-4.2, RTL8153 ECM Device [24763.802963] usb 4-4.2: Set SEL for device-initiated U1 failed. [24763.806450] usb 4-4.2: Set SEL for device-initiated U2 failed. [24763.809953] usb 4-4.2: usb_reset_and_verify_device Failed to disable LTM [24763.809953] . [24763.810579] usb 4-4.2: USB disconnect, device number 7 [24763.940765] userif-1: sent link down event. [24763.940769] userif-1: sent link up event. And like this on mainline: [ 259.731142] usb 4-3: new SuperSpeed USB device number 4 using xhci_hcd [ 259.752915] usb 4-3: New USB device found, idVendor=0bda, idProduct=8153 [ 259.752918] usb 4-3: New USB device strings: Mfr=1, Product=2, SerialNumber=6 [ 259.752920] usb 4-3: Product: USB 10/100/1000 LAN [ 259.752921] usb 4-3: Manufacturer: Realtek [ 259.752922] usb 4-3: SerialNumber: 0100 [ 259.909368] usb 4-3: reset SuperSpeed USB device number 4 using xhci_hcd [ 259.993254] r8152 4-3:1.0 eth0: v1.08.3 [ 260.079151] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 296.266600] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 300.785814] r8152 4-3:1.0 eth0: Stop submitting intr, status -71 [ 302.832697] usb 4-3: usb_reset_and_verify_device Failed to disable LTM [ 302.832697] . [ 302.833086] usb 4-3: USB disconnect, device number 4 Mainline version fyi: [0.00] Linux version 4.6.0-040600-generic (kernel@gomeisa) (gcc version 5.3.1 20160509 (Ubuntu 5.3.1-19ubuntu1) ) #201605151930 SMP Sun May 15 23:32:59 UTC 2016 I also get a similar message about 'Failed to disable LTM' if I just unplug the device before the breakage occurs. I've attached lsusb before the breakage occurs (so you can see the device) from the mainline kernel. Interestingly it appears the drivers on trusty and wily/mainline are different (r815x vs r8152) yet still exhibit similar troubles. I'm still digging around to try and figure out why this doesn't seem to be working, but I was wondering if you all had any idea what might be going pear-shaped here. Thanks! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1586195/+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 1586195] PulseList.txt
apport information ** Attachment added: "PulseList.txt" https://bugs.launchpad.net/bugs/1586195/+attachment/5327759/+files/PulseList.txt -- 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/1586195 Title: Realtek 8153-based ethernet adapter on usb3 eventually stops working requiring unplug/replug Status in linux package in Ubuntu: Confirmed Status in linux source package in Xenial: Expired Bug description: Continued in Bug #1622322. Seems to be paired with dmesg entries like this on the trusty kernel: [24763.731054] usb 4-4.2: Disable of device-initiated U1 failed. [24763.734507] usb 4-4.2: Disable of device-initiated U2 failed. [24763.734594] r815x 4-4.2:2.0 eth3: unregister 'r815x' usb-:00:14.0-4.2, RTL8153 ECM Device [24763.802963] usb 4-4.2: Set SEL for device-initiated U1 failed. [24763.806450] usb 4-4.2: Set SEL for device-initiated U2 failed. [24763.809953] usb 4-4.2: usb_reset_and_verify_device Failed to disable LTM [24763.809953] . [24763.810579] usb 4-4.2: USB disconnect, device number 7 [24763.940765] userif-1: sent link down event. [24763.940769] userif-1: sent link up event. And like this on mainline: [ 259.731142] usb 4-3: new SuperSpeed USB device number 4 using xhci_hcd [ 259.752915] usb 4-3: New USB device found, idVendor=0bda, idProduct=8153 [ 259.752918] usb 4-3: New USB device strings: Mfr=1, Product=2, SerialNumber=6 [ 259.752920] usb 4-3: Product: USB 10/100/1000 LAN [ 259.752921] usb 4-3: Manufacturer: Realtek [ 259.752922] usb 4-3: SerialNumber: 0100 [ 259.909368] usb 4-3: reset SuperSpeed USB device number 4 using xhci_hcd [ 259.993254] r8152 4-3:1.0 eth0: v1.08.3 [ 260.079151] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 296.266600] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 300.785814] r8152 4-3:1.0 eth0: Stop submitting intr, status -71 [ 302.832697] usb 4-3: usb_reset_and_verify_device Failed to disable LTM [ 302.832697] . [ 302.833086] usb 4-3: USB disconnect, device number 4 Mainline version fyi: [0.00] Linux version 4.6.0-040600-generic (kernel@gomeisa) (gcc version 5.3.1 20160509 (Ubuntu 5.3.1-19ubuntu1) ) #201605151930 SMP Sun May 15 23:32:59 UTC 2016 I also get a similar message about 'Failed to disable LTM' if I just unplug the device before the breakage occurs. I've attached lsusb before the breakage occurs (so you can see the device) from the mainline kernel. Interestingly it appears the drivers on trusty and wily/mainline are different (r815x vs r8152) yet still exhibit similar troubles. I'm still digging around to try and figure out why this doesn't seem to be working, but I was wondering if you all had any idea what might be going pear-shaped here. Thanks! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1586195/+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 1586195] ProcEnviron.txt
apport information ** Attachment added: "ProcEnviron.txt" https://bugs.launchpad.net/bugs/1586195/+attachment/5327756/+files/ProcEnviron.txt -- 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/1586195 Title: Realtek 8153-based ethernet adapter on usb3 eventually stops working requiring unplug/replug Status in linux package in Ubuntu: Confirmed Status in linux source package in Xenial: Expired Bug description: Continued in Bug #1622322. Seems to be paired with dmesg entries like this on the trusty kernel: [24763.731054] usb 4-4.2: Disable of device-initiated U1 failed. [24763.734507] usb 4-4.2: Disable of device-initiated U2 failed. [24763.734594] r815x 4-4.2:2.0 eth3: unregister 'r815x' usb-:00:14.0-4.2, RTL8153 ECM Device [24763.802963] usb 4-4.2: Set SEL for device-initiated U1 failed. [24763.806450] usb 4-4.2: Set SEL for device-initiated U2 failed. [24763.809953] usb 4-4.2: usb_reset_and_verify_device Failed to disable LTM [24763.809953] . [24763.810579] usb 4-4.2: USB disconnect, device number 7 [24763.940765] userif-1: sent link down event. [24763.940769] userif-1: sent link up event. And like this on mainline: [ 259.731142] usb 4-3: new SuperSpeed USB device number 4 using xhci_hcd [ 259.752915] usb 4-3: New USB device found, idVendor=0bda, idProduct=8153 [ 259.752918] usb 4-3: New USB device strings: Mfr=1, Product=2, SerialNumber=6 [ 259.752920] usb 4-3: Product: USB 10/100/1000 LAN [ 259.752921] usb 4-3: Manufacturer: Realtek [ 259.752922] usb 4-3: SerialNumber: 0100 [ 259.909368] usb 4-3: reset SuperSpeed USB device number 4 using xhci_hcd [ 259.993254] r8152 4-3:1.0 eth0: v1.08.3 [ 260.079151] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 296.266600] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 300.785814] r8152 4-3:1.0 eth0: Stop submitting intr, status -71 [ 302.832697] usb 4-3: usb_reset_and_verify_device Failed to disable LTM [ 302.832697] . [ 302.833086] usb 4-3: USB disconnect, device number 4 Mainline version fyi: [0.00] Linux version 4.6.0-040600-generic (kernel@gomeisa) (gcc version 5.3.1 20160509 (Ubuntu 5.3.1-19ubuntu1) ) #201605151930 SMP Sun May 15 23:32:59 UTC 2016 I also get a similar message about 'Failed to disable LTM' if I just unplug the device before the breakage occurs. I've attached lsusb before the breakage occurs (so you can see the device) from the mainline kernel. Interestingly it appears the drivers on trusty and wily/mainline are different (r815x vs r8152) yet still exhibit similar troubles. I'm still digging around to try and figure out why this doesn't seem to be working, but I was wondering if you all had any idea what might be going pear-shaped here. Thanks! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1586195/+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 1586195] ProcInterrupts.txt
apport information ** Attachment added: "ProcInterrupts.txt" https://bugs.launchpad.net/bugs/1586195/+attachment/5327757/+files/ProcInterrupts.txt -- 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/1586195 Title: Realtek 8153-based ethernet adapter on usb3 eventually stops working requiring unplug/replug Status in linux package in Ubuntu: Confirmed Status in linux source package in Xenial: Expired Bug description: Continued in Bug #1622322. Seems to be paired with dmesg entries like this on the trusty kernel: [24763.731054] usb 4-4.2: Disable of device-initiated U1 failed. [24763.734507] usb 4-4.2: Disable of device-initiated U2 failed. [24763.734594] r815x 4-4.2:2.0 eth3: unregister 'r815x' usb-:00:14.0-4.2, RTL8153 ECM Device [24763.802963] usb 4-4.2: Set SEL for device-initiated U1 failed. [24763.806450] usb 4-4.2: Set SEL for device-initiated U2 failed. [24763.809953] usb 4-4.2: usb_reset_and_verify_device Failed to disable LTM [24763.809953] . [24763.810579] usb 4-4.2: USB disconnect, device number 7 [24763.940765] userif-1: sent link down event. [24763.940769] userif-1: sent link up event. And like this on mainline: [ 259.731142] usb 4-3: new SuperSpeed USB device number 4 using xhci_hcd [ 259.752915] usb 4-3: New USB device found, idVendor=0bda, idProduct=8153 [ 259.752918] usb 4-3: New USB device strings: Mfr=1, Product=2, SerialNumber=6 [ 259.752920] usb 4-3: Product: USB 10/100/1000 LAN [ 259.752921] usb 4-3: Manufacturer: Realtek [ 259.752922] usb 4-3: SerialNumber: 0100 [ 259.909368] usb 4-3: reset SuperSpeed USB device number 4 using xhci_hcd [ 259.993254] r8152 4-3:1.0 eth0: v1.08.3 [ 260.079151] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 296.266600] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 300.785814] r8152 4-3:1.0 eth0: Stop submitting intr, status -71 [ 302.832697] usb 4-3: usb_reset_and_verify_device Failed to disable LTM [ 302.832697] . [ 302.833086] usb 4-3: USB disconnect, device number 4 Mainline version fyi: [0.00] Linux version 4.6.0-040600-generic (kernel@gomeisa) (gcc version 5.3.1 20160509 (Ubuntu 5.3.1-19ubuntu1) ) #201605151930 SMP Sun May 15 23:32:59 UTC 2016 I also get a similar message about 'Failed to disable LTM' if I just unplug the device before the breakage occurs. I've attached lsusb before the breakage occurs (so you can see the device) from the mainline kernel. Interestingly it appears the drivers on trusty and wily/mainline are different (r815x vs r8152) yet still exhibit similar troubles. I'm still digging around to try and figure out why this doesn't seem to be working, but I was wondering if you all had any idea what might be going pear-shaped here. Thanks! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1586195/+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 1586195] Lspci.txt
apport information ** Attachment added: "Lspci.txt" https://bugs.launchpad.net/bugs/1586195/+attachment/5327752/+files/Lspci.txt -- 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/1586195 Title: Realtek 8153-based ethernet adapter on usb3 eventually stops working requiring unplug/replug Status in linux package in Ubuntu: Confirmed Status in linux source package in Xenial: Expired Bug description: Continued in Bug #1622322. Seems to be paired with dmesg entries like this on the trusty kernel: [24763.731054] usb 4-4.2: Disable of device-initiated U1 failed. [24763.734507] usb 4-4.2: Disable of device-initiated U2 failed. [24763.734594] r815x 4-4.2:2.0 eth3: unregister 'r815x' usb-:00:14.0-4.2, RTL8153 ECM Device [24763.802963] usb 4-4.2: Set SEL for device-initiated U1 failed. [24763.806450] usb 4-4.2: Set SEL for device-initiated U2 failed. [24763.809953] usb 4-4.2: usb_reset_and_verify_device Failed to disable LTM [24763.809953] . [24763.810579] usb 4-4.2: USB disconnect, device number 7 [24763.940765] userif-1: sent link down event. [24763.940769] userif-1: sent link up event. And like this on mainline: [ 259.731142] usb 4-3: new SuperSpeed USB device number 4 using xhci_hcd [ 259.752915] usb 4-3: New USB device found, idVendor=0bda, idProduct=8153 [ 259.752918] usb 4-3: New USB device strings: Mfr=1, Product=2, SerialNumber=6 [ 259.752920] usb 4-3: Product: USB 10/100/1000 LAN [ 259.752921] usb 4-3: Manufacturer: Realtek [ 259.752922] usb 4-3: SerialNumber: 0100 [ 259.909368] usb 4-3: reset SuperSpeed USB device number 4 using xhci_hcd [ 259.993254] r8152 4-3:1.0 eth0: v1.08.3 [ 260.079151] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 296.266600] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 300.785814] r8152 4-3:1.0 eth0: Stop submitting intr, status -71 [ 302.832697] usb 4-3: usb_reset_and_verify_device Failed to disable LTM [ 302.832697] . [ 302.833086] usb 4-3: USB disconnect, device number 4 Mainline version fyi: [0.00] Linux version 4.6.0-040600-generic (kernel@gomeisa) (gcc version 5.3.1 20160509 (Ubuntu 5.3.1-19ubuntu1) ) #201605151930 SMP Sun May 15 23:32:59 UTC 2016 I also get a similar message about 'Failed to disable LTM' if I just unplug the device before the breakage occurs. I've attached lsusb before the breakage occurs (so you can see the device) from the mainline kernel. Interestingly it appears the drivers on trusty and wily/mainline are different (r815x vs r8152) yet still exhibit similar troubles. I'm still digging around to try and figure out why this doesn't seem to be working, but I was wondering if you all had any idea what might be going pear-shaped here. Thanks! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1586195/+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 1586195] CRDA.txt
apport information ** Attachment added: "CRDA.txt" https://bugs.launchpad.net/bugs/1586195/+attachment/5327749/+files/CRDA.txt -- 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/1586195 Title: Realtek 8153-based ethernet adapter on usb3 eventually stops working requiring unplug/replug Status in linux package in Ubuntu: Confirmed Status in linux source package in Xenial: Expired Bug description: Continued in Bug #1622322. Seems to be paired with dmesg entries like this on the trusty kernel: [24763.731054] usb 4-4.2: Disable of device-initiated U1 failed. [24763.734507] usb 4-4.2: Disable of device-initiated U2 failed. [24763.734594] r815x 4-4.2:2.0 eth3: unregister 'r815x' usb-:00:14.0-4.2, RTL8153 ECM Device [24763.802963] usb 4-4.2: Set SEL for device-initiated U1 failed. [24763.806450] usb 4-4.2: Set SEL for device-initiated U2 failed. [24763.809953] usb 4-4.2: usb_reset_and_verify_device Failed to disable LTM [24763.809953] . [24763.810579] usb 4-4.2: USB disconnect, device number 7 [24763.940765] userif-1: sent link down event. [24763.940769] userif-1: sent link up event. And like this on mainline: [ 259.731142] usb 4-3: new SuperSpeed USB device number 4 using xhci_hcd [ 259.752915] usb 4-3: New USB device found, idVendor=0bda, idProduct=8153 [ 259.752918] usb 4-3: New USB device strings: Mfr=1, Product=2, SerialNumber=6 [ 259.752920] usb 4-3: Product: USB 10/100/1000 LAN [ 259.752921] usb 4-3: Manufacturer: Realtek [ 259.752922] usb 4-3: SerialNumber: 0100 [ 259.909368] usb 4-3: reset SuperSpeed USB device number 4 using xhci_hcd [ 259.993254] r8152 4-3:1.0 eth0: v1.08.3 [ 260.079151] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 296.266600] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 300.785814] r8152 4-3:1.0 eth0: Stop submitting intr, status -71 [ 302.832697] usb 4-3: usb_reset_and_verify_device Failed to disable LTM [ 302.832697] . [ 302.833086] usb 4-3: USB disconnect, device number 4 Mainline version fyi: [0.00] Linux version 4.6.0-040600-generic (kernel@gomeisa) (gcc version 5.3.1 20160509 (Ubuntu 5.3.1-19ubuntu1) ) #201605151930 SMP Sun May 15 23:32:59 UTC 2016 I also get a similar message about 'Failed to disable LTM' if I just unplug the device before the breakage occurs. I've attached lsusb before the breakage occurs (so you can see the device) from the mainline kernel. Interestingly it appears the drivers on trusty and wily/mainline are different (r815x vs r8152) yet still exhibit similar troubles. I'm still digging around to try and figure out why this doesn't seem to be working, but I was wondering if you all had any idea what might be going pear-shaped here. Thanks! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1586195/+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 1586195] IwConfig.txt
apport information ** Attachment added: "IwConfig.txt" https://bugs.launchpad.net/bugs/1586195/+attachment/5327751/+files/IwConfig.txt -- 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/1586195 Title: Realtek 8153-based ethernet adapter on usb3 eventually stops working requiring unplug/replug Status in linux package in Ubuntu: Confirmed Status in linux source package in Xenial: Expired Bug description: Continued in Bug #1622322. Seems to be paired with dmesg entries like this on the trusty kernel: [24763.731054] usb 4-4.2: Disable of device-initiated U1 failed. [24763.734507] usb 4-4.2: Disable of device-initiated U2 failed. [24763.734594] r815x 4-4.2:2.0 eth3: unregister 'r815x' usb-:00:14.0-4.2, RTL8153 ECM Device [24763.802963] usb 4-4.2: Set SEL for device-initiated U1 failed. [24763.806450] usb 4-4.2: Set SEL for device-initiated U2 failed. [24763.809953] usb 4-4.2: usb_reset_and_verify_device Failed to disable LTM [24763.809953] . [24763.810579] usb 4-4.2: USB disconnect, device number 7 [24763.940765] userif-1: sent link down event. [24763.940769] userif-1: sent link up event. And like this on mainline: [ 259.731142] usb 4-3: new SuperSpeed USB device number 4 using xhci_hcd [ 259.752915] usb 4-3: New USB device found, idVendor=0bda, idProduct=8153 [ 259.752918] usb 4-3: New USB device strings: Mfr=1, Product=2, SerialNumber=6 [ 259.752920] usb 4-3: Product: USB 10/100/1000 LAN [ 259.752921] usb 4-3: Manufacturer: Realtek [ 259.752922] usb 4-3: SerialNumber: 0100 [ 259.909368] usb 4-3: reset SuperSpeed USB device number 4 using xhci_hcd [ 259.993254] r8152 4-3:1.0 eth0: v1.08.3 [ 260.079151] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 296.266600] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 300.785814] r8152 4-3:1.0 eth0: Stop submitting intr, status -71 [ 302.832697] usb 4-3: usb_reset_and_verify_device Failed to disable LTM [ 302.832697] . [ 302.833086] usb 4-3: USB disconnect, device number 4 Mainline version fyi: [0.00] Linux version 4.6.0-040600-generic (kernel@gomeisa) (gcc version 5.3.1 20160509 (Ubuntu 5.3.1-19ubuntu1) ) #201605151930 SMP Sun May 15 23:32:59 UTC 2016 I also get a similar message about 'Failed to disable LTM' if I just unplug the device before the breakage occurs. I've attached lsusb before the breakage occurs (so you can see the device) from the mainline kernel. Interestingly it appears the drivers on trusty and wily/mainline are different (r815x vs r8152) yet still exhibit similar troubles. I'm still digging around to try and figure out why this doesn't seem to be working, but I was wondering if you all had any idea what might be going pear-shaped here. Thanks! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1586195/+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 1586195] ProcCpuinfo.txt
apport information ** Attachment added: "ProcCpuinfo.txt" https://bugs.launchpad.net/bugs/1586195/+attachment/5327754/+files/ProcCpuinfo.txt -- 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/1586195 Title: Realtek 8153-based ethernet adapter on usb3 eventually stops working requiring unplug/replug Status in linux package in Ubuntu: Confirmed Status in linux source package in Xenial: Expired Bug description: Continued in Bug #1622322. Seems to be paired with dmesg entries like this on the trusty kernel: [24763.731054] usb 4-4.2: Disable of device-initiated U1 failed. [24763.734507] usb 4-4.2: Disable of device-initiated U2 failed. [24763.734594] r815x 4-4.2:2.0 eth3: unregister 'r815x' usb-:00:14.0-4.2, RTL8153 ECM Device [24763.802963] usb 4-4.2: Set SEL for device-initiated U1 failed. [24763.806450] usb 4-4.2: Set SEL for device-initiated U2 failed. [24763.809953] usb 4-4.2: usb_reset_and_verify_device Failed to disable LTM [24763.809953] . [24763.810579] usb 4-4.2: USB disconnect, device number 7 [24763.940765] userif-1: sent link down event. [24763.940769] userif-1: sent link up event. And like this on mainline: [ 259.731142] usb 4-3: new SuperSpeed USB device number 4 using xhci_hcd [ 259.752915] usb 4-3: New USB device found, idVendor=0bda, idProduct=8153 [ 259.752918] usb 4-3: New USB device strings: Mfr=1, Product=2, SerialNumber=6 [ 259.752920] usb 4-3: Product: USB 10/100/1000 LAN [ 259.752921] usb 4-3: Manufacturer: Realtek [ 259.752922] usb 4-3: SerialNumber: 0100 [ 259.909368] usb 4-3: reset SuperSpeed USB device number 4 using xhci_hcd [ 259.993254] r8152 4-3:1.0 eth0: v1.08.3 [ 260.079151] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 296.266600] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 300.785814] r8152 4-3:1.0 eth0: Stop submitting intr, status -71 [ 302.832697] usb 4-3: usb_reset_and_verify_device Failed to disable LTM [ 302.832697] . [ 302.833086] usb 4-3: USB disconnect, device number 4 Mainline version fyi: [0.00] Linux version 4.6.0-040600-generic (kernel@gomeisa) (gcc version 5.3.1 20160509 (Ubuntu 5.3.1-19ubuntu1) ) #201605151930 SMP Sun May 15 23:32:59 UTC 2016 I also get a similar message about 'Failed to disable LTM' if I just unplug the device before the breakage occurs. I've attached lsusb before the breakage occurs (so you can see the device) from the mainline kernel. Interestingly it appears the drivers on trusty and wily/mainline are different (r815x vs r8152) yet still exhibit similar troubles. I'm still digging around to try and figure out why this doesn't seem to be working, but I was wondering if you all had any idea what might be going pear-shaped here. Thanks! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1586195/+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 1586195] CurrentDmesg.txt
apport information ** Attachment added: "CurrentDmesg.txt" https://bugs.launchpad.net/bugs/1586195/+attachment/5327750/+files/CurrentDmesg.txt -- 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/1586195 Title: Realtek 8153-based ethernet adapter on usb3 eventually stops working requiring unplug/replug Status in linux package in Ubuntu: Confirmed Status in linux source package in Xenial: Expired Bug description: Continued in Bug #1622322. Seems to be paired with dmesg entries like this on the trusty kernel: [24763.731054] usb 4-4.2: Disable of device-initiated U1 failed. [24763.734507] usb 4-4.2: Disable of device-initiated U2 failed. [24763.734594] r815x 4-4.2:2.0 eth3: unregister 'r815x' usb-:00:14.0-4.2, RTL8153 ECM Device [24763.802963] usb 4-4.2: Set SEL for device-initiated U1 failed. [24763.806450] usb 4-4.2: Set SEL for device-initiated U2 failed. [24763.809953] usb 4-4.2: usb_reset_and_verify_device Failed to disable LTM [24763.809953] . [24763.810579] usb 4-4.2: USB disconnect, device number 7 [24763.940765] userif-1: sent link down event. [24763.940769] userif-1: sent link up event. And like this on mainline: [ 259.731142] usb 4-3: new SuperSpeed USB device number 4 using xhci_hcd [ 259.752915] usb 4-3: New USB device found, idVendor=0bda, idProduct=8153 [ 259.752918] usb 4-3: New USB device strings: Mfr=1, Product=2, SerialNumber=6 [ 259.752920] usb 4-3: Product: USB 10/100/1000 LAN [ 259.752921] usb 4-3: Manufacturer: Realtek [ 259.752922] usb 4-3: SerialNumber: 0100 [ 259.909368] usb 4-3: reset SuperSpeed USB device number 4 using xhci_hcd [ 259.993254] r8152 4-3:1.0 eth0: v1.08.3 [ 260.079151] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 296.266600] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 300.785814] r8152 4-3:1.0 eth0: Stop submitting intr, status -71 [ 302.832697] usb 4-3: usb_reset_and_verify_device Failed to disable LTM [ 302.832697] . [ 302.833086] usb 4-3: USB disconnect, device number 4 Mainline version fyi: [0.00] Linux version 4.6.0-040600-generic (kernel@gomeisa) (gcc version 5.3.1 20160509 (Ubuntu 5.3.1-19ubuntu1) ) #201605151930 SMP Sun May 15 23:32:59 UTC 2016 I also get a similar message about 'Failed to disable LTM' if I just unplug the device before the breakage occurs. I've attached lsusb before the breakage occurs (so you can see the device) from the mainline kernel. Interestingly it appears the drivers on trusty and wily/mainline are different (r815x vs r8152) yet still exhibit similar troubles. I'm still digging around to try and figure out why this doesn't seem to be working, but I was wondering if you all had any idea what might be going pear-shaped here. Thanks! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1586195/+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 1586195] Lsusb.txt
apport information ** Attachment added: "Lsusb.txt" https://bugs.launchpad.net/bugs/1586195/+attachment/5327753/+files/Lsusb.txt -- 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/1586195 Title: Realtek 8153-based ethernet adapter on usb3 eventually stops working requiring unplug/replug Status in linux package in Ubuntu: Confirmed Status in linux source package in Xenial: Expired Bug description: Continued in Bug #1622322. Seems to be paired with dmesg entries like this on the trusty kernel: [24763.731054] usb 4-4.2: Disable of device-initiated U1 failed. [24763.734507] usb 4-4.2: Disable of device-initiated U2 failed. [24763.734594] r815x 4-4.2:2.0 eth3: unregister 'r815x' usb-:00:14.0-4.2, RTL8153 ECM Device [24763.802963] usb 4-4.2: Set SEL for device-initiated U1 failed. [24763.806450] usb 4-4.2: Set SEL for device-initiated U2 failed. [24763.809953] usb 4-4.2: usb_reset_and_verify_device Failed to disable LTM [24763.809953] . [24763.810579] usb 4-4.2: USB disconnect, device number 7 [24763.940765] userif-1: sent link down event. [24763.940769] userif-1: sent link up event. And like this on mainline: [ 259.731142] usb 4-3: new SuperSpeed USB device number 4 using xhci_hcd [ 259.752915] usb 4-3: New USB device found, idVendor=0bda, idProduct=8153 [ 259.752918] usb 4-3: New USB device strings: Mfr=1, Product=2, SerialNumber=6 [ 259.752920] usb 4-3: Product: USB 10/100/1000 LAN [ 259.752921] usb 4-3: Manufacturer: Realtek [ 259.752922] usb 4-3: SerialNumber: 0100 [ 259.909368] usb 4-3: reset SuperSpeed USB device number 4 using xhci_hcd [ 259.993254] r8152 4-3:1.0 eth0: v1.08.3 [ 260.079151] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 296.266600] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 300.785814] r8152 4-3:1.0 eth0: Stop submitting intr, status -71 [ 302.832697] usb 4-3: usb_reset_and_verify_device Failed to disable LTM [ 302.832697] . [ 302.833086] usb 4-3: USB disconnect, device number 4 Mainline version fyi: [0.00] Linux version 4.6.0-040600-generic (kernel@gomeisa) (gcc version 5.3.1 20160509 (Ubuntu 5.3.1-19ubuntu1) ) #201605151930 SMP Sun May 15 23:32:59 UTC 2016 I also get a similar message about 'Failed to disable LTM' if I just unplug the device before the breakage occurs. I've attached lsusb before the breakage occurs (so you can see the device) from the mainline kernel. Interestingly it appears the drivers on trusty and wily/mainline are different (r815x vs r8152) yet still exhibit similar troubles. I'm still digging around to try and figure out why this doesn't seem to be working, but I was wondering if you all had any idea what might be going pear-shaped here. Thanks! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1586195/+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 1586195] AlsaInfo.txt
apport information ** Attachment added: "AlsaInfo.txt" https://bugs.launchpad.net/bugs/1586195/+attachment/5327748/+files/AlsaInfo.txt -- 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/1586195 Title: Realtek 8153-based ethernet adapter on usb3 eventually stops working requiring unplug/replug Status in linux package in Ubuntu: Confirmed Status in linux source package in Xenial: Expired Bug description: Continued in Bug #1622322. Seems to be paired with dmesg entries like this on the trusty kernel: [24763.731054] usb 4-4.2: Disable of device-initiated U1 failed. [24763.734507] usb 4-4.2: Disable of device-initiated U2 failed. [24763.734594] r815x 4-4.2:2.0 eth3: unregister 'r815x' usb-:00:14.0-4.2, RTL8153 ECM Device [24763.802963] usb 4-4.2: Set SEL for device-initiated U1 failed. [24763.806450] usb 4-4.2: Set SEL for device-initiated U2 failed. [24763.809953] usb 4-4.2: usb_reset_and_verify_device Failed to disable LTM [24763.809953] . [24763.810579] usb 4-4.2: USB disconnect, device number 7 [24763.940765] userif-1: sent link down event. [24763.940769] userif-1: sent link up event. And like this on mainline: [ 259.731142] usb 4-3: new SuperSpeed USB device number 4 using xhci_hcd [ 259.752915] usb 4-3: New USB device found, idVendor=0bda, idProduct=8153 [ 259.752918] usb 4-3: New USB device strings: Mfr=1, Product=2, SerialNumber=6 [ 259.752920] usb 4-3: Product: USB 10/100/1000 LAN [ 259.752921] usb 4-3: Manufacturer: Realtek [ 259.752922] usb 4-3: SerialNumber: 0100 [ 259.909368] usb 4-3: reset SuperSpeed USB device number 4 using xhci_hcd [ 259.993254] r8152 4-3:1.0 eth0: v1.08.3 [ 260.079151] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 296.266600] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 300.785814] r8152 4-3:1.0 eth0: Stop submitting intr, status -71 [ 302.832697] usb 4-3: usb_reset_and_verify_device Failed to disable LTM [ 302.832697] . [ 302.833086] usb 4-3: USB disconnect, device number 4 Mainline version fyi: [0.00] Linux version 4.6.0-040600-generic (kernel@gomeisa) (gcc version 5.3.1 20160509 (Ubuntu 5.3.1-19ubuntu1) ) #201605151930 SMP Sun May 15 23:32:59 UTC 2016 I also get a similar message about 'Failed to disable LTM' if I just unplug the device before the breakage occurs. I've attached lsusb before the breakage occurs (so you can see the device) from the mainline kernel. Interestingly it appears the drivers on trusty and wily/mainline are different (r815x vs r8152) yet still exhibit similar troubles. I'm still digging around to try and figure out why this doesn't seem to be working, but I was wondering if you all had any idea what might be going pear-shaped here. Thanks! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1586195/+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 1586195] ProcCpuinfoMinimal.txt
apport information ** Attachment added: "ProcCpuinfoMinimal.txt" https://bugs.launchpad.net/bugs/1586195/+attachment/5327755/+files/ProcCpuinfoMinimal.txt -- 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/1586195 Title: Realtek 8153-based ethernet adapter on usb3 eventually stops working requiring unplug/replug Status in linux package in Ubuntu: Confirmed Status in linux source package in Xenial: Expired Bug description: Continued in Bug #1622322. Seems to be paired with dmesg entries like this on the trusty kernel: [24763.731054] usb 4-4.2: Disable of device-initiated U1 failed. [24763.734507] usb 4-4.2: Disable of device-initiated U2 failed. [24763.734594] r815x 4-4.2:2.0 eth3: unregister 'r815x' usb-:00:14.0-4.2, RTL8153 ECM Device [24763.802963] usb 4-4.2: Set SEL for device-initiated U1 failed. [24763.806450] usb 4-4.2: Set SEL for device-initiated U2 failed. [24763.809953] usb 4-4.2: usb_reset_and_verify_device Failed to disable LTM [24763.809953] . [24763.810579] usb 4-4.2: USB disconnect, device number 7 [24763.940765] userif-1: sent link down event. [24763.940769] userif-1: sent link up event. And like this on mainline: [ 259.731142] usb 4-3: new SuperSpeed USB device number 4 using xhci_hcd [ 259.752915] usb 4-3: New USB device found, idVendor=0bda, idProduct=8153 [ 259.752918] usb 4-3: New USB device strings: Mfr=1, Product=2, SerialNumber=6 [ 259.752920] usb 4-3: Product: USB 10/100/1000 LAN [ 259.752921] usb 4-3: Manufacturer: Realtek [ 259.752922] usb 4-3: SerialNumber: 0100 [ 259.909368] usb 4-3: reset SuperSpeed USB device number 4 using xhci_hcd [ 259.993254] r8152 4-3:1.0 eth0: v1.08.3 [ 260.079151] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 296.266600] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 300.785814] r8152 4-3:1.0 eth0: Stop submitting intr, status -71 [ 302.832697] usb 4-3: usb_reset_and_verify_device Failed to disable LTM [ 302.832697] . [ 302.833086] usb 4-3: USB disconnect, device number 4 Mainline version fyi: [0.00] Linux version 4.6.0-040600-generic (kernel@gomeisa) (gcc version 5.3.1 20160509 (Ubuntu 5.3.1-19ubuntu1) ) #201605151930 SMP Sun May 15 23:32:59 UTC 2016 I also get a similar message about 'Failed to disable LTM' if I just unplug the device before the breakage occurs. I've attached lsusb before the breakage occurs (so you can see the device) from the mainline kernel. Interestingly it appears the drivers on trusty and wily/mainline are different (r815x vs r8152) yet still exhibit similar troubles. I'm still digging around to try and figure out why this doesn't seem to be working, but I was wondering if you all had any idea what might be going pear-shaped here. Thanks! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1586195/+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 1586195] Re: Realtek 8153-based ethernet adapter on usb3 eventually stops working requiring unplug/replug
ProblemType: Bug ApportVersion: 2.20.9-0ubuntu7.9 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: idallen 30789 F pulseaudio CurrentDesktop: ubuntu:GNOME DistroRelease: Ubuntu 18.04 InstallationDate: Installed on 2015-04-28 (1751 days ago) InstallationMedia: Ubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422) MachineType: System manufacturer System Product Name Package: linux (not installed) ProcFB: 0 radeondrmfb 1 radeondrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-76-generic root=UUID=5a875d56-b2fd-43bd-b9a4-ecf90aced5fa ro ProcVersionSignature: Ubuntu 4.15.0-76.86-generic 4.15.18 RelatedPackageVersions: linux-restricted-modules-4.15.0-76-generic N/A linux-backports-modules-4.15.0-76-generic N/A linux-firmware 1.173.14 RfKill: Tags: bionic Uname: Linux 4.15.0-76-generic x86_64 UpgradeStatus: Upgraded to bionic on 2018-09-02 (528 days ago) UserGroups: adm audio cdrom davfs2 dip docker lpadmin lxd plugdev sambashare sudo wireshark _MarkForUpload: True dmi.bios.date: 06/10/2009 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 1303 dmi.board.asset.tag: To Be Filled By O.E.M. dmi.board.name: M4A79T Deluxe dmi.board.vendor: ASUSTeK Computer INC. dmi.board.version: Rev 1.xx dmi.chassis.asset.tag: Asset-1234567890 dmi.chassis.type: 3 dmi.chassis.vendor: Chassis Manufacture dmi.chassis.version: Chassis Version dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr1303:bd06/10/2009:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKComputerINC.:rnM4A79TDeluxe:rvrRev1.xx:cvnChassisManufacture:ct3:cvrChassisVersion: dmi.product.family: To Be Filled By O.E.M. dmi.product.name: System Product Name dmi.product.version: System Version dmi.sys.vendor: System manufacturer ** Tags added: apport-collected bionic -- 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/1586195 Title: Realtek 8153-based ethernet adapter on usb3 eventually stops working requiring unplug/replug Status in linux package in Ubuntu: Confirmed Status in linux source package in Xenial: Expired Bug description: Continued in Bug #1622322. Seems to be paired with dmesg entries like this on the trusty kernel: [24763.731054] usb 4-4.2: Disable of device-initiated U1 failed. [24763.734507] usb 4-4.2: Disable of device-initiated U2 failed. [24763.734594] r815x 4-4.2:2.0 eth3: unregister 'r815x' usb-:00:14.0-4.2, RTL8153 ECM Device [24763.802963] usb 4-4.2: Set SEL for device-initiated U1 failed. [24763.806450] usb 4-4.2: Set SEL for device-initiated U2 failed. [24763.809953] usb 4-4.2: usb_reset_and_verify_device Failed to disable LTM [24763.809953] . [24763.810579] usb 4-4.2: USB disconnect, device number 7 [24763.940765] userif-1: sent link down event. [24763.940769] userif-1: sent link up event. And like this on mainline: [ 259.731142] usb 4-3: new SuperSpeed USB device number 4 using xhci_hcd [ 259.752915] usb 4-3: New USB device found, idVendor=0bda, idProduct=8153 [ 259.752918] usb 4-3: New USB device strings: Mfr=1, Product=2, SerialNumber=6 [ 259.752920] usb 4-3: Product: USB 10/100/1000 LAN [ 259.752921] usb 4-3: Manufacturer: Realtek [ 259.752922] usb 4-3: SerialNumber: 0100 [ 259.909368] usb 4-3: reset SuperSpeed USB device number 4 using xhci_hcd [ 259.993254] r8152 4-3:1.0 eth0: v1.08.3 [ 260.079151] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 296.266600] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 300.785814] r8152 4-3:1.0 eth0: Stop submitting intr, status -71 [ 302.832697] usb 4-3: usb_reset_and_verify_device Failed to disable LTM [ 302.832697] . [ 302.833086] usb 4-3: USB disconnect, device number 4 Mainline version fyi: [0.00] Linux version 4.6.0-040600-generic (kernel@gomeisa) (gcc version 5.3.1 20160509 (Ubuntu 5.3.1-19ubuntu1) ) #201605151930 SMP Sun May 15 23:32:59 UTC 2016 I also get a similar message about 'Failed to disable LTM' if I just unplug the device before the breakage occurs. I've attached lsusb before the breakage occurs (so you can see the device) from the mainline kernel. Interestingly it appears the drivers on trusty and wily/mainline are different (r815x vs r8152) yet still exhibit similar troubles. I'm still digging around to try and figure out why this doesn't seem to be working, but I was wondering if you all had any idea what might be going pear-shaped here. Thanks! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1586195/+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 1586195] Re: Realtek 8153-based ethernet adapter on usb3 eventually stops working requiring unplug/replug
USB 3 Gigabit Ethernet device (Realtek) disconnect/reconnect repeats randomly. $ lsb_release -a [...] Description:Ubuntu 18.04.4 LTS $ uname -a Linux linux 4.15.0-76-generic #86-Ubuntu SMP Fri Jan 17 17:24:28 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux $ lsusb [...] Bus 009 Device 003: ID 0bda:8153 Realtek Semiconductor Corp. Bus 009 Device 054: ID 0bda:8153 Realtek Semiconductor Corp. Syslog (two incidents of many): Feb 10 05:38:56 idallen-oak kernel: [1148004.410285] r8152 9-3.4:1.0 eth3: Stop submitting intr, status -71 Feb 10 05:38:56 idallen-oak kernel: [1148004.578733] usb 9-3: USB disconnect, device number 39 Feb 10 05:38:56 idallen-oak kernel: [1148004.578741] usb 9-3.4: USB disconnect, device number 40 Feb 10 05:38:56 idallen-oak NetworkManager[1403]: [1581331136.8384] devices removed (path: /sys/devices/pci:00/:00:05.0/:05:00.0/usb9/9-3/9-3.4/9-3.4:1.0/net/eth3, iface: eth3) Feb 10 05:38:56 idallen-oak NetworkManager[1403]: [1581331136.8564] get unmanaged devices count: 2 Feb 10 05:38:56 idallen-oak kernel: [1148004.908306] usb 9-3: new SuperSpeed USB device number 41 using xhci_hcd Feb 10 05:38:56 idallen-oak kernel: [1148004.944551] usb 9-3: New USB device found, idVendor=0bda, idProduct=0411 Feb 10 05:38:56 idallen-oak kernel: [1148004.944558] usb 9-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Feb 10 05:38:56 idallen-oak kernel: [1148004.944563] usb 9-3: Product: 4-Port USB 3.0 Hub Feb 10 05:38:56 idallen-oak kernel: [1148004.944566] usb 9-3: Manufacturer: Generic Feb 10 05:38:57 idallen-oak kernel: [1148004.949495] hub 9-3:1.0: USB hub found Feb 10 05:38:57 idallen-oak kernel: [1148004.951169] hub 9-3:1.0: 4 ports detected Feb 10 05:38:57 idallen-oak upowerd[4883]: unhandled action 'bind' on /sys/devices/pci:00/:00:05.0/:05:00.0/usb9/9-3/9-3:1.0 Feb 10 05:38:57 idallen-oak upowerd[4883]: unhandled action 'bind' on /sys/devices/pci:00/:00:05.0/:05:00.0/usb9/9-3 Feb 10 05:38:57 idallen-oak kernel: [1148005.247277] usb 9-3.4: new SuperSpeed USB device number 42 using xhci_hcd Feb 10 05:38:57 idallen-oak kernel: [1148005.277094] usb 9-3.4: New USB device found, idVendor=0bda, idProduct=8153 Feb 10 05:38:57 idallen-oak kernel: [1148005.277102] usb 9-3.4: New USB device strings: Mfr=1, Product=2, SerialNumber=6 Feb 10 05:38:57 idallen-oak kernel: [1148005.277107] usb 9-3.4: Product: USB 10/100/1000 LAN Feb 10 05:38:57 idallen-oak kernel: [1148005.277111] usb 9-3.4: Manufacturer: CMI Feb 10 05:38:57 idallen-oak kernel: [1148005.277114] usb 9-3.4: SerialNumber: 01 Feb 10 05:38:57 idallen-oak kernel: [1148005.373123] usb 9-3.4: reset SuperSpeed USB device number 42 using xhci_hcd Feb 10 05:38:57 idallen-oak kernel: [1148005.752039] r8152 9-3.4:1.0 eth3: renamed from eth1 Feb 10 05:38:58 idallen-oak NetworkManager[1403]: [1581331138.2100] devices added (path: /sys/devices/pci:00/:00:05.0/:05:00.0/usb9/9-3/9-3.4/9-3.4:1.0/net/eth3, iface: eth3) Feb 10 05:39:00 idallen-oak kernel: [1148008.501102] r8152 9-3.4:1.0 eth3: carrier on A few minutes later, it repeats: Feb 10 10:56:43 idallen-oak kernel: [1167071.434329] r8152 9-3.4:1.0 eth3: Stop submitting intr, status -71 Feb 10 10:56:43 idallen-oak kernel: [1167071.597275] usb 9-3: USB disconnect, device number 41 Feb 10 10:56:43 idallen-oak kernel: [1167071.597283] usb 9-3.4: USB disconnect, device number 42 Feb 10 10:56:43 idallen-oak NetworkManager[1403]: [1581350203.5700] devices removed (path: /sys/devices/pci:00/:00:05.0/:05:00.0/usb9/9-3/9-3.4/9-3.4:1.0/net/eth3, iface: eth3) Feb 10 10:56:43 idallen-oak NetworkManager[1403]: [1581350203.5720] get unmanaged devices count: 2 Feb 10 10:56:43 idallen-oak kernel: [1167071.930010] usb 9-3: new SuperSpeed USB device number 43 using xhci_hcd Feb 10 10:56:43 idallen-oak kernel: [1167071.964334] usb 9-3: New USB device found, idVendor=0bda, idProduct=0411 Feb 10 10:56:43 idallen-oak kernel: [1167071.964341] usb 9-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Feb 10 10:56:43 idallen-oak kernel: [1167071.964346] usb 9-3: Product: 4-Port USB 3.0 Hub Feb 10 10:56:43 idallen-oak kernel: [1167071.964349] usb 9-3: Manufacturer: Generic Feb 10 10:56:43 idallen-oak kernel: [1167071.969105] hub 9-3:1.0: USB hub found Feb 10 10:56:43 idallen-oak kernel: [1167071.970389] hub 9-3:1.0: 4 ports detected Feb 10 10:56:43 idallen-oak upowerd[4883]: unhandled action 'bind' on /sys/devices/pci:00/:00:05.0/:05:00.0/usb9/9-3/9-3:1.0 Feb 10 10:56:43 idallen-oak upowerd[4883]: unhandled action 'bind' on /sys/devices/pci:00/:00:05.0/:05:00.0/usb9/9-3 Feb 10 10:56:44 idallen-oak kernel: [1167072.269853] usb 9-3.4: new SuperSpeed USB device number 44 using xhci_hcd Feb 10 10:56:44 idallen-oak kernel: [1167072.295017] usb 9-3.4: New USB device found, idVendor=0bda, idProduct=8153 Feb 10 10:56:44 idallen-oak kernel: [1167072.295025] usb 9-3.4: New USB device
[Kernel-packages] [Bug 1516052] Re: [regression] 3.13.0-69 infinite ip rules
*** This bug is a duplicate of bug 1514785 *** https://bugs.launchpad.net/bugs/1514785 The recent Ubuntu 15.04 kernel update to vmlinuz-3.19.0-37-generic installed this same bug. I had to reboot back to vmlinuz-3.19.0-33-generic to avoid the loop. -- 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/1516052 Title: [regression] 3.13.0-69 infinite ip rules Status in linux package in Ubuntu: Confirmed Bug description: When I run the 3.13.0-69 -proposed kernel on Trusty, I'm seeing infinite amount of ip rules: $ ip -f inet rule show | head 0:from all lookup local 0:from all lookup local 0:from all lookup local 0:from all lookup local 0:from all lookup local 0:from all lookup local 0:from all lookup local 0:from all lookup local 0:from all lookup local 0:from all lookup local And it never stops: $ time ip -f inet rule show | wc -l ^C real 3m30.262s user 0m46.742s sys 3m39.516s Deleting the "lookup local" then shows an infinite amount of "lookup main". When I go back to 3.13.0-68, things look normal: $ time ip -f inet rule show 0:from all lookup local 32766:from all lookup main 32767:from all lookup default real 0m0.002s user 0m0.000s sys 0m0.002s To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1516052/+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 1514785] Re: kernel 3.16.0.52+53 - ip rule repeats all default rules (messing up rule table)
The recent Ubuntu 15.04 kernel update to vmlinuz-3.19.0-37-generic installed this same bug. I had to reboot back to vmlinuz-3.19.0-33-generic to avoid the loop. -- 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/1514785 Title: kernel 3.16.0.52+53 - ip rule repeats all default rules (messing up rule table) Status in linux package in Ubuntu: Confirmed Status in linux-lts-utopic package in Ubuntu: Invalid Status in linux source package in Trusty: Fix Released Status in linux-lts-utopic source package in Trusty: Fix Released Status in linux source package in Vivid: Fix Committed Bug description: Kernel breaks PBR routing on several versions. Problem occurs on server and desktop. Example using linux-image-3.13.0-70 lsb_release: Ubutu 14.04.3 LTS Release 14.04 Expected: To have the normal rule table when using 'ip rule show' 0: from all lookup local 32766: from all lookup main 32767: from all lookup default Instead: The 'ip rule show' command is messed up showing lots of repeated rules for local/main/default (did not count them - simply too much) A sec prob in my case as it is making policy based routing useless if you need to grep whether your rule exists already. Workaraound, go back to/remain on either of these series: 3.13.0-68 3.16.0.51 PBR NOT working on: 3.13.0-69 3.13.0-70 3.16.0-52 3.16.0-53 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1514785/+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
