Bug#661193: linux-tools-3.2: perf fails to annotate code with separate debug info under some conditions
Package: linux-tools-3.2 Version: 3.2.1-2 Severity: normal Hi! perf report does not show source code lines (annotation) for some binaries with separate debug information if those build-id's have been cached in perf's build-id cache. This is true for at least those packages whose debug symbols are installed in /usr/lib/debug/path/binary and not in /usr/lib/debug/.build-id/.../$hash. For example, e2fslibs, e2fsprogs and I believe very many others packages are affected by this (the mentioned packages even after fixing their -dbg packages per #661071). This manifests with the following symptoms. If you want to test this, I suggest either waiting for a fix for #661071 to be uploaded or to choose a different package from e2fsprogs and its corresponding -dbg package (but not one where the -dbg package has files in the .build-id directory): 1. Compile a package with separate debug info (so that you have the sources available actually) and install both the package and the -dbg package. Use a binary from the package in place of dumpe2fs in following steps. 2. Run perf record -g dumpe2fs $some_fs_image 3. Run perf annotate NOTE: functions in e.g. libext2fs.so.2.4 or in dumpe2fs are not annotated with source code lines 4. run perf buildid-list. Note that it lists binaries for those non-annotated functions. Either find the file in the ~/.debug/.build-id directory tree, or investigate using perf annotate -vv (grep for "Executing:") where the file file resides. 5. Note that the file you found is a copy of the binary or the library in question, *not* a copy of the relevant file from /usr/lib/debug. The objdump command that perf reports executing does not annotate it with source code lines. If you try that same line but replace the filename with the path to the actual binary, objdump knows where to find the debug info and does annotate it. 6. mv perf.data perf.data.tmp 7. perf record -g ls (this step is important because it empties the build-id cache and populates it with objects needed for the ls execution; turns out perf handles annotating fine once the relevant object is no longer in the build-id cache) 8. perf annotate -i perf.data.tmp NOTE: the functions that were unannotated in step 3 in that old perf.data are now correctly annotated with source code. I think the actual bug is that, for some reason, in step 2 perf record copies the non-debug version to the build-id cache instead of the debug version. I have not investigated why this happens. I also tried to remove the wrong file from the build-id cache and re-add the correct one with perf buildid-cache -v --remove=1a22c5f5c7a51ede62d01eeba1de59c15e7c9325; perf buildid-cache --add=/path/to/file, but for some reason I couldn't get that --remove= command to actually remove anything from the cache. Sami -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.4 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages linux-tools-3.2 depends on: ii libc6 2.13-26 ii libdw10.152-1+b1 ii libelf1 0.152-1+b1 ii libnewt0.52 0.52.14-8 ii libperl5.14 5.14.2-7 ii libpython2.7 2.7.2-13 ii libslang2 2.2.4-6 ii perl 5.14.2-7 ii python2.7.2-10 Versions of packages linux-tools-3.2 recommends: ii linux-base 3.4 Versions of packages linux-tools-3.2 suggests: pn linux-doc-3.2 -- no debconf information signature.asc Description: Digital signature
Bug#410204: linux-image-2.6.18-4-amd64: Data corruption on dm-crypt+XFS
Package: linux-image-2.6.18-4-amd64
Version: 2.6.18.dfsg.1-10
Severity: critical
Tags: patch
Justification: causes serious data loss
The current latest 2.6 kernel in unstable causes serious data loss
when using XFS over dm-crypt due to a bug or a number of bugs in
dm-crypt. Generally XFS metadata corruption sooner or later causes an
oops. It's not clear if this will be triggered by anything else than
XFS, but that triggers it easily and often. A fix was merged upstream
in 2.6.18.6 ("[PATCH] dm crypt: Fix data corruption with dm-crypt over
RAID5"), but is not apparently included in the Debian kernel (or at
least I ran into this with a very similar backtrace). See:
1. http://bugzilla.kernel.org/show_bug.cgi?id=7258
(There's some kind of patch referenced in comment #4 and available at
http://marc.theaimsgroup.com/?l=linux-kernel&m=116503133222152&w=2)
Also note
2. http://bugzilla.kernel.org/show_bug.cgi?id=7799
(esp. the last comment:
"Bug in dmcrypt. There's been several bugs in dmcrypt that
only XFS has triggered and the last of these that I know about
was fixed in 2.6.19.")
Sami
-- System Information:
Debian Release: 4.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-amd64
Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)
Versions of packages linux-image-2.6.18-4-amd64 depends on:
ii coreutil 5.97-5.3The GNU core utilities
ii debconf 1.5.11 Debian configuration management sy
ii e2fsprog 1.39+1.40-WIP-2006.11.14+dfsg-1 ext2 file system utilities and lib
ii initramf 0.85e tools for generating an initramfs
ii module-i 3.3-pre4-1 tools for managing Linux kernel mo
ii yaird [l 0.0.12-18 Yet Another mkInitRD
linux-image-2.6.18-4-amd64 recommends no packages.
-- debconf information:
linux-image-2.6.18-4-amd64/postinst/kimage-is-a-directory:
linux-image-2.6.18-4-amd64/postinst/bootloader-test-error-2.6.18-4-amd64:
linux-image-2.6.18-4-amd64/preinst/lilo-initrd-2.6.18-4-amd64: true
linux-image-2.6.18-4-amd64/preinst/initrd-2.6.18-4-amd64:
linux-image-2.6.18-4-amd64/preinst/failed-to-move-modules-2.6.18-4-amd64:
linux-image-2.6.18-4-amd64/postinst/old-initrd-link-2.6.18-4-amd64: true
linux-image-2.6.18-4-amd64/preinst/lilo-has-ramdisk:
linux-image-2.6.18-4-amd64/postinst/old-dir-initrd-link-2.6.18-4-amd64: true
linux-image-2.6.18-4-amd64/prerm/removing-running-kernel-2.6.18-4-amd64: true
linux-image-2.6.18-4-amd64/preinst/already-running-this-2.6.18-4-amd64:
linux-image-2.6.18-4-amd64/preinst/abort-install-2.6.18-4-amd64:
shared/kernel-image/really-run-bootloader: true
linux-image-2.6.18-4-amd64/preinst/abort-overwrite-2.6.18-4-amd64:
linux-image-2.6.18-4-amd64/postinst/depmod-error-initrd-2.6.18-4-amd64: false
linux-image-2.6.18-4-amd64/postinst/create-kimage-link-2.6.18-4-amd64: true
linux-image-2.6.18-4-amd64/postinst/depmod-error-2.6.18-4-amd64: false
linux-image-2.6.18-4-amd64/postinst/bootloader-error-2.6.18-4-amd64:
linux-image-2.6.18-4-amd64/postinst/old-system-map-link-2.6.18-4-amd64: true
linux-image-2.6.18-4-amd64/preinst/bootloader-initrd-2.6.18-4-amd64: true
linux-image-2.6.18-4-amd64/preinst/overwriting-modules-2.6.18-4-amd64: true
linux-image-2.6.18-4-amd64/preinst/elilo-initrd-2.6.18-4-amd64: true
linux-image-2.6.18-4-amd64/prerm/would-invalidate-boot-loader-2.6.18-4-amd64:
true
signature.asc
Description: Digital signature
Bug#410204: linux-image-2.6.18-4-amd64: Data corruption on dm-crypt+XFS
On Thu, Feb 08, 2007 at 05:11:32PM +0200, Sami Liedes wrote:
> XFS, but that triggers it easily and often. A fix was merged upstream
> in 2.6.18.6 ("[PATCH] dm crypt: Fix data corruption with dm-crypt over
> RAID5"), but is not apparently included in the Debian kernel (or at
> least I ran into this with a very similar backtrace). See:
Hmm, seems it (the entire 2.6.18.6) IS included in the Debian kernel.
I wonder which fix is missing then, or if the bug is still in the
vanilla kernel tree. Here's the oops:
Feb 8 04:43:08 lh kernel: Filesystem "dm-7": Disabling barriers, not supported
by the underlying device
Feb 8 04:43:08 lh kernel: XFS mounting filesystem dm-7
Feb 8 04:43:08 lh kernel: Ending clean XFS mount for filesystem: dm-7
Feb 8 04:46:10 lh kernel: Unable to handle kernel NULL pointer dereference at
RIP:
Feb 8 04:46:10 lh kernel: [] page_to_pfn+0x0/0x33
Feb 8 04:46:10 lh kernel: PGD 24a6c067 PUD 1da31067 PMD 0
Feb 8 04:46:10 lh kernel: Oops: [1] SMP
Feb 8 04:46:10 lh kernel: CPU 0
Feb 8 04:46:10 lh kernel: Modules linked in: sha256 aes dm_crypt snd_intel8x0
xfs ipt_owner ipt_REJECT xt_state xt_tcpudp iptable_filter ipt_MASQUERADE
iptable_nat ip_nat ip_conntrack nfnetlink ip_tables x_tables radeon drm
binfmt_misc freq_table ppdev lp button ac battery ipv6 nls_iso8859_1 nls_cp437
vfat fat ext2it87 hwmon_vid i2c_isa eeprom usbmouse ide_cd cdrom tsdev
snd_ac97_codec snd_ac97_bus snd_opl3_lib snd_pcm_oss snd_mixer_oss snd_hwdep
snd_mpu401 snd_mpu401_uart i2c_nforce2 snd_rawmidi snd_seq_device analog
i2c_core parport_pc parport snd_pcm snd_timer psmouse serio_raw snd
snd_page_alloc gameport evdev floppy soundcore pcspkr ext3 jbd mbcache
dm_mirror dm_snapshot dm_mod ide_generic sd_mod ide_disk sata_nv libata
scsi_mod 3c59x mii forcedeth generic amd74xx ide_core ehci_hcd ohci_hcd thermal
processor fan
Feb 8 04:46:10 lh kernel: Pid: 198, comm: pdflush Not tainted 2.6.18-4-amd64 #1
Feb 8 04:46:10 lh kernel: RIP: 0010:[] []
page_to_pfn+0x0/0x33
Feb 8 04:46:10 lh kernel: RSP: 0018:81003e7e97d8 EFLAGS: 00010297
Feb 8 04:46:10 lh kernel: RAX: RBX: 81000bce2640 RCX:
Feb 8 04:46:10 lh kernel: RDX: 0056 RSI: 81000bce2640 RDI:
Feb 8 04:46:10 lh kernel: RBP: 81003b3c8000 R08: R09:
810037ade870
Feb 8 04:46:10 lh kernel: R10: R11: 81000c1a1ec0 R12:
81000bce2640
Feb 8 04:46:10 lh kernel: R13: R14: R15:
81003e8f8088
Feb 8 04:46:10 lh kernel: FS: 2b4d40df3d20()
GS:80521000() knlGS:f7b446c0
Feb 8 04:46:10 lh kernel: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b
Feb 8 04:46:10 lh kernel: CR2: CR3: 1e0c6000 CR4:
06e0
Feb 8 04:46:10 lh kernel: Process pdflush (pid: 198, threadinfo
81003e7e8000, task 810037ade870)
Feb 8 04:46:10 lh kernel: Stack: 8022bf96 810037ade870
d400
Feb 8 04:46:10 lh kernel: 8101 0001 81000bce2640
81003e8f8088
Feb 8 04:46:10 lh kernel: 8100192517c0 810007f997a8 0056
0002a000
Feb 8 04:46:10 lh kernel: Call Trace:
Feb 8 04:46:10 lh kernel: [] blk_recount_segments+0x7e/0x21b
Feb 8 04:46:10 lh kernel: [] __bio_clone+0x71/0x8a
Feb 8 04:46:10 lh kernel: [] bio_clone+0x35/0x3d
Feb 8 04:46:10 lh kernel: [] :dm_crypt:crypt_map+0xcd/0x304
Feb 8 04:46:10 lh kernel: [] :dm_mod:__map_bio+0x47/0x9b
Feb 8 04:46:10 lh kernel: [] :dm_mod:__split_bio+0x172/0x37d
Feb 8 04:46:10 lh kernel: [] :dm_mod:dm_request+0x101/0x110
Feb 8 04:46:10 lh kernel: []
generic_make_request+0x13a/0x14d
Feb 8 04:46:10 lh kernel: [] submit_bio+0xcb/0xd2
Feb 8 04:46:10 lh kernel: [] __bio_add_page+0x188/0x1ce
Feb 8 04:46:10 lh kernel: []
:xfs:xfs_submit_ioend_bio+0x1e/0x27
Feb 8 04:46:10 lh kernel: []
:xfs:xfs_page_state_convert+0xa2f/0xb6e
Feb 8 04:46:10 lh kernel: [] :xfs:xfs_vm_writepage+0xa7/0xdd
Feb 8 04:46:10 lh kernel: [] mpage_writepages+0x1a6/0x34d
Feb 8 04:46:10 lh kernel: [] :xfs:xfs_vm_writepage+0x0/0xdd
Feb 8 04:46:10 lh kernel: [] do_writepages+0x20/0x2f
Feb 8 04:46:10 lh kernel: []
__writeback_single_inode+0x1b4/0x38b
Feb 8 04:46:10 lh kernel: []
:dm_mod:dm_any_congested+0x38/0x3f
Feb 8 04:46:10 lh kernel: []
:dm_mod:dm_table_any_congested+0x46/0x63
Feb 8 04:46:10 lh kernel: [] sync_sb_inodes+0x1d1/0x2b5
Feb 8 04:46:10 lh kernel: [] keventd_create_kthread+0x0/0x61
Feb 8 04:46:10 lh kernel: [] writeback_inodes+0x7d/0xd3
Feb 8 04:46:10 lh kernel: [] background_writeout+0x82/0xb5
Feb 8 04:46:10 lh kernel: [] pdflush+0x0/0x1ed
Feb 8 04:46:10 lh kernel: [] pdflush+0x143/0x1ed
Feb 8 04:46:10 lh kernel: [] background_writeout+0x0/0xb5
Feb 8 04:46:10 lh kernel: []
Bug#411284: initramfs-tools: Created initramfs fails to evms_activate
Package: initramfs-tools Version: 0.85e Severity: normal The created initramfs for some reason seems to fail to activate evms. I have a setup where I have evms+lvm2, and an evms-volume "root-crypted" is a luks volume of the root file system. This is what happens (typed, not captured from serial console or something, so any typos are mine): Begin: Mounting root file system ... Begin: Running /scripts/local-top ... device-mapper: ioctl: 4.7.0-ioctl (2006-06-24) initialised: [EMAIL PROTECTED] Volume group "root" not found Done. Begin: Waiting for root file system... I don't know what causes the message about vg "root" to not be found. I have no such vg, although it might be that I have have once had such. Once I get dropped to busybox shell, inspecting /dev reveals there is no /dev/evms directory. Running evms_activate from the shell correctly creates the directory and the nodes/mappings there, but after that fails with libgcc_s.so.1 must be installed for pthread_cancel to work Aborted However the nodes and mappings apparently have been correctly created before that. After that, I run "cryptsetup luksOpen /dev/evms/root-crypted root-decrypted" and enter my root filesystem password. /dev/mapper/root-decrypted is created. Then typing "exit" allows the boot process to continue and finish successfully. All the required block devices are correctly detected in the boot process (I have hda, hdd, sda. Of these all are detected, but only sda should be needed for booting after grub; the initramfs and kernel are on a partition on hda). Here's how my evms/lvm2 is setup (the volume1-root in the output below is my old root, not the current one; the current one is root-decrypted): # dmsetup --tree ls hda4 (254:3) `- (3:0) volume1-root (254:19) `-hdd3 (254:7) `- (22:64) hda3 (254:2) `- (3:0) my_container-test--region (254:22) `-sda6 (254:10) `- (8:0) hda2 (254:1) `- (3:0) my_container-my_region (254:20) `-sda5 (254:9) `- (8:0) hdd4 (254:6) `- (22:64) lvm2|volume1|root (254:8) `-hdd3 (254:7) `- (22:64) hda1 (254:0) `- (3:0) hdd2 (254:5) `- (22:64) swap-crypted (254:15) `-lvm2|my_container|swap1 (254:14) `-sda6 (254:10) `- (8:0) hdd1 (254:4) `- (22:64) test-volume (254:17) `-lvm2|my_container|test-region (254:16) `-sda6 (254:10) `- (8:0) sda1 (254:13) `- (8:0) my_container-swap1 (254:21) `-sda6 (254:10) `- (8:0) root-decrypted (254:18) `-root-crypted (254:12) `-lvm2|my_container|my_region (254:11) `-sda5 (254:9) `- (8:0) Additionally there's something wrong with the busybox shell: ctrl-c and ctrl-z do not work in it, so if I issue e.g. the commad "cat" in the shell, I'm stuck forever. The kernel I'm running is the Debian-provided linux-image-2.6.18-4-amd64 2.6.18.dfsg.1-10. You can get the generated initramfs from http://users.tkk.fi/~sliedes/my-initramfs . Sami -- Package-specific info: -- /proc/cmdline root=/dev/mapper/root-decrypted ro -- /proc/filesystems cramfs ext3 ext2 -- lsmod Module Size Used by radeon116384 2 drm87080 3 radeon binfmt_misc17292 1 freq_table 9728 0 ppdev 14088 0 lp 17736 0 button 12192 0 ac 10376 0 battery15496 0 ipv6 285664 18 ext2 70416 1 it87 28708 0 hwmon_vid 7424 1 it87 i2c_isa10752 1 it87 eeprom 12560 0 usbmouse 10496 0 ide_cd 45088 0 cdrom 40488 1 ide_cd tsdev 13056 0 snd_mpu401 13608 0 snd_cmipci 41984 0 snd_intel8x0 39592 0 snd_ac97_codec106456 1 snd_intel8x0 snd_ac97_bus7296 1 snd_ac97_codec snd_seq_dummy 8580 0 snd_seq_oss37248 0 snd_opl3_lib 15744 1 snd_cmipci snd_hwdep 15240 1 snd_opl3_lib snd_mpu401_uart13568 2 snd_mpu401,snd_cmipci snd_pcm_oss48672 0 snd_mixer_oss 21888 1 snd_pcm_oss snd_seq_midi 13632 0 snd_rawmidi31392 2 snd_mpu401_uart,snd_seq_midi snd_seq_midi_event 12544 2 snd_seq_oss,snd_seq_midi snd_seq59520 6 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event snd_seq_device 13204 6 snd_seq_dummy,snd_seq_oss,snd_opl3_lib,snd_seq_midi,snd_rawmidi,snd_seq snd_pcm89096 4 snd_cmipci,snd_intel8x0,snd_ac97_codec,
Bug#411284: [Pkg-cryptsetup-devel] Processed: Re: Bug#411284: initramfs-tools: Created initramfs fails to evms_activate
On Tue, Feb 20, 2007 at 12:01:20PM +0100, maximilian attems wrote: > copy_exec() explicitly copies the non-optimized libraries, > don't know yet why /lib/libgcc_s.so.1 falls into that category. > so that looks more like an possible initramfs-tools bug. > > the intersting output is > ldd /usr/sbin/evms_activate $ ldd /sbin/evms_activate libevms-2.5.so.0 => /lib/libevms-2.5.so.0 (0x2b034a121000) libpthread.so.0 => /lib/libpthread.so.0 (0x2b034a29a000) libc.so.6 => /lib/libc.so.6 (0x2b034a3b) libdl.so.2 => /lib/libdl.so.2 (0x2b034a5ed000) /lib64/ld-linux-x86-64.so.2 (0x2b034a009000) -- Sami signature.asc Description: Digital signature
Bug#464788: initramfs-tools: Please consider either relaxing script name requirements or issuing a warning on ignored scripts
Package: initramfs-tools Version: 0.91d Severity: wishlist Hi, I fought with initramfs-tools for some time because I had not noticed the warning in the man page that script names must match [a-zA-Z0-9_]+. (I admit I don't read entire man pages when I just need to quickly check how to do something.) So I had a script named /etc/initramfs-tools/scripts/local-premount/tuxonice-resume, and had to scratch my head for a while when it was silently ignored by the initrd creation process (I think even -v didn't say anything about it). I don't know if there's another purpose for the restriction besides ignoring backup files, but perhaps at least emitting a warning when ignoring a script which doesn't match a known backup file pattern (i.e. something like *~ and *.bak) would spare some time for others who have yet to hit this issue without, I hope, being too invasive. Regards, Sami signature.asc Description: Digital signature
Bug#383481: nvidiafb contains obfuscated source code, DFSG violation?
Revisiting a bit old issue, as I haven't seen this specific point discussed, although related points have been: On Fri, Nov 10, 2006 at 05:03:49AM -0800, Steve Langasek wrote: > severity 383481 important > thanks > > When Kyle cloned this bug, his comment was: > > > Wow. Looks a lot like copying register bank settings. Much like > > the drivers listed in Bug#383403. > > I don't believe there's any prevailing sentiment that the DFSG requires > non-numeric "source" in the case of register settings being changed; indeed, > various discussions on debian-vote and the like have explicitly acknowledged > that in cases when we *know* we're dealing with registers rather than code > compiled for an embedded processor, no source code is needed. I'm going to > go out on a limb then and downgrade this bug; it is arguably still a bug > since there is room for improvement to the source, but it's not an RC bug. We're talking about Linux kernel in this bug, and Linux is GPL, so for the code to be distributable, it definitely needs to be in "preferred form for modification" as per GPL, right (or alternatively we need permission from every GPL code contributor to the kernel)? Although I don't know if Debian makes exceptions for the kernel in this issue since upstream doesn't treat it with so much care... Sami signature.asc Description: Digital signature
Bug#446277: Still reproducible (#446277 - single quotes broken in UTF-8 console)
(This is about bug #446277, single quotes shown as boxes in UTF-8 console. Please Cc: the bug in replies.) I can reproduce this on current sid. Single quote seems to be somehow broken in UTF-8 console. Perhaps this should be reassigned to the kernel, as (as far as I can tell) the UTF-8 console things are handled in kernel. Don't know about the console things well enough to be sure though. Hence Cc:ing the debian-kernel list. Sami signature.asc Description: Digital signature
