* i40e: Kernel unaligned access due to 'struct i40e_dma_mem' being 'packed'
@ 2016-01-28 1:50 ` tndave
0 siblings, 0 replies; 8+ messages in thread
From: tndave @ 2016-01-28 1:50 UTC (permalink / raw)
To: netdev, Kirsher, Jeffrey T, Brandeburg, Jesse, Nelson, Shannon,
Wyborny, Carolyn, Skidmore, Donald C, Allan, Bruce W, Ronciak,
John, mitch.a.williams, intel-wired-lan
Cc: tushar.n.dave
Hi,
i40e driver has 'struct i40e_dma_mem' defined with 'packed' directive
causing kernel unaligned errors on sparc (when 40e_allocate_dma_mem_d()
is being called)
log_unaligned: 1031 callbacks suppressed
Kernel unaligned access at TPC[448ae8] dma_4v_alloc_coherent+0x188/0x2e0
Kernel unaligned access at TPC[448ae8] dma_4v_alloc_coherent+0x188/0x2e0
Kernel unaligned access at TPC[448ae8] dma_4v_alloc_coherent+0x188/0x2e0
Kernel unaligned access at TPC[448ae8] dma_4v_alloc_coherent+0x188/0x2e0
This can be fixed with get_unaligned/put_unaligned(). However I don't
see 'struct i40e_dma_mem' is being directly shoved into NIC hardware.
But instead fields of the struct are being read and used for hardware
(e.g. dma_addr_t pa). For the test, I remove __packed, and i40e driver
and HW works fine. (of course kernel unaligned errors are gone too).
My question is, does 'struct i40e_dma_mem' required to be __packed?
Thanks.
-Tushar
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Intel-wired-lan] i40e: Kernel unaligned access due to 'struct i40e_dma_mem' being 'packed'
@ 2016-01-28 1:50 ` tndave
0 siblings, 0 replies; 8+ messages in thread
From: tndave @ 2016-01-28 1:50 UTC (permalink / raw)
To: intel-wired-lan
Hi,
i40e driver has 'struct i40e_dma_mem' defined with 'packed' directive
causing kernel unaligned errors on sparc (when 40e_allocate_dma_mem_d()
is being called)
log_unaligned: 1031 callbacks suppressed
Kernel unaligned access at TPC[448ae8] dma_4v_alloc_coherent+0x188/0x2e0
Kernel unaligned access at TPC[448ae8] dma_4v_alloc_coherent+0x188/0x2e0
Kernel unaligned access at TPC[448ae8] dma_4v_alloc_coherent+0x188/0x2e0
Kernel unaligned access at TPC[448ae8] dma_4v_alloc_coherent+0x188/0x2e0
This can be fixed with get_unaligned/put_unaligned(). However I don't
see 'struct i40e_dma_mem' is being directly shoved into NIC hardware.
But instead fields of the struct are being read and used for hardware
(e.g. dma_addr_t pa). For the test, I remove __packed, and i40e driver
and HW works fine. (of course kernel unaligned errors are gone too).
My question is, does 'struct i40e_dma_mem' required to be __packed?
Thanks.
-Tushar
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: i40e: Kernel unaligned access due to 'struct i40e_dma_mem' being 'packed'
2016-01-28 1:50 ` [Intel-wired-lan] " tndave
@ 2016-01-28 6:56 ` David Miller
-1 siblings, 0 replies; 8+ messages in thread
From: David Miller @ 2016-01-28 6:56 UTC (permalink / raw)
To: tushar.n.dave
Cc: netdev, jeffrey.t.kirsher, jesse.brandeburg, shannon.nelson,
carolyn.wyborny, donald.c.skidmore, bruce.w.allan, john.ronciak,
mitch.a.williams, intel-wired-lan
From: tndave <tushar.n.dave@oracle.com>
Date: Wed, 27 Jan 2016 17:50:14 -0800
> Hi,
>
> i40e driver has 'struct i40e_dma_mem' defined with 'packed' directive
> causing kernel unaligned errors on sparc (when
> 40e_allocate_dma_mem_d()
> is being called)
>
> log_unaligned: 1031 callbacks suppressed
> Kernel unaligned access at TPC[448ae8]
> dma_4v_alloc_coherent+0x188/0x2e0
> Kernel unaligned access at TPC[448ae8]
> dma_4v_alloc_coherent+0x188/0x2e0
> Kernel unaligned access at TPC[448ae8]
> dma_4v_alloc_coherent+0x188/0x2e0
> Kernel unaligned access at TPC[448ae8]
> dma_4v_alloc_coherent+0x188/0x2e0
>
> This can be fixed with get_unaligned/put_unaligned(). However I don't
> see 'struct i40e_dma_mem' is being directly shoved into NIC hardware.
> But instead fields of the struct are being read and used for hardware
> (e.g. dma_addr_t pa). For the test, I remove __packed, and i40e driver
> and HW works fine. (of course kernel unaligned errors are gone too).
> My question is, does 'struct i40e_dma_mem' required to be __packed?
People get overzealoud with __packed.
And even if it doesn't cause unaligned accesses like this, it generates
terrible code (byte at a time accesses to words) on several architectures.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Intel-wired-lan] i40e: Kernel unaligned access due to 'struct i40e_dma_mem' being 'packed'
@ 2016-01-28 6:56 ` David Miller
0 siblings, 0 replies; 8+ messages in thread
From: David Miller @ 2016-01-28 6:56 UTC (permalink / raw)
To: intel-wired-lan
From: tndave <tushar.n.dave@oracle.com>
Date: Wed, 27 Jan 2016 17:50:14 -0800
> Hi,
>
> i40e driver has 'struct i40e_dma_mem' defined with 'packed' directive
> causing kernel unaligned errors on sparc (when
> 40e_allocate_dma_mem_d()
> is being called)
>
> log_unaligned: 1031 callbacks suppressed
> Kernel unaligned access at TPC[448ae8]
> dma_4v_alloc_coherent+0x188/0x2e0
> Kernel unaligned access at TPC[448ae8]
> dma_4v_alloc_coherent+0x188/0x2e0
> Kernel unaligned access at TPC[448ae8]
> dma_4v_alloc_coherent+0x188/0x2e0
> Kernel unaligned access at TPC[448ae8]
> dma_4v_alloc_coherent+0x188/0x2e0
>
> This can be fixed with get_unaligned/put_unaligned(). However I don't
> see 'struct i40e_dma_mem' is being directly shoved into NIC hardware.
> But instead fields of the struct are being read and used for hardware
> (e.g. dma_addr_t pa). For the test, I remove __packed, and i40e driver
> and HW works fine. (of course kernel unaligned errors are gone too).
> My question is, does 'struct i40e_dma_mem' required to be __packed?
People get overzealoud with __packed.
And even if it doesn't cause unaligned accesses like this, it generates
terrible code (byte at a time accesses to words) on several architectures.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: i40e: Kernel unaligned access due to 'struct i40e_dma_mem' being 'packed'
2016-01-28 6:56 ` [Intel-wired-lan] " David Miller
@ 2016-01-29 22:47 ` tndave
-1 siblings, 0 replies; 8+ messages in thread
From: tndave @ 2016-01-29 22:47 UTC (permalink / raw)
To: David Miller
Cc: netdev, jeffrey.t.kirsher, jesse.brandeburg, shannon.nelson,
carolyn.wyborny, donald.c.skidmore, bruce.w.allan, john.ronciak,
mitch.a.williams, intel-wired-lan
On 01/27/2016 10:56 PM, David Miller wrote:
> From: tndave <tushar.n.dave@oracle.com>
> Date: Wed, 27 Jan 2016 17:50:14 -0800
>
>> Hi,
>>
>> i40e driver has 'struct i40e_dma_mem' defined with 'packed' directive
>> causing kernel unaligned errors on sparc (when
>> 40e_allocate_dma_mem_d()
>> is being called)
>>
>> log_unaligned: 1031 callbacks suppressed
>> Kernel unaligned access at TPC[448ae8]
>> dma_4v_alloc_coherent+0x188/0x2e0
>> Kernel unaligned access at TPC[448ae8]
>> dma_4v_alloc_coherent+0x188/0x2e0
>> Kernel unaligned access at TPC[448ae8]
>> dma_4v_alloc_coherent+0x188/0x2e0
>> Kernel unaligned access at TPC[448ae8]
>> dma_4v_alloc_coherent+0x188/0x2e0
>>
>> This can be fixed with get_unaligned/put_unaligned(). However I don't
>> see 'struct i40e_dma_mem' is being directly shoved into NIC hardware.
>> But instead fields of the struct are being read and used for hardware
>> (e.g. dma_addr_t pa). For the test, I remove __packed, and i40e driver
>> and HW works fine. (of course kernel unaligned errors are gone too).
>> My question is, does 'struct i40e_dma_mem' required to be __packed?
>
> People get overzealoud with __packed.
>
> And even if it doesn't cause unaligned accesses like this, it generates
> terrible code (byte at a time accesses to words) on several architectures.
True. For the same reason I want to clarify if __packed is actually
needed? instead of fixing it with get_unaligned/put_unaligned()!
-Tushar
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Intel-wired-lan] i40e: Kernel unaligned access due to 'struct i40e_dma_mem' being 'packed'
@ 2016-01-29 22:47 ` tndave
0 siblings, 0 replies; 8+ messages in thread
From: tndave @ 2016-01-29 22:47 UTC (permalink / raw)
To: intel-wired-lan
On 01/27/2016 10:56 PM, David Miller wrote:
> From: tndave <tushar.n.dave@oracle.com>
> Date: Wed, 27 Jan 2016 17:50:14 -0800
>
>> Hi,
>>
>> i40e driver has 'struct i40e_dma_mem' defined with 'packed' directive
>> causing kernel unaligned errors on sparc (when
>> 40e_allocate_dma_mem_d()
>> is being called)
>>
>> log_unaligned: 1031 callbacks suppressed
>> Kernel unaligned access at TPC[448ae8]
>> dma_4v_alloc_coherent+0x188/0x2e0
>> Kernel unaligned access at TPC[448ae8]
>> dma_4v_alloc_coherent+0x188/0x2e0
>> Kernel unaligned access at TPC[448ae8]
>> dma_4v_alloc_coherent+0x188/0x2e0
>> Kernel unaligned access at TPC[448ae8]
>> dma_4v_alloc_coherent+0x188/0x2e0
>>
>> This can be fixed with get_unaligned/put_unaligned(). However I don't
>> see 'struct i40e_dma_mem' is being directly shoved into NIC hardware.
>> But instead fields of the struct are being read and used for hardware
>> (e.g. dma_addr_t pa). For the test, I remove __packed, and i40e driver
>> and HW works fine. (of course kernel unaligned errors are gone too).
>> My question is, does 'struct i40e_dma_mem' required to be __packed?
>
> People get overzealoud with __packed.
>
> And even if it doesn't cause unaligned accesses like this, it generates
> terrible code (byte at a time accesses to words) on several architectures.
True. For the same reason I want to clarify if __packed is actually
needed? instead of fixing it with get_unaligned/put_unaligned()!
-Tushar
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: i40e: Kernel unaligned access due to 'struct i40e_dma_mem' being 'packed'
2016-01-29 22:47 ` [Intel-wired-lan] " tndave
@ 2016-02-14 0:22 ` tndave
-1 siblings, 0 replies; 8+ messages in thread
From: tndave @ 2016-02-14 0:22 UTC (permalink / raw)
To: jeffrey.t.kirsher, jesse.brandeburg, shannon.nelson,
carolyn.wyborny, donald.c.skidmore, bruce.w.allan, john.ronciak,
mitch.a.williams, intel-wired-lan
Cc: David Miller, netdev
On 01/30/2016 04:17 AM, tndave wrote:
>
>
> On 01/27/2016 10:56 PM, David Miller wrote:
>> From: tndave <tushar.n.dave@oracle.com>
>> Date: Wed, 27 Jan 2016 17:50:14 -0800
>>
>>> Hi,
>>>
>>> i40e driver has 'struct i40e_dma_mem' defined with 'packed' directive
>>> causing kernel unaligned errors on sparc (when
>>> 40e_allocate_dma_mem_d()
>>> is being called)
>>>
>>> log_unaligned: 1031 callbacks suppressed
>>> Kernel unaligned access at TPC[448ae8]
>>> dma_4v_alloc_coherent+0x188/0x2e0
>>> Kernel unaligned access at TPC[448ae8]
>>> dma_4v_alloc_coherent+0x188/0x2e0
>>> Kernel unaligned access at TPC[448ae8]
>>> dma_4v_alloc_coherent+0x188/0x2e0
>>> Kernel unaligned access at TPC[448ae8]
>>> dma_4v_alloc_coherent+0x188/0x2e0
>>>
>>> This can be fixed with get_unaligned/put_unaligned(). However I don't
>>> see 'struct i40e_dma_mem' is being directly shoved into NIC hardware.
>>> But instead fields of the struct are being read and used for hardware
>>> (e.g. dma_addr_t pa). For the test, I remove __packed, and i40e driver
>>> and HW works fine. (of course kernel unaligned errors are gone too).
>>> My question is, does 'struct i40e_dma_mem' required to be __packed?
>>
>> People get overzealoud with __packed.
>>
>> And even if it doesn't cause unaligned accesses like this, it generates
>> terrible code (byte at a time accesses to words) on several
>> architectures.
> True. For the same reason I want to clarify if __packed is actually
> needed? instead of fixing it with get_unaligned/put_unaligned()!
We are having this issue on multiple sparc servers. It would be really
helpful to have feedback from i40e driver folks.
Thanks.
-Tushar
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Intel-wired-lan] i40e: Kernel unaligned access due to 'struct i40e_dma_mem' being 'packed'
@ 2016-02-14 0:22 ` tndave
0 siblings, 0 replies; 8+ messages in thread
From: tndave @ 2016-02-14 0:22 UTC (permalink / raw)
To: intel-wired-lan
On 01/30/2016 04:17 AM, tndave wrote:
>
>
> On 01/27/2016 10:56 PM, David Miller wrote:
>> From: tndave <tushar.n.dave@oracle.com>
>> Date: Wed, 27 Jan 2016 17:50:14 -0800
>>
>>> Hi,
>>>
>>> i40e driver has 'struct i40e_dma_mem' defined with 'packed' directive
>>> causing kernel unaligned errors on sparc (when
>>> 40e_allocate_dma_mem_d()
>>> is being called)
>>>
>>> log_unaligned: 1031 callbacks suppressed
>>> Kernel unaligned access at TPC[448ae8]
>>> dma_4v_alloc_coherent+0x188/0x2e0
>>> Kernel unaligned access at TPC[448ae8]
>>> dma_4v_alloc_coherent+0x188/0x2e0
>>> Kernel unaligned access at TPC[448ae8]
>>> dma_4v_alloc_coherent+0x188/0x2e0
>>> Kernel unaligned access at TPC[448ae8]
>>> dma_4v_alloc_coherent+0x188/0x2e0
>>>
>>> This can be fixed with get_unaligned/put_unaligned(). However I don't
>>> see 'struct i40e_dma_mem' is being directly shoved into NIC hardware.
>>> But instead fields of the struct are being read and used for hardware
>>> (e.g. dma_addr_t pa). For the test, I remove __packed, and i40e driver
>>> and HW works fine. (of course kernel unaligned errors are gone too).
>>> My question is, does 'struct i40e_dma_mem' required to be __packed?
>>
>> People get overzealoud with __packed.
>>
>> And even if it doesn't cause unaligned accesses like this, it generates
>> terrible code (byte at a time accesses to words) on several
>> architectures.
> True. For the same reason I want to clarify if __packed is actually
> needed? instead of fixing it with get_unaligned/put_unaligned()!
We are having this issue on multiple sparc servers. It would be really
helpful to have feedback from i40e driver folks.
Thanks.
-Tushar
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2016-02-14 0:22 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-01-28 1:50 i40e: Kernel unaligned access due to 'struct i40e_dma_mem' being 'packed' tndave
2016-01-28 1:50 ` [Intel-wired-lan] " tndave
2016-01-28 6:56 ` David Miller
2016-01-28 6:56 ` [Intel-wired-lan] " David Miller
2016-01-29 22:47 ` tndave
2016-01-29 22:47 ` [Intel-wired-lan] " tndave
2016-02-14 0:22 ` tndave
2016-02-14 0:22 ` [Intel-wired-lan] " tndave
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.