SD card reader only works after a suspend/resume
Hi, I discovered this by chance. The SD card reader in my laptop has never worked, but now I noticed it does after suspending and resuming. The controller is probed and attached on boot: sdhci_acpi1: iomem 0x90a0-0x90a00fff irq 47 on acpi0 But nothing happens if I put a card in. Unless I suspend and resume: mmc1: on sdhci_acpi1 mmcsd0: 32GB at mmc1 50.0MHz/4bit/65535-block Then I can remove and replug cards and it seems to work just fine. Jakob ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Celeron J3160 with enabled Turbo mode stays at 480MHz(lowestsetting) forever and can not lower frequency without Tuebo mode
On 06.09.2018 4:15, Benjamin Kaduk wrote: > Okay, "system openssl" and the FreeBSD version is enough to nail down the > code and configuration, and I see the processor type is in the subject > line. I guess posting the CPU features bits from dmesg might save whoever > tries to track down the codepaths being used some time (unless that was > posted already and I missed it?). I'll post it tonight, but I don't think it is very openssl-specific or thermal throttling. I've monitored temperatures, of course, and monitored frequencies with turbostat. With Turbo enabled freuqnces jumps wildly and were lower than with Turbo disabled. And anyway, even frequencies jumps were not large enough to explain x3.5 difference. Another thing which puzzles me, that with Turbo disabled (!) I see frequencies 2666MHz accroding to turbostat, which seems impossible, as it is higher than official Turbo frequency (!). I don't know how to explain this. Maybe, turbostat fails? -- // Lev Serebryakov ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Celeron J3160 with enabled Turbo mode stays at 480MHz(lowestsetting) forever and can not lower frequency without Tuebo mode
On 06.09.2018 4:15, Benjamin Kaduk wrote: > Okay, "system openssl" and the FreeBSD version is enough to nail down the > code and configuration, and I see the processor type is in the subject > line. I guess posting the CPU features bits from dmesg might save whoever > tries to track down the codepaths being used some time (unless that was > posted already and I missed it?). CPU: Intel(R) Celeron(R) CPU J3160 @ 1.60GHz (1600.05-MHz K8-class CPU) Origin="GenuineIntel" Id=0x406c4 Family=0x6 Model=0x4c Stepping=4 Features=0xbfebfbff Features2=0x43d8e3bf AMD Features=0x28100800 AMD Features2=0x101 Structured Extended Features=0x2282 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics And here are two outputs of turbostat with additional settings: turbostat, Turbo DISABLED: CPUID(0): GenuineIntel 11 CPUID levels; family:model:stepping 0x6:4c:4 (6:76:4) CPUID(1): SSE3 MONITOR - EIST TM2 TSC MSR ACPI-TM TM CPUID(6): APERF, No-TURBO, DTS, No-PTM, No-HWP, No-HWPnotify, No-HWPwindow, No-HWPepp, No-HWPpkg, EPB cpu3: MSR_IA32_MISC_ENABLE: 0x4000850089 (TCC EIST No-MWAIT PREFETCH No-TURBO) CPUID(7): No-SGX cpu3: MSR_PLATFORM_INFO: 0x60002001400 6 * 133.3 = 800.0 MHz max efficiency frequency 20 * 133.3 = 2666.6 MHz base frequency cpu3: MSR_IA32_POWER_CTL: 0x (C1E auto-promotion: DISabled) cpu3: MSR_TURBO_RATIO_LIMIT: 0x cpu3: MSR_PKG_CST_CONFIG_CONTROL: 0x0014000f (UNlocked: pkg-cstate-limit=15: unknown) NSFOD /sys/devices/system/cpu/cpu3/cpufreq/scaling_driver cpu0: MSR_IA32_ENERGY_PERF_BIAS: 0x (performance) cpu2: MSR_IA32_ENERGY_PERF_BIAS: 0x (performance) cpu0: MSR_IA32_TEMPERATURE_TARGET: 0x005a (90 C) cpu2: MSR_IA32_TEMPERATURE_TARGET: 0x005a (90 C) turbostat, Turbo ENABLED: CPUID(0): GenuineIntel 11 CPUID levels; family:model:stepping 0x6:4c:4 (6:76:4) CPUID(1): SSE3 MONITOR - EIST TM2 TSC MSR ACPI-TM TM CPUID(6): APERF, TURBO, DTS, No-PTM, No-HWP, No-HWPnotify, No-HWPwindow, No-HWPepp, No-HWPpkg, EPB cpu1: MSR_IA32_MISC_ENABLE: 0x00850089 (TCC EIST No-MWAIT PREFETCH TURBO) CPUID(7): No-SGX cpu1: MSR_PLATFORM_INFO: 0x60002001400 6 * 133.3 = 800.0 MHz max efficiency frequency 20 * 133.3 = 2666.6 MHz base frequency cpu1: MSR_IA32_POWER_CTL: 0x (C1E auto-promotion: DISabled) cpu1: MSR_TURBO_RATIO_LIMIT: 0x cpu1: MSR_PKG_CST_CONFIG_CONTROL: 0x0014000f (UNlocked: pkg-cstate-limit=15: unknown) NSFOD /sys/devices/system/cpu/cpu1/cpufreq/scaling_driver cpu0: MSR_IA32_ENERGY_PERF_BIAS: 0x (performance) cpu2: MSR_IA32_ENERGY_PERF_BIAS: 0x (performance) cpu0: MSR_IA32_TEMPERATURE_TARGET: 0x005a (90 C) cpu2: MSR_IA32_TEMPERATURE_TARGET: 0x005a (90 C) -- // Lev Serebryakov ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SD card reader only works after a suspend/resume
On Thu, Sep 06, 2018 at 12:33:39PM +0200, Jakob Alvermark wrote: > Hi, > > > I discovered this by chance. > > The SD card reader in my laptop has never worked, but now I noticed it > does after suspending and resuming. > > The controller is probed and attached on boot: > > sdhci_acpi1: iomem > 0x90a0-0x90a00fff irq 47 on acpi0 > > But nothing happens if I put a card in. Unless I suspend and resume: > > mmc1: on sdhci_acpi1 > mmcsd0: 32GB at mmc1 > 50.0MHz/4bit/65535-block > > Then I can remove and replug cards and it seems to work just fine. I believe that making SD card insertion/removal with the integrated SDHCI controlers of newer Intel SoCs work out-of-the-box requires support for ACPI GPE interrupts and ACPI GPIO events respectively to be added to FreeBSD. Otherwise insertion/removal interrutps/events aren't reported and polling the card present state doesn't generally work as a workaround with these controllers either, unfortunately. I'm not aware of anyone working on the former, though. Polling the card present state happens to work one time after SDHCI initialization with these controllers which is why a card will be attached when inserted as part of a suspend/resume cycle (resume of mmc(4) had some bugs until some months ago, which probably explains why that procedure hasn't worked as a workaround for you in the past). Inserting the card before boot, unloading/loading sdhci_acpi.ko or triggering detach/attach of sdhci_acpi(4) via devctl(8) should allow to attach a card, too. Marius ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: github freebsd and svn freebsd
On 4 September 2018 at 06:53, Kurt Jaeger wrote: > > The github repo isn't official, because there are still some > consistency issues. The consistency problem is: If an repo-copy > from svn to git is done, how can that repo-copy be done a second > time and still keep the same commit ids (in the git repo) ? Restarting a svn->git conversion from scratch will usually generate the same commit hashes. However, there's an unfortunate point where the svn mirroring messed up [1] that resulted in bogus metadata on the manufactured git commit, and all hashes from that point on are broken. (Ironically this was from a bug in the svn mirroring process, not the svn->git conversion or git itself.) Assuming we're confident the issue in the svn mirroring process is fixed and will not recur we can redo the conversion, with a one-time change to all hashes from the offending commit on, and they would not change again in the future. [1] https://github.com/freebsd/freebsd/commit/c5e8194f33abf05314599d63c1e00d01aa354f47 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: github freebsd and svn freebsd
On Thu, Sep 6, 2018, 5:49 PM Ed Maste wrote: > On 4 September 2018 at 06:53, Kurt Jaeger wrote: > > > > The github repo isn't official, because there are still some > > consistency issues. The consistency problem is: If an repo-copy > > from svn to git is done, how can that repo-copy be done a second > > time and still keep the same commit ids (in the git repo) ? > > Restarting a svn->git conversion from scratch will usually generate > the same commit hashes. However, there's an unfortunate point where > the svn mirroring messed up [1] that resulted in bogus metadata on the > manufactured git commit, and all hashes from that point on are broken. > (Ironically this was from a bug in the svn mirroring process, not the > svn->git conversion or git itself.) > > Assuming we're confident the issue in the svn mirroring process is > fixed and will not recur we can redo the conversion, with a one-time > change to all hashes from the offending commit on, and they would not > change again in the future. > > [1] > https://github.com/freebsd/freebsd/commit/c5e8194f33abf05314599d63c1e00d01aa354f47 What is the upgrade story for current users? How do they cut over? We need a how to or something in the handbook. Warner > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Reviewer needed for D17067
FreeBSD recently introduced a new ELF auxiliary vector, AT_EHDRFLAGS. procstat(1) needs to be updated to reflect the new auxvec. Patch is up for review here: https://reviews.freebsd.org/D17067 Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: github freebsd and svn freebsd
On 6 September 2018 at 20:11, Warner Losh wrote: > >> Assuming we're confident the issue in the svn mirroring process is >> fixed and will not recur we can redo the conversion, with a one-time >> change to all hashes from the offending commit on, and they would not >> change again in the future. > > What is the upgrade story for current users? How do they cut over? We need a > how to or something in the handbook. Yes, we'd need to have a fully documented migration process, and we should be able to have both 'old' and 'new' branches exist in parallel for some time. One way we could handle the mechanics of the migration itself is: * Create an alias for the current master branch - say, master-gen1 * Continue running the existing conversion * Start running a fixed svn-git conversion which pushes to master-gen2 * Document the process for migrating downstream work from one to the other * Switch master to master-gen2 * Deprecate master-gen1 after a suitable period Because of the way git works the additional branch would result in only a nominal increase in repository size. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
