Re: SLES9 DB2 Restore Problem with 3590 tapes
I have this SuSE version: # uname -a Linux 2.6.5-7.252-s390x #1 SMP Tue Feb 14 11:11:04 UTC 2006 s390x s390x s390x GNU/Linux But I am not sure of which 3590 OCO drive I should have applied. Probably I installed the wrong one. Which driver version is the rightest one for my current SuSE version ? and how can I install it ? I have tried to install tape_3590-sles9-2.6.5-7.236-s390x.tar.gz and then /tmp/tape3590 # depmod -a /tmp/tape3590 # modprobe tape_3590 /lib/modules # lsmod atlas:/lib/modules # lsmod Module Size Used by tape_3590 48648 2 tape 86568 2 tape_3590 tape_class 21512 1 tape sg 68936 0 st 68920 0 ipv6 426664 142 sd_mod 43272 0 sr_mod 39980 0 scsi_mod 206712 4 sg,st,sd_mod,sr_mod cdrom 65320 1 sr_mod qeth 245696 0 qdio 75088 3 qeth ccwgroup 27648 1 qeth dm_mod100120 12 dasd_eckd_mod 89344 60 dasd_mod 103528 61 dasd_eckd_mod ext3 184512 11 jbd 118856 1 ext3 atlas:/lib/modules # Saludos, José R. Barón Dpto. Sistemas CALCULO S. A. Tel. 91 330 86 44 e-mail: [EMAIL PROTECTED] -Mensaje original- De: Linux on 390 Port [mailto:[EMAIL PROTECTED] En nombre de Cornelia Huck Enviado el: viernes, 07 de abril de 2006 9:43 Para: LINUX-390@VM.MARIST.EDU Asunto: Re: SLES9 DB2 Restore Problem with 3590 tapes On Thu, 6 Apr 2006 22:15:19 -0400 Neale Ferguson [EMAIL PROTECTED] wrote: It's not the tape error per se but the code in the kernel. X'' will give you an operation exception and the kernel will throw up its hands and give up. That's the expected behaviour since the code threw a BUG(), which is achieved by on s390 :) It means the tape driver did something strage which the block layer didn't like at all (and since this happened in interrupt context, it caused a kernel panic). Is this the latest tape mod you have for this kernel? I'd second that question. The BUG() may have been caused by a problem in the 3590 driver (or the tape_block driver). Cornelia -- 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 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
Re: SLES9 DB2 Restore Problem with 3590 tapes
On Thu, 6 Apr 2006 22:15:19 -0400 Neale Ferguson [EMAIL PROTECTED] wrote: It's not the tape error per se but the code in the kernel. X'' will give you an operation exception and the kernel will throw up its hands and give up. That's the expected behaviour since the code threw a BUG(), which is achieved by on s390 :) It means the tape driver did something strage which the block layer didn't like at all (and since this happened in interrupt context, it caused a kernel panic). Is this the latest tape mod you have for this kernel? I'd second that question. The BUG() may have been caused by a problem in the 3590 driver (or the tape_block driver). Cornelia -- 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
Re: SLES9 DB2 Restore Problem with 3590 tapes
On Thu, Apr 06, 2006 at 11:15:19PM -0400, Neale Ferguson wrote: From the console log: Krnl Code: 00 00 b9 04 00 2b b9 04 00 3c c0 e5 ff ff e9 61 e3 30 b1 18 It's not the tape error per se but the code in the kernel. X'' will give you an operation exception and the kernel will throw up its hands and give up. Is this the latest tape mod you have for this kernel? Is that bit of storage being overwritten (use #CP D R282170.10 to see if the storage has that value when the system is IPL'd)? If it's not zeroes then, as you are running under VM try: #CP TR STOR INTO 282178 And see is anything is storing zeroes there. Not needed. It's an intentional illegal opcode generated by a BUG(...) statement in the kernel code that is not supposed to be reached. Looks like a bug in the 3590 code. Heiko -- 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
Re: SLES9 DB2 Restore Problem with 3590 tapes
The cause for the crash was the BUG() statement in ll_rw_blk.c (if you have the sources installed you could look there what was the problem there). Seems something in the tape block device didn't go too well. But first of all. Is it really intentional to use the block device at all? Why not using /dev/rtibm* for the restore? The problem itself doesn't seem to be tied to the 3590 but to the tape block device (which was originally intended to ro-mount an iso-image on tape). Regards, Stefan Bader SW Linux on zSeries Development Services [EMAIL PROTECTED] -- When all other means of communication fail, try words. Linux on 390 Port LINUX-390@VM.MARIST.EDU wrote on 07.04.2006 00:39:24: Hi, all. I am currently trying to restore a DB2 backup copy I had done into 3590 tape. I proceeded like this: BACKUP == - modprobe tape_3590 - chccwdev -e 0.0.0800 - mt -f /dev/rtibm0 setblk 2048 - chmod +777 /dev/rtibm0 - db2 backup db lnxr89 to /dev/rtibm0 compress RESTORE === - Executed pedro.sh (a restore script) - It executed fine until the db2 restore itself. Then, after 30-40 minutes of successful execution it suddenly got cancelled. It wasn't just a restore cancelation, not even a DB2 cancellation but a WHOLE-LINUX-CANCELLATION All because of a tape error How can it be ??? What am I doing wrong ? I am enclosing the LINUX console for more information. HELP Please !! brgds, José R. Barón Dpto. Sistemas CALCULO S. A. Tel. 91 330 86 44 e-mail: [EMAIL PROTECTED] -- 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 [attachment casque.txt deleted by Stefan Bader/Germany/IBM] [attachment pedro script.txt deleted by Stefan Bader/Germany/IBM] -- 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
Re: SLES9 DB2 Restore Problem with 3590 tapes
Hi Jose, I am not familiar to the DB2 backup process, but what looks strange to me, is that the db2 restore seems to use the tape blockdevice (/dev/btibm0). Is the backup really written as an ISO 9660 file to the tape and is the tape mounted as a blockdevice afterwards for db2 restore? If not, /dev/btibm0 is the wrong device to use in the pedro script. It should be /dev/rtibm0 or /dev/ntibm0. Michael Linux for E-Server Development Phone: +49-7031-16-2360, Bld 71032-03-U09 Email: [EMAIL PROTECTED] Jose Raul Baron [EMAIL PROTECTED] Sent by: Linux on 390 Port LINUX-390@VM.MARIST.EDU 07.04.2006 00:39 Please respond to Linux on 390 Port LINUX-390@VM.MARIST.EDU To LINUX-390@VM.MARIST.EDU cc Subject SLES9 DB2 Restore Problem with 3590 tapes Hi, all. I am currently trying to restore a DB2 backup copy I had done into 3590 tape. I proceeded like this: BACKUP == - modprobe tape_3590 - chccwdev -e 0.0.0800 - mt -f /dev/rtibm0 setblk 2048 - chmod +777 /dev/rtibm0 - db2 backup db lnxr89 to /dev/rtibm0 compress RESTORE === - Executed pedro.sh (a restore script) - It executed fine until the db2 restore itself. Then, after 30-40 minutes of successful execution it suddenly got cancelled. It wasn't just a restore cancelation, not even a DB2 cancellation but a WHOLE-LINUX-CANCELLATION All because of a tape error How can it be ??? What am I doing wrong ? I am enclosing the LINUX console for more information. HELP Please !! brgds, José R. Barón Dpto. Sistemas CALCULO S. A. Tel. 91 330 86 44 e-mail: [EMAIL PROTECTED] -- 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 [attachment casque.txt deleted by Michael Holzheu/Germany/IBM] [attachment pedro script.txt deleted by Michael Holzheu/Germany/IBM] -- 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
SLES9 DB2 Restore Problem with 3590 tapes
Hi, all. I am currently trying to restore a DB2 backup copy I had done into 3590 tape. I proceeded like this: BACKUP == - modprobe tape_3590 - chccwdev -e 0.0.0800 - mt -f /dev/rtibm0 setblk 2048 - chmod +777 /dev/rtibm0 - db2 backup db lnxr89 to /dev/rtibm0 compress RESTORE === - Executed pedro.sh (a restore script) - It executed fine until the db2 restore itself. Then, after 30-40 minutes of successful execution it suddenly got cancelled. It wasn't just a restore cancelation, not even a DB2 cancellation but a WHOLE-LINUX-CANCELLATION All because of a tape error How can it be ??? What am I doing wrong ? I am enclosing the LINUX console for more information. HELP Please !! brgds, José R. Barón Dpto. Sistemas CALCULO S. A. Tel. 91 330 86 44 e-mail: [EMAIL PROTECTED] -- 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 == El disco de arranque es el 151 Deseas hacer IPL (S/N) ? == s Booting default (ipl)... Linux version 2.6.5-7.252-s390x ([EMAIL PROTECTED]) (gcc version 3.3.3 (SuSE Linux)) ¥1 SMP Tue Feb 14 11:11:04 UTC 2006 We are running under VM (64 bit mode) On node 0 totalpages: 1572864 DMA zone: 524288 pages, LIFO batch:31 Normal zone: 1048576 pages, LIFO batch:31 HighMem zone: 0 pages, LIFO batch:1 Built 1 zonelists Kernel command line: dasd=150-151,2CD-2D2,2D7-2DC,2E1-2E6,2E9-2EA,2EE-2F5 root=/dev/dasdb1 selinux=0 TERM=dumb elevator=cfq BOOT_IMA GE=0 PID hash table entries: 4096 (order 12: 65536 bytes) CKRM Initialization .. Initializing ClassTypetaskclass .. Initializing ClassTypesocketclass CKRM Initialization done Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes) Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes) Memory: 6170368k/6291456k available (3457k kernel code, 0k reserved, 1074k data, 116k init) Security Scaffold v1.0.0 initialized SELinux: Disabled at boot. Mount-cache hash table entries: 256 (order: 0, 4096 bytes) Detected 1 CPU's Boot cpu address 1 cpu 0 phys_idx=1 vers=FF ident=11 machine=2086 unused=8000 Brought up 1 CPUs checking if image is initramfs... it isn't (no cpio magic); looks like an initrd Freeing initrd memory: 1622k freed khelper: max 64 concurrent processes debug: Initialization complete resid is -1 name is io NULL CKRM .. create res clsobj for resouce ioclass taskclass par= NET: Registered protocol family 16 VFS: Disk quotas dquot_6.5.1 Initializing Cryptographic API RAMDISK driver initialized: 16 RAM disks of 32768K size 1024 blocksize loop: loaded (max 8 devices) md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27 Channel measurement facility using extended format (autodetected) NET: Registered protocol family 2 IP: routing cache hash table of 32768 buckets, 512Kbytes TCP established hash table entries: 131072 (order: 9, 3145728 bytes) TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) TCP: Hash tables configured (established 131072 bind 65536) NET: Registered protocol family 1 resid is -1 name is cpu NULL CKRM .. create res clsobj for resouce cpuclass taskclass par= init_ckrm_sched_res , resid= 5 md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE. RAMDISK: Compressed image found at block 0 VFS: Mounted root (ext2 filesystem). Starting udev Creating devices Loading kernel/fs/jbd/jbd.ko Loading kernel/fs/ext3/ext3.ko Loading kernel/drivers/s390/block/dasd_mod.ko dasd=150-151,2CD-2D2,2D7-2DC,2E1-2 E6,2E9-2EA,2EE-2F5 Loading kernel/drivers/s390/block/dasd_eckd_mod.ko dasd(eckd): 0.0.02cd: 3390/0C(CU:3990/04) Cyl:10017 Head:15 Sec:224 Using cfq io scheduler dasd(eckd): 0.0.02cd: (4kB blks): 7212240kB at 48kB/trk compatible disk layout dasdc:VOL1/ 0X02CD: dasdc1 dasd(eckd): 0.0.02ce: 3390/0C(CU:3990/04) Cyl:10017 Head:15 Sec:224 dasd(eckd): 0.0.02ce: (4kB blks): 7212240kB at 48kB/trk compatible disk layout dasdd:VOL1/ 0X02CE: dasdd1 dasd(eckd): 0.0.02cf: 3390/0C(CU:3990/04) Cyl:10017 Head:15 Sec:224 dasd(eckd): 0.0.02cf: (4kB blks): 7212240kB at 48kB/trk compatible disk layout dasde:VOL1/ 0X02CF: dasde1 dasd(eckd): 0.0.02d0: 3390/0C(CU:3990/04) Cyl:10017 Head:15 Sec:224 dasd(eckd): 0.0.02d0: (4kB blks): 7212240kB at 48kB/trk compatible disk layout dasdf:VOL1/ 0X02D0: dasdf1 dasd(eckd): 0.0.02d1: 3390/0C(CU:3990/04) Cyl:10017 Head:15 Sec:224 dasd(eckd): 0.0.02d1: (4kB blks): 7212240kB at 48kB/trk compatible disk layout dasdg:VOL1/ 0X02D1: dasdg1 dasd(eckd): 0.0.02d2: 3390/0C(CU:3990/04) Cyl:10017 Head:15 Sec:224 dasd(eckd): 0.0.02d2: (4kB blks): 7212240kB at 48kB/trk compatible disk layout dasdh:VOL1/ 0X02D2: dasdh1 dasd(eckd): 0.0.02d7: 3390/0C(CU:3990/04) Cyl:10017 Head:15 Sec:224 dasd(eckd):
Re: SLES9 DB2 Restore Problem with 3590 tapes
From the console log: Krnl Code: 00 00 b9 04 00 2b b9 04 00 3c c0 e5 ff ff e9 61 e3 30 b1 18 It's not the tape error per se but the code in the kernel. X'' will give you an operation exception and the kernel will throw up its hands and give up. Is this the latest tape mod you have for this kernel? Is that bit of storage being overwritten (use #CP D R282170.10 to see if the storage has that value when the system is IPL'd)? If it's not zeroes then, as you are running under VM try: #CP TR STOR INTO 282178 And see is anything is storing zeroes there. -Original Message- Hi, all. I am currently trying to restore a DB2 backup copy I had done into 3590 tape. -- 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
