I've tried this one on linux-scsi but to no avail, here is a resend to
lkml.
I have a dell poweredge 1650 with a perc3/DI raid controller. When the
AACRAID driver loads it prints the following lines:
AAC0: kernel 2.7.4 build 3170
AAC0: monitor 2.7.4 build 3170
AAC0: bios 2.7.0 build 3170
AAC0: serial 0b9c810d3
scsi0 : percraid
And then there is a complete freeze. I don't know if sysrq isn't
initialized at this time, but it doesn't work ;) Anybody know what's
going on?
My config file looks like this:
============================================================
#
# Automatically generated make config: don't edit
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_SWAP=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
#
# General setup
#
CONFIG_SYSVIPC=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
CONFIG_LOG_BUF_SHIFT=14
#
# Loadable module support
#
# CONFIG_MODULES is not set
#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
CONFIG_MPENTIUMIII=y
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MELAN is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_TSC=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_PREFETCH=y
CONFIG_HUGETLB_PAGE=y
CONFIG_SMP=y
# CONFIG_PREEMPT is not set
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_NR_CPUS=32
# CONFIG_X86_MCE is not set
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set
# CONFIG_EDD is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
# CONFIG_MTRR is not set
CONFIG_HAVE_DEC_LOCK=y
#
# Power management options (ACPI, APM)
#
# CONFIG_PM is not set
#
# ACPI Support
#
# CONFIG_ACPI is not set
#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set
#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
# CONFIG_SCx200 is not set
CONFIG_PCI_LEGACY_PROC=y
CONFIG_PCI_NAMES=y
# CONFIG_ISA is not set
# CONFIG_MCA is not set
# CONFIG_HOTPLUG is not set
#
# Executable file formats
#
CONFIG_KCORE_ELF=y
# CONFIG_KCORE_AOUT is not set
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=y
#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set
#
# Parallel port support
#
# CONFIG_PARPORT is not set
#
# Plug and Play support
#
# CONFIG_PNP is not set
#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_NBD is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
# CONFIG_LBD is not set
#
# ATA/ATAPI/MFM/RLL device support
#
# CONFIG_IDE is not set
#
# SCSI device support
#
CONFIG_SCSI=y
#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
CONFIG_CHR_DEV_SG=y
#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_REPORT_LUNS=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
#
# SCSI low-level drivers
#
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_ACARD is not set
CONFIG_SCSI_AACRAID=y
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_IN2000 is not set
# CONFIG_SCSI_AM53C974 is not set
# CONFIG_SCSI_MEGARAID is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_CPQFCTS is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_PIO is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_GENERIC_NCR5380 is not set
# CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_NCR53C7xx is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_NCR53C8XX is not set
# CONFIG_SCSI_SYM53C8XX is not set
# CONFIG_SCSI_PCI2000 is not set
# CONFIG_SCSI_PCI2220I is not set
# CONFIG_SCSI_QLOGIC_ISP is not set
CONFIG_SCSI_QLOGIC_FC=y
# CONFIG_SCSI_QLOGIC_FC_FIRMWARE is not set
CONFIG_SCSI_QLOGIC_1280=y
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_U14_34F is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set
#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set
#
# Fusion MPT device support
#
# CONFIG_FUSION is not set
#
# IEEE 1394 (FireWire) support (EXPERIMENTAL)
#
# CONFIG_IEEE1394 is not set
#
# I2O device support
#
# CONFIG_I2O is not set
#
# Networking support
#
CONFIG_NET=y
#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
# CONFIG_NETLINK_DEV is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_FILTER=y
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
CONFIG_INET_ECN=y
CONFIG_SYN_COOKIES=y
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_XFRM_USER is not set
#
# IP: Netfilter Configuration
#
# CONFIG_IP_NF_CONNTRACK is not set
# CONFIG_IP_NF_QUEUE is not set
# CONFIG_IP_NF_IPTABLES is not set
# CONFIG_IP_NF_ARPTABLES is not set
# CONFIG_IP_NF_COMPAT_IPCHAINS is not set
# CONFIG_IP_NF_COMPAT_IPFWADM is not set
# CONFIG_IPV6 is not set
#
# SCTP Configuration (EXPERIMENTAL)
#
CONFIG_IPV6_SCTP__=y
# CONFIG_IP_SCTP is not set
# CONFIG_ATM is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_LLC is not set
# CONFIG_DECNET is not set
# CONFIG_BRIDGE is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_FASTROUTE is not set
# CONFIG_NET_HW_FLOWCONTROL is not set
#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
CONFIG_NETDEVICES=y
#
# ARCnet devices
#
# CONFIG_ARCNET is not set
CONFIG_DUMMY=y
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_ETHERTAP is not set
#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
# CONFIG_MII is not set
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
CONFIG_NET_VENDOR_3COM=y
CONFIG_VORTEX=y
# CONFIG_TYPHOON is not set
#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_B44 is not set
# CONFIG_DGRS is not set
# CONFIG_EEPRO100 is not set
CONFIG_E100=y
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_8139CP is not set
# CONFIG_8139TOO is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set
#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
CONFIG_E1000=y
# CONFIG_E1000_NAPI is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SK98LIN is not set
# CONFIG_TIGON3 is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set
#
# Token Ring devices (depends on LLC=y)
#
CONFIG_NET_FC=y
# CONFIG_IPHASE5526 is not set
# CONFIG_RCPCI is not set
# CONFIG_SHAPER is not set
#
# Wan interfaces
#
# CONFIG_WAN is not set
#
# Amateur Radio support
#
# CONFIG_HAMRADIO is not set
#
# IrDA (infrared) support
#
# CONFIG_IRDA is not set
#
# ISDN subsystem
#
# CONFIG_ISDN_BOOL is not set
#
# Telephony Support
#
# CONFIG_PHONE is not set
#
# Input device support
#
CONFIG_INPUT=y
#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set
#
# Input I/O drivers
#
# CONFIG_GAMEPORT is not set
CONFIG_SOUND_GAMEPORT=y
# CONFIG_SERIO is not set
#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_INPUT_MOUSE=y
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=y
# CONFIG_INPUT_UINPUT is not set
#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_SERIAL_NONSTANDARD is not set
#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
# CONFIG_SERIAL_8250_EXTENDED is not set
#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_UNIX98_PTYS is not set
#
# I2C support
#
# CONFIG_I2C is not set
#
# I2C Hardware Sensors Mainboard support
#
#
# I2C Hardware Sensors Chip support
#
#
# Mice
#
# CONFIG_BUSMOUSE is not set
# CONFIG_QIC02_TAPE is not set
#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set
#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_INTEL_RNG is not set
# CONFIG_AMD_RNG is not set
# CONFIG_NVRAM is not set
CONFIG_RTC=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set
#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
# CONFIG_AGP is not set
# CONFIG_DRM is not set
# CONFIG_MWAVE is not set
CONFIG_RAW_DRIVER=y
# CONFIG_HANGCHECK_TIMER is not set
#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
#
# File systems
#
CONFIG_QUOTA=y
# CONFIG_QFMT_V1 is not set
# CONFIG_QFMT_V2 is not set
CONFIG_QUOTACTL=y
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=y
CONFIG_REISERFS_FS=y
# CONFIG_REISERFS_CHECK is not set
CONFIG_REISERFS_PROC_INFO=y
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
CONFIG_EXT3_FS=y
# CONFIG_EXT3_FS_XATTR is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
# CONFIG_FAT_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_TMPFS is not set
CONFIG_RAMFS=y
CONFIG_HUGETLBFS=y
# CONFIG_ISO9660_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_NTFS_FS is not set
# CONFIG_HPFS_FS is not set
CONFIG_PROC_FS=y
# CONFIG_DEVFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_ROMFS_FS is not set
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UDF_FS is not set
# CONFIG_UFS_FS is not set
CONFIG_XFS_FS=y
# CONFIG_XFS_RT is not set
# CONFIG_XFS_QUOTA is not set
# CONFIG_XFS_POSIX_ACL is not set
#
# Network File Systems
#
# CONFIG_CODA_FS is not set
# CONFIG_INTERMEZZO_FS is not set
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V4 is not set
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
# CONFIG_NFSD_V4 is not set
CONFIG_NFSD_TCP=y
CONFIG_SUNRPC=y
# CONFIG_SUNRPC_GSS is not set
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=y
# CONFIG_CIFS is not set
# CONFIG_SMB_FS is not set
# CONFIG_NCP_FS is not set
# CONFIG_AFS_FS is not set
#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_EFI_PARTITION is not set
#
# Graphics support
#
CONFIG_FB=y
# CONFIG_FB_CLGEN is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not set
# CONFIG_FB_VESA is not set
CONFIG_VIDEO_SELECT=y
# CONFIG_FB_HGA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_MATROX is not set
CONFIG_FB_RADEON=y
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_VIRTUAL is not set
#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_PCI_CONSOLE=y
# CONFIG_FBCON_ADVANCED is not set
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
#
# Sound
#
# CONFIG_SOUND is not set
#
# USB support
#
# CONFIG_USB is not set
#
# Bluetooth support
#
# CONFIG_BT is not set
#
# Profiling support
#
CONFIG_PROFILING=y
CONFIG_OPROFILE=y
#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_IOVIRT is not set
CONFIG_MAGIC_SYSRQ=y
# CONFIG_DEBUG_SPINLOCK is not set
CONFIG_KALLSYMS=y
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
CONFIG_FRAME_POINTER=y
CONFIG_X86_EXTRA_IRQS=y
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
#
# Security options
#
# CONFIG_SECURITY is not set
#
# Cryptographic options
#
# CONFIG_CRYPTO is not set
#
# Library routines
#
# CONFIG_CRC32 is not set
CONFIG_X86_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_X86_TRAMPOLINE=y
============================================================
--
Christoffer
On Mon, 2003-03-03 at 10:05, Christoffer Hall-Frederiksen wrote:
> I've tried this one on linux-scsi but to no avail, here is a resend to
> lkml.
>
> I have a dell poweredge 1650 with a perc3/DI raid controller. When the
> AACRAID driver loads it prints the following lines:
>
> AAC0: kernel 2.7.4 build 3170
> AAC0: monitor 2.7.4 build 3170
> AAC0: bios 2.7.0 build 3170
> AAC0: serial 0b9c810d3
> scsi0 : percraid
Its freezing after setup somewhere. There have been a lot of scsi changes
and not all of them are ones I've checked with aacraid. The osdl guys have
actually done pretty much all the work so far.
First things to try
Does it hang with SMP/Pre-empt off
Where does the nmi lockbreaker show it hanging
On Mon, Mar 03, 2003 at 01:40:44PM +0000, Alan Cox wrote:
|> Its freezing after setup somewhere. There have been a lot of scsi changes
|> and not all of them are ones I've checked with aacraid. The osdl guys have
|> actually done pretty much all the work so far.
|>
|> First things to try
|>
|> Does it hang with SMP/Pre-empt off
|> Where does the nmi lockbreaker show it hanging
Preemt was never on and turning off smp doesn't change anything, the
freeze happens in the same place.
I've tried with UP, APIC-enabled and nmi_watchdog={1,2}, but that
doesn't change anything. Next I'll be throwing kgdb after it.
--
Christoffer
On Fri, 2003-02-28 at 05:30, Christoffer Hall-Frederiksen wrote:
> I have a dell poweredge 1650 with a perc3/DI controller. When the
> AACRAID driver loads it stops with the following lines:
>
> AAC0: kernel 2.7.4 build 3170
> AAC0: monitor 2.7.4 build 3170
> AAC0: bios 2.7.0 build 3170
> AAC0: serial 0b9c810d3
> scsi0 : percraid
>
We just ran into this too at osdl. I have something that gets the
driver to load, but I'm not sure what the right thing is to do.
The cmd_per_lun element of the driver_template is set to
AAC_NUM_IO_FIB. This is 512.
During probe, scsi_alloc_sdev is called. It calls
scsi_adjust_queue_depth with the cmd_per_lun value.
scsi_adjust_queue_depth returns without doing anything if the tags value
is greater than 256. This leaves the Scsi_Device queue_depth at zero.
Later when an I/O is queued, scsi_request_fn checks for device_busy >=
queue_depth. If so, the function does a break and exits. This is where
it hangs.
To get things to load I set cmd_per_lun to 256. I don't know if the is
the correct way to deal with the problem. Maybe someone else can say
something about that.
===== drivers/scsi/aacraid/linit.c 1.12 vs edited =====
--- 1.12/drivers/scsi/aacraid/linit.c Mon Feb 24 13:03:30 2003
+++ edited/drivers/scsi/aacraid/linit.c Wed Mar 12 14:32:18 2003
@@ -693,7 +693,7 @@
this_id: 16,
sg_tablesize: 16,
max_sectors: 128,
- cmd_per_lun: AAC_NUM_IO_FIB,
+ cmd_per_lun: 256,
eh_abort_handler: aac_eh_abort,
eh_device_reset_handler:aac_eh_device_reset,
eh_bus_reset_handler: aac_eh_bus_reset,
--
Mark Haverkamp <[email protected]>
On Wed, 2003-03-12 at 23:06, Mark Haverkamp wrote:
> During probe, scsi_alloc_sdev is called. It calls
> scsi_adjust_queue_depth with the cmd_per_lun value.
> scsi_adjust_queue_depth returns without doing anything if the tags value
> is greater than 256. This leaves the Scsi_Device queue_depth at zero.
> Later when an I/O is queued, scsi_request_fn checks for device_busy >=
> queue_depth. If so, the function does a break and exits. This is where
> it hangs.
>
> To get things to load I set cmd_per_lun to 256. I don't know if the is
> the correct way to deal with the problem. Maybe someone else can say
> something about that.
If the SCSI layer is trying to be clever by ignoring the requested 512
then thats the actual problem. 512 is the right value because its not
really a disk you are talking to on the main channel. So the scsi layer
ought to honour it.
Alan Cox wrote:
> On Wed, 2003-03-12 at 23:06, Mark Haverkamp wrote:
>
>>During probe, scsi_alloc_sdev is called. It calls
>>scsi_adjust_queue_depth with the cmd_per_lun value.
>>scsi_adjust_queue_depth returns without doing anything if the tags value
>>is greater than 256. This leaves the Scsi_Device queue_depth at zero.
>>Later when an I/O is queued, scsi_request_fn checks for device_busy >=
>>queue_depth. If so, the function does a break and exits. This is where
>>it hangs.
>>
>>To get things to load I set cmd_per_lun to 256. I don't know if the is
>>the correct way to deal with the problem. Maybe someone else can say
>>something about that.
>
>
> If the SCSI layer is trying to be clever by ignoring the requested 512
> then thats the actual problem. 512 is the right value because its not
> really a disk you are talking to on the main channel. So the scsi layer
> ought to honour it.
Here is the relevant code snippet in scsi.c around line
930:
void scsi_adjust_queue_depth(Scsi_Device *SDpnt, int tagged, int tags)
{
static spinlock_t device_request_lock = SPIN_LOCK_UNLOCKED;
unsigned long flags;
/*
* refuse to set tagged depth to an unworkable size
*/
if(tags <= 0)
return;
/*
* Limit max queue depth on a single lun to 256 for now. Remember,
* we allocate a struct scsi_command for each of these and keep it
* around forever. Too deep of a depth just wastes memory.
*/
if(tags > 256)
return;
....
[pardon the wrap]
Now scsi_device::queue_depth is an unsigned short so that
is not a problem. Also the comment prior to the
"if (tags > 256)" is no longer correct (I think). So
perhaps it can be changed to "if (tags > 65535) ..."
Doug Gilbert
On Wed, 2003-03-12 at 23:55, Douglas Gilbert wrote:
> /*
> * Limit max queue depth on a single lun to 256 for now. Remember,
> * we allocate a struct scsi_command for each of these and keep it
> * around forever. Too deep of a depth just wastes memory.
> */
> if(tags > 256)
> return;
> ....
I can see the memory consideration. However the thing can really handle big
queues well. Possibly we should be setting the queue to 512 / somefunction(volumes)
though to avoid the worst case overcommit here
Alan Cox [[email protected]] wrote:
> On Wed, 2003-03-12 at 23:55, Douglas Gilbert wrote:
> > /*
> > * Limit max queue depth on a single lun to 256 for now. Remember,
> > * we allocate a struct scsi_command for each of these and keep it
> > * around forever. Too deep of a depth just wastes memory.
> > */
> > if(tags > 256)
> > return;
> > ....
>
> I can see the memory consideration. However the thing can really handle big
> queues well. Possibly we should be setting the queue to 512 / somefunction(volumes)
> though to avoid the worst case overcommit here
I agree with Doug that the previous comment is out of date and we could
raise the value, but we also should never leave the function with the
possibility that the queue_depth is 0.
The patch below is something Patrick and I where discussing though I
believe he indicated that I should print out the value we where setting
the queue_depth to. It was only compiled and not tested on any devices.
-andmike
--
Michael Anderson
[email protected]
scsi.c | 32 +++++++++++++++++++++++---------
1 files changed, 23 insertions(+), 9 deletions(-)
------
--- 1.96/drivers/scsi/scsi.c Fri Feb 21 13:46:58 2003
+++ edited/drivers/scsi/scsi.c Wed Mar 12 16:05:42 2003
@@ -926,15 +926,28 @@
/*
* refuse to set tagged depth to an unworkable size
*/
- if(tags <= 0)
- return;
+ if(tags <= 0) {
+ printk(KERN_WARNING "(scsi%d:%d:%d:%d) "
+ "%s, tag value to small\n"
+ "disabled\n", SDpnt->host->host_no,
+ SDpnt->channel, SDpnt->id, SDpnt->lun,
+ __FUNCTION__);
+
+ SDpnt->queue_depth = 1;
+ }
/*
- * Limit max queue depth on a single lun to 256 for now. Remember,
- * we allocate a struct scsi_command for each of these and keep it
- * around forever. Too deep of a depth just wastes memory.
+ * Limit max queue depth on a single lun to 256 for now.
+ * Too deep of a depth just wastes memory.
*/
- if(tags > 256)
- return;
+ if(tags > 256) {
+ printk(KERN_WARNING "(scsi%d:%d:%d:%d) "
+ "%s, tag value to big\n"
+ "disabled\n", SDpnt->host->host_no,
+ SDpnt->channel, SDpnt->id, SDpnt->lun,
+ __FUNCTION__);
+
+ SDpnt->queue_depth = 256;
+ }
spin_lock_irqsave(&device_request_lock, flags);
SDpnt->queue_depth = tags;
@@ -949,9 +962,10 @@
break;
default:
printk(KERN_WARNING "(scsi%d:%d:%d:%d) "
- "scsi_adjust_queue_depth, bad queue type, "
+ "%s, bad queue type, "
"disabled\n", SDpnt->host->host_no,
- SDpnt->channel, SDpnt->id, SDpnt->lun);
+ SDpnt->channel, SDpnt->id, SDpnt->lun,
+ __FUNCTION__);
case 0:
SDpnt->ordered_tags = SDpnt->simple_tags = 0;
SDpnt->queue_depth = tags;
Alan Cox wrote:
> On Wed, 2003-03-12 at 23:55, Douglas Gilbert wrote:
>
>> /*
>> * Limit max queue depth on a single lun to 256 for now. Remember,
>> * we allocate a struct scsi_command for each of these and keep it
>> * around forever. Too deep of a depth just wastes memory.
>> */
>> if(tags > 256)
>> return;
>>....
>
>
> I can see the memory consideration. However the thing can really handle big
> queues well. Possibly we should be setting the queue to 512 / somefunction(volumes)
> though to avoid the worst case overcommit here
The situation is different between 2.4 and 2.5 ...
In 2.4 the per device queue_depth is an unsigned char
and that number of scsi_cmnd instances are pre-allocated
in the scsi_build_commandblocks() function. So the worst
case number of scsi_cmnd instances for all scsi devices
is always available (at the expense of [wasted] ram).
In 2.5 queue_depth is an unsigned short and a slab
allocator called "scsi_cmd_cache" is used as required.
There is some throttle logic (or at least it has been
talked about) to make sure one scsi_cmnd instance per
scsi device will always be available.
I think that comment (probably by Doug Ledford) refers
to the 2.5 series before the slab allocator was
introduced.
Doug Gilbert
On Wed, 2003-03-12 at 17:06, Alan Cox wrote:
> On Wed, 2003-03-12 at 23:55, Douglas Gilbert wrote:
> > /*
> > * Limit max queue depth on a single lun to 256 for now. Remember,
> > * we allocate a struct scsi_command for each of these and keep it
> > * around forever. Too deep of a depth just wastes memory.
> > */
> > if(tags > 256)
> > return;
> > ....
>
> I can see the memory consideration. However the thing can really handle big
> queues well. Possibly we should be setting the queue to 512 / somefunction(volumes)
> though to avoid the worst case overcommit here
>
Does the cmd_per_lun element of the Scsi_Host_Template structure serve
more than one purpose? In scsi_alloc_sdev it is passed into
scsi_adjust_queue_depth. In the aacraid case this is 512. Later the
aacraid driver (in aac_slave_configure) sets the queue depth to either
128 for tagged or 1 if not.
Mark.
--
Mark Haverkamp <[email protected]>
On Wed, 2003-03-12 at 16:50, Mike Anderson wrote:
> Alan Cox [[email protected]] wrote:
> > On Wed, 2003-03-12 at 23:55, Douglas Gilbert wrote:
> > > /*
> > > * Limit max queue depth on a single lun to 256 for now. Remember,
> > > * we allocate a struct scsi_command for each of these and keep it
> > > * around forever. Too deep of a depth just wastes memory.
> > > */
> > > if(tags > 256)
> > > return;
> > > ....
> >
> > I can see the memory consideration. However the thing can really handle big
> > queues well. Possibly we should be setting the queue to 512 / somefunction(volumes)
> > though to avoid the worst case overcommit here
>
> I agree with Doug that the previous comment is out of date and we could
> raise the value, but we also should never leave the function with the
> possibility that the queue_depth is 0.
>
> The patch below is something Patrick and I where discussing though I
> believe he indicated that I should print out the value we where setting
> the queue_depth to. It was only compiled and not tested on any devices.
>
> -andmike
> --
> Michael Anderson
> [email protected]
>
> scsi.c | 32 +++++++++++++++++++++++---------
> 1 files changed, 23 insertions(+), 9 deletions(-)
>
> ------
>
> --- 1.96/drivers/scsi/scsi.c Fri Feb 21 13:46:58 2003
> +++ edited/drivers/scsi/scsi.c Wed Mar 12 16:05:42 2003
> @@ -926,15 +926,28 @@
> /*
> * refuse to set tagged depth to an unworkable size
> */
> - if(tags <= 0)
> - return;
> + if(tags <= 0) {
> + printk(KERN_WARNING "(scsi%d:%d:%d:%d) "
> + "%s, tag value to small\n"
> + "disabled\n", SDpnt->host->host_no,
> + SDpnt->channel, SDpnt->id, SDpnt->lun,
> + __FUNCTION__);
> +
> + SDpnt->queue_depth = 1;
> + }
> /*
> - * Limit max queue depth on a single lun to 256 for now. Remember,
> - * we allocate a struct scsi_command for each of these and keep it
> - * around forever. Too deep of a depth just wastes memory.
> + * Limit max queue depth on a single lun to 256 for now.
> + * Too deep of a depth just wastes memory.
> */
> - if(tags > 256)
> - return;
> + if(tags > 256) {
> + printk(KERN_WARNING "(scsi%d:%d:%d:%d) "
> + "%s, tag value to big\n"
> + "disabled\n", SDpnt->host->host_no,
> + SDpnt->channel, SDpnt->id, SDpnt->lun,
> + __FUNCTION__);
> +
> + SDpnt->queue_depth = 256;
> + }
>
> spin_lock_irqsave(&device_request_lock, flags);
> SDpnt->queue_depth = tags;
> @@ -949,9 +962,10 @@
> break;
> default:
> printk(KERN_WARNING "(scsi%d:%d:%d:%d) "
> - "scsi_adjust_queue_depth, bad queue type, "
> + "%s, bad queue type, "
> "disabled\n", SDpnt->host->host_no,
> - SDpnt->channel, SDpnt->id, SDpnt->lun);
> + SDpnt->channel, SDpnt->id, SDpnt->lun,
> + __FUNCTION__);
> case 0:
> SDpnt->ordered_tags = SDpnt->simple_tags = 0;
> SDpnt->queue_depth = tags;
>
>
This looks like a good idea. This is better than a hung system and no
indication why.
Mark.
--
Mark Haverkamp <[email protected]>
Mark Haverkamp wrote:
> Does the cmd_per_lun element of the Scsi_Host_Template structure serve
> more than one purpose?
Only when inappropriately abused by LLDD authors. The cmd_per_lun value
is suppossed to be for untagged devices only! If you have a tape drive
that doesn't support tagged commands but you want to be able to
internally have the next command queued up and ready to go when the
current command completes (in order to keep it streaming better), then
you can set cmd_per_lun to 2 and you will get two outstanding commands
for this device at a time. I used that so that in my interrupt handler
I could send the next command to the device before I passed the
completed command up to the SCSI layer.
> In scsi_alloc_sdev it is passed into
> scsi_adjust_queue_depth. In the aacraid case this is 512. Later the
> aacraid driver (in aac_slave_configure) sets the queue depth to either
> 128 for tagged or 1 if not.
That's where you are suppossed to set the queue depth on tagged devices.
--
Doug Ledford <[email protected]> 919-754-3700 x44233
Red Hat, Inc.
1801 Varsity Dr.
Raleigh, NC 27606
Mark Haverkamp wrote:
> Then it sounds like the aacraid driver could set cmd_per_lun to a small
> number like one since the real queue depth will be set later in
> aac_slave_configure.
Yes. And since the driver doesn't support anything other than drives to
my knowledge, 1 would be appropriate.
--
Doug Ledford <[email protected]> 919-754-3700 x44233
Red Hat, Inc.
1801 Varsity Dr.
Raleigh, NC 27606
On Thu, 2003-03-13 at 15:17, Doug Ledford wrote:
> Mark Haverkamp wrote:
>
> > Does the cmd_per_lun element of the Scsi_Host_Template structure serve
> > more than one purpose?
>
> Only when inappropriately abused by LLDD authors. The cmd_per_lun value
> is suppossed to be for untagged devices only! If you have a tape drive
> that doesn't support tagged commands but you want to be able to
> internally have the next command queued up and ready to go when the
> current command completes (in order to keep it streaming better), then
> you can set cmd_per_lun to 2 and you will get two outstanding commands
> for this device at a time. I used that so that in my interrupt handler
> I could send the next command to the device before I passed the
> completed command up to the SCSI layer.
>
> > In scsi_alloc_sdev it is passed into
> > scsi_adjust_queue_depth. In the aacraid case this is 512. Later the
> > aacraid driver (in aac_slave_configure) sets the queue depth to either
> > 128 for tagged or 1 if not.
>
> That's where you are suppossed to set the queue depth on tagged devices.
Then it sounds like the aacraid driver could set cmd_per_lun to a small
number like one since the real queue depth will be set later in
aac_slave_configure.
Mark.
--
Mark Haverkamp <[email protected]>
Douglas Gilbert wrote:
> Alan Cox wrote:
>
>> On Wed, 2003-03-12 at 23:55, Douglas Gilbert wrote:
>>
>>> /*
>>> * Limit max queue depth on a single lun to 256 for now.
>>> Remember,
>>> * we allocate a struct scsi_command for each of these and
>>> keep it
>>> * around forever. Too deep of a depth just wastes memory.
>>> */
>>> if(tags > 256)
>>> return;
>>> ....
>>
>>
>>
>> I can see the memory consideration. However the thing can really
>> handle big
>> queues well. Possibly we should be setting the queue to 512 /
>> somefunction(volumes)
>> though to avoid the worst case overcommit here
>
>
> The situation is different between 2.4 and 2.5 ...
>
> In 2.4 the per device queue_depth is an unsigned char
> and that number of scsi_cmnd instances are pre-allocated
> in the scsi_build_commandblocks() function. So the worst
> case number of scsi_cmnd instances for all scsi devices
> is always available (at the expense of [wasted] ram).
Correct.
> In 2.5 queue_depth is an unsigned short and a slab
> allocator called "scsi_cmd_cache" is used as required.
> There is some throttle logic (or at least it has been
> talked about) to make sure one scsi_cmnd instance per
> scsi device will always be available.
Not throttle logic, we simply have a struct list_head that we stick one
command (per host) onto and should it ever need to be used, then in
scsi_done() when we would normally free a command we are done with we
instead stick it back on that list head. That way, memory pressure
can't kill us, just slow us down.
> I think that comment (probably by Doug Ledford) refers
> to the 2.5 series before the slab allocator was
> introduced.
Yep.
--
Doug Ledford <[email protected]> 919-754-3700 x44233
Red Hat, Inc.
1801 Varsity Dr.
Raleigh, NC 27606
On 13 March 2003 02:50, Mike Anderson wrote:
> The patch below is something Patrick and I where discussing though I
> believe he indicated that I should print out the value we where
> setting the queue_depth to. It was only compiled and not tested on
> any devices.
>
> -andmike
--- 1.96/drivers/scsi/scsi.c Fri Feb 21 13:46:58 2003
+++ edited/drivers/scsi/scsi.c Wed Mar 12 16:05:42 2003
@@ -926,15 +926,28 @@
/*
* refuse to set tagged depth to an unworkable size
*/
- if(tags <= 0)
- return;
+ if(tags <= 0) {
+ printk(KERN_WARNING "(scsi%d:%d:%d:%d) "
+ "%s, tag value to small\n"
+ "disabled\n", SDpnt->host->host_no,
Please do not split message into several lines.
There are several reasons why you shouldn't do it.
+ SDpnt->channel, SDpnt->id, SDpnt->lun,
+ __FUNCTION__);
+
+ SDpnt->queue_depth = 1;
+ }
/*
- * Limit max queue depth on a single lun to 256 for now. Remember,
- * we allocate a struct scsi_command for each of these and keep it
- * around forever. Too deep of a depth just wastes memory.
+ * Limit max queue depth on a single lun to 256 for now.
+ * Too deep of a depth just wastes memory.
*/
- if(tags > 256)
- return;
+ if(tags > 256) {
+ printk(KERN_WARNING "(scsi%d:%d:%d:%d) "
+ "%s, tag value to big\n"
+ "disabled\n", SDpnt->host->host_no,
Same here.
+ SDpnt->channel, SDpnt->id, SDpnt->lun,
+ __FUNCTION__);
+
+ SDpnt->queue_depth = 256;
+ }
spin_lock_irqsave(&device_request_lock, flags);
SDpnt->queue_depth = tags;
@@ -949,9 +962,10 @@
break;
default:
printk(KERN_WARNING "(scsi%d:%d:%d:%d) "
- "scsi_adjust_queue_depth, bad queue type, "
+ "%s, bad queue type, "
"disabled\n", SDpnt->host->host_no,
- SDpnt->channel, SDpnt->id, SDpnt->lun);
+ SDpnt->channel, SDpnt->id, SDpnt->lun,
+ __FUNCTION__);
case 0:
SDpnt->ordered_tags = SDpnt->simple_tags = 0;
SDpnt->queue_depth = tags;
Denis Vlasenko [[email protected]] wrote:
> + if(tags <= 0) {
> + printk(KERN_WARNING "(scsi%d:%d:%d:%d) "
> + "%s, tag value to small\n"
> + "disabled\n", SDpnt->host->host_no,
>
> Please do not split message into several lines.
> There are several reasons why you shouldn't do it.
Thanks for pointing this out.
This was a paste typo. There was also some incorrect style spacing, and
it did not work (the queue_depth was set to tags down below). From Doug
Ledford's later comments this change may not be needed to correct the
problem, but I will re-roll tomorrow.
-andmike
--
Michael Anderson
[email protected]
On Thu, 2003-03-13 at 23:25, Doug Ledford wrote:
> Mark Haverkamp wrote:
> > Then it sounds like the aacraid driver could set cmd_per_lun to a small
> > number like one since the real queue depth will be set later in
> > aac_slave_configure.
>
> Yes. And since the driver doesn't support anything other than drives to
> my knowledge, 1 would be appropriate.
It supports both disks and non disk devices. Disks are mapped onto bus 0
and are driven via firmware smarts as logical devices, non disks are bus 1
and there it behaves mostly like a scsi controller
On Fri, 2003-03-14 at 06:57, Alan Cox wrote:
> On Thu, 2003-03-13 at 23:25, Doug Ledford wrote:
> > Mark Haverkamp wrote:
> > > Then it sounds like the aacraid driver could set cmd_per_lun to a small
> > > number like one since the real queue depth will be set later in
> > > aac_slave_configure.
> >
> > Yes. And since the driver doesn't support anything other than drives to
> > my knowledge, 1 would be appropriate.
>
> It supports both disks and non disk devices. Disks are mapped onto bus 0
> and are driven via firmware smarts as logical devices, non disks are bus 1
> and there it behaves mostly like a scsi controller
Is aac_slave_configure only called for disk devices? If its called for
all scsi devices, then the queue depth will always be set to something a
lot less than 512. I did some searching through the scsi code and I see
only two places that cmd_per_lun is used. It is used to set the queue
depth in scsi_track_queue_full and scsi_alloc_sdev. So it seems that, if
aac_slave_configure gets called for all scsi devices, that setting
cmd_per_lun in the aacraid scsi host template to 1 would be OK. Does
that make sense or did I miss something?
Thanks,
Mark.
--
Mark Haverkamp <[email protected]>
On Fri, 2003-03-14 at 15:34, Mark Haverkamp wrote:
> Is aac_slave_configure only called for disk devices? If its called for
> all scsi devices, then the queue depth will always be set to something a
> lot less than 512. I did some searching through the scsi code and I see
> only two places that cmd_per_lun is used. It is used to set the queue
> depth in scsi_track_queue_full and scsi_alloc_sdev. So it seems that, if
> aac_slave_configure gets called for all scsi devices, that setting
> cmd_per_lun in the aacraid scsi host template to 1 would be OK. Does
> that make sense or did I miss something?
I think you are right