Re: Bug#661069: d-i: radeon: Please make sure firmware is installed or the user warned about its lack
Quoting Ben Hutchings (b...@decadent.org.uk): Maybe the linux-image packages should also warn in case 1, probably using a different message. I have no specific advice about this but if that's the plan, pretty please put me into the loop (as I guess this will be done through debconf) so that I can coordinate a translation update round. signature.asc Description: Digital signature
Re: Bug#661379: debian-installer: Keyboard connected via Logitech Unifying sender/receiver stops working during installation
reassign 661379 linux tags 661379 d-i retitle 661379 Missing hid_logitech_dj module in D-I kernel thanks Quoting Matt Horan (m...@matthoran.com): I am seeing this behavior as well, and it makes installing Debian with my wireless keyboard and mouse impossible. The keyboard and mouse work fine when the system is up and running under wheezy. However, I wanted to reinstall wheezy, but cannot because the keyboard and mouse do not work in the installer. When the system is up and running, I see that the hid_logitech_dj module is loaded. Not sure if this is possibly missing from the installer. The choice of modules in the D-I kernel is shorter (for size issues) so it's very likely that adding this module could help. I see this in debian/installer/modules/input-modules: hid usbhid hid-apple ? hid-belkin ? hid-microsoft ? hid-logitech ? hid-monterey ? hid-sunplus ? hid-cherry ? synaptics_usb ? wistron_btns ? Dunno what the ? means but anyway, I see no hid-logitech-dj here... I suspect it was named hid-logitech and got renamed to hid-logitech-dj Kernel team? signature.asc Description: Digital signature
Processed: Re: Bug#661379: debian-installer: Keyboard connected via Logitech Unifying sender/receiver stops working during installation
Processing commands for cont...@bugs.debian.org: reassign 661379 linux Bug #661379 [debian-installer] debian-installer: Keyboard connected via Logitech Unifying sender/receiver stops working during installation Bug reassigned from package 'debian-installer' to 'linux'. Ignoring request to alter found versions of bug #661379 to the same values previously set Ignoring request to alter fixed versions of bug #661379 to the same values previously set tags 661379 d-i Bug #661379 [linux] debian-installer: Keyboard connected via Logitech Unifying sender/receiver stops working during installation Added tag(s) d-i. retitle 661379 Missing hid_logitech_dj module in D-I kernel Bug #661379 [linux] debian-installer: Keyboard connected via Logitech Unifying sender/receiver stops working during installation Changed Bug title to 'Missing hid_logitech_dj module in D-I kernel' from 'debian-installer: Keyboard connected via Logitech Unifying sender/receiver stops working during installation' thanks Stopping processing here. Please contact me if you need assistance. -- 661379: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661379 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.134423448719699.transcr...@bugs.debian.org
Bug#680513: linux-image-3.4-trunk-amd64: bad rss-counter state
Hi Michael, Michael Below wrote: after the system had been idle (lunch break) I found a message BUG: bad rss-counter state in the log file, see below It seems to be solved here: https://lkml.org/lkml/2012/6/9/47 For reference, that link leads to commit 4fe7efdbdfb1c7e7a7f31decfd831c0f31d37091 Author: Konstantin Khlebnikov khlebni...@openvz.org Date: Wed Jun 20 12:53:01 2012 -0700 mm: correctly synchronize rss-counters at exit/exec which is part of 3.5-rc4. Was this crash reproducible? Does upgrading to 3.5 from experimental avoid trouble? Am I correct in guessing that 3.2.y from wheezy is not affected? Thanks for reporting and hope that helps, Jonathan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120806073340.GA27887@mannheim-rule.local
Bug#678215: [wheezy] USB mouse not recognized after resuming from suspend to RAM
Hi again, Jonathan Nieder wrote: Paul Menzel wrote: the mouse is not working after resuming from suspend to RAM. Replugging the mouse works although that is quite inconvenient. [...] - how does the 3.4.y kernel from experimental behave? - how does the 2.6.32.y kernel from stable behave? (It should work fine on a wheezy/sid system.) Beyond that, I have no great ideas, so if this is reproducible with 3.4.y, please send a summary of the symptoms to linux-...@vger.kernel.org, cc-ing either me or this bug log so we can track it. Be sure to mention Ping. Did you get a chance to try a newer or older kernel, and if so, what was the result? In suspense, Jonathan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120806072724.GA27874@mannheim-rule.local
Bug#680707: marked as done (Asus P5NSLI: lockup on resume from suspend)
Your message dated Mon, 6 Aug 2012 00:47:54 -0700 with message-id 20120806074754.GA27940@mannheim-rule.local and subject line Re: [3.3 - 3.4-rc1 regression] Asus P5NSLI: lockup on resume from suspend has caused the Debian Bug report #680707, regarding Asus P5NSLI: lockup on resume from suspend 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.) -- 680707: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680707 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: src:linux Version: 3.2.20-1 Severity: normal Dear Maintainer, Since upgrading to kernel 3.2, I'm unable to suspend my PC. I configured the button to do something like what pm-suspend does. Kernel 3.1 (linux-image-3.1.0-1-686-pae version 3.1.8-2) does NOT exhibit this problem. As of today, I'm falling back to that version to be able to suspend my PC. If I remove the ohci_hcd module, pm-suspend works again. Of course, I lose my keyboard, mouse and sometimes my flash drive (I *think* I saw it picked up by ehci_hcd, but I'm really not sure if this makes sense at all). Thank you very much! -- Package-specific info: ** Version: Linux version 3.2.0-2-686-pae (Debian 3.2.20-1) (debian-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-7) ) #1 SMP Mon Jun 11 18:27:04 UTC 2012 ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.2.0-2-686-pae root=UUID=f8b60c34-b27c-4517-be16-efe785260da8 ro quiet splash vmalloc=256M ** Tainted: O (4096) * Out-of-tree module has been loaded. ** Kernel log: [8.439477] [drm] radeon: 1024M of VRAM memory ready [8.439479] [drm] radeon: 512M of GTT memory ready. [8.439503] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [8.439505] [drm] Driver supports precise vblank timestamp query. [8.439555] radeon :01:00.0: irq 45 for MSI/MSI-X [8.439562] radeon :01:00.0: radeon: using MSI. [8.439596] [drm] radeon: irq initialized. [8.439602] [drm] GART: num cpu pages 131072, num gpu pages 131072 [8.440444] [drm] Loading CEDAR Microcode [8.921180] [drm] PCIE GART of 512M enabled (table at 0x0004). [8.921293] radeon :01:00.0: WB enabled [8.938654] [drm] ring test succeeded in 1 usecs [8.938835] [drm] radeon: ib pool ready. [8.938923] [drm] ib test succeeded in 0 usecs [8.939970] [drm] Radeon Display Connectors [8.939973] [drm] Connector 0: [8.939975] [drm] HDMI-A [8.939977] [drm] HPD2 [8.939979] [drm] DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c 0x644c [8.939982] [drm] Encoders: [8.939984] [drm] DFP1: INTERNAL_UNIPHY1 [8.939986] [drm] Connector 1: [8.939987] [drm] DVI-I [8.939989] [drm] HPD4 [8.939991] [drm] DDC: 0x6460 0x6460 0x6464 0x6464 0x6468 0x6468 0x646c 0x646c [8.940024] [drm] Encoders: [8.940026] [drm] DFP2: INTERNAL_UNIPHY [8.940028] [drm] CRT1: INTERNAL_KLDSCP_DAC1 [8.940030] [drm] Connector 2: [8.940031] [drm] VGA [8.940034] [drm] DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 0x643c [8.940036] [drm] Encoders: [8.940038] [drm] CRT2: INTERNAL_KLDSCP_DAC2 [8.940069] [drm] Internal thermal controller with fan control [8.940119] [drm] radeon: power management initialized [9.083327] [drm] fb mappable at 0xC0142000 [9.083331] [drm] vram apper at 0xC000 [9.08] [drm] size 8294400 [9.083335] [drm] fb depth is 24 [9.083336] [drm]pitch is 7680 [9.083432] fbcon: radeondrmfb (fb0) is primary device [9.334673] ACPI: PCI Interrupt Link [AAZA] enabled at IRQ 23 [9.334681] snd_hda_intel :00:10.1: PCI INT B - Link[AAZA] - GSI 23 (level, low) - IRQ 23 [9.334684] hda_intel: Disabling MSI [9.334710] snd_hda_intel :00:10.1: setting latency timer to 64 [9.339256] Console: switching to colour frame buffer device 160x64 [9.345989] fb0: radeondrmfb frame buffer device [9.345991] drm: registered panic notifier [9.346014] [drm] Initialized radeon 2.12.0 20080528 for :01:00.0 on minor 0 [ 10.118176] input: HDA Digital PCBeep as /devices/pci:00/:00:10.1/input/input6 [ 10.268374] ACPI: PCI Interrupt Link [APC6] enabled at IRQ 16 [ 10.268382] snd_hda_intel :01:00.1: PCI INT B - Link[APC6] - GSI 16 (level, low) - IRQ 16 [ 10.268466] snd_hda_intel :01:00.1: irq 46 for MSI/MSI-X [ 10.268494] snd_hda_intel :01:00.1: setting latency timer to 64 [ 10.492653] HDMI status: Codec=0 Pin=3 Presence_Detect=0 ELD_Valid=0 [ 10.492786] input: HD-Audio Generic HDMI/DP,pcm=3 as
Bug#679158: asus-wmi: use ASUS_WMI_METHODID_DSTS2 as default DSTS ID
tags 679158 + fixed-upstream quit Carsten Otto wrote: The patch works, dmesg before and after are attached. Thanks! Queued for 3.2.27 as asus-wmi-use-asus_wmi_methodid_dsts2-as-default-dsts-id.patch. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120806083332.GA28058@mannheim-rule.local
Processed: Re: asus-wmi: use ASUS_WMI_METHODID_DSTS2 as default DSTS ID
Processing commands for cont...@bugs.debian.org: tags 679158 + fixed-upstream Bug #679158 [src:linux] asus-wmi: use ASUS_WMI_METHODID_DSTS2 as default DSTS ID Added tag(s) fixed-upstream. quit Stopping processing here. Please contact me if you need assistance. -- 679158: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679158 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.134424202528356.transcr...@bugs.debian.org
Bug#598144: very low transfers and link quality
Package: linux-2.6 Version: 2.6.32-45 Severity: normal I am receiving a similar issue as the bug reporter. As can be seen below, my kernel log is spammed with the same error. Using the Debian Squeeze ISO as a baseline, the machine tops out downloading the ISO at around 80 kb/s. Another machine on the same access point via an Atheros card dowloads from the same mirror at over 1 Mb/s. As can be seen in the kernel log below, the logged message can be stopped; I did so by issuing the command: # iwconfig wlan0 power off However, I still receive poor throughput. I can reproduce these issues, and would like to help with the ticket. -- Nate -- Package-specific info: ** Version: Linux version 2.6.32-5-amd64 (Debian 2.6.32-45) (da...@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Sun May 6 04:00:17 UTC 2012 ** Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-amd64 root=UUID=f6b41718-95f9-4189-97e9-e85a5aeb99fc ro quiet ** Tainted: P (1) * Proprietary module has been loaded. ** Kernel log: [ 808.608158] phy0 - rt2500pci_set_device_state: Error - Device failed to enter state 1 (-16). [ 808.888155] phy0 - rt2500pci_set_device_state: Error - Device failed to enter state 1 (-16). [ 809.764160] phy0 - rt2500pci_set_device_state: Error - Device failed to enter state 1 (-16). [ 810.012487] phy0 - rt2500pci_set_device_state: Error - Device failed to enter state 1 (-16). [ 810.800159] phy0 - rt2500pci_set_device_state: Error - Device failed to enter state 1 (-16). [ 812.552161] phy0 - rt2500pci_set_device_state: Error - Device failed to enter state 1 (-16). [ 812.852161] phy0 - rt2500pci_set_device_state: Error - Device failed to enter state 1 (-16). [ 813.736161] phy0 - rt2500pci_set_device_state: Error - Device failed to enter state 1 (-16). [ 814.436151] phy0 - rt2500pci_set_device_state: Error - Device failed to enter state 1 (-16). [ 814.900162] phy0 - rt2500pci_set_device_state: Error - Device failed to enter state 1 (-16). [ 815.984492] phy0 - rt2500pci_set_device_state: Error - Device failed to enter state 1 (-16). [ 816.324491] phy0 - rt2500pci_set_device_state: Error - Device failed to enter state 1 (-16). [ 817.868160] phy0 - rt2500pci_set_device_state: Error - Device failed to enter state 1 (-16). [ 818.688162] phy0 - rt2500pci_set_device_state: Error - Device failed to enter state 1 (-16). [ 821.244152] phy0 - rt2500pci_set_device_state: Error - Device failed to enter state 1 (-16). [ 826.016161] phy0 - rt2500pci_set_device_state: Error - Device failed to enter state 1 (-16). [ 826.348169] phy0 - rt2500pci_set_device_state: Error - Device failed to enter state 1 (-16). [ 827.020161] phy0 - rt2500pci_set_device_state: Error - Device failed to enter state 1 (-16). [ 827.216153] phy0 - rt2500pci_set_device_state: Error - Device failed to enter state 1 (-16). [ 828.816173] phy0 - rt2500pci_set_device_state: Error - Device failed to enter state 1 (-16). [ 829.060146] phy0 - rt2500pci_set_device_state: Error - Device failed to enter state 1 (-16). [ 829.776158] phy0 - rt2500pci_set_device_state: Error - Device failed to enter state 1 (-16). [ 829.980490] phy0 - rt2500pci_set_device_state: Error - Device failed to enter state 1 (-16). [ 830.208159] phy0 - rt2500pci_set_device_state: Error - Device failed to enter state 1 (-16). [ 830.872160] phy0 - rt2500pci_set_device_state: Error - Device failed to enter state 1 (-16). [ 831.484159] phy0 - rt2500pci_set_device_state: Error - Device failed to enter state 1 (-16). [ 834.048151] phy0 - rt2500pci_set_device_state: Error - Device failed to enter state 1 (-16). [ 834.780162] phy0 - rt2500pci_set_device_state: Error - Device failed to enter state 1 (-16). [ 835.712152] phy0 - rt2500pci_set_device_state: Error - Device failed to enter state 1 (-16). [ 835.920154] phy0 - rt2500pci_set_device_state: Error - Device failed to enter state 1 (-16). [ 839.468158] phy0 - rt2500pci_set_device_state: Error - Device failed to enter state 1 (-16). [ 839.708147] phy0 - rt2500pci_set_device_state: Error - Device failed to enter state 1 (-16). [ 840.808484] phy0 - rt2500pci_set_device_state: Error - Device failed to enter state 1 (-16). [ 844.000150] phy0 - rt2500pci_set_device_state: Error - Device failed to enter state 1 (-16). [ 844.216159] phy0 - rt2500pci_set_device_state: Error - Device failed to enter state 1 (-16). [ 849.144160] phy0 - rt2500pci_set_device_state: Error - Device failed to enter state 1 (-16). [ 850.228159] phy0 - rt2500pci_set_device_state: Error - Device failed to enter state 1 (-16). [ 850.944159] phy0 - rt2500pci_set_device_state: Error - Device failed to enter state 1 (-16). [ 851.176143] phy0 - rt2500pci_set_device_state: Error - Device failed to enter state 1 (-16). [ 855.128151] phy0 - rt2500pci_set_device_state: Error - Device failed to enter state 1 (-16). [ 855.780159] phy0 - rt2500pci_set_device_state: Error - Device failed to enter state 1 (-16). [
Bug#680513: linux-image-3.4-trunk-amd64: bad rss-counter state
Hi, Am Montag, den 06.08.2012, 00:33 -0700 schrieb Jonathan Nieder: Was this crash reproducible? Does upgrading to 3.5 from experimental avoid trouble? Am I correct in guessing that 3.2.y from wheezy is not affected? Yes, it is reproducible, the error happens daily a couple of times if I am running 3.4 from experimental. Mostly, I see it during shutdown. But it's not a crash that brings down the system. I haven't seen this bug with 3.2 kernels. I will try the 3.5 kernel soon, but first I will see what I can tell you about the rcu_sched_state bug in 3.2 (#656196). Thanks Michael -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1344243545.5521.6.camel@ossietzky
Processed: Re: ath5k phy0: noise floor calibration timeout
Processing commands for cont...@bugs.debian.org: # merging optimistically tags 666969 - moreinfo Bug #666969 [linux-2.6] linux-image-2.6.32-5-amd64: ath5k noise floor calibration timeout Removed tag(s) moreinfo. forcemerge 611107 666969 Bug #611107 [linux-2.6] ath5k: noise floor calibration timeout Bug #666969 [linux-2.6] linux-image-2.6.32-5-amd64: ath5k noise floor calibration timeout Severity set to 'normal' from 'important' Marked as fixed in versions linux-2.6/3.0.0-1. There is no source info for the package 'linux-2.6' at version '2.6.32-30' with architecture '' Unable to make a source version for version '2.6.32-30' There is no source info for the package 'linux-2.6' at version '2.6.32-41squeeze2' with architecture '' Unable to make a source version for version '2.6.32-41squeeze2' The source linux-2.6 and version 2.6.32-38 do not appear to match any binary packages Marked as found in versions linux-2.6/2.6.32-38, 2.6.32-30, and linux-2.6/2.6.32-45. Added tag(s) pending. Bug #611107 [linux-2.6] ath5k: noise floor calibration timeout There is no source info for the package 'linux-2.6' at version '2.6.32-30' with architecture '' Unable to make a source version for version '2.6.32-30' There is no source info for the package 'linux-2.6' at version '2.6.32-41squeeze2' with architecture '' Unable to make a source version for version '2.6.32-41squeeze2' The source linux-2.6 and version 2.6.32-38 do not appear to match any binary packages Marked as found in versions 2.6.32-41squeeze2. Merged 611107 666969 End of message, stopping processing here. Please contact me if you need assistance. -- 611107: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611107 666969: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666969 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.13442442709507.transcr...@bugs.debian.org
Bug#598144: rt2500pci: very low transfers and link quality
submitter 598144 Nathan Schulte nmschu...@gmail.com tags 598144 - unreproducible quit Hi Nathan, Nathan Schulte wrote: I am receiving a similar issue as the bug reporter. As can be seen below, my kernel log is spammed with the same error. Using the Debian Squeeze ISO as a baseline, the machine tops out downloading the ISO at around 80 kb/s. Another machine on the same access point via an Atheros card dowloads from the same mirror at over 1 Mb/s. As can be seen in the kernel log below, the logged message can be stopped; I did so by issuing the command: # iwconfig wlan0 power off However, I still receive poor throughput. I can reproduce these issues, and would like to help with the ticket. Thanks! I'm setting you as the new contact for this bug. Can you try a 3.x.y kernel from squeeze-backports, sid, or experimental? The only packages from outside squeeze that should be needed for this test aside from the kernel itself are linux-base and initramfs-tools. If it works well, we can try to track down what change fixed it and apply the same fix to squeeze. If it doesn't work well, we can try to reproduce it without the nvidia driver and then get help from upstream. So either result is a win. Hope that helps, Jonathan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120806093051.GB28150@mannheim-rule.local
Processed: Re: rt2500pci: very low transfers and link quality
Processing commands for cont...@bugs.debian.org: submitter 598144 Nathan Schulte nmschu...@gmail.com Bug #598144 [linux-2.6] rt2500pci: very low transfers and link quality Changed Bug submitter to 'Nathan Schulte nmschu...@gmail.com' from 'David Sánchez Herrero david.kru...@gmail.com' tags 598144 - unreproducible Bug #598144 [linux-2.6] rt2500pci: very low transfers and link quality Removed tag(s) unreproducible. quit Stopping processing here. Please contact me if you need assistance. -- 598144: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598144 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.134424545615398.transcr...@bugs.debian.org
SUPER3deals: Vibratone -45 lei/ Slap -chop -15lei/ Cooler laptop - 19 lei
Daca nu vizualizati corect acest mail faceti click aici: http://www.pretulverde.ro/SUPER3deals.html Va puteti dezabona aici: http://www.pretulverde.ro/letter/?p=unsubscribeuid=2e8d441d9e584c88b54469869ef35b4e Sau puteti trimite oferta noastra unui prieten: http://www.pretulverde.ro/letter/?p=forwarduid=2e8d441d9e584c88b54469869ef35b4emid=105 -- powered by phpList, www.phplist.com -- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/db894a114a6d62b6c436b6cfdf3bc...@www.pretulverde.ro
Bug#598144: rt2500pci: very low transfers and link quality
Jonathan Nieder wrote: Thanks! I'm setting you as the new contact for this bug. Okay, sounds good. I hope I can help solve this. Can you try a 3.x.y kernel from squeeze-backports, sid, or experimental? The only packages from outside squeeze that should be needed for this test aside from the kernel itself are linux-base and initramfs-tools. If it works well, we can try to track down what change fixed it and apply the same fix to squeeze. If it doesn't work well, we can try to reproduce it without the nvidia driver and then get help from upstream. So either result is a win. I was already on it, :). I ran into a hiccup, but I've worked through it. $ uname -a Linux desmas-s 3.2.0-0.bpo.2-amd64 #1 SMP Fri Jun 29 20:42:29 UTC 2012 x86_64 GNU/Linux Downloading the same ISO from the mirror gives 40 kb/s average, peaked at 100kb/s once. The same ISO on the machine with the Atheros chip gives over 1Mb/s still. It looks like the problem is still prevalent. Where to now? Output from dmesg is attached. -- Nate [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.2.0-0.bpo.2-amd64 (Debian 3.2.20-1~bpo60+1) (debian-kernel@lists.debian.org) (gcc version 4.4.5 (Debian 4.4.5-8) ) #1 SMP Fri Jun 29 20:42:29 UTC 2012 [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.2.0-0.bpo.2-amd64 root=UUID=f6b41718-95f9-4189-97e9-e85a5aeb99fc ro quiet [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009f800 (usable) [0.00] BIOS-e820: 0009f800 - 000a (reserved) [0.00] BIOS-e820: 000e6000 - 0010 (reserved) [0.00] BIOS-e820: 0010 - 7fea (usable) [0.00] BIOS-e820: 7fea - 7feb (ACPI data) [0.00] BIOS-e820: 7feb - 7fee (ACPI NVS) [0.00] BIOS-e820: 7fee - 7ff0 (reserved) [0.00] BIOS-e820: fff0 - 0001 (reserved) [0.00] NX (Execute Disable) protection: active [0.00] DMI present. [0.00] DMI: To Be Filled By O.E.M. To Be Filled By O.E.M./A785GM-LE, BIOS P1.20 04/22/2010 [0.00] e820 update range: - 0001 (usable) == (reserved) [0.00] e820 remove range: 000a - 0010 (usable) [0.00] No AGP bridge found [0.00] last_pfn = 0x7fea0 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-E uncachable [0.00] F-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 00 mask FF8000 write-back [0.00] 1 disabled [0.00] 2 disabled [0.00] 3 disabled [0.00] 4 disabled [0.00] 5 disabled [0.00] 6 disabled [0.00] 7 disabled [0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [0.00] found SMP MP-table at [880ff780] ff780 [0.00] initial memory mapped : 0 - 2000 [0.00] Base memory trampoline at [8809a000] 9a000 size 20480 [0.00] init_memory_mapping: -7fea [0.00] 00 - 007fe0 page 2M [0.00] 007fe0 - 007fea page 4k [0.00] kernel direct mapping tables up to 7fea @ 1fffc000-2000 [0.00] RAMDISK: 375d1000 - 37ff [0.00] ACPI: RSDP 000fb940 00014 (v00 ACPIAM) [0.00] ACPI: RSDT 7fea 00044 (v01 042210 RSDT1540 20100422 MSFT 0097) [0.00] ACPI: FACP 7fea0200 00084 (v01 A_M_I OEMFACP 12000601 MSFT 0097) [0.00] ACPI Warning: Optional field Pm2ControlBlock has zero address or length: 0x/0x1 (20110623/tbfadt-560) [0.00] ACPI: DSDT 7fea0450 091A9 (v01 AS267 AS267113 0113 INTL 20051117) [0.00] ACPI: FACS 7feb 00040 [0.00] ACPI: APIC 7fea0390 0007C (v01 042210 APIC1540 20100422 MSFT 0097) [0.00] ACPI: MCFG 7fea0410 0003C (v01 042210 OEMMCFG 20100422 MSFT 0097) [0.00] ACPI: OEMB 7feb0040 00072 (v01 042210 OEMB1540 20100422 MSFT 0097) [0.00] ACPI: SRAT 7feaa450 000A0 (v03 AMDFAM_F_10 0002 AMD 0001) [0.00] ACPI: AAFT 7feaa4f0 00027 (v01 042210 OEMAAFT 20100422 MSFT 0097) [0.00] ACPI: HPET 7feaa520 00038 (v01 042210 OEMHPET 20100422 MSFT 0097) [0.00] ACPI: SSDT 7feaa560 002CC (v01 A M I POWERNOW 0001 AMD 0001) [0.00] ACPI: Local APIC address 0xfee0 [0.00] SRAT: PXM 0 - APIC 0x00 - Node 0 [0.00] SRAT: PXM 0 - APIC 0x01 - Node 0 [0.00] SRAT: Node 0 PXM 0 0-a [
Re: Bug#661379: debian-installer: Keyboard connected via Logitech Unifying sender/receiver stops working during installation
Christian PERRIER, le Mon 06 Aug 2012 08:27:56 +0200, a écrit : Dunno what the ? means It means not to fail if the module does not actually exist, which is useful when the availability depends on the arch. Samuel -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120806101238.gd32...@type.famille.thibault.fr
Bug#598144: rt2500pci: very low transfers and link quality
Nathan Schulte wrote: I am receiving a similar issue as the bug reporter. As can be seen below, my kernel log is spammed with the same error. Using the Debian Squeeze ISO as a baseline, the machine tops out downloading the ISO at around 80 kb/s. Another machine on the same access point via an Atheros card dowloads from the same mirror at over 1 Mb/s. Downloading the same ISO from the mirror gives 40 kb/s average, peaked at 100kb/s once. The same ISO on the machine with the Atheros chip gives over 1Mb/s still. Oops! I meant bytes, not bits. Sub 100 kilobytes per second on the Ralink, and over 1 megabyte per second on the Atheros, for both kernels. -- Nate -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/501fa0fe.7060...@gmail.com
Bug#678215: [wheezy] USB mouse not recognized after resuming from suspend to RAM
Dear Jonathan, I am sorry for not reporting back on this issue. Am Montag, den 06.08.2012, 00:27 -0700 schrieb Jonathan Nieder: Jonathan Nieder wrote: Paul Menzel wrote: the mouse is not working after resuming from suspend to RAM. Replugging the mouse works although that is quite inconvenient. [...] - how does the 3.4.y kernel from experimental behave? - how does the 2.6.32.y kernel from stable behave? (It should work fine on a wheezy/sid system.) Beyond that, I have no great ideas, so if this is reproducible with 3.4.y, please send a summary of the symptoms to linux-...@vger.kernel.org, cc-ing either me or this bug log so we can track it. Be sure to mention Ping. Did you get a chance to try a newer or older kernel, and if so, what was the result? I contacted linux-...@vger.kernel.org [1][2] and it looks like that the mouse and the ASUS M2A-VM do not get along. Currently the motherboard is replaced by a different board ASRock A780Full HD and the USB mouse works without any problems with it. I am not certain if I am going to have the chance to test this again with the ASUS M2A-VM. So maybe we should just close this bug as (currently) unreproducible or moreinfo? Thanks, Paul [1] http://www.spinics.net/lists/linux-usb/msg65853.html [2] http://www.spinics.net/lists/linux-usb/msg65903.html signature.asc Description: This is a digitally signed message part
Bug#684041: linux-image-3.5-trunk-amd64: Intel GPU hang caught
Package: src:linux Version: 3.5-1~experimental.1 Severity: normal Hello, After upgrading to linux-image-3.5 the X server freezes after some time. Most of the time this happens when to switch from an xterm to another desktop, xterm still works (commands can still be executed), terminal output can still be seen, but the rest of the screen is not updated anymore, not even on switch to another virtual desktop. Switching to another VT works and kernel console (kms) works. Recovery is only really possible with a reboot. Kernel linux-image-3.2.0-2-amd64 worked without any problems, uptime 40 days (same x-server as for 3.5) Kernel error message: [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung X org error message: Some message about possible corrupted screen state. Seems a common problem with 3.5 ubuntu has identical bugreports. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1022879 greets, Michael -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: LENOVO product_name: 7469WA2 product_version: ThinkPad X200s chassis_vendor: LENOVO chassis_version: Not Available bios_vendor: LENOVO bios_version: 6DET40WW (2.04 ) board_vendor: LENOVO board_name: 7469WA2 board_version: Not Available ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub [8086:2a40] (rev 07) Subsystem: Lenovo Device [17aa:20e0] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort+ SERR- PERR- INTx- Latency: 0 Capabilities: access denied Kernel driver in use: agpgart-intel 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07) (prog-if 00 [VGA controller]) Subsystem: Lenovo Device [17aa:20e4] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 46 Region 0: Memory at f200 (64-bit, non-prefetchable) [size=4M] Region 2: Memory at d000 (64-bit, prefetchable) [size=256M] Region 4: I/O ports at 1800 [size=8] Expansion ROM at unassigned [disabled] Capabilities: access denied Kernel driver in use: i915 00:02.1 Display controller [0380]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a43] (rev 07) Subsystem: Lenovo Device [17aa:20e4] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Region 0: Memory at f240 (64-bit, non-prefetchable) [size=1M] Capabilities: access denied 00:03.0 Communication controller [0780]: Intel Corporation Mobile 4 Series Chipset MEI Controller [8086:2a44] (rev 07) Subsystem: Lenovo Device [17aa:20e6] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx+ Latency: 0 Interrupt: pin A routed to IRQ 11 Region 0: Memory at f2826800 (64-bit, non-prefetchable) [size=16] Capabilities: access denied 00:19.0 Ethernet controller [0200]: Intel Corporation 82567LM Gigabit Network Connection [8086:10f5] (rev 03) Subsystem: Lenovo Device [17aa:20ee] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 43 Region 0: Memory at f260 (32-bit, non-prefetchable) [size=128K] Region 1: Memory at f2625000 (32-bit, non-prefetchable) [size=4K] Region 2: I/O ports at 1840 [size=32] Capabilities: access denied Kernel driver in use: e1000e 00:1a.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 [8086:2937] (rev 03) (prog-if 00 [UHCI]) Subsystem: Lenovo Device [17aa:20f0] Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 20 Region 4: I/O ports at 1860 [size=32] Capabilities: access denied Kernel driver in use: uhci_hcd 00:1a.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9
Bug#683768: linux-image-3.2.0-3-amd64: hibernate 3x slower after upgrade to linux-image-3.2.0-3-amd64
On Sun, Aug 5, 2012 at 6:36 PM, Ben Hutchings b...@decadent.org.uk wrote:
On Sun, 2012-08-05 at 17:50 -0500, hugo vanwoerkom wrote:
[...]
Yes, 3.2.19-1 still takes 12s. But as to problems
disappearing/appearing I could have sworn that 3.2.21-3 took 12s. last
night but now it takes 35s. I think the problem comes from the kernel,
because that is the only thing that I am varying and I have been
hibernating this box for years with up to now predictable speeds.
Don't use wicd though.
If the change was made between 3.2.19 and 3.2.21 then it might be due
to:
commit d006ab31cd818f5e4dda2453fd09767063f49933
Author: Michal Hocko mho...@suse.cz
Date: Tue May 29 15:06:45 2012 -0700
mm: consider all swapped back pages in used-once logic
So you could test with the reverse of that patch (attached), following
the instructions at
http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s4.2.2
I tested all the snapshot kernels again and the change occurred with
3.2.21-1. That is the first one to have a hibernate of 35s. The one
previous to that 3.2.20-1 is fine with 10s. These results are consistent.
It could not be the mm vmscan patch because both 3.2.20-1 and 3.2.21-1 have
that set the same way:
if (referenced_ptes) {
if (PageSwapBacked(page))
return PAGEREF_ACTIVATE;
Hugo
Bug#683807: R: Bug#683807: R: Bug#683807: R: Re: Segfault while using mv/fusermount -u with sshfs share
Hi, This morning when you sent your message i disabled bumblebee and nvidia, i rebooted and then i verified kernel.tainted. The value was 0. (ok) But today, I suspended-to-ram the notebook and i resumed after 2 minutes. Now , almost 30 minutes later, iceweasel crashed 3 times, each time it crashes just a few seconds after the launch. I noticed this in the syslog: (time is italian time) : Aug 6 14:51:45 stan kernel: [37168.409654] NVRM: No NVIDIA graphics adapter found! Aug 6 14:51:45 stan kernel: [37168.607847] NVRM: No NVIDIA graphics adapter found! Aug 6 14:51:45 stan kernel: [37168.811535] NVRM: No NVIDIA graphics adapter found! Aug 6 14:54:55 stan kernel: [37358.716872] NVRM: No NVIDIA graphics adapter found! Aug 6 14:54:56 stan kernel: [37358.890747] NVRM: No NVIDIA graphics adapter found! Aug 6 14:54:56 stan kernel: [37359.089789] NVRM: No NVIDIA graphics adapter found! Aug 6 14:56:01 stan kernel: [37424.221231] NVRM: No NVIDIA graphics adapter found! Aug 6 14:56:01 stan kernel: [37424.415548] NVRM: No NVIDIA graphics adapter found! Aug 6 14:56:01 stan kernel: [37424.579289] NVRM: No NVIDIA graphics adapter found! Aug 6 14:57:07 stan kernel: [37490.289895] NVRM: No NVIDIA graphics adapter found! Aug 6 14:57:08 stan kernel: [37490.487921] NVRM: No NVIDIA graphics adapter found! Aug 6 14:57:08 stan kernel: [37490.691978] NVRM: No NVIDIA graphics adapter found! Aug 6 14:58:05 stan kernel: [37548.337713] NVRM: No NVIDIA graphics adapter found! Aug 6 14:58:06 stan kernel: [37548.534012] NVRM: No NVIDIA graphics adapter found! Aug 6 14:58:06 stan kernel: [37548.732858] NVRM: No NVIDIA graphics adapter found! Aug 6 15:02:12 stan kernel: [37794.609294] intel ips :00:1f.6: MCP limit exceeded: Avg power 40218, limit 35000 Aug 6 15:04:07 stan kernel: [37909.381592] intel ips :00:1f.6: MCP limit exceeded: Avg power 39909, limit 35000 Aug 6 15:05:04 stan kernel: [37966.530669] NVRM: No NVIDIA graphics adapter found! Aug 6 15:05:05 stan kernel: [37966.716222] NVRM: No NVIDIA graphics adapter found! Aug 6 15:05:05 stan kernel: [37966.890703] NVRM: No NVIDIA graphics adapter found! Aug 6 15:13:39 stan kernel: [38479.811089] NVRM: No NVIDIA graphics adapter found! Aug 6 15:13:39 stan kernel: [38479.966457] NVRM: No NVIDIA graphics adapter found! Aug 6 15:13:39 stan kernel: [38480.148372] NVRM: No NVIDIA graphics adapter found! and kernel was tainted: kernel.tainted = 4097 so i opted for a complete uninstallation of bumblebee apt-get remove bumblebee bumblebee-nvidia Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: bbswitch-dkms libglu1-mesa virtualgl virtualgl-libs virtualgl-libs-ia32 Use 'apt-get autoremove' to remove them. The following packages will be REMOVED: bumblebee bumblebee-nvidia 0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded. After this operation, 222 kB disk space will be freed. Do you want to continue [Y/n]? (Reading database ... 76865 files and directories currently installed.) Removing bumblebee-nvidia ... update-alternatives: using /usr/lib/nvidia to provide /usr/lib/glx (glx) in auto mode. update-alternatives: using /usr/lib32/nvidia/libGL.so.1 to provide /usr/lib32/libGL.so.1 (ia32-libGL.so.1) in auto mode. Removing bumblebee ... [ ok ] Stopping Bumblebee daemon: bumblebeed. Processing triggers for man-db ... and then apt-get autoremove now the No NVIDIA graphics adapter found! messages have stopped appearing. could the bbswitch module itself be the cause of those segfaults? note: i was connected via wireless when the problem appeared. browser is iceweasel 10.0.6 connected via Tor and using torbutton I had very similar segfaults recently (~ 1 or 2 weeks ago) with transmission- gtk. Also in that case it was a simple segfault (with Segmentation Fault in the xfce4-terminal) without any traces about that in the syslog. i've just rebooted now, uptime was 11 hours. After the reboot i tried to suspend-to-ram and there're no 'No NVIDIA' messages in the syslog this time. Asdrubale. Messaggio originale Da: b...@decadent.org.uk Data: 6-ago-2012 1.39 A: asronche...@libero.itasronche...@libero.it Cc: 683...@bugs.debian.org Ogg: Bug#683807: R: Bug#683807: R: Re: Segfault while using mv/quot; fusermount -uquot; with sshfs share [Re-sending with the bug address cc'd.] On Mon, 2012-08-06 at 01:14 +0200, asronche...@libero.it wrote: Hi Ben, Yes, i can try. I think a week could be enough (crashes happens in a day or two, on my notebook). I'll start with tomorrow morning (Monday). Do i need to uninstall all nvidia and bumblebee stuff and modules (modules: bbswitch and nvidia) or will this procedure be enough? 1) disable bumblebee service and nvidia-kernel, using the rcconf application. 2) blacklist bbswitch via /etc/modprobe.d/blacklist. 4) mount back the 8GB
Bug#684049: linux-image-3.2.0-3-amd64: syslog flooded with [e|o]hci_hcd related messages
Package: src:linux Version: 3.2.21-3 Severity: normal Dear Maintainer, Recently I noticed that syslog is flooded with these kind of messages: Aug 6 16:43:26 siika kernel: [ 657.856294] ehci_hcd :00:12.2: PME# enabled Aug 6 16:43:26 siika kernel: [ 658.324244] ehci_hcd :00:12.2: BAR 0: set to [mem 0xf034c000-0xf034c0ff] (PCI address [0xf034c000-0xf034c0ff]) Aug 6 16:43:26 siika kernel: [ 658.324357] ehci_hcd :00:12.2: restoring config space at offset 0x1 (was 0x2b0, writing 0x2b00013) Aug 6 16:43:26 siika kernel: [ 658.324419] ehci_hcd :00:12.2: PME# disabled Aug 6 16:43:26 siika kernel: [ 658.324445] ehci_hcd :00:12.2: PCI INT B - GSI 17 (level, low) - IRQ 17 Aug 6 16:43:26 siika kernel: [ 658.368211] ehci_hcd :00:13.2: BAR 0: set to [mem 0xf034a000-0xf034a0ff] (PCI address [0xf034a000-0xf034a0ff]) Aug 6 16:43:26 siika kernel: [ 658.368347] ehci_hcd :00:13.2: restoring config space at offset 0x1 (was 0x2b0, writing 0x2b00013) Aug 6 16:43:26 siika kernel: [ 658.368413] ehci_hcd :00:13.2: PME# disabled Aug 6 16:43:26 siika kernel: [ 658.368440] ehci_hcd :00:13.2: PCI INT B - GSI 17 (level, low) - IRQ 17 Aug 6 16:43:26 siika kernel: [ 658.396646] ohci_hcd :00:12.0: PCI INT A - GSI 18 (level, low) - IRQ 18 Aug 6 16:43:27 siika kernel: [ 658.528792] ohci_hcd :00:13.0: PCI INT A - GSI 18 (level, low) - IRQ 18 Aug 6 16:43:29 siika kernel: [ 660.809470] ohci_hcd :00:12.0: PCI INT A disabled Aug 6 16:43:29 siika kernel: [ 660.824144] ehci_hcd :00:13.2: PCI INT B disabled Aug 6 16:43:29 siika kernel: [ 660.824222] ehci_hcd :00:13.2: PME# enabled Aug 6 16:43:29 siika kernel: [ 660.825707] ohci_hcd :00:13.0: PCI INT A disabled Aug 6 16:43:31 siika kernel: [ 662.856405] ehci_hcd :00:12.2: PCI INT B disabled I have not noticed that something would not work, but the messages are annoying. I don't remember seeing them when I started using wheezy in April. -- Package-specific info: ** Version: Linux version 3.2.0-3-amd64 (Debian 3.2.21-3) (debian-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-8) ) #1 SMP Thu Jun 28 09:07:26 UTC 2012 ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.2.0-3-amd64 root=UUID=0c009ddc-ed8b-4e55-a799-0cf38e3174a4 ro ** Tainted: PO (4097) * Proprietary module has been loaded. * Out-of-tree module has been loaded. ** Kernel log: [ 813.809296] ohci_hcd :00:13.0: PCI INT A disabled [ 813.824258] ehci_hcd :00:13.2: PCI INT B disabled [ 813.824277] ohci_hcd :00:12.0: PCI INT A disabled [ 813.824513] ehci_hcd :00:13.2: PME# enabled [ 815.840121] ehci_hcd :00:12.2: PCI INT B disabled [ 815.840178] ehci_hcd :00:12.2: PME# enabled [ 816.552119] ehci_hcd :00:12.2: BAR 0: set to [mem 0xf034c000-0xf034c0ff] (PCI address [0xf034c000-0xf034c0ff]) [ 816.552171] ehci_hcd :00:12.2: restoring config space at offset 0x1 (was 0x2b0, writing 0x2b00013) [ 816.552221] ehci_hcd :00:12.2: PME# disabled [ 816.552240] ehci_hcd :00:12.2: PCI INT B - GSI 17 (level, low) - IRQ 17 [ 816.596144] ehci_hcd :00:13.2: BAR 0: set to [mem 0xf034a000-0xf034a0ff] (PCI address [0xf034a000-0xf034a0ff]) [ 816.596197] ehci_hcd :00:13.2: restoring config space at offset 0x1 (was 0x2b0, writing 0x2b00013) [ 816.596244] ehci_hcd :00:13.2: PME# disabled [ 816.596264] ehci_hcd :00:13.2: PCI INT B - GSI 17 (level, low) - IRQ 17 [ 816.624407] ohci_hcd :00:12.0: PCI INT A - GSI 18 (level, low) - IRQ 18 [ 816.760469] ohci_hcd :00:13.0: PCI INT A - GSI 18 (level, low) - IRQ 18 [ 818.825090] ohci_hcd :00:12.0: PCI INT A disabled [ 818.840193] ehci_hcd :00:13.2: PCI INT B disabled [ 818.840263] ehci_hcd :00:13.2: PME# enabled [ 818.864301] ohci_hcd :00:13.0: PCI INT A disabled [ 821.024084] ehci_hcd :00:12.2: PCI INT B disabled [ 821.024145] ehci_hcd :00:12.2: PME# enabled [ 822.012216] ehci_hcd :00:12.2: BAR 0: set to [mem 0xf034c000-0xf034c0ff] (PCI address [0xf034c000-0xf034c0ff]) [ 822.012350] ehci_hcd :00:12.2: restoring config space at offset 0x1 (was 0x2b0, writing 0x2b00013) [ 822.012415] ehci_hcd :00:12.2: PME# disabled [ 822.012441] ehci_hcd :00:12.2: PCI INT B - GSI 17 (level, low) - IRQ 17 [ 822.056297] ehci_hcd :00:13.2: BAR 0: set to [mem 0xf034a000-0xf034a0ff] (PCI address [0xf034a000-0xf034a0ff]) [ 822.056432] ehci_hcd :00:13.2: restoring config space at offset 0x1 (was 0x2b0, writing 0x2b00013) [ 822.056495] ehci_hcd :00:13.2: PME# disabled [ 822.056522] ehci_hcd :00:13.2: PCI INT B - GSI 17 (level, low) - IRQ 17 [ 822.084591] ohci_hcd :00:12.0: PCI INT A - GSI 18 (level, low) - IRQ 18 [ 822.216637] ohci_hcd :00:13.0: PCI INT A - GSI 18 (level, low) - IRQ 18 [ 824.825365] ohci_hcd :00:12.0: PCI INT A disabled [ 824.825464] ohci_hcd :00:13.0: PCI INT A disabled [ 824.840255] ehci_hcd :00:13.2: PCI INT B disabled [
Bug#684049: linux-image-3.2.0-3-amd64: syslog flooded with [e|o]hci_hcd related messages
On Mon, 2012-08-06 at 16:55 +0300, Juha Heinanen wrote:
Package: src:linux
Version: 3.2.21-3
Severity: normal
Dear Maintainer,
Recently I noticed that syslog is flooded with these kind of messages:
[...]
This is probably the result of run-time power management. It seems very
eager to turn off the USB ports, but I don't think that's actually a
problem.
I do recognise that syslog should not be filled up with this noise,
though. Can you test whether the attached patch fixes this for you?
Instructions for building a patched kernel package are at
http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s4.2.1.
Ben.
--
Ben Hutchings
Theory and practice are closer in theory than in practice.
- John Levine, moderator of comp.compilers
From: Vincent Palatin vpala...@chromium.org
Date: Mon, 5 Dec 2011 11:51:18 -0800
Subject: PCI/PM/Runtime: make PCI traces quieter
commit 85b8582d7ca516030efb84d94fa29a73c1d9a125 upstream.
When the runtime PM is activated on PCI, if a device switches state
frequently (e.g. an EHCI controller with autosuspending USB devices
connected) the PCI configuration traces might be very verbose in the
kernel log. Let's guard those traces with DEBUG condition.
Acked-by: Rafael J. Wysocki r...@sisk.pl
Signed-off-by: Vincent Palatin vpala...@chromium.org
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/acpi/pci_irq.c | 10 +-
drivers/pci/pci.c |5 ++---
drivers/pci/setup-res.c |6 +++---
3 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/acpi/pci_irq.c b/drivers/acpi/pci_irq.c
index 7f9eba9..0eefa12 100644
--- a/drivers/acpi/pci_irq.c
+++ b/drivers/acpi/pci_irq.c
@@ -487,10 +487,10 @@ int acpi_pci_irq_enable(struct pci_dev *dev)
else
link_desc[0] = '\0';
- dev_info(dev-dev, PCI INT %c%s - GSI %u (%s, %s) - IRQ %d\n,
- pin_name(pin), link_desc, gsi,
- (triggering == ACPI_LEVEL_SENSITIVE) ? level : edge,
- (polarity == ACPI_ACTIVE_LOW) ? low : high, dev-irq);
+ dev_dbg(dev-dev, PCI INT %c%s - GSI %u (%s, %s) - IRQ %d\n,
+ pin_name(pin), link_desc, gsi,
+ (triggering == ACPI_LEVEL_SENSITIVE) ? level : edge,
+ (polarity == ACPI_ACTIVE_LOW) ? low : high, dev-irq);
return 0;
}
@@ -524,6 +524,6 @@ void acpi_pci_irq_disable(struct pci_dev *dev)
* (e.g. PCI_UNDEFINED_IRQ).
*/
- dev_info(dev-dev, PCI INT %c disabled\n, pin_name(pin));
+ dev_dbg(dev-dev, PCI INT %c disabled\n, pin_name(pin));
acpi_unregister_gsi(gsi);
}
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 5c5adef..54343aa 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -973,7 +973,7 @@ void pci_restore_state(struct pci_dev *dev)
for (i = 15; i = 0; i--) {
pci_read_config_dword(dev, i * 4, val);
if (val != dev-saved_config_space[i]) {
- dev_printk(KERN_DEBUG, dev-dev, restoring config
+ dev_dbg(dev-dev, restoring config
space at offset %#x (was %#x, writing %#x)\n,
i, val, (int)dev-saved_config_space[i]);
pci_write_config_dword(dev,i * 4,
@@ -1542,8 +1542,7 @@ void pci_pme_active(struct pci_dev *dev, bool enable)
}
out:
- dev_printk(KERN_DEBUG, dev-dev, PME# %s\n,
- enable ? enabled : disabled);
+ dev_dbg(dev-dev, PME# %s\n, enable ? enabled : disabled);
}
/**
diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
index 5717509b..b66bfdb 100644
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -85,9 +85,9 @@ void pci_update_resource(struct pci_dev *dev, int resno)
}
}
res-flags = ~IORESOURCE_UNSET;
- dev_info(dev-dev, BAR %d: set to %pR (PCI address [%#llx-%#llx])\n,
- resno, res, (unsigned long long)region.start,
- (unsigned long long)region.end);
+ dev_dbg(dev-dev, BAR %d: set to %pR (PCI address [%#llx-%#llx])\n,
+ resno, res, (unsigned long long)region.start,
+ (unsigned long long)region.end);
}
int pci_claim_resource(struct pci_dev *dev, int resource)
signature.asc
Description: This is a digitally signed message part
Processed: tagging 684049
Processing commands for cont...@bugs.debian.org: tags 684049 + patch moreinfo Bug #684049 [src:linux] linux-image-3.2.0-3-amd64: syslog flooded with [e|o]hci_hcd related messages Added tag(s) moreinfo and patch. thanks Stopping processing here. Please contact me if you need assistance. -- 684049: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684049 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.134426288719068.transcr...@bugs.debian.org
Bug#678215: [wheezy] USB mouse not recognized after resuming from suspend to RAM
retitle 678215 ASUS M2A-VM: USB mouse not recognized after resume from suspend to RAM forwarded 678215 http://thread.gmane.org/gmane.linux.usb.general/66109 tags 678215 = unreproducible quit Paul Menzel wrote: I am sorry for not reporting back on this issue. No problem. Thanks for the update. [...] I contacted linux-...@vger.kernel.org [1][2] and it looks like that the mouse and the ASUS M2A-VM do not get along. Currently the motherboard is replaced by a different board ASRock A780Full HD and the USB mouse works without any problems with it. Alan suggested that using a different mouse might work. Did you try that? Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120806155736.GA28290@mannheim-rule.local
Processed: Re: [wheezy] USB mouse not recognized after resuming from suspend to RAM
Processing commands for cont...@bugs.debian.org: retitle 678215 ASUS M2A-VM: USB mouse not recognized after resume from suspend to RAM Bug #678215 [src:linux] linux-image-3.2.0-2-: USB mouse not recognized after resuming from suspend to RAM Changed Bug title to 'ASUS M2A-VM: USB mouse not recognized after resume from suspend to RAM' from 'linux-image-3.2.0-2-: USB mouse not recognized after resuming from suspend to RAM' forwarded 678215 http://thread.gmane.org/gmane.linux.usb.general/66109 Bug #678215 [src:linux] ASUS M2A-VM: USB mouse not recognized after resume from suspend to RAM Set Bug forwarded-to-address to 'http://thread.gmane.org/gmane.linux.usb.general/66109'. tags 678215 = unreproducible Bug #678215 [src:linux] ASUS M2A-VM: USB mouse not recognized after resume from suspend to RAM Added tag(s) unreproducible; removed tag(s) moreinfo. quit Stopping processing here. Please contact me if you need assistance. -- 678215: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678215 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.134426867918930.transcr...@bugs.debian.org
Re: autobuilding src:nvidia-* [non-free]
On Mon, Aug 06, 2012 at 06:49:11PM +0200, Andreas Beckmann wrote: On 2012-08-06 17:07, Philipp Kern wrote: I gathered. That doesn't answer my point, though. It is the *last* package in the archive doing so, instead of using dkms. There is nvidia-kernel-dkms, too. But for historic reasons we always provided prebuilt modules for stable and I don't want to change this. Copying debian-release@ and debian-kernel@ on what they think. To provide context (it seems that pkg-nvidia-devel@ dropped my mails or put it into a queue, hence they're not in a list archive): nvidia-graphics-modules seems to be the last package to provide pre-built kernel modules. Do we still want this for wheezy given the maintenance hassle if there's an ABI bump? Or is an ABI bump (e.g. through a security update) completely unlikely for wheezy, given that we managed to keep squeeze stable? It does mean that it needs to be updated on every kernel ABI bump. Right, but that hopefully does not happen too often for stable (but the next ABI bump is already scheduled, as I heard). (Also in theory the ABI compatibility guarantee of the Debian Linux packages is that they can add new symbols at any time, they just won't drop old ones. But I guess that's not as relevant for the nvidia packages. I recently needed to rebuild it for 3.2.0-3 again because of mismatching symbol versioning without ABI-bump (#683365), that should be doable by a plain binNMU in the future. It could at least be compatible one-way by specifying strict dependencies onto the package it was compiled against. But if kernel upgrades randomly break it, that concerns me even more and somehow points to it being unsuitable as a mechanism for a stable distribution. Yes, we could possibly update the modules through a stable update at point release time (or maybe through stable-updates), but if there's already a solution that solves it: Why shouldn't we use it? Kind regards Philipp Kern signature.asc Description: Digital signature
Re: autobuilding src:nvidia-* [non-free]
On Mon, Aug 06, 2012 at 07:03:16PM +0200, Philipp Kern wrote: On Mon, Aug 06, 2012 at 06:49:11PM +0200, Andreas Beckmann wrote: On 2012-08-06 17:07, Philipp Kern wrote: I gathered. That doesn't answer my point, though. It is the *last* package in the archive doing so, instead of using dkms. There is nvidia-kernel-dkms, too. But for historic reasons we always provided prebuilt modules for stable and I don't want to change this. Copying debian-release@ and debian-kernel@ on what they think. To provide context (it seems that pkg-nvidia-devel@ dropped my mails or put it into a queue, hence they're not in a list archive): nvidia-graphics-modules seems to be the last package to provide pre-built kernel modules. Do we still want this for wheezy given the maintenance hassle if there's an ABI bump? Or is an ABI bump (e.g. through a security update) completely unlikely for wheezy, given that we managed to keep squeeze stable? No promises, but I think it's quite unlikely that we will have to change ABI for the standard (non-rt) configurations after release. It does mean that it needs to be updated on every kernel ABI bump. Right, but that hopefully does not happen too often for stable (but the next ABI bump is already scheduled, as I heard). (Also in theory the ABI compatibility guarantee of the Debian Linux packages is that they can add new symbols at any time, they just won't drop old ones. But I guess that's not as relevant for the nvidia packages. I recently needed to rebuild it for 3.2.0-3 again because of mismatching symbol versioning without ABI-bump (#683365), that should be doable by a plain binNMU in the future. It could at least be compatible one-way by specifying strict dependencies onto the package it was compiled against. But if kernel upgrades randomly break it, that concerns me even more and somehow points to it being unsuitable as a mechanism for a stable distribution. Yes, we could possibly update the modules through a stable update at point release time (or maybe through stable-updates), but if there's already a solution that solves it: Why shouldn't we use it? There is actually no attempt to check or maintain ABI stability for packages with the rt featureset (or openvz or vserver, in squeeze), as their stable updates have been comparatively less stable. This fact hasn't been advertised nearly as widely as it should be. I think we should do better and actually change the ABI numbers per-featureset, as the current arrangement obviously works really badly with OOT modules. But it will require more trips through NEW and more linux-latest updates. (I'm a little sceptical that many OOT modules work properly with rt, but let's assume some of them do.) Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120806173230.gk1...@decadent.org.uk
Re: autobuilding src:nvidia-* [non-free]
Philipp Kern pk...@debian.org writes: Copying debian-release@ and debian-kernel@ on what they think. To provide context (it seems that pkg-nvidia-devel@ dropped my mails or put it into a queue, hence they're not in a list archive): Sorry, they're all approved now. We get unbelievable amounts of spam, so the list moderates messages from people who aren't subscribed with the normal whitelisting for Debian administrative mail, and sometimes I don't get to that right away (like this time). The folks participating in this thread are also now whitelisted. nvidia-graphics-modules seems to be the last package to provide pre-built kernel modules. Do we still want this for wheezy given the maintenance hassle if there's an ABI bump? Or is an ABI bump (e.g. through a security update) completely unlikely for wheezy, given that we managed to keep squeeze stable? I've personally dropped the non-dkms methods from the other package that I have with kernel modules, but I'll note in defense of providing prebuilt modules that it's somewhat simpler for users and the non-free video drivers are often used by the least sophisticated Debian users. What Andreas has been doing, which I think is fairly reasonable, is keeping them out of testing until shortly before the freeze and then updating them for the freeze, which means only doing new uploads for ABI changes that happen during the freeze or in stable (relatively rare). -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874noflv4u@windlord.stanford.edu
Processed: closing 645069
Processing commands for cont...@bugs.debian.org: fixed 645069 3.4-1 Bug #645069 [linux-2.6] linux 3.0.0: kernel bug in kswapd0 There is no source info for the package 'linux-2.6' at version '3.4-1' with architecture '' Unable to make a source version for version '3.4-1' Marked as fixed in versions 3.4-1. close 645069 Bug #645069 [linux-2.6] linux 3.0.0: kernel bug in kswapd0 Marked Bug as done thanks Stopping processing here. Please contact me if you need assistance. -- 645069: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=645069 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.134428002218263.transcr...@bugs.debian.org
PCIe debugging error messages - kern.log
I've been working with the Intel E1000 development team in trying to find the cause of a hardware hang in my kern.log. They suggested contacting the Debian User list for extra help, whom suggested that I ask the Kernel list to see if I could get any insight. This is the error in my kern.log: Jul 24 02:49:45 gaia kernel: [806292.204500] e1000e :02:00.0: eth1: Detected Hardware Unit Hang: Jul 24 02:49:45 gaia kernel: [806292.204503] TDH 8c Jul 24 02:49:45 gaia kernel: [806292.204504] TDT 8f Jul 24 02:49:45 gaia kernel: [806292.204505] next_to_use 8f Jul 24 02:49:45 gaia kernel: [806292.204506] next_to_clean8c Jul 24 02:49:45 gaia kernel: [806292.204508] buffer_info[next_to_clean]: Jul 24 02:49:45 gaia kernel: [806292.204509] time_stamp 10c029ca3 Jul 24 02:49:45 gaia kernel: [806292.204510] next_to_watch8c Jul 24 02:49:45 gaia kernel: [806292.204511] jiffies 10c029dc2 Jul 24 02:49:45 gaia kernel: [806292.204512] next_to_watch.status 0 Jul 24 02:49:45 gaia kernel: [806292.204513] MAC Status 80383 Jul 24 02:49:45 gaia kernel: [806292.204514] PHY Status 792d Jul 24 02:49:45 gaia kernel: [806292.204516] PHY 1000BASE-T Status 3800 Jul 24 02:49:45 gaia kernel: [806292.204517] PHY Extended Status3000 Jul 24 02:49:45 gaia kernel: [806292.204518] PCI Status 10 One of the steps to find the cause of this is to enable extended error reporting by using ethtool: sudo ethtool -s eth1 msglvl 0x2c01 This will tell the driver to dump extended debugging (a PCIe Ring Dump) info to the kernel log with another error is detected. However, after enabling this extended logging, the next time an error occurs, I still don't get the debug dump in the kern.log. I get basically the same info as above. Is there anything Debian specific that would cause this to not get logged? I've tried searching all of the log files in /var/log for the dump information in case it gets logged somewhere else, but could not find anything. I have checked to make sure that the debug message level is set correctly: Settings for eth1: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Speed: 1000Mb/s Duplex: Full Port: Twisted Pair PHYAD: 1 Transceiver: internal Auto-negotiation: on MDI-X: off Supports Wake-on: pumbag Wake-on: g Current message level: 0x2c01 (11265) Link detected: yes Any help would be appreciated. Thanks -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CABrZ_K2orMgc-3oDgM8mm1Ew=8ytuvrdwo95jxlb2qpb5q-...@mail.gmail.com
Re: autobuilding src:nvidia-* [non-free]
Hey Russ, On Mon, Aug 06, 2012 at 11:42:41AM -0700, Russ Allbery wrote: Sorry, they're all approved now. thank you. nvidia-graphics-modules seems to be the last package to provide pre-built kernel modules. Do we still want this for wheezy given the maintenance hassle if there's an ABI bump? Or is an ABI bump (e.g. through a security update) completely unlikely for wheezy, given that we managed to keep squeeze stable? I've personally dropped the non-dkms methods from the other package that I have with kernel modules, but I'll note in defense of providing prebuilt modules that it's somewhat simpler for users and the non-free video drivers are often used by the least sophisticated Debian users. I'm a bit confused why that is. If I'm installing a nvidia-graphics-driver package that does all the magic using dkms at install time, how is that more sophisticated than providing pre-built module packages, especially in the light that it's the only one left doing it that way? (Why isn't it the same for fglrx? Where's that 3.2.0-3 module for virtualbox?) Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#598144: rt2500pci: very low transfers and link quality
reassign 598144 src:linux 3.2.21-3 found 598144 linux-2.6/2.6.32-20 found 598144 linux-2.6/2.6.32-45 quit Nathan Schulte wrote: $ uname -a Linux desmas-s 3.2.0-0.bpo.2-amd64 #1 SMP Fri Jun 29 20:42:29 UTC 2012 x86_64 GNU/Linux [...] It looks like the problem is still prevalent. Thanks for the quick reply. Marking so. I don't see any obvious relevant fixes upstream, but it would probably be useful to try 3.5 from experimental, too, anyway --- sorry for the fuss. Afterwards, please report this upstream (regardless of the result) to linux-wirel...@vger.kernel.org, cc-ing us...@rt2x00.serialmonkey.com, Gertjan van Wingerde gwinge...@gmail.com, and either me or this bug log so we can track it. Then hopefully someone upstream can provide commands or a patch to try to track down the cause and work toward a fix. Thanks again for your work, Jonathan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120806215236.GA268@mannheim-rule.local
Processed: Re: rt2500pci: very low transfers and link quality
Processing commands for cont...@bugs.debian.org: reassign 598144 src:linux 3.2.21-3 Bug #598144 [linux-2.6] rt2500pci: very low transfers and link quality Bug reassigned from package 'linux-2.6' to 'src:linux'. No longer marked as found in versions 2.6.32-45 and 2.6.32-20. Ignoring request to alter fixed versions of bug #598144 to the same values previously set Bug #598144 [src:linux] rt2500pci: very low transfers and link quality Marked as found in versions linux/3.2.21-3. found 598144 linux-2.6/2.6.32-20 Bug #598144 [src:linux] rt2500pci: very low transfers and link quality Marked as found in versions linux-2.6/2.6.32-20. found 598144 linux-2.6/2.6.32-45 Bug #598144 [src:linux] rt2500pci: very low transfers and link quality Marked as found in versions linux-2.6/2.6.32-45. quit Stopping processing here. Please contact me if you need assistance. -- 598144: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598144 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.13442899628295.transcr...@bugs.debian.org
Re: autobuilding src:nvidia-* [non-free]
I'm afraid, this is getting a bit off-topic ... On 2012-08-06 23:28, Philipp Kern wrote: I'm a bit confused why that is. If I'm installing a nvidia-graphics-driver package that does all the magic using dkms at install time, how is that more sophisticated than providing pre-built module packages, There are a few people that don't like the dkms way (to many dependencies: compiler, kernel headers; leaves cruft around (I tried to fix a bit of this in my dkms NMU); ) and prefer to take the responsibility to provide their own kernel module packages for local deployment. So with the current state a foo-dkms package is an alternative to foo-source, but not a replacement for it. But I think there were enough threads about this topic already, no need to start a new one ... especially in the light that it's the only one left doing it that way? (Why isn't it the same for fglrx? unfortunately the license does not permit distribution of precompiled kernel modules Where's that 3.2.0-3 module for virtualbox?) in my private repository :-) I have a generic branch of nvidia-graphics-modules.git with all the nvidia specific bits made configurable that can be used to quickly build module packages with module-assistant for any foo-source package (tested with fglrx-source and virtualbox-source on i386 and amd64), if anyone is interested, I can push this somewhere. Nice way for getting prebuilt modules (+ corresponding meta-packages) into a local repository. Andreas PS: I also maintain r8168-dkms which is dkms only (and only in sid) - primarily to get some more experience with dkms ... -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/502045d7.6000...@abeckmann.de
Re: autobuilding src:nvidia-* [non-free]
On 2012-08-06 19:32, Ben Hutchings wrote: There is actually no attempt to check or maintain ABI stability for packages with the rt featureset (or openvz or vserver, in squeeze), as their stable updates have been comparatively less stable. This fact hasn't been advertised nearly as widely as it should be. In that case we should probably drop the RT prebuilt modules (like we did for openvz and xen in squeeze) - or do semi-automatic binNMUs whenever a new linux_3.2* gets out. I think we should do better and actually change the ABI numbers per-featureset, as the current arrangement obviously works really badly with OOT modules. But it will require more trips through NEW and more linux-latest updates. (I'm a little sceptical that many OOT modules work properly with rt, but let's assume some of them do.) I think nvidia works with RT, although I haven't tried this myself. I picked up a patch from arch linux earlier this year that worked around some GPL-only symbols getting pulled in by the RT patch, but that is no longer neccessary. Andreas -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/502048d9.6060...@abeckmann.de
Re: autobuilding src:nvidia-* [non-free]
Philipp Kern pk...@debian.org writes: I'm a bit confused why that is. If I'm installing a nvidia-graphics-driver package that does all the magic using dkms at install time, how is that more sophisticated than providing pre-built module packages, especially in the light that it's the only one left doing it that way? The main problem with the DKMS approach is that you have to have a version of the kernel headers installed that matches the version of the kernel that you have. If you don't, you just don't get the module, and then stuff doesn't work. People seem to really struggle with this when they don't understand what's going on under the hood, and our dependency system is not powerful enough to clearly express this dependency. With the prebuilt modules, you can just install the meta tracking package for the nvidia modules and from the perspective of the user it just works, since the packaging takes care of keeping the dependencies in sync with the kernel module versions. It's more fragile from a Debian perspective, but within a stable release it means the user doesn't have to notice that they need the header package installed. (Admittedly, with the DKMS approach, you can just install the header tracking package and once you have that installed, similarly everything will just work. The confusion seems to come from people not realizing that they need to also install the header tracking package; they find the NVIDIA DKMS package and then don't realize that's not enough.) It's a relatively minor benefit, I'll grant. If I were doing all the NVIDIA stuff by myself, I wouldn't bother, but I can see some benefit as long as Andreas wants to keep doing the work. I think what we're currently doing doesn't put a lot of work on anyone else, other than some work for ftp-master approving the new packages after an ABI update and the release team approving freeze exceptions for the new packages after an ABI update. I'm not sure if that work is a strong argument against doing this. I noticed that dkms now Recommends the tracking kernel header package, so maybe that makes this somewhat more obsolete. That means that the average user should, through the dependency tree, get the header package installed when they install nvidia-modules-dkms, which in turn they should get via Recommends from nvidia-graphics-modules. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ehnj1vdz@windlord.stanford.edu
Re: autobuilding src:nvidia-* [non-free]
Andreas Beckmann deb...@abeckmann.de writes: There are a few people that don't like the dkms way (to many dependencies: compiler, kernel headers; leaves cruft around (I tried to fix a bit of this in my dkms NMU); ) and prefer to take the responsibility to provide their own kernel module packages for local deployment. So with the current state a foo-dkms package is an alternative to foo-source, but not a replacement for it. The other benefit for having the -source package is that it works somewhat more smoothly with self-built kernels that don't use the Debian layout. The last time I looked at this, the things that you have to do when you're building your own Linux kernel to get the DKMS support to work are more complex than what you have to do to get the module-assistant or kernel-package stuff to work. This is all fairly dated information, though; I stopped building my own kernel a long time ago, so most of my understanding is hearsay. I keep maintaining -source packages for other packages with kernel modules mostly because I keep getting a small number of bug reports for them, so people are clearly still using them. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87628v1v5x@windlord.stanford.edu
Bug#683807: taintness
an update: i've found this information: Documentation/sysctl/kernel.txt == tainted: Non-zero if the kernel has been tainted. Numeric values, which can be ORed together: 1 - A module with a non-GPL license has been loaded, this includes modules with no license. Set by modutils = 2.4.9 and module-init-tools. 4096 - An out-of-tree module has been loaded. == maybe the non-GPL module was the nvidia module. I dont know what 'out-of-tree module' means. anyway, uptime is 14hrs and still no problems :) From: asronche...@libero.it asronche...@libero.it Date: Mon, 6 Aug 2012 15:54:40 +0200 (CEST) and kernel was tainted: kernel.tainted = 4097 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/9484189.4349531344310766893.JavaMail.defaultUser@defaultHost
Bug#683807: taintness
On Tue, 2012-08-07 at 05:39 +0200, asronche...@libero.it wrote: an update: i've found this information: Documentation/sysctl/kernel.txt == tainted: Non-zero if the kernel has been tainted. Numeric values, which can be ORed together: 1 - A module with a non-GPL license has been loaded, this includes modules with no license. Set by modutils = 2.4.9 and module-init-tools. 4096 - An out-of-tree module has been loaded. == maybe the non-GPL module was the nvidia module. Yes, that's right. I dont know what 'out-of-tree module' means. Any module not built as part of the kernel package. Loading either bbswitch or nvidia would set this flag. anyway, uptime is 14hrs and still no problems :) Good, but I think it will take longer that to be confident. Ben. -- Ben Hutchings Theory and practice are closer in theory than in practice. - John Levine, moderator of comp.compilers signature.asc Description: This is a digitally signed message part
Bug#681232: [3.2.20-3.2.21 regression] Atheros WiFi Adapter couldn't find networks gain calibration timeout
Well, it's not going to happen when I'm using 3.2.0-2, and it always happens on 3.2.0-3 rendering it basically useless for a working system - not only is my network controller unusable, it also constantly spams the console with those gain calibration timeout messages. Since 3.2.0-3 reports itself as Version: 3.2.21-3, and vanilla 3.2.21 worked fine, it must be some difference between the debian build and the upstream 3.2.21 that is causing this issue. Right? On Sun, Aug 5, 2012 at 6:41 PM, Jonathan Nieder jrnie...@gmail.com wrote: Jesse Rhodes wrote: Steps a. and c.: Neither 3.3.0-rc6 (from snapshots), nor 3.2.21, nor 3.2.20 reproduced the bug. I'm typing this email from 3.2.21 right now with a fully functional wireless connection. Thanks, Jesse. I'd suggest using whatever kernel is most convenient and letting us know whether it's happened again in a few days. Do you mind if I forward your reply to the bug log? Ciao, Jonathan
