In the following you have a simple example: let’s imagine that there is a counter that controls the
communication between the Jetdirect card and the printer’s firmware. Whenever a new packet of information
is sent by the Jetdirect card to the printer, the counter increases. When the printer receives the packet and
processes it correctly, the counter decreases. Another process checks the counter from time to time to see its
value and take conclusions from it. If the counter is near 0, it means that the printer is processing correctly,
and if it grows too big, it may mean that there is a bottleneck somewhere and maybe the Jetdirect card
throughput is decreased to control its speed to the printer. However, if the access to this counter is not
properly controlled, undesirable effects may happen: in a real environment, a Jetdirect card processes
thousands of information packets per second, so this counter is updated frequently, both by the Jetdirect and
the printer. If at a certain point the Jetdirect and the printer try to access the counter at the same time and
the code is not prepare to handle this, it may happen that the Jetdirect cannot increase the counter because
the printer is writing to it, and what’s worse, that it does not realize this fact. If this happens a few times each
second, it may happen that the counter is decreasing faster than it’s increasing and that at a certain point it
has a negative value. And then, what will the process that is checking this counter do? Most likely, the
process will not be prepared to react to a negative value and will launch an exception that will trigger a 79:04
system error.
Symptoms
This type of 79:04 always occurs in heavy load conditions, so the symptoms will always be similar to this
pattern:
●
A printer that is being heavily used (printing a project or in a reprographics environment) produces
79:04 errors randomly, forcing the user to restart.
●
After restarting, the printer can be used without any issues for an extended period of time, but if the
workload is consistently high, a random error will occur again.
●
The error can never be associated with a specific file. The file that was being printed when the error
occurred the last time can be printed without issues after restart. And a file that has been printed
without issues several times can trigger the error in the future.
●
This error is very dependant of the workflow the customer has. The most common user workflows have
been extensively tested both by HP and by our beta sites, so it is highly unlikely to see random 79:04
issues in these cases. These random issues tend to occur in very specific corner cases, and cannot be
reproduced unless the exact conditions of the workflow are replicated. They normally happen when
sending files generated by external applications (RIPs, 3rd party drivers, etc.)
Solutions and workarounds
Random 79:04 errors are, by far, the most complex ones to diagnose and to fix. The only solutions available
in these cases are:
1. Run the Hard Disk Recovery utility.
2. Identify the root cause (either in the files or in the firmware) and fix it in the code, which requires the
intervention of the GBU.
3. Test any options available to modify the customer’s workflow and see if any combination of them
solves the issue.
In both cases, a profound understanding of the customer’s workflow is necessary. In particular, the
information that is needed is:
●
Front panel settings
●
Application that is being used; RIP or driver that is being used
148 Chapter 3 System error codes ENWW
To Next Page
Loading...
