[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c54e9eee0add4f04b0ce61a1ae2c3f04@ZCOM03.mut-group.com>
Date: Thu, 2 Aug 2018 11:02:39 +0000
From: Marcel Hellwig <mhellwig@...-group.com>
To: 'Eric Dumazet' <eric.dumazet@...il.com>,
Paolo Abeni <pabeni@...hat.com>,
"'davem@...emloft.net'" <davem@...emloft.net>,
"'kuznet@....inr.ac.ru'" <kuznet@....inr.ac.ru>,
"'yoshfuji@...ux-ipv6.org'" <yoshfuji@...ux-ipv6.org>,
"'andrew@...n.ch'" <andrew@...n.ch>
CC: "'netdev@...r.kernel.org'" <netdev@...r.kernel.org>,
"'linux-kernel@...r.kernel.org'" <linux-kernel@...r.kernel.org>,
"Matthias Wystrik" <mwystrik@...-group.com>
Subject: AW: AW: AW: PROBLEM: Kernel Oops in UDP stack
Hi everyone,
I did three things that evening.
* I created a small dts file, so I could boot a 3.5.7 kernel.
* Ported the pskb_expand_head from 3.5.7 to 3.4.113
* Ported the whole skbuf.{c,h} file from 3.5.7 to 3.4.113
Sadly enough the second and third one panicked as well, but interestingly not the first one (3.5.7 with a simple dts file). Now the question is: Is something changed outside of the skbuf (maybe in udp.{c,h}?) or is it because the dts uses a different approach of talking to the MAC of the lpc3250?
I may try a more recent kernel with a dts file (maybe a 4.x.x one), but I think that will be impossible to backport a patch for our 2.6 kernel :(
If anybody has any more ideas about why the dts kernel does not panic, you're very welcome.
Mit freundlichen Grüßen / With kind regards
Marcel Hellwig
B. Sc. Informatik
Entwickler
m-u-t GmbH
Am Marienhof 2
22880 Wedel
Germany
Phone: +49 4103 9308 - 474
Fax: +49 4103 9308 - 99
mhellwig@...-group.com
www.mut-group.com
Geschäftsführer (Managing Director): Fabian Peters
Amtsgericht Pinneberg (Commercial Register No.): HRB 10304 PI
USt-IdNr. (VAT-No.): DE228275390
WEEE-Reg-Nr.: DE 72271808
Powered by blists - more mailing lists