| === cpaelzer__ is now known as cpaelzer | ||
| === himcesjf_ is now known as him-cesjf | ||
| derjohn | Hi, is there anyone aldready working on fixing the PPA builds? "eoan-amd64: chroot not found ( chroot:bionic-amd64" seems to block all architecture kernel builds. Or do I need to report it? | 12:16 |
|---|---|---|
| === cpaelzer__ is now known as cpaelzer | ||
| cjwatson | derjohn: Do you have a link to a failure? | 12:24 |
| cjwatson | Not sure from that whether it's an infrastructure-level problem or something specific to kernel builds | 12:24 |
| mamarley | cjwatson: https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.1.7/ | 12:32 |
| cjwatson | Oh right, "PPA" | 12:36 |
| cjwatson | Not my problem then :-) | 12:36 |
| cjwatson | apw: ^- maybe? | 12:36 |
| apw | derjohn, you need to report it, to me | 12:46 |
| derjohn | apw THX ! The current kernel don't build, see https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.1.7/ (as cjwatson already showed). | 13:06 |
| derjohn | apw, Should I report it on launchpad or so? if so, which package !?!? | 13:07 |
| apw | derjohn, count it reported | 13:11 |
| TJ- | Has anyone heard of invisible memory-leak issues due to PCIE-AER faults? I'm helping a user that has a system that 'eats' 5GB of RAM in a day invisibly, and the only real clue is they need "pci=noaer" to avoid logs being overwhelmed with AER reports. I've asked them to remove noaer to find out what the reports are, but wondering if with it disabled the kernel could be using up memory collecting the | 13:11 |
| TJ- | reports even when they're not logged. | 13:11 |
| derjohn | apw, :thumbs: yeah ! Good to know. I has always struggles to find the right place to report .... I am using the kernels in out production relatively early .... | 13:12 |
| apw | derjohn, not that using those i production is a very good idead; but hey | 13:12 |
| TJ- | Also, I was checking on CONFIG_DEBUG_KMEMLEAK but we seem to have CONFIG_HAVE_DEBUG_KMEMLEAK=y but there is /no/ kernel code relying on that, and the actual setting is: "# CONFIG_DEBUG_KMEMLEAK is not set" | 13:13 |
| apw | sforshee, ^ | 13:14 |
| apw | TJ-, not heard of anything like the aer thing, but if there was going to be a bug in freeing an incoming message like that it would be when turning them off from teh command line which noone would do | 13:15 |
| sforshee | TJ-: enabling CONFIG_DEBUG_KMEMLEAK adds overhead to memory allocations, it seems to me that this is the sort of thing a developer turns on to debug memory leaks and not an option for a distro kernel to enable | 13:18 |
| TJ- | apw: right, user has pci=noaer but the system is losing memory rapidly (6GB overnight). I'm getitng them to create a bug. Apparently Windows 10 doesn't have this problem, so I think we have a problem in the PCI sub-system somewhere (Windows isn't losing memory or reporting AERs at least) | 13:18 |
| apw | TJ-, and not reporting them might involve recieving them and dumping them immediatly | 13:19 |
| TJ- | sforshee: I know, my point is that in looking at what we have that set to I found "debian.master/config/config.common.ubuntu:CONFIG_HAVE_DEBUG_KMEMLEAK=y" but there is nothing in-kernel I can find that uses that | 13:19 |
| sforshee | TJ-: those HAVE_FOO sorts of options are generally things which are set to make another option available for selection | 13:20 |
| sforshee | so if your arch or whatever doesn't set CONFIG_HAVE_DEBUG_KMEMLEAK then you won't be presented with the CONFIG_DEBUG_KMEMLEAK option | 13:20 |
| TJ- | apw: That's what I would imagine; it's a weird one here, but the only clue does seem to be these AERs (all measures of memory usage just seem to indicate memory is 'used' but cannot account anywhere for it. I had the user just boot to multi-user.target overnight, and in the morning it had eaten memory :) | 13:20 |
| TJ- | sforshee: right, but my point is I cannot find anything but the config file itself testing that value | 13:21 |
| apw | testing the HAVE_ version ? | 13:21 |
| apw | that would be right | 13:21 |
| sforshee | TJ-: that's exactly the point. The architecture selects HAVE_FOO, then if it's set you get prompted whether or not to set the CONFIG_FOO option | 13:22 |
| sforshee | only CONFIG_FOO affects the code that's built, HAVE_FOO just controls whether or not you get the chance to select CONFIG_FOO | 13:22 |
| TJ- | what I mean is, there's nothing like "drivers/net/dsa/Kconfig: depends on HAVE_NET_DSA" , no "depends on HAVE_DEBUG_KMEMLEAK" which confused me :) | 13:23 |
| TJ- | sorry for going on a tagent; this only came up because it confused me as to the state of KMEMLEAK :) | 13:24 |
| sforshee | TJ-: lib/Kconfig.debug | 13:24 |
| sforshee | config DEBUG_KMEMLEAK | 13:24 |
| sforshee | depends on DEBUG_KERNEL && HAVE_DEBUG_KMEMLEAK | 13:24 |
| TJ- | sforshee: doh! thank-you, I need to sleep more and work overnight less! I was doing "git grep CONFGI_HAVE_DEBUG_KMEMLEAK" !! Sorry | 13:25 |
| sforshee | no worries, happens to all of us | 13:26 |
| TJ- | sforshee: anyhow, upshot is, we'll need to build a custom kernel with DEBUG_KMEMLEAK enabled so the user can grab more info on this | 13:26 |
| TJ- | I'm having them check the windows event-logs to see if it is receiving AERs as well; if it is it isn't suffering vanishing memory | 13:28 |
| === himcesjf_ is now known as him-cesjf | ||
| derjohn | apw, Thx for fixing the PPA builds! | 20:54 |
| TJ- | Any chance of getting this ACPI ID added to enable a touchpad? Bug #1831710 | 21:15 |
| ubot5 | bug 1831710 in linux-signed-hwe (Ubuntu) "Touchpad not working (Lenevo Ideapad 330 series)" [Undecided,New] https://launchpad.net/bugs/1831710 | 21:15 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!