But at the time the mesa3d file
src/gallium/drivers/nouveau/nv30/nv30_screen.c
is called and when the various PUSH_DATA begin to be called there is not yet
a call to nouveau_pushbuf_space. So it would generate a seg fault in
push->curr. Again, sorry for the confusion and thanks for the reply.
See libdrm's pushbuf.c -- iirc push->cur points to a GART-mapped bo.
http://cgit.freedesktop.org/mesa/drm/tree/nouveau/pushbuf.c#n682
nouveau_pushbuf_data(push, NULL, 0, 0);
nouveau_bo_ref(bo, >bo);
nouveau_bo_ref(NULL, );
nvpb->bgn = nvpb->bo->map;
nvpb->ptr = nvpb->bgn;
push->cur = nvpb->bgn;
SORRY SORRY SORRY :)
Thanks for the consideration.
2015-11-02 15:42 GMT-03:00 Ilia Mirkin :
> E are you sure?
>
> nv30_screen_create starts with a bunch of stuff init'ing objects, and then
> does:
>
>BEGIN_NV04(push, NV01_SUBC(3D, OBJECT), 1);
>PUSH_DATA
E are you sure?
nv30_screen_create starts with a bunch of stuff init'ing objects, and then does:
BEGIN_NV04(push, NV01_SUBC(3D, OBJECT), 1);
PUSH_DATA (push, screen->eng3d->handle);
And as you can see in nv30_winsys.h:
static inline void
BEGIN_NV04(struct nouveau_pushbuf *push,
https://bugs.freedesktop.org/show_bug.cgi?id=90626
--- Comment #20 from Ilia Mirkin ---
(In reply to René from comment #18)
> (In reply to Ilia Mirkin from comment #17)
> > Could one of you post an acpidump from the laptop? Specifically interested
> > in how the _ROM method
https://bugs.freedesktop.org/show_bug.cgi?id=90626
--- Comment #18 from René ---
(In reply to Ilia Mirkin from comment #17)
> Could one of you post an acpidump from the laptop? Specifically interested
> in how the _ROM method is defined.
I can do that. Just two questions:
https://bugs.freedesktop.org/show_bug.cgi?id=90626
--- Comment #22 from René ---
Created attachment 119334
--> https://bugs.freedesktop.org/attachment.cgi?id=119334=edit
acpidump (HP ZBook 15, nVidia GK208GLM [Quadro K610M], BIOS v31/03/2015)
Ok, here you are. There is
https://bugs.freedesktop.org/show_bug.cgi?id=90626
--- Comment #19 from Ortwin Glück ---
Created attachment 119333
--> https://bugs.freedesktop.org/attachment.cgi?id=119333=edit
acpidump -b
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=90626
--- Comment #21 from Ilia Mirkin ---
(In reply to Ortwin Glück from comment #19)
> Created attachment 119333 [details]
> acpidump -b
Sorry, I don't know what to do this. Can you get me the output without -b?
These
https://bugs.freedesktop.org/show_bug.cgi?id=90626
Ortwin Glück changed:
What|Removed |Added
Attachment #119333|0 |1
is obsolete|
Hi, sorry if I misunderstood everything...
In the file src/gallium/drivers/nouveau/nv30/nv30_screen.c there is loans of
PUSH_DATA which is basically *push->curr = data;
I'm thinking that somehow push->curr is the bo->map = drm_mmap(...)
that is called in nouveau_bo_map. But I cannot see how they
https://bugs.freedesktop.org/show_bug.cgi?id=90626
--- Comment #24 from Ilia Mirkin ---
Looks like this bios hard-codes a 4K return size for each bios chunk fetch.
There is a "fast" and a "slow" method in nouveau... the fast one grabs it all
in one go, while the "slow" one
https://bugs.freedesktop.org/show_bug.cgi?id=90626
--- Comment #27 from René Krell ---
(In reply to Ilia Mirkin from comment #26)
> FTR, the _ROM function from both dumps (same thing):
> ...
> 0x00
>
https://bugs.freedesktop.org/show_bug.cgi?id=70354
--- Comment #81 from Julien Isorce ---
Hi, here is the output of: sudo lspci -nnv -d 10de:0fe4
01:00.0 3D controller [0302]: NVIDIA Corporation GK107M [GeForce GT 750M]
[10de:0fe4] (rev a1)
Subsystem: Samsung
https://bugs.freedesktop.org/show_bug.cgi?id=90626
--- Comment #30 from Ilia Mirkin ---
(In reply to Ilia Mirkin from comment #28)
> (In reply to René Krell from comment #27)
> > (In reply to Ilia Mirkin from comment #26)
> > > FTR, the _ROM function from both dumps (same
https://bugs.freedesktop.org/show_bug.cgi?id=90626
--- Comment #33 from Ortwin Glück ---
(In reply to Ilia Mirkin from comment #32)
> nouveau.config=War00C800_0=1
Doesn't help, but don't worry now - different issue.
> The old code was able to make the fallback just fine,
https://bugs.freedesktop.org/show_bug.cgi?id=90626
--- Comment #28 from Ilia Mirkin ---
(In reply to René Krell from comment #27)
> (In reply to Ilia Mirkin from comment #26)
> > FTR, the _ROM function from both dumps (same thing):
> > ...
> >
https://bugs.freedesktop.org/show_bug.cgi?id=90626
--- Comment #29 from René Krell ---
(In reply to Ilia Mirkin from comment #28)
> ... Feel free to give your contact at HP a call :)
I will refer to this issue to not spread rumours :-)
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=90626
--- Comment #31 from Ortwin Glück ---
The delays during boot are not caused by the bios shadow code but by this:
[5.878439] nouveau E[ PGRAPH][:01:00.0] wait for idle timeout (en: 1,
ctxsw: 0, busy: 1)
[7.877714]
https://bugs.freedesktop.org/show_bug.cgi?id=90626
--- Comment #25 from Ortwin Glück ---
Yes that fixes it for me. Tested with 4.3.0-rc6.
The slow version really is slower and causes a noticable delay during booting,
but I don't really mind: work laptop boots only once a day.
--
https://bugs.freedesktop.org/show_bug.cgi?id=90626
--- Comment #26 from Ilia Mirkin ---
FTR, the _ROM function from both dumps (same thing):
Method (_ROM, 2, NotSerialized) // _ROM: Read-Only Memory
{
Local0 += Arg0 = (VRMB (0x04) +
https://bugs.freedesktop.org/show_bug.cgi?id=70354
--- Comment #82 from Ilia Mirkin ---
(In reply to Julien Isorce from comment #81)
> Hi, here is the output of: sudo lspci -nnv -d 10de:0fe4
> 01:00.0 3D controller [0302]: NVIDIA Corporation GK107M [GeForce GT 750M]
>
https://bugs.freedesktop.org/show_bug.cgi?id=90626
--- Comment #32 from Ilia Mirkin ---
(In reply to Ortwin Glück from comment #31)
> The delays during boot are not caused by the bios shadow code but by this:
> [5.878439] nouveau E[ PGRAPH][:01:00.0] wait for idle
https://bugs.freedesktop.org/show_bug.cgi?id=70354
--- Comment #83 from Julien Isorce ---
(In reply to Ilia Mirkin from comment #82)
> You should see the following print:
>
> nvkm_info(>subdev, "hw bug workaround enabled\n");
>
> in your kernel log. You need to be
https://bugs.freedesktop.org/show_bug.cgi?id=72315
--- Comment #7 from hart...@free.fr ---
Hi,
I have a same problem on a recent fedora 22 install.
I can use it but I have many crash when I watch video:
nov. 01 18:56:07 homepc kernel: nouveau E[ PFIFO][:03:00.0] PBDMA0: ch 5
https://bugs.freedesktop.org/show_bug.cgi?id=90626
--- Comment #34 from Ilia Mirkin ---
(In reply to Ortwin Glück from comment #33)
> (In reply to Ilia Mirkin from comment #32)
> > nouveau.config=War00C800_0=1
>
> Doesn't help, but don't worry now - different issue.
26 matches
Mail list logo