PROBLEM: (ZPOB82799) (Patch ID: OSF415-410031) ******** 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: OSF415-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: OSF415-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: OSF415-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, QAR46237) (Patch ID: OSF415-400176-1) ******** On an AdvFS system, a broadcast message will cause the idle time to be reset to zero. (Patch ID: OSF415-400176-1) PROBLEM: (QAR 36779) (Patch ID: OSF415-405098 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: OSF415-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: OSF415-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: OSF415-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: OSF415-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 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. 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 identify 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: (CLD UTO101199,HPAQ30ETE, QAR 51485,52365) (Patch ID: OSF415-410087) ******** (Patch ID OSF415-029 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: (UVO105186) (Patch ID: OSF415-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: (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: (UVO105368) (Patch ID: OSF415-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: (QAR 50858,QAR 44602,QAR 44776) (Patch ID: OSF415-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 the following error message: panic (cpu 0): bfs_invalidate: not on free list syncing disks...done PROBLEM: (HPXQB22D0, QAR 45498) (Patch ID: OSF415-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: (GOZ100774) (Patch ID: OSF415-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: OSF415-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: OSF415-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). When a user specified the "-t" option, vrestore erroneously attempted to restore proplists on files that had them; issuing same warning messages. PROBLEM: ( FNO100126, UTO101198, MGO102729, UVO105463, MGO102993, TKTB91678, ******** QAR 43407) (Patch ID: OSF415-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, QAR 46833) (Patch ID: OSF415-410092) ******** 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: (QAR 55308, QAR 55447) (Patch ID: OSF415-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 51816,QAR 45334) (Patch ID: OSF415-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: OSF415-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_startio() Note: Users should also not attempt to reduce the AdvFS per-volume cache to zero. This could result in mismanagement of buffers associated with that device and could cause further panics or corruptions. This is generally done by performing "chvol -t 0 domain". In a future release this will be disallowed. PROBLEM: (QAR 57680,57689,58050,49803) (Patch ID: OSF415-400476) ******** 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: (QAR 56845, QAR 56403) (Patch ID: OSF415-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,54852) (Patch ID: OSF415-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, 0xfffffc0007cc00 18) ["../../../../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 57938, QAR 50417) (Patch ID: OSF415-405146) ******* This patch corrects a problem in AdvFS where a data structure field is not initialized until after an AdvFS mount which is too late. This results in the inability for example to see the files after a remount. An example of this problem would be the ls command not being able to list files on an AdvFS mounted filesystem that is NFS exported. PROBLEM: (TKTRA2376) (Patch ID: OSF415-410118) ******** 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,36473,44706,49895) (Patch ID: OSF415-410123) ******** 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 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: OSF415-410128) ******** 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 57258,56851) (Patch ID: OSF415-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: OSF415-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: OSF415-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: OSF415-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() fs_cleanup_thread() PROBLEM: (QARs 57927,58380,57750,55812,46684,52548,53105) ******** (PatchID: OSF415-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 frag files (>2GB); gives detailed warning messages when a frag file is found to be incorrectly terminated, helping the user to know which be incorrectly terminated, helping the user to know which file's fragments are involved; 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; 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 domains can be worked with. PROBLEM: (QAR 56152, QAR 55813) (Patch ID: OSF415-410129) ******** 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 55791, QAR 55773) (Patch ID: OSF415-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, QAR 57702) (Patch ID: OSF415-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: OSF415-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 57625, QAR 57639, QAR 58959, QAR 58241) (Patch ID: OSF415-405171) ******** This patch fixes an AdvFS problme tha causes a lockmode 4 system panic. A sample stack trace is as follows: 0 boot() 1 panic() 2 thread_block() 3 thread_preempt() 4 boot() 5 panic() 6 lock_fault() 7 lock_read() 8 prom_getenv() 9 lk201_reset_keyboard() 10 wsputc() 11 sccputc() 12 cnputc() 13 cons_puts() 14 printf() 15 lock_fault() 16 lock_write() 17 fuser() 18 syscall() 19 _Xsyscall() PROBLEM: (QAR 55640, QAR 51918) (Patch ID: OSF415-405172) ******** This patch fixes AdvFS performance problems. PROBLEM: (Patch ID: OSF415-405205) ******** This patch fixes a problem in which vrestore can cause an occasional core dump (Foating Exception). PROBLEM: (MCGMC03FC,HPAQ11P4K,EVT102458,MGO103284,QAR 58879) (Patch ID: OSF415-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: OSF415-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 56366, QAR 56062) (Patch ID: OSF415-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: OSF415-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: OSF415-405228) ******** This patch corrects a panic and hang situation due to a limit of advfs access structures. PROBLEM: (QAR 54322,QAR 57034) (Patch ID: OSF415-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: OSF415-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: OSF415-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: OSF415-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: OSF415-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: (QAR 52487,QAR 58963) (Patch ID: OSF415-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: (CLD SOO101109) (Patch ID: OSF415-405253) ******** This patch fixes a problem that occurred when an AdvFS panic crashed the customer's 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: (QAR 56824, QAR 55656) (Patch ID: OSF415-410126) ******** 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 one that timed out) will be one whose stack trace includes 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, QAR 56851) (Patch ID: OSF415-410163) ******** 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 58740) (Patch ID: OSF415-410156) ******** 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: (EVT102509 GOZ100927 QAR 60509) (Patch ID: OSF415-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: OSF415-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: OSF415-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: OSF415-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: OSF415-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 54246,QAR 57344) (Patch ID: OSF415-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 57450) (Patch ID: OSF415-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: OSF415-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: OSF415-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 44395,QAR 45174,QAR 45558,QAR 45561,QAR 45639) (Patch ID: OSF415-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 55008,QAR 60308) (Patch ID: OSF415-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: OSF415-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: ) ******** 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 57304,QAR 50820,QAR 57898,QAR 59077) (Patch ID: OSF415-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 60129, QAR 62613) (Patch ID: OSF415-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: OSF415-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 62299, QAR 51568, HPAQ60W1F, QAR 62617, QAR 62610, UVO106018, QAR 61185, QAR 63686, QAR 63703, QAR 54276, QAR 60262) (Patch ID: OSF415-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 61275, QAR 61777) (Patch ID: OSF415-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: OSF415-405438) ******** This patch 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: OSF415-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: OSF415-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 59953, QAR 59419) (Patch ID: OSF415-410159) ******** 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 55975, QAR 53061) (Patch ID: OSF415-405203) ******** This patch fixes a problem in the chvol command. chvol was not recognizing LSM volumes. PROBLEM: (QAR 60922, QAR 55002, QAR 46115) (Patch ID: OSF415-410169) ******** 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 60888, QAR 61768, QAR 58064) (Patch ID: OSF415-410180) ******** 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 62673,QAR 61388) (Patch ID: OSF415-410202) ******** 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 56531 QAR 56516 QAR 56530 QAR 56529) (Patch ID: OSF415-400437) ******** Commands vquota, vedquota, quota, edquota, dump, csh, and nslookup will sometimes display the incorrect error message for non-english locales.