[smartmontools-support] smartmonclt behaves not correctly on IXP400 processors (armv5b target)

[Olivier P. <oli...@gm...>]

Dear all,

on 2006-10-20 00:29, Ouistyty <ouistyty@ho...> reported in
https://sourceforge.net/mailarchive/message.php?msg_id=37394649 that his
Seagate ST332062A0 installed on a Synology DS101 (a network hardrive box
running Linux) with firmware 2.01 - 3.0371was not recognised by smartmonctl.

I also have a Synology DS101j with a Maxtor MaxlineIII HD and I'm facing
the same issue than Ouistyty. The point is that I have exactly the same
drive on my linux PC and that on this linux PC smartctl works like a
charm with this very same HD. So I started some investigations:

For those who don't know, the DS101line of product run on a Intel IXP400
processor based on a ARM core. The gcc target is identified as a armv5b
one. The linux kernel is 2.4.22-uc0.


On the linux PC I have the followin results:

LinuxPC:/# smartctl -i /dev/hda
smartctl version 5.37 [i686-pc-linux-gnu] Copyright (C) 2002-6 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF INFORMATION SECTION ===
Model Family:     Maxtor MaXLine III family (ATA/133 and SATA/150)
Device Model:     Maxtor 7L300R0
Serial Number:    L625S2DG
Firmware Version: BAJ41G20
User Capacity:    300 090 728 448 bytes
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   7
ATA Standard is:  ATA/ATAPI-7 T13 1532D revision 0
Local Time is:    Sun Jan  7 10:40:17 2007 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled


Ok, excellent.


Now on the Synology DS101-j,I have:

DiskStation> smartctl -i /dev/hda
smartctl version 5.37 [armv5b-softfloat-linux-gnu] Copyright (C) 2002-6
Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF INFORMATION SECTION ===
Device Model:     aMtxro7 3L000R
Serial Number:    6L92M9G1
Firmware Version: AB4JG102
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   15
ATA Standard is:  Not recognized. Minor revision code: 0x1e00
Local Time is:    Sun Jan  7 10:44:24 2007 CET
SMART support is: Ambiguous - ATA IDENTIFY DEVICE words 82-83 don't show
if SMART supported.
                  Checking for SMART support by trying SMART ENABLE command.
                  SMART ENABLE appeared to work!  Continuing.
SMART support is: Available - device has SMART capability.
SMART support is: Disabled




Look, the device model: "aMtxro7 3L000R" instead of "Maxtor 7L300R0".
Bytes are swapped on the ds-101j !!!! Same for the Serial Number and the
Firmware Version...
Looks like we have a big/little endian issue with thje ds-101j (which
runs on Intel IXP400 processeur (armv5b target))

I will not show the output of "smartctl -a /dev/hda" command as it is
quite long but believe me when I say it's ok on my linux PC and outpouts
only garbage on the DS-101j (like on post
https://sourceforge.net/mailarchive/message.php?msg_id=37394649)

So I started to look at the source code and found out that:

1.  utility.cpp, function "isbigendian" returns 1 on the DS-101j whereas
0 is expected (well I think so at least as some googling told me the
IXP400 is little endian). So I hardcoded a 0 as return value here.

2. ataprint.c, function "formatdriveidstring", line 100, replace:
#ifndef __NetBSD__
  swapbytes(tmp, in, n);
#else

by:
#ifndef __NetBSD__
  strncpy(tmp, in, n);
#else


With these 2 modifications, the output of "smartctl -i /dev/hda" is now
OK on the DS-101j and the output of "smartctl -a /dev/hda" is almost OK,
except for the Vendor Attributes which remain garbage.

If I remove the hack #1 (isbigendian returns 0), then the "User
Capacity" field is not returned and the "ATA version" is returned
incorrectly. I went through the functions that get and format these
fields and couldn't find a relationship with "isbigendian"...

Anyway, i now give all my foundings back to the community but still
wonder if the issue is in smartctl code or in kernel ioctls that return
any data back to smartctl...
However if the kernel were buggy I suspect a lot of things wouldn't work
as expected on the DS-101j...


I'd be glad to hear something from you and to help you debug this issue!

Regards
Olivier