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 8672AC433EF for ; Wed, 23 Mar 2022 09:51:50 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 1AAD583C0F; Wed, 23 Mar 2022 10:51:48 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=gmx.de Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; secure) header.d=gmx.net header.i=@gmx.net header.b="RUlYVNzr"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 4814B83C3A; Wed, 23 Mar 2022 10:51:46 +0100 (CET) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id C333883BDB for ; Wed, 23 Mar 2022 10:51:44 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmx.de Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=xypron.glpk@gmx.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1648029090; bh=/Rcru2E8CvbXiFPCBqLEw3XSlcUHEs+nlzdt1PJmKFU=; h=X-UI-Sender-Class:Date:Subject:To:References:From:Cc:In-Reply-To; b=RUlYVNzraFnvVdJDzbKr7trdj19ip+MfGoYTmMD5bG1t1zVwCpRgDdKvOz6/fNrZJ 5hu3n+UoiYkEItnss0mFildz0oOT4CpI8u7KmXAMs9Q5myRyDjhhxsoY0d6Cn1tJZM /ABwihi+8ocweygUlpnj7qzUQopqieRrD4hQgq/4= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.123.67] ([88.152.144.107]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MYeMt-1nb08P1SbL-00Vjur; Wed, 23 Mar 2022 10:51:30 +0100 Message-ID: Date: Wed, 23 Mar 2022 10:51:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: data abort when run 'dhcp' Content-Language: en-US To: qianfan 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> From: Heinrich Schuchardt Cc: u-boot@lists.denx.de In-Reply-To: <7884d265-3c73-a695-104f-0b34d3e8bc18@163.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:pJD5Ho/6mucxQfEN+J0dNWhhH0Ty3Yg5ljGv41NLvUBfdRF3np7 Clr9x2JMir6RNu9e5FEuPNJX9Un+9fIZUuTSGlyYkE12DPpl9LwOQ5GVisWYxxpBPMlP4PZ J0Kvh02L4uEFGwyTzowBG6clow4GxkecBHiZPD4M3F5J9vUry5Pf/1tZRXl2AE0QVl/nb52 3P/6cc13a/WoX3RpFxnmw== X-UI-Out-Filterresults: notjunk:1;V03:K0:Yb9xNSlaawg=:QKUX82jPuP/yNzsHkuAYfV 2Z7fva5b9S3mPs+TVVUFwSLUuf2YA2+8O/nnDDMw22QNi6UIXfHq1oacwravR5bIPMrn9Ry3t X8mfXLZuRixo9vDIbtgpvs/3jS3w3Dsaq8ktnm6IDaq29sxab/5htAFx0zLzf8qu3Wf+thasu r9eAx2np5Yp0etowMyYdLalivw6qBvIEZGadnZSUawDRDPIOv2oz1ieCA3qbImjSUrx48aOL5 UIoeFdidsEomDWc3OobffBDdX2t8bNHkkdcIAQG7d2GXxHQbr1lnURA3RZlpKdJxAHkwJZG3Y Yd8LUHzSr3mVgqo9wc2q8MFtW5sSDGAGj4sXYATe/eleIKipvNa9TRM2suCYxYBRSwdOe0e1C 3wMT6B63WUubSyjmiF/lV3H1ofz7kpiOvFmDIopxnAW9CpykOBmggBOJNeK1uc0GxC6fAa+FL d0ldWqBVOqQZXCgwJbIuHXApmqBWDh6uI/7L16MKIYGjnR/QPmdWp/18xDymH3kFmBiItMnEL nVbfaV1TPPhvhGsIGMw6/L4bglafg1m9LNc/TuDuQ6O05IA8IazA/exKXf12O15Vi4v4OSiXF njNHeqj8lBhH5EsGcNcALuzWQugyCmKpM9PrmOGuHpQ7gYxojnMrc/ougljM/st0MTrMWciZu x6vJ0HMAXt6aIeOjCW84fXUm6WFlqt3riFm8DvlxFOQCkBcY3vNzN75pu1BqXURGOWR8G01ko uEkewRcTJsQjNRo4QdAdx86AU2CHvJvr+rxfTP5f4JvQF3chfrEAN+XKEuLgqwdjir6ixZZ3C PlF4mErqdAcV0Z9q5sAZrQicp1tGVdKtKCx0DjcXlgkqhR4SfyzXX4UimmOBG/gKbkzgaz6Zd nYn1JnGGnDnctbYwyMJuuHN2obDGtghR1Li1jx9H35ebf7Ea+mM7S8JxPAM2chlIfQkybZSDd /qu+eYHNqbxxCRF3kIJ4b0jhsOv9MeSQPc0cn6lyoLiT+VfWm4fCnPJwwbChh1jWYkdFF4YlY oki+ch74SnSrl9e6vJFGjBSc6wh05GIO0i1DUkOLqvcvfNctSqjCiBAQp+qbJuSYrYjayVW5I xKIRXxy/W/kLBs= 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.5 at phobos.denx.de X-Virus-Status: Clean On 3/23/22 10:13, qianfan wrote: > > =E5=9C=A8 2022/3/23 16:02, qianfan =E5=86=99=E9=81=93: >> >> >> =E5=9C=A8 2022/3/23 15:45, qianfan =E5=86=99=E9=81=93: >>> >>> >>> =E5=9C=A8 2022/3/23 10:28, qianfan =E5=86=99=E9=81=93: >>>> >>>> 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 >>>> =3D> setenv autoload no >>>> =3D> dhcp >>>> 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 : 000000= 01 >>>> r10: 9de5345c=C2=A0 r9 : 9de67e80=C2=A0=C2=A0=C2=A0=C2=A0 r8 : 9febba= e5 >>>> r7 : 9de72c30=C2=A0 r6 : 9feec710=C2=A0=C2=A0=C2=A0=C2=A0 r5 : 000000= 0d=C2=A0 r4 : 00000018 >>>> r3 : 3fdd8e04=C2=A0 r2 : 00000002=C2=A0=C2=A0=C2=A0=C2=A0 r1 : 9feec7= 28=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 >>>> >>> This bug doesn't fixed on master code. I found v2021.01 is good and >>> v2021.04-rc2 is bad. >>> >>> Also I had tested this on beaglebone black with am335x_evm_defconfig, >>> 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_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() from the ca= llers 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() (Coverity = CID 316362). >>> >>> =C2=A0=C2=A0=C2=A0 In fat_unlink() return -EIO if flush_dirty_fat_buff= er() 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 before >>> e97eb638de0dc8f6e989e20eaeb0342f103cb917: >>> >>> * e97eb638de0dc8f6e989e20eaeb0342f103cb917 fs: fat: consistent error >>> 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 +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 >>> =3D> dhcp >>> 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) >>> =3D> >>> > "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 : 00000001 > r10: 9df38eac=C2=A0 r9 : 9df4ceb0=C2=A0=C2=A0=C2=A0=C2=A0 r8 : 9ffa1b7d > r7 : 9df52fd0=C2=A0 r6 : 9ffdbba8=C2=A0=C2=A0=C2=A0=C2=A0 r5 : 0000000d= =C2=A0 r4 : 00000018 > r3 : 3ff589e0=C2=A0 r2 : 9ffafa11=C2=A0=C2=A0=C2=A0=C2=A0 r1 : 9ffdbbc0= =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 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 set_inuse_bit_at_offset(victim, victim_s= ize); > 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 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=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. > > 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 #define DEBUG 1 #include #include Best regards Heinrich