RE: Linux 5.10-rc4

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



From: Dave Airlie
> Sent: 19 November 2020 01:16
> 
> On Thu, 19 Nov 2020 at 08:25, Dave Airlie <airlied@xxxxxxxxx> wrote:
> >
> > On Thu, 19 Nov 2020 at 08:15, Daniel Vetter <daniel.vetter@xxxxxxxx> wrote:
> > >
> > > On Wed, Nov 18, 2020 at 11:01 PM David Laight <David.Laight@xxxxxxxxxx> wrote:
> > > >
> > > > From: Thomas Zimmermann
> > > > > Sent: 18 November 2020 19:37
> > > > >
> > > > > Hi
> > > > >
> > > > > Am 18.11.20 um 19:10 schrieb Linus Torvalds:
> > > > > > On Wed, Nov 18, 2020 at 4:12 AM David Laight <David.Laight@xxxxxxxxxx> wrote:
> > > > > >>
> > > > > >> I've got the 'splat' below during boot.
> > > > > >> This is an 8-core C2758 Atom cpu using the on-board/cpu graphics.
> > > > > >> User space is Ubuntu 20.04.
> > > > > >>
> > > > > >> Additionally the X display has all the colours and alignment slightly
> > > > > >> messed up.
> > > > > >> 5.9.0 was ok.
> > > > > >> I'm just guessing the two issues are related.
> > > > > >
> > > > > > Sounds likely.  But it would be lovely if you could bisect when
> > > > > > exactly the problem(s) started to both verify that, and just to
> > > > > > pinpoint the exact change..
> > > >
> > > > I don't quite understand what 'git bisect' did.
> > > > I was bisecting between v5.9 and v5.10-rc1 but it suddenly started
> > > > generating v5.9.0-rc5+ kernels.
> > >
> > > We queue up patches for -rc1 way before the previous kernel is
> > > released, so this is normal.
> > >
> > > > The identified commit was 13a8f46d803 drm/ttm: move ghost object created.
> > > > (retyped - hope it is right).
> > > > But the diff to that last 'good' commit is massive.
> > >
> > > Yeah that's also normal for non-linear history. If you want to
> > > double-check, re-test the parent of that commit (which is 2ee476f77ffe
> > > ("drm/ttm: add a simple assign mem to bo wrapper")), which should
> > > work, and then the bad commit.
> > >
> > > Also is this the first bad commit for both the splat and the screen
> > > corruption issues?
> > >
> > > > So I don't know if that is anywhere near right.
> > >
> > > Thomas guessed it could be a ttm change, you hit one, and it looks
> > > like it could be the culprit. Now I guess it's up to Dave. Also adding
> > > Christian, in case he has an idea.
> >
> > I'd be mildly surprised if it's that commit, since it just refactors
> > what looks to me to be two identical code pieces into one instance
> > (within the scope of me screwing that up, but reading it I can't see
> > it).
> >
> > I'll dig into this today.
> 
> https://patchwork.freedesktop.org/patch/401559/
> 
> should fix it.

Nope, and probably not relevant.
pl_flags is 2 or 3 and it is testing for 4.

The oldest kernel doesn't generate the 'splat' either.
Just the f*cked up display output.

I'll put a screenshot (photo) into another email.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel



[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux