From owner-freebsd-scsi Mon Aug 21 06:43:28 1995 Return-Path: freebsd-scsi-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id GAA19968 for freebsd-scsi-outgoing; Mon, 21 Aug 1995 06:43:28 -0700 Received: from hda.com (hda.com [199.232.40.182]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id GAA19958 for ; Mon, 21 Aug 1995 06:43:24 -0700 Received: (from dufault@localhost) by hda.com (8.6.11/8.6.9) id JAA07241; Mon, 21 Aug 1995 09:34:39 -0400 From: Peter Dufault Message-Id: <199508211334.JAA07241@hda.com> Subject: Re: scsiconf change To: joerg_wunsch@uriah.heep.sax.de Date: Mon, 21 Aug 1995 09:34:39 -0400 (EDT) Cc: scsi@freebsd.org In-Reply-To: <199508200511.HAA10037@uriah.heep.sax.de> from "J Wunsch" at Aug 20, 95 07:11:48 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 3346 Sender: freebsd-scsi-owner@freebsd.org Precedence: bulk [I'm widening the audience a bit so we can get some more feedback, Joerg] Joerg asked about how to match a driver when the device lies about what type it is - that is, it says it is type 0 when it is really type X. I wrote: > > I thought you could do this now by matching directly on the inquiry > > data. I know that Julian has a device that reports the wrong device > > type, so I thought we had some way of handling this. > [Joerg] > Perhaps i've overlooked this? No, you haven't overlooked it. Apparently it either never worked the way I thought it did or it was broken at some time. Note that we have a type to use in the "scsidevs" structure (the matching structure), and we carefully take the type out of that structure after a match: > *type_p = bestmatch->type; But this is a NOP since the match fails when the type is different. I think that the current matching tests are wrong; it is too inflexible. I would keep NEW_SCSICONF (since that is all I've been running lately and one of the two branches is getting musty) and change scsi_selectdev to a scoring scheme: high_score = 0; bestmatch = 0; /* XXX: See commentary below about hunting through "knowndevs". */ for ( thisentry = knowndevs; thisentry->manufacturer; thisentry++ ) { int score = 0; /* Choose the best match by a scoring system. One point * for manufacturer and model, one point for revision, * one point for type, and one point for removable. */ if (match(thisentry->manufacturer, manu) && match(thisentry->model, model)) { score++; if (match(thisentry->version, rev)) score++; if (type == thisentry->type) score++; if (remov == thisentry->removable) score++; if (score > high_score) { high_score = score; bestmatch = thisentry; } } } ... Then after you match you copy the new info into the inquiry data, effectively lieing about what you saw, something like: (after return from match...) if (*type_p != bestmatch->type && bestmatch->type != -1) { sc_print_start(sc_link); printf("attaching as type %d", bestmatch->type); sc_print_finish(); *type_p = bestmatch->type; } I'd do the same thing for anything else we match on, so far, for "removable" and "version". If I actually did this, I'd generalize it so that you zapped the stored away inquiry data with the synthetic information in the "bestmatch" structure. Commentary about hunting through "knowndevs": The changes I outline here should give you what you want, and I think would be an improvement. However, instead of a single structure we really should have a distributed structure where in addition to a possible list of "knowndevs" in scsiconf.c we have additional devices in each type driver (st.c, sd.c, etc) and a way to add new ones via config and "boot -c". Then your current problem would be near zero: you'd just config in a new "rogue". Unfortunately I'm no longer running -current: I don't have a system unimportant enough at the moment to do so! If you'd like I'll make these changes, get them to compile and then let you do some testing. These are pretty low risk changes. Peter From owner-freebsd-scsi Mon Aug 21 10:22:28 1995 Return-Path: freebsd-scsi-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id KAA01133 for freebsd-scsi-outgoing; Mon, 21 Aug 1995 10:22:28 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id KAA01111 for ; Mon, 21 Aug 1995 10:22:22 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA03641; Mon, 21 Aug 1995 19:22:16 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id TAA23870; Mon, 21 Aug 1995 19:22:16 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id TAA06324; Mon, 21 Aug 1995 19:04:10 +0200 From: J Wunsch Message-Id: <199508211704.TAA06324@uriah.heep.sax.de> Subject: Re: scsiconf change To: dufault@hda.com (Peter Dufault) Date: Mon, 21 Aug 1995 19:04:09 +0200 (MET DST) Cc: joerg_wunsch@uriah.heep.sax.de, scsi@freebsd.org In-Reply-To: <199508211334.JAA07241@hda.com> from "Peter Dufault" at Aug 21, 95 09:34:39 am Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 2392 Sender: freebsd-scsi-owner@freebsd.org Precedence: bulk As Peter Dufault wrote: > > [I'm widening the audience a bit so we can get some more feedback, Joerg] (I've just subscribed to the scsi list, too. Should get mails from there within a few hours.) > [Joerg] > > Perhaps i've overlooked this? > > No, you haven't overlooked it. Apparently it either never worked the > way I thought it did or it was broken at some time. Note that we have > a type to use in the "scsidevs" structure (the matching structure), > and we carefully take the type out of that structure after a match: > > > *type_p = bestmatch->type; > > But this is a NOP since the match fails when the type is different. Yup. > I think that the current matching tests are wrong; it is too inflexible. Ideally, i would like that disk od0 at scbus0 target 3 would force the device on scbus0 target3 to go to the `od' driver. I'm not sure if this might be a good idea, since some bozo could attach a tape drive to target 3, and the `od' driver would horribly fail. > I would keep NEW_SCSICONF (since that is all I've been running lately > and one of the two branches is getting musty) > and change scsi_selectdev to a scoring scheme: Guess i like it. > Commentary about hunting through "knowndevs": > > The changes I outline here should give you what you want, and I > think would be an improvement. However, instead of a single > structure we really should have a distributed structure where in > addition to a possible list of "knowndevs" in scsiconf.c we have > additional devices in each type driver (st.c, sd.c, etc) and a way > to add new ones via config and "boot -c". Then your current problem > would be near zero: you'd just config in a new "rogue". Hmmmmm. Interesting. It would require extending config(8) and UserConfig. I don't see problems for the former, but maybe the latter will become too much bloated then? Remember, kernel pages are not pageable, and UserConfig is totally useless wasted memory once the kernel is running. > Unfortunately I'm no longer running -current: I don't have a system > unimportant enough at the moment to do so! If you'd like I'll make these > changes, get them to compile and then let you do some testing. These > are pretty low risk changes. I can do it. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Mon Aug 21 11:05:35 1995 Return-Path: freebsd-scsi-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id LAA03402 for freebsd-scsi-outgoing; Mon, 21 Aug 1995 11:05:35 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id LAA03395 for ; Mon, 21 Aug 1995 11:05:33 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.11/8.6.9) id LAA24139; Mon, 21 Aug 1995 11:02:53 -0700 From: Julian Elischer Message-Id: <199508211802.LAA24139@ref.tfs.com> Subject: Re: scsiconf change To: joerg_wunsch@uriah.heep.sax.de Date: Mon, 21 Aug 1995 11:02:52 -0700 (PDT) Cc: dufault@hda.com, scsi@freebsd.org In-Reply-To: <199508211704.TAA06324@uriah.heep.sax.de> from "J Wunsch" at Aug 21, 95 07:04:09 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 3567 Sender: freebsd-scsi-owner@freebsd.org Precedence: bulk > > As Peter Dufault wrote: > > > > [I'm widening the audience a bit so we can get some more feedback, Joerg] > > (I've just subscribed to the scsi list, too. Should get mails from > there within a few hours.) it's been very quiet.. you haven't missed much.. > > > [Joerg] > > > Perhaps i've overlooked this? > > > > No, you haven't overlooked it. Apparently it either never worked the > > way I thought it did or it was broken at some time. Note that we have > > a type to use in the "scsidevs" structure (the matching structure), > > and we carefully take the type out of that structure after a match: > > > > > *type_p = bestmatch->type; > > > > But this is a NOP since the match fails when the type is different. > well it used to work at TFS, but it's changed almost beyond recognition. I USED to have a device that reported itself as a tape when it was a processor.. I just added an entry in for it that said it was a tape, and had a pointer to the 'processor' attach routine associated with it.. with the new code I guess I'd need to put { T_SEQUENTIAL, T_REMOV, "WangDAT", "Model 1300", "*", "proc", SC_ONE_LU, 0, mode_wangdat1300 }, as there is no longer a direct pointer to the routine, but just a 'name' to lookup in the list of installed drivers.. > > Ideally, i would like that > > disk od0 at scbus0 target 3 > > would force the device on scbus0 target3 to go to the `od' driver. > I'm not sure if this might be a good idea, since some bozo could > attach a tape drive to target 3, and the `od' driver would horribly > fail. > more likely you want to do this for a failing device in which case you want it to be a 'rogue' type entry. > > I would keep NEW_SCSICONF (since that is all I've been running lately > > and one of the two branches is getting musty) > > and change scsi_selectdev to a scoring scheme: that's funny.. I thought you wanted to get rid of NEW_SCSICONF :) > > Guess i like it. > > > Commentary about hunting through "knowndevs": > > > > The changes I outline here should give you what you want, and I > > think would be an improvement. However, instead of a single > > structure we really should have a distributed structure where in > > addition to a possible list of "knowndevs" in scsiconf.c we have > > additional devices in each type driver (st.c, sd.c, etc) and a way > > to add new ones via config and "boot -c". Then your current problem > > would be near zero: you'd just config in a new "rogue". I agree with this.. each driver needs to be able to add it's own 'rogues as it's configured in.. the init routine can do this.. that's why we put it there.. it becomes a linked list of variable length arrays? or do we link them all into one big list? (speed isn't important .. it's run so rarely) > > Hmmmmm. Interesting. It would require extending config(8) and > UserConfig. I don't see problems for the former, but maybe the latter > will become too much bloated then? Remember, kernel pages are not > pageable, and UserConfig is totally useless wasted memory once the > kernel is running. > > > Unfortunately I'm no longer running -current: I don't have a system > > unimportant enough at the moment to do so! If you'd like I'll make these > > changes, get them to compile and then let you do some testing. These > > are pretty low risk changes. > > I can do it. > > -- > cheers, J"org > > joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ > Never trust an operating system you don't have sources for. ;-) > From owner-freebsd-scsi Mon Aug 21 21:21:15 1995 Return-Path: freebsd-scsi-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id VAA01270 for freebsd-scsi-outgoing; Mon, 21 Aug 1995 21:21:15 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id VAA01247 for ; Mon, 21 Aug 1995 21:21:04 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA23459; Tue, 22 Aug 1995 06:21:02 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id GAA02508; Tue, 22 Aug 1995 06:21:01 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id BAA07940; Tue, 22 Aug 1995 01:12:04 +0200 From: J Wunsch Message-Id: <199508212312.BAA07940@uriah.heep.sax.de> Subject: Re: scsiconf change To: julian@ref.tfs.com (Julian Elischer) Date: Tue, 22 Aug 1995 01:12:04 +0200 (MET DST) Cc: joerg_wunsch@uriah.heep.sax.de, dufault@hda.com, scsi@freebsd.org In-Reply-To: <199508211802.LAA24139@ref.tfs.com> from "Julian Elischer" at Aug 21, 95 11:02:52 am Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 699 Sender: freebsd-scsi-owner@freebsd.org Precedence: bulk As Julian Elischer wrote: > > with the new code I guess I'd need to put > { > T_SEQUENTIAL, T_REMOV, "WangDAT", "Model 1300", "*", > "proc", SC_ONE_LU, 0, mode_wangdat1300 > }, > as there is no longer a direct pointer to the routine, but just a 'name' > to lookup in the list of installed drivers.. I don't believe this would work currently. I've tried it for the `od' driver -- i've got a very old SONY MOD device that identifies itself as T_DIRECT, and it has always been assigned to the `sd' driver. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Mon Aug 21 22:29:14 1995 Return-Path: freebsd-scsi-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id WAA03779 for freebsd-scsi-outgoing; Mon, 21 Aug 1995 22:29:14 -0700 Received: from duality.gnu.ai.mit.edu (duality.gnu.ai.mit.edu [18.43.0.236]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id WAA03769 for ; Mon, 21 Aug 1995 22:29:12 -0700 Received: by duality.gnu.ai.mit.edu (8.6.12/8.6.12GNU) id BAA01099; Tue, 22 Aug 1995 01:29:04 -0400 Date: Tue, 22 Aug 1995 01:29:04 -0400 Message-Id: <199508220529.BAA01099@duality.gnu.ai.mit.edu> From: Charles Hannum To: dufault@hda.com Cc: joerg_wunsch@uriah.heep.sax.de, scsi@freebsd.org Subject: Re: scsiconf change Sender: freebsd-scsi-owner@freebsd.org Precedence: bulk and change scsi_selectdev to a scoring scheme: [code omitted] This is a similar idea to the pattern matcher I wrote in the NetBSD SCSI code last year. The vendor/product/revision matching can be partial, and is scored based on the number of characters that were checked, which provides even more flexibility. The patterns are stored in an array, which each driver can elect to specify a wider version of, with the beginning of each array element being assumed to be in a common format. (This is vaguely similar to how the qsort(3) interface works, so there's some precedent for it.) Currently, only the `st' driver has any driver-specific quirk info. The net effect of this design is that it has all the flexibility people have been asking for, allows each driver to have its own quirk info, and still allows the matching to be done with a common routine. I've also made a number of other structural improvements, including much better error handling, and one that effectively speeds up probing for SCSI devices by a factor of 3x. Anyone interested can inquire, or go look at the code. (Note that I'm *very* busy, so replies are likely to be glacial.) From owner-freebsd-scsi Tue Aug 22 09:00:27 1995 Return-Path: freebsd-scsi-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id JAA02842 for freebsd-scsi-outgoing; Tue, 22 Aug 1995 09:00:27 -0700 Received: from hda.com (hda.com [199.232.40.182]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id JAA02829 for ; Tue, 22 Aug 1995 09:00:23 -0700 Received: (from dufault@localhost) by hda.com (8.6.11/8.6.9) id LAA10334; Tue, 22 Aug 1995 11:51:44 -0400 From: Peter Dufault Message-Id: <199508221551.LAA10334@hda.com> Subject: Re: scsiconf change To: julian@ref.tfs.com (Julian Elischer) Date: Tue, 22 Aug 1995 11:51:43 -0400 (EDT) Cc: joerg_wunsch@uriah.heep.sax.de, scsi@freebsd.org In-Reply-To: <199508211802.LAA24139@ref.tfs.com> from "Julian Elischer" at Aug 21, 95 11:02:52 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 594 Sender: freebsd-scsi-owner@freebsd.org Precedence: bulk > that's funny.. I thought you wanted to get rid > of NEW_SCSICONF :) Shh... I'm being polite in public, the NEW_SCSICONF author might be reading... It is important to get rid of ONE of the SCSICONFs, and since I proposed to change my biggest complaint NEW_SCSICONF is as good as OLD_SCSICONF. My complaint about NEW_SCSICONF is the one I mention: Moving tape info into scsiconf.c instead of keeping it in st.c. Peter -- Peter Dufault Real Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 dufault@hda.com Fax: 508 433 5267 From owner-freebsd-scsi Wed Aug 23 02:53:31 1995 Return-Path: freebsd-scsi-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id CAA25141 for freebsd-scsi-outgoing; Wed, 23 Aug 1995 02:53:31 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id CAA25132 for ; Wed, 23 Aug 1995 02:53:28 -0700 Received: from corbin.Root.COM (corbin [198.145.90.34]) by Root.COM (8.6.11/8.6.5) with ESMTP id CAA05925; Wed, 23 Aug 1995 02:52:29 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.11/8.6.5) with SMTP id CAA01907; Wed, 23 Aug 1995 02:54:18 -0700 Message-Id: <199508230954.CAA01907@corbin.Root.COM> To: scsi@freebsd.org cc: julian@ref.tfs.com Subject: bt742a.c From: David Greenman Reply-To: davidg@Root.COM Date: Wed, 23 Aug 1995 02:54:18 -0700 Sender: freebsd-scsi-owner@freebsd.org Precedence: bulk Can someone with BusLogic programming information tell me if the following change is correct? -DG *** 210/sys/i386/isa/bt742a.c Tue May 30 01:01:21 1995 --- sys/i386/isa/bt742a.c Tue Jul 25 09:06:06 1995 *************** *** 121,128 **** /* The following command appeared at FirmWare 3.31 */ #define BT_ROUND_ROBIN 0x8f /* Enable/Disable(default) round robin */ ! #define BT_DISABLE 0x00 /* Parameter value for Disable */ ! #define BT_ENABLE 0x01 /* Parameter value for Enable */ struct bt_cmd_buf { u_char byte[16]; --- 121,128 ---- /* The following command appeared at FirmWare 3.31 */ #define BT_ROUND_ROBIN 0x8f /* Enable/Disable(default) round robin */ ! #define BT_STRICT_ROUND_ROBIN 0x00 /* Parameter value for strict mode */ ! #define BT_AGRES_ROUND_ROBIN 0x01 /* Parameter value for backword comp */ struct bt_cmd_buf { u_char byte[16]; *************** *** 1383,1392 **** * BT_ROUND_ROBIN command amurai@spec.co.jp */ if ( bID.firm_revision >= '3' ) { ! printf("bt%d: Enabling Round robin scheme\n", unit); ! bt_cmd(unit, 1, 0, 0, 0, BT_ROUND_ROBIN, BT_ENABLE); } else { ! printf("bt%d: Not Enabling Round robin scheme\n", unit); } } --- 1387,1396 ---- * BT_ROUND_ROBIN command amurai@spec.co.jp */ if ( bID.firm_revision >= '3' ) { ! printf("bt%d: Using Strict Round robin scheme\n", unit); ! bt_cmd(unit, 1, 0, 0, 0, BT_ROUND_ROBIN, BT_STRICT_ROUND_ROBIN); } else { ! printf("bt%d: Not using Strict Round robin scheme\n", unit); } }