Re: [gentoo-user] Adding a use flag: hwdb
On 06/12/2012 12:29 AM, Chris Stankevitz wrote: Michael, On Mon, Jun 11, 2012 at 7:22 PM, Michael Orlitzky mich...@orlitzky.com wrote: Portage doesn't know what you want to do, so it does the safe thing and lets you decide. Either, Somewhat tongue-in-cheek: I don't know either. I don't want udev, udisks, hwdb or even know what they are. Somebody else wants all that stuff on my system (gentoo profile or the gentoo handbook author) and I wish that person would have addressed emerge's concerns WRT use flags. I understand, but somewhere along the line, you installed something that needs udisks, and udisks needs udev with USE=hwdb set. If you went to install that thing now (whatever it was), you would be faced with a choice: enable USE=hwdb, or don't install the thing. Maybe USE=hwdb should be default for udev, who knows. Sometimes USE flags are basically essential like git with USE=perl and the devs will make them default. Other times, the flag may do something stupid but another package requires it anyway. In that case, you don't want the flag on by default, and so you're still stuck with a choice. If you *always* want it to just emerge the thing, enable the autounmask-write feature. I didn't know what RUBY was or why it was on my system or who wanted it or whether that person wanted ruby_targets_ruby19 or RUBY_TARGETS or whatever. Me waiting would require 1) that I knew RUBY was a temporary problem that would be fixed in the future [I assumed it was not... just like hwdb] and 2) that I not perform an emerge sync/world. When I `emerge -puDN world` and something looks like it's going to be a big pain in the ass, I just ignore it for a few days and `emerge -uN1' the rest of the packages a few at a time. Often it gets fixed (or obsoleted) before I have to deal with it.
Re: [gentoo-user] Adding a use flag: hwdb
On Mon, 11 Jun 2012 21:29:48 -0700, Chris Stankevitz wrote: Portage doesn't know what you want to do, so it does the safe thing and lets you decide. Either, I don't know either. I don't want udev, udisks, hwdb or even know what they are. Somebody else wants all that stuff on my system (gentoo profile or the gentoo handbook author) and I wish that person would have addressed emerge's concerns WRT use flags. They have, as far as is possible. udisks needs udev with hwdb, and the ebuild tells you that when you try to merge it. An ebuild can override default flag settings for itself, but not for other packages (that would lead to anarchy) so it tells you what changes are needed and offers to make them for you. When hwdb becomes more global in scope, it may make sense to add it to the desktop profiles as default, but for now it is optional. If you choose a distro that offers you maximum choice over how your system is built, you really shouldn't complain about being given choices... -- Neil Bothwick How is it one careless match can start a forest fire, but it takes a whole box to start a campfire? signature.asc Description: PGP signature
Re: [gentoo-user] Traffic shaping - downstream data
On Mon, June 11, 2012 5:27 pm, Datty wrote: Hi all I'm looking for some help setting up traffic shaping on my internet connection. I have a bit of an odd setup in that I run a remote VPN server that all of my traffic is pushed through and out on to the internet. As I understand generally it isn't possible to shape incoming traffic but as I have control of the VPN server which pushes the traffic to me I wondered if it was possible to implement something on that side? No traffic other than the VPN tunnel goes out of my home connection. I'm trying to do this because I have a service running on one of my home machines that requires around 5kbps constantly with low latency (200ms), but as my home connection is 750kbps it gets saturated very quickly causing huge spikes in latency. Does anyone have any ideas as to how I could achieve this? Generally any pointers at all would be greatly appreciated. If VPN is the only traffic to/from your home, eg. using your internet connection and you control the VPN-server on the other side, you could limit the upstream of the remote server to your home. Thanks for your time Oliver -- Joost
[gentoo-user] Re: Adding a use flag: hwdb
On Tuesday, June 12, 2012, Neil Bothwick wrote: you really shouldn't complain about being given choices... I apologize, it was no my intention to complain. In the future I will make a decision and not complain. Thank you to everyone for your assistance! Chris
Re: [gentoo-user] Traffic shaping - downstream data
On Tue, Jun 12, 2012 at 9:58 AM, J. Roeleveld jo...@antarean.org wrote: On Mon, June 11, 2012 5:27 pm, Datty wrote: Hi all I'm looking for some help setting up traffic shaping on my internet connection. I have a bit of an odd setup in that I run a remote VPN server that all of my traffic is pushed through and out on to the internet. As I understand generally it isn't possible to shape incoming traffic but as I have control of the VPN server which pushes the traffic to me I wondered if it was possible to implement something on that side? No traffic other than the VPN tunnel goes out of my home connection. I'm trying to do this because I have a service running on one of my home machines that requires around 5kbps constantly with low latency (200ms), but as my home connection is 750kbps it gets saturated very quickly causing huge spikes in latency. Does anyone have any ideas as to how I could achieve this? Generally any pointers at all would be greatly appreciated. If VPN is the only traffic to/from your home, eg. using your internet connection and you control the VPN-server on the other side, you could limit the upstream of the remote server to your home. Thanks for your time Oliver -- Joost Thanks that makes total sense. I was looking at it backwards, not thinking that I could apply the same upstream limit to my VPN server. A bit of background/my aims - The vpn interface is 100mbps, I want everybody but me on the VPN to be able to use up to that speed, but for traffic sent to 192.168.50.0/24 to be limited to 750kbps, with 700kbps of that for normal traffic and 50kbps for my tcp traffic from port . Based on that do the following rules make sense? tc qdisc add dev tap0 root handle 1: htb default 12 -- Set the interface to be handle 1 and default traffic to be in class 1:12 tc class add dev tap0 parent 1: classid 1:1 htb rate 100mbps ceil 100mbps -- Set 100mbps to be available to all classes overall tc class add dev tap0 parent 1:1 classid 1:12 htb rate 100mbps ceil 100mbps -- Set 100mbps to be available to all people on the vpn tc class add dev tap0 parent 1:1 classid 1:15 htb rate 750kbps ceil 750kbps -- To be applied to all traffic from my home network tc class add dev tap0 parent 1:15 classid 1:16 htb rate 700kbps ceil 700kbps -- To be applied to all traffic other than special on home network tc class add dev tap0 parent 1:15 classid 1:17 htb rate 50kbps ceil 50kbps -- To be applied to special traffic on home network tc qdisc add dev $modemif parent 1:15 handle 20: sfq perturb 10 -- I understand this to prevent high bandwidth traffic in a class from filling up the whole of the class bandwidth and allow fair sharing. Is this right/needed? tc qdisc add dev $modemif parent 1:12 handle 20: sfq perturb 10 iptables -t mangle -A POSTROUTING -o tap0 -d 192.168.50.0/24 -p tcp --sport -j CLASSIFY --set-class 1:17 iptables -t mangle -A POSTROUTING -o tap0 -d 192.168.50.4/24 -j CLASSIFY --set-class 1:16 iptables -t mangle -A POSTROUTING -o tap0 -j CLASSIFY --set-class 1:12 Thanks again for your help Oliver
Re: [gentoo-user] Traffic shaping - downstream data
More detail later...but make sure your vpn link is not TCP. UDP, fine, IP-IP, fine, but not TCP. TCP transport for a VPN tunnel leads to ugly traffic problems. On Jun 12, 2012 8:59 AM, Datty datty@gmail.com wrote: On Tue, Jun 12, 2012 at 9:58 AM, J. Roeleveld jo...@antarean.org wrote: On Mon, June 11, 2012 5:27 pm, Datty wrote: Hi all I'm looking for some help setting up traffic shaping on my internet connection. I have a bit of an odd setup in that I run a remote VPN server that all of my traffic is pushed through and out on to the internet. As I understand generally it isn't possible to shape incoming traffic but as I have control of the VPN server which pushes the traffic to me I wondered if it was possible to implement something on that side? No traffic other than the VPN tunnel goes out of my home connection. I'm trying to do this because I have a service running on one of my home machines that requires around 5kbps constantly with low latency (200ms), but as my home connection is 750kbps it gets saturated very quickly causing huge spikes in latency. Does anyone have any ideas as to how I could achieve this? Generally any pointers at all would be greatly appreciated. If VPN is the only traffic to/from your home, eg. using your internet connection and you control the VPN-server on the other side, you could limit the upstream of the remote server to your home. Thanks for your time Oliver -- Joost Thanks that makes total sense. I was looking at it backwards, not thinking that I could apply the same upstream limit to my VPN server. A bit of background/my aims - The vpn interface is 100mbps, I want everybody but me on the VPN to be able to use up to that speed, but for traffic sent to 192.168.50.0/24 to be limited to 750kbps, with 700kbps of that for normal traffic and 50kbps for my tcp traffic from port . Based on that do the following rules make sense? tc qdisc add dev tap0 root handle 1: htb default 12 -- Set the interface to be handle 1 and default traffic to be in class 1:12 tc class add dev tap0 parent 1: classid 1:1 htb rate 100mbps ceil 100mbps -- Set 100mbps to be available to all classes overall tc class add dev tap0 parent 1:1 classid 1:12 htb rate 100mbps ceil 100mbps -- Set 100mbps to be available to all people on the vpn tc class add dev tap0 parent 1:1 classid 1:15 htb rate 750kbps ceil 750kbps -- To be applied to all traffic from my home network tc class add dev tap0 parent 1:15 classid 1:16 htb rate 700kbps ceil 700kbps -- To be applied to all traffic other than special on home network tc class add dev tap0 parent 1:15 classid 1:17 htb rate 50kbps ceil 50kbps -- To be applied to special traffic on home network tc qdisc add dev $modemif parent 1:15 handle 20: sfq perturb 10 -- I understand this to prevent high bandwidth traffic in a class from filling up the whole of the class bandwidth and allow fair sharing. Is this right/needed? tc qdisc add dev $modemif parent 1:12 handle 20: sfq perturb 10 iptables -t mangle -A POSTROUTING -o tap0 -d 192.168.50.0/24 -p tcp --sport -j CLASSIFY --set-class 1:17 iptables -t mangle -A POSTROUTING -o tap0 -d 192.168.50.4/24 -j CLASSIFY --set-class 1:16 iptables -t mangle -A POSTROUTING -o tap0 -j CLASSIFY --set-class 1:12 Thanks again for your help Oliver
Re: [gentoo-user] Traffic shaping - downstream data
On Tue, Jun 12, 2012 at 2:21 PM, Michael Mol mike...@gmail.com wrote: More detail later...but make sure your vpn link is not TCP. UDP, fine, IP-IP, fine, but not TCP. TCP transport for a VPN tunnel leads to ugly traffic problems. On Jun 12, 2012 8:59 AM, Datty datty@gmail.com wrote: On Tue, Jun 12, 2012 at 9:58 AM, J. Roeleveld jo...@antarean.org wrote: On Mon, June 11, 2012 5:27 pm, Datty wrote: Hi all I'm looking for some help setting up traffic shaping on my internet connection. I have a bit of an odd setup in that I run a remote VPN server that all of my traffic is pushed through and out on to the internet. As I understand generally it isn't possible to shape incoming traffic but as I have control of the VPN server which pushes the traffic to me I wondered if it was possible to implement something on that side? No traffic other than the VPN tunnel goes out of my home connection. I'm trying to do this because I have a service running on one of my home machines that requires around 5kbps constantly with low latency (200ms), but as my home connection is 750kbps it gets saturated very quickly causing huge spikes in latency. Does anyone have any ideas as to how I could achieve this? Generally any pointers at all would be greatly appreciated. If VPN is the only traffic to/from your home, eg. using your internet connection and you control the VPN-server on the other side, you could limit the upstream of the remote server to your home. Thanks for your time Oliver -- Joost Thanks that makes total sense. I was looking at it backwards, not thinking that I could apply the same upstream limit to my VPN server. A bit of background/my aims - The vpn interface is 100mbps, I want everybody but me on the VPN to be able to use up to that speed, but for traffic sent to 192.168.50.0/24 to be limited to 750kbps, with 700kbps of that for normal traffic and 50kbps for my tcp traffic from port . Based on that do the following rules make sense? tc qdisc add dev tap0 root handle 1: htb default 12 -- Set the interface to be handle 1 and default traffic to be in class 1:12 tc class add dev tap0 parent 1: classid 1:1 htb rate 100mbps ceil 100mbps -- Set 100mbps to be available to all classes overall tc class add dev tap0 parent 1:1 classid 1:12 htb rate 100mbps ceil 100mbps -- Set 100mbps to be available to all people on the vpn tc class add dev tap0 parent 1:1 classid 1:15 htb rate 750kbps ceil 750kbps -- To be applied to all traffic from my home network tc class add dev tap0 parent 1:15 classid 1:16 htb rate 700kbps ceil 700kbps -- To be applied to all traffic other than special on home network tc class add dev tap0 parent 1:15 classid 1:17 htb rate 50kbps ceil 50kbps -- To be applied to special traffic on home network tc qdisc add dev $modemif parent 1:15 handle 20: sfq perturb 10 -- I understand this to prevent high bandwidth traffic in a class from filling up the whole of the class bandwidth and allow fair sharing. Is this right/needed? tc qdisc add dev $modemif parent 1:12 handle 20: sfq perturb 10 iptables -t mangle -A POSTROUTING -o tap0 -d 192.168.50.0/24 -p tcp --sport -j CLASSIFY --set-class 1:17 iptables -t mangle -A POSTROUTING -o tap0 -d 192.168.50.4/24 -j CLASSIFY --set-class 1:16 iptables -t mangle -A POSTROUTING -o tap0 -j CLASSIFY --set-class 1:12 Thanks again for your help Oliver Ah it is TCP at the moment. Not something I could change too easily either. Is it possible to work around or is it not worth fighting with?
Re: [gentoo-user] Issues with =x11-drivers/xf86-video-ati-6.14.4: driver issue or hardware issue?
On Thu, 7 Jun 2012 16:18:02 +0200 Michael Scherer a6702...@unet.univie.ac.at wrote: On Thu, 7 Jun 2012 04:52:35 -0400 Andrey Moshbear andrey@gmail.com wrote: On Tue, Jun 5, 2012 at 11:41 AM, Michael Scherer a6702...@unet.univie.ac.at wrote: On Fri, 1 Jun 2012 04:11:35 -0400 Andrey Moshbear andrey@gmail.com wrote: On Wed, May 23, 2012 at 11:12 AM, Michael Scherer a6702...@unet.univie.ac.at wrote: - Original Message - From: Andrey Moshbear andrey@gmail.com To: gentoo-user gentoo-user@lists.gentoo.org Sent: Tuesday, 22 May, 2012 08:02 Subject: [gentoo-user] Issues with =x11-drivers/xf86-video-ati-6.14.4: driver issue or hardware issue? Lately, I've been having some issues with segfaults when running startx and it's been pretty persistent. Xorg.0.log and emerge --info are available at https://gist.github.com/2766926 . Kernel config is available at https://gist.github.com/276943 . I've tried downgrading, but =x11-drivers/xf86-video-ati-6.14.2 fails to compile due to incomplete structs. Is this more a driver or a hardware issue? first thing thing is your usage of ACCEPT_KEYWORDS=amd64 ~amd64. with ~amd64 you globally allow all packages masked for amd64. unless you are a developer/tester for gentoo you should remove this keyword, because gentoo usually has good reasons to mask some packages. if for some reason you really need a masked package, you can do this easily only for that package. global unmasking alone might be the reason for half of your troubles. second, it is advisable to use kernel modesetting, which is obviously not enabled. gentoo has a detailed howto for this under http://www.gentoo.org/doc/en/xorg-config.xml. this gives you all necessary details. just a quick shot for the moment. your kernel config doesn't under the link you give, I'd like to see that too, and maybe /etc/X11/xorg.conf or the contents of /etc/X11/xorg.conf.d, if you have any of these, regards, nichael Well, I added radeon drm modesetting and the kernel is crashing right after the microcode is loaded, but without any signs of panic, be it flashing keyboard lights or kernel backtrace with register values. Also, the segfault was caused by the DRI code interpreting a DRI opcode as a pointer, hence 0xa4 or similar in the back trace. -- m0shbear in any case, I'd need some more information: the link to your .config is broken, I only get an empty page. if the kernel is involved, output of dmesg and rc.log would be needed to. by the way, did you anything with your ACCEPT_KEYWORDS? if not, the best thing would be set it simply = (and afterwards --update world, --depclean and revdep-rebuild), but that's up to you. please send me the requested information, otherwise it's difficult to find out what's wrong. Also, I've noticed that that radeon.ko autodetection configures it as a RS780, whereas, according to motherboard documentation, it should be RS880 (780G vs 785G). This may be a reason for crashing, since the video card dies due to being supplied bad microcode. according to the gentoo manual, under device drivers-graphics- support for framebufferdevices you should uncheck -everything- except enable video mode handling helpers. instead of uvesafb in the kernel parameters you may use radeondrmfb, if anything at all. from the Xorg radeon page: First of all check that you don't load radeonfb, uvesafb or vesafb module. This includes no vga parameters for kernel when using KMS. Console is provided by fbcon and radeondrmfb frame buffer console. So it is best to make sure that fbcon module is loaded disabling vesa also should rid you of uvesa messages in Xorg.0.log. the rs880 and configuring as rs780 is indeed probably at the root of your troubles. seems that you got the wrong firmware. I have found other postings with the exact same problem, but as yet no clear solution. I'll see what I can find and let you know. regards, michael if you haven't solved your problem already, there are two possibilities you coud try: one is using the Radeon R600-family RLC microcode: radeon/R600_rlc.bin (without something else). this should include the rs880. another option might be to download firmware-linux-nonfree from http://packages.debian.org/de/squeeze/firmware-linux-nonfree some people seem to have used it successfully, but I don't know if it works on gentoo. sorry that I can only guess on this, not having an rs880 myself. isn't someone on gentoo users with a similar configuration who could give you better advice? regards, michael
Re: [gentoo-user] Traffic shaping - downstream data
On Tue, Jun 12, 2012 at 9:37 AM, Datty datty@gmail.com wrote: On Tue, Jun 12, 2012 at 2:21 PM, Michael Mol mike...@gmail.com wrote: On Jun 12, 2012 8:59 AM, Datty datty@gmail.com wrote: [snip] More detail later...but make sure your vpn link is not TCP. UDP, fine, IP-IP, fine, but not TCP. TCP transport for a VPN tunnel leads to ugly traffic problems. Ah it is TCP at the moment. Not something I could change too easily either. Is it possible to work around or is it not worth fighting with? If all of these cases are true: * You only have TCP traffic going over that VPN * You don't have any latency-sensitive traffic going over that VPN (no VOIP, no interactive terminal sessions and you won't pull your hair out over 10s or more round-trips slowing down page loads) * You don't have large bulk data transfers going over that VPN (my best example of personal experience here was trying to locally sync my work-related IMAP mailbox) ...then it's not worth fighting with. It's very unlikely you fall in that camp. The problem of TCP VPN transport is a confluence of three issues: 1) You're likely to have packet loss underneath that transport due to things like congestion...the TCP transport will hide this from tunneled traffic and retransmit itself. 2) In TCP, Nagle's Algorithm handles flow throttling, but it depends on detecting packet loss to limit how many packets it pushes. 3) Your VPN endpoint will very probably buffer a very large amount of data for sending if its TCP transport link is acting slow. Here's what happens: 1) Your TCP app on your computer opens a connection with a remote host. This connection is encapsulated inside your TCP OpenVPN tunnel. 2) Your app's TCP connection starts exchanging data. For as long as it's not losing any packets, it figures it can send more and more data without waiting for a response; this is Nagle's Algorithm managing your TCP sliding window, and it's why TCP can scale from dial-up speeds up to 10g ethernet. 3) Your VPN link's TCP connection experiences packet loss. Maybe it's because of a congested router between you and the remote side of the VPN, or maybe it's because someone's ADSL connection is pushing more than its measly 768Kb/s upstream speed allows for. Or maybe it's noise on the copper causing packet loss on the ADSL link. Or maybe it's a frame collision on the PPoE link. ...time passes... 4) Your VPN link's TCP stack notes the packet loss and retransmits the lost packet until the packet gets through. 5) The connection traffic from step (2) is completely unaware that the VPN's TCP connection is fielding packet loss issues for it, and Nagle's Algorithm figures, 'hey, this is a high-bandwith link! Let's shove more data!' 6) OpenVPN link is now receving data it can't stuff into the pipe right this second, so it buffers it for a moment, and then sends it when its turn has come. Still, no data is lost. ...time passes... 7) Steps 4-6 repeat themselves, causing your original connection to become more and more confident about the bandwidth of the pipe. ...time passes... 8) The connection from step 2 is now so confident of the connection speed of the pipe, it's pushing data to OpenVPN faster than OpenVPN could conceivably push out, even if there were no packet loss issues. You've now got a cycle of just steps 5 and 6. Presumably, you'd eventually hit OpenVPN's buffer limit. I don't know what that is, and I don't think it's tuneable. The one time I personally saw, measured and helped diagnose this, I was getting up to a *fifteen minute* round-trip ping time over the VPN, even though the round-trip time for ping outside the VPN between the VPN endpoints was only about 100ms. Watching that round-trip time climb was surreal until I figured out what was happening. Switching the VPN transport to UDP allowed the tunneled connections' TCP stacks to properly gauge and react to available throughput. Even SIP started working over that VPN link. -- :wq
[gentoo-user] Can't get any microphone to work
Damn! I've been all morning struggling with this. I have an analog microphone wired to my hda intel onboard sound card. Also, I have a genius webcam (gspca_pac7302) with a builtin mic. I tried arecord but couldn't capture anything from any of it, so I guess I'm doing something wrong. But what? Below is arecord list output. Is arecord appropriate for this test or there is another tool I can grab? Thanks! Ezequiel. localhost ~ # arecord -l List of CAPTURE Hardware Devices card 0: SB [HDA ATI SB], device 0: ALC887 Analog [ALC887 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: SB [HDA ATI SB], device 1: ALC887 Digital [ALC887 Digital] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: SB [HDA ATI SB], device 2: ALC887 Analog [ALC887 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 localhost ~ # arecord -L null Discard all samples (playback) or generate zero samples (capture) default:CARD=SB HDA ATI SB, ALC887 Analog Default Audio Device front:CARD=SB,DEV=0 HDA ATI SB, ALC887 Analog Front speakers surround40:CARD=SB,DEV=0 HDA ATI SB, ALC887 Analog 4.0 Surround output to Front and Rear speakers surround41:CARD=SB,DEV=0 HDA ATI SB, ALC887 Analog 4.1 Surround output to Front, Rear and Subwoofer speakers surround50:CARD=SB,DEV=0 HDA ATI SB, ALC887 Analog 5.0 Surround output to Front, Center and Rear speakers surround51:CARD=SB,DEV=0 HDA ATI SB, ALC887 Analog 5.1 Surround output to Front, Center, Rear and Subwoofer speakers surround71:CARD=SB,DEV=0 HDA ATI SB, ALC887 Analog 7.1 Surround output to Front, Center, Side, Rear and Woofer speakers iec958:CARD=SB,DEV=0 HDA ATI SB, ALC887 Digital IEC958 (S/PDIF) Digital Audio Output
Re: [gentoo-user] Traffic shaping - downstream data
On Tue, Jun 12, 2012 at 11:06 AM, Michael Mol mike...@gmail.com wrote: On Tue, Jun 12, 2012 at 9:37 AM, Datty datty@gmail.com wrote: On Tue, Jun 12, 2012 at 2:21 PM, Michael Mol mike...@gmail.com wrote: On Jun 12, 2012 8:59 AM, Datty datty@gmail.com wrote: [snip] More detail later...but make sure your vpn link is not TCP. UDP, fine, IP-IP, fine, but not TCP. TCP transport for a VPN tunnel leads to ugly traffic problems. Ah it is TCP at the moment. Not something I could change too easily either. Is it possible to work around or is it not worth fighting with? If all of these cases are true: * You only have TCP traffic going over that VPN * You don't have any latency-sensitive traffic going over that VPN (no VOIP, no interactive terminal sessions and you won't pull your hair out over 10s or more round-trips slowing down page loads) * You don't have large bulk data transfers going over that VPN (my best example of personal experience here was trying to locally sync my work-related IMAP mailbox) ...then it's not worth fighting with. I could stand to be more precise and concise: If you're going to use a TCP transport for VPN: * You need to not mix TCP and UDP traffic * You need to not have latency-sensitive traffic. In practice, you'll almost always have some UDP traffic; that's how DNS generally operates. And even where DNS uses TCP, it's still latency-sensitive. So I can be even more concise: If you're going to use a TCP transport for VPN, you must avoid having TCP traffic over that VPN link. -- :wq
Re: [gentoo-user] Re: Adding a use flag: hwdb
On 06/12/12 05:45, Chris Stankevitz wrote: On Tuesday, June 12, 2012, Neil Bothwick wrote: you really shouldn't complain about being given choices... I apologize, it was no my intention to complain. In the future I will make a decision and not complain. Thank you to everyone for your assistance! No one is forced to reply, so I say complain away =)
Re: [gentoo-user] Can't get any microphone to work
On Tue, Jun 12, 2012 at 8:32 AM, Ezequiel Garcia elezegar...@gmail.com wrote: Damn! I've been all morning struggling with this. I have an analog microphone wired to my hda intel onboard sound card. Also, I have a genius webcam (gspca_pac7302) with a builtin mic. I have on-going problems with the mic on my system also. Alsa always sets the mic controls I need back to 0 and won't ever save what I was using. Each time I need the mic I have to enable 3 settings in KDE mixer. (which also exist in Alsamixer if you prefer to use that tool - hit F4 once in it) --- Front Mic - turn it on. My system has 4 settings. I raise it by one click at least. Note that in KDE I must grab the one on the right. The one on the left won't raise the pair. Alsamixer only shows one control. --- Capture - turn it up to 80% or so --- Digital - turn it up to 80% or so These settings work for me but Alsa won't save them on my system like it save headphone/PCM/Master settings so I have to turn them on by hand every time.. HTH, Mark
[gentoo-user] [PATCH] Using ati-drivers with kernel 3.5
Like the last time, this patch is an ugly hack and it needs
a professional touch before any sane dev would take it seriously.
But here it is anyway :)
BTW, I replaced for_each_cpu_mask because I still haven't learned
the correct syntax for it. The number 4 is the number of cpus in
this particular machine. You should use the correct number for your
machine, obviously.
--- firegl_public.c.orig2012-06-12 11:15:38.025293759 -0700
+++ firegl_public.c 2012-06-12 12:02:11.463348365 -0700
@@ -2120,9 +2120,9 @@
flags = MAP_SHARED;
prot = PROT_READ|PROT_WRITE;
-down_write(current-mm-mmap_sem);
-vaddr = (void *) do_mmap(file, 0, len, prot, flags, pgoff);
-up_write(current-mm-mmap_sem);
+//down_write(current-mm-mmap_sem);
+vaddr = (void *) vm_mmap(file, 0, len, prot, flags, pgoff);
+//up_write(current-mm-mmap_sem);
if (IS_ERR(vaddr))
return 0;
else
@@ -2133,18 +2133,18 @@
{
int retcode = 0;
-down_write(current-mm-mmap_sem);
+//down_write(current-mm-mmap_sem);
#ifdef FGL_LINUX_RHEL_MUNMAP_API
-retcode = do_munmap(current-mm,
+retcode = vm_munmap(
addr,
len,
1);
#else
-retcode = do_munmap(current-mm,
+retcode = vm_munmap(
addr,
len);
#endif
-up_write(current-mm-mmap_sem);
+//up_write(current-mm-mmap_sem);
return retcode;
}
@@ -4156,7 +4156,7 @@
{
unsigned int p;
KCL_DEBUG5(FN_FIREGL_KAS, %d\n, level_init);
-for_each_cpu_mask(p, cpu_possible_map)
+for(p=0;p4;p++)
{
KCL_DEBUG1(FN_FIREGL_KAS,Setting initial execution level for CPU #
%d\n, p);
preempt_disable();
Re: [gentoo-user] Traffic shaping - downstream data
On Tue, Jun 12, 2012 at 5:05 PM, Michael Mol mike...@gmail.com wrote: On Tue, Jun 12, 2012 at 11:06 AM, Michael Mol mike...@gmail.com wrote: On Tue, Jun 12, 2012 at 9:37 AM, Datty datty@gmail.com wrote: On Tue, Jun 12, 2012 at 2:21 PM, Michael Mol mike...@gmail.com wrote: On Jun 12, 2012 8:59 AM, Datty datty@gmail.com wrote: [snip] More detail later...but make sure your vpn link is not TCP. UDP, fine, IP-IP, fine, but not TCP. TCP transport for a VPN tunnel leads to ugly traffic problems. Ah it is TCP at the moment. Not something I could change too easily either. Is it possible to work around or is it not worth fighting with? If all of these cases are true: * You only have TCP traffic going over that VPN * You don't have any latency-sensitive traffic going over that VPN (no VOIP, no interactive terminal sessions and you won't pull your hair out over 10s or more round-trips slowing down page loads) * You don't have large bulk data transfers going over that VPN (my best example of personal experience here was trying to locally sync my work-related IMAP mailbox) ...then it's not worth fighting with. I could stand to be more precise and concise: If you're going to use a TCP transport for VPN: * You need to not mix TCP and UDP traffic * You need to not have latency-sensitive traffic. In practice, you'll almost always have some UDP traffic; that's how DNS generally operates. And even where DNS uses TCP, it's still latency-sensitive. So I can be even more concise: If you're going to use a TCP transport for VPN, you must avoid having TCP traffic over that VPN link. -- :wq Thank you for that very thorough explanation, I had no idea there was a problem with using TCP, I figured the error correction would help it be more stable than just throwing data at it and hoping it got there. Somehow I've avoided the majority of the issues you've mentioned up to now, but then again generally my connection is very slow so maybe I'm just not feeling the effects. My ping however is around 40ms higher over the VPN link so I'm guessing that may be a sign. I'll set up a second vpn tunnel using UDP to test it out, my resistance to changing the main one is purely down to the fact that I have around 30 clients, probably half of which would reach for antiseptic if I mentioned TCP and I don't fancy having to drive 200+ miles to each of them to change it for them. I'll give it a shot tomorrow and report back on how it gets on. Regarding the tc rules I mentioned, do they look alright? I'm not 100% on how it all goes together still and would appreciate a prod in the right direction. Thanks again Oliver
Re: [gentoo-user] Traffic shaping - downstream data
On Tue, Jun 12, 2012 at 4:43 PM, Datty datty@gmail.com wrote: On Tue, Jun 12, 2012 at 5:05 PM, Michael Mol mike...@gmail.com wrote: On Tue, Jun 12, 2012 at 11:06 AM, Michael Mol mike...@gmail.com wrote: On Tue, Jun 12, 2012 at 9:37 AM, Datty datty@gmail.com wrote: On Tue, Jun 12, 2012 at 2:21 PM, Michael Mol mike...@gmail.com wrote: On Jun 12, 2012 8:59 AM, Datty datty@gmail.com wrote: [snip] More detail later...but make sure your vpn link is not TCP. UDP, fine, IP-IP, fine, but not TCP. TCP transport for a VPN tunnel leads to ugly traffic problems. Ah it is TCP at the moment. Not something I could change too easily either. Is it possible to work around or is it not worth fighting with? If all of these cases are true: * You only have TCP traffic going over that VPN * You don't have any latency-sensitive traffic going over that VPN (no VOIP, no interactive terminal sessions and you won't pull your hair out over 10s or more round-trips slowing down page loads) * You don't have large bulk data transfers going over that VPN (my best example of personal experience here was trying to locally sync my work-related IMAP mailbox) ...then it's not worth fighting with. I could stand to be more precise and concise: If you're going to use a TCP transport for VPN: * You need to not mix TCP and UDP traffic * You need to not have latency-sensitive traffic. In practice, you'll almost always have some UDP traffic; that's how DNS generally operates. And even where DNS uses TCP, it's still latency-sensitive. So I can be even more concise: If you're going to use a TCP transport for VPN, you must avoid having TCP traffic over that VPN link. -- :wq Thank you for that very thorough explanation, I had no idea there was a problem with using TCP, I figured the error correction would help it be more stable than just throwing data at it and hoping it got there. Somehow I've avoided the majority of the issues you've mentioned up to now, but then again generally my connection is very slow so maybe I'm just not feeling the effects. My ping however is around 40ms higher over the VPN link so I'm guessing that may be a sign. I'll set up a second vpn tunnel using UDP to test it out, my resistance to changing the main one is purely down to the fact that I have around 30 clients, probably half of which would reach for antiseptic if I mentioned TCP and I don't fancy having to drive 200+ miles to each of them to change it for them. I'll give it a shot tomorrow and report back on how it gets on. Regarding the tc rules I mentioned, do they look alright? I'm not 100% on how it all goes together still and would appreciate a prod in the right direction. Thanks again I'd suggest setting up that second VPN link for parallel use, get all the clients up on that one (can you remote admin?), and then take down the old one once the TCP link is no longer actively used. You should be able to do it pretty seamlessly. Regarding the tc rules...no idea off the top of my head. I think when I first saw them I had more questions about topology, but I don't have time to grok it again today. -- :wq
Re: [gentoo-user] Can't get any microphone to work
Hello! On Tue, 12 Jun 2012 12:32:43 -0300 Ezequiel Garcia elezegar...@gmail.com wrote: Damn! I've been all morning struggling with this. I have an analog microphone wired to my hda intel onboard sound card. Also, I have a genius webcam (gspca_pac7302) with a builtin mic. I tried arecord but couldn't capture anything from any of it, so I guess I'm doing something wrong. But what? ... My personal experience shows me that most of the time all the silence in mic is because of the muted (or very too quiet) or wrong selected recording device. I prefer to check this in 'alsamixer'. If you have several microphones on your PC, there should be a possibility to choose the device to record the sound from (on my system there are 'Line', 'Internal Mic' and 'Mic' options). If you choose a correct device, then check if it is not muted as well (a symbol 'M' in Alsamixer means 'muted'). If the device you need is un-muted, then raise the volume level (or maybe 'Mic Boost' as well). If none of the above helps, then perhaps your device wasn't properly set up. You need to specify you soundcard model by hand in some cases. For example, on my laptop I added the string options snd-hda-intel model=targa-8ch-dig to the file '/etc/modprobe.d/alsa.conf' and rebooted, after which I got an access to all of the features of my soundcard. Hope this helps. Regards, Vladimir - v...@ukr.net
Re: [gentoo-user] Can't get any microphone to work
On Tue, Jun 12, 2012 at 6:33 PM, v...@ukr.net wrote: Hello! On Tue, 12 Jun 2012 12:32:43 -0300 Ezequiel Garcia elezegar...@gmail.com wrote: Damn! I've been all morning struggling with this. I have an analog microphone wired to my hda intel onboard sound card. Also, I have a genius webcam (gspca_pac7302) with a builtin mic. I tried arecord but couldn't capture anything from any of it, so I guess I'm doing something wrong. But what? ... My personal experience shows me that most of the time all the silence in mic is because of the muted (or very too quiet) or wrong selected recording device. I prefer to check this in 'alsamixer'. If you have several microphones on your PC, there should be a possibility to choose the device to record the sound from (on my system there are 'Line', 'Internal Mic' and 'Mic' options). If you choose a correct device, then check if it is not muted as well (a symbol 'M' in Alsamixer means 'muted'). If the device you need is un-muted, then raise the volume level (or maybe 'Mic Boost' as well). This was exactly the case. Some alsamixer tweaking was needed. Strangely, I needed to change Channel mode from 6 ch to 2 ch for my intel-hda soundcard. I still can't get the webcam mic to work :-( Thanks a lot!
[gentoo-user] Re: Can't get any microphone to work
On 06/12/2012 03:05 PM, Ezequiel Garcia wrote: Strangely, I needed to change Channel mode from 6 ch to 2 ch for my intel-hda soundcard. I still can't get the webcam mic to work :-( Are you running pulseaudio, and do you have the pulseaudio USEFLAG set? If yes, /etc/pulse/default.pa has a variable set-default-source that might be of interest. I have no idea what you should set it to, though. Running pactl list might give you a hint about how to fix it.
