=== tinoco is now known as inaddy
[14:52] <ppisati> cking: ./stress-ng --aggressive -a0 --maximize --metrics-brief
[14:53] <ppisati> cking: http://pastebin.ubuntu.com/15002159/
[14:53] <ppisati> cking: https://launchpad.net/~p-pisati/+archive/ubuntu/embedded/+files/linux-image-4.4.0-1004-snapdragon_4.4.0-1004.4_arm64.deb
[14:55] <ppisati> cking: stress-ng --aggressive --sequential 0 --maximize --metrics-brief
[14:56] <cking> yep, the latter is good :-)
[15:09] <smoser> apw, around ?
[15:09] <smoser> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#initramfs-tools
[15:09] <smoser> i know you poked at that some. there is one marked 'Regression'
[15:09] <smoser> i need that into archive with that change i made. what can i do to help?
[15:12] <apw> smoser, the ppc64el linux regression is an linux realted issue and not related to initramfs-tools
[15:12] <apw> smoser, i asked for a retry as it is a intermittent (separatly reported)
[15:12] <apw> smoser, buut with the perl transition dropping 2k tests on the adt queue it will take a fair while to even start
[15:13] <apw> smoser, if you want to ask for it to be waved trhough based on that, i would support that
[15:13] <smoser> in the theory that we'd put it in and then deal with it if it fell out
[15:14] <apw> i know for sure the issue in that test is there with older initamgs-tools, it is not new
[15:14] <apw> it appears about 1/3 linux tests on ppc64el regardless of trigger
[15:20] <smoser> nice
[15:20] <smoser> apw, can you help me in ubuntu-release then ?
[15:26] <apw> smoser, what does your fix fix ?
[15:27] <smoser> the last merge from debian broke mounting of vfat filesystems
[15:27] <smoser> as vfat depends on nls_ and nls_somesillyname got dropped from the list of modules to include.
[15:27] <smoser> and it wasn't automatically included because there is no 'vfat' module (as we build that in... not sure why we do that)
[15:28] <smoser> ie, 'vfat' is listed, and if it were a module it would have read modules.dep and pulled in the others (i think)
[15:28] <smoser> but because its not a module, it doesn't know to get the other things.
[15:28] <apw> vfat is built in to handle efi and the like, so you are sure you can write your kernel to where it needs to be
[15:28] <smoser> not sure though if nls_*  is explicilty a dependecny or not.
[15:28] <smoser> then maybe you should also build in the nls things
[15:28] <smoser> because you can't actually mount vfat
[15:28] <apw> that is entirely possible
[15:29] <smoser> https://bugs.launchpad.net/curtin/+bug/1540522
[15:29] <ubot5`> Launchpad bug 1540522 in initramfs-tools (Ubuntu) "vfat support broken in initramfs" [High,Confirmed]
[15:29] <apw> smoser, ok request made, you could chip in
[15:45] <smoser> apw,  i dont know that the kernel ever could actually mount vfat without the nls module.
[15:46] <smoser> really odd.... at least it can't do that for any vfat authored by a modern (probably anything ever produced by a Ubuntu mkfs.vfat) 
[15:46] <smoser> modern mkfs.vfat
[15:46] <apw> smoser, perhaps we use a different charset by default, 437 rings a bell
[15:47] <apw> the majority of those are likely bios made
[15:49] <smoser> apw, well, the original change, that i put back in included
[15:49] <smoser>  vfat nls_cp437 nls_iso8859-1
[15:50] <apw> right, but i think cp437 is builtin, which makes vfat useful
[15:50] <smoser> yeah. you're right.
[15:50] <apw> (in a limited set of cases)
[15:51] <smoser> so vfat would not actually depend on those anyway.
[15:51] <smoser> right ? (from a modules.dep perspective)
[15:51] <apw> likely not
[15:51] <apw> cirtainly it owuld not pull them all in
[16:46] <apw> smoser, migrated
[16:46] <smoser> apw,  thanks.
[16:58] <webdaford> I'm having trouble figuring out how to report a configuration problem in the latest 4.4.1 kernel builds.  I'll describe below.
[16:59] <webdaford> I have a new laptop that only has an NVME SSD drive.  The ubuntu supplied 4.4.1 kernel is configured to add support for NVME block devices as a modulue.
[16:59] <webdaford> CONFIG_BLK_DEV_NVME=m
[16:59] <apw> webdaford, yes
[16:59] <webdaford> I can install, but when I boot, the drive can't be accessed because there's not support.
[17:00] <webdaford> I've built my own 4.4.1 kernel and am able to boot (with other issues) by setting CONFIG_BLK_DEV_NVME=y
[17:00] <apw> webdaford, it depends which series you are running, as mainline renamed hte NVME drivers and so initramfs-tools needed to change to support them
[17:00] <webdaford> I poked around trying to figure out how to report this, but without much success.
[17:01] <apw> webdaford, it is already reported, and indeed fixed in xenial i beleive
[17:01] <webdaford> I've taken the configuration from the daily (yesterday) build ubuntu 4.4.1 kernel and am building with the module included.  I expect it to boot. 
[17:02] <webdaford> hmm, not from yesterday
[17:02] <apw> webdaford, it is not the kernel that changes to fix the issue, it is initramfs-tools
[17:02] <webdaford> ah.  (I'm new :-)  any suggestions on how to proceed?
[17:02] <apw> which version of ubuntu do you have installed
[17:03] <webdaford> I've played around a bit, I think the latest I can boot (with problems) is 15.10, I was trying to go to the 4.4.1 kernel to get suport for a wireless card.
[17:04] <webdaford> just confirmed 15.10
[17:05] <apw> support in 4.4.1 only or in any 4.4 ?
[17:05] <apw> only xenial has initramfs-tools fixes for that as yet, as 4.4 isn't a supported kenrle in wily
[17:05] <webdaford> I have a new Dell xps13 (9350) with a new Broadcom wifi card, I believe support is in 4.4.*
[17:06] <webdaford> I've tripped across a few blogs with people running 15.10 and upgrading to the latest ubuntu kernels and having success.
[17:06] <apw> webdaford, yep in principle it works, because you have an NVME root, you need to upgrade
[17:06] <apw> initramfs-tools as well
[17:06] <webdaford> hint?
[17:08] <apw> erm, if you have a 4.4* kernel on 15.10 you need the initramfs-tools from xenial in order for the initramfs to find your root disk
[17:09] <webdaford> any suggestions on what to google so I can find instructions on how to accomplish that?
[17:10]  * apw goes see if initramfs-tools will build in wily
[17:11] <webdaford> I did try an install of 16.04 (latest), but that failed to boot as well
[17:12] <lamont> 4.4.0-2 hates my second display
[17:12] <lamont> 4.3.0-7 and earlier find it just fine
[17:12] <lamont> 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset Integrated Graphics Controller (rev 03)
[17:12] <lamont> 00:02.1 Display controller: Intel Corporation 4 Series Chipset Integrated Graphics Controller (rev 03)
[17:12] <lamont> only one of those is there in 4.4.0-2... known?
[17:13] <apw> webdaford, would depend when the image was produced, the fix for initramfs-tools is prety fresh
[17:13] <apw> lamont, you have two intel display controllers in the same machine ?
[17:13] <lamont> mebbe
[17:13] <apw> lamont, i'd say file a bug with the full dmesg from working and not working kernels, and jsalisbury can perhaps look at the delta
[17:14] <lamont> apw: will do
[17:15] <webdaford> checking it (16.04) was built yesterday.  I got it from here: http://cdimage.ubuntu.com/daily-live/current/
[17:15] <jsalisbury> apw lamont I can review
[17:15] <apw> jsalisbury, thanks
[17:15] <lamont> jsalisbury: it's 2 connectors on the MB - dvi and vga
[17:16] <lamont> 4.4 hates the dvi
[17:16] <lamont> jsalisbury: I'm going to give you kern.log, rather than rebooting the broken kernel
[17:17] <webdaford> I'll try again with today's 16.04
[17:17] <jsalisbury> lamont, kern.log from the broken kernel?
[17:17] <lamont> both kernels
[17:18] <lamont> you'll love them - they're full of network csum fault spam too
[17:18] <jsalisbury> lamont, ok.  can you also post the apport data to the bug?  It should collect it automatically, depending on how you open the ub
[17:18] <lamont> jsalisbury: sure... do you care which kernel is running when I file it?
[17:19] <jsalisbury> lamont, the bad kernel would be better, since it will collect dmesg, etc.
[17:19] <lamont> FINE
[17:20] <lamont> brb
[17:20] <jsalisbury> lamont, thanks
[17:24] <apw> webdaford, ok i've just backported the NVME fixes to wily and uploaded a test package to my ppa:apw/ubuntu/initramfs-tools (https://launchpad.net/~apw/+archive/ubuntu/initramfs-tools/)
[17:25] <apw> webdaford, when that finishes buildnig you could try adding that PPA and see if it works better for you
[17:26] <lamont> jsalisbury: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1543683
[17:26] <ubot5`> Launchpad bug 1543683 in linux (Ubuntu) "Fails to detect (second) display" [Undecided,New]
[17:26]  * lamont reboots back to 4.3.0-7, to restore his user experience.
[17:27] <jsalisbury> lamont, thanks for opening the bug, I'll give it a review
[17:28] <webdaford> apw, many thanks
[17:31] <jsalisbury> lamont, can you post 'lspci -vvvnn' on the good kernel and post it in the bug?  
[17:31] <webdaford> apw, to make life difficult, my laptop has no network access....that's what I'm trying to acomplish with the 4.4.* kernel update.  Hmm..
[17:33] <apw> webdaford, any other machines? you could put the .deb's on a memory stick
[17:33] <webdaford> yes, this one (wily)
[17:35] <webdaford> I see them on the web site
[17:37] <webdaford> newbie question: is it possible to download the deb's from the ppa website?
[17:38] <lamont> jsalisbury: done
[17:39] <jsalisbury> lamont, thanks
[17:39] <lamont> thanks for jumping on it
[17:40] <webdaford> I found the tar file for initramfs-tools_0.122ubuntu3.tar.xz, is that the one I want?
[17:40] <jsalisbury> lamont, I'll review the diffs for the two kernels, but we may end up having to perform kernel bisect.  That would require testing about 7-10 kernels
[17:40] <lamont> jsalisbury: oh, joy...
[17:41] <lamont> worst case, gimme a pointer to the tree, and the good/bad checkins, and remind me of the joy of building, and I'll be "happy" to drive it.
[17:41] <lamont> :/
[17:41]  * lamont hasn't built his own kernel in a looong time.
[17:42] <jsalisbury> lamont, I don't mind building the kernels for you.  I have access to a nice build machine that can do in 20 minutes or so
[17:43] <lamont> jsalisbury: wfm
[17:43] <lamont> I might even break out the laptop for the testing time
[17:43] <jsalisbury> lamont, it's testing the kernels that takes the time.  Let me first take a look at the i915 changes and see if anything sticks out between the kernels
[17:54] <lamont> jsalisbury: any benefit to me trying anything in between those kernels (that's already packaged, that is)
[17:55] <jsalisbury> lamont, sure.  There are over 400 i915 changes between those two kernel versions, we probably want to narrow it down more.  I'll post some links to kernels in the bug
[17:55] <lamont> I was figuring on just bysecting the fullpubhgistory
[17:59] <lamont> otoh, 4.4.0-1.15 seems to have left the building
[18:00] <jsalisbury> lamont, it would be best to also test the upstream kernels during the bisect.  that will tell us if the bug is Ubuntu specific.  I'm writing up a comment to the bug now.
[18:00] <lamont> cool
[18:02] <lamont> jsalisbury: I may need to be a total slacker - need to write some code for a demo that happens tomorrow...  so I may be 24 hours laggy :(
[18:02] <jsalisbury> lamont, ok, posted.  It's a pain to bisect, but it's usually the best approach with so many changes.
[18:02] <jsalisbury> lamont, that's no problem at all, as I usually multi task as well :-)
[18:14] <lamont> jsalisbury: http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.4-rc2-wily/ looks very boring and usleess
[18:15] <lamont> (just fyi)
[18:15] <lamont> jsalisbury: I'm assuming that a simple "good/bad" indicator is sufficient, and that you don't care too much about capturing the various bits
[18:16] <jsalisbury> lamont, yes
[18:16] <jsalisbury> lamont, once we know the last good and first bad, we can start the bisect to identify the commit.  Or it may just stick out in the git logs
[18:17] <lamont> ack
[18:17]  * lamont will happily play the "clueless" card rather than look at the logs
[18:28] <apw> webdaford, nope that is one of the source packages
[18:29] <apw> webdaford, assuming you are 64 bit, then you want th two .debs on: https://launchpad.net/~apw/+archive/ubuntu/initramfs-tools/+build/8989012
[18:32]  * lamont reboots a few times.. brb
[18:44] <tjaalton> apw: the nvme-not-in-initrd seems not fixed
[18:44] <apw> tjaalton, hrmm
[18:44] <tjaalton> I just installed a build of 4.4.0-4
[18:44] <apw> what is a man to do, testing results seem to mean nothing
[18:44] <tjaalton> and it fails to boot like before
[18:44] <tjaalton> heh
[18:45] <apw> tjaalton, what version of initramfs-tools
[18:45] <tjaalton> 0.122ubuntu1
[18:46] <tjaalton> I see it's in hook-functions under block)
[18:46] <apw> tjaalton, can you like: zcat /boot/initrd... | cpio -it | pastebinit
[18:47] <tjaalton> or update-initramfs -v?
[18:47] <tjaalton> I have both
[18:47] <apw> lib/modules/4.4.0-2-generic/kernel/drivers/nvme
[18:47] <apw> lib/modules/4.4.0-2-generic/kernel/drivers/nvme/host
[18:47] <apw> lib/modules/4.4.0-2-generic/kernel/drivers/nvme/host/nvme.ko
[18:47] <apw> my initramfs has the nvme drivers in it
[18:47] <tjaalton> hmmm
[18:47] <apw> which is a 0.122ubuntu1 version i believe
[18:47] <tjaalton> ok then, sorry
[18:48] <tjaalton> I see them too now :P
[18:48]  * apw regenerates
[18:48] <tjaalton> but I don't understand why cryptsetup fails again
[18:48] <tjaalton> guess I just need to debug it further..
[18:48] <apw> tjaalton, well its a big merge, somethign else could be broken pretty easily
[18:48] <tjaalton> last time the reason was nvme missing
[18:49] <apw> break=bottom or something and see if you have a/
[18:49] <apw> yeah a rebuild has the drivers at least
[18:51] <tjaalton> so mainline 4.4.0 works, -2/-4 doesn't. rebuilt the mainline initrd so it's not due to that
[18:54] <apw> tjaalton, so the initramfs-tools bits must be good if mainline 440 works
[18:54] <tjaalton> yeah
[18:54] <tjaalton> jumped the gun there, it's something else
[18:55] <apw> tjaalton, np, its good to know we're making some kind of progess
[18:55] <lamont> jsalisbury: bug updated (rc4 is fail, rc2 is missing)
[18:56] <tjaalton> apw: ha, unlocking root works without splash
[18:57] <tjaalton> actually
[18:57] <lamont> jsalisbury: and with that, I'm done rebooting until I get my code finished
[18:57] <tjaalton> aaah of course
[18:59] <tjaalton> it was all my fault.. the initrd doesn't include i915_bpo (again) :)
[19:00] <lamont> tjaalton: I hate days like thyat
[19:00] <jsalisbury> lamont, thanks for the testing.  We should rc3 or rc1 next.  I can post links in the bug
[19:00] <apw> tjaalton, oh how did that fall out, did i do that /
[19:00] <tjaalton> so the splash pwd dialog doesn't work, bah
[19:00] <apw> ?
[19:00] <apw> tjaalton, i could believe i lost something
[19:00] <tjaalton> apw: I'm not sure if it was added to mainline
[19:00] <tjaalton> but yeah that should be kept as it's kinda coming back every year :)
[19:01] <apw> mainline wouldn't have more than ur stuff
[19:01] <apw> our stuff
[19:01]  * lamont bets he can guess what they are. :p
[19:02] <lamont> jsalisbury: i'll poke you when I have an update... expect ~20+ hours from now
[19:02] <jsalisbury> lamont, thanks
[19:03] <tjaalton> apw: oh right I meant our mainline and not vivid/trusty
[19:03] <tjaalton> as in the current tip
[19:04] <apw> tjaalton, but yes, ubuntu/ in xenial doesn't have *_bpo ...
[19:04] <tjaalton> yep
[19:22] <apw> tjaalton, surely by now that must be upstream ...
[19:57] <lamont> jsalisbury: for further giggles, rc1 is missing kernels, too
[19:57] <lamont> I'll test rc3 once I get code happy
[19:58] <apw> lamont, is that 4.4-rc1/2 ?
[19:58] <apw> lamont, if so check out the +cod1 variants
[20:05] <tjaalton> apw: what is?
[20:14] <tjaalton> the old i915_bpo bits are, but now we need newer crap for KBL and BXT and tbh for SKL still..
[21:16] <lamont> apw: it is.  will do
=== Noskcaj_ is now known as Noskcaj