Hey Przemek, I have submitted a new patch to solve the current issue: https://lists.osuosl.org/pipermail/intel-wired-lan/Week-of-Mon-20260629/055891.html I ran numerous tests on it and also verified it against the setup which initially triggered the issue. This system had a problem where ice_discover_flash_size read time was greater that 3 seconds and as a result failed with EBUSY status (FW at asome point releases the lock). With new patch issue was not reproduced even when the read time was much higher than normally expected: [ 75.999353] ice 0000:05:00.0: CQ CMD: opcode 0x0008, flags 0x2000, datalen 0x0000, retval 0x0000 <- First lock acquisition [ 82.152231] ice 0000:05:00.0: Predicted flash size is 10485760 bytes <- ice_discover_flash_size finished reading (7 seconds). In this case, the driver properly read the NVM contents without needing any retries.
I also analyzed the overhead of adding an acquire/release lock between each 0x0701 call and based on my observations it did not negatively impact the driver in any way. Execution time for ice_discover_flash_size in normal scenario increased from around 0,02s to 0,05s which should still be acceptable. Regards, Robert On Fri, Jun 26, 2026 at 1:46 PM Przemek Kitszel <[email protected]> wrote: > > On 6/26/26 10:15, Robert Malz wrote: > > Hey Przemek, > > I ran some tests and unfortunately, the following sentence from the > > datasheet is true: > > "For specific resources, such as Change Lock (0x0003) and Global Config Lock > > (0x0004), this field is used by software to override the default timeout > > for the > > operation, and also to specify the timeout used for this operation." > > > > This means we can only change a default timeout for 0x0003 and 0x0004 > > but not for 0x0001 (NVM resource). > > Whatever timeout I provide FW defaults to 0xB88 > > Input: > > [ 2209.656758] ice 0000:31:00.0: CQ CMD: opcode 0x0008, flags 0x2000, > > datalen 0x0000, retval 0x0000 > > [ 2209.656760] ice 0000:31:00.0: cookie (h,l) 0x00000000 0x00000000 > > [ 2209.656761] ice 0000:31:00.0: param (0,1) 0x00010001 0x00000BB9 > > Output: > > [ 2209.656927] ice 0000:31:00.0: CQ CMD: opcode 0x0008, flags 0x2003, > > datalen 0x0000, retval 0x0000 > > [ 2209.656929] ice 0000:31:00.0: cookie (h,l) 0x00000000 0x00000000 > > [ 2209.656931] ice 0000:31:00.0: param (0,1) 0x00010001 0x00000BB8 > > > > Correct me If I'm wrong, but the only way to properly handle it is to > > ensure the resource is locked and released between every > > ice_acquire_nvm call. > > I'll start working on this. > > thank you for checking out! > > I agree that simple retries with improved (refactored) locking will be > good solution. > Failure to lock should count as an unsuccessful attempt, with possible > retry after a sleep. > > > > > Regards, > > Robert > >
