I've got a brand new .5U P4 system running several (I think) Seagate 80gig SATA drives. I tried to copy data from the first drive (sda) to the second drive (sdc) and was only getting about 1.7megs/sec. So I figured DMA was off. And this is what happened when I typed "hdparm -d1 /dev/hdc":
/dev/hdc: setting using_dma to 1 (on) HDIO_SET_DMA failed: Operation not permitted using_dma = 0 (off)
Any suggestions? I've never had this type of problem before.
Thanks,
On 11/03/06, Chris Mauritz chrism@imntv.com wrote:
I've got a brand new .5U P4 system running several (I think) Seagate 80gig SATA drives. I tried to copy data from the first drive (sda) to the second drive (sdc) and was only getting about 1.7megs/sec. So I
The only time I saw similar issue was on a MoBo with SiL sata controller chip. It was overcome by plugging in a SATA pci card :-)
-- Sudev Barar Learning Linux
Sudev Barar wrote:
On 11/03/06, Chris Mauritz chrism@imntv.com wrote:
I've got a brand new .5U P4 system running several (I think) Seagate 80gig SATA drives. I tried to copy data from the first drive (sda) to the second drive (sdc) and was only getting about 1.7megs/sec. So I
The only time I saw similar issue was on a MoBo with SiL sata controller chip. It was overcome by plugging in a SATA pci card :-)
I'm reasonably sure it's a garden variety intel ICHX chipset on an Intel motherboard. Dmesg doesn't really offer any clues (at least none that I'm able to decipher).
Cheers,
On Fri, 2006-03-10 at 19:39 -0500, Chris Mauritz wrote:
Sudev Barar wrote:
On 11/03/06, Chris Mauritz chrism@imntv.com wrote:
I've got a brand new .5U P4 system running several (I think) Seagate 80gig SATA drives. I tried to copy data from the first drive (sda) to the second drive (sdc) and was only getting about 1.7megs/sec. So I
The only time I saw similar issue was on a MoBo with SiL sata controller chip. It was overcome by plugging in a SATA pci card :-)
I'm reasonably sure it's a garden variety intel ICHX chipset on an Intel motherboard. Dmesg doesn't really offer any clues (at least none that I'm able to decipher).
Cheers,
Chris,
Use the command:
dmidecode
This will tell you everything you might want to know about your machine ...
I do this on all my machines in the /root directory:
dmidecode > dmidecode.out
Then I can review that text file whenever I want.
Johnny Hughes wrote:
On Fri, 2006-03-10 at 19:39 -0500, Chris Mauritz wrote:
Sudev Barar wrote:
On 11/03/06, Chris Mauritz chrism@imntv.com wrote:
I've got a brand new .5U P4 system running several (I think) Seagate 80gig SATA drives. I tried to copy data from the first drive (sda) to the second drive (sdc) and was only getting about 1.7megs/sec. So I
The only time I saw similar issue was on a MoBo with SiL sata controller chip. It was overcome by plugging in a SATA pci card :-)
I'm reasonably sure it's a garden variety intel ICHX chipset on an Intel motherboard. Dmesg doesn't really offer any clues (at least none that I'm able to decipher).
Cheers,
Chris,
Use the command:
dmidecode
This will tell you everything you might want to know about your machine ...
I do this on all my machines in the /root directory:
dmidecode > dmidecode.out
Then I can review that text file whenever I want.
That was a great suggestion, and very informative (since the box is phsically about 100 miles away and I wasn't the one who ordered or installed it "way back when"). The only mention of the IDE ports/controller is this:
Handle 0x000C DMI type 8, 9 bytes. Port Connector Information Internal Reference Designator: PRIMARY IDE Internal Connector Type: On Board IDE External Reference Designator: Not Specified External Connector Type: None Port Type: Other Handle 0x000D DMI type 8, 9 bytes. Port Connector Information Internal Reference Designator: SECONDARY IDE Internal Connector Type: On Board IDE External Reference Designator: Not Specified External Connector Type: None Port Type: Other
dmesg yields:
PCI: Probing PCI hardware PCI: Ignoring BAR0-3 of IDE controller 00:1f.2 Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx hda: HDS722512VLSA80, ATA DISK drive hdc: HDS722512VLSA80, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: attached ide-disk driver. hda: host protected area => 1 hda: 241254720 sectors (123522 MB) w/7938KiB Cache, CHS=15017/255/63 hdc: attached ide-disk driver. hdc: host protected area => 1 hdc: 241254720 sectors (123522 MB) w/7938KiB Cache, CHS=15017/255/63 libata version 1.11 loaded. ata_piix version 1.03 ata: 0x1f0 IDE port busy ata: 0x170 IDE port busy Journalled Block Device driver loaded kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,3), internal journal Adding Swap: 1052216k swap-space (priority -1) Adding Swap: 1052248k swap-space (priority -2) kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on ide1(22,2), internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,1), internal journal EXT3-fs: mounted filesystem with ordered data mode.
Any suggestions would be greatly appreciated.
Best regards,
Following-up my own post.....
I've also been able to determine that the affected system is using a Supermicro motherboard with an Intel 845GE chipset.
Cheers,
On 11/03/06, Chris Mauritz chrism@imntv.com wrote:
Following-up my own post.....
I've also been able to determine that the affected system is using a Supermicro motherboard with an Intel 845GE chipset.
SO not Intel MoBo. IAC you details did not yield much to me. One more hack suggestion since yoou mention it is an old box. Check or replace HDD cables. I have seen impact of transfer speed by changing cables climb up from ~15 to ~40 on IDE PATA drives.
-- Sudev Barar Learning Linux
Sudev Barar wrote:
On 11/03/06, Chris Mauritz chrism@imntv.com wrote:
Following-up my own post.....
I've also been able to determine that the affected system is using a Supermicro motherboard with an Intel 845GE chipset.
SO not Intel MoBo. IAC you details did not yield much to me. One more hack suggestion since yoou mention it is an old box. Check or replace HDD cables. I have seen impact of transfer speed by changing cables climb up from ~15 to ~40 on IDE PATA drives.
Actually, the system is only about 5 months old and is running a P4 3.2mhz processor. The drives are SATA Hitachi units so it's definitely not an old PATA cable issue.
Cheers,
Hello,
I had a very similar problem with a bunch of supermicro boards (X6DVL-EG2). The problem was that the bios somehow confused libata so badly that it fell back to using the old ide legacy whatever thingy (resulting in hda instead of sda and of course no dma).
The solution was to fiddle with the sata settings in bios. Strangely enough, enabling mixed mode (pata and sata) in bios resulted in something the kernel could understand and libata has been happy ever since (reporting combined mode operation in dmesg).
good luck, Peter
On Sunday 12 March 2006 02:15, Chris Mauritz wrote:
Sudev Barar wrote:
On 11/03/06, Chris Mauritz chrism@imntv.com wrote:
Following-up my own post.....
I've also been able to determine that the affected system is using a Supermicro motherboard with an Intel 845GE chipset.
... Actually, the system is only about 5 months old and is running a P4 3.2mhz processor. The drives are SATA Hitachi units so it's definitely not an old PATA cable issue.
On Mon, 2006-03-13 at 08:44 +0100, Peter Kjellström wrote:
Hello,
I had a very similar problem with a bunch of supermicro boards (X6DVL-EG2). The problem was that the bios somehow confused libata so badly that it fell back to using the old ide legacy whatever thingy (resulting in hda instead of sda and of course no dma).
The solution was to fiddle with the sata settings in bios. Strangely enough, enabling mixed mode (pata and sata) in bios resulted in something the kernel could understand and libata has been happy ever since (reporting combined mode operation in dmesg).
cap makes a very good point. All the sata drives I use are registered as scsi drives and not ide drives (sda and sdb NOT hda and hdb).
try our new 2.6.9-34.EL kernel.
also make sure the motherboard has the latest bios from the manufacturer.
Johnny Hughes wrote:
On Mon, 2006-03-13 at 08:44 +0100, Peter Kjellström wrote:
Hello,
I had a very similar problem with a bunch of supermicro boards (X6DVL-EG2). The problem was that the bios somehow confused libata so badly that it fell back to using the old ide legacy whatever thingy (resulting in hda instead of sda and of course no dma).
The solution was to fiddle with the sata settings in bios. Strangely enough, enabling mixed mode (pata and sata) in bios resulted in something the kernel could understand and libata has been happy ever since (reporting combined mode operation in dmesg).
cap makes a very good point. All the sata drives I use are registered as scsi drives and not ide drives (sda and sdb NOT hda and hdb).
try our new 2.6.9-34.EL kernel.
Hmmm...I'd love to try the new kernel, but this machine is running 3.6. 8-( Is there a recommended procedure for doing this with a 3.6 box?
also make sure the motherboard has the latest bios from the manufacturer.
The machine is located about 100 miles away so I'm planning to visit it sometime in the next few days to do that and to fondle the SATA settings per Peter's suggestion. I only knew something was amiss when my remaining P3-733mhz machines were doing disk to disk backups at 4-5 times the speed of these relatively new P4 systems. 8-) Nobody ever noticed before because these machines don't do anything very disk intensive (except backups).
Cheers,
-
Chris Mauritz -
Johnny Hughes -
Peter Kjellström -
Sudev Barar