| morrison | hola alguien de aki habla español? | 01:04 |
|---|---|---|
| === fta_ is now known as fta | ||
| === calc__ is now known as calc | ||
| laga | amitk: i'm working on the aufs patch now. | 08:46 |
| laga | wgrant: why do you need AUFS_HINOTIFY? it's documented as having a negative impact on performance | 09:37 |
| wgrant | laga: Do we know how negative? The setup that we use it in (on top of a potentially rw NFS branch) can get a bit angry otherwise. | 09:41 |
| wgrant | We can always keep compiling a custom one, of course. | 09:41 |
| wgrant | But it'd be better not to have to. I guess it depends on the size of the performance hit. | 09:41 |
| laga | sure. how can we benchmark that? bonnie++? | 09:43 |
| wgrant | Perhaps, but I'm not sure. | 09:43 |
| laga | i guess one could also look at the code | 09:44 |
| laga | maybe it'll only have a negative impact if you mount with udba=inotify | 09:45 |
| wgrant | The only difference it would make is some extra potential jumps. | 09:45 |
| wgrant | Right, that's the only significant impact AFAICT. | 09:46 |
| wgrant | But IIRC people complained last time that the extra potential jumps would hurt performance. | 09:46 |
| laga | maybe we can slip it in ;) | 09:46 |
| laga | or i could ask the aufs guy | 09:47 |
| wgrant | I can't see how it would be anything other than very, very minor. | 09:47 |
| wgrant | Comparison against the udba setting can't be particularly expensive. | 09:47 |
| laga | i'll look into it. right now i need to get it to compile | 09:47 |
| wgrant | Pfft. We don't need built kernels. | 09:48 |
| laga | heh | 09:48 |
| bugabundo_work | hi | 10:14 |
| bugabundo_work | can someone let me know the correct name for the KernelRemoval function introdused on Intrepid? | 10:15 |
| bugabundo_work | never mind... found it | 10:28 |
| bugabundo_work | last good kernel | 10:28 |
| bugabundo_work | https://wiki.ubuntu.com/KernelTeam/removing-old-kernels | 10:28 |
| amitk | laga: thanks | 11:27 |
| xivulon | cking hi | 11:46 |
| xivulon | I left a message on 204133 some time ago', I would like to enable syncio but last time I tried, the performance hit was quite obivous | 11:47 |
| cking | xivulon: OK - let me investigate this on my Alpha 6 installation to see what can be done | 11:53 |
| cking | xivulon: is sync IO required while copying this ISO? | 11:56 |
| xivulon | cking no is not required, I just copied over an ISO as a test of write performance | 11:57 |
| xivulon | although I was thinking of mounting ntfs with syncio also during installation, so it will be used when files are copied from squashfs | 11:58 |
| xivulon | cking would you say we should use dm-loop instead of loop? | 12:24 |
| xivulon | cking, davmor2 just did some testing and he confirms that syncio is ~10x slower | 12:50 |
| === TheMuso_ is now known as TheMuso | ||
| DBO | for whom it may concern: Intrepid has given me no end of trouble with suspend on a new thinkpad T500 (intel through and through) | 14:25 |
| DBO | I finally hooked up the linux-rt kernel, which is still at 2.6.26 I believe, and after adding my usb modules to the suspend modules list, everything works great | 14:25 |
| DBO | I don't want to throw out nasty words like regression, but I have updated my bug report on the issue to reflect this, and maybe someone here will find it interesting too | 14:26 |
| DBO | the bug report is #272307 | 14:26 |
| tjaalton | perhaps a dupe of bug 269884 | 14:27 |
| DBO | tjaalton, yeah, I was told to report a new bug at one point, so I did | 14:29 |
| DBO | tjaalton, is there going to be action on 269884 | 14:29 |
| tjaalton | DBO: probably. you could try -4 in the meantime | 14:30 |
| DBO | is it available? | 14:30 |
| tjaalton | at least it's uploaded | 14:30 |
| tjaalton | I haven't tried yet | 14:31 |
| DBO | updating my package list now | 14:31 |
| tjaalton | yep, it is | 14:31 |
| DBO | mine says its not, I'll switch to the main repo | 14:31 |
| rtg | tjaalton: -4 isn't quite baked yet. | 14:31 |
| tjaalton | rtg: oh, ok | 14:32 |
| rtg | tjaalton: still gotta get meta uploaded after LRM is NEW'd | 14:32 |
| tjaalton | yeah, but you can try it out without LRM | 14:32 |
| DBO | i dont need lrm | 14:32 |
| tjaalton | me neither :) | 14:32 |
| DBO | happy to finally have a laptop that doesn't need it | 14:33 |
| DBO | is -4 still based on rc4? | 14:33 |
| rtg | -rc7 | 14:33 |
| tjaalton | um no? | 14:33 |
| DBO | sweet, rc7 changelog had a couple patches that looked relevant to suspend issues | 14:34 |
| rtg | mjg59 has declared that suspend is no longer an interesting problem. While he's right about the larger picture, I think there are still a couple of minor issues to deal with, such as UHCI and EHCI. | 14:37 |
| tjaalton | my sierra sometimes fails to reinitialize correctly after a resume, but apparently that's a hw bug since I've heard the same happens on vista | 14:38 |
| tjaalton | reloading the module helps | 14:39 |
| tjaalton | but that's a userspace problem.. | 14:39 |
| rtg | nvidia appears to be the most intractable resume issue. dunno if we'll ever fix that one. | 14:40 |
| tjaalton | probably not | 14:40 |
| wgrant | What makes suspend so sloooow? | 14:41 |
| DBO | no worky | 14:42 |
| smb_tp | CarlFK, kernel 2.6.27-4 might also be interesting in your case. I saw one patch that deals with clockevents that looks promising. | 14:45 |
| rtg | xen-master zul: can you look at bug #238549 ? | 15:09 |
| elmo | oh, we se that! | 15:09 |
| elmo | FWIW, changing to an amd64 kernel fixes it | 15:10 |
| zul | rtg: sure | 15:14 |
| rtg | elmo: changing dom0 to amd64 works around it? | 15:16 |
| laga | oh, neat. aufs built. | 15:36 |
| laga | and i only needed half of the patches.. should that scare me? | 15:37 |
| elmo | rtg: yep, that's what we ended up doing | 15:43 |
| elmo | rtg: the machines have been running flawlessly since then | 15:43 |
| rtg | elmo: thanks. that'll help isolate the problem. | 15:44 |
| CarlFK | smb_tp: Ill check it out | 15:50 |
| munckfish | rtg: got a sec re linux-ports? | 16:24 |
| rtg | yo | 16:24 |
| rtg | munckfish: ^^ | 16:25 |
| munckfish | rtg: hi thx for looking at my pull-request. However I need your advice - I've since noticed that an intermittent hang on shutdown has not been cured :( | 16:26 |
| munckfish | From the PS3 perspective this is still a good enough kernel build to allow us to begin testing install/upgrade | 16:26 |
| munckfish | but I've no way to test on the other architectures | 16:26 |
| munckfish | I'm investigating the problem this week. But I've no idea how long it'll take me to find the problem or whether there's a patch I can cherry pick | 16:27 |
| rtg | munckfish: well, its likwely that shutdown issues are arch specific. | 16:27 |
| munckfish | What would you advise in this situ? | 16:27 |
| munckfish | well, I'm hoping it's PS3 specific | 16:27 |
| rtg | munckfish: Ben is the real expert since he did the initial port. Perhaps you should try and catch him? | 16:28 |
| munckfish | I get a stack trace when I hit Atl+SysRq+O | 16:28 |
| munckfish | And at the top of the list is a call to shutdown the PS3 Logical Perf Monitor | 16:28 |
| munckfish | rtg: I could do that but I was planning on asking the upstream folks first before bothering him | 16:29 |
| rtg | munckfish: ask both. | 16:30 |
| munckfish | ok | 16:30 |
| munckfish | rtg: could you explain what the procedure would be from here? I'm a complete kernelteam newb. After you'd pulled into the main intrepid-ports tree | 16:31 |
| munckfish | would you immediately do an upload? Or would you look to have the other architectures tested before hand? | 16:31 |
| rtg | munckfish: clone ubuntu-intrepid-ports, then perform the pull into the repo from yours, then fix the conflicts. | 16:32 |
| munckfish | rtg: ok. I answered you mail. What step was I missing? | 16:33 |
| munckfish | That would have prevented these conflict? | 16:33 |
| kirkland | what's the magic kernel boot param to disable acpi? noacpi? acpi=off? | 16:40 |
| rtg | kirkland: acpi=off IIRC | 16:43 |
| kirkland | rtg: thanks! | 16:43 |
| rtg | kirkland: I'm checking just to be sure. | 16:43 |
| rtg | kirkland: yep, thats it. | 16:44 |
| kirkland | rtg: excellent, trying that | 16:45 |
| munckfish | rtg: are you using "git pull -f" to pull into the ports tree? | 16:47 |
| rtg | munckfish: nope. I'll respond to your email in a bit. you are over complicating things. | 16:47 |
| munckfish | oh ok | 16:48 |
| munckfish | thx | 16:48 |
| munckfish | BenC: I've discovered there is still an intermittent shutdown hang on the PS3 ports kernel. I'm going to contact upstream this week to see if anyone knows about it | 16:59 |
| BenC | munckfish: ok | 17:00 |
| munckfish | but r t g suggested I speak to you about it - my feeling is even with what we have now | 17:00 |
| munckfish | it's better than what's in the repo currently | 17:00 |
| munckfish | and would allow us to begin testing install/upgrade | 17:00 |
| munckfish | also I think (big think) that the problem may only affect PS3 | 17:00 |
| munckfish | but I can't be sure | 17:01 |
| munckfish | how would you suggest we proceed? wait, or go ahead and upload again once fixed? | 17:01 |
| munckfish | BenC: over | 17:01 |
| BenC | munckfish: waiting is bad right now | 17:02 |
| munckfish | yep | 17:03 |
| munckfish | so you'd be happy to go ahead | 17:03 |
| munckfish | Ok well r t g is helping me get my tree sorted so the pull works | 17:03 |
| munckfish | ogasawara: re LP #249555 | 17:18 |
| munckfish | that'll affect our 2.6.25 based ports kernel not the main 2.6.27 one | 17:18 |
| munckfish | ogasawara: ok sorry I'm wrong he's trying to use these on x86 | 17:20 |
| munckfish | rtg: seems I misunderstood the dev process, I thought while in development phases you guys continually rebased against kernel.org upstream | 18:11 |
| munckfish | And I thought, as a member of the community, by doing this I was helping out :( | 18:11 |
| munckfish | rtg: what motivates as rebase then? | 18:12 |
| munckfish | Sorry, got to leave now. Bye. | 18:16 |
| CarlFK | smb_tp: is the .4 kernel in a ubuntu repo, or do I have to built it from k.org source? | 19:00 |
| smb_tp | CarlFK, Let me verify this quickly but I think it is in the repo but the meta package is not updated yet. | 19:01 |
| CarlFK | smb_tp: must have just hit: The following NEW packages will be installed: linux-headers-2.6.27-4 | 19:04 |
| smb_tp | CarlFK, Yep, as I thought. You don't have to build | 19:04 |
| smb_tp | CarlFK, Ah, ok then | 19:04 |
| CarlFK | smb_tp: do you think this is an AMD thing or an HP thing? if HP, I have a friend at HP that might be able to do something | 19:05 |
| smb_tp | CarlFK, I suspect rather an AMD issue. Something together with C1E | 19:06 |
| CarlFK | that was my guess | 19:06 |
| CarlFK | smb_tp: .4 - same thing. and now no X (no nvidia, and nv doesn't support my card) | 19:55 |
| CarlFK | vesa should work.. hmm.. | 19:56 |
| CarlFK | vesa works. good enough. | 20:01 |
| smb_tp | CarlFK, Hm, ok. The pauses yet seem to hide. The description and change looked promising... :( | 20:02 |
| CarlFK | did you see my note it waking up after 170 seconds? | 20:03 |
| smb_tp | CarlFK, I am not sure. Last week was a bit busy. But in one of the earlier reports softlockup did get triggered after some long(er) time | 20:04 |
| CarlFK | boot, pauses at 3.1, i don't touch it, and get [ 174.059763] Clocksource tsc unstable (delta = 4398045961326 ns) | 20:04 |
| CarlFK | wondering if that would help you hook up some debugging code | 20:05 |
| smb_tp | CarlFK, hm, right. Might be an idea to print out the timers from the watchdog... Ok, just lets try that. I patch a kernel together and ping you if I am done | 20:08 |
| CarlFK | smb_tp: i'm hear all day | 20:10 |
| CarlFK | here too :) | 20:10 |
| smb_tp | CarlFK, great. :) | 20:10 |
| laga | amitk: weeee. aufs works! | 20:45 |
| amitk | laga: great! Now what would make it super is if you could figure out how to add it to the kernel for easy updates later. Currently it isn't that easy to update to a newer release. | 20:47 |
| laga | update aufs itself? | 20:47 |
| laga | well.. with the current approach of constantly rebasing, thus loosing individual commits, it's a bit hard. | 20:48 |
| amitk | laga: yes, in the kernel. | 20:48 |
| laga | but it should be as simple as copying the aufs source to ubuntu/aufs/ and fix compilation. | 20:49 |
| laga | which is not that hard to do usually. | 20:49 |
| amitk | laga: losing commits? | 20:49 |
| laga | amitk: individual commits getting merged into one. | 20:50 |
| laga | http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=commit;h=c5e9b298cdcaabfdf8e74c16e7bfd3802ca33f74 | 20:50 |
| laga | "includes patches to work with apparmor changes" is not helpful at all. i seem to remember there being individual commits for that | 20:51 |
| laga | a few weeks ago, when i made my first aufs patch, searching for aufs showed a lot more results than just one, which made it easy to cherry-pick individual fixes | 20:52 |
| amitk | laga: agreed. that should have been split into aufs and vfs changes | 20:52 |
| laga | yeah. and that aufs tree is completely butchered. ;) | 20:53 |
| amitk | laga: here is your chance to fix it :) | 20:53 |
| laga | yay :) | 20:53 |
| laga | how do i update the kernel config? i think i'm supposed to use splitconfig.pl | 21:24 |
| jcastro | I don't know if this affects ubuntu kernels but I wanted to throw it up here just in case: https://bugzilla.novell.com/show_bug.cgi?id=425480 | 21:40 |
| rtg | jcastro: Intel is aware of the problem and is working towards a fix. dunno what progress they've made lately. | 21:51 |
| jcastro | rtg: cool, I was seeing if someone on the kernel team was aware - though I suspect you guys knew about this before me. :D | 21:53 |
| rtg | jcastro: just ask Chris (Ng) about it. He had to send his motherboard in to have the part replaced. | 21:53 |
| jcastro | oh no! | 21:54 |
| amitk | laga: debian/rules updateconfigs is your friend | 21:56 |
| laga | amitk: oh, thanks. i used vim this time ;) | 21:56 |
| Ng | jcastro: fwiw we're tracking it as bug 263555. I'll add the novell bug now, thanks for mentioning it | 21:56 |
| Ng | and I added the kernel bugzilla entry, which I should have linked up before | 21:58 |
| Ng | jcastro: I dunno if we have a general policy on such things, but maybe give the novell guys the LP url, since we have a comment from an Intel guy saying they've reproduced it and are investigating | 21:59 |
| Ng | (and fwiw, the commit they mention in comment #7 only applies to e1000, the e1000e stuff is different) | 21:59 |
| jcastro | Ng: I can do that, there's no policy but it seems the right thing to do | 22:00 |
| jcastro | Ng: so ... shouldn't we be telling people with intel nic's that this bug is pretty dangerous? | 22:30 |
| smb_tp | CarlFK, Just wanted to let you know that kernel compile takes really long today. And I have to leave for a few hours. So maybe you probably should not actively wait for it... :-/ | 22:41 |
| laga | kernel compiles always take ages for me, even with distcc :/ | 22:41 |
| laga | err, ccache | 22:42 |
| Ng | jcastro: I kind of think so, but I don't want another "zomg ubanto kills hard disks!!!11" debacle ;) | 22:42 |
| Ng | jcastro: I certainly think it would be good if we could poke intel for some information. this bug shouldn't be possible on e1000e, I'm told | 22:44 |
| jcastro | Ng: well, suse's already put out a "don't use our betas at all" message. | 22:45 |
| jcastro | dunno, I would be livid if this broke my brand new X300. :p | 22:46 |
| Ng | jcastro: I'm not livid, I chose to run a pre-release kernel from a pre-release distro and it was Intel's own driver that destroyed the part. Lenovo repaired it (although to be fair I didn't say "linux killed my laptop") and it's on all the right radars now | 22:47 |
| Ng | it's certainly frustrating though, and from my perspective it would be a release blocker to the point of removing the driver until it's fixed | 22:48 |
| Ng | but I'm no kernel hacker, it may be that the problem is elsewhere | 22:48 |
| jcastro | I just think "and oh by the way, those of you using intel NICs in intrepid should shut it off in the bios" or something. | 22:50 |
| Ng | I pretty much agree, but it's not my call :) | 22:51 |
| CarlFK | smb_tp: im at home - no plans on leaving today :)( | 22:54 |
| laga | amitk: patch sent to the mailing list | 23:36 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!