From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 7016DEB64DA for ; Thu, 20 Jul 2023 16:39:26 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 740CF86807; Thu, 20 Jul 2023 18:39:24 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=bootlin.com header.i=@bootlin.com header.b="FxHXxlpA"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 345D686814; Thu, 20 Jul 2023 18:39:23 +0200 (CEST) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id C544C867A8 for ; Thu, 20 Jul 2023 18:39:19 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=miquel.raynal@bootlin.com Received: by mail.gandi.net (Postfix) with ESMTPSA id 991321C0005; Thu, 20 Jul 2023 16:39:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1689871159; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=A1FCV41HNrs4hBB+U9G3ndRcMbgCfen6w02oR3QZL8s=; b=FxHXxlpAJCn7qAYu+X44AXbSS+9zqI2HASSDwHtQ7OV1X/xpzU9SXkVU+zZ0TKRHnwHgAB Pm1bC660/kEIEkJa7v+FCJlUH0xBHz3czBopEb8qH8tQppRwkg5T4NlhlYUJ30BePTJScg whaTBCnUrfqijN0L8HSdaCrhUCfsPyrQXK1kjmpyqCZubRbsEKeoH8ayXNOUr8rg6TgUJl GOaGgkqP+C8/J5i7eZKHxj0nrEail4Y+PsilbRgD5JsTVQKXfnsF4UeJZAYia1Y3iE9SjR 2GIlqkZU07yWuEOhKgoLQSQuzEh0qByVhtpRPc/CkskcLJ4gTzAi2Z/HsQG0wQ== Date: Thu, 20 Jul 2023 18:39:17 +0200 From: Miquel Raynal To: qianfan Cc: Heinrich Schuchardt , u-boot@lists.denx.de, Tom Rini Subject: Re: data abort when run 'dhcp' Message-ID: <20230720183917.74e1a46c@xps-13> In-Reply-To: References: <7536b9e1-de7a-a492-6951-485d4eb75df1@163.com> <2fe3a2a4-ec68-b18f-3446-ae6cb4de6d32@163.com> <23003c48-f525-f886-a241-e7bac7a68643@163.com> <7884d265-3c73-a695-104f-0b34d3e8bc18@163.com> <2930a323-e860-e334-28ee-b0edb524960d@163.com> Organization: Bootlin X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-GND-Sasl: miquel.raynal@bootlin.com X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.8 at phobos.denx.de X-Virus-Status: Clean 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. >=20 > 1. Starting u-boot and dhcp via am335x's ethernet(cpsw driver), it's ok. >=20 > 2. Starting u-boot and dhcp via am335x's usb net, data abort. >=20 > 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 :-) Thanks, Miqu=C3=A8l >=20 > =E5=9C=A8 2022/3/24 17:33, qianfan =E5=86=99=E9=81=93: > > > > =E5=9C=A8 2022/3/23 18:12, Heinrich Schuchardt =E5=86=99=E9=81=93: =20 > >> On 3/23/22 11:07, qianfan wrote: =20 > >>> > >>> =E5=9C=A8 2022/3/23 17:51, Heinrich Schuchardt =E5=86=99=E9=81=93: =20 > >>>> On 3/23/22 10:13, qianfan wrote: =20 > >>>>> > >>>>> =E5=9C=A8 2022/3/23 16:02, qianfan =E5=86=99=E9=81=93: =20 > >>>>>> > >>>>>> > >>>>>> =E5=9C=A8 2022/3/23 15:45, qianfan =E5=86=99=E9=81=93: =20 > >>>>>>> > >>>>>>> > >>>>>>> =E5=9C=A8 2022/3/23 10:28, qianfan =E5=86=99=E9=81=93: =20 > >>>>>>>> > >>>>>>>> Hi: > >>>>>>>> > >>>>>>>> I had a custom AM335X board connected my computer by usbnet. It > >>>>>>>> always report data abort when 'dhcp': > >>>>>>>> > >>>>>>>> Next it the log: > >>>>>>>> > >>>>>>>> U-Boot 2022.01-rc1-00183-gfa5b4e2d19-dirty (Feb 25 2022 - 15:45:= 02 > >>>>>>>> +0800) > >>>>>>>> > >>>>>>>> CPU=C2=A0 : AM335X-GP rev 2.1 > >>>>>>>> Model: WISDOM AM335X CCT > >>>>>>>> DRAM:=C2=A0 512 MiB > >>>>>>>> NAND:=C2=A0 256 MiB > >>>>>>>> MMC:=C2=A0=C2=A0 OMAP SD/MMC: 0 > >>>>>>>> Loading Environment from NAND... *** Warning - bad CRC, using > >>>>>>>> default environment > >>>>>>>> > >>>>>>>> Net:=C2=A0=C2=A0 Could not get PHY for ethernet@4a100000: addr 0 > >>>>>>>> eth2: ethernet@4a100000, eth3: usb_ether > >>>>>>>> Hit any key to stop autoboot:=C2=A0 0 =20 > >>>>>>>> =3D> setenv autoload no > >>>>>>>> =3D> dhcp =20 > >>>>>>>> using musb-hdrc, OUT ep1out IN ep1in STATUS ep2in > >>>>>>>> MAC de:ad:be:ef:00:01 > >>>>>>>> HOST MAC de:ad:be:ef:00:00 > >>>>>>>> RNDIS ready > >>>>>>>> musb-hdrc: peripheral reset irq lost! > >>>>>>>> high speed config #2: 2 mA, Ethernet Gadget, using RNDIS > >>>>>>>> USB RNDIS network up! > >>>>>>>> BOOTP broadcast 1 > >>>>>>>> BOOTP broadcast 2 > >>>>>>>> BOOTP broadcast 3 > >>>>>>>> DHCP client bound to address 192.168.200.4 (757 ms) > >>>>>>>> data abort > >>>>>>>> pc : [<9fe9b0a2>]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 lr : [<9febbc3f>] > >>>>>>>> reloc pc : [<808130a2>]=C2=A0=C2=A0=C2=A0 lr : [<80833c3f>] > >>>>>>>> sp : 9de53410=C2=A0 ip : 9de53578=C2=A0=C2=A0=C2=A0=C2=A0 fp : 0= 0000001 > >>>>>>>> r10: 9de5345c=C2=A0 r9 : 9de67e80=C2=A0=C2=A0=C2=A0=C2=A0 r8 : 9= febbae5 > >>>>>>>> r7 : 9de72c30=C2=A0 r6 : 9feec710=C2=A0=C2=A0=C2=A0=C2=A0 r5 : 0= 000000d=C2=A0 r4 : 00000018 > >>>>>>>> r3 : 3fdd8e04=C2=A0 r2 : 00000002=C2=A0=C2=A0=C2=A0=C2=A0 r1 : 9= feec728=C2=A0 r0 : 9feec700 > >>>>>>>> Flags: Nzcv=C2=A0 IRQs off=C2=A0 FIQs on=C2=A0 Mode SVC_32 (T) > >>>>>>>> Code: f023 0303 60ca 4403 (6091) 685a > >>>>>>>> Resetting CPU ... > >>>>>>>> > >>>>>>>> resetting ... > >>>>>>>> > >>>>>>>> > >>>>>>>> It's there has any doc about how to debug data abort? Or is the = bug > >>>>>>>> is already fixed? > >>>>>>>> > >>>>>>>> Thanks > >>>>>>>> =20 > >>>>>>> This bug doesn't fixed on master code. I found v2021.01 is good a= nd > >>>>>>> v2021.04-rc2 is bad. > >>>>>>> > >>>>>>> Also I had tested this on beaglebone black with am335x_evm_defcon= fig, > >>>>>>> has the simliar problem. > >>>>>>> > >>>>>>> find the first bug commit via 'git bisect': it told me that commit > >>>>>>> e97eb638de0dc8f6e989e20eaeb0342f103cb917 broke it. But it is very > >>>>>>> strange due to this commit doesn't touch any dhcp or network code. > >>>>>>> > >>>>>>> =E2=9E=9C=C2=A0 u-boot-main git:(e97eb638de) =E2=9C=97 git bisect= bug > >>>>>>> e97eb638de0dc8f6e989e20eaeb0342f103cb917 is the first bug commit > >>>>>>> commit e97eb638de0dc8f6e989e20eaeb0342f103cb917 > >>>>>>> Author: Heinrich Schuchardt > >>>>>>> Date:=C2=A0=C2=A0 Wed Jan 20 22:21:53 2021 +0100 > >>>>>>> > >>>>>>> =C2=A0=C2=A0=C2=A0 fs: fat: consistent error handling for flush_d= ir() > >>>>>>> > >>>>>>> =C2=A0=C2=A0=C2=A0 Provide function description for flush_dir(). > >>>>>>> =C2=A0=C2=A0=C2=A0 Move all error messages for flush_dir() from t= he callers to the > >>>>>>> function. > >>>>>>> =C2=A0=C2=A0=C2=A0 Move mapping of errors to -EIO to the function. > >>>>>>> =C2=A0=C2=A0=C2=A0 Always check return value of flush_dir() (Cove= rity CID 316362). > >>>>>>> > >>>>>>> =C2=A0=C2=A0=C2=A0 In fat_unlink() return -EIO if flush_dirty_fat= _buffer() fails. > >>>>>>> > >>>>>>> =C2=A0=C2=A0=C2=A0 Signed-off-by: Heinrich Schuchardt > >>>>>>> > >>>>>>> :040000 040000 2281a449f2d134078d7faa1ee735a367b55aad7e > >>>>>>> 77d188b1c99181fd71f2167fdeee3434a09db209 M=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 fs > >>>>>>> > >>>>>>> > >>>>>>> 184aa6504143b452132e28cd3ebecc7b941cdfa1 is the first commit befo= re > >>>>>>> e97eb638de0dc8f6e989e20eaeb0342f103cb917: > >>>>>>> > >>>>>>> * e97eb638de0dc8f6e989e20eaeb0342f103cb917 fs: fat: consistent er= ror > >>>>>>> handling for flush_dir() > >>>>>>> *=C2=A0=C2=A0 184aa6504143b452132e28cd3ebecc7b941cdfa1 Merge tag > >>>>>>> 'u-boot-rockchip-20210121' of > >>>>>>> https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip > >>>>>>> |\ > >>>>>>> | * 9ddc0787bd660214366e386ce689dd78299ac9d0 pci: Add Rockchip dwc > >>>>>>> based PCIe controller driver > >>>>>>> > >>>>>>> I checked 184aa6504143b452132e28cd3ebecc7b941cdfa1 can work fine. > >>>>>>> > >>>>>>> U-Boot 2021.01-00688-g184aa65041-dirty (Mar 23 2022 - 15:07:56 +0= 800) > >>>>>>> > >>>>>>> CPU=C2=A0 : AM335X-GP rev 2.1 > >>>>>>> Model: TI AM335x BeagleBone Black > >>>>>>> DRAM:=C2=A0 512 MiB > >>>>>>> WDT:=C2=A0=C2=A0 Started with servicing (60s timeout) > >>>>>>> NAND:=C2=A0 0 MiB > >>>>>>> MMC:=C2=A0=C2=A0 OMAP SD/MMC: 0, OMAP SD/MMC: 1 > >>>>>>> Loading Environment from FAT... not set. Validating fir= st > >>>>>>> E-fuse MAC > >>>>>>> Net:=C2=A0=C2=A0 eth2: ethernet@4a100000, eth3: usb_ether > >>>>>>> Hit any key to stop autoboot:=C2=A0 0 =20 > >>>>>>> =3D> dhcp =20 > >>>>>>> ethernet@4a100000 Waiting for PHY auto negotiation to > >>>>>>> complete......... TIMEOUT ! > >>>>>>> using musb-hdrc, OUT ep1out IN ep1in STATUS ep2in > >>>>>>> MAC de:ad:be:ef:00:01 > >>>>>>> HOST MAC de:ad:be:ef:00:00 > >>>>>>> RNDIS ready > >>>>>>> musb-hdrc: peripheral reset irq lost! > >>>>>>> high speed config #2: 2 mA, Ethernet Gadget, using RNDIS > >>>>>>> USB RNDIS network up! > >>>>>>> BOOTP broadcast 1 > >>>>>>> BOOTP broadcast 2 > >>>>>>> BOOTP broadcast 3 > >>>>>>> DHCP client bound to address 192.168.200.157 (757 ms) > >>>>>>> Using usb_ether device > >>>>>>> TFTP from server 192.168.200.1; our IP address is 192.168.200.157 > >>>>>>> Filename 'u-boot.img'. > >>>>>>> Load address: 0x82000000 > >>>>>>> Loading: > >>>>>>> ################################################################# > >>>>>>> ################################################################# > >>>>>>> ################################################################# > >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ################= ######### > >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2.5 MiB/s > >>>>>>> done > >>>>>>> Bytes transferred =3D 1123888 (112630 hex) =20 > >>>>>>> =3D> =20 > >>>>>>> =20 > >>>>> "data abort" messages: > >>>>> > >>>>> data abort > >>>>> pc : [<9ff8196c>]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 lr : [<9ffa1cd7>] > >>>>> reloc pc : [<8081496c>]=C2=A0=C2=A0=C2=A0 lr : [<80834cd7>] > >>>>> sp : 9df38e60=C2=A0 ip : 9df38fc8=C2=A0=C2=A0=C2=A0=C2=A0 fp : 0000= 0001 > >>>>> r10: 9df38eac=C2=A0 r9 : 9df4ceb0=C2=A0=C2=A0=C2=A0=C2=A0 r8 : 9ffa= 1b7d > >>>>> r7 : 9df52fd0=C2=A0 r6 : 9ffdbba8=C2=A0=C2=A0=C2=A0=C2=A0 r5 : 0000= 000d=C2=A0 r4 : 00000018 > >>>>> r3 : 3ff589e0=C2=A0 r2 : 9ffafa11=C2=A0=C2=A0=C2=A0=C2=A0 r1 : 9ffd= bbc0=C2=A0 r0 : 9ffdbb00 > >>>>> Flags: Nzcv=C2=A0 IRQs off=C2=A0 FIQs on=C2=A0 Mode SVC_32 (T) > >>>>> Code: 0303 60ca 4403 6091 (685a) f042 > >>>>> Resetting CPU ... > >>>>> > >>>>> objdump u-boot:pc is in malloc and lr is in env_attr_walk > >>>>> > >>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 unlink(victim, bck, fwd); > >>>>> 80814966:=C2=A0=C2=A0=C2=A0 60ca=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2= =A0=C2=A0=C2=A0 str=C2=A0=C2=A0=C2=A0 r2, [r1, #12] > >>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 set_inuse_bit_at_offset(victim= , victim_size); > >>>>> 80814968:=C2=A0=C2=A0=C2=A0 4403=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2= =A0=C2=A0=C2=A0 add=C2=A0=C2=A0=C2=A0 r3, r0 > >>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 unlink(victim, bck, fwd); > >>>>> 8081496a:=C2=A0=C2=A0=C2=A0 6091=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2= =A0=C2=A0=C2=A0 str=C2=A0=C2=A0=C2=A0 r1, [r2, #8] > >>>>> =C2=A0=C2=A0=C2=A0 =C2=A0set_inuse_bit_at_offset(victim, victim_siz= e); > >>>>> 8081496c:=C2=A0=C2=A0=C2=A0 685a=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2= =A0=C2=A0=C2=A0 ldr=C2=A0=C2=A0=C2=A0 r2, [r3, #4] > >>>>> 8081496e:=C2=A0=C2=A0=C2=A0 f042 0201 =C2=A0=C2=A0=C2=A0 orr.w=C2= =A0=C2=A0=C2=A0 r2, r2, #1 > >>>>> 80814972:=C2=A0=C2=A0=C2=A0 605a=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2= =A0=C2=A0=C2=A0 str=C2=A0=C2=A0=C2=A0 r2, [r3, #4] > >>>>> > >>>>> r3 is 3ff589e0 and it's not a valid ram address on am335x. > >>>>> > >>>>> =20 > >>>> > >>>> I have seen crashes in common/dlmalloc.c before after double free() = or > >>>> free() with an incorrect pointer. > >>>> > >>>> The assert() statements in do_check_inuse_chunk() are meant to catch > >>>> this but assert() as defined in include/log.h does not stop the code= and > >>>> even does not print without _DEBUG=3D1. > >>>> > >>>> You should be able to get the assert output with > >>>> > >>>> #include > >>>> #define _DEBUG 1 > >>>> #include > >>>> > >>>> at the top of common/dlmalloc.c. > >>>> > >>>> You should get full malloc debug output with =20 > >>> > >>> Hi: I had try add DEBUG marco before and no other malloc mess= age =20 > >> > >> assert() checks for _DEBUG. Defining DEBUG after common.h will not > >> define _DEBUG. =20 > > > > Finally I got a malloc error message on console: > > > > TFTP from server 192.168.200.1; our IP address is 192.168.200.39 > > Filename 'u-boot.img'. > > Load address: 0x82000000 > > Loading: ##############################################################= ### > > ################################################################# > > ################################################################# > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ######################= ################################=C2=A0 0 Bytes > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1.9 MiB/s > > done > > Bytes transferred =3D 1274816 (1373c0 hex) > > common/dlmalloc.c:819: do_check_chunk: Assertion `(char*)p + sz <=3D (c= har*)top' > failed. > > > > I had tried many times, do_check_chunk not always failed, and sometimes= it > report common/dlmalloc.c:802: do_check_chunk: Assertion `!chunk_is_mm= apped(p)' > failed. The situation is not the same. > > > > I got a bt stack when malloc failed: > > > > (gdb) bt > > #0=C2=A0 0x9ffb5684 in panic_finish () at lib/panic.c:23 > > #1=C2=A0 panic (fmt=3D0x9ffbd96b "%s:%u: %s: Assertion `%s' failed.") a= t lib/panic.c:49 > > #2=C2=A0 0x9ffb5696 in __assert_fail (assertion=3D, file= =3D out>, line=3D, function=3D) a= t lib/panic.c:56 > > #3=C2=A0 0x9ff76910 in do_check_inuse_chunk (p=3Dp@entry=3D0x9ffd7200) = at > common/dlmalloc.c:866 > > #4=C2=A0 0x9ff769d6 in do_check_malloced_chunk (p=3Dp@entry=3D0x9ffd720= 0, s=3Ds@entry=3D24) > at common/dlmalloc.c:900 > > #5=C2=A0 0x9ff76da6 in malloc (bytes=3D) at common/dlmal= loc.c:1552 > > #6=C2=A0 0x9ff96b72 in env_attr_walk (attr_list=3D, > ca= llback=3D0x9ff969f9 , priv=3D0x9df28dc8) at env/attr.c:70 > > #7=C2=A0 0x9ff96bc2 in env_attr_lookup (attr_list=3D, na= me=3D out>, attributes=3D0x9df28dec "") at env/attr.c:184 > > #8=C2=A0 0x9ff97146 in env_callback_init (var_entry=3D0x9df46f60) at en= v/callback.c:67 > > #9=C2=A0 0x9ffb36fc in hsearch_r (item=3D..., action=3DENV_ENTER, retva= l=3D0x9df28f60, > htab=3D0x9ffdbce8, flag=3D512) at lib/hashtable.c:403 > > #10 0x9ff7090e in _do_env_set (argc=3D, argv=3D, > env_flag=3D512, flag=3D0) at cmd/nvedit.c:296 > > #11 0x9ff70b64 in env_set (varname=3D, varvalue=3D) > at cmd/nvedit.c:318 > > #12 0x9ff6d522 in netboot_update_env () at cmd/net.c:133 > > #13 netboot_common (proto=3DDHCP, cmdtp=3D0x9ffdd0e8, argc=3D, > argv=3D0x9df442c8) at cmd/net.c:268 > > #14 0x9ff783a4 in cmd_call (repeatable=3D0x9df29008, argv=3D0x9df442c8,= argc=3D1, > flag=3D0, cmdtp=3D0x9ffdd0e8) at common/command.c:580 > > #15 cmd_process (flag=3D, argc=3D1, argv=3D0x9df442c8, >= repeatable=3D0x9ffdf6a0, ticks=3D0x0) at common/command.c:635 > > #16 0x9ff71d16 in run_pipe_real (pi=3D0x9df44220) at common/cli_hush.c:= 1676 > > #17 run_list_real (pi=3D) at common/cli_hush.c:1873 > > #18 0x9ff71e28 in run_list (pi=3D0x9df44220) at common/cli_hush.c:2022 > > #19 parse_stream_outer (inp=3Dinp@entry=3D0x9df290e8, flag=3Dflag@entry= =3D2) at > common/cli_hush.c:3206 > > #20 0x9ff721ba in parse_file_outer () at common/cli_hush.c:3289 > > #21 0x9ff77c1a in cli_loop () at common/cli.c:229 > > #22 0x9ff70d3e in main_loop () at common/main.c:66 > > #23 0x9ff72672 in run_main_loop () at common/board_r.c:584 > > #24 0x9ff72830 in initcall_run_list (init_sequence=3D0x9ffd7224) at > i= nclude/initcall.h:46 > > #25 board_init_r (new_gd=3D, dest_addr=3D= ) at > common/board_r.c:822 > > Backtrace stopped: previous frame identical to this frame (corrupt stac= k?) > > =20 > >> > >> Best regards > >> > >> Heinrich > >> =20 > >>> printed. > >>> =20 > >>>> > >>>> #define DEBUG 1 > >>>> #include > >>>> #include > >>>> > >>>> Best regards > >>>> > >>>> Heinrich =20 > >>> =20