search for: aperently

Please find below an automated bisection report for a kernel Oops seen during the initialisation of the nouveau GPU driver on jetson-tk1. All the LAVA test jobs for this bisection can be found here: http://lava.baylibre.com:10080/scheduler/alljobs?length=25&search=lava-bisect-staging-7366#table Here's the beginning of the Oops stack trace: [ 7.485361] [00000064] *pgd=f9e7b835 [

Currently vesafb/efifb/... is kicked when hardware driver is registering framebuffer. To do it hardware must be fully functional, so there's a short window between start of initialisation and framebuffer registration when two drivers touch the hardware. Unfortunately sometimes it breaks nouveau initialisation. Fix it by kicking firmware driver(s) before we start touching the hardware.

uhhhhhhhhhhhhh didn't we fix this weeks ago? with "drm/nouveau: tegra: Call nouveau_drm_device_init()" On Fri, 2018-12-07 at 23:31 +0000, Guillaume Tucker wrote: > Please find below an automated bisection report for a kernel Oops > seen during the initialisation of the nouveau GPU driver on > jetson-tk1. > > > All the LAVA test jobs for this bisection can be

On 08/12/2018 00:08, Lyude Paul wrote: > uhhhhhhhhhhhhh > didn't we fix this weeks ago? with "drm/nouveau: tegra: Call > nouveau_drm_device_init()" Yes here's the fix from Thierry: https://patchwork.freedesktop.org/patch/263587/ and I can confirm that it does fix the Oops when applied on top of next-20181206 (what I used for the bisection last week):

It simplifies nouveau code by removal of detection which region to pass to kick vesafb/efifb. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> Cc: Eric Anholt <eric at anholt.net> Cc: Ben Skeggs <bskeggs at redhat.com> Cc: Thomas Hellstrom <thellstrom at vmware.com> Cc: Dave Airlie <airlied at redhat.com> Cc: Peter Jones <pjones at redhat.com> Cc:

This series is intended to add support for shutting down the GPU on kernel shutdown/reboot using the ->shutdown() hook, similar to what amdgpu does. This is mainly intended to workaround a bios issue on the P50 that was preventing nouveau from initializing the dedicated GM107 GPU on that system properly. You can find more details on this issue in the patch labeled "Shut down GPU on kernel

fb_do_apertures_overlap is returning wrong value when one aperture is completely whithin the other. Add generic ranges_overlap macro (probably kernel.h candidate) and use it here. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> Cc: Dave Airlie <airlied at redhat.com> Cc: Peter Jones <pjones at redhat.com> Cc: Andrew Morton <akpm at linux-foundation.org> ---

On Wed, Aug 07, 2013 at 08:04:07PM -0700, Sudeep Dutt wrote: > +/** > + * struct mic_device - MIC device information for each card. > + * > + * @name: Unique name for this MIC device. > + * @mmio: MMIO bar information. > + * @pdev: The PCI device structure. > + * @family: The MIC family to which this device belongs. > + * @ops: MIC HW specific operations. > + * @id: The

On Wed, Aug 07, 2013 at 08:04:07PM -0700, Sudeep Dutt wrote: > +/** > + * struct mic_device - MIC device information for each card. > + * > + * @name: Unique name for this MIC device. > + * @mmio: MMIO bar information. > + * @pdev: The PCI device structure. > + * @family: The MIC family to which this device belongs. > + * @ops: MIC HW specific operations. > + * @id: The

From: Thierry Reding <treding at nvidia.com> Hi Ben, these are a couple of patches that are in preparation for adding GV11B support. The fundamental issue that these are trying to solve is that the GV11B is the first Tegra incarnation of the GPU where the aperture really matters. All prior generations would accept any of them. For dGPUs we usually allocate memory in VRAM, so the default

On Tue, 17 Sep 2019 at 01:18, Thierry Reding <thierry.reding at gmail.com> wrote: > > From: Thierry Reding <treding at nvidia.com> > > The gk20a (as well as all subsequent Tegra instantiations of the GPU) do > in fact use the same apertures as regular GPUs. Prior to gv11b there are > no checks in hardware for the aperture, so we get away with setting VRAM > as the

It removes a hack from nouveau code which had to detect which region to pass to kick vesafb/efifb. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> Cc: Eric Anholt <eric at anholt.net> Cc: Ben Skeggs <bskeggs at redhat.com> Cc: Thomas Hellstrom <thellstrom at vmware.com> Cc: Dave Airlie <airlied at redhat.com> Cc: Peter Jones <pjones at redhat.com>

From: Thierry Reding <treding at nvidia.com> The gk20a (as well as all subsequent Tegra instantiations of the GPU) do in fact use the same apertures as regular GPUs. Prior to gv11b there are no checks in hardware for the aperture, so we get away with setting VRAM as the aperture for buffers that are actually in system memory. Signed-off-by: Thierry Reding <treding at nvidia.com> ---

On Tue, Sep 17, 2019 at 01:43:13PM +1000, Ben Skeggs wrote: > On Tue, 17 Sep 2019 at 01:18, Thierry Reding <thierry.reding at gmail.com> wrote: > > > > From: Thierry Reding <treding at nvidia.com> > > > > The gk20a (as well as all subsequent Tegra instantiations of the GPU) do > > in fact use the same apertures as regular GPUs. Prior to gv11b there are

Turing introduced a new simplified page kind scheme, reducing the number of possible page kinds from 256 to 16. It also is the first NVIDIA GPU in which the highest possible page kind value is not reserved as an "invalid" page kind. To address this, the invalid page kind is made an explicit property of the MMU HAL, and a new table of page kinds is added to the tu102 MMU HAL. One

This patch enables the following: a) Initializes the Intel MIC X100 PCIe devices. b) Provides sysfs entries for family and stepping information. Co-author: Dasaratharaman Chandramouli <dasaratharaman.chandramouli at intel.com> Signed-off-by: Ashutosh Dixit <ashutosh.dixit at intel.com> Signed-off-by: Caz Yokoyama <Caz.Yokoyama at intel.com> Signed-off-by: Dasaratharaman

This patch enables the following: a) Initializes the Intel MIC X100 PCIe devices. b) Provides sysfs entries for family and stepping information. Co-author: Dasaratharaman Chandramouli <dasaratharaman.chandramouli at intel.com> Signed-off-by: Ashutosh Dixit <ashutosh.dixit at intel.com> Signed-off-by: Caz Yokoyama <Caz.Yokoyama at intel.com> Signed-off-by: Dasaratharaman

On Sat, Jul 12, 2014 at 3:15 PM, Alexander Perlis <aperlis at math.lsu.edu> wrote: > On 07/11/2014 09:39 PM, Gene Cumm wrote: >> >> With everything else from 6.03-pre18, try this binary (xzip-compressed): >> http://www.zytor.com/~genec/lpxelinux-6.03p18g3.tgz > > > It works! Thanks! > > Anything else I should do/report on this hardware before I upgrade the

gmux is a microcontroller built into dual GPU MacBook Pros. On pre-retina MBPs, if we're the inactive GPU, we need apple-gmux to temporarily switch DDC so that we can probe the panel's EDID. The checks for CONFIG_VGA_ARB and CONFIG_VGA_SWITCHEROO are necessary because if either of them is disabled but gmux is present, the driver would never load, even if we're the active GPU.

On Fri, Jul 11, 2014 at 5:49 PM, Alexander Perlis <aperlis at math.lsu.edu> wrote: > On 07/11/2014 04:31 PM, H. Peter Anvin wrote: >> >> On 07/11/2014 10:17 AM, Alexander Perlis wrote: >>> >>> >>> Trace shows that lpxelinux.0 6.03-pre18 is transferred, and after that >>> there is only ARP traffic: a "gratuitous" ARP announcement by