[Resolved] OS/2 guest on macOS host, sharedfolder usage causes guest system hang

[jvw_dfsee]

Anyone been able to use the sharedfolder feature on an OS/2 guest yet?

I upgraded my VBOX 5.2.30 to 6.0.8 today, on macOS 10.14.5 (Mojave)

I have macOS SIP (System Integrity Protection) switched OFF for other reasons,
so I did not hit the 'unable to upgrade' problems that others have found
running on this macOS release as a host.

So far so good.

Trying the OS/2 additions supplied with VBOX 6.0.8 did not lead to success yet.

Allthough listing and connecting to the shared folder works, actually using the
share with a 'DIR V:' command results in a complete system hang (kernel).

I collected the host-side log, but that did not contain much relevant info I think,
and I did use the '/v' switch on the vboxsf.ifs and '-v' on VboxControl.exe
See the log fragments below and the attachements. The hang is at the 48 second
timestamp in the host logfile (ArcaOS-5.0-guest-macOS-host.log)



Note:
I need to start the VboxService.exe manually, after booting, since
doing that from startup.cmd also gave a solid hang situation ...


One more thing I could do is do the same test with a Windows-10 host,
to rule out a host-specific bug, but that will take some time.


Regards, JvW

++++++++++ VboxService output
13:56:00.285000 main     VBoxService 6.0.8 r130520 (verbosity: 1) os2.x86 (May 13 2019 15:54:05) release log
13:56:00.285000 main     Log opened 2019-06-11T13:56:00.285000000Z
13:56:00.287000 main     OS Product: OS/2
13:56:00.287000 main     OS Release: 1
13:56:00.287000 main     OS Version: 2.45
13:56:00.287000 main     Executable: D:\VBOX\VBOXSERVICE.EXE
13:56:00.287000 main     Process ID: 64
13:56:00.287000 main     Package type: OS2_32BITS_GENERIC
13:56:00.289000 main     6.0.8 r130520 started. Verbose level = 1
13:56:01.000000 timesync time set to 2019-06-11T13:56:01.564000000Z
13:56:01.002000 main     All services started.
13:56:02.139000 automount vbsvcAutomounterMountIt: Successfully mounted 'jvw' on 'V:'
++++++++++

[jvw_dfsee]

FYI,

Since the problem looks a lot like ticket #18376 stating 'Fixed in SVN' I decided to try a later guest release.

(#18376 uses HPFS instead of JFS, 6.04 instead of 6.08, trap-D instead of HANG)

I tested the latest test build (currently 6.0.9 r131183 dated 6th of june 2019)
of the GUEST-additions against the standard 6.0.8 r130520 macOS host.

The problem remains exactly the same, so at least it was not fixed at the guest side of the code ...

Regards, JvW

[bird]

Hi Jan,

finally managed to reproduced the problem. Required a non-W4 kernel. I've reproduced it with the SMP kernel, but I suspect it is also reproducible with the UNI one. The CPU (or one of them if there are several) gets stuck getting _R0SpinLock:

Code: Select all

VBoxDbg> r
eax=0002798a ebx=ffebaed4 ecx=00000007 edx=00000020 esi=02640160 edi=02646d4f
eip=fff11543 esp=0000535c ebp=00005380 iopl=0 nv up ei ng nz ac po cy
cs=0168 ds=0160 es=0160 fs=0000 gs=0000 ss=1530               eflags=00000297
doscalls!spin_4_lock+0x6:
0168:fff11543 3b 05 4c 2e ec ff       cmp eax, dword [0ffec2e4ch]
VBoxDbg> info lis
 Local info segment: 1548:0000 (00000000f9000000 LB 0x2b flags=0x2)
         pidCurrent: 0x0024 (36)
          pidParent: 0x001e (30)
        prtyCurrent: 0x0400 (1024)
         tidCurrent: 0x0020 (32)
          sgCurrent: 0x0012 (18)
       rfProcStatus: 0x10
        fForeground: 0x00 (0)
        typeProcess: 0x03 (3)
     selEnvironment: 0x002c (0000000000050000 LB 0x90d flags=0x2)
         offCmdLine: 0x08fa (2298)
      cbDataSegment: 0x0000 (0)
            cbStack: 0x0000 (0)
             cbHeap: 0x0000 (0)
               hmod: 0x041d
              selDS: 0x0053 (0000000000000000 LB 0x5fffffff flags=0x2)
VBoxDbg> dg 2c
002c DataRW Bas=00050000 Lim=0000090d DPL=3 P  NA       AVL=0 L=0VBoxDbg> db 50000+8fa
%00000000000508fa: 43 3a 5c 4f 53 32 5c 50-4d 53 48 45 4c 4c 2e 45  C:\OS2\PMSHELL.E
%000000000005090a: 58 45 00 00 19 00 00 3b-19 00 18 3b 19 00 30 3b  XE.....;...;..0;
%000000000005091a: 19 00 4c 3b 19 00 64 3b-19 00 7c 3b 19 00 94 3b  ..L;..d;..|;...;
%000000000005092a: 19 00 ac 3b 19 00 c4 3b-19 00 dc 3b 19 00 f4 3b  ...;...;...;...;
%000000000005093a: 19 00 0c 3c 19 00 24 3c-19 00 3c 3c 19 00 54 3c  ...<..$<..<<..T<
%000000000005094a: 19 00 6c 3c 19 00 84 3c-19 00 9c 3c 19 00 b4 3c  ..l<...<...<...<

It appears we're in PMSHELL.EXE. And Just completed a FS_FSINFO request according debug logging

Code: Select all

00:01:13.612458 VMMDev: Guest Log: 00000025 00250008 VbglR0SfConnect: idClient=6                                                        
00:01:13.612502 VMMDev: Guest Log: 00000025 00250008 vboxSfOs2MapFolder: fd675894 - tmp                                                 
00:01:13.612517 VMMDev: Guest Log: 00000025 00250008 vboxSfOs2Attach: Successfully attached 'tmp' to 'Z:'.                              
00:01:13.612531 VMMDev: Guest Log: 00000025 00250008 FS32_ATTACH: returns 0                                                             
00:01:14.010441 VMMDev: Guest Log: 00000024 00240020 FS32_FSINFO: fFlags=0x0 hVpb=0x3ea pbData=02647028 cbData=0x14 uLevel=00000001     
00:01:14.010468 VMMDev: Guest Log: 00000024 00240020 FS32_FSINFO: hVpb=0x3ea -> pVpFsd=fd387557 pVpFsi=fd387597                         
00:01:14.010603 VMMDev: Guest Log: 00000024 00240020 FS32_FSINFO: VbglR0SfHostReqCreate -> 0 Result=3 Handle=0x1                        
00:01:14.010795 VMMDev: Guest Log: 00000024 00240020 FS32_FSINFO: returns 0x0                                                           

However, there isn't too much to work with on the stack:

Code: Select all

VBoxDbg> k
#  EBP      Ret EBP  Ret CS:EIP    Arg0     Arg1     Arg2     Arg3     CS:EIP / Symbol [line]
00 00005380 02646cf4 0168:ffdc1001 000090d0 00000148 02646d4f 02646d10 doscalls!spin_4_lock+6
01 02646cf4 00000000 0168:00000000 00000000 00000000 00000000 00000000 doscalls!RETFDLabel
VBoxDbg> u 0168:ffdc1001
doscalls!RETFDLabel:
0168:ffdc1001 cb                      retf
VBoxDbg> dd 1530:00005380
1530:00005380: 02646cf4 ffdc1001 000090d0 00000148
1530:00005390: 02646d4f 02646d10 02646cf4 000053b0
1530:000053a0: 0000efc0 00000020 00000007 7d00132f
1530:000053b0: 00000000 0000150b 001c0053 98920053
1530:000053c0: 00147349 987a0000 00000202 0000e411
1530:000053d0: 0000ffef 00000000 02646d44 02646d54
VBoxDbg> ln 148:90d0
%00000000ffee00d0 doscalls!fixptr + 000000000000004c

Need some more digging to figure this one out. It's bed time now.

Cheers,
knut.

[bird]

Was too optimistic wrt kernel locking requirements, so change them to non-optimal-but-safe for now till I've got time to figure out how to make it work with more optimal locking.

Uploaded a test build with the workaround: https://www.virtualbox.org/download/tes ... 131257.iso
Should be sufficient to update VBoxSF.IFS.

Cheers, bird.

[jvw_dfsee]

Hi Knut,

Thanks a lot for the quick fix!
This build solves the system hang for me.

It also has correct timestamps on copying files into the shared folder (which was a problem with Valerys fork)

Not all is perfect though, two issues now, with one a show-stopper for real use:

1)
There seems to be a timing issue starting VboxService from startup.cmd, when automounting.
When doing that, the screen shows the service starting, but the drive is not there, and TOP
does not show the service process either, so I guess it aborts/crashes.
Adding a 4 second delay (sleep 4) in startup.cmd solves the issue

Perhaps the IFS is not completely initialized when running startup.cmd ?
(The vboxsf.ifs is the last line in my config.sys, so last IFS started)


2)
On copying files OUT OF the shared folder (using CMD.EXE, COPY command) I often (always ?) get an error message:

SYS0282: The target filesystem can not save extended attributes
0 files copied

A confusing message, since the file does not have any EA's, and the target filesystem is JFS
(but I also tested with FAT12, same error)

Perhaps it refers to the filesystem where the shared folder is located on the host, which is APFS (Apple Filesystem)
allthough I would not expect the guest-addition IFS to be aware of that (should be a Vbox-generic interface, right ?)


2a)
Doing the same file copy using FC/2 always results in a kernel trap-E
Always the same location, with slight variations in the stackpointer etc
(see 2 screenshots in attached ZIP, together with the host log from the session)

Note that copying files INTO the shared folder works without problems sofar,
performce seems OK as well.


Let me know if there is any other info I could provide!


Question:
Is there a debug option for the IFS that makes it log to the host log file (as VMMDev: Guest .....) ?
I am already using 'vboxsf /V' but that does not seem to make much of a difference.

Regards, JvW

[jvw_dfsee]

Hi Knut,

Issue (2) I mentioned might not be a complete showstopper after all:

Using XCOPY instead of COPY works as expected, and also the internal
COPY command that is in 4OS2 seems to work just fine too.

So it is just the CMD.EXE built-in COPY that fails.
(probably using another API/code-path)

Also, deleting files from the shared folder also works fine.

So I can probably work around those issues in my DFSee release procedure for now.

Thanks again, JvW

[jvw_dfsee]

FYI,

The issue as mentioned in the title has been resolved.
A few other issues with CMD.EXE-COPY are fixed too.

At the moment there is one known issue remaining,
wildcard expansion by CMD.EXE COPY/XCOPY results
in various error messages and failure to copy.
(this works fine when using 4OS2 instead)

The fixes should be in the 6.0.9 version of the OS/2 guest additions.

Kudos to BIRD for his quick fixes sofar!

Regards, JvW