First, please don't remove the older parts of the thread. We're using outlook here and the threading is awful and sometimes it's hard for me to follow the thread.
Second, I'm not sure what you're doing. Your first email said: Known-good versions: sourceforge igb-5.2.5.tar.gz and earlier upstream in-kernel igb Known-bad versions: sourceforge igb-5.2.9.2.tar.gz and later igb_cache_ring_register hasn't changed between igb-5.2.5.tar.gz and igb-5.2.9.2.tar.gz. While I'm not doubting we changed some behavior, I have to repeat what I said in my first reply, your fix is wrong. We'll try reproducing your issue locally so we'll need exact repro steps starting from how you installed the OS to what you did to set up your system. Thanks. Todd Fujinaka Software Application Engineer Networking Division (ND) Intel Corporation todd.fujin...@intel.com (503) 712-4565 -----Original Message----- From: Tony Battersby [mailto:to...@cybernetics.com] Sent: Wednesday, January 07, 2015 11:06 AM To: Fujinaka, Todd; e1000-devel@lists.sourceforge.net Subject: Re: [E1000-devel] [PATCH] igb: fix Tx Unit Hang on 82576 with RSS > 1 I had igb_cache_ring_register() print out the relevant values and this is what I get: rss_queues = 8 vmdq_pools = 0 num_rx_queues = 8 num_tx_queues = 8 With those values, the unpatched igb_cache_ring_register() does nothing because of the break. With my patch, it falls through to the default case. Maybe the break should be contained within the if ((adapter->rss_queues > 1) && adapter->vmdq_pools) { ... } code segment instead, and the 82576 non-VMDq case should fall through? But I am testing only the non-VMDq case, so I can't confirm if the VMDq case is broken or not. What do you think of this patch instead: --- igb-5.2.15/src/igb_main.c.orig 2014-09-18 12:12:17.000000000 -0400 +++ igb-5.2.15/src/igb_main.c 2015-01-07 14:02:08.000000000 -0500 @@ -407,8 +407,9 @@ static void igb_cache_ring_register(stru for (; i < adapter->rss_queues; i++) adapter->rx_ring[i]->reg_idx = rbase_offset + Q_IDX_82576(i); + break; } - break; + /* Fall through */ case e1000_82575: case e1000_82580: case e1000_i350: On 01/07/2015 01:10 PM, Fujinaka, Todd wrote: > I think this is a setup issue. We don't use multiple TX queues per pool when > VMDq is enabled and that's why there's a special case for the 82576. > > Your patch would invalidate the whole switch statement and set up all parts > the same way. > > Todd Fujinaka > Software Application Engineer > Networking Division (ND) > Intel Corporation > todd.fujin...@intel.com > (503) 712-4565 > > ------------------------------------------------------------------------------ Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net _______________________________________________ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
