SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
And Eric, have you gotten ZFS to work like you did LVM, LUKS, etc? If you have, please share. The lack of people willing to share information about getting things working, especially with a ZFS root on GNU/Linux, and working properly is long overdue for an end.
Each boot attempt I've attempted only ended with a kernel panic or an unreadable file system regardless of bootloader. Init be damned if the filesystem isn't readable by whatever means, so do share.
No, I do not use ZFS (or btrfs) but in Freenode's ##slackware channel there are several people working on this, and I asked them to publish their documentation once they have an initrd that allows booting with ZFS, which they agreed to.
The docs.slackware.com server should be the place to document that.
Sounds good. It would be nice to know why ZFS built into the kernel along with SPL still generate a non-bootable partition. It works fine mounted after the fact if you use it as a standard data partition. Oh well.
However, on another note glad to see new updates yet again. The new Mesa extensions are really nice and have really brought my GeForce 9800 GT up to par driverwise with the 340 series legacy driver from Nvidia.
Does anyone with AMD GPU or Kaveri APU has any issue with the new LLVM 3.7 and new mesa?
I didn't try the new mesa and compiled a git version instead but this hangs as soon as X starts. Reverting to my older working mesa (and appropriate libdrm and xfree86 driver) allow X to start but plasma crashes. Only reverting to old llvm and mesa allowed me to come back to a working desktop.
Of course, there may be several reasons besides the current updates, but I'd like to know if someone has it worling on AMD GPU for trying again and going deeper.
Does anyone with AMD GPU or Kaveri APU has any issue with the new LLVM 3.7 and new mesa?
I didn't try the new mesa and compiled a git version instead but this hangs as soon as X starts. Reverting to my older working mesa (and appropriate libdrm and xfree86 driver) allow X to start but plasma crashes. Only reverting to old llvm and mesa allowed me to come back to a working desktop.
Of course, there may be several reasons besides the current updates, but I'd like to know if someone has it worling on AMD GPU for trying again and going deeper.
I would suggest that you try using exclusively packages provided in Slackware current instead of custom ones so we be sure that the issue really occurs with these packages. It is possible that this issue (as any other) occurs only with some specific models of these brands.
Last edited by Didier Spaier; 09-16-2015 at 12:45 PM.
Does anyone with AMD GPU or Kaveri APU has any issue with the new LLVM 3.7 and new mesa?
I didn't try the new mesa and compiled a git version instead but this hangs as soon as X starts. Reverting to my older working mesa (and appropriate libdrm and xfree86 driver) allow X to start but plasma crashes. Only reverting to old llvm and mesa allowed me to come back to a working desktop.
Of course, there may be several reasons besides the current updates, but I'd like to know if someone has it worling on AMD GPU for trying again and going deeper.
I got an richland NI APU A10-5750M (8650G/8670M Dual GPU) and it works for me and glxinfo reports 8670M as OpenGL 4.1
For any AMD CPU, make sure you have the latest kernel, libdrm, llvm/clang, mesa, xf86-video-ati, and kernel-firmware to get the best support. -Current should have these by now.
I would suggest that you try using exclusively packages provided in Slackware current instead of custom ones so we be sure that the issue really occurs with these packages. It is possible that this issue (as any other) occurs only with some specific models of these brands.
I 've been using exclusively git compiled versions of libdrm, mesa, libvdpau, firmware and xfree86-video-ati, as well as self-compiled kernels (currently running 4.2.0) for the last 3 years, usually without issues.
I know that sometimes problems occur with specific brands only, that's why I asked if someone successfully used AMD products with the latest -current updates to see if it seemed widespread or if I had to look into the way I compile my packages that may be inappropriate for LLVM 3.7, for instance.
Nille's answer suggests that -current packages works well with his APU, so I probably need to dig deeper around the options that are used by Pat and see the differences with my own. :-)
It may also be an issue with the 4.2.0 kernel.
Thanks for all your answer, I'll have some time next week to work on that!
I 've been using exclusively git compiled versions of libdrm, mesa, libvdpau, firmware and xfree86-video-ati, as well as self-compiled kernels (currently running 4.2.0) for the last 3 years, usually without issues.
I know that sometimes problems occur with specific brands only, that's why I asked if someone successfully used AMD products with the latest -current updates to see if it seemed widespread or if I had to look into the way I compile my packages that may be inappropriate for LLVM 3.7, for instance.
Nille's answer suggests that -current packages works well with his APU, so I probably need to dig deeper around the options that are used by Pat and see the differences with my own. :-)
It may also be an issue with the 4.2.0 kernel.
Thanks for all your answer, I'll have some time next week to work on that!
Then this thread is not for you, sorry!
There we talk exclusively about, like the thread title say, the desired updates to Slackware-current.
Works something like: we propose updates, Slackware Team eventually consider some of them, adapt, build and test the packages, finally those eventually arrive in current. You see the light?
Last edited by Darth Vader; 09-17-2015 at 09:06 AM.
Slackware-Current only has support for the 4.1.x series of kernels at this time. It has been noted in several topics of various issues with 4.2.x though, so that might answer some questions.
Using git sourced versions of software can be risky, but in general, it's not entirely bad practice to use a git source. There are packages that are only available via git pulls. However, if there are existing packages for a distribution, using those will be advised more due to the fact people will know how those packages behave.
ccache 3.2.3 (3.1.9 on -current)
cdrtools 3.01a31 and now 3.01 final (3.01a24 on -current)
efibootmgr-0.12 + efivar-0.20 (this is a bit intrusive i guess)
ddrescue 1.19 (1.18.1 -on -current)
gnupg2 2.1.8 (this again is a bit intrusive because it works entirely differently than 2.0 branch)
mcelog v124 (1.0pre3 on -current) this decodes more messages and some days ago the v125 version was released with better support for the latest intel cpus.
smartmontools 6.4 (6.3 on -current)
I use the above programs for some time and haven't noticed any bugs but i haven't done any testing of course.
efibootmgr-0.12 + efivar-0.20 (this is a bit intrusive i guess)
Nothing intrusive, but nothing to update either. Actually 0.12 is just a renaming by RH/Fedora and the last entry in RH's Changelog (dated 23 Jan 2013) mentions this patch from Matthew Garrett: efibootmgr-0.5.4-Work-around-broken-Apple-firmware.patch that is already applied in the efibootmgr package shipped in Slackware version 14.1.
Last edited by Didier Spaier; 09-17-2015 at 01:50 PM.
Reason: Typo fix.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
