| === tinoco is now known as inaddy | ||
| ppisati | cking: ./stress-ng --aggressive -a0 --maximize --metrics-brief | 14:52 |
|---|---|---|
| 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:53 |
| ppisati | cking: stress-ng --aggressive --sequential 0 --maximize --metrics-brief | 14:55 |
| cking | yep, the latter is good :-) | 14:56 |
| 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:09 |
| 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:12 |
| 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:13 |
| 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:14 |
| smoser | nice | 15:20 |
| smoser | apw, can you help me in ubuntu-release then ? | 15:20 |
| apw | smoser, what does your fix fix ? | 15:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| smoser | apw, i dont know that the kernel ever could actually mount vfat without the nls module. | 15:45 |
| 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:46 |
| apw | the majority of those are likely bios made | 15:47 |
| smoser | apw, well, the original change, that i put back in included | 15:49 |
| smoser | vfat nls_cp437 nls_iso8859-1 | 15:49 |
| 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:50 |
| 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 | 15:51 |
| apw | smoser, migrated | 16:46 |
| smoser | apw, thanks. | 16:46 |
| 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:58 |
| 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. | 16:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| webdaford | just confirmed 15.10 | 17:04 |
| 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:05 |
| 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:06 |
| 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:08 |
| webdaford | any suggestions on what to google so I can find instructions on how to accomplish that? | 17:09 |
| * apw goes see if initramfs-tools will build in wily | 17:10 | |
| webdaford | I did try an install of 16.04 (latest), but that failed to boot as well | 17:11 |
| 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:12 |
| 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:13 |
| lamont | apw: will do | 17:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| jsalisbury | lamont, the bad kernel would be better, since it will collect dmesg, etc. | 17:19 |
| lamont | FINE | 17:19 |
| lamont | brb | 17:20 |
| jsalisbury | lamont, thanks | 17:20 |
| 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:24 |
| apw | webdaford, when that finishes buildnig you could try adding that PPA and see if it works better for you | 17:25 |
| 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:26 | |
| jsalisbury | lamont, thanks for opening the bug, I'll give it a review | 17:27 |
| webdaford | apw, many thanks | 17:28 |
| 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:31 |
| apw | webdaford, any other machines? you could put the .deb's on a memory stick | 17:33 |
| webdaford | yes, this one (wily) | 17:33 |
| webdaford | I see them on the web site | 17:35 |
| webdaford | newbie question: is it possible to download the deb's from the ppa website? | 17:37 |
| lamont | jsalisbury: done | 17:38 |
| jsalisbury | lamont, thanks | 17:39 |
| lamont | thanks for jumping on it | 17:39 |
| 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:40 |
| 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:41 | |
| 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:42 |
| 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:43 |
| lamont | jsalisbury: any benefit to me trying anything in between those kernels (that's already packaged, that is) | 17:54 |
| 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:55 |
| lamont | otoh, 4.4.0-1.15 seems to have left the building | 17:59 |
| 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:00 |
| 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:02 |
| lamont | jsalisbury: http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.4-rc2-wily/ looks very boring and usleess | 18:14 |
| 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:15 |
| 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:16 |
| lamont | ack | 18:17 |
| * lamont will happily play the "clueless" card rather than look at the logs | 18:17 | |
| apw | webdaford, nope that is one of the source packages | 18:28 |
| 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:29 |
| * lamont reboots a few times.. brb | 18:32 | |
| 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:44 |
| apw | tjaalton, what version of initramfs-tools | 18:45 |
| tjaalton | 0.122ubuntu1 | 18:45 |
| tjaalton | I see it's in hook-functions under block) | 18:46 |
| apw | tjaalton, can you like: zcat /boot/initrd... | cpio -it | pastebinit | 18:46 |
| 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:47 |
| 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:48 |
| apw | break=bottom or something and see if you have a/ | 18:49 |
| apw | yeah a rebuild has the drivers at least | 18:49 |
| tjaalton | so mainline 4.4.0 works, -2/-4 doesn't. rebuilt the mainline initrd so it's not due to that | 18:51 |
| 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:54 |
| 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:55 |
| tjaalton | apw: ha, unlocking root works without splash | 18:56 |
| 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:57 |
| tjaalton | it was all my fault.. the initrd doesn't include i915_bpo (again) :) | 18:59 |
| 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:00 |
| 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:01 | |
| lamont | jsalisbury: i'll poke you when I have an update... expect ~20+ hours from now | 19:02 |
| jsalisbury | lamont, thanks | 19:02 |
| tjaalton | apw: oh right I meant our mainline and not vivid/trusty | 19:03 |
| tjaalton | as in the current tip | 19:03 |
| apw | tjaalton, but yes, ubuntu/ in xenial doesn't have *_bpo ... | 19:04 |
| tjaalton | yep | 19:04 |
| apw | tjaalton, surely by now that must be upstream ... | 19:22 |
| lamont | jsalisbury: for further giggles, rc1 is missing kernels, too | 19:57 |
| lamont | I'll test rc3 once I get code happy | 19:57 |
| apw | lamont, is that 4.4-rc1/2 ? | 19:58 |
| apw | lamont, if so check out the +cod1 variants | 19:58 |
| tjaalton | apw: what is? | 20:05 |
| tjaalton | the old i915_bpo bits are, but now we need newer crap for KBL and BXT and tbh for SKL still.. | 20:14 |
| lamont | apw: it is. will do | 21:16 |
| === Noskcaj_ is now known as Noskcaj | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!