You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by John Rippetoe <jr...@roboticresearch.com> on 2021/03/04 20:46:26 UTC
STM32H7 ethernet hardfaults
Hello All,
I've been playing around with networking on the STM32H7 and am seeing
hardfaults that appear to be related to NET_ETH_PKTSIZE. From the log
below, the driver would appear to be dropping packets that are too large
to fit into the default packet size of 590. By increasing the packet
size to the max (1518), the problem seems to disappear, but I am a
little confused why the driver is able to catch the fact that the
received packet was too large and drop it appropriately, but then crash.
After poking around the ethernet driver, I think I understand the issue
to be that because the MAC DMA does not know that the buffer it is
writing into has a size limit, it is overflowing the buffer and writing
into adjacent memory. Am I understanding this correctly?
My main concern here is that increasing NET_ETH_PKTSIZE to the limit
will only hide the issue for a time instead of solving it. A quick
google search does show that the maximum ethernet frame size is 1518
bytes though, so I am working under the assumption that maxing it out in
my config will account for all possible frame sizes and eliminate this
issue. I have no experience with low level networking protocols and
standards, so I thought it would be prudent to seek out additional help
to make sure I am on the right track.
Thanks in advance.
- John
stm32_receive: WARNING: DROPPED Too big: 684
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
stm32_receive: WARNING: DROPPED Too big: 1332
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
stm32_receive: WARNING: DROPPED Too big: 1264
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
stm32_receive: WARNING: DROPPED Too big: 684
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
stm32_receive: WARNING: DROPPED Too big: 1364
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
stm32_receive: WARNING: DROPPED Too big: 1264
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
stm32_receive: WARNING: DROPPED Too big: 1436
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
stm32_receive: WARNING: DROPPED Too big: 1300
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
up_hardfault: PANIC!!! Hard fault: 40000000
up_assert: Assertion failed at file:armv7-m/up_hardfault.c line: 148
task: lpwork
up_registerdump: R0: 24012080 2401206e 0000024e 00000000 24012000
40029160 24011fc0 00008040
up_registerdump: R8: 40029134 24011f00 24011fe0 240120b8 00000001
38002f88 080a26a7 080a2538
up_registerdump: xPSR: 81000000 BASEPRI: 000000f0 CONTROL: 00000000
up_registerdump: EXC_RETURN: ffffffe9
up_dumpstate: sp: 24010bb0
up_dumpstate: IRQ stack:
up_dumpstate: base: 24010c00
up_dumpstate: size: 00000200
up_dumpstate: used: 00000140
up_stackdump: 24010ba0: 24010bb0 2400e830 0000064c 080a0fed 000000f0
00000000 240120b8 00000001
up_stackdump: 24010bc0: 38002f88 080a26a7 080a2538 0816625a 00000000
080a129f 080a1271 080f754f
up_stackdump: 24010be0: 000000f0 080a2935 000000f0 38002eb4 40029160
24011fc0 00008040 080a1b8f
up_dumpstate: sp: 38002f88
up_dumpstate: User stack:
up_dumpstate: base: 38003008
up_dumpstate: size: 0000064c
up_dumpstate: used: 000003e0
up_stackdump: 38002f80: 00000010 080a269b 24012050 24012000 00000000
24012010 2400b430 00000000
up_stackdump: 38002fa0: 000000f0 00000080 00000000 00000000 00005ec8
0809d2e7 ffffffff ffffffff
up_stackdump: 38002fc0: 00005ec8 00000001 00000010 00020000 39276cac
2400b430 00000000 00000000
up_stackdump: 38002fe0: 00000000 00000000 00000000 00000000 00000000
0809c501 0809c4f1 0809bed5
up_stackdump: 38003000: 00000000 00000000 deadbeef 38003014 00000000
6f77706c de006b72 7b93d153
up_taskdump: Idle Task: PID=0 Stack Used=0 of 0
up_taskdump: hpwork: PID=1 Stack Used=352 of 2028
up_taskdump: lpwork: PID=2 Stack Used=992 of 1612
up_taskdump: init: PID=3 Stack Used=1544 of 2980
CONFIDENTIALITY NOTICE: This communication may contain private, confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please delete this e-mail and any attachments permanently.
RE: STM32H7 ethernet hardfaults
Posted by David Sidrane <Da...@nscdg.com>.
Hi James,
> Do you guys have any iperf numbers for UDP on H7?
No, I do not. But not that iperf is in apps, it should be easy to get.
David
-----Original Message-----
From: James Dougherty [mailto:jafrado@gmail.com]
Sent: Friday, March 05, 2021 9:45 AM
To: dev@nuttx.apache.org
Subject: Re: STM32H7 ethernet hardfaults
Wow, nice! Thank you guys!
David, nice description of the descriptors, it looks like zero padding is
being done by the MAC.
Do you guys have any iperf numbers for UDP on H7?
On Fri, Mar 5, 2021 at 7:15 AM John Rippetoe <jr...@roboticresearch.com>
wrote:
> Wow, that was fast David! Good find on the cache invalidation issue.
> I'll get your fix running on my board to verify the hard faults have
> been resolved.
>
> Thanks everyone for all of your input and help!
>
> - John
>
> On 3/5/21 9:11 AM, David Sidrane wrote:
> > PR is in. Please have a look and test with the default
> > CONFIG_NET_ETH_PKTSIZE. All should be happy now. :)
> >
> > https://github.com/apache/incubator-nuttx/pull/2985
> >
> > -----Original Message-----
> > From: David Sidrane [mailto:David.Sidrane@nscdg.com]
> > Sent: Friday, March 05, 2021 1:26 AM
> > To: 'dev@nuttx.apache.org'
> > Subject: RE: STM32H7 ethernet hardfaults
> >
> > Hi,
> >
> > Thank you all for sharing your Networking and dcache expertise!
> >
> > The descriptors and buffers are all aligned and sized for the dcache
> > line
> > size.
> >
> > The problem is the following. (The value of number do not matter, but
> help
> > express the nature of the problem.)
> >
> > If CONFIG_NET_ETH_PKTSIZE is the default 490 and a 1518 frame on the
> network
> > is received by the F7.
> >
> > The DMA HW will store the frame as n buffer sizes segments and one or 0
> > remainder sizes buffer.
> >
> > The following will happen:
> >
> > 490 becomes 608 after the sizing and alignment.
> >
> > DMA populates the buffers from the descriptors
> >
> > +>D0->B0(608) the FL is 1518 the d_len is set to 1514. FL from (FL bits
> in
> > RDES0[29:16]) - 4
> > | |
> > | V
> > | D1->B1(608)
> > | |
> > | V
> > | D2->B2(298)
> > | ....
> > | |
> > | V
> > <+Dn->Bn[]
> > ....
> >
> > From RM410: To compute the amount of valid data in this final buffer,
> the
> > driver must read the frame length (FL bits in RDES0[29:16]) and
> > subtract
> > the sum of the buffer sizes of the preceding buffers in this frame.
> >
> > But the code is invalidating from &B0[0] to &B0[1513]. If the buffers
> were
> > contiguous in memory this would be ok. But the buffers that are used in
> RX
> > are replaced (in the descriptors) from the free pool using the
> > g_txbuffer
> > memory.
> >
> > While at boot B0 to Bn are contiguous, they become scattered as a
> process of
> > receiving (the nature of the ring and replacement from the free pool)
> >
> > The ring:
> >
> > /* Scan descriptors owned by the CPU. Scan until:
> > *
> > * 1) We find a descriptor still owned by the DMA,
> > * 2) We have examined all of the RX descriptors, or
> > * 3) All of the TX descriptors are in flight.
> > *
> >
> > The replacement:
> >
> > buffer = stm32_allocbuffer(priv);
> > /* Take the buffer from the RX descriptor of the first
> free
> > * segment, put it into the network device structure,
> > then
> > * replace the buffer in the RX descriptor with the newly
> > * allocated buffer.
> > */
> > dev->d_buf = (uint8_t *)rxcurr->rdes2;
> > rxcurr->rdes2 = (uint32_t)buffer;
> >
> >
> > Eventually, B0 is allocated from one of the buffers in the g_txbuffer
> array.
> >
> >
> > Given this layout of memory low-high
> >
> > /* Descriptor allocations */
> >
> > g_rxtable[RXTABLE_SIZE]
> > g_txtable[TXTABLE_SIZE]
> >
> > /* Buffer allocations */
> >
> > g_rxbuffer[RXBUFFER_ALLOC]
> > g_txbuffer[TXBUFFER_ALLOC]
> >
> > /* These are the pre-allocated Ethernet device structures */
> >
> > stm32_ethmac_s g_stm32ethmac[STM32F7_NETHERNET];
> >
> > The dev->d_buf is an address in g_txbuffer. dev->d_len is the Frame
> Length
> > 1514 NOT the buffer length!
> >
> > The up_invalidate_dcache then corrupts the g_stm32ethmac. The result is
> > dev->d_buf and + dev->d_len are both 0.
> >
> > Context before the call to up_invalidate_dcache
> >
> > dev->d_buf = &g_txbuffer[n * (RXBUFFER_ALLOC/608)]
> > dev->d_len = 1514
> >
> > up_invalidate_dcache((uintptr_t)dev->d_buf,
> > (uintptr_t)dev->d_buf +
> dev->d_len);
> >
> > Context after the call to up_invalidate_dcache
> > dev->d_buf =0
> > dev->d_len = 0
> >
> >
> > This then returns OK and stm32_receive dereferences a null pointer and
> > places the null into the free pool.
> > The hard fault then happens.
> >
> > When the CONFIG_NET_ETH_PKTSIZE is 1514, the corruption does to happen
> > because sizeof FRAME == sizeof BUFFER
> >
> > (The system will still crash if the hardware can receive a bigger frame
> the
> > numbers are relaitve)
> >
> > The driver is not quite right, the code manages the segments but does
> > not
> > coalesce them back in to a frame. (memcpy with such a DMA is gross
> thought)
> > So the data RX data is useless to the network layer.
> >
> > If the network layers used IOB and could deal with on the fly assembly
> the
> > system would be most efficient. But that is a major undertaking.
> >
> > The goal now is to harden the driver.
> >
> > 1) Discard frames (all segments) grater then the size of one buffer.
> > 2) Fix the invalidation.
> >
> > David
> >
> >
> > -----Original Message-----
> > From: Gregory Nutt [mailto:spudaneco@gmail.com]
> > Sent: Thursday, March 04, 2021 5:01 PM
> > To: dev@nuttx.apache.org
> > Subject: Re: STM32H7 ethernet hardfaults
> >
> >
> >> My question for Greg was: Is there an assumption that
> >> CONFIG_NET_ETH_PKTSIZE
> >> has to be 1514? So that ultimately a frame must be received completely
> >> into
> >> one buffer?
> > Search for packet and frame in the Ethernet section of the reference
> > manual. The hardware will DMA up to (I think it was) 2048 bytes without
> > Jumbo mode. These are the 2K packets. This is for the H7 (and probably
> > the F7).
> >
> > However, that should not happen because nothing should ever send packets
> > that large to the station (and PROMISCUOUS mode should be disabled).
> >
> > From what you are saying, the packet buffer should also be aligned to
> > the cache line and be a multiple of the cache line size. So for an MTU
> > of X, I think that should be
> >
> > mask = Y - 1
> >
> > size = ( (X + 18) + mask) & ~mask
> >
> > buffer = memalign(Y, size);
> >
> > where
> >
> > * X is the MTU (like 1500). The MTU does not include the Ethernet
> > overhead.
> > * Y is the cache line size, usually 32.
> > * 18 is the Ethernet overhead (14 byte Ethernet header + 2 byte FCS
> > at
> > the end). The FCS is usually accounted for the the
> > CONFIG_GUARD_SIZE which defaults to 2. But some hardware transfers
> > additional info after the FCS.
> >
> > The 1514 packet size you mention may not be meaningful without some
> > clarification. The packet buffer size of 1518 is a 1500 byte MTU plus
> > the 18 byte Ethernet overhead. Some hardware verifies the FCS and does
> > not transfer it to memory ... that would make 1514. But that is not a
> > typical case.
> >
> > The selection of the MTU should not matter on most networks or with most
> > network hardware. TCP should follow the negotiated MSS and everything
> > else should be small. The MTU should be selected based on the
> > configured properties of the network, resources available in the target,
> > and the needs of the application
> >
> > IP size = Ethernet header + MTU + FCS
> >
> > = Ethernet header + IP header + protocol header + MSS +
> > FCS
> >
> > IPv4 hosts are required to be able to handle an MSS of at least 536
> > bytes; IPv6 hosts are required to be able to handle an MSS of 1220
> > bytes. This results in the minimum sizes and is correct.
> CONFIDENTIALITY NOTICE: This communication may contain private,
> confidential and privileged material for the sole use of the intended
> recipient. If you are not the intended recipient, please delete this
> e-mail
> and any attachments permanently.
>
>
Re: STM32H7 ethernet hardfaults
Posted by James Dougherty <ja...@gmail.com>.
Wow, nice! Thank you guys!
David, nice description of the descriptors, it looks like zero padding is
being done by the MAC.
Do you guys have any iperf numbers for UDP on H7?
On Fri, Mar 5, 2021 at 7:15 AM John Rippetoe <jr...@roboticresearch.com>
wrote:
> Wow, that was fast David! Good find on the cache invalidation issue.
> I'll get your fix running on my board to verify the hard faults have
> been resolved.
>
> Thanks everyone for all of your input and help!
>
> - John
>
> On 3/5/21 9:11 AM, David Sidrane wrote:
> > PR is in. Please have a look and test with the default
> > CONFIG_NET_ETH_PKTSIZE. All should be happy now. :)
> >
> > https://github.com/apache/incubator-nuttx/pull/2985
> >
> > -----Original Message-----
> > From: David Sidrane [mailto:David.Sidrane@nscdg.com]
> > Sent: Friday, March 05, 2021 1:26 AM
> > To: 'dev@nuttx.apache.org'
> > Subject: RE: STM32H7 ethernet hardfaults
> >
> > Hi,
> >
> > Thank you all for sharing your Networking and dcache expertise!
> >
> > The descriptors and buffers are all aligned and sized for the dcache line
> > size.
> >
> > The problem is the following. (The value of number do not matter, but
> help
> > express the nature of the problem.)
> >
> > If CONFIG_NET_ETH_PKTSIZE is the default 490 and a 1518 frame on the
> network
> > is received by the F7.
> >
> > The DMA HW will store the frame as n buffer sizes segments and one or 0
> > remainder sizes buffer.
> >
> > The following will happen:
> >
> > 490 becomes 608 after the sizing and alignment.
> >
> > DMA populates the buffers from the descriptors
> >
> > +>D0->B0(608) the FL is 1518 the d_len is set to 1514. FL from (FL bits
> in
> > RDES0[29:16]) - 4
> > | |
> > | V
> > | D1->B1(608)
> > | |
> > | V
> > | D2->B2(298)
> > | ....
> > | |
> > | V
> > <+Dn->Bn[]
> > ....
> >
> > From RM410: To compute the amount of valid data in this final buffer,
> the
> > driver must read the frame length (FL bits in RDES0[29:16]) and subtract
> > the sum of the buffer sizes of the preceding buffers in this frame.
> >
> > But the code is invalidating from &B0[0] to &B0[1513]. If the buffers
> were
> > contiguous in memory this would be ok. But the buffers that are used in
> RX
> > are replaced (in the descriptors) from the free pool using the g_txbuffer
> > memory.
> >
> > While at boot B0 to Bn are contiguous, they become scattered as a
> process of
> > receiving (the nature of the ring and replacement from the free pool)
> >
> > The ring:
> >
> > /* Scan descriptors owned by the CPU. Scan until:
> > *
> > * 1) We find a descriptor still owned by the DMA,
> > * 2) We have examined all of the RX descriptors, or
> > * 3) All of the TX descriptors are in flight.
> > *
> >
> > The replacement:
> >
> > buffer = stm32_allocbuffer(priv);
> > /* Take the buffer from the RX descriptor of the first
> free
> > * segment, put it into the network device structure, then
> > * replace the buffer in the RX descriptor with the newly
> > * allocated buffer.
> > */
> > dev->d_buf = (uint8_t *)rxcurr->rdes2;
> > rxcurr->rdes2 = (uint32_t)buffer;
> >
> >
> > Eventually, B0 is allocated from one of the buffers in the g_txbuffer
> array.
> >
> >
> > Given this layout of memory low-high
> >
> > /* Descriptor allocations */
> >
> > g_rxtable[RXTABLE_SIZE]
> > g_txtable[TXTABLE_SIZE]
> >
> > /* Buffer allocations */
> >
> > g_rxbuffer[RXBUFFER_ALLOC]
> > g_txbuffer[TXBUFFER_ALLOC]
> >
> > /* These are the pre-allocated Ethernet device structures */
> >
> > stm32_ethmac_s g_stm32ethmac[STM32F7_NETHERNET];
> >
> > The dev->d_buf is an address in g_txbuffer. dev->d_len is the Frame
> Length
> > 1514 NOT the buffer length!
> >
> > The up_invalidate_dcache then corrupts the g_stm32ethmac. The result is
> > dev->d_buf and + dev->d_len are both 0.
> >
> > Context before the call to up_invalidate_dcache
> >
> > dev->d_buf = &g_txbuffer[n * (RXBUFFER_ALLOC/608)]
> > dev->d_len = 1514
> >
> > up_invalidate_dcache((uintptr_t)dev->d_buf,
> > (uintptr_t)dev->d_buf +
> dev->d_len);
> >
> > Context after the call to up_invalidate_dcache
> > dev->d_buf =0
> > dev->d_len = 0
> >
> >
> > This then returns OK and stm32_receive dereferences a null pointer and
> > places the null into the free pool.
> > The hard fault then happens.
> >
> > When the CONFIG_NET_ETH_PKTSIZE is 1514, the corruption does to happen
> > because sizeof FRAME == sizeof BUFFER
> >
> > (The system will still crash if the hardware can receive a bigger frame
> the
> > numbers are relaitve)
> >
> > The driver is not quite right, the code manages the segments but does not
> > coalesce them back in to a frame. (memcpy with such a DMA is gross
> thought)
> > So the data RX data is useless to the network layer.
> >
> > If the network layers used IOB and could deal with on the fly assembly
> the
> > system would be most efficient. But that is a major undertaking.
> >
> > The goal now is to harden the driver.
> >
> > 1) Discard frames (all segments) grater then the size of one buffer.
> > 2) Fix the invalidation.
> >
> > David
> >
> >
> > -----Original Message-----
> > From: Gregory Nutt [mailto:spudaneco@gmail.com]
> > Sent: Thursday, March 04, 2021 5:01 PM
> > To: dev@nuttx.apache.org
> > Subject: Re: STM32H7 ethernet hardfaults
> >
> >
> >> My question for Greg was: Is there an assumption that
> >> CONFIG_NET_ETH_PKTSIZE
> >> has to be 1514? So that ultimately a frame must be received completely
> >> into
> >> one buffer?
> > Search for packet and frame in the Ethernet section of the reference
> > manual. The hardware will DMA up to (I think it was) 2048 bytes without
> > Jumbo mode. These are the 2K packets. This is for the H7 (and probably
> > the F7).
> >
> > However, that should not happen because nothing should ever send packets
> > that large to the station (and PROMISCUOUS mode should be disabled).
> >
> > From what you are saying, the packet buffer should also be aligned to
> > the cache line and be a multiple of the cache line size. So for an MTU
> > of X, I think that should be
> >
> > mask = Y - 1
> >
> > size = ( (X + 18) + mask) & ~mask
> >
> > buffer = memalign(Y, size);
> >
> > where
> >
> > * X is the MTU (like 1500). The MTU does not include the Ethernet
> > overhead.
> > * Y is the cache line size, usually 32.
> > * 18 is the Ethernet overhead (14 byte Ethernet header + 2 byte FCS at
> > the end). The FCS is usually accounted for the the
> > CONFIG_GUARD_SIZE which defaults to 2. But some hardware transfers
> > additional info after the FCS.
> >
> > The 1514 packet size you mention may not be meaningful without some
> > clarification. The packet buffer size of 1518 is a 1500 byte MTU plus
> > the 18 byte Ethernet overhead. Some hardware verifies the FCS and does
> > not transfer it to memory ... that would make 1514. But that is not a
> > typical case.
> >
> > The selection of the MTU should not matter on most networks or with most
> > network hardware. TCP should follow the negotiated MSS and everything
> > else should be small. The MTU should be selected based on the
> > configured properties of the network, resources available in the target,
> > and the needs of the application
> >
> > IP size = Ethernet header + MTU + FCS
> >
> > = Ethernet header + IP header + protocol header + MSS + FCS
> >
> > IPv4 hosts are required to be able to handle an MSS of at least 536
> > bytes; IPv6 hosts are required to be able to handle an MSS of 1220
> > bytes. This results in the minimum sizes and is correct.
> CONFIDENTIALITY NOTICE: This communication may contain private,
> confidential and privileged material for the sole use of the intended
> recipient. If you are not the intended recipient, please delete this e-mail
> and any attachments permanently.
>
>
Re: STM32H7 ethernet hardfaults
Posted by John Rippetoe <jr...@roboticresearch.com>.
Wow, that was fast David! Good find on the cache invalidation issue.
I'll get your fix running on my board to verify the hard faults have
been resolved.
Thanks everyone for all of your input and help!
- John
On 3/5/21 9:11 AM, David Sidrane wrote:
> PR is in. Please have a look and test with the default
> CONFIG_NET_ETH_PKTSIZE. All should be happy now. :)
>
> https://github.com/apache/incubator-nuttx/pull/2985
>
> -----Original Message-----
> From: David Sidrane [mailto:David.Sidrane@nscdg.com]
> Sent: Friday, March 05, 2021 1:26 AM
> To: 'dev@nuttx.apache.org'
> Subject: RE: STM32H7 ethernet hardfaults
>
> Hi,
>
> Thank you all for sharing your Networking and dcache expertise!
>
> The descriptors and buffers are all aligned and sized for the dcache line
> size.
>
> The problem is the following. (The value of number do not matter, but help
> express the nature of the problem.)
>
> If CONFIG_NET_ETH_PKTSIZE is the default 490 and a 1518 frame on the network
> is received by the F7.
>
> The DMA HW will store the frame as n buffer sizes segments and one or 0
> remainder sizes buffer.
>
> The following will happen:
>
> 490 becomes 608 after the sizing and alignment.
>
> DMA populates the buffers from the descriptors
>
> +>D0->B0(608) the FL is 1518 the d_len is set to 1514. FL from (FL bits in
> RDES0[29:16]) - 4
> | |
> | V
> | D1->B1(608)
> | |
> | V
> | D2->B2(298)
> | ....
> | |
> | V
> <+Dn->Bn[]
> ....
>
> From RM410: To compute the amount of valid data in this final buffer, the
> driver must read the frame length (FL bits in RDES0[29:16]) and subtract
> the sum of the buffer sizes of the preceding buffers in this frame.
>
> But the code is invalidating from &B0[0] to &B0[1513]. If the buffers were
> contiguous in memory this would be ok. But the buffers that are used in RX
> are replaced (in the descriptors) from the free pool using the g_txbuffer
> memory.
>
> While at boot B0 to Bn are contiguous, they become scattered as a process of
> receiving (the nature of the ring and replacement from the free pool)
>
> The ring:
>
> /* Scan descriptors owned by the CPU. Scan until:
> *
> * 1) We find a descriptor still owned by the DMA,
> * 2) We have examined all of the RX descriptors, or
> * 3) All of the TX descriptors are in flight.
> *
>
> The replacement:
>
> buffer = stm32_allocbuffer(priv);
> /* Take the buffer from the RX descriptor of the first free
> * segment, put it into the network device structure, then
> * replace the buffer in the RX descriptor with the newly
> * allocated buffer.
> */
> dev->d_buf = (uint8_t *)rxcurr->rdes2;
> rxcurr->rdes2 = (uint32_t)buffer;
>
>
> Eventually, B0 is allocated from one of the buffers in the g_txbuffer array.
>
>
> Given this layout of memory low-high
>
> /* Descriptor allocations */
>
> g_rxtable[RXTABLE_SIZE]
> g_txtable[TXTABLE_SIZE]
>
> /* Buffer allocations */
>
> g_rxbuffer[RXBUFFER_ALLOC]
> g_txbuffer[TXBUFFER_ALLOC]
>
> /* These are the pre-allocated Ethernet device structures */
>
> stm32_ethmac_s g_stm32ethmac[STM32F7_NETHERNET];
>
> The dev->d_buf is an address in g_txbuffer. dev->d_len is the Frame Length
> 1514 NOT the buffer length!
>
> The up_invalidate_dcache then corrupts the g_stm32ethmac. The result is
> dev->d_buf and + dev->d_len are both 0.
>
> Context before the call to up_invalidate_dcache
>
> dev->d_buf = &g_txbuffer[n * (RXBUFFER_ALLOC/608)]
> dev->d_len = 1514
>
> up_invalidate_dcache((uintptr_t)dev->d_buf,
> (uintptr_t)dev->d_buf + dev->d_len);
>
> Context after the call to up_invalidate_dcache
> dev->d_buf =0
> dev->d_len = 0
>
>
> This then returns OK and stm32_receive dereferences a null pointer and
> places the null into the free pool.
> The hard fault then happens.
>
> When the CONFIG_NET_ETH_PKTSIZE is 1514, the corruption does to happen
> because sizeof FRAME == sizeof BUFFER
>
> (The system will still crash if the hardware can receive a bigger frame the
> numbers are relaitve)
>
> The driver is not quite right, the code manages the segments but does not
> coalesce them back in to a frame. (memcpy with such a DMA is gross thought)
> So the data RX data is useless to the network layer.
>
> If the network layers used IOB and could deal with on the fly assembly the
> system would be most efficient. But that is a major undertaking.
>
> The goal now is to harden the driver.
>
> 1) Discard frames (all segments) grater then the size of one buffer.
> 2) Fix the invalidation.
>
> David
>
>
> -----Original Message-----
> From: Gregory Nutt [mailto:spudaneco@gmail.com]
> Sent: Thursday, March 04, 2021 5:01 PM
> To: dev@nuttx.apache.org
> Subject: Re: STM32H7 ethernet hardfaults
>
>
>> My question for Greg was: Is there an assumption that
>> CONFIG_NET_ETH_PKTSIZE
>> has to be 1514? So that ultimately a frame must be received completely
>> into
>> one buffer?
> Search for packet and frame in the Ethernet section of the reference
> manual. The hardware will DMA up to (I think it was) 2048 bytes without
> Jumbo mode. These are the 2K packets. This is for the H7 (and probably
> the F7).
>
> However, that should not happen because nothing should ever send packets
> that large to the station (and PROMISCUOUS mode should be disabled).
>
> From what you are saying, the packet buffer should also be aligned to
> the cache line and be a multiple of the cache line size. So for an MTU
> of X, I think that should be
>
> mask = Y - 1
>
> size = ( (X + 18) + mask) & ~mask
>
> buffer = memalign(Y, size);
>
> where
>
> * X is the MTU (like 1500). The MTU does not include the Ethernet
> overhead.
> * Y is the cache line size, usually 32.
> * 18 is the Ethernet overhead (14 byte Ethernet header + 2 byte FCS at
> the end). The FCS is usually accounted for the the
> CONFIG_GUARD_SIZE which defaults to 2. But some hardware transfers
> additional info after the FCS.
>
> The 1514 packet size you mention may not be meaningful without some
> clarification. The packet buffer size of 1518 is a 1500 byte MTU plus
> the 18 byte Ethernet overhead. Some hardware verifies the FCS and does
> not transfer it to memory ... that would make 1514. But that is not a
> typical case.
>
> The selection of the MTU should not matter on most networks or with most
> network hardware. TCP should follow the negotiated MSS and everything
> else should be small. The MTU should be selected based on the
> configured properties of the network, resources available in the target,
> and the needs of the application
>
> IP size = Ethernet header + MTU + FCS
>
> = Ethernet header + IP header + protocol header + MSS + FCS
>
> IPv4 hosts are required to be able to handle an MSS of at least 536
> bytes; IPv6 hosts are required to be able to handle an MSS of 1220
> bytes. This results in the minimum sizes and is correct.
CONFIDENTIALITY NOTICE: This communication may contain private, confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please delete this e-mail and any attachments permanently.
RE: STM32H7 ethernet hardfaults
Posted by David Sidrane <Da...@nscdg.com>.
PR is in. Please have a look and test with the default
CONFIG_NET_ETH_PKTSIZE. All should be happy now. :)
https://github.com/apache/incubator-nuttx/pull/2985
-----Original Message-----
From: David Sidrane [mailto:David.Sidrane@nscdg.com]
Sent: Friday, March 05, 2021 1:26 AM
To: 'dev@nuttx.apache.org'
Subject: RE: STM32H7 ethernet hardfaults
Hi,
Thank you all for sharing your Networking and dcache expertise!
The descriptors and buffers are all aligned and sized for the dcache line
size.
The problem is the following. (The value of number do not matter, but help
express the nature of the problem.)
If CONFIG_NET_ETH_PKTSIZE is the default 490 and a 1518 frame on the network
is received by the F7.
The DMA HW will store the frame as n buffer sizes segments and one or 0
remainder sizes buffer.
The following will happen:
490 becomes 608 after the sizing and alignment.
DMA populates the buffers from the descriptors
+>D0->B0(608) the FL is 1518 the d_len is set to 1514. FL from (FL bits in
RDES0[29:16]) - 4
| |
| V
| D1->B1(608)
| |
| V
| D2->B2(298)
| ....
| |
| V
<+Dn->Bn[]
....
From RM410: To compute the amount of valid data in this final buffer, the
driver must read the frame length (FL bits in RDES0[29:16]) and subtract
the sum of the buffer sizes of the preceding buffers in this frame.
But the code is invalidating from &B0[0] to &B0[1513]. If the buffers were
contiguous in memory this would be ok. But the buffers that are used in RX
are replaced (in the descriptors) from the free pool using the g_txbuffer
memory.
While at boot B0 to Bn are contiguous, they become scattered as a process of
receiving (the nature of the ring and replacement from the free pool)
The ring:
/* Scan descriptors owned by the CPU. Scan until:
*
* 1) We find a descriptor still owned by the DMA,
* 2) We have examined all of the RX descriptors, or
* 3) All of the TX descriptors are in flight.
*
The replacement:
buffer = stm32_allocbuffer(priv);
/* Take the buffer from the RX descriptor of the first free
* segment, put it into the network device structure, then
* replace the buffer in the RX descriptor with the newly
* allocated buffer.
*/
dev->d_buf = (uint8_t *)rxcurr->rdes2;
rxcurr->rdes2 = (uint32_t)buffer;
Eventually, B0 is allocated from one of the buffers in the g_txbuffer array.
Given this layout of memory low-high
/* Descriptor allocations */
g_rxtable[RXTABLE_SIZE]
g_txtable[TXTABLE_SIZE]
/* Buffer allocations */
g_rxbuffer[RXBUFFER_ALLOC]
g_txbuffer[TXBUFFER_ALLOC]
/* These are the pre-allocated Ethernet device structures */
stm32_ethmac_s g_stm32ethmac[STM32F7_NETHERNET];
The dev->d_buf is an address in g_txbuffer. dev->d_len is the Frame Length
1514 NOT the buffer length!
The up_invalidate_dcache then corrupts the g_stm32ethmac. The result is
dev->d_buf and + dev->d_len are both 0.
Context before the call to up_invalidate_dcache
dev->d_buf = &g_txbuffer[n * (RXBUFFER_ALLOC/608)]
dev->d_len = 1514
up_invalidate_dcache((uintptr_t)dev->d_buf,
(uintptr_t)dev->d_buf + dev->d_len);
Context after the call to up_invalidate_dcache
dev->d_buf =0
dev->d_len = 0
This then returns OK and stm32_receive dereferences a null pointer and
places the null into the free pool.
The hard fault then happens.
When the CONFIG_NET_ETH_PKTSIZE is 1514, the corruption does to happen
because sizeof FRAME == sizeof BUFFER
(The system will still crash if the hardware can receive a bigger frame the
numbers are relaitve)
The driver is not quite right, the code manages the segments but does not
coalesce them back in to a frame. (memcpy with such a DMA is gross thought)
So the data RX data is useless to the network layer.
If the network layers used IOB and could deal with on the fly assembly the
system would be most efficient. But that is a major undertaking.
The goal now is to harden the driver.
1) Discard frames (all segments) grater then the size of one buffer.
2) Fix the invalidation.
David
-----Original Message-----
From: Gregory Nutt [mailto:spudaneco@gmail.com]
Sent: Thursday, March 04, 2021 5:01 PM
To: dev@nuttx.apache.org
Subject: Re: STM32H7 ethernet hardfaults
> My question for Greg was: Is there an assumption that
> CONFIG_NET_ETH_PKTSIZE
> has to be 1514? So that ultimately a frame must be received completely
> into
> one buffer?
Search for packet and frame in the Ethernet section of the reference
manual. The hardware will DMA up to (I think it was) 2048 bytes without
Jumbo mode. These are the 2K packets. This is for the H7 (and probably
the F7).
However, that should not happen because nothing should ever send packets
that large to the station (and PROMISCUOUS mode should be disabled).
From what you are saying, the packet buffer should also be aligned to
the cache line and be a multiple of the cache line size. So for an MTU
of X, I think that should be
mask = Y - 1
size = ( (X + 18) + mask) & ~mask
buffer = memalign(Y, size);
where
* X is the MTU (like 1500). The MTU does not include the Ethernet
overhead.
* Y is the cache line size, usually 32.
* 18 is the Ethernet overhead (14 byte Ethernet header + 2 byte FCS at
the end). The FCS is usually accounted for the the
CONFIG_GUARD_SIZE which defaults to 2. But some hardware transfers
additional info after the FCS.
The 1514 packet size you mention may not be meaningful without some
clarification. The packet buffer size of 1518 is a 1500 byte MTU plus
the 18 byte Ethernet overhead. Some hardware verifies the FCS and does
not transfer it to memory ... that would make 1514. But that is not a
typical case.
The selection of the MTU should not matter on most networks or with most
network hardware. TCP should follow the negotiated MSS and everything
else should be small. The MTU should be selected based on the
configured properties of the network, resources available in the target,
and the needs of the application
IP size = Ethernet header + MTU + FCS
= Ethernet header + IP header + protocol header + MSS + FCS
IPv4 hosts are required to be able to handle an MSS of at least 536
bytes; IPv6 hosts are required to be able to handle an MSS of 1220
bytes. This results in the minimum sizes and is correct.
RE: STM32H7 ethernet hardfaults
Posted by David Sidrane <Da...@nscdg.com>.
Hi,
Thank you all for sharing your Networking and dcache expertise!
The descriptors and buffers are all aligned and sized for the dcache line
size.
The problem is the following. (The value of number do not matter, but help
express the nature of the problem.)
If CONFIG_NET_ETH_PKTSIZE is the default 490 and a 1518 frame on the network
is received by the F7.
The DMA HW will store the frame as n buffer sizes segments and one or 0
remainder sizes buffer.
The following will happen:
490 becomes 608 after the sizing and alignment.
DMA populates the buffers from the descriptors
+>D0->B0(608) the FL is 1518 the d_len is set to 1514. FL from (FL bits in
RDES0[29:16]) - 4
| |
| V
| D1->B1(608)
| |
| V
| D2->B2(298)
| ....
| |
| V
<+Dn->Bn[]
....
From RM410: To compute the amount of valid data in this final buffer, the
driver must read the frame length (FL bits in RDES0[29:16]) and subtract
the sum of the buffer sizes of the preceding buffers in this frame.
But the code is invalidating from &B0[0] to &B0[1513]. If the buffers were
contiguous in memory this would be ok. But the buffers that are used in RX
are replaced (in the descriptors) from the free pool using the g_txbuffer
memory.
While at boot B0 to Bn are contiguous, they become scattered as a process of
receiving (the nature of the ring and replacement from the free pool)
The ring:
/* Scan descriptors owned by the CPU. Scan until:
*
* 1) We find a descriptor still owned by the DMA,
* 2) We have examined all of the RX descriptors, or
* 3) All of the TX descriptors are in flight.
*
The replacement:
buffer = stm32_allocbuffer(priv);
/* Take the buffer from the RX descriptor of the first free
* segment, put it into the network device structure, then
* replace the buffer in the RX descriptor with the newly
* allocated buffer.
*/
dev->d_buf = (uint8_t *)rxcurr->rdes2;
rxcurr->rdes2 = (uint32_t)buffer;
Eventually, B0 is allocated from one of the buffers in the g_txbuffer array.
Given this layout of memory low-high
/* Descriptor allocations */
g_rxtable[RXTABLE_SIZE]
g_txtable[TXTABLE_SIZE]
/* Buffer allocations */
g_rxbuffer[RXBUFFER_ALLOC]
g_txbuffer[TXBUFFER_ALLOC]
/* These are the pre-allocated Ethernet device structures */
stm32_ethmac_s g_stm32ethmac[STM32F7_NETHERNET];
The dev->d_buf is an address in g_txbuffer. dev->d_len is the Frame Length
1514 NOT the buffer length!
The up_invalidate_dcache then corrupts the g_stm32ethmac. The result is
dev->d_buf and + dev->d_len are both 0.
Context before the call to up_invalidate_dcache
dev->d_buf = &g_txbuffer[n * (RXBUFFER_ALLOC/608)]
dev->d_len = 1514
up_invalidate_dcache((uintptr_t)dev->d_buf,
(uintptr_t)dev->d_buf + dev->d_len);
Context after the call to up_invalidate_dcache
dev->d_buf =0
dev->d_len = 0
This then returns OK and stm32_receive dereferences a null pointer and
places the null into the free pool.
The hard fault then happens.
When the CONFIG_NET_ETH_PKTSIZE is 1514, the corruption does to happen
because sizeof FRAME == sizeof BUFFER
(The system will still crash if the hardware can receive a bigger frame the
numbers are relaitve)
The driver is not quite right, the code manages the segments but does not
coalesce them back in to a frame. (memcpy with such a DMA is gross thought)
So the data RX data is useless to the network layer.
If the network layers used IOB and could deal with on the fly assembly the
system would be most efficient. But that is a major undertaking.
The goal now is to harden the driver.
1) Discard frames (all segments) grater then the size of one buffer.
2) Fix the invalidation.
David
-----Original Message-----
From: Gregory Nutt [mailto:spudaneco@gmail.com]
Sent: Thursday, March 04, 2021 5:01 PM
To: dev@nuttx.apache.org
Subject: Re: STM32H7 ethernet hardfaults
> My question for Greg was: Is there an assumption that
> CONFIG_NET_ETH_PKTSIZE
> has to be 1514? So that ultimately a frame must be received completely
> into
> one buffer?
Search for packet and frame in the Ethernet section of the reference
manual. The hardware will DMA up to (I think it was) 2048 bytes without
Jumbo mode. These are the 2K packets. This is for the H7 (and probably
the F7).
However, that should not happen because nothing should ever send packets
that large to the station (and PROMISCUOUS mode should be disabled).
From what you are saying, the packet buffer should also be aligned to
the cache line and be a multiple of the cache line size. So for an MTU
of X, I think that should be
mask = Y - 1
size = ( (X + 18) + mask) & ~mask
buffer = memalign(Y, size);
where
* X is the MTU (like 1500). The MTU does not include the Ethernet
overhead.
* Y is the cache line size, usually 32.
* 18 is the Ethernet overhead (14 byte Ethernet header + 2 byte FCS at
the end). The FCS is usually accounted for the the
CONFIG_GUARD_SIZE which defaults to 2. But some hardware transfers
additional info after the FCS.
The 1514 packet size you mention may not be meaningful without some
clarification. The packet buffer size of 1518 is a 1500 byte MTU plus
the 18 byte Ethernet overhead. Some hardware verifies the FCS and does
not transfer it to memory ... that would make 1514. But that is not a
typical case.
The selection of the MTU should not matter on most networks or with most
network hardware. TCP should follow the negotiated MSS and everything
else should be small. The MTU should be selected based on the
configured properties of the network, resources available in the target,
and the needs of the application
IP size = Ethernet header + MTU + FCS
= Ethernet header + IP header + protocol header + MSS + FCS
IPv4 hosts are required to be able to handle an MSS of at least 536
bytes; IPv6 hosts are required to be able to handle an MSS of 1220
bytes. This results in the minimum sizes and is correct.
Re: STM32H7 ethernet hardfaults
Posted by Gregory Nutt <sp...@gmail.com>.
> My question for Greg was: Is there an assumption that CONFIG_NET_ETH_PKTSIZE
> has to be 1514? So that ultimately a frame must be received completely into
> one buffer?
Search for packet and frame in the Ethernet section of the reference
manual. The hardware will DMA up to (I think it was) 2048 bytes without
Jumbo mode. These are the 2K packets. This is for the H7 (and probably
the F7).
However, that should not happen because nothing should ever send packets
that large to the station (and PROMISCUOUS mode should be disabled).
From what you are saying, the packet buffer should also be aligned to
the cache line and be a multiple of the cache line size. So for an MTU
of X, I think that should be
mask = Y - 1
size = ( (X + 18) + mask) & ~mask
buffer = memalign(Y, size);
where
* X is the MTU (like 1500). The MTU does not include the Ethernet
overhead.
* Y is the cache line size, usually 32.
* 18 is the Ethernet overhead (14 byte Ethernet header + 2 byte FCS at
the end). The FCS is usually accounted for the the
CONFIG_GUARD_SIZE which defaults to 2. But some hardware transfers
additional info after the FCS.
The 1514 packet size you mention may not be meaningful without some
clarification. The packet buffer size of 1518 is a 1500 byte MTU plus
the 18 byte Ethernet overhead. Some hardware verifies the FCS and does
not transfer it to memory ... that would make 1514. But that is not a
typical case.
The selection of the MTU should not matter on most networks or with most
network hardware. TCP should follow the negotiated MSS and everything
else should be small. The MTU should be selected based on the
configured properties of the network, resources available in the target,
and the needs of the application
IP size = Ethernet header + MTU + FCS
= Ethernet header + IP header + protocol header + MSS + FCS
IPv4 hosts are required to be able to handle an MSS of at least 536
bytes; IPv6 hosts are required to be able to handle an MSS of 1220
bytes. This results in the minimum sizes and is correct.
RE: STM32H7 ethernet hardfaults
Posted by David Sidrane <Da...@nscdg.com>.
Hi John,
Jinx you owe me a soda! I am just debugging this same thing today.
This is happening on the F7 as well. It is a bug, in this line.
up_invalidate_dcache((uintptr_t)dev->d_buf,
(uintptr_t)dev->d_buf + dev->d_len);
It in performs cache invalidation using the Frame length (1514) from the
descriptor and not the actual length of the buffer (590) moreover the
segment buffers are not necessarily contiguous in memory.
This corrupts g_stm32ethmac. And sets the d_buf and d_len to 0, that cause
that fault downstream.
My question for Greg was: Is there an assumption that CONFIG_NET_ETH_PKTSIZE
has to be 1514? So that ultimately a frame must be received completely into
one buffer?
There is no segmentation reassembly in the code. So I will do a pr to drop
what does not fit and do the invalidation on min(BUFFSIZE, dev->d_len);
David
-----Original Message-----
From: John Rippetoe [mailto:jrippetoe@roboticresearch.com]
Sent: Thursday, March 04, 2021 12:46 PM
To: dev@nuttx.apache.org
Subject: STM32H7 ethernet hardfaults
Hello All,
I've been playing around with networking on the STM32H7 and am seeing
hardfaults that appear to be related to NET_ETH_PKTSIZE. From the log
below, the driver would appear to be dropping packets that are too large
to fit into the default packet size of 590. By increasing the packet
size to the max (1518), the problem seems to disappear, but I am a
little confused why the driver is able to catch the fact that the
received packet was too large and drop it appropriately, but then crash.
After poking around the ethernet driver, I think I understand the issue
to be that because the MAC DMA does not know that the buffer it is
writing into has a size limit, it is overflowing the buffer and writing
into adjacent memory. Am I understanding this correctly?
My main concern here is that increasing NET_ETH_PKTSIZE to the limit
will only hide the issue for a time instead of solving it. A quick
google search does show that the maximum ethernet frame size is 1518
bytes though, so I am working under the assumption that maxing it out in
my config will account for all possible frame sizes and eliminate this
issue. I have no experience with low level networking protocols and
standards, so I thought it would be prudent to seek out additional help
to make sure I am on the right track.
Thanks in advance.
- John
stm32_receive: WARNING: DROPPED Too big: 684
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
stm32_receive: WARNING: DROPPED Too big: 1332
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
stm32_receive: WARNING: DROPPED Too big: 1264
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
stm32_receive: WARNING: DROPPED Too big: 684
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
stm32_receive: WARNING: DROPPED Too big: 1364
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
stm32_receive: WARNING: DROPPED Too big: 1264
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
stm32_receive: WARNING: DROPPED Too big: 1436
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
stm32_receive: WARNING: DROPPED Too big: 1300
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
up_hardfault: PANIC!!! Hard fault: 40000000
up_assert: Assertion failed at file:armv7-m/up_hardfault.c line: 148
task: lpwork
up_registerdump: R0: 24012080 2401206e 0000024e 00000000 24012000
40029160 24011fc0 00008040
up_registerdump: R8: 40029134 24011f00 24011fe0 240120b8 00000001
38002f88 080a26a7 080a2538
up_registerdump: xPSR: 81000000 BASEPRI: 000000f0 CONTROL: 00000000
up_registerdump: EXC_RETURN: ffffffe9
up_dumpstate: sp: 24010bb0
up_dumpstate: IRQ stack:
up_dumpstate: base: 24010c00
up_dumpstate: size: 00000200
up_dumpstate: used: 00000140
up_stackdump: 24010ba0: 24010bb0 2400e830 0000064c 080a0fed 000000f0
00000000 240120b8 00000001
up_stackdump: 24010bc0: 38002f88 080a26a7 080a2538 0816625a 00000000
080a129f 080a1271 080f754f
up_stackdump: 24010be0: 000000f0 080a2935 000000f0 38002eb4 40029160
24011fc0 00008040 080a1b8f
up_dumpstate: sp: 38002f88
up_dumpstate: User stack:
up_dumpstate: base: 38003008
up_dumpstate: size: 0000064c
up_dumpstate: used: 000003e0
up_stackdump: 38002f80: 00000010 080a269b 24012050 24012000 00000000
24012010 2400b430 00000000
up_stackdump: 38002fa0: 000000f0 00000080 00000000 00000000 00005ec8
0809d2e7 ffffffff ffffffff
up_stackdump: 38002fc0: 00005ec8 00000001 00000010 00020000 39276cac
2400b430 00000000 00000000
up_stackdump: 38002fe0: 00000000 00000000 00000000 00000000 00000000
0809c501 0809c4f1 0809bed5
up_stackdump: 38003000: 00000000 00000000 deadbeef 38003014 00000000
6f77706c de006b72 7b93d153
up_taskdump: Idle Task: PID=0 Stack Used=0 of 0
up_taskdump: hpwork: PID=1 Stack Used=352 of 2028
up_taskdump: lpwork: PID=2 Stack Used=992 of 1612
up_taskdump: init: PID=3 Stack Used=1544 of 2980
CONFIDENTIALITY NOTICE: This communication may contain private, confidential
and privileged material for the sole use of the intended recipient. If you
are not the intended recipient, please delete this e-mail and any
attachments permanently.
Re: STM32H7 ethernet hardfaults
Posted by Gregory Nutt <sp...@gmail.com>.
Disabling DMA is not a option on most Ethernet MACs.
On 3/4/2021 3:00 PM, Alan Carvalho de Assis wrote:
> Hi John,
>
> Did you try to disable DMA support to see if the issue disappear?
>
> I think other MCUs are using DMA for Ethernet too and this issue
> didn't happen. So I think disabling DMA could be a valid test to find
> out the root causes.
>
> BR,
>
> Alan
>
> On 3/4/21, John Rippetoe <jr...@roboticresearch.com> wrote:
>> Hello All,
>>
>> I've been playing around with networking on the STM32H7 and am seeing
>> hardfaults that appear to be related to NET_ETH_PKTSIZE. From the log
>> below, the driver would appear to be dropping packets that are too large
>> to fit into the default packet size of 590. By increasing the packet
>> size to the max (1518), the problem seems to disappear, but I am a
>> little confused why the driver is able to catch the fact that the
>> received packet was too large and drop it appropriately, but then crash.
>> After poking around the ethernet driver, I think I understand the issue
>> to be that because the MAC DMA does not know that the buffer it is
>> writing into has a size limit, it is overflowing the buffer and writing
>> into adjacent memory. Am I understanding this correctly?
>>
>> My main concern here is that increasing NET_ETH_PKTSIZE to the limit
>> will only hide the issue for a time instead of solving it. A quick
>> google search does show that the maximum ethernet frame size is 1518
>> bytes though, so I am working under the assumption that maxing it out in
>> my config will account for all possible frame sizes and eliminate this
>> issue. I have no experience with low level networking protocols and
>> standards, so I thought it would be prudent to seek out additional help
>> to make sure I am on the right track.
>>
>> Thanks in advance.
>>
>> - John
>>
>> stm32_receive: WARNING: DROPPED Too big: 684
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> stm32_receive: WARNING: DROPPED Too big: 1332
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> stm32_receive: WARNING: DROPPED Too big: 1264
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> stm32_receive: WARNING: DROPPED Too big: 684
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> stm32_receive: WARNING: DROPPED Too big: 1364
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> stm32_receive: WARNING: DROPPED Too big: 1264
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> stm32_receive: WARNING: DROPPED Too big: 1436
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> stm32_receive: WARNING: DROPPED Too big: 1300
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> up_hardfault: PANIC!!! Hard fault: 40000000
>> up_assert: Assertion failed at file:armv7-m/up_hardfault.c line: 148
>> task: lpwork
>> up_registerdump: R0: 24012080 2401206e 0000024e 00000000 24012000
>> 40029160 24011fc0 00008040
>> up_registerdump: R8: 40029134 24011f00 24011fe0 240120b8 00000001
>> 38002f88 080a26a7 080a2538
>> up_registerdump: xPSR: 81000000 BASEPRI: 000000f0 CONTROL: 00000000
>> up_registerdump: EXC_RETURN: ffffffe9
>> up_dumpstate: sp: 24010bb0
>> up_dumpstate: IRQ stack:
>> up_dumpstate: base: 24010c00
>> up_dumpstate: size: 00000200
>> up_dumpstate: used: 00000140
>> up_stackdump: 24010ba0: 24010bb0 2400e830 0000064c 080a0fed 000000f0
>> 00000000 240120b8 00000001
>> up_stackdump: 24010bc0: 38002f88 080a26a7 080a2538 0816625a 00000000
>> 080a129f 080a1271 080f754f
>> up_stackdump: 24010be0: 000000f0 080a2935 000000f0 38002eb4 40029160
>> 24011fc0 00008040 080a1b8f
>> up_dumpstate: sp: 38002f88
>> up_dumpstate: User stack:
>> up_dumpstate: base: 38003008
>> up_dumpstate: size: 0000064c
>> up_dumpstate: used: 000003e0
>> up_stackdump: 38002f80: 00000010 080a269b 24012050 24012000 00000000
>> 24012010 2400b430 00000000
>> up_stackdump: 38002fa0: 000000f0 00000080 00000000 00000000 00005ec8
>> 0809d2e7 ffffffff ffffffff
>> up_stackdump: 38002fc0: 00005ec8 00000001 00000010 00020000 39276cac
>> 2400b430 00000000 00000000
>> up_stackdump: 38002fe0: 00000000 00000000 00000000 00000000 00000000
>> 0809c501 0809c4f1 0809bed5
>> up_stackdump: 38003000: 00000000 00000000 deadbeef 38003014 00000000
>> 6f77706c de006b72 7b93d153
>> up_taskdump: Idle Task: PID=0 Stack Used=0 of 0
>> up_taskdump: hpwork: PID=1 Stack Used=352 of 2028
>> up_taskdump: lpwork: PID=2 Stack Used=992 of 1612
>> up_taskdump: init: PID=3 Stack Used=1544 of 2980
>>
>>
>> CONFIDENTIALITY NOTICE: This communication may contain private, confidential
>> and privileged material for the sole use of the intended recipient. If you
>> are not the intended recipient, please delete this e-mail and any
>> attachments permanently.
>>
>>
Re: STM32H7 ethernet hardfaults
Posted by Gregory Nutt <sp...@gmail.com>.
> The MAC in the the H7 has it's own dedicated internal DMA, so I don't
> think that disabling the system-wide DMA would have any effect. I can
> give it a shot anyways though and report back!
One thing I am wondering is if you have properly set up the MAC address
filtering. For TCP, each peer advertises its supported MSS (read MTU)
and any connected peer should never send a packet that exceeds that
negotiated MTU. That limiting should prevent TCP packets from
overflowing a tiny, 590 byte buffer.
It does nothing for broadcast or UDP packets, however. But those do not
tend to be so large as streaming TCP data which will normally transmits
data at the negotiated maximum size.
But if you are not properly filtering incoming addresses, then you are
also receiving packets that are are not destined for you and hence will
not obey the negotiated maximum.
May sure that PROMISCUOUS mode and other other more obscure filter
options are disabled.
Re: STM32H7 ethernet hardfaults
Posted by Oliver Miranda <ol...@aurotecnologia.com.br>.
Hi John,
You can check this very useful post about Hardfault in Cortex M in the
follow link:
-
https://cwiki.apache.org/confluence/display/NUTTX/Analyzing+Cortex-M+Hardfaults
Regards,
Oliver Miranda
Em qui., 4 de mar. de 2021 às 18:06, John Rippetoe <
jrippetoe@roboticresearch.com> escreveu:
> Alan,
>
> The MAC in the the H7 has it's own dedicated internal DMA, so I don't
> think that disabling the system-wide DMA would have any effect. I can
> give it a shot anyways though and report back!
>
> Thanks for the suggestion.
>
> - John
>
> On 3/4/21 4:00 PM, Alan Carvalho de Assis wrote:
> > Hi John,
> >
> > Did you try to disable DMA support to see if the issue disappear?
> >
> > I think other MCUs are using DMA for Ethernet too and this issue
> > didn't happen. So I think disabling DMA could be a valid test to find
> > out the root causes.
> >
> > BR,
> >
> > Alan
> >
> > On 3/4/21, John Rippetoe <jr...@roboticresearch.com> wrote:
> >> Hello All,
> >>
> >> I've been playing around with networking on the STM32H7 and am seeing
> >> hardfaults that appear to be related to NET_ETH_PKTSIZE. From the log
> >> below, the driver would appear to be dropping packets that are too large
> >> to fit into the default packet size of 590. By increasing the packet
> >> size to the max (1518), the problem seems to disappear, but I am a
> >> little confused why the driver is able to catch the fact that the
> >> received packet was too large and drop it appropriately, but then crash.
> >> After poking around the ethernet driver, I think I understand the issue
> >> to be that because the MAC DMA does not know that the buffer it is
> >> writing into has a size limit, it is overflowing the buffer and writing
> >> into adjacent memory. Am I understanding this correctly?
> >>
> >> My main concern here is that increasing NET_ETH_PKTSIZE to the limit
> >> will only hide the issue for a time instead of solving it. A quick
> >> google search does show that the maximum ethernet frame size is 1518
> >> bytes though, so I am working under the assumption that maxing it out in
> >> my config will account for all possible frame sizes and eliminate this
> >> issue. I have no experience with low level networking protocols and
> >> standards, so I thought it would be prudent to seek out additional help
> >> to make sure I am on the right track.
> >>
> >> Thanks in advance.
> >>
> >> - John
> >>
> >> stm32_receive: WARNING: DROPPED Too big: 684
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> stm32_receive: WARNING: DROPPED Too big: 1332
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> stm32_receive: WARNING: DROPPED Too big: 1264
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> stm32_receive: WARNING: DROPPED Too big: 684
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> stm32_receive: WARNING: DROPPED Too big: 1364
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> stm32_receive: WARNING: DROPPED Too big: 1264
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> stm32_receive: WARNING: DROPPED Too big: 1436
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> stm32_receive: WARNING: DROPPED Too big: 1300
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> up_hardfault: PANIC!!! Hard fault: 40000000
> >> up_assert: Assertion failed at file:armv7-m/up_hardfault.c line: 148
> >> task: lpwork
> >> up_registerdump: R0: 24012080 2401206e 0000024e 00000000 24012000
> >> 40029160 24011fc0 00008040
> >> up_registerdump: R8: 40029134 24011f00 24011fe0 240120b8 00000001
> >> 38002f88 080a26a7 080a2538
> >> up_registerdump: xPSR: 81000000 BASEPRI: 000000f0 CONTROL: 00000000
> >> up_registerdump: EXC_RETURN: ffffffe9
> >> up_dumpstate: sp: 24010bb0
> >> up_dumpstate: IRQ stack:
> >> up_dumpstate: base: 24010c00
> >> up_dumpstate: size: 00000200
> >> up_dumpstate: used: 00000140
> >> up_stackdump: 24010ba0: 24010bb0 2400e830 0000064c 080a0fed 000000f0
> >> 00000000 240120b8 00000001
> >> up_stackdump: 24010bc0: 38002f88 080a26a7 080a2538 0816625a 00000000
> >> 080a129f 080a1271 080f754f
> >> up_stackdump: 24010be0: 000000f0 080a2935 000000f0 38002eb4 40029160
> >> 24011fc0 00008040 080a1b8f
> >> up_dumpstate: sp: 38002f88
> >> up_dumpstate: User stack:
> >> up_dumpstate: base: 38003008
> >> up_dumpstate: size: 0000064c
> >> up_dumpstate: used: 000003e0
> >> up_stackdump: 38002f80: 00000010 080a269b 24012050 24012000 00000000
> >> 24012010 2400b430 00000000
> >> up_stackdump: 38002fa0: 000000f0 00000080 00000000 00000000 00005ec8
> >> 0809d2e7 ffffffff ffffffff
> >> up_stackdump: 38002fc0: 00005ec8 00000001 00000010 00020000 39276cac
> >> 2400b430 00000000 00000000
> >> up_stackdump: 38002fe0: 00000000 00000000 00000000 00000000 00000000
> >> 0809c501 0809c4f1 0809bed5
> >> up_stackdump: 38003000: 00000000 00000000 deadbeef 38003014 00000000
> >> 6f77706c de006b72 7b93d153
> >> up_taskdump: Idle Task: PID=0 Stack Used=0 of 0
> >> up_taskdump: hpwork: PID=1 Stack Used=352 of 2028
> >> up_taskdump: lpwork: PID=2 Stack Used=992 of 1612
> >> up_taskdump: init: PID=3 Stack Used=1544 of 2980
> >>
> >>
> >> CONFIDENTIALITY NOTICE: This communication may contain private,
> confidential
> >> and privileged material for the sole use of the intended recipient. If
> you
> >> are not the intended recipient, please delete this e-mail and any
> >> attachments permanently.
> >>
> >>
> CONFIDENTIALITY NOTICE: This communication may contain private,
> confidential and privileged material for the sole use of the intended
> recipient. If you are not the intended recipient, please delete this e-mail
> and any attachments permanently.
>
>
Re: STM32H7 ethernet hardfaults
Posted by John Rippetoe <jr...@roboticresearch.com>.
Alan,
The MAC in the the H7 has it's own dedicated internal DMA, so I don't
think that disabling the system-wide DMA would have any effect. I can
give it a shot anyways though and report back!
Thanks for the suggestion.
- John
On 3/4/21 4:00 PM, Alan Carvalho de Assis wrote:
> Hi John,
>
> Did you try to disable DMA support to see if the issue disappear?
>
> I think other MCUs are using DMA for Ethernet too and this issue
> didn't happen. So I think disabling DMA could be a valid test to find
> out the root causes.
>
> BR,
>
> Alan
>
> On 3/4/21, John Rippetoe <jr...@roboticresearch.com> wrote:
>> Hello All,
>>
>> I've been playing around with networking on the STM32H7 and am seeing
>> hardfaults that appear to be related to NET_ETH_PKTSIZE. From the log
>> below, the driver would appear to be dropping packets that are too large
>> to fit into the default packet size of 590. By increasing the packet
>> size to the max (1518), the problem seems to disappear, but I am a
>> little confused why the driver is able to catch the fact that the
>> received packet was too large and drop it appropriately, but then crash.
>> After poking around the ethernet driver, I think I understand the issue
>> to be that because the MAC DMA does not know that the buffer it is
>> writing into has a size limit, it is overflowing the buffer and writing
>> into adjacent memory. Am I understanding this correctly?
>>
>> My main concern here is that increasing NET_ETH_PKTSIZE to the limit
>> will only hide the issue for a time instead of solving it. A quick
>> google search does show that the maximum ethernet frame size is 1518
>> bytes though, so I am working under the assumption that maxing it out in
>> my config will account for all possible frame sizes and eliminate this
>> issue. I have no experience with low level networking protocols and
>> standards, so I thought it would be prudent to seek out additional help
>> to make sure I am on the right track.
>>
>> Thanks in advance.
>>
>> - John
>>
>> stm32_receive: WARNING: DROPPED Too big: 684
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> stm32_receive: WARNING: DROPPED Too big: 1332
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> stm32_receive: WARNING: DROPPED Too big: 1264
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> stm32_receive: WARNING: DROPPED Too big: 684
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> stm32_receive: WARNING: DROPPED Too big: 1364
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> stm32_receive: WARNING: DROPPED Too big: 1264
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> stm32_receive: WARNING: DROPPED Too big: 1436
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> stm32_receive: WARNING: DROPPED Too big: 1300
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> up_hardfault: PANIC!!! Hard fault: 40000000
>> up_assert: Assertion failed at file:armv7-m/up_hardfault.c line: 148
>> task: lpwork
>> up_registerdump: R0: 24012080 2401206e 0000024e 00000000 24012000
>> 40029160 24011fc0 00008040
>> up_registerdump: R8: 40029134 24011f00 24011fe0 240120b8 00000001
>> 38002f88 080a26a7 080a2538
>> up_registerdump: xPSR: 81000000 BASEPRI: 000000f0 CONTROL: 00000000
>> up_registerdump: EXC_RETURN: ffffffe9
>> up_dumpstate: sp: 24010bb0
>> up_dumpstate: IRQ stack:
>> up_dumpstate: base: 24010c00
>> up_dumpstate: size: 00000200
>> up_dumpstate: used: 00000140
>> up_stackdump: 24010ba0: 24010bb0 2400e830 0000064c 080a0fed 000000f0
>> 00000000 240120b8 00000001
>> up_stackdump: 24010bc0: 38002f88 080a26a7 080a2538 0816625a 00000000
>> 080a129f 080a1271 080f754f
>> up_stackdump: 24010be0: 000000f0 080a2935 000000f0 38002eb4 40029160
>> 24011fc0 00008040 080a1b8f
>> up_dumpstate: sp: 38002f88
>> up_dumpstate: User stack:
>> up_dumpstate: base: 38003008
>> up_dumpstate: size: 0000064c
>> up_dumpstate: used: 000003e0
>> up_stackdump: 38002f80: 00000010 080a269b 24012050 24012000 00000000
>> 24012010 2400b430 00000000
>> up_stackdump: 38002fa0: 000000f0 00000080 00000000 00000000 00005ec8
>> 0809d2e7 ffffffff ffffffff
>> up_stackdump: 38002fc0: 00005ec8 00000001 00000010 00020000 39276cac
>> 2400b430 00000000 00000000
>> up_stackdump: 38002fe0: 00000000 00000000 00000000 00000000 00000000
>> 0809c501 0809c4f1 0809bed5
>> up_stackdump: 38003000: 00000000 00000000 deadbeef 38003014 00000000
>> 6f77706c de006b72 7b93d153
>> up_taskdump: Idle Task: PID=0 Stack Used=0 of 0
>> up_taskdump: hpwork: PID=1 Stack Used=352 of 2028
>> up_taskdump: lpwork: PID=2 Stack Used=992 of 1612
>> up_taskdump: init: PID=3 Stack Used=1544 of 2980
>>
>>
>> CONFIDENTIALITY NOTICE: This communication may contain private, confidential
>> and privileged material for the sole use of the intended recipient. If you
>> are not the intended recipient, please delete this e-mail and any
>> attachments permanently.
>>
>>
CONFIDENTIALITY NOTICE: This communication may contain private, confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please delete this e-mail and any attachments permanently.
Re: STM32H7 ethernet hardfaults
Posted by Alan Carvalho de Assis <ac...@gmail.com>.
Hi John,
Did you try to disable DMA support to see if the issue disappear?
I think other MCUs are using DMA for Ethernet too and this issue
didn't happen. So I think disabling DMA could be a valid test to find
out the root causes.
BR,
Alan
On 3/4/21, John Rippetoe <jr...@roboticresearch.com> wrote:
> Hello All,
>
> I've been playing around with networking on the STM32H7 and am seeing
> hardfaults that appear to be related to NET_ETH_PKTSIZE. From the log
> below, the driver would appear to be dropping packets that are too large
> to fit into the default packet size of 590. By increasing the packet
> size to the max (1518), the problem seems to disappear, but I am a
> little confused why the driver is able to catch the fact that the
> received packet was too large and drop it appropriately, but then crash.
> After poking around the ethernet driver, I think I understand the issue
> to be that because the MAC DMA does not know that the buffer it is
> writing into has a size limit, it is overflowing the buffer and writing
> into adjacent memory. Am I understanding this correctly?
>
> My main concern here is that increasing NET_ETH_PKTSIZE to the limit
> will only hide the issue for a time instead of solving it. A quick
> google search does show that the maximum ethernet frame size is 1518
> bytes though, so I am working under the assumption that maxing it out in
> my config will account for all possible frame sizes and eliminate this
> issue. I have no experience with low level networking protocols and
> standards, so I thought it would be prudent to seek out additional help
> to make sure I am on the right track.
>
> Thanks in advance.
>
> - John
>
> stm32_receive: WARNING: DROPPED Too big: 684
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> stm32_receive: WARNING: DROPPED Too big: 1332
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> stm32_receive: WARNING: DROPPED Too big: 1264
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> stm32_receive: WARNING: DROPPED Too big: 684
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> stm32_receive: WARNING: DROPPED Too big: 1364
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> stm32_receive: WARNING: DROPPED Too big: 1264
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> stm32_receive: WARNING: DROPPED Too big: 1436
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> stm32_receive: WARNING: DROPPED Too big: 1300
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> up_hardfault: PANIC!!! Hard fault: 40000000
> up_assert: Assertion failed at file:armv7-m/up_hardfault.c line: 148
> task: lpwork
> up_registerdump: R0: 24012080 2401206e 0000024e 00000000 24012000
> 40029160 24011fc0 00008040
> up_registerdump: R8: 40029134 24011f00 24011fe0 240120b8 00000001
> 38002f88 080a26a7 080a2538
> up_registerdump: xPSR: 81000000 BASEPRI: 000000f0 CONTROL: 00000000
> up_registerdump: EXC_RETURN: ffffffe9
> up_dumpstate: sp: 24010bb0
> up_dumpstate: IRQ stack:
> up_dumpstate: base: 24010c00
> up_dumpstate: size: 00000200
> up_dumpstate: used: 00000140
> up_stackdump: 24010ba0: 24010bb0 2400e830 0000064c 080a0fed 000000f0
> 00000000 240120b8 00000001
> up_stackdump: 24010bc0: 38002f88 080a26a7 080a2538 0816625a 00000000
> 080a129f 080a1271 080f754f
> up_stackdump: 24010be0: 000000f0 080a2935 000000f0 38002eb4 40029160
> 24011fc0 00008040 080a1b8f
> up_dumpstate: sp: 38002f88
> up_dumpstate: User stack:
> up_dumpstate: base: 38003008
> up_dumpstate: size: 0000064c
> up_dumpstate: used: 000003e0
> up_stackdump: 38002f80: 00000010 080a269b 24012050 24012000 00000000
> 24012010 2400b430 00000000
> up_stackdump: 38002fa0: 000000f0 00000080 00000000 00000000 00005ec8
> 0809d2e7 ffffffff ffffffff
> up_stackdump: 38002fc0: 00005ec8 00000001 00000010 00020000 39276cac
> 2400b430 00000000 00000000
> up_stackdump: 38002fe0: 00000000 00000000 00000000 00000000 00000000
> 0809c501 0809c4f1 0809bed5
> up_stackdump: 38003000: 00000000 00000000 deadbeef 38003014 00000000
> 6f77706c de006b72 7b93d153
> up_taskdump: Idle Task: PID=0 Stack Used=0 of 0
> up_taskdump: hpwork: PID=1 Stack Used=352 of 2028
> up_taskdump: lpwork: PID=2 Stack Used=992 of 1612
> up_taskdump: init: PID=3 Stack Used=1544 of 2980
>
>
> CONFIDENTIALITY NOTICE: This communication may contain private, confidential
> and privileged material for the sole use of the intended recipient. If you
> are not the intended recipient, please delete this e-mail and any
> attachments permanently.
>
>
Re: STM32H7 ethernet hardfaults
Posted by James Dougherty <ja...@gmail.com>.
That “thing i quoted” *was* the ethernet spec - THE NORMAL STANDARD
- the latest version 802.3-2018 going for about $1000 USD.
And like I said, there is no such thing as a "Jumbo" frame, it's not
IEEE standard, the spec shows that also.
therefore saying "it's already a jumbo frame" is meaningless. The
Ethernet Layer-2 standard defines a 14-byte ethernet
header and 1500 byte payload size, with a 4 byte CRC that is 1518
bytes. When you say "it's part of the data" you have
to be clear about what layer you are talking about.
No. The TAG comes after the DA/SA, the length after the tag. Here is a
picture https://en.wikipedia.org/wiki/EtherType
See section VLAN tagging. What happens in hardware is the fixed DA/SA
(12 bytes) is extracted, a 0x8100 type / len
re-inserted and CRC recomputed.
The firmware for the Broadcom StrataSwitch 56xx ethernet switches
handles L2 Ethernet I/II, tagged/untagged
with/without snap headers, as well as L3 hardware routing including
rewriting up to 52 bytes of the IP header field,
all while respecting TOS and QoS — we didn’t drop packets over 1500
bytes at L2 - and that was 20 years ago.
This is where the defines in net/if_ether.h in any modern linux kernel
come from - note the distinction between
ETH_FRAME_LEN (1514) and ETH_DATA_LEN (1500) the former which handles
the Ethernet header.
To make it even more complicated, there are additional header values
which are typically inserted on a GigE/VLAN
based controller and that is all "pulled up" (removed) by the time the
IP layer gets the packet (by your Ethernet MAC
or driver).
Regardless, the recommendation for any Ethernet L2 use case today is a
1518 to 2K frame size. I understand on these
microcontrollers that may seem excessive, but newer chips will have
even more ram and performance and you have
to decide whether you want interop or a dedicated point to point use-case.
If you want to nitpick on something, it should be the standard, the
latest envelope extensions are going to make
networking even more difficult in the future :(
> On Mar 5, 2021, at 2:45 AM, Johnny Billquist <bq...@softjar.se> wrote:
>
>> On 2021-03-05 05:35, James Dougherty wrote:
>> Technically, the MTU should be 1496 of you use VLANs, or else it's
>>> actually already a jumbo frame. The total size according to the ethernet
>>> spec is really 1518. Larger are not allowed. VLAN information is
>>> actually a part of the payload.
>>>
>>>
>> Yes, 1518 is the size, true. But VLANS are not part of the payload. An
>> untagged frame which enters a VLAN
>> switch will have the 802.1Q tag inserted after the DA/SA. When that happens
>> the CRC has to be recomputed
>> so therefore *it is not* just part of the payload (e.g. like a UDP
>> datagram). Larger are allowed, we typically use 2K
>> sizes for additional link layer encapsulation (most of the switching
>> hardware today does at least).
>
> The CRC covers the whole packet, so of course the CRC have to be recomputed if you add a VLAN tag.
>
> The VLAN tags are not added after the DA/SA, but actually after the length field.
> When you add VLANs, you normally no longer use ethernet, but instead 802.3. In which this is not considered a part of the payload, I know. But the controller receiving the packet might have no clue about this. It's all at a higher level of protocol handling. It's nice that 802.3 have defined so that larger frames are allowed. Older ethernet controllers will still drop such packets because they are over 1500 bytes of payload. Even if they understand 802.3. And even if software would understand VLANs.
> Not that the thing you quoted states "MAC Client Data Field". And that is 1500 (the normal standard), 1504 with Q-tag, and so on. That's the MAC Client *Data* field. It's part of the data.
>
> But I suspect you know this. :-)
>
> I feel I should stop now anyway. Feel free to mail me in private though. But I don't want to pollute the mailbox of everyone with my nitpickings.
>
> Johnny
>
> --
> Johnny Billquist || "I'm on a bus
> || on a psychedelic trip
> email: bqt@softjar.se || Reading murder books
> pdp is alive! || tryin' to stay hip" - B. Idol
Re: STM32H7 ethernet hardfaults
Posted by Johnny Billquist <bq...@softjar.se>.
On 2021-03-05 05:35, James Dougherty wrote:
> Technically, the MTU should be 1496 of you use VLANs, or else it's
>> actually already a jumbo frame. The total size according to the ethernet
>> spec is really 1518. Larger are not allowed. VLAN information is
>> actually a part of the payload.
>>
>>
> Yes, 1518 is the size, true. But VLANS are not part of the payload. An
> untagged frame which enters a VLAN
> switch will have the 802.1Q tag inserted after the DA/SA. When that happens
> the CRC has to be recomputed
> so therefore *it is not* just part of the payload (e.g. like a UDP
> datagram). Larger are allowed, we typically use 2K
> sizes for additional link layer encapsulation (most of the switching
> hardware today does at least).
The CRC covers the whole packet, so of course the CRC have to be
recomputed if you add a VLAN tag.
The VLAN tags are not added after the DA/SA, but actually after the
length field.
When you add VLANs, you normally no longer use ethernet, but instead
802.3. In which this is not considered a part of the payload, I know.
But the controller receiving the packet might have no clue about this.
It's all at a higher level of protocol handling. It's nice that 802.3
have defined so that larger frames are allowed. Older ethernet
controllers will still drop such packets because they are over 1500
bytes of payload. Even if they understand 802.3. And even if software
would understand VLANs.
Not that the thing you quoted states "MAC Client Data Field". And that
is 1500 (the normal standard), 1504 with Q-tag, and so on. That's the
MAC Client *Data* field. It's part of the data.
But I suspect you know this. :-)
I feel I should stop now anyway. Feel free to mail me in private though.
But I don't want to pollute the mailbox of everyone with my nitpickings.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Re: STM32H7 ethernet hardfaults
Posted by James Dougherty <ja...@gmail.com>.
Technically, the MTU should be 1496 of you use VLANs, or else it's
> actually already a jumbo frame. The total size according to the ethernet
> spec is really 1518. Larger are not allowed. VLAN information is
> actually a part of the payload.
>
>
Yes, 1518 is the size, true. But VLANS are not part of the payload. An
untagged frame which enters a VLAN
switch will have the 802.1Q tag inserted after the DA/SA. When that happens
the CRC has to be recomputed
so therefore *it is not* just part of the payload (e.g. like a UDP
datagram). Larger are allowed, we typically use 2K
sizes for additional link layer encapsulation (most of the switching
hardware today does at least).
IEEE Std 802.3-2012 (Revision of IEEE Std 802.3-2008)
1.4.102 basic frame
A MAC frame that carries a Length/Type field with the Length or type
interpretation and has a maximum length of *1518* octets. The
basic frame is not intended to allow inclusion of additional tags (i.e.,
untagged) or encapsulations required by higher layer
protocols. (See IEEE Std 802.3, 3.2.7.)
3.2.7 MAC Client Data Field
Ethernet implementations shall support at least one of three maximum MAC
Client Data field sizes defined as follows:
a) 1500 decimal—basic frames (see 1.4.102)
b) 1504 decimal—Q-tagged frames (see 1.4.334)
c) 1982 decimal—envelope frames (see 1.4.184)
If layer management is implemented, frames with a MAC Client Data field
larger than the supported maximum MAC Client Data field size are counted.
Also, if we have a length field, then it's an 802.3 frame, while if you
> have type information in there it is a Ethernet II frame. So IP commonly
> use Ethernet II, and not 802.3. There is a standard for sending IP over
> 802.3 as well, but it has been declared obsolete since many years now.
>
3.2.6 Length/Type field This two-octet field takes one of two meanings,
depending on its numeric value.
For numerical evaluation, the first octet is the most significant octet of
this field.
a)If the value of this field is less than or equal to 1500 decimal (05DC
hexadecimal), then the Length/Type
field indicates the number of MAC client data octets contained in the
subsequent MAC Client Data field of
the basic frame (Length interpretation).
b)If the value of this field is greater than or equal to 1536 decimal (0600
hexadecimal), then the Length/Type
field indicates the Ethertype of the MAC client protocol (Type
interpretation). The Length and Type interpretations
of this field are mutually exclusive.
>
> Sorry, this was mostly silly trivia...
>
> We are running with STM32H7 chips, but I think we are actually using a
> large enough packet size. So I don't have any direct feedback on this
> problem.
>
>
So what packet size do you use? We're running STM32F7 with some exotic
radio hardware, probably
will get to this later on in the year (Ethernet bridging).
> Johnny
>
> On 2021-03-04 22:48, James Dougherty wrote:
> > John, to answer your question on ethernet, 1500 is a very common MTU. For
> > VLAN tagged frame support (802.1Q VLAN ID ), 1518 bytes (1522 bytes on
> the
> > wire with 4-byte / 32-bit ETH CRC32), for Jumbo frames (not IEEE) 9122 is
> > common. Minimum frame size with CRC is 64-bytes and zero padding is
> common,
> > < 64 is considered a runt frame. And note if ethernet_len field is 0x800
> > you have an IP packet. Good luck on STM32H7 ethernet hardfault debug.
> >
> > On Thu, Mar 4, 2021 at 12:46 PM John Rippetoe <
> jrippetoe@roboticresearch.com>
> > wrote:
> >
> >> Hello All,
> >>
> >> I've been playing around with networking on the STM32H7 and am seeing
> >> hardfaults that appear to be related to NET_ETH_PKTSIZE. From the log
> >> below, the driver would appear to be dropping packets that are too large
> >> to fit into the default packet size of 590. By increasing the packet
> >> size to the max (1518), the problem seems to disappear, but I am a
> >> little confused why the driver is able to catch the fact that the
> >> received packet was too large and drop it appropriately, but then crash.
> >> After poking around the ethernet driver, I think I understand the issue
> >> to be that because the MAC DMA does not know that the buffer it is
> >> writing into has a size limit, it is overflowing the buffer and writing
> >> into adjacent memory. Am I understanding this correctly?
> >>
> >> My main concern here is that increasing NET_ETH_PKTSIZE to the limit
> >> will only hide the issue for a time instead of solving it. A quick
> >> google search does show that the maximum ethernet frame size is 1518
> >> bytes though, so I am working under the assumption that maxing it out in
> >> my config will account for all possible frame sizes and eliminate this
> >> issue. I have no experience with low level networking protocols and
> >> standards, so I thought it would be prudent to seek out additional help
> >> to make sure I am on the right track.
> >>
> >> Thanks in advance.
> >>
> >> - John
> >>
> >> stm32_receive: WARNING: DROPPED Too big: 684
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> stm32_receive: WARNING: DROPPED Too big: 1332
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> stm32_receive: WARNING: DROPPED Too big: 1264
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> stm32_receive: WARNING: DROPPED Too big: 684
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> stm32_receive: WARNING: DROPPED Too big: 1364
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> stm32_receive: WARNING: DROPPED Too big: 1264
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> stm32_receive: WARNING: DROPPED Too big: 1436
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> stm32_receive: WARNING: DROPPED Too big: 1300
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> up_hardfault: PANIC!!! Hard fault: 40000000
> >> up_assert: Assertion failed at file:armv7-m/up_hardfault.c line: 148
> >> task: lpwork
> >> up_registerdump: R0: 24012080 2401206e 0000024e 00000000 24012000
> >> 40029160 24011fc0 00008040
> >> up_registerdump: R8: 40029134 24011f00 24011fe0 240120b8 00000001
> >> 38002f88 080a26a7 080a2538
> >> up_registerdump: xPSR: 81000000 BASEPRI: 000000f0 CONTROL: 00000000
> >> up_registerdump: EXC_RETURN: ffffffe9
> >> up_dumpstate: sp: 24010bb0
> >> up_dumpstate: IRQ stack:
> >> up_dumpstate: base: 24010c00
> >> up_dumpstate: size: 00000200
> >> up_dumpstate: used: 00000140
> >> up_stackdump: 24010ba0: 24010bb0 2400e830 0000064c 080a0fed 000000f0
> >> 00000000 240120b8 00000001
> >> up_stackdump: 24010bc0: 38002f88 080a26a7 080a2538 0816625a 00000000
> >> 080a129f 080a1271 080f754f
> >> up_stackdump: 24010be0: 000000f0 080a2935 000000f0 38002eb4 40029160
> >> 24011fc0 00008040 080a1b8f
> >> up_dumpstate: sp: 38002f88
> >> up_dumpstate: User stack:
> >> up_dumpstate: base: 38003008
> >> up_dumpstate: size: 0000064c
> >> up_dumpstate: used: 000003e0
> >> up_stackdump: 38002f80: 00000010 080a269b 24012050 24012000 00000000
> >> 24012010 2400b430 00000000
> >> up_stackdump: 38002fa0: 000000f0 00000080 00000000 00000000 00005ec8
> >> 0809d2e7 ffffffff ffffffff
> >> up_stackdump: 38002fc0: 00005ec8 00000001 00000010 00020000 39276cac
> >> 2400b430 00000000 00000000
> >> up_stackdump: 38002fe0: 00000000 00000000 00000000 00000000 00000000
> >> 0809c501 0809c4f1 0809bed5
> >> up_stackdump: 38003000: 00000000 00000000 deadbeef 38003014 00000000
> >> 6f77706c de006b72 7b93d153
> >> up_taskdump: Idle Task: PID=0 Stack Used=0 of 0
> >> up_taskdump: hpwork: PID=1 Stack Used=352 of 2028
> >> up_taskdump: lpwork: PID=2 Stack Used=992 of 1612
> >> up_taskdump: init: PID=3 Stack Used=1544 of 2980
> >>
> >>
> >> CONFIDENTIALITY NOTICE: This communication may contain private,
> >> confidential and privileged material for the sole use of the intended
> >> recipient. If you are not the intended recipient, please delete this
> e-mail
> >> and any attachments permanently.
> >>
> >>
> >
>
> --
> Johnny Billquist || "I'm on a bus
> || on a psychedelic trip
> email: bqt@softjar.se || Reading murder books
> pdp is alive! || tryin' to stay hip" - B. Idol
>
Re: STM32H7 ethernet hardfaults
Posted by Johnny Billquist <bq...@softjar.se>.
Technically, the MTU should be 1496 of you use VLANs, or else it's
actually already a jumbo frame. The total size according to the ethernet
spec is really 1518. Larger are not allowed. VLAN information is
actually a part of the payload.
Also, if we have a length field, then it's an 802.3 frame, while if you
have type information in there it is a Ethernet II frame. So IP commonly
use Ethernet II, and not 802.3. There is a standard for sending IP over
802.3 as well, but it has been declared obsolete since many years now.
Sorry, this was mostly silly trivia...
We are running with STM32H7 chips, but I think we are actually using a
large enough packet size. So I don't have any direct feedback on this
problem.
Johnny
On 2021-03-04 22:48, James Dougherty wrote:
> John, to answer your question on ethernet, 1500 is a very common MTU. For
> VLAN tagged frame support (802.1Q VLAN ID ), 1518 bytes (1522 bytes on the
> wire with 4-byte / 32-bit ETH CRC32), for Jumbo frames (not IEEE) 9122 is
> common. Minimum frame size with CRC is 64-bytes and zero padding is common,
> < 64 is considered a runt frame. And note if ethernet_len field is 0x800
> you have an IP packet. Good luck on STM32H7 ethernet hardfault debug.
>
> On Thu, Mar 4, 2021 at 12:46 PM John Rippetoe <jr...@roboticresearch.com>
> wrote:
>
>> Hello All,
>>
>> I've been playing around with networking on the STM32H7 and am seeing
>> hardfaults that appear to be related to NET_ETH_PKTSIZE. From the log
>> below, the driver would appear to be dropping packets that are too large
>> to fit into the default packet size of 590. By increasing the packet
>> size to the max (1518), the problem seems to disappear, but I am a
>> little confused why the driver is able to catch the fact that the
>> received packet was too large and drop it appropriately, but then crash.
>> After poking around the ethernet driver, I think I understand the issue
>> to be that because the MAC DMA does not know that the buffer it is
>> writing into has a size limit, it is overflowing the buffer and writing
>> into adjacent memory. Am I understanding this correctly?
>>
>> My main concern here is that increasing NET_ETH_PKTSIZE to the limit
>> will only hide the issue for a time instead of solving it. A quick
>> google search does show that the maximum ethernet frame size is 1518
>> bytes though, so I am working under the assumption that maxing it out in
>> my config will account for all possible frame sizes and eliminate this
>> issue. I have no experience with low level networking protocols and
>> standards, so I thought it would be prudent to seek out additional help
>> to make sure I am on the right track.
>>
>> Thanks in advance.
>>
>> - John
>>
>> stm32_receive: WARNING: DROPPED Too big: 684
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> stm32_receive: WARNING: DROPPED Too big: 1332
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> stm32_receive: WARNING: DROPPED Too big: 1264
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> stm32_receive: WARNING: DROPPED Too big: 684
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> stm32_receive: WARNING: DROPPED Too big: 1364
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> stm32_receive: WARNING: DROPPED Too big: 1264
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> stm32_receive: WARNING: DROPPED Too big: 1436
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> stm32_receive: WARNING: DROPPED Too big: 1300
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
>> up_hardfault: PANIC!!! Hard fault: 40000000
>> up_assert: Assertion failed at file:armv7-m/up_hardfault.c line: 148
>> task: lpwork
>> up_registerdump: R0: 24012080 2401206e 0000024e 00000000 24012000
>> 40029160 24011fc0 00008040
>> up_registerdump: R8: 40029134 24011f00 24011fe0 240120b8 00000001
>> 38002f88 080a26a7 080a2538
>> up_registerdump: xPSR: 81000000 BASEPRI: 000000f0 CONTROL: 00000000
>> up_registerdump: EXC_RETURN: ffffffe9
>> up_dumpstate: sp: 24010bb0
>> up_dumpstate: IRQ stack:
>> up_dumpstate: base: 24010c00
>> up_dumpstate: size: 00000200
>> up_dumpstate: used: 00000140
>> up_stackdump: 24010ba0: 24010bb0 2400e830 0000064c 080a0fed 000000f0
>> 00000000 240120b8 00000001
>> up_stackdump: 24010bc0: 38002f88 080a26a7 080a2538 0816625a 00000000
>> 080a129f 080a1271 080f754f
>> up_stackdump: 24010be0: 000000f0 080a2935 000000f0 38002eb4 40029160
>> 24011fc0 00008040 080a1b8f
>> up_dumpstate: sp: 38002f88
>> up_dumpstate: User stack:
>> up_dumpstate: base: 38003008
>> up_dumpstate: size: 0000064c
>> up_dumpstate: used: 000003e0
>> up_stackdump: 38002f80: 00000010 080a269b 24012050 24012000 00000000
>> 24012010 2400b430 00000000
>> up_stackdump: 38002fa0: 000000f0 00000080 00000000 00000000 00005ec8
>> 0809d2e7 ffffffff ffffffff
>> up_stackdump: 38002fc0: 00005ec8 00000001 00000010 00020000 39276cac
>> 2400b430 00000000 00000000
>> up_stackdump: 38002fe0: 00000000 00000000 00000000 00000000 00000000
>> 0809c501 0809c4f1 0809bed5
>> up_stackdump: 38003000: 00000000 00000000 deadbeef 38003014 00000000
>> 6f77706c de006b72 7b93d153
>> up_taskdump: Idle Task: PID=0 Stack Used=0 of 0
>> up_taskdump: hpwork: PID=1 Stack Used=352 of 2028
>> up_taskdump: lpwork: PID=2 Stack Used=992 of 1612
>> up_taskdump: init: PID=3 Stack Used=1544 of 2980
>>
>>
>> CONFIDENTIALITY NOTICE: This communication may contain private,
>> confidential and privileged material for the sole use of the intended
>> recipient. If you are not the intended recipient, please delete this e-mail
>> and any attachments permanently.
>>
>>
>
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Re: STM32H7 ethernet hardfaults
Posted by James Dougherty <ja...@gmail.com>.
Yes, that's true. very good discussion. I bring this up since you can do
whatever you want on a point to point link.
For maximum compatibility, using 1500 or 1518 will help you handle all of
the cross-network cases
where you cross a bridge/switch or gateway.
The other unintended side-effect of this is that when you use these smaller
MTU's you will impose a slightly
larger number of packets in overhead. Many people think the bitrates are
the limitation but it usually ends up
being the number of packets. What you put in your payload is going to
mandate your fragmentation and therefore
your true number of packets to/from your stack.
Its time or space, you can't have both :-)
On Thu, Mar 4, 2021 at 6:38 PM Johnny Billquist <bq...@softjar.se> wrote:
> On 2021-03-05 00:21, Gregory Nutt wrote:
> >
> > On 3/4/2021 4:59 PM, James Dougherty wrote:
> >> Thank you, that is interesting. Doesn't it also imply is that with the
> >> smaller MTU of 590 you'll end up having
> >> fragmentation which will add a little bit of processing overhead? I
> >> understand it is not that big of a deal since
> >> fragmentation happens a lot, but for the best performance yes, both
> sides
> >> have to agree on a decent MTU.
> >
> > In TCP, both sides do agree. That is the negotiated MTU.
>
> Sorry for jumping in like this. Stop me if I bore people too much.
>
> Actually, TCP do not negotiate any MTU.
>
> But there are two mechanisms that is sortof close to this, which might
> be what you are thinking of.
>
> The first one is MSS. This is a value each TCP endpoint announce to the
> other end, and which essentially declares the largest packet size that
> end is capable of handle (well, primarily receive). Each side just sends
> the MSS that applies for that size. And each side should not send
> packets that are larger than MSS the other end declared. And usually you
> would not send packets larger than your own MSS, since usually there is
> some good reason for whatever MSS you declare to the other end, and it
> applies just as much to transmission as reception.
>
> That means you'll commonly not see packets larger than the smaller MSS
> of the two ends involved in communication.
>
> However, this does not avoid packet fragmentation happen, because packet
> fragmentation is an IP level feature, and it will also happen if any hop
> between the two endpoints have a small enough MTU, or possibly if
> various IP options are added that TCP just don't know about, and so on.
>
> So, the second mechanism is the path MTU detection (or PMTU). But this
> is no negotiation at all, but a trick the sending TCP do in order to try
> and figure out how large packets can be sent without them being
> fragmented along the way. The basics of the trick is that TCP sends
> packets with the don't fragment bit set in IP, and if any hop along the
> way require the packet to be fragmented, an ICMP error packet will
> instead be returned. This is then a signal to TCP that it should
> retransmit, but also reduce the PMTU. And once it a while, TCP should
> try to increase the PMTU, to just check if the path might actually have
> changed to allow larger packets (assuming you're not already at your own
> interface MTU, at which you can't go larger anyway).
>
> And as to MTU, the actual "legal" lower limit of the MTU in IP is 68.
> However, the minimum sized packet an IP implementation must support is
> 576 bytes. But there is nothing saying that it has be able to be
> transferred without fragmentation. But an IP stack is technically
> allowed to drop without notice packets that are larger than 576 bytes
> (although it wouldn't be very nice).
>
> If people want to read all the itty bitty details, I can give you the
> RFCs. But you can just google it as well.
>
> > Of course, larger MTUs have better transfer rates. That is the old
> > performance vs. size trade-off. If so configured, both end points
> > should use the configured MTU of the network. However, they should also
> > work with limited devices with smaller MTUs.
>
> All very true. But it does mean that if you are on the same ethernet,
> and one host have defined a smaller MTU, and you use UDP for example,
> then larger packets might get lost without any feedback. Because UDP
> have no clue about the other end having a different/smaller MTU.
>
> TCP should usually manage, since MSS should reflect the local MTU, and
> thus the other end knows it can't send larger packets than that, when
> using TCP at least.
>
> It's rather recommended that all hosts on a shared medium use the same
> MTU, if possible. Otherwise there is a clear risk that communication
> might not work as expected.
>
> Johnny
>
> --
> Johnny Billquist || "I'm on a bus
> || on a psychedelic trip
> email: bqt@softjar.se || Reading murder books
> pdp is alive! || tryin' to stay hip" - B. Idol
>
Re: STM32H7 ethernet hardfaults
Posted by Johnny Billquist <bq...@softjar.se>.
On 2021-03-05 00:21, Gregory Nutt wrote:
>
> On 3/4/2021 4:59 PM, James Dougherty wrote:
>> Thank you, that is interesting. Doesn't it also imply is that with the
>> smaller MTU of 590 you'll end up having
>> fragmentation which will add a little bit of processing overhead? I
>> understand it is not that big of a deal since
>> fragmentation happens a lot, but for the best performance yes, both sides
>> have to agree on a decent MTU.
>
> In TCP, both sides do agree. That is the negotiated MTU.
Sorry for jumping in like this. Stop me if I bore people too much.
Actually, TCP do not negotiate any MTU.
But there are two mechanisms that is sortof close to this, which might
be what you are thinking of.
The first one is MSS. This is a value each TCP endpoint announce to the
other end, and which essentially declares the largest packet size that
end is capable of handle (well, primarily receive). Each side just sends
the MSS that applies for that size. And each side should not send
packets that are larger than MSS the other end declared. And usually you
would not send packets larger than your own MSS, since usually there is
some good reason for whatever MSS you declare to the other end, and it
applies just as much to transmission as reception.
That means you'll commonly not see packets larger than the smaller MSS
of the two ends involved in communication.
However, this does not avoid packet fragmentation happen, because packet
fragmentation is an IP level feature, and it will also happen if any hop
between the two endpoints have a small enough MTU, or possibly if
various IP options are added that TCP just don't know about, and so on.
So, the second mechanism is the path MTU detection (or PMTU). But this
is no negotiation at all, but a trick the sending TCP do in order to try
and figure out how large packets can be sent without them being
fragmented along the way. The basics of the trick is that TCP sends
packets with the don't fragment bit set in IP, and if any hop along the
way require the packet to be fragmented, an ICMP error packet will
instead be returned. This is then a signal to TCP that it should
retransmit, but also reduce the PMTU. And once it a while, TCP should
try to increase the PMTU, to just check if the path might actually have
changed to allow larger packets (assuming you're not already at your own
interface MTU, at which you can't go larger anyway).
And as to MTU, the actual "legal" lower limit of the MTU in IP is 68.
However, the minimum sized packet an IP implementation must support is
576 bytes. But there is nothing saying that it has be able to be
transferred without fragmentation. But an IP stack is technically
allowed to drop without notice packets that are larger than 576 bytes
(although it wouldn't be very nice).
If people want to read all the itty bitty details, I can give you the
RFCs. But you can just google it as well.
> Of course, larger MTUs have better transfer rates. That is the old
> performance vs. size trade-off. If so configured, both end points
> should use the configured MTU of the network. However, they should also
> work with limited devices with smaller MTUs.
All very true. But it does mean that if you are on the same ethernet,
and one host have defined a smaller MTU, and you use UDP for example,
then larger packets might get lost without any feedback. Because UDP
have no clue about the other end having a different/smaller MTU.
TCP should usually manage, since MSS should reflect the local MTU, and
thus the other end knows it can't send larger packets than that, when
using TCP at least.
It's rather recommended that all hosts on a shared medium use the same
MTU, if possible. Otherwise there is a clear risk that communication
might not work as expected.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Re: STM32H7 ethernet hardfaults
Posted by Gregory Nutt <sp...@gmail.com>.
On 3/4/2021 4:59 PM, James Dougherty wrote:
> Thank you, that is interesting. Doesn't it also imply is that with the
> smaller MTU of 590 you'll end up having
> fragmentation which will add a little bit of processing overhead? I
> understand it is not that big of a deal since
> fragmentation happens a lot, but for the best performance yes, both sides
> have to agree on a decent MTU.
In TCP, both sides do agree. That is the negotiated MTU.
Of course, larger MTUs have better transfer rates. That is the old
performance vs. size trade-off. If so configured, both end points
should use the configured MTU of the network. However, they should also
work with limited devices with smaller MTUs.
Re: STM32H7 ethernet hardfaults
Posted by James Dougherty <ja...@gmail.com>.
Thank you, that is interesting. Doesn't it also imply is that with the
smaller MTU of 590 you'll end up having
fragmentation which will add a little bit of processing overhead? I
understand it is not that big of a deal since
fragmentation happens a lot, but for the best performance yes, both sides
have to agree on a decent MTU.
On Thu, Mar 4, 2021 at 2:39 PM Gregory Nutt <sp...@gmail.com> wrote:
> > John, to answer your question on ethernet, 1500 is a very common MTU. For
> > VLAN tagged frame support (802.1Q VLAN ID ), 1518 bytes (1522 bytes on
> the
> > wire with 4-byte / 32-bit ETH CRC32), for Jumbo frames (not IEEE) 9122 is
> > common. Minimum frame size with CRC is 64-bytes and zero padding is
> common,
> > < 64 is considered a runt frame. And note if ethernet_len field is 0x800
> > you have an IP packet. Good luck on STM32H7 ethernet hardfault debug.
>
> The MTU is a property of a network that is controlled by the network
> configuration. These are the "standard" MTUs used on commercial
> networks and are pervasive in commercial networks. Other MTUs are
> theoretically possible for custom networks but are not supported by the
> H7 Ethernet MAC.
>
> The value 590 is the minimum size that you can use for a fully
> functional network. It is not commonly used but perfectly valid.
> Increasing this default would break some configurations. Some older
> parts, such as LPC17xx have plenty of SRAM, but are constrained to a
> very small bank of DMA-able memory for Ethernet and USB.
>
> Ethernet MACs that are not able to support certain packet sizes need to
> have checks to prohibit selection of sizes that they cannot support.
>
>
>
Re: STM32H7 ethernet hardfaults
Posted by Gregory Nutt <sp...@gmail.com>.
> John, to answer your question on ethernet, 1500 is a very common MTU. For
> VLAN tagged frame support (802.1Q VLAN ID ), 1518 bytes (1522 bytes on the
> wire with 4-byte / 32-bit ETH CRC32), for Jumbo frames (not IEEE) 9122 is
> common. Minimum frame size with CRC is 64-bytes and zero padding is common,
> < 64 is considered a runt frame. And note if ethernet_len field is 0x800
> you have an IP packet. Good luck on STM32H7 ethernet hardfault debug.
The MTU is a property of a network that is controlled by the network
configuration. These are the "standard" MTUs used on commercial
networks and are pervasive in commercial networks. Other MTUs are
theoretically possible for custom networks but are not supported by the
H7 Ethernet MAC.
The value 590 is the minimum size that you can use for a fully
functional network. It is not commonly used but perfectly valid.
Increasing this default would break some configurations. Some older
parts, such as LPC17xx have plenty of SRAM, but are constrained to a
very small bank of DMA-able memory for Ethernet and USB.
Ethernet MACs that are not able to support certain packet sizes need to
have checks to prohibit selection of sizes that they cannot support.
Re: STM32H7 ethernet hardfaults
Posted by James Dougherty <ja...@gmail.com>.
John, to answer your question on ethernet, 1500 is a very common MTU. For
VLAN tagged frame support (802.1Q VLAN ID ), 1518 bytes (1522 bytes on the
wire with 4-byte / 32-bit ETH CRC32), for Jumbo frames (not IEEE) 9122 is
common. Minimum frame size with CRC is 64-bytes and zero padding is common,
< 64 is considered a runt frame. And note if ethernet_len field is 0x800
you have an IP packet. Good luck on STM32H7 ethernet hardfault debug.
On Thu, Mar 4, 2021 at 12:46 PM John Rippetoe <jr...@roboticresearch.com>
wrote:
> Hello All,
>
> I've been playing around with networking on the STM32H7 and am seeing
> hardfaults that appear to be related to NET_ETH_PKTSIZE. From the log
> below, the driver would appear to be dropping packets that are too large
> to fit into the default packet size of 590. By increasing the packet
> size to the max (1518), the problem seems to disappear, but I am a
> little confused why the driver is able to catch the fact that the
> received packet was too large and drop it appropriately, but then crash.
> After poking around the ethernet driver, I think I understand the issue
> to be that because the MAC DMA does not know that the buffer it is
> writing into has a size limit, it is overflowing the buffer and writing
> into adjacent memory. Am I understanding this correctly?
>
> My main concern here is that increasing NET_ETH_PKTSIZE to the limit
> will only hide the issue for a time instead of solving it. A quick
> google search does show that the maximum ethernet frame size is 1518
> bytes though, so I am working under the assumption that maxing it out in
> my config will account for all possible frame sizes and eliminate this
> issue. I have no experience with low level networking protocols and
> standards, so I thought it would be prudent to seek out additional help
> to make sure I am on the right track.
>
> Thanks in advance.
>
> - John
>
> stm32_receive: WARNING: DROPPED Too big: 684
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> stm32_receive: WARNING: DROPPED Too big: 1332
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> stm32_receive: WARNING: DROPPED Too big: 1264
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> stm32_receive: WARNING: DROPPED Too big: 684
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> stm32_receive: WARNING: DROPPED Too big: 1364
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> stm32_receive: WARNING: DROPPED Too big: 1264
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> stm32_receive: WARNING: DROPPED Too big: 1436
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> stm32_receive: WARNING: DROPPED Too big: 1300
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> up_hardfault: PANIC!!! Hard fault: 40000000
> up_assert: Assertion failed at file:armv7-m/up_hardfault.c line: 148
> task: lpwork
> up_registerdump: R0: 24012080 2401206e 0000024e 00000000 24012000
> 40029160 24011fc0 00008040
> up_registerdump: R8: 40029134 24011f00 24011fe0 240120b8 00000001
> 38002f88 080a26a7 080a2538
> up_registerdump: xPSR: 81000000 BASEPRI: 000000f0 CONTROL: 00000000
> up_registerdump: EXC_RETURN: ffffffe9
> up_dumpstate: sp: 24010bb0
> up_dumpstate: IRQ stack:
> up_dumpstate: base: 24010c00
> up_dumpstate: size: 00000200
> up_dumpstate: used: 00000140
> up_stackdump: 24010ba0: 24010bb0 2400e830 0000064c 080a0fed 000000f0
> 00000000 240120b8 00000001
> up_stackdump: 24010bc0: 38002f88 080a26a7 080a2538 0816625a 00000000
> 080a129f 080a1271 080f754f
> up_stackdump: 24010be0: 000000f0 080a2935 000000f0 38002eb4 40029160
> 24011fc0 00008040 080a1b8f
> up_dumpstate: sp: 38002f88
> up_dumpstate: User stack:
> up_dumpstate: base: 38003008
> up_dumpstate: size: 0000064c
> up_dumpstate: used: 000003e0
> up_stackdump: 38002f80: 00000010 080a269b 24012050 24012000 00000000
> 24012010 2400b430 00000000
> up_stackdump: 38002fa0: 000000f0 00000080 00000000 00000000 00005ec8
> 0809d2e7 ffffffff ffffffff
> up_stackdump: 38002fc0: 00005ec8 00000001 00000010 00020000 39276cac
> 2400b430 00000000 00000000
> up_stackdump: 38002fe0: 00000000 00000000 00000000 00000000 00000000
> 0809c501 0809c4f1 0809bed5
> up_stackdump: 38003000: 00000000 00000000 deadbeef 38003014 00000000
> 6f77706c de006b72 7b93d153
> up_taskdump: Idle Task: PID=0 Stack Used=0 of 0
> up_taskdump: hpwork: PID=1 Stack Used=352 of 2028
> up_taskdump: lpwork: PID=2 Stack Used=992 of 1612
> up_taskdump: init: PID=3 Stack Used=1544 of 2980
>
>
> CONFIDENTIALITY NOTICE: This communication may contain private,
> confidential and privileged material for the sole use of the intended
> recipient. If you are not the intended recipient, please delete this e-mail
> and any attachments permanently.
>
>
Re: STM32H7 ethernet hardfaults
Posted by Gregory Nutt <sp...@gmail.com>.
I think this behavior is pretty clear from reading the H7 reference
manual. The H7 Ethernet MAC supports only three maximum packet size,
standard (1518 or 1522 if tagged), 2K, and Jumbo (9018 or 9022 if
tagged). The Jumbo packet selection is controlled by settings in registers.
So while 590 is a valid minimum packet size, it is not valid for the H7
(and possibly other MACs). The packet size should be hard coded to 1518
or 1522 for that part (or 9018 or 9022 if Jumbo packet support is needed).
On 3/4/2021 2:46 PM, John Rippetoe wrote:
> Hello All,
>
> I've been playing around with networking on the STM32H7 and am seeing
> hardfaults that appear to be related to NET_ETH_PKTSIZE. From the log
> below, the driver would appear to be dropping packets that are too
> large to fit into the default packet size of 590. By increasing the
> packet size to the max (1518), the problem seems to disappear, but I
> am a little confused why the driver is able to catch the fact that the
> received packet was too large and drop it appropriately, but then
> crash. After poking around the ethernet driver, I think I understand
> the issue to be that because the MAC DMA does not know that the buffer
> it is writing into has a size limit, it is overflowing the buffer and
> writing into adjacent memory. Am I understanding this correctly?
>
> My main concern here is that increasing NET_ETH_PKTSIZE to the limit
> will only hide the issue for a time instead of solving it. A quick
> google search does show that the maximum ethernet frame size is 1518
> bytes though, so I am working under the assumption that maxing it out
> in my config will account for all possible frame sizes and eliminate
> this issue. I have no experience with low level networking protocols
> and standards, so I thought it would be prudent to seek out additional
> help to make sure I am on the right track.
>
> Thanks in advance.
>
> - John
>
> stm32_receive: WARNING: DROPPED Too big: 684
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> stm32_receive: WARNING: DROPPED Too big: 1332
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> stm32_receive: WARNING: DROPPED Too big: 1264
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> stm32_receive: WARNING: DROPPED Too big: 684
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> stm32_receive: WARNING: DROPPED Too big: 1364
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> stm32_receive: WARNING: DROPPED Too big: 1264
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> stm32_receive: WARNING: DROPPED Too big: 1436
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> stm32_receive: WARNING: DROPPED Too big: 1300
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> up_hardfault: PANIC!!! Hard fault: 40000000
> up_assert: Assertion failed at file:armv7-m/up_hardfault.c line: 148
> task: lpwork
> up_registerdump: R0: 24012080 2401206e 0000024e 00000000 24012000
> 40029160 24011fc0 00008040
> up_registerdump: R8: 40029134 24011f00 24011fe0 240120b8 00000001
> 38002f88 080a26a7 080a2538
> up_registerdump: xPSR: 81000000 BASEPRI: 000000f0 CONTROL: 00000000
> up_registerdump: EXC_RETURN: ffffffe9
> up_dumpstate: sp: 24010bb0
> up_dumpstate: IRQ stack:
> up_dumpstate: base: 24010c00
> up_dumpstate: size: 00000200
> up_dumpstate: used: 00000140
> up_stackdump: 24010ba0: 24010bb0 2400e830 0000064c 080a0fed 000000f0
> 00000000 240120b8 00000001
> up_stackdump: 24010bc0: 38002f88 080a26a7 080a2538 0816625a 00000000
> 080a129f 080a1271 080f754f
> up_stackdump: 24010be0: 000000f0 080a2935 000000f0 38002eb4 40029160
> 24011fc0 00008040 080a1b8f
> up_dumpstate: sp: 38002f88
> up_dumpstate: User stack:
> up_dumpstate: base: 38003008
> up_dumpstate: size: 0000064c
> up_dumpstate: used: 000003e0
> up_stackdump: 38002f80: 00000010 080a269b 24012050 24012000 00000000
> 24012010 2400b430 00000000
> up_stackdump: 38002fa0: 000000f0 00000080 00000000 00000000 00005ec8
> 0809d2e7 ffffffff ffffffff
> up_stackdump: 38002fc0: 00005ec8 00000001 00000010 00020000 39276cac
> 2400b430 00000000 00000000
> up_stackdump: 38002fe0: 00000000 00000000 00000000 00000000 00000000
> 0809c501 0809c4f1 0809bed5
> up_stackdump: 38003000: 00000000 00000000 deadbeef 38003014 00000000
> 6f77706c de006b72 7b93d153
> up_taskdump: Idle Task: PID=0 Stack Used=0 of 0
> up_taskdump: hpwork: PID=1 Stack Used=352 of 2028
> up_taskdump: lpwork: PID=2 Stack Used=992 of 1612
> up_taskdump: init: PID=3 Stack Used=1544 of 2980
>
>
> CONFIDENTIALITY NOTICE: This communication may contain private,
> confidential and privileged material for the sole use of the intended
> recipient. If you are not the intended recipient, please delete this
> e-mail and any attachments permanently.
>