Re: MNT Reform2 USB LCP flash
On Sun, Feb 04, 2024 at 10:37:59AM +0200, Staffan Thomen wrote: > According to this random website I found[1]... > > [1] https://www.stix.id.au/wiki/SCSI_Sense_Data Hardly random - and thanks for the reminder, I hadn't updated that for 4 years. Cheers, -- Paul Ripke "Great minds discuss ideas, average minds discuss events, small minds discuss people." -- Disputed: Often attributed to Eleanor Roosevelt. 1948.
Re: MNT Reform2 USB LCP flash
Staffan Thomen writes: > Right, with this information is was very easy to put together a patch, > and I can now mount the LPC fake umass device on my netbsd laptop. I > didn't try writing the firmware yet but I'm sure that'll work too. > > Patch follows for anyone who might have need. I assume a PR is the best > way of getting this committed? Wouldn't it be neat if one could manipulate the kernel quirks information from userland (moderated by the securelevel)? So when this strange USB device is plugged in and causes error messages, one can just detach it, add one or more quirks, say by having drvctl read or write plist entries from/to the kernel, plug it in again, and just have it work. -jarle -- "Meh, good enough." -- Mediocrates
Re: MNT Reform2 USB LCP flash
On 2/4/24 19:36, Michael van Elst wrote:
There seems to be nothing yet for NO_START_STOP. There is
PQUIRK_START
that forces a start at attach time. But at open time when the unit
still does not report ready, we issue the comamnd again (and fail if
it doesn't succeed). We probably need another quirk PQUIRK_NOSTART
and check it in scsipi_start() similar to the PQUIRK_NODOORLOCK in
scsipi_prevent().
Right, with this information is was very easy to put together a patch,
and I can now mount the LPC fake umass device on my netbsd laptop. I
didn't try writing the firmware yet but I'm sure that'll work too.
Patch follows for anyone who might have need. I assume a PR is the best
way of getting this committed?
Staffan (will probably be happily insomniac from this and zombie
tomorrow :-)
--8<--
# HG changeset patch
# User Staffan Thomen
# Date 1707080552 0
# Sun Feb 04 21:02:32 2024 +
# Branch netbsd-10
# Node ID f368df5ceae4dbeb3a6a10e7e8b3c6668dc08303
# Parent 7ddaaaeb813a1bceaf4190cb6c3444cc3c225ebb
Round up cylinders to 1 if the device is so small it would be 0
diff -r 7ddaaaeb813a -r f368df5ceae4 sys/dev/scsipi/sd.c
--- a/sys/dev/scsipi/sd.c Tue Jan 16 08:28:51 2024 +
+++ b/sys/dev/scsipi/sd.c Sun Feb 04 21:02:32 2024 +
@@ -1769,6 +1769,8 @@
dp->heads = 64;
dp->sectors = 32;
dp->cyls = dp->disksize / (64 * 32);
+ if (dp->cyls == 0)
+ dp->cyls = 1;
}
dp->rot_rate = 3600;
# HG changeset patch
# User Staffan Thomen
# Date 1707080615 0
# Sun Feb 04 21:03:35 2024 +
# Branch netbsd-10
# Node ID fb8c5f27a9473039c3bc82d453164ab2c201d5f4
# Parent f368df5ceae4dbeb3a6a10e7e8b3c6668dc08303
Add the PQUIRK_NOSTART quirk to prevent a START command from being sent
to devices that don't support them
diff -r f368df5ceae4 -r fb8c5f27a947 sys/dev/scsipi/scsipi_base.c
--- a/sys/dev/scsipi/scsipi_base.c Sun Feb 04 21:02:32 2024 +
+++ b/sys/dev/scsipi/scsipi_base.c Sun Feb 04 21:03:35 2024 +
@@ -1312,6 +1312,9 @@
{
struct scsipi_start_stop cmd;
+ if (periph->periph_quirks & PQUIRK_NOSTART)
+ return 0;
+
memset(, 0, sizeof(cmd));
cmd.opcode = START_STOP;
cmd.byte2 = 0x00;
diff -r f368df5ceae4 -r fb8c5f27a947 sys/dev/scsipi/scsipiconf.h
--- a/sys/dev/scsipi/scsipiconf.h Sun Feb 04 21:02:32 2024 +
+++ b/sys/dev/scsipi/scsipiconf.h Sun Feb 04 21:03:35 2024 +
@@ -504,6 +504,7 @@
#define PQUIRK_NOREPSUPPOPC 0x0100 /* does not grok
REPORT SUPPORTED OPCODES
to fetch device timeouts */
+#define PQUIRK_NOSTART 0x0200 /* does not support START STOP */
/*
* Error values an adapter driver may return
*/
# HG changeset patch
# User Staffan Thomen
# Date 1707080713 0
# Sun Feb 04 21:05:13 2024 +
# Branch netbsd-10
# Node ID cb668c56dec8cabbe5d0f6ed362d35db3faef28a
# Parent fb8c5f27a9473039c3bc82d453164ab2c201d5f4
Add the NXP vendor and the LPC1XXX product to apply its quirks
diff -r fb8c5f27a947 -r cb668c56dec8 sys/dev/usb/umass_quirks.c
--- a/sys/dev/usb/umass_quirks.cSun Feb 04 21:03:35 2024 +
+++ b/sys/dev/usb/umass_quirks.cSun Feb 04 21:05:13 2024 +
@@ -343,6 +343,16 @@
UMATCH_VENDOR_PRODUCT,
NULL, NULL
},
+
+ /* NXP LPC1xxx series ISP (In-System Programming) devices */
+
+ { { USB_VENDOR_NXP, USB_PRODUCT_NXP_LPC1XXX },
+ UMASS_WPROTO_UNSPEC, UMASS_CPROTO_UNSPEC,
+ 0,
+ PQUIRK_NOSTART | PQUIRK_NODOORLOCK | PQUIRK_NOSYNCCACHE |
PQUIRK_ONLYBIG,
+ UMATCH_VENDOR_PRODUCT,
+ NULL, NULL
+ }
};
const struct umass_quirk *
diff -r fb8c5f27a947 -r cb668c56dec8 sys/dev/usb/usbdevs
--- a/sys/dev/usb/usbdevs Sun Feb 04 21:03:35 2024 +
+++ b/sys/dev/usb/usbdevs Sun Feb 04 21:05:13 2024 +
@@ -563,6 +563,7 @@
vendor LINUXFOUNDATION 0x1d6b Linux Foundation
vendor CINTERION 0x1e2d Cinterion
vendor AIRTIES 0x1eda AirTies
+vendor NXP 0x1fc9 NXP
vendor DLINK 0x2001 D-Link
vendor PLANEX2 0x2019 Planex Communications
vendor ENCORE 0x203d Encore
@@ -2572,6 +2573,9 @@
product NOVATEL2 U760_DRIVER 0x5030 Novatel Wireless U760 Windows/Mac
Driver
product NOVATEL2 U760 0x6000 Novatel 760USB
+/* NXP products */
+product NXP LPC1XXX 0x000b NXP LPC1xxx IFLASH
+
/* Olympus products */
product OLYMPUS C1 0x0102 C-1 Digital Camera
product OLYMPUS C700 0x0105 C-700 Ultra Zoom
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: MNT Reform2 USB LCP flash
staf...@shangtai.net (=?UTF-8?B?U3RhZmZhbiBUaG9tw6lu?=) writes: >While I was fiddling around with it, I booted a FreeBSD-14 thumbdrive >and there it does work as well, and their driver helpfully tells you >what quirks it uses. This is what I found: >umass quirks: 0xc104 >0x0004 - NO_START_STOP, "The drive does not support START STOP" >0x0100 - NO_GETMAXLUN, "No GetMaxLun call" >0x4000 - NO_SYNCHRONIZE_CACHE, "Deice cannot handle a SCSI synchronize >cache command." >0x8000 - NO_PREVENT_ALLOW, "Device does not support PREVENT/ALLOW MEDIUM >REMOVAL" >da: quirks: 0x2 >0x2 NO_6_BYTE - use SBC (10-byte) commands instead of RBC (6-byte) commands There is sys/dev/usb/umass_quirks.c. These quirks exist: PQUIRK_NOSYNCCACHE (like NO_SYNCHRONIZE_CACHE) PQUIRK_NODOORLOCK (like NO_PREVENT_ALLOW) PQUIRK_ONLYBIG (like NO_6_BYTE) We don't do GetMaxLun. There seems to be nothing yet for NO_START_STOP. There is PQUIRK_START that forces a start at attach time. But at open time when the unit still does not report ready, we issue the comamnd again (and fail if it doesn't succeed). We probably need another quirk PQUIRK_NOSTART and check it in scsipi_start() similar to the PQUIRK_NODOORLOCK in scsipi_prevent().
Re: MNT Reform2 USB LCP flash
Michael van Elst wrote: On Sun, Feb 04, 2024 at 10:37:59AM +0200, Staffan Thomen wrote: [ 214.0188739] umass0: NXP (0x1fc9) LPC1XXX IFLASH (0x000b), rev 2.00/7.04, [ 214.0288745] sd0(umass0:0:0:0): sense debug information: [ 214.0288745] code 0x70 valid 0 [ 214.0288745] seg 0x0 key 0x2 ili 0x0 eom 0x0 fmark 0x0 [ 214.0288745] info: 0x0 0x0 0x0 0x0 followed by 10 extra bytes [ 214.0288745] extra (up to 10 bytes): 0x0 0x0 0x0 0x0 0x30 0x1 0x0 0x0 0x0 0x0 That's what the device answers, but I cannot tell why. Maybe the device is not (yet) in the correct mode to accept USB access. The product code 0x1fc9:0x000b seems to be a LPC11U24, there is an application note AN11305 from NXP for "USB In-System Programming with th LPC11U3X/LPC1U2X", but I didn't find any hints in that document. I found this document and as it seemed from it I could just copy the file in windows, I did this and it still boots so I guess it's updated. While I was fiddling around with it, I booted a FreeBSD-14 thumbdrive and there it does work as well, and their driver helpfully tells you what quirks it uses. This is what I found: umass quirks: 0xc104 0x0004 - NO_START_STOP, "The drive does not support START STOP" 0x0100 - NO_GETMAXLUN, "No GetMaxLun call" 0x4000 - NO_SYNCHRONIZE_CACHE, "Deice cannot handle a SCSI synchronize cache command." 0x8000 - NO_PREVENT_ALLOW, "Device does not support PREVENT/ALLOW MEDIUM REMOVAL" da: quirks: 0x2 0x2 NO_6_BYTE - use SBC (10-byte) commands instead of RBC (6-byte) commands Might something here be the culprit? If so, how do I tell NetBSD to do these things? Is there a umass quirks table somewhere? Staffan
Re: MNT Reform2 USB LCP flash
On Sun, Feb 04, 2024 at 10:37:59AM +0200, Staffan Thomen wrote: > [ 214.0188739] umass0: NXP (0x1fc9) LPC1XXX IFLASH (0x000b), rev 2.00/7.04, > [ 214.0288745] sd0(umass0:0:0:0): sense debug information: > [ 214.0288745] code 0x70 valid 0 > [ 214.0288745] seg 0x0 key 0x2 ili 0x0 eom 0x0 fmark 0x0 > > [ 214.0288745] info: 0x0 0x0 0x0 0x0 followed by 10 extra bytes > [ 214.0288745] extra (up to 10 bytes): 0x0 0x0 0x0 0x0 0x30 0x1 0x0 0x0 > 0x0 0x0 That's what the device answers, but I cannot tell why. Maybe the device is not (yet) in the correct mode to accept USB access. The product code 0x1fc9:0x000b seems to be a LPC11U24, there is an application note AN11305 from NXP for "USB In-System Programming with th LPC11U3X/LPC1U2X", but I didn't find any hints in that document. Greetings, -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: MNT Reform2 USB LCP flash
On 2/4/24 10:12, Michael van Elst wrote: On Sun, Feb 04, 2024 at 09:58:39AM +0200, Staffan Thomén wrote: The man page for scsictl(8) says that SCSIPI_DEBUG is the required option... SCSIPI_DEBUG is it. It should also set the default debug flags (that the ioctl may change). Yep, I just tried it and I got some more info. [ 214.0188739] umass0: NXP (0x1fc9) LPC1XXX IFLASH (0x000b), rev 2.00/7.04, addr 3 [ 214.0188739] umass0: using SCSI over Bulk-Only [ 214.0188739] scsibus0 at umass0: 2 targets, 1 lun per target [ 214.0188739] scsipi_inqmatch: 2/0/1 <, , > [ 214.0188739] sd0 at scsibus0 target 0 lun 0: 1.0> disk removable [ 214.0288745] sd0: fabricating a geometry [ 214.0288745] sd0: 34816, 1 cyl, 64 head, 32 sec, 512 bytes/sect x 68 sectors [ 214.0288745] sd0(umass0:0:0:0): sense debug information: [ 214.0288745] code 0x70 valid 0 [ 214.0288745] seg 0x0 key 0x2 ili 0x0 eom 0x0 fmark 0x0 [ 214.0288745] info: 0x0 0x0 0x0 0x0 followed by 10 extra bytes [ 214.0288745] extra (up to 10 bytes): 0x0 0x0 0x0 0x0 0x30 0x1 0x0 0x0 0x0 0x0 [ 214.0288745] autoconfiguration error: sd0: unable to open device, error = 5 According to this random website I found[1], key 0x2 does indeed mean NOT READY. But since I can't open() the device, how does one go about making it ready? There's a lot of zero "info" bytes, but 0x30 0x1 has the meaning "CANNOT READ MEDIUM - UNKNOWN FORMAT" according to the same random website. Is this perhaps a clue? [1] https://www.stix.id.au/wiki/SCSI_Sense_Data OpenPGP_signature.asc Description: OpenPGP digital signature
Re: MNT Reform2 USB LCP flash
Michael van Elst wrote:
On Sat, Feb 03, 2024 at 09:55:47PM +0200, Staffan Thomén wrote:
Staffan Thomen wrote:
[ 188.679957] sd0: 34816, 1 cyl, 64 head, 32 sec, 512 bytes/sect
x 68 sectors [ 188.689958] autoconfiguration error: sd0: unable
to open device, error = 5
Any thoughts of how to continue debugging this?
A kernel compiled with SCSI_DEBUG can show which commands to the
device actually fail and how. This should be the initial
TEST_UNIT_READY and possibly the START command. No idea why, it's
possible that these are not implemented and errors need to be
ignored.
I built a kernel with options SCSIDEBUG, SCSIVERBOSE and SCSI_DEBUG, and
saw nothing new in the dmesg.
The man page for scsi(4) says that SCSIDEBUG (not SCSI_DEBUG) enables
ioctls for extra printfs, so I wrote this small program to run the
ioctl, but it still fails on the open call with Input/output error (EIO).
I tried /dev/sd0, /dev/sd0d, /dev/rsd0, /dev/rsd0d, /dev/sd0c and
/dev/rsd0c.
For good measure, I tried it on /dev/scsibus0 and that gave me an EFAULT
from ioctl.
I just now noticed that scsictl actually implements this ioctl as well,
but it also errors out with EIO.
The man page for scsictl(8) says that SCSIPI_DEBUG is the required option...
I think I'm more confused than before now. What enables scsi command
debugging?
Staffan
--8<--
#include
#include
#include
#include
#include
#include
#include
int main(int argc, char **argv) {
if (argc < 2) {
printf("Usage: %s \n", getprogname());
return -1;
}
int fd = open(argv[1], O_RDONLY);
if (fd == -1) {
perror("open");
return -1;
}
int result = ioctl(fd, SCIOCDEBUG, 0x15);
if (result == -1)
perror("ioctl");
close(fd);
return 0;
}
Re: MNT Reform2 USB LCP flash
On Sun, Feb 04, 2024 at 09:58:39AM +0200, Staffan Thomén wrote: > > The man page for scsictl(8) says that SCSIPI_DEBUG is the required option... SCSIPI_DEBUG is it. It should also set the default debug flags (that the ioctl may change). Greetings, -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: MNT Reform2 USB LCP flash
Staffan Thomen wrote: [ 188.679957] sd0: 34816, 1 cyl, 64 head, 32 sec, 512 bytes/sect x 68 sectors [ 188.689958] autoconfiguration error: sd0: unable to open device, error = 5 Any thoughts of how to continue debugging this? Staffan
Re: MNT Reform2 USB LCP flash
On Sat, Feb 03, 2024 at 09:55:47PM +0200, Staffan Thomén wrote: > Staffan Thomen wrote: > > [ 188.679957] sd0: 34816, 1 cyl, 64 head, 32 sec, 512 bytes/sect x 68 > > sectors > > [ 188.689958] autoconfiguration error: sd0: unable to open device, > > error = 5 > > Any thoughts of how to continue debugging this? A kernel compiled with SCSI_DEBUG can show which commands to the device actually fail and how. This should be the initial TEST_UNIT_READY and possibly the START command. No idea why, it's possible that these are not implemented and errors need to be ignored. Greetings, -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: MNT Reform2 USB LCP flash
Thanks for the suggestions! I tried to do the modification (just manually since it's two lines) and it does show up as 1 in the dmesg, but no dice. dmesg from my laptop since it was easier, this uhub2 is on an ehci bus: [ 188.679957] umass0 at uhub2 port 2 configuration 1 interface 0 [ 188.679957] umass0: NXP (0x1fc9) LPC1XXX IFLASH (0x000b), rev 2.00/7.04, addr 4 [ 188.679957] umass0: using SCSI over Bulk-Only [ 188.679957] scsibus0 at umass0: 2 targets, 1 lun per target [ 188.679957] sd0 at scsibus0 target 0 lun 0: disk removable [ 188.679957] sd0: fabricating a geometry [ 188.679957] sd0: 34816, 1 cyl, 64 head, 32 sec, 512 bytes/sect x 68 sectors [ 188.689958] autoconfiguration error: sd0: unable to open device, error = 5 roadwarrior# fdisk sd0 fdisk: cannot opendisk /dev/rsd0: Input/output error roadwarrior# disklabel sd0 disklabel: /dev/rsd0: Input/output error roadwarrior# mount -t msdos /dev/sd0d /mnt mount_msdos: /dev/sd0d on /mnt: Input/output error I also tried the start command mlelstv@ suggested, but alas: roadwarrior# scsictl sd0 start scsictl: sd0: Input/output error and for good measure: roadwarrior# scsictl scsibus0 reset scsictl: SCBUSIORESET: Inappropriate ioctl for device roadwarrior# scsictl scsibus0 scan 0 0 roadwarrior# scsictl scsibus0 scan 1 0 (nothing new in dmesg) Staffan OpenPGP_signature.asc Description: OpenPGP digital signature
Re: MNT Reform2 USB LCP flash
> On Jan 26, 2024, at 2:41 AM, Robert Elz wrote: > >Date:Fri, 26 Jan 2024 09:26:38 - (UTC) >From:mlel...@serpens.de (Michael van Elst) >Message-ID: > > | Fortunately the drive geometry isn't really used anywhere. All > | accesses just use the logical block addresses. > > I have been meaning to suggest for ages that we remove all the > geometry nonsense from everywhere in the kernel, except those > drivers that actually need it - those should be responsible for > converting block numbers to CHS in a way that works for thej, > if they really need it (ancient ide drives before LBA addressing, > vax massbus drives, sun xd drives ... anything like that which > almost no-one has seen in decades). > > It is just bizarre to see ssd and even nvme 'drives' claiming > to have cylinders and heads! 10% agree. Alas, FFS's whole schtick is caring about drive geometry, so we kind of need to fake up something for newfs on such drives (and we should do it in a generic way so the code isn’t replicated in a million different places), and have some way of getting the real info for drives where it actually does exist. -- thorpej
Re: MNT Reform2 USB LCP flash
k...@munnari.oz.au (Robert Elz) writes: >I have been meaning to suggest for ages that we remove all the >geometry nonsense from everywhere in the kernel, except those >drivers that actually need it. We use that nonsense without actually knowing. The "cylinder" value is used to sort disk accesses. The "sector" value was used to optimize filesystem allocation. Neither takes the values as is (the values are mostly fake anyway), but as a hint. Newer technologies may not use C/H/S coordinates, but every HDD still uses cylinders and every SSD has a topology based on erase blocks where "cylinder" could be a hint to optimize accesses. So, such information should not be removed but needs to be exposed. Better if it were exposed 1:1 from the underlying technology, but it still needs to be compatible with the abstractions that use it. Doesn't mean that you could not find a better abstraction for a storage medium in the future. For now, pretending everything is a rotational disk from 50 years ago doesn't hurt but helps.
Re: MNT Reform2 USB LCP flash
k...@munnari.oz.au (Robert Elz) writes: >If you are able, try building a kernel with the patch below. >I suspect this should probably apply without too many problems >to any reasonably modern NetBSD kernel version, patch is to >src/sys/dev/scsipi/sd.c >+ if (dp->cyls == 0) /* very small devices */ >+ dp->cyls = 1; /* round up # cyls */ People using the cylinder count assume that a disk is made of cylinders, heads (surfaces) and sectors and that cyls * heads * sectors is the capacity. For modern disks that's not true. The values are intentionally truncated so that such people cannot access blocks beyond the end of the device and software that (still) uses C/H/S coordinates has a chance to use modern devices. An alternative handling would be round up the values so that you can reach all blocks using C/H/S coordinates and non-existent blocks return errors. But what purpose would such fictious C/H/S coordinates serve and would software relying on C/H/S be able to handle the errors ? Rounding up only for disks with less than one full cylinder only helps people that suffer from oudenophobia.
Re: MNT Reform2 USB LCP flash
Date:Fri, 26 Jan 2024 09:26:38 - (UTC) From:mlel...@serpens.de (Michael van Elst) Message-ID: | Fortunately the drive geometry isn't really used anywhere. All | accesses just use the logical block addresses. I have been meaning to suggest for ages that we remove all the geometry nonsense from everywhere in the kernel, except those drivers that actually need it - those should be responsible for converting block numbers to CHS in a way that works for thej, if they really need it (ancient ide drives before LBA addressing, vax massbus drives, sun xd drives ... anything like that which almost no-one has seen in decades). It is just bizarre to see ssd and even nvme 'drives' claiming to have cylinders and heads! kre
Re: MNT Reform2 USB LCP flash
staf...@shangtai.net (=?UTF-8?B?U3RhZmZhbiBUaG9tw6lu?=) writes: >[21.611880] scsibus1 at umass1: 2 targets, 1 lun per target >[21.611880] sd1 at scsibus1 target 0 lun 0: 1.0> disk removable >[21.611880] sd1: fabricating a geometry >[21.611880] sd1: 34816, 0 cyl, 64 head, 32 sec, 512 bytes/sect x 68 >sectors >[21.611880] autoconfiguration error: sd1: unable to open device, >error = 5 >It seems a bit interesting that it reports 2 targets, but only creates >an sd for one, The '2 targets' is a parameter of 'scsibus1', it tells the SCSI layer that it may look for up to 2 targets. USB mass storage usually only has a single 'sd' target, but some also provide an extra 'ses' enclosure target. >and 0 cylinders seems a bit suspicous but I don't know if >that's ok or not. When the drive doesn't return a valid geometry, the driver uses a fake one, based on 64 heads and 32 sectors per head. In your case the drive is smaller than a single cylinder (64*32), so you get zero (full) cylinders. Fortunately the drive geometry isn't really used anywhere. All accesses just use the logical block addresses. The EIO (5) error probably occurs because the drive is reported as 'offline'. This is like a drive with a removable medium but no medium has been loaded. It is possible that there needs to be some action to 'load' the 'medium', or it might just take some time to appear online. You may use scsictl sd1 start to attempt another access. The LPC1xxx manual didn't reveal anything obvious about this problem. It just claims that you can copy the firmware to the storage. It also doesn't say how, with just 68 sectors that's not a fake filesystem, you probably need to write the firmware image to the raw device.
Re: MNT Reform2 USB LCP flash
If you are able, try building a kernel with the patch below. I suspect this should probably apply without too many problems to any reasonably modern NetBSD kernel version, patch is to src/sys/dev/scsipi/sd.c If patch(1) won't just work on your kernel sources, just edit that fike, search for "fabricating" then a few lines under that you'll see where secs & heads are arbitrarily set, then cyls = size/(64*32) ... when size (not the actual var name) is < 64*32 (eg: if it happened to be 68), it is easy to see how cyls gets to be 0. Just test for that, and set cyls = 1 if the division made 0. Not sure yet if that will be a complete solution to the problem, this kind of issue may occur elsewhere, but it should be a start. kre Index: sd.c === RCS file: /cvsroot/src/sys/dev/scsipi/sd.c,v retrieving revision 1.335 diff -u -r1.335 sd.c --- sd.c28 Aug 2022 10:26:37 - 1.335 +++ sd.c26 Jan 2024 08:38:34 - @@ -1769,6 +1769,8 @@ dp->heads = 64; dp->sectors = 32; dp->cyls = dp->disksize / (64 * 32); + if (dp->cyls == 0) /* very small devices */ + dp->cyls = 1; /* round up # cyls */ } dp->rot_rate = 3600;
