linux-kernel - Re: Linux 3.4-rc4

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120502012029.GA24097@elliptictech.com>
Date:	Tue, 1 May 2012 21:20:29 -0400
From:	Nick Bowler <nbowler@...iptictech.com>
To:	Maarten Maathuis <madman2003@...il.com>
Cc:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Martin Peres <martin.peres@...ri.fr>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	dri-devel@...ts.freedesktop.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ben Skeggs <bskeggs@...hat.com>
Subject: Re: Linux 3.4-rc4

(re-adding Ben to the Cc because he was apparently dropped somewhere in
this thread)

On 2012-05-01 09:23 -0400, Nick Bowler wrote:
> On 2012-04-30 11:07 +0200, Maarten Maathuis wrote:
> > On Mon, Apr 30, 2012 at 12:37 AM, Dmitry Torokhov
> > <dmitry.torokhov@...il.com> wrote:
> > > On Sat, Apr 28, 2012 at 11:33:50AM -0400, Nick Bowler wrote:
> > >> On 2012-04-28 02:19 -0400, Alex Deucher wrote:
> > >> > On Fri, Apr 27, 2012 at 8:39 PM, Nick Bowler <nbowler@...iptictech.com> wrote:
> > >> > > While tracking down the black screen issue, I've been having the monitor
> > >> > > directly connected to the video card the whole time, but now when I'm
> > >> > > connected through my KVM switch (an IOGear GCS1804), it appears that
> > >> > > something's going wrong with reading the EDID, because the available
> > >> > > modes are all screwed up (both console and X decide they want to drive
> > >> > > the display at 1024x768).
> [...]
> > >> > > Also, looking at /sys/class/drm/card0-VGA-1/edid I see that it
> > >> > > is empty on 3.4-rc4+ and it is correct on 3.2.15.  Things seem
> > >> > > to work OK when the KVM is not involved.
> > >> >
> > >> > Were you ever able to fetch a EDID with the KVM involved?  KVMs are
> > >> > notorious for not connecting the ddc pins.
> > >>
> > >> Yes, it works on 3.2.15 as described above.
> > >
> > > I have the same (or similar) KVM (not in the office at the moment) and I
> > > can confirm that with newer kernels EDID fecthing in flaky. It's 50/50
> > > if EDED retrieval succeeds or if it fails with:
> > >
> > > Apr 26 13:06:57 dtor-d630 kernel: [13464.936336] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 208
> [...]
> > > Earlier kernels were able to retrieve EDEDs reliably.
> 
> FWIW, for me EDID failure on new kernels is 100% reproducible, and there
> are no such checksum errors in the log.  It's just missing.
> 
> > Just a crazy thought, but didn't we change some timings related to
> > EDID retrieval? To make it faster.
> 
> OK, this time bisecting started off relatively smoothly (doing the same
> "backwards" bisect on the branch-o-reverts as last time), but then my
> disk died halfway through...
[...]

OK, system is back online and I finished the bisection.  The commit that
broke it for me is the following, and reverting it on top of 3.3.4 + the
"make VGA work at all" patch fixes this particular issue for me.

commit f553b79c03f0dbd52f6f03abe8233a2bef8cbd0d
Author: Ben Skeggs <bskeggs@...hat.com>
Date:   Wed Dec 21 18:09:12 2011 +1000

    drm/nouveau/i2c: handle bit-banging ourselves
    
    i2c-algo-bit doesn't actually work very well on one card I have access to
    (NVS 300), random single-bit errors occur most of the time - what we're
    doing now is closer to what xf86i2c.c does.
    
    The original plan was to figure out why i2c-algo-bit fails on the NVS 300,
    and fix it.  However, while investigating I discovered i2c-algo-bit calls
    cond_resched(), which makes it a bad idea for us to be using as we execute
    VBIOS scripts from a tasklet, and there may very well be i2c transfers as
    a result.
    
    So, since I already wrote this code in userspace to track down the NVS 300
    bug, and it's not really much code - lets use it.
    
    Signed-off-by: Ben Skeggs <bskeggs@...hat.com>

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/