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 9DD81EB64DC for ; Fri, 21 Jul 2023 11:54:34 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id BC8C88624A; Fri, 21 Jul 2023 13:54:31 +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="Ln/rFVZx"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id A524086272; Fri, 21 Jul 2023 13:54:29 +0200 (CEST) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::224]) (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 056E18621A for ; Fri, 21 Jul 2023 13:54:25 +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 B0605E0005; Fri, 21 Jul 2023 11:54:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1689940465; 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=rOQ3IRAhhvKCENhyf+OQssYDjbGnKZZcQEevQtfwhy4=; b=Ln/rFVZxMGs+H2vB00Laq5vjPyCY7ioo/9BweAJD3rQYhNeAnj9VlmbAzyY3FbQB24Unou gMKExj/ky8k9llL5NIrne1nDqWWv7G+UpUcNJVgviBaMTrjg6+a6M+8QPmjyXh6f1XrxFA /7qqhsehaSldHXGRPKIgEQSEjla605vA0gkA39DKMWbKiP2uShaOByJYNnp9vW2M2tCIy0 IiL2pzmywxTCAjXZ7hJcE7HNZ1yQGxoE6zSaexLXUxsIIgac4Wf/oJXzfag1y2d2ITg/9H YDWbkqp1NKsmxbX4aTXFKYYUAyXyNoz76DLBOYC7SXY9JqJ79Y8IAgakR3oqlQ== Date: Fri, 21 Jul 2023 13:54:23 +0200 From: Miquel Raynal To: Heinrich Schuchardt Cc: qianfan , u-boot@lists.denx.de, Tom Rini Subject: Re: data abort when run 'dhcp' Message-ID: <20230721135423.133f6ad8@xps-13> In-Reply-To: <8AC592D9-794D-4CC1-8CE4-6A606D0A1F91@gmx.de> 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> <20230720183917.74e1a46c@xps-13> <8AC592D9-794D-4CC1-8CE4-6A606D0A1F91@gmx.de> 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 Hi Heinrich, xypron.glpk@gmx.de wrote on Thu, 20 Jul 2023 19:55:39 +0200: > Am 20. Juli 2023 18:39:17 MESZ schrieb Miquel Raynal : > >Hello, > > > >qianfanguijin@163.com wrote on Fri, 25 Mar 2022 18:04:46 +0800: > > =20 > >> 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 o= k. > >>=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. =20 > > > >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 >=20 >=20 > Can this problem be reproduced on QEMU? I haven't tried on QEMU, what do you have in mind? What should we try to do? Thanks, Miqu=C3=A8l >=20 > Best regards >=20 > Heinrich=20 >=20 > > =20 > >>=20 > >> =E5=9C=A8 2022/3/24 17:33, qianfan =E5=86=99=E9=81=93: =20 > >> > > >> > =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: add= r 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 = : 00000001 > >> >>>>>>>> r10: 9de5345c=C2=A0 r9 : 9de67e80=C2=A0=C2=A0=C2=A0=C2=A0 r8 = : 9febbae5 > >> >>>>>>>> r7 : 9de72c30=C2=A0 r6 : 9feec710=C2=A0=C2=A0=C2=A0=C2=A0 r5 = : 0000000d=C2=A0 r4 : 00000018 > >> >>>>>>>> r3 : 3fdd8e04=C2=A0 r2 : 00000002=C2=A0=C2=A0=C2=A0=C2=A0 r1 = : 9feec728=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 t= he bug > >> >>>>>>>> is already fixed? > >> >>>>>>>> > >> >>>>>>>> Thanks > >> >>>>>>>> =20 > >> >>>>>>> This bug doesn't fixed on master code. I found v2021.01 is goo= d and > >> >>>>>>> v2021.04-rc2 is bad. > >> >>>>>>> > >> >>>>>>> Also I had tested this on beaglebone black with am335x_evm_def= config, > >> >>>>>>> has the simliar problem. > >> >>>>>>> > >> >>>>>>> find the first bug commit via 'git bisect': it told me that co= mmit > >> >>>>>>> e97eb638de0dc8f6e989e20eaeb0342f103cb917 broke it. But it is v= ery > >> >>>>>>> strange due to this commit doesn't touch any dhcp or network c= ode. > >> >>>>>>> > >> >>>>>>> =E2=9E=9C=C2=A0 u-boot-main git:(e97eb638de) =E2=9C=97 git bis= ect bug > >> >>>>>>> e97eb638de0dc8f6e989e20eaeb0342f103cb917 is the first bug comm= it > >> >>>>>>> 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 flus= h_dir() > >> >>>>>>> > >> >>>>>>> =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() fro= m the callers to the > >> >>>>>>> function. > >> >>>>>>> =C2=A0=C2=A0=C2=A0 Move mapping of errors to -EIO to the funct= ion. > >> >>>>>>> =C2=A0=C2=A0=C2=A0 Always check return value of flush_dir() (C= overity 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 b= efore > >> >>>>>>> e97eb638de0dc8f6e989e20eaeb0342f103cb917: > >> >>>>>>> > >> >>>>>>> * e97eb638de0dc8f6e989e20eaeb0342f103cb917 fs: fat: consistent= error > >> >>>>>>> handling for flush_dir() > >> >>>>>>> *=C2=A0=C2=A0 184aa6504143b452132e28cd3ebecc7b941cdfa1 Merge t= ag > >> >>>>>>> '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 fi= ne. > >> >>>>>>> > >> >>>>>>> U-Boot 2021.01-00688-g184aa65041-dirty (Mar 23 2022 - 15:07:56= +0800) > >> >>>>>>> > >> >>>>>>> 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 = first > >> >>>>>>> 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 : 0= 0000001 > >> >>>>> r10: 9df38eac=C2=A0 r9 : 9df4ceb0=C2=A0=C2=A0=C2=A0=C2=A0 r8 : 9= ffa1b7d > >> >>>>> r7 : 9df52fd0=C2=A0 r6 : 9ffdbba8=C2=A0=C2=A0=C2=A0=C2=A0 r5 : 0= 000000d=C2=A0 r4 : 00000018 > >> >>>>> r3 : 3ff589e0=C2=A0 r2 : 9ffafa11=C2=A0=C2=A0=C2=A0=C2=A0 r1 : 9= ffdbbc0=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(vic= tim, 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_= size); > >> >>>>> 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 ca= tch > >> >>>> this but assert() as defined in include/log.h does not stop the c= ode 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 m= essage =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= (char*)top' > failed. > >> > > >> > I had tried many times, do_check_chunk not always failed, and someti= mes it > report common/dlmalloc.c:802: do_check_chunk: Assertion `!chunk_is= _mmapped(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."= ) at lib/panic.c:49 > >> > #2=C2=A0 0x9ffb5696 in __assert_fail (assertion=3D, f= ile=3D out>, line=3D, function=3D= ) at lib/panic.c:56 > >> > #3=C2=A0 0x9ff76910 in do_check_inuse_chunk (p=3Dp@entry=3D0x9ffd720= 0) at > common/dlmalloc.c:866 > >> > #4=C2=A0 0x9ff769d6 in do_check_malloced_chunk (p=3Dp@entry=3D0x9ffd= 7200, s=3Ds@entry=3D24) > at common/dlmalloc.c:900 > >> > #5=C2=A0 0x9ff76da6 in malloc (bytes=3D) at common/dl= malloc.c:1552 > >> > #6=C2=A0 0x9ff96b72 in env_attr_walk (attr_list=3D, >= callback=3D0x9ff969f9 , priv=3D0x9df28dc8) at env/attr.c:70 > >> > #7=C2=A0 0x9ff96bc2 in env_attr_lookup (attr_list=3D,= name=3D out>, attributes=3D0x9df28dec "") at env/attr.c:184 > >> > #8=C2=A0 0x9ff97146 in env_callback_init (var_entry=3D0x9df46f60) at= env/callback.c:67 > >> > #9=C2=A0 0x9ffb36fc in hsearch_r (item=3D..., action=3DENV_ENTER, re= tval=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=3D0x9df442= c8, 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:20= 22 > >> > #19 parse_stream_outer (inp=3Dinp@entry=3D0x9df290e8, flag=3Dflag@en= try=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 = > include/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 s= tack?) > >> > =20 > >> >> > >> >> Best regards > >> >> > >> >> Heinrich > >> >> =20 > >> >>> printed. > >> >>> =20 > >> >>>> > >> >>>> #define DEBUG 1 > >> >>>> #include > >> >>>> #include > >> >>>> > >> >>>> Best regards > >> >>>> > >> >>>> Heinrich =20 > >> >>> =20