FreeBSD Hp Proliant DL580 g7 IBM 3650 installation problem
Hi, I have got a big computer which has got at least 4 core Hp Proliant DL580 g7 server. And it has got HP p410i smart array RAID card. I tried to install FreeBSD 8.2, 8.3 9.1 from DVD and bootonly cd but after passed menu screen I got an error. Please show me the way for solution. I attached last screenshot from HP 580. And IBM machine give an error and restart again and again. I attached screenshot too.___ 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
Re: malloc+utrace, tracking memory leaks in a running program.
On 1/10/13 2:38 AM, Konstantin Belousov wrote: On Thu, Jan 10, 2013 at 01:56:48AM -0500, Alfred Perlstein wrote: Here are more convenient links that give diffs against FreeBSD and jemalloc for the proposed changes: FreeBSD: https://github.com/alfredperlstein/freebsd/compare/13e7228d5b83c8fcfc63a0803a374212018f6b68~1...utrace2 Why do you need to expedite the records through the ktrace at all ? Wouldn't direct write(2)s to a file allow for better performance due to not stressing kernel memory allocator and single writing thread ? Also, the malloc coupling to the single-system interface would be prevented. I believe that other usermode tracers also behave in the similar way, using writes and not private kernel interface. Also, what /proc issues did you mentioned ? There is sysctl kern.proc.vmmap which is much more convenient than /proc/pid/map and does not require /proc mounted. jemalloc: https://github.com/alfredperlstein/jemalloc/compare/master...utrace2 Konstantin, you are right, it is a strange thing this utrace. I am not sure why it was done this way. You are correct in that much more efficient system could be made using writes gathered into a single write(2). Do you think there is any reason they may have re-used the kernel paths for ktrace even at the cost of efficiency? About kern.proc.vmmap I will look into that. -Alfred ___ 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
Re: malloc+utrace, tracking memory leaks in a running program.
On Thu, Jan 10, 2013 at 10:16:46AM -0500, Alfred Perlstein wrote: On 1/10/13 2:38 AM, Konstantin Belousov wrote: On Thu, Jan 10, 2013 at 01:56:48AM -0500, Alfred Perlstein wrote: Here are more convenient links that give diffs against FreeBSD and jemalloc for the proposed changes: FreeBSD: https://github.com/alfredperlstein/freebsd/compare/13e7228d5b83c8fcfc63a0803a374212018f6b68~1...utrace2 Why do you need to expedite the records through the ktrace at all ? Wouldn't direct write(2)s to a file allow for better performance due to not stressing kernel memory allocator and single writing thread ? Also, the malloc coupling to the single-system interface would be prevented. I believe that other usermode tracers also behave in the similar way, using writes and not private kernel interface. Also, what /proc issues did you mentioned ? There is sysctl kern.proc.vmmap which is much more convenient than /proc/pid/map and does not require /proc mounted. jemalloc: https://github.com/alfredperlstein/jemalloc/compare/master...utrace2 Konstantin, you are right, it is a strange thing this utrace. I am not sure why it was done this way. You are correct in that much more efficient system could be made using writes gathered into a single write(2). Even without writes gathering, non-coalesced writes should be faster than utrace. Do you think there is any reason they may have re-used the kernel paths for ktrace even at the cost of efficiency? I can only speculate. The utracing of the malloc calls in the context of the ktrace stream is useful for the human reading the trace. Instead of seeing the sequence of unexplanaible calls allocating and freeing memory, you would see something more penetrable. For example, you would see accept/malloc/read/write/free, which could be usefully interpreted as network server serving the client. This context is not needed for a leak detector. About kern.proc.vmmap I will look into that. -Alfred pgpMOJFXTDekU.pgp Description: PGP signature
Re: malloc+utrace, tracking memory leaks in a running program.
On 1/10/13 1:05 PM, Konstantin Belousov wrote:
On Thu, Jan 10, 2013 at 10:16:46AM -0500, Alfred Perlstein wrote:
On 1/10/13 2:38 AM, Konstantin Belousov wrote:
On Thu, Jan 10, 2013 at 01:56:48AM -0500, Alfred Perlstein wrote:
Here are more convenient links that give diffs against FreeBSD and
jemalloc for the proposed changes:
FreeBSD:
https://github.com/alfredperlstein/freebsd/compare/13e7228d5b83c8fcfc63a0803a374212018f6b68~1...utrace2
Why do you need to expedite the records through the ktrace at all ?
Wouldn't direct write(2)s to a file allow for better performance
due to not stressing kernel memory allocator and single writing thread ?
Also, the malloc coupling to the single-system interface would be
prevented.
I believe that other usermode tracers also behave in the similar way,
using writes and not private kernel interface.
Also, what /proc issues did you mentioned ? There is
sysctl kern.proc.vmmap which is much more convenient than /proc/pid/map
and does not require /proc mounted.
jemalloc:
https://github.com/alfredperlstein/jemalloc/compare/master...utrace2
Konstantin, you are right, it is a strange thing this utrace. I am not
sure why it was done this way.
You are correct in that much more efficient system could be made using
writes gathered into a single write(2).
Even without writes gathering, non-coalesced writes should be faster than
utrace.
Do you think there is any reason they may have re-used the kernel paths
for ktrace even at the cost of efficiency?
I can only speculate. The utracing of the malloc calls in the context
of the ktrace stream is useful for the human reading the trace. Instead
of seeing the sequence of unexplanaible calls allocating and freeing
memory, you would see something more penetrable. For example, you would
see accept/malloc/read/write/free, which could be usefully interpreted
as network server serving the client.
This context is not needed for a leak detector.
Now I may be wrong here, but I think it's an artifact of someone
noticing how useful fitting this into the ktrace system and leveraging
existing code.
Even though there are significant performance deficiencies, the actual
utility of the existing framework may have been such a stepping stool
towards tracing that it was just used.
Right now the code already exists, however it logs just {operation,
size, ptr}, example:
malloc, 512, - 0xdeadbeef
free, 0, 0xdeadbeef
realloc, 512, 0 - 0xdeadc0de
realloc, 1024, 0xdeadc0de - 0x
free, 0, 0x
What do you think of just adding the address of the caller of
malloc/free/realloc to these already existing tracepoints?
-Alfred
___
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
__builtin_frame_address broken with self created stack?
I'm working on a project that uses State Threads (ports/devel/st). For the unaware, it's a kinda neat library that implements totally userland threads with setjmp/longjmp, manually creating stacks and moving the stack pointer around. It works well, except for one problem, attempting to get a backtrace of threads. Under linux, the state threads library uses execinfo to get a backtrace. FreeBSD has libexecinfo in ports which basically is just a wrapper around __builtin_frame_address and __builtin_return_address. This also mostly works. Except occasionally __builtin_frame_address will segfault when executing in the context of a created stack. I'm kinda lost how to debug this, because gdb seems entirely confused as to what happened when the segfault is received, I'm guessing because this is a builtin. It works 99% of the time, but under certain (somewhat deterministic circumstances) __builtin_frame_address breaks. I realize this is breaking a whole lot of assumptions by mallocing some memory, declaring it to be the new stack by using some assembly to move the SP register. But, I'm having trouble figuring out what's actually going wrong here. When it does work, libexecinfo's backtrace() function keeps stepping back one frame at a time until it hits NULL. When it doesn't work, when it reaches the frame that should have a NULL frame after it, it segfaults. Breaking into gdb while using the stack that would kill backtrace() and executing bt works okay - gdb is able to read that frame anyway. Another datapoint is that this worked fine in FreeBSD 3.0, but that's a pretty large set of changes to try to narrow down what's different now. Anyone have any idea where to even start with this? I'm having trouble finding anything that documents how frames work now, and what I'm possibly not doing when creating a new stack by hand. ___ 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
Re: malloc+utrace, tracking memory leaks in a running program.
On Thu, Jan 10, 2013 at 01:29:38PM -0500, Alfred Perlstein wrote:
On 1/10/13 1:05 PM, Konstantin Belousov wrote:
On Thu, Jan 10, 2013 at 10:16:46AM -0500, Alfred Perlstein wrote:
On 1/10/13 2:38 AM, Konstantin Belousov wrote:
On Thu, Jan 10, 2013 at 01:56:48AM -0500, Alfred Perlstein wrote:
Here are more convenient links that give diffs against FreeBSD and
jemalloc for the proposed changes:
FreeBSD:
https://github.com/alfredperlstein/freebsd/compare/13e7228d5b83c8fcfc63a0803a374212018f6b68~1...utrace2
Why do you need to expedite the records through the ktrace at all ?
Wouldn't direct write(2)s to a file allow for better performance
due to not stressing kernel memory allocator and single writing thread ?
Also, the malloc coupling to the single-system interface would be
prevented.
I believe that other usermode tracers also behave in the similar way,
using writes and not private kernel interface.
Also, what /proc issues did you mentioned ? There is
sysctl kern.proc.vmmap which is much more convenient than /proc/pid/map
and does not require /proc mounted.
jemalloc:
https://github.com/alfredperlstein/jemalloc/compare/master...utrace2
Konstantin, you are right, it is a strange thing this utrace. I am not
sure why it was done this way.
You are correct in that much more efficient system could be made using
writes gathered into a single write(2).
Even without writes gathering, non-coalesced writes should be faster than
utrace.
Do you think there is any reason they may have re-used the kernel paths
for ktrace even at the cost of efficiency?
I can only speculate. The utracing of the malloc calls in the context
of the ktrace stream is useful for the human reading the trace. Instead
of seeing the sequence of unexplanaible calls allocating and freeing
memory, you would see something more penetrable. For example, you would
see accept/malloc/read/write/free, which could be usefully interpreted
as network server serving the client.
This context is not needed for a leak detector.
Now I may be wrong here, but I think it's an artifact of someone
noticing how useful fitting this into the ktrace system and leveraging
existing code.
Even though there are significant performance deficiencies, the actual
utility of the existing framework may have been such a stepping stool
towards tracing that it was just used.
Right now the code already exists, however it logs just {operation,
size, ptr}, example:
malloc, 512, - 0xdeadbeef
free, 0, 0xdeadbeef
realloc, 512, 0 - 0xdeadc0de
realloc, 1024, 0xdeadc0de - 0x
free, 0, 0x
What do you think of just adding the address of the caller of
malloc/free/realloc to these already existing tracepoints?
In most real-world applications I saw, malloc() was not a function called
to do the allocation. Usually, there is either an app-specific wrapper,
or the language runtime system which calls malloc(), e.g. the new operator
for the C++ code. Than, the caller address becomes constant for the whole
duration of the program run.
What would be useful is the full backtrace of each allocation. The tools
like libunwind are indeed optimized for this usage pattern.
From this POV, the libc malloc(3) might be better offering a set of the
well-defined hooks for a pluggable tracer to utilize. I am on the fence
there, you could override the malloc/free without hooks, by the ELF symbol
interposing technique, but hooks would also offer features not easily
implementable with the interposing.
pgp3bpBpdU_be.pgp
Description: PGP signature
SATA disk disappears
got this on dell poweredge T110 server with 4 disks, including two 3TB drives (ada2,ada3): ahcich2: Timeout on slot 8 port 0 ahcich2: is cs 1e00 ss 1f00 rs 1f00 tfd 40 serr cmd c817 ahcich2: AHCI reset: device not ready after 31000ms (tfd = 0080) (ada2:ahcich2:0:0:0): lost device GEOM_MIRROR: Request failed (error=6). ada2[WRITE(offset=2997587410944, length=753664)] GEOM_MIRROR: Device home1: provider ada2 disconnected. (ada2:ahcich2:0:0:0): removing device entry did camcontrol reset 2, rescan 2 and ada2 reappeared ada2 at ahcich2 bus 0 scbus2 target 0 lun 0 ada2: WDC WD30EZRX-00DC0B0 80.00A80 ATA-9 SATA 3.x device ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada2: Command Queueing enabled ada2: 2861588MB (5860533168 512 byte sectors: 16H 63S/T 16383C) GEOM_MIRROR: Component ada2 (device home1) broken, skipping. GEOM_MIRROR: Cannot add disk ada2 to home1 (error=22). started gmirror rebuild and it now works at full speed. GEOM_MIRROR: Device home1: rebuilding provider ada2. What kind of hardware failure may it be? smartctl -a /dev/ada2 shows disk is fine. I use latest FreeBSD-8 ___ 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
Re: SATA disk disappears
On Fri, 11 Jan 2013, Wojciech Puchar wrote: got this on dell poweredge T110 server with 4 disks, including two 3TB drives (ada2,ada3): ahcich2: Timeout on slot 8 port 0 ahcich2: is cs 1e00 ss 1f00 rs 1f00 tfd 40 serr cmd c817 ahcich2: AHCI reset: device not ready after 31000ms (tfd = 0080) (ada2:ahcich2:0:0:0): lost device GEOM_MIRROR: Request failed (error=6). ada2[WRITE(offset=2997587410944, length=753664)] GEOM_MIRROR: Device home1: provider ada2 disconnected. (ada2:ahcich2:0:0:0): removing device entry did camcontrol reset 2, rescan 2 and ada2 reappeared ada2 at ahcich2 bus 0 scbus2 target 0 lun 0 ada2: WDC WD30EZRX-00DC0B0 80.00A80 ATA-9 SATA 3.x device ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada2: Command Queueing enabled ada2: 2861588MB (5860533168 512 byte sectors: 16H 63S/T 16383C) GEOM_MIRROR: Component ada2 (device home1) broken, skipping. GEOM_MIRROR: Cannot add disk ada2 to home1 (error=22). started gmirror rebuild and it now works at full speed. GEOM_MIRROR: Device home1: rebuilding provider ada2. What kind of hardware failure may it be? smartctl -a /dev/ada2 shows disk is fine. I had a new WD drive recently that had a write error. Reallocated sector count did not go up, but it quickly failed the SMART self-test, short or long. See smartctl(8) about the -t parameters. ___ 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
RE: kern/174749: Unexpected change of default route
Do some body know how can we debug kernel memory corruption on live system? We need to find out which function/subsystem is cause of this mess. Or maybe is there some way to lock particular memory area, where default gateway lies and watch which subsystem will cause system crash? ___ 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
Inconsistent TCP state in tcp_do_segment()
Hi,
I've been using the kernel socket API and noticed that every once in a
while the data received at the remote end of a TCP connection doesn't match
the data sent locally using sosend(). I tracked it down to the piece of
code in tcp_do_segment() starting at line 2665: (svn rev 245286)
if (acked so-so_snd.sb_cc) {
tp-snd_wnd -= so-so_snd.sb_cc;
sbdrop_locked(so-so_snd, (int)so-so_snd.sb_cc);
ourfinisacked = 1;
} else {
sbdrop_locked(so-so_snd, acked);
tp-snd_wnd -= acked;
ourfinisacked = 0;
}
sowwakeup_locked(so);
/* Detect una wraparound. */
if (!IN_RECOVERY(tp-t_flags)
SEQ_GT(tp-snd_una, tp-snd_recover)
SEQ_LEQ(th-th_ack, tp-snd_recover))
tp-snd_recover = th-th_ack - 1;
/* XXXLAS: Can this be moved up into cc_post_recovery? */
if (IN_RECOVERY(tp-t_flags)
SEQ_GEQ(th-th_ack, tp-snd_recover)) {
EXIT_RECOVERY(tp-t_flags);
}
tp-snd_una = th-th_ack;
if (tp-t_flags TF_SACK_PERMIT) {
if (SEQ_GT(tp-snd_una, tp-snd_recover))
tp-snd_recover = tp-snd_una;
}
if (SEQ_LT(tp-snd_nxt, tp-snd_una))
tp-snd_nxt = tp-snd_una;
The issue is that sowwakeup_locked() is called before all the tcpcb fields
are updated to account for the current ACK processing as can be seen from
the tp-snd_una = th-th_ack in line 2686. My code that uses the kernel
socket API calls sosend() in the upcall path resulting from
sowwakeup_locked() which in turn can lead to tcp_output() being called with
inconsistent TCP state. If I move the call to sowwakeup_locked() to after
the 'if (SEQ_LT(tp-snd_nxt, tp-snd_una))' line in the code snippet above
the data corruption issue seems to be fixed.
___
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
Possible bug in m_split() when splitting M_EXT mbufs
Hi,
Could someone please verify if m_split as in svn rev 245286 is doing the
right thing in the scenario where a mbuf chain is split with len0 falling
on a mbuf boundary and the mbuf in question being a M_EXT mbuf? Consider
the following example where m0 is a mbuf chain consisting of 2 M_EXT mbufs,
both 1448 bytes in length. Let len0 be 1448. The 'len0 m-m_len' check
will be false so the for loop will not be entered in this case. We now have
len = 1448 and remain = 0 and m still points to the first mbuf in the
chain. Also assume that m0 is a pkthdr mbuf. A new pkthdr mbuf n will be
allocated and initialized before the following piece of code is executed :
extpacket:
if (m-m_flags M_EXT) {
n-m_data = m-m_data + len;
mb_dupcl(n, m);
} else {
bcopy(mtod(m, caddr_t) + len, mtod(n, caddr_t), remain);
}
n-m_len = remain;
m-m_len = len;
n-m_next = m-m_next;
m-m_next = NULL;
return (n);
As m is a M_EXT mbuf the code in the if() clause will be executed. The
problem is that m still points to the first mbuf so effectively the data
pointer for n is assigned to the end of m's data pointer. It should
actually point to the start of the data pointer of the next mbuf in the
original m0 chain, right?
___
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
