You have to do all steps successfully:
umount
chccwdev -d
vmcp det

otherwise the disk is stuck in some state 'in the middle'

/Tore 


___________________________________________
Tore Agblad
Volvo Information Technology
Infrastructure Mainframe Design & Development, Linux servers
Dept 4352  DA1S 
SE-405 08, Gothenburg  Sweden

Telephone: +46-31-3233569
E-mail: [email protected]

http://www.volvo.com/volvoit/global/en-gb/

-----Original Message-----
From: Linux on 390 Port [mailto:[email protected]] On Behalf Of Florian 
Bilek
Sent: den 22 november 2010 19:11
To: [email protected]
Subject: Problems with DASD driver on SLES 11 SP1?

Dear all

Since some weeks I am facing some weird problem with SLES 11 SP1. I am on
the current patch level with that image (I hope), the kernel is:

# uname -a
Linux sles11 2.6.32.24-0.2-default #1 SMP 2010-10-29 16:39:49 +0200 s390x
s390x s390x GNU/Linux

I use that guest for cloning purposes and because of that I am very often
attaching and detaching MINIDISKS, doing formatting, copying etc.

1. problem:

I link a minidisk from another guest which is surely down via the vmcp link
command and then do a chccwdev -e.

vmcp link clonset7 201 7201 w
chccwdev -e 0.0.7201

I see with lsdasd that this device is active.

lsdasd
Bus-ID     Status      Name      Device  Type  BlkSz  Size      Blocks
==============================================================================
0.0.0201   active      dasda     94:0    ECKD  4096   7043MB    1803060
0.0.0203   active      dasdb     94:4    ECKD  4096   7043MB    1803060
0.0.0400   active      dasdc     94:8    ECKD  4096   892MB     228600
0.0.7201   active      dasdd     94:12   ECKD  4096   1573MB    402840

So far so good. Now I am going to change that device 7201 offline and detach
it from the linux guest.

lsdasd shows that the device is gone and I also don't have any item in
/sys/bus/ccw/devices

Next is that I link that device again in r/o mode:
vmcp link clonset7 201 7201 r
chccwdev -e 0.0.7201

and lsdasd shows

# lsdasd
Bus-ID     Status      Name      Device  Type  BlkSz  Size      Blocks
==============================================================================
0.0.0201   active      dasda     94:0    ECKD  4096   7043MB    1803060
0.0.0203   active      dasdb     94:4    ECKD  4096   7043MB    1803060
0.0.0400   active      dasdc     94:8    ECKD  4096   892MB     228600
0.0.7201   active(ro)  dasdd     94:12   ECKD  4096   1573MB    402840

which is also still correct.

Now the problem comes: When I detach again the device and re-link it again
in r/w mode, the flag that the device is r/o still remains.

I don't know how that comes but when I do a vmcp q v dasd that device is
shown as R/W from CP side.

I think that might be a bug since I don't see why is behaves like that.


2. Problem:

Because I lack the FLASHCOPY function I use for disk to disk copy dd.

dd bs=4096 if=/dev/dasdx of=/dev/dasdy

In principle it works ok. But when I do a chccwdev -d 0.0.xxxx even with an
udevadm settle --timeout=20 afterwards,
the file system gets corrupted, when I attach it to another guest.

I am really lost since all that was working well under SLES 10 SP2. I would
really like to know if someone had similar experience in SLES 11 SP1.

Thank you in advance.

Kind regards,

Florian

----------------------------------------------------------------------
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
----------------------------------------------------------------------
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

----------------------------------------------------------------------
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
----------------------------------------------------------------------
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Reply via email to