* memory leak in scsi_cmd_cache 2.6.15 @ 2006-01-22 2:13 Ariel 2006-01-22 6:58 ` Andrew Morton 2006-01-22 8:16 ` Arjan van de Ven 0 siblings, 2 replies; 30+ messages in thread From: Ariel @ 2006-01-22 2:13 UTC (permalink / raw) To: linux-ide, linux-kernel [-- Attachment #1: Type: TEXT/PLAIN, Size: 18037 bytes --] I have a memory leak in scsi_cmd_cache. Attached is a pretty graph made by munin, and you can see slab_cache growing constantly since last reboot. Also attached is /proc/config.gz And here is a copy of /proc/meminfo and /proc/slabinfo I'm rebooting now since my system is all but unusable (so the mem stats will reset), but if you need any more info let me know. -Ariel > uname -a Linux cherryberry.dsgml.com 2.6.15 #4 SMP Thu Jan 12 02:09:21 EST 2006 i686 GNU/Linux > cat /proc/meminfo MemTotal: 1032816 kB MemFree: 13404 kB Buffers: 5040 kB Cached: 38472 kB SwapCached: 87320 kB Active: 152660 kB Inactive: 10944 kB HighTotal: 131008 kB HighFree: 800 kB LowTotal: 901808 kB LowFree: 12604 kB SwapTotal: 8386528 kB SwapFree: 7860012 kB Dirty: 992 kB Writeback: 0 kB Mapped: 150152 kB Slab: 827436 kB CommitLimit: 8902936 kB Committed_AS: 1186920 kB PageTables: 3684 kB VmallocTotal: 114680 kB VmallocUsed: 63700 kB VmallocChunk: 47604 kB > cat /proc/slabinfo slabinfo - version: 2.1 # name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail> nv_pte_t 142 254 12 254 1 : tunables 120 60 8 : slabdata 1 1 0 fib6_nodes 5 113 32 113 1 : tunables 120 60 8 : slabdata 1 1 0 ip6_dst_cache 4 15 256 15 1 : tunables 120 60 8 : slabdata 1 1 0 ndisc_cache 1 15 256 15 1 : tunables 120 60 8 : slabdata 1 1 0 RAWv6 4 6 640 6 1 : tunables 54 27 8 : slabdata 1 1 0 UDPv6 3 18 640 6 1 : tunables 54 27 8 : slabdata 3 3 0 tw_sock_TCPv6 0 0 128 30 1 : tunables 120 60 8 : slabdata 0 0 0 request_sock_TCPv6 0 0 128 30 1 : tunables 120 60 8 : slabdata 0 0 0 TCPv6 5 6 1280 3 1 : tunables 24 12 8 : slabdata 2 2 0 packet_task 0 0 44 84 1 : tunables 120 60 8 : slabdata 0 0 0 raid5/md0 256 256 480 8 1 : tunables 54 27 8 : slabdata 32 32 0 rpc_buffers 8 8 2048 2 1 : tunables 24 12 8 : slabdata 4 4 0 rpc_tasks 8 15 256 15 1 : tunables 120 60 8 : slabdata 1 1 0 rpc_inode_cache 0 0 512 7 1 : tunables 54 27 8 : slabdata 0 0 0 UNIX 212 240 384 10 1 : tunables 54 27 8 : slabdata 24 24 0 ip_conntrack_expect 0 0 92 42 1 : tunables 120 60 8 : slabdata 0 0 0 ip_conntrack 256 468 216 18 1 : tunables 120 60 8 : slabdata 26 26 0 tcp_bind_bucket 43 203 16 203 1 : tunables 120 60 8 : slabdata 1 1 0 inet_peer_cache 1 59 64 59 1 : tunables 120 60 8 : slabdata 1 1 0 secpath_cache 0 0 128 30 1 : tunables 120 60 8 : slabdata 0 0 0 xfrm_dst_cache 0 0 384 10 1 : tunables 54 27 8 : slabdata 0 0 0 ip_fib_alias 17 113 32 113 1 : tunables 120 60 8 : slabdata 1 1 0 ip_fib_hash 17 113 32 113 1 : tunables 120 60 8 : slabdata 1 1 0 ip_dst_cache 478 870 256 15 1 : tunables 120 60 8 : slabdata 58 58 0 arp_cache 4 15 256 15 1 : tunables 120 60 8 : slabdata 1 1 0 RAW 5 7 512 7 1 : tunables 54 27 8 : slabdata 1 1 0 UDP 33 35 512 7 1 : tunables 54 27 8 : slabdata 5 5 0 tw_sock_TCP 11 30 128 30 1 : tunables 120 60 8 : slabdata 1 1 0 request_sock_TCP 35 59 64 59 1 : tunables 120 60 8 : slabdata 1 1 0 TCP 135 161 1152 7 2 : tunables 24 12 8 : slabdata 23 23 0 flow_cache 0 0 128 30 1 : tunables 120 60 8 : slabdata 0 0 0 dm-crypt_io 0 0 68 56 1 : tunables 120 60 8 : slabdata 0 0 0 dm_tio 1652 2030 16 203 1 : tunables 120 60 8 : slabdata 10 10 60 dm_io 1652 2030 16 203 1 : tunables 120 60 8 : slabdata 10 10 60 i2o_block_req 32 33 2176 3 2 : tunables 24 12 8 : slabdata 11 11 0 uhci_urb_priv 75 184 40 92 1 : tunables 120 60 8 : slabdata 2 2 7 scsi_cmd_cache 2007640 2007640 384 10 1 : tunables 54 27 8 : slabdata 200764 200764 0 cfq_ioc_pool 0 0 48 78 1 : tunables 120 60 8 : slabdata 0 0 0 cfq_pool 0 0 96 40 1 : tunables 120 60 8 : slabdata 0 0 0 crq_pool 0 0 48 78 1 : tunables 120 60 8 : slabdata 0 0 0 deadline_drq 0 0 52 72 1 : tunables 120 60 8 : slabdata 0 0 0 as_arq 169 531 64 59 1 : tunables 120 60 8 : slabdata 9 9 0 mqueue_inode_cache 1 6 640 6 1 : tunables 54 27 8 : slabdata 1 1 0 fuse_request 0 0 320 12 1 : tunables 54 27 8 : slabdata 0 0 0 fuse_inode 0 0 384 10 1 : tunables 54 27 8 : slabdata 0 0 0 romfs_inode_cache 0 0 364 11 1 : tunables 54 27 8 : slabdata 0 0 0 ntfs_big_inode_cache 0 0 640 6 1 : tunables 54 27 8 : slabdata 0 0 0 ntfs_inode_cache 0 0 176 22 1 : tunables 120 60 8 : slabdata 0 0 0 ntfs_name_cache 0 0 512 8 1 : tunables 54 27 8 : slabdata 0 0 0 ntfs_attr_ctx_cache 0 0 32 113 1 : tunables 120 60 8 : slabdata 0 0 0 ntfs_index_ctx_cache 0 0 64 59 1 : tunables 120 60 8 : slabdata 0 0 0 hpfs_inode_cache 0 0 444 9 1 : tunables 54 27 8 : slabdata 0 0 0 cifs_small_rq 30 30 256 15 1 : tunables 120 60 8 : slabdata 2 2 0 cifs_request 4 4 16640 1 8 : tunables 8 4 0 : slabdata 4 4 0 cifs_oplock_structs 0 0 32 113 1 : tunables 120 60 8 : slabdata 0 0 0 cifs_mpx_ids 3 59 64 59 1 : tunables 120 60 8 : slabdata 1 1 0 cifs_inode_cache 0 0 392 10 1 : tunables 54 27 8 : slabdata 0 0 0 smb_request 0 0 256 15 1 : tunables 120 60 8 : slabdata 0 0 0 smb_inode_cache 0 0 380 10 1 : tunables 54 27 8 : slabdata 0 0 0 nfs_write_data 36 42 512 7 1 : tunables 54 27 8 : slabdata 6 6 0 nfs_read_data 32 35 512 7 1 : tunables 54 27 8 : slabdata 5 5 0 nfs_inode_cache 0 0 608 6 1 : tunables 54 27 8 : slabdata 0 0 0 nfs_page 0 0 64 59 1 : tunables 120 60 8 : slabdata 0 0 0 isofs_inode_cache 0 0 384 10 1 : tunables 54 27 8 : slabdata 0 0 0 fat_inode_cache 0 0 412 9 1 : tunables 54 27 8 : slabdata 0 0 0 fat_cache 0 0 20 169 1 : tunables 120 60 8 : slabdata 0 0 0 coda_inode_cache 0 0 400 10 1 : tunables 54 27 8 : slabdata 0 0 0 ext2_inode_cache 0 0 468 8 1 : tunables 54 27 8 : slabdata 0 0 0 journal_handle 52 169 20 169 1 : tunables 120 60 8 : slabdata 1 1 0 journal_head 223 720 52 72 1 : tunables 120 60 8 : slabdata 10 10 0 revoke_table 12 254 12 254 1 : tunables 120 60 8 : slabdata 1 1 0 revoke_record 15 203 16 203 1 : tunables 120 60 8 : slabdata 1 1 0 ext3_inode_cache 1941 3320 488 8 1 : tunables 54 27 8 : slabdata 415 415 0 dnotify_cache 154 169 20 169 1 : tunables 120 60 8 : slabdata 1 1 0 dquot 0 0 128 30 1 : tunables 120 60 8 : slabdata 0 0 0 eventpoll_pwq 0 0 36 101 1 : tunables 120 60 8 : slabdata 0 0 0 eventpoll_epi 0 0 128 30 1 : tunables 120 60 8 : slabdata 0 0 0 inotify_event_cache 0 0 28 127 1 : tunables 120 60 8 : slabdata 0 0 0 inotify_watch_cache 1 101 36 101 1 : tunables 120 60 8 : slabdata 1 1 0 kioctx 0 0 256 15 1 : tunables 120 60 8 : slabdata 0 0 0 kiocb 0 0 128 30 1 : tunables 120 60 8 : slabdata 0 0 0 fasync_cache 1 203 16 203 1 : tunables 120 60 8 : slabdata 1 1 0 shmem_inode_cache 3813 3840 452 8 1 : tunables 54 27 8 : slabdata 480 480 0 posix_timers_cache 0 0 96 40 1 : tunables 120 60 8 : slabdata 0 0 0 uid_cache 12 59 64 59 1 : tunables 120 60 8 : slabdata 1 1 0 sgpool-128 32 32 2048 2 1 : tunables 24 12 8 : slabdata 16 16 0 sgpool-64 32 36 1024 4 1 : tunables 54 27 8 : slabdata 8 9 0 sgpool-32 39 48 512 8 1 : tunables 54 27 8 : slabdata 6 6 0 sgpool-16 42 60 256 15 1 : tunables 120 60 8 : slabdata 4 4 0 sgpool-8 180 180 128 30 1 : tunables 120 60 8 : slabdata 6 6 0 blkdev_ioc 1685 1778 28 127 1 : tunables 120 60 8 : slabdata 14 14 0 blkdev_queue 39 50 388 10 1 : tunables 54 27 8 : slabdata 5 5 0 blkdev_requests 205 480 160 24 1 : tunables 120 60 8 : slabdata 20 20 60 biovec-(256) 260 260 3072 2 2 : tunables 24 12 8 : slabdata 130 130 0 biovec-128 264 265 1536 5 2 : tunables 24 12 8 : slabdata 53 53 0 biovec-64 312 330 768 5 1 : tunables 54 27 8 : slabdata 66 66 0 biovec-16 283 300 256 15 1 : tunables 120 60 8 : slabdata 20 20 0 biovec-4 286 295 64 59 1 : tunables 120 60 8 : slabdata 5 5 0 biovec-1 771 3654 16 203 1 : tunables 120 60 8 : slabdata 18 18 368 bio 756 1440 128 30 1 : tunables 120 60 8 : slabdata 48 48 384 file_lock_cache 30 84 92 42 1 : tunables 120 60 8 : slabdata 2 2 0 sock_inode_cache 407 434 512 7 1 : tunables 54 27 8 : slabdata 62 62 0 skbuff_fclone_cache 286 330 384 10 1 : tunables 54 27 8 : slabdata 33 33 189 skbuff_head_cache 411 555 256 15 1 : tunables 120 60 8 : slabdata 37 37 0 acpi_operand 1232 1288 40 92 1 : tunables 120 60 8 : slabdata 14 14 0 acpi_parse_ext 4 84 44 84 1 : tunables 120 60 8 : slabdata 1 1 0 acpi_parse 65 127 28 127 1 : tunables 120 60 8 : slabdata 1 1 0 acpi_state 66 78 48 78 1 : tunables 120 60 8 : slabdata 1 1 0 proc_inode_cache 54 160 372 10 1 : tunables 54 27 8 : slabdata 16 16 0 sigqueue 135 135 144 27 1 : tunables 120 60 8 : slabdata 5 5 0 radix_tree_node 3442 7896 276 14 1 : tunables 54 27 8 : slabdata 564 564 0 bdev_cache 62 63 512 7 1 : tunables 54 27 8 : slabdata 9 9 0 sysfs_dir_cache 6116 6256 40 92 1 : tunables 120 60 8 : slabdata 68 68 0 mnt_cache 32 60 128 30 1 : tunables 120 60 8 : slabdata 2 2 0 inode_cache 1591 1661 356 11 1 : tunables 54 27 8 : slabdata 151 151 0 dentry_cache 7709 14868 140 28 1 : tunables 120 60 8 : slabdata 531 531 30 filp 3196 4185 256 15 1 : tunables 120 60 8 : slabdata 279 279 0 names_cache 25 25 4096 1 1 : tunables 24 12 8 : slabdata 25 25 0 idr_layer_cache 151 174 136 29 1 : tunables 120 60 8 : slabdata 6 6 0 buffer_head 1996 5688 52 72 1 : tunables 120 60 8 : slabdata 79 79 300 mm_struct 124 161 512 7 1 : tunables 54 27 8 : slabdata 23 23 0 vm_area_struct 7950 9944 88 44 1 : tunables 120 60 8 : slabdata 226 226 1 fs_cache 129 295 64 59 1 : tunables 120 60 8 : slabdata 5 5 0 files_cache 126 154 512 7 1 : tunables 54 27 8 : slabdata 22 22 0 signal_cache 178 220 384 10 1 : tunables 54 27 8 : slabdata 22 22 0 sighand_cache 174 190 1408 5 2 : tunables 24 12 8 : slabdata 38 38 0 task_struct 215 231 1328 3 1 : tunables 24 12 8 : slabdata 77 77 0 anon_vma 2707 5080 12 254 1 : tunables 120 60 8 : slabdata 20 20 0 pgd 124 124 4096 1 1 : tunables 24 12 8 : slabdata 124 124 0 size-131072(DMA) 0 0 131072 1 32 : tunables 8 4 0 : slabdata 0 0 0 size-131072 0 0 131072 1 32 : tunables 8 4 0 : slabdata 0 0 0 size-65536(DMA) 0 0 65536 1 16 : tunables 8 4 0 : slabdata 0 0 0 size-65536 6 6 65536 1 16 : tunables 8 4 0 : slabdata 6 6 0 size-32768(DMA) 0 0 32768 1 8 : tunables 8 4 0 : slabdata 0 0 0 size-32768 0 0 32768 1 8 : tunables 8 4 0 : slabdata 0 0 0 size-16384(DMA) 0 0 16384 1 4 : tunables 8 4 0 : slabdata 0 0 0 size-16384 4 4 16384 1 4 : tunables 8 4 0 : slabdata 4 4 0 size-8192(DMA) 0 0 8192 1 2 : tunables 8 4 0 : slabdata 0 0 0 size-8192 241 250 8192 1 2 : tunables 8 4 0 : slabdata 241 250 0 size-4096(DMA) 0 0 4096 1 1 : tunables 24 12 8 : slabdata 0 0 0 size-4096 436 436 4096 1 1 : tunables 24 12 8 : slabdata 436 436 0 size-2048(DMA) 0 0 2048 2 1 : tunables 24 12 8 : slabdata 0 0 0 size-2048 320 348 2048 2 1 : tunables 24 12 8 : slabdata 174 174 84 size-1024(DMA) 0 0 1024 4 1 : tunables 54 27 8 : slabdata 0 0 0 size-1024 336 336 1024 4 1 : tunables 54 27 8 : slabdata 84 84 0 size-512(DMA) 0 0 512 8 1 : tunables 54 27 8 : slabdata 0 0 0 size-512 651 760 512 8 1 : tunables 54 27 8 : slabdata 95 95 54 size-256(DMA) 0 0 256 15 1 : tunables 120 60 8 : slabdata 0 0 0 size-256 1230 1230 256 15 1 : tunables 120 60 8 : slabdata 82 82 0 size-128(DMA) 0 0 128 30 1 : tunables 120 60 8 : slabdata 0 0 0 size-128 3390 3390 128 30 1 : tunables 120 60 8 : slabdata 113 113 0 size-64(DMA) 0 0 64 59 1 : tunables 120 60 8 : slabdata 0 0 0 size-32(DMA) 0 0 32 113 1 : tunables 120 60 8 : slabdata 0 0 0 size-64 4880 8732 64 59 1 : tunables 120 60 8 : slabdata 148 148 180 size-32 4085 6102 32 113 1 : tunables 120 60 8 : slabdata 54 54 0 kmem_cache 210 210 128 30 1 : tunables 120 60 8 : slabdata 7 7 0 [-- Attachment #2: Type: IMAGE/png, Size: 21400 bytes --] [-- Attachment #3: Type: APPLICATION/octet-stream, Size: 10924 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: memory leak in scsi_cmd_cache 2.6.15 2006-01-22 2:13 memory leak in scsi_cmd_cache 2.6.15 Ariel @ 2006-01-22 6:58 ` Andrew Morton 2006-01-22 18:18 ` Ariel 2006-01-22 8:16 ` Arjan van de Ven 1 sibling, 1 reply; 30+ messages in thread From: Andrew Morton @ 2006-01-22 6:58 UTC (permalink / raw) To: Ariel; +Cc: linux-ide, linux-kernel, linux-scsi 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. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: memory leak in scsi_cmd_cache 2.6.15 2006-01-22 6:58 ` Andrew Morton @ 2006-01-22 18:18 ` Ariel 0 siblings, 0 replies; 30+ messages in thread From: Ariel @ 2006-01-22 18:18 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-ide, linux-kernel, linux-scsi 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: memory leak in scsi_cmd_cache 2.6.15 2006-01-22 2:13 memory leak in scsi_cmd_cache 2.6.15 Ariel 2006-01-22 6:58 ` Andrew Morton @ 2006-01-22 8:16 ` Arjan van de Ven 2006-01-22 8:20 ` Arjan van de Ven 1 sibling, 1 reply; 30+ messages in thread From: Arjan van de Ven @ 2006-01-22 8:16 UTC (permalink / raw) To: Ariel; +Cc: linux-ide, linux-kernel On Sat, 2006-01-21 at 21:13 -0500, Ariel wrote: > I have a memory leak in scsi_cmd_cache. > > Attached is a pretty graph made by munin, and you can see slab_cache > growing constantly since last reboot. Also attached is /proc/config.gz > > And here is a copy of /proc/meminfo and /proc/slabinfo > > I'm rebooting now since my system is all but unusable (so the mem stats > will reset), but if you need any more info let me know. does this happen without the binary nvidia driver too? (it appears you're using that). That's a good datapoint to have if so... ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: memory leak in scsi_cmd_cache 2.6.15 2006-01-22 8:16 ` Arjan van de Ven @ 2006-01-22 8:20 ` Arjan van de Ven 2006-01-22 18:51 ` Ariel 0 siblings, 1 reply; 30+ messages in thread From: Arjan van de Ven @ 2006-01-22 8:20 UTC (permalink / raw) To: Ariel; +Cc: linux-ide, linux-kernel 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. > > > > Attached is a pretty graph made by munin, and you can see slab_cache > > growing constantly since last reboot. Also attached is /proc/config.gz > > > > And here is a copy of /proc/meminfo and /proc/slabinfo > > > > I'm rebooting now since my system is all but unusable (so the mem stats > > will reset), but if you need any more info let me know. > > > does this happen without the binary nvidia driver too? (it appears > you're using that). That's a good datapoint to have if so... btw please post an lsmod, so that we can find "common" things with the other reporters of this issue, and thus maybe are able to get closer to the issue by reducing the candidates... ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: memory leak in scsi_cmd_cache 2.6.15 2006-01-22 8:20 ` Arjan van de Ven @ 2006-01-22 18:51 ` Ariel 2006-01-22 19:07 ` Arjan van de Ven 0 siblings, 1 reply; 30+ messages in thread From: Ariel @ 2006-01-22 18:51 UTC (permalink / raw) To: Arjan van de Ven; +Cc: linux-ide, linux-kernel 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... I had the exact same nvidia driver with 2.6.12 (just recompiled) and it didn't happen there. But just in case I used slabtop to watch scsi_cmd_cache grow by 1.24KB per second (104MB per day), then I rmmoded nvidia and watched it grow by 1.16KB per second. The speed is not constant, watching it, and listening to the disks, it looks like it grows with each IO request. > btw please post an lsmod, so that we can find "common" things with the > other reporters of this issue, and thus maybe are able to get closer to > the issue by reducing the candidates... Here is my lsmod, but since I compile most things into the kernel the config.gz I sent earlier is probably much more useful. And BTW I don't even have any scsi devices. scsi is being used by sata and usb storage. -Ariel Module Size Used by nvidia 3924252 12 vmnet 34340 3 vmmon 172556 0 snd_rtctimer 3724 1 ipv6 269408 24 ipt_state 2304 5 ipt_MASQUERADE 4096 1 eth1394 21512 0 cx88_blackbird 21276 0 tvaudio 24732 0 msp3400 35248 0 tda9887 16656 0 tuner 45476 0 cx88_dvb 10628 0 cx8802 12676 2 cx88_blackbird,cx88_dvb mt352 7172 1 cx88_dvb or51132 11140 1 cx88_dvb video_buf_dvb 7172 1 cx88_dvb ohci1394 35764 0 bttv 168208 0 nxt200x 16004 1 cx88_dvb firmware_class 10880 4 cx88_blackbird,or51132,bttv,nxt200x cx8800 33548 1 cx88_blackbird ieee1394 313016 2 eth1394,ohci1394 cx88xx 63776 4 cx88_blackbird,cx88_dvb,cx8802,cx8800 snd_bt87x 15432 3 video_buf 22788 7 cx88_blackbird,cx88_dvb,cx8802,video_buf_dvb,bttv,cx8800,cx88xx ir_common 9988 1 cx88xx tveeprom 15760 2 bttv,cx88xx lgdt330x 8604 1 cx88_dvb cx22702 6916 1 cx88_dvb btcx_risc 5384 4 cx8802,bttv,cx8800,cx88xx ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: memory leak in scsi_cmd_cache 2.6.15 2006-01-22 18:51 ` Ariel @ 2006-01-22 19:07 ` Arjan van de Ven 2006-01-22 19:16 ` Chase Venters ` (3 more replies) 0 siblings, 4 replies; 30+ messages in thread From: Arjan van de Ven @ 2006-01-22 19:07 UTC (permalink / raw) To: Ariel; +Cc: linux-ide, linux-kernel On Sun, 2006-01-22 at 13:51 -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... > > I had the exact same nvidia driver with 2.6.12 (just recompiled) and it > didn't happen there. > > But just in case I used slabtop to watch scsi_cmd_cache grow by 1.24KB per > second (104MB per day), then I rmmoded nvidia and watched it grow by > 1.16KB per 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. <lsmod snipped> I see you also use vmware. The other person who reported this also uses vmware. Could you please repeat the test without BOTH the nvidia and vmware modules? ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: memory leak in scsi_cmd_cache 2.6.15 2006-01-22 19:07 ` Arjan van de Ven @ 2006-01-22 19:16 ` Chase Venters 2006-01-22 19:24 ` Arjan van de Ven 2006-01-22 19:24 ` Chase Venters ` (2 subsequent siblings) 3 siblings, 1 reply; 30+ messages in thread From: Chase Venters @ 2006-01-22 19:16 UTC (permalink / raw) To: Arjan van de Ven; +Cc: Ariel, linux-ide, linux-kernel On Sunday 22 January 2006 13:06, Arjan van de Ven wrote: > I see you also use vmware. The other person who reported this also uses > vmware. Could you please repeat the test without BOTH the nvidia and > vmware modules? Arjan, FYI - I reported this as well and I do not use VMWare. Cheers, Chase ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: memory leak in scsi_cmd_cache 2.6.15 2006-01-22 19:16 ` Chase Venters @ 2006-01-22 19:24 ` Arjan van de Ven 2006-01-22 19:46 ` Chase Venters 0 siblings, 1 reply; 30+ messages in thread From: Arjan van de Ven @ 2006-01-22 19:24 UTC (permalink / raw) To: Chase Venters; +Cc: Ariel, linux-ide, linux-kernel On Sun, 2006-01-22 at 13:16 -0600, Chase Venters wrote: > On Sunday 22 January 2006 13:06, Arjan van de Ven wrote: > > I see you also use vmware. The other person who reported this also uses > > vmware. Could you please repeat the test without BOTH the nvidia and > > vmware modules? > > Arjan, > FYI - I reported this as well and I do not use VMWare. and you're not using nvidia either? can you see if you have modules/drivers in common with this reporter to see if there maybe are common suspects? ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: memory leak in scsi_cmd_cache 2.6.15 2006-01-22 19:24 ` Arjan van de Ven @ 2006-01-22 19:46 ` Chase Venters 2006-01-23 2:19 ` Ariel 0 siblings, 1 reply; 30+ messages in thread From: Chase Venters @ 2006-01-22 19:46 UTC (permalink / raw) To: Arjan van de Ven; +Cc: Ariel, linux-ide, linux-kernel On Sunday 22 January 2006 13:24, Arjan van de Ven wrote: > and you're not using nvidia either? can you see if you have > modules/drivers in common with this reporter to see if there maybe are > common suspects? No - I am tainting with NVIDIA unfortunately. I was trying to find the time to diagnose sans NVIDIA when Anton reported the same leak (turns out he has the same Asus P5GDC-V Deluxe board), only in his dmesg he is not tainting at all. 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. Cheers, Chase ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: memory leak in scsi_cmd_cache 2.6.15 2006-01-22 19:46 ` Chase Venters @ 2006-01-23 2:19 ` Ariel 0 siblings, 0 replies; 30+ messages in thread From: Ariel @ 2006-01-23 2:19 UTC (permalink / raw) To: Chase Venters; +Cc: Arjan van de Ven, linux-ide, linux-kernel, linux-scsi 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: memory leak in scsi_cmd_cache 2.6.15 2006-01-22 19:07 ` Arjan van de Ven 2006-01-22 19:16 ` Chase Venters @ 2006-01-22 19:24 ` Chase Venters 2006-01-23 0:58 ` Jamie Heilman 2006-01-23 2:14 ` Ariel 3 siblings, 0 replies; 30+ messages in thread From: Chase Venters @ 2006-01-22 19:24 UTC (permalink / raw) To: Arjan van de Ven; +Cc: Ariel, linux-ide, linux-kernel On Sunday 22 January 2006 13:06, Arjan van de Ven wrote: > I see you also use vmware. The other person who reported this also uses > vmware. Could you please repeat the test without BOTH the nvidia and > vmware modules? Arjan, Forgot to mention as well... Anton Titov reported this problem, and after going over his boot-time dmesg again it appears he's not tainting his kernel at all. Cheers, Chase ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: memory leak in scsi_cmd_cache 2.6.15 2006-01-22 19:07 ` Arjan van de Ven 2006-01-22 19:16 ` Chase Venters 2006-01-22 19:24 ` Chase Venters @ 2006-01-23 0:58 ` Jamie Heilman 2006-01-23 2:14 ` Ariel 3 siblings, 0 replies; 30+ messages in thread From: Jamie Heilman @ 2006-01-23 0:58 UTC (permalink / raw) To: Arjan van de Ven; +Cc: Ariel, linux-ide, linux-kernel Arjan van de Ven wrote: > On Sun, 2006-01-22 at 13:51 -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... > > > > I had the exact same nvidia driver with 2.6.12 (just recompiled) and it > > didn't happen there. > > > > But just in case I used slabtop to watch scsi_cmd_cache grow by 1.24KB per > > second (104MB per day), then I rmmoded nvidia and watched it grow by > > 1.16KB per > > 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. Hrmph, yeah one of my workstations is exhibiting this too. I use the nvidia module, but I did clean reboot without it loaded and the leak was still there. So I'll add my data points at http://audible.transient.net/~jamie/k/ ... all the files starting with "scsi_cmd_cache." -- Jamie Heilman http://audible.transient.net/~jamie/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: memory leak in scsi_cmd_cache 2.6.15 2006-01-22 19:07 ` Arjan van de Ven ` (2 preceding siblings ...) 2006-01-23 0:58 ` Jamie Heilman @ 2006-01-23 2:14 ` Ariel 2006-01-23 6:18 ` Arjan van de Ven 3 siblings, 1 reply; 30+ messages in thread From: Ariel @ 2006-01-23 2:14 UTC (permalink / raw) To: Arjan van de Ven; +Cc: linux-ide, linux-kernel, linux-scsi 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: memory leak in scsi_cmd_cache 2.6.15 2006-01-23 2:14 ` Ariel @ 2006-01-23 6:18 ` Arjan van de Ven 2006-01-23 6:28 ` Chase Venters 0 siblings, 1 reply; 30+ messages in thread From: Arjan van de Ven @ 2006-01-23 6:18 UTC (permalink / raw) To: Ariel; +Cc: linux-ide, linux-kernel, linux-scsi 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? ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: memory leak in scsi_cmd_cache 2.6.15 2006-01-23 6:18 ` Arjan van de Ven @ 2006-01-23 6:28 ` Chase Venters 2006-01-23 6:46 ` Ariel 0 siblings, 1 reply; 30+ messages in thread From: Chase Venters @ 2006-01-23 6:28 UTC (permalink / raw) To: Arjan van de Ven; +Cc: Ariel, linux-ide, linux-kernel, linux-scsi 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: memory leak in scsi_cmd_cache 2.6.15 2006-01-23 6:28 ` Chase Venters @ 2006-01-23 6:46 ` Ariel 2006-01-23 7:25 ` Jamie Heilman 0 siblings, 1 reply; 30+ messages in thread From: Ariel @ 2006-01-23 6:46 UTC (permalink / raw) To: Chase Venters Cc: Arjan van de Ven, Jamie Heilman, linux-ide, linux-kernel, linux-scsi 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: memory leak in scsi_cmd_cache 2.6.15 2006-01-23 6:46 ` Ariel @ 2006-01-23 7:25 ` Jamie Heilman 2006-01-23 8:33 ` Jens Axboe 2006-01-26 18:12 ` Ariel 0 siblings, 2 replies; 30+ messages in thread From: Jamie Heilman @ 2006-01-23 7:25 UTC (permalink / raw) To: Ariel Cc: Chase Venters, Arjan van de Ven, linux-ide, linux-kernel, linux-scsi 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/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: memory leak in scsi_cmd_cache 2.6.15 2006-01-23 7:25 ` Jamie Heilman @ 2006-01-23 8:33 ` Jens Axboe 2006-01-27 11:28 ` Jamie Heilman 2006-01-26 18:12 ` Ariel 1 sibling, 1 reply; 30+ messages in thread From: Jens Axboe @ 2006-01-23 8:33 UTC (permalink / raw) To: Ariel, Chase Venters, Arjan van de Ven, linux-ide, linux-kernel, linux-scsi 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: memory leak in scsi_cmd_cache 2.6.15 2006-01-23 8:33 ` Jens Axboe @ 2006-01-27 11:28 ` Jamie Heilman 2006-01-28 19:27 ` Jens Axboe 0 siblings, 1 reply; 30+ messages in thread From: Jamie Heilman @ 2006-01-27 11:28 UTC (permalink / raw) To: Jens Axboe Cc: Ariel, Chase Venters, Arjan van de Ven, linux-ide, linux-kernel, linux-scsi 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/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: memory leak in scsi_cmd_cache 2.6.15 2006-01-27 11:28 ` Jamie Heilman @ 2006-01-28 19:27 ` Jens Axboe 0 siblings, 0 replies; 30+ messages in thread From: Jens Axboe @ 2006-01-28 19:27 UTC (permalink / raw) To: Ariel, Chase Venters, Arjan van de Ven, linux-ide, linux-kernel, linux-scsi 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: memory leak in scsi_cmd_cache 2.6.15 2006-01-23 7:25 ` Jamie Heilman 2006-01-23 8:33 ` Jens Axboe @ 2006-01-26 18:12 ` Ariel 2006-01-27 16:23 ` Nix 1 sibling, 1 reply; 30+ messages in thread From: Ariel @ 2006-01-26 18:12 UTC (permalink / raw) To: Jamie Heilman Cc: Chase Venters, Arjan van de Ven, linux-ide, linux-kernel, linux-scsi 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: memory leak in scsi_cmd_cache 2.6.15 2006-01-26 18:12 ` Ariel @ 2006-01-27 16:23 ` Nix 2006-01-28 19:27 ` Jens Axboe 0 siblings, 1 reply; 30+ messages in thread From: Nix @ 2006-01-27 16:23 UTC (permalink / raw) To: Ariel Cc: Jamie Heilman, Chase Venters, Arjan van de Ven, linux-ide, linux-kernel, linux-scsi 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: memory leak in scsi_cmd_cache 2.6.15 2006-01-27 16:23 ` Nix @ 2006-01-28 19:27 ` Jens Axboe 2006-01-28 19:46 ` Chase Venters 2006-01-29 15:50 ` Pasi Kärkkäinen 0 siblings, 2 replies; 30+ messages in thread From: Jens Axboe @ 2006-01-28 19:27 UTC (permalink / raw) To: Nix Cc: Ariel, Jamie Heilman, Chase Venters, Arjan van de Ven, linux-ide, linux-kernel, linux-scsi 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: memory leak in scsi_cmd_cache 2.6.15 2006-01-28 19:27 ` Jens Axboe @ 2006-01-28 19:46 ` Chase Venters 2006-01-28 21:29 ` Jens Axboe 2006-01-29 15:50 ` Pasi Kärkkäinen 1 sibling, 1 reply; 30+ messages in thread From: Chase Venters @ 2006-01-28 19:46 UTC (permalink / raw) To: Jens Axboe Cc: Nix, Ariel, Jamie Heilman, Arjan van de Ven, linux-ide, linux-kernel, linux-scsi 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: memory leak in scsi_cmd_cache 2.6.15 2006-01-28 19:46 ` Chase Venters @ 2006-01-28 21:29 ` Jens Axboe 0 siblings, 0 replies; 30+ messages in thread From: Jens Axboe @ 2006-01-28 21:29 UTC (permalink / raw) To: Chase Venters Cc: Nix, Ariel, Jamie Heilman, Arjan van de Ven, linux-ide, linux-kernel, linux-scsi 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: memory leak in scsi_cmd_cache 2.6.15 2006-01-28 19:27 ` Jens Axboe 2006-01-28 19:46 ` Chase Venters @ 2006-01-29 15:50 ` Pasi Kärkkäinen 2006-01-29 16:38 ` James Bottomley 1 sibling, 1 reply; 30+ messages in thread From: Pasi Kärkkäinen @ 2006-01-29 15:50 UTC (permalink / raw) To: Jens Axboe Cc: Nix, Ariel, Jamie Heilman, Chase Venters, Arjan van de Ven, linux-ide, linux-kernel, linux-scsi 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: memory leak in scsi_cmd_cache 2.6.15 2006-01-29 15:50 ` Pasi Kärkkäinen @ 2006-01-29 16:38 ` James Bottomley 2006-01-29 17:10 ` Pasi Kärkkäinen 2006-01-29 19:57 ` Jens Axboe 0 siblings, 2 replies; 30+ messages in thread From: James Bottomley @ 2006-01-29 16:38 UTC (permalink / raw) To: Pasi Kärkkäinen Cc: Jens Axboe, Nix, Ariel, Jamie Heilman, Chase Venters, Arjan van de Ven, linux-ide, linux-kernel, linux-scsi 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: memory leak in scsi_cmd_cache 2.6.15 2006-01-29 16:38 ` James Bottomley @ 2006-01-29 17:10 ` Pasi Kärkkäinen 2006-01-29 19:57 ` Jens Axboe 1 sibling, 0 replies; 30+ messages in thread From: Pasi Kärkkäinen @ 2006-01-29 17:10 UTC (permalink / raw) To: James Bottomley Cc: Jens Axboe, Nix, Ariel, Jamie Heilman, Chase Venters, Arjan van de Ven, linux-ide, linux-kernel, linux-scsi 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: memory leak in scsi_cmd_cache 2.6.15 2006-01-29 16:38 ` James Bottomley 2006-01-29 17:10 ` Pasi Kärkkäinen @ 2006-01-29 19:57 ` Jens Axboe 1 sibling, 0 replies; 30+ messages in thread From: Jens Axboe @ 2006-01-29 19:57 UTC (permalink / raw) To: James Bottomley Cc: Pasi Kärkkäinen, Nix, Ariel, Jamie Heilman, Chase Venters, Arjan van de Ven, linux-ide, linux-kernel, linux-scsi 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2006-01-29 20:00 UTC | newest] Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-01-22 2:13 memory leak in scsi_cmd_cache 2.6.15 Ariel 2006-01-22 6:58 ` Andrew Morton 2006-01-22 18:18 ` Ariel 2006-01-22 8:16 ` Arjan van de Ven 2006-01-22 8:20 ` Arjan van de Ven 2006-01-22 18:51 ` Ariel 2006-01-22 19:07 ` Arjan van de Ven 2006-01-22 19:16 ` Chase Venters 2006-01-22 19:24 ` Arjan van de Ven 2006-01-22 19:46 ` Chase Venters 2006-01-23 2:19 ` Ariel 2006-01-22 19:24 ` Chase Venters 2006-01-23 0:58 ` Jamie Heilman 2006-01-23 2:14 ` Ariel 2006-01-23 6:18 ` Arjan van de Ven 2006-01-23 6:28 ` Chase Venters 2006-01-23 6:46 ` Ariel 2006-01-23 7:25 ` Jamie Heilman 2006-01-23 8:33 ` Jens Axboe 2006-01-27 11:28 ` Jamie Heilman 2006-01-28 19:27 ` Jens Axboe 2006-01-26 18:12 ` Ariel 2006-01-27 16:23 ` Nix 2006-01-28 19:27 ` Jens Axboe 2006-01-28 19:46 ` Chase Venters 2006-01-28 21:29 ` Jens Axboe 2006-01-29 15:50 ` Pasi Kärkkäinen 2006-01-29 16:38 ` James Bottomley 2006-01-29 17:10 ` Pasi Kärkkäinen 2006-01-29 19:57 ` Jens Axboe
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).