Re: trap 12 on 9.0 when memcache gets some load [resolved] ZERO_COPY trap
Andriy Gapon wrote: on 27/03/2012 18:48 Volodymyr Kostyrko said the following: Hi all. I'm just puzzled with this. At first I though this happens because of some memory problems. But now project was moved to another server with some other brands for motherboard/memory and different cpu's. And still once in an hour this happens again: == screenshot current_process = 1935 (memcached) trap number = 12 panic: page fault cpuid = 2 KDB: stack backtrace: #0 0x8038ab38 at kdb_backtrace+0x58 #1 0x80358f80 at panic+0x190 #2 0x80567b15 at trap_fatal+0x395 #3 0x80567ce9 at trap_pfault+0x1c9 #4 0x80567536 at trap+0x3a6 #5 0x80552603 at calltrap+0x8 #6 0x803b2c90 at socow_setup+0xd0 I think that zero-copy sockets are not regarded as a reliable feature. Not an expert, just my two cents. Disabling zero_zopy seems to work as server still runs after 12 hours. Before that one hour was enough to trigger error. kern.ipc.zero_copy.receive: 0 kern.ipc.zero_copy.send: 0 -- Sphinx of black quartz judge my vow. ___ 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
What is actual status of SUJ in 9-STABLE?
Hello, Freebsd-fs. My server crashed today morning due to PSU failure, and now it is checking (in foreground!) 8Tb UFS2+SU volume for 6200 seconds, and it is only Phase 1b (!!!). I don't want even think about background check of this FS. Is SUJ stable enough to migrate to it? It was marked as stable some time ago, and was included into 9-RELEASE, but later I seen some messages on fs@ list, that it still has some problems, and even some references to McKusick's message about this instability (but I've failed to find message itself). BTW, this check reveals many softupdate inconsistences (mostly DUPs), and most of them are in files, which was not written for sure in time of crash (old archives, which could be only read!). -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ 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: What is actual status of SUJ in 9-STABLE?
Use of SU+J use with snapshots is being addressed. Latest update (to 9.0 Stable) was today, please refer to http://lists.freebsd.org/pipermail/svn-src-stable-9/2012-March/001406.html If you mean to use it in production (ie with snapshots), then it is not advisable. Regards, Dewayne. ___ 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
9.0-release panics with ASR_COMPAT and raidutil
Hi, My box panics when I use raidutil tool to turn off write-back for arrays and disks, as advised for database setup (because of no battery) and when getting status. Panic occurs immediately after issuing command 'raidutil -d 0 -w off d0b0t0d0', but sometimes it manages to complete and echo that write-back has been turned off. Several minutes after that it panics anyway, maybe on next disk, maybe on 'raidutil -d 0 -L all' to get information about status, maybe on reboot. Sometimes it panics after only one informational command 'raidutil -d 0 -L all' (immediate and several minutes later). Kernel config: include GENERIC ident CTRL1 options SC_HISTORY_SIZE=2000 options IPFIREWALL options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_FORWARD options DUMMYNET options QUOTA options RACCT options RCTL device smbus device smb device ichsmb device ichwd options ASR_COMPAT raidutil is from port sysutils/asr-utils, ASR_COMPAT is added to kernel config to get it working. Several panic textdumps: http://pastebin.com/pnehc75B http://pastebin.com/NnpijeYJ http://pastebin.com/m8qJPPzD http://pastebin.com/UUUwcFMX http://pastebin.com/bP1BEbzG http://pastebin.com/1CWSEgqL No consistent backtrace among them - all different, so I am not including any in this message. vmcore.* dumps are preserved for a while, so they can be used if needed. I have to say that previously this box was running 7.4-release, and at least informational command 'raidutil -d 0 -L all' did not lead to panic. Any hint to help debugging this issue would be greatly appreciated. -- Best regards, Victor Popov ___ 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
[stable-ish 9] Dell R815 ipmi(4) attach failure
Noting a failure to attach to the onboard IPMI controller with this dell R815. Not sure what to start poking at and thought I'd though this over here for comment. -bash-4.2$ dmesg |grep ipmi ipmi0: KCS mode found at io 0xca8 on acpi ipmi1: IPMI System Interface on isa0 device_attach: ipmi1 attach returned 16 ipmi1: IPMI System Interface on isa0 device_attach: ipmi1 attach returned 16 ipmi0: Timed out waiting for GET_DEVICE_ID -bash-4.2$ sysctl -a|grep ipmi device ipmi# IPMI hw.ipmi.on: 1 dev.ipmi.0.%desc: IPMI System Interface dev.ipmi.0.%driver: ipmi dev.ipmi.0.%location: handle=\_SB_.PCI0.ISA_.NIPM dev.ipmi.0.%pnpinfo: _HID=IPI0001 _UID=5 dev.ipmi.0.%parent: acpi0 ___ 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: ahci hangs on Supermicro MicroCloud second channel
On Thu, 22 Mar 2012, Dmitry Morozovsky wrote: I have received 1.0b from Mar 19, flashed it, but nothing changes regarding disk subsystem; moreover, now kernel is constantly whining about acpi_tz0. Will investigate further. Which version of FreeBSD is this on Dmitry? Just checked our machines here and not seeing anything in /var/log/messages about this, so curious. I'm now testing two blades, one with releng/8, and second with releng/9. Same effect. For the archives: yes, it seems very strange glitch with these blades and WD Caviar Blue AAKX: quick test with Hitachi 3T revieals expected 130+ Mbps throughput. What puzzles me most is that the very same disks work flawlessly on the very same chipset, but different SuperMicro platform. I just ordered another batch of small disks, will test with them. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ 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
FreeBSD 8.3 and 9.0 freeze with firefox
Hi, Starting with 8.3, I've been experiencing FreeBSD freezing up completely after using firefox for a while. Thinking the problem would go away if I upgraded to 9.0, I did that and I am still experiencing the same freezing up. The mouse pointer freezes, the keyboard freezes (caps lock light will not come on; Ctrl-Alt-F[1-10] does not work etc.). The only way to get the system back is by pressing and holding down the power button. The problem seems similar to: kern/163145 There is nothing in /var/log/messages to indicate a problem. Output of pciconf -lv and uname -a are at: http://www.eskimo.com/~joji/wisdom/ Anybody else experiencing similar freeze ups with 8.3 or 9.0 while using firefox? ___ 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: FreeBSD 8.3 and 9.0 freeze with firefox
Hi, On Friday 30 March 2012 09:28:06 Joseph Olatt wrote: Starting with 8.3, I've been experiencing FreeBSD freezing up completely after using firefox for a while. Thinking the problem would go away if I upgraded to 9.0, I did that and I am still experiencing the same freezing up. The mouse pointer freezes, the keyboard freezes (caps lock light will not come on; Ctrl-Alt-F[1-10] does not work etc.). The only way to get the system back is by pressing and holding down the power button. The problem seems similar to: kern/163145 There is nothing in /var/log/messages to indicate a problem. Output of pciconf -lv and uname -a are at: http://www.eskimo.com/~joji/wisdom/ Anybody else experiencing similar freeze ups with 8.3 or 9.0 while using firefox? I use 8.3 and Firefox without problems. What extension did you install? Are they all properly updated? Earlier, it helped deleting firefox' directory in the user directory. Erich ___ 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
LSI MegaRAID SAS 9240 with mfi driver?
Hi,
I have a loan LSI MegaRAID SAS 9240-4i controller for testing.
According to the LSI documentation, this device provides the MegaRAID interface
and the BIOS message mentions MFI. The LSI driver for this device also lists
support for the 9261 which I know is supported by mfi(4). Based on all this, I
was hopeful that mfi(4) would work with the 9240.
The pciconf -lv output is:
none3@pci0:1:0:0: class=0x010400 card=0x92411000 chip=0x00731000 rev=0x03
hdr=0x00
vendor = 'LSI Logic / Symbios Logic'
device = 'MegaRAID SAS 9240'
class = mass storage
subclass = RAID
I added this line to src/sys/dev/mfi/mfi_pci.c
{0x1000, 0x0073, 0x, 0x, MFI_FLAGS_GEN2, LSI MegaRAID SAS
9240},
It gave this result (tried with hw.mfi.msi set to 0 and to 1):
mfi0: LSI MegaRAID SAS 9240 port 0xdc00-0xdcff mem
0xfe7bc000-0xfe7b,0xfe7c-0xfe7f irq 16 at device 0.0 on pci1
mfi0: Using MSI
mfi0: Megaraid SAS driver Ver 3.00
mfi0: Frame 0xff8000285000 timed out command 0x26C8040
mfi0: failed to send init command
The firmware is package 20.10.1-0077, which is the latest on the LSI website.
Is this path likely to work out? Any suggestions on where to go from here?
Thanks,
Jan Mikkelsen
___
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
