/lib32")
lm_fini("1, libc-client4.so.9" lml-Adresse 0x2826c168)
lm_fini("f=libcrypto.so.8, t=libcrypto.so.6")
lm_fini("f=libssl.so.8, t=libssl.so.6")
lm_fini("2, /usr/local/php52/" lml-Adresse 0x2826c068)
lm_fini("f=/usr/
/usr/local/lib/mysql, t=/usr/local/lib32/mysql")
lm_fini("f=/usr/local/lib, t=/usr/local/lib32")
So for $DEFAULTS we have a lot of identical entries. This comes from the
TAILQ_INSERT_HEAD statement in lm_add(). I am not sure if this can be
accep
rary: [librt.so.1]
0x0001 (NEEDED) Shared library: [libm.so.5]
0x0001 (NEEDED) Shared library: [libxml2.so.5]
0x0001 (NEEDED) Shared library: [libz.so.5]
0x0001 (NEEDED)
hing for \"%s\"", name);
@@ -2831,7 +2833,7 @@
char *res;
len = strcspn(path, ":;");
- trans = lm_findn(NULL, path, len);
+ trans = lm_findn(save_refobj_path, path, len);
if (trans)
res = callback(trans, strlen(trans), arg);
Konstantin Belousov wrote:
> On Mon, Jul 08, 2013 at 12:26:43AM +0200, Andreas Longwitz wrote:
>> The deadlock can be explained now: pid 1 (init) sleeps on "mount drain"
>> because mp->mnt_lockref was 1. This setting was done by pid 18 (gjournal
>> switcher)
was 1. This setting was done by pid 18 (gjournal
switcher) by calling vfs_busy(). pid 18 now sleeps on "suspwt" because
mp->mnt_writeopcount was 1. This setting was done by pid 1 before going
to sleep by calling vn_start_write() in dounmount().
I think the reason for this deadlock is t
s_snapshot.c
> +++ b/sys/ufs/ffs/ffs_snapshot.c
> @@ -687,8 +687,7 @@ out1:
> /*
>* Resume operation on filesystem.
>*/
> - vfs_write_resume(vp->v_mount);
> - vn_start_write(NULL, &wrtmp, V_WAIT);
> + vfs_write_resume_flags(vp->v_mount, VR_START_WRITE);
> if (collectsnapstats && starttime.tv_sec > 0) {
> nanotime(&endtime);
> timespecsub(&endtime, &starttime);
Your patch adjusted to FreeBSD Stable 8 works fine. Creating a snapshot
every minute runs without errors for more than 6 hours now, without the
patch my test machine hangs not later than one hour.
--
Andreas Longwitz
___
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"
Konstantin Belousov wrote:
>>> On Thu, Dec 27, 2012 at 12:28:54PM +0100, Andreas Longwitz wrote:
>> db> alltrace (pid 18 and 7126)
>>
>> Tracing command g_journal switcher pid 18 tid 100076 td 0xff0002bd5000
>> sched_switch() at sched_switch+0x
Konstantin Belousov wrote:
> On Thu, Dec 27, 2012 at 12:28:54PM +0100, Andreas Longwitz wrote:
>> On a FreeBSD 8-Stable machine with UFS + GJOURNAL (no SU) I observed the
>> same behaviour as described for UFS+SU+J in
>> lists.freebsd.org/pipermail/freebsd-current/201
a8d2000) (stack 0xff8245a52000) sched_switch()
at sched_switch+0xde
100215 (0xff00847cc000) (stack 0xff824525f000) sched_switch()
at sched_switch+0xde
It seems there is a deadlock on the suspfs lock, but I could not figure
out who holds this lock.
Any hints how to g
rst bootverbose run with your block switching patch
>> was ok. I will do some more expansive tests next week.
>
> Thank you very much.
> I've committed this change to head.
After several tests I can state: the patch is ok for me.
Thanks for your quick help!
--
Andreas Longwitz
___
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"
ddr, IOAPIC_REDTBL_HI(intpin->io_intpin), value);
>
> So a pending interrupt would be happily delivered to a wrong destination (new
> vector + old lapic).
> I am not sure if just swapping these two blocks of lines would fix the issue,
> but
> I hope that it would. Could you
es+0x9c: 0
interrupt_sources+0xa0: 0
interrupt_sources+0xa4: 0
interrupt_sources+0xa8: 0
interrupt_sources+0xac: 0
interrupt_sources+0xb0: 0
interrupt_sources+0xb4: 0
interrupt_sources+0xb8: 0
interrupt_sources+0xbc: 0
interrupt_sources+0xc0: 0
interrupt_sources+0xc4: 0
db> reset
--
Andreas Longwitz
___
54
INT active-lo level1 11:A 55
--
Local Ints:TypePolarityTrigger Bus ID IRQAPIC ID PIN#
ExtINT active-hiedge2 02550
NMI active-hiedge0 0:A2551
he corresponding SA (maybe a field like
natt_l2tp_port). So the kernel does for outgoing L2TP packets not know
the correct SA, if two ore more SA's with the same IP exists.
I would like to know if the patch mentioned in this thread adresses this
problem.
--
Dr. Andreas Longwitz
Data Service
anybody the same problem with FreeBSD 8 i386 ?
--
Dr. Andreas Longwitz
Data Service GmbH
Beethovenstr. 2A
23617 Stockelsdorf
Amtsgericht Lübeck, HRB 318 BS
Geschäftsführer: Wilfried Paepcke, Dr. Andreas Longwitz, Josef Flatau
___
freebsd-stable@freebsd.org
John Baldwin wrote:
> On Monday, September 19, 2011 6:20:07 am Andreas Longwitz wrote:
>> Eugene Grosbein wrote:
>>
>>> Well, given that before busdma commit that hardware worked just fine
>>> with stock driver, it could be less overhead for me to rollbac
ge besides re(4)...
Another example is de(4) as mentioned in kern/151941.
--
Dr. Andreas Longwitz
Data Service GmbH
Beethovenstr. 2A
23617 Stockelsdorf
Amtsgericht Lübeck, HRB 318 BS
Geschäftsführer: Wilfried Paepcke, Dr. Andreas Longwitz, Josef Flatau
___
_length, MAX_AMR_IOCTL) when doing the malloc.
Thank you for this hint, I have posted this to kern/155658.
--
Dr. Andreas Longwitz
Data Service GmbH
Beethovenstr. 2A
23617 Stockelsdorf
Amtsgericht Lübeck, HRB 318 BS
Geschäftsführer: Wilfried Paepc
controller has nothing to do with the version
of FreeBSD. I have verified that the overruns occurs in FreeBSD 6 too,
but I do not have an explanation, why FreeBSD did not crash for years
because I used megarc all the time every day.
--
Dr. Andreas Longwitz
Data Service GmbH
Beethovenstr. 2A
2
_object already is filled with zeros and especially
mtx_lock should be 4 (UNOWNED) or the thread id of someone.
What may be the reason, that the panics never occured before and then
on a dozen server in a short time ? No further crashs since a week now.
Any hints are welcome.
--
Dr. Andr
21 matches
Mail list logo
