netdev - Re: Tulip 21142 panic on physical link disconnect

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: <alpine.DEB.2.21.2506200144030.37405@angie.orcam.me.uk>
Date: Fri, 20 Jun 2025 01:57:05 +0100 (BST)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: Greg Chandler <chandleg@...ardsworks.org>
cc: Florian Fainelli <f.fainelli@...il.com>, stable@...r.kernel.org, 
    netdev@...r.kernel.org
Subject: Re: Tulip 21142 panic on physical link disconnect

On Thu, 19 Jun 2025, Greg Chandler wrote:

> > > I am still not sure why I could not see that warning on by Cobalt Qube2
> > > trying
> > > to reproduce Greg's original issue, that is with an IP assigned on the
> > > interface yanking the cable did not trigger a timer warning. It could be
> > > that
> > > machine is orders of magnitude slower and has a different CONFIG_HZ value
> > > that
> > > just made it less likely to be seen?
> > 
> >  Can it have a different PHY attached?  There's this code:
> > 
> > 	if (tp->chip_id == PNIC2)
> > 		tp->link_change = pnic2_lnk_change;
> > 	else if (tp->flags & HAS_NWAY)
> > 		tp->link_change = t21142_lnk_change;
> > 	else if (tp->flags & HAS_PNICNWAY)
> > 		tp->link_change = pnic_lnk_change;
> 
> I'm not sure which of us that was directed at, but for my onboard tulips:

 It was for Florian, as obviously your system does trigger the issue.

> I found a link to the datasheet (If needed), but have had mixed luck with
> alldatasheets:
> https://www.alldatasheet.com/datasheet-pdf/pdf/75840/MICRO-LINEAR/ML6698CH.html

 There's no need to chase hw documentation as the issue isn't directly 
related to it.

 As I noted in the earlier e-mail it seems a regression in the handling of 
`del_timer_sync', perhaps deliberate, introduced sometime between 5.18 and 
6.4.  I suggest that you try 5.18 (or 5.17 as it was 5.18.0-rc2 actually 
here that worked correctly) and see if it still triggers the problem and 
if it does not then bisect it (perhaps limiting the upper bound to 6.4 if 
it does trigger it for you, to save an iteration or a couple).  Once you 
know the offender you'll likely know the solution.  Or you can come back 
with results and ask for one if unsure.

 HTH,

  Maciej