t; procstat(8), fuser and fstat have been converted to use new functionality, so
> they are able to operate both on coredumps and on the live system.
> We still need to commit the libprocstat itself,
> though.
>
Just to let you know that I am eagerly await
on 12/11/2010 15:58 Stanislav Sedov said the following:
> On Fri, 12 Nov 2010 14:14:47 +0200
> Andriy Gapon mentioned:
>
>> Just to let you know that I am eagerly awaiting for that to happen.
>> Perhaps even could help with something if you'd need that.
>>
4
+#defineCPUTPM2_EFFREQ 0x0001
+
+/*
* Important bits in the AMD extended cpuid flags
*/
#defineAMDID_SYSCALL 0x0800
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To u
assed further down to sched_clock() and handled there
too.
--
Andriy Gapon
___
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"
2000))
> *val = -1;
> -}
> }
As is - this is a perfect candidate for a "local only" patch.
To be included into the tree - this, most probably, has to be controlled by a
tunable/sysctl.
--
Andriy Gapon
___
freebsd-hackers@free
32 KERNEL_FLAGS=-j32
> BUILDNAME=sbruno CHROOTDIR=/new_release
BTW, just in case, I think that EXTSRCDIR could be used to make a release out of
an existing src directory as opposed to code in a repository.
--
Andriy Gapon
--
Andriy Gapon
_
on 22/11/2010 01:18 Paul B Mahol said the following:
> On Sun, Nov 21, 2010 at 9:17 PM, Andriy Gapon wrote:
>> As is - this is a perfect candidate for a "local only" patch.
>> To be included into the tree - this, most probably, has to be controlled by a
>> tunab
lso by extension.
If I need to execute func() on all CPUs - which one is better again -
smp_rendezvous_cpus() or CPU_FOREACH+sched_bind?
Thanks a lot!
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-h
enter()/spinlock_exit() should be used to prevent races between
non-interrupt code and nested interrupt code.
What do you think?
Thanks!
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hacke
on 23/11/2010 08:33 Andriy Gapon said the following:
> I think that this is quite similar to what we do for per-CPU caches in UMA and
> so the same approach should work here.
> That is, as in (Open)Solaris, the data should be accessed only from the owning
> CPU and spinlock_enter()/s
other CPUs. However, I think all the interrupt
> bits will be MD, not MI.
That's a good idea and a comprehensive approach.
One minor technical detail - should an offlined CPU be removed from all_cpus
mask/set?
--
Andriy Gapon
___
fre
on 25/11/2010 17:28 John Baldwin said the following:
> Andriy Gapon wrote:
>> on 22/11/2010 16:24 John Baldwin said the following:
>>> Well, the real solution is actually larger than described in the PR. What
>>> you
>>> really want to do is take the logica
on 23/11/2010 15:26 Andriy Gapon said the following:
> on 23/11/2010 08:33 Andriy Gapon said the following:
>> I think that this is quite similar to what we do for per-CPU caches in UMA
>> and
>> so the same approach should work here.
>> That is, as in (Open)Solaris,
on 26/11/2010 21:10 Artem Belevich said the following:
> On Fri, Nov 26, 2010 at 5:54 AM, Andriy Gapon wrote:
>>> I will appreciate reviews and testing.
>>
>> Should I wait for any pending comments?
>> Otherwise I am confident enough in the patch to commit it.
>
pus().
The pc_cpumask should just be a cosmetic change.
--
Andriy Gapon
___
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"
closed too soon when handling the signal or something of that nature.
> It's also been suggested that this could be a bug in libdtrace, but I
> haven't the knowledge (or skill) to try and pinpoint the cause myself.
>
> Is there anyone here that may b
amp;dev->vblank[i].count, 0);
/usr/src/sys/dev/cxgb/ulp/tom/cxgb_tom.c: atomic_set_int(&t->tids_in_use,
0);
I wonder if these are all bugs and atomic_store_xxx() was actually intended?
--
Andriy Gapon
___
freebsd-hackers@freebsd.or
never tried it.
>>
>> Is there any advantage to using lsof instead of fstat(1) (fstat -p pid)?
>
> I believe that lsof reports on all open files by all processes,
> whereas fstat will only report on a specific provided pid.
Just try runnin
ou please enlighten me?
--
Andriy Gapon
___
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"
maybe I misunderstood your question and you talked about a different I/O
layer
or different I/O path.
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, sen
on 10/12/2010 16:48 Andriy Gapon said the following:
> But maybe I misunderstood your question and you talked about a different I/O
> layer
> or different I/O path.
>
Oh, probably you talk about physread/physwrite == physio.
Indeed, it issues bio-s with max size of si_iosize_max a
on 10/12/2010 16:45 Alexander Motin said the following:
> by default. Many SCSI drivers still limited by DFLTPHYS - 64K.
Including the cases where MAXBSIZE is abused because it historically has the
same
value.
--
Andriy Gapon
___
freebsd-hack
> I agree.
+1, just in case.
--
Andriy Gapon
___
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"
es on. I'll try to get one set up under
> VirtualBox later, but for now the patch is for 8-STABLE/amd64 only.
It would be nice to get the i386 counterpart too when this goes into the tree.
Thanks!
--
Andriy Gapon
___
freebsd-hackers@freebsd.or
on 21/12/2010 11:27 Artem Belevich said the following:
> On Tue, Dec 21, 2010 at 1:26 AM, Artem Belevich wrote:
>> On Mon, Dec 20, 2010 at 3:15 AM, Andriy Gapon wrote:
>>> It would be nice to get the i386 counterpart too when this goes into the
>>> tree.
>>
&
I agree.
I am going on vacation and I don't want to risk, so it looks like I will be able
to commit your patch after the holidays. Unless someone else beats me to it.
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freeb
d machdep.hlt_cpus and I assume
> the logical counterpart never be used with ULE?
--
Andriy Gapon
___
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"
sily fixed or not?
--
Andriy Gapon
___
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"
es that describe usable pages.
There is one vm_page_t structure per each 4KB page.
I believe that that memory is excluded from physmem.
--
Andriy Gapon
___
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 27/01/2011 07:43 Lawrence Stewart said the following:
> Hi Andriy,
>
> On 10/15/09 04:12, Andriy Gapon wrote:
>>
>> Some time ago I posted some ideas about HECI/MEI driver for FreeBSD:
>> http://docs.freebsd.org/cgi/mid.cgi?4968E9A1.3080006
>>
>> I act
ntal reasons for us to not support that configuration in
situations where hardware and BIOS (in x86 case) happen to support it?
I am personally more interested in non-uniform topologies like one package
having
two cores and another having four.
--
Andriy Gapon
etails: sdt_modevent ->
sdt_load -> sdt_provider_listall(sdt_provider_reg_callback) -> dtrace_register.
I am not saying that this behavior is correct/desired, just that this is what we
have now.
--
Andriy Gapon
___
freebsd-hackers@
uld be a subcase of the other
--
Andriy Gapon
___
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"
BootLoader
Please note that graphical loaders are not very serial console friendly ;-)
--
Andriy Gapon
___
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"
would have .4th files each of which would represent one extra
menu
option. So instead of hacking system .4th files, one could easily extend main
menu with custom entries.
Just a dream...
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing
s) from the same ports tree; support for multiple ports
sources.(when people maintain different ports tree (e.g. kde or gnome
development
ports tree)). Perhaps, with some compatibility/hierarchy support for packages
and
ports sources. But that's almost a pipe dream, so don't take it seriously :)
--
Andriy Gapon
___
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"
ckage name in addition to package metadata
could have certain benefits.
--
Andriy Gapon
___
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"
systems are, it's better
to
be slow and cautious.
All the ideas that I suggested were more for the "next step" than for now.
Thank you for the work!
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/m
suggestions.
P.S.
I see that Linux uses EROFS and ENOMEDIUM for these purposes.
I am not sure about EROFS in this role.
And we don't have ENOMEDIUM (nor EMEDIUMTYPE).
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebs
__
> From: owner-freebsd-hack...@freebsd.org [owner-freebsd-hack...@freebsd.org]
> On Behalf Of Warner Losh [i...@bsdimp.com]
> Sent: Friday, April 01, 2011 10:51 AM
> To: Andriy Gapon
> Cc: FreeBSD Hackers; FreeBSD Arch
> Subject: Re: looking for error codes
>
m. :)
This is just for your information:
http://thread.gmane.org/gmane.os.freebsd.current/127979/focus=128577
Maybe you'll find something useful there.
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/fre
on 01/04/2011 17:29 Andriy Gapon said the following:
>
> I am looking for error codes that would unambiguously signal that a disk
> drive has
> readonly or write-protected media and that disk drive has no media at the
> moment.
> I foresee these error codes being used m
ng back to R/O mount
--
Andriy Gapon
___
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 08/04/2011 03:00 Jeremy Chadwick said the following:
> On Thu, Apr 07, 2011 at 01:20:53PM -0700, Garrett Cooper wrote:
>> On Thu, Apr 7, 2011 at 10:25 AM, Andriy Gapon wrote:
>>>
>>> [sorry for double post, it should have been "hackers" not "hardware&q
t ENODEV anywhere under sys/ufs.
> Also, Tom Rhodes has a similar change to what I suggested on the
> backburner, but it hasn't been 100% fleshed out yet.
I like that approach too. It has its advantages.
But I don't give up yet on my suggestion.
--
Andriy Gapon
osed.
And, AFAIK, Linux does what I propose by default, without any additional
options.
Google for "block device ... is write-protected, mounting read-only".
But yes, it seems that they handle this situation entirely in userland.
And I am not against it.
--
Andriy Gapon
___
ime and don't need to be checked).
This is a very good idea, I would like to get that too, but it's a bit more work
than the "auto"-mounting.
--
Andriy Gapon
___
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"
here are many things that I don't know about...
--
Andriy Gapon
___
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"
You have to be familiar with assembly and know basic behavior of BIOS booting
(supposing we talk about x86) and FreeBSD boot blocks, e.g. what is loaded at
what address.
Here's an example of something related:
http://lists.freebsd.org/pipermail/freebsd-fs/2010-May/008580.htm
This is for your .vimrc.
Picked from some google search results.
" highlight too long lines
autocmd BufWinEnter *.c let w:m2=matchadd('ErrorMsg', '\%>80v.\+', -1)
autocmd BufWinLeave *.c call matchdelete(w:m2)
" permanently highlight 80th column
" set colorcolumn=80
" highlight trailing whitesp
ne knowledgeable in the area.
--
Andriy Gapon
___
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 16/04/2011 14:46 Andriy Gapon said the following:
>
> Guys,
>
> I am trying to debug this chromium issue:
> http://trillian.chruetertee.ch/chromium/ticket/13
> Not sure SOCK_SEQPACKET mentioned in the ticket is an actual culprit, the
> problem that interests me is t
on 16/04/2011 14:46 Andriy Gapon said the following:
> The second puzzle is the EPERM return value itself, on stable/8.
> From what I seem chromium does a bunch of forks before it gets to the place of
> interest. My debugging shows that those forks are "single-threaded"
on 17/04/2011 18:21 Daniel Eischen said the following:
> On Sun, 17 Apr 2011, Andriy Gapon wrote:
>
>> on 16/04/2011 14:46 Andriy Gapon said the following:
>>> The second puzzle is the EPERM return value itself, on stable/8.
>>> From what I seem chromium does a bu
it to have. If chromium build infrastructure circumvents that, it is
> only said build infrastructure to blame.
OK, I see, thank you.
Still inconvenient.
As in: if we know for a fact that "gcc ... -pthread -lc" results in a broken
binary, then IMO we should do something a
make sure that you compile your sources with -g in the first
> place? DWARF debug info is what CTF generation utils use to figure out
> types and function prototypes.
Also, dtrace process needs to access the module file for address-to-name
translati
on 22/04/2011 18:56 Chuck Tuffli said the following:
> On Fri, Apr 22, 2011 at 8:44 AM, Andriy Gapon wrote:
>> Also, dtrace process needs to access the module file for address-to-name
>> translation.
>
> Hmm ... I'm building this module out of tree. Where does dtr
Can a current thread panic or receive a trap while some other thread holds its
thread_lock (the same lock as pointed to by the td_lock)?
And a related question, can there be a reason for a thread in panic or kdb
context to try to get the thread_lock?
Thank you!
--
Andriy Gapon
be convenient.
--
Andriy Gapon
___
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"
seems like you could have an MBR that is reject by
code
in in 8. Have you tried to get a lit of devices that kernel sees at the
mountroot
prompt? What are those?
It could also be useful to boot from 8 or 9 live disk and examine how the system
sees your disks.
--
Andriy Gapon
_
hat. Symbol format `elf64-x86-64-freebsd' unknown.
>
This is a somewhat known issue that John was going to fix a while ago.
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ha
on 26/05/2011 16:33 John Baldwin said the following:
> On Thursday, May 26, 2011 3:37:13 am Andriy Gapon wrote:
>> on 26/05/2011 03:35 Raphael Kubo da Costa said the following:
>>> If I compile the port myself, I can't run any binary (PR ports/152896,
>>> whic
des that property (either via explicit testing or by making guesses based
on
CPU model or etc)
> Comments?
Perhaps I missed it, but I don't remember the "lowres" part of the patch being
discussed.
--
Andriy Gapon
___
freebsd-hackers@fr
on 31/05/2011 23:16 Jung-uk Kim said the following:
> On Tuesday 31 May 2011 07:18 am, Andriy Gapon wrote:
>> on 24/05/2011 20:56 Jung-uk Kim said the following:
>>> I think it's about time to enable invariant TSC timecounter on
>>> SMP by default. Please see
ughts?
I am still not sure which case this code should solve.
Thread T1: x1 = rdtsc() on CPU1;
Thread T1: x2 = rdtsc() on CPU2;
x2 < x1 ?
Or?
--
Andriy Gapon
___
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 03/06/2011 14:50 John Baldwin said the following:
> On Friday, June 03, 2011 2:03:55 am Andriy Gapon wrote:
>>> Consecutive RDTSCs used on a same CPU is always incremental but we
>>> cannot 100% guarantee that on two cores, even if TSC is derived from
>>> the sam
o accurately measure it with
> current generation hardware.
Yeah, quite unfortunate.
--
Andriy Gapon
___
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"
dit` where it fails every other save. There are no issues with
> `echo 'hi' >> test` as there is no O_TRUNC, it only seems to be an O_TRUNC
> error.
>
> Any tips? Otherwise I'll be looking into this today myself.
Just a hint that you could try using DTrace s
on 19/07/2011 03:19 Brandon Falk said the following:
> On 7/18/2011 10:18 AM, Andriy Gapon wrote:
>> on 18/07/2011 17:53 Brandon Falk said the following:
>>> Hello,
>>>
>>> In recent branches (confirmed with 224119) builds compiled with clang
>>> happe
on 20/07/2011 15:34 Julian H. Stacey said the following:
> Even if we're too lazy to do anything more, we should at least
> document it as a patch to man gcc.
Talk to GCC people now?
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailin
ters (general-purpose and fixed-function counters) and their
companion control MSRs are duplicated for each logical processor.
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hacker
what's reported by the hardware, e.g.:
# pciconf -r pci0:0:24:3 0xa4
1c881880
You can read the BKDG to see how to interpret the value - search for F3xA4. See
F3xE4 for offset calculation.
Hopefully you should be able to see if hardware reports sane value and how the
amdtemp ends up reporting 0°C.
--
Andriy Gapon
___
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"
inally, I promise to test this patch soon-ish.
Thank you for digging into this!
--
Andriy Gapon
___
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 01/08/2011 22:48 Jung-uk Kim said the following:
> amdtemp(4) attaches under PCI bus but its sibling on function 2 isn't
> easy to address, i.e., hostbN.
pci_find_bsf() should help with that.
--
Andriy Gapon
___
freebsd-hackers@freebsd.
muse users
with numbers, let's just print a warning :-)
--
Andriy Gapon
___
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 02/08/2011 00:08 Jung-uk Kim said the following:
> On Monday 01 August 2011 04:07 pm, Andriy Gapon wrote:
>> on 01/08/2011 22:48 Jung-uk Kim said the following:
>>> amdtemp(4) attaches under PCI bus but its sibling on function 2
>>> isn't easy to address,
0x00406b2c in main (argc=3, argv=0x7ffed9c0)
> at
> /usr/src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/cmd/dtrace/dtrace.c:1825
> ...
%s, %p, %p) error"
> " %d\n", data->name, (void *)data->evhand, data->priv,
> error);
> + linker_release_module(NULL, NULL, lf);
> } else {
> MOD_XLOCK;
> if
3 ada1p2 ada1p1 gptid/81652d6f-94ff-11e0-afed-6cf049b01360
> gpt/disk0 gptid/815afb70-94ff-11e0-afed-6cf049b01360 gpt/swap0
> gptid/81543d17-94ff-11e0-afed-6cf049b01360 ada3 ada2 ada1 ada0p3 ada0p2
> ada0p1
> ada0 cd0
>
> but I don't see any zfs,
>
> any help/i
ad). Running head now with
> a dtrace enabled kernel.
>
> Suggestions?
On head, start with checking what source is used for driving clocks:
sysctl kern.eventtimer
When the problem starts using vmstat -i to check interrupt rates and see if any
relevant counter gets stuck.
--
Andriy Gapo
addresses from faults on garbage kernel addresses. I
am sure that there could be other clever techniques to catch such garbage
addresses early.
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/fre
on 18/08/2011 02:15 Steven Hartland said the following:
> - Original Message - From: "Andriy Gapon"
>
>> Thanks to the debug that Steven provided and to the help that I received from
>> Kostik, I think that now I understand the basic mechanics of this panic
on 18/08/2011 13:35 Steven Hartland said the following:
> - Original Message - From: "Andriy Gapon"
>>> Thats interesting, are you using http as an example or is that something
>>> thats
>>> been gleaned from the debugging of our output? I ask as t
on 18/08/2011 14:11 Andriy Gapon said the following:
> Probably I have mistakenly assumed that the 'prison' in prison_derefer() has
> something to do with an actual jail, while it could have been just prison0
> where
> all non-jailed processes belong.
So, indeed:
(kgdb) p
on 17/08/2011 23:21 Andriy Gapon said the following:
It seems like everything starts with some kind of a race between terminating
processes in a jail and termination of the jail itself. This is where the
details are very thin so far. What we see is that a process (http) is in
exit(2) syscall
:
>
> # Do a backtrace given %eip and %ebp as args
> define bt
> set $_eip = $arg0
> set $_ebp = $arg1
> set $i = 0
> while ($_ebp != 0 || $_eip != 0)
> printf "%2d: pc ", $i
> if ($_eip != 0)
> x/1i $_eip
>
on 02/08/2011 00:06 Jung-uk Kim said the following:
> On Monday 01 August 2011 04:10 pm, Andriy Gapon wrote:
>> on 01/08/2011 22:48 Jung-uk Kim said the following:
>>> I have mixed feeling about this because I own a system with such
>>> CPU/motherboard combo, too. I als
ght thing auto-magically, we should try
to
make the calling code check panicstr and kdb_active and do the right thing on
that
level (which would include not invoking those lock-related operations or other
inappropriate operations).
Thank you very much in advance for your insights
r so minutes
> before displaying the copyright banner).
Not sure if hw.memtest.tests tunable has made it into 9.0-BETA1.
Setting it to zero should result in skipping the checks.
You may also try to capture and share a verbose dmesg, if possible.
--
Andriy Gapon
_
on 29/08/2011 18:18 Ivan Voras said the following:
> On 29 August 2011 17:15, Andriy Gapon wrote:
>> on 29/08/2011 17:46 Ivan Voras said the following:
>>> On 26/08/2011 19:44, Garrett Cooper wrote:
>>>> On Fri, Aug 26, 2011 at 10:36 AM, Ivan Voras wrote:
>>
:04, Brandon Gooch wrote:
>> I'm guessing you've read this:
>>
>> http://wiki.freebsd.org/DTrace
>>
>> Make certain you've configure your kernel correctly, and that you've
>> rebuilt your kernel and modules...
>>
>> -Brandon
>
Anybody uses topgit for FreeBSD or FreeBSD related development?
What's your impressions of it?
Any peculiarities in the workflow?
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hacke
e with the wider audience e.g. via hackers@.
P.S. This code sharing is made easier for me by git, Gitorious and "git rebase
--onto" in particular. Thanks to Fabien Thomas for the initial FreeBSD clone
repository at Gitorious!
--
Andriy Gapon
___
s to the
tree. topgit implements that idea by having a separate branch for each
(developer defined) change and by stacking those branches on top of each other
to get the tree that has all the dependent changes.
--
Andriy Gapon
___
freebsd-hackers@fr
on 19/09/2011 10:41 Andriy Gapon said the following:
> on 19/09/2011 01:25 Gleb Kurtsou said the following:
>> Let me share my experience as well.
>>
>> My repo: https://github.com/glk/freebsd-head/
>>
>> I used rebase to keep local branches as well, but no longe
during idle period we accumulate enough timer ticks and then run all those
ticks very rapidly, then the SW_WATCHDOG code may get an impression that it was
not patted for many real ticks.
Not sure what would be the best way to make SW_WATCHDOG happier/smarter.
--
Andriy Gapon
on 20/09/2011 23:04 Alexander Motin said the following:
> Hi.
>
> On 20.09.2011 22:19, Andriy Gapon wrote:
>> just want to check with you first if the following makes sense.
>> I use SW_WATCHDOG on one of the test machines, which was recently updated to
>> from stable/
ith KTR_SPARE2 ktrace enabled should help to collect
> valuable info about timers behavior before the crash.
I will try to debug this further using your suggestion.
Thank you!
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.free
MODDIR does (in bsd.own.mk).
--
Andriy Gapon
___
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 RB_DELETE crash!
>
> Any hints how to debug such strange situation?
A trivial check first - does the element on which you call RB_DELETE actually
belong to the tree in question?
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
h
1 - 100 of 614 matches
Mail list logo
