fedora-meeting
LOGS

15:02:34 <pknirsch> #startmeeting Power management for Fedora
15:02:34 <zodbot> Meeting started Thu Sep  3 15:02:34 2009 UTC.  The chair is pknirsch. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:34 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:02:44 <pknirsch> Hello and welcome everyone.
15:03:07 <pknirsch> First of as usual a quick recap of last week
15:03:15 <pknirsch> #topic Last week recap
15:04:12 <pknirsch> - pknirsch was away, so skalnik1 stepped in to lead the meeting
15:04:22 <pknirsch> - Main topic was Fedora 12 test day
15:04:32 <pknirsch> - Initial discussion with QA
15:04:48 <pknirsch> - To be continued next week
15:05:09 <pknirsch> which brings us to todays (continued) topic:
15:05:18 <pknirsch> #topic Fedora 12 test day (continued)
15:05:46 <pknirsch> As skalnik1 and jscotka have been doing most of the work regarding that i'd like to hand it over to them to continue. :)
15:06:08 <skalnik1> thanks :-)
15:07:21 <skalnik1> well, dpravec prepared skeleton of test day site
15:07:30 <skalnik1> http://fedoraproject.org/w/index.php?title=Test_Day:2009-10-22
15:07:44 <skalnik1> we should fill it with necessary info
15:08:29 <skalnik1> i'd like to send an email to attendees of last test day when it will be more completed
15:08:54 <skalnik1> and also we have to propagate it on fedeora-devel list
15:09:24 <skalnik1> i suppose jscotka could inform us about test cases ?
15:11:33 <plautrba> jvcelak has tried some tests from f11 test day with actual fedora rawhide live cd but only first test passed
15:13:00 <plautrba> others ends with "Input Output Error"
15:13:42 <plautrba> so it seems that live cd isn't usable for this
15:15:22 <jvcelak> that's right. now I am trying to run the same tests on f11 live cd, first two tests passwd (personal, tuned) .. the third one (init 1) failed with the same error.
15:15:32 <jvcelak> *passed
15:16:40 <mgahagan> have you been able to dig into why the failures are happening? i.e. are we just missing needed bits on the live cd?
15:17:10 <jscotka> skalnik1: yes I can
15:17:45 <jscotka> four testcases are same as in testday for F11
15:17:54 <jscotka> and are added 2-3 new
15:19:03 <jscotka> 4 same testcases are mainly intend for people who was at previous pm testday
15:21:00 <jscotka> jvcelak: you try it from liveCD?
15:21:25 <jvcelak> jscotka: exactly
15:22:52 <jscotka> there is problem that the testcase have to read/write to disc, and also work from CD isnt usefull
15:23:38 <jvcelak> mgahagan: i am not really sure, what's the problem. a have rebooted the f11 live cd a minute ago, and now i get the same problem with running su (bash: /bin/su: Input/output error).
15:23:39 <jscotka> jvcelak: because working from CD have nontrivial powerconsuption itself
15:24:57 <plautrba> jscotka: that;s the point. show differencies in results from native and live system
15:25:44 <jscotka> plautrba: ah, you mean to do it as testcase?
15:26:22 <plautrba> jscotka: can be, but mainly show that it is not usable fot hese test cases
15:28:46 <jscotka> plautrba: Im not sure, I never tried it :-) but I think that liveCD have specific behaviour (special fs, COW to ram and many more, or not)
15:34:25 <jvcelak> I would like to add that running these tests from Live CD will be problematic even if we manage to solve this problems with I/O errors. Because it means booting a then downloading all necessary packages before each test. For example: bltk test requires openoffice.
15:35:17 <plautrba> jvcelak: if we use livecd we will have that prepared with all needed software
15:35:28 <jscotka> jvcelak: yep, thats big problem
15:36:03 <plautrba> if is it possible to add everything on one cd
15:36:25 <jscotka> jvcelak: last PM testday had these liveCD only for installation (because was problematic to install rawhide directly)
15:36:26 <jvcelak> i think the biggest problem will only with bltk test, the others need only few packages.
15:37:30 <jscotka> we havent it prepired for running from CD
15:38:08 <jscotka> jvcelak: liveCD was only last chance how to install rawhide to HDD :-)
15:38:21 <jvcelak> jscotka: :-)
15:38:23 <Southern_Gentlem> huh???
15:39:01 <Southern_Gentlem> install f11 and enable the rawhide (development repos) yum update
15:40:18 <jscotka> Southern_Gentlem: It is possible that now it is better, but when was F10 and then update to rawhide(F11) was manytimes the biggest quest of testday :-)
15:41:43 <jscotka> Southern_Gentlem: there was lots of bugs which causes malfunction of updating or direct installation of rawhide. But How I said, propably is now situation better, and liveCD isnt needed.
15:44:34 <skalnik1> the first intention of live-cd was to have everything inclusive test cases on the cd without necessity to have installed rawhide, isn't it?
15:46:56 <jscotka> skalnik1: not sure, for me it is only source of all needed packages together
15:47:13 <skalnik1> what about package preparation that will contain test cases and to provide it via test-day-repository. we would leave only the idea that the rawhide installation isn't mandatory ...
15:47:35 <jvcelak> so this means bypassing somehow these problems and customizing the current live cd to have everything included. :)
15:48:29 <jscotka> skalnik1: I think that run only from liveCD will be useful, but only for some of testcases.
15:48:55 <skalnik1> jvcelak, yes, it was the goal afaiu
15:51:16 <jscotka> I must say bye today :-)
15:51:31 <mgahagan> how much of an issue do you think having this testday after the F12 freeze with be with getting any identified fixes into the final F12 bits? Or do you guys think the currently state of (in)stability outweighs those concerns?
15:51:59 <mgahagan> that is we wouldn't get good results if we did it eariler.
15:52:31 <pknirsch> the features themselves should be ready to be tested
15:53:06 <pknirsch> but preparing better testcases would probably be still helpful, especially for the new things we did for F12.
15:55:17 <mgahagan> pknirsch, is there a pointer to where any possible new testcases are? (or ideas for new ones)
15:56:28 <pknirsch> mgahagan: we've listed those on the Fedora 12 feature page, but they are just descriptions, whereas we tried to have some ready to use scripts to test things before
15:56:45 <pknirsch> mgahagan: you can find them here: http://fedoraproject.org/wiki/Features/PowerManagementF12
15:56:51 <pknirsch> mgahagan: under the Test Plan section
15:57:24 <pknirsch> mgahagan: maybe those would already be sufficient as additional tests for a f12 test day?
15:57:35 <mgahagan> pknirsch, ok I will take a look at those... haven't had a chance to see all the new stuff there yet.
15:57:48 <pknirsch> mgahagan: perfect, thanks :)
15:59:16 <mgahagan> pknirsch, I was wondering how we could test/monitor disk spindown (without the test itself using the disk to prevent it from spinning up)... busybox's hdparm inside a ramdisk maybe?
16:00:07 <pknirsch> mgahagan: that would be a good idea, yes. is there actually a way to determine if a disk is spun down (ioctl or some such)?
16:01:30 <pknirsch> iirc the smartctl provided something like that actually, now that i think about it.
16:03:12 <mgahagan> pknirsch, I think it does, although it looks like start_stop_count is as close as you get... was hoping there was some way to coax its power state out of it.
16:04:18 <mgahagan> pknirsch, there is hdparm -C, which is supposed to tell you the current power state of the drive
16:05:12 <pknirsch> [root@hamburg lib]# hdparm -C /dev/sda
16:05:12 <pknirsch> /dev/sda:
16:05:12 <pknirsch> drive state is:  active/idle
16:05:24 <pknirsch> [root@hamburg lib]# hdparm -Y /dev/sda; hdparm -C /dev/sda
16:05:24 <pknirsch> /dev/sda:
16:05:24 <pknirsch> issuing sleep command
16:05:24 <pknirsch> /dev/sda:
16:05:24 <pknirsch> drive state is:  standby
16:05:26 <pknirsch> looks good!
16:06:48 <mgahagan> so if it works in busybox the same way we should be good (seems like that would be easier than building a staticly-linked hdparm binary)
16:07:43 <pknirsch> or in the worst case copy smartcl and hdparm to the ramdisk as well
16:07:47 <pknirsch> won't take that much space
16:08:25 <mgahagan> yeah, I was just hoping that it wouldn't require bringing in the rest of glibc :)
16:08:34 <pknirsch> hehe
16:08:44 <pknirsch> urgs
16:08:52 <pknirsch> smartctl even needs the libstdc++:
16:08:59 <pknirsch> [root@hamburg lib]# ldd /usr/sbin/smartctl
16:08:59 <pknirsch> linux-vdso.so.1 =>  (0x00007fffb6bff000)
16:08:59 <pknirsch> libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f6eb0450000)
16:08:59 <pknirsch> libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f6eb0146000)
16:08:59 <pknirsch> libm.so.6 => /lib64/libm.so.6 (0x00007f6eafec2000)
16:08:59 <pknirsch> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f6eafca8000)
16:09:01 <pknirsch> libc.so.6 => /lib64/libc.so.6 (0x00007f6eaf93a000)
16:09:03 <pknirsch> libdl.so.2 => /lib64/libdl.so.2 (0x00007f6eaf736000)
16:09:04 <mgahagan> that was why I considered the hdparm route (since it is in busybox)
16:09:05 <pknirsch> /lib64/ld-linux-x86-64.so.2 (0x00007f6eb066e000)
16:09:11 <pknirsch> yea
16:09:27 <pknirsch> that would be a good starting point to investigate if that works
16:10:04 <mgahagan> hdparm doesn't look that bad:
16:10:08 <mgahagan> [root@blackice ~]# ldd /sbin/hdparm
16:10:08 <mgahagan> linux-vdso.so.1 =>  (0x00007fff1193c000)
16:10:08 <mgahagan> libc.so.6 => /lib64/libc.so.6 (0x0000003321200000)
16:10:08 <mgahagan> /lib64/ld-linux-x86-64.so.2 (0x0000003320e00000)
16:10:13 <pknirsch> mhm
16:16:01 <pknirsch> ok, but i think unfortunately we're running out of time for this weeks meeting. We can continue the discussion and the work on the fedora wiki pages and via email and see where we stand in next weeks meeting i think.
16:16:56 <pknirsch> so thanks everyone for joining and participating, and see you again next week! (without me though, as i'll be on vacation ;).
16:17:02 <pknirsch> #endmeeting