Bug#856821: marked as done (firmware-linux-nonfree: romheaders of R420_cp.bin for ati x800 xt agp gfx card in package not OK.)
Your message dated Sun, 05 Mar 2017 04:11:22 + with message-id <1488687082.2953.5.ca...@decadent.org.uk> and subject line Re: Bug#856821: firmware-linux-nonfree: romheaders of R420_cp.bin for ati x800 xt agp gfx card in package not OK. has caused the Debian Bug report #856821, regarding firmware-linux-nonfree: romheaders of R420_cp.bin for ati x800 xt agp gfx card in package not OK. to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 856821: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856821 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: firmware-linux-nonfree Version: 0.43 Severity: important Tags: newcomer Dear Maintainer, Copy-pasted: me@mybox:~/fw-radeon$ romheaders R420_cp.bin Image 1: PCI Expansion ROM Header: Signature: 0x (Not Ok) CPU unique data: 0x00 0x00 0x42 0x00 0xe0 0x00 0x00 0x00 0x00 0x00 0x40 0x00 0xe0 0x00 0x00 0x00 Pointer to PCI Data Structure: 0x Rom Header error occured. Bailing out. This is for the R420_cp.bin in firmware-linux-nonfree. I used another rom from 'net and though no GPU acceleration (noted disabled in dmesg), at least that one doesn't lock up my system at boot. At boot with this R420_cp.bin from firmware-linux-nonfree I get a black screen and system lockup, though X was previously working fine (no other changes) before the package's installation. Here's copy-paste for my rom from 'net for comparison: me@mybox:~/ati_ret_x800xt$ romheaders R420_cp.bin Image 1: PCI Expansion ROM Header: Signature: 0x55aa (Ok) CPU unique data: 0x40 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Pointer to PCI Data Structure: 0x0020 PCI Data Structure: Signature: 0x50434952 'PCIR' (Ok) Vendor ID: 0x1002 Device ID: 0x4a48 Vital Product Data: 0x PCI Data Structure Length: 0x0020 (32 bytes) PCI Data Structure Revision: 0x00 Class Code: 0x03 (VGA Display controller) Image Length: 0x00f1 blocks (123392 bytes) Revision Level of Code/Data: 0x Code Type: 0x01 (Open Firmware) Last-Image Flag: 0x80 (last image in rom) Reserved: 0x Platform specific data for Open Firmware compliant rom: Pointer to FCode program: 0x0040 Note: I still do NOT get GPU acceleration by any means, though using a rom that is not apparently volatile. Thank you. -- System Information: Debian Release: 8.7 APT prefers stable APT policy: (1000, 'stable'), (900, 'stable'), (50, 'unstable') Architecture: powerpc (ppc64) Kernel: Linux 3.16.0-4-powerpc64 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) --- End Message --- --- Begin Message --- You are confusing two entirely different types of firmware - GPU microcode and PCI expansion ROMs. The microcode is 'correct', or at least it is the same microcode that Linux has used since 2008. The problem you're seeing is in the radeon kernel or X driver. It is triggered by installation of this package because they won't use GPU acceleration if there is no microcode available for it. You can open a bug against the kernel, but I'm afraid it is very unlikely that radeon's issues with old PowerPC machines will ever be fixed. Ben. -- Ben Hutchings All the simple programs have been written, and all the good names taken. signature.asc Description: This is a digitally signed message part --- End Message ---
Bug#856821: firmware-linux-nonfree: romheaders of R420_cp.bin for ati x800 xt agp gfx card in package not OK.
Package: firmware-linux-nonfree Version: 0.43 Severity: important Tags: newcomer Dear Maintainer, Copy-pasted: me@mybox:~/fw-radeon$ romheaders R420_cp.bin Image 1: PCI Expansion ROM Header: Signature: 0x (Not Ok) CPU unique data: 0x00 0x00 0x42 0x00 0xe0 0x00 0x00 0x00 0x00 0x00 0x40 0x00 0xe0 0x00 0x00 0x00 Pointer to PCI Data Structure: 0x Rom Header error occured. Bailing out. This is for the R420_cp.bin in firmware-linux-nonfree. I used another rom from 'net and though no GPU acceleration (noted disabled in dmesg), at least that one doesn't lock up my system at boot. At boot with this R420_cp.bin from firmware-linux-nonfree I get a black screen and system lockup, though X was previously working fine (no other changes) before the package's installation. Here's copy-paste for my rom from 'net for comparison: me@mybox:~/ati_ret_x800xt$ romheaders R420_cp.bin Image 1: PCI Expansion ROM Header: Signature: 0x55aa (Ok) CPU unique data: 0x40 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Pointer to PCI Data Structure: 0x0020 PCI Data Structure: Signature: 0x50434952 'PCIR' (Ok) Vendor ID: 0x1002 Device ID: 0x4a48 Vital Product Data: 0x PCI Data Structure Length: 0x0020 (32 bytes) PCI Data Structure Revision: 0x00 Class Code: 0x03 (VGA Display controller) Image Length: 0x00f1 blocks (123392 bytes) Revision Level of Code/Data: 0x Code Type: 0x01 (Open Firmware) Last-Image Flag: 0x80 (last image in rom) Reserved: 0x Platform specific data for Open Firmware compliant rom: Pointer to FCode program: 0x0040 Note: I still do NOT get GPU acceleration by any means, though using a rom that is not apparently volatile. Thank you. -- System Information: Debian Release: 8.7 APT prefers stable APT policy: (1000, 'stable'), (900, 'stable'), (50, 'unstable') Architecture: powerpc (ppc64) Kernel: Linux 3.16.0-4-powerpc64 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#856808: error during mount: first meta block group too large
Package: linux-image-4.9.0-2-amd64
Version: 4.9.13-1
Severity: important
Tags: patch upstream
Hi!
After rebooting one of my systems with 4.9.x I got hit by the following
error:
[ 309.934171] EXT4-fs (dm-5): mounting ext3 file system using the ext4
subsystem
[ 309.934748] EXT4-fs (dm-5): first meta block group too large: 1 (group
descriptor block count 1)
Unfortunately for me this is my /var filesystem.
This is https://bugzilla.kernel.org/show_bug.cgi?id=194567 and got fixed
by https://patchwork.ozlabs.org/patch/728066/
Rebuilding the kernel with the patch applied allows my system to mount
and boot again. Please add the fix to the next release, should be fix
not be included in a stable release until then.
Grüße,
Sven.
-- System Information:
Debian Release: 9.0
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500,
'unstable'), (500, 'testing'), (200, 'experimental'), (1, 'experimental-debug')
Architecture: i386 (x86_64)
Foreign Architectures: amd64
Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages linux-image-4.9.0-2-amd64:amd64 depends on:
ii initramfs-tools [linux-initramfs-tool] 0.127
ii kmod24-1
ii linux-base 4.5
Versions of packages linux-image-4.9.0-2-amd64:amd64 recommends:
ii firmware-linux-free 3.4
ii irqbalance 1.1.0-2.2
Versions of packages linux-image-4.9.0-2-amd64:amd64 suggests:
pn debian-kernel-handbook
ii grub-pc 2.02~beta3-5
pn linux-doc-4.9
-- debconf-show failed
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index dde14a7ac6d7..a673558fe5f8 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -3860,7 +3860,7 @@ static int ext4_fill_super(struct super_block *sb, void
*data, int silent)
db_count = (sbi->s_groups_count + EXT4_DESC_PER_BLOCK(sb) - 1) /
EXT4_DESC_PER_BLOCK(sb);
if (ext4_has_feature_meta_bg(sb)) {
- if (le32_to_cpu(es->s_first_meta_bg) >= db_count) {
+ if (le32_to_cpu(es->s_first_meta_bg) > db_count) {
ext4_msg(sb, KERN_WARNING,
"first meta block group too large: %u "
"(group descriptor block count %u)",
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index dde14a7ac6d7..a673558fe5f8 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -3860,7 +3860,7 @@ static int ext4_fill_super(struct super_block *sb, void
*data, int silent)
db_count = (sbi->s_groups_count + EXT4_DESC_PER_BLOCK(sb) - 1) /
EXT4_DESC_PER_BLOCK(sb);
if (ext4_has_feature_meta_bg(sb)) {
- if (le32_to_cpu(es->s_first_meta_bg) >= db_count) {
+ if (le32_to_cpu(es->s_first_meta_bg) > db_count) {
ext4_msg(sb, KERN_WARNING,
"first meta block group too large: %u "
"(group descriptor block count %u)",
Bug#757356: Scan code event not generated for some keys of the Apple keyboard' from 'Scan code event not generated for some keys of the Appple keyboard
I was recently annoyed that alt/meta don't generate scancodes when
swap_opt_cmd is on, and patched it (diff attached). This passes the
original scancodes through unmodified, even when the keycodes are
translated (e.g. Fn+F1 sends scancodes for Fn and F1, but keycode for
brightness down). Works for me, though I'm not sure if this is a good
approach overall.
--- a/drivers/hid/hid-apple.c 2017-03-04 01:34:38.655588991 -0500
+++ b/drivers/hid/hid-apple.c 2017-03-04 01:47:08.082599141 -0500
@@ -177,6 +177,15 @@
return NULL;
}
+static void input_event_with_scancode(struct input_dev *input,
+ __u8 type, __u16 code, unsigned int hid, __s32 value)
+{
+ if (type == EV_KEY &&
+ (!test_bit(code, input->key)) == value)
+ input_event(input, EV_MSC, MSC_SCAN, hid);
+ input_event(input, type, code, value);
+}
+
static int hidinput_apple_event(struct hid_device *hid, struct input_dev *input,
struct hid_usage *usage, __s32 value)
{
@@ -185,7 +194,8 @@
if (usage->code == KEY_FN) {
asc->fn_on = !!value;
- input_event(input, usage->type, usage->code, value);
+ input_event_with_scancode(input, usage->type, usage->code,
+usage->hid, value);
return 1;
}
@@ -217,8 +227,8 @@
else
clear_bit(usage->code, asc->pressed_fn);
-input_event(input, usage->type, trans->to,
- value);
+input_event_with_scancode(input, usage->type,
+ trans->to, usage->hid, value);
return 1;
}
@@ -238,8 +248,8 @@
clear_bit(usage->code,
asc->pressed_numlock);
-input_event(input, usage->type, trans->to,
- value);
+input_event_with_scancode(input, usage->type,
+ trans->to, usage->hid, value);
}
return 1;
@@ -250,7 +260,8 @@
if (asc->quirks & APPLE_ISO_KEYBOARD) {
trans = apple_find_translation(apple_iso_keyboard, usage->code);
if (trans) {
-input_event(input, usage->type, trans->to, value);
+input_event_with_scancode(input, usage->type,
+ trans->to, usage->hid, value);
return 1;
}
}
@@ -259,7 +270,8 @@
if (swap_opt_cmd) {
trans = apple_find_translation(swapped_option_cmd_keys, usage->code);
if (trans) {
- input_event(input, usage->type, trans->to, value);
+ input_event_with_scancode(input, usage->type,
+ trans->to, usage->hid, value);
return 1;
}
}
linux-signed_4.3~bpo8+1_multi.changes ACCEPTED into jessie-backports->backports-policy, jessie-backports
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 03 Mar 2017 16:09:56 + Source: linux-signed Binary: kernel-image-4.9.0-0.bpo.2-amd64-di nic-modules-4.9.0-0.bpo.2-amd64-di nic-wireless-modules-4.9.0-0.bpo.2-amd64-di nic-shared-modules-4.9.0-0.bpo.2-amd64-di serial-modules-4.9.0-0.bpo.2-amd64-di usb-serial-modules-4.9.0-0.bpo.2-amd64-di ppp-modules-4.9.0-0.bpo.2-amd64-di pata-modules-4.9.0-0.bpo.2-amd64-di cdrom-core-modules-4.9.0-0.bpo.2-amd64-di firewire-core-modules-4.9.0-0.bpo.2-amd64-di scsi-core-modules-4.9.0-0.bpo.2-amd64-di scsi-modules-4.9.0-0.bpo.2-amd64-di loop-modules-4.9.0-0.bpo.2-amd64-di btrfs-modules-4.9.0-0.bpo.2-amd64-di ext4-modules-4.9.0-0.bpo.2-amd64-di isofs-modules-4.9.0-0.bpo.2-amd64-di jfs-modules-4.9.0-0.bpo.2-amd64-di ntfs-modules-4.9.0-0.bpo.2-amd64-di xfs-modules-4.9.0-0.bpo.2-amd64-di fat-modules-4.9.0-0.bpo.2-amd64-di md-modules-4.9.0-0.bpo.2-amd64-di multipath-modules-4.9.0-0.bpo.2-amd64-di usb-modules-4.9.0-0.bpo.2-amd64-di usb-storage-modules-4.9.0-0.bpo.2-amd64-di pcmcia-storage-modules-4.9.0-0.bpo.2-amd64-di fb-modules-4.9.0-0.bpo.2-amd64-di input-modules-4.9.0-0.bpo.2-amd64-di event-modules-4.9.0-0.bpo.2-amd64-di mouse-modules-4.9.0-0.bpo.2-amd64-di nic-pcmcia-modules-4.9.0-0.bpo.2-amd64-di pcmcia-modules-4.9.0-0.bpo.2-amd64-di nic-usb-modules-4.9.0-0.bpo.2-amd64-di sata-modules-4.9.0-0.bpo.2-amd64-di acpi-modules-4.9.0-0.bpo.2-amd64-di i2c-modules-4.9.0-0.bpo.2-amd64-di crc-modules-4.9.0-0.bpo.2-amd64-di crypto-modules-4.9.0-0.bpo.2-amd64-di crypto-dm-modules-4.9.0-0.bpo.2-amd64-di efi-modules-4.9.0-0.bpo.2-amd64-di ata-modules-4.9.0-0.bpo.2-amd64-di mmc-core-modules-4.9.0-0.bpo.2-amd64-di mmc-modules-4.9.0-0.bpo.2-amd64-di nbd-modules-4.9.0-0.bpo.2-amd64-di squashfs-modules-4.9.0-0.bpo.2-amd64-di speakup-modules-4.9.0-0.bpo.2-amd64-di virtio-modules-4.9.0-0.bpo.2-amd64-di uinput-modules-4.9.0-0.bpo.2-amd64-di sound-modules-4.9.0-0.bpo.2-amd64-di hyperv-modules-4.9.0-0.bpo.2-amd64-di udf-modules-4.9.0-0.bpo.2-amd64-di fuse-modules-4.9.0-0.bpo.2-amd64-di linux-image-4.9.0-0.bpo.2-amd64 linux-image-4.9.0-0.bpo.2-rt-amd64 kernel-image-4.9.0-0.bpo.2-arm64-di nic-modules-4.9.0-0.bpo.2-arm64-di nic-wireless-modules-4.9.0-0.bpo.2-arm64-di nic-shared-modules-4.9.0-0.bpo.2-arm64-di ppp-modules-4.9.0-0.bpo.2-arm64-di cdrom-core-modules-4.9.0-0.bpo.2-arm64-di scsi-core-modules-4.9.0-0.bpo.2-arm64-di scsi-modules-4.9.0-0.bpo.2-arm64-di loop-modules-4.9.0-0.bpo.2-arm64-di btrfs-modules-4.9.0-0.bpo.2-arm64-di ext4-modules-4.9.0-0.bpo.2-arm64-di isofs-modules-4.9.0-0.bpo.2-arm64-di jfs-modules-4.9.0-0.bpo.2-arm64-di xfs-modules-4.9.0-0.bpo.2-arm64-di fat-modules-4.9.0-0.bpo.2-arm64-di md-modules-4.9.0-0.bpo.2-arm64-di multipath-modules-4.9.0-0.bpo.2-arm64-di usb-modules-4.9.0-0.bpo.2-arm64-di usb-storage-modules-4.9.0-0.bpo.2-arm64-di fb-modules-4.9.0-0.bpo.2-arm64-di input-modules-4.9.0-0.bpo.2-arm64-di event-modules-4.9.0-0.bpo.2-arm64-di nic-usb-modules-4.9.0-0.bpo.2-arm64-di sata-modules-4.9.0-0.bpo.2-arm64-di i2c-modules-4.9.0-0.bpo.2-arm64-di crc-modules-4.9.0-0.bpo.2-arm64-di crypto-modules-4.9.0-0.bpo.2-arm64-di crypto-dm-modules-4.9.0-0.bpo.2-arm64-di efi-modules-4.9.0-0.bpo.2-arm64-di ata-modules-4.9.0-0.bpo.2-arm64-di mmc-modules-4.9.0-0.bpo.2-arm64-di nbd-modules-4.9.0-0.bpo.2-arm64-di squashfs-modules-4.9.0-0.bpo.2-arm64-di virtio-modules-4.9.0-0.bpo.2-arm64-di uinput-modules-4.9.0-0.bpo.2-arm64-di leds-modules-4.9.0-0.bpo.2-arm64-di udf-modules-4.9.0-0.bpo.2-arm64-di fuse-modules-4.9.0-0.bpo.2-arm64-di linux-image-4.9.0-0.bpo.2-arm64 kernel-image-4.9.0-0.bpo.2-armmp-di nic-modules-4.9.0-0.bpo.2-armmp-di nic-wireless-modules-4.9.0-0.bpo.2-armmp-di nic-shared-modules-4.9.0-0.bpo.2-armmp-di ppp-modules-4.9.0-0.bpo.2-armmp-di pata-modules-4.9.0-0.bpo.2-armmp-di scsi-core-modules-4.9.0-0.bpo.2-armmp-di scsi-modules-4.9.0-0.bpo.2-armmp-di loop-modules-4.9.0-0.bpo.2-armmp-di btrfs-modules-4.9.0-0.bpo.2-armmp-di ext4-modules-4.9.0-0.bpo.2-armmp-di isofs-modules-4.9.0-0.bpo.2-armmp-di jfs-modules-4.9.0-0.bpo.2-armmp-di fat-modules-4.9.0-0.bpo.2-armmp-di md-modules-4.9.0-0.bpo.2-armmp-di multipath-modules-4.9.0-0.bpo.2-armmp-di usb-modules-4.9.0-0.bpo.2-armmp-di usb-storage-modules-4.9.0-0.bpo.2-armmp-di fb-modules-4.9.0-0.bpo.2-armmp-di input-modules-4.9.0-0.bpo.2-armmp-di event-modules-4.9.0-0.bpo.2-armmp-di nic-usb-modules-4.9.0-0.bpo.2-armmp-di sata-modules-4.9.0-0.bpo.2-armmp-di crc-modules-4.9.0-0.bpo.2-armmp-di crypto-modules-4.9.0-0.bpo.2-armmp-di crypto-dm-modules-4.9.0-0.bpo.2-armmp-di efi-modules-4.9.0-0.bpo.2-armmp-di ata-modules-4.9.0-0.bpo.2-armmp-di mmc-modules-4.9.0-0.bpo.2-armmp-di nbd-modules-4.9.0-0.bpo.2-armmp-di squashfs-modules-4.9.0-0.bpo.2-armmp-di virtio-modules-4.9.0-0.bpo.2-armmp-di uinput-modules-4.9.0-0.bpo.2-armmp-di zlib-modules-4.9.0-0.bpo.2-armmp-di leds-modules-4.9.0-0.bpo.2-armmp-di udf-modules-4.9.0-0.bpo.2-armmp-di
Bug#856733: Follow-up
Some additional info: I shutdown the xen guest and restarted it - this logged the same bootup BUG message as before. Shutting it down, launching a different Xen guest, and then launching the troublesome guest, works without any BUG messages being logged. I suppose this could point at a RAM issue with the host, I just find it odd that it shows up suddenly and has not been noticed before. Regards, Henrik Størner
Bug#856733: linux-image-3.16.0-4-amd64: Xen guest has multiple stack dumps, ending with spontaneous reboot
Package: src:linux Version: 3.16.39-1+deb8u1 Severity: important Dear Maintainer, after installing the latest linux-image update, one of my Xen guests suddenly logged multiple kernel stacktraces. The initial one was this: Mar 4 03:05:14 saltmaster kernel: [798533.537459] WARNING: CPU: 1 PID: 9901 at /build/linux-NAZ6Cx/linux-3.16.39/arch/x86/xen/multicalls.c:129 __xen_mc_entry+0x110/0x180() Mar 4 03:05:14 saltmaster kernel: [798533.537463] Modules linked in: x86_pkg_temp_thermal thermal_sys intel_rapl coretemp crc32_pclmul aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper evdev cryptd pcspkr autofs4 ext4 crc16 mbcache jbd2 xen_netfront crct10di f_pclmul crct10dif_common xen_blkfront crc32c_intel Mar 4 03:05:14 saltmaster kernel: [798533.537483] CPU: 1 PID: 9901 Comm: salt-master Not tainted 3.16.0-4-amd64 #1 Debian 3.16.39-1+deb8u1 Mar 4 03:05:14 saltmaster kernel: [798533.537486] 81514c41 0009 Mar 4 03:05:14 saltmaster kernel: [798533.537490] 81068867 01ff 88007adcbd00 Mar 4 03:05:14 saltmaster kernel: [798533.537496] 0001 0150 81005150 01ff Mar 4 03:05:14 saltmaster kernel: [798533.537501] Call Trace: Mar 4 03:05:14 saltmaster kernel: [798533.537507] [] ? dump_stack+0x5d/0x78 Mar 4 03:05:14 saltmaster kernel: [798533.537513] [] ? warn_slowpath_common+0x77/0x90 Mar 4 03:05:14 saltmaster kernel: [798533.537517] [] ? __xen_mc_entry+0x110/0x180 Mar 4 03:05:14 saltmaster kernel: [798533.537521] [] ? xen_pin_page+0x58/0x160 Mar 4 03:05:14 saltmaster kernel: [798533.537524] [] ? xen_do_pin+0x50/0x50 Mar 4 03:05:14 saltmaster kernel: [798533.537527] [] ? __xen_pgd_walk+0x2e4/0x310 Mar 4 03:05:14 saltmaster kernel: [798533.537529] [] ? xen_do_pin+0x50/0x50 Mar 4 03:05:14 saltmaster kernel: [798533.537532] [] ? __xen_pgd_pin+0x5b/0x340 Mar 4 03:05:14 saltmaster kernel: [798533.537535] [] ? xen_dup_mmap+0x1e/0x30 Mar 4 03:05:14 saltmaster kernel: [798533.537539] [] ? copy_process.part.25+0x1781/0x1c50 Mar 4 03:05:14 saltmaster kernel: [798533.537543] [] ? do_fork+0xe0/0x3d0 Mar 4 03:05:14 saltmaster kernel: [798533.537547] [] ? __alloc_fd+0x7c/0x120 Mar 4 03:05:14 saltmaster kernel: [798533.537550] [] ? stub_clone+0x69/0x90 Mar 4 03:05:14 saltmaster kernel: [798533.537554] [] ? system_call_fast_compare_end+0x10/0x15 Mar 4 03:05:14 saltmaster kernel: [798533.537556] ---[ end trace ef0d5e3cd38fc131 ]--- immediately followed by this: Mar 4 03:05:14 saltmaster kernel: [798533.538577] WARNING: CPU: 1 PID: 9901 at /build/linux-NAZ6Cx/linux-3.16.39/arch/x86/xen/multicalls.c:129 __xen_pgd_pin+0x103/0x340() Mar 4 03:05:14 saltmaster kernel: [798533.538580] Modules linked in: x86_pkg_temp_thermal thermal_sys intel_rapl coretemp crc32_pclmul aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper evdev cryptd pcspkr autofs4 ext4 crc16 mbcache jbd2 xen_netfront crct10di f_pclmul crct10dif_common xen_blkfront crc32c_intel Mar 4 03:05:14 saltmaster kernel: [798533.538597] CPU: 1 PID: 9901 Comm: salt-master Tainted: GW 3.16.0-4-amd64 #1 Debian 3.16.39-1+deb8u1 Mar 4 03:05:14 saltmaster kernel: [798533.538600] 81514c41 0009 Mar 4 03:05:14 saltmaster kernel: [798533.538604] 81068867 000edf90 8800fa16 88007bfb1800 Mar 4 03:05:14 saltmaster kernel: [798533.538608] 8800843fe000 77ff8000 81009ad3 88007bfb1800 Mar 4 03:05:14 saltmaster kernel: [798533.538611] Call Trace: Mar 4 03:05:14 saltmaster kernel: [798533.538614] [] ? dump_stack+0x5d/0x78 Mar 4 03:05:14 saltmaster kernel: [798533.538617] [] ? warn_slowpath_common+0x77/0x90 Mar 4 03:05:14 saltmaster kernel: [798533.538621] [] ? __xen_pgd_pin+0x103/0x340 Mar 4 03:05:14 saltmaster kernel: [798533.538624] [] ? xen_dup_mmap+0x1e/0x30 Mar 4 03:05:14 saltmaster kernel: [798533.538627] [] ? copy_process.part.25+0x1781/0x1c50 Mar 4 03:05:14 saltmaster kernel: [798533.538630] [] ? do_fork+0xe0/0x3d0 Mar 4 03:05:14 saltmaster kernel: [798533.538634] [] ? __alloc_fd+0x7c/0x120 Mar 4 03:05:14 saltmaster kernel: [798533.538637] [] ? stub_clone+0x69/0x90 Mar 4 03:05:14 saltmaster kernel: [798533.538641] [] ? system_call_fast_compare_end+0x10/0x15 Mar 4 03:05:14 saltmaster kernel: [798533.538643] ---[ end trace ef0d5e3cd38fc132 ]--- After this, multiple stacktraces were logged without much call trace info: Mar 4 03:05:14 saltmaster kernel: [798533.538726] WARNING: CPU: 0 PID: 0 at /build/linux-NAZ6Cx/linux-3.16.39/arch/x86/xen/multicalls.c:129 xen_end_context_switch+0xe/0x20() Mar 4 03:05:14 saltmaster kernel: [798533.538732] Modules linked in: x86_pkg_temp_thermal thermal_sys intel_rapl coretemp crc32_pclmul aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper evdev cryptd pcspkr autofs4 ext4
Bug#856474: stap: include runtime_defines.h not found
On Sat, 2017-03-04 at 02:12 +, Ben Hutchings wrote: > On Sat, 2017-03-04 at 01:39 +, Ben Hutchings wrote: > [...] > > I investigated this and found that it occurs when the kernel source and > > object trees are separate (an "out-of-tree" build, not to be confused > > with out-of-tree modules). We separate them in Debian kernel header > > packages to avoid duplicating source files for each flavour. > > > > When this is the case, the compiler is called in the root of the > > object tree, and the kernel build system adjusts -I options in the > > compiler flags to refer to subdirectories of the source tree if > > necessary. Any directory name beginning with /, ./ or ../ is excluded > > from this adjustment. > > > > systemtap uses -I"/usr/share/systemtap/runtime", which ought to be > > excluded... but make has no understanding of shell quoting, so it is > > wrongly adjusted to something like > > -I/usr/src/linux-headers-4.9.0-2-common/"/usr/share/systemtap/runtime" > > and runtime_defines.h cannot be found. > > By the way, kbuild has been doing this ever since it started supporting > out-of-tree builds (around Linux 2.6.0). However, both the adjusted > and original -I options were used. Since Linux 4.8 only the adjusted > option is used. > Thank you very much, Ben. I tested with your fix and it resolves the issue. -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System signature.asc Description: This is a digitally signed message part
