Приглашаем к публикации [РИНЦ]
___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 246940] [wishlist/enhancement, patch incl.]: idle user tasks should be charged as "nice" or "idle" CPU time
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246940
--- Comment #7 from t.eichsta...@gmx.net ---
(In reply to Conrad Meyer from comment #6)
Good morning, and thx for your time.
>> [mixed up nice & priority]
> This is a misunderstanding. Nice and priority are orthogonal.
OK I'll try harder to be more precise and choose the right verbs.
>> [my assumption: load values ~ runtime sched classes]
> This is also a misunderstanding; it isn't the categorization used by cp_times.
> [...] That's it.
OK. Got that. Wrong assumption/association.
> I think it would be reasonable to collect and expose the data you want, [...]
I'm glad to hear that. Do you mean to weave in the computations to update a
modern clone of cp_time, with additional fields for the non-traditional (soft)
realtime & user_idle classes, into the "if(usermode)"-branch of statclock()?
And clone the resp. SYSCTL_PROCs for the overall and per-cpu cp_time(s)?
Is it possible to simply add a flag to the existing one and use the very same
function for both sysctl's? Or do we need a wrapper function? These functions
seem to be so simple, I'd resist to copy&paste when all that's different is the
number of fields in an array. Is there an implicit mutex or lock set by one of
these SYSCTL_XXX macros? I have no clue about these SYSCTL things... if you
want do that because it's trivial and useful anyway, I'm happy. If you want to
let me do it instead, because I'm the only one asking for it, I'll dive into it
and come up with a suggestion. Would that need to be against the
FBSD-13_CURRENT src?
> If we want to provide a better laptop experience, it needs to work out of the
> box.
+++ IMHO we can assume laptop users enable powerd or such, and others do not.
> (†): User-driven frequency scaling is kind of a losing game at this point,
> especially with powerd. Idle C-states consume almost nothing regardless of
> frequency.
When any other except the kernel idle task is running, the cpu is in the C0
state, right? So the states >=C1 are not reached as long there's some task
ready to run, because the scheduler picks it up to let it run, right? Thus, to
achieve what I consider ("cool" user_idle tasks), the runtime scheduler had to
provide a mechanism to artificially "retard" an (or all) idle user task, i.e.
give it less time slices (less often), which it currently does not do on an
otherwise idle system. I'm not aware of such a mechanism. The implicit
assumption of the scheduler is to get all work done, optimized and
parameterized for a mix of speed, throughput and (by architecture) "fairness",
and it has no notion neither for ernergy efficiency nor absolute power
consumption. If you suggest the better solution would be to update the
scheduler instead, I'd be interested as well, but probably that's beyond my
current skills. More likely than not. Anyway, it'd be much more complicated
and - foremost - dangerous.
Regarding power consumption, the cpu freq is the dominating factor (in C0
state). That's basic physics. Am I wrong here? Freq scaling based on load
values is what exists and will be in use for the lifetime of today's machines.
If you can point me to what powerd does methodically wrong (other than the
mentioned handling of independant cores), feel free to do so. Likewise, any
other better solution - I welcome your hints.
> Powerd doesn't know how to manage frequency on multiple independent CPUs.
I'll have a look at that. Is this possible on a one-package two-core SMT
system? I have a Core i7-5600U, that's what I can test on bare metal. These
things never interested me more than to survive a test at the univ. Obviously
two virtual SMT cores on one physical core can not have different freqs. The
rest is what I "just use", but if I have to dive into that, I'll do so.
> Intel is moving away from OS-driven p-states entirely; future CPUs will
> simply
> not support it. (Instead, cores can be set to an energy efficiency
> profile on some 0-100 percentage scale.)
Sounds like KISS. It's important to support new hardware, but it's also fair
to support existing hw during it's lifetime. Let's say, two decades.
Sorry for the lengthy mail - I want to have this going (i.e. "cool" user_idle).
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 246951] Regular crash: panic, trap_pfault, ip_input || ip_output using ipSec, AES-NI & CARP
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246951 Bug ID: 246951 Summary: Regular crash: panic, trap_pfault, ip_input || ip_output using ipSec, AES-NI & CARP Product: Base System Version: 11.3-STABLE Hardware: amd64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: freebsd-bugzilla@biscuit.ninja Created attachment 215186 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=215186&action=edit Compilation of crash dump information Hello, We're using FreeBSD 11.3 Stable (pfSense). We have encountered numerous kernel panics during recent months (see attached). They are all trap_pfault and usually feature ip_input or ip_output. The pfSense boxes are in a CARP configuration (the crash is always on the active firewall). We are using IPSec (AES256-GCM, SHA256) and AES-NI. Many but not all of the stack traces include IPSec and AES-NI calls.All interfaces are using switch independent failover LAGG. Using FreeBSD 11.2-RELEASE-p3 without producing this problem. There is one other person who appears to have the same problem: https://forum.netgate.com/topic/151329/pfsense-active-carp-member-crashed-aesni_process-crypto_dispatch/12 Hardware is as follows: * Dell PowerEdge R330 * Intel Xeon E3-1270 v5 * Intel I350 Quad Port 1GbE network cards (x2) We are just wondering if you can give any pointers as to the potential cause/resolution? Thank you -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 246951] Regular crash: panic, trap_pfault, ip_input || ip_output using ipSec, AES-NI & CARP
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246951 Mark Linimon changed: What|Removed |Added Keywords||panic Assignee|b...@freebsd.org|n...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 246630] stable/11 regression: base.txz reproducibility depends on number of cpu cores
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246630 --- Comment #25 from Ed Maste --- (In reply to Alexandre Ganea from comment #23) Thanks for the reply on this issue Alexandre. It seems rather unlikely that your change could be directly responsible for this issue and that it's more likely just exposing a latent issue or some sort of second order effect. It seems like we might want to disable the behaviour by default in stable/11 and stable/12, what do you think dim? -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 238389] no booting after installation from the FreeBSD-12.0-RELEASE image.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238389 Mark Johnston changed: What|Removed |Added CC||ma...@freebsd.org Status|New |Closed Resolution|--- |Overcome By Events --- Comment #2 from Mark Johnston --- Sorry for the delayed reply, but there is very little information here. What does "does not boot" mean? Where it does it fail? What kind of system is it? Have you tried 12.1? I will close the bug for now, since it has been a year. Please re-open with answers to the above questions if you are willing to pursue this. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 204521] [new driver] [request] Port rtsx from OpenBSD to FreeBSD
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204521 --- Comment #163 from Gleb Popov --- (In reply to Henri Hennebert from comment #162) The test was mostly successfull. dd'ing from a random file to /dev/mmcsd0 was successfull. However, reading the file back resulted in rtsx0: Controller timeout rtsx0: Soft reset mmcsd0: Error indicated: 1 Timeout This happens randomly after starting reading from the card, after reading about 50 Mb. Playing with block size doesn't seem to change anything. Creating a FAT filesystem and a file on it also worked. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 246960] file(1) does not report PIE binaries
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246960 Bug ID: 246960 Summary: file(1) does not report PIE binaries Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: ema...@freebsd.org Reproduction steps: 1. build a PIE (position independent executable) binary: $ cc -fpie -pie -o hello ~/hello.c $ ./hello Hello, world 2. use file to determine the type: $ file hello hello: ELF 64-bit LSB shared object, x86-64, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 13.0 (1300087), FreeBSD-style, with debug_info, not stripped As of very recently we have a DF_1_PIE flag to indicate that this is a PIE binary, not a DSO: $ readelf -d hello Dynamic section at offset 0xc20 contains 25 entries: TagType Name/Value 0x0001 NEEDED Shared library: [libc.so.7] 0x6ffb FLAGS_1 PIE We should report something like "ELF 64-bit LSB position independent executable..." from file/libmagic. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 246630] stable/11 regression: base.txz reproducibility depends on number of cpu cores
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246630 --- Comment #26 from Dimitry Andric --- Created attachment 215200 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=215200&action=edit Reproduction files for printf.c This is a tarball with reproduction files for compiling printf.c, which should be completely standalone. Contents: bug246630-repro/printf-699ef3.c bug246630-repro/printf-699ef3.sh Note that the shell script already invokes clang -cc1, so it will not do anything special (AFAIK) with the spawn-new-cc setting. But it could be used to attempt to detect undefined behavior or usage of uninitialized memory. Since valgrind doesn't work on FreeBSD, I had to resort to running it on Linux, and there I get: ==120363== Conditional jump or move depends on uninitialised value(s) ==120363==at 0x1634474: llvm::ConstantExpr::getGetElementPtr(llvm::Type*, llvm::Constant*, llvm::ArrayRef, bool, llvm::Optional, llvm::Type*) (Constants.cpp:2191) ==120363==by 0x112D6D9: getGetElementPtr (Constants.h:1163) ==120363==by 0x112D6D9: (anonymous namespace)::SymbolicallyEvaluateGEP(llvm::GEPOperator const*, llvm::ArrayRef, llvm::DataLayout const&, llvm::TargetLibraryInfo const*) (ConstantFolding.cpp:1005) ==120363==by 0x112DF70: (anonymous namespace)::ConstantFoldInstOperandsImpl(llvm::Value const*, unsigned int, llvm::ArrayRef, llvm::DataLayout const&, llvm::TargetLibraryInfo const*) (ConstantFolding.cpp:1039) ==120363==by 0x112C165: (anonymous namespace)::ConstantFoldConstantImpl(llvm::Constant const*, llvm::DataLayout const&, llvm::TargetLibraryInfo const*, llvm::SmallDenseMap, llvm::detail::DenseMapPair >&) [clone .part.0] (ConstantFolding.cpp:1114) ==120363==by 0x112C5CF: llvm::ConstantFoldConstant(llvm::Constant const*, llvm::DataLayout const&, llvm::TargetLibraryInfo const*) (ConstantFolding.cpp:1194) ==120363==by 0x188F410: prepareICWorklistFromFunction (InstructionCombining.cpp:3584) ==120363==by 0x188F410: combineInstructionsOverFunction(llvm::Function&, llvm::InstCombineWorklist&, llvm::AAResults*, llvm::AssumptionCache&, llvm::TargetLibraryInfo&, llvm::DominatorTree&, llvm::OptimizationRemarkEmitter&, llvm::BlockFrequencyInfo*, llvm::ProfileSummaryInfo*, unsigned int, llvm::LoopInfo*) (InstructionCombining.cpp:3703) ==120363==by 0x189205F: runOnFunction (InstructionCombining.cpp:3789) ==120363==by 0x189205F: llvm::InstructionCombiningPass::runOnFunction(llvm::Function&) (InstructionCombining.cpp:3768) ==120363==by 0x16F4352: llvm::FPPassManager::runOnFunction(llvm::Function&) (LegacyPassManager.cpp:1482) ==120363==by 0x16F4DE8: llvm::FPPassManager::runOnModule(llvm::Module&) (LegacyPassManager.cpp:1518) ==120363==by 0x16F51A2: runOnModule (LegacyPassManager.cpp:1583) ==120363==by 0x16F51A2: llvm::legacy::PassManagerImpl::run(llvm::Module&) (LegacyPassManager.cpp:1695) ==120363==by 0x1FF4CFE: EmitAssembly (BackendUtil.cpp:954) ==120363==by 0x1FF4CFE: clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::unique_ptr >) (BackendUtil.cpp:1677) ==120363==by 0x2C471A8: clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (CodeGenAction.cpp:335) ==120363== Uninitialised value was created by a stack allocation ==120363==at 0x112C653: (anonymous namespace)::SymbolicallyEvaluateGEP(llvm::GEPOperator const*, llvm::ArrayRef, llvm::DataLayout const&, llvm::TargetLibraryInfo const*) (ConstantFolding.c I'm trying to reduce this now. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 246630] stable/11 regression: base.txz reproducibility depends on number of cpu cores
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246630
--- Comment #27 from commit-h...@freebsd.org ---
A commit references this bug:
Author: dim
Date: Wed Jun 3 16:51:30 UTC 2020
New revision: 361755
URL: https://svnweb.freebsd.org/changeset/base/361755
Log:
Disable clang's -fintegrated-cc1 stage by default
In bug 246630, it was found that part of the rescue binary could be
compiled to very slightly different (but still equivalent) machine code,
depending on the number of simultaneous make jobs (via the -j option).
This turned out to be caused by the upstream change that made clang's
first stage compiler (i.e. the -cc1 stage) run as part of the initial
clang process invocation, instead of forking and exec'ing a new clang
process.
We are currently investigating the root cause for the difference in
output, but while that is ongoing, disable the integrated cc1 stage for
now to work around it. You can always turn it on explicitly by using the
-fintegrated-cc1 option, or turn it off with -fno-integrated-cc1.
Direct commit to stable/{11,12}, so this can hopefully end up in the
upcoming 11.4-RELEASE.
Reported by: Fabian Keil
PR: 246630
Changes:
stable/11/lib/clang/include/clang/Config/config.h
stable/12/lib/clang/include/clang/Config/config.h
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 246962] fsck_ffs frequently requires multiple runs
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246962 Bug ID: 246962 Summary: fsck_ffs frequently requires multiple runs Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: ma...@freebsd.org I use a FreeBSD HEAD VM for development, with SU (no journaling) on the root FS. It panics frequently, and often drops me off in single user mode after fsck_ffs returns a non-zero exit status: -- Starting file system checks: /dev/gpt/rootfs: INCORRECT BLOCK COUNT I=330657 (8 should be 0) (CORRECTED) /dev/gpt/rootfs: INCORRECT BLOCK COUNT I=330658 (8 should be 0) (CORRECTED) /dev/gpt/rootfs: INCORRECT BLOCK COUNT I=330660 (8 should be 0) (CORRECTED) /dev/gpt/rootfs: INCORRECT BLOCK COUNT I=330661 (8 should be 0) (CORRECTED) /dev/gpt/rootfs: INCORRECT BLOCK COUNT I=330665 (8 should be 0) (CORRECTED) /dev/gpt/rootfs: INCORRECT BLOCK COUNT I=330666 (16 should be 0) (CORRECTED) ... /dev/gpt/rootfs: ZERO LENGTH DIR I=727410 OWNER=root MODE=41777 /dev/gpt/rootfs: SIZE=0 MTIME=Jun 3 11:00 2020 (CLEARED) /dev/gpt/rootfs: FREE BLK COUNT(S) WRONG IN SUPERBLK (SALVAGED) /dev/gpt/rootfs: SUMMARY INFORMATION BAD (SALVAGED) /dev/gpt/rootfs: BLK(S) MISSING IN BIT MAPS (SALVAGED) /dev/gpt/rootfs: 51340 files, 1475643 used, 3343995 free (5475 frags, 417315 blocks, 0.1% fragmentation) * PLEASE RERUN FSCK * WARNING: /: reload pending error: blocks 184 files 8 Automatic file system check failed; help! ERROR: ABORTING BOOT (sending SIGTERM to parent)! 2020-06-03T08:15:42.153887-04:00 init 1 - - /bin/sh on /etc/rc terminated abnormally, going to single user mode -- Then, running fsck_ffs again returns with no errors: -- root@:/ # fsck_ffs -y / ** /dev/gpt/rootfs ** Last Mounted on / ** Root file system ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 51340 files, 1475643 used, 3343995 free (5475 frags, 417315 blocks, 0.1% fragmentation) * FILE SYSTEM MARKED CLEAN * -- Why does fsck_ffs require a restart here? I know that there is some rc.conf variable I can set to work around this, but it looks like it shouldn't be necessary to begin with. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 246307] Kernel panic when running sysctl -a | grep igb
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246307 Mark Johnston changed: What|Removed |Added CC||d...@dpdtech.com --- Comment #2 from Mark Johnston --- *** Bug 243993 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 204521] [new driver] [request] Port rtsx from OpenBSD to FreeBSD
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204521 --- Comment #164 from Jesper Schmitz Mouridsen --- Thanks gleb for the test. Testing rtsx0@pci0:1:0:0: class=0xff card=0x522910ec chip=0x522910ec rev=0x01 hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTS5229 PCI Express Card Reader' bar [10] = type Memory, range 32, base 0x9120, size 4096, enabled my self in my Lenovo ideapad 120S-14IAP I could not replicate. dd random to mmcsd0 as well as reading back did not fail. I wonder how a bad card behaves... -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 204521] [new driver] [request] Port rtsx from OpenBSD to FreeBSD
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204521 --- Comment #165 from Henri Hennebert --- (In reply to Jesper Schmitz Mouridsen from comment #164) I am lost in the readers you test. can you give the list of card reader, freebsd version and make of the computer. So I will complete the README.md Thanks in advance. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 204521] [new driver] [request] Port rtsx from OpenBSD to FreeBSD
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204521 --- Comment #166 from Jesper Schmitz Mouridsen --- (In reply to Henri Hennebert from comment #165) Yes of course. I have tested RTS5229 PCI Express Card Reader on Lenovo ideapad 120S-14IAP successfully on FreeBSD 12.1-RELEASE-p1 and on Manufacturer: LENOVO Product Name: 5017AA5 Version: ThinkPad L520 rtsx0@pci0:4:0:0: class=0xff rev=0x01 hdr=0x00 vendor=0x10ec device=0x5209 subvendor=0x17aa subdevice=0x21dd vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTS5209 PCI Express Card Reader' bar [10] = type Memory, range 32, base 0xf060, size 4096, enabled with version FreeBSD 13.0-CURRENT #0 r361019 which also works successfully. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 246630] stable/11 regression: base.txz reproducibility depends on number of cpu cores
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246630
--- Comment #28 from commit-h...@freebsd.org ---
A commit references this bug:
Author: dim
Date: Wed Jun 3 21:22:15 UTC 2020
New revision: 361772
URL: https://svnweb.freebsd.org/changeset/base/361772
Log:
MF11 r361755:
Disable clang's -fintegrated-cc1 stage by default
In bug 246630, it was found that part of the rescue binary could be
compiled to very slightly different (but still equivalent) machine code,
depending on the number of simultaneous make jobs (via the -j option).
This turned out to be caused by the upstream change that made clang's
first stage compiler (i.e. the -cc1 stage) run as part of the initial
clang process invocation, instead of forking and exec'ing a new clang
process.
We are currently investigating the root cause for the difference in
output, but while that is ongoing, disable the integrated cc1 stage for
now to work around it. You can always turn it on explicitly by using the
-fintegrated-cc1 option, or turn it off with -fno-integrated-cc1.
Direct commit to stable/{11,12}, so this can hopefully end up in the
upcoming 11.4-RELEASE.
Approved by: re (gjb)
Reported by: Fabian Keil
PR: 246630
Changes:
_U releng/11.4/
releng/11.4/lib/clang/include/clang/Config/config.h
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243225] "mpr0: Out of chain frames" boot hang after clang 9.0.1 import (probably timing, not compiler related)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243225 Warner Losh changed: What|Removed |Added CC||i...@freebsd.org --- Comment #4 from Warner Losh --- Looking at the source we see: mpr_dprint(sc, MPR_INFO, "Out of chain frames, " "consider increasing hw.mpr.max_chains.\n"); Have you increased hw.mpr.max_chains? We use this sort of controller all the time (though we don't use tape drive) at work and haven't seen this at all. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243225] "mpr0: Out of chain frames" boot hang after clang 9.0.1 import (probably timing, not compiler related)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243225 --- Comment #5 from Terry Kennedy --- (In reply to Warner Losh from comment #4) I tried increasing it and it doesn't help. This happens during the initial device probe at boot time. We should only need chain frames if we're doing I/O to a connected peripheral, and this error happens even without the tape drive (or anything else) connected. Changing the slot the controller is in, enabling/disabling hyperthreading, or sometimes just sitting at the loader prompt before proceeding will make the problem disappear. My guess is that it is a timing loop that is close to marginal, depending on the other hardware in the system. When the problem manifests, the system goes down the rabbit hole of "out of chain frames", probably because the code thinks the only reason for an error in that part of the path is running out of chain frames. This is a Dell R730 (complete description in prior reply) so I can capture the complete boot as a video and make the video (and player app) available if anyone wants to look at it. Alternatively, I can provide remore access (console, reset, etc) via the Dell iDRAC controller. The problem has persisted from 12.0 to the latest 12-STABLE. All hardware is up-to-date, Dell has replaced the controller multiple times and the tape drive and cable once. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 212258] bootpool is not imported after reboot on a MBR partitioned drive
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212258 --- Comment #19 from David Christensen --- (In reply to David Christensen from comment #18) Problem persists after upgrading system: 2020-06-03 20:34:29 toor@vf1 ~ # zpool list NAMESIZE ALLOC FREE CKPOINT EXPANDSZ FRAGCAP DEDUP HEALTH ALTROOT vf1_zroot 3.75G 690M 3.08G- - 3%17% 1.00x ONLINE - 2020-06-03 20:34:31 toor@vf1 ~ # freebsd-version && uname -a 12.1-RELEASE-p5 FreeBSD vf1.tracy.holgerdanske.com 12.1-RELEASE-p5 FreeBSD 12.1-RELEASE-p5 GENERIC amd64 2020-06-03 20:36:54 toor@vf1 ~ # gpart show ada0 ada0s1 => 63 14673585 ada0 MBR (7.0G) 63 1- free - (512B) 64 14673584 1 freebsd [active] (7.0G) => 0 14673584 ada0s1 BSD (7.0G) 0 4194304 1 freebsd-zfs (2.0G) 4194304 2097152 2 freebsd-swap (1.0G) 6291456 8382128 4 freebsd-zfs (4.0G) 2020-06-03 20:37:32 toor@vf1 ~ # zpool import pool: bootpool id: 13757577973895316021 state: ONLINE action: The pool can be imported using its name or numeric identifier. config: bootpoolONLINE ada0s1a ONLINE 2020-06-03 20:37:38 toor@vf1 ~ # zpool import -f bootpool 2020-06-03 20:38:02 toor@vf1 ~ # zpool list NAMESIZE ALLOC FREE CKPOINT EXPANDSZ FRAGCAP DEDUP HEALTH ALTROOT bootpool 1.88G 209M 1.67G- - 0%10% 1.00x ONLINE - vf1_zroot 3.75G 690M 3.08G- - 4%17% 1.00x ONLINE - 2020-06-03 20:38:14 toor@vf1 ~ # zpool status pool: bootpool state: ONLINE scan: none requested config: NAMESTATE READ WRITE CKSUM bootpoolONLINE 0 0 0 ada0s1a ONLINE 0 0 0 errors: No known data errors pool: vf1_zroot state: ONLINE scan: none requested config: NAMESTATE READ WRITE CKSUM vf1_zroot ONLINE 0 0 0 ada0s1d ONLINE 0 0 0 errors: No known data errors -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
