Bug#695182: [RFC] Reproducible OOM with just a few sleeps
On 01/14/2013 11:00 PM, Dave Hansen wrote: On 01/11/2013 07:31 PM, paul.sz...@sydney.edu.au wrote: Seems that any i386 PAE machine will go OOM just by running a few processes. To reproduce: sh -c 'n=0; while [ $n -lt 1 ]; do sleep 600 ((n=n+1)); done' My machine has 64GB RAM. With previous OOM episodes, it seemed that running (booting) it with mem=32G might avoid OOM; but an OOM was obtained just the same, and also with lower memory: Memorysleeps to OOM free shows total (mem=64G) 5300 64447796 mem=32G 10200 31155512 mem=16G 13400 14509364 mem=8G14200 6186296 mem=6G15200 4105532 mem=4G16400 2041364 The machine does not run out of highmem, nor does it use any swap. I think what you're seeing here is that, as the amount of total memory increases, the amount of lowmem available _decreases_ due to inflation of mem_map[] (and a few other more minor things). The number of sleeps So if he config sparse memory, the issue can be solved I think. you can do is bound by the number of processes, as you noticed from ulimit. Creating processes that don't use much memory eats a relatively large amount of low memory. This is a sad (and counterintuitive) fact: more RAM actually *CREATES* RAM bottlenecks on 32-bit systems. On my large machine, 'free' fails to show about 2GB memory, e.g. with mem=16G it shows: root@zeno:~# free -l total used free sharedbuffers cached Mem: 14509364 435440 14073924 0 4068 111328 Low:769044 120232 648812 High: 13740320 315208 13425112 -/+ buffers/cache: 320044 14189320 Swap:134217724 0 134217724 You probably have a memory hole. mem=16G means give me all the memory below the physical address at 16GB. It does *NOT* mean, give me enough memory such that 'free' will show ~16G available. If you have a 1.5GB hole below 16GB, and you do mem=16G, you'll end up with ~14.5GB available. The e820 map (during early boot in dmesg) or /proc/iomem will let you locate your memory holes. Dear Dave, two questions here: 1) e820 map is read from BIOS, correct? So if all kinds of ranges dump from /proc/iomem are setup by BIOS? 2) only System RAM range dump from /proc/iomem can be treated as real memory, all other ranges can be treated as holes, correct? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majord...@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a -- 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/51209e9c.3020...@gmail.com
Re: Cannot compile kernel: problem with EXPORT_SYMBOL and EXPORT_SYMBOL_GPL symbols
On 15.02.2013 20:40, Ben Hutchings wrote: -CONFIG_NR_CPUS=32 +CONFIG_NR_CPUS=2 Why? Well, it turned out that 686-pae kernel from repository does not boot on my PC: kernel hangs during initialization. 486 is booting OK. Recompilation for the native CPU was the last measure. If I am already playing with recompilation, why not to reduce the number of CPUs (as to help, that is saving 30 * 8Kb = 240Kb). Yes, because you changed the kernel module ABI without changing the binary package name. Interesting is that I have also changed few other options: CONFIG_X86_GENERIC=n CONFIG_MICROCODE_INTEL=n CONFIG_MICROCODE_AMD=n CONFIG_PREEMPT_NONE=y and it looks like this did not change ABI. That puzzled me. 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. I have changed the string to 4fix and I have overwritten the configuration with custom one: $ cp ../myconfig debian/config/kernelarch-x86/config-arch-32 After that it worked smoothly. Thanks! -- 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/5120ea30.8040...@gmail.com
Re: 6.0.7 planning
On Fri, 2013-02-15 at 11:32 +, Adam D. Barratt wrote: 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. All the builds are now in, so we should be ready for lkdi updates when convenient. I gather there's a chance there might need to be further security updates; will that mean we need another update in p-u? 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/1361114044.20472.76.ca...@jacala.jungle.funky-badger.org
Re: Cannot compile kernel: problem with EXPORT_SYMBOL and EXPORT_SYMBOL_GPL symbols
On Sun, 2013-02-17 at 15:33 +0100, Dmitry Katsubo wrote: On 15.02.2013 20:40, Ben Hutchings wrote: -CONFIG_NR_CPUS=32 +CONFIG_NR_CPUS=2 Why? Well, it turned out that 686-pae kernel from repository does not boot on my PC: kernel hangs during initialization. 486 is booting OK. Recompilation for the native CPU was the last measure. If I am already playing with recompilation, why not to reduce the number of CPUs (as to help, that is saving 30 * 8Kb = 240Kb). Yes, because you changed the kernel module ABI without changing the binary package name. Interesting is that I have also changed few other options: CONFIG_X86_GENERIC=n CONFIG_MICROCODE_INTEL=n CONFIG_MICROCODE_AMD=n CONFIG_PREEMPT_NONE=y and it looks like this did not change ABI. That puzzled me. Changing CONFIG_NR_CPUS changes the size of objects in memory, which modules may depend on, whereas the others don't. (But turning off CONFIG_X86_GENERIC probably ought to be considered as changing ABI.) 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. I have changed the string to 4fix and I have overwritten the configuration with custom one: $ cp ../myconfig debian/config/kernelarch-x86/config-arch-32 After that it worked smoothly. Thanks! Please can you send the complete configuration file and the contents of /proc/cpuinfo? Ben. -- Ben Hutchings Experience is what causes a person to make new mistakes instead of old ones. signature.asc Description: This is a digitally signed message part
Bug#700466: Update: seems to be kernel 3.2.0-0.bpo.4-686-pae
Hi, After furtherv testing with the old firmware version, I wasn't able to connect with kernel 3.2.0-0.bpo.4-686-pae at all. 3.2.0-0.bpo.3-686-pae works (at least with the old firmware version). How can I test further what's wrong here? Best wishes Michael -- 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/512138c1.3070...@schokokeks.org
Re: linux-image-rt AUFS support
On Wed, Feb 13, 2013 at 06:07:52PM -0300, Victor Rosales wrote: That is great news, I'll try that. I did on the sid branch, and it builds just fine. I don't know how to test though. And I'm not sure adding aufs to the rt featureset is worth the effort of talking to the release management and asking for a freeze exception. Still more as (AFAIK) there are no plans to offer an offical rt live image. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- 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/20130217211955.gb32...@pengutronix.de
Re: 6.0.7 planning
On Sun, Feb 17, 2013 at 03:14:04PM +, Adam D. Barratt wrote: On Fri, 2013-02-15 at 11:32 +, Adam D. Barratt wrote: 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. All the builds are now in, so we should be ready for lkdi updates when convenient. I gather there's a chance there might need to be further security updates; will that mean we need another update in p-u? Possibly; an alternative would be to release a 48squeeze1 via security to sync up w/ the fixes just before the point release. That would let us go ahead and get the lkdi/d-i updates ready and give us some flexibility to react to any follow-on changes that may appear this week as CVE-2013-0871 is discussed. On the other hand, I know Ben has another fix queued for stable, and I saw a mention of a possible s390/KVM regression - so those may justify the extra p-u update. Thoughts? -- 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/20130217213323.gg18...@dannf.org
Re: 6.0.7 planning
On Sun, 2013-02-17 at 13:33 -0800, dann frazier wrote: On Sun, Feb 17, 2013 at 03:14:04PM +, Adam D. Barratt wrote: I gather there's a chance there might need to be further security updates; will that mean we need another update in p-u? Possibly; an alternative would be to release a 48squeeze1 via security to sync up w/ the fixes just before the point release. That would let us go ahead and get the lkdi/d-i updates ready and give us some flexibility to react to any follow-on changes that may appear this week as CVE-2013-0871 is discussed. From the release perspective, I obviously have a bias toward wanting to get a finalised kernel and lkdi / d-i sorted sooner rather than later, both so we can get people to test the former and to reduce the likelihood of last minute issues / upload chasing with the latter. On the other hand, I know Ben has another fix queued for stable, and I saw a mention of a possible s390/KVM regression - so those may justify the extra p-u update. Are these regressions from the current stable kernel? 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/1361140954.20472.122.ca...@jacala.jungle.funky-badger.org
Re: 6.0.7 planning
On Sun, 2013-02-17 at 13:33 -0800, dann frazier wrote: On Sun, Feb 17, 2013 at 03:14:04PM +, Adam D. Barratt wrote: On Fri, 2013-02-15 at 11:32 +, Adam D. Barratt wrote: 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. All the builds are now in, so we should be ready for lkdi updates when convenient. I gather there's a chance there might need to be further security updates; will that mean we need another update in p-u? Possibly; an alternative would be to release a 48squeeze1 via security to sync up w/ the fixes just before the point release. That would let us go ahead and get the lkdi/d-i updates ready and give us some flexibility to react to any follow-on changes that may appear this week as CVE-2013-0871 is discussed. On the other hand, I know Ben has another fix queued for stable, and I saw a mention of a possible s390/KVM regression - so those may justify the extra p-u update. Thoughts? I would prefer to give users the option to install just the urgent security fixes and delay upgrading to the point release. Releasing a 48squeeze1 means bundling together all those changes. I don't think it's critical that the installer has the same kernel version as the stable suite. We do need to be careful with ordering of the changelog to allow the installer kernel version to be constructed from the later version by running debian/bin/patch.apply, and/or ask the FTP team nicely to ensure the older version remains in squeeze. Ben. -- Ben Hutchings Experience is what causes a person to make new mistakes instead of old ones. signature.asc Description: This is a digitally signed message part
Bug#700826: please add ar5523.bin to firmware-atheros
Package: firmware-atheros Version: 0.37 Severity: wishlist Tags: experimental Hi The ar5523 kernel module (USB 2.0 wlan card, IEEE802.11G/ Turbo G) has been merged into kernel 3.8, therefore it would be nice to have its firmware available too. The license follows the one used for the existing QCA Atheros firmware images and should be freely redistributable: Copyright (c) 2008-2010, Atheros Communications, Inc. All rights reserved. Redistribution. Redistribution and use in binary form, without modification, are permitted provided that the following conditions are met: * Redistributions must reproduce the above copyright notice and the following disclaimer in the documentation and/or other materials provided with the distribution. * Neither the name of Atheros Communications, Inc. nor the names of its suppliers may be used to endorse or promote products derived from this software without specific prior written permission. * No reverse engineering, decompilation, or disassembly of this software is permitted. Limited patent license. Atheros Communications, Inc. grants a world-wide, royalty-free, non-exclusive license under patents it now or hereafter owns or controls to make, have made, use, import, offer to sell and sell (Utilize) this software, but solely to the extent that any such patent is necessary to Utilize the software in conjunction with an Atheros Chipset. The patent license shall not apply to any other combinations which include this software. No hardware per se is licensed hereunder. DISCLAIMER. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. The firmware image is available from upstream linux-firmware.git and I have successfully tested it with ar5523.ko in v3.8(-rc7-93-gf741656). $ md5sum -b /lib/firmware/ar5523.bin 78fe4478dca9134c028e7507421b3f6a */lib/firmware/ar5523.bin [ 2209.669039] usb 2-7: new high-speed USB device number 3 using ehci-pci [ 2209.784545] usb 2-7: New USB device found, idVendor=1385, idProduct=4251 [ 2209.784556] usb 2-7: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 2209.784563] usb 2-7: Product: WG111T [ 2209.784570] usb 2-7: Manufacturer: Atheros Communications Inc [ 2209.784575] usb 2-7: SerialNumber: 1.0 [ 2209.939904] usbcore: registered new interface driver ar5523 [ 2210.088330] usb 2-7: USB disconnect, device number 3 [ 2210.320040] usb 2-7: new high-speed USB device number 4 using ehci-pci [ 2210.435278] usb 2-7: New USB device found, idVendor=1385, idProduct=4250 [ 2210.435287] usb 2-7: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 2210.435295] usb 2-7: Product: WG111T [ 2210.435301] usb 2-7: Manufacturer: Atheros Communications Inc [ 2210.435307] usb 2-7: SerialNumber: 1.0 [ 2210.483029] usb 2-7: Cap: CAP_TARGET_VERSION=0x0006 [ 2210.483393] usb 2-7: Cap: CAP_TARGET_REVISION=0x0001 [ 2210.483643] usb 2-7: Cap: CAP_MAC_VERSION=0x0008 [ 2210.484056] usb 2-7: Cap: CAP_MAC_REVISION=0x0001 [ 2210.484406] usb 2-7: Cap: CAP_PHY_REVISION=0x0046 [ 2210.484644] usb 2-7: Cap: CAP_ANALOG_5GHz_REVISION=0x0046 [ 2210.485045] usb 2-7: Cap: CAP_ANALOG_2GHz_REVISION=0x [ 2210.485405] usb 2-7: Cap: CAP_REG_DOMAIN=0x [ 2210.485767] usb 2-7: Cap: CAP_REG_CAP_BITS=0x [ 2210.486055] usb 2-7: Cap: CAP_WIRELESS_MODES=0x [ 2210.486406] usb 2-7: Cap: CAP_CHAN_SPREAD_SUPPORT=0x001c [ 2210.486643] usb 2-7: Cap: CAP_COMPRESS_SUPPORT=0x0001 [ 2210.487045] usb 2-7: Cap: CAP_BURST_SUPPORT=0x0001 [ 2210.487403] usb 2-7: Cap: CAP_FAST_FRAMES_SUPPORT=0x0001 [ 2210.487767] usb 2-7: Cap: CAP_CHAP_TUNING_SUPPORT=0x0001 [ 2210.488048] usb 2-7: Cap: CAP_TURBOG_SUPPORT=0x0001 [ 2210.488403] usb 2-7: Cap: CAP_TURBO_PRIME_SUPPORT=0x0001 [ 2210.488643] usb 2-7: Cap: CAP_DEVICE_TYPE=0x0001 [ 2210.489050] usb 2-7: Cap: CAP_WME_SUPPORT=0x0001 [ 2210.489402] usb 2-7: Cap: CAP_TOTAL_QUEUES=0x0001 [ 2210.489643] usb 2-7: Cap: CAP_CONNECTION_ID_MAX=0x000a [ 2210.490045] usb 2-7: Cap: CAP_LOW_5GHZ_CHAN=0x0004 [ 2210.490402] usb 2-7: Cap: CAP_HIGH_5GHZ_CHAN=0x1338 [ 2210.490769] usb 2-7: Cap: CAP_LOW_2GHZ_CHAN=0x17d4 [ 2210.491045] usb 2-7: Cap: CAP_HIGH_2GHZ_CHAN=0x0908 [
Re: 6.0.7 planning
On Sun, Feb 17, 2013 at 11:12:18PM +, Ben Hutchings wrote: On Sun, 2013-02-17 at 13:33 -0800, dann frazier wrote: On Sun, Feb 17, 2013 at 03:14:04PM +, Adam D. Barratt wrote: On Fri, 2013-02-15 at 11:32 +, Adam D. Barratt wrote: 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. All the builds are now in, so we should be ready for lkdi updates when convenient. I gather there's a chance there might need to be further security updates; will that mean we need another update in p-u? Possibly; an alternative would be to release a 48squeeze1 via security to sync up w/ the fixes just before the point release. That would let us go ahead and get the lkdi/d-i updates ready and give us some flexibility to react to any follow-on changes that may appear this week as CVE-2013-0871 is discussed. On the other hand, I know Ben has another fix queued for stable, and I saw a mention of a possible s390/KVM regression - so those may justify the extra p-u update. Thoughts? I would prefer to give users the option to install just the urgent security fixes and delay upgrading to the point release. Releasing a 48squeeze1 means bundling together all those changes. Agreed; and I think I was unclear. I was taking for granted that we *will* do a 46squeeze2 now w/ the CVE-2013-0871 fix and bypass 46squeeze1. 46squeeze2 would provide the security-only option. The question was whether or not we should try and fix p-u by getting a -49 into -stable now w/ the CVE-2013-0871 fix, or just make sure there's a 48squeeze1 in security for after. Ah - but maybe the point you're making is that a 48squeeze1 in security would make 46squeeze2 harder to find/install - if so, I can understand that point. I don't think it's critical that the installer has the same kernel version as the stable suite. We do need to be careful with ordering of the changelog to allow the installer kernel version to be constructed from the later version by running debian/bin/patch.apply, and/or ask the FTP team nicely to ensure the older version remains in squeeze. Ordering it properly shouldn't be a problem. -- 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/20130217233634.gh18...@dannf.org
Re: 6.0.7 planning
On Sun, 2013-02-17 at 22:42 +, Adam D. Barratt wrote: On Sun, 2013-02-17 at 13:33 -0800, dann frazier wrote: On Sun, Feb 17, 2013 at 03:14:04PM +, Adam D. Barratt wrote: I gather there's a chance there might need to be further security updates; will that mean we need another update in p-u? Possibly; an alternative would be to release a 48squeeze1 via security to sync up w/ the fixes just before the point release. That would let us go ahead and get the lkdi/d-i updates ready and give us some flexibility to react to any follow-on changes that may appear this week as CVE-2013-0871 is discussed. From the release perspective, I obviously have a bias toward wanting to get a finalised kernel and lkdi / d-i sorted sooner rather than later, both so we can get people to test the former and to reduce the likelihood of last minute issues / upload chasing with the latter. On the other hand, I know Ben has another fix queued for stable, and I saw a mention of a possible s390/KVM regression - so those may justify the extra p-u update. Are these regressions from the current stable kernel? The s390/KVM issue is a possible regression introduced in -48. I don't have confirmation that this affects the Debian build, but it was reported upstream as caused by the fix we cherry-picked for #698382. The fix for the regression is labelled as being for v3.3+, but I don't see any relevant changes between 3.2 and 3.3 so I don't trust that minimum version. But the code it touches looks substantially different in 2.6.32. Who can test this? The other bug for which there is a pending fix (#700544) is not a regression and is easy to work around. Ben. -- Ben Hutchings Sturgeon's Law: Ninety percent of everything is crap. signature.asc Description: This is a digitally signed message part
Uploading linux (3.2.39-1)
Now that d-i rc1 is out, it's time to update the kernel in unstable. There are a huge number of pending fixes from 3.2.y (including security issues and the Samsung laptop brick bug), lots of new hardware support (particularly the DRM update), and udeb updates for armhf and for HID drivers. The curent changelog entry is below. I expect to release 3.2.39 on Tuesday, having started the review cycle this evening. This should include fixes for CVE-2013-0216, CVE-2013-0217, CVE-2013-0228 and CVE-2013-0871. Would it be OK to upload a package based on that shortly after? Are there any other urgent fixes? Ben. --- linux (3.2.38-1) UNRELEASED; urgency=low * New upstream stable update: http://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.2.36 - freezer: PF_FREEZER_NOSIG should be cleared along with PF_NOFREEZE (Closes: #697077) - tmpfs: fix shared mempolicy leak - virtio: 9p: correctly pass physical address to userspace for high pages - virtio: force vring descriptors to be allocated from lowmem - USB: EHCI: bugfix: urb-hcpriv should not be NULL - rcu: Fix batch-limit size problem - Bluetooth: ath3k: Add support for VAIO VPCEH [0489:e027] (Closes: #700550) - mvsas: fix undefined bit shift - ALSA: usb-audio: Avoid autopm calls after disconnection; Fix missing autopm for MIDI input (Closes: #664068) - target/file: Fix 32-bit highmem breakage for SGL - iovec mapping - SCSI: fix Null pointer dereference on disk error - proc: pid/status: show all supplementary groups - nfsd4: fix oops on unusual readlike compound - ARM: missing -mmap_sem around find_vma() in swp_emulate.c - sctp: fix memory leak in sctp_datamsg_from_user() when copy from user space fails - ne2000: add the right platform device - irda: sir_dev: Fix copy/paste typo - ipv4: ip_check_defrag must not modify skb before unsharing - telephony: ijx: buffer overflow in ixj_write_cid() - udf: fix memory leak while allocating blocks during write http://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.2.37 - ext4: fix extent tree corruption caused by hole punch - jbd2: fix assertion failure in jbd2_journal_flush() - tmpfs mempolicy: fix /proc/mounts corrupting memory - sparc: huge_ptep_set_* functions need to call set_huge_pte_at() - inet: Fix kmemleak in tcp_v4/6_syn_recv_sock and dccp_v4/6_request_recv_sock - net: sched: integer overflow fix - tcp: implement RFC 5961 3.2 - tcp: implement RFC 5961 4.2 - tcp: refine SYN handling in tcp_validate_incoming - tcp: tcp_replace_ts_recent() should not be called from tcp_validate_incoming() - tcp: RFC 5961 5.2 Blind Data Injection Attack Mitigation - RDMA/nes: Fix for crash when registering zero length MR for CQ - ACPI : do not use Lid and Sleep button for S5 wakeup http://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.2.38 - staging: comedi: comedi_test: fix race when cancelling command - mm: use aligned zone start for pfn_to_bitidx calculation - [s390] s390/time: fix sched_clock() overflow (Closes: #698382) - [i386] xen: Fix stack corruption in xen_failsafe_callback for 32bit PVOPS guests. (CVE-2013-0190) - KVM: PPC: Emulate dcbf - evm: checking if removexattr is not a NULL - ath9k_htc: Fix memory leak - ath9k: do not link receive buffers during flush - ath9k: fix double-free bug on beacon generate failure - x86/msr: Add capabilities check - can: c_can: fix invalid error codes - can: ti_hecc: fix invalid error codes - can: pch_can: fix invalid error codes - smp: Fix SMP function call empty cpu mask race - xfs: Fix possible use-after-free with AIO - EDAC: Test correct variable in -store function - samsung-laptop: Disable on EFI hardware, to avoid damaging it - NFS: Don't silently fail setattr() requests on mountpoints - intel-iommu: Prevent devices with RMRRs from being placed into SI Domain - ALSA: usb-audio: Fix regression by disconnection-race-fix patch (Closes: #696321) - printk: fix buffer overflow when calling log_prefix function from call_console_drivers [ Ben Hutchings ] * Input: wacom - fix touch support for Bamboo Fun CTH-461 * media/rc: Add iguanair driver from Linux 3.7 (Closes: #696925) * rt2800: add chipset revision RT5390R support (Closes: #696592) * [armhf/mx5] mtd: Enable MTD_BLOCK as module * [armhf/mx5] udeb: Add missing storage drivers (Closes: #697128) - Add ata-modules including libata, pata-modules including pata_imx, sata-modules including ahci_platform - Add sdhci-esdhc-imx to mmc-modules - Add mtd-modules including mtd, mtdblock and m25p80 * [armhf] udeb: Fix network driver selection - [armhf/mx5] Remove nic-modules - [armhf/vexpress] Add usb-modules - Add standard set of USB drivers to nic-usb-modules - Add nic-wireless-modules * be2net: Apply
Processed: Re: linux-base: Cannot resume after suspending (laptop model HP CQ61 410SH)
Processing commands for cont...@bugs.debian.org: tags 700513 - moreinfo Bug #700513 [src:linux] linux-base: Cannot resume after suspending (laptop model HP CQ61 410SH) Removed tag(s) moreinfo. End of message, stopping processing here. Please contact me if you need assistance. -- 700513: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700513 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.13611532331362.transcr...@bugs.debian.org
