Yet another pointless discussion thread...

Talk about anything you feel like talking about. Pull up a soapbox and pontificate to your heart's content. May contain some adult humour or otherwise objectionable content (NSFW). No warez, pr0n or illegal stuff.

Re: another distro: dragora

Postby Head_on_a_Stick » November 6th, 2018, 5:31 pm

cynwulf wrote:Your continual references to "evil licences" isn't clever.

It's just a joke, pinhead.

cynwulf wrote:https://packages.debian.org/stretch/firmware-amd-graphics

^ That's a firmware package, did you link that by mistake?

AMD graphics cards require a kernel driver and a DDX driver (as well as the firmware), the xserver-xorg-video-amdgpu package is the DDX driver and it is AMD's new, open source replacement for the old "fglrx" proprietary DDX driver.

There is a proprietary amdgpu-pro driver but the open source version outperforms it in every respect, at least according to Phoronix.

cynwulf wrote:you fail to differentiate between device microcode and a proprietary BLOB in the form of a LKM

I know the difference thanks, I'd rather not have any of them.
Show Off
User avatar
Head_on_a_Stick
 
Posts: 163
Joined: June 16th, 2015, 8:35 pm
Location: London baby!

Re: another distro: dragora

Postby Head_on_a_Stick » November 6th, 2018, 5:42 pm

cynwulf wrote:you have not mentioned at all, as to whether you've attempted to simply disable SMT in the BIOS/(U)EFI?

Well, I thought it was pretty obvious that my machine does not have a setting in the firmware ("BIOS") to disable SMT, why would I have gone to all that trouble otherwise? :?

cynwulf wrote:Surely this is the best and first suggestion?

Again, I was crediting the members of forums.debian.net with a modicum of common sense and so presumed that they would immediately read the link I provided to the actual security announcement:
My link wrote:## Fix

Disable SMT/Hyper-Threading in the bios

Not to mention my reference to Theo's post that contains the same advice.

cynwulf wrote:no decent excuse to post a typically overly complex systemd specific solution

It seems that your reading comprehension isn't quite what it should be:
I wrote:The good folks over at the ArchLabs forums have reported that my udev rules don't work very well.

http://forums.debian.net/viewtopic.php?p=684319#p684319

The systemd method also gives logging coverage and allows for the hyperthreading to be enabled again if needed, see my latest version:

http://forums.debian.net/viewtopic.php?p=684372#p684372

cynwulf wrote:Just manually disabling odd numbered cores, as I've also seen suggested on various sites, seems like a poor solution

Yes, I agree, it's hacky as hell but the `lscpu --extended` output on my box now shows only one thread per physical core so I'm happy :)
Show Off
User avatar
Head_on_a_Stick
 
Posts: 163
Joined: June 16th, 2015, 8:35 pm
Location: London baby!

Re: another distro: dragora

Postby cynwulf » November 7th, 2018, 9:42 am

Head_on_a_Stick wrote:^ That's a firmware package, did you link that by mistake?

Did you do any research or do you simply regurgitate tech press oversimplifications? Does it do any acceleration at all without the firmware? Is the firmware closed or open source? What do you think the firmware is? What is the "driver", what do you think the kernel module consists of? Are they, in open sourcing the kernel module - i.e. the bit which is exposed to the GPL licenced kernel/ABI - really open sourcing anything of value? Does it use mesa/dri like the ati/radeon DRM drivers did or a proprietary closed source libgl like fglrx?

Again: "Do you seriously believe that the likes of AMD would open source their proprietary core technologies...?"

To put it another way: do you seriously believe that AMD would expose that IP, developed over the last three decades, to the likes of Nvidia and Intel?

Let me know when the open source AMD Windows/Direct3D API drivers appear and then you can proclaim that "AMD have gone open source", (along with MS. At that point, look out for flying pigs...)

Regarding your SMT thread - no it's not obvious. "To disable SMT in Debian, we need to apply a udev rule", is a specific statement and presented by you as the one and only means to disable SMT. You make no references to disabling in the BIOS. Therefore we can only conclude that it hadn't occurred to you that it could be disabled in the BIOS.

Most users will have a BIOS off switch, so won't need to go through that hassle. If not, for newer supported hardware a BIOS update should make the option available (as a security fix), then finally if there's no other option, manually disabling the virtual SMT cores ("threads") is where you're at.

At this point there is clearly "no need for further discussion". Have fun, etc...
cynwulf
 
Posts: 2548
Joined: April 26th, 2011, 2:46 pm

Re: another distro: dragora

Postby Head_on_a_Stick » November 7th, 2018, 7:10 pm

cynwulf wrote:Does it do any acceleration at all without the firmware? Is the firmware closed or open source? What do you think the firmware is?

AMD graphics cards have never offered acceleration without firmware, no.

Yes, the firmware is closed source, as it always has been.

And yes, I know what firmware is :)

I wasn't referring to the firmware because that situation has not changed, nor is it likely to. Sadly, Intel now also require non-free firmware for their cards.

cynwulf wrote:What is the "driver", what do you think the kernel module consists of?

OK, let me try again, perhaps you will learn something...

The Linux video stack for AMD cards consists of three components: the kernel driver (which is and always has been open sourced), the DDX driver (responsible for 2D graphics acceleration) and the Mesa stuff (for 3D graphics).

In the past the choices for the DDX driver were either xserver-xorg-video-ati or "fglrx", which was AMD's proprietary DDX driver.

Now the choice is either xserver-xorg-video-amdgpu or the proprietary amdgpu-pro driver — phoronix.com have tested both and xserver-xorg-video-amdgpu performs better; AMD update the pro version very rarely.

cynwulf wrote:Does it use mesa/dri like the ati/radeon DRM drivers did or a proprietary closed source libgl like fglrx?

The xserver-xorg-video-amdgpu driver integrates with the rest of the open stack, yes.

cynwulf wrote:Regarding your SMT thread - no it's not obvious.

Yes, you're probably right, I've copy&pasted the n00b version of my guide from the ArchLabs forums.

Thanks for the feedback!
Show Off
User avatar
Head_on_a_Stick
 
Posts: 163
Joined: June 16th, 2015, 8:35 pm
Location: London baby!

Re: Yet another pointless discussion thread...

Postby nodir » November 7th, 2018, 7:28 pm

I can offer feedback too: if you want to install a backports kernel on newer hardware which doesn't work with debian stable, how is that supposed to work?
nodir
 
Posts: 307
Joined: June 16th, 2015, 10:10 pm

Re: Yet another pointless discussion thread...

Postby Head_on_a_Stick » November 7th, 2018, 7:47 pm

nodir wrote:if you want to install a backports kernel on newer hardware which doesn't work with debian stable, how is that supposed to work?

Well it worked just fine for the *many* users who have followed that guide in the past (I have had versions of it on other forums and received very positive feedback).

Why do you think my guide will not work? Is there a mistake?
Show Off
User avatar
Head_on_a_Stick
 
Posts: 163
Joined: June 16th, 2015, 8:35 pm
Location: London baby!

Re: Yet another pointless discussion thread...

Postby nodir » November 7th, 2018, 9:20 pm

I mean it like this:
a) I buy my shiny new hardware.
b) i download the debian stable iso and start to install
c) the old debian kernel can't boot my shiny new hardware.
How would i install a backports kernel, if i can't install debian stable in the first place ?
nodir
 
Posts: 307
Joined: June 16th, 2015, 10:10 pm

Re: Yet another pointless discussion thread...

Postby Head_on_a_Stick » November 7th, 2018, 10:10 pm

nodir wrote:the old debian kernel can't boot my shiny new hardware.
How would i install a backports kernel, if i can't install debian stable in the first place ?

Boot up a recent Arch Linux ISO image (that does support the hardware) and install the system using this guide:

https://www.debian.org/releases/stretch ... 03.html.en

Just add the backports repository and install the kernel from the chroot, exactly as described in my guide, and the system should then reboot successfully.

But yes, my guide wouldn't work directly in such a case.

In many cases though the new hardware will install & boot successfully but the support will be sub-optimal and flaky — it is for these users that my guide is primarily intended.
Show Off
User avatar
Head_on_a_Stick
 
Posts: 163
Joined: June 16th, 2015, 8:35 pm
Location: London baby!

Re: Yet another pointless discussion thread...

Postby nodir » November 7th, 2018, 11:42 pm

I have to use arch to do that?

And i got that right: your guide mainly describes how to use stable-backports? Sounds a bit too advanced for a forum like debian.net, but hey, perhaps you will inspire some.
nodir
 
Posts: 307
Joined: June 16th, 2015, 10:10 pm

Re: Yet another pointless discussion thread...

Postby Head_on_a_Stick » November 8th, 2018, 6:43 am

nodir wrote:I have to use arch to do that?

No, not at all, any "live" GNU/Linux distribution with a recent enough kernel will do :)

I recommended Arch because the ISO includes the excellent arch-chroot helper script, which automates the chroot setup stage.
Show Off
User avatar
Head_on_a_Stick
 
Posts: 163
Joined: June 16th, 2015, 8:35 pm
Location: London baby!

PreviousNext

Return to Nonsense

Who is online

Users browsing this forum: No registered users and 1 guest

x