19:02:11 #startmeeting 19:02:11 Meeting started Fri Jan 25 19:02:11 2013 UTC. The chair is jwb. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:02:11 Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:02:21 #meetingname fedora-kernel 19:02:21 The meeting name has been set to 'fedora-kernel' 19:02:28 #meetingtopic Fedora Kernel 19:02:32 #topic init 19:02:42 who's here 19:02:47 * brunowolff is here 19:02:50 * nirik is lurking around. 19:02:51 * jforbes 19:02:57 word 19:03:20 i thought we'd skip the normal release overview today. pretty boring and there are a couple other things we can talk about. anybody have objections? 19:03:40 nothing much has changed since last time, so why not (other than f16 getting closer to eol) 19:03:57 yeah, i'll do some administriva things in the minutes at the end 19:04:11 #topic Checkpoint/Restore 19:04:19 so this feature was submitted for F19: 19:04:22 https://fedoraproject.org/wiki/Features/Checkpoint_Restore 19:04:50 The 3.8 kernel is in pretty good shape for C/R from what I understand 19:05:09 but we'd need to turn on namespaces, and the c/r option 19:05:33 if we did that, we'd leave USER_NS disabled because it can't be enabled with things like XFS, NFS, etc 19:05:39 work is still on-going for that one 19:05:45 but afaik, USER_NS isn't required 19:06:03 so my thinking is we patch the kconfig so it doesn't depend on EXPERT (because that's a nightmare), and enable in rawhide 19:06:28 maybe ask adrianr if he has some decent tests we can add to the test git tree 19:06:42 that's a very good idea 19:06:48 thoughts, objections? 19:06:56 for the most part, I expect people to not even notice we've turned that option on 19:07:03 sounds good. It should get enabled as soon as we can to get more testing. ;) 19:07:09 nirik, yeah 19:07:12 unless you care about that feature, it should be fairly benign 19:07:19 davej, aside from it being in the release notes, yeah 19:07:36 right, but it shouldn't impact performance for eg for people who don't care 19:07:43 hopefully not, yeah 19:07:56 ok, i'll email adrianr about the tests stuff 19:07:57 I do like the idea of getting some test cases though. With new features and active development 19:08:48 #action jwb to discuss getting some testcases with adrianr 19:09:04 #info plan is to enable soon, without relying on CONFIG_EXPERT (small patch) 19:09:23 ok, anything else on this one? 19:09:46 guess not 19:09:48 #topic rawhide kernel debug options 19:10:02 jforbes, wanna briefly talk about how this is going, and what the next steps are? 19:10:07 Sure 19:10:32 * nirik hasn't had a chance to try the kernel today. 19:11:07 So today we enabled slub debug. That gives us lockdep, slub and spinlocks. I am surprised we got this far, and would be very surprised if we got further 19:11:13 nirik, i did. hard to tell, but it might be marginally slower at video playback. not bad enough i would say "omg, broken" though 19:11:20 I am testing it now and might be seeing a yum slowdown. I want to do some more testing tonight when I can reboot my home machines. 19:11:42 I cna test in a bit. 19:11:44 brunowolff, you changed to testing rawhide kernel + f18 userpsace, right? to avoid anything else in rawhide? 19:11:51 just too much stuff going on to get to the reboot yet today. ;) 19:12:07 That said, we might also see that it is a combination of things which slow it down drastically so who knows 19:12:22 On the machine I am testing on now. At home I have both rawhide and f18 machines running 3.8 kernels. 19:12:42 I really appreciate the feedback we have been getting on this. Even the "works fine for me" lets me know that people are testing so results will be meaningful 19:13:10 The reason why I wanted to try it on f18, is that something else was slowing down yum for me on rawhide. That seems to be fixed now, though I don't which update fixed things. 19:13:24 #info lockdep + spinlock seemed fine. today has slub debug and needs feedback 19:13:53 if slub debug seems slow, booting with slub_debug=- will disable it too. 19:14:47 what else after slub was there? 19:14:48 Right, so once we figure out "what" is slowing us down, we need to figure out "why" 19:15:19 nirik: lots of smaller options 19:15:22 nirik, lots of stuff, but mostly small 19:15:36 cool. 19:15:52 That said, could be a bigger impact than expected from a smaller piece 19:16:06 * nirik nods. 19:16:19 Not willing to rule anything out until it has been tested 19:16:46 PROVE_RCU isn't set yet 19:16:51 right 19:17:14 or atomic sleep, etc 19:18:29 anything else on this one? 19:18:38 not from me 19:18:41 nope 19:18:43 * nirik read that as atomic sheep. I need some more sleep. 19:18:49 #topic coprs 19:19:07 so at FUDCon, skvidal gave us access to the coprs stuff 19:19:10 My yum update here is still running and I think that slub will turn out to be what cause me grief. I'll need to try reproduceable yum changes so I can compare run times though. 19:19:30 i thought it would be worth trying it out to see if it made things easier for the rawhide nodebug kernel stuff 19:19:43 i think it has some potential, but right now it won't cut it 19:20:00 it might be useful for one off builds with a test fix for something. 19:20:02 or no? 19:20:05 seth fixed the build space issues i think, but we only get one worker (builder) per copr 19:20:13 so it's rather slow 19:20:28 slower than koji --scratch? 19:20:36 need to try again to be sure 19:20:39 but it might be 19:20:49 something i plan on poking on today 19:20:49 since my nodebug build from this morning is still going... 19:20:57 FYI, we rebuilt all the koji builders so there are fewer of them now, but with more mem/disk 19:21:19 ok. i'll give it a shot. i'll do the "two separate coprs" trick too, so i get two workers, one for i686 and one for x86_64 19:21:45 i do like the ideas behind it though, and it might prove useful in the long run 19:21:52 particularly for test kernels like nirik mentioned 19:22:12 worth poking at still. i'll come back with more info on it after i play with it more 19:22:25 I guess these builds won't work with secure-boot ? 19:22:25 #action jwb to try more copr builds for kernels this/next week 19:22:34 davej, right. neither will nodebug via --scratch 19:22:38 *nod* 19:22:39 davej: no, though neither do our current builds 19:22:44 yeah, only official ones. 19:23:05 davej, if people import the test cert, they can use them with SB 19:23:27 but that has impliciations. like "you better know what you're downloading" 19:23:35 which isn't much different than today without sb, but still 19:24:06 ok, that's all i had on coprs 19:24:11 #topic open floor 19:24:31 I had one item to mention... 19:24:35 shoot 19:24:47 my iwlwifi woes have gotten worse again. It works for a few hours then craps out 19:24:56 bug 863424 19:25:10 802.11n? 19:25:11 with the "iwlwifi 0000:03:00.0: fail to flush all tx fifo queues" in dmesg 19:25:16 yeah. 19:25:22 does it happen with g? 19:25:28 * jsmith notes that his battery life seems to be much better lately, for what little it's worth 19:25:30 there's a 1 line patch in there that helped in the past, I need to try it again on newer kernels 19:25:39 istr reading something about disabling power management improving wifi woes on iwlwifi recently 19:25:41 I've not tried disabling n. 19:25:43 I think there's a module param 19:26:02 davej: I Think I saw that in another bug report as well. 19:26:06 for some reason i have the idea that iwlwifi firmware is dodgy with n 19:26:13 I fear if I disable n and it works I will forget about it and live with crappy speed for a long time. ;) 19:26:21 heh, fair 19:26:35 but just wanted to mention it if others are hitting it. 19:26:44 nirik: try the power_save=0 param, and see if that helps any 19:26:55 oh wait, it's disabled by default. 19:26:57 thanks Intel. 19:26:57 davej: ok, will do 19:27:00 humf 19:28:13 anything else? 19:28:30 * nirik has nothing else. 19:28:46 ok. i'll do a quick administriva update then 19:28:50 #topic administriva 19:29:04 #info rawhide on 3.8-rc4.git5. continuing through 3.8-rcX 19:29:25 #info F18/F17 on 3.7.4. 3.7.5 coming soon, with possible intel fixes for hangs 19:29:51 #info F16 heading towards EOL. possibly one final update before EOL. Please upgrade to f17/f18 19:30:12 anyting else before i close it out? 19:30:43 no tings. 19:30:56 sounding all like Mel 19:31:05 nada 19:31:12 ok, closing it out. thanks for coming everyone 19:31:14 #endmeeting