netdev - Re: bnxt_en 0000:01:09.1 s1p2: hwrm req_type 0xe0 seq id 0xcdf error 0x3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAKOOJTzOxWa-g18dLL2ohEuVK6_iOzdGehsuJENao8w6X1XpFw@mail.gmail.com>
Date:   Fri, 21 Aug 2020 11:43:59 -0700
From:   Edwin Peer <edwin.peer@...adcom.com>
To:     Marc Smith <msmith626@...il.com>
Cc:     Netdev <netdev@...r.kernel.org>
Subject: Re: bnxt_en 0000:01:09.1 s1p2: hwrm req_type 0xe0 seq id 0xcdf error 0x3

On Thu, Aug 20, 2020 at 9:28 AM Marc Smith <msmith626@...il.com> wrote:

> [45186.100161] bnxt_en 0000:01:09.1 s1p2: hwrm req_type 0xe0 seq id
> 0xcdf error 0x3
> ...
>
> If I've used the decoder ring correctly, these appear to be the
> req_type and error values:
> req_type -> HWRM_TEMP_MONITOR_QUERY
> error -> HWRM_ERR_CODE_RESOURCE_ACCESS_DENIED

You seem to be using it correctly, yes. ;)

> So I assume this is because VF's don't have access to the temperature
> sensors, either by design or something else is misconfigured. If this
> is expected for VF's, perhaps we could set those messages to silent if
> it's a VF PCI ID? Or handle this in bnxt_hwmon_open() if it's a VF PCI
> ID (eg, not do anything)?

I expect not exposing the temperature to VFs is by design. Thanks for
bringing this to attention, I'll look into it.

Regards,
Edwin Peer