Phillip Susi writes:
> And it works, but 6.7-rc5 does not, even though it includes that patch.
> Here's the syslog from the attempt. I'll start bisecting again.
I checked out the patch that got merged upstream and it also fails. I
looked at the two commits, and I see what
Alex Deucher writes:
> Phillip,
>
> Can you test this patch? I was not able to repro the issue on the
> navi2x card I had handy, but I think it should fix it.
I pulled -rc4 and it still had the problem. I applied this patch, and
yes, it fixed it!
Luben Tuikov writes:
> I remember that the problem was really that amdgpu called
> drm_sched_entity_init(),
> in amdgpu_ttm_set_buffer_funcs_status() without actually having initialized
> the scheduler
> used therein. For instance, the code before commit b70438004a14f4, looked
> like this:
>
Alex Deucher writes:
>> In that case those are the already known problems with the scheduler
>> changes, aren't they?
>
> Yes. Those changes went into 6.7 though, not 6.6 AFAIK. Maybe I'm
> misunderstanding what the original report was actually testing. If it
> was 6.7, then try reverting:
> 5
Alex Deucher writes:
> Yes. Those changes went into 6.7 though, not 6.6 AFAIK. Maybe I'm
> misunderstanding what the original report was actually testing. If it
> was 6.7, then try reverting:
> 56e449603f0ac580700621a356d35d5716a62ce5
> b70438004a14f4d0f9890b3297cd66248728546c
I had been runn
Christian König writes:
> Well none of the commits mentioned can affect radeon in any way. Radeon
> simply doesn't use the scheduler.
>
> My suspicion is that the user is actually using amdgpu instead of
> radeon. The switch potentially occurred accidentally, for example by
> compiling amdgpu
Bagas Sanjaya writes:
> Please show the full bisect log, and also tell why these commits are
> skipped.
Two of them would not compile and one would not boot.
Here's the log.
# bad: [4bbdb725a36b0d235f3b832bd0c1e885f0442d9f] Merge tag
'iommu-updates-v6.7' of git://git.kernel.org/pub/scm/linux/
I had been testing some things on a post 6.6-rc5 kernel for a week or
two and then when I pulled to a post 6.6 release kernel, I found that
system suspend was broken. It seems that the radeon driver failed to
suspend, leaving the display dead, the wayland display server hung, and
the system still
Daniel Vetter writes:
> Just a quick comment on this: Since most framebuffers are write-combining,
> and reads from that tend to be ~3 orders of magnitude slower than writes
> (at least on the pile of machines I looked at here, there's big
> differences, and some special streaming cpu instructio
Geert Uytterhoeven writes:
Judging from some of the comments in the code, it looks like you were
one of the original authors of fbcon? I haven't been able to find any
of these sczbot crash reports, and am not sure how fuzzing syscalls
would really affect this code ( it's not really handling a b
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 6/5/2014 10:13 AM, Alex Deucher wrote:
| One of the kcalloc() calls in radeon_cs_parser_relocs() is failing.
Well yea, the question is *why*? I seem to have plenty of free memory.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)
Com
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
While playing minecraft it complains that the kernel rejected CS, see dmesg for
more info. dmesg shows:
[389509.644744] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
[389509.645383] [drm:radeon_cs_ioctl] *ERROR* Failed to parse reloc
On 02/26/2011 03:09 AM, Michel D?nzer wrote:
> On Fre, 2011-02-25 at 12:11 -0500, Phillip Susi wrote:
>>
>> It seems like the GPU is executing a few different microcode kernels
>> that process commands placed into ring buffers. When the ring buffers
>> are empty and the
On 02/26/2011 03:09 AM, Michel Dänzer wrote:
On Fre, 2011-02-25 at 12:11 -0500, Phillip Susi wrote:
It seems like the GPU is executing a few different microcode kernels
that process commands placed into ring buffers. When the ring buffers
are empty and the gui is idle, it seems like the GPU
On 02/25/2011 06:19 PM, Alex Deucher wrote:
> The memory clock is still running at whatever clock it's set to unless
> you manually change it. Things are like displays are constantly being
> fed from vram.
Sure, the master clock is still running, but the dac only reads from the
frame buffer so f
On 02/25/2011 03:56 PM, Dave Airlie wrote:
> So you made an assumpution you knew how graphics cards worked and
> derived a theory, unfortunately the assumption was wrong.
How so? After studying the R600 documentation I found, it sounds like
whatever microcode is in that firmware image is constan
On 02/25/2011 03:38 PM, Alex Deucher wrote:
> The CP firmware has nothing to do with the temperature. The CP
> firmware is just a packet parser for reading in command buffers and
> programming the register backbone. Just alike a CPU, the GPU runs at
> whatever speed it's clock is set to. You can
On 2/25/2011 3:03 PM, Dave Airlie wrote:
> How do you know its running in an infinite loop?
Because the gpu temperature is rising to over 80 C, so it is busy doing
something. And this is booting with init=/bin/bash, so NOTHING is
running that could be keeping it busy.
I had been under the impres
On 02/25/2011 06:19 PM, Alex Deucher wrote:
The memory clock is still running at whatever clock it's set to unless
you manually change it. Things are like displays are constantly being
fed from vram.
Sure, the master clock is still running, but the dac only reads from the
frame buffer so fast
On 02/25/2011 03:56 PM, Dave Airlie wrote:
So you made an assumpution you knew how graphics cards worked and
derived a theory, unfortunately the assumption was wrong.
How so? After studying the R600 documentation I found, it sounds like
whatever microcode is in that firmware image is constant
On 02/25/2011 03:38 PM, Alex Deucher wrote:
The CP firmware has nothing to do with the temperature. The CP
firmware is just a packet parser for reading in command buffers and
programming the register backbone. Just alike a CPU, the GPU runs at
whatever speed it's clock is set to. You can manua
On 2/25/2011 3:03 PM, Dave Airlie wrote:
> How do you know its running in an infinite loop?
Because the gpu temperature is rising to over 80 C, so it is busy doing
something. And this is booting with init=/bin/bash, so NOTHING is
running that could be keeping it busy.
I had been under the impres
So I have been looking over the source code in drivers/gpu/drm/radeon.
I see various functions to start/stop/resume/initialize "mc" and "cp".
I assume those stand for microcode and control program? What exactly is
the difference?
It seems like the GPU is executing a few different microcode kernel
On 2/24/2011 6:03 PM, Jerome Glisse wrote:
> We don't have source of firmware, only nouveau is reverse engineering
> the nvidia one.
Then where does the firmware come from? I've been glancing at the AMD
documentation for the R600 and I'd like to figure out why the firmware
seems to be running in
So I have been looking over the source code in drivers/gpu/drm/radeon.
I see various functions to start/stop/resume/initialize "mc" and "cp".
I assume those stand for microcode and control program? What exactly is
the difference?
It seems like the GPU is executing a few different microcode kernel
On 2/24/2011 6:03 PM, Jerome Glisse wrote:
> We don't have source of firmware, only nouveau is reverse engineering
> the nvidia one.
Then where does the firmware come from? I've been glancing at the AMD
documentation for the R600 and I'd like to figure out why the firmware
seems to be running in
I'm looking for resources I can read to learn more. I mostly have some
basic questions that are probably in a FAQ or something, so if someone
could point me the right way I'd appreciate it.
Specifically some of the things I have been wondering are:
1) It looks like the firmware is in the kernel
I'm looking for resources I can read to learn more. I mostly have some
basic questions that are probably in a FAQ or something, so if someone
could point me the right way I'd appreciate it.
Specifically some of the things I have been wondering are:
1) It looks like the firmware is in the kernel
28 matches
Mail list logo
