Bug#987851: linux-version sort: argv and stdin behaviors differ
Package: linux-base
Version: 4.6
Severity: normal
Tags: patch
Using argv:
$ linux-version sort 5.8.0-50-generic 5.8.0-50-generic-64k
5.8.0-50-generic
5.8.0-50-generic-64k
Using stdin:
$ cat versions.txt
5.8.0-50-generic
5.8.0-50-generic-64k
$ cat versions.txt | linux-version sort
5.8.0-50-generic-64k
5.8.0-50-generic
It seems the trailing "\n" is unexpectedly being used in the comparison.
Now, perl and I have never really gotten along, but this patch seems to work:
--- /usr/bin/linux-version.orig 2020-06-25 17:23:24.0 +
+++ /usr/bin/linux-version 2021-04-30 20:39:13.708560573 +
@@ -70,7 +70,7 @@
@versions = map({[$_, "\n"]} @_);
} else {
while () {
- /^([^ ]*)(.*\n?)$/ or die;
+ /^([^ \n]*)(.*\n?)$/ or die;
push @versions, [$1, $2];
}
}
-- System Information:
Debian Release: 11.0
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-5-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages linux-base depends on:
ii debconf [debconf-2.0] 1.5.76
linux-base recommends no packages.
linux-base suggests no packages.
-- debconf information:
* linux-base/removing-running-kernel: true
linux-base/removing-title:
Bug#965935: MR link
https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/32
Bug#965935: configure_networking() should wait for specified interface
Package: initramfs-tools-core Version: 0.137 Severity: normal Tags: patch configure_networking() will do a `udevadm settle` before trying to configure an interface. However it is possible for a NIC to appear after the event queue has settled. This is pretty reproducible with a USB NIC I have. There doesn't appear to be a good way to wait for all devices that were connected at boot time to become available - `udevadm settle` is just the closest thing we have. However, in the case that the user has told us which interface they expect to be used in the initramfs, we can just wait for it specifically. As a bonus, this should shave off some time on systems where the NIC is available before the udev event queue has emptied. I've a patch to do this, which I'll submit as an MR in salsa. Note: This should help out with the following issue in clevis, which provides a mechanism for unlocking a LUKS root device from the initramfs by communicating with a tang server: https://github.com/latchset/clevis/issues/145 -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages initramfs-tools-core depends on: ii coreutils8.32-3 ii cpio 2.13+dfsg-3 ii e2fsprogs1.45.6-1 ii klibc-utils 2.0.7-1 ii kmod 27+20200310-2 ii logsave 1.45.6-1 ii udev 245.6-3 Versions of packages initramfs-tools-core recommends: ii busybox 1:1.30.1-5 ii pigz 2.4-1+b1 Versions of packages initramfs-tools-core suggests: ii bash-completion 1:2.10-1 -- Configuration Files: /etc/initramfs-tools/initramfs.conf changed [not included] -- no debconf information
Bug#852747: enable kexec on arm64
Source: linux Version: 4.9.2-2 Hi! Please enable CONFIG_KEXEC on arm64. The userspace side landed in unstable yesterday, and I verified that it works (at least in QEMU) w/ a Debian kernel rebuilt w/ CONFIG_KEXEC=y. -dann
retiring from security team
hey, I've been unable to find time to work on kernel security updates for some time now and - since I don't see that changing - it is time I officially retire from the team. DSA, please remove me from the appropriate groups. Thanks to Martin Moritz for helping me get started with my first DSAs in '05, '06 (woody was painful[1]), to Ben, Moritz and Salvatore for keeping the kernel DSAs coming since I started slacking, and to the rest of you for continuing to help keep my computers secure :) [1] https://lists.debian.org/debian-security-announce/2006/msg00168.html signature.asc Description: Digital signature
Re: Arm64 port live on debian-ports
On Sun, Apr 20, 2014 at 05:29:13PM +0100, Ian Campbell wrote: On Sun, 2014-04-20 at 09:08 -0700, Vagrant Cascadian wrote: On Sun, Apr 20, 2014 at 04:28:45PM +0100, Ian Campbell wrote: On Sun, 2014-04-20 at 16:13 +0100, Ben Hutchings wrote: Given that, it seems like a good time to add arm64 to src:linux with a configuration that will run on at least a typical QEMU ARM64 emulation. AIUI qemu 2.0 only does qemu-aarch64-user, with the system emulation portion slated to be merged shortly[0]. Not sure if it works, but qemu-system-aarch64 is in the 2.0 packages in sid: https://packages.debian.org/search?suite=sidsearchon=contentskeywords=qemu-system-aarch64 $ qemu-system-aarch64 No machine specified, and there is no default. Use -machine help to list supported machines! $ qemu-system-aarch64 -machine ? [... a long list of 32-bit arm = v7 machines, AFAICT ...] I've not actually tried it, but it doesn't look likely to work. Yeah - at this point qemu-system is only usable for KVM accelerated VMs on said mythical hardware. Only broadly available test platform for a kernel would be the ARM fast model. Some instructions for generating a bootable image for that are here: https://wiki.ubuntu.com/ARM64/FoundationModel -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140421194017.GF5978@fluid.dannf
Bug#711135: unable to reproduce
On Thu, Dec 05, 2013 at 02:01:37PM +1100, Peter Chubb wrote: dann == dann frazier da...@debian.org writes: dann I've got a zx6000 here, but I'm unable to reproduce. Are we dann using the same versions of firmware/elilo? I'm using the serial dann console. I'm using the serial console via the HP iLO system. I collected today's snapshot fo jessie's netboot.tgz, unpacked it on our tftp server, and booted via DHCP: EFI Boot Manager ver 1.10 [14.61] Firmware ver 2.31 [4411] Please select a boot option EFI Shell [Built-in] CDROm DHCP Boot (Gigabit) Debian Boot Option Maintenance Menu System Configuration Menu Use ^ and v to change option(s). Use Enter to select an option Loading.: DHCP Boot (Gigabit) Running LoadFile() CLIENT MAC ADDR: 00 30 6E F3 7E AF CLIENT IP: 10.13.0.38 MASK: 255.255.254.0 DHCP IP: 10.13.0.1 GATEWAY IP: 10.13.0.1 TSize.Running LoadFile() Starting: DHCP Boot (Gigabit) ELILO v3.14 for EFI/IA-64 .. Uncompressing Linux... done Loading file /gelato/debian-installer/ia64/initrd.gz...done Uncompressing Linux... done *** * ROM Version : 02.31 * ROM Date: 03/11/2004 * BMC Version : 01.52 *** Can you attach your elilo.conf? I'm mostly trying to confirm you are specifying relocatable, but also curious about other settings. fwiw, I am also able to boot the latest recent kernels: ELILO boot: di Uncompressing Linux... done Loading file \EFI\debian\boot\initrd.img-di...done [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 3.11-2-itanium (debian-kernel@lists.debian.org) (gcc version 4.6.4 (Debian 4.6.4-4) ) #1 SMP Debian 3.11.10-1 (2013-12-04) [0.00] EFI v1.10 by HP: SALsystab=0x3fb38000 ACPI 2.0=0x3fb2e000 SMBIOS=0x3fb3a000 HCDP=0x3fb2c000 [0.00] booting generic kernel on platform hpzx1 [0.00] PCDP: v0 at 0x3fb2c000 [0.00] Explicit console=; ignoring PCDP [...] -- 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/20131207213114.GB739@fluid.dannf
Bug#711135: unable to reproduce
I've got a zx6000 here, but I'm unable to reproduce. Are we using the same versions of firmware/elilo? I'm using the serial console. Like Martin, my system is also a Madison - but clocked at 1.3GHz vs. his 1.4. EFI Boot Manager ver 1.10 [14.61] Firmware ver 2.31 [4411] Please select a boot option Debian GNU/Linux EFI Shell [Built-in] Boot Option Maintenance Menu System Configuration Menu Use ^ and v to change option(s). Use Enter to select an option Loading.: Debian GNU/Linux Starting: Debian GNU/Linux ELILO v3.14 for EFI/IA-64 .. Uncompressing Linux... done Loading file \EFI\debian\initrd.img...done [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.2.0-4-mckinley (debian-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.41-2+deb7u2 [...] -- 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/20131204213525.GA12870@fluid.dannf
Bug#701744: fixed in linux 3.2.46-1+deb7u1
On Tue, Sep 03, 2013 at 11:04:25AM +0200, Jan Wagner wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, Am 01.09.13 23:47, schrieb dann frazier: Source: linux Source-Version: 3.2.46-1+deb7u1 We believe that the bug you reported is fixed in the latest version of linux, which is due to be installed in the Debian FTP archive. as we are facing this also massively on squeeze, is there a chance to get that also fixed there, even when this is oldstable? Yes, this is currently queued. -- 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/20130903145700.gb3...@dannf.org
Re: wheezy security update for linux
On Thu, Aug 29, 2013 at 01:23:52PM +0100, Ian Campbell wrote: On Wed, 2013-08-28 at 10:36 -0600, dann frazier wrote: On Wed, Aug 28, 2013 at 12:30:41PM +0100, Ben Hutchings wrote: The changelog entry for 3.2.46-1+deb7u1 is closed, though there isn't a tag for this version. What is the update waiting for now? It was waiting for some more testing, but I finished that yesterday. DSA should be going out today. Which I see has now happened, thanks! #701744 doesn't seem to have been autoclosed though, is that normal for a security update? BTW, was anyone looking at uploading the pending squeeze update? It fixes #701744 too. I need to do a security pass through it, but that'll be next. -- 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/20130829192757.gw29...@dannf.org
Re: wheezy security update for linux
On Wed, Aug 28, 2013 at 12:30:41PM +0100, Ben Hutchings wrote: The changelog entry for 3.2.46-1+deb7u1 is closed, though there isn't a tag for this version. What is the update waiting for now? It was waiting for some more testing, but I finished that yesterday. DSA should be going out today. I forgot to tag, doing that now. I want to merge security changes into the wheezy branch for 3.2.50-1; can I do that now or should I wait a bit longer? I don't want to have 3.2.46-1+deb7u1 in the changelog without also including all the patches that really go into that version. -- 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/20130828163600.go29...@dannf.org
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, 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 Wed, Feb 13, 2013 at 03:34:51PM +, Ben Hutchings wrote: On Wed, 2013-02-13 at 15:18 +, Adam D. Barratt wrote: On 12.02.2013 02:15, Ben Hutchings wrote: One or other of us will then need to merge the squeeze-security branch into squeeze and upload -48 in time for the point release. Is there an ETA for that? Sorry for chasing, but if we're going to go for the 23rd (which is looking likely atm) we'd be looking at closing p-u-NEW over the weekend and could really do with announcing that asap. (So it'll be uploaded to p-u-NEW over the weekend should be fine, as we can then plan around that.) I can do that but it depends on the security update being finalised first. Security update has been uploaded. I'll post the builds somewhere as they become available for anyone interested in testing. -- 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/20130214182821.gb9...@dannf.org
Re: 6.0.7 planning
On Wed, Feb 13, 2013 at 03:34:51PM +, Ben Hutchings wrote: On Wed, 2013-02-13 at 15:18 +, Adam D. Barratt wrote: On 12.02.2013 02:15, Ben Hutchings wrote: One or other of us will then need to merge the squeeze-security branch into squeeze and upload -48 in time for the point release. Is there an ETA for that? Sorry for chasing, but if we're going to go for the 23rd (which is looking likely atm) we'd be looking at closing p-u-NEW over the weekend and could really do with announcing that asap. (So it'll be uploaded to p-u-NEW over the weekend should be fine, as we can then plan around that.) I can do that but it depends on the security update being finalised first. Yeah, and that should be finalised today, so this weekend seems reasonable. -- 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/20130213162149.ge18...@dannf.org
Re: 6.0.7 planning
On Mon, Feb 11, 2013 at 03:41:03AM +, Ben Hutchings wrote: On Sun, 2013-02-10 at 16:25 +, Adam D. Barratt wrote: Hi, We're somewhat overdue with the next Squeeze point release (6.0.7) and it'd be good to get it done before the wheezy release, so that we can pull in some upgrade fixes. As an opening gambit, some proposed dates, all of which appear to currently work for me: February 23rd March 2nd March 9th No opinion on dates, but here's the state of the Linux kernel: The current version in s-p-u (2.6.32-47) adds support for new SCSI controllers, which should be included in the installer. However there has been disappointingly little testing feedback about this. fyi, I did hear from an HP contact that the hpsa update was working for him on new servers. There are a couple of pending non-security fixes: * [s390] s390/time: fix sched_clock() overflow (Closes: #698382) * Revert time: Avoid making adjustments if we haven't accumulated anything (Closes: #699112, regression in 2.6.32.60) These ought to be included in the point release but should not be need in the installer. Dann/Moritz, do you have any plans for a security or other stable update? Should I upload to stable with just these two fixes? I've been planning a security update, but work travel has been intervening. An upload in the next couple days should be doable though. Given your statement above, do you think this should be based on -47 or -46? I'll probably drop the fix for CVE-2012-3552, at least for this upload. Your suggestion for avoiding the ABI change is good, but I'm not yet confident enough w/ the backport. -- 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/20130211163610.ga13...@dannf.org
3.2.30-1 FTBFS on mipsen
Apparently because NFS is statically linked (and we only ignore those ABI changes in the modules). Curious - is there a reason for statically linking NFS on mips? Perhaps sb1-bcm91250a and sb1a-bcm91480b need ROOT_NFS more than other architectures, but I that doesn't explain mipsel. -- 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/20120928072944.ga5...@dannf.org
Re: Squeeze point release (6.0.6)
On Mon, Sep 24, 2012 at 10:54:00PM +0100, Adam D. Barratt wrote: On Mon, 2012-09-24 at 09:01 +0900, dann frazier wrote: On Sun, Sep 23, 2012 at 05:39:21PM +0100, Adam D. Barratt wrote: Thanks for the upload; the builds seem to be going well. There don't seem to be any new d-i changes in git, so I assume we just need lkdi, a round of d-i binNMUs and then a d-i-n-i upload? afaik, that's correct. Cool; thanks. All of the kernel builds are (finally) in now; would you have time to take care of the lkdi uploads? Yep, should after work today. -- 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/20120925002142.ga26...@dannf.org
Re: Squeeze point release (6.0.6)
On Sun, Sep 23, 2012 at 05:39:21PM +0100, Adam D. Barratt wrote: On Tue, 2012-09-18 at 11:30 -0600, dann frazier wrote: On Mon, Sep 17, 2012 at 03:58:13PM +0200, Philipp Kern wrote: ok, given the replies, let's settle on this: On Fri, Sep 07, 2012 at 09:43:03PM +0200, Philipp Kern wrote: * Sep 29/30: ok from RT side [...] Sorry, been travelling heavily for the past several days. We do have some changes queued, and I should be able to get a kernel uploaded by this weekend, but probably not sooner since I expect work to keep me pretty busy throught the work week. Thanks for the upload; the builds seem to be going well. There don't seem to be any new d-i changes in git, so I assume we just need lkdi, a round of d-i binNMUs and then a d-i-n-i upload? afaik, that's correct. -- 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/20120924000123.ga14...@dannf.org
Re: Upload linux (3.2.30-1)?
On Sun, Sep 23, 2012 at 01:01:54AM +0100, Ben Hutchings wrote: Since 3.2.29-1 failed to build on s390 (stupid error on my part, now fixed), there needs to be another upload for d-i beta 3. I would have liked to do that today, but have been busy with other things, and I'm going to be travelling tomorrow. Could someone else handle this? linux-latest also should be uploaded. By the way 3.2.30 made some ABI changes, but I think they won't affect OOT modules and I have marked them to be ignored. Yeah, I should be able to do this. -- 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/20120923025112.ga27...@dannf.org
Re: Squeeze point release (6.0.6)
On Mon, Sep 17, 2012 at 03:58:13PM +0200, Philipp Kern wrote: Hi, ok, given the replies, let's settle on this: On Fri, Sep 07, 2012 at 09:43:03PM +0200, Philipp Kern wrote: * Sep 29/30: ok from RT side We still need a press officer for somewhen in the evening to send out the announcement, feedback from -live and a note from -kernel if there's still a change staged for the next point release. p-u-NEW will close on the weekend of Sep 22nd/23rd (barring any breakage induced by the ftp-master meeting ;-). Sorry, been travelling heavily for the past several days. We do have some changes queued, and I should be able to get a kernel uploaded by this weekend, but probably not sooner since I expect work to keep me pretty busy throught the work week. -- 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/20120918173003.gf4...@dannf.org
Bug#679882: linux: leap second fixes missing in 3.2 and 2.6.32 longterm
On Fri, Sep 07, 2012 at 10:35:20AM -0700, Steve Lane wrote: Hi Ben, Is anything happening with this bug e.g. getting the patches into the Debian stable kernel package (2.6.32) and a new version pushed out? We had another meltdown at the end of August and it would be really helpful to have an upgrade before the end of this month (September, in 23 days). Nothing has been added to the bug report since the 5th of last month (August); if there is updated information could someone please update the bug report? I've applied John Stultz's backport to my local tree - will commit it after some testing. -- 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/20120908185321.gc32...@dannf.org
Re: Squeeze point release (6.0.5)
On Thu, May 03, 2012 at 11:14:38PM +0100, Adam D. Barratt wrote: On Mon, 2012-04-30 at 10:09 -0600, dann frazier wrote: On Mon, Apr 30, 2012 at 04:15:31AM +0100, Ben Hutchings wrote: On Sun, 2012-04-29 at 16:36 +0100, Adam D. Barratt wrote: Is the new version ready for upload? It's looking like the point release will be the 12/13th, so it would be good to have everything ready in p-u by next weekend. I think it's ready, though there may be some security fixes we should throw in as well. Dann? Yeah - there's some security stuff to get in as well; I'll be working on that this week. Thanks for the confirmation. How are things looking? We've got all the changes committed that I think should go in and I'm doing some testing w/ a build this morning. I expect the upload to happen this afternoon. As far as I can see there aren't any changes on d-i's squeeze branch, so I guess we could just binNMU d-i once lkdi-* are sorted? (and then do dini.) Agreed. -- 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/20120504152624.ga26...@dannf.org
Re: Squeeze point release (6.0.5)
On Mon, Apr 30, 2012 at 04:15:31AM +0100, Ben Hutchings wrote: On Sun, 2012-04-29 at 16:36 +0100, Adam D. Barratt wrote: On Thu, 2012-04-26 at 05:00 +0100, Ben Hutchings wrote: I think we're going to need to do another kernel upload before the point release to revert a fix that is worse than the original bug: Subject: Revert autofs: work around unhappy compat problem on x86-64 This reverts commit 82e43e2a64739caf323ac98641e1250c3808c300 (commit a32744d4abae24572eff7269bc17895c41bd0085 upstream). The original bug (#633423) is 6 years old and autofs has a workaround for it which is broken by this fix. systemd doesn't have the workaround, but it also isn't in squeeze. That bug's marked as found in 2.6.32-44, which I assume is the not-yet-released version you were planning on including in the point release? Yes. Is the new version ready for upload? It's looking like the point release will be the 12/13th, so it would be good to have everything ready in p-u by next weekend. I think it's ready, though there may be some security fixes we should throw in as well. Dann? Yeah - there's some security stuff to get in as well; I'll be working on that this week. -- 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/20120430160949.gb10...@dannf.org
Re: Planning for final lenny point release (5.0.10)
On Sat, Mar 03, 2012 at 12:29:58PM +, Adam D. Barratt wrote: On 29.02.2012 17:20, dann frazier wrote: On Wed, Feb 29, 2012 at 01:20:32PM +, Adam D. Barratt wrote: Feel free to go ahead with the kernel upload, so we can get it chucked at the buildds. [...] Ack. Unfortunately, the powerpc build died: CC [M] arch/powerpc/oprofile/op_model_power4.o arch/powerpc/oprofile/op_model_power4.c: In function 'pmc_overflow': arch/powerpc/oprofile/op_model_power4.c:273: error: 'PV_POWER7' undeclared (first use in this function) arch/powerpc/oprofile/op_model_power4.c:273: error: (Each undeclared identifier is reported only once arch/powerpc/oprofile/op_model_power4.c:273: error: for each function it appears in.) make[4]: *** [arch/powerpc/oprofile/op_model_power4.o] Error 1 This appears to be a consequence of the patch for CVE-2011- 4347 (URL:http://anonscm.debian.org/viewvc/kernel/dists/lenny-security/linux-2.6/debian/patches/bugfix/powerpc/oprofile-handle-events-that-raise-an-exception-without-overflowing.patch?view=markuppathrev=18552). I reuploaded w/o that patch - that fix was POWER7 specific, and it looks like POWER7 support wasn't supported in the lenny timeframe anyway. -- 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/20120305013106.ga8...@dannf.org
Re: Planning for final lenny point release (5.0.10)
On Wed, Feb 29, 2012 at 01:20:32PM +, Adam D. Barratt wrote: On 27.02.2012 01:12, dann frazier wrote: Ok - sounds like no DSA, but maybe an upload via o-p-u. My vote is to do no kernel upload if the release gets scheduled for the first weekend in march - that's one week out, and I'll have spotty availability beginning mid-week. For later weekends, I'm for it. As you most likely saw already, we've scheduled the point release for the 10th; i.e. a week and a bit from now. Feel free to go ahead with the kernel upload, so we can get it chucked at the buildds. If we could look at getting lkdi and d-i sorted fairly quickly after the kernel builds are in, that would be great, so we don't end up with any last minute surprises; let us know if there's anything you'd like us to assist with there. I was hoping we could get away with binNMUing d-i, but we'd need a manual upload for hppa anyway, so we might as well start with a source+hppa upload I suppose... Ack. -- 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/20120229172036.gb19...@dannf.org
Re: Planning for final lenny point release (5.0.10)
On Sat, Feb 25, 2012 at 10:12:11PM +0100, Philipp Kern wrote: Hi, On Fri, Feb 24, 2012 at 08:44:46PM +, Adam D. Barratt wrote: Assuming the technical side still works, I do worry a little that a new DSA three weeks after the announced EOL for security support might confuse people. I suppose we could do a last-minute kernel update via o-p-u, although I don't know if we have any idea how many people actually upgrade to EOL point releases in the relatively short period before the move to archive.d.o. yeah, I wondered the same. I don't actually know when ftp-master gets rid of oldstable on the mirrors. If we'd know that it's still around for a few months I'd say o-p-u. The old suites used to stay on security-master for ages, but AFAICS that's no longer the case neither. Maybe the final announcement should point people at archive already (it could already get synced there at that point, given that it won't change anymore). Ok - sounds like no DSA, but maybe an upload via o-p-u. My vote is to do no kernel upload if the release gets scheduled for the first weekend in march - that's one week out, and I'll have spotty availability beginning mid-week. For later weekends, I'm for it. -- 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/20120227011257.ga17...@dannf.org
Bug#605090: Linux 3.2 in wheezy
On Wed, Feb 01, 2012 at 02:32:19PM +, Ben Hutchings wrote: On Wed, 2012-02-01 at 10:51 +0100, Yves-Alexis Perez wrote: On mer., 2012-02-01 at 10:34 +0100, Wouter Verhelst wrote: On Wed, Feb 01, 2012 at 10:24:40AM +0100, Yves-Alexis Perez wrote: On mar., 2012-01-31 at 11:01 -0500, micah anderson wrote: What is stopping you from creating another package, that provides the kernel with grsecurity patches applied? Don't bother the kernel team with it, and just maintain it yourself in the archive? Its free software afterall. Honestly, having multiple linux source package in the archive doesn't really sound like a good idea. I don't really think the kernel team would appreciate, I'm pretty sure ftpmasters would disagree, and as a member of the security team, It's definitely something I would object. Well, that's what we have the 'linux-source' packages for: to allow other packages to build-depend on them. Hmhm, that might be a good idea indeed. I need to investigate and try that a bit. Ben, what would kernel team think of that? I don't speak for the whole team, and nor do I.. but I don't see that it solves any problem. You would have to Build-Depend on exact versions of linux-source, so that you know your external patches will apply. Then you would have to rebase the patches every time linux-2.6 is updated, making sure (without much help from upstream) that you don't introduce a subtle security problem. Whilte it may help the kernel team to not have to worry about problems in the grsec flavor when preparing uploads, preventing delays for the non-grsec images. But, that just pushes the coordination down a ways - for stable updates we would need to add the grsec build into the pipeline, and there'd be delays in grsec security updates that go in via linux-2.6. Not nak'ing the idea, but it does extend some critical paths. -- 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/20120201184655.gb2...@dannf.org
Re: Linux kernel version for wheezy
On Sun, Jan 22, 2012 at 12:28:41AM +, Ben Hutchings wrote: If I don't hear any objections from the kernel team in the next week, I'm going to assume that everyone is happy to go with Linux 3.2. I'm cool w/ that. -dann The decision needs to be communicated to Debian developers in general (d-d-a) and to Greg Kroah-Hartman in his capacity as organiser of stable/longterm series. If we go with 3.2 then we will also want to work closely with the Ubuntu kernel maintainers. Ben. -- 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/20120123160440.gc10...@dannf.org
Re: Request to upload linux-2.6 (various suites)
On Thu, Dec 22, 2011 at 01:17:16AM +, Ben Hutchings wrote:
I think the following versions should be uploaded soon:
stable-proposed-updates: 2.6.32-40
Upstream stable updates 2.6.32.{47,48,49,50,51}, a few other fixes, and
backport of isci driver.
I can handle this one (if Bastian isn't already working on it...)
-dann
--
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/20111223164921.ge3...@dannf.org
Re: Upcoming Point Releases
On Wed, Sep 07, 2011 at 09:30:50PM +0200, Philipp Kern wrote: Hi, we finally got target dates for the next point releases of both Lenny and Squeeze. Lenny should get 5.0.9 on October 1st; Squeeze will follow on October 8th with 6.0.3. NEW for Lenny will be closed on the weekend of September 24th; NEW for Squeeze on the weekend of October 1st. The upload of debian-installer for Lenny should happen on the closing weekend at the latest; the middle of week 38 would be appreciated, so that we have everything together on the 24th. We have a lenny security update about ready to release (just waiting on a couple builds). I've merged those changes into the lenny branch and I can upload an o-p-u build tomorrow (which I'll do, barring any objection). This should allow for a d-i upload before the weekend. I don't think a d-i upload is strictly necessary - we haven't added any hardware support since the last point release - but it is probably a good idea given the large number of changes since the last update. For Squeeze it would be cool to have the kernel in for testing end of next week (16/17th). The d-i upload should be there the middle of week 39, October 1st at the latest. base-files can be uploaded now, as it will be held in NEW until closing time anyway. Kind regards and thanks for your efforts Philipp Kern -- 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/2011092004.gc18...@dannf.org
Bug#632923: CVE request: perf: may parse user-controlled config file
This was reported by Christian Ohm at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=632923 The perf command, provided as part of the Linux kernel source, looks for and honors configuration settings in ./config. A local user could obtain elevated privileges by convincing a superuser to run the perf command from a directory the user controls. -- 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/20110807173438.ga14...@dannf.org
Bug#524438: test build
Virgo, Benoit, I've committed a fix for this to our lenny branch. Would either of you be able to test it? I've posted a 32bit build here: http://people.debian.org/~dannf/bugs/524438/ I don't have access to a ME system, but I did smoke test w/ a windows 2008 server didn't experience any problems - though I couldn't reproduce the original issue. -- 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/20110802055705.ga2...@dannf.org
Bug#633738: ip6_tunnel: kernel BUG at net_namespace.c:497
On Wed, Jul 20, 2011 at 09:19:07PM +0100, Alexander Clouter wrote: * dann frazier da...@dannf.org [2011-07-15 13:24:39-0600]: I'd appreciate it if you could test Arnaud's proposed fix in your configuration to help verify that no other issues remain. Applying the patch fixes the problem and the tunnel works as expected. Excellent, thanks for your testing and feedback. I'll get a fix committed shortly. -- 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/20110720210831.gg15...@dannf.org
Bug#633738: ip6_tunnel: kernel BUG at net_namespace.c:497
tags 633738 + lenny thanks On Fri, Jul 15, 2011 at 03:15:32PM +0100, Ben Hutchings wrote: On Thu, 2011-07-14 at 19:03 +0200, Arnaud Patard wrote: Alexander Clouter a...@digriz.org.uk writes: Hi, [ 33.356789] [c02397ec] (net_assign_generic+0x3c/0xbc) from [bf24d3d0] (ip6_tnl_init_net+0x98/0x19c [ip6_tunnel]) [ 33.367378] [bf24d3d0] (ip6_tnl_init_net+0x98/0x19c [ip6_tunnel]) from [c023942c] (register_pernet_operations+0x40/0xf4) [ 33.378658] [c023942c] (register_pernet_operations+0x40/0xf4) from [c02395c0] (register_pernet_device+0x20/0x54) [ 33.389240] [c02395c0] (register_pernet_device+0x20/0x54) from [bf25200c] (ip6_tunnel_init+0xc/0x84 [ip6_tunnel]) [ 33.399915] [bf25200c] (ip6_tunnel_init+0xc/0x84 [ip6_tunnel]) from [c002734c] (do_one_initcall+0x6c/0x1e4) [ 33.410062] [c002734c] (do_one_initcall+0x6c/0x1e4) from [c00738ec] (sys_init_module+0xc0/0x1f0) [ 33.419241] [c00738ec] (sys_init_module+0xc0/0x1f0) from [c0027ea0] (ret_fast_syscall+0x0/0x28) [ 33.428333] Code: e1a01000 e59f000c eb0a2ec7 e3a03000 (e5833000) [ 33.434502] ---[ end trace bf87ce5c849aaa8e ]--- Segmentation fault Failed to bring up iptv-shironeko. This is a regression as I was able to do all this with earlier kernels; definately 2.6.32-34squeeze1. hm... looks like it's from the backport of mainline commit d5aa407f59f5b83d2c50ec88f5bf56d40f1f8978. It's changing a call to register_pernet_gen_device() into a call to register_pernet_device(). [...] Right. And it looks like this affects lenny as well (since 2.6.26-26lenny3). Yep, I used basically the same backport for both updates. Apologies for the regression. Alexander, I'd appreciate it if you could test Arnaud's proposed fix in your configuration to help verify that no other issues remain. -- 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/20110715192439.gb30...@dannf.org
Bug#624605: Potential fixes for lenny from stable 2.6.27.59
fyi, got a lot done on this while travelling, but not yet complete - I've just committed my current set of changes for safe keeping. Once I finish that up I'll follow-up here w/ a more complete reply to the patchlist. -- 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/20110516010411.ga26...@dannf.org
Bug#624268: [squeeze] include important changes from 2.6.32.39
On Wed, Apr 27, 2011 at 01:35:06AM +0100, Ben Hutchings wrote: On Tue, Apr 26, 2011 at 06:17:08PM -0600, dann frazier wrote: [...] 6f396d4a x86, cpu: Fix regression in AMD errata checking code fixes hangs on some K8 systems I believe this is a fixup for these: [...] d4274252 x86, AMD: Set ARAT feature on AMD processors 7a3b25c0 x86, cpu: Clean up AMD erratum 400 workaround bba4804e x86, cpu: AMD errata checking framework These avoid switching to HPET timers in deep C states on AMD CPUs. Though obviously an improvement, I'm not really sure what makes these candidates for stable - unless people have been seeing hangs w/ the broadcast timer code on AMD systems? I'm dubious about the value of these quite large changes, as you may have seen in discussion on stable-review. Given that no-one was able to explain what bug is fixed, and there is a functional change hidden in the 'cleanup' patch which again no-one was able to explain, I would favour reverting these. +1 - I've got them reverted in my local tree, will commit after some testing. -- 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/20110428001622.gc3...@dannf.org
Bug#624268: [squeeze] include important changes from 2.6.32.39
Source: linux-2.6 Version: 2.6.32-33 Severity: important 2.6.32.39 seems to apply/build fine w/o any ABI changes - here's a brief review of the changes w/ a squeeze bias: dcef84f1 net: fix rds_iovec page count overflow CVE-2010-3865 (we've had a fix since 2.6.32-31) c4f6afb9 net: ax25: fix information leak to userland harder follow up fix for CVE-2010-3875 6f396d4a x86, cpu: Fix regression in AMD errata checking code fixes hangs on some K8 systems 5d7a20b5 USB: xhci - fix math in xhci_get_endpoint_interval() Improves spec compliance; I suspect this translates into more reliable behavior for any USB 3.0 users. 53d5fa19 USB: xhci - fix unsafe macro definitions What it says on the tin b90adfeb USB: fix formatting of SuperSpeed endpoints in /proc/bus/usb/devices /proc/bus/usb/devices is deprecated, and we don't mount it by default, but this should improve the output for anyone who does use it.. a572af68 USB: EHCI: unlink unused QHs when the controller is stopped fixes an issue w/ EHCI failover... which I didn't even know existed d86dbfba proc: do proper range check on readdir offset 67e022f3 next_pidmap: fix overflow condition CVE-2011-1593 3aed738e USB: option: Added support for Samsung GT-B3730/GT-B3710 LTE USB modem. 3cd02e97 USB: option: Add new ONDA vendor id and product id for ONDA MT825UP fbf2ed35 USB: ftdi_sio: add ids for Hameg HO720 and HO730 2233c6ee USB: ftdi_sio: add PID for OCT DK201 docking station 6a1c23da USB: ftdi_sio: Added IDs for CTI USB Serial Devices yay new hardware! 8835b61c x86, amd: Disable GartTlbWlkErr when BIOS forgets it avoids random reboots d4274252 x86, AMD: Set ARAT feature on AMD processors 7a3b25c0 x86, cpu: Clean up AMD erratum 400 workaround bba4804e x86, cpu: AMD errata checking framework These avoid switching to HPET timers in deep C states on AMD CPUs. Though obviously an improvement, I'm not really sure what makes these candidates for stable - unless people have been seeing hangs w/ the broadcast timer code on AMD systems? 4f4f117c UBIFS: fix oops when R/O file-system is fsync'ed looks good 286ef426 MAINTAINERS: update STABLE BRANCH info documentation change only e9f20dc7 ramfs: fix memleak on no-mmu arch We don't build any no-mmu kernels ad18f970 mca.c: Fix cast from integer to pointer warning e0ab4946 tioca: Fix assignment from incompatible pointer warnings Just fixes compiler warnings? Seem odd for stable, but correct. 17ebcafe x86: Fix a bogus unwind annotation in lib/semaphore_32.S Not sure what the end user value is here... better kernel backtracing? dd12cd10 NET: cdc-phonet, handle empty phonet header improved hardware support 6b29cc2f UBIFS: restrict world-writable debugfs files 55d39791 video: sn9c102: world-wirtable sysfs files security improvements b6502c56 cifs: always do is_path_accessible check in cifs_mount fixes a BUG() -- 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/20110427001708.gf11...@dannf.org
Bug#622937: [squeeze] Include important changes from 2.6.32.37
On Sat, Apr 16, 2011 at 02:49:28AM +0100, Ben Hutchings wrote: On Fri, 2011-04-15 at 17:52 -0600, dann frazier wrote: [...] bd378dd net: fix rds_iovec page count overflow overflow fix, looks pretty straightforward but needs a fix-up, which is in 2.6.32.38. *nod* - yeah noticed that later [...] f101d38 ext4: fix credits computing for indirect mapped files I'm not sure what improvement this provides users When using delayed allocation, ext4 still needs to count how many blocks the pending writes will need and fail any writes that would overflow the disk. This is a fix for under-counting which would result in data loss (or a crash?) when a disk fills up. ok [...] 483cb5a atm/solos-pci: Don't include frame pseudo-header on transmit hex-dump This seems to be a fixup for debug code? I suggest omitting. I would rather not diverge from upstream here. It has no effect if the user doesn't set the atmdebug parameter. That's less conservative than we have been for previous stable releases, but I do agree it won't affect the vast majority of users. [...] ba7eb95 Squashfs: handle corruption of directory structure Adds some sanity checks that might avoid an oops; looks good to me I asked Vince Sanders to eyeball this as he has done some work with squashfs. He didn't see anything wrong with it. Thanks [...] 6373cc6 x86, microcode, AMD: Extend ucode size verification That hash is ambiguous here. Full hash is 6373cc665a7f5859bcd7772a45a581ecbc86e2cd. I'll defer to Ben who commented on this upstream. The code is dumb but this doesn't seem to make it any worse. It raises the maximum allowed size for microcode updates to AMD family 15h processors, and will presumably be necessary to apply microcode updates at some point. ok [...] 5381fb8 gro: reset skb_iif on reuse Doesn't apply to our tree It depends on the next one; did you try to apply them in reverse order? perhaps.. 2863e5a gro: Reset dev pointer on reuse This looks like it'd apply, but I'll defer to Ben's network expertise here I think the bug is likely to result in a crash. [...] 6216277 Treat writes as new when holes span across page boundaries looks like a data corruption fix and information leak. [...] d7c7517 mm: avoid wrapping vm_pgoff in mremap() avoids a BUG() which is a trivial local DoS. right [...] bd94ab2 Relax si_code check in rt_sigqueueinfo and rt_tgsigqueueinfo looks like a good correctness fix Not sure about correctness, but it's important for compatibility. 11ab449 staging: hv: use sync_bitops when interacting with the hypervisor af352e4 staging: hv: Fix GARP not sent after Quick Migration we don't enable HYPERV, but might be good for those who build from our source I'm intending to enable them at some point. I may just backport the current upstream versions though. 1ed34c9 staging: usbip: bugfix for isochronous packets and optimization d9638d9 staging: usbip: bugfix add number of packets for isochronous frames 98d7db5 staging: usbip: bugfixes related to kthread conversion I'm a bit concerned about the size of these patches, but they *seem* important for compatibility (and the last one avoids a deadlock) [...] This is staging. It was crap to start with and these will probably make it marginally less crap. :-) I've started preparing a commit but I'll be mostly offline today so I won't be able to finish it up before this evening. - dann -- 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/20110418142658.ga4...@dannf.org
Bug#622937: [squeeze] Include important changes from 2.6.32.37
Source: linux-2.6 Version: 2.6.32-33 Tags: squeeze Since we've seen a few regressions w/ longterm updates lately, I thought I'd use a bug as a way to review each change w/ a Debian-specific lens. Here's my initial pass - other reviews welcome.. eebefbf xfs: zero proper structure size for geometry calls already included in 2.6.32-33 bd378dd net: fix rds_iovec page count overflow overflow fix, looks pretty straightforward c18114e exec: copy-and-paste the fixes into compat_do_execve() paths already included in 2.6.32-30 d3de146 exec: make argv/envp memory visible to oom-killer already included in 2.6.32-30 40521c9 CAN: Use inode instead of kernel address for /proc file already included in 2.6.32-31 9d880ce irda: prevent integer underflow in IRLMP_ENUMDEVICES already included in 2.6.32-30 7847ca8 econet: Fix crash in aun_incoming(). already included in 2.6.32-30 2dbba29 inet_diag: Make sure we actually run the same bytecode we audited. already included in 2.6.32-30 4312007 net: tipc: fix information leak to userland already included in 2.6.32-30 fe540c3 nfsd: fix auth_domain reference leak on nlm operations fixes a reference leak - code change looks innocuous enough f101d38 ext4: fix credits computing for indirect mapped files I'm not sure what improvement this provides users 975c07c net: packet: fix information leak to userland already included in 2.6.32-30 1fe4497 net: ax25: fix information leak to userland already included in 2.6.32-30 483cb5a atm/solos-pci: Don't include frame pseudo-header on transmit hex-dump This seems to be a fixup for debug code? I suggest omitting. 3f89dad sctp: fix to calc the INIT/INIT-ACK chunk length correctly is set Fixes an oops; commit log includes a test case we should use to verify. ba7eb95 Squashfs: handle corruption of directory structure Adds some sanity checks that might avoid an oops; looks good to me 794e8ff Revert x86: Cleanup highmap after brk is concluded Already queued for 2.6.32-34 (#621072) 7b74539 powerpc: Fix default_machine_crash_shutdown #ifdef botch a55ee54 powerpc/kexec: Add ifdef CONFIG_PPC_STD_MMU_64 to PPC64 code Already included in 2.6.32-33 6373cc6 x86, microcode, AMD: Extend ucode size verification I'll defer to Ben who commented on this upstream. 7dbaa2b x86, amd-ucode: Remove needless log messages Removes a useless log message... doesn't seem = important to me 5381fb8 gro: reset skb_iif on reuse Doesn't apply to our tree 2863e5a gro: Reset dev pointer on reuse This looks like it'd apply, but I'll defer to Ben's network expertise here 79760cb repair gdbstub to match the gdbserial protocol specification We don't enable KGDB, but it might fix an issue for someone using our source to build their own kernel. a98fa05 sound: oss: midi_synth: check get_user() return value 0042e33 sound/oss: remove offset from load_patch callbacks We don't build these, but might help someone building w/ our source d343ebc econet: 4 byte infoleak to the network Already included in 2.6.32-32 48a129a drivers/misc/ep93xx_pwm.c: world-writable sysfs files 92d191d drivers/rtc/rtc-ds1511.c: world-writable sysfs nvram file These should probably get CVEs 23b37e1 mfd: ab3100: world-writable debugfs *_priv files debugfs shouldn't get a CVE, but should be fixed a41e7f1 ipv6: netfilter: ip6_tables: fix infoleak to userspace Already included in 2.6.32-32 8fd563c netfilter: ipt_CLUSTERIP: fix buffer overflow +1 bf97177 netfilter: arp_tables: fix infoleak to userspace Already included in 2.6.32-32 3be5e2f netfilter: ip_tables: fix infoleak to userspace Already included in 2.6.32-32 913bb1e char/tpm: Fix unitialized usage of data buffer should probably get a CVE 6216277 Treat writes as new when holes span across page boundaries looks like a data corruption fix e469bb3 Bluetooth: add support for Apple MacBook Pro 8,2 just adding ids e826581 Bluetooth: bnep: fix buffer overflow already fixed in 2.6.32-32 a04a632 bridge: netfilter: fix information leak already fixed in 2.6.32-32 1fdae72 Bluetooth: sco: fix information leak to userspace already fixed in 2.6.32-32 91443ec b43: allocate receive buffers big enough for max frame len + offset avoids a BUG() cda10c1 p54usb: IDs for two new devices just adding ids d7c7517 mm: avoid wrapping vm_pgoff in mremap() avoids a BUG() 8975a50 quota: Don't write quota info in dquot_commit() the journaling filesystem aspect seems like it makes this a candidate b94738f UBIFS: fix debugging failure in dbg_check_space_info fixes an oops 5cb4b85 UBIFS: fix oops on error path in read_pnode good oops fix b7236ed UBIFS: do not read flash unnecessarily basically a performance improvement... but trivial. a8c2609 ath9k: fix a chip wakeup related crash in ath9k_start looks good a9a4c9c x86, mtrr, pat: Fix one cpu getting out of sync during resume looks good to me e8a7988 Btrfs: Fix uninitialized root flags for subvolumes looks
Re: security impact of nfsd4_op_flags
On Sun, Apr 10, 2011 at 12:19:32PM -0400, J. Bruce Fields wrote: On Sun, Mar 27, 2011 at 03:09:37PM -0600, dann frazier wrote: Mi, We were wondering if you could help us define the security impact (if any) of your fix for nfsd4_op_flags, commit 5ece3ca upstream. If it does have a security impact, we can work with MITRE to get a CVE ID assigned. Apologies, but I don't have an immediate answer off the top of my head, or time to trace through it. No problem, thanks for taking the time to reply. -- 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/20110410172202.ga6...@dannf.org
Re: Stable update of linux-2.6
On Sun, Apr 03, 2011 at 01:21:03PM +0530, Kamalesh Babulal wrote: * dann frazier da...@dannf.org [2011-04-02 11:23:03]: 2.6.32.36 also fails to build on powerpc/SMP: CC arch/powerpc/kernel/crash.o arch/powerpc/kernel/crash.c: In function 'crash_kexec_wait_realmode': arch/powerpc/kernel/crash.c:176: error: 'paca' undeclared (first use in this function) arch/powerpc/kernel/crash.c:176: error: (Each undeclared identifier is reported only once arch/powerpc/kernel/crash.c:176: error: for each function it appears in.) make[1]: *** [arch/powerpc/kernel/crash.o] Error 1 make: *** [arch/powerpc/kernel] Error 2 Hi Dann, Can you please try the following patch, which adds the changes introduced by Kumar Gala to the commit b3df895aeb to my previous patch. Yep, that fixes the build. -dann powerpc: Fix default_machine_crash_shutdown #ifdef build failure Introducing #ifdef to fix the build failure caused by crash_kexec_wait_realmode(), with powerpc build with !SMP. Reported-by: Ben Hutchings b...@decadent.org.uk Reported-by: dann frazier da...@dannf.org Signed-off-by: Kamalesh Babulal kamal...@linux.vnet.ibm.com cc: Paul E. McKenney paul...@linux.vnet.ibm.com cc: Michael Neuling mi...@neuling.org cc: Benjamin Herrenschmidt b...@kernel.crashing.org cc: Anton Blanchard an...@samba.org cc: Kumar Gala ga...@kernel.crashing.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/20110404215755.ge3...@dannf.org
Re: Stable update of linux-2.6
On Sun, Apr 03, 2011 at 07:33:39AM +1000, Benjamin Herrenschmidt wrote: On Sun, 2011-04-03 at 00:10 +0530, Kamalesh Babulal wrote: * dann frazier da...@dannf.org [2011-04-02 11:23:03]: 2.6.32.36 also fails to build on powerpc/SMP: CC arch/powerpc/kernel/crash.o arch/powerpc/kernel/crash.c: In function 'crash_kexec_wait_realmode': arch/powerpc/kernel/crash.c:176: error: 'paca' undeclared (first use in this function) arch/powerpc/kernel/crash.c:176: error: (Each undeclared identifier is reported only once arch/powerpc/kernel/crash.c:176: error: for each function it appears in.) make[1]: *** [arch/powerpc/kernel/crash.o] Error 1 make: *** [arch/powerpc/kernel] Error 2 This build is not reproducible locally, can you please send the .config file. Smells to me like a 32-bit build... Yep, it is. Current upstream has the function crash_kexec_wait_realmode() protected by: #ifdef CONFIG_PPC_STD_MMU_64 Maybe that is missing in .32.36 ? You can disable CONFIG_CRASH_DUMP as a workaround. Is it that useful anyways on 32-bit ? (Does it even work ?) I'm just reporting this as a build-time regression in stable as it caused an issue when we merged recent stable updates into the Debian tree. I've never personally tried to configure kdump on powerpc. fwiw, a quick test shows that kexec doesn't work on my test box: dannf@macmini:~$ sudo kexec -l /boot/vmlinux-2.6.32-5-powerpc --append=root=/dev/hda3 ro --initrd=/boot/initrd.img-2.6.32-5-powerpc get_memory_ranges(): Unsupported platform Could not get memory layout -- 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/20110404221055.gf3...@dannf.org
Re: Stable update of linux-2.6
2.6.32.36 also fails to build on powerpc/SMP: CC arch/powerpc/kernel/crash.o arch/powerpc/kernel/crash.c: In function 'crash_kexec_wait_realmode': arch/powerpc/kernel/crash.c:176: error: 'paca' undeclared (first use in this function) arch/powerpc/kernel/crash.c:176: error: (Each undeclared identifier is reported only once arch/powerpc/kernel/crash.c:176: error: for each function it appears in.) make[1]: *** [arch/powerpc/kernel/crash.o] Error 1 make: *** [arch/powerpc/kernel] Error 2 -- 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/20110402172303.gb2...@dannf.org
another stable kernel update
We've fixed the powerpc FTBFS, an XFS regression and a few other issues, so I'll plan to upload -33 tomorrow. -- 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/20110401005934.ga26...@dannf.org
security impact of nfsd4_op_flags
Mi, We were wondering if you could help us define the security impact (if any) of your fix for nfsd4_op_flags, commit 5ece3ca upstream. If it does have a security impact, we can work with MITRE to get a CVE ID assigned. -- 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/20110327210937.gx10...@dannf.org
[2.6.32.y] radio-aimslab build fix
hey Greg, Apologies if you've already been notifed of this, but the radio-aimslab fix in 2.6.32.29 introduces a build failures. Looks like we also need to grab: commit 2400982a2e8a8e4e95f0a0e1517bbe63cc88038f Author: Geert Uytterhoeven ge...@linux-m68k.org Date: Sun Jan 16 10:09:13 2011 -0300 [media] radio-aimslab.c needs #include linux/delay.h -- 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/20110221010359.ga24...@dannf.org
scheduling 2.6.26-26lenny2
Just a heads up that I plan to do an upload for stable-security tomorrow. There's no embargoed issues, and a draft of the advisory is text is in the kernel-sec repo under dsa-texts/2.6.26-26lenny2. -- 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/20110126024122.gd3...@dannf.org
2.6.26-27
SRM is looking to do another point release soon, so I'd like to go ahead and upload a 2.6.26-27 today or tomorrow. This branch currently just contains a single change, Ben's fix for #604457. I also plan to disable econet autoloading there. I plan to get a security update pushed out soon, but I'd like to keep that off of the critical path of the point release. Let me know if you've any other changes you'd like to get in first. -- 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/20110112192654.gc24...@dannf.org
Bug#604457: fix verification
Wouter, Were you able to verify the fix for this bug? If it helps, I've posted a test build here that includes this fix: http://people.debian.org/~dannf/bugs/604457/ -- 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/20110112203603.gg24...@dannf.org
Re: 2.6.26-27
On Wed, Jan 12, 2011 at 08:00:38PM +, Ben Hutchings wrote: On Wed, Jan 12, 2011 at 12:26:54PM -0700, dann frazier wrote: SRM is looking to do another point release soon, so I'd like to go ahead and upload a 2.6.26-27 today or tomorrow. This branch currently just contains a single change, Ben's fix for #604457. I also plan to disable econet autoloading there. [...] AFAIK we still don't have confirmation that the fix for #604457 actually works. Ah.. ok. I'll post a test build I just did and poke the submitter. If we can't get that fix verified, then no need for a stable upload. -- 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/20110112203129.gf24...@dannf.org
Bug#597658: linux-headers-2.6.32-5-amd64: Missing aesni-intel module in kernel
On Mon, Jan 03, 2011 at 08:29:02PM +, Ben Hutchings wrote: On Mon, 2011-01-03 at 10:12 -0700, dann frazier wrote: On Mon, Jan 03, 2011 at 05:05:32AM +, Ben Hutchings wrote: On Sun, 2011-01-02 at 21:30 -0700, dann frazier wrote: On Sun, Jan 02, 2011 at 08:57:19PM +, Ben Hutchings wrote: [...] Please can you test whether aesni-intel loads and works in: 1. Package version 2.6.32-12 http://snapshot.debian.org/package/linux-2.6/2.6.32-12/. This was the last version with aesni-intel included. 2. Package version 2.6.32-29, modified to reenable aesni-intel. See the instructions at http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official. a. Follow section 4.2.1. b. Change '# CONFIG_CRYPTO_AES_NI_INTEL is not set' to 'CONFIG_CRYPTO_AES_NI_INTEL=m' in debian/config/kernelarch-x86/config-arch-64. c. Follow section 4.2.4. fyi, 2.6.32-12 2.6.32-29 w/ CONFIG_CRYPTO_AES_NI_INTEL=m both boot successfully w/ the aesni_intel module on my Lenovo T410. I'm guessing you don't have an AES-encrypted hard drive though... I do: $ sudo cryptsetup status sda5_crypt /dev/mapper/sda5_crypt is active: cipher: aes-cbc-essiv:sha256 [...] Though I don't know how to verify that the hardware implementation is actually being used. I think that trying to remove the module is a valid test. Finally found a convenient time to reboot; in both cases (-12 -29 + the module) the module is unremovable on my system. -dann -- 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/20110110203956.ga2...@dannf.org
CVE Request: kernel [Re: Security review of 2.6.32.28]
On Thu, Jan 06, 2011 at 01:05:47AM +, Ben Hutchings wrote: These are the patches that looked security-relevant, from a fairly quick review: Thanks for the review Ben! Steve, can you assign CVEs for the following issues? [03/49] fuse: verify ioctl retries Kernel buffer overflow, but only CUSE servers could exploit it and /dev/cuse is normally restricted to root. Upstream fix: http://git.kernel.org/linus/7572777eef78ebdee1ecb7c258c0ef94d35bad16 Introduced in 2.6.29. [16/49] IB/uverbs: Handle large number of entries in poll CQ Fixes integer overflow and information leak which I assume can be triggered by unprivileged local users. Sounds like it - Documentation/infiniband/user_verbs.txt says: Since the InfiniBand userspace verbs should be safe for use by non-privileged processes, it may be useful to add an appropriate MODE or GROUP to the udev rule. Upstream fix: http://git.kernel.org/linus/7182afea8d1afd432a17c18162cc3fd441d0da93 Introduced in 2.6.15. [20/49] orinoco: fix TKIP countermeasure behaviour Fixes cryptographic weakness potentially leaking information to remote (but physically nearby) users. Upstream fix: http://git.kernel.org/linus/0a54917c3fc295cb61f3fb52373c173fd3b69f48 Introduced in 2.6.28. [24/49] tracing: Fix panic when lseek() called on trace opened for writing File is normally only writable by root, so not a security issue. ack [33/49] [SCSI] bfa: fix system crash when reading sysfs fc_host statistics Local denial-of-service. CVE-2010-4343 [36/49] install_special_mapping skips security_file_mmap check. May enable privilege escalation through null pointer bugs that would otherwise only cause denial-of-service. CVE-2010-4346 [42/49] sound: Prevent buffer overflow in OSS load_mixer_volumes Not relevant to Debian kernel images since we don't build OSS. CVE-2010-4257 [44/49] ima: fix add LSM rule bug Allows subversion of IMA. Not relevant to Debian kernel images since we don't build IMA. Upstream fix: http://git.kernel.org/linus/867c20265459d30a01b021a9c1e81fb4c5832aa9 Introoduced in 2.6.30. [48/49] sctp: Fix a race between ICMP protocol unreachable and connect() Remote denial-of-service. CVE-2010-4526 Ben. -- 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/20110106161811.ge12...@dannf.org
Bug#597658: linux-headers-2.6.32-5-amd64: Missing aesni-intel module in kernel
On Mon, Jan 03, 2011 at 05:05:32AM +, Ben Hutchings wrote: On Sun, 2011-01-02 at 21:30 -0700, dann frazier wrote: On Sun, Jan 02, 2011 at 08:57:19PM +, Ben Hutchings wrote: [...] Please can you test whether aesni-intel loads and works in: 1. Package version 2.6.32-12 http://snapshot.debian.org/package/linux-2.6/2.6.32-12/. This was the last version with aesni-intel included. 2. Package version 2.6.32-29, modified to reenable aesni-intel. See the instructions at http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official. a. Follow section 4.2.1. b. Change '# CONFIG_CRYPTO_AES_NI_INTEL is not set' to 'CONFIG_CRYPTO_AES_NI_INTEL=m' in debian/config/kernelarch-x86/config-arch-64. c. Follow section 4.2.4. fyi, 2.6.32-12 2.6.32-29 w/ CONFIG_CRYPTO_AES_NI_INTEL=m both boot successfully w/ the aesni_intel module on my Lenovo T410. I'm guessing you don't have an AES-encrypted hard drive though... I do: $ sudo cryptsetup status sda5_crypt /dev/mapper/sda5_crypt is active: cipher: aes-cbc-essiv:sha256 [...] Though I don't know how to verify that the hardware implementation is actually being used. fwiw, the init messages do differ for me between -12 -29 (as the git log suggests it should): -12: [ 13.565523] alg: No test for __aes-aesni (__driver-aes-aesni) [ 13.565542] alg: No test for __ecb-aes-aesni (__driver-ecb-aes-aesni) [ 13.565559] alg: No test for __cbc-aes-aesni (__driver-cbc-aes-aesni) [ 13.566877] alg: No test for __ecb-aes-aesni (cryptd(__driver-ecb-aes-aesni)) [ 13.569514] alg: No test for __cbc-aes-aesni (cryptd(__driver-cbc-aes-aesni)) -29: [ 10.766143] alg: No test for __cbc-aes-aesni (cryptd(__driver-cbc-aes-aesni)) -- 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/20110103171252.gb12...@dannf.org
Bug#597658: linux-headers-2.6.32-5-amd64: Missing aesni-intel module in kernel
On Sun, Jan 02, 2011 at 08:57:19PM +, Ben Hutchings wrote: On Sun, 2011-01-02 at 20:41 +0100, cfchris6 wrote: What has to be done until the proposed solution to blacklist the module could be implemented? I do think that it is not very nice to have a big part of those with a newer amd64 box unable to use this functionality. If I get it correctly, the main reason for the decision to disable that module is that it's not playing nice with a T400. What is the number of the bug report with upstream on that matter? I don't know of one. There is a Fedora bug report https://bugzilla.redhat.com/show_bug.cgi?id=571577 and if I read that correctly then this is not a model-specific bug - the module was actually completely broken in 2.6.32 if CONFIG_CRYPTO_FIPS=y (which it is in Debian packages). However, it also looks like this was fixed in 2.6.32.19, which is incorporated in the source for the current package. Please can you test whether aesni-intel loads and works in: 1. Package version 2.6.32-12 http://snapshot.debian.org/package/linux-2.6/2.6.32-12/. This was the last version with aesni-intel included. 2. Package version 2.6.32-29, modified to reenable aesni-intel. See the instructions at http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official. a. Follow section 4.2.1. b. Change '# CONFIG_CRYPTO_AES_NI_INTEL is not set' to 'CONFIG_CRYPTO_AES_NI_INTEL=m' in debian/config/kernelarch-x86/config-arch-64. c. Follow section 4.2.4. fyi, 2.6.32-12 2.6.32-29 w/ CONFIG_CRYPTO_AES_NI_INTEL=m both boot successfully w/ the aesni_intel module on my Lenovo T410. -- 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/20110103043033.ga2...@dannf.org
Bug#607370: linux-image-2.6.32-5-amd64: exploit for x86_64 linux kernel ia32syscall emulation still works
On Fri, Dec 17, 2010 at 09:22:16AM -0500, Travis Thompson wrote: Package: linux-2.6 Version: 2.6.32-29 Severity: important An older explot based off of CVE-2010-3301 still works or works again on current amd64 kernel for debian testing. http://www.exploit-db.com/exploits/15023/ this code currently can root my computer. I just did a fresh install of squeeze and I cannot reproduce. Are you sure the shell the exploit gives you is a *root* shell? -- 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/20101217170802.gc26...@dannf.org
Bug#606289: 4.0.517 firmware crashes frequently on HP NC522SFP
Package: firmware-netxen Version: 0.27 Severity: important A user reported that the 4.0.517 crashes within seconds on this netxen-based NIC - this is the firmware version we currently ship in 0.27. The user confirmed that 4.0.534 fixes the issue. This version was recently accepted into the linux-firmware tree. -- 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/20101208065849.ga13...@dannf.org
scheduling 2.6.26-26
In order to get the kernel/d-i stack squared away for 5.0.7, I'd like to go ahead and upload 2.6.26-26 tomorrow. I had planned to push the changes in the lenny branch via security (w/ several other queued security fixes), but I'll need a little more time to get the security upload ready. Let me know if you have any stable changes in preparation that I should wait for. -- 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/20101119235134.ge30...@dannf.org
Re: Minutes of the Debian linux-2.6 Group Meeting
On Thu, Nov 11, 2010 at 01:52:12PM +, maximilian attems wrote: [...] Automated tests --- This is a pressing task, we should know sooner if the specific branch compiles and boots. waldi shouts for reprepro, sbuild and wannbuild. Build server needed between 6-12 hours and back then we didn't have debug yet. People were using and testing our builds. Action item by Ben to poke Vince for a Debian solution with enough horse power and no bandwidth troubles. Also the automated tests proposed at the kernel summit are to be watched. fyi, hp was hosting a system for d-i testing that has recently become available. Its a dual socket, 4-core xeon 2.33GHz system w/ 8 G of RAM and 8x 15K RPM SAS drives (2 of which may be failing.. SMART status is vague). -- 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/20101117160835.ga19...@dannf.org
Re: Minutes of the Debian linux-2.6 Group Meeting
On Thu, Nov 11, 2010 at 01:52:12PM +, maximilian attems wrote: #534964 memory cgroup support for linux containers? --- bwh has patch to have cgroup mem functionaly but disabled by default. The cost of it has not yet been evaluated. We need a server box with good cooling to run benchmarks with it. The server I mentioned for testing could probably be setup for this purpose fairly quickly.. Action Item take by bwh as their seem to be a strange profileration of recipes to recompile Debian linux-2.6 for Linux containers due to this missing feature. -- 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/20101117163732.gb19...@dannf.org
Re: Security: auto-loading protocol modules
On Thu, Nov 18, 2010 at 03:33:36AM +, Ben Hutchings wrote: Unlike device or filesystem modules, most protocol modules may be auto- loaded on behalf of local users without any special capabilities. This means that security vulnerabilities in such protocol modules may be exploitable by local users even on a system where there is no need for the protocol. Protocol modules are requested via module aliases generated from the protocol-family, protocol and type numbers passed to socket(). Administrators can of course blacklist the modules or disable their aliases, but there is an ever-growing list of protocols. There has been some discussion upstream of providing a means to disable or restrict this auto-loading altogether, but this is currently unresolved. I've been thinking about this as well, and I'd like to see us come up with something. Its a shame to put so many users at added risk to provide support for protocols used by just a fraction. Removing aliases is certainly one way to do it. One problem with that is that, if an admin intentionally wants to support a protocol, they have to leave the module loaded at all times. Big problem? Probably not. Another way to do this would be to ship a default blacklist. This seems like it takes the same amount of local config (instead of adding to /etc/modules, you'd comment out a line in the blacklist file). Personally, I've even considered adding dpkg filters to machines I admin to just avoid having these modules (and others) installed at all. -dann These are the changes in defined aliases between current stable and unstable kernels: -alias net-pf-10 ipv6 This is now built-in. +alias net-pf-16-proto-13 ip6_queue +alias net-pf-16-proto-3 ip_queue Netlink support for iptables/ip6tables. This is not new code but auto-loading was only enabled in Linux 2.6.30. Most use seems to be dependent on capable(CAP_NET_ADMIN). +alias net-pf-21 rds This has had several recent vulnerabilities. Perhaps we should remove this alias? +alias net-pf-35 phonet +alias net-pf-35-proto-2 pn_pep I was unable to create AF_PHONET sockets, so I assume they can only be created if a suitable device exists. +alias net-pf-36 af_802154 I have no idea of the security state of this. I was able to create AF_IEEE802154 sockets on system with no suitable devices. Ben. -- 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/20101118072049.gt19...@dannf.org
Bug#602536: useless /dev/cciss/ device
On Fri, Nov 05, 2010 at 05:40:29PM +, Ian Jackson wrote: Package: linux-image-2.6.26-2-686-bigmem Version: 2.6.26-25lenny1 On an HP DL165 with nothing connected to the CCISS controller (the disks are connected only to the ordinary SATA controller), this kernel produces a device node /dev/cciss/c0d0, without a corresponding entry in /proc/partitions, but with an entry in /sys/block. (parted sees this and complains about it, and it makes automated installs awkward.) The device can be opened but looks empty: woodlouse:~# dd if=/dev/cciss/c0d0 of=t 0+0 records in 0+0 records out 0 bytes (0 B) copied, 0.000570254 s, 0.0 kB/s woodlouse:~# hey Ian, I belive this is intentional. This device file persists so that mgmt software can still talk to the controller: commit 8ce51966d3b809d6c1ae4f3902058558589480b8 Author: Stephen M. Cameron scame...@beardog.cce.hp.com Date: Thu Sep 17 13:47:34 2009 -0500 cciss: Handle special case for sysfs attributes of the first logical drive. For c0dx where x is not 0, we handle deletion and addition simply, but for c0d0, there is the special case that even when there's no disk, the device node exists so that the controller may be accessed. So, for c0d0, we only create the sysfs entries once, when a controller is added, and only remove them once, when a controller is being taken down. Signed-off-by: Stephen M. Cameron scame...@beardog.cce.hp.com Signed-off-by: Jens Axboe jens.ax...@oracle.com Though it could be argued that there are more modern interfaces for configuring devices (raid_class ?), I highly suspect it would break compatibility with a lot of existing userspace software. Though you could certainly ask :) My suggestion would be to blacklist the cciss driver on your system. -- 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/20101118074107.gu19...@dannf.org
Bug#595502: linux-image-2.6.32-5-mckinley: panics while loading INIT, IOMMU out of mapping resources
On Mon, Nov 15, 2010 at 12:40:27PM +, Ben Hutchings wrote: On Mon, 2010-11-15 at 13:10 +0100, Thibaut VARENE wrote: On Tue, Sep 14, 2010 at 10:37 AM, Thibaut VARÈNE vare...@debian.org wrote: Package: linux-image-2.6.32-5-mckinley Version: 2.6.32-20 Severity: grave Justification: renders system unusable System boots fine with linux-image-2.6.32-3-mckinley 2.6.32-9. Panics with 2.6.32-20 with: I/O MMU @ c000fed01000 is out of mapping resources FWIW, this bug still affects 2.6.32-27, and renders the system completely unusable. I've had to stick with 2.6.32-9 so far. Note that dann no longer works for HP, which probably makes it quite hard for him to do IA64 testing. Actually, I have a zx6000 sitting right here :) It is happily running 2.6.32-27. Since you apparently still haven't tested Linux 2.6.35, we're waiting for you to do that. Actually, make that 2.6.36 now. -- 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/20101115172525.ga28...@dannf.org
Bug#595502: linux-image-2.6.32-5-mckinley: panics while loading INIT, IOMMU out of mapping resources
On Mon, Nov 15, 2010 at 02:35:21PM +, Ben Hutchings wrote: On Mon, Nov 15, 2010 at 02:03:01PM +0100, Thibaut VARENE wrote: On Mon, Nov 15, 2010 at 1:40 PM, Ben Hutchings b...@decadent.org.uk wrote: On Mon, 2010-11-15 at 13:10 +0100, Thibaut VARENE wrote: On Tue, Sep 14, 2010 at 10:37 AM, Thibaut VARÈNE vare...@debian.org wrote: Package: linux-image-2.6.32-5-mckinley Version: 2.6.32-20 Severity: grave Justification: renders system unusable System boots fine with linux-image-2.6.32-3-mckinley 2.6.32-9. Panics with 2.6.32-20 with: I/O MMU @ c000fed01000 is out of mapping resources FWIW, this bug still affects 2.6.32-27, and renders the system completely unusable. I've had to stick with 2.6.32-9 so far. Note that dann no longer works for HP, which probably makes it quite hard for him to do IA64 testing. Since you apparently still haven't tested Linux 2.6.35, we're waiting for you to do that. Actually, make that 2.6.36 now. As expected, 2.6.36.1 from experimental fucked up my raid gracefully, just as 2.6.35-21 did. I'm so very very happy right now, thank you. Needless to say, I'm not testing any other kernel on that machine. I suppose ia64 has porters, too? [...] Given that this bug still exists in 2.6.36, you can report a bug upstream at https://bugzilla.kernel.org. We will be happy to backport any fix if possible. Let us know the upstream bug number or URL so we can track it. +1 - my system uses only scsi disks, so I can't reproduce this 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/20101115172857.gb28...@dannf.org
Re: updated text
On Tue, Nov 02, 2010 at 08:10:09PM -0400, Ben Hutchings wrote: On Tue, 2010-11-02 at 21:35 +0100, Mario Kleinsasser wrote: Hello Dann, I've got your message from the list and would like to ask you what this mean? We are massively using OpenVZ for our containers and this is the base of our weberver farm. The lxc Linux Containers project (http://lxc.sourceforge.net) sounds similar as OpenVZ. Are the kernel patches based upon the work of OpenVZ from Kir Kolyshkin? My colleague and I know Kir Kolyshkin (OpenVZ) since some years and we are in contact from time to time with him. I believe that many of the OpenVZ developers have also been working on Linux Containers. Yes, my understanding is that they are working to redesign pieces to get them excepted upstream, and then altering the OpenVZ patches to make use of the upstreamed code. (This is based upon a talk by Kir at the LF Collaboration Summit in April). I hope to see a mature/upstream LXC implementation for wheezy to which we can migrate OpenVZ/Linux Vserver users. I gather that it isn't currently a problem for us because squeeze will have an OpenVZ kernel image but its good to know whats coming next because we then have to productive migrate a lot of instances. Does anyone know whats the currently status of OpenVZ integration in Debian 6.0 and later is? Whats the plan or vision? [...] It is still supported in Debian 6.0, and the OpenVZ developers are actively maintaining a branch based on Linux 2.6.32 which we are taking fixes from. I'd add that, in my experience, the OpenVZ developers have been very good at working with Debian and our users - this isn't a rebuke of their work, but is part of an effort to reduce the overhead of maintaining several flavors, and to target upstreamed solutions. -- 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/20101103163857.gf24...@dannf.org
updated text
Maks I discussed this on IRC and drafted the following text which we believe is ready for inclusion: Debian 6.0 will be the final Debian release to include Linux kernel virtualization featuresets outside of mainline. This means that the OpenVZ and Linux-Vserver featuresets should be considered deprecated, and users should migrate to linux-2.6 upstream merged virtualization solutions like KVM, Linux Containers or Xen. -- 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/20101102154313.ga24...@dannf.org
item for kernel meeting -- NX emulation
hey, Kees poked me to see if Debian would consider including the NX emulation patch that Ubuntu and Fedora are currently shipping. I won't be able to make Paris this weekend, but I'd like to request that this get added to the agenda. Kees, can you provide a reference for the changes? [CC'ing the security team as well for possible feedback] -- 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/20101029135004.gb17...@dannf.org
Re: item for kernel meeting -- NX emulation
On Fri, Oct 29, 2010 at 02:13:14PM +, maximilian attems wrote: hello dann! On Fri, Oct 29, 2010 at 07:50:04AM -0600, dann frazier wrote: Kees poked me to see if Debian would consider including the NX emulation patch that Ubuntu and Fedora are currently shipping. I won't be able to make Paris this weekend, but I'd like to request that this get added to the agenda. Kees, can you provide a reference for the changes? [CC'ing the security team as well for possible feedback] items are to be found here, please just edit: http://wiki.debian.org/DebianKernel/Meetings appended. -- 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/20101029144312.gc17...@dannf.org
Bug#600281: linux-image-2.6.26-2-sparc64: networks halt after a few weeks on TULIP DAVICOM DM9102, NETDEV WATCHDOG: eth0: transmit timed out
On Fri, Oct 15, 2010 at 03:48:27PM +0200, Remi Bouhl wrote: Package: linux-image-2.6.26-2-sparc64 Version: 2.6.26-22lenny1 Severity: important I am using a Sun Fire V100 with Debian Lenny. It was OK for a few weeks, then suddenly it was not possible to access it from SSH: connexion timed out. The only thing I could get from network was the index of apache default index page. No way to download a file. All looked like if the network was over logging. I couldn't get physical access, so asked someone to reboot it. After that I had a look to syslog, there are many lines like this: [...] Oct 14 15:02:11 titine kernel: [7088458.574525] NETDEV WATCHDOG: eth0: transmit timed out Oct 14 15:02:27 titine kernel: [7088474.574528] NETDEV WATCHDOG: eth0: transmit timed out Oct 14 15:02:47 titine kernel: [7088494.574530] NETDEV WATCHDOG: eth0: transmit timed out Oct 14 15:03:03 titine kernel: [7088510.574533] NETDEV WATCHDOG: eth0: transmit timed out Oct 14 15:03:19 titine kernel: [7088526.574532] NETDEV WATCHDOG: eth0: transmit timed out Oct 14 15:03:39 titine kernel: [7088546.574534] NETDEV WATCHDOG: eth0: transmit timed out Oct 14 15:03:55 titine kernel: [7088562.574532] NETDEV WATCHDOG: eth0: transmit timed out Oct 14 15:04:11 titine kernel: [7088578.574537] NETDEV WATCHDOG: eth0: transmit timed out Oct 14 15:04:23 titine kernel: [7088590.574540] NETDEV WATCHDOG: eth0: transmit timed out Oct 14 15:04:47 titine kernel: [7088614.574541] NETDEV WATCHDOG: eth0: transmit timed out Oct 14 15:05:27 titine kernel: [7088654.574546] NETDEV WATCHDOG: eth0: transmit timed out Oct 14 15:06:03 titine kernel: [7088690.574542] NETDEV WATCHDOG: eth0: transmit timed out [...] Does /var/log/kern.log contain anything interesting before these messages? (oops message, tulip driver messages, etc)? Saw a similar bug, number 522592. It's closed now, with no solution or fix. As suggested in that bug report, can you try the 2.6.32 kernel from squeeze and see if it has better results? -- 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/20101018153016.ga22...@lackof.org
Bug#600305: forcing dma mode
On Sun, Oct 17, 2010 at 01:03:04AM +, Debian Bug Tracking System wrote:
Processing commands for cont...@bugs.debian.org:
# Automatically generated email from bts, devscripts version 2.10.35lenny7
tags 600305 + pending
Bug #600305 [linux-image-2.6.32-5-amd64] linux-image-2.6.32-5-amd64:
MacBookPro 7, 1 mcp89 sata link reset fails, no disks detected during install
process
Added tag(s) pending.
End of message, stopping processing here.
Please contact me if you need assistance.
Ben,
Should we include these as well to force on DMA mode?
--
dann frazier
[Backported to Debian's 2.6.32 by dann frazier da...@debian.org]
commit 1529c69adce1e95f7ae72f0441590c226bbac7fc
Author: Tejun Heo t...@kernel.org
Date: Tue Jun 22 12:27:26 2010 +0200
ata_generic: implement ATA_GEN_* flags and force enable DMA on MBP 7,1
IDE mode of MCP89 on MBP 7,1 doesn't set DMA enable bits in the BMDMA
status register. Make the following changes to work around the problem.
* Instead of using hard coded 1 in id-driver_data as class code
match, use ATA_GEN_CLASS_MATCH and carry the matched id in
host-private_data.
* Instead of matching PCI_VENDOR_ID_CENATEK, use ATA_GEN_FORCE_DMA
flag in id instead.
* Add ATA_GEN_FORCE_DMA to the id entry of MBP 7,1.
Signed-off-by: Tejun Heo t...@kernel.org
Cc: Peer Chen pc...@nvidia.com
Cc: sta...@kernel.org
Reported-by: Anders Ãsthus grapz...@gmail.com
Reported-by: Andreas Graf andreas_g...@csgraf.de
Reported-by: Benoit Gschwind gschw...@gnu-log.net
Reported-by: Damien Cassou damien.cas...@gmail.com
Reported-by: tixet...@juno.com
Signed-off-by: Jeff Garzik jgar...@redhat.com
diff -urpN a/drivers/ata/ata_generic.c b/drivers/ata/ata_generic.c
--- a/drivers/ata/ata_generic.c 2010-10-18 17:18:22.160591155 -0600
+++ b/drivers/ata/ata_generic.c 2010-10-18 17:28:35.700130856 -0600
@@ -32,6 +32,11 @@
* A generic parallel ATA driver using libata
*/
+enum {
+ ATA_GEN_CLASS_MATCH = (1 0),
+ ATA_GEN_FORCE_DMA = (1 1),
+};
+
/**
* generic_set_mode - mode setting
* @link: link to set up
@@ -46,13 +51,17 @@
static int generic_set_mode(struct ata_link *link, struct ata_device **unused)
{
struct ata_port *ap = link-ap;
+ const struct pci_device_id *id = ap-host-private_data;
int dma_enabled = 0;
struct ata_device *dev;
struct pci_dev *pdev = to_pci_dev(ap-host-dev);
- /* Bits 5 and 6 indicate if DMA is active on master/slave */
- if (ap-ioaddr.bmdma_addr)
+ if (id-driver_data ATA_GEN_FORCE_DMA) {
+ dma_enabled = 0xff;
+ } else if (ap-ioaddr.bmdma_addr) {
+ /* Bits 5 and 6 indicate if DMA is active on master/slave */
dma_enabled = ioread8(ap-ioaddr.bmdma_addr + ATA_DMA_STATUS);
+ }
if (pdev-vendor == PCI_VENDOR_ID_CENATEK)
dma_enabled = 0xFF;
@@ -126,7 +135,7 @@ static int ata_generic_init_one(struct p
const struct ata_port_info *ppi[] = { info, NULL };
/* Don't use the generic entry unless instructed to do so */
- if (id-driver_data == 1 all_generic_ide == 0)
+ if ((id-driver_data ATA_GEN_CLASS_MATCH) all_generic_ide == 0)
return -ENODEV;
/* Devices that need care */
@@ -155,7 +164,7 @@ static int ata_generic_init_one(struct p
return rc;
pcim_pin_device(dev);
}
- return ata_pci_sff_init_one(dev, ppi, generic_sht, NULL);
+ return ata_pci_sff_init_one(dev, ppi, generic_sht, (void *)id);
}
static struct pci_device_id ata_generic[] = {
@@ -167,18 +176,21 @@ static struct pci_device_id ata_generic[
{ PCI_DEVICE(PCI_VENDOR_ID_HINT, PCI_DEVICE_ID_HINT_VXPROII_IDE), },
{ PCI_DEVICE(PCI_VENDOR_ID_VIA,PCI_DEVICE_ID_VIA_82C561), },
{ PCI_DEVICE(PCI_VENDOR_ID_OPTI, PCI_DEVICE_ID_OPTI_82C558), },
- { PCI_DEVICE(PCI_VENDOR_ID_CENATEK,PCI_DEVICE_ID_CENATEK_IDE), },
+ { PCI_DEVICE(PCI_VENDOR_ID_CENATEK,PCI_DEVICE_ID_CENATEK_IDE),
+ .driver_data = ATA_GEN_FORCE_DMA },
/*
* For some reason, MCP89 on MacBook 7,1 doesn't work with
* ahci, use ata_generic instead.
*/
{ PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NFORCE_MCP89_SATA,
- PCI_VENDOR_ID_APPLE, 0xcb89, },
+ PCI_VENDOR_ID_APPLE, 0xcb89,
+ .driver_data = ATA_GEN_FORCE_DMA },
{ PCI_DEVICE(PCI_VENDOR_ID_TOSHIBA,PCI_DEVICE_ID_TOSHIBA_PICCOLO), },
{ PCI_DEVICE(PCI_VENDOR_ID_TOSHIBA,PCI_DEVICE_ID_TOSHIBA_PICCOLO_1), },
{ PCI_DEVICE(PCI_VENDOR_ID_TOSHIBA,PCI_DEVICE_ID_TOSHIBA_PICCOLO_2), },
/* Must come last. If you add entries adjust this table appropriately */
- { PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_CLASS_STORAGE_IDE 8, 0xFF00UL, 1},
+ { PCI_DEVICE_CLASS(PCI_CLASS_STORAGE_IDE 8, 0xFF00UL),
+ .driver_data = ATA_GEN_CLASS_MATCH },
{ 0, },
};
commit 728e0eaf99631d197e5158e21b4a8c4335a39231
Author: Tejun Heo t...@kernel.org
Date: Fri Jul 2 14:41:24 2010 +0200
ata_generic: drop hard coded DMA force logic for CENATEK
Commit 1529c69adc (ata_generic: implement ATA_GEN_* flags and force
enable DMA
Bug#600305: forcing dma mode
On Tue, Oct 19, 2010 at 02:23:26AM +0100, Ben Hutchings wrote: On Mon, 2010-10-18 at 17:42 -0600, dann frazier wrote: On Sun, Oct 17, 2010 at 01:03:04AM +, Debian Bug Tracking System wrote: Processing commands for cont...@bugs.debian.org: # Automatically generated email from bts, devscripts version 2.10.35lenny7 tags 600305 + pending Bug #600305 [linux-image-2.6.32-5-amd64] linux-image-2.6.32-5-amd64: MacBookPro 7, 1 mcp89 sata link reset fails, no disks detected during install process Added tag(s) pending. End of message, stopping processing here. Please contact me if you need assistance. Ben, Should we include these as well to force on DMA mode? Yes, thanks for spotting those. Committed in r16456. -- dann frazier -- 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/20101019012758.ga13...@lackof.org
Bug#599615: linux-image-2.6.32-5-xen-686: kernel BUG at /buildd/buildd-linux-2.6_2.6.32-24-i386-JPvGSk/linux-2.6-2.6.32/debi an/build/source_i386_xen/drivers/md/md.c: 6192!
On Sat, Oct 09, 2010 at 04:03:49PM +, Clint Adams wrote: Package: linux-image-2.6.32-5-xen-686 Version: 2.6.32-24 I am experiencing various problems with I/O of domU's and dom0 choking when using drbd-backed Xen VMs. I saw this message on console after a failed attempt to reboot: (hand-transcribed) kernel BUG at /buildd/buildd-linux-2.6_2.6.32-24-i386-JPvGSk/linux-2.6-2.6.32/debian/build/source_i386_xen/drivers/md/md.c:6192! invalid opcode: [#1] SMP hm.. wonder if it is related to: http://www.spinics.net/lists/raid/msg21823.html Upstream was pondering removal of this BUG_ON(): http://www.spinics.net/lists/raid/msg28563.html But no fix has gone upstream for this, afaict. -- 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/20101011165703.gc31...@lackof.org
Bug#592497: unrelated issue
fyi, messages #27, #32 and #37 refer to an issue unrelated to this bug report. Please disregard. Suporte, Please file a separate bug for the issue you are seeing if you wish to continue seeking a fix. -- dann frazier -- 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/20101011192413.gf31...@lackof.org
Bug#592497: linux-image-2.6.32-bpo.5-amd64: strange memory messages
... and here's the missing attachment.
diff -urpN linux-source-2.6.32.orig/drivers/net/bnx2.c linux-source-2.6.32/drivers/net/bnx2.c
--- linux-source-2.6.32.orig/drivers/net/bnx2.c 2010-09-29 18:03:41.0 -0600
+++ linux-source-2.6.32/drivers/net/bnx2.c 2010-10-07 19:56:35.0 -0600
@@ -2650,13 +2650,13 @@ bnx2_set_mac_addr(struct bnx2 *bp, u8 *m
}
static inline int
-bnx2_alloc_rx_page(struct bnx2 *bp, struct bnx2_rx_ring_info *rxr, u16 index)
+bnx2_alloc_rx_page(struct bnx2 *bp, struct bnx2_rx_ring_info *rxr, u16 index, gfp_t gfp)
{
dma_addr_t mapping;
struct sw_pg *rx_pg = rxr-rx_pg_ring[index];
struct rx_bd *rxbd =
rxr-rx_pg_desc_ring[RX_RING(index)][RX_IDX(index)];
- struct page *page = alloc_page(GFP_ATOMIC);
+ struct page *page = alloc_page(gfp);
if (!page)
return -ENOMEM;
@@ -2691,7 +2691,7 @@ bnx2_free_rx_page(struct bnx2 *bp, struc
}
static inline int
-bnx2_alloc_rx_skb(struct bnx2 *bp, struct bnx2_rx_ring_info *rxr, u16 index)
+bnx2_alloc_rx_skb(struct bnx2 *bp, struct bnx2_rx_ring_info *rxr, u16 index, gfp_t gfp)
{
struct sk_buff *skb;
struct sw_bd *rx_buf = rxr-rx_buf_ring[index];
@@ -2699,7 +2699,7 @@ bnx2_alloc_rx_skb(struct bnx2 *bp, struc
struct rx_bd *rxbd = rxr-rx_desc_ring[RX_RING(index)][RX_IDX(index)];
unsigned long align;
- skb = netdev_alloc_skb(bp-dev, bp-rx_buf_size);
+ skb = __netdev_alloc_skb(bp-dev, bp-rx_buf_size, gfp);
if (skb == NULL) {
return -ENOMEM;
}
@@ -2950,7 +2950,7 @@ bnx2_rx_skb(struct bnx2 *bp, struct bnx2
int err;
u16 prod = ring_idx 0x;
- err = bnx2_alloc_rx_skb(bp, rxr, prod);
+ err = bnx2_alloc_rx_skb(bp, rxr, prod, GFP_ATOMIC);
if (unlikely(err)) {
bnx2_reuse_rx_skb(bp, rxr, skb, (u16) (ring_idx 16), prod);
if (hdr_len) {
@@ -3015,7 +3015,8 @@ bnx2_rx_skb(struct bnx2 *bp, struct bnx2
rx_pg-page = NULL;
err = bnx2_alloc_rx_page(bp, rxr,
- RX_PG_RING_IDX(pg_prod));
+ RX_PG_RING_IDX(pg_prod),
+ GFP_ATOMIC);
if (unlikely(err)) {
rxr-rx_pg_cons = pg_cons;
rxr-rx_pg_prod = pg_prod;
@@ -5153,7 +5154,7 @@ bnx2_init_rx_ring(struct bnx2 *bp, int r
ring_prod = prod = rxr-rx_pg_prod;
for (i = 0; i bp-rx_pg_ring_size; i++) {
- if (bnx2_alloc_rx_page(bp, rxr, ring_prod) 0)
+ if (bnx2_alloc_rx_page(bp, rxr, ring_prod, GFP_KERNEL) 0)
break;
prod = NEXT_RX_BD(prod);
ring_prod = RX_PG_RING_IDX(prod);
@@ -5162,7 +5163,7 @@ bnx2_init_rx_ring(struct bnx2 *bp, int r
ring_prod = prod = rxr-rx_prod;
for (i = 0; i bp-rx_ring_size; i++) {
- if (bnx2_alloc_rx_skb(bp, rxr, ring_prod) 0)
+ if (bnx2_alloc_rx_skb(bp, rxr, ring_prod, GFP_KERNEL) 0)
break;
prod = NEXT_RX_BD(prod);
ring_prod = RX_RING_IDX(prod);
Bug#592497: linux-image-2.6.32-bpo.5-amd64: strange memory messages
On Thu, Oct 07, 2010 at 10:32:18PM -0300, Suporte REMO wrote: Hi, I'm using the last lenny-backports kernel on a HP ProLiant ML350 G5 and have similar problem, but my system doesn't crach, only I see many errors in log (in annex). ii linux-image-2.6.32-bpo.5-amd642.6.32-23~bpo50+1 Linux 2.6.32 for 64-bit PCs I notice that in all cases in this bug report the driver Broadcom NetXtremeII (package firmware-bnx2) is in use. So, that can be the source of the problem. hmm... looks similar to this issue: https://bugzilla.redhat.com/show_bug.cgi?id=612861 Which was possibly fixed by: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a2df00aa33f741096e977456573ebb08eece0b6f The attached patch backports this to the Debian kernel. Would you be able to test it? For instructions on building a new kernel package w/ a patch see: http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official -- 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/20101008020007.ga18...@lackof.org
Bug#597576: [Secure-testing-team] Bug#597576: linux-image-2.6.32-5-amd64: 2.6.32-23 still vulnerable to CVE-2010-3301
On Mon, Sep 20, 2010 at 06:51:16PM -0400, Jon wrote: Package: linux-2.6 Version: 2.6.32-23 Justification: root security hole Severity: critical Tags: security The changelog says the CVE-2010-3301 was fixed in this update: * x86-64, compat (CVE-2010-3301): - Retruncate rax after ia32 syscall entry tracing - Test %rax for the syscall number, not %eax But a test of the exploit shows otherwise: n...@nobel:~(0)$ ./robert_you_suck resolved symbol commit_creds to 0x8106914d resolved symbol prepare_kernel_cred to 0x81069050 mapping at 3f8000 UID 1000, EUID:1000 GID:100, EGID:100 $ How so? UID 1000 isn't root... -- 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/20100920231910.ge13...@lackof.org
Bug#597232: xfs broken in linux-modules-2.6.26-2-xen-amd64
On Fri, Sep 17, 2010 at 01:34:15PM -0700, Mladen Vasic wrote: Package: linux-modules-2.6.26-2-xen-amd64 Version: 2.6.26-25lenny1 After today update from linux-modules-2.6.26-1-xen-amd64 to linux-modules-2.6.26-2-xen-amd64 xfs is not working. $modprobe xfs FATAL: Error inserting xfs (/lib/modules/2.6.26-2-xen-amd64/kernel/fs/xfs/xfs.ko): Unknown symbol in module, or unknown parameter (see dmesg) $dmsg [ 1770.259238] xfs: Unknown symbol compat_alloc_user_spac $uname -a Linux test1 2.6.26-2-xen-amd64 #1 SMP Tue Aug 31 11:17:26 UTC 2010 x86_64 GNU/Linux You need to also update linux-image-2.6.26-2-xen-amd64 and reboot. With both packages at version 2.6.26-25lenny1, I have no problems loading the xfs module. Can you verify this works for you? -- dann frazier -- 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/20100917213930.gb22...@lackof.org
Bug#595502: linux-image-2.6.32-5-mckinley: panics while loading INIT, IOMMU out of mapping resources
On Sat, Sep 04, 2010 at 05:38:13PM +0200, Thibaut VARÈNE wrote: Package: linux-image-2.6.32-5-mckinley Version: 2.6.32-20 Severity: grave Justification: renders system unusable System boots fine with linux-image-2.6.32-3-mckinley 2.6.32-9. Panics with 2.6.32-20 with: I/O MMU @ c000fed01000 is out of mapping resources fyi, my rx2600 boots fine on both 2.6.32-20 and 2.6.32-21. (ROM Version 2.31) -- 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/20100913220901.ga29...@lackof.org
Bug#595502: linux-image-2.6.32-5-mckinley: panics while loading INIT, IOMMU out of mapping resources
On Tue, Sep 14, 2010 at 12:48:22AM +0100, Ben Hutchings wrote: On Tue, 2010-09-14 at 01:19 +0200, Thibaut VARÈNE wrote: Le 14 sept. 10 à 01:11, Thibaut VARÈNE a écrit : Le 14 sept. 10 à 00:09, dann frazier a écrit : On Sat, Sep 04, 2010 at 05:38:13PM +0200, Thibaut VARÈNE wrote: Package: linux-image-2.6.32-5-mckinley Version: 2.6.32-20 Severity: grave Justification: renders system unusable System boots fine with linux-image-2.6.32-3-mckinley 2.6.32-9. Panics with 2.6.32-20 with: I/O MMU @ c000fed01000 is out of mapping resources fyi, my rx2600 boots fine on both 2.6.32-20 and 2.6.32-21. (ROM Version 2.31) This was a zx2000, same ROM, and I was about to try a rx2600. I guess this makes it moot ;P Just thinking out loud, but given the symptoms (disk errors) and the specifics of zx2000 vs rx2600, I'm guessing the IOMMU pukes on IDE, which rx2600 doesn't use for disks... That might be significant, since we've made the libata transition. Did you get a traceback for the kernel panic? Another datapoint - also was unable to reproduce on a zx2000 here, though mine uses contains only SCSI disks. -- dann frazier -- 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/20100914022257.gh29...@lackof.org
Re: netxen_nic support for unified firmware images
On Fri, Sep 03, 2010 at 11:55:42PM +0100, Ben Hutchings wrote: On Thu, 2010-09-02 at 17:20 -0600, dann frazier wrote: I'd like to propose we add support for unified firmware images for netxen nics for squeeze. HP ships servers with netxen controllers, and we've seen problems with old firmware/new driver combinations - basically the network runs ridiculously slow, causing network installs to take many hours. Flashing to the latest firmware resolves the issues - but flashing a system (or 50) before install can be a pain (once you've finally identified firmware as the problem). There's an online flash tool you can use post-install but, as of this writing, it is not very Debian friendly (distributed in an RPM, needs out of tree driver, script has incompatible paths/bashisms). netxen_nic can load updated firmware via request_firmware, and recently a firmware blob got accepted into the linux-firmware tree w/ a non-free-compatible license, specifically for this reason. However, this blob is in a newer unified format that the 2.6.32 driver didn't yet support. This patch cherry picks the change to add support for the unified rom image, as well as several fixes that came after. I prefer to deal with individual patches as it's easier to compare them with the upstream version that way. I'm not sure how much that matters here. Thanks for the review, and sorry for my slow response. Yeah, I also like to keep track of individual patches, but in this case I did so by just keeping the changeset summaries at the top of the unified patch. I have all of them stored as such in a local git tree if we decide to go that way. In addition, I'd like to also package the firmware blob. The blob alone is 1.7 MB, whereas the entire contents of firmware-linux-nonfree is 940K. That implies to me that it should be a new binary package, but I don't feel strongly about that. It should be. k. I'll commit the changes I have queued for this new package then. Any objections to these changes? AFAIK only HP shipped many of these NICs so if you (wearing your HP hat) are happy with the changes then that's good enough for me. da...@hp.com I am, thanks. -- dann frazier -- 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/20100908153602.ga31...@lackof.org
netxen_nic support for unified firmware images
I'd like to propose we add support for unified firmware images for netxen nics for squeeze. HP ships servers with netxen controllers, and we've seen problems with old firmware/new driver combinations - basically the network runs ridiculously slow, causing network installs to take many hours. Flashing to the latest firmware resolves the issues - but flashing a system (or 50) before install can be a pain (once you've finally identified firmware as the problem). There's an online flash tool you can use post-install but, as of this writing, it is not very Debian friendly (distributed in an RPM, needs out of tree driver, script has incompatible paths/bashisms). netxen_nic can load updated firmware via request_firmware, and recently a firmware blob got accepted into the linux-firmware tree w/ a non-free-compatible license, specifically for this reason. However, this blob is in a newer unified format that the 2.6.32 driver didn't yet support. This patch cherry picks the change to add support for the unified rom image, as well as several fixes that came after. In addition, I'd like to also package the firmware blob. The blob alone is 1.7 MB, whereas the entire contents of firmware-linux-nonfree is 940K. That implies to me that it should be a new binary package, but I don't feel strongly about that. Any objections to these changes? diff --git a/sid/linux-2.6/debian/changelog b/sid/linux-2.6/debian/changelog index 56d05b1..2474c4a 100644 --- a/sid/linux-2.6/debian/changelog +++ b/sid/linux-2.6/debian/changelog @@ -35,6 +35,9 @@ linux-2.6 (2.6.32-22) UNRELEASED; urgency=low [ Bastian Blank ] * Use Breaks instead of Conflicts. + [ dann frazier ] + * netxen_nic: add support for loading unified firmware images + -- Ben Hutchings b...@decadent.org.uk Fri, 27 Aug 2010 08:38:26 +0100 linux-2.6 (2.6.32-21) unstable; urgency=high diff --git a/sid/linux-2.6/debian/patches/features/all/netxen-unified-fw-image.patch b/sid/linux-2.6/debian/patches/features/all/netxen-unified-fw-image.patch new file mode 100644 index 000..04294e0 --- /dev/null +++ b/sid/linux-2.6/debian/patches/features/all/netxen-unified-fw-image.patch @@ -0,0 +1,1566 @@ +commit 5fe4d5c338291bbd504b8ebbd4d3931adfa61772 +Author: Amit Kumar Salecha amit.sale...@qlogic.com +Date: Mon Mar 29 02:43:44 2010 + + +netxen: fix fw load from file + +Rarely: Fw file size can be unaligned to 8. + +Signed-off-by: Amit Kumar Salecha amit.sale...@qlogic.com +Signed-off-by: David S. Miller da...@davemloft.net + +commit 3111bf7ed99902687728eeec2ad068c2a7f8e5f0 +Author: Rajesh K Borundia rajesh.borun...@qlogic.com +Date: Mon Mar 29 02:43:43 2010 + + +netxen: validate unified romimage + +Signed-off-by: Rajesh K Borundia rajesh.borun...@qlogic.com +Signed-off-by: Amit Kumar Salecha amit.sale...@qlogic.com + +Validate all sections of unified romimage, before accessing them, + to avoid seg fault. + +Signed-off-by: Amit Kumar Salecha amit.sale...@qlogic.com +Signed-off-by: David S. Miller da...@davemloft.net + +commit e9c75051c380aa07e237fd271a191f71cc5b79ef +Author: Amit Kumar Salecha amit.sale...@qlogic.com +Date: Fri Mar 26 00:30:07 2010 + + +netxen: fix bios version calculation + +Bios sub version from unified fw image is calculated incorrect. + +Signed-off-by: Amit Kumar Salecha amit.sale...@qlogic.com +Signed-off-by: David S. Miller da...@davemloft.net + +commit 31ae5cfdfd99db77ef6f213d4c35422320356d3b +Author: Amit Kumar Salecha amit.sale...@qlogic.com +Date: Tue Dec 8 20:40:57 2009 + + +netxen: fix unified fw size check + +o Unified firmware image size can be 1 MB + +Signed-off-by: Amit Kumar Salecha amit.sale...@qlogic.com +Signed-off-by: David S. Miller da...@davemloft.net + +commit fd1ae25890ba3e63c62f4ba53519ec21bcc7181b +Author: Dhananjay Phadke dhanan...@netxen.com +Date: Sat Dec 5 12:23:56 2009 + + +netxen: fix firmware type check + +Unified firmware image may not contain MN type of firmware. +Driver should fall back to NOMN firmware type instead +of going to flash. + +Signed-off-by: Dhananjay Phadke dhanan...@netxen.com +Signed-off-by: Amit Kumar Salecha amit.sale...@qlogic.com +Signed-off-by: David S. Miller da...@davemloft.net + +commit 629073465ea87a2f5792225dc4647b9f965ee2d3 +Author: Amit Kumar Salecha a...@netxen.com +Date: Sat Oct 24 16:03:58 2009 + + +netxen: support for new firmware file format + +Add support for extracting firmware from a unified +file format which embeds firmware images for all chip +revisions. Fallback to orginal file formats if new +image is not found. + +Signed-off-by: Amit Kumar Salecha a...@netxen.com +Signed-off-by: Dhananjay Phadke dhanan...@netxen.com +Signed-off-by: David S. Miller da...@davemloft.net + +commit 57cf596bef5692dc543b846cd1c05ea075270741 +Author: Dhananjay Phadke
Re: mlock/guard page/xen-tools lenny
On Tue, Aug 31, 2010 at 11:58:32AM +0100, Ian Campbell wrote:
On Tue, 2010-08-31 at 11:28 +0100, Ian Campbell wrote:
On Tue, 2010-08-31 at 11:00 +0100, Ian Campbell wrote:
On Mon, 2010-08-30 at 22:57 -0600, dann frazier wrote:
On Mon, Aug 30, 2010 at 08:22:23AM -0600, dann frazier wrote:
hey Ian,
I haven't seen any reports of xen problems w/ the latest lenny DSA
that added the guard page code. I looked at backporting the 3 patches
from Linus - but the mlock patch touches code that didn't exist in
.26, so I'm wondering if that patch is just not needed.
fyi, I setup a Xen/lenny system and didn't have any problems w/
save/restore, so we're good afaict :)
Thanks, I can't see code in the Lenny kernel equivalent to that which
was broken either.
I wrote a pretty skanky test program to test for the issue (mlock.c,
attached, run with ./mlock lock to trigger the issue). I don't have a
Lenny system to hand right not where I can run it but if you still have
a Lenny system setup then it might be interesting to try. (the test
program doesn't actually require Xen to demonstrate the issue so any
Lenny system should do).
I installed up a Lenny VM and ran the test case there and it did
fail :-(.
Thanks for the test case, that's very helpful.
I can reproduce. 2.6.26-24 does not fail, 2.6.26-24lenny1 does.
However, unless we come across a report of an actual failure with the
real toolstack I don't think it is worth worrying about.
FWIW I think the below is the moral equivalent of:
commit 0e8e50e20c837eeec8323bba7dcd25fe5479194c
Author: Linus Torvalds torva...@linux-foundation.org
Date: Fri Aug 20 16:49:40 2010 -0700
mm: make stack guard page logic use vm_prev pointer
I've actually already included a backport for this in 2.6.26-25 (in
p-u), and I've verified that your test case does not fail:
da...@dl380g5:~$ ./mlock lock
pad1 at 0xffc15380-0xffc1737f
LCK at 0xffc17380-0xffc17384
pad2 at 0xffc17384-0xffc19383
esp: 0xffc15360
locking 0xffc17380-0xffc17384 - 0xffc17000-0xffc18000 - 0
minor faults: 157 - 157
major faults: 0 - 0
So looks like we're ok?
-dann
Like the mlock() change previously, this makes the stack guard
check
code use vma-vm_prev to see what the mapping below the current
stack
is, rather than have to look it up with find_vma().
Also, accept an abutting stack segment, since that happens
naturally if
you split the stack with mlock or mprotect.
Tested-by: Ian Campbell i...@hellion.org.uk
Signed-off-by: Linus Torvalds torva...@linux-foundation.org
without the reliance on vm_prev (IOW it implements only the Also, ...
bit. I'm just building a test kernel to check it now.
$ cat
debian/patches/bugfix/all/mm-stack-guard-accept-abutting-stack-segment.patch
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2287,11 +2287,18 @@
{
address = PAGE_MASK;
if ((vma-vm_flags VM_GROWSDOWN) address == vma-vm_start) {
- address -= PAGE_SIZE;
- if (find_vma(vma-vm_mm, address) != vma)
- return -ENOMEM;
+ struct vm_area_struct *prev = find_vma(vma-vm_mm, address -
PAGE_SIZE);
- expand_stack(vma, address);
+ /*
+ * Is there a mapping abutting this one below?
+ *
+ * That's only ok if it's the same stack mapping
+ * that has gotten split..
+ */
+ if (prev prev-vm_end == address)
+ return prev-vm_flags VM_GROWSDOWN ? 0 : -ENOMEM;
+
+ expand_stack(vma, address - PAGE_SIZE);
}
return 0;
}
--
dann frazier
--
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/20100831170445.ge23...@lackof.org
mlock/guard page/xen-tools lenny
hey Ian, I haven't seen any reports of xen problems w/ the latest lenny DSA that added the guard page code. I looked at backporting the 3 patches from Linus - but the mlock patch touches code that didn't exist in .26, so I'm wondering if that patch is just not needed. -- dann frazier -- 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/20100830142223.ga23...@lackof.org
Re: mlock/guard page/xen-tools lenny
On Mon, Aug 30, 2010 at 08:22:23AM -0600, dann frazier wrote: hey Ian, I haven't seen any reports of xen problems w/ the latest lenny DSA that added the guard page code. I looked at backporting the 3 patches from Linus - but the mlock patch touches code that didn't exist in .26, so I'm wondering if that patch is just not needed. fyi, I setup a Xen/lenny system and didn't have any problems w/ save/restore, so we're good afaict :) -- dann frazier -- 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/20100831045717.gd23...@lackof.org
Bug#570382: after upgrade: vlogin: openpty(): No such file or directory
On Fri, Aug 27, 2010 at 12:13:00PM -0600, Scott Barker wrote: After applying the latest kernel package, all of my VMs started just fine as well. All i386. Well, this is good news I suppose.. personally I'd rather have something 100% reproducing than intermittently failing :( -- dann frazier -- 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/20100827220255.gd23...@lackof.org
Re: Ubuntu+BFS
On Mon, Jul 26, 2010 at 12:53:57PM -0400, Daniel Hollocher wrote: Hey folks, I'm not confident that this is the right list to ask. Someone suggested this list, but if I should post in Ubuntu land lists, let me know. Is your goal to create a kernel package w/ the Ubuntu source to run on *Debian*? If not, then you do probably need to ask on an Ubuntu list. The kernel packaging between the two is significantly different. I am working on a linux package [0] that consists of the Ubuntu kernel patched with the ck patches [1]. Right now, I do this in a seemingly hackish way, based off the work of the person who was doing it before me[2]. This person put together a patch which I believe edits the package name in a whole bunch of places, and disables some of the sanity checks to get it working in a ppa setting. What I have been doing is to just update this patch for new kernel releases, ie add this, remove that, update the line counts kinda thing. It is working for me. My question is, is this really the best way to do things? It is hard to tell through the different docs that I found through google... Thanks, Dan [0] https://launchpad.net/~chogydan/+archive/ppa [1] http://users.on.net/~ckolivas/kernel/ [2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/424927 see the linux-rename patch -- dann frazier -- 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/20100726171715.ga25...@lackof.org
Bug#588574: bisect results
I was able to easily reproduce it by running 'make check'. The first test case (gcore) reliably fails with either a system hang or an MCA. Bisect shows that it was introduced by the following commit: 62eede62dafb4a6633eae7ffbeb34c60dba5e7b1 is the first bad commit commit 62eede62dafb4a6633eae7ffbeb34c60dba5e7b1 Author: Hugh Dickins hugh.dick...@tiscali.co.uk Date: Mon Sep 21 17:03:34 2009 -0700 mm: ZERO_PAGE without PTE_SPECIAL Reinstate anonymous use of ZERO_PAGE to all architectures, not just to those which __HAVE_ARCH_PTE_SPECIAL: as suggested by Nick Piggin. Contrary to how I'd imagined it, there's nothing ugly about this, just a zero_pfn test built into one or another block of vm_normal_page(). But the MIPS ZERO_PAGE-of-many-colours case demands is_zero_pfn() and my_zero_pfn() inlines. Reinstate its mremap move_pte() shuffling of ZERO_PAGEs we did from 2.6.17 to 2.6.19? Not unless someone shouts for that: it would have to take vm_flags to weed out some cases. Signed-off-by: Hugh Dickins hugh.dick...@tiscali.co.uk Cc: Rik van Riel r...@redhat.com Reviewed-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com Cc: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com Cc: Nick Piggin npig...@suse.de Cc: Mel Gorman m...@csn.ul.ie Cc: Minchan Kim minchan@gmail.com Cc: Ralf Baechle r...@linux-mips.org Signed-off-by: Andrew Morton a...@linux-foundation.org Signed-off-by: Linus Torvalds torva...@linux-foundation.org I also checked SLES11 SP1, but this issue was not reproducible. I went through the config differences found that the relevant difference is PAGE_SIZE. For whatever reason, 64KB pages (which SLES uses) masks the issue, while 16KB (Debian) does not. -- 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/20100720172236.ge26...@ldl.fc.hp.com
looking for gfs2/lenny users
The kernel in proposed-updates (2.6.26-23) includes a couple of security fixes for the gfs2 filesystem. I've performed some smoke testing in a VM, but I'm looking for users who might have actual (non-production) clusters to do some pre-release testing. -- dann frazier -- 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/20100620192335.gg32...@lackof.org
Bug#561203: threads and fork on machine with VIPT-WB cache
On Fri, Jun 04, 2010 at 12:44:55PM +0200, Thibaut VARENE wrote: On Fri, Jun 4, 2010 at 7:21 AM, dann frazier da...@debian.org wrote: On Fri, Jun 04, 2010 at 10:03:07AM +0900, NIIBE Yutaka wrote: Modestas Vainius wrote: Note that Debian's buildds run a UP kernel, so as soon as those fixes go upstream we can pull them in. Thanks for all your work here! Well, as long as this is unfixed or at least common, I don't see how hppa can be considered to be a release arch. Is that UP patch available somewhere? My case and my analysis talked about UP kernel, and John David Anglin made a patch: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561203#144 After that, the discussion went to SMP cases. It would be better to evaluate the patch again, and make sure it works for UP case and fix failures of buildd, then apply for Linux in Debian (only) for HPPA. I know that the patch is not that ideal because it touches architecture independent part of Linux, but it is worth for Linux in Debian (or Linux for the HPPA machine of buildd, at least). I'm happy to test the patch if necessary to help push this change upstream. However, we do need the change to go upstream before we can include it in the Debian kernel. Just for reference, I've summarized the test cases and related patches here: http://wiki.parisc-linux.org/TestCases Cool - that is helpful. I've updated the kernel on peri/penalosa with the various patches listed there that have gone upstream, but I'm not seeing better results with any failing packages. btw, I thought it would be useful to edit that page and tag each patch with its status in Debian (in-official-kernel, installed-on-buildds, etc), but the page appears to be immutable. -- dann frazier -- 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/20100607171136.ga14...@lackof.org
Bug#561203: threads and fork on machine with VIPT-WB cache
On Fri, Jun 04, 2010 at 10:03:07AM +0900, NIIBE Yutaka wrote: Modestas Vainius wrote: Note that Debian's buildds run a UP kernel, so as soon as those fixes go upstream we can pull them in. Thanks for all your work here! Well, as long as this is unfixed or at least common, I don't see how hppa can be considered to be a release arch. Is that UP patch available somewhere? My case and my analysis talked about UP kernel, and John David Anglin made a patch: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561203#144 After that, the discussion went to SMP cases. It would be better to evaluate the patch again, and make sure it works for UP case and fix failures of buildd, then apply for Linux in Debian (only) for HPPA. I know that the patch is not that ideal because it touches architecture independent part of Linux, but it is worth for Linux in Debian (or Linux for the HPPA machine of buildd, at least). I'm happy to test the patch if necessary to help push this change upstream. However, we do need the change to go upstream before we can include it in the Debian kernel. -- 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/20100604052106.gc15...@lackof.org
Bug#561203: threads and fork on machine with VIPT-WB cache
On Wed, Jun 02, 2010 at 01:16:01PM -0400, John David Anglin wrote: On Wed, 02 Jun 2010, Modestas Vainius wrote: Hello, this bug [1] is back to the very common department with eglibc 2.11 (libc6- dev_2.11.1-1) builds. Majority of KDE applications are failing to build on hppa again. Is there really nothing what could be done to fix it? I will just say it is very tricky. I think a fix is possible (arm and mips had similar cache problems) but the victim replacement present in PA8800/PA8900 caches makes the problem especially difficult for hardware using these processors. I have spent the last few months testing various alternatives and have now done hundreds of kernel builds. I did post some experimental patches that fix the problem on UP kernels. However, the problem is not resolved for SMP kernels. Note that Debian's buildds run a UP kernel, so as soon as those fixes go upstream we can pull them in. Thanks for all your work here! The minifail test is a good one to demonstrate the problem. Indeed, a very similar test was given in the thread below: http://readlist.com/lists/vger.kernel.org/linux-kernel/54/270861.html This thread also discusses the PA8800 problem: http://readlist.com/lists/vger.kernel.org/linux-kernel/54/271417.html I currently surmise that we have a problem with the cache victim replacement, although the cause isn't clear. I did find recently that the cache prefetch in copy_user_page_asm extends to the line beyond the end of the page, but fixing this doesn't resolve the problem. I am still experimenting with using equivalent aliasing. It does help to flush in ptep_set_wrprotect. Dave -- dann frazier -- 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/20100602175616.ga23...@lackof.org
Bug#583139: linux-2.6: no DHCP offers on r8169
[Please keep the bug # in the CC] On Thu, May 27, 2010 at 11:08:09AM +0200, Alexandre Rossi wrote: Hi, Thanks for the report. I don't see anything in -22 that looks like it would've affected your setup, but in -22lenny1 there is a security fix for the r8169 driver. Would you mind retesting -22 just to be sure? Yep me neither, that's why I tested multiple times... But just to be sure, I just tested another time, and my first results are not consistent with what I found again. I've been running for about a day with 2.6.26-22 and I could not reproduce. I'll try again to upgrade to -22lenny1 tonight. Ok, sounds good. Also, please supply the output of 'dmesg' on your system after the dhcp fails on -22lenny1. It might be useful to see the output on -21lenny4 as well for comparison. Not much interesting in those. In the following, r8169=eth0 and eth1 is another interface running with 8139too. For 2.6.26-22lenny1 : -- [0.00] Linux version 2.6.26-2-openvz-amd64 (Debian 2.6.26-22lenny1) (dan n...@debian.org) (gcc version 4.1.3 20080704 (prerelease) (Debian 4.1.2-25)) #1 SM P Wed May 12 18:14:56 UTC 2010 [...] [ 23.631312] r8169: eth0: link up [ 86.387430] eth1: link up, 100Mbps, full-duplex, lpa 0x41E1 [ 86.863726] NET: Registered protocol family 10 -- For 2.6.26-22 : -- [0.00] Linux version 2.6.26-2-openvz-amd64 (Debian 2.6.26-22) (da...@deb ian.org) (gcc version 4.1.3 20080704 (prerelease) (Debian 4.1.2-25)) #1 SMP Tue Mar 9 17:24:55 UTC 2010 [...] [ 22.893548] r8169: eth0: link up [ 71.346600] r8169: eth0: link down [ 89.546732] eth1: link up, 100Mbps, full-duplex, lpa 0x41E1 -- For 2.6.26-21lenny4 (eth1, the next inerface, is up earlier because DHCP on eth0=r8169 succeeds) : -- [0.00] Linux version 2.6.26-2-openvz-amd64 (Debian 2.6.26-21lenny4) (da...@debian.org) (gcc version 4.1.3 20080704 (prerelease) (Debian 4.1.2-25)) #1 SMP Tue Mar 9 23:10:10 UTC 2010 [...] [ 32.418312] r8169: eth0: link up [ 37.406798] eth1: link up, 100Mbps, full-duplex, lpa 0x41E1 -- 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/20100527142100.gb25...@lackof.org
Bug#583139: linux-2.6: no DHCP offers on r8169
On Tue, May 25, 2010 at 07:43:00PM +0200, Alexandre Rossi wrote: Package: linux-2.6 Version: 2.6.26-22lenny1 Severity: important Hi, I get no DHCP offers on the r8169 device since the upgrade to 2.6.26-22lenny1. Reverting to 2.6.26-22 does not fix the problem. Reverting to 2.6.26-21lenny4 *does* fix the problem. Please contact me for more info. Alex, Thanks for the report. I don't see anything in -22 that looks like it would've affected your setup, but in -22lenny1 there is a security fix for the r8169 driver. Would you mind retesting -22 just to be sure? Also, please supply the output of 'dmesg' on your system after the dhcp fails on -22lenny1. It might be useful to see the output on -21lenny4 as well for comparison. -- 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/20100525195948.ga8...@lackof.org
Bug#573071:
On Wed, May 12, 2010 at 07:03:25PM +0200, Werner Opriel wrote: Am Dienstag, 11. Mai 2010 schrieb dann frazier: On Tue, May 11, 2010 at 09:52:34AM +0200, Werner Opriel wrote: I haven't been able to reproduce this issue on my systems, for whatever reason. Would you be able to verify that this build fixes it for you? http://people.debian.org/~dannf/bugs/573071/ Sorry, i didn't mentioned that i'm using linux-image-2.6.26-2-686-bigmem (2.6.26-21lenny4) on Debian 5.0.4, 32 bits on a AMD64 Board. The behaviour is nearly the same as described with the 64bit kernel. I would like to verify this build as soon as it is available for me. Thanks a lot. i386 builds are available in the same location now. Installing the linux-image-2.6.26-2-686-bigmem_2.6.26-22lenny1_i386.deb fixed the problem for me. Your fixed kernel let me boot my guests, Debian squeeze (kernel 2.6.30 / 2.6.32) , as well as xubuntu (2.6.31), with no problems. Thank you! Great - thanks for testing. -- dann frazier -- 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/20100512172728.ga16...@lackof.org
Bug#573071:
On Tue, May 11, 2010 at 09:52:34AM +0200, Werner Opriel wrote: I haven't been able to reproduce this issue on my systems, for whatever reason. Would you be able to verify that this build fixes it for you? http://people.debian.org/~dannf/bugs/573071/ Sorry, i didn't mentioned that i'm using linux-image-2.6.26-2-686-bigmem (2.6.26-21lenny4) on Debian 5.0.4, 32 bits on a AMD64 Board. The behaviour is nearly the same as described with the 64bit kernel. I would like to verify this build as soon as it is available for me. Thanks a lot. i386 builds are available in the same location now. -- 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/20100511214445.gd5...@lackof.org
Bug#580710: linux-base: elilo needs simpler assignments
On Tue, May 11, 2010 at 04:12:54AM +0100, Ben Hutchings wrote:
On Sat, 2010-05-08 at 21:56 +0100, Ben Hutchings wrote:
On Fri, 2010-05-07 at 16:42 -0600, dann frazier wrote:
Source: linux-2.6
Version: 2.6.32-12
Severity: serious
Tags: patch
/usr/sbin/elilo didn't like the converted elilo.conf because it
doesn't support quoted strings, or spaces around '='.
Oops, when I read the code it looked like it was closely based on LILO
(like many other bootloaders). Apparently it's not so close.
[...]
I'll re-read the ELILO code to check exactly how its parser differs.
The versions in lenny (3.8-1) and sid (3.12-1) certainly look like they
support quoted filenames. Which version are you using?
3.12-2. It may have some support for quoted file names but, if so, it
is buggy. The problem I hit is this bit of code:
checkconf()
{
if [ -L $boot ] ; then
oldboot=$boot
boot=$(readlink -f $oldboot)
echo 12 $PRG: $oldboot is a symbolic link, using $boot
instead
fi
if [ ! -e $boot ] ; then
[...]
This will error out because $boot will still contain the quotes. So,
instead of looking for:
/dev/disk/by-uuid/9C73-E0C3
it will be looking for:
/dev/disk/by-uuid/9C73-E0C3
da...@krebs:~$ sudo elilo
elilo: /dev/disk/by-uuid/9C73-E0C3: No such file or directory
Loaded efivars kernel module to enable use of efibootmgr
I'd certainly argue that elilo *should* support quoted strings, but I
suspect we'll have to assume it doesn't at least for the
lenny-squeeze upgrade.
--
dann frazier
--
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/20100511035145.gf11...@lackof.org
Bug#580710: linux-base: elilo needs simpler assignments
Source: linux-2.6
Version: 2.6.32-12
Severity: serious
Tags: patch
/usr/sbin/elilo didn't like the converted elilo.conf because it
doesn't support quoted strings, or spaces around '='.
Instead of:
boot = /dev/disk/by-uuid/9C73-E0C3
it needs:
boot=/dev/disk/by-uuid/9C73-E0C3
The following patch fixes it, but it is pretty ugly. I would've
preferred to use the line that is commented out, but when I do I get
an extraneous newline both before and after the newly inserted line.
I assume this is due to how things are tokenized (I'm not enough of a
perl guy to grok it).
Also, it has a cosmetic issue where we lose the tab indention in stanzas.
We go from this:
image=/vmlinuz.old
label=LinuxOLD
root=/dev/sda2
read-only
initrd=/initrd.img.old
To this:
image=/vmlinuz.old
label=LinuxOLD
# root=/dev/sda2
root=UUID=170d52c1-c568-4bad-aass-be4248ad1af4
read-only
initrd=/initrd.img.old
(Now to reboot, to make sure it actually works...)
--
dann frazier
Index: debian/linux-base.postinst
===
--- debian/linux-base.postinst (revision 15638)
+++ debian/linux-base.postinst (working copy)
@@ -499,8 +499,8 @@
return @bdevs;
}
-sub lilo_update {
-my ($old, $new, $map) = @_;
+sub do_lilo_update {
+my ($old, $new, $map, $simple_assign) = @_;
my @tokens = lilo_tokenize($old);
my $i = 0;
my $in_generic = 1; # global or image=/vmlinuz or image=/vmlinuz.old
@@ -533,7 +533,12 @@
}
if (defined($new_value)) {
$new_value =~ s/\\//g;
- $text = \n# $name = $value\n$name = \$new_value\\n;
+ if ($simple_assign) {
+ $text = \n# $name = $value\n$name = \$new_value\\n;
+ } else {
+# $text = \n# $name=$value\n$name=$new_value\n;
+ $text = # $name=$value\n$name=$new_value;
+ }
} else {
$text .= $tokens[$i + 1][0] . $tokens[$i + 2][0];
}
@@ -546,6 +551,13 @@
}
}
+sub lilo_update {
+my ($old, $new, $map) = @_;
+my $simple_assign = 1;
+
+do_lilo_update($old, $new, $map, $simple_assign);
+}
+
sub lilo_post {
_system('lilo');
}
@@ -558,6 +570,13 @@
### ELILO
+sub elilo_update {
+my ($old, $new, $map) = @_;
+my $simple_assign = 0;
+
+do_lilo_update($old, $new, $map, $simple_assign);
+}
+
sub elilo_post {
_system('elilo');
}
@@ -970,7 +989,7 @@
{packages = 'elilo',
path = '/etc/elilo.conf',
list = \lilo_list,
- update = \lilo_update,
+ update = \elilo_update,
post_update = \elilo_post,
is_boot_loader = 1},
{packages = 'extlinux',
Bug#580422: [sparc] Irrecoverable deferred error trap
Source: linux-2.6
Version: 2.6.26-22
Severity: serious
Tags: patch, lenny
I have a sparc that fails to boot a lenny kernel.
The issue was reported upstream by another Debian user here:
http://permalink.gmane.org/gmane.linux.ports.sparc/13092
And was resolved by the following patch:
commit bdd32ce95f79fb5cc964cd789d7ae4500bba7c6f
Author: David S. Miller da...@davemloft.net
Date: Sun Apr 4 01:12:50 2010 -0700
sunxvr500: Ignore secondary output PCI devices.
These just represent the secondary and further heads attached to the
card, and they have different sets of PCI bar registers to map.
So don't try to drive them in the main driver.
Reported-by: Frans van Berckel fberc...@xs4all.nl
Tested-by: Frans van Berckel fberc...@xs4all.nl
Signed-off-by: David S. Miller da...@davemloft.net
diff --git a/drivers/video/sunxvr500.c b/drivers/video/sunxvr500.c
index 4cd5049..3803745 100644
--- a/drivers/video/sunxvr500.c
+++ b/drivers/video/sunxvr500.c
@@ -242,11 +242,27 @@ static int __devinit e3d_set_fbinfo(struct e3d_info *ep)
static int __devinit e3d_pci_register(struct pci_dev *pdev,
const struct pci_device_id *ent)
{
+ struct device_node *of_node;
+ const char *device_type;
struct fb_info *info;
struct e3d_info *ep;
unsigned int line_length;
int err;
+ of_node = pci_device_to_OF_node(pdev);
+ if (!of_node) {
+ printk(KERN_ERR e3d: Cannot find OF node of %s\n,
+ pci_name(pdev));
+ return -ENODEV;
+ }
+
+ device_type = of_get_property(of_node, device_type, NULL);
+ if (!device_type) {
+ printk(KERN_INFO e3d: Ignoring secondary output device
+ at %s\n, pci_name(pdev));
+ return -ENODEV;
+ }
+
err = pci_enable_device(pdev);
if (err 0) {
printk(KERN_ERR e3d: Cannot enable PCI device %s\n,
@@ -265,13 +281,7 @@ static int __devinit e3d_pci_register(struct pci_dev *pdev,
ep-info = info;
ep-pdev = pdev;
spin_lock_init(ep-lock);
- ep-of_node = pci_device_to_OF_node(pdev);
- if (!ep-of_node) {
- printk(KERN_ERR e3d: Cannot find OF node of %s\n,
- pci_name(pdev));
- err = -ENODEV;
- goto err_release_fb;
- }
+ ep-of_node = of_node;
/* Read the PCI base register of the frame buffer, which we
* need in order to interpret the RAMDAC_VID_*FB* values in
--
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/20100505212020.gg8...@lackof.org
Re: drbd in linux-2.6
On Tue, Mar 30, 2010 at 09:31:20AM -0600, dann frazier wrote: drbd maintainers, As you no doubt know, linux-modules-extra has been dropped for squeeze. The recommended[1] direction for building out-of-tree module is to either: a) get merged into linux-2.6 b) use the dkms framework DRBD is now merged upstream, so it seems like a good candidate for option a. Do the drbd8 maintainers know of any issue with that (userspace tool compatability, etc)? Are you ok with dropping the drbd8-source binary package if we include this in linux-2.6? I've backported the latest upstream DRBD bits into our kernel targeted at squeeze: http://people.debian.org/~dannf/drbd/ I'd appreciate it if an existing drbd user could test it. I didn't hear back from the drbd maintainers, but I did get some testing feedback from a drbd user (thanks to Lukasz Oles, bcc'd) On Tue, Apr 06, 2010 at 11:41:33PM +0200, ?ukasz Ole? wrote: I tested drbd in primary/primay mode with ocfs2 on top of it, and it seems to work fine. I tried full resynchronization and copying file to both nodes and it worked. My plan is therefore to: 1) Commit these changes for inclusion in the next linux-2.6 upload 2) After that upload, I will file an RC bug to request the removal of the drbd8-source binary from the drbd8 source package Comments? -- dann frazier -- 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/20100406220954.ga13...@lackof.org
Re: drbd in linux-2.6
On Wed, Apr 07, 2010 at 12:02:00AM +0200, Moritz Muehlenhoff wrote: On Tue, Mar 30, 2010 at 04:02:22PM -0600, dann frazier wrote: On Tue, Mar 30, 2010 at 11:45:54PM +0200, Moritz Muehlenhoff wrote: On 2010-03-30, dann frazier da...@debian.org wrote: drbd maintainers, As you no doubt know, linux-modules-extra has been dropped for squeeze. The recommended[1] direction for building out-of-tree module is to either: a) get merged into linux-2.6 b) use the dkms framework DRBD is now merged upstream, so it seems like a good candidate for option a. Do the drbd8 maintainers know of any issue with that (userspace tool compatability, etc)? Are you ok with dropping the drbd8-source binary package if we include this in linux-2.6? I've backported the latest upstream DRBD bits into our kernel targeted at squeeze: http://people.debian.org/~dannf/drbd/ I'd appreciate it if an existing drbd user could test it. [1] http://lists.debian.org/debian-devel-announce/2009/10/msg3.html I've done the same 3-4 weeks ago and likewise send them the patch for testing, unfortunately they we unable to test it yet. Oh, sorry - I must've missed that. Did you get a response or just silence? I was thinking that if we didn't get a response in a couple of days, I could contact some of the drbd8 bug reporters and see if we can recruit them to test :) Sorry for the late response, I'm still in VAC more or less. DRBD maintainers said they wanted to look into it, but one of the maintainers had a ski accident and AFAICS noone found the time to test it over the course of the last two months. Oh, ok. Just before I read this I sent a message about some positive test results I got from a DRBD user. -- 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/20100406221125.gc9...@lackof.org
