Bug#703506: GMA500: higher resolutions than 800x600 don't work
Hi again, I left out the URL for Intel's bug reporting guidelines: Jonathan Nieder wrote: Georg Sassen wrote: While the native resolution (1280x720) worked fine until kernel version 3.2.0.4-686-pae_3.2.35-2, I now only have 800x600 resolution in X11 and the initial framebuffer now on my Nokia Booklet 3G since the update. Thanks for reporting. Can you reproduce this using xserver-xorg-video-modesetting and the 3.8.y kernel from experimental as well? If so, please file a report upstream at bugzilla.kernel.org, product Drivers, component Video(DRI - Intel) with the information described at [1] and let us know the bug number so we can track it. [1] https://01.org/linuxgraphics/documentation/how-report-bugs-0 If not, we can try to find what patch fixed it and apply the same to wheezy. So either result is progress. Thanks again, and sorry for the noise. -- 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/20130321055840.GA5753@elie.Belkin
Bug#703485: [3.2-3.8.3 regression] Battery not detected on Dell Latitude E5530
# regression severity 703485 important quit Hi Jean-Christophe, Jean-Christophe Dubacq wrote: While trying to resolve stability issues with the testing linux image, I tried kernel 3.8 in experimental. I fully understand that this kernel may not be used in production. However, when booting with this kernel, the battery is not detected (and thus, laptop-detect thinks that it is a desktop computer, which it is not). Of course, no /proc/acpi/BAT0 is created, which makes system tools not work. I think the problem lies in the kernel because of this. The first significant difference that I see in the logs is: -ACPI Error: [DCK9] Namespace lookup failure, AE_ALREADY_EXISTS (20121018/dswload2-330) Please report this upstream at bugzilla.kernel.org, product ACPI, component Power-Battery, and let us know the bug number so we can track it. Be sure to include: - steps to reproduce the problem, expected result, actual result, and how the difference indicates a bug (should be simple enough) - which kernel versions you have tested and what happened with each - full dmesg output from an affected and unaffected boot, as attachments - acpidump output, as an attachment Hopefully the upstream developers may have ideas for further tracking the problem down from that point. Then if you'd like to track this down further before hearing back from them, a good way can be to try versions halfway between the newest known-good and oldest known-bad kernels from http://snapshot.debian.org/package/linux/, which can help narrow down the search for the problematic patch. 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/20130321061417.GC5753@elie.Belkin
Processed: Re: [3.2-3.8.3 regression] Battery not detected on Dell Latitude E5530
Processing commands for cont...@bugs.debian.org: # regression severity 703485 important Bug #703485 [src:linux] linux-image-3.8-trunk-amd64: Battery not detected on Dell Latitude E5530 Severity set to 'important' from 'normal' quit Stopping processing here. Please contact me if you need assistance. -- 703485: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703485 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.136384646927352.transcr...@bugs.debian.org
Bug#703592: /dev/console vs. mesg(1) in recovery mode
Package: src:linux Version: 3.2.39-2 Severity: minor At boot choose recovery mode, 'Debian GNU/Linux, with Linux 3.2.0-4-486 (recovery mode)' Type the root password, then in the shell that appears, type # mesg y This will cause mesg: error: tty device is not owned by group `tty' Note I did this on a root account with no dot files ... vanilla installation. Versions of packages linux-image-3.2.0-4-486 depends on: ii debconf [debconf-2.0] 1.5.49 ii initramfs-tools [linux-initramfs-tool] 0.109 ii kmod9-2 ii linux-base 3.5 ii module-init-tools 9-2 -- 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/87r4j9fawi@jidanni.org
Bug#703209: linux: Please Add multiplatform flavour to armhf
On Thu, 2013-03-21 at 12:52 +0900, Nobuhiro Iwamatsu wrote: Hi, On Wed, Mar 20, 2013 at 12:17 AM, Paul Wise p...@debian.org wrote: On Tue, 2013-03-19 at 15:05 +, Ian Campbell wrote: I think the question here is what the `uname -r` bit should be. Specifically the $FLAVOUR in 3.x.y-z-$FLAVOUR. Woops, I missed that uname -r includes the flavour bit. I think there is an argument for making the multiplatform case be the default no-flavour flavour i.e. $FLAVOUR is armhf/arm64 etc. Or maybe that's what you are suggesting having not realised that `uname -r` currently includes the -$FLAVOUR suffix. Hrm, I think we may actually be talking about the same thing ;-) Right, my suggestion is just to use the architecture for the flavour, as is done on the other architectures. Thank you for your comment. In ARM ((but may be used on other architectures as well) ) all architectures, flavor with the name of the CPU do is that it is multiplatform? For example, armv7 flavor is multiplatform support in armhf. A single multiplatform kernel can support both armv6 and armv7 (or armv4 + armv5). I don't know if Debian plans to have separate versions for each architecture version - there may be performance benefits to this - in which case using armv6 -v7 etc sounds like a good idea. Also, a multiplatform kernel can't support armv5 and armv6, so there may need to be more than one 'mp' version anyway. -- Tixy -- 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/1363855369.3242.5.ca...@computer5.home
Bug#703607: Please include Cypress PS/2 Trackpad driver in linux-image-3.2.0-*
Package: src:linux Version: 3.2.39-2 Severity: wishlist Dear Maintainer, Please include the driver for the Cypress PS/2 Trackpad found in newer Dell laptops (Dell XPS 12 and XPS 13) in wheezy's 3.2 kernel. Without this driver the trackpad works as a plain PS/2 mouse with no additional features (tap-to-click, scroll, multitouch support etc). The driver has been merged upstream in 3.9rc1, but a version for 3.2 exists in Ubuntu Precise Pangolin's kernel for Dell's project Sputnik[1]. This version has mostly found its way in Ubuntu's mainline kernel as well AFAICT. The relevant commits from [1] are: 31d910b UBUNTU: SAUCE: Input: fix Cypress PS/2 Trackpad in Dell XPS12 4cb50f2 UBUNTU: SAUCE: input: Cypress PS/2 Trackpad list additional contributors 710840c UBUNTU: SAUCE: input: Cypress PS/2 Trackpad fix taps turning into hardware clicks dc4298f UBUNTU: SAUCE: input: Cypress PS/2 Trackpad fix lost sync upon palm contact b0827c3 UBUNTU: SAUCE: input: Cypress PS/2 Trackpad fix multi-source, double-click 58a51d6 UBUNTU: SAUCE: input: Cypress PS/2 Trackpad fix disabling tap-to-click b0868fe UBUNTU: SAUCE: input: Cypress PS/2 Trackpad move PSMOUSE_CYPRESS enum e49b04c UBUNTU: SAUCE: input: Cypress PS/2 Trackpad link driver into psmouse-base a36670e UBUNTU: SAUCE: input: Cypress PS/2 Trackpad set default debug_level=0 ca0b397 UBUNTU: SAUCE: input: Cypress PS/2 Trackpad fix no-config stubs a6bc484 UBUNTU: SAUCE: input: Cypress PS/2 Trackpad eliminate dead code cd01bae UBUNTU: SAUCE: input: Cypress PS/2 Trackpad code style cleanup e8b4fed UBUNTU: SAUCE: input: Cypress PS/2 Trackpad mouse driver They apply cleanly to Debian's 3.2.39-2 with the exception of an ubuntu-specific build-system file not needed in Debian. The kernel builds successfully and the trackpad seems to function properly using the synaptics X11 driver. The trackpad driver from 3.9rc1 is not trivial to backport since the kernel's multitouch input API has changed significantly. [1] git://kernel.ubuntu.com/kamal/ubuntu-precise.git http://kernel.ubuntu.com/git?p=kamal/ubuntu-precise.git;a=shortlog;h=refs/heads/dellxps Regards, Apollon -- Package-specific info: ** Version: Linux version 3.2.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-15) ) #1 SMP Debian 3.2.39-2 ** Command line: BOOT_IMAGE=/vmlinuz-3.2.0-4-amd64 root=/dev/mapper/ssd-root ro ** Not tainted -- System Information: Debian Release: 7.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing'), (90, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=el_GR.UTF-8, LC_CTYPE=el_GR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages linux-image-3.2.0-4-amd64 depends on: ii debconf [debconf-2.0] 1.5.49 ii initramfs-tools [linux-initramfs-tool] 0.109 ii kmod9-2 ii linux-base 3.5 ii module-init-tools 9-2 Versions of packages linux-image-3.2.0-4-amd64 recommends: ii firmware-linux-free 3.2 Versions of packages linux-image-3.2.0-4-amd64 suggests: pn debian-kernel-handbook none ii grub-pc 1.99-27 ii linux-doc-3.2 3.2.39-2 Versions of packages linux-image-3.2.0-4-amd64 is related to: pn firmware-atherosnone pn firmware-bnx2 none pn firmware-bnx2x none pn firmware-brcm80211 none pn firmware-intelwimax none pn firmware-ipw2x00none pn firmware-ivtv none pn firmware-iwlwifinone pn firmware-libertas none pn firmware-linux none ii firmware-linux-nonfree 0.36+wheezy.1 pn firmware-myricomnone pn firmware-netxen none pn firmware-qlogic none pn firmware-ralink none pn firmware-realteknone pn xen-hypervisor none -- debconf information excluded -- 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/20130321102149.ga8...@apollon.skroutz.gr
how are you?
http://wheusden.nl/wp-content/windows8.php?gzcfbwwt700rkzzdh = It really is a shame that this is the only planet we have a choice to live on. -- Howard Stern
Bug#703506: GMA500: higher resolutions than 800x600 don't work
Hi Jonathan, Thanks for reporting. Can you reproduce this using xserver-xorg-video-modesetting and the 3.8.y kernel from experimental as well? With the 3.8 kernel it works fine, the gma500_gfx module ist loaded and the native resolution of the display shown. I don't see your GPU driver here. It seems CONFIG_DRM_GMA500 (and maybe CONFIG_STUB_POULSBO) is not set in the kernel config, so the gma500_gfx is not built at all, maybe because of the name change from psb_gfx which was loaded with the 3.2.35 kernel. I enabled the config options, and now the little machine is compiling a new kernel, which might take some time though... I will tell if it works. Georg -- 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/20130321133358.ga30...@sassen.de
Bug#703209: linux: Please Add multiplatform flavour to armhf
On Thu, Mar 21, 2013 at 08:42:49AM +, Tixy wrote: A single multiplatform kernel can support both armv6 and armv7 (or armv4 + armv5). I don't know if Debian plans to have separate versions for each architecture version - there may be performance benefits to this - in which case using armv6 -v7 etc sounds like a good idea. Also, a multiplatform kernel can't support armv5 and armv6, so there may need to be more than one 'mp' version anyway. Well armhf only supports armv7 so far, so armv6 adn armv5 are irrelevant to armhf. armel would be a different question. I do wonder how long armel will continue to be maintained if most of the arm developers get too excited with armhf. :) -- Len Sorensen -- 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/20130321135535.gk1...@csclub.uwaterloo.ca
Bug#703592: marked as done (/dev/console vs. mesg(1) in recovery mode)
Your message dated Thu, 21 Mar 2013 14:18:08 + with message-id 1363875488.31336.118.ca...@deadeye.wl.decadent.org.uk and subject line Re: Bug#703592: /dev/console vs. mesg(1) in recovery mode has caused the Debian Bug report #703592, regarding /dev/console vs. mesg(1) in recovery mode 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.) -- 703592: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703592 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: src:linux Version: 3.2.39-2 Severity: minor At boot choose recovery mode, 'Debian GNU/Linux, with Linux 3.2.0-4-486 (recovery mode)' Type the root password, then in the shell that appears, type # mesg y This will cause mesg: error: tty device is not owned by group `tty' Note I did this on a root account with no dot files ... vanilla installation. Versions of packages linux-image-3.2.0-4-486 depends on: ii debconf [debconf-2.0] 1.5.49 ii initramfs-tools [linux-initramfs-tool] 0.109 ii kmod9-2 ii linux-base 3.5 ii module-init-tools 9-2 ---End Message--- ---BeginMessage--- On Thu, 2013-03-21 at 15:51 +0800, jida...@jidanni.org wrote: Package: src:linux Don't be ridiculous. Version: 3.2.39-2 Severity: minor At boot choose recovery mode, 'Debian GNU/Linux, with Linux 3.2.0-4-486 (recovery mode)' Type the root password, then in the shell that appears, type # mesg y [...] # tty /dev/console You booted in single user mode. What would be the point of letting other users write to your terminal? Besides which /dev/console had damn well better be trustworthy. Ben. -- Ben Hutchings It is easier to write an incorrect program than to understand a correct one. signature.asc Description: This is a digitally signed message part ---End Message---
Bug#703592: closed by Ben Hutchings b...@decadent.org.uk (Re: Bug#703592: /dev/console vs. mesg(1) in recovery mode)
B You booted in single user mode. What would be the point of letting B other users write to your terminal? Besides which /dev/console had damn B well better be trustworthy. The point is that single user mode comes before the ttys are fully set up! It should come after! -- 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/87ehf8kej5@jidanni.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 #702885 (http://bugs.debian.org/702885) # Bug title: linux-image-3.8-trunk-amd64: Samsung NP900X3C display does not resume from suspend # * http://bugzilla.kernel.org/show_bug.cgi?id=47941 # * remote status changed: (?) - REOPENED usertags 702885 + 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/20130321164051.1741.74243.btsl...@sonntag.debian.org
Bug#703637: linux-image-3.2.0-4-amd64: Kernel Panic randomly after upgrade to 3.2.39-2
Package: src:linux Version: 3.2.39-2 Severity: important Dear Maintainer, I got kernel panic randomly after I upgrade the kernel from 3.2.35 to 3.2.39-2. I have tried to rollback the kernel to 3.2.35, and the kernel works fine again. -- Package-specific info: ** Version: Linux version 3.2.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-15) ) #1 SMP Debian 3.2.39-2 ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.2.0-4-amd64 root=UUID=713ff01f-7459-40f3-91b0-0192dac30afc ro i915.i915_enable_rc6=1 i915.i915_enable_fbc=1 i915.lvds_downclock=1 quiet i915.i915_enable_rc6=1 i915.i915_enable_fbc=1 i915.lvds_downclock=1 ** Tainted: O (4096) * Out-of-tree module has been loaded. ** Kernel log: [4.471153] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 [4.471997] snd_hda_intel :00:1b.0: irq 44 for MSI/MSI-X [4.472071] snd_hda_intel :00:1b.0: setting latency timer to 64 [5.021146] input: HDA Digital PCBeep as /devices/pci:00/:00:1b.0/input/input11 [5.029625] HDMI status: Codec=3 Pin=5 Presence_Detect=0 ELD_Valid=0 [5.029832] HDMI status: Codec=3 Pin=6 Presence_Detect=0 ELD_Valid=0 [5.030018] HDMI status: Codec=3 Pin=7 Presence_Detect=0 ELD_Valid=0 [5.030293] input: HDA Intel PCH HDMI/DP,pcm=8 as /devices/pci:00/:00:1b.0/sound/card0/input12 [5.030498] input: HDA Intel PCH HDMI/DP,pcm=7 as /devices/pci:00/:00:1b.0/sound/card0/input13 [5.030679] input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci:00/:00:1b.0/sound/card0/input14 [5.031449] input: HDA Intel PCH Mic as /devices/pci:00/:00:1b.0/sound/card0/input15 [5.031617] input: HDA Intel PCH Mic as /devices/pci:00/:00:1b.0/sound/card0/input16 [5.031779] input: HDA Intel PCH Headphone as /devices/pci:00/:00:1b.0/sound/card0/input17 [5.588319] EXT4-fs (sda2): re-mounted. Opts: (null) [5.641509] EXT4-fs (sda2): re-mounted. Opts: discard,errors=remount-ro [5.685699] loop: module loaded [6.815490] EXT4-fs (sda3): mounted filesystem with ordered data mode. Opts: discard [7.714414] thinkpad_ec: thinkpad_ec_request_row: arg0 rejected: (0x01:0x00)-0x00 [7.714419] thinkpad_ec: thinkpad_ec_read_row: failed requesting row: (0x01:0x00)-0xfffb [7.714491] thinkpad_ec: initial ec test failed [8.117278] /dev/vmmon[2577]: Module vmmon: registered with major=10 minor=165 [8.117301] /dev/vmmon[2577]: Module vmmon: initialized [8.140298] [2611]: VMCI: shared components initialized. [8.140342] [2611]: VMCI: host components initialized. [8.140430] [2611]: VMCI: Module registered (name=vmci,major=10,minor=57). [8.140433] [2611]: VMCI: Using host personality [8.140435] [2611]: VMCI: Module (name=vmci) is initialized [8.164463] Bluetooth: Core ver 2.16 [8.164503] NET: Registered protocol family 31 [8.164505] Bluetooth: HCI device and connection manager initialized [8.164509] Bluetooth: HCI socket layer initialized [8.164511] Bluetooth: L2CAP socket layer initialized [8.164517] Bluetooth: SCO socket layer initialized [8.167673] Bluetooth: RFCOMM TTY layer initialized [8.167679] Bluetooth: RFCOMM socket layer initialized [8.167682] Bluetooth: RFCOMM ver 1.11 [8.199121] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [8.199125] Bluetooth: BNEP filters: protocol multicast [8.214214] fuse init (API version 7.17) [8.288168] Bridge firewalling registered [8.414609] e1000e :00:19.0: irq 40 for MSI/MSI-X [8.466958] e1000e :00:19.0: irq 40 for MSI/MSI-X [8.470010] ADDRCONF(NETDEV_UP): eth0: link is not ready [8.470203] netlink: 12 bytes leftover after parsing attributes. [8.470291] netlink: 12 bytes leftover after parsing attributes. [8.484360] rtl8192c_common: Loading firmware file rtlwifi/rtl8192cfw.bin [8.824296] /dev/vmnet: open called by PID 2880 (vmnet-netifup) [8.824317] /dev/vmnet: hub 1 does not exist, allocating memory. [8.824390] /dev/vmnet: port on hub 1 successfully opened [8.825144] /dev/vmnet: open called by PID 2863 (vmnet-bridge) [8.825166] /dev/vmnet: hub 0 does not exist, allocating memory. [8.825245] /dev/vmnet: port on hub 0 successfully opened [8.827878] ADDRCONF(NETDEV_UP): wlan0: link is not ready [8.833406] bridge-wlan0: device is wireless, enabling SMAC [8.833412] bridge-wlan0: up [8.833415] bridge-wlan0: attached [8.833484] bridge-wlan0: disabling the bridge on dev down [8.833552] bridge-wlan0: down [8.833556] bridge-wlan0: detached [8.852886] ip_tables: (C) 2000-2006 Netfilter Core Team [8.901863] /dev/vmnet: open called by PID 2889 (vmnet-dhcpd) [8.901884] /dev/vmnet: port on hub 1 successfully opened [8.911125] /dev/vmnet: open called by PID 2912 (vmnet-natd) [8.911134] /dev/vmnet: hub 8 does not exist, allocating memory. [8.911149] /dev/vmnet: port on hub 8 successfully opened [
Bug#703506: GMA500: higher resolutions than 800x600 don't work
On Wed, Mar 20, 2013 at 22:58:41 -0700, Jonathan Nieder wrote: Hi again, I left out the URL for Intel's bug reporting guidelines: Jonathan Nieder wrote: Georg Sassen wrote: While the native resolution (1280x720) worked fine until kernel version 3.2.0.4-686-pae_3.2.35-2, I now only have 800x600 resolution in X11 and the initial framebuffer now on my Nokia Booklet 3G since the update. Thanks for reporting. Can you reproduce this using xserver-xorg-video-modesetting and the 3.8.y kernel from experimental as well? If so, please file a report upstream at bugzilla.kernel.org, product Drivers, component Video(DRI - Intel) with the information described at [1] and let us know the bug number so we can track it. [1] https://01.org/linuxgraphics/documentation/how-report-bugs-0 That's for i915. psb is not maintained by the same team. So I'm not sure these instructions are appropriate. Cheers, Julien signature.asc Description: Digital signature
Bug#703637: linux-image-3.2.0-4-amd64: Kernel Panic randomly after upgrade to 3.2.39-2
On Fri, Mar 22, 2013 at 01:32:07 +0800, SuperCat wrote: Package: src:linux Version: 3.2.39-2 Severity: important Dear Maintainer, I got kernel panic randomly after I upgrade the kernel from 3.2.35 to 3.2.39-2. I have tried to rollback the kernel to 3.2.35, and the kernel works fine again. Please provide a log or image of the panic message. ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.2.0-4-amd64 root=UUID=713ff01f-7459-40f3-91b0-0192dac30afc ro i915.i915_enable_rc6=1 i915.i915_enable_fbc=1 i915.lvds_downclock=1 quiet i915.i915_enable_rc6=1 i915.i915_enable_fbc=1 i915.lvds_downclock=1 And please remove these i915 options from your kernel command line. There's a reason they're not the default. Cheers, Julien signature.asc Description: Digital signature
Processed: tagging 703637
Processing commands for cont...@bugs.debian.org: tags 703637 + moreinfo Bug #703637 [src:linux] linux-image-3.2.0-4-amd64: Kernel Panic randomly after upgrade to 3.2.39-2 Added tag(s) moreinfo. thanks Stopping processing here. Please contact me if you need assistance. -- 703637: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703637 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.136389002019059.transcr...@bugs.debian.org
Bug#703640: src:linux: [3.8 - 3.8.1 regression]: Resume from suspend stuck with framebuffer locking rework
Package: src:linux Version: 3.8.3-1~experimental.1 Severity: important Tags: upstream Hi, As mentioned in the subject, the following commit prevents me to resume from suspend in kernel ≥ 3.8.1: commit cace7c323ddde7358ab2f2390ece964c55f30330 Author: Alan Cox a...@linux.intel.com Date: Fri Jan 25 10:28:15 2013 +1000 fb: rework locking to fix lock ordering on takeover commit 50e244cc793d511b86adea24972f3a7264cae114 upstream. Adjust the console layer to allow a take over call where the caller already holds the locks. Make the fb layer lock in order. This is partly a band aid, the fb layer is terminally confused about the locking rules it uses for its notifiers it seems. [a...@linux-foundation.org: remove stray non-ascii char, tidy comment] [a...@linux-foundation.org: export do_take_over_console()] [airlied: cleanup another non-ascii char] Signed-off-by: Alan Cox a...@linux.intel.com Cc: Florian Tobias Schandinat florianschandi...@gmx.de Cc: Stephen Rothwell s...@canb.auug.org.au Cc: Jiri Kosina jkos...@suse.cz Tested-by: Sedat Dilek sedat.di...@gmail.com Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch Signed-off-by: Andrew Morton a...@linux-foundation.org Signed-off-by: Dave Airlie airl...@redhat.com Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org I didn't try to boot with this commit reverted, and looking at its size, I fear there will be some conflict to solve before attempting to do so. I guess it could be interesting to try 3.9-rc. to see how it behaves (I didn't see what have been merged in this area in the last merge window). I might try to connect through ssh to see if I get a trace. Cheers, Vincent -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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/20130321182819.4630.88444.reportbug@lamella
Bug#703506: GMA500: higher resolutions than 800x600 don't work
Hi, Julien Cristau wrote: On Wed, Mar 20, 2013 at 22:58:41 -0700, Jonathan Nieder wrote: Jonathan Nieder wrote: Georg Sassen wrote: While the native resolution (1280x720) worked fine until kernel version 3.2.0.4-686-pae_3.2.35-2, I now only have 800x600 resolution in X11 and the initial framebuffer now on my Nokia Booklet 3G since the update. Thanks for reporting. Can you reproduce this using xserver-xorg-video-modesetting and the 3.8.y kernel from experimental as well? If so, please file a report upstream at bugzilla.kernel.org, product Drivers, component Video(DRI - Intel) with the information described at [1] and let us know the bug number so we can track it. [1] https://01.org/linuxgraphics/documentation/how-report-bugs-0 That's for i915. psb is not maintained by the same team. So I'm not sure these instructions are appropriate. I know Alan takes reports through bugzilla.kernel.org, and I know Intel gives good advice about what information to include in such a report. Beyond that, all bets are off. I certainly don't think the instructions are inappropriate, unless there is some way they cause harm that I missed. Are you in contact with the upstream i915 team? Perhaps a pointer on that page to another page describing how to handle psb bugs would avoid confusion. Luckily the bug isn't reproducible in 3.8.y, so that particular question is moot. 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/20130321190356.ge29...@google.com
Bug#703506: GMA500: higher resolutions than 800x600 don't work
On Thu, Mar 21, 2013 at 12:03:56 -0700, Jonathan Nieder wrote: I know Alan takes reports through bugzilla.kernel.org Still? I thought that would have kinda stopped after https://plus.google.com/04121194250082892/posts/KW3TdRYwjr9 Cheers, Julien signature.asc Description: Digital signature
Bug#703506: GMA500: higher resolutions than 800x600 don't work
Julien Cristau wrote: On Thu, Mar 21, 2013 at 12:03:56 -0700, Jonathan Nieder wrote: I know Alan takes reports through bugzilla.kernel.org Still? I thought that would have kinda stopped after https://plus.google.com/04121194250082892/posts/KW3TdRYwjr9 You're right. I'm out of date. There have been fixes since then sent through the drm tree. bugzilla.kernel.org + mailing lists are still probably the best place to coordinate. -- 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/20130321194508.gf29...@google.com
Processed: tagging 703640
Processing commands for cont...@bugs.debian.org: tags 703640 + moreinfo Bug #703640 [src:linux] src:linux: [3.8 - 3.8.1 regression]: Resume from suspend stuck with framebuffer locking rework Added tag(s) moreinfo. thanks Stopping processing here. Please contact me if you need assistance. -- 703640: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703640 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.136389738212583.transcr...@bugs.debian.org
Bug#703640: src:linux: [3.8 - 3.8.1 regression]: Resume from suspend stuck with framebuffer locking rework
Le jeudi 21 mars 2013 à 19:28 +0100, Vincent Blut a écrit : Package: src:linux Version: 3.8.3-1~experimental.1 Severity: important Tags: upstream Hi, As mentioned in the subject, the following commit prevents me to resume from suspend in kernel ≥ 3.8.1: commit cace7c323ddde7358ab2f2390ece964c55f30330 Author: Alan Cox a...@linux.intel.com Date: Fri Jan 25 10:28:15 2013 +1000 fb: rework locking to fix lock ordering on takeover commit 50e244cc793d511b86adea24972f3a7264cae114 upstream. Adjust the console layer to allow a take over call where the caller already holds the locks. Make the fb layer lock in order. This is partly a band aid, the fb layer is terminally confused about the locking rules it uses for its notifiers it seems. [a...@linux-foundation.org: remove stray non-ascii char, tidy comment] [a...@linux-foundation.org: export do_take_over_console()] [airlied: cleanup another non-ascii char] Signed-off-by: Alan Cox a...@linux.intel.com Cc: Florian Tobias Schandinat florianschandi...@gmx.de Cc: Stephen Rothwell s...@canb.auug.org.au Cc: Jiri Kosina jkos...@suse.cz Tested-by: Sedat Dilek sedat.di...@gmail.com Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch Signed-off-by: Andrew Morton a...@linux-foundation.org Signed-off-by: Dave Airlie airl...@redhat.com Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org I didn't try to boot with this commit reverted, and looking at its size, I fear there will be some conflict to solve before attempting to do so. I guess it could be interesting to try 3.9-rc. to see how it behaves (I didn't see what have been merged in this area in the last merge window). I might try to connect through ssh to see if I get a trace. Same issue with 3.9-rc3, I'll try to find some time tomorrow in order to get eventual stack traces. Cheers, Vincent -- 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/1363899395.3891.2.camel@lamella
Re: [PATCH] ext4/jbd2: don't wait (forever) for stale tid caused by wraparound
On Thu, Mar 21, 2013 at 09:46:38PM +0100, Jan Kara wrote:
Good catch! But shouldn't we rather fix jbd2_log_wait_commit() instead of
inventing new function?
In most of the places where we call jbd2_log_start_commit(), we're
actually starting the current running transaction. So the fact that
we pass in a tid, and we're having to validate that the tid is
actually a valid one, is a bit of a waste. So in the long run I think
it's worth rethinking whether or not jbd2_log_{start,wait}_commit()
should exist in their current form, or whether we should reorganize
their functionality (i.e., by having a jbd2_start_running_commit(),
for example.). Piling on fixes to jbd2_log_wait_commit() would make
it get even more complicated, and I think if we separate out the
various ways in which we use these functions, we can make the code
simpler and easier to read.
In fact, I had started making this rather large set of changes when I
decided it would be better to save that kind of wholesale refactoring
for the next merge window. So the reason why I ended up fixing the
patch the way I did was to keep things simple.
Also as I mentioned in the commit description, by using a single
function I was also able to optimize the locking the locking somewhat.
- Ted
--
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/20130321210940.gd21...@thunk.org
Re: [PATCH] ext4/jbd2: don't wait (forever) for stale tid caused by wraparound
On Sun 17-03-13 22:54:01, Ted Tso wrote:
On Sat, Mar 16, 2013 at 05:34:22AM +, Ben Hutchings wrote:
We use debian for a number of machines in our storage infrastructure
and we have recently been seeing a number of hangs. We primary
notice this by seeing nfsd processes locking up and then a hung task
killer going wild. We finally managed to get a trace last night - its
pasted below:
Thanks for reporting this. I thought we had fixed this in 3.0.
Before then, when we had a tid wrap, it would result in kjournald
spinning forever. I suspect this was your spontaneous reboots that
you mentioned you mentioned when you were using 2.6.39 --- did you
have a hardware or softward watchdog timer enabled by any chance?
Since we didn't have a good way of reproducing the problem at the
time, I didn't realize that the problem had not been fully fixed;
since while jbd2_log_start_commit() would no longer cause kjournald to
spin forwever, a subsequent call to jbd2_log_wait_commit() with a
stale transaction id would wait for a very long time (possibly until
the heat death of the universe :-)
I think a patch like this should fix things; I've run a stress test
with a hack to increment the transaction id by 1 24 after each
commit, to more quickly cause an tid wrap, and the regression tests
seem to be passing without complaint.
- Ted
From 76b05344fef573701b22ced444223188f054f94d Mon Sep 17 00:00:00 2001
From: Theodore Ts'o ty...@mit.edu
Date: Sun, 17 Mar 2013 22:24:46 -0400
Subject: [PATCH] ext4/jbd2: don't wait (forever) for stale tid caused by
wraparound
In the case where an inode has a very stale transaction id (tid) in
i_datasync_tid or i_sync_tid, it's possible that after a very large
(2**31) number of transactions, that the tid number space might wrap,
causing tid_geq()'s calculations to fail.
Commit deeeaf13 jbd2: fix fsync() tid wraparound bug, later modified
by commit e7b04ac0 jbd2: don't wake kjournald unnecessarily,
attempted to fix this problem, but it only avoided kjournald spinning
forever by fixing the logic in jbd2_log_start_commit().
Unfortunately, in the codepaths in fs/ext4/fsync.c and fs/ext4/inode.c
that might call jbd2_log_start_commit() with a stale tid, those
functions will subsequently call jbd2_log_wait_commit() with the same
stale tid, and then wait for a very long time. To fix this, we
replace the calls to jbd2_log_start_commit() and
jbd2_log_wait_commit() with a call to a new function,
jbd2_complete_transaction(), which will correctly handle stale tid's.
As a bonus, jbd2_complete_transaction() will avoid locking
j_state_lock for writing unless a commit needs to be started. This
should have a small (but probably not measurable) improvement for
ext4's scalability.
Signed-off-by: Theodore Ts'o ty...@mit.edu
Reported-by: Ben Hutchings b...@decadent.org.uk
Reported-by: George Barnett gbarn...@atlassian.com
Cc: sta...@vger.kernel.org
Good catch! But shouldn't we rather fix jbd2_log_wait_commit() instead of
inventing new function? So jbd2_log_wait_commit() would do something like:
__func__, journal-j_commit_request, tid);
}
#endif
+ /* Not running or committing trans = must be already committed. */
+ if (!((journal-j_running_transaction
+journal-j_running_transaction-t_tid == tid) ||
+ (journal-j_committing_transaction
+journal-j_committing_transaction-t_tid == tid))) {
+ read_unlock(journal-j_state_lock);
+ return 0;
+ }
while (tid_gt(tid, journal-j_commit_sequence)) {
jbd_debug(1, JBD2: want %d, j_commit_sequence=%d\n,
tid, journal-j_commit_sequence);
Honza
---
fs/ext4/fsync.c | 3 +--
fs/ext4/inode.c | 3 +--
fs/jbd2/journal.c| 31 +++
include/linux/jbd2.h | 1 +
4 files changed, 34 insertions(+), 4 deletions(-)
diff --git a/fs/ext4/fsync.c b/fs/ext4/fsync.c
index 3278e64..e0ba8a4 100644
--- a/fs/ext4/fsync.c
+++ b/fs/ext4/fsync.c
@@ -166,8 +166,7 @@ int ext4_sync_file(struct file *file, loff_t start,
loff_t end, int datasync)
if (journal-j_flags JBD2_BARRIER
!jbd2_trans_will_send_data_barrier(journal, commit_tid))
needs_barrier = true;
- jbd2_log_start_commit(journal, commit_tid);
- ret = jbd2_log_wait_commit(journal, commit_tid);
+ ret = jbd2_complete_transaction(journal, commit_tid);
if (needs_barrier) {
err = blkdev_issue_flush(inode-i_sb-s_bdev, GFP_KERNEL, NULL);
if (!ret)
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index b6fab7c..de4b58d 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -211,8 +211,7 @@ void ext4_evict_inode(struct inode *inode)
Re: [PATCH] ext4/jbd2: don't wait (forever) for stale tid caused by wraparound
On Thu 21-03-13 17:09:40, Ted Tso wrote:
On Thu, Mar 21, 2013 at 09:46:38PM +0100, Jan Kara wrote:
Good catch! But shouldn't we rather fix jbd2_log_wait_commit() instead of
inventing new function?
In most of the places where we call jbd2_log_start_commit(), we're
actually starting the current running transaction. So the fact that
we pass in a tid, and we're having to validate that the tid is
actually a valid one, is a bit of a waste. So in the long run I think
it's worth rethinking whether or not jbd2_log_{start,wait}_commit()
should exist in their current form, or whether we should reorganize
their functionality (i.e., by having a jbd2_start_running_commit(),
for example.). Piling on fixes to jbd2_log_wait_commit() would make
it get even more complicated, and I think if we separate out the
various ways in which we use these functions, we can make the code
simpler and easier to read.
I don't find jbd2_log_wait_commit() that complex that it couldn't bear
another if :) But given there are really two waiting operations that make
sense:
a) request commit of running transaction and wait for it
b) wait for committing transaction
then I agree there may be a better interface. OTOH I'm somewhat
curious about the new interface because the only race-free way of
identifying a transaction you want to wait for is using its tid.
In fact, I had started making this rather large set of changes when I
decided it would be better to save that kind of wholesale refactoring
for the next merge window. So the reason why I ended up fixing the
patch the way I did was to keep things simple.
Also as I mentioned in the commit description, by using a single
function I was also able to optimize the locking the locking somewhat.
Yeah. I'm not as much opposed to the new function doing start commit
wait but what I dislike is the fact that we have still exposed the
function jbd2_log_wait_commit() which can possibly lockup if tid overflows.
I agree there aren't currently any other callers where this could happen
but in a few years who knows...
Honza
--
Jan Kara j...@suse.cz
SUSE Labs, CR
--
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/20130321224143.ga5...@quack.suse.cz
Bug#703665: linux-image-3.8-trunk-amd64: version 3.8.3-1~experimental.1 causes xrandr to detect too many monitors
Package: src:linux Version: 3.8.3-1~experimental.1 Severity: important Dear Maintainer, Recently it was discovered in Ubuntu that version 3.8.3 of the linux kernel had issues that caused xrandr to detect an external monitor connected to a laptop with Intel integrated graphics when in fact no monitors were connected, limiting the max display resolution to 1024x768 until the Mirrored Displays option was unchecked. This would allow one to set the laptop display to the correct resolution, though it would eventually reset itself back to 1024x768 because all open applications would fail to be drawn correctly on the window upon changing the resolution, meaning confirming the new settings wasn't possible. Logging out before this happens then logging back in would keep the changed resolution for the user, however the consoles and login screen would retain the incorrect resolution. I want to point out that your current kernel suffers from the same issues, and the Ubuntu kernel has recently been fixed so it no longer happens. The launchpad bug about this issue is here, for your perusal: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1156310 I hope you take a look into this and release a fixed kernel soon, until then I'll revert back to 3.8.2 to avoid this issue. -- Package-specific info: ** Version: Linux version 3.8-trunk-amd64 (debian-kernel@lists.debian.org) (gcc version 4.7.2 (Debian 4.7.2-5) ) #1 SMP Debian 3.8.2-1~experimental.1 ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.8-trunk-amd64 root=UUID=376d5c13-85a6-476a-aa9e-1be9dc19d808 ro quiet splash ** Tainted: I (2048) * Working around severe firmware bug. ** Kernel log: [8.272826] Intel(R) Wireless WiFi driver for Linux, in-tree: [8.272831] Copyright(c) 2003-2012 Intel Corporation [8.273251] iwlwifi :02:00.0: irq 44 for MSI/MSI-X [8.493515] Linux video capture interface: v2.00 [8.593711] uvcvideo: Found UVC 1.00 device CNF9011 (04f2:b175) [8.610028] input: CNF9011 as /devices/pci:00/:00:1d.7/usb2/2-5/2-5:1.0/input/input9 [8.610179] usbcore: registered new interface driver uvcvideo [8.610182] USB Video Class driver (1.1.1) [8.624411] iwlwifi :02:00.0: loaded firmware version 39.31.5.1 build 35138 [8.856100] iwlwifi :02:00.0: CONFIG_IWLWIFI_DEBUG disabled [8.856107] iwlwifi :02:00.0: CONFIG_IWLWIFI_DEBUGFS disabled [8.856111] iwlwifi :02:00.0: CONFIG_IWLWIFI_DEVICE_TRACING disabled [8.856115] iwlwifi :02:00.0: CONFIG_IWLWIFI_DEVICE_TESTMODE disabled [8.856119] iwlwifi :02:00.0: CONFIG_IWLWIFI_P2P enabled [8.856124] iwlwifi :02:00.0: Detected Intel(R) Centrino(R) Wireless-N 1000 BGN, REV=0x6C [8.856266] iwlwifi :02:00.0: L1 Enabled; Disabling L0S [8.942282] ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs' [9.132175] snd_hda_intel :00:1b.0: irq 45 for MSI/MSI-X [9.483932] psmouse serio2: synaptics: Touchpad model: 1, fw: 7.2, id: 0x1c0b1, caps: 0xd04733/0xa4/0xa, board id: 3655, fw id: 568746 [9.499796] input: HDA Digital PCBeep as /devices/pci:00/:00:1b.0/input/input10 [9.530035] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio2/input/input11 [9.576457] input: HDA Intel HDMI/DP,pcm=3 as /devices/pci:00/:00:1b.0/sound/card0/input12 [9.576664] input: HDA Intel Mic as /devices/pci:00/:00:1b.0/sound/card0/input13 [9.576827] input: HDA Intel Headphone as /devices/pci:00/:00:1b.0/sound/card0/input14 [9.790952] cfg80211: World regulatory domain updated: [9.790957] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [9.790962] cfg80211: (2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 2000 mBm) [9.790966] cfg80211: (2457000 KHz - 2482000 KHz @ 2 KHz), (300 mBi, 2000 mBm) [9.790970] cfg80211: (2474000 KHz - 2494000 KHz @ 2 KHz), (300 mBi, 2000 mBm) [9.790974] cfg80211: (517 KHz - 525 KHz @ 4 KHz), (300 mBi, 2000 mBm) [9.790977] cfg80211: (5735000 KHz - 5835000 KHz @ 4 KHz), (300 mBi, 2000 mBm) [ 12.416431] Adding 1048572k swap on /dev/sda3. Priority:-1 extents:1 across:1048572k [ 12.440647] EXT4-fs (sda1): re-mounted. Opts: (null) [ 12.831851] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro [ 13.077889] fuse init (API version 7.20) [ 13.114873] loop: module loaded [ 16.539343] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null) [ 16.592183] EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: (null) [ 25.942738] Bluetooth: Core ver 2.16 [ 25.942769] NET: Registered protocol family 31 [ 25.942772] Bluetooth: HCI device and connection manager initialized [ 25.942785] Bluetooth: HCI socket layer initialized [ 25.942790] Bluetooth: L2CAP socket layer initialized [ 25.942799] Bluetooth: SCO socket layer initialized [ 26.035018] Bluetooth: RFCOMM TTY layer
[RFC] Putting the date back into utsname::version
[Please reply to the debian-kernel list only.]
We have a longstanding support problem where there is confusion between
the kernel release string (utsname::release, output of uname -r, tail of
package names) and the kernel package version.
Until recently, even uname -a would not report the package version for
the running kernel. You would have to look in /proc/version or the
kernel log. See bug #638878.
I dealt with this bug by changing the format of utsname::version
(output of uname -v) from:
# build-counter { flag }* date
to:
# build-counter { flag }* Debian package-version
(The date format being the default output format of the date command.)
However, two sysadmins have since complained that they find the date of
the current package easier to check than the package version string.
Certainly, there is more entropy in the date strings of stable package
updates than in their version strings.
The userland ABI sets a hard limit of 64 bytes (not including
terminating null) for this string. This is not sufficient to include
all the information in the old and new formats (otherwise I would not
have removed the date).
Here are examples of the old, new and possible alternative formats using
likely maximum-length components:
old: #1 SMP PREEMPT RT Tue Mar 21 23:12:08 GMT 2023 [46]
new: #1 SMP PREEMPT RT Debian 9.99~rc99-9~experimental.9 [51]
alt: #1 SMP PREEMPT RT 2023-02-21 Debian 9.99~rc99-9~experimental.9 [62]
alt: #1 SMP PREEMPT RT Debian 9.99~rc99-9~experimental.9 (2023-02-21) [64]
We could perhaps shorten 'experimental' to 'exp', which would leave
stable security updates with the longest version strings and allow for:
alt: #1 SMP PREEMPT RT Tue Mar 21 2023 Debian 9.99.99-9codename9 [59]
alt: #1 SMP PREEMPT RT Debian 9.99.99-9codename9 (Tue Mar 21 2023)[61]
Would anyone like to argue in favour of any particular alternative?
Ben.
--
Ben Hutchings
It is easier to write an incorrect program than to understand a correct one.
signature.asc
Description: This is a digitally signed message part
PREEMPT_RT vs 'hrtimer: Prevent hrtimer_enqueue_reprogram race'
Commit b22affe0aef4 'hrtimer: Prevent hrtimer_enqueue_reprogram race'
conflicts with the RT patches
hrtimer-fixup-hrtimer-callback-changes-for-preempt-r.patch and
peter_zijlstra-frob-hrtimer.patch, as they all change
hrtimer_enqueue_reprogram(). It seems that the changes in the RT
patches now belong in __hrtimer_start_range_ns().
Since I haven't seen any RT releases in a while, here's what I came up
with for 3.2-rt:
---
From: Thomas Gleixner t...@linutronix.de
Date: Fri, 3 Jul 2009 08:44:31 -0500
Subject: hrtimer: fixup hrtimer callback changes for preempt-rt
In preempt-rt we can not call the callbacks which take sleeping locks
from the timer interrupt context.
Bring back the softirq split for now, until we fixed the signal
delivery problem for real.
Signed-off-by: Thomas Gleixner t...@linutronix.de
Signed-off-by: Ingo Molnar mi...@elte.hu
[bwh: Pull the changes to hrtimer_enqueue_reprogram() up into
__hrtimer_start_range_ns(), following changes in
commit b22affe0aef4 'hrtimer: Prevent hrtimer_enqueue_reprogram race'
backported into 3.2.40]
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
--- a/include/linux/hrtimer.h
+++ b/include/linux/hrtimer.h
@@ -111,6 +111,8 @@ struct hrtimer {
enum hrtimer_restart(*function)(struct hrtimer *);
struct hrtimer_clock_base *base;
unsigned long state;
+ struct list_headcb_entry;
+ int irqsafe;
#ifdef CONFIG_TIMER_STATS
int start_pid;
void*start_site;
@@ -147,6 +149,7 @@ struct hrtimer_clock_base {
int index;
clockid_t clockid;
struct timerqueue_head active;
+ struct list_headexpired;
ktime_t resolution;
ktime_t (*get_time)(void);
ktime_t softirq_time;
--- a/kernel/hrtimer.c
+++ b/kernel/hrtimer.c
@@ -589,8 +589,7 @@ static int hrtimer_reprogram(struct hrti
* When the callback is running, we do not reprogram the clock event
* device. The timer callback is either running on a different CPU or
* the callback is executed in the hrtimer_interrupt context. The
-* reprogramming is handled either by the softirq, which called the
-* callback or at the end of the hrtimer_interrupt.
+* reprogramming is handled at the end of the hrtimer_interrupt.
*/
if (hrtimer_callback_running(timer))
return 0;
@@ -625,6 +624,9 @@ static int hrtimer_reprogram(struct hrti
return res;
}
+static void __run_hrtimer(struct hrtimer *timer, ktime_t *now);
+static int hrtimer_rt_defer(struct hrtimer *timer);
+
/*
* Initialize the high resolution related parts of cpu_base
*/
@@ -730,6 +732,11 @@ static inline int hrtimer_enqueue_reprog
}
static inline void hrtimer_init_hres(struct hrtimer_cpu_base *base) { }
static inline void retrigger_next_event(void *arg) { }
+static inline int hrtimer_reprogram(struct hrtimer *timer,
+ struct hrtimer_clock_base *base)
+{
+ return 0;
+}
#endif /* CONFIG_HIGH_RES_TIMERS */
@@ -861,9 +868,9 @@ void hrtimer_wait_for_timer(const struct
{
struct hrtimer_clock_base *base = timer-base;
- if (base base-cpu_base !hrtimer_hres_active(base-cpu_base))
+ if (base base-cpu_base !timer-irqsafe)
wait_event(base-cpu_base-wait,
- !(timer-state HRTIMER_STATE_CALLBACK));
+ !(timer-state HRTIMER_STATE_CALLBACK));
}
#else
@@ -913,6 +920,11 @@ static void __remove_hrtimer(struct hrti
if (!(timer-state HRTIMER_STATE_ENQUEUED))
goto out;
+ if (unlikely(!list_empty(timer-cb_entry))) {
+ list_del_init(timer-cb_entry);
+ goto out;
+ }
+
next_timer = timerqueue_getnext(base-active);
timerqueue_del(base-active, timer-node);
if (timer-node == next_timer) {
@@ -1011,6 +1023,26 @@ int __hrtimer_start_range_ns(struct hrti
*/
if (leftmost new_base-cpu_base == __get_cpu_var(hrtimer_bases)
hrtimer_enqueue_reprogram(timer, new_base)) {
+#ifdef CONFIG_PREEMPT_RT_BASE
+ again:
+ /*
+* Move softirq based timers away from the rbtree in
+* case it expired already. Otherwise we would have a
+* stale base-first entry until the softirq runs.
+*/
+ if (!hrtimer_rt_defer(timer)) {
+ ktime_t now = ktime_get();
+
+ __run_hrtimer(timer, now);
+ /*
+* __run_hrtimer might have requeued timer and
+* it could be base-first again.
+*/
+ if (timer-node ==
Bug#703668: linux-image-3.2.0-4-amd64: kernel BUG at /build/buildd-linux_3.2.39-2-amd64-G5_nM0/linux-3.2.39/fs/inode.c:428
Package: linux-image-3.2.0-4-amd64 Version: 3.2.39-2 This is transcribed, and due to photographic ineptitude, I've lost everything after the RIP line: kernel BUG at /build/buildd-linux_3.2.39-2-amd64-G5_nM0/linux-3.2.39/fs/inode.c:428 invalid opcode: [#1] SMP CPU 2 Modules linked in: tun parport_pc ppdev lp parport bnep rfcomm bluetooth cpufreq_powersave cpufreq_conservative cpufreq_userspace cpufreq_stats xfrm_user xfrm4_tunnel tunnel4 ipcomp xfrm_ipcomp esp4 ah4 uinput deflate ctr twofish_generic twofish_x86_64_3way twofish_x86_64 twofish_common camellia serpent blowfish_generic blowfish_x86_64 blowfish_common cast5 des_generic cbc xcbc rmd160 sha512_generic sha1_ssse3 sha1_generic hmac crypto_null af_key fuse rpsec_gss_krb5 nfsd nfs nfs_acl auth_rpcgss fscache lockd sunrpc loop firewire_sbp2 kvm_intel kvm snd_hda_codec_hdmi snd_hda_codec_conexant joydev uvcvideo videodev v4l2_compat_ioctl32 media snd_hda_intel snd_hda_codec snd_hwdep arc4 snd_pcm_oss snd_mixer_oss iTCO_wdt snd_pcm iTCO_vendor_support snd_page_alloc thinkpad_acpi nvram rtl8192ce rtlwifi snd_seq_midi snd_seq_midi_event snd_rawmidi rtl8192c_common mac80211 cfg80211 snd_seq snd_seq_device snd_times snd acpi_cpufreq mperf processor battery tpm_tis tpm tpm_bios i2c_i801 coretemp ac power_supply rfkill soundcore psmouse serio_raw pcspkr evdev ext4 crc16 jbd2 mbcache btrfs libcrc32c zlib_deflate sha256_generic dm_crypt dm_mod sr_mod sg cdrom sd_mod crc_t10dif usb_storage crc32c_intel ghash_clmulni_intel ahci aesni_intel libahci thermal i915 libata firewire_ohci aes_x86_64 e1000e aes_generic cryptd ehci_hcd wmi firewire_core crc_itu_t video scsi_mod sdhci_pci sdhci mmc_core usbore button i2c_algo_bit drm_kms_helper drm usb_common i2c_core thermal_sys [last unloaded: scsi_wait_scan] Pid: 4055 comm: xmobar Not tainted 3.2.0-4-amd64 #1 Debian 3.2.39-2 LENOVO 4239CTO/4239CTO RIP: 0010:[8110c4ea] [8110c4ea] end_writeback+0x1f/0x77 RSP: 0018:8801153e5e68 EFLAGS: 00010086 RAX: RBX: 88000785baa8 RCX: RDX: RSI: 88000785bc00 RDI: 88000785bc00 RBP: 88000785bba0 R08: 000e R09: R10: 88008ce4ad80 R11: 88008ce4ad80 R12: 814152d0 R13: 0001 R14: 8800239cb3c0 R15: 88008ce4ad90 FS: 7fc38f50a700() GS:88011e28() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7fe13d5ea0bc CR3: 0001150f CR4: 000406e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process xmobar (pid: 4055, threadinfo 8801153e4000, task 88011531f120) Stack: 88000785baa8 8113ec5c 88000785baa8 8110c5d8 8800239cb3c0 880119802980 88000785baa8 811099d6 88000785baa8 8800239cb3c0 8800239cb41c 88000785baa8 Call Trace: [8113ec5c] ? proc_evict_inode+0x1a/0x62 [8110c5d8] ? evict+0x96/0x148 [811099d6] ? dentry_kill+0x112/0x12e [81109c2d] ? dput+0xe2/0xee [810fab6e] ? fput+0x17a/0x1a1 [810f8819] ? filp_close+0x62/0x6a [810f88af] ? sys_close+0x8e/0xcb [81352952] ? system_call_fastpath+0x16/0x1b Code: 12 ba 10 81 e9 6a 08 24 00 31 c0 c3 53 48 89 fb e8 8c 01 24 00 48 8d bb 58 01 00 00 e8 b8 14 24 00 48 83 bb a0 01 00 00 00 74 02 0f 0b 66 ff 83 58 01 00 00 fb 66 66 90 66 66 90 48 8d 83 d0 01 RIP [8110c4ea] end_writeback+0x1f/0x77 ... -- 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/20130322011823.ga24...@scru.org
Re: PREEMPT_RT vs 'hrtimer: Prevent hrtimer_enqueue_reprogram race'
On Fri, 2013-03-22 at 01:11 +, Ben Hutchings wrote:
Commit b22affe0aef4 'hrtimer: Prevent hrtimer_enqueue_reprogram race'
conflicts with the RT patches
hrtimer-fixup-hrtimer-callback-changes-for-preempt-r.patch and
peter_zijlstra-frob-hrtimer.patch, as they all change
hrtimer_enqueue_reprogram(). It seems that the changes in the RT
patches now belong in __hrtimer_start_range_ns().
Since I haven't seen any RT releases in a while, here's what I came up
with for 3.2-rt:
Note, I posted a fix on Tuesday:
https://lkml.org/lkml/2013/3/19/369
I'm waiting for Thomas to give his OK on it before releasing the series.
He told me he'll have a look at it tomorrow. I've already ran the series
through all my tests, and will post it immediately after I get the OK.
Or if there's a issue I will have to fix it and rerun my tests.
---
From: Thomas Gleixner t...@linutronix.de
Date: Fri, 3 Jul 2009 08:44:31 -0500
Subject: hrtimer: fixup hrtimer callback changes for preempt-rt
In preempt-rt we can not call the callbacks which take sleeping locks
from the timer interrupt context.
Bring back the softirq split for now, until we fixed the signal
delivery problem for real.
Signed-off-by: Thomas Gleixner t...@linutronix.de
Signed-off-by: Ingo Molnar mi...@elte.hu
[bwh: Pull the changes to hrtimer_enqueue_reprogram() up into
__hrtimer_start_range_ns(), following changes in
commit b22affe0aef4 'hrtimer: Prevent hrtimer_enqueue_reprogram race'
backported into 3.2.40]
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
--- a/include/linux/hrtimer.h
+++ b/include/linux/hrtimer.h
@@ -111,6 +111,8 @@ struct hrtimer {
enum hrtimer_restart(*function)(struct hrtimer *);
struct hrtimer_clock_base *base;
unsigned long state;
+ struct list_headcb_entry;
+ int irqsafe;
#ifdef CONFIG_TIMER_STATS
int start_pid;
void*start_site;
@@ -147,6 +149,7 @@ struct hrtimer_clock_base {
int index;
clockid_t clockid;
struct timerqueue_head active;
+ struct list_headexpired;
ktime_t resolution;
ktime_t (*get_time)(void);
ktime_t softirq_time;
--- a/kernel/hrtimer.c
+++ b/kernel/hrtimer.c
@@ -589,8 +589,7 @@ static int hrtimer_reprogram(struct hrti
* When the callback is running, we do not reprogram the clock event
* device. The timer callback is either running on a different CPU or
* the callback is executed in the hrtimer_interrupt context. The
- * reprogramming is handled either by the softirq, which called the
- * callback or at the end of the hrtimer_interrupt.
+ * reprogramming is handled at the end of the hrtimer_interrupt.
*/
if (hrtimer_callback_running(timer))
return 0;
@@ -625,6 +624,9 @@ static int hrtimer_reprogram(struct hrti
return res;
}
+static void __run_hrtimer(struct hrtimer *timer, ktime_t *now);
+static int hrtimer_rt_defer(struct hrtimer *timer);
+
/*
* Initialize the high resolution related parts of cpu_base
*/
@@ -730,6 +732,11 @@ static inline int hrtimer_enqueue_reprog
}
static inline void hrtimer_init_hres(struct hrtimer_cpu_base *base) { }
static inline void retrigger_next_event(void *arg) { }
+static inline int hrtimer_reprogram(struct hrtimer *timer,
+ struct hrtimer_clock_base *base)
+{
+ return 0;
+}
#endif /* CONFIG_HIGH_RES_TIMERS */
@@ -861,9 +868,9 @@ void hrtimer_wait_for_timer(const struct
{
struct hrtimer_clock_base *base = timer-base;
- if (base base-cpu_base !hrtimer_hres_active(base-cpu_base))
+ if (base base-cpu_base !timer-irqsafe)
wait_event(base-cpu_base-wait,
- !(timer-state HRTIMER_STATE_CALLBACK));
+!(timer-state HRTIMER_STATE_CALLBACK));
}
#else
@@ -913,6 +920,11 @@ static void __remove_hrtimer(struct hrti
if (!(timer-state HRTIMER_STATE_ENQUEUED))
goto out;
+ if (unlikely(!list_empty(timer-cb_entry))) {
+ list_del_init(timer-cb_entry);
+ goto out;
+ }
+
next_timer = timerqueue_getnext(base-active);
timerqueue_del(base-active, timer-node);
if (timer-node == next_timer) {
@@ -1011,6 +1023,26 @@ int __hrtimer_start_range_ns(struct hrti
*/
if (leftmost new_base-cpu_base == __get_cpu_var(hrtimer_bases)
hrtimer_enqueue_reprogram(timer, new_base)) {
+#ifdef CONFIG_PREEMPT_RT_BASE
+ again:
What kernel are you working with? I don't see anywhere the again:
within a PREEMPT_RT_BASE block.
+ /*
+ * Move softirq based timers away from the rbtree in
+
Re: PREEMPT_RT vs 'hrtimer: Prevent hrtimer_enqueue_reprogram race'
On Thu, 2013-03-21 at 22:31 -0400, Steven Rostedt wrote:
On Fri, 2013-03-22 at 01:11 +, Ben Hutchings wrote:
Commit b22affe0aef4 'hrtimer: Prevent hrtimer_enqueue_reprogram race'
conflicts with the RT patches
hrtimer-fixup-hrtimer-callback-changes-for-preempt-r.patch and
peter_zijlstra-frob-hrtimer.patch, as they all change
hrtimer_enqueue_reprogram(). It seems that the changes in the RT
patches now belong in __hrtimer_start_range_ns().
Since I haven't seen any RT releases in a while, here's what I came up
with for 3.2-rt:
Note, I posted a fix on Tuesday:
https://lkml.org/lkml/2013/3/19/369
Thanks. I did search GMANE with some obvious terms but I think its
index is lagging.
I'm waiting for Thomas to give his OK on it before releasing the series.
He told me he'll have a look at it tomorrow. I've already ran the series
through all my tests, and will post it immediately after I get the OK.
Or if there's a issue I will have to fix it and rerun my tests.
---
From: Thomas Gleixner t...@linutronix.de
Date: Fri, 3 Jul 2009 08:44:31 -0500
Subject: hrtimer: fixup hrtimer callback changes for preempt-rt
[...]
@@ -1011,6 +1023,26 @@ int __hrtimer_start_range_ns(struct hrti
*/
if (leftmost new_base-cpu_base == __get_cpu_var(hrtimer_bases)
hrtimer_enqueue_reprogram(timer, new_base)) {
+#ifdef CONFIG_PREEMPT_RT_BASE
+ again:
What kernel are you working with? I don't see anywhere the again:
within a PREEMPT_RT_BASE block.
I'm rebasing the rt patch series generated with
'git format-patch v3.2.39..v3.2.39-rt59-rebase' on top of v3.2.41 (plus
Debian changes, which introduce some trivial textual conflicts).
So these patches were previously:
commit c495d005449523772e27a22fb74814dc3cebff8e
Author: Thomas Gleixner t...@linutronix.de
Date: Fri Jul 3 08:44:31 2009 -0500
hrtimer: fixup hrtimer callback changes for preempt-rt
commit 80cc960e628509c72f63a7327a4dc22707a02b81
Author: Peter Zijlstra a.p.zijls...@chello.nl
Date: Fri Aug 12 17:39:54 2011 +0200
hrtimer: Don't call the timer handler from hrtimer_start
[...]
This is very similar to what I came up with.
[...]
Yep, looks like we are on the right track :-)
[...]
Good to hear.
Ben.
--
Ben Hutchings
Make three consecutive correct guesses and you will be considered an expert.
signature.asc
Description: This is a digitally signed message part
Processed: reassign 703668 to src:linux, found 703668 in linux/3.2.39-2
Processing commands for cont...@bugs.debian.org: reassign 703668 src:linux 3.2.39-2 Bug #703668 [linux-image-3.2.0-4-amd64] linux-image-3.2.0-4-amd64: kernel BUG at /build/buildd-linux_3.2.39-2-amd64-G5_nM0/linux-3.2.39/fs/inode.c:428 Bug reassigned from package 'linux-image-3.2.0-4-amd64' to 'src:linux'. No longer marked as found in versions linux/3.2.39-2. Ignoring request to alter fixed versions of bug #703668 to the same values previously set Bug #703668 [src:linux] linux-image-3.2.0-4-amd64: kernel BUG at /build/buildd-linux_3.2.39-2-amd64-G5_nM0/linux-3.2.39/fs/inode.c:428 Marked as found in versions linux/3.2.39-2. found 703668 linux/3.2.39-2 Bug #703668 [src:linux] linux-image-3.2.0-4-amd64: kernel BUG at /build/buildd-linux_3.2.39-2-amd64-G5_nM0/linux-3.2.39/fs/inode.c:428 Ignoring request to alter found versions of bug #703668 to the same values previously set thanks Stopping processing here. Please contact me if you need assistance. -- 703668: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703668 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.13639235586399.transcr...@bugs.debian.org
Re: PREEMPT_RT vs 'hrtimer: Prevent hrtimer_enqueue_reprogram race'
On Fri, 2013-03-22 at 03:24 +, Ben Hutchings wrote: Note, I posted a fix on Tuesday: https://lkml.org/lkml/2013/3/19/369 Thanks. I did search GMANE with some obvious terms but I think its index is lagging. It didn't help that my subject had no mention of -rt in it :-( I'm rebasing the rt patch series generated with 'git format-patch v3.2.39..v3.2.39-rt59-rebase' on top of v3.2.41 (plus Debian changes, which introduce some trivial textual conflicts). Ah, OK, I do it the opposite way. As the stable rt git never rebases, I always merge the latest stable into my tree. I then create a rebased tree as well. When I do that, I'm sure I'll end up fixing the patches up pretty much the same as you have. Thanks, -- Steve -- 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/1363923275.6345.93.ca...@gandalf.local.home
Re: [RFC] Putting the date back into utsname::version
Ben Hutchings b...@decadent.org.uk writes: We have a longstanding support problem where there is confusion between the kernel release string (utsname::release, output of uname -r, tail of package names) and the kernel package version. Agreed. Would anyone like to argue in favour of any particular alternative? I don't really care about the format of uname -v but I'd really like to have a stable way to get just the version number part. Now I have: case $DISTRO in Debian) # 2.6.32-39 if uname -v | grep -q Debian; then VERSION=$(uname -v | cut -d -f 4) else VERSION=$(cut -d -f 5 /proc/version | cut -d ) -f 1) fi ;; Ubuntu) # 2.6.32-37.81 VERSION=$(cut -d -f 2 /proc/version_signature | cut -d - -f 1-2) ;; esac -- 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/84620k7zji@sauna.l.org
