Re: 7.2 dies in zfs
On Nov 22, 2009, at 12:34 AM, Randy Bush wrote: Try running FreeBSD 7-Stable to get the latest ZFS version which on FreeBSD is 13 that is what i am running. RELENG_7 I've been following ZFS on FreeBSD long ago, and it really seems to be stable on 8.0/amd64. Even Sun Microsystems say that ZFS is better used on a 64 bit system, they don't recommend it on the 32 bit version of Solaris. That said, there's still an outstanding bug, I managed to deadlock it but the condition is easy to avoid. Borja. ___ 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: 7.2 dies in zfs
On Mon, Nov 23, 2009 at 09:41:43AM +0100, Borja Marcos wrote: On Nov 22, 2009, at 12:34 AM, Randy Bush wrote: Try running FreeBSD 7-Stable to get the latest ZFS version which on FreeBSD is 13 that is what i am running. RELENG_7 I've been following ZFS on FreeBSD long ago, and it really seems to be stable on 8.0/amd64. Even Sun Microsystems say that ZFS is better used on a 64 bit system, they don't recommend it on the 32 bit version of Solaris. That said, there's still an outstanding bug, I managed to deadlock it but the condition is easy to avoid. Please provide details of this deadlock (PR, kernel output, scenario details, etc.), and details of how to avoid it. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: 7.2 dies in zfs
On Nov 23, 2009, at 10:01 AM, Jeremy Chadwick wrote: On Mon, Nov 23, 2009 at 09:41:43AM +0100, Borja Marcos wrote: On Nov 22, 2009, at 12:34 AM, Randy Bush wrote: Try running FreeBSD 7-Stable to get the latest ZFS version which on FreeBSD is 13 that is what i am running. RELENG_7 I've been following ZFS on FreeBSD long ago, and it really seems to be stable on 8.0/amd64. Even Sun Microsystems say that ZFS is better used on a 64 bit system, they don't recommend it on the 32 bit version of Solaris. That said, there's still an outstanding bug, I managed to deadlock it but the condition is easy to avoid. Please provide details of this deadlock (PR, kernel output, scenario details, etc.), and details of how to avoid it. Of course, it's been discussed on freebsd-fs, that's why I didn's cross-post. I'm making a heavy usage of zfs send/receive to keep a replica of a dataset. ZFS can deadlock if you are doing a zfs send and zfs receive (I'm using incremental snapshots) and at the same time you have reading activity on the destination dataset. Imagine this: Machine 1 is the origin, machine 2 is the destination: machine 1: zfs send -i pool/data...@first pool/data...@second | ssh machine2 zfs receive -d pool And while this is running, I have some activity going on with pool/dataset. Easy to replicate if pool/dataset contains /usr/obj and you are doing a make buildworld on the first machine, doing frequent replicas (30 second intervals) while on the second machine you keep a job reading it, I did the tests with a tar process copying the /usr/obj tree to another location. However, if you can ensure that the destination dataset is not read while the zfs receive is working, there is no problem at all, zfs send -i/zfs receives work like a charm, even at 30 second intervals. Borja. ___ 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
Christmas Administrators - Recruitment Support Services
Most of our recruitment clients recognise Christmas time as being the ideal opportunity to undertake an annual clean up of their databases to have their back offices ship shape for the New Year. £45.00 per day This is the cost of a FULL-TIME administrator This is the cost of a FULL-TIME administrator working 8 hrs per day This is the cost of a FULL-TIME administrator working 8 hrs per day with only you as a client Verveoffshore Recruitment Process Outsourcing We offer flexible solutions to fit around your business Kind Regards, Rupesh Agrawal | Manager - Client Services VerveOS2i | India | Phone:+91 20-41056789 Ext. 6712 | E-mail: rupesh.agra...@verveos2i.com | Website: www.verveos2i.com CONFIDENTIALITY DISCLAIMER: This E-mail from VerveOS2i is confidential. It may also be legally privileged. If you are not the intended receiver, you may not copy, reproduce, forward, disclose, disseminate or use any part of it. If you have received this message by slip, delete it and all copies from your system and notify the sender immediately by return E-mail. We do not guarantee the security of Internet communications and are not liable for any errors or omissions. We are a responsible email marketing team and comply with necessary regulations. Most often we buy email lists from opt-in repositories and carry our necessary checks. If this email has come to you by error or if you need us to remove your ID from our emailing list, please reply to this email with REMOVE on the subject line. ___ 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: mfi(4) endless loop kernel output on attach
Did you ever get a resolution for this? The 6.x bugs definitely need
to be fixed. The reported timeouts on 7.x might be due to the adapter
taking a log time to do the command.
Scott
On Oct 22, 2009, at 8:30 AM, pluknet wrote:
2009/10/15 John Baldwin j...@freebsd.org:
On Thursday 15 October 2009 5:51:19 am pluknet wrote:
Hi.
This is 7.2-R. Seen on IBM x3650M2.
During the boot I get those endless looping kernel messages while on
mfi(4) attach phase.
It's getting more odd since 7.2 booted and worked fine on exactly
this
server model
months ago (on different box though).. Any hints?
We just had some boxes die like this (but spewing a different loop
of messages
on boot related to continuously scheduling patrol reads and
consistency
checks that finished immediately) at work. We fixed them by
swapping out the
controller. We might try stick them in a different box and
reflashing them
using mfiutil(8) to see if it's some sort of corrupted state that
flashing
the adapter fixes.
In your case it looks lik the firmware keeps crashing and restarting.
Some more thoughts..
There was a problem I got with 'MegaCli -AdpBbuCmd -BbuLearn -aall'
command.
On 6.2-R process slept on mfiwait wchan:
db bt 14734
Tracing pid 14734 tid 100135 td 0xc93f8190
sched_switch(c93f8190,0,1) at sched_switch+0x143
mi_switch(1,0,c93f8190,f9a32acc,c06a43a4,...) at mi_switch+0x1ba
sleepq_switch(c8c6b0d0) at sleepq_switch+0x87
sleepq_wait(c8c6b0d0,0,c93f8190,c8c6b0d0,c8c25800,...) at sleepq_wait
+0x5c
msleep(c8c6b0d0,c8c25954,4c,c090acbc,0) at msleep+0x269
mfi_wait_command(c8c25800,c8c6b0d0,0,0,cc382460,...) at
mfi_wait_command+0xa8
mfi_ioctl(c8c31300,c1144d01,cc870a00,1,c93f8190,...) at mfi_ioctl
+0x485
devfs_ioctl_f(c90a2750,c1144d01,cc870a00,c9048000,c93f8190) at
devfs_ioctl_f+0xaf
ioctl(c93f8190,f9a32d04) at ioctl+0x445
syscall(3b,3b,3b,0,bfbfedc0,...) at syscall+0x2bf
Xint0x80_syscall() at Xint0x80_syscall+0x1f
--- syscall (54, FreeBSD ELF32, ioctl), eip = 0x8177207, esp =
0xbfbfe88c, ebp = 0xbfbfe8b8 ---
Then:
mfi0: COMMAND 0xc8c6b0d0 TIMEOUT AFTER 51 SECONDS
mfi0: COMMAND 0xc8c61d50 TIMEOUT AFTER 49 SECONDS
mfi0: COMMAND 0xc8c61850 TIMEOUT AFTER 49 SECONDS
On 6.4-R MegaCli throws a page fault due to NULL deref
in mfi_data_cb():cm-cm_sg (see below).
There was past 6.4 backport mentioning
fix some bugs in the API for the management ioctl.
With this patch I have no longer panic and/or locks.
Thanks to LSI now on 7.2-R (and on patched 6.4-R) it returns an error:
# ./MegaCli -AdpBbuCmd -BbuLearn -aall
Adapter 0: BBU Learn Failed
Exit Code: 0x32
db bt
Tracing pid 43059 tid 101363 td 0xcf46e680
mfi_data_cb(c9cfae00,c9cc3e00,1,0) at mfi_data_cb+0x5e
bus_dmamap_load(c9cd7c80,0,caf86270,0,c0597240,c9cfae00,0) at
bus_dmamap_load+0x4a1
mfi_mapcmd(c9cc3800,c9cfae00) at mfi_mapcmd+0x31
mfi_startio(c9cc3800) at mfi_startio+0x9b
mfi_wait_command(c9cc3800,c9cfae00,0,0,caf86270,...) at
mfi_wait_command+0x89
mfi_ioctl(c9cf7200,c1144d01,d3fb6200,1,cf46e680,...) at mfi_ioctl
+0x52a
devfs_ioctl_f(d1a551b0,c1144d01,d3fb6200,cbf52c80,cf46e680) at
devfs_ioctl_f+0xaf
ioctl(cf46e680,fbd91d04) at ioctl+0x445
syscall(3b,3b,3b,0,bfbfedc0,...) at syscall+0x2bf
Xint0x80_syscall() at Xint0x80_syscall+0x1f
--- syscall (54, FreeBSD ELF32, ioctl), eip = 0x8177207, esp =
0xbfbfe88c, ebp = 0xbfbfe8b8
#9 0xc08cbb1a in calltrap () at /usr/src/sys/i386/i386/exception.s:
139
#10 0xc059729e in mfi_data_cb (arg=0xc8a744b0, segs=0xc8a49e00,
nsegs=1,
---Type return to continue, or q return to quit---
error=0) at /usr/src/sys/dev/mfi/mfi.c:1488
#11 0xc08c7afd in bus_dmamap_load (dmat=0xc8a6f100, map=0xac89e000,
buf=0xc8a5ac60, buflen=0, callback=0xc0597240 mfi_data_cb,
callback_arg=0xc8a744b0, flags=0)
at /usr/src/sys/i386/i386/busdma_machdep.c:733
#12 0xc059721d in mfi_mapcmd (sc=0xc8a49800, cm=0xc8a49e00)
at /usr/src/sys/dev/mfi/mfi.c:1452
#13 0xc0597177 in mfi_startio (sc=0xc8a49800)
at /usr/src/sys/dev/mfi/mfi.c:1436
#14 0xc0595f09 in mfi_wait_command (sc=0xc8a49800, cm=0xc8a744b0)
at /usr/src/sys/dev/mfi/mfi.c:822
#15 0xc059840a in mfi_ioctl (dev=0xac89e000, cmd=0, arg=0xc8de8800
, flag=1,
td=0xc8a5ac60) at /usr/src/sys/dev/mfi/mfi.c:2061
#16 0xc06598b7 in devfs_ioctl_f (fp=0xc902dc18, com=3239333121,
data=0xc8de8800, cred=0xc9052980, td=0xc8e2dd00)
at /usr/src/sys/fs/devfs/devfs_vnops.c:480
#17 0xc06d3a11 in ioctl (td=0xc8e2dd00, uap=0xeb37bd04) at file.h:265
(kgdb) f 10
#10 0xc059729e in mfi_data_cb (arg=0xc8a744b0, segs=0xc8a49e00,
nsegs=1,
error=0) at /usr/src/sys/dev/mfi/mfi.c:1488
1488sgl-sg32[i].addr = segs[i].ds_addr;
(kgdb) list
1483return;
1484}
1485
1486if ((sc-mfi_flags MFI_FLAGS_SG64) == 0) {
1487for (i = 0; i nsegs; i++) {
1488sgl-sg32[i].addr = segs[i].ds_addr;
1489sgl-sg32[i].len = segs[i].ds_len;
1490
Re: mfi(4) endless loop kernel output on attach
2009/11/23 Scott Long sco...@samsco.org: Did you ever get a resolution for this? The 6.x bugs definitely need to be fixed. The reported timeouts on 7.x might be due to the adapter taking a log time to do the command. Scott An endless loop kernel output on boot always solved with clearing logs with MegaCli -AdpEventLog -GetEventLogInfo -aAll. As for BBULearn issue, I just tested it again on one of my boxes: # ./MegaCli -AdpBbuCmd -BbuLearn -aall Adapter 0: BBU Learn Succeeded. Exit Code: 0x00 So it seems to work. I see no problems. mfi0: 3748 (312279437s/0x0008/info) - Battery relearn started mfi0: 3749 (312279437s/0x0008/WARN) - BBU disabled; changing WB virtual disks to WT mfi0: 3750 (312279437s/0x0001/info) - Policy change on VD 00/0 to [ID=00,dcp=6d,ccp=6c,ap=0,dc=0,dbgi=0] from [ID=00,dcp=6d,ccp=6d,ap=0,dc=0,dbgi=0] mfi0: 3751 (312279442s/0x0008/info) - Battery is discharging mfi0: 3752 (312279442s/0x0008/info) - Battery relearn in progress On Oct 22, 2009, at 8:30 AM, pluknet wrote: 2009/10/15 John Baldwin j...@freebsd.org: On Thursday 15 October 2009 5:51:19 am pluknet wrote: Hi. This is 7.2-R. Seen on IBM x3650M2. During the boot I get those endless looping kernel messages while on mfi(4) attach phase. It's getting more odd since 7.2 booted and worked fine on exactly this server model months ago (on different box though).. Any hints? We just had some boxes die like this (but spewing a different loop of messages on boot related to continuously scheduling patrol reads and consistency checks that finished immediately) at work. We fixed them by swapping out the controller. We might try stick them in a different box and reflashing them using mfiutil(8) to see if it's some sort of corrupted state that flashing the adapter fixes. In your case it looks lik the firmware keeps crashing and restarting. Some more thoughts.. There was a problem I got with 'MegaCli -AdpBbuCmd -BbuLearn -aall' command. On 6.2-R process slept on mfiwait wchan: db bt 14734 Tracing pid 14734 tid 100135 td 0xc93f8190 sched_switch(c93f8190,0,1) at sched_switch+0x143 mi_switch(1,0,c93f8190,f9a32acc,c06a43a4,...) at mi_switch+0x1ba sleepq_switch(c8c6b0d0) at sleepq_switch+0x87 sleepq_wait(c8c6b0d0,0,c93f8190,c8c6b0d0,c8c25800,...) at sleepq_wait+0x5c msleep(c8c6b0d0,c8c25954,4c,c090acbc,0) at msleep+0x269 mfi_wait_command(c8c25800,c8c6b0d0,0,0,cc382460,...) at mfi_wait_command+0xa8 mfi_ioctl(c8c31300,c1144d01,cc870a00,1,c93f8190,...) at mfi_ioctl+0x485 devfs_ioctl_f(c90a2750,c1144d01,cc870a00,c9048000,c93f8190) at devfs_ioctl_f+0xaf ioctl(c93f8190,f9a32d04) at ioctl+0x445 syscall(3b,3b,3b,0,bfbfedc0,...) at syscall+0x2bf Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x8177207, esp = 0xbfbfe88c, ebp = 0xbfbfe8b8 --- Then: mfi0: COMMAND 0xc8c6b0d0 TIMEOUT AFTER 51 SECONDS mfi0: COMMAND 0xc8c61d50 TIMEOUT AFTER 49 SECONDS mfi0: COMMAND 0xc8c61850 TIMEOUT AFTER 49 SECONDS On 6.4-R MegaCli throws a page fault due to NULL deref in mfi_data_cb():cm-cm_sg (see below). There was past 6.4 backport mentioning fix some bugs in the API for the management ioctl. With this patch I have no longer panic and/or locks. Thanks to LSI now on 7.2-R (and on patched 6.4-R) it returns an error: # ./MegaCli -AdpBbuCmd -BbuLearn -aall Adapter 0: BBU Learn Failed Exit Code: 0x32 db bt Tracing pid 43059 tid 101363 td 0xcf46e680 mfi_data_cb(c9cfae00,c9cc3e00,1,0) at mfi_data_cb+0x5e bus_dmamap_load(c9cd7c80,0,caf86270,0,c0597240,c9cfae00,0) at bus_dmamap_load+0x4a1 mfi_mapcmd(c9cc3800,c9cfae00) at mfi_mapcmd+0x31 mfi_startio(c9cc3800) at mfi_startio+0x9b mfi_wait_command(c9cc3800,c9cfae00,0,0,caf86270,...) at mfi_wait_command+0x89 mfi_ioctl(c9cf7200,c1144d01,d3fb6200,1,cf46e680,...) at mfi_ioctl+0x52a devfs_ioctl_f(d1a551b0,c1144d01,d3fb6200,cbf52c80,cf46e680) at devfs_ioctl_f+0xaf ioctl(cf46e680,fbd91d04) at ioctl+0x445 syscall(3b,3b,3b,0,bfbfedc0,...) at syscall+0x2bf Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x8177207, esp = 0xbfbfe88c, ebp = 0xbfbfe8b8 #9 0xc08cbb1a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #10 0xc059729e in mfi_data_cb (arg=0xc8a744b0, segs=0xc8a49e00, nsegs=1, ---Type return to continue, or q return to quit--- error=0) at /usr/src/sys/dev/mfi/mfi.c:1488 #11 0xc08c7afd in bus_dmamap_load (dmat=0xc8a6f100, map=0xac89e000, buf=0xc8a5ac60, buflen=0, callback=0xc0597240 mfi_data_cb, callback_arg=0xc8a744b0, flags=0) at /usr/src/sys/i386/i386/busdma_machdep.c:733 #12 0xc059721d in mfi_mapcmd (sc=0xc8a49800, cm=0xc8a49e00) at /usr/src/sys/dev/mfi/mfi.c:1452 #13 0xc0597177 in mfi_startio (sc=0xc8a49800) at /usr/src/sys/dev/mfi/mfi.c:1436 #14 0xc0595f09 in mfi_wait_command (sc=0xc8a49800, cm=0xc8a744b0) at /usr/src/sys/dev/mfi/mfi.c:822 #15 0xc059840a in mfi_ioctl (dev=0xac89e000, cmd=0, arg=0xc8de8800 ,
Re: NSIS compile failed on FreeBSD 7.2
If that's indeed the case, then the port Makefile needs to be modified to reject building on any architectures other than i386. This should suffice: ONLY_FOR_ARCHS= i386 If you could file a PR on this matter, the FreeBSD Project folks would likely appreciate it. :-) There isn't actually a FreeBSD port for this project. I was compiling source obtained from the NSIS sourceforge page. -- Matt Wilks Colossians 2:6-7 University of TorontoInformation Security, I+TS (416) 978-3328 m...@madhaus.cns.utoronto.ca 4 Bancroft Ave., Rm. 102 Toronto, ON M5S 1C1 ___ 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: panic in 7.2 (ffs_alloc.c?)
Just a follow-up... The machine was waiting for a manual fsck - this crash seemed to scramble things up pretty good, it hit the jail partition hard and seemed to touch others that were quiet at the time. I'm re-running mstone with an even heavier load to see if I can reproduce this again. Full verbose dmesg: http://pastie.org/711839 Should I bother with a PR or anything on this? Doesn't look like a hardware issue to me. It seems like there could be a nasty bug waiting in the UFS2 code somewhere, does anyone want to persue this at all? I have the dump available for anyone that wants it. Thanks, Charles On Sun, 22 Nov 2009, Charles Sprickman wrote: Howdy, I'm not expert at getting info out of a dump, but I'll do my best to provide some information. This is a Dell PE2970 w/PERC6/i RAID running FreeBSD 7.2/amd64. Brand new box, has been doing very light work for about two weeks. Last night I started a very long mstone run on a jailed mail server and found that quite a way into this burn-in, the box paniced. I was going to put it in service Monday (after punishing it all weekend). Looking for some input on what the root cause is and whether going to a -stable snapshot might be worthwhile. I can tell you there was a good deal of disk activity at the time in the jail - mstone was simulating 100 POP and SMTP clients hitting the machine at once. This is qmail+courier. So messages are coming in, hitting the queue, hitting a user's maildir, getting read and deleted via the POP client over and over again. I do see lots of ffs_* stuff in the backtrace, which is a little scary. Here's my stab at a kgdb session (also @ pastie for easier reading: http://pastie.org/709671): [r...@bigmail /usr/obj/usr/src/sys/BWAY7-64]# kgdb kernel.debug /var/crash/vmcore.0 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: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x12d4b9f5c fault code = supervisor read data, page not present instruction pointer = 0x8:0x8050382e stack pointer = 0x10:0x281a75b0 frame pointer = 0x10:0xff000455f800 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 6324 (vdelivermail) trap number = 12 panic: page fault cpuid = 0 Uptime: 12d0h32m3s Physical memory: 6130 MB Dumping 725 MB: 710 694 678 662 646 630 614 598 582 566 550 534 518 502 486 470 454 438 422 406 390 374 358 342 326 310 294 278 262 246 230 214 198 182 166 150 134 118 102 86 70 54 38 22 6 Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from /boot/kernel/nullfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/nullfs.ko Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/fdescfs.ko #0 doadump () at pcpu.h:195 195 __asm __volatile(movq %%gs:0,%0 : =r (td)); #3 0x8034cba2 in panic (fmt=0x104 Address 0x104 out of bounds) at /usr/src/sys/kern/kern_shutdown.c:574 #4 0x80574823 in trap_fatal (frame=0xff00046c8000, eva=Variable eva is not available. ) at /usr/src/sys/amd64/amd64/trap.c:757 #5 0x80574bf5 in trap_pfault (frame=0x281a7500, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:673 #6 0x80575534 in trap (frame=0x281a7500) at /usr/src/sys/amd64/amd64/trap.c:444 #7 0x8055969e in calltrap () at /usr/src/sys/amd64/amd64/exception.S:209 #8 0x8050382e in ffs_realloccg (ip=0xff00267f75c0, lbprev=0, bprev=6288224785898156086, bpref=593305256, osize=0, nsize=2048, flags=33619968, cred=0xff00927fe800, bpp=0x281a7800) at /usr/src/sys/ufs/ffs/ffs_alloc.c:1349 #9 0x80506e8e in ffs_balloc_ufs2 (vp=0xff0027a64dc8, startoffset=Variable startoffset is not available. ) at /usr/src/sys/ufs/ffs/ffs_balloc.c:692 #10 0x805223e5 in ffs_write (ap=0x281a7a10) at /usr/src/sys/ufs/ffs/ffs_vnops.c:724 #11 0x805a0645 in VOP_WRITE_APV (vop=0x80793d20, a=0x281a7a10) at vnode_if.c:691 #12 0x803dd731 in vn_write (fp=0xff001027cd00, uio=0x281a7b00, active_cred=Variable active_cred is not available. ) at vnode_if.h:373 #13 0x80388768 in dofilewrite (td=0xff00046c8000, fd=5, fp=0xff001027cd00, auio=dwarf2_read_address: Corrupted
Re: 8.0-RC1 NFS client timeout issue
On Tue, 27 Oct 2009, Olaf Seibert wrote: I see an annoying behaviour with NFS over TCP. It happens both with nfs and newnfs. This is with FreeBSD/amd64 8.0-RC1 as client. The server is some Linux or perhaps Solaris, I'm not entirely sure. [good stuff snipped...] Though technically the connection is closed in one direction only, the intention of the server seems clear, and it would be better to be careful and make a new connection right away. I believe that r199293 committed to stable/8 should fix this. It did not make it into FreeBSD8.0, so users of FreeBSD8.0 will need to switch to using udp or apply the patch themselves, if slow reconnects after a non-FreeBSD NFS server are causing them grief. rick ___ 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: HEADS UP: major CAM ATA MFC
On Thu, 2009-11-19 at 22:43 -0500, Alexandre Sunny Kovalenko wrote: On Wed, 2009-11-18 at 01:30 +0200, Alexander Motin wrote: Feedbacks are welcome as always. Works here (ThinkPad X60): ahci0: Intel ICH7M AHCI SATA controller port 0x18d0-0x18d7,0x18c4-0x18c7,0x18c8-0x18cf,0x18c0-0x18c3,0x18b0-0x18bf mem 0xee00-0xee4447ff irq 16 at device 31.2 on pci0 ahci0: [ITHREAD] ahci0: AHCI v1.10 with 4 1.5Gbps ports, Port Multiplier not supported ahcich0: AHCI channel at channel 0 on ahci0 RabbitsDen# camcontrol tags ada0 (pass0:ahcich0:0:0:0): device openings: 32 RabbitsDen# Might be of interest for some other people out there: with this driver, I can suspend/resume my ThinkPad X60 with UP kernel -- the original ATA driver was going into the timeout loop upon resume. -- Alexandre Kovalenko (Олександр Коваленко) ___ 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
Don Wilde wants to connect on LinkedIn
LinkedIn Don Wilde requested to add you as a connection on LinkedIn: -- Dear Valeriy, I'm merging my GMail with Liked-In so I can easily learn more about what's new in your lives. Please accept my humble invitation and feel free to personally reconnect and strengthen the connection! :D - Don Wilde Accept invitation from Don Wilde http://www.linkedin.com/e/2bA_QBNshSoW6_Mg2FRMfzNsaTwKa_DOn-2pAopq/blk/I39742775_4/1BpC5vrmRLoRZcjkkZt5YCpnlOt3RApnhMpmdzgmhxrSNBszYQnPkTdP8QdPAPiiZWd44MblxWiOYPdz8Md3sPe3wLrCBxbOYWrSlI/EML_comm_afe/ View invitation from Don Wilde http://www.linkedin.com/e/2bA_QBNshSoW6_Mg2FRMfzNsaTwKa_DOn-2pAopq/blk/I39742775_4/d5YRdPsOd3sVcQALqnpPbOYWrSlI/svi/ -- DID YOU KNOW you can be the first to know when a trusted member of your network changes jobs? With Network Updates on your LinkedIn home page, you'll be notified as members of your network change their current position. Be the first to know and reach out! http://www.linkedin.com/ -- (c) 2009, LinkedIn Corporation ___ 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
tcpdump/libpcap core dump on amd64.
Hi, I have experience core dump signal 11 using tcpdump in amd64 arch. 8.0-PRERELEASE FreeBSD 8.0-PRERELEASE #14: Tue Nov 24 03:28:14 JST 2009 tcpdump -nvi em2 - no core dump tcpdump -nvi em2 -c 100 - core dump i try in i386 and the result: no coredump here's the core file: 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... Core was generated by `tcpdump'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libpcap.so.7...done. Loaded symbols for /lib/libpcap.so.7 Reading symbols from /lib/libcrypto.so.6...done. Loaded symbols for /lib/libcrypto.so.6 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x000800b244e7 in free () from /lib/libc.so.7 (gdb) bt #0 0x000800b244e7 in free () from /lib/libc.so.7 #1 0x0008006f6a75 in pcap_cleanup_live_common (p=0x800e04400) at /usr/src/lib/libpcap/../../contrib/libpcap/pcap.c:1158 #2 0x0008006f7768 in pcap_cleanup_bpf (p=0x800e04400) at /usr/src/lib/libpcap/../../contrib/libpcap/pcap-bpf.c:1218 #3 0x0008006f65ee in pcap_close (p=0x800e04400) at /usr/src/lib/libpcap/../../contrib/libpcap/pcap.c:1232 #4 0x00452b04 in main (argc=Variable argc is not available. ) at /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1230 thanks! -- -dikshie- ___ 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
