[00:00] <blue_anna> please help
[00:00] <blue_anna> I gave up on my af9015 card, I've started a second time on a tv card that uses the em28xx drivers -- both drivers have built, but neither attach to their card when it is installed
[00:00] <blue_anna> and I have the latest hardware -- but there's scant little, virutally no results for em28xx support. these are both dvb drivers
[00:00] <blue_anna> ** firmware, not hardware
[00:01] <blue_anna> I can't find any documentation for em28xx that's recent 
[00:13] <blue_anna> the modules load if I modprobe them, and after I did that the administration->hardware drivers found a firmware for me to download for my card, but still I get nothing from my card with that firmware installed
[00:14] <blue_anna> online I found something saying that a different firmware was needed but its not working either
[00:15] <blue_anna> and I just tried removing the firmware that the system automatically installed and reloading the em28xx modules, but that didnt pick up either
[00:19] <blue_anna> lsusb doesn't list any name for the hardware, like this is all it says right now: Bus 001 Device 029: ID 1d2c:1012  -- but there's like a million lines of output in lsusb -v for the device: http://pastebin.ws/6htngd
[01:04] <reecefowell> Can anyone tell me if i am correct in my understanding that programs must request a kernel write to the hdd on its behalf and that programs usually dont have access to the hdd to write to it on its own?
[02:04] <cooloney> morning guys
[02:18] <vanhoof> ogasawara: you may be my new best friend ;)
[02:18] <ogasawara> vanhoof: heh, I'm not sure if that's good or bad :)
[02:19] <vanhoof> ogasawara: def good :)
[02:20] <akgraner> ogasawara, be afraid if vanhoof is offering to be your bff....:-/  just sayin'
[02:20] <vanhoof> lol thanks akgraner 
[02:20] <akgraner> opps inside voice  - I mean vanhoof is awesome... yeah that's what I meant :-)
[03:25] <greenfish> where would i locate the debug kernel image for lucid 2.6.32?
[03:31] <jk-> greenfish: what debug info are you after?
[03:32] <greenfish> vmlinux compiled with debug symbols
[03:37] <jk-> not sure if there's a pre-built one; but most of the time you can get by with the symbol table & System.map
[03:37] <pgraner> greenfish: http://ddebs.ubuntu.com/pool/main/l/linux/
[03:37] <jk-> oh, cool.
[03:37] <pgraner> greenfish: however the 2.6.32 ones broke for a long period
[03:37] <pgraner> greenfish: so I don't see them there
[03:37] <pgraner> greenfish: you might be outta luck
[03:38] <greenfish> yeah. thats tough for a sysadmin who needs to profile things...
[03:38] <greenfish> pgraner: i wasn't seeing them either
[03:40] <pgraner> greenfish: I know the build system for some reason was broke and I don't think we can go back and recreate, the next SRU kernel should have one tho
[03:40] <jk-> greenfish: what kind of profiling? 'perf'?
[03:40] <pgraner> greenfish: what are you trying to debug, normally full symbols is overkill as jk was saying
[03:41] <greenfish> pgraner: the tcp stack and memory management when certain applications in my stack are under extreme load
[03:41] <pgraner> greenfish: perf is prob a better tool or ftrace
[03:43] <greenfish> regardless of the tool, i'll need debug symbols to see what the kernel is doing
[03:43] <pgraner> greenfish: are you familiar with perf or ftrace? You don't
[03:43] <greenfish> perf might give me a call graph, but i'm much more familiar with oprofile
[03:44] <pgraner> greenfish: not much we can do, as I said we can't recreate if its not urgent you can wait for the next SRU kernel and it will have ddebs
[03:45] <greenfish> ahh. where are the backups? ;)
[03:45] <pgraner> greenfish: they never got created, the build system was broke 
[03:45] <greenfish> yeah. tough to back that up then ;)
[03:45] <pgraner> greenfish: unfortunately we don't use ddebs that often and when we realized it was too late
[03:47] <jk-> greenfish: so you're looking for hot functions in the kernel?
[03:47] <greenfish> i see. there are 2.6.34 kernels in the ddebs pool. is that from maverick?
[03:48] <greenfish> jk-: perhaps. i just need a full stack profile of the system under specific loads.
[03:48] <greenfish> i'm not opposed to other tools, but i'd have to learn them before they would be useful to me
[03:49] <pgraner> greenfish: yes those are maverick kernels
[03:49] <pgraner> greenfish: if you install the maverick kernel and are experiencing the same issues you can use those ddebs to debug with the tools your familiar with
[03:50] <pgraner> greenfish: I'm running the maverick kernel on the lucid userspace with no issues on both desktop & server so I'd give it a go
[03:52] <greenfish> pgraner: terrific. can that be updated using apt with the right source and not interfere with non-kernel dependencies?
[03:52] <jk-> greenfish: perf should suit; `sudo perf record -a -f -g` and `perf report --call-graph -i perf.data`
[03:52] <greenfish> apologies for the silly question, ubuntu is not my primary distro
[03:55] <greenfish> or, alternatively, where can i find the build process for the 2.6.32 generic kernel? while the resulting binary may not be exactly the same, if i do a full build of both vmlinux, and vmlinuz then things should line up with little to no differences from the ubuntu build
[03:58] <pgraner> greenfish: https://wiki.ubuntu.com/KernelTeam/
[03:58] <greenfish> thanks again
[03:58] <pgraner> greenfish: then find the KnowledgeBase link and follow the link to build instructions
[03:59] <pgraner> jk-: you got video conf working yet....
[03:59] <jk-> pgraner: can set it up on my machine if you need
[04:02] <jk-> but putting it on a .mills host would be cool
[04:02] <pgraner> jk-: how much resource do you need, I can give you sudo on frylock if you want
[04:02] <pgraner> jk-: I'd like to see how well it works
[04:03] <jk-> pgraner: the server doesn't need much CPU
[04:03] <pgraner> jk-: ok, lemme add you to the sudoers 
[04:04] <jk-> yeah, happy to set it up for testing. it was just a hack for our virtual-coffee-machine calls though.
[04:21] <vanhoof> jk-: what'cha working on?
[04:22] <jk-> vanhoof: I hacked together a video conf server for our informal calls
[04:22] <jk-> just getting it set up on pgraner's machine
[04:23] <pgraner> vanhoof: this way I can see your ugly mug
[04:23] <vanhoof> oh nice
[04:23] <vanhoof> pgraner: dont make me drive west :)
[04:23] <vanhoof> can skype do more than 1:1
[04:23] <pgraner> vanhoof: bring it (and some friends)
[04:24] <vanhoof> pgraner: if by friends you mean jess, and my dogs sure :)
[04:24] <vanhoof> pgraner: http://hphotos-snc3.fbcdn.net/hs575.snc3/31375_389772562186_511662186_4512783_5162068_n.jpg
[04:25] <vanhoof> ... a nightmare in the graner household lol
[04:25] <pgraner> vanhoof: nope just something for murphy to play with
[04:27] <vanhoof> pgraner: does he get along w/ women? :)
[04:27] <pgraner> vanhoof: yep
[05:33]  * jk- out for a bit
[08:14] <amitk> cooloney: do you know anything about this on mx51? http://pastebin.ubuntu.com/439766/
[08:15] <amitk> I'm trying to boot a mainline mx51 kernel
[08:15] <amitk> it looks related to the mdio code you were hacking on?
[08:17] <cooloney> amitk: i posted 2 patches to upstream
[08:18] <cooloney> amitk: but Andy Fleming who is the phylib maintainer has some concern
[08:18] <amitk> cooloney: patches to fix this issue?
[08:18] <cooloney> i don't have hardware to do furthur development
[08:19] <cooloney> amitk: i'm not sure about that. 
[08:19] <cooloney> amitk: could you try my patch and test again
[08:19] <cooloney> let me find the patch for you
[08:20]  * smb yawns
[08:21] <amitk> cooloney: l-a-k?
[08:21] <smb> cooloney, Hi, just as info: boot is ok. If you can play around a bit, the better, but there is no real regression test plan for arm
[08:22] <smb> amitk, Morning
[08:22] <amitk> moin smb 
[08:22] <cooloney> smb: ok, got it. GrueMaster will help to test it on his hardware
[08:23] <smb> cooloney, Great, thanks!
[08:24]  * smb goes back to his long checklist
[08:25] <cooloney> amitk: i sent them out to netdev mailist
[08:25] <cooloney> amitk: did you subscribe to that mail list?
[08:27] <lag> Morning smb
[08:28] <lag> Morning amitk
[08:28] <amitk> hi lag 
[08:28] <smb> lHey lag
[08:28] <amitk> cooloney: I think not, but I'll find the archives
[08:28]  * smb punches the backspace key harder
[08:28] <cooloney> amitk: http://kerneltrap.org/mailarchive/linux-kernel/2010/5/7/4566895
[08:28] <lag> smb: Has apw spoken to you regarding the new bug stuff yet?
[08:29] <cooloney> amitk: i need rework on this patch, but don't have working hardware, so ......
[08:29] <smb> lag, Nope. I assume neither to you then
[08:29] <smb> lag, Guess we need to get back to him later
[08:29] <lag> smb: Sure
[08:37]  * apw looks blearly over his domain
[08:37]  * smb and lag already wait in the shadows for apw to arrive
[08:38] <amitk> apw: you make a poor warlord if your desk is your domain
[08:38] <smb> cking, morning
[08:38] <cking> hiya
[08:38] <lag> smb: Speak for yourself ;)
[08:38] <apw> amitk, heh indeed
[08:39]  * apw notes that 12 hours on linux armel is still building
[08:39] <amitk> I noted that, its surprising
[08:39] <lag> amitk: It worked for Churchill  
[08:39] <apw> amitk, why is it supprising?
[08:39] <amitk> apw: I'd thought 5+5 hrs
[08:39] <apw> it takes 6-7 hours to do 1 armel flavour, you added a new one yesterday
[08:40] <amitk> ok, so it should be about done now
[08:40] <apw> 5.5 for the build itself, plus packaging time, which is huge
[08:40] <apw> its in the last 30-40 mins yes
[08:41] <apw> this brings up an issue we need to consider, for when you do get all arm branches in the same image
[08:41] <apw> we can't afford to have a ton of flavours
[08:41] <amitk> by then (next 6 months), we will have ARM HW with 2GB RAM
[08:41] <apw> oh the build is 'done' we ar in pkg*mangler
[08:42] <apw> oh no, maybe not, seems to be back to linux-image now for versatile
[08:43] <amitk> we're talking to vendors to give us faster disk though (sata connections)
[08:43] <apw> we need some 64 way arm servers
[08:43] <amitk> talk to Martyn @ Smoothstone
[08:44] <apw> indeed
[08:44] <apw> sadly adding omap probabally means we need to pull back all our freeze dates by a day
[08:44] <apw> as now you can only do 1 arm build a day not two
[08:46] <amitk> I wonder how hard it would be to hack our scripts to do cross-compile for testing automatically
[08:46] <apw> i do armel builds using crossbuilds primarily, but those don't seem to be able to make the tools side
[08:46] <apw> you need one of those real cross-buildy qemu thingies
[08:46] <amitk> *automatic cross-compile for test-builds
[08:47] <apw> you can do automated test builds using sbuild, though being qemu emulated its like 2:30 a flavour for me
[08:48] <amitk> apw: just for arm
[08:49] <apw> to tooling i am using for just building the linux-image, works using cross compilers for armel builds automatically
[08:49] <apw> and i just found sbuild, so am thinking on letting that be a backend
[08:50] <apw> its an interesting approach for all platforms, not tried it for performance on x86, though i assume its native speeds
[08:50] <smb> lag, To reply to "pseaking for yourself". I meant the bug processing thingy. Though I completely trust you to speak for yourself there, too. :)
[08:50] <apw> the nice thing about sbuild is it seems to be a pbuilder style 'auto install deps' kind of thing, and uses aufs to retain the virgin original chroot
[08:51] <lag> smb: I was joking. I meant I wasn't cowering in the shadows awaiting the arrival of our overruling leader. ;)
[08:52] <smb> lag, Ah you prefer the open attack. :-P
[08:52]  * apw marshalls his forces
[08:53] <lag> smb, apw: Full frontal! ;)
[08:53] <cooloney> apw: how about using qemu running on x86
[08:53]  * apw does not need any full frontal pictures at this time of day
[08:53] <cooloney> and we native compile kernel for armel in qemu
[08:53] <lag> apw: Are we going to chat today about the new bug processes? We didn't really get chance yesterday did we?
[08:53] <apw> cooloney, that is what sbuilder does in this context.  2.5 hours a flavour still
[08:54] <amitk> apw: 2.5 hrs on emerald?
[08:54] <apw> that was on a local box, a 4 way
[08:54] <apw> not tried on emerald as yet
[08:54] <cooloney> and if the x86 is very powerful, we can running several qemu instance and use dist-cc to distribute the building tasks to several qemu builder
[08:55] <amitk> cooloney: how many cores can qemu use effectively?
[08:55] <apw> cooloney, yes i really was trying to say even there its not 'instant', yes much better than the real h/w
[08:55]  * abogani2 waves
[08:55] <abogani2> I'm wondering about ubuntu-debian.git. What it is useful for?
[08:55]  * smb points to apw
[08:55] <apw> though the performance on the real buildd is not guarenteed to be the same, not is the outcome
[08:55] <cooloney> amitk: actually, i have no idea about that
[08:55] <apw> abogani2, its a respository for the master copy of the debian build machinary
[08:56] <apw> we are cleaning up the disparate copies in all our trees over the next few weeks
[08:56] <smb> abogani2, But in general, it should become the source for what is in our debian directories
[08:56] <apw> so that they all behave the same
[08:56] <apw> the main trees will retain their own copied, but they will be regularly updated from the common copy
[08:56] <amitk> abogani2: unified build policy across all releases
[08:56] <apw> as most changes there affect all releases and should be pushed out to all
[08:57] <apw> as they relate to archive behavour which is the same regardless of release age
[08:58] <abogani2> amitk, apw: Understand thanks.
[09:17] <lag> #ifdef DEBUG
[09:17] <lag> #define pr_devel(fmt, ...) \
[09:17] <lag> 	printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
[09:29] <apw> amitk, i see the armel build is in its 14th hour
[09:30] <amitk> still packaging?
[09:30] <apw> yep, the dbg deps are bigger than the machine so it thrashes like  pig i am sure
[09:30] <apw> they take many minutes on emerald
[09:30] <apw> let alone a memory starved arm
[09:31] <apw> i have been saying arm takes 6-7 hours per falvour, and noone believes me
[09:31] <smb> always whining... :-P
[09:31] <apw> amitk, what worries me, is now is the stage where it goes 'package foo not in control file, BANG'
[09:32] <apw> and throws away everything its done
[09:32] <amitk> yeah, I *hate* that
[09:32] <apw> makes me want to cry
[09:45] <ogra> hmm, there seems to be something weird in your package build scripts, omap4 didnt build because the code below only seems to detect omap but not omap4
[09:45] <ogra> imagelist=$(cat /build/buildd/linux-ti-omap4-2.6.33/debian/build/kernel-versions | grep ^armel | awk '{print $4}')
[09:45] <ogra> (thats right after "# unpack the kernels into a temporary directory")
[09:45] <ogra> and results in: ls: cannot access ../linux-image-2.6.33-900-omap_2.6.33-900.1_armel.deb: No such file or directory
[09:46]  * lag is ready to talk about 'moths in relays' with apw and smb
[09:46]  * smb can join
[09:47]  * apw gets tea
[09:48] <cooloney> ogra: ok, thanks, i think i missed something in the debian script stuff
[10:00] <cooloney> ogra: thanks, i forgot to replace omap to omap4 in debian.ti-omap4/d-i/kernel-versions.in
[10:01] <cooloney> ogra: will upload and build again, although it will take 6hrs to build
[10:02] <ogra> ah, perfect
[10:02] <ogra> yeah, the babbage boards arent fast but reliable :)
[10:16] <jjohansen> good night *
[10:25] <amitk> apw: arm is done building
[10:32] <amitk> apw: all flavours of a single arch are built on the same machine, right?
[10:32] <apw> amitk, yes all flavours are built sequentially on one machine
[10:33] <amitk> apw: could that be split up in debian/ ? Or is that buildd backend magic?
[10:34] <apw> amitk, a source package is sequential per architecture, and single thread per architecture
[10:34] <amitk> *sigh*
[10:34] <apw> but the point of your work is to make one kernel for all so we won't have an issue right
[10:35] <apw> amitk, i suspect if we end up with more than 2 arm flavours in 'master' we will have to do something like make two source packages out of the same master tree
[10:35] <amitk> apw: that work is still a year away realistically
[10:35] <apw> linux and linux2
[10:36] <apw> amitk, yep, but of course until you win that battle the arm variants are likely to remain branches, and their own packages, and threfore buildable in parallel
[10:36] <apw> amitk, so likely self limiting in a lot of senses
[10:37] <amitk> true
[11:14] <cooloney> guys, my upload to arm PPA build failed, 
[11:14] <cooloney> it is ti-omap4 kernel package, 
[11:14] <cooloney> i build it successfully in my local machine
[11:14] <cooloney> but it failed in our build system
[11:15] <cooloney> so i fixed it in my kernel pakcage and wanna to reupload, but it was rejected because of my initial upload is there
[11:16] <cooloney> do you guys know how to change my package version without bumping my kernel ABI?
[11:16] <cooloney> apw, amitk and smb-afk ^^^
[11:16] <apw> add build2 to the end of the version number
[11:17] <cking> apw, why does that help?
[11:18] <cooloney> apw: which file contains that version number i can change?
[11:19] <apw> cking, you have to increment version numbers in every upload
[11:19] <apw> cooloney, in the debian.<branch>/changelog
[11:20] <cooloney> apw: oh, sh*t, i know that. 
[11:20] <apw> the complaint is about the literal and total version number which must increment
[11:20] <cooloney> apw: thanks
[11:20] <apw> so build2 is a common way, you can use build3 etc when it fails again
[11:20] <apw> though as a general rule, where i am testing sometihng i will upload as -10.20 i use ~pre1 ~pre2 as i go and never use the real number
[11:21] <apw> allowing that to only appear in the main archive.  that way someone running my test version is decernable as against the official build
[11:22] <cooloney> apw: ok, understood. so normally, for this change, will you commit it into the kernel git?
[11:22] <cooloney> apw: i think we just change the name for upload
[11:25] <apw> cooloney, just for the upload yes
[11:26] <cooloney> apw: thanks, man
[11:26] <lag> apw: bug 569882
[11:26] <ubot2> Launchpad bug 569882 in linux (Ubuntu) (and 1 other project) "Suspend Lenovo Thinkpad X61 with card in SD card reader (affects: 3) (heat: 24)" [Undecided,In progress] https://launchpad.net/bugs/569882
[11:27] <apw> smb-afk, this looks to be a duplicate of your MMC card crashy on suspend bug ... 
[11:27] <apw> bug #477106
[11:27] <ubot2> Launchpad bug 477106 in linux (Ubuntu) "[regression] lucid alpha-2 and earlier freeze upon suspend with sd card plugged in with some hardware (affects: 76) (dups: 15) (heat: 526)" [Medium,Confirmed] https://launchpad.net/bugs/477106
[11:44]  * pgraner yawns and blinks
[11:47] <apw> morning pgraner 
[11:47] <pgraner> apw: sup man?
[11:47] <apw> just chilling ... nothing speical
[11:49] <pgraner> apw: Updated my primary desktop Maverick... and well I'm bleeding a bit, not called bleeding edge for nothing!
[11:49] <apw> pgraner, you are mad :)
[11:51] <pgraner> apw: not bad, other than I loose my mouse about once an hour and I have to reboot. X is working fine, keyboard, just the mouse locks up unplugging shows in demsg but X never picks it up again
[11:51] <pgraner> apw: and evolution keeps crashing on startup
[11:52] <amitk> pgraner: switched back to evo?
[11:52] <apw> mouse> interesting ... in lucid i am pretty sure i lose my mount and sometimes external keyboard but a USB unplug replug works there
[11:53] <apw> mouse
[11:53] <apw> pgraner, i actually use a VT switch to 1 and back to restore them too sometimes
[12:02] <pgraner> apw: not here, I've even tried forcing a suspend/resume to see if that would shake it loose but nothing
[12:31] <smb> apw, mcc thingy sounds similar, yeap
[12:31] <smb> mmc even
[12:31] <apw> smb sounds like lag has made some progess isolating it too
[12:32] <apw> so perhaps you can palm it off on him :)
[12:32] <smb> Oh he is always free to fix it. I can test if he has something. :)
[12:33] <smb> Is there something in the scrollback (about what it could be)?
[12:33] <lag> smb, apw: Okay, I'll crack on with it then
[12:46] <apw> smb, he has identified a module that if you rmmod it on suspend and modprobe it on result it doesn't blammo <- about right lag ?
[12:46] <apw> which probabally tells us which suspend/resume callbacks are broked
[12:48] <smb> Hm, ok. I am not sure there is a rmmod in the case I looked at. But it might still be related.
[12:49] <lag> It's not an rmmod per-say
[12:50] <lag> You can tell PM to unload/reload modules on suspend/resume via a config file
[12:50] <apw> i thought you added it to the pm-suspend list
[12:50] <apw> right and that makes it rmmod on suspend and modprobe on resume
[12:50] <lag> I did so and fixed the errors on my ThinkPad
[12:50] <lag> Correct
[12:50] <apw> right ... so its likely the suspend callback on that driver thats blowing chunks
[12:51] <lag> I don't know the inner workings, but I would have thought so
[12:51] <apw> as when the module is removed it does not blow chunks, which avoids that callback
[12:51] <smb> or rmmoding adds another sync-wait point
[12:51] <lag> Which is where my debug code is currently ;)
[12:51] <apw> as the module is not there on suspend
[12:51] <apw> smb, or indeed it may just slow down suspend enough
[12:51] <apw> but i do suspect suspend based borkage
[12:51] <apw> i suspect it panics
[12:52] <lag> I'm in the middle of these theories currently - leave it with me :)
[12:52] <smb> Chances for that are high. But I guess its in good hand with lag :) Just enlighten us when youre finished
[12:53] <apw> yep
[12:55] <lag> It doesn't look like it's even getting to the module's suspend function
[12:55] <lag> It's dieing in the interrupt handler 
[12:56]  * lag gets ready for a new debugging session :)
[12:56]  * lag smiles
[12:57] <cybrocop> Hi all. I'm having a permissions-related problem with qemu/kvm and I believe it is a kernel related issue (through process of elimination). I would really value insight from members of this group. 
[12:57] <cybrocop> http://open.eucalyptus.com/forum/libvirt-operation-failed-failed-retrieve-chardev-info-qemu-info-chardev
[12:58] <cybrocop> Both apparmor and selinux are disabled with kernel boot parameters... yet for some reason, kvm cannot get permission to open a simple file for logging the console.
[12:59] <apw> cybrocop, which file is it, what filesystem type is it on
[12:59] <cybrocop> apw: filesystem is ext4
[13:00] <apw> is that inside or outside the KVM instance?
[13:00] <cybrocop> Whenever I include this as part of libvirt.xml, kvm fails to start: http://slexy.org/raw/s20HiyArHA
[13:01] <cybrocop> libvirt is unable to create the "serial" device and thus kvm fails to start.
[13:01] <apw> gah xml, now i remember why i work on the kernel
[13:01] <apw> what does ls -l on that file say, and on the containing directory?
[13:01] <aquarius> apw, ping?
[13:01] <apw> hi
[13:02] <aquarius> pgraner said I should ping you :)
[13:02] <aquarius> imagine I have a USB stick which, when plugged in, says lots of "device not accepting address 13, error -71" in dmesg, and doesn't mount
[13:02] <apw> cybrocop, what generates that fragment
[13:02] <cybrocop> apw: the file doesn't exist (wasn't able to be created).  here is "ls -al"    http://slexy.org/view/s2LWfnYhXw
[13:02] <aquarius> (or get a device name or anything)
[13:02] <aquarius> is there any way to get the data off it?
[13:03] <apw> aquarius, well i would try it on a different machine, and on an older kernel to confirm its not s/w related, but generally i've foudn that behaviour to be 'bad'
[13:03] <aquarius> apw, it's not s/w related; fails under Windows too (that's where it failed originally, so it was brought to an Ubuntu machine to see if that helped)
[13:03] <apw> aquarius, that is assuming that at some point it has worked in the past of course
[13:04] <aquarius> yeah, it used to work :)
[13:04] <cybrocop> apw:  that fragment is part of the full libvirt.xml...  Eucalyptus generates teh XML file and that is supposed to launch a VM instance. It contains the definitions for the VM instance, to be used by libvirt. Here is the full libvirt.xml     http://slexy.org/raw/s2KPFinewG
[13:04] <aquarius> I have given the owner a little lecture about not keeping your *only* copy of files on a usb stick.
[13:04] <apw> aquarius, i would be suspicious it is sick at the h/w level then sadly ... as its refusing to take an address at the USB level
[13:05] <aquarius> apw, so it's just broken and there's nothing that can be done about it? bah. That's what I thought, but I didn't know if there were Secret Things that could be done
[13:05] <apw> i don't know of any way to talk to it if its really not having an address, thats kinda the first step
[13:05] <apw> cking, know any magic to get a usb stick which is refusing addresses on both win and ubuntu to play ball?
[13:06] <apw> cybrocop, ok the sensible debugging step would be to get an strace off the startup sequence to see what the open it tried did and said
[13:06] <cybrocop> apw: Basically libvirt/kvm tries to create that file in order to map it to the serial port for the VM instance. I suspect it cannot create the file and thus KVM errors out... 
[13:07] <apw> cybrocop, i have no idea whether you can get to it do do that or not, have you brought this up on #ubuntu-server, they are the ucalyptus experts
[13:07] <apw> cybrocop, if not then we should move over there and get their input
[13:08] <cybrocop> apw: I have spent many hours on #eucalyptus and they have tried to debug this with me to no avail.  #ubuntu-server didn't provide any insight. 
[13:08] <apw> well i see nothing in the directory settings which is unusual.  if basic permissions didn't work on ext4 i think we would have noticed by now
[13:09] <apw> cybrocop, so the next step is to get a trace off of the thing as it tries to start, normally i use strace for that -- strace -o /tmp/TRACE -f -e 'trace=open' <command which makes it happen>
[13:09] <apw> something like that
[13:09] <cybrocop> apw: The consensus (and I agree) is that Eucalyptus is not responsible for this as it tries to fire a KVM instance. Eucalyptus is eliminated as a culprit because I try to launch it manually using virsh and it fails.
[13:09] <cybrocop> apw: Thank a lot, I'll try that.
[13:10] <apw> cybrocop, use the very simplest command you can to start it for sure
[13:10] <apw> and then the output should be all files opened, looking for the open which is to that file
[13:10]  * lag 's new GIT book as arrived :D
[13:10] <apw> $DEITY help us all
[13:11] <lag> ;)
[13:12] <jk-> soon you'll be commiting by editing .git/objects/** directly
[13:12] <jk-> working trees are for chumps
[13:13]  * apw imagines doing the sha1's in his head
[13:14]  * lag is still confused, as he hasn't yet read the book and has no idea what they $PLACE_BAD_PEOPLE_GO you're on about!
[13:14] <lag> the*
[13:15] <cking> apw, no idea how to fix a misbehaving USB stick that looks dead
[13:16] <apw> cking, yeah i think so too ... ouch
[13:16] <cking> what does the kernel say when it's plugged in
[13:16] <cybrocop> apw: Here's the output.. http://slexy.org/raw/s2FmLeuYdM  Is it possible that virsh is firing off another process which isn't monitored by strace?
[13:18] <jk-> cybrocop: the other process could be started by the libvirtd daemon
[13:18]  * jk- doesn't have much context
[13:20] <cybrocop> jk: can I attach strace to a running proc?
[13:23] <jk-> sure can, strace -p <pid>
[13:23] <aquarius> cking, the kernel says lots of "device not accepting address 13, error -71" when the USB stick is plugged in
[13:24] <cking> aquarius, tried the USB stick in a different machine just in case it's not the USB stick?
[13:24] <jk-> -EPROTO ?
[13:26] <aquarius> cking, yep -- failed under windows in one machine, failed under ubuntu in another
[13:26] <cking> sounds like broken H/W to me
[13:26] <ogra> you shouldnt use your usb keys as swap space ;)
[13:27] <aquarius> cking, thanks :)
[13:27]  * manjo says N900 got a maemo 5 update, disable extra-devel extra-testing before you do an upgrade, or you might not have enough space on rootfs
[13:27] <ogra> manjo, bah, to late, already running 
[13:28] <manjo> ogra, ota in the us was today
[13:28] <ogra> here too
[13:28] <manjo> :) you have some lead time on me 
[13:29] <ogra> yeah, but only got around to click the button 1/2h ago
[13:29] <manjo> ogra, :) N900 won't get the meego update 
[13:29] <ogra> i dont want meego
[13:29] <amitk> :)
[13:30] <manjo> this is probably the last update to maemo
[13:30]  * ogra is happy with maemo 
[13:30] <cybrocop> jk / apw: it was indeed libvirtd that is starting it. Here is the command I used:  strace -o /tmp/TRACE -f -e 'trace=open' -p 945
[13:30]  * ogra wishes the new arm project would take over maemo :)
[13:30] <cybrocop> jk / apw: Then I ran this from another shell: http://slexy.org/view/s2jndz6OKP
[13:31]  * manjo wants andriod 2.2 on N900
[13:31] <ogra> bah
[13:31]  * manjo want to dual boot 
[13:32]  * ogra just wants ubuntu based maemo
[13:32] <cybrocop> jk / apw: Then I detailed by Ctrl-C. Here is the output of /tmp/TRACE   http://slexy.org/raw/s2u2zWu5Ur
[13:32] <cybrocop> detailed -> detached
[13:32] <jk-> cybrocop: so libvirtd does not have access to console.log ?
[13:33] <apw> cybrocop, right who is that daemon running as ?
[13:33] <cybrocop> No, which is very puzzling... 
[13:33] <cybrocop> root       945     1  0 14:48 ?        00:00:00 /usr/sbin/libvirtd -d
[13:34] <jk-> does it drop privs at any point
[13:34] <jk-> ?
[13:34] <apw> need to know its real ids
[13:34] <cybrocop> It should (according to the advertisement) drop privs to libvirt-qemu:libvirtd
[13:34] <cybrocop> root@srv-uec-qa-node02:~# grep libvirt /etc/passwd /etc/group
[13:35] <jk-> strace -e trace=open,setuid,seteuid [...]
[13:35] <cybrocop> jk: let me try with those options.
[13:35] <apw> cybrocop, you can tell from /proc
[13:36] <jk-> apw: provided he can catch the spawned process in time :)
[13:36] <cybrocop> apw: can you be more specific? Does it contain a history of setuid/setgid?
[13:36] <cybrocop> jk: correct, the spawned process dies quickly.
[13:37] <apw> cat /proc/945/status and grep for Uid and Gid
[13:38] <apw> jk its possible it has d already
[13:38] <apw> jk it is possible that it has dropped them already
[13:38] <apw> cybrocop, if the docs are right then the permissions it runs them as doesn't have open right in there does it?
[13:38] <cybrocop> root@srv-uec-qa-node02:~# cat /proc/945/status |grep -i -e "uid" -e "gid"
[13:38] <cybrocop> Tgid:	945
[13:38] <cybrocop> Uid:	0	0	0	0
[13:38] <cybrocop> Gid:	0	0	0	0
[13:39] <jk-> ok, so console.log (and the parent directories) need to be accessible by that user
[13:39] <apw> yeah unless libvirt-qemu is in eucalyptus group then its not going to work is it\?
[13:39] <apw> so check if its a member of that, if not then the permissions checks are working as expected
[13:39] <cybrocop> jk / apw: I am running the command as root
[13:40] <apw> and something is owned by the wrong person
[13:40] <apw> cybrocop, but the docs tell you it demotese self to libvirtsomething didn't you just say
[13:40] <cybrocop> jk: "that user"  uid=0 ?
[13:40] <jk-> cybrocop: it doesn't matter who is running the command
[13:40] <jk-> "that user" = the user that libvirtd is setuid-ing to
[13:41] <apw> and the docs you just pasted told us who it was
[13:42] <cybrocop> jk /awo:   this is from /etc/group   -   libvirtd:x:114:olm,eucalyptus
[13:42] <apw> thats not the user you pasted above though
[13:42] <apw> libvirtd-qemu you said
 It should (according to the advertisement) drop privs to libvirt-qemu:libvirtd
[13:44] <cybrocop> apw: Let me do an strace and get the exact user. Sorry for the confusion. I thought i may be libvirtd-qemu, but I have to admit it is not from docs, just my memory.
[13:44] <apw> cybrocop, ok
[13:46] <cybrocop> jk: hmm... what am I doing wrong here
[13:46] <cybrocop> jk: root@srv-uec-qa-node02:~# strace -o /tmp/TRACE -f -e 'trace=open,setuid,seteuid' -p 945
[13:46] <cybrocop> strace: invalid system call `seteuid'
[13:47] <jk-> my bad, remove seteuid
[13:47] <cybrocop> jk: ok
[13:49] <cybrocop> jk / apw: I don't see any setuid  http://slexy.org/raw/s21B2A4Dlo
[13:50] <cybrocop> furthermore, I remember, that when I set the path of the file to be /tmp/console.log (in libvirt.xml) the owner of the file was root
[13:50] <sokeman> does anyone have a touch screen running in lucid?
[13:50] <apw> sokeman, yes
[13:51] <sokeman> i think i know how you did it but i have a proble,
[13:51] <sokeman> problem*
[13:51] <apw> cybrocop, does chacl -l say anything on any of the paths ?
[13:52] <cybrocop> acl package was not installed. Should I get it?
[13:52] <sokeman> lol its not installed
[13:53] <sokeman> i had it working (kinda)
[13:53] <cybrocop> root@srv-uec-qa-node02:/var/lib/eucalyptus/instances/admin/i-37DA0723# chacl -l .
[13:53] <cybrocop> chacl: cannot get access ACL on '.': Operation not supported
[13:53] <sokeman> it was clicking where i touched but it also click at the same moment the top left hand corner
[13:54] <cybrocop> apw: I downloaded the acl package and above is the output.
[13:54] <cking> lag, If our instruction modifies memory in an unpredictable fashion, add "memory" to the list of clobbered registers. This will cause GCC to not keep memory values cached in registers across the assembler instruction. We also have to add the volatile keyword if the memory affected is not listed in the inputs or outputs of the asm. 
[13:55] <cking> lag, http://www.ibiblio.org/gferg/ldp/GCC-Inline-Assembly-HOWTO.html
[13:55] <sokeman> before i even installed anything it clicked the topleft hand corner when i touch it and know i have deleted everything it still does it
[13:55] <cybrocop> jk / apw: I just changed the path to "/tmp/console.log" to be sure... and it is indeed running as root. 
[13:55] <cybrocop> root@srv-uec-qa-node02:/var/lib/eucalyptus/instances/admin/i-37DA0723# ls -l /tmp/console.log 
[13:55] <cybrocop> -rw-r--r-- 1 root root 36541 2010-05-26 17:55 /tmp/console.log
[13:58] <sokeman> apw: how can i find the driver that is seeing the input from the touch screen?
[14:00] <lag> apw: #define barrier() __asm__ __volatile__("": : :"memory")
[14:14] <apw> sokeman, do you know what type of touch screen it is ?
[14:15] <apw> bah where did cybro... go
[14:17] <sokeman> no i dont 
[14:17] <sokeman> how can i find out?
[14:19] <sokeman> apw: is there a way to find out?
[14:20] <apw> cnd, how does one find out which touch driver you are using
[14:22] <apw> Keybuk, is there an easy way to tell what was passed to upstart
[14:23] <apw> Keybuk, ignore me, of course i can check its cmdline and environ
[14:23] <ogra> manjo, eeek, my n900 has a progressbar on boot now !
[14:23] <manjo> ogra, yep I noticed that too 
[14:23] <JFo> heh
[14:23] <ogra> how ugly 
[14:23] <manjo> which means its loading more s**t 
[14:24] <JFo> did you guys see the slide to unlock bar?
[14:24] <ogra> bah and i get an ovi ad in the face right after booting
[14:26] <ogra> hrm, and my theme is blue now
[14:26]  * ogra hates blue
[14:26] <manjo> ogra, I use humanity theme
[14:26] <JFo> what did you guys update with?
[14:26] <JFo> mine is still the same
[14:26] <manjo> JFo, he probably kept the default theme
[14:26] <JFo> ah
[14:27] <apw> an _ad_ sounds a bit off ?  
[14:27] <ogra> manjo, nope
[14:27] <manjo> JFo, were you able to get portrait mode working ? 
[14:27] <JFo> what do you mean?
[14:27] <ogra> i had something brownish/yellowish 
[14:28] <manjo> ogra, probably the EU roms are different 
[14:28] <manjo> JFo, the browser is supposed to have portrait mode
[14:28] <JFo> interesting, I never tried it
[14:28]  * JFo experiments
[14:29] <amitk> ogra: how did you manage to get all of that? scratch install? I just upgraded...
[14:29] <ogra> manjo, i was using the shipped digital nature theme but with a different wallpaper
[14:30] <ogra> and apparently it switched back to the default blue theme after the upgrade
[14:30] <amitk> you could do a "apt-get update; apt-get dist-upgrade" btw
[14:30] <ogra> but keeping the wallpaper
[14:30] <smb> bjf, Oh, other channel talk reminds me. I sent you a mail about the lbm alsa updates for lucid. Have I just missed it or did you not reply?
[14:31] <ogra> switching back to the digital nature theme gets me the right widget color but i forgot how i changed the wallpaper :P
[14:31] <manjo> amitk, how do I get portrait mode in the browser 
[14:33] <JFo> oh hey lag you may have noticed that I set some tix you are assigned to In Progress
[14:34] <amitk> manjo: Ctrl+Shift+R enable it
[14:35] <lag> JFO: Yep, got those, thanks
[14:35] <JFo> :-)
[14:35] <amitk> manjo: in browser, you need to enable it in settings too
[14:36] <lag> JFo: I removed "kernel-suspend" and added "suspend resume" and "kernel-power" - I think that is correct
[14:36] <JFo> k
[14:36] <lag> JFo: That's the way it's documented in any case
[14:36] <lag> =:-)
[14:37] <apw> Keybuk, hey ... am a bit worried about this passing everything to init patch.  although it makes sense to 'init' passing all that crap to bash will not make it happy
[14:41] <cybrocop> apw / jk : Sorry, had a power outage and dropped off. Did you respond to me by any chance?
[14:41] <JFo> lag, you are correct
[14:41] <cybrocop> apw / jk : Last thing I tried was to do an strace and capture getuid, but there was no observed dropping of privs. effective uid is root it seems. 
[14:43] <apw> cybrocop, did you get just a full trace ?  without -e, if you could get than and pastebin it so i can look that would help
[14:44] <lag> Thanks for confirming JFo
[14:44] <cybrocop> apw, I'll do that. Right now there is still no power so the servers are down, but should come back within 30 mins.
[14:44] <apw> cybrocop, ok
[14:45] <JFo> lag, my pleasure, but you already knew you were right ;-0
[14:45]  * JFo fusses at his right shift key
[14:45] <pgraner> jk-: did you get the conf stuff setup?
[14:46] <cnd> apw: you can check Xorg.0.log and grep for evdev
[14:47] <cnd> that will show you all the /dev/input/event* files that are used for input
[14:47] <cnd> then you can correlate those with lsinput
[14:47] <cnd> but I don't know if you want info on input drivers that don't use evdev
[14:48] <lag> JFo: Not true, I was meaning to ask you about it (lag==newbie - JFo==old_hand)
[14:49] <JFo> heh
[14:50] <cnd> lag, back on my first week in february, I went up to JFo and started asking him questions, and after a few "I'm not sure..." answers, he said he had only been here for three weeks up to that point :)
[14:50] <cnd> old hands means you've been here a few weeks, so you'll be old hand pretty soon :)
[14:51] <JFo> heh
[14:51] <JFo> yeah, I remember that cnd :-)
[14:52] <lag> People age quick here eh?!
[14:52] <lag> :)
[14:53] <amitk> lag: hair is acceptable loss in the line of duty
[14:54] <lag> I've noticed ;)
[14:54] <amitk> lag: I am sure you're not referring to apw here, he joined that way ;)
[14:55] <lag> *whistles*
[14:55]  * lag whistles 
[14:56]  * apw rounds up a firing squad
[14:58]  * lag retires to the shadows with smb
[14:59] <amitk> :)
[14:59] <Fjodor> Quick question: Does anyone know what's up with the source packages at http://kernel.ubuntu.com/~kernel-ppa?
[15:01] <cnd> RAOF: so what will happen if I try to upgrade my nouveau machine to a maverick kernel?
[15:02]  * lag treats himself to a lunch break for a change
[15:02] <lag> bbs
[15:02] <cnd> will it just work (like tgardner's), or do I need to update libdrm as well?
[15:03] <tgardner> cnd, just try the maverick .deb first
[15:03] <cnd> tgardner: ok, I'll try it out
[15:04] <apw> Fjodor, what is your issue with them?
[15:05] <Fjodor> apw: Well, mainly that they are in the low kb size area, so I suspect them to be rather empty ;-)
[15:06] <apw> JFo, i had a thought when reviewing my 'kernel-needs-review' bugs ... and tagged those i wanted as kernel-candidate
[15:06] <apw> JFo, is we all did that you'd be able to find them easy and review of them by us on monday if needed would be easy
[15:07] <apw> Fjodor, bah
[15:07] <JFo> yep, sounds great
[15:07] <Fjodor> apw: ?
[15:07] <apw> Fjodor, bah
[15:07] <apw> i hate the mainline builds, there is always something or other wrong with them
[15:07] <JFo> I was actually thinking we could use the kernel-needs-review as a method for me to present the ones I think need to be looked at to the reviewers
[15:08] <apw> JFo, that is indeed what i means isn't it ?
[15:08] <JFo> apw, I saw a comment that they were empty in a bug yesterday
[15:08] <JFo> apw, indeed
[15:08] <apw> i look at -needs-review and convert them all to  either -reviewed or -reviewed and -candidate
[15:08] <JFo> so the system seems to be working :)
[15:09] <JFo> I like it
[15:09] <JFo> want me to add -candidate to the tagging page|?
[15:09] <apw> and then you take the -candidates and add them to the list and we discuss the overflow on mondays
[15:09] <JFo> sounds good
[15:09] <apw> that way random bugs can't put themselves on the list, cause you are in the middle, but its all simple other than that step
[15:09] <JFo> apw, ogasawara got the script done, so I am testing it now
[15:10] <JFo> apw, yep
[15:10] <apw> JFo, awsome
[15:10] <Fjodor> apw: Ah ok, that sort of "bah". It's just that I have run into the otherwise known problem of qemu vms running extremely slow, have seen that increasing the tick frequency might help, and would like to try out a kernel as close to mainline as possible with that as the only change. At any rate, the source packages still should be built correctly, even if you dislike them, shouldn't hey?
[15:13] <apw> Fjodor, i didn't say anything about the problem, only that i hate the builds en toto because they create a lot of work for me keeping them working
[15:14] <JFo> brb
[15:16] <Fjodor> apw: Ah, ok, but my question, then, would be "Who is responsible for the builds, whom I can talk to to get the source packages built correctly?" :-)
[15:16] <apw> Fjodor, the other problem is the source package there is not a source package which can be used to build a deb. it is a raw source tree
[15:16] <apw> and so even when i fix them, the next complaint will be that they are not what you wanted
[15:16] <apw> Fjodor, i look after them
[15:17] <apw> Fjodor, i assume you actually want to be able to build a kernel deb for yourself
[15:19] <apw> Fjodor, ?
[15:19] <Fjodor> apw: Well, I know how to use make-kpkg and such, as I have done so extensively on earlier occasions - I just wanted to install the sources via a source package from you, since I then gather that the sources would be the same as the ones used to produce the image debs :-)
[15:19] <apw> Fjodor, unfortuanatly a -source package is only the linus source
[15:20] <apw> and the linus source is exactly as it is in linus tree, at the commit mentioned so you can recover that easily
[15:20] <apw> it does not give you the build machinary however
[15:20] <apw> the BUILD.LOG contains the exactly commit that was built from
[15:21] <Fjodor> apw: Ok, thank you - so there aren't any ubuntu specific patches applied to the sources that it would be easier for me to get in one package via you, as opposed to pulling a vanilla linux tree?
[15:22] <apw> Fjodor, nope, the point of the mainline builds for testing is that they have no ubuntu delta, the only thing they have is an ubuntu style config
[15:23] <Fjodor> apw: Ok, great - still, I noticed that I'm not the only one asking about the source packages on the ml - just saying. Thank you, though, I'll pull a vanilla tree :-)
[15:24] <apw> Fjodor, yeah i'll put it on my todo list, though i will get moaned at they are useless next
[15:25] <apw> i suspect not making them would make more sense, and makeing either a real source uploadable package or a tarball of the clean build tree would be of more value space wise
[15:26] <Fjodor> apw: Well, just the tarball would have been enough for me, and as for them being useless, well, that was not my understanding or the case for my specific wants, but thank you for the answers :-)
[15:31] <cnd> tgardner: when setting the version for an update to the linux-firmware* packages in lucid-updates, I remember there being an issue where the version had to be bumped like 1.24 to 1.25.1
[15:31] <cnd> is that correct?
[15:32] <tgardner> cnd, nope, it should be 1.24.1
[15:32] <cnd> I see that's what happened for linux-firmware-nonfree in karmic-updates, but the normal version incrementing took place for linux-firmware in karmic-updates
[15:36] <Keybuk> apw: but the kernel already passes anything it doesn't know to bash
[15:36] <Keybuk> so bash has to handle it
[15:36] <apw> right but nominally that is nothing right
[15:36] <Keybuk> if you do init=/bin/bash foo bar baz then you deserve to break it ;)
[15:36] <Keybuk> ahh
[15:37] <Keybuk> right, so when you do init= only the arguments *after* init are passed
[15:37] <Keybuk> we want to preserve _that_ behaviour
[15:37] <Keybuk> it's when you have no init= on the command-line, it passes everything it doesn't know - we want that to just pass everything
[15:37] <Keybuk> so "default init" if you like
[15:37] <apw> well actually i think all unknown ones are passed, but the majority of options are known
[15:37] <Keybuk> apw: no, init= does limit it to only those after init=
[15:37]  * ogra wants console= 
[15:37] <apw> the problem is that the semantics change as you drop down
[15:37] <ogra> :)
[15:38] <apw> Keybuk, you sure, i haven't seen the code which does that anywhere
[15:38] <Keybuk> apw: almost entirely positive
[15:38] <apw> the real issue is that the behaviour changes as you fall down the list
[15:39] <apw> we may want to pass 'all' to */init, but 'minimal' to /bin/bash and /bin/sh
[15:40] <apw> Keybuk, ok found the code which does init=
[15:40] <apw> Keybuk, and yes it does zap 'before'
[15:40] <apw> but that doesn't work for the default case
[15:40] <apw> Keybuk, one option might be to not pass them on the command line
[15:40] <apw> but make them into environment variables
[15:40] <apw> in the 'all' mode
[15:41] <apw> so if there is no arg we do like 'quiet=true' in the environment instead
[15:41] <Keybuk> apw: the default case will never be bash though
[15:41] <apw> that would maintain the command line semantics
[15:42] <Keybuk> I don't see the problem with the default case passing the "known" command-line options as well as the unknown ones
[15:42] <Keybuk> right, I don't *want* to maintain the command line semantics
[15:42] <apw> Keybuk, right but to allow fallback which will work i need to make and maintain _two_ command lines
[15:42] <Keybuk> I want to change them
[15:42] <apw> right but the semantics are compatible with /bin/bash and /bin/sh right now
[15:42] <Keybuk> why the fallback?
[15:42] <apw> so we can literrally do
[15:42] <apw> exec '/sbin/inint'
[15:43] <Keybuk> but you can't have /bin/bash as init= without passing init= which *changes* the semantics anyway
[15:43] <apw> exec '/init'
[15:43] <apw> exec '/bin/bash'
[15:43] <Keybuk> yes, but that's a bash script
[15:43] <apw> exec '/bin/sh'
[15:43] <Keybuk> not /bin/bash
[15:43] <Keybuk> so won't pass any of the arguments
[15:43] <apw> yes but that is a different path
[15:43] <Keybuk> if you copied /bin/bash *to* /sbin/init - then yes, it would cause unknown arguments to get passed to bash
[15:43] <Keybuk> but nobody ever does that
[15:43] <apw> if you say init= then we do bash semantics for everything
[15:44] <apw> if you don't then we do run init, and fallback to bash using the same semantics
[15:44] <Keybuk> if you say init= only the arguments on the command-line *after* init= should be considered
[15:44] <Keybuk> what?
[15:44] <Keybuk> we don't fallback to bash!
[15:44] <apw> yes we do
[15:44] <Keybuk> if the kernel doesn't see /sbin/init, it falls back to bash?
[15:44] <apw>         run_init_process("/sbin/init");
[15:44] <apw>         run_init_process("/etc/init");
[15:44] <apw>         run_init_process("/bin/init");
[15:44] <apw>         run_init_process("/bin/sh");
[15:44] <Keybuk> oh, wow, I didn't know that :p
[15:44] <apw> that has always be the way in unix world
[15:44]  * ogra never saw that working
[15:45] <ogra> it usually panicks before it gets there
[15:45] <apw> and its that semantic which we break if we pass everythign on the command line
[15:45] <Keybuk> apw: hmm, but that would break today anyway right?
[15:45] <Keybuk> because the kernel would still pass "splash" to bash
[15:45] <Keybuk> so would really run "/bin/sh splash"
[15:45] <apw> that is possible yes
[15:46] <Keybuk> and would break in recovery mode
[15:46] <Keybuk> because it would run "/bin/sh single"
[15:47]  * apw considers, it does appear so
[15:47] <apw> unless single is known which i assume it cannot be
[15:47] <apw> so the fallbacks are just useless
[15:48] <ogra> apw, so why do i get a panic if i rm /sbin/init and dont end up at a shell 
[15:48] <ogra> with the above i should never see a kernel panic caused by init missin
[15:48] <apw> ogra, perhaps because you have splash on the command line, as Keybuk points out
[15:49] <ogra> i dont think it tries to actually spawn the shell 
[15:49] <Keybuk> apw: it can't be known, since otherwise init wouldn't see it ;-)
[15:50] <apw> right
[15:50] <apw> so its mostly useless
[15:51] <apw> Keybuk, so it is possible we need an early_param to turn off this new behaviour just in case
[15:51] <apw> no we have init= to fix everything
[15:54] <Keybuk> right, init= fixes everything, no?
[15:54] <Keybuk> you can always stick init=/sbin/sulogin on the end
[15:55] <apw> Keybuk, yep that override makes me happy, thanks
[16:06] <vanhoof> ogasawara: ping
[16:12] <ogasawara> vanhoof: pong
[16:13] <bjf> moin all
[16:15] <JFo> moin bjf 
[16:15] <vanhoof> ogasawara: lmk when you have a few to talk, i know its early for you
[16:15] <ogasawara> vanhoof: I have time now
[16:15] <JFo> aw lookit vanhoof trying to get some time with the release queen :)
[16:16] <vanhoof> ogasawara: cool
[16:16] <ogasawara> vanhoof: mumble?
[16:16] <apw> i don't see him doing enough bowing
[16:16]  * vanhoof bows
[16:16] <vanhoof> apw: hey, ogasawara became my best friend last night ;)
[16:19] <bjf> JFo, you going to expire some more today? I've done all I can for now
[16:19] <JFo> yeah
[16:19] <JFo> not sure how many though
[16:20] <JFo> looks like I'm still hitting some vague limit on how many I can process
[16:20] <bjf> JFo, just remove the limit and let it do all with the given params
[16:20] <apw> JFo, where is that chart again ?
[16:20] <bjf> JFo, http://status.qa.ubuntu.com/qapkgstatus/linux
[16:20] <JFo> bjf, i have
[16:20] <bjf> http://status.qa.ubuntu.com/qapkgstatus/alsa-driver
[16:21] <apw> JFo, any idea why there is going to be a jump in triaged bugs ?
[16:21] <bjf> JFo, are you running it on cranberry?
[16:21] <JFo> bjf, no on my local machine
[16:21] <JFo> apw, because I am setting some to triaged
[16:22] <apw> JFo, heh ahh then that makes sense
[16:22] <JFo> bjf, I wish the linux graph looked more like that :)
[16:22] <JFo> apw, yeah, I have been trying to use triaged appropriately, but I need to define its role in our plans
[16:22] <bjf> JFo, don't understand why the connected yellow line didn't connect
[16:23] <JFo> it hasn't run it's daily yet
[16:24] <cybrocop_> Hi apw, finally got the trace. Are you around?
[16:24] <apw> yep
[16:24] <apw> pastebin it
[16:25] <cybrocop_> apw: Here  http://slexy.org/raw/s2I1ZYzm8k
[16:25] <cybrocop_> search for console.log
[16:30] <bjf> JFo, check out bug 466716 (the last comment after I expired the bug)
[16:30] <ubot2> Launchpad bug 466716 in alsa-driver (Ubuntu) "No sound after upgrading to 9.10 desktop from 9.04 desktop. (affects: 16)" [Undecided,Expired] https://launchpad.net/bugs/466716
[16:30] <cybrocop_> apw, let me change the location of the file to /tmp/console and you can compare it with a successful run.
[16:30] <bjf> JFo, the username is "special" and the comment means nothing to me
[16:31] <JFo> heh
[16:32] <apw> cybrocop_, it think this is your issue, this is running as root yes, but it also capsets itself into a non-priviledged state
[16:32] <JFo> well, I am out for a bit of lunch goodness away from the house. bbiab
[16:33] <apw> 9600  capset(0x20080522, 9600, {0, 0, 0}) = 0
[16:34] <cybrocop_> So it has something to do with cgroups?
[16:36] <apw> no it has something to do with capabilities, it appears the server is deliberatly dropping its priviledges
[16:36] <apw> which means that it run as uid with none of the advantages, so if root is not in the group it cannot write there
[16:36] <apw>        CAP_DAC_OVERRIDE
[16:36] <apw>               Bypass file read, write, and execute permission checks.  (DAC is
[16:36] <apw>               an abbreviation of "discretionary access control".)
[16:37] <apw> specifically it has dropped that capability, so root no longer has its 'all your files are mine' ability
[16:38] <apw> cybrocop_, it seems like a bug in the way the services are owned to me
[16:39] <apw> cybrocop_, i would tend to blame ecalyptus, where do they hang out
[16:40] <cybrocop_> apw, hmm. they are on #eucalyptus
[16:40] <cybrocop_> but kvm is not eucalyptus
[16:40] <cybrocop_> It would be more of a kvm/qemu issue no?
[16:41] <ogasawara> JFo: did that new buglist script run ok for you?
[16:42] <cybrocop_> apw: All they're involved in is the creation of the libvirt.xml file, which tells the kvm instance what to do (what devices to have, etc...) 
[16:42] <cybrocop_> apw: here is the libvirt.xml generated by them. http://slexy.org/raw/s2KPFinewG  They don't seem to include any directives that would limit a vm's capabilities
[16:43] <apw> 9600  capset(0x20080522, 9600, {0, 0, 0}) = 0
[16:43] <apw> 9600  execve("/usr/bin/kvm", ["/usr/bin/kvm", "-S", "-M", "pc-0.12", "-enable-kvm", "-m", "896", "-smp", "1", "-name", "i-46D20834", "-uuid", "fe3c868b-861b-bcad-18c6-e5f667c9"..., "-nographic", "-chardev", "socket,id=monitor,path=/var/lib/"..., ...], [/* 2 vars */]) = 0
[16:43] <apw> cybrocop_, its not kvm's fault
[16:43] <cybrocop_> I mean virsh
[16:44] <cybrocop_> I use teh command: virsh start <domain>  ... this communicated with libvirtd... eucalyptus is not involved here.
[16:44] <cybrocop_> apw: I thought libvirtd is the same as kvm... but I guess they're different packages.
[16:45] <apw> ok then its libvirtd thats at fault
[16:47] <cybrocop_> I know there is this new cgroup features (or maybe its called lxc).  Do you think it has something to do with that? Maybe there's a libvirtd config option that specifically limits it this way (I couldn't find anything in the libvirtd.conf).
[16:47] <cybrocop_> apw: for security purposes maybe?
[16:48] <apw> cybrocop_, you are beyond my knowledge of userspace.   all i can see is that the caller of KVM has dropped its creds, so the behaviour is correct, that file is not creatable for a nutered root process
[16:48] <apw> i would think libvirt is under #ubuntu-servers perview
[16:48] <cybrocop_> apw: Thanks a lot. You were very heplful. At least I'm a step closer to identifying the problem.
[16:53] <cnd> cking: is it true that a laptop hanging on the second suspend is a bios bug?
[16:53] <cnd> or is there potentially something we can do in the kernel?
[16:53] <cking> cnd, it depends ;-)
[16:55] <cking> cnd, it could be dodgy drivers or something deeper. 
[16:58] <manjo> cking, can you make your programs exit/return 0 for pass 1 for fail ? 
[16:58] <cking> manjo, 0 = ok, 1 = fail
[16:58] <manjo> 0 for pass and errno for fail which ever makes sense 
[16:59] <cking> manjo, yep
[16:59] <manjo> will you have a situation where the result is unresolved ? 
[17:00] <cking> manjo, don't think so - it's pass or fail
[17:00] <manjo> ok
[17:04] <cnd> cking: can you expand a bit on the suspend issue?
[17:05] <apw> ogasawara, just updated the trend lines for maverick ... approximatly
[17:06] <ogasawara> apw: we're actually below the line!
[17:06] <apw> ogasawara, heh you did close about a months worth of work-items with your upload :)
[17:07] <apw> i don't expect it to stay that way
[17:07] <ogasawara> apw: true.  I suspect this will the the one and only time we're below :)
[17:07] <apw> heh one reason i didn't get the history removed so we can see the work appearing
[17:08] <ogasawara> apw: yah, someone just slammed a kernel config bug to the config blueprint, and it's got over 100 config request changes
[17:08]  * ogasawara just about fell over when I read it
[17:09] <apw> ogasawara, who the heck, whats the bug number ?
[17:09]  * apw frootles about for his gun
[17:10] <ogasawara> apw: don't know who it was, some random bug subscriber who sent me a heads up they linked it to the blueprint
[17:10] <ogasawara> apw: bug 446480
[17:10] <ubot2> Launchpad bug 446480 in linux (Ubuntu) "karmic kernel configuration gotchas... (affects: 2) (heat: 22)" [Medium,Triaged] https://launchpad.net/bugs/446480
[17:11] <apw> ogasawara, karmic ?
[17:12] <ogasawara> apw: originally was targeted for karmic, I'm inclined to rip it from the blueprint
[17:13] <ogasawara> apw: was going to give it a quick once over first to see if the requested config changes are valid for Lucid
[17:14] <cnd> brb, rebooting to a test kernel
[17:14] <ogasawara> s/Lucid/Maverick
[17:16] <apw> i had a look at the 'key critical' ones and they are already as specified
[17:17] <apw> ogasawara, i'd tend to do no more than see which ones are as he has already asked for
[17:18] <apw> and those which are not just ask for justification
[17:18] <apw> i would only do it if you can do it as a script, no handy doing it
[17:18] <ogasawara> apw: ack
[17:19] <apw> ogasawara, and really the two he is bitching about are MCE and PAT i think
[17:19] <apw> and they are as he says
[17:19] <ogasawara> indeed
[17:20] <apw> i recon you could justify saying 'X86_PAT and X86_MCE are both set now as expected.  As we are now two released furter on could you regenerate your list based on the current discrepancies"
[17:20] <apw> "and provice justtification for each"
[17:20] <apw> noting that he has done good justifications for the first two
[17:21] <ogasawara> apw: agreed, I'll slam a comment in there
[17:21] <apw> you have enough shit to do
[17:24] <apw> ogasawara, we maybe below the line overall, we are above it for a-1
[17:24] <anoteng> Anybody here familiar with git-bisecting a ubuntu kernel? I fear I keep building the same packages over and over... Anybody care to take a look at my commands and see if I'm doing anything stupid? http://pastebin.com/Rfif04jx
[17:24] <apw> http://people.canonical.com/~pitti/workitems/maverick/canonical-kernel-team-maverick-alpha-1.html
[17:24] <apw> anoteng, looks right to me
[17:25] <apw> the version number won't change with each bisect i suspect
[17:25] <ogasawara> apw: damn, just a few work items over for a-1.  wonder what I've got I can close.
[17:25] <anoteng> that's what got me worried.. that, and the fact that I've only found good kernels too this point. Will continue like before then...
[17:26] <anoteng> apw: thanks…
[17:26] <apw> we only change the version number at "start new release" a
[17:26] <apw> and at "bump abi"
[17:26] <apw> anoteng, ^
[17:27] <anoteng> ok. thanks..
[17:29] <bjf> cking ping
[17:31] <manjo> smb, have the lbm updates happened ? 
[17:31] <smb> manjo, Lucid, no due to missing bug references
[17:31] <manjo> ok thanks 
[17:33] <manjo> smb, any eta on when we can expect ? I need to update a bug with that info 
[17:35] <smb> manjo, as tgardner had some wireless things to add and with current things going probably mid-next week
[17:36] <manjo> ok thanks 
[17:38] <stenten> is anyone here familiar with bug #404064?
[17:38] <ubot2> Launchpad bug 404064 in linux (Ubuntu Karmic) (and 2 other projects) "KMS error message while intializing modesetting (during boot and resume) - render error detected, EIR: 0x00000010 [i915] (affects: 51) (dups: 3) (heat: 294)" [Medium,Fix released] https://launchpad.net/bugs/404064
[17:39] <cnd> lag: as root:
[17:39] <manjo> lag, https://rt.wiki.kernel.org/index.php/Ftrace
[17:39] <cnd> echo 'function_graph' > /sys/kernel/debug/tracing/current_tracer
[17:39] <lag> http://www.mjmwired.net/kernel/Documentation/trace/ftrace.txt
[17:39] <cnd> then, as root or as normal user, cat /sys/kernel/debug/tracing/trace
[17:39] <stenten> i have another bug (584475) that looks like a duplicate, but the original one i mentioned is already marked as "Fix Released", so I'm not sure how to triage it. Do I re-open the fixed bug?
[17:40] <manjo> stenten, you could dup it 
[17:43] <apw> cnd, fdr binary-perarch
[17:44] <cnd> apw, thanks!
[17:44] <cking> bjf, sorry, missed your ping, I was plowing through some email backlogs
[17:48] <bjf> cking, np, i worked it out myself
[17:48] <stenten> manjo: I've dup'd it and told them to add a comment that they were still affected, and include their kernel version. Thanks.
[17:49] <bjf> cking, i'd just confused myself
[17:49] <cking> bjf, happens to me all the time too when it comes to these webby tools
[17:50] <cking-afk> back in 18
[19:36] <cnd> JFo: ping
[19:42] <kees> how do I create (and push) various topic branches?
[19:43] <kees> more specifically, if I have a clone of linux-2.6, and I have 3 different sets of patches, how do I build up the 3 branches?
[19:43] <cnd> kees: for the master kernel tree?
[19:43] <kees> cnd: yeah.
[19:43] <kees> cnd: I have this: http://kernel.ubuntu.com/git?p=kees/linux-2.6.git;a=summary
[19:43] <kees> cnd: I want to have three branches with a subset of the 5 commits on top there spread out in them.
[19:44] <kees> i.e. "master" would be real upstream master, and I'd have "nx-emu", "symlink", "hardlink" branches.
[19:44]  * kees is such a git newb.  ;)
[19:44] <cnd> kees: why do you want three separate branches? to test each patches individually?
[19:44] <smb> kees, from master you would do a git checkout -b name 
[19:44] <ogasawara> kees: git checkout -b nx-emu
[19:44] <kees> but won't that branch from the current location (instead of HEAD minus 5)?
[19:45] <ogasawara> kees: indeed, will checkout from the tip
[19:45] <cnd> kees, if you want a branch from a specific location, you can "git checkout <sha id of commit> && git checkout -b <new branch name>"
[19:45] <kees> how do I back up?
[19:45] <ogasawara> kees: but once on the branch you could then git reset --hard HEAD~5
[19:45] <kees> ah-ha
[19:45] <smb> kees, I think you want to create the branches from before and then cerry pick
[19:45]  * abogani2 agrees ^
[19:45] <smb> git checkout -b name sha1
[19:45] <cnd> kees: we're giving you three separate ways to do the same thing :)
[19:46] <kees> \o/
[19:46] <cnd> kees: but I still wonder, why do you need three separate branches?
[19:46] <cnd> is it for testing each patch set isolated from the rest?
[19:46] <smb> where sha1 is the sha id of the commit before you added the 5
[19:47] <smb> but what ogasawara said works the same. too many choices. :)
[19:48] <kees> excellent, yes.  working on it now
[19:48] <smb> kees, for pushing you will just say git push repo branch. eg. git push origin version1 
[19:49] <smb> whatever you named your branch
[19:52] <cnd> tgardner: have you uploaded the new linux-firmware package to lucid-proposed?
[19:52] <cnd> I'm going to check for the SRU procedure on the bugs it will fix
[19:52] <tgardner> cnd, its in the queue
[19:53] <cnd> tgardner: thanks
[20:01] <kees> \o/ branch topics of my very own.  :)  thanks guys.
[20:02] <kees> http://kernel.ubuntu.com/git?p=kees/linux-2.6.git;a=heads
[20:05] <tgardner> kees, now you can easily keep your master branch up to date by 'git checkout -f master;git fetch origin master;git reset --hard FETCH_HEAD', then update your branch thusly: 'git checkout -f hardlink;git rebase master'
[20:06] <kees> tgardner: you anticipated my next question.  ;)
[20:07] <kees> tgardner: why the "-f"?
[20:08] <tgardner> kees, force, it overwrites any local changes.
[20:09] <tgardner> kees, my clean sequence to ensure a pristine tree is 'git checkout -f;git clean -f -d;git ls-files --others --directory |xargs rm -rf;rm -rf .git/rebase*'
[20:10] <kees> hm, I think I'll leave off the -f in case I'm a dork and forget something.  :)
[20:10] <tgardner> kees, you can always check using 'git status'
[20:11] <kees> true
[20:11] <kees> oh! one more question... how do I set my "push" target to be ssh+git://zinc....  ?
[20:12] <tgardner> kees, you can either specify the push repo directly, or you can add a remote in order to make it a bit simpler.
[20:12] <kees> i.e. this is wrong:
[20:12] <kees>   Fetch URL: git://kernel.ubuntu.com/kees/linux-2.6.git
[20:12] <kees>   Push  URL: git://kernel.ubuntu.com/kees/linux-2.6.git
[20:12] <kees> the "fetch" is fine, but the "Push" is wrong
[20:12] <tgardner> git:// is read only.
[20:12] <kees> right
[20:13] <tgardner> add a remote like this 'git remote add rtg zinc.canonical.com:/srv/kernel.ubuntu.com/git/rtg/ubuntu-lucid.git'
[20:13] <tgardner> then you can 'git push rtg branch_name'
[20:14] <tgardner> alternately, you could also 'git push zinc.canonical.com:/srv/kernel.ubuntu.com/git/rtg/ubuntu-lucid.git' branch_name'
[20:14] <kees> git remote set-url ?
[20:14] <kees> yeah, I want to avoid the full URL every time I push.
[20:14] <tgardner> kees, I've never used set-url
[20:16] <kees> ah-ha, yes, that did it:
[20:16] <kees> git remote set-url origin ssh+git://zinc/srv/kernel.ubuntu.com/git/kees/linux-2.6.git
[20:16] <tgardner> kees, ok, now you can use a simple 'git push origin hardlink'
[20:18] <tgardner> kees, note that after rebasing your branches against master you'll have to 'git push --force origin hardlink', etc
[20:20] <smb> tgardner, don't teach him that dangerous stuff ;-)
[20:20] <smb> kees, git push origin +branch does the same
[20:21] <tgardner> smb, there is a reason I grant write access to only a few devs
[20:21] <smb> :)
[20:47] <tgardner> kees, with your ptrace patch, what is an example of a process taht I _should_ be able to strace? I'd have thought my login shell would be a child of sshd or bash
[20:51] <JFo> cnd, sorry about that I am back now
[20:53] <cnd> JFo: actually, I think I'm ok
[20:53] <cnd> thanks for getting back to me though :)
[20:53] <JFo> sure, sorry it took so long
[20:53] <tgardner> kees, never mind, I figured it out.
[20:58] <ilpuccio> hello
[20:59] <ilpuccio> I'm on lucid, I'd like to installa kernel 2.6.34 from http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.34-lucid/linux-image-2.6.34-020634-generic_2.6.34-020634_amd64.deb
[21:00] <ilpuccio> but installing nvidia drivers It said that kernel was compiled with gcc 4.2? Is it normal? I'm running 2.6.32 and I have installed nvidia's drivers without any problem
[21:02] <cnd> ilpuccio: the mainline kernel should have been built with the same gcc as the 10.04 kernels are built with
[21:02] <tgardner> ilpuccio, can you use the neoveau driver?
[21:03] <ilpuccio> tgardner, not tried.
[21:03] <ilpuccio> tgardner, is there a way to check the compiler used for the kernel ?
[21:03] <tgardner> ilpuccio, the backported kernel is not intended to support the desktop, but I know for a fact that it still works with nouveau
[21:03] <cnd> tgardner: heh, I just remembered that I'm booted on 2.6.34-4 with nouveau and lucid libdrm :)
[21:04] <cnd> seems to be working fine
[21:05] <ilpuccio> tgardner, I'll try but that are the opensource, right ? It sound strange to me the fact that nvidia detect a different compiler for 2.6.34
[21:06] <tgardner> ilpuccio, you're running lucid, right?
[21:06] <ilpuccio> tgardner, yes
[21:06] <tgardner> the backport was built using the lucid toolchain
[21:06] <manjo> have you guys seen the review on Lucid on toms hardware, it looks pretty good... http://www.tomshardware.com/reviews/ubuntu-10.04-lucid-lynx,2634.html
[21:14] <Sarvatt> can I see your /var/log/Xorg.0.log cnd? :)
[21:19] <kees> tgardner: basically you can ptrace anything that is a direct child, so "strace ls" or "gdb ls" will work.
[21:20] <kees> tgardner: strace -p  and gdb "attach" won't (without sudo)
[21:21] <kees> so, isn't "git push hardlink" the same as "git push origin hardlink" ?  due to the branch tracking?
[21:22] <tgardner> kees, it might be, but its a form I'm unfamiliar with.
[21:35] <ilpuccio> hey guys .... head /usr/src/linux-headers-2.6.32-22-generic/kernel/bounds.s is 4.4
[21:36] <ilpuccio> head linux-headers-2.6.34-020634-generic/kernel/bounds.s is 4.2
[21:45]  * bjf is done for now, his head feels like it's going to explode
[21:45] <ilpuccio> dunno if matters
[21:54] <cnd> mpoirier: https://wiki.ubuntu.com/KernelTeam/KernelBugFixing?highlight=(send\-email)|(git)
[21:57] <ilpuccio> thanks bye bye 
[21:58] <JFo> cnd, that looks like one that could be cleaned up and moved over under Kernel/
[21:58]  * JFo whistles innocently :)
[21:59] <cnd> JFo: heh, it's actually in pretty good shape, but it could use breaking up into sub pages
[21:59] <JFo> :-D
[22:01]  * JFo updates his n900
[22:09] <cnd> JFo: weren't we going to divide up the pages and assign people to migrate them to the new wiki setup?
[22:09] <cnd> I work better when I have tasks assigned to me :)
[22:09] <JFo> yeah, I was just picking on you, but we do need to look at that
[22:09]  * JFo assigns tasks to cnd :-P
[22:10] <cnd> if you want to assign it to me, add a task on a blueprint or send me an email
[22:10] <cnd> otherwise I'll forget :)
[22:17] <JFo> nah, just picking on you
[22:17] <JFo> I want to have some time to discuss it
[22:17] <JFo> maybe tomorrow on mumble
[22:36] <ogasawara> mpoirier: BugLink: http://bugs.launchpad.net/bugs/584920
[22:36] <ubot2> Launchpad bug 584920 in linux-ti-omap (Ubuntu) "netinstall fails, it has no network driver for moschip (affects: 1) (heat: 6)" [Medium,Confirmed]
[22:37] <ogasawara> mpoirier: and Subject I'd suggest "[Lucid] [PATCH] UBUNTU: Fixing ARM Lucid bug 584920"
[22:37] <ubot2> Launchpad bug 584920 in linux-ti-omap (Ubuntu) "netinstall fails, it has no network driver for moschip (affects: 1) (heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/584920
[23:38] <RAOF> cnd: The chances are good that upgrading your nouveau machine to the maverick kernel will work; we've got an appropriate libdrm.