* sata_sil24 0000:04:00.0: DMA-API: device driver frees DMA sg list with different entry count [map count=13] [unmap count=10]
@ 2009-05-26 19:14 Torsten Kaiser
2009-05-26 23:40 ` Robert Hancock
0 siblings, 1 reply; 15+ messages in thread
From: Torsten Kaiser @ 2009-05-26 19:14 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: SCSI development list
On upgrading to 2.6.30-rc1 I enable the DMA-Debugging option
CONFIG_DMA_API_DEBUG=y
Since then I get the following or similar errors on each boot:
May 26 06:50:31 treogen [ 231.082923] ------------[ cut here ]------------
May 26 06:50:31 treogen [ 231.082942] WARNING: at lib/dma-debug.c:530
check_unmap+0x65e/0x6a0()
May 26 06:50:31 treogen [ 231.082947] Hardware name: KFN5-D SLI
May 26 06:50:31 treogen [ 231.082952] sata_sil24 0000:04:00.0:
DMA-API: device driver frees DMA sg list with different entry count
[map count=13] [unmap count=10]
May 26 06:50:31 treogen [ 231.082958] Modules linked in: msp3400
tuner tea5767 tda8290 tuner_xc2028 xc5000 tda9887 tuner_simple
tuner_types mt20xx tea5761 bttv ir_common v4l2_common videodev
v4l1_compat v4l2_compat_ioctl32 videobuf_dma_sg videobuf_core sg
pata_amd btcx_risc tveeprom
May 26 06:50:31 treogen [ 231.083000] Pid: 3575, comm: logger Not
tainted 2.6.30-rc7 #1
May 26 06:50:31 treogen [ 231.083005] Call Trace:
May 26 06:50:31 treogen [ 231.083009] <IRQ> [<ffffffff8041755e>] ?
check_unmap+0x65e/0x6a0
May 26 06:50:31 treogen [ 231.083026] [<ffffffff802432d8>]
warn_slowpath_common+0x78/0xd0
May 26 06:50:31 treogen [ 231.083033] [<ffffffff802433b4>]
warn_slowpath_fmt+0x64/0x70
May 26 06:50:31 treogen [ 231.083043] [<ffffffff8028dd42>] ?
mempool_free_slab+0x12/0x20
May 26 06:50:31 treogen [ 231.083054] [<ffffffff8068d74d>] ?
_spin_lock_irqsave+0x1d/0x40
May 26 06:50:31 treogen [ 231.083061] [<ffffffff8041755e>]
check_unmap+0x65e/0x6a0
May 26 06:50:31 treogen [ 231.083068] [<ffffffff804176ae>]
debug_dma_unmap_sg+0x10e/0x1b0
May 26 06:50:31 treogen [ 231.083077] [<ffffffff804bfe31>] ?
__scsi_put_command+0x61/0xa0
May 26 06:50:31 treogen [ 231.083086] [<ffffffff804d2f68>]
ata_sg_clean+0x78/0xf0
May 26 06:50:31 treogen [ 231.083093] [<ffffffff804d3015>]
__ata_qc_complete+0x35/0x110
May 26 06:50:31 treogen [ 231.083101] [<ffffffff804c6898>] ?
scsi_io_completion+0x398/0x530
May 26 06:50:31 treogen [ 231.083108] [<ffffffff804d31ad>]
ata_qc_complete+0xbd/0x250
May 26 06:50:31 treogen [ 231.083116] [<ffffffff804d36eb>]
ata_qc_complete_multiple+0xab/0xf0
May 26 06:50:31 treogen [ 231.083125] [<ffffffff804e8f99>]
sil24_interrupt+0xb9/0x5b0
May 26 06:50:31 treogen [ 231.083133] [<ffffffff80273030>]
handle_IRQ_event+0x70/0x180
May 26 06:50:31 treogen [ 231.083140] [<ffffffff8027533d>]
handle_fasteoi_irq+0x6d/0xe0
May 26 06:50:31 treogen [ 231.083147] [<ffffffff8020e42f>]
handle_irq+0x1f/0x30
May 26 06:50:31 treogen [ 231.083153] [<ffffffff8020db7a>] do_IRQ+0x6a/0xf0
May 26 06:50:31 treogen [ 231.083162] [<ffffffff8020be53>]
ret_from_intr+0x0/0xf
May 26 06:50:31 treogen [ 231.083166] <EOI> [<ffffffff8068d5fa>] ?
_spin_unlock_irqrestore+0x1a/0x40
May 26 06:50:31 treogen [ 231.083179] [<ffffffff80405981>] ?
__up_read+0x91/0xb0
May 26 06:50:31 treogen [ 231.083188] [<ffffffff8025da89>] ? up_read+0x9/0x10
May 26 06:50:31 treogen [ 231.083196] [<ffffffff80229477>] ?
do_page_fault+0x147/0x280
May 26 06:50:31 treogen [ 231.083204] [<ffffffff8068d9df>] ?
page_fault+0x1f/0x30
May 26 06:50:31 treogen [ 231.083209] ---[ end trace 9d69801031c35329 ]---
May 26 06:50:31 treogen [ 231.083213] Mapped at:
May 26 06:50:31 treogen [ 231.083215] [<ffffffff80416d69>]
debug_dma_map_sg+0x159/0x180
May 26 06:50:31 treogen [ 231.083224] [<ffffffff804d34dc>]
ata_qc_issue+0x19c/0x300
May 26 06:50:31 treogen [ 231.083231] [<ffffffff804d93d8>]
ata_scsi_translate+0xa8/0x180
May 26 06:50:31 treogen [ 231.083239] [<ffffffff804dbf71>]
ata_scsi_queuecmd+0xb1/0x2d0
May 26 06:50:31 treogen [ 231.083245] [<ffffffff804bfc33>]
scsi_dispatch_cmd+0xe3/0x220
Other traces:
One with a size mismatch instead of the wrong map count:
May 26 19:16:55 treogen [ 131.688242] ------------[ cut here ]------------
May 26 19:16:55 treogen [ 131.688262] WARNING: at lib/dma-debug.c:505
check_unmap+0x455/0x6a0()
May 26 19:16:55 treogen [ 131.688267] Hardware name: KFN5-D SLI
May 26 19:16:55 treogen [ 131.688273] sata_sil24 0000:04:00.0:
DMA-API: device driver frees DMA memory
with different size [device address=0x0000000078886000] [map
size=8192 bytes] [unmap size=16384 bytes]
May 26 19:16:55 treogen [ 131.688280] Modules linked in: msp3400
tuner tea5767 tda8290 tuner_xc2028 xc
5000 tda9887 tuner_simple tuner_types mt20xx tea5761 bttv ir_common
v4l2_common videodev v4l1_compat v4
l2_compat_ioctl32 videobuf_dma_sg videobuf_core btcx_risc tveeprom sg pata_amd
May 26 19:16:55 treogen [ 131.688322] Pid: 0, comm: swapper Not
tainted 2.6.30-rc7 #1
May 26 19:16:55 treogen [ 131.688327] Call Trace:
May 26 19:16:55 treogen [ 131.688331] <IRQ> [<ffffffff80417355>] ?
check_unmap+0x455/0x6a0
May 26 19:16:55 treogen [ 131.688348] [<ffffffff802432d8>]
warn_slowpath_common+0x78/0xd0
May 26 19:16:55 treogen [ 131.688355] [<ffffffff802433b4>]
warn_slowpath_fmt+0x64/0x70
May 26 19:16:55 treogen [ 131.688366] [<ffffffff8028dd42>] ?
mempool_free_slab+0x12/0x20
May 26 19:16:55 treogen [ 131.688376] [<ffffffff8068d74d>] ?
_spin_lock_irqsave+0x1d/0x40
May 26 19:16:55 treogen [ 131.688384] [<ffffffff80417355>]
check_unmap+0x455/0x6a0
May 26 19:16:55 treogen [ 131.688391] [<ffffffff804176ae>]
debug_dma_unmap_sg+0x10e/0x1b0
May 26 19:16:55 treogen [ 131.688400] [<ffffffff804bfe31>] ?
__scsi_put_command+0x61/0xa0
May 26 19:16:55 treogen [ 131.688410] [<ffffffff804d2f68>]
ata_sg_clean+0x78/0xf0
May 26 19:16:55 treogen [ 131.688417] [<ffffffff804d3015>]
__ata_qc_complete+0x35/0x110
May 26 19:16:55 treogen [ 131.688426] [<ffffffff804c6898>] ?
scsi_io_completion+0x398/0x530
May 26 19:16:55 treogen [ 131.688433] [<ffffffff804d31ad>]
ata_qc_complete+0xbd/0x250
May 26 19:16:55 treogen [ 131.688441] [<ffffffff804d36eb>]
ata_qc_complete_multiple+0xab/0xf0
May 26 19:16:55 treogen [ 131.688450] [<ffffffff804e8f99>]
sil24_interrupt+0xb9/0x5b0
May 26 19:16:55 treogen [ 131.688457] [<ffffffff8026147c>] ?
getnstimeofday+0x5c/0xf0
May 26 19:16:55 treogen [ 131.688466] [<ffffffff8025d309>] ?
ktime_get_ts+0x59/0x60
May 26 19:16:55 treogen [ 131.688474] [<ffffffff80273030>]
handle_IRQ_event+0x70/0x180
May 26 19:16:55 treogen [ 131.688482] [<ffffffff8027533d>]
handle_fasteoi_irq+0x6d/0xe0
May 26 19:16:55 treogen [ 131.688489] [<ffffffff8020e42f>]
handle_irq+0x1f/0x30
May 26 19:16:55 treogen [ 131.688495] [<ffffffff8020db7a>] do_IRQ+0x6a/0xf0
May 26 19:16:55 treogen [ 131.688504] [<ffffffff8020be53>]
ret_from_intr+0x0/0xf
May 26 19:16:55 treogen [ 131.688508] <EOI> [<ffffffff80213657>] ?
default_idle+0x77/0xe0
May 26 19:16:55 treogen [ 131.688522] [<ffffffff80213655>] ?
default_idle+0x75/0xe0
May 26 19:16:55 treogen [ 131.688529] [<ffffffff8025e37f>] ?
notifier_call_chain+0x3f/0x80
May 26 19:16:55 treogen [ 131.688536] [<ffffffff802136f8>] ?
c1e_idle+0x38/0x110
May 26 19:16:55 treogen [ 131.688544] [<ffffffff8020a71e>] ?
cpu_idle+0x6e/0xd0
May 26 19:16:55 treogen [ 131.688553] [<ffffffff8067adbd>] ?
rest_init+0x6d/0x80
May 26 19:16:55 treogen [ 131.688562] [<ffffffff80929cc5>] ?
start_kernel+0x35a/0x422
May 26 19:16:55 treogen [ 131.688570] [<ffffffff80929289>] ?
x86_64_start_reservations+0x99/0xb9
May 26 19:16:55 treogen [ 131.688577] [<ffffffff80929389>] ?
x86_64_start_kernel+0xe0/0xf2
May 26 19:16:55 treogen [ 131.688582] ---[ end trace cff6b5339db27b54 ]---
May 26 19:16:55 treogen [ 131.688585] Mapped at:
May 26 19:16:55 treogen [ 131.688588] [<ffffffff80416d69>]
debug_dma_map_sg+0x159/0x180
May 26 19:16:55 treogen [ 131.688597] [<ffffffff804d34dc>]
ata_qc_issue+0x19c/0x300
May 26 19:16:55 treogen [ 131.688604] [<ffffffff804d93d8>]
ata_scsi_translate+0xa8/0x180
May 26 19:16:55 treogen [ 131.688613] [<ffffffff804dbf71>]
ata_scsi_queuecmd+0xb1/0x2d0
May 26 19:16:55 treogen [ 131.688619] [<ffffffff804bfc33>]
scsi_dispatch_cmd+0xe3/0x220
sometimes the "Mapped at" info is missing:
May 23 03:57:55 treogen [ 70.774289] ------------[ cut here ]------------
May 23 03:57:55 treogen [ 70.774297] WARNING: at lib/dma-debug.c:530
check_unmap+0x65e/0x6a0()
May 23 03:57:55 treogen [ 70.774302] Hardware name: KFN5-D SLI
May 23 03:57:55 treogen [ 70.774307] sata_sil24 0000:04:00.0:
DMA-API: device driver frees DMA sg lis
t with different entry count [map count=4] [unmap count=2]
May 23 03:57:55 treogen [ 70.774313] Modules linked in: msp3400
tuner tea5767 tda8290 tuner_xc2028 xc
5000 tda9887 tuner_simple tuner_types mt20xx tea5761 bttv ir_common
v4l2_common videodev v4l1_compat v4
l2_compat_ioctl32 videobuf_dma_sg videobuf_core btcx_risc tveeprom pata_amd sg
May 23 03:57:55 treogen [ 70.774355] Pid: 458, comm: xfslogd/3 Not
tainted 2.6.30-rc6 #1
May 23 03:57:55 treogen [ 70.774359] Call Trace:
May 23 03:57:55 treogen [ 70.774363] <IRQ> [<ffffffff80243330>]
warn_slowpath_fmt+0xd0/0x120
May 23 03:57:55 treogen [ 70.774383] [<ffffffff8020e966>] ?
dump_trace+0x116/0x2c0
May 23 03:57:55 treogen [ 70.774395] [<ffffffff8068d4bf>] ?
_spin_unlock_irqrestore+0x2f/0x40
May 23 03:57:55 treogen [ 70.774402] [<ffffffff804163c4>] ?
add_dma_entry+0x64/0x80
May 23 03:57:55 treogen [ 70.774413] [<ffffffff804e8c90>] ?
sil24_qc_prep+0xb0/0x150
May 23 03:57:55 treogen [ 70.774422] [<ffffffff804d33f5>] ?
ata_qc_issue+0x1e5/0x300
May 23 03:57:55 treogen [ 70.774430] [<ffffffff804bf9f0>] ?
scsi_done+0x0/0x20
May 23 03:57:55 treogen [ 70.774438] [<ffffffff804d8ff0>] ?
ata_scsi_rw_xlat+0x0/0x210
May 23 03:57:55 treogen [ 70.774445] [<ffffffff804d92a8>] ?
ata_scsi_translate+0xa8/0x180
May 23 03:57:55 treogen [ 70.774452] [<ffffffff804174de>]
check_unmap+0x65e/0x6a0
May 23 03:57:55 treogen [ 70.774459] [<ffffffff8041762e>]
debug_dma_unmap_sg+0x10e/0x1b0
May 23 03:57:55 treogen [ 70.774467] [<ffffffff804bfcf1>] ?
__scsi_put_command+0x61/0xa0
May 23 03:57:55 treogen [ 70.774474] [<ffffffff804d2e38>]
ata_sg_clean+0x78/0xf0
May 23 03:57:55 treogen [ 70.774480] [<ffffffff804d2ee5>]
__ata_qc_complete+0x35/0x110
May 23 03:57:55 treogen [ 70.774489] [<ffffffff804c6758>] ?
scsi_io_completion+0x398/0x530
May 23 03:57:55 treogen [ 70.774496] [<ffffffff804d307d>]
ata_qc_complete+0xbd/0x250
May 23 03:57:55 treogen [ 70.774503] [<ffffffff804d35bb>]
ata_qc_complete_multiple+0xab/0xf0
May 23 03:57:55 treogen [ 70.774510] [<ffffffff804e8e69>]
sil24_interrupt+0xb9/0x5a0
May 23 03:57:55 treogen [ 70.774520] [<ffffffff80272ff0>]
handle_IRQ_event+0x70/0x180
May 23 03:57:55 treogen [ 70.774527] [<ffffffff802752fd>]
handle_fasteoi_irq+0x6d/0xe0
May 23 03:57:55 treogen [ 70.774533] [<ffffffff8020e42f>]
handle_irq+0x1f/0x30
May 23 03:57:55 treogen [ 70.774538] [<ffffffff8020db7a>] do_IRQ+0x6a/0xf0
May 23 03:57:55 treogen [ 70.774547] [<ffffffff8020be53>]
ret_from_intr+0x0/0xf
May 23 03:57:55 treogen [ 70.774551] <EOI> [<ffffffff8023c544>] ?
finish_task_switch+0x54/0x100
May 23 03:57:55 treogen [ 70.774566] [<ffffffff803fbc00>] ?
cfq_kick_queue+0x0/0x40
May 23 03:57:55 treogen [ 70.774573] [<ffffffff8068aad7>] ?
thread_return+0x3e/0x6f7
May 23 03:57:55 treogen [ 70.774582] [<ffffffff803bcb00>] ?
xfs_buf_iodone_work+0x0/0xa0
May 23 03:57:55 treogen [ 70.774589] [<ffffffff803bcb00>] ?
xfs_buf_iodone_work+0x0/0xa0
May 23 03:57:55 treogen [ 70.774595] [<ffffffff8068b199>] ? schedule+0x9/0x20
May 23 03:57:55 treogen [ 70.774604] [<ffffffff80255d45>] ?
worker_thread+0x1e5/0x1f0
May 23 03:57:55 treogen [ 70.774612] [<ffffffff80259cc0>] ?
autoremove_wake_function+0x0/0x40
May 23 03:57:55 treogen [ 70.774620] [<ffffffff80255b60>] ?
worker_thread+0x0/0x1f0
May 23 03:57:55 treogen [ 70.774627] [<ffffffff80255b60>] ?
worker_thread+0x0/0x1f0
May 23 03:57:55 treogen [ 70.774633] [<ffffffff80259826>] ? kthread+0x56/0x90
May 23 03:57:55 treogen [ 70.774641] [<ffffffff8020c4aa>] ?
child_rip+0xa/0x20
May 23 03:57:55 treogen [ 70.774648] [<ffffffff8020bea9>] ?
restore_args+0x0/0x30
May 23 03:57:55 treogen [ 70.774654] [<ffffffff802597d0>] ? kthread+0x0/0x90
May 23 03:57:55 treogen [ 70.774661] [<ffffffff8020c4a0>] ?
child_rip+0x0/0x20
May 23 03:57:55 treogen [ 70.774665] ---[ end trace 65ea6e90ae7ed767 ]---
May 23 03:57:55 treogen [ 70.774669] Mapped at:
May 23 03:57:55 treogen [ 70.774672] [<ffffffffffffffff>] 0xffffffffffffffff
It is also not at the same time of each boot, once it took really long
to show up:
May 24 15:50:24 treogen [25330.655309] ------------[ cut here ]------------
May 24 15:50:24 treogen [25330.655327] WARNING: at lib/dma-debug.c:530
check_unmap+0x65e/0x6a0()
May 24 15:50:24 treogen [25330.655331] Hardware name: KFN5-D SLI
May 24 15:50:24 treogen [25330.655337] sata_sil24 0000:04:00.0:
DMA-API: device driver frees DMA sg lis
t with different entry count [map count=2] [unmap count=1]
May 24 15:50:24 treogen [25330.655342] Modules linked in: msp3400
tuner tea5767 tda8290 tuner_xc2028 xc
5000 tda9887 tuner_simple tuner_types mt20xx tea5761 bttv ir_common
v4l2_common videodev v4l1_compat v4
l2_compat_ioctl32 videobuf_dma_sg videobuf_core btcx_risc sg tveeprom pata_amd
May 24 15:50:24 treogen [25330.655384] Pid: 0, comm: swapper Not
tainted 2.6.30-rc7 #1
May 24 15:50:24 treogen [25330.655388] Call Trace:
May 24 15:50:24 treogen [25330.655392] <IRQ> [<ffffffff8041755e>] ?
check_unmap+0x65e/0x6a0
May 24 15:50:24 treogen [25330.655408] [<ffffffff802432d8>]
warn_slowpath_common+0x78/0xd0
May 24 15:50:24 treogen [25330.655415] [<ffffffff802433b4>]
warn_slowpath_fmt+0x64/0x70
May 24 15:50:24 treogen [25330.655425] [<ffffffff8028ddda>] ?
mempool_free+0x8a/0xa0
May 24 15:50:24 treogen [25330.655432] [<ffffffff8028dd42>] ?
mempool_free_slab+0x12/0x20
May 24 15:50:24 treogen [25330.655442] [<ffffffff8068d74d>] ?
_spin_lock_irqsave+0x1d/0x40
May 24 15:50:24 treogen [25330.655449] [<ffffffff8041755e>]
check_unmap+0x65e/0x6a0
May 24 15:50:24 treogen [25330.655457] [<ffffffff804176ae>]
debug_dma_unmap_sg+0x10e/0x1b0
May 24 15:50:24 treogen [25330.655465] [<ffffffff802c0de5>] ?
__slab_free+0x185/0x340
May 24 15:50:24 treogen [25330.655474] [<ffffffff804bfe31>] ?
__scsi_put_command+0x61/0xa0
May 24 15:50:24 treogen [25330.655483] [<ffffffff804d2f68>]
ata_sg_clean+0x78/0xf0
May 24 15:50:24 treogen [25330.655490] [<ffffffff804d3015>]
__ata_qc_complete+0x35/0x110
May 24 15:50:24 treogen [25330.655499] [<ffffffff804c6898>] ?
scsi_io_completion+0x398/0x530
May 24 15:50:24 treogen [25330.655506] [<ffffffff804d31ad>]
ata_qc_complete+0xbd/0x250
May 24 15:50:24 treogen [25330.655513] [<ffffffff804d36eb>]
ata_qc_complete_multiple+0xab/0xf0
May 24 15:50:24 treogen [25330.655522] [<ffffffff804e8f99>]
sil24_interrupt+0xb9/0x5b0
May 24 15:50:24 treogen [25330.655529] [<ffffffff8026147c>] ?
getnstimeofday+0x5c/0xf0
May 24 15:50:24 treogen [25330.655538] [<ffffffff8025d309>] ?
ktime_get_ts+0x59/0x60
May 24 15:50:24 treogen [25330.655546] [<ffffffff80273030>]
handle_IRQ_event+0x70/0x180
May 24 15:50:24 treogen [25330.655553] [<ffffffff8027533d>]
handle_fasteoi_irq+0x6d/0xe0
May 24 15:50:24 treogen [25330.655561] [<ffffffff8020e42f>]
handle_irq+0x1f/0x30
May 24 15:50:24 treogen [25330.655566] [<ffffffff8020db7a>] do_IRQ+0x6a/0xf0
May 24 15:50:24 treogen [25330.655575] [<ffffffff8020be53>]
ret_from_intr+0x0/0xf
May 24 15:50:24 treogen [25330.655579] <EOI> [<ffffffff80213657>] ?
default_idle+0x77/0xe0
May 24 15:50:24 treogen [25330.655592] [<ffffffff80213655>] ?
default_idle+0x75/0xe0
May 24 15:50:24 treogen [25330.655600] [<ffffffff8025e37f>] ?
notifier_call_chain+0x3f/0x80
May 24 15:50:24 treogen [25330.655607] [<ffffffff802136f8>] ?
c1e_idle+0x38/0x110
May 24 15:50:24 treogen [25330.655614] [<ffffffff8020a71e>] ?
cpu_idle+0x6e/0xd0
May 24 15:50:24 treogen [25330.655623] [<ffffffff8067adbd>] ?
rest_init+0x6d/0x80
May 24 15:50:24 treogen [25330.655632] [<ffffffff80929cc5>] ?
start_kernel+0x35a/0x422
May 24 15:50:24 treogen [25330.655639] [<ffffffff80929289>] ?
x86_64_start_reservations+0x99/0xb9
May 24 15:50:24 treogen [25330.655646] [<ffffffff80929389>] ?
x86_64_start_kernel+0xe0/0xf2
May 24 15:50:24 treogen [25330.655651] ---[ end trace 513a0b087125ae17 ]---
May 24 15:50:24 treogen [25330.655655] Mapped at:
May 24 15:50:24 treogen [25330.655658] [<ffffffff80416d69>]
debug_dma_map_sg+0x159/0x180
May 24 15:50:24 treogen [25330.655666] [<ffffffff804d34dc>]
ata_qc_issue+0x19c/0x300
May 24 15:50:24 treogen [25330.655674] [<ffffffff804d93d8>]
ata_scsi_translate+0xa8/0x180
May 24 15:50:24 treogen [25330.655682] [<ffffffff804dbf71>]
ata_scsi_queuecmd+0xb1/0x2d0
May 24 15:50:24 treogen [25330.655688] [<ffffffff804bfc33>]
scsi_dispatch_cmd+0xe3/0x220
The system in an AMD x86_64 with 4GB of RAM, some of it remapped to
above the 32bit address limit.
lspci from the controller in question:
04:00.0 Mass storage controller: Silicon Image, Inc. SiI 3132 Serial
ATA Raid II Controller (rev 01)
Subsystem: ASUSTeK Computer Inc. Device 819f
Flags: bus master, fast devsel, latency 0, IRQ 19
Memory at efeffc00 (64-bit, non-prefetchable) [size=128]
Memory at efef8000 (64-bit, non-prefetchable) [size=16K]
I/O ports at ec00 [size=128]
Expansion ROM at efe00000 [disabled] [size=512K]
Capabilities: [54] Power Management version 2
Capabilities: [5c] MSI: Mask- 64bit+ Count=1/1 Enable-
Capabilities: [70] Express Legacy Endpoint, MSI 00
Kernel driver in use: sata_sil24
Looking at the code in libata I can't see any problems with
qc->orig_n_elem, so I have no clue what goes wrong here.
If you need more information, please ask.
Torsten
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: sata_sil24 0000:04:00.0: DMA-API: device driver frees DMA sg list with different entry count [map count=13] [unmap count=10]
2009-05-26 19:14 sata_sil24 0000:04:00.0: DMA-API: device driver frees DMA sg list with different entry count [map count=13] [unmap count=10] Torsten Kaiser
@ 2009-05-26 23:40 ` Robert Hancock
2009-05-27 2:11 ` Torsten Kaiser
2009-06-03 19:30 ` Torsten Kaiser
0 siblings, 2 replies; 15+ messages in thread
From: Robert Hancock @ 2009-05-26 23:40 UTC (permalink / raw)
To: Torsten Kaiser; +Cc: Linux Kernel Mailing List, SCSI development list
Torsten Kaiser wrote:
> On upgrading to 2.6.30-rc1 I enable the DMA-Debugging option
> CONFIG_DMA_API_DEBUG=y
> Since then I get the following or similar errors on each boot:
Please retest with a newer -rc, this patch likely fixes it:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5825627c9463581fd9e70f8285685889ae5bb9bb
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: sata_sil24 0000:04:00.0: DMA-API: device driver frees DMA sg list with different entry count [map count=13] [unmap count=10]
2009-05-26 23:40 ` Robert Hancock
@ 2009-05-27 2:11 ` Torsten Kaiser
2009-06-03 19:30 ` Torsten Kaiser
1 sibling, 0 replies; 15+ messages in thread
From: Torsten Kaiser @ 2009-05-27 2:11 UTC (permalink / raw)
To: Robert Hancock; +Cc: Linux Kernel Mailing List, SCSI development list
On Wed, May 27, 2009 at 1:40 AM, Robert Hancock <hancockrwd@gmail.com> wrote:
> Torsten Kaiser wrote:
>>
>> On upgrading to 2.6.30-rc1 I enable the DMA-Debugging option
>> CONFIG_DMA_API_DEBUG=y
>> Since then I get the following or similar errors on each boot:
>
> Please retest with a newer -rc, this patch likely fixes it:
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5825627c9463581fd9e70f8285685889ae5bb9bb
>
I saw this with 2.6.30-rc1 the first time, but I'm not sure if it
broke during the merge window or if it was always broken, because I
did not have enable DMA_API_DEBUG with earlier kernels.
But I'm seeing it with all -rc since then. The traces I posted were
from -rc6 and -rc7.
Torsten
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: sata_sil24 0000:04:00.0: DMA-API: device driver frees DMA sg list with different entry count [map count=13] [unmap count=10]
2009-05-26 23:40 ` Robert Hancock
2009-05-27 2:11 ` Torsten Kaiser
@ 2009-06-03 19:30 ` Torsten Kaiser
2009-06-03 20:21 ` Kasper Sandberg
2009-06-04 0:02 ` FUJITA Tomonori
1 sibling, 2 replies; 15+ messages in thread
From: Torsten Kaiser @ 2009-06-03 19:30 UTC (permalink / raw)
To: Robert Hancock; +Cc: Linux Kernel Mailing List, SCSI development list
On Wed, May 27, 2009 at 1:40 AM, Robert Hancock <hancockrwd@gmail.com> wrote:
> Torsten Kaiser wrote:
>>
>> On upgrading to 2.6.30-rc1 I enable the DMA-Debugging option
>> CONFIG_DMA_API_DEBUG=y
>> Since then I get the following or similar errors on each boot:
>
> Please retest with a newer -rc, this patch likely fixes it:
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5825627c9463581fd9e70f8285685889ae5bb9bb
>
Still happens with 2.6.30-rc8 (see trace at the end of the email)
As orig_n_elem is only used two times in libata-core.c I suspected a
corruption of the qc->sg, but adding checks for this did not trigger.
So I looked into lib/dma-debug.c.
It seems add_dma_entry() does not protect against adding the same
entry twice. That could explain these warnings, if the hash_bucket
returns a different entry that then has the wrong map/unmap count.
So I added WARN_ON(hash_bucket_find(bucket, entry)); before the
hash_bucket_add(bucket, entry); in add_dma_entry();
That WARN_ON() triggered more then 1500 times until the KDE desktop
was loaded...
This is the first full stackdump, I dont have the real first one,
because the dmesg buffer overflowed.
Jun 3 21:14:07 treogen [ 30.094954] ------------[ cut here ]------------
Jun 3 21:14:07 treogen [ 30.094960] WARNING: at lib/dma-debug.c:256
add_dma_entry+0x7b/0xb0()
Jun 3 21:14:07 treogen [ 30.094964] Hardware name: KFN5-D SLI
Jun 3 21:14:07 treogen [ 30.094966] Modules linked in: msp3400
tuner tea5767 tda8290 tuner_xc2028 xc
5000 tda9887 tuner_simple tuner_types mt20xx tea5761 bttv ir_common
v4l2_common videodev v4l1_compat v4
l2_compat_ioctl32 videobuf_dma_sg videobuf_core sg btcx_risc pata_amd tveeprom
Jun 3 21:14:07 treogen [ 30.094996] Pid: 1156, comm: md3_raid1
Tainted: G W 2.6.30-rc8 #3
Jun 3 21:14:07 treogen [ 30.094999] Call Trace:
Jun 3 21:14:07 treogen [ 30.095005] [<ffffffff8041667b>] ?
add_dma_entry+0x7b/0xb0
Jun 3 21:14:07 treogen [ 30.095012] [<ffffffff802432e8>]
warn_slowpath_common+0x78/0xd0
Jun 3 21:14:07 treogen [ 30.095018] [<ffffffff8024334f>]
warn_slowpath_null+0xf/0x20
Jun 3 21:14:07 treogen [ 30.095025] [<ffffffff8041667b>]
add_dma_entry+0x7b/0xb0
Jun 3 21:14:07 treogen [ 30.095031] [<ffffffff80416db4>]
debug_dma_map_sg+0x144/0x180
Jun 3 21:14:07 treogen [ 30.095038] [<ffffffff804d367c>]
ata_qc_issue+0x19c/0x310
Jun 3 21:14:07 treogen [ 30.095044] [<ffffffff804bfca0>] ?
scsi_done+0x0/0x20
Jun 3 21:14:07 treogen [ 30.095051] [<ffffffff804d92a0>] ?
ata_scsi_rw_xlat+0x0/0x210
Jun 3 21:14:07 treogen [ 30.095058] [<ffffffff804d9558>]
ata_scsi_translate+0xa8/0x180
Jun 3 21:14:07 treogen [ 30.095065] [<ffffffff804bfca0>] ?
scsi_done+0x0/0x20
Jun 3 21:14:07 treogen [ 30.095070] [<ffffffff804dc0f1>]
ata_scsi_queuecmd+0xb1/0x2d0
Jun 3 21:14:07 treogen [ 30.095077] [<ffffffff804bfda3>]
scsi_dispatch_cmd+0xe3/0x220
Jun 3 21:14:07 treogen [ 30.095084] [<ffffffff804c5a0e>]
scsi_request_fn+0x38e/0x480
Jun 3 21:14:07 treogen [ 30.095091] [<ffffffff803f0ae3>]
__generic_unplug_device+0x33/0x40
Jun 3 21:14:07 treogen [ 30.095098] [<ffffffff803f0c09>]
generic_unplug_device+0x29/0x40
Jun 3 21:14:07 treogen [ 30.095105] [<ffffffff803ef92e>]
blk_unplug+0x4e/0x60
Jun 3 21:14:07 treogen [ 30.095111] [<ffffffff80566c7b>]
unplug_slaves+0x9b/0xe0
Jun 3 21:14:07 treogen [ 30.095118] [<ffffffff80569418>] raid1d+0xd68/0x1070
Jun 3 21:14:07 treogen [ 30.095124] [<ffffffff8024dcea>] ?
try_to_del_timer_sync+0x5a/0x70
Jun 3 21:14:07 treogen [ 30.095130] [<ffffffff8024dd1a>] ?
del_timer_sync+0x1a/0x30
Jun 3 21:14:07 treogen [ 30.095138] [<ffffffff805708d4>]
md_thread+0x54/0x140
Jun 3 21:14:07 treogen [ 30.095144] [<ffffffff80259cf0>] ?
autoremove_wake_function+0x0/0x40
Jun 3 21:14:07 treogen [ 30.095151] [<ffffffff80570880>] ?
md_thread+0x0/0x140
Jun 3 21:14:07 treogen [ 30.095158] [<ffffffff80570880>] ?
md_thread+0x0/0x140
Jun 3 21:14:07 treogen [ 30.095164] [<ffffffff80259856>] kthread+0x56/0x90
Jun 3 21:14:07 treogen [ 30.095171] [<ffffffff8020c4aa>] child_rip+0xa/0x20
Jun 3 21:14:07 treogen [ 30.095178] [<ffffffff8020bea9>] ?
restore_args+0x0/0x30
Jun 3 21:14:07 treogen [ 30.095184] [<ffffffff80259800>] ? kthread+0x0/0x90
Jun 3 21:14:07 treogen [ 30.095190] [<ffffffff8020c4a0>] ?
child_rip+0x0/0x20
Jun 3 21:14:07 treogen [ 30.095194] ---[ end trace f87165562db78e9a ]---
Is this a bug in the DMA-API debuging or in libata / sata_sil24?
Torsten
DMA-API-Warning from vanilla 2.6.30-rc8:
Jun 3 18:52:31 treogen [ 486.447661] ------------[ cut here ]------------
Jun 3 18:52:31 treogen [ 486.447684] WARNING: at lib/dma-debug.c:530
check_unmap+0x65e/0x6a0()
Jun 3 18:52:31 treogen [ 486.447689] Hardware name: KFN5-D SLI
Jun 3 18:52:31 treogen [ 486.447694] sata_sil24 0000:04:00.0:
DMA-API: device driver frees DMA sg lis
t with different entry count [map count=1] [unmap count=2]
Jun 3 18:52:31 treogen [ 486.447699] Modules linked in: msp3400
tuner tea5767 tda8290 tuner_xc2028 xc
5000 tda9887 tuner_simple tuner_types mt20xx tea5761 bttv ir_common
v4l2_common videodev v4l1_compat v4
l2_compat_ioctl32 videobuf_dma_sg videobuf_core pata_amd sg btcx_risc tveeprom
Jun 3 18:52:31 treogen [ 486.447740] Pid: 3328, comm: nxproxy Not
tainted 2.6.30-rc8 #1
Jun 3 18:52:31 treogen [ 486.447744] Call Trace:
Jun 3 18:52:31 treogen [ 486.447748] <IRQ> [<ffffffff8041758e>] ?
check_unmap+0x65e/0x6a0
Jun 3 18:52:31 treogen [ 486.447766] [<ffffffff802432e8>]
warn_slowpath_common+0x78/0xd0
Jun 3 18:52:31 treogen [ 486.447773] [<ffffffff802433c4>]
warn_slowpath_fmt+0x64/0x70
Jun 3 18:52:31 treogen [ 486.447783] [<ffffffff804d3665>] ?
ata_qc_issue+0x1e5/0x300
Jun 3 18:52:31 treogen [ 486.447791] [<ffffffff804bfc70>] ?
scsi_done+0x0/0x20
Jun 3 18:52:31 treogen [ 486.447799] [<ffffffff804d9260>] ?
ata_scsi_rw_xlat+0x0/0x210
Jun 3 18:52:31 treogen [ 486.447807] [<ffffffff804d9518>] ?
ata_scsi_translate+0xa8/0x180
Jun 3 18:52:31 treogen [ 486.447817] [<ffffffff8068d33d>] ?
_spin_lock_irqsave+0x1d/0x40
Jun 3 18:52:31 treogen [ 486.447824] [<ffffffff8041758e>]
check_unmap+0x65e/0x6a0
Jun 3 18:52:31 treogen [ 486.447831] [<ffffffff804176de>]
debug_dma_unmap_sg+0x10e/0x1b0
Jun 3 18:52:31 treogen [ 486.447838] [<ffffffff804bff71>] ?
__scsi_put_command+0x61/0xa0
Jun 3 18:52:31 treogen [ 486.447845] [<ffffffff804d30a8>]
ata_sg_clean+0x78/0xf0
Jun 3 18:52:31 treogen [ 486.447852] [<ffffffff804d3155>]
__ata_qc_complete+0x35/0x110
Jun 3 18:52:31 treogen [ 486.447862] [<ffffffff804c69d8>] ?
scsi_io_completion+0x398/0x530
Jun 3 18:52:31 treogen [ 486.447869] [<ffffffff804d32ed>]
ata_qc_complete+0xbd/0x250
Jun 3 18:52:31 treogen [ 486.447876] [<ffffffff804d382b>]
ata_qc_complete_multiple+0xab/0xf0
Jun 3 18:52:31 treogen [ 486.447885] [<ffffffff804e90d9>]
sil24_interrupt+0xb9/0x5b0
Jun 3 18:52:31 treogen [ 486.447894] [<ffffffff80273060>]
handle_IRQ_event+0x70/0x180
Jun 3 18:52:31 treogen [ 486.447902] [<ffffffff8027536d>]
handle_fasteoi_irq+0x6d/0xe0
Jun 3 18:52:31 treogen [ 486.447909] [<ffffffff8020e42f>]
handle_irq+0x1f/0x30
Jun 3 18:52:31 treogen [ 486.447915] [<ffffffff8020db7a>] do_IRQ+0x6a/0xf0
Jun 3 18:52:31 treogen [ 486.447924] [<ffffffff8020be53>]
ret_from_intr+0x0/0xf
Jun 3 18:52:31 treogen [ 486.447927] <EOI> [<ffffffff802c967a>] ?
file_move+0x3a/0x60
Jun 3 18:52:31 treogen [ 486.447939] [<ffffffff802c9668>] ?
file_move+0x28/0x60
Jun 3 18:52:31 treogen [ 486.447949] [<ffffffff802c682f>] ?
__dentry_open+0xbf/0x2e0
Jun 3 18:52:31 treogen [ 486.447957] [<ffffffff802c6b57>] ?
nameidata_to_filp+0x57/0x70
Jun 3 18:52:31 treogen [ 486.447963] [<ffffffff802d51f2>] ?
do_filp_open+0x292/0x990
Jun 3 18:52:31 treogen [ 486.447972] [<ffffffff8064915d>] ?
unix_ioctl+0xad/0xf0
Jun 3 18:52:31 treogen [ 486.447979] [<ffffffff802bde9c>] ?
get_partial_node+0x2c/0xa0
Jun 3 18:52:31 treogen [ 486.447986] [<ffffffff802c1705>] ?
__slab_alloc+0x95/0x480
Jun 3 18:52:31 treogen [ 486.447992] [<ffffffff802d6b91>] ?
vfs_ioctl+0x31/0xa0
Jun 3 18:52:31 treogen [ 486.447999] [<ffffffff8068a817>] ?
thread_return+0x3e/0x6f7
Jun 3 18:52:31 treogen [ 486.448007] [<ffffffff802d25d6>] ?
getname+0x36/0x200
Jun 3 18:52:31 treogen [ 486.448015] [<ffffffff802df56a>] ?
alloc_fd+0x4a/0x140
Jun 3 18:52:31 treogen [ 486.448023] [<ffffffff802c668b>] ?
do_sys_open+0x7b/0x110
Jun 3 18:52:31 treogen [ 486.448030] [<ffffffff802c674b>] ?
sys_open+0x1b/0x20
Jun 3 18:52:31 treogen [ 486.448037] [<ffffffff8020b4eb>] ?
system_call_fastpath+0x16/0x1b
Jun 3 18:52:31 treogen [ 486.448042] ---[ end trace 9e90cc92d8410ab6 ]---
Jun 3 18:52:31 treogen [ 486.448045] Mapped at:
Jun 3 18:52:31 treogen [ 486.448048] [<ffffffffffffffff>] 0xffffffffffffffff
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: sata_sil24 0000:04:00.0: DMA-API: device driver frees DMA sg list with different entry count [map count=13] [unmap count=10]
2009-06-03 19:30 ` Torsten Kaiser
@ 2009-06-03 20:21 ` Kasper Sandberg
2009-06-03 23:33 ` Robert Hancock
2009-06-04 6:00 ` Torsten Kaiser
2009-06-04 0:02 ` FUJITA Tomonori
1 sibling, 2 replies; 15+ messages in thread
From: Kasper Sandberg @ 2009-06-03 20:21 UTC (permalink / raw)
To: Torsten Kaiser
Cc: Robert Hancock, Linux Kernel Mailing List, SCSI development list
On Wed, 2009-06-03 at 21:30 +0200, Torsten Kaiser wrote:
> On Wed, May 27, 2009 at 1:40 AM, Robert Hancock <hancockrwd@gmail.com> wrote:
> > Torsten Kaiser wrote:
> >>
> >> On upgrading to 2.6.30-rc1 I enable the DMA-Debugging option
> >> CONFIG_DMA_API_DEBUG=y
> >> Since then I get the following or similar errors on each boot:
> >
> > Please retest with a newer -rc, this patch likely fixes it:
> >
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5825627c9463581fd9e70f8285685889ae5bb9bb
> >
>
> Still happens with 2.6.30-rc8 (see trace at the end of the email)
>
<snip>
Does this actually give you any problems? should I be scared to give .30
a test?
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: sata_sil24 0000:04:00.0: DMA-API: device driver frees DMA sg list with different entry count [map count=13] [unmap count=10]
2009-06-03 20:21 ` Kasper Sandberg
@ 2009-06-03 23:33 ` Robert Hancock
2009-06-04 6:00 ` Torsten Kaiser
1 sibling, 0 replies; 15+ messages in thread
From: Robert Hancock @ 2009-06-03 23:33 UTC (permalink / raw)
To: Kasper Sandberg
Cc: Torsten Kaiser, Linux Kernel Mailing List, SCSI development list
Kasper Sandberg wrote:
> On Wed, 2009-06-03 at 21:30 +0200, Torsten Kaiser wrote:
>> On Wed, May 27, 2009 at 1:40 AM, Robert Hancock <hancockrwd@gmail.com> wrote:
>>> Torsten Kaiser wrote:
>>>> On upgrading to 2.6.30-rc1 I enable the DMA-Debugging option
>>>> CONFIG_DMA_API_DEBUG=y
>>>> Since then I get the following or similar errors on each boot:
>>> Please retest with a newer -rc, this patch likely fixes it:
>>>
>>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5825627c9463581fd9e70f8285685889ae5bb9bb
>>>
>> Still happens with 2.6.30-rc8 (see trace at the end of the email)
>>
> <snip>
>
> Does this actually give you any problems? should I be scared to give .30
> a test?
If Torsten's diagnosis is correct it's a problem with the DMA debugging
code, not an actual driver bug.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: sata_sil24 0000:04:00.0: DMA-API: device driver frees DMA sg list with different entry count [map count=13] [unmap count=10]
2009-06-03 19:30 ` Torsten Kaiser
2009-06-03 20:21 ` Kasper Sandberg
@ 2009-06-04 0:02 ` FUJITA Tomonori
2009-06-04 6:12 ` Torsten Kaiser
1 sibling, 1 reply; 15+ messages in thread
From: FUJITA Tomonori @ 2009-06-04 0:02 UTC (permalink / raw)
To: just.for.lkml; +Cc: hancockrwd, linux-kernel, linux-scsi
On Wed, 3 Jun 2009 21:30:32 +0200
Torsten Kaiser <just.for.lkml@googlemail.com> wrote:
> On Wed, May 27, 2009 at 1:40 AM, Robert Hancock <hancockrwd@gmail.com> wrote:
> > Torsten Kaiser wrote:
> >>
> >> On upgrading to 2.6.30-rc1 I enable the DMA-Debugging option
> >> CONFIG_DMA_API_DEBUG=y
> >> Since then I get the following or similar errors on each boot:
> >
> > Please retest with a newer -rc, this patch likely fixes it:
> >
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5825627c9463581fd9e70f8285685889ae5bb9bb
> >
>
> Still happens with 2.6.30-rc8 (see trace at the end of the email)
>
> As orig_n_elem is only used two times in libata-core.c I suspected a
> corruption of the qc->sg, but adding checks for this did not trigger.
> So I looked into lib/dma-debug.c.
> It seems add_dma_entry() does not protect against adding the same
> entry twice.
Do you mean that add_dma_entry() doesn't protect against adding a new
entry identical to the existing entry, right? Then it's not a
dma-debug bug (it might be better for dma-debug to check it though),
that is, such situation should not happen. Probably, it's an IOMMU bug
or a driver bug.
> That could explain these warnings, if the hash_bucket
> returns a different entry that then has the wrong map/unmap count.
>
> So I added WARN_ON(hash_bucket_find(bucket, entry)); before the
> hash_bucket_add(bucket, entry); in add_dma_entry();
>
> That WARN_ON() triggered more then 1500 times until the KDE desktop
> was loaded...
btw, does 'iommu=nomerge' kernel boot option fix the problem?
> This is the first full stackdump, I dont have the real first one,
> because the dmesg buffer overflowed.
> Jun 3 21:14:07 treogen [ 30.094954] ------------[ cut here ]------------
> Jun 3 21:14:07 treogen [ 30.094960] WARNING: at lib/dma-debug.c:256
> add_dma_entry+0x7b/0xb0()
> Jun 3 21:14:07 treogen [ 30.094964] Hardware name: KFN5-D SLI
> Jun 3 21:14:07 treogen [ 30.094966] Modules linked in: msp3400
> tuner tea5767 tda8290 tuner_xc2028 xc
> 5000 tda9887 tuner_simple tuner_types mt20xx tea5761 bttv ir_common
> v4l2_common videodev v4l1_compat v4
> l2_compat_ioctl32 videobuf_dma_sg videobuf_core sg btcx_risc pata_amd tveeprom
> Jun 3 21:14:07 treogen [ 30.094996] Pid: 1156, comm: md3_raid1
> Tainted: G W 2.6.30-rc8 #3
> Jun 3 21:14:07 treogen [ 30.094999] Call Trace:
> Jun 3 21:14:07 treogen [ 30.095005] [<ffffffff8041667b>] ?
> add_dma_entry+0x7b/0xb0
> Jun 3 21:14:07 treogen [ 30.095012] [<ffffffff802432e8>]
> warn_slowpath_common+0x78/0xd0
> Jun 3 21:14:07 treogen [ 30.095018] [<ffffffff8024334f>]
> warn_slowpath_null+0xf/0x20
> Jun 3 21:14:07 treogen [ 30.095025] [<ffffffff8041667b>]
> add_dma_entry+0x7b/0xb0
> Jun 3 21:14:07 treogen [ 30.095031] [<ffffffff80416db4>]
> debug_dma_map_sg+0x144/0x180
> Jun 3 21:14:07 treogen [ 30.095038] [<ffffffff804d367c>]
> ata_qc_issue+0x19c/0x310
> Jun 3 21:14:07 treogen [ 30.095044] [<ffffffff804bfca0>] ?
> scsi_done+0x0/0x20
> Jun 3 21:14:07 treogen [ 30.095051] [<ffffffff804d92a0>] ?
> ata_scsi_rw_xlat+0x0/0x210
> Jun 3 21:14:07 treogen [ 30.095058] [<ffffffff804d9558>]
> ata_scsi_translate+0xa8/0x180
> Jun 3 21:14:07 treogen [ 30.095065] [<ffffffff804bfca0>] ?
> scsi_done+0x0/0x20
> Jun 3 21:14:07 treogen [ 30.095070] [<ffffffff804dc0f1>]
> ata_scsi_queuecmd+0xb1/0x2d0
> Jun 3 21:14:07 treogen [ 30.095077] [<ffffffff804bfda3>]
> scsi_dispatch_cmd+0xe3/0x220
> Jun 3 21:14:07 treogen [ 30.095084] [<ffffffff804c5a0e>]
> scsi_request_fn+0x38e/0x480
> Jun 3 21:14:07 treogen [ 30.095091] [<ffffffff803f0ae3>]
> __generic_unplug_device+0x33/0x40
> Jun 3 21:14:07 treogen [ 30.095098] [<ffffffff803f0c09>]
> generic_unplug_device+0x29/0x40
> Jun 3 21:14:07 treogen [ 30.095105] [<ffffffff803ef92e>]
> blk_unplug+0x4e/0x60
> Jun 3 21:14:07 treogen [ 30.095111] [<ffffffff80566c7b>]
> unplug_slaves+0x9b/0xe0
> Jun 3 21:14:07 treogen [ 30.095118] [<ffffffff80569418>] raid1d+0xd68/0x1070
> Jun 3 21:14:07 treogen [ 30.095124] [<ffffffff8024dcea>] ?
> try_to_del_timer_sync+0x5a/0x70
> Jun 3 21:14:07 treogen [ 30.095130] [<ffffffff8024dd1a>] ?
> del_timer_sync+0x1a/0x30
> Jun 3 21:14:07 treogen [ 30.095138] [<ffffffff805708d4>]
> md_thread+0x54/0x140
> Jun 3 21:14:07 treogen [ 30.095144] [<ffffffff80259cf0>] ?
> autoremove_wake_function+0x0/0x40
> Jun 3 21:14:07 treogen [ 30.095151] [<ffffffff80570880>] ?
> md_thread+0x0/0x140
> Jun 3 21:14:07 treogen [ 30.095158] [<ffffffff80570880>] ?
> md_thread+0x0/0x140
> Jun 3 21:14:07 treogen [ 30.095164] [<ffffffff80259856>] kthread+0x56/0x90
> Jun 3 21:14:07 treogen [ 30.095171] [<ffffffff8020c4aa>] child_rip+0xa/0x20
> Jun 3 21:14:07 treogen [ 30.095178] [<ffffffff8020bea9>] ?
> restore_args+0x0/0x30
> Jun 3 21:14:07 treogen [ 30.095184] [<ffffffff80259800>] ? kthread+0x0/0x90
> Jun 3 21:14:07 treogen [ 30.095190] [<ffffffff8020c4a0>] ?
> child_rip+0x0/0x20
> Jun 3 21:14:07 treogen [ 30.095194] ---[ end trace f87165562db78e9a ]---
>
> Is this a bug in the DMA-API debuging or in libata / sata_sil24?
>
> Torsten
>
>
> DMA-API-Warning from vanilla 2.6.30-rc8:
> Jun 3 18:52:31 treogen [ 486.447661] ------------[ cut here ]------------
> Jun 3 18:52:31 treogen [ 486.447684] WARNING: at lib/dma-debug.c:530
> check_unmap+0x65e/0x6a0()
> Jun 3 18:52:31 treogen [ 486.447689] Hardware name: KFN5-D SLI
> Jun 3 18:52:31 treogen [ 486.447694] sata_sil24 0000:04:00.0:
> DMA-API: device driver frees DMA sg lis
> t with different entry count [map count=1] [unmap count=2]
> Jun 3 18:52:31 treogen [ 486.447699] Modules linked in: msp3400
> tuner tea5767 tda8290 tuner_xc2028 xc
> 5000 tda9887 tuner_simple tuner_types mt20xx tea5761 bttv ir_common
> v4l2_common videodev v4l1_compat v4
> l2_compat_ioctl32 videobuf_dma_sg videobuf_core pata_amd sg btcx_risc tveeprom
> Jun 3 18:52:31 treogen [ 486.447740] Pid: 3328, comm: nxproxy Not
> tainted 2.6.30-rc8 #1
> Jun 3 18:52:31 treogen [ 486.447744] Call Trace:
> Jun 3 18:52:31 treogen [ 486.447748] <IRQ> [<ffffffff8041758e>] ?
> check_unmap+0x65e/0x6a0
> Jun 3 18:52:31 treogen [ 486.447766] [<ffffffff802432e8>]
> warn_slowpath_common+0x78/0xd0
> Jun 3 18:52:31 treogen [ 486.447773] [<ffffffff802433c4>]
> warn_slowpath_fmt+0x64/0x70
> Jun 3 18:52:31 treogen [ 486.447783] [<ffffffff804d3665>] ?
> ata_qc_issue+0x1e5/0x300
> Jun 3 18:52:31 treogen [ 486.447791] [<ffffffff804bfc70>] ?
> scsi_done+0x0/0x20
> Jun 3 18:52:31 treogen [ 486.447799] [<ffffffff804d9260>] ?
> ata_scsi_rw_xlat+0x0/0x210
> Jun 3 18:52:31 treogen [ 486.447807] [<ffffffff804d9518>] ?
> ata_scsi_translate+0xa8/0x180
> Jun 3 18:52:31 treogen [ 486.447817] [<ffffffff8068d33d>] ?
> _spin_lock_irqsave+0x1d/0x40
> Jun 3 18:52:31 treogen [ 486.447824] [<ffffffff8041758e>]
> check_unmap+0x65e/0x6a0
> Jun 3 18:52:31 treogen [ 486.447831] [<ffffffff804176de>]
> debug_dma_unmap_sg+0x10e/0x1b0
> Jun 3 18:52:31 treogen [ 486.447838] [<ffffffff804bff71>] ?
> __scsi_put_command+0x61/0xa0
> Jun 3 18:52:31 treogen [ 486.447845] [<ffffffff804d30a8>]
> ata_sg_clean+0x78/0xf0
> Jun 3 18:52:31 treogen [ 486.447852] [<ffffffff804d3155>]
> __ata_qc_complete+0x35/0x110
> Jun 3 18:52:31 treogen [ 486.447862] [<ffffffff804c69d8>] ?
> scsi_io_completion+0x398/0x530
> Jun 3 18:52:31 treogen [ 486.447869] [<ffffffff804d32ed>]
> ata_qc_complete+0xbd/0x250
> Jun 3 18:52:31 treogen [ 486.447876] [<ffffffff804d382b>]
> ata_qc_complete_multiple+0xab/0xf0
> Jun 3 18:52:31 treogen [ 486.447885] [<ffffffff804e90d9>]
> sil24_interrupt+0xb9/0x5b0
> Jun 3 18:52:31 treogen [ 486.447894] [<ffffffff80273060>]
> handle_IRQ_event+0x70/0x180
> Jun 3 18:52:31 treogen [ 486.447902] [<ffffffff8027536d>]
> handle_fasteoi_irq+0x6d/0xe0
> Jun 3 18:52:31 treogen [ 486.447909] [<ffffffff8020e42f>]
> handle_irq+0x1f/0x30
> Jun 3 18:52:31 treogen [ 486.447915] [<ffffffff8020db7a>] do_IRQ+0x6a/0xf0
> Jun 3 18:52:31 treogen [ 486.447924] [<ffffffff8020be53>]
> ret_from_intr+0x0/0xf
> Jun 3 18:52:31 treogen [ 486.447927] <EOI> [<ffffffff802c967a>] ?
> file_move+0x3a/0x60
> Jun 3 18:52:31 treogen [ 486.447939] [<ffffffff802c9668>] ?
> file_move+0x28/0x60
> Jun 3 18:52:31 treogen [ 486.447949] [<ffffffff802c682f>] ?
> __dentry_open+0xbf/0x2e0
> Jun 3 18:52:31 treogen [ 486.447957] [<ffffffff802c6b57>] ?
> nameidata_to_filp+0x57/0x70
> Jun 3 18:52:31 treogen [ 486.447963] [<ffffffff802d51f2>] ?
> do_filp_open+0x292/0x990
> Jun 3 18:52:31 treogen [ 486.447972] [<ffffffff8064915d>] ?
> unix_ioctl+0xad/0xf0
> Jun 3 18:52:31 treogen [ 486.447979] [<ffffffff802bde9c>] ?
> get_partial_node+0x2c/0xa0
> Jun 3 18:52:31 treogen [ 486.447986] [<ffffffff802c1705>] ?
> __slab_alloc+0x95/0x480
> Jun 3 18:52:31 treogen [ 486.447992] [<ffffffff802d6b91>] ?
> vfs_ioctl+0x31/0xa0
> Jun 3 18:52:31 treogen [ 486.447999] [<ffffffff8068a817>] ?
> thread_return+0x3e/0x6f7
> Jun 3 18:52:31 treogen [ 486.448007] [<ffffffff802d25d6>] ?
> getname+0x36/0x200
> Jun 3 18:52:31 treogen [ 486.448015] [<ffffffff802df56a>] ?
> alloc_fd+0x4a/0x140
> Jun 3 18:52:31 treogen [ 486.448023] [<ffffffff802c668b>] ?
> do_sys_open+0x7b/0x110
> Jun 3 18:52:31 treogen [ 486.448030] [<ffffffff802c674b>] ?
> sys_open+0x1b/0x20
> Jun 3 18:52:31 treogen [ 486.448037] [<ffffffff8020b4eb>] ?
> system_call_fastpath+0x16/0x1b
> Jun 3 18:52:31 treogen [ 486.448042] ---[ end trace 9e90cc92d8410ab6 ]---
> Jun 3 18:52:31 treogen [ 486.448045] Mapped at:
> Jun 3 18:52:31 treogen [ 486.448048] [<ffffffffffffffff>] 0xffffffffffffffff
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: sata_sil24 0000:04:00.0: DMA-API: device driver frees DMA sg list with different entry count [map count=13] [unmap count=10]
2009-06-03 20:21 ` Kasper Sandberg
2009-06-03 23:33 ` Robert Hancock
@ 2009-06-04 6:00 ` Torsten Kaiser
1 sibling, 0 replies; 15+ messages in thread
From: Torsten Kaiser @ 2009-06-04 6:00 UTC (permalink / raw)
To: Kasper Sandberg
Cc: Robert Hancock, Linux Kernel Mailing List, SCSI development list
On Wed, Jun 3, 2009 at 10:21 PM, Kasper Sandberg <lkml@metanurb.dk> wrote:
> On Wed, 2009-06-03 at 21:30 +0200, Torsten Kaiser wrote:
>> On Wed, May 27, 2009 at 1:40 AM, Robert Hancock <hancockrwd@gmail.com> wrote:
>> > Torsten Kaiser wrote:
>> >>
>> >> On upgrading to 2.6.30-rc1 I enable the DMA-Debugging option
>> >> CONFIG_DMA_API_DEBUG=y
>> >> Since then I get the following or similar errors on each boot:
>> >
>> > Please retest with a newer -rc, this patch likely fixes it:
>> >
>> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5825627c9463581fd9e70f8285685889ae5bb9bb
>> >
>>
>> Still happens with 2.6.30-rc8 (see trace at the end of the email)
>>
> <snip>
>
> Does this actually give you any problems? should I be scared to give .30
> a test?
No, other then the warning from this debug code I do not have any problems.
As I'm using Gentoo unstable this is triggered most often when I
install an upgrade to some package.
I would expect, if this really would write wrong data to the harddisk,
I would have already destroyed my system.
So while I think there is a problem somewhere that should be fixed,
I'm still using the .30 kernel for my system.
Torsten
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: sata_sil24 0000:04:00.0: DMA-API: device driver frees DMA sg list with different entry count [map count=13] [unmap count=10]
2009-06-04 0:02 ` FUJITA Tomonori
@ 2009-06-04 6:12 ` Torsten Kaiser
2009-06-04 6:33 ` FUJITA Tomonori
0 siblings, 1 reply; 15+ messages in thread
From: Torsten Kaiser @ 2009-06-04 6:12 UTC (permalink / raw)
To: FUJITA Tomonori; +Cc: hancockrwd, linux-kernel, linux-scsi
On Thu, Jun 4, 2009 at 2:02 AM, FUJITA Tomonori
<fujita.tomonori@lab.ntt.co.jp> wrote:
> On Wed, 3 Jun 2009 21:30:32 +0200
> Torsten Kaiser <just.for.lkml@googlemail.com> wrote:
>> Still happens with 2.6.30-rc8 (see trace at the end of the email)
>>
>> As orig_n_elem is only used two times in libata-core.c I suspected a
>> corruption of the qc->sg, but adding checks for this did not trigger.
>> So I looked into lib/dma-debug.c.
>> It seems add_dma_entry() does not protect against adding the same
>> entry twice.
>
> Do you mean that add_dma_entry() doesn't protect against adding a new
> entry identical to the existing entry, right?
Yes, as I read the hash bucket code in lib/dma-debug.c a second entry
from the same device and the same address will just be added to the
list and on unmap it will always return the first entry.
> Then it's not a
> dma-debug bug (it might be better for dma-debug to check it though),
> that is, such situation should not happen.
At least the warning about the wrong unmap count is a bug in the
dma-debug, as that is not what happens on my system.
> Probably, it's an IOMMU bug
> or a driver bug.
Could it be just a forgotten unmap?
That would leave the old entry in the dma-debug list, but from the
driver side it would be valid to map the same place again without
corrupting any data transfer to the harddisk.
What also would point in this direction, sometime I have seen this in my log:
[ 1004.061989] DMA-API: debugging out of memory - disabling
>> That could explain these warnings, if the hash_bucket
>> returns a different entry that then has the wrong map/unmap count.
>>
>> So I added WARN_ON(hash_bucket_find(bucket, entry)); before the
>> hash_bucket_add(bucket, entry); in add_dma_entry();
>>
>> That WARN_ON() triggered more then 1500 times until the KDE desktop
>> was loaded...
>
>
> btw, does 'iommu=nomerge' kernel boot option fix the problem?
No, this WARN_ON() still triggers and I just had another report from
the debugging code:
[ 1205.876238] sata_sil24 0000:04:00.0: DMA-API: device driver frees
DMA sg list with different entry count [map count=13] [unmap count=1]
Does it matter that the system in question is a 2 NUMA node system
(using 2 Opteron CPUs)?
Torsten
>> This is the first full stackdump, I dont have the real first one,
>> because the dmesg buffer overflowed.
>> Jun 3 21:14:07 treogen [ 30.094954] ------------[ cut here ]------------
>> Jun 3 21:14:07 treogen [ 30.094960] WARNING: at lib/dma-debug.c:256
>> add_dma_entry+0x7b/0xb0()
>> Jun 3 21:14:07 treogen [ 30.094964] Hardware name: KFN5-D SLI
>> Jun 3 21:14:07 treogen [ 30.094966] Modules linked in: msp3400
>> tuner tea5767 tda8290 tuner_xc2028 xc
>> 5000 tda9887 tuner_simple tuner_types mt20xx tea5761 bttv ir_common
>> v4l2_common videodev v4l1_compat v4
>> l2_compat_ioctl32 videobuf_dma_sg videobuf_core sg btcx_risc pata_amd tveeprom
>> Jun 3 21:14:07 treogen [ 30.094996] Pid: 1156, comm: md3_raid1
>> Tainted: G W 2.6.30-rc8 #3
>> Jun 3 21:14:07 treogen [ 30.094999] Call Trace:
>> Jun 3 21:14:07 treogen [ 30.095005] [<ffffffff8041667b>] ?
>> add_dma_entry+0x7b/0xb0
>> Jun 3 21:14:07 treogen [ 30.095012] [<ffffffff802432e8>]
>> warn_slowpath_common+0x78/0xd0
>> Jun 3 21:14:07 treogen [ 30.095018] [<ffffffff8024334f>]
>> warn_slowpath_null+0xf/0x20
>> Jun 3 21:14:07 treogen [ 30.095025] [<ffffffff8041667b>]
>> add_dma_entry+0x7b/0xb0
>> Jun 3 21:14:07 treogen [ 30.095031] [<ffffffff80416db4>]
>> debug_dma_map_sg+0x144/0x180
>> Jun 3 21:14:07 treogen [ 30.095038] [<ffffffff804d367c>]
>> ata_qc_issue+0x19c/0x310
>> Jun 3 21:14:07 treogen [ 30.095044] [<ffffffff804bfca0>] ?
>> scsi_done+0x0/0x20
>> Jun 3 21:14:07 treogen [ 30.095051] [<ffffffff804d92a0>] ?
>> ata_scsi_rw_xlat+0x0/0x210
>> Jun 3 21:14:07 treogen [ 30.095058] [<ffffffff804d9558>]
>> ata_scsi_translate+0xa8/0x180
>> Jun 3 21:14:07 treogen [ 30.095065] [<ffffffff804bfca0>] ?
>> scsi_done+0x0/0x20
>> Jun 3 21:14:07 treogen [ 30.095070] [<ffffffff804dc0f1>]
>> ata_scsi_queuecmd+0xb1/0x2d0
>> Jun 3 21:14:07 treogen [ 30.095077] [<ffffffff804bfda3>]
>> scsi_dispatch_cmd+0xe3/0x220
>> Jun 3 21:14:07 treogen [ 30.095084] [<ffffffff804c5a0e>]
>> scsi_request_fn+0x38e/0x480
>> Jun 3 21:14:07 treogen [ 30.095091] [<ffffffff803f0ae3>]
>> __generic_unplug_device+0x33/0x40
>> Jun 3 21:14:07 treogen [ 30.095098] [<ffffffff803f0c09>]
>> generic_unplug_device+0x29/0x40
>> Jun 3 21:14:07 treogen [ 30.095105] [<ffffffff803ef92e>]
>> blk_unplug+0x4e/0x60
>> Jun 3 21:14:07 treogen [ 30.095111] [<ffffffff80566c7b>]
>> unplug_slaves+0x9b/0xe0
>> Jun 3 21:14:07 treogen [ 30.095118] [<ffffffff80569418>] raid1d+0xd68/0x1070
>> Jun 3 21:14:07 treogen [ 30.095124] [<ffffffff8024dcea>] ?
>> try_to_del_timer_sync+0x5a/0x70
>> Jun 3 21:14:07 treogen [ 30.095130] [<ffffffff8024dd1a>] ?
>> del_timer_sync+0x1a/0x30
>> Jun 3 21:14:07 treogen [ 30.095138] [<ffffffff805708d4>]
>> md_thread+0x54/0x140
>> Jun 3 21:14:07 treogen [ 30.095144] [<ffffffff80259cf0>] ?
>> autoremove_wake_function+0x0/0x40
>> Jun 3 21:14:07 treogen [ 30.095151] [<ffffffff80570880>] ?
>> md_thread+0x0/0x140
>> Jun 3 21:14:07 treogen [ 30.095158] [<ffffffff80570880>] ?
>> md_thread+0x0/0x140
>> Jun 3 21:14:07 treogen [ 30.095164] [<ffffffff80259856>] kthread+0x56/0x90
>> Jun 3 21:14:07 treogen [ 30.095171] [<ffffffff8020c4aa>] child_rip+0xa/0x20
>> Jun 3 21:14:07 treogen [ 30.095178] [<ffffffff8020bea9>] ?
>> restore_args+0x0/0x30
>> Jun 3 21:14:07 treogen [ 30.095184] [<ffffffff80259800>] ? kthread+0x0/0x90
>> Jun 3 21:14:07 treogen [ 30.095190] [<ffffffff8020c4a0>] ?
>> child_rip+0x0/0x20
>> Jun 3 21:14:07 treogen [ 30.095194] ---[ end trace f87165562db78e9a ]---
>>
>> Is this a bug in the DMA-API debuging or in libata / sata_sil24?
>>
>> Torsten
>>
>>
>> DMA-API-Warning from vanilla 2.6.30-rc8:
>> Jun 3 18:52:31 treogen [ 486.447661] ------------[ cut here ]------------
>> Jun 3 18:52:31 treogen [ 486.447684] WARNING: at lib/dma-debug.c:530
>> check_unmap+0x65e/0x6a0()
>> Jun 3 18:52:31 treogen [ 486.447689] Hardware name: KFN5-D SLI
>> Jun 3 18:52:31 treogen [ 486.447694] sata_sil24 0000:04:00.0:
>> DMA-API: device driver frees DMA sg lis
>> t with different entry count [map count=1] [unmap count=2]
>> Jun 3 18:52:31 treogen [ 486.447699] Modules linked in: msp3400
>> tuner tea5767 tda8290 tuner_xc2028 xc
>> 5000 tda9887 tuner_simple tuner_types mt20xx tea5761 bttv ir_common
>> v4l2_common videodev v4l1_compat v4
>> l2_compat_ioctl32 videobuf_dma_sg videobuf_core pata_amd sg btcx_risc tveeprom
>> Jun 3 18:52:31 treogen [ 486.447740] Pid: 3328, comm: nxproxy Not
>> tainted 2.6.30-rc8 #1
>> Jun 3 18:52:31 treogen [ 486.447744] Call Trace:
>> Jun 3 18:52:31 treogen [ 486.447748] <IRQ> [<ffffffff8041758e>] ?
>> check_unmap+0x65e/0x6a0
>> Jun 3 18:52:31 treogen [ 486.447766] [<ffffffff802432e8>]
>> warn_slowpath_common+0x78/0xd0
>> Jun 3 18:52:31 treogen [ 486.447773] [<ffffffff802433c4>]
>> warn_slowpath_fmt+0x64/0x70
>> Jun 3 18:52:31 treogen [ 486.447783] [<ffffffff804d3665>] ?
>> ata_qc_issue+0x1e5/0x300
>> Jun 3 18:52:31 treogen [ 486.447791] [<ffffffff804bfc70>] ?
>> scsi_done+0x0/0x20
>> Jun 3 18:52:31 treogen [ 486.447799] [<ffffffff804d9260>] ?
>> ata_scsi_rw_xlat+0x0/0x210
>> Jun 3 18:52:31 treogen [ 486.447807] [<ffffffff804d9518>] ?
>> ata_scsi_translate+0xa8/0x180
>> Jun 3 18:52:31 treogen [ 486.447817] [<ffffffff8068d33d>] ?
>> _spin_lock_irqsave+0x1d/0x40
>> Jun 3 18:52:31 treogen [ 486.447824] [<ffffffff8041758e>]
>> check_unmap+0x65e/0x6a0
>> Jun 3 18:52:31 treogen [ 486.447831] [<ffffffff804176de>]
>> debug_dma_unmap_sg+0x10e/0x1b0
>> Jun 3 18:52:31 treogen [ 486.447838] [<ffffffff804bff71>] ?
>> __scsi_put_command+0x61/0xa0
>> Jun 3 18:52:31 treogen [ 486.447845] [<ffffffff804d30a8>]
>> ata_sg_clean+0x78/0xf0
>> Jun 3 18:52:31 treogen [ 486.447852] [<ffffffff804d3155>]
>> __ata_qc_complete+0x35/0x110
>> Jun 3 18:52:31 treogen [ 486.447862] [<ffffffff804c69d8>] ?
>> scsi_io_completion+0x398/0x530
>> Jun 3 18:52:31 treogen [ 486.447869] [<ffffffff804d32ed>]
>> ata_qc_complete+0xbd/0x250
>> Jun 3 18:52:31 treogen [ 486.447876] [<ffffffff804d382b>]
>> ata_qc_complete_multiple+0xab/0xf0
>> Jun 3 18:52:31 treogen [ 486.447885] [<ffffffff804e90d9>]
>> sil24_interrupt+0xb9/0x5b0
>> Jun 3 18:52:31 treogen [ 486.447894] [<ffffffff80273060>]
>> handle_IRQ_event+0x70/0x180
>> Jun 3 18:52:31 treogen [ 486.447902] [<ffffffff8027536d>]
>> handle_fasteoi_irq+0x6d/0xe0
>> Jun 3 18:52:31 treogen [ 486.447909] [<ffffffff8020e42f>]
>> handle_irq+0x1f/0x30
>> Jun 3 18:52:31 treogen [ 486.447915] [<ffffffff8020db7a>] do_IRQ+0x6a/0xf0
>> Jun 3 18:52:31 treogen [ 486.447924] [<ffffffff8020be53>]
>> ret_from_intr+0x0/0xf
>> Jun 3 18:52:31 treogen [ 486.447927] <EOI> [<ffffffff802c967a>] ?
>> file_move+0x3a/0x60
>> Jun 3 18:52:31 treogen [ 486.447939] [<ffffffff802c9668>] ?
>> file_move+0x28/0x60
>> Jun 3 18:52:31 treogen [ 486.447949] [<ffffffff802c682f>] ?
>> __dentry_open+0xbf/0x2e0
>> Jun 3 18:52:31 treogen [ 486.447957] [<ffffffff802c6b57>] ?
>> nameidata_to_filp+0x57/0x70
>> Jun 3 18:52:31 treogen [ 486.447963] [<ffffffff802d51f2>] ?
>> do_filp_open+0x292/0x990
>> Jun 3 18:52:31 treogen [ 486.447972] [<ffffffff8064915d>] ?
>> unix_ioctl+0xad/0xf0
>> Jun 3 18:52:31 treogen [ 486.447979] [<ffffffff802bde9c>] ?
>> get_partial_node+0x2c/0xa0
>> Jun 3 18:52:31 treogen [ 486.447986] [<ffffffff802c1705>] ?
>> __slab_alloc+0x95/0x480
>> Jun 3 18:52:31 treogen [ 486.447992] [<ffffffff802d6b91>] ?
>> vfs_ioctl+0x31/0xa0
>> Jun 3 18:52:31 treogen [ 486.447999] [<ffffffff8068a817>] ?
>> thread_return+0x3e/0x6f7
>> Jun 3 18:52:31 treogen [ 486.448007] [<ffffffff802d25d6>] ?
>> getname+0x36/0x200
>> Jun 3 18:52:31 treogen [ 486.448015] [<ffffffff802df56a>] ?
>> alloc_fd+0x4a/0x140
>> Jun 3 18:52:31 treogen [ 486.448023] [<ffffffff802c668b>] ?
>> do_sys_open+0x7b/0x110
>> Jun 3 18:52:31 treogen [ 486.448030] [<ffffffff802c674b>] ?
>> sys_open+0x1b/0x20
>> Jun 3 18:52:31 treogen [ 486.448037] [<ffffffff8020b4eb>] ?
>> system_call_fastpath+0x16/0x1b
>> Jun 3 18:52:31 treogen [ 486.448042] ---[ end trace 9e90cc92d8410ab6 ]---
>> Jun 3 18:52:31 treogen [ 486.448045] Mapped at:
>> Jun 3 18:52:31 treogen [ 486.448048] [<ffffffffffffffff>] 0xffffffffffffffff
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: sata_sil24 0000:04:00.0: DMA-API: device driver frees DMA sg list with different entry count [map count=13] [unmap count=10]
2009-06-04 6:12 ` Torsten Kaiser
@ 2009-06-04 6:33 ` FUJITA Tomonori
2009-06-04 7:15 ` Boaz Harrosh
0 siblings, 1 reply; 15+ messages in thread
From: FUJITA Tomonori @ 2009-06-04 6:33 UTC (permalink / raw)
To: just.for.lkml; +Cc: fujita.tomonori, hancockrwd, linux-kernel, linux-scsi
On Thu, 4 Jun 2009 08:12:34 +0200
Torsten Kaiser <just.for.lkml@googlemail.com> wrote:
> On Thu, Jun 4, 2009 at 2:02 AM, FUJITA Tomonori
> <fujita.tomonori@lab.ntt.co.jp> wrote:
> > On Wed, 3 Jun 2009 21:30:32 +0200
> > Torsten Kaiser <just.for.lkml@googlemail.com> wrote:
> >> Still happens with 2.6.30-rc8 (see trace at the end of the email)
> >>
> >> As orig_n_elem is only used two times in libata-core.c I suspected a
> >> corruption of the qc->sg, but adding checks for this did not trigger.
> >> So I looked into lib/dma-debug.c.
> >> It seems add_dma_entry() does not protect against adding the same
> >> entry twice.
> >
> > Do you mean that add_dma_entry() doesn't protect against adding a new
> > entry identical to the existing entry, right?
>
> Yes, as I read the hash bucket code in lib/dma-debug.c a second entry
> from the same device and the same address will just be added to the
> list and on unmap it will always return the first entry.
It means that two different DMA operations will be performed against
the same dma addresss on the same device at the same time. It doesn't
happen unless there is a bug in a driver, an IOMMU or somewhere, as I
wrote in the previous mail.
> > Then it's not a
> > dma-debug bug (it might be better for dma-debug to check it though),
> > that is, such situation should not happen.
>
> At least the warning about the wrong unmap count is a bug in the
> dma-debug, as that is not what happens on my system.
>
> > Probably, it's an IOMMU bug
> > or a driver bug.
>
> Could it be just a forgotten unmap?
> That would leave the old entry in the dma-debug list, but from the
> driver side it would be valid to map the same place again without
> corrupting any data transfer to the harddisk.
Yeah, I thought about this possibility. However, you use GART IOMMU,
right (you can see "PCI-DMA: using GART IOMMU." in a boot message if
so)? If you use GART IOMMU, unmapped addresses are not reused.
> What also would point in this direction, sometime I have seen this in my log:
> [ 1004.061989] DMA-API: debugging out of memory - disabling
Sounds like there is a leak...
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: sata_sil24 0000:04:00.0: DMA-API: device driver frees DMA sg list with different entry count [map count=13] [unmap count=10]
2009-06-04 6:33 ` FUJITA Tomonori
@ 2009-06-04 7:15 ` Boaz Harrosh
2009-06-04 7:44 ` FUJITA Tomonori
0 siblings, 1 reply; 15+ messages in thread
From: Boaz Harrosh @ 2009-06-04 7:15 UTC (permalink / raw)
To: FUJITA Tomonori; +Cc: just.for.lkml, hancockrwd, linux-kernel, linux-scsi
On 06/04/2009 09:33 AM, FUJITA Tomonori wrote:
> On Thu, 4 Jun 2009 08:12:34 +0200
> Torsten Kaiser <just.for.lkml@googlemail.com> wrote:
>
>> On Thu, Jun 4, 2009 at 2:02 AM, FUJITA Tomonori
>> <fujita.tomonori@lab.ntt.co.jp> wrote:
>>> On Wed, 3 Jun 2009 21:30:32 +0200
>>> Torsten Kaiser <just.for.lkml@googlemail.com> wrote:
>>>> Still happens with 2.6.30-rc8 (see trace at the end of the email)
>>>>
>>>> As orig_n_elem is only used two times in libata-core.c I suspected a
>>>> corruption of the qc->sg, but adding checks for this did not trigger.
>>>> So I looked into lib/dma-debug.c.
>>>> It seems add_dma_entry() does not protect against adding the same
>>>> entry twice.
>>> Do you mean that add_dma_entry() doesn't protect against adding a new
>>> entry identical to the existing entry, right?
>> Yes, as I read the hash bucket code in lib/dma-debug.c a second entry
>> from the same device and the same address will just be added to the
>> list and on unmap it will always return the first entry.
>
> It means that two different DMA operations will be performed against
> the same dma addresss on the same device at the same time. It doesn't
> happen unless there is a bug in a driver, an IOMMU or somewhere, as I
> wrote in the previous mail.
>
What about the draining buffers used by libata. Are they not the same buffer
for all devices for all requests?
>
>>> Then it's not a
>>> dma-debug bug (it might be better for dma-debug to check it though),
>>> that is, such situation should not happen.
>> At least the warning about the wrong unmap count is a bug in the
>> dma-debug, as that is not what happens on my system.
>>
>>> Probably, it's an IOMMU bug
>>> or a driver bug.
>> Could it be just a forgotten unmap?
>> That would leave the old entry in the dma-debug list, but from the
>> driver side it would be valid to map the same place again without
>> corrupting any data transfer to the harddisk.
>
> Yeah, I thought about this possibility. However, you use GART IOMMU,
> right (you can see "PCI-DMA: using GART IOMMU." in a boot message if
> so)? If you use GART IOMMU, unmapped addresses are not reused.
>
>
>> What also would point in this direction, sometime I have seen this in my log:
>> [ 1004.061989] DMA-API: debugging out of memory - disabling
>
> Sounds like there is a leak...
Boaz
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: sata_sil24 0000:04:00.0: DMA-API: device driver frees DMA sg list with different entry count [map count=13] [unmap count=10]
2009-06-04 7:15 ` Boaz Harrosh
@ 2009-06-04 7:44 ` FUJITA Tomonori
2009-06-04 7:53 ` Jens Axboe
0 siblings, 1 reply; 15+ messages in thread
From: FUJITA Tomonori @ 2009-06-04 7:44 UTC (permalink / raw)
To: bharrosh
Cc: fujita.tomonori, just.for.lkml, hancockrwd, linux-kernel,
linux-scsi
On Thu, 04 Jun 2009 10:15:14 +0300
Boaz Harrosh <bharrosh@panasas.com> wrote:
> On 06/04/2009 09:33 AM, FUJITA Tomonori wrote:
> > On Thu, 4 Jun 2009 08:12:34 +0200
> > Torsten Kaiser <just.for.lkml@googlemail.com> wrote:
> >
> >> On Thu, Jun 4, 2009 at 2:02 AM, FUJITA Tomonori
> >> <fujita.tomonori@lab.ntt.co.jp> wrote:
> >>> On Wed, 3 Jun 2009 21:30:32 +0200
> >>> Torsten Kaiser <just.for.lkml@googlemail.com> wrote:
> >>>> Still happens with 2.6.30-rc8 (see trace at the end of the email)
> >>>>
> >>>> As orig_n_elem is only used two times in libata-core.c I suspected a
> >>>> corruption of the qc->sg, but adding checks for this did not trigger.
> >>>> So I looked into lib/dma-debug.c.
> >>>> It seems add_dma_entry() does not protect against adding the same
> >>>> entry twice.
> >>> Do you mean that add_dma_entry() doesn't protect against adding a new
> >>> entry identical to the existing entry, right?
> >> Yes, as I read the hash bucket code in lib/dma-debug.c a second entry
> >> from the same device and the same address will just be added to the
> >> list and on unmap it will always return the first entry.
> >
> > It means that two different DMA operations will be performed against
> > the same dma addresss on the same device at the same time. It doesn't
> > happen unless there is a bug in a driver, an IOMMU or somewhere, as I
> > wrote in the previous mail.
> >
>
> What about the draining buffers used by libata. Are they not the same buffer
> for all devices for all requests?
I'm not sure if the drain buffer is used like that. But is there
easier ways to see the same buffer; e.g. sending the same buffer twice
with DIO?
As I wrote, I assume that he uses GART IOMMU; it allocates an unique
dma address per dma mapping operation.
However, dma-debug is broken wrt this, I guess.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: sata_sil24 0000:04:00.0: DMA-API: device driver frees DMA sg list with different entry count [map count=13] [unmap count=10]
2009-06-04 7:44 ` FUJITA Tomonori
@ 2009-06-04 7:53 ` Jens Axboe
2009-06-04 18:07 ` Torsten Kaiser
0 siblings, 1 reply; 15+ messages in thread
From: Jens Axboe @ 2009-06-04 7:53 UTC (permalink / raw)
To: FUJITA Tomonori
Cc: bharrosh, just.for.lkml, hancockrwd, linux-kernel, linux-scsi
On Thu, Jun 04 2009, FUJITA Tomonori wrote:
> On Thu, 04 Jun 2009 10:15:14 +0300
> Boaz Harrosh <bharrosh@panasas.com> wrote:
>
> > On 06/04/2009 09:33 AM, FUJITA Tomonori wrote:
> > > On Thu, 4 Jun 2009 08:12:34 +0200
> > > Torsten Kaiser <just.for.lkml@googlemail.com> wrote:
> > >
> > >> On Thu, Jun 4, 2009 at 2:02 AM, FUJITA Tomonori
> > >> <fujita.tomonori@lab.ntt.co.jp> wrote:
> > >>> On Wed, 3 Jun 2009 21:30:32 +0200
> > >>> Torsten Kaiser <just.for.lkml@googlemail.com> wrote:
> > >>>> Still happens with 2.6.30-rc8 (see trace at the end of the email)
> > >>>>
> > >>>> As orig_n_elem is only used two times in libata-core.c I suspected a
> > >>>> corruption of the qc->sg, but adding checks for this did not trigger.
> > >>>> So I looked into lib/dma-debug.c.
> > >>>> It seems add_dma_entry() does not protect against adding the same
> > >>>> entry twice.
> > >>> Do you mean that add_dma_entry() doesn't protect against adding a new
> > >>> entry identical to the existing entry, right?
> > >> Yes, as I read the hash bucket code in lib/dma-debug.c a second entry
> > >> from the same device and the same address will just be added to the
> > >> list and on unmap it will always return the first entry.
> > >
> > > It means that two different DMA operations will be performed against
> > > the same dma addresss on the same device at the same time. It doesn't
> > > happen unless there is a bug in a driver, an IOMMU or somewhere, as I
> > > wrote in the previous mail.
> > >
> >
> > What about the draining buffers used by libata. Are they not the same buffer
> > for all devices for all requests?
>
> I'm not sure if the drain buffer is used like that. But is there
> easier ways to see the same buffer; e.g. sending the same buffer twice
> with DIO?
I'm pretty sure we discussed this some months ago, the intel iommu
driver had a similar bug iirc. Lets say you want to write the same 4kb
block to two spots on the disk. You prepare and submit that with
O_DIRECT and using aio. On a device with NCQ, that could easily map the
same page twice. Or, perhaps more likely, doing 512b writes and not
getting all of them merged.
> As I wrote, I assume that he uses GART IOMMU; it allocates an unique
> dma address per dma mapping operation.
>
> However, dma-debug is broken wrt this, I guess.
Seems so.
--
Jens Axboe
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: sata_sil24 0000:04:00.0: DMA-API: device driver frees DMA sg list with different entry count [map count=13] [unmap count=10]
2009-06-04 7:53 ` Jens Axboe
@ 2009-06-04 18:07 ` Torsten Kaiser
2009-06-04 22:43 ` FUJITA Tomonori
0 siblings, 1 reply; 15+ messages in thread
From: Torsten Kaiser @ 2009-06-04 18:07 UTC (permalink / raw)
To: Jens Axboe
Cc: FUJITA Tomonori, bharrosh, hancockrwd, linux-kernel, linux-scsi
On Thu, Jun 4, 2009 at 9:53 AM, Jens Axboe <jens.axboe@oracle.com> wrote:
> On Thu, Jun 04 2009, FUJITA Tomonori wrote:
>> On Thu, 04 Jun 2009 10:15:14 +0300
>> Boaz Harrosh <bharrosh@panasas.com> wrote:
>>
>> > On 06/04/2009 09:33 AM, FUJITA Tomonori wrote:
>> > > On Thu, 4 Jun 2009 08:12:34 +0200
>> > > Torsten Kaiser <just.for.lkml@googlemail.com> wrote:
>> > >
>> > >> On Thu, Jun 4, 2009 at 2:02 AM, FUJITA Tomonori
>> > >> <fujita.tomonori@lab.ntt.co.jp> wrote:
>> > >>> On Wed, 3 Jun 2009 21:30:32 +0200
>> > >>> Torsten Kaiser <just.for.lkml@googlemail.com> wrote:
>> > >>>> Still happens with 2.6.30-rc8 (see trace at the end of the email)
>> > >>>>
>> > >>>> As orig_n_elem is only used two times in libata-core.c I suspected a
>> > >>>> corruption of the qc->sg, but adding checks for this did not trigger.
>> > >>>> So I looked into lib/dma-debug.c.
>> > >>>> It seems add_dma_entry() does not protect against adding the same
>> > >>>> entry twice.
>> > >>> Do you mean that add_dma_entry() doesn't protect against adding a new
>> > >>> entry identical to the existing entry, right?
>> > >> Yes, as I read the hash bucket code in lib/dma-debug.c a second entry
>> > >> from the same device and the same address will just be added to the
>> > >> list and on unmap it will always return the first entry.
>> > >
>> > > It means that two different DMA operations will be performed against
>> > > the same dma addresss on the same device at the same time. It doesn't
>> > > happen unless there is a bug in a driver, an IOMMU or somewhere, as I
>> > > wrote in the previous mail.
>> > >
>> >
>> > What about the draining buffers used by libata. Are they not the same buffer
>> > for all devices for all requests?
>>
>> I'm not sure if the drain buffer is used like that. But is there
>> easier ways to see the same buffer; e.g. sending the same buffer twice
>> with DIO?
>
> I'm pretty sure we discussed this some months ago, the intel iommu
> driver had a similar bug iirc. Lets say you want to write the same 4kb
> block to two spots on the disk. You prepare and submit that with
> O_DIRECT and using aio. On a device with NCQ, that could easily map the
> same page twice. Or, perhaps more likely, doing 512b writes and not
> getting all of them merged.
I have a even better theory: RAID1
There are two disk on this sil24 controller that are uses as an RAID1
to form my root partition.
That also fits the pattern of the very large number of duplicate dma
mappings (as each data block needs to be written twice), but that the
DMA-API debug check only triggers during heavier load: Most of the
time both drives are in sync and so the write request should be
idential, so it does not matter which entry gets returned from the
hash bucket.
But when I run 'updatedb' to trigger this error the read request
disturb the pattern and the write requests also become asymetric.
>> As I wrote, I assume that he uses GART IOMMU;
[ 0.010000] Checking aperture...
[ 0.010000] No AGP bridge found
[ 0.010000] Node 0: aperture @ a7f0000000 size 32 MB
[ 0.010000] Aperture beyond 4GB. Ignoring.
[ 0.010000] Your BIOS doesn't leave a aperture memory hole
[ 0.010000] Please enable the IOMMU option in the BIOS setup
(sadly my BIOS does not have such an option...)
[ 0.010000] This costs you 64 MB of RAM
[ 0.010000] Mapping aperture over 65536 KB of RAM @ 20000000
[ 0.010000] Memory: 4057512k/4718592k available (4674k kernel code,
524868k absent, 136212k reserved
, 2520k data, 1172k init)
[snip]
[ 1.304386] DMA-API: preallocated 32768 debug entries
[ 1.309439] DMA-API: debugging enabled by kernel config
[ 1.310123] PCI-DMA: Disabling AGP.
[ 1.313711] PCI-DMA: aperture base @ 20000000 size 65536 KB
[ 1.320002] PCI-DMA: using GART IOMMU.
[ 1.323763] PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture
[ 1.330640] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 31
[ 1.340007] hpet0: 3 comparators, 32-bit 25.000000 MHz counter
>> it allocates an unique
>> dma address per dma mapping operation.
>>
>> However, dma-debug is broken wrt this, I guess.
>
> Seems so.
Yes, as the md code for RAID1 has a very good cause to send the same
memory page twice to this device.
Torsten
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: sata_sil24 0000:04:00.0: DMA-API: device driver frees DMA sg list with different entry count [map count=13] [unmap count=10]
2009-06-04 18:07 ` Torsten Kaiser
@ 2009-06-04 22:43 ` FUJITA Tomonori
0 siblings, 0 replies; 15+ messages in thread
From: FUJITA Tomonori @ 2009-06-04 22:43 UTC (permalink / raw)
To: just.for.lkml
Cc: jens.axboe, fujita.tomonori, bharrosh, hancockrwd, linux-kernel,
linux-scsi
On Thu, 4 Jun 2009 20:07:36 +0200
Torsten Kaiser <just.for.lkml@googlemail.com> wrote:
> On Thu, Jun 4, 2009 at 9:53 AM, Jens Axboe <jens.axboe@oracle.com> wrote:
> > On Thu, Jun 04 2009, FUJITA Tomonori wrote:
> >> On Thu, 04 Jun 2009 10:15:14 +0300
> >> Boaz Harrosh <bharrosh@panasas.com> wrote:
> >>
> >> > On 06/04/2009 09:33 AM, FUJITA Tomonori wrote:
> >> > > On Thu, 4 Jun 2009 08:12:34 +0200
> >> > > Torsten Kaiser <just.for.lkml@googlemail.com> wrote:
> >> > >
> >> > >> On Thu, Jun 4, 2009 at 2:02 AM, FUJITA Tomonori
> >> > >> <fujita.tomonori@lab.ntt.co.jp> wrote:
> >> > >>> On Wed, 3 Jun 2009 21:30:32 +0200
> >> > >>> Torsten Kaiser <just.for.lkml@googlemail.com> wrote:
> >> > >>>> Still happens with 2.6.30-rc8 (see trace at the end of the email)
> >> > >>>>
> >> > >>>> As orig_n_elem is only used two times in libata-core.c I suspected a
> >> > >>>> corruption of the qc->sg, but adding checks for this did not trigger.
> >> > >>>> So I looked into lib/dma-debug.c.
> >> > >>>> It seems add_dma_entry() does not protect against adding the same
> >> > >>>> entry twice.
> >> > >>> Do you mean that add_dma_entry() doesn't protect against adding a new
> >> > >>> entry identical to the existing entry, right?
> >> > >> Yes, as I read the hash bucket code in lib/dma-debug.c a second entry
> >> > >> from the same device and the same address will just be added to the
> >> > >> list and on unmap it will always return the first entry.
> >> > >
> >> > > It means that two different DMA operations will be performed against
> >> > > the same dma addresss on the same device at the same time. It doesn't
> >> > > happen unless there is a bug in a driver, an IOMMU or somewhere, as I
> >> > > wrote in the previous mail.
> >> > >
> >> >
> >> > What about the draining buffers used by libata. Are they not the same buffer
> >> > for all devices for all requests?
> >>
> >> I'm not sure if the drain buffer is used like that. But is there
> >> easier ways to see the same buffer; e.g. sending the same buffer twice
> >> with DIO?
> >
> > I'm pretty sure we discussed this some months ago, the intel iommu
> > driver had a similar bug iirc. Lets say you want to write the same 4kb
> > block to two spots on the disk. You prepare and submit that with
> > O_DIRECT and using aio. On a device with NCQ, that could easily map the
> > same page twice. Or, perhaps more likely, doing 512b writes and not
> > getting all of them merged.
>
> I have a even better theory: RAID1
> There are two disk on this sil24 controller that are uses as an RAID1
> to form my root partition.
>
> That also fits the pattern of the very large number of duplicate dma
> mappings (as each data block needs to be written twice), but that the
> DMA-API debug check only triggers during heavier load: Most of the
> time both drives are in sync and so the write request should be
> idential, so it does not matter which entry gets returned from the
> hash bucket.
> But when I run 'updatedb' to trigger this error the read request
> disturb the pattern and the write requests also become asymetric.
>
> >> As I wrote, I assume that he uses GART IOMMU;
>
> [ 0.010000] Checking aperture...
> [ 0.010000] No AGP bridge found
> [ 0.010000] Node 0: aperture @ a7f0000000 size 32 MB
> [ 0.010000] Aperture beyond 4GB. Ignoring.
> [ 0.010000] Your BIOS doesn't leave a aperture memory hole
> [ 0.010000] Please enable the IOMMU option in the BIOS setup
> (sadly my BIOS does not have such an option...)
> [ 0.010000] This costs you 64 MB of RAM
> [ 0.010000] Mapping aperture over 65536 KB of RAM @ 20000000
> [ 0.010000] Memory: 4057512k/4718592k available (4674k kernel code,
> 524868k absent, 136212k reserved
> , 2520k data, 1172k init)
> [snip]
> [ 1.304386] DMA-API: preallocated 32768 debug entries
> [ 1.309439] DMA-API: debugging enabled by kernel config
> [ 1.310123] PCI-DMA: Disabling AGP.
> [ 1.313711] PCI-DMA: aperture base @ 20000000 size 65536 KB
> [ 1.320002] PCI-DMA: using GART IOMMU.
> [ 1.323763] PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture
> [ 1.330640] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 31
> [ 1.340007] hpet0: 3 comparators, 32-bit 25.000000 MHz counter
You use GART IOMMU. So I thought that you shouldn't hit this problem
because an IOMMU gives an unique dma address per dma mapping... but I
forgot one really important thing about GART, it's not real IOMMU
hardware. It does address remapping only when necessary (an address
can be accessed by a device). It's possible that you see multiple DMA
transfers performed against the same dma address on one device at the
same time.
> >> it allocates an unique
> >> dma address per dma mapping operation.
> >>
> >> However, dma-debug is broken wrt this, I guess.
> >
> > Seems so.
>
> Yes, as the md code for RAID1 has a very good cause to send the same
> memory page twice to this device.
Yeah, now it's clear for me why you hit this bug.
I'm not sure there is any simple way to fix dma-debug wrt this. I
think that it's better to just disable it since 2.6.30 will be
released shortly.
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2009-06-04 22:43 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-05-26 19:14 sata_sil24 0000:04:00.0: DMA-API: device driver frees DMA sg list with different entry count [map count=13] [unmap count=10] Torsten Kaiser
2009-05-26 23:40 ` Robert Hancock
2009-05-27 2:11 ` Torsten Kaiser
2009-06-03 19:30 ` Torsten Kaiser
2009-06-03 20:21 ` Kasper Sandberg
2009-06-03 23:33 ` Robert Hancock
2009-06-04 6:00 ` Torsten Kaiser
2009-06-04 0:02 ` FUJITA Tomonori
2009-06-04 6:12 ` Torsten Kaiser
2009-06-04 6:33 ` FUJITA Tomonori
2009-06-04 7:15 ` Boaz Harrosh
2009-06-04 7:44 ` FUJITA Tomonori
2009-06-04 7:53 ` Jens Axboe
2009-06-04 18:07 ` Torsten Kaiser
2009-06-04 22:43 ` FUJITA Tomonori
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox