* More information on scsi_cmd_cache leak... (bisect)
@ 2006-01-27 10:09 Chase Venters
2006-01-27 11:11 ` Neil Brown
` (3 more replies)
0 siblings, 4 replies; 21+ messages in thread
From: Chase Venters @ 2006-01-27 10:09 UTC (permalink / raw)
To: linux-kernel, linux-scsi, akpm, a.titov, axboe, askernel2615,
jamie, neilb
[-- Attachment #1: Type: text/plain, Size: 2598 bytes --]
Greetings,
Just a quick recap - there are at least 4 reports of 2.6.15 users
experiencing severe slab leaks with scsi_cmd_cache. It seems that a few of us
have a board (Asus P5GDC-V Deluxe) in common. We seem to have raid in common.
After dealing with this leak for a while, I decided to do some dancing around
with git bisect. I've landed on a possible point of regression:
commit: a9701a30470856408d08657eb1bd7ae29a146190
[PATCH] md: support BIO_RW_BARRIER for md/raid1
I spent about an hour and a half reading through the patch, trying to see if
I could make sense of what might be wrong. The result (after I dug into the
code to make a change I foolishly thought made sense) was a hung kernel.
This is important because when I rebooted into the kernel that had been
giving me trouble, it started an md resync and I'm now watching (at least
during this resync) the slab usage for scsi_cmd_cache stay sane:
turbotaz ~ # cat /proc/slabinfo | grep scsi_cmd_cache
scsi_cmd_cache 30 30 384 10 1 : tunables 54 27 8 :
slabdata 3 3 0
I guess I'm going to have to wait for this resync to finish and see if the
slab leak starts back up.
Other data: I've done an mdadm --stop on my raid1 /boot partition, leaving
only my raid10 / partition active. The slab continues to leak long after md0
(raid1) is stopped. Boot is also never mounted except when explicitly needed.
As I was going through bisect iterations, the cache on good kernels would
report no more than 9 objects right after boot (granted, I built the bisect
kernels with support for basically nothing but my USB keyboard and SATA). The
bad kernels would vary from 350 on up to somewhere around 600 right after
boot.
All bisect kernels were built from the same .config, and "make clean; make
mrproper" was executed between each compile. (Do I really need to do that?
How does git handle timestamps? I assumed I didn't really need to but did it
to be thorough).
I've attached my bisect log in case anyone wants to trace my steps, as well
as the config I was using to build the bisect kernels.
I can't rule Neil's patch out as being inherently responsible, but I'm sure
lots of people are using it now, so perhaps issuing these barriers in
md_super_write are having an interaction elsewhere?
I thought super_written_barrier looked funny in terms of how bio_put is
called on the original bio before the barrier bio is sent to super_written
(looked backwards), but altering it caused the hang. I guess I'm not quite
there yet in understanding block IO :P
Thanks,
Chase
[-- Attachment #2: bisect-log --]
[-- Type: text/plain, Size: 2377 bytes --]
git-bisect start
# bad: [88026842b0a760145aa71d69e74fbc9ec118ca44] Linux v2.6.15
git-bisect bad 88026842b0a760145aa71d69e74fbc9ec118ca44
# good: [2b10839e32c4c476e9d94492756bb1a3e1ec4aa8] Linux v2.6.14
git-bisect good 2b10839e32c4c476e9d94492756bb1a3e1ec4aa8
# good: [dd0314f7bb407bc4bdb3ea769b9c8a3a5d39ffd7] fbcon: Initialize new driver when old driver is released
git-bisect good dd0314f7bb407bc4bdb3ea769b9c8a3a5d39ffd7
# bad: [ad36d1a533da91d3448029b4da1113c5b880f25d] [libata ahci] error handling fixes
git-bisect bad ad36d1a533da91d3448029b4da1113c5b880f25d
# good: [2b5200a7b19a53969db68c97d379339592ca6a4f] v4l: 766: add dvb card winfast dtv1000-t
git-bisect good 2b5200a7b19a53969db68c97d379339592ca6a4f
# bad: [f51750d5eab50f0db5396a5ca30d5bafc038c263] libata: Note a nasty ATA quirk
git-bisect bad f51750d5eab50f0db5396a5ca30d5bafc038c263
# bad: [7df446e7e043b2ba5fd5de42529f9d797e8b501a] Merge branch 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6
git-bisect bad 7df446e7e043b2ba5fd5de42529f9d797e8b501a
# good: [6e45f5d8d27cb619cf7e94c78a67fb61a4f3dd5e] v4l: 894: work around to allow hybrid dvb card to autoload the tda9887
git-bisect good 6e45f5d8d27cb619cf7e94c78a67fb61a4f3dd5e
# good: [ed8c0e99f27451a9b980adf0de318d60e6de811f] fbcon: Console Rotation - Add support for 270-degree rotation
git-bisect good ed8c0e99f27451a9b980adf0de318d60e6de811f
# good: [bd926c63b7a6843d3ce2728396c0891e54fce5c4] md: make md on-disk bitmaps not host-endian
git-bisect good bd926c63b7a6843d3ce2728396c0891e54fce5c4
# bad: [787453c2397edcc3261efebb661739acd8c38547] md: complete conversion of md to use kthreads
git-bisect bad 787453c2397edcc3261efebb661739acd8c38547
# bad: [3855ad9f398de88a3290f7dd799633c4b73903ea] md: make sure a user-request sync of raid5 ignores intent bitmap
git-bisect bad 3855ad9f398de88a3290f7dd799633c4b73903ea
# bad: [f91de92ed6bfb70a3ff607558c910c7bf34d45e9] md: allow md arrays to be started read-only (module parameter).
git-bisect bad f91de92ed6bfb70a3ff607558c910c7bf34d45e9
# bad: [19133a4298223422742db7b5f940e8c54c6a1846] md: Remove attempt to use dynamic names in sysfs for component devices on an MD array.
git-bisect bad 19133a4298223422742db7b5f940e8c54c6a1846
# bad: [a9701a30470856408d08657eb1bd7ae29a146190] md: support BIO_RW_BARRIER for md/raid1
git-bisect bad a9701a30470856408d08657eb1bd7ae29a146190
[-- Attachment #3: bisect-config --]
[-- Type: text/plain, Size: 29586 bytes --]
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.14
# Thu Jan 26 23:18:12 2006
#
CONFIG_X86_32=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_SYSCTL=y
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_CPUSETS is not set
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y
#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# 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_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 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 is not set
# CONFIG_MPENTIUMM is not set
CONFIG_MPENTIUM4=y
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
# CONFIG_HPET_TIMER is not set
CONFIG_SMP=y
CONFIG_NR_CPUS=8
CONFIG_SCHED_SMT=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=y
CONFIG_X86_MCE_P4THERMAL=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_X86_REBOOTFIXUPS is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set
#
# Firmware Drivers
#
# CONFIG_EDD is not set
# CONFIG_DELL_RBU is not set
# CONFIG_DCDBAS is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
# CONFIG_SPARSEMEM_STATIC is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_EFI is not set
CONFIG_IRQBALANCE=y
# CONFIG_REGPARM is not set
CONFIG_SECCOMP=y
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_PHYSICAL_START=0x100000
# CONFIG_KEXEC is not set
#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
#
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_VIDEO=y
# CONFIG_ACPI_HOTKEY is not set
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_ASUS is not set
CONFIG_ACPI_IBM=y
# CONFIG_ACPI_TOSHIBA is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
# CONFIG_X86_PM_TIMER is not set
# CONFIG_ACPI_CONTAINER is not set
#
# APM (Advanced Power Management) BIOS Support
#
# CONFIG_APM 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_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
# CONFIG_PCIEPORTBUS is not set
# CONFIG_PCI_MSI is not set
CONFIG_PCI_LEGACY_PROC=y
# CONFIG_PCI_DEBUG is not set
CONFIG_ISA_DMA_API=y
CONFIG_ISA=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set
# CONFIG_HOTPLUG_CPU is not set
#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set
#
# PCI Hotplug Support
#
# CONFIG_HOTPLUG_PCI is not set
#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_MISC=y
#
# Networking
#
CONFIG_NET=y
#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
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_FIB_HASH=y
# 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_SYN_COOKIES is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_TUNNEL is not set
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_BIC=y
#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
# CONFIG_NETFILTER_NETLINK is not set
#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=y
# CONFIG_IP_NF_CT_ACCT is not set
# CONFIG_IP_NF_CONNTRACK_MARK is not set
# CONFIG_IP_NF_CONNTRACK_EVENTS is not set
# CONFIG_IP_NF_CT_PROTO_SCTP is not set
# CONFIG_IP_NF_FTP is not set
# CONFIG_IP_NF_IRC is not set
# CONFIG_IP_NF_NETBIOS_NS is not set
# CONFIG_IP_NF_TFTP is not set
# CONFIG_IP_NF_AMANDA is not set
# CONFIG_IP_NF_PPTP is not set
CONFIG_IP_NF_QUEUE=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_LIMIT=y
CONFIG_IP_NF_MATCH_IPRANGE=y
CONFIG_IP_NF_MATCH_MAC=y
CONFIG_IP_NF_MATCH_PKTTYPE=y
CONFIG_IP_NF_MATCH_MARK=y
CONFIG_IP_NF_MATCH_MULTIPORT=y
CONFIG_IP_NF_MATCH_TOS=y
CONFIG_IP_NF_MATCH_RECENT=y
CONFIG_IP_NF_MATCH_ECN=y
CONFIG_IP_NF_MATCH_DSCP=y
CONFIG_IP_NF_MATCH_AH_ESP=y
CONFIG_IP_NF_MATCH_LENGTH=y
CONFIG_IP_NF_MATCH_TTL=y
CONFIG_IP_NF_MATCH_TCPMSS=y
CONFIG_IP_NF_MATCH_HELPER=y
CONFIG_IP_NF_MATCH_STATE=y
CONFIG_IP_NF_MATCH_CONNTRACK=y
CONFIG_IP_NF_MATCH_OWNER=y
# CONFIG_IP_NF_MATCH_ADDRTYPE is not set
# CONFIG_IP_NF_MATCH_REALM is not set
# CONFIG_IP_NF_MATCH_SCTP is not set
# CONFIG_IP_NF_MATCH_DCCP is not set
# CONFIG_IP_NF_MATCH_COMMENT is not set
# CONFIG_IP_NF_MATCH_HASHLIMIT is not set
# CONFIG_IP_NF_MATCH_STRING is not set
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_TARGET_LOG=y
CONFIG_IP_NF_TARGET_ULOG=y
CONFIG_IP_NF_TARGET_TCPMSS=y
# CONFIG_IP_NF_TARGET_NFQUEUE is not set
CONFIG_IP_NF_NAT=y
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_IP_NF_TARGET_REDIRECT=y
CONFIG_IP_NF_TARGET_NETMAP=y
CONFIG_IP_NF_TARGET_SAME=y
# CONFIG_IP_NF_NAT_SNMP_BASIC is not set
CONFIG_IP_NF_MANGLE=y
CONFIG_IP_NF_TARGET_TOS=y
CONFIG_IP_NF_TARGET_ECN=y
CONFIG_IP_NF_TARGET_DSCP=y
CONFIG_IP_NF_TARGET_MARK=y
CONFIG_IP_NF_TARGET_CLASSIFY=y
# CONFIG_IP_NF_TARGET_TTL is not set
CONFIG_IP_NF_RAW=m
CONFIG_IP_NF_TARGET_NOTRACK=m
CONFIG_IP_NF_ARPTABLES=y
CONFIG_IP_NF_ARPFILTER=y
CONFIG_IP_NF_ARP_MANGLE=y
#
# DCCP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_DCCP is not set
#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK 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
#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set
# CONFIG_NET_CLS_ROUTE is not set
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_IEEE80211 is not set
#
# Device Drivers
#
#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=m
# CONFIG_DEBUG_DRIVER is not set
#
# Connector - unified userspace <-> kernelspace linker
#
# CONFIG_CONNECTOR is not set
#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set
#
# Parallel port support
#
CONFIG_PARPORT=y
CONFIG_PARPORT_PC=y
# CONFIG_PARPORT_SERIAL is not set
# CONFIG_PARPORT_PC_FIFO is not set
# CONFIG_PARPORT_PC_SUPERIO is not set
# CONFIG_PARPORT_GSC is not set
# CONFIG_PARPORT_1284 is not set
#
# Plug and Play support
#
CONFIG_PNP=y
# CONFIG_PNP_DEBUG is not set
#
# Protocols
#
# CONFIG_ISAPNP is not set
# CONFIG_PNPBIOS is not set
CONFIG_PNPACPI=y
#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_DEV_XD is not set
# CONFIG_PARIDE is not set
# 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_COW_COMMON is not set
# CONFIG_BLK_DEV_LOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
# CONFIG_BLK_DEV_RAM is not set
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_LBD=y
# CONFIG_CDROM_PKTCDVD is not set
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_AS=y
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="anticipatory"
# CONFIG_ATA_OVER_ETH is not set
#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_IDE_SATA is not set
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=y
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
# CONFIG_BLK_DEV_IDESCSI is not set
# CONFIG_IDE_TASK_IOCTL is not set
#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
CONFIG_BLK_DEV_CMD640=y
# CONFIG_BLK_DEV_CMD640_ENHANCED is not set
# CONFIG_BLK_DEV_IDEPNP is not set
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_BLK_DEV_GENERIC=y
# CONFIG_BLK_DEV_OPTI621 is not set
CONFIG_BLK_DEV_RZ1000=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_BLK_DEV_ATIIXP is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5520 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_SC1200 is not set
CONFIG_BLK_DEV_PIIX=y
# CONFIG_BLK_DEV_IT821X is not set
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
# CONFIG_BLK_DEV_PDC202XX_NEW is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_VIA82CXXX is not set
# CONFIG_IDE_ARM is not set
# CONFIG_IDE_CHIPSETS is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_BLK_DEV_HD is not set
#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
CONFIG_SCSI_PROC_FS=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
# CONFIG_CHR_DEV_SCH is not set
#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
# CONFIG_SCSI_MULTI_LUN is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set
#
# SCSI Transport Attributes
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_ATTRS is not set
#
# SCSI low-level drivers
#
# CONFIG_ISCSI_TCP is not set
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_7000FASST is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AHA152X is not set
# CONFIG_SCSI_AHA1542 is not set
# CONFIG_SCSI_AACRAID is not set
# 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_IN2000 is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
CONFIG_SCSI_SATA=y
# CONFIG_SCSI_SATA_AHCI is not set
# CONFIG_SCSI_SATA_SVW is not set
CONFIG_SCSI_ATA_PIIX=y
# CONFIG_SCSI_SATA_MV is not set
# CONFIG_SCSI_SATA_NV is not set
# CONFIG_SCSI_PDC_ADMA is not set
# CONFIG_SCSI_SATA_QSTOR is not set
# CONFIG_SCSI_SATA_PROMISE is not set
# CONFIG_SCSI_SATA_SX4 is not set
# CONFIG_SCSI_SATA_SIL is not set
# CONFIG_SCSI_SATA_SIL24 is not set
# CONFIG_SCSI_SATA_SIS is not set
# CONFIG_SCSI_SATA_ULI is not set
# CONFIG_SCSI_SATA_VIA is not set
# CONFIG_SCSI_SATA_VITESSE is not set
CONFIG_SCSI_SATA_INTEL_COMBINED=y
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_EATA 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_PPA is not set
# CONFIG_SCSI_IMM is not set
# CONFIG_SCSI_NCR53C406A is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PSI240I is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
CONFIG_SCSI_QLA2XXX=y
# CONFIG_SCSI_QLA21XX is not set
# CONFIG_SCSI_QLA22XX is not set
# CONFIG_SCSI_QLA2300 is not set
# CONFIG_SCSI_QLA2322 is not set
# CONFIG_SCSI_QLA6312 is not set
# CONFIG_SCSI_QLA24XX is not set
# CONFIG_SCSI_LPFC is not set
# CONFIG_SCSI_SYM53C416 is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_T128 is not set
# CONFIG_SCSI_U14_34F is not set
# CONFIG_SCSI_ULTRASTOR is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set
#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set
#
# Multi-device support (RAID and LVM)
#
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
CONFIG_MD_LINEAR=y
CONFIG_MD_RAID0=y
CONFIG_MD_RAID1=y
CONFIG_MD_RAID10=y
CONFIG_MD_RAID5=y
CONFIG_MD_RAID6=y
CONFIG_MD_MULTIPATH=y
CONFIG_MD_FAULTY=y
CONFIG_BLK_DEV_DM=y
CONFIG_DM_CRYPT=y
CONFIG_DM_SNAPSHOT=y
CONFIG_DM_MIRROR=y
CONFIG_DM_ZERO=y
# CONFIG_DM_MULTIPATH is not set
#
# Fusion MPT device support
#
# CONFIG_FUSION is not set
# CONFIG_FUSION_SPI is not set
# CONFIG_FUSION_FC is not set
# CONFIG_FUSION_SAS is not set
#
# IEEE 1394 (FireWire) support
#
# CONFIG_IEEE1394 is not set
#
# I2O device support
#
# CONFIG_I2O is not set
#
# Network device support
#
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_NET_SB1000 is not set
#
# ARCnet devices
#
# CONFIG_ARCNET is not set
#
# PHY device support
#
# CONFIG_PHYLIB is not set
#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_LANCE is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set
#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_AT1700 is not set
# CONFIG_DEPCA is not set
# CONFIG_HP100 is not set
# CONFIG_NET_ISA 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_AC3200 is not set
# CONFIG_APRICOT is not set
# CONFIG_B44 is not set
# CONFIG_FORCEDETH is not set
# CONFIG_CS89x0 is not set
# CONFIG_DGRS is not set
# CONFIG_EEPRO100 is not set
# CONFIG_E100 is not set
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_8139CP is not set
CONFIG_8139TOO=y
CONFIG_8139TOO_PIO=y
# CONFIG_8139TOO_TUNE_TWISTER is not set
# CONFIG_8139TOO_8129 is not set
# CONFIG_8139_OLD_RX_RESET 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
# CONFIG_NET_POCKET is not set
# CONFIG_FEC_8XX is not set
#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
# CONFIG_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set
# CONFIG_BNX2 is not set
#
# Ethernet (10000 Mbit)
#
# CONFIG_CHELSIO_T1 is not set
# CONFIG_IXGB is not set
CONFIG_S2IO=m
# CONFIG_S2IO_NAPI is not set
#
# Token Ring devices
#
# CONFIG_TR is not set
#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set
#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PLIP is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
#
# ISDN subsystem
#
# CONFIG_ISDN 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 Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_INPORT is not set
# CONFIG_MOUSE_LOGIBM is not set
# CONFIG_MOUSE_PC110PAD is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set
#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PARKBD is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_GAMEPORT 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 is not set
# CONFIG_SERIAL_8250_ACPI is not set
CONFIG_SERIAL_8250_NR_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set
#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
CONFIG_PRINTER=y
# CONFIG_LP_CONSOLE is not set
# CONFIG_PPDEV is not set
# CONFIG_TIPAR is not set
#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set
#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_NVRAM is not set
# CONFIG_RTC is not set
# CONFIG_GEN_RTC is not set
# 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_AGP is not set
# CONFIG_DRM is not set
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HPET is not set
# CONFIG_HANGCHECK_TIMER is not set
#
# TPM devices
#
# CONFIG_TCG_TPM is not set
# CONFIG_TELCLOCK is not set
#
# I2C support
#
# CONFIG_I2C is not set
#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set
#
# Hardware Monitoring support
#
CONFIG_HWMON=y
# CONFIG_HWMON_VID is not set
# CONFIG_SENSORS_HDAPS is not set
# CONFIG_HWMON_DEBUG_CHIP is not set
#
# Misc devices
#
# CONFIG_IBM_ASM is not set
#
# Multimedia Capabilities Port drivers
#
#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set
#
# Graphics support
#
# CONFIG_FB is not set
# CONFIG_VIDEO_SELECT is not set
#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
#
# Sound
#
# CONFIG_SOUND is not set
#
# USB support
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set
#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_BANDWIDTH is not set
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_SUSPEND is not set
# CONFIG_USB_OTG is not set
#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_SPLIT_ISO=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_ISP116X_HCD=y
CONFIG_USB_OHCI_HCD=y
# CONFIG_USB_OHCI_BIG_ENDIAN is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_UHCI_HCD=y
# CONFIG_USB_SL811_HCD is not set
#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set
#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
#
#
# may also be needed; see USB_STORAGE Help for more information
#
# CONFIG_USB_STORAGE is not set
#
# USB Input Devices
#
CONFIG_USB_HID=y
CONFIG_USB_HIDINPUT=y
# CONFIG_HID_FF is not set
CONFIG_USB_HIDDEV=y
# CONFIG_USB_AIPTEK is not set
# CONFIG_USB_WACOM is not set
# CONFIG_USB_ACECAD is not set
# CONFIG_USB_KBTAB is not set
# CONFIG_USB_POWERMATE is not set
# CONFIG_USB_MTOUCH is not set
# CONFIG_USB_ITMTOUCH is not set
# CONFIG_USB_EGALAX is not set
# CONFIG_USB_YEALINK is not set
# CONFIG_USB_XPAD is not set
# CONFIG_USB_ATI_REMOTE is not set
# CONFIG_USB_KEYSPAN_REMOTE is not set
# CONFIG_USB_APPLETOUCH is not set
#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set
#
# USB Multimedia devices
#
# CONFIG_USB_DABUSB is not set
#
# Video4Linux support is needed for USB Multimedia device support
#
#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET is not set
# CONFIG_USB_MON is not set
#
# USB port drivers
#
# CONFIG_USB_USS720 is not set
#
# USB Serial Converter support
#
# CONFIG_USB_SERIAL is not set
#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_PHIDGETKIT is not set
# CONFIG_USB_PHIDGETSERVO is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TEST is not set
#
# USB DSL modem support
#
#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set
#
# MMC/SD Card support
#
# CONFIG_MMC is not set
#
# InfiniBand support
#
# CONFIG_INFINIBAND is not set
#
# SN Devices
#
#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT2_FS_XIP is not set
# CONFIG_EXT3_FS is not set
# CONFIG_JBD is not set
CONFIG_REISERFS_FS=y
# CONFIG_REISERFS_CHECK is not set
CONFIG_REISERFS_PROC_INFO=y
CONFIG_REISERFS_FS_XATTR=y
CONFIG_REISERFS_FS_POSIX_ACL=y
CONFIG_REISERFS_FS_SECURITY=y
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_INOTIFY is not set
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set
#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
# CONFIG_ZISOFS is not set
CONFIG_UDF_FS=y
CONFIG_UDF_NLS=y
#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
# CONFIG_RELAYFS_FS is not set
#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
#
# Network File Systems
#
CONFIG_NFS_FS=y
# CONFIG_NFS_V3 is not set
# CONFIG_NFS_V4 is not set
# CONFIG_NFS_DIRECTIO is not set
CONFIG_NFSD=y
# CONFIG_NFSD_V3 is not set
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=y
CONFIG_EXPORTFS=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
# CONFIG_RPCSEC_GSS_KRB5 is not set
# CONFIG_RPCSEC_GSS_SPKM3 is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
# CONFIG_9P_FS is not set
#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set
#
# Instrumentation Support
#
# CONFIG_PROFILING is not set
# CONFIG_KPROBES is not set
#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_MAGIC_SYSRQ is not set
CONFIG_LOG_BUF_SHIFT=15
CONFIG_DETECT_SOFTLOCKUP=y
# CONFIG_SCHEDSTATS is not set
CONFIG_DEBUG_SLAB=y
CONFIG_DEBUG_PREEMPT=y
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_FS is not set
# CONFIG_DEBUG_VM is not set
CONFIG_FRAME_POINTER=y
# CONFIG_RCU_TORTURE_TEST is not set
CONFIG_EARLY_PRINTK=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_DEBUG_STACK_USAGE is not set
CONFIG_DEBUG_PAGEALLOC=y
CONFIG_4KSTACKS=y
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set
#
# Cryptographic options
#
CONFIG_CRYPTO=y
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_MD4 is not set
# CONFIG_CRYPTO_MD5 is not set
# CONFIG_CRYPTO_SHA1 is not set
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_WP512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_DES is not set
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_AES_586 is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_DEFLATE is not set
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_TEST is not set
#
# Hardware crypto devices
#
# CONFIG_CRYPTO_DEV_PADLOCK is not set
#
# Library routines
#
# CONFIG_CRC_CCITT is not set
# CONFIG_CRC16 is not set
CONFIG_CRC32=y
CONFIG_LIBCRC32C=m
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_X86_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_X86_TRAMPOLINE=y
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: More information on scsi_cmd_cache leak... (bisect)
2006-01-27 10:09 More information on scsi_cmd_cache leak... (bisect) Chase Venters
@ 2006-01-27 11:11 ` Neil Brown
2006-01-27 11:23 ` Jens Axboe
2006-01-27 13:33 ` Alexey Dobriyan
` (2 subsequent siblings)
3 siblings, 1 reply; 21+ messages in thread
From: Neil Brown @ 2006-01-27 11:11 UTC (permalink / raw)
To: Chase Venters
Cc: linux-kernel, linux-scsi, akpm, a.titov, axboe, askernel2615, jamie
On Friday January 27, chase.venters@clientec.com wrote:
> Greetings,
> Just a quick recap - there are at least 4 reports of 2.6.15 users
> experiencing severe slab leaks with scsi_cmd_cache. It seems that a few of us
> have a board (Asus P5GDC-V Deluxe) in common. We seem to have raid in common.
> After dealing with this leak for a while, I decided to do some dancing around
> with git bisect. I've landed on a possible point of regression:
>
> commit: a9701a30470856408d08657eb1bd7ae29a146190
> [PATCH] md: support BIO_RW_BARRIER for md/raid1
>
> I spent about an hour and a half reading through the patch, trying to see if
> I could make sense of what might be wrong. The result (after I dug into the
> code to make a change I foolishly thought made sense) was a hung kernel.
> This is important because when I rebooted into the kernel that had been
> giving me trouble, it started an md resync and I'm now watching (at least
> during this resync) the slab usage for scsi_cmd_cache stay sane:
>
> turbotaz ~ # cat /proc/slabinfo | grep scsi_cmd_cache
> scsi_cmd_cache 30 30 384 10 1 : tunables 54 27 8 :
> slabdata 3 3 0
>
This suggests that the problem happens when a BIO_RW_BARRIER write is
sent to the device. With this patch, md flags all superblock writes
as BIO_RW_BARRIER However md is not so likely to update the superblock often
during a resync.
There is a (rough) count of the number of superblock writes in the
"Events" counter which "mdadm -D" will display.
You could try collecting 'Events' counter together with the
'active_objs' count from /proc/slabinfo and graph the pairs - see if
they are linear.
I believe a BIO_RW_BARRIER is likely to send some sort of 'flush'
command to the device, and the driver for your particular device may
well be losing scsi_cmd_cache allocation when doing that, but I leave
that to someone how knows more about that code.
Good detective work!
NeilBrown
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: More information on scsi_cmd_cache leak... (bisect)
2006-01-27 11:11 ` Neil Brown
@ 2006-01-27 11:23 ` Jens Axboe
2006-01-27 11:28 ` Jens Axboe
0 siblings, 1 reply; 21+ messages in thread
From: Jens Axboe @ 2006-01-27 11:23 UTC (permalink / raw)
To: Neil Brown
Cc: Chase Venters, linux-kernel, linux-scsi, akpm, a.titov,
askernel2615, jamie
On Fri, Jan 27 2006, Neil Brown wrote:
> On Friday January 27, chase.venters@clientec.com wrote:
> > Greetings,
> > Just a quick recap - there are at least 4 reports of 2.6.15 users
> > experiencing severe slab leaks with scsi_cmd_cache. It seems that a few of us
> > have a board (Asus P5GDC-V Deluxe) in common. We seem to have raid in common.
> > After dealing with this leak for a while, I decided to do some dancing around
> > with git bisect. I've landed on a possible point of regression:
> >
> > commit: a9701a30470856408d08657eb1bd7ae29a146190
> > [PATCH] md: support BIO_RW_BARRIER for md/raid1
> >
> > I spent about an hour and a half reading through the patch, trying to see if
> > I could make sense of what might be wrong. The result (after I dug into the
> > code to make a change I foolishly thought made sense) was a hung kernel.
> > This is important because when I rebooted into the kernel that had been
> > giving me trouble, it started an md resync and I'm now watching (at least
> > during this resync) the slab usage for scsi_cmd_cache stay sane:
> >
> > turbotaz ~ # cat /proc/slabinfo | grep scsi_cmd_cache
> > scsi_cmd_cache 30 30 384 10 1 : tunables 54 27 8 :
> > slabdata 3 3 0
> >
>
> This suggests that the problem happens when a BIO_RW_BARRIER write is
> sent to the device. With this patch, md flags all superblock writes
> as BIO_RW_BARRIER However md is not so likely to update the superblock often
> during a resync.
>
> There is a (rough) count of the number of superblock writes in the
> "Events" counter which "mdadm -D" will display.
> You could try collecting 'Events' counter together with the
> 'active_objs' count from /proc/slabinfo and graph the pairs - see if
> they are linear.
>
> I believe a BIO_RW_BARRIER is likely to send some sort of 'flush'
> command to the device, and the driver for your particular device may
> well be losing scsi_cmd_cache allocation when doing that, but I leave
> that to someone how knows more about that code.
I already checked up on that since I suspected barriers initially. The
path there for scsi is sd.c:sd_issue_flush() which looks pretty straight
forward. In the end it goes through the block layer and gets back to the
SCSI layer as a regular REQ_BLOCK_PC request.
--
Jens Axboe
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: More information on scsi_cmd_cache leak... (bisect)
2006-01-27 11:23 ` Jens Axboe
@ 2006-01-27 11:28 ` Jens Axboe
2006-01-27 15:20 ` Chase Venters
2006-01-27 19:06 ` Mike Christie
0 siblings, 2 replies; 21+ messages in thread
From: Jens Axboe @ 2006-01-27 11:28 UTC (permalink / raw)
To: Neil Brown
Cc: Chase Venters, linux-kernel, linux-scsi, akpm, a.titov,
askernel2615, jamie
On Fri, Jan 27 2006, Jens Axboe wrote:
> On Fri, Jan 27 2006, Neil Brown wrote:
> > On Friday January 27, chase.venters@clientec.com wrote:
> > > Greetings,
> > > Just a quick recap - there are at least 4 reports of 2.6.15 users
> > > experiencing severe slab leaks with scsi_cmd_cache. It seems that a few of us
> > > have a board (Asus P5GDC-V Deluxe) in common. We seem to have raid in common.
> > > After dealing with this leak for a while, I decided to do some dancing around
> > > with git bisect. I've landed on a possible point of regression:
> > >
> > > commit: a9701a30470856408d08657eb1bd7ae29a146190
> > > [PATCH] md: support BIO_RW_BARRIER for md/raid1
> > >
> > > I spent about an hour and a half reading through the patch, trying to see if
> > > I could make sense of what might be wrong. The result (after I dug into the
> > > code to make a change I foolishly thought made sense) was a hung kernel.
> > > This is important because when I rebooted into the kernel that had been
> > > giving me trouble, it started an md resync and I'm now watching (at least
> > > during this resync) the slab usage for scsi_cmd_cache stay sane:
> > >
> > > turbotaz ~ # cat /proc/slabinfo | grep scsi_cmd_cache
> > > scsi_cmd_cache 30 30 384 10 1 : tunables 54 27 8 :
> > > slabdata 3 3 0
> > >
> >
> > This suggests that the problem happens when a BIO_RW_BARRIER write is
> > sent to the device. With this patch, md flags all superblock writes
> > as BIO_RW_BARRIER However md is not so likely to update the superblock often
> > during a resync.
> >
> > There is a (rough) count of the number of superblock writes in the
> > "Events" counter which "mdadm -D" will display.
> > You could try collecting 'Events' counter together with the
> > 'active_objs' count from /proc/slabinfo and graph the pairs - see if
> > they are linear.
> >
> > I believe a BIO_RW_BARRIER is likely to send some sort of 'flush'
> > command to the device, and the driver for your particular device may
> > well be losing scsi_cmd_cache allocation when doing that, but I leave
> > that to someone how knows more about that code.
>
> I already checked up on that since I suspected barriers initially. The
> path there for scsi is sd.c:sd_issue_flush() which looks pretty straight
> forward. In the end it goes through the block layer and gets back to the
> SCSI layer as a regular REQ_BLOCK_PC request.
Sorry, that was for the ->issue_flush() that md also does but did before
the barrier addition as well. Most of the barrier handling is done in
the block layer, but it could show leaks in SCSI of course. FWIW, I
tested barriers with and without md on SCSI here a few days ago and
didn't see any leaks at all.
Chase, can you post full dmesg again? I don't have it, thanks.
--
Jens Axboe
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: More information on scsi_cmd_cache leak... (bisect)
2006-01-27 10:09 More information on scsi_cmd_cache leak... (bisect) Chase Venters
2006-01-27 11:11 ` Neil Brown
@ 2006-01-27 13:33 ` Alexey Dobriyan
2006-01-27 18:41 ` Ariel
2006-01-27 18:53 ` Ariel
3 siblings, 0 replies; 21+ messages in thread
From: Alexey Dobriyan @ 2006-01-27 13:33 UTC (permalink / raw)
To: Chase Venters
Cc: linux-kernel, linux-scsi, akpm, a.titov, axboe, askernel2615,
jamie, neilb
On Fri, Jan 27, 2006 at 04:09:44AM -0600, Chase Venters wrote:
> All bisect kernels were built from the same .config, and "make clean; make
> mrproper" was executed between each compile. (Do I really need to do that?
git bisect {good,bad}
make
should be enough.
First bisect steps usually result in full rebuild because some often
included header is patched.
> How does git handle timestamps? I assumed I didn't really need to but did it
> to be thorough).
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: More information on scsi_cmd_cache leak... (bisect)
2006-01-27 11:28 ` Jens Axboe
@ 2006-01-27 15:20 ` Chase Venters
2006-01-27 19:06 ` Mike Christie
1 sibling, 0 replies; 21+ messages in thread
From: Chase Venters @ 2006-01-27 15:20 UTC (permalink / raw)
To: Jens Axboe
Cc: Neil Brown, linux-kernel, linux-scsi, akpm, a.titov, askernel2615, jamie
[-- Attachment #1: Type: text/plain, Size: 462 bytes --]
On Friday 27 January 2006 05:28, Jens Axboe wrote:
> Sorry, that was for the ->issue_flush() that md also does but did before
> the barrier addition as well. Most of the barrier handling is done in
> the block layer, but it could show leaks in SCSI of course. FWIW, I
> tested barriers with and without md on SCSI here a few days ago and
> didn't see any leaks at all.
>
> Chase, can you post full dmesg again? I don't have it, thanks.
Attached.
Thanks,
Chase
[-- Attachment #2: dmesg --]
[-- Type: text/plain, Size: 32552 bytes --]
Linux version 2.6.15-ck1 (root@turbotaz) (gcc version 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)) #1 SMP PREEMPT Tue Jan 10 12:42:28 CST 2006
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000003ffb0000 (usable)
BIOS-e820: 000000003ffb0000 - 000000003ffbe000 (ACPI data)
BIOS-e820: 000000003ffbe000 - 000000003fff0000 (ACPI NVS)
BIOS-e820: 000000003fff0000 - 0000000040000000 (reserved)
BIOS-e820: 00000000ffb80000 - 0000000100000000 (reserved)
1023MB LOWMEM available.
found SMP MP-table at 000ff780
On node 0 totalpages: 262064
DMA zone: 4096 pages, LIFO batch:0
DMA32 zone: 0 pages, LIFO batch:0
Normal zone: 257968 pages, LIFO batch:31
HighMem zone: 0 pages, LIFO batch:0
DMI 2.3 present.
Intel MultiProcessor Specification v1.4
Virtual Wire compatibility mode.
OEM ID: INTEL Product ID: DELUXE APIC at: 0xFEE00000
Processor #0 15:4 APIC version 20
I/O APIC #2 Version 32 at 0xFEC00000.
Enabling APIC mode: Flat. Using 1 I/O APICs
Processors: 1
Allocating PCI resources starting at 50000000 (gap: 40000000:bfb80000)
Built 1 zonelists
Kernel command line: root=/dev/md1 noapic acpi=off console=ttyS0,38400n8 console=tty0
mapped APIC to ffffd000 (fee00000)
mapped IOAPIC to ffffc000 (fec00000)
Initializing CPU#0
CPU 0 irqstacks, hard=b0791000 soft=b078f000
PID hash table entries: 4096 (order: 12, 65536 bytes)
Detected 3212.691 MHz processor.
Using tsc for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 262144 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 131072 (order: 7, 524288 bytes)
Memory: 1030612k/1048256k available (4837k kernel code, 17088k reserved, 1597k data, 256k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 6429.42 BogoMIPS (lpj=3214711)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: bfebfbff 00000000 00000000 00000000 0000441d 00000000 00000000
CPU: After vendor identify, caps: bfebfbff 00000000 00000000 00000000 0000441d 00000000 00000000
monitor/mwait feature present.
using mwait in idle threads.
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 1024K
CPU: Physical Processor ID: 0
CPU: After all inits, caps: bfebfbff 00000000 00000000 00000080 0000441d 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU0: Intel P4/Xeon Extended MCE MSRs (12) available
CPU0: Thermal monitoring enabled
mtrr: v2.0 (20020519)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
CPU0: Intel(R) Pentium(R) 4 CPU 3.20GHz stepping 01
Total of 1 processors activated (6429.42 BogoMIPS).
Brought up 1 CPUs
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xf0031, last bus=4
PCI: Using configuration type 1
ACPI: Subsystem revision 20050902
ACPI: Interpreter disabled.
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI: disabled
Generic PHY: Registered new driver
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
Boot video device is 0000:04:00.0
PCI: Transparent bridge - 0000:00:1e.0
PCI: Discovered primary peer bus ff [IRQ]
PCI: Using IRQ router PIIX/ICH [8086/2640] at 0000:00:1f.0
PCI: IRQ 0 for device 0000:00:01.0 doesn't match PIRQ mask - try pci=usepirqmask
PCI: Found IRQ 10 for device 0000:00:01.0
PCI: Sharing IRQ 10 with 0000:00:1b.0
PCI: Sharing IRQ 10 with 0000:00:1c.0
PCI: Sharing IRQ 10 with 0000:00:1d.3
PCI: Sharing IRQ 10 with 0000:04:00.0
PCI: IRQ 0 for device 0000:00:1c.1 doesn't match PIRQ mask - try pci=usepirqmask
PCI: Found IRQ 5 for device 0000:00:1c.1
PCI: Sharing IRQ 5 with 0000:02:00.0
PCI: Sharing IRQ 5 with 0000:01:09.0
PCI: IRQ 0 for device 0000:00:1f.1 doesn't match PIRQ mask - try pci=usepirqmask
PCI: Found IRQ 5 for device 0000:00:1f.1
PCI: Sharing IRQ 5 with 0000:00:1d.2
PCI: Sharing IRQ 5 with 0000:01:09.2
PCI: IRQ 0 for device 0000:00:1f.3 doesn't match PIRQ mask - try pci=usepirqmask
PCI: Found IRQ 3 for device 0000:00:1f.3
PCI: Sharing IRQ 3 with 0000:00:1d.1
PCI: Sharing IRQ 3 with 0000:00:1f.2
PCI: Bridge: 0000:00:01.0
IO window: e000-efff
MEM window: cdf00000-cfffffff
PREFETCH window: d0000000-dfffffff
PCI: Bridge: 0000:00:1c.0
IO window: d000-dfff
MEM window: disabled.
PREFETCH window: disabled.
PCI: Bridge: 0000:00:1c.1
IO window: c000-cfff
MEM window: cde00000-cdefffff
PREFETCH window: disabled.
PCI: Bridge: 0000:00:1e.0
IO window: a000-bfff
MEM window: cdd00000-cddfffff
PREFETCH window: 50000000-500fffff
PCI: Found IRQ 10 for device 0000:00:01.0
PCI: Sharing IRQ 10 with 0000:00:1b.0
PCI: Sharing IRQ 10 with 0000:00:1c.0
PCI: Sharing IRQ 10 with 0000:00:1d.3
PCI: Sharing IRQ 10 with 0000:04:00.0
PCI: Setting latency timer of device 0000:00:01.0 to 64
PCI: Found IRQ 10 for device 0000:00:1c.0
PCI: Sharing IRQ 10 with 0000:00:01.0
PCI: Sharing IRQ 10 with 0000:00:1b.0
PCI: Sharing IRQ 10 with 0000:00:1d.3
PCI: Sharing IRQ 10 with 0000:04:00.0
PCI: Setting latency timer of device 0000:00:1c.0 to 64
PCI: Found IRQ 5 for device 0000:00:1c.1
PCI: Sharing IRQ 5 with 0000:02:00.0
PCI: Sharing IRQ 5 with 0000:01:09.0
PCI: Setting latency timer of device 0000:00:1c.1 to 64
PCI: Setting latency timer of device 0000:00:1e.0 to 64
Machine check exception polling timer started.
IA-32 Microcode Update Driver: v1.14 <tigran@veritas.com>
audit: initializing netlink socket (disabled)
audit(1138354673.738:1): initialized
Total HugeTLB memory allocated, 0
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
fuse init (API version 7.3)
JFS: nTxBlock = 8052, nTxLock = 64423
SGI XFS with ACLs, security attributes, large block numbers, no debug enabled
SGI XFS Quota Management subsystem
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
0000:00:1d.0: uhci_check_and_reset_hc: legsup = 0x0f30
0000:00:1d.0: Performing full reset
0000:00:1d.1: uhci_check_and_reset_hc: legsup = 0x0030
0000:00:1d.1: Performing full reset
0000:00:1d.2: uhci_check_and_reset_hc: legsup = 0x0030
0000:00:1d.2: Performing full reset
0000:00:1d.3: uhci_check_and_reset_hc: legsup = 0x0030
0000:00:1d.3: Performing full reset
0000:00:1d.7 EHCI: early BIOS handoff failed (BIOS bug ?)
PCI: Found IRQ 10 for device 0000:00:01.0
PCI: Sharing IRQ 10 with 0000:00:1b.0
PCI: Sharing IRQ 10 with 0000:00:1c.0
PCI: Sharing IRQ 10 with 0000:00:1d.3
PCI: Sharing IRQ 10 with 0000:04:00.0
PCI: Setting latency timer of device 0000:00:01.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[pcie00]
PCI: Found IRQ 10 for device 0000:00:1c.0
PCI: Sharing IRQ 10 with 0000:00:1b.0
PCI: Sharing IRQ 10 with 0000:00:1d.3
PCI: Sharing IRQ 10 with 0000:04:00.0
PCI: Setting latency timer of device 0000:00:1c.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[pcie00]
Allocate Port Service[pcie02]
PCI: Found IRQ 5 for device 0000:00:1c.1
PCI: Sharing IRQ 5 with 0000:02:00.0
PCI: Sharing IRQ 5 with 0000:01:09.0
PCI: Setting latency timer of device 0000:00:1c.1 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[pcie00]
Allocate Port Service[pcie02]
Real Time Clock Driver v1.12
Non-volatile memory driver v1.2
hw_random: RNG not detected
[drm] Initialized drm 1.0.0 20040925
PNP: No PS/2 controller found. Probing ports directly.
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
pktcdvd: v0.2.0a 2004-07-14 Jens Axboe (axboe@suse.de) and petero2@telia.com
Marvell 88E1101: Registered new driver
Davicom DM9161E: Registered new driver
Davicom DM9131: Registered new driver
Cicada Cis8204: Registered new driver
LXT970: Registered new driver
LXT971: Registered new driver
QS6612: Registered new driver
Linux video capture interface: v1.00
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH6: IDE controller at PCI slot 0000:00:1f.1
PCI: Found IRQ 5 for device 0000:00:1f.1
PCI: Sharing IRQ 5 with 0000:00:1d.2
PCI: Sharing IRQ 5 with 0000:01:09.2
ICH6: chipset revision 3
ICH6: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:pio, hdd:pio
Probing IDE interface ide0...
hda: PLEXTOR DVDR PX-716A, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
IT8212: IDE controller at PCI slot 0000:01:04.0
PCI: Found IRQ 11 for device 0000:01:04.0
PCI: Sharing IRQ 11 with 0000:00:1d.0
PCI: Sharing IRQ 11 with 0000:00:1d.7
IT8212: chipset revision 19
it821x: controller in pass through mode.
IT8212: 100% native mode on irq 11
ide2: BM-DMA at 0xa880-0xa887, BIOS settings: hde:pio, hdf:pio
ide3: BM-DMA at 0xa888-0xa88f, BIOS settings: hdg:pio, hdh:pio
Probing IDE interface ide2...
Probing IDE interface ide3...
Probing IDE interface ide1...
Probing IDE interface ide2...
Probing IDE interface ide3...
hda: ATAPI 40X DVD-ROM DVD-R CD-R/RW drive, 8192kB Cache, UDMA(66)
Uniform CD-ROM driver Revision: 3.20
PCI: Found IRQ 11 for device 0000:01:0a.0
PCI: Sharing IRQ 11 with 0000:01:03.0
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
<Adaptec 2902/04/10/15/20C/30C SCSI adapter>
aic7850: Ultra Single Channel A, SCSI Id=7, 3/253 SCBs
Vendor: PLEXTOR Model: CD-R PX-W124TS Rev: 1.07
Type: CD-ROM ANSI SCSI revision: 02
target0:0:4: Beginning Domain Validation
target0:0:4: FAST-20 SCSI 20.0 MB/s ST (50 ns, offset 8)
target0:0:4: Domain Validation skipping write tests
target0:0:4: Ending Domain Validation
libata version 1.20 loaded.
ata_piix 0000:00:1f.2: version 1.05
PCI: Found IRQ 3 for device 0000:00:1f.2
PCI: Sharing IRQ 3 with 0000:00:1d.1
PCI: Sharing IRQ 3 with 0000:00:1f.3
PCI: Setting latency timer of device 0000:00:1f.2 to 64
ata1: SATA max UDMA/133 cmd 0x9C00 ctl 0x9882 bmdma 0x9400 irq 3
ata2: SATA max UDMA/133 cmd 0x9800 ctl 0x9482 bmdma 0x9408 irq 3
ata1: dev 0 cfg 49:2f00 82:346b 83:7f01 84:4003 85:3469 86:3e01 87:4003 88:203f
ata1: dev 0 ATA-6, max UDMA/100, 625142448 sectors: LBA48
ata1: dev 1 cfg 49:2f00 82:306b 83:7e01 84:4003 85:3069 86:3c01 87:4003 88:203f
ata1: dev 1 ATA-6, max UDMA/100, 625142448 sectors: LBA48
ata1: dev 0 configured for UDMA/100
ata1: dev 1 configured for UDMA/100
scsi1 : ata_piix
ata2: dev 0 cfg 49:2f00 82:306b 83:7e01 84:4003 85:3069 86:3c01 87:4003 88:203f
ata2: dev 0 ATA-6, max UDMA/100, 625142448 sectors: LBA48
ata2: dev 1 cfg 49:2f00 82:346b 83:7f01 84:4003 85:3469 86:3c01 87:4003 88:203f
ata2: dev 1 ATA-6, max UDMA/100, 625142448 sectors: LBA48
ata2: dev 0 configured for UDMA/100
ata2: dev 1 configured for UDMA/100
scsi2 : ata_piix
Vendor: ATA Model: WDC WD3200JD-98K Rev: 08.0
Type: Direct-Access ANSI SCSI revision: 05
Vendor: ATA Model: WDC WD3200JD-60K Rev: 08.0
Type: Direct-Access ANSI SCSI revision: 05
Vendor: ATA Model: WDC WD3200JD-60K Rev: 08.0
Type: Direct-Access ANSI SCSI revision: 05
Vendor: ATA Model: WDC WD3200JD-00K Rev: 08.0
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sda: 625142448 512-byte hdwr sectors (320073 MB)
SCSI device sda: drive cache: write back
SCSI device sda: 625142448 512-byte hdwr sectors (320073 MB)
SCSI device sda: drive cache: write back
sda: sda1 sda2 sda3
sd 1:0:0:0: Attached scsi disk sda
SCSI device sdb: 625142448 512-byte hdwr sectors (320073 MB)
SCSI device sdb: drive cache: write back
SCSI device sdb: 625142448 512-byte hdwr sectors (320073 MB)
SCSI device sdb: drive cache: write back
sdb: sdb1 sdb2 sdb3
sd 1:0:1:0: Attached scsi disk sdb
SCSI device sdc: 625142448 512-byte hdwr sectors (320073 MB)
SCSI device sdc: drive cache: write back
SCSI device sdc: 625142448 512-byte hdwr sectors (320073 MB)
SCSI device sdc: drive cache: write back
sdc: sdc1 sdc2 sdc3
sd 2:0:0:0: Attached scsi disk sdc
SCSI device sdd: 625142448 512-byte hdwr sectors (320073 MB)
SCSI device sdd: drive cache: write back
SCSI device sdd: 625142448 512-byte hdwr sectors (320073 MB)
SCSI device sdd: drive cache: write back
sdd: sdd1 sdd2 sdd3
sd 2:0:1:0: Attached scsi disk sdd
sr0: scsi3-mmc drive: 32x/32x writer cd/rw xa/form2 cdda tray
sr 0:0:4:0: Attached scsi CD-ROM sr0
sr 0:0:4:0: Attached scsi generic sg0 type 5
sd 1:0:0:0: Attached scsi generic sg1 type 0
sd 1:0:1:0: Attached scsi generic sg2 type 0
sd 2:0:0:0: Attached scsi generic sg3 type 0
sd 2:0:1:0: Attached scsi generic sg4 type 0
ehci_hcd: block sizes: qh 128 qtd 96 itd 192 sitd 96
PCI: Found IRQ 11 for device 0000:00:1d.7
PCI: Sharing IRQ 11 with 0000:00:1d.0
PCI: Sharing IRQ 11 with 0000:01:04.0
PCI: Setting latency timer of device 0000:00:1d.7 to 64
ehci_hcd 0000:00:1d.7: EHCI Host Controller
ehci_hcd 0000:00:1d.7: reset hcs_params 0x104208 dbg=1 cc=4 pcc=2 ordered !ppc ports=8
ehci_hcd 0000:00:1d.7: reset hcc_params 6871 thresh 7 uframes 1024 64 bit addr
ehci_hcd 0000:00:1d.7: debug port 1
ehci_hcd 0000:00:1d.7: capability 1000001 at 68
PCI: cache line size of 128 is not supported by device 0000:00:1d.7
drivers/usb/core/inode.c: creating file 'devices'
drivers/usb/core/inode.c: creating file '001'
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:1d.7: irq 11, io mem 0xcdcff800
ehci_hcd 0000:00:1d.7: reset command 080012 (park)=0 ithresh=8 Periodic period=1024 Reset HALT
ehci_hcd 0000:00:1d.7: init command 010001 (park)=0 ithresh=1 period=1024 RUN
ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: default language 0x0409
usb usb1: new device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: EHCI Host Controller
usb usb1: Manufacturer: Linux 2.6.15-ck1 ehci_hcd
usb usb1: SerialNumber: 0000:00:1d.7
usb usb1: hotplug
usb usb1: adding 1-0:1.0 (config #1, interface 0)
usb 1-0:1.0: hotplug
hub 1-0:1.0: usb_probe_interface
hub 1-0:1.0: usb_probe_interface - got id
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 8 ports detected
hub 1-0:1.0: standalone hub
hub 1-0:1.0: no power switching (usb 1.0)
hub 1-0:1.0: individual port over-current protection
hub 1-0:1.0: Single TT
hub 1-0:1.0: TT requires at most 8 FS bit times (666 ns)
hub 1-0:1.0: power on to power good time: 20ms
hub 1-0:1.0: local power source is good
hub 1-0:1.0: state 5 ports 8 chg 0000 evt 0000
drivers/usb/core/inode.c: creating file '001'
ehci_hcd 0000:00:1d.7: GetStatus port 2 status 001803 POWER sig=j CSC CONNECT
hub 1-0:1.0: port 2, status 0501, change 0001, 480 Mb/s
USB Universal Host Controller Interface driver v2.3
PCI: Found IRQ 11 for device 0000:00:1d.0
PCI: Sharing IRQ 11 with 0000:00:1d.7
PCI: Sharing IRQ 11 with 0000:01:04.0
PCI: Setting latency timer of device 0000:00:1d.0 to 64
uhci_hcd 0000:00:1d.0: UHCI Host Controller
uhci_hcd 0000:00:1d.0: detected 2 ports
uhci_hcd 0000:00:1d.0: uhci_check_and_reset_hc: cmd = 0x0000
uhci_hcd 0000:00:1d.0: Performing full reset
drivers/usb/core/inode.c: creating file '002'
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:1d.0: irq 11, io base 0x00008880
usb usb2: default language 0x0409
usb usb2: new device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: UHCI Host Controller
hub 1-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x501
usb usb2: Manufacturer: Linux 2.6.15-ck1 uhci_hcd
usb usb2: SerialNumber: 0000:00:1d.0
usb usb2: hotplug
usb usb2: adding 2-0:1.0 (config #1, interface 0)
usb 2-0:1.0: hotplug
hub 2-0:1.0: usb_probe_interface
hub 2-0:1.0: usb_probe_interface - got id
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
hub 2-0:1.0: standalone hub
hub 2-0:1.0: no power switching (usb 1.0)
hub 2-0:1.0: individual port over-current protection
hub 2-0:1.0: power on to power good time: 2ms
hub 2-0:1.0: local power source is good
ehci_hcd 0000:00:1d.7: port 2 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 1-2: new high speed USB device using ehci_hcd and address 2
drivers/usb/core/inode.c: creating file '001'
PCI: Found IRQ 3 for device 0000:00:1d.1
PCI: Sharing IRQ 3 with 0000:00:1f.2
PCI: Sharing IRQ 3 with 0000:00:1f.3
ehci_hcd 0000:00:1d.7: port 2 high speed
ehci_hcd 0000:00:1d.7: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
PCI: Setting latency timer of device 0000:00:1d.1 to 64
uhci_hcd 0000:00:1d.1: UHCI Host Controller
uhci_hcd 0000:00:1d.1: detected 2 ports
uhci_hcd 0000:00:1d.1: uhci_check_and_reset_hc: cmd = 0x0000
uhci_hcd 0000:00:1d.1: Performing full reset
drivers/usb/core/inode.c: creating file '003'
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:1d.1: irq 3, io base 0x00008c00
usb usb3: default language 0x0409
usb usb3: new device strings: Mfr=3, Product=2, SerialNumber=1
usb usb3: Product: UHCI Host Controller
usb usb3: Manufacturer: Linux 2.6.15-ck1 uhci_hcd
usb usb3: SerialNumber: 0000:00:1d.1
usb usb3: hotplug
usb usb3: adding 3-0:1.0 (config #1, interface 0)
usb 3-0:1.0: hotplug
hub 3-0:1.0: usb_probe_interface
hub 3-0:1.0: usb_probe_interface - got id
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
hub 3-0:1.0: standalone hub
hub 3-0:1.0: no power switching (usb 1.0)
hub 3-0:1.0: individual port over-current protection
hub 3-0:1.0: power on to power good time: 2ms
hub 3-0:1.0: local power source is good
usb 1-2: default language 0x0409
usb 1-2: new device strings: Mfr=0, Product=1, SerialNumber=0
usb 1-2: Product: USB2.0 Hub
usb 1-2: hotplug
usb 1-2: adding 1-2:1.0 (config #1, interface 0)
usb 1-2:1.0: hotplug
hub 1-2:1.0: usb_probe_interface
hub 1-2:1.0: usb_probe_interface - got id
hub 1-2:1.0: USB hub found
hub 1-2:1.0: 4 ports detected
hub 1-2:1.0: standalone hub
hub 1-2:1.0: individual port power switching
hub 1-2:1.0: individual port over-current protection
hub 1-2:1.0: Single TT
hub 1-2:1.0: TT requires at most 32 FS bit times (2664 ns)
hub 1-2:1.0: Port indicators are supported
hub 1-2:1.0: power on to power good time: 100ms
hub 1-2:1.0: local power source is good
hub 1-2:1.0: enabling power on all ports
drivers/usb/core/inode.c: creating file '001'
PCI: Found IRQ 5 for device 0000:00:1d.2
PCI: Sharing IRQ 5 with 0000:00:1f.1
PCI: Sharing IRQ 5 with 0000:01:09.2
usb 1-2: link qh256-0001/efad4100 start 255 [1/0 us]
drivers/usb/core/inode.c: creating file '002'
ehci_hcd 0000:00:1d.7: GetStatus port 5 status 001403 POWER sig=k CSC CONNECT
hub 1-0:1.0: port 5, status 0501, change 0001, 480 Mb/s
PCI: Setting latency timer of device 0000:00:1d.2 to 64
uhci_hcd 0000:00:1d.2: UHCI Host Controller
uhci_hcd 0000:00:1d.2: detected 2 ports
uhci_hcd 0000:00:1d.2: uhci_check_and_reset_hc: cmd = 0x0000
uhci_hcd 0000:00:1d.2: Performing full reset
drivers/usb/core/inode.c: creating file '004'
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4
uhci_hcd 0000:00:1d.2: irq 5, io base 0x00009000
usb usb4: default language 0x0409
usb usb4: new device strings: Mfr=3, Product=2, SerialNumber=1
usb usb4: Product: UHCI Host Controller
usb usb4: Manufacturer: Linux 2.6.15-ck1 uhci_hcd
usb usb4: SerialNumber: 0000:00:1d.2
usb usb4: hotplug
usb usb4: adding 4-0:1.0 (config #1, interface 0)
usb 4-0:1.0: hotplug
hub 4-0:1.0: usb_probe_interface
hub 4-0:1.0: usb_probe_interface - got id
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
hub 4-0:1.0: standalone hub
hub 4-0:1.0: no power switching (usb 1.0)
hub 4-0:1.0: individual port over-current protection
hub 4-0:1.0: power on to power good time: 2ms
hub 4-0:1.0: local power source is good
hub 1-0:1.0: debounce: port 5: total 100ms stable 100ms status 0x501
ehci_hcd 0000:00:1d.7: port 5 low speed --> companion
ehci_hcd 0000:00:1d.7: GetStatus port 5 status 003002 POWER OWNER sig=se0 CSC
hub 1-0:1.0: state 5 ports 8 chg 0000 evt 0000
hub 2-0:1.0: state 5 ports 2 chg 0000 evt 0004
uhci_hcd 0000:00:1d.0: port 2 portsc 0082,00
hub 2-0:1.0: port 2, status 0100, change 0001, 12 Mb/s
drivers/usb/core/inode.c: creating file '001'
PCI: Found IRQ 10 for device 0000:00:1d.3
PCI: Sharing IRQ 10 with 0000:00:1b.0
PCI: Sharing IRQ 10 with 0000:04:00.0
PCI: Setting latency timer of device 0000:00:1d.3 to 64
uhci_hcd 0000:00:1d.3: UHCI Host Controller
uhci_hcd 0000:00:1d.3: detected 2 ports
uhci_hcd 0000:00:1d.3: uhci_check_and_reset_hc: cmd = 0x0000
uhci_hcd 0000:00:1d.3: Performing full reset
drivers/usb/core/inode.c: creating file '005'
uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 5
hub 2-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x100
hub 3-0:1.0: state 5 ports 2 chg 0000 evt 0000
hub 1-2:1.0: state 5 ports 4 chg 0000 evt 0018
uhci_hcd 0000:00:1d.3: irq 10, io base 0x00009080
usb usb5: default language 0x0409
usb usb5: new device strings: Mfr=3, Product=2, SerialNumber=1
usb usb5: Product: UHCI Host Controller
usb usb5: Manufacturer: Linux 2.6.15-ck1 uhci_hcd
usb usb5: SerialNumber: 0000:00:1d.3
usb usb5: hotplug
usb usb5: adding 5-0:1.0 (config #1, interface 0)
usb 5-0:1.0: hotplug
hub 5-0:1.0: usb_probe_interface
hub 5-0:1.0: usb_probe_interface - got id
hub 5-0:1.0: USB hub found
hub 1-2:1.0: port 3, status 0301, change 0001, 1.5 Mb/s
hub 5-0:1.0: 2 ports detected
hub 5-0:1.0: standalone hub
hub 5-0:1.0: no power switching (usb 1.0)
hub 5-0:1.0: individual port over-current protection
hub 5-0:1.0: power on to power good time: 2ms
hub 5-0:1.0: local power source is good
drivers/usb/core/inode.c: creating file '001'
hub 1-2:1.0: debounce: port 3: total 100ms stable 100ms status 0x301
hub 1-2:1.0: port 3 not reset yet, waiting 10ms
usb 1-2.3: new low speed USB device using ehci_hcd and address 4
hub 1-2:1.0: port 3 not reset yet, waiting 10ms
usb 1-2.3: skipped 1 descriptor after interface
usb 1-2.3: default language 0x0409
usb 1-2.3: new device strings: Mfr=4, Product=26, SerialNumber=0
usb 1-2.3: Product: Keytronic USB Keyboard
usb 1-2.3: Manufacturer: Key Tronic
usb 1-2.3: hotplug
usb 1-2.3: adding 1-2.3:1.0 (config #1, interface 0)
usb 1-2.3:1.0: hotplug
usb 1-2.3: wrong descriptor type 00 for string 20 ("ic?Keytronic USB Keyboard?1234???????????????????????©")
drivers/usb/core/inode.c: creating file '004'
hub 1-2:1.0: port 4, status 0301, change 0001, 1.5 Mb/s
hub 1-2:1.0: debounce: port 4: total 100ms stable 100ms status 0x301
hub 1-2:1.0: port 4 not reset yet, waiting 10ms
usb 1-2.4: new low speed USB device using ehci_hcd and address 5
hub 1-2:1.0: port 4 not reset yet, waiting 10ms
usb 1-2.4: skipped 1 descriptor after interface
usb 1-2.4: default language 0x0409
usb 1-2.4: new device strings: Mfr=0, Product=1, SerialNumber=0
usb 1-2.4: Product: USB Mouse
usb 1-2.4: hotplug
usb 1-2.4: adding 1-2.4:1.0 (config #1, interface 0)
usb 1-2.4:1.0: hotplug
drivers/usb/core/inode.c: creating file '005'
hub 4-0:1.0: state 5 ports 2 chg 0000 evt 0002
uhci_hcd 0000:00:1d.2: port 1 portsc 01a3,00
uhci_hcd 0000:00:1d.1: suspend_rh (auto-stop)
hub 4-0:1.0: port 1, status 0301, change 0001, 1.5 Mb/s
usbcore: registered new driver usblp
drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver
Initializing USB Mass Storage driver...
hub 4-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x301
usb 4-1: new low speed USB device using uhci_hcd and address 2
uhci_hcd 0000:00:1d.0: suspend_rh (auto-stop)
usb 4-1: skipped 1 descriptor after interface
usb 4-1: default language 0x0409
uhci_hcd 0000:00:1d.3: suspend_rh (auto-stop)
usb 4-1: new device strings: Mfr=3, Product=1, SerialNumber=2
usb 4-1: Product: Back-UPS RS 1000 FW:7.g8 .D USB FW:g8
usb 4-1: Manufacturer: American Power Conversion
usb 4-1: SerialNumber: QB0507149462
usb 4-1: hotplug
usb 4-1: adding 4-1:1.0 (config #1, interface 0)
usb 4-1:1.0: hotplug
drivers/usb/core/inode.c: creating file '002'
hub 1-2:1.0: state 5 ports 4 chg 0000 evt 0010
usbcore: registered new driver usb-storage
hub 5-0:1.0: state 5 ports 2 chg 0000 evt 0000
USB Mass Storage support registered.
usbcore: registered new driver ati_remote
drivers/usb/input/ati_remote.c: Registered USB driver ATI/X10 RF USB Remote Control v. 2.2.1
usbcore: registered new driver hiddev
usbhid 1-2.3:1.0: usb_probe_interface
usbhid 1-2.3:1.0: usb_probe_interface - got id
input: Key Tronic Keytronic USB Keyboard as /class/input/input0
usb 1-2.3: link qh8-0601/efad4280 start 7 [1/2 us]
input: USB HID v1.10 Keyboard [Key Tronic Keytronic USB Keyboard] on usb-0000:00:1d.7-2.3
usbhid 1-2.4:1.0: usb_probe_interface
usbhid 1-2.4:1.0: usb_probe_interface - got id
input: USB Mouse as /class/input/input1
input: USB HID v1.00 Mouse [USB Mouse] on usb-0000:00:1d.7-2.4
usbhid 4-1:1.0: usb_probe_interface
usbhid 4-1:1.0: usb_probe_interface - got id
drivers/usb/core/file.c: looking for a minor, starting at 0
hiddev0: USB HID v1.10 Device [American Power Conversion Back-UPS RS 1000 FW:7.g8 .D USB FW:g8 ] on usb-0000:00:1d.2-1
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
usbcore: registered new driver usbserial
drivers/usb/serial/usb-serial.c: USB Serial support registered for generic
usbcore: registered new driver usbserial_generic
drivers/usb/serial/usb-serial.c: USB Serial Driver core
gameport: EMU10K1 is pci0000:01:09.1/gameport0, io 0xbc00, speed 932kHz
mice: PS/2 mouse device common for all mice
input: PC Speaker as /class/input/input2
I2O subsystem v1.288
i2o: max drivers = 8
I2O Configuration OSM v1.248
I2O Bus Adapter OSM v$Rev$
I2O Block Device OSM v1.287
I2O SCSI Peripheral OSM v1.282
I2O ProcFS OSM v1.145
i2c /dev entries driver
md: linear personality registered as nr 1
md: raid0 personality registered as nr 2
md: raid1 personality registered as nr 3
md: raid10 personality registered as nr 9
md: raid5 personality registered as nr 4
raid5: automatically using best checksumming function: pIII_sse
pIII_sse : 4744.000 MB/sec
raid5: using function: pIII_sse (4744.000 MB/sec)
raid6: int32x1 925 MB/s
raid6: int32x2 996 MB/s
raid6: int32x4 726 MB/s
raid6: int32x8 609 MB/s
raid6: mmxx1 1957 MB/s
raid6: mmxx2 2269 MB/s
raid6: sse1x1 1164 MB/s
raid6: sse1x2 1246 MB/s
raid6: sse2x1 2226 MB/s
raid6: sse2x2 2402 MB/s
raid6: using algorithm sse2x2 (2402 MB/s)
md: raid6 personality registered as nr 8
md: multipath personality registered as nr 7
md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 4.39
device-mapper: 4.4.0-ioctl (2005-01-12) initialised: dm-devel@redhat.com
device-mapper: dm-multipath version 1.0.4 loaded
device-mapper: dm-round-robin version 1.0.0 loaded
device-mapper: dm-emc version 0.0.3 loaded
wbsd: Winbond W83L51xD SD/MMC card interface driver, 1.5
wbsd: Copyright(c) Pierre Ossman
padlock: VIA PadLock not detected.
oprofile: using NMI interrupt.
NET: Registered protocol family 2
IP route cache hash table entries: 65536 (order: 6, 262144 bytes)
TCP established hash table entries: 262144 (order: 9, 3145728 bytes)
TCP bind hash table entries: 65536 (order: 7, 786432 bytes)
TCP: Hash tables configured (established 262144 bind 65536)
TCP reno registered
IPv4 over IPv4 tunneling driver
GRE over IPv4 tunneling driver
TCP bic registered
Initializing IPsec netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
NET: Registered protocol family 15
Bridge firewalling registered
802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
All bugs added by David S. Miller <davem@redhat.com>
CCID: Registered CCID 3 (ccid3)
Using IPI Shortcut mode
md: Autodetecting RAID arrays.
md: autorun ...
md: considering sdd3 ...
md: adding sdd3 ...
md: sdd1 has different UUID to sdd3
md: adding sdc3 ...
md: sdc1 has different UUID to sdd3
md: adding sdb3 ...
md: sdb1 has different UUID to sdd3
md: adding sda3 ...
md: sda1 has different UUID to sdd3
md: created md1
md: bind<sda3>
md: bind<sdb3>
md: bind<sdc3>
md: bind<sdd3>
md: running: <sdd3><sdc3><sdb3><sda3>
md: md1: raid array is not clean -- starting background reconstruction
raid10: raid set md1 active with 4 out of 4 devices
md: syncing RAID array md1
md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction.
md: using 128k window, over a total of 622920192 blocks.
md: considering sdd1 ...
md: adding sdd1 ...
md: adding sdc1 ...
md: adding sdb1 ...
md: adding sda1 ...
md: created md0
md: bind<sda1>
md: bind<sdb1>
md: bind<sdc1>
md: bind<sdd1>
md: running: <sdd1><sdc1><sdb1><sda1>
raid1: raid set md0 active with 4 out of 4 mirrors
md: ... autorun DONE.
ReiserFS: md1: found reiserfs format "3.6" with standard journal
ReiserFS: md1: using ordered data mode
ReiserFS: md1: journal params: device md1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: md1: checking transaction log (md1)
ReiserFS: md1: Using r5 hash to sort names
VFS: Mounted root (reiserfs filesystem) readonly.
Freeing unused kernel memory: 256k freed
Adding 1004052k swap on /dev/sda2. Priority:-1 extents:1 across:1004052k
Adding 1004052k swap on /dev/sdb2. Priority:-2 extents:1 across:1004052k
PCI: Found IRQ 5 for device 0000:02:00.0
PCI: Sharing IRQ 5 with 0000:01:09.0
sk98lin: Network Device Driver v8.23.1.3
(C)Copyright 1999-2005 Marvell(R).
PCI: Found IRQ 5 for device 0000:02:00.0
PCI: Sharing IRQ 5 with 0000:01:09.0
PCI: Setting latency timer of device 0000:02:00.0 to 64
eth0: Yukon Gigabit Ethernet 10/100/1000Base-T Adapter
PrefPort:A RlmtMode:Check Link State
PCI: Found IRQ 10 for device 0000:00:1b.0
PCI: Sharing IRQ 10 with 0000:00:1d.3
PCI: Sharing IRQ 10 with 0000:04:00.0
PCI: Setting latency timer of device 0000:00:1b.0 to 64
nvidia: no version for "struct_module" found: kernel tainted.
nvidia: module license 'NVIDIA' taints kernel.
PCI: Found IRQ 10 for device 0000:04:00.0
PCI: Sharing IRQ 10 with 0000:00:1b.0
PCI: Sharing IRQ 10 with 0000:00:1d.3
PCI: Setting latency timer of device 0000:04:00.0 to 64
NVRM: loading NVIDIA Linux x86 NVIDIA Kernel Module 1.0-7676 Fri Jul 29 12:58:54 PDT 2005
ADDRCONF(NETDEV_UP): eth0: link is not ready
eth0: network connection up using port A
speed: 100
autonegotiation: yes
duplex mode: full
flowctrl: none
irq moderation: disabled
tcp offload: enabled
scatter-gather: enabled
tx-checksum: enabled
rx-checksum: enabled
rx-polling: enabled
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
cdrom: open failed.
eth0: no IPv6 routers present
usb 1-2.4: link qh8-3008/efad4300 start 7 [1/2 us]
usb 1-2.4: unlink qh8-3008/efad4300 start 7 [1/2 us]
ehci_hcd 0000:00:1d.7: reused qh efad4300 schedule
usb 1-2.4: link qh8-3008/efad4300 start 7 [1/2 us]
md: md1: sync done.
RAID10 conf printout:
--- wd:4 rd:4
disk 0, wo:0, o:1, dev:sdc3
disk 1, wo:0, o:1, dev:sdd3
disk 2, wo:0, o:1, dev:sdb3
disk 3, wo:0, o:1, dev:sda3
spurious 8259A interrupt: IRQ7.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: More information on scsi_cmd_cache leak... (bisect)
2006-01-27 10:09 More information on scsi_cmd_cache leak... (bisect) Chase Venters
2006-01-27 11:11 ` Neil Brown
2006-01-27 13:33 ` Alexey Dobriyan
@ 2006-01-27 18:41 ` Ariel
2006-01-27 18:58 ` Chase Venters
2006-01-27 21:07 ` Neil Brown
2006-01-27 18:53 ` Ariel
3 siblings, 2 replies; 21+ messages in thread
From: Ariel @ 2006-01-27 18:41 UTC (permalink / raw)
To: Chase Venters
Cc: linux-kernel, linux-scsi, akpm, a.titov, axboe, jamie, neilb, arjan
On Fri, 27 Jan 2006, Chase Venters wrote:
> After dealing with this leak for a while, I decided to do some dancing around
> with git bisect. I've landed on a possible point of regression:
>
> commit: a9701a30470856408d08657eb1bd7ae29a146190
> [PATCH] md: support BIO_RW_BARRIER for md/raid1
I can confirm that it only leaks with raid!
I rebooted with my raid5 root, read only, and it didn't leak. As soon as I
remount,rw it started leaking. Go back to ro and it stopped (although it
didn't clean up the old leaks). Tried my raid1 /boot and same thing - rw
leaks, ro doesn't. But, it only leaks on activity.
I then tried a regular lvm mount (with root ro), and no leaks!
What's interesting is that the mount was ro NOT the md (which can be set
ro independently). So it looks like it only leaks if you write to the md
device, and that's why setting the mount ro stopped the leaks.
-Ariel
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: More information on scsi_cmd_cache leak... (bisect)
2006-01-27 10:09 More information on scsi_cmd_cache leak... (bisect) Chase Venters
` (2 preceding siblings ...)
2006-01-27 18:41 ` Ariel
@ 2006-01-27 18:53 ` Ariel
3 siblings, 0 replies; 21+ messages in thread
From: Ariel @ 2006-01-27 18:53 UTC (permalink / raw)
To: Chase Venters
Cc: linux-kernel, linux-scsi, akpm, a.titov, axboe, jamie, neilb, arjan
I found a patch called: slab-leak-detector.patch and applied it (manually
since it's for a slightly older kernel).
Here are the results: (after leaking about 1MB)
c03741ba <__scsi_get_command+0x29/0x73>
Is the leaker with 294 of them, vs 4 of:
c03743fd <scsi_setup_command_freelist+0xb0/0x101>
and 21:
fffffffe <0xfffffffe>
I'm not sure how helpful that result is though, since I guess we already
knew it was scsi, and from the other email, that's it's also some
interaction with md.
-Ariel
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: More information on scsi_cmd_cache leak... (bisect)
2006-01-27 18:41 ` Ariel
@ 2006-01-27 18:58 ` Chase Venters
2006-01-27 21:07 ` Neil Brown
1 sibling, 0 replies; 21+ messages in thread
From: Chase Venters @ 2006-01-27 18:58 UTC (permalink / raw)
To: Ariel
Cc: Chase Venters, linux-kernel, linux-scsi, akpm, a.titov, axboe,
jamie, neilb, arjan
On Fri, 27 Jan 2006, Ariel wrote:
>
> On Fri, 27 Jan 2006, Chase Venters wrote:
>
>> After dealing with this leak for a while, I decided to do some
>> dancing around
>> with git bisect. I've landed on a possible point of regression:
>>
>> commit: a9701a30470856408d08657eb1bd7ae29a146190
>> [PATCH] md: support BIO_RW_BARRIER for md/raid1
>
> I can confirm that it only leaks with raid!
>
> I rebooted with my raid5 root, read only, and it didn't leak. As soon as I
> remount,rw it started leaking. Go back to ro and it stopped (although it
> didn't clean up the old leaks). Tried my raid1 /boot and same thing - rw
> leaks, ro doesn't. But, it only leaks on activity.
>
> I then tried a regular lvm mount (with root ro), and no leaks!
>
> What's interesting is that the mount was ro NOT the md (which can be set ro
> independently). So it looks like it only leaks if you write to the md device,
> and that's why setting the mount ro stopped the leaks.
Yeah, if the mount is ro, md won't have any reasons to write the
superblock any more, which means it won't be sending out bio's with
barriers any more.
I'm in the middle of a crash course on block IO and SATA, but hopefully
some more skillful devs will beat me to the punch :)
> -Ariel
Cheers,
Chase
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: More information on scsi_cmd_cache leak... (bisect)
2006-01-27 11:28 ` Jens Axboe
2006-01-27 15:20 ` Chase Venters
@ 2006-01-27 19:06 ` Mike Christie
2006-01-27 19:16 ` Jens Axboe
2006-01-27 19:20 ` James Bottomley
1 sibling, 2 replies; 21+ messages in thread
From: Mike Christie @ 2006-01-27 19:06 UTC (permalink / raw)
To: Jens Axboe
Cc: Neil Brown, Chase Venters, linux-kernel, linux-scsi, akpm,
a.titov, askernel2615, jamie
Jens Axboe wrote:
> On Fri, Jan 27 2006, Jens Axboe wrote:
>
>>On Fri, Jan 27 2006, Neil Brown wrote:
>>
>>>On Friday January 27, chase.venters@clientec.com wrote:
>>>
>>>>Greetings,
>>>> Just a quick recap - there are at least 4 reports of 2.6.15 users
>>>>experiencing severe slab leaks with scsi_cmd_cache. It seems that a few of us
>>>>have a board (Asus P5GDC-V Deluxe) in common. We seem to have raid in common.
>>>> After dealing with this leak for a while, I decided to do some dancing around
>>>>with git bisect. I've landed on a possible point of regression:
>>>>
>>>>commit: a9701a30470856408d08657eb1bd7ae29a146190
>>>>[PATCH] md: support BIO_RW_BARRIER for md/raid1
>>>>
>>>> I spent about an hour and a half reading through the patch, trying to see if
>>>>I could make sense of what might be wrong. The result (after I dug into the
>>>>code to make a change I foolishly thought made sense) was a hung kernel.
>>>> This is important because when I rebooted into the kernel that had been
>>>>giving me trouble, it started an md resync and I'm now watching (at least
>>>>during this resync) the slab usage for scsi_cmd_cache stay sane:
>>>>
>>>>turbotaz ~ # cat /proc/slabinfo | grep scsi_cmd_cache
>>>>scsi_cmd_cache 30 30 384 10 1 : tunables 54 27 8 :
>>>>slabdata 3 3 0
>>>>
>>>
>>>This suggests that the problem happens when a BIO_RW_BARRIER write is
>>>sent to the device. With this patch, md flags all superblock writes
>>>as BIO_RW_BARRIER However md is not so likely to update the superblock often
>>>during a resync.
>>>
>>>There is a (rough) count of the number of superblock writes in the
>>>"Events" counter which "mdadm -D" will display.
>>>You could try collecting 'Events' counter together with the
>>>'active_objs' count from /proc/slabinfo and graph the pairs - see if
>>>they are linear.
>>>
>>>I believe a BIO_RW_BARRIER is likely to send some sort of 'flush'
>>>command to the device, and the driver for your particular device may
>>>well be losing scsi_cmd_cache allocation when doing that, but I leave
>>>that to someone how knows more about that code.
>>
>>I already checked up on that since I suspected barriers initially. The
>>path there for scsi is sd.c:sd_issue_flush() which looks pretty straight
>>forward. In the end it goes through the block layer and gets back to the
>>SCSI layer as a regular REQ_BLOCK_PC request.
>
>
> Sorry, that was for the ->issue_flush() that md also does but did before
> the barrier addition as well. Most of the barrier handling is done in
> the block layer, but it could show leaks in SCSI of course. FWIW, I
> tested barriers with and without md on SCSI here a few days ago and
> didn't see any leaks at all.
>
It does not have anything to do with this in scsi_io_completion does it?
if (blk_complete_barrier_rq(q, req, good_bytes >> 9))
return;
For that case the scsi_cmnd does not get freed. Does it come back around
again and get released from a different path?
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: More information on scsi_cmd_cache leak... (bisect)
2006-01-27 19:06 ` Mike Christie
@ 2006-01-27 19:16 ` Jens Axboe
2006-01-27 19:20 ` James Bottomley
1 sibling, 0 replies; 21+ messages in thread
From: Jens Axboe @ 2006-01-27 19:16 UTC (permalink / raw)
To: Mike Christie
Cc: Neil Brown, Chase Venters, linux-kernel, linux-scsi, akpm,
a.titov, askernel2615, jamie
On Fri, Jan 27 2006, Mike Christie wrote:
> Jens Axboe wrote:
> >On Fri, Jan 27 2006, Jens Axboe wrote:
> >
> >>On Fri, Jan 27 2006, Neil Brown wrote:
> >>
> >>>On Friday January 27, chase.venters@clientec.com wrote:
> >>>
> >>>>Greetings,
> >>>> Just a quick recap - there are at least 4 reports of 2.6.15 users
> >>>>experiencing severe slab leaks with scsi_cmd_cache. It seems that a few
> >>>>of us have a board (Asus P5GDC-V Deluxe) in common. We seem to have
> >>>>raid in common. After dealing with this leak for a while, I decided
> >>>> to do some dancing around with git bisect. I've landed on a possible
> >>>>point of regression:
> >>>>
> >>>>commit: a9701a30470856408d08657eb1bd7ae29a146190
> >>>>[PATCH] md: support BIO_RW_BARRIER for md/raid1
> >>>>
> >>>> I spent about an hour and a half reading through the patch, trying
> >>>> to see if I could make sense of what might be wrong. The result (after
> >>>>I dug into the code to make a change I foolishly thought made sense)
> >>>>was a hung kernel.
> >>>> This is important because when I rebooted into the kernel that had
> >>>> been giving me trouble, it started an md resync and I'm now watching
> >>>>(at least during this resync) the slab usage for scsi_cmd_cache stay
> >>>>sane:
> >>>>
> >>>>turbotaz ~ # cat /proc/slabinfo | grep scsi_cmd_cache
> >>>>scsi_cmd_cache 30 30 384 10 1 : tunables 54 27
> >>>>8 : slabdata 3 3 0
> >>>>
> >>>
> >>>This suggests that the problem happens when a BIO_RW_BARRIER write is
> >>>sent to the device. With this patch, md flags all superblock writes
> >>>as BIO_RW_BARRIER However md is not so likely to update the superblock
> >>>often
> >>>during a resync.
> >>>
> >>>There is a (rough) count of the number of superblock writes in the
> >>>"Events" counter which "mdadm -D" will display.
> >>>You could try collecting 'Events' counter together with the
> >>>'active_objs' count from /proc/slabinfo and graph the pairs - see if
> >>>they are linear.
> >>>
> >>>I believe a BIO_RW_BARRIER is likely to send some sort of 'flush'
> >>>command to the device, and the driver for your particular device may
> >>>well be losing scsi_cmd_cache allocation when doing that, but I leave
> >>>that to someone how knows more about that code.
> >>
> >>I already checked up on that since I suspected barriers initially. The
> >>path there for scsi is sd.c:sd_issue_flush() which looks pretty straight
> >>forward. In the end it goes through the block layer and gets back to the
> >>SCSI layer as a regular REQ_BLOCK_PC request.
> >
> >
> >Sorry, that was for the ->issue_flush() that md also does but did before
> >the barrier addition as well. Most of the barrier handling is done in
> >the block layer, but it could show leaks in SCSI of course. FWIW, I
> >tested barriers with and without md on SCSI here a few days ago and
> >didn't see any leaks at all.
> >
>
> It does not have anything to do with this in scsi_io_completion does it?
>
> if (blk_complete_barrier_rq(q, req, good_bytes >> 9))
> return;
>
> For that case the scsi_cmnd does not get freed. Does it come back around
> again and get released from a different path?
Certainly smells fishy. Unfortunately I cannot take a look at this until
monday :/
But adding some tracing there might be really interesting. Since we are
not seeing bio and/or req leaks, this does look very promising.
--
Jens Axboe
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: More information on scsi_cmd_cache leak... (bisect)
2006-01-27 19:06 ` Mike Christie
2006-01-27 19:16 ` Jens Axboe
@ 2006-01-27 19:20 ` James Bottomley
2006-01-27 19:29 ` Jens Axboe
2006-01-27 19:46 ` Mike Christie
1 sibling, 2 replies; 21+ messages in thread
From: James Bottomley @ 2006-01-27 19:20 UTC (permalink / raw)
To: Mike Christie
Cc: Jens Axboe, Neil Brown, Chase Venters, linux-kernel, linux-scsi,
akpm, a.titov, askernel2615, jamie
On Fri, 2006-01-27 at 13:06 -0600, Mike Christie wrote:
> It does not have anything to do with this in scsi_io_completion does it?
>
> if (blk_complete_barrier_rq(q, req, good_bytes >> 9))
> return;
>
> For that case the scsi_cmnd does not get freed. Does it come back around
> again and get released from a different path?
It looks such a likely candidate, doesn't it. Unfortunately, Tejun Heo
removed that code around 6 Jan (in [BLOCK] update SCSI to use new
blk_ordered for barriers), so if it is that, then the latest kernels
should now not be leaking.
However, all the avaliable evidence does seem to point to the write
barrier enforcement. I'll take another look over those code paths.
James
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: More information on scsi_cmd_cache leak... (bisect)
2006-01-27 19:20 ` James Bottomley
@ 2006-01-27 19:29 ` Jens Axboe
2006-01-27 19:46 ` Mike Christie
1 sibling, 0 replies; 21+ messages in thread
From: Jens Axboe @ 2006-01-27 19:29 UTC (permalink / raw)
To: James Bottomley
Cc: Mike Christie, Neil Brown, Chase Venters, linux-kernel,
linux-scsi, akpm, a.titov, askernel2615, jamie
On Fri, Jan 27 2006, James Bottomley wrote:
> On Fri, 2006-01-27 at 13:06 -0600, Mike Christie wrote:
> > It does not have anything to do with this in scsi_io_completion does it?
> >
> > if (blk_complete_barrier_rq(q, req, good_bytes >> 9))
> > return;
> >
> > For that case the scsi_cmnd does not get freed. Does it come back around
> > again and get released from a different path?
>
> It looks such a likely candidate, doesn't it. Unfortunately, Tejun Heo
> removed that code around 6 Jan (in [BLOCK] update SCSI to use new
> blk_ordered for barriers), so if it is that, then the latest kernels
> should now not be leaking.
Ah I thought so, seems my memory wasn't totally shot (don't have the
sources with me).
> However, all the avaliable evidence does seem to point to the write
> barrier enforcement. I'll take another look over those code paths.
The fact that it only happens with raid is very odd, though.
--
Jens Axboe
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: More information on scsi_cmd_cache leak... (bisect)
2006-01-27 19:20 ` James Bottomley
2006-01-27 19:29 ` Jens Axboe
@ 2006-01-27 19:46 ` Mike Christie
2006-01-27 19:49 ` Jens Axboe
1 sibling, 1 reply; 21+ messages in thread
From: Mike Christie @ 2006-01-27 19:46 UTC (permalink / raw)
To: James Bottomley
Cc: Jens Axboe, Neil Brown, Chase Venters, linux-kernel, linux-scsi,
akpm, a.titov, askernel2615, jamie
James Bottomley wrote:
> On Fri, 2006-01-27 at 13:06 -0600, Mike Christie wrote:
>
>>It does not have anything to do with this in scsi_io_completion does it?
>>
>> if (blk_complete_barrier_rq(q, req, good_bytes >> 9))
>> return;
>>
>>For that case the scsi_cmnd does not get freed. Does it come back around
>>again and get released from a different path?
>
>
> It looks such a likely candidate, doesn't it. Unfortunately, Tejun Heo
> removed that code around 6 Jan (in [BLOCK] update SCSI to use new
> blk_ordered for barriers), so if it is that, then the latest kernels
> should now not be leaking.
>
Oh, I thought the reports were for 2.6.15 and below which has that
scsi_io_completion test. Have there been reports for this with
2.6.16-rc1 too?
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: More information on scsi_cmd_cache leak... (bisect)
2006-01-27 19:46 ` Mike Christie
@ 2006-01-27 19:49 ` Jens Axboe
2006-01-27 19:53 ` Chase Venters
0 siblings, 1 reply; 21+ messages in thread
From: Jens Axboe @ 2006-01-27 19:49 UTC (permalink / raw)
To: Mike Christie
Cc: James Bottomley, Neil Brown, Chase Venters, linux-kernel,
linux-scsi, akpm, a.titov, askernel2615, jamie
On Fri, Jan 27 2006, Mike Christie wrote:
> James Bottomley wrote:
> >On Fri, 2006-01-27 at 13:06 -0600, Mike Christie wrote:
> >
> >>It does not have anything to do with this in scsi_io_completion does it?
> >>
> >> if (blk_complete_barrier_rq(q, req, good_bytes >> 9))
> >> return;
> >>
> >>For that case the scsi_cmnd does not get freed. Does it come back around
> >>again and get released from a different path?
> >
> >
> >It looks such a likely candidate, doesn't it. Unfortunately, Tejun Heo
> >removed that code around 6 Jan (in [BLOCK] update SCSI to use new
> >blk_ordered for barriers), so if it is that, then the latest kernels
> >should now not be leaking.
> >
>
> Oh, I thought the reports were for 2.6.15 and below which has that
> scsi_io_completion test. Have there been reports for this with
> 2.6.16-rc1 too?
The reports of leaks are only with > 2.6.15, not with 2.6.15.
--
Jens Axboe
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: More information on scsi_cmd_cache leak... (bisect)
2006-01-27 19:49 ` Jens Axboe
@ 2006-01-27 19:53 ` Chase Venters
2006-01-27 20:00 ` Jens Axboe
2006-01-27 20:02 ` askernel2615
0 siblings, 2 replies; 21+ messages in thread
From: Chase Venters @ 2006-01-27 19:53 UTC (permalink / raw)
To: Jens Axboe
Cc: Mike Christie, James Bottomley, Neil Brown, Chase Venters,
linux-kernel, linux-scsi, akpm, a.titov, askernel2615, jamie
On Fri, 27 Jan 2006, Jens Axboe wrote:
> On Fri, Jan 27 2006, Mike Christie wrote:
>> James Bottomley wrote:
>>> On Fri, 2006-01-27 at 13:06 -0600, Mike Christie wrote:
>>>
>>>> It does not have anything to do with this in scsi_io_completion does it?
>>>>
>>>> if (blk_complete_barrier_rq(q, req, good_bytes >> 9))
>>>> return;
>>>>
>>>> For that case the scsi_cmnd does not get freed. Does it come back around
>>>> again and get released from a different path?
>>>
>>>
>>> It looks such a likely candidate, doesn't it. Unfortunately, Tejun Heo
>>> removed that code around 6 Jan (in [BLOCK] update SCSI to use new
>>> blk_ordered for barriers), so if it is that, then the latest kernels
>>> should now not be leaking.
>>>
>>
>> Oh, I thought the reports were for 2.6.15 and below which has that
>> scsi_io_completion test. Have there been reports for this with
>> 2.6.16-rc1 too?
>
> The reports of leaks are only with > 2.6.15, not with 2.6.15.
>
Correction... my leak is with 2.6.15. I discovered it originally in an
NVIDIA-tainted, sk98lin-patched 2.6.15, but my bisect was stock 2.6.15
(bad) to 2.6.14 (good) in Linus's tree, sans any tainting or
modifications.
I haven't actually tried building the latest Linus kernel from git. I'll
do a pull and give it a try when I get home.
Cheers,
Chase
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: More information on scsi_cmd_cache leak... (bisect)
2006-01-27 19:53 ` Chase Venters
@ 2006-01-27 20:00 ` Jens Axboe
2006-01-27 20:02 ` askernel2615
1 sibling, 0 replies; 21+ messages in thread
From: Jens Axboe @ 2006-01-27 20:00 UTC (permalink / raw)
To: Chase Venters
Cc: Mike Christie, James Bottomley, Neil Brown, linux-kernel,
linux-scsi, akpm, a.titov, askernel2615, jamie
On Fri, Jan 27 2006, Chase Venters wrote:
> On Fri, 27 Jan 2006, Jens Axboe wrote:
>
> >On Fri, Jan 27 2006, Mike Christie wrote:
> >>James Bottomley wrote:
> >>>On Fri, 2006-01-27 at 13:06 -0600, Mike Christie wrote:
> >>>
> >>>>It does not have anything to do with this in scsi_io_completion does it?
> >>>>
> >>>> if (blk_complete_barrier_rq(q, req, good_bytes >> 9))
> >>>> return;
> >>>>
> >>>>For that case the scsi_cmnd does not get freed. Does it come back around
> >>>>again and get released from a different path?
> >>>
> >>>
> >>>It looks such a likely candidate, doesn't it. Unfortunately, Tejun Heo
> >>>removed that code around 6 Jan (in [BLOCK] update SCSI to use new
> >>>blk_ordered for barriers), so if it is that, then the latest kernels
> >>>should now not be leaking.
> >>>
> >>
> >>Oh, I thought the reports were for 2.6.15 and below which has that
> >>scsi_io_completion test. Have there been reports for this with
> >>2.6.16-rc1 too?
> >
> >The reports of leaks are only with > 2.6.15, not with 2.6.15.
> >
>
> Correction... my leak is with 2.6.15. I discovered it originally in an
> NVIDIA-tainted, sk98lin-patched 2.6.15, but my bisect was stock 2.6.15
> (bad) to 2.6.14 (good) in Linus's tree, sans any tainting or
> modifications.
>
> I haven't actually tried building the latest Linus kernel from git. I'll
> do a pull and give it a try when I get home.
Ah, so the raid barrier stuff predates 2.6.15, I didn't think it did.
Can you try 2.6.16-rc1 at least? If this is the blk_complete_barrier()
leak, then it's not so interesting.
As a work around, please try (in 2.6.15) to set ordered_flush to 0 in
the scsi host template for your sata driver.
--
Jens Axboe
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: More information on scsi_cmd_cache leak... (bisect)
2006-01-27 19:53 ` Chase Venters
2006-01-27 20:00 ` Jens Axboe
@ 2006-01-27 20:02 ` askernel2615
2006-01-27 20:06 ` Jens Axboe
1 sibling, 1 reply; 21+ messages in thread
From: askernel2615 @ 2006-01-27 20:02 UTC (permalink / raw)
To: Chase Venters
Cc: Jens Axboe, Mike Christie, James Bottomley, Neil Brown,
linux-kernel, linux-scsi, akpm, a.titov, jamie
On Fri, 27 Jan 2006, Chase Venters wrote:
> On Fri, 27 Jan 2006, Jens Axboe wrote:
>> The reports of leaks are only with > 2.6.15, not with 2.6.15.
> Correction... my leak is with 2.6.15.
Mine is also 2.6.15. Stock with debian patches.
In fact I believe ALL the reports are from 2.6.15.
-Ariel
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: More information on scsi_cmd_cache leak... (bisect)
2006-01-27 20:02 ` askernel2615
@ 2006-01-27 20:06 ` Jens Axboe
2006-01-27 22:50 ` Tim Morley
0 siblings, 1 reply; 21+ messages in thread
From: Jens Axboe @ 2006-01-27 20:06 UTC (permalink / raw)
To: askernel2615
Cc: Chase Venters, Mike Christie, James Bottomley, Neil Brown,
linux-kernel, linux-scsi, akpm, a.titov, jamie
On Fri, Jan 27 2006, askernel2615@dsgml.com wrote:
>
>
> On Fri, 27 Jan 2006, Chase Venters wrote:
>
> >On Fri, 27 Jan 2006, Jens Axboe wrote:
>
> >>The reports of leaks are only with > 2.6.15, not with 2.6.15.
>
> >Correction... my leak is with 2.6.15.
>
> Mine is also 2.6.15. Stock with debian patches.
>
> In fact I believe ALL the reports are from 2.6.15.
Hmm so does it happen in 2.6.16-rc1 or not? And try the suggestion I
made in the other, edit the sata driver for your device and set
ordered_flush to 0 instead of 1.
--
Jens Axboe
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: More information on scsi_cmd_cache leak... (bisect)
2006-01-27 18:41 ` Ariel
2006-01-27 18:58 ` Chase Venters
@ 2006-01-27 21:07 ` Neil Brown
1 sibling, 0 replies; 21+ messages in thread
From: Neil Brown @ 2006-01-27 21:07 UTC (permalink / raw)
To: Ariel
Cc: Chase Venters, linux-kernel, linux-scsi, akpm, a.titov, axboe,
jamie, arjan
On Friday January 27, askernel2615@dsgml.com wrote:
>
> On Fri, 27 Jan 2006, Chase Venters wrote:
>
> > After dealing with this leak for a while, I decided to do some dancing around
> > with git bisect. I've landed on a possible point of regression:
> >
> > commit: a9701a30470856408d08657eb1bd7ae29a146190
> > [PATCH] md: support BIO_RW_BARRIER for md/raid1
>
> I can confirm that it only leaks with raid!
>
> I rebooted with my raid5 root, read only, and it didn't leak. As soon as I
> remount,rw it started leaking. Go back to ro and it stopped (although it
> didn't clean up the old leaks). Tried my raid1 /boot and same thing - rw
> leaks, ro doesn't. But, it only leaks on activity.
>
> I then tried a regular lvm mount (with root ro), and no leaks!
It might be interesting, but probably not particularly helpful, to
create an ext3 filesystem on this device and mount it with the
barrier=1
mount option.
That should send BIO_RW_BARRIER requests to the device just line md
does.
NeilBrown
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: More information on scsi_cmd_cache leak... (bisect)
2006-01-27 20:06 ` Jens Axboe
@ 2006-01-27 22:50 ` Tim Morley
0 siblings, 0 replies; 21+ messages in thread
From: Tim Morley @ 2006-01-27 22:50 UTC (permalink / raw)
To: Jens Axboe
Cc: askernel2615, Chase Venters, Mike Christie, James Bottomley,
Neil Brown, linux-kernel, linux-scsi, akpm, a.titov, jamie
Jens Axboe writes ("Re: More information on scsi_cmd_cache leak... (bisect)"):
> On Fri, Jan 27 2006, askernel2615@dsgml.com wrote:
> > Mine is also 2.6.15. Stock with debian patches.
> >
> > In fact I believe ALL the reports are from 2.6.15.
>
> Hmm so does it happen in 2.6.16-rc1 or not? And try the suggestion I
> made in the other, edit the sata driver for your device and set
> ordered_flush to 0 instead of 1.
FYI I've had the problem with 2.6.15 and 2.6.15.1. I'm using raid1 and
raid5 on 4 sata drives with an ICH7 controller on an ASUS P5LD2-VM.
I've just got a 2.6.16-rc1 built and it seems that it fixes it! My
scsi_cmd_cache is setting happily at 10 allocations and not moving.
Tim Morley
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2006-01-27 22:50 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-01-27 10:09 More information on scsi_cmd_cache leak... (bisect) Chase Venters
2006-01-27 11:11 ` Neil Brown
2006-01-27 11:23 ` Jens Axboe
2006-01-27 11:28 ` Jens Axboe
2006-01-27 15:20 ` Chase Venters
2006-01-27 19:06 ` Mike Christie
2006-01-27 19:16 ` Jens Axboe
2006-01-27 19:20 ` James Bottomley
2006-01-27 19:29 ` Jens Axboe
2006-01-27 19:46 ` Mike Christie
2006-01-27 19:49 ` Jens Axboe
2006-01-27 19:53 ` Chase Venters
2006-01-27 20:00 ` Jens Axboe
2006-01-27 20:02 ` askernel2615
2006-01-27 20:06 ` Jens Axboe
2006-01-27 22:50 ` Tim Morley
2006-01-27 13:33 ` Alexey Dobriyan
2006-01-27 18:41 ` Ariel
2006-01-27 18:58 ` Chase Venters
2006-01-27 21:07 ` Neil Brown
2006-01-27 18:53 ` Ariel
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.