Processed: Re: Bluetooth activation failed (btusb module)

Processing commands for cont...@bugs.debian.org: > # From : > # > # > Linux version 3.2.0-2-amd64 (Debian 3.2.18-1a~test) > (debian-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-5) ) #1 SMP > Sun May 27 21:49:41 WIT 2012 > # [...] > # > rts_pstor: de

Processed: Re: mdadm: sending ioctl 1261 to a partition warnings in kernel log with kernel 3.2

Processing commands for cont...@bugs.debian.org: > # looks like 577ebb374 ("block: add and use scsi_blk_cmd_ioctl", > # 2012-01-12) didn't help > found 656899 linux-2.6/2.6.32-43 Bug #656899 [src:linux-2.6] mdadm: sending ioctl 1261 to a partition warnings in kernel log with kernel 3.2 Bug #66585

Processed: Re: initramfs generation fails at fs/udf/udf.ko (Re: Cannot update kernel with ...)

Processing commands for cont...@bugs.debian.org: > reassign 674059 initramfs-tools 0.98.8 Bug #674059 [linux-2.6] linux-image-2.6.32-5-amd64: Cannot update kernel with apt(itude) Bug reassigned from package 'linux-2.6' to 'initramfs-tools'. No longer marked as found in versions 2.6.32-45. Ignorin

Bug#675093: linux-image-3.2.0-2-amd64: USB "timeout initializing reports" with Eaton UPS

Package: linux-2.6 Version: 3.2.18-1 Severity: normal It would seem that the kernel is doing something wrong when trying to initalise an USB connection to an Eaton (formerly Merlin Gerin) Ellipse Max UPS. When the box is booting, the device's initialisation adds a ~15s delay, then some USB error

Potential PowerTOP breakage with Linux 3.6

According to , Linux 3.6 will likely include a change to the trace event format that breaks PowerTOP 1.x. If wheezy includes PowerTOP 1.x then a partial upgrade to wheezy+1 will probably break it. Are you planning to update to 2.0 in time for wheezy? Ben. -- Ben

Bug#657689: e1000e Detected Hardware Unit Hang:

Hi Matthew, Matthew Ingersoll wrote: > On Tue, May 29, 2012 at 10:53 AM, Jonathan Nieder wrote: >> Thanks.  Sounds worth a try.  Please test the attached patch, for example >> following instructions from [1]. [...] > These are production systems and I do not have a spare NIC to test > with in th

Bug#657689: e1000e Detected Hardware Unit Hang:

On Tue, May 29, 2012 at 10:53 AM, Jonathan Nieder wrote: > > # fixed in 3.0.y. see also bug#663533 > tags 657689 + upstream patch moreinfo fixed-upstream > quit > > Matthew Ingersoll wrote: > > > Searching around, this may already be fixed elsewhere.  See the following > > reports: > > > > https:/

Processed: Re: e1000e Detected Hardware Unit Hang:

Processing commands for cont...@bugs.debian.org: > # fixed in 3.0.y. see also bug#663533 > tags 657689 + upstream patch moreinfo fixed-upstream Bug #657689 [linux-2.6] e1000e Detected Hardware Unit Hang: Added tag(s) upstream, fixed-upstream, moreinfo, and patch. > quit Stopping processing here.

Bug#657689: e1000e Detected Hardware Unit Hang:

# fixed in 3.0.y. see also bug#663533 tags 657689 + upstream patch moreinfo fixed-upstream quit Matthew Ingersoll wrote: > Searching around, this may already be fixed elsewhere. See the following > reports: > > https://bugzilla.redhat.com/show_bug.cgi?id=785806 > > http://www.mail-archive.com/e1

Bug#584314: base: System freezes at random time after Resume from Suspend (Regression)

Andreas Berger wrote: > out of curiousity, is the scope of this still to make a patch for squeeze? Yep, squeeze still has at least a year of life in it yet. Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact

Bug#657689: e1000e Detected Hardware Unit Hang:

On two different machines running two different intel cards, I'm seeing a very similar issue. One machine has the Intel 82572EI and the other is 82571EB. After installing irqbalance on both machines, the messages have gone away for _only_ the 82571EB machine (before it was multiple times daily).

Bug#584314: base: System freezes at random time after Resume from Suspend (Regression)

On Sunday, May 20, 2012 07:32:10 Jonathan Nieder wrote: > Hi Andreas, > > Jonathan Nieder wrote: > > Andreas Berger wrote: > >> ok, i narrowed it down, but it is: > >> > >> found: linux-image-2.6.36-trunk-686, version 2.6.36-1~experimental.1 > >> not found: linux-image-2.6.37-rc4-686, versi

Processed: Re: Toshiba Satellite battery not recognized by acpi

Processing commands for cont...@bugs.debian.org: > found 609846 linux-2.6/3.2.17-1 Bug #609846 [linux-2.6] Toshiba Satellite battery not recognized by acpi Marked as found in versions linux-2.6/3.2.17-1. > found 609846 linux-2.6/3.2.18-1 Bug #609846 [linux-2.6] Toshiba Satellite battery not recogn

Bug#609846: Toshiba Satellite battery not recognized by acpi

found 609846 linux-2.6/3.2.17-1 found 609846 linux-2.6/3.2.18-1 tags 609846 - moreinfo quit Taylor Brown wrote: > No battery status in kernel version '3.2.17-1~bpo60+1' > (squeeze-backports package 'linux-image-3.2.0-0.bpo.2-amd64') or > '3.2.18-1' (sid package 'linux-image-3.2.0-2-amd64'). Than

Bug#661318: to Debian? Fw: 1) cd006086fa5d ata_piix: defer disks to the Hyper-V drivers by default 2) db63a4c8115a libata: add a host flag to ignore detected ATA device FW: use hv_storvsc instead of a

Hi! I spotted that and added them last night. :-) Thanks! Best regards, Victor Miasnikov Blog: http://vvm.blog.tut.by/ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.

Bug#674565: Bluetooth activation failed (btusb module)

Arief M Utama wrote: > On Tue, May 29, 2012 at 3:57 AM, Jonathan Nieder wrote: >> Arief M Utama wrote: >>> [0.00] DMI: Hewlett-Packard HP ENVY 15 NOTEBOOK PC/1688, BIOS F.04 >>> 11/12/2011 >> [...] >>> [2.529762] \_SB_.PCI0:_OSC invalid UUID [...] >>> [2.573869] pci:00: ACPI

Re: to Debian? Fw: 1) cd006086fa5d ata_piix: defer disks to the Hyper-V drivers by default 2) db63a4c8115a libata: add a host flag to ignore detected ATA device FW: use hv_storvsc instead of ata_piix

On Tue, 2012-05-29 at 13:11 +0300, Victor Miasnikov wrote: > Hi! > > Mathieu Simon: >> Finally we should decide on which of > Mathieu Simon: >> the patches we could itegrate for the ata_piix vs. > hv_storvsc > Ben Hutchings: > I prefer that this is resolved upstream. > > Already ( see later) >

Bug#674565: Bluetooth activation failed (btusb module)

On Tue, May 29, 2012 at 3:57 AM, Jonathan Nieder wrote: > Arief M Utama wrote: > > > Hit enter too quick, forgot about the dmesg attachment. Here it is. > > Wonderful, thanks. Just for fun, let's parse some unrelated messages. > > > [0.00] DMI: Hewlett-Packard HP ENVY 15 NOTEBOOK PC/1688

Bug#661318: to Debian? Fw: 1) cd006086fa5d ata_piix: defer disks to the Hyper-V drivers by default 2) db63a4c8115a libata: add a host flag to ignore detected ATA device FW: use hv_storvsc instead of a

Hi! Mathieu Simon: >> Finally we should decide on which of Mathieu Simon: >> the patches we could itegrate for the ata_piix vs. hv_storvsc Ben Hutchings: > I prefer that this is resolved upstream. Already ( see later) May be have sense backport this patches to Debian? - Original Message -

Bug#675010: linux-image-3.3.0-trunk-amd64: Please include CONFIG_OPENVSWITCH as a module

Package: linux-2.6 Version: 3.3.4-1~experimental.1 Severity: wishlist Hi, kernel 3.3 got mainline support for Open vSwitch (CONFIG_OPENVSWITCH / openvswitch.ko) which was previously available as a DKMS module package. This would make the module-assistant and DKMS packages openvswitch-datapath-sour

Bug#674565: Bluetooth activation failed (btusb module)

On Tue, May 29, 2012 at 2:07 AM, Jonathan Nieder wrote: > Arief M Utama wrote: > > On Sun, May 27, 2012 at 1:35 AM, Jonathan Nieder > wrote: > > >> Will look around and then submit these > >> for inclusion in 3.2.y from kernel.org if they seem to be well tested. > >

Bug#670398: Deadlock in hid_reset when Dell iDRAC is reset

On Mon, May 21, 2012 at 10:25:09PM +0530, shyam_i...@dell.com wrote: Hi, > We have observed that doing a reset on idrac on low-end server like R|T210 > R|T310 triggers > the panic whereas the high end servers do not deadlock on an iDRAC reset so > we know that > this timing dependent. Ah thank