I have a Dell Inspiron 6000d which has a SATA hard disk and PATA optical drive. The performance for the hard disk is good, but the optical drive's performance is very poor, I can't turn on DMA.
I used a kernel patch that got both drives working well, but it caused my kernel to be unstable (random lock ups). Here is a discussion of the patch: http://www.math.ucla.edu/~jimc/insp6000/p-disc.html#cd
I searched the web more and found a discussion on the kernel parameter atapi_enabled=1, but that didn't work for me either. http://comments.gmane.org/gmane.linux.kernel/351063
This is the kernel I'm using: kernel-2.6.12-1.1381_FC3
Any advice, tips or hints? Thank you.
On Friday 09 December 2005 23:41, Christopher J. Bottaro wrote:
I have a Dell Inspiron 6000d which has a SATA hard disk and PATA optical drive. The performance for the hard disk is good, but the optical drive's performance is very poor, I can't turn on DMA.
I used a kernel patch that got both drives working well, but it caused my kernel to be unstable (random lock ups). Here is a discussion of the patch: http://www.math.ucla.edu/~jimc/insp6000/p-disc.html#cd
I searched the web more and found a discussion on the kernel parameter atapi_enabled=1, but that didn't work for me either. http://comments.gmane.org/gmane.linux.kernel/351063
This is the kernel I'm using: kernel-2.6.12-1.1381_FC3
Any advice, tips or hints? Thank you.
Yeah, use a newer kernel. I've got the same setup in my laptop (ICH6M SATA controller) and I've got my optical drive recognized as a SCSI device, with full performance. I use 2.6.14.3-vanilla w/a couple of patches applied. Here's the patch I use to enable ATAPI in the libata-driver:
diff -uNr linux-2.6.14-rc5/drivers/scsi/libata-core.c linux-2.6.14-rc5.libata_pata/drivers/scsi/libata-core.c --- linux-2.6.14-rc5/drivers/scsi/libata-core.c 2005-10-20 14:39:45.000000000 +0200 +++ linux-2.6.14-rc5.libata_pata/drivers/scsi/libata-core.c 2005-10-20 14:41:52.000000000 +0200 @@ -75,7 +75,7 @@ static unsigned int ata_unique_id = 1; static struct workqueue_struct *ata_wq;
-int atapi_enabled = 0; +int atapi_enabled = 1; module_param(atapi_enabled, int, 0444); MODULE_PARM_DESC(atapi_enabled, "Enable discovery of ATAPI devices (0=off, 1=on)");
diff -uNr linux-2.6.14-rc5/include/linux/libata.h linux-2.6.14-rc5.libata_pata/include/linux/libata.h --- linux-2.6.14-rc5/include/linux/libata.h 2005-10-20 14:39:49.000000000 +0200 +++ linux-2.6.14-rc5.libata_pata/include/linux/libata.h 2005-10-20 14:41:38.000000000 +0200 @@ -40,7 +40,7 @@ #undef ATA_VERBOSE_DEBUG /* yet more debugging output */ #undef ATA_IRQ_TRAP /* define to ack screaming irqs */ #undef ATA_NDEBUG /* define to disable quick runtime checks */ -#undef ATA_ENABLE_PATA /* define to enable PATA support in some +#define ATA_ENABLE_PATA /* define to enable PATA support in some * low-level drivers */ #undef ATAPI_ENABLE_DMADIR /* enables ATAPI DMADIR bridge support */
It applies nicely to 2.6.14.3. I've _never_ had any lock ups with this, but, of course, I cannot guarantee any thing. I'd backup my data before playing with these things.
Øyvind
Øyvind Stegard wrote:
On Friday 09 December 2005 23:41, Christopher J. Bottaro wrote:
I have a Dell Inspiron 6000d which has a SATA hard disk and PATA optical drive. The performance for the hard disk is good, but the optical drive's performance is very poor, I can't turn on DMA.
I used a kernel patch that got both drives working well, but it caused my kernel to be unstable (random lock ups). Here is a discussion of the patch: http://www.math.ucla.edu/~jimc/insp6000/p-disc.html#cd
I searched the web more and found a discussion on the kernel parameter atapi_enabled=1, but that didn't work for me either. http://comments.gmane.org/gmane.linux.kernel/351063
This is the kernel I'm using: kernel-2.6.12-1.1381_FC3
Any advice, tips or hints? Thank you.
Yeah, use a newer kernel. I've got the same setup in my laptop (ICH6M SATA controller) and I've got my optical drive recognized as a SCSI device, with full performance. I use 2.6.14.3-vanilla w/a couple of patches applied. Here's the patch I use to enable ATAPI in the libata-driver:
diff -uNr linux-2.6.14-rc5/drivers/scsi/libata-core.c linux-2.6.14-rc5.libata_pata/drivers/scsi/libata-core.c --- linux-2.6.14-rc5/drivers/scsi/libata-core.c 2005-10-20 14:39:45.000000000 +0200 +++ linux-2.6.14-rc5.libata_pata/drivers/scsi/libata-core.c 2005-10-20 14:41:52.000000000 +0200 @@ -75,7 +75,7 @@ static unsigned int ata_unique_id = 1; static struct workqueue_struct *ata_wq;
-int atapi_enabled = 0; +int atapi_enabled = 1; module_param(atapi_enabled, int, 0444); MODULE_PARM_DESC(atapi_enabled, "Enable discovery of ATAPI devices (0=off, 1=on)");
diff -uNr linux-2.6.14-rc5/include/linux/libata.h linux-2.6.14-rc5.libata_pata/include/linux/libata.h --- linux-2.6.14-rc5/include/linux/libata.h 2005-10-20 14:39:49.000000000 +0200 +++ linux-2.6.14-rc5.libata_pata/include/linux/libata.h 2005-10-20 14:41:38.000000000 +0200 @@ -40,7 +40,7 @@ #undef ATA_VERBOSE_DEBUG /* yet more debugging output */ #undef ATA_IRQ_TRAP /* define to ack screaming irqs */ #undef ATA_NDEBUG /* define to disable quick runtime checks */ -#undef ATA_ENABLE_PATA /* define to enable PATA support in some +#define ATA_ENABLE_PATA /* define to enable PATA support in some
- low-level drivers */
#undef ATAPI_ENABLE_DMADIR /* enables ATAPI DMADIR bridge support */
It applies nicely to 2.6.14.3. I've _never_ had any lock ups with this, but, of course, I cannot guarantee any thing. I'd backup my data before playing with these things.
I've read on the web that you can enable atapi (for 2.6.14) without patching the source by using the kernel param atapi_enabled=1 or libata.atapi_enabled=1. The former works for some people and the latter works for others...still neither work for some people: http://kerneltrap.org/node/5836
Those people in that thread are simply using the kernel param without having to recompile the kernel with this part of your patch: -#undef ATA_ENABLE_PATA +#define ATA_ENABLE_PATA
Maybe that's why it doesn't work for some people...?
One last thing, I've had bad luck compiling vanilla kernels from kernel.org in the past. They compiled and booted fine, but my system was extremely sluggish while running them. Since then, I've only been compiling what Redhat makes available to in via the kernel-{version}.src.rpm packages...and a 2.6.14 kernel src rpm package isn't available for FC3 yet. Any tips on getting a vanilla kernel running up to speed?
Øyvind
Thanks for the reply and help, -- Christopher
P.S. My machine is a Dell Inspiron 6000d laptop if it matters.
On Saturday 10 December 2005 01:48, Christopher J. Bottaro wrote:
One last thing, I've had bad luck compiling vanilla kernels from kernel.org in the past. They compiled and booted fine, but my system was extremely sluggish while running them. Since then, I've only been compiling what Redhat makes available to in via the kernel-{version}.src.rpm packages...and a 2.6.14 kernel src rpm package isn't available for FC3 yet.
I must say I've had the complete opposite experience on my laptop. It's brand new, Intel 915GM Centrino based, and I've never successfully booted any of the newer FC4 kernels on it. I guess I could make them work by fiddling with kernel params, but I _do_not_ want to disable ACPI, and other newer features. I don't have to with vanilla. I had a h**l of a time bootstrapping/installing Fedora on it, the first time, with the kernel that comes with the FC4 install CD.
Any tips on getting a vanilla kernel running up to speed?
You could base the 2.6.14.3 config on the config of the newest FC4 kernel, using make oldconfig .. I'd go through manually, though, and sanity check the everything afterwords. And if you're going to roll your own kernel, I would remove all the cruft, while I was at it. There's a lot. I usually go through the entire kernel configuration manually, and set things the way I like it.
Remember to create an initrd when you install new vanilla kernels, and make sure it's used in grub.conf. It's required for udev to create some basic devices nodes, if I remember correctly. The details should be available here: http://fedora.redhat.com/docs/udev/
Øyvind
Øyvind Stegard wrote:
Any tips on getting a vanilla kernel running up to speed?
You could base the 2.6.14.3 config on the config of the newest FC4 kernel, using make oldconfig .. I'd go through manually, though, and sanity check the everything afterwords. And if you're going to roll your own kernel, I would remove all the cruft, while I was at it. There's a lot. I usually go through the entire kernel configuration manually, and set things the way I like it.
That worked nicely, thanks for the tip. My cd burner is seen as a scsi device and I get full performance. Now it's time to play the waiting game (to see if I get any lock ups).
Øyvind
-- Christopher
Christopher J. Bottaro wrote:
Øyvind Stegard wrote:
I've read on the web that you can enable atapi (for 2.6.14) without patching the source by using the kernel param atapi_enabled=1 or libata.atapi_enabled=1. The former works for some people and the latter works for others...still neither work for some people: http://kerneltrap.org/node/5836
Those people in that thread are simply using the kernel param without having to recompile the kernel with this part of your patch: -#undef ATA_ENABLE_PATA +#define ATA_ENABLE_PATA
Maybe that's why it doesn't work for some people...?
One last thing, I've had bad luck compiling vanilla kernels from kernel.org in the past. They compiled and booted fine, but my system was extremely sluggish while running them. Since then, I've only been compiling what Redhat makes available to in via the kernel-{version}.src.rpm packages...and a 2.6.14 kernel src rpm package isn't available for FC3 yet. Any tips on getting a vanilla kernel running up to speed?
Øyvind
Thanks for the reply and help, -- Christopher
P.S. My machine is a Dell Inspiron 6000d laptop if it matters.
For what it is worth on this matter. I have a Toshiba laptop with the same chipset and had the same issues. With the latest kernel and libata.atapi_enabled=1 in the modprobe.conf file, my laptop works as expected. Can watch DVD's on the drive with no issues and is recognized as /dev/sdc. Good work developers.
I didn't do anything else. The day I sat down to work on it over the Xmas break, I found that all was well. My wife is a very happy person which makes me happy.
-
Christopher J. Bottaro -
Robin Laing -
Øyvind Stegard