The above video goes away if you are a member and logged in, so log in now!
I already mentioned the fact that I'm using linux. Vsub and me are in really two opposite setup. So that's why I suspect the PS2 version may be the cause ?
Originally Posted by Northbear
We both had no problems before to setup our netwok. So even if the issue is not completly related to ops2ld, I'm pretty sure it can be resolved on its side.
Vsub, are you sure of your wireshark captures ?
Cause I also did some ... and on my side I did not get a single packet in case of the freeze !
I stopped all web/network apps to cut down every parasitical traffic, I tried 2 or 3 times ... no packets at all.
So I'm pretty sure it is not due to old connection not closed (and you must agree it will explain your 6 hours delay).
Now I think it is just due to the "timing". When it was working 100%, the network initialization took a lot more seconds ... I gonna try to add some "delay" between each step just to see, tomorrow ...
The second lan card is used for my PS2 only,nothing else have access to it.
I started now wireshark after the app freeze and I didn't get anything on the log.
Actually when it freezes on 1,it shows log couple of lines more and then stop.
I have been having this problem since r145 every time I try and load the network it stops at 1!
r144 works fine every time for me... loading host in Ule before running r145+ and network works but without loading host first it gets stuck at network loading:1 every time on my v9 ps2!
And what type of connection do you have. A direct cross-connect cable or a setup with router/switch ?
Originally Posted by Ishtar
@others in this thread:
I think you guys have been discussing two entirely separate issues here recently, and confusing them with each other.
On the one hand we have fairly high-level operations of Windows file handling routines, which keep track of open files and folders, so as to protest against deletion or renaming that could cause access conflicts. This problem is one I think we can do very little about at its source since that is the Windows OS. So we just have to learn to live with it. And the best way to do that is to handle multiple SMB game paths not by renaming shares on the PC, but by having different shares in parallel on the PC (or PCs), and use a new selection menu in OPNPS2LD to choose between alternate shares and perhaps even between alternate servers (very useful in a multi-PC LAN). And whenever possible we should make sure that the program closes connections to an old server/share before activating another.
On the other hand we have definite low-level interactions of the ethernet driver, with possible repercushions also for the IP protocol drivers, even if no IP packets are sent or received as part of the interactions mentioned.
So far these problems seem specific to people with a direct cross-connect cable, while people with routers/switches seem immune to it. This raises the question of some impropriety within the ethernet drivers of Windows, causing some specific problem if those drivers can directly sense the activation of the PS2 ethernet interface.
With a router or switch that will never happen, since they both present both the PS2 and the PC with an ethernet node that is already active, for so long as the router/switch is turned on. So then PS2 and PC will only interact with each other indirectly, through real IP traffic, but not directly at ethernet level. At that level they will both interact directly only with the router/switch.
Apparently different ways of initializing the PS2 network drivers will interact differently with the drivers at the other end (with direct cable), causing the lock-up to be released and allowing normal function. So perhaps this problem can be resolved by changing the network driver initialization of OPNPS2LD so as to be more like that of uLE, or even to add in an extra initialization stage and an extra IOP reset, just to simulate the effect of a previous network init by uLE, since that seems to have helped in most cases.
Best regards: dlanor
Like I said before, I've been having the same symptom with my setup. I have tested Ops2L rev175 with two consoles (50001/Genuine Matrix 1.93 and 75001/fake Matrix "2.0") using a crossover cable with a second lan card, only for my PS2s. My OS is Windows XP SP3.
On my V10 (50001) with internal HDD when I configure "Use Hard Drive ON" in Ops2L the connection works fine. The same occurs if I first start Ule's host. In any of this situations, the network always works.
If I use Ops2L 0.6 oficial release I do not need to start Ule's host, the connection works well. Of course I have to disable modchip and to use FMCB.
I think we can be seeing this since r145 since then the main thread initializes the network. What that means is under some circumstances the smbman can try communicating through smap without some delay (thus through not completely initialized smap). The delay was there before as a side effect of the secondary thread usage, which was lower priority.
I propose a test - Somebody with this problem, please try this:
right before the line
in src/main.c (Function LoadNetworkModules).
id=SifExecModuleBuffer(&smbman_irx, size_smbman_irx, 0, NULL, &ret);
I have tried direct with just a crossover cable, with a router and just a switch to a pc running xp pro sp3 and also with a seagate blackarmor 220 nas I have the same issue with any mix of them every time I tried! if I load host in Ule first then it works fine every time!
Originally Posted by dlanor
I want to try this but I can't compile OPS2L(I don't know how and what to download)
Originally Posted by volca
on its own that didn't help I tried higher 10 20 50 no change then I added delay(5); to all the module loads above it and that solved my problem I will test more later I don't have time now...
Originally Posted by volca