Custom Query (1376 matches)

​Dan Fandrich reported via database mailing list:

smartctl 7.2 works with a Buffalo MiniStation Cobalt drive (USB ID 0411:0157) with
the following patch to the drivedb.

--- /tmp/drivedb.h	2022-02-07 12:02:33.749758230 -0800
+++ /usr/share/smartmontools/drivedb.h	2022-02-07 12:09:00.483882887 -0800
@@ -5070,7 +5070,7 @@
     "-d sat"
   },
   { "USB: Buffalo; ",
-    "0x0411:0x0(1[df]9|1e7|240|251|27e)", // 0x01d9: HD-PCTU2 (0x0108), 0x01e7: HD-PNTU3,
+    "0x0411:0x0(157|1[df]9|1e7|240|251|27e)", // 0x0157: HD-PEU2, 0x01d9: HD-PCTU2 (0x0108), 0x01e7: HD-PNTU3,
       // 0x01f9: HD-PZU3 (0x0100), 0x0240: HD-PCFU3, 0x0251: HD-PNFU3, 0x027e: HD-LC3
     "",
     "",

I have a Mushkin Triactor 3D SSD drive that is very similar to the drives added in #905, and I would like to add it to the drivedb. The attributes seem to line up with the ones for those drives.

Hello,

I recently bought jmicron controllers to put away some duplication load (for mdraid level 1) from the system to those controllers. I have one jmb56x and two jmb39x attached, smart readings work well besides one thing which makes me stomachache: I need to force on one of them for a sector as its boot record is stored there.

with "hdparm --read-sector" I searched for a free one on this device and could not find one in the range of 33 <= LBA <= 62

Is there a specific reason why it is limited to this range? My partiton tables start at 2048, so there would be much sectors before which are free (and zero-filled). I tried with jmraidcon implementation, as I do not know how to e.g. mask 2047 in the command {READ_CMD, 0x00, 0x00, 0x00, 0x00, 0x21, 0x00, 0x00, 0x01, 0x00}; I just swapped 0x21 with 0xfe - LBA sector 254 which is also zero-filled on this device and it succeeds as well with this, so I assume the limited range is not caused by the JMicron controller not accepting the commands there?

I read all sectors until 2048 and from sector 105 starting they are all zero-filled (attached the txt of the affected drive). I would prefer to avoid always overwriting and restoring parts of my bootrecord, but as I am not sure why the limit is currently implemented this way, I would like to clarify this first. :-)

Thank you so much!

Best regards Alois