=== ogra is now known as Guest96093
[09:48] <apw> bryceh, yep, working on getting a kernel which will boot on 32 and 64 bit at the same time
[09:52] <apw> cking, this may be of interest to you
[09:52] <apw> commit d551d81d6a720542873f478def60baab6b5df403
[09:52] <apw> Author: Rafael J. Wysocki <rjw@sisk.pl>
[09:52] <apw> Date:   Wed Jan 19 22:27:55 2011 +0100
[09:52] <apw>     ACPI / PM: Call suspend_nvs_free() earlier during resume
[09:56] <cking> apw, ta. last night we cornered the bug down to issues in the i915 driver for sure.
=== ogra is now known as ogra_
=== ogra_ is now known as ogra
[13:06] <apw> diwic, about ?
[13:06] <apw> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/682617 <-- anything happening on this bug ?
[13:06] <ubot2> Launchpad bug 682617 in linux "Microphone not working in Optiplex 980" [Critical,Incomplete]
[13:07] <apw> diwic, it seems that that one is not a kernel issue per-see, perhaps a pulse setup issue ?
[13:07] <diwic> apw, let me see
[13:09] <diwic> apw, yeah, I wanted cr3 to confirm that I and he had the same opinion on what was wrong and he never replied back
[13:09] <diwic> apw, or replied back saying he had more important issues that day
[13:09] <apw> diwic, would it make sense to move it over to pulseaudio package
[13:10] <diwic> apw, yes, and would hopefully be fixed with my pulse-mixer patch which should be in Natty given some more testing and review
[13:12] <diwic> apw, ok, moved to pulseaudio
[13:14] <apw> diwic, wicked thanks
=== Quintasan_ is now known as Quintasan
[13:40] <apw> cking,     2. powersave (CPU_FREQ_DEFAULT_GOV_POWERSAVE) (NEW)
[13:40] <apw>  <-- might be of business
[13:46] <bguthro> dwic, we developed a fix for that same problem...let me see if I can pastebin it somewhere
[13:49] <bguthro> dwic, take a look here:
[13:49] <bguthro> http://paste.ubuntu.com/556518/
[13:50] <bguthro> I don't think my colleague has had an opportunity to submit it upstream yet...
[13:51] <bguthro> FWIW, this was developed under 10.04
[13:54] <apw> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/539467
[13:54] <ubot2> Launchpad bug 539467 in pm-utils-powersave-policy "SATA link power management causes disk errors and corruption" [Undecided,Fix released]
[13:58] <smb> sforshee, Morning, btw /me seems to be always around as I got a bip proxy running. Still always worth checking but I could be off :)
[14:01] <sforshee> smb, I figured you were probably offline, but like you said, always worth checking
[14:02] <sforshee> pgraner said you've fixed problems with the Huawei modems in the past?
[14:03] <diwic> bguthro, hmm, I've fixed optiplex 380 a while ago - I think that fix has reached Lucid as well as Maverick and Natty by now, but I'm not completely sure 
[14:03] <smb> sforshee, I certainly was looking at one or two bug with them. Though usually it was finding stuff upstream. wHY?
[14:04] <sforshee> smb, does but 565058 look like anything you've dealt with before?
[14:04]  * smb punches the stupid capslock key
[14:04] <smb> bug 565058
[14:04] <ubot2> Launchpad bug 565058 in linux "Lucid: hotplugging Huawei E220 doesn't load 'option' module" [Undecided,Incomplete] https://launchpad.net/bugs/565058
[14:04] <bguthro> dwic, it's entirely possible. We're working with a somewhat outdated local mirror.
[14:04] <sforshee> the mode switch happens okay, but the ttyUSB devices don't show up
[14:05] <sforshee> not sure if udev isn't loading the option module or something else
[14:05] <smb> sforshee, I think we looked at that briefly in Dallas. Wasn't it the usb id showing up in two drivers or so?
[14:06] <sforshee> smb, not sure what you mean
[14:06] <sforshee> the id does match usb_storage and option
[14:06] <smb> Though reading the description, things do work when manually loading the option driver. Just that autoloading seems to stop with the storage module
[14:06] <sforshee> but the device class, etc. are different between the two
[14:07] <sforshee> yeah, I think it's that udev doesn't load the module, but I'm trying to get some more logs to verify that for certain
[14:08] <sforshee> I do see for sure that udev receives events for the device that should match the option module though
[14:11] <smb> sforshee, It surely will be interesting to see what events get triggered by udev. So lsusb says we got one device with three interfaces, one of which is generic storage class and the other two probably the modem part.
[14:13] <smb> So (I am guessing) option probably matches only based on the usb id, while usb-storage matches on the class. 
[14:13] <sforshee> smb, if you look at the udevadm_monitor.txt attachment, you see the events for the modem interfaces
[14:13] <sforshee> actually usb_storage matches only on the id and option matches on the class
[14:13] <smb> ok, have not got that far yeet
[14:14] <sforshee> alias usb:v12D1p1003d0000dc*dsc*dp*ic*isc*ip* usb_storage
[14:14] <JFo> iirc there was some issue with them where it wouldn't work if it had storage mounted, but it you unmount that it begins working
[14:14] <sforshee> alias usb:v12D1p1003d*dc*dsc*dp*icFFiscFFipFF* option
[14:15] <smb> sforshee, Ah, actually option matches on both
[14:16] <sforshee> JFo, when it's first plugged in it shows up as a storage device, then udev runs something called usb_modeswitch
[14:16] <JFo> right
[14:16] <sforshee> that part is working, but after the modeswitch things are going wrong
[14:17] <JFo> hmmm
[14:17] <sforshee> it ought to be able to use all three interfaces that appear after the modeswitch concurrently though
[14:17] <sforshee> (one of those being a storage device)
[14:18] <smb> Yeah, one would expect
[14:18] <sforshee> smb, if you haven't dealt with this situation before I'll just keep working on it
[14:18] <sforshee> just wanted to make sure there wasn't a known solution
[14:18] <smb> And as manually loading is said to work there must be something in the udev rules
[14:19] <sforshee> maybe
[14:19] <sforshee> I wish udev would output what it actually does in response to an event
[14:19] <smb> That would be nice
[14:20] <smb> Actually I think you should look for whether there is indvidual events for the interfaces
[14:20] <smb> Interface 0 matches up with the storage device
[14:20] <sforshee> there are events for the interfaces
[14:20] <sforshee> after the mode switch interfaces 0 and 1 are the modem, and interface 2 is the storage device
[14:22] <sforshee> smb, the only other interesting thing I see is that usb_modeswitch thinks the mode switch failed
[14:22] <sforshee> it looks like it's just an error in the logic
[14:23] <smb> Oh, right, wrong line taken for the interface number
[14:23] <sforshee> that shouldn't affect udev's response to the events for the modem interfaces, right?
[14:23] <sforshee> well, the logic error is that it expects to see more modem interfaces after the mode switch than before, but the way it counts both before and after the mode switch is incorrect
[14:23] <sforshee> it's fixed in later versions
[14:23] <smb> I would think it should run driver probes for each interface
[14:24] <sforshee> as long as the option module is loaded
[14:24] <smb> rigth and that I would hope to be tied to an event that occurs when those interfaces come up
[14:25] <sforshee> it should be, due to the line in modules.alias
[14:25] <sforshee> unless another udev rule matches the devices first, I guess
[14:25] <sforshee> doesn't udev stop after the first match for an event?
[14:31] <smb> INO, they should all be checked. And every match may add additional things to run or other info
[14:32] <sforshee> okay, thanks for clarifying, I couldn't remember for sure
[14:32] <tgardner> apw, CONFIG_NR_CPUS=256 did the trick
[14:33] <apw> tgardner, awsome ...i'll just apply that to my latest tree
[14:33] <apw> as i have done an updateconfigs since then, which flavours are we going for?
[14:33] <tgardner> apw, we likely only need it for server flavours, right?
[14:33] <smb> sforshee,At least all the interfaces seem to emit events again after (I would think by modeswitch) the go away briefly
[14:34] <smb> sforshee, But as you say, there is no way to see from this what actions were started
[14:34] <apw> tgardner, yeah so -generic-pae and -server i guess
[14:34] <apw> actually perhaps it doesn't make any diff on 32 bit
[14:35] <tgardner> apw, I'm not sure we want to support that many on generic-pae. I think tahts insane
[14:35] <smb> sforshee, I wonder whether that could be made visible by changing the loglevel of udev for a moment
[14:35] <apw> tend to agree.   ok i'll apply it just for amd64 server, how about virtual, you might be mad enough to have a lot of cpus; maybe
[14:35] <apw> smb, whats the most cpus you can get in ec2 instancs ?
[14:36] <tgardner> apw, I think we should leave -virtual alone for now until we run into a case where its really needed.
[14:36] <apw> tgardner, ack, just -server amd64 for now then
[14:37] <sforshee> smb, any idea how that's done?
[14:37] <smb> apw, Bonkers, the doc say 20 ec2 compute units (which is 8 virtual cpu with 2.5 ec2 computeunits). Cant they write normal terms?
[14:38] <apw> heh 8 then, ok
[14:38] <smb> apw, but I think in essence 8 vcpus
[14:38] <tgardner> certainly less then 64
[14:38] <sforshee> smb, I found it, it's in /etc/udev/udev.conf. I'll look to see what kind of things get logged at other levels
[14:39] <smb> sforshee, There is also a way with udevadm
[14:39] <smb> sforshee, udevadm control --log-priority=debug
[14:39] <smb> or back to err
[14:39] <sforshee> smb, that's even easier, thanks!
=== sconklin-away is now known as sconklin
=== smb` is now known as smb
=== yofel_ is now known as yofel
[15:18] <sconklin> https://launchpad.net/ubuntu/+source/linux/2.6.32-28.55/+buildjob/2159614
[15:25] <smagoun> pgraner: sconklin: Hi, OEM would like to request an SRU verification exception for https://bugs.launchpad.net/ubuntu/+source/linux/+bug/685015 . The patch has already been tested and signed-off by OEM QA in a custom OEM kernel. OEM no longer has access to the specific hardware for testing the patch in -proposed. We think the patch is a very low risk of regression - it affects only a single hardware variant.
[15:25] <ubot2> Launchpad bug 685015 in linux "[MAVERICK] Thinkpad Edge 13 External headphones/mic not functiona" [Low,Fix committed]
[15:28] <pgraner> smagoun, dude are we a bit late on this? the deadline was yesterday
[15:29] <apw> smagoun, where is the custom OEM kernel, it would be good to know how similar to the one that was tested by oem-qa to know how valid that testing is
[15:29] <vanhoof> apw: its in oem-master
[15:29] <vanhoof> one sec
[15:29] <smagoun> pgraner: yup, I realize that. We've been scrambling to try to find access to the hardware, and our last lead ran out yesterday at about 7pm ET. I understand that the upload happens today at 11am ET
[15:30] <vanhoof> apw: http://kernel.ubuntu.com/git?p=hwe/oem-master.git;a=shortlog;h=refs/tags/oem/kernel/sutton/02
[15:30] <pgraner> smagoun, yea in 30 min? 
[15:30] <pgraner> smagoun, I thought we were supposed to have two of everything in OEM QA? 
[15:31] <smagoun> pgraner: In this case the vendor asked us to return the machines for use in a trade show
[15:32] <pgraner> smagoun, gotcha, let me talk to the stable team and get the thoughts there
[15:32] <smagoun> pgraner: thanks, let me know if I can help
[15:32] <pgraner> smagoun, TBH I hate doing this cuz it sets a precedence, and we can't keep doing things like this
[15:33] <smagoun> pgraner: I agree, I don't want to do this either. I'm out of options though, and I don't want an ubuntu update to cause a regression on hardware that ships with Ubuntu
[15:33] <pgraner> smagoun, and have it sustainable
[15:33] <pgraner> smagoun, ack lemme take the the team on risk and such
[15:35] <pgraner> smagoun, can you send an email to ubuntu-kernel asking for the exception and we will get the proper acks
[15:35] <smagoun> pgraner: will do that right now
[15:35] <pgraner> smagoun, its not totally our decision we recommend and it has to be accepted by the release team make sure you cc: skaet 
[15:36] <smagoun> ACK
[15:36] <sconklin> and pitti
[15:55] <smagoun> pgraner: mail sent to kernel-team cc skaet, pitti, and vanhoof
[15:55] <pgraner> smagoun, ack thanks
[16:03] <ilmari> hm, no updated drm-intel-next kernels since 2011-01-13
[17:21] <apw> JFo, hey
[17:42] <kamal> I'm looking for AKPM's (Andrew Morton)'s kernel git tree (is it still called the "-mm" tree?).  anyone know where I can find that?
[17:44] <kamal> oh... http://en.wikipedia.org/wiki/Mm_tree says that the -mm tree is now the linux-next tree, which I can find easily at kernel.org
[17:46] <apw> jjohansen, about ?
[17:46] <jjohansen> yep
[17:46] <apw> kamal, there is no git for it is there?
[17:46] <apw> jjohansen, you have three patches in our delta whch i am wondering if we still need or not
[17:47] <jjohansen> apw: shoot?
[17:47] <apw> UBUNTU: SAUCE: Improve Amazon EBS performance for EC2 (d4cd6a8bb5575a999e3ff8a4c28b79188e4e542a)
[17:47] <apw> UBUNTU: SAUCE: fix pv-ops for legacy Xen (43a5c4e9edd44daf3beaf563724d1fcd60de242d)
[17:47] <apw> UBUNTU: SAUCE: blkfront: default to sd devices (fe8b3202017eba2a51c805c6ed1d64e0f24bc47d)
[17:47] <apw> do we need em?
[17:47] <apw> i suspect we do
[17:47] <jjohansen> UBUNTU: SAUCE: Improve Amazon EBS performance for EC2 yes
[17:48] <jjohansen> give me a sec to check the other ones
[17:48] <apw> cool then i can close off your task :)
[17:48] <kamal> apw: there is a git tree for -next :   http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=summary
[17:48] <apw> kamal, not sure that represents -mm though
[17:49] <jjohansen> UBUNTU: SAUCE: fix pv-ops for legacy Xen yes
[17:49] <sforshee> kamal, apw, http://userweb.kernel.org/~akpm/mmotm/mmotm-readme.txt
[17:49] <sforshee> maybe this is what you're looking for?
[17:49] <apw> sforshee, thats my memory of where its at
[17:49] <jjohansen> apw: hrmm, I thought we reverted fe8b3202017eba2a51c805c6ed1d64e0f24bc47d
[17:50] <kamal> apw: oh I'm not sure of that either, but the wiki article impled that there just isn't anything called "mm" anymore
[17:50] <apw> jjohansen, let me check we may have
[17:50] <jjohansen> I know I tested reverting it and had problems, but smb picked it up
[17:50] <jjohansen> as I recall reverting it was working for him
[17:51] <kamal> sforshee: yes, I guess I stumbed upon that also, but that appears to be just a snapshot, and the git tree it points to is bogus
[17:51] <smb> yes it has
[17:51] <apw> jjohansen, yes it is dropped already, page out of date
[17:51] <apw> (page fixed)
[17:51] <sforshee> kamal, I think maybe all that's provided is a snapshot
[17:51] <sforshee> iirc akpm maintains -mm as a patch series using quilt or something like that
[17:52] <apw> sforshee, indeed so, he is not a git-ter
[17:52] <jjohansen> apw: okay
[17:52] <apw> jjohansen, the third one looks needed to my eye too, concur ?
[17:52] <kamal> sforshee: ah, got it.  ok, anyway I think -next is what I'm really looking for.  thanks much!
[17:52] <jjohansen> apw: yep, its needed.  so two needed 1 reverted
[17:53] <apw> jjohansen, cool i'll do the admin, and you can forget about that task -> DONE
[17:54] <jjohansen> apw: actually I thought I had marked it DONE
[17:54] <jjohansen> apw: maybe I didn't hit save :(
[17:54] <apw> seems not... somehow, maybe it came back or something as i note its missing from those slipped too
[17:55] <apw> so its probabally a balls up elsewhere
[17:57] <apw> sconklin, about ?
[17:57] <sconklin> apw: yep
[17:58] <apw> sconklin, you have an open slipped A1 task "document officially supported flavours on a per release basis and who is responsible for those (eg ti etc)" ...
[17:58] <apw> i seem to remember you had done most of that somewhere along the line?
[17:59] <sconklin> hmmm. Let me look for the wiki page I made and the spreadsheet it came from. I'm not sure it's complete
[17:59] <apw> [jjohansen] PV on HVM support (XEN_PCI_PLATFORMDEV) turned on for all, requires testing: INPROGRESS
[17:59] <apw> jjohansen, is that testing done, is it something smb should be doing?
[17:59] <jjohansen> apw: done
[17:59] <apw> jjohansen, ok will close it off for you :)
[18:00] <jjohansen> gah, I can't even get to it, I keep getting server error
[18:01] <apw> jjohansen, heh working for me, and now closed :)
[18:03] <sconklin> apw: here's what I had done https://wiki.canonical.com/KernelTeam/StableSupportMatrix
[18:04] <apw> sconklin, that looks pretty complete
[18:04] <sconklin> I'd be happy to have it marked as a completed task
[18:04] <apw> sconklin, if you added ti-omap4 and marked "patches from TI" i recon that one is closed
[18:05] <sconklin> ok, which releases?
[18:05] <apw> natty, and i think maverick
[18:05] <apw> sconklin, i'll assume you're adding those two lines and write it up and close it
[18:05] <sconklin> I can check. I am all up in maverick today
[18:05] <sconklin> apw will do
[18:06] <apw> sconklin, thanks ... i am glad to find we are not as far back as the items are sayng
=== sforshee is now known as sforshee-lunch
[18:06] <sconklin> yay
[18:06] <sconklin> another reason to drink
[18:11] <sconklin> apw: done
[18:11] <apw> sconklin, great ... two more items down ... *smack*
[18:12] <sconklin> you're channeling ogasawara
[18:12] <apw> someone has to :)
[18:13] <apw> JFo, about?
[18:14] <apw> [jeremyfoshee] look at arsenal scripts to nag the users:TODO
[18:14] <apw> you have that one hanging about?
[18:14] <apw> sconklin/bjf, actually do you already have automation in place for nagging people to validate ?
[18:15] <apw> (in launchpad bugs; for stable releases)
[18:17] <apw> sconklin, also, do you know if victor has done any of these, i guess most of it would be output for your consumption:
[18:17] <apw> [vtuson] HW Cert team - provide a description of what testing they provide, and an idea of the number of hours required to run those:TODO
[18:17] <apw> [vtuson] to investigate which systems are "common" for cert testing:TODO
[18:17] <apw> [vtuson] blueprint for cert-team:TODO
[18:18] <sconklin> apw: yes, we have a nag script done
[18:18] <apw> sconklin, ok so shall i assign that to bjf or you, as i close it?
[18:18] <sconklin> don't know about victor's items. we've still been discussing the best platforms to use for test, but I haven't seen written docs that address the work items
[18:19] <sconklin> assign it to bjf AND close it.
[18:19] <apw> sconklin, sounds like not done then, hastle time :)
[18:19] <apw> sconklin, will do
[18:20] <apw> *smack* one more closed
[18:23] <apw> sconklin, you have been doing a git bisect haven't you ... recently ... wonder if you are going to document the how of it
[18:25] <sconklin> apw: it's not obvious by running "git bisect --help"?
[18:25] <sconklin> well, I suppose that doesn't tell you what to do with the changelog, ets
[18:26] <apw> well i suspect there is some hoop jumping when config is broken or changelog is ... yeah
[18:26] <apw> i personally just pull debian* from HEAD each time
[18:26] <sconklin> ok, I'll document that. Won't touch the config broken case. with a pole.
[18:26] <apw> but ... perhaps between us we need to document a sane way to make them
[18:26] <apw> i can add to it when done
[18:27] <apw> sconklin, we have a task for it, so i'll pencil you in on it
[18:27] <sconklin> ok
[18:27] <apw> (its not urgent or anything)
[18:27] <apw> sconklin, uts i
[18:27] <sconklin> should be part of newbie training anyway, and is potentially something anyone in the community can do for themselves
[18:28] <apw> sconklin, its on https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-bug-handling
[18:28] <apw> sconklin, well you could instruct sforshee-lunch and pass it on to him too :)
[18:29] <apw> cnd about?
[18:29] <sconklin> It'll be easy for me to do as I still have the bisect log and all that, and we have an example bug that shows testing. 
[18:29] <cnd> apw, yep
[18:29] <apw> [chasedouglas] Investigate input-redirection patches:
[18:29] <apw> any idea whats going on with that?
[18:29] <cnd> you can close it out
[18:29] <cnd> we don't need it for natty
[18:30] <apw> cnd, excellent thanks
[18:31] <apw> cnd, gone
=== sforshee-lunch is now known as sforshee
[19:05]  * tgardner --> lunch
[19:11] <apw> tgardner, i think that it is allocating memory for all possible CPUs, and as we have HOTPLUG_CPU=y that might mean all that you allow:
[19:11] <apw>  *  If HOTPLUG is enabled, then cpu_possible_mask is forced to have
[19:11] <apw>  *  all NR_CPUS bits set, otherwise it is just the set of CPUs that
[19:11] <apw>  *  ACPI reports present at boot.
[19:30] <apw> tgardner, seems that this line in dmesg tells you how many pages per CPU you are allocating
[19:30] <apw> [    0.000000] PERCPU: Embedded 30 pages/cpu @ffff880001e00000 s91520 r8192 d23168 u1048576
[19:30] <apw> (so 30 pages per CPU in my case)
[19:33] <apw> tgardner, and this line tells you how many 'possible' CPUs you have:
[19:33] <apw> [    0.000000] SMP: Allowing 2 CPUs, 0 hotplug CPUs
[19:33] <apw> in my case 2 + 0 is how many 'possilble' bits are set
[19:33] <apw> from tangerine i see this:
[19:33] <apw> [    0.000000] SMP: Allowing 64 CPUs, 0 hotplug CPUs
[19:34] <apw> but i think that is the maximum anyhow
[19:34] <apw> but this is from tyler:
[19:34] <apw> [    0.000000] SMP: Allowing 24 CPUs, 0 hotplug CPUs
[19:35] <apw> so that implies, dispite the comments i pasted above, that actually it knows that no more CPUs can come, and its stopped at 24
[19:35] <tgardner> apw, so, should we reconsider  HOTPLUG_CPU=y for very large machines?
[19:36] <apw> tgardner, if you read the rest of that, i think its lying when it says HOTPLUG_CPU will make all of them available
[19:36] <apw> could you check the new machine?
[19:36] <apw> pm me if you prefer
[19:36] <apw> the SMP and PERCPU lines from dmesg
[19:36] <tgardner> apw, actually, tangerine should show the results we need
[19:37] <apw> tgardner, i thought it has 64 cpus, which is what the thing is set to
[19:37] <tgardner> or any 64 bit machine for that matter
[19:37] <apw> therefore its not representative
[19:37] <apw> tyler there says 24, so i think we are ok
[19:37] <apw> but i'd like to see your line from the thing with 256 set
[19:37] <tgardner> I booted a kernel with NR_CPUS=256
[19:37] <tgardner> ok, gimme a bit
[19:38] <tgardner> it takes about 5 minutes to boot
[19:39] <apw> tgardner, as far as i can tell that initla comment is out of date, if you look at prefill_possible_map
[19:39] <apw> it seems to take some account of HOTPLUG but only to enable 'disabled' processors in your acpi information
[19:39] <apw> so i think it really bounds out at what holes you have in the mobo
[19:40] <tgardner> apw, agreed, though it looks like it rounds up to the nearest power of 2. I have a 6 core hyper thread, with 'NR_CPUS:64 nr_cpumask_bits:64 nr_cpu_ids:16 nr_node_ids:1'
[19:41] <apw> whats the SMP line looks like
[19:41] <tgardner> apw, actually, I'm mistaken. its a 4 core
[19:41] <tgardner> SMP: Allowing 16 CPUs, 8 hotplug CPUs
[19:42] <apw> ok so i thinks you have 16 real cpus int he machine and space for 8 more
[19:43] <apw> my laptop for instance has 
[19:43] <apw> [    0.000000] setup_percpu: NR_CPUS:64 nr_cpumask_bits:64 nr_cpu_ids:2 nr_node_ids:1
[19:43] <apw> [    0.000000] SMP: Allowing 2 CPUs, 0 hotplug CPUs
[19:43] <apw> so it would only be wasting room for two dispite NCPUS=64
[19:43] <tgardner> here is the 4 way server: SMP: Allowing 80 CPUs, 0 hotplug CPUs
[19:43] <apw> and dispite having HOTPLUG on
[19:43] <apw> so your bios is reporting 80 cpus!
[19:44] <apw> and no extra space ...
[19:44] <apw> so we are golden
[19:47]  * jjohansen -> lunch
[20:11]  * smb -> out
[20:54] <bjf> rtg, https://spreadsheets.google.com/a/canonical.com/ccc?key=0AgFTUDTDyXredE92dFdsVGkxN1FMMWJabS0wZENLRWc&hl=en&ndplr=1#gid=0
[21:04] <sconklin> https://api.edge.launchpad.net/beta/bugs/cve/2010-3086
[21:04] <sconklin> https://bugs.launchpad.net/launchpad/+bug/322560
[21:04] <ubot2> Launchpad bug 322560 in launchpad "Cannot lookup CVEs by name" [Medium,Triaged]
[21:05] <bjf> sconklin, https://edge.launchpad.net/+apidoc/1.0.html#cves
[21:06] <bjf> sconklin, that gets you a collection of cves
[21:07] <bjf> sconklin, https://edge.launchpad.net/+apidoc/1.0.html#cve
[21:07] <sconklin> yeah, and the data structure reflects what's in that page of cve info
[21:07] <sconklin> looking at that now
=== bjf is now known as bjf[afk]
[22:22] <sivang> hi all
[22:22] <sivang> I hae a very strange behavior with LG T380 and maverick
[22:23] <sivang> the keyboard misses keys while I type
[22:23] <sivang> e.g. as if the keyboard interrupt is being ignored or blocked through the normal operation of the kernel
[22:23] <sivang> can that be? What would be the way to solve this?
[22:24] <sivang> http://pastebin.com/PxKdQVh8
[22:24] <sivang> this is my cpuinfo
[22:24] <sivang> any lead will bemuchly appreciated
=== sconklin is now known as sconklin-gone