Another log, per Lyude on #nouveau. j On Tuesday, January 14, 2020 8:52:51 AM AKST Joshua J. Kugler wrote:> Here we go! > > j > > On Tuesday, January 14, 2020 7:08:20 AM AKST Ilia Mirkin wrote: > > Hi Joshua, > > > > Not a fix for your issue, but Ben noticed this (and fixed it): > > > > https://github.com/skeggsb/nouveau/commit/024bda7d2b0c3b0731433d60a494c78a > > b5 8cb216 > > > > which is what causes us to even try 540MB/s link training. However > > with this fix applied, it'll just give up faster. I'm told eDP is > > generally a single lane, and you're trying to get more than 270MB/s. > > So ... the question is ... why is it trying to do 10bpc. One likely > > reason is that the display_info.bpc == 0 for some reason (and we, > > rather questionably, default to 10bpc for bandwidth determination). > > There's no concrete theory as to what that reason might be, but it > > would explain what's going on. > > > > After resuming into a bad state, can you grab the contents of > > /sys/class/drm/card0-eDP-1/edid (you'll have to cat it or something)? > > My hope is that it's somehow messed up. > > > > Also, can you add "drm.debug=0x1e" to the boot cmd line, in addition > > to the bits you have already? Should provide some more info, perhaps > > some of it will even be relevant. > > > > Thanks, > > > > -ilia > > > > On Mon, Jan 13, 2020 at 6:48 PM Joshua J. Kugler <joshua at azariah.com>wrote:> > > I've added debugging command-line parameters to the kernel command line, > > > per skeggsb and imirkin on #nouveau. > > > > > > root at joyful:~# cat /proc/cmdline > > > BOOT_IMAGE=/vmlinuz-5.3.0-26-generic root=/dev/mapper/vgubuntu-root ro > > > quiet splash log_buf_len=8M > > > nouveau.debug=disp=trace,bios=trace,i2c=trace > > > 3 > > > > > > On this particular run, closing the lid and then opening got me back to > > > the > > > console, but then I tried running > > > > > > echo mem > /sys/power/state > > > > > > and it did not recover from that. That is, the laptop is awake, I can > > > ssh > > > in, screen back-light is on; black screen. > > > > > > j > > > > > > On Sunday, January 12, 2020 2:02:00 PM AKST Joshua J. Kugler wrote: > > > > Howdy! I've been doing a lot of troubleshooting, and haven't arrived > > > > at > > > > a > > > > solution yet. > > > > > > > > Kernel log attached. VBIOS also attached. > > > > Ubuntu 19.10 > > > > > > > > $ uname -a > > > > Linux joyful 5.3.0-26-generic #28-Ubuntu SMP Wed Dec 18 05:37:46 UTC > > > > 2019 > > > > x86_64 x86_64 x86_64 GNU/Linux > > > > $ dpkg -l|grep nouveau > > > > ii libdrm-nouveau2:amd64 2.4.99-1ubuntu1 > > > > amd64 Userspace interface to nouveau-specific kernel DRM > > > > services > > > > -- > > > > runtime > > > > ii xserver-xorg-video-nouveau 1:1.0.16-1 > > > > amd64 X.Org X server -- Nouveau display driver > > > > $ lspci |grep VGA > > > > 01:00.0 VGA compatible controller: NVIDIA Corporation GT218M [NVS > > > > 3100M] > > > > (rev a2) > > > > > > > > This is a Dell Latitude E6510, so not exactly bleeding edge. :) > > > > > > > > The system boots just fine, and I can use the laptop without issue. > > > > Goes > > > > to > > > > sleep just fine. When I resume from sleep, the display is black, and > > > > will > > > > not come to life (the back light is on, though). I can ssh in, and > > > > run > > > > all > > > > kinds of commands; restart the display manager does *not* bring it > > > > back > > > > to > > > > life. > > > > > > > > Any tips would be greatly appreciated. > > > > > > > > j > > > > > > -- > > > Joshua J. Kugler - Fairbanks, Alaska - joshua at azariah.com > > > Azariah Enterprises - Programming and Website Design > > > PGP Key: http://pgp.mit.edu/ ID > > > 0x68108cbb73b13b6a_______________________________________________ > > > Nouveau > > > mailing list > > > Nouveau at lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/nouveau-- Joshua J. Kugler - Fairbanks, Alaska - joshua at azariah.com Azariah Enterprises - Programming and Website Design PGP Key: http://pgp.mit.edu/ ID 0x68108cbb73b13b6a -------------- next part -------------- A non-text attachment was scrubbed... Name: kernel_log_2020-01-14-2.txt.gz Type: application/gzip Size: 64810 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/nouveau/attachments/20200114/00351ce6/attachment-0001.gz>
Just curious if any of the recent fixes have addressed this. :) j On Tuesday, January 14, 2020 1:05:28 PM AKDT Joshua J. Kugler wrote:> Another log, per Lyude on #nouveau. > > j > > On Tuesday, January 14, 2020 8:52:51 AM AKST Joshua J. Kugler wrote: > > Here we go! > > > > j > > > > On Tuesday, January 14, 2020 7:08:20 AM AKST Ilia Mirkin wrote: > > > Hi Joshua, > > > > > > Not a fix for your issue, but Ben noticed this (and fixed it): > > > > > > https://github.com/skeggsb/nouveau/commit/024bda7d2b0c3b0731433d60a494c7 > > > 8a > > > b5 8cb216 > > > > > > which is what causes us to even try 540MB/s link training. However > > > with this fix applied, it'll just give up faster. I'm told eDP is > > > generally a single lane, and you're trying to get more than 270MB/s. > > > So ... the question is ... why is it trying to do 10bpc. One likely > > > reason is that the display_info.bpc == 0 for some reason (and we, > > > rather questionably, default to 10bpc for bandwidth determination). > > > There's no concrete theory as to what that reason might be, but it > > > would explain what's going on. > > > > > > After resuming into a bad state, can you grab the contents of > > > /sys/class/drm/card0-eDP-1/edid (you'll have to cat it or something)? > > > My hope is that it's somehow messed up. > > > > > > Also, can you add "drm.debug=0x1e" to the boot cmd line, in addition > > > to the bits you have already? Should provide some more info, perhaps > > > some of it will even be relevant. > > > > > > Thanks, > > > > > > -ilia > > > > > > On Mon, Jan 13, 2020 at 6:48 PM Joshua J. Kugler <joshua at azariah.com> > > wrote: > > > > I've added debugging command-line parameters to the kernel command > > > > line, > > > > per skeggsb and imirkin on #nouveau. > > > > > > > > root at joyful:~# cat /proc/cmdline > > > > BOOT_IMAGE=/vmlinuz-5.3.0-26-generic root=/dev/mapper/vgubuntu-root ro > > > > quiet splash log_buf_len=8M > > > > nouveau.debug=disp=trace,bios=trace,i2c=trace > > > > 3 > > > > > > > > On this particular run, closing the lid and then opening got me back > > > > to > > > > the > > > > console, but then I tried running > > > > > > > > echo mem > /sys/power/state > > > > > > > > and it did not recover from that. That is, the laptop is awake, I can > > > > ssh > > > > in, screen back-light is on; black screen. > > > > > > > > j > > > > > > > > On Sunday, January 12, 2020 2:02:00 PM AKST Joshua J. Kugler wrote: > > > > > Howdy! I've been doing a lot of troubleshooting, and haven't arrived > > > > > at > > > > > a > > > > > solution yet. > > > > > > > > > > Kernel log attached. VBIOS also attached. > > > > > Ubuntu 19.10 > > > > > > > > > > $ uname -a > > > > > Linux joyful 5.3.0-26-generic #28-Ubuntu SMP Wed Dec 18 05:37:46 UTC > > > > > 2019 > > > > > x86_64 x86_64 x86_64 GNU/Linux > > > > > $ dpkg -l|grep nouveau > > > > > ii libdrm-nouveau2:amd64 2.4.99-1ubuntu1 > > > > > amd64 Userspace interface to nouveau-specific kernel DRM > > > > > services > > > > > -- > > > > > runtime > > > > > ii xserver-xorg-video-nouveau 1:1.0.16-1 > > > > > amd64 X.Org X server -- Nouveau display driver > > > > > $ lspci |grep VGA > > > > > 01:00.0 VGA compatible controller: NVIDIA Corporation GT218M [NVS > > > > > 3100M] > > > > > (rev a2) > > > > > > > > > > This is a Dell Latitude E6510, so not exactly bleeding edge. :) > > > > > > > > > > The system boots just fine, and I can use the laptop without issue. > > > > > Goes > > > > > to > > > > > sleep just fine. When I resume from sleep, the display is black, and > > > > > will > > > > > not come to life (the back light is on, though). I can ssh in, and > > > > > run > > > > > all > > > > > kinds of commands; restart the display manager does *not* bring it > > > > > back > > > > > to > > > > > life. > > > > > > > > > > Any tips would be greatly appreciated. > > > > > > > > > > j > > > > > > > > -- > > > > Joshua J. Kugler - Fairbanks, Alaska - joshua at azariah.com > > > > Azariah Enterprises - Programming and Website Design > > > > PGP Key: http://pgp.mit.edu/ ID > > > > 0x68108cbb73b13b6a_______________________________________________ > > > > Nouveau > > > > mailing list > > > > Nouveau at lists.freedesktop.org > > > > https://lists.freedesktop.org/mailman/listinfo/nouveau-- Joshua J. Kugler - Fairbanks, Alaska - joshua at azariah.com Azariah Enterprises - Programming and Website Design PGP Key: http://pgp.mit.edu/ ID 0x68108cbb73b13b6a
Sorry, haven't really looked since our initial interaction. That EDID
decodes as:
Block 0, Base EDID:
EDID Structure Version & Revision: 1.0
Vendor & Product Identification:
Manufacturer: SEC
Model: 21569
Made in: 2010
Basic Display Parameters & Features:
Digital display
Maximum image size: 34 cm x 19 cm
Gamma: 2.20
RGB color display
First detailed timing is preferred timing
Color Characteristics:
Red : 0.6201, 0.3398
Green: 0.3300, 0.5703
Blue : 0.1503, 0.0595
White: 0.3134, 0.3291
Established Timings I & II: none
Standard Timings: none
Detailed Timing Descriptors:
DTD 1: 1366x768 60.003 Hz 683:384 47.402 kHz 75.180 MHz (344
mm x 194 mm)
Hfront 48 Hsync 32 Hback 140 Hpol P
Vfront 2 Vsync 5 Vback 15 Vpol N
DTD 2: 1366x768 39.999 Hz 683:384 31.599 kHz 48.220 MHz (344
mm x 194 mm)
Hfront 48 Hsync 32 Hback 80 Hpol P
Vfront 2 Vsync 5 Vback 15 Vpol N
Alphanumeric Data String: 'T892T'
Manufacturer-Specified Display Descriptor (0x00): 00 00 00 00 41
01 19 00 00 00 00 09 01 0a 20 20 '....A......... '
Checksum: 0x4
----------------
edid-decode SHA: 9bdf55523f83072f5c056953f1fbc9fcf09d9496
Warnings:
Block 0, Base EDID:
EDID Structure Version & Revision: EDID 1.0 is deprecated, do not use.
Failures:
Block 0, Base EDID:
Basic Display Parameters & Features: Digital Video Interface
Standard set to reserved value 0x15.
Display Descriptor #3: Has descriptor blocks other than detailed timings.
Alphanumeric Data String: Non-printable character.
Display Descriptor #4: Has descriptor blocks other than detailed timings.
and in your logs you have
[ 289.906506] nouveau 0000:01:00.0: disp: outp 00:0006:0344: data
281925 KB/s link 0 KB/s mst 0->0
[ 289.906511] nouveau 0000:01:00.0: disp: outp 00:0006:0344: link
requirements changed
Where completely coincidentally,
75180 * 30 / 8 = 281925
So it's clearly wanting 10bpc. And based on my reading of the logic in
drm_edid.c, your display_info.bpc with that edid would == 0. However
in nouveau_connector_detect_depth() we would then force it to 6. And
in nv50_mstc_get_modes it'd become 8. So this is still a bit unclear
to me.
If you're up to it, do some tracing, try to figure out why it's
deciding to do 10bpc.
Cheers,
-ilia
On Tue, Mar 31, 2020 at 8:37 PM Joshua J. Kugler <joshua at azariah.com>
wrote:>
> Just curious if any of the recent fixes have addressed this. :)
>
> j
>
> On Tuesday, January 14, 2020 1:05:28 PM AKDT Joshua J. Kugler wrote:
> > Another log, per Lyude on #nouveau.
> >
> > j
> >
> > On Tuesday, January 14, 2020 8:52:51 AM AKST Joshua J. Kugler wrote:
> > > Here we go!
> > >
> > > j
> > >
> > > On Tuesday, January 14, 2020 7:08:20 AM AKST Ilia Mirkin wrote:
> > > > Hi Joshua,
> > > >
> > > > Not a fix for your issue, but Ben noticed this (and fixed
it):
> > > >
> > > >
https://github.com/skeggsb/nouveau/commit/024bda7d2b0c3b0731433d60a494c7
> > > > 8a
> > > > b5 8cb216
> > > >
> > > > which is what causes us to even try 540MB/s link training.
However
> > > > with this fix applied, it'll just give up faster.
I'm told eDP is
> > > > generally a single lane, and you're trying to get more
than 270MB/s.
> > > > So ... the question is ... why is it trying to do 10bpc. One
likely
> > > > reason is that the display_info.bpc == 0 for some reason
(and we,
> > > > rather questionably, default to 10bpc for bandwidth
determination).
> > > > There's no concrete theory as to what that reason might
be, but it
> > > > would explain what's going on.
> > > >
> > > > After resuming into a bad state, can you grab the contents
of
> > > > /sys/class/drm/card0-eDP-1/edid (you'll have to cat it
or something)?
> > > > My hope is that it's somehow messed up.
> > > >
> > > > Also, can you add "drm.debug=0x1e" to the boot cmd
line, in addition
> > > > to the bits you have already? Should provide some more info,
perhaps
> > > > some of it will even be relevant.
> > > >
> > > > Thanks,
> > > >
> > > > -ilia
> > > >
> > > > On Mon, Jan 13, 2020 at 6:48 PM Joshua J. Kugler <joshua
at azariah.com>
> >
> > wrote:
> > > > > I've added debugging command-line parameters to the
kernel command
> > > > > line,
> > > > > per skeggsb and imirkin on #nouveau.
> > > > >
> > > > > root at joyful:~# cat /proc/cmdline
> > > > > BOOT_IMAGE=/vmlinuz-5.3.0-26-generic
root=/dev/mapper/vgubuntu-root ro
> > > > > quiet splash log_buf_len=8M
> > > > > nouveau.debug=disp=trace,bios=trace,i2c=trace
> > > > > 3
> > > > >
> > > > > On this particular run, closing the lid and then
opening got me back
> > > > > to
> > > > > the
> > > > > console, but then I tried running
> > > > >
> > > > > echo mem > /sys/power/state
> > > > >
> > > > > and it did not recover from that. That is, the laptop
is awake, I can
> > > > > ssh
> > > > > in, screen back-light is on; black screen.
> > > > >
> > > > > j
> > > > >
> > > > > On Sunday, January 12, 2020 2:02:00 PM AKST Joshua J.
Kugler wrote:
> > > > > > Howdy! I've been doing a lot of
troubleshooting, and haven't arrived
> > > > > > at
> > > > > > a
> > > > > > solution yet.
> > > > > >
> > > > > > Kernel log attached. VBIOS also attached.
> > > > > > Ubuntu 19.10
> > > > > >
> > > > > > $ uname -a
> > > > > > Linux joyful 5.3.0-26-generic #28-Ubuntu SMP Wed
Dec 18 05:37:46 UTC
> > > > > > 2019
> > > > > > x86_64 x86_64 x86_64 GNU/Linux
> > > > > > $ dpkg -l|grep nouveau
> > > > > > ii libdrm-nouveau2:amd64
2.4.99-1ubuntu1
> > > > > > amd64 Userspace interface to
nouveau-specific kernel DRM
> > > > > > services
> > > > > > --
> > > > > > runtime
> > > > > > ii xserver-xorg-video-nouveau
1:1.0.16-1
> > > > > > amd64 X.Org X server -- Nouveau display
driver
> > > > > > $ lspci |grep VGA
> > > > > > 01:00.0 VGA compatible controller: NVIDIA
Corporation GT218M [NVS
> > > > > > 3100M]
> > > > > > (rev a2)
> > > > > >
> > > > > > This is a Dell Latitude E6510, so not exactly
bleeding edge. :)
> > > > > >
> > > > > > The system boots just fine, and I can use the
laptop without issue.
> > > > > > Goes
> > > > > > to
> > > > > > sleep just fine. When I resume from sleep, the
display is black, and
> > > > > > will
> > > > > > not come to life (the back light is on, though).
I can ssh in, and
> > > > > > run
> > > > > > all
> > > > > > kinds of commands; restart the display manager
does *not* bring it
> > > > > > back
> > > > > > to
> > > > > > life.
> > > > > >
> > > > > > Any tips would be greatly appreciated.
> > > > > >
> > > > > > j
> > > > >
> > > > > --
> > > > > Joshua J. Kugler - Fairbanks, Alaska - joshua at
azariah.com
> > > > > Azariah Enterprises - Programming and Website Design
> > > > > PGP Key: http://pgp.mit.edu/ ID
> > > > >
0x68108cbb73b13b6a_______________________________________________
> > > > > Nouveau
> > > > > mailing list
> > > > > Nouveau at lists.freedesktop.org
> > > > > https://lists.freedesktop.org/mailman/listinfo/nouveau
>
>
> --
> Joshua J. Kugler - Fairbanks, Alaska - joshua at azariah.com
> Azariah Enterprises - Programming and Website Design
> PGP Key: http://pgp.mit.edu/ ID 0x68108cbb73b13b6a
>
>
> _______________________________________________
> Nouveau mailing list
> Nouveau at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau