* 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 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 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 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: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: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: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-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-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 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-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-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-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-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).