[ENBD] enbd_ioctl 2.6.9 kernel fails to modprobe enbd - seg fault

[scunacc]

Dear Peter et al.

Thank you for your reply.

> > I am having a problem with building ebnd and a 2.6.9 kernel.
> It shouldn't fail - I compile against 2.6.8 and 2.6.12 (for example)
> with no problems. Is there something special about 2.6.9 that would
> cause a problem?

I have read elsewhere over the last few weeks of multiple kernel
building (of 2.6.9) that 2.6.9 has a few odd problems. Yes.

However, I am stuck with it because of the bproc patches out of
Clustermatic 5 at the moment. 

The stock kernel on the system is 2.6.11, and I'd much rather use that
or later, but that's how it is I'm afraid. I have looked at patching the
bproc stuff onto a later kernel, but it's hours that I can't commit to
it on the project right now.

> > The compiler rev there is: gcc version 4.0.0 20050519 (Red Hat 4.0.0-8)
> I wouldn't trust that an inch, but that said, it's probably just
> complaining about something I don't notice. Can you show meteh compile
> problem?

Yes, I will - as I can - tomorrow hopefully.

> > which led me to move a couple of the static function definitions from
> > their placement inside functions to just before them. gcc 4 is picky
> > that way.
> 
> Can you let me see the error? There's nothing wrong with a local static
> fn.

No, I know, - but gcc 4 thinks there is! :-|

Same with forward declarations that use [] instead of * (not in your
code, but others I've had to mangle to make work with this particular
gcc 4.0

Again, it's a case of having committed to a particular solution that I
can't now easily back out of (not for some months anyway).

> > Noting a couple of changes mentioned by others, I also put the 
> > 
> >  > #ifdef __KERNEL_STRICT_NAMES
> >  >
> >  > #ifdef __CHECKER__
> >  > #define __bitwise __attribute__((bitwise))
> >  > #else
> >  > #define __bitwise
> >  > #endif
> 
> I've  no idea about that. Never heard of it!
> 
> >  > typedef __u16 __bitwise __le16;
> >  > typedef __u16 __bitwise __be16;
> >  > typedef __u32 __bitwise __le32;
> >  > typedef __u32 __bitwise __be32;
> >  > typedef __u64 __bitwise __le64;
> >  > typedef __u64 __bitwise __be64;
> 
> Uh ... none of those are used aywhere, are they? 

These are used inside something (can't recall w/o checking) that's
included by cdrom.h which you include in ioctl.c

I saw this answer posted by someone else - whether on enbd list as I
searched it or somewhere else on the web. Anyhow, I added that and it
did indeed fix the (identical) problem.

> It sounds to me
> like you have some RH adaptations in the kernel ... 

Not RH, but certainly some, - the bproc ones for example.

Also, this *particular* build is running in vmware, so the vmware
drivers are also loaded, but, the same kernel will be net booted across
a bproc cluster, on "real" hardware. (It has to work on both).

> check the compile
> against a non-RH kernel to make sure. 

Hmmm. That might be tricky on that system. May be able to on my own home
system running Mandriva 2006 with a 2.6.12 kernel. I'll have to see if I
can arrange that.

> And confirm that 2.6.8.1 compiles
> OK ... I have that. We might as well check that we agree. And compile
> with -O1 for luck.

Now that latter tip is interesting. Yes. I've seen other posts about
2.6.9 (or it might have been gcc 4) on *occasion* being unhappy with a
-O2 compile. Hmmm. I'll look at that as a possibility too.

Many thanks.

(I'll try and post a few more details tomorrow. It's kinda late here now
and I've just replied after getting home this evening.)

Kind regards

Derek Jones.