> I'm using gentoo, and have specifically excluded the "nptl" USE flag to
> prevent the new thread handling. I have no tls directory under /lib, so I
> guess this is working (?)
There's also a gcc flag for emitting direct TLS references directly in the
code (the TLS library does this, which is why we disable it). The gcc flag
is "-mno-tls-direct-seg-refs". Could this be your problem? Does
recompiling, with no-tls-direct-seg-refs help?
Cheers,
Mark
> > The best soloution is to install a 'xen friendly' glibc for your
> > installation. What distro are you running?
> >
> > The othe ralternative is to not disable tls by mv'ing the directory out
> > the way, but to leave it active. You'll get some loss of performance,
> > but it should be executed correctly.
> >
> > Another interesting datapoint would be to try the unstable.bk tree. It's
> > still a bit 'raw', but providing you're just using the features present
> > in 2.x its actually pretty stable.
> >
> > If anyone has a simple recipe for deterministically provoking this issue
> > it would be good to know.
>
> FWIW, my setup here has involved several machines a couple of "live" ones
> basically used to hold transient data in a queue, a development box and a
> reporting server containing large volumes of log records - mostly used for
> queries.
>
> It's the reporting server which had the data corruption, and the two queue
> handlers which have experienced the segvs.
>
> The queue handlers are running on identical boxes (IBM e325s over scsi),
> and the reporting server on a generic system over SATA, if this helps.
>
> The queue handlers have both had the segv, but at different times. They're
> in a round-robin carrying much the same traffic. I guess this means the
> problem is going to be difficult to reproduce :-(
>
> > Best,
> > Ian
>
> Hope this helps,
> Paul.
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home