RE: what to do with dpt_i2o

RE: what to do with dpt_i2o

[Salyzyn, Mark]

I have not been submitting an updated patch for the dpt_i2o driver
because of a handful of customers experiencing problems with >4G of
memory in certain systems (all Zero Channel RAID). I am still
investigating.

The hot-changing of devices is still using a controversial interface
(busy checks wrapped around calls to driver writes to /proc/scsi/scsi in
2.4, and the drv->rescan() or scsi_rescan_device in 2.6) and there is
resistance to the LLD/car Firmware knowing more about device status.

Sincerely -- Mark Salyzyn

-----Original Message-----
From: Markus Lidel [mailto:Markus.Lidel@shadowconnect.com] 
Sent: Monday, October 11, 2004 4:30 AM
To: Christoph Hellwig
Cc: Salyzyn, Mark; linux-scsi@vger.kernel.org
Subject: Re: what to do with dpt_i2o

Hello,

Christoph Hellwig wrote:
>>Marcus, you'd been doing a lot of testing with the DPT/Adaptec cards
for
>>the new i2o layer, right?  IIRC we now have both support for the
Adaptec
>>managment utils and the optimizes sglist format, so there's probably
no
>>reason anymore to keep dpt_i2o.

Maybe i should list some remaining issues:

- 64 bit Scatter Gather elements
- supports hot-changing of devices, and array changes without a reboot.

The second one is implemented, but didn't work on my system. I didn't 
have the time to verify if the dpt_i2o driver recognize it if a drive
fails.


Best regards,


Markus Lidel
------------------------------------------
Markus Lidel (Senior IT Consultant)

Shadow Connect GmbH
Carl-Reisch-Weg 12
D-86381 Krumbach
Germany

Phone:  +49 82 82/99 51-0
Fax:    +49 82 82/99 51-11

E-Mail: Markus.Lidel@shadowconnect.com
URL:    http://www.shadowconnect.com

Re: what to do with dpt_i2o

[Markus Lidel]

Hello,

Christoph Hellwig wrote:
>>Marcus, you'd been doing a lot of testing with the DPT/Adaptec cards for
>>the new i2o layer, right?  IIRC we now have both support for the Adaptec
>>managment utils and the optimizes sglist format, so there's probably no
>>reason anymore to keep dpt_i2o.

Maybe i should list some remaining issues:

- 64 bit Scatter Gather elements
- supports hot-changing of devices, and array changes without a reboot.

The second one is implemented, but didn't work on my system. I didn't 
have the time to verify if the dpt_i2o driver recognize it if a drive fails.


Best regards,


Markus Lidel
------------------------------------------
Markus Lidel (Senior IT Consultant)

Shadow Connect GmbH
Carl-Reisch-Weg 12
D-86381 Krumbach
Germany

Phone:  +49 82 82/99 51-0
Fax:    +49 82 82/99 51-11

E-Mail: Markus.Lidel@shadowconnect.com
URL:    http://www.shadowconnect.com

Re: what to do with dpt_i2o

[Christoph Hellwig]

On Sat, Sep 25, 2004 at 03:46:22PM +0200, Christoph Hellwig wrote:
> Marcus, you'd been doing a lot of testing with the DPT/Adaptec cards for
> the new i2o layer, right?  IIRC we now have both support for the Adaptec
> managment utils and the optimizes sglist format, so there's probably no
> reason anymore to keep dpt_i2o.
> 
> If OTOH we want to keep it it would be nice of Mark could finally send
> the last round of patches we had agreed on..

ping..

what to do with dpt_i2o

[Christoph Hellwig]

Marcus, you'd been doing a lot of testing with the DPT/Adaptec cards for
the new i2o layer, right?  IIRC we now have both support for the Adaptec
managment utils and the optimizes sglist format, so there's probably no
reason anymore to keep dpt_i2o.

If OTOH we want to keep it it would be nice of Mark could finally send
the last round of patches we had agreed on..