/srv/irclogs.ubuntu.com/2008/08/19/#ubuntu-kernel.txt

=== asac_ is now known as asac
=== emma_ is now known as emma
VampyreDragonGood Evening01:21
amitkmorning pgraner 08:56
pgraneramitk: good morning. I see you made it back ok09:02
amitkpgraner: yeah... wasn't too bad on the way back09:07
pgraneramitk: cool. 09:09
=== BenC changed the topic of #ubuntu-kernel to: Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.26-5.14 (based on 2.6.26 final) | Latest news: Please test last-good-boot, now in intrepid (grub/module-init-tools) | Next meeting: Aug 19, 16:00 UTC | Kernel Team machine: http://kernel.ubuntu.com
nirjoin #ubuntu-helpteam16:29
nirhi16:29
BenCamitk, smb_tp, cking, rtg: ping a ling17:02
smb_tpBenC, There I am17:02
ckingBenC, me too17:02
rtgBenC: dude17:02
* zul lurks17:02
BenCsweet17:02
amitkBenC: ping17:02
cr3hey dudes, I'll be joining today17:02
BenCogasawara, slangasek: alive?17:02
slangasekhi17:03
* ogasawara waves17:03
smb_tpcr3, hey dude :)17:03
BenCThe gangs all here17:03
zulhi cr317:03
BenCCall the meeting to order then17:03
BenCPrimary agenda for today, which we will dive right into, is whether we should start the move to 2.6.27 for intrepid17:03
cr3smb_tp: yo mama!17:03
BenCIf we do it, it has to start now17:04
zulBenC: that would be nice 17:04
BenCLuckily, I've been maintaining a synced 2.6.27 tree that is pretty much a drop in replacement for 2.6.2617:04
BenCso the "doing it" part is pretty much "done"17:04
smb_tpAs you said the volume of new stuff went down, so the main window might be over17:04
BenCOther than the upload17:05
ckingI think the benefits (additional drivers, etc) outweigh the risks.17:05
BenCThe drawbacks we face, and have to decide whether it is worth the effort are:17:05
BenC1) 2.6.27 timeline may leave us with a pre-released kernel at intrepid release time17:05
BenC2) The possibility that the kernel will be less stable due to it being so fresh (even if it is final 2.6.27 at intrepid release)17:06
amitkBenC: bugs(2.6.26 + backport of alsa+wireless) > bugs(2.6.27-rcX)17:06
BenCAs cking and amitk have pointed out, we are already considering moving to a newer wireless and alsa stack in 2.6.26, which we would get for free moving to 2.6.2717:07
rtgamitk: I'm beginning to become convinced that backporting the wireless pile is not feasible.17:07
BenCOne of the main reasons for alsa and wireless is newer device support that isn't easy to backport in bits17:08
slangasekand if the timeline leaves us with a pre-release at intrepid release, is the intent that it be updated to 2.6.27 release in SRU?17:08
BenCslangasek: yes17:08
BenCslangasek: if we are left with -rc at release, the amount of delta to final wont be much17:08
BenCslangasek: so we should be able to evaluate every commit that will be there17:09
rtgslangasek: I also think we (the kernel team) should follow the stable tree updates until upstream stops maintaining it.17:09
slangasekthat's not an answer I like very much, just because SRUs take time away from working on the next dev release17:09
BenCslangasek: hardy SRU's are already taking up time, and we didn't do this for hardy17:10
slangasekfor an LTS it's understandable that there are going to be SRUs17:10
slangasekfor intrepid, which isn't an SRU, I think that's spreading ourselves rather thin17:10
BenCslangasek: I don't think it will incur a long period of overhead...just a one shot deal17:10
slangaseker, isn't an LTS17:10
BenCslangasek: and because we are on a continuous move, we'll be able to get started on intrepid+1 kernel pretty quickly17:11
slangasekno SRU is a "one-shot deal" for the SRU team :)17:11
BenCslangasek: IOW, we wont have the huge burden of forward porting all of our patches across two versions of the kernel before starting...we'll have a kernel ready on day zero of intrepid+1 opening17:11
BenCour work on intrepid+1 wont really start until after UDS, so we have that time frame17:12
BenCslangasek: we usually have a month or so of SRU's for the kernel, even on non-LTS...do you think this one would incur more overhead than usual?17:13
BenC(and note, most of those SRU's are lum/lbm work for supporting newer drivers, which will be moot because of the move to 2.6.27)17:13
slangasekwell, my work on intrepid+1 has to start significantly earlier than UDS in order to get the archive opened, so having to spend additional time on SRUs would be resource contention :)17:14
BenCslangasek: plus we have to consider how much work it will be for us if we stick to 2.6.2617:14
slangasekright, that's fair17:14
smb_tpIt also depends on the policy. If it is agreed to follow the stable kernel updates it is less overhad to process...17:14
amitkit would also help to move kerneloops package to default install if we decide to go with 2.6.27 to help upstream bug identification17:14
BenCamitk: sounds like a volunteer has stepped in to do that ;)17:14
slangasekOTOH, it also seems to imply that the kernel is going to be undergoing significant changes well past FeatureFreeze?17:14
amitkBenC: ack17:15
slangasekwhich can have a destabilizing effect on bits of userspace, as things are deprecated etc17:15
zulI guess from the server team perspective there is additonal features that we want for the virtualization stuff that we do (xen64 and more kvm features)17:15
BenCslangasek: well, the kernel updates past feature freeze will be limited to bug fixing by upstream's process17:15
slangasekok17:15
* soren agrees with zul and drools over mmu notifiers17:15
BenCzul: xen64 is in .27?17:15
slangasekyou seem to have addressed all the objections I can think of, then17:15
amitkslangasek: things don't really get deprecated in -rc6/rc7, it is only bug fixing17:15
zulBenC: yep17:16
BenCanother reason to add to the list, thanks17:16
BenCslangasek: I've been watching .27 tree since it opened, and the churn has already dropped to bug fixing only17:16
zulalso so we dont have to carry a different flavour for redhat's xen64 patchset17:16
slangasekI'd appreciate it if this plan can be floated by more people than just me (i.e., cjwatson/Keybuk) before we're committed to it17:17
BenCslangasek: I'll post the summary of this discussion and our reasoning to -devel to get feedback17:17
BenCslangasek: If we do it, I'd like to hit next Alpha17:18
slangasekgiven that next alpha is after FF, I agree :)17:18
BenCwhen is next alpha?17:18
BenCtwo weeks from thu?17:18
slangasekSep 17:18
slangasekso, yes17:18
BenCIf we can commit to this by next week, same time, we should be good then17:19
BenCOk, so action: Me: post summary for discussion on ubuntu-devel list17:20
BenCWill do that today17:20
BenCThat's the only topic I had formally set for this17:20
BenCslangasek, zul, soren: Thanks for input17:20
zulnp17:20
smb_tpOk, then we might discuss quickly about the -security fixes17:21
BenCAnyone have anything they want to bring up now?17:21
BenCsmb_tp: Ok, podium's yours then :)17:21
smb_tpIt seems quity urgent for at least Gutsy to have something out17:21
cr3BenC: I would like to mention that all daily iso images for ubuntu (alternate), kubuntu, mythbuntu, xubuntu, ubuntu-server are being tested17:21
smb_tpI checked those asn fixes upstream and they disagree how to fix17:21
smb_tpOne is fixed by ULONG to UINT17:22
slangasekBenC: n/p, thanks for the invite :)17:22
cr3BenC: this is all done automatically, so I would like to take this opportunity to ask whether the kernel team might have special requests for tests to run. I'll be integrating ltp and autotest, but I'm wondering what might be your priorities17:22
smb_tpthe other (better as I guess) by making size to be size_t17:22
BenCcr3: excellent!17:22
BenCcr3: let's let smb finish this topic, and we'll open to that discussion17:23
BenCsmb_tp: Ok...is it easy to cherry pick the upstream fixes?17:23
smb_tpOk, quite simple, yes. And if upstream is happy with that.17:24
BenCsmb_tp: Ok, can you resubmit the upstream versions to kernel-team for ACK?17:24
smb_tpASAP17:24
BenCI don't see a problem with ACK'ing them, but just to keep the process rolling...17:25
BenCsmb_tp: thanks17:25
BenCcr3: Ok, on to your topic17:25
BenCcr3: what are you currently running as testing right now?17:25
cr3BenC: so, I would like to know what the kernel team would find most urgen, preferably in order of priority, to test in my automated suite17:25
cr3BenC: it's rather pathetic right now, I'm simply making sure that the image installs and then making sure that a few processes relating to specific packages are running17:26
ogasawaracr3: can you refresh my memory what specific kernel tests autotest provides?17:26
rtgcr3: device support, virtualization issues, tests that focus on kernel stuff.17:27
cr3ogasawara: I don't recall, sorry17:27
cr3rtg: for device support, I have hardware to help me automate audio testing but it still requires a bit of work, I have also thought of a way to automate webcam testing and I need to perform some exploration for modem testing.17:27
ckingcr3: autotest covers ~17:27
cr3rtg: for those devices and potentially other devices, what might be your priorities?17:28
ckingcr3: try again..  ltp covers 3000+ tests, fs, memory, scheduler, disk I/O, networks, syscalls 17:28
rtgcr3: disk, wireless, video17:28
BenCcr3: a check for /proc/asound/card0 existing17:28
cr3BenC: noted17:28
BenCcr3: checking that there is an interface for every PCI device that is of network class17:29
amitkcr3: how many machines and what kinds do you test on?17:29
ckingcr3: maybe consider dbench, aio-stress, aio-cp, hackbench, vmmstress, kernbench17:29
BenCcking: one thing we have to remember is "daily testing" and the time it takes to run tests :)17:29
rtgcr3: are you doing anything with lvm and/or RAID stuff?17:30
BenCcr3: is this geared at testing the dist, or specific hardware?17:30
ckingBenC: true.. 17:30
cr3amitk: I have about 100 machines ranging from laptops, desktops, servers and a few thin clients I'm not testing very well17:30
ckingcr3: How much time does the current testing take?17:30
cr3amitk: the automated tests right now are very poor, the most relevant being simply testing the installation. however, I'm now in a position to add more tests since the whole process is completely automated so I get test results when I come in the office in the morning :)17:31
rtgcr3: wow, you just about need a test profile for each machine 'cause some of the tests aren't relevant.17:31
ckingcr3: I will send you some info from OLS on testing that I may be useful. 17:31
cr3cking: I'm reluctant to test the hardware with benchmark tools rather than the compatibility of ubuntu with the hardware. what do you think is the particular relevance of benchmark tools?17:32
amitkcr3: if you can simultaneously test on all of them, then I'd like to know if every PCI and USB device has a driver associate with it.17:32
cr3rtg: nothing with lvm or raid right now, but noted17:32
smb_tpcr3, benchmarks usually are doing some stress test17:32
rtgcr3: per amitk's suggestion, you should definitely note unsupported devices.17:32
cr3BenC: now that certification is under QA, the tests are geared towards both hardware and software. basically, everything :)17:33
smb_tpcr3, and some problems show up on procesing high volumes of traffic network or storage17:33
BenCcr3: Ok...just wanted to make sure the comments I was making fell under the scope you were working toward :)17:33
cr3cking: current testing takes about the time of installation, so about 20 minutes. So, I get test results between 20 and 1h20 minutes after a new ISO images is made available on cdimage.ubuntu.com17:33
cr3rtg: the relevance of some tests is currently detected on the machine itself. so, if hal detects that there's an audio controller, then the audio tests are run17:34
rtgcr3: makes sense17:34
cr3rtg: however, this doesn't always work. for example, there might be two network controllers in a machine but only one is detected17:34
cr3rtg: so, I will be introducing the concept of profiles but I have no timeline for this17:35
ckingcr3: It would be interesting to see how much coverage these tests actually do on the entire kernel - I believe that LTP only covers a few percent of the kernel17:35
cr3smb_tp: true, but there's a difference between running a cpuburn and compiling the kernel with num_processors + 1 processes. I think the former is irrelevant because it only tests the hardware whereas the latter is relevant because it tests smp17:36
BenCOk. I say we take this up more in depth over email...sounds like we have some good ideas, and cr3 is probably going to get swamped :)17:36
cr3cking: I think ltp in combination with autotest and lsb might cover a good portion of the kernel17:37
smb_tpcr3, I would rather think of iobench or netbench or how they are named17:37
cr3smb_tp: noted, I actually used to have those as part of my suite, but I removed them eventually because I figured the provided little bang for the buck: some of these benchmarks take a long time to run which delays test results17:38
cr3smb_tp: one solution might be to dispatch test results incrementally, instead of in a batch, but there are no real plans for this yet17:38
BenCcr3: Are these results going to be made available for others?17:40
cr3ok, I think I have plenty to work on until the meeting next week. I will try to keep you guys posted17:40
cr3BenC: yes. this is currently done under the certification framework which is gradually being opened to the community since the department is now under QA17:40
BenCcr3: great, thanks17:41
BenCIf no one else has anything to discuss....17:41
* BenC pauses for slow typers17:41
amitkcr3: what's your annual HW upgrade budget to keep with the current fashion? ;-p17:41
BenCamitk: we don't stock Mac's, so we're not into fashion ;)17:42
amitkhehe17:42
cr3amitk: I have no budget, this is all hardware sent to us by hardware vendors17:42
amitkgood to know17:43
cr3amitk: if you think we should have specific devices, let me know and I could raise this issue with heno17:44
* BenC calls the meeting adjourned17:44
cr3personally, I would rather invest my budget in testing infrastructure such as some telephone switch for testing modems17:44
BenCThanks everyone. See you next week17:44
cr3thanks for all the suggestions folks, much appreciated!17:45
=== mkrufky is now known as mkrufky-lunch
zulBenC: where are the 2.6.27 kernels again?18:53
BenCzul: http://kernel.ubuntu.com/pub/next/18:55
zulthanks18:59
rtgsoren: bug #257569, can you think of a use case for IP filter and connection tracking in the virtual kernel?19:14
elmortg: kernels without those options are useless to me, FWIW19:15
rtgelmo, yeah, but a virtual kernel?19:16
elmortg: well, I use the -xen kernel, but yes ;-)19:16
_rubenvirtualized routers arent that uncommon19:20
_rubenespecially for testing purposes, but also live environments19:20
=== mkrufky-lunch is now known as mkrufky
sorenrtg: Yes. I use it all the time.20:01
sorenrtg: My vpn endpoint is a virtual machine.20:02
rtgsoren: I'm talking about the virtual flavour.20:02
sorenrtg: Yes...20:02
sorenrtg: I thought I was too.20:03
sorenrtg: My vpn server is a virtual machine, which would be running the virtual kernel if there were an amd64 version of it.20:04
rtgsoren: config.virtual:# CONFIG_NF_CT_NETLINK is not set20:04
sorenrtg: The only difference between the server kernel and the virtual kernel really should be device drivers.20:04
rtgsoren: ok, I'll enable it for -virtual.20:05
sorenrtg: In Intrepid?20:05
rtgsoren: Hardy for now. I'll make sure Intrepid is consistent20:05
sorenDon't worry about intrepid.20:05
sorenIt's handled quite differently.20:05
rtgsoren: I want to make sure the main kernel flavors have it enabled.20:06
sorenrtg: all my vm's are amd64 ones, so I don't actually use the virtual kernel flavour much.20:06
sorenrtg: (the production ones are running hardy)20:06
sorenYes, they should all have the same ip filtering capabilities.20:06
rtgsoren: Intrepid has connection tracking enabled for all flavours.20:07
sorenRight.20:07
perfectorwill increasing the kernel shared memory improve overall performance?20:20
arturo-xineramahey everyone. I'm trying to follow online instructions to use my Microsoft Ergonomic Keyboard, but modprobe usbnek4k says no such module found21:36
arturo-xineramarunning kernel 2.6.24-19-generic21:36
arturo-xineramalast thing I read this module was included in the 2.6.24 kernel release21:36
=== rikai_ is now known as rikai
=== superm1 is now known as superm1|away
chris_goearturo-xinerama: you can use "/sbin/modprobe -l" to see which kernel modules are available23:05
=== TheMuso_ is now known as TheMuso

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!