MSL5060 Drive firmware update 도중 fail 발생

[정성호]

MSL5060의 firmware 를 update 하는 도중 fail이 발생을 하였습니다.

일단 libray firmware 는 4.30 으로 성공을 하였는데..그후 4개의 Drive는 fail 이 발생 하였습니다.

답변 주시면 감사하겠습니다.

Model : MSL5060

Drive : Ultrium 230

HP O/S : 11.0



You can update firmware on these devices. Type the corresponding number to select/clear, then type 'start'.

See the command list for additional help.



Device Current Rev New Rev Status

------ ----------- ------- ------

1 Library (MSL5000 Series) 0430 not selected

2 Drive 1 (Ultrium 1-SCSI) E30W E38W pending

3

4 +- Informational: hp L&TT - Firmware Update -----------------------------------------------------+

5 | |

| Firmware update failed |

| |

| |

| |

| Exception: Application Exception 1020 (Logical Device: non-fatal I/O failure, function will |

| continue) |

| |

| |

| |

| Exception: I/O Exception (Error: 2133 - I/O: Command Incomplete) |

| |

| |

+- Press any key to continue --------------------------------------------------------------------+





======================================================================

=========== Syslog =================================================

======================================================================



Mar 23 16:48:59 vmunix: SCSI: isrEscape Controller at 0/2/0/0.

Mar 23 16:48:59 vmunix:

Mar 23 16:48:59 vmunix: SCSI: First party detected bus hang (HTH) -- lbolt: 534634084, dev:

cb051000

Mar 23 16:48:59 vmunix: lbp->state: 30008

Mar 23 16:48:59 vmunix: lbp->offset: ffffffff

Mar 23 16:48:59 vmunix: lbp->nominalOffset: 270

Mar 23 16:48:59 vmunix: lbp->Cmdindex: 9

Mar 23 16:48:59 vmunix: lbp->last_nexus_index: 27

Mar 23 16:48:59 vmunix: lbp->nexus_index: 28

Mar 23 16:48:59 vmunix: uCmdSent: 900da40 uNexus_offset: 2d6a0

Mar 23 16:48:59 vmunix: last lbp->puStatus :

Mar 23 16:48:59 vmunix: 00031100 00031100 00031100 00031100

Mar 23 16:48:59 vmunix: next lbp->puStatus :

Mar 23 16:48:59 vmunix: From most recent interrupt:

Mar 23 16:48:59 vmunix: ISTAT: 0a, SIST0: 40, SIST1: 01, DSTAT: 80, DSPS: 00

000000

Mar 23 16:48:59 vmunix: lsp: 0x0000000056001700

Mar 23 16:48:59 vmunix: 00031100 00031100 00031100 00031100

Mar 23 16:48:59 vmunix: bp->b_dev: cb051000

Mar 23 16:48:59 vmunix: scb->io_id: 5d80008

Mar 23 16:48:59 vmunix: scb->cdb: 3b 05 01 00 00 00 00 00 00 00

Mar 23 16:48:59 vmunix: lbolt_at_timeout: 534693860, lbolt_at_start: 5346338

60

Mar 23 16:48:59 vmunix: lsp->state: 4205

Mar 23 16:48:59 vmunix: Jump Table entry : 00001100 85ffc288

Mar 23 16:48:59 vmunix: DSAtbl->host_iocb_index: 9

Mar 23 16:48:59 vmunix: DSAtbl->host_iocb_addr: 2da40

Mar 23 16:48:59 vmunix: stored scratcha: 0x31100

Mar 23 16:48:59 vmunix: scratch_lsp: 0x0000000056001700

Mar 23 16:48:59 vmunix: c8xx_iocb :

Mar 23 16:48:59 vmunix: 0900da40 00001100 85ffc288 bf010f00

Mar 23 16:48:59 vmunix: 00000001 0002da20 0000000a 0002da28

Mar 23 16:48:59 vmunix: Pre-DSP script dump :

Mar 23 16:48:59 vmunix: 1a000000 00000018 e27c0004 00028700

Mar 23 16:48:59 vmunix: e2600004 0002da3c 7c36fb00 00000000

Mar 23 16:48:59 vmunix: Script dump :

Mar 23 16:48:59 vmunix: 898b0000 000001e8 888b0000 000001e0

Mar 23 16:48:59 vmunix: 828a0000 ffffffc8 83830000 00000268

Mar 23 16:48:59 vmunix: NCR chip register dump for: 0x400200a

Mar 23 16:48:59 vmunix: 00: SCNTL3: bf SCNTL2: 80 SCNTL1: 10 SCNTL0

: da

Mar 23 16:48:59 vmunix: 04: GPREG: 0a SDID: 01 SXFER: 0f SCID:47

Mar 23 16:48:59 vmunix: 08: SBCL: 22 SSID: 80 SOCL: 02 SFBR:00

Mar 23 16:48:59 vmunix: 0c: SSTAT2: 00 SSTAT1: 0a SSTAT0: 01 DSTAT80

Mar 23 16:48:59 vmunix: 10: DSA: 85ffcb00

Mar 23 16:48:59 vmunix: 14: MBOX1: 00 MBOX0: 00 ISTAT1: 00 ISTAT08

Mar 23 16:48:59 vmunix: 1c: TEMP: 85ffcaa0

Mar 23 16:48:59 vmunix: 24: DCMDDBC: 898b0000

Mar 23 16:48:59 vmunix: 28: DNAD: 85ffc270

Mar 23 16:48:59 vmunix: 2c: DSP: 85ffc278

Mar 23 16:48:59 vmunix: 30: DSPS: 000001e8

Mar 23 16:48:59 vmunix: 34: SCRATCHA: 00031100

Mar 23 16:48:59 vmunix: 38: DCNTL: a1 DWT: 00 DIEN: 7f DMODE4c

Mar 23 16:48:59 vmunix: 3c: ADDER: 85ffc460

Mar 23 16:48:59 vmunix: 40: SIST1: 00 SIST0: 00 SIEN1: 97 SIEN08f

Mar 23 16:48:59 vmunix: 44: GPCNTL: 2f MACNTL: 00 SWIDE: 00 SLPAR00

Mar 23 16:48:59 vmunix: 48: RESPID1: 00 RESPID0: 80 STIME1: 00 STIME0

[PS LEE]

Robotic Controller와 연결되어 있는 서버에서 hp_ltt를 사용하여 f/w업데이트를 실행하신것으로 보이는데요.



제 생각에는 4개의 드라이브가 모두 fail 난 것으로 보아,

Library 자체 구성이 어떻게 돼있는지 궁금하네요.

- 드라이브는 다른 서버와 연결되어 있는게 아닌지?

- NSR의 연결은 Manual 대로 정확히 되어 있는지?

등을 확인하셔야 할 듯 합니다.

사실 update 실패할 경우에도 사용하는 데는 문제가 없었습니다.

[정성호]

답변을 주셔서 감사합니다.



libray 의 Drive 와 server의 Ultra160 SCSI 4개와 각각 연결되어 있습니다. 케이블 연결은 정상적으로 되어 있습니다.

library 의 백업 도중 media 가 full 이 났을 경우 media 를 교체하여 백업을 하지않고 백업이 도중에 fail 이 발생합니다.

따라서 Drive firmware 를 update 해보려 합니다.

일반 inr backup은 정상적으로 돌아가지만 full backup(160GB) 정도의 백업이 두번 정도 돌아가면 fail이 발생을 합니다.

[PS LEE]

(1) libray 의 Drive 와 server의 Ultra160 SCSI 4개와 각각 연결되어 있습니다

=> 서버와 Library가 FC가 아닌 SCSI로 연결돼있다는 의미인가요? LTT를 실행하는 서버에서는 controller와 해당 드라이브가 물리적으로 연결되어 있어야 합니다.(ioscan시 드라이브가 보여야 합니다) 만약 드라이브는 다른 서버와 연결되어 있다면 업그레이드는 할 수 없을 것 같습니다.(LTT에서 보이긴 합니다)



(2)library 의 백업 도중 media 가 full 이 났을 경우 media 를 교체하여 백업을 하지않고 백업이 도중에 fail 이 발생합니다.

=> 이 경우는 물론 버전이 오래되긴 했지만 E30 f/w의 문제일 가능성은 낮아 보입니다. 위의 H/W구성 상태 및 백업소프트웨어 구성과 연관되는 문제일 수 있습니다. 160GB가 두번 돌아간다고 하면 320GB 라고 가정했을 때 테잎이 하나가 넘어가는 상황이므로 Robotic Controller가 change 해주는 역할을 해주어야 하는데 이것에 문제가 있는 것이 아닐까요?

그 상황에서 드라이브 역할은 loading/unloading 인데, 이것은 OS에서도 mc 명령어로 간단히 확인하실 수 있습니다.



# ioscan -fnkC autoch (Robotic Controller의 device file을 확인)

device file이 /dev/rac/c7t0d0 라고 할 때

# mc -p /dev/rac/c7t0d0 -r DS (Library inventory 상태 확인)

Slot1의 Tape을 Drive1에 loading 테스트

# mc -p /dev/rac/c7t0d0 -s S1 -d D1

Drive1에서 unload 후 Drive2에 loading 테스트

# mc -p /dev/rac/c7t0d0 -s D1 -d D2

Drive2의 Tape을 원래 Slot1으로 move

# mc -p /dev/rac/c7t0d0 -s D2 -d S1



어플리케이션 레벨 이전에, 이런 기본 동작이 제대로 수행되는지 점검하시는게 우선이라고 생각됩니다.

[이태곤]

서버가 어떤것인지는모르겠지만 11.0을 사용하는것으로 봐 n4000(rp7400)이나 L2000 쯤 이라 생각됩니다.

이모델들은 기본적으로 Ultra-2 기반모델들입니다. Ultra-3(Ultra160)가 처음 나왔을때 system firmware나 patch 작업을 진행하지 않으면 문제가 발생했습니다.

또 MSL5030이나 MSL5060을 FC로 사용했을때는 문제가 되지 않았는데 SCSI로 연결했을때 TAPE의 End of Tpae을 찍을때 테잎이 poor상태로 되고 다음 테잎을 로딩하지 못하고 에러가 발생한 경우도 있었습니다.

(한테잎의 용량을 넘는 백업이 진행될때)



문의 하신경우가 이경우가 아닌지 점검해보십시오. 의심이 가신다면

Firmware와 Ultra160, stape 최신 패치을 하시고 만약 Data Protector을 사용하신다면 rc에 추가 패치을 요청하십시오.



질문하신분이 이 경우가 아니라 면 참고하십시오



(제경우도 정상적으로 LTT을 사용하여 firmware update을 시도하였는데 에러가 발생되어 driver을 교체한적이 있습니다.)

[정성호]

답변 감사합니다.

그렇다면 drive 를 교체한 후에는 모두다 정상적으로 backup 이 되었는지 궁금합니다.

제 증상과 동일합니다.

일단은 omniback II 4.10 의 최신patch 는 적용되어 있는 상태입니다.



drive firmware update 만 실패 하였습니다.

이것을 가능하게 하려면 어떤 방법이 있는지 궁금합니다.