headers
Dr. Volker Jaenisch | 19 Sep 2007 00:04
Picon

Compiling under AMD64 fails

Hello Peter!

I stuck at similar errors as Lothar compiling
the 2.4.33 version of endb under debian etch with
kernel 2.6.18 (and also 2.6.22).

Any hint is welcome!

Best Regards,

Volker

charyptis:~/enbd/enbd-2.4.33# uname -a
Linux charyptis 2.6.18-5-xen-amd64 #1 SMP Thu Aug 30 02:48:14 UTC 2007 
x86_64 GNU/Linux
charyptis:~/enbd/enbd-2.4.33# make
mkdir -p /tmp
cp nbd/configure /tmp/configure && chmod +x /tmp/configure
make config
make[1]: Entering directory `/root/enbd/enbd-2.4.33'
export CONFIG_SITE=/root/enbd/enbd-2.4.33/nbd/conf/config.Linux; \
        cd /tmp;  ./configure --srcdir=/root/enbd/enbd-2.4.33/nbd  \
                                  --with-kernel-srcdir=/usr; \

loading site script /root/enbd/enbd-2.4.33/nbd/conf/config.Linux
creating cache ./config.cache
checking for gcc... gcc
checking whether the C compiler (gcc -D_LARGEFILE64_SOURCE=1 
-D_LARGEFILE_SOURCE=1 -D_GNU_SOURCE=1 -D_XOPEN_SOURCE=1 
-D_FILE_OFFSET_BITS=64 -Wall -Winline -O2 -I/usr/include ) works... yes
(Continue reading)

Permalink | Reply | 8 comments |
headers
Peter T. Breuer | 19 Sep 2007 23:22
Picon

Re: Compiling under AMD64 fails

"Also sprach Dr. Volker Jaenisch:"
> I stuck at similar errors as Lothar compiling
> the 2.4.33 version of endb under debian etch with
> kernel 2.6.18 (and also 2.6.22).

I have a amd64 so one would have thought it worked. I'll check 2.4.33.
(my amd64 makes an awful noise and it is late!)

Peter
Permalink | Reply | 1 comment |
headers
Dr. Volker Jaenisch | 20 Sep 2007 00:20
Picon

Re: Compiling under AMD64 fails

Hi Peter!

Peter T. Breuer wrote:
> "Also sprach Dr. Volker Jaenisch:"
>   
>> I stuck at similar errors as Lothar compiling
>> the 2.4.33 version of endb under debian etch with
>> kernel 2.6.18 (and also 2.6.22).
>>     
>
> I have a amd64 so one would have thought it worked. I'll check 2.4.33.
> (my amd64 makes an awful noise and it is late!)
>   
Our AMD64s are noisy too - but they live in the DC far away :-).
If you like to have a testing facility that is more quiet we can supply 
you a root login
on one of our VMs.

Thank you very much for your efford!

Best regards,

Volker

--

-- 
====================================================
   inqbus it-consulting      +49 ( 341 )  5643800
   Dr.  Volker Jaenisch      http://www.inqbus.de
   Herloßsohnstr.    12      0 4 1 5 5    Leipzig
   N  O  T -  F Ä L L E      +49 ( 170 )  3113748
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter T. Breuer | 20 Sep 2007 00:29
Picon

Re: Compiling under AMD64 fails

"Also sprach Dr. Volker Jaenisch:"
> I stuck at similar errors as Lothar compiling
> the 2.4.33 version of endb under debian etch with
> kernel 2.6.18 (and also 2.6.22).

I should add that it was enbd 2.4.34 that I was using perfectly under
kernel 2.6.20.something (or later - I don't want to turn on my noisy
amd64 to check) a few weeks ago. I performed extended tests for at
least a week.

As I recall, there were changes in the kernel around 2.6.18/19/20 that
have a considerable impact and I had to make some changes to cater for
those. 

> Any hint is welcome!

Well, try 2.4.34 and tell me if it works for you. Then we can
interpolate!

> gcc -DCONFDIR="\"/etc\"" -DPIDDIR="\"/var/run\"" 
> -DSTATEDIR="\"/var/state/enbd\"" -D_LARGEFILE64_SOURCE=1 
> -D_LARGEFILE_SOURCE=1 -D_GNU_SOURCE=1 -D_XOPEN_SOURCE=1 
> -D_FILE_OFFSET_BITS=64 -Wall -Winline 
> -O2                                   
> -I/tmp                                   
> -I/root/enbd/enbd-2.4.33/kernel/linux-2.6.x/include                                   
> -I/usr/include                                     -D__SMP__ 
> -DCONFIG_X86_LOCAL_APIC                                   -DDEBUG=0 -o 
> enbd-server.o -c /root/enbd/enbd-2.4.33/nbd/enbd-server.c
> /root/enbd/enbd-2.4.33/nbd/enbd-server.c: In function 'do_srv_write':
(Continue reading)

Permalink | Reply | 5 comments |
headers
Dr. Volker Jaenisch | 20 Sep 2007 00:37
Picon

Re: Compiling under AMD64 fails

Peter T. Breuer wrote:
> Well, try 2.4.34 and tell me if it works for you. Then we can
> interpolate!
>   
Ok. Starting test with 2.4.34
Stay tuned.

Best regards,

Volker

--

-- 
====================================================
   inqbus it-consulting      +49 ( 341 )  5643800
   Dr.  Volker Jaenisch      http://www.inqbus.de
   Herloßsohnstr.    12      0 4 1 5 5    Leipzig
   N  O  T -  F Ä L L E      +49 ( 170 )  3113748
====================================================
Permalink | Reply | 0 comments |
headers
Dr. Volker Jaenisch | 20 Sep 2007 01:03
Picon

Re: Compiling under AMD64 fails

Hi Peter!

Peter T. Breuer wrote:
> Well, try 2.4.34 and tell me if it works for you. Then we can
> interpolate!
>   
Sorry for the complaining!

2.4.34pre compiles flawlessly under AMD64.

Maybe you should remove the "pre" suffix to encourage precautious people 
to use it. :-)

Thank you very much.

We will share our experiances with endb.

<OFF TOPIC>
Backgroud:
We are performing a study on cheap linux SAN structures. We will test 
most of the combinations
of DRBD, (X)NDB, iSCSI, ATAoE with Software-RAID, OCFS2, NFS and maybe 
openGFS.
The motivation for our analysis is the paper
http://www.linux-magazin.de/heft_abo/ausgaben/2006/07/block_spirale?special=Storage&category=13791
</OFF TOPIC>

NDB below Software-RAID gives very promising performance results. The 
only problem is the stability of NDB
in case of network trouble. We are optimistic that enbd is more robust
(Continue reading)

Permalink | Reply | 3 comments |
headers
Peter T. Breuer | 20 Sep 2007 13:33
Picon

Re: Compiling under AMD64 fails

"Also sprach Dr. Volker Jaenisch:"
> 2.4.34pre compiles flawlessly under AMD64.

Actually, now I'm aware of the situation, I'll carefully back port the
minor changes required for just compilation on amd64 to the stable
2.4.33.  For cautious people.

> Maybe you should remove the "pre" suffix to encourage precautious people 
> to use it. :-)

> We will share our experiances with endb.

Be aware that I had to work on other things (hard input for static
annalysis of kernel C) for a couple of years and am only now getting
back into the swing of thigs with enbd and raid. I talked to Neil Brown
(the kernel soft raid maintainer)  and I believe we are agreed that a
special "slow mode" is needed for raid where one component is a network
device like enbd, and I will work in the coming weeks or months to
provide it.

If I ever get a millisecond to actually do _anything_.

The problem to be solved is what I explained to you in another mail ...

  ... under write pressure to a network device the linux kernel will
  fill all buffers with dirty stuff to go to the net, but then won't
  have any memory to spare to form tcp buffers with which it can
  actually send it out!

Under very recent kernels (as I tested a few weeks ago) it doesn't seem
(Continue reading)

Permalink | Reply | 2 comments |
headers
Peter T. Breuer | 22 Sep 2007 20:58
Picon

Re: Compiling under AMD64 fails

"Also sprach Peter T. Breuer:"
> "Also sprach Dr. Volker Jaenisch:"
> > 2.4.34pre compiles flawlessly under AMD64.
> 
> Actually, now I'm aware of the situation, I'll carefully back port the
> minor changes required for just compilation on amd64 to the stable
> 2.4.33.  For cautious people.

I did that (only a question of adding casts into some error print
statements) ..  I was able to confirm that everything compiles, but no
more, since enbd 2.4.33 only has a chance of compiling up till kernel
2.6.15.x (x maximal) due to profound kernel changes after that and I am
running 2.6.20 on my amd64 machine (I could make the changes necessary
to compile under later kernels in enbd 2.4.33 but only at risk of
destabilizing, so I didn't).

Enbd 2.4.34pre compiles and runs fine on kernels up to at least
2.6.20.x. Be encouraged to use it and report anything untoward to me.

Peter
Permalink | Reply | 0 comments |
headers
Peter T. Breuer | 26 Sep 2007 23:08
Picon

Re: Compiling under AMD64 fails

Following on the discussion about the error messages on enbd 2.4.33 when
compiling for amd64 (I believe I cautiously and harmlessly patched that
away but I've only confirmed it still works fine for ia32), I see this
interesting related item on the kernel list:

   Re: [PATCH] Since we have counters in __u64 

   > > __u64 is not always long long.
   >
   > What is the maximum size of long long across all architectures?
   > How does one format __u64 for printing?

   With %lu you get warnings when u64 is long long (32-bit).
   With %llu you get warnings when u64 is plain long (most 64-bit).

   Hence %llu + long long cast, i.e.:
   printf("%llu", (unsigned long long)value);

   This is ugly but luckily imposes no runtime overheads on
   current 32- or 64-bit machines.

   This could be done more cleanly if the u64 typedef also
   #define:d a corresponding FMT_U64 format string.

and

   In user space, use the macro PRIu64 (or PRIx64 etc) from <inttypes.h>.

I've no intention of using a macro that seems to be so special. I more
or less just cast everything to long long for printing and formated it
(Continue reading)

Permalink | Reply | 0 comments |

Gmane