Re: another error with md malloc based fs
Michael Schuh schrieb: hi Chuck, hi @list me again, behind the scenes, i would take over my Server by an hoster from Linux to FreeBSD on the running system, while the hoster takes money for pressing 2 buttons and put a disk in my Server...so i create now a mfs based system that can bootet from disk and resides fully in ram. I have tryed out Colin's depenguinator, but it fails...some times now i would do the steps by hand thanks cheers michael Hi Michael! Some months ago I modified the depenguinator and made it work again. But sorry, I didn't yet get to write down all the steps involved (I am not a good writer). But I recently found another much more comfortable way using QEMU which I documented. Does your provider offer a linux rescue system? If yes, you can try this: http://www.vrdevelopers.de/content/view/45/40/1/5/lang,en/ I'll try to follow up with the modified depenguinator asap, but don't hold your breath... HTH, Manuel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
100% repeatable crashes on 6.2-RELEASE-p3
Hello,
I've got these repeatable crashes with:
klon# uname -a
FreeBSD klon.klsp.kharkov.ua 6.2-RELEASE-p3 FreeBSD 6.2-RELEASE-p3 #7:
Fri Mar 23 11:26:01 EET 2007
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/KLON i386
the system is running quagga and l2tpd built from the yesterday's ports.
I noticed that this panics are usually happen when third ppp interface
going up.
what can I do?
Below is the complete back trace.
klon# cd /usr/obj/usr/src/sys/KLON/
klon# kgdb kernel.debug /var/crash/vmcore.0
kgdb: kvm_nlist(_stopped_cpus):
kgdb: kvm_nlist(_stoppcbs):
[GDB will not be able to debug user-mode threads:
/usr/lib/libthread_db.so: Undefined symbol ps_pglobal_lookup]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-marcel-freebsd.
Ready to go. Enter 'tr' to connect to the remote target
with /dev/cuad0, 'tr /dev/cuad1' to connect to a different port
or 'trf portno' to connect to the remote target with the firewire
interface. portno defaults to 5556.
Type 'getsyms' after connection to load kld symbols.
If you're debugging a local system, you can use 'kldsyms' instead
to load the kld symbols. That's a less obnoxious interface.
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xff80
fault code = supervisor write, page not present
instruction pointer = 0x20:0xc050d011
stack pointer = 0x28:0xcc76fa6c
frame pointer = 0x28:0xcc76fa78
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 302 (ripd)
trap number = 12
panic: page fault
Uptime: 1h18m47s
Dumping 254 MB (2 chunks)
chunk 0: 1MB (159 pages) ... ok
chunk 1: 254MB (64960 pages) 238 222 206 190 174 158 142 126 110 94 78
62 46 30 14
#0 doadump () at pcpu.h:165
165 __asm __volatile(movl %%fs:0,%0 : =r (td));
(kgdb) bktr
Undefined command: bktr. Try help.
(kgdb) backtrace
#0 doadump () at pcpu.h:165
During symbol reading, Incomplete CFI data; unspecified registers at
0xc04d87b5.
#1 0xc04d8c96 in boot (howto=0x104) at
/usr/src/sys/kern/kern_shutdown.c:409
#2 0xc04d8f2c in panic (fmt=0xc06496b4 %s) at
/usr/src/sys/kern/kern_shutdown.c:565
#3 0xc062a874 in trap_fatal (frame=0xcc76fa2c, eva=0xff80) at
/usr/src/sys/i386/i386/trap.c:837
#4 0xc062a5db in trap_pfault (frame=0xcc76fa2c, usermode=0x0,
eva=0xff80) at /usr/src/sys/i386/i386/trap.c:745
#5 0xc062a219 in trap (frame=
{tf_fs = 0xc04e0008, tf_es = 0xc1da0028, tf_ds = 0xc2420028,
tf_edi = 0xc1e7296c, tf_esi = 0xc1d9c438, tf_ebp = 0xcc76fa78, tf_isp =
0xcc76fa58, tf_ebx = 0xc22ec900, tf_edx = 0xc22ec900, tf_ecx =
0xff80, tf_eax = 0xc239c800, tf_trapno = 0xc, tf_err = 0x2, tf_eip =
0xc050d011, tf_cs = 0x20, tf_eflags = 0x10202, tf_esp = 0xc1d9c438,
tf_ss = 0xc1e728f6}) at /usr/src/sys/i386/i386/trap.c:435
#6 0xc06188ea in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7 0xc050d011 in putc (chr=0x20, clistp=0xc1d9c438) at
/usr/src/sys/kern/tty_subr.c:399
#8 0xc055233b in pppasyncstart (sc=0xc24e5200) at
/usr/src/sys/net/ppp_tty.c:601
#9 0xc054bf2e in pppoutput (ifp=0xc1ed, m0=0xc245d600,
dst=0xcc76fb18, rtp=0x0) at /usr/src/sys/net/if_ppp.c:961
#10 0xc0564494 in ip_output (m=0xc245d600, opt=0xc1ed,
ro=0xcc76fb14, flags=0x20, imo=0xc239d680, inp=0xc1fef924)
at /usr/src/sys/netinet/ip_output.c:777
#11 0xc0574e07 in udp_output (inp=0xc1fef924, m=0xc245d600,
addr=0xc23a43c0, control=0x20, td=0xc1e36d80)
at /usr/src/sys/netinet/udp_usrreq.c:913
#12 0xc05757ae in udp_send (so=0xc239c800, flags=0x0, m=0xc2425b00,
addr=0xc23a43c0, control=0x0, td=0xc1e36d80)
at /usr/src/sys/netinet/udp_usrreq.c:1090
#13 0xc0511d8b in sosend (so=0xc23b29bc, addr=0xc23a43c0,
uio=0xcc76fc40, top=0xc2425b00, control=0x0, flags=0x0,
td=0xc1e36d80) at /usr/src/sys/kern/uipc_socket.c:836
#14 0xc0517729 in kern_sendit (td=0xc1e36d80, s=0x9, mp=0xcc76fcbc,
flags=0x0, control=0x0, segflg=3258566656)
at /usr/src/sys/kern/uipc_syscalls.c:772
#15 0xc05175e3 in sendit (td=0xc1e36d80, s=0x9, mp=0xcc76fcbc,
flags=0x0) at /usr/src/sys/kern/uipc_syscalls.c:712
#16 0xc05178d1 in sendto (td=0xc1e36d80, uap=0xc22ec900) at
/usr/src/sys/kern/uipc_syscalls.c:830
#17 0xc062ab8b in syscall (frame=
{tf_fs = 0x3b, tf_es = 0x3b, tf_ds = 0xbfbf003b, tf_edi = 0x9,
tf_esi = 0xbfbfeb60, tf_ebp = 0xbfbfeb88, tf_isp = 0xcc76fd64, tf_ebx =
0x80a9a20, tf_edx = 0xc00, tf_ecx = 0xc, tf_eax = 0x85, tf_trapno =
0x0, tf_err = 0x2, tf_eip = 0x281a8f43, tf_cs =
Re: 100% repeatable crashes on 6.2-RELEASE-p3 (bt full)
Gregory Edigarov wrote:
Hello,
I've got these repeatable crashes with:
klon# uname -a
FreeBSD klon.klsp.kharkov.ua 6.2-RELEASE-p3 FreeBSD 6.2-RELEASE-p3 #7:
Fri Mar 23 11:26:01 EET 2007
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/KLON i386
the system is running quagga and l2tpd built from the yesterday's ports.
I noticed that this panics are usually happen when third ppp interface
going up.
what can I do?
Below is the complete back trace.
klon# cd /usr/obj/usr/src/sys/KLON/
klon# kgdb kernel.debug /var/crash/vmcore.0
kgdb: kvm_nlist(_stopped_cpus):
kgdb: kvm_nlist(_stoppcbs):
[GDB will not be able to debug user-mode threads:
/usr/lib/libthread_db.so: Undefined symbol ps_pglobal_lookup]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for
details.
This GDB was configured as i386-marcel-freebsd.
Ready to go. Enter 'tr' to connect to the remote target
with /dev/cuad0, 'tr /dev/cuad1' to connect to a different port
or 'trf portno' to connect to the remote target with the firewire
interface. portno defaults to 5556.
Type 'getsyms' after connection to load kld symbols.
If you're debugging a local system, you can use 'kldsyms' instead
to load the kld symbols. That's a less obnoxious interface.
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xff80
fault code = supervisor write, page not present
instruction pointer = 0x20:0xc050d011
stack pointer = 0x28:0xcc76fa6c
frame pointer = 0x28:0xcc76fa78
code segment = base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 302 (ripd)
trap number = 12
panic: page fault
Uptime: 1h18m47s
Dumping 254 MB (2 chunks)
chunk 0: 1MB (159 pages) ... ok
chunk 1: 254MB (64960 pages) 238 222 206 190 174 158 142 126 110 94 78
62 46 30 14
#0 doadump () at pcpu.h:165
165 __asm __volatile(movl %%fs:0,%0 : =r (td));
(kgdb) bktr
Undefined command: bktr. Try help.
(kgdb) backtrace
#0 doadump () at pcpu.h:165
During symbol reading, Incomplete CFI data; unspecified registers at
0xc04d87b5.
#1 0xc04d8c96 in boot (howto=0x104) at
/usr/src/sys/kern/kern_shutdown.c:409
#2 0xc04d8f2c in panic (fmt=0xc06496b4 %s) at
/usr/src/sys/kern/kern_shutdown.c:565
#3 0xc062a874 in trap_fatal (frame=0xcc76fa2c, eva=0xff80) at
/usr/src/sys/i386/i386/trap.c:837
#4 0xc062a5db in trap_pfault (frame=0xcc76fa2c, usermode=0x0,
eva=0xff80) at /usr/src/sys/i386/i386/trap.c:745
#5 0xc062a219 in trap (frame=
{tf_fs = 0xc04e0008, tf_es = 0xc1da0028, tf_ds = 0xc2420028, tf_edi =
0xc1e7296c, tf_esi = 0xc1d9c438, tf_ebp = 0xcc76fa78, tf_isp =
0xcc76fa58, tf_ebx = 0xc22ec900, tf_edx = 0xc22ec900, tf_ecx =
0xff80, tf_eax = 0xc239c800, tf_trapno = 0xc, tf_err = 0x2, tf_eip
= 0xc050d011, tf_cs = 0x20, tf_eflags = 0x10202, tf_esp = 0xc1d9c438,
tf_ss = 0xc1e728f6}) at /usr/src/sys/i386/i386/trap.c:435
#6 0xc06188ea in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7 0xc050d011 in putc (chr=0x20, clistp=0xc1d9c438) at
/usr/src/sys/kern/tty_subr.c:399
#8 0xc055233b in pppasyncstart (sc=0xc24e5200) at
/usr/src/sys/net/ppp_tty.c:601
#9 0xc054bf2e in pppoutput (ifp=0xc1ed, m0=0xc245d600,
dst=0xcc76fb18, rtp=0x0) at /usr/src/sys/net/if_ppp.c:961
#10 0xc0564494 in ip_output (m=0xc245d600, opt=0xc1ed,
ro=0xcc76fb14, flags=0x20, imo=0xc239d680, inp=0xc1fef924)
at /usr/src/sys/netinet/ip_output.c:777
#11 0xc0574e07 in udp_output (inp=0xc1fef924, m=0xc245d600,
addr=0xc23a43c0, control=0x20, td=0xc1e36d80)
at /usr/src/sys/netinet/udp_usrreq.c:913
#12 0xc05757ae in udp_send (so=0xc239c800, flags=0x0, m=0xc2425b00,
addr=0xc23a43c0, control=0x0, td=0xc1e36d80)
at /usr/src/sys/netinet/udp_usrreq.c:1090
#13 0xc0511d8b in sosend (so=0xc23b29bc, addr=0xc23a43c0,
uio=0xcc76fc40, top=0xc2425b00, control=0x0, flags=0x0,
td=0xc1e36d80) at /usr/src/sys/kern/uipc_socket.c:836
#14 0xc0517729 in kern_sendit (td=0xc1e36d80, s=0x9, mp=0xcc76fcbc,
flags=0x0, control=0x0, segflg=3258566656)
at /usr/src/sys/kern/uipc_syscalls.c:772
#15 0xc05175e3 in sendit (td=0xc1e36d80, s=0x9, mp=0xcc76fcbc,
flags=0x0) at /usr/src/sys/kern/uipc_syscalls.c:712
#16 0xc05178d1 in sendto (td=0xc1e36d80, uap=0xc22ec900) at
/usr/src/sys/kern/uipc_syscalls.c:830
#17 0xc062ab8b in syscall (frame=
{tf_fs = 0x3b, tf_es = 0x3b, tf_ds = 0xbfbf003b, tf_edi = 0x9, tf_esi
= 0xbfbfeb60, tf_ebp = 0xbfbfeb88, tf_isp = 0xcc76fd64, tf_ebx =
0x80a9a20, tf_edx = 0xc00, tf_ecx = 0xc, tf_eax = 0x85, tf_trapno
= 0x0, tf_err = 0x2, tf_eip = 0x281a8f43, tf_cs = 0x33, tf_eflags =
0x296, tf_esp = 0xbfbfeafc, tf_ss = 0x3b}) at
/usr/src/sys/i386/i386/trap.c:983
#18 0xc061893f in Xint0x80_syscall ()
Re: 100% repeatable crashes on 6.2-RELEASE-p3
On Fri, Mar 23, 2007 at 02:25:44PM +0200, Gregory Edigarov wrote: Hello, I've got these repeatable crashes with: klon# uname -a FreeBSD klon.klsp.kharkov.ua 6.2-RELEASE-p3 FreeBSD 6.2-RELEASE-p3 #7: Fri Mar 23 11:26:01 EET 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/KLON i386 the system is running quagga and l2tpd built from the yesterday's ports. I noticed that this panics are usually happen when third ppp interface going up. what can I do? Not use kernel ppp, which is known to be broken. I don't know what this means for your application. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: another error with md malloc based fs
Michael Schuh wrote: Chuck Swiger wrote: Michael Schuh wrote: i can't understand how malloc can eat all available memory, i have 2Gigs of it ;-) so it seems to me i know what i doing, if i have 1,6 Gigs free Memory, and i say ok get me 750Megs from my 1,6 Gigs of free Memory, what was faulty on that The two choices involve a swap-based RAMdisk, which can use all of the available physical RAM it needs to, since this memory is swappable, or a kernel-memory-based RAMdisk, which uses wired-down memory from within the kernel. Ok, so that is it harder to understand for me in the first time, if i understand it now right the swap or file based memory backend is also in the ram, but it get another way managed from kernels vm. the malloc based ramdisk get's not reallly managed by the kvm, but it underlays under the paging and swapping, and also ba the thread-killer there shot's thread down it it get's to much work for the system i hope i understand this right, it is important for me... Let me try to explain it with a little different words. The following is a bit simplified, but it should give you an idea about the advantages and disadvantages of each md disk type. First of all, _both_ malloc and swap-backed md disks are RAM disks. You don't have to worry that a swap-backed md disk will be created on your swap partiton. It's not. It will reside in RAM, just like a malloc md disk. However, the difference is that a malloc md disk uses memory from the KVM area (kernel virtual memory), which is hardwired into the RAM. It cannot be paged, and it is taken from the kernel's own memory pool, which is usually much smaller than your total available RAM. It's taken from the same pool of RAM that's used for network buffers, driver data and similar things. On the other hand, swap-backed md disks use regular memory, so to speak, just like a normal user process. That also means that they are pageable, which means that they can be paged to swap if necessary (if the systems runs low on RAM). That's what swap-backed means. Because of that, they don't have a size limit (well, they shouldn't be bigger than your RAM + swap, of course). If there is enough RAM, then they will stay completely in RAM and will _not_ touch your swap at all. For typical RAM disks, such as for /tmp, you should use a swap-backed md disk (it should be the default). The malloc type should be used only for rather small, special uses. I hope it's now a little clearer. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd [...] one observation we can make here is that Python makes an excellent pseudocoding language, with the wonderful attribute that it can actually be executed. -- Bruce Eckel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 100% repeatable crashes on 6.2-RELEASE-p3
Kris Kennaway [EMAIL PROTECTED] writes: Hello, Not use kernel ppp, which is known to be broken. I don't know what this means for your application. Sorry to hijack this thread but is there any way to mimic the following pppd invocation with mpd or ppp(8) : /usr/sbin/pppd 192.168.0.15:192.168.0.80 nodefaultroute nodetach debug \ lcp-echo-failure 10 lcp-echo-interval 10 proxyarp deflate 8 It could help me to get reliable operation from ssltunnel based links (ports/net/ssltunnel-*) Regards -- J'aimerai créer mon propre newsgroup fr.mincir.vitalite [...] Ainsi, cela permettrait aux personnes de se rendre directement dans mon newsgroup plutot que moi-même de publier des annonces dans les autres -+-LH in Guide du Neuneu Usenet : Mince, Neuneu investit (dans) fufe -+- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: another error with md malloc based fs
Oliver, Thanks for this excellent article. I was trying to write about the same thing, but keep it simple enough to improve the chances of it crossing the language barrier weel enough to be useful. I believe you did a really good job of this and saved me several minutes of tying to do the same. I thought the warning in the man page was adequate (until 7.0 changes the default to swap backed), but, at least in Michael's case, I guess I was wrong. I guess the man page need to somehow make it clear that the memory used by malloc backed mds is a very limited resource. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpND9BHTEswl.pgp Description: PGP signature
Re: another error with md malloc based fs
Kevin Oberman wrote: I thought the warning in the man page was adequate (until 7.0 changes the default to swap backed), but, at least in Michael's case, I guess I was wrong. I guess the man page need to somehow make it clear that the memory used by malloc backed mds is a very limited resource. I think it's not necessarily only the language barrier, but the fact that not everyone is familiar with technical terms and details. I guess that many people don't know what swap-backed means exactly. I also think that the name malloc is badly chosen in that context ... even a (userland) programmer might confuse it with malloc(3), which is quite a different thing. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd If Java had true garbage collection, most programs would delete themselves upon execution. -- Robert Sewell ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: another error with md malloc based fs
Hi Oliver, Hi @list, yes that's exatly what i have in my mind, after the explainings from Chuck. thanks very much cheers michael 2007/3/23, Oliver Fromme [EMAIL PROTECTED]: Michael Schuh wrote: Chuck Swiger wrote: Michael Schuh wrote: i can't understand how malloc can eat all available memory, i have 2Gigs of it ;-) so it seems to me i know what i doing, if i have 1,6 Gigs free Memory, and i say ok get me 750Megs from my 1,6 Gigs of free Memory, what was faulty on that The two choices involve a swap-based RAMdisk, which can use all of the available physical RAM it needs to, since this memory is swappable, or a kernel-memory-based RAMdisk, which uses wired-down memory from within the kernel. Ok, so that is it harder to understand for me in the first time, if i understand it now right the swap or file based memory backend is also in the ram, but it get another way managed from kernels vm. the malloc based ramdisk get's not reallly managed by the kvm, but it underlays under the paging and swapping, and also ba the thread-killer there shot's thread down it it get's to much work for the system i hope i understand this right, it is important for me... Let me try to explain it with a little different words. The following is a bit simplified, but it should give you an idea about the advantages and disadvantages of each md disk type. First of all, _both_ malloc and swap-backed md disks are RAM disks. You don't have to worry that a swap-backed md disk will be created on your swap partiton. It's not. It will reside in RAM, just like a malloc md disk. However, the difference is that a malloc md disk uses memory from the KVM area (kernel virtual memory), which is hardwired into the RAM. It cannot be paged, and it is taken from the kernel's own memory pool, which is usually much smaller than your total available RAM. It's taken from the same pool of RAM that's used for network buffers, driver data and similar things. On the other hand, swap-backed md disks use regular memory, so to speak, just like a normal user process. That also means that they are pageable, which means that they can be paged to swap if necessary (if the systems runs low on RAM). That's what swap-backed means. Because of that, they don't have a size limit (well, they shouldn't be bigger than your RAM + swap, of course). If there is enough RAM, then they will stay completely in RAM and will _not_ touch your swap at all. For typical RAM disks, such as for /tmp, you should use a swap-backed md disk (it should be the default). The malloc type should be used only for rather small, special uses. I hope it's now a little clearer. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd [...] one observation we can make here is that Python makes an excellent pseudocoding language, with the wonderful attribute that it can actually be executed. -- Bruce Eckel -- === michael-schuh.net === Michael Schuh Preußenstr. 13 66111 Saarbrücken phone: 0681/8319664 mobil: 0177/9738644 @: [EMAIL PROTECTED] === Ust-ID: DE251072318 === ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
installation issue 6.2 AMD64-bit 3ware 9550SX
I am trying to install FreeBSD-stable 6.2 64-bit from CDROM and the installation hangs. The installation hangs after the 3ware 9000 Series Storage Controller is recognized (using the twa0 driver). If I disable ACPI, I get to the sysinstall screen, however, no hard drives are detected. Here is a list of the system details (2) AMD Opteron 2210 processors Super Micro HDa8-2 Motherboard 3ware 9550SX-12 SATA RAID Controller (8) Seagate 7200.10 750 Gb SATA hard drives GeForce 7300GS PCI-E video card Sony DVD/CDROM Sony AIT4 tape drive nVidia Corp MCP55 ethernet ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: installation issue 6.2 AMD64-bit 3ware 9550SX
Jon, This issue should be fixed in the FreeBSD 6.X driver on the 3ware web-site (9.4.1 codeset). We need to send a kernel patch to update the in-kernel 6.X driver to the latest version. -Adam On 3/23/07, Jon Langton [EMAIL PROTECTED] wrote: I am trying to install FreeBSD-stable 6.2 64-bit from CDROM and the installation hangs. The installation hangs after the 3ware 9000 Series Storage Controller is recognized (using the twa0 driver). If I disable ACPI, I get to the sysinstall screen, however, no hard drives are detected. Here is a list of the system details (2) AMD Opteron 2210 processors Super Micro HDa8-2 Motherboard 3ware 9550SX-12 SATA RAID Controller (8) Seagate 7200.10 750 Gb SATA hard drives GeForce 7300GS PCI-E video card Sony DVD/CDROM Sony AIT4 tape drive nVidia Corp MCP55 ethernet ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Amd64 Unstable Areca
Hello...
El vie, 23-03-2007 a las 11:12 +1100, Jan Mikkelsen escribió:
Hi,
Phillip Neumann wrote:
My amd64 box is not very stable.
In its hardware list, you can see there is an areca 1210 card, wich
suffer the errata of 6.2-release (high load crash)
Last week or so, i saw a commit where the areca bugs were fixed, so i
updated the system.
I can still see the mashine crashing under load
How heavy is the load? I can't make 6-STABLE crash, but I could make
6.2-RELEASE crash. My guess is that you have filesystem corruption
introduced with the earlier driver which is now causing problems even
though the driver now works.
Im attaching a new backtrace, when the system crashed, iostat reported
actually not very high load:
00 21.80 171 3.64 0.00 0 0.00 16.00 2 0.03 6 0 3 0
91
00 25.00 92 2.24 0.00 0 0.00 0.00 0 0.00 7 0 6 0
87
00 13.99 143 1.95 8.00 5 0.04 0.00 0 0.00 3 0 7 0
90
00 18.25 331 5.89 0.00 0 0.00 16.00 1 0.02 0 0 1 1
97
00 9.84 766 7.36 9.00 8 0.07 23.32 74 1.68 1 0 3 1
95
00 5.05 551 2.72 9.00 8 0.07 11.31 113 1.25 4 0 1 0
94
when it crashed, jailed-apache was the most moving process in the
system...
The real load is coused by tinderbox, wich uses the disks and one of
both CPUs present in the system.
Are you sudgesting to newfs FS's?
Actually i used plain 6.2 install disks to do that...
Have you done an fsck in single user mode, not a background fsck?
yes, sometimes (after panic) i need to fsck in single user mode...
sometimes (under load) i see this message:
Interrupt storm detected on swi2:; throttling interrupt source
I see this too. It seems to be benign.
okey.
Regards,
Jan Mikkelsen
How would i get more info?
Any tips are welcome, Thanks!
--
KillFill [EMAIL PROTECTED]
[EMAIL PROTECTED] /usr/obj/usr/src/sys/WORM]# kgdb kernel.debug
/var/crash/vmcore.0
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol ps_pglobal_lookup]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as amd64-marcel-freebsd.
Unread portion of the kernel message buffer:
/usr/local: bad dir ino 363554 at offset 512: mangled entry
panic: ufs_dirbad: bad dir
cpuid = 0
Uptime: 19h46m33s
Dumping 2047 MB (2 chunks)
chunk 0: 1MB (156 pages) ... ok
chunk 1: 2047MB (524016 pages) 2031 2015 1999 1983 1967 1951 1935 1919 1903
1887 1871 1855 1839 1823 1807 1791 1775 1759 1743 1727 1711 1695 1679 1663 1647
1631 1615 1599 1583 1567 1551 1535 1519 1503 1487 1471 1455 1439 1423 1407 1391
1375 1359 1343 1327 1311 1295 1279 1263 1247 1231 1215 1199 1183 1167 1151 1135
1119 1103 1087 1071 1055 1039 1023 1007 991 975 959 943 927 911 895 879 863 847
831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527
511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207
191 175 159 143 127 111 95 79 63 47 31 15
#0 doadump () at pcpu.h:172
172 __asm __volatile(movq %%gs:0,%0 : =r (td));
(kgdb) bt
#0 doadump () at pcpu.h:172
#1 0x0004 in ?? ()
#2 0x804085e7 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:409
#3 0x80408c81 in panic (fmt=0xff005e027000 \b�L^)
at /usr/src/sys/kern/kern_shutdown.c:565
#4 0x8059b230 in ufs_dirbad (ip=0x0, offset=0, how=0x0)
at /usr/src/sys/ufs/ufs/ufs_lookup.c:599
#5 0x8059b657 in ufs_lookup (ap=0xb76867a0)
at /usr/src/sys/ufs/ufs/ufs_lookup.c:287
#6 0x806807fa in VOP_CACHEDLOOKUP_APV (vop=0x0, a=0x0) at
vnode_if.c:150
#7 0x80465bd5 in vfs_cache_lookup (ap=0x0) at vnode_if.h:82
#8 0x8068153d in VOP_LOOKUP_APV (vop=0x808d4540,
a=0xb7686890)
at vnode_if.c:99
#9 0x8046a555 in lookup (ndp=0xb7686990) at vnode_if.h:56
#10 0x8046b285 in namei (ndp=0xb7686990)
at /usr/src/sys/kern/vfs_lookup.c:216
#11 0x8047c4b4 in kern_lstat (td=0xff005e027000, path=0x0,
pathseg=UIO_USERSPACE, sbp=0xb7686af0) at
/usr/src/sys/kern/vfs_syscalls.c:2141
#12 0x8047c9a7 in lstat (td=0x0, uap=0xb7686bc0)
at /usr/src/sys/kern/vfs_syscalls.c:2124
#13 0x8062ae91 in syscall (frame=
{tf_rdi = 5275880, tf_rsi = 5275760, tf_rdx = 0, tf_rcx = 0, tf_r8 =
-140737483074239, tf_r9 = 128, tf_rax = 190, tf_rbx = 5275648, tf_rbp =
5275760, tf_r10 = 0, tf_r11 = 0, tf_r12 = 5259264, tf_r13 = 0, tf_r14 =
5271552, tf_r15 = 0, tf_trapno = 12, tf_addr = 5275744, tf_flags = 0, tf_err =
2, tf_rip = 34367048508, tf_cs = 43, tf_rflags
Re: Amd64 Unstable Areca
A newer version of the driver has been release to fix this problem (I think): http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/arcmsr/ If that doesn't work move back down to 1.20.00.12: http://www.nbritton.org/uploads/areca/ Added erich and scott to the cc list. On 3/22/07, Phillip Neumann [EMAIL PROTECTED] wrote: Dear FreeBSD-stable... My amd64 box is not very stable. In its hardware list, you can see there is an areca 1210 card, wich suffer the errata of 6.2-release (high load crash) Last week or so, i saw a commit where the areca bugs were fixed, so i updated the system. I can still see the mashine crashing under load attached are dmesg -a, and a simple 'bt' of kgdb. sometimes (under load) i see this message: Interrupt storm detected on swi2:; throttling interrupt source i get the same behaviour with sched_bsd or sched_ule Is this info useful to determine where the problem is? If so, where is it? :-) Has this something to do with the fs? or the scheduler? thanks! killfill. [EMAIL PROTECTED] /usr/obj/usr/src/sys/WORM]# kgdb kernel.debug /var/crash/vmcore.1 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol ps_pglobal_lookup] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd. Unread portion of the kernel message buffer: panic: handle_workitem_remove: lost inodedep cpuid = 0 Uptime: 2h19m9s Dumping 2047 MB (2 chunks) chunk 0: 1MB (156 pages) ... ok chunk 1: 2047MB (524016 pages) 2031 2015 1999 1983 1967 1951 1935 1919 1903 1887 1871 1855 1839 1823 1807 1791 1775 1759 1743 1727 1711 1695 1679 1663 1647 1631 1615 1599 1583 1567 1551 1535 1519 1503 1487 1471 1455 1439 1423 1407 1391 1375 1359 1343 1327 1311 1295 1279 1263 1247 1231 1215 1199 1183 1167 1151 1135 1119 1103 1087 1071 1055 1039 1023 1007 991 975 959 943 927 911 895 879 863 847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:172 172 __asm __volatile(movq %%gs:0,%0 : =r (td)); (kgdb) bt #0 doadump () at pcpu.h:172 #1 0x0004 in ?? () #2 0x804085e7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #3 0x80408c81 in panic (fmt=0xff007a9cd980 #65533;VTx) at /usr/src/sys/kern/kern_shutdown.c:565 #4 0x80589fc6 in handle_workitem_remove (dirrem=0xff001a6c7b40, xp=0x0) at /usr/src/sys/ufs/ffs/ffs_softdep.c:3599 #5 0x8058a3dc in process_worklist_item (mp=0xff0031482630, flags=0) at /usr/src/sys/ufs/ffs/ffs_softdep.c:962 #6 0x8058fd3d in softdep_process_worklist (mp=0xff0031482630, full=0) at /usr/src/sys/ufs/ffs/ffs_softdep.c:851 #7 0x80590031 in softdep_flush () at /usr/src/sys/ufs/ffs/ffs_softdep.c:762 #8 0x803ed647 in fork_exit (callout=0x8058fee0 softdep_flush, arg=0x0, frame=0xb49abc50) at /usr/src/sys/kern/kern_fork.c:821 #9 0x80615b0e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:394 #10 0x in ?? () #11 0x in ?? () #12 0x0001 in ?? () #13 0x in ?? () #14 0x in ?? () #15 0x in ?? () #16 0x in ?? () #17 0x in ?? () #18 0x in ?? () #19 0x in ?? () #20 0x in ?? () #21 0x in ?? () #22 0x in ?? () #23 0x in ?? () #24 0x in ?? () #25 0x in ?? () #26 0x in ?? () #27 0x in ?? () #28 0x in ?? () #29 0x in ?? () #30 0x in ?? () #31 0x in ?? () #32 0x in ?? () ---Type return to continue, or q return to quit--- #33 0x in ?? () #34 0x in ?? () #35 0x in ?? () #36 0x in ?? () #37 0x in ?? () #38 0x in ?? () #39 0x in ?? () #40 0x in ?? () #41 0x in ?? () #42 0x00b7d000 in ?? () #43 0x in ?? () #44 0xff002d080600 in ?? () #45 0x in ?? () #46 0xff00785456b0 in ?? () #47 0xff007a9f2000 in ?? () #48 0xb49ab878 in ?? () #49 0xff007a9cd980 in ?? () #50 0x8041ed56 in sched_switch (td=0x0, newtd=0x0, flags=1) at /usr/src/sys/kern/sched_4bsd.c:973 #51 0x in ?? () #52 0x in ?? () #53 0x in
Re: Xen Dom0, are we making progress?
On 3/13/07, Kip Macy [EMAIL PROTECTED] wrote: I know you were working on Xen support in FreeBSD, but web about it (http://www.fsmware.com/xenofreebsd/7.0/STATUS) has one year old info (support planned in FreeBSD 6.1). So is there any progress, or Xen will not be in any near future release? Basically Xen did not mature in the fashion that I anticipated. As far as I can tell it is really only good for server consolidation for large Linux distro vendors. You need to have what amounts to a private branch. The xen developers don't appear to understand the importance of interface versioning. They broke ABI compatibility going from 3.0.2 - 3.0.3 (trivial to fix, but that is not the point). When last I worked on it, they had one branch that was in constant flux and another branch that only received minor bug fixes and was 18 months behind from a functionality standpoint (think 5.x / 4.x). There are numerous other logging / supportability issues that I think are only addressed by the major distros. As it stood 6 months ago, unless you understood the internals of various bits of the code, there was no way of diagnosing failures due to a misconfiguration. This is not to say that it isn't cool technology, but rather that isn't going to be useful for the things I wanted to use it for so my time is being directed elsewhere. If I ever have a need for EC2 I may look at it again. One of the guys who ported FreeBSD to the xbox has expressed interest - so something may yet come of it. I'm happy to provide technical support to an individual who is largely self-sustaining in working on the code. What about implementing something like DragonFly BSD virtual kernels? Matthew Dillon talks about it in is bsdtalk interview: http://cisx1.uma.maine.edu/~wbackman/bsdtalk/bsdtalk098.mp3 I suppose it's sorta like linux compat / windows on windows / coLinux... Towards the end of the interview he talk about it being extremely easy to implement: 1. signal mailboxes. 2. memory map / virtual page table support. 3. vm space management. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Xen Dom0, are we making progress?
- Nikolas Britton [EMAIL PROTECTED] wrote: What about implementing something like DragonFly BSD virtual kernels? Matthew Dillon talks about it in is bsdtalk interview: http://cisx1.uma.maine.edu/~wbackman/bsdtalk/bsdtalk098.mp3 It seems very similar to User Mode Linux, rather than a true VM environment. http://user-mode-linux.sourceforge.net/ Each DragonFlyBSD vkernel runs as a process. I don't know why this is even interesting, for anything but kernel developers. Improving BSD jails to the same level as Solaris Containers (Solaris Containers are Solaris Zones with resource control), would widely useful for many BSD users. In VM environment, like Xen, each VM has its own kernel and possibly different OS. Xen has managed to get a lot of people interested in their VM environment, so there are a lot of OSes that support the Xen architecture. And for those that don't there is early support for booting them by using virtual features in newer CPUs (ex. Windows). Microsoft has joined the Xen bandwagon, even though the core is all open source, as they are threatened in the enterprise space by the VMWare juggernaut, and their Virtual Server/Virtual PC product is so bland, no one cares. UML has been available for longer than Xen, but Xen already outperforms it. I don't see a lot of future in the virtual kernel concept. Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
