[02:56] apw: Greetings, I have a small diff here http://paste.ubuntu.com/12189919/ but it would seem [02:57] that something else is not right yet. I believe I understand all the code you added and I would like to [02:59] chat when you and I can both be online [03:03] Ok I just tested again and it did not boot, hmmm. [03:07] Odd with quiet not on cmdline it fails but with it on cmdline it boots. Another hmmm. [03:09] I am not fully sure, but I can manually mount filesystem.squashfs and then exit busybox [03:10] when testing. Oh and so the patch works unless you remove quiet from boot param. To me that is [03:12] unrelated for now. But in busybox initramfs it does not allow me to mount multiple lowerdir stack [03:12] so I am not sure what is going on. Thanks for your help and I hope this information assists [03:12] somehow. [08:45] moin [08:46] ok that is odd, something wrong with the verbose code perhaps ... === _ruben_ is now known as _ruben === ghostcube_ is now known as ghostcube [09:42] apw: hi, it's been about 5 years since I set up my last git branch on http://kernel.ubuntu.com, and, as a result, I can't remember how to make a branch public, how pull requests work, etc. Is there a wiki page about it? [09:42] tseliot, though you could go through all that, you might just want to use a personal LP git repo now [09:43] tseliot, as we are meant to be using LP for such things in principle [09:43] apw: and could I send a pull request to a branch on http://kernel.ubuntu.com then? I need to update linux-firmware [09:44] tseliot, yep location is no barrier to git [09:44] git+ssh://tseliot@git.launchpad.net/~tseliot/ubuntu/+source/linux-firmware [09:45] or similar [09:45] you can have multiple repos there with the addition of +git/name should that make sense to you [09:45] apw: excellent. Thanks a lot! [09:46] tseliot, and obviously you have different ones for other source packages [09:49] right [12:11] tseliot, any progress on wily fglrx ? [12:11] rtg: no, sorry, I haven't looked into it yet but I will [12:12] I need to finish some other work first [12:12] tseliot, no pressure, but it is the last package that needs to work before we promote a 4.2 based kernel to -proposed [12:13] rtg: ok, I'll do it either later today or tomorrow [12:59] sforshee: hi, shall I send a pull request to wily or to master? [12:59] isn't master upstream ? [12:59] so it depends which you are proposing it for [13:00] tseliot, it should be against wily initially, then we'll have to do the same for trusty [13:00] to support the HWE kernel [13:00] oh, so master = upstream ? [13:00] ok [13:00] iirc yes i think he said that [13:01] then wily it is [13:01] sforshee | tseliot: btw you'll want to use the wily branch, master just tracks upstream [13:01] thought i saw that somewhere [13:01] I'm sure I missed it, my eyes are very tired these days [13:02] tseliot, :) [13:24] apw, sforshee: I've just made a pull request, if I screwed that up, just let me know and I'll try again ;) [13:46] tseliot: I haven't seen an email for your pull request yet [13:47] sforshee: how does that work? Sorry, I'm used to github when it comes to pull requests [13:49] bjf: Could you attach /var/log/cloud-init.log to https://bugs.launchpad.net/cloud-init/+bug/1488507 please? [13:49] Ubuntu bug 1488507 in cloud-init "Wily daily MAAS cloud image fails to fully install. " [Undecided,New] [13:49] tseliot: basically, push the thing you want pulled to your public repo, run 'git request-pull ...', then put the output it spews into an email [13:50] sforshee: oh, ok, shall I send the output to your email address and subscribe some other list? [13:51] Odd_Bloke, working on it [13:51] tseliot: send it to kernel-team@lists.ubuntu.com, you can send to me too if you want but I'll see it there [13:52] sforshee: ok, thanks [13:52] Odd_Bloke, done [13:53] bjf: Thanks. [13:54] bjf: Looks like we just/recently introduced that breakage; I've asked smoser to take a look. [13:54] Odd_Bloke, ack === ghostcube__ is now known as ghostcube [13:57] sforshee: ok, sent [14:04] bjf: smoser is on it. :) [14:18] apw, rtg: is this the repository with the kernel in the ppa that makes fglrx fail? git://kernel.ubuntu.com/ubuntu/unstable.git [14:22] tseliot, git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/wily master-next [14:23] tseliot, you can also get the kernel and headers from https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/ppa [14:27] rtg: ok, thanks [14:38] tjaalton: i915 question. If 4.2-rcX is broken, and 4.1 works (for external monitors), before bisection are there out of tree patches I should try looking at first? [14:40] drm-intel-nightly? is that the right tree or is it something else [14:48] arges: yeah seeing if drm-intel-nightly works would be the next step to see if its already fixed for 4.3 [14:48] Sarvatt: thanks, giving that a shot now. [14:49] rtg: I've found what broke fglrx on i386 (d5cea9b0af1509f170337ba8f47160d0699ff374). I'm testing my patch, and I plan to upload soon [14:49] tseliot, ack, thanks [14:57] Sarvatt: ok drm-intel-nightly seems to work, do i need to report anything to enusre that makes it into the wily/4.2 kernel? [14:59] arges: what's the bug? [14:59] and which intel generation [14:59] what 4.2 was broken? rc7 had some problems that got fixed in rc8 [15:00] tjaalton: oh i noticed on my x220 using the 4.2.0 wily kernel caused the external monitor to not display correctly. internal only mode worked fine [15:00] also check drm-intel-next, which is a bit old at this point but should be a good bisection point if nightly works [15:00] ah [15:01] it's been filed already, if you mean flickering? [15:01] yea the external montior was flickering when I set it to span mode. but internal only on the x220 panel worked fine [15:01] but drm-intel-nightly works as well as 4.1.0/wily kernel [15:02] https://bugs.launchpad.net/bugs/1421575 [15:02] Ubuntu bug 1421575 in xserver-xorg-video-intel (Ubuntu) "Desktop corruption when changing monitor config" [High,Triaged] [15:02] that's weird if wily kernel works, since this bug is on same hw and still broken on wily [15:03] yea I think my failure is slightly different. I see more stability than the entire screen looking like that in the bug [15:05] jsalisbury, don't we want the fix for LP: #1486146 in lts-utopic also ? [15:05] Launchpad bug 1486146 in linux (Ubuntu Wily) "recvfrom SYSCALL infinite loop/deadlock chewing 100% CPU (MSG_PEEK|MSG_WAITALL)" [High,In progress] https://launchpad.net/bugs/1486146 [15:12] bjf, yes, I can add the bug task in the bug [15:13] jsalisbury, i'll just make it so [15:13] bjf, great, thanks [15:21] apw, rtg: fixing that got me into a new GPL-only issue :/ http://paste.ubuntu.com/12193123/ [15:22] tseliot, yeah, I got about that far before I left on vacation (then completely forgot about it) [15:24] tseliot, commit 5e907bb0459399b0d1cc8d4c7e9f363a995b748a did that in 4.2-rc1 [15:24] rtg: right, although fglrx doesn't seem to use it directly [15:24] xsave uses it [15:25] apw: right, I only grepped xsave_state [15:25] sigh [15:27] tseliot, is there a way to have i386 do the same thing as amd64 (which appears to work) [15:32] rtg: it checks if static_cpu_has(X86_FEATURE_XSAVE), or if static_cpu_has(X86_FEATURE_FXSR), or it uses another solution if neither is true: http://paste.ubuntu.com/12193182/ [15:33] my eyes are leaving me already... [15:37] ** [15:37] ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting [15:37] ** [16:12] it sounds like it needs an rtg patch saying this limits other simple things like xsave to be _GPL [17:00] ## [17:00] ## Meeting starting now [17:00] ## [18:57] <_ruben> bah .. wished the linux kernel features would have better documentation .. am rather interesting in the vti stuff (virtual tunnel interface), but docs are *really* sparse .. and yes, this obviously not an ubuntu issue, but just needed semi-ontopic place to vent ;) [19:00] kernel documentation is for wimps :) [19:03] <_ruben> the only "docs" i found so far are the commit logs, which have some bits of usefull info in 'em, just not enough to make for a working poc :) [19:04] there are names in MAINTAINERS you could email [19:07] what do you acttually want to know [19:08] <_ruben> ohsix: how to setup a functional vti tunnel :) [19:08] it looks similar to all the tunnel/encap stuff [19:11] <_ruben> http://paste.ubuntu.com/12194539/ [19:12] <_ruben> this is almost direct copy of one of those commit logs [19:14] http://git.kernel.org/cgit/linux/kernel/git/shemminger/iproute2.git/tree/ip/link_vti.c [19:15] you know about 'ip' and 'tc' right === jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues Sep 1st, 2015 - 17:00 UTC || If you have a question just ask, and do wait around for an answer! If the question is should I file a bug for something, likely you can assume yes. || Channel logs: http://irclogs.ubuntu.com/ [22:44] hello, from #ubuntu, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/989191 was mentioned, and that it may have a bad 'fix released' status - anyone on the kernel team want to check if that's the case? [22:44] Ubuntu bug 989191 in linux (Ubuntu) "Asus Zenbook UX31E powers off on plugin in/out AC adapter" [Medium,Triaged] [22:45] or nevermind, TJ- already did :) [22:45] i sometimes forget people are in multiple chans :) [22:46] :) [22:46] I've added a commentary [22:46] Reasonably convinced it's not a linux bug [22:46] I spent a while working on that years ago [22:47] (y'all don't mind if I lurk here do you?) [22:48] There are several reports that the model works fine as far back as 12.04 [22:48] However, there are several confirmed reports that disconnecting the internal battery, and/or re-insulating its leads, solves the issue. That suggests a power starvation issue [22:51] My recollection is that whether it turned off or not depended on whether it was above a specific temperature when you pulled the power [22:52] Something changed the thermal trip level and it immediately powered off [22:54] Some users report acpi_osi="Microsoft Windows XP" solves it, which makes sense. mjg59 I suppose it's worth looking at the DSDT [22:55] Yeah, I don't have access to one any more [22:55] Oh, I was looking at the 31e, not the a [22:55] http://mjg59.dreamwidth.org/11750.html [22:56] I've just disassembled the one attached to the g.k.o report [22:56] s/g.k.o/b.k.o/ [22:57] I'll ask our user to dump the ACPI once he's fixed the corrupted file-systems