On Sat, 16 Sep 2000, Bryan Whitehead wrote:
>> The driver should be on DPT's site. Im not sure on the current state with the
(The driver _IS_ on DPT's site. It always has been.)
>The driver directory is on thier web site. true. But it only works for
>specific versions of kernel's from RH. They do have the sources available
This is true of _any_ binary module. That's why I never use binary modules.
>also. The problem comes when compiling. They specifically say not to use
>Linux's i2o stuff. Fine. They claim they have their "own" i2o
>implementaion. But it won't build, actually it won;t link. After looking
>at the FAQ more they say I need to build with gcc version 2.7.2. Becasue
>their driver only works with that. So i remove the gcc from my system and
>install an old gcc / linker. no change. Still the same damn error.
Have you bothered tell us what that error is? I've not seen anything on
dpt's mail-list. (Which is where this should be discussed.)
>not like I'm some stupid moron (i wish that were the case then I'd be able
...
>development for Mission and Control for NASA's Deep Space network. So i'm
(you aren't inspiring any confidence here...)
>I need to have at LEAST 2.2.16 for security resons. But they don't give a
>crap.
Yes they do. You just are talking to the right people. (Maybe those "right
people" aren't there anymore. DPT is now an Adaptec company, remember.)
>If Linux can get the card working with they native i2o drivers then
>great.
One of the primary reasons for use the DPT driver is to use the DPT RAID
mananger. The Linux I2O code doesn't (currently) have that support. It
could be added later, but someone's got to get the card to work with the
existing I2O code. (And I'll add the standard warning about SCSI card
HW RAID solutions... all of them require mucking about with the SCSI core
to prevent command timeouts. In the case of the DPT card, it can take over
2 MINUTES to signal command completion -- my card will queue 210 commands
in an instant.)
>I'm to the point I don't mind blowing another $10,000 in taxpayers money
>to get the fsck'n RAID working in 2.2.17 land and hopefully 2.4 soon.
Point of fact: There _are_ people using >2.2.12 with the DPT driver.
Point of fact: There _are_ people usin 2.4 with the DPT driver.
I'm the one who made it work at 2.3.33... I sent those changes to DPT and
mailed several lists.
(http://chickenboo.bluetopia.net/~jfbeam/DPT/)
[jfbeam:pts/0]chickenboo:~/[2:05pm]:uname -a
Linux chickenboo 2.4.0-test5-SMP #13 SMP Thu Aug 24 16:23:36 EDT 2000 i686 unknown
[jfbeam:pts/0]chickenboo:~/[2:05pm]:gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
[jfbeam:pts/0]chickenboo:~/[2:10pm]:cat /proc/scsi/dpt_i2o/0
Vendor: DPT Model: PM1554U2 Rev: 3013, scsi 0:
DPT I2O Driver Version: 1.09.1-cramer/1.2:
cmd_per_lun = 210, max_id = 15, max_lun = 7, max_channel = 1
sg_tablesize = 39, irq = 16, OutstandingMsgs = 0
maxfromiopmsgs = 64, maxtoiopmsgs = 210
Devices:
Channel = 0, Target = 0, Lun = 0
Channel = 1, Target = 4, Lun = 0
[jfbeam:pts/0]chickenboo:~/[2:11pm]:cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: DPT Model: CHICKENBOO Rev: 3013
Type: Direct-Access ANSI SCSI revision: 02
Host: scsi0 Channel: 01 Id: 04 Lun: 00
Vendor: SONY Model: SDT-10000 Rev: 0101
Type: Sequential-Access ANSI SCSI revision: 02
It's currently booting from that controller. The driver also works as a
module.
>All I gatta say is thier driver is a piece of crap. I'll use Linux's i2o
Yes, it's hideous... it was originally a SCO driver. But it works.
>If you would like me to try *ANYTHING* out to aid in getting the Card
>working I'm all yours. I'm a bit burned out but hell, If you think it's
>not that far away. Then who am i to argue?
For starters, you can tell us exactly what the hell your problem is. Blow
off all the steam you want, but no one can help you until you tell us your
specific problem.
--Ricky
PS: I've had my difficulties with Mylex as well -- as if replacing the RTC
battery is going to fix a parity calculation fault in the firmware.
They knew damn well that battery had nothing to do with that card
crashing.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 21:00:13 EST