There's a number of usb controllers that are common yet aren't
contained in the host directory. Include these for generic host.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
The phy and power modules are needed by some of the recent ARM
devices that have appeared like CHIP and some exynos devices.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Specifying a different kernel module directory with --kmoddir would
result in the same directory being the destination directory.
Strip everything before the "/lib/modules" for the destination dir.
https://github.com/dracutdevs/dracut/issues/194
The default output filename for --uefi is
<EFI>/EFI/Linux/linux-$kernel$-<MACHINE_ID>-<BUILD_ID>.efi.
<EFI> might be /efi, /boot or /boot/efi depending on where the ESP partition
is mounted. The <BUILD_ID> is taken from BUILD_ID in /usr/lib/os-release or
if it exists /etc/os-release and is left out, if BUILD_ID is non-existant or
empty.
Also a new option --no-machineid was added, which affects the default output
filename of --uefi and will discard the <MACHINE_ID> part.
Some docs claimed that values in certain config files would be
overwritten, when they would actually be overridden.
Override: a file is not modified but its contents are superseded by
something else. (configurations set in
/etc/dracut.conf.d/*.conf override configurations set in
/etc/dracut.conf)
Overwrite: a file is modified or its contents replaced by an action
(use dracut --force to overwrite the existing initramfs)
Bug related to this issue: https://bugzilla.redhat.com/show_bug.cgi?id=1360131
Now dracut only attempts to copy GlobalKnownHostsFile while generating kdump's
initramfs. This method will cause kdump's failure if users set customized
UserKnownHostsFile in /etc/ssh/ssh_config. This patch simply attempts to copy
those files too while going through /etc/ssh/ssh_config. Note that we need to
make sure ~/foo will be copied as /root/foo in kdump's initramfs.
Extend "rd.memdebug" to "4", and "make_trace_mem" to "4+:komem".
Add new "cleanup_trace_mem" to cleanup the trace if active.
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
The current method for memory debug is to use "rd.memdebug=[0-3]",
it is not enough for debugging kernel modules. For example, when we
want to find out which kernel module consumes a large amount of memory,
"rd.memdebug=[0-3]" won't help too much.
A better way is needed to achieve this requirement, this is useful for
kdump OOM debugging.
The principle of this patch is to use kernel trace to track slab and
buddy allocation calls during kernel module loading(module_init), thus
we can analyze all the trace data and get the total memory consumption.
As for large slab allocation, it will probably fall into buddy allocation,
thus tracing "mm_page_alloc" alone should be enough for the purpose(this
saves quite some trace buffer memory, also large free is quite unlikey
during module loading, we neglect those memory free events).
The trace events include memory calls under "tracing/events/":
kmem/mm_page_alloc
We also inpect the following events to detect the module loading:
module/module_load
module/module_put
Since we use filters to trace events, the final trace data size won't
be too big. Users can adjust the trace buffer size via "trace_buf_size"
kernel boot command line as needed.
We can get the module name and task pid from "module_load" event which
also mark the beginning of the loading, and module_put called by the
same task pid implies the end of the loading. So the memory events
recorded in between by the same task pid are consumed by this module
during loading(i.e. modprobe or module_init()).
With these information, we can record the rough total memory(the larger,
the more precise the result will be) consumption involved by each kernel
module loading.
Thus we introduce this shell script to find out which kernel module
consumes a large amount of memory during loading. Use "rd.memdebug=4"
as the tigger.
After applying this patch and specifying "rd.memdebug=4", during booting
it will print out something extra like below:
0 pages consumed by "pata_acpi"
0 pages consumed by "ata_generic"
1 pages consumed by "drm"
0 pages consumed by "ttm"
0 pages consumed by "drm_kms_helper"
835 pages consumed by "qxl"
0 pages consumed by "mii"
6 pages consumed by "8139cp"
0 pages consumed by "virtio"
0 pages consumed by "virtio_ring"
9 pages consumed by "virtio_pci"
1 pages consumed by "8139too"
0 pages consumed by "serio_raw"
0 pages consumed by "crc32c_intel"
199 pages consumed by "virtio_console"
0 pages consumed by "libcrc32c"
9 pages consumed by "xfs"
From the print, we see clearly that "qxl" consumed the most memory.
This file will be installed as a separate executable named "tracekomem"
in the following patch.
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Daniel Molkentin