2023-06-05 21:42 CEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0006002WHDLoad[All Projects] Generalpublic2023-03-12 16:08
ReporterMBry0 
Assigned ToWeplProject InfoHD-Installer for OS-Killer
http://whdload.de/
 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionno change required 
Product Version18.8 
Target VersionFixed in Version 
Summary0006002: Very long loading times with network connected
DescriptionLately I'm using roadshow, enabled at startup.
I've resolved the crash/freeze/recoverable alerts problems using 0004091 advices.
Now it work fine, no crash or freeze, but very long loading times, and for long I mean something like 2 minutes and more, then whdload splash screen comes up and everything works as expected, no crash during the game, no crash on exit.

During loading time, I can browse the net without problems, everything works as expected. The connection stops as soon as the whdload splash screen comes up.
Steps To ReproduceMaybe configuring whdload.prefs, WHDLoad-Cleanup and WHDLoad-Startup as Paul Head did in the 0004091 (except for the wireless part, i'm using an ethernet card).
Additional InformationAmiga 1200 with blizzard 1260+scsi module, ateobus bridgeboard, rtg pixel64 with 2mb ram, nic ateonet. Rom 3.2.1, Wb 3.2.1.

The very same issue occurs on my friend's Amiga 3000 with network card.
TagsNo tags attached.
MachineA1200
CPU68060
CPUSpeed66
ChipSetAGA
GFXCardOther
ChipMem2 MB
FastMem96 (32+64, blizzard+scsi kit)
WorkbenchOS 3.2
KickROM47 - Kick 3.2
KickSoftNone
WHDLoad18.7
Attached Files
  • ? file icon .whdl_trace (5,536 bytes) 2023-01-16 21:48 -
    [16-Jan-23 21:42:32.66 6478] started 1000Miglia.slave 18.8.6478 *****************************
    [16-Jan-23 21:42:32.66 6478] eaf=80FF waf=FF vbr=6612C228 cacr=A0808000 tc=8008 pcr=4300101 bplcon0=200 chiprev=1F
    [16-Jan-23 21:42:32.66 6478] mem delta 93128096
    [16-Jan-23 21:42:32.68 6478] name=                    attr=5 lower=66000020 upper=6BF80000 free= 91147952
    [16-Jan-23 21:42:32.68 6478] name=        chip memory attr=703 lower=    4020 upper=  200000 free=  1980144
    [16-Jan-23 21:42:32.70 6478] performing Slave Update Check for '1000Miglia.slave', Stack='Roadshow 4.347 (29.11.2019)'
    [16-Jan-23 21:42:32.78 6478] connecting to host 'cgi.whdload.net' ip=$5CCD365B port=80
    [16-Jan-23 21:43:47.56 6478] Couldn't connect to remote host: Operation timed out
    [16-Jan-23 21:43:47.58 6478] restart point
    [16-Jan-23 21:43:47.58 6478] int: tbe     d=0 c=0 n=0
    [16-Jan-23 21:43:47.58 6478] int: dskblk  d=66005374 c=FC507A n=660053C2
    [16-Jan-23 21:43:47.58 6478] int: dskblk  t=0 p=0 n=disk.resource d=66005374 c=FC507A
    [16-Jan-23 21:43:47.58 6478] int: softint d=0 c=F8197C n=0
    [16-Jan-23 21:43:47.58 6478] int: ports   d=4020 c=F818FC n=0
    [16-Jan-23 21:43:47.58 6478] int: ports   t=2 p=127 n=card.resource d=6600A690 c=FC109A
    [16-Jan-23 21:43:47.58 6478] int: ports   t=2 p=120 n=ciaa.resource d=66005060 c=FC44D2
    [16-Jan-23 21:43:47.58 6478] int: ports   t=2 p=115 n=ateobus.interrupt d=66199000 c=6619CC30
    [16-Jan-23 21:43:47.60 6478] int: ports   t=2 p=110 n=1230scsi.device d=6601D944 c=66001F44
    [16-Jan-23 21:43:47.60 6478] int: ports   t=2 p=20 n=scsi.device d=66123FE0 c=6611CD38
    [16-Jan-23 21:43:47.60 6478] int: coper   d=4040 c=F818FC n=0
    [16-Jan-23 21:43:47.60 6478] int: vertb   d=4030 c=F818FC n=0
    [16-Jan-23 21:43:47.60 6478] int: vertb   t=0 p=10 n=graphics.library d=660058B8 c=661E4B64
    [16-Jan-23 21:43:47.60 6478] int: vertb   t=2 p=0 n=gameport.device d=6600A304 c=FC9A90
    [16-Jan-23 21:43:47.60 6478] int: vertb   t=2 p=0 n=timer.device d=6600A49C c=FC6F1E
    [16-Jan-23 21:43:47.60 6478] int: blit    d=660058B8 c=F9484E n=6600592E
    [16-Jan-23 21:43:47.60 6478] int: blit    t=0 p=0 n=graphics.library d=660058B8 c=F9484E
    [16-Jan-23 21:43:47.62 6478] int: aud0    d=0 c=0 n=0
    [16-Jan-23 21:43:47.62 6478] int: aud1    d=0 c=0 n=0
    [16-Jan-23 21:43:47.62 6478] int: aud2    d=0 c=0 n=0
    [16-Jan-23 21:43:47.62 6478] int: aud3    d=0 c=0 n=0
    [16-Jan-23 21:43:47.62 6478] int: rbf     d=0 c=0 n=0
    [16-Jan-23 21:43:47.62 6478] int: dsksync d=66005374 c=FC5090 n=660053D8
    [16-Jan-23 21:43:47.62 6478] int: dsksync t=0 p=0 n=disk.resource d=66005374 c=FC5090
    [16-Jan-23 21:43:47.62 6478] int: exter   d=4050 c=F818FC n=0
    [16-Jan-23 21:43:47.62 6478] int: exter   t=2 p=120 n=ciab.resource d=66005100 c=FC4578
    [16-Jan-23 21:43:47.62 6478] int: exter   t=2 p=-127 n=card.resource d=6600A690 c=FC0F80
    [16-Jan-23 21:43:47.64 6478] int: inten   d=0 c=0 n=0
    [16-Jan-23 21:43:47.64 6478] int: nmi     d=4060 c=F818FC n=0
    [16-Jan-23 21:43:47.64 6478] basesz=80000 abssz=65200 lo=1AE00@66763C48 hi=0@0 free=17E1C0
    [16-Jan-23 21:43:47.72 6478] data0: Games_Demos:Games/0/1000Miglia vdt=PFS\1 dd=DH1,scsi.device/0 ed=scsi.device IDE-fix 119.16 (03.06.99) mxt=1FE00 msk=7FFFFFFE fs=Professional-File-System-III 19.2 PFS3AIO-VERSION (2.10.201 ddt=PDS\3
    [16-Jan-23 21:43:47.72 6478] mem delta -576560
    [16-Jan-23 21:43:47.72 6478] name=                    attr=5 lower=66000020 upper=6BF80000 free= 90986320
    [16-Jan-23 21:43:47.72 6478] name=        chip memory attr=703 lower=    4020 upper=  200000 free=  1565216
    [16-Jan-23 21:43:47.74 6478] filecache start maxmem=90833424
    [16-Jan-23 21:43:47.74 6478] using mempool puddle=5677089 tresh=1419272 at=$666EF7E8
    [16-Jan-23 21:43:47.74 6478] s=1396 n=ReadMe.info
    [16-Jan-23 21:43:47.74 6478] s=5060 n=ReadMe
    [16-Jan-23 21:43:47.76 6478] s=29608 n=igame.iff
    [16-Jan-23 21:43:48.14 6478] s=901120 n=Disk.1
    [16-Jan-23 21:43:48.16 6478] s=1620 n=1000Miglia.Slave
    [16-Jan-23 21:43:48.16 6478] s=239 n=1000Miglia.info
    [16-Jan-23 21:43:48.16 6478] s=116 n=1000miglia.save
    [16-Jan-23 21:43:48.16 6478] files=7 min=116 max=901120 avg=134165 sum=939159 exall=1 pudcnt=1 time=0.42
    [16-Jan-23 21:43:48.16 6478] mem delta -5678200
    [16-Jan-23 21:43:48.16 6478] name=                    attr=5 lower=66000020 upper=6BF80000 free= 85308120
    [16-Jan-23 21:43:48.16 6478] name=        chip memory attr=703 lower=    4020 upper=  200000 free=  1565216
    [16-Jan-23 21:43:55.76 6478] no CDTV detected
    [16-Jan-23 21:43:56.20 6478] found p96: n=Pixel64 v=VBInt Pixel64 (0) f=4081E3 i=66209822
    [16-Jan-23 21:43:56.22 6478] mem delta -10464
    [16-Jan-23 21:43:56.22 6478] name=                    attr=5 lower=66000020 upper=6BF80000 free= 85305456
    [16-Jan-23 21:43:56.22 6478] name=        chip memory attr=703 lower=    4020 upper=  200000 free=  1557416
    [16-Jan-23 21:43:56.22 6478] resload start
    [16-Jan-23 21:43:56.28 6478] resload end
    [16-Jan-23 21:43:56.30 6478] restoring p96
    [16-Jan-23 21:43:56.32 6478] no CDTV detected
    [16-Jan-23 21:44:29.00 6478] clock restored
    [16-Jan-23 21:44:29.00 6478] dircache clearing
    [16-Jan-23 21:44:29.00 6478] filecache clearing
    [16-Jan-23 21:44:29.00 6478] caches cleared
    [16-Jan-23 21:44:29.00 6478] check restart
    [16-Jan-23 21:44:29.02 6478] exit
    [16-Jan-23 21:44:29.04 6478] mem delta 6250232
    [16-Jan-23 21:44:29.04 6478] name=                    attr=5 lower=66000020 upper=6BF80000 free= 91132960
    [16-Jan-23 21:44:29.04 6478] name=        chip memory attr=703 lower=    4020 upper=  200000 free=  1980144
    ? file icon .whdl_trace (5,536 bytes) 2023-01-16 21:48 +

-Relationships
+Relationships

-Notes

note ~0012299

Paul Head (reporter)

To help Wepl, how are you loading the game?
Are you clicking on the game icon from Workbench or are you using a game launcher?
Is the delay with all games?
Whilst the delay is ongoing is there any hard drive activity on that drive (Drive LED or SnoopDOS)?
I'll be honest though it does sound like it's to do with the network checking of slave updates. From memory, I turned off that feature because I had a problem with it loading my web browser after there was little memory left (because of preload) and hence my machine was starved of ram and it was pointless trying to browse the slave update page etc...So it's 'NoNetwork' for me in my WHDLoad.prefs file.

note ~0012302

MBry0 (reporter)

I'm using latest igame, but there's no differences between loading through the frontend or directly from the slave.

The delay is the same with every game (i tried at least 20). In very rare occasions everything works as expected, but only after a cold boot.

No drive activity.

I have 96mb of fast ram, so the memory quantity surely is not the problem here.
While the game is "loading" i can browse the net or exchange files with my pc through FTP, so I think that the network is working properly.

Thanks Paul.

note ~0012308

Paul Head (reporter)

Been a while since I read that old 0004091 issue. I think Wepl was correct, PoolMem with Roadshow issue. I don't go on that Amiga very much now, but I am kind of intrigued myself as to whether that fault still exists or not without the Wait command (with new WHDLoad versions and Roadshow etc). I'll revisit it one of these days and add another post if it's fixed.

Anyway, onto your issue again...have you tried the NoNetwork option which turns off the slave update check?

I remember now the reason I use NoNetwork was because of Chip RAM starvation (consumed by heftier slaves (AGA for example) and then IBrowse was loaded...not a great combo). This may seem a childish question, but you do have plenty of free Chip RAM right? When this '2 min delay' is occurring, do you have plenty of free Chip RAM (graphics memory in Workbench). I say this because your RTG browsing doesn't need Chip RAM, but WHDLoad certainly does.

Also, you say crash/freeze/alert problems in your original report. What was causing this issue and how did you solve it? Do you use either Roadshow or PoolMem like me, or both?

note ~0012309

MBry0 (reporter)

Nonetwork works as it should, no problems at all. Instant loading after whdload info window.

The os uses very little chip ram (there's 2.009.296 graphics mem free after wb loading), and it goes down to 1.993.776 in the "loading" part, then it takes what needed to launch the game.

I do not use poolmem.

It's hard for me and my little knowledge to give the dev some detailed report, so I'm giving up. Of course it's not a problem running whdload without the version check at start, but I'm very curious on the origin of the problem...

Anyway, thanks for your kind support.

note ~0012312

Wepl (manager)

The delay is probably caused by WHDLoad waiting for an answer to his network access. Maybe it cannot resolve the address or there is another problem with your network setup.
You can use option TRACE for further diagnostics. WHDLoad will then write a file called .whdl_trace. Look into this to see if there is a network error reported.

note ~0012317

Paul Head (reporter)

This must be a new feature then as it had previously escaped my attention!
I have tried it out and it doesn't appear to create the trace file unless I specify a CoreDumps path.

@MBry0
You're very welcome! Now fire up your Amiga and use this TRACE option.
It's easy, just select a game which has the long delay going (any game I believe), select the game icon once with left mouse click and go into the Icon Information in the Icons Menu in Workbench...what we'll do here is just add a ToolType called TRACE. Once entered, select save and load the game up with a double-click. Wait for the game to appear and then quit it and examine the file created which is stored in your "CoreDumpsPath=...." (editable in S:WHDLoad.prefs). The trace file is called ".whdl_trace". I just tried it out here and it works fine. It's only a few KB in size so easy to upload here. Well, when you have a spare few minutes of course ;-)

note ~0012318

Paul Head (reporter)

When I say "wait for the game to appear" I do mean the actual game, and not the Splash Window. I just thought I'd mention that.

note ~0012319

MBry0 (reporter)

There you go. It seems that it "couldn't connect to remote host". But as I said, the network is fully functional while the game is "loading". I tried to browse the whdload.de while loading, and everything works as expected.

note ~0012320

MBry0 (reporter)

Log attached.

note ~0012326

Wepl (manager)

Try if you can open http://cgi.whdload.net/suc.cgi in your browser. That is what WHDLoad tries to load.

note ~0012449

Afebriwyn (reporter)

Hello,
I have the same problem:
A500 / ACA 500+ / ACA1234 / X-Surf500 (AmiTCP).

In fact, even the first call of the update URL via a browser leads to time-out, but a reload of the URL then works.
At the same time, however, a ping to the host is possible, i.e. name resolution and route are correct.
I do not have an explanation for this behavior...

note ~0012475

Wepl (manager)

Last edited: 2023-03-09 21:52

View 2 revisions

There is a problem since the website has moved to a new server in Dec 2022.
Since then the webserver does not support http-connections with a remote port of 1024. These connections will timeout. A subsequent connection using port 1025 then works. If you start WHDLoad, as the first application opening a tcp connection, the tcpip-stack usually uses the first non reserved port which is 1024. Then WHDLoad will hang because of this tcp-timeout.
I'm in the process to relocate the website to another datacenter without this problem, as the current webhoster seems to be unable to fix this problem.
In the meantime you may try to start anything, which opens a tcp-connection, prior to start WHDLoad, to avoid the problem.

note ~0012498

Wepl (manager)

The website has been moved to different datacenter. This problem doesn't appears anymore.
+Notes

-Issue History
Date Modified Username Field Change
2023-01-10 10:05 MBry0 New Issue
2023-01-12 13:52 Paul Head Note Added: 0012299
2023-01-12 17:39 MBry0 Note Added: 0012302
2023-01-13 12:53 Paul Head Note Added: 0012308
2023-01-13 17:10 MBry0 Note Added: 0012309
2023-01-14 16:00 administrator Assigned To => administrator
2023-01-14 16:00 administrator Status new => assigned
2023-01-14 16:00 Wepl Assigned To administrator => Wepl
2023-01-14 19:16 Wepl Note Added: 0012312
2023-01-16 20:08 Paul Head Note Added: 0012317
2023-01-16 20:09 Paul Head Note Added: 0012318
2023-01-16 21:48 MBry0 File Added: .whdl_trace
2023-01-16 21:48 MBry0 Note Added: 0012319
2023-01-16 21:48 MBry0 Note Added: 0012320
2023-01-18 17:57 Wepl Note Added: 0012326
2023-02-13 11:17 Afebriwyn Note Added: 0012449
2023-02-23 23:07 Wepl Description Updated View Revisions
2023-02-23 23:11 Wepl Steps to Reproduce Updated View Revisions
2023-03-09 21:50 Wepl Note Added: 0012475
2023-03-09 21:52 Wepl Note Edited: 0012475 View Revisions
2023-03-12 16:08 Wepl Note Added: 0012498
2023-03-12 16:08 Wepl Status assigned => resolved
2023-03-12 16:08 Wepl Resolution open => no change required
+Issue History