On Fri, May 13, 2016 at 3:59 AM, David Gwynne wrote:
>
>> On 12 May 2016, at 20:28, Alexey Suslikov wrote:
>>
>> On Wed, Apr 27, 2016 at 7:22 PM, Theo de Raadt
>> wrote:
On 27/04/16(Wed) 15:45, Alexey Suslikov wrote:
> Theo de Raadt cvs.openbsd.org> writes:
>
>>
>> Most of
On Thu, May 12, 2016 at 11:00:54PM +0200, Mark Kettenis wrote:
> > Date: Thu, 12 May 2016 22:31:37 +0200
> > From: Marcus Glocker
> >
> > On my G5 the maxds(4) control register read fails. I guess because
> > there is no such chip on the mainboard though the eeprom -p claims
> > there is one (o
On Thu, May 12, 2016 at 08:39:01PM +, Miod Vallat wrote:
> > > fcu(4) could benefit from a similar change, as there may be pwm fans
> > > there too. At least RackMac3,1 has two pwm fans according to the eeprom
> > > -p output.
> >
> > Hmm, looking at the fcu(4) code it already should support
> Date: Thu, 12 May 2016 22:31:37 +0200
> From: Marcus Glocker
>
> On my G5 the maxds(4) control register read fails. I guess because
> there is no such chip on the mainboard though the eeprom -p claims
> there is one (or it's broken).
>
> In case maxds(4) can't read the control register at att
> > fcu(4) could benefit from a similar change, as there may be pwm fans
> > there too. At least RackMac3,1 has two pwm fans according to the eeprom
> > -p output.
>
> Hmm, looking at the fcu(4) code it already should support pwm fans, no?
Doh! I was looking for `fan' in the sensors output and di
On my G5 the maxds(4) control register read fails. I guess because
there is no such chip on the mainboard though the eeprom -p claims
there is one (or it's broken).
In case maxds(4) can't read the control register at attach time
we should return (like lmtemp(4) does it) instead of continue to
set
On Tue, May 10, 2016 at 11:46:24PM +0200, Marcus Glocker wrote:
> I've recently noticed that two of five fans in my G5 don't spin up.
> That's because smu(4) currently just supports RPM fans.
> The attached diff adds initial support for PWM fans as well.
>
> sysctl before:
> # sysctl -a | grep fa
On Wed, May 11, 2016 at 07:53:56PM +, Miod Vallat wrote:
>
> > I've recently noticed that two of five fans in my G5 don't spin up.
> > That's because smu(4) currently just supports RPM fans.
> > The attached diff adds initial support for PWM fans as well.
>
> fcu(4) could benefit from a simi
install has a "safe mode" -S option, although it's not as entirely safe as one
might assume. It relies on rename() being an atomic operation, which is good.
However, rename doesn't guarantee that a file's *contents* are on disk. Thus,
there is a window between the rename and the eventual flushing o
Theo de Raadt wrote:
> > > > I think we should remove the check. It doesn't make sense, and it's
> > > > different
> > > > from other systems using kqueue. (I also had to work around it in
> > > > rebound,
> > > > where some code could be organized better if it weren't for the need to
> > > > ca
> > > I think we should remove the check. It doesn't make sense, and it's
> > > different
> > > from other systems using kqueue. (I also had to work around it in rebound,
> > > where some code could be organized better if it weren't for the need to
> > > call
> > > kevent before switching IDs.)
>
> > I think we should remove the check. It doesn't make sense, and it's
> > different
> > from other systems using kqueue. (I also had to work around it in rebound,
> > where some code could be organized better if it weren't for the need to call
> > kevent before switching IDs.)
>
> FreeBSD has p
On Thu, 12 May 2016 12:07:43 -0400, "Ted Unangst" wrote:
> I think we should remove the check. It doesn't make sense, and it's different
> from other systems using kqueue. (I also had to work around it in rebound,
> where some code could be organized better if it weren't for the need to call
> kev
There is a permission check for EVFILT_PROC that is not documented. Actually,
it directly contradicts the documentation, which says you can watch any
process you can see. The documented behavior makes sense, since I could also
just run ps in a tight loop and get the same info, only less efficiently
On Tue, 10 May 2016 16:42:25 +0200, Marc Espie wrote:
> Both bmake and gmake support a list of files in include/sinclude
> "systemV style".
>
> Adding this to our make would make us slightly more compatible.
>
> It also allows modern dependency patterns a la
>
> .sinclude ${SRC:R:=.d}
>
> Jus
That is among the reasons why ipmi is disabled.
And will remain disabled, until all the reasons are fixed.
> It looks like the Supermicro X9SCM BIOS lies about the presence of a BMC.
>
> This board does not have a BMC but OpenBSD 5.9 tries to attach it and fails
> with the following panic:
> ...
Quoth Okan Demirmen on Mon, Dec 14, 2015:
> On Mon 2015.12.14 at 20:06 +0100, Matej Nanut wrote:
> > Hello,
> >
> > will these patches eventually be commited to CVS?
> >
> > I really like this one.
>
> Hi - I haven't had spare cycles to look into this, nor the other recent
> patches yet, but the
It looks like the Supermicro X9SCM BIOS lies about the presence of a BMC.
This board does not have a BMC but OpenBSD 5.9 tries to attach it and fails
with the following panic:
...
acpibtn0 at acpi0: SLPB
acpibtn1 at acpi0: PWRB
panic: ipmi0: sendcmd fails
Starting stack trace...
panic() at panic+0
This survived a full bulk build.
Now I'm fishing for okays.
(and a seeing eye)
On Tue, May 10, 2016 at 04:42:25PM +0200, Marc Espie wrote:
> Both bmake and gmake support a list of files in include/sinclude
> "systemV style".
>
> Adding this to our make would make us slightly more compatible.
>
I have another VPN I need to setup, so it must be time for another
attempt at trying to get iked to work.
Has anyone already figured out a local hack to get iked to bind to
a particular address so the packets from sendto() come with the
correct source address on a multihomed system?
I've poked ar
Thank you!now that's a bug report..
On Thu, May 12, 2016 at 4:28 AM, Alexey Suslikov
wrote:
> On Wed, Apr 27, 2016 at 7:22 PM, Theo de Raadt
> wrote:
>>> On 27/04/16(Wed) 15:45, Alexey Suslikov wrote:
>>> > Theo de Raadt cvs.openbsd.org> writes:
>>> >
>>> > >
>>> > > Most of these bug rep
ok?
Index: ubsec.c
===
RCS file: /cvs/src/sys/dev/pci/ubsec.c,v
retrieving revision 1.161
diff -u -p -r1.161 ubsec.c
--- ubsec.c 10 Dec 2015 21:00:51 - 1.161
+++ ubsec.c 12 May 2016 10:54:57 -
@@ -1104,7 +1104,7 @
On Wed, Apr 27, 2016 at 7:22 PM, Theo de Raadt wrote:
>> On 27/04/16(Wed) 15:45, Alexey Suslikov wrote:
>> > Theo de Raadt cvs.openbsd.org> writes:
>> >
>> > >
>> > > Most of these bug reports completely stink.
>> > >
>> > > ALWAYS include *ALL* information in a report.
>> >
>> > In an idealistic
Hi Martijn,
Martijn van Duren wrote on Tue, May 10, 2016 at 10:34:54PM +0200:
> On 05/10/16 20:58, Ingo Schwarze wrote:
>> Martijn van Duren wrote on Tue, May 10, 2016 at 08:08:34PM +0200:
>>> On 05/10/16 19:29, Ingo Schwarze wrote:
Martijn van Duren wrote on Tue, May 10, 2016 at 02:43:54PM +
Despite being redundant, the LK_CANRECURSE flag isn't checked anywhere.
Ok?
natano
Index: sys/kern/kern_lock.c
===
RCS file: /cvs/src/sys/kern/kern_lock.c,v
retrieving revision 1.46
diff -u -p -r1.46 kern_lock.c
--- sys/kern/kern_l
25 matches
Mail list logo
