On Wed, Feb 19, 2020 at 07:23:13PM -0600, Scott Cheloha wrote:
> On Wed, Feb 19, 2020 at 05:26:40PM +0100, Otto Moerbeek wrote:
> > On Wed, Feb 19, 2020 at 05:10:11PM +0100, Otto Moerbeek wrote:
> >
> > > On Wed, Feb 19, 2020 at 10:02:10AM -0600, Scott Cheloha wrote:
> > >
> > > > On Wed, Feb 19
On Fri, Jan 10, 2020 at 06:54:26PM -0600, Scott Cheloha wrote:
> Ticks to milliseconds.
>
> ok?
Bump and rebase.
1/2 seconds, so, 500 milliseconds.
ok?
Index: dwiic.c
===
RCS file: /cvs/src/sys/dev/ic/dwiic.c,v
retrieving revision
On Fri, Jan 10, 2020 at 07:31:28PM -0600, Scott Cheloha wrote:
> Ticks to milliseconds.
>
> ok?
Bump.
1/4 seconds, so, 250 milliseconds.
Index: ic/i82365.c
===
RCS file: /cvs/src/sys/dev/ic/i82365.c,v
retrieving revision 1.37
diff
1/10 seconds, so, 100 milliseconds.
ok?
Index: ic/pgt.c
===
RCS file: /cvs/src/sys/dev/ic/pgt.c,v
retrieving revision 1.97
diff -u -p -r1.97 pgt.c
--- ic/pgt.c9 Jan 2020 14:35:19 - 1.97
+++ ic/pgt.c20 Feb 2020 01:29
On Wed, Feb 19, 2020 at 05:26:40PM +0100, Otto Moerbeek wrote:
> On Wed, Feb 19, 2020 at 05:10:11PM +0100, Otto Moerbeek wrote:
>
> > On Wed, Feb 19, 2020 at 10:02:10AM -0600, Scott Cheloha wrote:
> >
> > > On Wed, Feb 19, 2020 at 04:00:34PM +0100, Otto Moerbeek wrote:
> > > >
> > > > [...]
> >
On Tue, Feb 18, 2020 at 12:09:10PM +0100, Tobias Heider wrote:
> here is an update of the last diff rebased onto current with minor fixes.
> There
> were some problems when multiple transport and non-transport policies were
> configured, which should now be fixed.
> I also have a test case for the
On 19/02/20(Wed) 14:13, Vitaliy Makkoveev wrote:
> On Wed, Jan 17, 2018 at 11:40:24AM +0100, Martin Pieuchot wrote:
> > Hello Sebastien,
> >
> > On 17/01/18(Wed) 10:19, Sebastien Marie wrote:
> > > [...]
> > > kernel modification is desirable in some cases, at least for disabling
> > > ulpt(4) wh
On Wed, Feb 19, 2020 at 05:10:11PM +0100, Otto Moerbeek wrote:
> On Wed, Feb 19, 2020 at 10:02:10AM -0600, Scott Cheloha wrote:
>
> > On Wed, Feb 19, 2020 at 04:00:34PM +0100, Otto Moerbeek wrote:
> > >
> > > [...]
> > >
> > > FFS1, the default filesystem, uses 32-bit signed timestamps on disk.
On Wed, Feb 19, 2020 at 10:02:10AM -0600, Scott Cheloha wrote:
> On Wed, Feb 19, 2020 at 04:00:34PM +0100, Otto Moerbeek wrote:
> >
> > [...]
> >
> > FFS1, the default filesystem, uses 32-bit signed timestamps on disk.
> > That means that in 2038, there's going to be a problem, timestamps
> > wi
On Wed, Feb 19, 2020 at 10:02:10AM -0600, Scott Cheloha wrote:
> On Wed, Feb 19, 2020 at 04:00:34PM +0100, Otto Moerbeek wrote:
> >
> > [...]
> >
> > FFS1, the default filesystem, uses 32-bit signed timestamps on disk.
> > That means that in 2038, there's going to be a problem, timestamps
> > wi
On Wed, Feb 19, 2020 at 04:00:34PM +0100, Otto Moerbeek wrote:
>
> [...]
>
> FFS1, the default filesystem, uses 32-bit signed timestamps on disk.
> That means that in 2038, there's going to be a problem, timestamps
> will the be interperet as coming from the start of the 1900's.
>
> FFS2 does no
Hi,
booting from an ffs2 filesystem is a puzzle containing many pieces.
For amd64 and i386 mbr booting, the pieces below are needed.
Lifted from an old bitrig tree.
Note that this is *not* enough to get thing going since boot(8) and
its variants do not support ffs2 yet, but for this diff I'm on
Eventually, it will become necessary to add new properties to
struct filterops. One such property is whether the filter is safe to use
without the kernel lock.
The diff below replaces the f_isfd field with a generic flags field in
struct filterops, to allow adding new properties without cluttering
Hoi,
FFS1, the default filesystem, uses 32-bit signed timestamps on disk.
That means that in 2038, there's going to be a problem, timestamps
will the be interperet as coming from the start of the 1900's.
FFS2 does not have this limitation, but at the moment, we cannot boot
from it. I'm working on
On Wed, Jan 17, 2018 at 11:40:24AM +0100, Martin Pieuchot wrote:
> Hello Sebastien,
>
> On 17/01/18(Wed) 10:19, Sebastien Marie wrote:
> > [...]
> > kernel modification is desirable in some cases, at least for disabling
> > ulpt(4) when using cups with USB printer.
>
> Sorry to hijack your threa
On Wed, 19 Feb 2020 08:45:39 +0100 Claudio Jeker
wrote:
> On Tue, Feb 18, 2020 at 11:16:54PM +, Stuart Henderson wrote:
> > On 2020/02/18 13:40, Gerhard Roth wrote:
> > > > > Yes, I tried MBIM_CONTEXT_IPTYPE_IPV4ANDV6 myself first but to no
> > > > > avail. The switched to MBIM_CONTEXT_IPTY
16 matches
Mail list logo