Bug#700544: linux-image-2.6.32-5-amd64: Error in acpi_memory_enable_device on memory hotplug, one memory bank missing

2013-02-15 Thread Bernhard Schmidt
On 15.02.2013 04:16, Ben Hutchings wrote:

Hello Ben,

 Please test a kernel with the attached patches, applied in the order:
 
 x86-PCI-for-debuggability-show-host-bridge-windows-e.patch
 x86-PCI-use-host-bridge-_CRS-info-by-default-on-2008.patch
 x86-PCI-Use-_CRS-by-default-on-VMware.patch
 
 and without adding the kernel parameter.
 
 This should result in a boot log message:
 
 PCI: Using host bridge windows from ACPI; if necessary, use pci=nocrs 
 and report a bug
 
 If VMware was not detected as I intended, then you'll see:
 
 PCI: Ignoring host bridge windows from ACPI; if necessary, use 
 pci=use_crs and report a bug
 

Looks good, VMware is detected, together with the patch from #699913
memory hotplugging works fine.

Thanks!
Bernhard


-- 
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/511e0bb7.7030...@lrz.de



Re: 6.0.7 planning

2013-02-15 Thread Adam D. Barratt
On Fri, 2013-02-15 at 01:41 +, Ben Hutchings wrote:
 On Thu, 2013-02-14 at 10:28 -0800, dann frazier wrote:
  Security update has been uploaded. I'll post the builds somewhere as
  they become available for anyone interested in testing.
 
 Version 2.6.32-48 has also been uploaded.

Flagged for acceptance; thanks.

Regards,

Adam


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1360927955.20472.8.ca...@jacala.jungle.funky-badger.org



Bug#698382: marked as done (s390/time: fix sched_clock() overflow)

2013-02-15 Thread Debian Bug Tracking System
Your message dated Fri, 15 Feb 2013 11:47:10 +
with message-id e1u6jl0-0003mx...@franck.debian.org
and subject line Bug#698382: fixed in linux-2.6 2.6.32-48
has caused the Debian Bug report #698382,
regarding s390/time: fix sched_clock() overflow
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.)


-- 
698382: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698382
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Source: linux-2.6
Version: 2.6.32-46

Hi,

this should be backported/included into our kernel when/if it's accepted
upstream. 2.6.32 and 3.2.0 are both affected. (So given the source
package change I guess this bug would need to be cloned for the latter,
but I'll leave that up to you.)

Kind regards
Philipp Kern

- Forwarded message from Heiko Carstens heiko.carst...@de.ibm.com -

Date: Tue, 15 Jan 2013 10:05:03 +0100
From: Heiko Carstens heiko.carst...@de.ibm.com
To: linux-...@vm.marist.edu
Subject: Re: Twin penguins prospered for 417 days, then died
User-Agent: Mutt/1.5.21 (2010-09-15)
Message-ID: 20130115090503.GB3227@osiris

On Mon, Jan 14, 2013 at 08:36:58PM +0100, Philipp Kern wrote:
 On Mon, Jan 14, 2013 at 01:11:34PM +0100, Heiko Carstens wrote:
  That patch is for x86 only and won't fix your problem. However we do have a
  similar bug in the s390 kernel code. The only difference is that it will
  indeed trigger after 417 days instead of 208 days.
  
  The reason is that we calculate with differences of the TOD clock register.
  The TOD clock wraps after appr. 143 years. So far no problem...
  
  However when converting a difference to nanoseconds we must divide the value
  by 4.096. Without floating point arithmetics in the kernel we do that by
  multiplying with 125 and afterwards dividing by 512... and there you can
  see when the overflow happens:
  
  143 years / 125 = 1.114 years. And 365 days * 1.114 = 417.56 days.
  
  So, that's when we hit the overflow.
  
  We are working on a fix!
  
  Thanks again for reporting!
 
 I'd be cool if you could followup here with the patch when it's available. For
 the sake of Debian and others…

The patch below is what we came up with. The patch is against current
kernel version 3.8-rc3+, however I added the Cc: sta...@kernel.org
tag, so it should be backported for all maintained stable kernels at
kernel.org.


From bf01d5d698b7d4a2ec42d55af19fb6d5c0bc0fe0 Mon Sep 17 00:00:00 2001
From: Heiko Carstens heiko.carst...@de.ibm.com
Date: Mon, 14 Jan 2013 16:55:55 +0100
Subject: [PATCH] s390/time: fix sched_clock() overflow

Converting a 64 Bit TOD format value to nanoseconds means that the value
must be divided by 4.096. In order to achieve that we multiply with 125
and divide by 512.
When used within sched_clock() this triggers an overflow after appr.
417 days. Resulting in a sched_clock() return value that is much smaller
than previously and therefore may cause all sort of weird things in
subsystems that rely on a monotonic sched_clock() behaviour.

To fix this implement a tod_to_ns() helper function which converts TOD
values without overflow and call this function from both places that
open coded the conversion: sched_clock() and kvm_s390_handle_wait().

Cc: sta...@kernel.org
Reviewed-by: Martin Schwidefsky schwidef...@de.ibm.com
Signed-off-by: Heiko Carstens heiko.carst...@de.ibm.com
Signed-off-by: Martin Schwidefsky schwidef...@de.ibm.com
---
 arch/s390/include/asm/timex.h | 28 
 arch/s390/kernel/time.c   |  2 +-
 arch/s390/kvm/interrupt.c |  2 +-
 3 files changed, 30 insertions(+), 2 deletions(-)

diff --git a/arch/s390/include/asm/timex.h b/arch/s390/include/asm/timex.h
index fba4d66..4c060bb 100644
--- a/arch/s390/include/asm/timex.h
+++ b/arch/s390/include/asm/timex.h
@@ -128,4 +128,32 @@ static inline unsigned long long get_clock_monotonic(void)
return get_clock_xt() - sched_clock_base_cc;
 }
 
+/**
+ * tod_to_ns - convert a TOD format value to nanoseconds
+ * @todval: to be converted TOD format value
+ * Returns: number of nanoseconds that correspond to the TOD format value
+ *
+ * Converting a 64 Bit TOD format value to nanoseconds means that the value
+ * must be divided by 4.096. In order to achieve that we multiply with 125
+ * and divide by 512:
+ *
+ *ns = (todval * 125)  9;
+ *
+ * In order to avoid an overflow with the multiplication we can rewrite this.
+ * With a split todval == 2^32 * th + tl (th upper 32 bits, tl lower 32 bits)
+ * we end up with
+ *
+ *ns = ((2^32 * th + tl) * 125 )  9;
+ * - ns = (2^23 * th * 125) + ((tl * 125)  9);
+ *
+ */
+static inline 

Bug#698387: marked as done (s390/time: fix sched_clock() overflow)

2013-02-15 Thread Debian Bug Tracking System
Your message dated Fri, 15 Feb 2013 11:47:10 +
with message-id e1u6jl0-0003mx...@franck.debian.org
and subject line Bug#698382: fixed in linux-2.6 2.6.32-48
has caused the Debian Bug report #698382,
regarding s390/time: fix sched_clock() overflow
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.)


-- 
698382: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698382
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Source: linux-2.6
Version: 2.6.32-46

Hi,

this should be backported/included into our kernel when/if it's accepted
upstream. 2.6.32 and 3.2.0 are both affected. (So given the source
package change I guess this bug would need to be cloned for the latter,
but I'll leave that up to you.)

Kind regards
Philipp Kern

- Forwarded message from Heiko Carstens heiko.carst...@de.ibm.com -

Date: Tue, 15 Jan 2013 10:05:03 +0100
From: Heiko Carstens heiko.carst...@de.ibm.com
To: linux-...@vm.marist.edu
Subject: Re: Twin penguins prospered for 417 days, then died
User-Agent: Mutt/1.5.21 (2010-09-15)
Message-ID: 20130115090503.GB3227@osiris

On Mon, Jan 14, 2013 at 08:36:58PM +0100, Philipp Kern wrote:
 On Mon, Jan 14, 2013 at 01:11:34PM +0100, Heiko Carstens wrote:
  That patch is for x86 only and won't fix your problem. However we do have a
  similar bug in the s390 kernel code. The only difference is that it will
  indeed trigger after 417 days instead of 208 days.
  
  The reason is that we calculate with differences of the TOD clock register.
  The TOD clock wraps after appr. 143 years. So far no problem...
  
  However when converting a difference to nanoseconds we must divide the value
  by 4.096. Without floating point arithmetics in the kernel we do that by
  multiplying with 125 and afterwards dividing by 512... and there you can
  see when the overflow happens:
  
  143 years / 125 = 1.114 years. And 365 days * 1.114 = 417.56 days.
  
  So, that's when we hit the overflow.
  
  We are working on a fix!
  
  Thanks again for reporting!
 
 I'd be cool if you could followup here with the patch when it's available. For
 the sake of Debian and others…

The patch below is what we came up with. The patch is against current
kernel version 3.8-rc3+, however I added the Cc: sta...@kernel.org
tag, so it should be backported for all maintained stable kernels at
kernel.org.


From bf01d5d698b7d4a2ec42d55af19fb6d5c0bc0fe0 Mon Sep 17 00:00:00 2001
From: Heiko Carstens heiko.carst...@de.ibm.com
Date: Mon, 14 Jan 2013 16:55:55 +0100
Subject: [PATCH] s390/time: fix sched_clock() overflow

Converting a 64 Bit TOD format value to nanoseconds means that the value
must be divided by 4.096. In order to achieve that we multiply with 125
and divide by 512.
When used within sched_clock() this triggers an overflow after appr.
417 days. Resulting in a sched_clock() return value that is much smaller
than previously and therefore may cause all sort of weird things in
subsystems that rely on a monotonic sched_clock() behaviour.

To fix this implement a tod_to_ns() helper function which converts TOD
values without overflow and call this function from both places that
open coded the conversion: sched_clock() and kvm_s390_handle_wait().

Cc: sta...@kernel.org
Reviewed-by: Martin Schwidefsky schwidef...@de.ibm.com
Signed-off-by: Heiko Carstens heiko.carst...@de.ibm.com
Signed-off-by: Martin Schwidefsky schwidef...@de.ibm.com
---
 arch/s390/include/asm/timex.h | 28 
 arch/s390/kernel/time.c   |  2 +-
 arch/s390/kvm/interrupt.c |  2 +-
 3 files changed, 30 insertions(+), 2 deletions(-)

diff --git a/arch/s390/include/asm/timex.h b/arch/s390/include/asm/timex.h
index fba4d66..4c060bb 100644
--- a/arch/s390/include/asm/timex.h
+++ b/arch/s390/include/asm/timex.h
@@ -128,4 +128,32 @@ static inline unsigned long long get_clock_monotonic(void)
return get_clock_xt() - sched_clock_base_cc;
 }
 
+/**
+ * tod_to_ns - convert a TOD format value to nanoseconds
+ * @todval: to be converted TOD format value
+ * Returns: number of nanoseconds that correspond to the TOD format value
+ *
+ * Converting a 64 Bit TOD format value to nanoseconds means that the value
+ * must be divided by 4.096. In order to achieve that we multiply with 125
+ * and divide by 512:
+ *
+ *ns = (todval * 125)  9;
+ *
+ * In order to avoid an overflow with the multiplication we can rewrite this.
+ * With a split todval == 2^32 * th + tl (th upper 32 bits, tl lower 32 bits)
+ * we end up with
+ *
+ *ns = ((2^32 * th + tl) * 125 )  9;
+ * - ns = (2^23 * th * 125) + ((tl * 125)  9);
+ *
+ */
+static inline 

Bug#699112: marked as done (Regression in timekeeping causes some programs to run slowly)

2013-02-15 Thread Debian Bug Tracking System
Your message dated Fri, 15 Feb 2013 11:47:10 +
with message-id e1u6jl0-0003ma...@franck.debian.org
and subject line Bug#699112: fixed in linux-2.6 2.6.32-48
has caused the Debian Bug report #699112,
regarding Regression in timekeeping causes some programs to run slowly
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.)


-- 
699112: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699112
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Package: src:linux-2.6
Version: 2.6.32-47
Severity: important
Tags: patch upstream

It was reported on the stable mailing list that one of the timekeeping
fixes in 2.6.32.60 causes some programs to sleep for longer than they
should.

Romain Francoise rom...@orebokech.com wrote:
[...]
 There are two separate workloads that are affected by this issue:
 - one is a pretty typical whole-distribution build, which gets 1.5x to 2x
   slower with v2.6.32.60
 - the other is a code simulator, which is basically a bunch of processes
   communicating together using POSIX message queues (mq_timedsend() and
   mq_timedreceive()). It runs approximately 10x slower, but doesn't seem
   to use more CPU, it just sits there doing pretty much nothing.
 
 I managed to narrow the second workload down to a single test case, which
 runs in approximately 0.7s in v2.6.32.59 and 8s (!) in v2.6.32.60. Having
 a simple test case allowed me to do a full bisection in a test VM, and it
 ends on commit 61b76840ddee647c0c223365378c3f394355b7d7 (time: Avoid
 making adjustments if we haven't accumulated anything).
[...]

John Stultz, who made the upstream change and backported it to 2.6.32,
said this fix could be reverted as unsuitable for 2.6.32 and not that
important, though it may be possible to fix it up.

Ben.

-- System Information:
Debian Release: 7.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 3.2.0-4.drm-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
---End Message---
---BeginMessage---
Source: linux-2.6
Source-Version: 2.6.32-48

We believe that the bug you reported is fixed in the latest version of
linux-2.6, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 699...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Ben Hutchings b...@decadent.org.uk (supplier of updated linux-2.6 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 14 Feb 2013 14:11:58 +
Source: linux-2.6
Binary: linux-tools-2.6.32 linux-source-2.6.32 linux-doc-2.6.32 
linux-manual-2.6.32 linux-patch-debian-2.6.32 firmware-linux-free 
linux-support-2.6.32-5 linux-base linux-libc-dev linux-headers-2.6.32-5-all 
linux-headers-2.6.32-5-all-alpha linux-headers-2.6.32-5-common 
linux-image-2.6.32-5-alpha-generic linux-headers-2.6.32-5-alpha-generic 
linux-image-2.6.32-5-alpha-smp linux-headers-2.6.32-5-alpha-smp 
linux-image-2.6.32-5-alpha-legacy linux-headers-2.6.32-5-alpha-legacy 
linux-headers-2.6.32-5-all-amd64 linux-image-2.6.32-5-amd64 
linux-headers-2.6.32-5-amd64 linux-image-2.6.32-5-amd64-dbg 
linux-headers-2.6.32-5-common-openvz linux-image-2.6.32-5-openvz-amd64 
linux-headers-2.6.32-5-openvz-amd64 linux-image-2.6.32-5-openvz-amd64-dbg 
linux-headers-2.6.32-5-common-vserver linux-image-2.6.32-5-vserver-amd64 
linux-headers-2.6.32-5-vserver-amd64 linux-image-2.6.32-5-vserver-amd64-dbg 
linux-headers-2.6.32-5-common-xen linux-image-2.6.32-5-xen-amd64 
linux-headers-2.6.32-5-xen-amd64
 linux-image-2.6.32-5-xen-amd64-dbg xen-linux-system-2.6.32-5-xen-amd64 
linux-headers-2.6.32-5-all-armel linux-image-2.6.32-5-iop32x 
linux-headers-2.6.32-5-iop32x linux-image-2.6.32-5-ixp4xx 
linux-headers-2.6.32-5-ixp4xx linux-image-2.6.32-5-kirkwood 
linux-headers-2.6.32-5-kirkwood linux-image-2.6.32-5-orion5x 
linux-headers-2.6.32-5-orion5x linux-image-2.6.32-5-versatile 
linux-headers-2.6.32-5-versatile linux-headers-2.6.32-5-all-hppa 
linux-image-2.6.32-5-parisc linux-headers-2.6.32-5-parisc 
linux-image-2.6.32-5-parisc-smp linux-headers-2.6.32-5-parisc-smp 

Bug#700486: marked as done (linux-image-2.6.32-5-amd64: Parent task's virtual memory size increases incorrectly when using vfork())

2013-02-15 Thread Debian Bug Tracking System
Your message dated Fri, 15 Feb 2013 11:47:10 +
with message-id e1u6jl0-0003md...@franck.debian.org
and subject line Bug#700486: fixed in linux-2.6 2.6.32-48
has caused the Debian Bug report #700486,
regarding linux-image-2.6.32-5-amd64: Parent task's virtual memory size 
increases incorrectly when using vfork()
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.)


-- 
700486: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700486
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Package: linux-2.6
Version: 2.6.32-46
Severity: normal

When using vfork() followed by any one of the exec*() functions the parent 
task's virtual memory size increases even though the
segment sizes as reported by /proc/pid/maps do not change. Here's an example 
program that shows the problem:

#include stdio.h
#include sys/types.h
#include sys/wait.h
#include unistd.h
 
int main(int argc, char **argv)
{
pid_t pid;
int status;
char *args[2];
 
args[0] = /bin/true;
args[1] = NULL;
 
for (;;) {
pid = vfork();
 
if (pid  0) {
perror(vfork);
return 1;
}
 
if (pid == 0) {
(void) execvp(args[0], args);
_exit(1);
}
 
(void) waitpid(-1, status, 0);
}
}

When running the program one can see the VIRT size of the process (as reported 
by ps/top or /proc/pid/stat) increase
indefinitely. Changing the vfork() call to fork() makes the problem disappear.

The increase in virtual memory size is directly proportional to the size of the 
arguments passed to the child process. Also,
the upstream kernel (tested versions: 2.6.31, 2.6.32, 2.6.34, 3.1.0, 3.5.0) 
does not exhibit this behavior.

One of the Debian patches 
(exec-make-argv-envp-memory-visible-to-oom-killer.patch) directly affects how 
argv-related memory
is accounted for. I believe that it is this patch which does not properly 
account for the fact that child processes spawned
by vfork() share the same mm struct like their parent proccesses.

-- Package-specific info:
** Version:
Linux version 2.6.32-5-amd64 (Debian 2.6.32-46) (da...@debian.org) (gcc version 
4.3.5 (Debian 4.3.5-4) ) #1 SMP Sun Sep 23 10:07:46 UTC 2012

** Command line:
BOOT_IMAGE=/vmlinuz-2.6.32-5-amd64 root=/dev/mapper/netways-root ro quiet

** Not tainted

** Kernel log:
[0.816610] usb usb7: configuration #1 chosen from 1 choice
[0.816627] hub 7-0:1.0: USB hub found
[0.816630] hub 7-0:1.0: 2 ports detected
[0.816661] uhci_hcd :00:1d.2: PCI INT C - GSI 18 (level, low) - IRQ 18
[0.816667] uhci_hcd :00:1d.2: setting latency timer to 64
[0.816669] uhci_hcd :00:1d.2: UHCI Host Controller
[0.816674] uhci_hcd :00:1d.2: new USB bus registered, assigned bus 
number 8
[0.816692] uhci_hcd :00:1d.2: irq 18, io base 0x18c0
[0.816714] usb usb8: New USB device found, idVendor=1d6b, idProduct=0001
[0.816715] usb usb8: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1
[0.816717] usb usb8: Product: UHCI Host Controller
[0.816718] usb usb8: Manufacturer: Linux 2.6.32-5-amd64 uhci_hcd
[0.816719] usb usb8: SerialNumber: :00:1d.2
[0.816753] usb usb8: configuration #1 chosen from 1 choice
[0.816772] hub 8-0:1.0: USB hub found
[0.816775] hub 8-0:1.0: 2 ports detected
[1.126999] usb 6-2: new low speed USB device using uhci_hcd and address 2
[1.145503] ata3: SATA link down (SStatus 0 SControl 300)
[1.156041] ata4: SATA link down (SStatus 0 SControl 300)
[1.303363] usb 6-2: New USB device found, idVendor=04d9, idProduct=1400
[1.303366] usb 6-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[1.303421] usb 6-2: configuration #1 chosen from 1 choice
[1.312416] usbcore: registered new interface driver hiddev
[1.330575] input: HID 04d9:1400 as 
/devices/pci:00/:00:1d.0/usb6/6-2/6-2:1.0/input/input1
[1.330606] generic-usb 0003:04D9:1400.0001: input,hidraw0: USB HID v1.10 
Keyboard [HID 04d9:1400] on usb-:00:1d.0-2/input0
[1.363630] input: HID 04d9:1400 as 
/devices/pci:00/:00:1d.0/usb6/6-2/6-2:1.1/input/input2
[1.363670] generic-usb 0003:04D9:1400.0002: input,hidraw1: USB HID v1.10 
Mouse [HID 04d9:1400] on usb-:00:1d.0-2/input1
[1.363681] usbcore: registered new interface driver usbhid
[1.363683] usbhid: v2.6:USB HID core driver
[1.436055] ata2.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[1.436066] 

linux-2.6_2.6.32-48_multi.changes ACCEPTED into proposed-updates-stable-new, proposed-updates

2013-02-15 Thread Debian FTP Masters


Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 14 Feb 2013 14:11:58 +
Source: linux-2.6
Binary: linux-tools-2.6.32 linux-source-2.6.32 linux-doc-2.6.32 
linux-manual-2.6.32 linux-patch-debian-2.6.32 firmware-linux-free 
linux-support-2.6.32-5 linux-base linux-libc-dev linux-headers-2.6.32-5-all 
linux-headers-2.6.32-5-all-alpha linux-headers-2.6.32-5-common 
linux-image-2.6.32-5-alpha-generic linux-headers-2.6.32-5-alpha-generic 
linux-image-2.6.32-5-alpha-smp linux-headers-2.6.32-5-alpha-smp 
linux-image-2.6.32-5-alpha-legacy linux-headers-2.6.32-5-alpha-legacy 
linux-headers-2.6.32-5-all-amd64 linux-image-2.6.32-5-amd64 
linux-headers-2.6.32-5-amd64 linux-image-2.6.32-5-amd64-dbg 
linux-headers-2.6.32-5-common-openvz linux-image-2.6.32-5-openvz-amd64 
linux-headers-2.6.32-5-openvz-amd64 linux-image-2.6.32-5-openvz-amd64-dbg 
linux-headers-2.6.32-5-common-vserver linux-image-2.6.32-5-vserver-amd64 
linux-headers-2.6.32-5-vserver-amd64 linux-image-2.6.32-5-vserver-amd64-dbg 
linux-headers-2.6.32-5-common-xen linux-image-2.6.32-5-xen-amd64 
linux-headers-2.6.32-5-xen-amd64
 linux-image-2.6.32-5-xen-amd64-dbg xen-linux-system-2.6.32-5-xen-amd64 
linux-headers-2.6.32-5-all-armel linux-image-2.6.32-5-iop32x 
linux-headers-2.6.32-5-iop32x linux-image-2.6.32-5-ixp4xx 
linux-headers-2.6.32-5-ixp4xx linux-image-2.6.32-5-kirkwood 
linux-headers-2.6.32-5-kirkwood linux-image-2.6.32-5-orion5x 
linux-headers-2.6.32-5-orion5x linux-image-2.6.32-5-versatile 
linux-headers-2.6.32-5-versatile linux-headers-2.6.32-5-all-hppa 
linux-image-2.6.32-5-parisc linux-headers-2.6.32-5-parisc 
linux-image-2.6.32-5-parisc-smp linux-headers-2.6.32-5-parisc-smp 
linux-image-2.6.32-5-parisc64 linux-headers-2.6.32-5-parisc64 
linux-image-2.6.32-5-parisc64-smp linux-headers-2.6.32-5-parisc64-smp 
linux-headers-2.6.32-5-all-i386 linux-image-2.6.32-5-486 
linux-headers-2.6.32-5-486 linux-image-2.6.32-5-686 linux-headers-2.6.32-5-686 
linux-image-2.6.32-5-686-bigmem linux-headers-2.6.32-5-686-bigmem 
linux-image-2.6.32-5-686-bigmem-dbg linux-image-2.6.32-5-openvz-686
 linux-headers-2.6.32-5-openvz-686 linux-image-2.6.32-5-openvz-686-dbg 
linux-image-2.6.32-5-vserver-686 linux-headers-2.6.32-5-vserver-686 
linux-image-2.6.32-5-vserver-686-bigmem 
linux-headers-2.6.32-5-vserver-686-bigmem 
linux-image-2.6.32-5-vserver-686-bigmem-dbg linux-image-2.6.32-5-xen-686 
linux-headers-2.6.32-5-xen-686 linux-image-2.6.32-5-xen-686-dbg 
xen-linux-system-2.6.32-5-xen-686 linux-headers-2.6.32-5-all-ia64 
linux-image-2.6.32-5-itanium linux-headers-2.6.32-5-itanium 
linux-image-2.6.32-5-mckinley linux-headers-2.6.32-5-mckinley 
linux-image-2.6.32-5-vserver-itanium linux-headers-2.6.32-5-vserver-itanium 
linux-image-2.6.32-5-vserver-mckinley linux-headers-2.6.32-5-vserver-mckinley 
linux-headers-2.6.32-5-all-m68k linux-image-2.6.32-5-amiga 
linux-headers-2.6.32-5-amiga linux-image-2.6.32-5-atari 
linux-headers-2.6.32-5-atari linux-image-2.6.32-5-bvme6000 
linux-headers-2.6.32-5-bvme6000 linux-image-2.6.32-5-mac 
linux-headers-2.6.32-5-mac
 linux-image-2.6.32-5-mvme147 linux-headers-2.6.32-5-mvme147 
linux-image-2.6.32-5-mvme16x linux-headers-2.6.32-5-mvme16x 
linux-headers-2.6.32-5-all-mips linux-image-2.6.32-5-r4k-ip22 
linux-headers-2.6.32-5-r4k-ip22 linux-image-2.6.32-5-r5k-ip32 
linux-headers-2.6.32-5-r5k-ip32 linux-image-2.6.32-5-sb1-bcm91250a 
linux-headers-2.6.32-5-sb1-bcm91250a linux-image-2.6.32-5-sb1a-bcm91480b 
linux-headers-2.6.32-5-sb1a-bcm91480b linux-image-2.6.32-5-4kc-malta 
linux-headers-2.6.32-5-4kc-malta linux-image-2.6.32-5-5kc-malta 
linux-headers-2.6.32-5-5kc-malta linux-headers-2.6.32-5-all-mipsel 
linux-image-2.6.32-5-r5k-cobalt linux-headers-2.6.32-5-r5k-cobalt 
linux-headers-2.6.32-5-all-powerpc linux-image-2.6.32-5-powerpc 
linux-headers-2.6.32-5-powerpc linux-image-2.6.32-5-powerpc-smp 
linux-headers-2.6.32-5-powerpc-smp linux-image-2.6.32-5-powerpc64 
linux-headers-2.6.32-5-powerpc64 linux-image-2.6.32-5-vserver-powerpc 
linux-headers-2.6.32-5-vserver-powerpc
 linux-image-2.6.32-5-vserver-powerpc64 
linux-headers-2.6.32-5-vserver-powerpc64 linux-headers-2.6.32-5-all-s390 
linux-image-2.6.32-5-s390x linux-headers-2.6.32-5-s390x 
linux-image-2.6.32-5-s390x-tape linux-image-2.6.32-5-vserver-s390x 
linux-headers-2.6.32-5-vserver-s390x linux-headers-2.6.32-5-all-sh4 
linux-image-2.6.32-5-sh7751r linux-headers-2.6.32-5-sh7751r 
linux-image-2.6.32-5-sh7785lcr linux-headers-2.6.32-5-sh7785lcr 
linux-headers-2.6.32-5-all-sparc linux-image-2.6.32-5-sparc64 
linux-headers-2.6.32-5-sparc64 linux-image-2.6.32-5-sparc64-smp 
linux-headers-2.6.32-5-sparc64-smp linux-image-2.6.32-5-vserver-sparc64 
linux-headers-2.6.32-5-vserver-sparc64
 linux-headers-2.6.32-5-all-sparc64
Architecture: all i386 source
Version: 2.6.32-48
Distribution: stable
Urgency: low
Maintainer: Debian Kernel Team debian-kernel@lists.debian.org
Changed-By: Ben Hutchings b...@decadent.org.uk
Closes: 698382 699112 700486
Description: 
 

Bug#700544: linux-image-2.6.32-5-amd64: Error in acpi_memory_enable_device on memory hotplug, one memory bank missing

2013-02-15 Thread Ben Hutchings
Control: tag -1 - moreinfo

On Fri, 2013-02-15 at 11:19 +0100, Bernhard Schmidt wrote:
 On 15.02.2013 04:16, Ben Hutchings wrote:
 
 Hello Ben,
 
  Please test a kernel with the attached patches, applied in the order:
  
  x86-PCI-for-debuggability-show-host-bridge-windows-e.patch
  x86-PCI-use-host-bridge-_CRS-info-by-default-on-2008.patch
  x86-PCI-Use-_CRS-by-default-on-VMware.patch
  
  and without adding the kernel parameter.
  
  This should result in a boot log message:
  
  PCI: Using host bridge windows from ACPI; if necessary, use pci=nocrs 
  and report a bug
  
  If VMware was not detected as I intended, then you'll see:
  
  PCI: Ignoring host bridge windows from ACPI; if necessary, use 
  pci=use_crs and report a bug
  
 
 Looks good, VMware is detected, together with the patch from #699913
 memory hotplugging works fine.

OK, these should be included in an update for squeeze.  (They just
missed 6.0.7, unfortunately.)

Ben.

-- 
Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer


signature.asc
Description: This is a digitally signed message part


Processed: Re: Bug#700544: linux-image-2.6.32-5-amd64: Error in acpi_memory_enable_device on memory hotplug, one memory bank missing

2013-02-15 Thread Debian Bug Tracking System
Processing control commands:

 tag -1 - moreinfo
Bug #700544 [linux-2.6] linux-image-2.6.32-5-amd64: Error in 
acpi_memory_enable_device on memory hotplug, one memory bank missing
Removed tag(s) moreinfo.

-- 
700544: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700544
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.b700544.136093432128227.transcr...@bugs.debian.org



Processed: tagging 700544

2013-02-15 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

 tags 700544 + pending
Bug #700544 [linux-2.6] linux-image-2.6.32-5-amd64: Error in 
acpi_memory_enable_device on memory hotplug, one memory bank missing
Added tag(s) pending.
 thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
700544: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700544
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.136093423827390.transcr...@bugs.debian.org



Bug#700629: firmware-iwlwifi: Microcode SW error detected

2013-02-15 Thread Vincent Blut
Package: firmware-iwlwifi
Version: 0.36+wheezy.1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I got the following firmware error with my wireless card:

02:00.0 Network controller [0280]: Intel Corporation Centrino Advanced-N
6235 [8086:088e] (rev 24)

However it seems to recover by itself (hence the normal severity) but caused a 
driver warning. 
Note that this error caused absolutely no harm to the connection which remains
stable, looking at statistics in '/sys/class/net/wlan0/' show no errors neither
in the reception nor in the transmission queue.

Sadly I can't find a way to reproduce it easily so debugging it might be
a nightmare!

This bug report might be merged with #550534.

[33286.921558] iwlwifi :02:00.0: Microcode SW error detected.
Restarting 0x200.
[33286.921570] iwlwifi :02:00.0: CSR values:
[33286.921576] iwlwifi :02:00.0: (2nd byte of CSR_INT_COALESCING is
CSR_INT_PERIODIC_REG)
[33286.921585] iwlwifi :02:00.0:CSR_HW_IF_CONFIG_REG:
0X00484b00
[33286.921594] iwlwifi :02:00.0:  CSR_INT_COALESCING:
0Xff40
[33286.921603] iwlwifi :02:00.0: CSR_INT:
0X
[33286.921611] iwlwifi :02:00.0:CSR_INT_MASK:
0X
[33286.921619] iwlwifi :02:00.0:   CSR_FH_INT_STATUS:
0X
[33286.921627] iwlwifi :02:00.0: CSR_GPIO_IN:
0X003c
[33286.921635] iwlwifi :02:00.0:   CSR_RESET:
0X
[33286.921643] iwlwifi :02:00.0:CSR_GP_CNTRL:
0X080403c5
[33286.921651] iwlwifi :02:00.0:  CSR_HW_REV:
0X00b0
[33286.921659] iwlwifi :02:00.0:  CSR_EEPROM_REG:
0X3d180ffd
[33286.921668] iwlwifi :02:00.0:   CSR_EEPROM_GP:
0X9801
[33286.921676] iwlwifi :02:00.0:  CSR_OTP_GP_REG:
0X00030001
[33286.921684] iwlwifi :02:00.0: CSR_GIO_REG:
0X00080044
[33286.921692] iwlwifi :02:00.0:CSR_GP_UCODE_REG:
0X3cee
[33286.921700] iwlwifi :02:00.0:   CSR_GP_DRIVER_REG:
0X
[33286.921708] iwlwifi :02:00.0:   CSR_UCODE_DRV_GP1:
0X
[33286.921716] iwlwifi :02:00.0:   CSR_UCODE_DRV_GP2:
0X
[33286.921723] iwlwifi :02:00.0: CSR_LED_REG:
0X0078
[33286.921731] iwlwifi :02:00.0:CSR_DRAM_INT_TBL_REG:
0X88118783
[33286.921739] iwlwifi :02:00.0:CSR_GIO_CHICKEN_BITS:
0X27800200
[33286.921747] iwlwifi :02:00.0: CSR_ANA_PLL_CFG:
0X
[33286.921754] iwlwifi :02:00.0:   CSR_HW_REV_WA_REG:
0X0001001a
[33286.921763] iwlwifi :02:00.0:CSR_DBG_HPET_MEM_REG:
0X
[33286.921767] iwlwifi :02:00.0: FH register values:
[33286.921786] iwlwifi :02:00.0:
FH_RSCSR_CHNL0_STTS_WPTR_REG: 0X117ca100
[33286.921803] iwlwifi :02:00.0:
FH_RSCSR_CHNL0_RBDCB_BASE_REG: 0X0117ca60
[33286.921820] iwlwifi :02:00.0:
FH_RSCSR_CHNL0_WPTR: 0X0028
[33286.921838] iwlwifi :02:00.0:
FH_MEM_RCSR_CHNL0_CONFIG_REG: 0X80811104
[33286.921855] iwlwifi :02:00.0:
FH_MEM_RSSR_SHARED_CTRL_REG: 0X00fc
[33286.921882] iwlwifi :02:00.0:
FH_MEM_RSSR_RX_STATUS_REG: 0X0703
[33286.921900] iwlwifi :02:00.0:
FH_MEM_RSSR_RX_ENABLE_ERR_IRQ2DRV: 0X
[33286.921918] iwlwifi :02:00.0:
FH_TSSR_TX_STATUS_REG: 0X07ff0001
[33286.921935] iwlwifi :02:00.0:
FH_TSSR_TX_ERROR_REG: 0X
[33286.921941] iwlwifi :02:00.0: Loaded firmware version: 18.168.6.1
[33286.922067] iwlwifi :02:00.0: Start IWL Error Log Dump:
[33286.922074] iwlwifi :02:00.0: Status: 0x02CC, count: 6
[33286.922084] iwlwifi :02:00.0: 0x198A | ADVANCED_SYSASSERT  
[33286.922092] iwlwifi :02:00.0: 0x00015920 | uPc
[33286.922102] iwlwifi :02:00.0: 0x00015910 | branchlink1
[33286.922107] iwlwifi :02:00.0: 0x00015910 | branchlink2
[33286.922112] iwlwifi :02:00.0: 0xDBEA | interruptlink1
[33286.922116] iwlwifi :02:00.0: 0x | interruptlink2
[33286.922121] iwlwifi :02:00.0: 0x000150DC | data1
[33286.922126] iwlwifi :02:00.0: 0x0001 | data2
[33286.922130] iwlwifi :02:00.0: 0x01DC | line
[33286.922135] iwlwifi :02:00.0: 0x4300A757 | beacon time
[33286.922140] iwlwifi :02:00.0: 0x153798A9 | tsf low
[33286.922144] iwlwifi :02:00.0: 0x0009 | tsf hi
[33286.922149] iwlwifi :02:00.0: 0x | time gp1
[33286.922154] iwlwifi :02:00.0: 0x60EA0C2F | time gp2
[33286.922158] iwlwifi :02:00.0: 0x | time gp3
[33286.922163] iwlwifi :02:00.0: 0x754312A8 | uCode version
[33286.922168] iwlwifi :02:00.0: 0x00B0 | hw version
[33286.922173] iwlwifi :02:00.0: 0x00484B00 | board version
[33286.922177] iwlwifi :02:00.0: 0x001C | hcmd
[33286.922182] iwlwifi :02:00.0: 0xAF863840 | isr0
[33286.922186] iwlwifi :02:00.0: 0x11C9F800 | isr1
[33286.922191] iwlwifi :02:00.0: 0x0F1A | isr2
[33286.922196] iwlwifi 

Processing of linux_3.7.8-1~experimental.1_multi.changes

2013-02-15 Thread Debian FTP Masters
linux_3.7.8-1~experimental.1_multi.changes uploaded successfully to localhost
along with the files:
  linux_3.7.8-1~experimental.1.dsc
  linux_3.7.8.orig.tar.xz
  linux_3.7.8-1~experimental.1.debian.tar.xz
  linux-doc-3.7_3.7.8-1~experimental.1_all.deb
  linux-manual-3.7_3.7.8-1~experimental.1_all.deb
  linux-source-3.7_3.7.8-1~experimental.1_all.deb
  linux-support-3.7-trunk_3.7.8-1~experimental.1_all.deb

Greetings,

Your Debian queue daemon (running on host franck.debian.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/e1u6nlc-0007c0...@franck.debian.org



Bug#700513: linux-base: Cannot resume after suspending (laptop model HP CQ61 410SH)

2013-02-15 Thread Daniel
On Thu, Feb 14, 2013 at 9:25 PM, Ben Hutchings b...@decadent.org.uk wrote:

 On Thu, 2013-02-14 at 08:27 -0600, Daniel wrote:
 
 
 
  On Wed, Feb 13, 2013 at 11:28 PM, Ben Hutchings b...@decadent.org.uk
  wrote:
  Control: tag -1 moreinfo
 
  On Wed, 2013-02-13 at 11:59 -0600, ddshore wrote:
   Package: linux-base
   Version: 3.4~bpo60+1
   Severity: normal
  
   After suspending the laptop, and attempting to resume, I get
  a black screen
   with the power and wifi icons turned on.  I have tried using
  different versions
   of the Linux Kernel,
 
 
  Which versions?
 
 
  2.6.32-5-686 and 3.2.0.0.bpo.4-rt-686-pae

 Could you also try 3.7-trunk-686-pae, from the experimental suite?

How can I install an experimental Linux on squeeze, you want me to do the
backport myself?


   adding pci=nocrs, acp_osi=Microsoft Windows NT,
   acp_osi=Linux, apm=off (since apparently my laptop uses both
  acpi and apm),
   acpi=off, but they have the same effect.
 
 
  I very much doubt that this laptop supports APM, as that's
  been obsolete
  for 10 years!
 
  So did the people at #linux, but apparently, they got this information
  from my dmesg (which was attached in my previous email).  I also get
  error messages saying apm: BIOS not found.

 That error message means that the kernel supports APM but the BIOS
 doesn't!

  As for ACPI, turning it off is generally a bad idea (as you've
  seen!)
  but the advice to 'try acpi=off' is still lingering among
  long-time
  Linux users.
 
  Right.  They told me the same thing, but wanted to see if anything
  happened at all.
  [...]
   This bug was also filed for ubuntu, but was never solved
  
  (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/675076).
 
  [...]
 
  And that was quite a few versions back, so evidently this is
  not a new
  problem.
 
  Yes, and I've seen some other people with the same problem.  Should I
  try getting more info on this problem? Would additional log files
  help?

 Try going through section 1(a) 'Test modes of hibernation' in:
 http://www.kernel.org/doc/Documentation/power/basic-pm-debugging.txt
 but instead of writing 'disk' to /sys/power/state, write 'mem'.

 That should help to work out where this is going wrong.

 Thanks, running these tests later today and will report the results.

 Ben.

 --
 Ben Hutchings
 Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer



Cannot compile kernel: problem with EXPORT_SYMBOL and EXPORT_SYMBOL_GPL symbols

2013-02-15 Thread Dmitry Katsubo
Dear Debian community,

I am trying to recompile default kernel with one just option changed:

-CONFIG_NR_CPUS=32
+CONFIG_NR_CPUS=4

I get problems with symbols on all modules (the error log is really long):

   LD [M]  sound/usb/usx2y/snd-usb-usx2y.ko
 make[2]: Leaving directory 
 `/home/dmitry/packages/kernel/linux-3.2.35/debian/build/build_i386_none_686-pae'
 python debian/bin/buildcheck.py debian/build/build_i386_none_686-pae i386 
 none 686-pae
 ABI has changed!  Refusing to continue.

 Added symbols:
 bprm_change_interp   module: vmlinux, version: 
 0x73a5ca09, export: EXPORT_SYMBOL
 ieee80211_get_mesh_hdrlenmodule: 
 net/wireless/cfg80211, version: 0xa197b1ff, export: EXPORT_SYMBOL
 kernel_stack_pointer module: vmlinux, version: 
 0x79a71c48, export: EXPORT_SYMBOL_GPL
 snd_card_unref   module: sound/core/snd, 
 version: 0x549e0966, export: EXPORT_SYMBOL
 
 Changed symbols:
 DAC1064_global_init  module: 
 drivers/video/matrox/matroxfb_DAC1064, version: 0x8a6c84a0 - 0x145d0e0b, 
 export: EXPORT_SYMBOL
 ...

How can I overcome this problem? Thanks in advance.

P.S.

There are many reports on similar problem in this maillist, but the the
ones I have looked through are connected with additional patches
applied. In my case there are extra patches: kernel package is used as
provided in repository, I just want to tune the config.

* Linux kernel 3.2.0-4, sources are installed with standard
  apt-get source linux-image-3.2.0-4-686-pae
* After all preparations, kernel was build for one target with
  fakeroot make -f debian/rules.gen binary-arch_i386_none_686-pae
* Kernel compiles OK with default config.

-- 
With best regards,
Dmitry


-- 
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/511e7dba.1020...@gmail.com



Bug#700513: linux-base: Cannot resume after suspending (laptop model HP CQ61 410SH)

2013-02-15 Thread Ben Hutchings
On Fri, Feb 15, 2013 at 10:43:09AM -0600, Daniel wrote:
 On Thu, Feb 14, 2013 at 9:25 PM, Ben Hutchings b...@decadent.org.uk wrote:
 
  On Thu, 2013-02-14 at 08:27 -0600, Daniel wrote:
  
  
  
   On Wed, Feb 13, 2013 at 11:28 PM, Ben Hutchings b...@decadent.org.uk
   wrote:
   Control: tag -1 moreinfo
  
   On Wed, 2013-02-13 at 11:59 -0600, ddshore wrote:
Package: linux-base
Version: 3.4~bpo60+1
Severity: normal
   
After suspending the laptop, and attempting to resume, I get
   a black screen
with the power and wifi icons turned on.  I have tried using
   different versions
of the Linux Kernel,
  
  
   Which versions?
  
  
   2.6.32-5-686 and 3.2.0.0.bpo.4-rt-686-pae
 
  Could you also try 3.7-trunk-686-pae, from the experimental suite?
 
 How can I install an experimental Linux on squeeze, you want me to do the
 backport myself?
[...]

Since you have installed linux-image-3.2.0.0.bpo.4-rt-686-pae, you
already have all the dependencies of linux-image-3.7-trunk-686-pae.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
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/20130215192815.ga9...@decadent.org.uk



Re: Cannot compile kernel: problem with EXPORT_SYMBOL and EXPORT_SYMBOL_GPL symbols

2013-02-15 Thread Ben Hutchings
On Fri, Feb 15, 2013 at 07:26:02PM +0100, Dmitry Katsubo wrote:
 Dear Debian community,
 
 I am trying to recompile default kernel with one just option changed:
 
 -CONFIG_NR_CPUS=32
 +CONFIG_NR_CPUS=4

Why?

 I get problems with symbols on all modules (the error log is really long):

Yes, because you changed the kernel module ABI without changing
the binary package name.

[...]
 How can I overcome this problem? Thanks in advance.
[...]
 
If you really think it's worth doing this (and you really want to
use the official package as a basic, rather than 'make deb-pkg'), you
have two basic options:

1. Add a distinguishing string after the ABI number in
debian/config/defines.  Please do not just change it to 5 as this
could be confused with an official package name.

2. Define a new 'flavour' with this configuration change.  Each
flavour has its own ABI.  You'll need to edit
debian/config/i386/defines to add the flavour name and define
it to use an extra configuration file which overrides
CONFIG_NR_CPUS.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
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/20130215194036.gb9...@decadent.org.uk



Bug#700333: Anyone?

2013-02-15 Thread vitalif

Anyone?

The bug still persists in 3.7.8-1~experimental.1.


--
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/6cab98d3f95e5927ce5ba43edb197...@yourcmc.ru



Bug#697548: same problem with another PC

2013-02-15 Thread gpe

Hi,

I've the same problem with another PC based on an ASUS P8P67-LE motherboard
and A Core i5-2500k.

Regards,

gpe


-- 
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/20130216024121.e94a43212b389ea6207ff...@free.fr



Bug#519586: Huge Slab Unreclaimable and continually growing

2013-02-15 Thread Ben Hutchings
On Fri, 2013-02-15 at 08:56 +0100, Josip Rodin wrote:
  I appear to be experiencing a serious problem with a 768 MB RAM Xen domU
  machine running an NFS client - every now and then (for months now), often
  in the middle of the night, it enters some kind of a broken state where a
  few semi-random processes (mainly apache2's and vsftpd's which are told to
  serve files from the NFS mount)
[...]
 I caught it earlier just now, at:
 
 [950084.590733] active_anon:2805 inactive_anon:11835 isolated_anon:0
 [950084.590735]  active_file:76 inactive_file:516 isolated_file:32
 [950084.590737]  unevictable:783 dirty:1 writeback:0 unstable:0
 [950084.590739]  free:26251 slab_reclaimable:15733 slab_unreclaimable:128868
 [950084.590741]  mapped:938 shmem:75 pagetables:651 bounce:0
 
 And snuck in a few slabtops (even some -o invocations were getting killed,
 along with my shell and pretty much everything else):
[...]
  65390  65390 100%2.06K  13338   15426816K net_namespace
[...]

Looks like CVE-2011-2189, for which there was a fix/workaround in:

vsftpd (2.3.2-3+squeeze2) stable-security; urgency=high

   * Non-maintainer upload by the Security Team.
   * Disable network isolation due to a problem with cleaning up network
 namespaces fast enough in kernels  2.6.35 (CVE-2011-2189).
 Thanks Ben Hutchings for the patch!
   * Fix possible DoS via globa expressions in STAT commands by
 limiting the matching loop (CVE-2011-0762; Closes: #622741).

 -- Nico Golde n...@debian.org  Wed, 07 Sep 2011 20:39:59 +

Do you have an old version of vsftpd, or perhaps an upstream version
which doesn't include the workaround?

Anyway, I'm closing the bug report; please don't hijack closed bugs.

Ben.

-- 
Ben Hutchings
Computers are not intelligent.  They only think they are.


signature.asc
Description: This is a digitally signed message part


Processed: closing 519586

2013-02-15 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

 close 519586
Bug #519586 [linux-image-2.6.32-5-xen-amd64] huge slab_unreclaimable in Xen domU
Marked Bug as done
 thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
519586: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=519586
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.136098440429813.transcr...@bugs.debian.org