t
>couldn't say it
>for sure. I'd do it dif=ferently: check if the value being written is
>the same that was read,
>=and skip the write in this case.
>Let me see, maybe I'll make a dif=ferent patch.
Hmm, the problem is we need to be able to
On Monday 06 April 2009 1:07:38 pm Ivan Voras wrote:
> 2009/4/6 John Baldwin :
> > On Sunday 05 April 2009 12:23:39 pm Sergey Babkin wrote:
>
> > Hmm, the problem is we need to be able to write to BARs to size them. Any
OS
> > needs to be able to do this to know what a
On Monday 06 April 2009 11:12:33 pm Sergey Babkin wrote:
> John Baldwin wrote:
> >
> > On Monday 06 April 2009 1:07:38 pm Ivan Voras wrote:
> > > 2009/4/6 John Baldwin :
> > > > On Sunday 05 April 2009 12:23:39 pm Sergey Babkin wrote:
> > >
> >
On Tuesday 07 April 2009 9:14:26 pm Sergey Babkin wrote:
> John Baldwin wrote:
> >
> > On Monday 06 April 2009 11:12:33 pm Sergey Babkin wrote:
>
> > > Anyway, as far as I can tell, it's only the base register of
> > > the simulated DEC21140 device
does not
> concern me that a interrupt can potentially interrupt the code.
You should just use a MTX_DEF mutex. Also, if you use M_NOWAIT, you will need
to handle malloc() returning NULL. In general I try to allocate things while
not holding any locks when possible and only acquire the lock to initialize
the memory returned from malloc().
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
On Tuesday 14 April 2009 8:46:51 pm Sergey Babkin wrote:
> John Baldwin wrote:
> > Your printf() probably isn't in the right place. pci_add_map() uses
> > PCIB_READ_CONFIG() directly and doesn't use pci_read_config(), so if your
> > printf is in pci_read_config_meth
release to do this.
This should work. I would maybe hack on src/release/Makefile and remove the
'@' from the lines in the iso.1 target to make sure it is doing things the way
you expect. You could make mkisoimages.sh echo the mkisofs comman
On Tuesday 21 April 2009 4:17:53 am Manolis Kiagias wrote:
> John Baldwin wrote:
> > On Saturday 18 April 2009 6:30:54 pm Manolis Kiagias wrote:
> >
> >> # make release CHROOTDIR=/data/release BUILDNAME=7.2-PRERELEASE
> >> CVSROOT=/data/ncvs EXTSRCDIR=/usr/sr
alloc_ring and
setup_data_maps at the same time during your attach routine. Similarly for
free_ring and free_data_maps during detach.
> As a side-note, the manpage does not document the behaviour when
> bus_dmamap_destroy() or bus_dma_tag_destroy() are called whilst a
> bu
e (I know what
> determines the quality of a clock visually from a oscilloscope =])?
I suspect that the quality of the HPET driver is lower simply because no one
had measured it previously and HPET is newer and less "proven".
--
John Baldwin
_
; I am currently trying to work a bit on the remaining "missing
> >>> feature" that NVIDIA requires (
http://wiki.freebsd.org/NvidiaFeatureRequests
> >>> or a back post in this ML) - the improved mmap system call.
>
>
> you might check with jhb (john Baldwin)
f a || like so:
> #if defined(_KERNEL) && !defined(__cplusplus)
I think this would be ok to let C++ work in the kernel. "Embedded" C++ (no
exceptions and no dynamic_cast<>) should work fine in theory. I would not
change the value of NULL that userland sees though
mory
anyway.
> - Use an rw/rm/sxlock to protect the sysctl tree, but only pick up
> the lock when we traverse parts of the sysctl tree that has
> dynamically created entries.
I don't think further work is needed here for the tree, notice that in-kernel
sysctls are already concurre
. However, do you really expect a symlink to be longer
than 2^31 on a 64-bit machine?
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freeb
On Monday 11 May 2009 2:33:09 pm Kostik Belousov wrote:
> On Mon, May 11, 2009 at 02:05:07PM -0400, John Baldwin wrote:
> > On Friday 28 September 2007 10:39:56 pm Ighighi wrote:
> ^
Yes, I had this stuck in the back of my head from when it first appeared
On Monday 11 May 2009 2:58:14 pm Kostik Belousov wrote:
> On Mon, May 11, 2009 at 02:46:14PM -0400, John Baldwin wrote:
> > On Monday 11 May 2009 2:33:09 pm Kostik Belousov wrote:
> > > On Mon, May 11, 2009 at 02:05:07PM -0400, John Baldwin wrote:
> > > > On Friday
are a bit
> more detailed below.
>
> On Mon, May 11, 2009 at 12:24 PM, John Baldwin wrote:
> > On Friday 08 May 2009 5:41:17 pm Ed Schouten wrote:
> >> A solution would be to solve it as follows:
> >>
> >> - Use a semaphore, initialized to some insane
uld check it myself. It might be better to replace the loop with a
vm_fault(..., VM_FAULT_DIRTY) though if that would have the same effect.
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd
On Thursday 14 May 2009 5:34:26 pm Ed Schouten wrote:
> * John Baldwin wrote:
> > Well, in theory a bunch of "small" requests to SYSCTL_PROC() nodes that
used
> > sysctl_wire_old() (or whatever it is called) could cause the amount of
user
> > memory wired for s
iority
for kernel threads (currently a rather bogus PVM I think).
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
/usr/src/sys/kern/kern_sig.c:2292
> hasn`t run function wake up on string 2292
> I`m think, what compiler use inline function, therefore code and trace
> differ.
> Tell me please, how compile kernel without any inline function.
makeoptions DEBUG="-g -fno-inline"
However.
On Thursday 04 June 2009 9:02:32 am Menshikov Konstantin wrote:
> John Baldwin wrote:
> > On Thursday 04 June 2009 5:24:07 am Menshikov Konstantin wrote:
> >
> >> Hi.
> >> My system FreeBSD 7.1 RELEASE periodically freeze.
> >>
> >>
fff80a25320},
> lod_witness = 0x80a25320}}
> (kgdb) p *lock1
> $7 = {li_lock = 0x80a12db8, li_file = 0x807c22f5
> "/usr/src/sys/kern/kern_sig.c", li_line = 2291,
> li_flags = 65536}
Ok, can you 'p *lock1->li_lock'?
--
John
27;lcd /folder/with/scripts' and 'source gdb6'. You
can then do 'lockchain 4283' to find who holds the lock this thread is
blocked on and what state they are in. You can use 'show lockchain 4283' in
DDB for similar info as well.
--
John Baldwin
__
On Tuesday 16 June 2009 1:52:23 pm Mel Flynn wrote:
> Hi John,
>
> On Tuesday 16 June 2009 04:19:57 John Baldwin wrote:
> > On Monday 15 June 2009 5:53:05 pm Mel Flynn wrote:
>
> > > PIDTID COMM TDNAME KSTACK
On Tuesday 16 June 2009 7:01:45 pm Mel Flynn wrote:
> On Tuesday 16 June 2009 11:02:42 John Baldwin wrote:
> > On Tuesday 16 June 2009 1:52:23 pm Mel Flynn wrote:
> > > Hi John,
> > >
> > > On Tuesday 16 June 2009 04:19:57 John Baldwin wrote:
> > >
On Wednesday 17 June 2009 3:52:54 pm Mel Flynn wrote:
> On Wednesday 17 June 2009 04:15:26 John Baldwin wrote:
> > On Tuesday 16 June 2009 7:01:45 pm Mel Flynn wrote:
> > > On Tuesday 16 June 2009 11:02:42 John Baldwin wrote:
> > > > On Tuesday 16 June 2009 1:52:23 pm
On Wednesday 17 June 2009 6:11:42 pm Mel Flynn wrote:
> On Wednesday 17 June 2009 13:17:37 John Baldwin wrote:
> > On Wednesday 17 June 2009 3:52:54 pm Mel Flynn wrote:
> > > On Wednesday 17 June 2009 04:15:26 John Baldwin wrote:
> > > > On Tuesday 16 June 2
On Wednesday 17 June 2009 6:11:42 pm Mel Flynn wrote:
> On Wednesday 17 June 2009 13:17:37 John Baldwin wrote:
> > These are the key frames. It looks like uipc_peeraddr() tries to lock two
> > unp locks w/o any protection from the global unp linkage lock. I've
> >
default:
- error = EINVAL;
+ error = ENOSYS;
break;
}
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
ing any callout indefinitely will stall the entire callout
> thread indefinitely, which in turn could lead to a variety of odd behaviors
> and potentially (although not necessarily) deadlock.
FWIW, we do not actually sort the callouts in this manner,
>len < 0 ||
+ if ((ssize_t) uap->len <= 0 ||
((flags & MAP_ANON) && uap->fd != -1))
return (EINVAL);
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/
hey suballocate regions from
BARs in the PCI device or is your device a subtractive bridge that will
forward requests for ISA ranges and your devices all use ISA ranges?
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/ma
On Monday 13 July 2009 2:49:24 pm Robert N. M. Watson wrote:
>
> On 13 Jul 2009, at 19:17, John Baldwin wrote:
>
> >> Callouts are marked as MPSAFE or non-MPSAFE when registered. If
> >> non-MPSAFE,
> >> we will acquire Giant automatically for the call
On Monday 13 July 2009 3:33:51 pm Tijl Coosemans wrote:
> On Monday 13 July 2009 20:28:08 John Baldwin wrote:
> > On Sunday 05 July 2009 3:32:25 am Alexander Best wrote:
> >> so mmap differs from the POSIX recommendation right. the malloc.conf
> >> option seems more
On Tuesday 14 July 2009 3:08:40 am Norbert Koch wrote:
>
> John Baldwin schrieb:
> > On Monday 13 July 2009 10:05:15 am Norbert Koch wrote:
> >
> >> Hello.
> >>
> >> I just started to write a device
> >> driver for a multi-function pci card
this
is probably to create a rman from your resource and then use
rman_reserve_resource() to sub-allocate chunks of that to your children).
For the interrupt resource you can just return your own resource pointer
directly in your bus_alloc_resource() routine.
--
John Baldwin
___
gt; >
> > I'm out of ideas.
> > John, do you know if this is a newbus limitation or if it can be
> > worked around ?
>
> I assume it is possible somehow, I am just too stupid (it is the first
> driver I wrote). John, for easy refe
for /dev/ppiX devices in /dev.
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
fic question, about why the driver did something
> > I should recall that. The ipmi(4) driver is in fairly clean. There
> > is some improvements I still need to do on probe/attachment that
> > causes a bogus ipmi1 at times.
>
> Thanks a lot for this interesting information. I see, things are more
> complicated than I thought. There is no easy way having a quick glance
> at "foreign" memory during probing. Now I have to figure out how to get
> the order of probing/attaching done. One thing I could do is:
>
> 1. attach mydriver_ACPI to acpi0
>
> 2. probe mydriver under hostb0, check if we need access to
>sysresources from acpi0 (depends on the chipset found).
>If no, goto 5.
>
> 3. ask mydriver_ACPI about stuff I want to know (HOW?)
>
> 4. tell mydriver to detach from acpi0 (HOW?)
>
> 5. attach mydriver to hostb0 and do my work
>
> What I would like more is something like:
>
> 1. probe mydriver under hostb0, check if we need access to
>sysresources from acpi0 (depends on the chipset found).
>If no, goto 3.
>
> 2. ask mydriver_ACPI to attach to acpi0, give me the info
>I want, detach mydriver_ACPI (HOW?)
>
> 3. attach mydriver to hostb0 and do my work
Did you try
doing 'bus_alloc_resource(device_get_parent(device_get_parent(dev))' in your
driver that is a child of hostb0?
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
On Thursday 23 July 2009 10:25:40 am Doug Ambrisko wrote:
> John Baldwin writes:
> | On Thursday 23 July 2009 2:08:35 am Andre Albsmeier wrote:
> | > On Wed, 22-Jul-2009 at 09:48:56 -0700, Doug Ambrisko wrote:
> | > > Andre Albsmeier writes:
> | > > | On Sat, 18-J
_RESOURCE(device_get_parent(dev), child,
type, rid, start, end, count, flags));
...
}
Rather than trying to allocate the whole chunk of the ACPI resource, I would
just do a specific allocation like so:
rid = 0;
res = BUS_ALLOC_RESOURCE(device_get_parent(de
hing i
> can cope with in my app.
Hmmm, that is a bit much. Though I do suppose you are incurring a user ->
kernel -> user transition for each I/O access.
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.o
ks (and
then you can use vn_open(), but _not_ kern_open()). I answered that question
just last week in another thread ("Driver development question" on drivers@).
However, in general the kernel is not nearly as friendly an environment as
userland, and it can be quite saner a
point at anything. File descriptors
are a property of userland processes, not of kernel processes. However,
fd_[cjr]dir need to be valid to perform any namei() lookup even if one is
simply going to do a vn_open() on the resulting vnode (which is
nterface with a menu of possible partitions,
etc.
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
f ps starts displaying more stuff no matter if
that stuff is correct and less stuff (current state) is incorrect
> 2. your personal preference is that current defaults are lovely
POLA
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
ew minutes.
One thing to note is that ktrace only logs voluntary context switches (i.e.
call to tsleep or waiting on a condition variable). It specifically does not
log preemptions or blocking on a mutex, so in theory if your machine was
livelocked temporarily that might explain t
up this patch and hope someone can
> tell me why this would or wouldn't work:
You would read back 0x3f9 because the lower 3 bits of a BAR are various flags.
bit 0 indicates if a BAR is for I/O (1) or memory (0) hence why you read back
0x3f8 | 0x1.
--
John Baldwin
___
RT,0xe800
>
> in src/sys/boot/i386/boot2/sio.S work? If it does, I can develop code to read
> and set it to the current port instead of hard-coding it.
Yes, I would try that. You can also just do 'BOOT_COMCONSOLE_PORT=0xe800' to
see if that will work as a test w/o having to modify any of the boot2 code
directly.
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
e accumulated value of
if_ierrors:
/* Rx Errors */
ifp->if_ierrors = total_missed_rx + adapter->stats.crcerrs +
adapter->stats.rlec;
It also increments if_ierrors in ixgbe_rxeof(). The driver should only do one
or the other, but probably not both.
--
On Monday 31 August 2009 3:15:53 pm Andrew Brampton wrote:
> 2009/8/31 John Baldwin :
> > It should be total and it sounds like a bug in the device driver. It
looks
> > like ixgbe_update_stats_counters() overwrites the accumulated value of
> > if_ierrors:
> &
If all the
CPUs are idle but some threads are blocked on locks you might have a
deadlock, etc.
You can use the gdb scripts at http://www.FreeBSD.org/~jhb/gdb/ in kgdb to
figure some of that stuff out (source gdb6 from within gdb. I usually start
with 'ps').
--
John Baldwin
mutexes (just force LO_QUIET on in
mtx_init() if MTX_SPIN is set) and use a schedgraph.py from the latest
RELENG_7. It knows how to parse KTR_LOCK events and drop event "bars" for
locks showing when they are held. A more recently schedgraph.py might also
fix the bugs you were seeing wi
On Friday 11 September 2009 11:35:14 am Julian Elischer wrote:
> John Baldwin wrote:
> >
> >
> > A more recently schedgraph.py might also
> > fix the bugs you were seeing with the idle threads looking too long (esp.
at
> > the start and end of graphs).
>
&
On Friday 11 September 2009 1:35:00 pm Linda Messerschmidt wrote:
> On Fri, Sep 11, 2009 at 11:02 AM, John Baldwin wrote:
> > Try turning off KTR_LOCK for spin mutexes (just force LO_QUIET on in
> > mtx_init() if MTX_SPIN is set)
>
> I have *no* idea what you just said.
write capabilities or there is no sense in trying
> other tools than svk?
I have used svk for this at ${JOB} and it works well for managing the mirror.
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listin
. I had just a quick look so far.
> I'll look more to see what tio change to compile my 80386 kernel.
> PS I cc'd jhb@ who seems to be the one who removed 80386.
> Maybe he has a patch set or comment.
My comment is to just use 4.x (seriously). A true 386 is going to be
On Wednesday 23 September 2009 11:54:34 am Julian H. Stacey wrote:
> Rui Paulo wrote:
> > On 22 Sep 2009, at 19:03, Nate Eldredge wrote:
> >
> > > On Tue, 22 Sep 2009, John Baldwin wrote:
> > >
> > >> My comment is to just use 4.x (seriously). A true
On Wednesday 23 September 2009 1:21:59 pm Julian Elischer wrote:
> John Baldwin wrote:
> > On Wednesday 23 September 2009 11:54:34 am Julian H. Stacey wrote:
> >> Rui Paulo wrote:
> >>> On 22 Sep 2009, at 19:03, Nate Eldredge wrote:
> >>>
>
for tier-1
> architectures).
The memory clobber is quite heavyweight. It actually forces gcc to forget any
cached memory items in registers and reload everything again. What I really
want is just a barrier to tell GCC to not reorder things. If I read a value
in the program before acquiring a lock it is in theory fine to keep that
cached across the barrier. However, there isn't a way to do this sort of
thing with GCC currently.
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
On Tuesday 29 September 2009 3:15:40 pm Attilio Rao wrote:
> 2009/9/29 John Baldwin :
> > On Tuesday 29 September 2009 11:39:37 am Attilio Rao wrote:
> >> 2009/9/25 Fabio Checconi :
> >> > Hi all,
> >> > looking at sys/sx.h I have some troubles understan
On Tuesday 29 September 2009 4:26:56 pm Marius Nünnerich wrote:
> On Tue, Sep 29, 2009 at 21:15, Attilio Rao wrote:
> > 2009/9/29 John Baldwin :
> >> On Tuesday 29 September 2009 11:39:37 am Attilio Rao wrote:
> >>> 2009/9/25 Fabio Checconi :
> >>> >
o see
> what do they implement in regard of volatile operands.
GCC can be quite aggressive with reordering even in the face of volatile. I
was recently doing a hack to export some data from the kernel to userland
that used a spin loop to grab a snapshot of the contents of a structure
similar to th
On Tuesday 29 September 2009 5:39:43 pm Attilio Rao wrote:
> 2009/9/29 John Baldwin :
> > On Tuesday 29 September 2009 4:42:13 pm Attilio Rao wrote:
> >> 2009/9/29 Max Laier :
> >> > On Tuesday 29 September 2009 17:39:37 Attilio Rao wrote:
> >> >>
Attilio Rao wrote:
2009/9/29 John Baldwin :
On Tuesday 29 September 2009 4:42:13 pm Attilio Rao wrote:
2009/9/29 Max Laier :
On Tuesday 29 September 2009 17:39:37 Attilio Rao wrote:
2009/9/25 Fabio Checconi :
Hi all,
looking at sys/sx.h I have some troubles understanding this comment
#x27; # XXX: this removes the unfilled part of
> a capture buffer
> + echo
> + fi
> + rm -f $file
> +fi
> +
>
I'm definitely in favor of this. I assume you have tested it locally? Do you
have a sample
crash.X.txt file with it enabled?
--
John
; thanks for clearing things up.
>
> however i stil think mentioning this situation in the mmap(2) manual (maybe in
> section MAP_FIXED) would be a good idea.
I'm not sure it is useful to attempt to enumerate all the possible ways one
can shoot one's own foot using mmap(2)
ut should apply cleanly to
> CURRENT: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/71258
A simpler patch would be to simply set pos = 0 below the MAP_STACK line if
MAP_ANON is set.
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
ht
or of a 1:1 threading model when 7.0 was released”
>
> Does it mean the KSE syscall can be removed from FreeBSD 7.0?
It has been removed entirely from 8.0. It is still present in 7, but it is
deprecated and not the default.
--
John Baldwin
to support either PTHREAD_PROCESS_SHARED
> > mutexes, or pshared posix semaphores in FreeBSD?
>
> It's planned, just not (yet) being actively worked on.
> It's a API change mostly, and then adding in all the
> compat hooks so we don't break ABI.
There are also an
On Friday 23 October 2009 10:56:06 am Daniel Eischen wrote:
> On Fri, 23 Oct 2009, John Baldwin wrote:
>
> > On Thursday 22 October 2009 5:17:07 pm Daniel Eischen wrote:
> >> On Thu, 22 Oct 2009, Andrew Gallatin wrote:
> >>
> >>> Daniel Eischen wrote:
&
On Friday 30 October 2009 10:38:24 pm Alexander Best wrote:
> John Baldwin schrieb am 2009-10-21:
> > On Wednesday 21 October 2009 11:51:04 am Alexander Best wrote:
> > > although the mmap(2) manual states in section MAP_ANON:
>
> > > "The offset argument is i
On Monday 02 November 2009 4:05:56 pm Alexander Best wrote:
> John Baldwin schrieb am 2009-11-02:
> > On Friday 30 October 2009 10:38:24 pm Alexander Best wrote:
> > > John Baldwin schrieb am 2009-10-21:
> > > > On Wednesday 21 October 2009 11:51:04 am Alexander Best
On Monday 02 November 2009 5:14:27 pm Alexander Best wrote:
> John Baldwin schrieb am 2009-11-02:
> > On Monday 02 November 2009 4:05:56 pm Alexander Best wrote:
> > > John Baldwin schrieb am 2009-11-02:
> > > > On Friday 30 October 2009 10:38:24 pm Alexander Best
s/95399/functions/mmap.html for
> > the following:
> >
>
> Just by accident I saw they changed that behaviour in a newer version of
> the spec:
>
> http://www.opengroup.org/onlinepubs/9699919799/functions/mmap.html
No
--- i386/xen/mp_machdep.c (revision 198997)
+++ i386/xen/mp_machdep.c (working copy)
@@ -31,6 +31,7 @@
#include "opt_cpu.h"
#include "opt_kstack_pages.h"
#include "opt_mp_watchdog.h"
+#include "opt_
=> return EINVAL
> 2) if MAP_STACK is defined and offset !=0 > offset = 0
>
> would be great if you could have a look at the patch if you've got a spare
> minute.
I didn't think 2) changed? I.e. both the old and new cod
very general
purpose, but it can be useful if you pin all your tasks to specific packages.
I haven't tested it with non-pinned workloads to see what effect it has.
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.or
is now 142 instead of 33. The scheduler
is likely far happier with that stathz. There is more detail in the commit
log I believe (just look at the logs for local_apic.c in either svn or
cvsweb).
--
John Baldwin
___
freebsd-hackers@freebsd.org ma
On Friday 04 December 2009 4:09:59 pm Ivan Voras wrote:
> 2009/12/4 John Baldwin :
> > On Friday 04 December 2009 9:52:39 am Ivan Voras wrote:
> >> For a long time, at least in the 6-stable timeframe, I was used to
> >> seeing timer interrupts going at the frequency of 2
hen it can result in
superpages being fragmented and never reassembled. Using vfork() should
prevent this from happening. It is a known issue, but it will probably be
some time before it is addressed. There is lower hanging fruit in other areas
in the VM that will probably be worked on firs
On Thursday 10 December 2009 9:50:52 am Bernd Walter wrote:
> On Wed, Dec 09, 2009 at 09:07:33AM -0500, John Baldwin wrote:
> > On Thursday 26 November 2009 10:14:20 am Linda Messerschmidt wrote:
> > > It's not clear to me if this might be a problem with the superpages
>
lication bug of some sort.
The segv trace doesn't include the first part of GDB messages which show which
thread actually had a seg fault. It looks like it was the thread that was
throwing an exception. However, nanosleep() doesn't throw exceptions, so that
stack trace doesn&#x
On Thursday 17 December 2009 12:27:17 pm Steven Hartland wrote:
> - Original Message -
> From: "John Baldwin"
> > For the hang it seems you have a thread waiting in a blocking read(), a
> > thread
> > waiting in a blocking accept(), and lots of threads
On Monday 21 December 2009 9:45:53 am Steven Hartland wrote:
> - Original Message -
> From: "John Baldwin"
> >> I've uploaded a two more traces for the oxt test failure / segv.
> >> http://code.google.com/p/phusion-passenger/issues/detail?id=441#
-p'. Some utilities also use it instead of _PATH_DEFPATH for
> root, but these values tend to be overridden by /etc/login.conf and/or
> shell startup files.
I vote to fix it. That's an old bug. :)
--
John Baldwin
___
freebsd-hackers@freeb
ubdirectory in /boot was going to be.
> >
> > (Default value for INSTKERNNAME is "kernel", which isn't something I
> > find useful to report.)
>
> Woopps. Cache-corruption;-) The original one is fine then.
Or maybe 'Installing INSTALLKERNEL as INSTKERNNAME'
paddr = pmap_extract(pmap, vaddr);
else
paddr = pmap_kextract(vaddr);
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/fr
heduler would always
> reload the same thread to execute the dma sync code ...
Ahh. I think bus_dmamap_load_uio() doesn't do deferred callbacks (i.e.
mandates BUS_DMA_NOWAIT), and probably is always invoked from curthread. Even
in the case of aio, the thread's vmspac
a slower version of using an sx
lock. If you have a very simple driver I would just use an sx lock. If you
later find that you need to optimize it then you can look at doing something
fancier. If you already have other state you are frobbing that includes the
equivalent of a buffer_in_use fl
EFIX /usr/obj-i386
> setenv TARGET i386
> setenv TARGET_ARCH i386
>
> then 'make buildworld' in /usr/src
Can you verify that 'make buildworld TARGET=i386' works? If so, can you
try just setting MAKEOBJDIRPREFIX via setenv (or setting it as an
nodev hugetlbfs
iso9660
nodev relayfs
nodev mqueue
ext3
nodev rpc_pipefs
nodev nfs
nodev nfs4
nodev autofs
To do the same thing in FreeBSD you would need to walk the vfsconf list
instead. However, I'm not sure it is worth it to add this unless there
are apps peop
On Tuesday 26 January 2010 4:52:35 pm Fernando Apesteguía wrote:
> 2010/1/15 John Baldwin :
> > On Friday 08 January 2010 12:19:29 pm Fernando Apesteguía wrote:
> >> Hi all,
> >>
> >> This patch implements the "filesystems" file in the linux proc
On Wednesday 27 January 2010 3:32:17 pm Fernando Apesteguía wrote:
> 2010/1/27 John Baldwin :
> > On Tuesday 26 January 2010 4:52:35 pm Fernando Apesteguía wrote:
> >> 2010/1/15 John Baldwin :
> >> > On Friday 08 January 2010 12:19:29 pm Fernando Ap
On Wednesday 27 January 2010 4:47:55 pm Kostik Belousov wrote:
> On Wed, Jan 27, 2010 at 04:10:33PM -0500, John Baldwin wrote:
> > I'm not aware of a portable way to obtain this information across all UNIX
> > variants. For FreeBSD, there isn't a way for userland
y
have among other things. Typically if all you have is ATA device (adX), then
the lowest numbered adX device would be 0, the next adX device would be 1,
etc. However, if you have drives attached to multiple storage controllers
then it depends on the order the controllers register their opti
the automatic promotion / demotion. That is a far-less common feature.
FreeBSD/i386 has used large pages for the kernel text as far back as at least
4.x, but that is not the same as superpages. Linux does not have automatic
promotion / demotion to my knowledge. I do not know about other OS's.
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
On Thursday 11 February 2010 2:05:12 am Julian Elischer wrote:
> John Baldwin wrote:
>
> > I think the unit number is largely ignored now. The kernel used to believe
> > it
> > for finding /, but the loader now reads /etc/fstab and sets a variable in
> > kenv
&
this using a non-FreeBSD server with a FreeBSD client or a
non-FreeBSD client with a FreeBSD server? That would narrow down the breakage
to either the client or the server.
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
601 - 700 of 1599 matches
Mail list logo
