On Thu, 2015-12-03 at 10:48 -0500, Sowmini Varadhan wrote: > The patch here: http://patchwork.ozlabs.org/patch/540218/ > is marked "Awaiting Upstream", I think that means it has to first > show up in some other repo first (which one?)? > > On addiitonal testing, we found a bug in the patch: if > we did not find the macaddr from Open Firmwre or IDPROM (i.e., > defaults > were ok) then you dont want to be doing i40e_macaddr_init again, else > you will get a failure like this (truncated dump_stack shown > below) > > [ 8127.050926] WARNING: CPU: 18 PID: 878 at kernel/irq/manage.c:1346 > __free_irq+0x9f/0x230() > [ 8127.050927] Trying to free already-free IRQ 177 > : > [ 8127.051013] [<ffffffffa043ddd0>] > i40e_clear_interrupt_scheme+0xb0/0xc0 [i40e] > [ 8127.051018] [<ffffffffa044b538>] i40e_probe.part.64+0x1018/0x1320 > [i40e] > : > [ 8127.051057] [<ffffffffa044b862>] i40e_probe+0x22/0x30 [i40e] > > I can think of a couple of ways to fix this- one (the ugly > way) is to ifdef the i40e_macaddr_init invocation for CONFIG_OF or > CONFIG_SPARC > only. Another way to solve this is to track some bit in struct > i40e_hw that > indicates that the macaddr is not the default, thus > i40e_macaddr_init() should > be called before register_netdev only if that bit is set. (Dont know > if there are cache-line considerations that exist in i40e_hw that > need to be taken into account for the second version) > > In order to send a fix out for review, what should I clone? > should I just apply the patch/540218 to net-next and send the update?
I will drop your current patch in my next-queue tree (dev-queue branch) and will await an updated patch.
signature.asc
Description: This is a digitally signed message part
