From owner-cvs-sys Sat Jan 25 12:27:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA15958 for cvs-sys-outgoing; Sat, 25 Jan 1997 12:27:17 -0800 (PST) Received: (from wpaul@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA15951; Sat, 25 Jan 1997 12:27:16 -0800 (PST) Date: Sat, 25 Jan 1997 12:27:16 -0800 (PST) From: Bill Paul Message-Id: <199701252027.MAA15951@freefall.freebsd.org> To: CVS-committers, cvs-all, cvs-sys Subject: cvs commit: src/sys/scsi scsi_base.c scsi_driver.c scsiconf.c scsiconf.h Sender: owner-cvs-sys@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk wpaul 97/01/25 12:27:15 Modified: sys/scsi scsi_base.c scsi_driver.c scsiconf.c scsiconf.h Log: Make the SCSI probe messages more BSDish. This may raise a few eyebrows ("Hey! Who made _you_ the keeper of all things BSDish?!") but this has bugged me for a long time, and now that I finally have the chance to hack on it (and test the results), I'll take my chances. I can also point to other BSD implementations for precedents if you put my back to the wall. The only thing that's changed is how the messages are formatted. Now, instead of having this: aha0 at 0x330-0x333 irq 11 drq 5 on isa (aha0:3:0): "HP C1553A 9503" type 1 removable SCSI 2 st0(aha0:3:0): Sequential-Access density code 0x24, variable blocks, write-enabled (aha0:3:1): "HP C1553A 9503" type 8 removable SCSI 2 ch0(aha0:3:1): Medium-Changer 6 slot(s) 1 drive(s) 0 arm(s) 0 i/e-slot(s) We have this: aha0 at 0x330-0x333 irq 11 drq 5 on isa scbus0 at aha0 bus 0 st0 at scbus0 target 3 lun 0 st0: type 1 removable SCSI 2 st0: Sequential-Access density code 0x24, variable blocks, write-enabled ch0 at scbus0 target 3 lun 1 ch0: type 8 removable SCSI 2 ch0: Medium-Changer 6 slot(s) 1 drive(s) 0 arm(s) 0 i/e-slot(s) Which is (to me anyway) is a lot more pleasant to look at. (Call me crazy -- g'head: you know you wanna -- but the previous messages remind me of Linux. Ever see the output from the linux device probes? It's a mess of copyright notices, version numbers/dates, author e-mail addresses and other crap. Let's not go there, okay? Bleh.) Notice that devices are now specified in terms of the scsi bus they live on rather than the adapter. This better reflects the contents of the kernel config file (if you use wired-down device specifications anyway) and removes some ambiguity that may arise if you have a multi- channel adapter with more than one bus. Also, sc_print_addr() now generates messages like this: st0 at scbus0 target 3 lun 0: NOT READY asc:3a,0 Medium not present instead of this: st0(aha0:3:0): NOT READY asc:3a,0 Medium not present I also added a quirk entry for the HP Superstore 12000e 6 tape DAT autoloader, which needs SC_MORE_LUS in order for the changer device to be properly probed and attached. (I'm working on a chcontrol utility to manipulate the changer on this drive which should hopefully be general enough to work with other changers too. If you want the prototype I have now, it's at ftp://skynet.ctr.columbia.edu/pub/freebsd/changer.c.) Remaining bugs: - The 'foodev0: yadda yadda yadda' bits should probably be printed entirely by the device-specific subdriver attach code instead of half by the scsi_device_attach() routine and half by the device specific attach routine like it is now. - The wired-down device specifications in the kernel config file should be used to control bus/device probing to some extent rather than just for choosing names for devices we find. If the config says there's a device at scbus0 target 0 lun 0 called sd0, we should look there and check for a device that can be managed by the sd driver. If we don't find one, we should probably complain that there's no device there or that there is a device but of the wrong type. Once all the devices from the wired down list have been probed, the code can then autodetect and autoattach any devices that remain unassigned. - Apparently some tape changers (hi Ulf!) return 'not ready/medium not present' when the magazine is loaded but a tape has not been put in the drive yet. This causes an open(/dev/ch0) to fail and prevents you from using the changer.c utility to load the first tape into the drive. My HP changer does not behave this way. The workaround is to manually load a tape into the drive before attempting to use the changer program, but you can get in trouble if you accidentally eject a tape without loading a new one and you're at a remote location: you won't be able to load any tapes anymore. I'm not sure what the correct software solution is for this but ideally there should be one. - I should not be doing this: I'm the NIS guru, not the SCSI guru. (This is not my beautiful code. How did I get here? My god: what have I done?) Revision Changes Path 1.42 +7 -10 src/sys/scsi/scsi_base.c 1.20 +9 -3 src/sys/scsi/scsi_driver.c 1.75 +84 -2 src/sys/scsi/scsiconf.c 1.48 +4 -0 src/sys/scsi/scsiconf.h