Bug#721005: linux: sierra Gobi 3000 WWAN no longer works
Hey. That seems to work again at least since 4.2.5-1, but probably already since few versions earlier (I didn't check this every time). See upstream for little more details Closing, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#721005: marked as done (linux: sierra Gobi 3000 WWAN no longer works)
Your message dated Sun, 08 Nov 2015 04:04:37 +0100 with message-id <1446951877.3.5.ca...@scientia.net> and subject line Re: linux: sierra Gobi 3000 WWAN no longer works has caused the Debian Bug report #721005, regarding linux: sierra Gobi 3000 WWAN no longer works 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.) -- 721005: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721005 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: linux Version: 3.10.7-1 Severity: normal Hi. I got a little bit stuck with this... I'm having a Fujitsu Lifebook E782 which has some Sierra Gobi 3000 UMTS modem in it. For many years it simply used to work perfectly, but a year ago or so it already stopped working (i.e. wasn't detected anymore by the kernel)... but it came back surprisingly around March that year and worked at least until May. Unfortunately I don't know when exactly it stopped worked since I use it only rarley when I'm on train. # lsusb Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 009: ID 04f2:b2fc Chicony Electronics Co., Ltd Bus 001 Device 011: ID 0489:e052 Foxconn / Hon Hai Bus 001 Device 010: ID 0b97:7772 O2 Micro, Inc. OZ776 CCID Smartcard Reader Bus 001 Device 003: ID 0b97:7761 O2 Micro, Inc. Oz776 1.1 Hub Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Manually loading sierra or sierra_net doens't help either, but the device is enabled in the BIOS. Any ideas? Cheers, Chris. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.10-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash --- End Message --- --- Begin Message --- Hey. That seems to work again at least since 4.2.5-1, but probably already since few versions earlier (I didn't check this every time). See upstream for little more details Closing, Chris. smime.p7s Description: S/MIME cryptographic signature --- End Message ---
Processed: found in 4.1
Processing control commands: > found 790050 4.1+67 Bug #790050 [src:linux] linux-image-4.0.0-2-amd64: Cannot use sdcard: DMA: Out of SW-IOMMU space for 65536 bytes at device :02:00.0 The source 'linux' and version '4.1+67' do not appear to match any binary packages Marked as found in versions linux/4.1+67. -- 790050: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790050 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#790050: found in 4.1
Control: found 790050 4.1+67 I experience this problem (also on a thinkpad) with kernel 4.1. It does seem to go away (at least temporarily) with a reboot.
Re: Upstream source handling
On Sat, 2015-11-07 at 17:49 +0100, Bastian Blank wrote: [...] > > Do you think we would tag when updating to a new upstream version, or > > only when making the first upload with a new orig tarball (allowing for > > further DFSG changes before uploading)? > > I think we have to tag while updating. We would need to rebase the > already published branches, if we change the orig later. Also it is > impossible to build a source package without the tag. OK. > > > - Rebase old main featureset branch on top of new orig tag as new > > > branch > > > - Rebase old other featureset branches on top of new main featureset > > > branch or replace with new base and create new branch > > > - Record new top commits and update changelog in main repo > > That's a lot of rebasing, though not so different from what we do now > > to refresh the patch series. Presumably we would add a script to > > support this and ensure it is all done properly? > > Sure, thats support infrastructure. > > > The submodules are checked out with detached heads by default. Is your > > intent that we would override this? > > Do you know if we can change it? No, as I said I'm not familiar with submodules. > > I tried this: > > $ cd source/orig > > source/orig is supposed to go away. At least that was my plan. > > > Is it possible to combine those push commands? Is this something else > > we would need to script? > > It is possible to change the way push works via the config, you can > specify what is going to be pushed. Including sub-modules? From what you wrote below, it sounds like that isn't possible. > > > - Cherry pick patch > > > - (Make sure the submodules are on the correct branch, otherwise it > > > will be hard to push changes or they will go to incorrect locations) > > > - Cherry pick patch > > > - Merge changes into all derived featuresets, if any > > Rather than rebasing? > > Rebasing published branches is no nice thing to do. OK, I suppose this is different from rebasing onto a new upstream as there we're creating a new branch. So in case we want to drop a patch, presumably we would revert the commit and then drop both the original and revert when moving to a new upstream? > > What I don't like: > > 3. Pushing is more complicated > > git push can push all submodules as well, but I don't see a config > option for it. I should use the option --recurse-submodules=on-demand, right? In the absence of a configuration variable, it would presumably be sensible to recommend an alias for this e.g. 'push-sm = push --recurse-submodules=on-demand' > > 4. Cherry-picking is more complicated > > Yeah. That warrants a script. > > > 6. It's not possible to see the history of one of our patches > > Which history do you mean? Currently we can run 'git log debian/patches/a/random.patch' and see when a patch was originally added and how it changed as it was rebased onto different upstream versions. If we were to use a merge-based workflow then 'git log .. patched/file.c' would provide similar information. But with a rebasing workflow, the git object model doesn't provide any association between the commits that apply a patch onto different upstream versions. Ben. -- Ben Hutchings 73.46% of all statistics are made up. signature.asc Description: This is a digitally signed message part
Re: Upstream source handling
On Sat, 2015-11-07 at 17:53 +0100, Bastian Blank wrote: > On Sat, Nov 07, 2015 at 02:16:13PM +, Ben Hutchings wrote: > > 7. The DFSG changes are not documented in the source package > > 8. Each featureset is reduced to a single patch in the source package > > > > (7) should be easy to fix, as the history is linear, except where we > > delete part of a file. > > git can generate patch files for deleted files without actually showing > the content. I know, that's why I said where we delete *part* of a file (using unifdef). However, there are currently no cases where we do that. > > (8) should be easy to fix for the 'none' > > featureset as its history will also be linear. For any other > > featuresets, reducing to a single patch may be unavoidable. > > I didn't want to enfore a linear history, but if we say it will be > linear (and check that in a hook during push), we can also generate > expanded patch series. Your description of the workflow did imply the history would be linear for the 'none' featureset. And non-linear history gets linearised when rebasing so it's probably not a good idea to introduce non-linearity in any branch that we expect to rebase later. Ben. -- Ben Hutchings 73.46% of all statistics are made up. signature.asc Description: This is a digitally signed message part
Re: Upstream source handling
On Sat, Nov 07, 2015 at 02:16:13PM +, Ben Hutchings wrote: > 7. The DFSG changes are not documented in the source package > 8. Each featureset is reduced to a single patch in the source package > > (7) should be easy to fix, as the history is linear, except where we > delete part of a file. git can generate patch files for deleted files without actually showing the content. > (8) should be easy to fix for the 'none' > featureset as its history will also be linear. For any other > featuresets, reducing to a single patch may be unavoidable. I didn't want to enfore a linear history, but if we say it will be linear (and check that in a hook during push), we can also generate expanded patch series. Bastian -- It would seem that evil retreats when forcibly confronted. -- Yarnek of Excalbia, "The Savage Curtain", stardate 5906.5
Re: Upstream source handling
Ben, thanks for the comments. On Sat, Nov 07, 2015 at 01:48:51PM +, Ben Hutchings wrote: > On Tue, 2015-09-08 at 22:52 +0200, Bastian Blank wrote: > > Main principles: > So genorig.py would be replaced with 'git archive'? Yes. > > Workflow: > > - New upstream version > > - Rebase old tag on top of new upstream, tag it with the new version > There are no tags in the repository you created. Can you add one as an > example? Done. > Do you think we would tag when updating to a new upstream version, or > only when making the first upload with a new orig tarball (allowing for > further DFSG changes before uploading)? I think we have to tag while updating. We would need to rebase the already published branches, if we change the orig later. Also it is impossible to build a source package without the tag. > > - Rebase old main featureset branch on top of new orig tag as new > > branch > > - Rebase old other featureset branches on top of new main featureset > > branch or replace with new base and create new branch > > - Record new top commits and update changelog in main repo > That's a lot of rebasing, though not so different from what we do now > to refresh the patch series. Presumably we would add a script to > support this and ensure it is all done properly? Sure, thats support infrastructure. > The submodules are checked out with detached heads by default. Is your > intent that we would override this? Do you know if we can change it? > I tried this: > $ cd source/orig source/orig is supposed to go away. At least that was my plan. > Is it possible to combine those push commands? Is this something else > we would need to script? It is possible to change the way push works via the config, you can specify what is going to be pushed. > > - Cherry pick patch > > - (Make sure the submodules are on the correct branch, otherwise it > > will be hard to push changes or they will go to incorrect locations) > > - Cherry pick patch > > - Merge changes into all derived featuresets, if any > Rather than rebasing? Rebasing published branches is no nice thing to do. > What I don't like: > 3. Pushing is more complicated git push can push all submodules as well, but I don't see a config option for it. > 4. Cherry-picking is more complicated Yeah. That warrants a script. > 6. It's not possible to see the history of one of our patches Which history do you mean? Bastian -- Earth -- mother of the most beautiful women in the universe. -- Apollo, "Who Mourns for Adonais?" stardate 3468.1
Re: Upstream source handling
On Sat, 2015-11-07 at 13:48 +, Ben Hutchings wrote: [...] > What I like: > 1. Rebasing is easier > 2. I can log, diff, etc. through our changes and upstream changes > > What I don't like: > 3. Pushing is more complicated > 4. Cherry-picking is more complicated > 5. Git working directory looks different from unpacked source package > 6. It's not possible to see the history of one of our patches > > (3) and (4) definitely need to be addressed, either by documentation > (if I'm missing some git feature or config) or by scripting. > > I think I can live with (5) and (6). For (6), maybe we should start > putting Change-Ids in our changes so that it would be possible to find > all versions using 'git log --tags=debian --grep=...' A couple more things I don't like: 7. The DFSG changes are not documented in the source package 8. Each featureset is reduced to a single patch in the source package (7) should be easy to fix, as the history is linear, except where we delete part of a file. (8) should be easy to fix for the 'none' featureset as its history will also be linear. For any other featuresets, reducing to a single patch may be unavoidable. Ben. -- Ben Hutchings Unix is many things to many people, but it's never been everything to anybody signature.asc Description: This is a digitally signed message part
Re: Upstream source handling
Bastian, I'm really sorry I've taken so long to look at this. On Tue, 2015-09-08 at 22:52 +0200, Bastian Blank wrote: > Moin > > During the linux packaging BoF at DebConf, Ben asked for usefull > upstream source handling. No compeling ones were mentioned. > > Some years ago (yes, years), I proposed some schema based on submodules, > but never got around to actually implement it. I finally managed to do > an initial implementation. It currently lives in the linux.git in > branch waldi/submodule. > > Main principles: > - source of each featureset is a submodule, using version specific > branches > - orig source via version specific tag So genorig.py would be replaced with 'git archive'? > Workflow: > - New upstream version > - Rebase old tag on top of new upstream, tag it with the new version There are no tags in the repository you created. Can you add one as an example? Do you think we would tag when updating to a new upstream version, or only when making the first upload with a new orig tarball (allowing for further DFSG changes before uploading)? > - Rebase old main featureset branch on top of new orig tag as new > branch > - Rebase old other featureset branches on top of new main featureset > branch or replace with new base and create new branch > - Record new top commits and update changelog in main repo That's a lot of rebasing, though not so different from what we do now to refresh the patch series. Presumably we would add a script to support this and ensure it is all done properly? The submodules are checked out with detached heads by default. Is your intent that we would override this? I tried this: $ cd source/orig $ git checkout orig/4.2-rc8 For some reason, this deleted upstream files in the working tree - maybe because of the '*' in .gitignore? ... Branch orig/4.2-rc8 set up to track remote branch orig/4.2-rc8 from origin. Switched to a new branch 'orig/4.2-rc8' $ git reset --hard ... $ git checkout -b orig/4.3 Switched to a new branch 'orig/4.3' $ git fetch ~/src/linux refs/tags/v4.3:refs/tags/v4.3 This fetched all tags; maybe I should have just fetched to FETCH_HEAD? ... $ git rebase v4.3 First, rewinding head to replay your work on top of it... Applying: Remove microcode patches for mgsuvd (not enabled in Debian configs) Applying: dvb-usb-af9005: remove, mark as broken Applying: vs6624: remove, mark as broken Applying: Remove and mark as broken: cops Applying: video: Remove nvidiafb and rivafb Applying: Remove the entire firmware directory Applying: Remove: ft1000 Applying: Remove: Non-free RFC $ cd ../none $ git checkout none/4.2-rc8 ... Branch none/4.2-rc8 set up to track remote branch none/4.2-rc8 from origin. Switched to a new branch 'none/4.2-rc8' $ git reset --hard ... $ git checkout -b none/4.3 Switched to a new branch 'none/4.3' $ git fetch ../orig orig/4.3 From ../orig * branchorig/4.3 -> FETCH_HEAD $ git rebase --onto=FETCH_HEAD origin/orig/4.2-rc8 This rebase took a while, but was definitely easier than rebasing with quilt. There are no featuresets to deal with currently. ... $ cd ../.. $ sed -i 's/4.2-rc8/4.3/' .gitmodules $ emacsclient debian/changelog Waiting for Emacs... $ git commit -a -m 'Update to 4.3' $ git push --set-upstream alioth benh/submodule ... $ cd source/orig $ git push --set-upstream origin orig/4.3 This pushed a whole load of tags too. WTF? ... $ cd ../none $ git push --set-upstream origin none/4.3 ... Is it possible to combine those push commands? Is this something else we would need to script? > - Cherry pick patch > - (Make sure the submodules are on the correct branch, otherwise it > will be hard to push changes or they will go to incorrect locations) > - Cherry pick patch > - Merge changes into all derived featuresets, if any Rather than rebasing? > - Record new top commits and update changelog in main repo So that's two commits rather than one at present. A little annoying. > There are some things not yet implemented or different in my preview: > - debuild from the repo tree does not yet work, the rules are missing > the special directory definitions > - orig is also a submodule > > Please take a look and let me know what you think about this variant. > Most likely I've forgotten something, but I don't know what it is. What I like: 1. Rebasing is easier 2. I can log, diff, etc. through our changes and upstream changes What I don't like: 3. Pushing is more complicated 4. Cherry-picking is more complicated 5. Git working directory looks different from unpacked source package 6. It's not possible to see the history of one of our patches (3) and (4) definitely need to be addressed, either by documentation (if I'm missing some git feature or config) or by scripting. I think I can liv
Bug#779515: Should enable the qxl kernel driver when installed
Le 07/11/15 02:23, Ben Hutchings a écrit : On Sat, 2015-11-07 at 00:24 +0100, Laurent Bigonville wrote: reassign 779515 linux-image-4.2.0-1-amd64 severity 779515 important thanks On Sun, 01 Mar 2015 18:47:54 + Ben Hutchings wrote: > I've enabled the kernel's qxl driver, but disabled by default so that > it doesn't conflict with wheezy's version of xserver-xorg-video-qxl. > > Please install a modprobe configuration file with the line: > > options qxl modeset=1 > > (When I tried this on a VM host with virt-manager and QEMU from sid, > the qxl driver complained of missing features, so KMS still didn't > work. However, the fall-back to UMS still worked.) Shouldn't the qxl kernel module be enabled by default in unstable now that the xserver-xorg-video-qxl package has been updated? [...] Only if xserver-xorg-video-qxl in jessie works properly with KMS. Is that the case? OK, so I tried on a jessie VM with jessie kernel and it gave me a backscreen. I updated to the kernel from bpo (4.2) and now gdm is starting properly. How can I verify if the issue you got is now fixed? I see this in the Xserver logs: [KMS] Kernel modesetting enabled. BTW, without qxl kernel driver, I see some ugly yellowish vt. Cheers, Laurent Bigonville
Bug#804318: marked as done (linux-image-amd64: no more linux-image RT available on sid)
Your message dated Sat, 07 Nov 2015 10:17:47 + with message-id <1446891467.6006.22.ca...@decadent.org.uk> and subject line Re: Bug#804318: linux-image-amd64: no more linux-image RT available on sid has caused the Debian Bug report #804318, regarding linux-image-amd64: no more linux-image RT available on sid 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.) -- 804318: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804318 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: linux-image-amd64 Version: 4.2+68 Severity: important Dear Maintainer, As the linux-image_4.1.0-2-rt-* package has been removed from sid repository, it has no more PREEMPT-RT patched kernel in the sid distribution. Solution is giving back this version or patching linux-latest. Many thanks ! -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages linux-image-amd64 depends on: ii linux-image-4.2.0-1-amd64 4.2.5-1 linux-image-amd64 recommends no packages. linux-image-amd64 suggests no packages. -- no debconf information --- End Message --- --- Begin Message --- On Sat, 2015-11-07 at 10:47 +0100, Florian Foinant wrote: > Package: linux-image-amd64 > Version: 4.2+68 > Severity: important > > Dear Maintainer, > > As the linux-image_4.1.0-2-rt-* package has been removed from sid > repository, > it has no more PREEMPT-RT patched kernel in the sid distribution. > > Solution is giving back this version or patching linux-latest. That's not possible, sorry. The rt featureset should be back in 4.3 or 4.4. Ben. -- Ben Hutchings Unix is many things to many people, but it's never been everything to anybody. signature.asc Description: This is a digitally signed message part --- End Message ---
Bug#804318: linux-image-amd64: no more linux-image RT available on sid
Package: linux-image-amd64 Version: 4.2+68 Severity: important Dear Maintainer, As the linux-image_4.1.0-2-rt-* package has been removed from sid repository, it has no more PREEMPT-RT patched kernel in the sid distribution. Solution is giving back this version or patching linux-latest. Many thanks ! -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages linux-image-amd64 depends on: ii linux-image-4.2.0-1-amd64 4.2.5-1 linux-image-amd64 recommends no packages. linux-image-amd64 suggests no packages. -- no debconf information
Bug#802432: marked as done (linux-image-4.3.0-rc5-amd64 fails to attach usb storage device)
Your message dated Sat, 07 Nov 2015 09:34:29 + with message-id <144669.6006.19.ca...@decadent.org.uk> and subject line Re: Bug#802432: fixed, can be closed. has caused the Debian Bug report #802432, regarding linux-image-4.3.0-rc5-amd64 fails to attach usb storage device 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.) -- 802432: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802432 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: linux-image-4.3.0-rc5-amd64 Version: 4.3~rc5-1~exp1 Severity: important Dear Maintainer, After upgrading linux-image-4.2.0-1-amd64 (4.2.3-2) from unstable to linux-image-4.3.0-rc5-amd64 from experimental my Verbatim usb flash drive is detected but fails to attach. Using kernel 4.2.3-2 this device is properly detected and attached. Please see the attached kernel.log -- System Information: Debian Release: sid + experimental Architecture: amd64 (x86_64) Kernel: linux-image-4.3.0-rc5-amd64 Systemd: 227-2 Kind regards, Jos v.Wolput Oct 20 11:34:21 debian kernel: [ 101.305777] usb-storage 2-2:1.0: USB Mass Storage device detected Oct 20 11:34:21 debian kernel: [ 101.306000] scsi host6: usb-storage 2-2:1.0 Oct 20 11:34:21 debian kernel: [ 101.306240] usbcore: registered new interface driver usb-storage Oct 20 11:34:21 debian kernel: [ 101.335548] usbcore: registered new interface driver uas Oct 20 11:34:22 debian kernel: [ 102.838335] scsi 6:0:0:0: Direct-Access Verbatim PQ: 0 ANSI: 4 Oct 20 11:34:22 debian kernel: [ 102.838737] [ cut here ] Oct 20 11:34:22 debian kernel: [ 102.838755] WARNING: CPU: 0 PID: 100 at /build/linux-HFgDpK/linux-4.3~rc5/kernel/kmod.c:140 __request_module+0x1e9/0x290() Oct 20 11:34:22 debian kernel: [ 102.838759] Modules linked in: uas usb_storage xt_recent nf_log_ipv4 nf_log_common snd_hrtimer snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device xt_tcpudp ip6table_mangle iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat xt_TCPMSS xt_LOG ipt_REJECT nf_reject_ipv4 iptable_mangle xt_multiport xt_state xt_limit xt_conntrack nf_conntrack_ftp nf_conntrack ip6table_filter ip6_tables iptable_filter ip_tables x_tables binfmt_misc zram zsmalloc hid_generic usbhid hid arc4 uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core v4l2_common videodev media rt2800pci rt2800mmio rt2800lib rt2x00pci rt2x00mmio joydev rt2x00lib eeprom_93cx6 mac80211 tg3 snd_hda_codec_realtek pcmcia kvm_amd cfg80211 snd_hda_codec_generic snd_hda_codec_hdmi ptp pps_core libphy kvm psmouse crc_ccitt snd_hda_intel rfkill pcspkr snd_hda_codec yenta_socket evdev snd_hda_core serio_raw pcmcia_rsrc snd_hwdep pcmcia_core snd_pcm_oss snd_mixer_oss k10temp snd_pcm ohci_pci sp5100_tco i2c_piix4 sr_mod ohci_hcd snd_timer ehci_pci cdrom snd ehci_hcd soundcore sg usbcore usb_common shpchp battery ene_ir rc_core wmi ac video button acpi_cpufreq processor loop parport_pc ppdev lp parport autofs4 ext4 crc16 mbcache jbd2 sd_mod ahci libahci radeon libata i2c_algo_bit drm_kms_helper scsi_mod ttm drm thermal lz4 lz4_compress Oct 20 11:34:22 debian kernel: [ 102.838926] CPU: 0 PID: 100 Comm: kworker/u4:4 Not tainted 4.3.0-rc5-amd64 #1 Debian 4.3~rc5-1~exp1 Oct 20 11:34:22 debian kernel: [ 102.838930] Hardware name: Acer TravelMate 4530 /Elgon , BIOS V1.11 08/06/2008 Oct 20 11:34:22 debian kernel: [ 102.838938] Workqueue: events_unbound async_run_entry_fn Oct 20 11:34:22 debian kernel: [ 102.838943] 817f5230 812c0349 8106ee11 Oct 20 11:34:22 debian kernel: [ 102.838949] a00de839 8800b8287d70 0001 88009cefa168 Oct 20 11:34:22 debian kernel: [ 102.838954] 81081e99 88012d4c85c0 88012548bba0 Oct 20 11:34:22 debian kernel: [ 102.838960] Call Trace: Oct 20 11:34:22 debian kernel: [ 102.838974] [] ? dump_stack+0x40/0x57 Oct 20 11:34:22 debian kernel: [ 102.838980] [] ? warn_slowpath_common+0x81/0xb0 Oct 20 11:34:22 debian kernel: [ 102.838989] [] ? __request_module+0x1e9/0x290 Oct 20 11:34:22 debian kernel: [ 102.838995] [] ? mutex_lock+0xe/0x30 Oct 20 11:34:22 debian kernel: [ 102.839004] [] ? kernfs_activate+0x65/0xe0 Oct 20 11:34:22 debian kernel: [ 102.839010] [] ? kernfs_add_one+0x100/0x160 Oct 20 11:34:22 debian kernel: [ 102.839048] [] ? scsi_dh_lookup+0x29/0x40 [scsi_mod] Oct 20 11:34:22 debian kernel: [ 102.839067] [] ? scsi_dh_add_device+0xca/0xf0 [scsi_mod] Oct 20 11:34:22 debian kernel: [ 102.839085] [] ? scsi_sysfs_add_sdev+0xb8/0x
Processed: Re: Bug#661193: linux-tools-3.2: perf fails to annotate code with separate debug info under some conditions
Processing control commands: > found -1 linux-tools/4.2-2 Bug #661193 [linux-tools-3.2] linux-tools-3.2: perf fails to annotate code with separate debug info under some conditions Marked as found in versions linux-tools/4.2-2. > tags -1 + fixed-upstream Bug #661193 [linux-tools-3.2] linux-tools-3.2: perf fails to annotate code with separate debug info under some conditions Added tag(s) fixed-upstream. -- 661193: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661193 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#661193: linux-tools-3.2: perf fails to annotate code with separate debug info under some conditions
Control: found -1 linux-tools/4.2-2 Control: tags -1 + fixed-upstream On 2012-02-24 23:11 +0100, Sami Liedes wrote: > 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 should be fixed in Linus' tree with commit 5baecbcd9c9a2f491afe1369fc22e7363f9c94d5[1], but I haven't tested it. Cheers, Sven 1. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5baecbcd9c9a2f491afe1369fc22e7363f9c94d5
