Re: kern/57561: iwm device timeouts

[bsdprg%tuta.io@localhost]

The following reply was made to PR kern/57561; it has been noted by GNATS.

From: bsdprg%tuta.io@localhost
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/57561: iwm device timeouts
Date: Thu, 10 Aug 2023 21:27:00 +0200 (CEST)

 Aug 9, 2023, 06:05 by martin%duskware.de@localhost:
 
 > The following reply was made to PR kern/57561; it has been noted by GNATS.
 >
 > From: Martin Husemann <martin%duskware.de@localhost>
 > To: gnats-bugs%NetBSD.org@localhost
 > Cc:
 > Subject: Re: kern/57561: iwm device timeouts
 > Date: Wed, 9 Aug 2023 08:01:47 +0200
 >
 > [please reply to gnats-bugs, do not mail netbsd-bugs directly, and make
 > sure to keep the subject formatted properly]
 >
 >
 First of all, thanks a lot for letting me know the right mailing list, looking into the PR and providing feedback.
 
 > I don't understand two things:
 >
 > - why do you consider a TX queue "getting stuck" not a serious issue?
 > Are the queues just blocked for longer than our single watchdog
 > expects? Do they recover later? How fast?
 >
 >
 You are right. It's a serious issue. After thinking about it, I don't understand why this patch seems to work. I will dig deeper and add more diagnostics before creating a patch.
 
 
 > - why does the reset of the interface cause loss of network connection?
 > (sounds like a serious issue in the driver reset code, probably not
 > syncing current queue pointers with the hardware or something like
 > that) - independent of the issue you see, this bug needs to be fixed.
 >
 
 I think I used the word "reset" when I meant "stop". When the watchdog kicks in, the watchdog handler function (iwm_watchdog) calls iwm_stop, which is the "if_stop" handler, and it stops the interface.
 
 
 > This sounds like several bugs and your patch just papering over it.
 > Maybe (in the end) it is the best way forward, but it should be analyzed
 > in more detail.
 >
 > Martin
 >