PROBLEM: (ZPOB82799) (Patch ID: OSF410-031) ******** This fixes a problem where a hang occurs on an AdvFS filesystem. This problem occurs when a thread is looping in routine "cleanup_closed_list". Sample stack after forced crash: stop_secondary_cpu() panic("cpu_ip_intr: panic request") cpu_ip_intr() _XentInt() cleanup_closed_list() fs_cleanup_thread() PROBLEM: (GOZ100505) (Patch ID: OSF410-400105) ******** A system will panic with the panic string "simple_lock: time limit exceeded". The stack trace of the panicing process is as follows: panic("simple_lock: time limit exceeded") simple_lock_fault() simple_lock_time_violation() msfs_getpage() u_seg_fault() u_map_fault() vm_fault() trap() _XentMM() PROBLEM: (QAR 50227) (Patch ID: OSF410-400148) ******** This patch fixes an "ADVFS EXCEPTION" panic after an "advfs I/O error" message to the console. The traceback of the panic thread will be as follows: panic() advfs_sad() ftx_fail_2() ftx_fail() fs_write() msfs_write() vn_write() rwuio() write() syscall() _Xsyscall(). PROBLEM: (HPAQ92E5E) (Patch ID: OSF410-400125) ******** The system is hung while running vdump and there is a thread with the following signature (note: this is _NOT_ the vdump thread): 0 imm_get_next_xtnt_desc() [../../../../src/kernel/msfs/bs/bs_inmem_map.c] 1 imm_merge_xtnt_map() [../../../../src/kernel/msfs/bs/bs_inmem_map.c] PROBLEM: (HPXQ42587, QAR 46237) (Patch ID: OSF410-400176) ******** On an AdvFS system, a broadcast message will cause the idle time to be reset to zero. (Patch ID: OSF410-400176-1) PROBLEM: (QAR 36779) (Patch ID: OSF410-400298-1 reference information) ******** This patch fixes a problem that occurs when running the NetWorker Version 4.2c application. The NetWorker application is unable to reset the atime (access time) attribute on files being accessed. No errors or warnings are displayed. Without this patch, NetWorker Version 4.2c will not perform well. PROBLEM: (TKTR71564, QAR 36411) (Patch ID: OSF410-400217) ******** Systems running with AdvFS and LSM under heavy I/O loads can have sluggish interactive performance. In a DECsafe environment, these systems can encounter unexpected relocation of services. PROBLEM: (HPXQ43C4D, TKTR52185, QAR 46016) (Patch ID: OSF410-400217) ******** A system can hang after the message "syncing disks..." prints during a panic. When a hang occurs, the "syncing disks..." message does not print entirely and the system does not take a dump. A time-out mechanism was added to the "syncing disks" logic. This mechanism improves the reliability of getting a dump by using the system clock to break out of the "syncing disks" path and take a dump if no progress is being made on reducing the number of buffers to be flushed. The numbers printed periodically between the "syncing disks..." and "done" messages are the number of buffers left to flush. PROBLEM: (MGO102584) (Patch ID: OSF410-400228) ******** This patch fixes AdvFS to prevent the following two panics: AdvFS Exception Module = 1, line = 1891 kernel memory fault with the following stack trace: _XentMM() bs_refpg_int() bs_refpg() tagdir_get_info() bs_bfdmn_activate() bs_bfdmn_tbl_activate() fs_fset_get_info() msfs_real_syscall() msfs_syscall() syscall() _Xsyscall() PROBLEM: (QAR 45580) (Patch ID: OSF410-400239B) ******** Multithreaded applications that call the pthread_mutex_destroy routine may fail when there are no threads referencing the mutex. This is caused by a race condition inside the pthread_mutex_unlock code. The typical symptom will be a return value of EBUSY from pthread_mutex_destroy. Due to the pthreads fix vdump and vrestore need to be redistributed. PROBLEM: (QAR 51304, QAR 51596) (Patch ID: OSF410-400231-1) ******** This patch fixes two problems that occur on AdvFS systems: An AdvFS data corruption problem can occur in user files. This problem occurs when AdvFS stores two different versions of a particular page (an 8K segment). This problem will not produce either a core file or a return non-zero system codes when accessing the corrupted file. The verify command will not detect the corrupted file. This patch provides the following: 1. The OS is corrected to prevent any new files from being corrupted. 2. The verify program now recognizes data corruptions. 3. The verify -f command detects the corruption and moves the file into a temporary file. Another temporary file is created to show the contents of the corresponding "visible" page. These files are then available for analysis by the user for the purpose of manually repairing the corruption. The following is an example of a recovery procedure. To detect a corrupted file: Run the verify utility, which resides in /sbin/advfs. # verify test_domain ^^+ Domain verification ^^+ Domain Id 32d3e638.000a46a0 Checking disks ... Checking storage allocated on disk /dev/rz1a Checking mcell list ... Checking mcell position field ... Checking tag directories ... ^^+ Fileset verification ^^+ ^^+ Fileset test_fileset ^^+ Checking frag file headers ... Checking frag file type lists ... Scanning directories and files ... Overlapping frag data corruption detected in: File: /50226.file.4 Page: 1 Run verify -f on this domain to enable recovery of this data. Scanning tags ... Searching for lost files ... # The verify utility has detected a corrupted file in fileset test_fileset. The name of the file is "50226.file.4" and it is located in the highest directory of the fileset when it is mounted. The page that is corrupted is page 1. Verify also suggests running verify again using the -f flag to enable recovery of the hidden data for page 1. At this point there are two choices: 1. Delete the file and recreate it. The corruption problem has been fixed on the system. The newly created file will not exhibit the undesired behavior. 2. Run verify with the -f flag to identify the corrupted data. To identify the corrupted data: Run the verify command with the -f flag. # verify -f test_domain ^^+ Domain verification ^^+ Domain Id 32d3e638.000a46a0 Checking disks ... Checking storage allocated on disk /dev/rz1a Checking mcell list ... Checking mcell position field ... Checking tag directories ... ^^+ Fileset verification ^^+ ^^+ Fileset test_fileset ^^+ Checking frag file headers ... Checking frag file type lists ... Scanning directories and files ... Overlapping frag data corruption detected in: File: /50226.file.4 Page: 1 Temporary files created representing the two versions of page 1 of file /50226.file.4 Refer to the README file accompanying the patch for a description of how to use these temporary files to recover from this overlapping frag corruption problem. Scanning tags ... Searching for lost files ... # The verify utility reports that it has created two temporary files in the same directory as the corrupted file. Mount the fileset to indentify these two files: # mount test_domain#test_fileset /test # ls -l /test total 169 drwx------ 2 root system 8192 Jan 8 13:23 .tags -rw-r--r-- 1 root system 24576 Jan 9 12:27 50226.file.1 -rw-r--r-- 1 root system 40960 Jan 9 12:27 50226.file.2 -rw-r--r-- 1 root system 32768 Jan 9 12:27 50226.file.3 -rw-r--r-- 1 root system 24576 Jan 9 12:27 50226.file.4 -rw------- 1 root system 8192 Jan 13 14:32 50226.file.4.page_1.ext -rw------- 1 root system 8192 Jan 13 14:32 50226.file.4.page_1.frag -rw-r----- 1 root operator 8192 Jan 8 13:23 quota.group -rw-r----- 1 root operator 8192 Jan 8 13:23 quota.user The .ext and .frag files contain information from the corrupted area. In the example above: 50226.file.4 The original corrupted file 50226.file.4.page_1.ext A file containing the hidden version of page 1 of the corrupted file. A read() cannot retrieve this data. 50226.file.4.page_1.frag A file containing the frag version of page 1 of the corrupted file. This is the same data that a read() of page 1 would return. To fix the corrupted file: 1. View the .ext and .frag files to determine which to keep. Note that what might really be desired is a merge of the two. If the file 50226.file.4.page_1.ext contains the desired data, enter: # ln -s 50226.file.4.page_1.ext desired_page_1 If the file 50226.file.4.page_1.frag contains the desired data, enter: # ln -s 50226.file.4.page_1.frag desired_page_1 If a merge of the two must be done, do the merge and put the result into a new file called desired_page_1. 2. Create a new fixed version of the corrupted file using the corrupted file and new file (desired_page_1 in this example). A. Copy page 0 (good page) from the corrupted file into a new file: # dd if=50226.file.4 of=newfile bs=8192 count=1 B. Append the desired page 1 to the new file by seeking over 1 page in the output file before writing: # dd if=desired_page_1 of=newfile bs=8192 count=1 seek=1 C. Append the remainder of the original file to the end of the new file by skipping past the first two pages of the input file before reading, and seeking past the first 2 pages (already rewritten) in the output file before writing: # dd if=50226.file.4 of=newfile bs=8192 seek=2 skip=2 Run the diff command on the new and the original file to confirm that only page 1 has changed to and that the difference is what is desired. For example: diff newfile 50226.file.4 D. Rename the new file and remove the temporary files: # mv newfile 50226.file.4 # rm 50226.file.4.page_1.ext 50226.file.4.page_1.frag desired_page_1 If desired, the verify command can now be run on the domain again to confirm that the data corruption problem is gone. PROBLEM: (UTO101199, HPAQ30ETE,QAR 51485, 52365) (Patch ID: OSF410-087) ******** (Patch ID OSF410-400298-1 reference information) This patch corrects a problem with an NFS V3 mounted AdvFS file system where under heavy I/O load, data being written to a file may be lost. Additionally, because file stats are not being saved, the file modification time may revert to a previous value. PROBLEM: (UVO105368) (Patch ID: OSF410-405094) ******** This patch fixes a problem where the vrestore program does not report failed exit status appropriately on incomplete or incorrect commands, corrupt or invalid saved sets, or file open failures. PROBLEM: (UVO105186) (Patch ID: OSF410-400259) ******** This patch fixes a problem that occurs on AdvFS system. When a user exceeds the quota limits, an excessive number of user warning messages are sent to the system console if the terminal is inaccessible. After applying this patch, if a user exceeds the quota limits, the warning messages are still displayed on the terminal (when possible) but never on the system console. Additionally, when a quota underflow occurs, the warning message now describes the fileset and the user or group that is experiencing the underflow problem. PROBLEM: (QAR 50858, 44602, 44776) (Patch ID: OSF410-400315) ******** This patch fixes a problem that occurs on systems running AdvFS. The problem occurs when greater than 512 filesets are created. The system panics with following error message: panic (cpu 0): bfs_invalidate: not on free list syncing disks...done PROBLEM: (GOZ100774) (Patch ID: OSF410-400344) ******** This patch fixes a problem that occurs on AdvFS systems. The system will panic with an error message similar to the following: AdvFS I/O error faulting virtual address: 0x000000000000003c pc of faulting instruction: 0xfffffc00003998d0 ra contents at time of fault: 0xfffffc000039ac70 sp contents at time of fault: 0xffffffffb7d0f480 panic (cpu 0): kernel memory fault The following is a sample stack trace: 0 thread_block() 1 thread_preempt() 2 boot() 3 panic() 4 trap() 5 _XentMM() 6 imm_get_first_xtnt_desc() 7 imm_get_first_hole() 8 frag_list_extend() 9 bs_frag_alloc() 10 fs_create_frag() 11 close_one_int() 12 close_int() 13 bs_vfs_close() 14 msfs_inactive() 15 vrele() 16 utimes() 17 syscall() 18 _Xsyscall() PROBLEM: (MCPM31DX7) (Patch ID: OSF410-405107) ******** This patch fixes a problem that occurs on SMP systems with an AdvFS filesystem in which the system panics with the following message: simple_lock: time limit exceeded The problem occurs when the lock is taken by a thread that calls the msfs_unmount routine, as can be seen from lock structure in pmsgbuf: pc of caller: 0xfffffc00003d756c lock address: 0xfffffc00574e12f8 current lock state: 0x00000000003d6a49 (cpu=0,pc=0xfffffc00003d6a48,busy) The pc in "current lock state" was code executed by that thread. This code can be further defined by printing it in dbx: dbx>0xfffffc00003d6a48/i [msfs_unmount:2035] PROBLEM: (HPAQ50U3T,ZUO101186) (Patch ID: OSF410-405112) ******** When a user attempted to restore a vdump, which had been done with the "-D" option and included directories for which Access Control Lists (ACL's) had been declared, the vrestore program was failing to restore ACL's on directory files and issued the following messages: RECORD HEADER (unknown/unexpected) record type : 14 data offset : 0 record size : 208 flags : RECORD HEADER (unknown/unexpected) record type : 14 data offset : 0 record size : 208 flags : vrestore: error setting extended attributes 2 The "unknown/unexpected" error was being reported twice on each directory for which ACL's had been found (since they are recorded twice in the vdump). (since they are recorded twice in the vdump). When a user specified the "-t" option, vrestore erroneously attempted to restore proplists on files that had them; issuing same warning messages. PROBLEM: (HPXQB22D0, QAR 45498) (Patch ID: OSF410-400342) ******** This patch fixes problems with the AdvFS filesystem commands "quotacheck -a" and "vquotacheck -a". These commands erroneously set all quotas for users to values derived from the last AdvFS fileset in /etc/fstab, rather than the correct values for each individual fileset. PROBLEM: (Patch ID: OSF410-400331) ******** When the /etc/passwd file is very large, a performance degradation may occur. When the number of passwd entries reaches up into the 30,000 to 80,000 range or greater, mkpasswd will sometimes fail to create a hashed (ndbm) database. Since the purpose of this database is to allow for efficient (fast) searches for passwd file information, failure to build it causes commands that rely on it to do a linear search of /etc/passwd. This results in a serious per- formance degradation for those commands. This patch allows the vedquota, vquot, vquota and vquotacheck commands to work correctly when the customer builds a hashed passwd database using a non-default page file block size. For customers choosing to use the mkpasswd -s option to avoid this type of failure, a potential database/binary compatibility problem may arise. If a customer application that accesses the password database created by mkpasswd is built statically (non-shared), that application will be unable to read from or write to the password database correctly. This would cause the customer application to fail either by generating incorrect results or by possibly dumping core. Any statically linked application would be affected if it directly or indirectly calls any of the libc ndbm routines documented in the ndbm(3) man page and then accesses the password database. To remedy this situation, the customer would need to re-link the application. Customers who do not use the mkpasswd -s option will not see this database/ binary compatibility problem. PROBLEM: (FNO100126,UTO101198,MGO102729,UVO105463,MGO102993,TKTB91678, ******** QAR 43407) (Patch ID: OSF410-405120) This patch fixes a panic with the panic string "spec_badop called", that can sometimes occur when an fpathconf system call is issued for a file in an AdvFS filesystem. The panic has following stack trace: panic (s = "spec_badop called") spec_badop fpathconf syscall _Xsyscall PROBLEM: (QAR 52525, 46833) (Patch ID: OSF410-092) ******** This patch fixes a problem in which a system hang or core dump occurs when one program inadvertently overwrites the contents of another program. For example, a program, test1, is running and another program, test2, is copied ("cp") onto test1, overwriting the contents of test1. The result is a system hang or a core dump. An example of the problem follows: On one window start running ./test1, while on another: # cp test2 test1 The result is shown here: # ./test1 . . . Test2 looping -- 2819 Test2 looping -- 281a Test2 looping -- 281b Memory fault - core dumped # ls -l core -rw------- 1 root system 360448 May 22 18:46 core An example with the patch shows: On one window start running ./test1, while on another: # cp test2 test1 cp: test1: Text file busy # cp test2 test1 cp: test1: Text file busy The result is shown here: # ./test1 . . . Test2 looping -- 2819 Test2 looping -- 281a Test2 looping -- 281b # ls -l total 50 -rwxr-xr-x 1 root system 24576 May 20 20:05 test1 -rw-r--r-- 1 root system 121 May 20 20:03 test1.c -rwxr-xr-x 1 root system 24576 May 20 20:05 test2 -rw-r--r-- 1 root system 121 May 20 20:03 test2.c PROBLEM: (TKTRA2376) (Patch ID: OSF410-118) ******** This patch fixes a problem with the vrestore command. When restoring a multi- volume tape archive, if the tapes that follow the first tape are write-protected the following error message is displayed: vrestore: can't open device file PROBLEM: (QAR 48878, QAR 36473, QAR 44706, QAR 49895) (Patch ID: OSF410-123) ******** This patch corrects problems with AdvFS performance regression, and two AdvFS race condition situations between multiple routines that can cause panics. One AdvFS race condition is between the ubc routines that call putpage and AdvFS invalidate. If this condition arises an ensuing panic may occur. Output from the panic might look like: lock_read: hierarchy violation pc of caller: 0xfffffc0000397728 lock address: 0xffffffff8031a200 lock info addr: 0xfffffc0000722200 lock class name: bfAccessT.xtntMap_lk class already locked: bfAccessT.putpage_lk current spl level: 0 panic (cpu 0): lock_read: hierarchy violation syncing disks... lock_read: simple lock owned pc of caller: 0xfffffc00003c6f80 lock address: 0xffffffff8031a2b0 lock info addr: 0xfffffc0000722210 lock class name: bfAccessT.putpage_lk pcb slock count: 2 current spl level: 2 The other AdvFS race condition is between msfs_putpage and bs_real_invalidate_pages. If this condition were to arise, it too might cause a panic to occur. Output from the panic might look like: panic "bs_real_invalidate_pages: buf refd or pinned" PROBLEM: (QAR 54983, QAR 49607) (Patch ID: OSF410-128) ******** This patch fixes a problem that occurs on an AdvFS file system. The system may panic with the following error message: ADVFS INTERNAL ERROR: dealloc_bits_page: can't clear a bit twice The following is an example of a stack trace: (dbx) t > 0 stop_secondary_cpu(do_lwc = 0x0) 1 panic(s = 0xfffffc0000556528) 2 event_timeout(func = 0xfffffc0000276738, arg = 0xfffffc000059a2c0, timeout = 0x5) 3 xcpu_puts(s = 0xfffffc00005798d0, prfbufp = 0xfffffc000059a2c0) 4 printf(fmt = 0xfffffc000051fd68) 5 panic(s = 0xffffffff88cb71d0) 6 advfs_sad(0xfffffc000030a7c8, 0x0, 0xe, 0x1f500, 0xfffffc0005952000) 7 CANT_CLEAR_TWICE(0x7b, 0xe, 0xffffffffffffff00, 0xc27f, 0x612) 8 dealloc_bits_page(0x38, 0xfffffc00005311a0, 0xfffffc00075d2008, 0xfffffc00057ba000, 0x301001a) 9 bitmap_undo_opx(0x3, 0xfffffc00005b9df8, 0xfffffc00075d2298, 0x0, 0xfffffc00075d3578) 10 ftx_fail_2(ftxH = struct { hndl = 0x1a level = 0x2 dmnh = 0x1 } 11 ftx_fail(ftxH = struct { hndl = 0x0 level = 0x0 dmnh = 0x0 } 12 fs_write_add_stg(0x1, 0xffffffff80287530, 0x7, 0xfffffc00020986e0, 0x0) 13 fs_write(0xc884, 0x14, 0x45f4f, 0x200000002, 0x0) 14 msfs_write(vp = 0xfffffc0002098600, uio = 0xffffffff88cb7848, cred = 0xfffffc0001e0be00) 15 vn_write(0xfffffc00002839ec, 0xffffffff88cb78e0, 0xfffffc000783bfc0, 0xf888, 0x1) 16 rwuio(0xfffffc0001fb6220, 0xfffffc0005431b80, 0xfffffc0000575ab0, 0xfffffc0001fb6000, 0xfffffc0 00783bfc0) 17 write(0xc884, 0xffffffff88cb7838, 0x28000, 0xc88400000001, 0x100000000) 18 syscall(0xf888, 0x1, 0xfffffc000045f7fc, 0x3ffc01877c0, 0x4) 19 _Xsyscall(0x8, 0x3ff800d2ed8, 0x14000c2c0, 0x3, 0x140059000) (dbx) PROBLEM: (QAR 56152, QAR 55813) (Patch ID: OSF410-129) ******** This patch fixes two problems that occur on AdvFS systems: o The system may panic with the following error message: simple_lock: hierarchy violation o A locking problem in the AdvFS log data structures may cause the following to occur: - System panics - Kernel memory faults - Memory corruption PROBLEM: (QAR 55308, QAR 55447 ) (Patch ID: OSF410-400389) ******** This patch fixes an AdvFS problem in which the "advfsstat -n" command causes a core dump. The system displays the following error message: Memory fault(coredump) PROBLEM: (QAR 54607,QAR 56125 ) (Patch ID: OSF410-400443) ******** This patch fixes a problem that occurs on AdvFS systems. The chfsets function returns incorrect exit values and inappropriate error messages. This problem occurs when an inactive domain is specified along with an explicit list of filesets. In this case, a successful exit code is returned, which is incorrect. If an inactive domain is specified without any filesets then it fails properly. PROBLEM: (QAR 51816,QAR 45334) (Patch ID: OSF410-400445) ******** This patch fixes a problem that occurs on AdvFS systems. If the "ls -l M1" command is given in a .tags directory, the fileset will become unmountable. If the system is then halted, the following panic will occur. 1 panic(...RefCnt =...) 2 advfs_sad() 3 bfs_dealloc() 4 bs_bfs_remove_root( ) 5 dmn_dealloc() 6 bs_bfdmn_deactivate() 7 bs_bfset_deactivate() 8 msfs_unmount( ) 9 dounmount() 10 boot( ) 11 reboot() 12 syscall() 13 _Xsyscall() PROBLEM: (MCGMA1R2P,FNO100154) (Patch ID: OSF410-400449) ******** This patch fixes an AdvFS problem in which improper handling of I/O queues cause either a kernel memory fault or the following panics: "bs_invalidate: cache rundown" "rm_or_moveq: ioDesc not on a queue" Sample stack traces follow: 1) 5 panic(s = 0xfffffc00005efab0 = "kernel memory fault") 6 trap() 7 _XentMM() 8 bs_osf_complete() (attempting to obtain a pointer to a virtual disk table to log statistics for the disk that the i/o occurred on) 9 msfs_async_iodone_lwc() 10 lwc_schedule() 11 thread_block() 12 xpt_callback_thread() 13 lwc_schedule() 2) 9 panic() 10 trap() 11 _XentMM() 12 bs_q_lazy() 13 bs_q_list() 14 bs_unpinpg() 3) 9 panic() 10 trap() 11 _XentMM() 12 consecutive_list_io() 13 bs_startio() PROBLEM: (QAR 57680, QAR 57689, QAR 58050, QAR 49803 (Patch ID: OSF410-400476) ******** This patch fixes a problem that occurs on an AdvFS file system. While the symptoms of these AdvFS problems vary, the most common is a panic with the following error message: bs_frag_alloc: pinpg faild\n N1 = -1035 Alternately, bs_frag_dealloc: pinpg faild\n N1 = -1035 A sample stack trace follows: 0 panic() 1 event_timeout() 2 xcpu_puts() 3 printf() 4 panic() 5 advfs_sad() 6 bs_frag_dealloc() 7 fs_delete_frag() 8 copy_and_del_frag() 9 fs_write_add_stg() 10 fs_write() 11 msfs_write() 12 vn_write() 13 rwuio() 14 write() 15 syscall() 16 _Xsyscall() PROBLEM: (QARs 57927,58380,57750,55812,46684,52548,53105) ******** (PatchID: OSF410-405241) This patch adds features and corrections to the AdvFS verify utility. The verify utility contains the following corrections: - Detects and reports some file system corruption problems it had previously ignored. - No longer gives seek errors on really large frag files (>2GB) - Provides detailed warning messages when frag files (>2GB) - Gives detailed warning messages when a frag file is found to be incorrectly terminated - Gives a useful error message when the when the root_domain is mounted read-only, preventing it from investigating other domains - Properly handles domains that have clones - Properly handles SBM fixups (code which was intended to correct corrupted pages in the SBM metadata file fixed the page in memory but then wrote the newly-corrected page over the NEXT page in the SBM.) - Increases the amount of memory available to the program so that large domains can be worked with. PROBLEM: (QAR 57258,56851) (Patch ID: OSF410-400497) ******** This patch corrects a problem where the mcellCount on-disk was not being updated as files were being migrated and this resulted in a panic situation. The panic would produce a message like: bs_frag_alloc: pinpg faild\n N1 = -1035 PROBLEM: (QAR 57798,57702) (Patch ID: OSF410-400497) ******** This patch fixes a race condition that occurs on an AdvFS file system. The system panics with the following error message: panic (cpu 0): bs_frag_alloc: pinpg faild PROBLEM: (QAR 57086,56656) (Patch ID: OSF410-400497) ******** This patch fixes a problem that occurs on an AdvFS file system. An AdvFS lock is not released which hangs the system next time a thread tries to obtain the lock. PROBLEM: (QAR 55791,55773) (Patch ID: OSF410-400497) ******** When executing /sbin/advfs/verify command on an unmounted AdvFS domain, the system will panic with the following panic string: panic_string: 0xfffffc00006cad90 = "kernel memory fault" The stack trace looks like the following: boot() panic() trap() _XentMM() fs_update_stats() cleanup_closed() PROBLEM: (QAR 56845, QAR 56403) (Patch ID: OSF410-400482) ******** This patch fixes an AdvFS problem that causes the system to panic with the following error message: simple_lock: lock already owned by cpu PROBLEM: (QAR 57164, QAR 54852) (Patch ID: OSF410-400489) ******** This patch fixes a system panic when shutting down to single user mode using one of the following commands: a.) # shutdown now b.) # init s When AdvFS is the root or usr filesystem. This cause of this problem is subject to the timing of several kernel threads, so therefore the symptoms or panic may occur intermittantly and on different platforms. The example stack trace is as follows: > 0 boot(0x0, 0x4, 0x1, 0x1, 0xfffffc00004893b8) ["../../../../src/kernel/arch/alph a/machdep.c":1795, 0xfffffc00004f4a6c] 1 panic(s = 0xfffffc0000630098 = "panic stuck syncing disks") ["../../../../src/kernel/bsd/subr_prf.c":673, 0xfffffc0000450eb8] 2 hardclock(pc = 0xfffffc0000281388 = "@", ps = 0x2) ["../../../../src/kernel/bsd/kern_clock.c":736, 0xf ffffc0000437044] 3 _XentInt(0x2, 0xfffffc0000281388, 0xfffffc0000681bd0, 0xfffffc0006152de0, 0x1) ["../../../../src/kernel/arch/alpha/locore.s":917, 0xfffffc00004f1764] 4 ufs_fsync_clrflag_wakeup(ip = 0xfffffc0006152cb0, dolock = 0x6152c00) ["../../../../src/kernel/ufs/ufs_vnops.c":6242, 0xfffffc0000281384] 5 ufs_inactive(vp = 0xfffffc0006152c00) ["../../../../src/kernel/ufs/ufs_inode.c":1231, 0xfffffc000026f180] 6 vrele(vp = 0xfffffc0002196400) ["../../../../src/kernel/vfs/vfs_subr.c":2234, 0xfffffc00004638ec] 7 mntbusybuf(mountp = (nil)) ["../../../../src/kernel/vfs/vfs_bio.c":1356, 0xfffffc0000460d30] 8 boot(0x0, 0x0, 0xffffffff887fb4c8, 0x36, 0x8000000000) ["../../../../src/kernel/arch/alpha/machdep.c":1751, 0xfffffc00004f4978] 9 panic(s = 0xffffffff887fb4c8 = "N1 = 2") ["../../../../src/kernel/bsd/subr_prf.c":757, 0xfffffc0000451074] 10 advfs_sad(0x1a, 0xae7, 0xfffffc000062ac30, 0x0, 0x2) ["../../../../src/kernel/msfs/bs/bs_misc.c":345,0xfffffc00003e85dc] 11 log_donerec_nunpin(ftxp = 0xfffffc0007cd8008, dmnp = (nil), lrdp = (nil)) ["../../../../src/kernel/msfs/bs/ftx_routines.c":2790, 0xfffffc00003c0218] 12 ftx_done_urdr(ftxH = (...), agentId = FTA_BS_BMT_UPDATE_REC_V1, undoOpSz = 0x0, undoOp = (nil), rootDnOpSz = 0x0, rootDnOp = (nil), redoOpSz = 0x0, redoOp = (nil)) ["../../../../src/kernel/msfs/bs/ftx_routines.c":1225, 0xfffffc00003bda38] 13 ftx_done_n(ftxH = (...), agentId = 30914472) ["../../../../src/kernel/msfs/bs/ftx_routines.c":978, 0xf ffffc00003bd5bc] 14 bmtr_update_rec_int(0xffffffff80287ef8, 0xff, 0xfffffc0007d61498, 0x58, 0x0) ["../../../../src/kernel/msfs/bs/bs_bmt_util.c":1816, 0xfffffc00003b6308] 15 bmtr_update_rec(0x400fe001f003c00, 0xff, 0xfffffc0007d61498, 0x58, 0x0) ["../../../../src/kernel/msfs/bs/bs_bmt_util.c":1646, 0xfffffc00003b5fe8] 16 fs_flush_saved_stats(0xfffffc000041cfa0, 0x0, 0x13000004b0273001, 0x2c000009f7000055, 0xfffffc0007cc0018) ["../../../../src/kernel/msfs/fs/fs_create.c":1100, 0xfffffc000041e1a8] 17 cleanup_bfap_with_saved_stats(bfap = 0xfffffc000041cfb8) ["../../../../src/kernel/msfs/bs/bs_access.c":766, 0xfffffc00003e5674] 18 fs_cleanup_thread(0x0, 0xfffffc0007d61488, 0x130000018e0169, 0x281f00000000, 0xa80000053d0000) ["../../../../src/kernel/msfs/fs/fs_dir_init.c":906, 0xfffffc000041cfb4] PROBLEM: (QAR 56824, QAR 55656) (Patch ID: OSF410-126) ******** This patch fixes the following problems that occurs on AdvFS system: o Race conditions occur due to threads seeing out-of -date extent maps. o A previous patch applied as a workaround to other extent map changes cause the system to hang. Applying this patch fixes this problem. o This patch fixes a problem with in-memory extent map locking that occurs on AdvFS systems. The problem can cause panics due to kernel memory faults or simple lock timeouts. Kernel memory fault stack traces which can occur are: panic(s = "kernel memory fault") trap _XentMM imm_page_to_sub_xtnt_map x_page_to_blk x_page_to_blkmap x_page_mapped bs_frag_has_stg msfs_getattr vn_stat stat1 lstat syscall _Xsyscall and panic(s = "kernel memory fault") trap() _XentMM() x_page_to_blk() x_page_to_blkmap() x_page_to_iolist() blkmap() seq_ahead() seq_ahead_cont() bs_refpg_int() bs_refpg() set_block_map() cp_copy_page_range() migrate_normal() mig_migrate() bs_migrate() msfs_real_syscall() msfs_syscall() syscall() _Xsyscall() The simple lock timeout will have a thread which timed out waiting for BfAccessTblMutex. That thread will have a panic string of "simple_lock: time limit exceeded". Among the threads in the crash dump (not necessarily the one that timed out) will be one whose stack trace include x_page_to_blk() or imm_load_sub_xtnt_map(), such as the following stack trace: panic(s = "event_timeout: panic request") event_timeout() xcpu_puts() printf() simple_lock_fault() simple_lock_time_violation() bs_refpg_int() bs_refpg() imm_load_sub_xtnt_map() x_page_to_blk() x_page_to_blkmap() x_page_to_iolist() blkmap() bs_pinpg_one_int() bs_pinpg_clone() bs_pinpg_put() msfs_putpage() ubc_flush_dirty() msfs_sync() sync() syscall() _Xsyscall() PROBLEM: (QAR 57258,56851) (Patch ID: OSF410-163) ******** This patch corrects a problem where the mcellCount on-disk was not being updated as files were being migrated and this resulted in a panic situation. The panic would produce a message like: bs_frag_alloc: pinpg faild\n N1 = -1035 PROBLEM: (QAR 55791,55773) (Patch ID: OSF410-405148) ******** This patch corrects a kernel read fault panic condition that occurs when the AdvFS verify utility runs. The panic message looks like: trap: invalid memory read access from kernel mode panic (cpu 0): kernel memory fault 0 boot() 1 panic(s = 0xfffffc00006dc450 = "kernel memory fault") 2 trap() 3 _XentMM() 4 fs_update_stats() 5 cleanup_closed_list() 6 fs_cleanup_thread() PROBLEM: (QAR 57798,57702) (Patch ID: OSF410-405156) ******** This patch fixes a race condition that occurs on an AdvFS file system. The system panics with the following error message: panic (cpu 0): bs_frag_alloc: pinpg faild PROBLEM: (QAR 57086, QAR 56656) (Patch ID: OSF410-405170) ******** This patch fixes a problem that occurs on an AdvFS file system. An AdvFS lock is not released which hangs the system next time a thread tries to obtain the lock. PROBLEM: (QAR 55640,51918) (Patch ID: OSF410-405172) ******** This patch fixes AdvFS performance problems. PROBLEM: (Patch ID: OSF410-405205) ******** This patch fixes a problem in which vrestore can cause an occasional core dump (Foating Exception). PROBLEM: (MCGMC03FC,HPAQ11P4K,EVT102458,MGO103284,58879) ******** (Patch ID: OSF410-405214) This patch fixes a problem that occurs on AdvFS file systems. A kernel memory fault occurs on the AdvFS file system when accessing nfs-mounted files. The error log contains the following information: trap: invalid memory read access from kernel mode faulting virtual address: 0x0000000000000050 pc of faulting instruction: 0xfffffc0000362224 ra contents at time of fault: 0xfffffc0000362218 sp contents at time of fault: 0xffffffffa9a73768 Possible stack: 15 _XentMM() 16 msfs_getattr() 17 rfs3_getattr() 18 rfs_dispatch() 19 nfs_rpc_recv() 20 nfs_rpc_input() 21 nfs_input() PROBLEM: (QAR 58250, 57918) (Patch ID: OSF410-405215) ******** This patch provides a performance improvement for AdvFS systems. A read() system call from an AdvFS file for a length less than 16K whose starting offset within an 8K page falls such that the read() request crosses into the next page, currently requires two disk I/O operations if the file pages are not already cached in the UBC from prior read() or write() requests. This performance change to AdvFS will prefetch the second page with a concurrent disk I/O operation. This means the requesting thread will only be put to sleep for I/O one time while processing the read() system call. PROBLEM: (QAR 58740) (Patch ID: OSF410-156) ******** This patch fixes an AdvFS response time problem that occurred when an application with many random access reads of many files was being slowed down by the resulting number of writes to disk. To fix the problem, there are three new features: o atimes and noatimes options are added to the mount -o option list for AdvFS file systems o the read system call has additional code to perform the operation requested by the noatimes option o a configurable parameter, AdvfsPreallocAccess, for tuning the number of access structures in the freelist at startup The AdvFS mount option noatimes changes AdvFS behavior for regular files in the specified fileset. AdvFS updates the file access time in memory on a read system call from a regular file, but does not write the stat structure for the file with the new access time out to disk until some other file modification is made. After a file is closed (and when the fileset is unmounted), the in memory updated access time can be lost. Therefore, this mount noatimes option should not be used in conjunction with utilities or applications which gather statistics or make decisions based on file access times, such as migrating unaccessed files to slower backing storage. PROBLEM: (QAR 56366, QAR 56062) (Patch ID: OSF410-405219) ******** This patch corrects a situation where a quotacheck can cause a system panic. The problem occurs in a system call in a race condition with umount. The panic looks similiar to: 0 stop_secondary_cpu(do_lwc = 0) 1 panic(s = 0xfffffc0000682f48 = "event_timeout: panic request") 2 event_timeout(func = 0xfffffc000027ef20, arg = 0xfffffc0000730908) 3 xcpu_puts(s = (nil), prfbufp = 0xfffffc0000730908) 4 printf() 5 panic(s = 0xffffffffa93634b8 = "bs_bf_htop: invalid handle\n N1 = 0") 6 advfs_sad() 7 bs_bf_htop() 8 bs_frag_has_stg(bfSetH = struct { setH = 0 dmnH = 0 }, fragId = struct { frag = 0 type = BF_FRAG_ANY }) 9 msfs_real_syscall() 10 msfs_syscall() 11 syscall() 12 _Xsyscall() PROBLEM: (QAR59747, HPAQ20W8R) (Patch ID: OSF410-405226) ******** A system using an AdvFS clone fileset can panic with either a kernel memory fault in bs_real_invalidate_pages(), or with the panic string: "bs_real_invalidate_pages: buf refd or pinned". The kernel memory fault would have a faulting virtual address of 0x040, and a stack trace which goes through msfs_reclaim and bs_real_invalidate_pages. A typical stack trace would be: 5 panic(s = "kernel memory fault") 6 trap 7 _XentMM 8 bs_real_invalidate_pages 9 msfs_reclaim 10 vclean 11 vgone 12 vflush 13 msfs_unmount 14 dounmount 15 unmount 16 syscall 17 _Xsyscall The panic with the string "bs_real_invalidate_pages: buf refd or pinned" would also go through msfs_reclaim and bs_real_invalidate_pages. A typical stack trace would be: 5 panic(s = "bs_real_invalidate_pages: buf refd or pinned") 6 advfs_sad 7 bs_real_invalidate_pages 8 msfs_reclaim 9 vclean 10 vgone 11 getnewvnode 12 vdealloc 13 vrele 14 namei 15 unp_connect 16 uipc_usrreq 17 sosend 18 sendit 19 sendto 20 syscall 21 _Xsyscall PROBLEM: (QAR 55785, QAR 55652) (Patch ID: OSF410-405228) ******** This patch corrects a panic and hang situation due to a limit of advfs access structures. PROBLEM: (QAR 54322, QAR 57034) (Patch ID: OSF410-405231) ******** This patch fixes a problem caused by the vdump command. When a user entered Ctrl/C to terminate a vdump operation, the command returned an incorrect status and mistakenly updated the /etc/vdumpdates file. PROBLEM: (QAR 58822, QAR 59748) (Patch ID: OSF410-405232) ******** This patch fixes an kernel memory fault panic. The system displays the following error message: trap: invalid memory read access from kernel mode The stack trace is as follows: 1 panic() 2 event_timeout() 3 xcpu_puts() 4 printf() 5 panic() 6 trap() 7 _XentMM() 8 bs_real_invalidate_pages() 9 bs_invalidate_rsvd_access_struct() 10 vd_remove() 11 bs_bfdmn_deactivate() 12 bs_bfset_activate_int() 13 bs_bfset_activate() 14 fs_fset_get_stats() 15 msfs_real_syscall() 16 msfs_syscall() 17 syscall() 18 _Xsyscall PROBLEM: (QAR 57258, QAR 56851) (Patch ID: OSF410-405235) ******** This patch corrects a problem where the mcellCount on-disk was not being updated as files were being migrated and this resulted in a panic situation. The panic would produce a message like: bs_frag_alloc: pinpg faild\n N1 = -1035 PROBLEM: (QAR 52529, QAR 49940) (Patch ID: OSF410-405239) ******** This patch corrects a problem with domain panics that could possibly cause the system to panic. A new AdvFS error number (E_DOMAIN_PANIC) (-1028) was created. the problem occurs when a domain panic occurs and the system is unable to handle or deal with the situation and it panics in turn. This patch corrects all known cases where the domain might panic. PROBLEM: (QAR 47047, QAR 51352) (Patch ID: OSF410-405240) ******** This patch fixes a problem that occurs when the user attempts to fill an AdvFS: the system crashes and displays the following panic: lock_write: hierarchy violation The panic information would be similar to the following: lock_write: hierarchy violation pc of caller: 0xfffffc0000375ccc lock address: 0xfffffc00e7e73180 lock info addr: 0xfffffc000073c220 lock class name: domainT.scLock class already locked: vdT.mcell_lk current spl level: 0 panic (cpu 2): lock_write: hierarchy violation simple_lock: lock already owned by cpu pc of caller: 0xfffffc0000563e8c lock address: 0xfffffc00ffe2ac48 lock info addr: 0xfffffc000073d260 lock class name: cam_isp current lock state: 0xc400012600565025 (cpu=0,pc=0xfffffc0000565024,busy simple locks held PROBLEM: (QARs 57927,58380,57750,55812,46684,52548,53105) ******** (Patch ID: OSF410-405241) This patch adds features and corrections to the AdvFS verify utility. The verify utility now detects and reports some file system corruption problems it had previously ignored. It also no longer gives seek errors on really large frag files (>2GB); gives detailed warning messages when a frag file is found to be incorrectly terminated, helping the user to know which file's fragments are involved; gives a useful error message when the root_domain is mounted read-only, preventing it from investigating other domains; properly handles domains that have clones; and properly handles SBM fixups (code which was intended to correct corrupted pages in the SBM metadata file fixed the page in memory but then wrote the newly-corrected page over the NEXT page in the SBM.) Also, increases the amount of memory available to the program so that large memory systems can be worked with. PROBLEM: (QAR 52487, QAR 58963) (Patch ID: OSF410-405242) ******** This patch fixes a problem caused by the vrestore command. The command would fail when restoring multiple savesets from a TZS20 tape drive. The vrestore command would fail when it attempted to restore the second saveset from the tape. The error message returned was: vrestore: unable to use save-set; invalid or corrupt format PROBLEM: (QAR 55975, QAR 53061) (Patch ID: OSF410-405203) ******** This patch fixes a problem in the chvol command. chvol was not recognizing LSM volumes. PROBLEM: (CLD SOO101109) (Patch ID: OSF410-405253) ******** This patch fixes a problem that occurred when an AdvFS panic crashed the system but the visible symptom was a crash due to a kernel memory fault. The kernel memory fault was caused by an internal conversion routine as it was attempting to format the string that reported the AdvFS panic. The following shows the crash footprint: dbx> p *pmsgbuf (also can use "pmsgbuf/100s") : : ADVFS EXCEPTION Module = ftx_routines.c, Line = 2879 trap: invalid memory read access from kernel mode faulting virtual address: 0xfffffffffffffbd8 pc of faulting instruction: 0xfffffc0000294bbc ra contents at time of fault: 0xfffffc0000293dec sp contents at time of fault: 0xffffffff" PROBLEM: (EVT102509 GOZ100927 QAR 60509) (Patch ID: OSF410-405249) ******** This patch prevents a "kernel memory fault" in the msfs_reclaim() routine on systems using AdvFS. The stack trace will look similar to the following: 0 boot 1 panic(s = "kernel memory fault") 2 trap 3 _XentMM 4 msfs_reclaim 5 vclean 6 vgone 7 getnewvnode PROBLEM: (QAR 57426,QAR 57942) (Patch ID: OSF410-405251) ******** This patch fixes a problem with the chfsets command. When a root user exceeded the fileset quota (which root is allowed to do), the chfsets command reported negative values for the free and available blocks in the fileset. PROBLEM: (QAR 54548, QAR 51121) (Patch ID: OSF410-405275) ******** This patch fixes a kernel memory fault problem that occurs on AdvFS file systems. The system displays the following error message: panic: kernel memory fault at spec_reclaim() A sample stack trace is shown in the following example: > 0 boot() 1 panic(s = 0xfffffc000068ed00 = "kernel memory fault") 2 trap() 3 _XentMM() 4 spec_reclaim() 5 msfsspec_reclaim(vp = 0xfffffc000186e200) 6 msfs_inactive() 7 vrele(vp = 0xfffffc000029eca0) 8 vn_close() 9 closef() 10 close() 11 syscall() 12 _Xsyscall() End Trace for machine_slot[paniccpu].cpu_panic_thread: PROBLEM: (QAR 59968, QAR 57858) (Patch ID: OSF410-405280) ******** This patch fixes an AdvFS problem that occurs when unmounting a domain. An unmount thread was waiting on a variable to be set to zero before continuing, but the routine that was to set the variable to zero never did. The stack trace is: 0 thread_block() 1 thread_sleep() 2 _cond_wait() 3 vd_free() 4 vd_remove() 5 bs_bfdmn_deactivate() 6 bs_bfset_deactivate() 7 msfs_unmount() 8 dounmount() 9 unmount(0xfffffc0000578af0, 0x16, 0xfffffc00006fbe00, 0xffffffff88b6c PROBLEM: (QAR 57163,QAR 56892) (Patch ID: OSF410-405283) ******** This patch fixes a problem that crashed the system while it was running a "collision" test. A process would hang on a lock, never be woken, and crash the system. PROBLEM: (QAR 57450) (Patch ID: OSF410-405286) ******** This patch fixes a problem with the AdvFS fs_write routine, which would mishandle partial writes after detecting an error. Now when the fs_write routine detects an error, it breaks out of the write page loop and decides either to exit immediately with an error (if no bytes have been written) or to commit the partial changes to disk and return the number of successfully-written bytes. PROBLEM: (QAR 61304, QAR 60584) (Patch ID: OSF410-405298) ******** This patch corrects a problem where a panic would occur when running rmtrashcan on a clone. The panic would look like: panic (cpu 0): bmtr_put_rec error in detach_undel_dir N1 = -1114 PROBLEM: (QAR 61395, QAR 61336) (Patch ID: OSF410-405310) ******** This patch fixes a problem with AdvFS, which caused a system panic with the following messge: log_flush_sync: pingpg error The system panic occurred when the AdvFS domain had already issued a domain panic and a user application then attempted to close a file in that domain. The stack trace is listed below: 7 panic() 8 advfs_sad() 9 log_flush_sync() 10 lgr_writev_ftx() 11 log_donerec_nunpin() 12 ftx_done_urdr() 13 ftx_done_n() 14 msfs_close() 15 vn_close() 16 closef() 17 close() 18 syscall() 19 _Xsyscall() PROBLEM: (QAR 55008,QAR 60308) (Patch ID: OSF410-405334) ******** This patch fixes a problem in AdvFS that produced the following system panic: bs_logflush_start: cannot write lsn PROBLEM: (QAR 61553) (Patch ID: OSF410-405344) ******** This patch fixes a problem with messages in system logs that reported AdvFS user and group quota limits. The messages were unclear: the user could not determine from them which users or groups were reaching the quota limits. Part of the problem was the term "inode," which is not an AdvFS entity. The term was replaced in the messages with "file." PROBLEM: (QAR 46502, QAR 52854, QAR 55893, QAR 59488, QAR 59854, QAR 61274, QAR 51985) (Patch ID: OSF410-405385) ******** This patch fixes several problems associated with AdvFS tag files and directories. Specific problems fixed in this patch are: 1. The tag file interface caused the vdf, showfile, and other commands to display erroneous data. 2. When a tag directory was opened, a vnode was assigned to an illegal mount point, causing an ENODEV error return or a system panic. 3. The routine that tested for referenced tag directories was incorrectly causing the system to panic with the following message: lock_write: lock already owned by thread and the following stack trace resulted: 8 panic() 9 lock_fault() 10 lock_write() 11 bf_get_l() 12 bf_get() 13 msfs_lookup() 14 namei() 15 _F64_stat1() 16 _F64_lstat() 17 syscall() 18 _Xsyscall() 4. When using the tags interface to access nonexisting reserved files, the system would panic with the following message: SMP Assertion failed and the following stack trace resulted: 1 panic() 2 advfs_sad() 3 imm_init_sub_xtnt_map() 4 load_from_xtnt_rec() 5 load_inmem_xtnt_map() 6 x_create_inmem_xtnt_map() 7 bs_map_bf() 8 rbf_access_one_int() 9 rbf_access_int() 10 rbf_vfs_access() 11 bf_get_l() 12 bf_get() 13 msfs_lookup() 14 namei() 15 _F64_stat1() 16 _F64_lstat() 17 syscall() 18 _Xsyscall() 5. A routine attempting to remove trashcans would report success on directories that did not even have trashcans. PROBLEM: (QAR 60129, QAR 62613) (Patch ID: OSF410-405400) ******** This patch fixes a problem in AdvFS locking code which causes the following panic: kernel memory fault The stack trace is listed below: 0 boot() 1 panic() 2 trap() 3 _XentMM() 4 bs_pinpg_clone() 5 bs_pinpg_ftx() 6 rbf_pinpg() 7 alloc_mcell() 8 bmt_alloc_prim_mcell() 9 new_mcell() 10 rbf_int_create() 11 rbf_create() 12 fs_create_file() 13 msfs_mkdir() 14 mkdir() 15 syscall() 16 _Xsyscall() PROBLEM: (QAR 63522) (Patch ID: OSF410-405427) ******** This patch fixes a problem in AdvFS that was causing a memory leak. An internal routine was not always deallocating buffers that were returned to it. PROBLEM: (QAR 61275, QAR 61777) (Patch ID: OSF410-405437) ******** This patch fixes a problem with AdvFS that caused a page fault and the following panic: panic (cpu 0): kernel memory fault A stack trace would be similar to the following: 0 boot() 1 panic() 2 trap() 3 _XentMM() 4 bs_logpage_dirty() 5 lgr_read() 6 ftx_fail_2() 7 ftx_fail() 8 stg_add_stg_no_cow() 9 stg_add_stg() 10 rbf_add_overlapping_stg() 11 fs_write_add_stg() 12 fs_write() 13 msfs_write() 14 vn_write() 15 rwuio() 16 write() 17 syscall() 18 _Xsyscall() PROBLEM: (QAR 62114,QAR 58469 , QAR 62503,QAR 49186) (Patch ID: OSF410-405438) ******** This patach fixes two AdvFS problems: 1. An error message was misleading when a DIGITAL UNIX Version 4 system attempted to access a file domain created by DIGITAL UNIX Version 5. 2. A state field in an AdvFS data structure was initialized, but not maintained. PROBLEM: (QAR 56028) (Patch ID: OSF410-405444) ******** This patch fixes a problem where a system hang can occur when creating an AdvFS file system, such as on "/ "or "/usr" partitions, on small memory systems (e.g. 32-64 mb). This problem was seen during installation when creating an AdvFS file system on /usr partition. PROBLEM: (QAR 63937, QAR 64709) (Patch ID: OSF410-405467) ******** This patch fixes a problem where user files or the AdvFS frag file could lose data, if they are updated during an AdvFS migration (that is, during a balance, defragment, migrate, or rmvol of their AdvFS domain). PROBLEM: (QAR 62673,QAR 61388) (Patch ID: OSF410-202) ******** This patch fixes a problem in AdvFS, which causes a system panic when a truncate operation is performed on a file. The panic is: log half full Here's the stack trace: > 0 boot() ["../../../../src/kernel/arch/alpha/machdep.c":1890, ] 1 panic(s = 0xffffffff8bc3af98 = "release_dirty_pg: log half full") ["../../../../src/kernel/bsd/sub r_prf.c":834, 0xfffffc000028c024] 2 advfs_sad() ["../../../../src/kernel/msfs/bs/bs_misc.c":556, ] 3 release_dirty_pg() ["../../../../src/kernel/msfs/bs/ms_logger.c":2005,] 4 lgr_writev_ftx() ["../../../../src/kernel/msfs/bs/ms_logger.c":1576, ] 5 log_donerec_nunpin()["../../../../src/kernel/msfs/bs/ftx_routines.c":2825,] 6 ftx_done_urdr() ["../../../../src/kernel/msfs/bs/ftx_routines.c":1246, ] 7 ftx_done_u() ["../../../../src/kernel/msfs/bs/ftx_routines.c":1060, ] 8 bmt_link_mcells() ["../../../../src/kernel/msfs/bs/bs_bmt_util.c":3770, ] 9 odm_create_xtnt_map() ["../../../../src/kernel/msfs/bs/bs_extents.c":1707,] 10 dealloc_stg() ["../../../../src/kernel/msfs/bs/bs_stg.c":6388, ] 11 remove_stg() ["../../../../src/kernel/msfs/bs/bs_stg.c":5897, ] 12 stg_remove_stg_start() ["../../../../src/kernel/msfs/bs/bs_stg.c":5743, ] 13 bf_setup_truncation() ["../../../../src/kernel/msfs/bs/bs_access.c":4189, ] 14 msfs_setattr() ["../../../../src/kernel/msfs/osf/msfs_vnops.c":1725, ] 15 vtruncate() ["../../../../src/kernel/vfs/vfs_syscalls.c":3488, ] 16 ftruncate() ["../../../../src/kernel/vfs/vfs_syscalls.c":3418, ] 17 syscall() ["../../../../src/kernel/arch/alpha/syscall_trap.c":627, ] 18 _Xsyscall() ["../../../../src/kernel/arch/alpha/locore.s":1409, ] End Trace for machine_slot[paniccpu].cpu_panic_thread: PROBLEM: (QAR 54246,QAR 57344) (Patch ID: OSF410-405284) ******** This patch fixes a problem with the vrestore command. The command had returned a success status code even though it had restored an incomplete file during the operation. PROBLEM: (QAR 44395,QAR 45174,QAR 45558,QAR 45561,QAR 45639) (Patch ID: OSF410-405323) ******** This patch fixes several problems with the vrestore command, all related to handling and parsing of terminal I/O: - Interactive shell's handling of space characters - Displaying of files containing non-printable characters to a terminal during interactive's ls command, -t, -v, or -l options. - Interactive mode commands piped from stdin. - Prompting and requesting of input from a terminal during ctrl-c signal handling. PROBLEM: (QAR 57304,QAR 50820,QAR 57898,QAR 59077) (Patch ID: OSF410-405398) ******** This patch fixes three verify command problems: 1. The command was displaying a large volume of meaningless data. [A -q flag and message suppression was added to the utility.] 2. When it encountered a nonrecoverable error, the command did not properly exit. [The nonrecoverable error returns were improved.] 3. The command sent some error messages to stderr, some to stdout. [Error messages are directed to stderr.] PROBLEM: (QAR 60888, QAR 61768, QAR 58064) (Patch ID: OSF410-180) ******** This patch fixes a problem in the AdvFS system. The log file corruption caused panics during recovery and failures displaying one of the following messages: ftx_fail: lgr_read failure -or- ftx_fail: dirty page not allowed Sample stack traces are listed below: 28 panic() 29 advfs_sad() 30 ftx_fail_2() 31 ftx_fail() 6 advfs_sad() 7 _ms_free() 8 ftx_fail_2() 9 ftx_recovery_pass() PROBLEM: (QAR 59953, QAR 59419) (Patch ID: OSF410-159) ******** This patch fixes a problem that occurs on AdvFS systems. The system will panic with the following error message: malloc_overflow: guard space corruption A sample stack trace is as follows: 6 panic() 7 malloc_debug() 8 free() 9 _ms_free() 10 free_dmntbl_setname() 11 msfs_real_syscall() 12 msfs_syscall() 13 syscall() 14 _Xsyscall() PROBLEM: (QAR 62299, QAR 51568, HPAQ60W1F, QAR 62617, QAR 62610, UVO106018, QAR 61185, QAR 63686, QAR 63703, QAR 54276, QAR 60262) (Patch ID: OSF410-405434) ******** This patch fixes the following problems in AdvFS: 1.) A operating system hang condition. The hang condition exists due to processes deadlocking in the AdvFS code. 2.) AdvFS does not return an error when a user opens a file in O_SYNC mode and power is lost on the disk drive. 3.) A locking error in the AdvFS fs_write() routine. PROBLEM: (QAR 60922, QAR 55002, QAR 46115) (Patch ID: OSF410-169) ******** This patch fixes an AdvFS problem that occurs when the rmvol command is stopped before the commmand successfully removes a volume from a domain. As a result, the showfdmn and addvol commands interpreted the volume as still in the domain (although with no data available) and a balance operation returned the following AdvFS error message: get vol params error EBAD_VDI (-1030) PROBLEM: (QAR 56531 QAR 56516 QAR 56530 QAR 56529) (Patch ID: OSF410-400437) ******** Commands vquota, vedquota, quota, edquota, dump, csh, and nslookup will sometimes display the incorrect error message for non-english locales. PROBLEM: (QAR 60371) (Patch ID: OSF410-405461) ******** This patch fixes a problem in AdvFS that produced the following system panic: malloc_overflow: guard space corruption The panic will only occur when the kernel memory debugging option, kmem_debug, has its KMEM_DEBUG_OVERFLOW bit set. The panic occurs because AdvFS may not allocate enough memory to hold the domain and fileset names if the combined length of the domain name and fileset name given to the mount command totals 60 bytes or more. A typical stack trace would be: panic("malloc_overflow: guard space corruption") src/kernel/bsd/subr_prf.c :791 malloc_overflow src/kernel/bsd/kern_malloc.c : 3002 malloc_debug src/kernel/bsd/kern_malloc.c : 2897 free src/kernel/bsd/kern_malloc.c : 1510 _ms_free src/kernel/msfs/bs/ms_mode.c : 220 advfs_mountfs src/kernel/msfs/osf/msfs_vfsops.c : 1432 msfs_mount src/kernel/msfs/osf/msfs_vfsops.c : 1312 mount1 src/kernel/vfs/vfs_syscalls.c : 1024 mount src/kernel/vfs/vfs_syscalls.c : 771 syscall src/kernel/arch/alpha/syscall_trap.c : 556 _Xsyscall src/kernel/arch/alpha/locore.s : 1177 PROBLEM: (QAR 64441) (Patch ID: OSF410-405484) ******** This patch enhances the AdvFS verify utility to detect incorrect "holes" in frags file. PROBLEM: (QAR 57532) (Patch ID: OSF410-405485) ******** Threads which perform asyncronous I/O modify the state of the associated buffer after the request gets enqueued onto the lazy queue. If the lazy queue gets bypassed, then it is possible for the I/O to complete before the issuing thread modifies the buffer. Once the I/O completes, the buffer could be reassigned. The issuing thread still attempts to modify the buffer state, leading to an inconsistency and possibly a panic. PROBLEM: (QAR 63780, QAR 50419, QAR 55713) (Patch ID: OSF410-405487) ******** The patch fixes the following two problems in the AdvFS system; 1) an error path when the system is running out of vnodes. A sample stack trace is as follows: 0 stop_secondary_cpu(do_lwc = 0x0) 1 panic() 2 event_timeout() 3 xcpu_puts() 4 printf() 5 panic() 6 trap() 7 _XentMM() 8 _ms_free() 9 imm_delete_sub_xtnt_maps() 10 imm_delete_xtnt_map() 11 alloc_copy_stg() 12 migrate_normal() 2)a system hang due to access structures that should not be on the closed list. PROBLEM: (QAR 62761, QAR 63890, QAR 56860) (Patch ID: OSF410-405488) ******** This patch fixes a problem in the AdvFS system. The system hangs due to a deadlock between update daemon sync() syscall processing in AdvFS and the truncation of AdvFS file. The stack trace for update daemon hangs with: 0 thread_block() 1 lock_read() 2 msfs_putpage() 3 ubc_flush_dirty() 4 msfs_sync() 5 sync() 6 syscall() 7 7 _Xsyscall() The stack trace for the deadlocking with the update daemon is: 0 thread_block() 1 ubc_invalidate() 2 bs_real_invalidate_pages() 3 stg_remove_stg_start() 4 bf_setup_truncation() 5 msfs_setattr() 6 vn_open_ftrunc() 7 vn_open() 8 copen() 9 open() 10 syscall() 11 _Xsyscall() PROBLEM: (QAR 65404 QAR 61571 BCSM40F2Q) (Patch ID: OSF410-405489) ******** If vrestore is being run from a script and a control C is typed in order to abort vrestore, vrestore continues to run. PROBLEM: (QAR 60578) (Patch ID: OSF410-405494) ******** This patch corrects a problem observed when using the edquota command under the Advanced File System (AdvFS). The edquota command may display an incorrect grace period. The default grace period is a special case where the default of "0" is interpreted to mean "7 days." This was not being handled correctly by the edquota command functions, which incorrectly displayed "0" instead of the correct period of 7 days. PROBLEM: (QAR 65739, 64945) (Patch ID: OSF410-405509) ******** QAR 65739: The system can hang when inactivating an AdvFS domain. A domain is inactivated when the last fileset in the domain is unmounted or when a command like showfset is issued and no filesets in the domain are mounted. Inactivating a domain inactivates each volume in the domain. The fix allows more I/O to be started even though the volume is being inactivated. QAR 64945: Under some unusual circumstances (for example, mis administration or some ASE failovers), some volumes in a domain will not be specified in /etc/fdmns/. When this happens, activating the domain will change the state of the volumes specified in /etc/fdmns but not on other volumes that should belong to the domain. When the links in /etc/fdmns are restored, the domain will not be mountable because the volume states do not match. The fix prevents the state of the volumes from being changed unless all volumes in the domain conform to a prescribed set of requirements. PROBLEM: (QAR 58502,QAR 59094,QAR 61399,QAR 67023) (Patch ID: OSF410-405511) ******** This patch provides the following fixes and enhancements to AdvFS: - AdvFS volumes were not setting the default I/O byte transfer size to the preferred size reported by the disk drives. This caused I/O consolidations to be smaller than is optimal for the disks. This patch now assigns the driver's preferred I/O transfer byte size to all new AdvFS volumes created with mkfdmn and addvol. - AdvFS chvol read and write transfer size range was increased. With this patch the transfer size range is now between 16 and 3276 512-byte blocks. - The read-ahead algorithm was modified to improve performance under certain conditions. The algorithm now sanity checks the number of pages that it would attempt to prefetch and apply the following restrictions when doing its calculations: - only read-ahead the number of pages remaining in the file - use a predetermined percentage of the buffer pool for use as read-ahead buffers. PROBLEM: (QAR 62648,QAR 62577) (Patch ID: OSF410-405534) ******** This enhancement for the /sbin/advfs/verify utility allows it to detect loops in the list of free frags kept in the frags file. PROBLEM: (QAR 60215) (Patch ID: OSF410-405539) ******** Make vrestore work with QIC-120 and QIC-150 tapes PROBLEM: (QAR 67785, QAR 67460, CLDS MGO103947,BCSMC0NRQ, HPAQC0W3M, HPAQ10S59) (Patch ID: OSF410-405555) ******** This patch fixes a problem in which a system can hang because cleanup_closed_list() can go into a loop. PROBLEM: (HPAQ60H3T,HPAQ70WKD,QAR 66904) (Patch ID: OSF410-405565) ******** This patch fixes two problems with the vrestore command. First, the command was slow to complete when a partial restore operation was requested. Second, the command failed to ignore extended attribute records for the files which were not requested for a vrestore operation. PROBLEM: (HPAQC0B99) (Patch ID: OSF410-405572) ******** This patch fixes a problem in AdvFS with auditing enabled. During a rmvol operation, the system can panic with a "kernel memory fault" with a stack trace that is similar to the following: > 0 boot() 1 panic(s = 0xfffffc00005b60a8 = "kernel memory fault") 2 trap() 3 _XentMM() 4 audit_rec_build() 5 audit_call() 6 msfs_audit_syscall() 7 msfs_real_syscall() 8 msfs_syscall() 9 syscall() 10 _Xsyscall() PROBLEM: (BCPM117VX, QAR 68804) (Patch ID: OSF410-405577) ******** This patch fixes a problem where the "statfs" system call was reporting incorrect block usage on AdvFS filesets. As a side effect of this problem, the sendmail utility may sleep needlessly (waiting for space to become available). PROBLEM: (XIP100014, XIO100017) (Patch ID: OSF410-405588) ******** This patch fixes a problem on systems using the AdvFS filesystem, where the system can panic with the panic string: "del_clean_mcell_list: no primary xtnt record". The stack trace will be similar to: advfs_sad del_clean_mcell_list bs_bfdmn_activate bs_bfdmn_tbl_activate fs_fset_get_info msfs_real_syscall msfs_syscall syscall _Xsyscall PROBLEM: (QAR 63409) (Patch ID: OSF410-222) ******** This patch fixes two AdvFS problems: 1) When an AdvFS volume is nearly full, AdvFS files may become corrupt as they are closed. The verify utility can be used to detect this "overlapped frag corruption" problem. 2) The truncation of the fragment bitfile was erroneously being turned off. This feature allows AdvFS to give back disk space periodically. PROBLEM: (QAR 65927 QAR 68369 CLD BCPMB0JP3) (Patch ID: OSF410-243) ******** Due to a problem with truncation during multiplication of 2 integers, the wrong offset was being calculated. This caused the update daemon to hang. PROBLEM: (QAR 60967, QAR 53146) (Patch ID: OSF410-405468) ******** This patch fixes a problem in the AdvFS system. A domain panic message was not being written to the binary error log file. Note: This patch only works with versions of DECEvent 2.6 and higher. PROBLEM (QAR 64688) (Patch ID: OSF410-239) This patch fixes kernel memory fault system panic in routine spec_relcaim. A sample stack trace is as follows: 0 stop_secondary_cpu() 1 panic() 2 event_timeout() 3 xcpu_puts() 4 printf() 5 panic() 6 trap() 7 _XentMM() 8 spec_reclaim() 9 vgone() PROBLEM (QAR 66544) (Patch ID: OSF410-239) This patch fixes a problem with executing the "file" command against a lat (BSD) special device in which the "file" process will hang. The system needs to be rebooted in order to remove the hung process. PROBLEM (QAR 67757) (Patch ID: OSF410-239) This patch fixes a problem on multiCPU systems where hangs can occur in the revoke system call when multiple threads attempt to call "revoke" at the same time. A sample stack trace is as follows: 0 thread_block() 1 clearalias() 2 revoke() 3 syscall() 4 _Xsyscall() PROBLEM: (QAR 54840, QAR 60476, QAR 58938) (Patch ID: OSF410-241) ******** This patch fixes a problem in AdvFS where a complex lock in the ddl_wait_for_active_entry() routine would cause the thread to hang and possibly blocking other threads. If the system is set with lockmode = 4, a system panic would occur. PROBLEM: (BCGM703PQ,BCPM70WFJ,HPAQ920JJ,BCGMC0NZ8,HPAQA225S,BCGM210JL, HPAQ20Z8V) (Patch ID: OSF410-253) ******** This patch fixes a problem where several processes accessing the same AdvFS file can hang with the following stack trace: thread_block ubc_lookup page_lookup bs_refpg_int bs_refpg fs_read msfs_read vn_read rwuio read syscall _Xsyscall