/srv/irclogs.ubuntu.com/2012/11/14/#ubuntu-kernel.txt

jjohansenapw: this was on the chromebooks I am hearing if the machine has 2G or under00:23
jjohansenso yeah not that low00:24
BenCapw: Finally, a build we can all be proud of03:00
=== smb` is now known as smb
* ppisati feels a bit sick today...09:47
apwppisati, sounds bad ... your football team lose ?10:14
ppisatiapw: yes, last weekend, but i don't think it's related10:14
ppisatinormal flu, i think i'll survive.. hopefully... :)10:15
jibelcking, I tested lxc with kernel 3.5.0-18.29-lp1065434, transfered data over different links, shutdown/restarted the container multiple times successfully while I can reproduce the bug reliably with the version of the kernel in 12.1010:21
jibelcking, it sound like it resolves the "waiting for lo to become free" issue10:22
ckingjibel, so that looks like a reasonable fix then :-)10:22
apwbug #106543410:23
ubot2Launchpad bug 1065434 in linux (Ubuntu) ""unregister_netdevice: waiting for lo to become free. Usage count = 1" after LXC container shutdown" [High,Incomplete] https://launchpad.net/bugs/106543410:23
ckingjibel, if you can update the bug report and I will SRU it10:24
jibelcking, sure, I'll update it with the tests I did. thanks for the fix!10:25
smbinfinity, still awake?10:43
xnoxI am seeing video/graphics degradation in kvm on raring-host&guest https://launchpadlibrarian.net/122917285/lightdm-grey-boxes.png11:19
* xnox ponders of any good ways troubleshooting that11:20
apwhenrix, hey ... i assume it is you doing the puloads for the current SRU cycle ?  when might i see a linux-lts-quantal 11:29
henrixapw: yep, i am working on that.11:29
apwhenrix, great indeed11:29
henrixapw: the quantal packages are pretty much ready for -proposed11:30
henrixapw: after they are in proposed, the bot should create the bug for the -lts. 11:30
apwhenrix, gotcha11:31
henrixapw: i may start working on the -lts today11:31
apwhenrix, cool, if you could start with the Q backport out of all the derivatives, as it will help expedite secure-boot testing in P11:31
henrixapw: ack11:32
henrixapw: ah! problem is that we still have a few kernels pending from previous cycle. and linux-lts-quantal is one of them11:32
apwhenrix, what is holding it back ?11:33
smbjodh, Would you know from the top of your head how I would make an upstart job depend on a certain device? "tty-device-add DEVICE=hvc0" is not complaining, but neither really seems to not work if I change the name to something that does not exist...11:51
jodhsmb: that should be "tty-device-added DEVNAME=hvc0" I think.11:54
smbjodh, Ah ok, likely DEVNAME to be what udevadm test prints out11:54
jodhsmb: correction, it should be "tty-device-added DEVNAME=*hvc0" (asterisk added)11:55
jodhsmb: the need for the asterisk being show by the output of...11:59
jodhsmb: awk 'BEGIN{RS="";ORS="\n\n"}; /UDEV.*\[/ && /ACTION=add/ && /SUBSYSTEM=tty/ { print; }' /var/log/udev11:59
smbjodh, Ah there is that log already. I suppose it is the same ass the adevadm call shows. I think it is working now. Thanks.12:00
ppisatiapw: did you already create a config diff matrix among flavours for R?12:06
apwppisati, hmmm, not refreshed it since UDS, but which flavour you interested in12:08
ppisatiapw: ah, the uds one is good12:08
ppisatiapw: where is it?12:08
smbjodh, What confused me was some statement that the format would be something like <subsystem>-device-<action>. (Or I did not read well enough) And then not realizing that "service x start" probably overrides any start on magic12:09
apwppisati, http://kernel.ubuntu.com/~kernel-ppa/configs/raring/reviews/UDS.html12:09
apwbut bear in mind it has not derivates as we do not have any at even a slightly similar level12:10
* apw will try and get a 'current' one done in a bit12:10
jodhsmb: good catch! The man pages are incorrect on that point! I'll get them fixed...12:13
smbinfinity, So just to let you know that I have a newer version of the xen package for raring in zinc:~smb/4review which is adding some of the things agreed to at uds and some cves. If you would review and sponsor that you may ignore the currently uploaded one in proposed.12:14
smbjodh, Ah, then at least something good came from my failure. :)12:14
rtgapw, I see that linux 3.7.0-0.5 was accepted finally. I presume that means ppc et al are now consistent and we can upload at will ?12:21
apwrtg, indeed it should mean exactly that ... phew12:22
rtgapw, the regression I was chasing yesterday (PERCPU allocation failure) was actually introduced between 3.5-rc1 and 3.5-rc2, so I think we're clear to upload 3.7-rc5 later today. Do you have anything you want in the upload ?12:24
rtgogasawara is working on some haswell crack, but I don't think its ready.12:25
rtgand it might be for Quantal anyways12:25
apwrtg, i think everything i wanted is on there, just be aware there are changes in there for the common headers package (for ppc) which should not change a think on master, but just be aware12:26
apws/think/thing12:26
rtgapw, this one ? "UBUNTU: [Config] Use SRCPKGNAME as prefix for indep linux headers package"12:26
apwrtg, yeah, in theory it is a noop on master, and a quick review still looks ok, and i have tested it, but it was ported to your cleanup of that code12:27
apwbut just worth checking those in your test build12:28
rtgapw, yeah, I looked at it yesterday. seems fine12:28
* henrix -> lunch12:44
rtgapw, please review ubuntu-raring-signed. Is there anything one needs to do besides just uploading it ?13:59
apwrtg, that looks fine, other than tagging it, uploading it should do the trick; it will depwait on the main binaries14:06
rtgapw, OK. I was waiting to tag it until after your review14:07
apwrtg, guessed as much indeed14:07
apwliterally making sure the version number is right, you found 'update-version' i assume14:07
rtgapw, um, no. I used 'dch -i'14:08
apwthere is a scripty to copy the right version from the master repo: ./update-version ../ubuntu-raring stylee14:08
rtgapw, I backed up one commit and ran update-version. It did the same as I did )by hand), so I guess I got it right.14:10
apwrtg, indeed, it looked similar enough i assumed you had used it :)14:10
apwit does emit the tag commands etc for you to make life easier14:11
rtgapw, oh well, I'm used to doing those by hand anyways. tagged, pushed and uploaded.14:11
apwrtg, thanks14:11
* rtg will be back on in a bit14:11
argessmb, hey14:48
smbarges, hi14:48
argessmb, I see that you fixed pad.lv/322737 a long time ago.  I think bug 1070182 might be related since it is the same network driver. 14:49
ubot2Launchpad bug 1070182 in linux (Ubuntu) "8086:10f5 Can't connect to the network through a wired connection - Network dialog shows "Wired Cable unplugged"" [Medium,Confirmed] https://launchpad.net/bugs/107018214:49
smbI did... must be a longer while14:49
argessmb, I think you made a sauce patch to fix this then, should I try and reapply the sauce to the newer version to see if it fixes the issue?14:49
smbarges, maybe you also could just refresh my memory with the subject of the patch I did and a release14:50
argessmb, sure   * SAUCE: Add support in e1000e for a couple of ICH10 PCI IDs  14:51
argessmb, added support for intel 82567LM 14:51
smbThat probably was hardy...14:51
argesoh yea 8.0414:51
smband usually just adding pci ids14:51
argessmb, so do I need to fix this in linux-ubuntu-modules? or is this in linux ?14:53
smbI think back there it was lum, which do not exist for any recent kernel14:53
argesyes14:54
smbAnd remember that only adds pci ids14:54
smbnot sure whether that matches the problem of that other bug14:54
argessmb, the error seen in dmesg is exactly the same14:54
smbOk, so might be just not attaching then...14:56
smbarges, Though the e1000e driver is loading.14:57
rtghenrix, I assigned bug #1072163 to you. Please see if you can drive it to some sort of conclusion.14:58
ubot2Launchpad bug 1072163 in linux (Ubuntu Raring) "Lack of fsam7400 kernel module in quantal" [Medium,In progress] https://launchpad.net/bugs/107216314:58
smbSo it looks like the pci id would be causing the probe but some checksum is not what is expected.14:58
henrixrtg: ack. i've seen it before, but couldn't find too much time to dig into it14:58
henrixrtg: basically, we don't want to fix it, i.e., we don't need that driver14:59
henrixrtg: there's an upstream driver with same functionality (actually, there are 2), and with the same prob14:59
argessmb, #define E1000_DEV_ID_ICH9_IGP_M_AMT             0x10F5  <--- yea its in the driver15:00
rtghenrix, I'm fine with that. mark it invalid or won't fix with an appropriate explanation.15:00
henrixrtg: ack. i'll try to focus on that bug later today (or, more likely, tomorrow)15:00
argesrtg, http://patchwork.ozlabs.org/patch/197479/15:18
hallynsmb: hey, could you give your opinion on whether bug 1078305 should be deemed a kernel (bridging) bug, or just a legitimate quirk which libvirt should work around?15:21
ubot2Launchpad bug 1078305 in libvirt (Ubuntu) "source IP address of broadcast packets gets rewritten when using NAT" [Undecided,New] https://launchpad.net/bugs/107830515:21
smbhallyn, not quickly I'd need some time to understand the thing15:25
hallynsmb: ok.  i just don't want to work around something in libvirt if it's actually a kernel bug.  i'll comment in the bug for nwo.15:38
apwhallyn, ok ... we really need to have confirmation of the network topology, and the iptables rules in use here15:52
apw  337 20220 MASQUERADE  tcp  --  *      *       192.168.122.0/24    !192.168.122.0/24     masq ports: 1024-6553515:53
apw   31  2296 MASQUERADE  udp  --  *      *       192.168.122.0/24    !192.168.122.0/24     masq ports: 1024-6553515:54
apw    1    40 MASQUERADE  all  --  *      *       192.168.122.0/24    !192.168.122.0/24    15:54
apwhallyn, so if his setup is default (ie matches mine) then i think it is doing what these rules tell it15:54
hallynapw: for some reason i'm having a really hard time reasoning about this bug this morning15:58
apwhallyn, could we rewrite these instead of using !192.168.122.0 ... so like -out !virbir0 -in virbir0 or something16:00
rtgsmb, iptables -vnL -t nat16:01
apwhallyn, have you got a test rig for this ?16:06
hallynapw: no16:06
hallynapw: been out a few days, just saw this bug sitting there today16:06
hallynapw: but, his observatiosn seem actually backward, right?16:06
hallynthe values are NOT masqueraded when usin 192.168.122.0, but are when using 0.0.0.016:07
hallynuh, s/0/255/g16:07
apwhallyn, well from what i can see the kernel is doing what was asked, if you use 255.255.255.255 as a destination then it must be rewritten16:07
apwhallyn, right and that matches his complaint, that if you send to 192.168.122.255 then no rewrite occurs16:08
apwand if you use 255.255.255.255 then you need to do masquerade whcih will rewrite the source address16:08
apwthe rules are just not right in that sense16:08
henrixrtg: you have a 'start new release' commit on ubuntu-precise-meta. was there something you wanted to get into this package?16:09
henrixrtg: ah, its a commit from 19th oct, so you probably don't remember about it anymore :)16:10
henrixrtg: actually, it was on precise-lbm, not -meta16:11
hallynapw: ok, thx.  i'm not sure how easy it is to fix the way you suggest (as it's somewhat hardcoded in libvirt), but i'll mark as not affecting kernel :)16:12
apwhallyn, am playing with some rules now to see if i can even write what we want written16:12
apwhallyn, well in theory you can make the bridge outside of libvirt and use that prebuilt one16:13
apwhallyn, and it is possible they are just wrong and should be fixed for everyone16:13
hallynapw: yes, i think it's wrong upstream, if that's what you mean.16:17
apwsudo iptables -t nat -I POSTROUTING 1 -s 192.168.122.0/24 -d 255.255.255.255 -j RETURN16:17
apwhallyn, i would be interested to know if the above also sorts it out16:17
hallyn<shrug>  i'll ask in the bug16:18
rtgapw, what model N7 did we get? the 16GB one ?16:28
apwrtg, i believe so yes16:29
apwits on the end of the box if that helps16:29
rtgapw, you mean the box I left in Denmark ?16:29
apwyeah that one.  mine cirtainly is 1616:29
apwrtg, ok ... i am seriously considering reinstating the common headers package for -lowlatency so disconnect it from master ... else lack of updates for it prevent linux from moving to -updates16:38
apwrtg, now that we have the template with ppc its pretty easy to do16:38
rtgapw, so that would make it the same as ppc , right ?16:39
rtgfully decoupled ?16:39
apwyes, that indeed16:39
rtggo for it16:39
rtgapw, the N7 rootfs image is giant. I'll likely be at it for awhile16:39
apwrtg, that sucks16:40
apwrtg your -1.6 upload is dropping depwait on libaudit-dev16:53
rtgapw, which is a tools build dependency16:53
rtgwhat do you mean 'dropping' ?16:54
apwrtg, i mean it doesn't exist so linux is not building16:54
apwE: Unable to locate package libaudit-dev16:54
rtgapw, ugh, wtf ? I'm sure I installed it.16:55
apwRaringreleaseon 2012-10-18universelibs16:55
apwif you could read that you'd see its universe, so needs an MIR for the build to succeed16:56
rtgapw, ah, shit16:56
rtgapw, I think x86 perf tools will build without it. lemme check16:57
* apw muses as to why all his pastes get shafted like that16:57
* ppisati -> EOD17:20
SpamapSis there some reason there are no mainline kernel builds for precise past 3.4 on http://kernel.ubuntu.com/~kernel-ppa/mainline/ ?17:30
rtgSpamapS, 'cause we started using the quantal config for 3.5, http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.5-quantal/17:37
SpamapSrtg: ah ok, so you'd expect the latest 3.6.6 to work on precise?17:43
rtgSpamapS, I see no reason why it wouldn't17:43
SpamapSrtg: I had thought there were firmware changes in quantal17:43
rtgSpamapS, there were for some devices. I've packaged those updates with the distro backport, but mainline doesn't have them17:44
SpamapSgotchya17:44
infinitysmb: I can poke at that today, sure.18:02
* rtg -> lunch18:33
* henrix -> EOD18:58
* apw wanders somewhere more comfortable ...19:05
=== ayan_ is now known as ayan
infinitybjf: Is shankbot just lagging on updating https://bugs.launchpad.net/ubuntu/+source/linux-lts-backport-oneiric/+bug/1068230 or has something gone pear-shaped with the rebase promotion logic, perhaps?20:10
ubot2Launchpad bug 1068230 in Kernel SRU Workflow "linux-lts-backport-oneiric: 3.0.0-27.44~lucid1 -proposed tracker" [Undecided,In progress]20:10
hertoninfinity, it's waiting on oneiric linux bug to be promoted to updates20:11
infinityherton: Oh, that's the wrong logic, IMO.  It should just wait on the promotion tasks being set.20:11
infinityherton: Otherwise, I'll just pre-empt the bot and promote without it setting the tasks, cause I'm not going to do this in two passes. :P20:12
hertoninfinity, I can change that, my understanding was that we wanted that behaviour, at least in case there was some dependencies between the binaries, which isn't the case20:13
infinityherton: The only place where there's actually a dependency between binaries is lowlatency->master (which just got fixed to no longer be true in raring).20:13
infinityherton: But even then, if all the promotion tasks are set together, one can assume that the packages will also get promoted together.  I don't tend to make more work for myself when I don't have to. ;)20:14
hertonnp, I'll fix the bot later to just wait for confirmation of the tasks instead of the current behaviour20:14
infinityShiny, thanks.20:15
infinityWe can test it next cadence.  This time, I'll just preempt the bot and DTRT.20:15
hertonack20:15
jsalisburyrtg, ogasawara, This was just assigned to the canonical kernel team: bug 107886120:18
ubot2Launchpad bug 1078861 in ubuntu-nexus7 "Rebase kernel to the branch shipping with Android 4.2" [Medium,New] https://launchpad.net/bugs/107886120:18
ogasawarajsalisbury: I'll assume jani just opened that as a tracking bug and will do the work there20:19
jsalisburyogasawara, ahh, ok20:20
rtgogasawara, I'm having a look20:20
rtgogasawara, bjf: by the way, I just pushed the lts-backport-raring branch to precise20:21
ogasawarartg: ack20:21
bjfrtg, so does that imply there is an upload happening real-soon-now ? will this be happening in the x-swat ppa like quantal?20:47
rtgbjf, I'm assuming so, though the PPA name is disingenuous20:47
bjfmaybe there should be a "hardware enablement" ppa20:49
=== yofel_ is now known as yofel
rtgbjf, I'll upload later tonight and also send a note to bryceh asking about PPA naming. Maybe they want to start a whole new one.20:50
bjfrtg, ack21:03
* rtg -> EOD21:11
infinityherton: Do you know who's responsible for the regression-testing task on https://bugs.launchpad.net/ubuntu/+source/linux-armadaxp/+bug/1068573 ?21:55
ubot2Launchpad bug 1068573 in linux-armadaxp (Ubuntu) "linux-armadaxp: 3.5.0-1604.6 -proposed tracker" [Medium,In progress]21:55
infinityherton: Would be nice to get that one done and released before starting all over again with the new Q kernels in the PPA.21:56
hertoninfinity, not sure, but I think our QA was doing the testing on armadaxp kernels, bjf ikepanhc  ^21:58
infinity(Not that it's critical that it be released before we start on Q, it just gets a bit harder to keep it all straight when the flavours are out of sync)21:59
bjfinfinity, QA is doing it. i know they were running into some issues today with HW22:00

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!