[07:40] <reisei> hello! I have strange issue: on shutdown, after unmounting devices I got this messages, that repeats in cycle: http://pastebin.com/fLM84Y2G Can you advice me, what's wrong with my configuration?
[08:13] <apw> reisei, that is a device which has not been shutdown correctly by the looks of it, i assume this is an arm device
[08:16] <apw> dupondje, as it doesn't seem to be in stable as far as i can tell you'd need to file a bug to track it
[08:18] <smb> mornings
[08:18] <apw> smb, moin
[08:21] <reisei> apw: yep, you're right.
[08:21] <ppisati> moin
[08:21] <dupondje> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/946928
[08:21] <ubot2`> Launchpad bug 946928 in linux "sysfs: can not remove 'bsg', no directory" [Undecided,New]
[08:22] <apw> ppisati, seen anything with arm boards not halting right, with errors from interrupts after 'System halted.' ?
[08:22] <reisei> apw: ppisati MUSB if off, btw
[08:23] <ppisati> nothing lately
[08:23] <ppisati> reisei: which board?
[08:24] <reisei> ppisati: variscite
[08:24] <apw> dupondje, what did you do to trigger this, i'd be supprised if anyone hit it
[08:25] <ppisati> reisei: variscite? omap3? omap4?
[08:26] <dupondje> Mar  4 23:08:39 laptop-jl kernel: [19951.765869] sd 17:0:0:0: [sdb] Attached SCSI disk
[08:26] <dupondje> this was just before ...
[08:26] <dupondje> hit it 2 times even yesterday :p
[08:27] <reisei> ppisati: omap4460
[08:27] <ppisati> reisei: kernel version?
[08:27] <apw> dupondje, attaching and detaching external USB disks ?
[08:27] <dupondje> apw: yea seems so
[08:28] <dupondje> it doesn't break anything anyway
[08:28] <dupondje> but less spam in console is always good :D
[08:29] <reisei> ppisati: 3.1
[08:29] <ppisati> reisei: wow, 4460 on pci module? http://www.variscite.com/products/item/76-var-som-om44-ti-omap4460
[08:29] <dupondje> anyway gtg now
[08:30] <dupondje> and its raining like hell :(
[08:31] <ppisati> reisei: btw 3.1 didn't have all the necessary bits to support 4460
[08:31] <reisei> ppisati: yep. 
[08:31] <ppisati> reisei: 3.1 vanilla or linaro? and, in case of linaro, which tree?
[08:31] <reisei> ppisati: what do you mean by bits?
[08:31] <ppisati> reisei: i mean support for freq scaling and dvfs
[08:32] <ppisati> reisei: without these, the cpu overheats quickly
[08:32] <reisei> ppisati: linaro, but it's somehow fixed by developer of that module
[08:32] <ppisati> reisei: if it's the 3.1 tilt tree, then you should be ok
[08:32] <reisei> ppisati: how can I check it?
[08:32] <ppisati> try booting a 4460 panda board
[08:33] <ppisati> with that kernel
[08:33]  * apw bounces for a new kernel ...
[08:33] <apw> wish me luck
[08:33]  * smb already got that
[08:34] <ppisati> i updated yesterday my laptop and it was ok, except for a garbled lightdm
[08:35] <smb> Have not noticed that here, but maybe there was a change in today changing that
[08:35] <ppisati> smb: well, i'm on unity2d so could be a 2donly issue
[08:35] <smb> ppisati, Is lightdm not always 2d?
[08:35] <reisei> ppisati: I don't have an 4460 panda, just an old one :-)
[08:36] <ppisati> smb: uhmm... good point... actually i get the garbled screen after i logged in but before the desktop is all setup
[08:37] <ppisati> reisei: uhmmm.. our kernels are tailored toward a set of boards, could be that you have to tweak some settings
[08:37] <ppisati> reisei: do you always get this panic?
[08:37] <ppisati> reisei: do you have a screenshot?
[08:37]  * ppisati -> coffee++
[08:38] <smb> ah... think that sounds like have that for as far as I can remember (more or less) with nvidia or ati
[08:38] <reisei> ppisati: Reboot goes well. Only on halt. I have dmesg log: http://pastebin.com/fLM84Y2G
[08:45] <ppisati> reisei: it seems it's a known issue - http://www.mail-archive.com/linux-omap@vger.kernel.org/msg53767.html
[08:45] <ppisati> reisei: you should look for any changes in that driver within latest linus. rmk or omap tree
[08:45] <ppisati> reisei: or simply ask agreen since he mantains that tree and maybe he already faced that problem
[08:46] <apw> BAH just had a graphics lockup, the old hang when pulling the launcher out of the side
[08:55] <reisei> ppisati: ok, thank you!
[10:27]  * smb wonders whether <super>+<alt>+<cursor> stopped moving the window in focus for other people too (ctrl+alt+shit+cursor right now... wonder was it really that before changing it to something involving super?)
[10:32] <brendand> smb - same here. unity help says super+alt is the correct one
[10:32] <brendand> smb - when i try that it does something in xchat, but not to the window
[10:33] <pkh> i've just upgraded to the beta and the kernel doesn't appear to support dmraid out of the box -- is this a bug or did I miss something out in the upgrade?
[10:33] <pkh> i'm back and running with the kernel from before the upgrade fine, but thought I shoudl report it anyway.
[10:34] <smb> Well I remember that there was someone saying they would do yomething about those keys (either change shift+super to something not hurting or completely revert). Just not sure whether it really was a three finger press before...
[10:36] <smb> pkh, Hm, I thought I did an upgrade test with a dmraid setup and it worked. But yes, please report it (if possible with dmesg from the failure and for comparision from before)
[10:36] <pkh> k, will do -- report where though?
[10:37] <smb> pkh, Launchpad bug report. 
[10:37] <pkh> k, will get on it.
[10:37] <smb> ubuntu-bug linux  (or dmraid) one of those we can change it later
[10:37] <smb> pkh, ^
[10:39] <pkh> ah, just relised that i don't think i'll be able to get a dmesg -- root is on dmraid, with new kernel I get left with that limited shell.
[10:40] <apw> pkh, you might be able to mount a usb stick within it
[10:40] <pkh> k, will ahve a play tonight and send whatever I can get hold of thought
[12:15]  * ppisati -> out for lunch
[14:02]  * tgardner reboots tangerine for kernel upgrade...
[14:13]  * smb just checked dmraid with the latest kernel and it still seems to work (at least for non-root usage)...
[14:20] <brendand> if an sd card reader is connected on the scsi bus, is there any way to tell that it's an sd card reader?
[14:22]  * cking --> back in 25-30 mins
[14:37] <htorque> hello everyone! would any kernel hacker with working systemtap be so nice and run the following as a user (user must be in groups 'stapdev' and 'stapusr'):
[14:37] <htorque> stap -e 'probe vfs.read {printf("read performed\n"); exit()}'
[14:38] <htorque> this fails for me on ubuntu and works on fedora, and i'd like to know if others see this too.
[15:03] <tgardner> ogasawara, ppisati, apw: Precise arm* chroots on gomeisa are borken, so use tangerine. its something to do with qemu.
[15:03] <ogasawara> tgardner: ack
[15:05] <ogasawara> how is it I just learned I can cherry-pick a range of commits now
[15:08] <ppisati> cool, latest kernel hangs on omap3
[15:09] <tgardner> ogasawara, is that something new with the latest git ?
[15:09] <ogasawara> tgardner: I think so.  it's awesome.  now if only I could do an interactive cherry-pick...
[15:10] <ppisati> tgardner: afaik arm precise chroot have always been broekn due to a qemu bug
[15:10] <ppisati> tgardner: they never worked
[15:10] <tgardner> ogasawara, can you filter based on a directory or file ? e.g., git log prettyprint=online -- fs/ecryptfs
[15:11] <tgardner> ppisati, its a host issue. works fine on tangerine (which is precise).
[15:11] <ppisati> tgardner: ok
[15:11] <ogasawara> tgardner: yep
[15:12] <tgardner> ogasawara, so, something of the form 'git cherry-pick v3.2..HEAD -- fs/ecryptfs' ?
[15:13] <ogasawara> tgardner: hrm, dunno about that.  /me tests
[15:17] <ogasawara> tgardner: yep, that works
[15:17] <tgardner> ogasawara, cool, stands to reason.
[15:18] <tgardner> ogasawara, hmm, I wonder what it does about merge commits ?
[15:19] <ogasawara> tgardner: I assume it'll vomit some type of conflict that'll need resolved
[15:19] <tgardner> prolly
[15:20] <ogasawara> tgardner: but for the most part, it's much easier to sync patches from P to Q now
[15:20] <tgardner> yep, I can imagine
[15:21] <tgardner> ogasawara, I assume you noticed I rebased sometime over the weekend ?
[15:21] <ogasawara> tgardner: I did, thanks.
[15:21] <cking> tgardner, my last ecryptfs patches probably need the SOB and buglink popped in to the patch before applying it to Natty - my fail to pop them in
[15:21] <tgardner> ogasawara, I've been running it on one of my problematic wifi laptops. it seems to work pretty well..
[15:22] <tgardner> cking, already taken care of
[15:22] <cking> ta
[15:22]  * cking will try to do it right next time..
[15:22] <tgardner> cking, I figured its best not to annoy you with minutiae
[15:23] <cking> :-)
[15:23]  * smb had been assuming tgardner would do so, too
[15:23] <tgardner> cking, besides, I have the magic bjf/herton script that will munge any patch with aplomb.
[15:24] <cking> ah, nice one
[15:24] <tgardner> cking, kteam-tools/maintscripts/maint-modify-patch
[15:27] <tyhicks> cking: Judging by all the eCryptfs-related SRU work you've done on the kernel-team mailing list recently, me slapping on the 'Cc: stable@vger.kernel.org' tag isn't cutting it.
[15:27] <tyhicks> cking: What can I do differently to help make sure these types of patches don't get lost?
[15:28] <tgardner> tyhicks, some of these went onto Natty which is no longer a supported stable kernel.
[15:28] <cking> tyhicks, I suspect that if they don't apply cleanly then don't land in stable
[15:28] <tyhicks> cking: Right, but gregkh's scripts automatically alert me that something marked for stable didn't apply. I've only ignored 1 of those emails and that was a year or 2 ago.
[15:28] <cking> and as tgardner said, for the Natty these need some love and attention
[15:29] <tyhicks> So when I feel something is important enough to mark it for stable, should I also send it to the kernel-team ML after Linus takes it in?
[15:29] <tgardner> tyhicks, that couldn't hurt
[15:30] <tyhicks> tgardner: Sounds good - that is trivial for me to do
[15:33] <cking> tyhicks, fortunately the list of outstanding patches for me to test and SRU is quite small now
[15:34] <tyhicks> cking: Great! Thanks for all of the work you've done on that!
[15:34] <cking> np
[15:35] <tyhicks> cking: Hopefully I can change my workflow up a little where backports for certain releases don't get lost in the shuffle
[15:35]  * cking nods
[15:36] <tyhicks> (going forward)
[15:38] <brendand> herton, bjf - we're trying to get the oneiric SRU done asap. could be tomorrow or maybe wednesday though
[15:39] <bjf> brendand: huh
[15:45] <brendand> bjf, last week was supposed to be the regression testing week. we're a little behind due to a few recent issues with our test systems
[15:58]  * ogasawara back in 20
[15:58]  * apw dispairs at the total inequality of computation on gomisa ... how can i have 1/5th of the build threads that leann does and yet get 1% of the forward progress
[15:59] <apw> why do her threads get priority
[15:59] <ogasawara> apw: they love me more :)
[16:02] <smb> bjf, I wonder whether you are currently more successful in getting cobbler to update images. Whenever I run cobbler-ubuntu-import it obscurely fails and leaves a tmp-* distro around (upgraded to precise)
[16:04] <bjf> smb, i'll send you my runes
[16:06] <smb> bjf, Thanks. But beside that, is that a known breakage? IOW do they (server-team) know about it if yes?
[16:09] <apw> ogasawara, i have been thinking about it and monitoring your builds and i cannot fathom it
[16:09] <apw> ogasawara, i am starting to believe your priority is based on len(username) its about the only thing that makes sense to me
[16:11] <apw> cking, how is your build progressing ?
[16:11] <apw> cking, will you tell me when it completes
[16:11] <cking> apw, like ogasawara has 90% of the cycles and I'm left with the crumbs
[16:12] <cking> scheduler has US <-> UK biasing controls?!
[16:12] <apw> len(ogasawara) > len(cking)
[16:12] <cking> len(cking) > len(apw) WIN
[16:13] <Sarvatt> there's always tangerine, but it builds kernels 3-4x slower than gomeisa does after it got upgraded to precise :)
[16:14] <ohsix> any one reason?
[16:14] <cking> all the cycles are being used by the HUD
[16:14] <Sarvatt> it used to take 11 minutes vs gomeisa's 9 when it was on lucid, now that its on precise its 31 minutes
[16:15] <apw> Sarvatt, that is positivly awsome ...
[16:15] <apw> tgardner, do we still have a .32 kernel avail on tangerine ?
[16:15] <cking> any physical changes on that box?
[16:16] <apw> ogasawara, are your builds done ?
[16:16] <Sarvatt> i noticed it first being slow on jan 20th but i hadn't built a kernel since december before that, tgardner said it was upgraded to precise in budapest
[16:16] <tgardner> apw, its a precise user space
[16:18] <ogasawara> apw: yep, they finished while I was away
[16:19] <apw> ogasawara, perplexing your entire builds fitted into the last 1/3rd of mine, which took enormously longer than normal
[16:19] <apw> i cannot fathom what the hell is wrong with the scheduling 
[16:20] <ogasawara> apw: something is definitely amiss as I seem to always get priority, even when you've already been building ahead of me
[16:20] <apw> tgardner, indeed, and was thinking perhaps a .32 kernel might let us see who is to blame for the performance loss Sarvatt is reporting
[16:21] <apw> ogasawara, you use a higher concurrency for sure, but i don't seem to get a proportionate slice, and that i cannot figure
[16:21] <ohsix> Sarvatt: i'd be interested in the cause of the slowdown if you find out; they did some io stuff that was supposed to alleviate a lot of suck from .32-3.2
[16:24] <tgardner> apw, otp
[17:02] <slangasek> herton: kees has uploaded your patch to udev for DM_COOKIE handling, after we discussed it yesterday at the global jam - thanks for the patch :)  Have you sent it to udev upstream?
[17:03] <herton> slangasek, cool. Not sent upstream already, will take a look
[17:03] <herton> s/already/yet/
[17:04] <kees> it'd need to go with the timeout patch too
[17:05] <herton> hmm indeed. apw, did you try to send the timeout patch, I think we would need to send both
[17:05] <kees> apw: looks like while viro says i_uid should be valid, I think calling vfs_stat is the right fix for yama. I'll send a patch
[17:06] <apw> herton, i did try, they said the kernel should not do that (emit events in the middle of handling one from udev) and they wen't going to take it
[17:07] <apw> kees, if i_uid is meant to be valid (and i agree that is what al says) then why is what you are doing wrong as it is?
[17:07] <herton> ok, so probably they will reject the DM_COOKIE patch also...
[17:08] <herton> which depends on the timely patch
[17:08] <apw> herton, i would expect them to, but trying to send it again (both indeed together if that makes sense) may not be pointless
[17:08] <kees> apw: seemed easier than trying to plumb the logic into overlayfs, especially in the face of it maybe being a problem with other filesystems in the future.
[17:48] <htorque> hi all! anyone here using systemtap?
[17:53] <apw> kees, and the cost of calling stat there?
[17:57] <cking> htorque, I tested systemtap on Precise with some kernel stap scripts last week
[17:57] <tgardner> ogasawara, pushed a patch to ubuntu-precise-meta. please give it a quick looksee.
[17:57] <ogasawara> tgardner: ack
[17:58] <tgardner> smb, does VNC console access to a Xen VM require X components ?
[17:58] <htorque> cking: you don't have it currently running i guess? i can't seem to get it to work as unprivileged user and wanted to know if it's just my setup or if it fails for other ubuntu users too (as the same steps work on fedora)
[17:58] <tgardner> bug #944582 argues that xen-kbdfront should be included  in the virtual flavour
[17:59] <ubot2`> Launchpad bug 944582 in linux-meta "xen-kbdfront module should be provided by linux-image-virtual or linux-virtual" [Undecided,New] https://launchpad.net/bugs/944582
[17:59] <htorque> like running this as user (which must be in groups 'stapusr' and 'stapdev'): stap -e 'probe vfs.read {printf("read performed\n"); exit()}'
[17:59] <tgardner> cking, is there a yama switch that you have to flip ?
[17:59] <cking> htorque, I always run it using sudo
[18:00] <htorque> cking: that's working here too
[18:00] <smb> tgardner, On the guest I don't think so. The host, not sure, I did not by itself install things but never checked
[18:01] <smb> tgardner, the kbdfront would likely be good for console... I'll look at it
[18:01] <tgardner> smb, can you offer your opinion in the bug?
[18:01] <cking> htorque, I need to load the .ddebs for /me to try it out, let me find a box where I can test this..
[18:03] <smb> tgardner, Right, we should put that into the main package. Not sure why it is in extras...
[18:03] <htorque> cking: that would be great (if it's no trouble to you).
[18:04] <cking> it will take me a little while to set up (my ISP is rate throttling me at the mo)..
[18:04] <tgardner> smb, ok, will do
[18:05] <htorque> cking: yeah, downloading the 650 mb is no joy. :-(
[18:05]  * cking nods
[18:05] <smb> tgardner, Ah ok, would have send out a patch to change it otherwise
[18:05] <tgardner> smb, its precise, I'll just do it.
[18:05] <smb> tgardner, ack
[18:07] <smb> tgardner, Either you were so quick or its already there but in the wrong place
[18:08] <tgardner> smb, haven't done anything yet....
[18:08] <kees> apw: that's the concern -- it's a bit expensive. semi-related -- why add the yama_permissions() function instead of using vfs_permissions()?
[18:08] <apw> i am not adding yama_permissions ?
[18:08] <apw> kees, ^^
[18:10] <apw> kees, this is coming from someone doing a touch 1; chmod 444 1; ln 1 2 ... within an overlayfs and yama barfing ... its std higher level permissions
[18:13] <smb> tgardner, I did a quick package check, it seems its there in precise but not in oneiric
[18:20] <tgardner> smb, the path is wrong in oneiric. I'll send an SRU patch
[18:20] <smb> tgardner, Bah, seems a type hit us. I sent a quickly whipped up patch to mailing list
[18:21] <smb> tgardner, Nearly the same time
[18:21] <smb> :)
[18:21] <smb> tgardner, But yes, seems in Precise it is correct but it is wrong for Oneiric
[18:22] <tgardner> smb, go ahead and send yours. I'll work on the meta package description updates
[18:22] <smb> tgardner, Just hit the list
[18:24] <kees> apw: the yama_permissions call from last year is what I mean -- why create that instead of using vfs_permissions ?
[18:26]  * apw can't even find vfs_permissions now, let alone then <-- kees
[18:26]  * kees goes looking
[18:28] <kees> apw: ah! sorry -- inode_permission
[18:29] <apw> that does a lot more than you already did, an i wasn converting 'generic_permission()' to somethign correct in the face of a permissions op
[18:30] <kees> what about do_inode_permission()? that's nearly identical.
[18:30] <apw> i worry slightly that you are in a LSM op, and you call that you are calling security_inode_permission
[18:30] <kees> do_inode_permission avoids that, but is static.
[18:30] <apw> do_inode_permission is definatly what it means, but as you say not exported
[18:30] <apw> i think i'd refer back to you and ask what did you mean to check what permissions
[18:30] <kees> okay, so I'll leave yama as-is, and for Q, we can remove the yama link restrictions in favor of upstream
[18:31] <apw> as its always possible inode_permission is right
[18:31]  * apw makes a note that overlayfs should be using it too
[18:31] <apw> bah
[18:31] <kees> it was unrelated to the overlayfs issue -- It was just a question I'd been meaning to ask you from when I converted the Yama link restrictions to the upstream VFS layer link restrictions
[18:32] <apw> yeah an it is an unrelated note to self
[18:32] <apw> that i adeded half that routine to overlayfs, and possibly i should using it
[19:18] <apw> with a minor success under his belt, and having not figured out why everyeone gets prio i am giving up ... till tommorrow
[20:03] <cking> htorque, I suspect you may need to configure systemtap-server to get it working w/o root privilege, but I'm darned if I can get it working at the moment, I'll give it a another try tomorrow
[20:24] <dupondje> jsalisbury: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/946928 , 37b40adf2d1b4a5e51323be73ccf8ddcf3f15dd3 is the commit id in upstream? http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commitdiff;h=37b40adf2d1b4a5e51323be73ccf8ddcf3f15dd3
[20:24] <ubot2`> Launchpad bug 946928 in linux "sysfs: can not remove 'bsg', no directory" [Medium,Triaged]
[20:25] <jsalisbury> dupondje, yes, it appears to be in the linux-stable tree.  You should see it if you run the following in the linux-stable src tree:
[20:25] <jsalisbury> git show 37b40adf2d1b4a5e51323be73ccf8ddcf3f15dd3
[20:26] <jsalisbury> dupondje, that commit is also in Precise.
[20:27] <dupondje> lets see
[20:31] <dupondje> jsalisbury: the commit is not there in http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-precise.git;a=tree;hb=HEAD
[20:35] <jsalisbury> dupondje, hmm, interesting.  The commit is reported with git log, but it looks like the following is indeed not it ~block/bsg.c: 
[20:35] <jsalisbury> -       sysfs_remove_link(&q->kobj, "bsg");
[20:35] <jsalisbury> +       if (q->kobj.sd)
[20:35] <jsalisbury> +               sysfs_remove_link(&q->kobj, "bsg");
[20:35] <jsalisbury> dupondje, I'll do some further research and update the bug.
[20:35] <tgardner> jsalisbury, you need to use --contains, e.g., 'git describe --contains 37b40adf2d1b4a5e51323be73ccf8ddcf3f15dd3'
[20:38] <jsalisbury> tgardner, ahh, that makes sense.  So that means the patch is in v3.3-rc4, but not in linux-stable.
[20:38] <tgardner> jsalisbury, correct
[20:38] <jsalisbury> tgardner, I wasn't aware the linux-stable tree would have commits for the mainline tree.
[20:39] <tgardner> jsalisbury, well, of course it would. for example, 3.2 stable has all of the mainline commits up through v3.2. everything on top of that would be stable commits with a different SHA1
[20:40] <dupondje> just cherry pick it :)
[20:40] <tgardner> dupondje, already done
[20:41] <dupondje> great
[20:42] <jsalisbury> tgardner, So any commit to the mainline tree will automatically show up in a 'git log' run against the linux-stable tree, even if it isn't applied to linux-stable yet?  And when the commit is applied, it gets a new SHA-1?
[20:43] <dupondje> tgardner: jsalisbury: changed bug to Fix Commited! thx
[20:43] <jsalisbury> dupondje, thanks
[20:44] <jsalisbury> tgardner, hmm, ok.  I can see all the tags up to v3.3-rc6 in the linux-stable tree.  
[20:44] <tgardner> jsalisbury, its relative to the branch that its on, and perhaps how you've populated your repo. for example, if you've ever done a 'git fetch git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master', then you'll have _all_ of mainline regardless if the object is in a branch.
[20:45] <tgardner> jsalisbury, its likely thats what greg k-h has done
[20:45] <jsalisbury> tgardner, ok, I understand now.
[20:48] <tgardner> dupondje, don't put URLs to gitdiff in a bug because the SHA1s are not immutable until the final kernel freeze before release.
[20:49] <dupondje> oh didn't know
[20:49] <dupondje> anyway :)
[20:55] <jsalisbury> tgardner, Unless I'm searching wrong, I looks like the commit is not in 3.2.8, but it is in 3.2.9
[20:55] <jsalisbury> tgardner, I run this command under both branches:
[20:55] <jsalisbury> git log --pretty=oneline | grep 'bsg: fix sysfs link remove warning'
[20:55] <htorque> cking: thanks, that's the only thing left for me to try. it's working under fedora though.
[20:55] <jsalisbury> tgardner, but I only see the commit when on the 3.2.9 branch.
[20:56] <cking> htorque, I suspect it is some user space foo config that we're missing
[20:57] <smoser> smb, ping
[20:58] <htorque> cking: would just be nice to know that foo and document it somewhere (ideally at both wikis). especially with user-space probing you want to be able to run stuff as normal user.
[20:59] <tgardner> jsalisbury, you're looking at linux-3.2.y ? I'm not seeing it there.
[20:59] <cking> htorque, i agree
[21:00] <jsalisbury> tgardner, Yes, my .git/config file points to:  url = git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
[21:00] <htorque> anyways, thanks again for trying. :-)
[21:00] <jsalisbury> tgardner, maybe I'll blow it away and re-clone it.
[21:00] <cking> htorque, I can't promise I can figure it out immediately, the workaround is run it with sudo for the moment I suppose
[21:00] <tgardner> jsalisbury, there are a number of branches in that repo. make sure you have 'git checkout -f linux-3.2.y'
[21:01] <jsalisbury> tgardner, ahh, maybe that's what I'm doing wrong.  I was getting the branches with git checkout v3.2.8 and git checkout v3.2.9
[21:01] <htorque> cking: sure, no need to promise anything. it's good enough to know that it's no 'layer 8' issue for now. ;-)
[21:02] <tgardner> jsalisbury, if you don't already have that branch, then 'git checkout -b linux-3.2.y remotes/origin/linux-3.2.y'
[21:02] <jsalisbury> tgardner, not with the linux- prefix
[21:03] <jsalisbury> tgardner, do you happen to know the difference between the v3.2.8 and linux-3.2.y tags?
[21:04] <jsalisbury> tgardner, where v3.2.8 can be v3.2.N
[21:04] <tgardner> jsalisbury, linux-3.2.y is a branch in which the tag v3.2.8 exists
[21:04] <jsalisbury> tgardner, doh, right.
[21:05] <jsalisbury> tgardner, so I was looking at the v3.2.9 tag in the master branch or linux-stable.
[21:05] <tgardner> jsalisbury, yep
[21:06] <jsalisbury> s/or/of/
[21:07] <jsalisbury> tgardner, And the master branch in linux-stable contains the mainline commits as well?  That's why I was seeing that commit.
[21:08] <tgardner> jsalisbury, yes, it probably _is_ Linus' master branch. I haven't looked too close.
[21:08] <jsalisbury> tgardner, thanks for the help.  I think I have my head on straight now :-)
[21:08]  * jsalisbury plans on studying all the branchs and trees closer.
[21:09] <tgardner> jsalisbury, do a 'git branch -a' to see all of the remote branches in the linux-stable repository
[21:09] <jsalisbury> tgardner, perfect, thanks!
[21:13] <jsalisbury> tgardner, The linux-stable repository is making much more sense now.  Thanks for all the info.
[21:13] <tgardner> jsalisbury, anytime
[21:13]  * jsalisbury owes tgardner one more beer :-)
[21:15] <cking> mmm. beer
[21:19]  * tgardner thinks it good to have beer favors
[21:53]  * tgardner -> EOD
[23:29] <GrueMaster> sconklin: Are you online?  Questions on this power amp meter.
[23:31] <sconklin> GrueMaster: I'm just barely still here, what's up?
[23:31] <GrueMaster> I am failing in my attempts to get meaningful power from this atx harness.
[23:32] <GrueMaster> I can get decent readings from a Via ITX board, but not on this arm board.  I have vamp'd into the 3.3v, 5v, and 12v power lines.
[23:33] <sconklin> Do you get any readings at all? Are they all pretty high and don't show variation when the load changes?
[23:33] <GrueMaster> The other issues is the closest I have to an electronics store is Ace Hardware, so connectors are hard to come by.
[23:33] <sconklin> (high is a relative term)
[23:33] <GrueMaster> The best reading I have seen is on 5v, but it is ~0.0000045 amps when booting.
[23:34] <GrueMaster> For reference, a panda is drawing 1.5 amps.
[23:34] <sconklin> when you are cutting into the power supply lines to measure current, are you sure you're cutting all the other lines with the same voltage?
[23:34] <sconklin> You have to get it down to one supply wire and measure that
[23:35] <GrueMaster> Yes.  All Orange (for example) are cut, and each group is twisted together and crimped into a connector, female on one side, male on the other.
[23:35] <GrueMaster> I knew that.
[23:36] <sconklin> I figured you did, but the symptom of very low current measurement is consistent with not having all the supply lines cut
[23:36] <GrueMaster> Only wires left are common (black), +3.3v Sense, Power on, and power good.
[23:37] <GrueMaster> I'm going by http://en.wikipedia.org/wiki/ATX#Power_connection_to_the_motherboard
[23:37] <GrueMaster> Using the 20/24 pin connector for reference.
[23:37] <sconklin> what's the board? It's possible that the current draw is really low if you're booting from flash compared with something else, for example
[23:38] <GrueMaster> For this initial test, Marvell Dove (from pre-Maverick).
[23:38] <GrueMaster> But even my beagle (omap3) draws 0.5 amps on power-up.
[23:39] <sconklin> yeah I would expect something like that. microamps is not in the ballpark
[23:39] <GrueMaster> The Marvell board is about the size of a full atx board.
[23:39] <GrueMaster> The kill-a-watt on the other side of the PS is showing more amps than that.
[23:40] <GrueMaster> Even given power drain.
[23:40] <GrueMaster> I have also used a power supply tester to check amp loads.
[23:40] <sconklin> I suppose it's possible that the meter fuse is blown for current measurement
[23:41] <sconklin> have you moved it back to another board that gives a sane reading?
[23:41] <GrueMaster> Yes.  Both Panda and Via ITX boards give sane readings.
[23:42] <GrueMaster> Of course, after my last test, half the wires came out of their crimp connectors so I have to redo that.  PITA.
[23:42] <sconklin> and the board uses 12V and 5V and 3.3V lines? and you're measuring the 5V line?
[23:42] <GrueMaster> I have measured all three lines.
[23:43] <GrueMaster> 5v is the only one that actually registered with the meter.
[23:44] <GrueMaster> The only other thing I can think of is that the board is drawing from what ever power seems better.  But there aren't enough electronics on the board to do in-line voltage regulating.
[23:44] <sconklin> I don't know what to tell you. The meter is working, because you tested it against another board
[23:45] <GrueMaster> Yes, and it works well on other boards.
[23:45] <sconklin> Inserting the meter shouldn't cause any changes in where it takes power from, so nothing should change 
[23:45] <GrueMaster> Very frustrating.
[23:45] <sconklin> and it boots and runs, right (I have to ask)
[23:46] <GrueMaster> I'm going to rebuild the harness with the connectors soldered in so they don't fall apart.  Then I will try powering with them all unplugged to see if the board is drawing power via osmosis or something.
[23:46] <sconklin> You could try opening the return line (black), and that will measure the return current for all the supply voltages. But that's a lot of wires.
[23:47] <GrueMaster> Yes, I am monitoring it via serial console every time.
[23:47] <sconklin> you've invented free energy.
[23:48] <GrueMaster> I thought of chopping black, but I am limited by what I have available.  There are 8 black wires, and I have no easy way to put a connector in between.  I don't want to fry anything (even though I am using a board we don't care about).
[23:50] <GrueMaster> I'll rebuild the cable and go forward.  I might have missed a power line, but not one of the main ones.  I'm positive about that.
[23:50] <sconklin> ack, let me know
[23:50] <GrueMaster> If this doesn't work, tomorrow I make a day trip to Fry's.