Bug 39447

Summary: 4.5R &4.6R Kernels fail to boot w/ AHA2940U2W attached to an IFT-3102 controller
Product: Base System Reporter: Nick Colakovic <nickc01>
Component: kernAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 4.6-RELEASE   
Hardware: Any   
OS: Any   

Description Nick Colakovic 2002-06-18 00:40:00 UTC
When attempting to boot multiple host systems attached via AHA2940UW's (or the OEM equivalent) to a IFT-3102 controller the kernel locks up in the "Waiting 15 seconds for SCSI devices to settle" phase of the kernel boot process.   This happens with the 4.5R and 4.6R boot floppies, but not with 4.4R.   In addition an upgrade was attempted via a source upgrade from 4.4R to 4.5R.  Despite playing with the kernel config to the system would fail at the same point in the kernel boot process.  Infrotrend (IFT) 3102 is a SCSI-SCSI raid controller that present's its logical RAID disks as conventional SCSI drives to a conventional SCSI HBA.  One indication that the kernel hasn't crashed is that the busy LED on the IFT-3102 stays on after the kernel's  "Waiting 15 seconds for SCSI devices to settle" message appears.   In all test cases no kernel error messages are displayed indicating any problem.

How-To-Repeat: System #1 is:
Intel LG440GX+ MB (Bios 13.0)
2 X P2-450Mhz
1GB ECC PC100 SDRAM
Onboard Adaptec AHA-78xx Ultra/UW controller (UW Channel A attached to IFT-3102, Firmware 2.20S1B1)

System #2 is:
Intel 810E
P3-550E
512MB PC100 SDRAM
Adaptec AHA2940U2W Controller (Firmware 2.20)

Both systems attached to seperate host channels on the IFT-3102.  Both systems boot fine under 4.1R to 4.4R.   Using the 4.5R and 4.6R boot floppies either system will crash the the "Waiting 15 seconds for SCSI devices to settle" phase of the kernel boot process.   The systems will respond that the kernel has no debugger (as these are the generic boot floppy kernels) when the Control-Alt-Escape sequence is pressed.   Despite this the kernel will not move beyond this point (even after several hours).   The only solution for a reboot at this point is a hard reset.   This same sequence of events was found when attempting to upgrade from 4.4R->4.5R via source.
Comment 1 Chris Knight 2002-06-19 13:35:00 UTC
Howdy,

It is probably worthwhile upgrading the firmware on the IFT-3102 if you're
not already running it.
I'd also recommend upgrading all the firmware on the L440GX mainboard (BIOS,
BMC, HSC and FRU/SDR). The order of installation is important - CMOS clear,
then BMC, then HSC, then BIOS, then FRU/SDR, then CMOS clear.
The firmware upgrade will get you a SCSI BIOS of 2.57 from memory.
I had boot issues with ASUS P2B-S attached to an IFT-3102 - I had to enable
interrupts for USB to boot successfully. Might be worth checking.

Regards,
Chris Knight
Systems Administrator
AIMS Independent Computer Professionals
Tel: +61 3 6334 6664  Fax: +61 3 6331 7032  Mob: +61 419 528 795
Web: http://www.aims.com.au
Comment 2 nickc 2002-06-20 20:22:08 UTC
> Can't say I had the geometry change occur when I upgraded 
> about 6 L440GX
> mainboards with the 2.57 SCSI BIOS. Different OSes were on them too - 
> FreeBSD (custom 2.2.8 kernel, 4.x) , NT4 and UnixWare (7.0.1).
> Mind you, I had the advantage of a spare server box to swap in if the
> firmware upgrades got ugly.
> 
> > > I had boot issues with ASUS P2B-S attached to an IFT-3102 - I 
> > > had to enable interrupts for USB to boot successfully. 
> Might be worth
> > > checking.
> > 
> > Will try this as I believe both FreeBSD systems have their USB ports
> > disabled.  Of course this brings up the question of why 
> > changes to the ahc driver are dependant on USB bios settings ;).
> > 
> I don't think it's the ahc driver - it has do to with boot-time device
> probing. I think Mike Smith or Warner Losh mentioned something about
> interrupt masking being the issue.
> 

I did another test based on the above recommendations.   I used a 3rd server
attached to this IFT-3102 that is not quite a critical as the other two.
This is system is another Intel CA810E system that runs NT 4.0.  Upgraded
the Intel CA810E bios to latest version, upgraded the AHA2940U2W to bios
2.57.2.  Enabled the USB ports in the bios, left the IDE primary controller
disabled, secondary IDE enabled (for CD-ROM) and attempted to boot via the
4.6R boot floppies.  Same result, the system does not get past the "Waiting
15 seconds for SCSI devices to settle" phase of the kernel boot. 
	I would be very be inclined to point a finger at the ahc driver
since I have had problems w/ this driver and the IFT-3102 before.  It
consistently has had a minor problem with sending a cache sync command to
the 3102 at shutdown.  I have had to fix this by manually patching the quirk
table in scsi_da.c from the initial install of 4.1R until at least 4.4R.  In
addition there was a problem at some point in 4.3-STABLE that caused
stability problems w/ the IFT-3102.  The fact that I am having this problem
on multiple systems where the only commonality is the use of a Adaptec U2W
controller would point me to this problem.  This is not to say that I have
been unhappy w/ FreeBSD just that the IFT tends to bring out strange
problems in the ahc driver.   

Nick R. Colakovic
Director of I.T.
First Industrial Realty Trust, Inc.
nickc01@corp.firstindustrial.com
Comment 3 nickc 2002-06-21 01:22:30 UTC
> > 2.57.2.  Enabled the USB ports in the bios, left the IDE 
> primary controller
> > disabled, secondary IDE enabled (for CD-ROM) and attempted 
> to boot via the
> > 4.6R boot floppies.
> 
> What do you need the USB ports for?  Why not disable them to remove a
> possible cause of this problem?
> 
That is how these systems are configured by default.  Actually I don't think
I can turn off USB on the Intel CA810E systems.  The kernel configs I use of
these systems don't even include USB at the kernel level.  This was
recommended to me as a solution for a boot problem related to interrupt
masking.  I agree that this was a rather magical attempt at a solution.  

> > Same result, the system does not get past the "Waiting
> > 15 seconds for SCSI devices to settle" phase of the kernel boot. 
> 
> Have you tried a verbose boot?  This would at least let you see
> if the ahc driver is even attempting to talk to the device.
> 
> > 	I would be very be inclined to point a finger at the ahc driver
> > since I have had problems w/ this driver and the IFT-3102 
> before.  It
> > consistently has had a minor problem with sending a cache 
> sync command to
> > the 3102 at shutdown.
> 
> You mean that FreeBSD occasionally complains about the sync 
> cache command
> failing?  This has absolutely nothing to do with the ahc 
> driver.  There
> is some long standing bug in the da driver that causes it to complain
> about sync cache commands failing even though there is code in there
> to be quiet about them.  The quirk table is just a hack around this
> problem that should actually be fixed.  If you could spend a 
> bit of time
> instrumenting the sync cache code in the da driver, you might be able
> to finally fix this bug.  Unfortunately, all of the hardware available
> to the SCSI engineers actually supports the sync cache 
> command correctly.

I stand corrected.  In the past I got the impression this was an problem
related to the ahc driver due to various patches you have provided.

> BTW, if you are using the quirk even though your controller supports
> sync cache, you are removing a very important operation that ensures
> that your data remains valid across a power cycle.

The controller has a NiMH battery designed to store cache information for a
week without power.   Using sync cache is should be irrelevant with the
battery cache.  In addition I disable APM in my kernel configs so the system
is not powering down at shutdown or reboot.
> 
> The disturbing thing about your report is that there are no messages.
> The ahc driver sets a timeout for every command it issues.  Does the
> num lock key toggle when you are in this condition?

Yes, and the kernel debugger does respond (control-alt-escape).  
> Please provide a verbose boot listing.  You may have to use console
> redirection in order to get one.  Many MB bios have this option.

I stand corrected after 10 minutes or so the kernel did boot.   Under 4.5R I
left a system for 2 hours without a successful boot.  4.6R takes about 10
minutes to boot.  I wasn't patient enough to wait this long under 4.6R
assuming (foolishly) that the behavior was the same as in 4.5R.  As a hack I
dropped a 4.6R kernel compiled on another system onto the root of the
existing 4.4R system (so userland is still 4.4R).  Included is a verbose
listing of 4.6R kernel boot of one of the Intel 810E systems:

ok boot -v
SMAP type=01 base=00000000 00000000 len=00000000 0009fc00
SMAP type=02 base=00000000 0009fc00 len=00000000 00000400
SMAP type=02 base=00000000 000e0000 len=00000000 00020000
SMAP type=01 base=00000000 00100000 len=00000000 1fdc0000
SMAP type=03 base=00000000 1fee0000 len=00000000 00018000
SMAP type=04 base=00000000 1fef8000 len=00000000 00008000
SMAP type=03 base=00000000 1fec0000 len=00000000 00020000
SMAP type=02 base=00000000 ffb80000 len=00000000 00080000
SMAP type=02 base=00000000 fff00000 len=00000000 00100000
Copyright (c) 1992-2002 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 4.6-RELEASE #0: Wed Jun 19 08:37:50 CDT 2002
    nickc@vanguard.firstindustrial.com:/usr/obj/usr/src/sys/SSCLEAN.R44
Calibrating clock(s) ... TSC clock: 548295083 Hz, i8254 clock: 1193099 Hz
CLK_USE_I8254_CALIBRATION not specified - using default frequency
Timecounter "i8254"  frequency 1193182 Hz
CLK_USE_TSC_CALIBRATION not specified - using old calibration method
Timecounter "TSC"  frequency 548336026 Hz
CPU: Pentium III/Pentium III Xeon/Celeron (548.34-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x681  Stepping = 1
 
Features=0x387f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,
PAT,PSE36,PN,MMX,FXSR,SSE
>
real memory  = 535560192 (523008K bytes)
Physical memory chunk(s):
0x00001000 - 0x0009efff, 647168 bytes (158 pages)
0x00348000 - 0x1feb7fff, 532086784 bytes (129904 pages)
avail memory = 518295552 (506148K bytes)
bios32: Found BIOS32 Service Directory header at 0xc00fda60
bios32: Entry = 0xfda74 (c00fda74)  Rev = 0  Len = 1
pcibios: PCI BIOS entry at 0xda95
pnpbios: Found PnP BIOS data at 0xc00f2b80
pnpbios: Entry = f0000:243a  Rev = 1.0
Other BIOS signatures found:
ACPI: 000ff980
Preloaded elf kernel "kernel.r46" at 0xc0321000.
Pentium Pro MTRR support enabled
pci_open(1):    mode 1 addr port (0x0cf8) is 0x80000050
pci_open(1a):   mode1res=0x80000000 (0x80000000)
pci_cfgcheck:   device 0 [class=060000] [hdr=00] is there (id=71248086)
Using $PIR table, 10 entries at 0xc00f30f0
npx0: <math processor> on motherboard
npx0: INT 16 interface
pcib0: <Intel 82810E (i810E GMCH) Host To Hub bridge> on motherboard
found-> vendor=0x8086, dev=0x7124, revid=0x03
        class=06-00-00, hdrtype=0x00, mfdev=0
        subordinatebus=0        secondarybus=0
found-> vendor=0x8086, dev=0x7125, revid=0x03
        class=03-00-00, hdrtype=0x00, mfdev=0
        subordinatebus=0        secondarybus=0
        intpin=a, irq=11
        map[10]: type 1, range 32, base f8000000, size 26
        map[14]: type 1, range 32, base ffa80000, size 19
found-> vendor=0x8086, dev=0x2418, revid=0x02
        class=06-04-00, hdrtype=0x01, mfdev=0
        subordinatebus=1        secondarybus=1
found-> vendor=0x8086, dev=0x2410, revid=0x02
        class=06-01-00, hdrtype=0x00, mfdev=1
        subordinatebus=0        secondarybus=0
found-> vendor=0x8086, dev=0x2411, revid=0x02
        class=01-01-80, hdrtype=0x00, mfdev=0
        subordinatebus=0        secondarybus=0
found-> vendor=0x8086, dev=0x2412, revid=0x02
        class=0c-03-00, hdrtype=0x00, mfdev=0
        subordinatebus=0        secondarybus=0
        intpin=d, irq=15
        map[20]: type 1, range 32, base 0000ef80, size  5
found-> vendor=0x8086, dev=0x2413, revid=0x02
        class=0c-05-00, hdrtype=0x00, mfdev=0
        subordinatebus=0        secondarybus=0
        intpin=b, irq=14
        map[20]: type 1, range 32, base 0000efa0, size  4
pci0: <PCI bus> on pcib0
pci0: <Intel 82810E (i810E GMCH) SVGA controller> (vendor=0x8086,
dev=0x7125) at 1.0 irq 11
pcib1: <Intel 82801AA (ICH) Hub to PCI bridge> at device 30.0 on pci0
found-> vendor=0x8086, dev=0x1229, revid=0x08
        class=02-00-00, hdrtype=0x00, mfdev=0
        subordinatebus=0        secondarybus=0
        intpin=a, irq=15
        map[10]: type 1, range 32, base ff8fe000, size 12
        map[14]: type 1, range 32, base 0000df00, size  6
        map[18]: type 1, range 32, base ff700000, size 20
found-> vendor=0x9005, dev=0x0010, revid=0x00
        class=01-00-00, hdrtype=0x00, mfdev=0
        subordinatebus=0        secondarybus=0
        intpin=a, irq=14
        map[10]: type 1, range 32, base 0000d800, size  8
        map[14]: type 1, range 64, base ff8ff000, size 12
pci1: <PCI bus> on pcib1
fxp0: <Intel Pro 10/100B/100+ Ethernet> port 0xdf00-0xdf3f mem
0xff700000-0xff7fffff,0xff8fe000-0xff8fe
fff irq 15 at device 1.0 on pci1
fxp0: using memory space register mapping
fxp0: Ethernet address 00:03:47:06:d6:84
fxp0: PCI IDs: 8086 1229 8086 3000 0008
fxp0: Dynamic Standby mode is disabled
inphy0: <i82555 10/100 media interface> on miibus0
inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ahc0: <Adaptec 2940 Ultra2 SCSI adapter> port 0xd800-0xd8ff mem
0xff8ff000-0xff8fffff irq 14 at device 
9.0 on pci1
ahc0: Reading SEEPROM...done.
ahc0: BIOS eeprom is present
ahc0: Secondary High byte termination Enabled
ahc0: Secondary Low byte termination Enabled
ahc0: Primary Low Byte termination Enabled
ahc0: Primary High Byte termination Enabled
ahc0: Downloading Sequencer Program... 422 instructions downloaded
aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs
isab0: <Intel 82801AA (ICH) PCI to LPC bridge> at device 31.0 on pci0
isa0: <ISA bus> on isab0
pci0: <Unknown PCI ATA controller> (vendor=0x8086, dev=0x2411) at 31.1
pci0: <Intel 82801AA (ICH) USB controller> (vendor=0x8086, dev=0x2412) at
31.2 irq 15
pci0: <unknown card> (vendor=0x8086, dev=0x2413) at 31.3 irq 14
Trying Read_Port at 203
Trying Read_Port at 243
Trying Read_Port at 283
Trying Read_Port at 2c3
Trying Read_Port at 303
Trying Read_Port at 343
Trying Read_Port at 383
Trying Read_Port at 3c3
isa_probe_children: disabling PnP devices
isa_probe_children: probing non-PnP devices
orm0: <Option ROMs> at iomem
0xc0000-0xcbfff,0xcc000-0xccfff,0xcd000-0xd27ff,0xd2800-0xd37ff on isa0
fdc0: <NEC 72065B or clone> at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
atkbd0: <AT Keyboard> flags 0x1 irq 1 on atkbdc0
atkbd: the current kbd controller command byte 0065
atkbd: keyboard ID 0x41ab (2)
kbdc: RESET_KBD return code:00fa
kbdc: RESET_KBD status:00aa
kbd0 at atkbd0
kbd0: atkbd0, AT 101/102 (2), config:0x1, flags:0x1d0000
psm0: current command byte:0065
kbdc: TEST_AUX_PORT status:0000
kbdc: RESET_AUX return code:00fa
kbdc: RESET_AUX status:00aa
kbdc: RESET_AUX ID:0000
psm: status 00 03 28
psm: status 90 03 3c
psm: status 90 03 3c
psm: status 90 03 3c
psm: data 08 00 00
psm: data 08 00 00
psm: status 00 03 28
psm0: <PS/2 Mouse> irq 12 on atkbdc0
psm0: model IntelliMouse, device ID 3-00, 3 buttons
psm0: config:00000000, flags:00000000, packet size:4
psm0: syncmask:08, syncbits:08
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
fb0: vga0, vga, type:VGA (5), flags:0x7007f
fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000
fb0: init mode:24, bios mode:3, current mode:24
fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k
VGA parameters upon power-up
50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81 
bf 1f 00 4f 0d 0e 00 00 04 60 9c 8e 8f 28 1f 96 
b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 
3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff 
VGA parameters in BIOS for mode 24
50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 
bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 
b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 
3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff 
EGA/VGA parameters to be used for mode 24
50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 
bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 
b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 
3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff 
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x100>
sc0: fb0, kbd0, terminal emulator: sc (syscons terminal)
sio0: irq maps: 0x41 0x51 0x41 0x41
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A, console
sio1: irq maps: 0x41 0x49 0x41 0x41
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
ppc0: parallel port found at 0x378
ppc0: using extended I/O port range
ppc0: EPP SPP
ppc0: <Parallel port> at port 0x378-0x37f irq 7 on isa0
ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode
lpt0: <Printer> on ppbus0
lpt0: Interrupt-driven port
ppi0: <Parallel I/O> on ppbus0
isa_probe_children: probing PnP devices
BIOS Geometries:
 0:03fe3f20 0..1022=1023 cylinders, 0..63=64 heads, 1..32=32 sectors
 0 accounted for
Device configuration finished.
Waiting 15 seconds for SCSI devices to settle
(noperiph:ahc0:0:-1:-1): SCSI bus reset delivered. 0 SCBs aborted.
(ahc0:A:0:0): Sending WDTR 1
(ahc0:A:0:0): Received WDTR 1 filtered to 1
ahc0: target 0 using 16bit transfers
(ahc0:A:0:0): Sending SDTR period a, offset 7f
(ahc0:A:0:0): Received SDTR period a, offset 1f
        Filtered to period a, offset 1f
ahc0: target 0 synchronous at 40.0MHz, offset = 0x1f
(ahc0:A:0:1): Sending WDTR 1
(ahc0:A:0:1): Received WDTR 1 filtered to 1
ahc0: target 0 using asynchronous transfers
(ahc0:A:0:1): Sending SDTR period a, offset 1f
(ahc0:A:0:1): Received SDTR period a, offset 1f
        Filtered to period a, offset 1f
ahc0: target 0 synchronous at 40.0MHz, offset = 0x1f
(ahc0:A:0:1): Sending WDTR 1
(ahc0:A:0:1): Received WDTR 1 filtered to 1
ahc0: target 0 using asynchronous transfers
(ahc0:A:0:1): Sending SDTR period a, offset 7f
(ahc0:A:0:1): Received SDTR period a, offset 1f
        Filtered to period a, offset 1f
ahc0: target 0 synchronous at 40.0MHz, offset = 0x1f
(ahc0:A:0:2): Sending WDTR 1
(ahc0:A:0:2): Received WDTR 1 filtered to 1
ahc0: target 0 using asynchronous transfers
(ahc0:A:0:2): Sending SDTR period a, offset 1f
(ahc0:A:0:2): Received SDTR period a, offset 1f
        Filtered to period a, offset 1f
ahc0: target 0 synchronous at 40.0MHz, offset = 0x1f

The messages continued in a loop for 10 minutes or so then:

        Filtered to period a, offset 1f
ahc0: target 0 synchronous at 40.0MHz, offset = 0x1f
(ahc0:A:0:7): Sending WDTR 1
(ahc0:A:0:7): Received WDTR 1 filtered to 1
ahc0: target 0 using asynchronous transfers
(ahc0:A:0:7): Sending SDTR period a, offset 1f
(ahc0:A:0:7): Received SDTR period a, offset 1f
        Filtered to period a, offset 1f
ahc0: target 0 synchronous at 40.0MHz, offset = 0x1f
(probe0:ahc0:0:0:7): Vendor Specific Command. CDB: 1a e0 a 0 14 0 
(probe0:ahc0:0:0:7): NOT READY asc:4,0
(probe0:ahc0:0:0:7): Logical unit not ready, cause not reportable
(ahc0:A:0:7): Sending WDTR 1
(ahc0:A:0:7): Received WDTR 1 filtered to 1
ahc0: target 0 using asynchronous transfers
(ahc0:A:0:7): Sending SDTR period a, offset 7f
(ahc0:A:0:7): Received SDTR period a, offset 1f
        Filtered to period a, offset 1f
ahc0: target 0 synchronous at 40.0MHz, offset = 0x1f
(ahc0:A:0:7): Sending WDTR 1
(ahc0:A:0:7): Received WDTR 1 filtered to 1
ahc0: target 0 using asynchronous transfers
(ahc0:A:0:7): Sending SDTR period a, offset 1f
(ahc0:A:0:7): Received SDTR period a, offset 1f
        Filtered to period a, offset 1f
ahc0: target 0 synchronous at 40.0MHz, offset = 0x1f
Creating DISK da0
Creating DISK da1
pass0 at ahc0 bus 0 target 0 lun 0
pass0: <IFT 3102 0223> Fixed Direct Access SCSI-2 device 
pass0: Serial Number  3132729        
pass0: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing
Enabled
pass1 at ahc0 bus 0 target 0 lun 1
pass1: <IFT 3102 0223> Fixed Direct Access SCSI-2 device 
pass1: Serial Number  3132729        
pass1: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing
Enabled
pass2 at ahc0 bus 0 target 0 lun 2
pass2: <IFT 3102 0223> Fixed unknown SCSI-2 device 
pass2: Serial Number  3132729        
pass2: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing
Enabled
pass3 at ahc0 bus 0 target 0 lun 3
pass3: <IFT 3102 0223> Fixed unknown SCSI-2 device 
pass3: Serial Number  3132729        
pass3: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing
Enabled
pass4 at ahc0 bus 0 target 0 lun 4
pass4: <IFT 3102 0223> Fixed unknown SCSI-2 device 
pass4: Serial Number  3132729        
pass4: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing
Enabled
pass5 at ahc0 bus 0 target 0 lun 5
pass5: <IFT 3102 0223> Fixed unknown SCSI-2 device 
pass5: Serial Number  3132729        
pass5: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing
Enabled
pass6 at ahc0 bus 0 target 0 lun 6
pass6: <IFT 3102 0223> Fixed unknown SCSI-2 device 
pass6: Serial Number  3132729        
pass6: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing
Enabled
pass7 at ahc0 bus 0 target 0 lun 7
pass7: <IFT 3102 0223> Fixed unknown SCSI-2 device 
pass7: Serial Number  3132729        
pass7: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing
Enabled
pass2 at ahc0 bus 0 target 0 lun 2
pass2: <IFT 3102 0223> Fixed unknown SCSI-2 device 
pass2: Serial Number  3132729        
pass2: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing
Enabled
pass3 at ahc0 bus 0 target 0 lun 3
pass3: <IFT 3102 0223> Fixed unknown SCSI-2 device 
pass3: Serial Number  3132729        
pass3: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing
Enabled
pass4 at ahc0 bus 0 target 0 lun 4
pass4: <IFT 3102 0223> Fixed unknown SCSI-2 device 
pass4: Serial Number  3132729        
pass4: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing
Enabled
pass5 at ahc0 bus 0 target 0 lun 5
pass5: <IFT 3102 0223> Fixed unknown SCSI-2 device 
pass5: Serial Number  3132729        
pass5: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing
Enabled
pass6 at ahc0 bus 0 target 0 lun 6
pass6: <IFT 3102 0223> Fixed unknown SCSI-2 device 
pass6: Serial Number  3132729        
pass6: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing
Enabled
pass7 at ahc0 bus 0 target 0 lun 7
pass7: <IFT 3102 0223> Fixed unknown SCSI-2 device 
pass7: Serial Number  3132729        
pass7: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing
Enabled
da0 at ahc0 bus 0 target 0 lun 0
da0: <IFT 3102 0223> Fixed Direct Access SCSI-2 device 
da0: Serial Number  3132729        
da0: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing
Enabled
da0: 4096MB (8388608 512 byte sectors: 64H 32S/T 4096C)
da1 at ahc0 bus 0 target 0 lun 1
da1: <IFT 3102 0223> Fixed Direct Access SCSI-2 device 
da1: Serial Number  3132729        
da1: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing
Enabled
da1: 4096MB (8388608 512 byte sectors: 64H 32S/T 4096C)
Mounting root from ufs:/dev/da0s1a
da0s1: type 0xa5, start 32, end = 8388607, size 8388576 : OK
start_init: trying /sbin/init
swapon: adding /dev/da0s1b as swap device
Automatic boot in progress...
/dev/da0s1a: FILESYSTEM CLEAN; SKIPPING CHECKS
/dev/da0s1a: clean, 101488 free (424 frags, 12633 blocks, 0.3d%
fragmentation)a
1s1: type 0xa5, start 32, end = 8388607, size 8388576 : OK
/dev/da0s1g: FILESYSTEM CLEAN; SKIPPING CHECKS
1dev/da0s1g: dclean, 988371 fraee (3 frags, 1231546 blocks, 0.0%s
fragmentation)
t/dev/da1s1e: FI:LESYSTEM CLEAN;  SKIPPING CHECKS
 /dev/da1s1e: clyean, 1692160 frepe (3264 frags, 2e11112 blocks, 0. 2%
fragmentation0)
xa5, start 32, end = 8388607, size 8388576 : OK
/dev/da0s1f: FILESYSTEM CLEAN; SKIPPING CHECKS
/dev/da0s1f: clean, 774811 free (31355 frags, 92932 blocks, 1.5%
fragmentation)
/dev/da1s1f: FILESYSTEM CLEAN; SKIPPING CHECKS
/dev/da1s1f: clean, 2032379 free (19 frags, 254045 blocks, 0.0%
fragmentation)
/dev/da0s1e: FILESYSTEM CLEAN; SKIPPING CHECKS
/dev/da0s1e: clean, 128301 free (205 frags, 16012 blocks, 0.0%
fragmentation)
da1s1: type 0xa5, start 32, end = 8388607, size 8388576 : OK
Doing initial network setup: hostname.
fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 172.16.0.22 netmask 0xffffe000 broadcast 172.16.31.255
        ether 00:03:47:06:d6:84 
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
        inet 127.0.0.1 netmask 0xff000000 
add net default: gateway 172.16.0.1
Additional routing options: TCP keepalive=YES.
Routing daemons:.
Additional daemons: syslogd.
Doing additional network setup: ntpd.
Starting final network daemons:.
ELF ldconfig path: /usr/lib /usr/lib/compat /usr/local/lib
a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout
Starting standard daemons: inetd cron sshd sendmail.
Recovering vi editor sessions:.
Initial rc.i386 initialization:.
Configuring syscons: blank_timevidcontrol: must be on a virtual console:
Inappropriate ioctl for device
.
Additional ABI support:.
Local package initialization:Starting Backup Express client

 apache apcupsdbkpupsd  mysqldStarting Netsaint service: 
This account is currently not available.
  PID  TT  STAT      TIME COMMAND
  874  ??  Rs     0:00.46 /a/services/netsaint/bin/netsaint -d
/a/services/nets
 Sambapostfix/postfix-script: starting the Postfix mail system
 snmpd.
Additional TCP options:.

Thu Jun 20 18:44:24 CDT 2002

FreeBSD/i386 (pariah.firstindustrial.com) (console)

login: 

The system that was used for this boot has IDE, sound, and APM features
disabled.  The controller is a AHA-2940U2W with 2.20 firmware.  I only have
2 luns mapped to this system, I don't know exactly why the pass* devices are
being found.   The WinNT 4.0 system on this same controller has the RAID
management GUI loaded.  Infortrend provides a GUI for inband management of
the controller (which only runs on Windows NT4/2K and Solaris).  They
require that the controller's "Peripheral Device Type" parameter to be set
to "0x1f" if the managing system is WinNT 4.0.  I am guessing here but is
seems that the controller is using passthrough devices to communicate w/ the
GUI that FreeBSD doesn't like.  I will try to change the Infortrend's
Peripheral Device Type parameter to the default of "0x7f" and retry. The
config file for the kernel in question is:


machine		i386
#cpu		I386_CPU
#cpu		I486_CPU
#cpu		I586_CPU
cpu		I686_CPU
ident		SSCLEAN
maxusers	64

makeoptions	DEBUG=-g		#Build kernel with gdb(1) debug
symbols

#options 	MATH_EMULATE		#Support for x87 emulation
options 	INET			#InterNETworking
#options 	INET6			#IPv6 communications protocols
options 	FFS			#Berkeley Fast Filesystem
options 	FFS_ROOT		#FFS usable as root device [keep
this!]
options 	SOFTUPDATES		#Enable FFS soft updates support
options         UFS_DIRHASH		#Enable Directory Hashing
#options 	MFS			#Memory Filesystem
#options 	MD_ROOT			#MD is a potential root device
options 	NFS			#Network Filesystem
#options 	NFS_ROOT		#NFS usable as root device, NFS
required
options 	MSDOSFS			#MSDOS Filesystem
options 	CD9660			#ISO 9660 Filesystem
#options 	CD9660_ROOT		#CD-ROM usable as root, CD9660
required
options 	PROCFS			#Process filesystem
options 	COMPAT_43		#Compatible with BSD 4.3 [KEEP
THIS!]
options 	SCSI_DELAY=15000	#Delay (in ms) before probing SCSI
options 	UCONSOLE		#Allow users to grab the console
options 	USERCONFIG		#boot -c editor
options 	VISUAL_USERCONFIG	#visual boot -c editor
options 	KTRACE			#ktrace(1) support
options 	SYSVSHM			#SYSV-style shared memory
options 	SYSVMSG			#SYSV-style message queues
options 	SYSVSEM			#SYSV-style semaphores
options 	P1003_1B		#Posix P1003_1B real-time extensions
options 	_KPOSIX_PRIORITY_SCHEDULING
options		ICMP_BANDLIM		#Rate limit bad replies
options 	KBD_INSTALL_CDEV	# install a CDEV entry in /dev
# Tweak Shared Memory for Squid

#options         MSGMNB=16384    # max # of bytes in a queue
#options         MSGMNI=41       # number of message queue identifiers
#options         MSGSEG=2049     # number of message segments
#options         MSGSSZ=64       # size of a message segment
#options         MSGTQL=512      # max messages in system


# To make an SMP kernel, the next two are needed
#options 	SMP			# Symmetric MultiProcessor Kernel
#options 	APIC_IO			# Symmetric (APIC) I/O

device		isa
#device		eisa
device		pci

# Floppy drives
device		fdc0	at isa? port IO_FD1 irq 6 drq 2
device		fd0	at fdc0 drive 0
device		fd1	at fdc0 drive 1
#
# If you have a Toshiba Libretto with its Y-E Data PCMCIA floppy,
# don't use the above line for fdc0 but the following one:
#device		fdc0

# ATA and ATAPI devices
#device		ata0	at isa? port IO_WD1 irq 14
#device		ata1	at isa? port IO_WD2 irq 15
#device		ata
#device		atadisk			# ATA disk drives
#device		atapicd			# ATAPI CDROM drives
#device		atapifd			# ATAPI floppy drives
#device		atapist			# ATAPI tape drives
#options 	ATA_STATIC_ID		#Static device numbering

# SCSI Controllers
#device		ahb		# EISA AHA1742 family
device		ahc		# AHA2940 and onboard AIC7xxx devices
#device		amd		# AMD 53C974 (Tekram DC-390(T))
#device		isp		# Qlogic family
#device		ncr		# NCR/Symbios Logic
#device		sym		# NCR/Symbios Logic (newer chipsets)
#options		SYM_SETUP_LP_PROBE_MAP=0x40
				# Allow ncr to attach legacy NCR devices
when 
				# both sym and ncr are configured

#device		adv0	at isa?
#device		adw
#device		bt0	at isa?
#device		aha0	at isa?
#device		aic0	at isa?

#device		ncv		# NCR 53C500
#device		nsp		# Workbit Ninja SCSI-3
#device		stg		# TMC 18C30/18C50

# SCSI peripherals
device		scbus		# SCSI bus (required)
device		da		# Direct Access (disks)
device		sa		# Sequential Access (tape etc)
device		cd		# CD
device		pass		# Passthrough device (direct SCSI access)

# RAID controllers interfaced to the SCSI subsystem
#device		asr		# DPT SmartRAID V, VI and Adaptec SCSI RAID
#device		dpt		# DPT Smartcache - See LINT for options!
#device		mly		# Mylex AcceleRAID/eXtremeRAID

# RAID controllers
#device		aac		# Adaptec FSA RAID, Dell PERC2/PERC3
#device		ida		# Compaq Smart RAID
#device		amr		# AMI MegaRAID
#device		mlx		# Mylex DAC960 family
#device		twe		# 3ware Escalade

# atkbdc0 controls both the keyboard and the PS/2 mouse
device		atkbdc0	at isa? port IO_KBD
device		atkbd0	at atkbdc? irq 1 flags 0x1
device		psm0	at atkbdc? irq 12

device		vga0	at isa?

# splash screen/screen saver
#pseudo-device	splash

# syscons is the default console driver, resembling an SCO console
device		sc0	at isa? flags 0x100

# Enable this and PCVT_FREEBSD for pcvt vt220 compatible console driver
#device		vt0	at isa?
#options 	XSERVER			# support for X server on a vt
console
#options 	FAT_CURSOR		# start with block cursor
# If you have a ThinkPAD, uncomment this along with the rest of the PCVT
lines
#options 	PCVT_SCANSET=2		# IBM keyboards are non-std

# Floating point support - do not disable.
device		npx0	at nexus? port IO_NPX irq 13

# Power management support (see LINT for more options)
#device		apm0    at nexus? disable flags 0x20 # Advanced Power
Management

# PCCARD (PCMCIA) support
#device		card
#device		pcic0	at isa? irq 0 port 0x3e0 iomem 0xd0000
#device		pcic1	at isa? irq 0 port 0x3e2 iomem 0xd4000 disable

# Serial (COM) ports
device		sio0	at isa? port IO_COM1 flags 0x10 irq 4
device		sio1	at isa? port IO_COM2 irq 3
#device		sio2	at isa? disable port IO_COM3 irq 5
#device		sio3	at isa? disable port IO_COM4 irq 9

# Parallel port
device		ppc0	at isa? irq 7
device		ppbus		# Parallel port bus (required)
device		lpt		# Printer
#device		plip		# TCP/IP over parallel
device		ppi		# Parallel port interface device
#device		vpo		# Requires scbus and da


# PCI Ethernet NICs.
device		de		# DEC/Intel DC21x4x (``Tulip'')
#device		txp		# 3Com 3cR990 (``Typhoon'')
device		vx		# 3Com 3c590, 3c595 (``Vortex'')

# PCI Ethernet NICs that use the common MII bus controller code.
# NOTE: Be sure to keep the 'device miibus' line in order to use these NICs!
device		miibus		# MII bus support
#device		dc		# DEC/Intel 21143 and various workalikes
device		fxp		# Intel EtherExpress PRO/100B (82557, 82558)
#device		pcn		# AMD Am79C97x PCI 10/100 NICs
#device		rl		# RealTek 8129/8139
#device		sf		# Adaptec AIC-6915 (``Starfire'')
#device		sis		# Silicon Integrated Systems SiS 900/SiS
7016
#device		ste		# Sundance ST201 (D-Link DFE-550TX)
#device		tl		# Texas Instruments ThunderLAN
#device		tx		# SMC EtherPower II (83c170 ``EPIC'')
#device		vr		# VIA Rhine, Rhine II
#device		wb		# Winbond W89C840F
#device		wx		# Intel Gigabit Ethernet Card (``Wiseman'')
device		xl		# 3Com 3c90x (``Boomerang'', ``Cyclone'')

# ISA Ethernet NICs.
# 'device ed' requires 'device miibus'
#device		ed0	at isa? port 0x280 irq 10 iomem 0xd8000
#device		ex
#device		ep
#device		fe0	at isa? port 0x300
# Xircom Ethernet
#device		xe
# PRISM I IEEE 802.11b wireless NIC.
#device		awi
# WaveLAN/IEEE 802.11 wireless NICs. Note: the WaveLAN/IEEE really
# exists only as a PCMCIA device, so there is no ISA attachment needed
# and resources will always be dynamically assigned by the pccard code.
#device		wi
# Aironet 4500/4800 802.11 wireless NICs. Note: the declaration below will
# work for PCMCIA and PCI cards, as well as ISA cards set to ISA PnP
# mode (the factory default). If you set the switches on your ISA
# card for a manually chosen I/O address and IRQ, you must specify
# those parameters here.
#device		an
# The probe order of these is presently determined by i386/isa/isa_compat.c.
#device		ie0	at isa? port 0x300 irq 10 iomem 0xd0000
#device		le0	at isa? port 0x300 irq 5 iomem 0xd0000
#device		lnc0	at isa? port 0x280 irq 10 drq 0
#device		cs0	at isa? port 0x300
#device		sn0	at isa? port 0x300 irq 10

# Pseudo devices - the number indicates how many units to allocate.
pseudo-device	loop		# Network loopback
pseudo-device	ether		# Ethernet support
#pseudo-device	sl	1	# Kernel SLIP
#pseudo-device	ppp	1	# Kernel PPP
#pseudo-device	tun		# Packet tunnel.
pseudo-device	pty		# Pseudo-ttys (telnet etc)
#pseudo-device	md		# Memory "disks"
#pseudo-device	gif		# IPv6 and IPv4 tunneling
#pseudo-device	faith	1	# IPv6-to-IPv4 relaying (translation)

# The `bpf' pseudo-device enables the Berkeley Packet Filter.
# Be aware of the administrative consequences of enabling this!
#pseudo-device	bpf		#Berkeley packet filter

# USB support
#device		uhci		# UHCI PCI->USB interface
#device		ohci		# OHCI PCI->USB interface
#device		usb		# USB Bus (required)
#device		ugen		# Generic
#device		uhid		# "Human Interface Devices"
#device		ukbd		# Keyboard
#device		ulpt		# Printer
#device		umass		# Disks/Mass storage - Requires scbus and da
#device		ums		# Mouse
#device		uscanner	# Scanners
# USB Ethernet, requires mii
#device		aue		# ADMtek USB ethernet
#device		cue		# CATC USB ethernet
#device		kue		# Kawasaki LSI USB ethernet

options         DDB
Comment 4 nickc 2002-06-21 02:20:08 UTC
I think I have been able to isolate the issue.   If the IFT-3102 is set with
it "Peripheral Device Type" parameter set to "0x1f" the 4.6R kernel is
delayed in booting by about 10 minutes in my environment.  This seems to be
because the ahc driver seems to be scanning the pseudo devices the
controller presents to its hosts to allow inband controller management and
monitoring.  Without looking the ahc sources I assume the driver paces the
scan of these devices in such a way to cause a fairly long boot delay.
	If I set the "Peripheral Device Type" parameter to the default of
"0x7f" (No Device Present according to the manual) the kernel boots
normally.   The setting of 0x1f is required if the managing system attached
to the controller is running Windows NT 4.0.  So is appears the problem can
be classified as an environment specific bug or problem (depending on your
point of view) when running a mix of OSes on the same IFT-3102 controller.
Loss of GUI management of the controller is not a problem because I
typically manage it from it serial interface anyhow.  Of course patience on
my part might have isolated the problem earlier.   I will recompile sources
on both affected systems and confirm that this 0x7f solution actually works.
Thanks for the assistance and recommendations.

	-NRC
Comment 5 Justin T. Gibbs 2002-06-21 12:33:24 UTC
>> BTW, if you are using the quirk even though your controller supports
>> sync cache, you are removing a very important operation that ensures
>> that your data remains valid across a power cycle.
>
>The controller has a NiMH battery designed to store cache information for a
>week without power.   Using sync cache is should be irrelevant with the
>battery cache.  In addition I disable APM in my kernel configs so the system
>is not powering down at shutdown or reboot.

Until you decide to change out the battery because it has failed its last
reconditioning - or you ship the box to a trade show only to find that
the batter is dead and your FS trashed.  They don't call it batter
"backup" for nothing.

>I stand corrected after 10 minutes or so the kernel did boot.

...

>ahc0: target 0 synchronous at 40.0MHz, offset = 0x1f
>(probe0:ahc0:0:0:7): Vendor Specific Command. CDB: 1a e0 a 0 14 0 
>(probe0:ahc0:0:0:7): NOT READY asc:4,0
>(probe0:ahc0:0:0:7): Logical unit not ready, cause not reportable

...

Again, this has absolutly nothing to do with the ahc driver.  Think of
the ahc driver as a "conduit" for SCSI commands.  The ahc driver doesn't
build commands or even understand what they mean.  It just delivers them to
the device and reports the result.  In this case, the infotrend is reporting
"not ready" to a perfectly valid command CAM issues during the probing
of devices.  If you hand't compiled your kernel without cdb strings,
the above message would indicate a standard MODE_SENSE_6 (CAM is trying
to determine if tag queueing has been disabled in a mode page).  Anyway,
"LUN not ready" type errors are usually transient.  CAM is waiting for
this error to go away.  CAM eventually gives up to the tune of aproximately 
1 minute for each LUN that reports this error.   When you change the
peripheral type to 0x7F, CAM ignores the device, since 0x7F in the
inquiry response means "device not present".  Perhaps you should ask
Infotrend why they constantly give not ready status for these devices.

--
Justin
Comment 6 Jens Schweikhardt freebsd_committer freebsd_triage 2003-07-19 18:45:44 UTC
State Changed
From-To: open->feedback

According to Justin this seems more like a problem of the SCSI target 
hardware. Is there any new insight or can we close this PR?
Comment 7 Jens Schweikhardt freebsd_committer freebsd_triage 2003-07-28 19:44:24 UTC
State Changed
From-To: feedback->closed

Closed after confirmation of submitter: 

The issue was related to the CAM layer probing the device's management 
interface (which is exposed as at the lun level) and taking 15-20 
minutes to timeout (under 4.6R). Disabling the management interface 
resolved the issue, but prevents the use the win32 based management 
console. I will note that this behavior has not been seen on the AIX 
and WinNT systems that we run with identical target disk arrays 
(meaning identical IFT-3102 controller and controller firmware).