Bug#700333: linux-image-3.7-trunk-amd64: Suspend to disk broken
Package: src:linux Version: 3.7.3-1~experimental.1 Followup-For: Bug #700333 Dear Maintainer, * What led up to the situation? Trying to do pm-hibernate with/without uswsusp installed. A black unresponsive screen, with no way to interrupt except forced turn off. This happens with the latest (3.7.8-1) too. Suspend to ram works fine as Vitaliy pointed out. Also, wasn't able to make anything out of logs. * What exactly did you do (or not do) that was effective (or ineffective)? Moved to the stable kernel - 3.2.0-4-amd64. (Practically Ineffective). Switched to older 3.7 (3.7.3-1), no positive results. * What was the outcome of this action? Fixes the issues with suspension, but brings up even grave issue i.e. system freezes. It is a know issue with Ivy Bridge process as far as I know. * What outcome did you expect instead? Both the system to run stably and successful suspends. s2disk worked fine for any version before 3.7 and after 3.2. -- Package-specific info: ** Version: Linux version 3.7-trunk-amd64 (debian-kernel@lists.debian.org) (gcc version 4.7.2 (Debian 4.7.2-5) ) #1 SMP Debian 3.7.3-1~experimental.1 ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.7-trunk-amd64 root=UUID=2f4f052d-25d5-47d5-92bd-790dba9f7fc3 ro resume=/dev/sda3 quiet resume=/dev/sda3 ** Tainted: C (1024) * Module from drivers/staging has been loaded. ** Kernel log: [5.271841] snd_hda_intel :00:1b.0: irq 47 for MSI/MSI-X [5.272186] [drm] initializing kernel modesetting (VERDE 0x1002:0x682F 0x1028:0x0572). [5.272288] [drm] register mmio base: 0xC000 [5.272291] [drm] register mmio size: 262144 [5.272295] vga_switcheroo: enabled [5.272525] ATPX version 1 [5.313404] hda_codec: CX20590: BIOS auto-probing. [5.314309] input: HDA Digital PCBeep as /devices/pci:00/:00:1b.0/input/input12 [5.321313] input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci:00/:00:1b.0/sound/card0/input13 [5.321467] input: HDA Intel PCH Mic as /devices/pci:00/:00:1b.0/sound/card0/input14 [5.321604] input: HDA Intel PCH Headphone as /devices/pci:00/:00:1b.0/sound/card0/input15 [6.064465] ATOM BIOS: Dell/Compal [6.064514] radeon :01:00.0: VRAM: 2048M 0x - 0x7FFF (2048M used) [6.064519] radeon :01:00.0: GTT: 512M 0x8000 - 0x9FFF [6.064531] mtrr: no more MTRRs available [6.064533] [drm] Detected VRAM RAM=2048M, BAR=256M [6.064536] [drm] RAM width 128bits DDR [6.064724] [TTM] Zone kernel: Available graphics memory: 4048974 kiB [6.064729] [TTM] Zone dma32: Available graphics memory: 2097152 kiB [6.064731] [TTM] Initializing pool allocator [6.064739] [TTM] Initializing DMA pool allocator [6.064778] [drm] radeon: 2048M of VRAM memory ready [6.064781] [drm] radeon: 512M of GTT memory ready. [6.064808] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [6.064810] [drm] Driver supports precise vblank timestamp query. [6.064872] radeon :01:00.0: irq 48 for MSI/MSI-X [6.064888] radeon :01:00.0: radeon: using MSI. [6.064932] [drm] radeon: irq initialized. [6.064939] [drm] GART: num cpu pages 131072, num gpu pages 131072 [6.065761] [drm] Loading VERDE Microcode [6.068130] platform radeon_cp.0: firmware: agent loaded radeon/VERDE_pfp.bin into memory [6.068372] platform radeon_cp.0: firmware: agent loaded radeon/VERDE_me.bin into memory [6.068621] platform radeon_cp.0: firmware: agent loaded radeon/VERDE_ce.bin into memory [6.068841] platform radeon_cp.0: firmware: agent loaded radeon/VERDE_rlc.bin into memory [6.069182] platform radeon_cp.0: firmware: agent loaded radeon/VERDE_mc.bin into memory [6.460854] [drm] PCIE GART of 512M enabled (table at 0x0004). [6.460977] radeon :01:00.0: WB enabled [6.460983] radeon :01:00.0: fence driver on ring 0 use gpu addr 0x8c00 and cpu addr 0x8802515e7c00 [6.460988] radeon :01:00.0: fence driver on ring 1 use gpu addr 0x8c04 and cpu addr 0x8802515e7c04 [6.460991] radeon :01:00.0: fence driver on ring 2 use gpu addr 0x8c08 and cpu addr 0x8802515e7c08 [6.480980] [drm] ring test on 0 succeeded in 1 usecs [6.480988] [drm] ring test on 1 succeeded in 1 usecs [6.480994] [drm] ring test on 2 succeeded in 1 usecs [6.497358] [drm] ib test on ring 0 succeeded in 0 usecs [6.497389] [drm] ib test on ring 1 succeeded in 0 usecs [6.497437] [drm] ib test on ring 2 succeeded in 0 usecs [6.497599] [drm] Radeon Display Connectors [6.506292] [drm] Internal thermal controller with fan control [6.506415] [drm] radeon: power management initialized [6.506587] No connectors reported connected with modes [6.506592] [drm] Cannot find any crtc or sizes - going 1024x768 [6.508150] [drm] fb
Bug#701050: linux-image-3.2.0-4-amd64: Wrong battery capacity values on HP Folio 13-2000
while my BIOS/UEFI reports a battery charge capacity of 92% for my
notebook-
battery, upower still reports a charge capacity of 100% (AFAIK
upower gets this
information from the kernel - I believe this to be a kernel ACPI
bug).
The kernel driver doesn't do anything very interesting so it's
actually
very likely a BIOS bug.
I checked the situation in Windows 7 over the last days and I don't see
the problem there. I can use the 'HP Support Assistant' in Windows to
check the battery capacity and status – it seems to be the same tool as
in the 'HP UEFI Support Environment'. The value 'Current' (in mAh)
accords to the values (in percentage of 'Full Charge Capacity') reported
by Windows.
This is why I don't think that this is a BIOS bug.
Can you send the contents of /sys/class/power_supply/BAT1/uevent so
we
at least know what the kernel is reporting?
stefan@rosa:~$ cat /sys/class/power_supply/BAT1/uevent
POWER_SUPPLY_NAME=BAT1
POWER_SUPPLY_STATUS=Discharging
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_TECHNOLOGY=Unknown
POWER_SUPPLY_CYCLE_COUNT=0
POWER_SUPPLY_VOLTAGE_MIN_DESIGN=1110
POWER_SUPPLY_VOLTAGE_NOW=10872000
POWER_SUPPLY_POWER_NOW=14851000
POWER_SUPPLY_ENERGY_FULL_DESIGN=5994
POWER_SUPPLY_ENERGY_FULL=5994
POWER_SUPPLY_ENERGY_NOW=17982000
POWER_SUPPLY_MODEL_NAME=Venturi
POWER_SUPPLY_MANUFACTURER=13-17
POWER_SUPPLY_SERIAL_NUMBER=01317 01/24/2012
Regarding my original issue ('GNOME fails to execute action on critical
battery condition') I just want to add that there seem to be three
issues involved: one is really a BIOS bug (see the last comments of
#695634), one at least seems to be a UPower bug (see #6841869) and then
there's this one.
Stefan.
--
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/f3f8b2040621f07fd5977b4d05a55...@stefan-nagy.at
Re: an issue with crash(8) perhaps?
On 2013-01-31 00:17, Ben Hutchings wrote: On Wed, 2013-01-30 at 14:50 -0500, David Magda wrote: The upstream bug report is at: https://www.redhat.com/archives/crash-utility/2011-June/thread.html#0 http://people.redhat.com/anderson/crash_patches/5.1.5-to-5.1.6.patch If it is the crash, can we either get: (a) the patch added to squeeze package, and/or (b) wheezy crash backported. This should be fixed in squeeze so that partial upgrades work correctly. Specific fixes of this nature are generally accepted by the stable release managers. Any news on whether (a) or (b) will be done? Or is there a (c) that hasn't been considered perhaps? -- 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/51262db6.9020...@oicr.on.ca
Re: kdump-tools: default debug kernel search path is incorrect
On 2013-02-12 09:07, David Magda wrote: In /usr/share/doc/kdump-tools/README.Debian the following text appears: 4. Debug Kernel You *should* have a debug kernel in order for makedumpfile to process the vmcore file. Without a debug kernel, the transfer process is reduced to using makedumpfile -d 1. Options: A) If /usr/lib/debug/vmlinux-$(uname -r) exists, kdump-tools will use that kernel. B) Explicitly set DEBUG_KERNEL in /etc/default/kdump-tools to point to your debug kernel. C) None of the above. makedumpfile will still work, but your dumpfile will be larger and take longer to save to disk. However all (?) the default -dbg Debian kernel packages put the kernels in /usr/lib/debug/boot/: [...] IMHO it would make sense to change (A) so that things worked automagically. If someone had a truly custom kernel, then tweaking DEBUG_KERNEL per (B) would make sense, but the 'standard' Debian tools should work with the standard Debian kernels. The other options would be to remove the boot/ from the debug kernel path. Has anyone had a chance to take a look at this and evaluate if it's a valid concern, or am I just talking crazy? -- 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/51262eda.3070...@oicr.on.ca
Processed: [bts-link] source package linux-2.6
Processing commands for cont...@bugs.debian.org: # # bts-link upstream status pull for source package linux-2.6 # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # user bts-link-upstr...@lists.alioth.debian.org Setting user to bts-link-upstr...@lists.alioth.debian.org (was bts-link-de...@lists.alioth.debian.org). # remote status report for #602966 (http://bugs.debian.org/602966) # Bug title: linux-source-2.6.36: Oops while unmouning an USB key with FAT filesystem # * http://bugzilla.kernel.org/show_bug.cgi?id=22602 # * remote resolution changed: OBSOLETE - CODE-FIX usertags 602966 - resolution-OBSOLETE Usertags were: status-RESOLVED resolution-OBSOLETE. Usertags are now: status-RESOLVED. usertags 602966 + resolution-CODE-FIX Usertags were: status-RESOLVED. Usertags are now: resolution-CODE-FIX status-RESOLVED. # remote status report for #609846 (http://bugs.debian.org/609846) # Bug title: Toshiba Satellite battery not recognized by acpi # * http://bugzilla.kernel.org/show_bug.cgi?id=15707 # * remote status changed: RESOLVED - REOPENED # * remote resolution changed: CODE-FIX - (?) # * reopen upstream tags 609846 - fixed-upstream Bug #609846 [linux-2.6] Toshiba Satellite battery not recognized by acpi Removed tag(s) fixed-upstream. usertags 609846 - status-RESOLVED resolution-CODE-FIX Usertags were: resolution-CODE-FIX status-RESOLVED. Usertags are now: . usertags 609846 + status-REOPENED There were no usertags set. Usertags are now: status-REOPENED. thanks Stopping processing here. Please contact me if you need assistance. -- 609846: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=609846 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.136146482215952.transcr...@bugs.debian.org
Processed: [bts-link] source package src:linux
Processing commands for cont...@bugs.debian.org: # # bts-link upstream status pull for source package src:linux # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # user bts-link-upstr...@lists.alioth.debian.org Setting user to bts-link-upstr...@lists.alioth.debian.org (was bts-link-de...@lists.alioth.debian.org). # remote status report for #697029 (http://bugs.debian.org/697029) # Bug title: linux-image-3.2.0-4-amd64: i915_hangcheck_ring_idle error makes the computer lag using intel core i7-620 integrated gpu # * https://bugs.freedesktop.org/show_bug.cgi?id=59792 # * remote status changed: NEEDINFO - RESOLVED # * remote resolution changed: (?) - WONTFIX # * upstream said bug is wontfix tags 697029 + upstream wontfix Bug #697029 [src:linux] linux-image-3.2.0-4-amd64: i915_hangcheck_ring_idle error makes the computer lag using intel core i7-620 integrated gpu Added tag(s) upstream and wontfix. usertags 697029 - status-NEEDINFO Usertags were: status-NEEDINFO. Usertags are now: . usertags 697029 + status-RESOLVED resolution-WONTFIX There were no usertags set. Usertags are now: resolution-WONTFIX status-RESOLVED. thanks Stopping processing here. Please contact me if you need assistance. -- 697029: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=697029 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.136146482215954.transcr...@bugs.debian.org
[bts-link] source package linux-2.6
# # bts-link upstream status pull for source package linux-2.6 # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # user bts-link-upstr...@lists.alioth.debian.org # remote status report for #602966 (http://bugs.debian.org/602966) # Bug title: linux-source-2.6.36: Oops while unmouning an USB key with FAT filesystem # * http://bugzilla.kernel.org/show_bug.cgi?id=22602 # * remote resolution changed: OBSOLETE - CODE-FIX usertags 602966 - resolution-OBSOLETE usertags 602966 + resolution-CODE-FIX # remote status report for #609846 (http://bugs.debian.org/609846) # Bug title: Toshiba Satellite battery not recognized by acpi # * http://bugzilla.kernel.org/show_bug.cgi?id=15707 # * remote status changed: RESOLVED - REOPENED # * remote resolution changed: CODE-FIX - (?) # * reopen upstream tags 609846 - fixed-upstream usertags 609846 - status-RESOLVED resolution-CODE-FIX usertags 609846 + status-REOPENED 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/20130221164014.8877.8031.btsl...@sonntag.debian.org
[bts-link] source package src:linux
# # bts-link upstream status pull for source package src:linux # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # user bts-link-upstr...@lists.alioth.debian.org # remote status report for #697029 (http://bugs.debian.org/697029) # Bug title: linux-image-3.2.0-4-amd64: i915_hangcheck_ring_idle error makes the computer lag using intel core i7-620 integrated gpu # * https://bugs.freedesktop.org/show_bug.cgi?id=59792 # * remote status changed: NEEDINFO - RESOLVED # * remote resolution changed: (?) - WONTFIX # * upstream said bug is wontfix tags 697029 + upstream wontfix usertags 697029 - status-NEEDINFO usertags 697029 + status-RESOLVED resolution-WONTFIX 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/20130221164014.8877.63259.btsl...@sonntag.debian.org
Re: Bug#699367: an issue with crash(8) perhaps?
On 02/21/13 09:22, David Magda wrote: If it is the crash, can we either get: (a) the patch added to squeeze package, and/or (b) wheezy crash backported. Any news on whether (a) or (b) will be done? Or is there a (c) that hasn't been considered perhaps? I haven't tried to push for a squeeze backport of crash debugger yet and honestly I really don't want to push for it unless there is a good reason. Unless I'm missing something, which is entirely possible, I can't see how this could have an effect on more than one or two users. How many people are really running a 3.x kernel on top of a Squeeze userspace AND who also are worried about running the debugger on that specific live system AND who can't easily workaround it? One simple workaround would be to move to the dump to a system running a new version of crash that supports the 3.0 kernel. In wheezy I moved to the minimal rules file that required a newer version of debhelper so a direct rebuild of the package doesn't work. However, crash does not require any new dependencies, nor does it need to be installed to run so it is extremely trivial to build and run directly from the upstream source. Since ware are only talking about users who have explicitly moved to a kernel that is not part of the original distribution and who also want to run the crash debugger against it I would say this is a technically aware user who shouldn't be too put off having to do: # Grab the squeeze build dependencies for crash apt-get build-dep crash wget http://people.redhat.com/anderson/crash-6.1.4.tar.gz -O - | tar xz cd crash-6.1.4 make ./crash Although, maybe I'm missing something and there is enough justification to do a quick backport. Thoughts? Troy signature.asc Description: Digital signature
Re: Bug#699367: an issue with crash(8) perhaps?
On Thu, Feb 21, 2013 at 11:39:04AM -0700, Troy Heber wrote: On 02/21/13 09:22, David Magda wrote: If it is the crash, can we either get: (a) the patch added to squeeze package, and/or (b) wheezy crash backported. Any news on whether (a) or (b) will be done? Or is there a (c) that hasn't been considered perhaps? I haven't tried to push for a squeeze backport of crash debugger yet and honestly I really don't want to push for it unless there is a good reason. Unless I'm missing something, which is entirely possible, I can't see how this could have an effect on more than one or two users. How many people are really running a 3.x kernel on top of a Squeeze userspace AND who also are worried about running the debugger on that specific live system AND who can't easily workaround it? [...] Since ware are only talking about users who have explicitly moved to a kernel that is not part of the original distribution and who also want to run the crash debugger against it I would say this is a technically aware user who shouldn't be too put off having to do: [...] The squeeze kernel is unfortunately missing support for a lot of current hardware (notably graphics but also some networking chips) so many people are running later kernel versions. I would love to fix some of these but I have my hands full and I can rarely test backported drivers myself. So I would expect quite a lot of people to be running Linux 3.2 from wheezy or squeeze-backports, or a custom 3.x kernel (which doesn't require a huge amount of technical sophistication). I don't know how many people use 'crash'; you're in a better position to answer that. I think that rather more than one or two users will be affected by this, and if there is a simple fix then it is fair to expect that you will save them the trouble. 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/20130221191008.gh9...@decadent.org.uk
Re: Bug#699367: an issue with crash(8) perhaps?
On 2013-02-21 14:10, Ben Hutchings wrote: The squeeze kernel is unfortunately missing support for a lot of current hardware (notably graphics but also some networking chips) so many people are running later kernel versions. I would love to fix some of these but I have my hands full and I can rarely test backported drivers myself. So I would expect quite a lot of people to be running Linux 3.2 from wheezy or squeeze-backports, or a custom 3.x kernel (which doesn't require a huge amount of technical sophistication). I don't know how many people use 'crash'; you're in a better position to answer that. I think that rather more than one or two users will be affected by this, and if there is a simple fix then it is fair to expect that you will save them the trouble. There's also the fact that until wheezy, no standard Debian kernel had automatic support for crash dumps either. Now that it's there, both in wheezy and squeeze-backports, there's a larger potential for its use. Previously one had to compile a custom kernel, now a simply 'apt-get' is needed. Even in wheezy, dumps don't Just Work(tm) out of the box: see 700418. -- 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/512673d4.1000...@oicr.on.ca
Re: Bug#699367: an issue with crash(8) perhaps?
On Thu, Feb 21, 2013 at 02:21:56PM -0500, David Magda wrote: On 2013-02-21 14:10, Ben Hutchings wrote: The squeeze kernel is unfortunately missing support for a lot of current hardware (notably graphics but also some networking chips) so many people are running later kernel versions. I would love to fix some of these but I have my hands full and I can rarely test backported drivers myself. So I would expect quite a lot of people to be running Linux 3.2 from wheezy or squeeze-backports, or a custom 3.x kernel (which doesn't require a huge amount of technical sophistication). I don't know how many people use 'crash'; you're in a better position to answer that. I think that rather more than one or two users will be affected by this, and if there is a simple fix then it is fair to expect that you will save them the trouble. There's also the fact that until wheezy, no standard Debian kernel had automatic support for crash dumps either. Now that it's there, both in wheezy and squeeze-backports, there's a larger potential for its use. So 'crash' is almost useless in squeeze now: it requires a custom kernel older than 3.0. Previously one had to compile a custom kernel, now a simply 'apt-get' is needed. Even in wheezy, dumps don't Just Work(tm) out of the box: see 700418. I know. Seems like several tools have different ideas where debug information for vmlinux should be, and we should keep them happy by adding symlinks. You can make this happen sooner if you send a patch to that bug. 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/20130221200015.gi9...@decadent.org.uk
Bug#701148: linux-image-3.7-trunk-amd64: Regression - brightness controls do not work.
Package: src:linux Version: 3.7.8-1~experimental.1 Severity: important If I boot the linux-image-3.6-trunk-amd64, the brightness controls work just fine. Whenever I boot the linux-image-3.7-trunk-amd64 my Fn+F4 and Fn+F5 brightness controls on my laptop do not work. According to xev, the events are getting registered but the brightness of the LCD screen doesn't change. -- Package-specific info: ** Version: Linux version 3.7-trunk-amd64 (debian-kernel@lists.debian.org) (gcc version 4.7.2 (Debian 4.7.2-5) ) #1 SMP Debian 3.7.8-1~experimental.1 ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.7-trunk-amd64 root=UUID=a23a4ab9-bd58-4fd7-8eeb-65b41b772aa7 ro quiet ** Tainted: C (1024) * Module from drivers/staging has been loaded. ** Kernel log: [7.349603] Copyright(c) 2003-2012 Intel Corporation [7.349821] iwlwifi :08:00.0: pci_resource_len = 0x2000 [7.349825] iwlwifi :08:00.0: pci_resource_base = c9c74000 [7.349827] iwlwifi :08:00.0: HW Revision ID = 0xC4 [7.349995] iwlwifi :08:00.0: irq 45 for MSI/MSI-X [7.351267] uvcvideo: Found UVC 1.00 device Laptop_Integrated_Webcam_HD (0c45:644a) [7.352297] pci :00:00.0: Intel Ivybridge Chipset [7.352352] pci :00:00.0: detected gtt size: 2097152K total, 262144K mappable [7.353313] pci :00:00.0: detected 65536K stolen memory [7.354909] i915 :00:02.0: setting latency timer to 64 [7.354938] iwlwifi :08:00.0: loaded firmware version 18.168.6.1 [7.363208] iwldvm: Intel(R) Wireless WiFi Link AGN driver for Linux, in-tree: [7.363212] iwldvm: Copyright(c) 2003-2012 Intel Corporation [7.363232] iwlwifi :08:00.0: CONFIG_IWLWIFI_DEBUG disabled [7.363235] iwlwifi :08:00.0: CONFIG_IWLWIFI_DEBUGFS disabled [7.363237] iwlwifi :08:00.0: CONFIG_IWLWIFI_DEVICE_TRACING disabled [7.363240] iwlwifi :08:00.0: CONFIG_IWLWIFI_DEVICE_TESTMODE disabled [7.363242] iwlwifi :08:00.0: CONFIG_IWLWIFI_P2P enabled [7.363245] iwlwifi :08:00.0: Detected Intel(R) Centrino(R) Wireless-N 2230 BGN, REV=0xC8 [7.363380] iwlwifi :08:00.0: L1 Enabled; Disabling L0S [7.370404] cfg80211: World regulatory domain updated: [7.370407] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [7.370410] cfg80211: (2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 2000 mBm) [7.370412] cfg80211: (2457000 KHz - 2482000 KHz @ 2 KHz), (300 mBi, 2000 mBm) [7.370414] cfg80211: (2474000 KHz - 2494000 KHz @ 2 KHz), (300 mBi, 2000 mBm) [7.370416] cfg80211: (517 KHz - 525 KHz @ 4 KHz), (300 mBi, 2000 mBm) [7.370418] cfg80211: (5735000 KHz - 5835000 KHz @ 4 KHz), (300 mBi, 2000 mBm) [7.370982] iwlwifi :08:00.0: RF_KILL bit toggled to disable radio. [7.377420] input: Laptop_Integrated_Webcam_HD as /devices/pci:00/:00:1a.0/usb3/3-1/3-1.5/3-1.5:1.0/input/input9 [7.377496] usbcore: registered new interface driver uvcvideo [7.377499] USB Video Class driver (1.1.1) [7.381215] iwlwifi :08:00.0: device EEPROM VER=0x81c, CALIB=0x6 [7.381218] iwlwifi :08:00.0: Device SKU: 0x150 [7.381222] iwlwifi :08:00.0: Valid Tx ant: 0x3, Valid Rx ant: 0x3 [7.381291] Registered led device: phy0-led [7.384636] [drm:__gen6_gt_force_wake_mt_get] *ERROR* Timed out waiting for forcewake old ack to clear. [7.385308] i915 :00:02.0: irq 46 for MSI/MSI-X [7.385320] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [7.385322] [drm] Driver supports precise vblank timestamp query. [7.385430] vgaarb: device changed decodes: PCI::00:02.0,olddecodes=io+mem,decodes=none:owns=io+mem [7.385432] vgaarb: transferring owner from PCI::00:02.0 to PCI::01:00.0 [7.386790] ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs' [7.602887] [drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp off [7.802830] fbcon: inteldrmfb (fb0) is primary device [8.284738] psmouse serio1: elantech: assuming hardware version 3 (with firmware version 0x450f02) [8.314025] psmouse serio1: elantech: Synaptics capabilities query result 0x79, 0x17, 0x0c. [8.479788] input: ETPS/2 Elantech Touchpad as /devices/platform/i8042/serio1/input/input10 [8.519583] Console: switching to colour frame buffer device 240x67 [8.535515] fb0: inteldrmfb frame buffer device [8.535518] drm: registered panic notifier [8.535883] [Firmware Bug]: ACPI(PEGP) defines _DOD but not _DOS [8.537380] acpi device:2d: registered as cooling_device8 [8.537615] ACPI: Video Device [PEGP] (multi-head: yes rom: no post: no) [8.537709] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:2b/LNXVIDEO:00/input/input11 [8.537835] [Firmware Bug]: Duplicate ACPI video bus devices for the same VGA controller, please try module parameter video.allow_duplicates=1if the current driver doesn't work. [
Bug#701148: linux-image-3.7-trunk-amd64: Regression - brightness controls do not work.
Control: tag -1 moreinfo On Fri, 2013-02-22 at 11:31 +0800, David M Smith wrote: Package: src:linux Version: 3.7.8-1~experimental.1 Severity: important If I boot the linux-image-3.6-trunk-amd64, the brightness controls work just fine. Whenever I boot the linux-image-3.7-trunk-amd64 my Fn+F4 and Fn+F5 brightness controls on my laptop do not work. According to xev, the events are getting registered but the brightness of the LCD screen doesn't change. [...] [8.537615] ACPI: Video Device [PEGP] (multi-head: yes rom: no post: no) [8.537709] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:2b/LNXVIDEO:00/input/input11 [8.537835] [Firmware Bug]: Duplicate ACPI video bus devices for the same VGA controller, please try module parameter video.allow_duplicates=1if the current driver doesn't work. [...] This is interesting. Can you try adding 'video.allow_duplicates=1' to the kernel command line, as suggested? Ben. -- Ben Hutchings Sturgeon's Law: Ninety percent of everything is crap. signature.asc Description: This is a digitally signed message part
Processed: Re: Bug#701148: linux-image-3.7-trunk-amd64: Regression - brightness controls do not work.
Processing control commands: tag -1 moreinfo Bug #701148 [src:linux] linux-image-3.7-trunk-amd64: Regression - brightness controls do not work. Added tag(s) moreinfo. -- 701148: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701148 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.b701148.13615120412173.transcr...@bugs.debian.org
Processed: tagging 602966
Processing commands for cont...@bugs.debian.org: tags 602966 + fixed-upstream Bug #602966 [linux-2.6] linux-source-2.6.36: Oops while unmouning an USB key with FAT filesystem Added tag(s) fixed-upstream. thanks Stopping processing here. Please contact me if you need assistance. -- 602966: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602966 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.136151350313346.transcr...@bugs.debian.org
Processed: fsnotify locking fixes - backport to wheezy
Processing control commands: tag -1 patch Bug #602966 [linux-2.6] linux-source-2.6.36: Oops while unmouning an USB key with FAT filesystem Added tag(s) patch. -- 602966: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602966 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.b602966.136151538125346.transcr...@bugs.debian.org
Bug#701148: linux-image-3.7-trunk-amd64: Regression - brightness controls do not work.
Summary: 3.2.0-4-amd64 (Wheezy): Brightness controls work, get a popup indicator showing the brightness should be changing, dmesg says ACPI fails to switch the brightness. 3.6-trunk: Brightness controls work, get a popup indicator showing the brightness should be changing, dmesg says ACPI fails to switch the brightness. 3.7-trunk: Brightness controls do nothing, no popup indicator, no ACPI failures about brightness in dmesg. 3.7-trunk+video.allow_duplicate=1: Brightness controls cause a popup indicator showing brightness should be changing, but the brightness doesn't change. no ACPI failures about brightness in dmesg. 3.6-trunk+video.allow_duplicate=1: Brightness controls cause a popup indicator showing brightness should be changing, but the brightness doesn't change. dmesg says ACPI fails to switch the brightness. -- 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/5127227d.1080...@gmail.com
