u3g and ubsa
I have recently been pointed to the u3g driver and gave it a try, because UBSA works very unreliable for me. - In combination with PF-NAT I get kernel panics under high load. - I have to hack some buffer sizes in the driver to get the full 3G speed. - Often my USB-3G stick is not detected, sometimes I spent several minutes plugging it in and out until it is detected. - It doesn't let me use the card reader in the stick. The u3g driver has NONE of these problems. Everything just works for me. So obviously I would like to have u3g in stable and chose for myself or even take support for devices out of ubsa that work better with u3g. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Will XFS be adopted
Dag-Erling Smørgrav pisze: Andrew Snow [EMAIL PROTECTED] writes: [...] I would wait until it has been considered stable and moved into the 7-STABLE tree before deploying a production server. ZFS has been in 7 for over a year. DES Yes, it's in STABLE, however zfs module says: This module (opensolaris) contains code covered by the Common Development and Distribution License (CDDL) see http://opensolaris.org/os/licensing/opensolaris_license/ *WARNING: ZFS is considered to be an experimental feature in FreeBSD.* So ZFS in 7.X should not be considered as STABLE for now. -- Bartosz Stec AUXILIA Spółka z o.o. ul. Wałbrzyska 43/2 52-314 Wrocław tel. (71) 79 99 760 w. 69 GSM: 662171775 E-Mail: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: High system in %system load .
I have only one CPU: Intel(R) Core(TM)2 Quad CPUQ6600 @ 2.40GHz (2400.10-MHz K8-class CPU) Origin = GenuineIntel Id = 0x6fb Stepping = 11 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8, This is from systat -v and this behavior is not the same as yours, CSW during problems could be from normal 8k -11k CSW some time rise to 57k for a 1-2 sec but system load ~30% in system and 10-20 process in block state process. --- 3 usersLoad 1.45 1.95 1.77 Nov 19 11:58 Mem:KBREALVIRTUAL VN PAGER SWAP PAGER Tot Share TotShareFree in out in out Act 1363876 17076 417559231032 273076 count All 1412996 20628 868303674448 pages Proc:Interrupts r p d s w Csw Trp Sys Int Sof Flt 44 cow9096 total 1 19 251 14k 13k 29k 1100 272 12k 12707 zfodata0 irq14 ozfod 210 atapci1 19 29.5%Sys 0.6%Intr 5.1%User 0.0%Nice 64.8%Idle%ozfod 2012 cpu0: time ||||||||||| daefr 890 bge0 256 ===353 prcfr 2012 cpu1: time 162 dtbuf12807 totfr 1986 cpu3: time Namei Name-cache Dir-cache10 desvn react 1986 cpu2: time Callshits %hits % 80638 numvn pdwak 99564 99060 99 308 0 25001 frevn pdpgs intrn Disks ad4 ad6 ad10 ar0 505820 wire KB/t 0.00 0.00 0.00 12.46 1359456 act tps 0 0 053 1880952 inact MB/s 0.00 0.00 0.00 0.65 115104 cache %busy 0 0 0 7 157972 free --- On Wed, Nov 19, 2008 at 11:42 AM, Tomas Randa [EMAIL PROTECTED] wrote: I think that ULE from 7.0 is not good enough... My problem was at 2x quad xeon (total 8 CPUS), where sometime system load increased to number 100-150 (normal was 1-4). When I look at systat -v, there was many CSW (about 300k, instead od 10k at normal). I tried many things - move from i386 to amd64 - same behaviour upgrade from 7.0 to 7.1BETA1 - better behaviour, but another problems.. when I switched from ULE to 4BSD, situation get worse. So I tried remove one CPU and it helps!... My opinion is, that FeeBSD scheduler in some situations (apache/php) do some cycle, which rapidly increase CSW. Try to look at CSW, when your problem occurs and write me a message Regards Tomáš Randa, Hosting Blueboard.cz -- Jabber: [EMAIL PROTECTED] ICQ: 100956181 Tel: +420 245 008 678 GSM: +420 775 086 575 Igor Lyapin wrote: On Wed, Nov 19, 2008 at 2:17 AM, Tomas Randa - Hosting Blueboard CZ [EMAIL PROTECTED] wrote: Hello, I have similar problem... what HW are you using? Some quad core xeon? One or two CPUS? I think it is scheduler based problem. Try to look at systat -v and watch CSW value at normal state and then if problem occurs.. Context switches do not rise and in problem and normal state is about 8000- 12000 Are you using 4BSD, aren`t you? Did you try ULE? I try ULE and 4BSD problem steel exists. Send dmesg... #dmesg All buffers synced. Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-RELEASE-p5 #0: Mon Nov 10 19:49:07 MSK 2008 [EMAIL PROTECTED]:/usr/obj/usr/ src/sys/KERNEL-4BSD Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Quad CPUQ6600 @ 2.40GHz (2400.10-MHz K8-class CPU) Origin = GenuineIntel Id = 0x6fb Stepping = 11 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe3bdSSE3,RSVD2,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF Cores per package: 4 usable memory = 4283449344 (4085 MB) avail memory = 4134977536 (3943 MB) ACPI APIC Table: 022108 APIC2247 FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 hptrr: HPT RocketRAID controller driver v1.1 (Nov 10 2008 19:48:39) acpi0: 022108 RSDT2247 on motherboard acpi0:
Re: Will XFS be adopted
[...] I would wait until it has been considered stable and moved into the 7-STABLE tree before deploying a production server. ZFS has been in 7 for over a year. DES Yes, it's in STABLE, however zfs module says: This module (opensolaris) contains code covered by the Common Development and Distribution License (CDDL) see http://opensolaris.org/os/licensing/opensolaris_license/ *WARNING: ZFS is considered to be an experimental feature in FreeBSD.* So ZFS in 7.X should not be considered as STABLE for now. Install a server with zfs and test it. Then let it handle tasks that are not critical. And if it works for you proceed and deploy it. It's somewhat difficult to say that it works for your particular workload. Some have rather positive experience and others are very reluctant. I use it as an internal samba-server and the issues I have are related to the external sas-cabinet rather than zfs itself. -- regards Claus When lenity and cruelty play for a kingdom, the gentler gamester is the soonest winner. Shakespeare ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: High system in %system load .
On Wed, Nov 19, 2008 at 12:04:10PM +0300, Igor Lyapin wrote: I have only one CPU: Intel(R) Core(TM)2 Quad CPUQ6600 @ 2.40GHz (2400.10-MHz K8-class CPU) Origin = GenuineIntel Id = 0x6fb Stepping = 11 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8, This is from systat -v and this behavior is not the same as yours, CSW during problems could be from normal 8k -11k CSW some time rise to 57k for a 1-2 sec but system load ~30% in system and 10-20 process in block state process. --- 3 usersLoad 1.45 1.95 1.77 Nov 19 11:58 Mem:KBREALVIRTUAL VN PAGER SWAP PAGER Tot Share TotShareFree in out in out Can you please fix whatever mail client you're using to not wrap lines? The data you've sent is impossible to read because of this. -- | Jeremy Chadwickjdc at 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 [EMAIL PROTECTED]
Re: High system in %system load .
Can you please fix whatever mail client you're using to not wrap lines? The data you've sent is impossible to read because of this. Sorry 3 usersLoad 1.91 1.87 1.89 Nov 19 12:26 Mem:KBREALVIRTUAL VN PAGER SWAP PAGER Tot Share TotShareFree in out in out Act 1369324 17144 419733231032 227288 count All 1419348 21020 871416073828 pages Proc:Interrupts r p d s w Csw Trp Sys Int Sof Flt506 cow9684 total 2 11 268 13k 9371 18k 1684 231 9151 8413 zfodata0 irq14 ozfod48 atapci1 19 28.9%Sys 0.5%Intr 4.3%User 0.0%Nice 66.4%Idle%ozfod 2011 cpu0: time ||||||||||| daefr 1636 bge0 256 ==+ 839 prcfr 2011 cpu1: time 324 dtbuf 8455 totfr 1989 cpu3: time Namei Name-cache Dir-cache10 desvn react 1989 cpu2: time Callshits %hits % 82598 numvn pdwak 73493 72895 99 399 1 25001 frevn pdpgs intrn Disks ad4 ad6 ad10 ar0 508592 wire KB/t 0.00 0.00 0.00 15.85 1366208 act tps 0 0 013 1916668 inact MB/s 0.00 0.00 0.00 0.21 152104 cache %busy 0 0 0 1 74912 free 219632 buf -- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: High system in %system load .
On Wed, Nov 19, 2008 at 12:28:59PM +0300, Igor Lyapin wrote: Can you please fix whatever mail client you're using to not wrap lines? The data you've sent is impossible to read because of this. Sorry 3 usersLoad 1.91 1.87 1.89 Nov 19 12:26 Mem:KBREALVIRTUAL VN PAGER SWAP PAGER Tot Share TotShareFree in out in out Act 1369324 17144 419733231032 227288 count All 1419348 21020 871416073828 pages Proc:Interrupts r p d s w Csw Trp Sys Int Sof Flt506 cow9684 total 2 11 268 13k 9371 18k 1684 231 9151 8413 zfodata0 irq14 ozfod48 atapci1 19 28.9%Sys 0.5%Intr 4.3%User 0.0%Nice 66.4%Idle%ozfod 2011 cpu0: time ||||||||||| daefr 1636 bge0 256 ==+ 839 prcfr 2011 cpu1: time 324 dtbuf 8455 totfr 1989 cpu3: time Namei Name-cache Dir-cache10 desvn react 1989 cpu2: time Callshits %hits % 82598 numvn pdwak 73493 72895 99 399 1 25001 frevn pdpgs intrn Disks ad4 ad6 ad10 ar0 508592 wire KB/t 0.00 0.00 0.00 15.85 1366208 act tps 0 0 013 1916668 inact MB/s 0.00 0.00 0.00 0.21 152104 cache %busy 0 0 0 1 74912 free 219632 buf These are still hard-wrapped. -- | Jeremy Chadwickjdc at 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 [EMAIL PROTECTED]
Re: fifo log problem
In message [EMAIL PROTECTED], Mike Tancsa writes: I could fear that you have two fifologs running at the same time, possibly as a result of syslogd doing something strange on sighup... There is nothing really strange about the config. Any idea on how to resolve? Not right now, there is nothing that rings a bell here and I have not seen it on any of my systems. As I said, I would fear that the SIGHUB to syslog results in some weird config where two writers are competing or something like that but that is purely a guess... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[2]: High system in %system load .
Hello Ivan, Where is the system busy? For start, try to collect information about what are your processes doing - for example from top(1). 4 usersLoad 1.43 1.46 1.27 Nov 19 13:14 Mem:KBREALVIRTUAL VN PAGER SWAP PAGER Tot Share TotShareFree in out in out Act 1367684 15208 444773227660 201372 count All 1424692 26352 9032876 107292 pages Proc:Interrupts r p d s w Csw Trp Sys Int Sof Flt467 cow9218 total 2 9 282 13k 7775 36k 1218 350 7386 6832 zfodata0 irq14 ozfod 286 atapci1 19 30.3%Sys 0.4%Intr 6.7%User 0.0%Nice 62.6%Idle%ozfod 2014 cpu0: time ||||||||||| daefr 932 bge0 256 === 1337 prcfr 2014 cpu1: time 146 dtbuf 7420 totfr 1986 cpu3: time Namei Name-cache Dir-cache10 desvn react 1986 cpu2: time Callshits %hits % 85727 numvn pdwak 139486 138964 100 300 0 25001 frevn pdpgs intrn Disks ad4 ad6 ad10 ar0 503544 wire KB/t 0.00 0.00 0.00 13.27 1363312 act tps 0 0 073 1949608 inact MB/s 0.00 0.00 0.00 0.95 168476 cache %busy 0 0 012 32896 free 219632 buf -- Best regards, Gmail.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Will XFS be adopted
Claus Guttesen pisze: [...] I would wait until it has been considered stable and moved into the 7-STABLE tree before deploying a production server. ZFS has been in 7 for over a year. DES Yes, it's in STABLE, however zfs module says: This module (opensolaris) contains code covered by the Common Development and Distribution License (CDDL) see http://opensolaris.org/os/licensing/opensolaris_license/ *WARNING: ZFS is considered to be an experimental feature in FreeBSD.* So ZFS in 7.X should not be considered as STABLE for now. Install a server with zfs and test it. Then let it handle tasks that are not critical. And if it works for you proceed and deploy it. It's somewhat difficult to say that it works for your particular workload. Some have rather positive experience and others are very reluctant. I use it as an internal samba-server and the issues I have are related to the external sas-cabinet rather than zfs itself. Well it's not simple indeed. I use ZFS on my home (not critical) box (RAIDZ1). After 4 weeks uptime with varied workload I assumed it's stable. Unfortunately ZFS crashed next week ;) -- Bartosz Stec AUXILIA Spółka z o.o. ul. Wałbrzyska 43/2 52-314 Wrocław tel. (71) 79 99 760 w. 69 GSM: 662171775 E-Mail: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: High system in %system load .
Igor Lyapin wrote: I already sent # top head in my first mail that's all non idle top process last pid: 56920; load averages: 2.90, 2.25, 1.72 up 0+22:10:12 20:04:05 210 processes: 2 running, 207 sleeping, 1 zombie CPU states: 8.3% user, 0.0% nice, 32.5% system, 0.3% interrupt, 58.9% idle Mem: 1268M Active, 1904M Inact, 479M Wired, 154M Cache, 214M Buf, 125M Free Swap: 8192M Total, 8192M Free PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 55546 www 1 -40 198M 24912K ufs1 0:25 29.39% httpd 55986 www 1 -40 198M 23228K ufs2 0:08 21.39% httpd 56030 www 1 -40 199M 23400K ufs1 0:05 11.23% httpd Ok, high sys load in ufs state for me was often caused by PHP session storage. By default, PHP will store all session records in a single directory, which can grow to monstruous sizes. If this is also your case, here are some things to try: a) increase vfs.ufs.dirhash_maxmem to 10 MB or something like that (look at vfs.ufs.dirhash_mem to see if you're hitting the limit and if so, monitor it to see what your dirhash_maxmem limit should be) b) configure PHP to use sharded directory structure for sessions. signature.asc Description: OpenPGP digital signature
Re: Frebsd 7-STABLE, atapicd, atapicam and Intel errors [SOLVED]
Yeah I thought also about bios bug... it`s pretty new piece of HW with modern chipset (Q45). I believe that the next release of BIOS comes soon. But what about those atapicd problems? Is it related to SATA interface of DVD/CD drive? Maybe also the LG drive has buggy FW :). Best regards Jeremy Chadwick napsal(a): On Wed, Nov 19, 2008 at 11:55:34AM +0100, Jan Sebosik wrote: Allright, I`ve played again with an HPET in BIOS little bit. Results - HPET disabled: kern.timecounter.choice: TSC(-100) ACPI-fast(1000) i8254(0) dummy(-100) kern.timecounter.hardware: ACPI-fast HPET enabled: kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000) i8254(0) dummy(-100) kern.timecounter.hardware: ACPI-fast But now FreeBSD boots also with HPET enabled (really don`t understand what`s going on). When I was trying to mount cd with mount -t cd9660 /dev/cd0 /mnt/cd0, mount works as expected (atapicd module not loaded). Then I`ve kldload-ed atapicd, mouunt -t cd9660 /dev/acd0 /mnt/cd0 (acd0, not cd0), but this ended with messages like this: unknown: FAILURE - READ_BIG timeout (retry count 0) Temporary I`ve disabled HPET in BIOS (Linux got problems too- he created gigabytes of log messages in /var/log/messages :D). Best regards, Jan Jeremy Chadwick napsal(a): On Wed, Nov 19, 2008 at 11:19:37AM +0100, Jan Sebosik wrote: Hi Yeah, I`ve tested it 2 times (switching it in BIOS). To me it seems bit mysterious, why there is a relationship between HPET setting and acd/cd problems in FreeBSD. Jeremy Chadwick napsal(a): On Wed, Nov 19, 2008 at 11:08:34AM +0100, Jan Sebosik wrote: Hi again so it seems to be a problem with HPET timer which is onboard and was enabled. If I turned him off, (acd | cd) problems went away. Jan Sebosik napsal(a): Hi all OS: Freebsd 7-STABLE from CVS of today Problematic HW: Intel DQ45CB (Q45 chipset, ICH10, SATA in native mode, but not AHCI), LG SATA DVD-RW GH20NS15 Problem: if I run freebsd without LG DVD connected to any SATA port onboard everything works allright. When I connect SATA DVD to board, then freebsd refuses to boot with messages similar to those: acd0: FAILURE-READ_BIG timed out unknown: FAILURE-READ_BIG timed out cddone: goit error 0x5 back Messages are repeating forever. Anybody knows where should be a bug? Temporary I`ve disconnected LG SATA burner from system board. Thanks for any idea. Best regards Are you ***absolutely 100% certain*** this is true? The time counter selected shouldn't have anything to do with the errors you see. Please thoroughly test this. I'd CC jhb@ to get confirmation of my statement, but I've promised myself I wouldn't bother him until 2009. :-) This is very bizarre. The errors being returned from acd0 are that an ATAPI/ATA command (READ_BIG, whatever the code for that is) did not receive a response from the controller or device within 5 seconds (assuming the ata(4) timeout values here; it could be something larger for ATAPI, I don't know). Maybe some a BIOS bug... Can you show us output from the following two commands? sysctl kern.timecounter.choice sysctl kern.timecounter.hardware Soren, do you know how/if the HPET time counter could cause this oddity? All of my systems use ACPI-fast, so I can't test this. What this proves is that disabling HPET in the BIOS makes absolutely no change to FreeBSD as far as the timecounter goes. It's still using ACPI-fast no matter if HPET is disabled or not. Disabling HPET does show up in FreeBSD (as you can tell), but the ATA/ATAPI stuff *should not* have some direct tie-in to HPET. I'm left believing you've found a BIOS bug. Please bring this up with your motherboard or system vendor. -- Jan Sebosik, Slovakia [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: High system in %system load .
On Wed, Nov 19, 2008 at 11:43:09AM +0100, Ivan Voras wrote: Igor Lyapin wrote: I already sent # top head in my first mail that's all non idle top process last pid: 56920; load averages: 2.90, 2.25, 1.72 up 0+22:10:12 20:04:05 210 processes: 2 running, 207 sleeping, 1 zombie CPU states: 8.3% user, 0.0% nice, 32.5% system, 0.3% interrupt, 58.9% idle Mem: 1268M Active, 1904M Inact, 479M Wired, 154M Cache, 214M Buf, 125M Free Swap: 8192M Total, 8192M Free PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 55546 www 1 -40 198M 24912K ufs1 0:25 29.39% httpd 55986 www 1 -40 198M 23228K ufs2 0:08 21.39% httpd 56030 www 1 -40 199M 23400K ufs1 0:05 11.23% httpd Ok, high sys load in ufs state for me was often caused by PHP session storage. By default, PHP will store all session records in a single directory, which can grow to monstruous sizes. If this is also your case, here are some things to try: a) increase vfs.ufs.dirhash_maxmem to 10 MB or something like that (look at vfs.ufs.dirhash_mem to see if you're hitting the limit and if so, monitor it to see what your dirhash_maxmem limit should be) b) configure PHP to use sharded directory structure for sessions. Good catch, Ivan! Also, I recommend tuning the session.gc_* php.ini variables to expire sessions more often (less files laying around means less CPU due to readdir()). The defaults PHP uses are absurd. I also hate how the session files end up in /var/tmp, making a gigantic mess. I made a separate directory for them, with specific perms (1777) for security: drwxrwxrwt 2 root wheel 1024 Nov 19 03:33 /var/tmp/php_sessions/ The piece of php.ini we use on our production web servers: [session] session.save_path = /var/tmp/php_sessions session.gc_maxlifetime = 900 session.gc_probability = 25 session.gc_divisor = 100 See the PHP documentation for what these variables do. -- | Jeremy Chadwickjdc at 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 [EMAIL PROTECTED]
Re[2]: High system in %system load [SOLVED]
Hello Ivan, Thank's Ivan you quite right this was problem with php session. Programmer set up in script's 2 years of session life. It was about 460k files in /var/tmp. COMMAND 55546 www 1 -40 198M 24912K ufs1 0:25 29.39% httpd 55986 www 1 -40 198M 23228K ufs2 0:08 21.39% httpd 56030 www 1 -40 199M 23400K ufs1 0:05 11.23% httpd Ok, high sys load in ufs state for me was often caused by PHP session storage. By default, PHP will store all session records in a single directory, which can grow to monstruous sizes. If this is also your case, here are some things to try: a) increase vfs.ufs.dirhash_maxmem to 10 MB or something like that (look at vfs.ufs.dirhash_mem to see if you're hitting the limit and if so, monitor it to see what your dirhash_maxmem limit should be) b) configure PHP to use sharded directory structure for sessions. -- Best regards, Igor ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gmirror and gstripe
Nenhum_de_Nos pisze: hail, I have an old AthlonXP 1700+ running 7-STABLE: FreeBSD xxx 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #1: Thu Nov 13 23:54:59 BRT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/xxx i386 where I have two 750GB Seagate SATA Disks. They are divided as two slices, around the first 120GB are gathered in gmirror, and what left is in gstripe. so that's whats going on. if the machine locks, and fsck comes to make its job, the box just gets slower and slower till I have to reset it the hard way. to make it not lock after just 5 minutes I have to boot and umount the arrays, and then run fsck_ufs on them. so this way I can have the box running again. Did you mean that machine slows down while doing background fsck? If yes, problem is probably related to snapshot which is created, and background fsck is done on snapshot. as I can't count on no power outage till the end of days, what can I do ? You may just disable background fsck and do it manually in single user mode in that case just by typing fsck -y. i just recompiled stable to make it stop this, but no go here ... this is an AthlonXP as said, running on EPoX kt600 based board, sata I is from via southbridge and 1GB of RAM. just another 40GB disk to the system. thanks, matheus If I am correct, your problem is old known and mksnap_ffs related. Jeremy Chadwick wrote a lot about it: http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues Good luck. -- Bartosz Stec AUXILIA Spółka z o.o. ul. Wałbrzyska 43/2 52-314 Wrocław tel. (71) 79 99 760 w. 69 GSM: 662171775 E-Mail: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: swap_pager: indefinite wait
Sossi Andrej schrieb: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 31, size: 4096 Can somebody help me understand why the system crashed this way or how to avoid future crash? This happens when it takes more than 20 seconds to swap out a page (http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/troubleshoot.html#INDEFINITE-WAIT-BUFFER). I had the same problem some time ago with FreeBSD 6.0 when making Backups (so the disks were busy). For me it helped to increase the timeout from 20 to 40 seconds in vm/swap_pager.c (http://fxr.watson.org/fxr/source/vm/swap_pager.c?v=FREEBSD60#L1103) -- Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
gmirror and gstripe
hail, I have an old AthlonXP 1700+ running 7-STABLE: FreeBSD xxx 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #1: Thu Nov 13 23:54:59 BRT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/xxx i386 where I have two 750GB Seagate SATA Disks. They are divided as two slices, around the first 120GB are gathered in gmirror, and what left is in gstripe. so that's whats going on. if the machine locks, and fsck comes to make its job, the box just gets slower and slower till I have to reset it the hard way. to make it not lock after just 5 minutes I have to boot and umount the arrays, and then run fsck_ufs on them. so this way I can have the box running again. as I can't count on no power outage till the end of days, what can I do ? i just recompiled stable to make it stop this, but no go here ... this is an AthlonXP as said, running on EPoX kt600 based board, sata I is from via southbridge and 1GB of RAM. just another 40GB disk to the system. thanks, matheus -- We will call you cygnus, The God of balance you shall be ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: _nyssin undefined
Peter, At this point, I've reinstalled the system, so I can't say. Jim -- In Response to your message - Date: Tue, 18 Nov 2008 04:56:45 +1100 To: J. W. Ballantine [EMAIL PROTECTED] From: Peter Jeremy [EMAIL PROTECTED] Subject: Re: _nyssin undefined --lHGcFxmlz1yfXmOs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2008-Nov-17 08:56:55 -0500, J. W. Ballantine [EMAIL PROTECTED] wrote: The problem started during the install of a new system build using the Friday AM CVS bits, and I can't get on the system in any mode. If you try to boot to single-user, do you get the enter shell pathname prompt? If so, does specifying /rescue/sh give you a shell? --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --lHGcFxmlz1yfXmOs Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkkhsF0ACgkQ/opHv/APuIcTzgCfUSZeYDAiiuQFZS4DH7Jc5CtV t74An2s0lsq0r41mRUH4uF45Mn19K5K1 =ZJAR -END PGP SIGNATURE- --lHGcFxmlz1yfXmOs-- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Frebsd 7-STABLE, atapicd, atapicam and Intel errors [SOLVED]
Opps, bad mailing-list... excuse me. Jan Sebosik napsal(a): Yeah I thought also about bios bug... it`s pretty new piece of HW with modern chipset (Q45). I believe that the next release of BIOS comes soon. But what about those atapicd problems? Is it related to SATA interface of DVD/CD drive? Maybe also the LG drive has buggy FW :). Best regards Jeremy Chadwick napsal(a): On Wed, Nov 19, 2008 at 11:55:34AM +0100, Jan Sebosik wrote: Allright, I`ve played again with an HPET in BIOS little bit. Results - HPET disabled: kern.timecounter.choice: TSC(-100) ACPI-fast(1000) i8254(0) dummy(-100) kern.timecounter.hardware: ACPI-fast HPET enabled: kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000) i8254(0) dummy(-100) kern.timecounter.hardware: ACPI-fast But now FreeBSD boots also with HPET enabled (really don`t understand what`s going on). When I was trying to mount cd with mount -t cd9660 /dev/cd0 /mnt/cd0, mount works as expected (atapicd module not loaded). Then I`ve kldload-ed atapicd, mouunt -t cd9660 /dev/acd0 /mnt/cd0 (acd0, not cd0), but this ended with messages like this: unknown: FAILURE - READ_BIG timeout (retry count 0) Temporary I`ve disabled HPET in BIOS (Linux got problems too- he created gigabytes of log messages in /var/log/messages :D). Best regards, Jan Jeremy Chadwick napsal(a): On Wed, Nov 19, 2008 at 11:19:37AM +0100, Jan Sebosik wrote: Hi Yeah, I`ve tested it 2 times (switching it in BIOS). To me it seems bit mysterious, why there is a relationship between HPET setting and acd/cd problems in FreeBSD. Jeremy Chadwick napsal(a): On Wed, Nov 19, 2008 at 11:08:34AM +0100, Jan Sebosik wrote: Hi again so it seems to be a problem with HPET timer which is onboard and was enabled. If I turned him off, (acd | cd) problems went away. Jan Sebosik napsal(a): Hi all OS: Freebsd 7-STABLE from CVS of today Problematic HW: Intel DQ45CB (Q45 chipset, ICH10, SATA in native mode, but not AHCI), LG SATA DVD-RW GH20NS15 Problem: if I run freebsd without LG DVD connected to any SATA port onboard everything works allright. When I connect SATA DVD to board, then freebsd refuses to boot with messages similar to those: acd0: FAILURE-READ_BIG timed out unknown: FAILURE-READ_BIG timed out cddone: goit error 0x5 back Messages are repeating forever. Anybody knows where should be a bug? Temporary I`ve disconnected LG SATA burner from system board. Thanks for any idea. Best regards Are you ***absolutely 100% certain*** this is true? The time counter selected shouldn't have anything to do with the errors you see. Please thoroughly test this. I'd CC jhb@ to get confirmation of my statement, but I've promised myself I wouldn't bother him until 2009. :-) This is very bizarre. The errors being returned from acd0 are that an ATAPI/ATA command (READ_BIG, whatever the code for that is) did not receive a response from the controller or device within 5 seconds (assuming the ata(4) timeout values here; it could be something larger for ATAPI, I don't know). Maybe some a BIOS bug... Can you show us output from the following two commands? sysctl kern.timecounter.choice sysctl kern.timecounter.hardware Soren, do you know how/if the HPET time counter could cause this oddity? All of my systems use ACPI-fast, so I can't test this. What this proves is that disabling HPET in the BIOS makes absolutely no change to FreeBSD as far as the timecounter goes. It's still using ACPI-fast no matter if HPET is disabled or not. Disabling HPET does show up in FreeBSD (as you can tell), but the ATA/ATAPI stuff *should not* have some direct tie-in to HPET. I'm left believing you've found a BIOS bug. Please bring this up with your motherboard or system vendor. -- Jan Sebosik, Slovakia [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gmirror and gstripe
On Wed, November 19, 2008 10:39 am, Bartosz Stec wrote: Nenhum_de_Nos pisze: hail, I have an old AthlonXP 1700+ running 7-STABLE: FreeBSD xxx 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #1: Thu Nov 13 23:54:59 BRT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/xxx i386 where I have two 750GB Seagate SATA Disks. They are divided as two slices, around the first 120GB are gathered in gmirror, and what left is in gstripe. so that's whats going on. if the machine locks, and fsck comes to make its job, the box just gets slower and slower till I have to reset it the hard way. to make it not lock after just 5 minutes I have to boot and umount the arrays, and then run fsck_ufs on them. so this way I can have the box running again. Did you mean that machine slows down while doing background fsck? If yes, problem is probably related to snapshot which is created, and background fsck is done on snapshot. I can say for slow down, as I can't do anything on it. ping to it responds really slow, and if I plug an usb keyboard and try to use the machine, the keyborad just is able to change consoles (from tty1 to tty2, and so on), but I can't even login to the machine, as nothing I type gets to the terminal. so I can't say its slow or locked. as I can't count on no power outage till the end of days, what can I do ? You may just disable background fsck and do it manually in single user mode in that case just by typing fsck -y. ok, but this makes me have to be there every reboot, if it wasn't a reboot from a command sent by me. and this makes my life hard, as I can't be allways there (this is a home server, nfs+pf+postfix+webmail+dns), I just want to put fsck_y on rc.conf ... i just recompiled stable to make it stop this, but no go here ... this is an AthlonXP as said, running on EPoX kt600 based board, sata I is from via southbridge and 1GB of RAM. just another 40GB disk to the system. thanks, matheus If I am correct, your problem is old known and mksnap_ffs related. Jeremy Chadwick wrote a lot about it: http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues gonna read :) thanks matheus Good luck. -- Bartosz Stec AUXILIA SpóÅka z o.o. ul. WaÅbrzyska 43/2 52-314 WrocÅaw tel. (71) 79 99 760 w. 69 GSM: 662171775 E-Mail: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- We will call you cygnus, The God of balance you shall be ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: u3g and ubsa
On Wed, November 19, 2008 6:05 am, Dominic Fandrey wrote: I have recently been pointed to the u3g driver and gave it a try, because UBSA works very unreliable for me. - In combination with PF-NAT I get kernel panics under high load. - I have to hack some buffer sizes in the driver to get the full 3G speed. - Often my USB-3G stick is not detected, sometimes I spent several minutes plugging it in and out until it is detected. - It doesn't let me use the card reader in the stick. The u3g driver has NONE of these problems. Everything just works for me. So obviously I would like to have u3g in stable and chose for myself or even take support for devices out of ubsa that work better with u3g. ___ same for me. I'm looking forward to see u3g in STABLE. matheus -- We will call you cygnus, The God of balance you shall be ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
atacontrol missing drive after upgrade to 6.3
I upgraded from 6.2 to 6.3 p5 last night. Upon rebooting, the second disk in the mirror is missing. # atacontrol status ar0 ar0: ATA RAID1 status: DEGRADED subdisks: 0 ad0 ONLINE 1 MISSING # grep ata /var/run/dmesg.boot ad0: 238475MB WDC WD2500AVJB-63UDA0 00.02C01 at ata0-master UDMA100 ad1: 238475MB WDC WD2500AVJB-63UDA0 00.02C01 at ata0-slave UDMA100 ar0: disk0 READY (master) using ad0 at ata0-master ar1: disk1 READY (mirror) using ad1 at ata0-slave I am unsure how to re-add the disk, or if this is a bug. I noticed a number of fixes for atacontrol.c beyond the current version in 6.3 (1.36.2.6) http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/atacontrol/atacontrol.c Obviously it won't rebuild # atacontrol rebuild ar0 atacontrol: ioctl(IOCATARAIDREBUILD): Input/output error Do I do? atacontrol detach ata0-slave atacontrol attach ata0-slave atacontrol addspare ad1 ar0 atacontrol rebuild ar0 (not sure what channel I am supposed to be using) Or is this something that requires atacontrol.c to be patched? I am not sure where to start, so I thought I would ask here first before trying anything. btw, its Intel ICH5: atapci1: Intel ICH5 SATA150 controller port 0xc000-0xc007,0xc400-0xc403,0xc800-0xc807,0xcc00-0xcc03,0xd000-0xd00f irq 18 at device 31.2 on pci0 Thank you in advance for any help you can provide. Mark Make the switch to the world#39;s best email. Get Yahoo!7 Mail! http://au.yahoo.com/y7mail ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atacontrol missing drive after upgrade to 6.3
On Wed, Nov 19, 2008 at 09:15:12AM -0800, Mark Sams wrote: I upgraded from 6.2 to 6.3 p5 last night. Upon rebooting, the second disk in the mirror is missing. # atacontrol status ar0 ar0: ATA RAID1 status: DEGRADED subdisks: 0 ad0 ONLINE 1 MISSING # grep ata /var/run/dmesg.boot ad0: 238475MB WDC WD2500AVJB-63UDA0 00.02C01 at ata0-master UDMA100 ad1: 238475MB WDC WD2500AVJB-63UDA0 00.02C01 at ata0-slave UDMA100 ar0: disk0 READY (master) using ad0 at ata0-master ar1: disk1 READY (mirror) using ad1 at ata0-slave I am unsure how to re-add the disk, or if this is a bug. I noticed a number of fixes for atacontrol.c beyond the current version in 6.3 (1.36.2.6) http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/atacontrol/atacontrol.c Obviously it won't rebuild # atacontrol rebuild ar0 atacontrol: ioctl(IOCATARAIDREBUILD): Input/output error Do I do? atacontrol detach ata0-slave atacontrol attach ata0-slave atacontrol addspare ad1 ar0 atacontrol rebuild ar0 (not sure what channel I am supposed to be using) Or is this something that requires atacontrol.c to be patched? I am not sure where to start, so I thought I would ask here first before trying anything. btw, its Intel ICH5: atapci1: Intel ICH5 SATA150 controller port 0xc000-0xc007,0xc400-0xc403,0xc800-0xc807,0xcc00-0xcc03,0xd000-0xd00f irq 18 at device 31.2 on pci0 You're using Intel MatrixRAID, aren't you? Please migrate away from this immediately, your data is at risk. http://wiki.freebsd.org/JeremyChadwick/ATA_issues_and_troubleshooting The problem you're experiencing is documented there. There is no solution, as far as I know. The problems still exist on RELENG_7 also. I recommend you back up (off-load) all of your data onto a disk or system somewhere else, and use gmirror(8) instead. Please, stay away from Intel MatrixRAID on FreeBSD. -- | Jeremy Chadwickjdc at 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 [EMAIL PROTECTED]
Re: atacontrol missing drive after upgrade to 6.3
- Original Message From: Jeremy Chadwick [EMAIL PROTECTED] You're using Intel MatrixRAID, aren't you? Please migrate away from this immediately, your data is at risk. Ummm... I don't think so. It is just a standard RAID 1 mirror using the built in ICH5 chip. It has been running fine for a over a year now on the other builds of FreeBSD 6.x. It is not RAID 0+1 or whatever the Matrix RAID thing is. Make the switch to the world#39;s best email. Get Yahoo!7 Mail! http://au.yahoo.com/y7mail ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atacontrol missing drive after upgrade to 6.3
On Wed, Nov 19, 2008 at 11:29:19AM -0800, Mark Sams wrote: From: Jeremy Chadwick [EMAIL PROTECTED] You're using Intel MatrixRAID, aren't you? Please migrate away from this immediately, your data is at risk. Ummm... I don't think so. It is just a standard RAID 1 mirror using the built in ICH5 chip. It has been running fine for a over a year now on the other builds of FreeBSD 6.x. It is not RAID 0+1 or whatever the Matrix RAID thing is. The built-in ICH5 == Intel MatrixRAID. It's BIOS-level RAID under an Intel ICH chip. It's called MatrixRAID. I have no personal problem with Intel MatrixRAID. What I'm telling you is that FreeBSD's support for it is horribly, horribly broken. You *will* lose your data. Read my Wiki entries in full. I'm only going to say this once more: please reconsider. You very likely are not going to be able to recover that failed array. The last person who had this problem had to boot a Linux LiveCD and attempt to use Linux tools to repair it. -- | Jeremy Chadwickjdc at 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 [EMAIL PROTECTED]
(actually ZFS discussion) Re: Will XFS be adopted
Well it's not simple indeed. I use ZFS on my home (not critical) box (RAIDZ1). After 4 weeks uptime with varied workload I assumed it's stable. Unfortunately ZFS crashed next week ;) Tune your system for ZFS and the crashes will go away. Read this: http://wiki.freebsd.org/ZFSTuningGuide A running system with ZFS caches a lot of disk access (making it really fast for some applications). WHen you run the 'top' command, you will see that WIRED amount of ram is higher than a system without ZFS. Mem: 161M Active, 114M Inact, 639M Wired, 1084K Cache, 199M Buf, 1086M Free What applications will benefit from ZFS? Read this article on MySQL and ZFS: http://dev.mysql.com/tech-resources/articles/mysql-zfs.html It proposed that you allocate less ram to MySQL in your my.cnf and let ZFS take care of caching. Here are my loader.conf settings. zfs_load=YES # ZFS tunings vm.kmem_size=800M vm.kmem_size_max=800M # http://wiki.freebsd.org/ZFSTuningGuide vfs.zfs.arc_max=160M vfs.zfs.vdev.cache.size=5M # and I have my root on zfs... vfs.root.mountfrom=zfs:tank/root - Rudy - ** monkeybrains.net colocation ** - ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atacontrol missing drive after upgrade to 6.3
On Wed, Nov 19, 2008 at 11:32:42AM -0800, Jeremy Chadwick wrote: On Wed, Nov 19, 2008 at 11:29:19AM -0800, Mark Sams wrote: From: Jeremy Chadwick [EMAIL PROTECTED] You're using Intel MatrixRAID, aren't you? Please migrate away from this immediately, your data is at risk. Ummm... I don't think so. It is just a standard RAID 1 mirror using the built in ICH5 chip. It has been running fine for a over a year now on the other builds of FreeBSD 6.x. It is not RAID 0+1 or whatever the Matrix RAID thing is. The built-in ICH5 == Intel MatrixRAID. It's BIOS-level RAID under an Intel ICH chip. It's called MatrixRAID. No, it is not. MatrixRAID was not introduced until with the ICH6R controller. Earlier Intel ICH chips (including the ICH5) may well have supported some kind of BIOS-level RAID, but it was not MatrixRAID. (This is not to say that their earlier RAID implementations was any more or less reliable - I have no data on that.) I have no personal problem with Intel MatrixRAID. What I'm telling you is that FreeBSD's support for it is horribly, horribly broken. You *will* lose your data. Read my Wiki entries in full. I'm only going to say this once more: please reconsider. You very likely are not going to be able to recover that failed array. The last person who had this problem had to boot a Linux LiveCD and attempt to use Linux tools to repair it. -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atacontrol missing drive after upgrade to 6.3
On Wed, Nov 19, 2008 at 08:48:51PM +0100, Erik Trulsson wrote: On Wed, Nov 19, 2008 at 11:32:42AM -0800, Jeremy Chadwick wrote: On Wed, Nov 19, 2008 at 11:29:19AM -0800, Mark Sams wrote: From: Jeremy Chadwick [EMAIL PROTECTED] You're using Intel MatrixRAID, aren't you? Please migrate away from this immediately, your data is at risk. Ummm... I don't think so. It is just a standard RAID 1 mirror using the built in ICH5 chip. It has been running fine for a over a year now on the other builds of FreeBSD 6.x. It is not RAID 0+1 or whatever the Matrix RAID thing is. The built-in ICH5 == Intel MatrixRAID. It's BIOS-level RAID under an Intel ICH chip. It's called MatrixRAID. No, it is not. MatrixRAID was not introduced until with the ICH6R controller. Earlier Intel ICH chips (including the ICH5) may well have supported some kind of BIOS-level RAID, but it was not MatrixRAID. (This is not to say that their earlier RAID implementations was any more or less reliable - I have no data on that.) This is news to me. I'll spend some time tonight at Intel's site reading old chipset specifications. :-) The ataraid(4) man page only mentions MatrixRAID with regards to Intel, which is why I'm wondering what exactly the ICH5 offers. I wonder if it's a very primitive RAID type which ataraid(4) simply handles under the MatrixRAID code (which would explain the problems he's having with getting the array back in order). Thanks for the education lesson! Always appreciated. :-) -- | Jeremy Chadwickjdc at 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 [EMAIL PROTECTED]
Re: What would be the appropriate value for kern.maxfiles
On Wed, Nov 19, 2008 at 3:51 PM, Ramesh Ayyagari [EMAIL PROTECTED] wrote: my server primarily runs postfix experiencing very huge inflow of mails 6 per hour. There are some other services that the servers runs like caching DNS etc but postfix being the primary application running on it. Ram 1.) Please don't top-post. 2.) I gave you an example. You obviously know what your server is doing, so you need to adjust the tunable accordingly. You can always set the number too high, then slim it down from there after testing to see what meets your requirements. -- Glen Barber If you have any trouble sounding condescending, find a Unix user to show you how it's done. --Scott Adams ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What would be the appropriate value for kern.maxfiles
my server primarily runs postfix experiencing very huge inflow of mails 6 per hour. There are some other services that the servers runs like caching DNS etc but postfix being the primary application running on it. Ram From: Glen Barber [EMAIL PROTECTED] To: Ramesh Ayyagari [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, November 18, 2008 6:43:56 PM Subject: Re: What would be the appropriate value for kern.maxfiles On Tue, Nov 18, 2008 at 6:05 PM, Ramesh Ayyagari [EMAIL PROTECTED] wrote: Hello All, I have my client system running FreeBSD 6.3-RELEASE-p1 with 4 GB of RAM. This morning i have the following errors popping up on the console log - postfix/qmgr[94057]: fatal: socket: Too many open files Googling for this error, I found this is someway related to the kernel parameter kern.maxflies and increasing this value can have errors go away. The present value of this parameter is 24000. I also found this also depends of the RAM we have on the system. what would the appropriate value for kern.maxfiles for a system having 2GB RAM, a system having 4 GB and a system having 16GB of RAM. Please help The Xorg meta-package recommends 'kern.maxfiles=25000' for a desktop system. This is a situation where it really depends on what you're using your system for. HTH -- Glen Barber 570.328.0318 If you have any trouble sounding condescending, find a Unix user to show you how it's done. --Scott Adams ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atacontrol missing drive after upgrade to 6.3
You're using Intel MatrixRAID, aren't you? Please migrate away from this immediately, your data is at risk. Although I am not using Matrix RAID, I guess I will switch to gmirror to be safe. Does the following approach seem valid? 1) Break the mirror (ar0) 2) Reboot using ad0 3) (from the link http://lantech.geekvenue.net/chucktips/jason/chuck/1175552464/index_html ): Step 1: Use sysctl to allow the mounted disk to be modified Step 2: Create the mirror (gm0) using ad0 with gmirror Step 3: Modify /boot/loader.conf to load gmirror on startup Step 4: Replace ar0 with gm0 in /etc/fstab Step 6: Use gmirror insert command to add ad1 to gm0 Step 7: Check the mirroring status with gmirror statusShould I just call the mirror ar0 instead of gm0 and save doing step4? Any problem with that? Thanks in advance. Mark Make the switch to the world#39;s best email. Get Yahoo!7 Mail! http://au.yahoo.com/y7mail ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atacontrol missing drive after upgrade to 6.3
On Wed, Nov 19, 2008 at 03:43:02PM -0800, Mark Sams wrote: You're using Intel MatrixRAID, aren't you? Please migrate away from this immediately, your data is at risk. Although I am not using Matrix RAID, I guess I will switch to gmirror to be safe. Does the following approach seem valid? You are missing one very important step that you should make regardless of which approach you use: 0) Make a backup of any and all data that you don't want to lose (and check that you can restore data from the backup while you still have the original data.) 1) Break the mirror (ar0) 2) Reboot using ad0 3) (from the link http://lantech.geekvenue.net/chucktips/jason/chuck/1175552464/index_html ): Step 1: Use sysctl to allow the mounted disk to be modified Step 2: Create the mirror (gm0) using ad0 with gmirror Step 3: Modify /boot/loader.conf to load gmirror on startup Step 4: Replace ar0 with gm0 in /etc/fstab Step 6: Use gmirror insert command to add ad1 to gm0 Step 7: Check the mirroring status with gmirror statusShould I just call the mirror ar0 instead of gm0 and save doing step4? Any problem with that? Thanks in advance. Mark (Somebody else will have to answer if the above can be expected to work or not, but I suspect that it would be easier and less errorprone to do as follow: 1) Make backups of all data 2) Delete the old RAID array. 3) Create a new array from scratch 4) Restore data from backups) -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: shutdown -p now crashes
Ganbold wrote: #3 0xc06ab8b3 in vput (vp=0xc3d11ac8) at /usr/src/sys/kern/vfs_subr.c:2202 #4 0xc06a69e6 in dounmount (mp=0xc3e59b30, flags=524288, td=0xc3b31d20) at /usr/src/sys/kern/vfs_mount.c:1288 #5 0xc06aa493 in vfs_unmountall () at /usr/src/sys/kern/vfs_subr.c:2939 #6 0xc062b7f4 in boot (howto=16392) at /usr/src/sys/kern/kern_shutdown.c:400 #7 0xc062bc17 in reboot (td=0xc3b31d20, uap=0xeef55cfc) at /usr/src/sys/kern/kern_shutdown.c:172 #8 0xc08171f5 in syscall (frame=0xeef55d38) at /usr/src/sys/i386/i386/trap.c:1090 #9 0xc07fd710 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255 #10 0x0033 in ?? () (kgdb) .. I was able to reproduce the panic. I plugged in external ZFS/GELI HDD via USB and used 'zpool import' to import disk and did some 'ls' and then used 'zpool export' to umount disk. Then I detached the disk from desktop and tried to shutdown -p now. This way panic is reproduced 2 times. More info: daemon% uname -an FreeBSD daemon.micom.mng.net 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #8 r185085M: Thu Nov 20 12:50:33 ULAT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GDAEMON i386 daemon% 118. 118Writing entropy file: 118. 118Terminated 118. 118Nov 20 14:30:12 daemon syslogd: exiting on signal 15 rootvp 0xc3d11ac8 v_usecount 2 KDB: stack backtrace: db_trace_self_wrapper(c086b1ee,f2c6bbac,c06abb23,c086faa8,c3d11ac8,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c086faa8,c3d11ac8,2,b,0,...) at kdb_backtrace+0x29 vrele(c3d11ac8,c3e6f690,0,0,0,...) at vrele+0x83 fdfree(c3e6f690,c3e8f000,48077bf0,f2c6bc80,c062ccfe,...) at fdfree+0x8b6 exit1(c3e6f690,0,f2c6bd2c,c0817245,c3e6f690,...) at exit1+0x5e9 sys_exit(c3e6f690,f2c6bcfc,4,c3e6f690,f2c6bd2c,...) at sys_exit+0x1d syscall(f2c6bd38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x4810ed2f, esp = 0xbfbfe6bc, ebp = 0xbfbfe6c8 --- rootvp 0xc3d11ac8 v_usecount 1 KDB: stack backtrace: db_trace_self_wrapper(c086b1ee,f2c6bbac,c06abb23,c086faa8,c3d11ac8,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c086faa8,c3d11ac8,1,b,0,...) at kdb_backtrace+0x29 vrele(c3d11ac8,c3e6f690,0,0,0,...) at vrele+0x83 fdfree(c3e6f690,c3e8f000,48077bf0,f2c6bc80,c062ccfe,...) at fdfree+0x8c3 exit1(c3e6f690,0,f2c6bd2c,c0817245,c3e6f690,...) at exit1+0x5e9 sys_exit(c3e6f690,f2c6bcfc,4,c3e6f690,f2c6bd2c,...) at sys_exit+0x1d syscall(f2c6bd38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x4810ed2f, esp = 0xbfbfe6bc, ebp = 0xbfbfe6c8 --- Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...2 1 0 0 done All buffers synced. rootvp 0xc3d11ac8 v_usecount 1 KDB: stack backtrace: db_trace_self_wrapper(c086b1ee,eef55ba8,c06abb23,c086faa8,c3d11ac8,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c086faa8,c3d11ac8,1,c3b31d20,eef55ba8,...) at kdb_backtrace+0x29 vrele(c3d11ac8,2,eef55bf0,c3b31d20,0,...) at vrele+0x83 dounmount(c3e56b30,8,c3b31d20,e3b61aec,0,...) at dounmount+0x491 vfs_unmountall(c0869007,0,c086906b,117,eef55c50,...) at vfs_unmountall+0x33 boot(c3b31d20,8,0,fffe,c3b31d20,...) at boot+0x444 reboot(c3b31d20,eef55cfc,4,8048290,9e7c9054,...) at reboot+0x67 syscall(eef55d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (55, FreeBSD ELF32, reboot), eip = 0x8050bb3, esp = 0xbfbfe8ec, ebp = 0xbfbfe9b8 --- panic: vput: negative ref cnt cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper(c086b1ee,eef55b68,c062bd39,c08832ea,0,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08832ea,0,c086fac1,eef55b74,0,...) at kdb_backtrace+0x29 panic(c086fac1,eef55ba8,c06abcd0,c3d11ac8,eef55b90,...) at panic+0x119 vput(c3d11ac8,2,eef55bf0,c3b31d20,0,...) at vput+0xf3 dounmount(c3e56b30,8,c3b31d20,e3b61aec,0,...) at dounmount+0x4a6 vfs_unmountall(c0869007,0,c086906b,117,eef55c50,...) at vfs_unmountall+0x33 boot(c3b31d20,8,0,fffe,c3b31d20,...) at boot+0x444 reboot(c3b31d20,eef55cfc,4,8048290,9e7c9054,...) at reboot+0x67 syscall(eef55d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (55, FreeBSD ELF32, reboot), eip = 0x8050bb3, esp = 0xbfbfe8ec, ebp = 0xbfbfe9b8 --- Uptime: 7m3s Physical memory: 1013 MB Dumping 54 MB: 39 23 7 (kgdb) where #0 doadump () at pcpu.h:196 #1 0xc062ba67 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc062bd72 in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc06ab8e3 in vput (vp=0xc3d11ac8) at /usr/src/sys/kern/vfs_subr.c:2211 #4 0xc06a69e6 in dounmount (mp=0xc3e56b30, flags=524288, td=0xc3b31d20) at /usr/src/sys/kern/vfs_mount.c:1288 #5 0xc06aa493 in vfs_unmountall () at /usr/src/sys/kern/vfs_subr.c:2948 #6 0xc062b7f4 in boot (howto=16392) at
Re: shutdown -p now crashes
On Thu, Nov 20, 2008 at 02:50:46PM +0800, Ganbold wrote: Ganbold wrote: #3 0xc06ab8b3 in vput (vp=0xc3d11ac8) at /usr/src/sys/kern/vfs_subr.c:2202 #4 0xc06a69e6 in dounmount (mp=0xc3e59b30, flags=524288, td=0xc3b31d20) at /usr/src/sys/kern/vfs_mount.c:1288 #5 0xc06aa493 in vfs_unmountall () at /usr/src/sys/kern/vfs_subr.c:2939 #6 0xc062b7f4 in boot (howto=16392) at /usr/src/sys/kern/kern_shutdown.c:400 #7 0xc062bc17 in reboot (td=0xc3b31d20, uap=0xeef55cfc) at /usr/src/sys/kern/kern_shutdown.c:172 #8 0xc08171f5 in syscall (frame=0xeef55d38) at /usr/src/sys/i386/i386/trap.c:1090 #9 0xc07fd710 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255 #10 0x0033 in ?? () (kgdb) .. I was able to reproduce the panic. I plugged in external ZFS/GELI HDD via USB and used 'zpool import' to import disk and did some 'ls' and then used 'zpool export' to umount disk. Then I detached the disk from desktop and tried to shutdown -p now. This way panic is reproduced 2 times. Are we sure that the problem isn't the well-known do not yank a device out from underneathe the rest of the OS problem, e.g. removing removable devices while filesystems are still mounted? If so, this problem is very well-known, documented on my Wiki, and work is being done in CURRENT to fix it (official ETA is 2009/02). I see geli(8) has a detach option, which you might need to do after the zpool export, being as the GEOM provider is still attached to the USB HDD. I would recommend trying that first. More info: daemon% uname -an FreeBSD daemon.micom.mng.net 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #8 r185085M: Thu Nov 20 12:50:33 ULAT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GDAEMON i386 daemon% 118. 118Writing entropy file: 118. 118Terminated 118. 118Nov 20 14:30:12 daemon syslogd: exiting on signal 15 rootvp 0xc3d11ac8 v_usecount 2 KDB: stack backtrace: db_trace_self_wrapper(c086b1ee,f2c6bbac,c06abb23,c086faa8,c3d11ac8,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c086faa8,c3d11ac8,2,b,0,...) at kdb_backtrace+0x29 vrele(c3d11ac8,c3e6f690,0,0,0,...) at vrele+0x83 fdfree(c3e6f690,c3e8f000,48077bf0,f2c6bc80,c062ccfe,...) at fdfree+0x8b6 exit1(c3e6f690,0,f2c6bd2c,c0817245,c3e6f690,...) at exit1+0x5e9 sys_exit(c3e6f690,f2c6bcfc,4,c3e6f690,f2c6bd2c,...) at sys_exit+0x1d syscall(f2c6bd38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x4810ed2f, esp = 0xbfbfe6bc, ebp = 0xbfbfe6c8 --- rootvp 0xc3d11ac8 v_usecount 1 KDB: stack backtrace: db_trace_self_wrapper(c086b1ee,f2c6bbac,c06abb23,c086faa8,c3d11ac8,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c086faa8,c3d11ac8,1,b,0,...) at kdb_backtrace+0x29 vrele(c3d11ac8,c3e6f690,0,0,0,...) at vrele+0x83 fdfree(c3e6f690,c3e8f000,48077bf0,f2c6bc80,c062ccfe,...) at fdfree+0x8c3 exit1(c3e6f690,0,f2c6bd2c,c0817245,c3e6f690,...) at exit1+0x5e9 sys_exit(c3e6f690,f2c6bcfc,4,c3e6f690,f2c6bd2c,...) at sys_exit+0x1d syscall(f2c6bd38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x4810ed2f, esp = 0xbfbfe6bc, ebp = 0xbfbfe6c8 --- Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...2 1 0 0 done All buffers synced. rootvp 0xc3d11ac8 v_usecount 1 KDB: stack backtrace: db_trace_self_wrapper(c086b1ee,eef55ba8,c06abb23,c086faa8,c3d11ac8,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c086faa8,c3d11ac8,1,c3b31d20,eef55ba8,...) at kdb_backtrace+0x29 vrele(c3d11ac8,2,eef55bf0,c3b31d20,0,...) at vrele+0x83 dounmount(c3e56b30,8,c3b31d20,e3b61aec,0,...) at dounmount+0x491 vfs_unmountall(c0869007,0,c086906b,117,eef55c50,...) at vfs_unmountall+0x33 boot(c3b31d20,8,0,fffe,c3b31d20,...) at boot+0x444 reboot(c3b31d20,eef55cfc,4,8048290,9e7c9054,...) at reboot+0x67 syscall(eef55d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (55, FreeBSD ELF32, reboot), eip = 0x8050bb3, esp = 0xbfbfe8ec, ebp = 0xbfbfe9b8 --- panic: vput: negative ref cnt cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper(c086b1ee,eef55b68,c062bd39,c08832ea,0,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08832ea,0,c086fac1,eef55b74,0,...) at kdb_backtrace+0x29 panic(c086fac1,eef55ba8,c06abcd0,c3d11ac8,eef55b90,...) at panic+0x119 vput(c3d11ac8,2,eef55bf0,c3b31d20,0,...) at vput+0xf3 dounmount(c3e56b30,8,c3b31d20,e3b61aec,0,...) at dounmount+0x4a6 vfs_unmountall(c0869007,0,c086906b,117,eef55c50,...) at vfs_unmountall+0x33 boot(c3b31d20,8,0,fffe,c3b31d20,...) at boot+0x444 reboot(c3b31d20,eef55cfc,4,8048290,9e7c9054,...) at reboot+0x67 syscall(eef55d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (55, FreeBSD ELF32, reboot),
Re: shutdown -p now crashes
Jeremy Chadwick wrote: On Thu, Nov 20, 2008 at 02:50:46PM +0800, Ganbold wrote: Ganbold wrote: #3 0xc06ab8b3 in vput (vp=0xc3d11ac8) at /usr/src/sys/kern/vfs_subr.c:2202 #4 0xc06a69e6 in dounmount (mp=0xc3e59b30, flags=524288, td=0xc3b31d20) at /usr/src/sys/kern/vfs_mount.c:1288 #5 0xc06aa493 in vfs_unmountall () at /usr/src/sys/kern/vfs_subr.c:2939 #6 0xc062b7f4 in boot (howto=16392) at /usr/src/sys/kern/kern_shutdown.c:400 #7 0xc062bc17 in reboot (td=0xc3b31d20, uap=0xeef55cfc) at /usr/src/sys/kern/kern_shutdown.c:172 #8 0xc08171f5 in syscall (frame=0xeef55d38) at /usr/src/sys/i386/i386/trap.c:1090 #9 0xc07fd710 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255 #10 0x0033 in ?? () (kgdb) .. I was able to reproduce the panic. I plugged in external ZFS/GELI HDD via USB and used 'zpool import' to import disk and did some 'ls' and then used 'zpool export' to umount disk. Then I detached the disk from desktop and tried to shutdown -p now. This way panic is reproduced 2 times. Are we sure that the problem isn't the well-known do not yank a device out from underneathe the rest of the OS problem, e.g. removing removable devices while filesystems are still mounted? If so, this problem is very well-known, documented on my Wiki, and work is being done in CURRENT to fix it (official ETA is 2009/02). I see geli(8) has a detach option, which you might need to do after the zpool export, being as the GEOM provider is still attached to the USB HDD. I would recommend trying that first. Thanks for suggestion :) In my zfs_mount and zfs_umount scripts I have: zfs_mount.sh #!/bin/sh geli attach -k /root/da0.key /dev/da0s1e zpool import tank1 zpool import tank2 zfs_umount.sh #!/bin/sh zpool export tank1 zpool export tank2 geli detach da0s1e.eli I hope that answers what you meant :) Ganbold More info: daemon% uname -an FreeBSD daemon.micom.mng.net 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #8 r185085M: Thu Nov 20 12:50:33 ULAT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GDAEMON i386 daemon% 118. 118Writing entropy file: 118. 118Terminated 118. 118Nov 20 14:30:12 daemon syslogd: exiting on signal 15 rootvp 0xc3d11ac8 v_usecount 2 KDB: stack backtrace: db_trace_self_wrapper(c086b1ee,f2c6bbac,c06abb23,c086faa8,c3d11ac8,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c086faa8,c3d11ac8,2,b,0,...) at kdb_backtrace+0x29 vrele(c3d11ac8,c3e6f690,0,0,0,...) at vrele+0x83 fdfree(c3e6f690,c3e8f000,48077bf0,f2c6bc80,c062ccfe,...) at fdfree+0x8b6 exit1(c3e6f690,0,f2c6bd2c,c0817245,c3e6f690,...) at exit1+0x5e9 sys_exit(c3e6f690,f2c6bcfc,4,c3e6f690,f2c6bd2c,...) at sys_exit+0x1d syscall(f2c6bd38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x4810ed2f, esp = 0xbfbfe6bc, ebp = 0xbfbfe6c8 --- rootvp 0xc3d11ac8 v_usecount 1 KDB: stack backtrace: db_trace_self_wrapper(c086b1ee,f2c6bbac,c06abb23,c086faa8,c3d11ac8,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c086faa8,c3d11ac8,1,b,0,...) at kdb_backtrace+0x29 vrele(c3d11ac8,c3e6f690,0,0,0,...) at vrele+0x83 fdfree(c3e6f690,c3e8f000,48077bf0,f2c6bc80,c062ccfe,...) at fdfree+0x8c3 exit1(c3e6f690,0,f2c6bd2c,c0817245,c3e6f690,...) at exit1+0x5e9 sys_exit(c3e6f690,f2c6bcfc,4,c3e6f690,f2c6bd2c,...) at sys_exit+0x1d syscall(f2c6bd38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x4810ed2f, esp = 0xbfbfe6bc, ebp = 0xbfbfe6c8 --- Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...2 1 0 0 done All buffers synced. rootvp 0xc3d11ac8 v_usecount 1 KDB: stack backtrace: db_trace_self_wrapper(c086b1ee,eef55ba8,c06abb23,c086faa8,c3d11ac8,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c086faa8,c3d11ac8,1,c3b31d20,eef55ba8,...) at kdb_backtrace+0x29 vrele(c3d11ac8,2,eef55bf0,c3b31d20,0,...) at vrele+0x83 dounmount(c3e56b30,8,c3b31d20,e3b61aec,0,...) at dounmount+0x491 vfs_unmountall(c0869007,0,c086906b,117,eef55c50,...) at vfs_unmountall+0x33 boot(c3b31d20,8,0,fffe,c3b31d20,...) at boot+0x444 reboot(c3b31d20,eef55cfc,4,8048290,9e7c9054,...) at reboot+0x67 syscall(eef55d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (55, FreeBSD ELF32, reboot), eip = 0x8050bb3, esp = 0xbfbfe8ec, ebp = 0xbfbfe9b8 --- panic: vput: negative ref cnt cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper(c086b1ee,eef55b68,c062bd39,c08832ea,0,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08832ea,0,c086fac1,eef55b74,0,...) at kdb_backtrace+0x29 panic(c086fac1,eef55ba8,c06abcd0,c3d11ac8,eef55b90,...) at panic+0x119 vput(c3d11ac8,2,eef55bf0,c3b31d20,0,...) at vput+0xf3 dounmount(c3e56b30,8,c3b31d20,e3b61aec,0,...) at dounmount+0x4a6
Re: shutdown -p now crashes
On Thu, Nov 20, 2008 at 03:18:10PM +0800, Ganbold wrote: Jeremy Chadwick wrote: On Thu, Nov 20, 2008 at 02:50:46PM +0800, Ganbold wrote: Ganbold wrote: #3 0xc06ab8b3 in vput (vp=0xc3d11ac8) at /usr/src/sys/kern/vfs_subr.c:2202 #4 0xc06a69e6 in dounmount (mp=0xc3e59b30, flags=524288, td=0xc3b31d20) at /usr/src/sys/kern/vfs_mount.c:1288 #5 0xc06aa493 in vfs_unmountall () at /usr/src/sys/kern/vfs_subr.c:2939 #6 0xc062b7f4 in boot (howto=16392) at /usr/src/sys/kern/kern_shutdown.c:400 #7 0xc062bc17 in reboot (td=0xc3b31d20, uap=0xeef55cfc) at /usr/src/sys/kern/kern_shutdown.c:172 #8 0xc08171f5 in syscall (frame=0xeef55d38) at /usr/src/sys/i386/i386/trap.c:1090 #9 0xc07fd710 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255 #10 0x0033 in ?? () (kgdb) .. I was able to reproduce the panic. I plugged in external ZFS/GELI HDD via USB and used 'zpool import' to import disk and did some 'ls' and then used 'zpool export' to umount disk. Then I detached the disk from desktop and tried to shutdown -p now. This way panic is reproduced 2 times. Are we sure that the problem isn't the well-known do not yank a device out from underneathe the rest of the OS problem, e.g. removing removable devices while filesystems are still mounted? If so, this problem is very well-known, documented on my Wiki, and work is being done in CURRENT to fix it (official ETA is 2009/02). I see geli(8) has a detach option, which you might need to do after the zpool export, being as the GEOM provider is still attached to the USB HDD. I would recommend trying that first. Thanks for suggestion :) In my zfs_mount and zfs_umount scripts I have: zfs_mount.sh #!/bin/sh geli attach -k /root/da0.key /dev/da0s1e zpool import tank1 zpool import tank2 zfs_umount.sh #!/bin/sh zpool export tank1 zpool export tank2 geli detach da0s1e.eli I hope that answers what you meant :) Thanks -- it does. I was worried the detach was missing and might explain the anomaly. It doesn't. I hope others can help... More info: daemon% uname -an FreeBSD daemon.micom.mng.net 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #8 r185085M: Thu Nov 20 12:50:33 ULAT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GDAEMON i386 daemon% 118. 118Writing entropy file: 118. 118Terminated 118. 118Nov 20 14:30:12 daemon syslogd: exiting on signal 15 rootvp 0xc3d11ac8 v_usecount 2 KDB: stack backtrace: db_trace_self_wrapper(c086b1ee,f2c6bbac,c06abb23,c086faa8,c3d11ac8,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c086faa8,c3d11ac8,2,b,0,...) at kdb_backtrace+0x29 vrele(c3d11ac8,c3e6f690,0,0,0,...) at vrele+0x83 fdfree(c3e6f690,c3e8f000,48077bf0,f2c6bc80,c062ccfe,...) at fdfree+0x8b6 exit1(c3e6f690,0,f2c6bd2c,c0817245,c3e6f690,...) at exit1+0x5e9 sys_exit(c3e6f690,f2c6bcfc,4,c3e6f690,f2c6bd2c,...) at sys_exit+0x1d syscall(f2c6bd38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x4810ed2f, esp = 0xbfbfe6bc, ebp = 0xbfbfe6c8 --- rootvp 0xc3d11ac8 v_usecount 1 KDB: stack backtrace: db_trace_self_wrapper(c086b1ee,f2c6bbac,c06abb23,c086faa8,c3d11ac8,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c086faa8,c3d11ac8,1,b,0,...) at kdb_backtrace+0x29 vrele(c3d11ac8,c3e6f690,0,0,0,...) at vrele+0x83 fdfree(c3e6f690,c3e8f000,48077bf0,f2c6bc80,c062ccfe,...) at fdfree+0x8c3 exit1(c3e6f690,0,f2c6bd2c,c0817245,c3e6f690,...) at exit1+0x5e9 sys_exit(c3e6f690,f2c6bcfc,4,c3e6f690,f2c6bd2c,...) at sys_exit+0x1d syscall(f2c6bd38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x4810ed2f, esp = 0xbfbfe6bc, ebp = 0xbfbfe6c8 --- Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...2 1 0 0 done All buffers synced. rootvp 0xc3d11ac8 v_usecount 1 KDB: stack backtrace: db_trace_self_wrapper(c086b1ee,eef55ba8,c06abb23,c086faa8,c3d11ac8,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c086faa8,c3d11ac8,1,c3b31d20,eef55ba8,...) at kdb_backtrace+0x29 vrele(c3d11ac8,2,eef55bf0,c3b31d20,0,...) at vrele+0x83 dounmount(c3e56b30,8,c3b31d20,e3b61aec,0,...) at dounmount+0x491 vfs_unmountall(c0869007,0,c086906b,117,eef55c50,...) at vfs_unmountall+0x33 boot(c3b31d20,8,0,fffe,c3b31d20,...) at boot+0x444 reboot(c3b31d20,eef55cfc,4,8048290,9e7c9054,...) at reboot+0x67 syscall(eef55d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (55, FreeBSD ELF32, reboot), eip = 0x8050bb3, esp = 0xbfbfe8ec, ebp = 0xbfbfe9b8 --- panic: vput: negative ref cnt cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper(c086b1ee,eef55b68,c062bd39,c08832ea,0,...) at db_trace_self_wrapper+0x26
