| cking | yawn | 08:00 |
|---|---|---|
| * smb agrees to yawn | 08:12 | |
| cking | smb, hrm, has mumble died again | 08:22 |
| smb | cking, Somewhere. Not sure here or there | 08:22 |
| 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:23 |
| cking | ah, now back in | 08:24 |
| 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:57 |
| smb | its friday, what can possibly go wrong... | 08:58 |
| apw | indeed | 08:58 |
| apw | another shiney kernel yay | 08:58 |
| * cking updated and it works fine | 09:00 | |
| apw | cking, then there is hope | 09:04 |
| apw | get any new unity features today ? pretty sure we are expecting some | 09:05 |
| 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:38 |
| apw | .quit | 09:46 |
| ppisati | apw: actually the stuff tim pushed covered only tools/ | 10:58 |
| apw | ppisati, yeah indeed. those patches i do not recognise | 10:58 |
| apw | ppisati, though they are as invasive as an invasive thing on invasive juice | 10:59 |
| ppisati | :) | 10:59 |
| ppisati | you mean the two i posted on people? | 11:00 |
| apw | ppisati, yes | 11:13 |
| apw | ppisati, it affects the kernel build rather than the packaging, so it is more invasive | 11:14 |
| ppisati | apw: well, but it seems they do what they advertise | 11:17 |
| ppisati | apw: the real problem is that i can't reproduce the breakage in chroot anymore | 11:18 |
| apw | ppisati, those wern't the ones which tiggered the breakage, they were all changes to the packaging | 11:22 |
| 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:23 |
| apw | hmm and are they the same now | 11:24 |
| 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:26 |
| 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:27 |
| 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:28 |
| ppisati | i'm able to cross compile in a P/amd64 chroot, armhf fails (but that's a qemu issue) | 11:34 |
| === smb` is now known as smb | ||
| * ppisati -> lunch | 13:07 | |
| * apw wanders to lunch | 13:25 | |
| 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 ? | 13:27 |
| cking | tgardner, not that I know of | 14:12 |
| 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:13 |
| tgardner | cking, its definitely a righteous fix | 14:16 |
| cking | but it should make no difference since those structs are the same size | 14:16 |
| cking | aka we got lucky it worked | 14:17 |
| tgardner | indeed | 14:17 |
| cking | tgardner, no difference in ACPI 5 either (which is kinda expected) | 14:18 |
| * cking gets on the phone to whine about his dead laptop, wish me luck | 14:22 | |
| josepht | cking: good luck indeed :) | 14:30 |
| cking | like being lost in a twisty maze w/o a map | 14:33 |
| * apw cannot believe how warm it is here | 14:48 | |
| * smb sweats it | 14:52 | |
| * ppisati notes the weather indicator crashed | 14:59 | |
| smb | Probably never tested to display more than 19°C... | 15:01 |
| ppisati | could be | 15:01 |
| 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:02 |
| ppisati | 21C btw | 15:03 |
| smb | 25C! ok... I think the sun reached the sensor... | 15:03 |
| ppisati | :) | 15:03 |
| smb | actually not but it might be a bit sheltered out there on the balcony | 15:04 |
| 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:09 |
| 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:10 |
| 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 | 15:11 |
| === bladernr_ is now known as bladernr_afk | ||
| apw | ogasawara, i am thinking about it, should be getting access to the box shortly | 15:11 |
| 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:12 |
| 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:13 | |
| apw | ogasawara, 42 | 15:14 |
| ogasawara | whoa++ | 15:14 |
| apw | yeah, no way i would expect that machine to work on 32bit, but the failure more is catasrophic | 15:15 |
| apw | so i am thinking we'll do something to mitigate it like drop the end of ram or something | 15:16 |
| cking | the e820 table is eye-popping on that bug | 15:20 |
| 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:21 |
| cking | BIOS-e820: 0000000100000000 - 0000000c40000000 (usable) - that's something you don't see everyday | 15:22 |
| 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:29 |
| apw | apw@dm$ | 17:30 |
| tgardner | apw, agreed, but its not a HW driver | 17:30 |
| 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:31 |
| tgardner | apw, hmm, maybe you're right. drivers/scsi/isci/init.c | 17:32 |
| tgardner | it is doing a PCI register | 17:32 |
| 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:33 |
| 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:34 |
| bryceh | -20 failed to boot for me just now; want a bug report or is this already known? | 17:38 |
| tgardner | bryceh, ASPM ? | 17:41 |
| tgardner | jsalisbury, ^^ | 17:41 |
| 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:44 |
| jsalisbury | bryceh, There is a test kernel in the bug, or you may be able to boot with: pcie_aspm=force | 17:45 |
| Sarvatt | bryceh: oh you skipped -19? | 17:46 |
| bryceh | Sarvatt, yeah this is my main desktop so I don't update it as often as the rest of my hw | 17:48 |
| 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:51 |
| lamont | smb: any updates? | 17:57 |
| 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 | 17:59 |
| smb | lamont, If you want another debug kernel, please type "yes" <enter> now. ;) | 18:00 |
| 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:01 |
| smb | lamont, :) Ok, well I agree that you can register from another port. But then you should not state otherwise in the headers | 18:02 |
| === tgardner is now known as tgardner-lunch | ||
| 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:03 |
| 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:04 |
| 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. | 18:27 |
| === tgardner-lunch is now known as tgardner | ||
| 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:51 |
| arges | apw, have a good one | 18:52 |
| smoser | smb, you're on friday night? | 19:06 |
| === yofel_ is now known as yofel | ||
| smb | smoser, not really but the computer is while I am enyoing tv and a bit of wine. :) | 19:48 |
| 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:21 |
| 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:42 |
| 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:44 |
| 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:45 |
| smoser | yeah, i probalby missed the your intent above. | 20:47 |
| 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:48 |
| 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:49 |
| smoser | i got to run, so monday probably for me. | 20:50 |
| tgardner | maybe this weekend... | 20:50 |
| * tgardner -> EOD | 20:50 | |
| === rsalveti` is now known as rsalveti | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!