Thread: Re: [Jfs-discussion] Re: rwsems, jfs, kernel 2.5.6
Brought to you by:
blaschke-oss,
shaggyk
From: David H. <dho...@re...> - 2002-03-21 10:33:59
|
> As "tmp" is not referenced after the assembly, I removed it from the > output list and added it to the input list. This appears to fix it. Do > you see anything wrong with removing tmp from the output list? Yes. You've told the compiler that the value in tmp hasn't changed and so it is free to re-use it. The way to do it is just to use the "=" constraint and split the "d" register value: "# ending __up_read\n" - : "+m"(sem->count), "+d"(tmp) - : "a"(sem) + : "+m"(sem->count), "=d"(tmp) + : "a"(sem), "1"(tmp) : "memory", "cc"); However, if I remember rightly, this has some other adverse side effects on the compiler:-( But it is the only other way to do it. David |
From: David H. <dho...@re...> - 2002-03-21 16:56:40
|
> This doesn't help. It still fails the same way compiling jfs_imap.c. Try splitting the "+m" too. David |
From: Dave K. <sh...@au...> - 2002-03-21 17:05:57
|
On Thursday 21 March 2002 07:56 am, David Howells wrote: > > This doesn't help. It still fails the same way compiling > > jfs_imap.c. > > Try splitting the "+m" too. I tried something else first, and it seems to work. I got rid of the tmp variable altogether and implemented to look more like up_write: --- include/asm-i386/rwsem.h.orig Mon Feb 25 14:59:07 2002 +++ include/asm-i386/rwsem.h Thu Mar 21 07:53:43 2002 @@ -148,9 +148,9 @@ */ static inline void __up_read(struct rw_semaphore *sem) { - __s32 tmp = -RWSEM_ACTIVE_READ_BIAS; __asm__ __volatile__( "# beginning __up_read\n\t" + " movl %2,%%edx\n\t" LOCK_PREFIX " xadd %%edx,(%%eax)\n\t" /* subtracts 1, returns the old value */ " js 2f\n\t" /* jump if the lock is being waited upon */ "1:\n\t" @@ -164,9 +164,9 @@ " jmp 1b\n" LOCK_SECTION_END "# ending __up_read\n" - : "+m"(sem->count), "+d"(tmp) - : "a"(sem) - : "memory", "cc"); + : "+m"(sem->count) + : "a"(sem), "i"(-RWSEM_ACTIVE_READ_BIAS) + : "memory", "cc", "edx"); } /* |
From: Dave K. <sh...@au...> - 2002-03-21 17:51:17
|
On Thursday 21 March 2002 07:56 am, David Howells wrote: > > This doesn't help. It still fails the same way compiling > > jfs_imap.c. > > Try splitting the "+m" too. Tried splitting just the +m. This seems to work as well. We seem to have two patches that work around the problem, but I guess this really is a gcc bug that should be fixed. --- include/asm-i386/rwsem.h.orig Mon Feb 25 14:59:07 2002 +++ include/asm-i386/rwsem.h Thu Mar 21 08:30:44 2002 @@ -164,8 +164,8 @@ " jmp 1b\n" LOCK_SECTION_END "# ending __up_read\n" - : "+m"(sem->count), "+d"(tmp) - : "a"(sem) + : "=m"(sem->count), "+d"(tmp) + : "a"(sem), "m"(sem->count) : "memory", "cc"); } |
From: David H. <dho...@re...> - 2002-03-22 01:54:15
|
- : "+m"(sem->count), "+d"(tmp) - : "a"(sem) + : "=m"(sem->count), "+d"(tmp) + : "a"(sem), "m"(sem->count) Try replacing '"m"(sem->count)' with '"0"(sem->count)' which should link to the first output constraint in this case. David |
From: Dave K. <sh...@au...> - 2002-03-22 16:52:50
|
On Thursday 21 March 2002 04:54 pm, David Howells wrote: > - : "+m"(sem->count), "+d"(tmp) > - : "a"(sem) > + : "=m"(sem->count), "+d"(tmp) > + : "a"(sem), "m"(sem->count) > > Try replacing '"m"(sem->count)' with '"0"(sem->count)' which should > link to the first output constraint in this case. For whatever reason, it still fails with the "0". |
From: David H. <dho...@re...> - 2002-03-22 17:07:36
|
> For whatever reason, it still fails with the "0". :-/ I hate gcc inline asm sometimes:-) David |
From: <ra...@gi...> - 2005-06-21 17:44:58
|
> From: Dave Kleikamp <snip> > Unfortunately, the damage extends to the root directory, which can't be > ignored. Since fsck says that your primary & secondary allocation > structures don't match, you could try forcing jfs_fsck to use the > secondary instead of the primary. This untested patch should do that. <snip> That patch doesn't resolve the problem... s5n06.hep(rader): sudo ./jfs_fsck -d -f /dev/sda1 ./jfs_fsck version 1.1.8, 03-May-2005 processing started: 6/21/2005 8.40.29 The current device is: /dev/sda1 [xchkdsk.c:1555] Open(...READ/WRITE EXCLUSIVE...) returned rc = 0 [fsckpfs.c:3227] Primary superblock is valid. [fsckmeta.c:1559] The type of file system for the device is JFS. [xchkdsk.c:1572] Block size in bytes: 4096 [xchkdsk.c:1899] Filesystem size in blocks: 586057467 [xchkdsk.c:1906] **Phase 0 - Replay Journal Log [xchkdsk.c:1913] LOGREDO: Log already redone! [logredo.c:555] logredo returned rc = 0 [xchkdsk.c:1945] **Phase 1 - Check Blocks, Files/Directories, and Directory Entries [xchkdsk.c:2038] Invalid data (7) detected in file system object MA1. [fsckmeta.c:2465] Invalid data (8) detected in file system object MA1. [fsckmeta.c:2473] Invalid data (9) detected in file system object MA1. [fsckmeta.c:2481] Invalid data (10) detected in file system object MA1. [fsckmeta.c:2489] Invalid data (11) detected in file system object MA1. [fsckmeta.c:2500] Invalid data (12) detected in file system object MA1. [fsckmeta.c:2508] Invalid data (13) detected in file system object MA1. [fsckmeta.c:2516] Invalid data (14) detected in file system object MA1. [fsckmeta.c:2524] Secondary metadata inode A1 is corrupt. [fsckmeta.c:2565] Unable to read the Primary File/Directory Allocation Table. [fsckmeta.c:1897] Errors detected in the Secondary File/Directory Allocation Table. [fsckmeta.c:1904] CANNOT CONTINUE. [fsckmeta.c:1911] processing terminated: 6/21/2005 8:40:30 with return code: -10049 exit code: 4. [xchkdsk.c:469] s5n06.hep(rader): grep FSCK_FAILED_BOTHAITBAD *.h xfsck.h:#define FSCK_FAILED_BOTHAITBAD -10049 The file system now appears in the same sorry shape as the file system a colleage of mine experienced with the exactly same hardware and os... http://sourceforge.net/mailarchive/message.php?msg_id=10804175 What'dya make of that? Fwiw (nothing??), I patched around the failure above... *************** *** 1903,1910 **** agg_recptr->ag_dirty = 1; fsck_send_msg(fsck_CANTCONTINUE); } else if (primary_part1_bad && secondary_part1_bad) { ! agg_recptr->ag_dirty = 1; ! fsck_send_msg(fsck_CANTCONTINUE); } else if (primary_part2_bad && secondary_part2_bad) { agg_recptr->ag_dirty = 1; fsck_send_msg(fsck_CANTCONTINUE); --- 1907,1916 ---- agg_recptr->ag_dirty = 1; fsck_send_msg(fsck_CANTCONTINUE); } else if (primary_part1_bad && secondary_part1_bad) { ! //agg_recptr->ag_dirty = 1; ! //fsck_send_msg(fsck_CANTCONTINUE); ! printf("SRDEBUG Ignoring primary_part1_bad && secondary_part1_bad\n"); ! vsait_rc = FSCK_OK; } else if (primary_part2_bad && secondary_part2_bad) { agg_recptr->ag_dirty = 1; fsck_send_msg(fsck_CANTCONTINUE); ....and the result is malloc() in alloc_wsp_extent() is failing... s5n06.hep(rader): sudo ./jfs_fsck -d -f /dev/sda1 ./jfs_fsck version 1.1.8, 03-May-2005 processing started: 6/21/2005 9.0.52 The current device is: /dev/sda1 [xchkdsk.c:1555] Open(...READ/WRITE EXCLUSIVE...) returned rc = 0 [fsckpfs.c:3227] Primary superblock is valid. [fsckmeta.c:1559] The type of file system for the device is JFS. [xchkdsk.c:1572] Block size in bytes: 4096 [xchkdsk.c:1899] Filesystem size in blocks: 586057467 [xchkdsk.c:1906] **Phase 0 - Replay Journal Log [xchkdsk.c:1913] LOGREDO: Log already redone! [logredo.c:555] logredo returned rc = 0 [xchkdsk.c:1945] **Phase 1 - Check Blocks, Files/Directories, and Directory Entries [xchkdsk.c:2038] Invalid data (7) detected in file system object MA1. [fsckmeta.c:2464] Invalid data (8) detected in file system object MA1. [fsckmeta.c:2472] Invalid data (9) detected in file system object MA1. [fsckmeta.c:2480] Invalid data (10) detected in file system object MA1. [fsckmeta.c:2488] Invalid data (11) detected in file system object MA1. [fsckmeta.c:2499] Invalid data (12) detected in file system object MA1. [fsckmeta.c:2507] Invalid data (13) detected in file system object MA1. [fsckmeta.c:2515] Invalid data (14) detected in file system object MA1. [fsckmeta.c:2523] Secondary metadata inode A1 is corrupt. [fsckmeta.c:2564] Unable to read the Primary File/Directory Allocation Table. [fsckmeta.c:1897] Errors detected in the Secondary File/Directory Allocation Table. [fsckmeta.c:1904] SRDEBUG Ignoring primary_part1_bad && secondary_part1_bad Insufficient dynamic storage available for required workspace (1,6). CANNOT CONTINUE [fsckwsp.c:287] processing terminated: 6/21/2005 9:06:30 with return code: -10097 exit code: 8. [xchkdsk.c:469] ugh. steve - - - systems & network manager high energy physics university of wisconsin |
From: Dave K. <sh...@au...> - 2005-06-21 17:36:49
|
On Tue, 2005-06-21 at 09:07 -0500, ra...@gi... wrote: > > From: Dave Kleikamp > <snip> > > Unfortunately, the damage extends to the root directory, which can't be > > ignored. Since fsck says that your primary & secondary allocation > > structures don't match, you could try forcing jfs_fsck to use the > > secondary instead of the primary. This untested patch should do that. > <snip> > > That patch doesn't resolve the problem... > > s5n06.hep(rader): sudo ./jfs_fsck -d -f /dev/sda1 > ./jfs_fsck version 1.1.8, 03-May-2005 > processing started: 6/21/2005 8.40.29 > The current device is: /dev/sda1 [xchkdsk.c:1555] > Open(...READ/WRITE EXCLUSIVE...) returned rc = 0 [fsckpfs.c:3227] > Primary superblock is valid. [fsckmeta.c:1559] > The type of file system for the device is JFS. [xchkdsk.c:1572] > Block size in bytes: 4096 [xchkdsk.c:1899] > Filesystem size in blocks: 586057467 [xchkdsk.c:1906] > **Phase 0 - Replay Journal Log [xchkdsk.c:1913] > LOGREDO: Log already redone! [logredo.c:555] > logredo returned rc = 0 [xchkdsk.c:1945] > **Phase 1 - Check Blocks, Files/Directories, and Directory Entries [xchkdsk.c:2038] > Invalid data (7) detected in file system object MA1. [fsckmeta.c:2465] > Invalid data (8) detected in file system object MA1. [fsckmeta.c:2473] > Invalid data (9) detected in file system object MA1. [fsckmeta.c:2481] > Invalid data (10) detected in file system object MA1. [fsckmeta.c:2489] > Invalid data (11) detected in file system object MA1. [fsckmeta.c:2500] > Invalid data (12) detected in file system object MA1. [fsckmeta.c:2508] > Invalid data (13) detected in file system object MA1. [fsckmeta.c:2516] > Invalid data (14) detected in file system object MA1. [fsckmeta.c:2524] > Secondary metadata inode A1 is corrupt. [fsckmeta.c:2565] > Unable to read the Primary File/Directory Allocation Table. [fsckmeta.c:1897] > Errors detected in the Secondary File/Directory Allocation Table. [fsckmeta.c:1904] > CANNOT CONTINUE. [fsckmeta.c:1911] Well, the secondary seems to be in worse shape than the primary, so this experiment didn't help. > The file system now appears in the same sorry shape as the file > system a colleage of mine experienced with the exactly same hardware > and os... > > http://sourceforge.net/mailarchive/message.php?msg_id=10804175 > > What'dya make of that? In that case, there was no mention of any problems with the hardware underneath the file system. In your case, you mentioned that there was a raid problem (hiccup) that triggered the jfs failures. > Fwiw (nothing??), I patched around the failure above... I wouldn't expect anything to succeed at this point. > ugh. yeah... > steve > - - - > systems & network manager > high energy physics > university of wisconsin > -- David Kleikamp IBM Linux Technology Center |
From: Sean M. <sm...@cs...> - 2005-06-21 19:41:14
|
On Jun 21, 2005, at 9:07 AM, ra...@gi... wrote: > > The file system now appears in the same sorry shape as the file > system a colleage of mine experienced with the exactly same hardware > and os... > > http://sourceforge.net/mailarchive/message.php?msg_id=10804175 > > What'dya make of that? It actually turns out that problem was caused by an underlying problem with the LVM code in the linux kernel. Sean Murphy sm...@cs... |
From: Dave K. <sh...@au...> - 2002-03-21 16:52:14
|
On Thursday 21 March 2002 01:33 am, David Howells wrote: > > As "tmp" is not referenced after the assembly, I removed it from > > the output list and added it to the input list. This appears to > > fix it. Do you see anything wrong with removing tmp from the > > output list? > > Yes. You've told the compiler that the value in tmp hasn't changed > and so it is free to re-use it. Okay, I understand. > > The way to do it is just to use the "=" constraint and split the "d" > register value: > > "# ending __up_read\n" > - : "+m"(sem->count), "+d"(tmp) > - : "a"(sem) > + : "+m"(sem->count), "=d"(tmp) > + : "a"(sem), "1"(tmp) > > : "memory", "cc"); This doesn't help. It still fails the same way compiling jfs_imap.c. > > However, if I remember rightly, this has some other adverse side > effects on the compiler:-( But it is the only other way to do it. I'll keep trying. > > David |