[00:36] moinmoin === kamal is now known as kamal-away [00:53] who should I poke to review my three kernel hardening patches? [01:00] kees: I'll take a stab at them, and then probably apw, rtg or smb [01:02] jjohansen: okay. I figured everyone was busy during UDS last week, but thought I'd ping on it this week. [01:02] kees: yeah, and this week everyone is recovering from last week :) [01:02] \o/ uds hangover === Edgan__ is now known as Edgan [01:11] is there any patch for a modules for the i915 kms that does a burn-in test of most basic functions of older chipsets ? [01:11] *module [01:14] btw if you warm-reboot a system from linux into memtest, you are going to find a lot of errors, all due to memory locking [01:57] anyone in here ? [01:59] I just got a i915 on a i855 xorg abort while I was ssh-d into it, so I took control when I saw the console screen on the display and I did a reboot in the ssh, and the ubuntu splash appeared, which make me think the problem is either xorg-centric, or the hangcheck code has a bug in it. [01:59] or am I mistaken to think that the splash screen is also part of kms ? [02:08] lapion: Have you seen the i8xx GPU hang wiki page? [02:11] okay tht page was not known to me [02:15] You've found it? [06:59] Morning :) === rsalveti_ is now known as rsalveti [08:19] I still don't have permissions to create a directory on zinc =:-( [08:23] lag: group? [08:23] * abogani waves [08:23] * amitk waves back [08:40] * smb waves [08:41] amitk: we are going to use -omap4 package name for our 10.07 release [08:41] lag, Where do you want to create it? In your home? [08:41] smb, no in git export [08:41] amitk: need i change the branch name from ti-omap to -omap4 or ti-omap4 [08:41] seems to have changed ownership for some reason [08:42] lag: nice to meet you, [08:42] smb: apw morning [08:42] cooloney: Likewise [08:42] apw, to kernel-ppa most interestingly... [08:43] yeah, not sure why that would be done, and i think i could partly pull it back, but i want to know why in case there is a reason [08:43] Yup, umderstanably [08:44] cooloney: we won't *replace* the existing ti-omap since that is a supported flavour. [08:45] cooloney: just create a new branch, ti-omap4 for all the omap4 patches [08:46] amitk: ok, so i need copy over all the debian.ti-omap to debian.ti-omap4 [08:46] amitk: then fix something in the dir and generate our package [08:48] cooloney: yes [08:49] amitk: ok, working on this. thx [09:46] dchroot -c lucid-i386 [09:47] * popey wonders if there's anything else he can do for bug 576601 :) [09:47] Launchpad bug 576601 in linux (Ubuntu) (and 1 other project) "[MacBookPro 7,1]mcp89 sata link reset fails, no disks detected (affects: 31) (heat: 190)" [Medium,Triaged] https://launchpad.net/bugs/576601 [09:54] popey, fix it :) [09:55] * apw feels like moving it to a Low priority for the arrogance that mac users are showing in it ... "a large proportion of ubuntu users affected" yeah right [09:55] [ 60.975812] [Firmware Bug]: ACPI(IGPU) defines _DOD but not _DOS [09:55] quality apple as always [09:58] Who needs standards when you produce the entire stack! [10:00] RAOF, i so wish you were wrong [10:01] I mean, at least Apple isn't *deliberately* messing with us here. [10:03] They could do something totally ridiculous, like encrypting the partition tables or something. [10:06] :) [10:09] the good thing about standards is that there are plenty to chose from! [10:09] apw: would it help if I put the machine online for one of you guys/gals to ssh into and poke about? [10:11] it may, i'll need to read that debug and try and add stuff to it to get more infor and get those boot tested, so likely its easier for you to do that [10:12] ok, no worries, if you need access just let me know. [10:38] apw, you know how comes vga16fb being always loaded even with a valid drm fb? [10:40] ericm|ubuntu, its a fallback and iirc there is no better way to tell its needed, but it should back off when it detects another fb [10:41] smb, I don't see any vga16fb in modprobe.d somehow? [10:42] how's that being requested to load? [10:43] as part of the startup scripts I believe [10:44] * psurbhi takes a lunch break [10:45] smb, yeah - /usr/share/initramfs-tools/hooks/framebuffer:manual_add_modules vga16fb [10:46] smb, ok - thanks [10:46] ericm|ubuntu, why the long irc nick? [10:46] cking, ericm is occupied [10:46] ahah [10:47] ericm|ubuntu, its loaded cause it matches the VGA* [10:47] via modaliases, that will go away with maverick [10:47] apw, ah right - manual_add_modules only copies the ko itself [10:48] apw, where's modaliases? [10:48] modinfo vga16fb [10:48] filename: /lib/modules/2.6.32-22-generic/kernel/drivers/video/vga16fb.ko [10:48] alias: pci:*bc03sc00i [10:50] smb, so it's /lib/modules/2.6.32-22-generic/modules.alias? [10:50] That is generated from the info the modules carry [10:51] smb, so every graphics card matches pci:*bc03sc00i ? [10:52] You normally have tha VGA compatible controller part [10:52] the alias meas VGA CARD [10:52] smb, ok I see [10:53] The bc03 and sc00 [10:53] not sure what bc exactands for again [10:54] * ericm|ubuntu reading http://wiki.archlinux.org/index.php/ModaliasPrimer - seems to be a good reference [10:54] apw, smb, the module list for modules.alias is maintained by the kernel debian build scripts? [10:54] or somewhere else? [10:55] ericm|ubuntu, The source _are_ the modules [10:56] smb, yet I found no vga16fb info in karmic kernel? [10:56] ericm|ubuntu: all the ids registered with the drivers are the source of the modaliases [10:57] ~/src/ubuntu-lucid/kernel$ grep ALIAS drivers/video/vga16fb.c [10:57] MODULE_ALIAS("pci:*bc03sc00i*"); [10:58] In the karmic kernel there wwasnt this [10:58] I think there it might be actually being loaded by the startup script somewhere [10:59] smb, I think commit http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=commitdiff;h=efc4c46c0d0aba445226f86898b7aed7a0642d05 changed the alias and make a wider match of VGA [11:01] smb, I see modules.alias and vga16fb.ko in karmic kernel, how comes it doesn't show up in modules.alias? [11:02] ericm|ubuntu, Because in Karmic the module does not define an module alias? [11:03] smb, I think MODULE_ALIAS should be already introduced? [11:04] ericm|ubuntu, But you _can_ write a module without using it [11:04] smb, ah right - checked again, vga16fb doesn't have a MODULE_ALIAS in karmic kernel [11:05] Exactly [11:05] ok, I think I can sleep tonight now :-) [11:07] right we added it for the boot performance work, as we can then wait for any FB to come live as one definatly will [11:09] apw, that makes sense === smb is now known as smb-afk [11:24] Does anyone know what could be causing this error? http://pastebin.ubuntu.com/436071/ === kro_ is now known as kro [11:39] jpds, make V=1? [11:41] ericm|ubuntu: Curious: http://pastebin.ubuntu.com/436074/ [11:43] jpds, it doesn't look to compile anything - maybe a make clean + make? [11:43] ericm|ubuntu: Same result. [11:44] jpds, how's the Makefile look like? [11:44] ericm|ubuntu: http://pastebin.ubuntu.com/436076/ [11:47] jpds, but it looks like nothing is being built - not even those $(MODULE_NAME)-objs := rtmp_main.o mlme.o connect.o rtusb_bulk.o rtusb_io.o \ [11:47] sync.o assoc.o auth.o auth_rsp.o rtusb_data.o \ [11:47] rtmp_init.o sanity.o rtmp_wep.o rtmp_info.o \ [11:47] rtmp_tkip.o wpa.o md5.o rt2x00debug.o [11:47] jpds, tried explicitly 'make modules'? [11:48] ericm|ubuntu: There's no modules target, but 'module' returns the same error. [11:51] jpds, tried explicitly 'make -C /lib/modules/$(uname -r)/build M=$(pwd) modules? [11:52] i.e. skipping the module phony === ericm|ubuntu is now known as ericm-afk [11:59] ericm-afk: That appears to only do: http://paste.ubuntu.com/436083/ [12:21] hi. im the one with the diying keyboard. i only want to say, that its not the g15daemon who causes the error. this time i stopped the daemon and the keyboard dies. so it must be something different. === cnd is now known as cnd_swap === smb-afk is now known as smb [13:08] * psurbhi someone at UDS infected me with their cold and cough :( .. and i had just finished my previous dose at UDS.. when is this cold going away! i want to work without being bogged down by it.. :( [13:08] cking, hey ... do we expect uefi bios'en to boot a lucid image ok ? [13:09] psurbhi, thats why we all try and work from home as much as possible, keep the lurgies away === JanC_ is now known as JanC [13:22] cking, about ? [13:23] apw, sorry, was distracted for a mo [13:24] apw, I got a lucid alpha2 to boot on an Intel based dev platform a while ago - but there were issues in setting the video modes. [13:25] cking, so this thing also has a WIN-P button ... i am starting to think we should just bind the thing to the appearance applet in gnome [13:25] apw, the Win-P issue needs resolving in userspace IMHO [13:26] we're never going to get the bios people to do something sensible [13:26] especially when pressured to do insane hot-key weirdnesses based on pressure from Microsoft [13:29] cking, so should i risk turning on the efi bios ticky? [13:29] apw, as long as you can turn it off ;-) [13:29] cking, do i expect it too boot? [13:30] you will have probs booting it though - I can send you the magic to config up the boot [13:30] cking, hrm ... not sure i want that level of pain [13:30] it's not too painful - honest! [13:31] it just hurts a little [13:32] cking, i added the sensors applet, i have about 20! [13:32] looks like it's a sensitive soul [13:34] apw, hacky notes email'd to you === JFo-afk is now known as JFo [13:59] cking, nothing so far, temps remaining constant [13:59] cking, nope [13:59] ..got a freezer handy? [14:00] oh, one fan just went off [14:00] yay [14:00] cking, i installed 64 bit, thinking of reinstalling 32 bit to see if that helps [14:01] apw, 64 bit will twiddle more transistors that's for sure [14:01] yeah hard to know how much worse/better, but i can test at least [14:04] apw, I suspect a few degrees C [14:04] i wouldn't be supprised, its not turned the fans back on since i got it back out, interestingly [14:04] apw, worth looking at the power consumption when idle for both 32 and 64 installs [14:05] yeah i guess i'll install both side by side for testing [14:09] cking, fans came on when the machine touched 54, and even though they got it down to 51, they arn't getting it any further, and i suspect their hyterysis is lower than they achieve [14:09] cking, just sent you some scripties and info [14:10] JFo, much appreciated! [14:10] my pleasure :) [14:10] apw, well, wonder what it's like with Windoze for idle temp [14:10] windows is gone, the installer ate it [14:10] lovely [14:10] yeah [14:11] it was their fault... they used up all the four primary slots, for the first 30 and last 10GB of the disk [14:11] apw, I normally dd the entire drive to some backup before faffin' around on this kit [14:11] and installer just heaped itself [14:11] you are more troll like than i :) [14:11] once bitten and all that [14:12] woner if its has a recovery paeriio [14:12] partition [14:12] that's some typo [14:13] indeed [14:13] i suspect you totally nuked it [14:15] * cking spots a 75000+ jiffy delay in S3 resume - looks like the mysterious 5 minute delay to me [14:15] * abogani waves BenC [14:16] apw, this appears to be a quick answer type of deal, bug 289087 [14:16] Launchpad bug 289087 in linux (Ubuntu) (and 1 other project) "Missing linux-image-debug packages and metapackages since Intrepid (affects: 22) (dups: 4) (heat: 182)" [High,Triaged] https://launchpad.net/bugs/289087 [14:17] smb: Hi! How should I proceed to see updated linux-rt package uploaded into Lucid archives? [14:18] abogani, sadly wait. I have a look next. But there is other stuff I need to do first [14:19] smb: No problems. I would want only know that I haven't other things to do. Thanks (in advance). [14:20] abogani, No, the ball is on my side I guess. [14:21] smb: Ok. Thanks again. [14:23] abogani: hey [14:37] JFo, what is there to answer, they are where the first comment says they are? [14:38] apw, do we provide them? [14:38] it seems as if there may be some confusion on the part of the bug commenters [14:38] have you read pitti's answer in comment #1 which point to where they are [14:38] other than the oens which are missing cause of the reaper of course, but most are there [14:40] * smb is dropping off irc. need to concentrate [14:40] smb ack [14:45] JFo, there is no reasoning with people who do not read what is in front of them, i have added a yet furhter explanation and i think we should close it fix released [14:46] ok, thanks apw [14:52] done [14:52] JFo, ok i've put in a closing comment and closed it [14:53] cool [14:53] ahh we overlapped, in just the right order [14:53] heh [14:54] apw: ogasawara: Since we're going to have two omap flavours for maverick, do you have a preference for the naming? [14:54] apw: ogasawara: omapmainline and omap4bsp ? [14:54] amitk, is the current one not already omap ? [14:55] i don't see any need to rename the current flavour no ? [14:56] apw: still cloning the maverick tree, I don't know what current is. [14:57] amitk, existing is omap [14:59] amitk, cant you call them like the packages ? [14:59] -omap and -omap4 [15:00] amitk, cooloney already builds -omap4 and -omap exists in lucid [15:01] once we can merge 3 and 4 we can easily switch back to -omap for everything, that saves a lot of upgrade transition stuff [15:02] amitk, are these two _new_ falvours or related to the existing omap and omap4 work we know about [15:02] omap is the one we already have in lucid (omap3, just newer upstream version) [15:03] omap4 will be new with the 10.07 release and we should provide a proper upgrade path to 10.10 [15:03] ok and those are one and the same as the ones amitk is talking about? [15:03] (since 10.07 will only be supported for a very short period) [15:03] if so then yes, omap is already called -omap and -omap4 seems approriate for the new one [15:04] apw, -omap is todays lucid omap3 flavour ... apart from using a newer mainline i wouldnt expect any changes to it [15:05] * apw wonders where 10.07 is going to exist [15:13] apw: 10.07 is mostly PPA work [15:13] apw: ogra: omap and omap4 sounds good [15:14] apw, mind having a look at bug 512192 [15:14] Launchpad bug 512192 in linux (Ubuntu) "Can't configure Elan tech touchpad on Dell Inspiron 11z, Asus K7I0C and maybe also Dell Mini 10 (not V), Asus k40in, Asus U81A, Asus UL80-VT, and Asus N61Jq. (affects: 63) (dups: 3) (heat: 410)" [Undecided,Triaged] https://launchpad.net/bugs/512192 [15:14] amitk, great [15:14] If I'm to have arm devs kicking around in my bugs they will need to follow the process [15:15] as far as status goes that is [15:28] cking, this heap is staying 50% in C2/50% in C4 when 'idle' that sounds wrong to me [15:29] sconklin, want to take a look at bug 564508 it has a git SHA in it [15:29] Launchpad bug 564508 in linux (Ubuntu) "Add USB_DEVICE Sitecom WL-349 to rtl8192su (affects: 1) (heat: 6)" [Medium,Triaged] https://launchpad.net/bugs/564508 [15:29] cking, in both 32 and 64 bit, its about the same [15:29] JFo: wilco [15:31] JFo, seems to be nothign to do on that than wait, unless you are proposing we take those four patches [15:31] i'd think we'd want the autodetect as well with it to be any use, and thats not till the next merge window [15:31] with all five we could test and consider them for lucid, depends how huge they are [15:32] apw, no... it looks like one of the 'arm' people is working it, but had it set to In Progress and unassigned [15:32] was my last comment too much? [15:32] that is my main concern [15:32] no its fine, you said its not inprogress without an assignee, and you arn't assigning it to someone [15:32] right [15:32] cool [15:32] * JFo moves on ;-) [15:34] smb: ping [15:36] smb is offline as he is working on some critical updates which are getting urgent [15:36] apw: No problem, I'll touch base with him tomorrow instead [15:44] ogasawara, bug 582555 appears to be a heads up on some coming changes that we will need to remain aware of :) [15:44] Launchpad bug 582555 in linux (Ubuntu) "ndiswrapper has issues working under kernels 2.6.33 or greater (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/582555 [15:45] cnd_swap, if you are available, mind having a quick look at bug 581312 [15:45] Launchpad bug 581312 in linux (Ubuntu) "Unknown key fee[x] pressed (affects: 1) (heat: 12)" [Medium,Triaged] https://launchpad.net/bugs/581312 [15:50] so on that one that we were looking at the other day for Mark ^^ [15:51] something appears to be detected twice as separate input devices [15:59] ogasawara, I jumped on -virtual 'cause its causing me a PITA for the LTS backport. [15:59] tgardner: it's all yours :) [15:59] tgardner: I've dropped it from my todo list as I saw you've already started on it in the misc blueprint [16:00] ogasawara, yep - saw the wiki update which reminded me to get in touch with you [16:00] JFo: am following up on 58255, thanks for the heads up [16:01] certainly :) [16:02] apw, what's it doing when it's idle? [16:02] nothing as far as i can see. in 64bit its even 98% n C4 [16:02] and still on fire [16:03] i have the feeling its not using something it should to control itself [16:03] i assume you are using the powers of powertop to see whats happening [16:04] yep, it says its ok basically [16:04] but its not [16:04] "it's not == the fan is out of control"? [16:04] any idea waht the contents od /proc/acpi/processor/CPU/throttling means [16:05] cking, no i mean the machine is hot, over 50c at 'rest' [16:05] apw, not off the top of my head [16:05] apw, have you disabled compiz? [16:05] yes [16:06] that's one sick puppy then === saispo is now known as StEdward [16:08] apw, if it's 98% in C4 and still hot, then it sounds broken to me [16:08] ogasawara, when reviewing stable patches for SRU, how far do you go? Do you just see if they look sane? Do you try to apply them to see if they need fiddling? Build? Test? [16:09] sconklin: all of the above [16:09] cking, my take on it too [16:09] ogasawara: ok, so how can you process 20 a day? :) [16:10] sconklin: first I'd apply them, which usually goes quickly and cleanly [16:10] sconklin: then I use the meld script to give them a once over [16:10] sconklin: then a build, and test [16:11] apw, I'd still install another OS on it and see how that behaves.. just in case... [16:11] sconklin: but I could only get through like 60-80 patches a day before my head would expload [16:11] ogasawara: ok, cool. I think I'm used to some of the driver backports, which often don't apply cleanly [16:11] sconklin, they don't make into the stable kernel _unless_ they apply cleanly. [16:12] tgardner: yeah, that's pretty obvious in hindsight [16:12] sconklin, do you have this? git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6-stable.git [16:14] sconklin: do you have the cherry-pick.sh script and the git-compare-all script? makes the applying and reviewing steps less painful [16:14] tgardner: no, I thought we worked from git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.32.y.git (or whatever the appropriate kernel is) [16:14] cking, dispite this machine claiming to have C1,2 and C4, the states in the kernel do not appear t match [16:15] apw, in what way don't they match? [16:15] sconklin, linux-2.6-stable.git has branches for each stable kernel [16:15] ogasawara: I think they are in stefan's scripts, haven't looked yet [16:16] tgardner: awesome [16:16] cking, /proc/acpi/processor/CPU0/power has this: [16:16] states: [16:16] C1: type[C1] promotion[--] demotion[--] latency[001] usage[00003440] duration[00000000000000000000] [16:16] C2: type[C2] promotion[--] demotion[--] latency[020] usage[00169577] duration[00000000004419124999] [16:16] note C1/C2 [16:16] on my atom i get C1/C2 and C3 mentioned [16:17] (other atom) [16:17] tgardner, ogasawara sorry, dealing with lots of inbound phone calls - my son wrecked the car last night [16:17] sconklin, man oh man, that one needs locking up [16:18] tgardner: he claims that it was the toyota "unintended acceleration" problem, and the marks on the road sort of back him up, so I'm trying to keep an open mind [16:18] sconklin: hope he's alright [16:19] sconklin, shit! [16:19] yeah, he's fine. Put it into a ditch and slid over about 50' of large rocks, completely destroyed the bottom. [16:19] apw, send me the acpi tables and I will poke around and see wassup [16:20] apw: What's exposed in /proc/acpi will depend on your BIOS - they often change from AC to battery, and the CPU states they map to may be entirely different again [16:20] he actually made some pretty good decisions about how to handle it [16:21] * apw cries [16:21] cking, how do i get those for you [16:22] an opportunity to improve arsenal scripts, perhaps? [16:23] apw, sudo acpidump > acpi.info and send it to me... [16:28] cking, hrm its quite big [16:28] cking, i emailed it to you, and also put it on chin [16:28] apw, yeah, lots of ACPI goodness - not [16:29] mjg59, thanks you've made my day [16:30] C3 in the bios will typically be C6 on modern CPUs [16:30] * kees looks around for smb [16:30] mjg59, as in "C6 appears to be C3" in powertop? [16:30] To make matters worse, it may be of ACPI type C2 depending on the precise system [16:30] kees: I think he's on holiday today? [16:30] ogasawara: ah-ha, thanks. [16:31] ogasawara, kees no he is offline doing some updates for kees without interuption [16:31] cking: Yeah, powertop has some knowledge of the actual CPU states that are used [16:31] apw: hah, seriously? [16:31] On my laptop, BIOS C2 corresponds to CPU C4 [16:31] kees, if its related to your updates i may be able to get [16:31] hold of him [16:31] Unless I'm on battery, in which case BIOS C2 corresponds to CPU C2 [16:31] And BIOS C3 corresponds to CPU C6 [16:31] apw: no, nothing there; he just wanted to get some help with bzr and I offered to help [16:31] And I don't get CPU C4 at all [16:32] kees, i suspect he will be back later when he is done with the work he is on, just couldn't concentrate with us wittering at him [16:32] apw: heh, okay === pgraner is now known as pgraner-afk [16:41] apw, do we need to move postponed items from Lucid blueprints to some new blueprint? [16:42] jfo potentially yes [16:42] k, was just looking over the lucid bug handling [16:42] will add those items to the maverick one [16:42] ok [16:43] so they can be reviewed [16:45] done, want me to subscribe you to it? [16:58] ogasawara: the kernel team tools repo has git-compare-all but not cherry-pick.sh, want to send it to me and I'll add it? [16:58] sconklin: sure, just a sec === kamal-away is now known as kamal [17:01] sconklin: sent [17:01] ogasawara: thx [17:08] * JFo goes for some lunch [17:12] cking: Hi -- at UDS you mentioned that you might have some pointers for debugging a laptop I'm working on where the system runs insanely slow after installation (but seemed fine when booted from a live-boot USB stick and during install) -- as if its being hammered by interrupts or something -- thoughts? [17:14] kamal, /proc/interrupts has the counts in it [17:14] kamal: check and see if bug #555595 looks related at all [17:14] Launchpad bug 555595 in linux (Ubuntu) (and 1 other project) "Intel graphics performance regression in 2.6.32-19 lucid kernel update (was: Firefox Slows Down Compiz) (affects: 8) (heat: 56)" [Medium,Triaged] https://launchpad.net/bugs/555595 [17:14] yep [17:15] apw: oh beautiful -- that looks like it will be very useful -- I'll boot the thing up and check it (in an hour when its done booting!) [17:16] sconklin: this laptop seems like its just crawling, even long before X starts up -- does that exclude the bug you mentioned? Either way, how can I disable i915 completely with a boot option? (seems like a good thing to know how to do). [17:17] sconklin, the latest pull request from Dave Airlie includes Intel Cougarpoint support [17:17] kamal, i think u can add single to the boot command line to stop the rest of booting [17:18] kamal: it's probably not the same, since the bug referenced is apparently related to compiz [17:18] apw: ah yes, that'll do. thanks [17:19] sconklin: got it [17:19] kamal: have you tried i915.modeset=0 ? just to isolate KMS [17:19] ogasawara, i boot tested the amd64 version of your .34 based kernel and it worked [17:19] apw: woot! [17:19] sconklin: I haven't tried it, but will do. [17:20] tgardner: Hi Mr Gardner, May disturb you with a single question? [17:20] kamal: the otehr thing you can do is tell the kernel to use vesafb, don't remember the command line - that will be slower but shouldn't crawl [17:20] * apw notes that abogani has used up his single question [17:20] heh [17:20] tgardner: Yeah, I knew that support was going in but had heard that it was still the basic plumbing parts, I have not looked at it [17:20] ogasawara, yeah didn't fix my issues but did at least boot [17:21] apw: ;-) [17:21] sconklin: i'll find the switch if I don't get joy from the lower level investigations -- I think I'll be able to reproduce the problem with 'single' even. [17:21] apw: what issues is that? [17:21] abogani, its always best to ask the original question out right, as we can say no to the question as much as say no to the request to ask [17:21] abogani, ask apw, he's got all the answers today. [17:21] * apw quits [17:21] ogasawara, i have a fan issue on a new bit of kit here [17:21] .34 didn't fix it [17:22] apw: ah. I'll cross my fingers for .35 to magically fix it :) [17:22] apw, tgardner: Is there a chance to have -preempt kernel on i386 in Maverick? I would want use it a default kernel for Ubuntu Studio. [17:23] * persia notes that many Studio users still use i386, for all they have been advised to use amd64 many times. Some cite HW issues. [17:24] mdomsch: does dell-firmware working on lucid? [17:25] persia, won't those folks having 64 bit compatibility issues get screwed anyway with the recent toolchain change to i686? [17:26] No. I can purchase a new computer in the shop today that runs i686 and not amd64. [17:26] atom based I assume [17:26] or VIA, but yeah, it only happens for special chips. [17:27] * persia is kinda happy the C7M is now "old", as it didn't do all of i686 [17:28] abogani, I've been trying to limit the number of flavours (though I'm in the process of converting the virtual sub-flavour into a regular flavour) [17:29] besides, I thought the studio folks were using the -rt kernel anyways [17:31] abogani: do you mean that with all the -rt stuff that has gone into mainline, you won't need an -rt kernel anymore? [17:31] tgardner: Is the problem that you don't want offer more flavours? So could I put an universe package (like -preempt2) and it would be OK for you? [17:31] Not since hardy, since -rt hasn't been able to match kernel versions well, and most folk don't really need -rt for their stuff. [17:32] amitk: Not all of it is mainline yet, although it's getting close. [17:32] amitk: For almost all multimedia users HZ=1000 and PREEMPT =ycould be suffice. [17:32] persia: i didn't mean all of it went in, but all that did go in :) [17:33] abogani, right. more flavours mean more build time and more maintenance. [17:33] a universe package is fine with me [17:34] * tgardner notes that ogasawara has been busy. [17:34] wasn't cnd_swap going to look into PREEMPT? Perhaps we should add HZ=1000 to his study list :) [17:34] abogani: If you do a universe package, please make it from the same source tree so that we don't get out of sync. I'd like to be able to use --preempt for the default installer, but would prefer to avoid i386/amd64 bug skew. [17:36] 'for the default installer' ??? persia ? [17:36] apw: For the Studio flavour, yes. A significant majority of Studio users need lower latency, as opposed to Desktop users. [17:37] * apw idly wonders what the heck they could need it for [17:37] Similar to how Server users have a different kernel flavour, do to different usage. [17:37] multiple audio generators being kept in sample-accurate sync, mostly. [17:38] persia: What is exactly the "i386/amd64 bug skew" which you would want avoid? [17:38] So if one is generating at e.g. 90kHz, one needs to run *each* tone generator and get the output each 10us. [17:38] well only if you don't think gneerating ahead is a good idea, but hey [17:38] * abogani sound odd to have an amd64 -preempt kernel in main and a similar kernel in universe.... [17:39] abogani: My worry is that if amd64 -preempt is build from one package, and i386 -preempt is build from a different package, we might end up with issues. [17:39] that does sound unhelpful [17:39] apw: You can't generate ahead if some of the tone generators depend on the others for input. Consider a filter and needing to adjust wet/dry mix. [17:39] ogasawara: why is ONDEMAND turned off in maverick? [17:40] amitk, its enabled, its just not the default [17:40] persia: Sorry I'm stupid: Why ever we should use two different source packages? [17:41] $ grep -r CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND debian.master/config/* [17:41] debian.master/config/config.common.ports:# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set [17:41] abogani, if you are uploading a separate paackage to universe its a separate source package [17:41] debian.master/config/config.common.ubuntu:# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set [17:41] tgardner: ^^ [17:41] amitk, thats the default [17:41] our default is not ondemand [17:41] CONFIG_CPU_FREQ_GOV_ONDEMAND=y [17:41] tgardner: aah, sorry, I'm blind [17:41] abogani: If there aren't two packages, ignore me :) [17:42] if someone put a new package in Universe it should rename it completely so now way to have an amd64 -preempt (in main) and a i386 (in universe). [17:43] To me it makes sense to only have *one* -preempt flavour. I don't think main/universe matters (and really, unless it ends up on some main-only flavour's images, the binaries will be in universe anyway) [17:44] Can we move all -preempt stuff in universe adding i386 in the same time? [17:44] abogani, the issue for us is just how long a build takes if we add loads of flavours [17:45] it already takes nearly 6 hours to build [17:45] abogani, you mean drop the preempt flavour in amd64 ? [17:45] I mean, move it from main into your universe kernel? [17:46] tgardner: Move it to (not mine) universe for provide both i386/amd64 binary packages. [17:46] ogasawara: I renamed the script to drop the ".sh" for consistency with the rest of the tools, and it's now in the maintscripts directory of the kteam-tools repo [17:47] sconklin: awesome, thanks [17:48] abogani, I'm fine with that. I don't think --prempt is main is getting much use anyways. [17:48]