Red Hat Bugzilla – Bug 76677
flaky ctc connection trying to install
Last modified: 2007-04-18 12:47:55 EDT
* reported by eval-customer * using 7.1-s390x product (64-bit) * install to guest client using z/VM v 4.3 customer tries to isntall over virtual ctc connection, after initial success (starting loader and xferring stage2 files), the ctc connection appears to die according to the z/VM tcp stack ... the ctc connection does not appear to be down to the linux ctc0 interface, but no data is transferred back ... some information from the linux install environment: cat /proc/chandev chan_type key bitfield ctc=0x1,escon=0x2,lcs=0x4,osad=0x8,qeth=0x10,claw=0x20 *'s for cu/dev type/models indicate don't cares cautious_auto_detect: on persist = 0x00 use_devno_names: off Channels enabled for detection chan cu cu dev dev max checksum use hw auto recovery type type model type model port_no. received stats type ============================================================================== 0x20 0x3088 0x61 * * 0 no no not_operational,no_path,revalidate,device_gone 0x08 0x3088 0x62 * * 0 no no not_operational,no_path,revalidate,device_gone 0x10 0x1731 0x05 0x1732 0x05 0 no no not_operational,no_path,revalidate,device_gone 0x10 0x1731 0x01 0x1732 0x01 0 no no not_operational,no_path,revalidate,device_gone 0x04 0x3088 0x60 * * 1 no no not_operational,no_path,revalidate,device_gone 0x06 0x3088 0x1f * * 15 no no not_operational,no_path,revalidate,device_gone 0x05 0x3088 0x08 * * 15 no no not_operational,no_path,revalidate,device_gone 0x04 0x3088 0x01 * * 15 no no not_operational,no_path,revalidate,device_gone Forced devices chan defif read write data memory port ip hw host adapter api type num devno devno devno usage(k) protocol no. chksum stats name name name =============================================================================================== 0x01 0 0xc000 0xc001 0x0000 default 0 0 0 Registered probe functions probefunc shutdownfunc msck_notfunc chan devices devices type found active ================================================================================== 0x00000000048096b0 0x0000000004809214 0x000000000480945c 0x03 1 1 Initialised Devices read write data read write data chan port dev dev memory read msck write msck data msck irq irq irq devno devno devno type no. ptr name usage(k) status status status ===================================================================================================================== 0x0000 0x0001 n/a 0xc000 0xc001 n/a 0x01 0 0x0000000003d49c00 ctc0 n/a good good not applicable Total device memory usage 0k. channels detected chan cu cu dev dev in chandev irq devno type type model type model pim chpids use reg. =============================================================================== 0x0000 0xc000 0x05 0x3088 0x08 0x0000 0x00 0x80 0x0000000000000000 yes yes 0x0001 0xc001 0x05 0x3088 0x08 0x0000 0x00 0x80 0x0000000000000000 yes yes sh-2.05# cat /proc/modules raid5 25684 0 (unused) xor 4344 0 raid5C raid1 17412 0 (unused) raid0 4928 0 (unused) loop 13992 2 cramfs 108756 1 ext3 81272 0 (unused) jbd 55296 0 ext3C dasd_eckd_mod 61256 0 dasd_mod 51224 1 dasd_eckd_modC ctc 67656 1 sh-2.05#
not able to reproduce the problem here locally ... will reopen if more information is provided ...
I'm pretty sure it's still there, but the renumbering of guests made it less obvious. Now it takes just one retry to reconnect on boot (2.4.9 connects without retries).