IBM Support

AIX61 PTF in Error (Doc Number=null)

Fix Readme


Abstract

AIX61 PTF in Error (Doc Number=null) PTF: U850080 Fileset: bos.iocp.rte.6.1.6.18 APAR: IV27337 reported against fix pack: 6100-06-08-1216 Fix available in fixpack: 6100-06-10-1241 This problem only happens with applications using IOCP. It has primarily been seen with Lotus Domino Server. . In certain timing, when the application is sending data and the server abruptly closes the connection, the system can crash. .
PTF: U851362 Fileset: bos.iocp.rte.6.1.6.19 APAR: IV28515 reported against fix pack: 6100-06-09-1228 Fix available in fixpack: 6100-06-10-1241 System may crash with following stack trace when iocp send is happening and the other end closes the connection: F1000000C0277534 iocp.ext:iocp_insque+000014 (F1000E000577D0E0, F1000000C0280A08 ?? ) F1000000C0275470 iocp.ext:iocp_process_pending_io+000270 (??) F1000000C0277C70 iocp.ext:iocp_isr+000070 () 00014D70 .hkey_legacy_gate+00004C () 004A11B8 Netintr+0002F8 () 004A0E80 netisr_thread+000020 () 00255654 threadentry+000094 (??, ??, ??, ??)
PTF: U850080 Fileset: bos.iocp.rte.6.1.6.18 APAR: IV28515 reported against fix pack: 6100-06-08-1216 Fix available in fixpack: 6100-06-10-1241 System may crash with following stack trace when iocp send is happening and the other end closes the connection: F1000000C0277534 iocp.ext:iocp_insque+000014 (F1000E000577D0E0

Content

AIX61 PTF in Error (Doc Number=null)

PTF:  U850080 Fileset:  bos.iocp.rte.6.1.6.18
APAR:  IV27337 reported against fix pack: 6100-06-08-1216
Fix available in fixpack:  6100-06-10-1241

This problem only happens with applications using IOCP. It has primarily been seen with Lotus Domino Server. . In certain timing, when the application is sending data and the server abruptly closes the connection, the system can crash. .


PTF:  U851362 Fileset:  bos.iocp.rte.6.1.6.19
APAR:  IV28515 reported against fix pack: 6100-06-09-1228
Fix available in fixpack:  6100-06-10-1241

System may crash with following stack trace when iocp send is happening and the other end closes the connection: F1000000C0277534 iocp.ext:iocp_insque+000014 (F1000E000577D0E0, F1000000C0280A08 ?? ) F1000000C0275470 iocp.ext:iocp_process_pending_io+000270 (??) F1000000C0277C70 iocp.ext:iocp_isr+000070 () 00014D70 .hkey_legacy_gate+00004C () 004A11B8 Netintr+0002F8 () 004A0E80 netisr_thread+000020 () 00255654 threadentry+000094 (??, ??, ??, ??)


PTF:  U850080 Fileset:  bos.iocp.rte.6.1.6.18
APAR:  IV28515 reported against fix pack: 6100-06-08-1216
Fix available in fixpack:  6100-06-10-1241

System may crash with following stack trace when iocp send is happening and the other end closes the connection: F1000000C0277534 iocp.ext:iocp_insque+000014 (F1000E000577D0E0, F1000000C0280A08 ?? ) F1000000C0275470 iocp.ext:iocp_process_pending_io+000270 (??) F1000000C0277C70 iocp.ext:iocp_isr+000070 () 00014D70 .hkey_legacy_gate+00004C () 004A11B8 Netintr+0002F8 () 004A0E80 netisr_thread+000020 () 00255654 threadentry+000094 (??, ??, ??, ??)


PTF:  U850107 Fileset:  bos.net.tcp.client.6.1.6.20
APAR:  IV28446 reported against fix pack: 6100-06-09-1228
Fix available in fixpack:  6100-06-10-1241

snmpinfo hrProcessorLoad metrics are incorrect in a shared processor environment for customer upgrades that include: APAR IZ72006 - HRPROCESSORLOAD DOES NOT MATCH WITH SAR hrProcessorLoad metrics do not match cpu load reported by native AIX tools such as topas, vmstat, mpstat, and sar. In this example, after a cpu spike, snmpinfo hrProcessorLoad remained at almost 100% while topas utilization returned to normal: snmpinfo hrProcessorLoad: ========================= Fri Jan 20 12:59:57 EST 2012 bash-3.00# snmpinfo -m dump -v hrprocessorload hrProcessorLoad.1 = 96 hrProcessorLoad.2 = 98 hrProcessorLoad.3 = 98 hrProcessorLoad.4 = 85 bash-3.00# Topas: ====== Fri Jan 20 13:01:54 2012 Interval: 2 Cswitch 710 Readch 23787 Syscall 555 Writech50079 CPU User% Kern% Wait% Idle% Physc Entc Reads 41 Rawin 0 ALL 0.2 0.3 0.0 99.5 0.01 0.7 Writes 6 Ttyout 382 This issue has been reported by customers who upgraded to 5.3 TL12 as well as upgrades to 6.1 TL6 SP3, SP4, SP5 The behavior is specific to shared processor environments and is not seen with dedicated processors.


PTF:  U849886 Fileset:  bos.net.tcp.client.6.1.6.19
APAR:  IV28446 reported against fix pack: 6100-06-08-1216
Fix available in fixpack:  6100-06-10-1241

snmpinfo hrProcessorLoad metrics are incorrect in a shared processor environment for customer upgrades that include: APAR IZ72006 - HRPROCESSORLOAD DOES NOT MATCH WITH SAR hrProcessorLoad metrics do not match cpu load reported by native AIX tools such as topas, vmstat, mpstat, and sar. In this example, after a cpu spike, snmpinfo hrProcessorLoad remained at almost 100% while topas utilization returned to normal: snmpinfo hrProcessorLoad: ========================= Fri Jan 20 12:59:57 EST 2012 bash-3.00# snmpinfo -m dump -v hrprocessorload hrProcessorLoad.1 = 96 hrProcessorLoad.2 = 98 hrProcessorLoad.3 = 98 hrProcessorLoad.4 = 85 bash-3.00# Topas: ====== Fri Jan 20 13:01:54 2012 Interval: 2 Cswitch 710 Readch 23787 Syscall 555 Writech50079 CPU User% Kern% Wait% Idle% Physc Entc Reads 41 Rawin 0 ALL 0.2 0.3 0.0 99.5 0.01 0.7 Writes 6 Ttyout 382 This issue has been reported by customers who upgraded to 5.3 TL12 as well as upgrades to 6.1 TL6 SP3, SP4, SP5 The behavior is specific to shared processor environments and is not seen with dedicated processors.


PTF:  U849877 Fileset:  bos.net.tcp.client.6.1.6.18
APAR:  IV28446 reported against fix pack: 6100-06-08-1216
Fix available in fixpack:  6100-06-10-1241

snmpinfo hrProcessorLoad metrics are incorrect in a shared processor environment for customer upgrades that include: APAR IZ72006 - HRPROCESSORLOAD DOES NOT MATCH WITH SAR hrProcessorLoad metrics do not match cpu load reported by native AIX tools such as topas, vmstat, mpstat, and sar. In this example, after a cpu spike, snmpinfo hrProcessorLoad remained at almost 100% while topas utilization returned to normal: snmpinfo hrProcessorLoad: ========================= Fri Jan 20 12:59:57 EST 2012 bash-3.00# snmpinfo -m dump -v hrprocessorload hrProcessorLoad.1 = 96 hrProcessorLoad.2 = 98 hrProcessorLoad.3 = 98 hrProcessorLoad.4 = 85 bash-3.00# Topas: ====== Fri Jan 20 13:01:54 2012 Interval: 2 Cswitch 710 Readch 23787 Syscall 555 Writech50079 CPU User% Kern% Wait% Idle% Physc Entc Reads 41 Rawin 0 ALL 0.2 0.3 0.0 99.5 0.01 0.7 Writes 6 Ttyout 382 This issue has been reported by customers who upgraded to 5.3 TL12 as well as upgrades to 6.1 TL6 SP3, SP4, SP5 The behavior is specific to shared processor environments and is not seen with dedicated processors.


PTF:  U849141 Fileset:  bos.net.tcp.client.6.1.6.17
APAR:  IV28446 reported against fix pack: 6100-06-07-1207
Fix available in fixpack:  6100-06-10-1241

snmpinfo hrProcessorLoad metrics are incorrect in a shared processor environment for customer upgrades that include: APAR IZ72006 - HRPROCESSORLOAD DOES NOT MATCH WITH SAR hrProcessorLoad metrics do not match cpu load reported by native AIX tools such as topas, vmstat, mpstat, and sar. In this example, after a cpu spike, snmpinfo hrProcessorLoad remained at almost 100% while topas utilization returned to normal: snmpinfo hrProcessorLoad: ========================= Fri Jan 20 12:59:57 EST 2012 bash-3.00# snmpinfo -m dump -v hrprocessorload hrProcessorLoad.1 = 96 hrProcessorLoad.2 = 98 hrProcessorLoad.3 = 98 hrProcessorLoad.4 = 85 bash-3.00# Topas: ====== Fri Jan 20 13:01:54 2012 Interval: 2 Cswitch 710 Readch 23787 Syscall 555 Writech50079 CPU User% Kern% Wait% Idle% Physc Entc Reads 41 Rawin 0 ALL 0.2 0.3 0.0 99.5 0.01 0.7 Writes 6 Ttyout 382 This issue has been reported by customers who upgraded to 5.3 TL12 as well as upgrades to 6.1 TL6 SP3, SP4, SP5 The behavior is specific to shared processor environments and is not seen with dedicated processors.


PTF:  U843088 Fileset:  bos.net.tcp.client.6.1.6.16
APAR:  IV28446 reported against fix pack: 6100-06-06-1140
Fix available in fixpack:  6100-06-10-1241

snmpinfo hrProcessorLoad metrics are incorrect in a shared processor environment for customer upgrades that include: APAR IZ72006 - HRPROCESSORLOAD DOES NOT MATCH WITH SAR hrProcessorLoad metrics do not match cpu load reported by native AIX tools such as topas, vmstat, mpstat, and sar. In this example, after a cpu spike, snmpinfo hrProcessorLoad remained at almost 100% while topas utilization returned to normal: snmpinfo hrProcessorLoad: ========================= Fri Jan 20 12:59:57 EST 2012 bash-3.00# snmpinfo -m dump -v hrprocessorload hrProcessorLoad.1 = 96 hrProcessorLoad.2 = 98 hrProcessorLoad.3 = 98 hrProcessorLoad.4 = 85 bash-3.00# Topas: ====== Fri Jan 20 13:01:54 2012 Interval: 2 Cswitch 710 Readch 23787 Syscall 555 Writech50079 CPU User% Kern% Wait% Idle% Physc Entc Reads 41 Rawin 0 ALL 0.2 0.3 0.0 99.5 0.01 0.7 Writes 6 Ttyout 382 This issue has been reported by customers who upgraded to 5.3 TL12 as well as upgrades to 6.1 TL6 SP3, SP4, SP5 The behavior is specific to shared processor environments and is not seen with dedicated processors.


PTF:  U838336 Fileset:  bos.net.tcp.client.6.1.6.4
APAR:  IV28446 reported against fix pack: 6100-06-04-1112
Fix available in fixpack:  6100-06-10-1241

snmpinfo hrProcessorLoad metrics are incorrect in a shared processor environment for customer upgrades that include: APAR IZ72006 - HRPROCESSORLOAD DOES NOT MATCH WITH SAR hrProcessorLoad metrics do not match cpu load reported by native AIX tools such as topas, vmstat, mpstat, and sar. In this example, after a cpu spike, snmpinfo hrProcessorLoad remained at almost 100% while topas utilization returned to normal: snmpinfo hrProcessorLoad: ========================= Fri Jan 20 12:59:57 EST 2012 bash-3.00# snmpinfo -m dump -v hrprocessorload hrProcessorLoad.1 = 96 hrProcessorLoad.2 = 98 hrProcessorLoad.3 = 98 hrProcessorLoad.4 = 85 bash-3.00# Topas: ====== Fri Jan 20 13:01:54 2012 Interval: 2 Cswitch 710 Readch 23787 Syscall 555 Writech50079 CPU User% Kern% Wait% Idle% Physc Entc Reads 41 Rawin 0 ALL 0.2 0.3 0.0 99.5 0.01 0.7 Writes 6 Ttyout 382 This issue has been reported by customers who upgraded to 5.3 TL12 as well as upgrades to 6.1 TL6 SP3, SP4, SP5 The behavior is specific to shared processor environments and is not seen with dedicated processors.


PTF:  U838245 Fileset:  bos.net.tcp.client.6.1.6.3
APAR:  IV28446 reported against fix pack: 6100-06-03-1048
Fix available in fixpack:  6100-06-10-1241

snmpinfo hrProcessorLoad metrics are incorrect in a shared processor environment for customer upgrades that include: APAR IZ72006 - HRPROCESSORLOAD DOES NOT MATCH WITH SAR hrProcessorLoad metrics do not match cpu load reported by native AIX tools such as topas, vmstat, mpstat, and sar. In this example, after a cpu spike, snmpinfo hrProcessorLoad remained at almost 100% while topas utilization returned to normal: snmpinfo hrProcessorLoad: ========================= Fri Jan 20 12:59:57 EST 2012 bash-3.00# snmpinfo -m dump -v hrprocessorload hrProcessorLoad.1 = 96 hrProcessorLoad.2 = 98 hrProcessorLoad.3 = 98 hrProcessorLoad.4 = 85 bash-3.00# Topas: ====== Fri Jan 20 13:01:54 2012 Interval: 2 Cswitch 710 Readch 23787 Syscall 555 Writech50079 CPU User% Kern% Wait% Idle% Physc Entc Reads 41 Rawin 0 ALL 0.2 0.3 0.0 99.5 0.01 0.7 Writes 6 Ttyout 382 This issue has been reported by customers who upgraded to 5.3 TL12 as well as upgrades to 6.1 TL6 SP3, SP4, SP5 The behavior is specific to shared processor environments and is not seen with dedicated processors.


PTF:  U835902 Fileset:  bos.net.tcp.client.6.1.6.15
APAR:  IV28446 reported against fix pack: 6100-06-05-1115
Fix available in fixpack:  6100-06-10-1241

snmpinfo hrProcessorLoad metrics are incorrect in a shared processor environment for customer upgrades that include: APAR IZ72006 - HRPROCESSORLOAD DOES NOT MATCH WITH SAR hrProcessorLoad metrics do not match cpu load reported by native AIX tools such as topas, vmstat, mpstat, and sar. In this example, after a cpu spike, snmpinfo hrProcessorLoad remained at almost 100% while topas utilization returned to normal: snmpinfo hrProcessorLoad: ========================= Fri Jan 20 12:59:57 EST 2012 bash-3.00# snmpinfo -m dump -v hrprocessorload hrProcessorLoad.1 = 96 hrProcessorLoad.2 = 98 hrProcessorLoad.3 = 98 hrProcessorLoad.4 = 85 bash-3.00# Topas: ====== Fri Jan 20 13:01:54 2012 Interval: 2 Cswitch 710 Readch 23787 Syscall 555 Writech50079 CPU User% Kern% Wait% Idle% Physc Entc Reads 41 Rawin 0 ALL 0.2 0.3 0.0 99.5 0.01 0.7 Writes 6 Ttyout 382 This issue has been reported by customers who upgraded to 5.3 TL12 as well as upgrades to 6.1 TL6 SP3, SP4, SP5 The behavior is specific to shared processor environments and is not seen with dedicated processors.


PTF:  U834372 Fileset:  bos.net.tcp.client.6.1.6.2
APAR:  IV28446 reported against fix pack: 6100-06-02-1044
Fix available in fixpack:  6100-06-10-1241

snmpinfo hrProcessorLoad metrics are incorrect in a shared processor environment for customer upgrades that include: APAR IZ72006 - HRPROCESSORLOAD DOES NOT MATCH WITH SAR hrProcessorLoad metrics do not match cpu load reported by native AIX tools such as topas, vmstat, mpstat, and sar. In this example, after a cpu spike, snmpinfo hrProcessorLoad remained at almost 100% while topas utilization returned to normal: snmpinfo hrProcessorLoad: ========================= Fri Jan 20 12:59:57 EST 2012 bash-3.00# snmpinfo -m dump -v hrprocessorload hrProcessorLoad.1 = 96 hrProcessorLoad.2 = 98 hrProcessorLoad.3 = 98 hrProcessorLoad.4 = 85 bash-3.00# Topas: ====== Fri Jan 20 13:01:54 2012 Interval: 2 Cswitch 710 Readch 23787 Syscall 555 Writech50079 CPU User% Kern% Wait% Idle% Physc Entc Reads 41 Rawin 0 ALL 0.2 0.3 0.0 99.5 0.01 0.7 Writes 6 Ttyout 382 This issue has been reported by customers who upgraded to 5.3 TL12 as well as upgrades to 6.1 TL6 SP3, SP4, SP5 The behavior is specific to shared processor environments and is not seen with dedicated processors.


PTF:  U834314 Fileset:  bos.net.tcp.client.6.1.6.1
APAR:  IV28446 reported against fix pack: 6100-06
Fix available in fixpack:  6100-06-10-1241

snmpinfo hrProcessorLoad metrics are incorrect in a shared processor environment for customer upgrades that include: APAR IZ72006 - HRPROCESSORLOAD DOES NOT MATCH WITH SAR hrProcessorLoad metrics do not match cpu load reported by native AIX tools such as topas, vmstat, mpstat, and sar. In this example, after a cpu spike, snmpinfo hrProcessorLoad remained at almost 100% while topas utilization returned to normal: snmpinfo hrProcessorLoad: ========================= Fri Jan 20 12:59:57 EST 2012 bash-3.00# snmpinfo -m dump -v hrprocessorload hrProcessorLoad.1 = 96 hrProcessorLoad.2 = 98 hrProcessorLoad.3 = 98 hrProcessorLoad.4 = 85 bash-3.00# Topas: ====== Fri Jan 20 13:01:54 2012 Interval: 2 Cswitch 710 Readch 23787 Syscall 555 Writech50079 CPU User% Kern% Wait% Idle% Physc Entc Reads 41 Rawin 0 ALL 0.2 0.3 0.0 99.5 0.01 0.7 Writes 6 Ttyout 382 This issue has been reported by customers who upgraded to 5.3 TL12 as well as upgrades to 6.1 TL6 SP3, SP4, SP5 The behavior is specific to shared processor environments and is not seen with dedicated processors.


PTF:  U851561 Fileset:  devices.vdevice.IBM.v-scsi.rte.6.1.6.18
APAR:  IV25755 reported against fix pack: 6100-06-09-1228
Fix available in fixpack:  6100-06-10-1241

There is a potential crash in the client VSCSI driver when unconfiguring the adapter instance (e.g., rmdev). The stack trace looks like: (0)> f pvthread+095900 STACK: [041ADB58]vscsi_free_scsi+000138 (0000000000000000 [??]) r31 : 0000000000000130 r30 : F1000A003EFA4000 [041A2524]vscsi_fail_config+0000A4 (??, ??, ??) r31 : 8000001000000002 r30 : 00000000041C02C0 r29 : 0000000000000000 r28 : F1000A003EFA4000 r27 : 0000000000000002 r26 : 8000001000000002 r25 : 00000000DEADBEEF [041A5CA8]vscsi_init_config+0001A8 (??, ??, ??) r31 : 0000000000000002 r30 : 0000000000000000 r29 : 0000000000000002 r28 : 0000000000000000 r27 : 0000000000000000 r26 : 8000001000000002 r25 : 00000000DEADBEEF r24 : 00000000DEADBEEF r23 : 00000000DEADBEEF r22 : 00000000DEADBEEF r21 : 00000000DEADBEEF r20 : 00000000DEADBEEF [00665950]config_dd+000270 (??, ??, ??) r31 : 0000000000000006 r30 : 000000002FF22560 r29 : 0000000000000014 r28 : 0000000000000000 r27 : 000000000000008A r26 : 0000000000000000 [006666A0]sysconfig+000240 (??, ??, ??) r31 : 0000000000000000 r30 : 0000000010002C88 r29 : 000000002000147C r28 : 0000000000000000 [00003850]ovlya_addr_sc_flih_main+000130 () [kdb_get_virtual_memory] no real storage @ 2FF22528 [10002C84]10002C84 () [kdb_read_mem] no real storage @ FFFFFFFFFFF9520 (0)> dc 041ADB58 .vscsi_free_scsi+000138 tweq r14,r14


PTF:  U849854 Fileset:  devices.vdevice.IBM.v-scsi.rte.6.1.6.17
APAR:  IV25755 reported against fix pack: 6100-06-07-1207
Fix available in fixpack:  6100-06-10-1241

There is a potential crash in the client VSCSI driver when unconfiguring the adapter instance (e.g., rmdev). The stack trace looks like: (0)> f pvthread+095900 STACK: [041ADB58]vscsi_free_scsi+000138 (0000000000000000 [??]) r31 : 0000000000000130 r30 : F1000A003EFA4000 [041A2524]vscsi_fail_config+0000A4 (??, ??, ??) r31 : 8000001000000002 r30 : 00000000041C02C0 r29 : 0000000000000000 r28 : F1000A003EFA4000 r27 : 0000000000000002 r26 : 8000001000000002 r25 : 00000000DEADBEEF [041A5CA8]vscsi_init_config+0001A8 (??, ??, ??) r31 : 0000000000000002 r30 : 0000000000000000 r29 : 0000000000000002 r28 : 0000000000000000 r27 : 0000000000000000 r26 : 8000001000000002 r25 : 00000000DEADBEEF r24 : 00000000DEADBEEF r23 : 00000000DEADBEEF r22 : 00000000DEADBEEF r21 : 00000000DEADBEEF r20 : 00000000DEADBEEF [00665950]config_dd+000270 (??, ??, ??) r31 : 0000000000000006 r30 : 000000002FF22560 r29 : 0000000000000014 r28 : 0000000000000000 r27 : 000000000000008A r26 : 0000000000000000 [006666A0]sysconfig+000240 (??, ??, ??) r31 : 0000000000000000 r30 : 0000000010002C88 r29 : 000000002000147C r28 : 0000000000000000 [00003850]ovlya_addr_sc_flih_main+000130 () [kdb_get_virtual_memory] no real storage @ 2FF22528 [10002C84]10002C84 () [kdb_read_mem] no real storage @ FFFFFFFFFFF9520 (0)> dc 041ADB58 .vscsi_free_scsi+000138 tweq r14,r14


PTF:  U836370 Fileset:  bos.net.sctp.6.1.6.15
APAR:  IV14705 reported against fix pack: 6100-06-05-1115
Fix available in fixpack:  6100-06-10-1241

System may crash with the following stack when SCTP is used for communication and an invalid iovec structure is passed to the recvmsg() function. (0)> f pvthread+017100 STACK: [0632BA80]sctp_pru_rcvd+000080 (0000000000000000 [??]) [0632FEB8]sctp_receive+000358 (??, ??, ??, ??, ??, ??) [004F81EC]erecvit+000EEC (??, ??, ??, ??) [004F8A60]_enrecvmsg+0005E0 (??, ??, ??, ??) [0000386C]ovlya_addr_sc_flih_main+00014C () [kdb_get_virtual_memory] no real storage @ 2FF203A8 [D02039B4]D02039B4 () [kdb_read_mem] no real storage @ FFFFFFFFFFF94D0


Doc number: 2840 Published date: 2012.12.14
AIX61 PTF in Error (Doc Number=null)
PTF:  U852354 Fileset:  bos.iocp.rte.6.1.7.16
APAR:  IV24569 reported against fix pack: 6100-07-05-1228
Fix available in fixpack:  6100-07-06-1241

This problem only happens with applications using IOCP. It has primarily been seen with Lotus Domino Server. . In certain timing, when the application is sending data and the server abruptly closes the connection, the system can crash. .


PTF:  U841072 Fileset:  bos.iocp.rte.6.1.7.15
APAR:  IV24569 reported against fix pack: 6100-07-04-1216
Fix available in fixpack:  6100-07-06-1241

This problem only happens with applications using IOCP. It has primarily been seen with Lotus Domino Server. . In certain timing, when the application is sending data and the server abruptly closes the connection, the system can crash. .


PTF:  U848572 Fileset:  devices.vdevice.IBM.v-scsi.rte.6.1.7.16
APAR:  IV29306 reported against fix pack: 6100-07-05-1228
Fix available in fixpack:  6100-07-06-1241

There is a potential crash in the client VSCSI driver when unconfiguring the adapter instance (e.g., rmdev). The stack trace looks like: (0)> f pvthread+095900 STACK: [041ADB58]vscsi_free_scsi+000138 (0000000000000000 [??]) r31 : 0000000000000130 r30 : F1000A003EFA4000 [041A2524]vscsi_fail_config+0000A4 (??, ??, ??) r31 : 8000001000000002 r30 : 00000000041C02C0 r29 : 0000000000000000 r28 : F1000A003EFA4000 r27 : 0000000000000002 r26 : 8000001000000002 r25 : 00000000DEADBEEF [041A5CA8]vscsi_init_config+0001A8 (??, ??, ??) r31 : 0000000000000002 r30 : 0000000000000000 r29 : 0000000000000002 r28 : 0000000000000000 r27 : 0000000000000000 r26 : 8000001000000002 r25 : 00000000DEADBEEF r24 : 00000000DEADBEEF r23 : 00000000DEADBEEF r22 : 00000000DEADBEEF r21 : 00000000DEADBEEF r20 : 00000000DEADBEEF [00665950]config_dd+000270 (??, ??, ??) r31 : 0000000000000006 r30 : 000000002FF22560 r29 : 0000000000000014 r28 : 0000000000000000 r27 : 000000000000008A r26 : 0000000000000000 [006666A0]sysconfig+000240 (??, ??, ??) r31 : 0000000000000000 r30 : 0000000010002C88 r29 : 000000002000147C r28 : 0000000000000000 [00003850]ovlya_addr_sc_flih_main+000130 () [kdb_get_virtual_memory] no real storage @ 2FF22528 [10002C84]10002C84 () [kdb_read_mem] no real storage @ FFFFFFFFFFF9520 (0)> dc 041ADB58 .vscsi_free_scsi+000138 tweq r14,r14


PTF:  U844772 Fileset:  devices.vdevice.IBM.v-scsi.rte.6.1.7.15
APAR:  IV29306 reported against fix pack: 6100-07-04-1216
Fix available in fixpack:  6100-07-06-1241

There is a potential crash in the client VSCSI driver when unconfiguring the adapter instance (e.g., rmdev). The stack trace looks like: (0)> f pvthread+095900 STACK: [041ADB58]vscsi_free_scsi+000138 (0000000000000000 [??]) r31 : 0000000000000130 r30 : F1000A003EFA4000 [041A2524]vscsi_fail_config+0000A4 (??, ??, ??) r31 : 8000001000000002 r30 : 00000000041C02C0 r29 : 0000000000000000 r28 : F1000A003EFA4000 r27 : 0000000000000002 r26 : 8000001000000002 r25 : 00000000DEADBEEF [041A5CA8]vscsi_init_config+0001A8 (??, ??, ??) r31 : 0000000000000002 r30 : 0000000000000000 r29 : 0000000000000002 r28 : 0000000000000000 r27 : 0000000000000000 r26 : 8000001000000002 r25 : 00000000DEADBEEF r24 : 00000000DEADBEEF r23 : 00000000DEADBEEF r22 : 00000000DEADBEEF r21 : 00000000DEADBEEF r20 : 00000000DEADBEEF [00665950]config_dd+000270 (??, ??, ??) r31 : 0000000000000006 r30 : 000000002FF22560 r29 : 0000000000000014 r28 : 0000000000000000 r27 : 000000000000008A r26 : 0000000000000000 [006666A0]sysconfig+000240 (??, ??, ??) r31 : 0000000000000000 r30 : 0000000010002C88 r29 : 000000002000147C r28 : 0000000000000000 [00003850]ovlya_addr_sc_flih_main+000130 () [kdb_get_virtual_memory] no real storage @ 2FF22528 [10002C84]10002C84 () [kdb_read_mem] no real storage @ FFFFFFFFFFF9520 (0)> dc 041ADB58 .vscsi_free_scsi+000138 tweq r14,r14


PTF:  U852376 Fileset:  bos.rte.archive.6.1.7.17
APAR:  IV29346 reported against fix pack: 6100-07-05-1228
Fix available in fixpack:  6100-07-06-1241

After writing the file to archive media, we remove the temp file and then try to get the extended attributes when the file is already deleted.


PTF:  U848561 Fileset:  bos.rte.archive.6.1.7.16
APAR:  IV29346 reported against fix pack: 6100-07-04-1216
Fix available in fixpack:  6100-07-06-1241

After writing the file to archive media, we remove the temp file and then try to get the extended attributes when the file is already deleted.


PTF:  U848163 Fileset:  bos.rte.archive.6.1.7.2
APAR:  IV29346 reported against fix pack: 6100-07-03-1207
Fix available in fixpack:  6100-07-06-1241

After writing the file to archive media, we remove the temp file and then try to get the extended attributes when the file is already deleted.


PTF:  U846106 Fileset:  bos.rte.archive.6.1.7.1
APAR:  IV29346 reported against fix pack: 6100-07-02-1150
Fix available in fixpack:  6100-07-06-1241

After writing the file to archive media, we remove the temp file and then try to get the extended attributes when the file is already deleted.


PTF:  U838171 Fileset:  bos.rte.archive.6.1.7.0
APAR:  IV29346 reported against fix pack: 6100-07
Fix available in fixpack:  6100-07-06-1241

After writing the file to archive media, we remove the temp file and then try to get the extended attributes when the file is already deleted.


PTF:  U852354 Fileset:  bos.iocp.rte.6.1.7.16
APAR:  IV28736 reported against fix pack: 6100-07-05-1228
Fix available in fixpack:  6100-07-06-1241

System may crash with following stack trace when iocp send is happening and the other end closes the connection: F1000000C0277534 iocp.ext:iocp_insque+000014 (F1000E000577D0E0, F1000000C0280A08 ?? ) F1000000C0275470 iocp.ext:iocp_process_pending_io+000270 (??) F1000000C0277C70 iocp.ext:iocp_isr+000070 () 00014D70 .hkey_legacy_gate+00004C () 004A11B8 Netintr+0002F8 () 004A0E80 netisr_thread+000020 () 00255654 threadentry+000094 (??, ??, ??, ??)


PTF:  U841072 Fileset:  bos.iocp.rte.6.1.7.15
APAR:  IV28736 reported against fix pack: 6100-07-04-1216
Fix available in fixpack:  6100-07-06-1241

System may crash with following stack trace when iocp send is happening and the other end closes the connection: F1000000C0277534 iocp.ext:iocp_insque+000014 (F1000E000577D0E0, F1000000C0280A08 ?? ) F1000000C0275470 iocp.ext:iocp_process_pending_io+000270 (??) F1000000C0277C70 iocp.ext:iocp_isr+000070 () 00014D70 .hkey_legacy_gate+00004C () 004A11B8 Netintr+0002F8 () 004A0E80 netisr_thread+000020 () 00255654 threadentry+000094 (??, ??, ??, ??)


PTF:  U848583 Fileset:  devices.pci.77102224.com.6.1.7.16
APAR:  IV28407 reported against fix pack: 6100-07-05-1228
Fix available in fixpack:  6100-07-06-1241

Possible crash in the QLogic Fibre Channel driver during target mode I/O with a stack trace similar to: 045DEAEC qlfsc_tm_process_atio+000B2C (??, ??) 045BF730 qlfsc_recv+000270 (??, ??) 044A4398 qlfc_proc_atio_iocbs+000218 (??) 044A4F70 qlfc_intr+000570 (??) This is a low probability problem that can occur only during heavy target mode I/O.


PTF:  U846201 Fileset:  devices.pci.77102224.com.6.1.7.2
APAR:  IV28407 reported against fix pack: 6100-07-03-1207
Fix available in fixpack:  6100-07-06-1241

Possible crash in the QLogic Fibre Channel driver during target mode I/O with a stack trace similar to: 045DEAEC qlfsc_tm_process_atio+000B2C (??, ??) 045BF730 qlfsc_recv+000270 (??, ??) 044A4398 qlfc_proc_atio_iocbs+000218 (??) 044A4F70 qlfc_intr+000570 (??) This is a low probability problem that can occur only during heavy target mode I/O.


PTF:  U846086 Fileset:  devices.pci.77102224.com.6.1.7.1
APAR:  IV28407 reported against fix pack: 6100-07-02-1150
Fix available in fixpack:  6100-07-06-1241

Possible crash in the QLogic Fibre Channel driver during target mode I/O with a stack trace similar to: 045DEAEC qlfsc_tm_process_atio+000B2C (??, ??) 045BF730 qlfsc_recv+000270 (??, ??) 044A4398 qlfc_proc_atio_iocbs+000218 (??) 044A4F70 qlfc_intr+000570 (??) This is a low probability problem that can occur only during heavy target mode I/O.


PTF:  U843027 Fileset:  devices.pci.77102224.com.6.1.7.15
APAR:  IV28407 reported against fix pack: 6100-07-04-1216
Fix available in fixpack:  6100-07-06-1241

Possible crash in the QLogic Fibre Channel driver during target mode I/O with a stack trace similar to: 045DEAEC qlfsc_tm_process_atio+000B2C (??, ??) 045BF730 qlfsc_recv+000270 (??, ??) 044A4398 qlfc_proc_atio_iocbs+000218 (??) 044A4F70 qlfc_intr+000570 (??) This is a low probability problem that can occur only during heavy target mode I/O.


PTF:  U838042 Fileset:  devices.pci.77102224.com.6.1.7.0
APAR:  IV28407 reported against fix pack: 6100-07
Fix available in fixpack:  6100-07-06-1241

Possible crash in the QLogic Fibre Channel driver during target mode I/O with a stack trace similar to: 045DEAEC qlfsc_tm_process_atio+000B2C (??, ??) 045BF730 qlfsc_recv+000270 (??, ??) 044A4398 qlfc_proc_atio_iocbs+000218 (??) 044A4F70 qlfc_intr+000570 (??) This is a low probability problem that can occur only during heavy target mode I/O.


PTF:  U850427 Fileset:  bos.rte.libc.6.1.7.16
APAR:  IV28346 reported against fix pack: 6100-07-05-1228
Fix available in fixpack:  6100-07-06-1241

Bos.rte.libc has a missing requisite to bos.rte.date. The date can display UTC if using Olson format, if libc is updated without bos.rte.date being updated.


PTF:  U842969 Fileset:  bos.rte.libc.6.1.7.15
APAR:  IV28346 reported against fix pack: 6100-07-04-1216
Fix available in fixpack:  6100-07-06-1241

Bos.rte.libc has a missing requisite to bos.rte.date. The date can display UTC if using Olson format, if libc is updated without bos.rte.date being updated.


PTF:  U848618 Fileset:  bos.rte.security.6.1.7.16
APAR:  IV24347 reported against fix pack: 6100-07-05-1228
Fix available in fixpack:  6100-07-06-1241

After AIX Upgrade to 6100-07-01 and upon reboot, system gets error message saying library load failed cannot load a file that does not have a valid format user:err|error syslog: err[1]=103 /usr/ccs/lib/libclic.a shr.o user:err|error syslog: Library load failed: Exec format error user:err|error syslog: err[0]=2 /usr/ccs/lib/libclic.a shr.o user:err|error syslog: err[1]=103 /usr/ccs/lib/libclic.a shr.o user:err|error syslog: Library load failed: Exec format error user:err|error syslog: err[0]=2 /usr/ccs/lib/libclic.a shr.o


PTF:  U846174 Fileset:  bos.rte.security.6.1.7.2
APAR:  IV24347 reported against fix pack: 6100-07-03-1207
Fix available in fixpack:  6100-07-06-1241

After AIX Upgrade to 6100-07-01 and upon reboot, system gets error message saying library load failed cannot load a file that does not have a valid format user:err|error syslog: err[1]=103 /usr/ccs/lib/libclic.a shr.o user:err|error syslog: Library load failed: Exec format error user:err|error syslog: err[0]=2 /usr/ccs/lib/libclic.a shr.o user:err|error syslog: err[1]=103 /usr/ccs/lib/libclic.a shr.o user:err|error syslog: Library load failed: Exec format error user:err|error syslog: err[0]=2 /usr/ccs/lib/libclic.a shr.o


PTF:  U846074 Fileset:  bos.rte.security.6.1.7.1
APAR:  IV24347 reported against fix pack: 6100-07-02-1150
Fix available in fixpack:  6100-07-06-1241

After AIX Upgrade to 6100-07-01 and upon reboot, system gets error message saying library load failed cannot load a file that does not have a valid format user:err|error syslog: err[1]=103 /usr/ccs/lib/libclic.a shr.o user:err|error syslog: Library load failed: Exec format error user:err|error syslog: err[0]=2 /usr/ccs/lib/libclic.a shr.o user:err|error syslog: err[1]=103 /usr/ccs/lib/libclic.a shr.o user:err|error syslog: Library load failed: Exec format error user:err|error syslog: err[0]=2 /usr/ccs/lib/libclic.a shr.o


PTF:  U838721 Fileset:  bos.rte.security.6.1.7.15
APAR:  IV24347 reported against fix pack: 6100-07-04-1216
Fix available in fixpack:  6100-07-06-1241

After AIX Upgrade to 6100-07-01 and upon reboot, system gets error message saying library load failed cannot load a file that does not have a valid format user:err|error syslog: err[1]=103 /usr/ccs/lib/libclic.a shr.o user:err|error syslog: Library load failed: Exec format error user:err|error syslog: err[0]=2 /usr/ccs/lib/libclic.a shr.o user:err|error syslog: err[1]=103 /usr/ccs/lib/libclic.a shr.o user:err|error syslog: Library load failed: Exec format error user:err|error syslog: err[0]=2 /usr/ccs/lib/libclic.a shr.o


PTF:  U837809 Fileset:  bos.rte.security.6.1.7.0
APAR:  IV24347 reported against fix pack: 6100-07
Fix available in fixpack:  6100-07-06-1241

After AIX Upgrade to 6100-07-01 and upon reboot, system gets error message saying library load failed cannot load a file that does not have a valid format user:err|error syslog: err[1]=103 /usr/ccs/lib/libclic.a shr.o user:err|error syslog: Library load failed: Exec format error user:err|error syslog: err[0]=2 /usr/ccs/lib/libclic.a shr.o user:err|error syslog: err[1]=103 /usr/ccs/lib/libclic.a shr.o user:err|error syslog: Library load failed: Exec format error user:err|error syslog: err[0]=2 /usr/ccs/lib/libclic.a shr.o


PTF:  U850425 Fileset:  bos.mp64.6.1.7.16
APAR:  IV24132 reported against fix pack: 6100-07-05-1228
Fix available in fixpack:  6100-07-06-1241

(28)> stat SYSTEM_CONFIGURATION: CHRP_SMP_PCI POWER_PC POWER_7 machine with 64 available CPU(s) (64-bit registers) CRASH INFORMATION: CPU 28 CSA F00000002FF47600 at time of crash, error code for LEDs: 30000000 pvthread+01C200 STACK: [00009514].simple_lock+000014 () [003DB214]makeFilesystemDegraded+0000B4 (??, ??) [00184D14]bmWrite+000314 (??) [003624A0]writeSuperblock+000100 (??, ??) [003621F8]updateSuperblock+0000B8 (??, ??) [00361DB0]j2_mount+000E50 (??, ??) [005A3B0C]vfs_mount+00002C (??, ??) [0059488C]smount+0004EC (??) [005955DC]vmount+00023C (??, ??) [00003850]ovlya_addr_sc_flih_main+000130 () [kdb_get_virtual_memory] no real storage @ 2FF1E508 [10004F04]10004F04 () [kdb_read_mem] no real storage @ FFFFFFFFFFF5B40 System crashes with the above stack during Filesystem mounting period. Usually this may happen when the system unable to write or access the Filesystem disk. Users may see DISK IO errors in error log.


PTF:  U843022 Fileset:  bos.mp64.6.1.7.15
APAR:  IV24132 reported against fix pack: 6100-07-04-1216
Fix available in fixpack:  6100-07-06-1241

(28)> stat SYSTEM_CONFIGURATION: CHRP_SMP_PCI POWER_PC POWER_7 machine with 64 available CPU(s) (64-bit registers) CRASH INFORMATION: CPU 28 CSA F00000002FF47600 at time of crash, error code for LEDs: 30000000 pvthread+01C200 STACK: [00009514].simple_lock+000014 () [003DB214]makeFilesystemDegraded+0000B4 (??, ??) [00184D14]bmWrite+000314 (??) [003624A0]writeSuperblock+000100 (??, ??) [003621F8]updateSuperblock+0000B8 (??, ??) [00361DB0]j2_mount+000E50 (??, ??) [005A3B0C]vfs_mount+00002C (??, ??) [0059488C]smount+0004EC (??) [005955DC]vmount+00023C (??, ??) [00003850]ovlya_addr_sc_flih_main+000130 () [kdb_get_virtual_memory] no real storage @ 2FF1E508 [10004F04]10004F04 () [kdb_read_mem] no real storage @ FFFFFFFFFFF5B40 System crashes with the above stack during Filesystem mounting period. Usually this may happen when the system unable to write or access the Filesystem disk. Users may see DISK IO errors in error log.


PTF:  U848595 Fileset:  bos.net.tcp.client.6.1.7.16
APAR:  IV16784 reported against fix pack: 6100-07-05-1228
Fix available in fixpack:  6100-07-06-1241

snmpinfo hrProcessorLoad metrics are incorrect in a shared processor environment for customer upgrades that include: APAR IZ72006 - HRPROCESSORLOAD DOES NOT MATCH WITH SAR hrProcessorLoad metrics do not match cpu load reported by native AIX tools such as topas, vmstat, mpstat, and sar. In this example, after a cpu spike, snmpinfo hrProcessorLoad remained at almost 100% while topas utilization returned to normal: snmpinfo hrProcessorLoad: ========================= Fri Jan 20 12:59:57 EST 2012 bash-3.00# snmpinfo -m dump -v hrprocessorload hrProcessorLoad.1 = 96 hrProcessorLoad.2 = 98 hrProcessorLoad.3 = 98 hrProcessorLoad.4 = 85 bash-3.00# Topas: ====== Fri Jan 20 13:01:54 2012 Interval: 2 Cswitch 710 Readch 23787 Syscall 555 Writech50079 CPU User% Kern% Wait% Idle% Physc Entc Reads 41 Rawin 0 ALL 0.2 0.3 0.0 99.5 0.01 0.7 Writes 6 Ttyout 382 This issue has been reported by customers who upgraded to 5.3 TL12 as well as upgrades to 6.1 TL6 SP3, SP4, SP5 The behavior is specific to shared processor environments and is not seen with dedicated processors.


PTF:  U846182 Fileset:  bos.net.tcp.client.6.1.7.3
APAR:  IV16784 reported against fix pack: 6100-07-03-1207
Fix available in fixpack:  6100-07-06-1241

snmpinfo hrProcessorLoad metrics are incorrect in a shared processor environment for customer upgrades that include: APAR IZ72006 - HRPROCESSORLOAD DOES NOT MATCH WITH SAR hrProcessorLoad metrics do not match cpu load reported by native AIX tools such as topas, vmstat, mpstat, and sar. In this example, after a cpu spike, snmpinfo hrProcessorLoad remained at almost 100% while topas utilization returned to normal: snmpinfo hrProcessorLoad: ========================= Fri Jan 20 12:59:57 EST 2012 bash-3.00# snmpinfo -m dump -v hrprocessorload hrProcessorLoad.1 = 96 hrProcessorLoad.2 = 98 hrProcessorLoad.3 = 98 hrProcessorLoad.4 = 85 bash-3.00# Topas: ====== Fri Jan 20 13:01:54 2012 Interval: 2 Cswitch 710 Readch 23787 Syscall 555 Writech50079 CPU User% Kern% Wait% Idle% Physc Entc Reads 41 Rawin 0 ALL 0.2 0.3 0.0 99.5 0.01 0.7 Writes 6 Ttyout 382 This issue has been reported by customers who upgraded to 5.3 TL12 as well as upgrades to 6.1 TL6 SP3, SP4, SP5 The behavior is specific to shared processor environments and is not seen with dedicated processors.


PTF:  U846071 Fileset:  bos.net.tcp.client.6.1.7.2
APAR:  IV16784 reported against fix pack: 6100-07-02-1150
Fix available in fixpack:  6100-07-06-1241

snmpinfo hrProcessorLoad metrics are incorrect in a shared processor environment for customer upgrades that include: APAR IZ72006 - HRPROCESSORLOAD DOES NOT MATCH WITH SAR hrProcessorLoad metrics do not match cpu load reported by native AIX tools such as topas, vmstat, mpstat, and sar. In this example, after a cpu spike, snmpinfo hrProcessorLoad remained at almost 100% while topas utilization returned to normal: snmpinfo hrProcessorLoad: ========================= Fri Jan 20 12:59:57 EST 2012 bash-3.00# snmpinfo -m dump -v hrprocessorload hrProcessorLoad.1 = 96 hrProcessorLoad.2 = 98 hrProcessorLoad.3 = 98 hrProcessorLoad.4 = 85 bash-3.00# Topas: ====== Fri Jan 20 13:01:54 2012 Interval: 2 Cswitch 710 Readch 23787 Syscall 555 Writech50079 CPU User% Kern% Wait% Idle% Physc Entc Reads 41 Rawin 0 ALL 0.2 0.3 0.0 99.5 0.01 0.7 Writes 6 Ttyout 382 This issue has been reported by customers who upgraded to 5.3 TL12 as well as upgrades to 6.1 TL6 SP3, SP4, SP5 The behavior is specific to shared processor environments and is not seen with dedicated processors.


PTF:  U843215 Fileset:  bos.net.tcp.client.6.1.7.1
APAR:  IV16784 reported against fix pack: 6100-07
Fix available in fixpack:  6100-07-06-1241

snmpinfo hrProcessorLoad metrics are incorrect in a shared processor environment for customer upgrades that include: APAR IZ72006 - HRPROCESSORLOAD DOES NOT MATCH WITH SAR hrProcessorLoad metrics do not match cpu load reported by native AIX tools such as topas, vmstat, mpstat, and sar. In this example, after a cpu spike, snmpinfo hrProcessorLoad remained at almost 100% while topas utilization returned to normal: snmpinfo hrProcessorLoad: ========================= Fri Jan 20 12:59:57 EST 2012 bash-3.00# snmpinfo -m dump -v hrprocessorload hrProcessorLoad.1 = 96 hrProcessorLoad.2 = 98 hrProcessorLoad.3 = 98 hrProcessorLoad.4 = 85 bash-3.00# Topas: ====== Fri Jan 20 13:01:54 2012 Interval: 2 Cswitch 710 Readch 23787 Syscall 555 Writech50079 CPU User% Kern% Wait% Idle% Physc Entc Reads 41 Rawin 0 ALL 0.2 0.3 0.0 99.5 0.01 0.7 Writes 6 Ttyout 382 This issue has been reported by customers who upgraded to 5.3 TL12 as well as upgrades to 6.1 TL6 SP3, SP4, SP5 The behavior is specific to shared processor environments and is not seen with dedicated processors.


PTF:  U841068 Fileset:  bos.net.tcp.client.6.1.7.15
APAR:  IV16784 reported against fix pack: 6100-07-04-1216
Fix available in fixpack:  6100-07-06-1241

snmpinfo hrProcessorLoad metrics are incorrect in a shared processor environment for customer upgrades that include: APAR IZ72006 - HRPROCESSORLOAD DOES NOT MATCH WITH SAR hrProcessorLoad metrics do not match cpu load reported by native AIX tools such as topas, vmstat, mpstat, and sar. In this example, after a cpu spike, snmpinfo hrProcessorLoad remained at almost 100% while topas utilization returned to normal: snmpinfo hrProcessorLoad: ========================= Fri Jan 20 12:59:57 EST 2012 bash-3.00# snmpinfo -m dump -v hrprocessorload hrProcessorLoad.1 = 96 hrProcessorLoad.2 = 98 hrProcessorLoad.3 = 98 hrProcessorLoad.4 = 85 bash-3.00# Topas: ====== Fri Jan 20 13:01:54 2012 Interval: 2 Cswitch 710 Readch 23787 Syscall 555 Writech50079 CPU User% Kern% Wait% Idle% Physc Entc Reads 41 Rawin 0 ALL 0.2 0.3 0.0 99.5 0.01 0.7 Writes 6 Ttyout 382 This issue has been reported by customers who upgraded to 5.3 TL12 as well as upgrades to 6.1 TL6 SP3, SP4, SP5 The behavior is specific to shared processor environments and is not seen with dedicated processors.


Doc number: 2841 Published date: 2012.12.14

[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SWG10","label":"AIX"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"","Edition":"","Line of Business":{"code":"LOB08","label":"Cognitive Systems"}}]

Document Information

Modified date:
14 December 2012

UID

isg1SSRVPOWERAIX61PE20121214