Bug#864777: initramfs-tools: Please support a tmpfs boot mode
Hi Benjamin, On Wed, Jun 14, 2017 at 05:47:54PM +0200, Benjamin Drung wrote: > Package: initramfs-tools > Version: 0.130 > Severity: normal > Tags: patch > > Hi, > > The tmpfs boot mode allows one to operate a disk-less live system by > downloading a root tarball (that can be created with debootstrap) and > extracting it to a tmpfs root partition. > > The tmpfs boot mode is similar to the nfs boot mode, but it does not > rely on any external service (after booting). We use this boot mode for > our compute nodes. I have attached a patch to support this boot mode and > tested it with qemu and on real hardware. Please take a look at the package live-boot (and the man page of the same name in live-boot-doc). Specifically, the parameter fetch=URL should satisfy your requirements and consume less resources. live-boot creates an overlay filesystem backed by a squashfs image, which means it likely uses much less RAM than copying root to tmpfs. (For my system, squashfs reduces the required memory to a third.) Regards, Peter
Bug#845500: nftables: notrack target fails with No such file or directory
On Thu, Nov 24, 2016 at 06:58:46PM +, Ben Hutchings wrote: > > IIRC Ben said that the next upstream kernel being tagged as LTS will be > > the one included in Debian strech, so we’ll probably have 4.9… unless > > Greg KH changes his mind again. :D > > Yes, exactly. Thanks for clarifying. There are worse things than 3 more years of iptables–ip6tables duality ;-). Peter
Bug#845500: nftables: notrack target fails with No such file or directory
On Thu, Nov 24, 2016 at 01:55:01AM +0100, Jens Reyer wrote: > According to > https://lists.debian.org/debian-devel-announce/2016/03/msg0.html it > will be 4.10. That would be great. After the recent announcement that 4.9 will probably be the next LTS kernel I assumed that the same version would also be shipped with stretch. http://kroah.com/log/blog/2016/09/06/4-dot-9-equals-equals-next-lts-kernel/ Peter
Bug#845500: nftables: notrack target fails with No such file or directory
On Wed, Nov 23, 2016 at 07:34:42PM -0500, Peter Colberg wrote: > Assuming 4.9 becomes the stretch kernel, could you backport the patch? The same applies to kernel support for the "fib" expression that may be used for reverse path filtering (analogous to iptables rp_filter). https://git.kernel.org/cgit/linux/kernel/git/pablo/nf-next.git/commit?id=f6d0cbcf09c506b9b022df8f9d7693a7cec3c732 That patch is more extensive and there are many more commits needed to sync nftables kernel support with userspace. Backporting does not make much sense. I am crossing fingers for 4.10 making it into stretch. Peter
Bug#818951: linux: [armv7] kernel panic on power down of Cubieboard (A20)
Hi Uwe, On Mon, May 02, 2016 at 09:22:50AM +0200, Uwe Kleine-König wrote: > In the good case the message > > i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0 > > isn't there, right? Correct, the message is printed only in the bad case. Note how the message along with the panic occurs after a pause of two seconds. Regards, Peter
Bug#818951: linux: [armv7] kernel panic on power down of Cubieboard (A20)
Dear Debian ARM porters, Are any of you running an armv7 board similar to the Cubieboard or Cubietruck by chance, who happen to see a kernel panic on poweroff using Debian testing/unstable with Linux kernel 4.2 up to 4.5? https://bugs.debian.org/818951 Regards, Peter
Bug#818951: linux: [armv7] kernel panic on power down of Cubieboard (A20)
Source: linux Version: 4.4.6-1 Severity: normal Tags: upstream Dear Maintainer, After upgrading from jessie to stretch, my Cubieboard (Allwinner A20) no longer powers down; instead, the machine halts with a kernel panic while continuing to be powered. I captured the following output on the serial console: # poweroff [ 654.415345] systemd-shutdown[1]: Sending SIGTERM to remaining processes... [ 654.457107] systemd-journald[272]: Received SIGTERM from PID 1 (systemd-shutdow). [ 654.576175] systemd-shutdown[1]: Sending SIGKILL to remaining processes... [ 654.614229] systemd-shutdown[1]: Unmounting file systems. [ 654.624854] systemd-shutdown[1]: Remounting '/' read-only with options 'ssd,discard,space_cache,subvolid=5,subvol=/'. [ 654.900813] BTRFS info (device dm-0): disk space caching is enabled [ 655.043127] systemd-shutdown[1]: Remounting '/' read-only with options 'ssd,discard,space_cache,subvolid=5,subvol=/'. [ 655.058439] BTRFS info (device dm-0): disk space caching is enabled [ 655.069255] systemd-shutdown[1]: All filesystems unmounted. [ 655.079341] systemd-shutdown[1]: Deactivating swaps. [ 655.089177] systemd-shutdown[1]: All swaps deactivated. [ 655.099060] systemd-shutdown[1]: Detaching loop devices. [ 655.109904] systemd-shutdown[1]: All loop devices detached. [ 655.120212] systemd-shutdown[1]: Detaching DM devices. [ 655.131915] systemd-shutdown[1]: Detaching DM 254:0. [ 655.141723] systemd-shutdown[1]: Could not detach DM /dev/dm-0: Device or resource busy [ 655.154470] systemd-shutdown[1]: Not all DM devices detached, 1 left. [ 655.165667] systemd-shutdown[1]: Cannot finalize remaining DM devices, continuing. [ 655.180404] systemd-shutdown[1]: Failed to finalize DM devices, ignoring [ 655.192305] systemd-shutdown[1]: Powering off. [ 655.201618] kvm: exiting hardware virtualization [ 655.211292] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 655.221730] sd 0:0:0:0: [sda] Stopping disk [ 655.323690] reboot: Power down [ 657.329374] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0 [ 657.342678] Kernel panic - not syncing: Attempted to kill init! exitcode=0x [ 657.342678] [ 657.361647] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 4.4.0-1-armmp-lpae #1 Debian 4.4.6-1 [ 657.375569] Hardware name: Allwinner sun7i (A20) Family [ 657.385995] [] (unwind_backtrace) from [] (show_stack+0x20/0x24) [ 657.399051] [] (show_stack) from [] (dump_stack+0xa0/0xb4) [ 657.411627] [] (dump_stack) from [] (panic+0xc0/0x258) [ 657.423871] [] (panic) from [] (do_exit+0xa54/0xa78) [ 657.435964] [] (do_exit) from [] (SyS_reboot+0x1c8/0x238) [ 657.448589] [] (SyS_reboot) from [] (ret_fast_syscall+0x0/0x34) [ 657.461841] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x [ 657.461841] In order to pinpoint the kernel version that introduced the regression, I tested the following kernels from snapshot.d.o: linux-image-4.0.0-2-armmp-lpae 4.0.8-2 OK linux-image-4.1.0-2-armmp-lpae 4.1.6-1 OK linux-image-4.2.0-1-armmp-lpae 4.2.6-3 PANIC linux-image-4.3.0-1-armmp-lpae 4.3.5-1 PANIC linux-image-4.4.0-1-armmp-lpae 4.4.6-1 PANIC The regression has been introduced in Linux 4.2. I compared the serial console output of Linux 4.2/4.3/4.4, and, apart from the address offsets, the stack traces of the kernel panic are identical. Please let me know how I can help with further debugging. Regards, Peter
Bug#811566: run-init: opening console: No such file or directory
Package: initramfs-tools Version: 0.121 Severity: important Dear Maintainer, Since upgrading initramfs-tools, the system no longer boots. Instead the initramfs rescue shell is started: Loading Linux 4.3.0-1-amd64 ... Loading initial ramdisk ... Loading, please wait... Scanning for Btrfs filesystems run-init: opening console: No such file or directory Target filesystem doesn't have requested /sbin/init. run-init: opening console: No such file or directory run-init: opening console: No such file or directory run-init: opening console: No such file or directory run-init: opening console: No such file or directory run-init: : No such file or directory No init found. Try passing init= bootarg. modprobe: module ehci-orion not found in modules.dep BusyBox v1.22.1 (Debian 1:1.22.0-16) built-in shell (ash) Enter 'help' for a list of built-in commands. /bin/sh: can't access tty; job control turned off (initramfs) The system is installed on a single btrfs filesystem. Regards, Peter -- Package-specific info: -- initramfs sizes -- /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-4.3.0-1-amd64 root=UUID=bdb66c4b-0279-47b3-8c08-0ab0d0b2accc ro console=ttyS0,115200n8 quiet -- resume RESUME=UUID=46ee0f17-5ab6-4722-a108-9145cb6f1020 -- /proc/filesystems btrfs -- lsmod Module Size Used by binfmt_misc20480 1 iptable_raw16384 1 ipt_REJECT 16384 2 nf_reject_ipv4 16384 1 ipt_REJECT nf_conntrack_ipv4 20480 2 nf_defrag_ipv4 16384 1 nf_conntrack_ipv4 iptable_filter 16384 1 ip_tables 28672 2 iptable_filter,iptable_raw xt_tcpudp 16384 9 xt_multiport 16384 8 xt_CT 16384 16 ip6table_raw 16384 1 ip6t_REJECT16384 2 nf_reject_ipv6 16384 1 ip6t_REJECT nf_conntrack_ipv6 20480 2 nf_defrag_ipv6 36864 1 nf_conntrack_ipv6 xt_conntrack 16384 4 nf_conntrack 118784 4 xt_CT,xt_conntrack,nf_conntrack_ipv4,nf_conntrack_ipv6 ip6table_filter16384 1 ip6_tables 28672 2 ip6table_filter,ip6table_raw x_tables 36864 12 ip6table_filter,xt_CT,ip_tables,xt_tcpudp,xt_conntrack,xt_multiport,iptable_filter,ip6table_raw,ipt_REJECT,ip6_tables,iptable_raw,ip6t_REJECT iosf_mbi 16384 0 crct10dif_pclmul 16384 0 crc32_pclmul 16384 0 jitterentropy_rng 16384 0 sha256_ssse3 28672 1 sha256_generic 24576 1 sha256_ssse3 hmac 16384 1 drbg 24576 1 ansi_cprng 16384 0 aesni_intel 167936 0 aes_x86_64 20480 1 aesni_intel lrw16384 1 aesni_intel i2c_piix4 24576 0 gf128mul 16384 1 lrw ppdev 20480 0 acpi_cpufreq 20480 0 pvpanic16384 0 evdev 20480 1 glue_helper16384 1 aesni_intel psmouse 126976 0 8250_fintek16384 0 serio_raw 16384 0 ablk_helper16384 1 aesni_intel pcspkr 16384 0 processor 36864 1 acpi_cpufreq button 16384 0 cryptd 20480 2 aesni_intel,ablk_helper parport_pc 28672 0 parport49152 2 ppdev,parport_pc tun28672 2 autofs440960 2 btrfs 954368 1 xor24576 1 btrfs raid6_pq 102400 1 btrfs ata_generic16384 0 virtio_net 28672 0 virtio_blk 20480 2 ata_piix 36864 0 crc32c_intel 24576 1 libata233472 2 ata_generic,ata_piix virtio_pci 24576 0 virtio_ring20480 3 virtio_blk,virtio_net,virtio_pci virtio 16384 3 virtio_blk,virtio_net,virtio_pci scsi_mod 229376 1 libata floppy 69632 0 -- /etc/initramfs-tools/modules -- /etc/kernel-img.conf # Kernel image management overrides # See kernel-img.conf(5) for details do_symlinks = no do_bootloader = no do_initrd = yes link_in_boot = no -- /etc/initramfs-tools/initramfs.conf MODULES=most BUSYBOX=auto KEYMAP=n COMPRESS=gzip DEVICE= NFSROOT=auto -- /etc/initramfs-tools/update-initramfs.conf update_initramfs=yes backup_initramfs=no -- mkinitramfs hooks /etc/initramfs-tools/hooks/: /usr/share/initramfs-tools/hooks: btrfs busybox dmsetup fsck fuse keymap klibc kmod resume thermal udev zz-busybox -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages initramfs-tools depends on: ii initramfs-tools-core 0.121 ii li
Bug#658662: drm/i915: no signal via DisplayPort on Sandy Bridge since Linux 3.2
Hi,
On Wed, Jul 04, 2012 at 10:39:49AM -0500, Jonathan Nieder wrote:
> Hi again,
>
> Peter Colberg wrote:
>
> > cd9dde44f47501394b9f0715b6a36a92aa74c0d0 is the first bad commit
>
> How about the attached patch --- does it work against the linux-3.2.y
> branch?
>
> Grateful,
> Jonathan
> From: Jesse Barnes
> Date: Thu, 21 Jun 2012 15:13:50 -0700
> Subject: drm/i915: prefer wide & slow to fast & narrow in DP configs
>
> commit 684aaa646f90f5ee07799d52d0735625756e607b upstream.
>
> High frequency link configurations have the potential to cause trouble
> with long and/or cheap cables, so prefer slow and wide configurations
> instead. This patch has the potential to cause trouble for eDP
> configurations that lie about available lanes, so if we run into that we
> can make it conditional on eDP.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45801
> Tested-by: pe...@colberg.org
> Signed-off-by: Jesse Barnes
> Signed-off-by: Daniel Vetter
> Signed-off-by: Jonathan Nieder
> ---
> drivers/gpu/drm/i915/intel_dp.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index d4c4937067fb..fae2050324bc 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -708,8 +708,8 @@ intel_dp_mode_fixup(struct drm_encoder *encoder, struct
> drm_display_mode *mode,
>
> bpp = adjusted_mode->private_flags & INTEL_MODE_DP_FORCE_6BPC ? 18 : 24;
>
> - for (lane_count = 1; lane_count <= max_lane_count; lane_count <<= 1) {
> - for (clock = 0; clock <= max_clock; clock++) {
> + for (clock = 0; clock <= max_clock; clock++) {
> + for (lane_count = 1; lane_count <= max_lane_count; lane_count
> <<= 1) {
> int link_avail =
> intel_dp_max_data_rate(intel_dp_link_clock(bws[clock]), lane_count);
>
> if (intel_dp_link_required(mode->clock, bpp)
> --
> 1.7.11.rc3
I tested upstream linux 3.2.23 with the above patch applied, and
the display is working fine, i.e. it comes up in maximum, native
resolution even after power-cycling the display.
Regards,
Peter
--
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/20120717221021.GA4476@alcyone
Bug#658662: drm/i915: no signal via DisplayPort on Sandy Bridge since Linux 3.2
On Wed, Apr 18, 2012 at 01:37:23PM -0500, Jonathan Nieder wrote: > tags 658662 + patch fixed-upstream > quit > > Hi, > > Peter Colberg wrote: > > > Since upgrading to linux-image-3.2.0-1-amd64, an external display > > connected via DisplayPort to a Sandy Bridge onboard graphics card > > stopped working, and instead turns off reporting âDP no signalâ. > > > > With linux-image-3.1.0-1-amd64, the same display connected via the > > DisplayPort works fine. > > Thanks again. This is said to be fixed by the patch "drm/i915: > properly compute dp dithering for user-created modes" (2012-04-10) > which has been queued for 3.2.16. No luck, that patch does *not* fix this problem :-(. https://bugs.freedesktop.org/show_bug.cgi?id=45801#c16 Peter -- 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/20120419042029.GA3939@alcyone
Bug#658662: drm/i915: no signal via DisplayPort on Sandy Bridge since Linux 3.2
On Wed, Feb 08, 2012 at 04:42:01PM -0600, Jonathan Nieder wrote: > tags 658662 + upstream patch moreinfo > quit > > Peter Colberg wrote: > > > cd9dde44f47501394b9f0715b6a36a92aa74c0d0 is the first bad commit > > Yay, thanks much for this. :) > > Please test the attached patch against the linux-3.2.y branch. > > git remote add -f stable \ >git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git > git checkout stable/linux-3.2.y > > git am -3sc thepatch > make silentoldconfig; # reuse configuration > make deb-pkg; # optionally with -j > dpkg -i ../ > reboot > From: Keith Packard > Date: Wed, 25 Jan 2012 08:16:25 -0800 > Subject: drm/i915: Force explicit bpp selection for intel_dp_link_required > > commit c898261c0dad617f0f1080bedc02d507a2fcfb92 upstream. > Thanks, but I just tested this patch (again). It is included in drm-intel-fixes, and it does not fix the regression: https://bugs.freedesktop.org/show_bug.cgi?id=45801#c5 Given that the problem persists, at least my bisect was not in vain ;-). Peter -- 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/20120208225821.GA4814@alcyone
Bug#658662: drm/i915: no signal via DisplayPort on Sandy Bridge since Linux 3.2
On Sat, Feb 04, 2012 at 06:31:13PM -0500, Peter Colberg wrote: > Since upgrading to linux-image-3.2.0-1-amd64, an external display > connected via DisplayPort to a Sandy Bridge onboard graphics card > stopped working, and instead turns off reporting “DP no signal”. Ok, I have finished the bisect, compiling and testing 17 kernels. It seems the math in the i915 DisplayPort code got worse… ;-) Peter cd9dde44f47501394b9f0715b6a36a92aa74c0d0 is the first bad commit commit cd9dde44f47501394b9f0715b6a36a92aa74c0d0 Author: Adam Jackson Date: Fri Oct 14 12:43:49 2011 -0400 drm/i915/dp: Fix the math in intel_dp_link_required The previous code was confused about units, which is pretty reasonable given that the units themselves are confusing. Signed-off-by: Adam Jackson Signed-off-by: Keith Packard :04 04 3c0a0f38fc6482a401340e03fa3fbd687d11eda4 294673b782b3ecc93540f46f7721d385bd30cfac M drivers # git bisect log # bad: [805a6af8dba5dfdd35ec35dc52ec0122400b2610] Linux 3.2 # good: [c3b92c8787367a8bb53d57d9789b558f1295cc96] Linux 3.1 git bisect start 'v3.2' 'v3.1' # bad: [68d99b2c8efcb6ed3807a55569300c53b5f88be5] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound git bisect bad 68d99b2c8efcb6ed3807a55569300c53b5f88be5 # good: [efb8d21b2c6db3497655cc6a033ae8a9883e4063] Merge branch 'tty-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty git bisect good efb8d21b2c6db3497655cc6a033ae8a9883e4063 # good: [8686a0e200419322654a75155e2e6f80346a1297] Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip git bisect good 8686a0e200419322654a75155e2e6f80346a1297 # bad: [f362f98e7c445643d27c610bb7a86b79727b592e] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/hch/vfs-queue git bisect bad f362f98e7c445643d27c610bb7a86b79727b592e # good: [ca836a25435ef1b9914840ed0a310c9b6ac261d1] Merge branch 'x86-vdso-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip git bisect good ca836a25435ef1b9914840ed0a310c9b6ac261d1 # good: [c5c42360bc1cb14c7da3186683e9525b33b72656] vmwgfx: Don't pass unused arguments to do_dirty functions git bisect good c5c42360bc1cb14c7da3186683e9525b33b72656 # bad: [5619a693965b291315685bdfe01a0246ebd7e41e] Merge branch 'for-linus' of git://oss.sgi.com/xfs/xfs git bisect bad 5619a693965b291315685bdfe01a0246ebd7e41e # bad: [82d165557ef094d4b4dfc05871aee618ec7102b0] drm/i915/dp: Fix eDP on PCH DP on CPT/PPT git bisect bad 82d165557ef094d4b4dfc05871aee618ec7102b0 # good: [a9e2641dee52cae2db7688a749344365642a5e79] drm/i915: close PM interrupt masking races in the rps work func git bisect good a9e2641dee52cae2db7688a749344365642a5e79 # good: [75770564c90c45618003267f4cdde4bbc090f1bd] drm/i915: use transcoder select bits on VGA and HDMI on CPT git bisect good 75770564c90c45618003267f4cdde4bbc090f1bd # good: [a487928908226df493a3ce145ecf4bb39296714e] drm/i915: remove transcoder PLL mashing from mode_set per specs git bisect good a487928908226df493a3ce145ecf4bb39296714e # bad: [a2006cf5a7ad3463e7c1e9da2c4bc90499427558] drm/i915: read full receiver capability field during DP hot plug git bisect bad a2006cf5a7ad3463e7c1e9da2c4bc90499427558 # good: [f52c619a590fa75276c07dfcaf380dee53e4ea4c] drm/i915/panel: Always record the backlight level again (but cleverly) git bisect good f52c619a590fa75276c07dfcaf380dee53e4ea4c # bad: [dc22ee6fc18ce0f15424e753e8473c306ece95c1] drm/i915/dp: Remove eDP special cases from bandwidth checks git bisect bad dc22ee6fc18ce0f15424e753e8473c306ece95c1 # bad: [cd9dde44f47501394b9f0715b6a36a92aa74c0d0] drm/i915/dp: Fix the math in intel_dp_link_required git bisect bad cd9dde44f47501394b9f0715b6a36a92aa74c0d0 -- 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/20120208185414.GA3816@alcyone
Bug#658662: drm/i915: no signal via DisplayPort on Sandy Bridge since Linux 3.2
Hi Jonathan, On Mon, Feb 06, 2012 at 01:15:44AM -0600, Jonathan Nieder wrote: > Please report this upstream, following instructions from [1], and let > us know the bug number so we can track it. > > The upstream developers may ask you to bisect to find the specific > patch that introduced the problem. It works like this: > … Thanks for the detailed walk-through. So far I tested vanilla Linux v3.2 as bad, v3.1 as good, and started the bisect (with the first half-way commit tested as bad). That means “roughly 12 steps” to go. I will report back when the upstream bug report is filed. Regards, Peter -- 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/20120207033230.GA3846@alcyone
Bug#658662: drm/i915: no signal via DisplayPort on Sandy Bridge since Linux 3.2
found 658662 3.2.4-1 thanks Since the changelog of Linux 3.2.3 contains drm/i915-related fixes, I tested the newest Debian kernel: No change, the external display remains dark. Peter -- 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/20120206021121.GA3606@alcyone
Bug#658662: drm/i915: no signal via DisplayPort on Sandy Bridge since Linux 3.2
On Sun, Feb 05, 2012 at 02:44:53AM -0600, Jonathan Nieder wrote: > Hi Peter, > > Peter Colberg wrote: > > > Package: linux-2.6 > > Version: 3.2.2-1 > > Severity: important > > Tags: upstream > > Which upstream version did you test? Sorry, I must have misinterpreted the upstream tag. I tested the Debian package only, i.e. linux-image-3.2.0-1-amd64=3.2.2-1. Peter -- 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/20120205163503.GA9675@alcyone
Bug#658662: drm/i915: no signal via DisplayPort on Sandy Bridge since Linux 3.2
Package: linux-2.6 Version: 3.2.2-1 Severity: important Tags: upstream Dear Maintainer, Since upgrading to linux-image-3.2.0-1-amd64, an external display connected via DisplayPort to a Sandy Bridge onboard graphics card stopped working, and instead turns off reporting “DP no signal”. With linux-image-3.1.0-1-amd64, the same display connected via the DisplayPort works fine. After powering both the display and the machine, the display first turns on when the i915 kernel module is loaded upon boot. It shows the console with boot messages at the maximum display resolution (1920x1080). Then the X server starts, and the external display switches to a lower resolution (1024x768), which seems to be the default setting of the X server. After login, I manually switch to the maximum resolution (1920x1080) using the command “xrandr --output DP1 --auto”. With linux-image-3.2.0-1-amd64, after powering both the display and the machine, the display remains dark during boot, even when the i915 kernel module is loaded. The display first turns on only when the X server is loaded, with the default resolution 1024x768. After login, I manually switch to 1920x1080, but then the display reports “DP no signal” and turns *off*. To summarize: The external display connected via DisplayPort works fine with Linux 3.1, while, with Linux 3.2, it works with lower (non-native) resolutions and fails with the maximum (native) resolution. I noticed one peculiarity: It is possible to have a working external display by booting into Linux 3.1 first, and then rebooting into Linux 3.2 *without interrupting the power supply of the display*. However, as soon as I power-cycle the display while under Linux 3.2, it stops working again. There is a recent thread by Keith Packard with DisplayPort-related patches: https://lkml.org/lkml/2012/1/25/204 I tested both a kernel with only patch 1/2, as well as a kernel with both patches 1/2 and 2/2 applied, based on the Debian kernel source and using the test-patches script. Both kernels showed the same faulty behaviour, i.e. the external display remains dark at the native resolution. If there are other potential fixes I could test, please let me know. Thanks, Peter -- xrandr: Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192 LVDS1 connected 1366x768+0+0 (normal left inverted right x axis y axis) 277mm x 156mm 1366x768 60.0*+ 1360x768 59.8 60.0 1024x768 60.0 800x60060.3 56.2 640x48059.9 VGA1 disconnected (normal left inverted right x axis y axis) HDMI1 disconnected (normal left inverted right x axis y axis) DP1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 477mm x 268mm 1920x1080 60.0*+ 1680x1050 60.0 1600x900 60.0 1280x1024 60.0 1280x800 59.8 1280x720 60.0 1024x768 60.0 800x60060.3 640x48060.0 HDMI2 disconnected (normal left inverted right x axis y axis) HDMI3 disconnected (normal left inverted right x axis y axis) DP2 disconnected (normal left inverted right x axis y axis) DP3 disconnected (normal left inverted right x axis y axis) -- Package-specific info: ** Version: Linux version 3.2.0-1-amd64 (Debian 3.2.2-1) (b...@decadent.org.uk) (gcc version 4.6.2 (Debian 4.6.2-12) ) #1 SMP Wed Feb 1 08:56:58 UTC 2012 ** Command line: BOOT_IMAGE=/vmlinuz-3.2.0-1-amd64 root=/dev/mapper/vg-root ro pcie_aspm=force i915.i915_enable_rc6=1 i915.i915_enable_fbc=1 i915.lvds_downclock=1 ** Not tainted ** Kernel log: [ 20.446802] [drm] Initialized drm 1.1.0 20060810 [ 20.910637] IBM TrackPoint firmware: 0x0e, buttons: 3/3 [ 20.928577] input: TPPS/2 IBM TrackPoint as /devices/platform/i8042/serio1/input/input4 [ 20.948229] input: HDA Digital PCBeep as /devices/pci:00/:00:1b.0/input/input5 [ 20.953169] HDMI status: Codec=3 Pin=5 Presence_Detect=0 ELD_Valid=0 [ 20.953416] HDMI status: Codec=3 Pin=6 Presence_Detect=0 ELD_Valid=0 [ 20.953667] HDMI status: Codec=3 Pin=7 Presence_Detect=0 ELD_Valid=0 [ 20.953878] input: HDA Intel PCH HDMI/DP,pcm=8 as /devices/pci:00/:00:1b.0/sound/card0/input6 [ 20.954053] input: HDA Intel PCH HDMI/DP,pcm=7 as /devices/pci:00/:00:1b.0/sound/card0/input7 [ 20.954225] input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci:00/:00:1b.0/sound/card0/input8 [ 20.955314] i915 :00:02.0: power state changed by ACPI to D0 [ 20.955380] i915 :00:02.0: power state changed by ACPI to D0 [ 20.955446] i915 :00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 20.955510] i915 :00:02.0: setting latency timer to 64 [ 20.983994] mtrr: no more MTRRs available [ 20.984054] [drm] MTRR allocation failed. Graphics performance may suffer. [ 20.984497] i915 :00:02.0: irq 51 for MSI/MSI-X [ 20.984501] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 20.984562] [drm] Driver supports precise vblank timestamp q
Bug#651015: linux-image-3.1.0-1-amd64: Turtle Beach USB Audio fails with Sandy Bridge USB 2.0 controller
On Mon, Dec 05, 2011 at 01:36:22AM +, Ben Hutchings wrote: > > Could this patch be applied to the Debian kernel? > > > > The comment hinting the patch [4] suggests it has not been merged for 3.2. > [...] > > It has been included in 3.2-rc3 as: > > commit 811c926c538f7e8d3c08b630dd5844efd7e000f6 > Author: Thomas Poussevin > Date: Thu Oct 27 18:46:48 2011 +0200 > > USB: EHCI: fix HUB TT scheduling issue with iso transfer > > This seems to require a further fix which is in Linus's tree but not yet > released: > > commit e3420901eba65b1c46bed86d360e3a8685d20734 > Author: Matthieu CASTET > Date: Mon Nov 28 11:30:22 2011 +0100 > > EHCI : Fix a regression in the ISO scheduler > > I'll apply both of these. Very nice, thanks. Peter -- 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/20111205014311.GA8769@alcyone
Bug#651015: linux-image-3.1.0-1-amd64: Turtle Beach USB Audio fails with Sandy Bridge USB 2.0 controller
Package: linux-2.6 Version: 3.1.4-1 Severity: normal Tags: upstream patch Dear Maintainer, After upgrading to newer hardware as detailed below (PCI devices), my Turtle Beach USB Audio card stopped working with Twinkle, a VoIP SIP client. Upon starting Twinkle, it fails to detect the speaker and microphone devices with the following error messages: Sun 19:36:53 Critical: Opening ALSA driver failed: snd_pcm_start failed: Broken pipe Sun 19:36:53 Critical: Opening ALSA driver failed: snd_pcm_start failed: Broken pipe Twinkle 1.4.2, 25 February 2009 This coincides with the following kernel messages: [44368.330704] cannot submit datapipe for urb 0, error -28: not enough bandwidth [44368.387786] cannot submit datapipe for urb 0, error -28: not enough bandwidth The same kernel message has been reported [1] to occur with a different USB audio card, and a patch has been proposed [2]. [1] https://bugzilla.redhat.com/show_bug.cgi?id=527813 [2] http://marc.info/?l=linux-usb&m=131973404328622 Using the test-patches script described in the Debian Linux Kernel Handbook, I compiled a custom Debian kernel with the patch [2] applied, and indeed this resolves the issue. With this fix, the Turtle Beach USB Audio card works with Twinkle again. Could this patch be applied to the Debian kernel? The comment hinting the patch [4] suggests it has not been merged for 3.2. [3] http://kernel-handbook.alioth.debian.org/ch-common-tasks.html [4] https://bugzilla.redhat.com/show_bug.cgi?id=527813#c16 Thanks, Peter -- Package-specific info: ** Version: Linux version 3.1.0-1-amd64 (Debian 3.1.4-1) (wa...@debian.org) (gcc version 4.6.2 (Debian 4.6.2-5) ) #1 SMP Tue Nov 29 13:47:12 UTC 2011 ** Command line: BOOT_IMAGE=/vmlinuz-3.1.0-1-amd64 root=/dev/mapper/vg-root ro pcie_aspm=force i915.i915_enable_rc6=1 i915.i915_enable_fbc=1 i915.lvds_downclock=1 ** Kernel log: [44363.758196] usb 4-1.2: new full speed USB device number 4 using ehci_hcd [44363.852439] usb 4-1.2: New USB device found, idVendor=10f5, idProduct=0211 [44363.852451] usb 4-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [44363.852458] usb 4-1.2: Product: Turtle Beach USB Audio [44363.852463] usb 4-1.2: Manufacturer: Generic [44363.852467] usb 4-1.2: SerialNumber: 01 [44363.857017] input: Generic Turtle Beach USB Audio as /devices/pci:00/:00:1d.0/usb4/4-1/4-1.2/4-1.2:1.3/input/input18 [44363.857380] generic-usb 0003:10F5:0211.0008: input,hidraw0: USB HID v1.00 Device [Generic Turtle Beach USB Audio] on usb-:00:1d.0-1.2/input3 [44368.330704] cannot submit datapipe for urb 0, error -28: not enough bandwidth [44368.387786] cannot submit datapipe for urb 0, error -28: not enough bandwidth ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation 2nd Generation Core Processor Family DRAM Controller [8086:0104] (rev 09) Subsystem: Lenovo Device [17aa:21da] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: agpgart-intel 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0126] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Lenovo Device [17aa:21da] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- [disabled] Capabilities: Kernel driver in use: i915 00:16.0 Communication controller [0780]: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 [8086:1c3a] (rev 04) Subsystem: Lenovo Device [17aa:21da] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 00:19.0 Ethernet controller [0200]: Intel Corporation 82579LM Gigabit Network Connection [8086:1502] (rev 04) Subsystem: Lenovo Device [17aa:21ce] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: e1000e 00:1a.0 USB Controller [0c03]: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 [8086:1c2d] (rev 04) (prog-if 20 [EHCI]) Subsystem: Lenovo Device [17aa:21da] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: ehci_hcd 00:1b.0 Audio device [0403]: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller [8086:1c20] (rev 04) Subsystem: Len
