From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 1DCA142616; Fri, 22 Sep 2023 10:07:47 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0E6FC4029C; Fri, 22 Sep 2023 10:07:47 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mails.dpdk.org (Postfix) with ESMTP id DE8F340150 for ; Fri, 22 Sep 2023 10:07:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1695370065; 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=K3uh+wEPWYrN23bIIaI8JnodBoQvAxynfVMhQ7gaUlQ=; b=bty7eXVKpLJNJxLxjWvAfWmFfHpGkAPzKMDaRq1W096MBcyxZgazVqO/2r18iedATKfsoL Bp24PreIZudOdmSVV1wjSSI+Ykx3W34bGT4isHQKOmfWFd9lo94FSXI9A663mOpcevbO59 F2X1XWRhLZubUakZElcgNgahoqUI7SA= Received: from mail-lj1-f198.google.com (mail-lj1-f198.google.com [209.85.208.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-557-6NGLvd3lNTqxf7XG3ffUmQ-1; Fri, 22 Sep 2023 04:07:44 -0400 X-MC-Unique: 6NGLvd3lNTqxf7XG3ffUmQ-1 Received: by mail-lj1-f198.google.com with SMTP id 38308e7fff4ca-2c135cf1316so12925271fa.1 for ; Fri, 22 Sep 2023 01:07:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695370062; x=1695974862; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=K3uh+wEPWYrN23bIIaI8JnodBoQvAxynfVMhQ7gaUlQ=; b=Apre/x5vk1tBrSC7/k1GGBJmYZnJw+fQkwsZtNeLIO2VbTHjNsiaHAZkvXOzjmlltm gXwDKb6JBfCL1hOYorJyxuy4qvRZNXPfJZSn3pI+h6TLRZOnBpLKjICtHERov5xBjQKC BcFK68tj3m5S7/U7O5nMCEXFIWBg9xlpvAV9dWMD16V/BOTmhhrlwwOD/3FhjqUo7i8t 9gD1exMx7kuO50c0X1dLhlBl7gIkKQ8NDDSPfAYlFJ59zQAr9APh9D9y888Fb1QoDY0M 0XMXj0eMhUQnSF6jFjaG+BaZNeeTAKQOPs/r1cfGPTUijE9Qcx+1fMGsWRSeImZUze30 b+0A== X-Gm-Message-State: AOJu0YzfSJauWV2kHT9hOTlu21AbAY2Z5mJvxFw6HgZNiki6u3BYaeTX Wq1B0xUE7U8G4/iwJg/tEQfE3Ui+v87Zwcg94rivBhf9l2ilvO9VBqpdxTlqS9byHISkuRkUexW GZMGm4xzs3EspP6WNYh4= X-Received: by 2002:a2e:7410:0:b0:2c0:17bc:124e with SMTP id p16-20020a2e7410000000b002c017bc124emr7093723ljc.38.1695370062587; Fri, 22 Sep 2023 01:07:42 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFPeZZa4c+BxRQFlo1iZEnjzIOq1HauWyMXrUZboODdyERektMrCSzjFdraMFoCKn5hL/W5i8w4FiQUuyNTGkI= X-Received: by 2002:a2e:7410:0:b0:2c0:17bc:124e with SMTP id p16-20020a2e7410000000b002c017bc124emr7093710ljc.38.1695370062196; Fri, 22 Sep 2023 01:07:42 -0700 (PDT) MIME-Version: 1.0 References: <20230830155927.3566-1-syalavarthi@marvell.com> <20230830155927.3566-3-syalavarthi@marvell.com> In-Reply-To: From: David Marchand Date: Fri, 22 Sep 2023 10:07:30 +0200 Message-ID: Subject: Re: [EXT] Re: [PATCH v1 02/34] ml/cnxk: drop use of RTE API for firmware read To: Srikanth Yalavarthi Cc: Jerin Jacob , Prince Takkar , "dev@dpdk.org" , Shivah Shankar Shankar Narayan Rao , Anup Prabhu X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Hello, On Fri, Sep 22, 2023 at 5:59=E2=80=AFAM Srikanth Yalavarthi wrote: > > From: David Marchand > > On Thu, Sep 21, 2023 at 3:06=E2=80=AFPM Srikanth Yalavarthi > > wrote: > > > > > > archive. This causes the ML firmware binary to be parsed > > > > > > incorrectly. > > > > > > > > > > + @David Marchand rte_firmware_read() author for his opinions > > > > > > > > /lib/firmware/mlip-fw.bin does not seem to be something packaged in > > > > Fedora, and I found no trace in linux-firmware repo, so I can't > > > > reproduce your issue. > > > > > > > > Please add some debug and give more details about the issue you are > > facing. > > > > > > The "/lib/firmware/mlip-fw.bin" is Marvell's ML firmware binary. This= file is > > in un-compressed form. > > > > > > When DPDK is built without libarchive support, No issues are observed= with > > using rte_firmware_read to load the firmware file as open and read sys= tem > > calls are used. > > > > > > When libarchive support is enabled, rte_firmware_read tries to parse = the > > firmware binary as an xz archive. Since the file is not an archive, thi= s step is > > failing. > > > > Please debug this part and point at the exact place where it fails. > > When compiled with libarchive support, the code fails in firmware_open (l= ib/eal/unix/eal_firmware.c:24) function > > if (archive_read_support_format_raw(ctx->a) !=3D ARCHIVE_OK || """ archive_read_support_format_raw() The =E2=80=9Craw=E2=80=9D format handler allows libarchive to = be used to read arbitrary data. It treats any data stream as an archive with a single entry. The pathname of this entry is =E2=80=9Cdata=E2=80=9D; all ot= her entry fields are unset. This is not enabled by archive_read_support_format_all() in order to avoid erroneous handling of damaged archives. """ Which means that this instance of libarchive accepts "raw" archive. > archive_read_support_filter_xz(ctx->a) !=3D ARCHI= VE_OK || """ archive_read_support_filter_bzip2(), archive_read_support_filter_compress(), archive_read_support_filter_grzip(), archive_read_support_filter_gzip(), archive_read_support_filter_lrzip(), archive_read_support_filter_lz4(), archive_read_support_filter_lzma(), archive_read_support_filter_lzop(), archive_read_support_filter_none(), archive_read_support_filter_rpm(), archive_read_support_filter_uu(), archive_read_support_filter_xz(), archive_read_support_filter_zstd(), Enables auto-detection code and decompression support for the specified compression. These functions may fall back on external programs if an appropriate library was not available at build time. Decompression using an external program is usually slower than decompression through built-in libraries. Note that =E2=80=9Cnone=E2=80=9D is always ena= bled by default. """ Which means that this instance of libarchive accepts xz compressed files, and uncompressed files too because the "none" filter is enabled by default. > archive_read_open_filename(ctx->a, name, blocksiz= e) !=3D ARCHIVE_OK || > archive_read_next_header(ctx->a, &e) !=3D ARCHIVE= _OK) { > archive_read_free(ctx->a); > ctx->a =3D NULL; > return -1; > } > > I understand that all of the 4 checks in the if condition assume that the= file is a compressed archive. i.e, they look for relevant metadata of a co= mpressed archive. I had double checked before replying last time, it works as I described with my fedora libarchive. > All 4 checks were failing when the file being read is a single uncompress= ed file (as in our case). o_O Did you check that all 4 checks are failing individually or are you saying this 4 tests fail as a whole? I have one suspicion on archive_read_support_filter_xz, which may return ARCHIVE_WARN. But that's my only serious hint so far. I have put up some debug patch, please have a try with it. https://patchwork.dpdk.org/project/dpdk/patch/20230922080606.905222-1-david= .marchand@redhat.com/ --=20 David Marchand