Bug#987851: linux-version sort: argv and stdin behaviors differ

[dann frazier]

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

[dann frazier]

https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/32

Bug#965935: configure_networking() should wait for specified interface

[dann frazier]

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

[dann frazier]

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

[dann frazier]

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

[dann frazier]

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=sid&searchon=contents&keywords=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

[dann frazier]

On Thu, Dec 05, 2013 at 02:01:37PM +1100, Peter Chubb wrote:
> >>>>> "dann" == dann frazier  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

[dann frazier]

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

[dann frazier]

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

[dann frazier]

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

[dann frazier]

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

[dann frazier]

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

[dann frazier]

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

[dann frazier]

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

[dann frazier]

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

[dann frazier]

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

[dann frazier]

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)

[dann frazier]

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)

[dann frazier]

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)?

[dann frazier]

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)

[dann frazier]

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

[dann frazier]

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)

[dann frazier]

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)

[dann frazier]

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)

[dann frazier]

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 
> (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=markup&pathrev=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)

[dann frazier]

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)

[dann frazier]

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

[dann frazier]

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

[dann frazier]

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)

[dann frazier]

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

[dann frazier]

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

[dann frazier]

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

[dann frazier]

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

[dann frazier]

On Wed, Jul 20, 2011 at 09:19:07PM +0100, Alexander Clouter wrote:
> * dann frazier  [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

[dann frazier]

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  writes:
> > 
> > Hi,
> > 
> > > [   33.356789] [] (net_assign_generic+0x3c/0xbc) from 
> > > [] (ip6_tnl_init_net+0x98/0x19c [ip6_tunnel])
> > > [   33.367378] [] (ip6_tnl_init_net+0x98/0x19c [ip6_tunnel]) 
> > > from [] (register_pernet_operations+0x40/0xf4)
> > > [   33.378658] [] (register_pernet_operations+0x40/0xf4) from 
> > > [] (register_pernet_device+0x20/0x54)
> > > [   33.389240] [] (register_pernet_device+0x20/0x54) from 
> > > [] (ip6_tunnel_init+0xc/0x84 [ip6_tunnel])
> > > [   33.399915] [] (ip6_tunnel_init+0xc/0x84 [ip6_tunnel]) from 
> > > [] (do_one_initcall+0x6c/0x1e4)
> > > [   33.410062] [] (do_one_initcall+0x6c/0x1e4) from 
> > > [] (sys_init_module+0xc0/0x1f0)
> > > [   33.419241] [] (sys_init_module+0xc0/0x1f0) from 
> > > [] (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

[dann frazier]

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

[dann frazier]

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

[dann frazier]

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

[dann frazier]

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

[dann frazier]

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: F

Re: security impact of nfsd4_op_flags

[dann frazier]

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

[dann frazier]

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  [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

[dann frazier]

On Sun, Apr 03, 2011 at 01:21:03PM +0530, Kamalesh Babulal wrote:
> * dann frazier  [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 
> Reported-by: dann frazier 
> Signed-off-by: Kamalesh Babulal 
> cc: Paul E. McKenney 
> cc: Michael Neuling 
>   cc: Benjamin Herrenschmidt 
> cc: Anton Blanchard 
> cc: Kumar Gala 


-- 
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

[dann frazier]

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

[dann frazier]

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

[dann frazier]

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

[dann frazier]

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 
Date:   Sun Jan 16 10:09:13 2011 -0300

[media] radio-aimslab.c needs #include 


-- 
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

[dann frazier]

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

Re: 2.6.26-27

[dann frazier]

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#604457: fix verification

[dann frazier]

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

2.6.26-27

[dann frazier]

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#597658: linux-headers-2.6.32-5-amd64: Missing aesni-intel module in kernel

[dann frazier]

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]

[dann frazier]

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

[dann frazier]

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

[dann frazier]

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
>  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
> .  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
> .
> 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

[dann frazier]

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

[dann frazier]

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

[dann frazier]

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

Bug#602536: useless /dev/cciss/ device

[dann frazier]

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 
  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 
  Signed-off-by: Jens Axboe 

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

Re: Security: auto-loading protocol modules

[dann frazier]

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

Re: Minutes of the Debian linux-2.6 Group Meeting

[dann frazier]

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: Minutes of the Debian linux-2.6 Group Meeting

[dann frazier]

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

Bug#595502: linux-image-2.6.32-5-mckinley: panics while loading INIT, IOMMU out of mapping resources

[dann frazier]

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  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  
> > >> 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
> .  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

Bug#595502: linux-image-2.6.32-5-mckinley: panics while loading INIT, IOMMU out of mapping resources

[dann frazier]

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  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

Re: updated text

[dann frazier]

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

[dann frazier]

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

Re: item for kernel meeting -- NX emulation

[dann frazier]

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

item for kernel meeting -- NX emulation

[dann frazier]

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

Bug#600305: forcing dma mode

[dann frazier]

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#600305: forcing dma mode

[dann frazier]

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 ]

commit 1529c69adce1e95f7ae72f0441590c226bbac7fc
Author: Tejun Heo 
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 
Cc: Peer Chen 
Cc: sta...@kernel.org
Reported-by: Anders Østhus 
Reported-by: Andreas Graf 
Reported-by: Benoit Gschwind 
Reported-by: Damien Cassou 
Reported-by: tixet...@juno.com
Signed-off-by: Jeff Garzik 

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 
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_G

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

[dann frazier]

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#592497: unrelated issue

[dann frazier]

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#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!

[dann frazier]

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: linux-image-2.6.32-bpo.5-amd64: strange memory messages

[dann frazier]

... 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

[dann frazier]

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

[dann frazier]

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

[dann frazier]

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

[dann frazier]

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

Bug#595502: linux-image-2.6.32-5-mckinley: panics while loading INIT, IOMMU out of mapping resources

[dann frazier]

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

Re: netxen_nic support for unified firmware images

[dann frazier]

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

[dann frazier]

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   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 
+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 
+Signed-off-by: David S. Miller 
+
+commit 3111bf7ed99902687728eeec2ad068c2a7f8e5f0
+Author: Rajesh K Borundia 
+Date:   Mon Mar 29 02:43:43 2010 +
+
+netxen: validate unified romimage
+
+Signed-off-by: Rajesh K Borundia 
+Signed-off-by: Amit Kumar Salecha 
+
+Validate all sections of unified romimage, before accessing them,
+  to avoid seg fault.
+
+Signed-off-by: Amit Kumar Salecha 
+Signed-off-by: David S. Miller 
+
+commit e9c75051c380aa07e237fd271a191f71cc5b79ef
+Author: Amit Kumar Salecha 
+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 
+Signed-off-by: David S. Miller 
+
+commit 31ae5cfdfd99db77ef6f213d4c35422320356d3b
+Author: Amit Kumar Salecha 
+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 
+Signed-off-by: David S. Miller 
+
+commit fd1ae25890ba3e63c62f4ba53519ec21bcc7181b
+Author: Dhananjay Phadke 
+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 
+Signed-off-by: Amit Kumar Salecha 
+Signed-off-by: David S. Miller 
+
+commit 629073465ea87a2f5792225dc4647b9f965ee2d3
+Author: Amit Kumar Salecha 
+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 
+Signed-off-by: Dhananjay Phadke 
+Signed-off-by: David S. Miller 
+
+commit 57cf596bef5692dc543b846cd1c05ea075270741
+Author: Dhananjay Phadke 
+Date:   Fri Oct 16 15:50:10 2009 +
+
+netxen: fix error codes in for tools access
+    
+    [Backported to Debian's 2.6.26 by dann frazier ]
+
+Use -EIO or -EINVAL as error codes, these can get passed up
+to applications (tools).
+
+Signed-off-by: Dhananjay Phadke 
+Signed-off-by: David S. Miller 
+
+commit 1648870d11e31d16b0c44d9a104ec68ebb5d9b58
+Author: Amit Kumar Salecha 
+Date:   Fri Oct 1

Re: mlock/guard page/xen-tools & lenny

[dann frazier]

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 
> 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 
> Signed-off-by: Linus Torvalds 
> 
> 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

Re: mlock/guard page/xen-tools & lenny

[dann frazier]

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

mlock/guard page/xen-tools & lenny

[dann frazier]

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

Bug#570382: after upgrade: "vlogin: openpty(): No such file or directory"

[dann frazier]

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

[dann frazier]

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

[dann frazier]

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 
  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 
Cc: Rik van Riel 
Reviewed-by: KAMEZAWA Hiroyuki 
Cc: KOSAKI Motohiro 
Cc: Nick Piggin 
Cc: Mel Gorman 
Cc: Minchan Kim 
Cc: Ralf Baechle 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 

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

[dann frazier]

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

Re: [Debian-ha-maintainers] drbd in linux-2.6

[dann frazier]

On Thu, Jun 10, 2010 at 08:53:37PM +0200, Norbert Tretkowski wrote:
> Hi Dann,
> 
> Am Dienstag, den 06.04.2010, 16:09 -0600 schrieb dann frazier:
> >  2) After that upload, I will file an RC bug to request the removal of
> > the drbd8-source binary from the drbd8 source package
> 
> I finally found time to upload drbd8 with the -source package dropped.

Thanks!

> Do you intend to update the patch in linux-2.6 to drbd 8.3.8? If yes,
> please ping me, so I can update the drbd8-utils package (I think I
> should rename it to drbd-utils anyway) to 8.3.8 as well.

I don't have plans to update the patch - do you think we should?

-- 
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/20100610194456.gc25...@lackof.org

scheduling 2.6.26-23

[dann frazier]

SRM is wanting to do a 5.0.5 later this month, so I'd like to get a
new upload into p-u. I'll plan to do this on Saturday - please
let me know if you need more time for something.

-- 
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/20100610185203.gb25...@lackof.org

Bug#561203: threads and fork on machine with VIPT-WB cache

[dann frazier]

On Thu, Jun 10, 2010 at 07:30:45PM +0300, Modestas Vainius wrote:
> Hello,
> 
> On sekmadienis 06 Bir??elis 2010 04:01:23 Modestas Vainius wrote:
> > On penktadienis 04 Bir??elis 2010 08:21:06 dann frazier wrote:
> > > > 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.
> > 
> > I made a hackish patch for QProcess in Qt (usleep(1000) before fork())
> > which seems to reduce likelihood of the failure to very rare again. Once a
> > new revision of qt4-x11 is uploaded to sid (soon I believe), KDE
> > applications should be able to build again (hopefully).
> 
> qt4-x11/hppa 4:4.6.3-1 has recently been uploaded to incoming. It has my hppa 
> hack applied. Therefore please give back the following KDE packages on hppa:
> 
> kde4libs basket kdesvn webkitkde kraft konq-plugins

done.




-- 
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/20100610172715.ga25...@lackof.org

Bug#561203: threads and fork on machine with VIPT-WB cache

[dann frazier]

On Fri, Jun 04, 2010 at 12:44:55PM +0200, Thibaut VARENE wrote:
> On Fri, Jun 4, 2010 at 7:21 AM, dann frazier  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

[dann frazier]

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

[dann frazier]

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

[dann frazier]

[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

[dann frazier]

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:

[dann frazier]

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:

[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.



-- 
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

[dann frazier]

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 1>&2 "$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

[dann frazier]

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',