IDE to SATA adapter

[phenest]

I have an IDE to SATA adapter bought from StarTech: IDE to SATA Adapter Converter. This gives 2 SATA 1.5Gb/s connectors. This allows the use of both SATA hard drives and optical drives, and doesn't require drivers. HDD's work fine, but it has issues if I connect a Solid State Drive. Neither StarTech nor Crucial (SSD) can offer any explanation for the issue nor see a reason for the issue in the first place. Which brings me here to see if any bright spark can offer an explanation or suggestion.

Test setup:

• Hardware
  • 1 x IDE hard drive connected via IDE
    1 x SSD connected via IDE to SATA adapter

• Software
  • Debian is installed on both drives from CD1
    IDE drive is running Stretch
    SSD drive is running Jessie
    1 x partition for / on both drives

Installing Debian to the SSD goes smoothly and boots up to Gnome with no errors. If I boot Debian from the IDE drive, it reports this:

Code: Select all

[    1.680265] ata2.00: ATAPI: PIONEER BD-RW   BDR-209D, 1.20, max UDMA/100
[    1.680422] ata2.01: ATA-9: CT120BX100SSD1, MU02, max UDMA/133
[    1.680425] ata2.01: 234441648 sectors, multi 1: LBA48 NCQ (depth 0/1)
[    1.704255] ata2.00: configured for UDMA/100
[    1.708699] ata2.01: NODEV after polling detection
[    1.708702] ata2.01: revalidation failed (errno=-2)
[    7.088251] ata2.00: configured for UDMA/100
[    7.092683] ata2.01: NODEV after polling detection
[    7.092686] ata2.01: revalidation failed (errno=-2)
[   12.464251] ata2.00: configured for UDMA/100
[   12.468679] ata2.01: NODEV after polling detection
[   12.468682] ata2.01: revalidation failed (errno=-2)
[   12.468738] ata2.01: disabled
[   12.468761] ata2.00: failed to set xfermode (err_mask=0x40)
[   17.836256] ata2.00: configured for UDMA/100

As you can see, ata2.01 (SSD) is disabled and inaccessible. There are no problems if I connect an HDD. All research suggest hardware issues. The computer is 12 years old, so there is no BIOS update. Firmware on the SSD is up to date. As stated earlier, the manufacturers of the adapter and the SSD can't understand why the SSD should cause a difference. Debian runs fine on the SSD, but Debian on the IDE drive has issues with the SSD.

[dasein]

Two random thoughts (in no particular order)...

- Make sure you are using an 80-pin cable, and not an early-IDE 40-pin

- Try swapping the two devices' position on the IDE cable.

[Segfault]

Methinks this adapter plugs into motherboard IDE port, there is no cable.

[phenest]

Yes, it plugs directly into the motherboard therefore no cables.

[dasein]

Sorry. Caffeine insufficiency got me thinking SATA-to-IDE, rather than the other way around.

Ignore me.

[Segfault]

Kernel issue. You installed Jessie and the kernel on install media recognized the SSD. Must be something with Stretch kernel.

[phenest]

Jessie gives the same results. Live CD's have the same problem too, but a Jessie installer has no problems.

[Segfault]

OK ... kernel is able to mount this drive all by itself, otherwise boot from it wouldn't be possible. However, it is not mountable when it is not the boot drive. Makes me think there is an udev issue with this piece of hardware. Have you tried creating device nodes by hand? BTW, error -2 is "no such file or directory".

[Segfault]

Just thinking. Your controller is IDE, this is major 3. The drive is SSD, was there ever an IDE SSD drive? Maybe this is why udev fails, it is impossible combination for it. When you boot into Jessie, the drive nodes are major 3 or 8?

[phenest]

Have you tried creating device nodes by hand? BTW, error -2 is "no such file or directory".

Thanks for the error code meaning. I've been looking for it myself. How would I go about creating a drive node?

When you boot into Jessie, the drive nodes are major 3 or 8?

How do I find that out?

[Segfault]

man makedev
ls -l /dev/sd*
ls -l will show major and minor numbers.

The major is the driver. 8 for SCSI and 3 for IDE.

Minor is the partition.
0 for first drive
1 for first partition on first drive.
16 for second drive
17 for first partition on second drive
...

Hope you get the picture.

Edit: I just realized nowadays IDE drives are accessed over SCSI layer, so there cannot be major 3.
Anyhow, check out the makedev man page and try creating missing nodes.

[phenest]

From Jessie:

Code: Select all

brw-rw---- 1 root disk 8, 0 Mar 12 15:50 /dev/sda

[Segfault]

Yes, this would be first drive with SCSI driver 8,0. It is not going to be the first drive from Stretch. BTW, the command to create nodes is mknod, I was mistaken when I wrote makedev. Sorry for confusion, but one does not create nodes nowadays in a routine manner, I don't remember all that stuff ...

[phenest]

BTW, error -2 is "no such file or directory".

How do I know what device node I should create? Shouldn't udev be making one?

I managed to make a node using mknod, but as the drive is disabled, I can't do anything with it. Should I make a udev rule?

[Segfault]

Look, I really do not see from here what is going on there. Yes, udev should, but it can fail, thus I recommended creating nodes manually. Maybe this is not the solution for your problem. I do not know, all I know is the bits of information provided by you.

Code: Select all

ls -l /dev/sd?

This will return existing drive nodes. Say, you have three drives abut only two show up.

Code: Select all

$ ls -l /dev/sd?
brw-rw---- 1 root disk 8,  0 Feb 28 16:39 /dev/sda
brw-rw---- 1 root disk 8, 16 Feb 28 16:39 /dev/sdb

Obviously you need to create a node for third drive.

Code: Select all

mknod /dev/sdc b 8 32

Then follow up with nodes for partition(s).

[phenest]

I can make the nodes but I still don't have access to the SSD. The drive has been disabled because of:

Code: Select all

[    1.708699] ata2.01: NODEV after polling detection
...
[   12.468738] ata2.01: disabled

I don't think this is a mounting issue. It's a detection issue from an external kernel. But the drive itself is bootable.

[Segfault]

What mounting?
After you created those nodes for SSD, did fdisk -l see the drive? You are sure you got the minor numbers right?
There is the kernel driver for controller, and controller deals with drive. When the drive is detected a node is created in /dev/. There may be a timing issue, the SSD may respond too fast for PATA driver for instance. No telling without enabling debug for PATA in kernel if this is the case.

[phenest]

The bit I don't understand is, if I create the nodes, what links the nodes to the drive? Do I need to restart udev or something?

[Segfault]

mknod is probably used by udev, certainly not the other way around.
When you create a node the major and minor number will point to that specific piece of hardware. I have two drives, when I run

Code: Select all

mknod /dev/sdc b 8 32

it wiil create the node for sdc. I could remove udev completely from my system and still, if I plug in another drive I will be able to access it as sdc using the node I created. Of course, if i have a partition on it I'd need to create a node for it.

Code: Select all

mknod /dev/sdc1 b 8 33

[phenest]

Ok, I understand that. To answer your previous questions:

After you created those nodes for SSD, did fdisk -l see the drive?

No.

You are sure you got the minor numbers right?

Yes. Owner, group and permissions too, if they're necessary.