Problems caused by commit 6803ed69994a14824081adbf1b58fd21a9966215 to 2.6.38-rc5
On Sun, 2011-04-17 at 15:40 -0400, Bob Gleitsmann wrote: > Good day, night, or whatever, Hey, I've pushed a fix for this (solution 2 that you mentioned) to nouveau's git tree. I'll get it to Dave with the next batch of fixes for .39-rc. Ben. > > The above mentioned commit which changed the flags passed to nouveau_gem_new > to > domain creates a problem in nouveau_notifier_init_channel (in > nouveau_notifier.c) when it calls nouveau_bo_pin with the domain flags. That > function seems to want TTM_PL_FLAGs. If this problem is not fixed, notifier > allocation during channel allocation goes awry the kernel thinks that the gpu > is locked up and switches to software fbcon, and X is gone. The solution is > obvious. However, I am not clear on what the original purpose of the patch > was > nor why the TTM placement flags and the NOUVEAU placement flags are reversed > for > GART and VRAM. I'm not saying there isn't a good reason, I just don't know > what it is. The choices are: > 1. Revert the patch > 2. Add code to nouveau_notifier_init_channel to pass the TTM_PL_FLAGS to > nouveau_bo_pin. > 3. Change nouveau_bo_pin so that it accepts the nouveau domain flags, and fix > every place that nouveau_bo_pin is called (not all that many) to give it the > flags it will then expect. > 4. None of the above > > Maybe this is only a problem with earlier cards. I have a 6800 Ultra. It's > hard to believe that no one else noticed it for a month as it's pretty > difficult > to ignore. > > Best Wishes, > > Bob Gleitsmann > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
Problems caused by commit 6803ed69994a14824081adbf1b58fd21a9966215 to 2.6.38-rc5
Good day, night, or whatever, The above mentioned commit which changed the flags passed to nouveau_gem_new to domain creates a problem in nouveau_notifier_init_channel (in nouveau_notifier.c) when it calls nouveau_bo_pin with the domain flags. That function seems to want TTM_PL_FLAGs. If this problem is not fixed, notifier allocation during channel allocation goes awry the kernel thinks that the gpu is locked up and switches to software fbcon, and X is gone. The solution is obvious. However, I am not clear on what the original purpose of the patch was nor why the TTM placement flags and the NOUVEAU placement flags are reversed for GART and VRAM. I'm not saying there isn't a good reason, I just don't know what it is. The choices are: 1. Revert the patch 2. Add code to nouveau_notifier_init_channel to pass the TTM_PL_FLAGS to nouveau_bo_pin. 3. Change nouveau_bo_pin so that it accepts the nouveau domain flags, and fix every place that nouveau_bo_pin is called (not all that many) to give it the flags it will then expect. 4. None of the above Maybe this is only a problem with earlier cards. I have a 6800 Ultra. It's hard to believe that no one else noticed it for a month as it's pretty difficult to ignore. Best Wishes, Bob Gleitsmann
Problems caused by commit 6803ed69994a14824081adbf1b58fd21a9966215 to 2.6.38-rc5
Good day, night, or whatever, The above mentioned commit which changed the flags passed to nouveau_gem_new to domain creates a problem in nouveau_notifier_init_channel (in nouveau_notifier.c) when it calls nouveau_bo_pin with the domain flags. That function seems to want TTM_PL_FLAGs. If this problem is not fixed, notifier allocation during channel allocation goes awry the kernel thinks that the gpu is locked up and switches to software fbcon, and X is gone. The solution is obvious. However, I am not clear on what the original purpose of the patch was nor why the TTM placement flags and the NOUVEAU placement flags are reversed for GART and VRAM. I'm not saying there isn't a good reason, I just don't know what it is. The choices are: 1. Revert the patch 2. Add code to nouveau_notifier_init_channel to pass the TTM_PL_FLAGS to nouveau_bo_pin. 3. Change nouveau_bo_pin so that it accepts the nouveau domain flags, and fix every place that nouveau_bo_pin is called (not all that many) to give it the flags it will then expect. 4. None of the above Maybe this is only a problem with earlier cards. I have a 6800 Ultra. It's hard to believe that no one else noticed it for a month as it's pretty difficult to ignore. Best Wishes, Bob Gleitsmann ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Problems caused by commit 6803ed69994a14824081adbf1b58fd21a9966215 to 2.6.38-rc5
On Sun, 2011-04-17 at 15:40 -0400, Bob Gleitsmann wrote: Good day, night, or whatever, Hey, I've pushed a fix for this (solution 2 that you mentioned) to nouveau's git tree. I'll get it to Dave with the next batch of fixes for .39-rc. Ben. The above mentioned commit which changed the flags passed to nouveau_gem_new to domain creates a problem in nouveau_notifier_init_channel (in nouveau_notifier.c) when it calls nouveau_bo_pin with the domain flags. That function seems to want TTM_PL_FLAGs. If this problem is not fixed, notifier allocation during channel allocation goes awry the kernel thinks that the gpu is locked up and switches to software fbcon, and X is gone. The solution is obvious. However, I am not clear on what the original purpose of the patch was nor why the TTM placement flags and the NOUVEAU placement flags are reversed for GART and VRAM. I'm not saying there isn't a good reason, I just don't know what it is. The choices are: 1. Revert the patch 2. Add code to nouveau_notifier_init_channel to pass the TTM_PL_FLAGS to nouveau_bo_pin. 3. Change nouveau_bo_pin so that it accepts the nouveau domain flags, and fix every place that nouveau_bo_pin is called (not all that many) to give it the flags it will then expect. 4. None of the above Maybe this is only a problem with earlier cards. I have a 6800 Ultra. It's hard to believe that no one else noticed it for a month as it's pretty difficult to ignore. Best Wishes, Bob Gleitsmann ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
