Home | Skip to Content | Skip to Search | Skip to Navigation | Skip to Footer |
Worldwide [change] |Register |About Cisco
Guest

Hierarchical Navigation

NEW    

Field Notice Customer Satisfaction Survey

 

Your feedback is very important to us.  Please take a minute to complete the brief Satisfaction Survey for this Field Notice

 

Cisco WAN Switching Modules

Field Notice: *Expired* FN - 12091 - ASC2 May Not Boot Up Due to PCMCIA Drive Mastership Problems

Revised July 27, 2007

April 22, 2000

NOTICE:

THIS FIELD NOTICE HAS BEEN ARCHIVED AND IS NO LONGER MAINTAINED OR UPDATED BY CISCO.

THIS FIELD NOTICE IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE, WARRANTY OR SUPPORT. USE OF THE INFORMATION ON THIS FIELD NOTICE OR MATERIALS LINKED FROM THIS FIELD NOTICE IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS FIELD NOTICE AT ANY TIME.

Products Affected

Product

Comments

AX-ASC2

In Standby or Active Mode running firmware prior to 4.1.07 or 5.0.12 and all versions of 4.0.

Problem Description

There are two failure modes covered in this Field Notice.

  1. The AXIS Shelf Controller 2 (ASC2) may fail to boot after power up.

  2. The ASC2 may report 4-second timeouts due to the hard drive being busy.

This problem has not been observed on the AX-ASC or the AX-ASC/B.

Background

The two problems discussed in this Field Notice are caused by anomalies in the way the personal computer memory card international association (PCMCIA) hard drive is configured on the ASC2.

  1. When the ASC2 powers up, either by hot insertion or MGX 8220 shelf power-up, the PCMCIA hard drive may be configured to "Slave" mode instead of "Master" mode. In the "Slave" mode, the ASC2 cannot boot up off the PCMCIA hard drive.

    Note:  the PCMCIA must always be "Master" for successful boot up of either the Standby or Active ASC, ASC/B or ASC2.

  2. During normal operation, the online firmware executes reads and writes to the PCMCIA hard drive. If there is no read or write activity on the PCMCIA hard drive for greater than 2 seconds, the read and write head is "auto-idled" or parked. In subsequent read or write activities, the PCMCIA hard drive must remove the auto-idle state by unparking the head and then execute the write activity. If the unparking activity delays for more than 4 seconds, the ASC2 firmware executes a reset on the PCMCIA hard drive.

    Note: In this case, only the PCMCIA hard drive is reset, not the entire ASC2, so user traffic is not affected. In most instances, the reset clears any problems with the disk access delays. However, in some instances, the PCMCIA hard drive may boot up into the "Slave" mode after PCMCIA reset as described in item 1.

Problem Symptoms

The screen captures below are symptomatic of both of the anomalies described in this Field Notice.

AXISNAME.1.4.ASC.a > dspfwrevs 
Cfg Size     Date       Time     File Name    Card Type    Version
 --- -------- ---------- -------- ------------ ------------ ------- 
pcMcia: BlkRead, drive busy over 4 seconds
, before read command 
pcMcia: BlkRead, drive busy over 4 seconds
, before read command  

pcMcia: BlkWrt, drive busy over 4 seconds
, before write command 
pcMcia: BlkWrt, drive busy over 4 seconds
, before write command



AXISNAME.1.4.ASC.a > chkdsk
pcmciaNBsy: drive is still busy
, status reg = 0xff, error reg = 0xff 
hardDriveCmd: No response from hard drive after 0x20 command, status:0xff 
Failed to read from cylinder = 0x1 head = 0x2; sector = 0x1c



AXISNAME.1.4.ASC.a > dspcds
   Slot  CardState    CardType      CardAlarm  Redundancy
   ----  -----------  ------------  ---------  ------------------
   1.1   Standby      BNM-155
   1.2   Active       BNM-155
   1.3   Standby      ASC                      Update In Progress

   1.4   Active       ASC           Minor

Workaround/Solution

Workaround

Continue to reset the affected ASC2 until the problem clears. This workaround is temporary.

Solution

Firmware releases 4.1.07 and 5.0.12 will resolve the slave/master setting. It is recommended that network engineers plan to upgrade ASC2s to either 4.1.07 or 5.0.12 or later releases to take advantage of the fixes in these MGX 8220 releases. The AX-ASC and AX-ASC/B do not exhibit this failure and need not be upgraded for this issue. Both of these releases are available in the Software Center on CCO.

Note: Both 4.1.07 and 5.0.12 have new ASC boot code: the file name is asc_ASC_BT_1.0.03.fw. When upgrading the MGX 8220 firmware to either 4.1.07 or 5.0.12, upgrade the bootcode as well. See the release notes in the Software Center on CCO.

DDTS

To follow the bug ID link below and see detailed bug information, you must be a registered user and you must be logged in.

View CSCdr13321

For More Information

If you require further assistance, or if you have any further questions regarding this field notice, please contact the Cisco Systems Technical Assistance Center (TAC) by one of the following methods:

Receive Email Notification For New Field Notices

Product Alert Tool - Set up a profile to receive email updates about reliability, safety, network security, and end-of-sale issues for the Cisco products you specify.