Actions
Forum Thread Details
  • State Not Answered
  • Replies 5 replies
  • Subscribers 347 subscribers
  • Views 869 views
  • Users 0 members are here
Related

3.17 Kernel hang

Former Member

Hello,

We are currently running M-ITX platform with modified PCIe root complex design and patched up Linux kernel (2014.4) 3.17 version.

We have a Nvidia GPU sitting in the PCIe slot and lspci shows the device with BARs allocated. When trying to modprobe the kernel module for that specific GPU,it causes the kernel to hang and there's no output on the console. What's the best way to debug the problem?

Please let me know.

Thank you!

Parents
  • 0

    Debugging PCIe drivers in the kernel is an ugly task.  To be efficient, this usually requires special hw tools from manufacturers like ARM (DS-5) or Lauterbach to be able to stop kernel threads while still allowing the rest of the system to run.  Without these you may be stuck with instrumenting the NVidea driver to see if you can narrow down the cause of the issue.  Sounds like loading the driver is causing the problem, so if you have eliminated issues with the devicetree (BARS are allocated correctly, so sounds like this is ok) I would start with printk in that area and go from there.

    Ron

  • 0 in reply to Former Member

    Hello Ron,

    Thank you for that suggestion. Is it not possible to debug using the USB-JTAG module on-board the m-ITX kit along with necessary software tools? If not, would you mind pointing out a recommended solution for Zynq?

    I see some previous posts on the forum where Windriver linux was suggested as a solution for a similar PCIe-GPU problem. Does that still hold? We are looking for a quicker fix if possible without debugging the driver issues.

    In terms of hardware, can 1GB memory connected to PS be a limiting factor for the GPU drivers to load and function efficiently?


    Thank you!

  • 0 in reply to Former Member

    You can use the Xilinx tools for LInux application debug, but for kernel debug additional hardware is required.  This is generally true of all Linux systems.  Depending on your level of familiarity with the drivers and kernel, the printk option can be quite useful in identifying the problems.  It's a shortcut that can give you insight into the driver operation, and in general one needs to understand exactly which part of the driver function is failing (or most likely waiting for a response from the system, if you don't see the kernel panic) before you can determine what form a solution will take.

    I like the Wind River platform for a couple of reasons.  One, it is a much more complete system that is very good for prototyping and allows you to augment the software system on target quickly and easily using tools like the Smart Package Manager.  The version for the Mini-ITX is built for the PCIe hardware as well.  The kernel and user space are maintained by Wind River, so you can gain access to much more Linux-specific support through their online support.   However, if it comes back in the end to kernel debug, the procedure is the same. 

    You can find links to download the Wind River Pulsar image for the version of Mini-ITX you are using under the Mini-ITX reference designs on this site.  Further documentation for getting started with the platform after booting are found on the Wind River Pulsar site.

    http://www.windriver.com/products/operating-systems/pulsar/

    Scroll down to the bottom where you will see Knowledge Library and click the link for "Learn More".

    Ron

  • 0 in reply to Former Member

    Hi h@qdi

    Any luck with getting this board up and running with an NVIDIA GPU? We're just getting started with it.

    Have you looked into running Ubuntu on the board?

    Thanks.

Reply Children
No Data