Emulated amiga locking up with bsdsocket.library enabled.

[DisasterIncarna]

I'm not sure whats happening here, but as my only functional "Amiga" is emulated via FS-UAE or sometimes WinUAE I'm not really sure where to post this issue.

As of today my OS32 install has started acting weird, when my desktop fully boots up, every few seconds my desktop locks up, icons refuse to draw, cant be clicked, (like my cpu is max'd out or something) until a few moments of delay then i can click an icon maybe once or twice for the workbench to lockup again for a few moments and this just repeats, weirdly enough my menu items all function without any lag.

After playing around with many options, this only seems to happen when i have bsdsocket.library enabled.

I thought perhaps i downloaded something nasty (havent downloaded much of anything recently tbh, some Exchange replacement programs from aminet and the new hippoplayer update), so i tried using 2 backups i know are functional and have/had no issues which are on my home NAS, weirdly enough they also now have this same issue and as backups they have had zero program/library/file updates in a month or more.

Just to eliminate another possibility of FS-UAE perhaps going bonkers (cant say it ever has before tbh) i tried my current install and my backup installs with WinUAE, and WinUAE also now periodically freezes up my desktop with bsdsocket.library enabled.

So my problem is now that whenever any of my Workbench installs get access to the internet my system is locking up periodically and functions perfectly fine when internet access is disabled, so my paranoid self has now totally disabled bsdsocket.library until i can figure out wtf is going on here.

Is my system somehow being trainwrecked/attacked from the net? (seems amazingly unlikely) Or is something more normal happening here, see the linked youtube vid, its 2 parts, the start is my desktop working perfectly fine, no lag/lockups/redraw issues (with bsdsocket disabled) and then quitting the emulator, restarting (with bsdsocket enabled) and then it all goes horribly wrong.

Any Clues? Something obvious my brain isnt picking up on?

[ Show youtube player ]

[thomas]

30 seconds to boot an emulated Amiga? That's surely a misconfiguration. I would get mad if any of my configs would need more than 1 second to boot.

On this background it's well imaginable that internet access slows down emulation even more. It's unlikely that you are attacked from the outside because AmigaOS does not have any services running.

Make sure that CPU is set to fastest possible and JIT enabled. Disable cycle-exact.

[DisasterIncarna]

my system does take longer than usual as i have additional entries in my startup that detect cputype/fputype and make numerous changes and assign/add's so that my system will use the correct libraries for say 020/030/040/060/etc starting from my detected cpu down to the lower ones, similar CPUTYPE assigns are added for C: L: DEVS: thsi doesnt take too long but its a slowdown non the less.

I also have a folder called Shares, which has individual entry's for each of my Windows/HomeNAS shares which get listed then executed (Via SMBFS) similar to how the entry for monitors in our startup-sequence gets executed, these mounted shares are all then Makelink'd to a folder in RAM:T/Shares which is "left out" to workbench so all network shares are linked in 1 convenient place.

Now as a final big slowdown, i made a program called RandomWallpaper, which scans all picture files in folders (and their subfolders) you specify via its prefs program and a randomised picture is linked to RAM:T/Workbench.Pic and RAM:T/Window.Pic, the more pictures i have (which is a lot btw) the longer this process and thus my bootup takes, i could probably cache the files, but atm they are scanned every boot/execution of the main program.

Yeah my bootup is slow, but there is good reason for it

as for the slowdown on the desktop, i played around some more and found the issue was not occuring on my Pi400/FS-UAE, so that means it is a windows issue, more specifically a windows issue and network issue. Again tried to narrow down the issue and foudn to my surprise that Avast decided to enable some rando trial mode and enable a firewall feature i didnt ask for, which seems to be the cause of the issue, when i disabled this unwanted feature my emulated desktop is back to normal with bsdsocket.library enabled.

So in the end it was something trivial/dumb which i probably should have thought of first..... a blasted firewall, tho i am a bit confused how a firewall translates into desktop/cpu lag under emulation. Still, its a lesson learned.

[Toni Wilen]

Could you try to get bsdsocket logging with the Avast feature enabled? I'd like to see what is going on because even if any host socket API takes long time to finish, it shouldn't affect emulator performance.

Include "-bsdlog" to winuae command line to enable bsdsocket emulation logging. (winue.exe -log -bsdlog shows logging in real time, use windowed mode). It also creates log file winuaelog.txt.

[DisasterIncarna]

Linked at the bottom is a youtube vid showing the logging process visually and an attached zip file with the logs in question.

As seen in the YT video, at the start just circling the mouse pointer you can see it being interrupted, same for dragging the RAM: window around, it looks fine then jerks/pauses occasionally, later tried downloading a file or 2 and much later using AmigaAMP to stream slayradio audio, where the jerkyness starts interrupting the audio playback.

It's 100% avast firewall related, as for further testing purposes i added full access/no restrictions to FS-UAE and deliberately left WinUAE alone, as both were behaving the same previously, now with the divide between them, FS-UAE is behaving properly and WinUAE is exhibiting the strange behavior/hiccups, so it must be the firewall messing things up.

Hopefully the logs show something useful, if not, just throw more instructions my way, cheers

[ Show youtube player ]

[Toni Wilen]

Lots of activity.. Do you get less log messages with that Avast feature disabled? Another log without it might help to see the difference(s).

[DisasterIncarna]

Ok, after much confusion, as when i repeated the test with the firewall off/dead, i tried again, the log is still replete with those socket messages, and seemingly the same large number, so I had to think (it can happen) why would a firewall visibly/noticably mess with my setup when previously it was fine? FS-UAE and WinUAE are both being affected and it all relates to network access of some kind, plus neither were affected until recently.

So like a moron, i totally forgot my setup collated a number of scripts in my SYS:Shares/Config folder, just like our monitor drivers are collated together into 1 file and executed as a list, i do the same with icons/iconX scripts for my Windows/Home NAS shares.

It's in 3 parts, just above IPrefs in my startup-sequence i have the following, which simply sets up the folders needed in RAM:T, uses makelink to make changes to the Share folder created in RAM: Permanant and the same for the .backdrop file which has the RAM:T/Shares folder left out to desktop, later on SMBFS mounts SMB Shares and makelinks to this Share folder in RAM:T/Shares, so all my SMB shares appear in 1 convenient folder.

; Prepare RAM SMB Shares Folder and Left Out Icon
  Makedir RAM:T/Shares >NIL:
  Makelink RAM:T/Shares.info TO S:Shares.info SOFT >NIL:
  Makelink RAM:.backdrop TO S:Shares.backdrop SOFT >NIL:
  Protect RAM:T/Shares -d QUIET >NIL:
; END SMB Share Icon

then in my WBStartup i have a script which does this, this is basically a copy of whats already in our startup-sequences to execute all our Monitor Drivers in DEVS:Monitors, only its done for my individual SMB Shares.

;BEGIN MOUNT ALL SMB NETWORK SHARES
  MakeDir Ram:T/SMB-Scripts >NIL:
  Copy SYS:Shares/Configs/~(#?.info) RAM:T/SMB-Scripts QUIET >NIL:
  Type RAM:T/SMB-Scripts/#? > RAM:T/SMB-Devices
  Execute RAM:T/SMB-Devices >NIL:
  Delete RAM:T/SMB-Devices QUIET >NIL:
  Delete RAM:T/SMB-Scripts ALL QUIET >NIL:
;END MOUNT SMB SHARES

then there is what the above script executes, which is setting up individual SMB shares via SMBFS and makelinking the created share/device to RAM:T/Shares/<NAME.OF.SMB.DEVICE> such as the following example.

RUN <>NIL: smbfs Workgroup=WORKGROUP User=admin Password=randopassword service=//192.168.1.20/nas-raid DEVICE=NAS3: VOLUME=NAS-MAIN: TRANSLATE=L:FileSystem_TRANS/INTL.crossdos quiet
MakeLink RAM:T/Shares/NAS-Main NAS3: SOFT

This kinda just all works, but now I am at this stage, as the only other "Network" related thing that could be causing issue, i renamed the folder with the SMB configs in them to DISABLED, then rebooted, the multitude of socket messages are now gone, as is the lag/glitch/hiccups.

Confirmed with manually activating each SMB share 1 at a time, i currently have 6, and with all activated the glitching/hiccups occur, which is weird as a month ago when i made a backup, i dont recall this happening and ive used this setup for a good half a year or so without issue, and i have been using the setup to program loads stuff in AmiBlitz3 as well as listening to music/play some games, so i would have noticed issues beforehand if they were there.

Also no idea why FS-UAE isnt glitching (unless avast firewall is on and FS-UAE gets blocked, then it glitched just as hard as WinUAE), or maybe it is and its just not as noticable?

So at a guess, maybe its the SMBFS program at fault here and not the emulator(s)? (but again, this wasnt an issue till recently) Is there anyone else out there using SMBFS and notices any issues? Theres also various other options within SMBFS ive left on defaults, timeout values and other stuff, I'll perhaps try messing with those values and see if anything changes.

Again tho, i must stress i had ZERO issues with WinUAE and FS-UAE until avast updated/slapped on a trial mode and enabled a firewall, and even with me telling avast to disable that firewall until reboot, WinUAE is still currently glitching for me even with firewall exceptions added manually, FS-UAE glitches with the firewall on as well, but works (or maybe just works a bit better?) with firewall exceptions added.

So I'm kinda still stuck, all was well before 1 rogue bit of software ruined my day :| atm, I'm having to settle for disabling my SMB shares for now until i can sort out whatever is going on.

On a happier note, all my UAE emulators on Linux/Pi-400 are working perfectly with the SMB shares still activated.

Other than avast being annoying the only other thing i can think of is that i have had a handful of winblows updates recently, perhaps something there is interfering with the well being of WinUAE and FS-UAE?

[DisasterIncarna]

I have a lot to investigate, just incase my paranoia about winblows updates comes to fruition, my recent updates include a handful of driver updates, 1 of which is my network adaptor, if that even makes a difference here, my "intel - system" driver, an "intel Xeon(R) processor" update, and a few unimportant audio/steelseries updates. then a few normal cumulative updates to also consider/factor in.

Maybe theres an issue in there, maybe not, but im kinda grasping at straws here, that or leaning back into my Linux setups at a push.

[DisasterIncarna]

As its not a UAE issue, this is no big deal, but still closure for my issue, turns out after much, MUCH checking on the reason for my issue, i tracked the problem down to something which is ofc so, so simple.

Basically, my issue ended up being a windows problem, for reasons beyond me, winblows decided to change my user from an online version to an offline user account, this meant when the emulated amiga side of things tried to access windows shares, it was hammering the windows side for samba logins, which no longer matched due to the bizarre change in user account (my online one is passworded, my offline doesnt even have a password).

Took ages, but problem found and solved and FS-UAE/WinUAE are all working perfectly again.