Mike Christie schrieb:

> The scsi layer sets a timeout on each command. If it does not execute in 
> X seconds, it will run the iscsi eh.
> So you can increase the scsi command time:
> To modify the udev rule open /etc/udev/rules.d/50-udev.rules, and find the
> following lines:
> ACTION=="add", SUBSYSTEM=="scsi" , SYSFS{type}=="0|7|14", \
>          RUN+="/bin/sh -c 'echo 60 > /sys$$DEVPATH/timeout'"
> and you probably want to decrease the number of oustanding commands by 
> setting the node.session.cmds_max for that session. With 50 kB/s you 
> might as well set this to 1 command.

This helps a bit, but after some time, something weird happens.

I increased the timeout to 240 seconds.

The data flows fine for some time, but after a couple of minutes, every
program running on that initiator machine seems to freeze (i.e. "ping"
stops to ping, "top" stops to refresh the data, they can't be
interrupted / won't exit with ctrl+c).
There is no traffic any more between the target and the initiator.

The machine is "a bit" alive, as it replies to pings and responds to
sysrq magic, and I can switch VTs (ctrl+alt+F1...).

The machine has its root filesystem accessible via iSCSI (via fast LAN,
to a different target) which can somehow contribute to the problem? It 
runs a 2.6.22 kernel.
Some bad interaction if the initiator is connected to two targets with
different IPs, and connection to one target is very slow?

No such phenomenon on a machine with rootfs on SATA, where everything
works fine.

Tomasz Chmielewski

You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to 
For more options, visit this group at http://groups.google.com/group/open-iscsi

Reply via email to