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
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
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?
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: 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
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)
On Sat, Dec 22, 2012 at 4:25 PM, Łukasz Wąsikowski luk...@wasikowski.net 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
Re: xz(1) keeps SEGFAULT-ing
Is it dumping core? Adrian On 22 December 2012 07:07, Mikhail T. mi+t...@aldan.algebra.com 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)
Quoth =?UTF-8?B?xYF1a2FzeiBXxIVzaWtvd3NraQ==?= luk...@wasikowski.net: 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: ipv6_addrs_IF aliases in rc.conf(5)
W dniu 2012-12-22 18:14, Ben Morrow pisze: Quoth =?UTF-8?B?xYF1a2FzeiBXxIVzaWtvd3NraQ==?= luk...@wasikowski.net: 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: 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
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: 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
Re: 9.1 minimal ram requirements
On 23 December 2012 03:40, Marten Vijn i...@martenvijn.nl 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 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 Sun, 23 Dec 2012 03:45:39 +0300, Sergey Kandaurov wrote:
On 23 December 2012 03:40, Marten Vijn i...@martenvijn.nl 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 requirements
Ken,
Does CAM CTL really need to pre-allocate 35MB of RAM at startup?
Adrian
On 22 December 2012 16:45, Sergey Kandaurov pluk...@gmail.com wrote:
On 23 December 2012 03:40, Marten Vijn i...@martenvijn.nl 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
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 pluk...@gmail.com wrote:
On 23 December 2012 03:40, Marten Vijn i...@martenvijn.nl 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
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: redacted
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: 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: redacted
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
