[01:05] <undriedsea> /proc/[pid]/maps question: How is it possible to have a mapping where the size of the shared library referenced by path is SMALLER than the mapped range? Example:
[01:05] <undriedsea> 7f6a9e61f000-7f6a9e81e000 ---p 0000c000 08:01 269062  /lib/x86_64-linux-gnu/libnss_files-2.13.so
[01:05] <undriedsea> Acutal File Length:  51728 (from "ls -la /lib/x86_64-linux-gnu/libnss_files-2.13.so")
[01:05] <undriedsea> Specd Offset:        49152 (0000c000)
[01:05] <undriedsea> Range End - Start: 2093056
[01:05] <undriedsea> ....so confused....
=== smb` is now known as smb
[08:30]  * smb comes in
[08:48]  * apw yawns
[08:49]  * smb gives apw some aspirin
=== bladernr_afk is now known as bladernr_
[08:58] <apw> actually my head is pretty much ok today :)
[08:58] <smb> apw, Good to hear. :) I hope it does not mean that some other part hurts. ;)
[08:59] <apw> heh
[09:00]  * smb turns on his hoover
=== jibel_ is now known as jibel
[10:38] <apw> (( arch armel | arch armhf ) & value CONFIG_FAT_FS y) | \
[10:39] <apw>         !arch armel & !arch armf & value CONFIG_FAT_FS m 
[10:39] <ubot2> apw: Error: I am only a bot, please don't think I'm intelligent :)
[10:39] <apw> (( arch armel | arch armhf ) & cut & value CONFIG_FAT_FS y) | \
[10:39] <apw>         value CONFIG_FAT_FS m
[10:41] <apw> arch armel armhf & value CONFIG_FAT_FS y | \
[10:41] <apw>         !arch armel armhf & value CONFIG_FAT_FS m
[10:41] <cking> arch(armel, armhf)
[10:41] <ubot2> apw: Error: I am only a bot, please don't think I'm intelligent :)
[10:42] <cking> arch[armel, armhf]
[10:48] <apw> arch armel armhf : value CONFIG_FAT_FS_Y | \
[10:48] <apw>         value CONFIG_FAT_FS
[11:01] <cking> apw:  powers_of_2 = [ n | n <- 1, 2*n .. ]
[11:02] <cking>  reciprocal = (1 /)
[11:03] <apw> reciproval 2
[11:05] <cking>  add a b = a + b
[11:05] <apw> 10 add 20
[11:05] <apw> add 10 20 
[11:06] <smb> 10 20 add? :)
[11:06] <apw> Q a b = a + b
[11:06] <apw> a Q B
[11:06] <apw> recip = / 1
[11:07] <apw> /+* 1 2 3 4
[11:08] <smb> 1 2 / 3 + 4 *...
[11:29]  * ppisati -> reboot
[11:47] <apw> ogasawara, just a heads up that those 4 ext4 patches have hit mainline so will collide with my fix in the next rebase; dropping mine is appropriate in response
=== bladernr_ is now known as bladernr_afk
[12:23]  * ppisati -> lunch
=== jk-- is now known as jk-
=== yofel_ is now known as yofel
[14:05] <ogasawara> apw: ack
[14:06] <ogasawara> apw: would you prefer if I just cherry-pick them before we rebase?  I'm probably gonna upload today or tomorrow.
[14:08] <apw> ogasawara, we may as well have the new ones in any upload you do yes
[14:08] <apw> if thats not going to be a rebase, then sure
[14:09] <apw>       ext4: handle EOF correctly in ext4_bio_write_page()
[14:09] <apw>       ext4: remove a wrong BUG_ON in ext4_ext_convert_to_initialized
[14:09] <apw>       ext4: correctly handle pages w/o buffers in ext4_discard_partial_b
[14:09] <apw>       ext4: avoid potential hang in mpage_submit_io() when blocksize < p
[14:09] <apw> ogasawara, those are the new names for the four we needed i believe
[14:10] <ogasawara> apw: thanks.  I'll go ahead and pick those and drop the sauce
[14:11] <tgardner> ogasawara, you might as well just rebase against tip, then just note the SHA1 in the changelog.
[14:12] <ogasawara> tgardner: makes sense.  will do that.
=== bladernr_afk is now known as bladernr_
[14:38] <brendand> herton - oneiric looking pretty close to verification. done today?
[14:39] <brendand> herton - i can do http://launchpad.net/bugs/813146
[14:39] <ubot2> Launchpad bug 813146 in linux "kernel panic when running Python test suite on ecryptfs" [Critical,Fix committed]
[14:39] <kirkland> brendand: that would be great!
[14:40] <brendand> just need someone to do http://launchpad.net/bugs/886521
[14:40] <ubot2> Launchpad bug 886521 in linux "CONFIG_XEN_PLATFORM_PCI should be "y" when building 3.1 kernel" [Medium,Fix committed]
[14:40] <herton> brendand, yes, looks like it can happen today, only two remaining, including this one
[14:40] <brendand> i haven't a clue for that one
[14:41] <herton> brendand, I'll take a look at it, checking the config is changed is enough
[14:41] <herton> in fact it's already verified
[14:41] <herton> so only 813146 remaining
[14:42] <brendand> herton - great. i'm downloading oneiric now. maybe someone can beat me too it
[14:43] <tgardner> apw, have you seen these yet? https://pastebin.canonical.com/57207/
[14:46] <GodManMonkey> anyone have any ideas how to get usb wireless adapter working 10.04 lts?
[14:46] <ohsix> plug it in
[14:46] <GodManMonkey> lol tried that
[14:47] <GodManMonkey> also tried setting up with ndiswrapper and ndisgtk...
[14:49] <ogasawara> tgardner: https://lkml.org/lkml/2011/12/5/421
[14:51] <tgardner> ogasawara, good catch. I'll hassle the fs-devel list.
[14:52] <tgardner> ogasawara, why don't you add that as a crack patch in the meantime. it looks right.
[14:52] <ogasawara> tgardner: ack
[14:53] <ogasawara> tgardner: was that reported in a LP bug that you want me to add to the commit message?
[14:53] <tgardner> ogasawara, pgraner has some machines that show this bug. I'll get him or patrick to start one.
[14:58] <pgraner> tgardner, on it
[15:09]  * herton -> lunch
[15:34]  * ogasawara back in 20
[15:43] <pgraner> ogasawara, tgardner, just booted the daily from today and the panic doesn't exist, only seems to exist in the installer kernel?
[15:44] <tgardner> pgraner, its not a panic, its a warning. Are there arch or version differences between the 2 ?
[15:46] <pgraner> tgardner, uname -a is telling me they are the same, why would booting from pxe cause it and not from USB?
[15:47] <tgardner> perhaps differences in how initrd hunts for the root FS ? I'm not sure.
[15:49] <tgardner> a PXE booted kernel has no idea what block devices exists, or what has a bootable partition, and has to go looking. when booting from USB I think it already knows.
[15:56] <tgardner> pgraner, if it only happens with the installer, then that WARNING is not having an impact on the boot speed tests, right ?
[16:00] <pgraner> tgardner, yep
[16:00] <tgardner> pgraner, yep, as in 'no impact' ?
[16:00] <pgraner> tgardner, that would be my assumption since we have to reboot twice to profile the ureadahead cache
=== bladernr_ is now known as bladernr_afk
[16:01] <pgraner> tgardner, I'll let you know if we see it in the dmesg after the first run today
[16:01] <tgardner> pgraner, ok, then its not a balls on emergency just yet.
[16:01] <pgraner> tgardner, that is post install
[16:01] <pgraner> tgardner, ack on that
[16:02] <tgardner> pgraner, I've bugged upstream about it.
[16:03] <tgardner> pgraner, plus ogasawara is gonna carry a crack patch until we get something official.
[16:03] <ogasawara> tgardner: yep, am prepping the upload right now
[16:08] <tgardner> ogasawara, did you have a look at cyphermox ipv6 patch on the list ?
[16:08] <ogasawara> tgardner: ah shoot, meant to take a look this morning
=== davmor2_ is now known as davmor2
[16:09] <tgardner> ogasawara, its not an emergency, so don't derail your upload for it 
[16:10] <ogasawara> tgardner: ack, will finish with the upload and then get to it
[16:23] <brendand> hmm, why wouldn't i be able to reproduce http://launchpad.net/bugs/813146 ?
[16:23] <ubot2> Launchpad bug 813146 in linux "kernel panic when running Python test suite on ecryptfs" [Critical,Fix committed]
[16:23] <brendand> i have an encrypted home. any other requirements?
[16:24] <tgardner> brendand, it was probably a race that is hard to hit. cking was able to trigger it on older kernels, but current upstream seems to have fixed it.
[16:24] <tyhicks> brendand: Yes, it is a race that is not always easy to trigger
[16:25] <tgardner> brendand, read https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/813146/comments/51
[16:25] <ubot2> Launchpad bug 813146 in linux "kernel panic when running Python test suite on ecryptfs" [Critical,Fix committed]
[16:25]  * tyhicks was just going to point that out
[16:25] <brendand> tyhicks -yep, looks like barry just verified it. great!
[16:26] <tyhicks> I know barry could trigger it everytime, so I'm thinking we're good if he can't trigger it
[16:26] <brendand> herton - so there is no respin of oneiric then (just to make sure). everything succesfully verified?
[16:26] <bjf> brendand, so that oneiric kernel is ready for testing
[16:27] <bjf> brendand, we are investigating a suspend/resume bug that came in today
[16:27] <brendand> bjf - ok. how long you want to give it?
[16:28] <bjf> brendand, i'd like you to start testing right now :-)
[16:28] <brendand> bjf - what's going to happen with the sus/res bug then?
[16:28] <brendand> bjf - what if it's a real regression?
[16:29] <bjf> brendand: we will work on it
[16:29] <brendand> bjf - which bug btw?
[16:29] <bjf> brendand, that is always the possibility
[16:30] <bjf> bug 904569
[16:30] <ubot2> Launchpad bug 904569 in linux "Linux 3.0.0-15-generic-pae causes laptops to fail to resume from suspend (Dell XPS 1645, Sony Vaio VPCF1390)" [Undecided,Confirmed] https://launchpad.net/bugs/904569
[16:31] <bjf> brendand, for *any* -proposed kernel that you are testing, we could be looking at bugs that come is as possible regressions, that doesn't mean we stop testing
[16:33] <brendand> bjf - i was just going to see if it's something we could check out. we'll start testing then
[16:51] <tgardner> cking, 'if ((!a) ^ (!b))' is the same as ' if (a != b)' right ?
[16:53] <tgardner> no, thats not quite right
[16:54] <cking> hrm, depends if a b are just 0,1
[16:54] <tgardner> cking, a and b can be arbitrary values.
[16:54] <tgardner> so, what is the intent of that kind of expression ?
[16:54] <cking> where is the code?
[16:55] <tgardner> cking, its on the k-team mailing list in the ipv6 patch
[16:55] <cking> that expression works if a,b are just 0,1 I believe
[16:56] <smb> No, don't think so
[16:56] <tgardner> cking, I think it must be  acopy/paste thing that he picked up from elsewhere. 
[16:56] <cking> ((!*p) ^ (!old))
[16:56] <smb> a = 0 -> 1 / a != 0 -> 0
[16:56] <tgardner> yep
[16:57] <tgardner> I think what he really wants is 'if (*p != old)'
[17:01] <cking> it's not clear. me rethinks again
[17:02] <smb> So what it currently does is if not both of them are NULL and not both are not NULL, isn't it...?
[17:04] <cking> if (( *p & !old) || ( !*p & old))
[17:04] <cking> i think
[17:05] <sforshee> cking, I think you want && instead of &
[17:05] <smb> if ( (*p == NULL & old != NULL) || (*p != NULL & old == NULL))
[17:05] <cking> sforshee, yep &&
[17:06] <sforshee> basically, if one is zero and the other is nonzero, execute the body
[17:06] <cking> smb, old is not a ptr 
[17:06] <smb> yeah, sounds right
[17:06] <smb> cking, Oh, right
[17:06] <smb> basically both are not
[17:07] <tgardner> sforshee, that only works if the inputs are 0 or 1. what if the user supplies a number > 1 ?
[17:07] <smb> cking, So yours is right, beside the && which I was trying to remember wheter its only in shell or c as well
[17:07] <sforshee> tgardner, it's converting both to either 0 or 1 with the !'s
[17:07] <smb> tgardner, ! is always 0 or 1
[17:07] <tgardner> sforshee, ah, right.
[17:08] <cking> that's why the !!val trick works 
[17:08] <cking> (from a different context)
[17:09] <cking> using ^ like that is a very succinct way of expressing that condition. nice
[17:10] <smb> yeah, but then taking long to decipher again
[17:10] <tgardner> here is the truth table for 0,1,2:
[17:10] <tgardner> i=0 j=0 ((!0) ^ (!0))=FALSE
[17:10] <tgardner> i=0 j=1 ((!0) ^ (!1))=TRUE
[17:10] <tgardner> i=0 j=2 ((!0) ^ (!2))=TRUE
[17:10] <tgardner> i=1 j=0 ((!1) ^ (!0))=TRUE
[17:10] <tgardner> i=1 j=1 ((!1) ^ (!1))=FALSE
[17:10] <tgardner> i=1 j=2 ((!1) ^ (!2))=FALSE
[17:11] <tgardner> i=2 j=0 ((!2) ^ (!0))=TRUE
[17:11] <tgardner> i=2 j=1 ((!2) ^ (!1))=FALSE
[17:11] <tgardner> i=2 j=2 ((!2) ^ (!2))=FALSE
[17:11] <tgardner> so I guess its correct. 
[17:12] <cking> wonder if that code is on a critical path (speed-wise) and if the compiler can't generate code that optimises it down to the ^ operator, then I suspect it makes sense
[17:12] <tgardner> cking, its asysctl
[17:12] <tgardner> a sysctl
[17:12] <cking> which case it's just a smart alec bit of logic
[17:13] <cking> the kind of spawn from MIT bithack ;-)
[17:14] <tgardner> cking, why not just do 'ret = !!proc_dointvec(ctl, write, buffer, lenp, ppos);'
[17:14] <tgardner> it would simplify everything else
[17:14] <tgardner> oh, never mind. thats the wrong place.
[17:15] <cking> -ETOOMUCHBEER?
[17:16] <tgardner> not yet. I wish...
[17:25]  * cking downloads the kernel .ddeb - only 653MB.. :-(
[17:26] <tgardner> cking, isn't this where BT squeezes you down to 1kbit ?
[17:27] <cking> tgardner, nah, plenty of bits left today. yesterday was bad, my daughter was off ill and downloaded Gigs of video-on-demand content and rate capped us until midnight
[17:31] <arges> smb, hello! i've been going though some bugs and found this xen issue: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/838177  . Was wondering if you've seen any updates in upstream that may help this, or have an suggestions on new tests or actions.
[17:31] <ubot2> Launchpad bug 838177 in linux "[Lucid] New version of kernel cannot do migration between two XenServers" [Medium,Triaged]
[17:33] <smb> arges, That was one of the bugs related to forcing certain irqs to resume early... It required an additional backport which came through stable...
[17:33] <smb> arges, IRQF_FORCE... is the keyword to look for. I would think it should be working at least in proposed now
[17:34] <arges> smb, ok i'll check 
[17:34] <smb> genirq: Add IRQF_RESUME_EARLY and resume such IRQs earlier
[17:35] <smb> Ubuntu-2.6.32-37.80
[17:35] <smb> bug 897377
[17:35] <ubot2> Launchpad bug 897377 in linux "Lucid update to 2.6.32.49 stable release" [Undecided,Fix committed] https://launchpad.net/bugs/897377
[17:36] <smb> bug 881542
[17:36] <ubot2> Launchpad bug 881542 in linux "Ubuntu 10.04 LTS as guest freezes after xm restore" [Medium,Fix committed] https://launchpad.net/bugs/881542
[17:36] <arges> you are quicker than I am : ) . Ok I'll have louis re-test with latest then
[17:37] <arges> smb, lucid-proposed right?
[17:37] <smb> arges, Thanks. :) Probably one bug should be duplicated on the other 
[17:38] <smb> arges, I had the same patch in there pre-stable... Hm which version was that in...
[17:39] <smb> Seems the same...
[17:39] <smb> arges, So yes, proposed
[17:40] <arges> smb, ok i'll mark 838177 as a dup of 881542 and have him test proposed
[17:41] <smb> arges, Or maybe first test
[17:41] <arges> smb, yea good idea. i'll make sure he tests first
[17:41] <smb> And if it is fixed by proposed it is confirmed to be duplicate
[17:41] <arges> ok great!
[17:43] <arges> smb, thanks
[17:43] <smb> np
[18:32] <cyphermox> tgardner: are you saying the patch doesn't apply?
[18:33] <cyphermox> (i'm responding on the ML anyway)
[18:33] <tgardner> cyphermox, yep, tried to apply it to master-next precise. no joy.
[18:33] <cyphermox> master-next?
[18:33] <cyphermox> I based it on ubuntu-precise.git; and tried on linux-2.6.git ;)
[18:34] <tgardner> ok, lemme try master
[18:34] <tgardner> it shold work in either case
[18:34] <cyphermox> what's master-next ?
[18:34] <tgardner> cyphermox, its a different branch that we use for staging upcoming patches
[18:34] <cyphermox> ok
[18:35] <tgardner> that section iof code should be unchanged between the branches
[18:35] <cyphermox> tgardner: is it far off from git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git ?
[18:35] <cyphermox> right, it suprises me that this code changes anyway
[18:37] <tgardner> cyphermox, it should be identical. i think the problem is likely your email client since the patch seems corrupted. can you 'git format-patch -1' from your tree and leave it somewhere I can get to it, like chinstrap ?
[18:37] <cyphermox> interested, that's how I did the patch initially ;)
[18:37] <cyphermox> sure
[18:38] <tgardner> cyphermox, where do you keep your git repo ? is it in a public spot ?
[18:38] <cyphermox> nah, just my laptop
[18:42] <cyphermox> http://people.ubuntu.com/~mathieu-tl/0001-ipv6-make-the-net.ipv6.conf.all.use_tempaddr-sysctl-.patch
[18:43] <cyphermox> diff says the one on the ML might indeed be corrupt... gah. and I tried really hard to avoid this 
[18:44] <tgardner> cyphermox, got it, and it applies, though with some trailing whitespace.
[18:44] <tgardner> you should 'scripts/checkpatch.pl 0001-ipv6-make-the-net.ipv6.conf.all.use_tempaddr-sysctl-.patch'
[18:44] <cyphermox> ok
[18:44] <tgardner> but its OK for now
[18:47] <cyphermox> ok, fixed now
[18:50] <tgardner> cyphermox, I'm gonna get some brain food, then I'll work through your patch. biab.
[18:50] <cyphermox> sure, thanks a lot
[18:56] <cyphermox> perhaps I can start with a question; I've added the dev_tempaddr_change function, which basically does the same as dev_disable_change(); this is probably a nop but the goal is roughly to restart the interface to make sure tempaddrs would start being created when the value changes
[18:57] <cyphermox> the question is: am I better to try to cycle the interface's state or just avoid that altogether?
[19:03] <vanhoof> random question :)
[19:03] <vanhoof> currently running oneiric on my x220, but wanting to check out precise kernels
[19:03] <bjf> yes you can
[19:03] <vanhoof> I already build my own (to add a few things) ...
[19:03] <vanhoof> would it be best to build precise kernels in a oneiric schroot (since I'm running oneiric)
[19:03] <vanhoof> or within a precise schroot
[19:04] <vanhoof> (or does it matter either way)
[19:04] <bjf> i don't think its really going to matter
[19:12] <bjf> jjohansen: bug 874544, your test kernels have not received any testing (no comments added anyway), do you plan to pursue this or should we mark the bug incomplete and let it expire if we get no feedback ?
[19:12] <ubot2> Launchpad bug 874544 in linux "mkdir failure on NFS with Apparmor" [Undecided,Confirmed] https://launchpad.net/bugs/874544
[19:14] <jjohansen> bjf: hrmm, good question.  I do know for a fact he is using the kernel and has reported it works for him but he hasn't updated the bug
[19:14] <bjf> jjohansen: ok, that's good info
[19:15] <jjohansen> bjf: I have tried poking him to update but no luck, the patch is basically a back port so it should be safe
[19:15] <bjf> jjohansen: do you plan on SRUing it?
[19:16] <jjohansen> bjf: well if I could get him to test, because I can't hit it
[19:16] <jjohansen> bjf: mark it incomplete for the moment
[19:16] <bjf> jjohansen: i'll mark it incomplete with a comment
[19:20] <bjf> sforshee: bug 865807, do you want me to decline your nominations ?
[19:20] <ubot2> Launchpad bug 865807 in linux "acer-wmi wont recognize hotkey on Travelmate 8372" [Undecided,Incomplete] https://launchpad.net/bugs/865807
[19:21] <sforshee> bjf, please do, thank you
[19:29] <vanhoof> tgardner: seen any oddness w/ iwlwifi on precise?
[19:29] <tgardner> vanhoof, just ran a pass on a 6300. looked OK
[19:30] <vanhoof> tgardner: using a 6205 here, booted into 3.2.0-4.10
[19:30] <vanhoof> would associate (after numerous tries), but would quickly drop
[19:30] <vanhoof> booted back into oneiric and i'm fine again (same location, back deck :))
[19:31]  * vanhoof wonders if building precise in an oneiric schroot caused any issues
[19:31]  * vanhoof will give it go
[19:31] <tgardner> vanhoof, unlikely, but you can always build it in the right chroot and try again. how is your AP configured ?
[19:35] <vanhoof> tgardner: 11ng on a 2.4ghz band
[19:35] <vanhoof> not running a separate 5ghz band
[19:35] <vanhoof> tgardner: this cycles consistently: http://paste.ubuntu.com/771500/
[19:35] <tgardner> vanhoof, thats exactly the setup I just tested with a 6300. lemme see if I have a 6205...
[19:36] <vanhoof> tgardner: ill try a kernel build in a precise schroot
[19:39] <tgardner> ogasawara, Tejun already has an ACK from Jens on the floppy driver warning patch.
[19:40] <ogasawara> tgardner: cool
[19:49]  * cking shuffles off for the day
[19:51]  * smb shuffles off for the year...
[19:52] <cking> smb, really?
[19:53] <smb> cking, It is not much left of it and not having taken many vacation days before.
[19:53] <cking> dude, you need to take vacation when there is some sun shine
[19:54] <smb> Too hot... :-P
[19:54] <kees> heheh
[19:54] <cking> smb, how about the southpole, nice and sunny and not hot at all
[19:55] <smb> cking, Maybe not bad. Apart from the social opportunities. But housing should be relatively cheap. :)
[19:55] <cking> internet maybe patchy
[19:56] <smb> good point... hmmm...
[19:56] <cking> like taking a vacation in the refrigerator really
[19:57] <cking> smb, well have a nice vacation..
[19:57] <cking> drink lots of beer
[19:58] <smb> cking, Heh, thanks. Maybe not beer, but there is lots of other stuff. :)
[19:58]  * cking really saunters away now..
[20:28]  * sforshee goes to run an errand, back in about 30 minutes
[20:47]  * ogasawara lunch
[20:53] <pgraner> jsalisbury, ping
[20:53] <jsalisbury> pgraner, pong
[20:53] <pgraner> jsalisbury, you going to be in lex anytime soon? I have a box for you
[20:54] <jsalisbury> pgraner, I could always drive down to pick it up.
[20:54] <pgraner> jsalisbury, its an intel ivybridge
[20:54] <pgraner> jsalisbury, I'll leave it with christine at the desk
[20:54] <jsalisbury> pgraner, cool, thanks!
[20:54] <jsalisbury> pgraner, I'll ping here about picking it up.
[20:55] <jsalisbury> s/here/her/
[20:56] <vanhoof> tgardner: went back to oneiric (outside) no issues ... rebuilt 3.2.0-4.10 in a precise schroot (but now inside since it's cold :)) ... but will give it a test out there in a bit
[20:56] <vanhoof> tgardner: stable so far inside
[20:57] <tgardner> vanhoof, wuss, put on a coat.
[20:57] <vanhoof> tgardner: :)
[20:57] <vanhoof> tgardner: 60F and cloudy :)
[20:58]  * vanhoof waits for stories of tgardner walking 10 miles in the snow to buy more coal for his furnace ;)
[20:58] <tgardner> its only made it above freezing here a couple times in the last 3 weeks
[20:58] <tgardner> I've had to start wearing shoes outside.
[20:59] <vanhoof> heh
[21:09]  * jsalisbury back online in about ~1.5 hours.  Taking a trip to the Lexington office.
[21:12] <vanhoof> tgardner: certainly holding up well inside :\
[21:12] <vanhoof> tgardner: http://paste.ubuntu.com/771589/
[21:13] <vanhoof> tgardner: maybe the driver is more sensitive to noise in 3.2 ... quite a few ap's in range when i'm out there
[21:13] <vanhoof> *shrugs*
[22:21]  * tgardner ->EOD