[08:00] <cking> yawn
[08:12]  * smb agrees to yawn
[08:22] <cking> smb, hrm, has mumble died again
[08:22] <smb> cking, Somewhere. Not sure here or there
[08:23] <smb> At least you seemed to have gone silent all of a sudden
[08:23] <cking> ugh, let me kick it on my end
[08:23] <smb> But taht could be me or you
[08:23] <cking> or both ;-)
[08:23] <smb> true :)
[08:23] <smb> Now we have to wait for a third person to join
[08:23] <cking> i'm getting connection refused now
[08:24] <cking> ah, now back in
[08:57] <apw> smb, is it safe to update today?
[08:57] <smb> apw, No idea, I decided (oh well just not did) against it
[08:57] <apw> ahh well, will give it a go, this is supposed to be B2 after all
[08:58] <smb> its friday, what can possibly go wrong...
[08:58] <apw> indeed
[08:58] <apw> another shiney kernel yay
[09:00]  * cking updated and it works fine 
[09:04] <apw> cking, then there is hope
[09:05] <apw> get any new unity features today ?  pretty sure we are expecting some
[09:38] <smb> apw, So sad we don't have new kernel features every Friday... :-P
[09:38] <apw> i claim landing them weds so that everything every
[09:38] <apw> body lands on a thursday is out of date, is better
[09:46] <apw> .quit
[10:58] <ppisati> apw: actually the stuff tim pushed covered only tools/
[10:58] <apw> ppisati, yeah indeed.  those patches i do not recognise
[10:59] <apw> ppisati, though they are as invasive as an invasive thing on invasive juice
[10:59] <ppisati> :)
[11:00] <ppisati> you mean the two i posted on people?
[11:13] <apw> ppisati, yes
[11:14] <apw> ppisati, it affects the kernel build rather than the packaging, so it is more invasive
[11:17] <ppisati> apw: well, but it seems they do what they advertise
[11:18] <ppisati> apw: the real problem is that i can't reproduce the breakage in chroot anymore
[11:22] <apw> ppisati, those wern't the ones which tiggered the breakage, they were all changes to the packaging
[11:23] <ppisati> apw: they were, the secondo one was reverted in O by Tim due to breakage
[11:23] <ppisati> apw: 9b1520dfc90d3c7f6b21773600a1d48ed85cb336
[11:23] <ppisati> apw: "Breaks cross compile in Oneiric x86 chroots."
[11:24] <apw> hmm and are they the same now
[11:26] <ppisati> apw: had to do some modifications to the first one to make it apply
[11:26] <ppisati> apw: but the funny thing is that, if i revert the revert in O
[11:26] <ppisati> apw: kernel builds fine
[11:26] <ppisati> door bell, brb
[11:26] <apw> ppisati, odd indeed.  perhaps the chroots are better now
[11:27] <apw> we did use to use external compilers for this, outside the chroots from code saucery, and now we have proper packages from linaro ... so 
[11:28] <apw> ppisati, and i note we left in the intrusive part ... so it can't have been tooo annoying else we'd have noticed
[11:28] <apw> so ... perhaps its time to consider wacking them back on, and let us find out again if its broken
[11:34] <ppisati> i'm able to cross compile in a P/amd64 chroot, armhf fails (but that's a qemu issue)
=== smb` is now known as smb
[13:07]  * ppisati -> lunch
[13:25]  * apw wanders to lunch
[13:27] <tgardner> cking, re: '[PATCH] ACPI, APEI, fix ERST table size checking' - have you noticed cases where those 2 tables are now different sizes, e.g., with UEFI ?
[14:12] <cking> tgardner, not that I know of
[14:13] <cking> tgardner, but I need to double check now that you've made me wonder
[14:13] <cking> but it is more to do with I need to check ACPI 5
[14:16] <tgardner> cking, its definitely a righteous fix
[14:16] <cking> but it should make no difference since those structs are the same size
[14:17] <cking> aka we got lucky it worked
[14:17] <tgardner> indeed
[14:18] <cking> tgardner, no difference in ACPI 5 either (which is kinda expected)
[14:22]  * cking gets on the phone to whine about his dead laptop, wish me luck
[14:30] <josepht> cking: good luck indeed :)
[14:33] <cking> like being lost in a twisty maze w/o a map
[14:48]  * apw cannot believe how warm it is here
[14:52]  * smb sweats it
[14:59]  * ppisati notes the weather indicator crashed
[15:01] <smb> Probably never tested to display more than 19°C...
[15:01] <ppisati> could be
[15:02] <ppisati> btw, how one is supposed to restart a crashed indicator?
[15:02] <ppisati> just relaunch it?
[15:02] <smb> be a good citizen a report a bug?
[15:03] <ppisati> 21C btw
[15:03] <smb> 25C! ok... I think the sun reached the sensor...
[15:03] <ppisati> :)
[15:04] <smb> actually not but it might be a bit sheltered out there on the balcony
[15:09] <ogasawara> smb: has anyone approached you about some LVM and MD memory leak issue?
[15:09] <smb> ogasawara, nope
[15:09] <smb> Well you, now sort of
[15:10] <ogasawara> smb: hrm, sabdfl pinged me about and said Daviey had the details so was wondering if he may have pinged you
[15:10] <ogasawara> smb: I'm just trying to figure out what the actual issue is
[15:10] <tgardner> ogasawara, apw mentioned that he was running a 32 bit kernel on a platform with gobs of RAM
[15:11] <smb> tgardner, Oh maybe thats all the same
[15:11] <tgardner> and having issues because his 6 core CPU didn't support all of the CPUs
[15:11] <apw> ogasawara, yes Daviey tallked to me
=== bladernr_ is now known as bladernr_afk
[15:11] <apw> ogasawara, i am thinking about it, should be getting access to the box shortly
[15:12] <ogasawara> apw: ack.  is there a bug filed?
[15:12] <apw> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/962992
[15:12] <ubot2`> Launchpad bug 962992 in linux "OOM when using a large amount of RAM, on i386/smp, when high disk IO" [Undecided,Confirmed]
[15:12] <apw> basically the machine is way over spec to work well with 32bit
[15:12] <apw> i am about to writ eit up and put it in the bug
[15:13] <ogasawara> apw: ok thanks
[15:13] <ogasawara> whoa, 32 gigs of ram?!
[15:13]  * smb already had erased that from his head (that it initially talked about lvm/md)
[15:14] <apw> ogasawara, 42
[15:14] <ogasawara> whoa++
[15:15] <apw> yeah, no way i would expect that machine to work on 32bit, but the failure more is catasrophic
[15:16] <apw> so i am thinking we'll do something to mitigate it like drop the end of ram or something
[15:20] <cking> the e820 table is eye-popping on that bug
[15:21] <smb> cking, Yeah I think that makes the problem even worse on machines that are able to handle that much ram... or its something else
[15:21] <smb> but on my server board the lowmem is not even enough to run memtest
[15:21] <smb> (a huge chunk taken away by bios tables)
[15:22] <cking> BIOS-e820: 0000000100000000 - 0000000c40000000 (usable) - that's something you don't see everyday
[17:29] <apw> tgardner, hmm that isci.ko thing, if its isci.ko then that is a real scsi disk controller, and that is not in d-i
[17:29] <apw> apw@dm$ find /lib/modules/`uname -r` -name isci.ko
[17:29] <apw> /lib/modules/3.2.0-20-generic/kernel/drivers/scsi/isci/isci.ko
[17:29] <apw> apw@dm$ git grep isci.ko -- debian.master/d-i
[17:30] <apw> apw@dm$ 
[17:30] <tgardner> apw, agreed, but its not a HW driver
[17:31] <apw> tgardner, i think isci is a h/w driver:
[17:31] <apw>         tristate "Intel(R) C600 Series Chipset SAS Controller"
[17:31] <apw>           This driver supports the 6Gb/s SAS capabilities of the storage
[17:32] <tgardner> apw, hmm, maybe you're right. drivers/scsi/isci/init.c
[17:32] <tgardner> it is doing a PCI register
[17:33] <apw> yeah i think its some new thing, that they have (stupidly) named very similarly to many other utterly different things
[17:33] <tgardner> apw, ok< i had a patch to add it to d-i. I'll ppush it shortly.
[17:34] <tgardner> I might as well add the firmware to the linux-firmware udeb at the same time
[17:34] <apw> yeah... bound to need the firmware ...
[17:38] <bryceh> -20 failed to boot for me just now; want a bug report or is this already known?
[17:41] <tgardner> bryceh, ASPM ?
[17:41] <tgardner> jsalisbury, ^^
[17:44] <jsalisbury> bryceh, know issue: bug 961482
[17:44] <ubot2`> Launchpad bug 961482 in linux "3.2.0-19 kernel fails to boot (-18 OK)" [Critical,Confirmed] https://launchpad.net/bugs/961482
[17:45] <jsalisbury> bryceh, There is a test kernel in the bug, or you may be able to boot with: pcie_aspm=force
[17:46] <Sarvatt> bryceh: oh you skipped -19?
[17:48] <bryceh> Sarvatt, yeah this is my main desktop so I don't update it as often as the rest of my hw
[17:51] <bryceh> jsalisbury, thanks that could  be it.  I have several other systems all running 19 happily (and being upgraded to 20 now), so guessing the desktop is unusual in some way.
[17:57] <lamont> smb: any updates?
[17:59] <smb> lamont, Err, no. Our chat ended in a way that led me to assume you wanted to check on the phone config ... So I did not do anything on it, yet
[18:00] <smb> lamont, If you want another debug kernel, please type "yes" <enter> now. ;)
[18:01] <lamont> ah.  I dug into it some and concluded that it's quite possible that the fine folks at cisco are compliant and that the registration may not come from 5060
[18:01] <bryceh> rebooting to test kernel, brb
[18:01] <lamont> that is, registering is one thing, where to send the reply is found in the UDP headers
[18:01] <lamont> yes
[18:01] <lamont> :-p
[18:02] <smb> lamont, :) Ok, well I agree that you can register from another port. But then you should not state otherwise in the headers
=== tgardner is now known as tgardner-lunch
[18:03] <smb> lamont, Given that it is past b-o-c, I'll get back to it on Monday
[18:03] <lamont> smb: I was meaning that one might actually register using a separate socket (and hence source address) than the socket that one has open to receive SIP traffic
[18:03] <lamont> but dunno
[18:04] <lamont> the biggest challenge is that nearly everyone uses 7640s with a cisco controller, rather than asterisk, as the SIP provider
[18:04] <lamont> making google not really my friend when it comes to finding answers
[18:04] <smb> lamont, Its hard to say. Just gathered from the difference between working and non-working example and the rought hinting about some expectation handling on addresses goes wrong
[18:27] <cking> rats, the ethernet cable popped out of the socket 95% the way through a 1 hour test and I lost my data capture from my multimeter. 
=== tgardner-lunch is now known as tgardner
[18:51] <apw> cking, that sucks
[18:51]  * apw thinks its time to go and enjoy some british fare ... curry and beer
[18:51] <apw> laters
[18:52] <arges> apw, have a good one
[19:06] <smoser> smb, you're on friday night?
=== yofel_ is now known as yofel
[19:48] <smb> smoser, not really but the computer is while I am enyoing tv and a bit of wine. :)
[20:21] <smoser> smb, well, after you've had another glass of wine, you can have some fun looking at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/963420
[20:21] <ubot2`> Launchpad bug 963420 in linux "https download performance significantly worse in precise than lucid" [Undecided,New]
[20:42] <tgardner> smoser, cjwatson just uploaded a new ssl that (I think) takes advantage of HW encryption support. I wonder if that'll make a difference.
[20:44] <tgardner> the other difference between lucid and precise is that the HW encryption routines are built-in in precise.
[20:44] <smoser> tgardner, but you wouldn't think that was there in lucid.
[20:44] <tgardner> well, these are virtual instances, right ?
[20:44] <smoser> ie, precise shouldnt need that to catch up
[20:44] <smoser> (yes, lots could be going on i dont know about)
[20:45] <smoser> but i can't seem to make precise win
[20:45] <tgardner> actually, I don't know for sure. I'm just thinking with my fingers.
[20:47] <smoser> yeah, i probalby missed the your intent above.
[20:48] <smoser> but the key thing is... i just can't seem to get precise faster than lucid with https
[20:48] <smoser> across multiple instances across multiple days... lucid always wins.
[20:48] <smoser> but with http... they both hit ~ 80M/s even.
[20:48] <tgardner> smoser, well, I'd be curious to know what crypto modules are loaded. that seems to be the root of the problem, right ?
[20:48] <smoser> and, i noted in the bug... on EC2, they seem similar.
[20:48] <smoser> i have no idea, tgardner 
[20:49] <smoser> you're welcome to my instances if you'd like
[20:49] <smoser> to poke around.
[20:49] <smoser> ive got to run her ein a minute though
[20:49] <tgardner> smoser, as do I. when you get a chance just drop it in the bug report
[20:49] <smoser> you have canonistack creds ?
[20:49] <smoser> just launch some instances
[20:50] <smoser> i got to run, so monday probably for me.
[20:50] <tgardner> maybe this weekend...
[20:50]  * tgardner -> EOD
=== rsalveti` is now known as rsalveti