Bug#317258: [stable] kernel upload to p-u
I tried with linux-2.6.26 from kernel.org and it works well. Vincent Le 3 juil. 08 à 18:14, dann frazier a écrit : On Thu, Jul 03, 2008 at 01:12:15PM +0200, Vincent Reydet wrote: Hi, I've a hp netserver lc 2000 with netraid scsi card, and etch kernel (#-6) still doesn't work. I've installed a sarge, net upgrade to etch, then build a kernel 2.6.18-6 with the patch above ( I could share it but nobody should trust my binary ... ). Now it's fine for me, but i would like to have this problem either corrected by a debian patch, either corrected upstream. What do you need for that ? I'd suggest testing the latest snapshot kernel (see http://wiki.debian.org/DebianKernelReportingBugs) 1) Make sure you have the latest fw available for your card 2) Test the latest trunk snapshot kernel Assuming this doesn't fix the problem, please contact upstream (see MAINTAINERS file for contact address). I've reported issues to them before and they were quite responsive. They would prefer to fix the new driver rather than add more IDs to the old. If a driver fix proves necessary and gets accepted upstream, we would certainly consider backporting it into a stable kernel for Debian. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#317258: [stable] kernel upload to p-u
On Thu, Jul 03, 2008 at 01:12:15PM +0200, Vincent Reydet wrote: > Hi, > > I've a hp netserver lc 2000 with netraid scsi card, and etch kernel (#-6) > still doesn't work. > > I've installed a sarge, net upgrade to etch, then build a kernel 2.6.18-6 > with the patch above ( I could share it but nobody should trust my binary > ... ). > > Now it's fine for me, but i would like to have this problem either > corrected by a debian patch, either corrected upstream. > > What do you need for that ? I'd suggest testing the latest snapshot kernel (see http://wiki.debian.org/DebianKernelReportingBugs) 1) Make sure you have the latest fw available for your card 2) Test the latest trunk snapshot kernel Assuming this doesn't fix the problem, please contact upstream (see MAINTAINERS file for contact address). I've reported issues to them before and they were quite responsive. They would prefer to fix the new driver rather than add more IDs to the old. If a driver fix proves necessary and gets accepted upstream, we would certainly consider backporting it into a stable kernel for Debian. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#317258: [stable] kernel upload to p-u
Hi, I've a hp netserver lc 2000 with netraid scsi card, and etch kernel (#-6) still doesn't work. I've installed a sarge, net upgrade to etch, then build a kernel 2.6.18-6 with the patch above ( I could share it but nobody should trust my binary ... ). Now it's fine for me, but i would like to have this problem either corrected by a debian patch, either corrected upstream. What do you need for that ? # lspci 00:00.0 Host bridge: Broadcom CNB20LE Host Bridge (rev 05) 00:00.1 Host bridge: Broadcom CNB20LE Host Bridge (rev 05) 00:02.0 PCI bridge: Intel Corporation 80960RP [i960 RP Microprocessor/ Bridge] (rev 05) 00:02.1 RAID bus controller: Intel Corporation 80960RP [i960RP Microprocessor] (rev 05) 00:04.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] (rev 08) 00:05.0 VGA compatible controller: ATI Technologies Inc 3D Rage IIC (rev 7a) 00:0f.0 ISA bridge: Broadcom OSB4 South Bridge (rev 4f) 00:0f.1 IDE interface: Broadcom OSB4 IDE Controller 03:06.0 SCSI storage controller: LSI Logic / Symbios Logic 53C896/897 (rev 06) 03:06.1 SCSI storage controller: LSI Logic / Symbios Logic 53C896/897 (rev 06) # lspci -v 00:02.1 RAID bus controller: Intel Corporation 80960RP [i960RP Microprocessor] (rev 05) Subsystem: Hewlett-Packard Company HP NetRAID-1Si Flags: bus master, medium devsel, latency 64, IRQ 177 Memory at fd00 (32-bit, prefetchable) [size=64K] [virtual] Expansion ROM at 5002 [disabled] [size=32K] Capabilities: [80] Power Management version 2 03:06.0 SCSI storage controller: LSI Logic / Symbios Logic 53C896/897 (rev 06) Subsystem: Hewlett-Packard Company Unknown device 60f0 Flags: bus master, medium devsel, latency 72, IRQ 193 I/O ports at 2000 [size=256] Memory at fd012000 (64-bit, non-prefetchable) [size=1K] Memory at fd01 (64-bit, non-prefetchable) [size=8K] Capabilities: [40] Power Management version 2 03:06.1 SCSI storage controller: LSI Logic / Symbios Logic 53C896/897 (rev 06) Subsystem: Hewlett-Packard Company Unknown device 60f0 Flags: bus master, medium devsel, latency 72, IRQ 201 I/O ports at 2400 [size=256] Memory at fd012400 (64-bit, non-prefetchable) [size=1K] Memory at fd014000 (64-bit, non-prefetchable) [size=8K] Capabilities: [40] Power Management version 2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#317258: [stable] kernel upload to p-u
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I finally had the opportunity to reset this server, and did it on the kernel without the patch to see the error messages. The kernel loads, the megaraid_mbox driver detects the device, and we have ... Megaraid mbox : Wait for 0 commands to complete :300 Megaraid mbox : reset sequence completed successfully appearing for a few minutes. It seems it tries for each id in the scsci chain. Eventually, it gives up with : scsi : Device offlined - not ready after error recovery. Voilà, hope it helps. Regards, - -- Clement Hermann (nodens) - - "L'air pur ? c'est pas en RL, ça ? c'est pas hors charte ?" Jean in L'Histoire des Pingouins, http://tnemeth.free.fr/fmbl/linuxsf/ Vous trouverez ma clef publique sur le serveur public pgp.mit.edu. Please find my public key on the public keyserver pgp.mit.edu. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHJc3F0yQ2guvROZ0RAo6BAJ44cotyAMbGchn5LGS5Er+8dNcVyQCdGajO FUIQtxB2llhcYAPCNzwupVM= =Mb85 -END PGP SIGNATURE-
Re: [stable] kernel upload to p-u
On Mon, Sep 17, 2007 at 02:21:27PM -0300, Otavio Salvador wrote: > dann frazier <[EMAIL PROTECTED]> writes: > > > Both #317258 and #410817 are showing activity now, but its difficult > > to predict when they will be resolved. In the meantime, I'm going to > > upload our current set of changes to proposed-updates so we can > > increase the testing pool. If these issues get resolved in time for > > r2, there's not reason we can't do a -15. > > This means it's a good time to start to work on udeb updates for -14? Sure - that is, once the buildds are done. The upload should happen this evening once my build completes. Here's the should-be-final changelog for -14. The only "new" thing here is the fuse issue (#427518). linux-2.6 (2.6.18.dfsg.1-14) stable; urgency=high [ dann frazier ] * [bluetooth] Fix panic caused by race between RFCOMM socket layer and RFCOMM TTY layer. Thanks to Mikko Rapeli. (closes: #394742) * Add support for AMD/ATI SB700 hardware, see #429622 * Add support for Intel ICH9 controllers, see #435877 * [hppa] remove misuse of global_ack_eiem, fixing a race condition that resulted in frequent lockups on SMP systems. See: #435878 [ Frederik Schler ] * Add support for 3ware 9650SE controllers. (closes: #402562) [ dann frazier ] * bugfix/reset-pdeathsig-on-suid-upstream.patch Update fix for CVE-2007-3848 with the patch accepted upstream * Fix ipv6 rfc conformance issue introduced in 2.6.18.dfsg.1-13 by the fix for CVE-2007-2242. Thanks to Brian Haley for the patch. (closes: #440127) * Fix a minor denial of service issue that allows local users to disable an interrupt by causing an interrupt handler to be quickly inserted/removed. This has only been shown to happen with certain serial devices so can only be triggered by a user who already has additional priveleges (dialout group). (closes: #404815) * Fix a BUG in fuse_ctl_add_dentry by resetting the dentry counter in fuse_ctl_kill_sb(). (closes: #427518) * Fix a regression introduced by the intel_agp changes in -13 that caused boot-time hangs on large memory systems. (closes: #438458) -- dann frazier <[EMAIL PROTECTED]> Mon, 17 Sep 2007 16:56:07 -0600 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [stable] kernel upload to p-u
On Fri, Sep 14, 2007 at 03:42:50PM +0200, Frederik Schueler wrote: > Hello, > > I think we should add patches to update the forcedeth and e1000 drivers > to the latest version, too. Those are many changes, but also many new > boxes require those new drivers: obviously most nvidia based athlon > and opteron boards, and many xeon board (supermicro, tyan). > > What is the chance to get these drivers, backported from 2.6.22 or .23 > into stable? I know we most fear regressions here, how extensive must > the tests be to "get it in"? If you're talking about a complete upgrade of the driver, then the testing must be extensive (imo). I'd suggest talking to the associated vendors to see if they can test the change across their supported hardware. Individual fixes for individual bugs are easier as they can often be more easily tested. Things like adding PCI IDs with possibly additional code that only executes for those IDs are pretty low-risk. Major driver rework that we cannot easily test will likely need to wait for etch & 1/2 (as already noted). -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#317258: [stable] kernel upload to p-u
[This is becoming off-topic for debian-release, and is redundant for debian-kernel (which already receives bug traffic), so removing both from To:] On Sat, Sep 15, 2007 at 09:50:13AM +0200, Bastian Blank wrote: > On Fri, Sep 14, 2007 at 07:03:32PM -0600, dann frazier wrote: > > I've modified the patch to also blacklist these controllers in the > > megaraid_mbox driver to avoid an overlap. I tested this patch on one > > of the 2M cards I have (which, for whatever reason, all work just fine > > with either driver). > > And this is the problem. What is the different between the cards which > works with both and the cards which only works with legacy? I imagine the answer is "firmware", so it'd be good to collect some data about this. I also wonder if all reporters mean the same thing when they say it "doesn't work"? The original reporter was complaining that neither driver claimed the card - that's no longer the case. All users: I'm interested in collecting the following data from each of you: 1) BIOS/FW versions reported at POST (before the kernel starts) 2) boot log when booting the etch kernel 3) boot log when booting a kernel w/ the workaround: http://people.debian.org/~dannf/bugs/317258/linux-image-2.6.18-5-686_2.6.18.dfsg.1-13etch2megaraid1_i386.deb -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [stable] kernel upload to p-u
dann frazier <[EMAIL PROTECTED]> writes: > Both #317258 and #410817 are showing activity now, but its difficult > to predict when they will be resolved. In the meantime, I'm going to > upload our current set of changes to proposed-updates so we can > increase the testing pool. If these issues get resolved in time for > r2, there's not reason we can't do a -15. This means it's a good time to start to work on udeb updates for -14? -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - "Microsoft sells you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [stable] kernel upload to p-u
On Tue, Sep 11, 2007 at 11:20:35AM +0200, Luk Claes wrote: > dann frazier wrote: >> hey, >> I think we're nearly ready for a kernel upload to proposed-updates. >> Here's the current list of changes queued for a stable upload. > > Can you please consider fixing #317258 again? It's only about PCI ID > mappings that got lost while splitting the megaraid and megaraid_mbox > drivers. At one point this bug got fixed, but it was reverted later on, no > idea why? > > A lot of the Debian machines at my work use these NetRAID cards and it's > silly to have to keep repeating that it will be fixed in some undefined > future while the fix is small and harmless... Both #317258 and #410817 are showing activity now, but its difficult to predict when they will be resolved. In the meantime, I'm going to upload our current set of changes to proposed-updates so we can increase the testing pool. If these issues get resolved in time for r2, there's not reason we can't do a -15. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#317258: [stable] kernel upload to p-u
dann frazier a écrit : > I also wonder if all reporters mean the same thing when they say it > "doesn't work"? The original reporter was complaining that neither > driver claimed the card - that's no longer the case. > > All users: > I'm interested in collecting the following data from each of you: > 1) BIOS/FW versions reported at POST (before the kernel starts) > 2) boot log when booting the etch kernel > 3) boot log when booting a kernel w/ the workaround: > > http://people.debian.org/~dannf/bugs/317258/linux-image-2.6.18-5-686_2.6.18.dfsg.1-13etch2megaraid1_i386.deb > > > I cannot provide it right now (the impacted servers are in production now, I integrated the workaround myself). I could try to schedule downtime, but It could take some time. However, I can say that on my NetRaid 2/M and Megaraid Express 500 (that is, the ones having the problem here), the -mbox driver claimed the card. The symptoms where timeouts (60 seconds) when initialisation commands where issued to the controller, happening a few times, and eventually the initramfs image would give a shell. Here are the first lines of /proc/megaraid/config, hope it helps : Netraid 1M v2.00.4 (Release Date: Thu Feb 9 08:51:30 EST 2006) HP NetRAID-1M Controller Type: 438/466/467/471/493/518/520/531/532 Controller Supports 40 Logical Drives Controller is not using 64-bit memory addressing Base = f0832000, Irq = 177, Logical Drives = 1, Channels = 1 Version =H01.07:G01.02, DRAM = 32Mb Controller Queue Depth = 254, Driver Queue Depth = 126 Express 500 v2.00.4 (Release Date: Thu Feb 9 08:51:30 EST 2006) Series 475 40 Logical Drive Firmware Controller Type: 438/466/467/471/493/518/520/531/532 Controller Supports 40 Logical Drives Controller capable of 64-bit memory addressing Controller is not using 64-bit memory addressing Base = e0802000, Irq = 209, Logical Drives = 1, Channels = 1 Version =l148:3.11, DRAM = 32Mb Controller Queue Depth = 254, Driver Queue Depth = 126 Cheers, -- Clément Hermann (nodens) - "L'air pur ? c'est pas en RL, ça ? c'est pas hors charte ?" Jean in L'Histoire des Pingouins, http://tnemeth.free.fr/fmbl/linuxsf/ Vous trouverez ma clef publique sur le serveur public pgp.mit.edu. Please find my public key on the public keyserver pgp.mit.edu. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#317258: [stable] kernel upload to p-u
On Fri, Sep 14, 2007 at 07:03:32PM -0600, dann frazier wrote:
> I've modified the patch to also blacklist these controllers in the
> megaraid_mbox driver to avoid an overlap. I tested this patch on one
> of the 2M cards I have (which, for whatever reason, all work just fine
> with either driver).
And this is the problem. What is the different between the cards which
works with both and the cards which only works with legacy?
> --- linux-source-2.6.18.orig/drivers/scsi/megaraid/megaraid_mbox.c
> 2006-09-19 21:42:06.0 -0600
> +++ linux-source-2.6.18/drivers/scsi/megaraid/megaraid_mbox.c 2007-09-14
> 18:50:40.0 -0600
> @@ -426,6 +426,16 @@ megaraid_probe_one(struct pci_dev *pdev,
> con_log(CL_ANN, ("bus %d:slot %d:func %d\n", pdev->bus->number,
> PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn)));
>
> + /* Some NetRAID 1M and 2M controllers still require the old driver */
> + if (pdev->vendor == PCI_VENDOR_ID_AMI && \
> + pdev->device == PCI_DEVICE_ID_AMI_MEGARAID3 && \
> + pdev->subsystem_vendor == PCI_VENDOR_ID_HP && \
> + (pdev->subsystem_device == 0x60e7 || \
> + pdev->subsystem_device == 0x60e8)) {
Magic constants, coding style.
> + con_log(CL_ANN, ("megaraid_mbox: Blacklisted device found,
> aborting.\n"));
Useless message.
> + return -ENODEV;
Coding style.
Bastian
--
Suffocating together ... would create heroic camaraderie.
-- Khan Noonian Singh, "Space Seed", stardate 3142.8
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [stable] kernel upload to p-u
Otavio Salvador <[EMAIL PROTECTED]> writes: > dann frazier <[EMAIL PROTECTED]> writes: > >> If this looks correct, I'll submit it upstream and then we can >> look at backporting it into a stable update. > > It looks like you've defined the HP_NETRAID[12]M_SUBSYS_DID constansts > however forgot to change to code to use them and on the if you use the > device ids directly on _mbox.c. I hadn't check if megaraid.h is > included on it but it looks logical to be and hence would be better to > use the defined names. Let me rephrase it, it was confusing ... sorry It looks like you've defined the HP_NETRAID[12]M_SUBSYS_DID on megaraid.h however didn't use them at megaraid_mbox.c. I hadn't check if megaraid.h is included on it but it looks logical to be and hence would be better to use this defined names. .oO( much better now :P ) -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - "Microsoft sells you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [stable] kernel upload to p-u
dann frazier <[EMAIL PROTECTED]> writes: > If this looks correct, I'll submit it upstream and then we can > look at backporting it into a stable update. It looks like you've defined the HP_NETRAID[12]M_SUBSYS_DID constansts however forgot to change to code to use them and on the if you use the device ids directly on _mbox.c. I hadn't check if megaraid.h is included on it but it looks logical to be and hence would be better to use the defined names. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - "Microsoft sells you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#317258: [stable] kernel upload to p-u
On Fri, Sep 14, 2007 at 07:12:52PM +0200, Bastian Blank wrote:
> On Fri, Sep 14, 2007 at 10:53:50AM -0600, dann frazier wrote:
> > Have you verified that this fix works in 2.6.18? It seems like its
> > adding support for megaraid3s w/ specific subsystem devices, while
> > 2.6.18 (and current upstream) claim megaraid3 devices w/ *any*
> > subsystem ids. (Although there does appear to be code to explicitly
> > not claim some cards w/ intel vendor ids).
>
> megaraid_mbox claims PCI_VENDOR_ID_AMI and PCI_VENDOR_ID_LSI_LOGIC for
> PCI_DEVICE_ID_AMI_MEGARAID3. megaraid claims PCI_VENDOR_ID_INTEL for the
> same device.
>
> The patch adds PCI_VENDOR_ID_AMI to megaraid with two specific subsystem
> ids. They are not excluded in megaraid_mbox, so both claim the same
> device.
Thanks waldi, I see that I failed to notice that the MEGARAID3 entry
was PCI_VENDOR_ID_INTEL (not _AMI).
I've modified the patch to also blacklist these controllers in the
megaraid_mbox driver to avoid an overlap. I tested this patch on one
of the 2M cards I have (which, for whatever reason, all work just fine
with either driver).
If this looks correct, I'll submit it upstream and then we can
look at backporting it into a stable update.
--- linux-source-2.6.18.orig/drivers/scsi/megaraid.c2006-09-19
21:42:06.0 -0600
+++ linux-source-2.6.18/drivers/scsi/megaraid.c 2007-09-14 18:10:16.0
-0600
@@ -24,6 +24,7 @@
*
* Supported controllers: MegaRAID 418, 428, 438, 466, 762, 467, 471, 490, 493
* 518, 520, 531, 532
+ * NetRAID 1M, 2M
*
* This driver is supported by LSI Logic, with assistance from Red Hat, Dell,
* and others. Please send updates to the mailing list
@@ -5042,6 +5043,10 @@ static struct pci_device_id megaraid_pci
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},
{PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_AMI_MEGARAID3,
PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
{0,}
--- linux-source-2.6.18.orig/drivers/scsi/megaraid.h2006-09-19
21:42:06.0 -0600
+++ linux-source-2.6.18/drivers/scsi/megaraid.h 2007-09-14 17:47:50.0
-0600
@@ -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_64BIT0x0299
--- linux-source-2.6.18.orig/drivers/scsi/megaraid/megaraid_mbox.c
2006-09-19 21:42:06.0 -0600
+++ linux-source-2.6.18/drivers/scsi/megaraid/megaraid_mbox.c 2007-09-14
18:50:40.0 -0600
@@ -426,6 +426,16 @@ megaraid_probe_one(struct pci_dev *pdev,
con_log(CL_ANN, ("bus %d:slot %d:func %d\n", pdev->bus->number,
PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn)));
+ /* Some NetRAID 1M and 2M controllers still require the old driver */
+ if (pdev->vendor == PCI_VENDOR_ID_AMI && \
+ pdev->device == PCI_DEVICE_ID_AMI_MEGARAID3 && \
+ pdev->subsystem_vendor == PCI_VENDOR_ID_HP && \
+ (pdev->subsystem_device == 0x60e7 || \
+pdev->subsystem_device == 0x60e8)) {
+con_log(CL_ANN, ("megaraid_mbox: Blacklisted device found,
aborting.\n"));
+ return -ENODEV;
+ }
+
if (pci_enable_device(pdev)) {
con_log(CL_ANN, (KERN_WARNING
"megaraid: pci_enable_device failed\n"));
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [stable] kernel upload to p-u
On Fri, Sep 14, 2007 at 10:53:50AM -0600, dann frazier wrote: > Have you verified that this fix works in 2.6.18? It seems like its > adding support for megaraid3s w/ specific subsystem devices, while > 2.6.18 (and current upstream) claim megaraid3 devices w/ *any* > subsystem ids. (Although there does appear to be code to explicitly > not claim some cards w/ intel vendor ids). megaraid_mbox claims PCI_VENDOR_ID_AMI and PCI_VENDOR_ID_LSI_LOGIC for PCI_DEVICE_ID_AMI_MEGARAID3. megaraid claims PCI_VENDOR_ID_INTEL for the same device. The patch adds PCI_VENDOR_ID_AMI to megaraid with two specific subsystem ids. They are not excluded in megaraid_mbox, so both claim the same device. Bastian -- Sometimes a feeling is all we humans have to go on. -- Kirk, "A Taste of Armageddon", stardate 3193.9 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [stable] kernel upload to p-u
On Tue, Sep 11, 2007 at 11:20:35AM +0200, Luk Claes wrote: > dann frazier wrote: >> hey, >> I think we're nearly ready for a kernel upload to proposed-updates. >> Here's the current list of changes queued for a stable upload. > > Can you please consider fixing #317258 again? It's only about PCI ID > mappings that got lost while splitting the megaraid and megaraid_mbox > drivers. At one point this bug got fixed, but it was reverted later on, no > idea why? Certainly. I should have access to a pile of various "NetRAID" cards today, and hopefully one of them will demonstrate the problem. > A lot of the Debian machines at my work use these NetRAID cards and it's > silly to have to keep repeating that it will be fixed in some undefined > future while the fix is small and harmless... Have you verified that this fix works in 2.6.18? It seems like its adding support for megaraid3s w/ specific subsystem devices, while 2.6.18 (and current upstream) claim megaraid3 devices w/ *any* subsystem ids. (Although there does appear to be code to explicitly not claim some cards w/ intel vendor ids). -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [stable] kernel upload to p-u
Frederik Schueler wrote: Hello, Hi I think we should add patches to update the forcedeth and e1000 drivers to the latest version, too. Those are many changes, but also many new boxes require those new drivers: obviously most nvidia based athlon and opteron boards, and many xeon board (supermicro, tyan). What is the chance to get these drivers, backported from 2.6.22 or .23 into stable? I know we most fear regressions here, how extensive must the tests be to "get it in"? I would think the chance is rather big to include it in the etch and a half kernel... Up to now we were only talking about regressions... Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [stable] kernel upload to p-u
Hello, I think we should add patches to update the forcedeth and e1000 drivers to the latest version, too. Those are many changes, but also many new boxes require those new drivers: obviously most nvidia based athlon and opteron boards, and many xeon board (supermicro, tyan). What is the chance to get these drivers, backported from 2.6.22 or .23 into stable? I know we most fear regressions here, how extensive must the tests be to "get it in"? Best regards Frederik Schüler -- ENOSIG signature.asc Description: Digital signature
Bug#317258: [stable] kernel upload to p-u
On Fri, Sep 14, 2007 at 03:10:44PM +0200, Holger Levsen wrote: > On Friday 14 September 2007 14:57, Bastian Blank wrote: > > The patch needs to be applied upstream until it can appear again. > > Why? > > I mean, I agree for sid, but I don't see the point in not fixing this in > stable. > > Care to elaborate? By policy, all patches we apply beyond the obvious Debian stuff, XEN and vserver must be backports, read they must go through the upstream quality assurance, and if they got accepted upstream, we can consider applying them on the current Debian kernel. For this special case, the issue is open since sarge, and the patch was either NACKed upstream, or never submitted, I don't remember. However, in the first case we won't apply it in it's current state, it needs to be fixed so upstream accepts it. If it was never submitted, this should be done now, and we will happily apply it as soon as it got blessed. Best regards Frederik Schüler -- ENOSIG signature.asc Description: Digital signature
Bug#317258: [stable] kernel upload to p-u
Hi, On Friday 14 September 2007 14:57, Bastian Blank wrote: > The patch needs to be applied upstream until it can appear again. Why? I mean, I agree for sid, but I don't see the point in not fixing this in stable. Care to elaborate? regards, Holger pgpwLVsMSclXO.pgp Description: PGP signature
Re: [stable] kernel upload to p-u
On Fri, Sep 14, 2007 at 02:18:48PM +0200, Holger Levsen wrote: > Is there? The patch needs to be applied upstream until it can appear again. It moves devices between two different drivers, which obviously are not compatible. Both megaraid drivers looks not really good maintained. Bastian -- Another Armenia, Belgium ... the weak innocents who always seem to be located on a natural invasion route. -- Kirk, "Errand of Mercy", stardate 3198.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [stable] kernel upload to p-u
Hi, On Tuesday 11 September 2007 12:16, Luk Claes wrote: > Bastian Blank wrote: > > On Tue, Sep 11, 2007 at 11:20:35AM +0200, Luk Claes wrote: > >> Can you please consider fixing #317258 again? It's only about PCI ID > >> mappings that got lost while splitting the megaraid and megaraid_mbox > >> drivers. At one point this bug got fixed, but it was reverted later on, > >> no idea why? > > > > No part of this patch is in linux upstream. The relevant code sections > > was not changed since .12. Please fix it there if it is a problem. We > > don't carry any megaraid patches. > > Not anymore and no I'm not going to do your job as a maintainer by > fixing it upstream... Any reason why you don't mention anything about > not cooperating with upstream about this in the bugreport? Me too thinks not fixing this bug in stable is a violation of the social contract: "..our priorities are our users and free software...", not free software alone. Anyway, as I'm somehow still a member of the kernel-team ;-) I guess I could work on the needed patch against the version for proposed updates, if there is still time to do so. Is there? regards, Holger pgpVutf824zl5.pgp Description: PGP signature
Re: [stable] kernel upload to p-u
Bastian Blank wrote: On Tue, Sep 11, 2007 at 11:20:35AM +0200, Luk Claes wrote: Can you please consider fixing #317258 again? It's only about PCI ID mappings that got lost while splitting the megaraid and megaraid_mbox drivers. At one point this bug got fixed, but it was reverted later on, no idea why? No part of this patch is in linux upstream. The relevant code sections was not changed since .12. Please fix it there if it is a problem. We don't carry any megaraid patches. Not anymore and no I'm not going to do your job as a maintainer by fixing it upstream... Any reason why you don't mention anything about not cooperating with upstream about this in the bugreport? Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [stable] kernel upload to p-u
On Tue, Sep 11, 2007 at 11:20:35AM +0200, Luk Claes wrote: > Can you please consider fixing #317258 again? It's only about PCI ID > mappings that got lost while splitting the megaraid and megaraid_mbox > drivers. At one point this bug got fixed, but it was reverted later on, > no idea why? No part of this patch is in linux upstream. The relevant code sections was not changed since .12. Please fix it there if it is a problem. We don't carry any megaraid patches. Bastian -- He's dead, Jim. -- McCoy, "The Devil in the Dark", stardate 3196.1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [stable] kernel upload to p-u
dann frazier wrote: hey, I think we're nearly ready for a kernel upload to proposed-updates. Here's the current list of changes queued for a stable upload. Can you please consider fixing #317258 again? It's only about PCI ID mappings that got lost while splitting the megaraid and megaraid_mbox drivers. At one point this bug got fixed, but it was reverted later on, no idea why? A lot of the Debian machines at my work use these NetRAID cards and it's silly to have to keep repeating that it will be fixed in some undefined future while the fix is small and harmless... Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[stable] kernel upload to p-u
hey, I think we're nearly ready for a kernel upload to proposed-updates. Here's the current list of changes queued for a stable upload. I've reverted the forcedeth changes for #439219 until we get some testers for them. The last thing I'm waiting for is some final feedback about a backported fix for the intel_agp regression in #438458. After the merge of the last security upload, this has been the biggest blocker imo since it fixes a regression introduced in r1. linux-2.6 (2.6.18.dfsg.1-14) UNRELEASED; urgency=high [ dann frazier ] * [bluetooth] Fix panic caused by race between RFCOMM socket layer and RFCOMM TTY layer. Thanks to Mikko Rapeli. (closes: #394742) * Add support for AMD/ATI SB700 hardware, see #429622 * Add pci ids for Intel ICH9 controllers, see #435877 * [hppa] remove misuse of global_ack_eiem, fixing a race condition that resulted in frequent lockups on SMP systems. See: #435878 [ Frederik Schler ] * Add support for 3ware 9650SE controllers. (closes: #402562) [ dann frazier ] * bugfix/reset-pdeathsig-on-suid-upstream.patch Update fix for CVE-2007-3848 with the patch accepted upstream * Fix ipv6 rfc conformance issue introduced in 2.6.18.dfsg.1-13 by the fix for CVE-2007-2242. Thanks to Brian Haley for the patch. (closes: #440127) * Fix a minor denial of service issue that allows local users to disable an interrupt by causing an interrupt handler to be quickly inserted/removed. This has only been shown to happen with certain serial devices so can only be triggered by a user who already has additional priveleges (dialout group). (closes: #404815) -- dann frazier <[EMAIL PROTECTED]> Mon, 10 Sep 2007 23:28:17 -0600 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
