Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[howto] sata, pata, libata and a dvd burner
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Documentation, Tips & Tricks
View previous topic :: View next topic  
Author Message
psy_ill
Tux's lil' helper
Tux's lil' helper


Joined: 06 Jul 2003
Posts: 106

PostPosted: Thu Mar 01, 2007 12:46 pm    Post subject: [howto] sata, pata, libata and a dvd burner Reply with quote

My DVD reader broke the other day. I wouldn't say it had served me well, it had done its duty in a rather noisy way (by the way, it was a LG product). Because of a terrible accident previous year, I was forced to buy a new CPU and a shiny new (almost modern) motherboard. A motherboard with both SATA-150 and PATA connectors... I have already put a hdd to work at one of the two SATA slots and it works beautifully. If I would have to replace the DVD unit, I might as well get me a sexy toy while I'm at it. A DVD burner with SATA interface would be something, wouldn't it? It would let me throw out my old CD burner too.
Ok, the SATA-150 is no faster than the PATA, but next time I buy a motherboard I'm not sure it will have PATA at all. A SATA unit would be a trusty investment.
Off I went, down to my sexy-toy-dealer, and came back with a SATA burner.

Time for some specifications:

  • Motherboard: ASRock K8Upgrade-NF3
  • BIOS version: 1.60
  • Chipset: nVidia nForce3-250
  • SATA DVD burner: Samsung SH-S183

Well, guess what: the nForce3-250 did not like my optical SATA unit. Past the memory check at boot, my mean machine rebooted when it tried to detect the drives. I pulled out the SATA hdd, switched SATA slot for the burner, checked my BIOS settings (no RAID). The chipset was not in the mood, thus, I had to pull out the burner. I checked ASRock's site for BIOS upgrades and there was actually a newer version, 2.20. But none of the versions succeeding mine bore any notice of changed SATA routines. With a ten year old, yet horrifying memory of the consequences of unnecessary BIOS updates in mind, I chose not to try the upgrade.

Back at the store, I switched the SATA unit for a PATA dito. (No quarrel concerning that the SATA unit now was used - I even got the price difference back. Great service, thanks GHData!)

  • New equipment: Samsung SH-S182D

The PATA unit was of course no problem, it went in, the system booted. To enable all features of the unit (though I'm not sure I will ever use them), I took a peek at gentoo-sources-2.6.20, especially the option for packet writing (CONFIG_CDROM_PKTCDVD). While I was looking around, it struck me that I was running ATA systems in parallel - using the traditional system (CONFIG_IDE) for PATA units and the libata system (CONFIG_ATA) for SATA units. How annoying! Of course, I ditched the old system. To make optical units and DVD burners work, I had to tamper a bit with the SCSI drivers too.

Important kernel options:
Code:

(only necessary if you are going to use packet writing)
CONFIG_CDROM_PKTCDVD=m

(the old system, must be disabled for the libata PATA to work)
# CONFIG_IDE is not set

CONFIG_SCSI=y
(SCSI disk support)
CONFIG_BLK_DEV_SD=y
(SCSI optical devices support)
CONFIG_BLK_DEV_SR=y
(SCSI general devices support, needed for burning)
CONFIG_CHR_DEV_SG=y

(the new libata system)
CONFIG_ATA=y
(these are specific for my chipset)
CONFIG_SATA_NV=y
CONFIG_PATA_AMD=y

Now I got to a tricky part: after compiling and installing the kernel, I had to change my GRUB settings and /etc/fstab to point at the new locations of my devices. The root partition previously was /dev/hda3, I had a SATA hdd at /dev/sda and my old CD burner had been at /dev/cdrw. I hate to admit it, but the right way is of course to change the udev rules so that no matter what devices I'm using, I still get the same symlinks. I stood to my lazyness and changed the /etc/fstab as well.

Libata recognizes the SATA unit first it seems (at least in my case) and then moves on to the PATA units. My SATA hdd remained at /dev/sda, my PATA hdd moved from /dev/hda to /dev/sdb, the DVD burner showed up as /dev/sr0 and /dev/sg2 and udev was kind enough to make symlinks to /dev/sr0 called /dev/cdrom, /dev/cdrw, /dev/dvd and /dev/dvdrw. I guessed all that, except the udev symlinks, before I rebooted, thus, I changed a line in my GRUB configuration file:
Code:

title=Gentoo Linux
root (hd0,0)
kernel (hd0,0)/boot/vmlinuz root=/dev/hda3

became
Code:

title=Gentoo Linux
root (hd0,0)
kernel (hd0,0)/boot/vmlinuz root=/dev/sdb3

Yes, as you probably saw, I did not add "libata.atapi_enabled=1" to the kernel parameters. That was previously the proper way to switch on ATAPI support for libata, but with recent kernel releases, ATAPI is switched on by default. (ATAPI is needed for most CD/DVD units.)

I rebooted my system, and I now have a working DVD burner (yes, I tested it) and every drive managed by libata.

There is one part missing from this story though: we (I) need to check whether we have DMA support. Previously, you could use hdparm to find out whether optical units had DMA enabled. Now you have to use sdparm to get any information from these units (hdparm still works on regular disks), but I can't seem to find any information about DMA. Has anyone some information?


Last edited by psy_ill on Mon Mar 19, 2007 1:10 pm; edited 1 time in total
Back to top
View user's profile Send private message
affinity
n00b
n00b


Joined: 01 Jul 2004
Posts: 66

PostPosted: Thu Mar 01, 2007 9:16 pm    Post subject: Reply with quote

It seems like libata.atapi_enabled=1 is not necessary on >=2.6.17 kernels as ATAPI is enabled by default, here's the relevant commit from the 2.6.17 changelog.
Code:
commit 418dc1f5a805822fcf1118804ddc689a4156db4a
Author: Jeff Garzik <jeff@garzik.org>
Date:   Sat Mar 11 20:50:08 2006 -0500

    libata: turn on ATAPI by default


Also to check if DMA is enabled (it's enabled automatically) you can grep kernel log/dmesg for "ata[0-9]" or "DMA".

(at least these work for me on 2.6.20 using ahci with samsung sh-s183a) ;-)
Back to top
View user's profile Send private message
yoyo
Bodhisattva
Bodhisattva


Joined: 04 Mar 2003
Posts: 4273
Location: Lyon - France

PostPosted: Fri Mar 02, 2007 6:56 am    Post subject: Reply with quote

affinity wrote:
It seems like libata.atapi_enabled=1 is not necessary on >=2.6.17 kernels as ATAPI is enabled by default, here's the relevant commit from the 2.6.17 changelog.
Well I saw that but one question comes into my mind. If I compiled both libata and idedev (can't remember the exact name for it but I'm sure you'll understand) in kernel can I switch between them with the "libata.atapi_enabled" boot argument ??
I mean, if I put "libata.atapi_enabled=0" on my grub config file, did the kernel load the "old" ata device support ?

Another thing is to use the LABEL in fstab in place of changing device name (or writing udev rules). Not all fs give this opportunity but he! you can check yours. :wink:

Enjoy !
_________________
La connaissance s'accroît quand on la partage.
JCB
Back to top
View user's profile Send private message
affinity
n00b
n00b


Joined: 01 Jul 2004
Posts: 66

PostPosted: Fri Mar 02, 2007 10:34 am    Post subject: Reply with quote

yoyo wrote:
Well I saw that but one question comes into my mind. If I compiled both libata and idedev (can't remember the exact name for it but I'm sure you'll understand) in kernel can I switch between them with the "libata.atapi_enabled" boot argument ??
I mean, if I put "libata.atapi_enabled=0" on my grub config file, did the kernel load the "old" ata device support ?

I don't think so, since it should just enable/disable discovery of ATAPI devices in libata, you probably just have to load the old driver before libata (somehow).
Back to top
View user's profile Send private message
psy_ill
Tux's lil' helper
Tux's lil' helper


Joined: 06 Jul 2003
Posts: 106

PostPosted: Mon Mar 19, 2007 1:08 pm    Post subject: Reply with quote

Thanks for pointing out that "libata.atapi_enabled=1" is unnecessary, I will change it immediately.
And thanks for the tip on checking the DMA status (I feel a bit silly not thinking of that myself), I will do a little sourcediving into the kernel source to check what these rows
Code:

ata1: SATA max UDMA/133 cmd 0xF80 ctl 0xF02 bmdma 0xD800 irq 10
ata2: SATA max UDMA/133 cmd 0xE80 ctl 0xE02 bmdma 0xD808 irq 10
ata3: PATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xFFA0 irq 14
ata4: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xFFA8 irq 15

mean exactly, down to each digit. :)
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Documentation, Tips & Tricks All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum