Background ========== I am building a gentoo linux server on a ASUS E45-M1-I x86_64 motherboard. It has two hard disk sda is SSD and sdb is a conventional HDD. The HDD is to be used for backups (overnight) so spends most of its time spun-down. It is spun down using "hdparm -S 12 /dev/sdb" For convenience the server has KDE 4.8.5 installed. The Problem =========== Occasionally, I have noticed that the box will reboot only very slowly and when it does the HDD will no longer be detected as a device. Is it a udisks bug? =================== Output from /var/log/messages from just after a user logs into KDE shows: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen ata2.00: failed command: SMART ata2.00: cmd b0/d1:01:00:4f:c2/00:00:00:00:00/00 tag 0 pio 512 in res 50/00:00:00:00:00/00:00:00:00:00/40 Emask 0x4 (timeout) ata2.00: status: { DRDY } ata2: hard resetting link ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300) ata2.00: configured for UDMA/133 ata2: EH complete On a hunch I suspected udisks and eventually found the commenting out the following line in /lib/udev/rules.d/80-udisks.rules fixed the problem KERNEL=="sd*[!0-9]", ATTR{removable}=="0", ENV{ID_BUS}=="ata", ENV{DEVTYPE}=="disk", IMPORT{program}="udisks-probe-ata-smart $tempnode" In Summary ========== How important is the above line? Is this a udisks bug or a libata bug? If this is suspected of being a udisks bug, please advise what other info you need to tract it down Many thanks theDuck
To answer your question, I don't think this is a udisks bug but it may have been caused by use of libatasmart to trigger a bug in the disk. In udisks 2.0 we rely on udev/systemd's ata_id to figure out if the disk is SMART capable and/or SMART is enabled. Either way, development focus is on udisks 2.0 which is a completely different codebase so closing WORKSFORME. Please reopen if the problem persists with udisks 2.0. Thanks.
Hi, udisk-2.1.0 has just been masked as stable in the gentoo distribution and with this upgrade this error returns in exactly the same way as originally described. Unfortunately, /lib/udev/rules.d/80-udisks.rules is nowhere to be seen with udev200. Is there another way to stop udisks probing for the smart properties of the disk? Is there a way to
Hi, Sorry, I could not work out how to finish the above, so have added another comment. Is there a way to stop udisks demon or is this counter productive? Many thanks theDuck
Saying "in exactly the same way as originally described" doesn't really help because the binary you are referring to simply does not exist. I don't doubt you are experiencing a problem with your OS but you have to explain why you think this is a problem with udisks 2.x. Don't reopen the bug until you've done this, please. Thanks.
Hi, Sorry. Perhaps you will allow me to try again. This problem with my OS has reappeared with udisksd-2.1.0. The "background" and "problem" remain exactly as before. However, a grep for udisksd in /var/log/messages turns up an error from udisksd Jun 20 18:30:20 merlin udisksd[3403]: udisks daemon version 2.1.0 starting Jun 20 18:30:20 merlin udisksd[3403]: Acquired the name org.freedesktop.UDisks2 on the system message bus Jun 20 18:31:36 merlin udisksd[3403]: Error performing housekeeping for drive /org/freedesktop/UDisks2/drives/ST31500541AS_6XW026FA: Error updating SMART data: sk_disk_smart_read_data: Input/output error (udisks-error-quark, 0) Where else might I look next to try and resolve this error? Many thanks, theDuck
(In reply to comment #5) > Jun 20 18:31:36 merlin udisksd[3403]: Error performing housekeeping for > drive /org/freedesktop/UDisks2/drives/ST31500541AS_6XW026FA: Error updating > SMART data: sk_disk_smart_read_data: Input/output error (udisks-error-quark, > 0) This has nothing to do with the problem you are experiencing - it's a harmless warning message. > Where else might I look next to try and resolve this error? I would talk to the people who maintains the OS you are using. In this case, use the Gentoo bug tracker. In general, users should not be filing bugs upstream unless you they 100% sure it's a problem with the upstream product.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.