It seems to be my unlucky week. Another problem which I don't know if its related with the problem I had a few days ago related to computer names.

Today while working with only one avid, avid 9 MC 2.7, on my unity, MN 5.1.1, all of a sudden I could not open several bins. It came with a OPENDOMAIN error and when pushing the "more" button it says end of file reached in file ......avb. I tried to copy the bin to another workspace and it gave me the error "not enough server space" which was rubbish as there was 21gig free in the other workspace. I feared a unity issue and yes.

At first in the monitor tool and administrator tool all looked fine but in the eventlog of my unity I find in the system log 2 messages The first message is:

Failed to allocate nonpaged pool at line 3780 in module avidcommrw.c.

the second message is:

Requested write operation failed with status = STATUS_INSUFFICIENT_RESOURCES.

These 2 messages appeared about 30 times in the event log. I decided to restart the unity and after the restart and reconnect of the avid all was fine again.... phew.. I had a backup of all projects from yesterday but todays work not yet. I made another backup just now.

After searching in the knowledge base I learned that avidcomm errors are related to the portserver. But did not find anything on this particular one. I will call my ACSR first thing in the morning but hope that some of you are also able to help out. Does anybody know what this exact error means?

I guess it will result in a re-image of my unity but would like to know for sure that it will solve the problem before I do it.

bumb

Hi Jeroen,

Hope you feel better by now!

This bug is referred to internally in Avid as the "WOIO bug" or the "PSP Deadlock" bug. The PortServer process AisPortServer.exe attempted to close a file. As the execution thread proceeded through the code, it acquired a mutual exclusion lock for the Channel Block Cache structure. I'll call this the CBlock Lock. It then continued calling other functions to do its work while holding the CBlock Lock. To hold a lock is to prevent any other thread from acquiring it. Locks are used in this way when it's important that only one thread modify an object at one time. In this case, the object that is being protected by the CBlock Lock is the Channel Block Cache structure. Eventually, this thread needed to acquire another lock - the Node Cache Lock.. Meanwhile, an application running on a remote Windows host was trying to close a file that resided in a Unity workspace. It's interesting to note that this access was made via CIFS, or Windows Network Neighborhood. Our MediaManager Select product will do this, as will Windows Explorer. Anyway, the Windows CIFS service that was running on the PortServer host (same host as the process described above) began to execute the code to close the file. It soon acquired the Node Cache Lock. It continued on until it needed to acquire the CBlock Lock, which was already locked by the AisPortServer.exe thread.. At this point, neither thread could continue. Furthermore, other threads that required these locks halted while waiting for them to be released. Since these locks are essential to basic operation of the Unity file system, no further accesses to Unity could be made on this PortServer. It is likely that one of the threads that was waiting for these locks to be released - possibly the Windows CIFS service thread - also held a more global Windows lock that prevented any mounted volumes from being accessed. This manifested as the searching flashlight icon in My Computer window.. There was an issue discovered in which a Port Server Pro (PSP) could get into a deadlock state. The symptom is that the PSP would become increasingly sluggish and eventually freeze. This condition has only been seen when MediaManager Select clients and Ethernet Attached Clients (EACs) accessing the same PSP. However, there are other scenarios that could cause this situation. Although this condition was only seen on a PSP, it is possible that this could be seen on a LANshare box running EACs as well.   This fix is a change to the avidcomm.sys file. This new avidcomm.sys file is version 3.3.5 15. (check 'File Version' in Properties, file size is 186,740 bytes.) This fix has only been tested with 3.3.4 and should not be attempted on any other release. This fix should not be proactively applied unless you 1.use MediaManager Selects extensively or 2. have PSP that are freezing. Future MediaNetwork releases will have this change embedded and will not require any further action (Not true).   1. Navigate c:\winnt\system32\drivers on your Portserver Pro, and rename it to avidcomm.334. 2. Copy the new avidcomm.sys to c:\winnt\system32\drivers. 3. Reboot the PortServer Pro. NOTE: there is an avidcomm.sys on all Fibre Channel clients, but this fix should only go on the PortServer Pro.

Thanasis

STATUS_INSUFFICIENT_RESOURCES - The status indicates that the amount of memory available to the kernel was insufficient to process the read or write request. Note that the amount of memory available to drivers is limited, even if the server contains a large amount of physical memory. Possible causes for this status are discussed in Microsoft Knowledge Base Article ID 329075.

Thx Thanansis,

I also found these articles in the knowledge base and by google search.

How is the first article related to my Unity 5.1.1?  Is this bug re-introduced in 5.1.1 and if so how come I've been working for months without facing this issue?

The second event log is a consequence of the first error. A resolution could be to remove the /3GB (for unity isn't in a /4GB?) boot.ini patch?

From both errors and the info that comes from the user base it seems that something causes a large amount of network traffic. The portserver reaches some kind of max and fails. That causes file corruption etc... But what is the cause and what is the resolution?

Hi Jeroen,

msvcr80.dll is appearing as the faulty module in the latest Media Engine event logs that I've checked with same disconnect symptoms as your system.

(MSDN Tips for this dll:
msvcr80.dll is a process associated with Microsoft Visual Studio 2005 from Microsoft Corporation. It is the Microsoft C Runtime Library and is used by programs written with Microsoft Visual Studio 2005.
msvcr80.dll is the default for all DLLs that were compiled using the Visual Studio 2005 compiler and linker.

Version mismatches and other errors in the C runtime library commonly cause application failure on Microsoft systems. To counter this problem, Microsoft has enforced the use of manifest in applications. Manifest helps in identifying the exact version of the dependent file required by the application. This has been done by enabling side-by-side existence of multiple versions of the same file without any conflicts. These shared DLL files are copied to the WinSxS folder (side-by-side cache) instead of the default C:\System32 folder.

However, this solution has its own complications. For instance, not all Windows operating systems support side-by side execution. And on those that do support it, the complex installation process opens up many options for errors.)

Please check if you see that module being faulty also on your event viewer logs after Port server Crashes.

Thanasis

Hi Thanasis,

No, I do not see any events in any of the event logs mentioning the msvcr80.dll.

 Jeroen

I'm I really the only one with this error...?

Ok I seem to have found the cause of the problem. But now the solution.

My configuration is as follows: 1x SMC 8824M switch with firmware 2.0.0.3. 3x HP XW8400 with the on board broadcom NetXtreme Gigabit cards, 6x HP XW8200 with the intel pro 1000 MT on board network card. and 1 XW8000 with the intel 82540 gigabit network card. 1 Unity 5 with an intel pro 1000 PM network card (the PL is not used)

 The problem is "flow control" in the ethernet network. all the XW8200's and XW8000 give a IEEE 802.3x flow control status in the smc switch. 1 of the XW8400 needs to be set to TX/RX Pause to get the SMC switch to accept IEE 802.3x flow control... and then switches back again. the other 2 XW8400 also are not consistent. On one of is installed a later driver which does result in correct flow control. 

But the unity5 I can't get into 802.3x flow control whatever I try. This could cause packet losses when network traffic is high and that is a killer for Avid+Unity. Practically I do not find packet loss in the switch logs but I don't trust it.

I tried updating the firmware of the SMC switch to 2.3.0.0. but that causes flow control be to set to off on all ports. I can't change that in the configuration web interface without changing the network duplex speed from 1000full to 100 full or lower...???? So no go....or is it? Went back to the original firmware.

What I have not done is install a newer driver for the intel pro1000 PM network card in the unity as I would be outside of the "avid certified" domain and don't know if it will solve anything.

I checked all documentation and nowhere did I find anything on the flow control settings for clients and server. Should I disable flow control on all clients?

Avid would you be so kind to check what the correct configuration is? I think this is also why the license server crashes and causes the portserver to crash every once in a while....

And what do I find in the manual for ISIS 2.0.4 ???

http://cdn.pinnaclesys.com/SupportFiles/attach/ISIS_ReadMe_v2_0_4.pdf

on page 16,17 and 18???

Well after more research I found that IEEE 802.3x is a flow control protocol for 100mb full. NOT for 1000mb full. So it seems the SMC switch handles this wrong. An update to firmware 2.3.0.0 makes the ports go into none when gigabit is selected. According to a number of networking specialists I contacted this seems to be correct. If a flow control would be enabled it would be IEEE 802.3ah.

But is this the problem? Is firmware 2.3.0.0 in the SMC 8824m switch certified by avid? The documentation supplied with Media networks only mentions the Certification of the SMC 8824m switch but does not mention anything about firmware version.

Can anyone check what the firmware is in their SMC 8824m switch? And also what the flow control status is for each port that has a PC connected to it?

Before I change firmware I would like to have it certified by avid but if that is not possible maybe someone out there has newer firmware in their switch and works fine.

nobody???

Our switches are running 2.2.0.7 of what it calls Operation Code Version.

All ports are running at what I believe is the default: Flow Control to none, Autonegotiation is enabled.

All Mac clients so things may be quite different with HPs.

Thx thx thx thx.....

That info is worth gold for me. Did you also get your switch directly from avid?

if you ever come to Greece I ow you food in the best tavern I know.