=== ericm-Zzz is now known as ericm === _Tommeh is now known as Tommeh === ericm is now known as ericm-otp === ericm-otp is now known as ericm === ericm is now known as ericm|ubuntu === bigbash is now known as zz_bigbash [13:16] herton, bjf, sconklin - is https://bugs.launchpad.net/ubuntu/+source/linux/+bug/760131 going to be rolled back? [13:16] Launchpad bug 760131 in linux "Power consumption raised significantly in natty" [High,Fix committed] [13:18] brendand: yep, probably natty will be respinned tomorrow to revert the patch from this one, no one verified (and given current state of the bug of mixed issues, I think hardly someone will verify it I think) [13:19] herton - ok, thanks [13:34] ## [13:34] ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting [13:34] ## agenda: https://wiki.ubuntu.com/KernelTeam/Meeting [13:34] ## [13:45] herton, brendand: https://bugs.launchpad.net/ubuntu-release-notes/+bug/760131/comments/200 [13:45] Launchpad bug 760131 in linux "Power consumption raised significantly in natty" [High,Fix committed] [13:53] tgardner: yes it's a good fix to have, and we had some reports of improvements for some like comment #168. If no one is against, someone could just mark it verification-done, if comment 168 is good enough, just trying to follow SRU policy here. [13:55] herton - that's the key isn't it? no-one has yet. [14:02] personally i'd love someone to verify it, so we can get started testing the SRU [14:03] brendand, herton: I marked it verification-done [14:08] * brendand waits for the certification-testing task to go to In Progress [14:09] brendand: I'm "releasing" that kernel, should be ready for testing soon [14:19] tgardner, brendand: natty update released from verification, ready for testing (bug 860832) [14:19] Launchpad bug 860832 in kernel-sru-workflow "linux: 2.6.38-12.51 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/860832 [14:23] * ogasawara back in 20 [15:27] bjf: I'll post the CVE bits for apw in the meeting. that way I can almost dominate the entire meeting :) [15:27] ogasawara: wfm [15:39] ogasawara: i think the meeting is you, me, sconklin [15:39] bjf: heh, really? [15:40] ogasawara: ppisati if he has anything [15:41] ogasawara: i'm driving, you and sconklin are doing most / all of the reporting [15:41] bjf: we could cancel, or we could go for the record of shortest meeting ever :) [15:41] start-meeting; ogasawara dump; sconklin dump; end-meeting [15:41] there's not any big news to report [15:42] ogasawara: this is the last one til post-uds anyway, nothing really to report [15:42] * ogasawara nods [15:43] ogasawara: you could announce at the last minute we've switched to 3.1 for oneiric [15:43] hehe [15:55] smb: will you be around for the meeting? [15:56] ppisati: you? [15:58] ogasawara: i'm thinking of canceling the meeting, there just aren't going to be any of us around for it [15:58] ogasawara: if you have no objections ... [15:58] bjf: fine by me [15:59] bjf, you just want to get some beers in early [15:59] * ppisati is here (even if is always silent...) [16:00] and no [16:00] nothing new to report this week [16:00] cking: that would mean starting at 10:00 a.m. (which is a little early even for the kernel team) [16:00] bjf: awww, I was going to be impressed if you had a beer by 10am [16:01] 10am is too early, the previous night's beer session hasn't worn off by then [16:02] ## [16:02] ## Today's Kernel team meeting has been canceled [16:02] ## [16:02] ack [16:02] nack ;-) === bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Oneiric Kernel Version: 3.0.0 || Ubuntu Kernel Team Meeting - Post-UDS - 17:00 UTC || If you have a question just ask, and do wait around for an answer! [16:06] bjf: of course, because I just finished editing the weekly report . . . [16:06] sconklin: i could run it just so you could report out [16:06] post UDS? [16:06] November? [16:06] ppisati: yes [16:07] ah ok [16:07] bjf, nah. There's nothing to report that you can't get from the kernel SRU report pages [16:38] * ppisati -> gym [17:06] GrueMaster: bug 862554 misses the qa-testing-* tag for QA (if it failed or passed) [17:06] Launchpad bug 862554 in kernel-sru-workflow/verification-testing "linux-ti-omap4: 2.6.38-1209.16 -proposed tracker" [Undecided,Fix released] https://launchpad.net/bugs/862554 [17:09] herton: It doesn't help when I have two separate launchpad bugs to track the same kernel and am expected to test it during release time. The added tag sometimes gets lost in the shuffle. [17:13] GrueMaster: which two bugs, I thought there was only this one opened? [17:14] herton: bug 709245 [17:14] Launchpad bug 709245 in linux-ti-omap4 "ARM SMP scheduler performance bug" [High,Fix committed] https://launchpad.net/bugs/709245 [17:14] See Comment #48. [17:16] GrueMaster: ah, this is a different case, the 709245 is not a tracking bug, it's a SRU. By SRU policy, all fixes must be verified, in addition to the QA done on the tracking bug. but verification any one can do, if they can reproduce and test the bug [17:18] Well, anyone usually only means me when it comes to ubuntu-arm testing. [17:49] smb, around ? [18:01] ogasawara, how would i best request that bug 794570 be fixed in early precise ? [18:01] Launchpad bug 794570 in linux "igbvf driver is missing from virtual-flavored kernel" [Undecided,Confirmed] https://launchpad.net/bugs/794570 [18:02] smoser: I'll take a look [18:03] smoser: is that not provided by the new linux-image-extra-virtual package? [18:04] it is [18:04] but, per shattered, these drivers are 100% virtual only. so it makes sense for them to be in the base. [18:05] there may be more, I only have use for igbvf [18:05] maybe vmxnet too [18:07] smoser, shattered: could we get separate bug reports per config request? Makes it easier tracking wise. [18:08] ogasawara, and if shattered opens them, how should he mark them such that you'll see them? [18:08] smoser, shattered: ping me with the bug #'s [18:09] so, one report for each driver? [18:09] shattered: yes please [18:09] shattered: then I can do one patch per bug [18:10] ok [18:20] bug 872411 [18:20] Launchpad bug 872411 in linux "ixgbevf driver is missing from virtual-flavored kernel" [Undecided,New] https://launchpad.net/bugs/872411 [18:24] another one, bug 250549 [18:24] Launchpad bug 250549 in linux "Wrong interface speed from snmpd running as snmp user" [Undecided,Fix released] https://launchpad.net/bugs/250549 [18:25] ogasawara, bjf, I'm seeing lots of duplicate bugs being reported for bug 844957 [18:25] Launchpad bug 844957 in linux "Safely removing external (usb) hdd's can cause a kernel panic or system freeze" [Medium,Confirmed] https://launchpad.net/bugs/844957 [18:25] smoser: you mentioned you wanted it fixed for Precise, did you want an Oneiric SRU as well or will the linux-image-extra-virtaul package suffice for Oneiric? [18:25] ogasawara, bjf, bug 863092 has a possible patch. [18:25] Launchpad bug 863092 in linux "kernel panic on "safely remove" USB 3.0 HDD (dup-of: 844957)" [Undecided,Confirmed] https://launchpad.net/bugs/863092 [18:26] jsalisbury: thanks, I'll take a look [18:26] ogasawara, thanks [18:26] shattered, ^ ? ogasawara shattered is the one affected. i only know of it from there. shattered has said most important thing is to have in LTS. [18:26] jsalisbury: we'll likely want to get them all dup'ed to a master bug [18:27] smoser, shattered: ack. so I'm going to target for Precise and suggest shattered use the linux-image-extra-virtual package for Oneiric. [18:27] ogasawara, ok, so mark each bug similar to 844957 as duplicates? Does anything need to be done to the master bug(844957)? [18:31] jsalisbury: hrm, so I don't see any output of what the actual panic is in the master bug, so you might want to hold off on marking dup's until you can confirm they are all indeed seeing the same panic [18:31] ogasawara, ok. I can request the additional details in all the bugs. [18:32] jsalisbury: cool thanks. gimme a bit to get these other bugs sorted for smoser and shattered and then I'll look at the possible patch for this panic. [18:33] ogasawara, great, thanks! [18:48] jsalisbury: just to double-check, is the kernel you want me to test for bug #848864 v3.1-rc9-oneiric ? [18:48] Launchpad bug 848864 in linux "BUG: unable to handle kernel paging request at ffffb4ff // ext4_get_acl+0x80/0x210" [High,Confirmed] https://launchpad.net/bugs/848864 [18:50] Q-FUNK, yes that would help. The test is to see if the issue is already resolved upstream. [18:50] jsalisbury: or is it whatever currently sits in http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current/ ? [18:50] jsalisbury: yes, I already understand the purpose of the test. :) I just need to make sure that I won't be wasting anyone's time by testing the wrong kernel. [18:52] Q-FUNK, the mainline kernel [18:53] Q-FUNK, actually, let me double check with ogasawara [18:53] jsalisbury: that doesn't answer my question. do you mean the daily build or v3.1-rc9-oneiric ? [18:54] jsalisbury: alright. standing by. :) [18:54] ogasawara, What is the primary differance between http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.1-rc9-oneiric/ and http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current/ [18:54] Q-FUNK: v3.1-rc9 [18:54] jsalisbury: v3.1-rc9 is the latest upstream release candidate, current I believe is the latest tip of the tree? [18:55] jsalisbury: so usually best to have the try the latest release candidate (whatever that is at the time) [18:55] alright. testing 3.1-rc9, then. [18:55] ogasawara, OK, thanks. And the daily has ubuntu specific patches on top? [18:55] jsalisbury: as the tip of the tree is a moving target and harder then to determine what they actually tested at the time [18:55] jsalisbury: no Ubuntu patches, purely mainline [18:56] ogasawara, ahh, understood. [18:56] jsalisbury: so to clarify its the tip of the mainline tree [18:56] ogasawara, thanks, that clears it up for me :-) [18:57] Q-FUNK, thanks for testing the 3.1-rc9 kernel. It would be great if you could update the bug with your findings [19:01] jsalisbury: sure. Just installed and mentioned which one I picked on the bug. Rebooting the target host now. [19:25] jsalisbury: that kernel seems to completely miss vesafb. that makes seeing what happens harder. [19:27] ogasawara: any particular reason why VESAFB is not set? [19:28] Q-FUNK, ok, thanks for the update. I'm not sure why it is not set in that kernel. Can you set it manually? [19:28] Q-FUNK: not sure, would have to look at the configs being used to generate the mainline builds [19:29] jsalisbury: no, since the kernel is built without it. [19:29] $ grep FB /boot/config-3.1.0-0301rc9-generic | grep VESA [19:29] # CONFIG_FB_BOOT_VESA_SUPPORT is not set [19:29] CONFIG_FB_UVESA=m [19:29] # CONFIG_FB_VESA is not set [19:29] Q-FUNK, ahh right. [19:29] no bootfb support and no vesafb. [19:31] Q-FUNK, on thing to try would be previous release candidates, until you find where vesafb as changed, or review the build config files. [19:31] Q-FUNK, that could take some time though. [19:43] Hi all, how do I get a mainline kernel built with a more recent toolset so that I can unload modules which are now marked as "permanent in use"? [19:49] slangasek: was it you that said that vesafb is being phased out in favor of using native fb? === yofel_ is now known as yofel === SanbarCo1puting is now known as SanbarComputing [20:29] 3.1.0-0301rc9-generic is scary. not only does it not have vesafb at all, uvesafb fails to reserve video memory where 3.0 did (yes, v86d is installed). === chrisccoulson_ is now known as chrisccoulson [20:39] Q-FUNK: hrm, I wouldn't have said that; kms-capable fb drivers are preferred, but vesafb is still our fallback [20:40] slangasek: vesafb is not compiled into mainline anymore, it seems. [20:41] Q-FUNK: that sounds like a configuration error with that particular package [20:41] slangasek: could be :) [20:41] that would be 3.1.0-0301rc9-generic [20:43] what exactly causes those "Waiting for network configuration..." displayed by plymouth since Oneiric? [20:46] nice. adding uvesafb to /etc/initramfs.d/modules and dpkg-reconfigure finally loads it at reboot, but it ignores GRUB_GFXMODE even though GRUB_GFXPAYLOAD_LINUX=keep is set. [21:11] "Waiting for network configuration" means that something in /etc/network/interfaces is configured but didn't come up at boot, so the failsafe job that's on a timer is waiting for those to finish coming up before giving up and continuing the boot anyway [21:12] that one only has 'lo' in it. [21:14] Is there an Ubuntu mainline kernel build with a toolset from Oneiric? [21:17] Lekensteyn: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.1-rc9-oneiric/ [21:19] Q-FUNK: I tried that one, but if I compile a module for it, it cannot be unloaded anymore. And according to the ubuntu wiki, it's still built with the toolset from hardy [21:23] Q-FUNK: in that case it sounds like you need to upgrade to the current upstart package in oneiric [21:26] slangasek: everything is up-to-date, unless there's been a new one within the last 24 hours. mind you, this is with 3.1.0-0301rc9-generic, which seems to be broken in many ways. [21:27] that's entirely unrelated to the kernel [21:28] slangasek: I'd asume so too, but I don't see that message with older kernels. [21:28] Q-FUNK: is lo listed as 'auto lo'? [21:28] yup [21:47] slangasek: and I'd somehow expect 'lo' to not require over 1 minute to bring up. :) [21:56] Q-FUNK: sudo initctl list | grep network-interface ? [22:27] slangasek: http://paste.ubuntu.com/706363/ [22:40] Q-FUNK: right, no idea why you would have seen the 'waiting for network' if you're up to date [22:43] slangasek: me neither, but I was wondering if there was anything I overlooked. [22:44] slangasek: interesting. flat out deleting /etc/network/interfaces seems to fix it. [22:47] slangasek: and 'lo' appears in the output of 'sudo initctl list | grep network-interface' regardless. [22:56] or not. [22:57] I still get the "waiting for network connection..." [22:57] /etc/init/network-interface.conf has a failsafe for lo. [22:57] with older kernels too, now. [22:57] what version of upstart is installed? [22:58] 1.3-0ubuntu10 [22:59] that's the right version; and /etc/init/failsafe.conf in that version will only show that message if it takes 20s more to bring up the interfaces in /etc/network/interfaces than it takes to mount the filesystem [22:59] pastebin /etc/network/interfaces? [23:00] slangasek: currently an empty file. [23:00] hrm [23:01] oh. what *does* bring up your network? [23:01] if you have no interfaces at all in there, the 'static-network-up' event will never be emitted [23:01] if you have lo in there, the event should be emitted when lo comes up [23:02] network-manager [23:05] odd. on the static host I'm currently testing the mainline kernel, renaming /etc/network/interfaces to /etc/network/interfaces.bak solved it and it even made the boot faster than before. [23:05] but on my laptop, doing the same it introduced a "waiting for network connection..." that never showed before. [23:08] [ 45.988594] init: network-interface (lo) pre-start process (608) terminated with status 1 [23:08] [ 46.050353] init: network-interface (lo) post-stop process (623) terminated with status 1 [23:09] slangasek: could this be it? [23:09] or is status 1 the expected outcome? [23:09] it is not [23:09] and yes, that sounds like the problem [23:10] what happens if you run 'ifup --allow auto lo'? [23:11] ifup: couldn't read interfaces file "/etc/network/interfaces" [23:15] Q-FUNK: right, which is why it exits 1... and why /etc/network/if-up.d/upstart doesn't get run. [23:16] slangasek: what then? put back all the interfaces in, then comment all the lines? [23:16] or just one comment line? [23:16] Q-FUNK: you should have the lines 'auto lo' and 'iface lo inet loopback' for proper operation [23:18] slangasek: adding them back makes the "waiting for network connection..." appear again. [23:19] yes, but what happens now when you run that ifup command? [23:19] slangasek: it returns nothing, if I have the file present, but with only comments. [23:20] well, I don't know what to tell you [23:20] /etc/network/interfaces is supposed to exist and have an entry for lo as an auto interface [23:21] if something's not working right when doing that, you'll have to trace why [23:22] the 'ifup --allow auto lo' needs to *succeed* when called, or else you'll get the network failsafe delay [23:22] slangasek: if it exists but only contains comments, the "waiting..." stops to appear, ifup no longer returns an error, and 'dmesg | grep status' returns 4 lines less. [23:23] the minute I add the 'lo' entry back, the "waiting..." returns. [23:23] yes, you'll have to debug why [23:23] but the lo entry *has* to be there [23:23] ok [23:23] brb [23:39] slangasek: seems to work again, now. *shrugs* [23:39] however: http://paste.ubuntu.com/706382/ [23:41] not necessarily kernel-related, though, so if you prefer moving this conversation to a more appopriate channel, please tell me.