[00:00] compiling any kernel always seems to burn a hole in my leg === bjf is now known as bjf-afk [02:07] there's something about compiling a kernel using the .config I got from gentoo that seems to make things not work [02:07] In a way - I'm not surprised at all [02:33] erm, how come alsa snd-aloop is not found in kernel? [02:34] my sound card has no PCM/mixer capture support and needs aloop [02:43] I was looking at CONFIG_SPI and saw "up to several tens of Mbit/sec. Chips are addressed with a" I'm guessing that should be s/tens/tenths/ === jk-_ is now known as jk- [03:23] Any ideas why this broke? http://pastebin.ubuntu.com/292024/ [03:30] ericm-Zzz, LOL , still not get up? === ericm-Zzz is now known as ericm [03:30] hi, anybody familiar with IGMP protocol in kernel ipv4? [03:30] hzhang__, naw actually is up [03:30] is that a must option for common usage? [03:30] ericm, yeah, got my email? i saved 6KB finally for remove OABI_COMPAT [03:31] hzhang__, yes - you're a poor man - struggling for saving 6KB :-) [03:31] hzhang__, so finally you are able to build a EABI kernel without OABI_COMPAT? [03:32] ericm, oh, i just comments off those #error in kernel/time.c [03:32] ericm, and seems kernel is ready for EABI [03:32] hzhang__, seems your kernel is a hybrid one :) [03:34] MTecknology: what source is this, and what .config have you used? [03:35] jk-: I pulled the source from git and I took the default .config for my profile and started removing some stuff [03:35] MTecknology: which git tree? [03:35] "for your profile" ? [03:36] git://kernel.ubuntu.com/ubuntu/ubuntu-karmic.git [03:36] ok, cool === Whoopie_ is now known as Whoopie [03:36] to get the default .config I did this - cat debian.master/config/config.common.ubuntu debian.master/config/amd64/config.common.amd64 debian.master/config/amd64/config.flavour.generic > .config [03:36] I compiled and it worked [03:37] now I'm having troubles pin pointing where I screwed up [03:37] ok, maybe diff your config against the original one that you got from 'cat ...' ? [03:37] i'm scared to :P [03:38] 'cat .... | diff -u - .config' [03:39] I just did diff file1 file2 [03:39] http://pastebin.ubuntu.com/292029/ [03:39] anyone knows that ath9k broken after resume is a known issue? [03:40] MTecknology: why such a difference? [03:40] ericm: first googgle result - did you try rmmod ath9k, then modprobe ath9k ? [03:40] jk-: I sat down and tweaked for about 2hr [03:40] my first guess would be to disable CONFIG_DEBUG_KERNEL [03:41] MTecknology, tried google - seems to be a known issue - but need confirmation (and unfortunately I don't have the hw, just looking into this issue reported by others) [03:41] jk-: it is disabled [03:41] or start from a clean .config, then change small things, and test between changes [03:41] Symbol: DEBUG_KERNEL [=n] [03:42] ouch [03:42] there's no easier way to see where I screwed up? [03:43] you could find out what's defining both 'debug' symbols [03:43] How can I do that? [03:45] I'm confused why there would be two things defining that symbol now but not earlier - I didn't add anything extra [03:54] do you have ndiswrapper enabled? [03:54] it's an option in the kernel that was * by default iirc [03:55] CONFIG_NDISWRAPPER=m [03:55] m* [03:59] (ndiswrapper seems to define a non-static 'debug' symbol) [04:01] If I drop that - will I have issues running flashplugin-nonfree... I'm guessing so but it's worth a shot [04:01] no, it's for windows wireless drivers [04:02] oh - i was under the assumption that that plugin used it in some way [04:03] nope [04:04] I'll try it like that :) [04:04] thanks [04:04] * MTecknology crosses fingers [04:05] I expect something to break - just like it to compile so I can get an error thrown at me that says something like "Hey moron; don't disable this!" [04:08] jk-: where did you find that information? [04:13] MTecknology: just looked for non-static debug vars [04:25] ericm_, LOL, hybrid kernel ... === hzhang__ is now known as panda|phenom [04:33] jk-: that fixed it :) [04:34] now to see if I can boot up with it [04:36] I made the kernel get scared [04:36] then it ran away [04:36] Something about needing to find it's roots [04:37] How can I pull up the error that it threw? [04:37] Sounds like you disabled the driver for your disk controller [04:38] how can I see what driver I need for it? [04:39] 'lspci -v' will show you which driver is used for each device under the current kernel [04:39] though it's not always easy to work out how that's labelled in the configuration menus [04:39] shiny :) [04:40] I already see what you mean :P [04:42] here it is http://pastebin.ubuntu.com/292050/ [04:43] this looks relevant - SATA controller [04:44] So you want ata_piix and ahci (not sure if you *need* both) [04:45] thanks :) [04:48] another 30min to recompile :P [04:49] I think it takes about that long [04:50] Less than 5 minutes with a minimal config [04:50] hm? [04:50] ...and more than one core [04:50] I'm trying to trim the default config down as far as I can [04:51] Why? [04:51] for fun mostly [04:51] and for a really really fast boot time [04:52] I'm considering dropping X and moving to framebuffer displays too... [04:52] You don't actually need to disable drivers for that, but building in the ones you do need can help [04:52] that compile took ~3min [04:53] and then getting rid of initramfs (but not all distributions support that and I don't know whether Ubuntu does) [04:53] ya - leaving them out seems to cause an infinitely long boot time [04:53] I mean, you build the drivers you need as built-in (=y) not modules (=m) [04:53] I heard initramfs can speed it up a lot - if this works I was planning on trying it [04:54] ya - I prefer built-in but making everything built-in won't help either [04:54] I'm going to try this out - brb [04:54] Personally I have no interest in doing that on production machines, but I do driver development and fast rebbooting is useful :-) === SyL is now known as Guest74631 [04:57] unable to moutn root-fs on unknown-block [04:57] same error as before [04:58] Did you include the filesystem? [04:58] that dang kernel is so scared of me it just wets it pants [04:58] Ext4, ya [04:58] Do I need to have Ext{2,3} even if I don't use them? [05:00] no [05:01] The whole system is either Ext4, swap, or extended [05:02] what do I need to get to an extended partition? [05:02] nothing special [05:02] ok [05:03] only /boot isn't on an extended partition [05:03] Is there any way to get teh exact error that came up? [05:03] serial console / netconsole / camera [05:04] I can try my camera phone.. [05:04] you did specify root= on the kernel command line, right? [05:10] I assume that was set - I'm only modifying the source [05:11] http://imagebin.ca/img/x-JURGKX.jpg | http://imagebin.ca/img/dx09FZq.jpg [05:12] the phone takes a cleaner image than I thought if I really try to stay steady [05:12] you can see how glossy the screen is - w/ my reflection [05:13] it has no idea what sda5 is... [05:15] Check that you have CONFIG_MSDOS_PARTITION=y [05:15] oh, I know, you're missing sd [05:16] SCSI disk support [05:16] SATA is much like SCSI at the protocol level so you have to enable that [05:16] I just saw that [05:16] the msdos part [05:17] which options should I enable for scsi? [05:17] I searched for scsi and that's right around massive [05:17] SCSI_DH? [05:18] CONFIG_BLK_DEV_SD [05:18] I'll try that out :) [05:19] I wonder how long this build is going to take [05:20] Womble2: thanks for the help :) [05:21] hopefully this just works nice and perfect and I'll be smart enough to do only a few things at a time and build-in things I know I'll need [06:21] Womble2: sorry, I had to run off [06:21] That part is working - now I need to figure out what I need for ecryptfs and another very minor error [06:25] Womble2: thanks again for all the help :D [06:28] thanks to everyone else too :) [06:32] I guess I was wrong with what I thought I needed - but I can't imagine making ecryptfs work should be too hard to find [08:44] ericm_, well, finally, fixed SLOB for my nommu board [08:45] panda|phenom, you are genius bro - what's the prob? [08:45] ericm_, only 2.5MB to run kernel, busybox, stream server and web server [08:45] ericm_, no, i'm poor, compound_order must be run on the head. [08:46] ericm_, so use virt_to_head_page(objp) instead of virt_to_page(objp) [08:46] ericm_, anyway, uclinux is amazing ... LOL [08:50] panda|phenom, you must have fun then :-) [08:52] ericm_, ah, well, i'm still a newbie and there are so many code i can't understood ... long way to go ... [08:53] panda|phenom, hey you are a panda - so don't worry about that === doko__ is now known as doko [12:06] is this patch included in karmic? http://bugzilla.kernel.org/show_bug.cgi?id=13121 [12:06] bugzilla.kernel.org bug 13121 in BIOS "Buggy _BCM - acer aspire 5720G, 5710Z, 5315" [High,Closed: code_fix] [12:08] cankoy, yes! I can see it in karmic [12:09] csurbhi: does it also cover 5715Z? I asked a number of times there, but it's ignored so far. [12:09] let me check, i am just making a patch and verifying that [12:17] cankoy, reading the comments there, i think the patch should work for 5715Z [12:18] csurbhi: as of 2.6.31.4, I still don't see http://bugzilla.kernel.org/attachment.cgi?id=21801. [12:19] if you get the latest karmic [12:19] release [12:19] i mean the source code and do a git log drivers/acpi/video.c\ [12:19] thats the first commit that will pop [12:20] ok, thanks [12:24] cankoy, you seem to be right [12:24] |the patch for 57151Z is not yet in [12:26] have u filed a bug in launchpad ? [12:26] no, should I? [12:27] if that's the only way to get noticed, then I can.. [12:27] yes, please do. I will apply it if a bug is filed [12:27] :) [12:36] cankoy, also can u ask in bugzilla about the merge of this patch upstream ? [12:46] csurbhi: https://bugs.launchpad.net/ubuntu/+source/linux-ports-meta/+bug/450288 [12:46] Malone bug 450288 in linux-ports-meta "fix for Acer Aspire 5715z brightness keys missing" [Undecided,New] === hggdh_ is now known as hggdh [13:48] apw, smb: what do you guys think about the bluetooth connection patches? [13:50] rtg, hard to tell how vast they are from his email [13:51] apw, isn't your block elevator patch suitable for stable? [13:51] rtg, Would need to look at the actual patches, but might be reasonable [13:51] ok the first two are small and obvious [13:51] rtg, elevator one, I think yes [13:51] the last needs more reading but it seems to be trying to reference count the devices ... [13:52] my only worry is they are pretty late, and i don't have any bluetooth devices to test with [13:52] rtg on the readahead, yes, it need submitting upstream and cc: stable, on my list for today [13:53] apw, do you want to change our commit log (e.g., add Cc: stable...) ? [13:53] heh, i could but normally i'd rebase it to mainline before sending and would add it then [13:54] apw, ok [13:55] those bluetooth things seem to have hit real mainline too [13:56] rtg, the 3rd one is a bit misty but it is upstream ... [13:56] the other two look ok [13:56] apw, they are all cherry picks and apply cleanly, which is why I asked him to send them upstream for stable. [13:56] yeah ... i guess normally i'd say wait for that, but freeze throws spanners in that [13:57] apw, well, if they _do_ come via stable, then smb can deal with them in a couple of weeks [13:58] :)) [13:58] :-P [13:58] rtg: this is getting fun :) [13:58] Brian did point out that they are not regression fixes, but rather improvements. [13:59] if i had some h/w to test with i might say shove them in now [13:59] not having a clue if they work after is a concern [14:00] i think my radio keyboard is exactly that some bespoke keyboard wireless thingy [14:00] From the policy point of view they fix a problem, though not an oops or hang and they are not enablement really, so.... [14:00] smb, which is why I've been considering them. [14:01] * apw asks on X if they have anything they can test with [14:02] apw, I think Marcel must already be headed to KS since he's not on the wireless channel [14:02] Rather keep things working after cycles of unplug / plug... We could say its "only" affecting bluetooth, so it could not get worse [14:02] Though my headset did work remarkably well with karmic [14:02] heheh ... bluetooth bashing [14:05] apw, you and smb are gonna have to give me a lesson in block devices in NC. wtf is failfast? [14:05] rtg, telling the scsi layer to not bother with error recovery [14:05] rtg thats the thing where a multi-path device can say 'don't retry here, retry higher in the stack' [14:05] too much [14:06] ah, ok. thats makes a bit of sense in a SAS env [14:06] :q [14:06] anyone know what the ima layer is? [14:06] ima_path_check ? [14:07] Integrity Measurement Architecture [14:12] rtg what was your feeling on that barrier thing for vios? [14:14] vios? [14:14] the null write barrier log spam thing [14:14] virtual io service thing [14:15] apw, is that in stable? clearly I have not encountered it yet. [14:15] no it was the one i pushed to our list, for server [14:17] apw, I am totally confused 'cause I have no idea what you're talking about. [14:27] the patch you punted on :) [14:30] rtg, ping [14:30] apw, I _intended_ to include it. I take it I missed it along the way? [14:30] * apw thought so, but i may have missed you not missing it [14:31] apw, what is the log message? [14:31] block: silently error unsupported [14:31] empty barriers too [14:33] apw, hmm, its in the list archive. guess I missed it. [14:33] rtg is the next upload going to be a bumper? [14:33] apw, dunno yet [14:33] rtg, Are the sec fixes in? [14:34] smb, the 2 CVE's ? [14:34] yup [14:34] (which one of them would be a bumber) [14:34] as of Ubuntu-2.6.31-13.45 [14:36] don't see them in .45 [14:36] appletalk: Fix skb leak when ipddp interface is not loaded, CVE-2009-2903 [14:36] sgi-gru: Fix kernel stack buffer overrun, CVE-2009-2584 [14:37] those 2, right? [14:37] actually, they went into Ubuntu-2.6.31-13.44 [14:38] If I do "git checkout Ubuntu-2.6.31-13.45" where is that? [14:38] sounds about right [14:39] Or is that checked out right into the root git directory? I've never used git [14:39] rtg, ahh it was a bumper, but it wasn't a bump [14:39] MTecknology, it cheecks out that tag into your working directory [14:39] apw, it was a bullshit bumper, so I ignored it [14:39] yeah i can see that, makes sense, didn't realise we could do that :) [14:40] as in we had any mechanism for it [14:40] apw, do you have the patch for bug #420423 in a repo somewhere that I can fetch? [14:40] Malone bug 420423 in linux "Running karmic as virtual machine with virtio hard disk outputs I/O errors" [High,In progress] https://launchpad.net/bugs/420423 [14:40] rtg sure [14:40] apw: Thanks, I was confused because it builds as "2.6.31.3" instead of something like "2.6.31-12" [14:41] MTecknology, that depends on how you do the build. a make makes .3 as thats the 'base'. a debuild makes -12 .debs [14:42] apw: and they're the exact same thing after I install it except for naming? [14:42] MTecknology, Likely not, for probably different configs [14:42] depends on where you get your .config i'd say, but otherwise ... [14:43] I'm making my own [14:43] apw, can you take care of the EC2 meta package while I sort out this next kernel upload. see the k-t list for my response to smoser [14:43] MTecknology, Then it is cleanly not the same. :) [14:43] rtg ack [14:44] I clearly need coffee. biab [14:44] thanks apw, rtg [14:44] smb: I meant the differenve between how I build them, not versus getting it from the main branch. My config.1 is the same as the main branch, config.{2,3,4,5} are different. (Keeping checkpoints for nice builds as I go) [14:45] MTecknology, The tree is then the same as from which -13.45 was build [14:46] thanks [14:46] git log should be at the last commit which is checking in the release with that message [14:46] the git tree is our master source repository, all uploads are built from there [14:46] git feels almost like a smart version of cvs.. [14:46] * apw laughs [14:47] that's only after ~30min working with it - but that's my first impression [14:47] rtg: git://kernel.ubuntu.com/apw/ubuntu-karmic lp420423 [14:50] apw: I'm beginning to believe that this laptop's problem could be overheating related [14:51] Keybuk: that burns.. I've had that issue a few times (thankfully on my system only once) [14:51] Not sure if you guys care and probably not at all for another 3 days but I'm finding this interesting - http://versioncontrolblog.com/comparison/Bazaar/CVS/Git/Mercurial/Subversion/index.html [14:56] rtg, ok we have sent you some email on the .4 update [15:02] soren: around? [15:06] apw, pulled lp420423 [15:06] rtg ack [15:06] rtg smoser linux-meta-ec2 uploaded [15:07] thanks. [15:27] smb: any word on bug 445456? [15:27] Malone bug 445456 in linux "kvm hangs booting windows XP Pro SP2 or later, since at least 2.6.28-15" [High,New] https://launchpad.net/bugs/445456 [15:28] I guess I should add the requested info.... [15:28] lamont, other than me asking for that info. no. To be honest even with it there I had not much time for any bugs [15:29] figures [15:35] apw, pushed master with all of the stable updates. still doing build and smoke testing. [15:36] rtg cool [15:36] apw, note the top commit, CONFIG_X86_MCE=y [15:39] interesting... the 2.6.28-11 kernel with karmic user space decides that I don't get my thumbpad [15:55] heh nice, who needed that [16:14] apw, I'm looking at what armel.mk produces. in the master rules, shouldn't linux-headers, linux-doc, and linux-source be specifically excluded for armel ? [16:14] i believe that is ok, note they are _all [16:15] talking to maxb etc it seems that i386 runs debuild -b, but all other arches do debuild -B [16:15] which only makes the one file [16:15] apw, huh, lemme try that [16:18] apw, damn, works likes a charm [16:18] yeah i was supprised too. i fixed the .mk then made it herre and had those _all's and asked on #u-d and they said that that was basically how its meant to work [16:18] all really does mean all, just we then say 'don't do all' for all other arches [16:20] apw, perhaps I should be changing my makefiles to reflect that, i.e., use -b for i386 and -B for all others. [16:20] yeah maybe, its a lot quicker for arm for one [16:27] rtg i now have some good testing on a usb hack for those Huawei E169 USB dongles which broke in 2.6.32.2 ... the fix is a hack from benh, and i think we'll get a proper fix later ... [16:27] but ... its those G3 sticks ... which are quite popular [16:27] so to consider it, or wait for the real thing for the first SRU [16:31] apw, k-t list yet? [16:32] no just got the feedback, and wondering if its sane to take the hack [16:32] is it device specific? [16:32] http://launchpadlibrarian.net/33442788/patch0 [16:32] thats the hack ... [16:33] its pretty generic ... i am leaning to waiting [16:33] Would me my feeling too [16:33] oh, that is a gross hack, isn't it :) [16:34] hello, can anyone help me? i got a mail regarding bug 446110 [16:34] Malone bug 446110 in linux "-12 kernel causes boot to halt at initramfs shell / boot hangs with "waiting for root file system" " [Undecided,New] https://launchpad.net/bugs/446110 [16:34] rtg its pretty scarey ... i think waiting is the order of the day [16:35] slacker_nl, what was the email about? [16:35] the janitor came by and talks about linux-meta and linux packages, reported the bug via apport, so I would assume the correct package was selected from the get-go [16:35] smb: bug 254668 - any point in digging into this more, or should it be closed as fixed? [16:35] Malone bug 254668 in linux "[2.6.27] pausing during boot (several issues)" [Unknown,Confirmed] https://launchpad.net/bugs/254668 [16:35] slacker_nl, yeah apport has a tendancy to chose linux-meta when you use linux-image-generic as the package to report against [16:35] apw: that is what happend [16:36] apw: can ignore the message ? [16:36] slacker_nl, so if your bug was a realy bug, something kernel not working-y then the janitor did the right thing [16:36] slacker_nl, sure can, we'll find the bug now its in the right place [16:36] apw: k, cool [16:37] CarlFK, It might be interesting to see your full dmesg in there. It would be interesting to see whether that kernel argument would have helped with the older kernels (not sure you are keen on trying to go backwards, though) [16:37] smb: box isn't in use right now, so I can try a few things [16:38] ill post dmesg [16:39] CarlFK, Cool, thanks. I would at least have a work-around documented for older kernels if we close this as fixed now [16:40] apw: so I changed my governor to powersave [16:40] and so far this machine hasn't hung [16:40] and it's fan is nowhere near the 747 levels it was at yesterday [16:40] heheh. sounds a bit dodgy [16:57] yeah [16:57] it's a Dell XPS 1330M [16:57] we don't support those, right? [16:58] M1330 even [16:58] manjo, pgraner, either of you having trouble with your M1330's ? [16:59] nope [16:59] apw: I haven't run Karmic on it since my wife appropriated it [16:59] ah yess ... [16:59] manjo, so you don't get any overheating issues? [17:00] apw, upgraded this morning ... have not noticed it [17:00] apw I mostly run on battery... is the over heating while charging ? [17:00] basically for me, after a few hours usage, the machine crawls to a slow snails pace [17:00] ** [17:00] ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting [17:00] ** [17:00] I've been running an XPS1330 with no heat issues [17:00] it needs a physical power off to be well again [17:00] overheating is just a theory [17:02] apw, ordered a dell 10V a week ago... but won't get it before the sprint, dell takes 2 weeks to ship [17:03] manjo, doh [17:03] manjo, so ... keep an eye out for going as slow as snot [17:03] apw, with ssd this time [17:04] Keybuk, the next kernel will have MCE enabled, maybe you'll get some more error info. [17:04] apw, so we have a machine to test ssd issues now [17:04] apw, machines + 1 May be [17:04] the 10v ? [17:05] yes [17:05] rtg: *nods* [17:05] that's interesting [17:05] I unplugged it from the mains as manjo hinted [17:05] and the temperature has already dropped 10 C [17:05] and the fan just throttled down [17:06] ooh, ACPI [17:06] Keybuk, I recharge when I am suspended ... [17:07] Keybuk, I have a HUGE battery [17:08] Keybuk, just plugged mine in ... will see the change [17:08] Keybuk, i wonder if you battery could be sickening [17:09] Keybuk, what are you using to check temp? [17:09] apw: don't think so, it's holding a reasonable charge [17:09] apw: >90% of design capacity [17:09] this laptop has mostly been on a shelf until my other one failed [17:10] Keybuk, don't hear the fan yet .... speed is normal [17:10] manjo: cat /proc/acpi/thermal_zone/THM/temperature [17:10] Keybuk, hmmm sounds ok [17:10] apw: the only thing it was used for was itunes and lightroom under windows [17:10] Keybuk, temperature: 44 C [17:10] I took the drive out, put an SSD in, and have been using this as a backup [17:11] manjo: I'm down to 48 C now [17:11] this is the nvidia model, so it might run hotter than yours if yours is the intel model? :P [17:11] Keybuk, 44C with power plugged in [17:11] it was 65 C at the point it went really slow [17:11] Keybuk, yes intel on mine [17:11] again, heat is just a guess here :p [17:12] though it's kinda interesting that I can actually touch the bottom of the laptop now [17:12] and all I've done is unplug the power [17:12] Keybuk, 44C and holding [17:15] it's holding at 48 C here, but hasn't quite finished the apt-get upgrade run [17:16] * amitk grumbles at a new pop-up dialog telling me my battery is discharging when I pull the power on the laptop [17:16] upgrade finished, and the fan just went even quieter [17:17] Keybuk, and if you put the ac back? [17:17] apw: just giving it a few more minutes, then will see [17:19] power back in now\ [17:23] (temp has climbed to 51 C so far) [17:23] mad [17:25] Keybuk, mine has gone up by 1C [17:27] my temp just dropped to 40C [17:28] mad [17:29] 52 C now [17:29] if anything I'm doing less on it right now than I was when it was in its 40s [17:29] I'm not upgrading openoffice for a start! [17:30] my laptop sits at 49c right now [17:30] on power [17:30] * apw pulls the plug [17:31] my netbook on 61 [17:32] (though I am running a hell lot of stuff (including looking at apw) [17:32] mine is staying around 49/50 with or without power (dell) [17:41] rtg is that a wrap on 14.46 ? a [17:41] and was the bump generic [17:42]