On Tue, Jan 07, 2020 at 12:44:59PM +0100, Claudio Jeker wrote:
> On Tue, Jan 07, 2020 at 09:27:50AM +0100, Claudio Jeker wrote:
> > In -current I added support for the additional I2C busses on piixpm(4)
> > now I noticed that on my old AMD system the I2C bus seems to either
> > connect all those 4
rt_ifa_add() and rt_ifa_del() have a major confusion when it comes to
rtlabelid (as in labels on a route) vs rtableid (as in routing table id).
Because of this 'ifconfig rtlabel XYZ' fails to add route labels to
the routing table.
The following diff fixes this issue.
To test:
ifconfig tap1001
On Wed, 08 Jan 2020 14:29:11 +1100, Jonathan Gray wrote:
> The non-pro product supposedly is 126f:2262 going by
> https://bugzilla.kernel.org/attachment.cgi?id=280237=diff
OK millert@
- todd
On Tue, Jan 07, 2020 at 08:12:05PM -0700, Todd C. Miller wrote:
> The Adata XPG SX8200 and SX8200 Pro are different products so I
> think the "Pro" should be present in the description.
>
> - todd
>
>
The non-pro product supposedly is 126f:2262 going by
The Adata XPG SX8200 and SX8200 Pro are different products so I
think the "Pro" should be present in the description.
- todd
On Tue, Jan 07, 2020 at 06:42:08PM +0100, Dariusz Sendkowski wrote:
> Hi,
>
> I've bought a new SSD drive by ADATA recently and its vendor and product
> IDs are missing in pcidevs. Here is a patch to add it to the pcidevs.
>
> Vendor and product info is taken from:
>
On Mon, Dec 30, 2019 at 11:57:39PM +0100, Klemens Nanni wrote:
> No functional change, just a tiny hoisting in the parser I'd like to
> better reflect the order in which we parse the tokens.
>
> If the given domain was already specified, don't bother allocating and
> initializing it.
>
> Drop
On Sun, Dec 29, 2019 at 11:33:06PM +0100, Klemens Nanni wrote:
> OBP defaults to booting from disk and network in that order.
> With multiple disks attached, only the first disk is tried.
>
> OBP mostly if not always also defaults to automatic boot, meaning
> domains start trying boot devices
On Mon, Dec 30, 2019 at 12:51:13AM +0100, Klemens Nanni wrote:
> Those are briefly mentioned for the specific softraid case in
> boot_sparc64(8) but I want better offline documentation.
Especially since this is how one can configure their boot devices with
`variable' in ldom.conf(5).
>
Hi,
been there unused since import, and counting accepts+rejects has been enough,
so here's a diff for cleaning it away.
-Artturi
diff --git a/usr.sbin/rdate/ntp.c b/usr.sbin/rdate/ntp.c
index d48b6cae19e..92cb4c70fcb 100644
--- a/usr.sbin/rdate/ntp.c
+++ b/usr.sbin/rdate/ntp.c
@@ -177,7
On Tue, Jan 07, 2020 at 07:48:54PM +0100, Tobias Heider wrote:
> the attached diff unifies the boilerplate code for some of the ikev2_add_*
> functions that append NOTIFY payloads to a message and removes unneeded
> arguments. There should be no functional changes, just a little less
> duplicate
Hi,
the attached diff unifies the boilerplate code for some of the ikev2_add_*
functions that append NOTIFY payloads to a message and removes unneeded
arguments. There should be no functional changes, just a little less
duplicate code.
ok?
diff --git a/sbin/iked/ikev2.c b/sbin/iked/ikev2.c
On Tue, Jan 07 2020, Klemens Nanni wrote:
> On Tue, Jan 07, 2020 at 06:47:16PM +0100, Jeremie Courreges-Anglas wrote:
>> Bah, I think I understand why this was chosen. bash functions declared
>> with "function name" or "function name()" aren't special. Probably we
>> should do the same.
...
On Tue, Jan 07, 2020 at 06:47:16PM +0100, Jeremie Courreges-Anglas wrote:
> Bah, I think I understand why this was chosen. bash functions declared
> with "function name" or "function name()" aren't special. Probably we
> should do the same. I'm postponing this for now, thanks for the
> feedback
On Sat, Dec 28 2019, Klemens Nanni wrote:
> On Sat, Dec 28, 2019 at 04:07:02PM +0100, Mark Kettenis wrote:
>> Are there other ksh implementations that have this "feature"?
> MirBSD's ksh allows all three forms but treats `function name()' like
> `name()', that is $0 stays the same and will not be
Hi,
I've bought a new SSD drive by ADATA recently and its vendor and product
IDs are missing in pcidevs. Here is a patch to add it to the pcidevs.
Vendor and product info is taken from:
https://devicehunt.com/view/type/pci/vendor/1CC1/device/8201
Index: pcidevs
On Tue, Jan 07, 2020 at 03:32:02PM +0100, Alexander Bluhm wrote:
> Hi,
>
> When the netcat server should check the certificate hash of the
> client, it always succeeds. So nc -c -H -l is always successful,
> no matter what certificate the client provides.
>
> The bug is that the TLS context of
On Sat, Dec 21, 2019 at 11:29:20PM +, Alexander Nasonov wrote:
> Ingo Schwarze wrote:
> > Looking at our code in lib/libc/stdlib/drand48.c, i conclude that
> > drand48(3) does return 0.0 with a probability of 2^-48.
>
> I looked at the code too and I have some comments.
>
> > More generally,
On Tue, Jan 07, 2020 at 09:50:46AM -0500, David Riley wrote:
> Hm, I also have a T5240 with a generous allotment of RAM that I could try. I
> don’t recall the firmware version, but I’ve been meaning to put OpenBSD on it
> for a while (I don’t spin it up much because it’s a noisy power hog that I
On Jan 7, 2020, at 04:12, Klemens Nanni wrote:
>
> On Mon, Jan 06, 2020 at 10:19:41PM -0800, Mike Larkin wrote:
>> Do you still need testing here? I could reinstall my t5240 if nobody has
>> tested yet...
> Thanks, but Mark already confirmed that T5120 machines do select new
> configurations
Hi,
When the netcat server should check the certificate hash of the
client, it always succeeds. So nc -c -H -l is always successful,
no matter what certificate the client provides.
The bug is that the TLS context of the listen socket is used instead
of the accepted connection.
Also I would
Current and patched current dmesg diff below and both dmesgs attached.
real mem = 4009230336 (3823MB)
-avail mem = 3875258368 (3695MB)
+avail mem = 3875254272 (3695MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
@@ -108,20 +108,9 @@
spdmem0 at iic0 addr 0x50: 2GB DDR3
> Date: Mon, 6 Jan 2020 17:21:01 -0600
> From: Scott Cheloha
>
> Sorry for the delay. I needed to think on this.
>
> On Fri, Jan 03, 2020 at 11:15:20AM +0100, Martin Pieuchot wrote:
> > On 02/01/20(Thu) 14:29, Scott Cheloha wrote:
> > > > On Jan 2, 2020, at 9:02 AM, Martin Pieuchot wrote:
> >
On Tue, Jan 07, 2020 at 09:27:50AM +0100, Claudio Jeker wrote:
> In -current I added support for the additional I2C busses on piixpm(4)
> now I noticed that on my old AMD system the I2C bus seems to either
> connect all those 4 busses together (or there is a bug in the driver).
Looks like this is
On 06/01/20(Mon) 17:21, Scott Cheloha wrote:
> [...]
> But the risk is there. So I don't want to change the rounding yet.
Which risk? You still haven't explain. Diff is below, where is the
risk?
> So I don't want to change the rounding yet.
That we understood :o)
On Mon, Jan 06, 2020 at 10:19:41PM -0800, Mike Larkin wrote:
> Do you still need testing here? I could reinstall my t5240 if nobody has
> tested yet...
Thanks, but Mark already confirmed that T5120 machines do select new
configurations automatically.
If you're still in for testing, I'd like to
In -current I added support for the additional I2C busses on piixpm(4)
now I noticed that on my old AMD system the I2C bus seems to either connect all
those 4 busses together (or there is a bug in the driver).
I would like to know if people with ATI SBx00 SMBus chips see the same
effect as I do.
> Convert ticks to milliseconds.
>
> The 33 milliseconds in the timeout_add_msec(9) call will be truncated
> to 3 ticks, but that was already the case with the current (hz / 30)
> code so this is no worse.
[...]
> /* allow 1/30 second for heads to settle */
> -
28 matches
Mail list logo
