[arch-general] Failure to resume on kernel 3.9.9
Hi list, I realise this email comes with a deplorable paucity of informaton, but I haven't found *any* logs relating to this event. I also realise I've waited what may be considered overlong to ask for help, but I was hoping the bug would be fixed in a later kernel release and it wasn't. Google has failed me, so now I come to you for help. My laptop is an HP Pavilion g7. The system suspends normally, but fails to resume leaving a powered-off screen and no responsiveness to keyboard input, including the magic sysrq, but the caps lock light turns on and off. At first I suspected fglrx, but it happens with or without fglrx loaded, and with or without nomodeset on the kernel command line. Further, it happens identically inside or outside of X. I tried git-bisect on the kernel but gave up after many hours of compiling and testing — anyone know of a faster/easier way to do this? I'm currently running kernel 3.9.8, but am perfectly willing to update again and generate a failure to provide any logs someone thinks may help — I haven't found anything, but I may not be looking in the right place. Thank you, ~Celti
Re: [arch-general] Patch for update-mime-info slowness
On Wed, Dec 4, 2013 at 9:00 PM, Sébastien Leblanc leblancse...@gmail.comwrote: I am kind of annoyed by the time it takes to update the MIME database (something like two minutes on a recent i7 quad-core laptop). Until pacman has hooks/triggers, I have removed the calls to fdatasync (which are supposed to ensure that the files are truly written to disk). I prefer letting the system take care of it anyway, and I don't care much for consistency in desktop links and file associations. I hadn't noticed, but now I'm annoyed too :-( Y'know, it might bear the name database, but it's not a database in the sense of a +1M row postgresql database). Anyone have an opinion on this? Am I a complete idiot in removing these calls to fdatasync? Yeah, I think that this is kind of useless. If the files got corrupted, you can rebuild them running the command again. Maybe I'm losing something there, but it looks like the ext4-ate-my-data syndrome. With this patch, updating takes around 5 seconds, haven't run it with a stopwatch yet. Instead of a patch I've installed the libeatmydata package from the AUR and added a file /usr/local/bin/update-mime-database that calls `exec eatmydata update-mime-database $@`. Before: 21.618 s. After: 0.275 s. A x100 improvement, that's something! -- Rodrigo
Re: [arch-general] Fwd: Notebook freeze and slow when copy big files to external usb
Maykel Franco maykeldeb...@gmail.com writes: Hi, I when I make a copy of a large file to a 2GB or 8GB usb 3.0 external hard drive, I notice that arch remains slow, frozen ... He struggles to open windows are minimized. I have the kernel: 3.12.2-1-ARCH Update the whole system to the last. Can you think because it can be? I also went from the 3.11 kernel However, debian, ubuntu, opensuse me not pass this ... It's happened to someone else? Thanks for everything. BTW what is the filesystem? I experienced similar problems on an internal disk, of which the filesystem is NTFS. NTFS-3g seems to consume too much CPU in the case of very large writes, and that caused me a hang. -- Carl Lei (XeCycle) Department of Physics and Astronomy, SJTU OpenPGP public key: 7795E591 pgpUAbZ1bCepu.pgp Description: PGP signature
Re: [arch-general] Fwd: Notebook freeze and slow when copy big files to external usb
Try: https://wiki.archlinux.org/index.php/USB_Storage_Devices#Poor_copy_performance_to_USB_pendrive Other possibility is a different kernel scheduler, more aware of disk load and desktop responsiveness, like linux-ckhttps://wiki.archlinux.org/index.php/linux-ck . On Thu, Dec 5, 2013 at 8:01 AM, XeCycle xecy...@gmail.com wrote: Maykel Franco maykeldeb...@gmail.com writes: Hi, I when I make a copy of a large file to a 2GB or 8GB usb 3.0 external hard drive, I notice that arch remains slow, frozen ... He struggles to open windows are minimized. I have the kernel: 3.12.2-1-ARCH Update the whole system to the last. Can you think because it can be? I also went from the 3.11 kernel However, debian, ubuntu, opensuse me not pass this ... It's happened to someone else? Thanks for everything. BTW what is the filesystem? I experienced similar problems on an internal disk, of which the filesystem is NTFS. NTFS-3g seems to consume too much CPU in the case of very large writes, and that caused me a hang. -- Carl Lei (XeCycle) Department of Physics and Astronomy, SJTU OpenPGP public key: 7795E591 -- /-=| Δ ŋ đ г Σ |=-\ «» ♫♫♫ http://www.google.com/profiles/andre.vmatos
Re: [arch-general] Fwd: Notebook freeze and slow when copy big files to external usb
On Wed, Dec 4, 2013 at 12:08 PM, Maykel Franco maykeldeb...@gmail.com wrote: Hi, I when I make a copy of a large file to a 2GB or 8GB usb 3.0 external hard drive, I notice that arch remains slow, frozen ... He struggles to open windows are minimized. I have the kernel: Take a look at this article on LWN: https://lwn.net/Articles/572911/ In short: it may be fixed by changing /proc/sys/vm/dirty_background_ratio of even better /proc/sys/vm/dirty_background_bytes to some reasonable small value. Lukas
Re: [arch-general] Failure to resume on kernel 3.9.9
On 12/05/13 at 01:54am, Patrick Burroughs (Celti) wrote: Hi list, I realise this email comes with a deplorable paucity of informaton, but I haven't found *any* logs relating to this event. I also realise I've waited what may be considered overlong to ask for help, but I was hoping the bug would be fixed in a later kernel release and it wasn't. Google has failed me, so now I come to you for help. My laptop is an HP Pavilion g7. The system suspends normally, but fails to resume leaving a powered-off screen and no responsiveness to keyboard input, including the magic sysrq, but the caps lock light turns on and off. At first I suspected fglrx, but it happens with or without fglrx loaded, and with or without nomodeset on the kernel command line. Further, it happens identically inside or outside of X. I tried git-bisect on the kernel but gave up after many hours of compiling and testing — anyone know of a faster/easier way to do this? I'm currently running kernel 3.9.8, but am perfectly willing to update again and generate a failure to provide any logs someone thinks may help — I haven't found anything, but I may not be looking in the right place. Thank you, ~Celti Sounds like https://bugzilla.kernel.org/show_bug.cgi?id=61781 -- Jelle van der Waa signature.asc Description: Digital signature
Re: [arch-general] Patch for update-mime-info slowness
[2013-12-04 15:00:31 -0500] Sébastien Leblanc: I am kind of annoyed by the time it takes to update the MIME database Please, please, please. Bug reports and feature requests go to: https://bugs.archlinux.org/ Not this list, not private emails to maintainers, not a combination of the above. This should really be clear to everyone by now... Starting now, I will reject any such emails submitted to this list and, if a whitelisted poster sends one, remove them from the whitelist. -- Gaetan
Re: [arch-general] Fwd: Notebook freeze and slow when copy big files to external usb
On Thu, Dec 05, 2013 at 12:33:38PM +0800, BlissSam wrote: 在 2013-12-4，19:08，Maykel Franco maykeldeb...@gmail.com 写道： Hi, I when I make a copy of a large file to a 2GB or 8GB usb 3.0 external hard drive, I notice that arch remains slow, frozen ... He struggles to open windows are minimized. I have the kernel: 3.12.2-1-ARCH Update the whole system to the last. Can you think because it can be? I also went from the 3.11 kernel However, debian, ubuntu, opensuse me not pass this ... It's happened to someone else? Thanks for everything. I experience this as well. No matter copying to an external drive or internal HDD. I experience very terrible freeze. Last time when I was copying big files, I locked the screen on GNOME and went out. When I came back and found the copy was still in process since the LED of my HDD is flashing. I typed my password and waited nearly 3 minutes until it stopped freezing and unlocked my screen! This isn't a) the same as described above and b) not a kernelbug. It's simply the combination of (slow) hdd, usb and the scheduler. Processes like your gnome and other os-stuff are sleeping while higher-priority processes come in. But the biggest problem will be that your internal-drive + usb are blocking the bus and while writing and reading big files the access time for other processes can be very slow (your hdd is at max. usage rate). -- Best regards, StarBrilliant
Re: [arch-general] Patch for update-mime-info slowness
On Thu, Dec 5, 2013 at 7:37 PM, Gaetan Bisson bis...@archlinux.org wrote: [2013-12-04 15:00:31 -0500] Sébastien Leblanc: I am kind of annoyed by the time it takes to update the MIME database Please, please, please. Bug reports and feature requests go to: I'm not sure whether this should classify as a bug report. Back to the topic. Lately, I have been annoyed by that, too. Maybe it's some recent change (or I just didn't notice it before). I concur, syncing something like MIME database that can be easily rebuild in case an unlikely filesystem corruption occurs seems kinda stupid. Lukas
Re: [arch-general] Patch for update-mime-info slowness
On 5.12.2013 20:10, Lukas Jirkovsky wrote: On Thu, Dec 5, 2013 at 7:37 PM, Gaetan Bisson bis...@archlinux.org wrote: [2013-12-04 15:00:31 -0500] Sébastien Leblanc: I am kind of annoyed by the time it takes to update the MIME database Please, please, please. Bug reports and feature requests go to: I'm not sure whether this should classify as a bug report. Back to the topic. Lately, I have been annoyed by that, too. Maybe it's some recent change (or I just didn't notice it before). I concur, syncing something like MIME database that can be easily rebuild in case an unlikely filesystem corruption occurs seems kinda stupid. Lukas It's a feature. It happened on 1.1 - 1.2 upgrade, and I believe that this commit may be the culprit: http://cgit.freedesktop.org/xdg/shared-mime-info/commit/?id=b58fea97ee1579517ced6091b7bd52d788fc01bb You can try reverting it yourself and then rebuilding the package to see if this is the actual problem. If it is, I suggest you report bug to shared-mime-info maintainers (bugs.fd.o).
Re: [arch-general] Patch for update-mime-info slowness
On 05/12/2013 20:10, Lukas Jirkovsky wrote: On Thu, Dec 5, 2013 at 7:37 PM, Gaetan Bisson bis...@archlinux.org wrote: [2013-12-04 15:00:31 -0500] Sébastien Leblanc: I am kind of annoyed by the time it takes to update the MIME database Please, please, please. Bug reports and feature requests go to: I'm not sure whether this should classify as a bug report. How could this not qualify for a bug report? Maybe this should also be discussed upstream as this is not a Arch specific issue as far as I understand. Maybe they do have reasons for calling fsync so heavily. Back to the topic. Lately, I have been annoyed by that, too. Maybe it's some recent change (or I just didn't notice it before). I concur, syncing something like MIME database that can be easily rebuild in case an unlikely filesystem corruption occurs seems kinda stupid. Again, file a bug upstream. -- Timothée Ravier
Re: [arch-general] Failure to resume on kernel 3.9.9
On Thu, Dec 5, 2013 at 6:05 AM, Jelle van der Waa je...@vdwaa.nl wrote: Sounds like https://bugzilla.kernel.org/show_bug.cgi?id=61781 That showed up in 3.11 and is fixed by reverting to 3.10, and also appears to be i686 only. I did find an Ubuntu bug-report for the same apparent issue last night, but with no helpful information: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1238203. ~Celti
Re: [arch-general] New users not automatically added to 'users' group if -g default group specified?
On Wed, 4 Dec 2013 17:10:45 -1000 Gaetan Bisson bis...@archlinux.org wrote: [2013-12-04 12:57:23 -0600] Leonid Isaev: On Wed, 04 Dec 2013 09:16:46 -0600 David C. Rankin drankina...@suddenlinkmail.com wrote: In the past with arch installs, new users have always been added to the 'users' group. Now that is not being done. In short, this is OK; your user doesn't need to be mentioned in /etc/groups after his primary group. If he is mentioned, then the primary group is also his supplementary one (which is anyway automatic). A while back, the default primary group for all new users was users. It's not anymore: an individual group is created for each new user. One can disable USERGROUPS_ENAB in login.defs to get the old behavior. That's right. This is done to save space in /etc/group on systems with large number of users. So each user gets a home directory, generates log info under /var/log upon login/logout, /etc/passwd and /etc/shadow grow linearly in the number of users, but we are going to shave a few bytes off /etc/group? That's hard to believe. I agree that this reasoning is a speculation, but still having 100 users in /etc/group after 'users' would a mess. Also, I remember the question of why 'users' contains no usernames has already been asked on this ML, but somehow I can't find the link... Best, -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] Patch for update-mime-info slowness
On 06/12/13 05:39, Timothée Ravier wrote: On 05/12/2013 20:10, Lukas Jirkovsky wrote: On Thu, Dec 5, 2013 at 7:37 PM, Gaetan Bisson bis...@archlinux.org wrote: [2013-12-04 15:00:31 -0500] Sébastien Leblanc: I am kind of annoyed by the time it takes to update the MIME database Please, please, please. Bug reports and feature requests go to: I'm not sure whether this should classify as a bug report. How could this not qualify for a bug report? Maybe this should also be discussed upstream as this is not a Arch specific issue as far as I understand. Maybe they do have reasons for calling fsync so heavily. Back to the topic. Lately, I have been annoyed by that, too. Maybe it's some recent change (or I just didn't notice it before). I concur, syncing something like MIME database that can be easily rebuild in case an unlikely filesystem corruption occurs seems kinda stupid. Again, file a bug upstream. I have seen this bug filed upstream and rejected. It is a feature... For the same reason, I would frown on Arch patching it out. It is how upstream decided they want their software. Allan
