gate_units[unit]->sc_provider still null and releases g_gate_units_lock.
2) Thread B traverses g_gate_units[] when checking for name collision and
craches accessing g_gate_units[unit]->sc_provider->name.
The attached patch fixes the issue in my case.
--
Mikolaj Golub
ggioc
On Sun, 27 Mar 2011 15:16:15 +0300 Mikolaj Golub wrote to Freddie Cash:
MG> The attached patch fixes the issue in my case.
The patch is committed to current.
--
Mikolaj Golub
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.
F> likely to hit this bug. Are the processes stable once launched ?
Yes, you may hit it only on hast devices creation. The workaround is to avoid
using 'hastctl role primary all', start providers one by one instead.
--
Mikolaj Golub
___
start -- switch node to primary (iscsi up, IP up, etc);
stop -- switch node to secondary;
status -- return current status (0 - UP, 1 - DOWN, 2 - UNKNOWN).
You can find more information in README:
http://code.google.com/p/hastmon/wiki/README
--
Mikolaj Golub
_
rent problem. If you have this again please provide the
output of 'procstat -kka'.
--
Mikolaj Golub
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
at -z how
VBD> g_bio increases and never releases memory.
VBD> I just destroy the current bio before returning and that prevents the
memory leak.
For me your patch look correct. But the same issue is for read :-). Also, to
avoid the le
On Sat, 2 Apr 2011 12:17:50 +0200 Pawel Jakub Dawidek wrote:
PJD> On Sat, Apr 02, 2011 at 12:04:09AM +0300, Mikolaj Golub wrote:
>> For me your patch look correct. But the same issue is for read :-). Also, to
>> avoid the leak I think we can just do g_destroy_bio() befo
On Mon, 4 Apr 2011 01:51:24 +0200 Victor Balada Diaz wrote:
VBD> On Sun, Apr 03, 2011 at 08:43:45PM +0300, Mikolaj Golub wrote:
>>
>> On Sat, 2 Apr 2011 12:17:50 +0200 Pawel Jakub Dawidek wrote:
>>
>> PJD> On Sat, Apr 02, 2011 at 12:04:09AM +0300, Mikolaj Go
;> still have any issues?
FC> Just to confirm, this is commit r220264, 220265, 220266 to -CURRENT?
Yes, r220264 and 220266. As it is stated in the commit log MFC is planned
after 1 week.
--
Mikolaj Golub
___
freebsd-stable@freebsd.org mailing
On Mon, 4 Apr 2011 11:08:16 -0700 Freddie Cash wrote:
FC> Once the deadlock patches above are MFC'd to -STABLE, I can do an
FC> upgrade cycle and test them.
Committed to STABLE.
--
Mikolaj Golub
___
freebsd-stable@freebsd.org mailin
On Sun, 03 Apr 2011 20:43:45 +0300 Mikolaj Golub wrote to Pawel Jakub Dawidek:
MG> On Sat, 2 Apr 2011 12:17:50 +0200 Pawel Jakub Dawidek wrote:
PJD>> On Sat, Apr 02, 2011 at 12:04:09AM +0300, Mikolaj Golub wrote:
>>> For me your patch look correct. But the same issue is
On Mon, 11 Apr 2011 11:26:15 -0700 Freddie Cash wrote:
FC> On Sun, Apr 10, 2011 at 12:36 PM, Mikolaj Golub
wrote:
>> On Mon, 4 Apr 2011 11:08:16 -0700 Freddie Cash wrote:
>> FC> Once the deadlock patches above are MFC'd to -STABLE, I can do an
>> FC
thout OpenSSL and is just insufficiently
MDF> tested, or whether it really just flat needs OpenSSL and the
MDF> conditionalization is vestigial, I don't know. pjd@ cc'd.
The attached patch should fix this.
--
Mikolaj Golub
Index: sbin/hastd/hast_proto.c
==
On Tue, 26 Apr 2011 18:25:09 +0200 Pawel Jakub Dawidek wrote:
PJD> On Tue, Apr 26, 2011 at 12:44:31PM +0300, Mikolaj Golub wrote:
>>
>> On Sat, 23 Apr 2011 09:38:39 -0500 Matthew D. Fuller wrote:
>>
>> MDF> On Sat, Apr 23, 2011 at 05:52:47AM -0700 I heard
On Wed, 27 Apr 2011 14:05:11 +0200 Denny Schierz wrote:
DS> hi,
DS> Am Dienstag, den 29.03.2011, 23:36 +0300 schrieb Mikolaj Golub:
>>
>> 2) There are complaints from watchdog.
DS> what happens, if the watchdog isn't available and one or both nodes are
DS>
e with highest priority will win.
3) One node that has highest priority configures is set on startup always to
primary. All others are to secondary.
With this configuration if the primary fails, secondary switches to primary,
then when the initial primary comes back it becomes primary again
automatically.
--
Mikolaj Golub
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
ized time).
Also, it might worth checking that there is no network packet corruption (some
strange things in netstat -di, netstat -s, may be copying large files via net
and comparing checksums).
--
Mikolaj Golub
___
freebsd-stable@freebsd.org mai
served, running netstat in loop, something
like below:
while sleep 5; do
t=`date '+%F %H:%M:%S'`;
netstat -na | grep 8457 |
while read l; do
echo "$t $l";
done;
done > /tmp/netstat.log
--
Mikolaj Golub
___
freebs
On Tue, 31 May 2011 15:51:07 +0300 Daniel Kalchev wrote:
DK> On 30.05.11 21:42, Mikolaj Golub wrote:
>> DK> One strange thing is that there is never established TCP connection
>> DK> between both nodes:
>>
>> DK> tcp4 0 0 10.
http://people.freebsd.org/~trociny/uipc_socket.c.patch
The patch was committed to current (r222454) and is going to be MFCed after
some time.
--
Mikolaj Golub
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-s
) -- this
should make secondary notice that another end is dead after this interval.
--
Mikolaj Golub
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
this state for over 10 minutes.
DK> Unfortunately, no KDB in kernel. Any ideas what other to look for?
Could you please try this patch?
http://people.freebsd.org/~trociny/hastd.no_shutdown.patch
After patching you need to rebuild hastd and restart it (I expect only on
secondary is enough
On Fri, 10 Jun 2011 20:05:43 +0300 Mikolaj Golub wrote to Daniel Kalchev:
MG> Could you please try this patch?
MG> http://people.freebsd.org/~trociny/hastd.no_shutdown.patch
Sure you still have to have your kernel patched with uipc_socket.c.patch :-)
--
Mikolaj
On Tue, 14 Jun 2011 16:39:11 +0300 Daniel Kalchev wrote:
DK> On 10.06.11 20:07, Mikolaj Golub wrote:
>> On Fri, 10 Jun 2011 20:05:43 +0300 Mikolaj Golub wrote to Daniel Kalchev:
>>
>> MG> Could you please try this patch?
>>
>> MG&
TS> thanks!
TS> ___
TS> freebsd-stable@freebsd.org mailing list
TS> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
TS> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
--
Mikolaj G
primary before the synchronization is
complete -- it will continue in right direction, but then you should expect
performance degradation until the synchronization is complete -- the READ
requests will go to remote node. So it might be better to wait until the
synchronization is complete before sw
abase ordeal is long over with/fixed/whatever?
>> It isn't[2].
>>
>> [1]:
>> http://lists.freebsd.org/pipermail/freebsd-stable/2011-June/063052.html
>> [2]:
>> http://www.dslreports.com/for
#x27;t close the fd
-- we still want to read from it. Poor shutdown(2) for non-socket :-).
Colin might tell more...
--
Mikolaj Golub
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscrib
On Sun, 18 Sep 2011 20:24:23 +0300 Kostik Belousov wrote:
KB> On Sun, Sep 18, 2011 at 02:54:34PM +0300, Mikolaj Golub wrote:
>>
>> On Sun, 18 Sep 2011 13:25:26 +0200 Ronald Klop wrote:
>>
>> RK> It is a while since I programmed C, but why will writing 0 byt
On Sun, Sep 18, 2011 at 1:58 PM, Mikolaj Golub wrote:
>
> On Sun, 18 Sep 2011 08:47:13 +0200 Ronald Klop wrote:
>
> RK> On Sun, 18 Sep 2011 07:39:01 +0200, Jeremy Chadwick
> RK> wrote:
>
> >> On Sun, Sep 18, 2011 at 12:54:13AM -0400, Jason Hellenthal wrote:
On Tue, 04 Oct 2011 18:34:07 +0200 Michiel Boland wrote:
MB> On 10/04/2011 13:15, Mikolaj Golub wrote:
>> On Sun, Sep 18, 2011 at 1:58 PM, Mikolaj Golub wrote:
MB> [...]
>>>
>>> I believe the behaviour is after this commit:
>>>
>>> http:
ime > 0 it
keeps sending VEOF. That is why you are observing series of ^D\b\b characters.
I am going to commit the attached patch to HEAD, that fixes this. But we will
still have one ^D\b\b in the output.
--
Mikolaj Golub
Index: usr.bin/script/script.c
=
may be best to remove writing EOF characters, perhaps adding an
JT> option to enable it again if there is a concrete use case for it.
Without passing EOF to the to the program being scripted the following command
will hang forever:
echo 1 |script /tmp/script.out cat
--
Mikolaj Golub
creates.
What's worse is that the upgrade never completes.
SB> You can easily see this for yourself:
SB> # portupgrade -a --batch This is on 8-stable from October 5th.
Could you please try the patch I attached to another my mail in this thread to
see if it helps?
On Sat, 15 Oct 2011 11:50:22 +0200 Stefan Bethke wrote:
SB> Am 15.10.2011 um 09:36 schrieb Mikolaj Golub:
>>
>> On Fri, 14 Oct 2011 22:50:32 +0200 Stefan Bethke wrote:
>>
>> SB> I finally figured out why my ports aren't updating anymore: when
>>
mode, for syncronization requests, write_complete() function,
which sends G_GATE_CMD_DONE command to ggate, is called twice and the second
call fails.
Artem, did you run async mode? If you did then I suppose you observed the
second issue. Could you please try the attached patch?
--
Mikolaj Gol
f the error still exists.
KERN_PROC_ENV is declared in sys/sys/sysctl.h, and this was MFCed in r230754,
before the MFC lib/libkvm (r230780) you are referring to.
--
Mikolaj Golub
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/
On Sun, 5 Feb 2012 10:27:54 +0100 Pawel Jakub Dawidek wrote:
PJD> The analysis and fixes look good to me, please go ahead and commit
PJD> (small nits below).
Thanks. Committed.
--
Mikolaj Golub
___
freebsd-stable@freebsd.org mailing lis
=/dev/zvol/zfs/hvol bs=131072 | ssh h2 dd bs=131072 of=/dev/zvol/zfs/hvol
(copy hvol from h1 to h2 without hastd to see if it will succeed).
Note: you will need to recreate HAST provider on secondary after this.
--
Mikolaj Golub
___
freebsd-stabl
but
it would be good to check. Could you please start synchronization again,
ktrace primary worker process when ENOMEM errors are observed and show output
here?
If it is send(2) who fails then monitoring netstat and network driver
statistics might be helpful. Something like
netstat -nax
nets
On Tue, 13 Mar 2012 00:22:23 +0100 Phil Regnauld wrote:
PR> Mikolaj Golub (to.my.trociny) writes:
>>
>> It looks like in the case of hastd this was send(2) who returned ENOMEM, but
>> it would be good to check. Could you please start synchronization again,
>> kt
R> dev.bce.0.stat_Dot3StatsAlignmentErrors: 0
What about failed counters like mbuf_alloc_failed_count,
dma_map_addr_rx_failed_count, dma_map_addr_tx_failed_count?
--
Mikolaj Golub
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/fr
uccessfully.
You sent SIGHUP to master process and on both hosts, didn't you?
Could you please provide more details if you still fail to add new resources
on the fly (configuration, log messages).
--
Mikolaj Golub
___
freebsd-stable@freebsd.org m
st print the
JH> orrelease as (0) and print the rest of the information that should be
JH> seen...
JH> Could someone have a closer look at this?
JH> On Fri, Apr 06, 2012 at 04:32:29PM +, Mikolaj Golub wrote:
>> Author: trociny
>> Date: Fri Apr 6 16:32:29 2012
t looks like the issue that has been fixed in STABLE.
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/144330
--
Mikolaj Golub
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send
The strightforward solution looks like to implement null_remove() that will
increase lower vnode's refcount before calling null_bypass() and then
decrement it after the call. See the attached patch (it works for me on both
8-STABLE and CURRENT).
--
Mikolaj Golub
On Sat, 12 Jun 2010 11:56:10 +0300 Mikolaj Golub wrote to Leon Meßner:
MG> See the attached patch (it works for me on both 8-STABLE and CURRENT).
Sorry, actually here is the patch.
--
Mikolaj Golub
Index: sys/fs/nullfs/null_vnop
ses (like some issues with hooks or a race that
showed up when changing HAST role in loop -- you would never do this in
production). And fixes were committed in several days after a report. I don't
know any open issue.
--
Mikolaj Golub
___
fr
;revision=211452
I wonder couldn't slow synchronization with MAX_SEND_SIZE=131072 be due to
SO_SNDBUF/SO_RCVBUF be equal to this size? May be increasing
SO_SNDBUF/SO_RCVBUF we could reach better performance with
MAX_SEND_SIZE=128kB?
--
Mikolaj Golub
done
Also tcpdump may help :-)
--
Mikolaj Golub
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
p(1) in hast_proto_send() between proto_send(header) and
proto_send(data). The error started to occur frequently.
--
Mikolaj Golub
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any
On Thu, 28 Oct 2010 18:30:36 +0200 Pawel Jakub Dawidek wrote:
PJD> On Wed, Oct 27, 2010 at 10:05:20PM +0300, Mikolaj Golub wrote:
>> In hast_proto_send() we send header and then data. Couldn't it be that
>> remote_send and sync threads interfere and their packets are mix
On Thu, 28 Oct 2010 22:08:54 +0300 Mikolaj Golub wrote to Pawel Jakub Dawidek:
PJD>> I looked at the code and the keepalive packets arbe sent from another
PJD>> thread. Could you try turning them off in primary.c and see if that
PJD>> helps?
MG> At first I set RETRY_S
access to my test instances and will report about the results.
--
Mikolaj Golub
Index: sbin/hastd/primary.c
===
--- sbin/hastd/primary.c (revision 214624)
+++ sbin/hastd/primary.c (working copy)
@@ -180,14 +180,20 @@ static pthread_mute
On Mon, 01 Nov 2010 17:06:49 +0200 Mikolaj Golub wrote:
MG> On Mon, 1 Nov 2010 12:01:00 +0100 Pawel Jakub Dawidek wrote:
PJD>> I like your patch and I agree of course it is better to send keepalive
PJD>> packets only when connection is idle. The only thing I'd change
th machdep.hlt_logical_cpus=1 that in C
column of top output there appear CPU numbers for CPUs that are actually
halted according to vmstat -i and I am curious too what this means.
--
Mikolaj Golub
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
(execute)
\
- }
\
+ { \
__pthread_cleanup_pop_imp(execute);
\
}
--
On Tue, 24 Nov 2009 16:53:35 +0200 Mikolaj Golub wrote:
> Hi,
>
> I have problems with compiling our application under 8.0.
>
> It fails due to these definitions in pthread.h that look like a typo or
> incorrectly applied patch:
>
> 170 #define pthread_clea
ur change is wrong.
>
> Basically, the code should do
> pthread_cleanup_push(some_func, arh);
> something ...
> pthread_cleanup_pop(1);
> (1 denotes that some_func should be called).
I see. Thank you. So it really looks like a bug in our application as
pthread_clea
d26 in jailed (cred=0x0) at /usr/src/sys/kern/kern_jail.c:465
465 {
(kgdb) list
460 /*
461 * Return 1 if the passed credential is in a jail, otherwise 0.
462 */
463 int
464 jailed(struct ucred *cred)
465 {
466
467 return (cred->cr_prison != NULL);
468 }
ooted to the kernel
without quota. To check the hardware is in our plans. Thank you.
--
Mikolaj Golub
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
On Wed, 9 Dec 2009 15:52:23 -0600 Mike Pritchard wrote:
> On Mon, Dec 07, 2009 at 10:23:49AM +0200, Mikolaj Golub wrote:
>> On Sun, 6 Dec 2009 20:18:13 +0200 Kostik Belousov wrote:
>>
>> > The kernel paniced because chkdq was supplied NULL credentials and
>> > _
privately if someone from developers is interested
to look at it.
We have removed all NFS shares from this server after the last incident, but
we have other servers where the problem might occur too. So any suggestions
what we should check/do then to provide more info could be helpful.
--
Mik
= 0xda888e94}}, b_pages =
{0xc3726e90, 0xc448dca8,
0xc2a55b98, 0xc3bf1a28, 0xc3467ff0, 0xc3299600, 0xc28db130, 0xc2301398, 0x0
},
b_npages = 8, b_dep = {lh_first = 0x0}, b_fsprivate1 = 0x0, b_fsprivate2 =
0x0, b_fsprivate3 = 0x0,
b_pin_count = 0}
These are entires from our log file. Note that b_qindex is 0. But
bufqueues[0] is empty:
(kgdb) p bufqueues[0]
$8 = {tqh_first = 0x0, tqh_last = 0xc0c83e20}
Also does not it look strange that lk_lockholder of b_lock points to
innvalid location (0xfffe)?
--
Mikolaj Golub
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
On Tue, 19 Jan 2010 10:02:57 +0200 Mikolaj Golub wrote:
> I have found in the Internet that other people have been observed the similar
> problem with FreeBSD6.2 client:
>
> http://forums.freebsd.org/showthread.php?t=1697
Reading this through carefully it looks like the guy did no
On Tue, 19 Jan 2010 10:02:57 +0200 Mikolaj Golub wrote:
> So, on some of our freebsd7.1 nfs clients (and it looks like we have had
> similar case with 6.3), which have several nfs mounts to the same CentOS 5.3
> NFS server (mount options: rw,-3,-T,-s,-i,-r=32768,-w=32768,-o=noinet6),
ts simultaneously, set the scripts in cron that just periodically write a
line to the file on nfs share (to "unlock" it if it is locked). We have not
been observed problems since then and we would not like to experiment in
production. If I manage to produce good test case in test enviro
op.core
core file is useless without binary and libraries. So it is better to run gdb
on your host, produce backtrace and post here:
gdb /usr/bin/top top.core
bt
And sure a backtrace from the top built with -g would be much better.
cd /usr/src/usr.bin/top
CFLAGS=-g make
407a10 in main (argc=1, argv=0x7fffeb08)
> at /usr/src/usr.bin/top/../../contrib/top/top.c:458
>
> I'm using nss_ldapd-0.7.2 and there's no way to live without ldap...
--
Mikolaj Golub
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
omeone else can test and/or
> review it... rick
I applied your patch to FreeBSD8.0 (the box I get on weekend :-), mounted 10
shares, set vfs.nfs.iodmaxidle=10 (to have nfsiod creation more frequently)
and have been running tests for 4 hours -- just to check the patch does not
break anything. No i
t know is how bsdnmp-ucb retrives
> those values and how it construct the udp response packet.
bsnmpd-ucd has nothing to do with HOST-RESOURCES-MIB. These mibs are provided
by snmp_hostres(3) module (/usr/lib/snmp_hostres.so). So something wrong is
there (I suppose it is not in sync with so
at SUPDrv.c:2307
2307paPages[iPage] = RTR0MemObjGetPagePhysAddr(Mem.MemObj,
iPage);
(kgdb) p Mem.MemObj.enmType
$1 = RTR0MEMOBJTYPE_LOCK
So, it looks like some additional handling should be added for this case...
--
Mikolaj Golub
___
freebsd-s
7.1 hosts in production and I observe nonzero values on 8
hosts (about 15%). I would send more details to you privately if you are
interested.
--
Mikolaj Golub
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freeb
se-kmod && make patch
applied this patch and your previous patch ("Patch to fix VirtualBox with
recent kernel versions")
built and reinstall
the same for emulators/virtualbox-ose
3) rebooted and started vm guest
virtualbox-ose-3.1.2_1 A
prefer normal dumps (with
output of ddb scripts in capture buffer) to textdumps. You can't debug
textdump and crashinfo will fail too. And all info provided in textdump is
retrieved from vmcore capture buffer by crashifo utility automatically.
--
Mikolaj Golub
___
g reveals 'sysctl dev.uart' to be what triggers it.
kern/143040 looks similar.
--
Mikolaj Golub
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
em0: Watchdog timeout -- resetting" issue. My
previous kernel was for Mar 12.
Tracking the revision where the problem appeared I see that the issue is not
observed for r203834 and starts to observe after r205869.
Interestingly, if I enter ddb and then exit (sometimes I needed to do this
On Sun, 11 Apr 2010 23:40:03 +0300 Mikolaj Golub wrote:
MG> Hi,
MG> Today I have upgraded the kernel in my VirtualBox (3.1.51.r27187) to the
MG> latest current and have "em0: Watchdog timeout -- resetting" issue. My
MG> previous kernel was for Mar 12.
MG> Tracki
On Wed, 14 Apr 2010 09:28:33 -0700 Jack Vogel wrote:
> Oh, didn't realize you were running the lem code :) Will make the changes
> shortly,
r206614 works for me. Thanks :-)
> thanks for your debugging efforts.
>
> Jack
--
Mikolaj Golub
___
o? If you do then what version is it?
In bsnmp-ucd-0.3.5 I introduced a bug that lead to bsnmpd crash on a
disk detach. It has been fixed (thanks to Brian Somers) in 0.3.6.
--
Mikolaj Golub
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd
On Mon, Sep 10, 2012 at 04:46:15PM +0200, Miroslav Lachman wrote:
> Mikolaj Golub wrote:
> > On Sun, Sep 09, 2012 at 11:56:55PM +0200, Miroslav Lachman wrote:
> >> I am running bsnmpd with basic snmpd.config (only community and location
> >> changed).
> >>
>
/src/usr.sbin/bsnmpd/modules/snmp_hostres clean all
install
AFAIK it might work or not. If it does not then wait for another crash :-)
--
Mikolaj Golub
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
T
m /usr/lib/snmp_mibII.so
> #38 0x in ?? ()
> #39 0x7fffc5cc in ?? ()
> #40 0x0001 in ?? ()
> #41 0x7fffc5e0 in ?? ()
> #42 0x31fa39e2fac72819 in ?? ()
> #43 0x0001 in ?? ()
> #44 0x00080065fad5 in poll_dispatch () from /lib/li
d uses device_map differently, so it is not affected.
--
Mikolaj Golub
Index: usr.sbin/bsnmpd/modules/snmp_hostres/hostres_diskstorage_tbl.c
===
--- usr.sbin/bsnmpd/modules/snmp_hostres/hostres_diskstorage_tbl.c (revision 240529)
+
On Sun, Sep 16, 2012 at 05:56:22PM +0400, Andrey V. Elsukov wrote:
> On 15.09.2012 16:50, Mikolaj Golub wrote:
> > I am attaching the patch that fixes the issue for me.
> >
> > I was wandering why the issue was not observed after md device
> > removal, as disk_OS_
. I am going to MFC it.
--
Mikolaj Golub
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Sorry, the message went privately to Daisuke, which was not my intention.
-- Forwarded message --
From: Mikolaj Golub
Date: Mon, Nov 26, 2012 at 9:38 AM
Subject: Re: hastctl hang
To: Daisuke Aoyama
On Mon, Nov 26, 2012 at 01:17:46AM +0900, Daisuke Aoyama wrote:
> He
it ok that now we have "new" operators being
still called via libstdc++ while "delete" operators being called
directly from libsupc++?
If it is ok, is the proposed solution with adding redirects for
libsupc++ is a right way to fix the valgrind?
--
Mikolaj Golub
On Sun, Jan 20, 2013 at 02:19:55PM +0200, Mikolaj Golub wrote:
> Hi,
>
> Some time ago I noticed that valgrind started to complain about
> "Mismatched free() / delete / delete []" for valid new/delete
> combinations.
>
> For example, the followi
xpect replacing pf with ipfw_nat or natd will give better
results.
If you still prefer pf, you may try destroying epair interface before
destroying vnet, e.g. using prestop rc.d/jail hooks instead of
poststop, if it is possible.
--
Mikolaj Golub
___
freebsd-s
eb_exec_poststop1="ifconfig epair4a destroy"
The crash happened when executing ifconfig epair destroy.
You might want to try running commands manually before using the rc
script.
--
Mikolaj Golub
___
freebsd-stable@freebsd.org mailing l
ot important in your case).
--
Mikolaj Golub
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
> *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru ***
>
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@f
e scripts
> > which try and parse the outut from 'status' which will need changing,
> > and I sspect I am not the only one...
>
> I see no problem with this, as it is one-lite patch (modulo usage/manual page
> changes); it would be direct commit to -st
ere rock solid under 8, and the only chnage I can see with 9 is
> > the trim support being added.
Another important change that comes to mind is the default replication
mode, changed from fullsync to memsync. Do you have the replication
mode explicitly set in your config?
--
Mikolaj Golub
___
e request failed" errors from your logs. Do you
have "Local request failed" errors too?
--
Mikolaj Golub
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
On Fri, Oct 11, 2013 at 01:42:39PM +0300, Mikolaj Golub wrote:
> You showed only "Remote request failed" errors from your logs. Do you
> have "Local request failed" errors too?
You should also see them in "local errors" statistics from `hast
ot; or "call doadump" and after reboot:
ddb capture -M /var/crash/vmcore.X print > out
I would recommend to increase debug.ddb.capture.bufsize sysctl variable to be
sure all the ddb session will be captured.
--
Mikolaj Golub
___
freebsd-
ot help.
It looks like related to this report:
http://www.freebsd.org/cgi/getmsg.cgi?fetch=1253844+1263253+/usr/local/www/db/text/2009/freebsd-bugs/20090322.freebsd-bugs
--
Mikolaj Golub
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd
t
/usr/src/sys/i386/i386/exception.s:255
MT> #13 0x0033 in ?? ()
MT> Previous frame inner to this frame (corrupt stack?)
MT> (kgdb)
Just FYI, the same problem has already been registered in pr database as
kern/132734.
--
Mikolaj Golub
1 - 100 of 111 matches
Mail list logo
