Re: intensive IO on usb-storage device causing system lock
Thank you. If I'll be able I'll try. Thank you again guys. Enrico On Wed, 11 Feb 2015, Alan Stern wrote: Date: Wed, 11 Feb 2015 16:21:50 From: Alan Stern st...@rowland.harvard.edu To: Enrico Mioso mrkiko...@gmail.com Cc: linux-usb@vger.kernel.org, linux-ker...@vger.kernel.org Subject: Re: intensive IO on usb-storage device causing system lock On Tue, 10 Feb 2015, Enrico Mioso wrote: Hello guys. the problem is still reproducible with final 3.19 kernel - I can confirm it. Re-sending the last trace here - don't know if it's available in cxg.de. Please stop posting these process traces. They don't help. Instead, post a usbmon trace showing what happens around the time when the problem occurs. If the trace file is quite large (which is likely, because usbmon can generate a lot of data in a short time), you can cut out everything up to the last few hundreds of KB before the problem starts. For those who might not have read the thread - the problem is: after some intensive IO to an USB (usb-storage) disk, for a more or less long time, depending on the quantity of IO you do, there start to be situations where some processes get stuck doing IO, in any case. Not IO to the USB disk, but IO also to other devices, like the one where the root partition resides, in my case a flash drive. I am using an EEE PC 701. That sounds like the problem may lie somewhere other than in the USB stack. But there's no way to tell without seeing a usbmon trace. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: intensive IO on usb-storage device causing system lock
On Tue, 10 Feb 2015, Enrico Mioso wrote: Hello guys. the problem is still reproducible with final 3.19 kernel - I can confirm it. Re-sending the last trace here - don't know if it's available in cxg.de. Please stop posting these process traces. They don't help. Instead, post a usbmon trace showing what happens around the time when the problem occurs. If the trace file is quite large (which is likely, because usbmon can generate a lot of data in a short time), you can cut out everything up to the last few hundreds of KB before the problem starts. For those who might not have read the thread - the problem is: after some intensive IO to an USB (usb-storage) disk, for a more or less long time, depending on the quantity of IO you do, there start to be situations where some processes get stuck doing IO, in any case. Not IO to the USB disk, but IO also to other devices, like the one where the root partition resides, in my case a flash drive. I am using an EEE PC 701. That sounds like the problem may lie somewhere other than in the USB stack. But there's no way to tell without seeing a usbmon trace. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: intensive IO on usb-storage device causing system lock
It seems the problem is also triggerable without rtorrent, but other tools like git when checking out lots of files (in the kernel git repository for example). -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: intensive IO on usb-storage device causing system lock
Hello guys. the problem is still reproducible with final 3.19 kernel - I can confirm it. Re-sending the last trace here - don't know if it's available in cxg.de. For those who might not have read the thread - the problem is: after some intensive IO to an USB (usb-storage) disk, for a more or less long time, depending on the quantity of IO you do, there start to be situations where some processes get stuck doing IO, in any case. Not IO to the USB disk, but IO also to other devices, like the one where the root partition resides, in my case a flash drive. I am using an EEE PC 701. I am sending the last trace I have: if you need more infos, then tell me. thank you. [10170.160485] SysRq : Show State [10170.160765] taskPC stack pid father [10170.160995] systemd S c0044000 0 1 0 0x [10170.161360] c0049eec 0086 c0049fec c0044000 c0044000 0246 c0049ef4 [10170.161956] c12bc120 dec31300 c0049ec8 c120a98d c12bc120 de2736c0 de1d5500 de21ab40 [10170.162572] c0049ed4 c10c8194 de1d550c c0049f0c c10c8352 62e136dd [10170.163181] Call Trace: [10170.163417] [c120a98d] ? sock_poll+0xd0/0xd9 [10170.163652] [c10c8194] ? ep_item_poll+0x15/0x1b [10170.163882] [c10c8352] ? ep_send_events_proc+0x8c/0x13c [10170.164130] [c12815ef] schedule+0x57/0x59 [10170.164357] [c1282ade] schedule_hrtimeout_range_clock+0x35/0xc2 [10170.164595] [c10c82c6] ? ep_pm_stay_awake+0x11/0x11 [10170.164829] [c10c8907] ? ep_scan_ready_list+0x128/0x150 [10170.165076] [c1282b75] schedule_hrtimeout_range+0xa/0xc [10170.165309] [c10c8e93] SYSC_epoll_wait+0x223/0x26f [10170.165546] [c1036dd5] ? wake_up_process+0x2c/0x2c [10170.165779] [c10c9604] SyS_epoll_wait+0x14/0x16 [10170.166023] [c128304c] sysenter_do_call+0x12/0x12 [10170.166253] kthreaddS c0044410 0 2 0 0x [10170.166580] c0051f8c 0046 c0051fec c0044410 c0044410 c1037361 0246 d1acc295 [10170.167189] c02e9c70 c0051f80 c10238cc 0dd9 d01e9880 00800711 [10170.167790] 0010 c0044410 d1acc295 c1033cce c084b160 d1acc295 c13de904 [10170.168401] Call Trace: [10170.168623] [c1037361] ? wake_up_new_task+0x53/0x6a [10170.168859] [c10238cc] ? do_fork+0x1a3/0x1cd [10170.169101] [c1033cce] ? init_completion+0x1e/0x1e [10170.169334] [c12815ef] schedule+0x57/0x59 [10170.169564] [c10342b2] kthreadd+0x60/0xbb [10170.169794] [c1282f80] ret_from_kernel_thread+0x20/0x30 [10170.170037] [c1034252] ? kthread_create_on_cpu+0x43/0x43 [10170.170269] ksoftirqd/0 S c0044820 0 3 2 0x [10170.170594] c0053f4c 0046 c0053fec c0044820 c0044820 c0053f0c c0053f0c 0246 [10170.171213] c0053f14 c11a2d9a 02053f0c 0256 c0053f20 0046 c144a7bc c0053f4c [10170.171811] c1025f25 0006 c0053fec 000a 04208040 1357d7a2 c0099460 [10170.172421] Call Trace: [10170.172653] [c11a2d9a] ? kbd_bh+0x41/0x78 [10170.172886] [c1025f25] ? __do_softirq+0x122/0x16f [10170.173131] [c12815ef] schedule+0x57/0x59 [10170.173361] [c1036044] smpboot_thread_fn+0xda/0x103 [10170.173593] [c1035f6a] ? SyS_setgroups+0x9d/0x9d [10170.173822] [c1033d65] kthread+0x97/0x9c [10170.174061] [c1282f80] ret_from_kernel_thread+0x20/0x30 [10170.174294] [c1033cce] ? init_completion+0x1e/0x1e [10170.174514] kworker/0:0HS c0045040 0 5 2 0x [10170.174837] c005bf40 0046 c005bfec c0045040 c0045040 de8568a0 d5e040d4 0003 [10170.175445] d5e7d800 c02d0730 c02d0730 c13de55c c02d07c4 c005bf18 c112e9fa c00267e0 [10170.176051] c005bf28 c1030f0c c00267e0 c13de55c c005bf48 c1031309 552dad3f c00267e0 [10170.176647] Call Trace: [10170.176878] [c112e9fa] ? __blk_run_queue_uncond+0x1d/0x26 [10170.177125] [c1030f0c] ? pwq_dec_nr_in_flight+0x54/0x68 [10170.177360] [c1031309] ? process_one_work+0x197/0x19f [10170.177596] [c12815ef] schedule+0x57/0x59 [10170.177826] [c10316e7] worker_thread+0x1c4/0x207 [10170.178068] [c1031523] ? rescuer_thread+0x1f1/0x1f1 [10170.178301] [c1033d65] kthread+0x97/0x9c [10170.178531] [c1282f80] ret_from_kernel_thread+0x20/0x30 [10170.178764] [c1033cce] ? init_completion+0x1e/0x1e [10170.178992] khelper S c0045860 0 7 2 0x [10170.179332] c0063f20 0046 c0063fec c0045860 c0045860 c0063edc c103a0b8 [10170.179932] c13df200 c0063ef0 c103b27e c13df1c0 c128e4a0 ffec c0063f08 c1036713 [10170.180540] c0045860 c0045860 0293 c0063f28 c1036866 ba37febc c00268a0 [10170.181147] Call Trace: [10170.181369] [c103a0b8] ? hrtick_update+0x12/0x35 [10170.181600] [c103b27e] ? enqueue_task_fair+0x69/0x6e [10170.192440] [c1036713] ? enqueue_task+0x23/0x29 [10170.192672] [c1036866] ? set_user_nice+0xbe/0xd7 [10170.192907] [c1031332] ? process_scheduled_works+0x21/0x21 [10170.193151] [c12815ef] schedule+0x57/0x59 [10170.193381] [c1031516] rescuer_thread+0x1e4/0x1f1 [10170.193614] [c1031332] ? process_scheduled_works+0x21/0x21
Re: intensive IO on usb-storage device causing system lock
Hello guys. Now that 3.19 is out there - I would like to know if I can domething more to help improve the situation regarding this bug - send some more info. I might eventually try to debug the problem differently but I will need some more spare time to do so. Thank you for all the help and attention, Enrico -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: intensive IO on usb-storage device causing system lock
Hello guys! I was lucky! :) I was able to reproduce the crash in less time. So - a big blob of infos about my system: complete dmesg, lspci, lsusb, kernel config and so on is at http://www.gstorm.eu/info The trace is: http://cxg.de/_59153c.htm I wasn't able to get other infos, the system wasn't able to read anything more from the internal flash memory; even the tty command wasn't returning. thank you for the help. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: intensive IO on usb-storage device causing system lock
Another note - I noticed the load average doesn't go down 2.02; and top doesn't evidence any particularly CPU-hungry or memory-hungry process. However, dmesg and mpd processes are still stuck, the rest of the system runs normally apparently. The USB disk spinned down, like thhere is no process accessing it - at the moment ony mpd was accessing it, rtorrent and screen where terminated before it was too late, strangely I got the chance to do so. It's very interesting guys. Enrico On Tue, 3 Feb 2015, Alan Stern wrote: Date: Tue, 3 Feb 2015 19:02:48 From: Alan Stern st...@rowland.harvard.edu To: Enrico Mioso mrkiko...@gmail.com Cc: linux-usb@vger.kernel.org Subject: Re: intensive IO on usb-storage device causing system lock On Tue, 3 Feb 2015, Enrico Mioso wrote: Hi guys. I finally was able to obtain some informations about what was going on - infos I retained useful. I am re-sending these, since it seems my previous message didn't get to the list - but might be I am wrong and didn't find it. This time I posted all the traces to a pstebin, so that it's easier to read the message and might be there are less problems with it in general. 1 - First trace: there where no problems http://cxg.de/_298ad9.htm 2 - Trace immediately before the crash http://cxg.de/_c43356.htm Without CONFIG_FRAME_POINTER, the stack traces are not very helpful. 3 - lspci: http://cxg.de/_4f202a.htm 4 - lsusb: http://cxg.de/_223f6c.htm Any help / hint would be very apreciated. You have two USB mass storage devices. Do you know which one is connected to the problem? You can try using usbmon to see what's going on at the USB level. See Documentation/usb/usbmon.txt for instructions. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: intensive IO on usb-storage device causing system lock
The situation is unchanged, but I noticed there is a continous process of creating workers. They might die at some point, but I noticed them now. Sorry for the verbosity. Here's the last trace: http://cxg.de/_dedb43.htm And process list: PID TTY STAT TIME COMMAND 1 ?Ss 0:01 /sbin/init auto 2 ?S 0:00 [kthreadd] 3 ?S 0:16 [ksoftirqd/0] 5 ?S 0:00 [kworker/0:0H] 7 ?S 0:00 [khelper] 8 ?S 0:00 [kdevtmpfs] 9 ?S 0:00 [perf] 107 ?S 0:00 [writeback] 110 ?S 0:00 [crypto] 111 ?S 0:00 [bioset] 113 ?S 0:00 [kblockd] 160 ?S 0:00 [ata_sff] 162 ?S 0:26 [kswapd0] 163 ?S 0:00 [fsnotify_mark] 167 ?S 0:00 [kthrotld] 420 ?S 0:10 [kworker/u2:2] 421 ?S 0:00 [scsi_eh_0] 438 ?S 0:00 [scsi_tmf_0] 441 ?S 0:00 [scsi_eh_1] 442 ?S 0:00 [scsi_tmf_1] 468 ?S 0:00 [deferwq] 482 ?S 0:00 [ext4-rsv-conver] 499 ?S 0:00 [ipv6_addrconf] 536 ?Ss 0:06 /usr/lib/systemd/systemd-journald 913 ?Ss 0:00 /usr/lib/systemd/systemd-udevd 933 ?S 0:00 [kpsmoused] 961 ?Ss 0:01 /usr/lib/systemd/systemd-logind 967 ?Ss 0:00 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation 970 ?S 0:00 [acpi_thermal_pm] 1016 ?S 0:00 [cfg80211] 1036 ?S 0:00 [hd-audio0] 1037 ?Ss 0:00 /usr/bin/sshd -D 1074 ?S 0:01 [kworker/u3:0] 1075 ?S 0:00 [hci0] 1076 ?S 0:00 [hci0] 1077 ?S 0:01 [kworker/u3:1] 1116 ?S 0:00 [scsi_eh_2] 1121 ?S 0:00 [scsi_tmf_2] 1122 ?S 0:00 [usb-storage] 1171 ?S 0:00 [kworker/0:1H] 1220 ?Ss 0:00 /usr/lib/bluetooth/bluetoothd 1235 ?Rsl1:25 brltty -b al -d bluetooth:00:A0:96:31:E5:1E 1244 ?S 0:00 [krfcommd] 1276 ?S 0:00 [scsi_eh_3] 1278 ?S 0:00 [scsi_tmf_3] 1279 ?S 0:20 [usb-storage] 1300 ?Ss 0:00 login -- mrkiko 1302 ?Ss 0:00 login -- mrkiko 1304 ?Ss 0:00 login -- mrkiko 1312 ?Ss 0:00 login -- mrkiko 1314 ?Ss 0:00 login -- mrkiko 1316 ?Ss 0:00 login -- mrkiko 1318 ?Ss 0:00 login -- mrkiko 1319 ?Ss 0:00 login -- mrkiko 1326 ?Ss 0:00 login -- mrkiko 1332 ?Ss 0:00 login -- mrkiko 1334 ?Ss 0:00 login -- mrkiko 1337 tty2 Ss 0:00 -bash 1351 ?Ssl0:00 /usr/lib/polkit-1/polkitd --no-debug 1407 ?Ss 0:00 /usr/bin/dhcpcd -q -w enp3s0 1410 tty3 Ss+0:00 -bash 1417 tty4 Ss+0:00 -bash 1424 tty5 Ss+0:00 -bash 1431 tty6 Ss+0:00 -bash 1438 tty7 Ss+0:00 -bash 1445 tty8 Ss+0:00 -bash 1452 tty9 Ss+0:00 -bash 1459 tty10Ss+0:00 -bash 1465 tty11Ss+0:00 -bash 1473 tty12Ss 0:00 -bash 1494 tty12S+ 0:07 finch 1536 ?S 0:00 [ext4-rsv-conver] 1804 ?Dsl2:12 mpd .mpdconf 3112 ?S 0:00 [ext4-rsv-conver] 3161 ?S 0:00 [kworker/u2:1] 3166 tty2 S 0:00 sudo su root 3167 tty2 S 0:00 su root 3168 tty2 S 0:00 bash 3178 tty2 D+ 0:00 dmesg 3183 ?Ss 0:00 login -- mrkiko 3205 ?S 0:00 [kworker/0:0] 3240 tty1 Ss 0:00 -bash 3535 ?S 0:00 [kworker/0:1] 3545 ?S 0:00 [kworker/0:2] 3561 tty1 S+ 0:00 alpine -i 3565 tty1 S+ 0:00 nano /tmp/pico.05873 3566 tty1 R+ 0:00 ps ax Where kworkers with PID 3535 and 3545 looked interesting to me. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: intensive IO on usb-storage device causing system lock
Hello guys. This time I am managing to use the system while in the middle of the problem. From the command: ps aux USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.5 22852 2600 ?Ss 09:24 0:01 /sbin/init auto root 2 0.0 0.0 0 0 ?S09:24 0:00 [kthreadd] root 3 0.2 0.0 0 0 ?S09:24 0:15 [ksoftirqd/0] root 5 0.0 0.0 0 0 ?S 09:24 0:00 [kworker/0:0H] root 7 0.0 0.0 0 0 ?S 09:24 0:00 [khelper] root 8 0.0 0.0 0 0 ?S09:24 0:00 [kdevtmpfs] root 9 0.0 0.0 0 0 ?S 09:24 0:00 [perf] root 107 0.0 0.0 0 0 ?S 09:24 0:00 [writeback] root 110 0.0 0.0 0 0 ?S 09:24 0:00 [crypto] root 111 0.0 0.0 0 0 ?S 09:24 0:00 [bioset] root 113 0.0 0.0 0 0 ?S 09:24 0:00 [kblockd] root 160 0.0 0.0 0 0 ?S 09:24 0:00 [ata_sff] root 162 0.3 0.0 0 0 ?S09:24 0:26 [kswapd0] root 163 0.0 0.0 0 0 ?S09:24 0:00 [fsnotify_mark] root 167 0.0 0.0 0 0 ?S 09:24 0:00 [kthrotld] root 420 0.1 0.0 0 0 ?S09:24 0:10 [kworker/u2:2] root 421 0.0 0.0 0 0 ?S09:24 0:00 [scsi_eh_0] root 438 0.0 0.0 0 0 ?S 09:24 0:00 [scsi_tmf_0] root 441 0.0 0.0 0 0 ?S09:24 0:00 [scsi_eh_1] root 442 0.0 0.0 0 0 ?S 09:24 0:00 [scsi_tmf_1] root 468 0.0 0.0 0 0 ?S 09:24 0:00 [deferwq] root 482 0.0 0.0 0 0 ?S 09:24 0:00 [ext4-rsv-conver] root 499 0.0 0.0 0 0 ?S 09:24 0:00 [ipv6_addrconf] root 536 0.0 0.4 7924 2164 ?Ss 09:24 0:03 /usr/lib/systemd/systemd-journald root 913 0.0 0.2 11120 1068 ?Ss 09:24 0:00 /usr/lib/systemd/systemd-udevd root 933 0.0 0.0 0 0 ?S 09:24 0:00 [kpsmoused] root 961 0.0 0.2 3140 1380 ?Ss 09:24 0:01 /usr/lib/systemd/systemd-logind dbus 967 0.0 0.2 4656 1472 ?Ss 09:24 0:00 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation root 970 0.0 0.0 0 0 ?S 09:24 0:00 [acpi_thermal_pm] root 1016 0.0 0.0 0 0 ?S 09:24 0:00 [cfg80211] root 1036 0.0 0.0 0 0 ?S 09:24 0:00 [hd-audio0] root 1037 0.0 0.2 7276 1176 ?Ss 09:24 0:00 /usr/bin/sshd -D root 1074 0.0 0.0 0 0 ?S 09:24 0:00 [kworker/u3:0] root 1075 0.0 0.0 0 0 ?S 09:24 0:00 [hci0] root 1076 0.0 0.0 0 0 ?S 09:24 0:00 [hci0] root 1077 0.0 0.0 0 0 ?S 09:24 0:00 [kworker/u3:1] root 1116 0.0 0.0 0 0 ?S09:24 0:00 [scsi_eh_2] root 1121 0.0 0.0 0 0 ?S 09:24 0:00 [scsi_tmf_2] root 1122 0.0 0.0 0 0 ?S09:24 0:00 [usb-storage] root 1171 0.0 0.0 0 0 ?S 09:24 0:00 [kworker/0:1H] root 1220 0.0 0.2 5532 1164 ?Ss 09:25 0:00 /usr/lib/bluetooth/bluetoothd root 1235 0.6 0.4 43472 2200 ?Ssl 09:25 0:50 brltty -b al -d bluetooth:00:A0:96:31:E5:1E root 1244 0.0 0.0 0 0 ?S 09:25 0:00 [krfcommd] root 1276 0.0 0.0 0 0 ?S09:25 0:00 [scsi_eh_3] root 1278 0.0 0.0 0 0 ?S 09:25 0:00 [scsi_tmf_3] root 1279 0.2 0.0 0 0 ?S09:25 0:20 [usb-storage] root 1300 0.0 0.2 5420 1140 ?Ss 09:26 0:00 login -- mrkiko root 1302 0.0 0.2 5420 1144 ?Ss 09:26 0:00 login -- mrkiko root 1304 0.0 0.2 5420 1140 ?Ss 09:26 0:00 login -- mrkiko root 1312 0.0 0.2 5420 1144 ?Ss 09:26 0:00 login -- mrkiko root 1314 0.0 0.2 5420 1144 ?Ss 09:26 0:00 login -- mrkiko root 1316 0.0 0.2 5420 1140 ?Ss 09:26 0:00 login -- mrkiko root 1318 0.0 0.2 5420 1140 ?Ss 09:26 0:00 login -- mrkiko root 1319 0.0 0.2 5420 1144 ?Ss 09:26 0:00 login -- mrkiko root 1326 0.0 0.2 5420 1144 ?Ss 09:26 0:00 login -- mrkiko root 1332 0.0 0.2 5420 1140 ?Ss 09:26 0:00 login -- mrkiko root 1334 0.0 0.2 5420 1140 ?Ss 09:26 0:00 login -- mrkiko mrkiko1337 0.0 0.3 5520 1976 tty2 Ss 09:26 0:00 -bash polkitd 1351 0.0 1.0 71816 5432 ?Ssl 09:26 0:00 /usr/lib/polkit-1/polkitd --no-debug root
Re: intensive IO on usb-storage device causing system lock
Sorry guys - I was wrong: the process appears in the traces. And if I read the call trace correctly is's stuck in apic_write ? Enrico On Tue, 3 Feb 2015, Alan Stern wrote: Date: Tue, 3 Feb 2015 19:02:48 From: Alan Stern st...@rowland.harvard.edu To: Enrico Mioso mrkiko...@gmail.com Cc: linux-usb@vger.kernel.org Subject: Re: intensive IO on usb-storage device causing system lock On Tue, 3 Feb 2015, Enrico Mioso wrote: Hi guys. I finally was able to obtain some informations about what was going on - infos I retained useful. I am re-sending these, since it seems my previous message didn't get to the list - but might be I am wrong and didn't find it. This time I posted all the traces to a pstebin, so that it's easier to read the message and might be there are less problems with it in general. 1 - First trace: there where no problems http://cxg.de/_298ad9.htm 2 - Trace immediately before the crash http://cxg.de/_c43356.htm Without CONFIG_FRAME_POINTER, the stack traces are not very helpful. 3 - lspci: http://cxg.de/_4f202a.htm 4 - lsusb: http://cxg.de/_223f6c.htm Any help / hint would be very apreciated. You have two USB mass storage devices. Do you know which one is connected to the problem? You can try using usbmon to see what's going on at the USB level. See Documentation/usb/usbmon.txt for instructions. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: intensive IO on usb-storage device causing system lock
Hello to everybody reading this list, Hello alan. First of all - thank you for your help, attention and time in helping me troubleshoot this problem. I am 99% certain the device generating the problem is Bus 001 Device 010: ID 1e68:0022 TrekStor GmbH Co. KG I don't think the problem is on the hardware behaviour. I am recompiling the kernel now with some more debugging hints - sorry I didn't do this before. To trigger the problem it takes LOTS of IO, so I will be back in some days unfortunately. Thank you for the usbmon hint - I think I'll try this if we can't understand what's happening from the tracing data. I say this because I think that usbmon will generate LOT of data - literally GB of it, and itwould become problematic to handle / share it the right way. thank you very much again, enrico -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: intensive IO on usb-storage device causing system lock
On Tue, 3 Feb 2015, Enrico Mioso wrote: Hi guys. I finally was able to obtain some informations about what was going on - infos I retained useful. I am re-sending these, since it seems my previous message didn't get to the list - but might be I am wrong and didn't find it. This time I posted all the traces to a pstebin, so that it's easier to read the message and might be there are less problems with it in general. 1 - First trace: there where no problems http://cxg.de/_298ad9.htm 2 - Trace immediately before the crash http://cxg.de/_c43356.htm Without CONFIG_FRAME_POINTER, the stack traces are not very helpful. 3 - lspci: http://cxg.de/_4f202a.htm 4 - lsusb: http://cxg.de/_223f6c.htm Any help / hint would be very apreciated. You have two USB mass storage devices. Do you know which one is connected to the problem? You can try using usbmon to see what's going on at the USB level. See Documentation/usb/usbmon.txt for instructions. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: intensive IO on usb-storage device causing system lock
Hi guys. I finally was able to obtain some informations about what was going on - infos I retained useful. I am re-sending these, since it seems my previous message didn't get to the list - but might be I am wrong and didn't find it. This time I posted all the traces to a pstebin, so that it's easier to read the message and might be there are less problems with it in general. 1 - First trace: there where no problems http://cxg.de/_298ad9.htm 2 - Trace immediately before the crash http://cxg.de/_c43356.htm 3 - lspci: http://cxg.de/_4f202a.htm 4 - lsusb: http://cxg.de/_223f6c.htm Any help / hint would be very apreciated. I am not subscribed to the list, so please keep me in CC. Thank you, Enrico -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: intensive IO on usb-storage device causing system lock
Hello guys. I should say that, wafter sending the command to SysRQ, the only output I can get is: SYSrq - shot state nothing more. There is no way to recover from this situation - no matter what I do. Sorry. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: intensive IO on usb-storage device causing system lock
Fine. Now the system is on-track. I can add another piece of info I collected. When removing (modprobe -r) usb-storage from memory, as long as uas, I can trigger an oops, but only if the IO not going on thing manifests. So the two things seems related at this point. Enrico On Sat, 31 Jan 2015, Oliver Neukum wrote: Date: Sat, 31 Jan 2015 13:20:48 From: Oliver Neukum oneu...@suse.de To: Enrico Mioso mrkiko...@gmail.com Cc: linux-usb@vger.kernel.org Subject: Re: intensive IO on usb-storage device causing system lock On Sat, 2015-01-31 at 12:10 +0100, Enrico Mioso wrote: Hi Oliver! Thank you for the reply and the attention overall. What do you mean for do it manually? Pressing Alt-Sysrq-T Yeah - I will try do do it via the sysrq key - I can't use the keyboard to trigger that actually (it's an Apple keyboard; yes I know there's a trick with it also). I'll wait until the next time it happens. Thank you. We can do little without a trace. Regards Oliver -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: intensive IO on usb-storage device causing system lock
Hi guys. The good news is that the problem is perfectly reproducible with some time - and some IO of course. A torrent file of somewhat 14 GB can trigger the issue; with files having a size of some MB each one. The bad news is that it triggers too aggressively - and therefore I wasn't able to get something out of the system. The times before it was sufficient to kill most processes to get the system somewhat funcitonal, but this time even reading the killall binary was a problem. And yes, killall was on the fs root that was on flash disk. The IO scheduler is noop. Let's see. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: intensive IO on usb-storage device causing system lock
Hi Oliver! Thank you for the reply and the attention overall. What do you mean for do it manually? Yeah - I will try do do it via the sysrq key - I can't use the keyboard to trigger that actually (it's an Apple keyboard; yes I know there's a trick with it also). I'll wait until the next time it happens. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: intensive IO on usb-storage device causing system lock
On Sat, 2015-01-31 at 08:57 +0100, Enrico Mioso wrote: This happens especially when I use rtorrent on the device. It can happen after rtorrent hashed downloaded files. Symptoms: - [kthreadd] (PID 2 here) stays persistently in disk-sleep state (D) - processes doing IO (such as mpd, Music Player Daemon) can still continue doing so with no particular problems - no further IO can be done, seeminglsy also on other devices Please get a sysrq trace echo t /proc/sysrq-trigger or do it manually the next time this happens. Regards Oliver -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: intensive IO on usb-storage device causing system lock
On Sat, 2015-01-31 at 12:10 +0100, Enrico Mioso wrote: Hi Oliver! Thank you for the reply and the attention overall. What do you mean for do it manually? Pressing Alt-Sysrq-T Yeah - I will try do do it via the sysrq key - I can't use the keyboard to trigger that actually (it's an Apple keyboard; yes I know there's a trick with it also). I'll wait until the next time it happens. Thank you. We can do little without a trace. Regards Oliver -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
