headers
Leon Toh | 1 Feb 2004 10:24

latest 2.6 patch for dpt_i20 driver

Hi Karen,

Here is the latest Adaptec I2O driver. Let me know your results.

Best Regards,
Leon

>Hi,
>
>I have access to several Adaptec I2O RAID controllers and am interested in
>running linux-2.6.x kernels in this lab for testing purposes. Will someone
>please advise me on where to find the most up to date patch(es) for this
>driver. Thanks in advance.
>
>Karen
>--
>  Karen Shaeffer
>  Neuralscape, Palo Alto, Ca. 94306
>  shaeffer <at> neuralscape.com  http://www.neuralscape.com
Attachment (dpt_i2o-2.5.0-2317.tgz): application/x-compressed, 55 KiB
Permalink | Reply | 2 comments |
headers
Christoph Hellwig | 1 Feb 2004 12:17
Favicon

Re: [PATCH, 2.6] tmscsim - no internal command-queuing

On Sat, Jan 31, 2004 at 12:23:48AM +0100, Guennadi Liakhovetski wrote:
> Hi
> 
> The attached patch removes the internal command-queuing in tmscsim. The
> driver still works:-) Don't know though if this is quite correct. Please,
> comment. Goes on the top of my yesterday's patch.

Patch looks mostly good for me.  But there's some fishyness in queuecommand,
mostly from before you patch:

 - many failure cases return one with the new EH code although we wouldn't
   want to requeue the midlayer in that case.  I removed the ifdef and added
   a failed goto to handle them.
 - we need to set cmd->result onlyh if we have an error instead of always
   an overriding it - else it will leak to the midlayer in the return 1
   case.
 - the check for ids out of range are superflous (this was one of the errors
   above, I decided to remove it instead of fixing it).
 - you don't do DC390_UNLOCK_ACB when failing.  While it's a noop I think
   it's bad to have locking macros in place and don't balance them.  You
   should probably remove it completly in one of the next patches.
 - the pDCB->pWaitingSRB looks a bit strange.  By unifying the the codepathes
   it becomes much more readable.

While I'm looking at queuecommand here's some suggestions for future driver
revisions:

 - dc390_initDCB should move to the slave_alloc callback - you get that once
   allocate scsi device, which is much cleaner.  Then you can store it
   in sdev->hostdata and easily retrieve it in ->queuecommand instead of the
(Continue reading)

Permalink | Reply | 4 comments |
headers
James Bottomley | 1 Feb 2004 16:25
Favicon

RE: Recovered disk error caused disk to go offline.

On Fri, 2004-01-30 at 14:02, Guy wrote:
> Sorry about the re-post, but no comments after almost 2 days.

Recovered disc error processing has been in the sd driver for nearly two
years now.  What kernel version was this?

James

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 2 comments |
headers
Christoph Hellwig | 1 Feb 2004 16:34
Picon

[PATCH] remove procfs write support from tmscsim

When looking at the driver after reviewing the changes I stubled over
that code.  Almost all of the funcitonality (except DUMP) should go
through the midlayer and will at least cause some confusion if it
doesn't.

Also the implementation isn't exactly nice, like kmalloced scsi commands
and the tytpical 'parsing' macros cut & pasted over all historic scsi
drivers.  I think we're better of removing it completly and maybe readd
dump as a sysfs attribute if needed.

500 lines of code gone.

--- 1.25/drivers/scsi/tmscsim.c	Fri Dec 19 16:53:43 2003
+++ edited/drivers/scsi/tmscsim.c	Sat Jan 31 06:41:21 2004
 <at>  <at>  -1871,25 +1871,6  <at>  <at> 
 	pDCB->CtrlR1 |= PARITY_ERR_REPO;
 }  

-
-/***********************************************************************
- * Function : static void dc390_updateDCBs ()
- *
- * Purpose :  Set the configuration dependent DCB params for all DCBs
- ***********************************************************************/
-
-static void dc390_updateDCBs (PACB pACB)
-{
-  int i;
-  PDCB pDCB = pACB->pLinkDCB;
-  for (i = 0; i < pACB->DCBCnt; i++)
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Bottomley | 1 Feb 2004 16:41
Favicon

Re: [PATCH, 2.6] tmscsim - no internal command-queuing

On Sun, 2004-02-01 at 06:17, Christoph Hellwig wrote:
> +
> + requeue:
> +    DC390_UNLOCK_ACB;
> +    return 1;

Since this is a host pausing requeue, the return value should be
SCSI_MLQUEUE_HOST_BUSY.

James

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
James Bottomley | 1 Feb 2004 16:46
Favicon

scsi_mid_low_api.txt update to clarify queuecommand return values

The only documentation about the MLQUEUE returns is in the code, it
should also be in here.  I'll add this if no-one objects.

James

===== scsi_mid_low_api.txt 1.15 vs edited =====
--- 1.15/Documentation/scsi/scsi_mid_low_api.txt	Fri Sep 26 20:07:12 2003
+++ edited/scsi_mid_low_api.txt	Sun Feb  1 10:45:23 2004
 <at>  <at>  -1091,14 +1091,44  <at>  <at> 
  *       <at> scp: pointer to scsi command object
  *       <at> done: function pointer to be invoked on completion
  *
- *      Returns 0 on success and 1 if the LLD or the HBA is busy (i.e. run
- *      out of resources to queue further commands). Other types of errors
- *      that are detected immediately are flagged by setting scp->result 
- *      to an appropriate value, invoking the 'done' callback, and then
- *      returning 0 from this function. If the command is not performed
- *      immediately (and the LLD is starting (or will start) the given
- *      command) then this function should place 0 in scp->result and
- *      return 0.
+ *      Returns 0 on success.
+ *
+ *	If there's a failure, return either:
+ *
+ *	SCSI_MLQUEUE_DEVICE_BUSY if the device queue is full, or
+ *	SCSI_MLQUEUE_HOST_BUSY if the entire host queue is full
+ *
+ *	On both of these returns, the mid-layer will requeue the I/O
+ *
+ *	- if the return is SCSI_MLQUEUE_DEVICE_BUSY, only that particular
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christoph Hellwig | 1 Feb 2004 16:48
Picon

[PATCH] missing pci_set_master in megaraid driver

--- 1.59/drivers/scsi/megaraid.c	Fri Jan 23 06:37:03 2004
+++ edited/drivers/scsi/megaraid.c	Sat Jan 31 06:52:56 2004
 <at>  <at>  -4644,6 +4644,7  <at>  <at> 

 	if (pci_enable_device(pdev))
 		goto out;
+	pci_set_master(pdev);

 	pci_bus = pdev->bus->number;
 	pci_dev_func = pdev->devfn;
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
'hch@infradead.org' | 1 Feb 2004 16:49
Favicon

[hch <at> infradead.org: Re: ANNOUNCE: megaraid driver version 2.10.1]

sorry, forgot to Cc the list when replying.

----- Forwarded message from "'hch <at> infradead.org'" <hch <at> infradead.org> -----

Date: Sun, 1 Feb 2004 15:46:11 +0000
From: "'hch <at> infradead.org'" <hch <at> infradead.org>
Subject: Re: ANNOUNCE: megaraid driver version 2.10.1
To: "Mukker, Atul" <Atulm <at> lsil.com>

On Fri, Jan 30, 2004 at 10:03:00AM -0500, Mukker, Atul wrote:
> Hello Christoph,
> 
> I am in process of testing the next version of the megaraid driver. I faced
> an issue while doing the insmod-rmmod sequence. Your patch for PCI hotplug
> does "pci_disable_device" when the driver is unloaded.

Yupp.

> The insmod-rmmod-insmod fails the first time unless you do an explicit
> pci_set_master at driver load time, since pci_enable_device does not seem to
> enable bus mastering, which is disabled by pci_disable_device.

Right, we need the pci_set_master anyway because it's not guaranteed to be
enabled even when loading the first time.  (although it usually is on PC
hardware).  I'll send a patch to jejb to fix it ASAP, but you should add it
to the 2.4 driver aswell.

> Even with pci_set_master, insmod stalls the CPU after about 2-3 hours of
> insmod-rmmod sequence. So I took out the pci_disable_device altogether to
> find out it takes only longer, about 9 hours, but CPU stalls at the exact
(Continue reading)

Permalink | Reply | 3 comments |
headers
Christoph Hellwig | 1 Feb 2004 17:00
Picon

[PATCH] fix wrong argument to pci_dma_sync_sg in megaraid driver

sgl is incremented for each element in the routine, but pci_dma_sync_sg
needs the original buffer.

--- 1.59/drivers/scsi/megaraid.c	Fri Jan 23 06:37:03 2004
+++ edited/drivers/scsi/megaraid.c	Sat Jan 31 07:09:25 2004
 <at>  <at>  -1805,7 +1805,7  <at>  <at> 
 	*len = (u32)cmd->request_bufflen;

 	if( scb->dma_direction == PCI_DMA_TODEVICE ) {
-		pci_dma_sync_sg(adapter->dev, sgl, cmd->use_sg,
+		pci_dma_sync_sg(adapter->dev, cmd->request_buffer, cmd->use_sg,
 				PCI_DMA_TODEVICE);
 	}

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |
headers
Christoph Hellwig | 1 Feb 2004 17:08
Picon

[RFC] killing the AMD53C974 and mac_NCR5380 drivers

Anyone screaming loudly if we remove them?

 - AMD53C974 is broken and doesn't even compile, all supported hardware is
   handled by the mainted tmscsim driver.
 - mac_NCR5380 isn't even referenced in the build and hasn't been at
   least since 2.4

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |

Gmane