[03:28] <jayT> I'm trying to build a module, but everytime I get the error: ERROR: Kernel configuration is invalid.
[03:28] <jayT> however, I can build my kernel just fine
[03:28] <jayT> the module is outside the kernel tree
[03:28] <jayT> just a simple hello test module
[03:28] <jayT> modules inside the kernel source tree are built fine
[03:28] <jayT> I have tried make oldconfig, make prepare, etc, and re-built the whole kernel,
[03:29] <jayT> but always got that error when I tried to compile a module outside
[03:29] <jayT> could anyone give a hint what's going wrong?
[03:30] <jayT> using ubuntu 11.04
[05:50] <philipballew> How do I put a the kernel time in my terminal when i issue comands?
[06:00] <jk-> philipballew: what do you mean by the kernel time?
[06:02] <philipballew> jk-, I have seen it by my kernal dev friends where on the side of the terminal the system time is there and shows next to each command and each line of output. 
[06:02] <jk-> so just the time of the day?
[06:03] <jk-> ^ philipballew 
[06:03] <amitk> philipballew: export PS1="[\d \t \u@\h:\w ] $ "
[06:04] <jk-> yep, what amitk said :)
[06:04] <jk-> but I'm a bit puzzled about the date appearing next to each line of output.
[06:05] <amitk> philipballew: not really kernel related, but here are the keywords to google for: PS1 linux shell prompt time
[06:06] <amitk> jk-: you could remove the '
[06:06] <amitk> \d 
[06:06] <jk-> amitk: no, more that you're only setting the prompt, which won't affect terminal output.
[06:07] <jk-> philipballew mentioned "shows next to each command *and each line of output*"
[06:07] <amitk> jk-: PS2 is your friend for that trick
[06:08] <amitk> I suspect
[06:08] <jk-> PS2 is for the secondary prompt
[06:08] <jk-> not output
[06:08] <jk-> ie, continuations
[06:08] <amitk> aah, i see what you mean now. I doubt it is on every line of output
[06:08] <jk-> yeah, me too :)
[06:08] <amitk> maybe he just saw dmesg with printk times
[06:09] <jk-> maybe.
[06:09] <amitk> which might explain "kernel time"
[06:09] <jk-> philipballew: show us a screenshot if you can.

[06:09] <amitk> totally :)
[06:24] <philipballew> amitk, jk-  sorry, Had to step away
[06:25] <philipballew>  export PS1="[\d \t \u@\h:\w ] $ " should be pasted where
[06:27] <jk-> philipballew: in to the terminal, and it will change the prompt temporarily
[06:27] <philipballew> alright, ill see what happenes
[06:27] <jk-> if you want to change it permanently, then add that line to ~/.bashrc
[06:29] <philipballew> oh, alright. Im ive seen it where it shows the system time. so you can see exactly when a partictular event happens
[06:29] <amitk> philipballew: type dmesg and tell me if you saw that?
[06:30] <jk-> philipballew: I'm still not clear on what you mean by 'system time', and how that differs from the current "clock" time.
[06:31] <philipballew> did like I would like when i tyoe dmesg i can have a system time stamp next to each line on the terminal output
[06:31] <philipballew> *type
[06:31] <jk-> that's what the numbers in square-brackets are - seconds since boot
[06:32] <philipballew> is that a common thing to have in your terminal?
[06:32] <philipballew> http://pastebin.ubuntu.com/663993/
[06:33] <jk-> no, it's specific to dmesg
[06:34] <philipballew> hum. haha. alright. Ill look around
[06:35] <jk-> you could add `| awk '{print strftime("%H:%M:%S")" "$0}'` after every command you type, but I don't think that's very convenient :D
[06:36] <philipballew> very true. im trying to debug a possible kernel power management error to see if an error is the kernal or grub related. thought it might help
[06:37] <philipballew> might be to much hassle
[06:37] <jk-> it's probably not a grub issue :)
[06:38] <philipballew> the desktop will not restart
[06:38] <philipballew> ive seen the issue be a boot loader issue, 
[06:38] <jk-> ok, that doesn't sound like a power management issue then
[06:39] <philipballew> haha. it hangs on reboot, but shutdown -h now works fine. 
[06:39] <jk-> riight
[06:40] <philipballew> seemes weird. but i think I have the wrong boot parameters myself
[06:40]  * philipballew is now off topic
[06:40] <jk-> where does it hang? do you see the BIOS screen?
[06:40] <jk-> no, this is now *on* topic :)
[06:41] <philipballew> whenever I type sudo reboot or just click reboot the comp shuts down all processes then says will now reboot and just sits there
[07:15] <apw> and what kernel command line options do you have
[07:18] <philipballew> none
[07:18] <philipballew> well easily
[07:18]  * philipballew is not a kernal know-it-all
[07:20] <jk-> philipballew: cat /proc/cmdline
[07:20] <philipballew> BOOT_IMAGE=/boot/vmlinuz-2.6.35-30-generic root=UUID=3ccd7388-34b9-40fe-960b-15371e1fb72a ro quiet splash
[07:21]  * philipballew is doing this from sshing to his desktop (if that matters)
[07:21] <jk-> philipballew: yeah, that's cool. nothing unusual there.
[07:22] <philipballew> maybe it needs something unusual to work?
[07:23] <apw> there is a reboot=<letter> which switches reboot mode
[07:23]  * apw finds the documentation
[07:24] <philipballew> it might be a bug for my hardware but the desktop is 6 years old so a big bug like this should mave been fixed
[07:25] <apw> philipballew, not necessarily it may be unsusual h/w to have linx on
[07:26] <apw> philipballew, ok i've pm'd you the documentation for the reboot=<x> command line option
[07:26] <philipballew> true. but i never had this problem with ubuntu and only xubuntu gives it. haha
[07:27] <apw> hmmm
[07:27] <apw> well thats odd as i would expect those to have the same kernels, our kernels, and so to behave the same
[07:27] <apw> which ubuntu worked (version) and which of xubuntu does not
[07:27] <philipballew> i would to. i had ubuntu server on there and nothing
[07:27] <philipballew> both 10.10 and 11.04
[07:28] <philipballew> but ubuntu 10.10 didnt
[07:28] <philipballew> i ran ubuntu on it for years from 7.10 up to 10.10 and no problems ever
[07:28] <apw> so i can ignore the xubuntu thing
[07:28] <apw> as its a new version which doesn't work
[07:29] <philipballew> ubuntu 10.10 reboot works. xubuntu 10.10 reboot = bad
[07:29] <apw> and which kernle does xubuntu 10.10 have in it
[07:29] <apw> cat /proc/version_signature tells you
[07:30] <philipballew> Ubuntu 2.6.35-30.56-generic 2.6.35.13
[07:32] <apw> and have you tested the same version in ubuntu 10.10 ?
[07:32] <apw> ie. how are you comparing to vanilla 10.10
[07:33] <philipballew> i can run a live cd you think?
[07:37] <siji> apw, goodafter noon
[07:37] <apw> well you are telling me a fact about ubuntu 10.10 so i am assuming you have tested it, i am asking how and when you _did_ test it.  so i can work oout if that would have had a similar or different kernel
[07:37] <apw> hi
[07:37] <siji> am trying here to fix the bug which we discussed yesterday
[07:38] <siji> http://marcin.juszkiewicz.com.pl/2010/10/19/how-to-cross-compile-arm-kernel-under-ubuntu-10-10/
[07:38] <siji> can you pls tell  me whether this doc is capable of building kernel for beagle 
[07:39] <siji> which is based on xdeb
[07:39] <siji> (till now i tried build the kernel directly in beagle , which consuming time) 
[07:41] <philipballew> apw it was 10.10 about 3 months ago. i tested it by knowing I restarted it and it worked just fine
[07:41] <apw> siji, it looks viable
[07:41] <siji> ok
[07:42] <apw> philipballew, ok so that had a lot older kernel so its entirly possible its an upstream stable change which has affected the kernel here ... you have a vanilla ubuntu kernel in your xubuntu image, so i suspect a real ubuntu install will also be affected the same way
[07:42] <siji> instead of linux-linaro have to use linux-omap3 right ?
[07:42] <apw> philipballew, so the correct thing to do is now is to test those reboot= options.  as the kernel includes a table to select the appropriate reboot option.  let us know which if a
[07:42] <apw> any work for you
[07:43] <apw> siji, i would guess so, i have obviously never actually tried it
[07:43] <philipballew> ill do it right now
[07:43] <siji> apw, ok will give a try
[07:43] <amitk> siji: you might find the author of the blogpost on #ubuntu-arm or #linaro as 'hrw'
[07:43] <siji> ok
[07:51] <philipballew> force did not work. onto next
[07:52] <siji> amitk, thanks i got him @ ubuntu-arm 
[07:54] <amitk> siji: I know, I'm there too :)
[07:54] <siji> :)
[08:09] <siji> apw, amitk can you pls suggest some other method to cross compile the kernel 
[08:10] <siji> (am familiar with OE)
[08:11] <apw> siji, i do all my cross-compiles in a regular chroot with the cross tools installed as in that post
[08:13] <siji> regular chroot  = x86 chroot | Cross tools=xdeb & gcc-arm-linux-gnueabi ?
[08:15] <amitk> siji: I haven't used xdeb either
[08:15] <amitk> I probably should try again, it was broken last time I tried
[08:16] <siji> amitk, i installed it with out any errors 
[08:16] <amitk> siji: it is the kernel compilation bit that was broken for xdeb
[08:21] <siji> amitk, ok
[10:19] <apw> siji, regular chroot with the cross compiler installed
[10:21] <siji> apw, ya understod 
[11:03] <Kaleo> hi
[11:09] <apw> hi
[13:10] <tjaalton> hum, how to build an amd64.deb mainline kernel with mainline-build? it defaults to i386
[13:12] <tgardner> apw, ^^
[13:16] <tjaalton> looks like it's hardcoded in mainline-build-one, I'll try creating one for amd64
[13:17] <ogasawara> tjaalton: I hand edit the mainline-build-one script to generate amd64 debs
[13:17] <tjaalton> ogasawara: heh, okay
[13:18] <ogasawara> tjaalton: http://pastebin.ubuntu.com/664241/
[13:18] <tjaalton> thanks, that saved me some time
[13:19] <apw> tjaalton, does it not make both by default
[13:20] <tjaalton> apw: nope
[13:20] <apw> don't understnad why not for you, it does normally
[13:20] <apw> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.0.1-oneiric/
[13:20] <tjaalton> this is the -one script
[13:21]  * apw thinks, is that something someone else added
[13:21] <ogasawara> apw: or maybe changes didn't get checked into kteam-tools?
[13:21] <tjaalton> mainline-build sends email to the list, so running that directly doesn't feel like a good idea :)
[13:21] <apw> ogasawara, no whats used daily is whats in the tree
[13:22] <apw> mainline-build-one builds the amd64 first i think
[13:23] <apw> it does clean, binary-indep, clean, binary-generic (in <release>) and then binary-generic (in <release-i386>)
[13:23] <apw> so it defiantly makes both
[13:23] <apw> tjaalton, ogasawara, ^^
[13:24] <tjaalton> well it didn't here, though I did run it against linux.git HEAD
[13:25] <apw> well ... it must have said something when it tried.  perhaps your chroots are not the right names
[13:29] <apw> tgardner, in case you hadn't noticed i've pushed up an empty LBM
[13:29] <apw> it even builds as of just now
[13:30] <tgardner> apw, ah ,and this tidbit of information implies I should upload it ?
[13:30] <apw> tgardner, i was hoping you'd glance over it for now
[13:30] <apw> as it only produced a single .udeb i am unsure if we care if it is uploaded or not yet
[13:30] <apw> ogasawara, t
[13:31] <apw> ogasawara, those lbm net packages, i think you added them
[13:31] <apw> ogasawara, do you know where the source was from, ie. does oneiiric need them?
[13:31]  * ogasawara tries to remember the lbm net bits
[13:31] <ogasawara> apw: was that the updated e1000e driver?
[13:32] <apw> that and igp or something
[13:32] <apw> igb
[13:32] <apw> something like that
[13:32] <tgardner> that stuff should all be upstream by now
[13:32] <ogasawara> apw: if I remember correctly, those were picked from upstream so O shouldn't need them
[13:32] <apw> ok then off is correct for them
[13:32] <ogasawara> apw: but let me double check to make sure
[13:33] <apw> gawd they have changed the login screen to be all mad and off centre, really jars in my OCD world
[13:35] <ogasawara> apw: yep, don't need them for O
[13:40] <tgardner> apw, ogasawara: I think we can drop the LBM alsa, input, and media directories (and assorted rules and control.d cruft) since they aren't even enabled in Natty.
[13:40] <ogasawara> tgardner: works for me
[13:54]  * ogasawara wonders if bjf is really here or in transit
[13:55] <bjf> unfortunately, really here, i just couldn't make myself sleep in
[13:55] <bjf> flight doesn't leave unti 13:30
[13:56] <bjf> but i'm _not_ going through ATL
[13:56] <tgardner> bjf, JFK instead ?
[13:56] <ogasawara> bjf: I'm going to change the format for this weeks IRC meeting.  Rather than me repeating myself every week with the delta review blueprint, I'm instead going to harp about outstanding work items that need done for the upcoming beta-1 milestone
[13:56] <bjf> tgardner, PDX -> AMS
[13:57] <tgardner> ogasawara, hmm, will that make you a 'harpie' or 'harpette' ?
[13:57] <ogasawara> heh
[13:57] <bjf> ogasawara, cool
[13:58]  * ogasawara back in 20
[14:29] <brendand> hi sconklin
[14:30] <brendand> sconklin - do you reckon we'll need to fully retest the respun kernel, or will the change be minor enough to make our results from the current valid?
[14:35] <sconklin> well,  on one hand, since he tests didn't catch this, being a graphics issue and all, there's not much to be added by retesting. On the other hand, these are probably invasive changes so I think we'll have to completely retest.
[14:35] <sconklin> But capping that off, we really don't have a fix yet, so we don't know what's required
[14:35] <sconklin> So I think we'll probably have to recertify plus run some additional tests to see if the graphics work on those platforms
[14:39] <tgardner> apw, ogasawara: uploaded linux-backports-modules-3.0.0_3.0.0-8.1
[14:39] <ogasawara> tgardner: thanks!
[14:39] <brendand> sconklin - is it only affecting particular gfx cards?
[14:40] <apw> tgardner, heh, oh i'll take that as being ok :).  /me orders ram for pete
[14:40] <tgardner> apw, oh, it was fine. I ripped out some obsolete stuff though.
[14:41] <apw> sconklin, did we have a display regression on 38-11 in natty ?
[14:41] <sconklin> brendand: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/814325 We know it affects Intel graphics, I don't know whether we have a subset of models. 
[14:41] <ubot2> Ubuntu bug 814325 in linux "fuzzy and corrupted display with update in natty-proposed" [High,Triaged]
[15:15] <apw> tgardner, yeah i half heartedly stripped it
[15:15] <tgardner> apw, I got out the bob nailed boots....
[15:15] <tgardner> hob*
[15:15]  * apw was liking the thought of bobs hammered into my boots
[15:16]  * tgardner is going back to learning cloud infrastructure
[15:17]  * apw notes that unity is the biggest source of bugs in oneiric again this week
[15:20]  * smb is glad he only needs to cope with the olds ones this week
[15:20]  * apw finds 5 bugs in the first 5 minutes as usual
[15:21] <smb> apw, You are using it in an unusual using manner
[15:22] <apw> smb, yeah i am using it rather than osx
[15:23] <smb> And trying to get some work done with it instead of looking how nice it looks... ;-P
[15:24] <apw> just managed to get compiz to coredump
[15:24] <apw> after trying to restart it cause it hung
[15:24] <apw> quality s/w
[15:25] <tgardner> apw, yeah, I've been having compiz issues this morning also
[15:25] <apw> luckily i only updated my scrapper today
[15:26]  * apw checks, beta 1 is definatly later than alpha 1
[15:28]  * smb reminds apw about optimism
[15:28] <apw> i stand my interpretation, stupid (n)
[15:29]  * smb keeps silent about apw having upgraded any machine
[15:31]  * jjohansen thanks apw for the subtle reminder not upgrade while traveling
[15:32]  * ogasawara feels compelled to upload today
[15:32] <apw> ogasawara, :)
[15:32] <ogasawara> tgardner, apw: anything else you want to shove onto master-next before I kick some test builds and upload
[15:32] <smb> ogasawara, And then run for the weekend. :)
[15:32] <ogasawara> smb: of course!
[15:32] <apw> ogasawara, nothing i know of here
[15:33]  * ogasawara goes back to opening P
[15:33] <tgardner> ogasawara, the only thing pending is perhaps jjohansen's AA patches.
[15:34] <ogasawara> tgardner: ack, I'll maybe wait till about lunch time to kick off builds to give him time to respond
[15:34] <ogasawara> tgardner: if not, they can go up in the next round
[15:34] <tgardner> ogasawara, ack
[15:37] <mdeslaur> herton: think you can build me a test kernel with ROAF's two patches from comment #27?
[15:38] <herton> mdeslaur: yep, I'm about to copy built kernels here, hang on
[15:38] <mdeslaur> herton: ah, cool :)
[15:40] <jjohansen> ogasawara: just upload my patches are not worth holding off for
[15:42] <ogasawara> jjohansen: ack, I'm in no big hurry to upload so if they're not in by noon-ish I'll pull the trigger.
[15:42] <jjohansen> ogasawara: okay, but it may be worth holding off on them and waiting to hash it out next week after I have talked to jdstrand
[15:43] <herton> mdeslaur: hmm, had to restart build here because an error, will ping you when I finish
[15:43] <ogasawara> jjohansen: ah, in that case then we can wait and I'll go ahead an upload
[15:43] <mdeslaur> herton: thanks
[15:57] <herton> mdeslaur: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/814325/comments/44
[15:57] <ubot2> Ubuntu bug 814325 in linux "fuzzy and corrupted display with update in natty-proposed" [High,Confirmed]
[15:58] <mdeslaur> herton: it only takes you 14 minutes to build a kernel? :P
[15:58] <mdeslaur> herton: thanks
[15:58] <herton> yes, I use one of our build machines, it's pretty fast
[15:59] <mdeslaur> kernel team gets all the cool toys :)
[16:00] <tgardner> mdeslaur, the kernel team has this really annoying guy that makes lots of demands
[16:00] <mdeslaur> tgardner: hehe :)
[16:12]  * herton -> lunch
[16:38] <georg> hi fellows! had an GPF using dm raid5 with dm crypt on top. Trace: http://pastebin.com/QK15DkaU (actual kernel: ubuntu natty 2.6.38-8-generic #42-Ubuntu SMP x86_64 GNU/Linux). is this known, should i file a bug?
[18:00] <tgardner> ogasawara, do you remember how I added a macro to chromium? For example, I can enter 'bug 1' in the URL window which automatically expands to https://bugs.launchpad.net/ubuntu/+bug/1. The Lucid version in -proposed is wedging on some searches, so I wanted to make sure my browser is mostly vanilla.
[18:00] <ubot2> tgardner: https://bugs.launchpad.net/ubuntu/+bug/1 (Not reporting large bug)
[18:01] <ogasawara> tgardner: hrm, I don't know how to do it with chromium.  I did for firefox
[18:01] <tgardner> is ther e a common extensions directory?
[18:01] <ogasawara> no idea
[18:01] <tgardner> how did you do it for FF ?
[18:01] <apw> tgardner, you do that in the search section
[18:01] <tgardner> I must have imported something
[18:01]  * ogasawara digs through notes to remember
[18:02] <apw> tgardner, hit the spanner, preferences, then on the basics tab there is a "Manage Search Engines"
[18:02] <apw> add a newone at the bottom with a keyword and you are good
[18:03] <apw> ogasawara, ^^
[18:03] <tgardner> apw, indeed, thats where it is
[18:03] <ogasawara> apw: awesome, thanks!
[18:03] <tgardner> so, thats unlikely to be the root of my lockup
[18:07]  * tgardner --> lunch
[18:28] <apw> BAH pidgin just ate a bunch of my disk space ... it seems
[18:28] <apw> any suggestion where it put it
[18:31] <apw> i had that 2G left message, cleared 8, and got it back in minutes ... and found pidgin consuming a whole CPU
[18:34] <apw> ahhh .xession-errors ... 15GB
[19:08] <jjohansen> apw: its beer o'clock, its just telling you to start the weekend
[19:41] <kamal> how does one build the linux-tools-{version} binary package?   I discovered "fakeroot debian/rules binary-tools" which seems to try but eventually bombs out with this (on tangerine):
[19:41] <kamal>   dpkg-gencontrol: error: package linux-image-3.0.0-8-tools not in control info
[19:43] <kamal> ... along the way, the build yields warnings about "newt not found, disables TUI support" and "/usr/bin/python-config is not an executable".
[19:43] <kamal> apw, tgardner, ogasawara: is tangerine set up to build the binary-tools target?  am I doing it wrong?
[19:44] <ogasawara> kamal: I can't say I've specifically ever tried fdr binary-tools
[19:44]  * ogasawara tries
[19:44] <tgardner> kamal, I don't remember that as being a target
[19:45] <kamal> tgardner: it is a target :-)    ogasawara, thanks!
[19:46] <tgardner> kamal, I think its binary-perarch
[19:46] <ogasawara> kamal: I just did a fdr binary tools (but on tyler) and it seems to be building
[19:46] <ogasawara> kamal: ah, fails
[19:47] <kamal> ogasawara: you did "binary<space>tools"  or "binary-tools"?
[19:47] <ogasawara> kamal: binary-tools
[19:47] <ogasawara> kamal: fails in the end though
[19:47] <ogasawara> kamal: same error
[19:47] <kamal> ogasawara: ok, thanks for confirmation
[19:48] <kamal> tgardner: I'll try binary-perarch
[19:48] <tgardner> kamal, the only reason I say that is because of this: 'debian/rules.d/2-binary-arch.mk:binary-perarch: toolspkg = $(tools_pkg_name)'
[19:48] <kamal> tgardner, ogasawara: yes, binary-perarch builds the pkg fine
[19:49] <kamal> tgardner: thanks!
[19:50] <tgardner> kamal, you also need linux-tools-common so that it installs the wrappers
[19:52] <kamal> tgardner: understood, thanks
[19:53] <tgardner> kamal, I presume you're looking at the x86 power tools ?
[19:54] <kamal> tgardner: my purpose here is to figure out whether the new "tools/power/cpupower/..." stuff is going to be built and packaged in linux-tools-* or not.  do you know?
[19:55] <tgardner> kamal, indeed I do, 'UBUNTU: [Config] Package x86_energy_perf_policy and turbostat'
[19:55] <kamal> tgardner: I saw that, but was unclear what effect that would have on the tools packaging.
[19:56] <tgardner> it adds wrapperd ala perf so that the correct ABI related tool is launched
[19:56] <tgardner> wrappers*
[20:01] <kamal> tgardner: I think I'm talking about something else... I'm talking about the (very) new tools/power/cpupower/... stuff that just landed in the v3.1-rc1 tree (its the userspace utility that used to be called 'cpufrequtils' but is now called 'cpupower').
[20:02] <tgardner> kamal, ah, I've not seen that yet
[20:45]  * tgardner --> EOW
[20:56]  * herton -> eow
[22:13] <asabil> hi all
[22:14] <asabil> is it normal that I don't have any pdflush process running ?
[22:15] <khanx> yep
[22:15] <khanx> its perfectly normal
[22:29] <milehigh> 2.6.38-10-generic-pae kernel, is CONFIG_NR_CPUS set to 7 for a reason? How can I change it while still using packaged kernels?