"Jeff V. Merkey" wrote:
>
> >
> I am still seeing the following linker misbehavior while linking and
> building the linux 2.2.16 and 2.4.0-test5 source trees on a live NWFS
> Volume, but is goes away if you simply type 'make bzImage' over again
> and the make picks up where it left off. I am still tuning the page
> cache interface, so I suspect the problem may lie there or I need to
> release 2.5 as soon as possible with rapid mounting (which does not use
> the memory intensive name hashes) ...:
>
> BUG IN DYNAMIC LINKER: ld.so: rtld.c 601: dl_main: Assertion
> '_dl_rtld_map.l_libname' failed.
>
I have tracked this linker problem to the an auto-generated program
called 'conmakehash' that appears to build unicode tables for the os
that get linked to the kernel image. If I attempt to invoke this
program from an NWFS volume, it returns the linker error message above.
Anyone got any ideas? I looked at the source code for the program and
it appears benign enough.
:-)
Jeff
> Jeff Merkey
> CEO, TRG
>
> ------------------------------------------------------------------------
>
> NWFS 2.4.3 RELEASE NOTES
> ------------------------
>
> NWFS is a work in progress. TRG will continue to develop enhancements
> and new features to NWFS in the future. You are encouraged to report
> bugs or requests for feature enhancements to jmerkey@timpanogas.com
>
> This release supports Linux Kernels 2.0 and 2.2 and 2.4. NWFS 2.4.3
> source code can be downloaded from www.timpanogas.com or FTP at
> 207.109.151.240.
>
> This is an interim release that contains bug fixes. The next major
> release (2.5) uses a rapid mounting scheme with a journal that allows
> NetWare volumes to be mounted rapidly and demand-paged rather than
> needing to read the entire volume directory and name hashes into memory.
> The 2.5 version reduces memory usage to @ 1/80th of what we are using
> at present. 2.5 also supports files up to 256 tera-bytes in size
> depending on the OS architecture (Linux looks like 1TB max).
>
> ENHANCEMENTS
> -------------
>
> This release corrects a bug in the TurboFAT indexes that could cause file
> corruption. TurboFAT's keep a sliding pointer into the FAT chains of an
> NWFS volume for rapid sequential file access. This index stores the cluster offset and index last used by a read, write, or truncate to a fat chain. There
> was one case where a hash element could get reused with a stale TurboFAT
> index that pointed to the previous file's fat chain. This bug has been
> corrected.
>
> This release also corrects a bug in the rename() function. This function
> was coded to exhibit NetWare behavior, i.e. when a target file exists
> under NetWare and rename is attempted, the rename fails with a
> 'File Exists" return code. Linux expects that the VFS above will have
> already done these checks, and assumes the underlying FS will simply
> delete a rename target if it already exsits. The NWFS Linux VFS functions
> in create.c have been changed to reproduce this Linux specific behavior.
>
> The bit search lists and volume segment allocators have been optimized
> to reduce bit list searching to under a dozen or so probes while looking
> for free suballocation blocks or clusters on a NetWare volume. This
> optimization allows for very fast bit block search times even on
> extremely large multi-segmented NetWare volumes.
>
> The suballocation FAT chains also have been enabled to use TurboFAT
> indexing to speed suballoc read and write operations.
>
> We will attempt to post the page cache code and a fix for the symlink
> problem on 2.4.0-test5 tommorrow.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Aug 07 2000 - 21:00:10 EST