Bug 13119 - RFE: support for i2o DPT SmartRaid Gen V/VI
RFE: support for i2o DPT SmartRaid Gen V/VI
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Alan Cox
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-06-27 12:27 EDT by giulioo
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-12-11 11:30:10 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description giulioo 2000-06-27 12:27:02 EDT
Is there any plan to include support for DPT PM1554U2/PM1564U3 i2o 
controllers in the next (7.0 ?) RH release?
DPT support told me that it's possible that the next version of SuSE will 
include support for their i2o controllers.

Until now we've used 2.2.14 + dpt driver v.1.10 (available on request, 
they have 1.09 on their site) and it works fine.
The only problem being that their monitoring daemon (online array 
operations)  sometime consumes much cpu power for 1 or 2 seconds when you 
run the "dptutil" command line utility (but you don't have to use it if 
all works ok...). We haven't tested their X dptmanager.

I see that there is the new i2o code in the official 2.2.x kernel (I read 
Alan Cox has tested DPT with it), but that is not enough for the DPT 
controllers and DPT monitoring daemon  to work, at least this is what DPT 
told me, so you would need their driver.

If there are no plans, is this because you would need to use their driver 
and you consider it not reliable or bad designed (it does not use the new 
standard i2o interface), or because RedHat thinks that there is not enough 
demand for DPT controllers support to justify the time needed for 
adding/testing the new driver?

Thanks.
Comment 1 Alan Cox 2000-08-02 14:59:19 EDT
Im currently working with Adaptec (bought DPT) on this and aacraid stuff. The
goal is to clean their
driver up of problem header files (not their fault but i2o sig originated
contamination) and get it into
the mainstream kernel post 2.2.17

I have hardware from them and a driver to start cleanup on but it wont be for
2.2.17 or I suspect
for 7.0
Comment 2 giulioo 2000-08-03 05:27:56 EDT
Thanks for the info.

After I filed this bugzilla RFE, I found out about i2o sig problems in
linux-kernel archives.

I see now that my RFE should be updated since these days Adaptec/DPT is
telling me that PM1564U3 will be out of production soon, and it will be
replaced by Adaptec 2100s, made by DPT with an adaptec chip instead of
qlogic one (buggy). 

"..The Adaptec 2100s and 3100s controllers (one and two channel
respectively), are Ultra160 SCSI RAID Controllers. The controllers
represent the next-generation of the DPT Decade Family of controllers.
They feature Adaptec Silicon and the performance of these controllers
will equal and in many cases exceed that promised by the Q-Logic-based
DPT Decade controllers. ..."

They say the linux drivers will be different.

I hope they gave you these new controllers for testing :-))
Comment 3 Alan Cox 2000-08-03 18:07:11 EDT
Im marking this as DEFER for 7.1 era. Hopefully sorted by then
Comment 4 Alan Cox 2001-12-11 11:30:03 EST
aacraid should be in something post 7.2. In the end I rewrote the aacraid
driver. dpt_i2o is in current 2.4 now so should percolate everywhere fine.

Note You need to log in before you can comment on or make changes to this bug.