[07:04] Hello! Are ubuntu kernels released every 2-3 months? Can I give a request of a change here? [08:07] When will there be support for Sandy bridge processors? [08:13] orated: Ubuntu has had basic support for sandy bridge processors since Ubuntu 10.10, and supported 3D acceleration since 11.04 [08:18] broder: Apart from graphic, are there any performance issues? Like system running in performance mode than normal mode [08:20] orated: That's not something I pay attention to, so I don't really know [08:21] broder: Well, that really drains life out of laptops with it.. [08:23] The processor fan running at performance mode even when idle [08:51] No. There's the PCIE PM power thingy, but that's not related to the cpu. [08:51] orated: Sandy Bridge processors are well supported in 11.10 (and slightly less well supported in 11.04) [08:54] RAOF, Hm, actually makes me wonder (since I got no hw to look at): is the graphics card you see on those somehow presented as being connected via pcie? [08:55] It does show up in lspci. [08:57] Its hard to say for sure but that still may leave a little opportunity of someone twiddling pcie pm and having some magic impact back on the cpu doing gpu'y things. (totally unrelated to any knowledge here, just thinking)... [08:57] cking, Hey how are you feeling today? [09:07] RAOF: I didn't get the reason for that. What is PCIE PM? [09:09] PCI Express power management; there's ambiguity between what the spec says and what Windows does. [09:09] RAOF, isn't there also some rc6 related power drain on sb ? [09:10] Yeah, there's that too. [09:10] Well, I n Windows it works absolutely fine. In Ubuntu it starts the fan in performance fan [09:10] That could just be your BIOS being stupid. [09:11] er [09:11] Which we *should* obviously deal with, but might not. [09:11] RAOF, is that the 'performance MSR' thing? [09:11] sb is a bit of a mess, and thats an upstream issue in the main [09:12] apw: EAMBIGOUSTHAT [09:12] and its going to take a while to perculate out into release [09:12] RAOF: I have the BIOS updated [09:12] RAOF, stupid BIOS> wondering if thats the 'CPU in performance by default' thingy thats controlled by a CPU msr or something more general [09:13] Oh, no. I was thinking "fan speed need not have any relationship to CPU performance mode" [09:14] ahh, more possibilities. i hate bios vendoes [09:14] RAOF: But isn't that proportional? [09:14] orated: Not necessarily; the fan control isn't wired up directly to a thermal sensor or anything like that. At least, not all the time :) [09:15] In other words: CPU state and fan state can be totally independent. [09:16] I'm not aware of the different states but I think the CPU fan rpm will increase/decrease as per CPU/GPU load [09:16] as far as I'm aware [09:16] No, that's by no means guaranteed. [09:17] Same with gpus, which is why the nouveau guys are paranoid about enabling fan control. It *is* entirely possible to turn off the fan and have the GPU cook itself. [09:18] So my system to run cpu fan in performance mode can be only due to power management? [09:18] What should happen is that the kernel should see that ACPI thermal zone $X has hit $TRIP_POINT and turn the fan on to $POWER_LEVEL. At least on most hardware. [09:19] orated: You CPU fan may be running at 100% simply because the BIOS starts it up at 100% and doesn't hand control off to the kernel correctly. [09:19] On what does it depend to hand over control to kernel? [09:20] It needs to say that the fan should be controlled by the OS. [09:20] * RAOF → dinner. [09:21] Well, I'm not that aware of proper technicalities but I only presented my observation here of system performance in Windows and Ubuntu. But if its BIOS issue, how can I fix it? Its updated ... [09:22] ah-ok. Catch up with you later then ... [09:40] The thing thats really missing atm is Optimus support. That drains the battery :) [09:40] that one will be a while coming [09:41] are things getting in kernel for that ? [09:42] apw: yeah, but we *should* be able to stopgap that some by being sure to power down the unused chip, at least in theory [09:49] broder, in some cases for some hardware with a machine specific quirk in every case [09:50] broder, its not going to be pretty until the proper support comes and no mistake [10:10] as it is, the fans are normally controlled by System Management Mode, so it's normally totally out of our control and up to the firmware to get it right. [10:12] cking, btw just found a funny state of brokenness: while everything else seemed ok, the discharge rate was reported as 0. Wonder whether its worth bailing out of powerstat and tell users to try to connect and disconnect ac (that was how I "fixed" it). [10:14] smb, yep, I can add that logic to cater for broken machines like yours ;-) [10:15] did you tinker with the other powerstat options? I'm interested to see if it looks useful or if we need to add more goodness to it [10:17] cking, I am pretty sure there are many more. :) Not yet, just had a quick run. Oh and it will actually run without complaining but with 0W power consumption on a desktop without any battery at all. ;) [10:18] gah, I didn't think of that, I'll fix that too :-) [10:20] cking, I feel a bit like the devil's advocate here, though. :) [10:20] smb, I appreciate you checking for things that I overlooked [10:22] cking, It is quite cool and I am sure apw will love it [10:22] * smb already does [10:22] did you try the funky -r and -s options? [10:23] cking, will look at those next. they sound pretty interesting [10:23] netlink was fun to figure out, but there was plenty of good documentation lying around [10:24] i sent an email to kernel-team@, but seems it didn't get through [10:24] tjaalton, Are you normally subscribed? [10:24] tjaalton, may be in the moderation queue, we get a _lot_ of spam [10:25] i'm subscribed yes, checking which address i have there [10:26] cking, Another completely unimportant note: -r is missing in the usage summary... [10:26] tjaalton, it was in the mod queue, i've poked it [10:26] smb: Can I ask which command you are using? [10:27] smb, err, try updating [10:27] ./powerstat -h [10:27] usage: ./powerstat [-s] [-h] [-d N] [delay [count]] [10:27] -s show process fork/exec/exit activity log [10:27] -d specify delay before stating, default is 15 seconds [10:27] -r redo a sample if we see process fork/exec/exit activity [10:27] -h show help [10:27] delay: delay between each sample, default is 10 seconds [10:27] count: number of samples to take, default is 10 [10:27] oh, yeah, I see now. [10:27] apw: thanks [10:27] orated, Something cking is currently whipping together [10:27] got it [10:28] orated, technically know as "work in progress" [10:30] smb, suppose I should write a man page too [10:30] ok, I had the wrong email address on the list, changed it now [10:31] cking, When things settle down, I guess that is a good idea, and in the end probably have it in a ppa [10:32] cking, Just an idea, you think it would be useful to have -r also redo the sample if idle is below a threshold (like 99)? [10:33] smb, yes, but how about making that another option, like -i, so we have more fine tuning? [10:34] cking: Regarding the fan rpm related to firmware you said above, I checked with dmidecode and the BIOS is updated and current A06 ... [10:34] cking, sounds good. probably could become -rf and -ri [10:35] smb, good suggestion, will do [10:37] cking, maybe not that simple with getopt (without making those --)... [10:38] smb, it's OK, getopt long is easy to use [11:19] * ppisati -> post office [12:46] herton, Quick question: is there currently a lucid-ec2 tracking bug open that I missed? Seeing the other uploads... [12:47] smb: yes, let me find the bug here [12:47] smb: bug 888700 [12:47] Launchpad bug 888700 in linux-ec2 "linux-ec2: -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/888700 [12:48] herton, Thanks, that one I totally missed somehow... [12:48] * ppisati wonders how much does it take to setup a local ubuntu repository... [12:49] space-wise i mean [12:51] ppisati, A lot probably does not help, but the sync would also take long. That is why I went for apt-cacher-ng [12:52] do you really need a full archive copy ? [12:52] i woudl go with something like approx instead [13:00] i was just wondering since this morning i read an article about "how to setup your own builder" or stuff like that, and one of the prerequisites was a local repostiory [13:02] well, approx, apt-cacher and friends work in a way that they pull from the archive *if* there is a newer package, else they use the local version [13:02] that has the advantage that you only use the diskpace for packages you actually need and that it only pulls updates if there actually are updates [13:02] Probably more of a recommendation to avoid you pulling packages over and over for each build. But as ogra_ said, you can use the proxy cachers as servers [13:03] indeed its slower than having a full local mirror ... on the first run [13:03] yep [13:03] but i still need a new 2tb disk, and latest flooding didn't help... :) [13:03] subsequent builds of the same package are fast though [13:03] oh, you only want to justify buying a new disk [13:03] go for a full mirror them :P [13:04] *then [13:04] asd :) [13:04] do you think 2tb is big enough? [13:04] don't think so [13:04] one arch one release ? [13:04] pretty much [13:04] shoudl be ok ... i guess [13:04] but better ask someone who actually has a full mirror at home [13:05] GrueMaster has one for example [13:05] ppisati, Oh you really want to buy three to have it raid5'd :-P [13:05] infinity too [13:05] ah [13:05] smb, 3 ? you need 5 for a 5.1 :P [13:05] smb: better to raid 0 then [13:05] i mean [13:05] raid 1, mirror [13:05] ppisati, yep [13:06] ppisati, But I thought you wanted more arguments for yourself to buy many disks... :) [13:06] ah :) [13:08] Cause in reality with caching (I use it a lot and currently got 4G used) you do not really need a new one and any raid is not really needed because you can always start over from the archive [13:09] smb: thgat [13:09] smb: that's true [13:10] but with a big enough disk i can offload not only the archives, but even the OS and all the rest [13:10] one raid to rule them all [14:45] hi herton, any ETA on a regression fix for lucid? (LP #875300) [14:45] Launchpad bug 875300 in linux "[Realtek ALC268] ALSA test tone not correctly played back (regression in lucid from 2.6.32-33.72)" [Medium,Triaged] https://launchpad.net/bugs/875300 [14:47] mdeslaur: I can revert the patch causing it, the problem is reverting should bring the previous regression the "fix" is handling. I plan to see if I find a solution until the end of the week. [14:48] herton: but, have you actually seen the regression? AFAIK lucid sound on mini 9's has always worked... [14:51] mdeslaur: it's just a problem with quirks, machines with same id but codec differences, so one quirk was applied to one model, but the same id make the quirk brake other models. Newer kernels have a better hda auto-config, and I suppose will handle this better. It's not so bad, you still can use model=dell (options snd-hda-intel model=dell), to avoid the breakage for now [14:53] herton: oh, hrm...I wonder if breaking people to fix others who's sound never worked in the first place is an acceptable trade-off [14:54] mdeslaur: yeah, may be we'll just revert the fix, I'm going to take a look at it if there is some we can do on lucid to have both cases fixed, if not revert it [14:54] herton: cool, thanks :P [14:55] herton: if you need any testing, let me know [14:55] ok, once I have something I'll let you know [15:03] * herton -> lunch === ericm|ubuntu is now known as ericm-Zzz [15:29] * ogasawara back in 20 [15:53] ppisati: My mirror is currently at 325G, but it is only arch armel/armhf/all binaries. I do not currently mirror source. Initial mirror setup and pull can take a weekend, depending on your bandwidth and the bottlenecks between you and the original source (I would assume ports). [15:55] My mirror is a 1U rack system w/ 4-1T sata drives in a soft raid (apparently, most SATA raid controllers are software raid, with software raid drivers for Windows - hence the raid marketing). [16:09] * ogra_ guesses armhf doesnt actually take much space yet :P [16:16] ogasawara: good day [16:17] mpoirier: hi [16:17] ogasawara: I have a brain bug this morning [16:17] ogasawara: ages ago you have me a make command to upgrade a target config . [16:17] something like make updateconfig [16:17] but I can't remember... [16:18] mpoirier: fdr updateconfigs [16:18] ha ! [16:18] fantastic thanks. [16:18] fdr == fakeroot debian/rules [16:18] yep. [16:35] cking, didn't you have something to execute an AML method and get the result from the command line? [16:52] mpoirier: any chance you give me an update on that patch i asked you? [16:52] sforshee, yep, lemme find it for you [16:53] GrueMaster: just 325GB??? [16:53] GrueMaster: entire armel repository? [16:53] ppisati: Armel, armhf (which I expect to almost double the sixe), and arch-all. [16:54] ppisati: you asked me for a patch ? [16:54] mpoirier: i think i did... wait a sec... [16:54] GrueMaster: i expected to take much more space... uhmm... [16:54] sforshee, git://kernel.ubuntu.com/cking/systemtap-scripts.git [16:55] ppisati: As I said earlier, no source (yet). [16:55] mpoirier: subject "Patch review/comment (from O to P)" [16:55] cking, thanks [16:55] sforshee, in acpi-eval, you can hack that script [16:55] mpoirier: i think the patch is not needed anymore, but i wanted you to give it a look [16:55] ppisati: that was in an email ? [16:55] mpoirier: yep [16:56] sforshee, you may like to also use the amltrace script too, perhaps a combo of both === hcfd__ is now known as hcfd