XPost: alt.os.linux.mint, alt.comp.os.windows-10   
   From: nospam@needed.invalid   
      
   On Fri, 2/7/2025 8:16 PM, Java Jive wrote:   
   > On 2025-02-07 23:04, David wrote:   
   >>   
   >> I thank you for prodding me into action, but I have already run all the   
   tests I could find at Dell.   
   >>   
   >> Here's one result:- https://i.ibb.co/kgqwBLbG/IMG-3158.jpg   
   >   
   > So why did you waste our collective time with this thread???!!!   
   >   
   > Plonk!   
   >   
      
   But that's just the history of diagnostic tests.   
      
   What I see in that picture, is the "typical result   
   of a coder not caring about their work".   
      
   One thing to check, is whether the diagnostic is running   
   as Administrator. Perhaps it is failing because it lacks   
   access to hardware registers.   
      
   There might be expectations about what kind of runtime   
   environment should be provided. Does it run from WinPE ?   
   Does it run from Safe Mode ? Are they using something   
   entirely different (not even Linux) for the test ?   
      
   The only diagnostic test that has ever impressed me,   
   was the diagnostic tests on a Sparc, in response to   
   flipping the switch to Test on the faceplate. When   
   that thing told you something was busted, it was   
   really busted.   
      
   I've purchased a couple diagnostics   
   a long time ago (for desktop computers), which looked   
   like "busy work" for some dev, and no clear picture that   
   they were intent on testing anything.   
      
   Any time a diagnostic test purports to test something   
   on the "critical path" for hardware, that path was   
   tested purely by the ability to be able to POST and boot   
   the computer. If you find such test items in a test list,   
   that tells you what percentage bullshit is in the test   
   suite.   
      
   Summary: Be suspicious of diagnostics. Use your head and   
            analyze what they propose to test. It's pretty easy   
            to spot the "busy work" versions where they threw   
            in test cases that have no business being there.   
      
            Also, be suspicious of tests which technically cannot   
            be safely conducted. The SMBUS has no industry-wide   
            accepted semaphore, to protect usage. Only one program can use   
            the SMBUS at a time. If two programs try to use it, and   
            a bus transfer is interrupted (and corrupted), that will   
            invalidate the results. To safely carry out such a test,   
            you need sufficient control of the runtime environment,   
            so that no second program can make accesses while the   
            "diagnostic" runs. Other buses, like LPC, don't have that   
            characteristic.   
      
            Sound should be test-able, as it is off to the side.   
            The HDAudio bus, you could likely give that a whack, without   
            side effects (this assumes there isn't a dialup networking   
            chip as a second item on the bus). You would still need a   
            runtime environment that is not doing register-level access   
            to some HDAudio codec chip.   
      
            Part of my job as a hardware guy, was writing enough   
            tests to prove hardware worked. My programming efforts   
            are a fly-speck compared to this stuff, but I've had to   
            think about the isolation aspects, and preventing system   
            activity from invalidating a test. Seeing as my hardware   
            was brand-new, there was usually no driver competing with   
            me for control. I could write my own interrupt handler   
            if I wanted.   
      
      Paul   
      
   --- SoupGate-DOS v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)