From: Sushil Adhikari <sushil446@gmail.com>
To: "Wiles, Keith" <keith.wiles@intel.com>
Cc: "users@dpdk.org" <users@dpdk.org>
Subject: Re: [dpdk-users] BUG: unable to handle kernel paging request
Date: Mon, 27 Feb 2017 16:22:39 -0600 [thread overview]
Message-ID: <CAPO9LfT0gFyvFrk=0LNtQX=ngKwBRq2R8E2Hz9DJri_6awU-5g@mail.gmail.com> (raw)
In-Reply-To: <6F62EB32-671C-458D-B24B-268491C2DA1E@intel.com>
I narrowed it to location where it was failing, its coming from
http://dpdk.org/browse/dpdk-stable/tree/lib/librte_eal/linuxapp/kni/kni_net.c?h=v16.07.2
line 169, I am getting the value of len to be 1358 from len=kva->pkt_len;
which seems right for ip packet and the memory allocation from line 157
also seems to be working fine. when I print the sizeof(*skb) or
sizeof(struct sk_buff) its giving me 208, I guess I dont know whether it
should be the size we allocate from line 157, which is len + 2 = 1360 or
its fixed size structure of 208 byte. I would appreciate any insight.
Linux version 4.4.20 (sushila@dev03) (gcc version 4.9.2 (crosstool-NG
1.20.0) ) #1 SMP Fri Feb 24 14:32:28 CST 2017
Thank you
Sushil
On Sat, Feb 25, 2017 at 10:31 AM, Wiles, Keith <keith.wiles@intel.com>
wrote:
>
> > On Feb 24, 2017, at 8:07 AM, Sushil Adhikari <sushil446@gmail.com>
> wrote:
> >
> > Resending because of unsupported email content type
> >
> >
> > yes hanging is the better word I guess, ctrl + c is not working to
> actually stop the program. I also had display connected to the target
> manchine and I have attached a picture that shows the messages in that
> display that is where I saw "BUG:Unable to handle kernel paging request at
> xxxxxx", which made me think that the program is in bad state.
>
> Sorry, I do not see why you are getting this message. All I can suggest is
> to use GDB and see if you can determine why the message is happening.
>
> >
> > info thread in gdb shows one thread running
> > Id Target Id Frame
> > * 1 LWP 843 "dpdkKni" 0x000000000044eaee in rte_kni_tx_burst ()
> >
> > On Thu, Feb 23, 2017 at 5:41 PM, Wiles, Keith <keith.wiles@intel.com>
> wrote:
> >
> > > On Feb 23, 2017, at 2:38 PM, Sushil Adhikari <sushil446@gmail.com>
> wrote:
> > >
> > > While trying to run dpdk Kni application I ran in to a problem, with
> > > following error message
> > > BUG: unable to handle kernel paging request at 000007ffe2b92780
> > >
> > > To run the application I first unbinded the ports from kernel module
> and
> > > binded them to igb_uio
> > >> echo 0000:05:00.1 > /sys/bus/pci/drivers/ixgbe/unbind
> > >> echo 0000:05:00.0 > /sys/bus/pci/drivers/ixgbe/unbind
> > >> echo 0x8086 0x1528 > /sys/bus/pci/drivers/igb_uio/new_id
> > >
> > > I ran the application using gdb as
> > >
> > > [~]$ /root/gdb dpdkKni
> > > GNU gdb (crosstool-NG 1.20.0) 7.8
> > > Copyright (C) 2014 Free Software Foundation, Inc.
> > > License GPLv3+: GNU GPL version 3 or later <
> http://gnu.org/licenses/gpl.html
> > >>
> > > This is free software: you are free to change and redistribute it.
> > > There is NO WARRANTY, to the extent permitted by law. Type "show
> copying"
> > > and "show warranty" for details.
> > > This GDB was configured as "x86_64-unknown-linux-gnu".
> > > Type "show configuration" for configuration details.
> > > For bug reporting instructions, please see:
> > > <http://www.gnu.org/software/gdb/bugs/>.
> > > Find the GDB manual and other documentation resources online at:
> > > <http://www.gnu.org/software/gdb/documentation/>.
> > > For help, type "help".
> > > Type "apropos word" to search for commands related to "word"...
> > > Reading symbols from dpdkKni...(no debugging symbols found)...done.
> > > (gdb) Run dpdkKni -c 0x0f -n 4 -- -P -p 0x3 --config="(0,0,1),(1,2,3)"
> > > Starting program: /root/dpdkKni dpdkKni -c 0x0f -n 4 -- -P -p 0x3
> > > --config="(0,0,1),(1,2,3)"
> > > warning: Could not load shared library symbols for linux-vdso.so.1.
> > > Do you need "set solib-search-path" or "set sysroot"?
> > > warning: Unable to find libthread_db matching inferior's thread
> library,
> > > thread debugging will not be available.
> > > EAL: Detected 4 lcore(s)
> > > EAL: Probing VFIO support...
> > > EAL: PCI device 0000:05:00.0 on NUMA socket -1
> > > EAL: probe driver: 8086:1528 net_ixgbe
> > > EAL: PCI device 0000:05:00.1 on NUMA socket -1
> > > EAL: probe driver: 8086:1528 net_ixgbe
> > > Address of pktmbuf_pool 0x7ffff5a7dec0
> > > APP: Initialising port 0 ...
> > > KNI: pci: 05:00:00 8086:1528
> > > kni created for port 0 with kni[i] address 0x7fff75638280 with i 0
> > > APP: Initialising port 1 ...
> > > KNI: pci: 05:00:01 8086:1528
> > > kni created for port 1 with kni[i] address 0x7fff75629e00 with i 0
> > > APP: Lcore 1 is writing to port 0
> > > APP: Lcore 2 is reading from port 1
> > > APP: Lcore 3 is writing to port 1
> > > APP: Lcore 0 is reading from port 0
> > > ^C
> > > Program received signal SIGINT, Interrupt.
> >
> > The program did not crash or get a segfault, but you hit control-c which
> stopped the application. When you ran the application you started 4 threads
> and this is why it would appear in different places when stopped.
> >
> > If the application is hanging then you can use control-C and then do
> ‘info threads’ command to see the location of all threads. You can use the
> ‘thread X’ command to switch between threads. Please check the command
> usage here I am going from memory.
> >
> > I am not sure if the application has a -i option to get a command line
> if so that maybe useful to enable, check the application to see if it used
> cmdline feature.
> >
> > It maybe the application just sits running and you have to use other
> tools or apps to send traffic on the KNI application, sorry I have not
> really used the KNI example.
> >
> > > 0x000000000044e916 in rte_kni_tx_burst ()
> > > (gdb) backtrace
> > > #0 0x000000000044e916 in rte_kni_tx_burst ()
> > > #1 0x0000000000619758 in main_loop(void*) ()
> > > #2 0x0000000000431183 in rte_eal_mp_remote_launch ()
> > > #3 0x000000000040d312 in main ()
> > >
> > > (this is where the program crashes)
> > >
> > > I tried to trace the crash with gdb(I am new to gdb)
> > >
> > > and when I do the backtrace it ends up in different functions each
> time:
> > > this time it gave me rte_kni_tx_burst()
> > >
> > > I'm running latest dpdk version 17.02 and linux kernel is
> > > Linux version 4.4.20 (tcuser@cibuild08) (gcc version 4.9.2
> (crosstool-NG
> > > 1.20.0) ) #1 SMP
> > >
> > > I would appreciate any suggestion or insight regarding this issue.
> >
> > Regards,
> > Keith
> >
> >
> > <kni.jpg>
>
> Regards,
> Keith
>
>
next prev parent reply other threads:[~2017-02-27 22:23 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-23 22:38 Sushil Adhikari
2017-02-23 23:41 ` Wiles, Keith
2017-02-24 15:35 ` Sushil Adhikari
2017-02-24 16:07 ` Sushil Adhikari
2017-02-25 16:31 ` Wiles, Keith
2017-02-27 22:22 ` Sushil Adhikari [this message]
2017-02-27 22:41 ` Wiles, Keith
2017-02-28 15:30 ` Sushil Adhikari
2017-02-28 15:34 ` Wiles, Keith
2017-02-28 15:42 ` Sushil Adhikari
2017-02-28 16:00 ` Wiles, Keith
2017-02-28 16:49 ` Sushil Adhikari
2017-03-08 14:23 ` Sushil Adhikari
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPO9LfT0gFyvFrk=0LNtQX=ngKwBRq2R8E2Hz9DJri_6awU-5g@mail.gmail.com' \
--to=sushil446@gmail.com \
--cc=keith.wiles@intel.com \
--cc=users@dpdk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).