Hi Michael, On Fri, 23 Apr 2010, Michael MacIsaac wrote: > It seemed that the chccwdev command finished asynchronously.
chccwdev does not finish asynchronously. If chccwdev returns the device driver completed its online/offline processing. The problem you try to solve is, that some things are handled by userspace, eg. the creation of device nodes - which is triggered by udev events. If chccwdev returns successfully these udev events have been already delivered to userspace. To be sure that these events are finally processed by udev, you use "udevadm settle". > After the udevadm settle timeout, the events queue contains: > > 415: /devices/css0/0.0.000d/0.0.1100 > 416: /devices/css0/0.0.000d > 423: /devices/css0/0.0.000d > 424: /devices/css0/0.0.000d/0.0.1102 > 427: /devices/css0/0.0.000d/0.0.1102 > 428: /devices/css0/0.0.000d > 431: /devices/css0/0.0.000d > 432: /devices/css0/0.0.000d/0.0.1102 > 435: /devices/css0/0.0.000d/0.0.1102 > 436: /devices/css0/0.0.000d I'm not shure what these are, but it looks like device 1100 was reachable via subchannel 000d and now device 1102 is reachable via subchannel 000d. (just a guess but maybe someone detached the device 1100 from your VM guest) So _if_ device 1100 is currently unreachable (check with "lscss --avail") and a udev script tried to start IO on this device, the device driver will block this IO until the device is reachable again (causing "udevadm settle" to hang or timeout). The blocked IO request will be fulfilled by the device driver if the device is available again. Regards, Sebastian ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
