at are being hidden by the
/usr partition (or any of your other partitions). Check there's nothing
`under' your mounts.
Jamie's comment about the reserved margin is also correct, but it doesn't
account for 2GB.
Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubs
k will not
be freed until everything has closed the file. Check out the rotatelogs(8)
man page that comes with Apache for information about how to properly
rotate its logs.
Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
away the modified version). Commit if it
works, and I'll look properly tomorrow. Sorry for the breakage.
Ian
Index: tcp_usrreq.c
===
RCS file: /dump/FreeBSD-CVS/src/sys/netinet/tcp_usrreq.c,v
retrieving revision 1.83
diff
In message <[EMAIL PROTECTED]>, Ian Dowse writes
:
>IP, but we were throwing away the modified version). Commit if it
>works, and I'll look properly tomorrow. Sorry for the breakage.
With the one compile error fixed, this seemed to make `telnet 0.0.0.0'
work again, so I wen
rsion expected? If so, something like the
patch above should ensure that the second vput() does not call
VOP_INACTIVE() again.
Ian
>(kgdb) where
>#0 doadump () at ../../../kern/kern_shutdown.c:223
>#1 0xc0236e8a in boot (howto=260) at ../../../kern/kern_shutdown.c:355
>#2 0xc0
tomic.h will
include opt_cpu.h. The other options referenced in atomic.h are all
in opt_global.h, so CPU_DISABLE_CMPXCHG needs to go there too (note
that the instruction is called cmpxchg, not cmpxfhg BTW).
Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current&qu
he problem?
Ian
Index: isa_pci.c
===
RCS file: /dump/FreeBSD-CVS/src/sys/dev/pci/isa_pci.c,v
retrieving revision 1.6
diff -u -r1.6 isa_pci.c
--- isa_pci.c 21 Dec 2001 01:28:46 - 1.6
+++ isa_pci.c 29 Oct 2002 01:01:33 -
In message <[EMAIL PROTECTED]>, Nate Lawson wri
tes:
>I looked at the change and it seems good. Can someone more familiar with
>the USB system verify this?
Done - I have a C-1 here, so I was able to test it - obviously I haven't
accessed the camera from -current in a while!
Ia
at" -gt 0 ]; then
killall -HUP moused
fi
done
to send a SIGHUP to moused after a resume, which seems to be necessary
on my Vaio C1.
Ian
Index: acpi.c
===
RCS file: /dump/FreeBSD-CVS/s
#for some laptops
>options PSM_RESETAFTERSUSPEND #reset the device at the resume event
>
>will resolve your problem without the patch.
Cool, thanks. I didn't know those options existed - I'll try them
out next time I reboot.
Ian
To Unsubscribe: send
somewhere?
Cheers,
Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
eir destruction, but I
haven't found the time to look into that yet.
Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
In message <[EMAIL PROTECTED]>, Bruce Evans writes:
>On Wed, 27 Nov 2002, Ian Dowse wrote:
>> I think moving the line
>>
>> tsleep(sc, PRIBIO, "mdwait", 0);
>>
>> to just after the following `if' statement may do the trick. If the
>
've tested the fix, and I'm just waiting for re@ approval to commit
it.
Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
In message <[EMAIL PROTECTED]>, Michal
Mertl writes:
>Subject says it all.
Fixed in md.c revision 1.74 - this was discussed here a few days
ago, but I was just waiting for approval to commit the fix.
Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-c
tting devices ..
done
ata1: resetting devices ..
done
panic: ata_dmasetup: transfer active on this device!
Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
he disabled kernel I/O slowdown, but from
userland. It seems to help quite a lot in leaving some disk bandwidth
for other processes. Waiting a while before starting the fsck seems
like a good idea anyway though. Patch below (I think I posted an
earlier version of this before).
mouse.
I'll see if I can find my notes on it, or reproduce it.
Maybe that will help someone smarter than me figure it out, if not
sorry for the "me too".
Ian
On Wed, Apr 03, 2002 at 12:55:54PM +0200, Nick Hibma wrote:
>
> This looks like an electrical problem. What happens
that
could just be my imagination).
Ian
On Wed, Apr 03, 2002 at 01:02:54PM -0500, Scott Christopher Dodson wrote:
>
> If it helps any, the optical logitech wheel mouse I have works without a
> hitch. I've got mind connected via USB, but have you tried using the
> USB/PS2 adapter a
would explain a problem I saw recently on a netbooted box
where kldload only worked with full module paths. Could `rootvnode'
be checked for NULL instead?
Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
this
>fu
>nction)
It's genuine breakage, caused by me, and fixed a few days ago. Try
updating again I guess. Sorry...
Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
In message <[EMAIL PROTECTED]>, Ian writes:
>Actually, I now think a more-correct fix would be to have no if statement at
>all, and just always recalculate the field widths after calling the routine
>to re-get the stats.
Yes, I agree. Committed, thanks!
Ian
To Unsubscribe: send
ults instead of
the potentially stale list from getmntinfo(..., MNT_NOWAIT).
Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
The logic for testing UMA_ZFLAG_INTERNAL in zone_dtor() is reversed.
I was able to reliably reproduce crashes with:
mdconfig -a -t malloc -s 10m
mdconfig -d -u 0
mdconfig -a -t malloc -s 10m
mdconfig -d -u 0
Ian
Index: uma_core.c
point of all this
is that we support drm2 on some platforms, but not x86 anymore. So to
me that implies not building the modules by default on x86.
-- Ian
> ---
> Sent using a tiny phone keyboard.
> Apologies for any typos and autocorrect.
> Also, this old phone only supports top
in /usr/obj/usr/src/amd64.amd64/sys/BRANE
*** Error code 1
Stop.
make[1]: stopped in /usr/src
*** Error code 1
Stop.
make: stopped in /usr/src
--
Ian Freislich
--
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/l
I moved the #ifdef down one line and its compiling.
Ian
--
Ian Freislich
On 08/29/2018 07:40 PM, John Baldwin wrote:
> On 8/29/18 4:20 PM, Ian FREISLICH wrote:
>> Hi
>>
>> I see the definition of interrupt_sorted is #ifdefed out by #ifdef SMP
>> at line 84.
s that locked process is in "[ttydcd]" state. ^C kills
> locked
> process.
>
> What do I have misconfigured?
>
Change the std.115200 to 3wire.115200 so that it ignores modem-control
signals.
-- Ian
___
freebsd-current@fr
ld I build?
>
> Eric
Do "make kernel-toolchains" to build all the tools needed to build all
universe kernels.
You can also add "MAKE_LINT_KERNELS=1" to build just the lint kernels
for all arches, but be aware that mips has no lint kernels.
-- Ian
f that will do better
> thanks,
> toomas
>
I don't think that will be an option. If it hasn't gotten to the point
of saying how much BIOS available memory there is, it's only halfway
through loader main() and has hung before getting to interact().
In fact, if that line ha
lready attached
>
> I haven't fiddled with identify() yet, will look at that tonight.
>
If this is just another "bus" an ig4 instance can attach to, I'd think
the recipe would be to add another DRIVER_MODULE() to ig4_iic.c naming
ig4_lpss as the parent. Then add a n
k" line 92:
> warning: using previous script for "_testsFILESINS_cleanup.ksh"
> defined here
>
>
> Is this something easily fixable? I'm unclear what is throwing a
> warning here?
>
> sean
>
Looks like some makefile has cleanup.ksh listed twi
_vte.o] Error code 1
> >
> > ...
> >
> > -- snip
> >
> > Is this known - did i miss something ?
> > Howto fix ?
> Does your "MODULAR" config file include "device miibus"?
>
It is possible to build miibus as
on between iicbus and the controller lives right alongside
the DRIVER_MODULE() statement that establishes the connection between
the controller and the bus it sits on. See, for example:
sys/dev/glxiic/glxiic.c
sys/dev/iicbus/iicoc.c
-- Ian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
ailed with error 2; retrying fpr
> 3 seconds
> Mounting from ufs:/dev/gpt/extroot failed with error 2; retrying fpr
> 2 seconds
> Mounting from ufs:/dev/gpt/extroot failed with error 2; retrying fpr
> 1 seconds
> ...
>
> I can provide a 'dmesg' output
o you can safely remove it from
your config.
Author: avos
Date: Fri Jan 25 13:48:40 2019
New Revision: 343427
URL: https://svnweb.freebsd.org/changeset/base/343427
Log:
Garbage collect AH_SUPPORT_AR5416 config option.
It does nothing since r318857.
-- Ian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
s dependency, and is there an UPDATING entry
> for this change?
>
> Thanks!
> -Enji
>
My question would be: why? If some drivers have a new dependency on
iflib, why isn't that expressed in sys/conf/files and handled
automatically?
-- Ian
__
On Fri, 2019-02-15 at 12:32 -0700, Warner Losh wrote:
> On Fri, Feb 15, 2019 at 12:17 PM Ian Lepore wrote:
>
> > On Fri, 2019-02-15 at 10:53 -0800, Enji Cooper wrote:
> > > > [...]
> > >
> > > HO Eric!
> > >
> > > iflib was a recen
the default driver on the major Linux distributions.
> > . . .
> >
> >
> >
> > but it seems to not have a 13-current entry. It does have
> > a 12.0-RELEASE entry.
> >
>
> Thanks. Kinda odd that freebsd-current doesn't have a manual
> page
> You do realize some of the emails are from frustrated users
> who are trying to make FreeBSD (see for example libm).
>
And do you realize that you've trimmed away all the context so that now
it looks like Warner was talking to you, when in fact he was replying
everything 32-bit under the bus and declare
freebsd to be a 64-bit-only OS. Netflix wins; those of us building
smaller embedded products will eventually be forced to move to linux.
-- Ian
___
freebsd-current@freebsd.org mailing list
https://lists.f
Thanks in advance!
>
>
I think 'devctl rescan' will do that, 'man devctl' for details.
-- Ian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
sense that the "garbage" might be
different between a firstboot after power-on and a reboot.
So all in all, it wouldn't hurt to update both gptzfsboot and loader
(gpart bootcode -b and -p) to see if there's a fix lurking in my zfs
probe changes.
-- Ian
___
On Mon, 2019-04-29 at 10:33 -0400, Thomas Laus wrote:
> > On 2019-04-28 22:27, Ian Lepore wrote:
> > >
> > > If you're using gptzfsboot, I guess you're using zfs? I just
> > > fixed a
> > > problem with probing disks for zfs volumes a few days
gptzfsboot and
> > pmbr in the drive boot record. I did not try booting an older
> > kernel
> > using the new gptzfsboot. I was concerned about the lack of ssh
> > login
> > when the computers lost their console, so I just rolled back my
> > system
> > to th
nice if "currdev syntax" worked too, so you could just
enter disk3p4 or similar. I may look into adding that to the code.
-- Ian
> > GPT does not have the concept of active partition.
>
> It has "bootme" / "bootonce" attributes. And [
> net.inet.ip.portrange.randomized: 1
> net.inet.ip.random_id_total: 0
> net.inet.ip.random_id_collisions: 0
> net.inet.ip.random_id_period: 0
> net.inet.ip.random_id: 0
> net.key.int_random: 60
> debug.fail_point.status_fill_kinfo_vnode__random_path: off
> debug.fail_point.fill_kinfo_vnode__random_path: off
>
bsd 13 and
that you plan on updating to freebsd 13 or later?"
Many of the systems that contained these old devices don't have enough
ram to run a modern version of freebsd. If you can't update the system
to 13, you don't need ongoing ed(4) support. And make no mistake,
ongoing support IS the issue -- it costs manpower we don't have much of
to maintain old device drivers.
-- Ian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
-ng and ptxdist from Pengutronix).
>
> Is there anything comparable to
> https://releng.netbsd.org/cgi-bin/builds.cgi , but for FreeBSD?
>
> If I see 0 passed, 67 failed for NetBSD-HEAD, I figure I should wait
> for a better time. But what about FreeBSD?
>
> Tom
A co
t have a really detailed answer because I've
never enabled the option. I've always perceived it as being something
most people don't need. WITHOUT_CLANG_EXTRAS may cut some time from
your build, but it probably won't cut it in half or anything.
-- Ian
e what
> triggered the issue, but I suspect it has to deal with an external
> [toolchain] change.
> Cheers!
> -Enji
r347992 seems like a good candidate.
-- Ian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/li
,install)
===> lib/libc (obj,all,install)
===> lib/libgcc_eh (obj,all,install)
===> lib/csu/amd64 (all)
===> lib/csu/amd64 (install)
===> lib/libgcc_s (obj,all,install)
===> lib/libcxxrt (obj,all,install)
I've seen some bad things happen in the past when parallel jobs try to
build in the same directory.
-- Ian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
; power in a hot office.
> Commit bits used to be suspended for un-buildable code. I'll boot
> stable.
Since you seem to be so focused on mean-spirited criticism of others,
I'm sure you'll understand when I ask...
Have you *seriosly* been using and building freebsd this long and you
don't know that an opt_*.h file is generated as part of the build and
exists only in the object directory, so that searching for it under
/usr/src or /usr/include would be... let's see, how did you put it?...
Oh yeah: A double waste of CPU & human time.
-- Ian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
ve been using make buildworld without -j n in the past on
> > that machine, the
> > problem seems to be introduced recently. Any idea what is the cause
> > of
> > the problem?
> >
> > Best regards
> > Michael
> > >
> >
> >
On Tue, 2019-06-18 at 07:01 -0700, Enji Cooper wrote:
> > On Jun 18, 2019, at 06:59, Enji Cooper
> > wrote:
> >
> >
> > > On Jun 18, 2019, at 06:53, Ian Lepore wrote:
> >
> > ...
> >
> > > Last Saturday, Bryan (cc'd) made a
it continued to be an
> > issue
>
> Even -j1 should avoid it. For some reason I am only seeing it without
> any -j flag at all.
>
> I should have a fix in soon.
>
There's a subtle difference between -j1 and no -j at all, having to d
On Wed, 2019-06-19 at 09:30 -0700, Rodney W. Grimes wrote:
> > In message <
> > fffbe5d47e3515c960429ab416bf2ba234f9671d.ca...@freebsd.org>
> > , Ian Le
> > pore writes:
> > > On Tue, 2019-06-18 at 07:01 -0700, Enji Cooper wrote:
> >
lave devices are both i2c and smbus
compatible, and the smbus slave timeout is 35ms, so that wouldn't be a
bad default value.
I don't think ignoring the error and forging ahead is a good idea. It
should return an error, and perhaps it should use the bitbang bus-
recovery seque
elay may make even more sense, since
DELAY() is generally just polling a clock register).
Hmm, actually, it looks like iicbb hardcodes the bus frequency delay as
10us and delays after every toggle, so I guess it's really running the
bus at 50khz.
-- Ian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
like the enumeration of busses and devices has changed.
> > > grepping for uhub and usbus of the working and broken dmesg.boot
> > > gives
> > >
> >
> > Are you able to bisect the commit introducing the bad behaviour?
> >
>
> I'll give it a shot.
g some AI algorithm. The
> first
> part is probably written by hand, and other one is generated. I just
> wondering what's the point of this.
>
> For everyone else, message looking much like this was sent to llvm-
> dev@
> mail list too.
>
>
Everything posted
x27;t that /tmp is tmpfs, the problem is that it's being
mounted by /etc/rc.d/tmp as a 20MB filesystem because tmpsize="20m" is
the default. You could set tmpsize to some bigger value in rc.conf, or
you can add an explicit mount for /tmp in fstab so that you get the
fu
ave to follow the rules (from style(9))...
If either or is needed, include it
before other include files. ( includes ;
do not include both.)
Typically, if you're including anything from sys/ you'll need
sys/types.h first.
-- Ian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
bably won't
use it. But if you are using it, and you want to truly kill the dog,
you would just do "watchdog -t 0" after "service watchdogd stop". If
you really felt the need to cover that with a single service command,
then how about using "service watchdogd cancel&quo
HOLE
> > return the file's size as the offset.
> >
> > What do others think? rick
> > ps: The man page should be updated, whatever is done w.r.t. this.
> >
>
> I also vote for option 2
>
If SEEK_DATA and SEEK_HOLE don&#
On Sun, 2019-08-11 at 09:12 -0600, Alan Somers wrote:
> On Sun, Aug 11, 2019 at 8:57 AM Ian Lepore wrote:
> >
> > On Sun, 2019-08-11 at 09:04 +0200, Gary Jennejohn wrote:
> > > On Sun, 11 Aug 2019 02:03:10 +
> > > Rick Macklem wrote:
> > >
> >
en I'm on my
amd64 machine building from /my/sources/rpi using TARGET_ARCH=armv6
it's going to find /usr/local/sys/modules/drm-current-kmod and try to
crossbuild it for armv6?
How about when I'm doing a build of 11-stable for testing, but what's
in my /usr/loc
On Wed, 2019-08-14 at 09:08 -0700, John Baldwin wrote:
> On 8/13/19 3:17 PM, Ian Lepore wrote:
> > On Tue, 2019-08-13 at 14:58 -0700, John Baldwin wrote:
> > > For developers this means even if you are doing testing on a box
> > > that doesn't use DRM, you can in
On Wed, 2019-08-14 at 19:55 +0200, Niclas Zeising wrote:
> On 2019-08-14 19:23, Emmanuel Vadot wrote:
> > On Wed, 14 Aug 2019 10:13:48 -0700
> > John Baldwin wrote:
> >
> > > On 8/14/19 9:22 AM, Ian Lepore wrote:
> > > > This all sounds vaguely wrong,
7;t think it's as easy to compare the buildhost
running version with the version of source being built, unless the
build is started from the top level so that Makefile.inc1 sets the
variables.
-- Ian
___
freebsd-current@freebsd.org mailing list
https
On Wed, 2019-08-14 at 13:59 -0600, Warner Losh wrote:
> On Wed, Aug 14, 2019 at 1:56 PM Ian Lepore wrote:
>
> > On Wed, 2019-08-14 at 12:00 -0700, John Baldwin wrote:
> > > On 8/14/19 11:06 AM, Kyle Evans wrote:
> > > > LOCAL_MODULES="" does seem lik
files are fine and it really is a uid
problem. But a "pkg check -s -a" as suggested in the PR couldn't hurt.
:)
-- Ian
> On Wed, Aug 28, 2019 at 5:20 PM Gary Palmer
> wrote:
> >
> > On Wed, Aug 28, 2019 at 05:09:35PM -0400, Ryan Stone wrote:
> > >
ables are
expanded. In particular, the loop variable for a .for is expanded on
each loop iteration, but doesn't yet exist during parsing. I suspect
that the .if is evaluated earlier, during parsing. For example, this
makefile:
all:
.for x in a "" b
.if empty(x)
@echo empty
.endif
@echo ${x}
.endfor
@echo done
gives this output:
revolution > make -f /tmp/Makefile
empty
a
empty
empty
b
done
The way I interpret that is that empty(x) is true during parsing, so
the for loop is generated to contain "@echo empty" and "@echo ${x}",
then the for loop actually runs and prints both "empty" and the value
of ${x} on each iteration.
-- Ian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
.
# This should not be necessary on most systems, but may improve
# performance on heavily-loaded servers experiencing enough
# memory pressure to cause ntpd to be paged out.
# rlimit memlock stacksize
Then we would need to come up with reasonable values for .
-- Ian
___
w only syslogd has oomprotect set to YES by default. Maybe
that's a good choice -- once we start declaring one daemon to be more
important than others, you'll discover there's a whole back lot full of
bikesheds that need painting.
So maybe we should just document ntpd_oomprotect=YES i
On Mon, 2019-09-09 at 21:44 +0300, Konstantin Belousov wrote:
> On Mon, Sep 09, 2019 at 12:13:24PM -0600, Ian Lepore wrote:
> > On Mon, 2019-09-09 at 09:30 -0700, Rodney W. Grimes wrote:
> > > > On Sat, 2019-09-07 at 09:28 -0700, Cy Schubert wrote:
> > > >
ation than the average user, and would use the rlimit command
in ntp.conf.
-- Ian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
was -- I just assumed the build machinery created it because
I had accidentally done a make in a wrong directory once.
So what are those directories about? I'm not used to seeing mystery
directories appear inside a source tree.
-- Ian
___
freebsd-
On Tue, 2019-09-10 at 21:41 +0200, Dimitry Andric wrote:
> On 10 Sep 2019, at 20:14, Ian Lepore wrote:
> >
> > On Tue, 2019-09-10 at 11:01 -0600, Warner Losh wrote:
> > > However, please do *NOT* remove the sys/*/compile directories.
> > >
> > > Warn
_spin'
> spinlock_enter();
>\
> ^
> . . .
>
> (spinlock_enter was not the only example.)
>
>
My bad, I forgot to include when I switched the code to
spinlocks. Should be fixed by r352333.
-- Ian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
ole lotta stuff happens between ntpd and syscons (the
thing that configures blanktime). Try setting rc_debug=YES in rc.conf,
that should write more info to syslog about what's happening between
ntpd and the lockup point.
-- Ian
___
freebsd-current
lists.freebsd.org/pipermail/freebsd-arm/2015-March/010649.html
There have also been some bug reports as recently as 2017 indicating
that people are still doing this on small armv7 systems.
-- Ian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
n the reverse order?
The current gpio(4) documentation really only covers gpiobus(4) and a
mentions a few of its older children and how to configure them via
hints. We need manpages for some of the newer drivers, and we
especially need a manpage that documents sys/gpio.h (which is used both
from us
xamining every existing driver and
probably changing many of them. I'm not afraid of this aspect of any
change we decide on... it's about 30 drivers, all of which will need
minor changes.
-- Ian
___
freebsd-current@freebsd.org mailing lis
to be done on
a different thread to avoid [recursion|deadlock|whatever]."
So I'd say the first thing to do is be sure that the best solution
isn't just to pthread_create() as needed. If it turns out the cost of
pthread_create() is like 1-2% of the t
n update -r "{date}"
The curly braces indicate you're specifying a date, which can be in a
large variety of typical formats, details here:
http://svnbook.red-bean.com/en/1.7/svn.tour.revs.specifiers.html
Curly braces are significant in some shells, so the quotes may be
required.
--
nted for when
setting the frequency of the eventtimer.
Hmm, it should affect the timecounter too, in which case you'd see
time-of-day advancing 16x too fast. If ntpd is running it would need to
step the clock pretty frequently, which would show up in syslog.
I don't have hardware to
cp'.
>
Just to be clear, all the problems in the original mail, including
failure to detect COMPILER_TYPE automatically and building the wrong
type of binaries, were fallout from the original problem of not setting
MAKEOBJDIRPREFIX correctly. It turns out if you use the build system
co
e interrupt
> device_attach: ata0 attach returned 6
>
>
> It works fine with r271697 kernel (latest I have booting). I haven't
> yet tried bisecting.
>
> Hardware is a PowerMac G5 (last generation).
>
> - Justin
Ooops, I think a pa
On Fri, 2014-09-26 at 07:40 -0700, Justin Hibbits wrote:
> That fixed it, thanks!
>
> -Justin
Fix committed as r272181, sorry for the glitch.
-- Ian
> On Sep 26, 2014 6:59 AM, "Ian Lepore" wrote:
>
> > On Thu, 2014-09-25 at 20:40 -0700, Justin Hibbits wr
t was mentioned in another reply, but maybe overlooked... the contents
of /etc/make.conf and /etc/src.conf must be identical between the
systems where you do buildworld and installworld. For example, if you
buildworld using WITHOUT_CTF and installworld without using that same
setting, it will tr
ency as close as possible to the
> FreeBSD standard build environment, instead of botching post-installworld...
>
> Thanks,
>
> -Harry
>
>
>
It appears that while bsd.ports.mk has lost the ability to use the
version of the running system (sysctl kern.osreldate), it still has the
logic to just use OSVERSION if it's already set on the make command line
or in the environment. Can you leverage that to regain the behavior
you're used to?
-- Ian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
On Tue, 2014-10-14 at 18:09 +0200, Harald Schmalzbauer wrote:
> Bezüglich Ian Lepore's Nachricht vom 14.10.2014 17:37 (localtime):
> ...
> > It appears that while bsd.ports.mk has lost the ability to use the
> > version of the running system (sysctl kern.osreldate), it sti
ther
than in src.conf. I know the manpage says you can put them in src.conf,
but I wonder if we've broken that and you're the first person to try
since then.
On an 8.4 i386 system I can get a failure (not exactly the same as the
one you hit) trying to cross-build for amd64 if I put th
gt; Stop in /usr/src.
> huff@>> make TARGET=amd64 TARGET_ARCH=amd64 installkernel
> ERROR: Please set DESTDIR!
> *** Error code 1
>
It appears you almost had it right at this point, but overlooked this
error which is also the instructions of how to fix this error. Note
that th
mes:/sbin:/bin:/usr/sbin:/usr/bin
Do a "make kernel-toolchain" which will build a new ctfconvert and put
it in the right place within /usr/obj to be used during buildkernel.
-- Ian
___
freebsd-current@freebsd.org mailing list
http://list
gt; wrote:
> > > > On Tue, 28 Oct 2014 17:01:39 -0600
> > > > Ian Lepore wrote:
> > > >
> > > >> On Tue, 2014-10-28 at 23:50 +0100, Gyrd Thane Lange wrote:
> > > >> > PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/
On Wed, 2014-10-29 at 21:24 +0100, Gyrd Thane Lange wrote:
> On Wed, 29 Oct 2014 08:42:22 -0600
> Ian Lepore wrote:
>
> > On Wed, 2014-10-29 at 14:38 +0100, Gyrd Thane Lange wrote:
> > > On Wed, 29 Oct 2014 01:24:32 +0100
> > > Gyrd Thane Lange wrote:
> >
ch() about a year ago, which in most cases
> provides enough entropy to unblock /dev/random before we even run
> init(8).
>
> DES
And I vaguely remember being promised that things like that would NEVER
happen, even on systems with little or no entropy available during early
startup (which
On Sat, 2014-11-01 at 15:59 +0100, Dag-Erling Smørgrav wrote:
> Ian Lepore writes:
> > Dag-Erling Smørgrav writes:
> > > That means we're not getting enough entropy during early boot, or
> > > we're underestimating the amount of entropy we're gett
201 - 300 of 866 matches
Mail list logo
