Re: memory leak in scsi_cmd_cache 2.6.15

Re: memory leak in scsi_cmd_cache 2.6.15

[Andrew Morton]

Ariel <askernel2615@dsgml.com> wrote:
>
> I have a memory leak in scsi_cmd_cache.

You're no the only one.  Please send the full `dmesg -s 1000000' output so
we can see which devices and drivers are in use.

Thanks.

Re: memory leak in scsi_cmd_cache 2.6.15

[Ariel]

On Sat, 21 Jan 2006, Andrew Morton wrote:

> Ariel <askernel2615@dsgml.com> wrote:
>>
>> I have a memory leak in scsi_cmd_cache.
>
> You're no the only one.  Please send the full `dmesg -s 1000000' output so
> we can see which devices and drivers are in use.

I don't actually have any scsi devices, it's being used by sata (and usb I 
guess). That's why I sent to linux-ide.

 	-Ariel

Linux version 2.6.15 (root@cherryberry.dsgml.com) (gcc version 3.3.5 (Debian 1:3.3.5-13)) #4 SMP Thu Jan 12 02:09:21 EST 2006
BIOS-provided physical RAM map:
  BIOS-e820: 0000000000000000 - 000000000009f400 (usable)
  BIOS-e820: 000000000009f400 - 00000000000a0000 (reserved)
  BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
  BIOS-e820: 0000000000100000 - 000000003fff0000 (usable)
  BIOS-e820: 000000003fff0000 - 000000003fff3000 (ACPI NVS)
  BIOS-e820: 000000003fff3000 - 0000000040000000 (ACPI data)
  BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
127MB HIGHMEM available.
896MB LOWMEM available.
found SMP MP-table at 000f5630
On node 0 totalpages: 262128
   DMA zone: 4096 pages, LIFO batch:0
   DMA32 zone: 0 pages, LIFO batch:0
   Normal zone: 225280 pages, LIFO batch:31
   HighMem zone: 32752 pages, LIFO batch:7
DMI 2.2 present.
ACPI: RSDP (v000 IntelR                                ) @ 0x000f70a0
ACPI: RSDT (v001 IntelR AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x3fff3000
ACPI: FADT (v001 IntelR AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x3fff3040
ACPI: MADT (v001 IntelR AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x3fff7040
ACPI: DSDT (v001 INTELR AWRDACPI 0x00001000 MSFT 0x0100000e) @ 0x00000000
ACPI: PM-Timer IO Port: 0x408
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 15:2 APIC version 20
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Processor #1 15:2 APIC version 20
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 50000000 (gap: 40000000:bec00000)
Built 1 zonelists
Kernel command line: BOOT_IMAGE=Linux ro root=900
mapped APIC to ffffd000 (fee00000)
mapped IOAPIC to ffffc000 (fec00000)
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 65536 bytes)
Detected 2793.694 MHz processor.
Using pmtmr for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1032256k/1048512k available (4203k kernel code, 15600k reserved, 1592k data, 292k init, 131008k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 5589.36 BogoMIPS (lpj=2794684)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: bfebfbff 00000000 00000000 00000000 00004400 00000000 00000000
CPU: After vendor identify, caps: bfebfbff 00000000 00000000 00000000 00004400 00000000 00000000
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: Physical Processor ID: 0
CPU: After all inits, caps: bfebfbff 00000000 00000000 00000080 00004400 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.
  tbxface-0109 [02] load_tables           : ACPI Tables successfully acquired
Parsing all Control Methods:............................................................................................................................................................
Table [DSDT](id 0005) - 506 Objects with 55 Devices 156 Methods 27 Regions
ACPI Namespace successfully loaded at root c07314bc
evxfevnt-0091 [03] enable                : Transition to ACPI mode successful
CPU0: Intel(R) Pentium(R) 4 CPU 2.80GHz stepping 09
Booting processor 1/1 eip 2000
Initializing CPU#1
Calibrating delay using timer specific routine.. 5585.26 BogoMIPS (lpj=2792631)
CPU: After generic identify, caps: bfebfbff 00000000 00000000 00000000 00004400 00000000 00000000
CPU: After vendor identify, caps: bfebfbff 00000000 00000000 00000000 00004400 00000000 00000000
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: Physical Processor ID: 0
CPU: After all inits, caps: bfebfbff 00000000 00000000 00000080 00004400 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#1.
CPU1: Intel P4/Xeon Extended MCE MSRs (12) available
CPU1: Thermal monitoring enabled
CPU1: Intel(R) Pentium(R) 4 CPU 2.80GHz stepping 09
Total of 2 processors activated (11174.63 BogoMIPS).
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
checking TSC synchronization across 2 CPUs: passed.
Brought up 2 CPUs
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xfba30, last bus=3
PCI: Using configuration type 1
ACPI: Subsystem revision 20050902
evgpeblk-0988 [06] ev_create_gpe_block   : GPE 00 to 1F [_GPE] 4 regs on int 0x9
evgpeblk-0996 [06] ev_create_gpe_block   : Found 9 Wake, Enabled 0 Runtime GPEs in this block
Completing Region/Field/Buffer/Package initialization:..................................................................
Initialized 27/27 Regions 9/9 Fields 19/19 Buffers 11/16 Packages (515 nodes)
Executing all Device _STA and_INI methods:............................................................
60 Devices found containing: 60 _STA, 2 _INI methods
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
PCI quirk: region 0400-047f claimed by ICH4 ACPI/GPIO/TCO
PCI quirk: region 0480-04bf claimed by ICH4 GPIO
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.2
Boot video device is 0000:03:00.0
PCI: Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 *9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 7 9 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 7 9 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 *5 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNK0] (IRQs 3 4 *5 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 5 7 *9 10 11 12 14 15)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 13 devices
PnPBIOS: Disabled by ACPI PNP
Generic PHY: Registered new driver
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
NET: Registered protocol family 23
pnp: 00:0a: ioport range 0x400-0x4bf could not be reserved
PCI: Bridge: 0000:00:01.0
   IO window: disabled.
   MEM window: disabled.
   PREFETCH window: disabled.
PCI: Bridge: 0000:00:03.0
   IO window: a000-afff
   MEM window: f7000000-f70fffff
   PREFETCH window: disabled.
PCI: Bridge: 0000:00:1e.0
   IO window: 7000-9fff
   MEM window: f0000000-f6ffffff
   PREFETCH window: d0000000-efffffff
PCI: Setting latency timer of device 0000:00:1e.0 to 64
Machine check exception polling timer started.
highmem bounce pool size: 64 pages
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Coda Kernel/Venus communications, v6.0.0, coda@cs.cmu.edu
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
NTFS driver 2.1.25 [Flags: R/W].
fuse init (API version 7.3)
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
ACPI: Power Button (FF) [PWRF]
ACPI: Power Button (CM) [PWRB]
ACPI: Fan [FAN] (on)
ACPI: Thermal Zone [THRM] (40 C)
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Real Time Clock Driver v1.12
hw_random: RNG not detected
Linux agpgart interface v0.101 (c) Dave Jones
[drm] Initialized drm 1.0.0 20040925
ipmi message handler version 38.0
PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1
PNP: PS/2 controller doesn't have AUX irq; using default 12
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
serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
00:06: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
00:07: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
parport: PnPBIOS parport detected.
parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE]
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
loop: loaded (max 8 devices)
Intel(R) PRO/1000 Network Driver - version 6.1.16-k2
Copyright (c) 1999-2005 Intel Corporation.
acpi_bus-0201 [01] bus_set_power         : Device is not power manageable
ACPI: PCI Interrupt 0000:02:01.0[A] -> GSI 18 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:02:01.0 to 64
e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
Davicom DM9161E: Registered new driver
Davicom DM9131: 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
HPT372N: IDE controller at PCI slot 0000:03:06.0
ACPI: PCI Interrupt 0000:03:06.0[A] -> GSI 21 (level, low) -> IRQ 17
HPT372N: chipset revision 6
HPT372N: 100% native mode on irq 17
hpt: HPT372N detected, using 372N timing.
FREQ: 85 PLL: 41
HPT37XN: unknown bus timing [44 2].
hpt: no known IDE timings, disabling DMA.
hpt: HPT372N detected, using 372N timing.
FREQ: 164 PLL: 66
HPT37XN: unknown bus timing [69 4].
hpt: no known IDE timings, disabling DMA.
Probing IDE interface ide2...
Probing IDE interface ide3...
ide0: I/O resource 0x1F0-0x1F7 not free.
ide0: ports already in use, skipping probe
Probing IDE interface ide1...
hdd: CD-ROM 50X L, ATAPI CD/DVD-ROM drive
Probing IDE interface ide2...
Probing IDE interface ide3...
ide1 at 0x170-0x177,0x376 on irq 15
hdd: ATAPI 50X CD-ROM drive, 128kB Cache
Uniform CD-ROM driver Revision: 3.20
libata version 1.20 loaded.
ata_piix 0000:00:1f.2: version 1.05
ata_piix 0000:00:1f.2: combined mode detected (p=1, s=0)
ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 18 (level, low) -> IRQ 16
ata: 0x170 IDE port busy
PCI: Setting latency timer of device 0000:00:1f.2 to 64
ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14
ata1: dev 0 cfg 49:2f00 82:7c6b 83:7f09 84:4003 85:7c69 86:3e01 87:4003 88:207f
ata1: dev 0 ATA-7, max UDMA/133, 312581808 sectors: LBA48
ata1: dev 1 cfg 49:2f00 82:7c6b 83:7f09 84:4673 85:7c69 86:3e01 87:4663 88:207f
ata1: dev 1 ATA-7, max UDMA/133, 586114704 sectors: LBA48
ata1: dev 0 configured for UDMA/133
ata1: dev 1 configured for UDMA/133
scsi0 : ata_piix
   Vendor: ATA       Model: Maxtor 6Y160M0    Rev: YAR5
   Type:   Direct-Access                      ANSI SCSI revision: 05
   Vendor: ATA       Model: Maxtor 7L300S0    Rev: BANC
   Type:   Direct-Access                      ANSI SCSI revision: 05
sata_sil 0000:03:05.0: version 0.9
ACPI: PCI Interrupt 0000:03:05.0[A] -> GSI 20 (level, low) -> IRQ 18
ata2: SATA max UDMA/100 cmd 0xF8802080 ctl 0xF880208A bmdma 0xF8802000 irq 18
ata3: SATA max UDMA/100 cmd 0xF88020C0 ctl 0xF88020CA bmdma 0xF8802008 irq 18
ata2: dev 0 cfg 49:2f00 82:7c6b 83:7f09 84:4673 85:7c69 86:3e21 87:4663 88:207f
ata2: dev 0 ATA-7, max UDMA/133, 586114704 sectors: LBA48
ata2: dev 0 configured for UDMA/100
scsi1 : sata_sil
ata3: dev 0 cfg 49:2f00 82:7c6b 83:7f09 84:4673 85:7c69 86:3e01 87:4663 88:207f
ata3: dev 0 ATA-7, max UDMA/133, 490234752 sectors: LBA48
ata3: dev 0 configured for UDMA/100
scsi2 : sata_sil
   Vendor: ATA       Model: Maxtor 6L300S0    Rev: BACE
   Type:   Direct-Access                      ANSI SCSI revision: 05
   Vendor: ATA       Model: Maxtor 6B250S0    Rev: BANC
   Type:   Direct-Access                      ANSI SCSI revision: 05
st: Version 20050830, fixed bufsize 32768, s/g segs 256
SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB)
SCSI device sda: drive cache: write back
SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB)
SCSI device sda: drive cache: write back
  sda: sda1 sda2 sda3 sda4
sd 0:0:0:0: Attached scsi disk sda
SCSI device sdb: 586114704 512-byte hdwr sectors (300091 MB)
SCSI device sdb: drive cache: write back
SCSI device sdb: 586114704 512-byte hdwr sectors (300091 MB)
SCSI device sdb: drive cache: write back
  sdb: sdb1 sdb2 sdb3 sdb4
sd 0:0:1:0: Attached scsi disk sdb
SCSI device sdc: 586114704 512-byte hdwr sectors (300091 MB)
SCSI device sdc: drive cache: write back
SCSI device sdc: 586114704 512-byte hdwr sectors (300091 MB)
SCSI device sdc: drive cache: write back
  sdc: sdc1 sdc2 sdc3
sd 1:0:0:0: Attached scsi disk sdc
SCSI device sdd: 490234752 512-byte hdwr sectors (251000 MB)
SCSI device sdd: drive cache: write back
SCSI device sdd: 490234752 512-byte hdwr sectors (251000 MB)
SCSI device sdd: drive cache: write back
  sdd: sdd1 sdd2 sdd3
sd 2:0:0:0: Attached scsi disk sdd
sd 0:0:0:0: Attached scsi generic sg0 type 0
sd 0:0:1:0: Attached scsi generic sg1 type 0
sd 1:0:0:0: Attached scsi generic sg2 type 0
sd 2:0:0:0: Attached scsi generic sg3 type 0
usbmon: debugfs is not available
USB Universal Host Controller Interface driver v2.3
ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 16 (level, low) -> IRQ 19
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: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:1d.0: irq 19, io base 0x0000bc00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 20
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: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:1d.1: irq 20, io base 0x0000b000
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 16
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: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:1d.2: irq 16, io base 0x0000b400
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.3[A] -> GSI 16 (level, low) -> IRQ 19
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: new USB bus registered, assigned bus number 4
uhci_hcd 0000:00:1d.3: irq 19, io base 0x0000b800
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
usb 1-2: new low speed USB device using uhci_hcd and address 2
Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
usb 3-1: new full speed USB device using uhci_hcd and address 2
scsi3 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 2
usb-storage: waiting for device to settle before scanning
usbcore: registered new driver hiddev
input: Logitech USB-PS/2 Optical Mouse as /class/input/input0
input: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-0000:00:1d.0-2
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
mice: PS/2 mouse device common for all mice
input: PC Speaker as /class/input/input1
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
it87 0-002d: Detected broken BIOS defaults, disabling PWM interface
it87: Found IT8712F chip at 0x290, revision 5
it87-isa 9191-0290: Detected broken BIOS defaults, disabling PWM interface
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  :  3628.000 MB/sec
raid5: using function: pIII_sse (3628.000 MB/sec)
raid6: int32x1    828 MB/s
raid6: int32x2   1089 MB/s
raid6: int32x4    742 MB/s
raid6: int32x8    550 MB/s
raid6: mmxx1     2242 MB/s
raid6: mmxx2     2851 MB/s
raid6: sse1x1    1511 MB/s
raid6: sse1x2    2093 MB/s
raid6: sse2x1    2421 MB/s
raid6: sse2x2    3062 MB/s
raid6: using algorithm sse2x2 (3062 MB/s)
md: raid6 personality registered as nr 8
md: faulty personality registered as nr 10
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
Advanced Linux Sound Architecture Driver Version 1.0.10rc3 (Mon Nov 07 13:30:21 2005 UTC).
ACPI: PCI Interrupt 0000:03:07.0[A] -> GSI 22 (level, low) -> IRQ 21
ALSA device list:
   #0: C-Media PCI CMI8738-MC6 (model 55) at 0x9800, irq 21
u32 classifier
     Perfomance counters on
     OLD policer on 
NET: Registered protocol family 2
IP route cache hash table entries: 65536 (order: 6, 262144 bytes)
TCP established hash table entries: 262144 (order: 9, 2097152 bytes)
TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
TCP: Hash tables configured (established 262144 bind 65536)
TCP reno registered
IPv4 over IPv4 tunneling driver
ip_conntrack version 2.4 (8191 buckets, 65528 max) - 216 bytes per conntrack
input: AT Translated Set 2 keyboard as /class/input/input2
ip_conntrack_pptp version 3.1 loaded
ip_nat_pptp version 3.0 loaded
ip_tables: (C) 2000-2002 Netfilter core team
TCP bic registered
Initializing IPsec netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 15
Starting balanced_irq
Using IPI Shortcut mode
BIOS EDD facility v0.16 2004-Jun-25, 4 devices found
md: Autodetecting RAID arrays.
md: autorun ...
md: considering sdd1 ...
md:  adding sdd1 ...
md:  adding sdc1 ...
md: sdb2 has different UUID to sdd1
md:  adding sdb1 ...
md: sda2 has different UUID to sdd1
md:  adding sda1 ...
md: created md0
md: bind<sda1>
md: bind<sdb1>
md: bind<sdc1>
md: bind<sdd1>
md: running: <sdd1><sdc1><sdb1><sda1>
raid5: device sdd1 operational as raid disk 3
raid5: device sdc1 operational as raid disk 2
raid5: device sdb1 operational as raid disk 1
raid5: device sda1 operational as raid disk 0
raid5: allocated 4203kB for md0
raid5: raid level 5 set md0 active with 4 out of 4 devices, algorithm 2
RAID5 conf printout:
  --- rd:4 wd:4 fd:0
  disk 0, o:1, dev:sda1
  disk 1, o:1, dev:sdb1
  disk 2, o:1, dev:sdc1
  disk 3, o:1, dev:sdd1
md: considering sdb2 ...
md:  adding sdb2 ...
md:  adding sda2 ...
md: created md1
md: bind<sda2>
md: bind<sdb2>
md: running: <sdb2><sda2>
raid1: raid set md1 active with 2 out of 2 mirrors
md: ... autorun DONE.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 292k freed
ACPI: PCI Interrupt 0000:03:04.1[A] -> GSI 17 (level, low) -> IRQ 22
ieee1394: Initialized config rom entry `ip1394'
cx2388x v4l2 driver version 0.0.5 loaded
ACPI: PCI Interrupt 0000:03:02.0[A] -> GSI 18 (level, low) -> IRQ 16
CORE cx88[0]: subsystem: 7063:3000, board: pcHDTV HD3000 HDTV [card=22,autodetected]
TV tuner 52 at 0x1fe, Radio tuner -1 at 0x1fe
bttv: driver version 0.9.16 loaded
bttv: using 8 buffers with 2080k (520 pages) each for capture
cx2388x dvb driver version 0.0.5 loaded
cx88[0]/0: found at 0000:03:02.0, rev: 5, irq: 16, latency: 32, mmio: 0xf2000000
tuner 1-0061: chip found @ 0xc2 (cx88[0])
tuner 1-0061: type set to 52 (Thomson DDT 7610 (ATSC/NTSC))
tda9887 1-0043: chip found @ 0x86 (cx88[0])
cx88[0]/0: registered device video0 [v4l2]
cx88[0]/0: registered device vbi0
cx88[0]/0: registered device radio0
ACPI: PCI Interrupt 0000:03:03.0[A] -> <6>ACPI: PCI Interrupt 0000:03:02.2[A] -> GSI 18 (level, low) -> IRQ 16
cx88[0]/2: found at 0000:03:02.2, rev: 5, irq: 16, latency: 32, mmio: 0xf3000000
cx88[0]/2: cx2388x based dvb card
GSI 19 (level, low) -> IRQ 20
CORE cx88[1]: subsystem: 7063:3000, board: pcHDTV HD3000 HDTV [card=22,autodetected]
TV tuner 52 at 0x1fe, Radio tuner -1 at 0x1fe
DVB: registering new adapter (cx88[0]).
DVB: registering frontend 0 (Oren OR51132 VSB/QAM Frontend)...
tuner 2-0061: chip found @ 0xc2 (cx88[1])
tuner 2-0061: type set to 52 (Thomson DDT 7610 (ATSC/NTSC))
tda9887 2-0043: chip found @ 0x86 (cx88[1])
cx88[1]/0: found at 0000:03:03.0, rev: 5, irq: 20, latency: 32, mmio: 0xf4000000
cx88[1]/0: registered device video1 [v4l2]
cx88[1]/0: registered device vbi1
cx88[1]/0: registered device radio1
bttv: Bt8xx card found (0).
ACPI: PCI Interrupt 0000:03:04.0[A] -> GSI 17 (level, low) -> IRQ 22
bttv0: Bt878 (rev 2) at 0000:03:04.0, irq: 22, latency: 32, mmio: 0xe0000000
bttv0: detected: Hauppauge WinTV [card=10], PCI subsystem ID is 0070:13eb
bttv0: using: Hauppauge (bt878) [card=10,autodetected]
bttv0: gpio: en=00000000, out=00000000 in=00ffffdb [init]
bttv0: Hauppauge/Voodoo msp34xx: reset line init [5]
ACPI: PCI Interrupt 0000:03:03.2[A] -> GSI 19 (level, low) -> IRQ 20
cx88[1]/2: found at 0000:03:03.2, rev: 5, irq: 20, latency: 32, mmio: 0xf5000000
cx88[1]/2: cx2388x based dvb card
DVB: registering new adapter (cx88[1]).
DVB: registering frontend 1 (Oren OR51132 VSB/QAM Frontend)...
tuner 3-0061: chip found @ 0xc2 (bt878 #0 [sw])
tveeprom 3-0050: Hauppauge model 61371, rev B223, serial# 2041163
tveeprom 3-0050: tuner model is Philips FM1236 (idx 23, type 2)
tveeprom 3-0050: TV standards NTSC(M) (eeprom 0x08)
tveeprom 3-0050: audio processor is MSP3430 (idx 7)
tveeprom 3-0050: has radio
bttv0: using tuner=2
tuner 3-0061: type set to 2 (Philips NTSC (FI1236,FM1236 and compatibles))
bttv0: i2c: checking for MSP34xx @ 0x80... found
msp3400 3-0040: chip=MSP3430G-A1 +nicam +simple +simpler +radio mode=simpler
msp3400 3-0040: msp34xxg daemon started
bttv0: i2c: checking for TDA9875 @ 0xb0... not found
bttv0: i2c: checking for TDA7432 @ 0x8a... not found
bttv0: i2c: checking for TDA9887 @ 0x86... not found
bttv0: registered device video2
bttv0: registered device vbi2
bttv0: registered device radio2
bttv0: PLL: 28636363 => 35468950 .. ok
ohci1394: $Rev: 1313 $ Ben Collins <bcollins@debian.org>
ACPI: PCI Interrupt 0000:03:0a.0[A] -> GSI 19 (level, low) -> IRQ 20
PCI: Via IRQ fixup for 0000:03:0a.0, from 10 to 4
ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[20]  MMIO=[f6001000-f60017ff]  Max Packet=[2048]
cx2388x blackbird driver version 0.0.5 loaded
   Vendor: Generic   Model: STORAGE DEVICE    Rev: 0113
   Type:   Direct-Access                      ANSI SCSI revision: 00
SCSI device sde: 32000 512-byte hdwr sectors (16 MB)
sde: Write Protect is off
sde: Mode Sense: 02 00 00 00
sde: assuming drive cache: write through
SCSI device sde: 32000 512-byte hdwr sectors (16 MB)
sde: Write Protect is off
sde: Mode Sense: 02 00 00 00
sde: assuming drive cache: write through
  sde: sde1
sd 3:0:0:0: Attached scsi removable disk sde
sd 3:0:0:0: Attached scsi generic sg4 type 0
usb-storage: device scan complete
ieee1394: Host added: ID:BUS[0-00:1023]  GUID[00502c0000093e5a]
eth1394: $Rev: 1312 $ Ben Collins <bcollins@debian.org>
eth1394: eth1: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0)
Adding 2096632k swap on /dev/sda3.  Priority:1 extents:1 across:2096632k
Adding 2096632k swap on /dev/sdb3.  Priority:2 extents:1 across:2096632k
Adding 2096632k swap on /dev/sdc2.  Priority:2 extents:1 across:2096632k
Adding 2096632k swap on /dev/sdd2.  Priority:2 extents:1 across:2096632k
EXT3 FS on md0, internal journal
kjournald starting.  Commit interval 5 seconds
EXT3 FS on md1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on dm-1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on dm-2, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on dm-5, internal journal
EXT3-fs: mounted filesystem with writeback data mode.
e1000: eth0: e1000_watchdog_task: NIC Link is Up 100 Mbps Full Duplex
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
IPv6 over IPv4 tunneling driver

Re: memory leak in scsi_cmd_cache 2.6.15

[Ariel]

On Sun, 22 Jan 2006, Arjan van de Ven wrote:
>>> On Sun, 2006-01-22 at 09:16 +0100, Arjan van de Ven wrote:
>>>> On Sat, 2006-01-21 at 21:13 -0500, Ariel wrote:

>>>>> I have a memory leak in scsi_cmd_cache.

>>>> does this happen without the binary nvidia driver too? (it appears
>>>> you're using that). That's a good datapoint to have if so...

> please repeat this without nvidia ever being loaded. Just having a
> module loaded before can already cause corruption that ripples through
> later, so just unloading is not enough to get a clean result.

I rebooted without nvidia or vmware ever being loaded and got a 
leak of 1.12KB/s. So I think we can rule that out.

A commonality I'm noticing is SATA. SATA had a big update in this 
version, so perhaps that's where to start looking.

 	-Ariel

Re: memory leak in scsi_cmd_cache 2.6.15

[Arjan van de Ven]

On Sun, 2006-01-22 at 21:14 -0500, Ariel wrote:
> On Sun, 22 Jan 2006, Arjan van de Ven wrote:
> >>> On Sun, 2006-01-22 at 09:16 +0100, Arjan van de Ven wrote:
> >>>> On Sat, 2006-01-21 at 21:13 -0500, Ariel wrote:
> 
> >>>>> I have a memory leak in scsi_cmd_cache.
> 
> >>>> does this happen without the binary nvidia driver too? (it appears
> >>>> you're using that). That's a good datapoint to have if so...
> 
> > please repeat this without nvidia ever being loaded. Just having a
> > module loaded before can already cause corruption that ripples through
> > later, so just unloading is not enough to get a clean result.
> 
> I rebooted without nvidia or vmware ever being loaded and got a 
> leak of 1.12KB/s. So I think we can rule that out.

great

> 
> A commonality I'm noticing is SATA. SATA had a big update in this 
> version, so perhaps that's where to start looking.

I wonder if it can be narrowed even more, like to the exact chipset
driver?

Re: memory leak in scsi_cmd_cache 2.6.15

[Chase Venters]

On Monday 23 January 2006 00:17, Arjan van de Ven wrote:
> > A commonality I'm noticing is SATA. SATA had a big update in this
> > version, so perhaps that's where to start looking.
>
> I wonder if it can be narrowed even more, like to the exact chipset
> driver?

Anton and I use an Intel 82801 (ICH6). Ariel's dmesg doesn't look like an ICH6 
to me at first glance, but he's also on ata_piix.

Cheers,
Chase

Re: memory leak in scsi_cmd_cache 2.6.15

[Ariel]

On Mon, 23 Jan 2006, Chase Venters wrote:

> On Monday 23 January 2006 00:17, Arjan van de Ven wrote:
>>> A commonality I'm noticing is SATA. SATA had a big update in this
>>> version, so perhaps that's where to start looking.
>>
>> I wonder if it can be narrowed even more, like to the exact chipset
>> driver?
>
> Anton and I use an Intel 82801 (ICH6). Ariel's dmesg doesn't look like an ICH6
> to me at first glance, but he's also on ata_piix.

I'm on ICH5, but also Sil3112 and HighPoint 372N.

Jamie has ICH6 and Sil3112.

ata_piix seems like it's in common for all, but this is not a lot of 
systems, so it could just be a coincidence and the problem caused by 
something that's not chipset specific.

 	-Ariel

Re: memory leak in scsi_cmd_cache 2.6.15

[Jamie Heilman]

Ariel wrote:
> I'm on ICH5, but also Sil3112 and HighPoint 372N.
> 
> Jamie has ICH6 and Sil3112.
> 
> ata_piix seems like it's in common for all, but this is not a lot of 
> systems, so it could just be a coincidence and the problem caused by 
> something that's not chipset specific.

Hmm.  I just moved my sata_sil stuff out of the way and rebooted:

$ uptime; grep scsi_cmd_cache /proc/slabinfo
 23:22:16 up 4 min,  1 user,  load average: 0.00, 0.03, 0.00
scsi_cmd_cache      1200   1200    384   10    1 : tunables   54   27   8 : slabdata    120    120      0

My other workstation also runs 2.6.15.1 but uses sata_nv and doesn't
exhibit the problem.

-- 
Jamie Heilman                     http://audible.transient.net/~jamie/

Re: memory leak in scsi_cmd_cache 2.6.15

[Jens Axboe]

On Sun, Jan 22 2006, Jamie Heilman wrote:
> Ariel wrote:
> > I'm on ICH5, but also Sil3112 and HighPoint 372N.
> > 
> > Jamie has ICH6 and Sil3112.
> > 
> > ata_piix seems like it's in common for all, but this is not a lot of 
> > systems, so it could just be a coincidence and the problem caused by 
> > something that's not chipset specific.
> 
> Hmm.  I just moved my sata_sil stuff out of the way and rebooted:
> 
> $ uptime; grep scsi_cmd_cache /proc/slabinfo
>  23:22:16 up 4 min,  1 user,  load average: 0.00, 0.03, 0.00
> scsi_cmd_cache      1200   1200    384   10    1 : tunables   54   27   8 : slabdata    120    120      0
> 
> My other workstation also runs 2.6.15.1 but uses sata_nv and doesn't
> exhibit the problem.

The SATA low level driver is very unlikely to play a role in this. But
you are both using md (raid1 to be specific) on top of scsi, I'd say
that's the best clue. I'd very much doubt the nvidia module as well.

-- 
Jens Axboe

Re: memory leak in scsi_cmd_cache 2.6.15

[Jamie Heilman]

Jens Axboe wrote:
> On Sun, Jan 22 2006, Jamie Heilman wrote:
> > Ariel wrote:
> > > ata_piix seems like it's in common for all, but this is not a lot of 
> > > systems, so it could just be a coincidence and the problem caused by 
> > > something that's not chipset specific.
> > 
> > Hmm.  I just moved my sata_sil stuff out of the way and rebooted:
> > 
> > $ uptime; grep scsi_cmd_cache /proc/slabinfo
> >  23:22:16 up 4 min,  1 user,  load average: 0.00, 0.03, 0.00
> > scsi_cmd_cache      1200   1200    384   10    1 : tunables   54   27   8 : slabdata    120    120      0
> > 
> > My other workstation also runs 2.6.15.1 but uses sata_nv and doesn't
> > exhibit the problem.
> 
> The SATA low level driver is very unlikely to play a role in this. But
> you are both using md (raid1 to be specific) on top of scsi, I'd say
> that's the best clue. I'd very much doubt the nvidia module as well.

True, my sata_nv box doesn't use md.  OTOH, my machines running raid1
on an LSI (MPT Fusion driver) SCSI controller don't have this leak.

-- 
Jamie Heilman                     http://audible.transient.net/~jamie/

Re: memory leak in scsi_cmd_cache 2.6.15

[Jens Axboe]

On Fri, Jan 27 2006, Jamie Heilman wrote:
> Jens Axboe wrote:
> > On Sun, Jan 22 2006, Jamie Heilman wrote:
> > > Ariel wrote:
> > > > ata_piix seems like it's in common for all, but this is not a lot of 
> > > > systems, so it could just be a coincidence and the problem caused by 
> > > > something that's not chipset specific.
> > > 
> > > Hmm.  I just moved my sata_sil stuff out of the way and rebooted:
> > > 
> > > $ uptime; grep scsi_cmd_cache /proc/slabinfo
> > >  23:22:16 up 4 min,  1 user,  load average: 0.00, 0.03, 0.00
> > > scsi_cmd_cache      1200   1200    384   10    1 : tunables   54   27   8 : slabdata    120    120      0
> > > 
> > > My other workstation also runs 2.6.15.1 but uses sata_nv and doesn't
> > > exhibit the problem.
> > 
> > The SATA low level driver is very unlikely to play a role in this. But
> > you are both using md (raid1 to be specific) on top of scsi, I'd say
> > that's the best clue. I'd very much doubt the nvidia module as well.
> 
> True, my sata_nv box doesn't use md.  OTOH, my machines running raid1
> on an LSI (MPT Fusion driver) SCSI controller don't have this leak.

Those SCSI LLD don't support ordered flush barriers, that's why.

-- 
Jens Axboe

Re: memory leak in scsi_cmd_cache 2.6.15

[Ariel]

On Sun, 22 Jan 2006, Jamie Heilman wrote:

> Ariel wrote:

>> ata_piix seems like it's in common for all, but this is not a lot of

> Hmm.  I just moved my sata_sil stuff out of the way and rebooted:

> $ uptime; grep scsi_cmd_cache /proc/slabinfo
> 23:22:16 up 4 min,  1 user,  load average: 0.00, 0.03, 0.00
> scsi_cmd_cache      1200   1200    384   10    1 : tunables   54   27 
8 : slabdata    120    120    $

Is this good or bad? I'm guessing it means it's still leaking. So it's
really starting to look like ata_piix is the problem. But we need someone
who has the leak to remove that and see if it helps. I can't, since my
drives are connected to it.

And developers:

Can anyone PLEASE take a look at this? We've got 4 confirmed reports of
it, and it's nothing to do with a tainted module. Take a look at this
slabtop output:

    OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
1230120 1230120 100%   0.38K 123012      10    492048K scsi_cmd_cache

I have a 492MB leak! And notice how objects never become unused - that
looks like the problem.

         -Ariel

Re: memory leak in scsi_cmd_cache 2.6.15

[Nix]

On 26 Jan 2006, Ariel noted:
> Is this good or bad? I'm guessing it means it's still leaking. So it's
> really starting to look like ata_piix is the problem. But we need someone
> who has the leak to remove that and see if it helps. I can't, since my
> drives are connected to it.

FWIW, a bit of negative-confirmatory evidence: I have a sym53c875
and non-SATA IDE drive on this 2.6.15.1, and there is no leak,
nor was there in 2.6.15:

    11     11 100%    0.34K      1       11         4K scsi_cmd_cache

Loaded modules:

Module                  Size  Used by
loop                   11304  0

.config attached.

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
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_SYSCTL_URANDOM=y
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_KALLSYMS=y
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_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_OBSOLETE_MODPARM=y
CONFIG_KMOD=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=m
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=m
CONFIG_DEFAULT_DEADLINE=y
CONFIG_DEFAULT_IOSCHED="deadline"
CONFIG_X86_PC=y
CONFIG_M586MMX=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_PPRO_FENCE=y
CONFIG_X86_F00F_BUG=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_ALIGNMENT_16=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_TSC=y
CONFIG_PREEMPT_NONE=y
CONFIG_X86_MCE=y
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m
CONFIG_NOHIGHMEM=y
CONFIG_PROC_MM=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_REGPARM=y
CONFIG_SECCOMP=y
CONFIG_HZ_100=y
CONFIG_HZ=100
CONFIG_PHYSICAL_START=0x100000
CONFIG_PM=y
CONFIG_PM_LEGACY=y
CONFIG_PCI=y
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_ISA_DMA_API=y
CONFIG_ISA=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_FIB_HASH=y
CONFIG_NET_IPGRE=m
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
CONFIG_TCP_CONG_BIC=y
CONFIG_BRIDGE=y
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_PARPORT_PC_FIFO=y
CONFIG_PNP=y
CONFIG_ISAPNP=y
CONFIG_BLK_DEV_FD=y
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_CRYPTOLOOP=m
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_IDE_GENERIC=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_PIIX=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_AUTO=y
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_BLK_DEV_SR=y
CONFIG_CHR_DEV_SG=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_SPI_ATTRS=y
CONFIG_SCSI_SYM53C8XX_2=y
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=0
CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16
CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64
CONFIG_SCSI_QLA2XXX=y
CONFIG_MD=y
CONFIG_BLK_DEV_DM=y
CONFIG_DM_CRYPT=y
CONFIG_DM_SNAPSHOT=y
CONFIG_DM_MIRROR=y
CONFIG_DM_ZERO=y
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
CONFIG_TUN=y
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
CONFIG_NET_VENDOR_3COM=y
CONFIG_VORTEX=y
CONFIG_NET_PCI=y
CONFIG_EEPRO100=y
CONFIG_NATSEMI=y
CONFIG_PLIP=m
CONFIG_INPUT=y
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
CONFIG_SERIO_LIBPS2=y
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_FRANDOM=y
CONFIG_HW_CONSOLE=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_CORE=y
CONFIG_UNIX98_PTYS=y
CONFIG_RTC=y
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
CONFIG_I2C_ISA=y
CONFIG_HWMON=y
CONFIG_HWMON_VID=y
CONFIG_SENSORS_LM78=y
CONFIG_VIDEO_SELECT=y
CONFIG_VGA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_SOUND=m
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_HWDEP=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_SEQUENCER=m
CONFIG_SND_SEQ_DUMMY=m
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=m
CONFIG_SND_SEQ_RTCTIMER_DEFAULT=y
CONFIG_SND_GENERIC_DRIVER=y
CONFIG_SND_MPU401_UART=m
CONFIG_SND_OPL3_LIB=m
CONFIG_SND_MPU401=m
CONFIG_SND_SBAWE=m
CONFIG_SND_SB16_CSP=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB=y
CONFIG_USB_DEVICEFS=y
CONFIG_USB_DYNAMIC_MINORS=y
CONFIG_USB_UHCI_HCD=y
CONFIG_USB_STORAGE=y
CONFIG_USB_STORAGE_ISD200=y
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_JBD=y
CONFIG_FS_MBCACHE=y
CONFIG_REISERFS_FS=y
CONFIG_REISERFS_FS_XATTR=y
CONFIG_REISERFS_FS_POSIX_ACL=y
CONFIG_FS_POSIX_ACL=y
CONFIG_MINIX_FS=m
CONFIG_INOTIFY=y
CONFIG_QUOTA=y
CONFIG_QFMT_V2=y
CONFIG_QUOTACTL=y
CONFIG_DNOTIFY=y
CONFIG_FUSE_FS=y
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=y
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=m
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
CONFIG_PROC_FS=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
CONFIG_RAMFS=y
CONFIG_RELAYFS_FS=m
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFSD=y
CONFIG_NFSD_V2_ACL=y
CONFIG_NFSD_V3=y
CONFIG_NFSD_V3_ACL=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=y
CONFIG_NFS_ACL_SUPPORT=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
CONFIG_PARTITION_ADVANCED=y
CONFIG_MSDOS_PARTITION=y
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=m
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_CODEPAGE_852=m
CONFIG_NLS_ASCII=m
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_2=m
CONFIG_NLS_ISO8859_15=m
CONFIG_LOG_BUF_SHIFT=14
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_EARLY_PRINTK=y
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=m
CONFIG_CRYPTO_SHA1=m
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_SHA512=m
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRC32=y
CONFIG_ZLIB_INFLATE=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_BIOS_REBOOT=y

-- 
`I won't make a secret of the fact that your statement/question
 sent a wave of shock and horror through us.' --- David Anderson

Re: memory leak in scsi_cmd_cache 2.6.15

[Jens Axboe]

On Fri, Jan 27 2006, Nix wrote:
> On 26 Jan 2006, Ariel noted:
> > Is this good or bad? I'm guessing it means it's still leaking. So it's
> > really starting to look like ata_piix is the problem. But we need someone
> > who has the leak to remove that and see if it helps. I can't, since my
> > drives are connected to it.
> 
> FWIW, a bit of negative-confirmatory evidence: I have a sym53c875
> and non-SATA IDE drive on this 2.6.15.1, and there is no leak,
> nor was there in 2.6.15:
> 
>     11     11 100%    0.34K      1       11         4K scsi_cmd_cache

It's not a bad data point, it just confirms that setting ->ordered_flush
to 0 in the SATA drivers will fix the leak. So really, it's as expected.
So far apparently nobody tried it, suggested it twice.

-- 
Jens Axboe

Re: memory leak in scsi_cmd_cache 2.6.15

[Chase Venters]

On Saturday 28 January 2006 13:26, Jens Axboe wrote:
> It's not a bad data point, it just confirms that setting ->ordered_flush
> to 0 in the SATA drivers will fix the leak. So really, it's as expected.
> So far apparently nobody tried it, suggested it twice.

In case you still wanted the data point, I just set ordered_flush to 0 on my 
ata_piix and the slab leak disappeared.

Thanks,
Chase

Re: memory leak in scsi_cmd_cache 2.6.15

[Jens Axboe]

On Sat, Jan 28 2006, Chase Venters wrote:
> On Saturday 28 January 2006 13:26, Jens Axboe wrote:
> > It's not a bad data point, it just confirms that setting ->ordered_flush
> > to 0 in the SATA drivers will fix the leak. So really, it's as expected.
> > So far apparently nobody tried it, suggested it twice.
> 
> In case you still wanted the data point, I just set ordered_flush to 0 on my 
> ata_piix and the slab leak disappeared.

Thanks for confirming!

-- 
Jens Axboe

Re: memory leak in scsi_cmd_cache 2.6.15

[Pasi Kärkkäinen]

On Sat, Jan 28, 2006 at 08:27:14PM +0100, Jens Axboe wrote:
> On Fri, Jan 27 2006, Nix wrote:
> > On 26 Jan 2006, Ariel noted:
> > > Is this good or bad? I'm guessing it means it's still leaking. So it's
> > > really starting to look like ata_piix is the problem. But we need someone
> > > who has the leak to remove that and see if it helps. I can't, since my
> > > drives are connected to it.
> > 
> > FWIW, a bit of negative-confirmatory evidence: I have a sym53c875
> > and non-SATA IDE drive on this 2.6.15.1, and there is no leak,
> > nor was there in 2.6.15:
> > 
> >     11     11 100%    0.34K      1       11         4K scsi_cmd_cache
> 
> It's not a bad data point, it just confirms that setting ->ordered_flush
> to 0 in the SATA drivers will fix the leak. So really, it's as expected.
> So far apparently nobody tried it, suggested it twice.
> 

Are all sata drivers affected by this bug in 2.6.15?

Any 'official' patch available?

Or is the recommended workaround to set ordered_flush to 0 to fix this..
does that have any downsides?

-- Pasi

Re: memory leak in scsi_cmd_cache 2.6.15

[James Bottomley]

On Sun, 2006-01-29 at 17:50 +0200, Pasi Kärkkäinen wrote:
> Are all sata drivers affected by this bug in 2.6.15?

Well, all SCSI drivers are affected by it, yes.  However, SATA devices
are peculiarly affected because the ordered_flush method of enforcing
barriers, which is where the leak is, can only be implemented for
devices that don't do tag command queueing (i.e. don't have multiple
commands outstanding for a given single device).  By and large, SATA
drivers are the only drivers in the SCSI subsystem that can't do tag
command queueing, which is why the problem didn't show up for any other
type of SCSI driver.

> Any 'official' patch available?

Well, yes, 2.6.16-rc1 has this fixed.  I can't see backporting this to
2.6.15.x since it represents a significant functionality enhancement as
well, so I'd lean towards just forcing ordered_flush to zero in 2.6.15.x
which seems to be the best bug fix.

> Or is the recommended workaround to set ordered_flush to 0 to fix this..
> does that have any downsides?

setting ordered_flush to zero for 2.6.15 turns off the flushing
functionality and restores the old behaviour.  I don't see that there
would be any down side to this.

James

Re: memory leak in scsi_cmd_cache 2.6.15

[Pasi Kärkkäinen]

On Sun, Jan 29, 2006 at 10:38:12AM -0600, James Bottomley wrote:
> On Sun, 2006-01-29 at 17:50 +0200, Pasi Kärkkäinen wrote:
> > Are all sata drivers affected by this bug in 2.6.15?
> 
> Well, all SCSI drivers are affected by it, yes.  However, SATA devices
> are peculiarly affected because the ordered_flush method of enforcing
> barriers, which is where the leak is, can only be implemented for
> devices that don't do tag command queueing (i.e. don't have multiple
> commands outstanding for a given single device).  By and large, SATA
> drivers are the only drivers in the SCSI subsystem that can't do tag
> command queueing, which is why the problem didn't show up for any other
> type of SCSI driver.
>

OK.. thanks for summarizing this.
 
> > Any 'official' patch available?
> 
> Well, yes, 2.6.16-rc1 has this fixed.  I can't see backporting this to
> 2.6.15.x since it represents a significant functionality enhancement as
> well, so I'd lean towards just forcing ordered_flush to zero in 2.6.15.x
> which seems to be the best bug fix.
>

OK.
 
> > Or is the recommended workaround to set ordered_flush to 0 to fix this..
> > does that have any downsides?
> 
> setting ordered_flush to zero for 2.6.15 turns off the flushing
> functionality and restores the old behaviour.  I don't see that there
> would be any down side to this.
> 

That's good to hear. Thanks.

-- Pasi 

Re: memory leak in scsi_cmd_cache 2.6.15

[Jens Axboe]

On Sun, Jan 29 2006, James Bottomley wrote:
> On Sun, 2006-01-29 at 17:50 +0200, Pasi Kärkkäinen wrote:
> > Are all sata drivers affected by this bug in 2.6.15?
> 
> Well, all SCSI drivers are affected by it, yes.  However, SATA devices
> are peculiarly affected because the ordered_flush method of enforcing
> barriers, which is where the leak is, can only be implemented for
> devices that don't do tag command queueing (i.e. don't have multiple
> commands outstanding for a given single device).  By and large, SATA
> drivers are the only drivers in the SCSI subsystem that can't do tag
> command queueing, which is why the problem didn't show up for any other
> type of SCSI driver.

2.6.15 didn't support barriers for anything other than ordered flush
SCSI low level drivers, hence only SATA is affected.

> > Any 'official' patch available?
> 
> Well, yes, 2.6.16-rc1 has this fixed.  I can't see backporting this to
> 2.6.15.x since it represents a significant functionality enhancement as
> well, so I'd lean towards just forcing ordered_flush to zero in 2.6.15.x
> which seems to be the best bug fix.

Agree, backporting the barrier rewrite would be insane for stable.

> > Or is the recommended workaround to set ordered_flush to 0 to fix this..
> > does that have any downsides?
> 
> setting ordered_flush to zero for 2.6.15 turns off the flushing
> functionality and restores the old behaviour.  I don't see that there
> would be any down side to this.

Just the usual correctness issue, but since it's leaky it doesn't seem
like a big deal to wait for 2.6.16.

So here's a patch for 2.6.15:

---

Turn off ordered flush barriers for SCSI driver, since the SCSI barrier
code has a command leak.

Signed-off-by: Jens Axboe <axboe@suse.de>

--- linux-2.6.15.1/drivers/scsi/scsi_lib.c~	2006-01-29 11:55:08.000000000 -0800
+++ linux-2.6.15.1/drivers/scsi/scsi_lib.c	2006-01-29 11:55:38.000000000 -0800
@@ -1534,11 +1534,6 @@
 	 */
 	if (shost->ordered_tag)
 		blk_queue_ordered(q, QUEUE_ORDERED_TAG);
-	else if (shost->ordered_flush) {
-		blk_queue_ordered(q, QUEUE_ORDERED_FLUSH);
-		q->prepare_flush_fn = scsi_prepare_flush_fn;
-		q->end_flush_fn = scsi_end_flush_fn;
-	}
 
 	if (!shost->use_clustering)
 		clear_bit(QUEUE_FLAG_CLUSTER, &q->queue_flags);

-- 
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: memory leak in scsi_cmd_cache 2.6.15

[Ariel]

On Sun, 22 Jan 2006, Chase Venters wrote:

> We did determine that Anton and I both use the Marvell sk98lin patch for our
> Yukon2s. However, Anton reported other servers using this patch with no leak.
>
> Ariel - are you using sk98lin? The only other modules I'm using are the ALSA
> modules for snd-hda-intel as of ALSA version 1.0.11-rc2.

Not that I know of. I'm using the kernel from debian unstable, so it's 
whatever patches they use: 
http://svn.debian.org/wsvn/kernel/releases/linux-2.6/2.6.15-2/debian/patches/?rev=0&sc=0

Are you using SATA?

 	-Ariel