Bug#317258: Megaraid driver lost PCI ID mapping for NetRAID 1M 2M
Package: kernel-source-2.6.11
Version: 2.6.11-7
I have an HP Netserver loaded with Debian Etch and configured with an HP
NetRAID 2M raid card. Since the split of the PCI IDs between the megaraid
(legacy) and megaraid_mbox (new) drivers, this card is no longer recognized
by either driver.
The split was such that AMI Megaraid generations 1 2 stayed in megaraid
and generation 3 went to megaraid_mbox. Unfortunately, NetRAID 1M 2M use
a generation 3 PCI ID but isn't within the PCI ID table of the megaraid_mbox
driver. From googling the web, it would appear that the NetRAID 1M 2M
will never be supported by the new driver.
So I'm submitting two very small patches that add back support specifically
for these two cards into the megaraid driver's pci id table. This has been
tested as working with my setup which uses a NetRAID 2m using a 2.02
firmware. I note that megaraid is a very well tested driver in general with
this card and still includes code specifically to work around lack of 64 bit
addressing with older NetRAID 1M/2M 1.07/1.08/1.09 firmware. As such,
keeping these cards associated with the megaraid (legacy) driver seems like
the best idea.
Keep up the good work.
Kevin
Patches:
--- kernel-source-2.6.11/drivers/scsi/megaraid.h2005-03-01
23:38:09.0 -0800
+++ kernel-source-2.6.11.works/drivers/scsi/megaraid.h 2005-07-05
10:05:44.0 -0700
@@ -84,6 +84,10 @@
#define LSI_SUBSYS_VID 0x1000
#define INTEL_SUBSYS_VID 0x8086
+/* Sub-System Device IDs */
+#define HP_NETRAID1M_SUBSYS_DID0x60E7
+#define HP_NETRAID2M_SUBSYS_DID0x60E8
+
#define HBA_SIGNATURE 0x3344
#define HBA_SIGNATURE_471 0x
#define HBA_SIGNATURE_64BIT0x029
--- kernel-source-2.6.11/drivers/scsi/megaraid.c2005-06-16
08:06:21.0 -0700
+++ kernel-source-2.6.11.works/drivers/scsi/megaraid.c 2005-07-05
10:06:39.0 -0700
@@ -5037,6 +5037,10 @@
PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
{PCI_VENDOR_ID_AMI, PCI_DEVICE_ID_AMI_MEGARAID2,
PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
+ {PCI_VENDOR_ID_AMI, PCI_DEVICE_ID_AMI_MEGARAID3,
+ HP_SUBSYS_VID, HP_NETRAID1M_SUBSYS_DID, 0, 0, 0},
+ {PCI_VENDOR_ID_AMI, PCI_DEVICE_ID_AMI_MEGARAID3,
+ HP_SUBSYS_VID, HP_NETRAID2M_SUBSYS_DID, 0, 0, 0},
{0,}
};
MODULE_DEVICE_TABLE(pci, megaraid_pci_tbl);
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#80878: Find, compare and buy Business and Productivity Software and other Computer Software products.
Super software, swell prices, splendid service. http://vtysr.wl0tzdwptow3tfe.spurternj.com To him that you tell your secret you resign your liberty. They should rule who are able to rule best. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#67718: OS-Adobe-Macromedia etc All under $15-$99 CDS
Software distribution. http://jiwfw.d2hsycv6a5d2sed.priestshipcg.com Even pleasure itself is a toil. It's a poor sort of memory that only works backward. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317285: initrd-tools: mkinitrd infinite recursion f RAID component device file missing
Package: initrd-tools
Version: 0.1.81.1
Severity: normal
In trying to perform a new sarge install onto a multi-disk RAID array,
I ran into a problem which caused the install to hang when installing
the kernel package. Investigation revealed that the
/usr/sbin/mkinitrd script was falling into infinite recursion and
eventually failing.
The core cause of this was that my RAID array involved a partition on
the 9th IDE device position (hdi). The block devices for hdi were not
present in the /dev of the installation target. This apparently
caused mdadm -D (which is invoked in the function getraid_mdadm) to
output lines for some partitions without a device file. Something
like this (not the real output):
Number Major Minor RaidDevice State
0 310 active sync /dev/hda1
1 2211 active sync
The awk script in the getraid_mdadm function assumes that the final
field of these lines will always be a device file. In my case (where
the device file was missing), it added the word sync to the devices
variable. This caused the getroot function to be invoked with sync
as its argument. Because getroot was given a single argument which
was not a block device, this code got executed:
# Assume label or UUID.
eval $(
awk 'NR 2 { printf getroot -s %d %d\n, $1, $2 }' \
/proc/partitions
)
This generated multiple calls to getroot, one of which had major
number 9, so it called getraid_mdadm again. Thus, it recursed
infinitely. During this, the shell process ran out of file
descriptors, but continued for some time after that. It eventually
failed, but took more than an hour to do so.
I avoided this problem for my installation purposes by moving my disk
from hdi to hda. This made the device node for the partition present
in the filesystem (which included hda-hdh but not hdi), which made the
output of mdadm -D include a device file, which avoided the getroot
sync call, and allowed mkinitrd to complete.
--Ken Schalk ken at xorian dot net
P.S. There's a separate problem here in that the installation
filesystem was missing /dev/hdi* when I was clearly using it, but I'm
not sure which package to file that bug against. Could someone point
me in the right direction?
-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.8-2-k7
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Versions of packages initrd-tools depends on:
ii coreutils [fileutils] 5.2.1-2The GNU core utilities
ii cpio 2.5-1.2GNU cpio -- a program to manage ar
ii cramfsprogs 1.1-6 Tools for CramFs (Compressed ROM F
ii dash 0.5.2-5The Debian Almquist Shell
ii util-linux2.12p-4Miscellaneous system utilities
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317287: kernel-image-2.6.11-1-k7: Package configuration stops with error if wacom kernel modules are installed
Package: kernel-image-2.6.11-1-k7 Version: 2.6.11-5 Severity: normal The following error appears after apt-get upgrade (Messages were in german and translated into english): Prepare replacement for kernel-image-2.6.11-1-k7 2.6.11-5 (with .../kernel-image-2.6.11-1-k7_2.6.11-7_i386.deb) ... The directory /lib/modules/2.6.11-1-k7 still exists. Continuing as directed. Unpack replacement for kernel-image-2.6.11-1-k7 ... dpkg: Error while process /var/cache/apt/archives/kernel-image-2.6.11-1-k7_2.6.11-7_i386.deb (--unpack): try to overwrite »/lib/modules/2.6.11-1-k7/kernel/drivers/usb/input/wacom.ko« which is also in package wacom-kernel-modules-2.6.11-1-k7 dpkg-deb: Subprocess paste killed with Signal (data transfer interrupted (broken pipe)) The package wacom-kernel-modules-2.6.11-1-k7 is a self compiled kernel modul. The source is from package wacom-kernel-source. Is this modul already in the kernel-image Package now? Wacom Package: ii wacom-kernel-modules 0.6.6-7 wacom modules for Linux kernel-2.6.11-1-k7 ii wacom-kernel-source 0.6.6-7 source for the wacom binary modules -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-1-k7 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) (ignored: LC_ALL set to [EMAIL PROTECTED]) Versions of packages kernel-image-2.6.11-1-k7 depends on: ii coreutils [fileutils] 5.2.1-2The GNU core utilities ii fileutils 5.2.1-2The GNU file management utilities ii initrd-tools 0.1.81.1 tools to create initrd image for p ii module-init-tools 3.2-pre1-2 tools for managing Linux kernel mo kernel-image-2.6.11-1-k7 recommends no packages. -- no debconf information
Bug#317288: Something goes wrong during mail delivery
Sorry something goes wrong while mail delivery. This bug report or #317287 can be closed. -- Fingerprint: 66D4 DDEF 6F4E 5BB7 E88F 75BB 8511 B5F9 75CE AEAA PK: http://www.fh-merseburg.de/~wesemart/src/marwes.asc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#317286: Please backport support for Promise SATAII TX2/TX4 cards (from 2.6.11)
Processing commands for [EMAIL PROTECTED]: reassign 317286 kernel Bug#317286: Please backport support for Promise SATAII TX2/TX4 cards (from 2.6.11) Warning: Unknown package 'kernel-source' Bug reassigned from package `kernel-source' to `kernel'. -- Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317288: kernel-image-2.6.11-1-k7: Package configuration stops with error if wacom kernel modules are installed
On Thu, Jul 07, 2005 at 03:14:14PM +0200, Martin Wesemann wrote: ?/lib/modules/2.6.11-1-k7/kernel/drivers/usb/input/wacom.ko? which is also in package wacom-kernel-modules-2.6.11-1-k7 dpkg-deb: Subprocess paste killed with Signal (data transfer interrupted (broken pipe)) The package wacom-kernel-modules-2.6.11-1-k7 is a self compiled kernel modul. The source is from package wacom-kernel-source. Is this modul already in the kernel-image Package now? Probably. Installing your own modules into the /lib/modules/*/kernel/ hierarchy is always wrong, they must go into /lib/modules/*/package -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317285: marked as done (initrd-tools: mkinitrd infinite recursion f RAID component device file missing)
Your message dated Thu, 7 Jul 2005 16:15:06 +0200
with message-id [EMAIL PROTECTED]
and subject line Bug#317285: initrd-tools: mkinitrd infinite recursion f RAID
component device file missing
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--
Received: (at submit) by bugs.debian.org; 7 Jul 2005 13:08:06 +
From [EMAIL PROTECTED] Thu Jul 07 06:08:06 2005
Return-path: [EMAIL PROTECTED]
Received: from vanguard.xorian.net [63.114.52.26]
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1DqW6o-0004dg-00; Thu, 07 Jul 2005 06:08:06 -0700
Received: by vanguard.xorian.net (Postfix, from userid 1000)
id 2E59C1659; Thu, 7 Jul 2005 09:07:35 -0400 (EDT)
From: Ken Schalk [EMAIL PROTECTED]
To: Debian Bug Tracking System [EMAIL PROTECTED]
Subject: initrd-tools: mkinitrd infinite recursion f RAID component device file
missing
X-Debbugs-CC: Ken Schalk [EMAIL PROTECTED]
Message-Id: [EMAIL PROTECTED]
Date: Thu, 7 Jul 2005 09:07:35 -0400 (EDT)
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-11.0 required=4.0 tests=BAYES_00,HAS_PACKAGE,
X_DEBBUGS_CC autolearn=ham version=2.60-bugs.debian.org_2005_01_02
X-Spam-Level:
Package: initrd-tools
Version: 0.1.81.1
Severity: normal
In trying to perform a new sarge install onto a multi-disk RAID array,
I ran into a problem which caused the install to hang when installing
the kernel package. Investigation revealed that the
/usr/sbin/mkinitrd script was falling into infinite recursion and
eventually failing.
The core cause of this was that my RAID array involved a partition on
the 9th IDE device position (hdi). The block devices for hdi were not
present in the /dev of the installation target. This apparently
caused mdadm -D (which is invoked in the function getraid_mdadm) to
output lines for some partitions without a device file. Something
like this (not the real output):
Number Major Minor RaidDevice State
0 310 active sync /dev/hda1
1 2211 active sync
The awk script in the getraid_mdadm function assumes that the final
field of these lines will always be a device file. In my case (where
the device file was missing), it added the word sync to the devices
variable. This caused the getroot function to be invoked with sync
as its argument. Because getroot was given a single argument which
was not a block device, this code got executed:
# Assume label or UUID.
eval $(
awk 'NR 2 { printf getroot -s %d %d\n, $1, $2 }' \
/proc/partitions
)
This generated multiple calls to getroot, one of which had major
number 9, so it called getraid_mdadm again. Thus, it recursed
infinitely. During this, the shell process ran out of file
descriptors, but continued for some time after that. It eventually
failed, but took more than an hour to do so.
I avoided this problem for my installation purposes by moving my disk
from hdi to hda. This made the device node for the partition present
in the filesystem (which included hda-hdh but not hdi), which made the
output of mdadm -D include a device file, which avoided the getroot
sync call, and allowed mkinitrd to complete.
--Ken Schalk ken at xorian dot net
P.S. There's a separate problem here in that the installation
filesystem was missing /dev/hdi* when I was clearly using it, but I'm
not sure which package to file that bug against. Could someone point
me in the right direction?
-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.8-2-k7
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Versions of packages initrd-tools depends on:
ii coreutils [fileutils] 5.2.1-2The GNU core utilities
ii cpio 2.5-1.2GNU cpio -- a program to manage ar
ii cramfsprogs 1.1-6 Tools for CramFs (Compressed ROM F
ii dash 0.5.2-5The Debian Almquist Shell
ii util-linux2.12p-4Miscellaneous system utilities
-- no debconf information
---
Received: (at 317285-done) by bugs.debian.org; 7 Jul 2005 14:15:05 +
From [EMAIL PROTECTED] Thu Jul 07 07:15:05 2005
Return-path: [EMAIL PROTECTED]
Received: from baikonur.stro.at [213.239.196.228]
Bug#80878: Softwares CDS all software under $15 and $99!
Office XP - $60 http://qohr.oval9noz3godl76.romanej.com Pain is inevitable. Suffering is optional. Let each man exercise the art he knows. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#317288: kernel-image-2.6.11-1-k7: Package configuration stops with error if wacom kernel modules are installed
Processing commands for [EMAIL PROTECTED]: merge 317288 317287 Bug#317287: kernel-image-2.6.11-1-k7: Package configuration stops with error if wacom kernel modules are installed Bug#317288: kernel-image-2.6.11-1-k7: Package configuration stops with error if wacom kernel modules are installed Merged 317287 317288. reassign 317288 wacom-kernel-source Bug#317288: kernel-image-2.6.11-1-k7: Package configuration stops with error if wacom kernel modules are installed Bug#317287: kernel-image-2.6.11-1-k7: Package configuration stops with error if wacom kernel modules are installed Bug reassigned from package `kernel-image-2.6.11-1-k7' to `wacom-kernel-source'. stop Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317285: acknowledged by developer (Re: Bug#317285: initrd-tools: mkinitrd infinite recursion f RAID component device file missing)
indeed that's a possible workaround. well i assume that you are using a static /dev tree. in that case makedev handles which devices show up in /dev. as one can't populate every debian system with all possible devices, the maintainer maid a trade-off to cut after 8 discs, which should not be noticable for the vast majority. *I* didn't make any choice about what kind of /dev tree to use. The installer did. I couldn't find any place to select devfs, and I didn't find any difference between choosing a 2.4 or 2.6 kernel when starting the installer. While I agree that it would be impractical to populate a static /dev tree with all possible devices, it *would* be practical to populate a static /dev tree with all physical partitions used in RAID devices configured from the installer's partitioner. sure, read the man of MAKEDEV(8) it tells you how to create those needed nodes. I did try that. However, there's not really an opportunity to create additional device nodes during a from-scratch install. I tried several different ways to do that before the installation of the kernel-image package, but didn't come up with one that worked. (Hence my falling back on the approach of moving the drive for hdi to hda.) Of course none of this is to do with initrd-tools, however: initrd can't possibly work for non existing device nodes. I'm not suggesting that it should. However, sitting in infinite recursion during an install for over an hour with no indication to the user of either progress or problems is profoundly unhelpful. (I had to spend several days figuring out what was going wrong, and many people would not be capable of debugging this kind of issue.) To me, such behavior does not seem acceptable, and I would argue that it is, in fact, a bug. This particular problem could be detected and handled at several different points in the mkinitrd script. I'm attaching a patch which shows at least two different ways to avoid this long-running infinite recursion. --Ken mkinitrd.patch Description: Binary data
Bug#317285: acknowledged by developer (Re: Bug#317285: initrd-tools: mkinitrd infinite recursion f RAID component device file missing)
On Thu, 07 Jul 2005, Kenneth C. Schalk wrote: *I* didn't make any choice about what kind of /dev tree to use. The installer did. I couldn't find any place to select devfs, and I didn't find any difference between choosing a 2.4 or 2.6 kernel when starting the installer. the etch installer will use udev than that sort of troubles, will not show up any more. if you insist feel free to reopen and reassign as installation-reports i guess debootstrap installs makedev. While I agree that it would be impractical to populate a static /dev tree with all possible devices, it *would* be practical to populate a static /dev tree with all physical partitions used in RAID devices configured from the installer's partitioner. well there is no logic right now for that stuff. sure, read the man of MAKEDEV(8) it tells you how to create those needed nodes. I did try that. However, there's not really an opportunity to create additional device nodes during a from-scratch install. I tried several different ways to do that before the installation of the kernel-image package, but didn't come up with one that worked. (Hence my falling back on the approach of moving the drive for hdi to hda.) well you can move to vc2 never had to invoke MAKEDEV, but i guess it should be possible. initrd can't possibly work for non existing device nodes. I'm not suggesting that it should. However, sitting in infinite recursion during an install for over an hour with no indication to the user of either progress or problems is profoundly unhelpful. (I had to spend several days figuring out what was going wrong, and many people would not be capable of debugging this kind of issue.) To me, such behavior does not seem acceptable, and I would argue that it is, in fact, a bug. This particular problem could be detected and handled at several different points in the mkinitrd script. I'm attaching a patch which shows at least two different ways to avoid this long-running infinite recursion. well initrd-tools has other severe problems that will not be curred as we are seeking for a complete remplacement. there is no point in working on that cornercase. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
qlogic firmware license
Hi, QLogic just emailed me the wording of their new license for qla2xxx firmware. Please let me know if anyone sees problems with this. Copyright (C) 2003 –2005 QLogic Corporation [QLA2x00] This program includes a device driver for Linux 2.6.x that is distributed with QLogic hardware specific firmware binary file. You may modify and redistribute the device driver code under the GNU Public License as published by the Free Software Foundation (version 2 or a later version) and/or under the following terms, as applicable: 1. Redistribution of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistribution in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The name of QLogic Corporation may not be used to endorse or promote products derived from this software without specific prior written permission REGARDLESS OF WHAT LICENSING MECHANISM IS USED OR APPLICABLE, THIS PROGRAM IS PROVIDED BY QLOGIC CORPORATION “AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. USER ACKNOWLEDGES AND AGREES THAT USE OF THIS PROGRAM WILL NOT CREATE OR GIVE GROUNDS FOR A LICENSE BY IMPLICATION, ESTOPPEL, OR OTHERWISE IN ANY INTELLECTUAL PROPERTY RIGHTS (PATENT, COPYRIGHT, TRADE SECRET, MASK WORK, OR OTHER PROPRIETARY RIGHT) EMBODIED IN ANY OTHER QLOGIC HARDWARE OR SOFTWARE EITHER SOLELY OR IN COMBINATION WITH THIS PROGRAM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#232135: kernel-image-2.4.24-1-386: No console output at boot and no virtual terminals
Herbert, It turns out I had a bad SVGA card. I replaced it and things are working much better. I would like to withdraw that bug. Sorry, Nathan Salwen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparing the first security update for kernel-source-2.6.8
On Thu, Jul 07, 2005 at 03:14:02PM -0600, dann frazier wrote: On Wed, 2005-06-29 at 16:09 +0900, Horms wrote: On Wed, Jun 29, 2005 at 11:14:20AM +0900, Horms wrote: On Tue, Jun 28, 2005 at 10:36:15PM +0200, Frederik Schueler wrote: Hello, I would like to start preparing a seurity update for kernel-source-2.6.8 in sarge, wich released with version 2.6.8-16. In sarge-security we have an old 2.6.15sarge1 wich never got released. Does anyone object if I update those sources to the revision in sarge, and we start building 2.6.8-16sarge1 from it? I already got some patches from the ubuntu 2.6.8 kernel package addressing the following 5 issues: CAN-2005-0756 CAN-2005-1265 CAN-2005-1762 CAN-2005-1763 CAN-2005-1765 and these 3 still need to be addressed: CAN-2005-1764 CAN-2005-0449 #295949 CAN-2005-0356 #310804 if nobody objects, I would like to commit my changes. Dann, could you comment on the need for backporting the patch below form 2.6.12.1. It does not apply cleanly to 2.6.8 as there seem to have been a bunch of other patches in the mean time. hey Horms, This patch appears to be relevant for 2.6.8. It depends on two earlier patches; one of which fixes what looks like another security issue to me - kernel is accessing unchecked addresses provided by userspace[1]. I've backported the fix for CAN-2005-1764 to our 2.6.8 with [1] applied (attached). I'd recommend applying both of these patches to our tree. Any objections? [1] http://linux.bkbits.net:8080/linux-2.6/[EMAIL PROTECTED]|src/|src/arch|src/arch/ia64|src/arch/ia64/kernel|related/arch/ia64/kernel/ptrace.c On the grounds that a) it fixes a security bug and b) it doesn't appear to change the ABI, yes, please go for it. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Processed: Re: Bug#317286: Please backport support for Promise SATAII TX2/TX4 cards (from 2.6.11)
Processing commands for [EMAIL PROTECTED]: reassign 317286 kernel-source-2.6.8 Bug#317286: Please backport support for Promise SATAII TX2/TX4 cards (from 2.6.11) Bug reassigned from package `kernel' to `kernel-source-2.6.8'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
