sata_nv frees DMA memory with different size (possibly a generic libata bug)

sata_nv frees DMA memory with different size (possibly a generic libata bug)

[Chuck Ebbert]

Fedora rawhide has the DMA API debug patch applied and it has found this...

>From https://bugzilla.redhat.com/show_bug.cgi?id=485172

WARNING: at lib/dma-debug.c:439 check_unmap+0x16a/0x3dd() (Tainted: G        W
)
Hardware name: System Product Name
sata_nv 0000:00:0d.0: DMA-API: device driver frees DMA memory with different
size [device address=0x00000000da031000] [map size=4096 bytes] [unmap
size=8192bytes]
Modules linked in: bridge stp llc bnep sco l2cap bluetooth sunrpc ip6t_REJECT
nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 cpufreq_ondemand
powernow_k8freq_table dm_multipath uinput snd_hda_codec_analog snd_hda_intel
snd_hda_codec snd_hwdep snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq
snd_seq_device snd_pcm_oss ppdev snd_mixer_oss snd_pcm snd_timer firewire_ohci
snd firewire_core soundcore aic7xxx snd_page_alloc jedec_probe crc_itu_t
forcedeth scsi_transport_spi pcspkr cfi_probe gen_probe sata_sil24 parport_pc
cfi_util parport mtd chipreg i2c_nforce2 map_funcs asus_atk0110 pata_amd
i2c_core hwmon ata_generic pata_acpi sata_nv raid456 async_xor async_memcpy
async_tx xor raid1 sha256_generic cbc aes_x86_64 aes_generic dm_crypt ext4 jbd2
crc16 [last unloaded: scsi_wait_scan]
Pid: 0, comm: swapper Tainted: G        W  2.6.29-0.99.rc4.git1.fc11.x86_64 #1
Call Trace:
<IRQ>  [<ffffffff81048822>] warn_slowpath+0xb7/0xe7
[<ffffffff8137bc4f>] ? _spin_lock_irqsave+0x78/0x86
[<ffffffff8119851b>] ? get_hash_bucket+0x28/0x34
[<ffffffff8106a5ae>] ? trace_hardirqs_off_caller+0x1f/0xac
[<ffffffff81198a15>] check_unmap+0x16a/0x3dd
[<ffffffff810388a7>] ? resched_task+0x2e/0x74
[<ffffffff81198d66>] debug_dma_unmap_sg+0x7c/0x9b
[<ffffffff8106a648>] ? trace_hardirqs_off+0xd/0xf
[<ffffffff8124fef9>] ata_sg_clean+0x96/0xd0
[<ffffffff8124ff89>] __ata_qc_complete+0x56/0xc9
[<ffffffff8125018b>] ata_qc_complete+0x18f/0x198
[<ffffffffa00cb249>] nv_swncq_interrupt+0x358/0x688 [sata_nv]
[<ffffffff8137b8fe>] ? _spin_unlock_irqrestore+0x3c/0x53
[<ffffffff8106a5ae>] ? trace_hardirqs_off_caller+0x1f/0xac
[<ffffffff81016d7d>] ? read_tsc+0x9/0x1a
[<ffffffff81063eb1>] ? getnstimeofday+0x5a/0xae
[<ffffffff81093288>] handle_IRQ_event+0x22/0x5e
[<ffffffff81094ba0>] handle_fasteoi_irq+0x8b/0xd7
[<ffffffff81013a55>] do_IRQ+0xd4/0x14b
[<ffffffff81011d93>] ret_from_intr+0x0/0x2e
<EOI>  [<ffffffff810179fe>] ? default_idle+0x47/0x77
[<ffffffff8106b61f>] ? trace_hardirqs_on+0xd/0xf
[<ffffffff81029282>] ? native_safe_halt+0x6/0x8
[<ffffffff8106b61f>] ? trace_hardirqs_on+0xd/0xf
[<ffffffff81017a03>] ? default_idle+0x4c/0x77
[<ffffffff810666fb>] ? clockevents_notify+0x5d/0x62
[<ffffffff81017b2d>] ? c1e_idle+0xf1/0x126
[<ffffffff81010220>] ? cpu_idle+0x63/0xae
[<ffffffff813754d1>] ? start_secondary+0x199/0x19e

Re: sata_nv frees DMA memory with different size (possibly a generic libata bug)

[Robert Hancock]

Chuck Ebbert wrote:
> Fedora rawhide has the DMA API debug patch applied and it has found this...
> 
> From https://bugzilla.redhat.com/show_bug.cgi?id=485172
> 
> WARNING: at lib/dma-debug.c:439 check_unmap+0x16a/0x3dd() (Tainted: G        W
> )
> Hardware name: System Product Name
> sata_nv 0000:00:0d.0: DMA-API: device driver frees DMA memory with different
> size [device address=0x00000000da031000] [map size=4096 bytes] [unmap
> size=8192bytes]
> Modules linked in: bridge stp llc bnep sco l2cap bluetooth sunrpc ip6t_REJECT
> nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 cpufreq_ondemand
> powernow_k8freq_table dm_multipath uinput snd_hda_codec_analog snd_hda_intel
> snd_hda_codec snd_hwdep snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq
> snd_seq_device snd_pcm_oss ppdev snd_mixer_oss snd_pcm snd_timer firewire_ohci
> snd firewire_core soundcore aic7xxx snd_page_alloc jedec_probe crc_itu_t
> forcedeth scsi_transport_spi pcspkr cfi_probe gen_probe sata_sil24 parport_pc
> cfi_util parport mtd chipreg i2c_nforce2 map_funcs asus_atk0110 pata_amd
> i2c_core hwmon ata_generic pata_acpi sata_nv raid456 async_xor async_memcpy
> async_tx xor raid1 sha256_generic cbc aes_x86_64 aes_generic dm_crypt ext4 jbd2
> crc16 [last unloaded: scsi_wait_scan]
> Pid: 0, comm: swapper Tainted: G        W  2.6.29-0.99.rc4.git1.fc11.x86_64 #1
> Call Trace:
> <IRQ>  [<ffffffff81048822>] warn_slowpath+0xb7/0xe7
> [<ffffffff8137bc4f>] ? _spin_lock_irqsave+0x78/0x86
> [<ffffffff8119851b>] ? get_hash_bucket+0x28/0x34
> [<ffffffff8106a5ae>] ? trace_hardirqs_off_caller+0x1f/0xac
> [<ffffffff81198a15>] check_unmap+0x16a/0x3dd
> [<ffffffff810388a7>] ? resched_task+0x2e/0x74
> [<ffffffff81198d66>] debug_dma_unmap_sg+0x7c/0x9b
> [<ffffffff8106a648>] ? trace_hardirqs_off+0xd/0xf
> [<ffffffff8124fef9>] ata_sg_clean+0x96/0xd0
> [<ffffffff8124ff89>] __ata_qc_complete+0x56/0xc9
> [<ffffffff8125018b>] ata_qc_complete+0x18f/0x198
> [<ffffffffa00cb249>] nv_swncq_interrupt+0x358/0x688 [sata_nv]

That's rather curious. It seems to be saying that the sg length is 
different between the map and unmap, but it doesn't look like sata_nv 
mucks with that anywhere, and neither does libata core..

Re: sata_nv frees DMA memory with different size (possibly a generic libata bug)

[Chuck Ebbert]

On Thu, 12 Feb 2009 21:03:38 -0600
Robert Hancock <hancockrwd@gmail.com> wrote:

> Chuck Ebbert wrote:
> > Fedora rawhide has the DMA API debug patch applied and it has found this...
> > 
> > From https://bugzilla.redhat.com/show_bug.cgi?id=485172
> > 
> > WARNING: at lib/dma-debug.c:439 check_unmap+0x16a/0x3dd() (Tainted: G        W
> > )
> > Hardware name: System Product Name
> > sata_nv 0000:00:0d.0: DMA-API: device driver frees DMA memory with different
> > size [device address=0x00000000da031000] [map size=4096 bytes] [unmap
> > size=8192bytes]
> > Modules linked in: bridge stp llc bnep sco l2cap bluetooth sunrpc ip6t_REJECT
> > nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 cpufreq_ondemand
> > powernow_k8freq_table dm_multipath uinput snd_hda_codec_analog snd_hda_intel
> > snd_hda_codec snd_hwdep snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq
> > snd_seq_device snd_pcm_oss ppdev snd_mixer_oss snd_pcm snd_timer firewire_ohci
> > snd firewire_core soundcore aic7xxx snd_page_alloc jedec_probe crc_itu_t
> > forcedeth scsi_transport_spi pcspkr cfi_probe gen_probe sata_sil24 parport_pc
> > cfi_util parport mtd chipreg i2c_nforce2 map_funcs asus_atk0110 pata_amd
> > i2c_core hwmon ata_generic pata_acpi sata_nv raid456 async_xor async_memcpy
> > async_tx xor raid1 sha256_generic cbc aes_x86_64 aes_generic dm_crypt ext4 jbd2
> > crc16 [last unloaded: scsi_wait_scan]
> > Pid: 0, comm: swapper Tainted: G        W  2.6.29-0.99.rc4.git1.fc11.x86_64 #1
> > Call Trace:
> > <IRQ>  [<ffffffff81048822>] warn_slowpath+0xb7/0xe7
> > [<ffffffff8137bc4f>] ? _spin_lock_irqsave+0x78/0x86
> > [<ffffffff8119851b>] ? get_hash_bucket+0x28/0x34
> > [<ffffffff8106a5ae>] ? trace_hardirqs_off_caller+0x1f/0xac
> > [<ffffffff81198a15>] check_unmap+0x16a/0x3dd
> > [<ffffffff810388a7>] ? resched_task+0x2e/0x74
> > [<ffffffff81198d66>] debug_dma_unmap_sg+0x7c/0x9b
> > [<ffffffff8106a648>] ? trace_hardirqs_off+0xd/0xf
> > [<ffffffff8124fef9>] ata_sg_clean+0x96/0xd0
> > [<ffffffff8124ff89>] __ata_qc_complete+0x56/0xc9
> > [<ffffffff8125018b>] ata_qc_complete+0x18f/0x198
> > [<ffffffffa00cb249>] nv_swncq_interrupt+0x358/0x688 [sata_nv]
> 
> That's rather curious. It seems to be saying that the sg length is 
> different between the map and unmap, but it doesn't look like sata_nv 
> mucks with that anywhere, and neither does libata core..

Could the SCSI code have merged two requests?

Re: sata_nv frees DMA memory with different size (possibly a generic libata bug)

[Robert Hancock]

Chuck Ebbert wrote:
> On Thu, 12 Feb 2009 21:03:38 -0600
> Robert Hancock <hancockrwd@gmail.com> wrote:
> 
>> Chuck Ebbert wrote:
>>> Fedora rawhide has the DMA API debug patch applied and it has found this...
>>>
>>> From https://bugzilla.redhat.com/show_bug.cgi?id=485172
>>>
>>> WARNING: at lib/dma-debug.c:439 check_unmap+0x16a/0x3dd() (Tainted: G        W
>>> )
>>> Hardware name: System Product Name
>>> sata_nv 0000:00:0d.0: DMA-API: device driver frees DMA memory with different
>>> size [device address=0x00000000da031000] [map size=4096 bytes] [unmap
>>> size=8192bytes]
>>> Modules linked in: bridge stp llc bnep sco l2cap bluetooth sunrpc ip6t_REJECT
>>> nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 cpufreq_ondemand
>>> powernow_k8freq_table dm_multipath uinput snd_hda_codec_analog snd_hda_intel
>>> snd_hda_codec snd_hwdep snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq
>>> snd_seq_device snd_pcm_oss ppdev snd_mixer_oss snd_pcm snd_timer firewire_ohci
>>> snd firewire_core soundcore aic7xxx snd_page_alloc jedec_probe crc_itu_t
>>> forcedeth scsi_transport_spi pcspkr cfi_probe gen_probe sata_sil24 parport_pc
>>> cfi_util parport mtd chipreg i2c_nforce2 map_funcs asus_atk0110 pata_amd
>>> i2c_core hwmon ata_generic pata_acpi sata_nv raid456 async_xor async_memcpy
>>> async_tx xor raid1 sha256_generic cbc aes_x86_64 aes_generic dm_crypt ext4 jbd2
>>> crc16 [last unloaded: scsi_wait_scan]
>>> Pid: 0, comm: swapper Tainted: G        W  2.6.29-0.99.rc4.git1.fc11.x86_64 #1
>>> Call Trace:
>>> <IRQ>  [<ffffffff81048822>] warn_slowpath+0xb7/0xe7
>>> [<ffffffff8137bc4f>] ? _spin_lock_irqsave+0x78/0x86
>>> [<ffffffff8119851b>] ? get_hash_bucket+0x28/0x34
>>> [<ffffffff8106a5ae>] ? trace_hardirqs_off_caller+0x1f/0xac
>>> [<ffffffff81198a15>] check_unmap+0x16a/0x3dd
>>> [<ffffffff810388a7>] ? resched_task+0x2e/0x74
>>> [<ffffffff81198d66>] debug_dma_unmap_sg+0x7c/0x9b
>>> [<ffffffff8106a648>] ? trace_hardirqs_off+0xd/0xf
>>> [<ffffffff8124fef9>] ata_sg_clean+0x96/0xd0
>>> [<ffffffff8124ff89>] __ata_qc_complete+0x56/0xc9
>>> [<ffffffff8125018b>] ata_qc_complete+0x18f/0x198
>>> [<ffffffffa00cb249>] nv_swncq_interrupt+0x358/0x688 [sata_nv]
>> That's rather curious. It seems to be saying that the sg length is 
>> different between the map and unmap, but it doesn't look like sata_nv 
>> mucks with that anywhere, and neither does libata core..
> 
> Could the SCSI code have merged two requests?

I wouldn't think so.. and if it did it seems like it would have to have 
changed the list after libata got the request somehow..

Re: sata_nv frees DMA memory with different size (possibly a generic libata bug)

[FUJITA Tomonori]

On Mon, 16 Feb 2009 20:53:43 -0600
Robert Hancock <hancockrwd@gmail.com> wrote:

> Chuck Ebbert wrote:
> > On Thu, 12 Feb 2009 21:03:38 -0600
> > Robert Hancock <hancockrwd@gmail.com> wrote:
> > 
> >> Chuck Ebbert wrote:
> >>> Fedora rawhide has the DMA API debug patch applied and it has found this...
> >>>
> >>> From https://bugzilla.redhat.com/show_bug.cgi?id=485172
> >>>
> >>> WARNING: at lib/dma-debug.c:439 check_unmap+0x16a/0x3dd() (Tainted: G        W
> >>> )
> >>> Hardware name: System Product Name
> >>> sata_nv 0000:00:0d.0: DMA-API: device driver frees DMA memory with different
> >>> size [device address=0x00000000da031000] [map size=4096 bytes] [unmap
> >>> size=8192bytes]
> >>> Modules linked in: bridge stp llc bnep sco l2cap bluetooth sunrpc ip6t_REJECT
> >>> nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 cpufreq_ondemand
> >>> powernow_k8freq_table dm_multipath uinput snd_hda_codec_analog snd_hda_intel
> >>> snd_hda_codec snd_hwdep snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq
> >>> snd_seq_device snd_pcm_oss ppdev snd_mixer_oss snd_pcm snd_timer firewire_ohci
> >>> snd firewire_core soundcore aic7xxx snd_page_alloc jedec_probe crc_itu_t
> >>> forcedeth scsi_transport_spi pcspkr cfi_probe gen_probe sata_sil24 parport_pc
> >>> cfi_util parport mtd chipreg i2c_nforce2 map_funcs asus_atk0110 pata_amd
> >>> i2c_core hwmon ata_generic pata_acpi sata_nv raid456 async_xor async_memcpy
> >>> async_tx xor raid1 sha256_generic cbc aes_x86_64 aes_generic dm_crypt ext4 jbd2
> >>> crc16 [last unloaded: scsi_wait_scan]
> >>> Pid: 0, comm: swapper Tainted: G        W  2.6.29-0.99.rc4.git1.fc11.x86_64 #1
> >>> Call Trace:
> >>> <IRQ>  [<ffffffff81048822>] warn_slowpath+0xb7/0xe7
> >>> [<ffffffff8137bc4f>] ? _spin_lock_irqsave+0x78/0x86
> >>> [<ffffffff8119851b>] ? get_hash_bucket+0x28/0x34
> >>> [<ffffffff8106a5ae>] ? trace_hardirqs_off_caller+0x1f/0xac
> >>> [<ffffffff81198a15>] check_unmap+0x16a/0x3dd
> >>> [<ffffffff810388a7>] ? resched_task+0x2e/0x74
> >>> [<ffffffff81198d66>] debug_dma_unmap_sg+0x7c/0x9b
> >>> [<ffffffff8106a648>] ? trace_hardirqs_off+0xd/0xf
> >>> [<ffffffff8124fef9>] ata_sg_clean+0x96/0xd0
> >>> [<ffffffff8124ff89>] __ata_qc_complete+0x56/0xc9
> >>> [<ffffffff8125018b>] ata_qc_complete+0x18f/0x198
> >>> [<ffffffffa00cb249>] nv_swncq_interrupt+0x358/0x688 [sata_nv]
> >> That's rather curious. It seems to be saying that the sg length is 
> >> different between the map and unmap, but it doesn't look like sata_nv 
> >> mucks with that anywhere, and neither does libata core..
> > 
> > Could the SCSI code have merged two requests?
> 
> I wouldn't think so.. and if it did it seems like it would have to have 
> changed the list after libata got the request somehow..

Does this box uses GART IOMMU?

Re: sata_nv frees DMA memory with different size (possibly a generic libata bug)

[Chuck Ebbert]

On Tue, 17 Feb 2009 20:22:05 +0900
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:

 
> > >>> sata_nv 0000:00:0d.0: DMA-API: device driver frees DMA memory with different
> > >>> size [device address=0x00000000da031000] [map size=4096 bytes] [unmap
> > >> That's rather curious. It seems to be saying that the sg length is 
> > >> different between the map and unmap, but it doesn't look like sata_nv 
> > >> mucks with that anywhere, and neither does libata core..
> > > 
> > > Could the SCSI code have merged two requests?
> > 
> > I wouldn't think so.. and if it did it seems like it would have to have 
> > changed the list after libata got the request somehow..
> 
> Does this box uses GART IOMMU?

I don't think so, but I've asked for the dmesg.

It's using an nVidia MCP55/C51 chipset if that's any help.

Re: sata_nv frees DMA memory with different size (possibly a generic libata bug)

[Chuck Ebbert]

On Wed, 18 Feb 2009 15:25:16 -0500
Chuck Ebbert <cebbert@redhat.com> wrote:

> On Tue, 17 Feb 2009 20:22:05 +0900
> FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:
> 
>  
> > > >>> sata_nv 0000:00:0d.0: DMA-API: device driver frees DMA memory with different
> > > >>> size [device address=0x00000000da031000] [map size=4096 bytes] [unmap
> > > >> That's rather curious. It seems to be saying that the sg length is 
> > > >> different between the map and unmap, but it doesn't look like sata_nv 
> > > >> mucks with that anywhere, and neither does libata core..
> > > > 
> > > > Could the SCSI code have merged two requests?
> > > 
> > > I wouldn't think so.. and if it did it seems like it would have to have 
> > > changed the list after libata got the request somehow..
> > 
> > Does this box uses GART IOMMU?
> 
> I don't think so, but I've asked for the dmesg.

Okay, it _is_ using GART IOMMU:

DMA-API: preallocated 8192 debug entries
DMA-API: debugging enabled by kernel config
PCI-DMA: Disabling AGP.
PCI-DMA: aperture base @ 20000000 size 65536 KB
PCI-DMA: using GART IOMMU.
PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture

Re: sata_nv frees DMA memory with different size (possibly a generic libata bug)

[FUJITA Tomonori]

On Wed, 18 Feb 2009 17:05:44 -0500
Chuck Ebbert <cebbert@redhat.com> wrote:

> On Wed, 18 Feb 2009 15:25:16 -0500
> Chuck Ebbert <cebbert@redhat.com> wrote:
> 
> > On Tue, 17 Feb 2009 20:22:05 +0900
> > FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:
> > 
> >  
> > > > >>> sata_nv 0000:00:0d.0: DMA-API: device driver frees DMA memory with different
> > > > >>> size [device address=0x00000000da031000] [map size=4096 bytes] [unmap
> > > > >> That's rather curious. It seems to be saying that the sg length is 
> > > > >> different between the map and unmap, but it doesn't look like sata_nv 
> > > > >> mucks with that anywhere, and neither does libata core..
> > > > > 
> > > > > Could the SCSI code have merged two requests?
> > > > 
> > > > I wouldn't think so.. and if it did it seems like it would have to have 
> > > > changed the list after libata got the request somehow..
> > > 
> > > Does this box uses GART IOMMU?
> > 
> > I don't think so, but I've asked for the dmesg.
> 
> Okay, it _is_ using GART IOMMU:
> 
> DMA-API: preallocated 8192 debug entries
> DMA-API: debugging enabled by kernel config
> PCI-DMA: Disabling AGP.
> PCI-DMA: aperture base @ 20000000 size 65536 KB
> PCI-DMA: using GART IOMMU.
> PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture

Thanks, that makes sense.

I think that the following patch could fix this:

http://marc.info/?l=linux-ide&m=123484533504307&w=2

Re: sata_nv frees DMA memory with different size (possibly a generic libata bug)

[Robert Hancock]

FUJITA Tomonori wrote:
> On Wed, 18 Feb 2009 17:05:44 -0500
> Chuck Ebbert <cebbert@redhat.com> wrote:
> 
>> On Wed, 18 Feb 2009 15:25:16 -0500
>> Chuck Ebbert <cebbert@redhat.com> wrote:
>>
>>> On Tue, 17 Feb 2009 20:22:05 +0900
>>> FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:
>>>
>>>  
>>>>>>>> sata_nv 0000:00:0d.0: DMA-API: device driver frees DMA memory with different
>>>>>>>> size [device address=0x00000000da031000] [map size=4096 bytes] [unmap
>>>>>>> That's rather curious. It seems to be saying that the sg length is 
>>>>>>> different between the map and unmap, but it doesn't look like sata_nv 
>>>>>>> mucks with that anywhere, and neither does libata core..
>>>>>> Could the SCSI code have merged two requests?
>>>>> I wouldn't think so.. and if it did it seems like it would have to have 
>>>>> changed the list after libata got the request somehow..
>>>> Does this box uses GART IOMMU?
>>> I don't think so, but I've asked for the dmesg.
>> Okay, it _is_ using GART IOMMU:
>>
>> DMA-API: preallocated 8192 debug entries
>> DMA-API: debugging enabled by kernel config
>> PCI-DMA: Disabling AGP.
>> PCI-DMA: aperture base @ 20000000 size 65536 KB
>> PCI-DMA: using GART IOMMU.
>> PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture
> 
> Thanks, that makes sense.
> 
> I think that the following patch could fix this:
> 
> http://marc.info/?l=linux-ide&m=123484533504307&w=2

The patch looks reasonable to me. I'm CCing the reporter of the bug. 
Wes, would you be able to test out Fujita's patch linked above?

Re: sata_nv frees DMA memory with different size (possibly a generic libata bug)

[Wes Shull]

On Thu, Feb 19, 2009 at 7:58 PM, Robert Hancock <hancockrwd@gmail.com> wrote:
> FUJITA Tomonori wrote:
>>
>> On Wed, 18 Feb 2009 17:05:44 -0500
>> Chuck Ebbert <cebbert@redhat.com> wrote:
>>
>>> On Wed, 18 Feb 2009 15:25:16 -0500
>>> Chuck Ebbert <cebbert@redhat.com> wrote:
>>>
>>>> On Tue, 17 Feb 2009 20:22:05 +0900
>>>> FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:
>>>>
>>>>
>>>>>>>>>
>>>>>>>>> sata_nv 0000:00:0d.0: DMA-API: device driver frees DMA memory with
>>>>>>>>> different
>>>>>>>>> size [device address=0x00000000da031000] [map size=4096 bytes]
>>>>>>>>> [unmap
>>>>>>>>
>>>>>>>> That's rather curious. It seems to be saying that the sg length is
>>>>>>>> different between the map and unmap, but it doesn't look like sata_nv mucks
>>>>>>>> with that anywhere, and neither does libata core..
>>>>>>>
>>>>>>> Could the SCSI code have merged two requests?
>>>>>>
>>>>>> I wouldn't think so.. and if it did it seems like it would have to
>>>>>> have changed the list after libata got the request somehow..
>>>>>
>>>>> Does this box uses GART IOMMU?
>>>>
>>>> I don't think so, but I've asked for the dmesg.
>>>
>>> Okay, it _is_ using GART IOMMU:
>>>
>>> DMA-API: preallocated 8192 debug entries
>>> DMA-API: debugging enabled by kernel config
>>> PCI-DMA: Disabling AGP.
>>> PCI-DMA: aperture base @ 20000000 size 65536 KB
>>> PCI-DMA: using GART IOMMU.
>>> PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture
>>
>> Thanks, that makes sense.
>>
>> I think that the following patch could fix this:
>>
>> http://marc.info/?l=linux-ide&m=123484533504307&w=2
>
> The patch looks reasonable to me. I'm CCing the reporter of the bug. Wes,
> would you be able to test out Fujita's patch linked above?

I grabbed the srpm for the fedoraized 2.6.29-0.137.rc5.git4 from koji,
applied the patch, and tested--no joy, I'm still getting the warning.
Would there be any value to me trying this with a vanilla+dma-debug
kernel build?

Tomorrow I'm going to bump up the show_num_errors (currently at 1) in
the dma debug patch to see if maybe that produces anything else
interesting; I've already got another bug that races with nv_sata to
get that first warning (in forcedeth, so you probably don't care, but
if so see https://bugzilla.redhat.com/show_bug.cgi?id=484494 ).

Re: sata_nv frees DMA memory with different size (possibly a generic libata bug)

[FUJITA Tomonori]

On Fri, 20 Feb 2009 04:20:29 -0700
Wes Shull <wes.shull@gmail.com> wrote:

> On Thu, Feb 19, 2009 at 7:58 PM, Robert Hancock <hancockrwd@gmail.com> wrote:
> > FUJITA Tomonori wrote:
> >>
> >> On Wed, 18 Feb 2009 17:05:44 -0500
> >> Chuck Ebbert <cebbert@redhat.com> wrote:
> >>
> >>> On Wed, 18 Feb 2009 15:25:16 -0500
> >>> Chuck Ebbert <cebbert@redhat.com> wrote:
> >>>
> >>>> On Tue, 17 Feb 2009 20:22:05 +0900
> >>>> FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:
> >>>>
> >>>>
> >>>>>>>>>
> >>>>>>>>> sata_nv 0000:00:0d.0: DMA-API: device driver frees DMA memory with
> >>>>>>>>> different
> >>>>>>>>> size [device address=0x00000000da031000] [map size=4096 bytes]
> >>>>>>>>> [unmap
> >>>>>>>>
> >>>>>>>> That's rather curious. It seems to be saying that the sg length is
> >>>>>>>> different between the map and unmap, but it doesn't look like sata_nv mucks
> >>>>>>>> with that anywhere, and neither does libata core..
> >>>>>>>
> >>>>>>> Could the SCSI code have merged two requests?
> >>>>>>
> >>>>>> I wouldn't think so.. and if it did it seems like it would have to
> >>>>>> have changed the list after libata got the request somehow..
> >>>>>
> >>>>> Does this box uses GART IOMMU?
> >>>>
> >>>> I don't think so, but I've asked for the dmesg.
> >>>
> >>> Okay, it _is_ using GART IOMMU:
> >>>
> >>> DMA-API: preallocated 8192 debug entries
> >>> DMA-API: debugging enabled by kernel config
> >>> PCI-DMA: Disabling AGP.
> >>> PCI-DMA: aperture base @ 20000000 size 65536 KB
> >>> PCI-DMA: using GART IOMMU.
> >>> PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture
> >>
> >> Thanks, that makes sense.
> >>
> >> I think that the following patch could fix this:
> >>
> >> http://marc.info/?l=linux-ide&m=123484533504307&w=2
> >
> > The patch looks reasonable to me. I'm CCing the reporter of the bug. Wes,
> > would you be able to test out Fujita's patch linked above?
> 
> I grabbed the srpm for the fedoraized 2.6.29-0.137.rc5.git4 from koji,
> applied the patch, and tested--no joy, I'm still getting the warning.
> Would there be any value to me trying this with a vanilla+dma-debug
> kernel build?
> 
> Tomorrow I'm going to bump up the show_num_errors (currently at 1) in
> the dma debug patch to see if maybe that produces anything else
> interesting;

I think that probably it's not interesting much. Once you get a
dma-debug error, the later errors are not reliable.

For example, dma-debug finds a dma-debug error about a NIC, you could
get false dma-debug errors about even good device drivers.


> I've already got another bug that races with nv_sata to
> get that first warning (in forcedeth, so you probably don't care, but
> if so see https://bugzilla.redhat.com/show_bug.cgi?id=484494 ).

As I explained above, you can't have other dma-debug error source. Can
you test only nv_sata with my patch again?

Re: sata_nv frees DMA memory with different size (possibly a generic libata bug)

[Wes Shull]

On Fri, Feb 20, 2009 at 11:57 PM, FUJITA Tomonori
<fujita.tomonori@lab.ntt.co.jp> wrote:
> On Fri, 20 Feb 2009 04:20:29 -0700
> Wes Shull <wes.shull@gmail.com> wrote:
>
>> On Thu, Feb 19, 2009 at 7:58 PM, Robert Hancock <hancockrwd@gmail.com> wrote:
>> > FUJITA Tomonori wrote:
>> >>
>> >> On Wed, 18 Feb 2009 17:05:44 -0500
>> >> Chuck Ebbert <cebbert@redhat.com> wrote:
>> >>
>> >>> On Wed, 18 Feb 2009 15:25:16 -0500
>> >>> Chuck Ebbert <cebbert@redhat.com> wrote:
>> >>>
>> >>>> On Tue, 17 Feb 2009 20:22:05 +0900
>> >>>> FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:
>> >>>>
>> >>>>
>> >>>>>>>>>
>> >>>>>>>>> sata_nv 0000:00:0d.0: DMA-API: device driver frees DMA memory with
>> >>>>>>>>> different
>> >>>>>>>>> size [device address=0x00000000da031000] [map size=4096 bytes]
>> >>>>>>>>> [unmap
>> >>>>>>>>
>> >>>>>>>> That's rather curious. It seems to be saying that the sg length is
>> >>>>>>>> different between the map and unmap, but it doesn't look like sata_nv mucks
>> >>>>>>>> with that anywhere, and neither does libata core..
>> >>>>>>>
>> >>>>>>> Could the SCSI code have merged two requests?
>> >>>>>>
>> >>>>>> I wouldn't think so.. and if it did it seems like it would have to
>> >>>>>> have changed the list after libata got the request somehow..
>> >>>>>
>> >>>>> Does this box uses GART IOMMU?
>> >>>>
>> >>>> I don't think so, but I've asked for the dmesg.
>> >>>
>> >>> Okay, it _is_ using GART IOMMU:
>> >>>
>> >>> DMA-API: preallocated 8192 debug entries
>> >>> DMA-API: debugging enabled by kernel config
>> >>> PCI-DMA: Disabling AGP.
>> >>> PCI-DMA: aperture base @ 20000000 size 65536 KB
>> >>> PCI-DMA: using GART IOMMU.
>> >>> PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture
>> >>
>> >> Thanks, that makes sense.
>> >>
>> >> I think that the following patch could fix this:
>> >>
>> >> http://marc.info/?l=linux-ide&m=123484533504307&w=2
>> >
>> > The patch looks reasonable to me. I'm CCing the reporter of the bug. Wes,
>> > would you be able to test out Fujita's patch linked above?
>>
>> I grabbed the srpm for the fedoraized 2.6.29-0.137.rc5.git4 from koji,
>> applied the patch, and tested--no joy, I'm still getting the warning.
>> Would there be any value to me trying this with a vanilla+dma-debug
>> kernel build?
>>
>> Tomorrow I'm going to bump up the show_num_errors (currently at 1) in
>> the dma debug patch to see if maybe that produces anything else
>> interesting;
>
> I think that probably it's not interesting much. Once you get a
> dma-debug error, the later errors are not reliable.
>
> For example, dma-debug finds a dma-debug error about a NIC, you could
> get false dma-debug errors about even good device drivers.
>
>
>> I've already got another bug that races with nv_sata to
>> get that first warning (in forcedeth, so you probably don't care, but
>> if so see https://bugzilla.redhat.com/show_bug.cgi?id=484494 ).
>
> As I explained above, you can't have other dma-debug error source. Can
> you test only nv_sata with my patch again?

Ok, I blocked forcedeth from loading, rebooted (still running the
kernel I built with your patch--despite these warning messages, it's
100% stable in all my testing), verified that forcedeth hadn't
loaded...  but I still got the nv_sata warning.  So that's not it
either :(

Re: sata_nv frees DMA memory with different size (possibly a generic libata bug)

[Robert Hancock]

Wes Shull wrote:
>>>>> I think that the following patch could fix this:
>>>>>
>>>>> http://marc.info/?l=linux-ide&m=123484533504307&w=2
>>>> The patch looks reasonable to me. I'm CCing the reporter of the bug. Wes,
>>>> would you be able to test out Fujita's patch linked above?
>>> I grabbed the srpm for the fedoraized 2.6.29-0.137.rc5.git4 from koji,
>>> applied the patch, and tested--no joy, I'm still getting the warning.
>>> Would there be any value to me trying this with a vanilla+dma-debug
>>> kernel build?
>>>
>>> Tomorrow I'm going to bump up the show_num_errors (currently at 1) in
>>> the dma debug patch to see if maybe that produces anything else
>>> interesting;
>> I think that probably it's not interesting much. Once you get a
>> dma-debug error, the later errors are not reliable.
>>
>> For example, dma-debug finds a dma-debug error about a NIC, you could
>> get false dma-debug errors about even good device drivers.
>>
>>
>>> I've already got another bug that races with nv_sata to
>>> get that first warning (in forcedeth, so you probably don't care, but
>>> if so see https://bugzilla.redhat.com/show_bug.cgi?id=484494 ).
>> As I explained above, you can't have other dma-debug error source. Can
>> you test only nv_sata with my patch again?
> 
> Ok, I blocked forcedeth from loading, rebooted (still running the
> kernel I built with your patch--despite these warning messages, it's
> 100% stable in all my testing), verified that forcedeth hadn't
> loaded...  but I still got the nv_sata warning.  So that's not it
> either :(

I suppose it makes sense it wouldn't fix this particular problem, though 
I think the patch is still correct (and Fujita should likely push it for 
-next). In this case it's complaining about a mismatch of one of the 
element sizes, not the number of elements which is what it was fixing

Fujita, do you know if there is some other kind of merging that the GART 
IOMMU code could be doing that would be tripping up this debug code?

Re: sata_nv frees DMA memory with different size (possibly a generic libata bug)

[FUJITA Tomonori]

On Sat, 21 Feb 2009 13:02:53 -0600
Robert Hancock <hancockrwd@gmail.com> wrote:

> I suppose it makes sense it wouldn't fix this particular problem, though 
> I think the patch is still correct (and Fujita should likely push it for 
> -next). In this case it's complaining about a mismatch of one of the 
> element sizes, not the number of elements which is what it was fixing

Yeah, you are right. The patch is correct. But after rereading the
dma-debug code, I'm sure that the patch doesn't fix this problem.


> Fujita, do you know if there is some other kind of merging that the GART 
> IOMMU code could be doing that would be tripping up this debug code?

Unfortunately, I don't now... I'll check the code later.