You are not logged in.
This problem persists since at least 2.6.26.
I tried each and every scheduler for the CPU and for the IO-scheduler. I tried the zen patchset, I tried the liqurix patchset, I tried vanilla kernel, I tried almost every kernel there is on the AUR and the problem still persists.
Whenever I copy something "big" to an external vfat formated USB device, my browser and system slows down and eventually reaches a point where it freezes (I can move the mouse, and type in the "Run command window" of KDE just fine, but the programs like the browsers (both chromium and firefox) are frozen.
After a few dozen seconds I can use the browser normally for a short time before it freezes again for a few seconds. This continues until a few dozen seconds to minutes after the file copy process has finished (but some data has first to be synced to the filesystem). After I run sync, the system works normally again.
I would also like to point out that my "backup" to an external USB-HDD, formated with JFS does not cause as much problems as to a vfat USB-"Stick" / Android-Phone, although there's also some "microfreezes" in the magnitude 0.5 to 4 seconds every few seconds.
This is becoming really annoying and I offer a bounty of 0.5 BTC for the person who can provide a fix.
Last edited by akurei (2011-09-07 17:15:13)
Offline
This problem persists since at least 2.6.26.
I tried each and every scheduler for the CPU and for the IO-scheduler. I tried the zen patchset, I tried the liqurix patchset, I tried vanilla kernel, I tried almost every kernel there is on the AUR and the problem still persists.
Whenever I copy something "big" to an external vfat formated USB device, my browser and system slows down and eventually reaches a point where it freezes (I can move the mouse, and type in the "Run command window" of KDE just fine, but the programs like the browsers (both chromium and firefox) are frozen.
After a few dozen seconds I can use the browser normally for a short time before it freezes again for a few seconds. This continues until a few dozen seconds to minutes after the file copy process has finished (but some data has first to be synced to the filesystem). After I run sync, the system works normally again.I would also like to point out that my "backup" to an external USB-HDD, formated with JFS does not cause as much problems as to a vfat USB-"Stick" / Android-Phone, although there's also some "microfreezes" in the magnitude 0.5 to 4 seconds every few seconds.
This is becoming really annoying and I offer a bounty of 0.5 BTC for the person who can provide a fix.
Exactlly my problem... Tried all the spolutions, not helped. I have found that ntfs on usb hdd or stick is faster than ext2... But still have the same problem with freezing etc. especially web browsers are slow,and the whole system starts freezing...
Offline
I noticed the Terminals CTRL+ALT+F1 to F6 don't suffer from this problem. Only X.
Offline
I tried using linux-vanilla (from AUR) today. It did not work. Just for the record.
Offline
All I can say is that I suffer from this problem too! And it's highly annoying
Offline
Clouseau reports he has solved with ext4 on another thread....
Prediction...This year will be a very odd year!
Hard work does not kill people but why risk it: Charlie Mccarthy
A man is not complete until he is married..then..he is finished.
When ALL is lost, what can be found? Even bytes get lonely for a little bit! X-ray confirms Iam spineless!
Offline
Clouseau reports he has solved with ext4 on another thread....
Offline
As the linux-hacker-in-chief at my company is wont to say: that's a work-around, not a solution.
But whether the Constitution really be one thing, or another, this much is certain - that it has either authorized such a government as we have had, or has been powerless to prevent it. In either case, it is unfit to exist.
-Lysander Spooner
Offline
After trying almost all available kernels and checking everything twice, I finally found a solution that worked wonders for me:
Run as root:
echo 1 > /proc/sys/vm/dirty_ratio && echo "echo 1 > /proc/sys/vm/dirty_ratio" >> /etc/rc.local
Offline
Am i right in thinking this would cause all pages to be forcibly flushed to disk almost immediatley?
I found this:
(vm.dirty_ratio) defines the percentage of memory which can be occupied by dirty pages before a forced flush starts. If the percentage of dirty pages reaches this number, then all processes become synchronous, they are not allowed to continue until the io operation they have requested is actually performed and the data is on disk. In case of high performance I/O machines, this causes a problem as the data caching is cut away and all of the processes doing I/O (the important ones in dCache pool) become blocked to wait for io. This will cause a big number of hanging processes, which leads to high load, which leads to unstable system and crappy performance.
at http://hep.kbfi.ee/index.php/IT/KernelTuning
the kernel versions mentioned also sound about right.
anyone else up for testing some values?
Offline
Changing the dirty_ratio had no effect on my system. However, this problem does not happen at all when using the LTS kernel.
Offline
Hi! For me this seems to have solved the issue: use mount option “flush” in FAT flash drives (http://kernelnewbies.org/Linux_2_6_19#h … 9499d0912e).
Offline
Hey guys,
there are plenty of similar thread regarding the "system hangs" problematic so i will post here, hopefully thats ok.
I read all the threads not only here in the archlinux forum, tried probably everything from changing the kernel, the scheduler, dirty_ratio etc. Nothing from the above seems to work to my satisfaction, there were still huge lags.
This lag (sometimes several minutes) occurred in two scenarios:
1. Copy files to a usb hard disk (no matter which file system).
2. Using a download manager that writes to that disk, using multiple connections. That means there are several parallel write action to the disk.
Adding this values to my /ets/sysctl.conf and using the linux-ck kernel seems to make a small difference:
vm.vfs_cache_pressure=50
vm.dirty_ratio = 1
Anyway, the big lag is still there.
Finally i found a solution i tested the last two weeks and the lag seems to be gone.
I stumbled over this by accident while upgrading my motherboard bios.
I disabled the usb legacy support in bios and that did it for me.
I'm happy that i finally found this solution, i had this problem for years now.
Hope this is helpful to somebody.
cya
Offline
I disabled the usb legacy support in bios and that did it for me.
I registered just to say thank you! For the last two years every time I copied stuff to my usb flash drive my system would hang. Following your advice, all I did was turn off legacy usb support (I didn't add anything to /etc/sysctl.conf or use a different kernel) and the same transfer now takes less than 30 seconds instead of a couple of minutes and I can actually use my computer during the transfer since it doesn't freeze up. The only small downside is that now my usb keyboard doesn't work in grub so I have to leave a ps2 keyboard plugged in since I dual boot.
Offline
Unfortunately, disabling USB legacy support is not an option for many
Offline
@joat
You are welcome, i was happy by byself, so i had to share it.
I have also a usb keyboard but normally i don't need it during boot.
@kalpik
I think you are right but at least it helps some people.
Offline
Well, this problem persists in kernel 3.2 rc1.
I copied some music to a Samsung Galaxy Nexus S:
[102340.263157] INFO: task kwin:31160 blocked for more than 120 seconds.
[102340.263162] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[102340.263167] kwin D 0000000101d39c98 0 31160 29191 0x00000000
[102340.263174] ffff880006001e68 0000000000000082 ffff880000000000 ffffffffa00b6562
[102340.263182] ffff88022be78730 ffff880006001fd8 ffff880006001fd8 ffff880006001fd8
[102340.263188] ffff88022e0cf300 ffff88022be78730 ffff880006001ea8 ffffffffa0014533
[102340.263198] Call Trace:
[102340.263253] [<ffffffffa00b6562>] ? radeon_gem_busy_ioctl+0x92/0xd0 [radeon]
[102340.263266] [<ffffffffa0014533>] ? drm_ioctl+0x4e3/0x510 [drm]
[102340.263272] [<ffffffff8116efd3>] ? putname+0x33/0x50
[102340.263281] [<ffffffff81416e1f>] schedule+0x3f/0x60
[102340.263285] [<ffffffff814193d5>] rwsem_down_failed_common+0xc5/0x160
[102340.263290] [<ffffffff81419483>] rwsem_down_write_failed+0x13/0x20
[102340.263296] [<ffffffff8123e083>] call_rwsem_down_write_failed+0x13/0x20
[102340.263300] [<ffffffff81418aa5>] ? down_write+0x25/0x27
[102340.263305] [<ffffffff8112ef05>] sys_munmap+0x45/0x80
[102340.263310] [<ffffffff8141a602>] system_call_fastpath+0x16/0x1b
[102459.958019] INFO: task kwin:31160 blocked for more than 120 seconds.
[102459.959273] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[102459.960497] kwin D 0000000101d39c98 0 31160 29191 0x00000000
[102459.960505] ffff880006001e68 0000000000000082 ffff880000000000 ffffffffa00b6562
[102459.960513] ffff88022be78730 ffff880006001fd8 ffff880006001fd8 ffff880006001fd8
[102459.960519] ffff88022e0cf300 ffff88022be78730 ffff880006001ea8 ffffffffa0014533
[102459.960525] Call Trace:
[102459.960572] [<ffffffffa00b6562>] ? radeon_gem_busy_ioctl+0x92/0xd0 [radeon]
[102459.960587] [<ffffffffa0014533>] ? drm_ioctl+0x4e3/0x510 [drm]
[102459.960595] [<ffffffff8116efd3>] ? putname+0x33/0x50
[102459.960605] [<ffffffff81416e1f>] schedule+0x3f/0x60
[102459.960611] [<ffffffff814193d5>] rwsem_down_failed_common+0xc5/0x160
[102459.960616] [<ffffffff81419483>] rwsem_down_write_failed+0x13/0x20
[102459.960623] [<ffffffff8123e083>] call_rwsem_down_write_failed+0x13/0x20
[102459.960628] [<ffffffff81418aa5>] ? down_write+0x25/0x27
[102459.960634] [<ffffffff8112ef05>] sys_munmap+0x45/0x80
[102459.960640] [<ffffffff8141a602>] system_call_fastpath+0x16/0x1b
[102579.652777] INFO: task kwin:31160 blocked for more than 120 seconds.
[102579.652782] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[102579.652786] kwin D 0000000101d39c98 0 31160 29191 0x00000000
[102579.652792] ffff880006001e68 0000000000000082 ffff880000000000 ffffffffa00b6562
[102579.652798] ffff88022be78730 ffff880006001fd8 ffff880006001fd8 ffff880006001fd8
[102579.652804] ffff88022e0cf300 ffff88022be78730 ffff880006001ea8 ffffffffa0014533
[102579.652809] Call Trace:
[102579.652903] [<ffffffffa00b6562>] ? radeon_gem_busy_ioctl+0x92/0xd0 [radeon]
[102579.652915] [<ffffffffa0014533>] ? drm_ioctl+0x4e3/0x510 [drm]
[102579.652923] [<ffffffff8116efd3>] ? putname+0x33/0x50
[102579.652933] [<ffffffff81416e1f>] schedule+0x3f/0x60
[102579.652938] [<ffffffff814193d5>] rwsem_down_failed_common+0xc5/0x160
[102579.652943] [<ffffffff81419483>] rwsem_down_write_failed+0x13/0x20
[102579.652948] [<ffffffff8123e083>] call_rwsem_down_write_failed+0x13/0x20
[102579.652953] [<ffffffff81418aa5>] ? down_write+0x25/0x27
[102579.652957] [<ffffffff8112ef05>] sys_munmap+0x45/0x80
[102579.652962] [<ffffffff8141a602>] system_call_fastpath+0x16/0x1b
[102699.347658] INFO: task kwin:31160 blocked for more than 120 seconds.
[102699.348719] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[102699.349831] kwin D 0000000101d39c98 0 31160 29191 0x00000000
[102699.349838] ffff880006001e68 0000000000000082 ffff880000000000 ffffffffa00b6562
[102699.349846] ffff88022be78730 ffff880006001fd8 ffff880006001fd8 ffff880006001fd8
[102699.349852] ffff88022e0cf300 ffff88022be78730 ffff880006001ea8 ffffffffa0014533
[102699.349858] Call Trace:
[102699.349907] [<ffffffffa00b6562>] ? radeon_gem_busy_ioctl+0x92/0xd0 [radeon]
[102699.349922] [<ffffffffa0014533>] ? drm_ioctl+0x4e3/0x510 [drm]
[102699.349929] [<ffffffff8116efd3>] ? putname+0x33/0x50
[102699.349939] [<ffffffff81416e1f>] schedule+0x3f/0x60
[102699.349945] [<ffffffff814193d5>] rwsem_down_failed_common+0xc5/0x160
[102699.349951] [<ffffffff81419483>] rwsem_down_write_failed+0x13/0x20
[102699.349958] [<ffffffff8123e083>] call_rwsem_down_write_failed+0x13/0x20
[102699.349964] [<ffffffff81418aa5>] ? down_write+0x25/0x27
[102699.349969] [<ffffffff8112ef05>] sys_munmap+0x45/0x80
[102699.349975] [<ffffffff8141a602>] system_call_fastpath+0x16/0x1b
Wenn your windowmanager has to wait for I/O for more than two minutes something is wrong.
Is maybe the radeon driver involved? ("radeon_gem_busy_ioctl"). Do the others with this problem also run open source drivers?
I will look whether I can disable usb legacy support on my laptop...
฿ 18PRsqbZCrwPUrVnJe1BZvza7bwSDbpxZz
Offline
@Cdh
I never had this problem on my system before but i use nvidia, so maybe its the radeon driver.
Offline
I have nvidia, and I definitely have this problem.
zʇıɹɟʇıɹʞsuɐs AUR || Cycling in Budapest with a helmet camera || Revised log levels proposal: "FYI" "WTF" and "OMG" (John Barnette)
Offline
@SanskritFritz
The lag in general or the crashing kwin?
Offline
kwin was not crashing. It was only blocked so it couldn't update the screen anymore. So everything in X except the mouse pointer itself was unresponsive. On the console outside of X the system was mostly fine.
฿ 18PRsqbZCrwPUrVnJe1BZvza7bwSDbpxZz
Offline
Hi! I experience the same problem (or quite the same!). When I copy files to a USB key, the system lags a little, but I have a big problem with chromium. Waiting for the copy to finish, I launch chromium (sometimes it is already launched), but it freezes. The copy continues and get finished, but I can't use chromium. Besides, the copy are in general quite slow.
Concerning my WM/things like that, I use Openbox and Lxpanel.
Offline
@SanskritFritz
The lag in general or the crashing kwin?
The lag. I'm using Openbox. The system hangs practically when I copy large files to an usb stick.
When done copying, everything gets back to normal. Crazy.
zʇıɹɟʇıɹʞsuɐs AUR || Cycling in Budapest with a helmet camera || Revised log levels proposal: "FYI" "WTF" and "OMG" (John Barnette)
Offline
sxe wrote:@SanskritFritz
The lag in general or the crashing kwin?The lag. I'm using Openbox. The system hangs practically when I copy large files to an usb stick.
When done copying, everything gets back to normal. Crazy.
Is it just the USB? What happens if you copy from one partition to another or e.g. run updatedb - no lag?
Offline
SanskritFritz wrote:sxe wrote:@SanskritFritz
The lag in general or the crashing kwin?The lag. I'm using Openbox. The system hangs practically when I copy large files to an usb stick.
When done copying, everything gets back to normal. Crazy.Is it just the USB? What happens if you copy from one partition to another or e.g. run updatedb - no lag?
There is some lag, but the system responsiveness is far better than when copying to an usb stick.
zʇıɹɟʇıɹʞsuɐs AUR || Cycling in Budapest with a helmet camera || Revised log levels proposal: "FYI" "WTF" and "OMG" (John Barnette)
Offline