[piotrpiano]

Hello,

As there are two "documented" cases of DL 3.0 not running harddisks in dma mode (Tiguere90 and myself), the goal of this thread is to possibly find other users touched by this issue, who could provide some help in testing and tracking down this bug.

So please check your disks using following command (in terminal):

sudo hdparm -X -d1 --verbose /dev/your_harddisk_symbol

Additionally, you can also run this one:

sudo hdparm -tT /dev/your_harddisk_symbol

- DON'T use command "sudo hdparm -i /dev/your_disk" as it gives false results
- Please run this test for all your pata and sata disks in your system
- Please test it on Dreamlinux running natively i.e. as LiveCD or hd install, not in virtual environment

Copy & paste your results here.

If your DL system is suspiciously slow, it may be due to this problem.

Thanks
Piotr

P.S. the original thread about dma problem here: http://dreamlinuxforums.org/index.php/topic,417.0.html

[andrepsb]

Hi,

Let's try to solve thtis:

Code:

andre@DL3-xfce:~$ sudo hdparm -X -d1 --verbose /dev/hda

/dev/hda:
 setting using_dma to 1 (on)
 setting xfermode to 0 (default PIO mode)
outgoing cdb:  85 06 20 00 03 00 00 00 00 00 00 00 00 40 ef 00
ioctl(fd,SG_IO): Invalid argument
trying legacy HDIO_DRIVE_CMD
 using_dma     =  1 (on)
andre@DL3-xfce:~$ sudo hdparm -tT /dev/hda

/dev/hda:
 Timing cached reads:   772 MB in  2.00 seconds = 385.20 MB/sec
 Timing buffered disk reads:  170 MB in  3.04 seconds =  56.01 MB/sec
andre@DL3-xfce:~$

Best regards,
André

[Resa]

Performed the test on my "old" PIII from LiveCD.
Here are the test results

Code:

dreamer@DL:~$ sudo hdparm -X -d1 --verbose /dev/hda

/dev/hda:
 setting using_dma to 1 (on)
 setting xfermode to 0 (default PIO mode)
outgoing cdb:  85 06 20 00 03 00 00 00 00 00 00 00 00 40 ef 00
ioctl(fd,SG_IO): Invalid argument
trying legacy HDIO_DRIVE_CMD
 using_dma     =  1 (on)
dreamer@DL:~$ sudo hdparm -tT /dev/hda

/dev/hda:
 Timing cached reads:   190 MB in  2.01 seconds =  94.47 MB/sec
 Timing buffered disk reads:   58 MB in  3.03 seconds =  19.14 MB/sec

Although this area is defenitely not my area of expertice, I understand from the above that DMA is used.
Which IMHO also is what the "NOT TO BE USED COMMAND" also indicates, see below

Code:

dreamer@DL:~$ sudo hdparm -i /dev/hda

/dev/hda:

 Model=SAMSUNG SV4084H, FwRev=PM100-13, SerialNo=0274J1FR306469
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=34902, SectSize=554, ECCbytes=4
 BuffType=DualPortCache, BuffSize=426kB, MaxMultSect=16, MultSect=16
 CurCHS=4047/16/255, CurSects=16511760, LBA=yes, LBAsects=79730784
 IORDY=yes, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4
 DMA modes:  mdma0 mdma1 mdma2
 UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: ATA/ATAPI-4 T13 1153D revision 17:  ATA/ATAPI-1,2,3,4,5,6

 * signifies the current active mode

Maybe I am thinking in the wrong direction here, but could it be that only a specific sort of hardware and/or hardware combination results in a wrong indication?

[mandog]

I've just done those tests on Parsix which is installed and on Ubuntu installed "sudo hdparm -X -d1 --verbose /dev/hda" in Ubuntu says DMA on but not in Parsix. This and reading Debian forums leads me to believe it is a bug in either Lenny or Testing but does not mean DMA is not working correctly  Parsix transfers file data from 1 hardrive to another faster than Ubuntu if I do "dmesg |grep ata" in parsix it says all drives set up for DMA. When Dreamlinux was on my hardrive. I could not perform any tests at all except "hdparm -tT /dev/sda" which was ok  on top line but drastically slow on the second line. The same test in Parsix and Ubuntu the second line is acceptable for my ide drives, which again makes me believe  "sudo hdparm -X -d1 --verbose /dev/hda" is not always accurate with Lenny Testing, And seeing I was not able to even perform the first test on Dreamlinux also confirms their is something wrong. Also on my machine Ubuntu Uses "/dev/hda", Parsix Dreamlinux, uses "/dev/sda I'm not on Sata so that could give the strange test result.Dreamlinux was so slow it took over 1hr to install, Parsix takes under 10min from pressing install to clicking FFox, that includes activating my network connection. 
 Just tried the "sudo hdparm -X -d1 --verbose /dev/sda" on a different drive this gives  HDIO_SET_DMA failed: Inappropriate ioctl for device

[tigar55]

Here's my output :

/dev/sda:
 setting using_dma to 1 (on)
 HDIO_SET_DMA failed: Invalid argument
 setting xfermode to 0 (default PIO mode)
outgoing cdb:  85 06 20 00 03 00 00 00 00 00 00 00 00 40 ef 00
SG_IO: ATA_16 status=0x0, host_status=0x5, driver_status=0x0
trying legacy HDIO_DRIVE_CMD
 HDIO_DRIVE_CMD(setxfermode) failed: Invalid argument
tigar@Kiki:~$ sudo hdparm -tT /dev/sda               

/dev/sda:
 Timing cached reads:   756 MB in  2.00 seconds = 377.20 MB/sec
 Timing buffered disk reads:   74 MB in  3.02 seconds =  24.52 MB/sec

[noisome]

root@Poison-x40:~# hdparm -X -d1 --verbose /dev/hda

/dev/hda:
 setting using_dma to 1 (on)
 setting xfermode to 0 (default PIO mode)
outgoing cdb:  85 06 20 00 03 00 00 00 00 00 00 00 00 40 ef 00
ioctl(fd,SG_IO): Invalid argument
trying legacy HDIO_DRIVE_CMD
 using_dma     =  1 (on)
root@Poison-x40:~# hdparm -tT /dev/hda

/dev/hda:
 Timing cached reads:   1064 MB in  2.00 seconds = 531.53 MB/sec
 Timing buffered disk reads:   56 MB in  3.03 seconds =  18.47 MB/sec

[camaro]

Heres mine, not the best result!

Hard drive

Code:

/dev/sda:
 setting using_dma to 1 (on)
 HDIO_SET_DMA failed: Inappropriate ioctl for device
 setting xfermode to 0 (default PIO mode)
outgoing cdb:  85 06 20 00 03 00 00 00 00 00 00 00 00 40 ef 00
SG_IO: ATA_16 status=0x2, host_status=0x0, driver_status=0x8
SG_IO: bad/missing ATA_16 sense data::  70 00 05 00 00 00 00 0a 00 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 HDIO_DRIVE_CMD(setxfermode) failed: Input/output error

DVD RW

Code:

/dev/hda:
 setting using_dma to 1 (on)
 HDIO_SET_DMA failed: Operation not permitted
 setting xfermode to 0 (default PIO mode)
outgoing cdb:  85 06 20 00 03 00 00 00 00 00 00 00 00 40 ef 00
SG_IO: ATA_16 status=0x2, host_status=0x0, driver_status=0x0
trying legacy HDIO_DRIVE_CMD
 using_dma     =  0 (off)

[ponadok]

hda

/dev/hda1:
 setting using_dma to 1 (on)
 HDIO_SET_DMA failed: Invalid argument
 setting xfermode to 0 (default PIO mode)
outgoing cdb:  85 06 20 00 03 00 00 00 00 00 00 00 00 40 ef 00
ioctl(fd,SG_IO): Invalid argument
trying legacy HDIO_DRIVE_CMD
 using_dma     =  0 (off)

[Resa]

Seems that both results DMA on and DMA off occur. So anyone has got a comment on my earlier post?

Maybe I am thinking in the wrong direction here, but could it be that only a specific sort of hardware and/or hardware combination results in a wrong indication?

[piotrpiano]

Seems that both results DMA on and DMA off occur. So anyone has got a comment on my earlier post?

Maybe I am thinking in the wrong direction here, but could it be that only a specific sort of hardware and/or hardware combination results in a wrong indication?

Yes, it seems that users touched by this problem are still in minority (it's not an isolated case though, as this thread shows) and it most likely manifests itself on some certain harware combination. The big question is: which hardware combination and how to resolve it. I hope Nelsongs finds time in next days to dig deeper into  it.
I asked not to use hdparm -i command because it shows udma 6 in my system, although hdparm -X -d indicates "using dma: 0 (off)" and my trasfer rates are very low, so the reslults reported by -i don't show the real situation...

[mandog]

This test fails on Dreamlinux as you can see it does not reconise any ati drives the same test on other Lenny/Sid based distros list all drives the max DMA settings and what they are set to
kelvin@kelvin:~$ dmesg |grep ata
 BIOS-e820: 000000007fff3000 - 0000000080000000 (ACPI data)
Memory: 2069124k/2097088k available (2509k kernel code, 26776k reserved, 980k data, 352k init, 1179584k highmem)
      .data : 0xc037347f - 0xc04685d0   ( 980 kB)
libata version 2.21 loaded.
pata_amd 0000:00:09.0: version 0.3.9
pata_amd 0000:00:09.0: failed to request/iomap BARs for port 0 (errno=-16)
pata_amd 0000:00:09.0: failed to request/iomap BARs for port 1 (errno=-16)
pata_amd 0000:00:09.0: no available native port
kelvin@kelvin:~$

This is the same test from Parsix which is also Lenny/sid as you can see it lists all drives and details.

kelvin@kelvin:~$ dmesg |grep ata
 BIOS-e820: 000000007fff3000 - 0000000080000000 (ACPI data)
Memory: 2067500k/2097088k available (2250k kernel code, 28384k reserved, 807k data, 252k init, 1179584k highmem)
      .data : 0xc0432826 - 0xc04fc6c4   ( 807 kB)
libata version 2.21 loaded.
pata_amd 0000:00:09.0: version 0.3.9
scsi0 : pata_amd
scsi1 : pata_amd
ata1: PATA max UDMA/133 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001f000 irq 14
ata2: PATA max UDMA/133 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001f008 irq 15
ata1.00: ATA-7: Maxtor 4R080J0, RAMB1TU0, max UDMA/133
ata1.00: 160086528 sectors, multi 16: LBA
ata1.01: ATA-7: WDC WD2500JB-55REA0, 20.00K20, max UDMA/100
ata1.01: 488397168 sectors, multi 16: LBA48
ata1.00: configured for UDMA/133
ata1.01: configured for UDMA/100
ata2.00: ATAPI: DVDR   PX-750A, 1.03, max UDMA/66
ata2.01: ATAPI: LITE-ON DVD SOHD-16P9SV, F$02, max UDMA/33
ata2.00: configured for UDMA/66
ata2.01: configured for UDMA/33
kelvin@kelvin:~$


I don't know if this has any bearing on the problem but libata is mentioned in 1 of the posts on the forum and on the Debian Forum as you can see its present in both tests as loaded but in the Dreamlinux test does not seem to do anything.

[andrepsb]

This is my result for this other test on DL3:

andre@DL3-xfce:~$ dmesg |grep ata
 BIOS-e820: 000000003bfc0000 - 000000003bfce000 (ACPI data)
Memory: 964180k/982784k available (2509k kernel code, 18036k reserved, 980k data, 352k init, 65280k highmem)
      .data : 0xc037347f - 0xc04685d0   ( 980 kB)
libata version 2.21 loaded.
sata_via 0000:00:0f.0: version 2.3
sata_via 0000:00:0f.0: routed to hard irq line 11
scsi0 : sata_via
scsi1 : sata_via
ata1: SATA max UDMA/133 cmd 0x0001ec00 ctl 0x0001e882 bmdma 0x0001e400 irq 16
ata2: SATA max UDMA/133 cmd 0x0001e800 ctl 0x0001e482 bmdma 0x0001e408 irq 16
ata1: SATA link down 1.5 Gbps (SStatus 0 SControl 300)
ata2: SATA link down 1.5 Gbps (SStatus 0 SControl 300)
ReiserFS: hda8: using ordered data mode
ReiserFS: hda7: using ordered data mode
ReiserFS: hda6: using ordered data mode
andre@DL3-xfce:~$

[RuudKuin]

ruud@N1050v:~$ sudo hdparm -X -d1 --verbose /dev/hda3
/dev/hda3:
 setting using_dma to 1 (on)
 HDIO_SET_DMA failed: Invalid argument
 setting xfermode to 0 (default PIO mode)
outgoing cdb:  85 06 20 00 03 00 00 00 00 00 00 00 00 40 ef 00
ioctl(fd,SG_IO): Invalid argument
trying legacy HDIO_DRIVE_CMD
 using_dma     =  0 (off)

Whatever it means to you...

Ruud

[Resa]

My previous post was while running the LiveCD, below are the test after installing DL 3.0 Beta3 (non modified version) as a dual boot on the before mentioned PIII

Code:

rdrijsen@Beta3-PIII:~$ dmesg | grep ata
 BIOS-e820: 000000000fff0000 - 000000000fff8000 (ACPI data)
Memory: 249744k/262080k available (2509k kernel code, 11808k reserved, 980k data, 352k init, 0k highmem)
      .data : 0xc037347f - 0xc04685d0   ( 980 kB)
libata version 2.21 loaded.
EXT3-fs: mounted filesystem with ordered data mode.
EXT3-fs: mounted filesystem with ordered data mode.

Code:

rdrijsen@Beta3-PIII:~$ sudo hdparm -X -d1 --verbose /dev/hda5

/dev/hda5:
 setting using_dma to 1 (on)
 HDIO_SET_DMA failed: Invalid argument
 setting xfermode to 0 (default PIO mode)
outgoing cdb:  85 06 20 00 03 00 00 00 00 00 00 00 00 40 ef 00
ioctl(fd,SG_IO): Invalid argument
trying legacy HDIO_DRIVE_CMD
 using_dma     =  1 (on)

Code:

rdrijsen@Beta3-PIII:~$ sudo hdparm -tT /dev/hda5

/dev/hda5:
 Timing cached reads:   194 MB in  2.01 seconds =  96.47 MB/sec
 Timing buffered disk reads:   72 MB in  3.04 seconds =  23.68 MB/sec

[piotrpiano]

First off, I'd like to thank all of you guys who done this test so far! The more the better, keep it coming!

@mandog

I also got silmilar results with pata drives to yours under DL:
dmesg |grep ata

Code:

BIOS-e820: 000000003fff3000 - 0000000040000000 (ACPI data)
Memory: 1029292k/1048512k available (2509k kernel code, 18552k reserved, 980k data, 352k init, 131008k highmem)
      .data : 0xc037347f - 0xc04685d0   ( 980 kB)
libata version 2.21 loaded.
sata_sil 0000:01:0b.0: version 2.3
scsi0 : sata_sil
scsi1 : sata_sil
ata1: SATA max UDMA/100 cmd 0xf8818080 ctl 0xf881808a bmdma 0xf8818000 irq 16
ata2: SATA max UDMA/100 cmd 0xf88180c0 ctl 0xf88180ca bmdma 0xf8818008 irq 16
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata1.00: ATA-6: ST380013AS, 3.05, max UDMA/133
ata1.00: 156301488 sectors, multi 16: LBA48
ata1.00: configured for UDMA/100
ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata2.00: ATA-6: ST380013AS, 3.05, max UDMA/133
ata2.00: 156301488 sectors, multi 16: LBA48
ata2.00: configured for UDMA/100
pata_amd 0000:00:09.0: version 0.3.9
pata_amd 0000:00:09.0: failed to request/iomap BARs for port 0 (errno=-16)
pata_amd 0000:00:09.0: failed to request/iomap BARs for port 1 (errno=-16)
pata_amd 0000:00:09.0: no available native port
EXT3-fs: mounted filesystem with ordered data mode.
EXT3-fs: mounted filesystem with ordered data mode.
EXT3-fs: mounted filesystem with ordered data mode.
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: cmd ef/05:fe:00:00:00/00:00:00:00:00/40 tag 0 cdb 0x0 data 0
ata1.00: configured for UDMA/100
ata1: EH complete
ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata2.00: cmd ef/05:fe:00:00:00/00:00:00:00:00/40 tag 0 cdb 0x0 data 0
ata2.00: configured for UDMA/100
ata2: EH complete

It looks fine in Sata departament, and indeed, sata works fine (2 disks in raid 0). The problem is with the pata disks...
For the comaprison, here are the results form Ubuntu Studio 7.10:

dmesg |grep ata

Code:

[    0.000000]  BIOS-e820: 000000003fff3000 - 0000000040000000 (ACPI data)
[   26.630137] Memory: 1021356k/1048512k available (2056k kernel code, 26476k reserved, 969k data, 364k init, 131008k highmem)
[   26.630154]       .data : 0xc03023dc - 0xc03f4b44   ( 969 kB)
[   30.365839] libata version 2.21 loaded.
[   33.083256] sata_sil 0000:01:0b.0: version 2.2
[   33.087174] scsi0 : sata_sil
[   33.089754] scsi1 : sata_sil
[   33.090015] ata1: SATA max UDMA/100 cmd 0xf8814080 ctl 0xf881408a bmdma 0xf8814000 irq 19
[   33.090021] ata2: SATA max UDMA/100 cmd 0xf88140c0 ctl 0xf88140ca bmdma 0xf8814008 irq 19
[   33.594080] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[   33.597670] ata1.00: ATA-6: ST380013AS, 3.05, max UDMA/133
[   33.597673] ata1.00: 156301488 sectors, multi 16: LBA48
[   33.603675] ata1.00: configured for UDMA/100
[   34.107412] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[   34.111004] ata2.00: ATA-6: ST380013AS, 3.05, max UDMA/133
[   34.111007] ata2.00: 156301488 sectors, multi 16: LBA48
[   34.117057] ata2.00: configured for UDMA/100
[   35.028652] EXT3-fs: mounted filesystem with ordered data mode.
[  105.529758] EXT3-fs: mounted filesystem with ordered data mode.
[  106.098118] EXT3-fs: mounted filesystem with ordered data mode.

I don't know if this has any bearing on the problem but libata is mentioned in 1 of the posts on the forum and on the Debian Forum as you can see its present in both tests as loaded but in the Dreamlinux test does not seem to do anything.

This I find strange. The libata seems to be loaded but when I run lsmod |grep ata I get following modules listed:

Code:

ata_generic             8580  0
pata_amd               13444  0

So, no indication of libata being loaded.

In Ubuntu it looks like that:

Code:

ata_generic             8580  0
sata_sil               12424  2
libata                125424  2 ata_generic,sata_sil
scsi_mod              148844  4 sbp2,sg,sd_mod,libata