[Solved] Building kernels under 5.10 takes twice as long as under 4.19
Bit the bullet, bisected v5.5..v5.6 and found this:
0ddad21d3e99c743a3aa473121dc5561679e26bb is the first bad commit
commit 0ddad21d3e99c743a3aa473121dc5561679e26bb
Author: Linus Torvalds
Date: Mon Dec 9 09:48:27 2019 -0800
pipe: use exclusive waits when reading or writing
[...]
[ Note! This kernel improvement seems to be very good at triggering a
race condition in the make jobserver (in GNU make 4.2.1) for me. It's a
long known bug that was fixed back in June 2017 by GNU make commit
b552b0525198 ("[SV 51159] Use a non-blocking read with pselect to
avoid hangs.").
But there wasn't a new release of GNU make until 4.3 on Jan 19 2020,
so a number of distributions may still have the buggy version. Some
have backported the fix to their 4.2.1 release, though, and even
without the fix it's quite timing-dependent whether the bug actually
is hit. ]
[...]
After updating "make" to 4.3 all is well.
Feynman was right again. ;)
--
The truth always turns out to be simpler than you thought.
Richard Feynman
signature.asc
Description: OpenPGP digital signature
Building kernels under 5.10 takes twice as long as under 4.19
Hi! I tried kernel 5.10.x and encountered a strange problem: building the same kernel (5.10.22/23) took roughly twice as long as under 4.19.179. This is reproducible under kernels 5.9, 5.8 and 5.6. The latter is where it apparently starts, kernel 5.5 is not affected. Here's an example: 5.6 built under 5.5, -j4 [...] LD [M] sound/pci/hda/snd-hda-intel.ko real11m44,125s user38m35,022s sys 3m17,940s 5.6 under 5.6, -j4 ** [...] LD [M] sound/pci/hda/snd-hda-intel.ko real23m25,834s user26m7,738s sys 2m42,292s Always after "make mrproper", with -j4, identical .config and everything else unchanged. It's also there with a default .config. When I build the kernels under 4.19 or 5.5 with -j4, CPU-usage is 100 % almost all the time. Under 5.6 and later, CPU-usage goes down to ~30 % for longer periods during which I see long sections of sorted items like "fs/xfs" which I had never noticed before. CPUfreq-governor was "ondemand" in all cases (for 5.10 set via commandline). The CPU is an Intel Core i3 (Clarkdale/Ironlake; still fast enough for a snappy LFS-Linux with Plasma 5). Before writing a bug-report: any ideas what might cause this or how to narrow the search? A full bisect between 5.5 and 5.6 would be a real drag. And please don't say this is a feature now. ;) Thanks. Rainer -- The truth always turns out to be simpler than you thought. Richard Feynman signature.asc Description: OpenPGP digital signature
Re: ext4 file system corruption with v4.19.3 / v4.19.4
Am 02.12.18 um 21:19 schrieb Andrey Melnikov: > чт, 29 нояб. 2018 г. в 01:08, Rainer Fiebig : >> >> Am 28.11.18 um 22:13 schrieb Andrey Melnikov: >>> ср, 28 нояб. 2018 г. в 18:55, Rainer Fiebig : >>>> >>>> Am Mittwoch, 28. November 2018, 13:02:56 schrieb Andrey Jr. Melnikov: >>>>> In gmane.comp.file-systems.ext4 Theodore Y. Ts'o wrote: >>>>>> On Wed, Nov 28, 2018 at 03:16:33AM +0300, Andrey Jr. Melnikov wrote: >>>>>>> Corrupted inodes - always directory, not touched at least year or >>>>>>> more for writing. Something wrong when updating atime? >>>>>> >>>>>> We're not sure. The frustrating thing is that it's not reproducing >>>>>> for me. I run extensive regression tests, and I'm using 4.19 on my >>>>>> development laptop without notcing any problems. If I could reproduce >>>>>> it, I could debug it, but since I can't, I need to rely on those who >>>>>> are seeing the problem to help pinpoint the problem. >>>>> >>>>> My workstation hit this bug every time after boot. If you have an idea - I >>>>> may test it. >>>>> >>>>>> I'm trying to figure out common factors from those people who are >>>>>> reporting problems. >>>>>> >>>>>> (a) What distribution are you running (it appears that many people >>>>>> reporting problems are running Ubuntu, but this may be a sampling >>>>>> issue; lots of people run Ubuntu)? (For the record, I'm using Debian >>>>>> Testing.) >>>>> >>>>> Debian sid but self-build kernel from ubuntu mainline-ppa. >>>> >>>> You could try a vanilla 4.19.5 from https://www.kernel.org/ >>>> and compile it with your current .config. >>> >>> mainline-ppa use vanilla kernel. Patches only adds debian specific >>> build infrastructure. >>> >>>> If you still see the errors, at least the Ubuntu-kernel could be ruled out. >>>> >>>> In addition, if you still see the errors: >>>> >>>> - backup your .config in a *different* folder (so that you can later re-use >>>> it) >>>> - do a "make mrproper" (deletes the .config, see above) >>>> - do a "make defconfig" >>>> - and compile the kernel with that new .config >>> >>> defconfig is great - for abstract hardware in vacuum. >>> >>>> If you still have the problem after that, you may want to learn how to >>>> bisect. >>>> ;) >>> I'm already know how-to bisect. From kernel 2.0 era. Without git ;) >>> >>> This problem simply non-bisectable, when same kernel corrupt FS on my >>> workstation but normally working on other servers. >>> And now - FS corrupted again with disabled CONFIG_EXT4_ENCRYPTION. Great. >> >> OK, - and now we are looking forward to *your* ideas how to solve this. > > After four days playing games around git bisect - real winner is > debian gcc-8.2.0-9. Upgrade it to 8.2.0-10 or use 7.3.0-30 version for > same kernel + config - does not exhibit ext4 corruption. > > I think I hit this https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87859 > with 8.2.0-9 version. > Good that it works for you. But others used gcc 5.4.0 or 6.3.0 and were hit anyway: https://bugzilla.kernel.org/show_bug.cgi?id=201685#c165 signature.asc Description: OpenPGP digital signature
Re: ext4 file system corruption with v4.19.3 / v4.19.4
Am 02.12.18 um 21:19 schrieb Andrey Melnikov: > чт, 29 нояб. 2018 г. в 01:08, Rainer Fiebig : >> >> Am 28.11.18 um 22:13 schrieb Andrey Melnikov: >>> ср, 28 нояб. 2018 г. в 18:55, Rainer Fiebig : >>>> >>>> Am Mittwoch, 28. November 2018, 13:02:56 schrieb Andrey Jr. Melnikov: >>>>> In gmane.comp.file-systems.ext4 Theodore Y. Ts'o wrote: >>>>>> On Wed, Nov 28, 2018 at 03:16:33AM +0300, Andrey Jr. Melnikov wrote: >>>>>>> Corrupted inodes - always directory, not touched at least year or >>>>>>> more for writing. Something wrong when updating atime? >>>>>> >>>>>> We're not sure. The frustrating thing is that it's not reproducing >>>>>> for me. I run extensive regression tests, and I'm using 4.19 on my >>>>>> development laptop without notcing any problems. If I could reproduce >>>>>> it, I could debug it, but since I can't, I need to rely on those who >>>>>> are seeing the problem to help pinpoint the problem. >>>>> >>>>> My workstation hit this bug every time after boot. If you have an idea - I >>>>> may test it. >>>>> >>>>>> I'm trying to figure out common factors from those people who are >>>>>> reporting problems. >>>>>> >>>>>> (a) What distribution are you running (it appears that many people >>>>>> reporting problems are running Ubuntu, but this may be a sampling >>>>>> issue; lots of people run Ubuntu)? (For the record, I'm using Debian >>>>>> Testing.) >>>>> >>>>> Debian sid but self-build kernel from ubuntu mainline-ppa. >>>> >>>> You could try a vanilla 4.19.5 from https://www.kernel.org/ >>>> and compile it with your current .config. >>> >>> mainline-ppa use vanilla kernel. Patches only adds debian specific >>> build infrastructure. >>> >>>> If you still see the errors, at least the Ubuntu-kernel could be ruled out. >>>> >>>> In addition, if you still see the errors: >>>> >>>> - backup your .config in a *different* folder (so that you can later re-use >>>> it) >>>> - do a "make mrproper" (deletes the .config, see above) >>>> - do a "make defconfig" >>>> - and compile the kernel with that new .config >>> >>> defconfig is great - for abstract hardware in vacuum. >>> >>>> If you still have the problem after that, you may want to learn how to >>>> bisect. >>>> ;) >>> I'm already know how-to bisect. From kernel 2.0 era. Without git ;) >>> >>> This problem simply non-bisectable, when same kernel corrupt FS on my >>> workstation but normally working on other servers. >>> And now - FS corrupted again with disabled CONFIG_EXT4_ENCRYPTION. Great. >> >> OK, - and now we are looking forward to *your* ideas how to solve this. > > After four days playing games around git bisect - real winner is > debian gcc-8.2.0-9. Upgrade it to 8.2.0-10 or use 7.3.0-30 version for > same kernel + config - does not exhibit ext4 corruption. > > I think I hit this https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87859 > with 8.2.0-9 version. > Good that it works for you. But others used gcc 5.4.0 or 6.3.0 and were hit anyway: https://bugzilla.kernel.org/show_bug.cgi?id=201685#c165 signature.asc Description: OpenPGP digital signature
Re: ext4 file system corruption with v4.19.3 / v4.19.4
Am 28.11.18 um 22:13 schrieb Andrey Melnikov: > ср, 28 нояб. 2018 г. в 18:55, Rainer Fiebig : >> >> Am Mittwoch, 28. November 2018, 13:02:56 schrieb Andrey Jr. Melnikov: >>> In gmane.comp.file-systems.ext4 Theodore Y. Ts'o wrote: >>>> On Wed, Nov 28, 2018 at 03:16:33AM +0300, Andrey Jr. Melnikov wrote: >>>>> Corrupted inodes - always directory, not touched at least year or >>>>> more for writing. Something wrong when updating atime? >>>> >>>> We're not sure. The frustrating thing is that it's not reproducing >>>> for me. I run extensive regression tests, and I'm using 4.19 on my >>>> development laptop without notcing any problems. If I could reproduce >>>> it, I could debug it, but since I can't, I need to rely on those who >>>> are seeing the problem to help pinpoint the problem. >>> >>> My workstation hit this bug every time after boot. If you have an idea - I >>> may test it. >>> >>>> I'm trying to figure out common factors from those people who are >>>> reporting problems. >>>> >>>> (a) What distribution are you running (it appears that many people >>>> reporting problems are running Ubuntu, but this may be a sampling >>>> issue; lots of people run Ubuntu)? (For the record, I'm using Debian >>>> Testing.) >>> >>> Debian sid but self-build kernel from ubuntu mainline-ppa. >> >> You could try a vanilla 4.19.5 from https://www.kernel.org/ >> and compile it with your current .config. > > mainline-ppa use vanilla kernel. Patches only adds debian specific > build infrastructure. > >> If you still see the errors, at least the Ubuntu-kernel could be ruled out. >> >> In addition, if you still see the errors: >> >> - backup your .config in a *different* folder (so that you can later re-use >> it) >> - do a "make mrproper" (deletes the .config, see above) >> - do a "make defconfig" >> - and compile the kernel with that new .config > > defconfig is great - for abstract hardware in vacuum. > >> If you still have the problem after that, you may want to learn how to >> bisect. >> ;) > I'm already know how-to bisect. From kernel 2.0 era. Without git ;) > > This problem simply non-bisectable, when same kernel corrupt FS on my > workstation but normally working on other servers. > And now - FS corrupted again with disabled CONFIG_EXT4_ENCRYPTION. Great. OK, - and now we are looking forward to *your* ideas how to solve this. > >> So long! >> >> Rainer Fiebig >> >> >>> >>>> (b) What hardware are you using? (SSD? SATA-attached? >>>> NVMe-attached?) >>> >>> SATA HDD WDC WD20EZRZ-00Z5HB0. >>> >>>> (c) Are you using LVM? LUKS (e.g., disk encrypted)? >>> >>> No and no. Plain ext4. >>> -- cut -- >>> debugfs: features >>> Filesystem features: has_journal ext_attr resize_inode dir_index filetype >>> needs_recovery extent 64bit flex_bg sparse_super large_file huge_file >>> dir_nlink extra_isize metadata_csum >>> -- cut -- >>> >>>> (d) are you using discard? One theory is a recent discard change may >>>> be in play. How do you use discard? (mount option, fstrim, etc.) >>> >>> no >> >> -- >> The truth always turns out to be simpler than you thought. >> Richard Feynman signature.asc Description: OpenPGP digital signature
Re: ext4 file system corruption with v4.19.3 / v4.19.4
Am 28.11.18 um 22:13 schrieb Andrey Melnikov: > ср, 28 нояб. 2018 г. в 18:55, Rainer Fiebig : >> >> Am Mittwoch, 28. November 2018, 13:02:56 schrieb Andrey Jr. Melnikov: >>> In gmane.comp.file-systems.ext4 Theodore Y. Ts'o wrote: >>>> On Wed, Nov 28, 2018 at 03:16:33AM +0300, Andrey Jr. Melnikov wrote: >>>>> Corrupted inodes - always directory, not touched at least year or >>>>> more for writing. Something wrong when updating atime? >>>> >>>> We're not sure. The frustrating thing is that it's not reproducing >>>> for me. I run extensive regression tests, and I'm using 4.19 on my >>>> development laptop without notcing any problems. If I could reproduce >>>> it, I could debug it, but since I can't, I need to rely on those who >>>> are seeing the problem to help pinpoint the problem. >>> >>> My workstation hit this bug every time after boot. If you have an idea - I >>> may test it. >>> >>>> I'm trying to figure out common factors from those people who are >>>> reporting problems. >>>> >>>> (a) What distribution are you running (it appears that many people >>>> reporting problems are running Ubuntu, but this may be a sampling >>>> issue; lots of people run Ubuntu)? (For the record, I'm using Debian >>>> Testing.) >>> >>> Debian sid but self-build kernel from ubuntu mainline-ppa. >> >> You could try a vanilla 4.19.5 from https://www.kernel.org/ >> and compile it with your current .config. > > mainline-ppa use vanilla kernel. Patches only adds debian specific > build infrastructure. > >> If you still see the errors, at least the Ubuntu-kernel could be ruled out. >> >> In addition, if you still see the errors: >> >> - backup your .config in a *different* folder (so that you can later re-use >> it) >> - do a "make mrproper" (deletes the .config, see above) >> - do a "make defconfig" >> - and compile the kernel with that new .config > > defconfig is great - for abstract hardware in vacuum. > >> If you still have the problem after that, you may want to learn how to >> bisect. >> ;) > I'm already know how-to bisect. From kernel 2.0 era. Without git ;) > > This problem simply non-bisectable, when same kernel corrupt FS on my > workstation but normally working on other servers. > And now - FS corrupted again with disabled CONFIG_EXT4_ENCRYPTION. Great. OK, - and now we are looking forward to *your* ideas how to solve this. > >> So long! >> >> Rainer Fiebig >> >> >>> >>>> (b) What hardware are you using? (SSD? SATA-attached? >>>> NVMe-attached?) >>> >>> SATA HDD WDC WD20EZRZ-00Z5HB0. >>> >>>> (c) Are you using LVM? LUKS (e.g., disk encrypted)? >>> >>> No and no. Plain ext4. >>> -- cut -- >>> debugfs: features >>> Filesystem features: has_journal ext_attr resize_inode dir_index filetype >>> needs_recovery extent 64bit flex_bg sparse_super large_file huge_file >>> dir_nlink extra_isize metadata_csum >>> -- cut -- >>> >>>> (d) are you using discard? One theory is a recent discard change may >>>> be in play. How do you use discard? (mount option, fstrim, etc.) >>> >>> no >> >> -- >> The truth always turns out to be simpler than you thought. >> Richard Feynman signature.asc Description: OpenPGP digital signature
Re: ext4 file system corruption with v4.19.3 / v4.19.4
Am 28.11.18 um 17:10 schrieb Theodore Y. Ts'o: > On Wed, Nov 28, 2018 at 04:56:51PM +0100, Rainer Fiebig wrote: >> >> If you still see the errors, at least the Ubuntu-kernel could be ruled out. > > My impression is that some of the people reporting problems have been > using stock upstream kernels, so I wasn't really worried about the > Ubuntu kernel (although it could be something about the default > configs that Ubuntu sets up). What I was more wondering was whether > there was something about userspace or default configs of Ubuntu. > This isn't necessarily a *problem* per se; for examople, not that long > ago some users were getting surprised when a problem showed up with an > older version of the LVM2 userspace with newer upstream kernels. > After a while, you learn to get super paranoid about making sure to > rule out all possibilities when trying to debug problems that are only > hitting a set of users. > > - Ted > OK, thanks. Perhaps Andrey can tell us then what impact the default .config had on the problem. Rainer Fiebig signature.asc Description: OpenPGP digital signature
Re: ext4 file system corruption with v4.19.3 / v4.19.4
Am 28.11.18 um 17:10 schrieb Theodore Y. Ts'o: > On Wed, Nov 28, 2018 at 04:56:51PM +0100, Rainer Fiebig wrote: >> >> If you still see the errors, at least the Ubuntu-kernel could be ruled out. > > My impression is that some of the people reporting problems have been > using stock upstream kernels, so I wasn't really worried about the > Ubuntu kernel (although it could be something about the default > configs that Ubuntu sets up). What I was more wondering was whether > there was something about userspace or default configs of Ubuntu. > This isn't necessarily a *problem* per se; for examople, not that long > ago some users were getting surprised when a problem showed up with an > older version of the LVM2 userspace with newer upstream kernels. > After a while, you learn to get super paranoid about making sure to > rule out all possibilities when trying to debug problems that are only > hitting a set of users. > > - Ted > OK, thanks. Perhaps Andrey can tell us then what impact the default .config had on the problem. Rainer Fiebig signature.asc Description: OpenPGP digital signature
Re: ext4 file system corruption with v4.19.3 / v4.19.4
Am Mittwoch, 28. November 2018, 13:02:56 schrieb Andrey Jr. Melnikov: > In gmane.comp.file-systems.ext4 Theodore Y. Ts'o wrote: > > On Wed, Nov 28, 2018 at 03:16:33AM +0300, Andrey Jr. Melnikov wrote: > > > Corrupted inodes - always directory, not touched at least year or > > > more for writing. Something wrong when updating atime? > > > > We're not sure. The frustrating thing is that it's not reproducing > > for me. I run extensive regression tests, and I'm using 4.19 on my > > development laptop without notcing any problems. If I could reproduce > > it, I could debug it, but since I can't, I need to rely on those who > > are seeing the problem to help pinpoint the problem. > > My workstation hit this bug every time after boot. If you have an idea - I > may test it. > > > I'm trying to figure out common factors from those people who are > > reporting problems. > > > > (a) What distribution are you running (it appears that many people > > reporting problems are running Ubuntu, but this may be a sampling > > issue; lots of people run Ubuntu)? (For the record, I'm using Debian > > Testing.) > > Debian sid but self-build kernel from ubuntu mainline-ppa. You could try a vanilla 4.19.5 from https://www.kernel.org/ and compile it with your current .config. If you still see the errors, at least the Ubuntu-kernel could be ruled out. In addition, if you still see the errors: - backup your .config in a *different* folder (so that you can later re-use it) - do a "make mrproper" (deletes the .config, see above) - do a "make defconfig" - and compile the kernel with that new .config If you still have the problem after that, you may want to learn how to bisect. ;) So long! Rainer Fiebig > > > (b) What hardware are you using? (SSD? SATA-attached? > > NVMe-attached?) > > SATA HDD WDC WD20EZRZ-00Z5HB0. > > > (c) Are you using LVM? LUKS (e.g., disk encrypted)? > > No and no. Plain ext4. > -- cut -- > debugfs: features > Filesystem features: has_journal ext_attr resize_inode dir_index filetype > needs_recovery extent 64bit flex_bg sparse_super large_file huge_file > dir_nlink extra_isize metadata_csum > -- cut -- > > > (d) are you using discard? One theory is a recent discard change may > > be in play. How do you use discard? (mount option, fstrim, etc.) > > no -- The truth always turns out to be simpler than you thought. Richard Feynman signature.asc Description: This is a digitally signed message part.
Re: ext4 file system corruption with v4.19.3 / v4.19.4
Am Mittwoch, 28. November 2018, 13:02:56 schrieb Andrey Jr. Melnikov: > In gmane.comp.file-systems.ext4 Theodore Y. Ts'o wrote: > > On Wed, Nov 28, 2018 at 03:16:33AM +0300, Andrey Jr. Melnikov wrote: > > > Corrupted inodes - always directory, not touched at least year or > > > more for writing. Something wrong when updating atime? > > > > We're not sure. The frustrating thing is that it's not reproducing > > for me. I run extensive regression tests, and I'm using 4.19 on my > > development laptop without notcing any problems. If I could reproduce > > it, I could debug it, but since I can't, I need to rely on those who > > are seeing the problem to help pinpoint the problem. > > My workstation hit this bug every time after boot. If you have an idea - I > may test it. > > > I'm trying to figure out common factors from those people who are > > reporting problems. > > > > (a) What distribution are you running (it appears that many people > > reporting problems are running Ubuntu, but this may be a sampling > > issue; lots of people run Ubuntu)? (For the record, I'm using Debian > > Testing.) > > Debian sid but self-build kernel from ubuntu mainline-ppa. You could try a vanilla 4.19.5 from https://www.kernel.org/ and compile it with your current .config. If you still see the errors, at least the Ubuntu-kernel could be ruled out. In addition, if you still see the errors: - backup your .config in a *different* folder (so that you can later re-use it) - do a "make mrproper" (deletes the .config, see above) - do a "make defconfig" - and compile the kernel with that new .config If you still have the problem after that, you may want to learn how to bisect. ;) So long! Rainer Fiebig > > > (b) What hardware are you using? (SSD? SATA-attached? > > NVMe-attached?) > > SATA HDD WDC WD20EZRZ-00Z5HB0. > > > (c) Are you using LVM? LUKS (e.g., disk encrypted)? > > No and no. Plain ext4. > -- cut -- > debugfs: features > Filesystem features: has_journal ext_attr resize_inode dir_index filetype > needs_recovery extent 64bit flex_bg sparse_super large_file huge_file > dir_nlink extra_isize metadata_csum > -- cut -- > > > (d) are you using discard? One theory is a recent discard change may > > be in play. How do you use discard? (mount option, fstrim, etc.) > > no -- The truth always turns out to be simpler than you thought. Richard Feynman signature.asc Description: This is a digitally signed message part.
Re: ext4 file system corruption with v4.19.3 / v4.19.4
Am 27.11.18 um 22:22 schrieb Guenter Roeck: > On Tue, Nov 27, 2018 at 07:55:01PM +0100, Rainer Fiebig wrote: >> Am Dienstag, 27. November 2018, 15:48:19 schrieb Marek Habersack: >>> On 27/11/2018 15:32, Guenter Roeck wrote: >>> Hi, >>> >>> You might try to see if you have CONFIG_SCSI_MQ_DEFAULT=yes in your kernel >>> config. Starting with 4.19.1 it somehow interferes with ext4 and causes >>> problems similar to the ones you list below. Ever since I disabled MQ >>> (either recompile your kernel or add `scsi_mod.use_blk_mq=0` to the kernel >>> command line) none of those errors came back. >>> >>> hope it helps, >>> >>> marek >> >> Unfortunately, this doesn't seem to work in every case: >> https://bugzilla.kernel.org/show_bug.cgi?id=201685#c54 >> >> And I'm using a defconfig-4.19.3 (meaning: CONFIG_SCSI_MQ_DEFAULT=yes) in a >> VM >> and I'm not seeing those errors there. OK, it's a VM - but anyway. >> > > Agreed. I disabled CONFIG_SCSI_MQ_DEFAULT, but the problem is still seen > at least on one of my servers, so disabling it does not help, at least not > in my case. > > If the problem is somehow related to CONFIG_SCSI_MQ_DEFAULT, you might > have to explicitly use a scsi drive (virtio-scsi-pci or similar) to > trigger its use in a VM. It seems more likely to me now that it may have nothing to do with the SCSI-settings. Perhaps with some other config-option that's not set in a defconfig. I had hoped the problem would show up in the VM, so I could have safely bisected it there. But tough luck. So long! Rainer Fiebig > > Guenter > >> The definite cause of this can only be found by bisecting, IMO. And it needs >> to be pinned down because else some feeling of insecurity will remain. >> >> So long! >> >> Rainer Fiebig >> >>> >>>> [trying again, this time with correct kernel.org address] >>>> >>>> Hi, >>>> >>>> I have seen the following and similar problems several times, >>>> with both v4.19.3 and v4.19.4: >>>> >>>> Nov 23 04:32:25 mars kernel: [112668.673671] EXT4-fs error (device sdb1): >>>> ext4_iget:4831: inode #12602889: comm git: bad extra_isize 33661 (inode >>>> size 256) >>>> Nov 23 04:32:25 mars kernel: [112668.675217] Aborting journal on device >>>> sdb1-8. Nov 23 04:32:25 mars kernel: [112668.676681] EXT4-fs (sdb1): >>>> Remounting filesystem read-only Nov 23 04:32:25 mars kernel: >>>> [112668.808886] EXT4-fs error (device sdb1): ext4_iget:4831: inode >>>> #12602881: comm rm: bad extra_isize 33685 (inode size 256) >>>> ... >>>> >>>> Nov 25 00:12:43 saturn kernel: [59377.725984] EXT4-fs error (device sda1): >>>> ext4_lookup:1578: inode #238034131: comm updatedb.mlocat: deleted inode >>>> referenced: 238160407 >>>> Nov 25 00:12:43 saturn kernel: [59377.766638] Aborting journal on device >>>> sda1-8. Nov 25 00:12:43 saturn kernel: [59377.779372] EXT4-fs (sda1): >>>> Remounting filesystem read-only ... >>>> >>>> Nov 24 01:52:31 saturn kernel: [189085.240016] EXT4-fs error (device >>>> sda1): ext4_lookup:1578: inode #52038457: comm nfsd: deleted inode >>>> referenced: 52043796 >>>> Nov 24 01:52:31 saturn kernel: [189085.263427] Aborting journal on device >>>> sda1-8. Nov 24 01:52:31 saturn kernel: [189085.275313] EXT4-fs (sda1): >>>> Remounting filesystem read-only >>>> >>>> >>>> The same systems running v4.18.6 never experienced a problem. >>>> >>>> Has anyone else seen similar problems ? Is there anything I can do >>>> to help tracking down the problem ? >>>> >>>> Thanks, >>>> Guenter >> >> -- >> The truth always turns out to be simpler than you thought. >> Richard Feynman > > signature.asc Description: OpenPGP digital signature
Re: ext4 file system corruption with v4.19.3 / v4.19.4
Am 27.11.18 um 22:22 schrieb Guenter Roeck: > On Tue, Nov 27, 2018 at 07:55:01PM +0100, Rainer Fiebig wrote: >> Am Dienstag, 27. November 2018, 15:48:19 schrieb Marek Habersack: >>> On 27/11/2018 15:32, Guenter Roeck wrote: >>> Hi, >>> >>> You might try to see if you have CONFIG_SCSI_MQ_DEFAULT=yes in your kernel >>> config. Starting with 4.19.1 it somehow interferes with ext4 and causes >>> problems similar to the ones you list below. Ever since I disabled MQ >>> (either recompile your kernel or add `scsi_mod.use_blk_mq=0` to the kernel >>> command line) none of those errors came back. >>> >>> hope it helps, >>> >>> marek >> >> Unfortunately, this doesn't seem to work in every case: >> https://bugzilla.kernel.org/show_bug.cgi?id=201685#c54 >> >> And I'm using a defconfig-4.19.3 (meaning: CONFIG_SCSI_MQ_DEFAULT=yes) in a >> VM >> and I'm not seeing those errors there. OK, it's a VM - but anyway. >> > > Agreed. I disabled CONFIG_SCSI_MQ_DEFAULT, but the problem is still seen > at least on one of my servers, so disabling it does not help, at least not > in my case. > > If the problem is somehow related to CONFIG_SCSI_MQ_DEFAULT, you might > have to explicitly use a scsi drive (virtio-scsi-pci or similar) to > trigger its use in a VM. It seems more likely to me now that it may have nothing to do with the SCSI-settings. Perhaps with some other config-option that's not set in a defconfig. I had hoped the problem would show up in the VM, so I could have safely bisected it there. But tough luck. So long! Rainer Fiebig > > Guenter > >> The definite cause of this can only be found by bisecting, IMO. And it needs >> to be pinned down because else some feeling of insecurity will remain. >> >> So long! >> >> Rainer Fiebig >> >>> >>>> [trying again, this time with correct kernel.org address] >>>> >>>> Hi, >>>> >>>> I have seen the following and similar problems several times, >>>> with both v4.19.3 and v4.19.4: >>>> >>>> Nov 23 04:32:25 mars kernel: [112668.673671] EXT4-fs error (device sdb1): >>>> ext4_iget:4831: inode #12602889: comm git: bad extra_isize 33661 (inode >>>> size 256) >>>> Nov 23 04:32:25 mars kernel: [112668.675217] Aborting journal on device >>>> sdb1-8. Nov 23 04:32:25 mars kernel: [112668.676681] EXT4-fs (sdb1): >>>> Remounting filesystem read-only Nov 23 04:32:25 mars kernel: >>>> [112668.808886] EXT4-fs error (device sdb1): ext4_iget:4831: inode >>>> #12602881: comm rm: bad extra_isize 33685 (inode size 256) >>>> ... >>>> >>>> Nov 25 00:12:43 saturn kernel: [59377.725984] EXT4-fs error (device sda1): >>>> ext4_lookup:1578: inode #238034131: comm updatedb.mlocat: deleted inode >>>> referenced: 238160407 >>>> Nov 25 00:12:43 saturn kernel: [59377.766638] Aborting journal on device >>>> sda1-8. Nov 25 00:12:43 saturn kernel: [59377.779372] EXT4-fs (sda1): >>>> Remounting filesystem read-only ... >>>> >>>> Nov 24 01:52:31 saturn kernel: [189085.240016] EXT4-fs error (device >>>> sda1): ext4_lookup:1578: inode #52038457: comm nfsd: deleted inode >>>> referenced: 52043796 >>>> Nov 24 01:52:31 saturn kernel: [189085.263427] Aborting journal on device >>>> sda1-8. Nov 24 01:52:31 saturn kernel: [189085.275313] EXT4-fs (sda1): >>>> Remounting filesystem read-only >>>> >>>> >>>> The same systems running v4.18.6 never experienced a problem. >>>> >>>> Has anyone else seen similar problems ? Is there anything I can do >>>> to help tracking down the problem ? >>>> >>>> Thanks, >>>> Guenter >> >> -- >> The truth always turns out to be simpler than you thought. >> Richard Feynman > > signature.asc Description: OpenPGP digital signature
Re: ext4 file system corruption with v4.19.3 / v4.19.4
Am Dienstag, 27. November 2018, 15:48:19 schrieb Marek Habersack: > On 27/11/2018 15:32, Guenter Roeck wrote: > Hi, > > You might try to see if you have CONFIG_SCSI_MQ_DEFAULT=yes in your kernel > config. Starting with 4.19.1 it somehow interferes with ext4 and causes > problems similar to the ones you list below. Ever since I disabled MQ > (either recompile your kernel or add `scsi_mod.use_blk_mq=0` to the kernel > command line) none of those errors came back. > > hope it helps, > > marek Unfortunately, this doesn't seem to work in every case: https://bugzilla.kernel.org/show_bug.cgi?id=201685#c54 And I'm using a defconfig-4.19.3 (meaning: CONFIG_SCSI_MQ_DEFAULT=yes) in a VM and I'm not seeing those errors there. OK, it's a VM - but anyway. The definite cause of this can only be found by bisecting, IMO. And it needs to be pinned down because else some feeling of insecurity will remain. So long! Rainer Fiebig > > > [trying again, this time with correct kernel.org address] > > > > Hi, > > > > I have seen the following and similar problems several times, > > with both v4.19.3 and v4.19.4: > > > > Nov 23 04:32:25 mars kernel: [112668.673671] EXT4-fs error (device sdb1): > > ext4_iget:4831: inode #12602889: comm git: bad extra_isize 33661 (inode > > size 256) > > Nov 23 04:32:25 mars kernel: [112668.675217] Aborting journal on device > > sdb1-8. Nov 23 04:32:25 mars kernel: [112668.676681] EXT4-fs (sdb1): > > Remounting filesystem read-only Nov 23 04:32:25 mars kernel: > > [112668.808886] EXT4-fs error (device sdb1): ext4_iget:4831: inode > > #12602881: comm rm: bad extra_isize 33685 (inode size 256) > > ... > > > > Nov 25 00:12:43 saturn kernel: [59377.725984] EXT4-fs error (device sda1): > > ext4_lookup:1578: inode #238034131: comm updatedb.mlocat: deleted inode > > referenced: 238160407 > > Nov 25 00:12:43 saturn kernel: [59377.766638] Aborting journal on device > > sda1-8. Nov 25 00:12:43 saturn kernel: [59377.779372] EXT4-fs (sda1): > > Remounting filesystem read-only ... > > > > Nov 24 01:52:31 saturn kernel: [189085.240016] EXT4-fs error (device > > sda1): ext4_lookup:1578: inode #52038457: comm nfsd: deleted inode > > referenced: 52043796 > > Nov 24 01:52:31 saturn kernel: [189085.263427] Aborting journal on device > > sda1-8. Nov 24 01:52:31 saturn kernel: [189085.275313] EXT4-fs (sda1): > > Remounting filesystem read-only > > > > > > The same systems running v4.18.6 never experienced a problem. > > > > Has anyone else seen similar problems ? Is there anything I can do > > to help tracking down the problem ? > > > > Thanks, > > Guenter -- The truth always turns out to be simpler than you thought. Richard Feynman signature.asc Description: This is a digitally signed message part.
Re: ext4 file system corruption with v4.19.3 / v4.19.4
Am Dienstag, 27. November 2018, 15:48:19 schrieb Marek Habersack: > On 27/11/2018 15:32, Guenter Roeck wrote: > Hi, > > You might try to see if you have CONFIG_SCSI_MQ_DEFAULT=yes in your kernel > config. Starting with 4.19.1 it somehow interferes with ext4 and causes > problems similar to the ones you list below. Ever since I disabled MQ > (either recompile your kernel or add `scsi_mod.use_blk_mq=0` to the kernel > command line) none of those errors came back. > > hope it helps, > > marek Unfortunately, this doesn't seem to work in every case: https://bugzilla.kernel.org/show_bug.cgi?id=201685#c54 And I'm using a defconfig-4.19.3 (meaning: CONFIG_SCSI_MQ_DEFAULT=yes) in a VM and I'm not seeing those errors there. OK, it's a VM - but anyway. The definite cause of this can only be found by bisecting, IMO. And it needs to be pinned down because else some feeling of insecurity will remain. So long! Rainer Fiebig > > > [trying again, this time with correct kernel.org address] > > > > Hi, > > > > I have seen the following and similar problems several times, > > with both v4.19.3 and v4.19.4: > > > > Nov 23 04:32:25 mars kernel: [112668.673671] EXT4-fs error (device sdb1): > > ext4_iget:4831: inode #12602889: comm git: bad extra_isize 33661 (inode > > size 256) > > Nov 23 04:32:25 mars kernel: [112668.675217] Aborting journal on device > > sdb1-8. Nov 23 04:32:25 mars kernel: [112668.676681] EXT4-fs (sdb1): > > Remounting filesystem read-only Nov 23 04:32:25 mars kernel: > > [112668.808886] EXT4-fs error (device sdb1): ext4_iget:4831: inode > > #12602881: comm rm: bad extra_isize 33685 (inode size 256) > > ... > > > > Nov 25 00:12:43 saturn kernel: [59377.725984] EXT4-fs error (device sda1): > > ext4_lookup:1578: inode #238034131: comm updatedb.mlocat: deleted inode > > referenced: 238160407 > > Nov 25 00:12:43 saturn kernel: [59377.766638] Aborting journal on device > > sda1-8. Nov 25 00:12:43 saturn kernel: [59377.779372] EXT4-fs (sda1): > > Remounting filesystem read-only ... > > > > Nov 24 01:52:31 saturn kernel: [189085.240016] EXT4-fs error (device > > sda1): ext4_lookup:1578: inode #52038457: comm nfsd: deleted inode > > referenced: 52043796 > > Nov 24 01:52:31 saturn kernel: [189085.263427] Aborting journal on device > > sda1-8. Nov 24 01:52:31 saturn kernel: [189085.275313] EXT4-fs (sda1): > > Remounting filesystem read-only > > > > > > The same systems running v4.18.6 never experienced a problem. > > > > Has anyone else seen similar problems ? Is there anything I can do > > to help tracking down the problem ? > > > > Thanks, > > Guenter -- The truth always turns out to be simpler than you thought. Richard Feynman signature.asc Description: This is a digitally signed message part.
Re: ext4 file system corruption with v4.19.3 / v4.19.4
Am Dienstag, 27. November 2018, 06:32:08 schrieb Guenter Roeck: > [trying again, this time with correct kernel.org address] > > Hi, > > I have seen the following and similar problems several times, > with both v4.19.3 and v4.19.4: > > Nov 23 04:32:25 mars kernel: [112668.673671] EXT4-fs error (device sdb1): > ext4_iget:4831: inode #12602889: comm git: bad extra_isize 33661 (inode > size 256) Nov 23 04:32:25 mars kernel: [112668.675217] Aborting journal on > device sdb1-8. Nov 23 04:32:25 mars kernel: [112668.676681] EXT4-fs (sdb1): > Remounting filesystem read-only Nov 23 04:32:25 mars kernel: > [112668.808886] EXT4-fs error (device sdb1): ext4_iget:4831: inode > #12602881: comm rm: bad extra_isize 33685 (inode size 256) ... > > Nov 25 00:12:43 saturn kernel: [59377.725984] EXT4-fs error (device sda1): > ext4_lookup:1578: inode #238034131: comm updatedb.mlocat: deleted inode > referenced: 238160407 Nov 25 00:12:43 saturn kernel: [59377.766638] > Aborting journal on device sda1-8. Nov 25 00:12:43 saturn kernel: > [59377.779372] EXT4-fs (sda1): Remounting filesystem read-only ... > > Nov 24 01:52:31 saturn kernel: [189085.240016] EXT4-fs error (device sda1): > ext4_lookup:1578: inode #52038457: comm nfsd: deleted inode referenced: > 52043796 Nov 24 01:52:31 saturn kernel: [189085.263427] Aborting journal on > device sda1-8. Nov 24 01:52:31 saturn kernel: [189085.275313] EXT4-fs > (sda1): Remounting filesystem read-only > > > The same systems running v4.18.6 never experienced a problem. > > Has anyone else seen similar problems ? Is there anything I can do > to help tracking down the problem ? > > Thanks, > Guenter This is already being discussed here: https://bugzilla.kernel.org/show_bug.cgi?id=201685 I guess bisecting between 4.18.0 and 4.19.0 by someone who is proficient in this and is affected by the problem would be immensely valuable. I'm not affected and am a bit reluctant to expose my production system to this. ;) So long! Rainer Fiebig -- The truth always turns out to be simpler than you thought. Richard Feynman signature.asc Description: This is a digitally signed message part.
Re: ext4 file system corruption with v4.19.3 / v4.19.4
Am Dienstag, 27. November 2018, 06:32:08 schrieb Guenter Roeck: > [trying again, this time with correct kernel.org address] > > Hi, > > I have seen the following and similar problems several times, > with both v4.19.3 and v4.19.4: > > Nov 23 04:32:25 mars kernel: [112668.673671] EXT4-fs error (device sdb1): > ext4_iget:4831: inode #12602889: comm git: bad extra_isize 33661 (inode > size 256) Nov 23 04:32:25 mars kernel: [112668.675217] Aborting journal on > device sdb1-8. Nov 23 04:32:25 mars kernel: [112668.676681] EXT4-fs (sdb1): > Remounting filesystem read-only Nov 23 04:32:25 mars kernel: > [112668.808886] EXT4-fs error (device sdb1): ext4_iget:4831: inode > #12602881: comm rm: bad extra_isize 33685 (inode size 256) ... > > Nov 25 00:12:43 saturn kernel: [59377.725984] EXT4-fs error (device sda1): > ext4_lookup:1578: inode #238034131: comm updatedb.mlocat: deleted inode > referenced: 238160407 Nov 25 00:12:43 saturn kernel: [59377.766638] > Aborting journal on device sda1-8. Nov 25 00:12:43 saturn kernel: > [59377.779372] EXT4-fs (sda1): Remounting filesystem read-only ... > > Nov 24 01:52:31 saturn kernel: [189085.240016] EXT4-fs error (device sda1): > ext4_lookup:1578: inode #52038457: comm nfsd: deleted inode referenced: > 52043796 Nov 24 01:52:31 saturn kernel: [189085.263427] Aborting journal on > device sda1-8. Nov 24 01:52:31 saturn kernel: [189085.275313] EXT4-fs > (sda1): Remounting filesystem read-only > > > The same systems running v4.18.6 never experienced a problem. > > Has anyone else seen similar problems ? Is there anything I can do > to help tracking down the problem ? > > Thanks, > Guenter This is already being discussed here: https://bugzilla.kernel.org/show_bug.cgi?id=201685 I guess bisecting between 4.18.0 and 4.19.0 by someone who is proficient in this and is affected by the problem would be immensely valuable. I'm not affected and am a bit reluctant to expose my production system to this. ;) So long! Rainer Fiebig -- The truth always turns out to be simpler than you thought. Richard Feynman signature.asc Description: This is a digitally signed message part.
Re: Linux 4.9.139
Am Freitag, 23. November 2018, 08:47:31 schrieb Greg KH: > I'm announcing the release of the 4.9.139 kernel. > > All users of the 4.9 kernel series must upgrade. > > The updated 4.9.y git tree can be found at: > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git > linux-4.9.y and can be browsed at the normal kernel.org git web browser: > > http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary > > thanks, > > greg k-h > Just *in case* this was an oversight: STIBP is still active in 4.9.139. Not that I would mind because for my modest Core i3 that I mainly use for office-work I don't see *any* difference in performance compared to 4.9.136 (no STIBP). So long! Rainer Fiebig > > > .gitignore|1 > Kbuild| 25 > Makefile | 27 +++- > arch/arm/include/asm/assembler.h | 12 ++ > arch/arm/include/asm/barrier.h| 32 + > arch/arm/include/asm/bugs.h |6 - > arch/arm/include/asm/cp15.h |3 > arch/arm/include/asm/cputype.h|8 + > arch/arm/include/asm/kvm_asm.h|2 > arch/arm/include/asm/kvm_host.h | 14 ++ > arch/arm/include/asm/kvm_mmu.h| 23 +++ > arch/arm/include/asm/proc-fns.h |4 > arch/arm/include/asm/system_misc.h| 15 ++ > arch/arm/include/asm/thread_info.h|4 > arch/arm/include/asm/uaccess.h| 26 +++- > arch/arm/kernel/Makefile |1 > arch/arm/kernel/bugs.c| 18 +++ > arch/arm/kernel/entry-common.S| 18 +-- > arch/arm/kernel/entry-header.S| 25 > arch/arm/kernel/signal.c | 55 + > arch/arm/kernel/smp.c |4 > arch/arm/kernel/suspend.c |2 > arch/arm/kernel/sys_oabi-compat.c |8 - > arch/arm/kvm/hyp/hyp-entry.S | 112 ++- > arch/arm/lib/copy_from_user.S |9 + > arch/arm/mm/Kconfig | 23 +++ > arch/arm/mm/Makefile |2 > arch/arm/mm/fault.c |3 > arch/arm/mm/proc-macros.S |3 > arch/arm/mm/proc-v7-2level.S |6 - > arch/arm/mm/proc-v7-bugs.c| 174 > ++ arch/arm/mm/proc-v7.S | > 154 +- arch/arm/vfp/vfpmodule.c | > 17 +- > arch/arm64/crypto/sha1-ce-core.S |6 - > arch/arm64/crypto/sha1-ce-glue.c | 11 - > arch/arm64/crypto/sha2-ce-core.S |6 - > arch/arm64/crypto/sha2-ce-glue.c | 13 -- > arch/arm64/include/asm/efi.h |3 > arch/arm64/include/asm/uaccess.h |4 > arch/ia64/kernel/Makefile | 26 > arch/x86/Makefile | 39 +- > arch/x86/boot/string.c|9 + > arch/x86/crypto/aes_ctrby8_avx-x86_64.S |7 - > drivers/firmware/efi/libstub/Makefile | 26 ++-- > drivers/firmware/efi/libstub/arm64-stub.c | 10 + > drivers/net/ethernet/broadcom/tg3.c | 18 ++- > drivers/net/usb/smsc95xx.c|7 + > drivers/xen/Makefile |3 > include/linux/kbuild.h|6 - > include/linux/module.h|4 > net/core/dev.c|4 > net/core/flow_dissector.c |4 > net/ipv4/inet_fragment.c | 28 ++-- > net/ipv4/ip_tunnel_core.c |2 > net/ipv6/route.c |7 - > net/sctp/socket.c | 26 > scripts/Kbuild.include| 18 ++- > scripts/Makefile.build|8 + > scripts/Makefile.extrawarn|1 > scripts/Makefile.host |6 - > scripts/Makefile.lib | 31 + > scripts/mod/Makefile | 28 > 62 files changed, 901 insertions(+), 296 deletions(-) > > Ard Biesheuvel (5): > crypto: arm64/sha - avoid non-standard inline asm tricks > efi/libstub/arm64: Use hidden attribute for struct screen_info > reference efi/libstub/arm64: Force 'hidden' visibility for section markers > efi/libstub: Preserve .debug sections after absolute relocation check > efi/libstub/arm64: Set -fpie when building the EFI stub > > Arnd Bergmann (2): > modules: mark __inittest/__exittest as __maybe_unused >
Re: Linux 4.9.139
Am Freitag, 23. November 2018, 08:47:31 schrieb Greg KH: > I'm announcing the release of the 4.9.139 kernel. > > All users of the 4.9 kernel series must upgrade. > > The updated 4.9.y git tree can be found at: > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git > linux-4.9.y and can be browsed at the normal kernel.org git web browser: > > http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary > > thanks, > > greg k-h > Just *in case* this was an oversight: STIBP is still active in 4.9.139. Not that I would mind because for my modest Core i3 that I mainly use for office-work I don't see *any* difference in performance compared to 4.9.136 (no STIBP). So long! Rainer Fiebig > > > .gitignore|1 > Kbuild| 25 > Makefile | 27 +++- > arch/arm/include/asm/assembler.h | 12 ++ > arch/arm/include/asm/barrier.h| 32 + > arch/arm/include/asm/bugs.h |6 - > arch/arm/include/asm/cp15.h |3 > arch/arm/include/asm/cputype.h|8 + > arch/arm/include/asm/kvm_asm.h|2 > arch/arm/include/asm/kvm_host.h | 14 ++ > arch/arm/include/asm/kvm_mmu.h| 23 +++ > arch/arm/include/asm/proc-fns.h |4 > arch/arm/include/asm/system_misc.h| 15 ++ > arch/arm/include/asm/thread_info.h|4 > arch/arm/include/asm/uaccess.h| 26 +++- > arch/arm/kernel/Makefile |1 > arch/arm/kernel/bugs.c| 18 +++ > arch/arm/kernel/entry-common.S| 18 +-- > arch/arm/kernel/entry-header.S| 25 > arch/arm/kernel/signal.c | 55 + > arch/arm/kernel/smp.c |4 > arch/arm/kernel/suspend.c |2 > arch/arm/kernel/sys_oabi-compat.c |8 - > arch/arm/kvm/hyp/hyp-entry.S | 112 ++- > arch/arm/lib/copy_from_user.S |9 + > arch/arm/mm/Kconfig | 23 +++ > arch/arm/mm/Makefile |2 > arch/arm/mm/fault.c |3 > arch/arm/mm/proc-macros.S |3 > arch/arm/mm/proc-v7-2level.S |6 - > arch/arm/mm/proc-v7-bugs.c| 174 > ++ arch/arm/mm/proc-v7.S | > 154 +- arch/arm/vfp/vfpmodule.c | > 17 +- > arch/arm64/crypto/sha1-ce-core.S |6 - > arch/arm64/crypto/sha1-ce-glue.c | 11 - > arch/arm64/crypto/sha2-ce-core.S |6 - > arch/arm64/crypto/sha2-ce-glue.c | 13 -- > arch/arm64/include/asm/efi.h |3 > arch/arm64/include/asm/uaccess.h |4 > arch/ia64/kernel/Makefile | 26 > arch/x86/Makefile | 39 +- > arch/x86/boot/string.c|9 + > arch/x86/crypto/aes_ctrby8_avx-x86_64.S |7 - > drivers/firmware/efi/libstub/Makefile | 26 ++-- > drivers/firmware/efi/libstub/arm64-stub.c | 10 + > drivers/net/ethernet/broadcom/tg3.c | 18 ++- > drivers/net/usb/smsc95xx.c|7 + > drivers/xen/Makefile |3 > include/linux/kbuild.h|6 - > include/linux/module.h|4 > net/core/dev.c|4 > net/core/flow_dissector.c |4 > net/ipv4/inet_fragment.c | 28 ++-- > net/ipv4/ip_tunnel_core.c |2 > net/ipv6/route.c |7 - > net/sctp/socket.c | 26 > scripts/Kbuild.include| 18 ++- > scripts/Makefile.build|8 + > scripts/Makefile.extrawarn|1 > scripts/Makefile.host |6 - > scripts/Makefile.lib | 31 + > scripts/mod/Makefile | 28 > 62 files changed, 901 insertions(+), 296 deletions(-) > > Ard Biesheuvel (5): > crypto: arm64/sha - avoid non-standard inline asm tricks > efi/libstub/arm64: Use hidden attribute for struct screen_info > reference efi/libstub/arm64: Force 'hidden' visibility for section markers > efi/libstub: Preserve .debug sections after absolute relocation check > efi/libstub/arm64: Set -fpie when building the EFI stub > > Arnd Bergmann (2): > modules: mark __inittest/__exittest as __maybe_unused >
Re: Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document
NeilBrown schrieb: > On Fri, Oct 26 2018, Rainer Fiebig wrote: > >> NeilBrown schrieb: >>> On Thu, Oct 25 2018, Rainer Fiebig wrote: >>> >>>> Am Montag, 22. Oktober 2018, 08:20:11 schrieb NeilBrown: >>>>> On Sat, Oct 20 2018, Greg Kroah-Hartman wrote: >>>>>> Hi all, >>>>>> >>>>>> As everyone knows by now, we added a new Code of Conduct to the kernel >>>>>> tree a few weeks ago. >>>>> >>>>> I wanted to stay detached from all this, but as remaining (publicly) >>>>> silent might be seen (publicly) as acquiescing, I hereby declare that: >>>>>I reject, as illegitimate, this Code and the process by >>>>>which it is being "developed". >>>>> >>>>> It is clear from the surrounding discussions that this is well outside our >>>>> core competencies. It will be flawed, it isn't what we need. >>>>> >>>>> I call on any other community members who reject this process to say so, >>>>> not to remain silent. >>>>> #Iobject >>>>> >>>>> We don't need a "Code of Conduct" nearly as much as we need "Leadership >>>>> in conduct". Without the leadership, any code looks like a joke. >>>>> >>>> [...] >>>> >>>>> I call on you, Greg: >>>>> - to abandon this divisive attempt to impose a "Code of Conduct" >>>>> - to revert 8a104f8b5867c68 >>>> >>>> Yes but this seems increasingly unlikely now. However, there may be an >>>> alternative. >>>> >>>> Jugding by the release-message for 4.19, some people here are fans of >>>> Monty Python's. No wonder - as those guys are famous for being unrelenting >>>> supporters of Political Correctness. >>>> >>>> So one would be on the safe side if one just supplemented "Our Pledge" >>>> with this: >>>> >>>>"Everybody has the right to be offended." >>>> >>>> I think, John Cleese would also welcome this.[1] >>>> >>>> What do you think? >>> >>> I do think that giving certain rights to the community is a good thing: >>> - the right to tell anyone that their speech is hurtful >>> - the right to (patch) review by a third party. >>> >>> I don't think the right to be offended really needs to be given. >>> Yes, I know it is a joke and I do like Monty Python. I just don't think >>> it is particular helpful in this context. Maybe I missed something. >> >> Of course it's a joke and iirc it was indeed John Cleese who made it. But he >> made it for a reason, out of concern. It has a serious core. >> >> The question is: what *is* helpful in this matter? >> >> Just saying "this is not helpful" isn't helpful either. It's a well-known >> killer-phrase that has been used ad nauseam in this discussion. But an >> alternative is never given. And thus it's just an other way of saying >> "Eat it. And shut tf up!" > > You asked me what I thought, and I told you what I thought. > If you think differently, you are quite welcome tell us - to explain the > way in which you think the addition would be helpful. > Neil, this is probably a misunderstanding. I really value your initiative and dedication in this matter. My suggestion of adding the "right to be offended" was of course just a sarcastic joke. I thought this was obvious, especially since I provided the link to the interview with John Cleese. But it wasn't obvious to you and I'm sorry for that. BTW - it just strikes me: perhaps this endless enumeration of protected/privileged classes was also just a joke and *I* didn't see it? ;) OK. "Not helpful": This is indeed a killer-phrase used to suppress critique and to silence people. I just wanted to expose this. It was not directed at *you*. That's why I began my critique with >> "The question is: what *is* helpful in this matter?" >> >> Not even *constructive* criticism is helpful. AFAIK I'm the only one here who >> came up with a *complete* alternative - ignored. Others provided patches for >> certain sections - ignored. Data that indicate that this may be detrimental >> to >> Linux - ignored. Almost anything that was provided by me or others - ignored. > > From my perspective, providing a complete alternative is no better than > what Greg did - provided a "comple
Re: Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document
NeilBrown schrieb: > On Fri, Oct 26 2018, Rainer Fiebig wrote: > >> NeilBrown schrieb: >>> On Thu, Oct 25 2018, Rainer Fiebig wrote: >>> >>>> Am Montag, 22. Oktober 2018, 08:20:11 schrieb NeilBrown: >>>>> On Sat, Oct 20 2018, Greg Kroah-Hartman wrote: >>>>>> Hi all, >>>>>> >>>>>> As everyone knows by now, we added a new Code of Conduct to the kernel >>>>>> tree a few weeks ago. >>>>> >>>>> I wanted to stay detached from all this, but as remaining (publicly) >>>>> silent might be seen (publicly) as acquiescing, I hereby declare that: >>>>>I reject, as illegitimate, this Code and the process by >>>>>which it is being "developed". >>>>> >>>>> It is clear from the surrounding discussions that this is well outside our >>>>> core competencies. It will be flawed, it isn't what we need. >>>>> >>>>> I call on any other community members who reject this process to say so, >>>>> not to remain silent. >>>>> #Iobject >>>>> >>>>> We don't need a "Code of Conduct" nearly as much as we need "Leadership >>>>> in conduct". Without the leadership, any code looks like a joke. >>>>> >>>> [...] >>>> >>>>> I call on you, Greg: >>>>> - to abandon this divisive attempt to impose a "Code of Conduct" >>>>> - to revert 8a104f8b5867c68 >>>> >>>> Yes but this seems increasingly unlikely now. However, there may be an >>>> alternative. >>>> >>>> Jugding by the release-message for 4.19, some people here are fans of >>>> Monty Python's. No wonder - as those guys are famous for being unrelenting >>>> supporters of Political Correctness. >>>> >>>> So one would be on the safe side if one just supplemented "Our Pledge" >>>> with this: >>>> >>>>"Everybody has the right to be offended." >>>> >>>> I think, John Cleese would also welcome this.[1] >>>> >>>> What do you think? >>> >>> I do think that giving certain rights to the community is a good thing: >>> - the right to tell anyone that their speech is hurtful >>> - the right to (patch) review by a third party. >>> >>> I don't think the right to be offended really needs to be given. >>> Yes, I know it is a joke and I do like Monty Python. I just don't think >>> it is particular helpful in this context. Maybe I missed something. >> >> Of course it's a joke and iirc it was indeed John Cleese who made it. But he >> made it for a reason, out of concern. It has a serious core. >> >> The question is: what *is* helpful in this matter? >> >> Just saying "this is not helpful" isn't helpful either. It's a well-known >> killer-phrase that has been used ad nauseam in this discussion. But an >> alternative is never given. And thus it's just an other way of saying >> "Eat it. And shut tf up!" > > You asked me what I thought, and I told you what I thought. > If you think differently, you are quite welcome tell us - to explain the > way in which you think the addition would be helpful. > Neil, this is probably a misunderstanding. I really value your initiative and dedication in this matter. My suggestion of adding the "right to be offended" was of course just a sarcastic joke. I thought this was obvious, especially since I provided the link to the interview with John Cleese. But it wasn't obvious to you and I'm sorry for that. BTW - it just strikes me: perhaps this endless enumeration of protected/privileged classes was also just a joke and *I* didn't see it? ;) OK. "Not helpful": This is indeed a killer-phrase used to suppress critique and to silence people. I just wanted to expose this. It was not directed at *you*. That's why I began my critique with >> "The question is: what *is* helpful in this matter?" >> >> Not even *constructive* criticism is helpful. AFAIK I'm the only one here who >> came up with a *complete* alternative - ignored. Others provided patches for >> certain sections - ignored. Data that indicate that this may be detrimental >> to >> Linux - ignored. Almost anything that was provided by me or others - ignored. > > From my perspective, providing a complete alternative is no better than > what Greg did - provided a "comple
Re: Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document
NeilBrown schrieb: > On Thu, Oct 25 2018, Rainer Fiebig wrote: > >> Am Montag, 22. Oktober 2018, 08:20:11 schrieb NeilBrown: >>> On Sat, Oct 20 2018, Greg Kroah-Hartman wrote: >>>> Hi all, >>>> >>>> As everyone knows by now, we added a new Code of Conduct to the kernel >>>> tree a few weeks ago. >>> >>> I wanted to stay detached from all this, but as remaining (publicly) >>> silent might be seen (publicly) as acquiescing, I hereby declare that: >>>I reject, as illegitimate, this Code and the process by >>>which it is being "developed". >>> >>> It is clear from the surrounding discussions that this is well outside our >>> core competencies. It will be flawed, it isn't what we need. >>> >>> I call on any other community members who reject this process to say so, >>> not to remain silent. >>> #Iobject >>> >>> We don't need a "Code of Conduct" nearly as much as we need "Leadership >>> in conduct". Without the leadership, any code looks like a joke. >>> >> [...] >> >>> I call on you, Greg: >>> - to abandon this divisive attempt to impose a "Code of Conduct" >>> - to revert 8a104f8b5867c68 >> >> Yes but this seems increasingly unlikely now. However, there may be an >> alternative. >> >> Jugding by the release-message for 4.19, some people here are fans of >> Monty Python's. No wonder - as those guys are famous for being unrelenting >> supporters of Political Correctness. >> >> So one would be on the safe side if one just supplemented "Our Pledge" >> with this: >> >> "Everybody has the right to be offended." >> >> I think, John Cleese would also welcome this.[1] >> >> What do you think? > > I do think that giving certain rights to the community is a good thing: > - the right to tell anyone that their speech is hurtful > - the right to (patch) review by a third party. > > I don't think the right to be offended really needs to be given. > Yes, I know it is a joke and I do like Monty Python. I just don't think > it is particular helpful in this context. Maybe I missed something. Of course it's a joke and iirc it was indeed John Cleese who made it. But he made it for a reason, out of concern. It has a serious core. The question is: what *is* helpful in this matter? Just saying "this is not helpful" isn't helpful either. It's a well-known killer-phrase that has been used ad nauseam in this discussion. But an alternative is never given. And thus it's just an other way of saying "Eat it. And shut tf up!" Not even *constructive* criticism is helpful. AFAIK I'm the only one here who came up with a *complete* alternative - ignored. Others provided patches for certain sections - ignored. Data that indicate that this may be detrimental to Linux - ignored. Almost anything that was provided by me or others - ignored. What kind of community or attitude is this? This feels more like "The Wall" or North Korea than an Open-Source-project. And what beat everything was to misuse famously politically *in*correct Monty Python to malign criticism of this Political-Correctness-monster. The "People's Front" - message will forever be a prominent exhibit in "Monty Python's Hall of Shame". And the author should be banned from laughing about MP-sketches until he recants. Perhaps one should also report this incident to the "Ministry of Silly CoCs". ;) > For myself, I relinquish my right to be offended. I just don't do it. > It doesn't seem to be worth the effort. I don't. John Cleese is a smart guy. And he has a point. OK, thanks for your reply! But I think it's time for me to move on. "Cut your losses", as they say. Good luck and regards! Rainer Fiebig signature.asc Description: OpenPGP digital signature
Re: Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document
NeilBrown schrieb: > On Thu, Oct 25 2018, Rainer Fiebig wrote: > >> Am Montag, 22. Oktober 2018, 08:20:11 schrieb NeilBrown: >>> On Sat, Oct 20 2018, Greg Kroah-Hartman wrote: >>>> Hi all, >>>> >>>> As everyone knows by now, we added a new Code of Conduct to the kernel >>>> tree a few weeks ago. >>> >>> I wanted to stay detached from all this, but as remaining (publicly) >>> silent might be seen (publicly) as acquiescing, I hereby declare that: >>>I reject, as illegitimate, this Code and the process by >>>which it is being "developed". >>> >>> It is clear from the surrounding discussions that this is well outside our >>> core competencies. It will be flawed, it isn't what we need. >>> >>> I call on any other community members who reject this process to say so, >>> not to remain silent. >>> #Iobject >>> >>> We don't need a "Code of Conduct" nearly as much as we need "Leadership >>> in conduct". Without the leadership, any code looks like a joke. >>> >> [...] >> >>> I call on you, Greg: >>> - to abandon this divisive attempt to impose a "Code of Conduct" >>> - to revert 8a104f8b5867c68 >> >> Yes but this seems increasingly unlikely now. However, there may be an >> alternative. >> >> Jugding by the release-message for 4.19, some people here are fans of >> Monty Python's. No wonder - as those guys are famous for being unrelenting >> supporters of Political Correctness. >> >> So one would be on the safe side if one just supplemented "Our Pledge" >> with this: >> >> "Everybody has the right to be offended." >> >> I think, John Cleese would also welcome this.[1] >> >> What do you think? > > I do think that giving certain rights to the community is a good thing: > - the right to tell anyone that their speech is hurtful > - the right to (patch) review by a third party. > > I don't think the right to be offended really needs to be given. > Yes, I know it is a joke and I do like Monty Python. I just don't think > it is particular helpful in this context. Maybe I missed something. Of course it's a joke and iirc it was indeed John Cleese who made it. But he made it for a reason, out of concern. It has a serious core. The question is: what *is* helpful in this matter? Just saying "this is not helpful" isn't helpful either. It's a well-known killer-phrase that has been used ad nauseam in this discussion. But an alternative is never given. And thus it's just an other way of saying "Eat it. And shut tf up!" Not even *constructive* criticism is helpful. AFAIK I'm the only one here who came up with a *complete* alternative - ignored. Others provided patches for certain sections - ignored. Data that indicate that this may be detrimental to Linux - ignored. Almost anything that was provided by me or others - ignored. What kind of community or attitude is this? This feels more like "The Wall" or North Korea than an Open-Source-project. And what beat everything was to misuse famously politically *in*correct Monty Python to malign criticism of this Political-Correctness-monster. The "People's Front" - message will forever be a prominent exhibit in "Monty Python's Hall of Shame". And the author should be banned from laughing about MP-sketches until he recants. Perhaps one should also report this incident to the "Ministry of Silly CoCs". ;) > For myself, I relinquish my right to be offended. I just don't do it. > It doesn't seem to be worth the effort. I don't. John Cleese is a smart guy. And he has a point. OK, thanks for your reply! But I think it's time for me to move on. "Cut your losses", as they say. Good luck and regards! Rainer Fiebig signature.asc Description: OpenPGP digital signature
Re: Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document
Am Montag, 22. Oktober 2018, 08:20:11 schrieb NeilBrown:
> On Sat, Oct 20 2018, Greg Kroah-Hartman wrote:
> > Hi all,
> >
> > As everyone knows by now, we added a new Code of Conduct to the kernel
> > tree a few weeks ago.
>
> I wanted to stay detached from all this, but as remaining (publicly)
> silent might be seen (publicly) as acquiescing, I hereby declare that:
>I reject, as illegitimate, this Code and the process by
>which it is being "developed".
>
> It is clear from the surrounding discussions that this is well outside our
> core competencies. It will be flawed, it isn't what we need.
>
> I call on any other community members who reject this process to say so,
> not to remain silent.
> #Iobject
>
> We don't need a "Code of Conduct" nearly as much as we need "Leadership
> in conduct". Without the leadership, any code looks like a joke.
>
[...]
> I call on you, Greg:
> - to abandon this divisive attempt to impose a "Code of Conduct"
> - to revert 8a104f8b5867c68
Yes but this seems increasingly unlikely now. However, there may be an
alternative.
Jugding by the release-message for 4.19, some people here are fans of
Monty Python's. No wonder - as those guys are famous for being unrelenting
supporters of Political Correctness.
So one would be on the safe side if one just supplemented "Our Pledge"
with this:
"Everybody has the right to be offended."
I think, John Cleese would also welcome this.[1]
What do you think?
Regards!
Rainer Fiebig
[1]
https://www.dailymail.co.uk/news/article-3427218/Political-correctness-killing-comedy-says-John-Cleese-Monty-Python-star-believes-fear-offending-certain-groups-lead-1984-style-society-free-expression-not-allowed.html
--
The truth always turns out to be simpler than you thought.
Richard Feynman
signature.asc
Description: This is a digitally signed message part.
Re: Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document
Am Montag, 22. Oktober 2018, 08:20:11 schrieb NeilBrown:
> On Sat, Oct 20 2018, Greg Kroah-Hartman wrote:
> > Hi all,
> >
> > As everyone knows by now, we added a new Code of Conduct to the kernel
> > tree a few weeks ago.
>
> I wanted to stay detached from all this, but as remaining (publicly)
> silent might be seen (publicly) as acquiescing, I hereby declare that:
>I reject, as illegitimate, this Code and the process by
>which it is being "developed".
>
> It is clear from the surrounding discussions that this is well outside our
> core competencies. It will be flawed, it isn't what we need.
>
> I call on any other community members who reject this process to say so,
> not to remain silent.
> #Iobject
>
> We don't need a "Code of Conduct" nearly as much as we need "Leadership
> in conduct". Without the leadership, any code looks like a joke.
>
[...]
> I call on you, Greg:
> - to abandon this divisive attempt to impose a "Code of Conduct"
> - to revert 8a104f8b5867c68
Yes but this seems increasingly unlikely now. However, there may be an
alternative.
Jugding by the release-message for 4.19, some people here are fans of
Monty Python's. No wonder - as those guys are famous for being unrelenting
supporters of Political Correctness.
So one would be on the safe side if one just supplemented "Our Pledge"
with this:
"Everybody has the right to be offended."
I think, John Cleese would also welcome this.[1]
What do you think?
Regards!
Rainer Fiebig
[1]
https://www.dailymail.co.uk/news/article-3427218/Political-correctness-killing-comedy-says-John-Cleese-Monty-Python-star-believes-fear-offending-certain-groups-lead-1984-style-society-free-expression-not-allowed.html
--
The truth always turns out to be simpler than you thought.
Richard Feynman
signature.asc
Description: This is a digitally signed message part.
Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document
Theodore Y. Ts'o schrieb:
> On Tue, Oct 23, 2018 at 04:22:54PM +0200, Rainer Fiebig wrote:
>>
>> And whether that CoC does come with a political agenda or is just being
>> *perceived* so, is irrelevant: the perception *is* the reality. And by
>> embracing this CoC, Linux is now being perceived as also supporting the
>> agenda
>> that comes with it. But perhaps that was intended?
>>
>> In my view you now have a new, probably even bigger problem: namely that by
>> adopting *this* CoC and by unyieldingly clinging to it, you have alienated
>> many, if not the majority of loyal Linux-users/supporters.
>
> Citation Needed: What's your *proof* the majority of Linux
> users/supports have been alienated? Many people have actually been
> quite supportive of the CoC.
>
Ah, come on. Proof? Do you have any hard data to underpin your assertion of
"many"?
That it *may* be the majority is the impression I got from the many
discussions that I have seen, I haven't counted the pro- and con-comments.
But I've found a little poll at "Pro-Linux", small sample, no way
representative but accessible only for registered users.[1]
The question was: "The new Code of Conduct: Good or bad for Linux?"
- Brings Linux sympathies and support: 11%
- Costs linux sympathies and support: 57%
- Will have no impact: 32%
- Nothing of this, but: 0%
I wouldn't call this "proof" but a worrisome indication nevertheless,
especially if you consider the name of the site.
> And perception is a funny thing. I have no doubt that there are
> people who will claim that some CoC's that might more be acceptable to
> you would be "useless" or "means nothing". (Note how simply removing
> three lines that troubled ***many*** Maintainers caused Josh to
> complain that it ruined the CoC). And there are others for whom the
> Contributor's Convenant automatically seems to mean kangaroo courts
> and harsh punishments with no accountability for minor issues. I
> suspect that both you *and* Josh are unhappy, in opposite directions,
> might be a hint that we've mostly gotten things right.
>
I find Josh's position rather extreme - for him it seems to be "All or nothing".
On the other hand, I've already made a proposal that is not too far from what
you have now - without the political sting. Doesn't mean you should use it.
So personally, I would be content already if you modified the first sentence
in the way that has been suggested by others here several times.
Less would be more.
> Another example of this is that zero-day testing bot changed its
> message in order to be more welcoming to newcomers. ("Thank you for
> the patch! Yet something to improve...".) At the Maintainer's Summit,
> someone from Germany pointed out that in European and especially
> German cultures, being ultra polite is often a signal that the person
> is considered stupid/incompetent, and he actually viewed it the change
> in the testing bot as making it be *less* welcoming, not *more*. Not
> that he cared, because he has a thick skin and after all, it's only a
> 'bot --- but in his view he thought it was quite funny that the change
> was welcomed by some as being an improvement when he viewed it
> completely the other way 'round.
>
Perhaps not *less* welcoming but yes, you might get the impression that this
bot wants to take you on a ride. :)
> Ultimately, we are a world-wide effort, and it's really hard to
> predict or control how people from different cultures will perceive an
> e-mail or some document. That doesn't mean we shouldn't *try*, and
> there may very well be times when someone will file a complaint for
> what is perceived to be a Code of Conduct which is really a
> misunderstanding due to a cultural mismatch. (And *obviously* that's
> not a CoC violation either, despite some people trying to spread FUD
> by making the case that it would be.)
>
>> In my view, the Linux-CoC stands for exactly that sort of extreme "Political
>> Correctness" that is infesting our societies and has proven its destructive
>> nature in more than enough instances. For some examples see [1][2][3][4][5].
>>
>>
>> To me it feels more and more like the dark times of witch-hunts are back or
>> when it was politically in-correct to say that the earth revolves around the
>> sun. In those days offenders like Galilei were at least offered the choice
>> between recanting and the funeral-pile. Today you may recant but you get
>> publicly burnt anyway.
>
> Yeah, and that's precisely the FUD that I'm talking about. I
> understand that is your view. Let's see if it's actually true. I
FUD? What happened to those g
Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document
Theodore Y. Ts'o schrieb:
> On Tue, Oct 23, 2018 at 04:22:54PM +0200, Rainer Fiebig wrote:
>>
>> And whether that CoC does come with a political agenda or is just being
>> *perceived* so, is irrelevant: the perception *is* the reality. And by
>> embracing this CoC, Linux is now being perceived as also supporting the
>> agenda
>> that comes with it. But perhaps that was intended?
>>
>> In my view you now have a new, probably even bigger problem: namely that by
>> adopting *this* CoC and by unyieldingly clinging to it, you have alienated
>> many, if not the majority of loyal Linux-users/supporters.
>
> Citation Needed: What's your *proof* the majority of Linux
> users/supports have been alienated? Many people have actually been
> quite supportive of the CoC.
>
Ah, come on. Proof? Do you have any hard data to underpin your assertion of
"many"?
That it *may* be the majority is the impression I got from the many
discussions that I have seen, I haven't counted the pro- and con-comments.
But I've found a little poll at "Pro-Linux", small sample, no way
representative but accessible only for registered users.[1]
The question was: "The new Code of Conduct: Good or bad for Linux?"
- Brings Linux sympathies and support: 11%
- Costs linux sympathies and support: 57%
- Will have no impact: 32%
- Nothing of this, but: 0%
I wouldn't call this "proof" but a worrisome indication nevertheless,
especially if you consider the name of the site.
> And perception is a funny thing. I have no doubt that there are
> people who will claim that some CoC's that might more be acceptable to
> you would be "useless" or "means nothing". (Note how simply removing
> three lines that troubled ***many*** Maintainers caused Josh to
> complain that it ruined the CoC). And there are others for whom the
> Contributor's Convenant automatically seems to mean kangaroo courts
> and harsh punishments with no accountability for minor issues. I
> suspect that both you *and* Josh are unhappy, in opposite directions,
> might be a hint that we've mostly gotten things right.
>
I find Josh's position rather extreme - for him it seems to be "All or nothing".
On the other hand, I've already made a proposal that is not too far from what
you have now - without the political sting. Doesn't mean you should use it.
So personally, I would be content already if you modified the first sentence
in the way that has been suggested by others here several times.
Less would be more.
> Another example of this is that zero-day testing bot changed its
> message in order to be more welcoming to newcomers. ("Thank you for
> the patch! Yet something to improve...".) At the Maintainer's Summit,
> someone from Germany pointed out that in European and especially
> German cultures, being ultra polite is often a signal that the person
> is considered stupid/incompetent, and he actually viewed it the change
> in the testing bot as making it be *less* welcoming, not *more*. Not
> that he cared, because he has a thick skin and after all, it's only a
> 'bot --- but in his view he thought it was quite funny that the change
> was welcomed by some as being an improvement when he viewed it
> completely the other way 'round.
>
Perhaps not *less* welcoming but yes, you might get the impression that this
bot wants to take you on a ride. :)
> Ultimately, we are a world-wide effort, and it's really hard to
> predict or control how people from different cultures will perceive an
> e-mail or some document. That doesn't mean we shouldn't *try*, and
> there may very well be times when someone will file a complaint for
> what is perceived to be a Code of Conduct which is really a
> misunderstanding due to a cultural mismatch. (And *obviously* that's
> not a CoC violation either, despite some people trying to spread FUD
> by making the case that it would be.)
>
>> In my view, the Linux-CoC stands for exactly that sort of extreme "Political
>> Correctness" that is infesting our societies and has proven its destructive
>> nature in more than enough instances. For some examples see [1][2][3][4][5].
>>
>>
>> To me it feels more and more like the dark times of witch-hunts are back or
>> when it was politically in-correct to say that the earth revolves around the
>> sun. In those days offenders like Galilei were at least offered the choice
>> between recanting and the funeral-pile. Today you may recant but you get
>> publicly burnt anyway.
>
> Yeah, and that's precisely the FUD that I'm talking about. I
> understand that is your view. Let's see if it's actually true. I
FUD? What happened to those g
Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document
Am Dienstag, 23. Oktober 2018, 04:11:44 schrieb Theodore Y. Ts'o: > On Tue, Oct 23, 2018 at 03:25:08PM +1100, NeilBrown wrote: > > Yes, you could, and you can. But if it was Linus who was behaving > > inappropriately, where did you go then? This is why I think whatever > > "code" we have should be overtly a statement Linus makes about his > > behaviour, in the first instance. > > You're still missing the point, and the problem. The concern was not > *that* a patch was rejected, it was in *how* the patch was rejected. And to solve *this* problem a highly controversial and politically charged CoC had to be introduced that has already begun to divide the wider community? Seems like a bit of an overkill to me. And whether that CoC does come with a political agenda or is just being *perceived* so, is irrelevant: the perception *is* the reality. And by embracing this CoC, Linux is now being perceived as also supporting the agenda that comes with it. But perhaps that was intended? In my view you now have a new, probably even bigger problem: namely that by adopting *this* CoC and by unyieldingly clinging to it, you have alienated many, if not the majority of loyal Linux-users/supporters. Bad choice and bad timing, now that Linux seemed ready to also take off in the desktop-area. > The "problem" has never been about how Linus was treating anyone other > than core maintainers; i.e., most of the rants that I can think of (a) > happened years of ago, and (b) were directed at the sort of people who > were in the room at the Maintainer's Summit yesterday. Who which, by > the way, didn't have a complaint about Linus's recent behavior; in > fact, there was general agreement that Linus's behavior has been > getting *better* over the last few years. > > One of the more important effects of the CoC is that newcomers have a > fear about Linux's reputation of having extremely toxic community. > There is a narrative that has been constructed that because Linus > behaves badly to everyone; and this gives everyone "permission" to > behave badly. Regardless of how true it may have been in the past, I > believe that it is largely obsolete today. And so, the mere existence > of a CoC has caused some newcomers to say that they have "already > noticed a difference" --- which is IMO mostly the effect of CoC easing > fears, as opposed to any real change in Linux community in the past > four weeks. > > I think how it will work out in practice is that the CoC will be more > a commitment about what we are holding up as community norms. > Unfortunately, for some poeple the term "CoC" apparently acts as > trigger language and it brings to mind legal proceedings, > unaccountable court-like entities, and hammering people with > punishments for petty issues with no appeal or recourse. > I think you're wrong here. It's not the term "CoC" as such that brings up the negative associations. It is the specific choice of the CoC and its wording that does. And quite a few people have pointed this out already. Mitigations and alternatives had been offered but were ignored. > Perhaps this is why other communities have elected to use terms such > as "How to do Samba: Nicely" and "GNU Kind Communication Guidelines". > All of these are trying to solve the same issue, and so my suggestion > is let's just wait and see how things go. If people continue to see > that the community has "changed" for the better, and other people see > that we're not hammering people with sanctions, but rather reminding > each other about the kind of community we aspire to be, it'll all be > good. > > - Ted Those other communities have not just chosen other terms but also chosen other approaches and wordings. In my view, the Linux-CoC stands for exactly that sort of extreme "Political Correctness" that is infesting our societies and has proven its destructive nature in more than enough instances. For some examples see [1][2][3][4][5]. To me it feels more and more like the dark times of witch-hunts are back or when it was politically in-correct to say that the earth revolves around the sun. In those days offenders like Galilei were at least offered the choice between recanting and the funeral-pile. Today you may recant but you get publicly burnt anyway. To see Linux falling for this is a sorry sight. Rainer Fiebig *** [1] https://www.ibtimes.co.uk/sacked-nobel-prize-winning-scientist-sir-tim-hunt-gets-backing-eight-fellow-laureates-1507096 [2] https://www.telegraph.co.uk/news/science/science-news/12057365/Sir-Tim-Hunt-to-leave-Britain-for-Japan-after-sexism-row.html [3] https://en.wikipedia.org/wiki/Tim_Hunt#The_toast [4] https://www.bbc.com/news/world-europe-45703700 [5] https://www.bbc.com/news/world-us-canada-45789819 -- The truth always turns out to be simpler than you thought. Richard Feynman
Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document
Am Dienstag, 23. Oktober 2018, 04:11:44 schrieb Theodore Y. Ts'o: > On Tue, Oct 23, 2018 at 03:25:08PM +1100, NeilBrown wrote: > > Yes, you could, and you can. But if it was Linus who was behaving > > inappropriately, where did you go then? This is why I think whatever > > "code" we have should be overtly a statement Linus makes about his > > behaviour, in the first instance. > > You're still missing the point, and the problem. The concern was not > *that* a patch was rejected, it was in *how* the patch was rejected. And to solve *this* problem a highly controversial and politically charged CoC had to be introduced that has already begun to divide the wider community? Seems like a bit of an overkill to me. And whether that CoC does come with a political agenda or is just being *perceived* so, is irrelevant: the perception *is* the reality. And by embracing this CoC, Linux is now being perceived as also supporting the agenda that comes with it. But perhaps that was intended? In my view you now have a new, probably even bigger problem: namely that by adopting *this* CoC and by unyieldingly clinging to it, you have alienated many, if not the majority of loyal Linux-users/supporters. Bad choice and bad timing, now that Linux seemed ready to also take off in the desktop-area. > The "problem" has never been about how Linus was treating anyone other > than core maintainers; i.e., most of the rants that I can think of (a) > happened years of ago, and (b) were directed at the sort of people who > were in the room at the Maintainer's Summit yesterday. Who which, by > the way, didn't have a complaint about Linus's recent behavior; in > fact, there was general agreement that Linus's behavior has been > getting *better* over the last few years. > > One of the more important effects of the CoC is that newcomers have a > fear about Linux's reputation of having extremely toxic community. > There is a narrative that has been constructed that because Linus > behaves badly to everyone; and this gives everyone "permission" to > behave badly. Regardless of how true it may have been in the past, I > believe that it is largely obsolete today. And so, the mere existence > of a CoC has caused some newcomers to say that they have "already > noticed a difference" --- which is IMO mostly the effect of CoC easing > fears, as opposed to any real change in Linux community in the past > four weeks. > > I think how it will work out in practice is that the CoC will be more > a commitment about what we are holding up as community norms. > Unfortunately, for some poeple the term "CoC" apparently acts as > trigger language and it brings to mind legal proceedings, > unaccountable court-like entities, and hammering people with > punishments for petty issues with no appeal or recourse. > I think you're wrong here. It's not the term "CoC" as such that brings up the negative associations. It is the specific choice of the CoC and its wording that does. And quite a few people have pointed this out already. Mitigations and alternatives had been offered but were ignored. > Perhaps this is why other communities have elected to use terms such > as "How to do Samba: Nicely" and "GNU Kind Communication Guidelines". > All of these are trying to solve the same issue, and so my suggestion > is let's just wait and see how things go. If people continue to see > that the community has "changed" for the better, and other people see > that we're not hammering people with sanctions, but rather reminding > each other about the kind of community we aspire to be, it'll all be > good. > > - Ted Those other communities have not just chosen other terms but also chosen other approaches and wordings. In my view, the Linux-CoC stands for exactly that sort of extreme "Political Correctness" that is infesting our societies and has proven its destructive nature in more than enough instances. For some examples see [1][2][3][4][5]. To me it feels more and more like the dark times of witch-hunts are back or when it was politically in-correct to say that the earth revolves around the sun. In those days offenders like Galilei were at least offered the choice between recanting and the funeral-pile. Today you may recant but you get publicly burnt anyway. To see Linux falling for this is a sorry sight. Rainer Fiebig *** [1] https://www.ibtimes.co.uk/sacked-nobel-prize-winning-scientist-sir-tim-hunt-gets-backing-eight-fellow-laureates-1507096 [2] https://www.telegraph.co.uk/news/science/science-news/12057365/Sir-Tim-Hunt-to-leave-Britain-for-Japan-after-sexism-row.html [3] https://en.wikipedia.org/wiki/Tim_Hunt#The_toast [4] https://www.bbc.com/news/world-europe-45703700 [5] https://www.bbc.com/news/world-us-canada-45789819 -- The truth always turns out to be simpler than you thought. Richard Feynman
Re: Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document
Am Montag, 22. Oktober 2018, 08:20:11 schrieb NeilBrown: > On Sat, Oct 20 2018, Greg Kroah-Hartman wrote: > > Hi all, > > > > As everyone knows by now, we added a new Code of Conduct to the kernel > > tree a few weeks ago. > > I wanted to stay detached from all this, but as remaining (publicly) And I didn't expect myself to ever post in this matter again, as I had already given up and relegated it to the "waste of precious lifetime" category. But your initiative and courage deserve support and so: +1. > I call on the community to consider what *does* need to be said, about > conduct, to people outside the community and who have recently joined. > What is the document that you would have liked to have read as you were > starting out? It is all too long ago for me to remember clearly, and so > much has changed. On the day the patch came out, I started working on a modified version, a CoC that I could have lived with. I guess this was my way of dealing with this unfortunate affair. So please find below what I would have submitted for discussion. Thanks and regards! Rainer Fiebig Disclosure == My contribution to the Linux kernel is admittedly negligible: I run rc- kernels, have reported a few problems, helped to fix them and fixed one myself. To the extent of the time and effort this took me, I dare to give my opinion in this matter. --- Code of Conduct +++ The goal of the Linux kernel development process is to maintain and advance the most robust operating system kernel ever. Needless to say, views on how to achieve this will differ at times. In order to keep arguments civilized and to ensure an open, positive and constructive environment, we have setup guidelines that participants are expected to comply with: No bias === Nobody must be discriminated or favored due to personal traits like - for example - age, gender or ethnicity. They are irrelevant. What counts is whether the contribution is in line with a/m goal. Any such contribution will be carefully reviewed. Be excellent to each other == Don't do to others what you don't want others to do to you. Straightforward talk is fine. But dissent can be communicated in a non-destructive manner. And keep in mind that at times it may be *you* who is dead wrong. Examples of encouraged behavior: * Being respectful of differing viewpoints * Criticizing constructively, i. e. showing ways for improvement * Accepting constructive criticism * Focusing on what is best for our goal and the community Examples of unacceptable behavior: * Comments intended to insult, depreciate or defame a person * Public or private harassment * Unwelcome sexual attention or advances * Fabricating incriminations by quoting out of context * Publishing others’ private information, such as a physical or electronic address, without explicit permission * Promoting political agendas * Trolling Responsibilities All participants are responsible for complying with this Code of Conduct. Maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of obviously unacceptable behavior. Maintainers have the right to ban temporarily or permanently any contributor who's behavior is not aligned to this Code of Conduct. Arbitration === Anyone who feels abused, harassed or affected by otherwise unacceptable behavior may report this to the Technical Advisory Board (TAB) at . All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The TAB is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific arbitration policies may be posted separately. Attribution === Some elements of this Code of Conduct are derived from the Contributor Covenant, version 1.4, available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
Re: Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document
Am Montag, 22. Oktober 2018, 08:20:11 schrieb NeilBrown: > On Sat, Oct 20 2018, Greg Kroah-Hartman wrote: > > Hi all, > > > > As everyone knows by now, we added a new Code of Conduct to the kernel > > tree a few weeks ago. > > I wanted to stay detached from all this, but as remaining (publicly) And I didn't expect myself to ever post in this matter again, as I had already given up and relegated it to the "waste of precious lifetime" category. But your initiative and courage deserve support and so: +1. > I call on the community to consider what *does* need to be said, about > conduct, to people outside the community and who have recently joined. > What is the document that you would have liked to have read as you were > starting out? It is all too long ago for me to remember clearly, and so > much has changed. On the day the patch came out, I started working on a modified version, a CoC that I could have lived with. I guess this was my way of dealing with this unfortunate affair. So please find below what I would have submitted for discussion. Thanks and regards! Rainer Fiebig Disclosure == My contribution to the Linux kernel is admittedly negligible: I run rc- kernels, have reported a few problems, helped to fix them and fixed one myself. To the extent of the time and effort this took me, I dare to give my opinion in this matter. --- Code of Conduct +++ The goal of the Linux kernel development process is to maintain and advance the most robust operating system kernel ever. Needless to say, views on how to achieve this will differ at times. In order to keep arguments civilized and to ensure an open, positive and constructive environment, we have setup guidelines that participants are expected to comply with: No bias === Nobody must be discriminated or favored due to personal traits like - for example - age, gender or ethnicity. They are irrelevant. What counts is whether the contribution is in line with a/m goal. Any such contribution will be carefully reviewed. Be excellent to each other == Don't do to others what you don't want others to do to you. Straightforward talk is fine. But dissent can be communicated in a non-destructive manner. And keep in mind that at times it may be *you* who is dead wrong. Examples of encouraged behavior: * Being respectful of differing viewpoints * Criticizing constructively, i. e. showing ways for improvement * Accepting constructive criticism * Focusing on what is best for our goal and the community Examples of unacceptable behavior: * Comments intended to insult, depreciate or defame a person * Public or private harassment * Unwelcome sexual attention or advances * Fabricating incriminations by quoting out of context * Publishing others’ private information, such as a physical or electronic address, without explicit permission * Promoting political agendas * Trolling Responsibilities All participants are responsible for complying with this Code of Conduct. Maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of obviously unacceptable behavior. Maintainers have the right to ban temporarily or permanently any contributor who's behavior is not aligned to this Code of Conduct. Arbitration === Anyone who feels abused, harassed or affected by otherwise unacceptable behavior may report this to the Technical Advisory Board (TAB) at . All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The TAB is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific arbitration policies may be posted separately. Attribution === Some elements of this Code of Conduct are derived from the Contributor Covenant, version 1.4, available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
Re: [Ksummit-discuss] [PATCH v2 0/3] code of conduct fixes
Am Mittwoch, 10. Oktober 2018, 18:23:24 schrieb Eric W. Biederman: > James Bottomley writes: > > > Resend to show accumulated tags and also to add a third patch listing > > the TAB as the reporting point as a few people seem to want. If it > > gets the same level of support, I'll send it in with the other two. > > > There is also: > > > Our Responsibilities > > > > > > Maintainers are responsible for clarifying the standards of acceptable > > behavior > > and are expected to take appropriate and fair corrective action in response > > to > > any instances of unacceptable behavior. > > > > Maintainers have the right and responsibility to remove, edit, or reject > > comments, commits, code, wiki edits, issues, and other contributions that > > are > > not aligned to this Code of Conduct, or to ban temporarily or permanently > > any > > contributor for other behaviors that they deem inappropriate, threatening, > > offensive, or harmful. > > Which is very problematic. > a) In append only logs like git we can not edit history. >Making it a mainters responsibility to edit the history, to do the >impossible is a problem. > > b) There are no responsibilities of for people who are not Maintainers. >That is another problem. > As a reminder/clarification one could introduce a line like this: Responsibilities All participants are responsible for complying with this Code of Conduct. Maintainers are responsible for[...] > c) The entire tone of the reponsibilities section is out of line with a >community where there are no enforcement powers only the power to >accept or not accept a patch. Only the power to persuade not to >enforce. > > Overall in the discussions I have heard people talking about persuading, > educating, and not feeding trolls. Nowhere have I heard people talking > about policing the community which I understand that responsiblity > section to be talking about. > I think Eward Cree aired this concerns early on in the discussion: https://lkml.org/lkml/2018/9/19/234 > Increasingly I am getting the feeling that this document does not the > linux development community. Perhaps a revert and trying to come up > with better language from scratch would be better. [...] +1. Nobody would get hurt or loose face by doing so. On the contrary. My suggestion would be: - revert the patch - discuss the matter (and the way it was introduced) at least at the next MS - setup a task-force to come up with a new proposal - discuss the proposal - make corrections, if necessary - implement it IMO there's no need to rush things in a matter so important for the future of the project. So long! Rainer Fiebig -- The truth always turns out to be simpler than you thought. Richard Feynman
Re: [Ksummit-discuss] [PATCH v2 0/3] code of conduct fixes
Am Mittwoch, 10. Oktober 2018, 18:23:24 schrieb Eric W. Biederman: > James Bottomley writes: > > > Resend to show accumulated tags and also to add a third patch listing > > the TAB as the reporting point as a few people seem to want. If it > > gets the same level of support, I'll send it in with the other two. > > > There is also: > > > Our Responsibilities > > > > > > Maintainers are responsible for clarifying the standards of acceptable > > behavior > > and are expected to take appropriate and fair corrective action in response > > to > > any instances of unacceptable behavior. > > > > Maintainers have the right and responsibility to remove, edit, or reject > > comments, commits, code, wiki edits, issues, and other contributions that > > are > > not aligned to this Code of Conduct, or to ban temporarily or permanently > > any > > contributor for other behaviors that they deem inappropriate, threatening, > > offensive, or harmful. > > Which is very problematic. > a) In append only logs like git we can not edit history. >Making it a mainters responsibility to edit the history, to do the >impossible is a problem. > > b) There are no responsibilities of for people who are not Maintainers. >That is another problem. > As a reminder/clarification one could introduce a line like this: Responsibilities All participants are responsible for complying with this Code of Conduct. Maintainers are responsible for[...] > c) The entire tone of the reponsibilities section is out of line with a >community where there are no enforcement powers only the power to >accept or not accept a patch. Only the power to persuade not to >enforce. > > Overall in the discussions I have heard people talking about persuading, > educating, and not feeding trolls. Nowhere have I heard people talking > about policing the community which I understand that responsiblity > section to be talking about. > I think Eward Cree aired this concerns early on in the discussion: https://lkml.org/lkml/2018/9/19/234 > Increasingly I am getting the feeling that this document does not the > linux development community. Perhaps a revert and trying to come up > with better language from scratch would be better. [...] +1. Nobody would get hurt or loose face by doing so. On the contrary. My suggestion would be: - revert the patch - discuss the matter (and the way it was introduced) at least at the next MS - setup a task-force to come up with a new proposal - discuss the proposal - make corrections, if necessary - implement it IMO there's no need to rush things in a matter so important for the future of the project. So long! Rainer Fiebig -- The truth always turns out to be simpler than you thought. Richard Feynman
Re: [Ksummit-discuss] [PATCH] code-of-conduct: Remove explicit list of discrimination factors
Am Mittwoch, 10. Oktober 2018, 15:16:12 schrieb Josh Triplett: > On Wed, Oct 10, 2018 at 01:55:04PM -0700, Frank Rowand wrote: > > On 10/07/18 01:51, Geert Uytterhoeven wrote: > > > Providing an explicit list of discrimination factors may give the false > > > impression that discrimination based on other unlisted factors would be > > > allowed. > > > > > > Avoid any ambiguity by removing the list, to ensure "a harassment-free > > > experience for everyone", period. > [...] > > > diff --git a/Documentation/process/code-of-conduct.rst > > > b/Documentation/process/code-of-conduct.rst > > > index ab7c24b5478c6b30..e472c9f86ff00b34 100644 > > > --- a/Documentation/process/code-of-conduct.rst > > > +++ b/Documentation/process/code-of-conduct.rst > > > @@ -6,10 +6,7 @@ Our Pledge > > > > > > In the interest of fostering an open and welcoming environment, we as > > > contributors and maintainers pledge to making participation in our > > > project and > > > -our community a harassment-free experience for everyone, regardless of > > > age, body > > > -size, disability, ethnicity, sex characteristics, gender identity and > > > -expression, level of experience, education, socio-economic status, > > > nationality, > > > -personal appearance, race, religion, or sexual identity and orientation. > > > +our community a harassment-free experience for everyone. > > > > > > Our Standards > > > = > > > > > > > > > The words removed by this patch are a political statement. > > Choosing not to say those words is a political statement. No. If there's an implicit statement it's "No politics here." The patch makes the sentence and its message completely neutral. And what can be more inclusive and encompassing than "everyone"? > > See the original commit message for the code of conduct: "Explicit > guidelines have demonstrated success in other projects and other areas > of the kernel." > Which does not mean that this is generally true. I guess you know the difference between deduction and induction. > And see the FAQ entry at https://www.contributor-covenant.org/faq for > "The Contributor Covenant explicitly lists a set of protected classes; "protected classes" is imo very unfortunate wording and very close to "privileged classes". I bet this won't go down well with lots of people, especially in the eastern hemisphere. Reminds me of "All animals are equal. But some animals are more equal than others."[1] History has shown were this leads to. > does this make it acceptable to discriminate or make others feel > unwelcome based on other factors?" (I wrote that FAQ entry and submitted > it upstream, where it was enthusiastically merged.) > Not really surprising. So long! Rainer Fiebig [1] https://en.wikipedia.org/wiki/Animal_Farm -- The truth always turns out to be simpler than you thought. Richard Feynman
Re: [Ksummit-discuss] [PATCH] code-of-conduct: Remove explicit list of discrimination factors
Am Mittwoch, 10. Oktober 2018, 15:16:12 schrieb Josh Triplett: > On Wed, Oct 10, 2018 at 01:55:04PM -0700, Frank Rowand wrote: > > On 10/07/18 01:51, Geert Uytterhoeven wrote: > > > Providing an explicit list of discrimination factors may give the false > > > impression that discrimination based on other unlisted factors would be > > > allowed. > > > > > > Avoid any ambiguity by removing the list, to ensure "a harassment-free > > > experience for everyone", period. > [...] > > > diff --git a/Documentation/process/code-of-conduct.rst > > > b/Documentation/process/code-of-conduct.rst > > > index ab7c24b5478c6b30..e472c9f86ff00b34 100644 > > > --- a/Documentation/process/code-of-conduct.rst > > > +++ b/Documentation/process/code-of-conduct.rst > > > @@ -6,10 +6,7 @@ Our Pledge > > > > > > In the interest of fostering an open and welcoming environment, we as > > > contributors and maintainers pledge to making participation in our > > > project and > > > -our community a harassment-free experience for everyone, regardless of > > > age, body > > > -size, disability, ethnicity, sex characteristics, gender identity and > > > -expression, level of experience, education, socio-economic status, > > > nationality, > > > -personal appearance, race, religion, or sexual identity and orientation. > > > +our community a harassment-free experience for everyone. > > > > > > Our Standards > > > = > > > > > > > > > The words removed by this patch are a political statement. > > Choosing not to say those words is a political statement. No. If there's an implicit statement it's "No politics here." The patch makes the sentence and its message completely neutral. And what can be more inclusive and encompassing than "everyone"? > > See the original commit message for the code of conduct: "Explicit > guidelines have demonstrated success in other projects and other areas > of the kernel." > Which does not mean that this is generally true. I guess you know the difference between deduction and induction. > And see the FAQ entry at https://www.contributor-covenant.org/faq for > "The Contributor Covenant explicitly lists a set of protected classes; "protected classes" is imo very unfortunate wording and very close to "privileged classes". I bet this won't go down well with lots of people, especially in the eastern hemisphere. Reminds me of "All animals are equal. But some animals are more equal than others."[1] History has shown were this leads to. > does this make it acceptable to discriminate or make others feel > unwelcome based on other factors?" (I wrote that FAQ entry and submitted > it upstream, where it was enthusiastically merged.) > Not really surprising. So long! Rainer Fiebig [1] https://en.wikipedia.org/wiki/Animal_Farm -- The truth always turns out to be simpler than you thought. Richard Feynman
Re: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses
James Bottomley schrieb: > On Tue, 2018-10-09 at 22:38 +0300, Laurent Pinchart wrote: >> Hi Josh, >> >> On Tuesday, 9 October 2018 21:56:23 EEST Josh Triplett wrote: >>> On Tue, Oct 09, 2018 at 08:29:24PM +0200, Rainer Fiebig wrote: >>>> Am Montag, 8. Oktober 2018, 08:20:44 schrieb Josh Triplett: >>>>> On Sat, Oct 06, 2018 at 02:36:39PM -0700, James Bottomley >>>>> wrote: >>>>>> The current code of conduct has an ambiguity in the it >>>>>> considers publishing private information such as email >>>>>> addresses unacceptable behaviour. Since the Linux kernel >>>>>> collects and publishes email addresses as part of the patch >>>>>> process, add an exception clause for email addresses >>>>>> ordinarily collected by the project to correct this >>>>>> ambiguity. >>>>> >>>>> Upstream has now adopted a FAQ, which addresses this and many >>>>> other questions. See https://www.contributor-covenant.org/faq . >>>>> >>>>> Might I suggest adding that link to the bottom of the document, >>>>> instead? (And then, optionally, submitting entries for that >>>>> FAQ.) >>>> >>>> The Code of Conflict has 28 lines, including the heading. >>>> The Code of Conduct has 81 lines, including the heading. And it >>>> needs a FAQ. Hm. >>> >>> Yes, it turns out to be a more complicated problem than it was >>> previously oversimplified to. People don't automatically share a >>> common understanding. >> >> I see an elephant in the room in the fact that we have carefully >> avoided discussing whether people share a common goal here :-/ > > We don't need to share a common goal; we just need to find the It wouldn't hurt to have one and mention it either. > document useful on its merits. That's why we're a mostly GPLv2 > project without signing up to most of the FSF philosophy. However, > that's also why we would keep our own interpretations, understandings > and clarifications in house, as it were. > > James > Sure. So long! Rainer Fiebig
Re: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses
James Bottomley schrieb: > On Tue, 2018-10-09 at 22:38 +0300, Laurent Pinchart wrote: >> Hi Josh, >> >> On Tuesday, 9 October 2018 21:56:23 EEST Josh Triplett wrote: >>> On Tue, Oct 09, 2018 at 08:29:24PM +0200, Rainer Fiebig wrote: >>>> Am Montag, 8. Oktober 2018, 08:20:44 schrieb Josh Triplett: >>>>> On Sat, Oct 06, 2018 at 02:36:39PM -0700, James Bottomley >>>>> wrote: >>>>>> The current code of conduct has an ambiguity in the it >>>>>> considers publishing private information such as email >>>>>> addresses unacceptable behaviour. Since the Linux kernel >>>>>> collects and publishes email addresses as part of the patch >>>>>> process, add an exception clause for email addresses >>>>>> ordinarily collected by the project to correct this >>>>>> ambiguity. >>>>> >>>>> Upstream has now adopted a FAQ, which addresses this and many >>>>> other questions. See https://www.contributor-covenant.org/faq . >>>>> >>>>> Might I suggest adding that link to the bottom of the document, >>>>> instead? (And then, optionally, submitting entries for that >>>>> FAQ.) >>>> >>>> The Code of Conflict has 28 lines, including the heading. >>>> The Code of Conduct has 81 lines, including the heading. And it >>>> needs a FAQ. Hm. >>> >>> Yes, it turns out to be a more complicated problem than it was >>> previously oversimplified to. People don't automatically share a >>> common understanding. >> >> I see an elephant in the room in the fact that we have carefully >> avoided discussing whether people share a common goal here :-/ > > We don't need to share a common goal; we just need to find the It wouldn't hurt to have one and mention it either. > document useful on its merits. That's why we're a mostly GPLv2 > project without signing up to most of the FSF philosophy. However, > that's also why we would keep our own interpretations, understandings > and clarifications in house, as it were. > > James > Sure. So long! Rainer Fiebig
Re: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses
Josh Triplett schrieb: > On Tue, Oct 09, 2018 at 08:29:24PM +0200, Rainer Fiebig wrote: >> Am Montag, 8. Oktober 2018, 08:20:44 schrieb Josh Triplett: >>> On Sat, Oct 06, 2018 at 02:36:39PM -0700, James Bottomley wrote: >>>> The current code of conduct has an ambiguity in the it considers publishing >>>> private information such as email addresses unacceptable behaviour. Since >>>> the Linux kernel collects and publishes email addresses as part of the >>>> patch >>>> process, add an exception clause for email addresses ordinarily collected >>>> by >>>> the project to correct this ambiguity. >>> >>> Upstream has now adopted a FAQ, which addresses this and many other >>> questions. See https://www.contributor-covenant.org/faq . >>> >>> Might I suggest adding that link to the bottom of the document, instead? >>> (And then, optionally, submitting entries for that FAQ.) >>> >> >> The Code of Conflict has 28 lines, including the heading. >> The Code of Conduct has 81 lines, including the heading. And it needs a FAQ. >> Hm. > > Yes, it turns out to be a more complicated problem than it was > previously oversimplified to. People don't automatically share a common > understanding. > I don't know what that complicated problem was. The commit message is a bit vaque in that respect. But I bet that in the end it *was* simple. And it probably wasn't that people felt discriminated because of their "body size". I also think that people actually do share a common understanding. Otherwise *no* CoC would work - however explicit it would be. We're not that different after all. A CoC that needs a FAQ to be understood may create more problems that it solves. So long! Rainer Fiebig
Re: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses
Josh Triplett schrieb: > On Tue, Oct 09, 2018 at 08:29:24PM +0200, Rainer Fiebig wrote: >> Am Montag, 8. Oktober 2018, 08:20:44 schrieb Josh Triplett: >>> On Sat, Oct 06, 2018 at 02:36:39PM -0700, James Bottomley wrote: >>>> The current code of conduct has an ambiguity in the it considers publishing >>>> private information such as email addresses unacceptable behaviour. Since >>>> the Linux kernel collects and publishes email addresses as part of the >>>> patch >>>> process, add an exception clause for email addresses ordinarily collected >>>> by >>>> the project to correct this ambiguity. >>> >>> Upstream has now adopted a FAQ, which addresses this and many other >>> questions. See https://www.contributor-covenant.org/faq . >>> >>> Might I suggest adding that link to the bottom of the document, instead? >>> (And then, optionally, submitting entries for that FAQ.) >>> >> >> The Code of Conflict has 28 lines, including the heading. >> The Code of Conduct has 81 lines, including the heading. And it needs a FAQ. >> Hm. > > Yes, it turns out to be a more complicated problem than it was > previously oversimplified to. People don't automatically share a common > understanding. > I don't know what that complicated problem was. The commit message is a bit vaque in that respect. But I bet that in the end it *was* simple. And it probably wasn't that people felt discriminated because of their "body size". I also think that people actually do share a common understanding. Otherwise *no* CoC would work - however explicit it would be. We're not that different after all. A CoC that needs a FAQ to be understood may create more problems that it solves. So long! Rainer Fiebig
Re: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses
Laurent Pinchart schrieb: > Hi Josh, > > On Tuesday, 9 October 2018 21:56:23 EEST Josh Triplett wrote: >> On Tue, Oct 09, 2018 at 08:29:24PM +0200, Rainer Fiebig wrote: >>> Am Montag, 8. Oktober 2018, 08:20:44 schrieb Josh Triplett: >>>> On Sat, Oct 06, 2018 at 02:36:39PM -0700, James Bottomley wrote: >>>>> The current code of conduct has an ambiguity in the it considers >>>>> publishing private information such as email addresses unacceptable >>>>> behaviour. Since the Linux kernel collects and publishes email >>>>> addresses as part of the patch process, add an exception clause for >>>>> email addresses ordinarily collected by the project to correct this >>>>> ambiguity. >>>> >>>> Upstream has now adopted a FAQ, which addresses this and many other >>>> questions. See https://www.contributor-covenant.org/faq . >>>> >>>> Might I suggest adding that link to the bottom of the document, instead? >>>> (And then, optionally, submitting entries for that FAQ.) >>> >>> The Code of Conflict has 28 lines, including the heading. >>> The Code of Conduct has 81 lines, including the heading. And it needs a >>> FAQ. Hm. >> >> Yes, it turns out to be a more complicated problem than it was >> previously oversimplified to. People don't automatically share a common >> understanding. > > I see an elephant in the room in the fact that we have carefully avoided > discussing whether people share a common goal here :-/ > I've been thinking about this a bit lately. Maybe it might be good to explicitly mention that common goal in a sort of a preamble. Here are the first few lines of what came to my mind: Code of Conduct +++ The goal of the Linux kernel development process is to maintain and advance the most robust operating system kernel ever. Needless to say, views on how to achieve this will differ at times. In order to keep arguments civilized and to ensure an open, positive and constructive environment, we have setup guidelines that participants are expected to comply with: No bias === Nobody must be discriminated or favored due to personal traits like - for example - age, gender or ethnicity. They are irrelevant. What counts is whether the contribution is in line with a/m goal. Any such contribution will be carefully reviewed. Be excellent to each other == [...] So long! Rainer Fiebig
Re: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses
Laurent Pinchart schrieb: > Hi Josh, > > On Tuesday, 9 October 2018 21:56:23 EEST Josh Triplett wrote: >> On Tue, Oct 09, 2018 at 08:29:24PM +0200, Rainer Fiebig wrote: >>> Am Montag, 8. Oktober 2018, 08:20:44 schrieb Josh Triplett: >>>> On Sat, Oct 06, 2018 at 02:36:39PM -0700, James Bottomley wrote: >>>>> The current code of conduct has an ambiguity in the it considers >>>>> publishing private information such as email addresses unacceptable >>>>> behaviour. Since the Linux kernel collects and publishes email >>>>> addresses as part of the patch process, add an exception clause for >>>>> email addresses ordinarily collected by the project to correct this >>>>> ambiguity. >>>> >>>> Upstream has now adopted a FAQ, which addresses this and many other >>>> questions. See https://www.contributor-covenant.org/faq . >>>> >>>> Might I suggest adding that link to the bottom of the document, instead? >>>> (And then, optionally, submitting entries for that FAQ.) >>> >>> The Code of Conflict has 28 lines, including the heading. >>> The Code of Conduct has 81 lines, including the heading. And it needs a >>> FAQ. Hm. >> >> Yes, it turns out to be a more complicated problem than it was >> previously oversimplified to. People don't automatically share a common >> understanding. > > I see an elephant in the room in the fact that we have carefully avoided > discussing whether people share a common goal here :-/ > I've been thinking about this a bit lately. Maybe it might be good to explicitly mention that common goal in a sort of a preamble. Here are the first few lines of what came to my mind: Code of Conduct +++ The goal of the Linux kernel development process is to maintain and advance the most robust operating system kernel ever. Needless to say, views on how to achieve this will differ at times. In order to keep arguments civilized and to ensure an open, positive and constructive environment, we have setup guidelines that participants are expected to comply with: No bias === Nobody must be discriminated or favored due to personal traits like - for example - age, gender or ethnicity. They are irrelevant. What counts is whether the contribution is in line with a/m goal. Any such contribution will be carefully reviewed. Be excellent to each other == [...] So long! Rainer Fiebig
Re: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses
Am Montag, 8. Oktober 2018, 08:20:44 schrieb Josh Triplett: > On Sat, Oct 06, 2018 at 02:36:39PM -0700, James Bottomley wrote: > > The current code of conduct has an ambiguity in the it considers publishing > > private information such as email addresses unacceptable behaviour. Since > > the Linux kernel collects and publishes email addresses as part of the patch > > process, add an exception clause for email addresses ordinarily collected by > > the project to correct this ambiguity. > > Upstream has now adopted a FAQ, which addresses this and many other > questions. See https://www.contributor-covenant.org/faq . > > Might I suggest adding that link to the bottom of the document, instead? > (And then, optionally, submitting entries for that FAQ.) > The Code of Conflict has 28 lines, including the heading. The Code of Conduct has 81 lines, including the heading. And it needs a FAQ. Hm. Here's a one-line Code of Conduct from Kant: "Act only according to that maxim whereby you can, at the same time, will that it should become a universal law."[1] Put another way: Don't do to others what you don't want others to do to you. Simple beats complex. No FAQ necessary, imo. Regards! Rainer Fiebig [1] https://en.wikipedia.org/wiki/Immanuel_Kant -- The truth always turns out to be simpler than you thought. Richard Feynman
Re: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses
Am Montag, 8. Oktober 2018, 08:20:44 schrieb Josh Triplett: > On Sat, Oct 06, 2018 at 02:36:39PM -0700, James Bottomley wrote: > > The current code of conduct has an ambiguity in the it considers publishing > > private information such as email addresses unacceptable behaviour. Since > > the Linux kernel collects and publishes email addresses as part of the patch > > process, add an exception clause for email addresses ordinarily collected by > > the project to correct this ambiguity. > > Upstream has now adopted a FAQ, which addresses this and many other > questions. See https://www.contributor-covenant.org/faq . > > Might I suggest adding that link to the bottom of the document, instead? > (And then, optionally, submitting entries for that FAQ.) > The Code of Conflict has 28 lines, including the heading. The Code of Conduct has 81 lines, including the heading. And it needs a FAQ. Hm. Here's a one-line Code of Conduct from Kant: "Act only according to that maxim whereby you can, at the same time, will that it should become a universal law."[1] Put another way: Don't do to others what you don't want others to do to you. Simple beats complex. No FAQ necessary, imo. Regards! Rainer Fiebig [1] https://en.wikipedia.org/wiki/Immanuel_Kant -- The truth always turns out to be simpler than you thought. Richard Feynman
Re: [PATCH 4.9 088/138] Revert "drm/i915: Do not rely on wm preservation for ILK watermarks"
Greg Kroah-Hartman wrote:
> 4.9-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> This reverts commit 7de694782cbe7840f2c0de6f1e70f41fc1b8b6e8 which is
> commit 8777b927b92cf5b6c29f9f9d3c737addea9ac8a7 upstream.
>
> It was reported to cause flickering and other regressions.
>
> Reported-by: Rainer Fiebig <j...@mailbox.org>
> Cc: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
> Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
> Cc: Matt Roper <matthew.d.ro...@intel.com>
> Cc: Rodrigo Vivi <rodrigo.v...@intel.com>
> Cc: Jani Nikula <jani.nik...@linux.intel.com>
> Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
>
> reverted:
> ---
> drivers/gpu/drm/i915/intel_drv.h |1
> drivers/gpu/drm/i915/intel_pm.c | 52
> ++-
> 2 files changed, 31 insertions(+), 22 deletions(-)
>
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -457,6 +457,7 @@ struct intel_crtc_scaler_state {
>
> struct intel_pipe_wm {
> struct intel_wm_level wm[5];
> + struct intel_wm_level raw_wm[5];
> uint32_t linetime;
> bool fbc_wm_enabled;
> bool pipe_enabled;
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -27,7 +27,6 @@
>
> #include
> #include
> -#include
> #include "i915_drv.h"
> #include "intel_drv.h"
> #include "../../../platform/x86/intel_ips.h"
> @@ -2018,9 +2017,9 @@ static void ilk_compute_wm_level(const s
>const struct intel_crtc *intel_crtc,
>int level,
>struct intel_crtc_state *cstate,
> - const struct intel_plane_state *pristate,
> - const struct intel_plane_state *sprstate,
> - const struct intel_plane_state *curstate,
> + struct intel_plane_state *pristate,
> + struct intel_plane_state *sprstate,
> + struct intel_plane_state *curstate,
>struct intel_wm_level *result)
> {
> uint16_t pri_latency = dev_priv->wm.pri_latency[level];
> @@ -2342,24 +2341,28 @@ static int ilk_compute_pipe_wm(struct in
> struct intel_pipe_wm *pipe_wm;
> struct drm_device *dev = state->dev;
> const struct drm_i915_private *dev_priv = to_i915(dev);
> - struct drm_plane *plane;
> - const struct drm_plane_state *plane_state;
> - const struct intel_plane_state *pristate = NULL;
> - const struct intel_plane_state *sprstate = NULL;
> - const struct intel_plane_state *curstate = NULL;
> + struct intel_plane *intel_plane;
> + struct intel_plane_state *pristate = NULL;
> + struct intel_plane_state *sprstate = NULL;
> + struct intel_plane_state *curstate = NULL;
> int level, max_level = ilk_wm_max_level(dev), usable_level;
> struct ilk_wm_maximums max;
>
> pipe_wm = >wm.ilk.optimal;
>
> - drm_atomic_crtc_state_for_each_plane_state(plane, plane_state,
> >base) {
> - const struct intel_plane_state *ps =
> to_intel_plane_state(plane_state);
> + for_each_intel_plane_on_crtc(dev, intel_crtc, intel_plane) {
> + struct intel_plane_state *ps;
>
> - if (plane->type == DRM_PLANE_TYPE_PRIMARY)
> + ps = intel_atomic_get_existing_plane_state(state,
> +intel_plane);
> + if (!ps)
> + continue;
> +
> + if (intel_plane->base.type == DRM_PLANE_TYPE_PRIMARY)
> pristate = ps;
> - else if (plane->type == DRM_PLANE_TYPE_OVERLAY)
> + else if (intel_plane->base.type == DRM_PLANE_TYPE_OVERLAY)
> sprstate = ps;
> - else if (plane->type == DRM_PLANE_TYPE_CURSOR)
> + else if (intel_plane->base.type == DRM_PLANE_TYPE_CURSOR)
> curstate = ps;
> }
>
> @@ -2381,9 +2384,11 @@ static int ilk_compute_pipe_wm(struct in
> if (pipe_wm->sprites_scaled)
> usable_level = 0;
>
> - memset(_wm->wm, 0, sizeof(pipe_wm->wm));
> ilk_compute_wm_level(dev_priv, intel_crtc, 0, cstate,
> - pristate, sprstate, curstate, _wm->wm[0]);
> + pristate, sprstate, curstate, _wm->raw_wm[0]);
> +
> + mem
Re: [PATCH 4.9 088/138] Revert "drm/i915: Do not rely on wm preservation for ILK watermarks"
Greg Kroah-Hartman wrote:
> 4.9-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> This reverts commit 7de694782cbe7840f2c0de6f1e70f41fc1b8b6e8 which is
> commit 8777b927b92cf5b6c29f9f9d3c737addea9ac8a7 upstream.
>
> It was reported to cause flickering and other regressions.
>
> Reported-by: Rainer Fiebig
> Cc: Maarten Lankhorst
> Cc: Ville Syrjälä
> Cc: Matt Roper
> Cc: Rodrigo Vivi
> Cc: Jani Nikula
> Signed-off-by: Greg Kroah-Hartman
>
> reverted:
> ---
> drivers/gpu/drm/i915/intel_drv.h |1
> drivers/gpu/drm/i915/intel_pm.c | 52
> ++-
> 2 files changed, 31 insertions(+), 22 deletions(-)
>
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -457,6 +457,7 @@ struct intel_crtc_scaler_state {
>
> struct intel_pipe_wm {
> struct intel_wm_level wm[5];
> + struct intel_wm_level raw_wm[5];
> uint32_t linetime;
> bool fbc_wm_enabled;
> bool pipe_enabled;
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -27,7 +27,6 @@
>
> #include
> #include
> -#include
> #include "i915_drv.h"
> #include "intel_drv.h"
> #include "../../../platform/x86/intel_ips.h"
> @@ -2018,9 +2017,9 @@ static void ilk_compute_wm_level(const s
>const struct intel_crtc *intel_crtc,
>int level,
>struct intel_crtc_state *cstate,
> - const struct intel_plane_state *pristate,
> - const struct intel_plane_state *sprstate,
> - const struct intel_plane_state *curstate,
> + struct intel_plane_state *pristate,
> + struct intel_plane_state *sprstate,
> + struct intel_plane_state *curstate,
>struct intel_wm_level *result)
> {
> uint16_t pri_latency = dev_priv->wm.pri_latency[level];
> @@ -2342,24 +2341,28 @@ static int ilk_compute_pipe_wm(struct in
> struct intel_pipe_wm *pipe_wm;
> struct drm_device *dev = state->dev;
> const struct drm_i915_private *dev_priv = to_i915(dev);
> - struct drm_plane *plane;
> - const struct drm_plane_state *plane_state;
> - const struct intel_plane_state *pristate = NULL;
> - const struct intel_plane_state *sprstate = NULL;
> - const struct intel_plane_state *curstate = NULL;
> + struct intel_plane *intel_plane;
> + struct intel_plane_state *pristate = NULL;
> + struct intel_plane_state *sprstate = NULL;
> + struct intel_plane_state *curstate = NULL;
> int level, max_level = ilk_wm_max_level(dev), usable_level;
> struct ilk_wm_maximums max;
>
> pipe_wm = >wm.ilk.optimal;
>
> - drm_atomic_crtc_state_for_each_plane_state(plane, plane_state,
> >base) {
> - const struct intel_plane_state *ps =
> to_intel_plane_state(plane_state);
> + for_each_intel_plane_on_crtc(dev, intel_crtc, intel_plane) {
> + struct intel_plane_state *ps;
>
> - if (plane->type == DRM_PLANE_TYPE_PRIMARY)
> + ps = intel_atomic_get_existing_plane_state(state,
> +intel_plane);
> + if (!ps)
> + continue;
> +
> + if (intel_plane->base.type == DRM_PLANE_TYPE_PRIMARY)
> pristate = ps;
> - else if (plane->type == DRM_PLANE_TYPE_OVERLAY)
> + else if (intel_plane->base.type == DRM_PLANE_TYPE_OVERLAY)
> sprstate = ps;
> - else if (plane->type == DRM_PLANE_TYPE_CURSOR)
> + else if (intel_plane->base.type == DRM_PLANE_TYPE_CURSOR)
> curstate = ps;
> }
>
> @@ -2381,9 +2384,11 @@ static int ilk_compute_pipe_wm(struct in
> if (pipe_wm->sprites_scaled)
> usable_level = 0;
>
> - memset(_wm->wm, 0, sizeof(pipe_wm->wm));
> ilk_compute_wm_level(dev_priv, intel_crtc, 0, cstate,
> - pristate, sprstate, curstate, _wm->wm[0]);
> + pristate, sprstate, curstate, _wm->raw_wm[0]);
> +
> + memset(_wm->wm, 0, sizeof(pipe_wm->wm));
> + pipe_wm->wm[0] = pipe_wm->raw_wm[0];
>
> if (IS_HASWELL(dev) || IS_BROADWELL(dev))
> pipe_wm->linetime = hsw_compute_linetime_wm(cstate);
> @@
Re: Bug 103796 - 4.9.62: intermittent flicker after upgrade from 4.9.61
Yes, it's the i915-backports that cause the problem: - diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 49de476..277a802 100644 - diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index a19ec06..3ce9ba3 100644 After reversing *both* (else the kernel won't compile) the flicker is gone, no more messages in dmesg. All else OK so far. Please do yourself and us users with older Intel CPU/GPU a favour and don't backport i915-stuff anymore for 4.9! It's risky and probably needless: until 4.9.60/61 everything was absolutely fine. Keep in mind that 4.4 is also unusable with those processors b/c of i915-problems (as you probably know). And I have a premonition now concerning 4.14. ;) -- The truth always turns out to be simpler than you thought. Richard Feynman
Re: Bug 103796 - 4.9.62: intermittent flicker after upgrade from 4.9.61
Yes, it's the i915-backports that cause the problem: - diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 49de476..277a802 100644 - diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index a19ec06..3ce9ba3 100644 After reversing *both* (else the kernel won't compile) the flicker is gone, no more messages in dmesg. All else OK so far. Please do yourself and us users with older Intel CPU/GPU a favour and don't backport i915-stuff anymore for 4.9! It's risky and probably needless: until 4.9.60/61 everything was absolutely fine. Keep in mind that 4.4 is also unusable with those processors b/c of i915-problems (as you probably know). And I have a premonition now concerning 4.14. ;) -- The truth always turns out to be simpler than you thought. Richard Feynman
Re: Bug 103796 - 4.9.62: intermittent flicker after upgrade from 4.9.61
Yes, it's the i915-backports that cause the problem: - diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 49de476..277a802 100644 - diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index a19ec06..3ce9ba3 100644 After reversing *both* (else the kernel won't compile) the flicker is gone, no more messages in dmesg. All else OK so far. Please do yourself and us users with older Intel CPU/GPU a favour and don't backport i915-stuff anymore for 4.9! It's risky and probably needless: until 4.9.60/61 everything was absolutely fine. Keep in mind that 4.4 is also unusable with those processors b/c of i915-problems (as you probably know). And I have a premonition now concerning 4.14. ;) So long! Rainer Fiebig -- The truth always turns out to be simpler than you thought. Richard Feynman
Re: Bug 103796 - 4.9.62: intermittent flicker after upgrade from 4.9.61
Yes, it's the i915-backports that cause the problem: - diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 49de476..277a802 100644 - diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index a19ec06..3ce9ba3 100644 After reversing *both* (else the kernel won't compile) the flicker is gone, no more messages in dmesg. All else OK so far. Please do yourself and us users with older Intel CPU/GPU a favour and don't backport i915-stuff anymore for 4.9! It's risky and probably needless: until 4.9.60/61 everything was absolutely fine. Keep in mind that 4.4 is also unusable with those processors b/c of i915-problems (as you probably know). And I have a premonition now concerning 4.14. ;) So long! Rainer Fiebig -- The truth always turns out to be simpler than you thought. Richard Feynman
Bug 103796 - 4.9.62: intermittent flicker after upgrade from 4.9.61
Hi! Probably encountered a bad backport. As 4.9 is an LTS-kernel and I'm not sure whether I reported the following at the right place, here's just FYI: https://bugs.freedesktop.org/show_bug.cgi?id=103796 Rainer Fiebig -- The truth always turns out to be simpler than you thought. Richard Feynman
Bug 103796 - 4.9.62: intermittent flicker after upgrade from 4.9.61
Hi! Probably encountered a bad backport. As 4.9 is an LTS-kernel and I'm not sure whether I reported the following at the right place, here's just FYI: https://bugs.freedesktop.org/show_bug.cgi?id=103796 Rainer Fiebig -- The truth always turns out to be simpler than you thought. Richard Feynman
