[08:38] hughhalf :-) [13:01] hi apw , when will rc7 be ready for mainline? [13:42] Kano, a couple of hours at least, seems there was some blockage due to fookage at kernel.org [14:04] apw: so that ich10 thing we weree playing with smb on... (hardy)... [14:04] I suspect that so long as it sees the disk, we're good, right? [14:05] lamont, blimey that seems like a long time ago, they were missing completly right? so yes if you can see them then things must be good [14:05] lamont, can you remind me the bug number? [14:05] we didn't have a bug number yet... missing PCI(?) ID [14:06] did smb or i make the test kernels, and where where they [14:06] (should help me find the original branch) [14:07] http://people.canonical.com/~apw/lamont-ich10-hardy/linux-image-2.6.24-28-generic_2.6.24-28.83~lamontich10v201012031333_amd64.deb [14:07] and smb threw together a random initrd that matches it [14:07] lamont, nice i should be able to find that [14:08] sadly, that means that my initrd believes that I have a german keyboard, which makes the flaky kvm even less useful to me... WTF is the | key?? [14:08] lamont, i presume you want than in lucid? for that we need a bug for the SRU are you able to ubuntu-bug it for me? [14:08] lamont, i _think_ its something like altgr-7 [14:08] I need it in haryd [14:08] (as in rightgr) [14:09] lamont, same deal, and clearly hardy from the version number, doh [14:09] unless you want to give me a working xen in lucid.... [14:09] lamont, i would love to, but i think working xen is going to be n or o [14:09] and yeah, once I confirm that I'm really happy, then I'll file the bug and push for the SRU [14:09] 'zactly [14:09] lamont, sweet [14:09] which means ppa builders are all hardy until at least then [14:10] lamont, i wonder, if we get it say in O then maybe Lucid+O backport will work for you [14:11] but i guess we wait for comfirmation that the xen as merged is actually useful [14:12] yeah - merged will definitely give us an idea of when [14:13] lamont, heh my hardy tree is on the branch with that patch still ... i obviously do little to that [14:14] apw: got a reference for me to stuff in the bug report, or would you just like the bugnumber and add it yourself? [14:14] yeah i don't really need anything in the bug, just the number when you are happy [14:15] [ 122.278637] scsi 0:0:0:0: Direct-Access ATA ST3500320NS SN04 PQ [14:15] I do believe we done found a disk. [14:15] as soon as i have that i can get it on the kernel-team list for review [14:15] that does indeed look promising [14:15] [ 119.770221] hub 8-0:1.0: USB hub found <-- do we have enough USB, I wonder? [14:16] do those things have much usb in em? [14:16] i assume your keyboard is [14:17] it's some random phat box in the DC - I'm on the serial console... and yeah, that many USB ports is not terribly surprising [14:18] these days they put additional hubs in in an area of the board rather than run cables, somehow its cheaper [14:19] 24GB of ram, linux claims '8' processors, X5570 2.93GHz Xeon ('tever) w/8M cache.. these could be suitable builders [14:20] which source package? 'linux' [14:20] ? [14:20] cool. we did do the name switch that long ago [14:22] lamont, dapper is the last one with the version in the name [14:23] tgardner: yeah, but I really care very little about edgy-gutsy [14:23] well, less than "very little", actually [14:23] dapper I do have some care for, at least for another 6 months [14:24] lamont, I have a similar level of concern [14:24] in other news, for whatever reason, the maverick kernel running on lucid seems to make Xserves happier (ppc64-smp) [14:24] tgardner: I believe we are on exactly the same page [14:25] lamont, so, the mutex race (or whatever it was) on PPC has gone away? [14:25] apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/693401 [14:25] Launchpad bug 693401 in linux (Ubuntu) "hardy kernel lacks support for ICH10 controller in Intel Server System SR1600UR (affects: 1) (heat: 6)" [Undecided,New] [14:26] tgardner: I have completely forgotten what the particular failure is, beyond it filling the display with backtrace - well past any meaningful content, mixed with my abject failure to figure out how to get the *(^)^) box to use a serial console [14:26] apw: you update it with fix info, and I'll +1 it when you poke me [14:28] lamont, will do [14:32] lamont, details of the fix are in [14:35] and my +1 is in [14:43] lamont, ok the patch is up for review [14:44] it should be eligable for the next stable update [14:47] tgardner, tracking the ftdi-issue, any ideas on the timeframe ofor 32.27 on hardy? [14:47] s/ofor/for/. [14:48] czr Lucid will get uploaded to -proposed likely sometime first week in Jan [14:48] cool. will take it for a spin then. [14:48] czr: I don't think the issue exists in Hardy. [14:48] ah. my bad :-). lucid I meant [14:49] using hardy for now because lucid is unusable. === _LibertyZero is now known as LibertyZero === bdmurray_ is now known as bdmurray [18:17] tgardner: er, so what's the state of the kernels in -updates? some have CVEs. [18:17] kees, um, I'd have to check which ones got promoted. [18:18] tgardner: I guess I'm worried about process -- the security team was not notified about it :( they need to go to -security too with USN publication. [18:18] lucid and maverick got promoted [18:18] and maverick is an ABI bump' [18:18] kees, I'm not sure sconklin was ready to have them promoted, but I guess the archive admins did it anyways. lemme check [18:24] kees, Lucid 2.6.32-27.49 was promoted to -updates and _does_ contain CVE, and it was also built in the non-virtualized PPA. You're right in that its promotion to -updates should have been coordinated with the security team. I assume the same is true of Karmic and Maverick [18:27] tgardner: yeah, though karmic doesn't seem to have been promoted yet. I'll ask in email, since pitti started a thread on that. [18:43] anyone know if pitti still about ? [18:54] is he not on leave this week? [18:55] kees: here/ [18:56] Keybuk: well, I tried to make a minimal testcase, but it doesn't fail. this is bug 693510. I assigned it to upstart for now since it's not obviously a kernel bug yet. [18:56] Launchpad bug 693510 in upstart (Ubuntu) "child paused by SIGTSTP fails to cause wait() to report WSTOPPED (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/693510 [18:57] which version of upstart? [18:59] 0.6.7-1 with natty kernel [18:59] right [18:59] I've just built that on the maverick kernel [18:59] and it passes [18:59] so back to linux, I'm afraid [18:59] Keybuk: does my testcase match? because it passes on natty [19:00] it's hard to tell [19:00] because you've not really given any information [19:00] ? [19:00] well [19:00] an ssh into the machine that's failing to run the test suite would be nice ;-) [19:00] you don't have natty? [19:01] no [19:02] let me construct a tunnel, gimme a minute... [19:05] one of the differences is that the test case lets the child go first [19:05] * tgardner --> lunch [19:05] (or at least forces them to run in parallel) [19:06] adding sleep(1) to the parent doesn't seem to change anything [19:16] Keybuk: see privmsg for tunnel details === yofel_ is now known as yofel [20:15] Hi, does someone mind telling me how to set gfxpayload=text easily for testing a bug? Can I just put that in the parameter line in grub after 'quiet splash'? === diwic is now known as diwic_afk === BenC__ is now known as BenC === JFo is now known as JFo-vacation === Sarvatt_ is now known as Sarvatt [23:22] ogasawara, i've done a fair amount of testing and i believe that there is no future for the iwl3945 driver: http://pastebin.ubuntu.com/546765/ [23:22] oh wait, she's not here [23:26] at any rate, i believe that the continuing regressions of the driver warrant a serious discussion with intel. i don't care if ipw3945 is revived/forked or if iwl3945 is rewritten. something needs to be done. [23:29] LLStarks: theres some power curve stuff thats being integrated into the drivers as time goes on, did you try checking out rssi and seeing if its flagging between bit rates [23:29] rssi? [23:29] it's the number that you see for signal strength, it's kind of opaque and depends on the driver but you can use it to check for relative signal strength [23:31] the bit rate on the connection changes dynamically based on signal conditions and what the driver decides to do; sometimes it can get pathological and bounce between say 54mbps and 11mbps, you'll get better behaviour if you lock it to the lower bitrate, but if there are changes that are making it less stable those should probably be looked at [23:31] why are there no userland controls that prevent that? [23:32] to prevent the flagging? it's something the driver is supposed to or is assumed it will do appropriately [23:32] brb, i'd like to illustrate a point. [23:32] but the point of mentioning it was so you could watch rssi/bitrate (with wavemon) and see if its stable [23:33] even with iwl3945, a 54Mb rate connection will not exceed 1Mb in actual speed [23:33] that's the problem [23:34] ah [23:35] wen yi is pretty much the only guy working 3945 drivers [23:35] there are some counters you can read for that too [23:35] for excessive retries and stuff, it could be just that the rate limiting algo changed [23:36] i need a way to test all of this without senseless kernel rerolls [23:36] compat-wireless splices are iffy [23:36] you could stash the .ko from the compat-wireless builds for each version you're testing [23:37] true. and i've done that. [23:37] i could back as far as i wanted if i so desired. [23:37] not sure how far back the git goes though. [23:37] heres some info on the rate limiting stuff most things use and its inputs/tweakable stuff, i don't know what intel's stuff actually does with respect to this however http://wireless.kernel.org/en/developers/Documentation/mac80211/RateControl/minstrel