Re: [REGRESSION] 5.3-rc1: r8169: remove 1000/Half from supported modes
On 26.07.19 at 22:24, Heiner Kallweit wrote: On 26.07.2019 22:16, Bernhard Held wrote: Hi Heiner, with commit a6851c613fd7 "r8169: remove 1000/Half from supported modes" my RTL8111B GB-link stops working. It thinks that it established a link, however nothing is actually transmitted. Setting the mode with `mii-tool -F 100baseTx-HD` establishes a successful connection. Can you provide standard ethtool output w/ and w/o this patch? Also a full dmesg output with the patch would be helpful. Is "100baseTx-HD" a typo and you mean GBit? And any special reason why you set half duplex? The requested files are attached. mii-tool doesn't offer GBit settings. I used HD only while playing around, both FD and HD are working. Hope it helps! Bernhard [0.00] Linux version 5.3.0-rc1-linus+ (berny@quad) (gcc version 9.1.1 20190723 [gcc-9-branch revision 273734] (SUSE Linux)) #597 SMP PREEMPT Fri Jul 26 21:33:15 CEST 2019 [0.00] Command line: BOOT_IMAGE=/vmlinuz-5.3.0-rc1-linus+ root=/dev/mapper/VGMX300-root resume=/dev/sda2 showopts radeon.dpm=1 plymouth.enable=0 memmap=1$0xe4fd net.ifnames=0 kvm-intel.vmentry_l1d_flush=never noibrs noibpb nospectre_v1 no_stf_barrier mitigations=off [0.00] KERNEL supported cpus: [0.00] Intel GenuineIntel [0.00] zhaoxin Shanghai [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [0.00] x86/fpu: Enabled xstate features 0x3, context size is 576 bytes, using 'standard' format. [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009dbff] usable [0.00] BIOS-e820: [mem 0x0009f800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000f-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xcfed] usable [0.00] BIOS-e820: [mem 0xcfee-0xcfee2fff] ACPI NVS [0.00] BIOS-e820: [mem 0xcfee3000-0xcfee] ACPI data [0.00] BIOS-e820: [mem 0xcfef-0xcfef] reserved [0.00] BIOS-e820: [mem 0xd000-0xdfff] reserved [0.00] BIOS-e820: [mem 0xfec0-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x0001afff] usable [0.00] NX (Execute Disable) protection: active [0.00] user-defined physical RAM map: [0.00] user: [mem 0x-0xe4fc] usable [0.00] user: [mem 0xe4fd-0xe4fd] reserved [0.00] user: [mem 0xe4fe-0x0009dbff] usable [0.00] user: [mem 0x0009f800-0x0009] reserved [0.00] user: [mem 0x000f-0x000f] reserved [0.00] user: [mem 0x0010-0xcfed] usable [0.00] user: [mem 0xcfee-0xcfee2fff] ACPI NVS [0.00] user: [mem 0xcfee3000-0xcfee] ACPI data [0.00] user: [mem 0xcfef-0xcfef] reserved [0.00] user: [mem 0xd000-0xdfff] reserved [0.00] user: [mem 0xfec0-0x] reserved [0.00] user: [mem 0x0001-0x0001afff] usable [0.00] SMBIOS 2.4 present. [0.00] DMI: Gigabyte Technology Co., Ltd. G33-DS3R/G33-DS3R, BIOS F7L 07/31/2009 [0.00] tsc: Fast TSC calibration using PIT [0.00] tsc: Detected 3000.288 MHz processor [0.003646] e820: update [mem 0x-0x0fff] usable ==> reserved [0.003648] e820: remove [mem 0x000a-0x000f] usable [0.003651] last_pfn = 0x1b max_arch_pfn = 0x4 [0.003655] MTRR default type: uncachable [0.003655] MTRR fixed ranges enabled: [0.003656] 0-9 write-back [0.003657] A-B uncachable [0.003657] C-CDFFF write-protect [0.003658] CE000-E uncachable [0.003658] F-F write-through [0.003659] MTRR variable ranges enabled: [0.003660] 0 base 00 mask 0F write-back [0.003661] 1 base 00E000 mask 0FE000 uncachable [0.003662] 2 base 00D000 mask 0FF000 uncachable [0.003663] 3 base 01 mask 0F write-back [0.003664] 4 base 01C000 mask 0FC000 uncachable [0.003664] 5 base 01B000 mask 0FF000 uncachable [0.003665] 6 base 00CFF0 mask 00 uncachable [0.003666] 7 disabled [0.005930] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT [0.006189] mtrr: your BIOS has configured an incorrect mask, fixing it. [0.006194] mtrr: your BIOS has configured an incorrect mask, fixing it. [0.006195] mtrr: your BIOS has configured an incorrect mask, fixing it. [0.006196] mtrr: y
[REGRESSION] 5.3-rc1: r8169: remove 1000/Half from supported modes
Hi Heiner, with commit a6851c613fd7 "r8169: remove 1000/Half from supported modes" my RTL8111B GB-link stops working. It thinks that it established a link, however nothing is actually transmitted. Setting the mode with `mii-tool -F 100baseTx-HD` establishes a successful connection. Reverting a6851c613fd7 (while considering the file name change) fixes autonegotiation for me. Kind regards Bernhard
Re: kvm splat in mmu_spte_clear_track_bits
On 08/28/2017 at 06:56 PM, Nadav Amit wrote: Bernhard Held <berny...@gmx.de> wrote: On 08/27/2017 at 02:35 PM, Adam Borowski wrote: 4.13-rc5 retested fails Crashed only after two hours or so of testing. 4.13-rc4 apparently works It survived several hours of varied tests (like 5 debian-installer runs, a win10 point release upgrade, some hurd package building, openbsd, etc), all while the host was likewise busy. Thus: to the best of my knowledge, the problem is between 4.13-rc4 and 4.13-rc5 but I wouldn't bet my life on it. I get crashes with Win10 in kvm with 4.13-rc5. 4.13-rc4 works for me. THP seems to accelerate the crash, but that's not 100% sure. There's still no crash after reverting merge 27df70 on 4.13-rc7. There are 21 commits in this merge, 10 are mm-related: $ git log 4e082e9ba7cd..e86b298bebf7 --pretty=oneline --abbrev-commit e86b298bebf7 userfaultfd: replace ENOSPC with ESRCH in case mm has gone during copy/zeropage f357e345eef7 zram: rework copy of compressor name in comp_algorithm_store() aac2fea94f7a rmap: do not call mmu_notifier_invalidate_page() under ptl d041353dc98a mm: fix list corruptions on shmem shrinklist af54aed94bf3 mm/balloon_compaction.c: don't zero ballooned pages c0a6a5ae6b5d MAINTAINERS: copy virtio on balloon_compaction.c b3a81d0841a9 mm: fix KSM data corruption 99baac21e458 mm: fix MADV_[FREE|DONTNEED] TLB flush miss problem 0a2dd266dd6b mm: make tlb_flush_pending global 56236a59556c mm: refactor TLB gathering API a9b802500ebb Revert "mm: numa: defer TLB flush for THP migration as long as possible" 0a2c40487f3e mm: migrate: fix barriers around tlb_flush_pending 16af97dc5a89 mm: migrate: prevent racy access to tlb_flush_pending 9eeb52ae712e fault-inject: fix wrong should_fail() decision in task context 4e98ebe5f435 test_kmod: fix small memory leak on filesystem tests 9c56771316ef test_kmod: fix the lock in register_test_dev_kmod() 434b06ae23ba test_kmod: fix bug which allows negative values on two config options a4afe8cdec16 test_kmod: fix spelling mistake: "EMTPY" -> "EMPTY" 5af10dfd0afc userfaultfd: hugetlbfs: remove superfluous page unlock in VM_SHARED case 75dddef32514 mm: ratelimit PFNs busy info message d507e2ebd2c7 mm: fix global NR_SLAB_.*CLAIMABLE counter reads Don’t blame me for the TLB stuff... My money is on aac2fea94f7a . Amit, thanks for your courage to expose your patch! I'm more and more confident that aac2fea94f7a is the culprit. Maybe it just accelerates the triggering of the splash. To be more sure the kernel needs to be tested for a couple of days. It would be great if others could assist in testing aac2fea94f7a. Have fun, Bernhard
Re: kvm splat in mmu_spte_clear_track_bits
On 08/28/2017 at 06:56 PM, Nadav Amit wrote: Bernhard Held wrote: On 08/27/2017 at 02:35 PM, Adam Borowski wrote: 4.13-rc5 retested fails Crashed only after two hours or so of testing. 4.13-rc4 apparently works It survived several hours of varied tests (like 5 debian-installer runs, a win10 point release upgrade, some hurd package building, openbsd, etc), all while the host was likewise busy. Thus: to the best of my knowledge, the problem is between 4.13-rc4 and 4.13-rc5 but I wouldn't bet my life on it. I get crashes with Win10 in kvm with 4.13-rc5. 4.13-rc4 works for me. THP seems to accelerate the crash, but that's not 100% sure. There's still no crash after reverting merge 27df70 on 4.13-rc7. There are 21 commits in this merge, 10 are mm-related: $ git log 4e082e9ba7cd..e86b298bebf7 --pretty=oneline --abbrev-commit e86b298bebf7 userfaultfd: replace ENOSPC with ESRCH in case mm has gone during copy/zeropage f357e345eef7 zram: rework copy of compressor name in comp_algorithm_store() aac2fea94f7a rmap: do not call mmu_notifier_invalidate_page() under ptl d041353dc98a mm: fix list corruptions on shmem shrinklist af54aed94bf3 mm/balloon_compaction.c: don't zero ballooned pages c0a6a5ae6b5d MAINTAINERS: copy virtio on balloon_compaction.c b3a81d0841a9 mm: fix KSM data corruption 99baac21e458 mm: fix MADV_[FREE|DONTNEED] TLB flush miss problem 0a2dd266dd6b mm: make tlb_flush_pending global 56236a59556c mm: refactor TLB gathering API a9b802500ebb Revert "mm: numa: defer TLB flush for THP migration as long as possible" 0a2c40487f3e mm: migrate: fix barriers around tlb_flush_pending 16af97dc5a89 mm: migrate: prevent racy access to tlb_flush_pending 9eeb52ae712e fault-inject: fix wrong should_fail() decision in task context 4e98ebe5f435 test_kmod: fix small memory leak on filesystem tests 9c56771316ef test_kmod: fix the lock in register_test_dev_kmod() 434b06ae23ba test_kmod: fix bug which allows negative values on two config options a4afe8cdec16 test_kmod: fix spelling mistake: "EMTPY" -> "EMPTY" 5af10dfd0afc userfaultfd: hugetlbfs: remove superfluous page unlock in VM_SHARED case 75dddef32514 mm: ratelimit PFNs busy info message d507e2ebd2c7 mm: fix global NR_SLAB_.*CLAIMABLE counter reads Don’t blame me for the TLB stuff... My money is on aac2fea94f7a . Amit, thanks for your courage to expose your patch! I'm more and more confident that aac2fea94f7a is the culprit. Maybe it just accelerates the triggering of the splash. To be more sure the kernel needs to be tested for a couple of days. It would be great if others could assist in testing aac2fea94f7a. Have fun, Bernhard
Re: kvm splat in mmu_spte_clear_track_bits
On 08/28/2017 at 06:01 PM, Takashi Iwai wrote: On Mon, 28 Aug 2017 17:26:05 +0200, Bernhard Held wrote: I get crashes with Win10 in kvm Did you get the crash reliably? I've been struggling how to trigger it efficiently, but currently in vain. The memory pressure isn't a single key to trigger it, as it seems... Yes, I get the crash pretty reliable with Win10 in kvm after 10 to 30 minutes. Some workload in Windows seems to be necessary to trigger the bug.
Re: kvm splat in mmu_spte_clear_track_bits
On 08/28/2017 at 06:01 PM, Takashi Iwai wrote: On Mon, 28 Aug 2017 17:26:05 +0200, Bernhard Held wrote: I get crashes with Win10 in kvm Did you get the crash reliably? I've been struggling how to trigger it efficiently, but currently in vain. The memory pressure isn't a single key to trigger it, as it seems... Yes, I get the crash pretty reliable with Win10 in kvm after 10 to 30 minutes. Some workload in Windows seems to be necessary to trigger the bug.
Re: kvm splat in mmu_spte_clear_track_bits
On 08/27/2017 at 02:35 PM, Adam Borowski wrote: 4.13-rc5 retested fails Crashed only after two hours or so of testing. 4.13-rc4 apparently works It survived several hours of varied tests (like 5 debian-installer runs, a win10 point release upgrade, some hurd package building, openbsd, etc), all while the host was likewise busy. Thus: to the best of my knowledge, the problem is between 4.13-rc4 and 4.13-rc5 but I wouldn't bet my life on it. I get crashes with Win10 in kvm with 4.13-rc5. 4.13-rc4 works for me. THP seems to accelerate the crash, but that's not 100% sure. There's still no crash after reverting merge 27df70 on 4.13-rc7. There are 21 commits in this merge, 10 are mm-related: $ git log 4e082e9ba7cd..e86b298bebf7 --pretty=oneline --abbrev-commit e86b298bebf7 userfaultfd: replace ENOSPC with ESRCH in case mm has gone during copy/zeropage f357e345eef7 zram: rework copy of compressor name in comp_algorithm_store() aac2fea94f7a rmap: do not call mmu_notifier_invalidate_page() under ptl d041353dc98a mm: fix list corruptions on shmem shrinklist af54aed94bf3 mm/balloon_compaction.c: don't zero ballooned pages c0a6a5ae6b5d MAINTAINERS: copy virtio on balloon_compaction.c b3a81d0841a9 mm: fix KSM data corruption 99baac21e458 mm: fix MADV_[FREE|DONTNEED] TLB flush miss problem 0a2dd266dd6b mm: make tlb_flush_pending global 56236a59556c mm: refactor TLB gathering API a9b802500ebb Revert "mm: numa: defer TLB flush for THP migration as long as possible" 0a2c40487f3e mm: migrate: fix barriers around tlb_flush_pending 16af97dc5a89 mm: migrate: prevent racy access to tlb_flush_pending 9eeb52ae712e fault-inject: fix wrong should_fail() decision in task context 4e98ebe5f435 test_kmod: fix small memory leak on filesystem tests 9c56771316ef test_kmod: fix the lock in register_test_dev_kmod() 434b06ae23ba test_kmod: fix bug which allows negative values on two config options a4afe8cdec16 test_kmod: fix spelling mistake: "EMTPY" -> "EMPTY" 5af10dfd0afc userfaultfd: hugetlbfs: remove superfluous page unlock in VM_SHARED case 75dddef32514 mm: ratelimit PFNs busy info message d507e2ebd2c7 mm: fix global NR_SLAB_.*CLAIMABLE counter reads Any hint on what to test first is welcome! Bernhard
Re: kvm splat in mmu_spte_clear_track_bits
On 08/27/2017 at 02:35 PM, Adam Borowski wrote: 4.13-rc5 retested fails Crashed only after two hours or so of testing. 4.13-rc4 apparently works It survived several hours of varied tests (like 5 debian-installer runs, a win10 point release upgrade, some hurd package building, openbsd, etc), all while the host was likewise busy. Thus: to the best of my knowledge, the problem is between 4.13-rc4 and 4.13-rc5 but I wouldn't bet my life on it. I get crashes with Win10 in kvm with 4.13-rc5. 4.13-rc4 works for me. THP seems to accelerate the crash, but that's not 100% sure. There's still no crash after reverting merge 27df70 on 4.13-rc7. There are 21 commits in this merge, 10 are mm-related: $ git log 4e082e9ba7cd..e86b298bebf7 --pretty=oneline --abbrev-commit e86b298bebf7 userfaultfd: replace ENOSPC with ESRCH in case mm has gone during copy/zeropage f357e345eef7 zram: rework copy of compressor name in comp_algorithm_store() aac2fea94f7a rmap: do not call mmu_notifier_invalidate_page() under ptl d041353dc98a mm: fix list corruptions on shmem shrinklist af54aed94bf3 mm/balloon_compaction.c: don't zero ballooned pages c0a6a5ae6b5d MAINTAINERS: copy virtio on balloon_compaction.c b3a81d0841a9 mm: fix KSM data corruption 99baac21e458 mm: fix MADV_[FREE|DONTNEED] TLB flush miss problem 0a2dd266dd6b mm: make tlb_flush_pending global 56236a59556c mm: refactor TLB gathering API a9b802500ebb Revert "mm: numa: defer TLB flush for THP migration as long as possible" 0a2c40487f3e mm: migrate: fix barriers around tlb_flush_pending 16af97dc5a89 mm: migrate: prevent racy access to tlb_flush_pending 9eeb52ae712e fault-inject: fix wrong should_fail() decision in task context 4e98ebe5f435 test_kmod: fix small memory leak on filesystem tests 9c56771316ef test_kmod: fix the lock in register_test_dev_kmod() 434b06ae23ba test_kmod: fix bug which allows negative values on two config options a4afe8cdec16 test_kmod: fix spelling mistake: "EMTPY" -> "EMPTY" 5af10dfd0afc userfaultfd: hugetlbfs: remove superfluous page unlock in VM_SHARED case 75dddef32514 mm: ratelimit PFNs busy info message d507e2ebd2c7 mm: fix global NR_SLAB_.*CLAIMABLE counter reads Any hint on what to test first is welcome! Bernhard
Re: [PATCH v2] X86: don't report PAT on CPUs that don't support it
On 06/07/2017 at 12:49 AM, Mikulas Patocka wrote: Hi Here I send the second version of the patch. It drops the change from boot_cpu_has(X86_FEATURE_PAT) to this_cpu_has(X86_FEATURE_PAT) (that caused kernel to be unbootable for some people). Another change is that setup_arch() calls init_cache_modes() if PAT is disabled, so that init_cache_modes() is always called. Mikulas [PATCH v2] Works for me! CHeers, Bernhard
Re: [PATCH v2] X86: don't report PAT on CPUs that don't support it
On 06/07/2017 at 12:49 AM, Mikulas Patocka wrote: Hi Here I send the second version of the patch. It drops the change from boot_cpu_has(X86_FEATURE_PAT) to this_cpu_has(X86_FEATURE_PAT) (that caused kernel to be unbootable for some people). Another change is that setup_arch() calls init_cache_modes() if PAT is disabled, so that init_cache_modes() is always called. Mikulas [PATCH v2] Works for me! CHeers, Bernhard
Re: [tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that don't support PAT
On 05/30/2017 at 07:59 PM, Mikulas Patocka wrote:
On Tue, 30 May 2017, Dominik Brodowski wrote:
Same boot problem here (Intel(R) Core(TM) i5-5200U CPU on a Dell XPS 13),
git-bisected to the same patch...
On Mon, May 29, 2017 at 06:50:57PM -0400, Mikulas Patocka wrote:
Please do the following three tests and test if the kernel boots.
1. use the PAT patch and revert the change to the function pat_enabled()
- i.e. change it to the original:
bool pat_enabled(void)
{
return !!__pat_enabled;
}
No joy.
2. use the PAT patch and revert the change to the function pat_ap_init
- i.e. change it to the original:
static void pat_ap_init(u64 pat)
{
if (!boot_cpu_has(X86_FEATURE_PAT)) {
Joy.
It is interesting - does it mean that the boot cpu does have PAT and the
secondary CPUs don't? Please send /proc/cpuinfo with all the cores active.
This part of the patch is not required anyway, so I will resubmit the
patch with this part disabled (and with an added call to
init_cache_modes() as Andy suggested).
Mikulas
3. use the full PAT patch and apply the below patch on the top of it.
No joy.
Same result here., only #2 boots.
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Xeon(R) CPU E5450 @ 3.00GHz
stepping: 10
microcode : 0xa0b
cpu MHz : 2000.000
cache size : 6144 KB
physical id : 0
siblings: 4
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm
constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64
monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 xsave lahf_lm
tpr_shadow vnmi flexpriority dtherm
bugs:
bogomips: 5999.70
clflush size: 64
cache_alignment : 64
address sizes : 38 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Xeon(R) CPU E5450 @ 3.00GHz
stepping: 10
microcode : 0xa0b
cpu MHz : 2000.000
cache size : 6144 KB
physical id : 0
siblings: 4
core id : 3
cpu cores : 4
apicid : 3
initial apicid : 3
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm
constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64
monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 xsave lahf_lm
tpr_shadow vnmi flexpriority dtherm
bugs:
bogomips: 5999.98
clflush size: 64
cache_alignment : 64
address sizes : 38 bits physical, 48 bits virtual
power management:
processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Xeon(R) CPU E5450 @ 3.00GHz
stepping: 10
microcode : 0xa0b
cpu MHz : 2000.000
cache size : 6144 KB
physical id : 0
siblings: 4
core id : 2
cpu cores : 4
apicid : 2
initial apicid : 2
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm
constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64
monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 xsave lahf_lm
tpr_shadow vnmi flexpriority dtherm
bugs:
bogomips: 5900.00
clflush size: 64
cache_alignment : 64
address sizes : 38 bits physical, 48 bits virtual
power management:
processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Xeon(R) CPU E5450 @ 3.00GHz
stepping: 10
microcode : 0xa0b
cpu MHz : 2000.000
cache size : 6144 KB
physical id : 0
siblings: 4
core id : 1
cpu cores : 4
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm
constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64
monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 xsave lahf_lm
tpr_shadow vnmi flexpriority dtherm
bugs:
bogomips: 5999.98
clflush size: 64
cache_alignment : 64
address sizes : 38 bits physical, 48 bits virtual
power
Re: [tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that don't support PAT
On 05/30/2017 at 07:59 PM, Mikulas Patocka wrote:
On Tue, 30 May 2017, Dominik Brodowski wrote:
Same boot problem here (Intel(R) Core(TM) i5-5200U CPU on a Dell XPS 13),
git-bisected to the same patch...
On Mon, May 29, 2017 at 06:50:57PM -0400, Mikulas Patocka wrote:
Please do the following three tests and test if the kernel boots.
1. use the PAT patch and revert the change to the function pat_enabled()
- i.e. change it to the original:
bool pat_enabled(void)
{
return !!__pat_enabled;
}
No joy.
2. use the PAT patch and revert the change to the function pat_ap_init
- i.e. change it to the original:
static void pat_ap_init(u64 pat)
{
if (!boot_cpu_has(X86_FEATURE_PAT)) {
Joy.
It is interesting - does it mean that the boot cpu does have PAT and the
secondary CPUs don't? Please send /proc/cpuinfo with all the cores active.
This part of the patch is not required anyway, so I will resubmit the
patch with this part disabled (and with an added call to
init_cache_modes() as Andy suggested).
Mikulas
3. use the full PAT patch and apply the below patch on the top of it.
No joy.
Same result here., only #2 boots.
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Xeon(R) CPU E5450 @ 3.00GHz
stepping: 10
microcode : 0xa0b
cpu MHz : 2000.000
cache size : 6144 KB
physical id : 0
siblings: 4
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm
constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64
monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 xsave lahf_lm
tpr_shadow vnmi flexpriority dtherm
bugs:
bogomips: 5999.70
clflush size: 64
cache_alignment : 64
address sizes : 38 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Xeon(R) CPU E5450 @ 3.00GHz
stepping: 10
microcode : 0xa0b
cpu MHz : 2000.000
cache size : 6144 KB
physical id : 0
siblings: 4
core id : 3
cpu cores : 4
apicid : 3
initial apicid : 3
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm
constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64
monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 xsave lahf_lm
tpr_shadow vnmi flexpriority dtherm
bugs:
bogomips: 5999.98
clflush size: 64
cache_alignment : 64
address sizes : 38 bits physical, 48 bits virtual
power management:
processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Xeon(R) CPU E5450 @ 3.00GHz
stepping: 10
microcode : 0xa0b
cpu MHz : 2000.000
cache size : 6144 KB
physical id : 0
siblings: 4
core id : 2
cpu cores : 4
apicid : 2
initial apicid : 2
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm
constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64
monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 xsave lahf_lm
tpr_shadow vnmi flexpriority dtherm
bugs:
bogomips: 5900.00
clflush size: 64
cache_alignment : 64
address sizes : 38 bits physical, 48 bits virtual
power management:
processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Xeon(R) CPU E5450 @ 3.00GHz
stepping: 10
microcode : 0xa0b
cpu MHz : 2000.000
cache size : 6144 KB
physical id : 0
siblings: 4
core id : 1
cpu cores : 4
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm
constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64
monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 xsave lahf_lm
tpr_shadow vnmi flexpriority dtherm
bugs:
bogomips: 5999.98
clflush size: 64
cache_alignment : 64
address sizes : 38 bits physical, 48 bits virtual
power
Re: [tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that don't support PAT
Hi, this patch breaks the boot of my kernel. The last message is "Booting the kernel.". My setup might be unusual: I'm running a Xenon E5450 (LGA 771) in a Gigbayte G33-DS3R board (LGA 775). The BIOS is patched with the microcode of the E5450 and recognizes the CPU. Please find below the dmesg of a the latest kernel w/o the PAT-patch. I'm happy to provide more information or to test patches. Have fun, Bernhard [0.00] Linux version 4.12.0-rc2-linus+ (berny@quad) (gcc version 6.3.1 20170202 [gcc-6-branch revision 245119] (SUSE Linux) ) #152 SMP PREEMPT Sun May 28 19:26:20 CEST 2017 [0.00] Command line: BOOT_IMAGE=/vmlinuz-4.12.0-rc2-linus+ root=/dev/mapper/VGMX300-root resume=/dev/sda2 showopts radeon.dpm=1 memmap=1$0xe4fd net.ifnames=0 [0.00] KERNEL supported cpus: [0.00] Intel GenuineIntel [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [0.00] x86/fpu: Enabled xstate features 0x3, context size is 576 bytes, using 'standard' format. [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009dbff] usable [0.00] BIOS-e820: [mem 0x0009f800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000f-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xcfed] usable [0.00] BIOS-e820: [mem 0xcfee-0xcfee2fff] ACPI NVS [0.00] BIOS-e820: [mem 0xcfee3000-0xcfee] ACPI data [0.00] BIOS-e820: [mem 0xcfef-0xcfef] reserved [0.00] BIOS-e820: [mem 0xd000-0xdfff] reserved [0.00] BIOS-e820: [mem 0xfec0-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x0001afff] usable [0.00] NX (Execute Disable) protection: active [0.00] e820: user-defined physical RAM map: [0.00] user: [mem 0x-0xe4fc] usable [0.00] user: [mem 0xe4fd-0xe4fd] reserved [0.00] user: [mem 0xe4fe-0x0009dbff] usable [0.00] user: [mem 0x0009f800-0x0009] reserved [0.00] user: [mem 0x000f-0x000f] reserved [0.00] user: [mem 0x0010-0xcfed] usable [0.00] user: [mem 0xcfee-0xcfee2fff] ACPI NVS [0.00] user: [mem 0xcfee3000-0xcfee] ACPI data [0.00] user: [mem 0xcfef-0xcfef] reserved [0.00] user: [mem 0xd000-0xdfff] reserved [0.00] user: [mem 0xfec0-0x] reserved [0.00] user: [mem 0x0001-0x0001afff] usable [0.00] SMBIOS 2.4 present. [0.00] DMI: Gigabyte Technology Co., Ltd. G33-DS3R/G33-DS3R, BIOS F7L 07/31/2009 [0.00] tsc: Fast TSC calibration using PIT [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] e820: last_pfn = 0x1b max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-CDFFF write-protect [0.00] CE000-E uncachable [0.00] F-F write-through [0.00] MTRR variable ranges enabled: [0.00] 0 base 00 mask 0F write-back [0.00] 1 base 00E000 mask 0FE000 uncachable [0.00] 2 base 00D000 mask 0FF000 uncachable [0.00] 3 base 01 mask 0F write-back [0.00] 4 base 01C000 mask 0FC000 uncachable [0.00] 5 base 01B000 mask 0FF000 uncachable [0.00] 6 base 00CFF0 mask 00 uncachable [0.00] 7 disabled [0.00] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WC UC- WT [0.00] mtrr: your BIOS has configured an incorrect mask, fixing it. [0.00] mtrr: your BIOS has configured an incorrect mask, fixing it. [0.00] mtrr: your BIOS has configured an incorrect mask, fixing it. [0.00] mtrr: your BIOS has configured an incorrect mask, fixing it. [0.00] mtrr: your BIOS has configured an incorrect mask, fixing it. [0.00] mtrr: your BIOS has configured an incorrect mask, fixing it. [0.00] mtrr: your BIOS has configured an incorrect mask, fixing it. [0.00] total RAM covered: 6143M [0.00] Found optimal setting for mtrr clean up [0.00] gran_size: 64K chunk_size: 2M num_reg: 7 lose cover RAM: 0G [0.00] e820: update [mem 0xcff0-0x] usable ==> reserved [0.00]
Re: [tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that don't support PAT
Hi, this patch breaks the boot of my kernel. The last message is "Booting the kernel.". My setup might be unusual: I'm running a Xenon E5450 (LGA 771) in a Gigbayte G33-DS3R board (LGA 775). The BIOS is patched with the microcode of the E5450 and recognizes the CPU. Please find below the dmesg of a the latest kernel w/o the PAT-patch. I'm happy to provide more information or to test patches. Have fun, Bernhard [0.00] Linux version 4.12.0-rc2-linus+ (berny@quad) (gcc version 6.3.1 20170202 [gcc-6-branch revision 245119] (SUSE Linux) ) #152 SMP PREEMPT Sun May 28 19:26:20 CEST 2017 [0.00] Command line: BOOT_IMAGE=/vmlinuz-4.12.0-rc2-linus+ root=/dev/mapper/VGMX300-root resume=/dev/sda2 showopts radeon.dpm=1 memmap=1$0xe4fd net.ifnames=0 [0.00] KERNEL supported cpus: [0.00] Intel GenuineIntel [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [0.00] x86/fpu: Enabled xstate features 0x3, context size is 576 bytes, using 'standard' format. [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009dbff] usable [0.00] BIOS-e820: [mem 0x0009f800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000f-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xcfed] usable [0.00] BIOS-e820: [mem 0xcfee-0xcfee2fff] ACPI NVS [0.00] BIOS-e820: [mem 0xcfee3000-0xcfee] ACPI data [0.00] BIOS-e820: [mem 0xcfef-0xcfef] reserved [0.00] BIOS-e820: [mem 0xd000-0xdfff] reserved [0.00] BIOS-e820: [mem 0xfec0-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x0001afff] usable [0.00] NX (Execute Disable) protection: active [0.00] e820: user-defined physical RAM map: [0.00] user: [mem 0x-0xe4fc] usable [0.00] user: [mem 0xe4fd-0xe4fd] reserved [0.00] user: [mem 0xe4fe-0x0009dbff] usable [0.00] user: [mem 0x0009f800-0x0009] reserved [0.00] user: [mem 0x000f-0x000f] reserved [0.00] user: [mem 0x0010-0xcfed] usable [0.00] user: [mem 0xcfee-0xcfee2fff] ACPI NVS [0.00] user: [mem 0xcfee3000-0xcfee] ACPI data [0.00] user: [mem 0xcfef-0xcfef] reserved [0.00] user: [mem 0xd000-0xdfff] reserved [0.00] user: [mem 0xfec0-0x] reserved [0.00] user: [mem 0x0001-0x0001afff] usable [0.00] SMBIOS 2.4 present. [0.00] DMI: Gigabyte Technology Co., Ltd. G33-DS3R/G33-DS3R, BIOS F7L 07/31/2009 [0.00] tsc: Fast TSC calibration using PIT [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] e820: last_pfn = 0x1b max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-CDFFF write-protect [0.00] CE000-E uncachable [0.00] F-F write-through [0.00] MTRR variable ranges enabled: [0.00] 0 base 00 mask 0F write-back [0.00] 1 base 00E000 mask 0FE000 uncachable [0.00] 2 base 00D000 mask 0FF000 uncachable [0.00] 3 base 01 mask 0F write-back [0.00] 4 base 01C000 mask 0FC000 uncachable [0.00] 5 base 01B000 mask 0FF000 uncachable [0.00] 6 base 00CFF0 mask 00 uncachable [0.00] 7 disabled [0.00] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WC UC- WT [0.00] mtrr: your BIOS has configured an incorrect mask, fixing it. [0.00] mtrr: your BIOS has configured an incorrect mask, fixing it. [0.00] mtrr: your BIOS has configured an incorrect mask, fixing it. [0.00] mtrr: your BIOS has configured an incorrect mask, fixing it. [0.00] mtrr: your BIOS has configured an incorrect mask, fixing it. [0.00] mtrr: your BIOS has configured an incorrect mask, fixing it. [0.00] mtrr: your BIOS has configured an incorrect mask, fixing it. [0.00] total RAM covered: 6143M [0.00] Found optimal setting for mtrr clean up [0.00] gran_size: 64K chunk_size: 2M num_reg: 7 lose cover RAM: 0G [0.00] e820: update [mem 0xcff0-0x] usable ==> reserved [0.00]
[PATCH] tcp_bbr: fix Kconfig to be able to make BBR the default congestion algorithm
Add missing line to be able to make BBR the default congestion algorithm. Signed-off-by: Bernhard Held <berny...@gmx.de> --- net/ipv4/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig index 300b068..b54b3ca 100644 --- a/net/ipv4/Kconfig +++ b/net/ipv4/Kconfig @@ -715,6 +715,7 @@ config DEFAULT_TCP_CONG default "reno" if DEFAULT_RENO default "dctcp" if DEFAULT_DCTCP default "cdg" if DEFAULT_CDG + default "bbr" if DEFAULT_BBR default "cubic" config TCP_MD5SIG
[PATCH] tcp_bbr: fix Kconfig to be able to make BBR the default congestion algorithm
Add missing line to be able to make BBR the default congestion algorithm. Signed-off-by: Bernhard Held --- net/ipv4/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig index 300b068..b54b3ca 100644 --- a/net/ipv4/Kconfig +++ b/net/ipv4/Kconfig @@ -715,6 +715,7 @@ config DEFAULT_TCP_CONG default "reno" if DEFAULT_RENO default "dctcp" if DEFAULT_DCTCP default "cdg" if DEFAULT_CDG + default "bbr" if DEFAULT_BBR default "cubic" config TCP_MD5SIG
