similar to: [Bug 101322] New: GM108/NV118: 0 MiB DDR3 and boot crash in gf100_ltc_oneinit_tag_ram

We are working with new desktop that have the NVIDIA NV118 chipset. During boot, the display becomes unusable at the point where the nouveau driver loads. We have reproduced on 4.8, 4.11 and linux master (4.12-rc3). Dmesg log is attached. Is this a known issue? Anything we can do to help? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Fri, Jun 2, 2017 at 4:01 AM, Chris Chiu <chiu at endlessm.com> wrote: > We are working with new desktop that have the NVIDIA NV118 > chipset. > > During boot, the display becomes unusable at the point where the > nouveau driver loads. We have reproduced on 4.8, 4.11 and linux > master (4.12-rc3). To save digging into the attachment, here is the crash: nouveau

It looks similiar to this one: https://bugs.freedesktop.org/show_bug.cgi?id=101322 please provide a dmesg booted with "nouveau.debug=debug" as well 2017-06-02 12:01 GMT+02:00 Chris Chiu <chiu at endlessm.com>: > We are working with new desktop that have the NVIDIA NV118 > chipset. > > During boot, the display becomes unusable at the point where the > nouveau driver

https://bugs.freedesktop.org/show_bug.cgi?id=102860 Bug ID: 102860 Summary: Nvidia 940MX (NV118, GM108) is reported as a NV117, GM107 Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: minor Priority: medium Component:

https://bugs.freedesktop.org/show_bug.cgi?id=107479 Bug ID: 107479 Summary: GM108: MMIO read of 00000000 FAULT at 612004 [ IBUS ] Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau

https://bugs.freedesktop.org/show_bug.cgi?id=95188 Bug ID: 95188 Summary: GeForce 840M (GM108) troubles Product: xorg Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau at lists.freedesktop.org

Actually GM108 is not one of the recognized chips. Someone needs to go through and check that its goldens didn't change. Nobody's done that. See https://bugs.freedesktop.org/show_bug.cgi?id=89558 On Thu, Mar 31, 2016 at 4:57 PM, Pierre Moreau <pierre.morrow at free.fr> wrote: > Hello, > > Acceleration support for GM107 was merged in kernel 4.1, and modesetting > support

Hello, A patch was merged yesterday to recognise GM108 (see https://github.com/skeggsb/nouveau/commit/3da1f2a19e5e8dc8d68a4400d9cca01c64ecd59e). I guess it will make it into 4.7. Pierre On 12:14 PM - Apr 18 2016, Sune Mølgaard wrote: > Is there anything I can do in this regard? > > /smo > > On 2016-03-31 23:12, Pierre Moreau wrote: > > Oh, hum, GM108 is NV118 and not

Oh, hum, GM108 is NV118 and not NV108 which is Gk208… My bad! SMF from the bug report seemed to have some working setup, and since he didn't pinged back, I guess it's working nicely. But some more checking might still be needed? On 04:59 PM - Mar 31 2016, Ilia Mirkin wrote: > Actually GM108 is not one of the recognized chips. Someone needs to go > through and check that its goldens

Is there anything I can do in this regard? /smo On 2016-03-31 23:12, Pierre Moreau wrote: > Oh, hum, GM108 is NV118 and not NV108 which is Gk208… My bad! > > SMF from the bug report seemed to have some working setup, and since he didn't > pinged back, I guess it's working nicely. But some more checking might still be > needed? > > On 04:59 PM - Mar 31 2016, Ilia

https://bugs.freedesktop.org/show_bug.cgi?id=89558 Bug ID: 89558 Summary: Unknown chipset error for GeForce 840M Product: xorg Version: unspecified Hardware: Other OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau at

https://bugs.freedesktop.org/show_bug.cgi?id=101601 Bug ID: 101601 Summary: Nvidia GT 1030 (NV138/GP108) support Product: xorg Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau at

https://bugs.freedesktop.org/show_bug.cgi?id=75985 Priority: medium Bug ID: 75985 Assignee: nouveau at lists.freedesktop.org Summary: HDMI audio device only visible after rescan QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux (All) Reporter: jean-louis at

This resend fixes intermediate compilation issues, thus unbreaking git bisect. In addition fixed a little thinko in nouveau_memx_wait, that transformed waits into either sleeps or nops. I didn't bother labelling patches v2, I hope you don't mind! :-) Roy

Przemysław Kopa reports that since commit b516ea586d71 ("PCI: Enable NVIDIA HDA controllers"), the discrete GPU Nvidia GeForce GT 540M on his 2011 Samsung laptop refuses to runtime suspend, resulting in a power regression and excessive heat. Rivera Valdez witnesses the same issue with a GeForce GT 525M (GF108M) of the same era, as does another Arch Linux user named "R0AR" with

Dear All, I have a data set with variables x1, x2, x3, ..., x20 and I want to create z1, z2, z3, ..., z20 with the following formula: z1 = 200 - x1 z2 = 200 - x2 z3 = 200 - x3 . . . z20 = 200 - x20. I tried using a for loop and its index as: for (i in 1:20) { z(i) = 200 - x(i) } But R gives the following error message: "Error: could not find function "x"". Is there any

Hi, Looking at some udp stuff on snv_57, and I noticed that mib:::udpInDatagrams no longer exists, has this been superceded by mib:::udpHCInDatagrams? From my understanding they represent the same counter, but I''m asking in case this is a bug. I noticed that there is still a reference to udpInDatagrams in the DTrace testsuite. - Fintan

On October 31, 2017 2:32:36 AM GMT+01:00, Ben Kamen <ben at benkamen.net> wrote: >Hey all, > > >?I'm feeling spunky... and want to update nut to handle the new v2.0 >MIB from CyberPower. > >I've looked at the cyberpower v0.1 .c/.h and being new to working on >nut to this level -- anything anyone has to offer on adding code >besides the obvious? >

On November 2, 2017 5:31:42 AM GMT+01:00, Ben Kamen <ben at benkamen.net> wrote: >On 10/31/2017 01:13 AM, Jim Klimov wrote: >> If the new data is in a separate OID tree, it can quite be a new MIB. >Otherwise you can use the UNIQUE flag and set the preferred (e.g. >newer, more precise) source for a value first in the list of same-named >mappings in existing file - if

On 11/02/2017 01:52 AM, Jim Klimov wrote: > > I believe the main reason for a new set of .c/.h files here would be if the new MIB is defined in a separate subtree. The top-level mapping binds the vendor entry OIDs (often "hidden" so one has to know where to poke). It may also be higher in the list of snmp-ups.h, in case the device also serves the older MIB but you'd prefer the