[Nouveau] [Bug 102722] [regression] changing resolution hangs the display on Lenovo Thinkpad p51
https://bugs.freedesktop.org/show_bug.cgi?id=102722 --- Comment #6 from craig harmer --- Created attachment 134218 --> https://bugs.freedesktop.org/attachment.cgi?id=134218&action=edit Kubuntu 16.04.3 contents of /etc/X11 compressed tarball of /etc/X11, consisting of the following files: craigster0@wideload[xorg-config-16.04.3] tar -tf etc-X11.tgz etc/X11/ etc/X11/xkb/ etc/X11/Xresources/ etc/X11/Xresources/x11-common etc/X11/xinit/ etc/X11/xinit/xserverrc etc/X11/xinit/xinitrc etc/X11/xinit/xinputrc etc/X11/xinit/xinitrc.d/ etc/X11/Xreset etc/X11/xsm/ etc/X11/xsm/system.xsm etc/X11/fonts/ etc/X11/fonts/Type1/ etc/X11/fonts/Type1/xfonts-scalable.scale etc/X11/fonts/misc/ etc/X11/fonts/misc/xfonts-base.alias etc/X11/Xsession.options etc/X11/Xwrapper.config etc/X11/rgb.txt etc/X11/Xsession etc/X11/cursors/ etc/X11/cursors/Breeze_Snow.theme etc/X11/cursors/breeze_cursors.theme etc/X11/Xreset.d/ etc/X11/Xreset.d/README etc/X11/app-defaults/ etc/X11/app-defaults/XLogo-color etc/X11/app-defaults/Bitmap-nocase etc/X11/app-defaults/Xditview etc/X11/app-defaults/XMore etc/X11/app-defaults/XCalc etc/X11/app-defaults/XSm etc/X11/app-defaults/Xvidtune etc/X11/app-defaults/XClock-color etc/X11/app-defaults/Xfd etc/X11/app-defaults/XLogo etc/X11/app-defaults/Xmag etc/X11/app-defaults/XLoad etc/X11/app-defaults/Xedit-color etc/X11/app-defaults/Bitmap-color etc/X11/app-defaults/Viewres-color etc/X11/app-defaults/XClock etc/X11/app-defaults/Clock-color etc/X11/app-defaults/Xgc-color etc/X11/app-defaults/Xedit etc/X11/app-defaults/Xgc etc/X11/app-defaults/Editres-color etc/X11/app-defaults/XClipboard etc/X11/app-defaults/Editres etc/X11/app-defaults/XFontSel etc/X11/app-defaults/Xmessage etc/X11/app-defaults/Bitmap etc/X11/app-defaults/Viewres etc/X11/app-defaults/Xditview-chrtr etc/X11/app-defaults/Xmessage-color etc/X11/app-defaults/XConsole etc/X11/app-defaults/Xman etc/X11/app-defaults/XCalc-color etc/X11/Xsession.d/ etc/X11/Xsession.d/70im-config_launch etc/X11/Xsession.d/65snappy etc/X11/Xsession.d/35x11-common_xhost-local etc/X11/Xsession.d/50x11-common_determine-startup etc/X11/Xsession.d/60xdg-user-dirs-update etc/X11/Xsession.d/40x11-common_xsessionrc etc/X11/Xsession.d/75dbus_dbus-launch etc/X11/Xsession.d/60x11-common_localhost etc/X11/Xsession.d/70gconfd_path-on-session etc/X11/Xsession.d/99x11-common_start etc/X11/Xsession.d/95dbus_update-activation-env etc/X11/Xsession.d/60x11-common_xdg_path etc/X11/Xsession.d/30x11-common_xresources etc/X11/Xsession.d/20x11-common_process-args etc/X11/Xsession.d/70xdg-kubuntu-dir etc/X11/Xsession.d/80kubuntu-xmodmap etc/X11/Xsession.d/90x11-common_ssh-agent etc/X11/Xsession.d/90qt-a11y etc/X11/Xsession.d/90gpg-agent etc/X11/default-display-manager craigster0@wideload[xorg-config-16.04.3] tar -tf etc-X11.tgz etc/X11/ etc/X11/xkb/ etc/X11/Xresources/ etc/X11/Xresources/x11-common etc/X11/xinit/ etc/X11/xinit/xserverrc etc/X11/xinit/xinitrc etc/X11/xinit/xinputrc etc/X11/xinit/xinitrc.d/ etc/X11/Xreset etc/X11/xsm/ etc/X11/xsm/system.xsm etc/X11/fonts/ etc/X11/fonts/Type1/ etc/X11/fonts/Type1/xfonts-scalable.scale etc/X11/fonts/misc/ etc/X11/fonts/misc/xfonts-base.alias etc/X11/Xsession.options etc/X11/Xwrapper.config etc/X11/rgb.txt etc/X11/Xsession etc/X11/cursors/ etc/X11/cursors/Breeze_Snow.theme etc/X11/cursors/breeze_cursors.theme etc/X11/Xreset.d/ etc/X11/Xreset.d/README etc/X11/app-defaults/ etc/X11/app-defaults/XLogo-color etc/X11/app-defaults/Bitmap-nocase etc/X11/app-defaults/Xditview etc/X11/app-defaults/XMore etc/X11/app-defaults/XCalc etc/X11/app-defaults/XSm etc/X11/app-defaults/Xvidtune etc/X11/app-defaults/XClock-color etc/X11/app-defaults/Xfd etc/X11/app-defaults/XLogo etc/X11/app-defaults/Xmag etc/X11/app-defaults/XLoad etc/X11/app-defaults/Xedit-color etc/X11/app-defaults/Bitmap-color etc/X11/app-defaults/Viewres-color etc/X11/app-defaults/XClock etc/X11/app-defaults/Clock-color etc/X11/app-defaults/Xgc-color etc/X11/app-defaults/Xedit etc/X11/app-defaults/Xgc etc/X11/app-defaults/Editres-color etc/X11/app-defaults/XClipboard etc/X11/app-defaults/Editres etc/X11/app-defaults/XFontSel etc/X11/app-defaults/Xmessage etc/X11/app-defaults/Bitmap etc/X11/app-defaults/Viewres etc/X11/app-defaults/Xditview-chrtr etc/X11/app-defaults/Xmessage-color etc/X11/app-defaults/XConsole etc/X11/app-defaults/Xman etc/X11/app-defaults/XCalc-color etc/X11/Xsession.d/ etc/X11/Xsession.d/70im-config_launch etc/X11/Xsession.d/65snappy etc/X11/Xsession.d/35x11-common_xhost-local etc/X11/Xsession.d/50x11-common_determine-startup etc/X11/Xsession.d/60xdg-user-dirs-update etc/X11/Xsession.d/40x11-common_xsessionrc etc/X11/Xsession.d/75dbus_dbus-launch etc/X11/Xsession.d/60x11-common_localhost etc/X11/Xsession.d/70gconfd_path-on-session etc/X11/Xsession.d/99x11-common_start etc/X11/Xsession.d/95dbus_update-activation-env etc/X11/Xsession.d/60x11-common_xdg_path etc/X11/Xsession.d/30x11-common_xresources etc/X11/Xsession.d/20x11-common_process-args etc/X11/Xsession.d/70xdg-kubun
[Nouveau] [Bug 102722] [regression] changing resolution hangs the display on Lenovo Thinkpad p51
https://bugs.freedesktop.org/show_bug.cgi?id=102722 --- Comment #5 from craig harmer --- Created attachment 134217 --> https://bugs.freedesktop.org/attachment.cgi?id=134217&action=edit output of xrandr --verbose -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 102722] [regression] changing resolution hangs the display on Lenovo Thinkpad p51
https://bugs.freedesktop.org/show_bug.cgi?id=102722 --- Comment #4 from craig harmer --- Created attachment 134216 --> https://bugs.freedesktop.org/attachment.cgi?id=134216&action=edit output of lspci -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 102722] [regression] changing resolution hangs the display on Lenovo Thinkpad p51
https://bugs.freedesktop.org/show_bug.cgi?id=102722 craig harmer changed: What|Removed |Added CC||charmer-freedesktop.org@pun ||chdown.org --- Comment #3 from craig harmer --- Created attachment 134215 --> https://bugs.freedesktop.org/attachment.cgi?id=134215&action=edit Kubuntu 16.04.3 dmesg output (probably nothing that's not in /var/log/syslog, above) -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 102722] [regression] changing resolution hangs the display on Lenovo Thinkpad p51
https://bugs.freedesktop.org/show_bug.cgi?id=102722 --- Comment #2 from craig harmer --- Created attachment 134214 --> https://bugs.freedesktop.org/attachment.cgi?id=134214&action=edit Kubuntu 16.04.3 /var/log/Xorg.0.log the contents of /var/log/Xorg.0.log -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 102722] [regression] changing resolution hangs the display on Lenovo Thinkpad p51
https://bugs.freedesktop.org/show_bug.cgi?id=102722 --- Comment #1 from craig harmer --- Created attachment 134213 --> https://bugs.freedesktop.org/attachment.cgi?id=134213&action=edit Kubuntu 16.04.3 /var/log/syslog including a "warning" with stack trace interesting excerpt from /var/log/syslog. i don't remember exactly, but i was either trying to change the resolution on the laptop display or connect an external display: Aug 30 22:15:00 p51 org.kde.KScreen[2281]: kscreen.xrandr: XRandR::setConfig done! Aug 30 22:15:00 p51 org.kde.KScreen[2281]: kscreen: Primary output changed from KScreen::Output(Id: 99 , Name: "eDP-1" ) ( "eDP-1" ) to KScreen::Output(Id: 99 , Name: "eDP-1" ) ( "eDP-1" ) Aug 30 22:15:00 p51 kernel: [ 103.994111] nouveau :01:00.0: disp: 0x6219[0]: INIT_GENERIC_CONDITON: unknown 0x07 Aug 30 22:15:00 p51 kernel: [ 104.069777] [ cut here ] Aug 30 22:15:00 p51 kernel: [ 104.069799] WARNING: CPU: 5 PID: 2205 at /build/linux-hwe-YA6IuF/linux-hwe-4.10.0/drivers/gpu/drm/nouveau/nouveau_bo.c:137 nouveau_bo_del_ttm+0x7f/0x90 [nouveau] Aug 30 22:15:00 p51 kernel: [ 104.069800] Modules linked in: rfcomm ccm bnep nls_iso8859_1 arc4 i2c_designware_platform i2c_designware_core iwlmvm snd_hda_codec_realtek intel_rapl snd_hda_codec_generic snd_seq_midi mac80211 snd_seq_midi_event x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_intel snd_hda_codec kvm_intel snd_hda_core snd_hwdep snd_pcm iwlwifi kvm snd_rawmidi cfg80211 irqbypass rtsx_pci_ms memstick uvcvideo joydev thinkpad_acpi videobuf2_vmalloc input_leds videobuf2_memops serio_raw videobuf2_v4l2 videobuf2_core nvram videodev media snd_seq snd_seq_device idma64 snd_timer btusb virt_dma btrtl mei_me shpchp mei ucsi intel_lpss_pci intel_pch_thermal snd hci_uart btbcm btqca btintel bluetooth soundcore intel_lpss_acpi intel_lpss tpm_crb mac_hid acpi_pad parport_pc ppdev lp parport autofs4 algif_skcipher af_alg Aug 30 22:15:00 p51 kernel: [ 104.069822] dm_crypt hid_generic usbhid nouveau rtsx_pci_sdmmc crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc mxm_wmi i2c_algo_bit aesni_intel ttm drm_kms_helper aes_x86_64 crypto_simd e1000e syscopyarea glue_helper sysfillrect cryptd sysimgblt uas fb_sys_fops ptp psmouse nvme drm pps_core ahci rtsx_pci usb_storage nvme_core libahci wmi pinctrl_sunrisepoint i2c_hid video pinctrl_intel hid fjes Aug 30 22:15:00 p51 kernel: [ 104.069834] CPU: 5 PID: 2205 Comm: Xorg Not tainted 4.10.0-33-generic #37~16.04.1-Ubuntu Aug 30 22:15:00 p51 kernel: [ 104.069834] Hardware name: LENOVO 20HHCTO1WW/20HHCTO1WW, BIOS N1UET31W (1.05 ) 02/13/2017 Aug 30 22:15:00 p51 kernel: [ 104.069835] Call Trace: Aug 30 22:15:00 p51 kernel: [ 104.069838] dump_stack+0x63/0x90 Aug 30 22:15:00 p51 kernel: [ 104.069839] __warn+0xcb/0xf0 Aug 30 22:15:00 p51 org.kde.KScreen[2281]: kscreen.xcb.helper: RRNotify_CrtcChange Aug 30 22:15:00 p51 kernel: [ 104.069840] warn_slowpath_null+0x1d/0x20 Aug 30 22:15:00 p51 kernel: [ 104.069855] nouveau_bo_del_ttm+0x7f/0x90 [nouveau] Aug 30 22:15:00 p51 kernel: [ 104.069858] ttm_bo_release_list+0xb5/0x170 [ttm] Aug 30 22:15:00 p51 kernel: [ 104.069860] ttm_bo_release+0x1ae/0x240 [ttm] Aug 30 22:15:00 p51 kernel: [ 104.069861] ttm_bo_unref+0x24/0x30 [ttm] Aug 30 22:15:00 p51 kernel: [ 104.069875] nouveau_gem_object_del+0x9a/0xf0 [nouveau] Aug 30 22:15:00 p51 kernel: [ 104.069881] drm_gem_object_free+0x29/0x70 [drm] Aug 30 22:15:00 p51 kernel: [ 104.069884] drm_gem_object_unreference_unlocked+0x3a/0xa0 [drm] Aug 30 22:15:00 p51 org.kde.KScreen[2281]: kscreen.xcb.helper: #011CRTC: 95 Aug 30 22:15:00 p51 kernel: [ 104.069887] drm_gem_object_handle_unreference_unlocked+0x65/0xb0 [drm] Aug 30 22:15:00 p51 kernel: [ 104.069891] drm_gem_object_release_handle+0x53/0x90 [drm] Aug 30 22:15:00 p51 kernel: [ 104.069894] drm_gem_handle_delete+0x5f/0x90 [drm] Aug 30 22:15:00 p51 kernel: [ 104.069897] drm_gem_close_ioctl+0x20/0x30 [drm] Aug 30 22:15:00 p51 kernel: [ 104.069901] drm_ioctl+0x21b/0x4d0 [drm] Aug 30 22:15:00 p51 org.kde.KScreen[2281]: kscreen.xcb.helper: #011Mode: 106 Aug 30 22:15:00 p51 kernel: [ 104.069904] ? drm_gem_handle_create+0x40/0x40 [drm] Aug 30 22:15:00 p51 kernel: [ 104.069906] ? signal_setup_done+0x6b/0xb0 Aug 30 22:15:00 p51 kernel: [ 104.069919] nouveau_drm_ioctl+0x68/0xc0 [nouveau] Aug 30 22:15:00 p51 kernel: [ 104.069921] do_vfs_ioctl+0xa1/0x5f0 Aug 30 22:15:00 p51 kernel: [ 104.069922] SyS_ioctl+0x79/0x90 Aug 30 22:15:00 p51 org.kde.KScreen[2281]: kscreen.xcb.helper: #011Rotation: "Rotate_0" Aug 30 22:15:00 p51 kernel: [ 104.069924] entry_SYSCALL_64_fastpath+0x1e/0xad Aug 30 22:15:00 p51 kernel: [ 104.069924] RIP: 0033:0x7ff294fdef07 Aug 30 22:15:00 p51 kernel: [ 104.069925] RSP: 002b:7fff5686def8 EFLAGS: 3246 ORIG_RAX: 0010 Aug 30 22:15:00 p51 kernel: [ 104.069925] RAX: ffda RBX: 0018 RCX: 7ff294fdef07 Aug 30 22:15:00 p51 kernel: [ 104.069926] RDX: 7ff
[Nouveau] [Bug 102722] New: [regression] changing resolution hangs the display on Lenovo Thinkpad p51
https://bugs.freedesktop.org/show_bug.cgi?id=102722 Bug ID: 102722 Summary: [regression] changing resolution hangs the display on Lenovo Thinkpad p51 Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: critical Priority: medium Component: Driver/nouveau Assignee: nouveau@lists.freedesktop.org Reporter: charmer-freedesktop@punchdown.org QA Contact: xorg-t...@lists.x.org on my brand new, rather expensive, Lenovo Thinkpad p51 (model 20HHCTO1WW) changing the display resolution from 4K to something readable causes the display to go black. the only way to recover is to power cycle the laptop. this is a regression. with the newer Nouveau driver included in Kubuntu 16.04.3 (Ubuntu 16.04.3), changing the resolution from 4K (3840x2160) to 2K (1920x1080) (and probably any other resolution) causes the screen to go black. with the older Nouveau driver included in Kubuntu 16.04.2 (Ubuntu 16.04.2) changing the display resolution from 4K to 2K works fine. Kubuntu 16.04.2 uses the xserver-xorg-video-nouveau-hwe-16.04 package at version 1:1.0.12-2~16.04.1. Kubuntu 16.04.3 uses the xserver-xorg-video-nouveau-hwe-16.04 package at version 1:1.0.14-0ubuntu1 apparently the change from 1.0.12 --> 1.0.14 broke the ability to change the screen resolution. but on the plus side, the Nouveau driver in 16.04.3 (1:1.0.14-0ubuntu1) fixes an equally dire problem where the screen around the cursor is "corrupted" in a way that makes the 16.04.2 driver pretty much unusable. more details: i just bought a Lenovo p51with the intention of running Ubuntu (Kubuntu) Linux on it. so far the new laptop is unusable due to display driver issues (both Nouveau and proprietary Nvidia drivers have issues that make them unusable). my laptop configuration is tagged as model 20HHCTO1WW and includes a 3840x2160 display, "hybrid" NVIDIA Quadro M2200M 4GB, and Xeon E3-1505M. the driver seems to identify the Nvidai chip as "NVIDIA GM206 (126360a1)". i'll attach the dmesg output later. the problem is easy to reproduce by booting off a "Live USB" version of Kubuntu 16.04.3 (and the 16.04.2 Live USB if you want to see resolution change working but areas near the cursor corrupted). i marked this as Critical because its almost impossible to use the 15" screen on the laptop with a display resolution of 3840x2160 on Linux. the default text sizes make things unreadable unless i put my eyes about 3 inches (8 cm) away from the screen. if i change font sizes to be (much) larger, the labels and icons do not scale as well so they are still very difficult to read. -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 01/10] arch:powerpc: return -ENOMEM on failed allocation
> I think the changelog for this series of conversions > should show that you've validated the change by > inspecting the return call chain at each modified line. > > Also, it seems you've cc'd the same mailing lists for > all of the patches modified by this series. > > It would be better to individually address each patch > in the series only cc'ing the appropriate maintainers > and mailing lists. > > A cover letter would be good too. Point noted. Thanks. - Allen ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 07/10] driver:megaraid: return -ENOMEM on allocation failure.
Signed-off-by: Allen Pais --- drivers/scsi/megaraid/megaraid_mbox.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_mbox.c b/drivers/scsi/megaraid/megaraid_mbox.c index ec3c438..b09a0a6 100644 --- a/drivers/scsi/megaraid/megaraid_mbox.c +++ b/drivers/scsi/megaraid/megaraid_mbox.c @@ -724,8 +724,8 @@ megaraid_init_mbox(adapter_t *adapter) * controllers */ raid_dev = kzalloc(sizeof(mraid_device_t), GFP_KERNEL); - if (raid_dev == NULL) return -1; - + if (!raid_dev) + return -ENOMEM; /* * Attach the adapter soft state to raid device soft state -- 2.7.4 ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 09/10] driver:video: return -ENOMEM on allocation failure.
Signed-off-by: Allen Pais --- drivers/video/fbdev/matrox/matroxfb_base.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/fbdev/matrox/matroxfb_base.c b/drivers/video/fbdev/matrox/matroxfb_base.c index f6a0b9a..5cd238d 100644 --- a/drivers/video/fbdev/matrox/matroxfb_base.c +++ b/drivers/video/fbdev/matrox/matroxfb_base.c @@ -2058,7 +2058,7 @@ static int matroxfb_probe(struct pci_dev* pdev, const struct pci_device_id* dumm minfo = kzalloc(sizeof(*minfo), GFP_KERNEL); if (!minfo) - return -1; + return -ENOMEM; minfo->pcidev = pdev; minfo->dead = 0; -- 2.7.4 ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 02/10] drivers:crypto: return -ENOMEM on allocation failure.
Signed-off-by: Allen Pais
---
drivers/crypto/omap-aes-gcm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/omap-aes-gcm.c b/drivers/crypto/omap-aes-gcm.c
index 7d4f8a4..2542224 100644
--- a/drivers/crypto/omap-aes-gcm.c
+++ b/drivers/crypto/omap-aes-gcm.c
@@ -186,7 +186,7 @@ static int do_encrypt_iv(struct aead_request *req, u32
*tag, u32 *iv)
sk_req = skcipher_request_alloc(ctx->ctr, GFP_KERNEL);
if (!sk_req) {
pr_err("skcipher: Failed to allocate request\n");
- return -1;
+ return -ENOMEM;
}
init_completion(&result.completion);
--
2.7.4
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 06/10] drivers:ethernet: return -ENOMEM on allocation failure.
On Wed, Sep 13, 2017 at 01:02:15PM +0530, Allen Pais wrote:
> Signed-off-by: Allen Pais
> ---
> drivers/net/ethernet/sun/cassini.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/sun/cassini.c
> b/drivers/net/ethernet/sun/cassini.c
> index 382993c..fc0ea3a 100644
> --- a/drivers/net/ethernet/sun/cassini.c
> +++ b/drivers/net/ethernet/sun/cassini.c
> @@ -3984,7 +3984,7 @@ static inline int cas_alloc_rx_desc(struct cas *cp, int
> ring)
> size = RX_DESC_RINGN_SIZE(ring);
> for (i = 0; i < size; i++) {
> if ((page[i] = cas_page_alloc(cp, GFP_KERNEL)) == NULL)
> - return -1;
> + return -ENOMEM;
> }
> return 0;
> }
static int cas_alloc_rxds(struct cas *cp)
{
int i;
for (i = 0; i < N_RX_DESC_RINGS; i++) {
if (cas_alloc_rx_desc(cp, i) < 0) {
cas_free_rxds(cp);
return -1;
}
}
return 0;
}
Again, your change is correct, but in the end the value is not used.
And if you fix it at the cas_alloc_rxds level, you also need a fix at
the next level up:
err = -ENOMEM;
if (cas_tx_tiny_alloc(cp) < 0)
goto err_unlock;
/* alloc rx descriptors */
if (cas_alloc_rxds(cp) < 0)
goto err_tx_tiny;
again, the return value is discarded.
Andrew
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 10/10] fs:btrfs: return -ENOMEM on allocation failure.
Signed-off-by: Allen Pais
---
fs/btrfs/check-integrity.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/check-integrity.c b/fs/btrfs/check-integrity.c
index 7d5a9b5..efa4c23 100644
--- a/fs/btrfs/check-integrity.c
+++ b/fs/btrfs/check-integrity.c
@@ -2913,7 +2913,7 @@ int btrfsic_mount(struct btrfs_fs_info *fs_info,
state = kvzalloc(sizeof(*state), GFP_KERNEL);
if (!state) {
pr_info("btrfs check-integrity: allocation failed!\n");
- return -1;
+ return -ENOMEM;
}
if (!btrfsic_is_initialized) {
--
2.7.4
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 08/10] driver:cxgbit: return -NOMEM on allocation failure.
Signed-off-by: Allen Pais
---
drivers/target/iscsi/cxgbit/cxgbit_target.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/target/iscsi/cxgbit/cxgbit_target.c
b/drivers/target/iscsi/cxgbit/cxgbit_target.c
index 514986b..47127d6 100644
--- a/drivers/target/iscsi/cxgbit/cxgbit_target.c
+++ b/drivers/target/iscsi/cxgbit/cxgbit_target.c
@@ -399,7 +399,7 @@ cxgbit_map_skb(struct iscsi_cmd *cmd, struct sk_buff *skb,
u32 data_offset,
if (padding) {
page = alloc_page(GFP_KERNEL | __GFP_ZERO);
if (!page)
- return -1;
+ return -ENOMEM;
skb_fill_page_desc(skb, i, page, 0, padding);
skb->data_len += padding;
skb->len += padding;
--
2.7.4
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 03/10] driver:gpu: return -ENOMEM on allocation failure.
Signed-off-by: Allen Pais --- drivers/gpu/drm/gma500/mid_bios.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/gma500/mid_bios.c b/drivers/gpu/drm/gma500/mid_bios.c index d75ecb3..1fa1633 100644 --- a/drivers/gpu/drm/gma500/mid_bios.c +++ b/drivers/gpu/drm/gma500/mid_bios.c @@ -237,7 +237,7 @@ static int mid_get_vbt_data_r10(struct drm_psb_private *dev_priv, u32 addr) gct = kmalloc(sizeof(*gct) * vbt.panel_count, GFP_KERNEL); if (!gct) - return -1; + return -ENOMEM; gct_virtual = ioremap(addr + sizeof(vbt), sizeof(*gct) * vbt.panel_count); -- 2.7.4 ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 04/10] drivers:mpt: return -ENOMEM on allocation failure.
Signed-off-by: Allen Pais
---
drivers/message/fusion/mptbase.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/message/fusion/mptbase.c b/drivers/message/fusion/mptbase.c
index 84eab28..7920b2b 100644
--- a/drivers/message/fusion/mptbase.c
+++ b/drivers/message/fusion/mptbase.c
@@ -4328,15 +4328,15 @@ initChainBuffers(MPT_ADAPTER *ioc)
if (ioc->ReqToChain == NULL) {
sz = ioc->req_depth * sizeof(int);
mem = kmalloc(sz, GFP_ATOMIC);
- if (mem == NULL)
- return -1;
+ if (!mem)
+ return -ENOMEM;
ioc->ReqToChain = (int *) mem;
dinitprintk(ioc, printk(MYIOC_s_DEBUG_FMT "ReqToChain alloc @
%p, sz=%d bytes\n",
ioc->name, mem, sz));
mem = kmalloc(sz, GFP_ATOMIC);
- if (mem == NULL)
- return -1;
+ if (!mem)
+ return -ENOMEM;
ioc->RequestNB = (int *) mem;
dinitprintk(ioc, printk(MYIOC_s_DEBUG_FMT "RequestNB alloc @
%p, sz=%d bytes\n",
@@ -4402,8 +4402,8 @@ initChainBuffers(MPT_ADAPTER *ioc)
sz = num_chain * sizeof(int);
if (ioc->ChainToChain == NULL) {
mem = kmalloc(sz, GFP_ATOMIC);
- if (mem == NULL)
- return -1;
+ if (!mem)
+ return -ENOMEM;
ioc->ChainToChain = (int *) mem;
dinitprintk(ioc, printk(MYIOC_s_DEBUG_FMT "ChainToChain alloc @
%p, sz=%d bytes\n",
--
2.7.4
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] GTX 1080 Ti (NV132/GP102)
Hey. Thanks for the tip. I finally got around to capturing these long entries. So, here they are: http://paste.ubuntu.com/25529150/ I hope it helps. What you can see in it, are two consecutive boot-ups. The first is without `nomodeset` and therefore fails (so I don't get any display output) and the second is with `nomodeset` so I do get a usable computer but no GPU acceleration. What do the logs tell us, please? On Sat, Aug 26, 2017 at 3:17 AM wrote: > dmesg | grep nouveau . You can do this if you have ssh enabled on your > machine. > > On my 980, There was an issue introduced in 4.12 which gives me similar > behavior where I cannot boot up GNOME. Commit that fixes it which is > part of 4.13 is called "add support for address-only transactions". > > Ask your distro to backport. > > On Mon, 2017-08-21 at 14:01 +, Shahar Or wrote: > > Since the Ubuntu 17.10 that I'm running now has Linux 4.12, there > > should be some support for my card, yet I still experience the same > > phenomenon. > > > > If I DO NOT use `nomodeset`, I see the boot log shooting through and > > then blank. I can tell that it is not a system halt, because I can > > ctrl-alt-delete and the OS catches that and safely reboots. > > > > It is the official Ubuntu 4.12.0-11-generic, x86_64. > > > > 03:00.0 VGA compatible controller: NVIDIA Corporation GP102 [GeForce > > GTX 1080 Ti] (rev a1) > > > > How can I further help you help me, please? > > > > On Thu, May 25, 2017 at 7:20 PM Pierre Moreau > > wrote: > > > > Another issue is that in Google Chrome I seem have no hardware > > > acceleration > > > > for anything other than "Multiple Raster Threads". See attached. > > > > > > Two things: you are using nomodeset, and hardware acceleration for > > > Pascal cards > > > was only merged in 4.12 (which has not been released yet), as > > > pointed out by > > > Ilia. > > > > > > Pierre > > > > ___ > > 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
Re: [Nouveau] [PATCH 06/10] drivers:ethernet: return -ENOMEM on allocation failure.
From: Allen Pais Date: Wed, 13 Sep 2017 13:02:15 +0530 > Signed-off-by: Allen Pais This is quite pointless as the caller doesn't do anything with the value, it just tests whether a negative value is returned or not. ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 10/10] fs:btrfs: return -ENOMEM on allocation failure.
On Wed, Sep 13, 2017 at 01:02:19PM +0530, Allen Pais wrote:
> Signed-off-by: Allen Pais
> ---
> fs/btrfs/check-integrity.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/btrfs/check-integrity.c b/fs/btrfs/check-integrity.c
> index 7d5a9b5..efa4c23 100644
> --- a/fs/btrfs/check-integrity.c
> +++ b/fs/btrfs/check-integrity.c
> @@ -2913,7 +2913,7 @@ int btrfsic_mount(struct btrfs_fs_info *fs_info,
> state = kvzalloc(sizeof(*state), GFP_KERNEL);
> if (!state) {
> pr_info("btrfs check-integrity: allocation failed!\n");
> - return -1;
> + return -ENOMEM;
Makes sense, also please fix the -1 a few lines below that also result
from failed memory allocation, indirectly from btrfsic_dev_state_alloc().
> }
>
> if (!btrfsic_is_initialized) {
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 01/10] arch:powerpc: return -ENOMEM on failed allocation
Signed-off-by: Allen Pais
---
arch/powerpc/platforms/cell/spider-pci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/cell/spider-pci.c
b/arch/powerpc/platforms/cell/spider-pci.c
index d1e61e2..82aa3f7 100644
--- a/arch/powerpc/platforms/cell/spider-pci.c
+++ b/arch/powerpc/platforms/cell/spider-pci.c
@@ -106,7 +106,7 @@ static int __init spiderpci_pci_setup_chip(struct
pci_controller *phb,
dummy_page_va = kmalloc(PAGE_SIZE, GFP_KERNEL);
if (!dummy_page_va) {
pr_err("SPIDERPCI-IOWA:Alloc dummy_page_va failed.\n");
- return -1;
+ return -ENOMEM;
}
dummy_page_da = dma_map_single(phb->parent, dummy_page_va,
@@ -137,7 +137,7 @@ int __init spiderpci_iowa_init(struct iowa_bus *bus, void
*data)
if (!priv) {
pr_err("SPIDERPCI-IOWA:"
"Can't allocate struct spiderpci_iowa_private");
- return -1;
+ return -ENOMEM;
}
if (of_address_to_resource(np, 0, &r)) {
--
2.7.4
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 06/10] drivers:ethernet: return -ENOMEM on allocation failure.
>
> static int cas_alloc_rxds(struct cas *cp)
> {
> int i;
>
> for (i = 0; i < N_RX_DESC_RINGS; i++) {
> if (cas_alloc_rx_desc(cp, i) < 0) {
> cas_free_rxds(cp);
> return -1;
> }
> }
> return 0;
> }
>
> Again, your change is correct, but in the end the value is not used.
> And if you fix it at the cas_alloc_rxds level, you also need a fix at
> the next level up:
>
> err = -ENOMEM;
> if (cas_tx_tiny_alloc(cp) < 0)
> goto err_unlock;
>
> /* alloc rx descriptors */
> if (cas_alloc_rxds(cp) < 0)
> goto err_tx_tiny;
>
> again, the return value is discarded.
I agree. I could send out v2 with fixes at both level.
- Allen
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 05/10] drivers:net: return -ENOMEM on allocation failure.
> propagates the -1. That is only called by bond_open() with: > > if (bond_alb_initialize(bond, (BOND_MODE(bond) == BOND_MODE_ALB))) > return -ENOMEM; > > So you might want to also modify this code, to return the return > value, rather than use the hard coded ENOMEM. > I'll modify the above and send it out a separate patch. Thank you. ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 05/10] drivers:net: return -ENOMEM on allocation failure.
Signed-off-by: Allen Pais --- drivers/net/bonding/bond_alb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c index c02cc81..89df377 100644 --- a/drivers/net/bonding/bond_alb.c +++ b/drivers/net/bonding/bond_alb.c @@ -864,7 +864,7 @@ static int rlb_initialize(struct bonding *bond) new_hashtbl = kmalloc(size, GFP_KERNEL); if (!new_hashtbl) - return -1; + return -ENOMEM; spin_lock_bh(&bond->mode_lock); -- 2.7.4 ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 06/10] drivers:ethernet: return -ENOMEM on allocation failure.
Signed-off-by: Allen Pais
---
drivers/net/ethernet/sun/cassini.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/sun/cassini.c
b/drivers/net/ethernet/sun/cassini.c
index 382993c..fc0ea3a 100644
--- a/drivers/net/ethernet/sun/cassini.c
+++ b/drivers/net/ethernet/sun/cassini.c
@@ -3984,7 +3984,7 @@ static inline int cas_alloc_rx_desc(struct cas *cp, int
ring)
size = RX_DESC_RINGN_SIZE(ring);
for (i = 0; i < size; i++) {
if ((page[i] = cas_page_alloc(cp, GFP_KERNEL)) == NULL)
- return -1;
+ return -ENOMEM;
}
return 0;
}
--
2.7.4
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 05/10] drivers:net: return -ENOMEM on allocation failure.
On Wed, Sep 13, 2017 at 01:02:14PM +0530, Allen Pais wrote: > Signed-off-by: Allen Pais Hi Allen Although correct, if you look higher up the call chain, this appears to be not so useful. rlb_initialize() is only called by bond_alb_initialize(), and it propagates the -1. That is only called by bond_open() with: if (bond_alb_initialize(bond, (BOND_MODE(bond) == BOND_MODE_ALB))) return -ENOMEM; So you might want to also modify this code, to return the return value, rather than use the hard coded ENOMEM. Since you code is OK as far as it goes: Reviewed-by: Andrew Lunn Andrew ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Nouveau: kernel hang on Optimus+Intel+NVidia GeForce 1060m
Thanks Tobias, I tried this but unfortunately the only effect was thta the boot was delayed by an additional 4 seconds :( The original timeout is at drivers/gpu/drm/nouveau/nvkm/subdev/secboot/ls_ucode_msgqueue.c I tried to increase that timeout, but it did not seem to make a difference either. I think I get this error less often when I have a cable plugged in the output of that card at boot, whereas I always get this error when I boot without a monitor attached to the card. On Wed, Sep 13, 2017 at 2:28 PM, Tobias Klausmann < tobias.johannes.klausm...@mni.thm.de> wrote: > Hi, > > the system fails to initialize your vbios using secureboot (i had a rare > chance to on my system to witness it again), for now i traced it to > acr_boot_falcon() in > "linux/drivers/gpu/drm/nouveau/nvkm/falcon/msgqueue_0148cdec.c" where it > throws -110 which is -ETIMEDOUT. You could try to increase the timeout > and see if it helps something, similar to the following: > > > diff --git a/drivers/gpu/drm/nouveau/nvkm/falcon/msgqueue.c > b/drivers/gpu/drm/nouveau/nvkm/falcon/msgqueue.c > index 77273b53672c..fc0cb187d80d 100644 > --- a/drivers/gpu/drm/nouveau/nvkm/falcon/msgqueue.c > +++ b/drivers/gpu/drm/nouveau/nvkm/falcon/msgqueue.c > @@ -326,7 +326,7 @@ nvkm_msgqueue_post(struct nvkm_msgqueue *priv, enum > msgqueue_msg_priority prio, > int ret; > > if (wait_init && !wait_for_completion_timeout(&priv->init_done, > -msecs_to_jiffies(1000))) > +msecs_to_jiffies(5000))) > return -ETIMEDOUT; > > queue = priv->func->cmd_queue(priv, prio); > > diff --git a/drivers/gpu/drm/nouveau/nvkm/falcon/msgqueue_0137c63d.c > b/drivers/gpu/drm/nouveau/nvkm/falcon/msgqueue_0137c63d.c > index fec0273158f6..c2ae525a0780 100644 > --- a/drivers/gpu/drm/nouveau/nvkm/falcon/msgqueue_0137c63d.c > +++ b/drivers/gpu/drm/nouveau/nvkm/falcon/msgqueue_0137c63d.c > @@ -279,6 +279,7 @@ acr_boot_falcon(struct nvkm_msgqueue *priv, enum > nvkm_secboot_falcon falcon) > u32 flags; > u32 falcon_id; > } cmd; > + const struct nvkm_subdev *subdev = priv->falcon->owner; > > memset(&cmd, 0, sizeof(cmd)); > > @@ -290,7 +291,8 @@ acr_boot_falcon(struct nvkm_msgqueue *priv, enum > nvkm_secboot_falcon falcon) > nvkm_msgqueue_post(priv, MSGQUEUE_MSG_PRIORITY_HIGH, &cmd.hdr, > acr_boot_falcon_callback, &completed, true); > > - if (!wait_for_completion_timeout(&completed, > msecs_to_jiffies(1000))) > + nvkm_error(subdev, "waiting for timeout in acr_boot_falcon > (msgqueue_0137bca5)\n"); > + if (!wait_for_completion_timeout(&completed, > msecs_to_jiffies(5000))) > return -ETIMEDOUT; > > return 0; > > > > On 9/13/17 11:37 AM, Nicolas Mercier wrote: > > I am still looking for a solution. I have hacked around in the code > > and found out the following: > > - Nouveau prefers using PCIE power managemet over ACPI Optimus calls. > > I tried to force it to use Optimus ACPI calls, but there was an error > > calling the ACPI method so it bails out and uses PCIE PM anyway. > > - I tried to debug the PCIE pm states which internally uses ACPI to > > turn power on/off. I could print different statuses here and there. > > When the power is switched off, ACPI calls turn the power off then the > > kernel successfully puts the device in state D3Cold (also turning off > > power to the PCI Express port). When waking up, ACPI turns the power > > on, apparently successfully (Device [PEGP] transitioned to D0). But a > > read from the PCI bus to get the power state & other flags return > > 65535 (~0) and the kernel fails to set the device in D0 (although ACPI > > claims it is in D0) > > The call to pci_raw_set_power_state (in drivers/pci/pci.c) seems to > > fail because pci_read_config_word returns "~0" (and does not return > > any error code) > > > > I have tried different things; if I use pcie_port_pm=off, the NVidia > > card goes to state D3Hot (if I am not mistaken, its PCIE port is still > > powered) but that did not fix it. I tried to turn on or off different > > PCI/PCIexpress features such as hotplug, PM and so on. The only thing > > that works is that PM is fully disabled, which equals to the device > > not being powered off, so that would be equivalent to nouveau.runpm=0, > > which is not helping a lot. I have tried to force pcie aspm by > > recompiling the ACPI table, still no luck. > > > > I am still taking a look, but it seems like the problem comes from the > > PCIExpress PM functions and ACPI, not directly from Nouveau > > > > /n > ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 93828] Xorg hangs randomly with nouveau driver
https://bugs.freedesktop.org/show_bug.cgi?id=93828 --- Comment #19 from bit...@earthlink.net --- The nouveau driver hangs with mythfrontend. My system is a desktop intel i7 onboard graphics running kde plasma and a separate user (seat) running mythfrontend directly on X (not kde) using an nvidia GT240 The allows me to use my desktop system at the same time the TV is running mythtv in an adjacent room. When the nouveau driver hangs it has no affect on the desktop system, the last frame or menu remains static on the TV even after restarting the mythfrontend application. I can reliably cause the hang by stopping the video player using the remote control then trying to stop it again before it completes the first stop. I see the last frame of video and the remote no longer works. Restarting the mythfrontend application, as root on the desktop, blanks the screen then the last frame of video is shown on the TV even though the application has not started a player. Restarting should display a menu, but once hung the picture does not change. I suspect the some internal registers or kernel data structures are not finished being cleaned up and the second stop does not allow this to complete. -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 01/10] arch:powerpc: return -ENOMEM on failed allocation
On Wed, 2017-09-13 at 13:02 +0530, Allen Pais wrote:
> Signed-off-by: Allen Pais
I think the changelog for this series of conversions
should show that you've validated the change by
inspecting the return call chain at each modified line.
Also, it seems you've cc'd the same mailing lists for
all of the patches modified by this series.
It would be better to individually address each patch
in the series only cc'ing the appropriate maintainers
and mailing lists.
A cover letter would be good too.
> ---
> arch/powerpc/platforms/cell/spider-pci.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/platforms/cell/spider-pci.c
> b/arch/powerpc/platforms/cell/spider-pci.c
> index d1e61e2..82aa3f7 100644
> --- a/arch/powerpc/platforms/cell/spider-pci.c
> +++ b/arch/powerpc/platforms/cell/spider-pci.c
> @@ -106,7 +106,7 @@ static int __init spiderpci_pci_setup_chip(struct
> pci_controller *phb,
> dummy_page_va = kmalloc(PAGE_SIZE, GFP_KERNEL);
> if (!dummy_page_va) {
> pr_err("SPIDERPCI-IOWA:Alloc dummy_page_va failed.\n");
> - return -1;
> + return -ENOMEM;
> }
>
> dummy_page_da = dma_map_single(phb->parent, dummy_page_va,
> @@ -137,7 +137,7 @@ int __init spiderpci_iowa_init(struct iowa_bus *bus, void
> *data)
> if (!priv) {
> pr_err("SPIDERPCI-IOWA:"
> "Can't allocate struct spiderpci_iowa_private");
> - return -1;
> + return -ENOMEM;
> }
>
> if (of_address_to_resource(np, 0, &r)) {
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Nouveau: kernel hang on Optimus+Intel+NVidia GeForce 1060m
Hi, the system fails to initialize your vbios using secureboot (i had a rare chance to on my system to witness it again), for now i traced it to acr_boot_falcon() in "linux/drivers/gpu/drm/nouveau/nvkm/falcon/msgqueue_0148cdec.c" where it throws -110 which is -ETIMEDOUT. You could try to increase the timeout and see if it helps something, similar to the following: diff --git a/drivers/gpu/drm/nouveau/nvkm/falcon/msgqueue.c b/drivers/gpu/drm/nouveau/nvkm/falcon/msgqueue.c index 77273b53672c..fc0cb187d80d 100644 --- a/drivers/gpu/drm/nouveau/nvkm/falcon/msgqueue.c +++ b/drivers/gpu/drm/nouveau/nvkm/falcon/msgqueue.c @@ -326,7 +326,7 @@ nvkm_msgqueue_post(struct nvkm_msgqueue *priv, enum msgqueue_msg_priority prio, int ret; if (wait_init && !wait_for_completion_timeout(&priv->init_done, - msecs_to_jiffies(1000))) + msecs_to_jiffies(5000))) return -ETIMEDOUT; queue = priv->func->cmd_queue(priv, prio); diff --git a/drivers/gpu/drm/nouveau/nvkm/falcon/msgqueue_0137c63d.c b/drivers/gpu/drm/nouveau/nvkm/falcon/msgqueue_0137c63d.c index fec0273158f6..c2ae525a0780 100644 --- a/drivers/gpu/drm/nouveau/nvkm/falcon/msgqueue_0137c63d.c +++ b/drivers/gpu/drm/nouveau/nvkm/falcon/msgqueue_0137c63d.c @@ -279,6 +279,7 @@ acr_boot_falcon(struct nvkm_msgqueue *priv, enum nvkm_secboot_falcon falcon) u32 flags; u32 falcon_id; } cmd; + const struct nvkm_subdev *subdev = priv->falcon->owner; memset(&cmd, 0, sizeof(cmd)); @@ -290,7 +291,8 @@ acr_boot_falcon(struct nvkm_msgqueue *priv, enum nvkm_secboot_falcon falcon) nvkm_msgqueue_post(priv, MSGQUEUE_MSG_PRIORITY_HIGH, &cmd.hdr, acr_boot_falcon_callback, &completed, true); - if (!wait_for_completion_timeout(&completed, msecs_to_jiffies(1000))) + nvkm_error(subdev, "waiting for timeout in acr_boot_falcon (msgqueue_0137bca5)\n"); + if (!wait_for_completion_timeout(&completed, msecs_to_jiffies(5000))) return -ETIMEDOUT; return 0; On 9/13/17 11:37 AM, Nicolas Mercier wrote: > I am still looking for a solution. I have hacked around in the code > and found out the following: > - Nouveau prefers using PCIE power managemet over ACPI Optimus calls. > I tried to force it to use Optimus ACPI calls, but there was an error > calling the ACPI method so it bails out and uses PCIE PM anyway. > - I tried to debug the PCIE pm states which internally uses ACPI to > turn power on/off. I could print different statuses here and there. > When the power is switched off, ACPI calls turn the power off then the > kernel successfully puts the device in state D3Cold (also turning off > power to the PCI Express port). When waking up, ACPI turns the power > on, apparently successfully (Device [PEGP] transitioned to D0). But a > read from the PCI bus to get the power state & other flags return > 65535 (~0) and the kernel fails to set the device in D0 (although ACPI > claims it is in D0) > The call to pci_raw_set_power_state (in drivers/pci/pci.c) seems to > fail because pci_read_config_word returns "~0" (and does not return > any error code) > > I have tried different things; if I use pcie_port_pm=off, the NVidia > card goes to state D3Hot (if I am not mistaken, its PCIE port is still > powered) but that did not fix it. I tried to turn on or off different > PCI/PCIexpress features such as hotplug, PM and so on. The only thing > that works is that PM is fully disabled, which equals to the device > not being powered off, so that would be equivalent to nouveau.runpm=0, > which is not helping a lot. I have tried to force pcie aspm by > recompiling the ACPI table, still no luck. > > I am still taking a look, but it seems like the problem comes from the > PCIExpress PM functions and ACPI, not directly from Nouveau > > /n ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Nouveau: kernel hang on Optimus+Intel+NVidia GeForce 1060m
I am still looking for a solution. I have hacked around in the code and found out the following: - Nouveau prefers using PCIE power managemet over ACPI Optimus calls. I tried to force it to use Optimus ACPI calls, but there was an error calling the ACPI method so it bails out and uses PCIE PM anyway. - I tried to debug the PCIE pm states which internally uses ACPI to turn power on/off. I could print different statuses here and there. When the power is switched off, ACPI calls turn the power off then the kernel successfully puts the device in state D3Cold (also turning off power to the PCI Express port). When waking up, ACPI turns the power on, apparently successfully (Device [PEGP] transitioned to D0). But a read from the PCI bus to get the power state & other flags return 65535 (~0) and the kernel fails to set the device in D0 (although ACPI claims it is in D0) The call to pci_raw_set_power_state (in drivers/pci/pci.c) seems to fail because pci_read_config_word returns "~0" (and does not return any error code) I have tried different things; if I use pcie_port_pm=off, the NVidia card goes to state D3Hot (if I am not mistaken, its PCIE port is still powered) but that did not fix it. I tried to turn on or off different PCI/PCIexpress features such as hotplug, PM and so on. The only thing that works is that PM is fully disabled, which equals to the device not being powered off, so that would be equivalent to nouveau.runpm=0, which is not helping a lot. I have tried to force pcie aspm by recompiling the ACPI table, still no luck. I am still taking a look, but it seems like the problem comes from the PCIExpress PM functions and ACPI, not directly from Nouveau /n ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
