> Does every packet from A trigger the crash?
In my last test the crash was triggered after 300MB of http output (on
the fifth run of a script downloading the same 60MB of data).
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More
> No I meant the exact output of ip x p and ip x s.
I know, but as I end up every time with a tainted kernel on our
production server I didn't turn ipcomp on, but now I got it.
src Net_B dst A
dir in priority 2088
tmpl src B dst A
proto comp reqid 16394 mode tunne
> OK, so are you now able to reproduce this crash without waiting
> for hours? That would be really helpful in tracking it down.
Yes, I can reproduce it in minutes now.
> Could you show me the exact policies/SAs of the tunnel involved
> in the crash?
esp/cbc(aes128)/hmac(sha1)
--
>> Net_A - GW_A --- GW_B - Net_B
>> The Net_A - Net_B ESP/AES/IPComp tunnel works fine, the tunnel
between
>> Net_B and the external IP address of GW_A triggers the oops in GW_A.
> That's interesting. So which one out of A and B is running 2.6.24?
A is the oopsing 2.6.24, B is 2.6.23.
I didn't c
> Unable to handle kernel paging request at c20fb000 RIP:
> [] deflate_slow+0x40/0x400
Here is some more information about the scenario in which I can easily
reproduce the oops now:
Net_A - GW_A --- GW_B - Net_B
The Net_A - Net_B ESP/AES/IPComp tunnel works fine, the tunnel between
Net
Nope! Right now it happened again, something must have changed with
2.6.24.
Unable to handle kernel paging request at c20fb000 RIP:
[] deflate_slow+0x40/0x400
PGD 7f845067 PUD 7f846067 PMD 7f847067 PTE 0
Oops: [1] SMP
CPU 0
Modules linked in:
Pid: 11055, comm: httpd Not tainted 2.6.2
>> Unable to handle kernel paging request at c20fb000 RIP:
>> [] deflate_slow+0x40/0x400
> I'm not able to get much information out of this crash dump. Nor
> can I reproduce this bug on my 32-bit machines and I'm currently
> away from my 64-bit machines.
> How long have you been using
One more issue with 2.6.24, some hours after I reactivated ipcomp with
Herb's 2 patches.
The httpd log shows a http request per esp tunnel at oops time.
Don't know whether it is for network or compression guys, so I started
posting here.
Daniel
Unable to handle kernel paging request at c20
> applied and tested to 2.6.24: ipcomp is working now.
> As always, thanks a lot Herbert for fixing this.
Thank you too, I applied the 2 patches and it works.
Daniel
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo
Has someone an idea which patch could have damaged ipcomp?
Daniel
> With 2.6.24 IPSEC/ESP tunnels to older kernels establish fine, data
> flows in both directions, but no data comes out of the tunnel.
> Needed to disable ipcomp.
--
To unsubscribe from this list: send the line "unsubscribe netdev"
With 2.6.24 IPSEC/ESP tunnels to older kernels establish fine, data
flows in both directions, but no data comes out of the tunnel.
Needed to disable ipcomp.
Daniel
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
> > Just to make it clear: Is this message an error, or a
> warning or just
> > for information?
> > Could you explain a bit please.
>
>
> Its a debugging message nowadays (NETDEBUG). I was mostly interested
> in this since I changed the IPsec MTU calculation in 2.6.22 and it
> might have been a
> Beschorner Daniel wrote:
> >>>No more crashes with IPComp and smaller PMTUs.
> >>>But the "pmtu discovery on SA ESP/..." messages don't disappear.
> >>
> >>Thats probably a different issue. Please post the output of
> >>"i
> > No more crashes with IPComp and smaller PMTUs.
> > But the "pmtu discovery on SA ESP/..." messages don't disappear.
>
> Thats probably a different issue. Please post the output of
> "ip -x xfrm state" (obfuscate keys if you care ..).
Linux (MTU 1500) <-> ADSL router (1492) <-> ... <-> Linux (
> >>> I managed to reproduce a crash with ipcomp, will try to
> fix it later.
> >>>
> >> Yes, I can confirm this.
> >> After disabling IPComp the crashes went away.
> >>
> > The crash happens in xfrm_bundle_ok when walking the bundle upwards
> > following xfrm_dst->u.next. The loop sho
> Today a new site joined our Linux IPSec VPN, now all the
> other routers (all 2.6.22) freeze hard reproducible.
> No oops, no sysreq, only hard reset rewakes them.
Ok, I did a longer test and nothing crashed in the mean time without
IPComp.
So it really must have been the reason.
BTW now I see
> >>Did you turn on IPSec compression?
> >
> >
> >
> > No. Please send the policy you're using.
>
>
> I managed to reproduce a crash with ipcomp, will try to fix it later.
Yes, I can confirm this.
After disabling IPComp the crashes went away.
Thank you
Daniel
-
To unsubscribe from this list
> I recreated the same setup here, but things work fine even with
> different MTUs. Please try to narrow it down further or capture
> some more information (serial console/netconsole,
> CONFIG_DETECT_SOFTLOCKUP, ..).
Did you turn on IPSec compression?
-
To unsubscribe from this list: send the lin
> Today a new site joined our Linux IPSec VPN, now all the
> >>>
> >>>other routers
> >>>
> (all 2.6.22) freeze hard reproducible.
> >
> >
> > The problem is more general und ugly than I thought.
> >
> > I took 2 arbitrary boxes, one behind an Ethernet (A, Kernel
> 2.6.21, MTU
> > 1500
> > > Today a new site joined our Linux IPSec VPN, now all the
> > other routers
> > > (all 2.6.22) freeze hard reproducible.
The problem is more general und ugly than I thought.
I took 2 arbitrary boxes, one behind an Ethernet (A, Kernel 2.6.21, MTU
1500), one behind ADSL (B, 2.4.x, 1492).
Esta
> Beschorner Daniel wrote:
> > Today a new site joined our Linux IPSec VPN, now all the
> other routers
> > (all 2.6.22) freeze hard reproducible.
>
> Do the other routers all do IPsec or just one of them?
They all do IPSec, that seems to be their mistake.
The unencry
Today a new site joined our Linux IPSec VPN, now all the other routers
(all 2.6.22) freeze hard reproducible.
No oops, no sysreq, only hard reset rewakes them.
The only difference of the new site compared to the others: ADSL, thus a
MTU of 1492, the others have 1500.
Disabling IPSec und doing norm
Since 2.6.21 I often got a 2 seconds delay when closing a telnet session
to such a machine (even to localhost).
I was at least not aware of this with older versions, but maybe I'm
wrong?!?
Client with delay:
0.62 select(4, [0 3], [], [3], NULL) = 1 (in [3])
1.803057 recvfrom(3, "", 8192, 0, N
Stephen,
you will be glad to hear that the long crashing saga (at least in my
case) turns to the end.
The combination 2.6.18 / skge 1.8 is working well with SMP/IRQ
migration.
The last test which crashed was 2.6.17 / skge 1.6 + PCI posting fixes.
So some fix in 1.7/1.8 seems to make the difference
> possible PCI posting bug?
>
> --- linux-2.6.orig/drivers/net/skge.c
> +++ linux-2.6/drivers/net/skge.c
> @@ -2745,7 +2745,7 @@ static int skge_poll(struct net_device *
> spin_lock_irq(&hw->hw_lock);
> hw->intr_mask |= rxirqmask[skge->port];
> skge_write32(hw, B0_IMSK, hw->intr_
>> Stephen,
>>
>> the reproducible crashes with all skge versions (where sk98lin works
>> fine) on my box are SMP related.
>> I booted with maxcpus=1 and the box survived my usual crash test, I will
>> keep an eye.
>>
>> Daniel
>>
> Is this P3 SMP?
> What form of IRQ balance are you using?
Ind
Stephen,
the reproducible crashes with all skge versions (where sk98lin works
fine) on my box are SMP related.
I booted with maxcpus=1 and the box survived my usual crash test, I will
keep an eye.
Daniel
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message
>> Does it harm?
>>
>> SKB BUG: Invalid truesize (380) len=1383, sizeof(sk_buff)=156
>> SKB BUG: Invalid truesize (316) len=1383, sizeof(sk_buff)=156
>> SKB BUG: Invalid truesize (348) len=1383, sizeof(sk_buff)=156
>> SKB BUG: Invalid truesize (316) len=1383, sizeof(sk_buff)=156
>> SKB BUG: Invali
Does it harm?
SKB BUG: Invalid truesize (380) len=1383, sizeof(sk_buff)=156
SKB BUG: Invalid truesize (316) len=1383, sizeof(sk_buff)=156
SKB BUG: Invalid truesize (348) len=1383, sizeof(sk_buff)=156
SKB BUG: Invalid truesize (316) len=1383, sizeof(sk_buff)=156
SKB BUG: Invalid truesize (380) len=
> I assume you sk98lin version downloaded from their web site.
Right.
sk98lin: Network Device Driver v8.32.2.3
(C)Copyright 1999-2006 Marvell(R).
ACPI: PCI Interrupt :00:0b.0[A] -> GSI 16 (level, low) -> IRQ 19
eth0: DGE-530T Gigabit Ethernet Adapter
PrefPort:A RlmtMode:Check Link Stat
Thank you for the hint, Krzysztof!
But this switch doesn't help, the problem for the crash is in my case the rx
side.
I can send big files over the card, as soon as I start receiving the box
crashes with the oopses you can find in former postings.
Daniel
> On Wed, 17 May 2006, Be
As David and me are using SMP systems when it's crashing, should I give a
non-SMP kernel a try, to see if it's some kind of race conditon?
Daniel
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.ke
Posted again on Netdev for completeness.
Hardware:
:00:0b.0 Ethernet controller: D-Link System Inc Gigabit Ethernet Adapter
(rev 11)
Subsystem: D-Link System Inc DGE-530T Gigabit Ethernet Adapter
Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 11
Memory at fa0
> [IPSEC] Use TOS when doing tunnel lookups
>
> We should use the TOS because it's one of the routing keys. It also
> means that we update the correct routing cache entry when PMTU occurs.
> Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
> Daniel, please let me know if this patch fixes it or not
Thanks to Herbert & Ilia (You mentioned your patch on the Openswan list, I
should have tried earlier)!
Results after a quick test: Ilia's patch works for me, Herbert's doesn't.
Daniel
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
35 matches
Mail list logo
