Bug#667446: linux-image-3.2.0-2-orion5x: leds-gpio fails on MV2120

2012-04-04 Thread Henry von Tresckow
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

2012-04-04 Thread Josip Rodin
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

2012-04-04 Thread Jan Prunk
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

2012-04-04 Thread Ian Campbell
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

2012-04-04 Thread rpnpif
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

2012-04-04 Thread Jonathan Nieder
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

2012-04-04 Thread Debian Bug Tracking System
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

2012-04-04 Thread Debian Bug Tracking System
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)

2012-04-04 Thread Debian Bug Tracking System
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)

2012-04-04 Thread Debian Bug Tracking System
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

2012-04-04 Thread Quintin Russ

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

2012-04-04 Thread Jonathan Nieder
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

2012-04-04 Thread Jonathan Nieder
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

2012-04-04 Thread Debian Bug Tracking System
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

2012-04-04 Thread Jonathan Nieder
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

2012-04-04 Thread Jonathan Nieder
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

2012-04-04 Thread Jonathan Nieder
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

2012-04-04 Thread Debian Bug Tracking System
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

2012-04-04 Thread Steven Chamberlain
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

2012-04-04 Thread Debian Bug Tracking System
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

2012-04-04 Thread Jonathan Nieder
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.

2012-04-04 Thread Debian Bug Tracking System
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

2012-04-04 Thread Jonathan Nieder
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

2012-04-04 Thread Jonathan Nieder
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

2012-04-04 Thread Debian Bug Tracking System
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)

2012-04-04 Thread Debian Bug Tracking System
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

2012-04-04 Thread Jonathan Nieder
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

2012-04-04 Thread Jonathan Nieder
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)

2012-04-04 Thread Steven Chamberlain
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

2012-04-04 Thread Kushal Koolwal
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

2012-04-04 Thread Jonathan Nieder
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.

2012-04-04 Thread Steven Sciame
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)

2012-04-04 Thread Jonathan Nieder
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

2012-04-04 Thread Toni Müller
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]

2012-04-04 Thread Jonathan Nieder
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

2012-04-04 Thread Tom Wright
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

2012-04-04 Thread Jonathan Nieder
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

2012-04-04 Thread Jonathan Nieder
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

2012-04-04 Thread Debian Bug Tracking System
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

2012-04-04 Thread David Fries
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