Ashutosh Naik wrote:This happens when we cannot reach the target for the noop timout and interval seconds, which can happen if a cable is unplugged or the network is not reach able or is dropping packets. However, once it happens we should not report it again like is done here. There is something weird there. Do you have the iscsid output? Between these two reports of pings timing out is there any messages from iscsid about reconnecting? And we should not get here. The iscsi driver's scsi command timeout handler should prevent the command from firing the scsi eh, because in this case we think it is a transport problem. What version of the iscsi tools are you using? Are they from a distro or open-iscsi.org? Are you running with the iscsi kernel modules from 2.6.25.6, or are you using the iscsi modules from the open-iscsi.org website that come with the tarball? Is the kernel a unmodified 2.6.25.6 or does it have some distro patches or patches that you have created? I think you get this message and what follows, is a result of the above problem. While the iscsi initiator is trying to reconnect, IO is queued by the scsi layer so fdisk is going to be waiting around until we recover or give up. --
| Ingo Molnar | Re: containers (was Re: -mm merge plans for 2.6.23) |
| Greg Kroah-Hartman | [PATCH 009/196] Chinese: add translation of sparse.txt |
| holzheu | Re: [RFC/PATCH] Documentation of kernel messages |
| Vladislav Bolkhovitin | Re: Integration of SCST in the mainstream Linux kernel |
git: | |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | [GIT]: Networking |
| Antonio Almeida | HTB accuracy for high speed |
