=== sconklin is now known as sconklin-gone [00:09] how do I make an ubuntu kernel source package for my customized ubuntu kernel? [00:59] mozmck: Would this do it? https://help.ubuntu.com/community/Kernel/Compile#AltBuildMethod [01:01] komputes: I don't know, but I just used this command and got .tar.gz and .dsc files of the source: dpkg-buildpackage -S -us -I.git -I.gitignore [01:01] so I think that's what I needed. [01:01] good to hear [01:27] any of the devs around? === anubhav__ is now known as anubhav [08:33] * apw yaens [08:33] * apw yearns for a keyboard with the keys where he seems to think they are [08:33] Is that a Scottish yawn? [08:34] heheh ... [08:47] RAOF, so how are we doing in maverick ... graphics wise? [08:48] Our plymouth/bootup fandangaling remains a source of endless frustration. [08:48] yeah plymouth seems to be tickling at least three bugs in the kernel [08:48] Apart from _that_, things are going nicely. [08:48] vesafb seems to be crazifying thnigs a bit, too. [08:48] i _think_ i have a reliably bootng kernel now at least on my worst affected test box [08:49] :) [08:49] that of course does not include getting the damn splash in the right format so it doesn't look like someone vomited on the screen [08:50] apw, talk to kwwii [08:54] ogra, any idea where they hang out? [08:55] #ubuntu-art (or artwork) or in #ayatana i think [09:08] hello, i seem to be experiencing some troubles with my fglrx driver in maveric with kernel 2.6.35. It just won't install, the bug report says that it won't build... why is that? [09:36] hego: https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-updates [09:38] fglrx is only going to work for a few more days in maverick though, will be broken once xserver 1.9 goes in [09:39] Ok, thanks [09:40] And what should i do when it gets broken? [09:40] Wait? [09:42] well, nvm. Thank you SO much! [10:07] * cooloney using checkpatch.pl to fix coding style [10:07] apw: found some issue about the checkpatch [10:08] cooloney, that happens [10:08] its cirtainly not perfect [10:10] apw: http://pastebin.ubuntu.com/470152/ [10:10] what you found wrong with it? [10:10] yep thats a bug, and you should ignore it from a submission stand point [10:10] do send that to me in email [10:10] apw: i have to say the code from TI is a good testcase of checkpatch.pl [10:10] heh i bet [10:11] apw: np, man. [10:11] i assume i can fix the coding style this morning, [10:11] just found it took me all the morning to fix one patch [10:11] just one patch [10:12] heh [10:12] actually their originally code is "MCBSP3_DMA_TX*ATC_SIZE," [10:13] checkpatch.pl reported the same error [10:13] you can just ignore that complaint, it is wrong, the rules for * is either x*y or x * y, just be same cosistent [10:13] even if i changed it to "MCBSP3_DMA_TX * ATC_SIZE," [10:13] yeah, thx [10:13] will email you later [10:13] the official style is either, the bug is matching that as a type [10:46] apw: how about this one? [10:46] ERROR: need consistent spacing around '-' (ctx:WxV) [10:46] #10695: FILE: sound/soc/codecs/abe/abe_typ.h:26: [10:46] +#define MAX_UINT8 ((((1L << 7) -1)<<1) + 1) ^ [10:46] is that - a subtraction ? [10:46] i thnk it is, then it should be either )-1) or ) - 1) [10:46] http://pastebin.ubuntu.com/470167/ [10:47] oh, sh*t, [10:47] my bad [10:47] yep that is clearly meant to be a subtraction so the code is wrong [10:47] i gonna crazy today [10:47] #define MAX_UINT8((((1L << 7) - 1)<<1) + 1) [10:47] is this right? [10:48] i would also put spaces round the second << [10:48] yeah, i always do that. [10:48] as you are not being consistant on the spaces both sides or not spaces both sides there [10:48] #define MAX_UINT8((((1L << 7) - 1) << 1) + 1) [10:48] yep [10:48] well space after the INT8 and before the ( [10:48] its not a function [10:49] and cpp will do the wrong thing [10:49] #define MAX_UINT8 ((((1L << 7) - 1)<<1) + 1) [10:49] << undone again [10:49] who wrote this code, i wanna kill him [10:49] not me :) [10:49] #define MAX_UINT8 ((((1L << 7) - 1) << 1) + 1) [10:49] wonderful code [10:50] thx a lot man [10:50] looks fine to my eye [10:50] yeah, me2. [10:50] feel much better [10:50] there is a double spacing between << 7 by my eye [10:51] cking: good catch [10:51] #define MAX_UINT8 ((((1L << 7) - 1) << 1) + 1) [10:51] #define MAX_UINT16 ((((1L << 15) - 1) << 1) + 1) [10:51] #define MAX_UINT32 ((((1L << 31) - 1) << 1) + 1) [10:51] that's the code [10:52] ok, that's ok then ;-) [10:52] they wanna make it beautiful [10:52] add one more space between << and 7 [10:56] apw: i got tons of warning about line over 80 characters [10:57] most of them are in the header files for some macros and registers. [10:57] is that ok to keep them. [10:57] otherwise most of their header files code need to rewrite [11:01] its frowned upon unless they only look sensible in that form [11:02] always what looks best and is most readable is the correct form [11:02] apw: ok, understand [11:02] and how to deal with WARNING: do not add new typedefs [11:03] heh .. don't add them :) [11:03] generally unless they are in the core official typedefs like atomic_t etc they are not beneficial is the thought [11:05] apw: right, that's duplicated. but i cannot remove them, it is used by tons of code [11:05] let me keep it and let them to fix it [11:05] yep [11:05] it all depends on the typedef in the end of the day [11:05] just got this ONE patch totally crazy [11:06] looks like an alien wrote this code [11:29] Hi, what is the exact procedure to build a kernel source package of a modified Ubuntu kernel, suitable for upload to a PPA? This link (http://tjworld.net/wiki/Linux/Ubuntu/Kernel/CustomBuildPPA) is showing one that does not work for me (missing debian/changelog) [11:31] andreoli, you probabally need to clean the tree 'fakeroot debian/rules clean' to get the changelog [11:37] ok, thx. Now, debian/rules tells me there's no rule to make target "print-ppa-file-name". I guess the prepare-personal-ppa-source script is obsolete. Can you point me to any docs explaining the current way of building and uploading a kernel source package to a PPA? [11:39] andreoli, the source package for a ppa is the same as a normal upload package, and that is in the maintenance document. someone is writing a simpler one but its not present today [11:49] ok, thx. So upload to a PPA shouldn't be a problem. But I'm a bit confused about building kernel packages. I know how to build a binary kernel package (https://help.ubuntu.com/community/Kernel/Compile) but, as far as I understand, I need a source package for PPA upload. I think I don't understand how to create a kernel source package from the ubuntu git repositories. [11:49] So I'm asking you: is the procedure for building a source package (described here: https://wiki.ubuntu.com/PackagingGuide/Complete) still valid for building a kernel source package, or do I need to do something different? [12:02] andreoli, dpkg-buildpackage -S ? [12:12] andreoli, there is a specific guide for the kernel [12:13] https://wiki.ubuntu.com/KernelTeam/KernelMaintenance [12:13] see 'preparing an upload' [12:13] from after where you tag ... [12:14] basically the clean, then the buildpackage -S === yofel_ is now known as yofel [13:20] apw and diwic, thx for your help. I'll try it now. [13:21] andreoli, luck [13:26] apw, how's your plymouthd race condition patch(s) coming? [13:27] i have something which seems to work in broad brush and gives userspace some hope of coping [13:27] they are a bile unpleasant in some senses [13:27] time to get some other eyeballs on it? [13:27] tgardner, close too ... i am just building the first set whihc is a 'clean' set of patches not just 100 commits [13:28] with all the deubggin out etc to prove to myself they work without [13:28] then yes... i'll want to send them out to us lot [13:29] the cleanup process is the highest danger of losng the fixing ... grr [13:29] but last night i did get 20 sequential boots without a problem [13:29] so i think its there [13:30] apw, cool. I was just looking for something to do this morning, so rather then actually produce something I thought I'd just pick on you :) [13:34] apw: are you saying that you can make sure that grub doesn't interfere with plymouth and with the graphics driver? [13:35] if so, I'd love to see your patch [13:37] I guess I should be using debian.master/rules ... instead of debian/rules [13:39] never mind, forgot to fakeroot debian/rules clean [13:43] tseliot, this is a different issue, that the kernel is sensitive to plymouthd getting to the framebuffers while they are initialising [13:43] tseliot, that we boot so fast we are tickling a number of bugs in initialisation and crashing ... the current boot instabilities [13:44] problem: git log shows my changes, but debian/rules insertchanges won't insert them into debian/changelog [13:45] apw: ah, ok. It looks at least as nasty as a race condition ;) and of course I'm still interested in the patch [13:47] tseliot, yes there are two, one is that the drm driver advertises the existance of the drm devices _before_ it calls load on the driver ... so a process can see and open /drv/dri/card0 or whatever before the i915 etc part of the driver has finished initialising itself ... leading to explosions [13:48] tseliot, the second is a bug in the frambuffer code which essentially renders it unsafe to unregister one... which is procisly what drm does. ... again we have a race triggered by udev gettting to the party real quick [13:48] apw: ok, now I can see why things were failing despite the fact that the drm device was reported as being there... [13:49] yep ... its just not ready, and random behaviour results. i think plymouthd finds no screens (as they arn't there) and immediatly closes the device ... and blows the kernle up as its still instantiating it [13:50] ouch, I'm curious to see how you're going to handle the second case. I guess I'll have to wait until your patches are complete [13:51] tseliot, i delay a critical hashing of the minor number to the driver until initialisation is complete. this renders the /dev/dri interfaces unsable until its ready [13:52] i've tried to do it in such a way we could either loop in the kernle, or as it does now, return EAGAIN to userspace such that userspace can be fixed to retry [13:52] we still have no solution such that plymouth is in sync with which buffer to use etc [13:52] it seems like a good idea [13:53] ah, it could try using the wrong buffer [13:53] i have tried to prevent the instantiation of the udev stuff until after, but the driver assumes they are there such that it can send out udev events [13:53] such as hotplug ... so likely this is a tape over job, and a proper much larger solution needed from upstream [13:54] * tseliot nods [13:55] i suspect if i am crafty glibc will retry the open === sconklin-gone is now known as sconklin === bjf[afk] is now known as bjf [14:20] diwic, moin [14:20] bjf, hi there [14:21] diwic, did you get a mentor assigned to you and regardless of that, do you have mumble installed? [14:28] brb Reboot [14:37] apw, ping [14:38] ericm, pong [14:38] apw, what needs to done every time after mvl-dove branch is rebased against master? [14:38] as in once the rebase is done, what happens ? [14:39] now suppose you need an upload of mvl-dove, what needs to be done? [14:39] fdr startnewrelease? [14:39] getabi? [14:39] to do an official one, yes you need a newrelease (which includes the abi updates) then an insertchanges, the make clean, make the source package, and upload it [14:40] and normally because the rebased mvl-dove carries over the previous tag commit like "UBUNTU: Ubuntu-2.6.32-207.20" [14:40] ericm, right, you should do a startnewrelease with abi stuff [14:40] then you should ubuntu-insert-cchanges with the old and new base [14:41] and commit that as 'UBUNTU: rebase to ' [14:41] then insertchanges sort of thing [14:41] making any sense ? [14:41] yep, I'll make a test run here and let you know if I don't understand something [14:42] ericm, though normally for stable releases the stable team does this lot for you [14:42] apw, yeah that saves me a lot trouble, but now I need to upload a kernel for a oem branch, which is conceptually a similar thing [14:47] apw, still a bit confused, e.g. http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=shortlog;h=refs/heads/mvl-dove [14:48] ericm, how are you confused. that looks ok [14:48] apw, so commit 'UBUNTU: SAUCE: dove: avoid page table overwrite when...' is actually the tip of what's rebased against tag '2.6.32-24.38' in master branch? [14:50] its the newest patch on the branch yes, your rebasing onto our master by definition leaves the same tip patch on the top [15:25] http://en.wikipedia.org/wiki/List_of_Ubuntu_releases [15:58] i'm trying to create an lvm-snapshot. my machine just gets stuck there. here's the kern.log http://pastebin.com/KUzVGZSQ [16:04] thx all, I think I just prepared my first kernel source package :) Now I have a problem: I have a file named "linux_2.6.32-24.39_source.changes". The PPA packaging guide (https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage) tells me to use a linux_2.6.32-24.38-ppa1~lucid1 name. [16:05] How do I enforce this? Is there any command that I can use to change the package name? Or is a simple "mv linux_2.6.32-24.39_source.changes linux_2.6.32-24.38ppa1~lucid" enough? [16:06] andreoli, You should change the debian/changelog accordingly [16:06] * abogani waves all! [16:07] abogani, I tried to do it through the debian/rules insertchanges script, but it seemed to fail silently (it did not apply my git log to debian/changelog). Should I modify the changelog manually? [16:08] andreoli, dch -i [16:08] thx [16:15] So, is it expected for debian/rules insertchanges to fail unless the upload is official? And in case of unofficial uploads, I have to insert the changes interactively through dch -i? [16:30] andreoli, not if you followed the standard no [16:30] that doesn't add it to debian/changelog, but to debian.master/changelog [16:30] debian/changelog is generated by the clean processing === kamalmostafa1 is now known as kamal === kamal is now known as Guest99574 === amitk is now known as amitk-afk [17:22] JFo: around today? was just looking at the kernel-maverick-firewire-stack blueprint. seems there's just one item left that belongs to you, "triage and maintain a list of bugs reported on the new firewire stack". [17:22] JFo: I did an informal search in launchpad -> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.searchtext=firewire&orderby=-datecreated&field.tag=maverick [17:23] JFo: it didn't seem to turn up anything significant [17:23] JFo: did you have something separate in mind for tracking this list of firewire bugs (if any)? [17:26] apw, thx for your response. My modifications don't seem to have been added to debian.master/changelog. I am modified a local git branch. I'll read the docs again. [17:26] (modified and commited) [17:26] ogasawara, I'm here [17:27] ogasawara, my main hope was that those individuals that tested would let me know if they found bugs and filed them [17:27] no one told me that they had [17:27] JFo: that's good then [17:27] yeah, I know of no issues with the new stack [17:27] want me to set that to DONE? [17:28] JFo: sure [17:28] or have you got it already? [17:28] cool [17:28] will do [17:28] another question; should the changelog be for lucid or for lucid-proposed? [17:28] JFo, and we have confirmed its turned on? [17:28] andreoli, lucid for a PPA [17:28] apw, I am under that impression yes, but I defer to manjo [17:29] my understanding was that it was turned on before we sent the CFT [17:29] JFo: I was under the same impression [17:29] for lucid ? [17:29] manjo: maverick [17:29] JFo, ogasawara, confirmed that in maverick the blacklist is inverted [17:29] so if we have exactly 0 bugs we must be reasonably ok [17:30] grrr, screen corruption [17:30] those damn mac users must have firewire for everything i am sure [17:30] need to reboot [17:30] brb [17:31] manjo, what is your timeframe for having the kernel-qa tests ready for addition into kteam-tools? [17:31] I should be able to send a pull request this week [17:32] ok so lets plan on doing that friday [17:32] manjo, wfm [17:32] have a couple of dell things I am busy with atm [17:32] well if you don't get to it, we can just pull in the officail verion and you can work agianst that [17:33] apw, I will have it by fri [17:33] good enoug [17:33] enough [17:38] k, I'm back [17:38] I agree 0 bugs means we are good [17:41] :) [17:41] do we know if people are testing it ? [17:41] yes, we have had feedback from several people on the list [17:41] <-lunch [17:41] cool! [17:42] fedora already had it turned on for a number of releases so I did not expect anything bad to happen in our case [17:48] interestingly, running the git log 087ca8b7e71139f7a0b21a5ad82f1ce7031daf28..HEAD | perl -w -f debian/scripts/misc/git-ubuntu-log works properly [17:49] trying to achieve the same through debian/rules insertchanges does not work [17:50] sconklin, tgardner that dodgy frequency relaxing patch for ironlake monitor frequency (the one which changes >> 10 to >> 9) seems to have hit stable [17:51] apw: yes, I think Manjo is planning to send it to u-k-l [17:51] sconklin, well, why would he have to? We'll get it naturally as part of stable [17:53] tgardner, so that will be in the kernel next 3 weeks or so ? [17:54] that'll happen anyway [17:55] asking so that vanhoof has an idea of time line [17:56] I think we've made it clear that the stable update and SRU process is not deterministic [17:58] and he was there for that discussion .. [17:59] apw: right [17:59] im not asking when it will be released [18:00] i was more interested in making sure its proposed [18:00] Actually he was also there for a discussion about how the patches could land in proposed within a couple of weeks provided they were in stable upstream and the security release went as expected. [18:00] proposed for inclusion, or "in proposed" [18:00] apw: proposed for inclusion [18:00] right they should indeed be in proposed pretty soon in the normal run of things [18:01] so i'd say if we are going to have that stable release in the next -proposed we rely on that, if we have too much stacked already to take the whole stable then we do it as one on its own [18:02] ogasawara, does the -12 kernel use the new compilers [18:03] JFo, have we or are we considering a call for testing on the new compiler/M686 combination ? [18:04] apw: yep [18:04] i wonder if the announcement should have said that ... [18:04] apw: QA team should have results as well and relay them to us [18:04] ok cool [18:05] with all the graphiics issues, i suspect their testing will be 'its broken' both sides of the line [18:05] apw: yah, I should have noted that in the announcement [18:06] apw: scratch that. the -11.16 was actually the first to be build with the new compiler/M686 combo, and I noted it in that announcement [18:07] ahh cool... my mistake [18:08] ogasawara, where can I get the -12.17 kernel from? [18:09] I think I got the problem. It seems I have to debian/rules startnewreleas in order to get the " CHANGELOG: " tag into debian.master/changelog.new. Then, debian/rules insertchanges works as expected. Problem is, I have to change the version name by hand. I'll do that. [18:09] bjf: https://edge.launchpad.net/ubuntu/+source/linux/2.6.35-12.17/ [18:10] ogasawara, its amusing that tgardner's PPA had the same kernel before the archive :) [18:10] (which i've been running for two days) [18:12] apw, well, I didn't have to wait on the tool chain [18:12] tgardner, ahh good point [18:13] still good results ... so far ok for 2 days [18:13] apw, did the writeback patches help performance? (or am I thinking of 2.6.32 stable) [18:13] hrm not sure, i've not notices much in the way of issues [18:14] ogasawara, i'll try and get you some patches for review today ... i have some obvious ones which should go in [18:15] you are aiming for either friday or monday depending on linus i believe [18:15] apw: hoping for friday, but yes waiting to see if 2.6.35 final drops [18:15] i guess upload friday with whatever you have, and then see on monday? [18:16] this damn console issue is going to kill me before long, now the console switcher has broken [18:16] apw: yep, that was my plan [18:16] * apw removes his mind-meld [18:35] ogasawara, you got the release meeting on friday? [18:35] apw: yep [18:35] apw: take the day off [18:35] cool then i think i am going to take friday as a comp day [18:43] apw, drm fixes should go to 2.6.33 or 32.y ? [18:44] sconklin, ^ ? [18:44] generally when submitting to stable you are saying 'this should go anywhere it applies' [18:44] and indicate places known to be affected [18:45] ok coz I need to do some backporting [18:45] the patches don't apply cleanly to 32 or 33 [18:45] grr [18:45] manjo: yes, what apw said [18:45] apw, so I need to pick a tree and backport [18:45] if you can supply ported ones then you will be much more popular, .33 is what we need, which may mean .34 in some senses [18:46] ok so I will port againt .33 sounds resonable ? [18:46] we [18:46] we need it there regardless [18:47] I thought you said 'yes' in french [18:51] manjo, I had to backport a hostap_cs patch to each stable release, so I sent stable 4 separate patches [18:51] probabally worth noting we need to test them before sending them [18:52] apw, tested against lucid [18:52] which is 2.6.32+~33 [18:52] yep the backports though need testing where possible [18:53] tgardner, I am going to send stable port against .33 1st so that it will make it to lucid, 1st prio, then send them others later if required ? [18:54] manjo, I take it that this is a DRM patch? [18:54] apw, I can have james from OEM team test the backport [18:54] yes [18:54] tgardner, yes [18:54] then .33 is likely the oldest kernel to which it applies anyway [18:54] manjo, yep i don't mean you have to test necesasarily but sending broken things to stable makes you die horribly [18:55] tgardner, ok cool that is the ans I was looking for [18:55] apw, yep understood [18:56] Q2: do we include buglink: ... in the patch ? [18:56] like we did for SRU ? [18:57] manjo, since you have to update the commit log anyways to explain that this is a backport, then you might as well include the buglink. [18:58] I guess if Greg doesn't like it he'll either elide it or make you do it over [18:59] i say for that i'd tend to put it in the s-o-b block [19:36] I'm looking at our SRU policy - can anyone tell me why the retention times are specified like this?: [19:36] "Uploads containing a upstream stable patchset increase the retention period to two weeks, while it is one week otherwise." [19:36] wouldn't we consider upstream patches to be better tested than otherwise and thus requiring less time to bake? [19:36] Should we just make it two weeks regardless? [19:39] sconklin: smb would know for sue, but I think that was originally written because of the size of some of the stable patch sets and the SRU team thus preferred a longer baking period [19:40] sconklin: I'd say just make it two weeks regardless. I don't think I've seen kernels promoted after only 1 week anyways. [19:42] ogasawara: thanks. Yeah, I'll check with smb, but I think a flat two weeks is good policy [19:45] sconklin, thats because the updates in a stable block are not known to fix an issue someone is seeing, so more care is needed [19:46] apw: yes, but we seldom actually get any feedback that a proposed kernel has fixed anything for anyone, so whether issues are fixed don't see to be related to the bake time - only whether we get reports of regressions [19:46] don't seem [19:46] right its about the expection that there is more likelyhood of a regression in 100 patches than the 10 we'd have otherwise [19:46] so it needs longer to shake out [19:47] remember on average we add 5-10 sru patches and 150-300 stabe patches in an update [19:48] apw: point taken. [19:48] damn recursion error ... i've printed something for every update to the console, which includes the printing ... DAMN [19:49] But - I think the opposite is true, that stable patches are less risky. As an example, look at the "temporary" patch that was put in Lucid for the file system unmount delay, which caused a new error. [19:50] * JFo goes to take meds and nap a bit [19:50] bbl [19:50] * sconklin needs meds [19:50] and I don't have the flu :) [19:50] sconklin, well indeed, and look at the ones we have put in in stable and had them reverted in the next stable [19:50] * JFo just got some at lunch... here's hopng they help [19:50] so ... its all much of a muchness [19:51] apw: I suppose that the biggest lesson is that there's no substitute for adequate QA [19:51] the wording as there was a result of talking to the sru people who didn't want to take them at all, but said if we soaked them longer they would not whine too much === bjf is now known as bjf[food] [20:00] does lucid support ext3's data=guarded mode? [20:01] i don't see anything in Kconfig regarding it. i haven't poked into the source just yet [20:02] hm, git grep guarded doesn't seem like it's there [20:15] * ogasawara lunch [20:19] just a followup, data=guarded isn't even upstream. not sure what happened to it, but oh well. === kamalmostafa is now known as kamal === bjf[food] is now known as bjf === kamal is now known as kamal-lunch [20:32] -> lunch [20:47] sconklin, have you seen this ? http://www.arrl.org/ubuntu-linux-for-hams [20:47] manjo: yes, thanks [20:48] manjo: I've already exchanged email with the author [20:48] sconklin, cool! [20:49] he's not happy about nvidia in Lucid [21:12] heh, then she should have tested it when it was fresh [21:12] sconklin, ^^ [21:14] apw: wrong side of the chasm [21:22] bah [21:22] its like taking responsibility for anti-social behavour in your neighbourhood [21:22] you should also take responsibility for your digital welfare [21:22] sconklin, ^^ [21:24] what _are_ you guys ranting about? [21:28] apw: aer you calling nouveau anti-social? [21:30] heh not quite [21:30] :) [21:45] speaking of nouveau - https://bugs.freedesktop.org/show_bug.cgi?id=26980#c25 [21:45] Freedesktop bug 26980 in Driver/nouveau "GT230M or GT218 with nouveau: X server hangs spontaneously" [Normal,New] [21:46] a large chunk of cards could probably do with being quirked to noaccel=1 [21:50] Sarvatt: wow, that is sooo special! (new microcontroller) === kamal-lunch is now known as kamal [21:52] Sarvatt: any idea how we can generate such a list of cards> [21:52] ? [21:53] 10DE:00A3 10DE:00A5 10DE:00A8 10DE:00A8 10DE:00AF 10DE:00C0 [21:54] oops minus the 00A8 repeat [21:55] theres a list here in order of newness - http://github.com/pathscale/envytools/blob/master/nvchipsets.xml [21:55] can't just use the whole range because 00AA and 00AC are older than those others [21:57] hi sconklin apw, I had a few issues, in which I would appreciate some kern dev love... I was unable to install i386 RC5 mainline kernel on a system which currently uses a pae kernel (4GB+ RAM). [22:01] Sarvatt: is there an ubuntu bug for this yet? [22:02] yeah i'm sure there are a bunch, i haven't had a chance to look yet but will tonight and tag them [22:02] komputes_ubuntu: unable to install, or unable to boot? [22:03] Sarvatt: ok, and we should probably wrap them all in one master bug for the quirking [22:03] sconklin: shows as installed, does not show up in grub [22:03] thanks [22:03] sconklin: looks like pae kernel is there already, also looks like system is has grub 0.97 installed [22:03] wish i could search file attachments on LP for this backtrace in one of the old logs - https://bugs.freedesktop.org/show_bug.cgi?id=26980#c27 [22:03] Freedesktop bug 26980 in Driver/nouveau "GT230M or GT218 with nouveau: X server hangs spontaneously" [Normal,New] [22:04] Sarvatt: bjf has some tools that might be able to do that [22:04] sconklin: After successful installation of these packages, rebooted holding down shift, GRUB only shows 2.6.32 kernels [22:05] Sarvatt, which log would that backtrace show up in? dmesg? [22:06] one of the 3 gdm logs or xorg.0.log.old [22:06] just searching for nouveau_bo_wait would spot most of them [22:06] Sarvatt, do you have one bug that you can point me at as an example? [22:06] Sarvatt, in the title? [22:07] no it'd be in the old logs, i don't have a bug handy and i have to run for a few hours but i'll dig one up when i get back [22:07] Sarvatt, i'll look in the mean time [22:11] oh those pciids i listed were wrong, it goes like 10de:0a30-10de:00a3f for each range [22:11] bjf: https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/585462 [22:11] Ubuntu bug 585462 in xserver-xorg-video-nouveau (Ubuntu) "random interface freeze (affects: 1) (heat: 60)" [Undecided,Confirmed] [22:12] thats for sure the same bug [22:12] Sarvatt, thanks [22:13] nouveau_bo_map_range would be what you'd have to search for, nouveau_bo_wait doesn't show up without debug symbols [22:15] Sarvatt, ok, will look into it [22:15] http://launchpadlibrarian.net/49083633/GdmLog2.txt [22:15] * bjf will be back in a bit === bjf is now known as bjf[afk] === BenC__ is now known as BenC === sconklin is now known as sconklin-gone [23:24] jjohansen: I just wanted to apologise, the bug with regards idle load is getting a lot of FUD in the last 72 hours; too many users jumping to conclusions IMO [23:24] astinus: np, that happens [23:24] jjohansen: I still think the best way to approach is to look at it on an idle box which has just been installed, no workload - if there is an actual knock-on performance impact due to whatever bug, we can clobber that ("Two birds, one stone") later on [23:25] jjohansen: I can't help but feel there is a huge glaring "RIGHT HERE!" plastered over the fact a Karmic Koala kernel loads using like 85% less memory (straight after boot) and my only issue so far has been, beyond the Wiki page detailing changes and the obvious version bump, I don't know how to bisect [23:25] astinus: there is an actual problem, its not just load reporting [23:26]