This SW WA didnt work so the HW team will have to review it.
** Changed in: linux-bluefield (Ubuntu)
Status: New => Invalid
** Changed in: linux-bluefield (Ubuntu Jammy)
Status: New => Invalid
--
You received this bug notification because you are a member of Kernel
Packages,
** Description changed:
SRU Justification:
[Impact]
- During the QA reboot test, the BF3 Vitesse PHY gets stuck in a bad
- state, resulting in no ip provisioning. The only way to recover is to
- toggle the PHY hard reset pin via GPIO17 (or powercycle cycle since it
- achieves just
Public bug reported:
SRU Justification:
[Impact]
During the QA reboot test, the BF3 Vitesse PHY gets stuck in a bad
state, resulting in no ip provisioning. The only way to recover is to
toggle the PHY hard reset pin via GPIO17 (or powercycle cycle since it
achieves just that). We might have
Public bug reported:
SRU Justification:
[Impact]
During the reboot test, QA found an intermittent issue where the OOB link is
down.
The link is down because the KSZ9031 PHY fails to complete autonegotiation.
Even under "normal" circumstances where autonegotiation completes,
it takes an
Public bug reported:
SRU Justification:
[Impact]
OCP3.0 project was discontinued and canceled so all stale code related to
that was removed.
The HID MLNXBF29 is used now for triggering a graceful shutdown for the Bobcat
board. On the bobcat board, the main board cpld issues the shutdown request
** Summary changed:
- mlxbf-gige: support bobcat
+ mlxbf-gige: support fixed phy for Bobcat
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-bluefield in Ubuntu.
https://bugs.launchpad.net/bugs/2054845
Title:
mlxbf-gige: support
Public bug reported:
SRU Justification:
[Impact]
Bobcat is a new board which doesn't have an external PHY connected to
the OOB. There are no MDIO busses involved and no PHY involved. The OOB
is directly connected to the switch (MAC to MAC). SO we need to use the
linux fixed phy to be able to
Public bug reported:
SRU Justification:
[Impact]
There is are several changes that needs to be made to pwr-mlxbf in focal:
* There is a race condition between gpio-mlxbf2.c driver being loaded and
pwr-mlxbf.c being loaded
* When the module is removed, there is a panic due to NULL pointer
Public bug reported:
SRU Justification:
[Impact]
There is a new feature request to replace the soft reset with a graceful reboot.
We will use acpi events triggered by the irq in the pwr-mlxbf file to trigger
the graceful reboot.
[Fix]
* Change the handling of GPIO7 (BF2) and GPIO6 (BF3).
Public bug reported:
SRU Justification:
[Impact]
After syncing up the gpio-mlxbf3.c driver with the upstreamed version, we
dropped the use of the valid_mask variable because kernels greater or equal to
6.2.0 dont need it.
This is no longer needed in kernel versions >= 6.2.0 because valid_mask
Public bug reported:
SRU Justification:
[Impact]
At the moment, the OOB port is enabled in the mlxbf_gige_probe
function. If the mlxbf_gige_open is not executed, this could cause
pause frames to increase in the case where there is high backgroud
traffic. This results in clogging the BMC port as
Public bug reported:
SRU Justification:
[Impact]
Cherry pick gpio-mlxbf3.c and pinctrl-mlxbf3.c patches from linux-next.
[Fix]
* Revert existing pinctrl-mlxbf3.c driver changes
* Revert existing gpio-mlxbf3.c driver changes
* Cherry-pick all the following commits from linux-next:
Public bug reported:
SRU Justification:
[Impact]
We have tested PXE boot successfully on the BlueField using grubaa64.efi and
grub.cfg but HTTP boot does not work.
During HTTP boot, UEFI is able to load the grubaa64.efi but doesn’t load
grub.cfg and goes instead into the grub rescue shell.
Public bug reported:
SRU Justification:
[Impact]
Running the following LTP (linux-test-project) script, causes
a kernel panic and a reboot of the DPU:
ltp/testcases/bin/read_all -d /sys -q -r 10
The above test reads all directory and files under /sys.
Reading the sysfs entry "large_icm" causes
Public bug reported:
SRU Justification:
[Impact]
Although the link is up, and the PHY interrupt is cleared, there is no
ip assigned. Nothing is being transmitted, and nothing is received. The
RX error count keeps on increasing (check ifconfig oob_net0). After
several minutes, the RX error count
Public bug reported:
SRU Justification:
[Impact]
We occasionally see a race condition (once every 350 reboots) where napi is
still
running (mlxbf_gige_poll) while a shutdown has been initiated through "reboot".
Since mlxbf_gige_poll is still running, it tries to access a NULL pointer and as
a
Public bug reported:
SRU Justification:
[Impact]
Add a new SMC call which allows setting the ARM boot progress state to
"OS is up".
[Fix]
* Add a new SMC call in mlxbf-bootctl which allows setting the ARM boot
progress state to "OS is up".
[Test Case]
* Check that
Since these patches have been acked for upstreaming but are not yet added to
any upstreaming branch, we will wait for another week before sending canonical
the patches.
Patches needed:
- pinctrl: Introduce struct pinfunction and PINCTRL_PINFUNCTION() macro
- [PATCH v4] gpio: mmio: handle
Public bug reported:
SRU Justification:
[Impact]
Support the BlueField-3 SoC GPIO driver for handling interrupts and providing
the option to change the direction and value of a GPIO.
Support the BlueField-3 SoC pin controller driver for allowing a select number
of GPIO pins to be manipulated
Public bug reported:
SRU Justification:
[Impact]
Although the link is up, and the PHY interrupt is cleared, there is no
ip assigned. Nothing is being transmitted, and nothing is received. The
RX error count keeps on increasing (check ifconfig oob_net0). After
several minutes, the RX error count
Public bug reported:
SRU Justification:
[Impact]
GPIO chip irq members are exposed before they could be completely
initialized and this leads to race conditions.
One such issue was observed for the gc->irq.domain variable which
was accessed through the pwr-mlxbf.c driver in gpiochip_to_irq()
Public bug reported:
SRU Justification:
[Impact]
The BlueField-3 ICM carveout feature will enable NIC FW to bypass the SMMU
block to access DRAM memory.
The amount of memory accessible by FW will be controlled by ARM. This patch
enables setting the size of the large ICM carveout from
Public bug reported:
SRU Justification:
[Impact]
* Support GPIO driver for BlueField-3 SoCs.
[Fix]
* Support GPIO driver for BlueField-3 SoCs.
* Allows user to alter GPIO value when direction is set to output
* Support configuring GPIOs as interrupts for dependent drivers such as
pwr-mlxbf
** Description changed:
SRU Justification:
[Impact]
Several i2c-mlxbf.c patches have been upstreamed recently and are in
linux-next at the moment. So revert all changes in both Focal (5.4) and
Jammy (5.15) and cherry-pick all changes from linux-next master.
- IMPORTANT NOTE:
Public bug reported:
SRU Justification:
[Impact]
Several i2c-mlxbf.c patches have been upstreamed recently and are in
linux-next at the moment. So revert all changes in both Focal (5.4) and
Jammy (5.15) and cherry-pick all changes from linux-next master.
IMPORTANT NOTE: please make sure you
** Description changed:
SRU Justification:
[Impact]
Improve the driver dependency on the gpio driver. Move that dependency
to the probe as instructed by maintainers. Flush if there is remaining
- work while the driver is removed.
+ work while the driver is removed. fix size for zero
Public bug reported:
SRU Justification:
[Impact]
We are using the wrong variable name priv->smbus->io instead of
priv->mst_cause->io. This could result in unexpected i2c behavior.
[Fix]
* replace priv->smbus->io with priv->mst_cause->io
[Test Case]
* Make sure the i2c-mlxbf.c driver is
Public bug reported:
SRU Justification:
[Impact]
On later version of linux, ioremap_cache is deprecated so replace
ioremap_cache with ioremap since it is deprecated in later kernels.
[Fix]
* replace ioremap_nocache with ioremap
[Test Case]
* Make sure the i2c-mlxbf.c driver is loaded and
** Description changed:
SRU Justification:
[Impact]
- Support the I2C lock mechanism, otherwise there could be unexpected
- behavior when an i2c bus is accessed by several entities like the linux
- driver, ATF driver and UEFI driver. Replace ioremap_cache with ioremap
- since it is
** Description changed:
SRU Justification:
[Impact]
Support the I2C lock mechanism, otherwise there could be unexpected
- behavior when the i2c driver is accessed by several entities like the
- linux driver, ATF driver and UEFI driver.
+ behavior when an i2c bus is accessed by several
Public bug reported:
SRU Justification:
[Impact]
Support the I2C lock mechanism, otherwise there could be unexpected
behavior when the i2c driver is accessed by several entities like the
linux driver, ATF driver and UEFI driver.
[Fix]
* Support lock and unlock
* replace ioremap_nocache with
Public bug reported:
SRU Justification:
[Impact]
At the moment, the mlxbf-gige is broken in the ubuntu image because it is out
of date. This change in the gpio-mlxbf2.c driver broke it:
https://code.launchpad.net/~asmaam/ubuntu/+source/linux-bluefield/+git/version-seeds/+merge/417771
Public bug reported:
SRU Justification:
[Impact]
Although the gpio-mlxbf2.c driver has already been upstreamed, it did not
include gpio interrupt handling. We recently upstreamed the latter and as
requested by maintainers, moved all gpio interrupt code from the mlxbf-gige
driver to the
Public bug reported:
SRU Justification:
[Impact]
This is reproducible on systems which already have heavy background
traffic. On top of that, the user issues one of the 2 docker pulls below:
docker pull nvcr.io/ea-doca-hbn/hbn/hbn:latest
OR
docker pull
** Description changed:
SRU Justification:
[Impact]
The mlxbf-gige driver has just been upstreamed so linux-bluefield needs to be
synced up with what we have upstreamed.
- IMPORTANT: during testing phase, make sure the latest UEFI (bootloader) is
loaded on top of these changes.
+
** Description changed:
SRU Justification:
[Impact]
- The mlxbf-gige driver has just been upstreamed so linux-bluefield needs
- to be synced up with what we have upstreamed.
+ The mlxbf-gige driver has just been upstreamed so linux-bluefield needs to be
synced up with what we have
Public bug reported:
SRU Justification:
[Impact]
The mlxbf-gige driver has just been upstreamed so linux-bluefield needs
to be synced up with what we have upstreamed.
[Fix]
* Cleaned up the gige driver as instructed by maintainers
* removed dependency between the mlxbf-gige driver and
Public bug reported:
SRU Justification:
[Impact]
There could be stack overflow in mlxbf_i2c_smbus_start_transaction().
memcpy() is called in a loop while 'operation->length' upper bound is not
checked and 'data_idx' also increments.
More details:
The operation length is verified by the caller
38 matches
Mail list logo
