Re: [arch-general] [signoff] linux-3.3.1-1
Am 08.04.2012 14:20, schrieb Vladimir Lomov: Hello, ** Jonathan Hudson [2012-04-08 12:53:42 +0100]: On Sun, 08 Apr 2012 13:48:11 +0200, Richard Schütz wrote: Am 07.04.2012 12:33, schrieb Vladimir Lomov: Hello, ** Jonathan Hudson [2012-04-06 20:00:33 +0100]: On Fri, 06 Apr 2012 20:41:46 +0200, Richard Schütz wrote: Since 3.3.0 suspend isn't working on my desktop computer anymore. Looks like device suspension fails somewhere. Furthermore 3.3.1 seriously breaks ath9k on my netbook [1]. [1] https://bugzilla.kernel.org/show_bug.cgi?id=43038 I have a similar reservation. On two eeepc 901, suspend works just fine. Alas, only only on one of them does resume work with a 3.3 kernel. I'm not convinced that 3.3 is ready. Same here: Archlinux x86_64, testing, kernel 3.1.1-1 HW: HP Pavilion dv3 (2210er) with nvidia g104m graphics card, atheros wi-fi. And with 3.2.x there were no problems like that for both of you? Correct. The "won't resume on 3.3.x" eeepc is suspending / resuming happily with 3.2.13-1-ARCH (downgraded a couple of days ago). As it's the wife's machine, I dare not touch it now it's working again. I'm somewhat baffled by the whole thing; there is nothing obvious in any logs, but X fails to come back from sleep. Do you mean "suspend to RAM" or "suspend to DISK"? I tried before "suspend to DISK": 3.3.1 and 3.3.0 works fine. I'm talking about suspend to RAM, but it shouldn't make that big difference in my case, because something seems to be wrong with device suspension already. -- Regards, Richard Schütz
Re: [arch-general] [signoff] linux-3.3.1-1
Am 08.04.2012 14:03, schrieb Vladimir Lomov: Hello, ** Richard Schütz [2012-04-08 13:48:11 +0200]: Am 07.04.2012 12:33, schrieb Vladimir Lomov: Hello, ** Jonathan Hudson [2012-04-06 20:00:33 +0100]: On Fri, 06 Apr 2012 20:41:46 +0200, Richard Schütz wrote: Am 06.04.2012 12:54, schrieb Tobias Powalowski: Hi guys, please signoff 3.3 series for both arches. Since 3.3.0 suspend isn't working on my desktop computer anymore. Looks like device suspension fails somewhere. Furthermore 3.3.1 seriously breaks ath9k on my netbook [1]. [1] https://bugzilla.kernel.org/show_bug.cgi?id=43038 I have a similar reservation. On two eeepc 901, suspend works just fine. Alas, only only on one of them does resume work with a 3.3 kernel. I'm not convinced that 3.3 is ready. Same here: Archlinux x86_64, testing, kernel 3.1.1-1 HW: HP Pavilion dv3 (2210er) with nvidia g104m graphics card, atheros wi-fi. And with 3.2.x there were no problems like that for both of you? I didn't notice any problem with wireless on my notebook before kernel 3.3.1 (I use it every evening). Right now I downgraded to kernel 3.3.0 (took necessary files from projects.archlinux.org/... for version 3.3.0 compiled and intalled .tar.xz packages) and wireless works fine. I have access to other notebook with Archlinux and kernel 3.3.1, that notebook provides AP using hostapd (Atheros wireless card), I'll try tomorrow if AP still works (after update to kernel 3.3.1 I didn't test AP). Ah, you're talking about the wireless problems. I thought you meant the suspend problems with „Same here“. Yeah, ath9k is definitely broken. -- Regards, Richard Schütz
Re: [arch-general] [signoff] linux-3.3.1-1
Am 07.04.2012 12:33, schrieb Vladimir Lomov: Hello, ** Jonathan Hudson [2012-04-06 20:00:33 +0100]: On Fri, 06 Apr 2012 20:41:46 +0200, Richard Schütz wrote: Am 06.04.2012 12:54, schrieb Tobias Powalowski: Hi guys, please signoff 3.3 series for both arches. Since 3.3.0 suspend isn't working on my desktop computer anymore. Looks like device suspension fails somewhere. Furthermore 3.3.1 seriously breaks ath9k on my netbook [1]. [1] https://bugzilla.kernel.org/show_bug.cgi?id=43038 I have a similar reservation. On two eeepc 901, suspend works just fine. Alas, only only on one of them does resume work with a 3.3 kernel. I'm not convinced that 3.3 is ready. Same here: Archlinux x86_64, testing, kernel 3.1.1-1 HW: HP Pavilion dv3 (2210er) with nvidia g104m graphics card, atheros wi-fi. And with 3.2.x there were no problems like that for both of you? -- Regards, Richard Schütz
Re: [arch-general] [signoff] linux-3.3.1-1
Am 06.04.2012 12:54, schrieb Tobias Powalowski: Hi guys, please signoff 3.3 series for both arches. Upstream changes: http://kernelnewbies.org/LinuxChanges Config cleanup: - disabled comedi staging modules - disabled not needed GPIO modules - disabled W1 support - disabled charger and battery modules - disabled snd_soc module - disabled regulator modules - disabled SPI support Fixed Bugs and feature requests: - New default 'ondemand' cpufreq govenor #28778 - added mtd header files #29076 - more I can't remember ;) greetings tpowa Since 3.3.0 suspend isn't working on my desktop computer anymore. Looks like device suspension fails somewhere. Furthermore 3.3.1 seriously breaks ath9k on my netbook [1]. [1] https://bugzilla.kernel.org/show_bug.cgi?id=43038 -- Regards, Richard Schütz
Re: [arch-general] linux 3.1-4 - two i686 lockups after ~ 5 hours of operations. two x86_64 seem OK
Am 10.11.2011 20:16, schrieb David C. Rankin: Richard, David - check your hardware clock "# hwclock -r" and compare that to the time returned by "# date". If they are hours apart, then make sure your sysclock is correct and set the hardware clock to your sysclock with "# hwclock -w". Worth checking regardless. I know this used to be done on boot or shutdown and I don't know why it isn't anymore. I'll do some more digging. I'm running ntpd on all machines, so sysclock and hwclock are almost perfect in sync. If the issue is clock-related it would be rather the fault of ntpd and adjtimex slewing the time than the difference between sysclock and hwclock. -- Regards, Richard Schütz
Re: [arch-general] linux 3.1-4 - two i686 lockups after ~ 5 hours of operations. two x86_64 seem OK
Am 10.11.2011 18:47, schrieb David C. Rankin: tpowa, Upgraded 5 i686 boxes and 2 x86_64 boxes to linux 3.1-4 yesterday night. This morning, one i686 server is dead, other i686 box responded to xterm (return input) and then locked (ssh connection was left up after login to confirm reboot). Two other i686 boxes (under no load) still running. The boxes are remote. I'll pull the logs when I get to the site and send. Anybody else seeing this with linux 3.1-4? I had lockups on my notebook [1] and netbook [2] during normal usage. Both have a Intel processor. The AMD based desktop machine had no problems so far. All systems are running linux 3.1-4 x86_64. [1] http://pastebin.com/VAnTLKtP [2] http://pastebin.com/64QKSJTN -- Regards, Richard Schütz
Re: [arch-general] VirtualBox not running properly
Am 13.10.2011 19:48, schrieb Madhurya Kakati: Even kvm doesn't seem to work. I loaded the kvm-amd module and added myself to the kvm group. When I try to run qemu with kvm I get this error: Could not access KVM kernel module: Permission denied failed to initialize KVM: Permission denied No accelerator found! Did you relogin after adding your user to the group? -- Regards, Richard Schütz
Re: [arch-general] VirtualBox not running properly
Am 13.10.2011 19:31, schrieb Victor Silva: Have you tried to run? /etc/init.d/vboxdrv setup Again? I think you mean rc.d here, but there is no init script anymore. To build the modules /usr/bin/vboxbuild must be used now. -- Regards, Richard Schütz
Re: [arch-general] VirtualBox not running properly
Am 13.10.2011 19:28, schrieb Madhurya Kakati: Hi, I installed Virtual/box from the official repos. However when I try to run a Virtual OS it gives me the following error. http://i.imgur.com/sBzl4.png I followed all the instructions after installing it. Did you add your user to the vboxusers group? -- Regards, Richard Schütz
Re: [arch-general] New GTK update make LibreOffice 'save' document type unreadable
Am 31.08.2011 18:06, schrieb David C. Rankin: Guys, I think the GTK update made the LibreOffice 'save' dialog 'document type' list box unreadable. Where you used to be able to read: "All Formats" "Open Document Text .odt" "Word 97 .doc", etc..., now the entire list is squished down into a 1/2 of screen space and is unreadable. I can reproduce this here, too. The only update that looks relevant is: gtk2 (2.24.5-3 -> 2.24.6-1). Is anyone else seeing this? If so, any idea whether this is a GTK2 bug or a Libre bug? I'm just trying to figure out where this bug goes Downgrading the gtk2 package brings back the old behaviour. I don't believe it's a LibreOffice related bug, because the issue is present in other GTK applications (e.g. GIMP), too. I think you should report this upstream. -- Regards, Richard Schütz
Re: [arch-general] Weird behaviour A/C vs battery
Am 13.08.2011 14:25, schrieb Mauro Santos: I've read that the reboot method/commands sent to the hardware were being changed to closely mimic what windows does [1], this was meant to workaround broken bios which don't comply to a standard and are only made and tested to work with windows. Maybe somehow that is causing the problem for you, I don't know if there is any way to use the "old" method but I guess that even if there is this is worth a bug report in the kernel bugtracker. [1] http://mjg59.livejournal.com/137313.html Switching between reboot methods is possible with a kernel parameter. There are several methods. May the source [0] be with you. [0] http://git.kernel.org/?p=linux/kernel/git/stable/linux-3.0.y.git;a=blob;f=arch/x86/kernel/reboot.c;h=9242436e9937e5a4ef91c6baa04eaf2e90243125;hb=HEAD#l55 -- Regards, Richard Schütz
Re: [arch-general] Vodafone HSDPA key
Am 01.07.2011 23:14, schrieb Fons Adriaensen: Hello all, Is it possible to use Vodafone's (Italy) HSDPA USB key with Archlinux ? I'd want to use it without depending on any 'desktop' tools - just netcfg and whatever other command line tools it takes. Ciao, pppd with a small chat script is sufficient. Perhaps you'll need usb_modeswitch to switch the HSPA stick to the correct mode, too. -- Regards, Richard Schütz
Re: [arch-general] Anybody else have problems with the new Nvidia drivers (275.09.07-1)
Am 19.06.2011 04:07, schrieb Armando M. Baratti: Em 18-06-2011 05:03, Richard Schütz escreveu: I don't think so. Epiphany is based on WebKit these days. And because I can trigger the bug in EOG (Eye of GNOME) it doesn't look like a browser problem for me at all. Perhaps it is a problem of GTK together with nvidia 275.09.07. I tried feh (a simple X11 image viewer that doesn't use GTK or Qt) and it works fine without flickering, artifacts or something else strange. I think you're right. I've downloaded and opened the file with some image viewers: geeqie / fotoxx / gimp are fine, but gthumb froze (eventually freezing xorg with it). Not all viewers trigger the bug, that's right. There surely is a small difference in the way the image is shown. By the way, opening other images, even bigger than yours, on gthumb worked without a glitch. It seems that there is something related specifically to that image involved in the freezing. As I wrote in my first post: it's the width of 2047px. You could take every picture with that width. The effect gets stronger with more height. nvidia 275.09.07-1 nvidia-utils 275.09.07-1 geeqie 1.0-5 fotoxx 11.06.1-1 gimp 2.6.11-5 GeForce 8600 GT nvidia 275.09.07 (x86_64) on GeForce 8600 GT here. I heard that older versions of the nvidia driver should be fine, but had no time to test it myself. Armando -- Regards, Richard Schütz
Re: [arch-general] Anybody else have problems with the new Nvidia drivers (275.09.07-1)
Am 18.06.2011 11:29, schrieb Martti Kühne: On Sat, Jun 18, 2011 at 10:03 AM, Richard Schütz wrote: Am 18.06.2011 09:08, schrieb Dan Vratil: I don't think so. Epiphany is based on WebKit these days. And because I can trigger the bug in EOG (Eye of GNOME) it doesn't look like a browser problem for me at all. Perhaps it is a problem of GTK together with nvidia 275.09.07. I tried feh (a simple X11 image viewer that doesn't use GTK or Qt) and it works fine without flickering, artifacts or something else strange. -- Regards, Richard Schütz Update, I also see anything but the picture when the bug occurs, namely random garbage. I can confirm that feh, launched the regular way does not trigger the bug, although, also I have to confirm that display (imagemagick-6.6.9.8-1) actually does trigger the bug. Actually my guess is feh restricts itself to become larger than the screen's resolution (which is smaller than 2047 here) and thus is just not storing the full resolution image in video memory. I just managed to something like trigger the bug, X hang for about 4 seconds here and will display some garbage, with $ feh --geometry 2047x1529 nvbugy7cd.jpg heh, after trying this several times, the hang disappears. Might this be related to caching? cheers! Yes, you are right: display crashed my X server right now. So this seems to be even unrelated to the toolkit. -- Regards, Richard Schütz
Re: [arch-general] Anybody else have problems with the new Nvidia drivers (275.09.07-1)
Am 18.06.2011 09:08, schrieb Dan Vratil: On Friday, June 17, 2011 23:10:01 Richard Schütz wrote: The new driver really seems to have a major problem. I figured out that you just need an image with 2047px width to screw up the driver. ATTENTION: This can crash your X server and corrupt memory! Example: [1], an otherwise harmless picture. Every picture with the same width will work, too. I could trigger the bug at least with Firefox, Midori, Epiphany and EOG. It looks like some applications like Chromium alter the size, so they don't trigger it. [1] http://www.abload.de/img/nvbugy7cd.jpg I can confirm crash of Xorg with Firefox 4 on Nvidia GT218 with 275.09.7 drivers. Epiphany displays weird artefacts, but does not crash. Opera and Chrome are OK. Looks like only Gecko has these problems. I don't think so. Epiphany is based on WebKit these days. And because I can trigger the bug in EOG (Eye of GNOME) it doesn't look like a browser problem for me at all. Perhaps it is a problem of GTK together with nvidia 275.09.07. I tried feh (a simple X11 image viewer that doesn't use GTK or Qt) and it works fine without flickering, artifacts or something else strange. -- Regards, Richard Schütz
Re: [arch-general] Anybody else have problems with the new Nvidia drivers (275.09.07-1)
Am 18.06.2011 00:20, schrieb John K Pate: On Fri, 2011-06-17 at 17:09 -0500, Yaro Kasear wrote: On Friday, June 17, 2011 04:10:01 PM Richard Schütz wrote: The new driver really seems to have a major problem. I figured out that you just need an image with 2047px width to screw up the driver. ATTENTION: This can crash your X server and corrupt memory! Example: [1], an otherwise harmless picture. Every picture with the same width will work, too. I could trigger the bug at least with Firefox, Midori, Epiphany and EOG. It looks like some applications like Chromium alter the size, so they don't trigger it. [1] http://www.abload.de/img/nvbugy7cd.jpg Are we sure ths is a bug with the nVidia driver? Can someone load that image who isn't using it? Loads fine for me in firefox and midori, using intel driver. I can confirm that i915 works fine in that case. -- Regards, Richard Schütz
Re: [arch-general] Anybody else have problems with the new Nvidia drivers (275.09.07-1)
The new driver really seems to have a major problem. I figured out that you just need an image with 2047px width to screw up the driver. ATTENTION: This can crash your X server and corrupt memory! Example: [1], an otherwise harmless picture. Every picture with the same width will work, too. I could trigger the bug at least with Firefox, Midori, Epiphany and EOG. It looks like some applications like Chromium alter the size, so they don't trigger it. [1] http://www.abload.de/img/nvbugy7cd.jpg -- Regards, Richard Schütz
Re: [arch-general] Network Config - Fixed IP - ifconfig no longer reports broadcast address?
Am 12.06.2011 00:59, schrieb David C. Rankin: Guys, Bug or feature? After updating rc.conf to contain the new network configuration for a fixed IP, ifconfig no longer reports the broadcast address. Using the new config of: interface=eth0 address=192.168.6.14 netmask=255.255.255.0 gateway=192.168.6.13 I get: 17:48 archangel:~> ifconfig eth0 Link encap:Ethernet HWaddr 00:21:85:1A:8C:FA inet addr:192.168.6.14 Bcast:0.0.0.0 Mask:255.255.255.0 ^^ inet6 addr: fe80::221:85ff:fe1a:8cfa/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:102 errors:0 dropped:0 overruns:0 frame:0 TX packets:140 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:14657 (14.3 Kb) TX bytes:15177 (14.8 Kb) Interrupt:41 Base address:0x2000 Prior to the change, the broadcast address was correctly reported. eth0 Link encap:Ethernet HWaddr 00:21:85:1A:8C:FA inet addr:192.168.6.14 Bcast:192.168.6.255 Mask:255.255.255.0 inet6 addr: fe80::221:85ff:fe1a:8cfa/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:103 errors:0 dropped:0 overruns:0 frame:0 TX packets:139 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:14683 (14.3 Kb) TX bytes:15505 (15.1 Kb) Interrupt:41 Base address:0x2000 If I modify rc.conf and change back to the old format: # old network config for broadcast address eth0="eth0 192.168.6.14 netmask 255.255.255.0 broadcast 192.168.6.255" INTERFACES=(eth0) gateway="default gw 192.168.6.13" ROUTES=(gateway) then the broadcast address is correctly reported again. Is this a bug or feature? What says "ip addr show"? -- Regards, Richard Schütz
Re: [arch-general] [signoff] kernel26-2.6.39.1-1
Am 10.06.2011 17:09, schrieb Tobias Powalowski: Hi guys, please signoff 2.6.39 series for both arches. Upstream changes: http://kernelnewbies.org/LinuxChanges WARNING: AUFS2 support is gone for now, if this is no showstopper we should go move it to [core]. If noone has real objections, I hope to get this kernel into [core]. Along with this the binary modules mentioned on the previous thread will be removed from [core] and [extra]: - tiacx (broken) - ndiswrapper (not needed anymore) - intel536/537 (does not compile on .39 series) - madwifi (obsolete) - martian (old modem driver) - tiacx-lts - ndiswrapper-lts greetings tpowa signoff x86_64 -- Regards, Richard Schütz
Re: [arch-general] mpd fails to start
Am 10.06.2011 18:47, schrieb Madhurya Kakati: Hello, Recently mpd has stopped working. It doesn't start up at boot and when i run "rc.d start mpd" I get this error /etc/rc.d/mpd: line 6: 24502 Aborted /usr/bin/mpd /etc/mpd.conf&>/dev/null. I am using gnome3(if thats somehow causing the problem.) I believe its due to some ALSA pulseaudio mixup but I am not sure. However if I run "sudo mpd" I get this output: [papul@papuldesktop ~]$ sudo mpd output: No "audio_output" defined in config file output: Attempt to detect audio output device output: Attempting to detect a alsa audio device output: Successfully detected a alsa audio device and after that if I run "mpc play" I get this: [papul@papuldesktop ~]$ mpc play Metallica - The Unforgiven II [paused] #4/8 0:00/6:36 (0%) volume: n/a repeat: off random: off single: off consume: off ERROR: problems opening audio device Please help coz I haven't been able to listen to music for quite sometime now. :( Did you try to configure MPD to use PulseAudio then? (see [1]) [1] https://wiki.archlinux.org/index.php/MPD -- Regards, Richard Schütz
Re: [arch-general] [arch-dev-public] removing load-modules.sh from udev
Am 29.05.2011 12:52, schrieb Tom Gundersen: On Sun, May 29, 2011 at 12:44 PM, Casey Peter wrote: Also !usblp for those of us with USB printer issues. (especially HP usb inkjets) Yup, blacklist it in /etc/modprobe.d (we should probably fix this once and for all, I believe other distro's simply removed this module, but haven't had time to look into it). On my computer the module is not loaded for some reason (I have a HP usb laserjet)... -t Removing the module isn't a good idea, as some applications still need it. For example escputil, which is shipped with gutenprint, needs usblp to read the ink levels from some EPSON printers. So only blacklisting it by default seems to be the better way. -- Regards, Richard Schütz
Re: [arch-general] [signoff] kernel26-2.6.38.4-1
Am 22.04.2011 21:09, schrieb Tobias Powalowski: Hi guys, please signoff 2.6.38.4 series for both arches. greetings tpowa Could you integrate the patch from [1]? This fixes the ath9k performance regression introduced in 2.6.38. See [2] for kernel bug tracker entry. [1] https://bugzilla.kernel.org/attachment.cgi?id=55392 [2] https://bugzilla.kernel.org/show_bug.cgi?id=31452 -- Regards, Richard Schütz
Re: [arch-general] pacman: -Ss search results weird
Am 22.04.2011 23:18, schrieb Marek Otahal: Hi, regarding the recent 'default syslog' discussion I wanted to check what is Arch up to now...I came to interesting results concerning pacman's search behavior. [marek@beruska ~]$ pacman -Ss syslog core/perl 5.12.3-1 [12.06 MB] (base) [installed] A highly capable, feature-rich programming language core/syslog-ng 3.2.2-2 [0.21 MB] (base) Next-generation syslogd with advanced networking and filtering capabilities extra/metalog 1.0-1 [0.02 MB] Metalog is a modern replacement for syslogd and klogd community/perl-device-modem 1.53-1 [0.04 MB] Perl extension to talk to modem devices connected via serial port community/rsyslog 5.8.0-1 [0.25 MB] [installed] An enhanced multi-threaded syslogd with a focus on security and reliability [marek@beruska ~]$ I thought pacman -Ss "string" searches packages' name and desc for the string, I wonder why the perl things show up? Cheers& happy Eastern! :) It's because the perl package provides perl-sys-syslog. -- Regards, Richard Schütz
Re: [arch-general] libre office java support
Am 12.04.2011 21:54, schrieb Dennis Beekman: Libre Office seems to depend on the openjdk6 package but this package doesn't support applets in firefox and therefore i use the jre & jdk packages instead. When i installed the latest updates wich included Libre Office it removed the jre package in favor of the openjdk6 package. I have forced pacman to remove to openjdk package and install the jre and jdk packages instead... and Libre Office works fine (i see no diffirence at least). Is there any specific reason for Libre Office to use openjdk6 ? and can we perhaps change this to jre/jdk instead ? libreoffice depends on java-runtime, which is no real package. java-runtine is provided by the openjdk6 and jre package, so it does not matter which you use. -- Regards, Richard Schütz
Re: [arch-general] Port 80 is shown open in port scan without any web server running
On 30/03/11 16:40, Richard Schütz wrote: The output of "ip addr show" would be interesting. here is the output: ip addr show 1: lo: mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo 2: eth0: mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 20:cf:30:5a:ea:aa brd ff:ff:ff:ff:ff:ff inet 172.16.37.164/26 brd 172.16.37.191 scope global eth0 3: vboxnet0: mtu 1500 qdisc noop state DOWN qlen 1000 link/ether 0a:00:27:00:00:00 brd ff:ff:ff:ff:ff:ff Either 172.16.37.164 is mapped 1:1 to a public IP address or you are behind a NAT. Looks very crappy in my eyes. -- Regards, Richard Schütz
Re: [arch-general] Port 80 is shown open in port scan without any web server running
nmap -sV 115.187.45.97 Are you sure that this IP is really your public one? The static IP which you do assign to your eth0 interface is from a private netblock. It looks like you create a tunnel on top of that connection with this strange Cyberoam client software. The output of "ip addr show" would be interesting. -- Regards, Richard Schütz
Re: [arch-general] [signoff] kernel26-2.6.38.1-1
Am 25.03.2011 09:09, schrieb Sergey Manucharian: Excerpts from Tobias Powalowski's message from Fri 25-Mar-11 07:46: Upstream changes: http://kernelnewbies.org/LinuxChanges Features included: - latest stable patches - disabled /dev/kmem - added AMD_IOMMU support - kernel image is now xz compressed - NUMA is enabled on x86_64 - AUTOSCHED (aka the wonder patch) is enabled - aufs2.1 latest snapshot - added additional i915 patch - added radeaon kms fix The video is still broken (ThinkPad R61, Intel GM965), the same artefacts and unusable X terminals... Looks like my i915 works properly now. I use the current libdrm and xf86-video-intel versions from [testing]. ath9k is still broken. Sorry for the delay, but last week was stressful. 2.6.38.2 is released anyway. -- Regards, Richard Schütz
Re: [arch-general] [signoff] kernel26-2.6.38-2
Am 22.03.2011 17:27, schrieb Richard Schütz: Am 22.03.2011 15:31, schrieb Tobias Powalowski: Hi guys, please signoff 2.6.38 series for both arches. Upstream changes: http://kernelnewbies.org/LinuxChanges Features included: - latest stable patches - disabled /dev/kmem - added AMD_IOMMU support - kernel image is now xz compressed - NUMA is enabled on x86_64 - AUTOSCHED (aka the wonder patch) is enabled - aufs2.1 latest snapshot greetings tpowa No signoff again. There are still graphic glitches (i915) and the WLAN (ath9k) performance on my netbook is miserable. I read that the graphic glitches should be fixed in userspace with current libdrm und xf86-video-intel versions (libdrm 2.4.24 and xf86-video-intel newer than 2011-02-22), but I was unable to test this yet. I noticed that new X packages hit [testing] and tried those, but the graphic glitches are still there. corresponding kernel bugzilla entries: i915 problems: https://bugzilla.kernel.org/show_bug.cgi?id=27572 ath9k problems: https://bugzilla.kernel.org/show_bug.cgi?id=31452 -- Regards, Richard Schütz
Re: [arch-general] [signoff] kernel26-2.6.38-2
Am 22.03.2011 15:31, schrieb Tobias Powalowski: Hi guys, please signoff 2.6.38 series for both arches. Upstream changes: http://kernelnewbies.org/LinuxChanges Features included: - latest stable patches - disabled /dev/kmem - added AMD_IOMMU support - kernel image is now xz compressed - NUMA is enabled on x86_64 - AUTOSCHED (aka the wonder patch) is enabled - aufs2.1 latest snapshot greetings tpowa No signoff again. There are still graphic glitches (i915) and the WLAN (ath9k) performance on my netbook is miserable. I read that the graphic glitches should be fixed in userspace with current libdrm und xf86-video-intel versions (libdrm 2.4.24 and xf86-video-intel newer than 2011-02-22), but I was unable to test this yet. -- Regards, Richard Schütz
Re: [arch-general] [signoff] kernel26-2.6.38-1
Am 19.03.2011 16:52, schrieb Richard Schütz: Am 19.03.2011 16:41, schrieb Jeff Cook: On Sat, Mar 19, 2011 at 7:21 AM, Richard Schütz wrote: On Sat, Mar 19, 2011 at 12:57 AM, Jeff Cook wrote: Having issues here with ath9k, much slower than it was with 2.6.37. Found this bug re: Ubuntu on Launchpad, haven't checked the kernel tracker: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/735171 Looks like I'm also getting bit by this on another machine that uses ath5k. Watching wireshark on two machines, almost all packets sent to the ath5k card never make it with 2.6.38. I also tested with a compat-wireless tarball from 2011-03-18 with the same results. Reverting to 2.6.37 makes the issue go away. Definitely seems like an unsafe upgrade at least for Atheros users. I can confirm that. When running 2.6.38 my downstream with ath9k is about 13 times slower compared to 2.6.37.4. -- Regards, Richard Schütz What kind of network are you using? A person in IRC suggested that these issues might only exist on certain (relatively rare) networks, like 802.11n or ad-hoc. It is a 802.11n network and they aren't that rare today. Every access point in my neighbourhood is using that standard. I'll try to reproduce the issue after switching my access point to 802.11g only. The issue is actually only present in 802.11n mode. I noticed that the "Invalid misc" counter shown by iwconfig rises quickly. -- Regards, Richard Schütz
Re: [arch-general] [signoff] kernel26-2.6.38-1
Am 19.03.2011 16:41, schrieb Jeff Cook: On Sat, Mar 19, 2011 at 7:21 AM, Richard Schütz wrote: On Sat, Mar 19, 2011 at 12:57 AM, Jeff Cook wrote: Having issues here with ath9k, much slower than it was with 2.6.37. Found this bug re: Ubuntu on Launchpad, haven't checked the kernel tracker: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/735171 Looks like I'm also getting bit by this on another machine that uses ath5k. Watching wireshark on two machines, almost all packets sent to the ath5k card never make it with 2.6.38. I also tested with a compat-wireless tarball from 2011-03-18 with the same results. Reverting to 2.6.37 makes the issue go away. Definitely seems like an unsafe upgrade at least for Atheros users. I can confirm that. When running 2.6.38 my downstream with ath9k is about 13 times slower compared to 2.6.37.4. -- Regards, Richard Schütz What kind of network are you using? A person in IRC suggested that these issues might only exist on certain (relatively rare) networks, like 802.11n or ad-hoc. It is a 802.11n network and they aren't that rare today. Every access point in my neighbourhood is using that standard. I'll try to reproduce the issue after switching my access point to 802.11g only. -- Regards, Richard Schütz
Re: [arch-general] [signoff] kernel26-2.6.38-1
Am 19.03.2011 09:04, schrieb Jeff Cook: On Sat, Mar 19, 2011 at 12:57 AM, Jeff Cook wrote: Hi guys, please signoff 2.6.38 series for both arches. Having issues here with ath9k, much slower than it was with 2.6.37. Found this bug re: Ubuntu on Launchpad, haven't checked the kernel tracker: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/735171 Looks like I'm also getting bit by this on another machine that uses ath5k. Watching wireshark on two machines, almost all packets sent to the ath5k card never make it with 2.6.38. I also tested with a compat-wireless tarball from 2011-03-18 with the same results. Reverting to 2.6.37 makes the issue go away. Definitely seems like an unsafe upgrade at least for Atheros users. I can confirm that. When running 2.6.38 my downstream with ath9k is about 13 times slower compared to 2.6.37.4. -- Regards, Richard Schütz
Re: [arch-general] Where is the boot log?
Am 18.03.2011 09:56, schrieb SanskritFritz: On Fri, Mar 18, 2011 at 5:59 AM, Madhurya Kakatiwrote: I guess arch should have a boot log. It is something every OS should have IMHO. Isn't that dmesg? Or are you looking for something else? He is looking for the error output of the scripts that are executed while booting. In his case it is the output of alsactl which is called in "/etc/rc.d/alsa". That stuff is only printed to the terminal and does not go to the kernel ring buffer. -- Regards, Richard Schütz
Re: [arch-general] [signoff] kernel26-2.6.38-1
Am 16.03.2011 20:27, schrieb Tobias Powalowski: Hi guys, please signoff 2.6.38 series for both arches. Upstream changes: http://kernelnewbies.org/LinuxChanges Features included: - kernel image is now xz compressed - NUMA is enabled on x86_64 - AUTOSCHED (aka the wonder patch) is enabled - aufs2.1 latest snapshot greetings tpowa No signoff. There are graphic glitches on my netbook that have not been there in latest 2.6.37. I found an upstream bug report which seems to deal exactly with my problem: https://bugzilla.kernel.org/show_bug.cgi?id=27572 -- Regards, Richard Schütz
Re: [arch-general] Where is the boot log?
Am 16.03.2011 04:55, schrieb Madhurya Kakati: Hi, I am facing some problems with alsa. During booting it shows some errors. But I don't know how to copy those and paste them here. Can someone please tell me where can I find the log file? Thanks. That is likely a problem with the dump of the ALSA state. Remove the file "/var/lib/alsa/asound.state" and run "/etc/rc.d/alsa stop" after that. Then the current state is dumped into a fresh file and the error should be gone. -- Regards, Richard Schütz
Re: [arch-general] [signoff] kernel26-2.6.37.3-1
Am 08.03.2011 13:25, schrieb Tobias Powalowski: Hi guys, - bump to latest version greetings tpowa signoff x86_64 -- Regards, Richard Schütz
Re: [arch-general] Kernel Panic on x64 when writting to 1TB External USB disk
I assume that both of you use X and as a consequence don't see the kernel panic output. Try to trigger the error with copying some files to the disk from e.g. tty1. Then useful debug information should be visible there. -- Regards, Richard Schütz
Re: [arch-general] [signoff] kernel26-2.6.37.1-1
Hi guys, - bump to latest version greetings tpowa signoff x86_64 -- Regards, Richard Schütz
Re: [arch-general] xcb_wait_for_reply () from /usr/lib/libxcb.so.1 causing kdesktop crash on x86_64 (is this an upstream issue?)
How do I add a debugging flag? Do I use CFLAGS=-DEBUG? CPPFLAGS=-DEBUG? add --enable-debug? I've checked ./configure --help and it is silent on the issue. I've added the --enable-debug below. It builds fine, but is only slightly larger than the original: -rw-r--r-- 1 david david 274088 Feb 19 12:12 libxcb-1.7-1-x86_64.pkg.tar.xz -rw-r--r-- 1 david david 273996 Feb 19 11:46 libxcb-1.7-1-x86_64.pkg.tar.xz.sav Do I need to enable debugging in another manner? You must add 'options=(!strip)' to the PKGBUILD. Otherwise the debugging symbols will be removed by makepkg automatically after the build process. 'export CFLAGS="$CFLAGS -g"' and 'export CXXFLAGS="$CXXFLAGS -g"' tell the compiler to build the binaries with debugging symbols. -- Regards, Richard Schütz
