Bug#661696: drm/i915: wrong fifo size due to uncareful refactoring which results in an xserver crash at 800x600
Package: linux-2.6
Version: 2.6.32-41
Severity: important
Tags: upstream patch
Hi,
I've encountered a nasty bug in the drm/i915 part of Debian's stable kernel.
The code is also present in 2.6.33.20, which is the latest stable upstream
release of 2.6.33.y at the time of writing.
During a refactoring of the i915 driver a regression has been introduced
(http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commit;h=e70236a8d3d0a4c100a0b9f7d394d9bda9c56aca):
For some chipsets the wrong fifo size is determined which results in lot's of
pixel errors when starting the xserver and choosing 800x600 as a resolution. If
another resolution is used (eg. 1024x768 or 1280x1024), I don't encounter this
problem.
I've attached a patch that fixes the problem (no pixel errors anymore) and
determines the correct fifo size.
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4828,15 +4828,15 @@ static void intel_init_display(struct drm_device *dev)
dev_priv-display.update_wm = i965_update_wm;
else if (IS_I9XX(dev) || IS_MOBILE(dev)) {
dev_priv-display.update_wm = i9xx_update_wm;
- dev_priv-display.get_fifo_size = i9xx_get_fifo_size;
- } else {
if (IS_I85X(dev))
dev_priv-display.get_fifo_size = i85x_get_fifo_size;
else if (IS_845G(dev))
dev_priv-display.get_fifo_size = i845_get_fifo_size;
else
- dev_priv-display.get_fifo_size = i830_get_fifo_size;
+ dev_priv-display.get_fifo_size = i9xx_get_fifo_size;
+ } else {
dev_priv-display.update_wm = i830_update_wm;
+ dev_priv-display.get_fifo_size = i830_get_fifo_size;
}
}
Regards,
Lukas
-- Package-specific info:
** Version:
Linux version 2.6.32-5-686 (Debian 2.6.32-41) (b...@decadent.org.uk) (gcc
version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Mon Jan 16 16:04:25 UTC 2012
** Command line:
BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-686
root=UUID=08a419ad-d4d1-47ff-94fd-6d7c8c5321de ro quiet
** Not tainted
** Kernel log:
[1.637921] sd 0:0:0:0: [sda] 8027712 512-byte logical blocks: (4.11 GB/3.82
GiB)
[1.638005] sd 0:0:0:0: [sda] Write Protect is off
[1.638010] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[1.638045] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled,
doesn't support DPO or FUA
[1.638258] sda: sda1 sda2
[1.639892] sd 0:0:0:0: [sda] Attached SCSI disk
[1.740461] usb 1-1: new full speed USB device using uhci_hcd and address 2
[1.744283] kjournald starting. Commit interval 5 seconds
[1.744299] EXT3-fs: mounted filesystem with ordered data mode.
[1.897098] usb 1-1: New USB device found, idVendor=1a40, idProduct=0201
[1.897104] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[1.897109] usb 1-1: Product: USB 2.0 Hub [MTT]
[1.897256] usb 1-1: configuration #1 chosen from 1 choice
[1.900120] hub 1-1:1.0: USB hub found
[1.902075] hub 1-1:1.0: 7 ports detected
[2.006518] udev[254]: starting version 164
[2.020066] usb 1-2: new full speed USB device using uhci_hcd and address 3
[2.194232] usb 1-2: New USB device found, idVendor=9710, idProduct=7830
[2.194239] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[2.194244] usb 1-2: Product: USB-MAC Controller
[2.194247] usb 1-2: Manufacturer: Moschip Semiconductor
[2.194251] usb 1-2: SerialNumber: 3b00043d
[2.194414] usb 1-2: configuration #1 chosen from 1 choice
[2.274033] usb 1-1.2: new full speed USB device using uhci_hcd and address 4
[2.350298] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[2.388923] input: PC Speaker as /devices/platform/pcspkr/input/input0
[2.403022] Marking TSC unstable due to TSC halts in idle
[2.405028] processor LNXCPU:00: registered as cooling_device1
[2.419214] Switching to clocksource acpi_pm
[2.456113] intel_rng: FWH not detected
[2.470309] ACPI: AC Adapter [ADP1] (off-line)
[2.470506] input: Power Button as
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input1
[2.470522] ACPI: Power Button [PWRB]
[2.470618] input: Power Button as
/devices/LNXSYSTM:00/LNXPWRBN:00/input/input2
[2.470624] ACPI: Power Button [PWRF]
[2.488242] i801_smbus :00:1f.3: PCI INT B - GSI 17 (level, low) - IRQ
17
[2.499895] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[2.529165] usb 1-1.3: new low speed USB device using uhci_hcd and address 5
[2.542981] usb 1-2: applying rev.C fixup
[2.549198] usb 1-2: applying rev.C fixup
[2.561229] eth1: register 'MOSCHIP usb-ethernet driver' at
usb-:00:1d.0-2, MOSCHIP 7830/7730 usb-NET adapter, 00:13:3b:00:04:3d
[2.561269] usbcore: registered new interface driver MOSCHIP usb-ethernet
driver
[2.618157] [drm] Initialized drm 1.1.0 20060810
[2.714449]
Re: Planning for final lenny point release (5.0.10)
On 27.02.2012 01:12, dann frazier wrote: Ok - sounds like no DSA, but maybe an upload via o-p-u. My vote is to do no kernel upload if the release gets scheduled for the first weekend in march - that's one week out, and I'll have spotty availability beginning mid-week. For later weekends, I'm for it. As you most likely saw already, we've scheduled the point release for the 10th; i.e. a week and a bit from now. Feel free to go ahead with the kernel upload, so we can get it chucked at the buildds. If we could look at getting lkdi and d-i sorted fairly quickly after the kernel builds are in, that would be great, so we don't end up with any last minute surprises; let us know if there's anything you'd like us to assist with there. I was hoping we could get away with binNMUing d-i, but we'd need a manual upload for hppa anyway, so we might as well start with a source+hppa upload I suppose... Regards, Adam -- 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/5af2f18beb5e18a15a737a13cd52c...@mail.adsl.funky-badger.org
Re: [3.1.8 - 3.2.4 regression] Mute with Pulseaudio ignored on a Thinkpad T500
clone 660994 -1 retitle -1 pulseaudio: mute ignored when Master Playback Switch is not present reassign 660994 src:linux-2.6 3.2.4-1 tags 660994 + patch upstream forwarded 660994 https://bugzilla.kernel.org/show_bug.cgi?id=42825 # regression severity 660994 important quit Jonathan Nieder wrote: Takashi Iwai explained[2]: This codec chip has really no mute control, thus it's actually a fix that removes the invalid control. Takashi wrote and S.G. tested a fix to add back the fake control, which should be part of stable kernels soon. (3868137, ALSA: hda - Add a fake mute feature, 2012-02-27) If I understand correctly, the problem is that pulseaudio's mute doesn't mute when the Master Playback Switch is not present. Please feel free to reassign back to the kernel if there turns out to be a fix that can be applied in the kernel to help, though. Cloning the bug since it still seems that pulseaudio could cope better with missing mute controls. Many thanks for your help. Nice to see this sound regression will be solved soon. Sincerely, 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/20120229171827.GA4148@burratino
Processed: Re: [3.1.8 - 3.2.4 regression] Mute with Pulseaudio ignored on a Thinkpad T500
Processing commands for cont...@bugs.debian.org: clone 660994 -1 Bug#660994: linux-image-3.2.0-1-amd64: Mute with Pulseaudio ignored on a Thinkpad T500 after upgrading Bug 660994 cloned as bug 661719. retitle -1 pulseaudio: mute ignored when Master Playback Switch is not present Bug #661719 [pulseaudio] linux-image-3.2.0-1-amd64: Mute with Pulseaudio ignored on a Thinkpad T500 after upgrading Changed Bug title to 'pulseaudio: mute ignored when Master Playback Switch is not present' from 'linux-image-3.2.0-1-amd64: Mute with Pulseaudio ignored on a Thinkpad T500 after upgrading' reassign 660994 src:linux-2.6 3.2.4-1 Bug #660994 [pulseaudio] linux-image-3.2.0-1-amd64: Mute with Pulseaudio ignored on a Thinkpad T500 after upgrading Bug reassigned from package 'pulseaudio' to 'src:linux-2.6'. Bug No longer marked as found in versions pulseaudio/1.0-4. Bug #660994 [src:linux-2.6] linux-image-3.2.0-1-amd64: Mute with Pulseaudio ignored on a Thinkpad T500 after upgrading Bug Marked as found in versions linux-2.6/3.2.4-1. tags 660994 + patch upstream Bug #660994 [src:linux-2.6] linux-image-3.2.0-1-amd64: Mute with Pulseaudio ignored on a Thinkpad T500 after upgrading Added tag(s) upstream and patch. forwarded 660994 https://bugzilla.kernel.org/show_bug.cgi?id=42825 Bug #660994 [src:linux-2.6] linux-image-3.2.0-1-amd64: Mute with Pulseaudio ignored on a Thinkpad T500 after upgrading Set Bug forwarded-to-address to 'https://bugzilla.kernel.org/show_bug.cgi?id=42825'. # regression severity 660994 important Bug #660994 [src:linux-2.6] linux-image-3.2.0-1-amd64: Mute with Pulseaudio ignored on a Thinkpad T500 after upgrading Severity set to 'important' from 'normal' quit Stopping processing here. Please contact me if you need assistance. -- 660994: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660994 661719: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661719 -1: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=-1 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.13305359302579.transcr...@bugs.debian.org
Re: Planning for final lenny point release (5.0.10)
On Wed, Feb 29, 2012 at 01:20:32PM +, Adam D. Barratt wrote: On 27.02.2012 01:12, dann frazier wrote: Ok - sounds like no DSA, but maybe an upload via o-p-u. My vote is to do no kernel upload if the release gets scheduled for the first weekend in march - that's one week out, and I'll have spotty availability beginning mid-week. For later weekends, I'm for it. As you most likely saw already, we've scheduled the point release for the 10th; i.e. a week and a bit from now. Feel free to go ahead with the kernel upload, so we can get it chucked at the buildds. If we could look at getting lkdi and d-i sorted fairly quickly after the kernel builds are in, that would be great, so we don't end up with any last minute surprises; let us know if there's anything you'd like us to assist with there. I was hoping we could get away with binNMUing d-i, but we'd need a manual upload for hppa anyway, so we might as well start with a source+hppa upload I suppose... Ack. -- 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/20120229172036.gb19...@dannf.org
Bug#606482: no headphone output on ASUS M4A785T-D motherboard
Sergio Gelato wrote: If you say so. I don't claim any real expertise in this area. I do note that http://www.intel.com/support/motherboards/desktop/sb/cs-020642.htm#standards jlandonx at Intel wrote: You can also physically check the audio cable of the front panel audio solution. If there is a cable connected to Pin 4, you have an HD Audio module; if there is no cable to Pin 4, you have an AC97 module. And: HD front panel audio solutions should be plugged into HD onboard headers. AC’97 front panel audio solutions should be plugged into AC’97 onboard headers. Some AC’97 front panel audio solutions (but not all) may work with HD onboard headers. If you want connect an AC’97 front panel audio system to HD onboard headers, try these steps: Connect Mic_IN (MIC) to MIC2_L. Connect Audio_R (RIN) to OUT2_R Connect Audio_L (LIN) to OUT2_L. MIC_RET and OUT_RET are for HD audio only; you don't need to connect them for AC'97 audio. Intel does not validate AC’97 front panel audio solutions with boards using HD audio. If the steps above do not work, you will need to use an HD front panel audio solution for full compatibility with Intel Desktop Boards using Intel 945 chipsets and later. I don't know if there's a way for the BIOS to automatically detect the front panel type, but now we're way out of kernel land, so yes, that doesn't make it sound like a major kernel bug. ;-) However, it seems odd to me that an older kernel (from Ubuntu 10.04) worked fine. Doesn't that suggest there might be a possible workaround? Maybe as suggested in [1] this is a jack sense problem and 1731437 (ALSA: HDA VIA: Add low current mode for power saving., 2009-10-10) triggered trouble and if we can detect this condition all we might need is a way to force the jack to power up. Curious, Jonathan [1] https://bugtrack.alsa-project.org/alsa-bug/view.php?id=5309#c23449 -- 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/20120229185945.GB5828@burratino
Processed: Re: drm/i915: wrong fifo size due to uncareful refactoring which results in an xserver crash at 800x600
Processing commands for cont...@bugs.debian.org: tags 661696 = upstream patch moreinfo Bug #661696 [linux-2.6] drm/i915: wrong fifo size due to uncareful refactoring which results in an xserver crash at 800x600 Added tag(s) moreinfo. quit Stopping processing here. Please contact me if you need assistance. -- 661696: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661696 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.13305406202563.transcr...@bugs.debian.org
Bug#661696: drm/i915: wrong fifo size due to uncareful refactoring which results in an xserver crash at 800x600
tags 661696 = upstream patch moreinfo
quit
Hi Lukas,
Lukas Anzinger wrote:
During a refactoring of the i915 driver a regression has been introduced
([...]h=e70236a8d3d0a4c100a0b9f7d394d9bda9c56aca): For some chipsets
the wrong fifo size is determined which results in lot's of pixel
errors when starting the xserver and choosing 800x600 as a
resolution. If another resolution is used (eg. 1024x768 or
1280x1024), I don't encounter this problem.
I've attached a patch that fixes the problem (no pixel errors
anymore) and determines the correct fifo size.
Thanks for the report and analysis. Please test the attached patch
against 2.6.32.y or a squeeze kernel. If it works, we can send this
to Greg for inclusion in the 2.6.32.y series so everyone benefits.
Hope that helps,
Jonathan
From: Adam Jackson a...@redhat.com
Date: Fri, 16 Apr 2010 18:20:57 -0400
Subject: drm/i915: Attempt to fix watermark setup on 85x (v2)
commit 8f4695ed1c9e068772bcce4cd4ff03f88d57a008 upstream.
IS_MOBILE() catches 85x, so we'd always try to use the 9xx FIFO sizing;
since there's an explicit 85x version, this seems wrong.
v2: Handle 830m correctly too.
Signed-off-by: Adam Jackson a...@redhat.com
Reviewed-by: Eric Anholt e...@anholt.net
Signed-off-by: Eric Anholt e...@anholt.net
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
drivers/gpu/drm/i915/intel_display.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 79cc437af3b8..25b3e903c67c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4355,17 +4355,18 @@ static void intel_init_display(struct drm_device *dev)
dev_priv-display.update_wm = g4x_update_wm;
else if (IS_I965G(dev))
dev_priv-display.update_wm = i965_update_wm;
- else if (IS_I9XX(dev) || IS_MOBILE(dev)) {
+ else if (IS_I9XX(dev)) {
dev_priv-display.update_wm = i9xx_update_wm;
dev_priv-display.get_fifo_size = i9xx_get_fifo_size;
+ } else if (IS_I85X(dev)) {
+ dev_priv-display.update_wm = i9xx_update_wm;
+ dev_priv-display.get_fifo_size = i85x_get_fifo_size;
} else {
- if (IS_I85X(dev))
- dev_priv-display.get_fifo_size = i85x_get_fifo_size;
- else if (IS_845G(dev))
+ dev_priv-display.update_wm = i830_update_wm;
+ if (IS_845G(dev))
dev_priv-display.get_fifo_size = i845_get_fifo_size;
else
dev_priv-display.get_fifo_size = i830_get_fifo_size;
- dev_priv-display.update_wm = i830_update_wm;
}
}
--
1.7.9.2
Bug#633423: Problem with autofs 64-bit kernel/32-bit userspace compatibility
tags 633423 = patch upstream quit Sven Joachim wrote: 3.3-rc5 works for me, as does 3.2.7 with the following changes cherry-picked: a32744d4abae (autofs: work around unhappy compat problem on x86-64) 3c761ea05a89 (Fix autofs compile without CONFIG_COMPAT) 048cd4e51d24 (compat: fix compile breakage on s390) Thanks! I've passed this information to Greg (though I'm a bit nervous since it hasn't shown up in mail archives yet). Hopefully we can see this fix in a 3.2.y-stable kernel soon. -- 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/20120229193253.GD5828@burratino
Processed: Re: Problem with autofs 64-bit kernel/32-bit userspace compatibility
Processing commands for cont...@bugs.debian.org: tags 633423 = patch upstream Bug #633423 [linux-2.6] autofs4 interface is broken between x86 and x86_64 Removed tag(s) fixed-upstream. quit Stopping processing here. Please contact me if you need assistance. -- 633423: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633423 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.133054398326510.transcr...@bugs.debian.org
Bug#661734: linux-image-2.6.32-5-amd64: When I manually turn off the wifi from the laptop special button, Debian freeze
Package: linux-2.6 Version: 2.6.32-41 Severity: important When I manually turn off the wifi from the laptop special button, Debian freeze, even caps lock not working -- Package-specific info: ** Version: Linux version 2.6.32-5-amd64 (Debian 2.6.32-41) (b...@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Mon Jan 16 16:22:28 UTC 2012 ** Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-amd64 root=UUID=8dc8f7f9-af32-4d56-9083-0e3a6ba380b3 ro quiet ** Tainted: C (1024) * Module from drivers/staging has been loaded. ** Kernel log: [ 12.708045] hda-intel: spurious response 0x0:0x0, last cmd=0x0f [ 12.708363] hda-intel: spurious response 0x0:0x0, last cmd=0x0f [ 12.708677] hda-intel: spurious response 0x0:0x0, last cmd=0x0f [ 12.708994] hda-intel: spurious response 0x0:0x0, last cmd=0x0f [ 12.709303] hda-intel: spurious response 0x0:0x0, last cmd=0x0f [ 12.709620] hda-intel: spurious response 0x0:0x0, last cmd=0x0f [ 12.709937] hda-intel: spurious response 0x0:0x0, last cmd=0x0f [ 12.710251] hda-intel: spurious response 0x0:0x0, last cmd=0x0f [ 12.710566] hda-intel: spurious response 0x0:0x0, last cmd=0x0f [ 12.710883] hda-intel: spurious response 0x0:0x0, last cmd=0x0f [ 12.711199] hda-intel: spurious response 0x0:0x0, last cmd=0x0f [ 12.711515] hda-intel: spurious response 0x0:0x0, last cmd=0x0f [ 12.711833] hda-intel: spurious response 0x0:0x0, last cmd=0x0f [ 12.712153] hda-intel: spurious response 0x0:0x0, last cmd=0x0f [ 12.712468] hda-intel: spurious response 0x0:0x0, last cmd=0x0f [ 12.712784] hda-intel: spurious response 0x0:0x0, last cmd=0x0f [ 12.713102] hda-intel: spurious response 0x0:0x0, last cmd=0x0f [ 12.713420] hda-intel: spurious response 0x0:0x0, last cmd=0x0f [ 12.713736] hda-intel: spurious response 0x0:0x0, last cmd=0x0f [ 12.714056] hda-intel: spurious response 0x0:0x0, last cmd=0x0f [ 12.714366] hda-intel: spurious response 0x0:0x0, last cmd=0x0f [ 12.714677] hda-intel: spurious response 0x0:0x0, last cmd=0x0f [ 12.714989] hda-intel: spurious response 0x0:0x0, last cmd=0x0f [ 13.717198] hda_intel: azx_get_response timeout, switching to single_cmd mode: last cmd=0x000f0001 [ 13.717973] hda-intel: no codecs initialized [ 13.718492] HDA Intel :01:00.1: PCI INT A disabled [ 14.015149] EXT3-fs warning: maximal mount count reached, running e2fsck is recommended [ 14.015871] EXT3 FS on sda10, internal journal [ 14.276341] kjournald starting. Commit interval 5 seconds [ 14.276350] EXT3-fs warning: maximal mount count reached, running e2fsck is recommended [ 14.276835] EXT3 FS on sda11, internal journal [ 14.276841] EXT3-fs: mounted filesystem with ordered data mode. [ 14.807513] fuse init (API version 7.13) [ 17.623942] ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 17.656546] r8169 :13:00.0: firmware: requesting rtl_nic/rtl8168d-2.fw [ 17.765907] r8169 :13:00.0: eth0: link down [ 17.766308] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 20.829341] Bluetooth: Core ver 2.15 [ 20.829420] NET: Registered protocol family 31 [ 20.829421] Bluetooth: HCI device and connection manager initialized [ 20.829424] Bluetooth: HCI socket layer initialized [ 20.855253] Bluetooth: L2CAP ver 2.14 [ 20.855256] Bluetooth: L2CAP socket layer initialized [ 20.956850] vgaarb: device changed decodes: PCI::00:02.0,olddecodes=io+mem,decodes=none:owns=io+mem [ 20.956853] vgaarb: transferring owner from PCI::00:02.0 to PCI::01:00.0 [ 20.998501] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 20.998503] Bluetooth: BNEP filters: protocol multicast [ 21.020361] Bluetooth: RFCOMM TTY layer initialized [ 21.020365] Bluetooth: RFCOMM socket layer initialized [ 21.020367] Bluetooth: RFCOMM ver 1.11 [ 21.083668] Bridge firewalling registered [ 21.123337] Bluetooth: SCO (Voice Link) ver 0.6 [ 21.123340] Bluetooth: SCO socket layer initialized [ 171.932416] CPU0 attaching NULL sched-domain. [ 171.932425] CPU1 attaching NULL sched-domain. [ 171.932429] CPU2 attaching NULL sched-domain. [ 171.932432] CPU3 attaching NULL sched-domain. [ 171.978863] CPU0 attaching sched-domain: [ 171.978868] domain 0: span 0,2 level SIBLING [ 171.978871] groups: group 88000520fae0 cpus 0 (cpu_power = 589) group 88000530fae0 cpus 2 (cpu_power = 589) [ 171.978880] domain 1: span 0-3 level MC [ 171.978883]groups: group 88000520fbf0 cpus 0,2 (cpu_power = 1178) group 88000528fbf0 cpus 1,3 (cpu_power = 1178) [ 171.978893] CPU1 attaching sched-domain: [ 171.978896] domain 0: span 1,3 level SIBLING [ 171.978898] groups: group 88000528fae0 cpus 1 (cpu_power = 589) group 88000538fae0 cpus 3 (cpu_power = 589) [ 171.978906] domain 1: span 0-3 level MC [ 171.978908]groups: group 88000528fbf0 cpus 1,3 (cpu_power = 1178) group 88000520fbf0 cpus 0,2
Bug#661734: When I manually turn off the wifi from the laptop special button, Debian freeze
Hi, Nadav Vinik wrote: When I manually turn off the wifi from the laptop special button, Debian freeze, even caps lock not working Thanks for reporting it. Can you get a log from when this happens using netconsole, serial console, or by taking a photograph on a text VT? http://www.kernel.org/doc/Documentation/networking/netconsole.txt http://www.kernel.org/doc/Documentation/serial-console.txt I'd also be interested to hear if 3.2.y from sid or squeeze-backports produces the same problem. The only packages from outside squeeze you may need in order to test aside from the kernel image itself are linux-base and initramfs-tools. Is this a regression? What's the last version that worked ok? Sorry for the trouble and hope that helps, Jonathan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120229195058.GE5828@burratino
Bug#661734: When I manually turn off the wifi from the laptop special button, Debian freeze
On 29 February 2012 21:50, Jonathan Nieder jrnie...@gmail.com wrote: Hi, Nadav Vinik wrote: When I manually turn off the wifi from the laptop special button, Debian freeze, even caps lock not working Thanks for reporting it. Can you get a log from when this happens using netconsole, serial console, or by taking a photograph on a text VT? I will check it. Just to mention: When I turn on the computer when the wifi close, Debian stuck in the boot process after the networking. http://www.kernel.org/doc/Documentation/networking/netconsole.txt http://www.kernel.org/doc/Documentation/serial-console.txt I'd also be interested to hear if 3.2.y from sid or squeeze-backports produces the same problem. The only packages from outside squeeze you may need in order to test aside from the kernel image itself are linux-base and initramfs-tools. Is this a regression? What's the last version that worked ok? Sorry for the trouble and hope that helps, Jonathan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120229195058.GE5828@burratino -- הבלוג שלי: http://nadavvin.com -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/camp6mpjmhs-rxawgnlfyhfzym6v8oezpcalitxjrbzx91az...@mail.gmail.com
Bug#628444: Info received (iwlagn - MAC is in deep sleep, cannot restore wifi operation)
Juha Jäykkä ju...@iki.fi writes: One thing just occurred to me: I added 2 GB of memory (total 4 GB) at about the time these problems started. I cannot say for sure the problems did not start earlier, but it is quite possible they started after! (Please do not tell Lenovo that I added the memory myself as I still have on-site warranty for another year or so. =) ) If the replugging of the wifi card does not solve the problem, i.e. if it resurfaces, I will try going back to 2 GB to see if that helps. FWIW I am using the exact same card in an X301 with 8 GB memory and have never seen any such problems. Don't think a RAM upgrade can have any impact, except maybe by causing the card to move in its slot. I assume that the memory slots and mini-pcie slots are behind the same cover in the X201 as well? Replugging it seems like a good idea... I have been using 3.x kernels from unstable for a while and am currently running 3.2.6-1. Card details: [ 12.610246] Intel(R) Wireless WiFi Link AGN driver for Linux, in-tree: [ 12.610317] Copyright(c) 2003-2011 Intel Corporation [ 12.610447] iwlwifi :03:00.0: PCI INT A - GSI 17 (level, low) - IRQ 17 [ 12.610522] iwlwifi :03:00.0: setting latency timer to 64 [ 12.610552] iwlwifi :03:00.0: pci_resource_len = 0x2000 [ 12.610618] iwlwifi :03:00.0: pci_resource_base = c90005794000 [ 12.610685] iwlwifi :03:00.0: HW Revision ID = 0x0 [ 12.610835] iwlwifi :03:00.0: irq 44 for MSI/MSI-X [ 12.610913] iwlwifi :03:00.0: Detected Intel(R) Ultimate N WiFi Link 5300 AGN, REV=0x24 [ 12.611061] iwlwifi :03:00.0: L1 Disabled; Enabling L0S [ 12.630680] iwlwifi :03:00.0: device EEPROM VER=0x11e, CALIB=0x4 [ 12.630752] iwlwifi :03:00.0: Device SKU: 0Xf0 [ 12.912837] iwlwifi :03:00.0: Tunable channels: 13 802.11bg, 24 802.11a channels [ 13.129544] iwlwifi :03:00.0: loaded firmware version 8.83.5.1 build 33692 [ 13.130194] Registered led device: phy0-led [ 13.198329] ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs' nemi:/tmp# lspci -vvnns 03:00.0 03:00.0 Network controller [0280]: Intel Corporation Ultimate N WiFi Link 5300 [8086:4236] Subsystem: Intel Corporation Device [8086:1011] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 44 Region 0: Memory at f050 (64-bit, non-prefetchable) [size=8K] Capabilities: [c8] Power Management version 3 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Address: fee0100c Data: 4199 Capabilities: [e0] Express (v1) Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s 512ns, L1 unlimited ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset+ DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ FLReset- MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 128ns, L1 32us ClockPM+ Surprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- Capabilities: [100 v1] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn- Capabilities: [140 v1] Device Serial Number 00-16-ea-ff-ff-b3-07-88 Kernel driver in use: iwlwifi Bjørn -- 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/87d38xcr31@nemi.mork.no
Bug#628444: Info received (iwlagn - MAC is in deep sleep, cannot restore wifi operation)
that the memory slots and mini-pcie slots are behind the same cover in the X201 as well? Replugging it seems like a good idea... I wish they were! They are in X4? and X30? but not X200s, where I had to remove the keyboard and handrest to get to the card. Most annoying. Nevertheless, the RAM is quit directly on the opposite side of the motherboard compared to the miniPCI slots (there are two: one is empty, I guess it is meant for 3g), so I would not rule out the miniPCI card moving when addin RAM. Especially since I now have almost 3 days of uptime without problems! This is the record since my problems started except for disabling 802.11n and powersave completely, which gave me about a week. I will report back when I loose wifi again or in two weeks if I do not loose it by then (in which case I will assume it was indeed loose in its socket). [ 12.610618] iwlwifi :03:00.0: pci_resource_base = c90005794000 [ 12.610835] iwlwifi :03:00.0: irq 44 for MSI/MSI-X These are different, but I assume it does not matter. [ 12.611061] iwlwifi :03:00.0: L1 Disabled; Enabling L0S I get: [245082.407512] iwlwifi :03:00.0: L1 Enabled; Disabling L0S Does this have any effect? What are L1 and L0S anyway? [ 12.630680] iwlwifi :03:00.0: device EEPROM VER=0x11e, CALIB=0x4 My EEPROM VER=0x11f, but otherwise everything matches. Cheers, Juha -- --- | Juha Jäykkä, ju...@iki.fi | | http://www.maths.leeds.ac.uk/~juhaj | --- signature.asc Description: This is a digitally signed message part.
Bug#661558: kernel messages
First things first: I can confirm that linux-image-3.2.0-1-amd64 3.2.6-1 crashes too. I've been able to capture the kernel messages using netconsole. The messages start, accidentally, just in time to see the kernel assemble the two real arrays I have here: [6.119851] md: raid1 personality registered for level 1 [6.127270] mdadm: sending ioctl 800c0910 to a partition! [6.127355] mdadm: sending ioctl 800c0910 to a partition! [6.127420] mdadm: sending ioctl 1261 to a partition! [6.127487] mdadm: sending ioctl 1261 to a partition! [6.128099] mdadm: sending ioctl 800c0910 to a partition! [6.128170] mdadm: sending ioctl 800c0910 to a partition! [6.128232] mdadm: sending ioctl 1261 to a partition! [6.128299] mdadm: sending ioctl 1261 to a partition! [6.144287] mdadm: sending ioctl 800c0910 to a partition! [6.144358] mdadm: sending ioctl 800c0910 to a partition! [6.218941] md: md1 stopped. [6.225242] md: bindsdc1 [6.225652] md: bindsdb1 [6.227112] bio: create slab bio-1 at 1 [6.227274] md/raid1:md1: active with 2 out of 2 mirrors [6.227659] created bitmap (1 pages) for device md1 [6.227996] md1: bitmap initialized from disk: read 1/1 pages, set 0 of 251 bits [6.249696] md1: detected capacity change from 0 to 263127040 [6.250354] md1: [6.292819] md: md2 stopped. [6.294717] md: bindsdc2 [6.295058] md: bindsdb2 [6.296711] md/raid1:md2: active with 2 out of 2 mirrors [6.304329] created bitmap (3 pages) for device md2 [6.304714] md2: bitmap initialized from disk: read 1/1 pages, set 0 of 5021 bits [6.330160] md2: detected capacity change from 0 to 336907403264 [6.332079] md2: unknown partition table [6.925562] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null) Here I create a new array on spare partitions: # mdadm --create /dev/md3 --metadata=0.90 --assume-clean -l1 -n2 /dev/sdb3 /dev/sdc1 [ 37.530284] scsi_verify_blk_ioctl: 74 callbacks suppressed [ 37.530354] mdadm: sending ioctl 1261 to a partition! [ 37.530415] mdadm: sending ioctl 1261 to a partition! [ 37.566744] mdadm: sending ioctl 1261 to a partition! [ 37.566814] mdadm: sending ioctl 1261 to a partition! [ 37.568463] mdadm: sending ioctl 1261 to a partition! [ 37.568534] mdadm: sending ioctl 1261 to a partition! [ 37.570387] mdadm: sending ioctl 1261 to a partition! [ 37.570457] mdadm: sending ioctl 1261 to a partition! [ 37.574025] mdadm: sending ioctl 1261 to a partition! [ 37.574095] mdadm: sending ioctl 1261 to a partition! [ 38.038824] md: bindsdd1 [ 38.039093] md: bindsdc3 [ 38.308214] md/raid1:md3: active with 2 out of 2 mirrors [ 38.308311] md3: detected capacity change from 0 to 100029104128 [ 38.309864] md3: unknown partition table Here I add the internal bitmap: # mdadm --grow /dev/md3 --bitmap=internal [ 38.360808] md3: bitmap file is out of date (0 1) -- forcing full recovery [ 38.360883] created bitmap (1 pages) for device md3 (at this point the array was still auto-read-only) Here I write something to the array: # dd if=/dev/zero of=/dev/md3 bs=1M count=10 [ 90.957478] BUG: unable to handle kernel NULL pointer dereference at 0010 [ 90.957645] IP: [a01dd2c1] bitmap_endwrite+0x131/0x18f [md_mod] [ 90.957752] PGD 2226c3067 PUD 223ed0067 PMD 0 [ 90.957927] Oops: [#1] SMP [ 90.958061] CPU 1 [ 90.958103] Modules linked in: ext4 mbcache jbd2 crc16 raid1 md_mod netconsole configfs nbd dm_mirror dm_region_hash dm_log dm_mod btrfs zlib_deflate crc32c libcrc32c usbhid hid sr_mod cdrom sd_mod crc_t10dif ata_generic ohci_hcd ahci libahci pata_atiixp ehci_hcd r8169 mii libata usbcore usb_common scsi_mod [last unloaded: scsi_wait_scan] [ 90.959794] [ 90.959849] Pid: 0, comm: swapper/1 Not tainted 3.2.0-1-amd64 #1 System manufacturer System Product Name/M5A78L [ 90.960046] RIP: 0010:[a01dd2c1] [a01dd2c1] bitmap_endwrite+0x131/0x18f [md_mod] [ 90.960167] RSP: 0018:88022fc43cb0 EFLAGS: 00010046 [ 90.960291] RDX: RSI: RDI: 8802236b70c0 [ 90.960355] RBP: 4ff8 R08: R09: 000163a8 [ 90.960418] R10: 000163a8 R11: 000163a8 R12: 0008 [ 90.960482] R13: 8802236b70fc R14: 0202 R15: 0001 [ 90.961330] FS: 7f1170c90700() GS:88022fc4() knlGS: [ 90.961330] CS: 0010 DS: ES: CR0: 8005003b [ 90.961330] CR2: 0010 CR3: 000223e5b000 CR4: 06e0 [ 90.961330] DR0: DR1: DR2: [ 90.961330] DR3: DR6: 0ff0 DR7: 0400 [ 90.961330] Process swapper/1 (pid: 0, threadinfo 880226ce4000, task 880226cd60c0) [ 90.961330] Stack: [ 90.961330] 000a 8802236b7178 0001b008 [ 90.961330]
Processed (with 1 errors): Re: kernel: pl2302 kernel driver bug
Processing commands for cont...@bugs.debian.org: Version: 3.2.6-1 Unknown command or malformed arguments to command. found 655376 linux-2.6/2.6.32-41 Bug #655376 [src:linux-2.6] kernek: pl2302 kernel driver bug Bug Marked as found in versions linux-2.6/2.6.32-41. quit Stopping processing here. Please contact me if you need assistance. -- 655376: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=655376 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.13305604577142.transcr...@bugs.debian.org
Bug#655376: marked as done (kernek: pl2302 kernel driver bug)
Your message dated Wed, 29 Feb 2012 18:07:25 -0600 with message-id 20120301000725.GB9099@burratino and subject line Re: kernel: pl2302 kernel driver bug has caused the Debian Bug report #655376, regarding kernek: pl2302 kernel driver bug 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.) -- 655376: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=655376 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: kernek Severity: important I just rebooted after installing updates (probably a kernel since reboot was required), and now my pl2303 usb serial dongle stopped working. It's quite important for me to have this working. I'll probably reboot into a older kernel if possible until this is fixed. [ 488.228349] [ cut here ] [ 488.228372] WARNING: at /tmp/buildd/linux-2.6-2.6.32/debian/build/source_amd64_none/drivers/usb/serial/usb-serial.c:440 serial_unthrottle+0x53/0x77 [usbserial]() [ 488.228377] Hardware name: Latitude E5520m [ 488.228380] Modules linked in: acpi_cpufreq cpufreq_conservative cpufreq_stats cpufreq_userspace cpufreq_powersave sco parport_pc ppdev bridge stp lp parport bnep rfcomm l2cap bluetooth binfmt_misc uinput fuse nfsd exportfs nfs lockd fscache nfs_acl auth_rpcgss sunrpc coretemp loop firewire_sbp2 snd_hda_codec_intelhdmi snd_hda_codec_idt snd_hda_intel i915 snd_hda_codec snd_hwdep drm_kms_helper snd_pcm drm snd_seq snd_timer snd_seq_device i2c_i801 i2c_algo_bit snd i2c_core psmouse brcm80211(C) pl2303 usbserial mac80211 soundcore snd_page_alloc cfg80211 video serio_raw battery dell_laptop rfkill wmi dcdbas evdev pcspkr output button processor ac ext4 mbcache jbd2 crc16 sg sr_mod cdrom sd_mod crc_t10dif uhci_hcd sdhci_pci sdhci ahci libata mmc_core led_class firewire_ohci firewire_core crc_itu_t thermal thermal_sys scsi_mod tg3 libphy ehci_hcd usbcore nls_base [last unloaded: scsi_wait_scan] [ 488.228485] Pid: 2462, comm: nw4.pl Tainted: G C 2.6.32-5-amd64 #1 [ 488.228489] Call Trace: [ 488.228498] [a02f65d9] ? serial_unthrottle+0x53/0x77 [usbserial] [ 488.228506] [a02f65d9] ? serial_unthrottle+0x53/0x77 [usbserial] [ 488.228514] [8104df9c] ? warn_slowpath_common+0x77/0xa3 [ 488.228521] [a02f65d9] ? serial_unthrottle+0x53/0x77 [usbserial] [ 488.228528] [811fdf7b] ? tty_unthrottle+0x3c/0x47 [ 488.228533] [811fcccf] ? n_tty_flush_buffer+0xc/0x68 [ 488.228539] [811ff8d6] ? tty_ldisc_flush+0x27/0x3d [ 488.228544] [812000f4] ? tty_port_close_end+0x18/0xb9 [ 488.228552] [a02f69b2] ? serial_close+0x78/0x92 [usbserial] [ 488.228558] [811fa9c6] ? tty_release_dev+0x1b5/0x4b9 [ 488.228565] [81097e62] ? rcu_start_gp+0x197/0x1c0 [ 488.228572] [810ff006] ? dput+0x2c/0x15e [ 488.228577] [811facdb] ? tty_release+0x11/0x1a [ 488.228583] [810eff11] ? __fput+0x100/0x1af [ 488.228588] [810ed376] ? filp_close+0x5b/0x62 [ 488.228593] [8104faa0] ? put_files_struct+0x64/0xc1 [ 488.228598] [81051365] ? do_exit+0x236/0x6c6 [ 488.228605] [8106223e] ? flush_work+0x29/0x87 [ 488.228610] [8105186b] ? do_group_exit+0x76/0x9d [ 488.228615] [8105e157] ? get_signal_to_deliver+0x310/0x339 [ 488.228622] [81010037] ? do_notify_resume+0x87/0x73f [ 488.228628] [8103fa2a] ? __wake_up+0x30/0x44 [ 488.228633] [811f8660] ? tty_read+0x80/0xb0 [ 488.228638] [810ef81c] ? vfs_read+0xa6/0xff [ 488.228643] [810efb34] ? fget_light+0x22/0x7e [ 488.228648] [81010e0e] ? int_signal+0x12/0x17 [ 488.228652] ---[ end trace d5ca774dc9515759 ]--- -- System Information: Debian Release: 6.0.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash ---End Message--- ---BeginMessage--- Version: 3.2.6-1 found 655376 linux-2.6/2.6.32-41 quit Hi, René Wagner wrote: ftdi_sio 3-1:1.0: FTDI USB Serial Device converter detected [...] FWIW, I've rebuilt/backported the 3.2.6-1 kernel from testing for/to stable (had to revert some changes in the python-based parts of the Debian kernel build system to make them work with python 2.6) and we can no longer reproduce the problem. Marking accordingly. Thanks for checking. Can you reproduce this with 2.6.33-1~experimental.4 from
Bug#628444: Info received (iwlagn - MAC is in deep sleep, cannot restore wifi operation)
On Wed, 29 Feb 2012, Bjørn Mork wrote: Juha Jäykkä ju...@iki.fi writes: One thing just occurred to me: I added 2 GB of memory (total 4 GB) at about the time these problems started. I cannot say for sure the problems did not start earlier, but it is quite possible they started after! (Please do not [snip] This brings up an interesting point, while I have been having assorted other problems, my deep sleep issues may have stopped around the time that I upgraded to 8GB of RAM. FWIW I am using the exact same card in an X301 with 8 GB memory and have never seen any such problems. Don't think a RAM upgrade can have any impact, except maybe by causing the card to move in its slot. I assume that the memory slots and mini-pcie slots are behind the same cover in the X201 as well? Replugging it seems like a good idea... [snip] Actually, a RAM upgrade can most definitely have an impact. Replacing any hardware on the bus changes bus loads, propagation delays and overall timing of the bus. These changes may be minor, but if the system is running near the limits of the specifications and/or any component on the bus violates the specs, then all sorts of flakey behavior can ensue. Even if everyone plays by the rules, some aspects of bus timings are programmable on some hardware, so a software/firmware bug can also be a source of what would appear to be a hardware problems. Unfortunately, I'm not current on the hardware/buses involved here, so I don't know how these potential issues might apply to this case. Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com | - Custom Software Development - Phone: (800) 467-5820 | - Natural Building Instruction - or: (541) 929-4089 | www.deatech.com
Bug#628444: Info received (iwlagn - MAC is in deep sleep, cannot restore wifi operation)
On Wed, 29 Feb 2012, Juha Jäykkä wrote: that the memory slots and mini-pcie slots are behind the same cover in the X201 as well? Replugging it seems like a good idea... I wish they were! They are in X4? and X30? but not X200s, where I had to remove the keyboard and handrest to get to the card. Most annoying. This is why I haven't tried it on my system. Nevertheless, the RAM is quit directly on the opposite side of the motherboard compared to the miniPCI slots (there are two: one is empty, I guess it is meant for 3g), so I would not rule out the miniPCI card moving when addin RAM. Especially since I now have almost 3 days of uptime without problems! This is the record since my problems started except for disabling 802.11n and powersave completely, which gave me about a week. I will report back when I loose wifi again or in two weeks if I do not loose it by then (in which case I will assume it was indeed loose in its socket). You are forgetting that you also added: pcie_aspm=off to your kernel boot command line. Since I did the same thing and have also suddenly enjoyed quite stable WIFI for the first time, I would venture to guess that your problem was not the seating of the card but the pcie_aspm option setting. If you want to confirm, you might want to remove that boot option and see if the problem returns. If so, this would be the first really useful confirmation of a specific source for the deep sleep problem and provide a workaround for it that others can use, though someone who is familiar with this aspect of the Linux kernel will have to decide what this means in terms of hardware/software issues, what is causing the fault, and how to fix it. Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com | - Custom Software Development - Phone: (800) 467-5820 | - Natural Building Instruction - or: (541) 929-4089 | www.deatech.com
Bug#628444: Info received (iwlagn - MAC is in deep sleep, cannot restore wifi operation)
On Wed, 2012-02-29 at 21:09 -0800, Shannon Dealy wrote: [...] Actually, a RAM upgrade can most definitely have an impact. Replacing any hardware on the bus changes bus loads, propagation delays and overall timing of the bus. [...] Unfortunately, I'm not current on the hardware/buses involved here, so I don't know how these potential issues might apply to this case. I don't think RAM and PCI cards have ever been on the same bus. And with PCIe there is a separate link to each card. Ben. -- Ben Hutchings Q. Which is the greater problem in the world today, ignorance or apathy? A. I don't know and I couldn't care less. signature.asc Description: This is a digitally signed message part
Bug#628444: Info received (iwlagn - MAC is in deep sleep, cannot restore wifi operation)
On Thu, 1 Mar 2012, Ben Hutchings wrote: On Wed, 2012-02-29 at 21:09 -0800, Shannon Dealy wrote: [...] Actually, a RAM upgrade can most definitely have an impact. Replacing any hardware on the bus changes bus loads, propagation delays and overall timing of the bus. [...] Unfortunately, I'm not current on the hardware/buses involved here, so I don't know how these potential issues might apply to this case. I don't think RAM and PCI cards have ever been on the same bus. And with PCIe there is a separate link to each card. Unfortunately, that doesn't actually isolate them, though it does usually reduce some of the sources of problems. There are always interface chips tying them together (otherwise DMA transfers would not be possible) and the behavior of these chips will change depending on the load and temperature, so activity on the bus on one side of the chip can significantly affect the timing behavior of the chip on the other side (I track down bugs like this for a living, just not on PC's in a very long time). I have seen bugs in software show up due to a change in manufacturing processes used to produce an interface chip in the system and hardware glitches on an isolated bus that were due to transmission line effects that rippled right through the chip that was supposed to be isolating the two buses. Of course there is always the old standby of noise passed between chips via the power supply traces. There are many more examples. FWIW. Shannon C. Dealy | DeaTech Research Inc. de...@deatech.com | - Custom Software Development - Phone: (800) 467-5820 | - Natural Building Instruction - or: (541) 929-4089 | www.deatech.com -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.00.1202292245520.6...@nashapur.deatech.com
ARM: backporting dreamplug patches for Wheezy
An initial set of patches for the Dreamplug (basically a descendant of shivaplug, guruplug etc, see [0]) have been accepted into the ARM SoC maintainer's tree. Would it be acceptable to backport these to the Wheezy kernel? I'm happy to do the backporting and test them etc. I recently started running a Dreamplug as my home firewall so I'm motivated to have this h/w supported in Debian. The specific patches are: http://git.kernel.org/?p=linux/kernel/git/arm/arm-soc.git;a=commit;h=3d468b6d6052293ad3b8538b8277077981c28286 http://git.kernel.org/?p=linux/kernel/git/arm/arm-soc.git;a=commit;h=759a45185ac0e4dfaf8bbfcb390ec73aca4b7a34 I imagine there will be more patches as more stuff is moved over to FDT. Is this our first platform which requires an FDT? Do we have a plan in mind for how to deal with those? The FDT file needs to live in /boot so the bootloader can find it. They aren't big -- it seems that an 8K DTB would be quite a large one. Although in principal they describe the hardware in reality the FDTs are being co-evolved along with the kernel code -- I'm not sure what the upstream policy is wrt backwards compatibility. I would hope that, modulo bugs, the most recent FDT would work for all kernels but I don't know that this is going to be the case. I think the choices are: * version the DTB files, like we do for vmlinuz and initrd, and have all the relevant ones in each linux-image package; * put all supported DTBs in a single package (linux-base? or something new? per arch?); * a new (tiny) package per supported board; * punt the problem to the bootloader package and/or the user; I don't think CONFIG_ARM_APPENDED_DTB can be used unless we concatenate at install time since you can only support a single board at a time that way. Ian. [0] http://www.globalscaletechnologies.com/t-dreamplugdetails.aspx -- Ian Campbell BOFH excuse #129: The ring needs another token signature.asc Description: This is a digitally signed message part
Bug#654799: Cranking sound coming out of speakers with the new 3.1 kernel
Hello ! The sound has been stable for the last days without noises, after applying % amixer -c0 set Auto-Mute Mode Disabled It seems this has solved it, until further notice. You might want to keep the bug open for a while, so I can check with all the kernels (it works with latest). Kind regards, Jan On Tue, Feb 28, 2012 at 4:38 PM, Takashi Iwai ti...@suse.de wrote: At Tue, 28 Feb 2012 16:16:48 +0100, Jan Prunk wrote: Hello ! On Sat, Jan 14, 2012 at 12:04 AM, Jonathan Nieder jrnie...@gmail.com wrote: Hi again, Jan Prunk wrote: I tried booting into 3.2.0-rc7-686-pae, but the crunching sound is still present, I am able to play music file properly, and crunching is in the background, and also while not processing any sounds, the crunching appears out of the speakers. Ok, thanks for testing. Please send a summary of this regression to alsa-de...@alsa-project.org, cc-ing Takashi Iwai ti...@suse.de and either me or this bug log so we can track it. Be sure to mention: - steps to reproduce, what you expect versus what actually happens, and how that indicates a bug The sound is ok in kernel version 3.0.0-1-686-pae but on all newer versions there are sparkling/farting noises coming out of the speaker. The noise is not very loud, its barely noticeable, but its repetative and doesn't go away. And I think it happens while typing on the keyboard and a bit later, then it dissapears for a few seconds, or by the time that I type again. - which kernel versions you tried, and what happens with each I tried running alsa-info.sh as a user. I tried 3.0.0-1-686-pae here is the debug: http://www.alsa-project.org/db/?f=c1149b6466b2068d79c7517a8b0808d8b5c26e6b --- Linux vaio 3.2.0-1-686-pae #1 SMP Fri Feb 17 06:27:21 UTC 2012 i686 GNU/Linux ii linux-image-3.2.0-1-686-pae 3.2.6-1 http://www.alsa-project.org/db/?f=fddbfbdc4fc44555a6dc851ecdc70760da6dd840 --- Linux vaio 3.2.0-rc7-686-pae #1 SMP Wed Dec 28 21:26:25 UTC 2011 i686 GNU/Linux ii linux-image-3.2.0-rc7-686-pae 3.2~rc7-1~experimental.1 http://www.alsa-project.org/db/?f=78c8919e87dd03294484f83b5f7ae44331b5edfe Being booted into this version for 15 minutes, it seems to not make any noises, but I will resubmit the info later if the noises will start to appear. 3.2.0-rc7 alsa-info shows that the headphone jack is plugged, thus the speaker is muted. It's natural that the noise goes away in this state. Apart from that, I see no obvious problem in 3.2.0 output. Does the problem still happen when you disable Auto-Mute Mode mixer enum? % amixer -c0 set Auto-Mute Mode Disabled Also, try to pass algin_buffer_size=0 option to snd-hda-intel. I don't expect much that this will influence, but at least, it's a difference between 3.0 and 3.2. Takashi - alsa-info.sh output, as an attachment - if you can make a recording of the strange sound available somewhere online, that would be ideal Because the noise is barely heard, I would need to find a good mic. to be able to record it, but I could do that in the next bug submission. - whether you are able to bisect or test patches if needed I might try that, if there are any manuals around how to do it, but my response might take some time. [1] may have more hints. Thanks and good luck, Jonathan [1] http://alsa-project.org/main/index.php/Help_To_Debug_Intel_HDA Kind regards, Jan Prunk -- Jan Prunk http://www.prunk.si 0x00E80E86 http://pgp.prunk.si http://AS50763.peeringdb.com -- Jan Prunk http://www.prunk.si 0x00E80E86 http://pgp.prunk.si http://AS50763.peeringdb.com -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/calnopx5-38i_jfvifgxczga+na4uvpmcpxrgdwrh9zfmzhy...@mail.gmail.com
