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