[06:31] <ppisati> moin
=== smb` is now known as smb
[07:11] <smb> ppisati, morning (damn you early risers :-P)
[07:25]  * apw yawns
[07:26] <smb> apw, Someone pushed you out of your bed?
[07:28] <apw> smb, yeah the alarm (normal wakeup one0
[07:29] <smb> apw, Damn those things too. :) Though usually I would not expect you to be on irc that quickly after
[07:30] <apw> smb, different location, different pattern
[07:31] <smb> apw, Yeah, wrong birds outside and wrong bed below one
[07:31] <apw> heh
[07:34] <apw> bah i would need to upgrade my openvpn server all the way to saucy to get official ipv6 support; that sucks
[07:35] <smb> Wow, would have thought we had support for longer now, and I thought just to have spotted changes in P about v6 in ... something
[07:37] <apw> it has some 'ipv6' options in there, but actually if you arn't just using a TAP it is pretty hard
[07:37] <apw> well i guess unless something got backported i guess
[07:39] <apw> oh it might be 'using ipv6 for transport' is not supported until 2.3
[07:40] <smb> I tend to be not following ipv6 that closely as you do (due to slacking on my side and any providers I got)
=== fmasi_afk is now known as fmasi
=== fmasi is now known as fmasi_afk
=== fmasi_afk is now known as fmasi
[08:02] <apw> slackage in ipv6 seems to be an industry standard
[08:03] <apw> it is funny (to me) that my vps has had  ipv6 from day 1, and i have had it more than 5 years
=== fmasi is now known as fmasi_afk
=== fmasi_afk is now known as fmasi
[09:13] <ppisati> brb
=== brendand is now known as brendand_afk
=== brendand_afk is now known as brendand
=== fmasi is now known as fmasi_afk
=== fmasi_afk is now known as fmasi
[13:02] <henrix> kamal-away: bjf: sconklin: this bug seems to be a regression in raring: bug #1215513
[13:02] <ubot2`> Launchpad bug 1215513 in linux (Ubuntu) "System locks up, requires hard reset" [High,Incomplete] https://launchpad.net/bugs/1215513
[13:04]  * henrix -> lunch
[13:50] <sconklin> henrix: thanks
[13:51] <henrix> sconklin: in fact, the issue should be present in quantal as well. lets see if we can get the original bug reporter to test the kernels with the offending commit reversed
[13:58] <bjf> henrix, yes i was looking at that late yesterday
[14:08] <rtg> apw, the server dudes will likely be hassling us about bug #1218995 - you're kind of the expert in both topics
[14:08] <ubot2`> Launchpad bug 1218995 in linux (Ubuntu) "Hyper-V Synthetic Video Frame Buffer Driver not working" [Medium,Confirmed] https://launchpad.net/bugs/1218995
[14:14] <bjf> henrix, since it's a staging driver and one that folks can easily disable and live without until its fixed i'm inclined to identify the fix and get it into the next cycle rather than respinning kernels at the end of this cycle
[14:15] <bjf> henrix, if we can identify the fix (and it looks like we may have already) we'll have -proposed kernels next week with the possible fix
[14:16] <henrix> bjf: makes sense to me. it looks there's a fix upstream, but its a non-trivial backport. i'm taking a look at it ATM, but we may just revert the offending commit as well
[14:16] <bjf> henrix, ack
[14:16] <bjf> sconklin, ^ seem reasonable ?
[14:16] <henrix> bjf: we'll probably need to bring a few extra commits to backport the fix to 3.5 and 3.8. but i'm still looking at it (trying to reproduce here)
[14:17] <sconklin> bjf, henrix: yes, seems reasonable to go with a workaround and figure out how to really fix it in the next cycle
[14:19] <rtg> henrix, bjf: as a matter of distro kernel policy, staging drivers are "best effort". we can do whatever we want because I don't consider them subject to SRU (as long as we don't do something egregiously stupid)
[14:19] <bjf> rtg, right that's why i wasn't going to respin for this issue
[14:20] <rtg> ack
[14:20] <bjf> rtg, henrix, also why i'm thinking just revert the 2-line patch and move on
[14:20] <bjf> if that is the issue
[14:20] <rtg> bjf, what driver is it ?
[14:20] <henrix> rtg: zram
[14:20] <rtg> ah, that mess
=== kamal__ is now known as kamal
[14:25] <sconklin> rtg, bjf iirc there's talk of moving zram into mainline soonish
[14:26] <sconklin> fwiw
[14:26] <rtg> sconklin, yeah, but I think its had some serious work to get moved out of staging
[14:26] <rtg> I guess it depends on what kernel version we're talking about
[14:27] <sconklin> the only thing a search turned up is a story on phoronix, and we know how accurate that might be . . .
[14:55] <rtg> apw, did you notice this ? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/882147/comments/37
[14:55] <ubot2`> Launchpad bug 882147 in coreutils (Ubuntu) "overlayfs does not implement inotify interfaces correctly" [Undecided,In progress]
=== caribou_ is now known as Caribou
[15:27] <rtg> jsalisbury, can you help out Til on bug #1167301 ?
[15:27] <ubot2`> Launchpad bug 1167301 in linux (Ubuntu) "8086:0166 [ThinkPad Twist S230u 3347] REGRESSION: Mirroring display works only with 1024x768 (4:3) whereas my laptop has 1366x768 (16:9) & external monitor 1920x1080 (16:9)" [High,Incomplete] https://launchpad.net/bugs/1167301
[15:28] <jsalisbury> rtg, sure
=== fmasi is now known as fmasi_afk
[17:30] <smoser> rtg, what made you think udev at bug 1220918 ?
[17:30] <ubot2`> Launchpad bug 1220918 in linux (Ubuntu) "networking does not come up in cloud image on hyper-v" [High,Incomplete] https://launchpad.net/bugs/1220918
[17:30] <smoser> it isn't impossible, but seems unlikely to me.
[17:31] <rtg> smoser, because you can manually configure the network ? that implies the driver is working.
[17:31] <smoser> if you look at the boot log, 'ci-info' (from cloud-init) shows that the network interfaces is up.
[17:31] <smoser> and /etc/network/interfaces is 'auto eth0' and 'dhcp'.
=== fmasi_afk is now known as fmasi
[17:32] <smoser> so it would seem udev did its job of sending the network device added and ifup brought tried to dhcp, but the dhcp failed.
[17:33] <smoser> i suspected dhcp server was busted, this is reported to work if you just swap out a precise image.
[17:33] <rtg> smoser, ok, I didn't look that close. if dhcp is running on that interface then udev has likely done its job.
[17:33] <smoser> i dont know for sure that dhcp is running... but 'ifconfig' showed the interface up.
[17:34] <rtg> smoser, I wonder what would happen if you ran dhclient by hand ?
[17:34] <smoser> well as reported it worked.
[17:34] <smoser> but that was much later in boot.
[17:35] <rtg> smoser, what was the bug number again ? I'll go back and take a closer look.
[17:35] <smoser> https://launchpad.net/bugs/1220918
[17:35] <ubot2`> Launchpad bug 1220918 in linux (Ubuntu) "networking does not come up in cloud image on hyper-v" [High,Incomplete]
[17:36] <smoser> basically, they tried to boot an image, it failed, logged in, ran 'ubuntu-bug' (and created the attached data)
[17:36] <smoser> and then ran 'ifup eth0' and it worked.
[17:41] <smoser> jsalisbury, do you have an easy way to install raring kernel into saucy ?
[17:42] <rtg> smoser, well, the driver thinks it is up; "[   14.878905] hv_netvsc vmbus_0_12: Device MAC fa:16:3e:3f:96:eb link state up"
[17:42] <smoser> that woudl be another good reason to think its up :)
[17:42] <smoser> but 'ifconfig eth0 up' isn't "dhcp worked"
[17:42] <rtg> how about getting them to try the official release kernel ?
[17:42] <smoser> well 12.04 works. per report.
[17:42] <smoser> what is "official release kernel"
[17:43] <smoser> raring ?
[17:43] <rtg> 3.11.0-5 ?
[17:43] <smoser> 3.11.0-4.9
[17:43] <smoser> is what they used.
[17:44] <rtg> they are booting 3.11.0-4 which is an -rc7 kernel IIRC
[17:44] <smoser> well its what was in a cloud image built yesterday.
[17:44] <smoser> err. maybe 2 days ago.
[17:44] <rtg> hmm, freaking beta freeze ....
[17:44] <smoser> http://cloud-images.ubuntu.com/saucy/current/saucy-server-cloudimg-amd64.manifest
[17:45] <smoser> yeah, that is still in there today.
[17:45] <rtg> -5 should bubble up in another day or 2
=== fmasi is now known as fmasi_afk
[18:30]  * apw has had enough of reviewing xen, and calls it a day
[18:32]  * smb has had enough of being reviewed and does the same
[20:05] <jsalisbury> smoser, sorry missed your request.  You can download the Raring kernel from: https://launchpad.net/ubuntu/raring/+source/linux/3.8.0-30.44  
[20:05] <jsalisbury> smoser, and install it with dpkg
[20:06] <jsalisbury> smoser, unless you want to wait and test the 3.11.0-5 kernel first
[20:08] <rtg> kamal, looks like a 3.8 regression in bug #1167301 (see comment #57)
[20:08] <ubot2`> Launchpad bug 1167301 in linux (Ubuntu) "8086:0166 [ThinkPad Twist S230u 3347] REGRESSION: Mirroring display works only with 1024x768 (4:3) whereas my laptop has 1366x768 (16:9) & external monitor 1920x1080 (16:9)" [High,Confirmed] https://launchpad.net/bugs/1167301
[20:15] <kamal> rtg, looking at the code, I think the behavior would be the same even now in 3.11
[20:16] <rtg> kamal, I'm sure Til would be happy to verify that for you
[20:16] <kamal> "for me"   ;-)
[20:21] <kamal> rtg, fyi, he already confirmed that the problem still happens in 3.11 (comment #50)
[20:21] <rtg> kamal, ack
[20:23] <kamal> rtg, so this is effectively "just" an upstream drm bug.  I'm inclined to advise him to file a bug on kernel.org.
[20:24] <rtg> kamal, yep, but you might also consider reverting it from stable in the meantime
[20:25] <kamal> rtg, but then I'd be re-breaking whatever it was intended to fix in the first place (and its been in 3.8 stable since 3.8.8 -- ages and ages) ... and it'll appear in Saucy.   I don't think I'll revert it from 3.8 unless/until upstream agrees (which I bet they won't).
[20:26] <rtg> ok
[20:41] <kamal> jsalisbury, fyi regarding your comment #47 in bug 1167301 ...  The patch that Til posted there isn't a proposed fix -- that's the content of the committed patch that broke it
[20:41] <ubot2`> Launchpad bug 1167301 in linux (Ubuntu) "8086:0166 [ThinkPad Twist S230u 3347] REGRESSION: Mirroring display works only with 1024x768 (4:3) whereas my laptop has 1366x768 (16:9) & external monitor 1920x1080 (16:9)" [High,Confirmed] https://launchpad.net/bugs/1167301
[20:41] <jsalisbury> kamal, ahh, ok.
[20:41] <kamal> jsalisbury, specifically 196e077dc165a307efbd9e7569f81bbdbcf18f65
[20:44] <jsalisbury> kamal, thanks.  I'd yet to look close at the commit that caused the regression.
[20:45] <kamal> jsalisbury, np... until I looked at the commit, I misunderstood what he meant there too!