Re: MNT Reform2 USB LCP flash

2024-01-26 Thread Staffan Thomen

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

2024-01-26 Thread Jason Thorpe


> 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

2024-01-26 Thread Michael van Elst
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

2024-01-26 Thread Michael van Elst
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

2024-01-26 Thread Robert Elz
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

2024-01-26 Thread Michael van Elst
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

2024-01-26 Thread Robert Elz
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;