panic: spin lock held too long 8.0-STABLE r207638
iH, Got a system that whenever I launch another Virtualbox instance, it will panic anywhere from 10 minutes to several days. I was able to get this system to panic constantly yesterday by trying to install Windows 2008, or after it was eventually installed, it only ran for ~45 minutes before panic. Some installs panic at around 2% done, most at ~80% and one actually completed. Trying to figure out if it's my hardware or what. I used to have a Windows XP VM running alongside, and the panics happened about once a week - eventually I got lazy and didn't start the XP VM. [less load and no swap usage, and no panics for 1.5 months until yesterday] Yesterday I tried to install Windows 2008, and in the ~6 hours I was messing around, it panicked around 8 times [after random amounts of time] panic: spin lock held too long [cpuid either 2,3, or 4 as far as I remember] 4GB of RAM AMD X4 CPU 8.0-STABLE r207638 amd64 vbox 3.1.6 mostly GENERIC kernel [sched_ule], with firewall/altq compiled in and unneccessary hardware removed from kernel config. With just one VM [FreeBSD 8-stable, 2 CPU 2GB RAM] the system runs fine for months. [it's also a file/print server] As soon as I try to get a Windows VM running on there, and it starts using some swap, anywhere from 20MB to 150MB it eventually panics [usually within an hour or so]. Any ideas ? hardware issues? Anyone successfull in running several VMs on FreeBSD -> VirtualBox ? [overloading it?] ]Peter[ ___ 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"
eclipse-devel caused gdb exited on signal 6 (core dumped)
install eclipse 3.5.2 sucessed from ports and got core dumped. pid 2047 (gdb), uid 1001: exited on signal 6 (core dumped) 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"...(no debugging symbols found)... Core was generated by `gdb'. Program terminated with signal 6, Aborted. Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /lib/libreadline.so.8...(no debugging symbols found)...done. Loaded symbols for /lib/libreadline.so.8 Reading symbols from /lib/libncurses.so.8...(no debugging symbols found)...done. Loaded symbols for /lib/libncurses.so.8 Reading symbols from /usr/lib/libgnuregex.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libgnuregex.so.5 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /usr/lib/libthread_db.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libthread_db.so Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x000800e1226c in kill () from /lib/libc.so.7 (gdb) bt #0 0x000800e1226c in kill () from /lib/libc.so.7 #1 0x000800e1106b in abort () from /lib/libc.so.7 #2 0x004830d5 in safe_strerror () #3 0x004832b9 in internal_verror () #4 0x00483351 in internal_error () #5 0x00522760 in _initialize_svr4_solib () #6 0x00522a40 in _initialize_svr4_solib () #7 0x00492bfe in throw_exception () #8 0x00492c53 in catch_errors () #9 0x0047705f in no_shared_libraries () #10 0x0047724b in solib_add () #11 0x00526f94 in ps_plog () #12 0x00438628 in attach_command () #13 0x00492230 in command_line_input () #14 0x00492bfe in throw_exception () #15 0x00492c53 in catch_errors () #16 0x00492d33 in catch_command_errors () #17 0x004356e5 in gdb_main () #18 0x00492bfe in throw_exception () #19 0x00492c53 in catch_errors () #20 0x00434f84 in gdb_main () #21 0x00434f56 in main () (gdb) # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x000900ac3a00, pid=2042, tid=34372365888 # # JRE version: 6.0-b17 # Java VM: OpenJDK 64-Bit Server VM (14.0-b16 mixed mode bsd-amd64 ) # Problematic frame: # C 0x000900ac3a00 # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --- T H R E A D --- Current thread (0x000801ced800): JavaThread "main" [_thread_in_native, id=12627520, stack(0x7faff000,0x7fbff000)] siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x000900ac3a00 Registers: RAX=0x0001, RBX=0x0001, RCX=0x, RDX=0x0001 RSP=0x7fbfca68, RBP=0x000895da7e00, RSI=0x0002, RDI=0x003f R8 =0x, R9 =0x, R10=0x000895da7e10, R11=0x0008a10f9a10 R12=0x00089e6e7500, R13=0x00089e6e7500, R14=0x0100, R15=0x00089ec34fc0 RIP=0x000900ac3a00, EFL=0x0001, ERR=0x0014 TRAPNO=0x000c Top of Stack: (sp=0x7fbfca68) 0x7fbfca68: 0008a311d331 00089e6e7500 0x7fbfca78: 0100 0001 0x7fbfca88: 000895da7e00 00089e6e7500 0x7fbfca98: 0008a30ef8ff 7fbfccd0 0x7fbfcaa8: 000800ca1940 0001 0x7fbfcab8: 000800d8f800 00089ec34fc0 0x7fbfcac8: 0008a1c8d586 0008a1112688 0x7fbfcad8: 0008a11126bb 0008a11126bb 0x7fbfcae8: 0008a1112680 0008a1112688 0x7fbfcaf8: a11126bb 0008a2625d00 0x7fbfcb08: 7fbfcafc 0008a11126a9 0x7fbfcb18: 00030012 0x7fbfcb28: 0003ffbfcc00 7fbfccd0 0x7fbfcb38: 80070057 0001 0x7fbfcb48: 0008a1c8f2c8 0x7fbfcb58: 7fbfcdc0 000800ca1940 0x7fbfcb68: 0008a25a1f43 ffbfcbe0 0x7fbfcb78: 0008a1112680 0008a2cebbb0 0x7fbfcb88: 0008a2bddb9e 0008a1112680 0x7fbfcb98: 000800d8f800 7fbfcc70 0x7fbfcba8
Re: Freebsd 8.0 kmem map too small
On 5 May 2010, at 15:33, Pawel Jakub Dawidek wrote: > Could you try to track down the commit that is causing your problems? > Could you try 8-STABLE kernel from before r206815? I do suspect something similar like that, and try to roll the kernel back too. I was just fine with 8.0 with zfs-on-root till the last update when my typical workload (portupgrade every now and then, make world) resulted in kmem map too small panics and more sluggish performance (spending most time in zio->io_cv) during pkgdb -F on a i386 system with 2gb memory. I have 1gb memory sized amd64 vmware fusion vm's that run without incident using the same workload. I had to bump KVA_PAGES to 512 and set vm.kmem_size=1024M to have this i386 system stable again. Prior to that I tried to lower the arc cache size but that resulted in a unresponsive system that I could not diagnose. Regards, Ruben ___ 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"
Re: iscsi, zfs, RAIS = Cheap SAN...maybe
Hi! On Thu, 06 May 2010 10:09:33 +0100 Michal wrote: > Many thanks...even if you just read this beast of an e-mail This is not an answer to your questions but my tiny experience in this area. I created two USB 2G storages with FreeBSD current i386: node001 and node002. Each system has one 250G hard disk. Both nodes export their disks via iscsi: - node001% sudo istgtcontrol list lun0 storage "/dev/ad0" 250059350016 DONE LIST command - node002% sudo istgtcontrol list lun0 storage "/dev/ad4" 250059350016 DONE LIST command - I used my workstation as a controller. And since it's an i386 (FreeBSD-CURRENT) I didn't try zfs but created a gmirror: - da0 at iscsi0 bus 0 scbus7 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) da1 at iscsi0 bus 0 scbus7 target 1 lun 0 da1: Fixed Direct Access SCSI-5 device da1: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) GEOM_MIRROR: Device mirror/storage0 launched (2/2). - bsam% gmirror status NameStatus Components mirror/storage0 COMPLETE da0 da1 bsam% mount -p | grep storage /dev/mirror/storage0/storageufs rw 2 2 - While using 100Mb/s network connection I've got 7-8 MB/s writes (after some sysctl tuning, 3-4 MB/s without). And switching to 1Gb/s network connection (Intel Gigabit Ethernet Controllers) gave me something like 20 Mb/s writes (no tuning): - bsam% dd if=/dev/zero of=/storage/file.2G bs=1M count=2000 2000+0 records in 2000+0 records out 2097152000 bytes transferred in 108.479201 secs (19332296 bytes/sec) bsam% netstat -w10 input(Total) output packets errs idrops bytespackets errs bytes colls 21 0 0 1658 9 0582 0 44 0 0 5425 35 0 3014 0 70470 0 05640905 114909 0 184072616 0 157670 0 0 11966753 257062 0 390774311 0 175056 0 0 11951631 285343 0 390099162 0 156502 0 0 11867216 255072 0 387223400 0 174907 0 0 11947580 285064 0 390607312 0 155607 0 0 11800874 253530 0 385202710 0 173359 0 0 11835884 282798 0 386524530 0 157604 0 0 11922283 256966 0 389324902 0 174224 0 0 11919850 284396 0 390212650 0 173677 0 0 11853356 283110 0 386944770 0 174934 0 0 11932229 285361 0 389785504 0 69574 0 04584810 113056 0 148735429 0 282 0 0 22196374 0 452062 0 20 0 0 2054 14 0 2473 0 - node001% netstat -w10 input(Total) output packets errs idrops bytespackets errs bytes colls 12 0 0 1008 1 0178 0 17 0 0 1626 2 0292 0 60498 0 0 88413959 37258 02616474 0 139627 0 0 204095754 86076 06064930 0 139188 0 0 203450154 85816 06047488 0 138486 0 0 202411672 85363 06000534 0 139258 0 0 203561033 85848 06049360 0 137636 0 0 201181818 84866 05981524 0 138262 0 0 202064896 85169 06004090 0 139297 0 0 203633800 85829 06031458 0 138884 0 0 203011098 85495 06025390 0 138280 0 0 202089488 85166 06004198 0 139272 0 0 203583962 85828 06047758 0 58465 0 0 85346106 36192 02545632 0 193 0 0 236228132 0 10360 0 - node002% netstat -w10 input(Total) output packets errs idrops bytespackets errs bytes colls 12 0 0 1008 1 0178 0 16 0 0 1566 2 0292 0 73703 0 0 107730061 44956 03134984 0 139420 0 0 203862166 85058 05899360 0 139295 0 0 203674472 85024 05896468 0 138129 0 0 201945040 84345 05850658 0 139068 0 0 203351261 84873 05886130 0 138214 0 0 202097218 84293 05846170 0 137860 0 0 201540738 84120 05835754 0 138751 0 0 202889156 84668 05871694 0 139260 0 0 203626362 84907 0554 0 138468 0 0 202435390 84534 05863900 0
iscsi, zfs, RAIS = Cheap SAN...maybe
*I apologise about the length of this e-mail, I tried to cover all details*
I am following up on a previous post which is here
http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2010-03/msg00392.html
The sum up my end goal is this;
"To have a SAN type system where I have multiple servers that contain
multiple disks. I can lose a server and due to RAID1 across the servers,
the data will still be on the network, IO will increase due to their
being multiple servers to read from simultaneously as opposed to one NAS
box and lastly to be able to add new servers to the system to increase
the storage (to the end users the amount of available space increases).
Stage one is to create a two server system that can take a failure of a
server. Second stage is to get better IO from two servers then from one
NAS box. Last stage is to have all that and the ability to easily add
more storage"
I have created 3 (not great spec just some spear) servers, two of which
have 2 HDD's each and I will call storedevice1 and storedevice2 these
are my devices that will hold the data. My 3rd server is my controller
which controls the devices. Each server has two hard drives which using
iscsi-target I export as data0 and data1 and in the controller I use the
iscsi-initiator to connect to these 4 HDD's. Here is the config files
storedevice1:
#cat /usr/local/etc/iscsi/targets
# extents filestart length
#extent0/tmp/iscsi-target0 0 100MB
extent0 /data0/data 0 28GB
extent1 /data1/data 0 28GB
# targetflags storage netmask
target0 rw extent0 192.168.2.0/24
target1 rw extent1 192.168.2.0/24
# ls -lh /data0/
total 2195442
drwxrwxr-x 2 root operator 512B Apr 20 17:49 .snap
-rw-r--r-- 1 root wheel 28G May 5 21:37 data
# ls -lh /data1/
total 2195442
drwxrwxr-x 2 root operator 512B Apr 22 13:27 .snap
-rw-r--r-- 1 root wheel 28G May 5 21:37 data
storedevice2:
#cat /usr/local/etc/iscsi/targets
# extents filestart length
extent2 /data0/data 0 28GB
extent3 /data1/data 0 28GB
# targetflags storage netmask
target2 rw extent2 192.168.2.0/24
target3 rw extent3 192.168.2.0/24
# ls -lh /data0/
total 2191250
drwxrwxr-x 2 root operator 512B Apr 22 15:09 .snap
-rw-r--r-- 1 root wheel 28G May 5 21:37 data
# ls -lh /data1/
total 2191250
drwxrwxr-x 2 root operator 512B Apr 22 17:40 .snap
-rw-r--r-- 1 root wheel 28G May 5 21:37 data
which gives me 4 extents and 4 targets accross both. /dataX/data is a
file which I think it needs to be (???)
On my controller I have;
OffSanCtrl1# cat /etc/iscsi.conf
offsan0 {
TargetName = iqn.1994-04.org.netbsd.iscsi-target:target0
TargetAddress = 192.168.2.160:3260,1
}
offsan1 {
TargetName = iqn.1994-04.org.netbsd.iscsi-target:target1
TargetAddress = 192.168.2.160:3260,1
}
offsan2 {
TargetName = iqn.1994-04.org.netbsd.iscsi-target:target2
TargetAddress = 192.168.2.161:3260,1
offsan3 {
TargetName = iqn.1994-04.org.netbsd.iscsi-target:target3
TargetAddress = 192.168.2.161:3260,1
}
which is my initiator and connects to my 4 targets
Up to this point I think I am doing everything correctly. I then setup a
zpool on the controller
OffSanCtrl1# zpool status
pool: store0
state: ONLINE
scrub: none requested
config:
NAMESTATE READ WRITE CKSUM
store0 ONLINE 0 0 0
mirrorONLINE 0 0 0
da1s1d ONLINE 0 0 0
da3s1d ONLINE 0 0 0
mirrorONLINE 0 0 0
da2s1d ONLINE 0 0 0
da4s1d ONLINE 0 0 0
errors: No known data errors
with da1s1d and da2s1d being from storedevice1 and da3s1d and da4s1d
from storedevice2 so if I am correct this should be a a sort of RAID10
(anything that could be done better please tell me).
I now set-up zfs on this zpool (again, I think I'm doing this the right way)
OffSanCtrl1# zfs list
NAME USED AVAIL REFER MOUNTPOINT
store04.12G 50.5G19K /store0
store0/users 4.12G 50.5G 4.12G /store0/users
Lastly, I need to be able to allow network users/servers to connect to
this. My choices I think are iscsi and samba as I have *nix and windows
machines, so I'll try iscsi. From the controller, create a target from
the zfs mount point I have created. If I am correct, a user should be
able to connect to the target from the controller, write data which will
actually be writing data across both storedevice's
OffSanCtrl1# cat /usr/local/etc/iscsi/targets
# extents filestart length
extent0 /store0/users/data 0
