[Bug 95911] Recursive error in radeon device driver module after resume from hibernation

[bugzilla-daemon at bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=95911

--- Comment #15 from gitne at excite.co.jp ---
(In reply to Michel Dänzer from comment #14)
>> Mantas Mikulėnas has determined that git commit 4474f3a91f95 was the last
>> known good to work.
> 
> So commit f2ba57b5eab8817d86d0f108fdf1878e51dc0a37 ("drm/radeon: UVD bringup
> v8") is the first bad one? In that case, I think you should be able to work
> around it by removing the /lib/firmware/radeon/*_uvd.bin files (and
> re-generating the initrd if necessary)

Okay, I have tried it and recreated the initramfs-*.img file with mkinitrd. I
am not sure I have done it correctly because Fedora's documentation on this
matter is rather non-existent and mkinitrd's man page is rather doll, just
mentioning that it uses dracut internally. So, this is the best I can offer.

Anyhow, this measure does not work around this issue either because it causes
the system to hang after a suspend or hibernate command is issued. This may be
due to the fact that I do not have a KAVERI_uvd.bin firmware file. I do not
know if such a file would be required. Or, perhaps it does exist but under a
different name. Maybe something like RV7xx_uvd.bin? Would simply soft-linking
to the adequate file and then recreating the initrd help? I do not know how the
firmware loading mechanism works.

>> It's a pity that actually *users* have to do the digging for this kind of
>> information. Its all there but kernel developers are obviously too tired or
>> too lazy to do actual work after they have spent countless hours bragging
>> about how genius they are in delivering fucked up work.
> 
> Your rudeness makes me highly doubt that you're Japanese, despite your
> e-mail address. Would you like us to respond in kind?

Nobody cares who I am, even if I were from Mars. The point is that this is a
serious bug (even always reproducible) and all I hear at conferences, events,
and in the media is how incredibility genius Linux kernel developers are
supposed to be, but when one offers advice on how to make things better by
making them more user friendly, or when it comes to fixing bugs and really
delivering a quality product that would make a lot more people to switch over
from proprietary software one gets shouted and talked down - or even worse -
gets humiliated by getting called a technical "dump ass" (which of course is
not true). Yes, most kernel developers do really suffer from broken egos, just
like many doctors suffer from the delusion of being a god over life and death.
But, enough said on that.

> We could spend all our time fixing bugs, but then there wouldn't be any
> support for new hardware or features. It's a trade-off. So yes, we do
> need users' help for testing and tracking down bugs.

Yes, I know. However, prioritizing fixing bugs is what makes software great and
foremost usable. There is no replacement for quality in products, whatever they
might be. It is bad enough that the industry prioritizes developing new
features over product support and quality. The open-source community should not
follow down this path either if it is serious about offering a working
alternative.

>> Oh and another "secret" has been revealed: The bug is caused by ring test
>> failures. Wow! Who could have thought of that!
> 
> A ring test failure is a symptom which can be caused by many things.

Yeah, so why do I have the feeling that it isn't adequately addressed?
If hunting down bugs with mean users, at the current state of the kernel is
really such a big problem then maybe the kernel needs a different design that
makes it more user friendly. To be honest, the current design of the kernel is
overly messy (compared to other kernels) and because of this, makes debugging
really difficult. This is a fact. But again, if one dares to mention this then
it is perceived by the responsible like pure blasphemy.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.