In the past months ivtv has started causing warnings (triggering kerneloops) in fedora devel kernels. Since it's getting quite annoying, and the kerneloops does not seem to be handled, here is a proper bug WARNING: at lib/dma-debug.c:620 check_sync+0x272/0x441() Hardware name: EP45-DS5 ivtv 0000:06:01.0: DMA-API: device driver syncs DMA memory with different direction [device address=0x0000000020070000] [size=12 bytes] [mapped with DMA_FROM_DEVICE] [synced with DMA_TO_DEVICE] Modules linked in: tuner_simple tuner_types wm8775 tda9887 tda8290 tuner cx25840 snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_event snd_seq_midi_emul snd_seq snd_hda_intel ivtv(+) snd_emu10k1 i2c_algo_bit snd_hda_codec cx2341x snd_rawmidi snd_ac97_codec v4l2_common videodev ac97_bus firewire_ohci snd_seq_device firewire_core v4l1_compat snd_pcm ata_generic snd_util_mem i2c_i801 v4l2_compat_ioctl32 iTCO_wdt pata_acpi tveeprom i2c_core pcspkr crc_itu_t snd_hwdep iTCO_vendor_support r8169 snd_timer snd mii soundcore pata_jmicron snd_page_alloc raid1 [last unloaded: scsi_wait_scan] Pid: 1062, comm: work_for_cpu Not tainted 2.6.30-0.89.rc7.fc12.x86_64 #1 Call Trace: [<ffffffff8105b001>] warn_slowpath_common+0x8d/0xbb [<ffffffff8105b0bc>] warn_slowpath_fmt+0x50/0x66 [<ffffffff81250106>] ? get_hash_bucket+0x3b/0x5d [<ffffffff812505e4>] check_sync+0x272/0x441 [<ffffffff812509ca>] debug_dma_sync_single_for_cpu+0x30/0x46 [<ffffffffa0164939>] pci_dma_sync_single_for_cpu+0x7f/0x9e [ivtv] [<ffffffffa0165296>] ivtv_stream_alloc+0x1f8/0x335 [ivtv] [<ffffffffa0166bc1>] ivtv_streams_setup+0x337/0x382 [ivtv] [<ffffffffa016c2f8>] ivtv_probe+0x13f4/0x1543 [ivtv] [<ffffffff81054e72>] ? finish_task_switch+0x4f/0x122 [<ffffffff814b6e8c>] ? thread_return+0x4e/0xbc [<ffffffff814b9a07>] ? _spin_unlock_irqrestore+0x5a/0x7f [<ffffffff810888c7>] ? trace_hardirqs_on_caller+0x139/0x173 [<ffffffff81259bf7>] local_pci_probe+0x2a/0x42 [<ffffffff810706b9>] do_work_for_cpu+0x27/0x50 [<ffffffff81070692>] ? do_work_for_cpu+0x0/0x50 [<ffffffff81075394>] kthread+0x6d/0xae [<ffffffff8101418a>] child_rip+0xa/0x20 [<ffffffff81013b50>] ? restore_args+0x0/0x30 [<ffffffff81075327>] ? kthread+0x0/0xae [<ffffffff81014180>] ? child_rip+0x0/0x20 ---[ end trace 08f9d5aa2be9be7e ]---
Created attachment 21544 [details] system lspci
Created attachment 21545 [details] dmesg
This is: if (ivtv_might_use_dma(s)) { s->sg_handle = pci_map_single(itv->pdev, s->sg_dma, sizeof(struc ... s->dma)) ivtv_stream_sync_for_cpu(s); } Mapped with the type s->dma and handle s->sg_handle then flushed using static inline void ivtv_stream_sync_for_cpu(struct ivtv_stream *s) { if (ivtv_use_dma(s)) pci_dma_sync_single_for_cpu(s->itv->pdev, s->sg_handle, sizeof(struct ivtv_sg_element), PCI_DMA_TODEVICE); } from the code it seems that the buffers may be to or from but the sg handle is always to so try the following patch
Created attachment 21731 [details] Patch to test Please try this
Created attachment 21739 [details] dmesg #2
(In reply to comment #4) > Please try this Well, the DMA-API message about ivtv is gone, now I have another one about ahci. ivtv itself works fine ahci 0000:00:1f.2: DMA-API: device driver frees DMA sg list with different entry count [map count=70] [unmap count=26] (see new attached dmesg)
WARNING: at lib/dma-debug.c:530 check_unmap+0x3cf/0x519() Hardware name: EP45-DS5 ahci 0000:00:1f.2: DMA-API: device driver frees DMA sg list with different entry count [map count=70] [unmap count=26] Modules linked in: it87 hwmon_vid coretemp hwmon xt_limit xt_TCPMSS ipt_LOG xt_pkttype iptable_mangle ipt_MASQUERADE ipt_REDIRECT xt_owner xt_multiport iptable_nat nf_nat acpi_cpufreq freq_table snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_event snd_seq_midi_emul snd_seq tuner_simple tuner_types wm8775 tda9887 tda8290 tuner cx25840 snd_emu10k1 snd_rawmidi snd_ac97_codec ivtv snd_hda_intel snd_hda_codec i2c_algo_bit cx2341x v4l2_common videodev ac97_bus firewire_ohci snd_seq_device v4l1_compat v4l2_compat_ioctl32 firewire_core tveeprom snd_util_mem snd_pcm snd_hwdep ata_generic snd_timer pata_acpi pcspkr i2c_i801 crc_itu_t i2c_core snd soundcore r8169 pata_jmicron iTCO_wdt iTCO_vendor_support mii snd_page_alloc raid1 [last unloaded: scsi_wait_scan] Pid: 0, comm: swapper Not tainted 2.6.30-0.91.rc7.git1.bzko503662.1.fc12.x86_64 #1 Call Trace: <IRQ> [<ffffffff8105b041>] warn_slowpath_common+0x8d/0xbb [<ffffffff8105b0fc>] warn_slowpath_fmt+0x50/0x66 [<ffffffff81250126>] ? get_hash_bucket+0x3b/0x5d [<ffffffff81250f00>] check_unmap+0x3cf/0x519 [<ffffffff81250126>] ? get_hash_bucket+0x3b/0x5d [<ffffffff81251239>] debug_dma_unmap_sg+0x152/0x18c [<ffffffff81087258>] ? register_lock_class+0x2d/0x37e [<ffffffff8133be71>] ata_sg_clean+0xa9/0xfa [<ffffffff8133bf28>] __ata_qc_complete+0x66/0xef [<ffffffff8133c154>] ata_qc_complete+0x1a3/0x1c4 [<ffffffff8133c4f3>] ata_qc_complete_multiple+0xb8/0xe8 [<ffffffff81351c8e>] ? ahci_interrupt+0x5d/0x4be [<ffffffff81352032>] ahci_interrupt+0x401/0x4be [<ffffffff81086d4a>] ? lock_release_holdtime+0x3f/0x147 [<ffffffff810b9644>] handle_IRQ_event+0x62/0x148 [<ffffffff810bbbb4>] handle_edge_irq+0xde/0x13c [<ffffffff81015eac>] handle_irq+0x9a/0xba [<ffffffff814b943b>] ? trace_hardirqs_off_thunk+0x3a/0x3c [<ffffffff810153f6>] do_IRQ+0x6f/0xee [<ffffffff81013a93>] ret_from_intr+0x0/0x16 <EOI> [<ffffffff812c0781>] ? acpi_idle_enter_simple+0x132/0x17a [<ffffffff812c077a>] ? acpi_idle_enter_simple+0x12b/0x17a [<ffffffff813d0335>] ? cpuidle_idle_call+0xa0/0xef [<ffffffff81011f4e>] ? cpu_idle+0xbf/0x10a [<ffffffff814b1bb8>] ? start_secondary+0x211/0x268 ---[ end trace 32a0d5fa6281db13 ]--- Mapped at: [<ffffffff81251502>] debug_dma_map_sg+0x4a/0x135 [<ffffffff8133c38c>] ata_qc_issue+0x217/0x2c6 [<ffffffff81343db2>] __ata_scsi_queuecmd+0x1a2/0x212 [<ffffffff81343ef9>] ata_scsi_queuecmd+0x6d/0xc0 [<ffffffff8131c516>] scsi_dispatch_cmd+0x1c2/0x25f (btw the build is available here if that matters, just added your patch to a regular fedora kernel https://koji.fedoraproject.org/koji/taskinfo?taskID=1392082 )
I will push the ivtv fixes and reassign the rest of this to libata