Chunchunmaru_

That's actually an improvement regardless of the license

That's actually an improvement regardless of the license

That's actually an improvement regardless of the license

Another similar program is GreenWithEnvy

https://gitlab.com/leinardi/gwe

Wait... What does it mean it doesn't work?

The DS4 controller had drivers for ages, now what matters here is the way the DS4 controller is grabbed.

By default, evdev should be natively supported (wine games should be using this, as for native games) but steam big picture and RPCS3 have another method called "hidraw" so you should be installing some udev rules manually or either with the steam-devices package

There is no confirmation whether this is GCN or not. In all likelihood it's an overhauled GCN with some big improvements (probably some backported stuff from whatever next gen arch they're working on). Considering the Linux kernel still refers to it as GCN it's probably a much improved GCN. Anandtech also says AMD kept quiet about what kind of beast this is and not mentioning the word GCN at all.

Summary: Looks like there is a bad commit in the Linux 5.1.2 kernel, which in some circumstances issuing a ATA TRIM causes actual data to be discarded instead of deleted blocks.

Looks like Windows 10 is not the only one to get data loss after updates.

So far, it appears the issue happens if:
LUKS+dm_crypt if:(Linux kernel software encryption) A Samsung SSD is used Linux 5.1.2 is used  

It should be noted that this happens only when ATA TRIM is issued, so when the "discard" fstab option is used or the weekly "fstrim" service cron/systemd timer is enabled, or a manual fstrim is issued through CLI.

Ubuntu based distros should not be affected by this as it doesn't use the Linux 5.1 kernel.

Arch Linux/Manjaro users sadly are affected, on Manjaro the fstrim is enabled automatically, while on Arch it has to be issued or configured manually.
I do not know if other distros are affected

Since it's a bug related to the device mapper, this could happen on any filesystem

Mitigation: The best thing you can do is to shut down the system immediately and use another kernel.
You can also try disabling the fstrim timer by issuing this command, but it's not very recommended:
`systemctl disable fstrim.timer` `systemctl stop fstrim.timer` Or if you are an expert, checking in /etc/fstab for the discard parameter (but you are basically screwed up if you have this enabled as it's a continuous trim)
Remember for your SSD health and optimal performance, to re-enable those options once everything is over by just replacing disable with enable, and stop with start.

Source:
https://www.redhat.com/archives/dm-devel/2019-May/msg00084.html
https://bbs.archlinux.org/viewtopic.php?id=246569
https://bugs.archlinux.org/task/62693
https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg87788.html
https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.1-FSTRIM-Bug

*Runs linux on her PS3*

Yeah...They are

Summary: Looks like there is a bad commit in the Linux 5.1.2 kernel, which in some circumstances issuing a ATA TRIM causes actual data to be discarded instead of deleted blocks.

Looks like Windows 10 is not the only one to get data loss after updates.

So far, it appears the issue happens if:
LUKS+dm_crypt if:(Linux kernel software encryption) A Samsung SSD is used Linux 5.1.2 is used  

It should be noted that this happens only when ATA TRIM is issued, so when the "discard" fstab option is used or the weekly "fstrim" service cron/systemd timer is enabled, or a manual fstrim is issued through CLI.

Ubuntu based distros should not be affected by this as it doesn't use the Linux 5.1 kernel.

Arch Linux/Manjaro users sadly are affected, on Manjaro the fstrim is enabled automatically, while on Arch it has to be issued or configured manually.
I do not know if other distros are affected

Since it's a bug related to the device mapper, this could happen on any filesystem

Mitigation: The best thing you can do is to shut down the system immediately and use another kernel.
You can also try disabling the fstrim timer by issuing this command, but it's not very recommended:
`systemctl disable fstrim.timer` `systemctl stop fstrim.timer` Or if you are an expert, checking in /etc/fstab for the discard parameter (but you are basically screwed up if you have this enabled as it's a continuous trim)
Remember for your SSD health and optimal performance, to re-enable those options once everything is over by just replacing disable with enable, and stop with start.

Source:
https://www.redhat.com/archives/dm-devel/2019-May/msg00084.html
https://bbs.archlinux.org/viewtopic.php?id=246569
https://bugs.archlinux.org/task/62693
https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg87788.html
https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.1-FSTRIM-Bug

It's not completely clear at this point, the reporters of those issues look like to have in common only Samsung SSD's + LUKS+LVM encryption, Samsung SSD's are pretty common though...

I miss the times where Torvalds himself roasts people with bad kernel commits...

Summary: Looks like there is a bad commit in the Linux 5.1.2 kernel, which in some circumstances issuing a ATA TRIM causes actual data to be discarded instead of deleted blocks.

Looks like Windows 10 is not the only one to get data loss after updates.

So far, it appears the issue happens if:
LUKS+dm_crypt if:(Linux kernel software encryption) A Samsung SSD is used Linux 5.1.2 is used  

It should be noted that this happens only when ATA TRIM is issued, so when the "discard" fstab option is used or the weekly "fstrim" service cron/systemd timer is enabled, or a manual fstrim is issued through CLI.

Ubuntu based distros should not be affected by this as it doesn't use the Linux 5.1 kernel.

Arch Linux/Manjaro users sadly are affected, on Manjaro the fstrim is enabled automatically, while on Arch it has to be issued or configured manually.
I do not know if other distros are affected

Since it's a bug related to the device mapper, this could happen on any filesystem

Mitigation: The best thing you can do is to shut down the system immediately and use another kernel.
You can also try disabling the fstrim timer by issuing this command, but it's not very recommended:
`systemctl disable fstrim.timer` `systemctl stop fstrim.timer` Or if you are an expert, checking in /etc/fstab for the discard parameter (but you are basically screwed up if you have this enabled as it's a continuous trim)
Remember for your SSD health and optimal performance, to re-enable those options once everything is over by just replacing disable with enable, and stop with start.

Source:
https://www.redhat.com/archives/dm-devel/2019-May/msg00084.html
https://bbs.archlinux.org/viewtopic.php?id=246569
https://bugs.archlinux.org/task/62693
https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg87788.html
https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.1-FSTRIM-Bug

I miss the times where Torvalds himself roasts people with bad kernel commits...

Summary: Looks like there is a bad commit in the Linux 5.1.2 kernel, which in some circumstances issuing a ATA TRIM causes actual data to be discarded instead of deleted blocks.

Looks like Windows 10 is not the only one to get data loss after updates.

So far, it appears the issue happens if:
LUKS+dm_crypt if:(Linux kernel software encryption) A Samsung SSD is used Linux 5.1.2 is used  

It should be noted that this happens only when ATA TRIM is issued, so when the "discard" fstab option is used or the weekly "fstrim" service cron/systemd timer is enabled, or a manual fstrim is issued through CLI.

Ubuntu based distros should not be affected by this as it doesn't use the Linux 5.1 kernel.

Arch Linux/Manjaro users sadly are affected, on Manjaro the fstrim is enabled automatically, while on Arch it has to be issued or configured manually.
I do not know if other distros are affected

Since it's a bug related to the device mapper, this could happen on any filesystem

Mitigation: The best thing you can do is to shut down the system immediately and use another kernel.
You can also try disabling the fstrim timer by issuing this command, but it's not very recommended:
`systemctl disable fstrim.timer` `systemctl stop fstrim.timer` Or if you are an expert, checking in /etc/fstab for the discard parameter (but you are basically screwed up if you have this enabled as it's a continuous trim)
Remember for your SSD health and optimal performance, to re-enable those options once everything is over by just replacing disable with enable, and stop with start.

Source:
https://www.redhat.com/archives/dm-devel/2019-May/msg00084.html
https://bbs.archlinux.org/viewtopic.php?id=246569
https://bugs.archlinux.org/task/62693
https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg87788.html
https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.1-FSTRIM-Bug

Using LVM Check, dm-crypt Check, Samsung SSD check, Kernel 5.1 nope, running 4.9. Thanks for the heads up, could of been affected by this if I decided to update to a more recent kernel. 

I miss the times where Torvalds himself roasts people with bad kernel commits...

I miss the times where Torvalds himself roasts people with bad kernel commits...

Has SSD in system running 5.1.x
Heart rate increases
Said system is running 5.1.2
Heart rate increases further
Said SSD is a samsung
Heart rate increases even further
Doesn’t use LUKS
Heart rate stabilizes
 
uh, yeah, still gonna go update the kernel on that machine right now though.

Summary: Looks like there is a bad commit in the Linux 5.1.2 kernel, which in some circumstances issuing a ATA TRIM causes actual data to be discarded instead of deleted blocks.

Looks like Windows 10 is not the only one to get data loss after updates.

So far, it appears the issue happens if:
LUKS+dm_crypt if:(Linux kernel software encryption) A Samsung SSD is used Linux 5.1.2 is used  

It should be noted that this happens only when ATA TRIM is issued, so when the "discard" fstab option is used or the weekly "fstrim" service cron/systemd timer is enabled, or a manual fstrim is issued through CLI.

Ubuntu based distros should not be affected by this as it doesn't use the Linux 5.1 kernel.

Arch Linux/Manjaro users sadly are affected, on Manjaro the fstrim is enabled automatically, while on Arch it has to be issued or configured manually.
I do not know if other distros are affected

Since it's a bug related to the device mapper, this could happen on any filesystem

Mitigation: The best thing you can do is to shut down the system immediately and use another kernel.
You can also try disabling the fstrim timer by issuing this command, but it's not very recommended:
`systemctl disable fstrim.timer` `systemctl stop fstrim.timer` Or if you are an expert, checking in /etc/fstab for the discard parameter (but you are basically screwed up if you have this enabled as it's a continuous trim)
Remember for your SSD health and optimal performance, to re-enable those options once everything is over by just replacing disable with enable, and stop with start.

Source:
https://www.redhat.com/archives/dm-devel/2019-May/msg00084.html
https://bbs.archlinux.org/viewtopic.php?id=246569
https://bugs.archlinux.org/task/62693
https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg87788.html
https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.1-FSTRIM-Bug

Summary: Looks like there is a bad commit in the Linux 5.1.2 kernel, which in some circumstances issuing a ATA TRIM causes actual data to be discarded instead of deleted blocks.

Looks like Windows 10 is not the only one to get data loss after updates.

So far, it appears the issue happens if:
LUKS+dm_crypt if:(Linux kernel software encryption) A Samsung SSD is used Linux 5.1.2 is used  

It should be noted that this happens only when ATA TRIM is issued, so when the "discard" fstab option is used or the weekly "fstrim" service cron/systemd timer is enabled, or a manual fstrim is issued through CLI.

Ubuntu based distros should not be affected by this as it doesn't use the Linux 5.1 kernel.

Arch Linux/Manjaro users sadly are affected, on Manjaro the fstrim is enabled automatically, while on Arch it has to be issued or configured manually.
I do not know if other distros are affected

Since it's a bug related to the device mapper, this could happen on any filesystem

Mitigation: The best thing you can do is to shut down the system immediately and use another kernel.
You can also try disabling the fstrim timer by issuing this command, but it's not very recommended:
`systemctl disable fstrim.timer` `systemctl stop fstrim.timer` Or if you are an expert, checking in /etc/fstab for the discard parameter (but you are basically screwed up if you have this enabled as it's a continuous trim)
Remember for your SSD health and optimal performance, to re-enable those options once everything is over by just replacing disable with enable, and stop with start.

Source:
https://www.redhat.com/archives/dm-devel/2019-May/msg00084.html
https://bbs.archlinux.org/viewtopic.php?id=246569
https://bugs.archlinux.org/task/62693
https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg87788.html
https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.1-FSTRIM-Bug

Summary: Looks like there is a bad commit in the Linux 5.1.2 kernel, which in some circumstances issuing a ATA TRIM causes actual data to be discarded instead of deleted blocks.

Looks like Windows 10 is not the only one to get data loss after updates.

So far, it appears the issue happens if:
LUKS+dm_crypt if:(Linux kernel software encryption) A Samsung SSD is used Linux 5.1.2 is used  

It should be noted that this happens only when ATA TRIM is issued, so when the "discard" fstab option is used or the weekly "fstrim" service cron/systemd timer is enabled, or a manual fstrim is issued through CLI.

Ubuntu based distros should not be affected by this as it doesn't use the Linux 5.1 kernel.

Arch Linux/Manjaro users sadly are affected, on Manjaro the fstrim is enabled automatically, while on Arch it has to be issued or configured manually.
I do not know if other distros are affected

Since it's a bug related to the device mapper, this could happen on any filesystem

Mitigation: The best thing you can do is to shut down the system immediately and use another kernel.
You can also try disabling the fstrim timer by issuing this command, but it's not very recommended:
`systemctl disable fstrim.timer` `systemctl stop fstrim.timer` Or if you are an expert, checking in /etc/fstab for the discard parameter (but you are basically screwed up if you have this enabled as it's a continuous trim)
Remember for your SSD health and optimal performance, to re-enable those options once everything is over by just replacing disable with enable, and stop with start.

Source:
https://www.redhat.com/archives/dm-devel/2019-May/msg00084.html
https://bbs.archlinux.org/viewtopic.php?id=246569
https://bugs.archlinux.org/task/62693
https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg87788.html
https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.1-FSTRIM-Bug

Summary: Looks like there is a bad commit in the Linux 5.1.2 kernel, which in some circumstances issuing a ATA TRIM causes actual data to be discarded instead of deleted blocks.

Looks like Windows 10 is not the only one to get data loss after updates.

So far, it appears the issue happens if:
LUKS+dm_crypt if:(Linux kernel software encryption) A Samsung SSD is used Linux 5.1.2 is used  

It should be noted that this happens only when ATA TRIM is issued, so when the "discard" fstab option is used or the weekly "fstrim" service cron/systemd timer is enabled, or a manual fstrim is issued through CLI.

Ubuntu based distros should not be affected by this as it doesn't use the Linux 5.1 kernel.

Arch Linux/Manjaro users sadly are affected, on Manjaro the fstrim is enabled automatically, while on Arch it has to be issued or configured manually.
I do not know if other distros are affected

Since it's a bug related to the device mapper, this could happen on any filesystem

Mitigation: The best thing you can do is to shut down the system immediately and use another kernel.
You can also try disabling the fstrim timer by issuing this command, but it's not very recommended:
`systemctl disable fstrim.timer` `systemctl stop fstrim.timer` Or if you are an expert, checking in /etc/fstab for the discard parameter (but you are basically screwed up if you have this enabled as it's a continuous trim)
Remember for your SSD health and optimal performance, to re-enable those options once everything is over by just replacing disable with enable, and stop with start.

Source:
https://www.redhat.com/archives/dm-devel/2019-May/msg00084.html
https://bbs.archlinux.org/viewtopic.php?id=246569
https://bugs.archlinux.org/task/62693
https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg87788.html
https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.1-FSTRIM-Bug

It's not completely clear at this point, the reporters of those issues look like to have in common only Samsung SSD's + LUKS+LVM encryption, Samsung SSD's are pretty common though...

Summary: Looks like there is a bad commit in the Linux 5.1.2 kernel, which in some circumstances issuing a ATA TRIM causes actual data to be discarded instead of deleted blocks.

Looks like Windows 10 is not the only one to get data loss after updates.

So far, it appears the issue happens if:
LUKS+dm_crypt if:(Linux kernel software encryption) A Samsung SSD is used Linux 5.1.2 is used  

It should be noted that this happens only when ATA TRIM is issued, so when the "discard" fstab option is used or the weekly "fstrim" service cron/systemd timer is enabled, or a manual fstrim is issued through CLI.

Ubuntu based distros should not be affected by this as it doesn't use the Linux 5.1 kernel.

Arch Linux/Manjaro users sadly are affected, on Manjaro the fstrim is enabled automatically, while on Arch it has to be issued or configured manually.
I do not know if other distros are affected

Since it's a bug related to the device mapper, this could happen on any filesystem

Mitigation: The best thing you can do is to shut down the system immediately and use another kernel.
You can also try disabling the fstrim timer by issuing this command, but it's not very recommended:
`systemctl disable fstrim.timer` `systemctl stop fstrim.timer` Or if you are an expert, checking in /etc/fstab for the discard parameter (but you are basically screwed up if you have this enabled as it's a continuous trim)
Remember for your SSD health and optimal performance, to re-enable those options once everything is over by just replacing disable with enable, and stop with start.

Source:
https://www.redhat.com/archives/dm-devel/2019-May/msg00084.html
https://bbs.archlinux.org/viewtopic.php?id=246569
https://bugs.archlinux.org/task/62693
https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg87788.html
https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.1-FSTRIM-Bug

JPEG to BASIS converter. Contains ads you won't want to see