On Fri, Aug 17, 2018 at 07:51:26PM -0500, Scott Cheloha wrote:
> On Fri, Aug 17, 2018 at 04:43:03PM -0500, Scott Cheloha wrote:
> > On Mon, Aug 13, 2018 at 07:20:38PM +0200, Theo Buehler wrote:
> > > On Mon, Aug 13, 2018 at 07:01:25PM +0200, Jeremie Courreges-Anglas wrote:
> > > > On Mon, Aug 13 20
On Fri, Aug 17, 2018 at 04:43:03PM -0500, Scott Cheloha wrote:
> On Mon, Aug 13, 2018 at 07:20:38PM +0200, Theo Buehler wrote:
> > On Mon, Aug 13, 2018 at 07:01:25PM +0200, Jeremie Courreges-Anglas wrote:
> > > On Mon, Aug 13 2018, Scott Cheloha wrote:
> > > > tb@ spotted this one.
> > > >
> > > >
On Mon, Aug 13, 2018 at 07:20:38PM +0200, Theo Buehler wrote:
> On Mon, Aug 13, 2018 at 07:01:25PM +0200, Jeremie Courreges-Anglas wrote:
> > On Mon, Aug 13 2018, Scott Cheloha wrote:
> > > tb@ spotted this one.
> > >
> > > If BIO_new fails we leak scon, so SSL_free it in that case.
> > >
> > > ok
Hi,
The current limit on 'tls ciphers' is 255 characters which prevents using
the cipher list as recommended by
https://mozilla.github.io/server-side-tls/ssl-config-generator/
for example (clocks in just shy of 300 characters).
tls ciphers
"ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256
Diff below reduces the number of arm64 CPUs we attach to the maximum
that we support. Without this diff a kernel running on hardware with
more than MAXCPUS CPUs will almost certainly crash.
To make this work, the code is changed to bump ncpus whenever we
attach a secondary CPU instead of bumping
Mark Kettenis wrote:
>Maybe you can add some printf's to figure out why the timeout is
>happening? Is it actually doing a delay? Is the delay too long? Or
>too short?
Yes, the delay is okay. The problem is that when "cold" is 1, the vblank
counter never changes during a call to drm_wait_one_vb
On Fri, 17 Aug 2018 10:20:09 -0500, Scott Cheloha wrote:
> I don't think we should encourage or even mention the possibility of the
> use of poll(2) to effect millisecond timeouts. Even if the standard library
> lacks such an interface.
>
> I'm pretty sure you can't use this hack portably, either
And I agree. The idiom remains possible, it just doesn't need to me
mentioned / encouraged.
Ingo Schwarze wrote:
> Hi Scott,
>
> Scott Cheloha wrote on Fri, Aug 17, 2018 at 10:20:09AM -0500:
>
> > I don't think we should encourage or even mention the possibility of the
> > use of poll(2) to ef
Hi Scott,
Scott Cheloha wrote on Fri, Aug 17, 2018 at 10:20:09AM -0500:
> I don't think we should encourage or even mention the possibility of the
> use of poll(2) to effect millisecond timeouts. Even if the standard
> library lacks such an interface.
>
> I'm pretty sure you can't use this hack
I don't think we should encourage or even mention the possibility of the
use of poll(2) to effect millisecond timeouts. Even if the standard library
lacks such an interface.
I'm pretty sure you can't use this hack portably, either.
But mostly I just think it's a misuse of the interface and poten
On 17/08/18 14:27, Mark Kettenis wrote:
>> Obviously I can't categorically state that QEMU's emulation is perfect,
>> but it can now reliably run all of Linux, MacOS, NetBSD and FreeBSD in
>> my local tests which makes me suspect that OpenBSD is trying to do
>> something different here.
>
> Runs
> On Aug 17, 2018, at 8:37 AM, Solene Rapenne wrote:
>
> The sad state is that less and less
> ports are running on them.
>
The last package count for 6.3 shows macppc had the most packages after amd64
and i386.
Can you share examples of ports you’re missing? I’d be interested to look at
> From: Mark Cave-Ayland
> Date: Fri, 17 Aug 2018 12:15:10 +0100
>
> Hi all,
>
> I was just wondering what is the current state of the openbsd/macppc
> port? As part of my recent work on qemu-system-ppc I now have a patch
> that can boot OpenBSD macppc under the New World (-M mac99,via=pmu)
> ma
Mark Cave-Ayland wrote:
> On 17/08/18 13:55, Solene Rapenne wrote:
>
> > I'm using the macppc port since 6.1 to -current and apart failing
> > harware I don't have any issue while playing Doom or rebuilind ports :)
>
> Hmmm. 6.1 is the latest version that I can boot to userspace, even if it
> fa
On Fri, Aug 17, 2018 at 8:48 AM, Mark Cave-Ayland
wrote:
> On 17/08/18 13:34, Jonathan Gray wrote:
>
>> On Fri, Aug 17, 2018 at 12:15:10PM +0100, Mark Cave-Ayland wrote:
>>> Hi all,
>>>
>>> I was just wondering what is the current state of the openbsd/macppc
>>> port? As part of my recent work on
On 17/08/18 13:55, Solene Rapenne wrote:
> I'm using the macppc port since 6.1 to -current and apart failing
> harware I don't have any issue while playing Doom or rebuilind ports :)
Hmmm. 6.1 is the latest version that I can boot to userspace, even if it
faults quickly after a few keypresses (QE
Mark Cave-Ayland wrote:
> On 17/08/18 13:37, Solene Rapenne wrote:
> > Mark Cave-Ayland wrote:
> >> Hi all,
> >>
> >> I was just wondering what is the current state of the openbsd/macppc
> >> port? As part of my recent work on qemu-system-ppc I now have a patch
> >> that can boot OpenBSD macppc u
On 17/08/18 13:37, Solene Rapenne wrote:
> Mark Cave-Ayland wrote:
>> Hi all,
>>
>> I was just wondering what is the current state of the openbsd/macppc
>> port? As part of my recent work on qemu-system-ppc I now have a patch
>> that can boot OpenBSD macppc under the New World (-M mac99,via=pmu)
>
On 17/08/18 13:34, Jonathan Gray wrote:
> On Fri, Aug 17, 2018 at 12:15:10PM +0100, Mark Cave-Ayland wrote:
>> Hi all,
>>
>> I was just wondering what is the current state of the openbsd/macppc
>> port? As part of my recent work on qemu-system-ppc I now have a patch
>> that can boot OpenBSD macppc
Mark Cave-Ayland wrote:
> Hi all,
>
> I was just wondering what is the current state of the openbsd/macppc
> port? As part of my recent work on qemu-system-ppc I now have a patch
> that can boot OpenBSD macppc under the New World (-M mac99,via=pmu)
> machine but I'm seeing quite a bit of instabil
On Fri, Aug 17, 2018 at 12:15:10PM +0100, Mark Cave-Ayland wrote:
> Hi all,
>
> I was just wondering what is the current state of the openbsd/macppc
> port? As part of my recent work on qemu-system-ppc I now have a patch
> that can boot OpenBSD macppc under the New World (-M mac99,via=pmu)
> machi
Hi all,
I was just wondering what is the current state of the openbsd/macppc
port? As part of my recent work on qemu-system-ppc I now have a patch
that can boot OpenBSD macppc under the New World (-M mac99,via=pmu)
machine but I'm seeing quite a bit of instability in OpenBSD compared to
all my oth
Sierra Wireless EM/MC7455
AT!USBCOMP=?
!USBCOMP:
AT!USBCOMP=,,
- configuration index to which the composition
applies, sould be 1
- 1:Generic, 2:USBIF-MBIM, 3:RNDIS
config type 2/3 should only be used for specific
SierraPIDs: 68B1, 9068
Sierra Wireless MC7304 ordinary firmware (no voice support):
SWI9X15C_05.05.67.00 r31378 CARMD-EV-FRMWR1 2016/03/11 14:58:53
0 - reserved NOT SUPPORTED
1 - DM AT SUPPORTED
2 - reserved
24 matches
Mail list logo
