(td->td_priority <= PRI_MAX_ITHD && THREAD_CAN_SCHED(td, self) &&
curthread->td_intr_nesting_level && ts->ts_cpu != self) {
SCHED_STAT_INC(pickcpu_intrbind);
ts->ts_cpu = self;
}
}
--
John Baldwin
___
riate comment in the new header that you use to replace
the 0x1000 in btx.S and in the definition of ARGADJ.
Hope that isn't too much, but I do think this will help make things even more
understandable.
--
John Baldwin
___
freebsd-hackers@fre
On Saturday, May 05, 2012 5:53:07 am Andriy Gapon wrote:
> on 05/05/2012 12:31 Andriy Gapon said the following:
> > on 04/05/2012 18:25 John Baldwin said the following:
> >> On Thursday, May 03, 2012 11:23:51 am Andriy Gapon wrote:
> >>> on 03/05/2012 18:02 A
e the equivalent of subtracting
KERNBASE from the load address. On both i386 and amd64, there is
a direct mapping of the kernel text such that KERNBASE maps address
0, etc. By default on i386 KERNBASE is 0xc000.
--
John Baldwin
___
freebsd-hackers@
On Monday, May 07, 2012 10:47:05 am Andriy Gapon wrote:
> on 07/05/2012 16:53 John Baldwin said the following:
> > On Saturday, May 05, 2012 5:53:07 am Andriy Gapon wrote:
> [snip]
> >> The new patchset: http://people.freebsd.org/~avg/zfsboot.patches.7.diff
> >
>
On Monday, May 07, 2012 11:15:53 am Andriy Gapon wrote:
> on 07/05/2012 17:47 Andriy Gapon said the following:
> > on 07/05/2012 16:53 John Baldwin said the following:
> >> Ok. Maybe add one comment to the bootargs.h head to explain that the
> >> 'bootargs'
On 5/8/12 3:14 AM, Andriy Gapon wrote:
> on 07/05/2012 20:43 John Baldwin said the following:
>> On Monday, May 07, 2012 10:47:05 am Andriy Gapon wrote:
>>> on 07/05/2012 16:53 John Baldwin said the following:
> [snip]
>>> What do you think about the -LOCORE- change
MFi386 of BTX changes for support of KARGS_FLAGS_EXTARG is pending.
> Do you think that it should be done?
You mean to pc98's btxldr? I think so, in general we should keep the
pc98 BTX bits as close to i386 as possible.
--
John Baldwin
___
freebs
On 5/10/12 5:41 AM, Andriy Gapon wrote:
> on 09/05/2012 14:28 John Baldwin said the following:
>> On 5/9/12 5:32 AM, Andriy Gapon wrote:
>>>
>>> Here is a subversion diff to make use of the new bootargs.h header in pc98
>>> cdboot and loader,
round wakeup to prevent lost wakeups. Note that in
a kernel without the SMP option, spin locks just devolve to
spinlock_enter/exit anyway.
--
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"
me on X32 and AMD64.
> The kernel seems to switch to long mode in /sys/amd64/amd64/mpboot.S
No. That is only for AP startup. The loader switches to long mode for an
amd64 kernel before it starts the kernel. For i386, boot2 and the loader
both start the kernel while running in f
port VM86). The only thing
I am aware of is the VESA bits but those use an emulator, they don't let the
CPU natively run BIOS routines. i386 could be adopted to do the same, but it
also doesn't make BIOS calls on modern systems outside of the
On Wednesday, May 16, 2012 9:24:54 am Eric McCorkle wrote:
> On 05/15/12 11:44, John Baldwin wrote:
> > The i386 kernel assumes it starts out with a flat 32-bit mode with
> > the kernel loaded into a contiguous memory region at a fixed
> > physical address. If we need a r
hell instead of traditional
> programming language for this kind of job is more straightforward and
> natural. Do you have a different opinion?
Have you looked at /usr/sbin/crashinfo?
--
John Baldwin
___
freebsd-hackers@freebsd.org mailin
7;t know what to ask for until looking at the
general information. There simply isn't a way to grab all the possible
information up front in textdumps.
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/list
(all consistent
with your hang). (And that is from your Ctrl-Alt-Esc)
Do you only have one CPU in this VM? If not, do you know which threads
the other CPUs were running (e.g. do you have ps7.png, etc.)?
--
John Baldwin
___
freebsd-hackers@freebs
;s going on. I'd like a hand trying to
> figure out why the schedgraph output is the way it is.
>
> Thanks!
As mentioned on IRC, you need to disable powerd and set machdep.idle=spin
and get new traces. Right now your traces show multiple things executing
on a single CPU.
--
John Bal
On Wednesday, May 30, 2012 12:07:50 pm Mark Felder wrote:
> On Wed, 30 May 2012 10:06:13 -0500, John Baldwin wrote:
>
> >
> > Do you only have one CPU in this VM? If not, do you know which threads
> > the other CPUs were running (e.g. do you have ps7.png, etc.)?
>
On Wednesday, May 30, 2012 3:56:02 pm Mark Felder wrote:
> On Wed, 30 May 2012 12:17:07 -0500, John Baldwin wrote:
>
> >
> > Humm, can you test it with 2 CPUs?
> >
>
> We primarily only run with 1 CPU. We have seen it crash on multiple CPU
> VMs. Also, Dane F
rupt. So, on this box (a Core i5), it can take 93 us after an
interrupt occurs during C3 before the CPU will get around to executing the
first instruction. It might be worse on your machine.
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing lis
0
> irq14: ata0 34 0
> irq18: em0 mpt0 1189748491218
> cpu0: timer 2174263198400
> Total 3364012124619
>
>
> I'm doing my best to ge
_ADD_CHILD() calls
device_add_child, which is perhaps wrong.)
For now I would change your child code to call a wrapper foo_delete_child()
function from your child drivers directly rather than calling
device_delete_child(). foo_delete_child() can do its cleanup and then call
device_delete_chi
On Thursday, May 31, 2012 12:15:48 pm Warner Losh wrote:
>
> On May 31, 2012, at 9:54 AM, John Baldwin wrote:
>
> > On Thursday, May 31, 2012 4:19:46 am Norbert Koch wrote:
> >> Hello,
> >>
> >> I have written a bus device driver
> >> w
n't look at Rock-Ridge extensions and only uses the base
ISO-9660 directory entries. That was enough fun to write in assembly.
OTOH, CD sectors are 2k, so you do have that much room to work with
and can probably fit a more advanced directory lookup into cdboot.
I'm happy to review
On Thursday, June 07, 2012 9:58:25 am rank1see...@gmail.com wrote:
> - Original Message -
> From: John Baldwin
> To: freebsd-hackers@freebsd.org
> Cc: rank1see...@gmail.com
> Date: Thu, 7 Jun 2012 08:21:39 -0400
> Subject: Re: CD bootcode
>
> > On Wednesday
On Friday, June 08, 2012 10:33:00 am rank1see...@gmail.com wrote:
> - Original Message -
> From: John Baldwin
> To: rank1see...@gmail.com
> Cc: hack...@freebsd.org
> Date: Thu, 7 Jun 2012 11:16:33 -0400
> Subject: Re: CD bootcode
>
> > On Thursday, June 0
able branches requires either increasing resources to support exising
releases longer, or slowing the pace of X.0 releases (but more aggressively
merging things from HEAD back). The latter case, especially, is part of
the culture and would be a choice we as a Proje
On Wednesday, June 13, 2012 11:52:28 am Adrian Chadd wrote:
> On 13 June 2012 05:53, John Baldwin wrote:
>
> >> You don't need to change the FreeBSD culture. We'd love to do an 8.4
> >> release. And an 8.5 release, and 8.6 release, etc. The problem is one
0 releases farther
apart then developers will still MFC things, the issue is that they don't
want to MFC to 2 stable branches.
--
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"
think
this is not nearly as complicated as you are making it out to be.
> The header unification has been "in progress" for years.
Actually, jilles@ has only been working on that for x86 in the last year or
so.
--
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"
people.freebsd.org/~davidxu/sysenter/kernel/sysenter.s
> movl PCPU(CURPCB),%esi
> call syscall
>
> Why do we movl PCPU(CURPCB),%esi before calling syscall? syscall is just c-
> function.
No clue on this one, looks like it is not needed.
--
John Baldwin
__
her modules in its kld are registered with new-bus before it tries to
attach to devices.
--
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, June 22, 2012 5:11:46 am Ruslan Bukin wrote:
> On Thu, Jun 21, 2012 at 08:12:41AM -0400, John Baldwin wrote:
> > On Wednesday, June 20, 2012 4:44:41 pm Ruslan Bukin wrote:
> > > Hi.
> > >
> > > I have the problem with different behavior of s
the MBR if needed while doing so.
> 6. I have changed userboot interface. I guess there is none consumers except
> the one test program. But if it isn't that, i can make it compatible.
One other consumer is in the bhyve branch. I think the 'kload' patches also
use it. However,
On Wednesday, June 27, 2012 12:50:20 am Andrey V. Elsukov wrote:
> On 26.06.2012 21:37, John Baldwin wrote:
> >> 4. The gptboot now searches the backup GPT header in the previous sectors,
> >> when it finds the "GEOM::" signature in the last sector. PMBR code
On Tuesday, June 26, 2012 5:23:08 pm Pawel Jakub Dawidek wrote:
> On Tue, Jun 26, 2012 at 01:37:11PM -0400, John Baldwin wrote:
> > > 4. The gptboot now searches the backup GPT header in the previous sectors,
> > > when it finds the "GEOM::" signature in the last sec
On Wednesday, June 27, 2012 10:08:17 am Pawel Jakub Dawidek wrote:
> On Wed, Jun 27, 2012 at 08:22:25AM -0400, John Baldwin wrote:
> > > I don't think so. Most common case is to configure partitions on top of
> > > a mirror. Mirroring partitions is less common. Mostly
On Wednesday, June 27, 2012 8:45:45 am Andrey V. Elsukov wrote:
> On 27.06.2012 16:07, John Baldwin wrote:
> >> • Check the Signature
> >> • Check the Header CRC
> >> • Check that the MyLBA entry points to the LBA that contains the GUID
> >> Partition
format is enforced by the vendor, so it is
reasonable to assume that metadata format will work across other OS's.
Anyway, I've said my piece and will let the matter drop from my end at this
point.
--
John Baldwin
___
freebsd-hackers@freebs
. Note that the firmware can also take up part of RAM as well (e.g. to
hold ACPI 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"
include/machine/cpufunc.h, but that is
> /usr/src/sys/amd64/include/cpufunc.h on amd64, which does not contain
> either of them.
The boot utilities on amd64 are built as 32-bit binaries using -m32
and with 'machine' pointing to 'i386&
Generally there is some sideband way for interrupt controllers to
register their available interrupt pins with the platform's nexus driver
(often the actual PIC is not managed via new-bus). You then need something
else to let a given device know which interrupt pin it wants (e.g. P
fferent terms; there is no way to currently specify multiple
> > independent (/overlapping) ivars in a child...
>
> There's no way to support overlapping IVAR keys, yes. However, if you are
designing the ivars for multiple inheritance, then you'll need to make them
non-ov
es
takes a few days for them to respond, but I've always had them respond.
--
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"
get_handle(dev) == NULL)
return (ENXIO);
if (pci_cfgregopen() == 0)
return (ENXIO);
device_set_desc(dev, "ACPI PCI-PCI bridge");
return (-1000);
}
New-bus is certainly not the only way to organize a device hierarchy and is
not perfect, but in your case I suggest you tone
it would be best to just call
kmem_alloc_attr() directly instead.
> BTW(2): Whilst studying busdma_machdep.c for arm and mips, I've
> noticed they appear to potentially allocate substantial kernel stack
> under some conditions as several bus_dma(9) functions include:
> bus_dma_se
ER
installs a periodic callout that executes KNOTE() and then resets itself (via
callout_reset()) each time it runs. This should generally be closer to
regulary spaced intervals than something that does:
for (;;) {
usleep(20 * 1000);
}
Which shou
On Thursday, July 12, 2012 9:57:16 am Ian Lepore wrote:
> On Thu, 2012-07-12 at 08:34 -0400, John Baldwin wrote:
> > On Wednesday, July 11, 2012 5:00:47 pm Ian Lepore wrote:
> > > On Wed, 2012-07-11 at 14:52 -0500, Paul Albrecht wrote:
> > > > Hi,
> > > >
On Thursday, July 12, 2012 11:08:47 am Davide Italiano wrote:
> On Thu, Jul 12, 2012 at 4:26 PM, John Baldwin wrote:
> > On Thursday, July 12, 2012 9:57:16 am Ian Lepore wrote:
> >> On Thu, 2012-07-12 at 08:34 -0400, John Baldwin wrote:
> >> > On Wednesday, July
nion is that Intel screwed up their implementation of that instruction
whereas AMD got it right, and we are merely working around Intel's CPU bug. :(
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/li
On Friday, July 13, 2012 8:22:13 am Davide Italiano wrote:
> On Thu, Jul 12, 2012 at 5:25 PM, John Baldwin wrote:
> > On Thursday, July 12, 2012 11:08:47 am Davide Italiano wrote:
> >> On Thu, Jul 12, 2012 at 4:26 PM, John Baldwin wrote:
> >> > On Thursday, July
On Friday, July 13, 2012 10:42:04 am Poul-Henning Kamp wrote:
> In message <201207130831.59211@freebsd.org>, John Baldwin writes:
>
> >Every FreeBSD/amd64 kernel in existent is vulnerable. In truth, my
personal
> >opinion is that Intel screwed up their implementa
example:
static void
ipmi_isa_identify(driver_t *driver, device_t parent)
{
struct ipmi_get_info info;
uint32_t devid;
if (ipmi_smbios_identify(&info) && info.iface_type != SSIF_MODE &&
device_find_child(parent, "ipmi", -1) == NULL) {
HTH!
This looks correct. A cosmetic nit would be to move the new changes up above
the "Traced system call" comment.
--
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 it
as a daemon provide anything running it via cron can't ? Are there any options
to stay away from , Linux only options etc ? Also does anyone know what
options there are for FreeBSD on sparc ?
I don't think I ported daemon mode for it. You will have to run it from cron
for now.
I do know that having a bunch of
people skype in would not be feasible (not enough bandwidth to send video out
in multiple streams). The video would need to go out in a single stream to a
distributor of some sort. And, quite frankly, despite Doug's "haves" vs
"have-nots" i
On Thursday, July 12, 2012 8:26:05 am John Baldwin wrote:
> However, rather add a wiredmalloc(), I think you should just have
> bus_dmamem_alloc() call kmem_alloc_attr() directly in this case. One of the
> things I've been meaning to add to bus_dma is a way to allocate other m
ueries the register. In some cases they read the registers
via a timer and cache the results and the sysctl handlers returned
the cached results.
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo
can give gains if you are careful to pin your threads to packages.
--
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 modifying the driver
or some other code, I am willing to try. Just need a little direction.
Hmm, does 'ifconfig foo down' not do this?
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/li
ing, that should work. Another option would be to break into gptboot's
prompt (similar to breaking into boot2) aud typing in 'ad1p2:/boot/loader' or
some such. If that works you should even be able to write that to
/boot.config on ada0p2's filesystem.
--
John Baldw
t; I propose this solution.
>
> In file /usr/src/include/net/ethernet.h add this lines:
>
> static inline void ether_addr_copy(ether_addr* src, ether_addr* dst) {
> #if defined(__i386__) || defined(__amd64__)
> *dst = *src;
> #else
> bcopy(src, dst, ETHER_ADDR_LEN);
Also, parts of the critically important headers do not live in machine/
> at all, e.g. the headers from libm.
>
> The work seems to be stale, do you want to cooperate with Tijl or continue ?
I think we should probably follow Tijl's model since we are on that path.
I originally preferre
> to/from headers.
>
> Thanks, I'm glad someone noticed this.
I doubt we even _need_ the ugliness. We should just use *dst = *src
unless there is a compelling reason not to.
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
On Wednesday, August 22, 2012 2:54:07 pm Adrian Chadd wrote:
> On 22 August 2012 05:02, John Baldwin wrote:
> > On Tuesday, August 21, 2012 12:34:42 pm Adrian Chadd wrote:
> >> Hi,
> >>
> >> What about just creating an ETHER_ADDR_COPY(dst, src) and putting
hat interrupts are available during
> bootup for some time.
No, interrupts do not work during bootup. If you can poll your hardware
you could use polling until interrupts are enabled (using 'if (cold)' to
check for the boot time before interrupts are enabled).
--
John Baldwin
___
ged, the only approach are left with is a brute-force crawl of
the filesystem looking for a file whose stat() results match your executable.
--
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, 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
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
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
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
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 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:
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 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
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
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
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"
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
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?
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
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 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
> &
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 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
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:
>
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"
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
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
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:
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
___
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, 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"?
&
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 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
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
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"
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
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
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
201 - 300 of 1599 matches
Mail list logo
