Bug#667446: linux-image-3.2.0-2-orion5x: leds-gpio fails on MV2120
Package: linux-2.6 Version: 3.2.12-1 Severity: normal During Bootup, the leds-gpio initalization fails with the following error message: leds-gpio: probe of leds-gpio failed with error -22 Only the power led stays lit. The /sys/class/leds directory is also empty. -- Package-specific info: ** Version: Linux version 3.2.0-2-orion5x (Debian 3.2.12-1) (debian-kernel@lists.debian.org) (gcc version 4.6.2 (Debian 4.6.2-12) ) #1 Thu Mar 22 03:54:01 UTC 2012 ** Command line: console=ttyS0,115200 root=/dev/md0 ro BOOT_MODE=normal runintime=13000 serialNo=CN68110K3H ** Not tainted ** Kernel log: [ 12.680997] rtc-pcf8563 0-0051: chip found, driver version 0.4.3 [ 12.688480] rtc-pcf8563 0-0051: low voltage detected, date/time is not reliable. [ 12.695918] rtc-pcf8563 0-0051: retrieved date/time is not valid. [ 12.702508] rtc-pcf8563 0-0051: rtc core: registered rtc-pcf8563 as rtc0 [ 12.709626] Registered led device: mv2120:blue:health [ 12.709882] Registered led device: mv2120:red:health [ 12.710120] Registered led device: mv2120:led:bright [ 12.710357] Registered led device: mv2120:led:dimmed [ 12.710627] Registered led device: mv2120:red:sata0 [ 12.711476] leds-gpio: probe of leds-gpio failed with error -22 [ 12.719263] TCP cubic registered [ 12.722558] NET: Registered protocol family 17 [ 12.727025] Registering the dns_resolver key type [ 12.731875] VFP support v0.3: not present [ 12.736937] registered taskstats version 1 [ 12.742752] rtc-pcf8563 0-0051: low voltage detected, date/time is not reliable. [ 12.750141] rtc-pcf8563 0-0051: retrieved date/time is not valid. [ 12.756267] rtc-pcf8563 0-0051: hctosys: invalid date/time [ 12.761913] Initializing network drop monitor service [ 12.768620] Freeing init memory: 140K [ 12.985733] udevd[48]: starting version 175 [ 13.539871] SCSI subsystem initialized [ 13.721327] libata version 3.00 loaded. [ 13.726336] sata_mv sata_mv.0: version 1.28 [ 13.727399] sata_mv sata_mv.0: slots 32 ports 2 [ 13.789925] scsi0 : sata_mv [ 13.799135] scsi1 : sata_mv [ 13.806608] ata1: SATA max UDMA/133 irq 29 [ 13.810714] ata2: SATA max UDMA/133 irq 29 [ 14.321015] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 14.361032] ata1.00: ATA-8: ST3500418AS, CC38, max UDMA/133 [ 14.366604] ata1.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32) [ 14.431043] ata1.00: configured for UDMA/133 [ 14.436116] scsi 0:0:0:0: Direct-Access ATA ST3500418AS CC38 PQ: 0 ANSI: 5 [ 14.790967] ata2: SATA link down (SStatus 0 SControl 300) [ 14.856637] sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/465 GiB) [ 14.867542] sd 0:0:0:0: [sda] Write Protect is off [ 14.872401] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 14.872733] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 14.919769] sda: sda1 sda2 sda5 [ 14.928971] sd 0:0:0:0: [sda] Attached SCSI disk [ 15.475178] device-mapper: uevent: version 1.0.3 [ 15.484779] device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: dm-de...@redhat.com [ 16.608932] kjournald starting. Commit interval 5 seconds [ 16.614579] EXT3-fs (dm-0): mounted filesystem with ordered data mode [ 18.521715] udevd[194]: starting version 175 [ 19.241204] input: gpio-keys as /devices/platform/gpio-keys/input/input0 [ 19.342251] mv643xx_eth: MV-643xx 10/100/1000 ethernet driver version 1.4 [ 19.349269] mv643xx_eth smi: probed [ 19.514333] mv643xx_eth_port mv643xx_eth_port.0: eth0: port 0 with MAC address 00:0a:e4:87:6e:27 [ 19.614814] usbcore: registered new interface driver usbfs [ 19.620510] usbcore: registered new interface driver hub [ 19.729908] usbcore: registered new device driver usb [ 19.737956] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 19.990610] alg: hash: Test 6 failed for mv-hmac-sha1 [ 19.995751] : 9a 5e 0d 81 ff f1 0b 69 3b 73 88 c8 d6 c9 13 d9 [ 20.002231] 0010: 06 e3 53 3e [ 20.054468] orion-ehci orion-ehci.0: Marvell Orion EHCI [ 20.059848] orion-ehci orion-ehci.0: new USB bus registered, assigned bus number 1 [ 20.141104] orion-ehci orion-ehci.0: irq 17, io mem 0xf105 [ 20.165456] orion-ehci orion-ehci.0: USB 2.0 started, EHCI 1.00 [ 20.189432] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [ 20.196295] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 20.203549] usb usb1: Product: Marvell Orion EHCI [ 20.208251] usb usb1: Manufacturer: Linux 3.2.0-2-orion5x ehci_hcd [ 20.214460] usb usb1: SerialNumber: orion-ehci.0 [ 20.371115] hub 1-0:1.0: USB hub found [ 20.406404] hub 1-0:1.0: 1 port detected [ 20.421073] orion-ehci orion-ehci.1: Marvell Orion EHCI [ 20.426391] orion-ehci orion-ehci.1: new USB bus registered, assigned bus number 2 [ 20.521091] orion-ehci orion-ehci.1: irq 12, io mem 0xf10a [ 20.571057] orion-ehci orion-ehci.1: USB 2.0 started,
Bug#666386: igb + bnx2 + ifenslave + brctl + vconfig = largely broken
On Mon, Apr 02, 2012 at 05:22:37AM +0100, Ben Hutchings wrote: On Sun, 2012-04-01 at 12:40 +0200, Josip Rodin wrote: On Sun, Apr 01, 2012 at 03:09:56AM +0100, Ben Hutchings wrote: I bet this is due to the combination of LRO plus bridging. We try to turn off LRO in devices under a bridge, but that won't work if there's an intermediate bonding device. If you run: # ethtool -K eth0 lro off # ethtool -K eth2 lro off does the bridge start working? Err... % sudo ethtool -K eth0 lro off Cannot set large receive offload settings: Operation not supported % sudo ethtool -K eth2 lro off Cannot set large receive offload settings: Operation not supported Hmm. Well it shouldn't be a problem but you could try also turning off GRO (similar commands). Ah, there we go. Once I ran sudo ethtool -K eth0 gro off, sudo ifenslave bond54 eth0 produced a still-working bond54. That's with eth0 removed from bonding, and eth2 inside. So the bonding device has only one slave now? Yes, it was like that. What if you take the bonding device out completely and add eth2 directly to the bridge? I think I had already tested that and everything was fine, too. Do you want me to test that or is the GRO removal conclusive? -- 2. That which causes joy or happiness. -- 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/20120404075557.ga3...@entuzijast.net
Bug#654799: Cranking sound coming out of speakers with the new 3.1 kernel
Hello ! I can confirm that I have NO further sound errors in the following kernels: ii linux-image-3.2.0-2-686-pae 3.2.9-1 ii linux-image-3.2.0-1-686-pae 3.2.6-1 The rest is still to be tested. Kind regards, Jan On Thu, Mar 1, 2012 at 8:56 AM, Takashi Iwai ti...@suse.de wrote: At Thu, 1 Mar 2012 08:44:33 +0100, Jan Prunk wrote: Hello ! The sound has been stable for the last days without noises, after applying % amixer -c0 set Auto-Mute Mode Disabled OK, another question is whether the auto-mute feature works in hardware, i.e. even when this mixer is set off, the hardware switches the speaker upon plugging the headphone? If yes, we can simply remove this switch and software feature from the driver. thanks, Takashi 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 -- 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/calnopx7hdaedx+wnuzrz0njst1jun1rl21hw5s+wzexvrs5...@mail.gmail.com
Bug#667434: lvcreate / lvremove snapshot under Xen causes Kernel OOPs
Hi Quintin, Thanks for your report. On Wed, 2012-04-04 at 13:54 +1200, Quintin Russ wrote: Package: linux-image-2.6.32-5-xen-amd64 Version: 2.6.32-39 Severity: important We have observed an issue when a Xen dom0 is removing a snapshot for a logical volume and another process comes along to create a snapshot for that same device (different names) causing the server to Kernel Ooops. According to my logs sometimes removing of the snapshot can pause or take a while contributing to the issue. Attempts to add locking code (using dotlockfile) have not so far been successful in mitigating this bug, but we are still exploring this option. The nodes that are affected intermittently we have been unable to reproduce this issue in the lab (on either the same model of hardware or hardware that has crashed in production). From our logs we can see that every time this issue occurs one process has been removing the snapshot while another has been creating a snapshot shortly after (seconds normally). We are currently seeing about a 5% chance of a crash per month (assuming our nodes are equal). This bug looks similar to a number of bugs that have already been filed related to this issue:http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=614400 A quick Google search shows many more (which have mostly been merged): https://www.google.co.nz/webhp?q=site%3Abugs.debian.org%20xen% 20snapshot%20kernel%20oops%20squeeze Those issues were believed to be fixed in 2.6.32-34 and you are running 2.6.32-39 so either this is a different issue (perhaps with similar symptoms) or the issue isn't really fixed. Either way I think we need to see your kernel logs containing the actual oops in order to make any progress. Thanks, Ian. -- Ian Campbell Current Noise: Cathedral - Carnival Bizarre HOORAY, Ronald!! Now YOU can marry LINDA RONSTADT too!! -- 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/133354.20582.13.ca...@zakaz.uk.xensource.com
Bug#667501: linux-image-3.2.0-0.bpo.2-686-pae: crash when trying to read a floppy disk with Nautilus
Package: linux-2.6 Version: 3.2.12-1~bpo60+1 Severity: normal In Nautilus when I click on floppy disk icon, an error is emitted. Floppy drive is unusable under Debian. -- Package-specific info: ** Version: Linux version 3.2.0-0.bpo.2-686-pae (Debian 3.2.12-1~bpo60+1) (debian-kernel@lists.debian.org) (gcc version 4.4.5 (Debian 4.4.5-8) ) #1 SMP Sun Mar 25 11:12:58 UTC 2012 ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.2.0-0.bpo.2-686-pae root=UUID=c9ea41b4-f399-48c8-87a5-b254689124b1 ro quiet ** Tainted: WO (4608) * Taint on warning. * Out-of-tree module has been loaded. ** Kernel log: [17563.596056] [ cut here ] [17563.596129] WARNING: at /build/buildd-linux-2.6_3.2.12-1~bpo60+1-i386-EZ37JT/linux-2.6-3.2.12/debian/build/source_i386_none/drivers/block/floppy.c:1041 setup_rw_floppy+0x1e8/0x2a1 [floppy]() [17563.596137] Hardware name: MS-6380 [17563.596140] floppy_disable_hlt() scheduled for removal in 2012 [17563.596144] Modules linked in: vboxnetadp(O) vboxnetflt(O) vboxdrv(O) mperf cpufreq_stats cpufreq_powersave cpufreq_conservative cpufreq_userspace ppdev lp snd_hrtimer binfmt_misc fuse ipt_REJECT xt_comment ipt_LOG xt_limit xt_tcpudp xt_addrtype xt_state ip6table_filter ip6_tables nf_nat_irc nf_conntrack_irc nf_nat_ftp nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack_ftp nf_conntrack iptable_filter ip_tables x_tables nls_utf8 nls_cp437 vfat fat ext4 jbd2 crc16 hwmon_vid sg loop firewire_sbp2 saa7134_alsa mt20xx tea5767 ir_lirc_codec tda9887 lirc_dev tda8290 ir_mce_kbd_decoder ir_sony_decoder snd_via82xx snd_ac97_codec ac97_bus ir_jvc_decoder tuner ir_rc6_decoder ir_rc5_decoder snd_pcm_oss snd_mixer_oss ir_nec_decoder snd_pcm saa7134 rc_core videobuf_dma_sg snd_page_alloc videobuf_core snd_mpu401_uart v4l2_common usbhid snd_seq_midi videodev snd_rawmidi hid snd_seq_midi_event snd_seq media ohci_hcd tveeprom radeon i2c_viapro ttm via_ircc drm_kms_helper drm irda uhci_hcd ehci_hcd usbcore sr_mod via_rhine crc_ccitt snd_timer snd_seq_device snd soundcore usb_common cdrom evdev i2c_algo_bit i2c_core firewire_ohci power_supply pcspkr 8139too firewire_core 8139cp crc_itu_t mii shpchp floppy ns558 gameport parport_pc parport processor thermal_sys button ext3 jbd mbcache sd_mod crc_t10dif ata_generic pata_via libata scsi_mod [17563.596288] Pid: 0, comm: swapper/0 Tainted: G O 3.2.0-0.bpo.2-686-pae #1 [17563.596292] Call Trace: [17563.596312] [c103b945] ? warn_slowpath_common+0x6a/0x7b [17563.596327] [f84583ae] ? setup_rw_floppy+0x1e8/0x2a1 [floppy] [17563.596333] [c103b9bc] ? warn_slowpath_fmt+0x28/0x2c [17563.596350] [f84583ae] ? setup_rw_floppy+0x1e8/0x2a1 [floppy] [17563.596369] [c104080d] ? irq_enter+0x49/0x49 [17563.596378] [c10465d5] ? run_timer_softirq+0x167/0x20b [17563.596391] [f84581c6] ? fd_watchdog+0x84/0x84 [floppy] [17563.596397] [c104080d] ? irq_enter+0x49/0x49 [17563.596403] [c10408a8] ? __do_softirq+0x9b/0x14e [17563.596409] [c104080d] ? irq_enter+0x49/0x49 [17563.596412] IRQ [c10406f0] ? irq_exit+0x2f/0x91 [17563.596425] [c10203eb] ? smp_apic_timer_interrupt+0x69/0x73 [17563.596434] [c12d62e9] ? apic_timer_interrupt+0x31/0x38 [17563.596443] [c1026554] ? native_safe_halt+0x2/0x3 [17563.596452] [c1011ee2] ? default_idle+0x50/0x87 [17563.596463] [c100bf09] ? cpu_idle+0xa3/0xbe [17563.596474] [c142c7d5] ? start_kernel+0x33d/0x342 [17563.596479] ---[ end trace 3810d95a8a9539d4 ]--- ** Model information not available ** Loaded modules: vboxnetadp(O) vboxnetflt(O) vboxdrv(O) mperf cpufreq_stats cpufreq_powersave cpufreq_conservative cpufreq_userspace ppdev lp snd_hrtimer binfmt_misc fuse ipt_REJECT xt_comment ipt_LOG xt_limit xt_tcpudp xt_addrtype xt_state ip6table_filter ip6_tables nf_nat_irc nf_conntrack_irc nf_nat_ftp nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack_ftp nf_conntrack iptable_filter ip_tables x_tables nls_utf8 nls_cp437 vfat fat ext4 jbd2 crc16 hwmon_vid sg loop firewire_sbp2 saa7134_alsa mt20xx tea5767 ir_lirc_codec tda9887 lirc_dev tda8290 ir_mce_kbd_decoder ir_sony_decoder snd_via82xx snd_ac97_codec ac97_bus ir_jvc_decoder tuner ir_rc6_decoder ir_rc5_decoder snd_pcm_oss snd_mixer_oss ir_nec_decoder snd_pcm saa7134 rc_core videobuf_dma_sg snd_page_alloc videobuf_core snd_mpu401_uart v4l2_common usbhid snd_seq_midi videodev snd_rawmidi hid snd_seq_midi_event snd_seq media ohci_hcd tveeprom radeon i2c_viapro ttm via_ircc drm_kms_helper drm irda uhci_hcd ehci_hcd usbcore sr_mod via_rhine crc_ccitt snd_timer snd_seq_device snd soundcore usb_common cdrom evdev i2c_algo_bit i2c_core firewire_ohci power_supply pcspkr 8139too firewire_core 8139cp crc_itu_t mii shpchp floppy ns558 gameport parport_pc parport processor thermal_sys button ext3 jbd mbcache sd_mod crc_t10dif ata_generic pata_via libata scsi_mod ** PCI devices: 00:00.0 Host bridge [0600]: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333] [1106:3099] Subsystem: VIA Technologies, Inc. Device
Bug#667501: WARNING when trying to read a floppy disk with Nautilus
reassign 667501 src:linux-2.6 3.2.12-1 tags 667501 + upstream patch moreinfo quit rpnpif wrote: WARNING: at /build/buildd-linux-2.6_3.2.12-1~bpo60+1-i386-EZ37JT/linux-2.6-3.2.12/debian/build/source_i386_none/drivers/block/floppy.c:1041 setup_rw_floppy+0x1e8/0x2a1 [floppy]() Hardware name: MS-6380 floppy_disable_hlt() scheduled for removal in 2012 Thanks. This is from commit 3b70b2e5fcf6 Author: Len Brown len.br...@intel.com Date: Fri Apr 1 15:08:48 2011 -0400 x86 idle floppy: deprecate disable_hlt() Plan to remove floppy_disable_hlt in 2012, an ancient workaround with comments that it should be removed. This allows us to remove clutter and a run-time branch from the idle code. WARN_ONCE() on invocation until it is removed. cc: x...@kernel.org cc: sta...@kernel.org # .39.x Signed-off-by: Len Brown len.br...@intel.com Using an assertion (WARN_ONCE) means that Len thinks calls to floppy_disable_hlt are a Bad Thing in some sense, presumably because of their effect on power consumption. So this might be a real bug or just an overly aggressive warning. The fix is commit f6365201d8a2 Author: Len Brown len.br...@intel.com Date: Thu Mar 29 14:49:17 2012 -0700 x86: Remove the ancient and deprecated disable_hlt() and enable_hlt() facility and is not part of master yet. I don't understand how anyone thought applying the warning without the fix could be a good idea. Please test the attached patch, for example using the following instructions: 0. Prerequisites. apt-get install git build-essential 1. Get a copy of the kernel history, if you don't already have it. git clone \ git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 2. Fetch point releases: cd linux git remote add stable \ git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git git fetch stable 3. Configure, build, and test: git checkout stable/linux-3.2.y cp /boot/config-$(uname -r) .config; # current configuration make localmodconfig; # optional: minimize configuration make deb-pkg; # optionally with -jnum for parallel build dpkg -i ../name of package; # as root reboot ... test test test ... 4. Hopefully it produces the warning. So try the patch: cd linux git am -3sc path to patch make deb-pkg; # maybe with -j4 dpkg -i ../name of package; # as root reboot ... test test test ... Hopefully it does not produce the warning. If you happen to have a cheap and ancient 486 or Cyrix 5510, see if floppy disk access makes the power supply go bad. An alternative set of instructions is at [1]. Ben, I think we should take this patch. Do you think it's a candidate for gregkh's stable tree? Thanks, Jonathan [1] http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official or the corresponding page in the debian-kernel-handbook package From: Len Brown len.br...@intel.com Date: Thu, 29 Mar 2012 14:49:17 -0700 Subject: x86: Remove the ancient and deprecated disable_hlt() and enable_hlt() facility commit f6365201d8a21fb347260f89d6e9b3e718d63c70 upstream. The X86_32-only disable_hlt/enable_hlt mechanism was used by the 32-bit floppy driver. Its effect was to replace the use of the HLT instruction inside default_idle() with cpu_relax() - essentially it turned off the use of HLT. This workaround was commented in the code as: disable hlt during certain critical i/o operations This halt magic was a workaround for ancient floppy DMA wreckage. It should be safe to remove. H. Peter Anvin additionally adds: To the best of my knowledge, no-hlt only existed because of flaky power distributions on 386/486 systems which were sold to run DOS. Since DOS did no power management of any kind, including HLT, the power draw was fairly uniform; when exposed to the much hhigher noise levels you got when Linux used HLT caused some of these systems to fail. They were by far in the minority even back then. Alan Cox further says: Also for the Cyrix 5510 which tended to go castors up if a HLT occurred during a DMA cycle and on a few other boxes HLT during DMA tended to go astray. Do we care ? I doubt it. The 5510 was pretty obscure, the 5520 fixed it, the 5530 is probably the oldest still in any kind of use. So, let's finally drop this. Signed-off-by: Len Brown len.br...@intel.com Signed-off-by: Josh Boyer jwbo...@redhat.com Signed-off-by: Andrew Morton a...@linux-foundation.org Acked-by: H. Peter Anvin h...@zytor.com Acked-by: Alan Cox a...@lxorguk.ukuu.org.uk Cc: Stephen Hemminger shemmin...@vyatta.com Cc: Linus Torvalds torva...@linux-foundation.org Cc: sta...@kernel.org Link:
Processed: Re: WARNING when trying to read a floppy disk with Nautilus
Processing commands for cont...@bugs.debian.org: reassign 667501 src:linux-2.6 3.2.12-1 Bug #667501 [linux-2.6] linux-image-3.2.0-0.bpo.2-686-pae: crash when trying to read a floppy disk with Nautilus Bug reassigned from package 'linux-2.6' to 'src:linux-2.6'. No longer marked as found in versions 3.2.12-1~bpo60+1. Ignoring request to alter fixed versions of bug #667501 to the same values previously set Bug #667501 [src:linux-2.6] linux-image-3.2.0-0.bpo.2-686-pae: crash when trying to read a floppy disk with Nautilus Marked as found in versions linux-2.6/3.2.12-1. tags 667501 + upstream patch moreinfo Bug #667501 [src:linux-2.6] linux-image-3.2.0-0.bpo.2-686-pae: crash when trying to read a floppy disk with Nautilus Added tag(s) upstream, moreinfo, and patch. quit Stopping processing here. Please contact me if you need assistance. -- 667501: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667501 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.133355690425684.transcr...@bugs.debian.org
Processed (with 1 errors): Re: Cranking sound coming out of speakers with the new 3.1 kernel
Processing commands for cont...@bugs.debian.org: Version: 3.2.6-1 Unknown command or malformed arguments to command. fixed 654799 linux-2.6/3.2.9-1 Bug #654799 [linux-2.6] linux-source-3.1: Cranking sound coming out of speakers with the new 3.1 kernel Bug #639165 [linux-2.6] linux-2.6: Cranking sound coming out of speakers with the new 3.0 kernel Marked as fixed in versions linux-2.6/3.2.9-1. Marked as fixed in versions linux-2.6/3.2.9-1. quit Stopping processing here. Please contact me if you need assistance. -- 639165: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639165 654799: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=654799 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.133355707626842.transcr...@bugs.debian.org
Bug#654799: marked as done (linux-source-3.1: Cranking sound coming out of speakers with the new 3.1 kernel)
Your message dated Wed, 4 Apr 2012 11:31:02 -0500 with message-id 20120404163101.GC3267@burratino and subject line Re: Cranking sound coming out of speakers with the new 3.1 kernel has caused the Debian Bug report #654799, regarding linux-source-3.1: Cranking sound coming out of speakers with the new 3.1 kernel 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.) -- 654799: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=654799 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: linux-source-3.1 Version: linux-image-3.1.0-1-686-pae 3.1.6-1 Severity: normal Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these lines *** Hello ! I experience the same error again with 3.1.6-1 like previously on 3.0.0-1. Cranking sound coming out of the speakers on my laptop. When booted into 3.0.0-3 I don't have this problem. The explanation is in the previous bug report #639165 Kind regards, Jan Prunk -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.0.0-1-686-pae (SMP w/1 CPU core) 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 fixed 654799 linux-2.6/3.2.9-1 quit Jan Prunk wrote: I can confirm that I have NO further sound errors in the following kernels: ii linux-image-3.2.0-2-686-pae 3.2.9-1 ii linux-image-3.2.0-1-686-pae 3.2.6-1 Marking accordingly. Thanks for testing. ---End Message---
Bug#639165: marked as done (linux-2.6: Cranking sound coming out of speakers with the new 3.0 kernel)
Your message dated Wed, 4 Apr 2012 11:31:02 -0500 with message-id 20120404163101.GC3267@burratino and subject line Re: Cranking sound coming out of speakers with the new 3.1 kernel has caused the Debian Bug report #654799, regarding linux-2.6: Cranking sound coming out of speakers with the new 3.0 kernel 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.) -- 654799: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=654799 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: linux-2.6 Version: linux-3.0.0 Severity: normal Hello ! I recently upgraded from squeeze to wheezy, and also kernel upgraded to wheezy version 3.0 Since then, when being booted with 3.0 my old laptop produces some kind of cranking sound, coming out of the speakers. There are no such problems when being booted into squeeze stable kernel 2.6.32 Kind regards, Jan -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.0.0-1-686-pae (SMP w/1 CPU core) 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 fixed 654799 linux-2.6/3.2.9-1 quit Jan Prunk wrote: I can confirm that I have NO further sound errors in the following kernels: ii linux-image-3.2.0-2-686-pae 3.2.9-1 ii linux-image-3.2.0-1-686-pae 3.2.6-1 Marking accordingly. Thanks for testing. ---End Message---
Bug#667434: lvcreate / lvremove snapshot under Xen causes Kernel OOPs
Hi Ian, On 05/04/12 01:00, Ian Campbell wrote: Hi Quintin, Thanks for your report. On Wed, 2012-04-04 at 13:54 +1200, Quintin Russ wrote: Package: linux-image-2.6.32-5-xen-amd64 Version: 2.6.32-39 Severity: important We have observed an issue when a Xen dom0 is removing a snapshot for a logical volume and another process comes along to create a snapshot for that same device (different names) causing the server to Kernel Ooops. According to my logs sometimes removing of the snapshot can pause or take a while contributing to the issue. Attempts to add locking code (using dotlockfile) have not so far been successful in mitigating this bug, but we are still exploring this option. The nodes that are affected intermittently we have been unable to reproduce this issue in the lab (on either the same model of hardware or hardware that has crashed in production). From our logs we can see that every time this issue occurs one process has been removing the snapshot while another has been creating a snapshot shortly after (seconds normally). We are currently seeing about a 5% chance of a crash per month (assuming our nodes are equal). This bug looks similar to a number of bugs that have already been filed related to this issue:http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=614400 A quick Google search shows many more (which have mostly been merged): https://www.google.co.nz/webhp?q=site%3Abugs.debian.org%20xen% 20snapshot%20kernel%20oops%20squeeze Those issues were believed to be fixed in 2.6.32-34 and you are running 2.6.32-39 so either this is a different issue (perhaps with similar symptoms) or the issue isn't really fixed. Either way I think we need to see your kernel logs containing the actual oops in order to make any progress. Yes, we have been having this problem since before 2.6.32-34 and were very hopeful that change would fix it. This sadly was not the case. Unfortunately there isn't anything in the logs for this, but I have a screenshot from the console, which I have attached. I also had an idle shell at the time the server crashed and this is what I saw: Message from syslogd@dom0 at Apr 4 01:37:22 ... kernel:[4805213.000629] Oops: [#1] SMP Message from syslogd@dom0 at Apr 4 01:37:22 ... kernel:[4805213.000661] last sysfs file: /sys/devices/virtual/block/dm-49/removable Message from syslogd@dom0 at Apr 4 01:37:22 ... kernel:[4805213.001891] Stack: Message from syslogd@dom0 at Apr 4 01:37:22 ... kernel:[4805213.002101] Call Trace: Message from syslogd@dom0 at Apr 4 01:37:22 ... kernel:[4805213.002540] Code: 66 ff 05 c9 83 58 00 48 89 ef e8 db 7a f7 ff 48 89 df e8 7f fe ff ff e8 51 b0 21 00 48 c7 c7 e0 99 67 81 e8 3b c0 21 00 48 8b 1b 48 8b 03 48 81 fb 90 d1 48 81 0f 18 08 0f 85 64 ff ff ff 66 ff Message from syslogd@dom0 at Apr 4 01:37:22 ... kernel:[4805213.002901] CR2: Please let me know if there is anything further I can provide. attachment: kerneloops.png
Bug#628670: Long waking up times on Intel HD gpu and rtl8192ce wireless drivers
Michal Tóth wrote: I am experiencing some problem with wifi drivers rtl8192ce supported by kernel 6.38-2-amd64. Waking up from suspend last probably 2-3minutes with all black screen. When system finally manages to wake up I see messages about kernel bugs reported to maintaniner, but I have no active connection that time, so nothing got send. Ben Hutchings wrote: The firmware requested by r8169 is optional; it's actually a patch that fixes compatibility with some switches and computers. In Linux 2.6.39 (now in sid) the driver will not try to load it during resume. The firmware requested by rtl8192ce is required. The driver should not try again to load it during resume, but it appears to do so even if the firmware was successfully loaded previously. This appears to be fixed in Linux 3.0-rc1, but I'm not sure we can easily apply the fix to Linux 2.6.39. Please forgive my ignorance: do I understand correctly that Michal's symptoms should be gone now? Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120404212921.GA18397@burratino
Bug#409349: usbhid: control queue full; hung apcupsd task
Jonathan Nieder wrote: Steven Chamberlain wrote: It may be only apcupsd users who experience this, but the process hangs due to a system call failing to return, and there were reports of a related error message in the kernel log (control queue full), which seems to have been a precursor to this hang. Thanks. Odd --- the control queue full messages were supposed to be addressed by v2.6.32.10~116 which was included in 2.6.32-10. Alas. Ping. Is nobody trying to use an APC UPS connected by USB any more? :) What kernels work and don't work? Tom, Hugo: are you still interested in pursuing this bug? If not, that's fine, but please do let us know so we can plan accordingly. In suspense, Jonathan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120404212301.GA18337@burratino
Processed: Re: [2.6.22 - 2.6.23 regression] [alpha] tg3: incoming ssh fails with Corrupted MAC on input
Processing commands for cont...@bugs.debian.org: tags 516382 - moreinfo Bug #516382 [linux-2.6] linux-image-2.6.26-1-alpha-generic: tg3: incoming ssh fails with Corrupted MAC on input Removed tag(s) moreinfo. quit Stopping processing here. Please contact me if you need assistance. -- 516382: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516382 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.133357516117738.transcr...@bugs.debian.org
Bug#516382: [2.6.22 - 2.6.23 regression] [alpha] tg3: incoming ssh fails with Corrupted MAC on input
tags 516382 - moreinfo quit Thibaut VARENE wrote: There is. I'll get in touch with you again later this week, I'm currently on vacation ;) Received and confirmed I could access the console and so on, thanks. I hope to get more time for this (e.g., learning how to use aboot) 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/20120404213224.GA18430@burratino
Bug#578477: crashes after several days of use
Hi Simon, Simon Richter wrote: I have switched to another machine. Given sufficient time, I might get around to retrying it on the PegasosII; if there is a motivated developer who might want such a box, I'd also be prepared to give the machine away to good hands. Did the PegasosII end up finding a new owner? Curious, 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/20120404213902.GA18581@burratino
Bug#645547: [i915] intermittent memory corruption after hibernation unless i915.modeset=0
tags 645547 + pending fixed-upstream quit Kjö Hansi Glaz wrote: I tried appending `i915.modeset=0` and thus falling back to vesa makes hibremation/resume working. Said to be fixed by 3.2.14: - drm/i915: suspend fbdev device around suspend/hibernate -- 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/20120404211552.GA18230@burratino
Processed: Re: [i915] intermittent memory corruption after hibernation unless i915.modeset=0
Processing commands for cont...@bugs.debian.org: tags 645547 + pending fixed-upstream Bug #645547 [linux-2.6] [i915] intermittent memory corruption after hibernation unless i915.modeset=0 Added tag(s) fixed-upstream and pending. quit Stopping processing here. Please contact me if you need assistance. -- 645547: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=645547 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.133357569320670.transcr...@bugs.debian.org
Bug#409349: usbhid: control queue full; hung apcupsd task
found 409349 linux-2.6/2.6.32-41 thanks On 04/04/12 22:23, Jonathan Nieder wrote: Ping. Is nobody trying to use an APC UPS connected by USB any more? :) Yep! This week on 2.6.32-41 I noticed apcupsd hang after about a day, followed by the 'control queue full' errors an hour later. That was with the patches suggested in #631287 applied, just in case they made any difference to this. What kernels work and don't work? I already tagged affected versions in the BTS; the first report of this was on 2.6.17 and I myself recall seeing it as far back as 2.6.26. I hadn't been able to test the UPS on a 3.y kernel until this week. Right now I have the UPS hooked up to a new server running 3.2.0-2-amd64 (Debian 3.2.12-1) to see if it recurs. Then in a few weeks, I'll be taking the original hardware (on which the issue was easily reproducible) out of production use, so I can try 3.y kernels on that too. (Until now, I couldn't try 3.y kernels on that box as it needs to run OpenVZ containers). Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/4f7cc08e.5000...@pyro.eu.org
Processed: Re: usbhid: control queue full; hung apcupsd task
Processing commands for cont...@bugs.debian.org: found 409349 linux-2.6/2.6.32-41 Bug #409349 [src:linux-2.6] usbhid: control queue full; hung apcupsd task Bug #611646 [src:linux-2.6] usbhid: control queue full; hung apcupsd task Marked as found in versions linux-2.6/2.6.32-41. Marked as found in versions linux-2.6/2.6.32-41. thanks Stopping processing here. Please contact me if you need assistance. -- 409349: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=409349 611646: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611646 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.133357585521245.transcr...@bugs.debian.org
Bug#578912: [squeeze] [R520] soft lockups with radeon KMS
Jonathan Nieder wrote: Zsolt Rizsanyi wrote: On Tue, Feb 14, 2012 at 11:22 AM, Jonathan Nieder jrnie...@gmail.com wrote: Zsolt Rizsanyi wrote: I could try 2.6.32-41 but I would be testing for a completely different (possibly irrelevant) issue. I understand. I would be interested in the result from 2.6.32-41 anyway. OK, I will get around to try both of them again soon :) So now I'm in suspense. How does 2.6.32-41 do? Ping. A squeeze kernel is supposed to work fine on a wheezy/sid system, and if it doesn't then that is an important bug. If you have any questions, feel free to ask. Sorry for the fuss, 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/20120404214616.GA18667@burratino
Processed: Re: XFS internal error xfs_da_do_buf(2) at line 2085 of file fs/xfs/xfs_da_btree.c.
Processing commands for cont...@bugs.debian.org: tags 579005 + upstream - moreinfo Bug #579005 [linux-2.6] XFS internal error xfs_da_do_buf(2) at line 2085 of file fs/xfs/xfs_da_btree.c Added tag(s) upstream. Bug #579005 [linux-2.6] XFS internal error xfs_da_do_buf(2) at line 2085 of file fs/xfs/xfs_da_btree.c Removed tag(s) moreinfo. End of message, stopping processing here. Please contact me if you need assistance. -- 579005: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=579005 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.133357605822284.transcr...@bugs.debian.org
Bug#582975: drm/i915: Hangcheck timer elapsed... GPU hung
Jonathan Nieder wrote: Edward Allcutt wrote: On latest squeeze kernel. warzone started seemingly ok but loading a game crashed with an OpenAL error: AL lib: pulseaudio.c:612: Context did not connect: Access denied Running it again showed a black screen instead of the normal menu, although the mouse cursor was visible and clicking got audible feedback. After killing the game from another tty, the regular desktop is visible but with some odd corruption [...] chipset: 855GM (Montara-GM) xorg-server 2:1.11.3.901-2 ddx: intel_drv 2.17.0 drm and mesa are presumably 2.4.30-1 and 7.11.2-1 respectively. If you have time to bisect through the kernels at http://snapshot.debian.org/ to find when the fix was introduced (e.g., a good first kernel to try might be 2.6.35), that would be very useful. Would you be interested in pursuing that? Alternatively if we find possibly relevant patches to try testing against squeeze, could you test them? If you have any questions, please don't hesitate to ask. Thanks much, 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/20120404215013.GA18732@burratino
Bug#409349: usbhid: control queue full; hung apcupsd task
unarchive 631287 reassign 631287 src:linux-2.6 2.6.32-35 found 631287 linux-2.6/2.6.32-34squeeze1 fixed 631287 linux-2.6/3.2.1-2 quit Steven Chamberlain wrote: Yep! This week on 2.6.32-41 I noticed apcupsd hang after about a day, followed by the 'control queue full' errors an hour later. [...] I hadn't been able to test the UPS on a 3.y kernel until this week. Right now I have the UPS hooked up to a new server running 3.2.0-2-amd64 (Debian 3.2.12-1) to see if it recurs. Then in a few weeks, I'll be taking the original hardware (on which the issue was easily reproducible) out of production use, so I can try 3.y kernels on that too. Perfect. Thanks much. While I have your attention: does the patch series in #631287 seem to prevent the BUG as advertised without any noticeable unpleasant side-effects? How long have you been testing it? 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/20120404220007.GD17985@burratino
Processed: Re: usbhid: control queue full; hung apcupsd task
Processing commands for cont...@bugs.debian.org: unarchive 631287 Bug #631287 {Done: Jonathan Nieder jrnie...@gmail.com} [linux-image-2.6.32-5-686-bigmem] BUG during access to hiddev (APC UPS) Unarchived Bug 631287 reassign 631287 src:linux-2.6 2.6.32-35 Bug #631287 {Done: Jonathan Nieder jrnie...@gmail.com} [linux-image-2.6.32-5-686-bigmem] BUG during access to hiddev (APC UPS) Bug reassigned from package 'linux-image-2.6.32-5-686-bigmem' to 'src:linux-2.6'. No longer marked as found in versions linux-2.6/2.6.32-35 and linux-2.6/2.6.32-34squeeze1. No longer marked as fixed in versions 3.2.1-2. Bug #631287 {Done: Jonathan Nieder jrnie...@gmail.com} [src:linux-2.6] BUG during access to hiddev (APC UPS) Marked as found in versions linux-2.6/2.6.32-35. found 631287 linux-2.6/2.6.32-34squeeze1 Bug #631287 {Done: Jonathan Nieder jrnie...@gmail.com} [src:linux-2.6] BUG during access to hiddev (APC UPS) Marked as found in versions linux-2.6/2.6.32-34squeeze1 and reopened. fixed 631287 linux-2.6/3.2.1-2 Bug #631287 [src:linux-2.6] BUG during access to hiddev (APC UPS) Marked as fixed in versions linux-2.6/3.2.1-2. quit Stopping processing here. Please contact me if you need assistance. -- 631287: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631287 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.133357682026560.transcr...@bugs.debian.org
Bug#583653: marked as done (xserver-xorg-video-radeon: 15x-slower performance regression in KMS mode for 2D operations)
Your message dated Wed, 4 Apr 2012 17:03:53 -0500 with message-id 20120404220353.GA18853@burratino and subject line Re: xserver-xorg-video-radeon: 15x-slower performance regression in KMS mode for 2D operations has caused the Debian Bug report #583653, regarding xserver-xorg-video-radeon: 15x-slower performance regression in KMS mode for 2D operations 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.) -- 583653: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583653 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: xserver-xorg-video-radeon Version: 1:6.13.0-2 Severity: important When using the R300 driver in KMS mode (current default), performances for 2D operations are 15x slower than without KMS mode (previous default). The attached simple test runs at 17FPS in KMS mode on my computer, against 300FPS in non-KMS mode. This makes most 2D games unplayable. It's worth noting that disabling KMS mode is currently not an option, since non-KMS has display corruption (which didn't happen in the Lenny version) and is otherwise obsoleted. See #583604. -- Package-specific info: /var/lib/x11/X.roster does not exist. /var/lib/x11/X.md5sum does not exist. X server symlink status: lrwxrwxrwx 1 root root 13 Jun 9 2006 /etc/X11/X - /usr/bin/Xorg -rwxr-xr-x 1 root root 1725256 May 4 15:51 /usr/bin/Xorg /var/lib/x11/xorg.conf.roster does not exist. VGA-compatible devices on PCI bus: 01:00.0 VGA compatible controller: ATI Technologies Inc RV350 AP [Radeon 9600] /var/lib/x11/xorg.conf.md5sum does not exist. Xorg X server configuration file status: -rw-r--r-- 1 root root 1412 May 29 09:47 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: # xorg.conf (X.Org X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # values from the debconf database. # # Edit this file with caution, and see the xorg.conf manual page. # (Type man xorg.conf at the shell prompt.) # # This file is automatically updated on xserver-xorg package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xorg # package. # # If you have edited this file but would like it to be automatically updated # again, run the following command: # sudo dpkg-reconfigure -phigh xserver-xorg Section InputDevice Identifier Generic Keyboard Driver kbd Option XkbRules xorg Option XkbModel pc105 Option XkbLayout fr EndSection Section InputDevice Identifier Configured Mouse Driver mouse EndSection Section Device Identifier Configured Video Device # Xorg.0.log says XAA ain't supported anymore: # (II) RADEON(0): XAA Render acceleration unsupported on Radeon 9500/9700 and newer. Please use EXA instead. # Option AccelMethod EXA # Option AccelMethod XAA # Won't work: # Driver radeonhd EndSection Section Monitor Identifier Configured Monitor EndSection Section Screen Identifier Default Screen Monitor Configured Monitor # DefaultDepth16 EndSection Section Extensions Option Composite enable EndSection Kernel version (/proc/version): Linux version 2.6.32-5-686 (Debian 2.6.32-13) (m...@debian.org) (gcc version 4.3.4 (Debian 4.3.4-10) ) #1 SMP Wed May 19 19:51:54 UTC 2010 Xorg X server log files on system: -rw-r--r-- 1 root root 37515 Jan 19 2008 /var/log/Xorg.20.log -rw-r--r-- 1 root root 47787 Apr 30 18:55 /var/log/Xorg.1.log -rw-r--r-- 1 root root 39446 May 29 09:50 /var/log/Xorg.2.log -rw-r--r-- 1 root root 39013 May 29 09:50 /var/log/Xorg.0.log Contents of most recent Xorg X server log file /var/log/Xorg.0.log: X.Org X Server 1.7.7 Release Date: 2010-05-04 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.32-4-686 i686 Debian Current Operating System: Linux dmc 2.6.32-5-686 #1 SMP Wed May 19 19:51:54 UTC 2010 i686 Kernel command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-686 root=UUID=a345c5eb-4d62-4b33-9cb5-8c408482c916 ro Build Date: 04 May 2010 03:43:42PM xorg-server 2:1.7.7-1 (Julien Cristau jcris...@debian.org) Current version of pixman: 0.16.4 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log
Bug#583870: inconsistencies in ext3 file systems
Toni Müller wrote: On 11/27/2011 05:06 AM, Jonathan Nieder wrote: Do you still have the corrupted filesystem available? It might be interesting to try to do a post-mortem analysis on it --- please see the RAW IMAGE FILES section of e2image(8) and let us know if that will be possible. the file system is still available, but I need to check with the user if I can ship his data offsite Did you find out? An image of the corrupt filesystem (without the actual files) would be useful since it would make it possible to try to figure out what the nature of the corruption was, which is a first step to finding the cause of corruption. Curious, 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/20120404220910.GA18889@burratino
Bug#586133: Boot process pauses indefinitely waiting for keyboard activity
Jonathan Nieder wrote: Jonathan Nieder wrote: One more test: is the behavior any different if you supply idle=mwait on the kernel command line? Ping. Are you still interested in pursuing this? (If the answer is no, that's fine, but please do let us know so we can stop tracking it.) Bob, Kushal: ping? Sorry again about the slow response before. -- 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/20120404222107.GA18969@burratino
Bug#631287: BUG during access to hiddev (APC UPS)
On 04/04/12 23:00, Jonathan Nieder wrote: While I have your attention: does the patch series in #631287 seem to prevent the BUG as advertised without any noticeable unpleasant side-effects? How long have you been testing it? I've been running a 2.6.32-41 kernel with those patches for 8 days, but all I can say is that I haven't noticed any *new* issues. My USB-attached APC UPS is working exactly as before, although still affected by #409349 (control queue full). I have never experienced the #631287 BUG to date, so I can't say if the patches really made an improvement. I would plug/unplug the UPS a few times to check for this, except: USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND root 1068 0.0 0.0 0 0 ?DMar28 0:00 [khubd] root 8488 0.0 0.0 12704 220 ?Ds Mar29 0:00 /sbin/apcupsd I've not rebooted since the last time I last experienced #409349, and it seems the UPS was not even detected when I plugged it back in just now. Sometime, perhaps in a few weeks when this box is retired from production use, I should repeatedly plug/unplug the UPS: * on an unpatched kernel, to make sure my specific hardware was affected in the first place * on the patched kernel, to make sure the patches have really fixed it Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/4f7cca70.1030...@pyro.eu.org
Bug#586133: Boot process pauses indefinitely waiting for keyboard activity
Jonathan Bob, Kushal: ping? Sorry for not responding earlier. I think this one is a wild goose chase at least in my case it was like that. Also, I don't have access to the system anymore exhibiting the problem. Most likely this seems to be a BIOS/Firmware bug. Thanks. Kushal Koolwal -- 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/CA+9rrTpnVwt6hO1roUb2uTy_6Dj+EvLgQgX_4ahEFZY0d=m...@mail.gmail.com
Bug#586133: Boot process pauses indefinitely waiting for keyboard activity
Kushal Koolwal wrote: Sorry for not responding earlier. I think this one is a wild goose chase at least in my case it was like that. Also, I don't have access to the system anymore exhibiting the problem. Most likely this seems to be a BIOS/Firmware bug. If I remember correctly there have been bugs like this before (e.g., broken DSDT putting the EC in an unpleasant state) which could be worked around by the kernel. Sorry we didn't get to it in time. Do you remember what make and model that machine had? Bob? Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120404223818.GG17985@burratino
Bug#667567: linux: When connecting to external monitor, screen is jerky as soon as X loads.
Package: linux-2.6 Version: 2.6.32-41squeeze2 Severity: normal File: linux Whenever I connect to an external monitor, the image jerks around and flickers as soon as X starts to load. The pre-boot looks fine including picking a kernel to load. As soon as X loads is where the trouble starts. If I use a different kernel, 2.6.38 (compiled from kernel.org) then the problem goes away. This only happens with the stock kernel (2.6.32-5-686) -- Package-specific info: ** Version: Linux version 2.6.32-5-686 (Debian 2.6.32-41squeeze2) (da...@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Mon Mar 26 05:20:33 UTC 2012 ** Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-686 root=UUID=c12d7448-3eb9-4c84-b82b-442573f5ac9e ro quiet ** Not tainted ** Kernel log: [5.784176] ACPI: Battery Slot [BAT0] (battery present) [5.784304] ACPI: WMI: Mapper loaded [5.786326] input: Lid Switch as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/input/input4 [5.786501] ACPI: Lid Switch [LID0] [5.786595] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input5 [5.786639] ACPI: Power Button [PWRB] [5.786750] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input6 [5.786786] ACPI: Power Button [PWRF] [5.874096] i801_smbus :00:1f.3: PCI INT B - Link[LNKB] - GSI 5 (level, low) - IRQ 5 [5.909873] intel_rng: FWH not detected [5.953273] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 [6.356830] [drm] Initialized drm 1.1.0 20060810 [6.432581] yenta_cardbus :02:05.0: CardBus bridge found [103c:3084] [6.432603] yenta_cardbus :02:05.0: Using CSCINT to route CSC interrupts to PCI [6.432607] yenta_cardbus :02:05.0: Routing CardBus interrupts to PCI [6.432612] yenta_cardbus :02:05.0: TI: mfunc 0x0112, devctl 0x64 [6.563489] i915 :00:02.0: PCI INT A - Link[LNKA] - GSI 10 (level, low) - IRQ 10 [6.563497] i915 :00:02.0: setting latency timer to 64 [6.573198] [drm] set up 31M of stolen space [6.711428] [drm] initialized overlay support [6.962455] yenta_cardbus :02:05.0: ISA IRQ mask 0x00d8, PCI irq 11 [6.962461] yenta_cardbus :02:05.0: Socket status: 3006 [6.962467] pci_bus :02: Raising subordinate bus# of parent bus (#02) from #02 to #06 [6.962482] yenta_cardbus :02:05.0: pcmcia: parent PCI bridge I/O window: 0x3000 - 0x3fff [6.962487] pcmcia_socket pcmcia_socket0: cs: IO port probe 0x3000-0x3fff: clean. [6.962856] yenta_cardbus :02:05.0: pcmcia: parent PCI bridge Memory window: 0xe020 - 0xe02f [6.962860] yenta_cardbus :02:05.0: pcmcia: parent PCI bridge Memory window: 0x2000 - 0x23ff [7.639745] cfg80211: Using static regulatory domain info [7.639750] cfg80211: Regulatory domain: US [7.639752] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [7.639757] (2402000 KHz - 2472000 KHz @ 4 KHz), (600 mBi, 2700 mBm) [7.639762] (517 KHz - 519 KHz @ 4 KHz), (600 mBi, 2300 mBm) [7.639766] (519 KHz - 521 KHz @ 4 KHz), (600 mBi, 2300 mBm) [7.639770] (521 KHz - 523 KHz @ 4 KHz), (600 mBi, 2300 mBm) [7.639775] (523 KHz - 533 KHz @ 4 KHz), (600 mBi, 2300 mBm) [7.639779] (5735000 KHz - 5835000 KHz @ 4 KHz), (600 mBi, 3000 mBm) [7.640236] cfg80211: Calling CRDA for country: US [7.715811] Console: switching to colour frame buffer device 128x48 [7.723763] fb0: inteldrmfb frame buffer device [7.723767] registered panic notifier [7.749061] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 [7.859278] b43-phy0: Broadcom 4306 WLAN found (core revision 5) [7.907109] pcmcia_socket pcmcia_socket0: cs: IO port probe 0x100-0x3af: clean. [7.909215] pcmcia_socket pcmcia_socket0: cs: IO port probe 0x3e0-0x4ff: excluding 0x4d0-0x4d7 [7.909930] pcmcia_socket pcmcia_socket0: cs: IO port probe 0x820-0x8ff: clean. [7.910522] pcmcia_socket pcmcia_socket0: cs: IO port probe 0xc00-0xcf7: clean. [7.911298] pcmcia_socket pcmcia_socket0: cs: IO port probe 0xa00-0xaff: clean. [8.292355] phy0: Selected rate control algorithm 'minstrel' [8.293451] Registered led device: b43-phy0::tx [8.293475] Registered led device: b43-phy0::rx [8.293503] Registered led device: b43-phy0::radio [8.293613] Broadcom 43xx driver loaded [ Features: PMLS, Firmware-ID: FW13 ] [8.360861] Intel ICH :00:1f.5: PCI INT B - Link[LNKB] - GSI 5 (level, low) - IRQ 5 [8.360900] Intel ICH :00:1f.5: setting latency timer to 64 [8.680050] intel8x0_measure_ac97_clock: measured 54172 usecs (2610 samples) [8.680054] intel8x0: clocking to 48000 [8.681050] Intel ICH Modem :00:1f.6: PCI INT B - Link[LNKB] - GSI 5 (level, low) - IRQ 5 [8.681073] Intel ICH Modem :00:1f.6: setting latency timer to 64 [9.036074] MC'97 0 converters and GPIO not
Bug#631287: BUG during access to hiddev (APC UPS)
Steven Chamberlain wrote: I've been running a 2.6.32-41 kernel with those patches for 8 days, but all I can say is that I haven't noticed any *new* issues. My USB-attached APC UPS is working exactly as before, although still affected by #409349 (control queue full). I have never experienced the #631287 BUG to date, so I can't say if the patches really made an improvement. Thanks much for testing. Very useful. I would plug/unplug the UPS a few times to check for this, except: No problem. (Hopefully someone who experienced the problem might report back, or if not, we might apply the patches anyway after reading the code more carefully.) Ciao, 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/20120404233754.GH17985@burratino
Bug#583870: inconsistencies in ext3 file systems
On 04/05/2012 12:09 AM, Jonathan Nieder wrote: Toni Müller wrote: the file system is still available, but I need to check with the user if I can ship his data offsite Did you find out? Yuck. I talked to the user, and he's fine with shipping the data, but somehow, it has become unclear which machine is effected, and furthermore, the user dislikes loss of operation to find out. I'll try to talk to him again to make the data finally available. Sorry for the delay. :(( Kind regards, --Toni++ -- 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/4f7cdace.3090...@oeko.net
Bug#409349: [huug...@gmail.com: Re: usbhid: control queue full; hung apcupsd task]
Forwarding with permission. ---BeginMessage--- On Wed, Apr 4, 2012 at 4:23 PM, Jonathan Nieder jrnie...@gmail.com wrote: Jonathan Nieder wrote: Steven Chamberlain wrote: It may be only apcupsd users who experience this, but the process hangs due to a system call failing to return, and there were reports of a related error message in the kernel log (control queue full), which seems to have been a precursor to this hang. Thanks. Odd --- the control queue full messages were supposed to be addressed by v2.6.32.10~116 which was included in 2.6.32-10. Alas. Ping. Is nobody trying to use an APC UPS connected by USB any more? :) What kernels work and don't work? Tom, Hugo: are you still interested in pursuing this bug? If not, that's fine, but please do let us know so we can plan accordingly. In suspense, Jonathan I bought an Back-UPS RS 700G that is connected by USB and apcupsd 3.14.10-1 using Sid and Wheezy, but it does not have this problem, so I cannot reproduce it. Strangely enough I get control queue full messages when I run tleds on my USB keyboard. Hugo ---End Message---
Bug#409349: usbhid: control queue full; hung apcupsd task
On Thursday 05 April 2012 00:39:32 you wrote: Tom Wright wrote: I haven't seen this bug in quite a while, so maybe it's fixed in 3.X? Best see what others say too I guess. Thanks for the update. How long have you been using the wheezy/sid kernel? Do you mind if I forward this information to the bug log? Quite a while now - I run sid on the machine which has a UPS, so however long it's been the standard kernel in that branch. A few months, at least. You're welcome to send it on to the bug log too. signature.asc Description: This is a digitally signed message part.
Bug#409349: usbhid: control queue full; hung apcupsd task
Tom Wright wrote: On Thursday 05 April 2012 00:39:32 you wrote: Tom Wright wrote: I haven't seen this bug in quite a while, so maybe it's fixed in 3.X? Best see what others say too I guess. Thanks for the update. How long have you been using the wheezy/sid kernel? Do you mind if I forward this information to the bug log? Quite a while now - I run sid on the machine which has a UPS, so however long it's been the standard kernel in that branch. A few months, at least. You're welcome to send it on to the bug log too. Thanks much. Do you remember roughly when you last experienced this bug? (The last time I see in the bug log is in 2007 with 2.6.17 or so :). Others have experienced it with kernels as new as 2.6.32-41 so I'd be especially interested if you remember the behavior with 2.6.33, 2.6.35, 2.6.38, etc. /var/log/dpkg.log* should have the upgrade history of the kernel package if that helps jog your memory.) 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/20120405001841.GC19575@burratino
Bug#583870: inconsistencies in ext3 file systems
Toni Müller wrote: Yuck. I talked to the user, and he's fine with shipping the data, but somehow, it has become unclear which machine is effected, and furthermore, the user dislikes loss of operation to find out. I'll try to talk to him again to make the data finally available. Sorry for the delay. Thanks, and no problem about the delay. I just wanted to get this moving again so it's not forgotten. :) -- 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/20120405002137.GD19575@burratino
Processed: tagging 645547
Processing commands for cont...@bugs.debian.org: tags 645547 + pending Bug #645547 [linux-2.6] [i915] intermittent memory corruption after hibernation unless i915.modeset=0 Ignoring request to alter tags of bug #645547 to the same tags previously set thanks Stopping processing here. Please contact me if you need assistance. -- 645547: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=645547 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.133359858724657.transcr...@bugs.debian.org
Bug#409349: usbhid: control queue full; hung apcupsd task
On Sat, 22 Jan 2011 19:39:24 + Steven Chamberlain wrote: Usually I see the stream of the control queue full errors first, but this time apcupsd hung very soon after boot: INFO: task apcupsd:21604 blocked for more than 120 seconds. [a01bdeb9] ? ohci_urb_dequeue+0xd9/0xe9 [ohci_hcd] [a003f10c] ? usb_kill_urb+0x9d/0xbb [usbcore] [8106681a] ? autoremove_wake_function+0x0/0x2e [a0209feb] ? usbhid_init_reports+0x8c/0xee [a020b396] ? hiddev_ioctl+0x2bf/0x632 [usbhid] This was despite raising apcupsd's POLLTIME from 10 to 60 seconds. My usbmon dump showed that requests were being made that the UPS wasn't returning or failing, sounds like a task for a bus analyzer and a read through the USB standard. usbhid_init_report is called from usbhid_start and from hid.c called on probe to start the device, and as such wouldn't be called each time apcupsd polls the UPS. So increasing the POLLTIME wouldn't have helped. I don't know how many reports it is requesting, but the timeout in usbhid_wait_io is 10 seconds, so 12 could add up to 120 seconds. Even so I would expect it to eventually timeout. Now if it was sitting in ohci_urb_dequeue for 120 seconds that is a problem. On Wed, Apr 04, 2012 at 10:43:42PM +0100, Steven Chamberlain wrote: found 409349 linux-2.6/2.6.32-41 thanks On 04/04/12 22:23, Jonathan Nieder wrote: Ping. Is nobody trying to use an APC UPS connected by USB any more? :) I have three. I only had problems with one OHCI SiS rev 07 PCI 1039:7001 controller, and once I added the patch for introduce timeout for stuck ctrl/out URBs I've not had the issue anymore. Yep! This week on 2.6.32-41 I noticed apcupsd hang after about a day, followed by the 'control queue full' errors an hour later. That was with the patches suggested in #631287 applied, just in case they made any difference to this. My guess is the control queue message full problem just enlarges the window of opportunity fro 'BUG during access to hiddev' bug report #631287. I think it would help avoid crashing when it gets into this situation, but from the patch titles I don't think it would help avoid it. The queue is 256 long, and with apcupsd querying every 10 seconds, 256*10/60=42 minutes once an entry gets blocked. With the timeout set to 5 seconds in the introduce timeout patch and apcups polling every 10 seconds it no matter if every request failed to complete it shouldn't be able to fill up. But that's only if apcupsd is only submitting one control request every 10 seconds, but looking at my old logs that isn't the case. For my UPS it seemed to only ignore a transfer rarely, maybe there are some that are frequent enough to be a problem, in which case the timeout patch wouldn't be able to keep up. It would be nice to have a usbmon dump of it happening to see if that is the case or not. What kernels work and don't work? I already tagged affected versions in the BTS; the first report of this was on 2.6.17 and I myself recall seeing it as far back as 2.6.26. I hadn't been able to test the UPS on a 3.y kernel until this week. Right now I have the UPS hooked up to a new server running 3.2.0-2-amd64 (Debian 3.2.12-1) to see if it recurs. What UPS do you have that's the problem? Mine was, BackUPS Pro 500 firmware 16.3.D USB FW:4 Then in a few weeks, I'll be taking the original hardware (on which the issue was easily reproducible) out of production use, so I can try 3.y kernels on that too. (Until now, I couldn't try 3.y kernels on that box as it needs to run OpenVZ containers). What kind of timeframe is easily reproducible? Can you run information gathering patches on the box, if so I'll put something together. Then again this has been going on for years, if you prefer to wait a few weeks until it is not in production use that's fine. Back when I was first debugging this I added some printk messages for when the queue length increased. If you'll give them a try I'll look them up and also printout that jiffies value as well. -- David Fries da...@fries.netPGP pub CB1EE8F0 http://fries.net/~david/ -- 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/20120405042703.ge3...@spacedout.fries.net