Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Lars

Pages: [1] 2 3 ... 55
1
Comments, Suggestions & Questions / Re: Hobbes (Files) Reoganization
« on: June 12, 2021, 03:08:30 pm »
It's not zero or one. You can keep say the last 3 driver versions or so. But it would be helpful to clearly separate the very latest from the rest. The intention is: make a new user take the latest version. Only if that fails, should he delve into it more deeply and try an older version.

Maybe an archive directory with the very same sublayout as the existing main dir would help. Whenever something is superseded by newer stuff, then move the existing stuff to the same subdir in that archive directory.

I myself keep older versions of my USB drivers only for a limited time. But since I properly tagged my source files, I would be able to recreate exactly one specific version (for example, to recreate an error case).

2
Seems that Martin has successfully turned off this ad crap. I l no longer get ads, even with the plain Google browser.
Thanks for that!

3
The QSINIT API allows you to ask for 512 byte sectors of memory. It can only be used by exactly one app at a time and I doubt that there is some protection against multiple users. Also, you will then lose all ability to use it as a RAM disc. The mem cannot be shared between RAM disc and other use. It's all or nothing.

4
I installed AD blocker on my Android phone. Otherwise, the site would become close to unusable.

5
it seems that with the help of GPT.FLT (that can modify the IORBs passed between OS2DASD.DMD and the ADD drivers), you can also address sectors beyond the ABSOLUTE 2TB limit and that OS2AHCI.ADD has some sort of extension to use 48 bits of LBA address. Potentially what I proposed earlier on.

I didn't see your proposal so I wrote my own  :)

There are two new CommandCodes: IOCC_GEOMETRY64 (0x13) and IOCC_EXECUTE_IO64 (0x14). They signal the use of new extended IORBs, GEOMETRY64 and IORB_EXECUTEIO64. The only difference from the 32-bit IORBs is that a 64-bit field has been added at the end of the structures to hold ullTotalSectors and ullRBA, respectively. The .ADD code is unchanged except that it now looks at the CmdCode to decide whether to take the LBA from the 32-bit or 64-bit field.

Current versions of AN's 'os2ahci.add' and 'nvme.add' support this interface. It's use comes at a small cost: for requests above 2TB, GPT.FLT has to create a 64-bit version of each request before it sends it to the .ADD. Each request is less than 100 bytes, so the overhead is minimal.

BTW... IOCC_GEOMETRY64 returns the actual number of sectors on a disk - it isn't rounded down to a cylinder boundary. The call can also be used as a safe way to determine if 48/64-bit support is available.

Quote
What is the reason why OS2DASD.DMD cannot be modified? License issues?

Virtually everything above the .ADD/.FLT level is tied to 32-bit LBAs. There's just too much to change.

Hi Rich,

I am always glad to help. Let me know if you need any :-)

Thanks for letting me know the new command codes. For reasons of large floppy support, I also had to add a new (internal) command code to USBMSD.ADD. Now I can check if that conflicts with the new command codes you mentioned.

6
Under UTILS. An APP is something standalone, serving a main purpose. A util is something that supports the user in interfacing with his computer.
But of course, that will always be arguable.
Yes, it is arguable, and I agree "desktop enhancements" should be under UTILS.
..but if
- XWP and XFolder should be consider WPS Utilities (under /pub/os2/util/wps).
- And there is already a structure for each kind of app.  For example, a WPS Calendar is a wps app (/apps/wps)  but there is also "/apps/calendar" which seems the correct place.
It will make "/pub/os2/apps/wps" empty.

Regards

That goes beyond what you have been asking for.
I would refrain from moving things that already exist at their final place. Someone might have a link on some of that.

7
I guess there cannot be a perfect solution as there will likely be multiple places where that 2TB limit will come into play, also thinking about the disk tools.
But it seems that with the help of GPT.FLT (that can modify the IORBs passed between OS2DASD.DMD and the ADD drivers), you can also address sectors beyond the ABSOLUTE 2TB limit and that OS2AHCI.ADD has some sort of extension to use 48 bits of LBA address. Potentially what I proposed earlier on.
What is the reason why OS2DASD.DMD cannot be modified?
License issues?

8
So that also means none of the real GPT partitions can be bigger than 2TB, correct?
If yes, then the sole intention of that filter is to make accessible GPT partitions and not to provide access to larger partitions, correct?

9
Thinking out loud: a transfer IORB for the ADD contains a 16-bit field "Blocksize". For once, that field is pretty useless as up to present day, OS/2 always expects a value of 512. But even if not, the upper say four bits could be used to extend the LBA address. But that would require to update OS2DASD.DMD accordingly. And of course, the ADD to take advantage of those 4 additional bits.

10

The storage driver provides 48 bit LBA addressing. And the GPT filter driver uses this interface. That way you can access a +2TB disc with ArcaOS.


As I understand it, the GPT filter driver will split a 6 TB drive into 3 units of 2 TB each, allowing you to access a 6 TB drive as, for example, E:, F: and G:. This is different from a single drive letter with 6 TB, which is currently only possible on a network drive.
Ok, that pretty much explains it. The drive letter "logically" extends the 32 bit LBA address, providing additional upper bits for the 48 or 64 bits sent to the device to address a sector. At least, that is a good trick but it uses up valuable drive letters.

11
Under UTILS. An APP is something standalone, serving a main purpose. A util is something that supports the user in interfacing with his computer.
But of course, that will always be arguable.

12
1) you are mixing up two points: there is a filter mechanism to suppress GPT disks (instead of erroneously accessing them) and then, there is 48/64 bit LBA support

2) 48/64 bit LBA support: what that can also mean is that the newer 48/64 LBA commands of the command set are supported, simply because newer drives don't support older 32-bit LBA commands anymore. Still, in reality, only the lower 32-bit will be set, the upper bits would be zero. At least I had to do some such with USBMSD.ADD (that supported only some very old SCSI commands with 21-bit LBA support, I updated to newer commands with 32-bit LBA support, supported by the current generation of USB MSD devices). But David will know for sure.

13
ADDs allow 32-bit LBA addressing. With a 512 byte Sector size, that makes up for 2 TB as Neil correctly stated. And for an ADD, the LBA is an absolute value starting from first sector of the disc (as far as I can remember). Which limits the whole disk to 2TB or am I overlooking something ?
Therefore: a 32-bit IFS can address more space (even if it addresses bytewise) then an ADD. An ADD effectively addresses 32+9= 41 bits. The 32-bit IFS can address up to 63 bits (highest bit is reserved for sign bit to support negative file offsets).
That might also explain why network drives could be bigger than 2TB: you do not need an ADD to access data on a network drive. Instead, the IFS will in some form interact with the remote system to access a byte or more. If the remote system supports bigger drives, then that can work.

Example: the Virtualbox "shared folders" support only needs an IFS (for the OS/2 guest). That IFS directly interacts with the drive support of the host OS (Windows, via some access layer, I don't know the technical details).

14
Applications / Re: theseus 4.001 trap in usbmon
« on: May 25, 2021, 02:31:36 pm »
This discussion is going into the wrong direction.

The real question is: how can Theseus bring down the whole system just by double clicking on one of the processes in the process view ? That should not happen.

We know the trap occurs in Ring 0, in a helper function invoked by Theseus. It happens for some people and it would also happen for me (as much as I can tell from the code around the trapping location) but for some reason the trapping code path is not executed on my system when I double click on USBMON (or any other process).

It would at least be helpful to know what needs to be done to circumvent that trap. A trap in Ring 0 is really a bad thing to happen.

15
Applications / Re: theseus 4.001 trap in usbmon
« on: May 25, 2021, 12:45:55 am »
What do you mean by "it is in OS2.INI" ? I cannot find any mentioning of USBMON.EXE in OS2.INI.

What IS really remarkable is if I remove "USBPRT Auto Monitor" (which is USBMON.EXE) from the Startup Folder, that object is recreated on the next system restart ! Therefore, it seems that USBMON.EXE is and has to be started from the Startup Folder. On my system, it is then started as a detached process (it shows up in the leftmost column in the process view in Theseus).

Dave, what happens, if you then doubleclick on the MTE entry (leftmost number on the line you have pasted) ? Will it display the content correctly or will that also crash Theseus/the system ?

Dave, maybe the object is in the XWorkplace Startup Folder instead of the legacy WPS startup folder ? For me, it is in the legacy WPS startup folder.

Pages: [1] 2 3 ... 55