| === johanbr_ is now known as johanbr | ||
| === yofel_ is now known as yofel | ||
| * smb yawns | 07:10 | |
| * apw looks blearily at smb | 07:41 | |
| smb | apw, Sounds as awake as I am | 07:41 |
|---|---|---|
| apw | hardly i suspect | 07:41 |
| Kano | hi, is 3.4 final already triggered to compile? | 07:42 |
| apw | depends what happend to the build server on friday | 07:43 |
| Kano | and what happend? | 07:43 |
| apw | they were shifting the disk as root was too big | 07:44 |
| Kano | and that disabled the autobuilds? | 07:44 |
| apw | if the machine doing the autobuilds is down, yes | 07:45 |
| Kano | can you check? | 07:45 |
| smb | If we got enough coffee and we can log in | 07:45 |
| Kano | btw. could you add a litte patch that just adds a 0 size header to fix build of some drivers? | 07:53 |
| Kano | it does not matter if it is the "correct" file, but it has to be there | 07:54 |
| Kano | http://paste.debian.net/170399/ | 08:03 |
| Kano | something like that | 08:03 |
| Kano | that would be enough | 08:04 |
| apw | cking, ?? | 08:12 |
| Kano | apw: whould you add that when attached to the bug report? | 08:13 |
| cking | apw, you referring to my audio beiong broken | 08:13 |
| apw | cking, rather unsubtly | 08:13 |
| smb | he does | 08:13 |
| * cking gives it a whack | 08:13 | |
| apw | Kano, i am working on your first question, and a cup of tea | 08:13 |
| Kano | ah | 08:13 |
| Kano | well i work on many things the same time ;) | 08:14 |
| apw | cking, we can hear you | 08:14 |
| apw | Kano, as can i, my other three threads are working on getting my laptop working | 08:14 |
| apw | cking, we are talking to each other | 08:14 |
| Kano | whats up with your laptop? | 08:15 |
| apw | Kano, catastrophic disk failure | 08:15 |
| apw | cking, nope, tempting though it is we are talking | 08:15 |
| smb | cking, Right we all muted ourselves... :-P | 08:15 |
| Kano | replace it? | 08:15 |
| apw | Kano, now that is a good idea, why didn't i think of it | 08:15 |
| cking | I think apw needs to glue all loose the oxide back on the platter | 08:16 |
| apw | cking, oh another good idea | 08:16 |
| Kano | dont worry my 40 gb ssd died last week | 08:17 |
| cking | Kano, which model? (so I won't buy one) | 08:17 |
| Kano | cking: corsair f40 | 08:17 |
| cking | ah | 08:18 |
| * cking reboots | 08:18 | |
| acapemont | quick question: my site works when you go to https://site.site.com but not http://site.site.com (loads HTML without a stylesheet) | 08:23 |
| apw | acapemont, hmmm ... the config for those two are differernt arn't they? effectivly different sites. though you'd find better understanding from the server folks, on #ubuntu-server | 08:24 |
| * ppisati -> goes for more coffee... | 08:24 | |
| acapemont | will check in there | 08:24 |
| acapemont | thanks | 08:24 |
| ohsix | browser might not like a css reference from an ssl page to a non ssl resource too :p | 08:24 |
| * ppisati -> reboots | 08:42 | |
| cooloney | morning, EU folks | 09:16 |
| smb | cooloney, evening | 09:17 |
| apw | cooloney, yo | 09:30 |
| apw | cooloney, hows it going... having fun with lxc ? | 09:31 |
| cooloney | interesting, a chinese linux os vendor called YlmfOS includes uksm in their kernel | 09:31 |
| Kano | anybody going to berlin this week? | 09:31 |
| apw | cooloney, uksm ? | 09:32 |
| cooloney | apw: http://kerneldedup.org/ | 09:32 |
| cooloney | too bad, all of them are in Chinese | 09:32 |
| apw | yeah chinese only it seems, my reading isn't quite up to that | 09:33 |
| cooloney | UKSM might be developed by some Chinese kernel developer, which support to kill data duplication so it will get more free memory in the system | 09:34 |
| cooloney | data deduplication | 09:34 |
| apw | oh universal kernel shared memory or something | 09:34 |
| cooloney | apw: ultra ksm, heh | 09:34 |
| cooloney | apw: but you can watch the video, | 09:35 |
| cooloney | apw: looks like it's a competitor for KSM | 09:39 |
| apw | its cirtainly an impressive looking video | 09:39 |
| apw | cooloney, is a shame i cannot read the sub-titles | 09:40 |
| cooloney | apw: it claims it's much better than KSM. | 09:41 |
| apw | its cirtainly doing something | 09:41 |
| apw | assuming the video is real | 09:41 |
| cooloney | apw: and it targets for virtualization, VPS market. | 09:41 |
| apw | cooloney, yeah those guys must love all of those sharing things | 09:42 |
| cooloney | but allo docs are in Chinese, and they don't have manpower to push code to upstream. heh | 09:43 |
| apw | there is always the problem, lack of manpower. when they get sick of forward portging it all the time they will learn, they don't have the manpower not to upstream it | 09:44 |
| cooloney | apw: they provide kernel for our 12.04, maybe we can try it. | 09:45 |
| apw | i think you should read the docs, and see how massive it is before we get excited about it | 09:45 |
| cooloney | apw: yeah, i'm reading their doc | 09:47 |
| cooloney | apw: at least, http://buyvm.net/ and ylmf OS 5.0 are using it. | 09:50 |
| alexbligh | Is there a simple way to get the changesets from stock kernel 3.2 (or whatever the upstream Precise is based on) and the source package to build the Precise kernel (i.e. incl debian & debian.master directories)? | 09:58 |
| apw | alexbligh, our kernel is in git on kernel.ubuntu.com ... all the changes are there as commits | 10:01 |
| apw | the source package it was built from you can either get from launchpad, or regenerate it from the tag in the same repo | 10:01 |
| ppisati | apw: when you have some free cycle, can you tell me where to find you config review scripts? | 10:13 |
| apw | ppisati, sure ... | 10:14 |
| Kano | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/942569 | 10:26 |
| ubot2 | Launchpad bug 942569 in linux "binary headers packages are missing include/generated/compile.h" [Low,In progress] | 10:26 |
| Kano | now added there | 10:26 |
| ppisati | i should fill the expenses... | 11:03 |
| cking | ppisati, definitely | 11:03 |
| * ppisati -> lunch | 11:45 | |
| alexbligh | apw, oops, missed your reply. Are you saying that kernel.ubuntu.com is rebased onto the 3.2 release? I'd assumed (quite possibly wrongly) that it was based on the Oneiric release, with the commits to bring the kernel up to date being imported. | 11:56 |
| apw | alexbligh, we rebase for each release, so that we know what we are carrying | 11:57 |
| alexbligh | apw, ah cool (I think). So in theory, if I had an extensively modified 3.2 kernel prepared by a.n.other (SUSE in this case), I should be able to apply your commits on top and get something with precise-like drivers and configuration. | 11:58 |
| apw | alexbligh, all depends how modified, but yes | 11:59 |
| alexbligh | 100 patches (patches.xen - oldstyle xenlinux). I've tried the other way around (take Precise kernel, apply 100 patches, and compile) but it's got lost in some has_fpu nastiness that I don't feel confident about fixing. Looks like SUSE and Ubuntu both took different approaches from mainline. | 12:00 |
| apw | alexbligh, patches.xen, those are for xen host integration right ? | 12:01 |
| apw | alexbligh, as we expect all the xen goodness to be in 3.2 | 12:01 |
| alexbligh | apw, oldstyle xenlinux support so you can run xen3.3 (as opposed to xen4). | 12:01 |
| apw | alexbligh, as in we are not carrying anything for xen at all | 12:02 |
| apw | smb, ^^ ? | 12:02 |
| alexbligh | apw, yes you do - you carry all the Xen4 stuff. | 12:02 |
| alexbligh | apw, at least it works fine with Precise as domU and Oneiric as dom0 | 12:02 |
| smb | Referring to lucid (10.04)? | 12:02 |
| alexbligh | smb, no Precise | 12:03 |
| smb | That is just mainline (having not read the hole backlog yet) | 12:03 |
| alexbligh | we have some customers who want to run Xen3 rather than Xen4 | 12:03 |
| apw | smb, we don't have any xen patches for either dom0 or domU do we ? | 12:03 |
| apw | (in precise) | 12:03 |
| alexbligh | smb, yeah, mainline is just fine for Xen4 | 12:03 |
| smb | apw, no | 12:03 |
| alexbligh | patches.xen is SUSE's patch set to support Xen3 (not Xen4) on 3.x | 12:04 |
| apw | hmmm, sounds like fun... /me declines to ask why someone would chose to run and old hypervisor | 12:04 |
| alexbligh | so my masochistic task for the week is to produce a kernel as close to Precise as possible (packaging and drivers) which does this too | 12:04 |
| smb | apw, You get what you get on ec2 | 12:04 |
| alexbligh | apw, because Xen3 HVM guests do not in general run well on Xen4 | 12:04 |
| alexbligh | apw, and what smb says :-) | 12:04 |
| apw | smb, but we don't run dom0 on ec2, so that at least is ok | 12:05 |
| alexbligh | (though it's the former for us, as we use PV-on-HVM rather than full paravirt). | 12:05 |
| apw | alexbligh, well that sounds like some fun :) | 12:05 |
| smb | apw, If having all sorts of hyervisors is ok... yes | 12:05 |
| apw | alexbligh, so normally their patches are a royal pain as they apply to a second set of source files | 12:06 |
| smb | There might be at least two issues I know of, but apart from that we run mainline on ec2 since maverick at least | 12:06 |
| smb | I believe Maverick was the one that still had the oxsave hack which now seems to cause problems with newer hypervisors | 12:07 |
| apw | smb, yeah alexbligh's problem is host support | 12:07 |
| alexbligh | apw, yes the patches are a PITA. I have actually got all the patches to apply on top of Precise. Compilation is a different matter though. I got this working for Natty rather more easily. Hence the different approach (take what SUSE has and Ubuntu-ify) | 12:07 |
| apw | (dom0 support) | 12:07 |
| apw | alexbligh, you are going to have sooo much fun | 12:07 |
| alexbligh | apw, well, tbf, the Natty kernel I built worked first time (and I nearly fell off my chair). Precise appears to be a bit harder. | 12:08 |
| smb | The suse set had a lot of staged things (xen_compat) which also makes you decide how far backward you want to go. Which in turn is hard to say on ec2 | 12:09 |
| alexbligh | smb, it's not so much EC-2 as I need. Technically the requirement is "to run Xen 3.3.x like Centos 2.6.18-xenified did" | 12:10 |
| * smb wonders what exactly are the issues running native guest kernels... | 12:10 | |
| alexbligh | smb, and it's also easier to take ALL the SUSE stuff (either by importing the patches, or by just starting off with the fully patched source) than bits and bobs. | 12:10 |
| smb | alexbligh, But you are aware that they rebase their set? Meaning future changes will sort of require a re-do-from-start | 12:11 |
| alexbligh | smb, the issue is that our licensees have customers, and they don't want to futz with customer machines. And (for instance) if the end-user has a VM running on Xen 3.3.x, with a modern kernel, and they move to Xen4, then Xen4 will helpfully unplug emulated disks which will cause the end user machine not to reboot. So we have people not wanting to move to Xen4. | 12:12 |
| alexbligh | smb, every Xen3 mod I have ever done means a redo-from-start. | 12:13 |
| alexbligh | smb, in an ideal world, I would organise a neutron ray which erased every trace of existence of Xen3. However, this technology is still in alpha. | 12:13 |
| alexbligh | smb, (but that's partly why I am looking to Ubuntu-ise a SUSE kernel, rather than patches.xen-ify an Ubuntu kernel, so they do all the hard work of rebasing not me). | 12:14 |
| smb | alexbligh, Well yes the unplug. Though at least for newer kernels it should be ok as we build in the pv drivers. And older are not causing it | 12:15 |
| smb | (newer meaning maverick to Precise (iirc)) probably only leaving natty in a mess | 12:16 |
| alexbligh | smb, the issue is they have (for instance) customers with (say) /boot mounted on /dev/sda3 (not /dev/xvda3). /boot is hardly ever used, so no one notices the drop in performance. They are running on a modern kernel (let's say Precise). You change the hypervisor underneath them, and their /boot disappears. Another completely separate problem is that the images we have built for these people with old kernels on with xenlinux pv driv | 12:18 |
| alexbligh | ers may or may not work under Xen4. The main problem is that the list of posisble changes (reordering of ethernet i/fs etc.) is so long, customers throw their hands up and day "noooo". | 12:18 |
| alexbligh | apw, OK I think I am being dumb here. So I am looking at kernel.ubuntu.com, at ubuntu/ubuntu-precise.git. Should I not expect to see somewhere a series of commits that adds debian, debian.master, and some drivers? All I can see is stuff that changes Makefile and changelog! | 12:20 |
| alexbligh | apw, ignore me, I am an idior | 12:21 |
| smb | alexbligh, Yeah, the naming. Though of course upstream Xen always discouraged the use of sd? in the config. Unfortunately did not disable it to force people off. FS labels seems to be the simplest way around that but I understand one does not want to change all customer images. | 12:23 |
| alexbligh | So when do you rebase against mainline? I can see a rebase against v3.2.14, but no rebase (or at least not commit with the word 'rebase' in) against 3.2.15 (though 3.2.15 tag is there) | 12:24 |
| smb | What is more of a worry are those host side problems that are worked around in the patchset. Like the OSXSAVE or some broken hv call in earliest 3.x Xen | 12:25 |
| smb | alexbligh, Either it is still in progress or has no commit. A rebase itself is invisible. Just normally one makes a comment when fixing up configs or changelogs... | 12:26 |
| alexbligh | smb, but won't I get them anyway by taking SUSE's entire patch set? I mean won't Jan have done the hard work for me? Or do you mean he may only be bothered about domU stuff... | 12:27 |
| smb | alexbligh, No it would be in there. It can have unexpected results sometimes. Like the fix for this broken hv poll call would turn ticket spinlocks into normal ones. | 12:28 |
| smb | That one was only needed for earlier than xen 3.2 (iirc) and it seems that ec2 slowly got away from those... | 12:29 |
| apw | alexbligh, we rebase against mainline/mainline stable until release, after release we cherrypick stable onto the top | 12:30 |
| alexbligh | smb, right, but I'm not going to use the resultant ugly chimera of a source tree to compile anything other than Xen dom0 kernels. So if you mean 'it will impact performance/sanity' then fine; if you mean 'it's not actually going to work', though... | 12:30 |
| apw | alexbligh, so there is a combination of techniques | 12:30 |
| alexbligh | hmmm.... perhaps I am better just copying over debian & debian.master and using a SUSE kernel, packaged as a debian kernel. Yuck. Are there many additional drivers in precise I'm going to miss? | 12:31 |
| apw | alexbligh, no idea what they have, we have little other than the union file systems that you may care about ... a lot of our delta is enablement for laptops and the like which is suspect is not your concern in a dom0 | 12:32 |
| smb | alexbligh, You mean only use it for guest kernels (sorry need more coffee for multilevel negation). I would expect it to only impact performance. If you pick the right compat setting | 12:32 |
| apw | alexbligh, i wonder did you consider just merging the two tips, the suse and ubuntu ones, to see what happens | 13:12 |
| apw | ppisati, do i see we now have a Q ti-omap4 ? | 13:29 |
| tgardner | apw, I have not uploaded it yet. I thiugh I'd wait on ogasawara 3.4 rebase, and then have another look at the tools build failure. | 13:32 |
| apw | tgardner, right but we have an official branch already ? | 13:32 |
| tgardner | apw, yes | 13:32 |
| * apw fixed up the cve-autotriager to use it ... | 13:33 | |
| ppisati | apw: yep | 13:50 |
| * ppisati is trying to make audio work on it... | 13:50 | |
| ogasawara | hrm, can anyone else get to gomeisa? | 13:51 |
| ogasawara | I keep getting a permission denied | 13:51 |
| tgardner | ogasawara, still working on LDAP access | 13:51 |
| apw | ogasawara, waiting on IS | 13:51 |
| ogasawara | ah | 13:51 |
| apw | tangerine should be ok | 13:52 |
| cking | it is | 13:52 |
| * ogasawara gets ready to abuse tangerine | 13:52 | |
| smb | fans start wailing | 13:54 |
| alexbligh | apw, no particular interest in xen3 dom0 on a laptop :-). I meant we will only be using it for dom0 (host). Problem with merging the two tips is that for reasons I do not fully understand some, but not all, of the patches.xen are in git on SUSE (i.e. the patches are in their kernel source archives as individual git files, but they do not appear to all be applied, or more accurately there is no arch/x86/include/mach-xen directory ( | 14:14 |
| alexbligh | even though patches.xen contains changes for it); I am a bit lost as to why that is. | 14:14 |
| apw | they prolly get copied from the originals, when the build is running | 14:15 |
| apw | as i think they are copies of the existing files of the same names | 14:15 |
| smb | At least this was some headache with that patchset (which we have in lucid ec2) | 14:15 |
| smb | You basically end up with two parallel universes of Xen in the same source tree | 14:16 |
| tseliot | apw, cking: my nvidia card is acting up with both nouveau and nvidia. It's a new card, I'm wondering if it's dying: http://paste.ubuntu.com/999086/ | 14:17 |
| smb | tseliot, At least something seems to decide to use interrupts no driver is expecting... | 14:20 |
| tseliot | smb: would irqpoll help? | 14:20 |
| tseliot | the only change I made was the graphics card... | 14:20 |
| smb | tseliot, Not sure. This is probably not immediate. Where there any suspends in between? I would check /proc/interrupts after boot to see which interrupts where used by what | 14:21 |
| smb | And when it happens whether it was a previously owned one that is reported to be not cared about | 14:22 |
| tseliot | smb: no, I don't use suspend on the desktop | 14:22 |
| smb | Somehow first irq#24 and then irq#16 triggered that and at least #24 was disabled... | 14:24 |
| tseliot | smb: irq24 is used by nouveau | 14:25 |
| cking | what is irq16 used by? | 14:25 |
| smb | and what type they are? msi? | 14:26 |
| tseliot | cking: IO-APIC-fasteoi ahci, uhci_hcd:usb3 | 14:26 |
| tseliot | 24 is IO-APIC-fasteoi nouveau | 14:27 |
| cking | tseliot, is the card seated in the slot correctly? | 14:28 |
| smb | Hm, so for some reason there was an interrupt triggered on #24 which nouveau (or nvidia) driver did not think came from the card ... | 14:28 |
| tseliot | cking: I think so but I'll double check this | 14:29 |
| alexbligh | smb, apw, aaarrrggghhh. I am completely confused then, as the ubuntu kernel /does/ have a mach-xen directory. | 14:31 |
| smb | alexbligh, The mach-xen is the upstream xen code... If the patchset is what I remember then you have xxx-xen.h header files in the arch/x86 | 14:32 |
| apw | apw@dm:~/git2/ubuntu-precise$ find . -name mach-xen | 14:32 |
| apw | apw@dm:~/git2/ubuntu-precise$ | 14:32 |
| apw | alexbligh, ? | 14:32 |
| smb | oh oops.. was it the other way... | 14:32 |
| alexbligh | apw, find . -name 'mach-xen' | 14:34 |
| alexbligh | ./arch/x86/include/mach-xen | 14:34 |
| alexbligh | that's AFTER applying the suse patches | 14:34 |
| smb | Yeah, sorry, mach-xen is the suse patchset | 14:34 |
| alexbligh | (mm, phone) | 14:34 |
| smb | arch/x86/include/xen is upstram | 14:34 |
| apw | alexbligh, must be suse, its not in my tree | 14:34 |
| === bjf[swapped] is now known as bjf | ||
| Cimi | I noticed bcmwl-kernel-source doesn't build in quantal, thus leaving users without wifi (like on my macbook) | 14:39 |
| * ogasawara back in 20 | 14:39 | |
| Cimi | I think there's a simple patch for it, let me try having it | 14:39 |
| === LetoTheII is now known as LetoThe2nd | ||
| smb | apw, alexbligh ,This is what I so much not like about the patchset. It makes obvious xen code not being used at all. And then some things used by both... | 14:40 |
| tseliot | apw, cking, smb: some nasty traces from the blob: http://paste.ubuntu.com/999116/ | 14:41 |
| Cimi | well, patch is here https://bugs.launchpad.net/ubuntu/+source/bcmwl/+bug/994255 | 14:41 |
| ubot2 | Launchpad bug 994255 in bcmwl "bcmwl-kernel-source 5.100.82.38+bdcom-0ubuntu6.1: bcmwl kernel module failed to build [fatal error: asm/system.h: No such file or directory]" [High,Confirmed] | 14:41 |
| tseliot | Cimi: what kernel? | 14:41 |
| Cimi | tseliot, ciao alberto, 3.4.0 quantal | 14:41 |
| tseliot | Cimi: ok, I think we have the same problem with Nvidia. I'll take care of it | 14:42 |
| * sforshee leaves to take a car to the shop, back in 30 minutes | 14:43 | |
| ppisati | any experience with the alsa trees? i'm looking for a patch, but i can't find it in any tree they have | 14:46 |
| * tgardner thinks ppisati should consult with david | 14:52 | |
| ppisati | diwic: ^^ | 14:54 |
| apw | tsimpson, Cimi, many fine system.h's have been removed P->Q | 14:54 |
| diwic | ppisati, how can I help? | 14:55 |
| ppisati | diwic: any experience with the git alsa tree? | 14:56 |
| diwic | ppisati, yes | 14:56 |
| ppisati | diwic: there's a patchset, composed of two patches | 14:56 |
| ppisati | diwic: the first one was not commited, but the second one was | 14:56 |
| ppisati | diwic: http://comments.gmane.org/gmane.linux.alsa.devel/96316 | 14:57 |
| ppisati | diwic: i can't find the first one | 14:57 |
| ppisati | diwic: do you know where they ususally commit? | 14:58 |
| diwic | ppisati, you might be looking for http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=summary | 14:59 |
| diwic | ppisati, with the asoc subtree http://git.kernel.org/?p=linux/kernel/git/broonie/sound.git;a=summary (look for the tags/heads as master is not updated in this tree it seems like) | 15:01 |
| ppisati | diwic: ok, found in the asoc tree, thanks | 15:06 |
| alexbligh | smb, yes, mach-xen is in the SUSE patch set, but is not in the git tree which is the patched version of the kernel, as far as I can tell. Perhaps someone forgot to do a git add :-) | 15:12 |
| smb | alexbligh, Looking at their source rpm some time ago, patching was part of the rpm build (at least for xen) | 15:14 |
| alexbligh | smb, it is, but they have two kernel repos, one 'kernel-source' which is just the patches, and one called 'kernel' which is, I think, meant to be a git repo with all the patches applied. It appears to have every patch applied I can find, but missing mach-xen. | 15:19 |
| alexbligh | (unless I've misunderstood). I think I should be asking this on #suse-kernel! | 15:19 |
| smb | alexbligh, They likely should know better... :) | 15:20 |
| smb | herton, bjf, Hm, does this look ok to you? | 15:24 |
| smb | linux | 3.2.0-24.37 | precise-updates | source | 15:25 |
| smb | linux | 3.2.0-24.38 | precise-security | source | 15:25 |
| smb | oh... | 15:26 |
| smb | nm, seems rmadison just got an intermediate state since the publishing was recently | 15:27 |
| herton | smb, seems -updates is missing the latest | 15:27 |
| herton | hmm ok | 15:27 |
| apw | check thats true in the real archive, it may be rmadison | 15:27 |
| smb | apw, yep | 15:27 |
| smb | After lp was kind enough to return the history it should be ok | 15:27 |
| henrix | smb: yeah, the kernel has just been copied to proposed | 15:27 |
| apw | yeah think thats just cause -security is done first | 15:28 |
| apw | but if it stayed like that security.u.c gets a caning | 15:28 |
| smb | funy enough it says updates was done 2m before the other | 15:28 |
| smb | oh no | 15:29 |
| tgardner | herton, I noticed that precise is still at 3.2.16. Are you gonna do 3.2.18 before the next upload ? | 15:29 |
| smb | other way round | 15:29 |
| herton | tgardner, I think we can update it, precise update being prepared now only have apw's hv fix, after that goes we will do with what we have in master-next | 15:30 |
| herton | if we were going to use master-next today I would say to wait and update later, but that's not the case | 15:30 |
| herton | I'll take care of it | 15:30 |
| tgardner | herton, I kind of like to get stable updates applied to master-next as soon as they are released so we can start smoke testing them in the dailies. I generally boot 'em on at least a couple of boxes. | 15:31 |
| herton | tgardner, yep, makes sense | 15:32 |
| * ppisati -> brb | 15:32 | |
| jsalisbury | cking, Interesting bug. Wireless performance drops off when running on battery vs AC power: bug 991232 | 15:33 |
| ubot2 | Launchpad bug 991232 in linux "14e4:432b Regression in wireless performance when on battery power" [Medium,Incomplete] https://launchpad.net/bugs/991232 | 15:33 |
| cking | jsalisbury, I will attend to that one | 15:34 |
| jsalisbury | cking, cool, thanks | 15:34 |
| cking | jsalisbury, so I don't think that was caused by any of the precise pm changes, it looks like a wl binary module issue to me | 15:42 |
| jsalisbury | cking, ok | 15:42 |
| cking | but I will add some notes just to sanity check my assumption :-) | 15:43 |
| ogasawara | tgardner: I think there were unwanted affects to amd64 after the collapsing of virtual | 15:51 |
| tgardner | ogasawara, do tell | 15:51 |
| ogasawara | tgardner: it looks like we're missing modules, eg like the extra's modules are not included | 15:51 |
| tgardner | apw, ^^ | 15:51 |
| apw | ogasawara, not included in what> | 15:52 |
| tgardner | ogasawara, yeah, there should be 2 packages, right ? | 15:52 |
| ogasawara | tgardner, apw: right, for i386 we should have 2 packages, amd64 only 1. however that 1 package for amd64 seems pretty bare. | 15:53 |
| apw | no there should be two for both | 15:53 |
| tgardner | ogasawara, why wouldn't we have 2 for amd64 ? | 15:53 |
| apw | generic is two halfs, one half effecticly -virtual, and both together -generic | 15:53 |
| ogasawara | tgardner, apw: oh? well that probably explains what I'm missing | 15:53 |
| ogasawara | for some reason I had it in my head we only had virtual for i386 | 15:54 |
| tgardner | ogasawara, yeah, there should be an -extra- package for both arches | 15:54 |
| tgardner | I believe in symmetry | 15:54 |
| ogasawara | tgardner, apw: just fyi, I've pushed the 3.4 rebased bits to master-next. it's basically what I intend to upload. Am just going to do some meta package testing before pulling the trigger. | 15:59 |
| apw | ogasawara, ack | 15:59 |
| tgardner | ogasawara, having a look now... | 16:00 |
| apw | tgardner, i take it you merged the fix for the udebs into my patches ? | 16:00 |
| tgardner | apw, yep | 16:01 |
| tgardner | apw, IIRC it was just a simple check to see if -extra- existed and to unpack it if so. | 16:01 |
| apw | yeah i see it now | 16:01 |
| smoser | smb, around? | 16:08 |
| smb | smoser, wassup? | 16:09 |
| smoser | on ec2 (precise) | 16:09 |
| smoser | $ echo /dev/disk/by-* | 16:09 |
| smoser | /dev/disk/by-label /dev/disk/by-path /dev/disk/by-uuid | 16:09 |
| smoser | absent is 'by-id' | 16:09 |
| smoser | i think we talked about this one, but dont remember, and only found https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/604335 as a reference for it (it was also broken for virtio) | 16:10 |
| ubot2 | Launchpad bug 604335 in grub2 "grub-pc.postinst script fails to detect virtio vda disk in KVM guest" [High,Triaged] | 16:10 |
| smoser | i'm fine to open a bug on this, but wanted to know if you knew something right away. i'd open against udev, but it seems maybe kernel related (or xen even) | 16:10 |
| smb | smoser, Hm, one of those things missing may point to some udev race. Not really remembering to have talked about this. May be the same thing... | 16:12 |
| smoser | its not race | 16:12 |
| smb | About opening a new bug, depends on how busy the other already is... | 16:12 |
| smoser | well the other is fix-released. | 16:13 |
| smoser | (it was a grub bug dealing with the issue, and virtio is fixed now) | 16:13 |
| smoser | i'll open a new bug, against kernel, let you figure out if that is where it should be, or if it is valid at all. | 16:14 |
| smb | smoser, Hm, the bug still is triaged only... | 16:14 |
| smoser | hm... interesting | 16:14 |
| smb | smoser, But ok, cannot hurt to open a new bug | 16:15 |
| smoser | hm.. wait. | 16:15 |
| smoser | let me check to see if virtio is fixed | 16:15 |
| smb | smoser, Just wondering a but that I should have had this when installing pv-on-hvm guests... | 16:18 |
| smb | a bit... | 16:18 |
| smoser | http://askubuntu.com/questions/80224/does-grub2-require-an-optional-scsi-feature | 16:18 |
| smoser | that calls serial numbers (which are used for by-id) a "optional feature" | 16:18 |
| smoser | and it seems that for vda it was at least not implemented at some points | 16:19 |
| smoser | and might also not be implemented for xen | 16:19 |
| smoser | verified that in 12.04 guest on 12.04 host (launched via openstack) there is no /dev/by-id | 16:20 |
| smb | That could be quite likely. Though my machine here it seems also possible to use other "ids" like model name and serial... Not necessarily this would be there for emulated disks either... | 16:20 |
| smb | smoser, But the real question is whether you also saw the failure they talk of... | 16:22 |
| smoser | well, i have seen the grub failure. | 16:22 |
| smoser | which is why i knew of this bug in the bakc of my head. | 16:23 |
| smoser | but the grub issue is worked around | 16:23 |
| smb | smoser, I did quite a few installs on hvm using the pv drives... | 16:23 |
| smoser | somehow, not sure how. | 16:23 |
| smb | Ah ok... | 16:23 |
| smb | smoser, Not sure why grub would need the by-id, I thought we use the by-uuid (which is fs based) | 16:26 |
| smoser | smb, but for identifying where to install aboot loader, block device is important | 16:28 |
| smoser | (ie, most likely its installed onto /dev/sda, not /dev/sda1 ... the MBR) | 16:29 |
| smb | smoser, Right, but how would your decision be made simpler by knowing any id? (not knowing exactly what grub2 does but usually tending towards the lowest major/minor it seems) | 16:32 |
| smoser | smb, my desire for id is not related to grub2 | 16:32 |
| smoser | (and actually, not related to ec2). | 16:32 |
| smb | Probably you can find /boot and then just drop any partition from the name | 16:33 |
| smoser | i was thinking of making openstack's "attach volume" able to take a serialnumber input. | 16:33 |
| smoser | and then it would attach the device with the given serial | 16:33 |
| smoser | so that outside and inside could agree on which disk was which | 16:33 |
| smoser | as it is right now, if you attach 2 block devices, there is no way of being certain which device is which. | 16:34 |
| smb | I guess not without giving it any fs before... | 16:34 |
| smoser | right. or if you dont know the contents of the block device. (ie, it *has* no fs) | 16:35 |
| smb | smoser, Ok, so you basically want a new feature. And for that the vendor model method does not work as the disk inside would have a different one (as it can or cannot be a real one). And that said of you have a disk image you would have no by-id usable from outside | 16:38 |
| smoser | smb, hm... | 16:44 |
| smb | The more I think about it the less I am positive you can do what you want. I suppose an openstack volume can also be a disk, partition, lv, image file on the host. Having the same id would only be valid for passing on whole disks. | 16:45 |
| smoser | i think we're misunderstanding each other. | 16:45 |
| smoser | kvm does support this. | 16:45 |
| smoser | i just verified. | 16:45 |
| smoser | vm -m 256 -drive file=disk.img,if=virtio,serial=FOOBAR123 -drive file=seed.img,if=virtio -curses | 16:45 |
| smoser | kvm -m 256 -drive file=disk.img,if=virtio,serial=FOOBAR123 -drive file=seed.img,if=virtio -curses | 16:45 |
| smoser | then, inside, i get: virtio-FOOBAR123 -> ../../vda | 16:46 |
| smoser | so its not really a new feature. but in xen it might be. | 16:46 |
| smb | Ok, so you assign some serial when creating the guest (at that time but I think I remember libvirt allows to save it persistently) | 16:47 |
| smoser | well, libvirt does support this, yes. and yeah, it would also keep that with the libvirtxml for that domain | 16:48 |
| smoser | but anyway. | 16:48 |
| smoser | so i guess that my only question for you at this point is whether or not xen block has a 'serial' for the block device | 16:48 |
| smoser | and the, if it did, if we appear to be correctly handling it . ie, its possible that ec2 is just not providing one. when none is provided in kvm, none is found in the guest. | 16:49 |
| smb | So ok, it depends on the abilities of qemu-dm used by xen, the meta data stored for a domain and the xen-blkfront. I cannot say either right now. | 16:50 |
| smb | I don't remember seeing a serial in example guest configs for xen... but that may be inclomplete | 16:50 |
| * ppisati -> bails out | 16:54 | |
| smb | smoser, Hm, checking some xen-unstable docs about the disk specification even for xl there does not seem to be any serial like option. | 16:56 |
| smoser | smb, thanks for looking. | 16:57 |
| === tgardner is now known as tgardner-lunch | ||
| * cking notes that bjf is working tangerine hard | 17:48 | |
| * henrix realised that some time ago :) | 17:49 | |
| bjf | load avg. 2300+ | 17:49 |
| cking | trying for a new record? | 17:50 |
| bjf | i'm trying to see if i can make it catch fire | 17:50 |
| cking | it's kinda unproductive to run so many things in parallel isn't it? | 17:51 |
| cking | swapping a bit | 17:52 |
| * cking tootles off, back later | 18:01 | |
| bjf | cking, i killed off all my builds, the load avg is still kind of high (1200+) | 18:11 |
| cking | bjf, it's dropping now, thanks ;-) | 18:11 |
| === tgardner-lunch is now known as tgardner | ||
| _ruben | 2300+ .. heh, nice :) | 18:16 |
| * jjohansen is afraid he is partly to blame | 18:56 | |
| achiang | jsalisbury: ping | 19:01 |
| jsalisbury | achiang, pong | 19:29 |
| * tgardner -> EOD | 19:37 | |
| achiang | jsalisbury: hi. re: #956845 | 19:37 |
| achiang | jsalisbury: did you write your latest comment by hand or did some bot do it? | 19:38 |
| achiang | jsalisbury: because i don't think that comment is accurate or relevant | 19:38 |
| jsalisbury | achiang, looking | 19:39 |
| jsalisbury | achiang, I posted that due to the request in comment #28 to test the mainline(At the time) kernel. Comment #29 reports the bug is in the upstream kernel as well. However, just noticed your comment #36 | 19:42 |
| jsalisbury | achiang, so you think this bug is firmware related and not kernel? | 19:42 |
| achiang | jsalisbury: right. i think the bug is due to the fact that ubuntu does not distribute proprietary broadcom firmware, and that jockey isn't/can't do the right thing to download it | 19:43 |
| achiang | jsalisbury: for me, if i extracted the firmware as per my comments, then i get no more lockups | 19:43 |
| jsalisbury | achiang, ahh, ok. thanks for the feedback. I'll update the bug and ask the bug reporter to test your suggestion in #34 again | 19:44 |
| achiang | jsalisbury: thanks. arguably there's a jockey bug in there, but i don't think it's necessarily related to the kernel. | 19:44 |
| jsalisbury | achiang, right. thanks again! | 19:45 |
| achiang | jsalisbury: ok, thanks. one last thing, the fix Worked For Me, but no clue if it'll be 100% reliable for the other guy | 19:47 |
| jsalisbury | achiang, ok. I'll await feedback from him. If the fix works for him, do you think this is a bug in firmware-b43-installer? | 19:47 |
| achiang | jsalisbury: perhaps. basically, i've never had luck getting firmware-b43-installer to do the right thing. i don't know if it is supposed to download the firmware i need, or if it is supposed to call the other meta-package, firmware-b43-lpphy-installer | 19:49 |
| jsalisbury | achiang, ok, thanks | 19:50 |
| achiang | jsalisbury: only firmware-b43-lpphy-installer seems to download the proper firmware. and even then, it only seems to work if the card is inserted into the machien | 19:50 |
| achiang | jsalisbury: however, if inserting the card into the machine locks it up... well, you can see the problem there | 19:50 |
| jsalisbury | achiang, yeah, right | 19:50 |
| achiang | jsalisbury: it checks to see if the card is inserted before downloading the firmware. if it can't find the card, it refuses to download it. so even if you're plugged into wired ethernet, you can't get the firmware you need | 19:51 |
| achiang | jsalisbury: the fix then, is to manually (ugh!) download and install the firmware. then you can insert the card without a complete lockup | 19:51 |
| jsalisbury | achiang, hmm, sounds fun | 19:52 |
| achiang | jsalisbury: hopefully you can feed this info back to the proper upstream | 19:52 |
| jsalisbury | achiang, will try to do that | 19:52 |
| jsalisbury | achiang, thanks for all the info | 19:52 |
| achiang | jsalisbury: sure. and if you need more clarification via email or something, let me know. i have the hardware for a few more days (before i give it away to someone ;) | 19:53 |
| jsalisbury | achiang, ok, thanks! | 19:53 |
| achiang | jsalisbury: in summary, this could be fixed if firmware-b43-lpphy-installer were patched to allow firmware download/installation without the card being inserted. then it would be a quite simple process. 1) connect machine to wired ethernet. 2) apt-get install b43-fwcutter firmware-b43-lpphy-installer 3) insert card and enjoy wifi | 19:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!