Advanced Communications Controller B.03.32.03 Release Notes
condition such as a Reset packet after the timeout. To resolve this defect, code change has
been done to check the flowcontrol parameters of the NLI2ZCOM driver. Once the driver
is out of the flowcontrol it sends RR.
• JAGae30469
Symptoms: System panics with Data Page Fault and the stack trace looks as below:
panic+0x14
report_trap_or_int_and_panic+0x84
interrupt+0x1d4
$ihndlr_rtn+0x0
streams_put+0x30
N2Z_F_reset_ind+0x94
N2z_iev_reset_ind+0x128
N2z_ReadEvent_Recvd+0x2278
Defect/Fix: This problem arises due a to race condition between the detaching and resetting
of a pvc. This panic is happening because the Reset and Detach processing of the same PVC
are going on simultaneously. While detaching the PVC, the readq pointer is set to NULL
and when Reset is trying to access that pointer it results in Data Page Fault panic in
N2Z_F_reset_ind function. The fix is to prevent Detach and Reset of a PVC to go
simultaneously. This is achieved by setting a flag Nz_X25_RESET_ACTIVE(lhvcp flag) in
N2z_iev_reset_ind( ) to indicate that a Reset is active and do not start Detaching this PVC,
wait till Reset is over for this PVC.
• JAGae23843
Symptoms: System panics with Data Page Fault and the stack trace looks as below:
panic+0x6c
report_trap_or_int_and_panic+0x94
trap+0xed4 nokgdb+0x8
kfree+0xe4
N2z_shutdown_x25_subsys+0x6ac
N2Z_F0_close+0x708
close_wrapper+0x38
Defect/Fix: This panic was a result of a Race condition between zmasterd shutdown and the
x25subsystem shutdown. In one thread N2z_zcom_shutdown_cleanup() function was
running in which we make l2pda->vctbl== NULL and in another thread
N2z_shutdown_x25_subsys() was going on. When N2z_shutdown_x25_subsys() tries to
access l2pda->vctbl which has been made NULL by N2z_zcom_shutdown_cleanup()it panics.
Fix was to add a check for l2pda->vctbl is NULL or not in N2z_shutdown_x25_subsys().
Also, care has been taken to prevent a race condition.
• JAGae04809
Symptoms: In nli2zcom driver some spinlock issues were found which can result in spinlock
timeout or deadlock panics.
Defect/Fix: In N2z_Cfg_Zlus() routine, it was observed that - in some part of the code there
were chances of the thread going to sleep while holding the spinlock - also one code path,
where the spinlock is supposed to be held, was not holding the lock. Both these cases can
lead to spinlock timeout/deadlock panics or race conditions. To resolve this defect, code
changes have been done to take care of these issues.
Patches and Fixes for this Version 15










