ChrisP1948 | Using this command sudo apt-get build-dep linux-image-3.13.0-35-generic which is found at https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel it downloaded 3.13.0-45 the newest instead of *-35. How do I get *-35? I need to bisect *-35 as it's the last good kernel before I stated having issues reported at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1402331 | 03:05 |
---|---|---|
ubot5 | Launchpad bug 1402331 in linux (Ubuntu) "System will periodically lockup with [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... render ring idle" [Medium,Incomplete] | 03:05 |
=== gerald is now known as Guest81008 | ||
apw | ChrisP1948 (N,BFTL), you are asking for the build-deps for linux, not for the source for that version... so you get the latest bits | 05:39 |
apw | as you are never there to hear the answer, and indeed are not reading backscroll, i am sure you will not see this either | 05:40 |
=== Diziet_ is now known as Diziet | ||
=== pgraner-afk is now known as pgraner | ||
shadeslayer | So, I'm using overlayfs and I'm seeing weird errors like failed to whiteout 'CMakeLists.txt | 15:25 |
shadeslayer | any ideas how I can investigate what's going wrong | 15:25 |
=== tyhicks` is now known as tyhicks | ||
=== smoser` is now known as smoser | ||
apw | shadeslayer, on what version of the kernel | 16:45 |
apw | shadeslayer, what exact string | 16:46 |
shadeslayer | apw: moment | 16:48 |
shadeslayer | apw: Linux rassilon 3.16.0-30-generic #40~14.04.1-Ubuntu SMP Thu Jan 15 17:43:14 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux | 16:49 |
shadeslayer | [ 1288.304277] overlayfs: ERROR - failed to whiteout 'CMakeLists.txt' | 16:49 |
shadeslayer | that's one of many strings it's failing on | 16:50 |
apw | shadeslayer, how full is the upper layer | 16:50 |
apw | shadeslayer, and is this on the livecd use case, or on a post install overlay | 16:50 |
shadeslayer | apw: it's on a AWS EC2 instance | 16:50 |
shadeslayer | I'm mounting a jenkins workspace dir inside a schroot using this script : http://paste.ubuntu.com/10056383/ | 16:51 |
shadeslayer | and : /dev/xvda1 493G 131G 341G 28% / < seems like there's plenty of space | 16:52 |
Free99 | Hello all, I have ubuntu 14.04 running on an HP Revolve 810 G2. Having an issue where the stylus moves only diagonally no matter where the stylus actually is on-screen. | 16:52 |
apw | shadeslayer, and what are you doing to the upper layer which is failing ... | 16:53 |
Free99 | I was able to fix the issue by compiling a kernel but editing a line in hid-input.c to force it to be relative vs absolute | 16:53 |
Free99 | downside is, it messes up X autodetection pretty badly | 16:53 |
apw | shadeslayer, and ... could you file a bug "ubuntu-bug linux" and shove all this detail in it, so it doesn't get flushed | 16:53 |
Free99 | any idea on how to do this fix on a regular ubuntu kernel? | 16:53 |
shadeslayer | apw: ok | 16:54 |
apw | shadeslayer, shove the bug # in here for me, so i can think about it | 16:54 |
shadeslayer | apw: I /think/ it's the underlying cause for http://dci.pangea.pub/job/plasma/job/kservice_source_unstable/13/consoleText | 16:55 |
apw | Free99, if you have a way to make it work like that, again a "ubuntu-bug linux" to get the h/w details, and put as much detail in it ... then we can look and see if we cna make it work for you and not break everyeone else | 16:55 |
Free99 | ok, sure thing apw | 16:55 |
Free99 | apw by the way I upgraded my kernel to utopic, but this still applied on 3.13-x as well | 17:03 |
Free99 | think that'll be an issue? | 17:03 |
apw | Free99, if it affects the one you are reporting against, no that is fine | 17:06 |
shadeslayer | apw: https://bugs.launchpad.net/ubuntu/+source/linux-lts-utopic/+bug/1418123 | 17:12 |
ubot5 | Launchpad bug 1418123 in linux-lts-utopic (Ubuntu) "overlayfs fails to whiteout CMakeLists.txt" [Undecided,New] | 17:12 |
shadeslayer | apw: do you need anything else? | 17:14 |
apw | shadeslayer, will update the bug if not | 17:16 |
shadeslayer | apw: cheers | 17:17 |
shadeslayer | I'll just redesign my schroot setup | 17:17 |
Free99 | apw, https://bugs.launchpad.net/ubuntu/+source/linux-lts-utopic/+bug/1418130 | 17:23 |
ubot5 | Launchpad bug 1418130 in linux-lts-utopic (Ubuntu) "Kernel doesn't respond to stylus properly" [Undecided,New] | 17:23 |
Free99 | apw thanks for the advice | 17:24 |
Free99 | question though: if I build something with DKMS, will it follow through kernel upgrades? | 17:24 |
Free99 | I ask because of https://bugs.launchpad.net/ubuntu/+source/linux-lts-utopic/+bug/1418134 | 17:24 |
ubot5 | Launchpad bug 1418134 in linux-lts-utopic (Ubuntu) "Alps TouchPad not recognized by kernel" [Undecided,New] | 17:24 |
apw | Free99, should do | 17:25 |
Free99 | apw you mean it ought to follow kernel upgrades, or that first bug report was detailed sufficiently? | 17:26 |
apw | Free99, i mean dkms would get rebuilt for each kernel upgrade | 17:27 |
apw | Free99, not looked at the bug yet | 17:27 |
Free99 | apw great, just trying to clarify what you meant :) | 17:28 |
Free99 | thanks again | 17:28 |
kfir | Hello, i'm developing a small kernel module and i'm getting the following error: module verification failed: signature and/or required key missing How can I bypass this for my module? | 21:11 |
blahdeblah | Hi all, is there a PPA or similar repo for tracking mainline builds? I'm currently on 3.19.0-031900rc3-generic trying to see if it solves https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1384342, and I'd prefer to keep tracking those builds for now. | 22:26 |
ubot5 | Launchpad bug 1384342 in linux (Ubuntu) "kernel messages intel_crtc_wait_for_pending_flips correlate to compiz hang" [High,Triaged] | 22:27 |
blahdeblah | I had a read through https://wiki.ubuntu.com/Kernel/MainlineBuilds and it seems to say that it's necessary to track http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D and manually install - is there an alternative? | 22:27 |
kees | so... anyone around familiar with UEFI -> kernel path? Does UEFI call startup_64 or startup_32 when loading the kernel? | 22:38 |
kees | I guess I mean shim and grub... | 22:40 |
apw | kees, it calls a specific efi entry doesn't it ? | 22:41 |
kees | apw: unclear to me. doesn't Ubuntu's UEFI thingy call shim, which calls grub, which calls the kernel? | 22:41 |
apw | kees, yeah, but it either calls "as normal" when not secure i think, and calls a special entry with boot services "available" | 22:42 |
kees | efi_pe_entry in the kernel seems to call startup_32. | 22:42 |
kees | oh hm, there's also efi64_stub_entry | 22:43 |
apw | kees, yeah there is two of 'em | 22:44 |
kees | I'm investigating a report of a corner case of a corner case... XD isn't enabled on some person's machine, and I'm looking at paths where that could happen. | 22:45 |
kees | it looks like any 64-bit kernel entry points skip fixing XD, since paging has already been started. | 22:46 |
kees | I wonder if 64-bit could drop to 32-bit temporarily, fix XD, rewrite the page tables, and switch back.... | 22:47 |
apw | ugg, nasty | 22:48 |
cristian_c | apw, I've collected the info in kernel.org format | 22:51 |
cristian_c | apw, as requested | 22:51 |
cristian_c | apw, I'd like to know if they are correct | 22:51 |
cristian_c | I ca paste them on pastebin | 22:52 |
cristian_c | *can | 23:02 |
mjg59 | kees: The answer is "it depends" | 23:18 |
mjg59 | kees: "linux" will call startup_32 | 23:19 |
mjg59 | "linuxefi" will call either the 32 or 64 bit offset in the stub, depending on the architecture of the firmware | 23:19 |
kees | mjg59: yeah, it sounds like I need to move this code into the common boot path | 23:24 |
kees | mjg59: and I don't think it'll require a 64->32->64 to do it. a TLB flush should DTRT... | 23:24 |
mjg59 | kees: So the current situation is that jumping into the 64 bit EFI stub skips XD? | 23:30 |
mjg59 | Or just startup_64? | 23:30 |
kees | mjg59: all the non-32-bit paths skip the bit of code I wrote to fix broken BIOSes that mask out XD support. | 23:32 |
kees | ("XD_DISABLE") | 23:32 |
kees | mjg59: so if you have a 64-bit boot on an especially crazy BIOS, you don't get NX support. :( | 23:32 |
mjg59 | kees: Oh, ok, so in the common case it's fine. That makes sense. | 23:33 |
kees | yeah, in the common case, the boot loader did all the right things when setting up paging. | 23:33 |
kees | but some seriously brain-dead boot firmware out there is setting XD_DISABLE _and_ booting 64-bit. O_o | 23:33 |
mjg59 | grub doesn't set up paging in the linuxefi case | 23:34 |
kees | in the 32-bit efi boot case? right. | 23:34 |
mjg59 | 32 or 64 | 23:34 |
mjg59 | That gets left up to the kernel | 23:34 |
kees | AIUI, 64-bit boot requires an identity mapped paging setup before starting the kernel. | 23:35 |
mjg59 | Either that's getting set up by the EFI boot code in the kernel, or that's what the firmware is setting up | 23:35 |
mjg59 | grub never touches page tables in the linuxefi case | 23:35 |
kees | right, if the boot firmware loads grub in 64-bit mode it must have set up identity mappings too | 23:36 |
kees | (i.e. grub doesn't need to) | 23:37 |
mjg59 | Yeah | 23:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!