RE: [PATCH 1/1] scsi: hpsa, add all PCI ID's that HP has in svn
> -Original Message-
> From: Hannes Reinecke [mailto:h...@suse.de]
> Sent: Friday, January 17, 2014 9:31 AM
> To: Miller, Mike (OS Dev)
> Cc: Tomas Henzl; Andrew Morton; James E. J. Bottomley; LKML; LKML-scsi;
> Stephen M. Cameron
> Subject: Re: [PATCH 1/1] scsi: hpsa, add all PCI ID's that HP has in svn
>
> On 01/17/2014 04:17 PM, Miller, Mike (OS Dev) wrote:
> >
> >
> >> -Original Message-
> >> From: Tomas Henzl [mailto:the...@redhat.com]
> >> Sent: Friday, January 17, 2014 9:14 AM
> >> To: Miller, Mike (OS Dev); Andrew Morton; James E. J. Bottomley
> >> Cc: LKML; LKML-scsi; h...@suse.de; Stephen M. Cameron
> >> Subject: Re: [PATCH 1/1] scsi: hpsa, add all PCI ID's that HP has in
> >> svn
> >>
> >> On 01/16/2014 08:51 PM, Mike Miller wrote:
> >>> From: Mike Miller
> >>>
> >>> This patch has every ID we have in our svn repository. Some
> >>> controllers were cancelled, others added, now the cancelled ones are
> >>> back. Apparently the debate rages on about which controllers are
> >>> cancelled, which are not, whatever. Please accept this patch. It is
> >>> dependent upon the patches I sent yesterday.
> >>> This patch made/tested against kernel-3.13.0-rc8
> >>>
> >>> Signed-off-by: Mike Miller
> >>> ---
> >>> drivers/scsi/hpsa.c | 12
> >>> 1 files changed, 12 insertions(+), 0 deletions(-)
> >>>
> >>> diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c index
> >>> 348b207..3affec5 100644
> >>> --- a/drivers/scsi/hpsa.c
> >>> +++ b/drivers/scsi/hpsa.c
> >>> @@ -100,6 +100,7 @@ static const struct pci_device_id
> >> hpsa_pci_device_id[] = {
> >>> {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C,
> >> 0x3354},
> >>> {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C,
> >> 0x3355},
> >>> {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C,
> >> 0x3356},
> >>> + {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C,
> >> 0x1920},
> >>> {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C,
> >> 0x1921},
> >>> {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C,
> >> 0x1922},
> >>> {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C,
> >> 0x1923},
> >>> @@ -108,15 +109,19 @@ static const struct pci_device_id
> >> hpsa_pci_device_id[] = {
> >>> {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C,
> >> 0x1926},
> >>> {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C,
> >> 0x1928},
> >>> {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C,
> >> 0x1929},
> >>> + {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C,
> >> 0x192A},
> >>> {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
> >> 0x21BD},
> >>> {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
> >> 0x21BE},
> >>> {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
> >> 0x21BF},
> >>> {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
> >> 0x21C0},
> >>> {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
> >> 0x21C2},
> >>> {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
> >> 0x21C3},
> >>> + {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
> >> 0x21C4},
> >>> {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
> >> 0x21C5},
> >>> + {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
> >> 0x21C6},
> >>> {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
> >> 0x21C7},
> >>> {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
> >> 0x21C8},
> >>> + {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
> >> 0x21C9},
> >>> {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
> >> 0x21CA},
> >>> {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
> >> 0x21CB},
> >>> {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
> >> 0x21CC},
> >>> @@ -149,22 +154,29 @@ static struct board_type products[] = {
> >>> {0x3354103C, "Smart Array P420i", &SA5_access},
> >>> {0x3355103C, "Smart Array P220i", &SA5_access},
> &g
RE: [PATCH 1/1] scsi: hpsa, add all PCI ID's that HP has in svn
> -Original Message-
> From: Tomas Henzl [mailto:the...@redhat.com]
> Sent: Friday, January 17, 2014 9:14 AM
> To: Miller, Mike (OS Dev); Andrew Morton; James E. J. Bottomley
> Cc: LKML; LKML-scsi; h...@suse.de; Stephen M. Cameron
> Subject: Re: [PATCH 1/1] scsi: hpsa, add all PCI ID's that HP has in svn
>
> On 01/16/2014 08:51 PM, Mike Miller wrote:
> > From: Mike Miller
> >
> > This patch has every ID we have in our svn repository. Some
> > controllers were cancelled, others added, now the cancelled ones are
> > back. Apparently the debate rages on about which controllers are
> > cancelled, which are not, whatever. Please accept this patch. It is
> > dependent upon the patches I sent yesterday.
> > This patch made/tested against kernel-3.13.0-rc8
> >
> > Signed-off-by: Mike Miller
> > ---
> > drivers/scsi/hpsa.c | 12
> > 1 files changed, 12 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c index
> > 348b207..3affec5 100644
> > --- a/drivers/scsi/hpsa.c
> > +++ b/drivers/scsi/hpsa.c
> > @@ -100,6 +100,7 @@ static const struct pci_device_id
> hpsa_pci_device_id[] = {
> > {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C,
> 0x3354},
> > {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C,
> 0x3355},
> > {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C,
> 0x3356},
> > + {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C,
> 0x1920},
> > {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C,
> 0x1921},
> > {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C,
> 0x1922},
> > {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C,
> 0x1923},
> > @@ -108,15 +109,19 @@ static const struct pci_device_id
> hpsa_pci_device_id[] = {
> > {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C,
> 0x1926},
> > {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C,
> 0x1928},
> > {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C,
> 0x1929},
> > + {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C,
> 0x192A},
> > {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
> 0x21BD},
> > {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
> 0x21BE},
> > {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
> 0x21BF},
> > {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
> 0x21C0},
> > {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
> 0x21C2},
> > {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
> 0x21C3},
> > + {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
> 0x21C4},
> > {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
> 0x21C5},
> > + {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
> 0x21C6},
> > {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
> 0x21C7},
> > {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
> 0x21C8},
> > + {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
> 0x21C9},
> > {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
> 0x21CA},
> > {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
> 0x21CB},
> > {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
> 0x21CC},
> > @@ -149,22 +154,29 @@ static struct board_type products[] = {
> > {0x3354103C, "Smart Array P420i", &SA5_access},
> > {0x3355103C, "Smart Array P220i", &SA5_access},
> > {0x3356103C, "Smart Array P721m", &SA5_access},
> > + {0x1920103C, "Smart Array P430i", &SA5_access},
> > {0x1921103C, "Smart Array P830i", &SA5_access},
> > {0x1922103C, "Smart Array P430", &SA5_access},
> > {0x1923103C, "Smart Array P431", &SA5_access},
> > {0x1924103C, "Smart Array P830", &SA5_access},
> > + {0x1925103C, "Smart Array P831", &SA5_access},
> > {0x1926103C, "Smart Array P731m", &SA5_access},
> > {0x1928103C, "Smart Array P230i", &SA5_access},
> > {0x1929103C, "Smart Array P530", &SA5_access},
> > + {0x192A103C, "Smart Array P531", &SA5_access},
> > {0x21BD103C, "Smart Array", &SA5_access},
> > {0x21BE103C, "Smart Array", &SA5_access},
> > {0x21BF103C, "Smart Array", &SA5_access},
> > {0x21C0103C, "Smart Array", &SA5_acces
RE: [PATCH 1/1] remove cpqarray from mainline kernel
> -Original Message- > From: Jens Axboe [mailto:ax...@kernel.dk] > Sent: Friday, October 18, 2013 11:55 AM > To: Miller, Mike (OS Dev); Andrew Morton > Cc: LKML-scsi; LKML > Subject: Re: [PATCH 1/1] remove cpqarray from mainline kernel > > On 10/18/2013 10:22 AM, Miller, Mike (OS Dev) wrote: > > > > > >> -Original Message- > >> From: Jens Axboe [mailto:ax...@kernel.dk] > >> Sent: Thursday, October 17, 2013 5:36 PM > >> To: Andrew Morton > >> Cc: Miller, Mike (OS Dev); LKML-scsi; LKML > >> Subject: Re: [PATCH 1/1] remove cpqarray from mainline kernel > >> > >> On Thu, Oct 17 2013, Andrew Morton wrote: > >>> On Thu, 17 Oct 2013 12:52:26 -0500 Mike Miller > >> wrote: > >>> > >>>> cpqarray hasn't been used in over 12 years. It's doubtful that > >>>> anyone still uses the board. It's time the driver was removed from > >>>> the > >> mainline kernel. > >>>> The only updates these days are minor and mostly done by people > >> outside of HP. > >>> > >>> It's amazing the weird stuff people get up to. Perhaps we should > >>> disable it in config for a cycle or two, see if that flushes anyone out? > >> > >> I think that would be prudent, you never know what people run... > >> > >> -- > >> Jens Axboe > > > > I agree with Andrew's suggestion. Should I submit a patch that only > removes cpqarray from config? > > I put one in yesterday: > > http://git.kernel.dk/?p=linux- > block.git;a=commit;h=f504954db0ecccaded5397e3432cdaf7175602fb > > -- > Jens Axboe Thanks, Jens. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1] remove cpqarray from mainline kernel
> -Original Message- > From: Jens Axboe [mailto:ax...@kernel.dk] > Sent: Thursday, October 17, 2013 5:36 PM > To: Andrew Morton > Cc: Miller, Mike (OS Dev); LKML-scsi; LKML > Subject: Re: [PATCH 1/1] remove cpqarray from mainline kernel > > On Thu, Oct 17 2013, Andrew Morton wrote: > > On Thu, 17 Oct 2013 12:52:26 -0500 Mike Miller > wrote: > > > > > cpqarray hasn't been used in over 12 years. It's doubtful that > > > anyone still uses the board. It's time the driver was removed from the > mainline kernel. > > > The only updates these days are minor and mostly done by people > outside of HP. > > > > It's amazing the weird stuff people get up to. Perhaps we should > > disable it in config for a cycle or two, see if that flushes anyone out? > > I think that would be prudent, you never know what people run... > > -- > Jens Axboe I agree with Andrew's suggestion. Should I submit a patch that only removes cpqarray from config? -- mikem -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] cpqarray: remove deprecated IRQF_DISABLED
> -Original Message-
> From: Michael Opdenacker [mailto:michael.opdenacker@free-
> electrons.com]
> Sent: Friday, October 11, 2013 11:15 PM
> To: chirag.kantha...@hp.com
> Cc: ISS StorageDev; linux-kernel@vger.kernel.org; Michael Opdenacker
> Subject: [PATCH] cpqarray: remove deprecated IRQF_DISABLED
>
> This patch proposes to remove the use of the IRQF_DISABLED flag
>
> It's a NOOP since 2.6.35 and it will be removed one day.
I plan to send a patch soon to remove cpqarray completely.
-- mikem
>
> Signed-off-by: Michael Opdenacker electrons.com>
> ---
> drivers/block/cpqarray.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/block/cpqarray.c b/drivers/block/cpqarray.c index
> 2b94403..370721e 100644
> --- a/drivers/block/cpqarray.c
> +++ b/drivers/block/cpqarray.c
> @@ -406,7 +406,7 @@ static int cpqarray_register_ctlr(int i, struct pci_dev
> *pdev)
> }
> hba[i]->access.set_intr_mask(hba[i], 0);
> if (request_irq(hba[i]->intr, do_ida_intr,
> - IRQF_DISABLED|IRQF_SHARED, hba[i]->devname, hba[i]))
> + IRQF_SHARED, hba[i]->devname, hba[i]))
> {
> printk(KERN_ERR "cpqarray: Unable to get irq %d for %s\n",
> hba[i]->intr, hba[i]->devname);
> --
> 1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [patch -resend] cciss: info leak in cciss_ioctl32_passthru()
-Original Message- From: Dan Carpenter [mailto:dan.carpen...@oracle.com] Sent: Wednesday, September 11, 2013 2:39 AM To: Miller, Mike (OS Dev); Andrew Morton Cc: ISS StorageDev; linux-kernel@vger.kernel.org; kernel-janit...@vger.kernel.org; Moritz Muehlenhoff Subject: [patch -resend] cciss: info leak in cciss_ioctl32_passthru() The arg64 struct has a hole after ->buf_size which isn't cleared. Or if any of the calls to copy_from_user() fail then that would cause an information leak as well. This was assigned CVE-2013-2147. Signed-off-by: Dan Carpenter Acked-by: Mike Miller diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c index 6374dc1..34971aa 100644 --- a/drivers/block/cciss.c +++ b/drivers/block/cciss.c @@ -1189,6 +1189,7 @@ static int cciss_ioctl32_passthru(struct block_device *bdev, fmode_t mode, int err; u32 cp; + memset(&arg64, 0, sizeof(arg64)); err = 0; err |= copy_from_user(&arg64.LUN_info, &arg32->LUN_info, -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [patch -resend] cpqarray: info leak in ida_locked_ioctl()
-Original Message- From: Dan Carpenter [mailto:dan.carpen...@oracle.com] Sent: Wednesday, September 11, 2013 2:38 AM To: Chirag Kantharia; Andrew Morton Cc: ISS StorageDev; linux-kernel@vger.kernel.org; kernel-janit...@vger.kernel.org; Moritz Muehlenhoff Subject: [patch -resend] cpqarray: info leak in ida_locked_ioctl() The pciinfo struct has a two byte hole after ->dev_fn so stack information could be leaked to the user. This was assigned CVE-2013-2147. Signed-off-by: Dan Carpenter Acked-by: Mike Miller diff --git a/drivers/block/cpqarray.c b/drivers/block/cpqarray.c index 639d26b..2b94403 100644 --- a/drivers/block/cpqarray.c +++ b/drivers/block/cpqarray.c @@ -1193,6 +1193,7 @@ out_passthru: ida_pci_info_struct pciinfo; if (!arg) return -EINVAL; + memset(&pciinfo, 0, sizeof(pciinfo)); pciinfo.bus = host->pci_dev->bus->number; pciinfo.dev_fn = host->pci_dev->devfn; pciinfo.board_id = host->board_id; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/4] hpsa: add HP Smart Array Gen9 PCI ID's
-Original Message- From: James Bottomley [mailto:james.bottom...@hansenpartnership.com] Sent: Tuesday, September 10, 2013 5:02 PM To: Miller, Mike (OS Dev) Cc: Andrew Morton; LKML; LKML-scsi Subject: Re: [PATCH 1/4] hpsa: add HP Smart Array Gen9 PCI ID's On Wed, 2013-09-04 at 15:05 -0500, Mike Miller wrote: > Patch 1 of 4 > > From: Mike Miller Just for future reference, doing it this way means I have to edit the patch. The way git am works when applying patches is that if the first body line is a keyword it recognises (like From: or Subject: or Date:) it will fold that into the commit metadata, otherwise everything becomes the commit message. So by putting the redundant "patch 1 of 4" first, git thinks the entire body is the commit message. James Sorry about that. I didn't realize git worked that way. So let me ask a dumb question, just having [PATCH x/y] in the subject line is enough? Would you like me to resubmit the patchset? -- mikem > This patch adds the PCI ID's for HP Smart Array Gen9 controllers. > Please consider this patch for inclusion. > > Signed-off-by: Mike Miller > --- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1] cciss: set max scatter gather entries to 32 on P600
-Original Message- From: James Bottomley [mailto:james.bottom...@hansenpartnership.com] Sent: Wednesday, August 14, 2013 4:27 PM To: Miller, Mike (OS Dev); mi...@thumper.usa.hp.com Cc: Andrew Morton; Jens Axboe; LKML-scsi; LKML; the...@redhat.com; bubr...@redhat.com; scame...@beardog.cce.hp.com Subject: Re: [PATCH 1/1] cciss: set max scatter gather entries to 32 on P600 On Wed, 2013-08-14 at 15:52 -0500, Mike Miller wrote: > Patch 1/1 > > From: Mike Miller > > At one time we used to set the maximum number of scatter gather > elements on all Smart Array controllers to 32. At some point in time > the firmware began to write the "appropriate" value for each controller into > the config table. > The cciss driver would then read that and set h->maxsgentries. > > h->maxsgentries = readl(&(h->cfgtable->MaxSGElements); > > On the P600 that value is 544. Under some workloads a significant > performance reduction may result. This patch forces the P600 to use > only 32 scatter gather elements. Other controllers are not affected. > > Signed-off-by: Mike Miller > Signed-off-by: Dwight (Bud) Brown > Signed-off-by: Tomas Henzl > Acked-by: Stephen M. Cameron I don't quite understand the signoff chain on this patch. For a one line patch, are you saying it has three authors? James The patch origin is unknown. I got it from Tomas and Bud who think it may have originated from HP. I cleaned it up, compile tested it, and sent it on. I'll review my procedures for future patches. -- mikem -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1] resubmit: cciss: procfs updates to display info about many volumes
Jens wrote: > > On Wed, Feb 20 2008, Mike Miller wrote: > > Patch 1 of 1 > > > > This patch hopefully fixes all the brokeness in my last > submission. It > > compiles cleanly with tape support on or off. I added a couple of > > #ifdef's and removed the broken macro definition. The > #ifdef's made it unneccesary. > > It also replaces create_proc_read_entry with proc_create. > > > > This patch allows us to display information about all of > the logical > > volumes configured on a particular controller without stepping on > > memory even when there are many volumes (128 or more) configured. > > Please consider this for inclusion. > > Looks a lot better, I've applied it. > Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.25-rc2-mm1: new create_proc_entry() users
> -Original Message- > From: Alexey Dobriyan [mailto:[EMAIL PROTECTED] > Sent: Sunday, February 17, 2008 4:51 AM > To: Andrew Morton > Cc: linux-kernel@vger.kernel.org; Miller, Mike (OS Dev); > [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: 2.6.25-rc2-mm1: new create_proc_entry() users > > > profile-likely-unlikely-macros > > page-owner-tracking-leak-detector > > cciss-procfs-updates-to-display-info-about-many-volumes > > Guys, create_proc_entry() is slightly racy in case of modular code and > proc_create() was invented to fix it. Eventually all > create_proc_entry() users will be converted to proc_create(), > so please do it for new code. > Why am I getting "implicit declaration of function 'proc_create'" when I try to use that function? I have kernel version 2.6.24, gcc version 4.1.1 20070105 (Red Hat 4.1.1-51). Am I missing a header file? -- mikem -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1] cciss: procfs updates to display info about many volumes
> -Original Message- > From: Andrew Morton [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 19, 2008 6:00 AM > To: Jens Axboe > Cc: Miller, Mike (OS Dev); LKML; LKML-scsi > Subject: Re: [PATCH 1/1] cciss: procfs updates to display > info about many volumes > > On Tue, 19 Feb 2008 11:48:18 +0100 Jens Axboe > <[EMAIL PROTECTED]> wrote: > > > On Mon, Feb 11 2008, Mike Miller wrote: > > > Patch 1 of 1 > > > > > > This patch allows us to display information about all of > the logical > > > volumes configured on a particular without stepping on > memory even > > > when there are many volumes (128 or more) configured. This patch > > > replaces the one submitted on 20071214. See > > > > http://groups.google.com/group/linux.kernel/browse_thread/thread/49a > > > > 50244b19f8855/ba3dc95b23391521?hl=en&lnk=gst&q=cciss#ba3dc95b2339152 > > > 1 which has not been merged. That patch displayed > information about > > > only the first logical volume on each controller and had negative > > > side effects for some installers. > > > Please consider this for inclusion. > > > > It looks ok, but has some flaws. Try to disable cciss scsi and tape > > support: > > > > In file included from drivers/block/cciss.c:231: > > drivers/block/cciss_scsi.c:1498:38: error: macro parameters must be > > comma-separated > > drivers/block/cciss.c: In function 'cciss_seq_show_header': > > drivers/block/cciss.c:272: error: implicit declaration of function > > 'cciss_seq_tape_report' > > drivers/block/cciss.c: In function 'cciss_proc_write': > > drivers/block/cciss.c:393: error: implicit declaration of function > > 'cciss_engage_scsi' > > > > You macro definition of cciss_seq_tape_report() is totally busted. > > Either write is as a macro OR as a function. > > > > Fix these up and resubmit, then I'll take it. > > > > It also need to be updated to use the non-racy proc_create(), > please, as per Alexey's comments. Thanks all, I'll fix and resubmit. -- mikem > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
FW: [Bug 9859] hp smart array E200i kernel panic upon boot
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Sent: Thursday, February 14, 2008 8:16 AM > To: Miller, Mike (OS Dev) > Subject: [Bug 9859] hp smart array E200i kernel panic upon boot > > http://bugzilla.kernel.org/show_bug.cgi?id=9859 > > > [EMAIL PROTECTED] changed: > >What|Removed |Added > -- > -- > CC||[EMAIL PROTECTED] > > > > > --- Comment #14 from [EMAIL PROTECTED] 2008-02-14 06:16 > --- I'm facing a problem that seems related also using > gentoo on a x86_64 configuration (Dual Opteron 270 on Tyan > K8SE) I'm booting from a 3ware 9500s controller. > Everything went find with 2.6.23 but stating from 2.6.24 i > get the same kernel panic message: Unable to mount root fs on > unknown-block(0,0) The sd messages for sda and sdb that > appear under 2.6.23 do no longer appear with 2.6.24 though > the 3ware driver reports it's loaded > Andrew, The latest reports being added to the bug point to something other than cciss. This user is reporting the same problem on a white box with a 3ware SAS card. I've recreated the problem in my lab with a DL385 Opteron server. I've confirmed the 2.6.24.x kernels do not fail on Intel based platforms. The question is what changed in the kernel to to break AMD platforms. I'll keep looking and post any updates. -- mikem > > -- > Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email > --- You are receiving this mail because: --- You are > the assignee for the bug, or are watching the assignee. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: kernel BUG at drivers/block/cciss.c:1260! (with recent linux-2.6 tree)
Jens wrote: > -Original Message- > From: Jens Axboe [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 29, 2008 12:54 PM > To: Andrew Vasquez > Cc: Linux Kernel Mailing List; Miller, Mike (OS Dev); > [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: kernel BUG at drivers/block/cciss.c:1260! (with > recent linux-2.6 tree) > > On Tue, Jan 29 2008, Andrew Vasquez wrote: > > On Tue, 29 Jan 2008, Jens Axboe wrote: > > > > > On Tue, Jan 29 2008, Andrew Vasquez wrote: > > > > On Tue, 29 Jan 2008, Jens Axboe wrote: > > > > > > > > > > Here the final snippet that was logged: > > > > > > > > > > > > [ 12.724997] input: USB HID v1.01 Mouse [HP > Virtual Keyboard] on usb-:01:04.4-1 > > > > > > [ 12.728971] usbcore: registered new interface > driver usbhid > > > > > > [ 12.732866] drivers/hid/usbhid/hid-core.c: > v2.6:USB HID core driver > > > > > > [ 12.741172] TCP cubic registered > > > > > > [ 12.744506] NET: Registered protocol family 1 > > > > > > [ 12.744884] NET: Registered protocol family 17 > > > > > > [ 12.749217] Freeing unused kernel memory: 228k freed > > > > > > [ 12.885823] cciss rq: dev cciss/c0d0: type=2, flags=104c8 > > > > > > [ 12.888929] > > > > > > [ 12.888930] sector 651061426900570, nr/cnr 0/0 > > > > > > [ 12.892895] bio 81042f130730, biotail > 81042f130730, buffer , data > , len 0 > > > > > > [ 12.896895] cdb: 12 00 00 00 fe 00 00 00 00 00 > 00 00 00 00 00 00 > > > > > > > > > > Ah ok, I see the problem... cciss is overriding the > data_len for > > > > > BLOCK_PC requests, hence it does not complete them properly. > > > > > Hmm. Does this work? > > > > > > > > > > diff --git a/drivers/block/cciss.c > b/drivers/block/cciss.c index > > > > > ef50068..b6fa52e 100644 > > > > > --- a/drivers/block/cciss.c > > > > > +++ b/drivers/block/cciss.c > > > > > @@ -2524,7 +2524,6 @@ after_error_processing: > > > > > resend_cciss_cmd(h, cmd); > > > > > return; > > > > > } > > > > > - cmd->rq->data_len = 0; > > > > > cmd->rq->completion_data = cmd; > > > > > blk_complete_request(cmd->rq); } > > > > > > > > > > > > Things look good so far -- with the patch above I can > finally boot > > > > the machine. > > > > > > Cool, sorry about that. Will get that applied asap. So after this > > > patch was applied, you didn't see any debug messages from > > > blk_dump_rq_flags() anymore, right? > > > > That's correct. I've yet to see any additional debug-messages from > > blk_dump_rq_flags(). > > Great, thanks for confirming. It does look like a clear bug > in cciss, it just got exposed now that it uses proper end > request handling. We never need to clear ->data_len, since > for blk_fs_request() it will be cleared on init. So just > setting a residual count there for blk_fs_request() like > cciss does is fine. Just so I'm clear: just removing the one line is enough to resolve the problem? -- mikem > > Anyway, it's in my pending queue for Linus. > > -- > Jens Axboe > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] drivers/block/: Spelling fixes
> -Original Message- > From: Joe Perches [mailto:[EMAIL PROTECTED] > Sent: Monday, December 17, 2007 1:30 PM > To: linux-kernel@vger.kernel.org > Cc: Andrew Morton; Miller, Mike (OS Dev); ISS StorageDev > Subject: [PATCH] drivers/block/: Spelling fixes > > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> Acked-by: Mike Miller <[EMAIL PROTECTED]> > --- > drivers/block/cciss_scsi.c |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/block/cciss_scsi.c > b/drivers/block/cciss_scsi.c index 63ee6c0..55178e9 100644 > --- a/drivers/block/cciss_scsi.c > +++ b/drivers/block/cciss_scsi.c > @@ -1453,7 +1453,7 @@ static int > cciss_eh_device_reset_handler(struct scsi_cmnd *scsicmd) > rc = sendcmd(CCISS_RESET_MSG, ctlr, NULL, 0, 2, 0, 0, > (unsigned char *) > &cmd_in_trouble->Header.LUN.LunAddrBytes[0], > TYPE_MSG); > - /* sendcmd turned off interrputs on the board, turn > 'em back on. */ > + /* sendcmd turned off interrupts on the board, turn > 'em back on. > + */ > (*c)->access.set_intr_mask(*c, CCISS_INTR_ON); > if (rc == 0) > return SUCCESS; > @@ -1483,7 +1483,7 @@ static int > cciss_eh_abort_handler(struct scsi_cmnd *scsicmd) > 0, 2, 0, 0, > (unsigned char *) > &cmd_to_abort->Header.LUN.LunAddrBytes[0], > TYPE_MSG); > - /* sendcmd turned off interrputs on the board, turn > 'em back on. */ > + /* sendcmd turned off interrupts on the board, turn > 'em back on. > + */ > (*c)->access.set_intr_mask(*c, CCISS_INTR_ON); > if (rc == 0) > return SUCCESS; > -- > 1.5.3.7.949.g2221a6 > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/3] cciss: export more attributes to sysfs (repost)
> > Mike, what's going on? I definitely told you last time I > looked at this patch that it is a bug to call > sysfs_remove_group() under spinlock, because > sysfs_remove_group() takes sleeping locks. Yet here it is again. > > Maybe you lost my email. It is here: > http://lkml.org/lkml/2007/11/20/77 > > > Also please see http://lkml.org/lkml/2007/11/20/79 > Andrew, My apologies. Obviously I did not read your email closely. When I return from vacation I will address these issues. -- mikem -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [Patch 4/8] Enhanced partition statistics: cciss fix
>
> Updates the enhanced partition statistics in cciss driver.
>
> Signed-off-by: Jerome Marchand <[EMAIL PROTECTED]>
> ---
> cciss.c |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-) diff -urNp -X
> linux-2.6/Documentation/dontdiff
> linux-2.6.orig/drivers/block/cciss.c linux-2.6/drivers/block/cciss.c
> --- linux-2.6.orig/drivers/block/cciss.c2007-12-04
> 17:37:13.0 +0100
> +++ linux-2.6/drivers/block/cciss.c 2007-12-05
> 13:46:29.0 +0100
> @@ -1268,7 +1268,8 @@ static void cciss_softirq_done(struct re
> if (blk_fs_request(rq)) {
> const int rw = rq_data_dir(rq);
>
> - disk_stat_add(rq->rq_disk, sectors[rw],
> rq->nr_sectors);
> + all_stat_add(rq->rq_disk, sectors[rw],
> +rq->nr_sectors, rq->sector);
> }
How does this mesh with the changes submitted by Kiyoshi Ueda? Any conflicts?
-- mikem
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 21/30] blk_end_request: changing cciss (take 4)
> > > > Why is this removed? > > Sorry for the less explanation. > > Because it is done in __end_that_request_first() called from > blk_end_request(). > I'll add the explanation to the patch description when I > update the patch. > Thank you. I've Acked the patch. -- mikem -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 21/30] blk_end_request: changing cciss (take 4)
> -Original Message-
> From: Kiyoshi Ueda [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, December 11, 2007 4:50 PM
> To: [EMAIL PROTECTED]
> Cc: linux-kernel@vger.kernel.org; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED]; Miller, Mike (OS Dev)
> Subject: [PATCH 21/30] blk_end_request: changing cciss (take 4)
>
> This patch converts cciss to use blk_end_request interfaces.
> Related 'uptodate' arguments are converted to 'error'.
>
> cciss is a little bit different from "normal" drivers.
> cciss directly calls bio_endio() and disk_stat_add() when
> completing request. But those can be replaced with
> __end_that_request_first().
> After the replacement, request completion procedures of those
> drivers become like the following:
> o end_that_request_first()
> o add_disk_randomness()
> o end_that_request_last()
> This can be converted to blk_end_request() by following the
> rule (a) mentioned in the patch subject "[PATCH 01/30]
> blk_end_request: add new request completion interface".
>
> Cc: Mike Miller <[EMAIL PROTECTED]>
> Signed-off-by: Kiyoshi Ueda <[EMAIL PROTECTED]>
> Signed-off-by: Jun'ichi Nomura <[EMAIL PROTECTED]>
Acked-by: Mike Miller <[EMAIL PROTECTED]>
> ---
> drivers/block/cciss.c | 25 +++--
> 1 files changed, 3 insertions(+), 22 deletions(-)
>
> Index: 2.6.24-rc4/drivers/block/cciss.c
> ===
> --- 2.6.24-rc4.orig/drivers/block/cciss.c
> +++ 2.6.24-rc4/drivers/block/cciss.c
> @@ -1187,17 +1187,6 @@ static int cciss_ioctl(struct inode *ino
> }
> }
>
> -static inline void complete_buffers(struct bio *bio, int status) -{
> - while (bio) {
> - struct bio *xbh = bio->bi_next;
> -
> - bio->bi_next = NULL;
> - bio_endio(bio, status ? 0 : -EIO);
> - bio = xbh;
> - }
> -}
> -
> static void cciss_check_queues(ctlr_info_t *h) {
> int start_queue = h->next_to_run; @@ -1263,21
> +1252,14 @@ static void cciss_softirq_done(struct re
> pci_unmap_page(h->pdev, temp64.val,
> cmd->SG[i].Len, ddir);
> }
>
> - complete_buffers(rq->bio, (rq->errors == 0));
> -
> - if (blk_fs_request(rq)) {
> - const int rw = rq_data_dir(rq);
> -
> - disk_stat_add(rq->rq_disk, sectors[rw],
> rq->nr_sectors);
> - }
> -
> #ifdef CCISS_DEBUG
> printk("Done with %p\n", rq);
> #endif /* CCISS_DEBUG */
>
> - add_disk_randomness(rq->rq_disk);
> + if (blk_end_request(rq, (rq->errors == 0) ? 0 : -EIO,
> blk_rq_bytes(rq)))
> + BUG();
> +
> spin_lock_irqsave(&h->lock, flags);
> - end_that_request_last(rq, (rq->errors == 0));
> cmd_free(h, cmd, 1);
> cciss_check_queues(h);
> spin_unlock_irqrestore(&h->lock, flags); @@ -2544,7
> +2526,6 @@ after_error_processing:
> }
> cmd->rq->data_len = 0;
> cmd->rq->completion_data = cmd;
> - blk_add_trace_rq(cmd->rq->q, cmd->rq, BLK_TA_COMPLETE);
> blk_complete_request(cmd->rq);
> }
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 21/30] blk_end_request: changing cciss (take 4)
>
> This patch converts cciss to use blk_end_request interfaces.
> Related 'uptodate' arguments are converted to 'error'.
>
> cciss is a little bit different from "normal" drivers.
> cciss directly calls bio_endio() and disk_stat_add() when
> completing request. But those can be replaced with
> __end_that_request_first().
> After the replacement, request completion procedures of those
> drivers become like the following:
> o end_that_request_first()
> o add_disk_randomness()
> o end_that_request_last()
> This can be converted to blk_end_request() by following the
> rule (a) mentioned in the patch subject "[PATCH 01/30]
> blk_end_request: add new request completion interface".
>
> Cc: Mike Miller <[EMAIL PROTECTED]>
> Signed-off-by: Kiyoshi Ueda <[EMAIL PROTECTED]>
> Signed-off-by: Jun'ichi Nomura <[EMAIL PROTECTED]>
> ---
> drivers/block/cciss.c | 25 +++--
> 1 files changed, 3 insertions(+), 22 deletions(-)
>
> Index: 2.6.24-rc4/drivers/block/cciss.c
> ===
> --- 2.6.24-rc4.orig/drivers/block/cciss.c
> +++ 2.6.24-rc4/drivers/block/cciss.c
> @@ -1187,17 +1187,6 @@ static int cciss_ioctl(struct inode *ino
> }
> }
>
> -static inline void complete_buffers(struct bio *bio, int status) -{
> - while (bio) {
> - struct bio *xbh = bio->bi_next;
> -
> - bio->bi_next = NULL;
> - bio_endio(bio, status ? 0 : -EIO);
> - bio = xbh;
> - }
> -}
> -
> static void cciss_check_queues(ctlr_info_t *h) {
> int start_queue = h->next_to_run; @@ -1263,21
> +1252,14 @@ static void cciss_softirq_done(struct re
> pci_unmap_page(h->pdev, temp64.val,
> cmd->SG[i].Len, ddir);
> }
>
> - complete_buffers(rq->bio, (rq->errors == 0));
> -
> - if (blk_fs_request(rq)) {
> - const int rw = rq_data_dir(rq);
> -
> - disk_stat_add(rq->rq_disk, sectors[rw],
> rq->nr_sectors);
> - }
> -
> #ifdef CCISS_DEBUG
> printk("Done with %p\n", rq);
> #endif /* CCISS_DEBUG */
>
> - add_disk_randomness(rq->rq_disk);
> + if (blk_end_request(rq, (rq->errors == 0) ? 0 : -EIO,
> blk_rq_bytes(rq)))
> + BUG();
> +
> spin_lock_irqsave(&h->lock, flags);
> - end_that_request_last(rq, (rq->errors == 0));
> cmd_free(h, cmd, 1);
> cciss_check_queues(h);
> spin_unlock_irqrestore(&h->lock, flags); @@ -2544,7
> +2526,6 @@ after_error_processing:
> }
> cmd->rq->data_len = 0;
> cmd->rq->completion_data = cmd;
> - blk_add_trace_rq(cmd->rq->q, cmd->rq, BLK_TA_COMPLETE);
Why is this removed?
-- mikem
> blk_complete_request(cmd->rq);
> }
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 22/30] blk_end_request: changing cpqarray (take 4)
> -Original Message-
> From: Kiyoshi Ueda [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, December 11, 2007 4:50 PM
> To: [EMAIL PROTECTED]
> Cc: linux-kernel@vger.kernel.org; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED]; Miller, Mike (OS Dev)
> Subject: [PATCH 22/30] blk_end_request: changing cpqarray (take 4)
>
> This patch converts cpqarray to use blk_end_request interfaces.
> Related 'ok' arguments are converted to 'error'.
>
> cpqarray is a little bit different from "normal" drivers.
> cpqarray directly calls bio_endio() and disk_stat_add() when
> completing request. But those can be replaced with
> __end_that_request_first().
> After the replacement, request completion procedures of those
> drivers become like the following:
> o end_that_request_first()
> o add_disk_randomness()
> o end_that_request_last()
> This can be converted to __blk_end_request() by following the
> rule (b) mentioned in the patch subject "[PATCH 01/30]
> blk_end_request: add new request completion interface".
>
> Cc: Mike Miller <[EMAIL PROTECTED]>
> Signed-off-by: Kiyoshi Ueda <[EMAIL PROTECTED]>
> Signed-off-by: Jun'ichi Nomura <[EMAIL PROTECTED]>
Acked-by: Mike Miller <[EMAIL PROTECTED]>
> ---
> drivers/block/cpqarray.c | 36 +++-
> 1 files changed, 7 insertions(+), 29 deletions(-)
>
> Index: 2.6.24-rc4/drivers/block/cpqarray.c
> ===
> --- 2.6.24-rc4.orig/drivers/block/cpqarray.c
> +++ 2.6.24-rc4/drivers/block/cpqarray.c
> @@ -167,7 +167,6 @@ static void start_io(ctlr_info_t *h);
>
> static inline void addQ(cmdlist_t **Qptr, cmdlist_t *c);
> static inline cmdlist_t *removeQ(cmdlist_t **Qptr, cmdlist_t
> *c); -static inline void complete_buffers(struct bio *bio,
> int ok); static inline void complete_command(cmdlist_t *cmd,
> int timeout);
>
> static irqreturn_t do_ida_intr(int irq, void *dev_id); @@
> -980,26 +979,13 @@ static void start_io(ctlr_info_t *h)
> }
> }
>
> -static inline void complete_buffers(struct bio *bio, int ok) -{
> - struct bio *xbh;
> -
> - while (bio) {
> - xbh = bio->bi_next;
> - bio->bi_next = NULL;
> -
> - bio_endio(bio, ok ? 0 : -EIO);
> -
> - bio = xbh;
> - }
> -}
> /*
> * Mark all buffers that cmd was responsible for
> */
> static inline void complete_command(cmdlist_t *cmd, int timeout) {
> struct request *rq = cmd->rq;
> - int ok=1;
> + int error = 0;
> int i, ddir;
>
> if (cmd->req.hdr.rcode & RCODE_NONFATAL && @@
> -1011,16 +997,17 @@ static inline void complete_command(cmdl
> if (cmd->req.hdr.rcode & RCODE_FATAL) {
> printk(KERN_WARNING "Fatal error on ida/c%dd%d\n",
> cmd->ctlr, cmd->hdr.unit);
> - ok = 0;
> + error = -EIO;
> }
> if (cmd->req.hdr.rcode & RCODE_INVREQ) {
> printk(KERN_WARNING "Invalid
> request on ida/c%dd%d = (cmd=%x sect=%d cnt=%d sg=%d ret=%x)\n",
> cmd->ctlr, cmd->hdr.unit,
> cmd->req.hdr.cmd,
> cmd->req.hdr.blk,
> cmd->req.hdr.blk_cnt,
> cmd->req.hdr.sg_cnt,
> cmd->req.hdr.rcode);
> - ok = 0;
> + error = -EIO;
> }
> - if (timeout) ok = 0;
> + if (timeout)
> + error = -EIO;
> /* unmap the DMA mapping for all the scatter gather
> elements */
> if (cmd->req.hdr.cmd == IDA_READ)
> ddir = PCI_DMA_FROMDEVICE; @@ -1030,18
> +1017,9 @@ static inline void complete_command(cmdl
> pci_unmap_page(hba[cmd->ctlr]->pci_dev,
> cmd->req.sg[i].addr,
> cmd->req.sg[i].size, ddir);
>
> - complete_buffers(rq->bio, ok);
> -
> - if (blk_fs_request(rq)) {
> - const int rw = rq_data_dir(rq);
> -
> - disk_stat_add(rq->rq_disk, sectors[rw],
> rq->nr_sectors);
> - }
> -
> - add_disk_randomness(rq->rq_disk);
> -
> DBGPX(printk("Done with %p\n", rq););
> - end_that_request_last(rq, ok ? 1 : -EIO);
> + if (__blk_end_request(rq, error, blk_rq_bytes(rq)))
> + BUG();
> }
>
> /*
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] drivers/block/cpqarray,cciss: kill unused var
> -Original Message-
> From: Jeff Garzik [mailto:[EMAIL PROTECTED]
> Sent: Saturday, October 13, 2007 2:04 PM
> To: Andrew Morton; Linus Torvalds
> Cc: LKML; [EMAIL PROTECTED]; ISS StorageDev
> Subject: [PATCH] drivers/block/cpqarray,cciss: kill unused var
>
> The recent bio work and subsequent fixups created unused variables.
>
> Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
Acked-by: Mike Miller <[EMAIL PROTECTED]>
> ---
> drivers/block/cciss.c|1 -
> drivers/block/cpqarray.c |3 +--
> 2 files changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
> index 28d1457..27401d6 100644
> --- a/drivers/block/cciss.c
> +++ b/drivers/block/cciss.c
> @@ -1191,7 +1191,6 @@ static inline void
> complete_buffers(struct bio *bio, int status) {
> while (bio) {
> struct bio *xbh = bio->bi_next;
> - int nr_sectors = bio_sectors(bio);
>
> bio->bi_next = NULL;
> bio_endio(bio, status ? 0 : -EIO);
> diff --git a/drivers/block/cpqarray.c
> b/drivers/block/cpqarray.c index 3853c9a..568603d 100644
> --- a/drivers/block/cpqarray.c
> +++ b/drivers/block/cpqarray.c
> @@ -981,9 +981,8 @@ static void start_io(ctlr_info_t *h)
> static inline void complete_buffers(struct bio *bio, int ok) {
> struct bio *xbh;
> - while(bio) {
> - int nr_sectors = bio_sectors(bio);
>
> + while (bio) {
> xbh = bio->bi_next;
> bio->bi_next = NULL;
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [2.6 patch] drivers/block/cciss.c: fix check-after-use
> -Original Message-
> From: Adrian Bunk [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 30, 2007 5:28 PM
> To: Miller, Mike (OS Dev); Jens Axboe
> Cc: ISS StorageDev; linux-kernel@vger.kernel.org
> Subject: [2.6 patch] drivers/block/cciss.c: fix check-after-use
>
> The Coverity checker spotted that we have already oops'ed if "disk"
> was NULL.
>
> Since "disk" being NULL seems impossible at this point this
> patch removes the NULL check.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Acked-by: Mike Miller <[EMAIL PROTECTED]>
>
> ---
>
> drivers/block/cciss.c | 56
> --
> 1 file changed, 27 insertions(+), 29 deletions(-)
>
> --- linux-2.6.23-rc1-mm1/drivers/block/cciss.c.old
> 2007-07-30 02:27:15.0 +0200
> +++ linux-2.6.23-rc1-mm1/drivers/block/cciss.c
> 2007-07-30 02:28:28.0 +0200
> @@ -1569,66 +1569,64 @@ static int deregister_disk(struct gendis
> ctlr_info_t *h = get_host(disk);
>
> if (!capable(CAP_SYS_RAWIO))
> return -EPERM;
>
> /* make sure logical volume is NOT is use */
> if (clear_all || (h->gendisk[0] == disk)) {
> if (drv->usage_count > 1)
> return -EBUSY;
> } else if (drv->usage_count > 0)
> return -EBUSY;
>
> /* invalidate the devices and deregister the disk. If
> it is disk
>* zero do not deregister it but just zero out it's
> values. This
>* allows us to delete disk zero but keep the
> controller registered.
>*/
> if (h->gendisk[0] != disk) {
> - if (disk) {
> - struct request_queue *q = disk->queue;
> - if (disk->flags & GENHD_FL_UP)
> - del_gendisk(disk);
> - if (q) {
> - blk_cleanup_queue(q);
> - /* Set drv->queue to NULL so
> that we do not try
> - * to call blk_start_queue on
> this queue in the
> - * interrupt handler
> - */
> - drv->queue = NULL;
> - }
> - /* If clear_all is set then we are
> deleting the logical
> - * drive, not just refreshing its info.
> For drives
> - * other than disk 0 we will call
> put_disk. We do not
> - * do this for disk 0 as we need it to
> be able to
> - * configure the controller.
> + struct request_queue *q = disk->queue;
> + if (disk->flags & GENHD_FL_UP)
> + del_gendisk(disk);
> + if (q) {
> + blk_cleanup_queue(q);
> + /* Set drv->queue to NULL so that we do not try
> + * to call blk_start_queue on this queue in the
> + * interrupt handler
> + */
> + drv->queue = NULL;
> + }
> + /* If clear_all is set then we are deleting the logical
> + * drive, not just refreshing its info. For drives
> + * other than disk 0 we will call put_disk. We do not
> + * do this for disk 0 as we need it to be able to
> + * configure the controller.
> + */
> + if (clear_all){
> + /* This isn't pretty, but we need to find the
> + * disk in our array and NULL our the pointer.
> + * This is so that we will call alloc_disk if
> + * this index is used again later.
> */
> - if (clear_all){
> - /* This isn't pretty, but we
> need to find the
> - * disk in our array and NULL
> our the pointer.
> - * This is so that we will call
> alloc_disk if
> - * this index is used again later.
> - */
> - for (i=0; i < CISS_MAX_LUN; i++){
> - if(h->gendisk[i] == disk){
> - h->gendisk[i] = NULL;
> - break;
> - }
> + for (i=0; i < CISS_MAX_LUN; i++){
> + if(h->g
RE: [PATCH 10] drivers/block/cpqarray.c: better error handling and kmalloc + memset conversion to k[cz]alloc
> -Original Message-
> From: Mariusz Kozlowski [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 31, 2007 12:12 PM
> To: linux-kernel@vger.kernel.org
> Cc: [EMAIL PROTECTED]; Andrew Morton; ISS
> StorageDev; [EMAIL PROTECTED]
> Subject: [PATCH 10] drivers/block/cpqarray.c: better error
> handling and kmalloc + memset conversion to k[cz]alloc
>
> This patch removes some redundant casts, does the kmalloc +
> memset to k[cz]alloc conversion and it changes the error path
> to use goto (to avoid code duplication).
>
> Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>
Acked-by: Mike Miller <[EMAIL PROTECTED]>
>
> drivers/block/cpqarray.c | 49567 -> 48623 (-944 bytes)
> drivers/block/cpqarray.o | 178820 -> 178288 (-532 bytes)
>
> drivers/block/cpqarray.c | 78 -
> 1 file changed, 26 insertions(+), 52 deletions(-)
>
> --- linux-2.6.23-rc1-mm1-a/drivers/block/cpqarray.c
> 2007-07-26 13:07:41.0 +0200
> +++ linux-2.6.23-rc1-mm1-b/drivers/block/cpqarray.c
> 2007-07-31 12:59:54.0 +0200
> @@ -420,18 +420,17 @@ static int __init cpqarray_register_ctlr
> goto Enomem2;
> }
>
> - hba[i]->cmd_pool = (cmdlist_t *)pci_alloc_consistent(
> + hba[i]->cmd_pool = pci_alloc_consistent(
> hba[i]->pci_dev, NR_CMDS * sizeof(cmdlist_t),
> &(hba[i]->cmd_pool_dhandle));
> - hba[i]->cmd_pool_bits = kmalloc(
> -
> ((NR_CMDS+BITS_PER_LONG-1)/BITS_PER_LONG)*sizeof(unsigned long),
> + hba[i]->cmd_pool_bits = kcalloc(
> + (NR_CMDS+BITS_PER_LONG-1)/BITS_PER_LONG,
> sizeof(unsigned long),
> GFP_KERNEL);
>
> if (!hba[i]->cmd_pool_bits || !hba[i]->cmd_pool)
> goto Enomem1;
>
> memset(hba[i]->cmd_pool, 0, NR_CMDS * sizeof(cmdlist_t));
> - memset(hba[i]->cmd_pool_bits, 0,
> ((NR_CMDS+BITS_PER_LONG-1)/BITS_PER_LONG)*sizeof(unsigned long));
> printk(KERN_INFO "cpqarray: Finding drives on %s",
> hba[i]->devname);
>
> @@ -1660,45 +1659,30 @@ static void getgeometry(int ctlr)
>
> info_p->log_drv_map = 0;
>
> - id_ldrive = kmalloc(sizeof(id_log_drv_t), GFP_KERNEL);
> - if(id_ldrive == NULL)
> - {
> + id_ldrive = kzalloc(sizeof(id_log_drv_t), GFP_KERNEL);
> + if (!id_ldrive) {
> printk( KERN_ERR "cpqarray: out of memory.\n");
> - return;
> + goto err_0;
> }
>
> - id_ctlr_buf = kmalloc(sizeof(id_ctlr_t), GFP_KERNEL);
> - if(id_ctlr_buf == NULL)
> - {
> - kfree(id_ldrive);
> + id_ctlr_buf = kzalloc(sizeof(id_ctlr_t), GFP_KERNEL);
> + if (!id_ctlr_buf) {
> printk( KERN_ERR "cpqarray: out of memory.\n");
> - return;
> + goto err_1;
> }
>
> - id_lstatus_buf = kmalloc(sizeof(sense_log_drv_stat_t),
> GFP_KERNEL);
> - if(id_lstatus_buf == NULL)
> - {
> - kfree(id_ctlr_buf);
> - kfree(id_ldrive);
> + id_lstatus_buf = kzalloc(sizeof(sense_log_drv_stat_t),
> GFP_KERNEL);
> + if (!id_lstatus_buf) {
> printk( KERN_ERR "cpqarray: out of memory.\n");
> - return;
> + goto err_2;
> }
>
> - sense_config_buf = kmalloc(sizeof(config_t), GFP_KERNEL);
> - if(sense_config_buf == NULL)
> - {
> - kfree(id_lstatus_buf);
> - kfree(id_ctlr_buf);
> - kfree(id_ldrive);
> + sense_config_buf = kzalloc(sizeof(config_t), GFP_KERNEL);
> + if (!sense_config_buf) {
> printk( KERN_ERR "cpqarray: out of memory.\n");
> - return;
> + goto err_3;
> }
>
> - memset(id_ldrive, 0, sizeof(id_log_drv_t));
> - memset(id_ctlr_buf, 0, sizeof(id_ctlr_t));
> - memset(id_lstatus_buf, 0, sizeof(sense_log_drv_stat_t));
> - memset(sense_config_buf, 0, sizeof(config_t));
> -
> info_p->phys_drives = 0;
> info_p->log_drv_map = 0;
> info_p->drv_assign_map = 0;
> @@ -1712,13 +1696,8 @@ static void getgeometry(int ctlr)
>* so the idastubopen will fail on all logical drives
>* on the controller.
>*/
> - /* Free all the buffers and return */
> printk(KERN_ERR "cpqarray: error sending ID
> controller\n");
> - kfree(sense_config_buf);
> -kfree(id_lstatus_buf);
> -kfree(id_ctlr_buf);
> -kfree(id_ldrive);
> -return;
> +goto err_4;
> }
>
> info_p->log_drives = id_ctlr_buf->nr_drvs; @@ -1764,12
> +1743,7 @@ static void getgeometry(int ctlr)
> " failed to report status of
> logical drive %d\n"
>"Access to this controller has been
> disabled\n",
> ctlr, log_unit);
> - /* Free all the buffers and return */
> -
RE: [PATCH 07] drivers/block/cciss.c: kmalloc + memset conversion to kzalloc
> -Original Message-
> From: Mariusz Kozlowski [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 31, 2007 12:04 PM
> To: linux-kernel@vger.kernel.org
> Cc: [EMAIL PROTECTED]; Andrew Morton; ISS
> StorageDev; [EMAIL PROTECTED]
> Subject: [PATCH 07] drivers/block/cciss.c: kmalloc + memset
> conversion to kzalloc
>
> Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>
Acked-by: Mike Miller <[EMAIL PROTECTED]>
>
> drivers/block/cciss.c | 104285 -> 104168 (-117 bytes)
> drivers/block/cciss.o | 277400 -> 277124 (-276 bytes)
>
> drivers/block/cciss.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> --- linux-2.6.23-rc1-mm1-a/drivers/block/cciss.c
> 2007-07-26 13:07:41.0 +0200
> +++ linux-2.6.23-rc1-mm1-b/drivers/block/cciss.c
> 2007-07-31 12:57:50.0 +0200
> @@ -1977,12 +1977,13 @@ cciss_read_capacity(int ctlr, int logvol {
> ReadCapdata_struct *buf;
> int return_code;
> - buf = kmalloc(sizeof(ReadCapdata_struct), GFP_KERNEL);
> - if (buf == NULL) {
> +
> + buf = kzalloc(sizeof(ReadCapdata_struct), GFP_KERNEL);
> + if (!buf) {
> printk(KERN_WARNING "cciss: out of memory\n");
> return;
> }
> - memset(buf, 0, sizeof(ReadCapdata_struct));
> +
> if (withirq)
> return_code = sendcmd_withirq(CCISS_READ_CAPACITY,
> ctlr, buf,
> sizeof(ReadCapdata_struct), @@ -2003,7 +2004,6 @@
> cciss_read_capacity(int ctlr, int logvol
> printk(KERN_INFO " blocks= %llu block_size= %d\n",
> (unsigned long long)*total_size+1, *block_size);
> kfree(buf);
> - return;
> }
>
> static void
> @@ -2011,12 +2011,13 @@ cciss_read_capacity_16(int ctlr, int log {
> ReadCapdata_struct_16 *buf;
> int return_code;
> - buf = kmalloc(sizeof(ReadCapdata_struct_16), GFP_KERNEL);
> - if (buf == NULL) {
> +
> + buf = kzalloc(sizeof(ReadCapdata_struct_16), GFP_KERNEL);
> + if (!buf) {
> printk(KERN_WARNING "cciss: out of memory\n");
> return;
> }
> - memset(buf, 0, sizeof(ReadCapdata_struct_16));
> +
> if (withirq) {
> return_code = sendcmd_withirq(CCISS_READ_CAPACITY_16,
> ctlr, buf,
> sizeof(ReadCapdata_struct_16), @@ -2038,7 +2039,6 @@
> cciss_read_capacity_16(int ctlr, int log
> printk(KERN_INFO " blocks= %llu block_size= %d\n",
> (unsigned long long)*total_size+1, *block_size);
> kfree(buf);
> - return;
> }
>
> static int cciss_revalidate(struct gendisk *disk)
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] cciss: force ignore of responses to unsent scsi commands after kexec reboot
> -Original Message- > From: Miller, Mike (OS Dev) > Sent: Thursday, June 14, 2007 1:16 PM > To: 'Neil Horman'; linux-kernel@vger.kernel.org > Cc: ISS StorageDev; [EMAIL PROTECTED] > Subject: RE: [PATCH] cciss: force ignore of responses to > unsent scsi commands after kexec reboot > > > > > -Original Message- > > From: Neil Horman [mailto:[EMAIL PROTECTED] > > Sent: Thursday, June 14, 2007 10:31 AM > > To: linux-kernel@vger.kernel.org > > Cc: Miller, Mike (OS Dev); ISS StorageDev; > [EMAIL PROTECTED]; > > [EMAIL PROTECTED] > > Subject: [PATCH] cciss: force ignore of responses to unsent scsi > > commands after kexec reboot > > > > Hey - > > cciss hardware currently can continue to send responses to scsi > > commands after the host system has undergone a kexec > reboot. The way > > the drier is currently written, reception of these commands > results in > > a BUG halt, since it can't match the response to any issued command > > since the boot. This patch corrects that by using the kexec > > reset_devices command line paramter to force ignore any > commands that > > it cant correlate. > > > > Regards > > Neil > > > > Signed-off-by: Neil Horman <[EMAIL PROTECTED]> Nacked-by: Mike Miller <[EMAIL PROTECTED]> > > > > > > cciss.c |8 > > 1 file changed, 8 insertions(+) > > > > > > diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c index > > 5acc6c4..ec1c1d2 100644 > > --- a/drivers/block/cciss.c > > +++ b/drivers/block/cciss.c > > @@ -2131,6 +2131,14 @@ static int add_sendcmd_reject(__u8 cmd, int > > ctlr, unsigned long complete) > >ctlr, complete); > > /* not much we can do. */ > > #ifdef CONFIG_CISS_SCSI_TAPE > > + /* We might get notification of completion of commands > > +* which we never issued in this kernel if this boot is > > +* taking place after previous kernel's crash. Simply > > +* ignore the commands in this case. > > +*/ > > + if (reset_devices) > > + return 0; > > + > > return 1; > > } > > > I don't understand how this will help. We need to reset the > controller which reset_devices cannot do alone. I just > haven't have the time to implement the fix yet. > > mikem > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1] cciss: add new controller support for P700m
> -Original Message- > From: Jens Axboe [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 19, 2007 1:51 PM > To: Miller, Mike (OS Dev) > Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; > [EMAIL PROTECTED] > Subject: Re: [PATCH 1/1] cciss: add new controller support for P700m > > On Tue, Jun 19 2007, Mike Miller (OS Dev) wrote: > > PATCH 1/1 > > > > This patch adds support for the Smart Array P700m SAS > controller. This > > new controller will ship Fall 2008. Please consider this > for inclusion. > > Fall 2007? Thank you. Yes, 2007. I forgot where I was for a moment. :) mikem > > Queued for 2.6.23. > > -- > Jens Axboe > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] cciss: force ignore of responses to unsent scsi commands after kexec reboot
Vivek wrote: > > I think this is not the right usage of reset_devices > parameter. This parameter instructs the driver to reset the > device before going ahead with rest of the initialization > before as underlying device might not be in a sane state. > kexec/kdump is one of the usages and this can also be useful > in the case of BIOS not doing its job. > > When I had proposed crash_boot parameter for kexec/kdump > purposes, that time andrew had suggested that he is afraid > that driver authors will use this parameter to solve all kind > of problems. > > I think we should stick to the theme of the parameter and > implement the reset routine for cciss driver instead of > simply returning back. Consider the case of hypothetical > scenario where somebody booted the kernel with reset_device > parameter (because of unreliable bios) and if there is a > problem on kernel side that after it issues the command it > lost track of that (because of kernel bug) then driver will > never catch that bug as upon receiving the response it will > simply ignore that. > > Mike, you know most about this device. Can you please help > out with implementing a reset routing for it? > Vivek I think I finally have an idea that will work. (`bout time!) We actually have 2 different issues. One is that there may outstanding commands on the controller when the kdump kernel initializes. Our SAS controllers support the reset message defined in the open CISS spec which will (hopefully) resolve this issue. The second problem is that I cannot allocate my MSI-X vectors because I couldn't free the vectors then disable MSI. So the cciss driver would most likely panic at that time. My idea for this is to put the card into INTx mode rather than MSI or MSI-X. That should the 2nd issue. I haven't tested the 64xx series to see if they support the reset message. I should to write the code today, maybe test by tomorrow and then send something upstream. mikem - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] cciss: force ignore of responses to unsent scsi commands after kexec reboot
> -Original Message- > From: Neil Horman [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 14, 2007 10:31 AM > To: linux-kernel@vger.kernel.org > Cc: Miller, Mike (OS Dev); ISS StorageDev; > [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: [PATCH] cciss: force ignore of responses to unsent > scsi commands after kexec reboot > > Hey - > cciss hardware currently can continue to send responses > to scsi commands after the host system has undergone a kexec > reboot. The way the drier is currently written, reception of > these commands results in a BUG halt, since it can't match > the response to any issued command since the boot. This > patch corrects that by using the kexec reset_devices command > line paramter to force ignore any commands that it cant correlate. > > Regards > Neil > > Signed-off-by: Neil Horman <[EMAIL PROTECTED]> > > > cciss.c |8 > 1 file changed, 8 insertions(+) > > > diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c > index 5acc6c4..ec1c1d2 100644 > --- a/drivers/block/cciss.c > +++ b/drivers/block/cciss.c > @@ -2131,6 +2131,14 @@ static int add_sendcmd_reject(__u8 > cmd, int ctlr, unsigned long complete) > ctlr, complete); > /* not much we can do. */ > #ifdef CONFIG_CISS_SCSI_TAPE > + /* We might get notification of completion of commands > + * which we never issued in this kernel if this boot is > + * taking place after previous kernel's crash. Simply > + * ignore the commands in this case. > + */ > + if (reset_devices) > + return 0; > + > return 1; > } > I don't understand how this will help. We need to reset the controller which reset_devices cannot do alone. I just haven't have the time to implement the fix yet. mikem - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] cciss: Fix pci_driver.shutdown while device is still active
> -Original Message-
> From: Gerald Britton [mailto:[EMAIL PROTECTED]
> Sent: Monday, May 14, 2007 12:53 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED];
> Miller, Mike (OS Dev); ISS StorageDev;
> [EMAIL PROTECTED]; linux-kernel@vger.kernel.org
> Subject: [PATCH] cciss: Fix pci_driver.shutdown while device
> is still active
>
> Fix an Oops in the cciss driver caused by system shutdown
> while a filesystem on a cciss device is still active. The
> cciss_remove_one function only properly removes the device if
> the device has been cleanly released by its users, which is
> not the case when the pci_driver.shutdown method is called.
Please send the Oops output.
mikem
>
> This patch adds a new cciss_shutdown function to better match
> the pattern used by various SCSI drivers: deactivate device
> interrupts and flush caches.
> It also alters the cciss_remove_one function to match and
> readds the __devexit annotation that was removed when
> cciss_remove_one was serving as the pci_driver.shutdown method.
>
> Signed-off-by: Gerald Britton <[EMAIL PROTECTED]>
> ---
> diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
> index 370dfe1..5acc6c4 100644
> --- a/drivers/block/cciss.c
> +++ b/drivers/block/cciss.c
> @@ -3469,13 +3469,39 @@ static int __devinit
> cciss_init_one(struct pci_dev *pdev,
> return -1;
> }
>
> -static void cciss_remove_one(struct pci_dev *pdev)
> +static void cciss_shutdown(struct pci_dev *pdev)
> {
> ctlr_info_t *tmp_ptr;
> - int i, j;
> + int i;
> char flush_buf[4];
> int return_code;
>
> + tmp_ptr = pci_get_drvdata(pdev);
> + if (tmp_ptr == NULL)
> + return;
> + i = tmp_ptr->ctlr;
> + if (hba[i] == NULL)
> + return;
> +
> + /* Turn board interrupts off and send the flush cache
> command */
> + /* sendcmd will turn off interrupt, and send the flush...
> + * To write all data in the battery backed cache to disks */
> + memset(flush_buf, 0, 4);
> + return_code = sendcmd(CCISS_CACHE_FLUSH, i, flush_buf,
> 4, 0, 0, 0, NULL,
> + TYPE_CMD);
> + if (return_code == IO_OK) {
> + printk(KERN_INFO "Completed flushing cache on
> controller %d\n", i);
> + } else {
> + printk(KERN_WARNING "Error flushing cache on
> controller %d\n", i);
> + }
> + free_irq(hba[i]->intr[2], hba[i]);
> +}
> +
> +static void __devexit cciss_remove_one(struct pci_dev *pdev) {
> + ctlr_info_t *tmp_ptr;
> + int i, j;
> +
> if (pci_get_drvdata(pdev) == NULL) {
> printk(KERN_ERR "cciss: Unable to remove device \n");
> return;
> @@ -3506,18 +3532,7 @@ static void cciss_remove_one(struct
> pci_dev *pdev)
>
> cciss_unregister_scsi(i); /* unhook from SCSI subsystem */
>
> - /* Turn board interrupts off and send the flush cache
> command */
> - /* sendcmd will turn off interrupt, and send the flush...
> - * To write all data in the battery backed cache to disks */
> - memset(flush_buf, 0, 4);
> - return_code = sendcmd(CCISS_CACHE_FLUSH, i, flush_buf,
> 4, 0, 0, 0, NULL,
> - TYPE_CMD);
> - if (return_code == IO_OK) {
> - printk(KERN_INFO "Completed flushing cache on
> controller %d\n", i);
> - } else {
> - printk(KERN_WARNING "Error flushing cache on
> controller %d\n", i);
> - }
> - free_irq(hba[i]->intr[2], hba[i]);
> + cciss_shutdown(pdev);
>
> #ifdef CONFIG_PCI_MSI
> if (hba[i]->msix_vector)
> @@ -3550,7 +3565,7 @@ static struct pci_driver cciss_pci_driver = {
> .probe = cciss_init_one,
> .remove = __devexit_p(cciss_remove_one),
> .id_table = cciss_pci_device_id,/* id_table */
> - .shutdown = cciss_remove_one,
> + .shutdown = cciss_shutdown,
> };
>
> /*
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] cciss: Fix warnings during compilation under 32bitenvironment
> -Original Message- > From: James Bottomley [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 19, 2007 11:22 AM > To: Miller, Mike (OS Dev) > Cc: Hisashi Hifumi; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; > [EMAIL PROTECTED]; Cameron, Steve > Subject: RE: [PATCH] cciss: Fix warnings during compilation > under 32bitenvironment > > On Thu, 2007-04-19 at 16:12 +, Miller, Mike (OS Dev) wrote: > > > > Nak. You still haven't told where you saw these warnings. What > > > > compiler are you using? I do not see these in my 32-bit > environment. > > > > > > I think it's seen with CONFIG_LBD=n on 32 bits > > > > > > In that configuration, sector_t is a u32 (it's u64 even > on 32 bits > > > with CONFIG_LBD=y). The proposed code change is a simple cut and > > > paste from the sd driver. > > > > Isn't there a better way than testing each one? > > It's not such a bad option. The sizeof() test is compile > time determinable, so the compiler simply zeros the fields in > the CONFIG_LBD=n case and does the shift for CONFIG_LBD=y. > It certainly never compiles to four inline condition checks. > OKIE-DOKIE then, add the change. Acked-by: Mike Miller <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] cciss: Fix warnings during compilation under 32bit environment
> -Original Message- > From: James Bottomley [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 19, 2007 10:19 AM > To: Miller, Mike (OS Dev) > Cc: Hisashi Hifumi; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; > [EMAIL PROTECTED]; Cameron, Steve > Subject: RE: [PATCH] cciss: Fix warnings during compilation > under 32bit environment > > On Thu, 2007-04-19 at 15:09 +, Miller, Mike (OS Dev) wrote: > > Nak. You still haven't told where you saw these warnings. What > > compiler are you using? I do not see these in my 32-bit environment. > > I think it's seen with CONFIG_LBD=n on 32 bits > > In that configuration, sector_t is a u32 (it's u64 even on 32 > bits with CONFIG_LBD=y). The proposed code change is a > simple cut and paste from the sd driver. Isn't there a better way than testing each one? mikem > > James > > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] cciss: Fix warnings during compilation under 32bit environment
> -Original Message-
> From: Hisashi Hifumi [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, April 18, 2007 2:03 AM
> To: Miller, Mike (OS Dev); [EMAIL PROTECTED]
> Subject: [PATCH] cciss: Fix warnings during compilation under
> 32bit environment
>
>
> Hi.
>
> I fixed following warnings.
>
> drivers/block/cciss.c: In function `do_cciss_request':
> drivers/block/cciss.c:2555: warning: right shift count >=
> width of type
> drivers/block/cciss.c:2556: warning: right shift count >=
> width of type
> drivers/block/cciss.c:2557: warning: right shift count >=
> width of type
> drivers/block/cciss.c:2558: warning: right shift count >=
> width of type
>
>
> Signed-off-by :Hisashi Hifumi <[EMAIL PROTECTED]>
Nak. You still haven't told where you saw these warnings. What compiler
are you using? I do not see these in my 32-bit environment.
mikem
>
>
> --- linux-2.6.21-rc7.org/drivers/block/cciss.c2007-04-17
> 16:36:02.0 +0900
> +++ linux-2.6.21-rc7/drivers/block/cciss.c2007-04-17
> 16:25:53.0 +0900
> @@ -2552,10 +2552,10 @@ static void do_cciss_request(request_que
> } else {
> c->Request.CDBLen = 16;
> c->Request.CDB[1]= 0;
> - c->Request.CDB[2]= (start_blk >> 56) & 0xff;//MSB
> - c->Request.CDB[3]= (start_blk >> 48) & 0xff;
> - c->Request.CDB[4]= (start_blk >> 40) & 0xff;
> - c->Request.CDB[5]= (start_blk >> 32) & 0xff;
> + c->Request.CDB[2]= sizeof(start_blk) > 4 ?
> (start_blk >> 56) & 0xff : 0; //MSB
> + c->Request.CDB[3]= sizeof(start_blk) > 4 ?
> (start_blk >> 48) & 0xff : 0;
> + c->Request.CDB[4]= sizeof(start_blk) > 4 ?
> (start_blk >> 40) & 0xff : 0;
> + c->Request.CDB[5]= sizeof(start_blk) > 4 ?
> (start_blk >> 32) & 0xff :
> +0;
> c->Request.CDB[6]= (start_blk >> 24) & 0xff;
> c->Request.CDB[7]= (start_blk >> 16) & 0xff;
> c->Request.CDB[8]= (start_blk >> 8) & 0xff;
>
>
>
> Thanks,
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [patch] cciss: unregister from SCSI before tearing down device resources
> -Original Message-
> From: Helgaas, Bjorn
> Sent: Tuesday, April 10, 2007 1:07 PM
> To: Helgaas, Bjorn; Miller, Mike (OS Dev)
> Cc: Andrew Morton; ISS StorageDev; linux-kernel@vger.kernel.org
> Subject: [patch] cciss: unregister from SCSI before tearing
> down device resources
>
> We must unregister from SCSI before we unmap device resources
> and unhook the IRQ handler. Otherwise, SCSI may send us more
> requests, and we won't be able to handle them.
>
> I'd like to see this patch in 2.6.21. In 2.6.21-rc6, I see
> the following oops during every reboot of my HP DL360:
>
> ...
> Unmounting local filesystems...done.
> Rebooting... Completed flushing cache on controller 0
> BUG: unable to handle kernel paging request at virtual
> address f8808040
> printing eip:
> c02dc72b
> *pde = 02120067
> *pte =
> Oops: 0002 [#1]
> SMP
> Modules linked in:
> CPU:1
> EIP:0060:[]Not tainted VLI
> EFLAGS: 00010046 (2.6.21-rc6 #1)
> EIP is at SA5_submit_command+0xb/0x20
> eax: f8808000 ebx: f7a0 ecx: f79f edx: 37a0
> esi: f79f edi: ebp: esp: dd717a44
> ds: 007b es: 007b fs: 00d8 gs: ss: 0068
> Process khelper (pid: 1427, ti=dd716000 task=c2260a70
> task.ti=dd716000)
> Stack: c02df2c0 f7a0 f7a0 00d41008 c02df691
> 0010 0002
> 0001 f79f f7fff844 c1398420
> 1000 230a3020
> 69666564 5420656e 50434f49 465f544b 4853554c
> 44414552 0a312009 66656423
> Call Trace:
> [] start_io+0x80/0x120
> [] do_cciss_request+0x331/0x350
> [] mempool_alloc+0x2a/0xe0
> [] blk_alloc_request+0x61/0x80
> [] get_request+0x15e/0x1e0
> [] cache_alloc_refill+0xb0/0x1e0
> [] as_update_rq+0x2d/0x80
> [] as_add_request+0x68/0x90
> [] elv_insert+0x119/0x160
> [] __make_request+0xcb/0x320
> [] lock_timer_base+0x20/0x50
> [] del_timer+0x56/0x60
> [] blk_remove_plug+0x38/0x70
> [] __generic_unplug_device+0x25/0x30
> [] generic_unplug_device+0x15/0x30
> ...
>
> Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
ACKed-by: Mike Miller <[EMAIL PROTECTED]>
>
> Index: cciss/drivers/block/cciss.c
> ===
> --- cciss.orig/drivers/block/cciss.c 2007-04-10
> 09:46:09.0 -0600
> +++ cciss/drivers/block/cciss.c 2007-04-10
> 10:11:06.0 -0600
> @@ -3423,6 +3423,25 @@
> "already be removed \n");
> return;
> }
> +
> + remove_proc_entry(hba[i]->devname, proc_cciss);
> + unregister_blkdev(hba[i]->major, hba[i]->devname);
> +
> + /* remove it from the disk list */
> + for (j = 0; j < CISS_MAX_LUN; j++) {
> + struct gendisk *disk = hba[i]->gendisk[j];
> + if (disk) {
> + request_queue_t *q = disk->queue;
> +
> + if (disk->flags & GENHD_FL_UP)
> + del_gendisk(disk);
> + if (q)
> + blk_cleanup_queue(q);
> + }
> + }
> +
> + cciss_unregister_scsi(i); /* unhook from SCSI subsystem */
> +
> /* Turn board interrupts off and send the flush cache
> command */
> /* sendcmd will turn off interrupt, and send the flush...
>* To write all data in the battery backed cache to
> disks */ @@ -3444,22 +3463,6 @@
> #endif /* CONFIG_PCI_MSI */
>
> iounmap(hba[i]->vaddr);
> - cciss_unregister_scsi(i); /* unhook from SCSI subsystem */
> - unregister_blkdev(hba[i]->major, hba[i]->devname);
> - remove_proc_entry(hba[i]->devname, proc_cciss);
> -
> - /* remove it from the disk list */
> - for (j = 0; j < CISS_MAX_LUN; j++) {
> - struct gendisk *disk = hba[i]->gendisk[j];
> - if (disk) {
> - request_queue_t *q = disk->queue;
> -
> - if (disk->flags & GENHD_FL_UP)
> - del_gendisk(disk);
> - if (q)
> - blk_cleanup_queue(q);
> - }
> - }
>
> pci_free_consistent(hba[i]->pdev, hba[i]->nr_cmds *
> sizeof(CommandList_struct),
> hba[i]->cmd_pool, hba[i]->cmd_pool_dhandle);
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] Perverting cciss
James wrote: > > On Thu, 2007-04-05 at 11:03 +0100, Christoph Hellwig wrote: > > On Thu, Apr 05, 2007 at 11:58:06AM +0200, Hannes Reinecke wrote: > > > Hi All, > > > > > > this patch adds the SG_IO ioctl to the cciss driver. > > > As the driver is capable of sending SCSI CDBs to the controller > > > there is no reason why we shouldn't exploit it. > > > This way we get to use all the nice sg_utils for the cciss driver. > > > And a persistent device name for free. > > > > Instead of adding yet another implementation of SG_IO > please implement > > support for REQ_TYPE_BLOCK_PC requests and add all the nice block > > layer passthrough ioctls to it. > > Actually, I happen to know that HP is in the process of > implementing this correctly (via REQ_TYPE_BLOCK_PC). I can't > reveal the details but it has something to do with a well > known Linux High Availability company needing SG_IO for > sg_persist to work ... > > James NAK. Please do not add this patch to cciss. We are working SG_IO internally and will post the patch soon. mikem > > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [Patch 1/2] cciss: fix for 2TB support
> -Original Message-
> From: Mike Miller (OS Dev) [mailto:[EMAIL PROTECTED]
>
> Andrew,
> Using this test program and changing the type of x to int,
> long, long long signed and unsigned the comparison always
> worked on x86, x86_64, and ia64. It looks to me like the
> comparsion will always do what we expect. Unless you see some
> other problem.
>
>
> #include
>
> int main(int argc, char *argv[])
> {
> unsigned long long x;
>
> x = 0x;
>
> printf(sizeof(x) == 8 ?
> "x = %lld, sizeof(x) = %d\n" :
> "x = %ld, sizeof(x) = %d\n", x, sizeof(x));
> if (x == 0x)
> printf("equal\n");
> else
> printf("not equal\n");
>
> }
>
> -- mikem
>
BTW: also changed x to be 8 f's, 16 f's, and 8 and 8 as shown.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: PME_Turn_Off in Linux
greg k-h wrote: > On Wed, Jan 17, 2007 at 10:43:14AM -0600, Miller, Mike (OS Dev) wrote: > > Hello, > > We've been seeing some nasty data corruption issues on some > platforms. > > We've been capturing PCI-E traces looking for something > nasty but we > > haven't found anything yet. One of the hardware guys if asking if > > there is a call in Linux to issue a PME_Turn_Off broadcast message. > > > > PME_Turn_Off Broadcast Message > > Before main component power and reference clocks are turned > off, the > > Root Complex or Switch Downstream Port must issue a > broadcast Message > > that instructs all agents downstream of that point within the > > hierarchy to cease initiation of any subsequent PM_PME Messages, > > effective immediately upon receipt of the PME_Turn_Off Message. > > > > This must be initiated from the root complex. Is there such > a call in > > linux? > > This firmware that implements the PCI-E connection should do > this, I don't think there is anything that the Operating > system can do to control this, as PCI-E should be transparant > to the OS. Hmmm, the hw folks tell me that "other" os'es implement that. But I would tend to agree that system firmware should probably be doing this. > > Unless this is on a PCI-E Hotplug system? What is the No hotplug. > sequence of events that cause the data corruption? Install rhel4 u4 on ia64, at the reboot prompt let the system sit idle for several hours or overnight. Then after rebooting the filesystems are totally trashed. I usually get a message that the kernel is not a valid compressed file format. If I try to rescue the system I cannot mount any filesystems. I don't have the message handy but it complains about an invalid Verneed record, whatever that is. I've also tried the same procedure using a dumb SAS hba. It complained that it couldn't read the initrd image but on a second attempt it acted like it read the initrd but the system goes out in the weeds while booting. Not the same symptoms but I suspect there's some relationship. I have not tried any other distros yet. Thanks, mikem - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PME_Turn_Off in Linux
Hello, We've been seeing some nasty data corruption issues on some platforms. We've been capturing PCI-E traces looking for something nasty but we haven't found anything yet. One of the hardware guys if asking if there is a call in Linux to issue a PME_Turn_Off broadcast message. PME_Turn_Off Broadcast Message Before main component power and reference clocks are turned off, the Root Complex or Switch Downstream Port must issue a broadcast Message that instructs all agents downstream of that point within the hierarchy to cease initiation of any subsequent PM_PME Messages, effective immediately upon receipt of the PME_Turn_Off Message. This must be initiated from the root complex. Is there such a call in linux? Thanks, mikem - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.19-git20 cciss: cmd f7b00000 timedout
> -Original Message- > From: Frazier, Daniel Kent > Sent: Thursday, December 14, 2006 3:12 PM > To: Miller, Mike (OS Dev) > Cc: Jens Axboe; Steve Roemen; LKML; ISS StorageDev > Subject: Re: 2.6.19-git20 cciss: cmd f7b0 timedout > > On Thu, Dec 14, 2006 at 01:44:34PM -0600, Miller, Mike (OS Dev) wrote: > > > > > > > -Original Message- > > > From: Jens Axboe [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, December 14, 2006 12:51 PM > > > To: Steve Roemen > > > Cc: LKML; ISS StorageDev; Miller, Mike (OS Dev) > > > Subject: Re: 2.6.19-git20 cciss: cmd f7b0 timedout > > > > > > On Thu, Dec 14 2006, Steve Roemen wrote: > > > > -BEGIN PGP SIGNED MESSAGE- > > > > Hash: SHA1 > > > > > > > > All, > > > > I tried out the 2.6.19-git20 kernel on one of my > machines (HP > > > > DL380 G3) that has the on board 5i controller (disabled), > > > > 2 smart array 642 controllers. > > > > > > > > I get the error (cciss: cmd f7b0 timedout) with Buffer > > > I/O error > > > > on device cciss/c (all cards, and disks) logical block 0, 1, 2, > > > > etc > > > > > > I saw this on another box, but it works on the ones that I have. > > > Does > > > 2.6.19 work? Any chance you can try and narrow down when it broke? > > > > Jens/Steve: > > We also encountered a time out issue on the 642. This one > is connected > > to an MSA500. Do either of you have MSA500? What controller > fw are you > > running? Check /proc/driver/cciss/ccissN. > > fyi, we've been seeing this in Debian too (which is why Mike > added me to the CC list), and I've narrowed it down to the > 2TB patch that went into 2.6.19: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=402787 H. Dann, did you see this on 32-bit Debian? I have this running in the lab on x86_64 and ia64. Someone else was _supposed_ to test ia32 for me. Dammit. Jens/Steve: Are your os'es 32-bit? mikem > -- > dann frazier | HP Open Source and Linux Organization > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.19-git20 cciss: cmd f7b00000 timedout
> -Original Message- > From: Steve Roemen [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 14, 2006 2:14 PM > To: Miller, Mike (OS Dev) > Cc: Jens Axboe; LKML; ISS StorageDev; Frazier, Daniel Kent > Subject: Re: 2.6.19-git20 cciss: cmd f7b0 timedout > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > MIke, Yes it's connected to a MSA 500 G2 > > the two 642's firmware are 2.34 for card 1, and 2.58 for card 2 What's the fw on the msa? You should be able to get that from the LCD display. mikem > > > Steve > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.3 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFFgbB1cA4cgQlZoQ8RAoWGAKCPgdqX2QYl69V0i7cJACmP3LJ40wCfX932 > ZEZEQGPhxYhJej0ovQ+6Spw= > =uIik > -END PGP SIGNATURE- > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.19-git20 cciss: cmd f7b00000 timedout
> -Original Message- > From: Jens Axboe [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 14, 2006 12:51 PM > To: Steve Roemen > Cc: LKML; ISS StorageDev; Miller, Mike (OS Dev) > Subject: Re: 2.6.19-git20 cciss: cmd f7b0 timedout > > On Thu, Dec 14 2006, Steve Roemen wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > All, > > I tried out the 2.6.19-git20 kernel on one of my machines (HP > > DL380 G3) that has the on board 5i controller (disabled), > > 2 smart array 642 controllers. > > > > I get the error (cciss: cmd f7b0 timedout) with Buffer > I/O error > > on device cciss/c (all cards, and disks) logical block 0, 1, 2, etc > > I saw this on another box, but it works on the ones that I have. Does > 2.6.19 work? Any chance you can try and narrow down when it broke? Jens/Steve: We also encountered a time out issue on the 642. This one is connected to an MSA500. Do either of you have MSA500? What controller fw are you running? Check /proc/driver/cciss/ccissN. mikem > > -- > Jens Axboe > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: can't boot 2.6.13
Thanks, Eric. Anyone have any ideas why my cciss based system won't boot? mikem > -Original Message- > From: Moore, Eric Dean [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 08, 2005 5:52 PM > To: Miller, Mike (OS Dev); linux-kernel@vger.kernel.org; > linux-scsi@vger.kernel.org > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: can't boot 2.6.13 > > On Thursday, September 08, 2005 3:19 PM, Mike Miller(HP) wrote: > > I am not able to boot the 2.6.13 version of the kernel. I've tried > > different systems, tried downloading again, still nothing. > Here's the > > last thing I see from the serial port: > > > > md: Autodetecting RAID arrays. > > md: autorun ... > > md: ... autorun DONE. > > RAMDISK: Compressed image found at block 0 > > input: AT Translated Set 2 keyboard on isa0060/serio0 > > VFS: Mounted root (ext2 filesystem). > > logips2pp: Detected unknown logitech mouse model 1 > > input: PS/2 Logitech Mouse on isa0060/serio1 SCSI subsystem > > initialized Fusion MPT base driver 3.03.02 Copyright (c) > 1999-2005 LSI > > Logic Corporation > > > > We introduced split drivers for 2.6.13. There are new layer > drivers that sit ontop of mptscsih.ko. These drivers are > split along bus protocal, so there is mptspi.ko, mptfc.ko, > and mptsas.ko. This is to tie into the scsi transport layers > that are split the same. > > For 1030(a SPI controller) > If your using RedHat, you need to change mptscish to mptspi > in /etc/modprobe.conf. > If your using SuSE, you need to change mptscish to mptspi in > /etc/sysconfig/kernel > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6: how do I this in sysfs?
> This is after my minimal sas transport class, please also
> read the thread about it on linux-scsi
>
In the referenced code for using sysfs, there only appear to be methods
for reading attributes. How about if we want to cause a command to
get written out to the hardware? Do we do something like this?
/* get a semaphore keep everyone else out while we're working,
and hope like hell that all the other processes are playing
nice and using the semaphore too, or else we're hosed. */
get_some_kind_of_semaphore();
fd = open("/sys/blah/blah/attribute1", O_RDWR);
write(fd, SOME_JUNK1, sizeof(SOME_JUNK1));
close(fd);
fd = open("/sys/blah/blah/attribute2", O_RDWR);
write(fd, SOME_JUNK2, sizeof(SOME_JUNK2));
close(fd);
fd = open("/sys/blah/blah/attribute3", O_RDWR);
write(fd, SOME_JUNK3, sizeof(SOME_JUNK3));
close(fd);
fd = open("/sys/blah/blah/attribute4", O_RDWR);
write(fd, SOME_JUNK4, sizeof(SOME_JUNK4));
close(fd);
fd = open("/sys/blah/blah/attribute5", O_RDWR);
write(fd, SOME_JUNK5, sizeof(SOME_JUNK5));
close(fd);
fd = open("/sys/blah/blah/attribute6", O_RDWR);
write(fd, SOME_JUNK6, sizeof(SOME_JUNK6));
close(fd);
fd = open("/sys/blah/blah/attribute7", O_RDWR);
write(fd, SOME_JUNK7, sizeof(SOME_JUNK7));
close(fd);
/* When the attribute write_doorbell is written to, by
convention
of this particular device "/sys/blah/blah", it acts as a
doorbell which causes all the values which were "latched" by
the above writes to be consolidated into one command and
written to the hardware. */
fd = open("/sys/blah/blah/write_doorbell", O_RDWR);
write(fd, "ding dong", 9);
close(fd);
release_some_kind_of_semaphore();
I'm not suggesting that the above is a good idea. I don't have a good
idea about how to do this.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2.6: how do I this in sysfs?
I've been asked to pass this on for some kind of clarification.
We have management apps requiring specific information from the Smart
Array controller. We're trying to use sysfs to accomplish the task. An
example of what we need to do is below. I'm sure some of you will
recognize this as CSMI.
The basic question is this: how do you pass complex data structures back
and forth between user/kernelspace and still abide by the rules around
sysfs like: one attribute per file, text files only, etc?
Thanks,
mikem
>
> We have a storage controller which has some features which
> Work more or less as follows, but are not really "regular i/o"
> In the sense that they are used for configuration or
> management Of devices rather than being the primary purpose
> of the devices.
>
> The host constructs a somewhat complex data buffer according
> to a predefined convention, And fills out certain parts of
> the buffer to formulate what could be a query, or perhaps
> configuration data.
> It then constructs a command which includes scatter gather
> elements Which reference this data buffer, and writes the bus
> address of the Command to a register on the controller.
>
> The controller reads the command and data buffer from host
> memory, And DMAs the results of the query into the same data
> buffer, and issues An interrupt to the host. So there's a
> bidirectional transfer Of data to/from the data buffer.
>
> For example, one the data buffers the controller understands
> looks like what's below:
>
> User applications need to be able to use this interface to
> talk To the controller. What's the recommended way to
> implement such An interface?
>
> // CC_CSMI_SAS_GET_PHY_INFO
> typedef struct _COMMAND_HEADER {
>__u32 IOControllerNumber;
> __u32 Length;
> __u32 ReturnCode;
> __u32 Timeout;
> __u16 Direction;
> } COMMAND_HEADER, *PCOMMAND_HEADER;
>
> typedef struct _CSMI_SAS_IDENTIFY {
>__u8 bDeviceType;
>__u8 bRestricted;
>__u8 bInitiatorPortProtocol;
>__u8 bTargetPortProtocol;
>__u8 bRestricted2[8];
>__u8 bSASAddress[8];
>__u8 bPhyIdentifier;
>__u8 bSignalClass;
>__u8 bReserved[6];
> } CSMI_SAS_IDENTIFY,
> *PCSMI_SAS_IDENTIFY;
>
> typedef struct _CSMI_SAS_PHY_ENTITY {
>CSMI_SAS_IDENTIFY Identify;
>__u8 bPortIdentifier;
>__u8 bNegotiatedLinkRate;
>__u8 bMinimumLinkRate;
>__u8 bMaximumLinkRate;
>__u8 bPhyChangeCount;
>__u8 bAutoDiscover;
>__u8 bReserved[2];
>CSMI_SAS_IDENTIFY Attached;
> } CSMI_SAS_PHY_ENTITY,
> *PCSMI_SAS_PHY_ENTITY;
>
> typedef struct _CSMI_SAS_PHY_INFO {
>__u8 bNumberOfPhys;
>__u8 bReserved[3];
>CSMI_SAS_PHY_ENTITY Phy[32];
> } CSMI_SAS_PHY_INFO,
> *PCSMI_SAS_PHY_INFO;
>
> typedef struct _CSMI_SAS_PHY_INFO_BUFFER {
>COMMAND_HEADER IoctlHeader;
>CSMI_SAS_PHY_INFO Information;
> } CSMI_SAS_PHY_INFO_BUFFER,
> *PCSMI_SAS_PHY_INFO_BUFFER;
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] fix cciss DMA unmap brokenness
Alex wrote: > >The CCISS driver seems to loose track of DMA mappings > created by it's > fill_cmd() routine. Neither callers of this routine are > extracting the DMA address created in order to do the unmap. > Instead, they simply try to unmap 0x0. It's easy to see this > problem on an x86_64 system when using the "swiotlb=force" > boot option. In this case, the driver is leaking resources > of the swiotlb and not causing a sync of the bounce buffer. Thanks > > Signed-off-by: Alex Williamson <[EMAIL PROTECTED]> Acked-by: Mike Miller <[EMAIL PROTECTED]> > > diff -r b9c8e9fdd6b2 drivers/block/cciss.c > --- a/drivers/block/cciss.c Wed Aug 17 04:06:25 2005 > +++ b/drivers/block/cciss.c Wed Aug 17 12:53:40 2005 > @@ -1420,8 +1420,10 @@ > } > } > /* unlock the buffers from DMA */ > + buff_dma_handle.val32.lower = c->SG[0].Addr.lower; > + buff_dma_handle.val32.upper = c->SG[0].Addr.upper; > pci_unmap_single( h->pdev, (dma_addr_t) buff_dma_handle.val, > - size, PCI_DMA_BIDIRECTIONAL); > + c->SG[0].Len, PCI_DMA_BIDIRECTIONAL); > cmd_free(h, c, 0); > return(return_status); > > @@ -1860,8 +1862,10 @@ > > cleanup1: > /* unlock the data buffer from DMA */ > + buff_dma_handle.val32.lower = c->SG[0].Addr.lower; > + buff_dma_handle.val32.upper = c->SG[0].Addr.upper; > pci_unmap_single(info_p->pdev, (dma_addr_t) buff_dma_handle.val, > - size, PCI_DMA_BIDIRECTIONAL); > + c->SG[0].Len, PCI_DMA_BIDIRECTIONAL); > cmd_free(info_p, c, 1); > return (status); > } > > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC 1 of 9] patches to add diskdump functionality to block layer
> From: Christoph Hellwig [mailto:[EMAIL PROTECTED] > > This looks like a patch for Linux 2.4. Such major changes for the > 2.4 tree don't make sense anymore, especially for > functionality not even in Linux 2.6. > This is for 2.4, I should have specified that in the Subject line. We did this work because of customer demand and a request from a vendor. Marcelo, is this something that you be interested in adding to 2.4? If not, I'll just submit this directly to the vendor. Thanks, mikem > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
FW: [patch 1/1] block/cciss: replace schedule_timeout() with msleep()
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Saturday, March 05, 2005 4:45 PM
> To: Miller, Mike (OS Dev)
> Cc: ISS StorageDev; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: [patch 1/1] block/cciss: replace schedule_timeout()
> with msleep()
>
>
>
>
> I used msleep(10) here under the presumption that the
> schedule_timeout(1) was written assuming that HZ=100 (as it
> used to be), which is equivalent to 10 milliseconds. If the
> desire is actually for 1 ms or the minimal sleep interval,
> then the patch can be changed appropriately. A similar
> assumption as to the constant delay value was made in the
> other replacement, which can also be appropriately adjusted.
>
> Change the delay logic in pollcomplete() to use msleep() and
> time_before(). Instead of assuming schedule_timeout() will
> sleep exactly as requested, use msleep(10) to guarantee
> minimally 10 millisecond increments and
> time_before() to guarantee stopping the loop as close to 20
> seconds as possible.
> Also changes another occurrence of schedule_timeout() to msleep().
> TASK_INTERRUPTIBLE is used in this case, but signals are not handled.
>
> Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>
> Acked-by: Mike Miller <[EMAIL PROTECTED]>
> Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
Please consider the following patch for inclusion.
Thanks,
mikem
---
kj-domen/drivers/block/cciss.c | 17 +++--
1 files changed, 7 insertions(+), 10 deletions(-)
diff -puN drivers/block/cciss.c~msleep-drivers_block_cciss
drivers/block/cciss.c
--- kj/drivers/block/cciss.c~msleep-drivers_block_cciss
2005-03-05 16:10:44.0 +0100
+++ kj-domen/drivers/block/cciss.c 2005-03-05
16:10:44.0 +0100
@@ -1702,17 +1702,15 @@ static int cciss_revalidate(struct
gendi static unsigned long pollcomplete(int ctlr) {
unsigned long done;
- int i;
+ unsigned long end_jiffies = jiffies + 20 * HZ;
/* Wait (up to 20 seconds) for a command to complete */
-
- for (i = 20 * HZ; i > 0; i--) {
+ while (time_before(jiffies,end_jiffies)) {
done = hba[ctlr]->access.command_completed(hba[ctlr]);
- if (done == FIFO_EMPTY) {
- set_current_state(TASK_UNINTERRUPTIBLE);
- schedule_timeout(1);
- } else
- return (done);
+ if (done == FIFO_EMPTY)
+ msleep(10);
+ else
+ return done;
}
/* Invalid address to tell caller we ran out of time */
return 1;
@@ -2486,8 +2484,7 @@ static int cciss_pci_init(ctlr_info_t *c
if (!(readl(c->vaddr + SA5_DOORBELL) &
CFGTBL_ChangeReq))
break;
/* delay and try again */
- set_current_state(TASK_INTERRUPTIBLE);
- schedule_timeout(10);
+ msleep(100);
}
#ifdef CCISS_DEBUG
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
CSMI questions
Sorry, my last mail went unintentionally. mikem - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: cciss CSMI via sysfs for 2.6
> -Original Message-
> From: Toon van der Pas [mailto:[EMAIL PROTECTED]
> > +
> > + iocommand.IoctlHeader.Length = sizeof(CSMI_SAS_PHY_INFO_BUFFER);
> > + c->cmd_type = CMD_IOCTL_PEND;
> > + c->Header.ReplyQueue = 0;
> > +
> > + //Do we send the whole buffer?
> > + if (iocommand.IoctlHeader.Length > 0){
>
> This test will always be true, no?
Yes, I'll fix that.
Thanks,
mikem
>
> > + c->Header.SGList = 1;
> > + c->Header.SGTotal = 1;
> > + } else {
> > + c->Header.SGList = 0;
> > + c->Header.SGTotal = 0;
> > + }
>
> --
> "Debugging is twice as hard as writing the code in the first place.
> Therefore, if you write the code as cleverly as possible, you are,
> by definition, not smart enough to debug it." - Brian W. Kernighan
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] Convert cciss to compat_ioctl
> -Original Message-
> Convert the cciss driver to compat_ioctl. This cleans up a lot
> of code.
>
> I don't have such hardware thus this is only compile tested.
>
> This requires the block device compat_ioctl patch I sent earlier.
Sorry I took so long to reply to this. I finally had a chance to test the
change and it looks OK.
mikem
>
> Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
>
> diff -u linux-2.6.11-rc1-bk4/drivers/block/cciss.c-o
> linux-2.6.11-rc1-bk4/drivers/block/cciss.c
> --- linux-2.6.11-rc1-bk4/drivers/block/cciss.c-o
> 2005-01-14 10:12:17.0 +0100
> +++ linux-2.6.11-rc1-bk4/drivers/block/cciss.c
> 2005-01-18 06:30:43.0 +0100
> @@ -146,11 +146,18 @@
> static void cciss_procinit(int i) {}
> #endif /* CONFIG_PROC_FS */
>
> +#ifdef CONFIG_COMPAT
> +static int cciss_compat_ioctl(struct file *f, unsigned cmd,
> unsigned long arg);
> +#endif
> +
> static struct block_device_operations cciss_fops = {
> .owner = THIS_MODULE,
> .open = cciss_open,
> .release= cciss_release,
> .ioctl = cciss_ioctl,
> +#ifdef CONFIG_COMPAT
> + .compat_ioctl = cciss_compat_ioctl,
> +#endif
> .revalidate_disk= cciss_revalidate,
> };
>
> @@ -477,80 +484,50 @@
> }
>
> #ifdef CONFIG_COMPAT
> -/* for AMD 64 bit kernel compatibility with 32-bit userland ioctls */
> -extern long sys_ioctl(unsigned int fd, unsigned int cmd,
> unsigned long arg);
> -extern int
> -register_ioctl32_conversion(unsigned int cmd, int
> (*handler)(unsigned int,
> - unsigned int, unsigned long, struct file *));
> -extern int unregister_ioctl32_conversion(unsigned int cmd);
> -
> -static int cciss_ioctl32_passthru(unsigned int fd, unsigned
> cmd, unsigned long arg, struct file *file);
> -static int cciss_ioctl32_big_passthru(unsigned int fd,
> unsigned cmd, unsigned long arg,
> - struct file *file);
> -
> -typedef int (*handler_type) (unsigned int, unsigned int,
> unsigned long, struct file *);
> -
> -static struct ioctl32_map {
> - unsigned int cmd;
> - handler_type handler;
> - int registered;
> -} cciss_ioctl32_map[] = {
> - { CCISS_GETPCIINFO, (handler_type) sys_ioctl, 0 },
> - { CCISS_GETINTINFO, (handler_type) sys_ioctl, 0 },
> - { CCISS_SETINTINFO, (handler_type) sys_ioctl, 0 },
> - { CCISS_GETNODENAME,(handler_type) sys_ioctl, 0 },
> - { CCISS_SETNODENAME,(handler_type) sys_ioctl, 0 },
> - { CCISS_GETHEARTBEAT, (handler_type) sys_ioctl, 0 },
> - { CCISS_GETBUSTYPES,(handler_type) sys_ioctl, 0 },
> - { CCISS_GETFIRMVER, (handler_type) sys_ioctl, 0 },
> - { CCISS_GETDRIVVER, (handler_type) sys_ioctl, 0 },
> - { CCISS_REVALIDVOLS,(handler_type) sys_ioctl, 0 },
> - { CCISS_PASSTHRU32, cciss_ioctl32_passthru, 0 },
> - { CCISS_DEREGDISK, (handler_type) sys_ioctl, 0 },
> - { CCISS_REGNEWDISK, (handler_type) sys_ioctl, 0 },
> - { CCISS_REGNEWD,(handler_type) sys_ioctl, 0 },
> - { CCISS_RESCANDISK, (handler_type) sys_ioctl, 0 },
> - { CCISS_GETLUNINFO, (handler_type) sys_ioctl, 0 },
> - { CCISS_BIG_PASSTHRU32, cciss_ioctl32_big_passthru, 0 },
> -};
> -#define NCCISS_IOCTL32_ENTRIES (sizeof(cciss_ioctl32_map) /
> sizeof(cciss_ioctl32_map[0]))
> -static void register_cciss_ioctl32(void)
> -{
> - int i, rc;
>
> - for (i=0; i < NCCISS_IOCTL32_ENTRIES; i++) {
> - rc = register_ioctl32_conversion(
> - cciss_ioctl32_map[i].cmd,
> - cciss_ioctl32_map[i].handler);
> - if (rc != 0) {
> - printk(KERN_WARNING "cciss: failed to register "
> - "32 bit compatible ioctl 0x%08x\n",
> - cciss_ioctl32_map[i].cmd);
> - cciss_ioctl32_map[i].registered = 0;
> - } else
> - cciss_ioctl32_map[i].registered = 1;
> - }
> -}
> -static void unregister_cciss_ioctl32(void)
> +static int do_ioctl(struct file *f, unsigned cmd, unsigned long arg)
> {
> - int i, rc;
> + int ret;
> + lock_kernel();
> + ret = cciss_ioctl(f->f_dentry->d_inode, f, cmd, arg);
> + unlock_kernel();
> + return ret;
> +}
>
> - for (i=0; i < NCCISS_IOCTL32_ENTRIES; i++) {
> - if (!cciss_ioctl32_map[i].registered)
> - continue;
> - rc = unregister_ioctl32_conversion(
> - cciss_ioctl32_map[i].cmd);
> - if (rc == 0) {
> - cciss_ioctl32_map[i].registered = 0;
> - continue;
> - }
> - printk(KERN_WARNING "cciss: failed to unregister "
> - "32 bit compatible ioctl 0x%08x\n",
> - cciss_ioctl32_map[i].cmd);
> +static int cciss_ioctl32_passthru(struct file *f, unsigned
> cmd, unsigned long arg);
> +static int cciss_
RE: [2.6 patch] drivers/block/cpqarray.c: small cleanups
> -Original Message-
> This patch contains the following cleanups:
> - make cpqarray_pci_device_id static
> - merge cpqarray_init_step2 into cpqarray_init and make it static
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Acked-by: Mike Miller <[EMAIL PROTECTED]>
>
> ---
>
> drivers/block/cpqarray.c | 13 ++---
> 1 files changed, 2 insertions(+), 11 deletions(-)
>
> This patch was already sent on:
> - 29 Nov 2004
>
> --- linux-2.6.10-rc1-mm3-full/drivers/block/cpqarray.c.old
> 2004-11-06 19:51:42.0 +0100
> +++ linux-2.6.10-rc1-mm3-full/drivers/block/cpqarray.c
> 2004-11-06 19:53:16.0 +0100
> @@ -97,7 +97,7 @@
> };
>
> /* define the PCI info for the PCI cards this driver can control */
> -const struct pci_device_id cpqarray_pci_device_id[] =
> +static const struct pci_device_id cpqarray_pci_device_id[] =
> {
> { PCI_VENDOR_ID_DEC, PCI_DEVICE_ID_COMPAQ_42XX,
> 0x0E11, 0x4058, 0, 0, 0}, /* SA431 */
> @@ -135,7 +135,6 @@
> /* Debug Extra Paranoid... */
> #define DBGPX(s) do { } while(0)
>
> -int cpqarray_init_step2(void);
> static int cpqarray_pci_init(ctlr_info_t *c, struct pci_dev *pdev);
> static void __iomem *remap_pci_mem(ulong base, ulong size);
> static int cpqarray_eisa_detect(void);
> @@ -312,14 +311,6 @@
>
> module_param_array(eisa, int, NULL, 0);
>
> -/* This is a bit of a hack,
> - * necessary to support both eisa and pci
> - */
> -int __init cpqarray_init(void)
> -{
> - return (cpqarray_init_step2());
> -}
> -
> static void release_io_mem(ctlr_info_t *c)
> {
> /* if IO mem was not protected do nothing */
> @@ -560,7 +551,7 @@
> * This is it. Find all the controllers and register them.
> * returns the number of block devices registered.
> */
> -int __init cpqarray_init_step2(void)
> +static int __init cpqarray_init(void)
> {
> int num_cntlrs_reg = 0;
> int i;
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
