Re: 3.9-rc7 suspend failure

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I have a feeling it's something else and the patch maybe have exposed it. A channel error occured and bit 12 is Completion Address Error. IOATDMA driver has no suspend/resume support. So what happens to the driver when a suspend and then resume happens? Is it possible that the DMA mapped completion address no longer exists after resume? What platform did this happen on?

On 04/26/2013 09:27 AM, Sarah Sharp wrote:
Ccing Dave Jiang.

Dave, can you please take a look at this resume from suspend failure?
Tony bisected it to one of your patches.

On Thu, Apr 25, 2013 at 11:43:00PM -0400, Tony Camuso wrote:
On 04/23/2013 05:14 PM, Sarah Sharp wrote:
On Tue, Apr 23, 2013 at 04:18:00PM -0400, Tony Camuso wrote:
It hangs in both suspend and resume with vanilla 3.9-rc7 and rc8.
Neither the new patch nor the old patch helps.
It might be unrelated to USB then.  Let's see what the bisect shows.

It does appear to be unrelated to usb. Now we need to determine why
this should cause problems with suspend/resume.

-----------------------------------------------------------------------------
# git bisect bad
4dec23d7718e6f1f5e1773698d112025169e7d49 is the first bad commit
commit 4dec23d7718e6f1f5e1773698d112025169e7d49
Author: Dave Jiang <dave.jiang@xxxxxxxxx>
Date:   Thu Feb 7 14:38:32 2013 -0700

     ioatdma: fix race between updating ioat->head and IOAT_COMPLETION_PENDING
     There is a race that can hit during __cleanup() when the ioat->head pointer is
     incremented during descriptor submission. The __cleanup() can clear the
     PENDING flag when it does not see any active descriptors. This causes new
     submitted descriptors to be ignored because the COMPLETION_PENDING flag is
     cleared. This was introduced when code was adapted from ioatdma v1 to ioatdma
     v2. For v2 and v3, IOAT_COMPLETION_PENDING flag will be abandoned and a new
     flag IOAT_CHAN_ACTIVE will be utilized. This flag will also be protected under
     the prep_lock when being modified in order to avoid the race.
     Signed-off-by: Dave Jiang <dave.jiang@xxxxxxxxx>
     Reviewed-by: Dan Williams <djbw@xxxxxx>
     Signed-off-by: Vinod Koul <vinod.koul@xxxxxxxxx>

:040000 040000 6a99537c215da68179b7431d165c4aa88c2f569d b339a473063ad04cd985399e43e2e11c9a2a7026 M	drivers
-----------------------------------------------------------------------------


Here is a Call Trace when resuming from suspend with the above patch.

-----------------------------------------------------------------------------
[   96.324588] ioatdma 0000:40:04.0: ioat2_timer_event: Channel halted (1000)
[   96.324659] ------------[ cut here ]------------
[   96.324661] kernel BUG at drivers/dma/ioat/dma_v2.c:317!
[   96.324665] invalid opcode: 0000 [#1] SMP
[   96.324709] Modules linked in: ipt_MASQUERADE nf_conntrack_netbios_ns nf_conntrack_broadcast ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 iptable_nat nf_nat_ipv4 nf_nat iptable_mangle nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ebtable_filter ebtables ip6table_filter ip6_tables kvm_intel snd_hda_codec_hdmi coretemp snd_hda_codec_realtek kvm snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm snd_page_alloc snd_timer snd hp_wmi crc32c_intel sb_edac ioatdma sparse_keymap iTCO_wdt soundcore edac_core ghash_clmulni_intel rfkill e1000e iTCO_vendor_support mei microcode i2c_i801 lpc_ich pcspkr serio_raw dca mfd_core nouveau isci video mxm_wmi i2c_algo_bit drm_kms_helper ttm libsas drm mpt2sas firewire_ohci firewire_core ata_generic raid_class scsi_transport_sas i2c_core pata_acpi crc_itu_t wmi
[   96.324718] CPU 0
[   96.324718] Pid: 0, comm: swapper/0 Not tainted 3.8.0-rc2+ #10 Hewlett-Packard HP Z820 Workstation/158B
[   96.324731] RIP: 0010:[<ffffffffa0275466>]  [<ffffffffa0275466>] ioat2_timer_event+0x1b6/0x2c0 [ioatdma]
[   96.324733] RSP: 0018:ffff8801a9c03df0  EFLAGS: 00010206
[   96.324734] RAX: 0000000000000023 RBX: ffff8801a6880228 RCX: 00000000000000ae
[   96.324735] RDX: 0000000000000000 RSI: 0000000000000086 RDI: 0000000000000246
[   96.324737] RBP: ffff8801a9c03e20 R08: ffffffff81e4b4e0 R09: ffffffff81e7faf0
[   96.324738] R10: 000000000000ba64 R11: 0000000000040000 R12: 0000000000001000
[   96.324740] R13: 0000000000000100 R14: ffffffffa02752b0 R15: ffff8801a6880228
[   96.324742] FS:  0000000000000000(0000) GS:ffff8801a9c00000(0000) knlGS:0000000000000000
[   96.324744] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   96.324745] CR2: 00007f8ce4190000 CR3: 0000000001c0c000 CR4: 00000000000407f0
[   96.324747] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   96.324748] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[   96.324751] Process swapper/0 (pid: 0, threadinfo ffffffff81c00000, task ffffffff81c14440)
[   96.324751] Stack:
[   96.324758]  000000019e050740 000000019e050740 ffffffff81e8c500 ffff8801a6880290
[   96.324763]  0000000000000100 ffffffffa02752b0 ffff8801a9c03e60 ffffffff8106cb9a
[   96.324768]  ffffffff8103d3d4 ffffffff81e8c500 ffff8801a6880290 ffffffffa02752b0
[   96.324769] Call Trace:
[   96.324774]  <IRQ>
[   96.324780]  [<ffffffffa02752b0>] ? reshape_ring+0x330/0x330 [ioatdma]
[   96.324788]  [<ffffffff8106cb9a>] call_timer_fn+0x3a/0x120
[   96.324794]  [<ffffffff8103d3d4>] ? native_apic_msr_eoi_write+0x14/0x20
[   96.324801]  [<ffffffffa02752b0>] ? reshape_ring+0x330/0x330 [ioatdma]
[   96.324807]  [<ffffffff81501ab0>] ? cpufreq_p4_target+0x120/0x120
[   96.324811]  [<ffffffff8106e92e>] run_timer_softirq+0x1fe/0x2b0
[   96.324815]  [<ffffffff81501ab0>] ? cpufreq_p4_target+0x120/0x120
[   96.324819]  [<ffffffff81066920>] __do_softirq+0xd0/0x210
[   96.324825]  [<ffffffff8101b8d3>] ? native_sched_clock+0x13/0x80
[   96.324829]  [<ffffffff81501ab0>] ? cpufreq_p4_target+0x120/0x120
[   96.324835]  [<ffffffff8165f31c>] call_softirq+0x1c/0x30


--

Dave Jiang
Application Engineer, Storage Divsion
Intel Corp.
dave.jiang@xxxxxxxxx

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux