[05:57] <hyperair> sb levelclear -level clientcrap,crap,joins,parts,quits,nicks,clientnotice
[07:52] <fairuz> morning
[11:51] <ppisati> smb: ping
[11:52] <ppisati> [flag@newluxor kteam-tools]$ ./stable/create-stable-tracker
[11:52] <ppisati> Traceback (most recent call last):
[11:52] <ppisati>   File "./stable/create-stable-tracker", line 11, in <module>
[11:52] <ppisati>     from lpltk.service                      import LaunchpadService, LaunchpadServiceError
[11:52] <ppisati> ImportError: No module named lpltk.service
[11:52] <ppisati> [flag@newluxor kteam-tools]$ dpkg -l | grep launchpad
[11:52] <ppisati> ii  launchpad-integration                0.1.38                                            launchpad integration
[11:52] <ppisati> ii  liblaunchpad-integration1            0.1.38                                            library for launchpad integration
[11:52] <ppisati> ii  liblaunchpad-integration1.0-cil      0.1.38                                            CLI bindings for liblaunchpad-integration
[11:52] <ppisati> ii  python-launchpad-integration         0.1.38                                            library for launchpad integration
[11:52] <ppisati> ii  python-launchpadlib                  1.6.1-1                                           Launchpad web services client library
[11:52] <ppisati> ii  python-launchpadlib-toolkit          0.2.1                                             convenience library for launchpadlib
[11:52] <ppisati> [flag@newluxor kteam-tools]$
[11:53] <ppisati> smb: which pkg am i missing?
[12:46] <DrDetroit> jjohansen: I have finished testing the 30 kernel and have not had any problems
[12:46] <DrDetroit> what do we do now?
[12:47] <jjohansen> DrDetroit: hrmm well I would say stick with the 30 kernel :)
[12:48] <jjohansen> I'll add a note to the bug, and mark it as incomplete or maybe invalid
[12:48] <DrDetroit> jjohansen: ok, I think we should probably delete my bug report, or mark it no good. I also want to thank you for helping me, and apparently fixing my problem
[12:49] <DrDetroit> Also, in appreciation of all your efforts, I am willing to help out test stuff if you ever need me to
[12:49] <jjohansen> I would like to say fix released but we don't know what it was etc.., so I will leave it a slightly less final state
[12:49] <jjohansen> DrDetroit: sounds good, I may just have to take you up on that
[12:49] <DrDetroit> its the least I can do to show my appreciation and to be of some help
[12:50] <DrDetroit> If this happens again, I will file a new bug report.
[12:52] <jjohansen> sounds good
[12:52] <DrDetroit> thank you so much
[12:53] <jjohansen> DrDetroit: your welcome
[12:54] <fairuz> Hi
[12:55] <fairuz> if I have a device registered with platform_device_register, how can I use it?
[12:55] <DrDetroit> good morning
[12:55] <fairuz> DrDetroit: morning
[12:59] <smb> ppisati, pong. I would guess the wrapper and the arsenal toolkit. In the stable directory there is a README with instructions how to get those
[13:39] <ppisati> smb: doh! i really missed the README... :P
[13:40] <smb> ppisati, There are these very rare occasions where those actually contain useful information. :D
[13:40] <ppisati> smb: yep, but i really didn't see it... :)
[13:41] <smb> hehe
[13:44] <fairuz> Hi, any idea why when i compiled my kernel, it adds + at the end of the kernel name
[13:50] <Shred00> why are the kernel-source packages not available for mainline kernels beyond v2.6.32.10-lucid?
[13:51] <smb> Shred00, because the way those were generated they were not that useful. Now you can just take a vanilla tarball and apply the patches in that are provided to get the same source as was used for the build.
[13:52] <Shred00> smb: ahhh.  ok.
[13:52] <smb> fairuz, Only a plus or some number too?
[13:52] <fairuz> smb: only a +
[13:53] <fairuz> smb: i suspect the LOCALVERSION is the culprit?
[13:53] <smb> fairuz, Not really sure then. That should normally end in having some git sha with it. Has that plus somehow made its way into your changelog's version number?
[13:54] <fairuz> smb: It was LOCALVERSION. I recompile with LOCALVERSION= and the + sign disappeared
[13:54] <fairuz> hmm werid. Never happens before
[13:54] <fairuz> *weird
[13:56] <smb> Normally that LOCALVERSION should get updated/modified by the builds environment to contain the version extension from the changelog. If you use the debian/rules calls
[13:58] <fairuz> smb: ok
[14:06] <ppisati> tgardner: ping
[14:06] <tgardner> ppisati, yo
[14:06] <ppisati> tgardner: i've some questions about the ti-omap4 pull/tracker/etcetc
[14:07] <ppisati> tgardner: for example, which version shall i pass to create-stable-tracker?
[14:07] <ppisati> tgardner: previously, you used the version of the kernel upon which you rebased
[14:07] <ppisati> tgardner: but in this case?
[14:07] <tgardner> Use the ti-omap4 version since it is what we're tracking
[14:08] <ppisati> ok
[14:08] <ppisati> so
[14:08] <ppisati> ../kteam-tools/stable/create-stable-tracker --version 2.6.35-903.22 <= prev. one was .21
[14:08] <tgardner> ppisati, that looks right. it also makes sense since a single rebase can contain multiple master stable updates.
[14:10] <Specialist> hi there! i could use some help debugging an s2ram issue... i already used /sys/power/pm_test to isolate the issue and problems start at the 'processor' level ('platform' still works correctly)
[14:14] <tgardner> Specialist, have you tried the firmware test suire (fwts) ? It might give you some ideas.
[14:14] <tgardner> suite*
[14:14] <Specialist> tgardner: nope, i'll have a look at fwts
[14:15] <Specialist> the ugly thing is that this is a regression since 2.6.35 where s2ram worked like a charm...
[14:24] <tgardner> smb, doesn't seem like it would be too hard to produce a test kernel for bug #730765. those are SRU'able patches (I think).
[14:24] <tgardner> and quite testable.
[14:27] <smb> tgardner, Testable should be no problem. The main issue is that those are the upstream versions which only need changing a single place. While the same code is spread over several places in one file (lucid) or two files (hardy)
[14:27] <ppisati> tgardner: about entries in changelog, some of them have a LP# while others don't have one, and i can't find any entry in LP about them
[14:27] <ppisati> tgardner: http://paste.ubuntu.com/586452/
[14:27] <Kano> hi apw , can you tell my why the mainline 38.1 kernel has got no FB_VESA module?
[14:27] <tgardner> smb, I checked Hardy. It seems correct.
[14:28] <ppisati> tgardner: i.e. the first one "ALSA: seq/oss - Fix double-free at error path of snd_seq_oss_open(), CVE-2010-3080" i can't fine any entry in LP about it
[14:28] <ubot2> ppisati: Double free vulnerability in the snd_seq_oss_open function in sound/core/seq/oss/seq_oss_init.c in the Linux kernel before 2.6.36-rc4 might allow local users to cause a denial of service or possibly have unspecified other impact via an unsuccessful attempt to open the /dev/sequencer device. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3080)
[14:28] <Kano> apw: # CONFIG_FB_VESA is not set
[14:28] <tgardner> ppisati, it seems that not all of the CVEs got bug reports. they may be quite old. you could ask bjf when he comes online.
[14:29] <ppisati> tgardner: ok
[14:29] <Kano> also CONFIG_FB_BOOT_VESA_SUPPORT is not set
[14:29] <tgardner> or, the fix may have come via stable updates.
[14:29] <smb> tgardner, Last time I looked there was interrupts regstered somewhere in arch/x86/xen and drivers/xen/ and the proposed patch only covered one place
[14:29] <ppisati> and the funny thing is that LP keeps timing out everytime i try to access a /bugs/cve/...
[14:29] <smb> tgardner, Well for Lucid it did
[14:29] <tgardner> smb, for Hardy it patches archx86/xen/events.c
[14:30] <smb> tgardner, Sadly drivers/xen/events.c is not used for lucid.ec2
[14:30] <tgardner> smb, well, lets see if we can fix Hardy first. that seems the simplest approach.
[14:30] <smb> tgardner, I think drivers/xen/core/evtchn.c might be another place to check
[14:31] <Specialist> hm... fwts segfaults during the hotkey test... is there a way to exclude this specific test?
[14:31] <smb> tgardner, IIRC in HArdy one file did the virqs and ipis and the other the rest of them
[14:31] <tgardner> cking, see Specialist comment above re fwts.
[14:33] <Kano> tgardner: did you work on 38.1?
[14:33] <Specialist> cking: i guess it is the hotkeys test as that is the last entry in the log file
[14:34] <smb> tgardner, Oh and of course one needs to make very sure that anything we change is actually used for the xen custom binary. Those patchsets seem to have the nasty habit of modifying the config options in a way the things looking ovious to be used are not always
[14:34] <cking> Specialist, yes, use fwts --skip-test=foo where foo is the name of the test
[14:34] <tgardner> smb, have you actually looked at the patch?
[14:35] <cking> Specialist, which version of fwts?  fwts -v
[14:35] <smb> tgardner, Only very quick and roughly I must admit
[14:35] <Specialist> cking: 0.18.04 (the version from maverick)
[14:37] <cking> Specialist, may be worth checking out ppa:firmware-testing-team/ppa-fwts-stable as this has some newer code and may fix the issue. If not, please file about against fwts
[14:37] <smb> tgardner, Just to make sure, we are talking about this one? http://launchpadlibrarian.net/66557764/combined.diff
[14:37] <Specialist> cking: afaics --skip-test is not yet implemented in that version
[14:37] <tgardner> smb, yeah, that look right.
[14:38] <tgardner> Specialist, get the Natty version
[14:38] <cking> Specialist, apologies, you're right, it's quite an old version now - so use the one it my ppa-fwts-stable PPA as this has a maverick build with the latest stable code
[14:45] <smb> tgardner, My feeling is that the Hardy patch is ok for ipi and virq, but might miss the same changes for the other types (in evtchn.c). And probably does not do the "use per cpu irq for virq and ipi" thing
[14:48] <tgardner> smb, hmm, I'll rely on your expert opinion. I'm not that familiar with the inner workings of xen
[14:49] <smb> tgardner, Actually its not so much the inner workings of xen as the magic working of the patchset, but let say, give me and hour and I try to see how far I get
[14:51] <ppisati> bjf: ping
[14:56] <Shred00> hrm.  http://www.kernel.org/pub/linux/kernel/v2.6/patch-2.6.32.12.bz2 is the patch one applies to http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.32.11.tar.bz2 to get 2.6.32.12 isn't it?
[15:02]  * ogasawara back in 20min
[15:02] <hyperair> 
[15:02] <hyperair> whoops
[15:09] <cking> Specialist, if the newer version of fwts still segfaults, please file a bug and I will try and get it fixed
[15:10] <Specialist> cking: will do (tests are currently running)
[15:10] <cking> ok
[15:10] <cking> I expect the keymap parsing may have got confused
[15:18] <Specialist> sorry... lost connectivity
[15:24] <Specialist> back to my original s2ram issue. i now have the fwts results available at: https://secure.tgbyte.de/dropbox/aiLiNi8b.txt
[15:24] <Specialist> i had to skip the hotkey, s3 and s4 tests (both freezing)
[15:26] <tgardner> Specialist, have you started a bug report? sometimes there known issues with certain platforms. 'ubuntu-bug linux'
[15:27] <Specialist> tgardner: i have both an ubuntu and a linux kernel bug open,which do not seem to mke much progress as my original kernel was tainted by the nvidia module. the issue, however also occurs with nouveau. i'll attach the fwts output to those reports, though.
[15:28] <tgardner> Specialist, ack
[15:29] <tgardner> sconklin, are you available for a mumble chat ?
[15:29] <cking> Specialist, is this based on an ASUS P5QL motherboard?
[15:29] <sconklin> sure, will fire it up
[15:31] <Specialist> cking: yes
[15:32] <Specialist> cking: any known issues with that hardware?
[15:33]  * cking can't recall of anything, but I've not dealt with that H/W
[15:36]  * cking has a quick google
[15:43] <cking> Specialist, have you tried the advice in https://wiki.ubuntu.com/DebuggingKernelSuspend and/or https://wiki.ubuntu.com/DebuggingKernelSuspendHibernateResume
[15:45] <Specialist> cking: yep, the suspend works until the 'platform' mode (including), but fails once the processor suspend is also tested
[15:46] <Specialist> cking: further diagnostics turn out to be pretty difficult as the screen is turned off before the freeze happens
[15:47] <cking> Specialist, try booting with no_console_suspend and switch to a console and re-do the test, maybe you will see something pop onto the console before it does
[15:47] <cking> s/does/dies/
[15:48] <Specialist> cking: ok, i'll give it a try
[15:49] <cking> it could be one of several issues, maybe a broken driver, or perhaps the BIOS, but w/o more debug it's hard to tell. 
[15:50] <Specialist> cking: aren't drivers ruled out by the fact that the 'platform' test still works?
[15:50] <cking> probably, I missed that
[15:53] <Specialist> cking: hm... my screen still turns off despite no_console_suspend being in place
[15:55] <cking> Specialist, hrm.  I see you have the latest firmware, so updating that is not a route we can look at either
[15:56] <Specialist> cking: ack. i did a bios update recently hoping that it would solve the issue
[15:56] <cking> has S3 always failed, no matter which release you have used?
[15:57] <Specialist> nope, it worked with kernel 2.6.35
[15:57] <fairuz> Hi, is there any way to check if the soource folder is dirty or not? 
[15:57] <Specialist> unfortunately, i had to upgrade to 2.6.38 as 2.6.35 has a terrible latency for dmcrypt/luks
[15:58] <Specialist> i also tried a bisect, but the results do not make much sense (cf. https://bugzilla.kernel.org/show_bug.cgi?id=31562)
[15:58] <ubot2> bugzilla.kernel.org bug 31562 in Hibernation/Suspend "Suspend to RAM (S3) sporadically hangs" [Normal,Reopened]
[16:00] <Specialist> my guess is that there was a false negative during the bisect
[16:00] <cking> yep, especially as the bug seems sporadic
[16:01] <Specialist> the weird thing is, that recently i have been able to reproduce it consistently
[16:02]  * tgardner swipes bug #630748 from ogasawara
[16:02] <ubot2> Launchpad bug 630748 in module-init-tools "iwlagn degrades quickly during normal wifi session" [High,In progress] https://launchpad.net/bugs/630748
[16:02] <cking> Specialist, it seems quite a popular motherboard, but I've not seen anyone else report similar issues
[16:04] <Specialist> cking: well, maybe there aren't too many people that have a core 2 quad running on that hardware. or there aren't too many people already on 2.6.38 so far...
[16:04] <ogasawara> tgardner: from my understanding there's not much more we can do unless there's new firmware to test
[16:05] <cking> Specialist, true. at this point, I'd start putting debug into the appropriate pm paths and the S3 suspend path and see if that shows anything up.
[16:05] <ogasawara> tgardner: but sabdfl is able to reproduce if we need someone to test
[16:05] <cking> Specialist, I think you've run down every reasonable debug avenue I can think of
[16:06] <Specialist> cking: yep, i'll compile a new kernel with debug acpi output enabled
[16:06] <tgardner> ogasawara, I corresponded with Mey-Yi. She thinks now that the drivers are split that we can turn 802.11n on for non-legacy devices. 3945 is gonna be broken forever
[16:06] <Specialist> cking: it may be tricky, though, to read the output considering that the display turns off ;-)
[16:07] <tgardner> ogasawara, what model iwlwifi device does sabdfl have?
[16:07] <Specialist> i guess there is no way to tap into the machine's state to still read data (network is already down) without any special hardware... or would a serial console work?
[16:09] <cking> Specialist,  it depends - I sometimes use the RTC to save state, or if possible I use a port $80 PCI card. Serial only goes so far because most machines I work on don't have a serial port, and one has to use USB/serial dongles and these only work so far in S3 
[16:09] <tgardner> cking, but his MB likely has serial.
[16:09] <Specialist> well, the board still has a serial port connector
[16:10] <cking> in which case, it's well worth a spin 
[16:10] <Specialist> it requires an adapter, but that should be possible to get
[16:11] <cking> if that's not possible, I generally resort to saving debug state in the RTC - it's limited and painful
[16:12] <cking> from the photo of the MB I google'd I couldn't see a serial port
[16:13] <ogasawara> tgardner: I'd have to double check with him, but i think 4965?
[16:14] <tgardner> ogasawara, ok, I'm trying to get my patch reviewed.
[16:15] <Specialist> cking: the P5QL Pro does have a COM1 header next to the super-i/o chip
[16:15] <ppisati> tgardner: about the changelog in LP, does it get filled automagically? or do i have to do it manually?
[16:15] <cking> Specialist, sweet - maybe you are in debug luck
[16:17] <tgardner> ogasawara, non-sequitur - did you notice 2.6.38.2 came out over the weekend?
[16:17] <diwic> cking, is the RTC still a separate chip? If so you could snoop it and use it as a serial port :-)
[16:17] <smb> tgardner, Just a quick feedback on where I am with xen and hardy: Turns out that (of course) arch/x86/xen is not used at all for the custom-binary-xen kernel. And while newer code does the handler calls when binding, the old code does that quite soon and only distinguishes between pirq and dynirq.
[16:17] <ogasawara> tgardner: I did, and I've already rebased and pushed it back up to master-next
[16:17] <tgardner> ogasawara, doh! I should have done my homework :)
[16:17] <ogasawara> ;)
[16:19] <smb> tgardner, So I think I may just try to get dynirqs to be fasteio and see what happens. And leave the use percpu for virq and ipi for a second approach.
[16:21] <tgardner> smb, if not arch/x86/xen, then where is the equivalent support in the patched kernel?
[16:21] <smb> tgardner, drivers/xen/core/evtchn.c as for Lucid
[16:22] <tgardner> smb, ah.
[16:23] <tgardner> how inconvenient.
[16:23] <tgardner> smb, is lucid-ec2 this borked as well?
[16:25] <smb> tgardner, yep, what you see may not be what you get. Everything that seems to be xen (or a lot) is only build with CONFIG_PARAVIRT_XEN set, which is not used/is not set for the topic branch (and hardy xen)
[16:26] <tgardner> smb, I think I'm beginning to feel your pain.
[16:27] <smb> tgardner, At least it makes my head hurt when trying to keep the various versions apart in my head.
[16:27] <tgardner> thats no surprise.
[16:36] <cking> smb,  you need an head expansion pack
[16:37] <smb> cking, Wished I could use those big micro sd cards on myself. At some point one surely does want not to remember. :-P
[16:38] <cking> yeah, back it all onto a micro sd card and put it in a box which will never see daylight again
[17:25] <herton> ogasawara: bug 733780 should be fixed by rebase to 2.6.38.2 on natty (sent patch had buglink but was changed)
[17:25] <ubot2> Launchpad bug 733780 in linux "[126167.230394] BUG: unable to handle kernel paging request at 00100104" [Undecided,Incomplete] https://launchpad.net/bugs/733780
[17:25] <ogasawara> herton: thanks, I'll fix up the changelog
[17:53] <Kano> why is vesa fb not available in 38.2/38.1?
[18:00] <ogasawara> Kano: I thought that was enabled as a module in the recent Natty upload?
[18:00] <Kano> you think, but thats not the case
[18:01] <tgardner> debian.master/config/config.common.ubuntu:CONFIG_FB_VESA=m
[18:01] <Kano> # CONFIG_FB_BOOT_VESA_SUPPORT is not set
[18:01] <Kano> # CONFIG_FB_VESA is not set
[18:01] <Kano> when you check the resulting kernel
[18:02] <Kano> tgardner: i saw it too, but the result is something different
[18:02] <tgardner> debian.master/config/amd64/config.common.amd64:CONFIG_FB_BOOT_VESA_SUPPORT=y
[18:02] <tgardner> debian.master/config/amd64/config.common.amd64:CONFIG_FB_UVESA=m
[18:02] <tgardner> d
[18:02] <tgardner> are we looking at the same kernel? this is Natty
[18:03] <Kano> tgardner: 32 bit .38.2 mainline (same for 38.1 mainline)
[18:03] <manjo> Bug #744419
[18:03] <ubot2> Launchpad bug 744419 in linux "[NATTY] [ Kernel oops installing natty @tty_write()" [Undecided,New] https://launchpad.net/bugs/744419
[18:03] <tgardner> oh, I guess the mailine builds are lagging behind natty
[18:27] <tgardner> ogasawara, gonna need meta package support for natty as soon as LBM is new'ed
[18:28] <ogasawara> tgardner: ack, will get a patch ready
[18:57]  * tgardner --> lunch
[19:00] <jjohansen> sconklin: I don't know if you followed the performance regression I was trying to bisect but, we weren't able too, the problem seem to surface unreliably and he is currently using the -30 kernel without problems
[19:10] <bjf> jjohansen, you were never able to reproduce it yourself ?
[19:10] <jjohansen> bjf: no, /me should add that to the bug
[19:11] <jjohansen> bjf: I was going to run the lucid install longer and see if it surfaced
[19:12] <bjf> jjohansen, i run that on my regular dev system here, and have not seen that issue
[19:12] <jjohansen> bjf: though I do have a perf dump from cfreak on his similar issue with .38
[19:13] <jjohansen> bjf: right, it seems to maybe be at least partially hardware related, cfreaks trace has issue with the hpet (it seems)
[19:19] <sconklin> jjohansen: I did see that in the bug email. Thanks for the effort bisecting. It would be nice to understand this one
[19:20] <jjohansen> sconklin: indeed
[19:47] <sconklin> tgardner: any news on the hppa failure?
[19:49] <tgardner> sconklin, nope, but thanks for the reminder. I sent lamont an email last Friday, but I've not followed up on it.
[19:54] <tgardner> sconklin, or at least I thought I did, but sure can't find it.
[20:13]  * jjohansen -> lunch
[20:50] <tgardner> ogasawara, you still have git repo commit rights, don't you?
[20:50] <ogasawara> tgardner: I do
[20:50] <tgardner> ogasawara, then just push the meta package update
[20:51] <ogasawara> tgardner: ack
[20:52] <ogasawara> tgardner: did you happen to ping cjwatson about the lbm-2.6.38 upload?  I recall andy mentioning we'd need to have him add it to some uploaders list.
[20:52] <ogasawara> tgardner: if not, I'll ping him
[20:52] <tgardner> ogasawara, not yet, we'll likely have to wait until Beta thaws
[20:53] <ogasawara> tgardner: yep, was just gonna give him a heads up
[20:53] <tgardner> ogasawara, sure. I uploaded it, but its stuck in NEW
[21:11] <herton> jjohansen, sconklin, bjf: there is a new performance regression report about 2.6.32, bug 743907
[21:11] <ubot2> Launchpad bug 743907 in linux "Performance degradation after resume" [Undecided,New] https://launchpad.net/bugs/743907
[21:11] <sconklin> herton: thanks
[21:11] <herton> but this one is different, the issue is after resume from suspend
[21:12] <herton> from the one you were looking with DrDetroit
[21:12] <jjohansen> hrmm, I've seen behavior like that before
[21:18] <DrDetroit> The one I was working on didn't show anything using resources, that is what made it so difficult
[21:18] <DrDetroit> but it has gone away on my machine.
[21:47] <jj-afk> back on in an hour
[21:55]  * ogasawara back on later
[22:57] <skaet> ogasawara, when you're back on later, could you take a pass at https://wiki.ubuntu.com/NattyNarwhal/TechnicalOverview and make any changes necessary to describe the kernel a bit better?
[23:33] <Specialist> hi all, i am currently trying to debug the linux kernel through a serial console. after getting the pinout right, everything is working - except for the fact that past a certain point in the boot sequence the kernel messages are no longer sent to the serial console
[23:34] <Specialist> is there any daemon active by default that redirects all kernel messages?
[23:36] <BenC> Specialist: getty
[23:36] <BenC> After initial boot it goes to the "console" which is usually the monitor
[23:37] <BenC> Specialist: http://www.linuxquestions.org/questions/linux-kernel-70/how-to-capture-kernel-panic-messages-on-serial-console-691396/
[23:37] <BenC> should be useful
[23:37] <Specialist> thx
[23:38] <Specialist> so configuring the console using console=ttyS1,115200n8 during boot is not sufficient, right?