From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Kirsher Date: Thu, 05 May 2016 15:44:18 -0700 Subject: [Intel-wired-lan] "Trying to free already-free IRQ" error on i40e next-queue/dev-queue In-Reply-To: References: Message-ID: <1462488258.2536.22.camel@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: intel-wired-lan@osuosl.org List-ID: On Thu, 2016-05-05 at 15:24 -0700, Alexander Duyck wrote: > So on the latest pull of the dev-queue branch of next-queue I am > seeing the following error on shutdown when I have been using i40e: > > [ 2627.661836] ------------[ cut here ]------------ > [ 2627.667263] WARNING: CPU: 0 PID: 11386 at kernel/irq/manage.c:1447 > __free_irq+0xa6/0x290 > [ 2627.675995] Trying to free already-free IRQ 36 > [ 2627.681082] Modules linked in: ip6_gre ip6_tunnel tunnel6 sit ipip > tunnel4 ip_gre gre vxlan i40evf(E) fou ip6_ud > p_tunnel udp_tunnel ip_tunnel 8021q garp mrp stp llc i40e(E) vfat fat > x86_pkg_temp_thermal intel_powerclamp coretem > p kvm_intel snd_hda_codec_realtek snd_hda_codec_generic kvm > snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_ > seq irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel > snd_seq_device snd_pcm iTCO_wdt mei_me eeepc_wmi ae > sni_intel asus_wmi lrw gf128mul sparse_keymap snd_timer glue_helper > ablk_helper iTCO_vendor_support cryptd video mx > m_wmi snd sb_edac lpc_ich mei i2c_i801 pcspkr edac_core shpchp > mfd_core soundcore acpi_power_meter wmi acpi_pad ip_ > tables xfs libcrc32c mlx4_en ast drm_kms_helper syscopyarea > sysfillrect sysimgblt fb_sys_fops ttm igb mlx5_core drm > ?mlx4_core ahci libahci dca i2c_algo_bit serio_raw libata > crc32c_intel > ptp i2c_core pps_core dm_mirror dm_region_ha > sh dm_log dm_mod [last unloaded: ipmi_msghandler] > [ 2627.771305] CPU: 0 PID: 11386 Comm: kworker/u64:2 Tainted: G > ????E???4.6.0-rc6+ #61 > [ 2627.780388] Hardware name: ASUSTeK COMPUTER INC. Z10PE-D8 > WS/Z10PE-D8 WS, BIOS 3204 12/18/2015 > [ 2627.789824] Workqueue: netns cleanup_net > [ 2627.794609]??0000000000000086 0000000022dea3b3 ffff88202fcc7ab8 > ffffffff8132684f > [ 2627.802940]??ffff88202fcc7b08 0000000000000000 ffff88202fcc7af8 > ffffffff81078091 > [ 2627.811320]??000005a738c65700 0000000000000024 0000000000000024 > ffff8820380a3e9c > [ 2627.819657] Call Trace: > [ 2627.822984]??[] dump_stack+0x63/0x84 > [ 2627.829040]??[] __warn+0xd1/0xf0 > [ 2627.834766]??[] warn_slowpath_fmt+0x5f/0x80 > [ 2627.841442]??[] ? __slab_free+0x9b/0x280 > [ 2627.847868]??[] __free_irq+0xa6/0x290 > [ 2627.854024]??[] free_irq+0x39/0x90 > [ 2627.859908]??[] i40e_vsi_free_irq+0x18f/0x200 > [i40e] > [ 2627.867364]??[] ? _raw_spin_unlock_bh+0x1e/0x20 > [ 2627.874385]??[] i40e_vsi_close+0x25/0x70 [i40e] > [ 2627.881449]??[] i40e_close+0x15/0x20 [i40e] > [ 2627.888138]??[] __dev_close_many+0x99/0x100 > [ 2627.894827]??[] dev_close_many+0x89/0x130 > [ 2627.901372]??[] dev_close.part.89+0x45/0x70 > [ 2627.908123]??[] > dev_change_net_namespace+0x391/0x3e0 > [ 2627.913981] ACPI: Preparing to enter system sleep state S5 > [ 2627.967435]??[] default_device_exit+0xc4/0xf0 > [ 2627.974358]??[] ops_exit_list.isra.4+0x38/0x60 > [ 2627.981307]??[] cleanup_net+0x1b5/0x2a0 > [ 2627.987655]??[] process_one_work+0x152/0x400 > [ 2627.994437]??[] worker_thread+0x125/0x4b0 > [ 2628.000975]??[] ? rescuer_thread+0x380/0x380 > [ 2628.007735]??[] kthread+0xd8/0xf0 > [ 2628.013533]??[] ret_from_fork+0x22/0x40 > [ 2628.019851]??[] ? kthread_park+0x60/0x60 > [ 2628.026255] ---[ end trace 369d10b6dd193e9b ]--- > > This appears to be something recent.??I hadn't seen this until today, > but I had been focusing on getting the Mellanox stuff up and running > so it may have just been that I wasn't testing it.??Still though I > would guess this was something introduced in the last couple of > weeks. > > I don't know if it has any impact on this issue, but my test setup > has > 7 VFs allocated, assigned to namespaces, and passing traffic. The only recent changes that were made were: - updated to Dave's latest net-next - removed Kiran's 2 patches that dealt with FLOW_TYPE_MASK and Flow Director I will see if Andrew is seeing the same issue and if he can git bisect the issue. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: