> > be more dynamic. Right now if you haven't touched UFS in 5 seconds it
> > throws the entire thing out on the first lowmem event. The LRU-approach
would
> > only throw the oldest 10% out on the first call, but eventually throw it
a
though at least 'pmbr' only works in terms of 512 bytes. :-(
Yes, the BIOS calls have always only used 512 byte sectors. There would
have to be an updated spec for those, and it would be a bit of a PITA to
use. I suspect the "right" answer for this on x86 is UEFI.
--
John Baldw
On Sunday, October 06, 2013 3:30:42 am Alexander Motin wrote:
> On 02.10.2013 20:30, John Baldwin wrote:
> > On Saturday, September 07, 2013 2:32:45 am Alexander Motin wrote:
> >> On 07.09.2013 02:02, Jeremie Le Hen wrote:
> >>> On Fri, Sep 06, 2013 at 11:29:11A
gt; > > (kgdb) up 7
> > > #7 0xc082c552 in inodedep_find (inodedephd=Variable "inodedephd" is
> not
> > > available.
> > > ) at /usr/src/sys/ufs/ffs/ffs_softdep.c:2073
> > > 2073/usr/src/sys/ufs/ffs/ffs_softdep.c: No such file or directory.
>
#7 0xc082c552 in inodedep_find (inodedephd=Variable "inodedephd" is not
> available.
> ) at /usr/src/sys/ufs/ffs/ffs_softdep.c:2073
> 2073/usr/src/sys/ufs/ffs/ffs_softdep.c: No such file or directory.
> in /usr/src/sys/ufs/ffs/ffs_softdep.c
> (kgdb)
--- dev/mfi/mfi_disk.c (revision 257407)
+++ dev/mfi/mfi_disk.c (working copy)
@@ -162,6 +162,7 @@
sc->ld_disk->d_unit = sc->ld_unit;
sc->ld_disk->d_sectorsize = secsize;
sc->ld_disk->d_mediasize = sectors * secsize;
+ sc->ld_disk->d_flags = DISKFLAG_DIRECT_COMPLETION;
if (sc->ld_disk->d_mediasize >= (1 * 1024 * 1024)) {
sc->ld_disk->d_fwheads = 255;
sc->ld_disk->d_fwsectors = 63;
--
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"
gt;
> #6 0xc0898d4c in calltrap () at /usr/src/sys/i386/i386/exception.s:169
> #7 0xc082c552 in inodedep_find (inodedephd=Variable "inodedephd" is not
> available.
> )
> at /usr/src/sys/ufs/ffs/ffs_softdep.c:2073
Please go to frame 7 and do 'x/i $rip'.
bsd-hackers
> > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
>
> I think that should be MI for us anyway. I'm not aware of any
> architectures FreeBSD supports with stacks that grow up. I'll give it a
> test on PPC.
ia64 has
uot;-x" option of cpuset for that purpose (to bind irq 260 and 261
in my example)?
Yes, cpuset -x.
--
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"
ximum age will
be more dynamic. Right now if you haven't touched UFS in 5 seconds it
throws the entire thing out on the first lowmem event. The LRU-approach would
only throw the oldest 10% out on the first call, but eventually throw it all out
if the situation remains dire.
--
John Baldwin
_
t; > > Dumping 186 MB: 171 155 139 123 107 91 75 59 43 27 11
> > > > >
> > > > > #7 0xc06caf34 in cache_lookup_times (dvp=0xc784a990,
> vpp=0xe7624ae8,
> > > > > cnp=0xe7624afc, tsp=0x0, ticksp=0x0) at
> > > > /usr/src/sys/kern
12
> > > panic: page fault
> > > Uptime: 23h0m41s
> > > Physical memory: 1014 MB
> > > Dumping 186 MB: 171 155 139 123 107 91 75 59 43 27 11
> > >
> > > #7 0xc06caf34 in cache_lookup_times (dvp=0xc784a990, vpp=0xe7624ae8,
> > > cn
> #7 0xc06caf34 in cache_lookup_times (dvp=0xc784a990, vpp=0xe7624ae8,
> cnp=0xe7624afc, tsp=0x0, ticksp=0x0) at
/usr/src/sys/kern/vfs_cache.c:547
Can you go up to this frame and do 'l'?
--
John Baldwin
___
freebsd-hackers@freebsd.o
On Friday, July 19, 2013 10:16:15 pm Yuri wrote:
> On 07/19/2013 14:04, John Baldwin wrote:
> > Hmm, that definitely looks like garbage. How are you with gdb scripting?
> > You could write a script that walks the PQ_ACTIVE queue and see if this
> > pointers ends up in the
On Friday, July 19, 2013 3:32:43 pm Yuri wrote:
> On 07/19/2013 08:00, John Baldwin wrote:
> > Well, you can probably find the value of 'm' in a register if you look at
the
> > dissassembly around the fault. You can then cast that pointer to the
right
> > type an
On Thursday, July 18, 2013 8:56:58 pm Yuri wrote:
> On 07/18/2013 13:52, John Baldwin wrote:
> > Are you in frame 8?
>
> For some reason the debug info is missing in frame 8, but is present in
> surrounding frames 7 and 9.
> The might be a bug in makefiles that debug f
On Thursday, July 18, 2013 3:56:46 pm Yuri wrote:
> On 07/18/2013 11:42, John Baldwin wrote:
> > Hmm, so this seems to indicate you have a page on the active queue that
> > doesn't have an associated VM object. Can you maybe 'p *m'? Maybe some
> > temporary
On Thursday, July 18, 2013 2:15:48 pm Yuri wrote:
> On 07/16/2013 08:07, John Baldwin wrote:
> > Can you go to frame 8 and do 'l' in kgdb?
>
> (kgdb) up 8
> #8 0x80baea78 in vm_pageout () at /usr/src/sys/vm/vm_pageout.c:829
> 829
sr/src/sys/amd64/amd64/trap.c:463
> #6 0x80cfc583 in calltrap () at
> /usr/src/sys/amd64/amd64/exception.S:232
> #7 0x8091a181 in _mtx_trylock (m=0x1, opts=0,
> file=, line=0) at /usr/src/sys/kern/kern_mutex.c:295
> #8 0x80baea78 in vm_page
s in
kgdb including 'sleepchain' and 'lockchain'.
http://www.freebsd.org/~jhb/gdb/
--
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"
acked by
that sglist. You could then insert that VM object into the kernel's address
space to map it into the kernel, or even make it available to userland via
d_mmap_single(), or direct manipulation of a process' address space via an
ioctl, etc.
--
John Baldwin
__
}
+#if defined(__amd64__) || defined(__i386__)
+if (irq < 16 && trig == ACPI_EDGE_SENSITIVE && pol == ACPI_ACTIVE_LOW)
+ pol = ACPI_ACTIVE_HIGH;
+#endif
BUS_CONFIG_INTR(dev, irq, (trig == ACPI_EDGE_SENSITIVE) ?
INTR_TR
cts its parent to tell it which children to manage and no
> probing is really done. The device only matches if its parent bus
> specifically said to use this driver.
Perhaps run this by Warner to make sure? (There is also a new-bus@ list FYI).
--
John Baldwin
__
;agp", -1);
}
>
> 3) I really don't like the way that I am adding my child to gpiobus. Upon
> writing this it occurs to me that device_identify would be the canonical
> way to do this. Previously it wasn't clear to me how to fit
&g
ich also necessitated not allocating
> statfs on the stack for the kernel.
He also fixed a few other things since changing this ABI is so invasive
IIRC. This really is the right fix for this. Is it in an svn branch
that can be updated and a new patch generated?
--
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 Friday, May 24, 2013 6:24:11 am Jilles Tjoelker wrote:
> On Tue, May 21, 2013 at 11:06:39AM -0400, John Baldwin wrote:
> > On Monday, May 20, 2013 5:47:31 pm Jilles Tjoelker wrote:
> > > The below patch allows deleting the pathname given to find itself:
>
> > >
an older loader such as from 8.3 release before all the recent
changes to rototill the disk partition code?
Also, the BIOS "knows" which devices are floppies (0x00 - 0x7f) vs hard drives
(0x80 - 0xff) and we should probably just not prove for ZFS on floppies.
Of course, I think USB floppies might present themselves as hard drives.
--
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"
ccpath);
I'm curious, how would you instruct a patched find to avoid deleteing the
/tmp/foo directory (e.g. if you wanted this to be a job that pruned empty
dirs from /tmp/foo but never pruned the directory itself). Would -mindepth 1
do it? (Just asking. I have also found this message anno
gt; been any previos FOREACH involved.
> >>
> >> TAILQ_FOREACH_FROM(...) ?
> >
> > Agreed. Thanks for the input.
>
> Here's an untested patch for consideration:
>
>
http://people.freebsd.org/~lstewart/patches/misc/queue_foreach_from_10.x.r250136.pa
ff85c789
> > IDT= 5e00 0197
> > CR0=0011 CR2= CR3= CR4=
> > DR0= DR1=00000000 DR2=
DR3=
> > DR6=0ff0 DR7=0400
> > CCS=0001 CCD=0
98 2067 8900 DPL=0 TSS32-avl
> GDT= ff85c789 0000
This seems wrong (address is way too high). I wonder if the gdtdesc was
trashed by something? Can you dump memory before the lgdtl instruction at the
0x95d0 address?
--
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 Monday, April 22, 2013 12:29:29 pm Freddie Cash wrote:
> On Mon, Apr 22, 2013 at 8:32 AM, John Baldwin wrote:
>
> > On Saturday, April 20, 2013 6:43:26 pm Robert Waksmundzki wrote:
> > > On NUMA systems allocated memory is striped across local and non-local
> >
_hdr+0x7# Flag reboot
jmp exit# Exit
And the 'exit' label eventually ends up at the 'exit.3' code I quoted
above. If the BIOS VMWare exports a reboot routine VMWare doesn't like
then VMWare needs to fix its BIOS. :)
The op
y domain the current thread is
running in at the time of the fault.)
--
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"
gt; this is a result of my own tests.
How do your tests work? Do you examine PTEs directly to check for superpages
or are you relying on the vm.pmap.pde sysctls?
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailm
On Monday, April 01, 2013 3:56:46 pm m...@freebsd.org wrote:
> On Mon, Apr 1, 2013 at 12:51 PM, wrote:
>
> > On Mon, Apr 1, 2013 at 11:24 AM, John Baldwin wrote:
> >
> >> On Saturday, March 30, 2013 5:30:21 pm m...@freebsd.org wrote:
> >> > Despite the m
slices. If an
interrupt arrives that awakens a higher priority thread (e.g. an interrupt
thread), or if your thread awakens a thread that has higher priority (e.g. due
to wakeup() or cv_signal()), then your thread will be preempted.
In general time-based preemptions are only d
no
deadlock is possible. The WITNESS checker in the kernel ignores try locks
when checking for lock order reversals for this reason.
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To u
but old
> userspace to be sure nothing is broken. I plan to commit this next week if
> I don't hear otherwise.
Hmm, the patch URL doesn't work, but please fix this. There is an old thread
we are both on from Dec 2011 where I ran into
ou need to split the 'struct file' reference count into two different
counts similar to the how we have vref/vrele vs vhold/vdrop for vnodes. The
fget for accept and probably most other system calls should probably be
equivalent
to vhold, whereas things like open/dup (and storing an fd in
gt; disabled and can be moved to AcpiLeaveSleepState. This is after the _BFS and
> _GTS support was removed.
>
> What do you think?
> Thank you.
Hmm, I think intr_table_lock used to be a spin lock at some point. I don't
remember
why we changed it to a regular mutex. It may be that
quot;real" root. I think your
change is fine.
--
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, February 28, 2013 2:59:16 pm Ian Lepore wrote:
> On Tue, 2013-02-26 at 15:29 -0500, John Baldwin wrote:
> > On Friday, February 22, 2013 2:06:00 pm Ian Lepore wrote:
> > > I ran into some trouble with rtprio_thread() today. I have a worker
> > > thread
med objects) and pass that fd
into the kernel where an ioctl handler can map it into KVA using shm_map()
and shm_unmap(). You'd have to change TCP to do something useful with this
buffer however.
--
John Baldwin
___
freebsd-hackers@freebsd.org mail
idual
thread to an idle or real-time priority).
--
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"
s lower than your current
priority (and then you don't have to check TDF_BORROWING I believe):
if (prio < td->td_priority)
sched_priority(td, prio);
--
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"
ead as you've already called
pre_ithread? Also, pre_ithread should already EOI the interrupt, the problem
is that it leaves it masked, and you need to invoke post_ithread to unmask it.
--
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, February 12, 2013 4:50:54 pm Mikolaj Golub wrote:
> On Fri, Jan 25, 2013 at 03:31:43PM -0500, John Baldwin wrote:
>
> > BTW, one off-ball thought I have is that I would like to have a mode where
> > libprocstat operates on a core file (of a process, not a kern
On Tuesday, February 19, 2013 6:49:52 pm Steven Hartland wrote:
> - Original Message -
> From: "John Baldwin"
>
> Thanks for the feedback John appreciated, a couple of questions inline
> below if you would be so kind.
Certainly.
> > - Is dump_confi
fix is specific to the FreeBSD driver.
- Please don't do assignments in declarations and leave a blank line between
declarations and the bode of code. Thus:
mfi_op_desc(...)
{
int i, num_ops;
num_ops = nitems(mfi_op_codes);
he sense that you can't call routines like
m_pullup() or m_prepend(), etc. Your device should still be able to DMA
into the buffer, but once the buffer is passed up to the stack the stack
can't mess with it. This is probably what you want anyway as you wouldn't
want the stack
On Wednesday, February 06, 2013 10:20:50 am Jacques Fourie wrote:
> On Wed, Feb 6, 2013 at 3:36 PM, John Baldwin wrote:
>
> > On Wednesday, February 06, 2013 4:50:39 am Lino Sanfilippo wrote:
> > >
> > > Hi all,
> > >
> > > I want to implement a de
be freed until all the mbufs are freed.
--
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"
ttings.
It supports at least some of those. You can also load modules manually by
using the add-kld command (give it a full path to an individual module). You
may need to use 'nosharedlibrary' to unload symbols from the "wrong" module
before add-kld will be useful however.
dump? You have to use tcpdump -p to avoid putting
the chip into promiscuous mode if so (promiscious causes the NIC to
receive all multicast regardless of the filters assuming that your
driver supports it correctly).
--
John Baldwin
___
freebsd-hac
ve a ppc port that do not have an ISA slots.
--
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"
write a packet to
the multicast group.
However, a simpler test is to toggle the sysctl to enable multicast ping
replies and to ping a multicast address from another machine after joining it
on the test machine using mtest.
--
John Baldwin
___
freebs
oth in the kernel and in the preloaded file and
> the module has a module event handler (modeventhand_t), then the handler will
> registered and called twice.
Yes, I think it is too hard at present to safely allow a linker file to
override the same module in a kernel, so the duplic
On Friday, January 25, 2013 1:37:45 pm Robert N. M. Watson wrote:
>
> On 24 Jan 2013, at 16:20, John Baldwin wrote:
>
> >>> Hmm, are you going to rewrite ps(1) to use libprocstat? Or rather, is
that a
> >>> goal someday? That is one current consumer of kvm_ge
On Wednesday, January 23, 2013 4:49:50 pm Mikolaj Golub wrote:
> On Wed, Jan 23, 2013 at 11:31:43AM -0500, John Baldwin wrote:
> > On Wednesday, January 23, 2013 2:25:00 am Mikolaj Golub wrote:
> > > IMHO, after adding procstat_getargv and procstat_getargv, the usage of
>
On Wednesday, January 23, 2013 11:57:33 am Ian Lepore wrote:
> On Wed, 2013-01-23 at 08:47 -0800, Matthew Jacob wrote:
> > On 1/23/2013 7:25 AM, John Baldwin wrote:
> > > On Tuesday, January 22, 2013 5:40:55 pm Sushanth Rai wrote:
> > >> Hi,
> > >>
&
On Wednesday, January 23, 2013 2:25:00 am Mikolaj Golub wrote:
> On Tue, Jan 22, 2013 at 02:17:39PM -0800, Stanislav Sedov wrote:
> >
> > On Jan 22, 2013, at 1:48 PM, John Baldwin wrote:
> > >
> > > Well, you could make procstat open a kvm handle i
s are
not updated for a while.
We currently use the local APIC timer as a timer with a normal interrupt.
There's no reason you couldn't add a mode to make the local APIC timer operate
in this fashion however.
--
John Baldwin
___
freeb
On Tuesday, January 22, 2013 4:17:43 pm Mikolaj Golub wrote:
> On Tue, Jan 22, 2013 at 12:01:06PM -0500, John Baldwin wrote:
>
> > How is this different from kvm_getargv()? It seems to be a direct copy.
>
> libprocstat(3) is a frontend for sysctl(3) and kvm(3) interfaces,
27;t parse a filesystem, so it
just loads a raw partition assuming that the partition is the boot loader.
The 545k bit has to do with where it is loaded. The boot loader has to live
in the lower 640k, but it starts at 0x7c00 (the address that the BIOS always
loads boot loa
rgument vector obtained from
> the previous call. On the other hand this is ok for typical use cases
> while does not add allocation overhead, so I like this approach more.
>
> I would like to commit this second patch, if there are no objections
> or suggestions how to improve th
people.freebsd.org/~davidxu/patch/grep.c.diff2
>
> Is it fine to be committed ?
I think the first part definitely looks fine. My guess is the non-blocking
change is als probably fine, but that should be run by the bsdgrep person at
least.
--
John Baldwin
__
onfigs also include the unattended option so
that even with the debugger present they reboot by default on a panic.
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send
complained about procsize since the 4.x days as 5.0 introduced a new
kinfo_proc structure that the kernel exports and it hasn't changed in size
since 5.0.
The mfiutil issue dhw@ mentioned is real and is due to an mfi(4) driver
change. I merged a fix for the panics to 8-stable, but it just
afe script to load the old kernel in case of
> psnic.
man nextboot (if you are using UFS)
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to &quo
ial port.)
I think adding -b is fine.
--
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"
0.1 3324 1244 13 D+7:52PM 0:00.01
> > procstat -ka
>
> [... 69 more removed ...]
>
> I had 2 minutely cron entries that were running kldstat(1)/netstat(1).
>
> Guessing the kldstat(1) and netstat(1) deadlocked initially.
Next time get a dump if at all po
On Wednesday, December 05, 2012 6:51:17 pm Damien Fleuriot wrote:
>
> On 5 Dec 2012, at 18:39, Warner Losh wrote:
>
> >
> > On Dec 5, 2012, at 9:42 AM, John Baldwin wrote:
> >
> >> On Tuesday, December 04, 2012 2:41:32 pm Ryan Stone wrote:
> >>&g
On Tuesday, December 04, 2012 2:41:32 pm Ryan Stone wrote:
> On Tue, Dec 4, 2012 at 10:52 AM, John Baldwin wrote:
>
> > Hmm, I certainly see the module directories being built in parallel. Some
> > of
> > the make jobs may not be as obvious since links are silent (no out
On Sunday, November 04, 2012 2:53:02 pm Andre Oppermann wrote:
> On 22.10.2012 15:28, John Baldwin wrote:
> > On Sunday, October 21, 2012 7:11:10 am Andre Oppermann wrote:
> >> What's keeping kernel modules from building in parallel with
> >> "make -j8"?
&
der passes it's variables as a set of environment variables.
They are stored in a contiguous block of memory after the last kernel
module. Look at sys/boot/i386/libi386/bootinfo{32,64}.c. Specifically
look at the bi_load*() routines.
--
John Baldwin
___
On Sunday, October 21, 2012 7:11:10 am Andre Oppermann wrote:
> What's keeping kernel modules from building in parallel with
> "make -j8"?
They don't for you? They do for me either via 'make buildkernel'
or the old method.
--
John Baldwin
___
On Thursday, October 18, 2012 12:42:18 pm Konstantin Belousov wrote:
> On Thu, Oct 18, 2012 at 09:39:34AM -0400, John Baldwin wrote:
> > On Thursday, October 18, 2012 4:35:37 am Konstantin Belousov wrote:
> > > On Thu, Oct 18, 2012 at 10:08:22AM +1000, Tristan Verniquet wrote:
you have enough RAM and no pressure to hold all the file pages resident.
> The syncer will do a writeback periodically regardless of the application
> calling msync(2) or not, with the interval of approximately 30 seconds.
You can mmap with MAP_NOSYNC to prevent the syncer from writing the file out
y in the debugger or writing out a crashdump
should probably bust all locks (code executed in debugger backends should
generally avoid all locking at all, and depend on things like try locks where it
gracefully fails if it must use locking. That would make the kdb_active case
here irrelevant, an
and sleep queue hash tables.
--
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 Wednesday, October 10, 2012 5:44:09 pm Carl Delsey wrote:
> Sorry for the slow response. I was dealing with a bit of a family
> emergency. Responses inline below.
>
> On 10/09/12 08:54, John Baldwin wrote:
> > On Monday, October 08, 2012 4:59:24 pm Warner Losh wrote:
>
On Monday, October 08, 2012 4:59:24 pm Warner Losh wrote:
>
> On Oct 5, 2012, at 10:08 AM, John Baldwin wrote:
>
> > On Thursday, October 04, 2012 1:20:52 pm Carl Delsey wrote:
> >> I noticed that the bus_space_*_8 functions are unimplemented for x86.
> >> Look
and submit it.
I think cxgb* already have an implementation. For amd64 we should certainly
have bus_space_*_8(), at least for SYS_RES_MEMORY. I think they should fail
for SYS_RES_IOPORT. I don't think we can force a compile-time error though,
would just have to return -1 on reads or some su
On Thursday, October 04, 2012 8:31:36 pm Brooks Davis wrote:
> On Tue, Sep 25, 2012 at 08:41:34AM -0400, John Baldwin wrote:
> > On Monday, September 24, 2012 5:31:37 pm Brooks Davis wrote:
> > > As part of switching to NetBSD's mtree I plan to import their versions
> &
gt; Author: Andriy Gapon
> Date: Sun Sep 23 22:49:26 2012 +0300
>
> kvm_proc: ignore processes in larvae state
I think this is fine.
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/fre
On Tuesday, October 02, 2012 10:29:49 am Garrett Cooper wrote:
> On Tue, Oct 2, 2012 at 4:50 AM, John Baldwin wrote:
>
> ...
>
> > This sounds like a superior approach. It doesn't break any current use
> > cases while giving the ability to build multiple progra
ogether to avoid
stomping on each other's toes. It seems there are some differences in
the two approaches that merit working out to avoid a lot of wasted
effort on both sides.
Do we already have a freebsd-atf@ mailing list? If not, perhaps we
should create one and start these discussions there?
st
'contrib/libc' is that it is ambiguous. OTOH, the contrib/NetBSD/libc
path isn't too pretty either. One option would be to merge directly from
the vendor area into src/lib/libc. One other option might be to just
do src/contrib/vis if it is only for 'vis' files.
--
Joh
e.
This looks ok to me. Did it pass a 'make universe'?
--
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"
sanitize process names if you need to). However, a crashdump that
you can use kgdb on will make debugging this significantly easier.
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hack
ystem was unable to make forward progress, possibly it
had to malloc() something (GEOM is terrible for doing this)
while trying to page out something to free up space. I would
look at the state of the pagedaemon kthread to see why it isn't
able to run.
--
John Baldwin
On Friday, September 07, 2012 10:48:39 am John Baldwin wrote:
> On Thursday, September 06, 2012 5:08:27 pm Navdeep Parhar wrote:
> > I have a system with multiple cards supported by cxgbe(4). When I build
> > a kernel with the driver compiled in, it attaches to the cards in a
toms nearly perfectly.
>
> http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2004-02/0250.html
>
> Hopefully this gets us closer to a fix...
Sorry, I just now saw this. :(
Are you still seeing this, and if so can you get a crashdump? Also, I'm
curious if you
On Friday, September 07, 2012 12:39:50 pm Konstantin Belousov wrote:
> On Fri, Sep 07, 2012 at 12:23:54PM -0400, John Baldwin wrote:
> > On Friday, September 07, 2012 11:59:36 am Konstantin Belousov wrote:
> > > On Fri, Sep 07, 2012 at 10:33:52AM -0400, John Baldwin wrote:
On Friday, September 07, 2012 11:59:36 am Konstantin Belousov wrote:
> On Fri, Sep 07, 2012 at 10:33:52AM -0400, John Baldwin wrote:
> > On Tuesday, September 04, 2012 7:46:23 pm Sam Varshavchik wrote:
> > > Is the dev+ino of what was exec()ed known, for another process?
On Tuesday, September 04, 2012 7:46:23 pm Sam Varshavchik wrote:
> John Baldwin writes:
>
> > On Tuesday, September 04, 2012 7:10:42 am Sam Varshavchik wrote:
> > > Konstantin Belousov writes:
> > >
> > > > The procfs links, as well as any other user of
don't need -O0, probably just -g. You should probably do this
for libc as well I think. That might help your backtrace. What I tend to do
for these btw is build debug shared libraries and use LD_LIBRARY_PATH to
run my test program with those libraries rather than overwriting the main
l
e walks the 'pciX' bus devices in numerical order (rather than walking the
tree). I suspect your BIOS is doing something weird and assigning bus numbers
in a non-depth first ordering so that the two orderings are not consisent as
they are on other
On Tuesday, September 04, 2012 9:30:08 pm Warner Losh wrote:
>
> On Sep 4, 2012, at 10:05 AM, John Baldwin wrote:
>
> > On Sunday, September 02, 2012 5:31:21 pm Aleksander Dutkowski wrote:
> >> hello!
> >>
> >> I have PMIC (TWL4030) module connected t
1 - 100 of 1599 matches
Mail list logo
