Bug 264681

Please attach your yast logs.

http://en.opensuse.org/Bugs/YaST

Created attachment 131458 [details]
y2logs openSUSE Alpha 3

I don't see any related error message in the logs. What exactly do you mean by saying that it doesn't work?

Created attachment 132640 [details]
"IDE DMA" Yast module bug screenshot

Actually, no Hard Disks are listed at all.

Thank you, please attach your /var/log/messages output of 'hwinfo --disk' and 'dmesg'.

Created attachment 132921 [details]
dmesg

Created attachment 132922 [details]
output of "hwinfo --disk"

Created attachment 132923 [details]
file: /var/log/messages

reassigned to maintainer or yast2-tune

It's caused by /dev/hd* -> /dev/sd* transition.

Steffen, how can I detect IDE (PATA) devices? Yast uses .probe.ide and removes devices which do not match /dev/hd* pattern (to remove SATA drives).

Good question. I'll check.

Hm, I can separate ATA from SCSI, but see no good way to differentiate
between ATA and SATA.

But there's more to it:

a) 56-idedma.rules matches only hdX to /lib/udev/idedma.sh, so
   sdX isn't even consided, but

b) 'hdparm -d' doesn't work with libata devices

So currently the IDE DMA Mode setting thing seems to be non-working
in several ways. :-)

Maybe it's obsolete and the libata drivers handle it all automatically?

Kay, do you know what the current intention is here?

I'm not sure, if libata drives need manual DMA settings in some cases. Tejun, will know. :)

libata currently doesn't support configuring DMA settings for the following two reasons.

1. Things like that gotta be done automatically and libata is pretty good at it.

2. (admittedly more importantly) It's difficult to get right.  IDE allowed it but it never was safe.  Currently the biggest road block is controllers which require host-wide (cross-ports) quiescence to change transfer mode.

It's scheduled to be added but priority is rather low.  When it gets implemented the primary interface will be issuing SETFEATURES - SETXFERMODE using SG_IO.  hdparm will probably be updated accordingly when it happens.

You can tell discern libata devices among SCSI devices by examining Device identification VPD page (0x83).

# sdparm --inquiry --page=0x83 /dev/sda
    /dev/sda: ATA       WDC WD5000YS-01M  07.0
Device identification VPD page:
  Addressed logical unit:
    desig_type: vendor specific [0x0],  code_set: ASCII
 00     20 20 20 20 20 57 44 2d  57 4d 41 4e 55 31 32 31         WD-WMANU121
 10     35 30 39 34                                         5094            
    desig_type: T10 vendor identification,  code_set: ASCII
      vendor id: ATA     
      vendor specific: WDC WD5000YS-01MPB0                          WD-WMANU1215094

The vendor id is ATA if it's a libata device.  You can access this info more easily with 'lsscsi'.

# lsscsi
[0:0:0:0]    disk    ATA      WDC WD5000YS-01M 07.0  /dev/sda
[1:0:0:0]    disk    ATA      WDC WD5000YS-01M 07.0  /dev/sdb
[2:0:0:0]    disk    ATA      SAMSUNG SP2504C  VT10  /dev/sdc
[4:0:0:0]    disk    SAMSUNG  HD300LD          0000  /dev/sdd

However, ATA vendor ID is from SAT (SCSI-ATA translation) standard so other SAT implementations probably use it too (ATA disk attached to SAS port).  But they're ATA devices too so probably can be dealt with the same way in most cases.  If you really have to discern libata devices, you can issue HDIO_GET_IDENTITY ioctl to it and see whether it returns valid ATA IDENTIFY page.  Sorry about the clumsy mechanism.  We'll have something better when libata receives its own sysfs nodes.

Just in case it's confusing.  In the above lsscsi result, the first three drives are attached via libata which is a SAT implementation and thus uses ATA as its vendor ID.  The last one [4:0:0:0] is a USB storage device and thus not a SAT device and it uses the harddisk's vendor ID (SAMSUNG) directly.

This means, we should - at least for now - remove the module completely.

Doesn't make much sense with SATA disks anyway.  For SATA, what matters is the PHY speed (1.5Gbps or 3.0) and whether NCQ is enabled.

Ok, the yast module has been disabled in yast2-tune-2.15.5

The libata problem is reported separately in bug #268323.

Marking as LATER (can be fixed when the libata/hdparm support is ready)

Documentation impact - added Docu people to CC

What do you mean by disabled ?
Will it be installed by default on Alpha 4 ?

"Disabled" means that the desktop file has been removed, the module will be installed but it will be hidden (no icon in the control center).

But it will be possible to start it manually ('yast2 idedma'), if you manually switch back to the old (non-libata) drivers you can still use the yast module...

Reopened

Tejun, what's the current status? Is (or will be) it possible to change DMA mode in 11.1? If not I'll close the bug as WONFIX.

It's currently under works but am not sure whether it will make it in time for 11.1 (priority is relatively low and tons of other stuff going on too...).  Feel free to close as WONTFIX or leave it open.  I'll try to remember to update this bug entry if something changes but pinging me after a while would be good idea.  :-)

Thanks.

Tejun, is there something new regarding to the DMA setting feature?

Sorry, no progress yet.  :-(

OK, resolving as WONTFIX.

Let me know if something is changed.

I'll.  Thanks.