Re: IBM-DJNA drives on FreeBSD
It seems Peter Wemm wrote: > > Well, CAM & ATAPI is "fairly" easy, the only problem being all the > > little details that are different enough to make it non-trivial to > > maintain. I once sat down and tried to get all the details on how > > the CCB's where different, and decided that I wouldn't want to engage > > in that. > > Another story is ATA disks, there you either have to teach CAM about > > a new lowlevel protocol, or write a SCSI<>ATA translator, which I > > also decided I didn't want to do... > > Well, that's assuming you use scsi ccb's... you could use atapi ccb's. > We have cam/* which is the generic transport handler. cam/scsi/* which > is the scsi peripheral drivers that use scsi ccbs, and then we could > have cam/ata/* which uses atapi ccb's and ata disk info. Then you have > cam/ata/ata_ad.c, cam/ata/atapi_cd.c etc. Your backend ata controller code > then gets requests sent to it in atapi format and/or something suitable for > ata disks. > > This approach is quite efficient and you get to use the common queueing, error > recovery, etc etc stuff. You don't have to do ccb translation or anything. > You get your own disk, tape, cd etc driver with their own names and major > numbers. They would look *very* similar to the scsi counterparts but would > be seperate as they use different ccbs, different backend-specific hooks, etc. Uhm, yes, agreed, but it defies some of the gains (ie common highlevel drivers) but would probably keep the performance of the current approach. It would make life a wee bit less complicated, but one would still have to do all the lowlevel code to deal with queing etc, but the higherlevel stuff could probably be shared, maybe CAM would have to be modified a bit but it should be possible... > Things like umass, vpo etc have it easy since they basically bulk send the > scsi ccb's to the device as they use the scsi protocol directly. The ATAPI > protocol is similar but would require translation if it used the common top > end drivers. So, it either requires different top end drivers or has to do > translation. So its basically a choice between added complexity or added complexity :) When I get all the lowlevel stuff done (this has to be done no matter what approach is chosen) I'll take a look at it again, but if anybody feels like doing anything about it, let me know, so we can get things coordinated -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IBM-DJNA drives on FreeBSD
Soren Schmidt wrote: > It seems Nick Hibma wrote: > > > > I should have said "known bad configuration". I know Søren's ATA > > > > driver supports UDMA on the Aladdin, but I don't have the luxury of > > > > expendable file systems, so I don't use it. I also think it's the > > > > wrong direction to go off in; if we're going to totally rewrite our > > > > IDE driver, we should do it within the CAM framework. > > > > > > Do I hear a volounteer here ?? > > > What the new ATA/ATAPI driver is all about is mostly a rewrite of all > > > the low level code, and that is still needed if you want to go the CAM w ay. > > > The higher levels of the new ATA driver is simply a port of my allready > > > done ATAPI drivers. > > > There is nothing in the way of screwing a CAM interface ontop of that > > > lowlevel code instead of/in parallel to the current highlvel code > > > > Yes yes yes! CAM on top of ATAPI. If we keep the command > > creation/conversion layer in CAM and make CCB come out at the lower end, > > we could instantly screw it on top of the USB Mass Storage driver (that > > supports SCSI through CAM at the moment). > > > > Well, CAM & ATAPI is "fairly" easy, the only problem being all the > little details that are different enough to make it non-trivial to > maintain. I once sat down and tried to get all the details on how > the CCB's where different, and decided that I wouldn't want to engage > in that. > Another story is ATA disks, there you either have to teach CAM about > a new lowlevel protocol, or write a SCSI<>ATA translator, which I > also decided I didn't want to do... Well, that's assuming you use scsi ccb's... you could use atapi ccb's. We have cam/* which is the generic transport handler. cam/scsi/* which is the scsi peripheral drivers that use scsi ccbs, and then we could have cam/ata/* which uses atapi ccb's and ata disk info. Then you have cam/ata/ata_ad.c, cam/ata/atapi_cd.c etc. Your backend ata controller code then gets requests sent to it in atapi format and/or something suitable for ata disks. This approach is quite efficient and you get to use the common queueing, error recovery, etc etc stuff. You don't have to do ccb translation or anything. You get your own disk, tape, cd etc driver with their own names and major numbers. They would look *very* similar to the scsi counterparts but would be seperate as they use different ccbs, different backend-specific hooks, etc. Things like umass, vpo etc have it easy since they basically bulk send the scsi ccb's to the device as they use the scsi protocol directly. The ATAPI protocol is similar but would require translation if it used the common top end drivers. So, it either requires different top end drivers or has to do translation. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IBM-DJNA drives on FreeBSD
It seems Nick Hibma wrote: > > > I should have said "known bad configuration". I know Søren's ATA > > > driver supports UDMA on the Aladdin, but I don't have the luxury of > > > expendable file systems, so I don't use it. I also think it's the > > > wrong direction to go off in; if we're going to totally rewrite our > > > IDE driver, we should do it within the CAM framework. > > > > Do I hear a volounteer here ?? > > What the new ATA/ATAPI driver is all about is mostly a rewrite of all > > the low level code, and that is still needed if you want to go the CAM way. > > The higher levels of the new ATA driver is simply a port of my allready > > done ATAPI drivers. > > There is nothing in the way of screwing a CAM interface ontop of that > > lowlevel code instead of/in parallel to the current highlvel code > > Yes yes yes! CAM on top of ATAPI. If we keep the command > creation/conversion layer in CAM and make CCB come out at the lower end, > we could instantly screw it on top of the USB Mass Storage driver (that > supports SCSI through CAM at the moment). > Well, CAM & ATAPI is "fairly" easy, the only problem being all the little details that are different enough to make it non-trivial to maintain. I once sat down and tried to get all the details on how the CCB's where different, and decided that I wouldn't want to engage in that. Another story is ATA disks, there you either have to teach CAM about a new lowlevel protocol, or write a SCSI<>ATA translator, which I also decided I didn't want to do... Having CAM & ATAPI without the ATA part is real clumsy if you ask me, so There are also subtle differences in the way errors & timeouts, not to speak about tagged cmds are handlede by the HW, that probably requieres changes to the way CAM works, or non-trivial translation mechanisems, but I havn't looked too deeply into that (yet).. Besides I can live without the CAM overhead (both speed and size wise). That all boils down to that if somebody is willing to do the job, I'm sure we can integrate it into the ATA driver so that both worlds can be made happy, I just dont have the motivation to do it... > On a related edge: > > Would it make sense to create a UFI command layer (USB floppies use it, > don't know what else) on top of CAM? Or am fundamentally wrong in > assuming that one can stack any command layer on top of CAM and abuse > it as a layer that provides common services, command queueing, error > handling? > > It would like this: > > SCSI UFI_da ATAPI > \| / >CAM layer > | > USB Mass Storage Driver >/ | \ > Bulk CB CBI You better ask Justin that... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IBM-DJNA drives on FreeBSD
> > I should have said "known bad configuration". I know Søren's ATA > > driver supports UDMA on the Aladdin, but I don't have the luxury of > > expendable file systems, so I don't use it. I also think it's the > > wrong direction to go off in; if we're going to totally rewrite our > > IDE driver, we should do it within the CAM framework. > > Do I hear a volounteer here ?? > What the new ATA/ATAPI driver is all about is mostly a rewrite of all > the low level code, and that is still needed if you want to go the CAM way. > The higher levels of the new ATA driver is simply a port of my allready > done ATAPI drivers. > There is nothing in the way of screwing a CAM interface ontop of that > lowlevel code instead of/in parallel to the current highlvel code Yes yes yes! CAM on top of ATAPI. If we keep the command creation/conversion layer in CAM and make CCB come out at the lower end, we could instantly screw it on top of the USB Mass Storage driver (that supports SCSI through CAM at the moment). On a related edge: Would it make sense to create a UFI command layer (USB floppies use it, don't know what else) on top of CAM? Or am fundamentally wrong in assuming that one can stack any command layer on top of CAM and abuse it as a layer that provides common services, command queueing, error handling? It would like this: SCSI UFI_da ATAPI \| / CAM layer | USB Mass Storage Driver / | \ Bulk CB CBI Cheers, Nick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IBM-DJNA drives on FreeBSD
It seems Dag-Erling Smorgrav wrote: > "Brian F. Feldman" <[EMAIL PROTECTED]> writes: > > On 4 Jul 1999, Dag-Erling Smorgrav wrote: > > > Depends on your motherboard. Try to just disable UDMA66 first. If that > > > doesn't help, or if you have a "known bad" chipset (e.g. AcerLabs > > > Aladdin), disable UDMA completely in the BIOS setup utility. > > What do you mean, "known bad" ALi? > > I should have said "known bad configuration". I know Søren's ATA > driver supports UDMA on the Aladdin, but I don't have the luxury of > expendable file systems, so I don't use it. I also think it's the > wrong direction to go off in; if we're going to totally rewrite our > IDE driver, we should do it within the CAM framework. Do I hear a volounteer here ?? What the new ATA/ATAPI driver is all about is mostly a rewrite of all the low level code, and that is still needed if you want to go the CAM way. The higher levels of the new ATA driver is simply a port of my allready done ATAPI drivers. There is nothing in the way of screwing a CAM interface ontop of that lowlevel code instead of/in parallel to the current highlvel code Oh and besides that I still have to loose a filesystem to the ATA driver :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IBM-DJNA drives on FreeBSD
"Brian F. Feldman" <[EMAIL PROTECTED]> writes: > On 4 Jul 1999, Dag-Erling Smorgrav wrote: > > Depends on your motherboard. Try to just disable UDMA66 first. If that > > doesn't help, or if you have a "known bad" chipset (e.g. AcerLabs > > Aladdin), disable UDMA completely in the BIOS setup utility. > What do you mean, "known bad" ALi? I should have said "known bad configuration". I know Søren's ATA driver supports UDMA on the Aladdin, but I don't have the luxury of expendable file systems, so I don't use it. I also think it's the wrong direction to go off in; if we're going to totally rewrite our IDE driver, we should do it within the CAM framework. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IBM-DJNA drives on FreeBSD
> Depends on your motherboard. Try to just disable UDMA66 first. Thanks, that's what I did. It works fine (I'm using a SOYO 5EHM motherboard with an AMD K6-2/200). Performance is excellent; bonnie gives: ---Sequential Output ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU svax32if 100 10336 95.5 14246 57.3 5733 35.9 11372 95.4 17128 57.0 147.9 3.3 that's 17MB/s for block reads (this varies quite a bit depending on the physical position on the disk). Not bad for a disk costing £165 for 13.5GB. On the other hand the system really grinds to a halt while the benchmark is running. Incidentally, I tried bonnie on an MSDOS partition (just because it's at the outside of the disk) and the result was: svax32im 100 8940 89.2 12984 76.1 473 2.8 9108 92.1 15584 86.4 76.3 48.8 Note the abysmal rewrite speed! -- Richard To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IBM-DJNA drives on FreeBSD
On 4 Jul 1999, Dag-Erling Smorgrav wrote: > Richard Tobin <[EMAIL PROTECTED]> writes: > > Is that relevant for 3.2 as well as current? And by "disabling ultra > > DMA" did you mean "disabling UDMA66" or "disabling UDMA completely"? > > (You can permanently disable UDMA66 with a DOS utility available > > from IBM, and it will then act as a plain UDMA33 drive.) > > Depends on your motherboard. Try to just disable UDMA66 first. If that > doesn't help, or if you have a "known bad" chipset (e.g. AcerLabs > Aladdin), disable UDMA completely in the BIOS setup utility. What do you mean, "known bad" ALi? I've had this mobo since the beginning of the year or so, and it's given me no trouble. Ultra DMA always worked right with Soren's ATA drivers. The only problem is that UDMA can't be disabled in the BIOS, but that's due more to the BIOS brand. > > DES > -- > Dag-Erling Smorgrav - [EMAIL PROTECTED] > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IBM-DJNA drives on FreeBSD
It seems Dag-Erling Smorgrav wrote: > Richard Tobin <[EMAIL PROTECTED]> writes: > > Is that relevant for 3.2 as well as current? And by "disabling ultra > > DMA" did you mean "disabling UDMA66" or "disabling UDMA completely"? > > (You can permanently disable UDMA66 with a DOS utility available > > from IBM, and it will then act as a plain UDMA33 drive.) > > Depends on your motherboard. Try to just disable UDMA66 first. If that > doesn't help, or if you have a "known bad" chipset (e.g. AcerLabs > Aladdin), disable UDMA completely in the BIOS setup utility. BZZST! The Aladdin isn't bad, the support in the old wd based driver is :) I use a DJNA drive on an Aladdin board, with the ATA driver, and it works just dandy no matter how I set the BIOS (and I always get UDMA33 btw, the Alladin wont do any higher than that)... -SØren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IBM-DJNA drives on FreeBSD
Richard Tobin <[EMAIL PROTECTED]> writes: > Is that relevant for 3.2 as well as current? And by "disabling ultra > DMA" did you mean "disabling UDMA66" or "disabling UDMA completely"? > (You can permanently disable UDMA66 with a DOS utility available > from IBM, and it will then act as a plain UDMA33 drive.) Depends on your motherboard. Try to just disable UDMA66 first. If that doesn't help, or if you have a "known bad" chipset (e.g. AcerLabs Aladdin), disable UDMA completely in the BIOS setup utility. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
IBM-DJNA drives on FreeBSD
I'm about to install FreeBSD 3.2 on a machine with an IBM-DJNA-371350 (Deskstar 22GXP 13.5GB) drive. I see that on the -current mailing list a few weeks ago you (phk) said: >Try disabling "ultra DMA" in the BIOS, that seems to have worked for >me on my IBM-DJNA-371800 drive. Is that relevant for 3.2 as well as current? And by "disabling ultra DMA" did you mean "disabling UDMA66" or "disabling UDMA completely"? (You can permanently disable UDMA66 with a DOS utility available from IBM, and it will then act as a plain UDMA33 drive.) Thanks, -- Richard To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
