# SATA hd: /dev/sdx or /dev/hdx

## Little Nemo

My mainboard (Asus 8KV SE deluxe) has a VIA southbridge.

There is a CDROM attached to the primary IDE controller, so I compiled the kernel with CONFIG_BLK_DEV_VIA82CXXX=y. I have a SATA harddisk attached to the VIA controller, so I selected CONFIG_SCSI_SATA_VIA=y, too.

As a result, the harddisk appears as /dev/hde (hda..hdd are reserved for the Ultra ATA interface). I suppose the disk would appear as /dev/sda if I omitted the IDE driver from the kernel -- but then the CDROM would not be recognized.

What worries me is the mixture of ATA and SATA drivers. Obviously the presence of the ATA driver somehow interferes with the device as the naming scheme is IDE, not SCSI (the SATA drivers apppear under "SCSI" in the kernel configuration, and others have reported that their SATA drives are named /dev/sdx). Does anyone know whether this is potentially dangerous?

----------

## Nate_S

I doubt that it's related to your ide drivers.  The use of scsi emulation or not on SATA conrtollers varies from driver to driver.

----------

## srs5694

What's happening is that the ATA driver is controlling your SATA disks; this isn't just a device naming issue. You can safely omit the libata drivers (under the SCSI section) and just use your system as it is.

If you really want to use the libata drivers for some reason, you can do so and keep the PATA CD-ROM drive:

Recompile the kernel with the libata driver in the kernel proper and the ATA driver as a module.

Reconfigure the system to load the ATA driver after you've booted, or upon demand when you try to access the CD-ROM drive.

You may also need to use hdparm to set access modes on the CD-ROM to improve performance; it may come up in a default low-performance mode.

----------

## Little Nemo

 *Nate_S wrote:*   

> I doubt that it's related to your ide drivers.  The use of scsi emulation or not on SATA conrtollers varies from driver to driver.

 

I don't think anything needs to be emulated here. AFAIK the SATA drivers are much closer to SCSI than they are to ATA, so if I can get rid of the ATA stuff, the disk will naturally be taken for a SCSI device.

----------

## Little Nemo

 *srs5694 wrote:*   

> What's happening is that the ATA driver is controlling your SATA disks; this isn't just a device naming issue. You can safely omit the libata drivers (under the SCSI section) and just use your system as it is.
> 
> 

 

Which is the libata driver? I cannot find that under "SCSI device support" or "SCSI low-level drivers"

----------

## srs5694

 *Little Nemo wrote:*   

> Which is the libata driver? I cannot find that under "SCSI device support" or "SCSI low-level drivers"

 

Device Drivers -> SCSI Device Support -> SCSI Low-Level Drivers -> Serial ATA (SATA) Support

Chances are these drivers aren't even loading right now, even if you've compiled them into the kernel.

----------

## scoobydu

I had the same problem with my SIL 3112 & SIL 3114 controllers.

I also have a SIL CMD 680, but that driver is together with the ATA 3112A driver!

If I install both SCSI SATA support and the CMD 0680 driver, my SATA drives appear as /dev/hde & hdg.

With just SATA support they appear as /dev/sda & sdb with better performance.

Until I find a solution I don't use the CMD 0680 and the drives attached to it!

----------

## Little Nemo

Thanks, srs5694! First of all, you were absolutely right: I recompiled the kernel without the libata driver, and it rebooted without any change. Apparently the libata code was never used. What confused me was a naming issue: The SATA driver is called libata while the PATA driver identifies as VIA8237SATA at bootup:

```
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2

ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx

VIA8237SATA: IDE controller at PCI slot 0000:00:0f.0

VIA8237SATA: chipset revision 128

VIA8237SATA: 100% native mode on irq 10

    ide2: BM-DMA at 0xd400-0xd407, BIOS settings: hde:pio, hdf:pio

    ide3: BM-DMA at 0xd408-0xd40f, BIOS settings: hdg:pio, hdh:pio

hde: Maxtor 6Y160M0, ATA DISK drive

ide2 at 0xe800-0xe807,0xe402 on irq 10

VP_IDE: IDE controller at PCI slot 0000:00:0f.1

VP_IDE: chipset revision 6

VP_IDE: not 100% native mode: will probe irqs later

VP_IDE: VIA vt8237 (rev 00) IDE UDMA133 controller on pci0000:00:0f.1

    ide0: BM-DMA at 0xfc00-0xfc07, BIOS settings: hda:DMA, hdb:pio

    ide1: BM-DMA at 0xfc08-0xfc0f, BIOS settings: hdc:pio, hdd:pio

hda: PLEXTOR DVDR PX-708A, ATAPI CD/DVD-ROM drive

ide0 at 0x1f0-0x1f7,0x3f6 on irq 14

hde: max request size: 1024KiB

hde: 320173056 sectors (163928 MB) w/7936KiB Cache, CHS=19929/255/63

 /dev/ide/host2/bus0/target0/lun0: p1 p2 p3 p4 < p5 p6 p7 >

hda: ATAPI 40X DVD-ROM DVD-R CD-R/RW CD-MRW drive, 2048kB Cache, UDMA(33)

```

Then I followed your advice to try it the other way round and recompiled the kernel with the libata drivers in the kernel and the ATA drivers as modules. I changed /etc/fstab and /boot/grub/grub.conf accordingly (/dev/sda instead of /dev/hde), and now I have the harddisk running under the libata (SATA) driver and the CD-ROM under the VIA vt8237 ATA driver:

```
libata version 1.02 loaded.

sata_via version 0.20

sata_via(0000:00:0f.0): routed to hard irq line 10

ata1: SATA max UDMA/133 cmd 0xE800 ctl 0xE402 bmdma 0xD400 irq 10

ata2: SATA max UDMA/133 cmd 0xE000 ctl 0xD802 bmdma 0xD408 irq 10

ata1: dev 0 cfg 49:2f00 82:7c69 83:7f09 84:4003 85:7c69 86:3e01 87:4003 88:407f

ata1: dev 0 ATA, max UDMA/133, 320173056 sectors (lba48)

ata1: dev 0 configured for UDMA/133

scsi0 : sata_via

ata2: no device found (phy stat 00000000)

ata2: thread exiting

scsi1 : sata_via

  Vendor: ATA       Model: Maxtor 6Y160M0    Rev: 1.02

  Type:   Direct-Access                      ANSI SCSI revision: 05

SCSI device sda: 320173056 512-byte hdwr sectors (163929 MB)

SCSI device sda: drive cache: write through

 /dev/scsi/host0/bus0/target0/lun0: p1 p2 p3 p4 < p5 p6 p7 >

Attached scsi disk sda at scsi0, channel 0, id 0, lun 0

Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0,  type 0

.

.

.

VP_IDE: IDE controller at PCI slot 0000:00:0f.1

VP_IDE: chipset revision 6

VP_IDE: not 100% native mode: will probe irqs later

VP_IDE: VIA vt8237 (rev 00) IDE UDMA133 controller on pci0000:00:0f.1

    ide0: BM-DMA at 0xfc00-0xfc07, BIOS settings: hda:DMA, hdb:pio

    ide1: BM-DMA at 0xfc08-0xfc0f, BIOS settings: hdc:pio, hdd:pio

hda: PLEXTOR DVDR PX-708A, ATAPI CD/DVD-ROM drive

ide0 at 0x1f0-0x1f7,0x3f6 on irq 14

hda: ATAPI 40X DVD-ROM DVD-R CD-R/RW CD-MRW drive, 2048kB Cache, UDMA(33)

Uniform CD-ROM driver Revision: 3.20

```

scoobydu, performance-wise there's little difference here. With the SATA driver, the disk performs minimally slower (about 1 per cent, as shown by "hdparm -t"). I guess this depends on the individual drivers.

----------

## scoobydu

 *Little Nemo wrote:*   

> scoobydu, performance-wise there's little difference here. With the SATA driver, the disk performs minimally slower (about 1 per cent, as shown by "hdparm -t"). I guess this depends on the individual drivers.

 

For me the CMD0680 driver was buggy, so its performance was poor to say the least! My SATA drive crawled until I found out what was happening  :Smile: 

----------

## piewie

Have you already tryed 

hde=noprobe

as boot option in your grub.conf?

----------

## torchZ06

ok, so is it better to use the SCSI drivers or not?

i'm having similar problems with my sk8v and sata drive.

see post:

https://forums.gentoo.org/viewtopic.php?p=1246683#1246683

----------

## srs5694

 *torchZ06 wrote:*   

> ok, so is it better to use the SCSI drivers or not?

 

My own experience (with an MSI K8T Neo-FSR) is that both the ATA and the libata (SCSI) drivers get the job done, and produce similar performance. There are some differences, though -- the ATA drivers yield a CHS geometry that doesn't match what the Windows drivers produce, at least by default; but these drivers enable the geometry to be altered by boot-time options, which don't exist for the libata drivers. The ATA drivers give more information about devices they control in the /proc filesystem. I've had a couple of mysterious system hangs when using the ATA drivers, but I'm not really positive they're the cause.

In sum, they don't seem greatly different to me (unless those system hangs were caused by the ATA driver). Of course, YMMV; it's possible that another motherboard or other SATA devices would cause significant differences.

----------

