Re: RELENG_9 panic with PERC 6/i (mfi)
> Greetings. > > I have a Dell R710 with a mfi device (PERC 6/i Integrated) that panics almost > immediately on FreeBSD 9. It works fine on FreeBSD 8.2-RELEASE, but I've now > had it panic in FreeBSD 9.0-STABLE and 9.1-RELEASE. > > Output of mfiutil show adapter and panic backtrace below. Anybody seen this > or have any ideas? > > # mfiutil show adapter: > mfi0 Adapter: > Product Name: PERC 6/i Integrated >Serial Number: > Firmware: 6.3.1-0003 > RAID Levels: JBOD, RAID0, RAID1, RAID5, RAID6, RAID10, RAID50 > Battery Backup: present >NVRAM: 32K > Onboard Memory: 256M > Minimum Stripe: 8K > Maximum Stripe: 1M > > # kgdb -n 5 > panic: kmem_malloc(-8192): kmem_map too small: 82677760 total allocated > cpuid = 2 > KDB: stack backtrace: > #0 0x809208a6 at kdb_backtrace+0x66 > #1 0x808ea8be at panic+0x1ce > #2 0x80b44930 at vm_map_locked+0 > #3 0x80b3b41a at uma_large_malloc+0x4a > #4 0x808d5a69 at malloc+0xd9 > #5 0x805b2985 at mfi_user_command+0x35 > #6 0x805b2f2d at mfi_ioctl+0x2fd > #7 0x807db28b at devfs_ioctl_f+0x7b > #8 0x80932325 at kern_ioctl+0x115 > #9 0x8093255d at sys_ioctl+0xfd > #10 0x80bd7ae6 at amd64_syscall+0x546 > #11 0x80bc3447 at Xfast_syscall+0xf7 > Uptime: 35s > Dumping 2032 out of 49122 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% > > (kgdb) lis *0x805b2985 > 0x805b2985 is in mfi_user_command (/usr/src/sys/dev/mfi/mfi.c:2836). > 2831 int error = 0, locked; > 2832 > 2833 > 2834 if (ioc->buf_size > 0) { > 2835 ioc_buf = malloc(ioc->buf_size, M_MFIBUF, M_WAITOK); > 2836 if (ioc_buf == NULL) { > 2837 return (ENOMEM); > 2838 } > 2839 error = copyin(ioc->buf, ioc_buf, ioc->buf_size); > 2840 if (error) { > I just upgraded such a box to 9.1-PRERELEASE, can you tell me how to panicit, because so far all seems ok: store-02> uname -aFreeBSD store-02 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #27: Fri Dec 21 09:11:51 IST 2012 danny@rnd:/home/obj/rnd/r+d/stable/9/sys/HUJI amd64 store-02> mfiutil -u 1 show adapter mfi1 Adapter: Product Name: PERC 6/E Adapter Serial Number: 1122334455667788 Firmware: 6.3.1-0003 RAID Levels: JBOD, RAID0, RAID1, RAID5, RAID6, RAID10, RAID50 Battery Backup: present NVRAM: 32K Onboard Memory: 512M Minimum Stripe: 8k Maximum Stripe: 1M store-02> gpart show => 34 29297213373 mfid0 GPT (13T) 34 128 1 freebsd-boot (64k) 162 4194304 2 freebsd-ufs [bootme] (2.0G) 4194466100663296 3 freebsd-swap (48G) 104857762 29192355645 4 freebsd-zfs (13T) store-02> zpool status pool: h state: ONLINE status: The pool is formatted using a legacy on-disk format. The pool can still be used, but some features are unavailable. action: Upgrade the pool using 'zpool upgrade'. Once this is done, the pool will no longer be accessible on software that does not support feature flags. scan: scrub repaired 0 in 7h21m with 0 errors on Wed Oct 24 22:57:31 2012 config: NAME STATE READ WRITE CKSUM h ONLINE 0 0 0 gptid/1ef2d5a2-daef-11e1-944e-d067e5e8228e ONLINE 0 0 0 errors: No known data errors ___ 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"
RELENG_9 panic with PERC 6/i (mfi)
Greetings. I have a Dell R710 with a mfi device (PERC 6/i Integrated) that panics almost immediately on FreeBSD 9. It works fine on FreeBSD 8.2-RELEASE, but I've now had it panic in FreeBSD 9.0-STABLE and 9.1-RELEASE. Output of mfiutil show adapter and panic backtrace below. Anybody seen this or have any ideas? # mfiutil show adapter: mfi0 Adapter: Product Name: PERC 6/i Integrated Serial Number: Firmware: 6.3.1-0003 RAID Levels: JBOD, RAID0, RAID1, RAID5, RAID6, RAID10, RAID50 Battery Backup: present NVRAM: 32K Onboard Memory: 256M Minimum Stripe: 8K Maximum Stripe: 1M # kgdb -n 5 panic: kmem_malloc(-8192): kmem_map too small: 82677760 total allocated cpuid = 2 KDB: stack backtrace: #0 0x809208a6 at kdb_backtrace+0x66 #1 0x808ea8be at panic+0x1ce #2 0x80b44930 at vm_map_locked+0 #3 0x80b3b41a at uma_large_malloc+0x4a #4 0x808d5a69 at malloc+0xd9 #5 0x805b2985 at mfi_user_command+0x35 #6 0x805b2f2d at mfi_ioctl+0x2fd #7 0x807db28b at devfs_ioctl_f+0x7b #8 0x80932325 at kern_ioctl+0x115 #9 0x8093255d at sys_ioctl+0xfd #10 0x80bd7ae6 at amd64_syscall+0x546 #11 0x80bc3447 at Xfast_syscall+0xf7 Uptime: 35s Dumping 2032 out of 49122 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% (kgdb) lis *0x805b2985 0x805b2985 is in mfi_user_command (/usr/src/sys/dev/mfi/mfi.c:2836). 2831 int error = 0, locked; 2832 2833 2834 if (ioc->buf_size > 0) { 2835 ioc_buf = malloc(ioc->buf_size, M_MFIBUF, M_WAITOK); 2836 if (ioc_buf == NULL) { 2837 return (ENOMEM); 2838 } 2839 error = copyin(ioc->buf, ioc_buf, ioc->buf_size); 2840 if (error) { ___ 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: 9.1 minimal ram requirements
Hi guys, Would someone please file a PR for this? This is a huge unused allocation of memory for something that honestly likely shouldn't have been included by default in GENERIC. I've cc'ed ken on a reply to this. Hopefully after the holidays he can chime in and figure out what's going on. Maybe just disabling it in GENERIC moving forward is enough - chances are it'll be fine being just a module. Thanks, Adrian On 22 December 2012 16:45, Sergey Kandaurov wrote: > On 23 December 2012 03:40, Marten Vijn wrote: >> On 12/23/2012 12:27 AM, Jakub Lach wrote: >>> >>> Guys, I've heard about some absurd RAM requirements >>> for 9.1, has anybody tested it? >>> >>> e.g. >>> >>> http://forums.freebsd.org/showthread.php?t=36314 >> >> >> jup, I can comfirm this with nanobsd (cross) compiled >> for my soekris net4501 which has 64 MB mem: >> >> from dmesg: real memory = 67108864 (64 MB) >> >> while the same config compiled against a 9.0 tree still works... >> > > This (i.e. the "kmem_map too small" message seen with kernel memory > shortage) could be due to CAM CTL ('device ctl' added in 9.1), which is > quite a big kernel memory consumer. > Try to disable CTL in loader with kern.cam.ctl.disable=1 to finish boot. > A longer term workaround could be to postpone those memory allocations > until the first call to CTL. > > # cam ctl init allocates roughly 35 MB of kernel memory at once > # three memory pools, somewhat under M_DEVBUF, and memory disk > # devbuf takes 1022K with kern.cam.ctl.disable=1 > > Type InUse MemUse HighUse Requests Size(s) >devbuf 213 20366K - 265 > 16,32,64,128,256,512,1024,2048,4096 >ctlmem 5062 10113K - 5062 64,2048 >ctlblk 200 800K - 200 4096 > ramdisk 1 4096K -1 > ctlpool 532 138K - 532 16,512 > > -- > wbr, > pluknet > ___ > 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-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: 9.1 minimal ram requirements
Ken, Does CAM CTL really need to pre-allocate 35MB of RAM at startup? Adrian On 22 December 2012 16:45, Sergey Kandaurov wrote: > On 23 December 2012 03:40, Marten Vijn wrote: >> On 12/23/2012 12:27 AM, Jakub Lach wrote: >>> >>> Guys, I've heard about some absurd RAM requirements >>> for 9.1, has anybody tested it? >>> >>> e.g. >>> >>> http://forums.freebsd.org/showthread.php?t=36314 >> >> >> jup, I can comfirm this with nanobsd (cross) compiled >> for my soekris net4501 which has 64 MB mem: >> >> from dmesg: real memory = 67108864 (64 MB) >> >> while the same config compiled against a 9.0 tree still works... >> > > This (i.e. the "kmem_map too small" message seen with kernel memory > shortage) could be due to CAM CTL ('device ctl' added in 9.1), which is > quite a big kernel memory consumer. > Try to disable CTL in loader with kern.cam.ctl.disable=1 to finish boot. > A longer term workaround could be to postpone those memory allocations > until the first call to CTL. > > # cam ctl init allocates roughly 35 MB of kernel memory at once > # three memory pools, somewhat under M_DEVBUF, and memory disk > # devbuf takes 1022K with kern.cam.ctl.disable=1 > > Type InUse MemUse HighUse Requests Size(s) >devbuf 213 20366K - 265 > 16,32,64,128,256,512,1024,2048,4096 >ctlmem 5062 10113K - 5062 64,2048 >ctlblk 200 800K - 200 4096 > ramdisk 1 4096K -1 > ctlpool 532 138K - 532 16,512 > > -- > wbr, > pluknet > ___ > 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-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: 9.1 minimal ram requirements
On Sun, 23 Dec 2012 03:45:39 +0300, Sergey Kandaurov wrote: > On 23 December 2012 03:40, Marten Vijn wrote: > > On 12/23/2012 12:27 AM, Jakub Lach wrote: > >> > >> Guys, I've heard about some absurd RAM requirements > >> for 9.1, has anybody tested it? > >> > >> e.g. > >> > >> http://forums.freebsd.org/showthread.php?t=36314 > > > > > > jup, I can comfirm this with nanobsd (cross) compiled > > for my soekris net4501 which has 64 MB mem: > > > > from dmesg: real memory = 67108864 (64 MB) > > > > while the same config compiled against a 9.0 tree still works... Same as the first message in that forum thread, I tried installing from i386 9.1-RC3 memstick on a PIII-M with 128MB RAM (Thinkpad T23) and it panics just a few percent into extracting base.txz, much to my surprise. I had a 256MB stick and was going to try that instead, but was in a bit of a hurry so just added it for 384MB and have had no further trouble, but haven't done anything much with it yet, no X or other packages. However the same forum user 'Zav' later reports the same panic at 2.5d uptime with 320MB, after earlier panics with 192MB post-installation when 'trying to do something', so I'm wondering if even 256MB is enough for 9.1? .. scratch my ambition to upgrade an older maxed-out 160MB laptop that runs fine on 5.5 w/X, KDE and all, albeit using some swap. > This (i.e. the "kmem_map too small" message seen with kernel memory > shortage) could be due to CAM CTL ('device ctl' added in 9.1), which is > quite a big kernel memory consumer. > Try to disable CTL in loader with kern.cam.ctl.disable=1 to finish boot. I've just added that, thanks Sergey, but it's sadly not an option for installation. I guess it's too late for the release notes - which at RC3 made no mention of CAM CTL at all - but it's not yet clear to me whether even 256MB is enough to boot, install and run 9.1 GENERIC? > A longer term workaround could be to postpone those memory allocations > until the first call to CTL. Under what circumstances is CAM CTL needed? What would leaving it out of GENERIC cost, and whom? Is it loadable? dmesg.boot reports loading, but I don't see a module, nor can I find much information about CTL in cam(3|4) or /sys/conf/NOTES. apropos found ctladm and ctlstat, but I'm little the wiser as to when it may be needed, beyond CAM/SCSI debugging? > # cam ctl init allocates roughly 35 MB of kernel memory at once > # three memory pools, somewhat under M_DEVBUF, and memory disk > # devbuf takes 1022K with kern.cam.ctl.disable=1 > > Type InUse MemUse HighUse Requests Size(s) >devbuf 213 20366K - 265 > 16,32,64,128,256,512,1024,2048,4096 >ctlmem 5062 10113K - 5062 64,2048 >ctlblk 200 800K - 200 4096 > ramdisk 1 4096K -1 > ctlpool 532 138K - 532 16,512 > > -- > wbr, > pluknet cheers, Ian ___ 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: 9.1 minimal ram requirement
> Guys, I've heard about some absurd RAM requirements > for 9.1, has anybody tested it? I prepared old laptop for something else and tried live cd image out. It took some time to load and I was surprised how slowly it went. Laptop has 128 mb or ram and might be a bit old to compare. I removed hdd and dmesg has shown nothing special. Once booted, it often touched cd drive. I didn't pay attention to ctl device. What could happen if it is moved from kernel? Btw, I write this from another account, since freebsd.org made service unavailable: (reason: 550-5.7.1 Service unavailable; client [89.216.2.35] blocked using b +.barracudacentral.org Best regards Zoran ___ 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: 9.1 minimal ram requirements
On 23 December 2012 03:40, Marten Vijn wrote: > On 12/23/2012 12:27 AM, Jakub Lach wrote: >> >> Guys, I've heard about some absurd RAM requirements >> for 9.1, has anybody tested it? >> >> e.g. >> >> http://forums.freebsd.org/showthread.php?t=36314 > > > jup, I can comfirm this with nanobsd (cross) compiled > for my soekris net4501 which has 64 MB mem: > > from dmesg: real memory = 67108864 (64 MB) > > while the same config compiled against a 9.0 tree still works... > This (i.e. the "kmem_map too small" message seen with kernel memory shortage) could be due to CAM CTL ('device ctl' added in 9.1), which is quite a big kernel memory consumer. Try to disable CTL in loader with kern.cam.ctl.disable=1 to finish boot. A longer term workaround could be to postpone those memory allocations until the first call to CTL. # cam ctl init allocates roughly 35 MB of kernel memory at once # three memory pools, somewhat under M_DEVBUF, and memory disk # devbuf takes 1022K with kern.cam.ctl.disable=1 Type InUse MemUse HighUse Requests Size(s) devbuf 213 20366K - 265 16,32,64,128,256,512,1024,2048,4096 ctlmem 5062 10113K - 5062 64,2048 ctlblk 200 800K - 200 4096 ramdisk 1 4096K -1 ctlpool 532 138K - 532 16,512 -- wbr, pluknet ___ 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: 9.1 minimal ram requirements
On 12/23/2012 12:27 AM, Jakub Lach wrote: Guys, I've heard about some absurd RAM requirements for 9.1, has anybody tested it? e.g. http://forums.freebsd.org/showthread.php?t=36314 jup, I can comfirm this with nanobsd (cross) compiled for my soekris net4501 which has 64 MB mem: from dmesg: real memory = 67108864 (64 MB) while the same config compiled against a 9.0 tree still works... cheers Marten -- View this message in context: http://freebsd.1045724.n5.nabble.com/9-1-minimal-ram-requirements-tp5771583.html Sent from the freebsd-stable mailing list archive at Nabble.com. ___ 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-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.1 minimal ram requirements
Guys, I've heard about some absurd RAM requirements for 9.1, has anybody tested it? e.g. http://forums.freebsd.org/showthread.php?t=36314 -- View this message in context: http://freebsd.1045724.n5.nabble.com/9-1-minimal-ram-requirements-tp5771583.html Sent from the freebsd-stable mailing list archive at Nabble.com. ___ 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: xz(1) keeps SEGFAULT-ing
On 22.12.2012 11:39, Adrian Chadd wrote: Is it dumping core? Yes, and, as I type this, I'm trying to reproduce the crash using the version of liblzma.so.5 compiled with "-O0 -g" (under valgrind). So far (25%) everything is clean and valgrind has no complaints either. Yours, -mi Following xz's fault, all other processes (dump, ccrypt, sh) dump their cores to, but, according to dmesg, the culprit is always xz.*According to core, the fault is somewhere inside liblzma.so.5*. I recompiled the library to enable debugging and am trying to investigate, but, perhaps, someone has already run into this? ___ 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: ipv6_addrs_IF aliases in rc.conf(5)
W dniu 2012-12-22 18:14, Ben Morrow pisze: > Quoth =?UTF-8?B?xYF1a2FzeiBXxIVzaWtvd3NraQ==?= : >> W dniu 2012-12-22 04:41, Kimmo Paasiala pisze: >> >>> Yeah, this is problem in network.subr. An interface is not recognized >>> as IPv6 capable if the interface is not in "ipv6_network_interfaces" >>> and there's no "ifconfig_IF_ipv6" in rc.conf(5), bummer. For IPv4 it >>> "just works" because the interface is always assumed to be IPv4 >>> capable. >> >> Ok, I used ifconfig_em0_ipv6="up" and it worked. So it looks like this: > > The documented way to do this is to just set the link-local address in > ifconfig_IF_ipv6, since an interface is required to have a link-local > address. Either configure an fe80:: address explicitly or set > > ifconfig_em0_ipv6="inet6 auto_linklocal" > > Alternatively, if you set ipv6_activate_all_interfaces all interfaces > will be considered IPv6-capable. link-local address is assigned by default, even with ifconfig_IF_ipv6="up". root@freebsd:~ # grep -Ev '^[[:space:]]*#|^$' /etc/rc.conf ; ifconfig em0 | grep -E '^[[:space:]]*inet6' | head -2 hostname="freebsd" ifconfig_em0="up" ipv4_addrs_em0="192.168.168.20-24/24" defaultrouter="192.168.168.1" ipv6_network_interfaces="em0" ipv6_defaultrouter="2001:6a0:1cb::" ifconfig_em0_ipv6="up" ipv6_addrs_em0="2001:6a0:1cb::1-e/128" sshd_enable="YES" dumpdev="NO" named_enable="YES" inet6 fe80::a00:27ff:fe02:8371%em0 prefixlen 64 scopeid 0x1 inet6 2001:6a0:1cb::1 prefixlen 128 Of course using "inet6 auto_linklocal" instead of "up" seems a better way to do it, thank you for this tip. -- best regards, Lukasz Wasikowski ___ 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: ipv6_addrs_IF aliases in rc.conf(5)
Quoth =?UTF-8?B?xYF1a2FzeiBXxIVzaWtvd3NraQ==?= : > W dniu 2012-12-22 04:41, Kimmo Paasiala pisze: > > > Yeah, this is problem in network.subr. An interface is not recognized > > as IPv6 capable if the interface is not in "ipv6_network_interfaces" > > and there's no "ifconfig_IF_ipv6" in rc.conf(5), bummer. For IPv4 it > > "just works" because the interface is always assumed to be IPv4 > > capable. > > Ok, I used ifconfig_em0_ipv6="up" and it worked. So it looks like this: The documented way to do this is to just set the link-local address in ifconfig_IF_ipv6, since an interface is required to have a link-local address. Either configure an fe80:: address explicitly or set ifconfig_em0_ipv6="inet6 auto_linklocal" Alternatively, if you set ipv6_activate_all_interfaces all interfaces will be considered IPv6-capable. Ben ___ 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: xz(1) keeps SEGFAULT-ing
Is it dumping core? Adrian On 22 December 2012 07:07, Mikhail T. wrote: > Hello! > > I've set up several nightly backups all using the pipe-chain of dump | xz -9 > | ccrypt > /remote/backups/fs.xz.cpt > > On one system these just work every night without a problem. On another I > see xz SEGFAULT-ing about 90% through almost every night for one of the > filesystems (the bigger of the two). This is, what cron emails me: > > DUMP: WARNING: should use -L when dumping live read-write filesystems! > DUMP: Date of this level 1 dump: Sat Dec 22 03:23:00 2012 > DUMP: Date of last level 0 dump: Thu Dec 6 01:23:02 2012 > DUMP: Dumping /dev/ad4s1g (/home) to standard output > DUMP: mapping (Pass I) [regular files] > DUMP: Cache 16 MB, blocksize = 65536 > DUMP: mapping (Pass II) [directories] > DUMP: estimated 2157823 tape blocks. > DUMP: dumping (Pass III) [directories] > DUMP: dumping (Pass IV) [regular files] > DUMP: 11.50% done, finished in 0:38 at Sat Dec 22 04:07:55 2012 > DUMP: 17.80% done, finished in 0:46 at Sat Dec 22 04:20:37 2012 > DUMP: 24.32% done, finished in 0:46 at Sat Dec 22 04:26:05 2012 > DUMP: 31.23% done, finished in 0:44 at Sat Dec 22 04:28:27 2012 > DUMP: 36.16% done, finished in 0:44 at Sat Dec 22 04:33:34 2012 > DUMP: 43.21% done, finished in 0:39 at Sat Dec 22 04:33:51 2012 > DUMP: 54.86% done, finished in 0:28 at Sat Dec 22 04:28:14 2012 > DUMP: 60.63% done, finished in 0:25 at Sat Dec 22 04:30:24 2012 > DUMP: 65.83% done, finished in 0:23 at Sat Dec 22 04:32:47 2012 > DUMP: 70.54% done, finished in 0:20 at Sat Dec 22 04:35:18 2012 > DUMP: 75.15% done, finished in 0:18 at Sat Dec 22 04:37:37 2012 > DUMP: 80.28% done, finished in 0:14 at Sat Dec 22 04:39:10 2012 > DUMP: 85.57% done, finished in 0:10 at Sat Dec 22 04:40:23 2012 > DUMP: 90.50% done, finished in 0:07 at Sat Dec 22 04:41:46 2012 > DUMP: SIGSEGV: ABORTING! > DUMP: DUMP: DUMP: SIGSEGV: ABORTING! >SIGSEGV: ABORTING! >SIGSEGV: ABORTING! > DUMP: SIGSEGV: ABORTING! > > Following xz's fault, all other processes (dump, ccrypt, sh) dump their > cores to, but, according to dmesg, the culprit is always xz. According to > core, the fault is somewhere inside liblzma.so.5. I recompiled the library > to enable debugging and am trying to investigate, but, perhaps, someone has > already run into this? > > Both systems used to run FreeBSD-8/amd64, when I first set the jobs up. I > have since upgraded the troublesome server to 9.1, but that did not fix the > problem. > > The remote filesystem (where ccrypt writes encrypted output) is mounted via > smbfs on both servers, but I doubt that matters... > > Any ideas? Thanks, > >-mi > > ___ > 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-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: ipv6_addrs_IF aliases in rc.conf(5)
On Sat, Dec 22, 2012 at 4:25 PM, Łukasz Wąsikowski wrote: > W dniu 2012-12-22 04:41, Kimmo Paasiala pisze: > It looks like the reason for the difference to ipv4_addrs_IF is that the "alias" parameter for ifconfig(8) operates differently for IPv6 addresses, the first address of an interface can't be added with "alias", for IPv4 it does not care. I'll have to dig deeper but that's what the problem seems to be. -Kimmo >>> >>> The 'alias' parameter of ifconfig(8) is not the problem on the first >>> ipv6 address, I have verified that. However, there's probably >>> something in network.subr or /etc/rc.d/netif that I have overlooked >>> and causes my code to be skipped if there's no ifconfig_IF_ipv6 >>> variable defined in rc.conf(5). >>> >>> -Kimmo >> >> Yeah, this is problem in network.subr. An interface is not recognized >> as IPv6 capable if the interface is not in "ipv6_network_interfaces" >> and there's no "ifconfig_IF_ipv6" in rc.conf(5), bummer. For IPv4 it >> "just works" because the interface is always assumed to be IPv4 >> capable. > > Ok, I used ifconfig_em0_ipv6="up" and it worked. So it looks like this: > > ipv6_activate_all_interfaces="NO" > ipv6_network_interfaces="em0" > ifconfig_em0_ipv6="up" > ipv6_addrs_em0="2001:6a0:1cb::1-ff/64" > ipv6_defaultrouter="2001:6a0:1cb::" > > Good job, thank you! :) > > -- > best regards, > Lukasz Wasikowski I'm looking into fixing the issue so you could just have the ipv6_addrs_em0 line in rc.conf. However I don't want to flood the PR and this mailing list with different versions of the patch. I want to get it right next time. Stay tuned. -Kimmo ___ 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"
xz(1) keeps SEGFAULT-ing
Hello! I've set up several nightly backups all using the pipe-chain of dump | xz -9 | ccrypt > /remote/backups/fs.xz.cpt On one system these just work every night without a problem. On another I see xz SEGFAULT-ing about 90% through almost every night for one of the filesystems (the bigger of the two). This is, what cron emails me: DUMP: WARNING: should use -L when dumping live read-write filesystems! DUMP: Date of this level 1 dump: Sat Dec 22 03:23:00 2012 DUMP: Date of last level 0 dump: Thu Dec 6 01:23:02 2012 DUMP: Dumping /dev/ad4s1g (/home) to standard output DUMP: mapping (Pass I) [regular files] DUMP: Cache 16 MB, blocksize = 65536 DUMP: mapping (Pass II) [directories] DUMP: estimated 2157823 tape blocks. DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: 11.50% done, finished in 0:38 at Sat Dec 22 04:07:55 2012 DUMP: 17.80% done, finished in 0:46 at Sat Dec 22 04:20:37 2012 DUMP: 24.32% done, finished in 0:46 at Sat Dec 22 04:26:05 2012 DUMP: 31.23% done, finished in 0:44 at Sat Dec 22 04:28:27 2012 DUMP: 36.16% done, finished in 0:44 at Sat Dec 22 04:33:34 2012 DUMP: 43.21% done, finished in 0:39 at Sat Dec 22 04:33:51 2012 DUMP: 54.86% done, finished in 0:28 at Sat Dec 22 04:28:14 2012 DUMP: 60.63% done, finished in 0:25 at Sat Dec 22 04:30:24 2012 DUMP: 65.83% done, finished in 0:23 at Sat Dec 22 04:32:47 2012 DUMP: 70.54% done, finished in 0:20 at Sat Dec 22 04:35:18 2012 DUMP: 75.15% done, finished in 0:18 at Sat Dec 22 04:37:37 2012 DUMP: 80.28% done, finished in 0:14 at Sat Dec 22 04:39:10 2012 DUMP: 85.57% done, finished in 0:10 at Sat Dec 22 04:40:23 2012 DUMP: 90.50% done, finished in 0:07 at Sat Dec 22 04:41:46 2012 DUMP: SIGSEGV: ABORTING! DUMP: DUMP: DUMP: SIGSEGV: ABORTING! SIGSEGV: ABORTING! SIGSEGV: ABORTING! DUMP: SIGSEGV: ABORTING! Following xz's fault, all other processes (dump, ccrypt, sh) dump their cores to, but, according to dmesg, the culprit is always xz. According to core, the fault is somewhere inside liblzma.so.5. I recompiled the library to enable debugging and am trying to investigate, but, perhaps, someone has already run into this? Both systems used to run FreeBSD-8/amd64, when I first set the jobs up. I have since upgraded the troublesome server to 9.1, but that did not fix the problem. The remote filesystem (where ccrypt writes encrypted output) is mounted via smbfs on both servers, but I doubt that matters... Any ideas? Thanks, -mi ___ 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: ipv6_addrs_IF aliases in rc.conf(5)
W dniu 2012-12-22 04:41, Kimmo Paasiala pisze: >>> It looks like the reason for the difference to ipv4_addrs_IF is that >>> the "alias" parameter for ifconfig(8) operates differently for IPv6 >>> addresses, the first address of an interface can't be added with >>> "alias", for IPv4 it does not care. I'll have to dig deeper but that's >>> what the problem seems to be. >>> >>> -Kimmo >> >> The 'alias' parameter of ifconfig(8) is not the problem on the first >> ipv6 address, I have verified that. However, there's probably >> something in network.subr or /etc/rc.d/netif that I have overlooked >> and causes my code to be skipped if there's no ifconfig_IF_ipv6 >> variable defined in rc.conf(5). >> >> -Kimmo > > Yeah, this is problem in network.subr. An interface is not recognized > as IPv6 capable if the interface is not in "ipv6_network_interfaces" > and there's no "ifconfig_IF_ipv6" in rc.conf(5), bummer. For IPv4 it > "just works" because the interface is always assumed to be IPv4 > capable. Ok, I used ifconfig_em0_ipv6="up" and it worked. So it looks like this: ipv6_activate_all_interfaces="NO" ipv6_network_interfaces="em0" ifconfig_em0_ipv6="up" ipv6_addrs_em0="2001:6a0:1cb::1-ff/64" ipv6_defaultrouter="2001:6a0:1cb::" Good job, thank you! :) -- best regards, Lukasz Wasikowski ___ 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: Strange problem with... ZFS? Disk? Controller?
On 22 déc. 2012, at 10:01, Derek Kulinski wrote: > Your drive is 2TB, and according to this the bigger the drive the more > likely you'll run into problems like these: > http://forums.storagereview.com/index.php/topic/27994-smart-hardware-ecc-recovered-values/ Thanks Derek for this interesting pointer. It's the first time I read about problem like this... It's frightful. I had no idea big drives could have such problems. Any other source that would confirm the issue? patpro
Re: Strange problem with... ZFS? Disk? Controller?
Try running diskinfo -t /dev/... If it says your device is really slow it's probably dying. I'd suspect it's having trouble seeking. ___ 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: Strange problem with... ZFS? Disk? Controller?
Hello Alex, SMART values are collected by the disk itself (smartmontools is only reading it). This would imply that the problem is between disk and controller. Since you have tons of Hardware_ECC_Recovered and none of UDMA_CRC_Error_Count I would think that the problem is with disk itself. I think the long waits are due to disk trying to re-read given sector multiple times. Your drive is 2TB, and according to this the bigger the drive the more likely you'll run into problems like these: http://forums.storagereview.com/index.php/topic/27994-smart-hardware-ecc-recovered-values/ I don't know how serious it is but if you keep anything important there I would recommend a backup. You should try SMART self tests. Best regards, Derek Saturday, December 22, 2012, 12:20:27 AM, you wrote: > Hello, > I'm running FreeBSD 9.0/amd64, pure ZFS setup, one Seagate disk > ST2000NM0011 SN02 on LSI Logic (mpt) controller. > Yes, I know that running one disk on RAID controller is a bit weird, I > have to find yet if it is possible to connect disk to internal SATA > controller. > About two days ago, system became SLOW. Disk usage is constantly 100%, > and sometimes I'm getting swap_pager: indefinite wait buffer error. I > had to reset computer twice in two days. > mptutil does not show any errors, and smartctl shows > SMART Attributes Data Structure revision number: 10 > Vendor Specific SMART Attributes with Thresholds: > ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED > WHEN_FAILED RAW_VALUE >1 Raw_Read_Error_Rate 0x000f 067 063 044Pre-fail > Always - 6218970 >3 Spin_Up_Time0x0003 093 092 000Pre-fail > Always - 0 >4 Start_Stop_Count0x0032 100 100 020Old_age > Always - 14 >5 Reallocated_Sector_Ct 0x0033 100 100 036Pre-fail > Always - 21 >7 Seek_Error_Rate 0x000f 091 060 030Pre-fail > Always - 1433294073 >9 Power_On_Hours 0x0032 090 090 000Old_age > Always - 8825 > 10 Spin_Retry_Count0x0013 100 100 097Pre-fail > Always - 0 > 12 Power_Cycle_Count 0x0032 100 100 020Old_age > Always - 16 > 184 End-to-End_Error0x0032 100 100 099Old_age > Always - 0 > 187 Reported_Uncorrect 0x0032 100 100 000Old_age > Always - 0 > 188 Command_Timeout 0x0032 100 099 000Old_age > Always - 12885098499 > 189 High_Fly_Writes 0x003a 100 100 000Old_age > Always - 0 > 190 Airflow_Temperature_Cel 0x0022 068 047 045Old_age > Always - 32 (Min/Max 31/32) > 191 G-Sense_Error_Rate 0x0032 100 100 000Old_age > Always - 859 > 192 Power-Off_Retract_Count 0x0032 100 100 000Old_age > Always - 15 > 193 Load_Cycle_Count0x0032 100 100 000Old_age > Always - 26 > 194 Temperature_Celsius 0x0022 032 053 000Old_age > Always - 32 (0 21 0 0 0) > 195 Hardware_ECC_Recovered 0x001a 103 099 000Old_age > Always - 6218970 > 197 Current_Pending_Sector 0x0012 100 100 000Old_age > Always - 0 > 198 Offline_Uncorrectable 0x0010 100 100 000Old_age > Offline - 0 > 199 UDMA_CRC_Error_Count0x003e 200 200 000Old_age > Always - 0 > SMART Error Log Version: 1 > No Errors Logged > I have removed most of snapshots, it does not help. > I have stopped all active processes, disk load did not decrease, same 100%. > What can I check and/or replace to get the problem fixed? Any ideas? > Alex > ___ > 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" -- Best regards, Derekmailto:kulin...@cs.ucla.edu If you choke a Smurf, what color does it turn? ___ 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"
Strange problem with... ZFS? Disk? Controller?
Hello, I'm running FreeBSD 9.0/amd64, pure ZFS setup, one Seagate disk ST2000NM0011 SN02 on LSI Logic (mpt) controller. Yes, I know that running one disk on RAID controller is a bit weird, I have to find yet if it is possible to connect disk to internal SATA controller. About two days ago, system became SLOW. Disk usage is constantly 100%, and sometimes I'm getting swap_pager: indefinite wait buffer error. I had to reset computer twice in two days. mptutil does not show any errors, and smartctl shows SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 067 063 044Pre-fail Always - 6218970 3 Spin_Up_Time0x0003 093 092 000Pre-fail Always - 0 4 Start_Stop_Count0x0032 100 100 020Old_age Always - 14 5 Reallocated_Sector_Ct 0x0033 100 100 036Pre-fail Always - 21 7 Seek_Error_Rate 0x000f 091 060 030Pre-fail Always - 1433294073 9 Power_On_Hours 0x0032 090 090 000Old_age Always - 8825 10 Spin_Retry_Count0x0013 100 100 097Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 020Old_age Always - 16 184 End-to-End_Error0x0032 100 100 099Old_age Always - 0 187 Reported_Uncorrect 0x0032 100 100 000Old_age Always - 0 188 Command_Timeout 0x0032 100 099 000Old_age Always - 12885098499 189 High_Fly_Writes 0x003a 100 100 000Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 068 047 045Old_age Always - 32 (Min/Max 31/32) 191 G-Sense_Error_Rate 0x0032 100 100 000Old_age Always - 859 192 Power-Off_Retract_Count 0x0032 100 100 000Old_age Always - 15 193 Load_Cycle_Count0x0032 100 100 000Old_age Always - 26 194 Temperature_Celsius 0x0022 032 053 000Old_age Always - 32 (0 21 0 0 0) 195 Hardware_ECC_Recovered 0x001a 103 099 000Old_age Always - 6218970 197 Current_Pending_Sector 0x0012 100 100 000Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000Old_age Offline - 0 199 UDMA_CRC_Error_Count0x003e 200 200 000Old_age Always - 0 SMART Error Log Version: 1 No Errors Logged I have removed most of snapshots, it does not help. I have stopped all active processes, disk load did not decrease, same 100%. What can I check and/or replace to get the problem fixed? Any ideas? Alex ___ 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"