Motherboard or drive problems

  • SpinRite v6.1 Release #3
    Guest:
    The 3rd release of SpinRite v6.1 is published and may be obtained by all SpinRite v6.0 owners at the SpinRite v6.1 Pre-Release page. (SpinRite will shortly be officially updated to v6.1 so this page will be renamed.) The primary new feature, and the reason for this release, was the discovery of memory problems in some systems that were affecting SpinRite's operation. So SpinRite now incorporates a built-in test of the system's memory. For the full story, please see this page in the "Pre-Release Announcements & Feedback" forum.
    /Steve.
  • Be sure to checkout “Tips & Tricks”
    Dear Guest Visitor → Once you register and log-in please checkout the “Tips & Tricks” page for some very handy tips!

    /Steve.
  • BootAble – FreeDOS boot testing freeware

    To obtain direct, low-level access to a system's mass storage drives, SpinRite runs under a GRC-customized version of FreeDOS which has been modified to add compatibility with all file systems. In order to run SpinRite it must first be possible to boot FreeDOS.

    GRC's “BootAble” freeware allows anyone to easily create BIOS-bootable media in order to workout and confirm the details of getting a machine to boot FreeDOS through a BIOS. Once the means of doing that has been determined, the media created by SpinRite can be booted and run in the same way.

    The participants here, who have taken the time to share their knowledge and experience, their successes and some frustrations with booting their computers into FreeDOS, have created a valuable knowledgebase which will benefit everyone who follows.

    You may click on the image to the right to obtain your own copy of BootAble. Then use the knowledge and experience documented here to boot your computer(s) into FreeDOS. And please do not hesitate to ask questions – nowhere else can better answers be found.

    (You may permanently close this reminder with the 'X' in the upper right.)

Zipdrive

Member
May 25, 2024
8
0
Following a successful run of Spinrite 6.1 my desktop and laptop PCs (and a failed run on a UEFI-only laptop), I tried running SR on my son's PC, based on an ASUStek B150M-A motherboard with four storage devices: A Samsung EVO SSD, two Samsung HDDs and a Hitachi HDD.
While Window is operation, all drives are accessible and seem fullly functional, but when loading SR6.1, I got error indications from one drive (in red) and an inability to access the other one (in gray). I'm not sure what the difference between the two is (something about recovering from reset command).
Moreover, As I tried running SR on the "viable" drives, it just wouldn't go anywhere. It ran for hours and hours on the SSD, not showing almost any progress, intermittantly clicking like crazy. Thinking there might be a major issue with the start of the drive, I stopped the run and started new runs at 5%, 50% and 80% of the drive, getting the same symptoms in all the spots.
Even though spinrite worked overnight (~14 hours) it did not manage to get much ahead and all I had to show for it was a single "U" sector (is U worse than B?)

I could really use some advice on what can be going on here. Is this a motherboard issue? How can all the drives show such a set of symptoms?
Thank you. any help is appreciated.
 

Attachments

  • copy1.jpg
    copy1.jpg
    47 KB · Views: 52
  • 20240517_114606.jpg
    20240517_114606.jpg
    67.6 KB · Views: 47
  • 20240517_114704.jpg
    20240517_114704.jpg
    63.9 KB · Views: 48
  • 20240517_120019.jpg
    20240517_120019.jpg
    56.5 KB · Views: 43
  • 20240518_075800.jpg
    20240518_075800.jpg
    56.9 KB · Views: 46
  • 20240518_085129.jpg
    20240518_085129.jpg
    67.1 KB · Views: 42
  • 20240518_090548.jpg
    20240518_090548.jpg
    37.9 KB · Views: 46
Can you move one of those drives to a different computer and try again?

Also, would you be willing to share the log files from the SRLOGS folder on your SpinRite boot drive?
 
I'm attaching the relevant logs. Note that I've had to rename the file extension tot txt as the forum attachment wouldn't accept ".log" files.
Moving the disks around will take some more time.
 

Attachments

  • 3.txt
    24.7 KB · Views: 35
Hmmm...it seems the forum won't accept my second, larger, log, probably due to its size (912KB). Any idea what the maximum allowed attachment size is?
 
Hmmm...it seems the forum won't accept my second, larger, log, probably due to its size (912KB). Any idea what the maximum allowed attachment size is?
I think it's around 500 kB. If you ZIP it, it will probably be small enough.
 
Hmm, your motherboard uses a very common Intel SATA controller (8086-A102). In fact, it's the same controller as my main testing machine. I was hoping your issues were being caused by an exotic controller 😁

Another odd thing is that there's no SMART data in either of your logs. There is definitely something strange going on with your machine.

Are the drives connected directly to the motherboard, or do you use something like a port multiplier?

Another thing to check is the SATA controller settings in the BIOS. For example, is it in RAID mode?
 
No RAID, and I wouldn't know a port multiplier if I ever saw one, but the drives are connected to the MB itself.
Regarding SMART data, I couldn't get any data in any of the computers I ran SR on, including my main desktop and old laptop, and even IIRC my work laptop using SR6.0
Attaching some logs for comparison.
 

Attachments

  • 0.txt
    11.1 KB · Views: 38
  • 1.txt
    10.4 KB · Views: 36
  • 2.txt
    8.8 KB · Views: 32
There's SMART data in all 3 of those logs. "End-of-Run SMART System Status", at the end of the scans against AHCI drives. It's normal for BIOS drives to not have SMART data. The scans in log #3 and 4 were against AHCI drives, so they definitely should have SMART data.

From log #0:
Code:
  |==========================================================================|
  |                      End-of-Run SMART System Status                      |
  |--------------------------------------------------------------------------|
  |  monitored param               margin         current/max    raw data    |
  |   ECC corrected  0 :::::::.......................  49/202 00000000000000 |
  |  rd chan margin  -                                                       |
  |  relocated sect  0 ::::::::::::::::::::::::::::::  90/90  00000000000000 |
  |  realloc events  0 :::::::::::::::::::::::::::::: 100/100 00000000000000 |
  |     seek errors  0 ::::::::::::::::::::::::::::::  49/49  00000000000000 |
  |   recal retries  0 :::::::::::::::::::::::::::::: 100/100 00000000000002 |
  |  cabling errors  0 :::::::::::::::::::::::::::::: 100/100 00000000000023 |
  |   uncorrectable  0 :::::::::::::::::::::::::::::: 100/100 00000000000000 |
  |    write errors  0 :::::::::::::::::::::::::::::: 100/100 00000000000000 |
  | command timeout  0 :::::::::::::::::::::::::::::: 100/100 00000000000000 |
  | pending sectors  0 :::::::::::::::::::::::::::::: 100/100 00000000000000 |
  |    read retries  -                                                       |
  |    total writes  -                                                       |
  |  write failures  -                                                       |
  |   wear leveling  -                                                       |
  |  remaining life  -                                                       |
  |   realloc space  -                                                       |
  |--------------------------------------------------------------------------|
  |                      drive temperature: 31'C/ 88'F                       |
  |==========================================================================|

One thing that could help Steve diagnose the problem with your B150M-A motherboard is a debug log. To generate one, call SpinRite with the "diags" parameter. If your boot drive launches straight into SpinRite, you'll have to exit it first. You don't have to run a scan, just launch it and exit. The file will end with .DBG, and will be in your SRLOGS folder.

Code:
spinrite.exe diags
 
It took a while, but I was able to run SR on the drives when they were attached to a different PC.
On the plus side the SSD, the Hitachi HDD and one of the Samsung HDDs all passed SR scans with flying colors.
On the other hand, the other Samsung HDD is apparently in such a shape that it put spinrite into a reboot loop. Any idea what that says?
Following the scans, they are still all usable on the original PC,
As a side issue, I couldn't figure out from windows 10 which of the physical drives is which logical ("letter") drive in order to back the problematic one up. Is there no easy way if figuring out if, say, drive D is the Hitachi or one of the Samsungs? Not to mention I can't tell which of the samsungs is which, as they are of identical model.
 
On the other hand, the other Samsung HDD is apparently in such a shape that it put spinrite into a reboot loop.
The entire computer is rebooting? Does this happen during Discovery, or during a scan?
As a side issue, I couldn't figure out from windows 10 which of the physical drives is which logical ("letter") drive in order to back the problematic one up.
You can correlate them by serial number. Run the following in PowerShell:
Code:
$Disks = Get-Disk
Get-Partition | Where-Object { $_.DriveLetter } | ForEach-Object {
    
    $PartitionDisk = $Disks | Where-Object Number -eq $_.DiskNumber
    [PSCustomObject]@{
        DriveLetter  = $_.DriveLetter
        DiskNumber   = $_.DiskNumber
        DiskModel    = $PartitionDisk.FriendlyName
        SerialNumber = $PartitionDisk.SerialNumber
        DiskSizeGB   = [Math]::Round(($PartitionDisk.Size / 1GB), 2)
    }
    
} | Format-Table -AutoSize
You can compare that to the serial numbers in your SpinRite logs (SRLOGS folder on your SpinRite boot drive).