Re: circular dependency pdat allocation
On Tuesday, 06/09/2015 at 09:27 EDT, "Dean, David (I/S)" wrote: > Anyway, I was then able to IPL this server 4 times successfully. > But the darned thing has been running for several years. I will see at 3 AM > tonight. Sometimes the glue that hold the bits together into bytes gets brittle with age and some of the bits fall off. You have to glue them back on. Use a glue that remains flexible over a wide temperature range and pH. (What other explanation can there be? Sunspots? I don't think so, Tim..) -- Chuckie -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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/
Re: circular dependency pdat allocation
Thanks, the system was restored because it would not come up - disabled wait. When we restored, life was good. At night this server runs a TSM backup at 2AM and then reboots itself, normally successfully. Last night I ran linux repair and rewrote the bootloader and changed zipl.conf and ran zipl. the zipl change was zipl was pointing to boot files through links, not direct. I changed that. Anyway, I was then able to IPL this server 4 times successfully. But the darned thing has been running for several years. I will see at 3 AM tonight. Thank you. -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Mark Post Sent: Tuesday, June 09, 2015 8:57 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: circular dependency pdat allocation >>> On 6/9/2015 at 06:21 AM, "Dean, David (I/S)" wrote: > I am clueless. Can someone tell me what this means. It just started > on a previously working server SUSE 11.3 zvm 6.3 > > Yesterday we restored the DASD backups and it came back up. Now it > has done it again. Was the system restored from backup because of this message coming out? Or some other reason? > setup.1a06a7: Linux is running as a z/VM guest operating system in > 64-bit mode This message is completely normal, so we'll ignore that. > Section 8 and 0 (node 0) have a circular dependency on usemap and > pgdat allocations This message seems to be related to the kernel feature that allows "hot remove" of memory from a system. It's informational only. It's in a module that deals with "sparse memory mappings." The comments just before the print statements say this: * There is a circular dependency. * Some platforms allow un-removable section because they will just * gather other removable sections for dynamic partitioning. * Just notify un-removable section's number here. Unless you're having real problems of some kind with the system, I'd say you can ignore it. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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/ -- Please see the following link for the BlueCross BlueShield of Tennessee E-mail disclaimer: http://www.bcbst.com/email_disclaimer.shtm -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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/
Re: circular dependency pdat allocation
>>> On 6/9/2015 at 06:21 AM, "Dean, David (I/S)" wrote: > I am clueless. Can someone tell me what this means. It just started on a > previously working server SUSE 11.3 zvm 6.3 > > Yesterday we restored the DASD backups and it came back up. Now it has done > it again. Was the system restored from backup because of this message coming out? Or some other reason? > setup.1a06a7: Linux is running as a z/VM guest operating system in 64-bit > mode This message is completely normal, so we'll ignore that. > Section 8 and 0 (node 0) have a circular dependency on usemap and pgdat > allocations This message seems to be related to the kernel feature that allows "hot remove" of memory from a system. It's informational only. It's in a module that deals with "sparse memory mappings." The comments just before the print statements say this: * There is a circular dependency. * Some platforms allow un-removable section because they will just * gather other removable sections for dynamic partitioning. * Just notify un-removable section's number here. Unless you're having real problems of some kind with the system, I'd say you can ignore it. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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/
circular dependency pdat allocation
I am clueless. Can someone tell me what this means. It just started on a previously working server SUSE 11.3 zvm 6.3 Yesterday we restored the DASD backups and it came back up. Now it has done it again. setup.1a06a7: Linux is running as a z/VM guest operating system in 64-bit mode Section 8 and 0 (node 0) have a circular dependency on usemap and pgdat allocati ons Zone PFN ranges: DMA 0x -> 0x0008 Normal 0x0008 -> 0x0028 -- Please see the following link for the BlueCross BlueShield of Tennessee E-mail disclaimer: http://www.bcbst.com/email_disclaimer.shtm -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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/
[no subject]
On 06/09/2015 09:22 AM, Mainframe Mainframe wrote: Hello Group, Currently we facing below issue. *Issue : * /scratch is on dasda1 device. We need mount sda device on /scratch so that we can do porting work. Steps taken to solve issue : # umount -l /scratch This seems to be a lazy unmount, so you don't know when this mount point will be truely unmounted properly. # fsck -y /scratch fsck 1.39 (29-May-2006) e2fsck 1.39 (29-May-2006) fsck.ext3: Attempt to read block from filesystem resulted in short read while trying to open /dev/sda1 Could this be a zero-length partition? Maybe due to the lazy unmount, /scratch might be in some intermediate state or now even already belong to containing the root-fs(!), so calling fsck on that mount point seems dangerous. A safe procedure might be to unmount without lazy option and then fsck the block device that used to be mounted on /scratch, i.e. /dev/dasda1. *cat /etc/fstab* LABEL=/ / ext3 defaults,usrquota,grpquota1 1 tmpfs /dev/shmtmpfs size=8045M0 0 devpts /dev/ptsdevpts gid=5,mode=620 0 0 sysfs /syssysfs defaults0 0 proc/proc procdefaults0 0 /dev/sda1/scratch ext3 defaults 1 0 *We changed * /dev/sda1/scratch ext3 defaults 1 0 to /dev/sda1/scratch ext3 defaults 1 2 You should always use multipathing instead of single path SCSI devices, otherwise you lack path redundancy. How do you ensure that all the paths to this SCSI disk are persistently configured? (SCSI devices don't appear fully automatically without any user action with Linux on z Systems.) In other words, it could have been that there is no /dev/sda at all during fsck time on boot. http://www-05.ibm.com/de/events/linux-on-z/pdf/day2/4_Steffen_Maier_zfcp-best-practices-2015.pdf *So, that fsck run on reboot time and we rebooted system and after reboot I was getting below messages.* Checking all file systems. -/sbin/fsck.ext3 (1) -- /- fsck.ext3 -a /dev/dasda1 /: clean, 177325/5412928 files, 1517520/5408976 blocks -/sbin/fsck.ext3 (1) -- /scratch- fsck.ext3 -a /dev/sda1 fsck.ext3: No such file or directory while trying to open /dev/sda1 /dev/sda1: The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 -FAILED- *** An error occurred during the file system check. *** Dropping you to a shell; the system will reboot *** when you leave the shell. Give root password for maintenance e2fsck -b 8193 Usage: e2fsck --panyrcdfvstDFSV- --b superblock- --B blocksize- --I inode_buffer_blocks- --P process_inode_size- --l|-L bad_blocks_file- --C fd- --j external_journal- --E extended-options- device Emergency help: -p Automatic repair (no questions) -n Make no changes to the filesystem -y Assume "yes" to all questions -c Check for bad blocks and add them to the badblock list -f Force checking even if filesystem is marked clean -v Be verbose -b superblockUse alternative superblock -B blocksize Force blocksize when looking for superblock -j external_journal Set location of the external journal -l bad_blocks_file Add to badblocks list -L bad_blocks_file Set badblocks list (Repair filesystem) 2 # Any solution of this issue. -- Mit freundlichen Grüßen / Kind regards Steffen Maier Linux on System z Development IBM Deutschland Research & Development GmbH Vorsitzende des Aufsichtsrats: Martina Koederitz Geschaeftsfuehrung: Dirk Wittkopp Sitz der Gesellschaft: Boeblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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/
[no subject]
Hello Group, Currently we facing below issue. *Issue : * /scratch is on dasda1 device. We need mount sda device on /scratch so that we can do porting work. Steps taken to solve issue : # umount -l /scratch # fsck -y /scratch fsck 1.39 (29-May-2006) e2fsck 1.39 (29-May-2006) fsck.ext3: Attempt to read block from filesystem resulted in short read while trying to open /dev/sda1 Could this be a zero-length partition? *cat /etc/fstab* LABEL=/ / ext3 defaults,usrquota,grpquota1 1 tmpfs /dev/shmtmpfs size=8045M0 0 devpts /dev/ptsdevpts gid=5,mode=620 0 0 sysfs /syssysfs defaults0 0 proc/proc procdefaults0 0 /dev/sda1/scratch ext3 defaults 1 0 *We changed * /dev/sda1/scratch ext3 defaults 1 0 to /dev/sda1/scratch ext3 defaults 1 2 *So, that fsck run on reboot time and we rebooted system and after reboot I was getting below messages.* Checking all file systems. -/sbin/fsck.ext3 (1) -- /- fsck.ext3 -a /dev/dasda1 /: clean, 177325/5412928 files, 1517520/5408976 blocks -/sbin/fsck.ext3 (1) -- /scratch- fsck.ext3 -a /dev/sda1 fsck.ext3: No such file or directory while trying to open /dev/sda1 /dev/sda1: The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 -FAILED- *** An error occurred during the file system check. *** Dropping you to a shell; the system will reboot *** when you leave the shell. Give root password for maintenance e2fsck -b 8193 Usage: e2fsck --panyrcdfvstDFSV- --b superblock- --B blocksize- --I inode_buffer_blocks- --P process_inode_size- --l|-L bad_blocks_file- --C fd- --j external_journal- --E extended-options- device Emergency help: -p Automatic repair (no questions) -n Make no changes to the filesystem -y Assume "yes" to all questions -c Check for bad blocks and add them to the badblock list -f Force checking even if filesystem is marked clean -v Be verbose -b superblockUse alternative superblock -B blocksize Force blocksize when looking for superblock -j external_journal Set location of the external journal -l bad_blocks_file Add to badblocks list -L bad_blocks_file Set badblocks list (Repair filesystem) 2 # Any solution of this issue. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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/
