August 2012 - Arch-general - lists.archlinux.org

[arch-general] xf86-video-intel-2.20.5
by Jameson 29 Aug '12

29 Aug '12

Updating xf86-video-intel to 2.20.5 today results in my DRM driver hanging when I try to use compiz. Has anyone else seen this, or am I just lucky with my hardware configuration? Does anyone know of something new that got turned on by default in this version that could result in this: Aug 27 12:39:09 localhost kernel: [ 4.733046] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0 Aug 27 12:42:27 localhost kernel: [ 219.129987] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... render ring idle Aug 27 12:42:37 localhost kernel: [ 220.723319] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... render ring idle Aug 27 12:42:37 localhost kernel: [ 222.229987] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... render ring idle Aug 27 12:42:37 localhost kernel: [ 222.230044] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung Aug 27 12:42:37 localhost kernel: [ 222.230087] [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state I'll be happy to post more information, and/or a bug later if that will be helpful. For now, I need to get caught back up at work. Thanks, =-Jameson

7 9

[arch-general] iptables forward policy
by Juan Diego Tascón 28 Aug '12

28 Aug '12

Good day, I'm currently configuring a router. I'm setting the default policies to DROP in the INPUT OUTPUT AND FORWARD chains. I'm thinking of setting the default FORWARD policy to ACCEPT as my default INPUT policy is DROP and unless there is a valid FORWARD rule for a given port the packets wont go anywhere. I'm I right on this? or could someone deliberately setup a packet to be forwarded from my router to my lan? all I could find on google was one similar question with no answer :( Thanks

5 6

[arch-general] linux-3.5.x status
by Tobias Powalowski 28 Aug '12

28 Aug '12

Hi guys, 3.5.x is not yet ready to move to [core], - ext4 regression is not fixed yet, will be fixed in 3.5.3 - watchdogs are completely broken I'm not sure how much of a showstopper the watchdogs are, so please shout out if this is a real problem. If you have any other showstopper please let me know. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

7 15

[arch-general] khugepaged hangs and filesystem unresponsive
by pants 28 Aug '12

28 Aug '12

Good evening, I just experienced a major problem with my system while listening to a music file in mpd from an xfs filesystem over a mdadm raid6. A kernel error was thrown, with the following error.log entry: output: /var/log/error.log > Aug 26 23:34:50 localhost kernel: [283781.061258] xhci_hcd 0000:0b:00.0: ERROR Transfer event TRB DMA ptr not part of current TD > Aug 26 23:34:50 localhost kernel: [283781.062268] xhci_hcd 0000:0b:00.0: ERROR Transfer event TRB DMA ptr not part of current TD > Aug 26 23:34:50 localhost kernel: [283781.063273] xhci_hcd 0000:0b:00.0: ERROR Transfer event TRB DMA ptr not part of current TD > Aug 26 23:34:50 localhost kernel: [283781.064245] xhci_hcd 0000:0b:00.0: ERROR Transfer event TRB DMA ptr not part of current TD > Aug 26 23:34:51 localhost kernel: [283782.058901] timeout: still 1 active urbs.. > Aug 26 23:38:48 localhost kernel: [284019.080666] INFO: task mpd:707 blocked for more than 120 seconds. > Aug 26 23:38:48 localhost kernel: [284019.080696] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > Aug 26 23:40:48 localhost kernel: [284139.071419] INFO: task khugepaged:32 blocked for more than 120 seconds. > Aug 26 23:40:48 localhost kernel: [284139.071451] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > Aug 26 23:40:48 localhost kernel: [284139.071589] INFO: task mpd:525 blocked for more than 120 seconds. > Aug 26 23:40:48 localhost kernel: [284139.071613] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > Aug 26 23:40:48 localhost kernel: [284139.071721] INFO: task mpd:707 blocked for more than 120 seconds. > Aug 26 23:40:48 localhost kernel: [284139.071744] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > Aug 26 23:40:48 localhost kernel: [284139.071943] INFO: task mplayer:28316 blocked for more than 120 seconds. > Aug 26 23:40:48 localhost kernel: [284139.071968] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > Aug 26 23:42:48 localhost kernel: [284259.062189] INFO: task khugepaged:32 blocked for more than 120 seconds. > Aug 26 23:42:48 localhost kernel: [284259.062220] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > Aug 26 23:42:48 localhost kernel: [284259.062358] INFO: task mpd:525 blocked for more than 120 seconds. > Aug 26 23:42:48 localhost kernel: [284259.062382] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > Aug 26 23:42:48 localhost kernel: [284259.062489] INFO: task mpd:702 blocked for more than 120 seconds. > Aug 26 23:42:48 localhost kernel: [284259.062512] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > Aug 26 23:42:48 localhost kernel: [284259.062688] INFO: task mpd:703 blocked for more than 120 seconds. > Aug 26 23:42:48 localhost kernel: [284259.062712] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > Aug 26 23:42:48 localhost kernel: [284259.062829] INFO: task mpd:704 blocked for more than 120 seconds. > Aug 26 23:42:48 localhost kernel: [284259.062852] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Attempts to access other files on the same filesystem after the incident caused the applications used to also go into interruptible sleep (see the mplayer processes that appear later in the log). I was forced to kill and unmount what I could, then force the system down. Afterwards, I could replicate the error by attempting to read the file in question at the same point Even if you have no solution, pointing me towards the relevant kernel mailing list would be very helpful. Thanks, pants.

2 2

[arch-general] systemd boot errors
by Arno Gaboury 28 Aug '12

28 Aug '12

Dear list, I am testing systemd. I have the following errors at boot: 1-failed to start packet filtering framework iptables is installed on my system 2-boot hangs on at: reached target graphical interface i do not use any login manager. runlevel 3 + startx 3-systemd can't write to journal. I have a message at boot: /var/log/journal/d564e939c66712bce792b0710000017f/fss file does not exist. I have in fact /var/log/journal/d564e939c66712bce792b0710000017f/system.journal. Thank you for any help.

3 2

[arch-general] [PSA] change to locale handling
by Tom Gundersen 28 Aug '12

28 Aug '12

Hi guys, We recently (in [testing]) refactored our locale handling. This should hopefully resolve some long-standing issues, so I though I'd bring it to everyone's attention. For some details see: <https://plus.google.com/114015603831160344127/posts/2zKCcnTWDpa>. Please report any issues/bugs/regressions on the bug tracker. Cheers, Tom

1 0

[arch-general] [signoff] syslinux-4.05-7
by Tobias Powalowski 28 Aug '12

28 Aug '12

Hi, we still miss a signoff for i686 anyone who wants to signoff? thanks greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

1 0

[arch-general] Arch Linux and systemd
by Myra Nelson 28 Aug '12

28 Aug '12

There has been much ado on the arch-general mailing list about the move to systemd. I participated in part of it, but like others finally tired of "seeing a dead horse kicked" over and over and over. So much so that the last dev who really paid attention to the list said goodbye. Yet the free for all continues. I think a comment on Allan's blog post might illustrate how I perceive this situation. Are We Removing What Defines Arch Linux? Allan McRae posted to Arch Planet on August 13, 2012 03:59 PM It's not about a single file, ie rc.conf (well not completely), it's about the simplicity of the system. Controversy #2 – The demise of /etc/rc.conf While the single rc.conf is highlighted as major feature of Arch Linux, reading the reviews makes you notice that configuration of an Arch install was never down to a single file. Other files mentioned included… But lets take a step back here… How about some quotes from Judd, the founder of Arch Linux: “In Arch “simple” is different what other distros are considering. The learning is more important than getting something easily done.” “Relying on GUIs to build/use your system is just going to hurt a user in the end. At some point in time a user will need to know all that some GUIs hide.” My question becomes, are we trading the simplicity and ease of setting up a single individuals computer, not corporate or work machine, or a set of two or three home machines for the trappings of the corporate desktop? Are we trading learning the shell (bash or otherwise) and learning to write bug free shell scripts, for learning a set or arbitrary and possibly arcane rules, decided upon in a building somewhere in the world, by someone who knows how to use your computer better than you do? We've already seen the likes of those already seen with polkit and consolekit. Even with udev moving into systemd, an individual on the systemd mailing list has already stated his desire to finally be rid of udev altogether. He considers it an abomination. As to the standardization mentioned, does not such standardization remove one's freedom? I'm not an RMS fan, so don't go there. However, I am old enough to remember when there was no choice for home computers, and a commercial by Apple for the first Mac using the idea of breaking out of 1984 and the dull boring corporate world. Now here we are moving the one OS that's stayed somewhat of a maverick into the stable, then out to pasture to graze with with the rest of the corporate world. At least IMHO. It's not about changing Arch, it's about becoming part of the corporate structure and playing nice with everyone else. You can read that line with the knowledge "Old hippies die hard. And I still don't trust the establishment as far a I can throw my house!" Interoperability is necessary in today's world, but I think it can be done with out sacrificing the heart and soul of Linux. When it comes to the move of lib and lib64 to /usr/lib, I'm basically ambivalent. I still don't like not being able to put /usr on a separate partition, I know there's a mkinitcpio hook to cover that, but I can see the logic in cleaning up the system. I've never really cared for the mess of the LSB. IMHO systemd is for administrators who, unlike Judd Vinet, want to hide the system setup from the user with fancy gui's and not allow anyone but the sysadmin to make any changes. I laud the devs who are working on this project, but I ask you to consider "Is it better for Arch to lead one of the last bastion's of freedom when using Linux into lock step with the the PTB's, or would it be better to develop an alternative that keeps, not just Arch Linux, but Linux a viable alternative to OSX, Windows, any Unix/BSD environment, and the corporate world?" I know it's the simpler, and probably less stressfull solution, but is it the better solution? I firmly believe more discussions like this on the ml would be more productive than the brawls we've seen lately. It also might provide the dev's an opportunity to participate more instead of throwing their hands up in the air and saying never again. To me the mailing list has become reactive. Too many responses, I've been guilty of this, come from predetermined ideas which may or may not be rooted in fact. They may be rooted in the users experience which may have been affected by other circumstances such as the dependency hell being created by the tighter and tighter upstream integration by KDE and Gnome. This again signals the move towards a "corporate desktop environment". A wise unix guru, can't remember the name right now, said something to the effect "the system should be a set of well written programs loosely connected programs, each doing one thing and doing it well". Something many of today's programs don't accomplish. As I said on the arch-general mailing list. These are the battles that have spawned many a linux distro and there is always LFS, even though they moved to use udev inside systemd. Myra Nelson To those who I bcc'd this to; I would like to humbly appologize if I intruded on your personal space, but I wanted to make sure it would be read by you in your own private space without the need to filter through the BS that's likely to occur on the ml. -- Life's fun when your sick and psychotic!

26 54

[arch-general] simple trick to make dealing with python 2/3 scripts easier
by Ben Booth 28 Aug '12

28 Aug '12

Lots of python scripts still use #!/usr/bin/python instead of explicitly stating which version of python to use. Here's quick trick to make running various python version 2 or 3 scripts easier: remove the /usr/bin/python symlink and replace with this shell script: #!/usr/bin/env bash exec /usr/bin/"${PYTHON:-python3}" "$@" Now you can set the PYTHON environment variable to be either python2 or python3, depending on which version of python the script expects. Just don't set PYTHON=python, or you'll get a recursive loop! The only problem with this approach is that /usr/bin/python is owned by the python package, so if you upgrade the python package it might create problems. Any one know of some way to work around this problem?

8 15

Re: [arch-general] xf86-video-intel-2.20.5
by Tobias Jansson 27 Aug '12

27 Aug '12

Hello. I run the Asus Zenbook UX31E sporting a Intel HD 3000. For me the upgrade posed no issues. It won't help you fix your problems, but at least other users could try upgrading knowing that not all users have issues. Regards, Tobias

2 1