Brian Hall wrote:
>
> So basically everywhere I see a GET_BLOCK(whatever, 4, &something), I should
> change the 4 to an 8?
If you are loading an 8 byte value from kernel memory (say a pointer value) AND
you are loading it into an eight byte local variable (buffer), then yes. But it
might be possible that you will have cases where the size will stay the same
(say if you are loading an int value that is 4 bytes in both 32 and 64-bit
world).
BTW, all of these kinds of calls (reading in pointer values via GET_BLOCK())
should
be located in arch specific modules. If you find one that isn't (quite
possible),
please let me know and I'll make sure it gets taken care of.
Thanks,
Tom
>
> On 27-Apr-2000 Tom Morano wrote:
> > The parameters to init_liballoc() are OK. Based on this, I would guess that
> > some memory is getting stomped on in or below the kl_init_kern_info()
> > function
> > call. You might check the block of memory causing the SEGV after returning
> > from the init_liballoc() call and before the kl_init_kern_info() call. See
> > if
> > it
> > looks OK at that point (I would guess the contents of this memory is change
> > by
> > the time you get to register_cmds()). If that's the case, then walk through
> > the
> > kl_init_kern_info() function and see where the memory contents changes. From
> > looking at the kl_init_kern_info() function, I can't see where the problem
> > might
> > occur (it basically just does symbol lookups and reads in the contents of
> > memory
> > into some local variables). Since the Alpha is 64 bit, I assume that the
> > amount
> > of
> > memory being read in for these values is 8 bytes instead of 4 (and that the
> > local
> > variables, NUM_PHYSPAGES and MEM_MAP have been changed also). Little things
> > like
> > that might be a factor. Anyway, that's how I would approach narrowing it
> > down.
>
> --
> http://www.bigfoot.com/~brihall
> Linux Consultant
|