Can't see scsi drives in sysinstall

We have a number of very similar machines that have been running 7.3-STABLE. I wanted to upgrade to 8.2-RELEASE, so I started with an arbitrary machine. I tried to do an in-place upgrade using the standard cvsup/buildworld/buildkernel/etc method, but when I went to boot into single-user mode to do the mergemaster/installworld, I couldn't boot anymore. Not really interested in diagnosing that, I went to install afresh, using an 8.2-RELEASE livefs cd. Unfortunately, when I go to partition the disk, it complains it can't find any. Likewise, when I go into the fixit console, an ls of /dev reveals no hard drives.

Thinking it might be a hardware issue, I brought down an identical-hardware machine and booted it from cd - same problem. Removing the cd, it boots right back into 7.3-STABLE (since I hadn't tried to upgrade that machine).

The machines aren't running any type of hardware raid (it's disabled in the bios). The SCSI controller is an LSILogic 1030 Ultra4 Adapter. I'm almost positive they use the "mpt" kernel module, which is part of GENERIC. When I went to kldload mpt.ko in the fixit console, I can see a "that module is already loaded"(paraphrasing) message in dmsesg.

I don't have output from the downed machine, but I do have dmesg output from the 7.3-STABLE machine that is running happily; I'll post it below. Am I missing something totally boneheaded? I've googled my heart out, and of course looked at the FreeBSD handbook, but can find no explanation for what I'm seeing.

thanks,
Nat

dmesg:
Code:
Copyright (c) 1992-2010 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
	The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.3-STABLE #2: Tue Nov 16 14:08:59 PST 2010
    [redacted]:/usr/obj/usr/src/sys/GENERIC amd64
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: AMD Opteron(tm) Processor 250 (2411.13-MHz K8-class CPU)
  Origin = "AuthenticAMD"  Id = 0xf5a  Family = f  Model = 5  Stepping = 10
  Features=0x78bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2>
  AMD Features=0xe0500800<SYSCALL,NX,MMX+,LM,3DNow!+,3DNow!>
usable memory = 3206860800 (3058 MB)
avail memory  = 3093815296 (2950 MB)
ACPI APIC Table: <PTLTD  	 APIC  >
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
ioapic0 <Version 1.1> irqs 0-23 on motherboard
ioapic1 <Version 1.1> irqs 24-27 on motherboard
ioapic2 <Version 1.1> irqs 28-31 on motherboard
kbd1 at kbdmux0
acpi0: <PTLTD   RSDT> on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0
acpi_button0: <Power Button> on acpi0
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
pci0: <memory> at device 0.0 (no driver attached)
isab0: <PCI-ISA bridge> at device 1.0 on pci0
isa0: <ISA bus> on isab0
pci0: <serial bus, SMBus> at device 1.1 (no driver attached)
ohci0: <OHCI (generic) USB controller> mem 0xc8000000-0xc8000fff irq 20 at device 2.0 on pci0
ohci0: [GIANT-LOCKED]
ohci0: [ITHREAD]
usb0: OHCI version 1.0, legacy support
usb0: SMM does not respond, resetting
usb0: <OHCI (generic) USB controller> on ohci0
usb0: USB revision 1.0
uhub0: <nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb0
uhub0: 10 ports with 10 removable, self powered
ehci0: <NVIDIA nForce4 USB 2.0 controller> mem 0xc8001000-0xc80010ff irq 21 at device 2.1 on pci0
ehci0: [GIANT-LOCKED]
ehci0: [ITHREAD]
usb1: EHCI version 1.0
usb1: companion controller, 4 ports each: usb0
usb1: <NVIDIA nForce4 USB 2.0 controller> on ehci0
usb1: USB revision 2.0
uhub1: <nVidia EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb1
uhub1: 10 ports with 10 removable, self powered
pci0: <multimedia, audio> at device 4.0 (no driver attached)
atapci0: <nVidia nForce CK804 UDMA133 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1c00-0x1c0f at device 6.0 on pci0
ata0: <ATA channel 0> on atapci0
ata0: [ITHREAD]
ata1: <ATA channel 1> on atapci0
ata1: [ITHREAD]
atapci1: <nVidia nForce CK804 SATA300 controller> port 0x1c40-0x1c47,0x1c34-0x1c37,0x1c38-0x1c3f,0x1c30-0x1c33,0x1c10-0x1c1f
 mem 0xc8003000-0xc8003fff irq 23 at device 7.0 on pci0
atapci1: [ITHREAD]
ata2: <ATA channel 0> on atapci1
ata2: [ITHREAD]
ata3: <ATA channel 1> on atapci1
ata3: [ITHREAD]
atapci2: <nVidia nForce CK804 SATA300 controller> port 0x1c58-0x1c5f,0x1c4c-0x1c4f,0x1c50-0x1c57,0x1c48-0x1c4b,0x1c20-0x1c2f
 mem 0xc8004000-0xc8004fff irq 20 at device 8.0 on pci0
atapci2: [ITHREAD]
ata4: <ATA channel 0> on atapci2
ata4: [ITHREAD]
ata5: <ATA channel 1> on atapci2
ata5: [ITHREAD]
pcib1: <ACPI PCI-PCI bridge> at device 9.0 on pci0
pci1: <ACPI PCI bus> on pcib1
vgapci0: <VGA-compatible display> port 0x2000-0x20ff mem 0xd0000000-0xd7ffffff,0xc8100000-0xc810ffff irq 16 at device 4.0 on pci1
nfe0: <NVIDIA nForce4 CK804 MCP9 Networking Adapter> port 0x1c60-0x1c67 mem 0xc8005000-0xc8005fff irq 21 at device 10.0 on pci0
miibus0: <MII bus> on nfe0
e1000phy0: <Marvell 88E1111 Gigabit PHY> PHY 1 on miibus0
e1000phy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
nfe0: Ethernet address: 00:e0:81:54:e5:6a
nfe0: [FILTER]
pcib2: <ACPI PCI-PCI bridge> at device 14.0 on pci0
pci2: <ACPI PCI bus> on pcib2
pcib3: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci8: <ACPI PCI bus> on pcib3
pcib4: <ACPI PCI-PCI bridge> at device 10.0 on pci8
pci9: <ACPI PCI bus> on pcib4
pcib5: <ACPI PCI-PCI bridge> at device 11.0 on pci8
pci10: <ACPI PCI bus> on pcib5
em0: <Intel(R) PRO/1000 Legacy Network Connection 1.0.1> port 0x3800-0x383f mem 0xd8140000-0xd815ffff,0xd8100000-0xd813ffff irq 28
 at device 4.0 on pci10
em0: [FILTER]
em0: Ethernet address: 00:04:23:d4:46:a8
em1: <Intel(R) PRO/1000 Legacy Network Connection 1.0.1> port 0x3840-0x387f mem 0xd8160000-0xd817ffff,0xd8180000-0xd81bffff irq 29
 at device 4.1 on pci10
em1: [FILTER]
em1: Ethernet address: 00:04:23:d4:46:a9
mpt0: <LSILogic 1030 Ultra4 Adapter> port 0x3000-0x30ff mem 0xd8300000-0xd83fffff,0xd8200000-0xd82fffff irq 30 at device 6.0 on pci10
mpt0: [ITHREAD]
mpt0: MPI Version=1.2.14.0
mpt1: <LSILogic 1030 Ultra4 Adapter> port 0x3400-0x34ff mem 0xd8500000-0xd85fffff,0xd8400000-0xd84fffff irq 31 at device 6.1 on pci10
mpt1: [ITHREAD]
mpt1: MPI Version=1.2.14.0
em2: <Intel(R) PRO/1000 Legacy Network Connection 1.0.1> port 0x3880-0x38bf mem 0xd8600000-0xd861ffff,0xd81c0000-0xd81fffff irq 29
 at device 9.0 on pci10
em2: [FILTER]
em2: Ethernet address: 00:04:23:d4:46:cc
em3: <Intel(R) PRO/1000 Legacy Network Connection 1.0.1> port 0x38c0-0x38ff mem 0xd8620000-0xd863ffff,0xd8640000-0xd867ffff irq 30
 at device 9.1 on pci10
em3: [FILTER]
em3: Ethernet address: 00:04:23:d4:46:cd
pcib6: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci128: <ACPI PCI bus> on pcib6
pci128: <memory> at device 0.0 (no driver attached)
pci128: <memory> at device 1.0 (no driver attached)
pcib7: <ACPI PCI-PCI bridge> at device 14.0 on pci128
pci129: <ACPI PCI bus> on pcib7
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
sio0: type 16550A, console
sio0: [FILTER]
fdc0: <floppy drive controller> port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0
fdc0: [FILTER]
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
cpu0: <ACPI CPU> on acpi0
powernow0: <Cool`n'Quiet K8> on cpu0
device_attach: powernow0 attach returned 6
cpu1: <ACPI CPU> on acpi0
powernow1: <Cool`n'Quiet K8> on cpu1
device_attach: powernow1 attach returned 6
ppc0: <Parallel port> port 0-0x7 on acpi0
ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode
ppbus0: <Parallel port bus> on ppc0
plip0: cannot reserve interrupt, failed.
lpt0: <Printer> on ppbus0
lpt0: Polled port
ppi0: <Parallel I/O> on ppbus0
orm0: <ISA Option ROMs> at iomem 0xc0000-0xcbfff,0xcc000-0xcd7ff,0xcd800-0xd17ff on isa0
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
sio1: configured irq 3 not in bitmap of probed irqs 0
sio1: port may not be enabled
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
Timecounters tick every 1.000 msec
acd0: CDROM <SONY CD-ROM CDU5215/7YS1> at ata0-master UDMA33
Waiting 5 seconds for SCSI devices to settle
(probe0:mpt0:0:8:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 
(probe0:mpt0:0:8:0): CAM Status: SCSI Status Error
(probe0:mpt0:0:8:0): SCSI Status: Check Condition
(probe0:mpt0:0:8:0): UNIT ATTENTION asc:29,0
(probe0:mpt0:0:8:0): Power on, reset, or bus device reset occurred
(probe0:mpt0:0:8:0): Retrying Command (per Sense Data)
ses0 at mpt0 bus 0 target 8 lun 0
ses0: <SUPER GEM359 REV001 1.09> Fixed Processor SCSI-2 device 
ses0: 3.300MB/s transfers
ses0: SAF-TE Compliant Device
SdMaP0:  aAtP  mCpPtU0  #b1u sL a0u ntcahregde!t
 0 lun 0
da0: <HITACHI HUS103014FL3800 SA18> Fixed Direct Access SCSI-3 device 
da0: 320.000MB/s transfers (160.000MHz DT, offset 80, 16bit)
da0: Command Queueing Enabled
da0: 140205MB (287140277 512 byte sectors: 255H 63S/T 17873C)
da1 at mpt0 bus 0 target 1 lun 0
da1: <HITACHI HUS103014FL3800 SA18> Fixed Direct Access SCSI-3 device 
da1: 320.000MB/s transfers (160.000MHz DT, offset 80, 16bit)
da1: Command Queueing Enabled
da1: 140205MB (287140277 512 byte sectors: 255H 63S/T 17873C)
Trying to mount root from ufs:/dev/da0s1a
em0: link state changed to UP
 
Within sysinstall, go to Options and try "Re-scan devices". That may help.
 
Between 7.3 and 8.2 , various geom_mbr.ko etc may be missing, and if readded, sysinstall and/or the buildworld reboot may work. Not certain though, but I have encountered that on at least two instances that I know of, as well as similar changes *maybe* between 8.x and 9.x (CURRENT). All were fixed (except one instance where a laptop card and irq problem intervened in the meantime, which itself was "fixed" ... deinsert the card slightly to boot an install CD, etc...)
 
SirDice: I wish it was something that obvious, but yes, I've already tried that.

jb_fvwm2: Are you saying that the 8.2-RELEASE livefs cd that I downloaded is not set up to load basic kernel modules? What do you mean "all were fixed"? Should I re-download the disc image? Should I try to kldload geom*.ko from the fixit console?
 
If I knew the solution, I could post it. Your 7.3 8.x *may* have omitted the geom_bsd.ko, geom_mbr.ko, and geom_label.ko (iirc) from the newer GENERIC, and adding them in *may* fix the reboot after installkernel. (Similarly *maybe* fixing the live cd, but I forget how to load those during sysintall... ) By "all were fixed", I found a solution in each case (as above) (including v8 > v9 which also involved other pata > sata (or sata > sata or pata > sata > sata etc.. )renamings probably).
 
So I tried booting off a 7.4-RELEASE disc today; that worked fine, e.g. it found my drives no problem. I went back to 8.2, booted to command prompt, used the "load" command to load geom_bsd, geom_mbr and gom_label, then the "boot" command to continue booting. Didn't help. I also confirmed using 'lsmod' from the boot prompt and by using kldstat -v in the fixit console that the various mpt modules are getting loaded. Somehow, FreeBSD 8's mpt driver seems to have broken support for my LSI 1030 (I tried an 8.1 disc as well). I looked and there does not seem to be updated firmware for it. Any suggestions as to where to search for more information? dmesg from the fixit console in an 8.2 disc boot simply shows no evidence of even trying to load an mpt device, and /dev/mpt0 is missing.
 
Search the forum for mpt? A large thread mentions many cards/controllers. (Did not read it for that LSI 1030, just skimmed it...)
 
Code:
ATOMIZER-64# dmesg | grep 'LSI'
mpt0: <LSILogic 1030 Ultra4 Adapter> port 0x7000-0x70ff mem 0x99a60000-0x99a7ffff,0x99a40000-0x99a5ffff irq 16 at device 1.0 on pci5
mpt1: <LSILogic 1030 Ultra4 Adapter> port 0x7400-0x74ff mem 0x99aa0000-0x99abffff,0x99a80000-0x99a9ffff irq 17 at device 1.1 on pci5

I have this adapter and have no problems with it on 8.x or now 9 RC2. Just make sure that

Code:
device    mpt

is in your kernel config file if you make a custom kernel.

Back in the 7/8-current day there were various problems with the mpt driver with each revision and you may even find old email that I sent the maintainer with diffs, but once 8 was in release there were no problems that I can recall. I've had this machine for 6 years now with LSI adapter(S).
 
RE:
Just make sure that
Code:
device    mpt
is in your kernel config file if you make a custom kernel.

Yep, it's in there. FYI, here's a url to my kernel config file: http://archaxis.net/htdocs/RTWingfield/htdocs/FreeBSD/kernel_dev/XEON.txt

Specifically, the following regarding the SCSI details:
Code:
# SCSI Controllers
device	ahc		# AHA2940 and onboard AIC7xxx devices
options AHC_REG_PRETTY_PRINT	# Print register bitfields in debug
					# output.  Adds ~128k to driver.
device	ahd		# AHA39320/29320 and onboard AIC79xx devices
options AHD_REG_PRETTY_PRINT	# Print register bitfields in debug
					# output.  Adds ~215k to driver.

device	mpt		# LSI-Logic MPT-Fusion

# SCSI peripherals
device	scbus		# SCSI bus (required for SCSI)
device	da		# Direct Access (disks)
device	sa		# Sequential Access (tape etc)
device	cd		# CD
device	pass		# Passthrough device (direct SCSI access)
device	ses		# SCSI Environmental Services (and SAF-TE)

# RAID controllers interfaced to the SCSI subsystem
device	asr		# DPT SmartRAID V, VI and Adaptec SCSI RAID

# RAID controllers
device	aac		# Adaptec FSA RAID
device	aacp		# SCSI passthrough for aac (requires CAM)
device	mfi		# LSI MegaRAID SAS
I'm fairly "new" at SCSI configuration. Do I have something conflicted in the preceeding code?

I'm reasonably confident that the controller is functioning as advertised. I've reformatted the drives, created and intialized logical drives (arrays) via the onboard BIOS, verified the drives, etc., still the OS just does not "see" them.

Thank for the suggestions!
 
rtwingfield said:
I'm fairly "new" at SCSI configuration. Do I have something conflicted in the preceeding code?

I'm reasonably confident that the controller is functioning as advertised. I've reformatted the drives, created and intialized logical drives (arrays) via the onboard BIOS, verified the drives, etc., still the OS just does not "see" them.

Thank for the suggestions!

You have a different card from a different manufacturer than what this thread was about, which is what I was responding to.

With that said, you don't need the mpt driver, you need an Adaptec driver. There is nothing special you should have to do other than that.

When you boot the machine, the scsi card should have a setup program...look at you boot messages to see the key sequence to enter it, this is before FreeBSD boots. Once in that setup, there should be diagnostic function to check drives. Do the quick test if available. The longer tests could take 1/2 a day depending on drive size and such.

Make sure you have a terminator on the end of the scsi cable unless you adapter self terminates.
 
RE:
When you boot the machine, the scsi card should have a setup program...look at you boot messages to see the key sequence to enter it, this is before FreeBSD boots. Once in that setup, there should be diagnostic function to check drives. Do the quick test if available. The longer tests could take 1/2 a day depending on drive size and such.

I've already done that. That's what I meant when I previously stated that I'm reasonably sure that the controller is functoning as advertised. I've used the onboard MegaRAID BIOS Conf Utility to reformat, configure (logical drives), initialize, and check consistency. Took almost fifteen hours.

I've executed pciconf -lv and the output reveals:
Code:
vendor     = 'Adapahd0@pci0:3:7:0:	class=0x010000 card=0x13801462 

chip=0x801f9005 rev=0x03 hdr=0x00
    vendor     = 'Adaptec Inc'
    device     = 'Ultra320 SCSI Controller (AIC-7902)'
    class      = mass storage
    subclass   = SCSI
ahd1@pci0:3:7:1:	class=0x010000 card=0x13801462 chip=0x801f9005 rev=0x03 

hdr=0x00
    tec Inc'
    device     = 'Ultra320 SCSI Controller (AIC-7902)'
    class      = mass storage
    subclass   = SCSI
none3@pci0:3:8:0:	class=0x010400 card=0x05201000 chip=0x19601000 rev=0x01 

hdr=0x00
    vendor     = 'LSI Logic (Was: Symbios Logic, NCR)'
    device     = 'MegaRAID'
    class      = mass storage
    subclass   = RAID


From the dmesg.boot file, the following regarding the Adaptec controller:
Code:
ahd0: <Adaptec AIC7902 Ultra320 SCSI adapter> port 0xb000-0xb0ff,0xb400-0xb4ff
 mem 0xf1000000-0xf1001fff irq 24 at device 7.0 on pci3
ahd0: [ITHREAD]
aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI 33 or 66MHz, 512 SCBs
ahd1: <Adaptec AIC7902 Ultra320 SCSI adapter> 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)
pci0: <unknown> at device 2.1 (no driver attached)

The last two lines of the preceeding regarding pci3 and pci0 note
Code:
no driver attached
and obviously suggest a driver problem.

I've specified the custom kernel configuration by stripping down the GENERIC distribution version (as indicated in my previous post above).

I've tried, and if I'm specifying the wrong driver as per
Code:
# SCSI Controllers
device	ahc		        # AHA2940 and onboard AIC7xxx devices
options AHC_REG_PRETTY_PRINT	# Print register bitfields in debug
					# output.  Adds ~128k to driver.
device	ahd		        # AHA39320/29320 and onboard AIC79xx devices
options AHD_REG_PRETTY_PRINT	# Print register bitfields in debug
					# output.  Adds ~215k to driver.
then what should I specify, and where would I find it? The comments in the kernel configuration are from the GENERIC distribution, and suggest that device ahc and ahd are for onboard AIC7xxx devices. My SCSI controllers are 1)an onboard Adaptec AIC 7902 Ultra 320; and 2)a LSI Logic MegaRAID SCSI 320-1 Controller (64bit PCI slot card).

With that said, you don't need the mpt driver, you need an Adaptec driver.

What I have found is that the LSI driver for the AMI MegaRaid family of controllers
Code:
# RAID controllers interfaced to the SCSI subsystem
device		amr		# AMI MegaRAID
should be included in the kernel (see my updated follow-up post below).
 
Roddierrod's question(s) started me thinking about the two different SCSI hardware controllers. The Adaptec 7902 is onboard the m'board. The RAID controller is a LSI Logic MegaRAID SCSI 320-1 Controller (64bit PCI slot card).

For chuckles and grins, I connected the onboard Adaptec 7902 directly to the "RAID cage" and the OS found the five SCSI drives and listed them in /dev as da0 through da4 but with no RAID arrays recognized.

I reconnected the cabling from the RAID controller to the "RAID cage" and I did some homework (a.k.a. as googling) and found the spec sheet for the LSI Logic MegaRAID SCSI 320-1 Controller, plus additional info. regarding drivers for OS'es other than Windows. I did not actually install any downloaded driver from their site, but I did take a look at the code and they describe their driver as a "Driver for the AMI MegaRaid family of controllers". I have no idea what "AMI" stands for, unless it's some bought-out manufacturer's product from (probably) American Megatrends Inc. (think BIOS world); regardless, the little gray cells started itching and I found the FreeBSD GENERIC kernel conf. line of code that spcifies:

Code:
# RAID controllers interfaced to the SCSI subsystem
device		amr		# AMI MegaRAID
. . .so considering that the comment # AMI MegaRAID is associated with the amr device driver (I suppose that that stands for AMI-Mega-RAID . . .who knows . . .how would you know? but it seems to point back to LSI . . .whatever), I added it to the kernel conf., recompiled and the following devices were included in the /dev set: (In my configuration, I've previously configured a RAID 1 and RAID 5 set of logical drives.)
Code:
amr0
amrd0
amrd1
Following up, I've executed bsdlabel -w for amrd0 and amrd1 resulting in the following inclusions in /dev:
Code:
amr0
amrd0
amrd0a
amrd1
amrd1a
I'm not sure what I've accomplished here . . .I haven't been able to mount any thing on them yet, but at least they are recognized by the OS. (I'll come back to this later.)

Let's move on to USB devices, specifically flash drives.

If I boot the system without a USB flash drive plugged in, then there are no devices included in /dev to mount the flash drive, i.e., there is no da0s1 to do something like
Code:
mount -t msdosfs /dev/da0s1 /mnt/usb/UDISK
there is no reference to any USB device in dmesg.boot.

. . .however, if I hot-plug the USB flash drive into the box, then the dmesg.boot file is appended with
Code:
usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored)
usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_STALLED
usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored)
usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_STALLED
usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored)
usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_STALLED
ugen0.2: <Unknown> at usbus0 (disconnected)
uhub_reattach_port: could not allocate new device
and as you might expect, there is no da0s1 in /dev.

If the system is powered down, and subsequently booted with the USB flash drive plugged in, then the system finds the device and the dmesg.boot includes
Code:
ugen0.2: <USB> at usbus0
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
(probe30:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 
(probe30:umass-sim0:0:0:0): CAM status: SCSI Status Error
(probe30:umass-sim0:0:0:0): SCSI status: Check Condition
(probe30:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:28,0
 (Not ready to ready change, medium may have changed)
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)
GEOM: da0: partition 1 does not start on a track boundary.
GEOM: da0: partition 1 does not end on a track boundary.
. . .da0s1 exist in /dev and stuff can be mounted on it.

Why is that?
 
rtwingfield said:
Let's move on to USB devices, specifically flash drives.

If I boot the system without a USB flash drive plugged in, then there are no devices included in /dev to mount the flash drive, i.e., there is no da0s1 to do something like
Code:
mount -t msdosfs /dev/da0s1 /mnt/usb/UDISK
there is no reference to any USB device in dmesg.boot.

. . .however, if I hot-plug the USB flash drive into the box, then the dmesg.boot file is appended with
Code:
usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored)
usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_STALLED
usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored)
usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_STALLED
usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored)
usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_STALLED
ugen0.2: <Unknown> at usbus0 (disconnected)
uhub_reattach_port: could not allocate new device
and as you might expect, there is no da0s1 in /dev.

If the system is powered down, and subsequently booted with the USB flash drive plugged in, then the system finds the device and the dmesg.boot includes
Code:
ugen0.2: <USB> at usbus0
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
(probe30:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 
(probe30:umass-sim0:0:0:0): CAM status: SCSI Status Error
(probe30:umass-sim0:0:0:0): SCSI status: Check Condition
(probe30:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:28,0
 (Not ready to ready change, medium may have changed)
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)
GEOM: da0: partition 1 does not start on a track boundary.
GEOM: da0: partition 1 does not end on a track boundary.
. . .da0s1 exist in /dev and stuff can be mounted on it.

Why is that?

I don't have answer for this, but I can confirm this behavior. It just started for me with 9 RC2, I did not see this on 8.2. I was under the assumption it had something to do with the file system, I see it more with my mp3 player that mounts as a hard drive.
 
1. Personal recommendation: think twice before using a hardware RAID controller to create an array. If the controller dies, the array may not be accessible until another compatible controller is located, and that might take a while.
2. GPT partitions (see gpart(8)) are superior to disklabels.
3. Filesystems have to be formatted before they can be mounted. See newfs(8).
4. The USB memory stick is an unrelated issue which is best addressed in a new thread. Looks to me like it needs a quirk, but that would be best covered in the freebsd-usb mailing list.
 
I cannot boot FreeBSD v8.2 from the SCSI drive(s); however, I can boot from a separate secondary master IDE drive/partition (/dev/ad2s1a) that has FreeBSD v8.2 installed. I can use the AMI BIOS to control the hard disk boot priority sequence. The "GEOM'd" file systems will mount per the following (see below) fstab.

If I take the IDE drive "out of the loop" (via BIOS options), the boot fails with a message that displays "Invalid partition table". In other words, the system is utilizing the IDE drive as a boot device, then it mount the SCSI RAIDs and run from the file systems installed on the SCSI drives.

Is there some other gpart bootcode ...etc that should be installed?

Some additional history and notes:

I have invested some time reading documentation regarding GEOM, and have setup the following RAID 1 mirror by using gmirror and gpart to create partitions (see below) essentially following the instructions of wblock's article, DiskSetup on FreeBSD . . .specifically, the New Alternate Method: gpart (8).

Per wblock's article, I installed the GPT bootcode into the boot partition:

Code:
# gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 da0
bootcode written to da0

Evidence that the partitioning should be OK as follows:

Code:
# gpart show -l /dev/mirror/gm0
=>       34  287274940  mirror/gm0  GPT  (137G)
         34        256           1  gpboot  (128K)
        290       1758              - free -  (879K)
       2048    4194304           2  gprootfs  (2.0G)
    4196352    8388608           3  gpswap  (4.0G)
   12584960  209715200           4  gpvarfs  (100G)
  222300160    2097152           5  gptmpfs  (1.0G)
  224397312   62877662           6  gpusrfs  (30G)

The following devices were created and are found in /dev/gpt:

Code:
0 crw-r-----  1 root  operator    0, 110 Dec 22 18:55 gpboot
0 crw-r-----  1 root  operator    0, 113 Dec 22 18:55 gprootfs
0 crw-r-----  1 root  operator    0, 115 Dec 22 18:55 gpswap
0 crw-r-----  1 root  operator    0, 121 Dec 22 18:55 gptmpfs
0 crw-r-----  1 root  operator    0, 124 Dec 22 18:55 gpusrfs
0 crw-r-----  1 root  operator    0, 118 Dec 22 18:55 gpvarfs



Code:
/etc/fstab 
# Device		Mountpoint	FStype	Options		Dump	Pass#
/dev/gpt/gpswap		none		swap	sw		0	0
/dev/gpt/gprootfs	/		ufs	rw		1	1
/dev/gpt/gptmpfs	/tmp		ufs	rw		2	2
/dev/gpt/gpusrfs	/usr		ufs	rw		2	2
/dev/gpt/gpvarfs	/var		ufs	rw		2	2
/dev/acd0               /cdrom          cd9660	ro,noauto	0	0
 
GPT partitions on top of gmirror(8) are not completely compatible, they both use the last block of the drive. gmirror With Disk Partitions shows how mirrors can be created from GPT partitions. MBR partitioning will work on top of gmirror, since MBR doesn't use the last block of the drive.

As to why it won't boot off the SCSI drives, maybe disabling the IDE controller will do it.
 
And you should install the boot blocks into all drives in the mirror. Just in case the BIOS detects the drive in 1,2 order, but the kernel detects the drives in 2,1 order (which kind of seems to be the case here).

You also want to be able to boot from any drive in the mirror, in case the primary drive fails. If the boot blocks are only installed on 1 drive, and that drive fails ...

Repeat the gpart bootcode install for da1, da2, etc.
 
That's exactly what the problem was. I remembered yesterday morning (after "sleeping on it") that I had installed the boot code on only the first logical mirror and had failed to change the selected bootable logical mirror in the RAID controller's BIOS. I was originally working with logical_1 rather than logical_0. The system now boots from the SCSI system, and as a test, I completely removed the IDE drive from the platform. So far, v8.2 seems to be running well with GEOM architecture including gmirror and gpart.

Actually, I'm going to redo all the partitions and increase the swap space from 4GB (an oversight miscalculation) to 6 on the "main" mirror . . .double the 3GB memory, and certainly install boot-block code on all mirrors.

By the way, re: Warren's suggestion to reconsider using the hard-card RAID controller, I've pursued the installation of the card-controller as an academic exercise.

Thanks to all! Everyone have a safe and happy holiday :)
 
Back
Top