Thanks, I had the latest SW already.
I can indeed do that test for you. Watch this space!

Thanks

I've had a couple of SSDs fail, but none of them died because of a lack of trim.

Thanks @Sleaka_J - I've decided to go with an old fashioned (brand new) mechanical drive, just to rule out any possible issues. For my personal use, I'd go with an SSD for sure 🙂

@Nehalem501

Here it is: https://1drv.ms/u/c/0f215fbb023f1ee9/EXvBFyUI … Y-R6Sw?e=HgVhMf

I was looking at the logs while copying (on a monitor), I see the XD10 copies everything in a temp folder and then renames everything. If those logs could be useful, I can try and fish them from the drive.
I've also included the RWM folder in case you needed it.

Let me know if you can see the files.
Thanks!

Thanks for the file. It seems like everything I need is there.
I will keep you posted with my progress.

I’ve managed to have my program recreate the original file from the XD10 files. The file is completely identical to the original one so it’s progressing smoothly.

There are still a few things I need to finish (there are a few shortcuts I took that I need to reimplement cleanly). I need to find a bit more free time to finish it. It should be good in a week or two.

Thanks for the update! If you need any more tests from an actual XD10, please do let me know!

for others running into this problem a live linux cd has been suggested, but a non-destructive frugal install of some small linux distro like slitaz (if the kernel is new enough for trim) to an existing fat partition might fit the bill as well. you can boot it from dos using loadlin, linld or tazboot. i even got rid of grub and use this method to boot q4os (debian bookworm) from dos, albeit from a ext4 partition.

Bringing back the same subject - and going slightly OT.

I went for a spinning SATA HDD of 1TB, the smallest I can get today. I bought some Startech SATA to PATA adaptors with a Marvel chip.

Everything works. BUT. The machine kind of misbehaves. It tends to have trouble booting, it fails to start X Window (for subtitles!), then detects an MD5 error with its own software which it proceeds to repair. This happens once every 20 boots, it's impossible to diagnose. Again at boot, I sometimes see an error on the display - which is just a watchdog, a timer: if the software is not resetting the timer all the time, an error is displayed.

I am almost confident that "working" machines don't do that. I have re-capped the MB, new PSU, new battery, everything is nice and clean. I could install Windows XP on this machine and it was fine.

Could it be that either the motherboard (Aopen MX3S-T or Asus P5P800-VM) *OR* the Linux kernel (Linux version 2.6.15-1) don't like either the very large HDD or the adaptor?

Or maybe the software was never designed to have to deal with a 1TB partition and maybe some file operations which would take 1 second on a 160GB HDD (as default) now take 10 seconds with a 1TB HDD and that upsets the timers?

I'm testing an old 200GB SATA drive to rule out the adaptor. I was wondering if anybody had any inputs on this subject?

What HDD model? Manufacturer? Is it SMR by any chance? Because device-managed SMR basically is a combination of all the downsides SSDs (complexity, slow erase in large blocks, extra translation layer, TRIM requirement, etc) and HDDs (performance/seek times) have. Might be causing issues, mainly by replying very slowly from time to time which may make the OS timeout and assume read error...

Thanks Archer57

It's a WD 1TB WD10EZEX - CMR. I did buy some SMR without realising and I returned them.

Datasheet: https://documents.westerndigital.com/content/ … blue-pc-hdd.pdf

The software is - IMHO - pretty bad and badly put together. I wouldn't be surprised if those timers all assumed a smaller disk. Maybe there is some HDD process happening in the background which is simply taking 10x the time. After all those machines were all sold with 120/160GB HDDs, the developers didn't have to assume anything different. If larger HDDs were sold, they would have probably issued a software update.

Apart from size modern HDDs may also do something weird which older ones did not do.

Like may be it is somehow power saving related? Modern drives may have a few things they do without any command from host, like parking heads, reducing RPM and some may even spin down completely.

May end up being easier to use SSD after all...

Also, did you go through kernel log to see if there is anything out of the ordinary? I've seen ide-sata adapters detected as using 40 pin cables and forced to use UDMA33. Linux sometimes does it even when actual 80pin cable is used and BIOS detects it correctly. There are kernel parameters to override this.

I actually was fooled by this - i have an XP machine which uses SSD and ide-sata adapter, XP works great reporting UDMA6, however i used clonezilla to backup/restore the OS and it was super slow. I assumed it was caused by old CPU and simply waited, but at some point i got bored, decided to read dmesg output and noticed it was using UDMA33...

Oh, I've been digging into the logs for days from multiple units. I have found what is not normal but not what is causing it.

Uhm... UDMA33? OMG you're right! The 1TB is seen as UDMA33, the original HDD is seen as UDMA100!

Oh no! That is it?

Even the 200GB HDD is shown as UDMA33. Old logs from "working" machines all show UDMA100. I did glimpse at the UDMA33 but I didn't think too much about that.

You're a star, I'd imagine that is my problem. Now, how do I solve it... I'll have to look into the BIOS but I somehow doubt I'll find the answer there and updating the BIOS is not an option. Sigh!

This is the adaptor I purchased. Funny it says it supports ATA133 but the manual asks to use a 40pin cable.
https://www.startech.com/en-gb/hdd/ide2sat2

Thanks a lot Archer, you are a star.

tony359 wrote on 2025-08-07, 11:23:

Now, how do I solve it... I'll have to look into the BIOS but I somehow doubt I'll find the answer there and updating the BIOS is not an option. Sigh!

This is the adaptor I purchased. Funny it says it supports ATA133 but the manual asks to use a 40pin cable.
https://www.startech.com/en-gb/hdd/ide2sat2

It is curious they ask for 40pin cable, this must be a mistake...

As for how to solve - add "libata.force=80c" kernel parameter into grub config, or whatever other boot manager is used.

BIOS... well, in my case it detects everything correctly. And so does windows. It is simply linux being weird, so not sure messing with BIOS is useful at all.

Archer57 wrote on 2025-08-07, 11:53:

It is curious they ask for 40pin cable, this must be a mistake... […]
Show full quote

tony359 wrote on 2025-08-07, 11:23:

Now, how do I solve it... I'll have to look into the BIOS but I somehow doubt I'll find the answer there and updating the BIOS is not an option. Sigh!

This is the adaptor I purchased. Funny it says it supports ATA133 but the manual asks to use a 40pin cable.
https://www.startech.com/en-gb/hdd/ide2sat2

It is curious they ask for 40pin cable, this must be a mistake...

As for how to solve - add "libata.force=80c" kernel parameter into grub config, or whatever other boot manager is used.

BIOS... well, in my case it detects everything correctly. And so does windows. It is simply linux being weird, so not sure messing with BIOS is useful at all.

An 80-conductor cable still has 40 pins on each connector , so it is more likely a lack of precision in the specs than anything else, I would guess.

I would have concerns about using "libata.force=80c" or other methods to force higher data transfer rates on a 40-conductor cable. There is a potential for data corruption.

That is the issue, I think the BIOS sees it as UDMA/33, I need to check.

I don't have easy access to that Linux partition without taking out the HDD and mount it somewhere else. That would also cause issues if someone was to reinstall the box - there is an automatic DVD from the manufacturer. BUT, that is definitely something I'll keep in mind.

I'd imagine that if the BIOS sees it as UDMA/33 then I need to find another adaptor. I understand Jmicron are also available. Startech has a bi-directional one with what sounds like a dodgy chipset: Sunplus SPIF223A

https://sgcdn.startech.com/005329/media/sets/ … /PATA2SATA3.pdf

I'm trying to avoid Aliexpress as I'd like to avoid surprises.

I'll play with the BIOS later, for now, thanks a millions!

Darry,

Fair enough, the 80 CONDUCTORS cable still has 40 PINS.

darry wrote on 2025-08-07, 12:24:

An 80-conductor cable still has 40 pins on each connector , so it is more likely a lack of precision in the specs than anything else, I would guess.

I would have concerns about using "libata.force=80c" or other methods to force higher data transfer rates on a 40-conductor cable. There is a potential for data corruption.

Yeah, you are right, i misworded that. But yeah, may be something is lost in translation or something.

And yeah, there is a potential for data corruption if stuff does not work. But also in my case it was obviously false detection since BIOS was detecting it as UDMA133 and so did windows. And it worked in windows just fine.

If you google this issue this seem to be quite common, even with actual IDE HDDs and proper cables. Though care should still be taken obviously.

tony359 wrote on 2025-08-07, 12:26:

That is the issue, I think the BIOS sees it as UDMA/33, I need to check. […]
Show full quote

That is the issue, I think the BIOS sees it as UDMA/33, I need to check.

I don't have easy access to that Linux partition without taking out the HDD and mount it somewhere else. That would also cause issues if someone was to reinstall the box - there is an automatic DVD from the manufacturer. BUT, that is definitely something I'll keep in mind.

I'd imagine that if the BIOS sees it as UDMA/33 then I need to find another adaptor. I understand Jmicron are also available. Startech has a bi-directional one with what sounds like a dodgy chipset: Sunplus SPIF223A

https://sgcdn.startech.com/005329/media/sets/ … /PATA2SATA3.pdf

I'm trying to avoid Aliexpress as I'd like to avoid surprises.

I'll play with the BIOS later, for now, thanks a millions!

Darry,

Fair enough, the 80 CONDUCTORS cable still has 40 PINS.

The way it is detected - certain pin should be grounded (i do not remember the pin exactly, but easy enough to google), which should happen with actual 8О conductor cable and make BIOS detect it correctly. Which works in my case. Should probably be working in your case too, because it worked before with actual HDD.

If that's the case and linux itself is being stubborn, like it is in my case, there is basically no other way but to add that parameter.

Different adapter may change something, but it is not very likely IMO. AFAIK people had this issues even with real IDE HDDs.

The joy of working on a 2005 computer. Nothing is as you'd expect!

I've ordered one of those Startech ones.

Startech used to have a JMicron adaptor which is now discontinued. What I like about the one I purchased and the previous version (https://www.startech.com/en-gb/hdd/ide2sat25) is that they PLUG into the motherboard eliminating those hideous flat cables, 40, 80, 800 conductors.

Fingers crossed - I'm trying to come up with something that "just works" as the original.

I'll keep you posted on what I find.

Archer57 wrote on 2025-08-07, 12:38:

Yeah, you are right, i misworded that. But yeah, may be something is lost in translation or something. […]
Show full quote

darry wrote on 2025-08-07, 12:24:

An 80-conductor cable still has 40 pins on each connector , so it is more likely a lack of precision in the specs than anything else, I would guess.

I would have concerns about using "libata.force=80c" or other methods to force higher data transfer rates on a 40-conductor cable. There is a potential for data corruption.

Yeah, you are right, i misworded that. But yeah, may be something is lost in translation or something.

And yeah, there is a potential for data corruption if stuff does not work. But also in my case it was obviously false detection since BIOS was detecting it as UDMA133 and so did windows. And it worked in windows just fine.

If you google this issue this seem to be quite common, even with actual IDE HDDs and proper cables. Though care should still be taken obviously.

tony359 wrote on 2025-08-07, 12:26:

That is the issue, I think the BIOS sees it as UDMA/33, I need to check. […]
Show full quote

That is the issue, I think the BIOS sees it as UDMA/33, I need to check.

I don't have easy access to that Linux partition without taking out the HDD and mount it somewhere else. That would also cause issues if someone was to reinstall the box - there is an automatic DVD from the manufacturer. BUT, that is definitely something I'll keep in mind.

I'd imagine that if the BIOS sees it as UDMA/33 then I need to find another adaptor. I understand Jmicron are also available. Startech has a bi-directional one with what sounds like a dodgy chipset: Sunplus SPIF223A

https://sgcdn.startech.com/005329/media/sets/ … /PATA2SATA3.pdf

I'm trying to avoid Aliexpress as I'd like to avoid surprises.

I'll play with the BIOS later, for now, thanks a millions!

Darry,

Fair enough, the 80 CONDUCTORS cable still has 40 PINS.

The way it is detected - certain pin should be grounded (i do not remember the pin exactly, but easy enough to google), which should happen with actual 8О conductor cable and make BIOS detect it correctly. Which works in my case. Should probably be working in your case too, because it worked before with actual HDD.

If that's the case and linux itself is being stubborn, like it is in my case, there is basically no other way but to add that parameter.

Different adapter may change something, but it is not very likely IMO. AFAIK people had this issues even with real IDE HDDs.

Agreed.

I do not recall ever hitting that issue personally or maybe I did in temporary connection scenarios where I did not really care. The current Marvell based adapter I use works fine at higher UDMA speeds (a Startech model that afixes directly to the drive ) on an ICH2. TRIM also works (under DOS, with RLOEW's utility).

@darry

Startech made two, the current model has a Marvell chip which is the one I am using.

The MB is indeed detecting the HDD as UDMA mode 5 which is UDMA/100. So somehow Linux is probably probing the drive and decides it's a UDMA/33 one.

So tweaking Linux is my only option?

Where do I find that file, @Archer57 ?

Adapters i am using are cheap ones from aliexpress as it always felt like startech stuff is.... overpriced. Not much to this adapter, just a chip + probably reference design board...

I've checked and specific one has JM20330 chip. And i am using it on nforce2 board in this case.

Really feels like software issue more than anything though - if i use actual 40 conductor cable both windows and bios correctly detect it and limit speed, in linux detection basically does not work - it always assumes 40 conductor cable.

As to how the edit bootloader configuration - that is somewhat distribution dependant, but if you are just editing files anyway - look for configuration files in /boot, you should be able to find something there.