|
Hello,
On Wed, 9 Aug 2000, Ratz wrote:
> > Looking in the LVS source I don't see other code before
> > IP_VS_DBG that needs to be under #ifdef CONFIG_IP_VS_DEBUG. If
> > you uncomment this code there will be extra "if (svc == NULL)" :)
>
> :) I give up, you won (:
:))
I agree, this is very pedantic (may be other optimizations
can save CPU cycles) but it is only one place in the source with
such #ifdefs :)
> > > > Do you play any games with creating new chains, etc? If yes,
> > > > show some names.
> > >
> > > nope, nothing:
> > > lb:/root # ipchains -L -n
> > > Chain input (policy ACCEPT):
> > > Chain forward (policy ACCEPT):
> > > Chain output (policy ACCEPT):
> > > lb:/root #
> >
> > Hm, someone is overwriting memory.
>
> how about a broken memory that can't refresh
> or has some other strange problem?
Hm, the oopses are on same place. Very strange.
But I'm not surprised. I have a hardware that sends packets
with wrong data and correct TCP checksums. I have to always
use gzip -tv :)) But seriously, we can only hope this problem
to be hardware related. Sometimes the different hardware
speed can trigger software bugs.
> > Are they with the same kernel+modules? Very strange oops
> > to be hardware related. Could this be caused from LVS?
>
> the kernel and modules are the same on each node. But
> I can't imaging the problem resulting from LVS. Actually
> it would be easy to test (same kernel without LVS) but
> the oops come really unfrequently and absolutely unpre-
> dictable; for my at least.
>
> Anyway, I'll trash this machine and take an other one.
Hm, OK.
> Thank you very much for trying to trace this behavior,
> I always appretiate your postings!
>
> > --
> > Julian Anastasov <ja@xxxxxx>
> ^^^^^^^^^
>
> Did you leave uni?
Oh, no, no. I'm not at the uni, more than two years :)
But Yes, this is my new address.
>
> regards,
> ratz
Regards
--
Julian Anastasov <ja@xxxxxx>
|
