SCSI Drives not Found

rtwingfield

rtwingfield

I have successuflly compiled a kernel for FreeBSD 8.2-RELEASE #1, CPU: Intel(R) Xeon(TM) CPU 2.40GHz (2392.29-MHz 686-class CPU), FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs

The following from dmesg.boot:
Code: 
aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI 33 or 66MHz, 512 SCBs
[B]ahd1: <Adaptec AIC7902 Ultra320 SCSI adapter>[/B] port 0xb800-0xb8ff,0xbc00-0xbcff mem 

0xf1002000-0xf1003fff irq 25 at device 7.1 on pci3
ahd1: [ITHREAD]
aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI 33 or 66MHz, 512 SCBs
pci3: <mass storage, RAID> at device 8.0 (no driver attached)

I can mount a USB flash drive, for example, the output of # mount:
Code: 
/dev/ad2s1a on / (ufs, local)
devfs on /dev (devfs, local, multilabel)
/dev/ad2s1e on /tmp (ufs, local, soft-updates)
/dev/ad2s1f on /usr (ufs, local, soft-updates)
/dev/ad2s1d on /var (ufs, local, soft-updates)
[B]/dev/da0s1 on /mnt/usb/UDISK (msdosfs, local)[/B]

/etc/fstab contains the following:

Code: 
# Device		Mountpoint	FStype	Options		Dump	Pass#
/dev/ad2s1b		none		swap	sw		0	0
/dev/ad2s1a		/		ufs	rw		1	1
/dev/ad2s1e		/tmp		ufs	rw		2	2
/dev/ad2s1f		/usr		ufs	rw		2	2
/dev/ad2s1d		/var		ufs	rw		2	2
/dev/acd0		/cdrom		cd9660	ro,noauto	0	0

I probably don't see the forest for the trees, but I do not understand why the system is not acknowledging the SCSI drives. As noted above in the dmesg.boot output,
Code: 
ahd1: <Adaptec AIC7902 Ultra320 SCSI adapter>
apparently is recognized. Is this just a simple matter of including appropriate code in the fstab file? If so, then can someone provide an example of the syntax for mounting the controller and/or drives (my apologies, the last time I configured a custom kernel was in 2003, and on a need-to-know basis, I haven't configured SCSI HDs before . . .just used them).

But then again, how can I mount a device such as ahd1 when it does not appear in the /dev list?
 
ahd1 is the controller. You don't mount the controller, you mount the drives attached to the controller.

SCSI disks are labelled daX where X is a number, with the first disk being da0. If you check the dmesg output again, you should see the daX entries.

And, if you check the output of # ls /dev/da* you'll see the disks (daX), the partitions (daXsY), and the filesystems (daXsYa).
 
Ah, yeah, I know that :r regarding the following . . .I should have clarified:
ahd1 is the controller. You don't mount the controller, you mount the drives attached to the controller.
Click to expand...

RE:
SCSI disks are labelled daX where X is a number, with the first disk being da0. If you check the dmesg output again, you should see the daX entries.
Click to expand...
Also know that; however, the only mention of anything similar in dmesg.boot is:

Code: 
da0 at umass-sim0 bus 0 scbus2 target 0 lun 0
da0: <USB DISK 2.0 1029> Removable Direct Access SCSI-0 device 
da0: 1.000MB/s transfers
da0: 7776MB (15925248 512 byte sectors: 255H 63S/T 991C)


And, if you check the output of # ls /dev/da* you'll see the disks (daX), the partitions (daXsY), and the filesystems (daXsYa).
Click to expand...
. . .problem is . . .da*s are just not in /dev.

I have read some "disturbing" posts (also in GoogleLand) regarding or suggesting things that are "broke" following upgrades from v7+ to v8+ as related to SCSI drivers and performance. Things like *.ko, i.e., kernel object modules missing or not included in GENERIC, or (in my case) the v8.2 RELEASE. Any thoughts?

Also, what about the mpt drivers . . .see mpt(4) . . .no mention of mpt in /dev or dmesg.boot.

Thanks!
 
Please give details. Are you upgrading a system? Did the SCSI sdrives have a system on them from before, or are they new? Post the whole output of dmesg(8) and ls /dev/* on pastebin.com and give a link to it.
 
RE:
Please give details. Are you upgrading a system? Did the SCSI sdrives have a system on them from before, or are they new? Post the whole output of dmesg(8) and ls /dev/*
Click to expand...

This is a new or fresh install of FreeBSD v8.2 installed on a WD Caviar 102BA Enhanced IDE (10.2GB) HD. The hardware was originally used as a fileserver running on MS/something server. It was used by my wife's law firm (she is a senior partner). The support company claimed that a drive had failed, or some laim excuse that the approx. 500GB storage was not enough to run a time billing application pig . . .incredible! Regardless, when I inherited it, it had no EIDE drive. I had the 10GB drive lying around and decided to install FreeBSD on it in order to install a prototype OS (FreeBSD v8.2). I don't know if they were booting from one of the SCSI drives or if it even had an EIDE drive in it. Nobody at the firm knows that much about it and the support company has been fired; regardless, I plan/need to do a low-level format (if that's the proper operation) to wipe all the firm data from the drives if not already erased. This poses a question in my mind . . .has someone already done that and wiped some of the SCSI "intelligence" from the drives? (Honestly, I don't know too much about SCSI configuration . . .never had to before.)


Additional SCSI hardware consists of a six-bay rack containing the following drives:

Code: 
2 Toshiba MAW3147NC (147GB) Ultra 320 SCSI
3 Toshiba MAP3367NC (36GB)  SCSI SCA-2

The SCSI controller is an Adaptec AIC 7902 Ultra 320, with LSI MegaRAID Ultra 320 BIOS v4.0 (I'll have to check regarding the latter)

Here is a URL to kernel configuration files, dmesg.boot, fstab, kernel modules, mount info, etc.: http://archaxis.net/htdocs/RTWingfield/htdocs/FreeBSD/kernel_dev/ (all are suffixed with .txt . . .seem to render nicely in your browser).

You'll recognize GENERIC as the distribution generic kernel configuration file. I've created the XEON configuration file (named after the Intell processors . . .whatever). The XEON.bu version is very similar to the GENERIC with regard to the configuration file sizes, but with a significant number of commented-out lines.

When I boot the OS with the kernel built from XEON.bu, the dmesg.boot file contains:

Code: 
umass0: <USB DISK 2.0, class 0/0, rev 2.00/10.29, addr 2> on usbus0
umass0:  SCSI over Bulk-Only; quirks = 0x0000
umass0:2:0:-1: Attached to scbus2
da0 at umass-sim0 bus 0 scbus2 target 0 lun 0
da0: <USB DISK 2.0 1029> Removable Direct Access SCSI-0 device
da0: 1.000MB/s transfers
da0: 7776MB (15925248 512 byte sectors: 255H 63S/T 991C)
If I boot with the kernel built from the XEON configuration file in which I attempted to delete only the commented-out lines, then the previously listed umass0 and da0 are not included, and da0 and da0s1 are omitted from /dev, too . . .? (The latter is probablyl my fault; I must have deleted something that was not commented-out . . .haven't checked yet.)

and the /dev list contains:

Code: 
crw-r-----  1 root  operator    0,  99 Dec  2 11:11 da0
crw-r-----  1 root  operator    0, 100 Dec  2 11:11 da0s1

Finally, I'd like to thank you (and Phoenix) for the invitation to submit my questions. This is a lenghty post, but I'm just at a loss for where to go next.

I will be driving from Little Rock to Ft. Worth, TX tomorrow morning, returning Sunday. As always, all thoughts, suggestions and recommendations will be greatly appreciated.
 
Okay, so the condition of the SCSI drives is unknown. The SCSI card may have a BIOS that will show drives detected. Someone may have tampered with termination or cables or the controller settings before you got it.
 
Don't worry, SCSI drives are just as reliable and easy to work with as ide or sata drives, once you get the hang of it. ;)
There is several interesting lines in your dmesg output:
Code: 
pci0: <unknown> at device 0.1 (no driver attached)
pci3: <mass storage, RAID> at device 8.0 (no driver attached)
pci0: <unknown> at device 2.1 (no driver attached)
You should figure out what those are, use the # pciconf -lv command for that.
To figure out if there are devices connected to scsi (and other) controllers, you use the camcontrol(8) command. Like this: # camcontrol devlist. Here is an example:
Code: 
root@kg-vm# camcontrol devlist -v
scbus0 on ata0 bus 0:
<Optiarc DVD RW AD-5170A 1.12>     at scbus0 target 0 lun 0 (cd0,pass0)
<>                                 at scbus0 target -1 lun -1 ()
scbus1 on ata2 bus 0:
<>                                 at scbus1 target -1 lun -1 ()
scbus2 on ata3 bus 0:
<>                                 at scbus2 target -1 lun -1 ()
scbus-1 on xpt0 bus 0:
<>                                 at scbus-1 target -1 lun -1 (xpt0)
Hope this helps.
 
Thanks for the encouragement! Regarding wblock@'s suggestions, I'm in the process of formatting the drives . . .got about an hour and fifteen minutes to go on the last 147GB drive. I think the controller is functioning as advertised. I've also doubled check the cables, terminators, etc. and all seem OK.

The controller BIOS runs the [font="Courier New"]MegaRAID Config Utility (40-Ld) v5.30 4 SEP 2002[/font]. Before I started the format operations, I configured the two 147GB drives into one logical array, and the three 36GB drives into an additional logical array, and still the v8.2 FreeBSD kernel configuration (albeit my version) did not recognize the logicals. My intention was to wipe the law firm's data from the physical drives anyway, so I dropped back and decided to start from scratch with the configuration, ergo, the reformatting of the physical drives.

Interesting to note that prior to the reformat ops., but following the configuration of the logical arrays, the kernel did not recognize the da0 or da0s1 devices . . .as before.

Also, I'm not really afraid of this SCSI configuration thing. It's just that on a need-to-know basis, I've never had to deal with it before. My IBM AS/400 9401-150 RISC box and old NCR Motorola 98000 SVR3 Unix box have SCSI drives and they just work . . .and work . . .and work. Really, quite amazing when you think about it.

Once the formatting is completed, I'll explore the configuration per your suggestions with pciconf and camcontrol.

Again, mucho thanks!
 
You must log in or register to reply here.
Back
Top