[Nouveau] i2c-dev driver corrupts display?

[Nouveau] i2c-dev driver corrupts display?

[Roger]

HARDWARE:
Dell Inspiron 8100 laptop
nVIDIA Geforce2 Go (NV11) with Intel AGP

PROBLEM:
Display corruption whenever nouveau module was loaded, seemingly at random.

CULPRIT:
Whenever the i2c-dev.ko driver/module was loaded, the display would become 
corrupted, or as if the timing became out of sync with hardware specifications, 
with weird moving pixels throughout the display.

If the i2c-dev is built into the kernel, possible the display would turn-off 
upon nouveau module loading, but could be possibly worked around (I think) by 
building the nouveau driver statically into the kernel, possibly loading prior 
to i2c-dev loading?

Been having this problem for many years, finally found it, and nothing found 
via Google on i2c-dev & nouveau.

WORKAROUND:
/etc/modprobe.d/blacklist.conf
blacklist i2c_dev

Or, rebuild the kernel without i2c-dev.

Quite a few Linux distributions either compile the i2c-dev into the kernel, or 
load the module during booting, creating significant display problems (as noted 
above) when trying to install from a Linux distribution CD/DVD.  Most people 
performing an install, I'm guessing, are then simply performing a nomodeset 
during boot and/or reverting to VESA/UVESAFB.


-- 
Roger
http://rogerx.sdf.org/
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] i2c-dev driver corrupts display?

[Ilia Mirkin]

That's very surprising. As I recall, i2c-dev just adds /dev nodes for
various i2c devices (some of which would be exposed by nouveau, most
likely just the connector one to read EDID in your case, as temp/etc
sensors came later). It shouldn't cause nouveau to do anything
differently -- just allows user-space to have access to the i2c
adapters.

You can try messing with the i2c implementation a bit with

nouveau.config=NvI2C=1

which will flip the internal implementation from the "shared" bit-bang
implementation, to a dedicated nouveau one. But it shouldn't matter.
And as I mentioned before, not sure how the i2c-dev module can affect
it either way -- either the shared impl works or it doesn't.

You can also try booting with

nouveau.debug=debug

to see if you can glean any meaningful information from the "broken" case.

I also remember reports of a later mobile board (NV28M) having weird
clock-related and cursor layout issues
(https://bugs.freedesktop.org/show_bug.cgi?id=54700,
https://bugs.freedesktop.org/show_bug.cgi?id=78543). Not directly
related to your situation, but just pointing to it in case it triggers
some ideas.

In your testing, it might also be wise to differentiate warm vs cold
boots. You can also force re-initialization of the board with

nouveau.config=NvForcePost=1

Cheers,

  -ilia

On Thu, Feb 25, 2021 at 5:40 PM Roger <rogerx.oss@gmail.com> wrote:
>
> HARDWARE:
> Dell Inspiron 8100 laptop
> nVIDIA Geforce2 Go (NV11) with Intel AGP
>
> PROBLEM:
> Display corruption whenever nouveau module was loaded, seemingly at random.
>
> CULPRIT:
> Whenever the i2c-dev.ko driver/module was loaded, the display would become
> corrupted, or as if the timing became out of sync with hardware specifications,
> with weird moving pixels throughout the display.
>
> If the i2c-dev is built into the kernel, possible the display would turn-off
> upon nouveau module loading, but could be possibly worked around (I think) by
> building the nouveau driver statically into the kernel, possibly loading prior
> to i2c-dev loading?
>
> Been having this problem for many years, finally found it, and nothing found
> via Google on i2c-dev & nouveau.
>
> WORKAROUND:
> /etc/modprobe.d/blacklist.conf
> blacklist i2c_dev
>
> Or, rebuild the kernel without i2c-dev.
>
> Quite a few Linux distributions either compile the i2c-dev into the kernel, or
> load the module during booting, creating significant display problems (as noted
> above) when trying to install from a Linux distribution CD/DVD.  Most people
> performing an install, I'm guessing, are then simply performing a nomodeset
> during boot and/or reverting to VESA/UVESAFB.
>
>
> --
> Roger
> http://rogerx.sdf.org/
> _______________________________________________
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau