Re: NFS stalling on 8.1-STABLE
On Thu, Aug 12, 2010 at 10:35:49AM -0700, Mark Morley wrote: I have five front end web servers that all mount their content from the same server via NFS. If I stress the link on any one of the machines (eg: copy a large directory with a lot of files to/from the mounted file system) the client will pause. That is, all processes trying to access that mount will freeze. The log files with hundreds or thousands of nfs server not responding / is alive again messages. After 60 seconds it returns to normal, unless the load is still there in which case it continues to pause. This has only started happening since I upgraded the client machines to 8.1-STABLE (previously four of them were 8.0 and one was 7.3). The server is 7.1-RELEASE-p11. No other changes have taken place in terms of hardware or software or mount options, etc. All nics involved are gigabit em cards, and they are on a private network (web access to the boxes is via an external interface). Are there any indications in dmesg that the NIC is responsible, e.g. interface down/up, etc.? Does switching to UDP-based NFS solve the problem for you? What OS version (uname -a) and NIC are used on the NFS server? Can you please provide the following output from one of the client machines running 8.1-STABLE with gigE em(4)? You can X-out machine names, MAC addresses, and IP addresses/netblocks if need be. * uname -a * ifconfig emX (where X is the interface number which would be used for NFS) * netstat -idn -I emX * pciconf -lvc (provide only the data for emX please) * vmstat -i * sysctl hw.pci * As root, run sysctl dev.em.X.stats=1 then do dmesg and provide the output for NIC statistics (will start with emX:) Thanks. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: zfs destroy snapshot doesn't free space
On 2010-Aug-13 16:51:24 +0200, Andreas Mayer andimaye...@gmail.com wrote: If I take a snapshot again, this snapshot also references 623G. What can I do to reclaim this space? I have to do this before I can set a quota (I have set quotas for all other file systems now :) ). Does a reboot resolve the problem? -- Peter Jeremy pgpbzS5ldbnfc.pgp Description: PGP signature
Re: Inconsistent IO performance
On 13.8.2010 18:01, Kevin Oberman wrote: For some time I have seen very odd issues with IO performance on 8-Stable. Going back to November of last year when 8.0 was released, I see variations of up to 22% in identical operations. This is not a degradation as the performance moves up and down. In 8.0-8.1 span of time there was some work on the ata driver to make it use MAXPHYS (128 KiB) transfer sizes instead of 64 KiB. Modifying this will involve changing and recompiling the kernel but if you want to try something and the hardware is SATA you might try the new AHCI driver (ada). http://ivoras.net/blog/tree/2009-11-17.trying-ahci-in-8.0.html ___ 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: Inconsistent IO performance
From: Ivan Voras ivo...@freebsd.org Date: Mon, 16 Aug 2010 15:03:23 +0200 Sender: owner-freebsd-sta...@freebsd.org On 13.8.2010 18:01, Kevin Oberman wrote: For some time I have seen very odd issues with IO performance on 8-Stable. Going back to November of last year when 8.0 was released, I see variations of up to 22% in identical operations. This is not a degradation as the performance moves up and down. In 8.0-8.1 span of time there was some work on the ata driver to make it use MAXPHYS (128 KiB) transfer sizes instead of 64 KiB. Modifying this will involve changing and recompiling the kernel but if you want to try something and the hardware is SATA you might try the new AHCI driver (ada). http://ivoras.net/blog/tree/2009-11-17.trying-ahci-in-8.0.html Thanks. I appreciate the suggestion. I am running a 8-Stable kernel from August 9, so I think I should be OK on this. IS there a requirement to set some parameter in the kernel config to take advantage of this? While the ThinkPad has a SATA ICH6-M chip-set, it does not provide or any SATA connections. Both SATA ports a run to a SATA/PATA converter chip and the only 2 physical connections available are PATA. I am assuming that this is because 2.5 in. SATA drives were pretty much unavailable when this system was shipped. This was the last of the T43 series and was dropped from the product line by Lenovo about a month after I got it, to be replaced by T60 systems running Core2 chips and using SATA drives. Just lousy timing almost 4 years ago. Thanks again! -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
STABLE kernel panic: privileged instruction fault
Hello. I have a couple of Supermicro servers which got the similar kernel panic with all FreeBSD versions I tried since 6.4. Now I want to investigate into the problem. The servers get into panic with similar workload: file server with a lot of files and connections. Web server software is nginx. File system is UFS+GJOURNAL. Outgoing traffic on each server is ~10 MB/s. I think it is not software problem, because when I've installed Linux with such configuration there were no kernel panics. Here is the short overview of the hardware: CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (2992.51-MHz K8-class CPU) Origin = GenuineIntel Id = 0xf65 Family = f Model = 6 Stepping = 5 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=0xe59dSSE3,DTES64,MON,DS_CPL,EST,TM2,CNXT-ID,CX16,xTPR,PDCM AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF TSC: P-state invariant real memory = 2147483648 (2048 MB) avail memory = 2054619136 (1959 MB) DMESG: http://lexasoft.ru/m/dmesg.txt CORE: http://lexasoft.ru/m/core.txt Fatal trap 1: privileged instruction fault while in kernel mode cpuid = 1; apic id = 01 instruction pointer = 0x20:0xff8040d2cc83 stack pointer = 0x28:0xff8040d2ca80 frame pointer = 0x28:0xff0060c0b740 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 9388 (nginx) trap number = 1 panic: privileged instruction fault cpuid = 1 Uptime: 17d15h48m49s Physical memory: 2032 MB Dumping 1485 MB: 1470 1454 1438 1422 1406 1390 1374 1358 1342 1326 1310 1294 1278 1262 1246 1230 1214 1198 1182 1166 1150 1134 1118 1102 1086 1070 1054 1038 1022 1006 990 974 958 942 926 910 894 878 862 846 830 814 798 782 766 750 734 718 702 686 670 654 638 622 606 590 574 558 542 526 510 494 478 462 446 430 414 398 382 366 350 334 318 302 286 270 254 238 222 206 190 174 158 142 126 110 94 78 62 46 30 14 (kgdb) #0 doadump () at pcpu.h:223 #1 0x80590c59 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 #2 0x8059108c in panic (fmt=0x80951fc4 %s) at /usr/src/sys/kern/kern_shutdown.c:579 #3 0x80878fd8 in trap_fatal (frame=0xff0060c0b740, eva=Variable eva is not available. ) at /usr/src/sys/amd64/amd64/trap.c:857 #4 0x808799ea in trap (frame=0xff8040d2c9d0) at /usr/src/sys/amd64/amd64/trap.c:644 #5 0x8085f983 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:224 #6 0xff8040d2cc83 in ?? () #7 0xff8040d2cb50 in ?? () #8 0xff8040d2caf0 in ?? () #9 0xff8040d2cbf0 in ?? () #10 0xff0060c0b740 in ?? () #11 0x80b83c60 in sysent () #12 0xff8040d2cc80 in ?? () #13 0xff8040d2cae0 in ?? () #14 0x8059c431 in bintime (bt=0x80ad3140) at /usr/src/sys/kern/kern_tc.c:200 Previous frame inner to this frame (corrupt stack?) (kgdb) -- Alexey Tarasov (\__/) (='.'=) E[: | | | | :]З ()_() ___ freebsd-curr...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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: Inconsistent IO performance
On Mon, Aug 16, 2010 at 07:46:38AM -0700, Kevin Oberman wrote: From: Ivan Voras ivo...@freebsd.org Date: Mon, 16 Aug 2010 15:03:23 +0200 Sender: owner-freebsd-sta...@freebsd.org On 13.8.2010 18:01, Kevin Oberman wrote: For some time I have seen very odd issues with IO performance on 8-Stable. Going back to November of last year when 8.0 was released, I see variations of up to 22% in identical operations. This is not a degradation as the performance moves up and down. In 8.0-8.1 span of time there was some work on the ata driver to make it use MAXPHYS (128 KiB) transfer sizes instead of 64 KiB. Modifying this will involve changing and recompiling the kernel but if you want to try something and the hardware is SATA you might try the new AHCI driver (ada). http://ivoras.net/blog/tree/2009-11-17.trying-ahci-in-8.0.html Thanks. I appreciate the suggestion. I am running a 8-Stable kernel from August 9, so I think I should be OK on this. IS there a requirement to set some parameter in the kernel config to take advantage of this? While the ThinkPad has a SATA ICH6-M chip-set, it does not provide or any SATA connections. Both SATA ports a run to a SATA/PATA converter chip and the only 2 physical connections available are PATA. I am assuming that this is because 2.5 in. SATA drives were pretty much unavailable when this system was shipped. This was the last of the T43 series and was dropped from the product line by Lenovo about a month after I got it, to be replaced by T60 systems running Core2 chips and using SATA drives. Just lousy timing almost 4 years ago. I should expand on what Kevin's stated (I read what was written 3 or 4 times over and it didn't jive; if there's no physical SATA connections, why is a SATA/PATA converter in use?). The T43 is a bizarre beast. The ICH6-M chipset uses SATA, but is physically wired to a custom PCB/adapter that serves a couple different purposes: - Converts a 2.5 PATA hard disk connector into SATA (meaning, the laptop actually uses 2.5 PATA hard disks). thinkwiki.org refers to this as a SATA-to-PATA bridge (controller-to-disk), while I tend to look at it as a PATA-to-SATA bridge (disk-to-controller). - Integrates a middle-man ASIC that supposedly intercepts ATA commands, in addition to doing some drive model string verification (requiring folks to purchase IBM-sanctioned drives). - The system BIOS knows of the PCB/adapter and, somehow, queries it to verifies its existence. I imagine it sends some vendor-centric ATA commands which the ASIC intercepts. Supposedly people have tried removing (desoldering) the adapter in attempt to use standard SATA disks and destroyed their systems in the process. As Kevin stated, the ICH6-M doesn't support AHCI, so using ahci.ko isn't an option in his case. It's possible that the adapter in question is going/has gone bad, is doing something awful, or the underlying drive itself has degraded in some way which SMART doesn't see (ex. on-disk cache going bad; wouldn't surprise me in this case). -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Inconsistent IO performance
On Mon, Aug 16, 2010 at 08:33:16AM -0700, Jeremy Chadwick wrote: On Mon, Aug 16, 2010 at 07:46:38AM -0700, Kevin Oberman wrote: From: Ivan Voras ivo...@freebsd.org Date: Mon, 16 Aug 2010 15:03:23 +0200 Sender: owner-freebsd-sta...@freebsd.org On 13.8.2010 18:01, Kevin Oberman wrote: For some time I have seen very odd issues with IO performance on 8-Stable. Going back to November of last year when 8.0 was released, I see variations of up to 22% in identical operations. This is not a degradation as the performance moves up and down. In 8.0-8.1 span of time there was some work on the ata driver to make it use MAXPHYS (128 KiB) transfer sizes instead of 64 KiB. Modifying this will involve changing and recompiling the kernel but if you want to try something and the hardware is SATA you might try the new AHCI driver (ada). http://ivoras.net/blog/tree/2009-11-17.trying-ahci-in-8.0.html Thanks. I appreciate the suggestion. I am running a 8-Stable kernel from August 9, so I think I should be OK on this. IS there a requirement to set some parameter in the kernel config to take advantage of this? While the ThinkPad has a SATA ICH6-M chip-set, it does not provide or any SATA connections. Both SATA ports a run to a SATA/PATA converter chip and the only 2 physical connections available are PATA. I am assuming that this is because 2.5 in. SATA drives were pretty much unavailable when this system was shipped. This was the last of the T43 series and was dropped from the product line by Lenovo about a month after I got it, to be replaced by T60 systems running Core2 chips and using SATA drives. Just lousy timing almost 4 years ago. I should expand on what Kevin's stated (I read what was written 3 or 4 times over and it didn't jive; if there's no physical SATA connections, why is a SATA/PATA converter in use?). The T43 is a bizarre beast. The ICH6-M chipset uses SATA, but is physically wired to a custom PCB/adapter that serves a couple different purposes: - Converts a 2.5 PATA hard disk connector into SATA (meaning, the laptop actually uses 2.5 PATA hard disks). thinkwiki.org refers to this as a SATA-to-PATA bridge (controller-to-disk), while I tend to look at it as a PATA-to-SATA bridge (disk-to-controller). - Integrates a middle-man ASIC that supposedly intercepts ATA commands, in addition to doing some drive model string verification (requiring folks to purchase IBM-sanctioned drives). - The system BIOS knows of the PCB/adapter and, somehow, queries it to verifies its existence. I imagine it sends some vendor-centric ATA commands which the ASIC intercepts. Supposedly people have tried removing (desoldering) the adapter in attempt to use standard SATA disks and destroyed their systems in the process. As Kevin stated, the ICH6-M doesn't support AHCI, so using ahci.ko isn't an option in his case. Strike that -- according to the Intel ICH6 specification, AHCI is supported on the ICH6-M and ICH6R: http://www.intel.com/assets/pdf/datasheet/301473.pdf The T43 might not offer this capability (not sure if it's available via the system BIOS) though. Skimming Google results in mixed responses, with some focus on ACPI DSDT and some mention of old BIOSes supporting it [AHCI] but newer ones removing it. Weird. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | It's possible that the adapter in question is going/has gone bad, is doing something awful, or the underlying drive itself has degraded in some way which SMART doesn't see (ex. on-disk cache going bad; wouldn't surprise me in this case). -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: STABLE kernel panic: privileged instruction fault
On Mon, Aug 16, 2010 at 07:15:16PM +0400, Alexey Tarasov wrote: Hello. I have a couple of Supermicro servers which got the similar kernel panic with all FreeBSD versions I tried since 6.4. Now I want to investigate into the problem. The servers get into panic with similar workload: file server with a lot of files and connections. Web server software is nginx. File system is UFS+GJOURNAL. Outgoing traffic on each server is ~10 MB/s. I think it is not software problem, because when I've installed Linux with such configuration there were no kernel panics. Here is the short overview of the hardware: CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (2992.51-MHz K8-class CPU) Origin = GenuineIntel Id = 0xf65 Family = f Model = 6 Stepping = 5 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=0xe59dSSE3,DTES64,MON,DS_CPL,EST,TM2,CNXT-ID,CX16,xTPR,PDCM AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF TSC: P-state invariant real memory = 2147483648 (2048 MB) avail memory = 2054619136 (1959 MB) DMESG: http://lexasoft.ru/m/dmesg.txt CORE: http://lexasoft.ru/m/core.txt Fatal trap 1: privileged instruction fault while in kernel mode cpuid = 1; apic id = 01 instruction pointer = 0x20:0xff8040d2cc83 stack pointer = 0x28:0xff8040d2ca80 frame pointer = 0x28:0xff0060c0b740 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 9388 (nginx) trap number = 1 panic: privileged instruction fault cpuid = 1 Uptime: 17d15h48m49s Physical memory: 2032 MB Dumping 1485 MB: 1470 1454 1438 1422 1406 1390 1374 1358 1342 1326 1310 1294 1278 1262 1246 1230 1214 1198 1182 1166 1150 1134 1118 1102 1086 1070 1054 1038 1022 1006 990 974 958 942 926 910 894 878 862 846 830 814 798 782 766 750 734 718 702 686 670 654 638 622 606 590 574 558 542 526 510 494 478 462 446 430 414 398 382 366 350 334 318 302 286 270 254 238 222 206 190 174 158 142 126 110 94 78 62 46 30 14 (kgdb) #0 doadump () at pcpu.h:223 #1 0x80590c59 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 #2 0x8059108c in panic (fmt=0x80951fc4 %s) at /usr/src/sys/kern/kern_shutdown.c:579 #3 0x80878fd8 in trap_fatal (frame=0xff0060c0b740, eva=Variable eva is not available. ) at /usr/src/sys/amd64/amd64/trap.c:857 #4 0x808799ea in trap (frame=0xff8040d2c9d0) at /usr/src/sys/amd64/amd64/trap.c:644 #5 0x8085f983 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:224 #6 0xff8040d2cc83 in ?? () #7 0xff8040d2cb50 in ?? () #8 0xff8040d2caf0 in ?? () #9 0xff8040d2cbf0 in ?? () #10 0xff0060c0b740 in ?? () #11 0x80b83c60 in sysent () #12 0xff8040d2cc80 in ?? () #13 0xff8040d2cae0 in ?? () #14 0x8059c431 in bintime (bt=0x80ad3140) at /usr/src/sys/kern/kern_tc.c:200 Previous frame inner to this frame (corrupt stack?) (kgdb) The backtrace make absolutely no sense. I would not trust kgdb anyway. Compile ddb in and do backtrace in console on the panic. Also, disassemble the kernel at the fault address. I am very curious which instruction causes this. This is stock GENERIC on the bare metal booted, right ? pgp0KYiAf9rFf.pgp Description: PGP signature
Re: STABLE kernel panic: privileged instruction fault
Hello Kostik! On Aug 16, 2010, at 10:48 PM, Kostik Belousov wrote: The backtrace make absolutely no sense. I would not trust kgdb anyway. Compile ddb in and do backtrace in console on the panic. Also, disassemble the kernel at the fault address. I am very curious which instruction causes this. This is stock GENERIC on the bare metal booted, right ? Yes, stock GENERIC. Please, check this out: Dump of assembler code from 0xff0060c0b700 to 0xff0060c0b780: 0xff0060c0b700: add%al,(%rax) 0xff0060c0b702: add%al,(%rax) 0xff0060c0b704: add%al,(%rax) 0xff0060c0b706: add%al,(%rax) 0xff0060c0b708: add%al,(%rax) 0xff0060c0b70a: add%al,(%rax) 0xff0060c0b70c: add%al,(%rax) 0xff0060c0b70e: add%al,(%rax) 0xff0060c0b710: or %dh,0xffc2(%rax) 0xff0060c0b713: cmp$0xff,%bh 0xff0060c0b716: (bad) 0xff0060c0b717: incl (%rax) 0xff0060c0b719: add%al,(%rcx) 0xff0060c0b71b: add%cl,%bh 0xff0060c0b71d: pop%rsp 0xff0060c0b71e: out%al,(%dx) 0xff0060c0b71f: pop%rdx 0xff0060c0b720: or $0x0,%al 0xff0060c0b722: add%al,(%rax) 0xff0060c0b724: or %al,%fs:(%rax) 0xff0060c0b727: add%ah,%bl 0xff0060c0b729: int3 0xff0060c0b72a: (bad) 0xff0060c0b72b: add%cl,%bh 0xff0060c0b72d: pop%rsp 0xff0060c0b72e: out%al,(%dx) 0xff0060c0b72f: pop%rdx 0xff0060c0b730: iret 0xff0060c0b731: pop%rsp 0xff0060c0b732: out%al,(%dx) 0xff0060c0b733: pop%rdx 0xff0060c0b734: rex xor$0x9f105aee,%eax 0xff0060c0b73a: add%al,(%rax) 0xff0060c0b73c: add%al,(%rax) 0xff0060c0b73e: add%al,(%rax) 0xff0060c0b740: rex pop%rdi 0xff0060c0b742: retq $0xff80 0xff0060c0b745: (bad) 0xff0060c0b746: (bad) 0xff0060c0b747: incl (%rax) 0xff0060c0b749: push %rax 0xff0060c0b74a: loop 0xff0060c0b78e 0xff0060c0b74c: add%bh,%bh 0xff0060c0b74e: (bad) 0xff0060c0b74f: incl (%rax) 0xff0060c0b751: add%al,(%rax) 0xff0060c0b753: add%al,(%rax) 0xff0060c0b755: add%al,(%rax) 0xff0060c0b757: add%dl,(%rax) 0xff0060c0b759: push %rax 0xff0060c0b75a: loop 0xff0060c0b79e 0xff0060c0b75c: add%bh,%bh 0xff0060c0b75e: (bad) 0xff0060c0b75f: incl (%rax) 0xff0060c0b761: add%al,(%rax) 0xff0060c0b763: add%al,(%rax) 0xff0060c0b765: add%al,(%rax) 0xff0060c0b767: add%bl,%al 0xff0060c0b769: pop%rdi 0xff0060c0b76a: retq $0xff80 0xff0060c0b76d: (bad) 0xff0060c0b76e: (bad) 0xff0060c0b76f: incl (%rax) 0xff0060c0b771: add%al,(%rax) 0xff0060c0b773: add%al,(%rax) 0xff0060c0b775: add%al,(%rax) 0xff0060c0b777: add%al,0x290c55(%rax) 0xff0060c0b77d: (bad) 0xff0060c0b77e: (bad) 0xff0060c0b77f: incl (%rax) -- Alexey Tarasov (\__/) (='.'=) E[: | | | | :]З ()_() ___ 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: STABLE kernel panic: privileged instruction fault
On Mon, Aug 16, 2010 at 11:21:15PM +0400, Alexey Tarasov wrote: Hello Kostik! On Aug 16, 2010, at 10:48 PM, Kostik Belousov wrote: The backtrace make absolutely no sense. I would not trust kgdb anyway. Compile ddb in and do backtrace in console on the panic. Also, disassemble the kernel at the fault address. I am very curious which instruction causes this. This is stock GENERIC on the bare metal booted, right ? Yes, stock GENERIC. Please, check this out: Dump of assembler code from 0xff0060c0b700 to 0xff0060c0b780: Would be nice if you keep all requested data in one place, so that we do not need to search for the old mails to see the context. According to your previous mail, the fault happen at the address instruction pointer = 0x20:0xff8040d2cc83 Your disassembled the stack instead. Please just do disass 0xff8040d2cc83,0xff8040d2cca0 in kgdb. But also, I want to see the backtrace and disassembly output from ddb. pgp2XZZMDRqkp.pgp Description: PGP signature
Re: STABLE kernel panic: privileged instruction fault
On Aug 16, 2010, at 11:31 PM, Kostik Belousov wrote: On Mon, Aug 16, 2010 at 11:21:15PM +0400, Alexey Tarasov wrote: Hello Kostik! On Aug 16, 2010, at 10:48 PM, Kostik Belousov wrote: The backtrace make absolutely no sense. I would not trust kgdb anyway. Compile ddb in and do backtrace in console on the panic. Also, disassemble the kernel at the fault address. I am very curious which instruction causes this. This is stock GENERIC on the bare metal booted, right ? Yes, stock GENERIC. Please, check this out: Dump of assembler code from 0xff0060c0b700 to 0xff0060c0b780: Would be nice if you keep all requested data in one place, so that we do not need to search for the old mails to see the context. According to your previous mail, the fault happen at the address instruction pointer = 0x20:0xff8040d2cc83 Your disassembled the stack instead. Please just do disass 0xff8040d2cc83,0xff8040d2cca0 in kgdb. But also, I want to see the backtrace and disassembly output from ddb. (kgdb) disass 0xff8040d2cc83,0xff8040d2cca0 No function contains specified address. I will build kernel with DDB tomorrow, install it on some servers and wait for the panic occurs. -- Alexey Tarasov (\__/) (='.'=) E[: | | | | :]З ()_() ___ 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: STABLE kernel panic: privileged instruction fault
On Mon, Aug 16, 2010 at 11:35:36PM +0400, Alexey Tarasov wrote: On Aug 16, 2010, at 11:31 PM, Kostik Belousov wrote: On Mon, Aug 16, 2010 at 11:21:15PM +0400, Alexey Tarasov wrote: Hello Kostik! On Aug 16, 2010, at 10:48 PM, Kostik Belousov wrote: The backtrace make absolutely no sense. I would not trust kgdb anyway. Compile ddb in and do backtrace in console on the panic. Also, disassemble the kernel at the fault address. I am very curious which instruction causes this. This is stock GENERIC on the bare metal booted, right ? Yes, stock GENERIC. Please, check this out: Dump of assembler code from 0xff0060c0b700 to 0xff0060c0b780: Would be nice if you keep all requested data in one place, so that we do not need to search for the old mails to see the context. According to your previous mail, the fault happen at the address instruction pointer = 0x20:0xff8040d2cc83 Your disassembled the stack instead. Please just do disass 0xff8040d2cc83,0xff8040d2cca0 in kgdb. But also, I want to see the backtrace and disassembly output from ddb. (kgdb) disass 0xff8040d2cc83,0xff8040d2cca0 No function contains specified address. Err, it seems that old gdb accepts only spaces. Please try disass 0xff8040d2cc83 0xff8040d2cca0 instead. I will build kernel with DDB tomorrow, install it on some servers and wait for the panic occurs. Ok. Did you checked for such things as rootkits ? pgpTly6pt0t7A.pgp Description: PGP signature
Re: STABLE kernel panic: privileged instruction fault
On Aug 16, 2010, at 11:39 PM, Kostik Belousov wrote: On Mon, Aug 16, 2010 at 11:35:36PM +0400, Alexey Tarasov wrote: On Aug 16, 2010, at 11:31 PM, Kostik Belousov wrote: On Mon, Aug 16, 2010 at 11:21:15PM +0400, Alexey Tarasov wrote: Hello Kostik! On Aug 16, 2010, at 10:48 PM, Kostik Belousov wrote: The backtrace make absolutely no sense. I would not trust kgdb anyway. Compile ddb in and do backtrace in console on the panic. Also, disassemble the kernel at the fault address. I am very curious which instruction causes this. This is stock GENERIC on the bare metal booted, right ? Yes, stock GENERIC. Please, check this out: Dump of assembler code from 0xff0060c0b700 to 0xff0060c0b780: Would be nice if you keep all requested data in one place, so that we do not need to search for the old mails to see the context. According to your previous mail, the fault happen at the address instruction pointer = 0x20:0xff8040d2cc83 Your disassembled the stack instead. Please just do disass 0xff8040d2cc83,0xff8040d2cca0 in kgdb. But also, I want to see the backtrace and disassembly output from ddb. (kgdb) disass 0xff8040d2cc83,0xff8040d2cca0 No function contains specified address. Err, it seems that old gdb accepts only spaces. Please try disass 0xff8040d2cc83 0xff8040d2cca0 instead. (kgdb) disass 0xff8040d2cc83 0xff8040d2cca0 Dump of assembler code from 0xff8040d2cc83 to 0xff8040d2cca0: 0xff8040d2cc83: (bad) 0xff8040d2cc84: (bad) 0xff8040d2cc85: jg 0xff8040d2cc87 0xff8040d2cc87: add%al,(%rax) 0xff8040d2cc89: add%al,(%rax) 0xff8040d2cc8b: add%al,(%rax) 0xff8040d2cc8d: add%al,(%rax) 0xff8040d2cc8f: add%al,(%rax) 0xff8040d2cc91: add%al,(%rax) 0xff8040d2cc93: add%al,(%rax) 0xff8040d2cc95: add%al,(%rax) 0xff8040d2cc97: add%al,(%rcx) 0xff8040d2cc99: add%al,(%rax) 0xff8040d2cc9b: add%al,(%rax) 0xff8040d2cc9d: add%al,(%rax) 0xff8040d2cc9f: add%al,(%rax) End of assembler dump. I will build kernel with DDB tomorrow, install it on some servers and wait for the panic occurs. Ok. Did you checked for such things as rootkits ? I am noticing such panics only on this model of supermicro servers for a long! time under FreeBSD. This servers were tested on huge workload under Linux and there were no problems. I've installed and run chkrootkit now, there are no rootkits. -- Alexey Tarasov (\__/) (='.'=) E[: | | | | :]З ()_() ___ 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_7 em problems (and RELENG_8)
Hi Jack, FYI, I am still seeing this same problem on RELENG_8 (code as of today). Unfortunately I cant try Pyun's patch since the underlying code has changed since then. e...@pci0:3:0:0: class=0x02 card=0x34ec8086 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c pci3: ACPI PCI bus on pcib3 em4: Intel(R) PRO/1000 Network Connection 7.0.5 port 0x1000-0x101f mem 0xb190-0xb191,0xb192-0xb1923fff irq 16 at device 0.0 on pci3 em4: Using MSI interrupt em4: [FILTER] em4: Ethernet address: 00:15:17:ed:3e:c4 ---Mike At 03:36 PM 7/2/2010, Pyun YongHyeon wrote: On Fri, Jul 02, 2010 at 01:39:22PM -0400, Mike Tancsa wrote: Hi Jack, Just a followup to the email below. I now saw what appears to be the same problem on RELENG_8, but on a different nic and with VLANs. So not sure if this is a general em problem, a problem specific to some em NICs, or a TSO problem in general. The issue seemed to be triggered when I added a new vlan based on e...@pci0:14:0:0:class=0x02 card=0x109a15d9 chip=0x109a8086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel PRO/1000 PL Network Adaptor (82573L)' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) pci14: ACPI PCI bus on pcib5 em3: Intel(R) PRO/1000 Network Connection 7.0.5 port 0x6000-0x601f mem 0xe830-0xe831 irq 17 at device 0.0 on pci14 em3: Using MSI interrupt em3: [FILTER] em3: Ethernet address: 00:30:48:9f:eb:81 em3: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=2098VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC ether 00:30:48:9f:eb:81 inet 10.255.255.254 netmask 0xfffc broadcast 10.255.255.255 media: Ethernet autoselect (1000baseT full-duplex) status: active I had to disable tso, rxcsum and txsum in order to see the devices on the other side of the two vlans trunked off em3. Unfortunately, the other sides were switches 100km and 500km away so I didnt have any tcpdump capabilities to diagnose the issue. I had already created one vlan off this NIC and all was fine. A few weeks later, I added a new one and I could no longer telnet into the remote switches from the local machine But, I could telnet into the switches from machines not on the problem box. Hence, it would appear to be a general TSO issue no ? I disabled tso on the nic (I didnt disable net.inet.tcp.tso as I forgot about that).. Still nothing. I could always ping the remote devices, but no tcp services. I then remembered this issue from before, so I tried disabling tso on the NIC. Still nothing. Then I disabled rxcsum and txcsum and I could then telnet into the remote devices. This newly observed issue was from a buildworld on Mon Jun 14 11:29:12 EDT 2010. I will try and recreate the issue locally again to see if I can trigger the problem on demand. Any thoughts on what it might be ? Perhaps an issue specific to certain em nics ? http://www.freebsd.org/cgi/query-pr.cgi?pr=141843 I'm not sure whether you're seeing the same issue though. I didn't have chance to try latest em(4) on stable/7. Mike Tancsa, tel +1 519 651 3400 Sentex Communications,m...@sentex.net Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ 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
Performance AMD Phenom II X6 1090T
Is there anyone using AMD Phenom II X6 1090T? What can you say about it's performance? Have you any tasks that use all 6-cores? Does it balance workload between all 6 cores properly? I am interested how it will work specifically under 8.1-RELEASE and 9.0-CURRENT. ___ 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
