[00:08] inbox zero, seeya tomorrow === sconklin is now known as sconklin-gone === bjf is now known as bjf[afk] [00:35] * manjo bad weather rolling in from the north .. heavy thunderstorms in the area... need to shutdown machine. [02:12] hughhalf: ping [02:12] achiang, ahoy [02:14] must be the nautical hughhalf [02:14] boutcher! [02:14] how goes man ? [02:15] goes great...using a lot of ubuntu in production these days ;-) [02:16] how are things down under? [02:17] hughhalf is totally nautical [02:18] boutcher, good man, good, liking Canonical and life overall goes well :) [02:18] but not sure about jk-- nautical references [02:18] hughhalf excellent....saw some picks of rachel doing linux presenting a while back....she's looking good [02:18] hey boutcher [02:19] boutcher, yeah, she's doing well :) [02:19] hey jk....long time no talk. I'd forgotten you're at canonical too [02:21] or I guess that's jk-- [02:21] hughhalf: exactly :) === ericm-Zzz is now known as ericm [02:47] JFo: you around? [04:14] Is everyone on the Ubuntu Kernel Team an employee of Canonical? [04:17] Squideshi: no [04:23] pgraner, I am now [04:24] JFo: you got any bits about bug filing down, specifically why we want new bugs, not dog piled ones? [04:24] I have some stuff drafted, but nothing wikified yet [04:24] want me to push something to a page? [04:30] JFo: just looking for something to point to in egregious bugs [04:30] I had been planning a Dos and Don'ts section of the Bugs/ page [04:30] JFo: yea, no worries [04:30] plus an expanding of the statuses a bit [04:31] * pgraner nods === pgraner is now known as pgraner-afk [04:47] What's the difference between the following two wiki pages? [04:47] https://wiki.ubuntu.com/Kernel/ [04:47] https://wiki.ubuntu.com/KernelTeam [04:47] KernelTeam/ is in the process of being migrated to Kernel/ [04:48] after that the KernelTeam/ pages will be deprecated [04:51] I just put a note to that effect on KernelTeam. [04:51] Thank you. [04:51] You won't keep KernelTeam/Meeting? That's how most teams manage their meetings and other internal affairs. [04:52] that is getting moved over as well [04:52] Squideshi, not necessary [04:52] JFo: Well, it confused me; and it might confuse someone else, but now it won't. :) [05:10] JFo, i like helpful people that are worried about other peoples confusion [05:51] is there an existing git short-hand for "git commit -a -m typo && git rebase -i HEAD~2" or should I just alias that? [05:51] * achiang wonders what kees is doing that requires that questionable operation to be an alias. ;) [05:52] achiang: I keep getting minor nit-picks from lkml about the symlink change I'm trying to upstream. [05:52] kees: looks like no other choice to me, but if you wanna try guilt, it can do that very easily [05:53] cooloney: I may go that route eventually, but I want to be fully comfortable with git before I add another layer. :) [05:53] yeah, with stg, that would just be: stg refresh ; stg rebase origin [05:54] kees: i'm wondering why you need to rebase on HEAD~2 [05:54] achiang: so that I can mark the "typo" fix as a "fixup" and it gets melded into the first change [05:55] kees: yeah, like guilt-fold [05:55] kees: what is HEAD~1? [05:56] achiang: same as HEAD^? it's the typo commit. [05:57] kees: hm, what is HEAD then? [05:57] *make changes*; git commit -a -e; *make tiny fix*; git commit -a -m fix; git rebase -i HEAD~2; *mark the "fix" change as a "fixup" and save* [05:58] rebase needs one past the stuff you're interested in? I'm losing count, but HEAD~2 works [05:58] kees: exactly, that's what i'm doing in pure git [05:58] cool [05:59] kees: ah. ok, well, i guess you're doing it the git way. but seriously, this is exactly the use case for other porcelains like stg or guilt [05:59] achiang: ah, right, so HEAD is the typo, HEAD~1 is what I want to merge it into, and HEAD~2 is the point I want to list all commits beyond. [05:59] this is what i was alluding to the other day about where stg is much nicer than git [05:59] achiang: I will likely start using it for my next upstreaming adventure. :) [06:00] achiang: I don't doubt, but I have a masochistic desire to understand what in the world git is up to first. :) [06:00] kees: you could start using it now and save yourself some trouble... ;) [06:00] hehe [06:00] git format-patch HEAD~2 (or maybe it's HEAD~3) [06:00] for i in *.patch do ; patch -p1 < $i ; done [06:00] stg init [06:00] stg new symlinks.patch [06:00] stg refresh [06:00] done [06:01] cool. yeah, very quilty :) [06:01] oh, i guess you'd need to revert the patches before applying them... [06:01] git reset --hard HEAD~2 (or 3 ;) [06:01] * kees nods [06:02] whoa [06:02] git rebase -u HEAD^2 [06:02] err, -i [06:02] * kees looks up -u [06:02] oh [06:02] heh [06:03] then you get an editor that asks you what you want to do with each patch [06:03] what git help page lists all the ~ ^ .. etc stuff? [06:03] jk--: yup, it's delightful [06:03] kees: man git-rev-parse [06:03] jk--: ah-ha! that's just what I needed, thanks. :) [06:04] kees: np :) [06:05] * cooloney is checking -u as well [06:07] jk--: -u is not available to me [06:07] cooloney: it was a typo [06:07] -u is a typo :) [06:07] OMG, [06:08] the keys are right next to each other, it's not *that* surprising! :) [06:11] kees: oh right, you were looking for alternatives to rebase -i :) [06:12] you're looking to edit the second-to-last patch? [06:12] jk--: yeah, i think kees knows -i [06:12] brb [06:13] * cooloney imagines that jk- will invent a option to git as --edit-2nd-to-last [07:24] hello, I can consistently reproduce a kernel crash while startinga a specific java app, what is the recommend procedure to collect the crash data ? [07:27] joaopinto: `ubuntu-bug linux` [07:27] - will file a new bug [07:27] right, but does it collect crash data ? [07:28] you could try enabling Apport to try and get a backtrace. [07:29] I can't find any of the errors showns on during the kernel oops event at /var/log/* [07:30] joaopinto: hm, what happens when it crashes? machine stops completely? [07:31] it prints a "Kernel bug at blah blah blah" with some information, and stops completely [07:31] right now I am looking to capute that information [07:32] this happens when starting an WebSphere Application Server nodeagent, which is basically a java process [07:34] I didn't have this issue during lucid's development, so it was either introduced with a near final or post final kernel upgrade, or it's triggered by another change not kernel related which triggers the bug [07:34] joaopinto: if the crash info doesn't reach the disk, then we can't recover it in the next boot, unfortunately [07:34] soooo [07:34] * jk- thinks [07:35] hum, I am being dumb, maybe I can simply ssh trigger the crash and get the error on the console, or maybe not, let me try [07:36] brb [07:36] erk [07:36] joaopinto: it'll only output to ttys that have a console running on them [07:37] (ie, ttyx and maybe ttyS0) [07:37] ah :( [07:37] if you can get a serial line working, then that will help [07:37] * kees would like to understand how the "netcat console" works for this kind of stuff [07:38] kees: https://wiki.ubuntu.com/KernelTeam/Netconsole ? [07:38] why yes :) [07:38] lookie there :) [07:38] woot! :) [07:38] going for netconsole :) [07:39] * kees has never tried netconsole, just fake serial ports via kvm [07:39] hum, I coultd try to reproduce the crash on a VM [07:41] that's what I've always done for weird crashes [07:41] it still needs setup, but virt-manager was pretty helpful in that regard. [07:43] it's a bit strange how a java process which is purely server oriented (no GUI related interaction) triggers a kernel crash [07:45] yeah. :( [07:45] especially if it's not running as root. [07:46] it's not, the good news is that I believe that WAS is one of the few BM products certified for Ubuntu, I just need to check if that applies to Lucid [07:46] ..IBM... [07:47] joaopinto: what does your /proc/sys/kernel/panic_on_oops contain? [07:48] jk-, 0, btw, I have installed the kernel-oops package now, but didn't crashed again [07:49] I hope the netconsole works with plymouth :) [07:50] joaopinto: that's for reporting oopses to kerneloops.org [07:51] joaopinto, you say it 'prints kernel bug blah' i presume that means you can see the output sometimes? [07:51] does it appear on the screen at least? sometimes a digitial photo is a useful approach [07:52] apw, I can always se the output when locally on the system [07:52] apw, an IT guy does not use photos to collect data :P [07:52] joaopinto, heh i often use photos to collect panics, better than not seeing it [07:53] joaopinto, the very first line that you indicate has some key information which can be extracted from a photo pretty easily [07:53] I will try 1) netconsole, 2) virtualbox.. 3) photo [07:53] it mentioned a specific .c file on the "bug" line [07:56] photo's rule: http://dupondje.be/DSCF1025.JPG :P [07:56] grr wait, this a laptop, wifi, the network will not be available for the netconsole module :( [07:58] morning lag [07:59] joaopinto, if you perhaps took a picture people could at least look at the issue with some real information [07:59] apw, ok, I will take a picture [08:01] Morning cking [08:01] :) [08:02] * lag has a fuzzy head! [08:02] grrrr, this time the output was so long that it scrolled and I can't read the initial lines with the helpful info [08:02] lag, too many beers? ;-) [08:03] does NOHZ: local_softirq_pending 242 as the last line on the crash output means anything ? [08:03] cking: Not enough ;) [08:04] heh [08:04] * lag went out and saw people =:-o [08:04] joaopinto, heh just your luck, one of the reasons i take a photo the first time i see the header of the error, just in case i cannot get it again... low tech, slow, even unreable at times ... but often a life saver [08:05] cking, seems someone has gone postal in the UK [08:05] hum, I see a lot of ip_* / network related functions on the output [08:05] unfortunatly without the top its hard to tell if it was those or they are just a victim [08:05] apw: Are you talking about that taxi driver? [08:06] I do have some internal policy firewalls rules [08:06] lag, walked in the news report so no idea who the person is, but likely there is only one killing spree [08:06] I will try to start the process without the firewalls rules [08:06] Yeah [08:07] one every 18 years or so is still too many [08:08] What was the last one? Dunblane? [08:08] 14 years back that was :( [08:09] Hungerford (1987), Dunblane (1996).. [08:10] Ah yes, Mr Ryan [08:10] i guess we have to be thankful they are mercifully far appart [08:11] http://en.wikipedia.org/wiki/2010_Cumbria_shootings [08:11] They didn't waste any time! [08:11] bad news always travels at the speed of light [08:12] Who things "Oh, there's been a massacre, let's start a Wiki page?" [08:12] thinks* [08:15] lag, think of it more as thinking it deserves recording, you could equally say, "there has been a massacre, who'd put it all over the news" [08:24] apw: I had every belief that it would be recorded. I wasn't shocked to see the other two Wiki pages. I was more shocked to see it up there so quickly, as if it was the first thing that popped into the author's mind. [08:25] lag, i think you'll find its 'slop over' from wikinews.org, people put it there, and the editors of that record the significant events from that [08:26] I see [08:32] * abogani2 waves [08:34] apw, jk- , starting in recovery mode and starting the java processes does not kernel panic [08:40] grr, now it just hardlocked without printing any info, the problem is reproducible the way it's reported is not :( [08:40] Jun 3 08:33:05 ThinkPad kernel: [ 98.620090] kmemleak: 247 new suspected memory leaks (see /sys/kernel/debug/kmemleak) [09:11] jk-, I got a wired connection and was able to setup a netconsole, now let's hope the panic info is sent before the lockup [09:12] cool :) [09:14] grrr, I can't believe this, with a wired connection+netconsole I am unable to reproduce the crash, after having done it 10 consecutive times [09:15] * cking needs to attend gas fitter - back in 20 [09:16] joaopinto: are you getting any console messages through netconsole? [09:16] jk-, yes I am, remote dmesg [09:17] this java process is expected to create multiple tcp listeners, and because I see a lot of ip_* functions on the kernel panic info it seems to be network related [09:17] using a wired connection might have changed the bug condition [09:20] jk-, this is getting funny, I have unplug the eth cable, restart the java process, got a kernel panic [09:29] apw: Sorry to bother you: Did you have a chance to take a look on my lowlatency kernel flavour? I have just rebased it to latest Maverick release and the build test is in progress on my PPA. [09:30] abogani2, sorry no, am fighting an aufs2 issue right now [09:30] apw: No problem. :) [09:32] abogani2, sorry to be so tardy looking at it, its bee a bit mad with A1 [09:33] apw: I understand. [09:38] jk-, the only unusual requirement from this java app is that on startup it checks that the configured listener IPs are configured in some network interface, and refuses to start if not [09:39] because this is a laptop I am using 127.0.1.1, for the app to start I need to: ifconfig lo 127.0.1.1 [09:40] it could be the "IP availability" validation on eth0 when the connection is not available leading to the kernel panic [10:18] smb: Thank you very much Mr. Bader! :-) [11:15] hughhalf, around? [12:15] apw: since smb is not here, how do you think we merge omap4 branch into lucid? [12:15] cooloney, whats the issue? [12:16] cooloney, mumber perhaps ? [12:17] apw: actually, smb thinks that is a big change through, he does not like to do that. [12:17] apw: i did get any feedback from him about this. [12:18] cooloney, he has been very busy with the security updates which shipped today [12:18] cooloney, join us on mumble ? [12:18] apw: yeah, understood. [12:18] apw: too bad, i have no time to fix my mic. sorry for mumble [12:18] * cooloney needs to fix it [12:19] bah [12:19] so i think his confusion is over the support side, putting it in our repo implies things about support and i thought he was asking about what the support requirements are [12:20] i believe the images will live outside of the archive in a PPA for the purpose, right? [12:20] apw: yeah, exactly, [12:20] so did we get the information on the support requirements ? [12:21] apw: davidm told me about this "the OMAP 4 support for the 10.07 release should not be SRU'ed back into Lucid, but kept out in a PPA, " [12:22] support for the 10.07 release will end in jan 11 [12:22] in an email, i think you will are in the loop [12:22] we dont want the source or binary packages in the distro [12:22] but cooloney needs a place for the tree [12:22] ogra, define 'source in the distro' [12:22] ogra: yeah, thanks, [12:22] as putting the branch in our git tree sounds like being in the distro [12:23] apw, no source package [12:23] all packaging will live in a PPA [12:23] source as well as binary [12:23] well i don't think there is much of an issue pushing the branch into our repo, its who is going to maintain it for the support period that was the outstanding issue as i see it [12:23] the tree should be maintained on out git server though, since its a merge of the TI and the ubuntu trees [12:24] as its supported for 6 months right ? [12:24] (bare omap4 upstream git is at omapzoom.org btw) [12:24] right [12:24] apw: i will maintain that branch, but still need smb to pull my patches. hehe [12:25] if you are signing up to maintain the branch 'hwe' style then i think thats going to be ok [12:25] ie we say 'we added security stuff to mainline, have at it for omap4' style emails coming your way [12:25] and you'll ask for a pull when its applied ? [12:29] yeah, i think so. [12:30] but is it a big trouble to add security stuff into omap4 branch directly? [12:39] cooloney, i don't understand your question [12:39] cooloney, what upstream version is omap4 based on [12:41] apw: it is based on .33 for 10.07 [12:42] it is the same as ti-omap branch [12:42] yeah so we don't have a .33 master branch for .33, so maintenance of .33 is a bigger job [12:43] yeah, i understood, that's smb's git concern [12:43] my question is also about that. [12:44] so for maintenance of .33, i will get those security updates from mainline instead of our .32 master branch? [12:44] cooloney, i would assume the omap branch will get them and you can get them from there, but that may mean you have to figure out which ones are which [12:47] apw: ok, got it. actually, ti-omap4 is also rebased from ti-omap branch [12:47] cooloney, its based on the normal ti-omap tree ? [12:47] in that case you may be able to just keep rebasing onto there [12:48] apw: yeah, i rebased all ti-omap stuff on omap4 branch from TI. [12:49] that sounds like the other way round, and a nightmare [12:49] so for our stuff such as apparmor, aufs, it is the same as ti-omap configuration [12:54] yep but if the tree is 'upsidedown' then we're not going to be able to just rebase it [12:54] so i think that nails its status as a hwe branch [12:54] apw, someone handles the omap3 branch in lucid, no ? [12:55] should be possible to just copy stuff over from there [12:55] since they are both .33 [12:55] ogra, indeed someone does, but the omap4 branch isn't the same process its not shaped the same [12:55] so its much more effort, and bryan has already volunteered to handle it [12:55] ok [12:56] * cooloney feels in hot water now [12:56] this is why these stupid heaps of arm patches are an unsustainable mess [12:56] heh [12:56] well, maverick will make everything better [12:57] we'll only have omap4 as a separate branch for arm [12:57] ogra, all i can say there is 'yeah right' [12:57] ogra, we'll only have that branch till we get a heap more, as happened, and is stil happening in lucid [12:57] this omap4 branch is the 9th branch [12:57] i doubt you will see a heap more [12:57] linaro should solve that [12:57] ogra, you can doubt it all you like, i just don't believe it [12:58] there is an army of devs working on fixing the situation now :) [12:58] and devicetree [12:58] should, in some unspecified timescale, i will be drinking champagne if we have less that 6 branches in maverick [12:59] all of that is at least 3-4 releases way (upstream) which makes it 2 releases away for us [12:59] i would have said one release (being optimistic) :) [12:59] (for us) [13:00] heh yeah, but we heard that a release ago, and frankly there is nothing usable there yet is there [13:01] not to take anything away from TI and the fact that we can almost have an omap flavour on the mainline kernel [13:01] apw: right, long term story, but we feel short term pain [13:01] it looked like there is some base stuff during UDS [13:02] so i would expect a first working arch in m+1 [13:02] ogra, yeah so i return to my previous position we'll have 6 branches again in M [13:02] * cooloney need some food to feel better. === cooloney is now known as cooloney-afk [13:02] which is a worlkd of pain [13:02] yes, M will still suck but i wouldnt expect more arm branches [13:03] omap3/4 and versatile are the only arm arches we officially support atm [13:03] * apw holds up his "i'll believe that when i see it" banner [13:04] heh [13:04] indeed, if $big_vendor comes in with $big_money that could change ... but i doubt it === cooloney-afk is now known as cooloney [13:25] apw: if i wanna built-in nfs modules, need i change d-i modules? [13:25] cooloney, depends if the udeb becomes empty [13:25] apw: i built-in nfs before, but building from source package in PPA failed [13:26] cooloney, if it was becase of the udebs the error would have told you, what error did you get [13:27] apw: oh, don't have the error log now, then i set NFS_FS as module like other arm branch [13:27] the building passed. [13:28] cooloney, its entirly possible you would cause a udeb to become empty, which means it needs adding to the exclusion list for the flavour [13:29] apw: OK, I saw your patch about that, it should be similar i guess. [13:30] why do you need to buildin NFS of all things [13:31] apw: that's a question from TI guys, they are heavily using NFS for boot [13:31] so you know, they are asking for building NFS_FS [13:31] built-in [13:31] find: `debian/nfs-modules-2.6.33-900-omap4-di': No such file or directory [13:31] nfs-modules-2.6.33-900-omap4-di will be empty [13:31] make[1]: *** [do-binary-udebs] Error 1 [13:31] make: *** [binary-udebs] Error 2 [13:31] dpkg-buildpackage: error: /usr/bin/fakeroot debian/rules binary-arch gave error exit status 2 [13:31] nfs-modules-2.6.33-900-omap4-di will be empty [13:31] https://launchpad.net/~canonical-arm-dev/+archive/ppa/+build/1757077/+files/buildlog_ubuntu-lucid-armel.linux-ti-omap4_2.6.33-900.1~build2_FAILEDTOBUILD.txt.gz [13:32] that line tells you that nfs-modules become empty [13:32] so you need to add nfs-modules to the excludes list [13:32] yeah, i understood [13:32] apw: cool, got it. [13:32] will try to fix that [13:32] apw: thanks, i have to off line now [13:33] have a nice day [13:33] see ya [13:37] Hello [13:37] for a server (mail, vpn, squid-proxy and firewall), whats the best for Timer frequency in kernel: 100Hz or 1000Hz [13:40] generally we set servers lower as they do not require the same interactivity [13:40] cking, is launchpad down _again_ today? [13:43] 100 or 250 [13:58] tgardner: you have emerald smoking, I have ear plugs and now I have about a 90 deg breeze blowing on me from the fans [14:00] pgraner-afk, just burning it in. perhaps you should move it downstairs? [14:00] tgardner: I'll put it back in the rack when your done [14:01] pgraner-afk, I'm off. did you fix the PXE boot? [14:02] tgardner: yep === pgraner-afk is now known as pgraner [14:02] tgardner: wow it got quiet === xfg is now known as zul [14:07] apw, lp is behaving slowly but it is working for me [14:08] pgraner, did it quiet down before or after you turned it of [14:08] off [14:11] apw: heh [14:20] Keybuk, yesterday you mentioned u had unionfs patched userspace tools. where can i find those [14:21] Keybuk, also in my red and green PPAs are the initargs and readahead-tracking patches building, i think they'll make it this time [14:31] When suspending, does USB suspend or just the connected devices? [14:33] lag, we power down the devices don't we [14:34] Yes [14:34] But does USB host need suspending too? [14:34] so we are definatly doing something to the host, i would imagine putting it in D0 [14:39] I don't think USB actually needs suspending [14:40] I have just found an option in the menuconfig to disallow any USB device to suspend anyway [14:40] * lag is a happy bunny now [14:57] lag, what option is that pray tell [14:57] 2 secs [14:58] CONFIG_USB_SUSPEND surprisingly :) [15:03] we don't build a specifically -server kernel do we? [15:03] one of the bug reporters just confused the heck out of me [15:03] JFo, um, of course we do [15:03] JFo, there is a -server flavour for amd64 [15:03] I see... oh, I knew that [15:04] * JFo goes to make coffee === bjf[afk] is now known as bjf [15:08] moin all [15:08] moi [15:20] moin bjf [15:22] I'm looking at a commit to the drm-next branch. How do I know if this patch has been incorporated into the mainline kernel, when, and which version? [15:22] http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=commit;h=f360132626b11d0dc60814033873ca0e3111677c [15:40] Squideshi, you'd do a git log against the source of the tree you want to know about [15:40] git log [15:41] in the example above f360132626b11d0dc60814033873ca0e3111677c is the SHA === xfg is now known as zul [15:56] JFo: In other words, I would need to actually download the mainline kernel source? [15:57] you would need the Ubuntu branches in order to tell, since you'd have to run the git log commands against them [15:57] or rather whichever release you were interested in [15:58] ogasawara, i did that aufs2 update. there is a bit of a colission between that an the removal of an arguemtn to fop fsync .. which means we may not be able to fsync directories correctly on aufs2 after this... hoping we get an update from the maintainer shortly [15:59] apw: ack [16:04] anybody know about kdump? [16:05] or rather know what is needed when it seemingly fails? [16:06] * JFo listens to the crickets [16:06] JFo: Sorry. If I knew, I would try to help. :) [16:06] no problem Squideshi [16:07] basically just wondered if anyone of the team had experience with it [16:07] I know next to nothing about it [16:09] I have an Intel 845G on an Dell Inspiron 1100 that seems to have several video problems with Lucid. I first had to uninstall Compiz to get it to work at all; but now I think there are two different problems, possibly both in the kernel... [16:09] First, there's a flicker problem (I hope that's the right term.) [16:09] It appears to be fixed when I installed the linux-image-2.6.33-997-generic kernel from drm-intel-next. [16:10] Squideshi, do you have a bug filed we can look at? [16:12] so lucid is basically unuseable on ec2 instances [16:12] you run chown -R foo:foo somedir/ and on lucid on ec2 the load goes straight to 40 [16:12] it's like a software simulation of a 300bps modem [16:12] from #kernel [16:16] tgardner, CONFIG_DEBUG_KERNEL=y [16:16] tgardner, http://hildstrom.com/projects/aestest/index.html [16:29] Does anyone know why kgdboc refuses to recognise ttyUSB0? [16:29] I get write error: No such device [16:31] lag, not sure if this is your problem... http://jdramer.wordpress.com/2010/04/28/linux-kernel-debugging-with-kgdb/ [16:33] manjo: Nope. That guy is using USB->Serial on his development machine. I need it on the target. [17:16] apw, I'm off to grab some lunch. ping me whenever you want to chat about wikis... we can postpone till later too if you like [17:20] JFo, ok [17:20] ogasawara, where shall i push this maverick thing [17:20] shall i just expose it on my zinc one ... seems sensible [17:21] apw: yah, anywhere on zinc should be good and I'll just grab it [17:21] ogasawara, i haven't tested it other than compiling aufs bit, as it then breaks more in ubuntu/ [17:22] apw: ack [17:22] ogasawara, i'll be monitoring the aufs tree for a proper fiz [17:22] fix [17:37] ogasawara, git://kernel.ubuntu.com/apw/ubuntu-maverick aufs2.35rc1 [17:37] apw: thanks [17:38] jdstrand, perhaps --cpu 4 for you [17:46] apw: --cpu 4 with testdrive you mean? === xfg is now known as zul [17:52] jdstrand, was wrong channe, and you said the same in paralle in the right place [18:04] ok, I wasn't aware of a -cpu' option, so wasn't sure [18:17] git remote show origin [18:17] -EWRONGWINDOW [18:19] heh [18:24] * oldkid is listening to 'Subway to Sally - Wolfstraum' from 'Engelskrieger' [18:24] ... [18:24] sorry wrong chan [18:25] heh [18:36] apw: hey did you see my patch enabling linux-tools in ubuntu-maverick-*meta* as well? [18:48] lool yeah, though ogasawara is owner for maverick and has taken ownership of the patch in patchworks [18:48] apw: Oh ok, how do I see that? [18:48] http://patchwork.ozlabs.org/project/ubuntu-kernel/list/ [18:49] Didn't know about this instance, thanks [18:49] apw: are there more arm trees in which to enable too? [18:49] linux-ti-omap and the like [18:49] lool: am in the middle of rebasing to 2.6.35-rc1 so will get everything that's under review applied afterwards [18:49] (and do you need patches for them) [18:50] ogasawara: Ok thanks [19:05] ogasawara, apw; https://wiki.ubuntu.com/Specs/M/ARMKernelVersionAlignment [19:07] ogasawara, apw: feel free to /join #linaro BTW :-) [19:07] ogasawara, apw: Someone is doing noise next to the phone [19:25] lool, it was someone typing i recon, and not i :) [19:26] I can see apw and ogasawara swearing under their breath [19:52] amitk, less than you might expect === xfg is now known as zul [20:02] ->lunch === pgraner is now known as pgraner-afk [21:56] JFo: as i'm guessing its a bad BIOS, seems like some other people have crashes with that bios also. Mailed ASUS, but they tell me its PSU, but its not right :s [21:56] hmmm, that is sad [21:56] wonder why they think it is the PSU [21:56] because they say newer cpu has bigger TDP then old one [21:56] but its shit :) [22:25] hmmm, I seem to recall an issue with a laptop where the vendor said much the same and, to my surprise, the new PSU fixed it [22:25] not saying that is the case here [22:25] but it reminded me of that [22:59] rebooting === sconklin is now known as sconklin-gone === bjf is now known as bjf[afk]