linux-kernel - Re: [PATCH 4/4] MIPS: Avoid DIVU in `__div64

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.2104270511060.2587@angie.orcam.me.uk>
Date:   Tue, 27 Apr 2021 14:16:47 +0200 (CEST)
From:   "Maciej W. Rozycki" <macro@...am.me.uk>
To:     Thomas Bogendoerfer <tsbogend@...ha.franken.de>
cc:     "H. Nikolaus Schaller" <hns@...delico.com>,
        Arnd Bergmann <arnd@...db.de>,
        Huacai Chen <chenhuacai@...nel.org>,
        Huacai Chen <chenhuacai@...ngson.cn>,
        Jiaxun Yang <jiaxun.yang@...goat.com>,
        linux-arch@...r.kernel.org, linux-mips@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/4] MIPS: Avoid DIVU in `__div64_32' is result would be
 zero

On Thu, 22 Apr 2021, Maciej W. Rozycki wrote:

>  NB, I have benchmarked the update with my DECstation, however my Malta 
> has not come up after a reboot last evening and neither it has after a few 
> remote power cycles.  I have planned a visit in my lab next week anyway, 
> so I'll see what has happened there; hopefully I'm able to bring the board 
> back to life as I find it valuable for my purposes.  I had to replace the 
> PSU it came with already a couple years back and the new one is supposedly 
> high-quality, so I fear it's the board itself.

 For the record I have put the Malta back in service now.

 It was weird: the YAMON status shown on the ASCII display was "E:P_UNKN",
i.e. "Unknown PCI device on board (should never happen)" (according to the 
manual).  Indeed I never saw that message before.  By elimination I have 
tracked down the DEFPA FDDI network interface to be the culprit and upon a 
close inspection found a bent pin with the PFI ASIC (the PCI interface 
chip), a 160-pin 20-mil PQFP part.  It was IDSEL shorting to RST_L, the 
adjacent pin.  No wonder the card wreaked havoc with the system.  Fixed by 
carefully moving the pins apart with a razor blade (always good to have 
one at hand!).

 Now I wonder how this card happened to work with the pin bent for some
15 years and only finally developed a short now.  Weird indeed, and 
weirder even to see a second failure related to IC pins this year only.

  Maciej