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. Unl
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 code
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 code
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
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 g
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 s
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
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.
>
