[OpenAFS] Re: modload failing, Sol10 SPARC, 1.4.14

[Jeff Blaine]

FWIW, I can't get any workaround to work.  Iterative
setting of -O to -O2 where I could find it across
various builds got me finally to here where I gave up:

bash-3.00# /usr/sbin/modload 
sun4x_510/dest/root.client/usr/vice/etc/modload/libafs64.o
can't load module: Out of memory or no room in system tables

May 31 18:01:47 rcf-afs-test.our.org genunix: [ID 104096 kern.warning] 
WARNING: system call missing from bind file

I then rebooted and got the same result upon trying modload
again.

I edited:

src/cf/osconf.m4
src/libuafs/MakefileProto.SOLARIS.in
src/libafs/MakefileProto.SOLARIS.in

On 5/31/2011 2:13 PM, Andrew Deason wrote:
> On Tue, 31 May 2011 12:14:31 -0500
> Andrew Deason<adeason@sinenomine.net>  wrote:
>
>> Or I can just find it by commenting stuff out and seeing when the
>> _memset ref goes away. It appears to be this loop that's causing it, in
>> afs_RebuildDynroot lines 378/379:
>>
>>      for (i = 0; i<  NHASHENT; i++)
>>              dirHeader->hashTable[i] = 0;
>>
>> which makes sense; that's pretty easily optimizable into a memset.
>>
>> I'll get a simpler demonstration together to submit to Oracle.
>
> Also, Jeff, if you want a quick workaround, you can change -O to -O2 or
> just leave out the -O option. I think changing the value of KERN_OPTMZ
> in src/cf/osconf.m4 should be enough...
>
> And now I'm not completely sure if this is a bug or if we're just
> missing the magic incantation to make this not happen. A simple test
> case:
>
> void
> foo(short *arr)
> {
>      int i;
>      for (i = 0; i<  256; i++)
>          arr[i] = 0;
> }
>
> If you compile with 'cc foo.c -c -o foo.o -O3', you get a reference to
> _memset. If you compile with -O2 or below, you don't. Passing
> -xbuiltin=%none, any of the -xno*lib or -xc99 etc options don't seem to
> change anything. With older versions of Sun/Solaris Studio, it never
> seems to call _memset.
>
> The Oracle documentation on this is puzzling to me:
> <http://download.oracle.com/docs/cd/E19205-01/821-1384/gjzku/index.html>
>
> It says "The following table lists runtime support functions that may be
> called in code compiled to run in the Solaris kernel, as a result of
> source code translation by the C compiler." the table includes _memset,
> _memcpy, et al. Then it says
>
> "Note that some versions of the kernel do not provide _memmove(),
> _memcpy(), or _memset(), but do provide kernel mode analogues of the
> user mode routines memmove(), memcpy(), and memset()."
>
> But it doesn't say how to avoid it. I'm not sure if there's a compiler
> flag we're missing here, or if it's not supported to use -O3 for kernel
> modules, or... ? Or it's just a bug. It's also interesting that this
> doesn't happen on amd64, though I assume that's just because it uses
> different arch-specific optimizations.
>
> I don't know, should I just try to file a bug anyway, or should we try
> to get someone with a support contract to say something?
>