Hi,
On Sun, 23 Feb 2020 12:18:37 +0100 (CET)
Mark Kettenis wrote:
>> Date: Sat, 22 Feb 2020 10:40:13 +0900 (JST)
>> From: YASUOKA Masahiko
>> efiboot is using ACPI UID to determine the minor number of comX.
(snip)
>> I originally wrote this code, because I thought ACPI UID enumeration
>> is bett
When I played with ipmi, I found problems in the initializing
watchdog.
As far as my test on HPE DL20 Gen10, the ipmi device refuses "set
watchdog timer" command if "use" value (in first byte) is none. Since
existing code uses the value which read from the device, if the value
is not set on the d
On Mon, Feb 24 2020 15:33:35 -0500, Ted Unangst wrote:
> Martin Pieuchot wrote:
> > On 24/02/20(Mon) 11:29, Lauri Tirkkonen wrote:
> > > On Mon, Feb 24 2020 10:24:53 +0100, Martin Pieuchot wrote:
> > > > On 23/02/20(Sun) 14:48, Lauri Tirkkonen wrote:
> > > > > I was working on a make jobserver impl
Hi,
On HPE DL20 Gen10, kernel keeps printing "ipmi0: sendcmd fails" if
ipmi0 is enabled.
The machine has following 4 sensor devices.
19-P/S 1 Inlet
20-P/S 2 Inlet
21-P/S 1
22-P/S 2
But reading value from these devices fails always. This causes the
problem above.
The diff makes such th
Hi,
On Fri, 21 Feb 2020 18:55:38 -0600
Andrew Daugherity wrote:
> On Thu, Feb 20, 2020 at 11:10 PM YASUOKA Masahiko wrote:
>> Hello,
>>
>> I am testing a new hardware, HPE DL20 Gen10.
>>
>> When efiboot starts the kernel, the video display becomes distorted
>> and never recovered until CPU reset
Hi,
When trying to bind to ldapd using a dn which has an invalid
userPassword entry, e.eg. a “defective” SHA valus like “{SHA}alpha”,
ldapd currently returns 1 (Operations Error).
The patch below changes this to 49 (Invalid Credentials).
There are basically two reasons for this:
1. The userPass
On Sun, Mar 01, 2020 at 02:16:20PM +0100, Mark Kettenis wrote:
> This probably means that msleep(4) has a similar issue.
Here is the diff for msleep() and rwsleep().
bluhm
Index: kern/kern_synch.c
===
RCS file: /data/mirror/openbsd/
> Date: Sun, 1 Mar 2020 14:02:53 +0100
> From: Alexander Bluhm
>
> Hi,
>
> I had a 6.6 machine where a lot of git processes got stuck sleeping
> on "futex". The process holding the futex rwlock was this one.
>
> 33293 332235 1 2734 30x800483 fsleepgit
>
> It called mi_s
Hi,
I had a 6.6 machine where a lot of git processes got stuck sleeping
on "futex". The process holding the futex rwlock was this one.
33293 332235 1 2734 30x800483 fsleepgit
It called mi_switch() from proc_stop() with this trace.
issignal(80002acc74a8) at issignal+0