From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 1 22:31:04 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8DEAB16A41F for ; Thu, 1 Sep 2005 22:31:04 +0000 (GMT) (envelope-from vkashyap@amcc.com) Received: from sdcexchange01.amcc.com (gatekeeper-out.amcc.com [198.137.200.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 330FD43D45 for ; Thu, 1 Sep 2005 22:31:04 +0000 (GMT) (envelope-from vkashyap@amcc.com) Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.326 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Sep 2005 15:31:00 -0700 Message-ID: <2B3B2AA816369A4E87D7BE63EC9D2F269B7B4D@SDCEXCHANGE01.ad.amcc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: panic in propagate_priority w/ postgresql under heavy load thread-index: AcWvQYf3QVjaWsAxQ9mDaYJcbWfdogAAslYg From: "Vinod Kashyap" To: "Koen Martens" , "Dimitry Andric" Cc: freebsd-hackers@freebsd.org Subject: RE: panic in propagate_priority w/ postgresql under heavy load X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2005 22:31:04 -0000 > -----Original Message----- > From: owner-freebsd-hackers@freebsd.org=20 > [mailto:owner-freebsd-hackers@freebsd.org] On Behalf Of Koen Martens > Sent: Thursday, September 01, 2005 3:11 PM > To: Dimitry Andric > Cc: freebsd-hackers@freebsd.org > Subject: Re: panic in propagate_priority w/ postgresql under=20 > heavy load >=20 > Hi Dim, >=20 > Dimitry Andric wrote: > > On 2005-09-01 at 19:02:06 Koen Martens wrote:=20 > >=20 > >>Anyway, it seems the dump should've gone to the swap partition, but=20 > >>i'm into multi-user mode again so i guess i'll have to wait for=20 > >>another panic to obtain it? > >=20 > > In RELENG_6, the dump device is chosen automagically during boot by=20 > > /etc/rc.d/dumpon, but this is (alas) not the case in RELENG_5_x, so=20 > > you'll have to manually specify it in /etc/rc.conf, i.e: > >=20 > > dumpdev=3D/dev/ad0s1b > >=20 > > Then make sure you have enough space in /var/crash, and try to=20 > > reproduce your panic... >=20 > Ok, i get it.. When it reboots it detects a dump on the swap=20 > partition and dd's that to /var/crash.. Which has plenty of=20 > free space on the particular box, 59 gigs ought to be enough=20 > for everyone :) >=20 > > Also, I think I read somewhere that there used to be problems with=20 > > dumping and 3Ware RAID cards (you seem to be using one according to=20 > > your kernel config, but you apparently didn't post a dmesg). >=20 > You're right, dmesg included below. >=20 > > However, > > it looks like revision 1.22.2.1 of src/sys/dev/twe/twe.c fixed that: > >=20 > >=20 > = http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/twe/twe.c?rev=3D1.22.2 > > .1&content-type=3Dtext/x-cvsweb-markup > >=20 > > Just to be sure, can you check if you got this version of twe.c, or > > 1.22.2.2 (which seems to be the RELENG_5_4 version, and=20 > thus it should=20 > > be fixed). >=20 > * $FreeBSD: src/sys/dev/twe/twe.c,v 1.22.2.2 2005/02/18 > 18:42:16 vkashyap > Exp $ >=20 > (nice wrapping, i think you get the idea :) >=20 >=20 > dmesg: >=20 >=20 >=20 > Copyright (c) 1992-2005 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992,=20 > 1993, 1994 > The Regents of the University of California. All rights=20 > reserved. > FreeBSD 5.4-RELEASE-p6 #1: Thu Sep 1 14:06:03 CEST 2005 > root@yin.sonologic.nl:/usr/obj/usr/src/sys/yin-yang-5.4 > WARNING: WITNESS option enabled, expect reduced performance. > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Xeon(TM) CPU 3.06GHz (3056.50-MHz 686-class CPU) > Origin =3D "GenuineIntel" Id =3D 0xf29 Stepping =3D 9 >=20 > Features=3D0xbfebfbff > Hyperthreading: 2 logical CPUs > real memory =3D 2146959360 (2047 MB) > avail memory =3D 2095415296 (1998 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0=20 > (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 6 > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 24-47 on motherboard > ioapic2 irqs 48-71 on motherboard > npx0: on motherboard > npx0: INT 16 interface > acpi0: on motherboard > acpi0: Power Button (fixed) > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 > cpu0: on acpi0 > cpu1: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pci0: at device 0.1 (no driver attached) > pcib1: at device 2.0 on pci0 > pci1: on pcib1 > pci1: at device 28.0=20 > (no driver attached) > pcib2: at device 29.0 on pci1 > pci2: on pcib2 > pci1: at device 30.0=20 > (no driver attached) > pcib3: at device 31.0 on pci1 > pci3: on pcib3 > 3ware device driver for 9000 series storage controllers, version: > 2.50.02.012 > twa0: <3ware 9000 series Storage Controller> port=20 > 0x7000-0x70ff mem 0xfd800000-0xfdffffff,0xfb200000-0xfb2000ff=20 > irq 48 at device 1.0 on pci3 > twa0: 4 ports, Firmware FE9X 2.02.00.008, BIOS BE9X 2.02.01.037 > pci0: at device 2.1 (no driver attached) > pcib4: at device 30.0 on pci0 > pci4: on pcib4 > pci4: at device 3.0 (no driver attached) > fxp0: port 0x8400-0x843f mem=20 > 0xfb300000-0xfb31ffff,0xfb341000-0xfb341fff irq 20 at device=20 > 4.0 on pci4 > miibus0: on fxp0 > inphy0: on miibus0 > inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > fxp0: Ethernet address: 00:02:b3:d8:8a:b5 > em0: =20 > port 0x8440-0x847f mem 0xfb320000-0xfb33ffff irq 23 at device=20 > 5.0 on pci4 > em0: Ethernet address: 00:02:b3:d8:8b:05 > em0: Speed:N/A Duplex:N/A > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port > 0x6c60-0x6c6f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device=20 > 31.1 on pci0 > ata0: channel #0 on atapci0 > ata1: channel #1 on atapci0 > pci0: at device 31.3 (no driver attached) > acpi_button0: on acpi0 > atkbdc0: port 0x64,0x60 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > fdc0: port=20 > 0x3f7,0x3f4-0x3f5,0x3f0-0x3f3 irq 6 drq 2 on acpi0 > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4=20 > flags 0x10 on acpi0 > sio0: type 16550A, console > sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 > sio1: type 16550A > ppc0: port=20 > 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0 > ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode > ppc0: FIFO with 16/16/9 bytes threshold > ppbus0: on ppc0 > plip0: on ppbus0 > lpt0: on ppbus0 > lpt0: Interrupt-driven port > ppi0: on ppbus0 > pmtimer0 on isa0 > orm0: at iomem > 0xe3000-0xe3fff,0xc8000-0xc97ff,0xc0000-0xc7fff on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=3D0x100> > vga0: at port 0x3c0-0x3df iomem=20 > 0xa0000-0xbffff on isa0 Timecounters tick every 10.000 msec > IPv6 packet filtering initialized, default to accept, logging=20 > limited to 10 packets/entry IP Filter: v3.4.35 initialized. =20 > Default =3D block all, Logging =3D enabled > witness_get: witness exhausted > ipfw2 initialized, divert disabled, rule-based forwarding=20 > enabled, default to accept, logging limited to 10=20 > packets/entry by default > acd0: CDROM at ata0-master PIO4 da0 at twa0=20 > bus 0 target 0 lun 0 > da0: <3ware Logical Disk 00 1.00> Fixed Direct Access SCSI-0 device > da0: 100.000MB/s transfers > da0: 114430MB (234352640 512 byte sectors: 255H 63S/T 14587C) > SMP: AP CPU #1 Launched! > Mounting root from ufs:/dev/da0s1a > WARNING: / was not properly dismounted > WARNING: /usr was not properly dismounted > WARNING: /var was not properly dismounted > /var: mount pending error: blocks 1024 files 7 > em0: Link is up 100 Mbps Full Duplex >=20 > twa0: INFO: (0x04: 0x000c): Background initialize started: unit=3D0 > twa0: INFO: (0x04: 0x0007): Background initialize done: unit=3D0 >=20 You seem to be booting off of a 9000 (twa) controller and not 7000/8000 (twe). It could be because of a 9000 firmware bug that you are not being able to get the dump. The firmware wrongly interprets physical address 0x0 as invalid during dumps, and fails the operations. This bug will be fixed in future firmware releases. -------------------------------------------------------- CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, = is for the sole use of the intended recipient(s) and contains = information that is confidential and proprietary to Applied Micro = Circuits Corporation or its subsidiaries. It is to be used solely for = the purpose of furthering the parties' business relationship. All = unauthorized review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply = e-mail and destroy all copies of the original message.