Re: data abort when run 'dhcp'

[Miquel Raynal <miquel.raynal@bootlin.com>]

Hi qianfan,

qianfanguijin@163.com wrote on Fri, 21 Jul 2023 08:31:17 +0800:

> 在 2023/7/21 0:39, Miquel Raynal 写道:
> > Hello,
> >
> > qianfanguijin@163.com wrote on Fri, 25 Mar 2022 18:04:46 +0800:
> >  
> >> It's very strange. And I can't detect it's a bug of usb or dlmalloc.
> >>
> >> 1. Starting u-boot and dhcp via am335x's ethernet(cpsw driver), it's ok.
> >>
> >> 2. Starting u-boot and dhcp via am335x's usb net, data abort.
> >>
> >> 3. start fastboot, and CTRL C right now, dhcp via am335x's usb net, it's ok.  
> > I am sorry to re-open a thread that is one year old but this is
> > still an open bug. The BBB is affected. In particular the BBBW
> > because there is no Ethernet connector, which makes the Eth-over-USB
> > emulation even more important. All U-Boots since 2021 are affected:
> > spurious data aborts, usually at the end of network interactions (tftp,
> > ping). I could not bisect it because the boot was deeply broken as
> > well on a significant range of commits :-/.
> >
> > On my side I narrowed it down to an env update which fails in malloc as
> > well. If I comment the env update, it fails a bit later. It really
> > looks like a stack corruption which is either related to the Ethernet
> > USB gadget or the USB controller driver itself. Network transfers on
> > the BBBW using regular Ethernet does not trigger any error.
> >
> > I also observe the very strange "fix" mentioned above: starting and
> > killing fastboot makes all tftp pass... If anyone has more details to
> > share, or perhaps a subsequent thread giving more details, I would
> > really like to see this fixed upstream, I suppose I am not the only one
> > :-)  
> Hi:
> 
> Could you please try this two patches?
> 
> http://patchwork.ozlabs.org/project/uboot/patch/20220402025836.19374-1-qianfanguijin@163.com/
> 
> http://patchwork.ozlabs.org/project/uboot/patch/20220402025836.19374-2-qianfanguijin@163.com/

Indeed these patches work. I ended up rewriting one of them to propose
a different approach. I also found two other proposals for the same
issue which are still pending around. I hope this submission will make
it to avoid more time to be spent on this :-)

Thanks a lot for the pointers, I've Cc'ed you on the submissions.

Kind regards,
Miquèl