Hi Ben,
Since 3.19 the NV BIOS can no longer be loaded via ACPI. This breaks my HP
laptop.
Looking at the recent changes (ad4a3626 split out shadow methods) in the bios
shadow code, I think
this happens:
- nvbios_shadow loops over all possible bios sources
- shadow_method
- shadow_score
- shad
Hi Ben,
Since 3.19 the NV BIOS can no longer be loaded via ACPI. This breaks my HP
laptop.
Looking at the recent changes (ad4a3626 split out shadow methods) in the bios
shadow code, I think
this happens:
- nvbios_shadow loops over all possible bios sources
- shadow_method
- shadow_score
- shad
On 19.09.2014 19:01, Ilia Mirkin wrote:
> Try booting with log_buf_len=100M
Done and the slightly lengthy files attached to the Bugzilla entry.
Ortwin
On 09/19/2014 07:01 PM, Ilia Mirkin wrote:
> Thanks! Hopefully you still have those kernels handy, as your logs got
> cut off.
Yeah, I noticed and hoped it wouldn't matter as it is mostly the boot log
that's
been cut off until syslog came up (it's from /var/log/messages). So
suspend/resume cycl
On 19.09.2014 17:58, Ilia Mirkin wrote:
> git checkout 415f12efc1b2308411b2cbc3e82666b3db8a7758^
Thanks again. I confirm that Bugzilla 83550 is the same issue. I have attached
the captured logs
there for reference.
Ortwin
On 18.09.2014 16:58, Ilia Mirkin wrote:
> This has been reported a few times already -- probably the same thing
> as bug https://bugs.freedesktop.org/show_bug.cgi?id=83550
Ah, thanks. I would like to try with that commit reverted, but unfortunately it
no longer reverts
cleanly, and my attempts
I have tried and reverted these commits but to no avail.
028791bb7d6 drm/nouveau/kms: restore fbcon after display has been resumed
456b0579fb0 drm/nouveau: use connector events for HPD instead of GPIO watching
Hi,
Since 3.16 an external monitor stays dark after resume from sleep. I didn't
manage to activate it
again with xrand. According to xrandr it is "connected" and configured with a
mode, but I get no signal.
Happens since 3.16 and is still broken with 3.17-rc5.
Hardware:
HP EliteBook 8540w
01:0
This is a regression towards 3.6. Occurs when starting X.
I had already reported this before -rc1 and -rc2, on 10. and 16. October.
This is with noaccel=1. Without the option, the machine hangs on a black
screen as soon as X starts up (which has always been like that).
Tell me if you need more
This is a regression towards 3.6. Occurs when starting X.
I had already reported this before -rc1, but nobody listened.
-- next part --
Oct 16 18:27:04 localhost kernel: Initializing cgroup subsys cpu
Oct 16 18:27:04 localhost kernel: Linux version 3.7.0-rc1 (root at ortwi
Hi,
Current nouveau code in Linus' tree oopses with noaccel. Didn't happen
in 3.6. Full dmesg attached.
Ortwin
BUG: unable to handle kernel NULL pointer dereference at 0018
Oct 10 18:05:49 localhost kernel: IP: []
nouveau_channel_new+0x41e/0x670
Oct 10 18:05:49 localhost kernel: PG
Work around a crash during boot if noaccel is set.
NB: still broken in 3.5 as well, used to work in 3.4. Why are people
ignoring this? It's a regression!
Signed-off-by: Ortwin Glück
---
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c
b/drivers/gpu/drm/nouveau/nv50_display.c
Work around a crash during boot if noaccel is set.
NB: still broken in 3.5 as well, used to work in 3.4. Why are people
ignoring this? It's a regression!
Signed-off-by: Ortwin Gl?ck
---
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c
b/drivers/gpu/drm/nouveau/nv50_display.c
index b244d99..
NB: still broken in 3.5 as well.
Signed-off-by: Ortwin Gl?ck
---
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c
b/drivers/gpu/drm/nouveau/nv50_display.c
index b244d99..c7ffa63 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -650,6 +650,12
NB: still broken in 3.5 as well.
Signed-off-by: Ortwin Glück
---
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c
b/drivers/gpu/drm/nouveau/nv50_display.c
index b244d99..c7ffa63 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -650,6
I have managed to turn the crash into a WARN_ON, by adding this to the
begin of nouveau_software_vblank():
if (!psw) {
WARN_ON(1);
return;
}
And I have also managed to load the module manually instead by udev. So
I am happy to attach a full lo
On 30.07.2012 19:16, Marcin Slusarz wrote:
> Are you sure you boot the correct kernel? I'm asking because your panic says
> its
> version is "3.5.0 #3" - exactly the same as in previous crash log.
I am using the correct kernel, don't worry. (.version may not be
incremented on each build necessar
Yes, as far as I can tell. I didn't do anything different this time. The date
on the kernel file looks ok. Just did a fresh make && make install again, and
got the same behaviour. When is that number after the hash sign upped?
Marcin Slusarz wrote:
>Are you sure you boot the correct kernel? I
Yes, as far as I can tell. I didn't do anything different this time. The date
on the kernel file looks ok. Just did a fresh make && make install again, and
got the same behaviour. When is that number after the hash sign upped?
Marcin Slusarz wrote:
>Are you sure you boot the correct kernel? I
On 29.07.2012 22:15, Marcin Slusarz wrote:
No, the real problem is: with "noaccel" we don't register "software engine",
but vblank ISR relies on its existance and happily derefences NULL pointer.
Now, this patch should fix it for real...
Unfortunately I am still seeing the crash. Without "noac
On 29.07.2012 22:15, Marcin Slusarz wrote:
> No, the real problem is: with "noaccel" we don't register "software engine",
> but vblank ISR relies on its existance and happily derefences NULL pointer.
>
> Now, this patch should fix it for real...
Unfortunately I am still seeing the crash. Without "
On 25.07.2012 20:42, Marcin Slusarz wrote:
Good, below patch should fix this panic.
Note that you can hit an oops in drm_handle_vblank because patch from
http://lists.freedesktop.org/archives/dri-devel/2012-May/023498.html
has not been applied (yet?).
After applying your patch, it still crashe
On 25.07.2012 20:42, Marcin Slusarz wrote:
> Good, below patch should fix this panic.
>
> Note that you can hit an oops in drm_handle_vblank because patch from
> http://lists.freedesktop.org/archives/dri-devel/2012-May/023498.html
> has not been applied (yet?).
After applying your patch, it still
Does it work if you boot without X and modprobe nouveau manually? If it does,
can you disable page flipping in xorg.conf (Option "PageFlip" "0" in nouveau
device section) and recheck with X?
It happens long before X, when the nouveau module is loaded.
Does it work if you disable acceleration (
On 24.07.2012 19:00, Marcin Slusarz wrote:
Please post the crash log.
Sorry, I was not precise: it boots until drm performs modesetting (so it
seems). The screen goes black and the machine is dead. So there is
nothing I could post here, unfortunately.
This is a video of 3.5 booting:
http://
> Does it work if you boot without X and modprobe nouveau manually? If it does,
> can you disable page flipping in xorg.conf (Option "PageFlip" "0" in nouveau
> device section) and recheck with X?
It happens long before X, when the nouveau module is loaded.
> Does it work if you disable accelerat
On 24.07.2012 19:00, Marcin Slusarz wrote:
> Please post the crash log.
Sorry, I was not precise: it boots until drm performs modesetting (so it
seems). The screen goes black and the machine is dead. So there is
nothing I could post here, unfortunately.
This is a video of 3.5 booting:
http://ww
Hi,
My HP Elitebook 8540w now crashes on boot with 3.5. All works fine with
3.4. Bisected to the following commit:
20abd1634a6e2eedb84ca977adea56b8aa06cc3e is the first bad commit
commit 20abd1634a6e2eedb84ca977adea56b8aa06cc3e
Author: Ben Skeggs
Date: Mon Apr 30 11:33:43 2012 -0500
dr
Hi,
My HP Elitebook 8540w now crashes on boot with 3.5. All works fine with
3.4. Bisected to the following commit:
20abd1634a6e2eedb84ca977adea56b8aa06cc3e is the first bad commit
commit 20abd1634a6e2eedb84ca977adea56b8aa06cc3e
Author: Ben Skeggs
Date: Mon Apr 30 11:33:43 2012 -0500
drm
I am seeing this on a 4670 M96XT RV730 (iMac 11,2) with 2.6.37-rc5
[drm:radeon_process_aux_ch] *ERROR* Buffer to small for return answer 1 16
[drm] Initialized drm 1.1.0 20060810
[drm] radeon defaulting to kernel modesetting.
[drm] radeon kernel modesetting enabled.
[drm] initializing kernel mod
I am seeing this on a 4670 M96XT RV730 (iMac 11,2) with 2.6.37-rc5
[drm:radeon_process_aux_ch] *ERROR* Buffer to small for return answer 1 16
[drm] Initialized drm 1.1.0 20060810
[drm] radeon defaulting to kernel modesetting.
[drm] radeon kernel modesetting enabled.
[drm] initializing kernel mod
31 matches
Mail list logo
