From owner-freebsd-stable@FreeBSD.ORG Sun Dec 21 06:07:59 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E09F81065670 for ; Sun, 21 Dec 2008 06:07:59 +0000 (UTC) (envelope-from nslay@comcast.net) Received: from QMTA08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by mx1.freebsd.org (Postfix) with ESMTP id 6AD6B8FC13 for ; Sun, 21 Dec 2008 06:07:59 +0000 (UTC) (envelope-from nslay@comcast.net) Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA08.westchester.pa.mail.comcast.net with comcast id thah1a00B1HzFnQ58hujTG; Sun, 21 Dec 2008 05:54:43 +0000 Received: from LIGHTBULB.LOCAL ([68.35.224.189]) by OMTA14.westchester.pa.mail.comcast.net with comcast id thu81a00345o48c3ahuA5u; Sun, 21 Dec 2008 05:54:11 +0000 Message-ID: <494DDA1B.6050206@comcast.net> Date: Sun, 21 Dec 2008 00:54:35 -0500 From: Nathan Lay User-Agent: Thunderbird 2.0.0.17 (X11/20081110) MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-stable Content-Type: multipart/mixed; boundary="------------050606040706090609080709" Cc: Subject: Very serious cooling issues CURRENT/STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Dec 2008 06:08:00 -0000 This is a multi-part message in MIME format. --------------050606040706090609080709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi list(s) Early in the year I noticed CURRENT failed to cool my frankenstein Thinkpad T40 (built from T40/40p parts) under load. The system would shut down from critically high temperatures while building a port. I did nothing special with ACPI. I thought nothing of it since, after all, I rebuilt a broken T40 from T40p parts. Today, however, I noticed that a very recent STABLE build failed to keep my T43 cool while building ports. It reached temperatures of 97, 98, 99C. It used to reach a max temperature of 80C while building a port (idling temperature is ~ 45C). It behaved normally from 5.3 all the way through 7.0. To remedy both issues, I had to underclock the processor (via dev.cpu) and force the fan to its highest (I'm running 533MHz shy of the processor's full potential, with a fan level of 7 to keep the temperature at ~75C). I've always suspected FreeBSD's ACPI didn't work properly on Thinkpad T series laptops (I have T40, T41, T42 and T43) as it could never fully use the fan (Windows XP can rev the fan far higher than acpi_ibm's level 7). Between STABLE and CURRENT...something seems very wrong. These systems never had cooling issues with FreeBSD before. I attached my dmesg and sysctl for hw.acpi, dev.acpi_ibm, and dev.cpu for both machines. I don't think the latter three pieces of information will be useful but I could be wrong. Let me know if there is any other information I can provide. Best Regards, Nathan Lay --------------050606040706090609080709 Content-Type: text/plain; name="freebsd-stable-acpi" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="freebsd-stable-acpi" hw.acpi.supported_sleep_state: S3 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S3 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 1 hw.acpi.s4bios: 0 hw.acpi.verbose: 0 hw.acpi.disable_on_reboot: 0 hw.acpi.handle_reboot: 0 hw.acpi.reset_video: 0 hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: 76.0C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 94.5C hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 99.0C hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: 5 hw.acpi.thermal.tz0._TC2: 4 hw.acpi.thermal.tz0._TSP: 600 hw.acpi.battery.life: 99 hw.acpi.battery.time: -1 hw.acpi.battery.state: 0 hw.acpi.battery.units: 1 hw.acpi.battery.info_expire: 5 hw.acpi.acline: 1 hw.acpi.cpu.cx_lowest: C1 --------------050606040706090609080709 Content-Type: text/plain; name="freebsd-stable-acpi_ibm" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="freebsd-stable-acpi_ibm" dev.acpi_ibm.0.%desc: IBM ThinkPad ACPI Extras dev.acpi_ibm.0.%driver: acpi_ibm dev.acpi_ibm.0.%location: handle=\_SB_.PCI0.LPC_.EC__.HKEY dev.acpi_ibm.0.%pnpinfo: _HID=IBM0068 _UID=0 dev.acpi_ibm.0.%parent: acpi0 dev.acpi_ibm.0.initialmask: 2060 dev.acpi_ibm.0.availmask: 16777215 dev.acpi_ibm.0.events: 0 dev.acpi_ibm.0.eventmask: 2060 dev.acpi_ibm.0.hotkey: 415 dev.acpi_ibm.0.lcd_brightness: 7 dev.acpi_ibm.0.volume: 12 dev.acpi_ibm.0.mute: 1 dev.acpi_ibm.0.thinklight: 0 dev.acpi_ibm.0.bluetooth: 0 dev.acpi_ibm.0.wlan: 1 dev.acpi_ibm.0.fan_speed: 4684 dev.acpi_ibm.0.fan_level: 7 dev.acpi_ibm.0.fan: 0 dev.acpi_ibm.0.thermal: 76 51 40 61 35 -1 28 -1 --------------050606040706090609080709 Content-Type: text/plain; name="freebsd-stable-dmesg" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="freebsd-stable-dmesg" 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.1-PRERELEASE #0: Wed Dec 10 04:09:36 EST 2008 nslay@LIGHTBULB.LOCAL:/usr/obj/usr/src/sys/LIGHTBULB module_register: module g_journal already exists! Module g_journal failed to register: 17 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) M processor 1.86GHz (1862.14-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6d8 Stepping = 8 Features=0xafe9fbff Features2=0x180 AMD Features=0x100000 real memory = 1609433088 (1534 MB) avail memory = 1567776768 (1495 MB) This module (opensolaris) contains code covered by the Common Development and Distribution License (CDDL) see http://opensolaris.org/os/licensing/opensolaris_license/ kbd1 at kbdmux0 netsmb_dev: loaded ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) ACPI Warning (tbfadt-0505): Optional field "Gpe1Block" has zero address or length: 0 102C/0 [20070320] acpi0: on motherboard acpi0: [ITHREAD] acpi_ec0: port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 5ff00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 11 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0x3000-0x30ff mem 0xc0000000-0xc7ffffff,0xb0100000-0xb010ffff irq 11 at device 0.0 on pci1 drm0: on vgapci0 info: [drm] Initialized radeon 1.25.0 20060524 pcib2: irq 11 at device 28.0 on pci0 pci2: on pcib2 bge0: mem 0xb0200000-0xb020ffff irq 11 at device 0.0 on pci2 miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: Ethernet address: 00:15:58:09:1b:e7 bge0: [ITHREAD] pcib3: irq 11 at device 28.2 on pci0 pci3: on pcib3 uhci0: port 0x1800-0x181f irq 11 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1820-0x183f irq 11 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x1840-0x185f irq 11 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x1860-0x187f irq 11 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xb0000000-0xb00003ff irq 11 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered pcib4: at device 30.0 on pci0 pci11: on pcib4 cbb0: mem 0xb4000000-0xb4000fff irq 11 at device 0.0 on pci11 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [ITHREAD] pcm0: port 0x1c00-0x1cff,0x1880-0x18bf mem 0xb0000800-0xb00009ff,0xb0000400-0xb00004ff irq 11 at device 30.2 on pci0 pcm0: [ITHREAD] pcm0: pci0: at device 30.3 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x18c0-0x18cf at device 31.2 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: flags 0x1000 irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 8250 or not responding sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled battery0: on acpi0 acpi_acad0: on acpi0 acpi_ibm0: on acpi0 cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcffff,0xd1800-0xd27ff,0xdc000-0xdffff,0xe0000-0xeffff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: at port 0x278-0x27f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 ppbus0: [ITHREAD] plip0: on ppbus0 plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled ugen0: on uhub2 WARNING: ZFS is considered to be an experimental feature in FreeBSD. Timecounter "TSC" frequency 1862138034 Hz quality 800 Timecounters tick every 1.000 msec The GEOM class JOURNAL is already loaded. ZFS filesystem version 6 ZFS storage pool version 6 ad0: 57231MB at ata0-master UDMA100 acd0: DVDR at ata1-master UDMA33 GEOM_JOURNAL: Journal 273940673: ad0s1e contains data. GEOM_JOURNAL: Journal 273940673: ad0s1e contains journal. GEOM_JOURNAL: Journal ad0s1e clean. Trying to mount root from ufs:/dev/ad0s1a ath0: mem 0xb4010000-0xb401ffff irq 11 at device 0.0 on cardbus0 ath0: [ITHREAD] ath0: WARNING: using obsoleted if_watchdog interface ath0: Ethernet address: 00:18:4d:8e:51:42 ath0: mac 7.9 phy 4.5 radio 5.6 WARNING: TMPFS is considered to be a highly experimental feature in FreeBSD. bridge0: Ethernet address: 96:e4:69:df:24:5b info: [drm] Setting GART location based on new memory map info: [drm] Loading R300 Microcode info: [drm] writeback test succeeded in 1 usecs drm0: [ITHREAD] --------------050606040706090609080709 Content-Type: text/plain; name="freebsd-stable-cpu" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="freebsd-stable-cpu" dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU_ dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 1333 dev.cpu.0.freq_levels: 1866/27000 1632/23625 1600/23700 1400/20737 1333/20400 1166/17850 1066/17100 932/14962 800/13800 700/12075 600/10350 500/8625 400/6900 300/5175 200/3450 100/1725 dev.cpu.0.cx_supported: C1/1 C2/1 C3/85 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% --------------050606040706090609080709 Content-Type: text/plain; name="freebsd-current-acpi" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="freebsd-current-acpi" hw.acpi.supported_sleep_state: S3 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S3 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 1 hw.acpi.s4bios: 0 hw.acpi.verbose: 0 hw.acpi.disable_on_reboot: 0 hw.acpi.handle_reboot: 0 hw.acpi.reset_video: 0 hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: 37.0C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 89.5C hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 93.0C hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: 5 hw.acpi.thermal.tz0._TC2: 4 hw.acpi.thermal.tz0._TSP: 600 hw.acpi.battery.life: 69 hw.acpi.battery.time: 31 hw.acpi.battery.state: 1 hw.acpi.battery.units: 1 hw.acpi.battery.info_expire: 5 hw.acpi.acline: 0 hw.acpi.cpu.cx_lowest: C1 --------------050606040706090609080709 Content-Type: text/plain; name="freebsd-current-acpi_ibm" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="freebsd-current-acpi_ibm" dev.acpi_ibm.0.%desc: IBM ThinkPad ACPI Extras dev.acpi_ibm.0.%driver: acpi_ibm dev.acpi_ibm.0.%location: handle=\_SB_.PCI0.LPC_.EC__.HKEY dev.acpi_ibm.0.%pnpinfo: _HID=IBM0068 _UID=0 dev.acpi_ibm.0.%parent: acpi0 dev.acpi_ibm.0.initialmask: 2060 dev.acpi_ibm.0.availmask: 16777215 dev.acpi_ibm.0.events: 0 dev.acpi_ibm.0.eventmask: 2060 dev.acpi_ibm.0.hotkey: 3328 dev.acpi_ibm.0.lcd_brightness: 7 dev.acpi_ibm.0.volume: 8 dev.acpi_ibm.0.mute: 1 dev.acpi_ibm.0.thinklight: 0 dev.acpi_ibm.0.bluetooth: 0 dev.acpi_ibm.0.wlan: 1 dev.acpi_ibm.0.fan_speed: 0 dev.acpi_ibm.0.fan_level: 0 dev.acpi_ibm.0.fan: 1 dev.acpi_ibm.0.thermal: 37 36 31 37 29 -1 25 -1 --------------050606040706090609080709 Content-Type: text/plain; name="freebsd-current-cpu" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="freebsd-current-cpu" dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU_ dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 1200 dev.cpu.0.freq_levels: 1600/-1 1400/-1 1225/-1 1200/-1 1050/-1 1000/-1 875/-1 800/-1 700/-1 600/-1 525/-1 450/-1 375/-1 300/-1 225/-1 150/-1 75/-1 dev.cpu.0.cx_supported: C1/1 C2/1 C3/85 C4/185 dev.cpu.0.cx_lowest: C3 dev.cpu.0.cx_usage: 0.00% 100.00% 0.00% 0.00% --------------050606040706090609080709 Content-Type: text/plain; name="freebsd-current-dmesg" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="freebsd-current-dmesg" 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 8.0-CURRENT #0 r186194: Tue Dec 16 22:46:15 EST 2008 nslay@BOTTLE.LOCAL:/usr/obj/usr/src/sys/BOTTLE WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) M processor 1600MHz (598.06-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x695 Stepping = 5 Features=0xa7e9f9bf Features2=0x180 real memory = 804651008 (767 MB) avail memory = 774418432 (738 MB) kbd1 at kbdmux0 ACPI Warning (tbfadt-0505): Optional field "Gpe1Block" has zero address or length: 0 102C/0 [20070320] acpi0: on motherboard acpi0: [ITHREAD] acpi_ec0: port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 2ff00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0x3000-0x30ff mem 0xe0000000-0xe7ffffff,0xc0100000-0xc010ffff irq 11 at device 0.0 on pci1 uhci0: port 0x1800-0x181f irq 11 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1820-0x183f irq 11 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x1840-0x185f irq 11 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xc0000000-0xc00003ff irq 11 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered pcib2: at device 30.0 on pci0 pci2: on pcib2 cbb0: mem 0xb0000000-0xb0000fff irq 11 at device 0.0 on pci2 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [FILTER] cbb1: mem 0xb1000000-0xb1000fff irq 11 at device 0.1 on pci2 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 cbb1: [FILTER] em0: port 0x8000-0x803f mem 0xc0220000-0xc023ffff,0xc0200000-0xc020ffff irq 11 at device 1.0 on pci2 em0: [FILTER] em0: Ethernet address: 00:09:6b:5f:3a:d0 pci2: at device 2.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) pcm0: port 0x1c00-0x1cff,0x18c0-0x18ff mem 0xc0000c00-0xc0000dff,0xc0000800-0xc00008ff irq 11 at device 31.5 on pci0 pcm0: [ITHREAD] pcm0: pci0: at device 31.6 (no driver attached) acpi_tz0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] battery0: on acpi0 acpi_acad0: on acpi0 acpi_ibm0: on acpi0 cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcffff,0xd0000-0xd0fff,0xd1000-0xd1fff,0xdc000-0xdffff,0xe0000-0xeffff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: at port 0x278-0x27f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 Timecounter "TSC" frequency 598063934 Hz quality 800 Timecounters tick every 1.000 msec ad0: 38154MB at ata0-master UDMA100 cardbus1: Expecting link target, got 0x0 cardbus1: Expecting link target, got 0x0 ral0: mem 0xc0218000-0xc021ffff irq 11 at device 0.0 on cardbus1 ral0: MAC/BBP RT2561C, RF RT2527 ral0: [ITHREAD] acd0: CDRW at ata1-master UDMA33 WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/ad0s1a lock order reversal: 1st 0xc3c6f044 user map (user map) @ /usr/src/sys/vm/vm_map.c:3115 2nd 0xc3dec7ac ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2079 KDB: stack backtrace: db_trace_self_wrapper(c087b43a,c3b6f918,c05eaa75,4,c0876c93,...) at db_trace_self_wrapper+0x26 kdb_backtrace(4,c0876c93,c3c29728,c3c2ea70,c3b6f974,...) at kdb_backtrace+0x29 _witness_debugger(c087df1b,c3dec7ac,c0871dfd,c3c2ea70,c0884d51,...) at _witness_debugger+0x25 witness_checkorder(c3dec7ac,1,c0884d51,81f,0,...) at witness_checkorder+0x82b __lockmgr_args(c3dec7ac,200501,c3dec7c8,0,0,...) at __lockmgr_args+0x228 ffs_lock(c3b6fa80,c05ea81b,c08a09cb,200501,c3dec754,...) at ffs_lock+0x82 VOP_LOCK1_APV(c08f5740,c3b6fa80,c3c6ce24,c0905280,c3dec754,...) at VOP_LOCK1_APV+0xa5 _vn_lock(c3dec754,200501,c0884d51,81f,4,...) at _vn_lock+0x5e vget(c3dec754,200501,c3c6cd80,4b4,0,...) at vget+0xcb vnode_pager_lock(c14442e8,0,c089dfa4,127,c3b6fc18,...) at vnode_pager_lock+0x1d9 vm_fault(c3c6f000,80db000,2,8,80db000,...) at vm_fault+0x1e9 trap_pfault(5,0,c08a93ff,2e7,c,...) at trap_pfault+0xf5 trap(c3b6fd38) at trap+0x26f calltrap() at calltrap+0x6 --- trap 0xc, eip = 0x80480e5, esp = 0xbfbfeef0, ebp = 0xbfbfef10 --- wlan0: Ethernet address: 00:11:50:dc:4c:ed ral0: need multicast update callback ral0: need multicast update callback --------------050606040706090609080709-- From owner-freebsd-stable@FreeBSD.ORG Sun Dec 21 09:55:08 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33170106564A for ; Sun, 21 Dec 2008 09:55:08 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id E797F8FC0C for ; Sun, 21 Dec 2008 09:55:07 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mobileKamikaze.norad (unknown [92.117.157.151]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id 4419A8A00D1; Sun, 21 Dec 2008 10:54:43 +0100 (CET) Message-ID: <494E1258.9010500@bsdforen.de> Date: Sun, 21 Dec 2008 10:54:32 +0100 From: Dominic Fandrey User-Agent: Thunderbird 2.0.0.18 (X11/20081123) MIME-Version: 1.0 To: =?UTF-8?B?TWFyaXVzIE7DvG5uZXJpY2g=?= References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org Subject: Re: Kernel not mounting root X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Dec 2008 09:55:08 -0000 Marius NĂ¼nnerich wrote: > Hi all, > > I did cvsup to 7-STABLE yesterday, build, installed and booted a new > kernel then buildworld. > Then I noticed that my PS/2 keyboard is not working at the loader menu > so I booted multiuser and did the make installworld part from there. > Then I tried to reboot but now it hangs after the line > Trying to mount root from ufs:/dev/ad4s1a > > It sits there for at least 10min. I tried so far: > - Installing 7.1-beta2 on another hd and booting it, it works. > - Copied that kernel to the old hd > - Moved kernel.old to kernel > - fsck everything > - mounted everything from the old hd under /mnt, chroot into that, installworld > > Anyone else seeing this or has an idea what to do next? > > Kind regards > Marius I encountered something similar with RC-1, yesterday. The installer entered the devices ad4s4a till ad4s4f instead of ad4s3a till ad4s3f into the fstab file. The annoying problem that you need to mount /usr to run /rescue/vi, because it needs a file from /usr/share is also still present. This makes /rescue/vi nearly useless in my opinion and honestly, ee is really awkward to use. Regards From owner-freebsd-stable@FreeBSD.ORG Sun Dec 21 11:04:38 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E46C11065679 for ; Sun, 21 Dec 2008 11:04:38 +0000 (UTC) (envelope-from nakal@web.de) Received: from fmmailgate03.web.de (fmmailgate03.web.de [217.72.192.234]) by mx1.freebsd.org (Postfix) with ESMTP id 79B6A8FC0C for ; Sun, 21 Dec 2008 11:04:31 +0000 (UTC) (envelope-from nakal@web.de) Received: from smtp05.web.de (fmsmtp05.dlan.cinetic.de [172.20.4.166]) by fmmailgate03.web.de (Postfix) with ESMTP id D8EF0F5AA215; Sun, 21 Dec 2008 12:04:29 +0100 (CET) Received: from [217.236.25.40] (helo=zelda.local) by smtp05.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.110 #273) id 1LEM6n-00029a-00; Sun, 21 Dec 2008 12:04:29 +0100 Date: Sun, 21 Dec 2008 12:04:27 +0100 From: Martin To: Nathan Lay Message-ID: <20081221120427.2dfde4b1@zelda.local> In-Reply-To: <494DDA1B.6050206@comcast.net> References: <494DDA1B.6050206@comcast.net> X-Mailer: Claws Mail 3.6.0 (GTK+ 2.12.11; amd64-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: nakal@web.de X-Sender: nakal@web.de X-Provags-ID: V01U2FsdGVkX19+81Q/qBPQhr1/Bw6MSJywtKaNihjJDEcb6mqa H88g8s3mAJ+D5hW/mwHMydBYEauvWppbZ8qeAuVV0xGxMNGNtR 5vMJcNZt8= Cc: freebsd-stable Subject: Re: Very serious cooling issues CURRENT/STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Dec 2008 11:04:39 -0000 Am Sun, 21 Dec 2008 00:54:35 -0500 schrieb Nathan Lay : > Hi list(s) > Early in the year I noticed CURRENT failed to cool my frankenstein=20 > Thinkpad T40 (built from T40/40p parts) under load. The system would=20 > shut down from critically high temperatures while building a port. I=20 > did nothing special with ACPI. I thought nothing of it since, after=20 > all, I rebuilt a broken T40 from T40p parts. Today, however, I > noticed that a very recent STABLE build failed to keep my T43 cool > while building ports. It reached temperatures of 97, 98, 99C. Hallo Nathan, I can confirm this on a T60p. My notebooks shuts down since I use 7.0 at 101=C2=B0C. I have written a script that throttles the CPU if it gets above 75=C2=B0C. I have to use it when I'm building world or ports. Btw, I have reported the problem here a some time ago [1]. I have received some feedback that IBM/Lenovo uses wrong cooling strategy placing the CPU and the VGA under one single cooled surface and using too much thermal grease. On the other hand I have also emphasized that the fan should be able to have about 800rpm more at the temperature of 80=C2=B0C, but this has been ignored so far. This is why I have never had any problems running "the other common operating systems" and I have put them under heavy load. They don't exceed 85=C2=B0C. > It > used to reach a max temperature of 80C while building a port (idling > temperature is ~ 45C). It behaved normally from 5.3 all the way > through 7.0. To remedy both issues, I had to underclock the > processor (via dev.cpu) and force the fan to its highest (I'm running > 533MHz shy of the processor's full potential, with a fan level of 7 > to keep the temperature at ~75C). I have one further hint for you. The VGA is running very hot on FreeBSD (~75=C2=B0C when idle), because it is not able to throttle the GPU and its voltage. Maybe you've had a working setup for your GPU before and you even did not notice? Did you change your Xorg drivers? > I've always suspected FreeBSD's > ACPI didn't work properly on Thinkpad T series laptops (I have T40, > T41, T42 and T43) as it could never fully use the fan (Windows XP can > rev the fan far higher than acpi_ibm's level 7). Between STABLE and > CURRENT...something seems very wrong. These systems never had > cooling issues with FreeBSD before. The fan is running definitely too slow. On my system, too. Thanks, Martin References: [1] http://lists.freebsd.org/pipermail/freebsd-stable/2008-June/042812.html From owner-freebsd-stable@FreeBSD.ORG Sun Dec 21 11:22:52 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D47B1065670 for ; Sun, 21 Dec 2008 11:22:52 +0000 (UTC) (envelope-from marius@nuenneri.ch) Received: from mail-gx0-f19.google.com (mail-gx0-f19.google.com [209.85.217.19]) by mx1.freebsd.org (Postfix) with ESMTP id 142CC8FC12 for ; Sun, 21 Dec 2008 11:22:51 +0000 (UTC) (envelope-from marius@nuenneri.ch) Received: by gxk12 with SMTP id 12so882585gxk.19 for ; Sun, 21 Dec 2008 03:22:50 -0800 (PST) Received: by 10.90.118.19 with SMTP id q19mr2734906agc.21.1229858570770; Sun, 21 Dec 2008 03:22:50 -0800 (PST) Received: by 10.90.73.15 with HTTP; Sun, 21 Dec 2008 03:22:50 -0800 (PST) Message-ID: Date: Sun, 21 Dec 2008 12:22:50 +0100 From: "=?ISO-8859-1?Q?Marius_N=FCnnerich?=" To: "Dominic Fandrey" , freebsd-stable@freebsd.org In-Reply-To: <494E1258.9010500@bsdforen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <494E1258.9010500@bsdforen.de> Cc: Subject: Re: Kernel not mounting root X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Dec 2008 11:22:52 -0000 On Sun, Dec 21, 2008 at 10:54 AM, Dominic Fandrey wr= ote: > Marius N=FCnnerich wrote: >> Hi all, >> >> I did cvsup to 7-STABLE yesterday, build, installed and booted a new >> kernel then buildworld. >> Then I noticed that my PS/2 keyboard is not working at the loader menu >> so I booted multiuser and did the make installworld part from there. >> Then I tried to reboot but now it hangs after the line >> Trying to mount root from ufs:/dev/ad4s1a >> >> It sits there for at least 10min. I tried so far: >> - Installing 7.1-beta2 on another hd and booting it, it works. >> - Copied that kernel to the old hd >> - Moved kernel.old to kernel >> - fsck everything >> - mounted everything from the old hd under /mnt, chroot into that, insta= llworld >> >> Anyone else seeing this or has an idea what to do next? >> >> Kind regards >> Marius > > I encountered something similar with RC-1, yesterday. The installer enter= ed > the devices ad4s4a till ad4s4f instead of ad4s3a till ad4s3f into the fst= ab > file. That is different ad4s1a would be the right partition in my case. From owner-freebsd-stable@FreeBSD.ORG Sun Dec 21 13:14:27 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 229851065675; Sun, 21 Dec 2008 13:14:27 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-gx0-f19.google.com (mail-gx0-f19.google.com [209.85.217.19]) by mx1.freebsd.org (Postfix) with ESMTP id A6F2F8FC0C; Sun, 21 Dec 2008 13:14:26 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by gxk12 with SMTP id 12so899510gxk.19 for ; Sun, 21 Dec 2008 05:14:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=sHOsx/Q0dmlESAuBC7//YjzRi4FRAg0yFGAm7bc6yPo=; b=vDJiVRrAhv+sQ92cLMfb47c1BbogHdXBkC0fmPZ3hC50bMcy/CGF0Z0DRAZ/BeioN6 4L8dW02+NmQcvWY1NXJqcaRiUJRnrjhOliD5m3qZK+T+dxvP5zcFjEf7XP5ooaNGSper BIJYOKpwafp9Gd1JZnSKfhAhG0r7+jBpgS1sU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=wqmG2Rxf0tvxPg9AD/ADYrNPwRX7m3R/QWdospf8xdEn5zhMrso7Wt/cR7tkjW6jb4 yGcrTHINoRL2NBRYSKHN9qFbp541eVA+MCc/TZheryA26kglua4KA3pey3UCS/5qKAOw uPA/sTnD/IWxSxb9ivZKhwNilh/j2j1eu7ewg= Received: by 10.231.16.129 with SMTP id o1mr132911iba.47.1229865265742; Sun, 21 Dec 2008 05:14:25 -0800 (PST) Received: by 10.231.17.8 with HTTP; Sun, 21 Dec 2008 05:14:25 -0800 (PST) Message-ID: <3a142e750812210514k6dc41c0o32d7ef57e765dcc8@mail.gmail.com> Date: Sun, 21 Dec 2008 14:14:25 +0100 From: "Paul B. Mahol" To: "Nathan Lay" In-Reply-To: <494DDA1B.6050206@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <494DDA1B.6050206@comcast.net> Cc: freebsd-current@freebsd.org, freebsd-stable Subject: Re: Very serious cooling issues CURRENT/STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Dec 2008 13:14:27 -0000 On 12/21/08, Nathan Lay wrote: > acpi.thermal.min_runtime: 0 > hw.acpi.thermal.polling_rate: 10 > hw.acpi.thermal.user_override: 0 > hw.acpi.thermal.tz0.temperature: 37.0C > hw.acpi.thermal.tz0.active: -1 Is this one ever changed? > hw.acpi.thermal.tz0.passive_cooling: 1 > hw.acpi.thermal.tz0.thermal_flags: 0 > hw.acpi.thermal.tz0._PSV: 89.5C > hw.acpi.thermal.tz0._HOT: -1 > hw.acpi.thermal.tz0._CRT: 93.0C > hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 This one means that coling will never be used, why: my output looks like this: hw.acpi.thermal.tz0._ACx: 85.0C 75.0C 60.0C 50.0C -1 -1 -1 -1 -1 -1 > hw.acpi.thermal.tz0._TC1: 5 > hw.acpi.thermal.tz0._TC2: 4 > hw.acpi.thermal.tz0._TSP: 600 You can play with all thermal values once you enable: hw.acpi.thermal.user_override But acpi may redo such values again after some time. You only real workaround is to use modified acpi ASL: it is explained in handbook. In my case I fixed in that way bogus kernel message "_CRT value is absurd, ignored". -- Paul From owner-freebsd-stable@FreeBSD.ORG Sun Dec 21 15:09:06 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 825681065670 for ; Sun, 21 Dec 2008 15:09:06 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [220.233.188.227]) by mx1.freebsd.org (Postfix) with ESMTP id 9C3A38FC0C for ; Sun, 21 Dec 2008 15:09:05 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id mBLEwHq2074030; Mon, 22 Dec 2008 01:58:18 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 22 Dec 2008 01:58:17 +1100 (EST) From: Ian Smith To: Martin In-Reply-To: <20081221120427.2dfde4b1@zelda.local> Message-ID: <20081222004228.G29108@sola.nimnet.asn.au> References: <494DDA1B.6050206@comcast.net> <20081221120427.2dfde4b1@zelda.local> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-61406932-1229869720=:29108" Content-ID: <20081222013231.R29108@sola.nimnet.asn.au> Cc: freebsd-stable , Nathan Lay Subject: Re: Very serious cooling issues CURRENT/STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Dec 2008 15:09:06 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-61406932-1229869720=:29108 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-ID: <20081222013231.P29108@sola.nimnet.asn.au> On Sun, 21 Dec 2008, Martin wrote: > Am Sun, 21 Dec 2008 00:54:35 -0500 > schrieb Nathan Lay : > > > Hi list(s) > > Early in the year I noticed CURRENT failed to cool my frankenstein > > Thinkpad T40 (built from T40/40p parts) under load. The system would > > shut down from critically high temperatures while building a port. I > > did nothing special with ACPI. I thought nothing of it since, after > > all, I rebuilt a broken T40 from T40p parts. Today, however, I > > noticed that a very recent STABLE build failed to keep my T43 cool > > while building ports. It reached temperatures of 97, 98, 99C. Nathan, have you cleaned out airpaths, heatsinks, thermal paste etc recently? Just checking; people have reported drastic improvements. > Hallo Nathan, > > I can confirm this on a T60p. My notebooks shuts down since I use 7.0 > at 101°C. I have written a script that throttles the CPU if it gets > above 75°C. I have to use it when I'm building world or ports. > > Btw, I have reported the problem here a some time ago [1]. I have > received some feedback that IBM/Lenovo uses wrong cooling strategy > placing the CPU and the VGA under one single cooled surface and using > too much thermal grease. We keep hearing that, but that shouldn't affect the T40 or T43 .. so addressing the maximum fan speed issue below is more a 'last resort'; overriding and lowering the _PSV value for .tz0 might help via p4tcc? > On the other hand I have also emphasized that the fan should be able to > have about 800rpm more at the temperature of 80°C, but this has been > ignored so far. This is why I have never had any problems running "the > other common operating systems" and I have put them under heavy load. > They don't exceed 85°C. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/acpi_support/acpi_ibm.c?rev=1.17 Comments in acpi_ibm_sysctl_get, case ACPI_IBM_METHOD_FANLEVEL: say that setting bit 6 (IBM_EC_MASK_FANDISENGAGED) of IBM_EC_FANSTATUS overrides the fan speed limit, which linux allows, 'doze too apparently. acpi_ibm_sysctl_set currently rejects fan levels higher than 7, ie does not allow running the fan disengaged, but that's something you could fix at your own risk .. it's been suggested that this could wear the fan out more quickly, so I guess acpi_ibm is tending to be conservative here. It doesn't look hard to at least allow values with bit 6 set (ie 64-127) in acpi_ibm_sysctl_set, case ACPI_IBM_METHOD_FANLEVEL: and a bit more work to preserve that bit in the _get values. It looks like you might need to set the fan in manual mode too (dev.acpi_ibm.0.fan=0) but test! > > It > > used to reach a max temperature of 80C while building a port (idling > > temperature is ~ 45C). It behaved normally from 5.3 all the way > > through 7.0. To remedy both issues, I had to underclock the > > processor (via dev.cpu) and force the fan to its highest (I'm running > > 533MHz shy of the processor's full potential, with a fan level of 7 > > to keep the temperature at ~75C). > > I have one further hint for you. The VGA is running very hot on > FreeBSD (~75°C when idle), because it is not able to throttle the GPU > and its voltage. Maybe you've had a working setup for your GPU before > and you even did not notice? Did you change your Xorg drivers? > > > I've always suspected FreeBSD's > > ACPI didn't work properly on Thinkpad T series laptops (I have T40, > > T41, T42 and T43) as it could never fully use the fan (Windows XP can > > rev the fan far higher than acpi_ibm's level 7). Between STABLE and > > CURRENT...something seems very wrong. These systems never had > > cooling issues with FreeBSD before. > > The fan is running definitely too slow. On my system, too. I guess if I was having overheating issues with my T23 and was confident with C and its debugging, I'd have a go at this .. but I am neither .. > Thanks, > Martin > > > References: > [1] > http://lists.freebsd.org/pipermail/freebsd-stable/2008-June/042812.html cheers, Ian --0-61406932-1229869720=:29108-- From owner-freebsd-stable@FreeBSD.ORG Sun Dec 21 15:47:10 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2310106564A for ; Sun, 21 Dec 2008 15:47:10 +0000 (UTC) (envelope-from nakal@web.de) Received: from fmmailgate03.web.de (fmmailgate03.web.de [217.72.192.234]) by mx1.freebsd.org (Postfix) with ESMTP id 71D448FC1A for ; Sun, 21 Dec 2008 15:47:10 +0000 (UTC) (envelope-from nakal@web.de) Received: from smtp08.web.de (fmsmtp08.dlan.cinetic.de [172.20.5.216]) by fmmailgate03.web.de (Postfix) with ESMTP id 07DC7F5AC6C8; Sun, 21 Dec 2008 16:47:09 +0100 (CET) Received: from [217.236.25.40] (helo=zelda.local) by smtp08.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.110 #273) id 1LEQWK-0002D3-00; Sun, 21 Dec 2008 16:47:08 +0100 Date: Sun, 21 Dec 2008 16:47:07 +0100 From: Martin To: Ken Smith Message-ID: <20081221164707.4538402a@zelda.local> In-Reply-To: <1228876766.35416.23.camel@bauer.cse.buffalo.edu> References: <1228876766.35416.23.camel@bauer.cse.buffalo.edu> X-Mailer: Claws Mail 3.6.0 (GTK+ 2.12.11; amd64-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: nakal@web.de X-Sender: nakal@web.de X-Provags-ID: V01U2FsdGVkX19dUxJkld2FI3wlXzjOAS8+LkWFB79PvIdDO7XV 9+pcCNGehetgNNm9YfL+d+ADG3zocZ4AZZezjitWpR9sXgsdm+ gn5ewoiRk= Cc: freebsd-stable Subject: Re: FreeBSD 7.1-RC1 Available... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Dec 2008 15:47:10 -0000 Am Tue, 09 Dec 2008 21:39:26 -0500 schrieb Ken Smith : > FreeBSD 7.1-RC1 is now available, the first of the Release Candidates. > There will be at least one more Release Candidate before the release > so the release itself is likely around 3 weeks from now IF no new > show-stoppers are uncovered during testing. Hi, I have just tried to use the RC1-livefs-CD (i386). It seems, I cannot boot it. I tried 3 different CD-R(W)s and three different drives (even one SCSI drive!). -- Martin From owner-freebsd-stable@FreeBSD.ORG Sun Dec 21 16:55:16 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 513DC1065676 for ; Sun, 21 Dec 2008 16:55:16 +0000 (UTC) (envelope-from nslay@comcast.net) Received: from QMTA08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by mx1.freebsd.org (Postfix) with ESMTP id 39AD18FC0C for ; Sun, 21 Dec 2008 16:55:16 +0000 (UTC) (envelope-from nslay@comcast.net) Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA08.emeryville.ca.mail.comcast.net with comcast id trym1a00B1GXsucA8sfGGF; Sun, 21 Dec 2008 16:39:16 +0000 Received: from LIGHTBULB.LOCAL ([68.35.224.189]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id tsfC1a00745o48c8TsfFcq; Sun, 21 Dec 2008 16:39:16 +0000 Message-ID: <494E712B.802@comcast.net> Date: Sun, 21 Dec 2008 11:39:07 -0500 From: Nathan Lay User-Agent: Thunderbird 2.0.0.17 (X11/20081110) MIME-Version: 1.0 To: "Paul B. Mahol" References: <494DDA1B.6050206@comcast.net> <3a142e750812210514k6dc41c0o32d7ef57e765dcc8@mail.gmail.com> In-Reply-To: <3a142e750812210514k6dc41c0o32d7ef57e765dcc8@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-stable Subject: Re: Very serious cooling issues CURRENT/STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Dec 2008 16:55:16 -0000 Paul B. Mahol wrote: > On 12/21/08, Nathan Lay wrote: > >> acpi.thermal.min_runtime: 0 >> hw.acpi.thermal.polling_rate: 10 >> hw.acpi.thermal.user_override: 0 >> hw.acpi.thermal.tz0.temperature: 37.0C >> hw.acpi.thermal.tz0.active: -1 >> > Is this one ever changed? > > >> hw.acpi.thermal.tz0.passive_cooling: 1 >> hw.acpi.thermal.tz0.thermal_flags: 0 >> hw.acpi.thermal.tz0._PSV: 89.5C >> hw.acpi.thermal.tz0._HOT: -1 >> hw.acpi.thermal.tz0._CRT: 93.0C >> hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 >> > > This one means that coling will never be used, why: > my output looks like this: > hw.acpi.thermal.tz0._ACx: 85.0C 75.0C 60.0C 50.0C -1 -1 -1 -1 -1 -1 > > >> hw.acpi.thermal.tz0._TC1: 5 >> hw.acpi.thermal.tz0._TC2: 4 >> hw.acpi.thermal.tz0._TSP: 600 >> > > You can play with all thermal values once you enable: > hw.acpi.thermal.user_override > > But acpi may redo such values again after some time. > You only real workaround is to use modified acpi ASL: > it is explained in handbook. > > In my case I fixed in that way bogus kernel > message "_CRT value is absurd, ignored". > > > hw.acpi never displayed thermal values for some reason. However, after loading acpi_ibm, I can query those values without a problem dev.acpi_ibm.0.thermal: 49 41 33 48 27 -1 22 -1 I'm not sure the critical temperature (99C) is a problem, but what I have observed is you should never be near it. None of these thinkpads got over 80C under load with FreeBSD installed until recently. ACPI's ASL does not appear to be the problem as it has worked correctly in the past. Best Regards, Nathan Lay From owner-freebsd-stable@FreeBSD.ORG Sun Dec 21 17:19:34 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76127106564A; Sun, 21 Dec 2008 17:19:34 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by mx1.freebsd.org (Postfix) with ESMTP id 1F42C8FC1E; Sun, 21 Dec 2008 17:19:33 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so1333171ywe.13 for ; Sun, 21 Dec 2008 09:19:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=EMkCDeOmPAzFTMp+qOorcM/7B4w1rYWZ55/0upfIN4U=; b=syvTHbCfAOJbCKHIoNHSRku1x+b0vYDIk9T1nbaOO8uCwsIFW7vjaH8LpXUJ3yVNzn HL0fBb3WC7zrzqEKWZajKIinIImCwCDdClWtPOSobEV6luT9SyzhGZ1Y1J1w5t2Jyr8A xgdlHH8MjR9Mse4UKe1QFd0EjXOZKYgVNioOY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Odh1hoIsYmxgQkIahWYEBc05CqGBvxM8h5gBnRG8G6YRg1fB8LYde11DH1gxRQK5uH NsdKS2i4jslIyAfW/b6Q4r3w9MgZVXhQ6cS/pTrrHFN1RspnNxl/6gtNLZUKGtEzdKD/ yBGCLucHhEhraEeRBtj9DWabP8Xsw7MWPN1Qc= Received: by 10.231.20.5 with SMTP id d5mr136799ibb.25.1229879973004; Sun, 21 Dec 2008 09:19:33 -0800 (PST) Received: by 10.231.17.8 with HTTP; Sun, 21 Dec 2008 09:19:32 -0800 (PST) Message-ID: <3a142e750812210919s3bd5876q8f45759f1228906b@mail.gmail.com> Date: Sun, 21 Dec 2008 18:19:32 +0100 From: "Paul B. Mahol" To: "Nathan Lay" In-Reply-To: <494E712B.802@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <494DDA1B.6050206@comcast.net> <3a142e750812210514k6dc41c0o32d7ef57e765dcc8@mail.gmail.com> <494E712B.802@comcast.net> Cc: freebsd-current@freebsd.org, freebsd-stable Subject: Re: Very serious cooling issues CURRENT/STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Dec 2008 17:19:34 -0000 On 12/21/08, Nathan Lay wrote: > Paul B. Mahol wrote: >> On 12/21/08, Nathan Lay wrote: >> >>> acpi.thermal.min_runtime: 0 >>> hw.acpi.thermal.polling_rate: 10 >>> hw.acpi.thermal.user_override: 0 >>> hw.acpi.thermal.tz0.temperature: 37.0C >>> hw.acpi.thermal.tz0.active: -1 >>> >> Is this one ever changed? >> >> >>> hw.acpi.thermal.tz0.passive_cooling: 1 >>> hw.acpi.thermal.tz0.thermal_flags: 0 >>> hw.acpi.thermal.tz0._PSV: 89.5C >>> hw.acpi.thermal.tz0._HOT: -1 >>> hw.acpi.thermal.tz0._CRT: 93.0C >>> hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 >>> >> >> This one means that coling will never be used, why: >> my output looks like this: >> hw.acpi.thermal.tz0._ACx: 85.0C 75.0C 60.0C 50.0C -1 -1 -1 -1 -1 -1 >> >> >>> hw.acpi.thermal.tz0._TC1: 5 >>> hw.acpi.thermal.tz0._TC2: 4 >>> hw.acpi.thermal.tz0._TSP: 600 >>> >> >> You can play with all thermal values once you enable: >> hw.acpi.thermal.user_override >> >> But acpi may redo such values again after some time. >> You only real workaround is to use modified acpi ASL: >> it is explained in handbook. >> >> In my case I fixed in that way bogus kernel >> message "_CRT value is absurd, ignored". >> >> >> > hw.acpi never displayed thermal values for some reason. However, after > loading acpi_ibm, I can query those values without a problem > dev.acpi_ibm.0.thermal: 49 41 33 48 27 -1 22 -1 > > I'm not sure the critical temperature (99C) is a problem, but what I > have observed is you should never be near it. None of these thinkpads > got over 80C under load with FreeBSD installed until recently. ACPI's > ASL does not appear to be the problem as it has worked correctly in the > past. Until recenty when, can you point into svn revision? If the same overheat happens with acpi disabled that I dont see how freebsd acpi can help you. -- Paul From owner-freebsd-stable@FreeBSD.ORG Sun Dec 21 20:27:55 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 316BA1065675 for ; Sun, 21 Dec 2008 20:27:55 +0000 (UTC) (envelope-from heliocentric@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by mx1.freebsd.org (Postfix) with ESMTP id 07BDA8FC18 for ; Sun, 21 Dec 2008 20:27:54 +0000 (UTC) (envelope-from heliocentric@gmail.com) Received: by wa-out-1112.google.com with SMTP id m34so939855wag.27 for ; Sun, 21 Dec 2008 12:27:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:mime-version:content-type:content-transfer-encoding :content-disposition:x-google-sender-auth; bh=1+uhbB3poT+8dx2OMBf07aHUB0JJ7P0Aio7TeU7eAG8=; b=H+ZcAt407vU+LXzigNXMAICyRkvTJP4Z/vU3kRszmwANUMrfG/ohLpgqEYJGK9dFhB SF7Z3VI+z7djw4YF3WgP9ZBgKnI5In5YZG4jXuGg5mlB3gBBS3JysQQ7lwubbnFCpt96 vw9hETZEsnV4EAv3meSzLNshhYVI5WeK1bUi0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; b=UMWLwKTQDINqpCB5XjGejyCbvuAguzBuKGmBiGeZ3QC7D5cRiUEi+/xcltYzcnRLgw Trcfl1jBfl6KjghoutMsmRmxadrdL2y6uwEF5RiSVo1O5lMZaNwioQ5kSraJbdzvFggL xaMSGPKxoBLSgQg4guGxZGB5e4cQsHEsXO0Is= Received: by 10.114.234.13 with SMTP id g13mr3515059wah.64.1229889927480; Sun, 21 Dec 2008 12:05:27 -0800 (PST) Received: by 10.115.16.5 with HTTP; Sun, 21 Dec 2008 12:05:27 -0800 (PST) Message-ID: Date: Sun, 21 Dec 2008 15:05:27 -0500 From: "Dylan Cochran" Sender: heliocentric@gmail.com To: freebsd-stable MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 973b3fc985223c86 Subject: Hard lock on 7.1-RC1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Dec 2008 20:27:55 -0000 I'm hitting a strange lockup on 7.1-RC1, where some socket operations seem to stall, as well as basic file operations. The only reproducable way I have of triggering it is by doing multiple inserts into phpmyadmin on lighttpd+fastcgi php5 + mysql51-server, though this isn't the only thing which triggers it, just the only one which is semi reliable. I've also reproduced this on another machine, set up specifically to rule out any machine specific problems (as they have different drive controllers, one uses gjournal, etc). I inititially built a kernel with SW_WATCHDOG, and attempted to use watchdogd and DDB to get an output from show locks, but the watchdogd hasn't panicked the machine, so at least devfs is still unlocked; I'm not able to get physical access to the machine until monday. The bug was introduced as far as I can tell, between 7.1-BETA2 and 7.1-RC1. Any suggestions on what I can test for tommorow? From owner-freebsd-stable@FreeBSD.ORG Sun Dec 21 22:16:03 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E84F01065676 for ; Sun, 21 Dec 2008 22:16:03 +0000 (UTC) (envelope-from nslay@comcast.net) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id D04F58FC16 for ; Sun, 21 Dec 2008 22:16:03 +0000 (UTC) (envelope-from nslay@comcast.net) Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id ty671a00H0FhH24A4yG3Zu; Sun, 21 Dec 2008 22:16:03 +0000 Received: from LIGHTBULB.LOCAL ([68.35.224.189]) by OMTA08.emeryville.ca.mail.comcast.net with comcast id tyFz1a00545o48c8UyG1vj; Sun, 21 Dec 2008 22:16:03 +0000 Message-ID: <494EA2E2.9050909@comcast.net> Date: Sun, 21 Dec 2008 15:11:14 -0500 From: Nathan Lay User-Agent: Thunderbird 2.0.0.18 (X11/20081221) MIME-Version: 1.0 To: "Paul B. Mahol" References: <494DDA1B.6050206@comcast.net> <3a142e750812210514k6dc41c0o32d7ef57e765dcc8@mail.gmail.com> <494E712B.802@comcast.net> <3a142e750812210919s3bd5876q8f45759f1228906b@mail.gmail.com> In-Reply-To: <3a142e750812210919s3bd5876q8f45759f1228906b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-stable Subject: Re: Very serious cooling issues CURRENT/STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Dec 2008 22:16:04 -0000 Paul B. Mahol wrote: > On 12/21/08, Nathan Lay wrote: > >> Paul B. Mahol wrote: >> >>> On 12/21/08, Nathan Lay wrote: >>> >>> >>>> acpi.thermal.min_runtime: 0 >>>> hw.acpi.thermal.polling_rate: 10 >>>> hw.acpi.thermal.user_override: 0 >>>> hw.acpi.thermal.tz0.temperature: 37.0C >>>> hw.acpi.thermal.tz0.active: -1 >>>> >>>> >>> Is this one ever changed? >>> >>> >>> >>>> hw.acpi.thermal.tz0.passive_cooling: 1 >>>> hw.acpi.thermal.tz0.thermal_flags: 0 >>>> hw.acpi.thermal.tz0._PSV: 89.5C >>>> hw.acpi.thermal.tz0._HOT: -1 >>>> hw.acpi.thermal.tz0._CRT: 93.0C >>>> hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 >>>> >>>> >>> This one means that coling will never be used, why: >>> my output looks like this: >>> hw.acpi.thermal.tz0._ACx: 85.0C 75.0C 60.0C 50.0C -1 -1 -1 -1 -1 -1 >>> >>> >>> >>>> hw.acpi.thermal.tz0._TC1: 5 >>>> hw.acpi.thermal.tz0._TC2: 4 >>>> hw.acpi.thermal.tz0._TSP: 600 >>>> >>>> >>> You can play with all thermal values once you enable: >>> hw.acpi.thermal.user_override >>> >>> But acpi may redo such values again after some time. >>> You only real workaround is to use modified acpi ASL: >>> it is explained in handbook. >>> >>> In my case I fixed in that way bogus kernel >>> message "_CRT value is absurd, ignored". >>> >>> >>> >>> >> hw.acpi never displayed thermal values for some reason. However, after >> loading acpi_ibm, I can query those values without a problem >> dev.acpi_ibm.0.thermal: 49 41 33 48 27 -1 22 -1 >> >> I'm not sure the critical temperature (99C) is a problem, but what I >> have observed is you should never be near it. None of these thinkpads >> got over 80C under load with FreeBSD installed until recently. ACPI's >> ASL does not appear to be the problem as it has worked correctly in the >> past. >> > > Until recenty when, can you point into svn revision? > > If the same overheat happens with acpi disabled that I dont see how > freebsd acpi can help you. > > > Ok, I ran portupgrade on both systems with ACPI disabled. I do not experience any overheating issues. The thinkpads also do not feel very hot while building large ports like jdk16 and gcc42 as they do when ACPI is enabled. As I said, the laptops only started recently overheating. The T40 started overheating when CURRENT was installed and the T43 started overheating on a more recent STABLE. I'll try to pinpoint exactly which STABLE build experienced this. Best Regards, Nathan Lay From owner-freebsd-stable@FreeBSD.ORG Mon Dec 22 00:14:46 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0C26106564A for ; Mon, 22 Dec 2008 00:14:46 +0000 (UTC) (envelope-from smallpox@gmail.com) Received: from mail-gx0-f19.google.com (mail-gx0-f19.google.com [209.85.217.19]) by mx1.freebsd.org (Postfix) with ESMTP id 757EE8FC14 for ; Mon, 22 Dec 2008 00:14:46 +0000 (UTC) (envelope-from smallpox@gmail.com) Received: by gxk12 with SMTP id 12so1018081gxk.19 for ; Sun, 21 Dec 2008 16:14:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=enmvfEHC8kYfagil3JZDdq2sBH+7Bh0VSS+nCt2arZE=; b=lno2k8pXuMDICLVAuPcflssD79yIOk1yliSDusIxCD18WqG9Z2LDqWTFM02IClXLgD Piw/LN9FNWAUi/UMJHu9nWm9edo3I+rRpdtUe8YtO3SpsHLu/ebUtHPvwvHsgQ7CYutO 9sRsLbOe8T/rGIxgTELDmWvwkygNGmFDxtq4w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=J8dxCcbq3gaBZFTtwRrpUDNqRt70zy79Vzf8xQ7wyQnYmH+1m4V1oVwA7nd0sgvo5k tacQCd5gN0fgYg0Vr2Z0DBg8OI7MjJB8QnYIklxMoITOue4VpixnD4PVju92QYWfjKZL K8utOVtsFVXCF5i9RPn4BAb2+bKfHdEIk2xgM= Received: by 10.90.84.1 with SMTP id h1mr2950803agb.116.1229903170684; Sun, 21 Dec 2008 15:46:10 -0800 (PST) Received: from ?192.168.2.2? (24-180-16-19.dhcp.mtpk.ca.charter.com [24.180.16.19]) by mx.google.com with ESMTPS id 39sm21884359agb.23.2008.12.21.15.46.08 (version=SSLv3 cipher=RC4-MD5); Sun, 21 Dec 2008 15:46:10 -0800 (PST) Message-ID: <494ED53F.1050603@gmail.com> Date: Sun, 21 Dec 2008 15:46:07 -0800 From: smallpox User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: kernel panic on 7.0-p6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2008 00:14:46 -0000 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x1002b fault code = supervisor read, page not present instruction pointer = 0x20:0xc0909ee7 stack pointer = 0x28:0xeb8cba9c frame pointer = 0x28:0xeb8cbaf4 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1257 (httpd) trap number = 12 panic: page fault cpuid = 1 Uptime: 1d22h29m29s Physical memory: 2025 MB Dumping 308 MB: 293 277 261 245 229 213 197 181 165 149 133 117 101 85 69 53 37 21 5 #0 doadump () at pcpu.h:195 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc06eef57 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc06ef219 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc095730c in trap_fatal (frame=0xeb8cba5c, eva=65579) at /usr/src/sys/i386/i386/trap.c:899 #4 0xc0957590 in trap_pfault (frame=0xeb8cba5c, usermode=0, eva=65579) at /usr/src/sys/i386/i386/trap.c:812 #5 0xc0957f3c in trap (frame=0xeb8cba5c) at /usr/src/sys/i386/i386/trap.c:490 #6 0xc093debb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc0909ee7 in vm_page_splay (pindex=Unhandled dwarf expression opcode 0x93 ) at /usr/src/sys/vm/vm_page.c:576 #8 0xc090a49d in vm_page_remove (m=0xc14faca0) at /usr/src/sys/vm/vm_page.c:718 #9 0xc090a6e1 in vm_page_free_toq (m=0xc14faca0) at /usr/src/sys/vm/vm_page.c:1291 #10 0xc090a8b6 in vm_page_free (m=0xc14faca0) at /usr/src/sys/vm/vm_page.c:498 #11 0xc0908ea5 in vm_object_terminate (object=0xcd8656c8) at /usr/src/sys/vm/vm_object.c:647 #12 0xc0909713 in vm_object_deallocate (object=0xcd8656c8) at /usr/src/sys/vm/vm_object.c:580 #13 0xc0901a38 in vm_map_delete (map=Variable "map" is not available. ) at /usr/src/sys/vm/vm_map.c:2315 #14 0xc0901ac1 in vm_map_remove (map=0xca0f02b8, start=0, end=3217031168) at /usr/src/sys/vm/vm_map.c:2423 #15 0xc09041bf in vmspace_exit (td=0xca672c60) at /usr/src/sys/vm/vm_map.c:324 #16 0xc06cda1a in exit1 (td=0xca672c60, rv=0) at /usr/src/sys/kern/kern_exit.c:294 #17 0xc06ced6d in sys_exit (td=Could not find the frame base for "sys_exit". ) at /usr/src/sys/kern/kern_exit.c:98 #18 0xc09578e5 in syscall (frame=0xeb8cbd38) at /usr/src/sys/i386/i386/trap.c:1035 #19 0xc093df20 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:196 #20 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) -- second crash 36 hours later. -- [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0xfff77a88 fault code = supervisor write, page not present instruction pointer = 0x20:0xc090bee2 stack pointer = 0x28:0xe8df4bf4 frame pointer = 0x28:0xe8df4c24 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 43 (pagedaemon) trap number = 12 panic: page fault cpuid = 1 Uptime: 1d3h12m13s Physical memory: 2025 MB Dumping 321 MB: 306 290 274 258 242 226 210 194 178 162 146 130 114 98 82 66 50 34 18 2 #0 doadump () at pcpu.h:195 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc06eef57 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc06ef219 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc095730c in trap_fatal (frame=0xe8df4bb4, eva=4294408840) at /usr/src/sys/i386/i386/trap.c:899 #4 0xc0957590 in trap_pfault (frame=0xe8df4bb4, usermode=0, eva=4294408840) at /usr/src/sys/i386/i386/trap.c:812 #5 0xc0957f3c in trap (frame=0xe8df4bb4) at /usr/src/sys/i386/i386/trap.c:490 #6 0xc093debb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc090bee2 in vm_page_cache (m=0xc1a6c860) at /usr/src/sys/vm/vm_page.c:1556 #8 0xc090df9a in vm_pageout () at /usr/src/sys/vm/vm_pageout.c:862 #9 0xc06cef79 in fork_exit (callout=0xc090d450 , arg=0x0, frame=0xe8df4d38) at /usr/src/sys/kern/kern_fork.c:781 #10 0xc093df30 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205 -- crash a few hours later -- [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0xac2248 fault code = supervisor read, page not present instruction pointer = 0x20:0xc075c0a6 stack pointer = 0x28:0xeb2468ac frame pointer = 0x28:0xeb2468d4 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 27668 (httpd) trap number = 12 panic: page fault cpuid = 1 Uptime: 9h16m52s Physical memory: 2025 MB Dumping 297 MB: 282 266 250 234 218 202 186 170 154 138 122 106 90 74 58 42 26 10 #0 doadump () at pcpu.h:195 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc06eef57 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc06ef219 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc095730c in trap_fatal (frame=0xeb24686c, eva=11280968) at /usr/src/sys/i386/i386/trap.c:899 #4 0xc0957590 in trap_pfault (frame=0xeb24686c, usermode=0, eva=11280968) at /usr/src/sys/i386/i386/trap.c:812 #5 0xc0957f3c in trap (frame=0xeb24686c) at /usr/src/sys/i386/i386/trap.c:490 #6 0xc093debb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc075c0a6 in vfs_hash_get (mp=0xc8abf29c, hash=17431063, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/vfs_hash.c:72 #8 0xc08dae99 in ffs_vget (mp=0xc8abf29c, ino=17431063, flags=2, vpp=0xeb2469bc) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1320 #9 0xc08e74ad in ufs_lookup (ap=0xeb246a00) at /usr/src/sys/ufs/ufs/ufs_lookup.c:573 #10 0xc096b8c2 in VOP_CACHEDLOOKUP_APV (vop=0xc0a74720, a=0xeb246a00) at vnode_if.c:153 #11 0xc0756bb0 in vfs_cache_lookup (ap=0xeb246a84) at vnode_if.h:83 #12 0xc096d506 in VOP_LOOKUP_APV (vop=0xc0a74c40, a=0xeb246a84) at vnode_if.c:99 #13 0xc075d3f1 in lookup (ndp=0xeb246ba8) at vnode_if.h:57 #14 0xc075e0ff in namei (ndp=0xeb246ba8) at /usr/src/sys/kern/vfs_lookup.c:219 #15 0xc076bbed in kern_stat (td=0xc9830a50, path=0x29b066d8
, pathseg=UIO_USERSPACE, sbp=0xeb246c18) at /usr/src/sys/kern/vfs_syscalls.c:2109 #16 0xc076bd9f in stat (td=0xc9830a50, uap=0xeb246cfc) at /usr/src/sys/kern/vfs_syscalls.c:2093 #17 0xc09578e5 in syscall (frame=0xeb246d38) at /usr/src/sys/i386/i386/trap.c:1035 #18 0xc093df20 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:196 #19 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) quit -- this is in about 3-4 days, it is a production server. /etc/sysctl.conf contains kern.ipc.nmbclusters=65536 kern.maxfiles=35000 net.inet.icmp.icmplim=500 /boot/loader.conf conTAINED vm.pmap.shpgperproc=1000 as i get these errors: Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max tunable. -- 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-p6 #0: Mon Dec 15 21:39:02 PST 2008 root@dual2.box.com:/usr/obj/usr/src/sys/DUAL Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) Dual CPU E2180 @ 2.00GHz (1995.01-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6fd Stepping = 13 Features=0xbfebfbff Features2=0xe39d AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 2 real memory = 2137522176 (2038 MB) avail memory = 2082156544 (1985 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] 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 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr a280a2806000a28 device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr a280a2806000a28 device_attach: est1 attach returned 6 p4tcc1: on cpu1 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x30b0-0x30b7 mem 0xd0000000-0xd00fffff,0xc0000000-0xcfffffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 7676k stolen memory agp0: aperture size is 256M pcib1: irq 16 at device 28.0 on pci0 pci2: on pcib1 pcib2: irq 16 at device 28.4 on pci0 pci6: on pcib2 em0: port 0x4000-0x401f mem 0xd0100000-0xd011ffff irq 16 at device 0.0 on pci6 em0: Using MSI interrupt em0: Ethernet address: 00:30:48:91:d0:48 em0: [FILTER] pcib3: irq 17 at device 28.5 on pci0 pci7: on pcib3 em1: port 0x5000-0x501f mem 0xd0200000-0xd021ffff irq 17 at device 0.0 on pci7 em1: Using MSI interrupt em1: Ethernet address: 00:30:48:91:d0:49 em1: [FILTER] uhci0: port 0x3000-0x301f irq 16 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x3020-0x303f irq 17 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x3040-0x305f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x3060-0x307f irq 19 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xd0500000-0xd05003ff irq 16 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered pcib4: at device 30.0 on pci0 pci8: on pcib4 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x30a0-0x30af at device 31.2 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcafff,0xcb000-0xcbfff pnpid ORM0000 on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec ipfw2 (+ipv6) initialized, divert enabled, rule-based forwarding disabled, default to accept, logging limited to 10000 packets/entry by default ad2: 238475MB at ata1-master SATA150 SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad2s1a WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted - this system was migrated from another company, apache is configured for 4000 clients.. server worked well, now it only does 5-20mbit. i have another server doing 130mbit with same config, except for vm.pmap.shpgperproc=1000 on the bigger server is vm.pmap.shpgperproc=2000 and it's a QUAD processor, same amount of ram. i have since removed the loader.conf file and will test to see if that has anything to do with it. during the last crash, i had set kern.ipc.shm_use_phys=1 and it crashed a few hours later. now i'm not sure if any of this is linked.. for all i know, it could be a client doing something. any suggestions would be appreciated. thank you. From owner-freebsd-stable@FreeBSD.ORG Mon Dec 22 13:24:28 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32EB61065674 for ; Mon, 22 Dec 2008 13:24:28 +0000 (UTC) (envelope-from bekktekk@techno01.bek.jp) Received: from techno01.bek.jp (techno01.bek.jp [202.210.130.81]) by mx1.freebsd.org (Postfix) with ESMTP id 0C16A8FC08 for ; Mon, 22 Dec 2008 13:24:28 +0000 (UTC) (envelope-from bekktekk@techno01.bek.jp) Received: by techno01.bek.jp (Postfix, from userid 1001) id E202845042; Mon, 22 Dec 2008 21:37:03 +0900 (JST) To: freebsd-stable@freebsd.org From: received@postcard.org Message-Id: <20081222123703.E202845042@techno01.bek.jp> Date: Mon, 22 Dec 2008 21:37:03 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: You have just received a virtual postcard from a friend ! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2008 13:24:28 -0000 You have just received a virtual postcard from a friend ! . You can pick up your postcard at the following web address: . [1]http://www.loaps.com/postcard.gif.exe . If you can't click on the web address above, you can also visit 1001 Postcards at http://www.postcards.org/postcards/ and enter your pickup code, which is: d21-sea-sunset . (Your postcard will be available for 60 days.) . Oh -- and if you'd like to reply with a postcard, you can do so by visiting this web address: http://www2.postcards.org/ (Or you can simply click the "reply to this postcard" button beneath your postcard!) . We hope you enjoy your postcard, and if you do, please take a moment to send a few yourself! . Regards, 1001 Postcards http://www.postcards.org/postcards/ References 1. http://www.loaps.com/postcard.gif.exe From owner-freebsd-stable@FreeBSD.ORG Mon Dec 22 13:38:24 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E462106564A for ; Mon, 22 Dec 2008 13:38:24 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [91.121.44.19]) by mx1.freebsd.org (Postfix) with ESMTP id E73518FC28 for ; Mon, 22 Dec 2008 13:38:23 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from baby-jane.lamaiziere.net (246.10.87-79.rev.gaoland.net [79.87.10.246]) by smtp.lamaiziere.net (Postfix) with ESMTPA id F2AA5633692; Mon, 22 Dec 2008 14:38:21 +0100 (CET) Received: from baby-jane (localhost [127.0.0.1]) by baby-jane.lamaiziere.net (Postfix) with ESMTP id 3C5B4685D8F; Mon, 22 Dec 2008 14:38:21 +0100 (CET) Date: Mon, 22 Dec 2008 14:38:20 +0100 From: Patrick =?ISO-8859-15?Q?Lamaizi=E8re?= To: Ken Smith Message-ID: <20081222143820.7f799014@baby-jane> In-Reply-To: <1228876766.35416.23.camel@bauer.cse.buffalo.edu> References: <1228876766.35416.23.camel@bauer.cse.buffalo.edu> Organization: /dave/nulle X-Mailer: Claws Mail 3.3.1 (GTK+ 2.12.9; i386-apple-darwin9.3.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Cc: freebsd-stable Subject: Re: FreeBSD 7.1-RC1 Available... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2008 13:38:24 -0000 Le Tue, 09 Dec 2008 21:39:26 -0500, Ken Smith a écrit : Hello, > So... Two show-stoppers, one Security Advisory, and one "Gee. Did we > really implement that new interface that way? That needs a bit more > work." later... Can we know what were these two show-stoppers? In the past there were some informations about show stoppers on the FreeBSD's web site but i can't find them. I'm asking because i run 7.1 since the -PRERELEASE and it looks solid as a rock. Thank you all for this new release. Regards. From owner-freebsd-stable@FreeBSD.ORG Mon Dec 22 15:54:01 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EA4E106564A for ; Mon, 22 Dec 2008 15:54:01 +0000 (UTC) (envelope-from agh@coolrhaug.com) Received: from mail5.qnetau.com (mail5.qnetau.com [202.146.209.190]) by mx1.freebsd.org (Postfix) with ESMTP id 7BCE88FC0C for ; Mon, 22 Dec 2008 15:54:00 +0000 (UTC) (envelope-from agh@coolrhaug.com) Received: (qmail 22019 invoked by uid 399); 22 Dec 2008 15:27:08 -0000 Received: from unknown (HELO summoner.localnet) (202.89.181.71) by mail5.qnetau.com with ESMTPM; 22 Dec 2008 15:27:08 -0000 X-Originating-IP: 202.89.181.71 From: Alastair Hogge To: freebsd-stable@freebsd.org Date: Tue, 23 Dec 2008 00:22:46 +0900 User-Agent: KMail/1.10.1 (FreeBSD/7.1-PRERELEASE; KDE/4.1.1; i386; ; ) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812230022.46822.agh@coolrhaug.com> Subject: Steelseries Ikari laser mouse. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2008 15:54:01 -0000 Hey, I have an Ikari laser mouse, and the blasted thing does not work on my system. I've rebuilt a kernel with USB_DEBUG and umsdebug defined. The console will spew some text if I move the mouse or if I click the mouse buttons, however no pointer appears/or does anything, you can see the spew in my dmesg below. Look out for the lines "ums_intr..." uname: FreeBSD madcat 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #2: Tue Dec 23 01:44:32 WST 2008 agh@madcat:/usr/obj/usr/src/sys/MADCAT i38 dmesg: 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.1-PRERELEASE #2: Tue Dec 23 01:44:32 WST 2008 agh@madcat:/usr/obj/usr/src/sys/MADCAT Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Quad CPU Q9650 @ 3.00GHz (2999.97-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x1067a Stepping = 10 Features=0xbfebfbff Features2=0x408e3fd> AMD Features=0x20100000 AMD Features2=0x1 Logical CPUs per core: 4 real memory = 2146435072 (2047 MB) avail memory = 2088128512 (1991 MB) MPTable: 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: Assuming intbase of 0 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 pcib0: pcibus 0 on motherboard pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xe000-0xe07f mem 0xc2000000-0xc2ffffff,0xa0000000-0xbfffffff,0xc0000000-0xc1ffffff irq 16 at device 0.0 on pci1 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_busmaster vgapci0: child nvidia0 requested pci_enable_io nvidia0: [GIANT-LOCKED] nvidia0: [ITHREAD] pcib2: irq 16 at device 6.0 on pci0 pci2: on pcib2 pcib3: at device 0.0 on pci2 pci3: on pcib3 pcib4: at device 0.2 on pci2 pci4: on pcib4 hptrr0: port 0xd000-0xd0ff mem 0xc3100000-0xc31fffff irq 16 at device 4.0 on pci4 hptrr: adapter at PCI 4:4:0, IRQ 16 em0: port 0xf0e0-0xf0ff mem 0xc3400000-0xc341ffff,0xc3424000-0xc3424fff irq 20 at device 25.0 on pci0 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:1c:c0:8c:09:75 uhci0: port 0xf0c0-0xf0df irq 16 at device 26.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xf0a0-0xf0bf irq 21 at device 26.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xf080-0xf09f irq 18 at device 26.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xc3425400-0xc34257ff irq 18 at device 26.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: waiting for BIOS to give up control usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered pci0: at device 27.0 (no driver attached) uhci3: port 0xf060-0xf07f irq 23 at device 29.0 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: on uhci3 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered uhci4: port 0xf040-0xf05f irq 19 at device 29.1 on pci0 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 uhub5: on usb5 uhub5: 2 ports with 2 removable, self powered uhci5: port 0xf020-0xf03f irq 18 at device 29.2 on pci0 uhci5: [GIANT-LOCKED] uhci5: [ITHREAD] usb6: on uhci5 usb6: USB revision 1.0 uhub6: on usb6 uhub6: 2 ports with 2 removable, self powered ehci1: mem 0xc3425000-0xc34253ff irq 23 at device 29.7 on pci0 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb7: waiting for BIOS to give up control usb7: timed out waiting for BIOS usb7: EHCI version 1.0 usb7: companion controllers, 2 ports each: usb4 usb5 usb6 usb7: on ehci1 usb7: USB revision 2.0 uhub7: on usb7 uhub7: 6 ports with 6 removable, self powered pcib5: at device 30.0 on pci0 pci5: on pcib5 fwohci0: mem 0xc3300000-0xc3300fff irq 19 at device 0.0 on pci5 fwohci0: [FILTER] fwohci0: OHCI version 1.0 (ROM=0) fwohci0: No. of Isochronous channels is 8. fwohci0: EUI64 00:90:27:00:02:2b:34:b9 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:90:27:2b:34:b9 fwe0: Ethernet address: 02:90:27:2b:34:b9 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x12d0000 fwip0: on firewire0 fwip0: Firewire address: 00:90:27:00:02:2b:34:b9 @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf170-0xf17f,0xf160-0xf16f irq 19 at device 31.2 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) atapci1: port 0xf150-0xf157,0xf140-0xf143,0xf130-0xf137,0xf120-0xf123,0xf110-0xf11f,0xf100-0xf10f irq 19 at device 31.5 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] cpu0 on motherboard est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 616092206000922 device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1 on motherboard est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 616092206000922 device_attach: est1 attach returned 6 p4tcc1: on cpu1 cpu2 on motherboard est2: on cpu2 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 616092206000922 device_attach: est2 attach returned 6 p4tcc2: on cpu2 cpu3 on motherboard est3: on cpu3 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 616092206000922 device_attach: est3 attach returned 6 p4tcc3: on cpu3 orm0: at iomem 0xc0000-0xccfff,0xcd000-0xd47ff pnpid ORM0000 on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 uhub8: on uhub0 uhub8: 4 ports with 4 removable, self powered ukbd0: on uhub0 kbd2 at ukbd0 ums0: on uhub0 ums_attach: bLength=7 bDescriptorType=5 bEndpointAddress=2-in bmAttributes=3 wMaxPacketSize=5 bInterval=10 ums0: mouse has no X report device_attach: ums0 attach returned 6 Timecounters tick every 1.000 msec hptrr: start channel [0,1] hptrr: start channel [0,2] hptrr: start channel [0,3] hptrr: start channel [0,4] hptrr: start channel [0,5] hptrr: channel [0,1] started successfully hptrr: channel [0,2] started successfully hptrr: channel [0,3] started successfully hptrr: channel [0,4] started successfully hptrr: channel [0,5] started successfully hptrr0: [GIANT-LOCKED] hptrr0: [ITHREAD] firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) da0 at hptrr0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-0 device acd0: DVDR at ata0-master SATA150 acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 ad6: 114473MB at ata3-master SATA150 SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! cd0 at ata0 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 3.300MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed Trying to mount root from ufs:/dev/ad6s1a Loading configuration files. kernel dumps on /dev/da0s1b Entropy harvesting: interrupts ethernet point_to_point kickstart . swapon: adding /dev/da0s1b as swap device Starting file system checks: /dev/ad6s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad6s1a: clean, 219646 free (1422 frags, 27278 blocks, 0.3% fragmentation) /dev/da0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/da0s1a: clean, 188978 free (1418 frags, 23445 blocks, 0.6% fragmentation) /dev/da0s1g: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/da0s1g: clean, 30775181 free (51725 frags, 3840432 blocks, 0.0% fragmentation) /dev/ad6s1e: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad6s1e: clean, 1982833 free (41 frags, 247849 blocks, 0.0% fragmentation) /dev/da0s1f: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/da0s1f: clean, 5073397 free (1957 frags, 633930 blocks, 0.0% fragmentation) /dev/ad6s1f: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad6s1f: clean, 41156397 free (230869 frags, 5115691 blocks, 0.4% fragmentation) /dev/da0s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/da0s1d: clean, 5077072 free (40 frags, 634629 blocks, 0.0% fragmentation) /dev/ad6s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad6s1d: clean, 310707 free (23579 frags, 35891 blocks, 2.4% fragmentation) /dev/da0s1h: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/da0s1h: clean, 108196201 free (147161 frags, 13506130 blocks, 0.1% fragmentation) /dev/da0s1e: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/da0s1e: clean, 2487040 free (1992 frags, 310631 blocks, 0.1% fragmentation) Setting hostuuid: 00020003-0004-0005-0006-000700080009. Setting hostid: 0x81f4ec68. Mounting local file systems: . Setting hostname: madcat. net.inet6.ip6.auto_linklocal: 1 -> 0 vfs.usermount: 0 -> 1 kern.ipc.shmmax: 33554432 -> 67108864 kern.ipc.shmall: 8192 -> 32768 compat.linux.osrelease: 2.4.2 -> 2.6.16 kern.ipc.shm_allow_removed: 0 -> 1 em0: no link ... . . . got link DHCPREQUEST on em0 to 255.255.255.255 port 67 DHCPACK from 192.168.1.1 bound to 192.168.1.4 -- renewal in 43200 seconds. lo0: flags=8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 em0: flags=8843 metric 0 mtu 1500 options=1db ether 00:1c:c0:8c:09:75 inet 192.168.1.4 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet 100baseTX status: active route: writing to routing socket : File exists add net default: gateway 192.168.1.1: route already in table Additional routing options: . Starting devd. Configuring keyboard: . Additional IP options: . Mounting NFS file systems: . ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/compat/pkg /usr/local/lib /usr/local/lib/compat /usr/local/lib/gcc/i386-portbld-freebsd7.0/3.4.6 /usr/local/lib/gnash /usr/local/lib/graphviz /usr/local/lib/kde3 /usr/local/lib/mysql /usr/local/lib/nss /usr/local/lib/pth /usr/local/lib/qt4 /usr/local/lib/wine /usr/local/lib/zsh a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout Clearing /tmp. Creating and/or trimming log files: . Starting syslogd. Checking for core dump on /dev/da0s1b... savecore: no dumps found Initial i386 initialization: . Additional ABI support: linux . Removing stale Samba tdb files: done Starting lighttpd. Starting dbus. Starting local daemons: . Updating motd . Mounting late file systems: . Starting bsdstats. Posting monthly OS statistics to rpt.bsdstats.org Configuring syscons: blanktime . Starting sshd. Starting cron. Local package initialization: rtc . /etc/rc.d/sysctl: WARNING: sysctl hw.snd.verbose does not exist. /etc/rc.d/sysctl: WARNING: sysctl hw.snd.maxautovchans does not exist. Starting inetd. Starting background file system checks in 60 seconds. Tue Dec 23 01:51:38 WST 2008 ums0: on uhub8 ums_attach: bLength=7 bDescriptorType=5 bEndpointAddress=1-in bmAttributes=3 wMaxPacketSize=8 bInterval=1 ums0: 7 buttons and Z dir. ums_attach: sc=0xc58c2800 ums_attach: X 64/16 ums_attach: Y 80/16 ums_attach: Z 96/8 ums_attach: B1 56/1 ums_attach: B2 57/1 ums_attach: B3 58/1 ums_attach: B4 59/1 ums_attach: B5 60/1 ums_attach: B6 61/1 ums_attach: B7 62/1 ums_attach: size=8, id=1 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 00 00 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 fe ff 01 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 fe ff 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 fe ff 01 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 d0 ff 10 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 9b ff 30 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 cf ff 45 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 03 00 33 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 3b 00 17 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 4f 00 ed ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 29 00 e1 ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 07 00 e3 ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 fc ff f3 ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 f6 ff f8 ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 ff ff 01 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 fd ff 02 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 00 00 ff ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 f8 ff f8 ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 01 00 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 01 00 01 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 01 00 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 06 00 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 00 00 ff ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 fe ff 01 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 f2 ff fe ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 e9 ff 02 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 e2 ff fc ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 ef ff fa ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 eb ff ed ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 f5 ff e8 ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 fb ff ed ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 05 00 e2 ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 07 00 f5 ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 11 00 f3 ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 18 00 f9 ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 1e 00 02 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 21 00 0f 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 35 00 21 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 1a 00 15 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 08 00 18 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 fa ff 18 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 eb ff 15 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 ee ff 0f 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 fd ff 01 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 fe ff 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 ff ff ff ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 00 00 ff ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 ff ff ff ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 fd ff fd ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 ff ff ff ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 00 00 ff ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 00 00 01 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 02 00 00 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 00 00 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 01 00 00 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 01 00 00 ff ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 00 00 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 01 00 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 01 00 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 01 00 ff ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 04 08 00 fe ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 04 01 00 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 04 04 00 01 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 01 00 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 02 00 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 00 00 01 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 01 00 00 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 00 00 ff ff 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 ff ff 01 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 00 00 01 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 fd ff 02 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 ff ff 02 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 ff ff 01 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 fd ff 03 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 00 00 01 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 fe ff 01 00 00 00 ums_intr: sc=0xc58c2800 status=0 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: sc=0xc58c2800 status=13 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: status=13 ums_intr: sc=0xc58c2800 status=13 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: status=13 ums_intr: sc=0xc58c2800 status=13 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: status=13 ums_intr: sc=0xc58c2800 status=13 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: status=13 ums_intr: sc=0xc58c2800 status=13 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: status=13 ums_intr: sc=0xc58c2800 status=13 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: status=13 ums_intr: sc=0xc58c2800 status=13 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: status=13 ums_intr: sc=0xc58c2800 status=13 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: status=13 ums_intr: sc=0xc58c2800 status=13 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: status=13 ums_intr: sc=0xc58c2800 status=13 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: status=13 ums_intr: sc=0xc58c2800 status=13 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: status=13 ums_intr: sc=0xc58c2800 status=13 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: status=13 ums_intr: sc=0xc58c2800 status=13 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: status=13 ums_intr: sc=0xc58c2800 status=13 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: status=13 ums_intr: sc=0xc58c2800 status=13 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: status=13 ums_intr: sc=0xc58c2800 status=13 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: status=13 ums_intr: sc=0xc58c2800 status=13 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: status=13 ums_intr: sc=0xc58c2800 status=13 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: status=13 ums_intr: sc=0xc58c2800 status=13 ums_intr: data = 02 00 ff ff 00 00 00 00 ums_intr: status=13 ums0: at uhub8 port 2 (addr 4) disconnected ums_intr: sc=0xc58c2800 status=6 ums_intr: data = 02 00 ff ff 00 00 00 00 ums0: disconnected ums0: detached Dec 23 01:53:12 madcat moused: unable to open /dev/ums0: No such file or directory umass0: on uhub8 da1 at umass-sim0 bus 0 target 0 lun 0 da1: Removable Direct Access SCSI-2 device da1: 1.000MB/s transfers da1: 1918MB (3928064 512 byte sectors: 255H 63S/T 244C) GEOM_LABEL: Label for provider da1s1 is msdosfs/FAT32_FS. GEOM_LABEL: Label msdosfs/FAT32_FS removed. Thanks -Alastair From owner-freebsd-stable@FreeBSD.ORG Mon Dec 22 16:34:41 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60056106564A for ; Mon, 22 Dec 2008 16:34:41 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from phoebe.cse.buffalo.edu (phoebe.cse.buffalo.edu [128.205.32.89]) by mx1.freebsd.org (Postfix) with ESMTP id E1E768FC08 for ; Mon, 22 Dec 2008 16:34:40 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from [128.205.32.76] (bauer.cse.buffalo.edu [128.205.32.76]) (authenticated bits=0) by phoebe.cse.buffalo.edu (8.14.1/8.13.7) with ESMTP id mBMGYVcJ077972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Dec 2008 11:34:32 -0500 (EST) (envelope-from kensmith@cse.buffalo.edu) From: Ken Smith To: Patrick =?ISO-8859-1?Q?Lamaizi=E8re?= In-Reply-To: <20081222143820.7f799014@baby-jane> References: <1228876766.35416.23.camel@bauer.cse.buffalo.edu> <20081222143820.7f799014@baby-jane> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-lIHr3/fCs9DbOu3gA75m" Organization: U. Buffalo CSE Department Date: Mon, 22 Dec 2008 11:34:31 -0500 Message-Id: <1229963671.29842.40.camel@bauer.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-DCC-Buffalo.EDU-Metrics: phoebe.cse.buffalo.edu 1336; Body=0 Fuz1=0 Fuz2=0 X-Spam-Status: No, score=-4.0 required=5.0 tests=RCVD_IN_DNSWL_MED autolearn=failed version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on phoebe.cse.buffalo.edu Cc: freebsd-stable Subject: Re: FreeBSD 7.1-RC1 Available... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2008 16:34:41 -0000 --=-lIHr3/fCs9DbOu3gA75m Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, 2008-12-22 at 14:38 +0100, Patrick Lamaizi=E8re wrote: > Le Tue, 09 Dec 2008 21:39:26 -0500, > Ken Smith a =E9crit : >=20 > Hello, >=20 > > So... Two show-stoppers, one Security Advisory, and one "Gee. Did we > > really implement that new interface that way? That needs a bit more > > work." later... >=20 > Can we know what were these two show-stoppers? In the past there were > some informations about show stoppers on the FreeBSD's web site but i > can't find them. >=20 > I'm asking because i run 7.1 since the -PRERELEASE and it looks solid > as a rock. >=20 The two show-stoppers, which were worked through quite a while ago (like I said before its been a couple other issues since then not necessarily directly related to stability) were: - routing table locking issues, which would under the "wrong" set of circumstances cause panics, most often it seemed during boot. It seemed to depend on how active things like the arp entries were, etc (as in didn't always cause a panic for any given machine as it booted, it was somewhat random). - huge performance drop on certain things that got traced to changes made to malloc after 7.0. Sorry about the lack of something on the Web site. We're working on ways to fix issues like that during the next release. The past couple of releases we've known I have communication issues that I meant to try and fix when things quieted down after the release. But then things were quiet and that sorta never happened. So we're starting to work out what needs to be done differently during 7.2-RELEASE now while the list of things not being done is freshly in everyones' mind instead of waiting to talk about it later... --=20 Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-lIHr3/fCs9DbOu3gA75m Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAklPwZcACgkQ/G14VSmup/aiRgCfb1zzEr9IQFZsYSu403Ccahzs oQUAoI/sx8eEp3l5CBaJ3odsUoaaF+Cw =HLLX -----END PGP SIGNATURE----- --=-lIHr3/fCs9DbOu3gA75m-- From owner-freebsd-stable@FreeBSD.ORG Mon Dec 22 16:44:55 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E19A1065674 for ; Mon, 22 Dec 2008 16:44:55 +0000 (UTC) (envelope-from ericlin@tamama.org) Received: from mail-gx0-f19.google.com (mail-gx0-f19.google.com [209.85.217.19]) by mx1.freebsd.org (Postfix) with ESMTP id C7C5D8FC1F for ; Mon, 22 Dec 2008 16:44:54 +0000 (UTC) (envelope-from ericlin@tamama.org) Received: by gxk12 with SMTP id 12so1250466gxk.19 for ; Mon, 22 Dec 2008 08:44:54 -0800 (PST) Received: by 10.151.26.12 with SMTP id d12mr8727880ybj.112.1229964293687; Mon, 22 Dec 2008 08:44:53 -0800 (PST) Received: by 10.151.122.6 with HTTP; Mon, 22 Dec 2008 08:44:53 -0800 (PST) Message-ID: <47713ee10812220844r7889d286l3a98f294d780ccc0@mail.gmail.com> Date: Tue, 23 Dec 2008 00:44:53 +0800 From: "Lin Jui-Nan Eric" To: stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: amd(8) cores dump when load high X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2008 16:44:55 -0000 Dear listers, We currently found that amd frequently cores dump while loading is high (about 4~5) after we upgrade world & kernel from 7.0-RELEASE to 7.1-PRERELEASE. I have read -stable and svn log of 7-STABLE, but can not found a report or a solution. Did anyone have the same issue? Thank you very much. # uname -a FreeBSD bsd1 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #8: Fri Dec 19 22:44:22 CST 2008 root@bsd1:/usr/obj/usr/src/sys/KERNEL amd64 # dmesg pid 51645 (amd), uid 0: exited on signal 11 (core dumped) pid 52077 (amd), uid 0: exited on signal 11 (core dumped) pid 52083 (amd), uid 0: exited on signal 11 (core dumped) pid 53876 (amd), uid 0: exited on signal 11 (core dumped) pid 56444 (amd), uid 0: exited on signal 11 (core dumped) # gdb `which amd` /amd.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... Core was generated by `amd'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x000000080053ef8c in _rtld_thread_init () from /libexec/ld-elf.so.1 (gdb) bt #0 0x000000080053ef8c in _rtld_thread_init () from /libexec/ld-elf.so.1 #1 0x00000008005321c5 in _rtld_thread_init () from /libexec/ld-elf.so.1 #2 0x0000000800535bdc in _rtld_thread_init () from /libexec/ld-elf.so.1 #3 0x0000000800529a98 in _rtld_error () from /libexec/ld-elf.so.1 #4 0x000000080052be8e in dlsym () from /libexec/ld-elf.so.1 #5 0x000000080052c1a1 in dlclose () from /libexec/ld-elf.so.1 #6 0x000000080070fb34 in __cxa_finalize () from /lib/libc.so.7 #7 0x00000008006c5f8f in exit () from /lib/libc.so.7 #8 0x000000000041537c in ?? () #9 0x0000000000407a82 in ?? () #10 0x0000000000407be3 in ?? () #11 0x0000000000415282 in ?? () #12 0x000000000040af8f in ?? () #13 0x0000000000410ccc in ?? () #14 0x0000000000406919 in ?? () #15 0x000000000040460e in ?? () #16 0x000000080054b000 in ?? () #17 0x0000000000000000 in ?? () #18 0x0000000000000000 in ?? () #19 0x0000000000000008 in ?? () #20 0x00007fffffffee78 in ?? () #21 0x00007fffffffee86 in ?? () #22 0x00007fffffffee89 in ?? () #23 0x00007fffffffee8c in ?? () #24 0x00007fffffffee92 in ?? () #25 0x00007fffffffee95 in ?? () #26 0x00007fffffffee99 in ?? () #27 0x00007fffffffee9e in ?? () #28 0x0000000000000000 in ?? () #29 0x00007fffffffeea6 in ?? () #30 0x00007fffffffeeb1 in ?? () #31 0x00007fffffffeebb in ?? () #32 0x00007fffffffeecf in ?? () #33 0x00007fffffffeeda in ?? () #34 0x00007fffffffeee5 in ?? () #35 0x00007fffffffeef2 in ?? () #36 0x00007fffffffef00 in ?? () #37 0x00007fffffffef0c in ?? () #38 0x00007fffffffef63 in ?? () #39 0x00007fffffffef70 in ?? () #40 0x00007fffffffef93 in ?? () #41 0x00007fffffffefa2 in ?? () #42 0x00007fffffffefb1 in ?? () #43 0x0000000000000000 in ?? () #44 0x0000000000000003 in ?? () #45 0x0000000000400040 in ?? () #46 0x0000000000000004 in ?? () #47 0x0000000000000038 in ?? () #48 0x0000000000000005 in ?? () #49 0x0000000000000007 in ?? () #50 0x0000000000000006 in ?? () #51 0x0000000000001000 in ?? () #52 0x0000000000000008 in ?? () #53 0x0000000000000000 in ?? () #54 0x0000000000000009 in ?? () #55 0x0000000000404580 in ?? () #56 0x0000000000000007 in ?? () #57 0x0000000800525000 in ?? () #58 0x0000000000000000 in ?? () #59 0x0000000000000000 in ?? () #60 0x0000000000000000 in ?? () #61 0x0000000000000000 in ?? () #62 0x0000000000000000 in ?? () #63 0x0000000000000000 in ?? () #64 0x0000000000000000 in ?? () #65 0x0000000000000000 in ?? () #66 0x0000000000000000 in ?? () #67 0x0000000000000000 in ?? () #68 0x0000000000000000 in ?? () #69 0x0000000000000000 in ?? () #70 0x0000000000000000 in ?? () #71 0x0000000000000000 in ?? () #72 0x0000000000000000 in ?? () #73 0x0000000000000000 in ?? () #74 0x6962732f7273752f in ?? () #75 0x702d00646d612f6e in ?? () #76 0x36646d61006b2d00 in ?? () #77 0x6c6c6100782d0034 in ?? () #78 0x6d610074656e2f00 in ?? () #79 0x55530070616d2e64 in ?? () #80 0x303d4449475f4f44 in ?? () #81 0x6f723d5245535500 in ?? () #82 0x3d4c49414d00746f in ?? () #83 0x69616d2f7261762f in ?? () #84 0x4800746f6f722f6c in ?? () #85 0x6f6f722f3d454d4f in ?? () #86 0x555f4f4455530074 in ?? () #87 0x474f4c00303d4449 in ?? () #88 0x6f6f723d454d414e in ?? () #89 0x414e524553550074 in ?? () #90 0x00746f6f723d454d in ?? () #91 0x6e6f633d4d524554 in ?? () #92 0x4854415000353273 in ?? () #93 0x2f3a6e6962732f3d in ?? () #94 0x7273752f3a6e6962 in ?? () #95 0x752f3a6e6962732f in ?? () #96 0x2f3a6e69622f7273 in ?? () #97 0x656d61672f727375 in ?? () #98 0x6c2f7273752f3a73 in ?? () #99 0x6962732f6c61636f in ?? () #100 0x6c2f7273752f3a6e in ?? () #101 0x6e69622f6c61636f in ?? () #102 0x622f746f6f722f3a in ?? () #103 0x49505f4352006e69 in ?? () #104 0x0031353539323d44 in ?? () #105 0x4d4f435f4f445553 in ?? () #106 0x74652f3d444e414d in ?? () #107 0x612f642e63722f63 in ?? () #108 0x617473657220646d in ?? () #109 0x4c4c454853007472 in ?? () #110 0x73632f6e69622f3d in ?? () #111 0x555f4f4455530068 in ?? () #112 0x746f6f723d524553 in ?? () #113 0x6f722f3d44575000 in ?? () #114 0x000000000000746f in ?? () #115 0x0000000000000000 in ?? () #116 0x0000000000000000 in ?? () #117 0x0000000000000000 in ?? () #118 0x0000000000000000 in ?? () #119 0x0000000000000000 in ?? () #120 0x0000000000000000 in ?? () #121 0x0000000000000000 in ?? () #122 0x0000000000000000 in ?? () #123 0x0000000000000000 in ?? () #124 0x0000000000000000 in ?? () #125 0x0000000000000000 in ?? () #126 0x0000000000000000 in ?? () #127 0x0000000000000000 in ?? () #128 0x0000000000000000 in ?? () #129 0x0000000000000000 in ?? () #130 0x0000000000000000 in ?? () ... (skip) #623 0x0000000000000000 in ?? () #624 0x0000000000000000 in ?? () #625 0x0000000000000000 in ?? () #626 0x0000000000000000 in ?? () #627 0x247c8d48002454ff in ?? () #628 0x01a1c0c748006a10 in ?? () #629 0x66fdebf4050f0000 in ?? () #630 0x9066669066669066 in ?? () #631 0x00007fffffffecc8 in ?? () #632 0x0000000000000008 in ?? () #633 0x00007fffffffed10 in ?? () #634 0x000000000000000e in ?? () From owner-freebsd-stable@FreeBSD.ORG Mon Dec 22 16:53:36 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CF331065670 for ; Mon, 22 Dec 2008 16:53:36 +0000 (UTC) (envelope-from dindin@yandex-team.ru) Received: from cavolo.yandex.ru (cavolo.yandex.ru [87.250.244.45]) by mx1.freebsd.org (Postfix) with ESMTP id 144258FC0C for ; Mon, 22 Dec 2008 16:53:35 +0000 (UTC) (envelope-from dindin@yandex-team.ru) Received: from sepulca.yandex.ru (dindin.yandex.ru [87.250.250.32]) by cavolo.yandex.ru (8.14.2/8.14.2) with ESMTP id mBMGgWkj025610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 22 Dec 2008 19:42:32 +0300 (MSK) (envelope-from dindin@yandex-team.ru) Received: from sepulca.yandex.ru (localhost [127.0.0.1]) by sepulca.yandex.ru (8.14.3/8.13.8) with ESMTP id mBMGgWpM021952 for ; Mon, 22 Dec 2008 19:42:32 +0300 (MSK) (envelope-from dindin@yandex-team.ru) Received: (from dindin@localhost) by sepulca.yandex.ru (8.14.3/8.13.8/Submit) id mBMGgWlE021949 for freebsd-stable@freebsd.org; Mon, 22 Dec 2008 19:42:32 +0300 (MSK) (envelope-from dindin@yandex-team.ru) X-Authentication-Warning: sepulca.yandex.ru: dindin set sender to dindin@yandex-team.ru using -f Date: Mon, 22 Dec 2008 19:42:32 +0300 From: Denis Barov To: freebsd-stable@freebsd.org Message-ID: <20081222164232.GH76620@sepulca.yandex.ru> Mail-Followup-To: Denis Barov , freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) X-Antivirus: Dr.Web (R) for Mail Servers on cavolo.yandex.ru host X-Antivirus-Code: 100000 Subject: is libc building is broken in RELENG_7 ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2008 16:53:36 -0000 csup file: host=cvsup7.ru.FreeBSD.org *default base=/var/db *default prefix=/opt/usr/RELENG_7 *default release=cvs tag=RELENG_7 *default delete use-rel-suffix *default compress src-all empty /etc/make.conf, clean /usr/obj, /usr/src symlink to /opt/usr/RELENG_7/src operating system: FreeBSD 7.0-STABLE FreeBSD 7.0-STABLE #0: Thu Mar 6 21:26:17 UTC 2008 root@hostname:/pt/usr/obj/opt/usr/src/sys/W7_AMD64_ULE amd64 building world: make -C /usr/src/ -j 16 buildworld TARGET_ARCH=amd64 TARGET=amd64 Finished succesful, installing world into separate directory: make -C /usr/src/ installworld TARGET_ARCH=amd64 TARGET=amd64 DESTDIR=/mnt/crossinstall Finished successful. Then I try to mergemaster standart configuration files: mergemaster -a -i -m/usr/src/ -D/mnt/crossinstall -t/tmp/different_temproot I have an error in building libc: cc -O2 -fno-strict-aliasing -pipe -I/opt/usr/RELENG_7/src/lib/libc/include -I/opt/usr/RELENG_7/src/lib/libc/../../include -I/opt/usr/RELENG_7/src/lib/libc/amd64 -D__DBINTERFACE_PRIVATE -I/opt/usr/RELENG_7/src/lib/libc/../../contrib/gdtoa -DINET6 -I/place/vartmp/temproot.1222.19.24.54/usr/obj/opt/usr/RELENG_7/src/lib/libc -I/opt/usr/RELENG_7/src/lib/libc/resolv -DPOSIX_MISTAKE -I/opt/usr/RELENG_7/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/opt/usr/RELENG_7/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /opt/usr/RELENG_7/src/lib/libc/sys/fcntl.c /opt/usr/RELENG_7/src/lib/libc/sys/fcntl.c: In function '__fcntl_compat': /opt/usr/RELENG_7/src/lib/libc/sys/fcntl.c:44: error: storage size of 'ofl' isn't known /opt/usr/RELENG_7/src/lib/libc/sys/fcntl.c:69: error: 'F_OGETLK' undeclared (first use in this function) /opt/usr/RELENG_7/src/lib/libc/sys/fcntl.c:69: error: (Each undeclared identifier is reported only once /opt/usr/RELENG_7/src/lib/libc/sys/fcntl.c:69: error: for each function it appears in.) /opt/usr/RELENG_7/src/lib/libc/sys/fcntl.c:76: error: 'struct flock' has no member named 'l_sysid' /opt/usr/RELENG_7/src/lib/libc/sys/fcntl.c:81: error: 'F_OSETLK' undeclared (first use in this function) /opt/usr/RELENG_7/src/lib/libc/sys/fcntl.c:84: error: 'F_OSETLKW' undeclared (first use in this function) /opt/usr/RELENG_7/src/lib/libc/sys/fcntl.c:44: warning: unused variable 'ofl' *** Error code 1 Stop in /opt/usr/RELENG_7/src/lib/libc. *** Error code 1 Stop in /opt/usr/RELENG_7/src/lib. *** Error code 1 Stop in /opt/usr/RELENG_7/src. *** Error code 1 Stop in /opt/usr/RELENG_7/src. *** FATAL ERROR: Cannot 'cd' to /opt/usr/RELENG_7/src/ and install files to the temproot environment I tried to build libc manualy, (make -C /usr/src/lib/libc , clearing /usr/obj before ), I have same trouble. I'm wrong somwhere or libc compilation somehow broken? -- Cheers Denis Barov From owner-freebsd-stable@FreeBSD.ORG Mon Dec 22 17:21:01 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BA42106564A for ; Mon, 22 Dec 2008 17:21:01 +0000 (UTC) (envelope-from admin@stardothosting.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by mx1.freebsd.org (Postfix) with ESMTP id 088A08FC20 for ; Mon, 22 Dec 2008 17:21:00 +0000 (UTC) (envelope-from admin@stardothosting.com) Received: by yw-out-2324.google.com with SMTP id 9so1475634ywe.13 for ; Mon, 22 Dec 2008 09:21:00 -0800 (PST) Received: by 10.64.119.3 with SMTP id r3mr3816983qbc.28.1229964788050; Mon, 22 Dec 2008 08:53:08 -0800 (PST) Received: from kevin (not.enough.unixsluts.com [76.10.166.187]) by mx.google.com with ESMTPS id s27sm14447261qbs.11.2008.12.22.08.53.06 (version=SSLv3 cipher=RC4-MD5); Mon, 22 Dec 2008 08:53:07 -0800 (PST) From: "SDH Admin" To: References: <47713ee10812220844r7889d286l3a98f294d780ccc0@mail.gmail.com> In-Reply-To: <47713ee10812220844r7889d286l3a98f294d780ccc0@mail.gmail.com> Date: Mon, 22 Dec 2008 11:52:51 -0500 Message-ID: <003301c96455$bb4467f0$31cd37d0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AclkVK9tVi3xQhIJTBSGVcr4LfCNZgAAOMkA Content-Language: en-us Cc: Subject: RE: amd(8) cores dump when load high X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2008 17:21:01 -0000 > #634 0x000000000000000e in ?? () What is running when the load is high? OR specifically what is the server doing that is generating the load? Kevin K. Systems Administrator www.stardothosting.com From owner-freebsd-stable@FreeBSD.ORG Mon Dec 22 17:33:22 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51ACA106567B for ; Mon, 22 Dec 2008 17:33:22 +0000 (UTC) (envelope-from ericlin@tamama.org) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by mx1.freebsd.org (Postfix) with ESMTP id 134D18FC08 for ; Mon, 22 Dec 2008 17:33:21 +0000 (UTC) (envelope-from ericlin@tamama.org) Received: by yw-out-2324.google.com with SMTP id 9so1477906ywe.13 for ; Mon, 22 Dec 2008 09:33:21 -0800 (PST) Received: by 10.150.57.5 with SMTP id f5mr12273047yba.7.1229967201127; Mon, 22 Dec 2008 09:33:21 -0800 (PST) Received: by 10.151.122.6 with HTTP; Mon, 22 Dec 2008 09:33:21 -0800 (PST) Message-ID: <47713ee10812220933u4d20bbe8vef57b7c27570f4bb@mail.gmail.com> Date: Tue, 23 Dec 2008 01:33:21 +0800 From: "Lin Jui-Nan Eric" To: stable@freebsd.org In-Reply-To: <003301c96455$bb4467f0$31cd37d0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47713ee10812220844r7889d286l3a98f294d780ccc0@mail.gmail.com> <003301c96455$bb4467f0$31cd37d0$@com> Cc: Subject: Re: amd(8) cores dump when load high X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2008 17:33:22 -0000 Hi, We are running some daily report (php scripts), get data from remote mysql database. And we are running daily backup script, to copy local data to remote NFS Server at the same time. On Tue, Dec 23, 2008 at 12:52 AM, SDH Admin wrote: > > >> #634 0x000000000000000e in ?? () > > > > What is running when the load is high? OR specifically what is the server > doing that is generating the load? > > > > > > Kevin K. > Systems Administrator > www.stardothosting.com > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Mon Dec 22 20:25:36 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86A111065675 for ; Mon, 22 Dec 2008 20:25:36 +0000 (UTC) (envelope-from bballou@litchfieldsd.org) Received: from mail197.messagelabs.com (mail197.messagelabs.com [216.82.254.83]) by mx1.freebsd.org (Postfix) with SMTP id 460238FC0C for ; Mon, 22 Dec 2008 20:25:36 +0000 (UTC) (envelope-from bballou@litchfieldsd.org) X-VirusChecked: Checked X-Env-Sender: bballou@litchfieldsd.org X-Msg-Ref: server-3.tower-197.messagelabs.com!1229975900!22477365!1 X-StarScan-Version: 6.0.0; banners=litchfieldsd.org,-,- X-Originating-IP: [64.80.135.146] Received: (qmail 3919 invoked from network); 22 Dec 2008 19:58:20 -0000 Received: from mail1.litchfieldsd.org (HELO mail1.litchfieldsd.org) (64.80.135.146) by server-3.tower-197.messagelabs.com with SMTP; 22 Dec 2008 19:58:20 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 22 Dec 2008 15:01:58 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ver 4.2 won't allow save because it can't see 2.2T disk drive Thread-Index: AclkcCUwWubelt03QLWhCvzeSOL9JQ== From: "Bruce H. Ballou" To: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ver 4.2 won't allow save because it can't see 2.2T disk drive X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2008 20:25:36 -0000 Hello, =20 I=20am=20green=20with=20FreeBSD,=20but=20I=20have=20a=20system=20(ver=204.= 2)=20which=20I=20can=20not update=20right=20now,=20but=20I=20am=20connected=20to=20a=20StoreVault=20d= ata=20storage=20device which=20has=20a=202.2T=20disk,=20so=20it=20is=20showing=20up=20as=20to=20l= arge=20to=20save=20data=20to. =20 df=20-h=20shows=20the=20following =20 Filesystem Size=20=20=20=20=20=20=20=20Used=20=20=20=20=20=20=20Avail=20=20=20=20=20C= apacity=20=20Mounted=20on 10.9.1.15:/vol/exports/lsdist/1-storage=20=20=20222G=20=20=20=20=20=20-715= .7G=20=20=20937G -323%=20=20=20=20=20=20=20=20/storage/1 =20 I=20need=20to=20patch=20this=20until=20I=20can=20update=20the=20system,=20= any=20pointers=20to where=20(if=20there=20is=20one)=20to=20get=20the=20patch=20for=20this,=20a= nd=20installation instructions. =20 Any=20help=20will=20be=20greatly=20apprecieated. =20 =20 Thanx, =20 Bruce=20Ballou Technology=20Director SAU=20#27=20 ________________________________________________________________________ This=20Email=20has=20been=20scanned=20for=20all=20viruses=20by=20PAETEC=20= Email=20Scanning=20Services,=20utilizing=20MessageLabs=20proprietary=20Sky= Scan=20infrastructure.=20For=20more=20information=20on=20a=20proactive=20a= nti-virus=20service=20working=20around=20the=20clock,=20around=20the=20glo= be,=20visit=20http://www.paetec.com. ________________________________________________________________________ From owner-freebsd-stable@FreeBSD.ORG Mon Dec 22 21:20:59 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3A831065675 for ; Mon, 22 Dec 2008 21:20:59 +0000 (UTC) (envelope-from admin@stardothosting.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by mx1.freebsd.org (Postfix) with ESMTP id 90C5D8FC18 for ; Mon, 22 Dec 2008 21:20:59 +0000 (UTC) (envelope-from admin@stardothosting.com) Received: by yw-out-2324.google.com with SMTP id 9so1514134ywe.13 for ; Mon, 22 Dec 2008 13:20:58 -0800 (PST) Received: by 10.65.241.15 with SMTP id t15mr5403676qbr.8.1229979180907; Mon, 22 Dec 2008 12:53:00 -0800 (PST) Received: from kevin (not.enough.unixsluts.com [76.10.166.187]) by mx.google.com with ESMTPS id k7sm13607946qba.26.2008.12.22.12.52.59 (version=SSLv3 cipher=RC4-MD5); Mon, 22 Dec 2008 12:53:00 -0800 (PST) From: "SDH Admin" To: References: In-Reply-To: Date: Mon, 22 Dec 2008 15:52:44 -0500 Message-ID: <006401c96477$3dd8e440$b98aacc0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AclkcCUwWubelt03QLWhCvzeSOL9JQABsmyw Content-Language: en-us Subject: RE: ver 4.2 won't allow save because it can't see 2.2T disk drive X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2008 21:20:59 -0000 >I need to patch this until I can update the system, any pointers to >where (if there is one) to get the patch for this, and installation >instructions. What is the 2.2T disk formatted as? Can you give more details on your hardware (storage device and the 4.2 server), as well as posting your dmesg output. --- Kevin K. Systems Administrator www.stardothosting.com From owner-freebsd-stable@FreeBSD.ORG Tue Dec 23 03:20:08 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67DEF1065670 for ; Tue, 23 Dec 2008 03:20:07 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.119.58.2]) by mx1.freebsd.org (Postfix) with ESMTP id 9B5F38FC08 for ; Tue, 23 Dec 2008 03:20:06 +0000 (UTC) (envelope-from brett@lariat.net) Received: (from brett@localhost) by lariat.net (8.9.3/8.9.3) id UAA14987 for stable@freebsd.org; Mon, 22 Dec 2008 20:07:29 -0700 (MST) Date: Mon, 22 Dec 2008 20:07:29 -0700 (MST) From: Brett Glass Message-Id: <200812230307.UAA14987@lariat.net> To: stable@freebsd.org Cc: Subject: FreeBSD 7.1 - Actual schedule? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2008 03:20:08 -0000 The schedule for release of FreeBSD 7.1 at http://www.freebsd.org/releases/7.1R/schedule.html is so woefully out of date that we've given up waiting and built a bunch of systems with 7.0-RELEASE, even though clients were asking us to put 7.1-RELEASE on them. Where can one track the actual progress toward a release? There appears to be no "to do" list (as there was for previous releases), and therefore no way to easily keep abreast of progress, snags, etc. --Brett Glass From owner-freebsd-stable@FreeBSD.ORG Tue Dec 23 03:42:08 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21C791065670 for ; Tue, 23 Dec 2008 03:42:08 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from phoebe.cse.buffalo.edu (phoebe.cse.buffalo.edu [128.205.32.89]) by mx1.freebsd.org (Postfix) with ESMTP id D8A7B8FC1B for ; Tue, 23 Dec 2008 03:42:07 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from [192.168.1.101] (cpe-74-77-179-53.buffalo.res.rr.com [74.77.179.53]) (authenticated bits=0) by phoebe.cse.buffalo.edu (8.14.1/8.13.7) with ESMTP id mBN3RTQj079947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Dec 2008 22:27:30 -0500 (EST) (envelope-from kensmith@cse.buffalo.edu) From: Ken Smith To: Brett Glass In-Reply-To: <200812230307.UAA14987@lariat.net> References: <200812230307.UAA14987@lariat.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-soD4bgAPq3xCCAPED+Rj" Date: Mon, 22 Dec 2008 22:27:24 -0500 Message-Id: <1230002844.13438.25.camel@neo.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-DCC-Buffalo.EDU-Metrics: phoebe.cse.buffalo.edu 1029; Body=0 Fuz1=0 Fuz2=0 X-Spam-Status: No, score=1.7 required=5.0 tests=RCVD_IN_SORBS_DUL, RDNS_DYNAMIC autolearn=no version=3.2.3 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on phoebe.cse.buffalo.edu Cc: stable@freebsd.org Subject: Re: FreeBSD 7.1 - Actual schedule? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2008 03:42:08 -0000 --=-soD4bgAPq3xCCAPED+Rj Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2008-12-22 at 20:07 -0700, Brett Glass wrote: > The schedule for release of FreeBSD 7.1 at >=20 > http://www.freebsd.org/releases/7.1R/schedule.html >=20 > is so woefully out of date that we've given up waiting and built > a bunch of systems with 7.0-RELEASE, even though clients were > asking us to put 7.1-RELEASE on them. Where can one track the > actual progress toward a release? There appears to be no > "to do" list (as there was for previous releases), and therefore > no way to easily keep abreast of progress, snags, etc. >=20 Yeah, sorry. I've apologized a couple times here about the communication issues and indicated its actively being worked on for next time. This time is something of a lost cause at this point. I just sent out the request that the builds for 7.1-RC2 begin, which unless something *really* *really* catastrophic comes along will be the last of the public tests. If that's the way it goes 7.1-REL will happen about 1.5 to 2 weeks from now, maybe a bit less. --=20 Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-soD4bgAPq3xCCAPED+Rj Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAklQWpwACgkQ/G14VSmup/abUACcDEnsqe4K+PH8qpyXLitVTBYM f8UAn2ELc/Va3NcpzcdaXp9kcc7wtDHM =VPVt -----END PGP SIGNATURE----- --=-soD4bgAPq3xCCAPED+Rj-- From owner-freebsd-stable@FreeBSD.ORG Tue Dec 23 05:56:01 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 790FB106564A for ; Tue, 23 Dec 2008 05:56:01 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by mx1.freebsd.org (Postfix) with ESMTP id 508A68FC13 for ; Tue, 23 Dec 2008 05:55:58 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so3732177rvf.43 for ; Mon, 22 Dec 2008 21:55:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=ITCr+cEvHHaHMpsCHwFofJAuT7ePxUmhJ78XUCgDz68=; b=SKNIh7XFMPqvy5MD9BsF1jVdx6OszFvf7/xNEYvufppFH56v9Vdp8HAnCz+MZX67MS iT1JyIJBw6SPhlAoG4wfl0J6fi9ISghWP2K8FB64tL23zhoMFwRo1xwDbzQay15z9MJf tzGTlVemcVQlT7uxNIDbPwJt9wbFYMCkJy36E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=wFpw06gNDftsSwCjOrT41ZrLotWcHJm+wTZX9alNbj+HMSYBHCaOr0IzmFzkEJK9Sf mlPXEo4hSpdfhTKpjfAuBIcZBEAOABe5oP1mbnKhIROPFx678riT3dpU8ZTFXZL41cju 9Qs1xJPux0EKDJOs3XDrisVoKyuQZU4LoUAXk= Received: by 10.140.188.10 with SMTP id l10mr3573095rvf.94.1230010556759; Mon, 22 Dec 2008 21:35:56 -0800 (PST) Received: by 10.140.135.2 with HTTP; Mon, 22 Dec 2008 21:35:56 -0800 (PST) Message-ID: <7d6fde3d0812222135l753daf54geb37b696c9c1cf8@mail.gmail.com> Date: Mon, 22 Dec 2008 21:35:56 -0800 From: "Garrett Cooper" To: amd64@freebsd.org, stable MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: -m32 broken on bi-arch amd64 systems? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2008 05:56:01 -0000 Hi guys, I think I may have found an issue today with our bi-endian structure, and I wanted to make sure whether or not it was an already known issue (-m32 is broken for gcc with lib32/libgcc.a): [root@fbsd-7-test]# gcc -o boo boo.c # Compiles [root@fbsd-7-test]# gcc -m32 -o boo boo.c /usr/bin/ld: skipping incompatible /usr/lib/libgcc.a when searching for -lgcc /usr/bin/ld: skipping incompatible /usr/lib/libgcc.a when searching for -lgcc /usr/bin/ld: cannot find -lgcc [root@fbsd-7-test]# file /usr/lib32/libgcc_s.so.1 /usr/lib32/libgcc_s.so.1: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, stripped [root@fbsd-7-test]# uname -a FreeBSD fbsd-7-test.gateway.2wire.net 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Sun Nov 23 16:19:09 UTC 2008 root@fbsd-7-test.gateway.2wire.net:/usr/obj/usr/src/sys/STARR amd64 I wish I had my amd64 CURRENT machine in front of me to confirm this, but I don't. Please keep me CC'ed as I am not subscribed to either amd64@ or stable@. Thanks! -Garrett From owner-freebsd-stable@FreeBSD.ORG Tue Dec 23 06:18:23 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20FDD1065670 for ; Tue, 23 Dec 2008 06:18:23 +0000 (UTC) (envelope-from heliocentric@gmail.com) Received: from mail-gx0-f19.google.com (mail-gx0-f19.google.com [209.85.217.19]) by mx1.freebsd.org (Postfix) with ESMTP id 9376D8FC19 for ; Tue, 23 Dec 2008 06:18:22 +0000 (UTC) (envelope-from heliocentric@gmail.com) Received: by gxk12 with SMTP id 12so1490946gxk.19 for ; Mon, 22 Dec 2008 22:18:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=r2OgACX+l1+9f92YIU9kyhZ7+QwVoKjQAzV4kjM/Fzo=; b=O+aQue3djRYr9c7HOHFAOXRnPRNL4OBQziQYog0KFFZi2E09j7ZgR575JCmlxnCwKm uN3BNP6jAUD61c2yKHvwl4iE44jCHw8fnI3WiBUjLMnKjXll9prre1SxNWFoKMw0Eres k6/B52FSY1MoNtQHs++YRRgTr0S/2Zoi/8jmU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=yDlj9aFaYTA/iFyRQu/bJ5/3q8y8Wd63IPoPz3psVMFXuslbAtYc15Jai/F+T1poHf cXccnDnwZTyjEMYNLKGlV7NSpUev6tdR+Tlfs0n7d+uVuaSJIiW4Rbe0IAYkGGUa6Xto P2j1q022H94K/JM2ohht0d0NN/qtEuIgLw4t4= Received: by 10.90.31.4 with SMTP id e4mr3665940age.113.1230013101476; Mon, 22 Dec 2008 22:18:21 -0800 (PST) Received: by 10.90.100.6 with HTTP; Mon, 22 Dec 2008 22:18:21 -0800 (PST) Message-ID: Date: Tue, 23 Dec 2008 01:18:21 -0500 From: "Dylan Cochran" Sender: heliocentric@gmail.com To: freebsd-stable In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: X-Google-Sender-Auth: 55739cb8340c3b5b Subject: Re: Hard lock on 7.1-RC1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2008 06:18:23 -0000 On Sun, Dec 21, 2008 at 3:05 PM, Dylan Cochran wrote: > I'm hitting a strange lockup on 7.1-RC1, where some socket operations > seem to stall, as well as basic file operations. The only reproducable > way I have of triggering it is by doing multiple inserts into > phpmyadmin on lighttpd+fastcgi php5 + mysql51-server, though this > isn't the only thing which triggers it, just the only one which is > semi reliable. I've also reproduced this on another machine, set up > specifically to rule out any machine specific problems (as they have > different drive controllers, one uses gjournal, etc). > > I inititially built a kernel with SW_WATCHDOG, and attempted to use > watchdogd and DDB to get an output from show locks, but the watchdogd > hasn't panicked the machine, so at least devfs is still unlocked; I'm > not able to get physical access to the machine until monday. > > The bug was introduced as far as I can tell, between 7.1-BETA2 and 7.1-RC= 1. > > Any suggestions on what I can test for tommorow? > I updated the kernel source to RELENG_7_1 as of a few hours ago, and built with DEBUG_VFS_LOCKS as well. Luckily the backtrace included the operating it was at before the watchdog, which seems to be kern_sendfile(). I'm no expert at kernel debugging, so any assistance on tracking this down further would be greatly appreciated. And, as promised, here is the output of script after the watchdog induced p= anic: Script started on Tue Dec 23 01:05:56 2008 # cu -l cua01 interrupt total irq4: sio0 623 irq6: fdc0 1 irq17: fwohci0 3 irq18: rl0 uhci2++ 60718 irq23: rl1 ehci0 206 cpu0: timer 514596 Total 576147 KDB: stack backtrace: db_trace_self_wrapper(c0b55b52,e66e0ae0,c07615e9,c0b50617,8ca93,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0b50617,8ca93,0,c41a7690,2,...) at kdb_backtrace+0x29 hardclock(0,c07ff29d,0,0,4,...) at hardclock+0x1f9 lapic_handle_timer(e66e0b08) at lapic_handle_timer+0x9c Xtimerint() at Xtimerint+0x1f --- interrupt, eip =3D 0xc07ff29d, esp =3D 0xe66e0b48, ebp =3D 0xe66e0c34 -= -- kern_sendfile(c41a7690,e66e0cfc,0,0,0,...) at kern_sendfile+0x90d do_sendfile(e66e0d2c,c0aba265,c41a7690,e66e0cfc,20,...) at do_sendfile+0xb1 sendfile(c41a7690,e66e0cfc,20,16,e66e0d2c,...) at sendfile+0x13 syscall(e66e0d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (393, FreeBSD ELF32, sendfile), eip =3D 0x282cb0cb, esp =3D 0xbfbfc7cc, ebp =3D 0xbfbfe848 --- KDB: enter: watchdog timeout [thread pid 1288 tid 100060 ] Stopped at kdb_enter_why+0x3a: movl $0,kdb_why db> show lock db> p=08 =08show all proc pid ppid pgrp uid state wmesg wchan cmd 1600 902 902 0 R watchdogd 1470 1469 1470 0 S+ ttyin 0xc418fc10 csh 1469 1 1469 0 Ss+ wait 0xc46032b8 login 1468 1 1468 0 Ss+ ttyin 0xc41ac810 getty 1427 1 1427 0 Ss nanslp 0xc0c7dc44 cron 1420 1 1420 0 Ss select 0xc0c88eb8 sshd 1419 1289 1289 80 SJ accept 0xc445ab9a php-cgi 1418 1289 1289 80 SJ accept 0xc445ab9a php-cgi 1417 1289 1289 80 SJ accept 0xc445ab9a php-cgi 1416 1289 1289 80 SJ accept 0xc445ab9a php-cgi 1415 1289 1289 80 SJ accept 0xc445ab9a php-cgi 1414 1289 1289 80 SJ accept 0xc445ab9a php-cgi 1413 1289 1289 80 SJ accept 0xc445ab9a php-cgi 1412 1289 1289 80 SJ accept 0xc445ab9a php-cgi 1411 1289 1289 80 SJ accept 0xc445ab9a php-cgi 1410 1289 1289 80 SJ accept 0xc445ab9a php-cgi 1409 1289 1289 80 SJ accept 0xc445ab9a php-cgi 1408 1289 1289 80 SJ accept 0xc445ab9a php-cgi 1407 1289 1289 80 SJ accept 0xc445ab9a php-cgi --More-- 1406 1289 1289 80 SJ accept 0xc445ab9a php-cgi --More-- 1405 1289 1289 80 SJ accept 0xc445ab9a php-cgi 1404 1289 1289 80 SJ accept 0xc445ab9a php-cgi 1403 1300 1300 80 SJ accept 0xc445a6ba php-cgi 1402 1300 1300 80 SJ accept 0xc445a6ba php-cgi 1401 1300 1300 80 SJ accept 0xc445a6ba php-cgi 1400 1300 1300 80 SJ accept 0xc445a6ba php-cgi 1399 1300 1300 80 RJ php-cgi 1398 1300 1300 80 SJ accept 0xc445a6ba php-cgi 1397 1300 1300 80 SJ accept 0xc445a6ba php-cgi 1396 1300 1300 80 SJ accept 0xc445a6ba php-cgi 1395 1300 1300 80 SJ accept 0xc445a6ba php-cgi 1394 1300 1300 80 SJ accept 0xc445a6ba php-cgi 1393 1300 1300 80 SJ accept 0xc445a6ba php-cgi 1392 1300 1300 80 SJ accept 0xc445a6ba php-cgi 1391 1300 1300 80 SJ accept 0xc445a6ba php-cgi 1390 1300 1300 80 SJ accept 0xc445a6ba php-cgi 1389 1300 1300 80 SJ accept 0xc445a6ba php-cgi 1388 1300 1300 80 SJ accept 0xc445a6ba php-cgi 1322 1 1322 25 SsJ pause 0xc4562b40 sendmail 1316 1 1316 0 RsJ sendmail --More-- 1306 1 1306 0 SsJ select 0xc0c88eb8 sshd 1300 1288 1300 80 SsJ wait 0xc43beae0 initial thread 1289 1288 1289 80 SsJ wait 0xc4564000 initial thread 1288 1 1287 80 RJ CPU 0 lighttpd 1286 1173 1170 88 R+J (threaded) mysqld 100114 S sigwait 0xe67a2be0 mysqld 100090 S ucond 0xc4359580 mysqld 100092 RunQ mysqld 100091 RunQ mysqld 100089 S ucond 0xc43598c0 mysqld 100088 S ucond 0xc4358c80 mysqld 100087 S ucond 0xc4094780 mysqld 100086 S ucond 0xc4359140 mysqld 100049 S select 0xc0c88eb8 initial thread 1173 1 1170 88 S+J wait 0xc43be2b8 sh 920 1 920 0 R+ (threaded) venti 100072 S ucond 0xc4358300 venti 100071 S accept 0xc445b03a venti 100070 S ucond 0xc4358200 venti 100069 S ucond 0xc4095980 venti --More-- 100068 S ucond 0xc41b1e00 venti 100067 S ucond 0xc4358100 venti 100066 S ucond 0xc4358280 venti 100065 S ucond 0xc41a45c0 venti 100064 S accept 0xc445a1da venti 100063 RunQ venti 100053 RunQ venti 902 1 902 0 Ss wait 0xc4343570 watchdogd 891 1 891 102 Rs gmond 770 1 770 0 Ss select 0xc0c88eb8 devd 338 1 338 65 Ss select 0xc0c88eb8 dhclient 322 1 49 0 S+ select 0xc0c88eb8 dhclient 48 0 0 0 SL sdflush 0xc0c95228 [softdepflush] 47 0 0 0 RL [syncer] 46 0 0 0 SL vlruwt 0xc4342000 [vnlru] 45 0 0 0 SL psleep 0xc0c89324 [bufdaemon] 44 0 0 0 SL pgzero 0xc0c95e00 [pagezero] 43 0 0 0 SL psleep 0xc0c95a18 [vmdaemon] 42 0 0 0 SL psleep 0xc0c959e0 [pagedaemon] 41 0 0 0 SL waiting_ 0xc0c8b0b4 [sctp_iterator] --More-- 40 0 0 0 WL [irq7: ppbus0 ppc0] 39 0 0 0 WL [irq1: atkbd0] 38 0 0 0 WL [irq15: ata1] 37 0 0 0 WL [irq14: ata0] 36 0 0 0 WL [swi0: sio] 35 0 0 0 SL - 0xc418d83c [fdc0] 34 0 0 0 SL - 0xc4097000 [fw0_probe] 33 0 0 0 SL - 0xc408c200 [fw0_taskq] 32 0 0 0 SL usbevt 0xc4013210 [usb4] 31 0 0 0 WL [irq23: rl1 ehci0] 30 0 0 0 SL usbevt 0xc407f210 [usb3] 29 0 0 0 SL usbevt 0xc406c210 [usb2] 28 0 0 0 WL [irq18: rl0 uhci2++] 27 0 0 0 SL usbevt 0xc405c210 [usb1] 26 0 0 0 WL [irq19: uhci1] 25 0 0 0 SL usbtsk 0xc0c7b234 [usbtask-dr] 24 0 0 0 SL usbtsk 0xc0c7b220 [usbtask-hc] 23 0 0 0 SL usbevt 0xc4024210 [usb0] 22 0 0 0 WL [irq16: uhci0 uhci3] 21 0 0 0 WL [irq9: acpi0] --More-- 20 0 0 0 WL [swi6: task queue] 19 0 0 0 WL [swi6: Giant taskq] 18 0 0 0 SL - 0xc3fe3700 [thread taskq] 17 0 0 0 WL [swi5: +] 9 0 0 0 SL - 0xc3fe3880 [acpi_task_2] 8 0 0 0 SL - 0xc3fe3880 [acpi_task_1] 7 0 0 0 SL - 0xc3fe3880 [acpi_task_0] 16 0 0 0 WL [swi2: cambio] 6 0 0 0 SL ccb_scan 0xc0c4b054 [xpt_thrd] 5 0 0 0 SL - 0xc3fe3a80 [kqueue taskq] 15 0 0 0 SL - 0xc0c7da74 [yarrow] 4 0 0 0 SL - 0xc0c7b62c [g_down] 3 0 0 0 SL - 0xc0c7b628 [g_up] 2 0 0 0 SL - 0xc0c7b620 [g_event] 14 0 0 0 WL [swi3: vm] 13 0 0 0 WL [swi4: clock sio] 12 0 0 0 WL [swi1: net] 11 0 0 0 RL [idle: cpu0] 1 0 1 0 SLs wait 0xc3f16ae0 [init] 10 0 0 0 SL audit_wo 0xc0c94c64 [audit] --More-- 0 0 0 0 SLs sched 0xc0c7b6e0 [swapper] db> Killed From owner-freebsd-stable@FreeBSD.ORG Tue Dec 23 12:41:43 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A54461065674 for ; Tue, 23 Dec 2008 12:41:43 +0000 (UTC) (envelope-from bsdlist@cogeco.ca) Received: from fep7.cogeco.net (smtp2.cogeco.ca [216.221.81.29]) by mx1.freebsd.org (Postfix) with ESMTP id 7F84E8FC17 for ; Tue, 23 Dec 2008 12:41:43 +0000 (UTC) (envelope-from bsdlist@cogeco.ca) Received: from [192.168.1.126] (d150-251-98.home.cgocable.net [24.150.251.98]) by fep7.cogeco.net (Postfix) with ESMTP id 75C19169D for ; Mon, 22 Dec 2008 09:59:03 -0500 (EST) Message-ID: <494FABC2.1020804@cogeco.ca> Date: Mon, 22 Dec 2008 10:01:22 -0500 From: Paul MacKenzie User-Agent: Thunderbird 3.0a1pre (Windows/2008022014) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4949673B.2070701@elehost.com> <494AED9E.9090900@cogeco.ca> In-Reply-To: <494AED9E.9090900@cogeco.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: 7.1-PRERELEASE: arcmsr write performance problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2008 12:41:43 -0000 > I actually find that running Wusage 8.0 a few times even with nice-19 > may be implicated in getting the system to spiral downwards. I hesitate > to mention this as it seems to be working fine on another 7.X server. I > believe that Wusage is tied to 6.X libraries and I wonder if somehow > this may initiate the problem. I also have another sio/com based program > running every few minutes which is also connected to the 6.X library > (scom thermal application for temperature monitoring) and turning both > of these off seems to help. I am going to try a 24 hour period without > either of these two running after a fresh reboot and we will see if this > is indeed one source to my abominable problem. > > Once the system spirals down into its locking then the io performance > never seems to recover unless I reboot it or somehow find the process > that is locked and kill it. > So after the testing period with the scom not running and wusage not running I still have the problem albeit less often. The stress on the system seems to bring it forward as notice by my other tests. It is easiest to see on httpd and a stop needs to be run try to free up the system. Dec 19 07:32:43 /usr/local/sbin/apachectl -k stop Dec 19 07:33:35 kernel: pid 31376 (httpd), uid 80: exited on signal 11 Dec 19 07:33:35 kernel: pid 31194 (httpd), uid 80: exited on signal 11 Dec 19 07:33:36 kernel: pid 31469 (httpd), uid 80: exited on signal 11 Dec 19 07:33:36 kernel: pid 31754 (httpd), uid 80: exited on signal 11 Dec 19 07:33:37 kernel: pid 31168 (httpd), uid 80: exited on signal 11 Dec 19 07:33:37 kernel: pid 31753 (httpd), uid 80: exited on signal 11 Dec 19 07:33:38 kernel: pid 31763 (httpd), uid 80: exited on signal 11 Dec 19 07:33:38 kernel: pid 31748 (httpd), uid 80: exited on signal 11 Its relatively easy to get this restarted but when it is something else in the system it is hard to locate and I have to do a reboot to release the blockage. When it is apache that has "locked" I have to kill it as a graceful will not work. The majority of the processes are in UFS state when it happens. If there was a quick way to determine which one has "locked" the system that would be so helpful as a temporary workaround. I am going to try to replace the motherboard next, This is one of the last hardware replacements to isolate this as a hardware problem. From owner-freebsd-stable@FreeBSD.ORG Tue Dec 23 16:34:59 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9910F1065689 for ; Tue, 23 Dec 2008 16:34:59 +0000 (UTC) (envelope-from mikej@rogers.com) Received: from smtp123.rog.mail.re2.yahoo.com (smtp123.rog.mail.re2.yahoo.com [206.190.53.28]) by mx1.freebsd.org (Postfix) with SMTP id 3C11A8FC12 for ; Tue, 23 Dec 2008 16:34:58 +0000 (UTC) (envelope-from mikej@rogers.com) Received: (qmail 23618 invoked from network); 23 Dec 2008 16:34:58 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Received:Message-ID:In-Reply-To:References:Date:Subject:From:To:Cc:User-Agent:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:Importance; b=BIw2CEq+WFzNWdSeXAwTh740ppBN8+LQkp/eIDaF9Ae5P4Fu2O2S5+FH2LbzdIG+Tm8zEoxM0+Sp2crJev+8D1TnhbbjwyKQ6SjQZkOwvLRlx6Ui88LKKe+32Q5lJGYd8dzFgNuZpSZ2KcrDqjkCOYP88S6iq3mIkYHCVUhV8I0= ; Received: from unknown (HELO wettoast.dyndns.org) (mikej@99.227.98.203 with login) by smtp123.rog.mail.re2.yahoo.com with SMTP; 23 Dec 2008 16:34:58 -0000 X-YMail-OSG: S23wYZQVM1lBy1Ekj0oAOCksKthkINGJr99bXO10qVFpT4KzFlhWEZcJzXZRq_bwug-- X-Yahoo-Newman-Property: ymail-3 Received: from 38.99.187.34 (SquirrelMail authenticated user mikej) by wettoast.dyndns.org with HTTP; Tue, 23 Dec 2008 11:35:11 -0500 (EST) Message-ID: In-Reply-To: <4944D3A3.8040505@delphij.net> References: <20081210160325.GA72838@mr-happy.com> <4944D3A3.8040505@delphij.net> Date: Tue, 23 Dec 2008 11:35:11 -0500 (EST) From: "Mike Jakubik" To: d@delphij.net User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Jeff Blank , Vlad GALU , freebsd-stable@freebsd.org Subject: Re: bce(4) and rx errors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2008 16:34:59 -0000 On Sun, December 14, 2008 4:36 am, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, Gents, > > I have not yet talked this with David but it looks like this patch would > make it disappear. > > Cheers, I have been running my production systems for about a week now with this patch, interrupts are low and rx errors reports are gone, thanks Xin. P.S. I'm still having problems with my application, but at this point i'm not sure whether it has anything to do with the driver, for what its worth here is the error which causes it to stop accepting new connection. wrapper.log.15:INFO | jvm 1 | 2008/12/17 18:49:12 | Exception in thread "Thread-0" java.nio.channels.IllegalBlockingModeException wrapper.log.15:INFO | jvm 1 | 2008/12/17 18:49:12 | at sun.nio.ch.ServerSocketAdaptor.accept(ServerSocketAdaptor.java:86) wrapper.log.15:INFO | jvm 1 | 2008/12/17 18:49:12 | at com.precyse.chat.service.connector.ServerSocketChannelConnector.registerSelection(ServerSocketChannelConnector.java:404) wrapper.log.15:INFO | jvm 1 | 2008/12/17 18:49:12 | at com.precyse.chat.service.connector.ServerSocketChannelConnector.run(ServerSocketChannelConnector.java:148) From owner-freebsd-stable@FreeBSD.ORG Tue Dec 23 16:56:29 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5422D1065675 for ; Tue, 23 Dec 2008 16:56:29 +0000 (UTC) (envelope-from andy@jaygroupllc.com) Received: from mail.jaygroupllc.com (mail.jaygroupllc.com [64.221.118.242]) by mx1.freebsd.org (Postfix) with ESMTP id 1C5488FC22 for ; Tue, 23 Dec 2008 16:56:29 +0000 (UTC) (envelope-from andy@jaygroupllc.com) Received: from localhost.localdomain ([66.226.75.20]) by mail.jaygroupllc.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Dec 2008 08:35:19 -0800 From: To: Message-ID: <1-JAY-01mgsQQIqrfFz00001671@mail.jaygroupllc.com> X-OriginalArrivalTime: 23 Dec 2008 16:35:19.0750 (UTC) FILETIME=[71AE2E60:01C9651C] Date: 23 Dec 2008 08:35:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Alert Notification: Billing Pending Inactivation in Account X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2008 16:56:29 -0000 Renew Your Account Now ! Dear Advertiser, This is your official notification from Yahoo! Inc. that the service(s) listed below will be deactivated and deleted if not renewed immediately. As the Primary Contact, you must renew the service(s) listed below or it will be deactivated and deleted. [1]Renew Now your Yahoo Sponsored Search services. SERVICE: Yahoo Sponsored Search EXPIRATION: December, 23 2008 Thank you for using Yahoo Inc service. We appreciate your business and the opportunity to serve you. Yahoo Inc. Sponsored Search Service *Note : Please do not reply to this Customer Service e-mail. Copyright ©2008 Yahoo! Inc. All rights reserved. References 1. http://www.yahoobusinessupdate.com/marketingsolutions/adui/renew/login/loadSignin.htm From owner-freebsd-stable@FreeBSD.ORG Tue Dec 23 17:04:19 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 863171065677 for ; Tue, 23 Dec 2008 17:04:19 +0000 (UTC) (envelope-from maciej@suszko.eu) Received: from 30.mail-out.ovh.net (30.mail-out.ovh.net [213.186.62.213]) by mx1.freebsd.org (Postfix) with SMTP id EB8FA8FC13 for ; Tue, 23 Dec 2008 17:04:18 +0000 (UTC) (envelope-from maciej@suszko.eu) Received: (qmail 24061 invoked by uid 503); 23 Dec 2008 16:35:53 -0000 Received: from gw2.ovh.net (HELO mail22.ha.ovh.net) (213.251.189.202) by 30.mail-out.ovh.net with SMTP; 23 Dec 2008 16:35:53 -0000 Received: from b0.ovh.net (HELO queue-out) (213.186.33.50) by b0.ovh.net with SMTP; 23 Dec 2008 16:36:15 -0000 Received: from host-89-228-109-220.olsztyn.mm.pl (HELO localhost) (maciej@suszko.eu@89.228.109.220) by ns0.ovh.net with SMTP; 23 Dec 2008 16:36:14 -0000 Date: Tue, 23 Dec 2008 17:36:08 +0100 From: Maciej Suszko To: "Garrett Cooper" Message-ID: <20081223173608.068fe9d8@suszko.eu> In-Reply-To: <7d6fde3d0812222135l753daf54geb37b696c9c1cf8@mail.gmail.com> References: <7d6fde3d0812222135l753daf54geb37b696c9c1cf8@mail.gmail.com> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/07I.D4JU0SUT0K4yXry66UE"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Ovh-Tracer-Id: 1404560134263759012 X-Ovh-Remote: 89.228.109.220 (host-89-228-109-220.olsztyn.mm.pl) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-Spam-Check: DONE|H 0.5/N Cc: amd64@freebsd.org, stable Subject: Re: -m32 broken on bi-arch amd64 systems? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2008 17:04:19 -0000 --Sig_/07I.D4JU0SUT0K4yXry66UE Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable "Garrett Cooper" wrote: > Hi guys, > I think I may have found an issue today with our bi-endian > structure, and I wanted to make sure whether or not it was an already > known issue (-m32 is broken for gcc with lib32/libgcc.a): >=20 > [root@fbsd-7-test]# gcc -o boo boo.c # Compiles > [root@fbsd-7-test]# gcc -m32 -o boo boo.c > /usr/bin/ld: skipping incompatible /usr/lib/libgcc.a when searching > for -lgcc /usr/bin/ld: skipping incompatible /usr/lib/libgcc.a when > searching for -lgcc /usr/bin/ld: cannot find -lgcc > [root@fbsd-7-test]# file /usr/lib32/libgcc_s.so.1 > /usr/lib32/libgcc_s.so.1: ELF 32-bit LSB shared object, Intel 80386, > version 1 (FreeBSD), dynamically linked, stripped > [root@fbsd-7-test]# uname -a > FreeBSD fbsd-7-test.gateway.2wire.net 7.1-PRERELEASE FreeBSD > 7.1-PRERELEASE #0: Sun Nov 23 16:19:09 UTC 2008 > root@fbsd-7-test.gateway.2wire.net:/usr/obj/usr/src/sys/STARR amd64 >=20 > I wish I had my amd64 CURRENT machine in front of me to confirm > this, but I don't. > Please keep me CC'ed as I am not subscribed to either amd64@ or > stable@. Thanks! > -Garrett I also noticed that behavior, shouldn't compiler/linker look into /usr/lib32 without additional -B switch? --=20 regards, Maciej Suszko. --Sig_/07I.D4JU0SUT0K4yXry66UE Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAklRE3gACgkQCikUk0l7iGpeIwCeLW+OZJOIEsBFF+q6zVCps0mK 9HYAn39GVLyus5iOidPvSlnkXkAWe7xB =nA6Q -----END PGP SIGNATURE----- --Sig_/07I.D4JU0SUT0K4yXry66UE-- From owner-freebsd-stable@FreeBSD.ORG Tue Dec 23 17:15:55 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2926F1065673 for ; Tue, 23 Dec 2008 17:15:55 +0000 (UTC) (envelope-from ericlin@tamama.org) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by mx1.freebsd.org (Postfix) with ESMTP id DCF368FC08 for ; Tue, 23 Dec 2008 17:15:49 +0000 (UTC) (envelope-from ericlin@tamama.org) Received: by yx-out-2324.google.com with SMTP id 8so1647957yxb.13 for ; Tue, 23 Dec 2008 09:15:48 -0800 (PST) Received: by 10.150.92.10 with SMTP id p10mr14243600ybb.227.1230052548777; Tue, 23 Dec 2008 09:15:48 -0800 (PST) Received: by 10.151.122.6 with HTTP; Tue, 23 Dec 2008 09:15:48 -0800 (PST) Message-ID: <47713ee10812230915o7ea8fd1dge1ae7352694cb961@mail.gmail.com> Date: Wed, 24 Dec 2008 01:15:48 +0800 From: "Lin Jui-Nan Eric" To: stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: Process stuck in STOP state X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2008 17:15:55 -0000 Dear listers, Our FreeBSD Server uses NFS to access PHP files on NetApp, then serve them with apache 2.2 (worker MPM + php fastcgi mode). At least one time a day the apache process is stuck in the STOP state and is unkillable. gdb won't attach to the process, either. Does anyone have any similar issue? I have found that may be because of libkse, but we use libthr now. Thank you all in advance. From owner-freebsd-stable@FreeBSD.ORG Tue Dec 23 17:17:16 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 940E61065678 for ; Tue, 23 Dec 2008 17:17:16 +0000 (UTC) (envelope-from ericlin@tamama.org) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.190]) by mx1.freebsd.org (Postfix) with ESMTP id 50B198FC13 for ; Tue, 23 Dec 2008 17:17:16 +0000 (UTC) (envelope-from ericlin@tamama.org) Received: by rn-out-0910.google.com with SMTP id j71so2074712rne.12 for ; Tue, 23 Dec 2008 09:17:15 -0800 (PST) Received: by 10.150.226.15 with SMTP id y15mr14247736ybg.225.1230052635239; Tue, 23 Dec 2008 09:17:15 -0800 (PST) Received: by 10.151.122.6 with HTTP; Tue, 23 Dec 2008 09:17:15 -0800 (PST) Message-ID: <47713ee10812230917u506d8ee1ta9e93c8ef25e86e3@mail.gmail.com> Date: Wed, 24 Dec 2008 01:17:15 +0800 From: "Lin Jui-Nan Eric" To: stable@freebsd.org In-Reply-To: <47713ee10812230915o7ea8fd1dge1ae7352694cb961@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47713ee10812230915o7ea8fd1dge1ae7352694cb961@mail.gmail.com> Cc: Subject: Re: Process stuck in STOP state X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2008 17:17:16 -0000 > Dear listers, > > Our FreeBSD Server uses NFS to access PHP files on NetApp, then serve > them with apache 2.2 (worker MPM + php fastcgi mode). Sorry. we use -STABLE now. event# uname -a FreeBSD event 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #1: Thu Dec 4 01:45:42 CST 2008 root@event:/usr/obj/usr/src/sys/KERNEL amd64 From owner-freebsd-stable@FreeBSD.ORG Tue Dec 23 17:19:19 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13CC41065675 for ; Tue, 23 Dec 2008 17:19:19 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9BC698FC17 for ; Tue, 23 Dec 2008 17:19:18 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 35E8F28486 for ; Wed, 24 Dec 2008 01:19:17 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 953D1EB3B05; Wed, 24 Dec 2008 01:19:16 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id G72bB8-kECr0; Wed, 24 Dec 2008 01:19:11 +0800 (CST) Received: from charlie.delphij.net (c-67-180-38-12.hsd1.ca.comcast.net [67.180.38.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 12EEEEB3ADB; Wed, 24 Dec 2008 01:19:09 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=j8lGws+8n0doiZ8oyMQfplXQWMTfRIiHC/ISU0c7drkKLIo2xZSGCPSdXYzSdFts/ vmFry/XnyEq8obna0IhTw== Message-ID: <49511D8A.2000304@delphij.net> Date: Tue, 23 Dec 2008 09:19:06 -0800 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.18 (X11/20081125) MIME-Version: 1.0 To: Mike Jakubik References: <20081210160325.GA72838@mr-happy.com> <4944D3A3.8040505@delphij.net> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jeff Blank , Vlad GALU , d@delphij.net, freebsd-stable@freebsd.org Subject: Re: bce(4) and rx errors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2008 17:19:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Mike, Mike Jakubik wrote: > On Sun, December 14, 2008 4:36 am, Xin LI wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi, Gents, >> >> I have not yet talked this with David but it looks like this patch would >> make it disappear. >> >> Cheers, > > I have been running my production systems for about a week now with this > patch, interrupts are low and rx errors reports are gone, thanks Xin. > > P.S. I'm still having problems with my application, but at this point i'm > not sure whether it has anything to do with the driver, for what its worth > here is the error which causes it to stop accepting new connection. > > wrapper.log.15:INFO | jvm 1 | 2008/12/17 18:49:12 | Exception in > thread "Thread-0" java.nio.channels.IllegalBlockingModeException > wrapper.log.15:INFO | jvm 1 | 2008/12/17 18:49:12 | at > sun.nio.ch.ServerSocketAdaptor.accept(ServerSocketAdaptor.java:86) > wrapper.log.15:INFO | jvm 1 | 2008/12/17 18:49:12 | at > com.precyse.chat.service.connector.ServerSocketChannelConnector.registerSelection(ServerSocketChannelConnector.java:404) > wrapper.log.15:INFO | jvm 1 | 2008/12/17 18:49:12 | at > com.precyse.chat.service.connector.ServerSocketChannelConnector.run(ServerSocketChannelConnector.java:148) Thanks for the feedback. Could you check netstat -m and/or vmstat -z to see if there is any mbuf exhaustion issue? Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAklRHYoACgkQi+vbBBjt66AlTACeOz59K8geIlaJTIjzf6dB0xHR UwMAoLCy9bTTha8fu0Y6v1SzzMk5JuOH =wh5l -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Tue Dec 23 17:54:13 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB9891065705 for ; Tue, 23 Dec 2008 17:54:12 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by mx1.freebsd.org (Postfix) with ESMTP id 935728FC1B for ; Tue, 23 Dec 2008 17:54:12 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so1653311ywe.13 for ; Tue, 23 Dec 2008 09:54:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=ovWrXaurJz2jPxQ5Mcz9PjkO3qZagIga/BRgr7SAazA=; b=AFBU1J7VHXWtylGZKdFQpbp3hr3xv2HH6OJmCeN7KhCJVHmHpjOvZxzko2wtjADrcl nr4JA/5SIjVjygV2qD4XswPSrFrmjPdGh8HsvZFWLdN1D3FOqSJdKqV7+uvOVGt/BasT RqJR1RHeQCVZD46X429zq6ElZ0SvELfNQ1sB4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=i/StiynpTsiLeJ1e+Lmm9zPsLhlDhdPFXw53CF/pzLZIJGuwxrLgPPFmsLT3MJgkTw LWulwTwzanT5pjS96wzUBxyq90b5QjtXyAijvPYuUIfLPXHIGYAN3nJJm1j08C2YZxqa 5AXL4wjC65Ojl6r1Hj0PIL1zfSuCZV978Jbc0= Received: by 10.90.113.11 with SMTP id l11mr4001266agc.91.1230053008581; Tue, 23 Dec 2008 09:23:28 -0800 (PST) Received: from kan.dnsalias.net (c-98-217-224-113.hsd1.ma.comcast.net [98.217.224.113]) by mx.google.com with ESMTPS id 18sm26401325agb.12.2008.12.23.09.23.27 (version=SSLv3 cipher=RC4-MD5); Tue, 23 Dec 2008 09:23:27 -0800 (PST) Date: Tue, 23 Dec 2008 12:23:13 -0500 From: Alexander Kabaev To: Maciej Suszko Message-ID: <20081223122313.6254e173@kan.dnsalias.net> In-Reply-To: <20081223173608.068fe9d8@suszko.eu> References: <7d6fde3d0812222135l753daf54geb37b696c9c1cf8@mail.gmail.com> <20081223173608.068fe9d8@suszko.eu> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/4ioWb7WqVNutJYefyNdX3X1"; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: amd64@freebsd.org, Garrett Cooper , stable Subject: Re: -m32 broken on bi-arch amd64 systems? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2008 17:54:13 -0000 --Sig_/4ioWb7WqVNutJYefyNdX3X1 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 23 Dec 2008 17:36:08 +0100 Maciej Suszko wrote: > "Garrett Cooper" wrote: > > Hi guys, > > I think I may have found an issue today with our bi-endian > > structure, and I wanted to make sure whether or not it was an > > already known issue (-m32 is broken for gcc with lib32/libgcc.a): > >=20 > > [root@fbsd-7-test]# gcc -o boo boo.c # Compiles > > [root@fbsd-7-test]# gcc -m32 -o boo boo.c > > /usr/bin/ld: skipping incompatible /usr/lib/libgcc.a when searching > > for -lgcc /usr/bin/ld: skipping incompatible /usr/lib/libgcc.a when > > searching for -lgcc /usr/bin/ld: cannot find -lgcc > > [root@fbsd-7-test]# file /usr/lib32/libgcc_s.so.1 > > /usr/lib32/libgcc_s.so.1: ELF 32-bit LSB shared object, Intel 80386, > > version 1 (FreeBSD), dynamically linked, stripped > > [root@fbsd-7-test]# uname -a > > FreeBSD fbsd-7-test.gateway.2wire.net 7.1-PRERELEASE FreeBSD > > 7.1-PRERELEASE #0: Sun Nov 23 16:19:09 UTC 2008 > > root@fbsd-7-test.gateway.2wire.net:/usr/obj/usr/src/sys/STARR amd64 > >=20 > > I wish I had my amd64 CURRENT machine in front of me to confirm > > this, but I don't. > > Please keep me CC'ed as I am not subscribed to either amd64@ or > > stable@. Thanks! > > -Garrett >=20 > I also noticed that behavior, shouldn't compiler/linker look > into /usr/lib32 without additional -B switch? > --=20 > regards, Maciej Suszko. Read email archives, this was discussed on several occasions before. Short summary: it never worked and will not work unless some non-trivial work is put into how GCC handles include and linker search paths. --=20 Alexander Kabaev --Sig_/4ioWb7WqVNutJYefyNdX3X1 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFJUR6BQ6z1jMm+XZYRAs3SAJ9ZTA35UkjFt6Q3FhbTr8elnOSJcwCfWjZV /kLeaKOsdVes4MoDhSuwKVg= =8iH3 -----END PGP SIGNATURE----- --Sig_/4ioWb7WqVNutJYefyNdX3X1-- From owner-freebsd-stable@FreeBSD.ORG Tue Dec 23 18:16:30 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 626F7106564A for ; Tue, 23 Dec 2008 18:16:30 +0000 (UTC) (envelope-from wieczyk@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by mx1.freebsd.org (Postfix) with ESMTP id 2FB1C8FC20 for ; Tue, 23 Dec 2008 18:16:29 +0000 (UTC) (envelope-from wieczyk@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so3983823rvf.43 for ; Tue, 23 Dec 2008 10:16:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=Woig57l+ZZSscuT3FT1ZcfxEJ6M44YV+wcSI/997xnU=; b=WgAuILW1PSktO642s1UqgKuTq2sn7z4LOPl20UQFrJJ7WO5F7/k6e0qhPVZLtVSXv+ jrxnkOKoWnlr6vq5xD9r3jEUwODsXxBE6ujVDTr5j1gbBYGUVnckU2udfcm0ZgDaPpSx 92m9SBc0XhBB2x4uFR1ia9p1hN0hXd6IE6GtU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=WTVciYRHAPcbpU/bqjhNTvDAI0nppnvufBEwnLWr7kEvsM4PIdsFJ3tYSrZQdQwX2r Uv1DZu9YbDJ1wxwgSRHis9y+BC7u/MUA1hyxz4tWEJhB7LFj3qJDTW8trV2I2l9CfG7x 6zULcx09DCPA/pJqmbR0LeSmzXxBLhQRv9vu4= Received: by 10.141.50.11 with SMTP id c11mr3865246rvk.28.1230054360883; Tue, 23 Dec 2008 09:46:00 -0800 (PST) Received: by 10.141.189.21 with HTTP; Tue, 23 Dec 2008 09:46:00 -0800 (PST) Message-ID: <1255bf0d0812230946nc90ee38u28b040c3d720868a@mail.gmail.com> Date: Tue, 23 Dec 2008 17:46:00 +0000 From: "=?ISO-8859-2?Q?Pawe=B3_Wieczorek?=" To: "Garrett Cooper" In-Reply-To: <7d6fde3d0812222135l753daf54geb37b696c9c1cf8@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7d6fde3d0812222135l753daf54geb37b696c9c1cf8@mail.gmail.com> Cc: amd64@freebsd.org, stable Subject: Re: -m32 broken on bi-arch amd64 systems? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2008 18:16:30 -0000 I will extend topic to C++: [19:38] zubr:~/Code (1) $ g++ -m32 -B /usr/lib32 p.cpp In file included from /usr/include/c++/4.2/ext/new_allocator.h:37, from /usr/include/c++/4.2/bits/c++allocator.h:39, from /usr/include/c++/4.2/bits/allocator.h:53, from /usr/include/c++/4.2/memory:54, from /usr/include/c++/4.2/string:48, from /usr/include/c++/4.2/bits/locale_classes.h:47, from /usr/include/c++/4.2/bits/ios_base.h:47, from /usr/include/c++/4.2/ios:48, from /usr/include/c++/4.2/ostream:45, from /usr/include/c++/4.2/iostream:45, from p.cpp:1: /usr/include/c++/4.2/new:95: error: 'operator new' takes type 'size_t' ('unsigned int') as first parameter /usr/include/c++/4.2/new:96: error: 'operator new' takes type 'size_t' ('unsigned int') as first parameter /usr/include/c++/4.2/new:99: error: 'operator new' takes type 'size_t' ('unsigned int') as first parameter /usr/include/c++/4.2/new:100: error: 'operator new' takes type 'size_t' ('unsigned int') as first parameter /usr/include/c++/4.2/new:105: error: 'operator new' takes type 'size_t' ('unsigned int') as first parameter /usr/include/c++/4.2/new:106: error: 'operator new' takes type 'size_t' ('unsigned int') as first parameter [19:38] zubr:~/Code (1) $ cat p.cpp #include int main() { return 0; } [19:39] zubr:~/Code $ Problem with C++ is more connected to headers than binaries, any suggestions how to use G++ to produce 32bit code ? From owner-freebsd-stable@FreeBSD.ORG Tue Dec 23 18:24:24 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66D2F1065670 for ; Tue, 23 Dec 2008 18:24:24 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: from mail-gx0-f15.google.com (mail-gx0-f15.google.com [209.85.217.15]) by mx1.freebsd.org (Postfix) with ESMTP id 12E188FC18 for ; Tue, 23 Dec 2008 18:24:23 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: by gxk8 with SMTP id 8so2608897gxk.7 for ; Tue, 23 Dec 2008 10:24:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=ArEGwMhDCe6ctRgKN/AWohJQRINdXtb/Zw08bNWKf+o=; b=npXaRlgW5EgnVsBSpxirEwSKPa7O2Rg8T6Gvb0R3jZ92Ve7SqGcN8ytelIr06JFa9p mN9HTzgcigSrxy012Q7jhxbwZP9zC3qEYtnuYirmoJICF3ECJ8ARa4WD0bT50u+mGmYe iGsEoUQc7+8gH1dkYH81ZZQDC55YDjDO36eNc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:references; b=d1aLl7sIdktdE1KALGCOQLd/ueJVlW/qMg10YNx03Tnb01w7ZElxP7NpZjk3eM5v7n Cpdrd7H/LSfFueFe7LtRGpNfNvm+5ez/KW1tNKCrLL1bukT4FE0t6xaAGQv89/QetJpo YC2KzheC78kJlfyPuqYUoBdTlt8z20Jr0K33Q= Received: by 10.151.12.1 with SMTP id p1mr3741140ybi.194.1230054904572; Tue, 23 Dec 2008 09:55:04 -0800 (PST) Received: by 10.151.39.1 with HTTP; Tue, 23 Dec 2008 09:55:04 -0800 (PST) Message-ID: <8cb6106e0812230955u1bd16932h7ae4ad3fc8c97f28@mail.gmail.com> Date: Tue, 23 Dec 2008 12:55:04 -0500 From: "Josh Carroll" To: "Maciej Suszko" In-Reply-To: <20081223173608.068fe9d8@suszko.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7d6fde3d0812222135l753daf54geb37b696c9c1cf8@mail.gmail.com> <20081223173608.068fe9d8@suszko.eu> Cc: amd64@freebsd.org, Garrett Cooper , stable Subject: Re: -m32 broken on bi-arch amd64 systems? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: josh.carroll@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2008 18:24:24 -0000 > I also noticed that behavior, shouldn't compiler/linker look > into /usr/lib32 without additional -B switch? > -- > regards, Maciej Suszko. > I don't know if it should or should not, but I can confirm that this behavior was around in 7.0-RELEASE, so it's been that way for quite a while, at least in the 7 branch. Josh From owner-freebsd-stable@FreeBSD.ORG Tue Dec 23 18:36:49 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 900491065687; Tue, 23 Dec 2008 18:36:49 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 6E51B8FC1B; Tue, 23 Dec 2008 18:36:49 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.3/8.14.3) with ESMTP id mBNIaneT090868; Tue, 23 Dec 2008 10:36:49 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.3/8.14.3/Submit) id mBNIanCJ090867; Tue, 23 Dec 2008 10:36:49 -0800 (PST) (envelope-from sgk) Date: Tue, 23 Dec 2008 10:36:49 -0800 From: Steve Kargl To: Josh Carroll Message-ID: <20081223183649.GA90840@troutmask.apl.washington.edu> References: <7d6fde3d0812222135l753daf54geb37b696c9c1cf8@mail.gmail.com> <20081223173608.068fe9d8@suszko.eu> <8cb6106e0812230955u1bd16932h7ae4ad3fc8c97f28@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8cb6106e0812230955u1bd16932h7ae4ad3fc8c97f28@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: amd64@freebsd.org, Garrett Cooper , stable , Maciej Suszko Subject: Re: -m32 broken on bi-arch amd64 systems? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2008 18:36:49 -0000 On Tue, Dec 23, 2008 at 12:55:04PM -0500, Josh Carroll wrote: > > I also noticed that behavior, shouldn't compiler/linker look > > into /usr/lib32 without additional -B switch? > > -- > > regards, Maciej Suszko. > > > > I don't know if it should or should not, but I can confirm that this > behavior was around in 7.0-RELEASE, so it's been that way for quite a > while, at least in the 7 branch. > Sigh. Read the list archives. It's been this way since Peter Wemm first introduce the ability to run i386 binaries on amd64. -- Steve From owner-freebsd-stable@FreeBSD.ORG Tue Dec 23 18:40:31 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 116D31065673; Tue, 23 Dec 2008 18:40:31 +0000 (UTC) (envelope-from jack@jarasoft.net) Received: from raats.xs4all.nl (raats.xs4all.nl [82.95.230.43]) by mx1.freebsd.org (Postfix) with ESMTP id BA1078FC1D; Tue, 23 Dec 2008 18:40:30 +0000 (UTC) (envelope-from jack@jarasoft.net) Received: from raats.xs4all.nl (localhost.jarasoft.net [127.0.0.1]) by raats.xs4all.nl (Postfix) with ESMTP id 2086A23534; Tue, 23 Dec 2008 19:30:09 +0100 (CET) Received: from jara3 (unknown [10.10.10.20]) by raats.xs4all.nl (Postfix) with ESMTPA id D55C923518; Tue, 23 Dec 2008 19:30:08 +0100 (CET) Message-ID: From: "Jack Raats" To: "freebsd-stable" , Date: Tue, 23 Dec 2008 19:30:07 +0100 Organization: JaRaSoft, Steenbergen, Nederland MIME-Version: 1.0 X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Relayed-By: GPGrelay Version 0.959 (Win32) X-Virus-Scanned: ClamAV using ClamSMTP on orac.jarasoft.net Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Problems installing FreeBSD 7.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jack Raats List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2008 18:40:31 -0000 Hi, At this moment I have problems installing FreeBSD 6.4 and FreeBSD 7.0. After booting from CD the system I get the menu. I have tried all = possible options. The system starts checking all hardware but freezes after finding the = CD-ROM drives printing the GEOM_LABLE (on FB 7.0, not 6.4) (acd0) The hardware is a Targa Visonary 2700XP, AMD 2700+ CPU, mem 1 GB Can anyone help me. I never had this problems before on other systems. Thanks=20 Jack From owner-freebsd-stable@FreeBSD.ORG Tue Dec 23 19:07:26 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC1A31065674 for ; Tue, 23 Dec 2008 19:07:26 +0000 (UTC) (envelope-from admin@stardothosting.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by mx1.freebsd.org (Postfix) with ESMTP id 8AABA8FC42 for ; Tue, 23 Dec 2008 19:07:26 +0000 (UTC) (envelope-from admin@stardothosting.com) Received: by yw-out-2324.google.com with SMTP id 9so1665527ywe.13 for ; Tue, 23 Dec 2008 11:07:25 -0800 (PST) Received: by 10.64.251.17 with SMTP id y17mr6226086qbh.9.1230059245001; Tue, 23 Dec 2008 11:07:25 -0800 (PST) Received: from kevin (not.enough.unixsluts.com [76.10.166.187]) by mx.google.com with ESMTPS id 27sm16505584qbw.20.2008.12.23.11.07.23 (version=SSLv3 cipher=RC4-MD5); Tue, 23 Dec 2008 11:07:24 -0800 (PST) From: "SDH Admin" To: "'freebsd-stable'" , References: In-Reply-To: Date: Tue, 23 Dec 2008 14:07:02 -0500 Message-ID: <00fb01c96531$a5fca290$f1f5e7b0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcllLgQxFreWSUS7RVafMEWXj0zbKAAA3LOQ Content-Language: en-us x-cr-hashedpuzzle: ZP0= CRf8 DL2n DvQ/ D69Z FRkn He49 LL7E NG2r Rlha T5FL T74G UWbQ Ub87 VCNE WJ/J; 2; ZgByAGUAZQBiAHMAZAAtAHEAdQBlAHMAdABpAG8AbgBzAEAAZgByAGUAZQBiAHMAZAAuAG8AcgBnADsAZgByAGUAZQBiAHMAZAAtAHMAdABhAGIAbABlAEAAZgByAGUAZQBiAHMAZAAuAG8AcgBnAA==; Sosha1_v1; 7; {6E70CE90-3DB4-4F2A-9D03-4F925082083B}; YQBkAG0AaQBuAEAAcwB0AGEAcgBkAG8AdABoAG8AcwB0AGkAbgBnAC4AYwBvAG0A; Tue, 23 Dec 2008 19:06:55 GMT; UgBFADoAIABQAHIAbwBiAGwAZQBtAHMAIABpAG4AcwB0AGEAbABsAGkAbgBnACAARgByAGUAZQBCAFMARAAgADcALgAwAA== x-cr-puzzleid: {6E70CE90-3DB4-4F2A-9D03-4F925082083B} Cc: Subject: RE: Problems installing FreeBSD 7.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2008 19:07:27 -0000 > The system starts checking all hardware but freezes after finding the > CD-ROM drives printing the GEOM_LABLE (on FB 7.0, not 6.4) > (acd0) > > The hardware is a Targa Visonary 2700XP, AMD 2700+ CPU, mem 1 GB Can you try to paste exactly what was on the screen before the "freeze" for both 6.4 and 7.0? Thanks. --- Kevin K. Systems Administrator www.stardothosting.com From owner-freebsd-stable@FreeBSD.ORG Tue Dec 23 19:09:17 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FB231065686 for ; Tue, 23 Dec 2008 19:09:17 +0000 (UTC) (envelope-from minimarmot@gmail.com) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.186]) by mx1.freebsd.org (Postfix) with ESMTP id DFE428FC2F for ; Tue, 23 Dec 2008 19:09:16 +0000 (UTC) (envelope-from minimarmot@gmail.com) Received: by rn-out-0910.google.com with SMTP id j71so2110704rne.12 for ; Tue, 23 Dec 2008 11:09:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=sXbu1Z1nocGQNKQiZMffbTuieLMzv3NZfh75OPL1CqI=; b=fgHhbbbFUKeoP4OCZ6EFp+wRxBsAiT+J0kiL7bTErZzcVc6jg9S9RFn1JfwzWkbW2S jFfJHhwIZtFg6BC3Okh9Cla/4g67iiMlIJsIQZ3DN0ayzhydjcOa/aaomN4o/Sqap/1C wBQFKT28PgE86wyNDdaLgcQpRMMRQCT4Gao/k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=O/quRjF0wGMyPxi71eoOpUwTAg+YsymetZZeoc8+zfcfpDF4S0NdMNEzOPoaJhe1LE Ef9wDisgXBQRermMZQ3FEFVuOgs+s4lBGSVRVvUYUT5o3NWRl3SbegwPdC8dGz8M7Q+U /j6NcJIws8iNA0LM8BC4ZZD5E5+pJBgmxsuCw= Received: by 10.142.214.11 with SMTP id m11mr3265570wfg.57.1230057958893; Tue, 23 Dec 2008 10:45:58 -0800 (PST) Received: by 10.143.100.5 with HTTP; Tue, 23 Dec 2008 10:45:58 -0800 (PST) Message-ID: <47d0403c0812231045o49cf05fv5999f32d1061a8a9@mail.gmail.com> Date: Tue, 23 Dec 2008 13:45:58 -0500 From: "Ben Kaduk" To: "Jack Raats" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: freebsd-stable Subject: Re: Problems installing FreeBSD 7.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2008 19:09:17 -0000 On Tue, Dec 23, 2008 at 1:30 PM, Jack Raats wrote: > Hi, > > At this moment I have problems installing FreeBSD 6.4 and FreeBSD 7.0. > After booting from CD the system I get the menu. I have tried all possible options. > The system starts checking all hardware but freezes after finding the CD-ROM drives printing the GEOM_LABLE (on FB 7.0, not 6.4) > (acd0) > > The hardware is a Targa Visonary 2700XP, AMD 2700+ CPU, mem 1 GB > > Can anyone help me. I never had this problems before on other systems. > Have you tried booting in verbose mode? If so, does it give any further output after printing the GEOM_LABEL for the other drives? -Ben Kaduk From owner-freebsd-stable@FreeBSD.ORG Tue Dec 23 19:19:52 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F610106574E for ; Tue, 23 Dec 2008 19:19:52 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: from mail-bw0-f19.google.com (mail-bw0-f19.google.com [209.85.218.19]) by mx1.freebsd.org (Postfix) with ESMTP id 86C7A8FC1A for ; Tue, 23 Dec 2008 19:19:51 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: by bwz12 with SMTP id 12so7649320bwz.19 for ; Tue, 23 Dec 2008 11:19:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=2NcqeaKvXTwUuIqbkuQjbzFMnfb8Qcl1Ul3Q0dZm/yw=; b=FZig8xpYz/QDFt5PCL5gt3tnshuE1mkP8cwmxT36LFI/Gur8L/Fr/Jf3i0XkjBau0N 3jjasRxCI4WSncVIPCzcDWhRAstsSfWkN7qzlq4jjKMFrQoCnTmuSG5NiU0fuUEtvEd9 xbxkigjoIzPWJK/LYqI2a4sotERhdDlkJ6eUU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=t+rF+cR3Cy/9BChbdUwp29G5RhXaRZoso88RUXKCowkQt0t2KtwR+f2LEojWPzGIB/ wb6w7dfp0+MVXqGdJyaA0KqE+hxazUepZvcReCqEnmNHQ7kmETvoLTswczdMzei7ENtS rwtxxguBYc8MmOf7tLNQuFWYI1bXFiMKT+7L0= Received: by 10.103.138.16 with SMTP id q16mr2881999mun.7.1230058571941; Tue, 23 Dec 2008 10:56:11 -0800 (PST) Received: by 10.103.91.11 with HTTP; Tue, 23 Dec 2008 10:56:11 -0800 (PST) Message-ID: <4ad871310812231056m72fd7d02sb67ac2bb168e1a6a@mail.gmail.com> Date: Tue, 23 Dec 2008 13:56:11 -0500 From: "Glen Barber" To: "Jack Raats" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: freebsd-stable , freebsd-questions@freebsd.org Subject: Re: Problems installing FreeBSD 7.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2008 19:19:52 -0000 On Tue, Dec 23, 2008 at 1:30 PM, Jack Raats wrote: > Hi, > > At this moment I have problems installing FreeBSD 6.4 and FreeBSD 7.0. > After booting from CD the system I get the menu. I have tried all possible options. > The system starts checking all hardware but freezes after finding the CD-ROM drives printing the GEOM_LABLE (on FB 7.0, not 6.4) > (acd0) > > The hardware is a Targa Visonary 2700XP, AMD 2700+ CPU, mem 1 GB > > Can anyone help me. I never had this problems before on other systems. > Have you tried disabling DMA or ACPI? hw.ata.ata_dma=0 -- Glen Barber From owner-freebsd-stable@FreeBSD.ORG Tue Dec 23 19:29:33 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D9F7106564A for ; Tue, 23 Dec 2008 19:29:33 +0000 (UTC) (envelope-from jack@jarasoft.net) Received: from raats.xs4all.nl (raats.xs4all.nl [82.95.230.43]) by mx1.freebsd.org (Postfix) with ESMTP id 157698FC1B for ; Tue, 23 Dec 2008 19:29:32 +0000 (UTC) (envelope-from jack@jarasoft.net) Received: from raats.xs4all.nl (localhost.jarasoft.net [127.0.0.1]) by raats.xs4all.nl (Postfix) with ESMTP id 6541D22B26; Tue, 23 Dec 2008 20:29:32 +0100 (CET) Received: from jara3 (unknown [10.10.10.20]) by raats.xs4all.nl (Postfix) with ESMTPA id 2556E2285E; Tue, 23 Dec 2008 20:29:32 +0100 (CET) Message-ID: <393E3A07623E4BB2847B00C34F500C60@jarasoft.net> From: "Jack Raats" To: "Ben Kaduk" References: <47d0403c0812231045o49cf05fv5999f32d1061a8a9@mail.gmail.com> Date: Tue, 23 Dec 2008 20:29:31 +0100 Organization: JaRaSoft, Steenbergen, Nederland MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Relayed-By: GPGrelay Version 0.959 (Win32) X-Virus-Scanned: ClamAV using ClamSMTP on orac.jarasoft.net Cc: freebsd-stable Subject: Re: Problems installing FreeBSD 7.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jack Raats List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2008 19:29:33 -0000 From: "Ben Kaduk" > On Tue, Dec 23, 2008 at 1:30 PM, Jack Raats wrote: >> Hi, >> >> At this moment I have problems installing FreeBSD 6.4 and FreeBSD 7.0. >> After booting from CD the system I get the menu. I have tried all >> possible options. >> The system starts checking all hardware but freezes after finding the >> CD-ROM drives printing the GEOM_LABLE (on FB 7.0, not 6.4) >> (acd0) >> >> The hardware is a Targa Visonary 2700XP, AMD 2700+ CPU, mem 1 GB >> >> Can anyone help me. I never had this problems before on other systems. >> > > > Have you tried booting in verbose mode? > If so, does it give any further output after printing the GEOM_LABEL for > the other drives? Verbose mode does not give much more information. It tells the info of the CD rom drives, after which it stops. Strange thing is that installing ubuntu doesn't give any trouble. Checking the hardware doesn't give any failures. Memory is OK. Thanks for your time Jack From owner-freebsd-stable@FreeBSD.ORG Tue Dec 23 19:32:40 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3998C106567D; Tue, 23 Dec 2008 19:32:40 +0000 (UTC) (envelope-from jack@jarasoft.net) Received: from raats.xs4all.nl (raats.xs4all.nl [82.95.230.43]) by mx1.freebsd.org (Postfix) with ESMTP id E5F7A8FC19; Tue, 23 Dec 2008 19:32:39 +0000 (UTC) (envelope-from jack@jarasoft.net) Received: from raats.xs4all.nl (localhost.jarasoft.net [127.0.0.1]) by raats.xs4all.nl (Postfix) with ESMTP id 703E822B26; Tue, 23 Dec 2008 20:32:39 +0100 (CET) Received: from jara3 (unknown [10.10.10.20]) by raats.xs4all.nl (Postfix) with ESMTPA id 3A5E42285E; Tue, 23 Dec 2008 20:32:39 +0100 (CET) Message-ID: From: "Jack Raats" To: "SDH Admin" , "'freebsd-stable'" , References: <00fb01c96531$a5fca290$f1f5e7b0$@com> Date: Tue, 23 Dec 2008 20:32:38 +0100 Organization: JaRaSoft, Steenbergen, Nederland MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Relayed-By: GPGrelay Version 0.959 (Win32) X-Virus-Scanned: ClamAV using ClamSMTP on orac.jarasoft.net Cc: Subject: Re: Problems installing FreeBSD 7.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jack Raats List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2008 19:32:40 -0000 ----- Original Message ----- From: "SDH Admin" >> The system starts checking all hardware but freezes after finding the >> CD-ROM drives printing the GEOM_LABLE (on FB 7.0, not 6.4) >> (acd0) >> >> The hardware is a Targa Visonary 2700XP, AMD 2700+ CPU, mem 1 GB > > > Can you try to paste exactly what was on the screen before the "freeze" > for > both 6.4 and 7.0? How can I do this if the systeem freezes??? Jack From owner-freebsd-stable@FreeBSD.ORG Tue Dec 23 19:34:51 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C42EF1065753; Tue, 23 Dec 2008 19:34:51 +0000 (UTC) (envelope-from admin@stardothosting.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id 620668FC1A; Tue, 23 Dec 2008 19:34:51 +0000 (UTC) (envelope-from admin@stardothosting.com) Received: by yx-out-2324.google.com with SMTP id 8so1671801yxb.13 for ; Tue, 23 Dec 2008 11:34:50 -0800 (PST) Received: by 10.65.75.2 with SMTP id c2mr6234092qbl.12.1230060889754; Tue, 23 Dec 2008 11:34:49 -0800 (PST) Received: from kevin (not.enough.unixsluts.com [76.10.166.187]) by mx.google.com with ESMTPS id s35sm17617951qbs.13.2008.12.23.11.34.48 (version=SSLv3 cipher=RC4-MD5); Tue, 23 Dec 2008 11:34:49 -0800 (PST) From: "SDH Admin" To: "'freebsd-stable'" , References: <00fb01c96531$a5fca290$f1f5e7b0$@com> In-Reply-To: Date: Tue, 23 Dec 2008 14:34:28 -0500 Message-ID: <010101c96535$7a4e6580$6eeb3080$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcllNTj0IkPABzkWRWKToE93fTp1IwAACgbA Content-Language: en-us Cc: Subject: RE: Problems installing FreeBSD 7.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2008 19:34:51 -0000 > How can I do this if the systeem freezes??? Good old fashioned pen + paper (as long as it's not too long). Never fails. --- Kevin K. Systems Administrator www.stardothosting.com From owner-freebsd-stable@FreeBSD.ORG Tue Dec 23 21:08:09 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D22E106564A; Tue, 23 Dec 2008 21:08:09 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by mx1.freebsd.org (Postfix) with ESMTP id CF26E8FC13; Tue, 23 Dec 2008 21:08:03 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so1683242ywe.13 for ; Tue, 23 Dec 2008 13:08:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:cc; bh=uKl+NIj4yIkn68rnT6Cr97cxIWr3Ux7B0VUylQlM4lw=; b=gL3KHxrKxtR0XJ7ZAfbQp+3tfYB5GEz2WRdbkeZAw/EhqoIEv6aKpUVoR7+FjfifFO wuy+MNphe7ug+W8GhnQ/u1Dy1zD/zh8Z5vkzk/Wpm3lGZlMEDJesF0I0frB+XwJqRdpH 95MOdKAVNS95tM0ieVAm+PSWSM1xeJIyxpClQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=RDBvVD8nSK+F23O235J918rLcnBBn76jIKORuaFmoUkb2r5x7N9oc8W5YZI4QFhONY 99wAKt0ZlCUMFey5rPuWUpc0cfWIA0OYptoFLn4hgcfzYgFNh923zAJOoLf92KjMapAX p8HZ/kFcmnTMHIB1mr9b5T1BMNAgDKOrb3cwo= Received: by 10.100.124.6 with SMTP id w6mr4912635anc.30.1230066482997; Tue, 23 Dec 2008 13:08:02 -0800 (PST) Received: from ?10.90.43.74? ([32.157.137.217]) by mx.google.com with ESMTPS id b14sm13363828ana.32.2008.12.23.13.07.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 23 Dec 2008 13:08:02 -0800 (PST) References: <7d6fde3d0812222135l753daf54geb37b696c9c1cf8@mail.gmail.com> <20081223173608.068fe9d8@suszko.eu> <8cb6106e0812230955u1bd16932h7ae4ad3fc8c97f28@mail.gmail.com> <20081223183649.GA90840@troutmask.apl.washington.edu> Message-Id: From: Garrett Cooper To: Steve Kargl In-Reply-To: <20081223183649.GA90840@troutmask.apl.washington.edu> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (5F136) Mime-Version: 1.0 (iPhone Mail 5F136) Date: Tue, 23 Dec 2008 13:07:38 -0800 Cc: Josh Carroll , "amd64@freebsd.org" , stable , Maciej Suszko Subject: Re: -m32 broken on bi-arch amd64 systems? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2008 21:08:09 -0000 On Dec 23, 2008, at 10:36, Steve Kargl wrote: > On Tue, Dec 23, 2008 at 12:55:04PM -0500, Josh Carroll wrote: >>> I also noticed that behavior, shouldn't compiler/linker look >>> into /usr/lib32 without additional -B switch? >>> -- >>> regards, Maciej Suszko. >>> >> >> I don't know if it should or should not, but I can confirm that this >> behavior was around in 7.0-RELEASE, so it's been that way for quite a >> while, at least in the 7 branch. >> > > Sigh. Read the list archives. It's been this way since Peter > Wemm first introduce the ability to run i386 binaries on > amd64. > > -- > Steve Ok, let's bury this topic then. Thanks for the confirmation and sorry for the noise. -Garrett From owner-freebsd-stable@FreeBSD.ORG Wed Dec 24 00:19:15 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 565F8106564A for ; Wed, 24 Dec 2008 00:19:15 +0000 (UTC) (envelope-from peter@wemm.org) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by mx1.freebsd.org (Postfix) with ESMTP id 318758FC19 for ; Wed, 24 Dec 2008 00:19:15 +0000 (UTC) (envelope-from peter@wemm.org) Received: by wf-out-1314.google.com with SMTP id 24so4505453wfg.7 for ; Tue, 23 Dec 2008 16:19:14 -0800 (PST) Received: by 10.142.222.21 with SMTP id u21mr3353575wfg.84.1230076463772; Tue, 23 Dec 2008 15:54:23 -0800 (PST) Received: by 10.142.255.21 with HTTP; Tue, 23 Dec 2008 15:54:23 -0800 (PST) Message-ID: Date: Tue, 23 Dec 2008 15:54:23 -0800 From: "Peter Wemm" To: "Garrett Cooper" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7d6fde3d0812222135l753daf54geb37b696c9c1cf8@mail.gmail.com> <20081223173608.068fe9d8@suszko.eu> <8cb6106e0812230955u1bd16932h7ae4ad3fc8c97f28@mail.gmail.com> <20081223183649.GA90840@troutmask.apl.washington.edu> Cc: Josh Carroll , "amd64@freebsd.org" , stable , Maciej Suszko , Steve Kargl Subject: Re: -m32 broken on bi-arch amd64 systems? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2008 00:19:15 -0000 On Tue, Dec 23, 2008 at 1:07 PM, Garrett Cooper wrote: > On Dec 23, 2008, at 10:36, Steve Kargl > wrote: > >> On Tue, Dec 23, 2008 at 12:55:04PM -0500, Josh Carroll wrote: >>>> >>>> I also noticed that behavior, shouldn't compiler/linker look >>>> into /usr/lib32 without additional -B switch? >>>> -- >>>> regards, Maciej Suszko. >>>> >>> >>> I don't know if it should or should not, but I can confirm that this >>> behavior was around in 7.0-RELEASE, so it's been that way for quite a >>> while, at least in the 7 branch. >>> >> >> Sigh. Read the list archives. It's been this way since Peter >> Wemm first introduce the ability to run i386 binaries on >> amd64. >> >> -- >> Steve > > Ok, let's bury this topic then. > Thanks for the confirmation and sorry for the noise. > -Garrett A patch can be extraced from http://people.freebsd.org/~peter/hammer.diff that makes it "work", but its not right. It doesn't quite do -I include overrides right when -m32 is specified. It's enough to make just about everything else work. I forgot that I was building valgrind with it for some time now. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-stable@FreeBSD.ORG Wed Dec 24 03:25:36 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D7741065675 for ; Wed, 24 Dec 2008 03:25:36 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 8D5678FC12 for ; Wed, 24 Dec 2008 03:25:36 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id CC5FC1A3C3B; Tue, 23 Dec 2008 19:07:30 -0800 (PST) Date: Tue, 23 Dec 2008 19:07:30 -0800 From: Alfred Perlstein To: Lin Jui-Nan Eric Message-ID: <20081224030730.GY18389@elvis.mu.org> References: <47713ee10812230915o7ea8fd1dge1ae7352694cb961@mail.gmail.com> <47713ee10812230917u506d8ee1ta9e93c8ef25e86e3@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47713ee10812230917u506d8ee1ta9e93c8ef25e86e3@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: stable@freebsd.org Subject: Re: Process stuck in STOP state X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2008 03:25:36 -0000 * Lin Jui-Nan Eric [081223 09:17] wrote: > > Dear listers, > > > > Our FreeBSD Server uses NFS to access PHP files on NetApp, then serve > > them with apache 2.2 (worker MPM + php fastcgi mode). > Sorry. we use -STABLE now. > > event# uname -a > FreeBSD event 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #1: Thu Dec 4 > 01:45:42 CST 2008 root@event:/usr/obj/usr/src/sys/KERNEL amd64 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" It'd be good if you could get to ddb and do a "show all" or "threads" and get all threads backtrace to see what's happening. thank you, -- - Alfred Perlstein From owner-freebsd-stable@FreeBSD.ORG Wed Dec 24 12:23:44 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6CAD1065675 for ; Wed, 24 Dec 2008 12:23:44 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-gx0-f19.google.com (mail-gx0-f19.google.com [209.85.217.19]) by mx1.freebsd.org (Postfix) with ESMTP id 926C88FC18 for ; Wed, 24 Dec 2008 12:23:39 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by gxk12 with SMTP id 12so1987058gxk.19 for ; Wed, 24 Dec 2008 04:23:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=hDso6hzq7y83RZGgFapydtVcLcg1FGqMyPOAcHYobCM=; b=BCorExH3tzfaUzzH/kQhZ4rb1EC5KhfOwM8HTe7IXFtp2kiNa0l3/U5KvABOu7Pavp N7Td2mGtMsvfbeNnodf1Yetx2+/DGc2rdzI1sMwMjL4Bd/x6lFr0bROqlGV8GP1mzId1 U+kRri79f51NyXF8wBh3NLwYsUVhDO/eEav4I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=foqsqme6ZIqqu8/eATUQemkDCiDpCL5wqFq0isAnMjBFEuqvmrqH+nLAJ5FuKVA/8k 2z95QlMPiDP46tvnuItaHS1z2mwjsNAVV4LEqtquKReYDztwTEjdtj9QRv5KMe3IYrja mAKDYYltC+SCpAODvJa66jaMzzHJC+Ae8MjY0= Received: by 10.90.71.15 with SMTP id t15mr4441190aga.90.1230121418515; Wed, 24 Dec 2008 04:23:38 -0800 (PST) Received: by 10.90.26.18 with HTTP; Wed, 24 Dec 2008 04:23:38 -0800 (PST) Message-ID: Date: Wed, 24 Dec 2008 15:23:38 +0300 From: pluknet To: "FreeBSD Stable Mailing List" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: process stuck in vmopar X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2008 12:23:44 -0000 Server version: Apache/2.2.11 (Unix) built from sources. After issuing kill -9 process stuck in vmopar state forever. aaa301 2313 0.0 0.0 0 8 ?? DE 3:10PM 0:00.01 /home/aaa301/myb vmopar System: FreeBSD 6.2 i386. Any hints? -- wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Wed Dec 24 13:54:41 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB62B1065673 for ; Wed, 24 Dec 2008 13:54:41 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by mx1.freebsd.org (Postfix) with ESMTP id 983C98FC17 for ; Wed, 24 Dec 2008 13:54:41 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so1784037yxb.13 for ; Wed, 24 Dec 2008 05:54:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=4FeU4Il3HxztFqVK1EIZ0jbxingAM8KIA4R/Liis+xU=; b=xML3hwBvOCEB/mDXyd/L4eVw3LWPa3IQYM7r337FRKlq68OhZ4KqsiB3fhvk0szU5Z VtQMkexe/k2TZwb/0cdVsXObFPPcvKlv25RbPIDDi5nAwiIZDRn1bT1/n6YCxSWQ8Nr3 tMfW1h850gcrLnoUEfl//HX9br/M0GqBiDOLU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Dk6Xoa03KlCDb914Lu3Itko4tsdvQlvu4XWqiffa9tFb/PKm79+4LvyjBlS3UcVS81 9r+cphyVYi0FmnP72HIwXUudrmBfFdyxkugoXbmRbE9hnS2w2s/IzeTNd7MER40d1uP9 ldzOaDdwH2zy8Od+X0Jx5ii/0qER6DZ8AFdak= Received: by 10.90.35.9 with SMTP id i9mr4357953agi.35.1230126881048; Wed, 24 Dec 2008 05:54:41 -0800 (PST) Received: by 10.90.26.18 with HTTP; Wed, 24 Dec 2008 05:54:40 -0800 (PST) Message-ID: Date: Wed, 24 Dec 2008 16:54:40 +0300 From: pluknet To: "FreeBSD Stable Mailing List" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Subject: Re: process stuck in vmopar X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2008 13:54:41 -0000 2008/12/24 pluknet : > Server version: Apache/2.2.11 (Unix) built from sources. > > After issuing kill -9 process stuck in vmopar state forever. > aaa301 2313 0.0 0.0 0 8 ?? DE 3:10PM 0:00.01 > /home/aaa301/myb vmopar > > System: FreeBSD 6.2 i386. > One important note. Kernel is built with options QUOTA, and this problem triggered only when this user is overquoted (usage > quota and limit). > Any hints? > -- wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Wed Dec 24 14:17:24 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6B28106568E for ; Wed, 24 Dec 2008 14:17:24 +0000 (UTC) (envelope-from 0ld@ukr.net) Received: from infocom.km.ua (infocom.km.ua [78.152.160.1]) by mx1.freebsd.org (Postfix) with ESMTP id 2EE188FC20 for ; Wed, 24 Dec 2008 14:17:23 +0000 (UTC) (envelope-from 0ld@ukr.net) Received: from old.ic (dog.infocom.km.ua [78.152.160.4]) by infocom.km.ua (8.14.2/8.14.2/ic) with ESMTP id mBODaA91038254 for ; Wed, 24 Dec 2008 15:36:16 +0200 (EET) (envelope-from 0ld@ukr.net) From: Alexander Melnik <0ld@ukr.net> To: "FreeBSD Stable Mailing List" Date: Wed, 24 Dec 2008 15:36:10 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812241536.10563.0ld@ukr.net> Subject: can't disable hyperthreading on 7.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2008 14:17:25 -0000 Hi I have several computers with 2 xeon processors with hyperthreading under FreeBSD 7.1-RC2 and in any case can not turn off hyperthreading: [old@vmat ~]$ cat /boot/loader.conf machdep.hyperthreading_allowed="0" machdep.hlt_logical_cpus="1" [old@vmat ~]$ sysctl machdep.hyperthreading_allowed machdep.hyperthreading_allowed: 0 [old@vmat ~]$ sysctl machdep.hlt_logical_cpus machdep.hlt_logical_cpus: 1 [old@vmat ~]$ sysctl hw.ncpu hw.ncpu: 4 If machdep.hyperthreading_allowed = "0", the hw.ncpu must be equal to 2? [old@vmat ~]$ top -nd 1 last pid: 825; load averages: 0.00, 0.00, 0.00 up 0+00:21:19 15:22:24 17 processes: 1 running, 16 sleeping Mem: 6228K Active, 6984K Inact, 20M Wired, 9520K Buf, 960M Free Swap: 2048M Total, 2048M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 762 root 1 4 0 8428K 3936K sbwait 2 0:00 0.00% sshd 767 old 1 8 0 4396K 2212K wait 2 0:00 0.00% bash 765 old 1 44 0 8428K 3952K select 0 0:00 0.00% sshd 571 root 1 44 0 3184K 1200K select 1 0:00 0.00% syslogd 706 root 1 44 0 5876K 3196K select 0 0:00 0.00% sendmail 716 root 1 8 0 3212K 1276K nanslp 2 0:00 0.00% cron 759 root 1 5 0 3184K 1088K ttyin 2 0:00 0.00% getty 758 root 1 5 0 3184K 1088K ttyin 3 0:00 0.00% getty 760 root 1 5 0 3184K 1088K ttyin 0 0:00 0.00% getty 700 root 1 44 0 5752K 3276K select 0 0:00 0.00% sshd 710 smmsp 1 20 0 5876K 3200K pause 2 0:00 0.00% sendmail 297 root 1 96 0 3128K 1208K select 0 0:00 0.00% dhclient 737 root 1 96 0 3240K 1152K select 3 0:00 0.00% inetd 163 root 1 20 0 1380K 804K pause 0 0:00 0.00% adjkerntz 512 root 1 44 0 1888K 564K select 0 0:00 0.00% devd 313 _dhcp 1 44 0 3128K 1320K select 0 0:00 0.00% dhclient 825 old 1 44 0 3496K 1656K CPU0 0 0:00 0.00% top If machdep.hlt_logical_cpus = "1" in the output top in any case should not be seen processors 2 and 3? [old@vmat ~]$ uname -a FreeBSD vmat.ic 7.1-RC2 FreeBSD 7.1-RC2 #0: Wed Dec 24 13:54:22 EET 2008 root@vmat.ic:/usr/obj/usr/src/sys/GENERIC i386 [old@vmat ~]$ dmesg 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.1-RC2 #0: Wed Dec 24 13:54:22 EET 2008 root@vmat.ic:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2793.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf43 Stepping = 3 Features=0xbfebfbff Features2=0x641d AMD Features=0x20100000 Logical CPUs per core: 2 real memory = 1073479680 (1023 MB) avail memory = 1036804096 (988 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 6 cpu3 (AP): APIC ID: 7 ioapic0: Changing APIC ID to 8 ioapic1: Changing APIC ID to 9 ioapic2: Changing APIC ID to 10 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 32-55 on motherboard ioapic2 irqs 64-87 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: at device 0.0 on pci1 pci2: on pcib2 mpt0: port 0xec00-0xecff mem 0xfe9f0000-0xfe9fffff,0xfe9e0000-0xfe9effff irq 42 at device 4.0 on pci2 mpt0: [ITHREAD] mpt0: MPI Version=1.2.12.0 amr0: mem 0xf80f0000-0xf80fffff irq 32 at device 6.0 on pci2 amr0: [ITHREAD] amr0: delete logical drives supported by controller amr0: Firmware 352D, BIOS 1.10, 64MB RAM pcib3: at device 0.2 on pci1 pci3: on pcib3 em0: port 0xdcc0-0xdcff mem 0xfe7e0000-0xfe7fffff irq 69 at device 7.0 on pci3 em0: [FILTER] em0: Ethernet address: 00:14:22:75:5a:54 pcib4: at device 4.0 on pci0 pci4: on pcib4 pcib5: at device 6.0 on pci0 pci5: on pcib5 uhci0: port 0xbce0-0xbcff irq 16 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xbcc0-0xbcdf irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xbca0-0xbcbf irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xfeb00000-0xfeb003ff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered pcib6: at device 30.0 on pci0 pci6: on pcib6 pci6: at device 3.0 (no driver attached) vgapci0: port 0xc800-0xc8ff mem 0xf0000000-0xf7ffffff,0xfe3f0000-0xfe3fffff irq 17 at device 5.0 on pci6 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] cpu0: on acpi0 p4tcc0: on cpu0 cpu1: on acpi0 p4tcc1: on cpu1 cpu2: on acpi0 p4tcc2: on cpu2 cpu3: on acpi0 p4tcc3: on cpu3 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcafff,0xcb000-0xcb7ff,0xec000-0xeffff pnpid ORM0000 on isa0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 ppbus0: [ITHREAD] plip0: on ppbus0 plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec acd0: CDRW at ata0-master UDMA33 Waiting 5 seconds for SCSI devices to settle amr0: delete logical drives supported by controller amrd0: on amr0 amrd0: 69360MB (142049280 sectors) RAID 5 (optimal) ses0 at amr0 bus 0 target 6 lun 0 ses0: Fixed Processor SCSI-2 device ses0: 166.664MB/s transfers (41.666MHz, offset 31, 32bit) ses0: SAF-TE Compliant Device SMP: AP CPU #2 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! Trying to mount root from ufs:/dev/amrd0s1a Sorry for my bad English. -- Bye! A.M. From owner-freebsd-stable@FreeBSD.ORG Wed Dec 24 15:24:40 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 342981065677 for ; Wed, 24 Dec 2008 15:24:40 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by mx1.freebsd.org (Postfix) with ESMTP id DF6078FC14 for ; Wed, 24 Dec 2008 15:24:39 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so1794778yxb.13 for ; Wed, 24 Dec 2008 07:24:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=0LuTQrlj4FIcepOHfPrfA7r/quaWXIOGcuJ0TavKIbM=; b=wEdi8R/+u4QdNAUUKezstr/TjM9wFoq4T7ZM7ZhzGjpGT91fmrPC4zIP4YO1/WAKjp YdJsZrJ4liJvpG5vssqDpGhxodekcRFJCweNL0ELfvnk+PrvGUbk3Z4afNzwmxyCV2py g7kNMLiJ+BTivdjYBetF1vflMAotkQWDZK40s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Y2ukCuf++SFZECgs+NVHWgocExlpRc04U9JJpvCJ11SrVPpmqc9REa25cHLX9FG42m op3zxlxq4k9I4ZkgjB53b+9W0A912dr9LN4yc0PwPhHWoXlqPP92ZH0MozBJ5TOJkxqj 0ES0vf++OK+51MNw1hSY4ulRtRnc7dI6x+sqc= Received: by 10.90.79.17 with SMTP id c17mr1000028agb.33.1230132278904; Wed, 24 Dec 2008 07:24:38 -0800 (PST) Received: by 10.90.26.18 with HTTP; Wed, 24 Dec 2008 07:24:38 -0800 (PST) Message-ID: Date: Wed, 24 Dec 2008 18:24:38 +0300 From: pluknet To: "FreeBSD Stable Mailing List" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Subject: Re: process stuck in vmopar X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2008 15:24:40 -0000 2008/12/24 pluknet : > 2008/12/24 pluknet : >> Server version: Apache/2.2.11 (Unix) built from sources. >> >> After issuing kill -9 process stuck in vmopar state forever. >> aaa301 2313 0.0 0.0 0 8 ?? DE 3:10PM 0:00.01 >> /home/aaa301/myb vmopar >> >> System: FreeBSD 6.2 i386. >> > > One important note. > Kernel is built with options QUOTA, and this problem triggered > only when this user is overquoted (usage > quota and limit). A bit later various processes begin to stuck in "ufs" state. > >> Any hints? >> -- wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Wed Dec 24 16:29:07 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7E641065677; Wed, 24 Dec 2008 16:29:07 +0000 (UTC) (envelope-from jack@jarasoft.net) Received: from raats.xs4all.nl (raats.xs4all.nl [82.95.230.43]) by mx1.freebsd.org (Postfix) with ESMTP id 8EDB88FC08; Wed, 24 Dec 2008 16:29:07 +0000 (UTC) (envelope-from jack@jarasoft.net) Received: from raats.xs4all.nl (localhost.jarasoft.net [127.0.0.1]) by raats.xs4all.nl (Postfix) with ESMTP id 1630523698; Wed, 24 Dec 2008 17:29:09 +0100 (CET) Received: from jara3 (unknown [10.10.10.20]) by raats.xs4all.nl (Postfix) with ESMTPA id B5E2A22983; Wed, 24 Dec 2008 17:29:08 +0100 (CET) Message-ID: <5CA7438D59284A97BB5B4BB36FECCD82@jarasoft.net> From: "Jack Raats" To: "'freebsd-stable'" , References: <00fb01c96531$a5fca290$f1f5e7b0$@com> <010101c96535$7a4e6580$6eeb3080$@com> Date: Wed, 24 Dec 2008 17:29:05 +0100 Organization: JaRaSoft, Steenbergen, Nederland MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Relayed-By: GPGrelay Version 0.959 (Win32) X-Virus-Scanned: ClamAV using ClamSMTP on orac.jarasoft.net Cc: Subject: Re: Problems installing FreeBSD 7.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jack Raats List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2008 16:29:07 -0000 From: "SDH Admin" >> How can I do this if the systeem freezes??? > > Good old fashioned pen + paper (as long as it's not too long). Never > fails. Main problem is: ad0: FreeBSD check1 failed I googled but didn't find any solution. Does anyone have a clue where to find the solution? Jack From owner-freebsd-stable@FreeBSD.ORG Wed Dec 24 17:12:42 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51E89106564A for ; Wed, 24 Dec 2008 17:12:42 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-gx0-f19.google.com (mail-gx0-f19.google.com [209.85.217.19]) by mx1.freebsd.org (Postfix) with ESMTP id E95118FC13 for ; Wed, 24 Dec 2008 17:12:41 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by gxk12 with SMTP id 12so2069575gxk.19 for ; Wed, 24 Dec 2008 09:12:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=/ZqVj1ytpiiS0BXlytiZz7RgAzZM9e9xik9ZjbXHsjM=; b=yDnRw2UvTmd7AJS5EqMPFX2gpvuBkbDcRa04qyTAeSzt8P3KzYoyBCF2kLVrSQpiN1 e2y5/m+R6nSufpGt1zVj819K6oewBu9RVjRT/q4t2N/RqRpYC4C8drX6TBUVFMnaeZyZ JzWj8OlAn1Y0QP/0Hhb3p3n+wC4/7ozI+6ZPM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=w3KkBeqYTLgaIYLs5OIjTTzDWd9oAaZoV0C6Mu9+qevST8abZfjyv5cxcrFhIKORiA zXhlzdOXe0+LudeBZWTZM2Q1n2UTQKxGyd3NnMGFWyTKop/Ka8MiS7uCYfPRlNMBxZUk 580axOqa7f4u3onRHpN4pGK6tL4lGRcnxhJI8= Received: by 10.90.120.19 with SMTP id s19mr4569678agc.17.1230138761124; Wed, 24 Dec 2008 09:12:41 -0800 (PST) Received: by 10.90.26.18 with HTTP; Wed, 24 Dec 2008 09:12:41 -0800 (PST) Message-ID: Date: Wed, 24 Dec 2008 20:12:41 +0300 From: pluknet To: "FreeBSD Stable Mailing List" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Subject: Re: process stuck in vmopar X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2008 17:12:42 -0000 2008/12/24 pluknet : > 2008/12/24 pluknet : >> 2008/12/24 pluknet : >>> Server version: Apache/2.2.11 (Unix) built from sources. >>> >>> After issuing kill -9 process stuck in vmopar state forever. >>> aaa301 2313 0.0 0.0 0 8 ?? DE 3:10PM 0:00.01 >>> /home/aaa301/myb vmopar >>> >>> System: FreeBSD 6.2 i386. >>> >> >> One important note. >> Kernel is built with options QUOTA, and this problem triggered >> only when this user is overquoted (usage > quota and limit). > > A bit later various processes begin to stuck in "ufs" state. backtrace of process that stucks in vmopar: db> bt 1385 Tracing pid 1385 tid 100181 td 0xc6c19960 sched_switch(c6c19960,0,1) at sched_switch+0x15b mi_switch(1,0) at mi_switch+0x270 sleepq_switch(c2954ec8,c0a3d0a0,0,c094c4eb,211,...) at sleepq_switch+0xc1 sleepq_wait(c2954ec8,0,c096897c,709,c096897c,...) at sleepq_wait+0x46 msleep(c2954ec8,c0ab8e80,244,c0968ca9,0,c9030444,0,c0968eb0,200,c2954ec8,82) at msleep+0x279 vm_page_sleep_if_busy(c2954ec8,1,c0968ca9) at vm_page_sleep_if_busy+0x7c vm_object_page_remove(c9030444,4,0,8000,0,0) at vm_object_page_remove+0xf9 vnode_pager_setsize(c903c000,4000,0) at vnode_pager_setsize+0xbd ffs_write(f734a78c) at ffs_write+0x264 VOP_WRITE_APV(c0a09b00,f734a78c) at VOP_WRITE_APV+0x112 vnode_pager_generic_putpages(c903c000,f734a8d0,9000,5,f734a860,...) at vnode_pag er_generic_putpages+0x1ef vop_stdputpages(f734a814) at vop_stdputpages+0x1a VOP_PUTPAGES_APV(c0a09b00,f734a814) at VOP_PUTPAGES_APV+0x8c vnode_pager_putpages(c9030444,f734a8d0,9,5,f734a860) at vnode_pager_putpages+0x7 e vm_pageout_flush(f734a8d0,9,5,0,0,...) at vm_pageout_flush+0x112 vm_object_page_collect_flush(c9030444,c29505a8,251,5,4a,...) at vm_object_page_c ollect_flush+0x2a0 vm_object_page_clean(c9030444,0,0,0,0,...) at vm_object_page_clean+0x184 vm_object_terminate(c9030444) at vm_object_terminate+0x60 vnode_destroy_vobject(c903c000,c6973500,f734aab8,c6c19960,0,...) at vnode_destro y_vobject+0x39 ufs_reclaim(f734aab8) at ufs_reclaim+0x46 VOP_RECLAIM_APV(c0a09b00,f734aab8) at VOP_RECLAIM_APV+0x7e vgonel(c903c000) at vgonel+0x12d vrecycle(c903c000,c6c19960) at vrecycle+0x38 ufs_inactive(f734ab40) at ufs_inactive+0x2af VOP_INACTIVE_APV(c0a09b00,f734ab40) at VOP_INACTIVE_APV+0x7e vinactive(c903c000,c6c19960) at vinactive+0x72 vrele(c903c000,c9030444,0,c096897c,1a2,...) at vrele+0x14a vm_object_vndeallocate(c9030444) at vm_object_vndeallocate+0xc0 vm_object_deallocate(c9030444,c9030444,0,c0968016,8e7) at vm_object_deallocate+0 xb3 vm_map_entry_delete(c722a000,c7194bf4,f734ac20,c081ca37,c722a000,...) at vm_map_ entry_delete+0x130 vm_map_delete(c722a000,0,bfc00000) at vm_map_delete+0x18f vmspace_exit(c6c19960,c0a4bde0,0,c09463ea,125,...) at vmspace_exit+0xd5 exit1(c6c19960,9,2831a4b4,c6c19960,c7234000,...) at exit1+0x496 sigexit(c6c19960,9,c7234aa8,0,c09499bc,...) at sigexit+0xdf postsig(9) at postsig+0x160 ast(f734ad38) at ast+0x35e doreti_ast() at doreti_ast+0x17 db> show alllock Process 1385 (httpd) thread 0xc6c19960 (100181) exclusive sx user map r = 0 (0xc722a044) locked @ /usr/src/sys_uvmem_uip.6.2_RELEASE/vm/vm_map.c:307 > >> >>> Any hints? >>> -- wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Wed Dec 24 20:57:13 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 601E31065674 for ; Wed, 24 Dec 2008 20:57:13 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail18.syd.optusnet.com.au (mail18.syd.optusnet.com.au [211.29.132.199]) by mx1.freebsd.org (Postfix) with ESMTP id E49878FC16 for ; Wed, 24 Dec 2008 20:57:12 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail18.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id mBOKv9LN026887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Dec 2008 07:57:10 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id mBOKv8K0020105; Thu, 25 Dec 2008 07:57:08 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id mBOKv8Qh020104; Thu, 25 Dec 2008 07:57:08 +1100 (EST) (envelope-from peter) Date: Thu, 25 Dec 2008 07:57:08 +1100 From: Peter Jeremy To: Jack Raats Message-ID: <20081224205708.GB1081@server.vk2pj.dyndns.org> References: <00fb01c96531$a5fca290$f1f5e7b0$@com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="z6Eq5LdranGa6ru8" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: 'freebsd-stable' , freebsd-questions@freebsd.org Subject: Re: Problems installing FreeBSD 7.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2008 20:57:13 -0000 --z6Eq5LdranGa6ru8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2008-Dec-23 20:32:38 +0100, Jack Raats wrote: >> Can you try to paste exactly what was on the screen before the "freeze"= =20 >> for >> both 6.4 and 7.0? > >How can I do this if the systeem freezes??? Take a photo and put it up somewhere (http://imagebin.ca/ if nowhere else). If scroll lock still works, you can take pictures of earlier output (and if caps/scroll/num lock don't work, that is a useful piece of information). --=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. --z6Eq5LdranGa6ru8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAklSoiMACgkQ/opHv/APuIfrKACgiOPGzS2mGwHjdF7tkdG28iQU kskAn3rRUZZq+EXOvI3CJD4PcSYsYybC =5Kss -----END PGP SIGNATURE----- --z6Eq5LdranGa6ru8-- From owner-freebsd-stable@FreeBSD.ORG Wed Dec 24 21:03:34 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67F221065674 for ; Wed, 24 Dec 2008 21:03:34 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail13.syd.optusnet.com.au (mail13.syd.optusnet.com.au [211.29.132.194]) by mx1.freebsd.org (Postfix) with ESMTP id D3B278FC1D for ; Wed, 24 Dec 2008 21:03:33 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail13.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id mBOL3Vrf011720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Dec 2008 08:03:32 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id mBOL3VjF020160; Thu, 25 Dec 2008 08:03:31 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id mBOL3VeR020159; Thu, 25 Dec 2008 08:03:31 +1100 (EST) (envelope-from peter) Date: Thu, 25 Dec 2008 08:03:31 +1100 From: Peter Jeremy To: Jack Raats Message-ID: <20081224210330.GC1081@server.vk2pj.dyndns.org> References: <010101c96535$7a4e6580$6eeb3080$@com> <5CA7438D59284A97BB5B4BB36FECCD82@jarasoft.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="L6iaP+gRLNZHKoI4" Content-Disposition: inline In-Reply-To: <5CA7438D59284A97BB5B4BB36FECCD82@jarasoft.net> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: 'freebsd-stable' , freebsd-questions@freebsd.org Subject: Re: Problems installing FreeBSD 7.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2008 21:03:34 -0000 --L6iaP+gRLNZHKoI4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2008-Dec-24 17:29:05 +0100, Jack Raats wrote: >Main problem is: >ad0: FreeBSD check1 failed This is produced when the ATA subsystem is trying to read RAID metadata off the disk and just means it failed to find any. It's not an error. Can you post more context please. --=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. --L6iaP+gRLNZHKoI4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAklSo6IACgkQ/opHv/APuIeDbACaAsNY2N7lP7nyoXe2NY5db9YS LhwAn0Jlezjq+GkQGFGDxC6Cb/LREOfI =3jGx -----END PGP SIGNATURE----- --L6iaP+gRLNZHKoI4-- From owner-freebsd-stable@FreeBSD.ORG Thu Dec 25 10:44:31 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D615106564A for ; Thu, 25 Dec 2008 10:44:31 +0000 (UTC) (envelope-from ericlin@tamama.org) Received: from mail-gx0-f19.google.com (mail-gx0-f19.google.com [209.85.217.19]) by mx1.freebsd.org (Postfix) with ESMTP id D9D5C8FC1E for ; Thu, 25 Dec 2008 10:44:30 +0000 (UTC) (envelope-from ericlin@tamama.org) Received: by gxk12 with SMTP id 12so2263091gxk.19 for ; Thu, 25 Dec 2008 02:44:30 -0800 (PST) Received: by 10.150.228.2 with SMTP id a2mr17838147ybh.124.1230201869995; Thu, 25 Dec 2008 02:44:29 -0800 (PST) Received: by 10.151.74.12 with HTTP; Thu, 25 Dec 2008 02:44:29 -0800 (PST) Message-ID: <47713ee10812250244uee89581ifb452c837d9f1ba@mail.gmail.com> Date: Thu, 25 Dec 2008 18:44:29 +0800 From: "Lin Jui-Nan Eric" To: stable@freebsd.org In-Reply-To: <20081224030730.GY18389@elvis.mu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47713ee10812230915o7ea8fd1dge1ae7352694cb961@mail.gmail.com> <47713ee10812230917u506d8ee1ta9e93c8ef25e86e3@mail.gmail.com> <20081224030730.GY18389@elvis.mu.org> Cc: Subject: Re: Process stuck in STOP state X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Dec 2008 10:44:31 -0000 Hi, We have done a textdump, located here: http://aqua.pixnet.tw/~jnlin/textdump/ Thank you! On Wed, Dec 24, 2008 at 11:07 AM, Alfred Perlstein wrote: > * Lin Jui-Nan Eric [081223 09:17] wrote: >> > Dear listers, >> > >> > Our FreeBSD Server uses NFS to access PHP files on NetApp, then serve >> > them with apache 2.2 (worker MPM + php fastcgi mode). >> Sorry. we use -STABLE now. >> >> event# uname -a >> FreeBSD event 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #1: Thu Dec 4 >> 01:45:42 CST 2008 root@event:/usr/obj/usr/src/sys/KERNEL amd64 >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > It'd be good if you could get to ddb and do a "show all" > or "threads" and get all threads backtrace to see what's happening. > > thank you, > -- > - Alfred Perlstein > From owner-freebsd-stable@FreeBSD.ORG Thu Dec 25 11:44:45 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6DCB1065674 for ; Thu, 25 Dec 2008 11:44:45 +0000 (UTC) (envelope-from me@janh.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.freebsd.org (Postfix) with ESMTP id 726648FC27 for ; Thu, 25 Dec 2008 11:44:45 +0000 (UTC) (envelope-from me@janh.de) Received: from janh.freebsd (e177251072.adsl.alicedsl.de [85.177.251.72]) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis) id 0ML29c-1LFodv0Ne4-0002Al; Thu, 25 Dec 2008 12:44:43 +0100 Message-ID: <4953720D.8090201@janh.de> Date: Thu, 25 Dec 2008 12:44:13 +0100 From: Jan Henrik Sylvester User-Agent: Thunderbird 2.0.0.18 (X11/20081125) MIME-Version: 1.0 To: stable-list freebsd Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX18llXO/bvMSEHSLTZlRph1Hqlg1Ny+UrV5Tjln jgmT0ECGStjsVUaeRvljCu38g8x7Z7mTPgntrlR+Le7tp2XYjl Mj5Dl2+Kl9Q7pT5F+zutQ== Subject: 7.1-RC2: link_elf: symbol cp_time undefined X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Dec 2008 11:44:45 -0000 During boot I see: link_elf: symbol cp_time undefined I have realized it now with RC2, but looking at my logs, I have had that message during boot since upgrading this machine from 7.0-RELEASE to 7.1-RC1 via freebsd-update a at Dec-8. (I did recompile kernel modules from ports: fusefs-kmod and kqemu-kmod.) What is the easiest way to find out what tried to link to the unknown symbol? The context in which the messages appear is: savecore: no dumps found Initial i386 initialization:. Additional ABI support: linux. Starting local daemons:kldload: can't load ntfs: File exists link_elf: symbol cp_time undefined kldload: can't load linprocfs: No such file or directory link_elf: symbol cp_time undefined mount: linprocfs : Operation not supported by device . Updating motd. Starting fusefs. fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 Mounting late file systems:. In my rc.local, I have kldload ntfs kldload linprocfs mount -t linprocfs linprocfs /usr/compat/linux/proc which used to work (I think). /boot/kernel/linprocfs.ko does exist. Cheers, Jan Henrik From owner-freebsd-stable@FreeBSD.ORG Thu Dec 25 14:38:14 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F7AD106564A for ; Thu, 25 Dec 2008 14:38:14 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from phoebe.cse.buffalo.edu (phoebe.cse.buffalo.edu [128.205.32.89]) by mx1.freebsd.org (Postfix) with ESMTP id 68A2B8FC14 for ; Thu, 25 Dec 2008 14:38:14 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from [192.168.1.101] (cpe-74-77-179-53.buffalo.res.rr.com [74.77.179.53]) (authenticated bits=0) by phoebe.cse.buffalo.edu (8.14.1/8.13.7) with ESMTP id mBPEc15e090545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 25 Dec 2008 09:38:07 -0500 (EST) (envelope-from kensmith@cse.buffalo.edu) From: Ken Smith To: freebsd-stable Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Bwu5EGvjW/Ay0W9Ao+lS" Date: Thu, 25 Dec 2008 09:37:55 -0500 Message-Id: <1230215875.3862.14.camel@neo.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-DCC-Buffalo.EDU-Metrics: phoebe.cse.buffalo.edu 1029; Body=0 Fuz1=0 Fuz2=0 X-Spam-Status: No, score=1.7 required=5.0 tests=RCVD_IN_SORBS_DUL, RDNS_DYNAMIC autolearn=no version=3.2.3 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on phoebe.cse.buffalo.edu Subject: FreeBSD 7.1-RC2 Available... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Dec 2008 14:38:14 -0000 --=-Bwu5EGvjW/Ay0W9Ao+lS Content-Type: text/plain Content-Transfer-Encoding: quoted-printable FreeBSD 7.1-RC2 is now available, the second of the Release Candidates. Unless an as yet undiscovered show-stopper comes along the release itself will be anywhere from a week to two weeks from now. We *might* be doing it next week since the release test cycle has gone on for quite a while now and the latest thing that delayed the release was a Security Advisory (SAs don't typically get or need much in the way of public testing). The traffic we're seeing on the lists and in Gnats is certainly stuff we'll pay attention to and deal with but isn't quite severe enough to warrant further delaying an already severely delayed release. NOTE: If updating from a 7.0 or earlier system due to a change in the Vendor's drivers certain Intel NICs will now come up as igb(4) instead of em(4). We normally try to avoid changes like that in stable branches but the vendor felt it necessary in order to support the new adapters. See the UPDATING entry dated 20080811 for details. There are only 3 PCI ID's that should have their name changed from em(4) to igb(4): 0x10A7, 0x10A9, and 0x10D6. You should be able to determine if your card will change names by running the command "pciconf -l", and for the line representing your NIC (should be named em on older systems, e.g. em0 or em1, etc) check the fourth column. If it says "chip=3D0x10a7" (or one of the other two IDs given above) you will have the adapter's name change. The ISO images and FTP install trees are available on the FreeBSD Mirror sites. Using the primary site as an example: ftp://ftp.freebsd.org/pub/FreeBSD/releases/${arch}/ISO-IMAGES/7.1/ where ${arch} is one of amd64, i386, ia64, pc98, or sparc64. The powerpc architecture builds haven't completed quite yet. The ISOs for amd64, i386, and sparc64 include what is expected to be the final package set. For all architectures the ISOs with "disc" in their names are CDROM-sized, if you intend to install a variety of packages during installation you will need all three. For amd64 and i386 there is a gzip-ed iso with "dvd" in its name which is DVD-sized. It contains everything (install bits, livefs, docs, and packages) and can be used if your machine has a DVD drive in it. If you would like to do a source-based update to 7.1-RC2 from an already installed machine you can update your tree to RELENG_7_1 using normal cvsup/csup methods. Note that due to an unfortunate side-effect of the "real" source code repository now being in SVN it will look like all files have a new version so mergemaster may be a bit tedious. The freebsd-update(8) utility supports binary upgrades of i386 and amd64 systems running earlier FreeBSD releases. Systems running 7.0-RELEASE, 7.1-BETA, 7.1-BETA2, or 7.1-RC1 can upgrade as follows: =20 # freebsd-update upgrade -r 7.1-RC2 During this process, FreeBSD Update may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. =20 # freebsd-update install The system must be rebooted with the newly installed kernel before continui= ng. # shutdown -r now =20 After rebooting, freebsd-update needs to be run again to install the new userland components, and the system needs to be rebooted again: # freebsd-update install # shutdown -r now =20 Users of Intel network interfaces which are changing their name from "em" t= o "igb" should make necessary changes to configuration files BEFORE running freebsd-update, since otherwise the network interface will not be configure= d appropriately after rebooting for the first time. =20 Users of earlier FreeBSD releases (FreeBSD 6.x) can also use freebsd-update= to upgrade to FreeBSD 7.1, but will be prompted to rebuild all third-party applications (e.g., anything installed from the ports tree) after the secon= d invocation of "freebsd-update install", in order to handle differences in t= he system libraries between FreeBSD 6.x and FreeBSD 7.x. Checksums: MD5 (7.1-RC2-amd64-bootonly.iso) =3D 5eae06e1a07402dc31ccda6414c4c480 MD5 (7.1-RC2-amd64-disc1.iso) =3D 4635c72b9b37f7df6697f6e06a020949 MD5 (7.1-RC2-amd64-disc2.iso) =3D 53eefb2082bb123b831b8637eca7e22d MD5 (7.1-RC2-amd64-disc3.iso) =3D 62ed3347923bb094f8070c01f171e215 MD5 (7.1-RC2-amd64-docs.iso) =3D 5942546ada3aa9e8d4bd3fe70add61e3 MD5 (7.1-RC2-amd64-dvd1.iso) =3D 42a33c01cea05f4507743cf04ec50dbe MD5 (7.1-RC2-amd64-livefs.iso) =3D 200acb39f0fa76dc5f655480ce18ea43 MD5 (7.1-RC2-i386-bootonly.iso) =3D 5b0234a090009c575fece7c0009aa616 MD5 (7.1-RC2-i386-disc1.iso) =3D 90c6c1d1fa46ce6ca79d4e9c210b5a4a MD5 (7.1-RC2-i386-disc2.iso) =3D d28477d9679ee9af1da17db97ea6f4ec MD5 (7.1-RC2-i386-disc3.iso) =3D 90f79ed26697cdb1492e86bbb8169508 MD5 (7.1-RC2-i386-docs.iso) =3D eb4ab4b087d73a8e72ca836c14067baa MD5 (7.1-RC2-i386-dvd1.iso) =3D 74cd8c4a5a1c1dc33389018c152feb71 MD5 (7.1-RC2-i386-livefs.iso) =3D b72de0770b9d35e051f99cf21ef67f6e MD5 (7.1-RC2-ia64-bootonly.iso) =3D aeccc0ef9e82d89dc2ce391ed8d6de41 MD5 (7.1-RC2-ia64-disc1.iso) =3D 401dddb2a02d1270921a9b8b23a248c1 MD5 (7.1-RC2-ia64-disc2.iso) =3D 3b25fe5c5f3dc2a3b388ebb0210c20c0 MD5 (7.1-RC2-ia64-disc3.iso) =3D 636bac3172ecd6ad55228365915a046c MD5 (7.1-RC2-ia64-docs.iso) =3D 8424225487159edbb3d6754b282f0430 MD5 (7.1-RC2-ia64-livefs.iso) =3D 47e0acc9f2011cf11756394ac4bfe16a MD5 (7.1-RC2-pc98-bootonly.iso) =3D bf2790bcb75096bf657a48f77fa33546 MD5 (7.1-RC2-pc98-disc1.iso) =3D 5d87d2c2924162acb125f5b1a46705ab MD5 (7.1-RC2-pc98-livefs.iso) =3D 46da1e7e223bf68b61f5c38a191ee865 MD5 (7.1-RC2-sparc64-bootonly.iso) =3D 97335ef101e32572757762a27e844769 MD5 (7.1-RC2-sparc64-disc1.iso) =3D 966090d9c70dcaadba6b00832d8b7533 MD5 (7.1-RC2-sparc64-disc2.iso) =3D f5e8780d0ba9f4f89f27cdf51eb17d5d MD5 (7.1-RC2-sparc64-disc3.iso) =3D 853a981ea3ffe95ef8cf82e9cd439e40 MD5 (7.1-RC2-sparc64-docs.iso) =3D 3001db73b78adc882c62a357d0a84422 SHA256 (7.1-RC2-amd64-bootonly.iso) =3D e1b6958a8f08748c1847312fab8bd2c9bc4= 33d7c519e92495c35ea13c5cac64f SHA256 (7.1-RC2-amd64-disc1.iso) =3D 7da2bb04862608c4541cd907dcc5b802f84a4f= 7350ff1aeda6ec3a981e33f051 SHA256 (7.1-RC2-amd64-disc2.iso) =3D 620de9a6c57e309874d76cd08a0007845c1920= 9b676d17a6c9930b7f16f87216 SHA256 (7.1-RC2-amd64-disc3.iso) =3D 6b796ff00a10ba5b0eb269a68a4a5370383d5d= af2577f59b1ceefc303f97feab SHA256 (7.1-RC2-amd64-docs.iso) =3D c87064dd86ec849748f35a0de6e2e25f1b35f74= 5351651d6f382781bfef99223 SHA256 (7.1-RC2-amd64-dvd1.iso) =3D df762671f0d2469612210b76d2feac0bf38d710= f39c4914891180228fc8b5dcb SHA256 (7.1-RC2-amd64-livefs.iso) =3D 4598a0f8944fb177b289c9e4bd55bf353a287= 6ae90db585d8ba31daacd6f46b3 SHA256 (7.1-RC2-i386-bootonly.iso) =3D ee1da8333b57e51ecc73f643bee38356f40d= 18722d37b506c5b88baa19346d69 SHA256 (7.1-RC2-i386-disc1.iso) =3D 4a5c2e58a3d92fc344b92b8bf86b29f5a092536= 5c8c6bf08b444f70fda94f6d5 SHA256 (7.1-RC2-i386-disc2.iso) =3D 74eb1f29a82b8a44d4f91989f217f2ffadee0dd= 71458e7888c88dfe5a154b788 SHA256 (7.1-RC2-i386-disc3.iso) =3D f7ee665dd4f03feafa371db83cfa9d428459097= 88ade888a3115da738fa71d07 SHA256 (7.1-RC2-i386-docs.iso) =3D 352fbc6c231a0379c4b3a7612f47b9a283ea47af= 4d2237596fec5710bbab4029 SHA256 (7.1-RC2-i386-dvd1.iso) =3D 02a5eb11de9dd2fb6922802abdb385586f8e2e90= 628dbdef81c5373d67c25c78 SHA256 (7.1-RC2-i386-livefs.iso) =3D f0d788c045cc3c3e243048de022db63dc83db2= ae8d9227f557d6d907b36f880d SHA256 (7.1-RC2-ia64-bootonly.iso) =3D 8bd8b31968406971784b225261524044c440= 9c9d0a6e28a649846dcce1a7adf2 SHA256 (7.1-RC2-ia64-disc1.iso) =3D 48ca1c5b0e5afc98849d3f11b6f7fac65ca0083= d26409c1b9faf4963e5176baf SHA256 (7.1-RC2-ia64-disc2.iso) =3D 4e30b2eff68b3dc050d791d687968b5744335c1= 3a2a1921b8d1730fa7c1d85cf SHA256 (7.1-RC2-ia64-disc3.iso) =3D c6f791f6cddef9fdd5964981916c28f093bdfcb= a3c00b8094a84e6c15a0e37ba SHA256 (7.1-RC2-ia64-docs.iso) =3D 011524d3f9fc0be1ef839a8648c31db457a3d2f1= b6458949a71ec5bbb01d0cb4 SHA256 (7.1-RC2-ia64-livefs.iso) =3D 514bb8294a6ce6f8c82d6082d19d2a77c86bb7= ff31950479e41b36fe6ae8495d SHA256 (7.1-RC2-pc98-bootonly.iso) =3D 3ed13c6dbb85665e0a34807ac6003cfcafe9= b3ccd27beb6d9db0c59b0cf3764a SHA256 (7.1-RC2-pc98-disc1.iso) =3D 514691424950d431f91ad0b0e45563d8e815500= 16ac600d3d9a2eb42666a20ef SHA256 (7.1-RC2-pc98-livefs.iso) =3D e0a39d59c14727d2293a07a57e826ae5e92142= 8f84bda8a320c4d19f03861633 SHA256 (7.1-RC2-sparc64-bootonly.iso) =3D 348fcf313f93dc78770ccc80a7b8a9b2b= df90de6f62c88f87f778c87bd1b9658 SHA256 (7.1-RC2-sparc64-disc1.iso) =3D 3474d05e71c43418d10c1327d013f7e0adf5= 99b4cb92d31e333a804728422aa6 SHA256 (7.1-RC2-sparc64-disc2.iso) =3D e4097cb638be81e5ec4cc0ca685cfe9e8b5c= 09a1bb080adcfbd579422db4d27c SHA256 (7.1-RC2-sparc64-disc3.iso) =3D bc3558b1c0159381731012d2b4776e467194= 48df75d579c7f6a399712c671fdb SHA256 (7.1-RC2-sparc64-docs.iso) =3D 80e892dbdb51120347a40354fa1fff591f1ec= b862d4cf966736f9d1849d5597b --=20 Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-Bwu5EGvjW/Ay0W9Ao+lS Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAklTmqUACgkQ/G14VSmup/Z8OgCgivVDiFsm24f7bsuawgkUcpKj cicAnRRhpUIKjrwnOfuM9xwacNh/f6A1 =JnyK -----END PGP SIGNATURE----- --=-Bwu5EGvjW/Ay0W9Ao+lS-- From owner-freebsd-stable@FreeBSD.ORG Thu Dec 25 18:01:40 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 304BD106567B for ; Thu, 25 Dec 2008 18:01:40 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from acme.spoerlein.net (cl-43.dus-01.de.sixxs.net [IPv6:2a01:198:200:2a::2]) by mx1.freebsd.org (Postfix) with ESMTP id B4A508FC1A for ; Thu, 25 Dec 2008 18:01:39 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from roadrunner.spoerlein.net (p54954B2C.dip.t-dialin.net [84.149.75.44]) by acme.spoerlein.net (8.14.2/8.14.2) with ESMTP id mBPI1ZDR016349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 25 Dec 2008 19:01:36 +0100 (CET) (envelope-from uspoerlein@gmail.com) Received: from roadrunner.spoerlein.net (localhost [127.0.0.1]) by roadrunner.spoerlein.net (8.14.3/8.14.3) with ESMTP id mBPI1VjZ001513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Dec 2008 19:01:31 +0100 (CET) (envelope-from uspoerlein@gmail.com) Received: (from uqs@localhost) by roadrunner.spoerlein.net (8.14.3/8.14.3/Submit) id mBPA2Zn1001592; Thu, 25 Dec 2008 11:02:35 +0100 (CET) (envelope-from uspoerlein@gmail.com) Date: Thu, 25 Dec 2008 11:02:35 +0100 From: Ulrich Spoerlein To: Lin Jui-Nan Eric Message-ID: <20081225100235.GA1355@roadrunner.spoerlein.net> Mail-Followup-To: Lin Jui-Nan Eric , stable@freebsd.org References: <47713ee10812220844r7889d286l3a98f294d780ccc0@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47713ee10812220844r7889d286l3a98f294d780ccc0@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: stable@freebsd.org Subject: Re: amd(8) cores dump when load high X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Dec 2008 18:01:40 -0000 On Tue, 23.12.2008 at 00:44:53 +0800, Lin Jui-Nan Eric wrote: > Dear listers, > > We currently found that amd frequently cores dump while loading is > high (about 4~5) after we upgrade world & kernel from 7.0-RELEASE to > 7.1-PRERELEASE. > > I have read -stable and svn log of 7-STABLE, but can not found a > report or a solution. Did anyone have the same issue? Thank you very > much. Ever since I switched from file-based NSS to LDAP, amd(8) has been crashing on me almost every day, especially if there's no LDAP server available during boot (ie. the laptop is not on the home network). It looks like the error handling in NSS requests could be improved, but I've yet to investigate the whole matter. Load plays no role in amd(8) crashing (at least for me). Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. From owner-freebsd-stable@FreeBSD.ORG Thu Dec 25 19:33:25 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8C0C106564A for ; Thu, 25 Dec 2008 19:33:25 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by mx1.freebsd.org (Postfix) with ESMTP id 8A6FF8FC0C for ; Thu, 25 Dec 2008 19:33:25 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so1934838ywe.13 for ; Thu, 25 Dec 2008 11:33:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:cc; bh=VSyWWXI/FT5H5a6zbT1uUi7AE+7y++nbKYFEbq9inzg=; b=GZOetiSjMkaJCGhNDDkErro7qJ5XfB1jd5jIcXXkCENx6t400NRdCWdDV1C88ZhNfh 1zrcDCne6e8IFnJKyU1BKcXNqTTYnMRax8SqDLm95VIPI6E9uOuPLtmKEyYpjWvVbCMi Q9ktZZJm4GVL0JS/at/qWsZPTM0iL8nuba7U8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=v3nt0CVb0pKLyOzvUCtsPBAQ7ns1XT26IHUSxf69hoWkDMefrzLx7U1Yw5ld+4o2ab 2CyKD1tIDGpctn7AdLMHWVe3OuGEVMDrKifUfeUEpozqgIMFFjUxhmMKlkIKc9NgjvjR CK08pt5V5qRYGeB7fFK5kFFIZVerys94UFEyI= Received: by 10.100.105.15 with SMTP id d15mr5962671anc.69.1230232208096; Thu, 25 Dec 2008 11:10:08 -0800 (PST) Received: from ?10.94.86.53? ([32.159.232.211]) by mx.google.com with ESMTPS id c28sm13876995anc.47.2008.12.25.11.10.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 25 Dec 2008 11:10:04 -0800 (PST) References: <4953720D.8090201@janh.de> Message-Id: From: Garrett Cooper To: Jan Henrik Sylvester In-Reply-To: <4953720D.8090201@janh.de> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (5F136) Mime-Version: 1.0 (iPhone Mail 5F136) Date: Thu, 25 Dec 2008 11:09:33 -0800 Cc: stable-list freebsd Subject: Re: 7.1-RC2: link_elf: symbol cp_time undefined X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Dec 2008 19:33:25 -0000 On Dec 25, 2008, at 3:44, Jan Henrik Sylvester wrote: > During boot I see: link_elf: symbol cp_time undefined > > I have realized it now with RC2, but looking at my logs, I have had > that message during boot since upgrading this machine from 7.0- > RELEASE to 7.1-RC1 via freebsd-update a at Dec-8. (I did recompile > kernel modules from ports: fusefs-kmod and kqemu-kmod.) > > What is the easiest way to find out what tried to link to the > unknown symbol? The context in which the messages appear is: > > savecore: no dumps found > Initial i386 initialization:. > Additional ABI support: linux. > Starting local daemons:kldload: can't load ntfs: File exists > link_elf: symbol cp_time undefined > kldload: can't load linprocfs: No such file or directory > link_elf: symbol cp_time undefined > mount: linprocfs : Operation not supported by device > . > Updating motd. > Starting fusefs. > fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 > Mounting late file systems:. > > In my rc.local, I have > kldload ntfs > kldload linprocfs > mount -t linprocfs linprocfs /usr/compat/linux/proc > which used to work (I think). /boot/kernel/linprocfs.ko does exist. > > Cheers, > Jan Henrik Did you compile your kernel from scratch? -Garrett From owner-freebsd-stable@FreeBSD.ORG Fri Dec 26 01:36:10 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D514106564A for ; Fri, 26 Dec 2008 01:36:10 +0000 (UTC) (envelope-from me@janh.de) Received: from mout-bounce.kundenserver.de (mout-bounce.kundenserver.de [212.227.17.2]) by mx1.freebsd.org (Postfix) with ESMTP id C61BD8FC0C for ; Fri, 26 Dec 2008 01:36:09 +0000 (UTC) (envelope-from me@janh.de) Received: from janh.freebsd (e177251072.adsl.alicedsl.de [85.177.251.72]) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis) id 0ML29c-1LG1cS1O8U-0002AL; Fri, 26 Dec 2008 02:36:04 +0100 Message-ID: <49543502.80505@janh.de> Date: Fri, 26 Dec 2008 02:36:02 +0100 From: Jan Henrik Sylvester User-Agent: Thunderbird 2.0.0.18 (X11/20081125) MIME-Version: 1.0 To: Garrett Cooper References: <4953720D.8090201@janh.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX18vlTbI6zAeyUC5IiirlwAbi2Aoc45luNRbXEN 879+V3JXqwQyI8JvieB70aBjWqlbyIBTT03HftJNS+SHjMfu0c ZulENyPL+U+6ngZPfstUQ== Cc: stable-list freebsd Subject: Re: 7.1-RC2: link_elf: symbol cp_time undefined X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Dec 2008 01:36:10 -0000 Garrett Cooper wrote: > On Dec 25, 2008, at 3:44, Jan Henrik Sylvester wrote: > >> During boot I see: link_elf: symbol cp_time undefined >> >> I have realized it now with RC2, but looking at my logs, I have had >> that message during boot since upgrading this machine from 7.0-RELEASE >> to 7.1-RC1 via freebsd-update a at Dec-8. (I did recompile kernel >> modules from ports: fusefs-kmod and kqemu-kmod.) >> >> What is the easiest way to find out what tried to link to the unknown >> symbol? The context in which the messages appear is: >> >> savecore: no dumps found >> Initial i386 initialization:. >> Additional ABI support: linux. >> Starting local daemons:kldload: can't load ntfs: File exists >> link_elf: symbol cp_time undefined >> kldload: can't load linprocfs: No such file or directory >> link_elf: symbol cp_time undefined >> mount: linprocfs : Operation not supported by device >> . >> Updating motd. >> Starting fusefs. >> fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 >> Mounting late file systems:. >> >> In my rc.local, I have >> kldload ntfs >> kldload linprocfs >> mount -t linprocfs linprocfs /usr/compat/linux/proc >> which used to work (I think). /boot/kernel/linprocfs.ko does exist. >> >> Cheers, >> Jan Henrik > > Did you compile your kernel from scratch? > -Garrett No, it came with freebsd-update (every possible freebsd-update since the install from the 7.0-BETA4 CD). Outside /etc, the IDS function of freebsd-update only reports a mismatch for /boot/kernel/linker.hints -- can this be the problem? (I will try to replace it tomorrow.) Cheers, Jan Henrik From owner-freebsd-stable@FreeBSD.ORG Fri Dec 26 03:26:31 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 458371065670 for ; Fri, 26 Dec 2008 03:26:31 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 32F448FC18 for ; Fri, 26 Dec 2008 03:26:30 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id D88001A3C3A; Thu, 25 Dec 2008 19:26:30 -0800 (PST) Date: Thu, 25 Dec 2008 19:26:30 -0800 From: Alfred Perlstein To: Lin Jui-Nan Eric Message-ID: <20081226032630.GN18389@elvis.mu.org> References: <47713ee10812230915o7ea8fd1dge1ae7352694cb961@mail.gmail.com> <47713ee10812230917u506d8ee1ta9e93c8ef25e86e3@mail.gmail.com> <20081224030730.GY18389@elvis.mu.org> <47713ee10812250244uee89581ifb452c837d9f1ba@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47713ee10812250244uee89581ifb452c837d9f1ba@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: stable@freebsd.org Subject: Re: Process stuck in STOP state X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Dec 2008 03:26:31 -0000 * Lin Jui-Nan Eric [081225 02:44] wrote: > Hi, > > We have done a textdump, located here: http://aqua.pixnet.tw/~jnlin/textdump/ > Thank you! Is NFS working when this happens? Can you run lsof too? It would be really good to get a backtrace from all processes, there's a ddb command to do this. -Alfred > > On Wed, Dec 24, 2008 at 11:07 AM, Alfred Perlstein wrote: > > * Lin Jui-Nan Eric [081223 09:17] wrote: > >> > Dear listers, > >> > > >> > Our FreeBSD Server uses NFS to access PHP files on NetApp, then serve > >> > them with apache 2.2 (worker MPM + php fastcgi mode). > >> Sorry. we use -STABLE now. > >> > >> event# uname -a > >> FreeBSD event 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #1: Thu Dec 4 > >> 01:45:42 CST 2008 root@event:/usr/obj/usr/src/sys/KERNEL amd64 > >> _______________________________________________ > >> freebsd-stable@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable > >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > > > It'd be good if you could get to ddb and do a "show all" > > or "threads" and get all threads backtrace to see what's happening. > > > > thank you, > > -- > > - Alfred Perlstein > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- - Alfred Perlstein From owner-freebsd-stable@FreeBSD.ORG Fri Dec 26 03:34:39 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E56B0106564A; Fri, 26 Dec 2008 03:34:39 +0000 (UTC) (envelope-from ericlin@tamama.org) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.187]) by mx1.freebsd.org (Postfix) with ESMTP id 87C758FC0C; Fri, 26 Dec 2008 03:34:39 +0000 (UTC) (envelope-from ericlin@tamama.org) Received: by rn-out-0910.google.com with SMTP id j71so2615144rne.12 for ; Thu, 25 Dec 2008 19:34:38 -0800 (PST) Received: by 10.150.201.2 with SMTP id y2mr1399116ybf.15.1230262478651; Thu, 25 Dec 2008 19:34:38 -0800 (PST) Received: by 10.151.74.12 with HTTP; Thu, 25 Dec 2008 19:34:38 -0800 (PST) Message-ID: <47713ee10812251934v7b15e2f0p2600c9c65c0f0677@mail.gmail.com> Date: Fri, 26 Dec 2008 11:34:38 +0800 From: "Lin Jui-Nan Eric" To: "Alfred Perlstein" In-Reply-To: <20081226032630.GN18389@elvis.mu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47713ee10812230915o7ea8fd1dge1ae7352694cb961@mail.gmail.com> <47713ee10812230917u506d8ee1ta9e93c8ef25e86e3@mail.gmail.com> <20081224030730.GY18389@elvis.mu.org> <47713ee10812250244uee89581ifb452c837d9f1ba@mail.gmail.com> <20081226032630.GN18389@elvis.mu.org> Cc: stable@freebsd.org Subject: Re: Process stuck in STOP state X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Dec 2008 03:34:40 -0000 Hi, No, NFS is not working (df hangs, and cd /nfs/vol hangs, too). we have run fstat and see some NFS file is opened. I will do a full back-trace while this happened again. (It happens very frequently....about 10 times/day now) On Fri, Dec 26, 2008 at 11:26 AM, Alfred Perlstein wrote: > * Lin Jui-Nan Eric [081225 02:44] wrote: >> Hi, >> >> We have done a textdump, located here: http://aqua.pixnet.tw/~jnlin/textdump/ >> Thank you! > > Is NFS working when this happens? > > Can you run lsof too? > > It would be really good to get a backtrace from all processes, there's > a ddb command to do this. > > -Alfred > >> >> On Wed, Dec 24, 2008 at 11:07 AM, Alfred Perlstein wrote: >> > * Lin Jui-Nan Eric [081223 09:17] wrote: >> >> > Dear listers, >> >> > >> >> > Our FreeBSD Server uses NFS to access PHP files on NetApp, then serve >> >> > them with apache 2.2 (worker MPM + php fastcgi mode). >> >> Sorry. we use -STABLE now. >> >> >> >> event# uname -a >> >> FreeBSD event 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #1: Thu Dec 4 >> >> 01:45:42 CST 2008 root@event:/usr/obj/usr/src/sys/KERNEL amd64 >> >> _______________________________________________ >> >> freebsd-stable@freebsd.org mailing list >> >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> > >> > It'd be good if you could get to ddb and do a "show all" >> > or "threads" and get all threads backtrace to see what's happening. >> > >> > thank you, >> > -- >> > - Alfred Perlstein >> > >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > -- > - Alfred Perlstein > From owner-freebsd-stable@FreeBSD.ORG Fri Dec 26 04:41:14 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A027106564A; Fri, 26 Dec 2008 04:41:14 +0000 (UTC) (envelope-from ericlin@tamama.org) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.185]) by mx1.freebsd.org (Postfix) with ESMTP id 96A198FC08; Fri, 26 Dec 2008 04:41:13 +0000 (UTC) (envelope-from ericlin@tamama.org) Received: by rn-out-0910.google.com with SMTP id j71so2623076rne.12 for ; Thu, 25 Dec 2008 20:41:13 -0800 (PST) Received: by 10.151.45.6 with SMTP id x6mr15081613ybj.47.1230266472717; Thu, 25 Dec 2008 20:41:12 -0800 (PST) Received: by 10.151.74.12 with HTTP; Thu, 25 Dec 2008 20:41:12 -0800 (PST) Message-ID: <47713ee10812252041p3b4ba9e8sa92772264bd2ac3b@mail.gmail.com> Date: Fri, 26 Dec 2008 12:41:12 +0800 From: "Lin Jui-Nan Eric" To: "Alfred Perlstein" In-Reply-To: <47713ee10812251934v7b15e2f0p2600c9c65c0f0677@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47713ee10812230915o7ea8fd1dge1ae7352694cb961@mail.gmail.com> <47713ee10812230917u506d8ee1ta9e93c8ef25e86e3@mail.gmail.com> <20081224030730.GY18389@elvis.mu.org> <47713ee10812250244uee89581ifb452c837d9f1ba@mail.gmail.com> <20081226032630.GN18389@elvis.mu.org> <47713ee10812251934v7b15e2f0p2600c9c65c0f0677@mail.gmail.com> Cc: stable@freebsd.org Subject: Re: Process stuck in STOP state X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Dec 2008 04:41:14 -0000 Hi, Full back-trace is located here: http://aqua.pixnet.tw/~jnlin/textdump/event3/1226/ On Fri, Dec 26, 2008 at 11:34 AM, Lin Jui-Nan Eric wrote: > Hi, > > No, NFS is not working (df hangs, and cd /nfs/vol hangs, too). we have > run fstat and see some NFS file is opened. > I will do a full back-trace while this happened again. (It happens > very frequently....about 10 times/day now) > > On Fri, Dec 26, 2008 at 11:26 AM, Alfred Perlstein wrote: >> * Lin Jui-Nan Eric [081225 02:44] wrote: >>> Hi, >>> >>> We have done a textdump, located here: http://aqua.pixnet.tw/~jnlin/textdump/ >>> Thank you! >> >> Is NFS working when this happens? >> >> Can you run lsof too? >> >> It would be really good to get a backtrace from all processes, there's >> a ddb command to do this. >> >> -Alfred >> >>> >>> On Wed, Dec 24, 2008 at 11:07 AM, Alfred Perlstein wrote: >>> > * Lin Jui-Nan Eric [081223 09:17] wrote: >>> >> > Dear listers, >>> >> > >>> >> > Our FreeBSD Server uses NFS to access PHP files on NetApp, then serve >>> >> > them with apache 2.2 (worker MPM + php fastcgi mode). >>> >> Sorry. we use -STABLE now. >>> >> >>> >> event# uname -a >>> >> FreeBSD event 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #1: Thu Dec 4 >>> >> 01:45:42 CST 2008 root@event:/usr/obj/usr/src/sys/KERNEL amd64 >>> >> _______________________________________________ >>> >> freebsd-stable@freebsd.org mailing list >>> >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >>> > >>> > It'd be good if you could get to ddb and do a "show all" >>> > or "threads" and get all threads backtrace to see what's happening. >>> > >>> > thank you, >>> > -- >>> > - Alfred Perlstein >>> > >>> _______________________________________________ >>> freebsd-stable@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> >> -- >> - Alfred Perlstein >> > From owner-freebsd-stable@FreeBSD.ORG Fri Dec 26 08:38:37 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBCF0106564A for ; Fri, 26 Dec 2008 08:38:37 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by mx1.freebsd.org (Postfix) with ESMTP id 7F4C28FC23 for ; Fri, 26 Dec 2008 08:38:37 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so1995597yxb.13 for ; Fri, 26 Dec 2008 00:38:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:cc; bh=DHJRXw/wySIIK+DB78D2p1ADZHk3QjX8g6fAYpF9hNg=; b=aq4qz9Srs+747Pmczt4B+El9PScD5quTTu8Ocrwn8f3ia4HxuRGsFdAVKYDdVg+qsq 3miIhu0K6Dgzi+ZWquRfynCfxyj+fM9A4gjQA9Ax9YhtZJ/zv2wFap/BiEV24x57zs4k l01hH6VabEXvlUGvYAw0+NvdoVSsbxreo/R8g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=IisRz/D+EXSlPrv6i5QMRsCvNBvJdFTFIO096fKZ9th7Fc/Qr+eAEzDMZMoRG800mh hIJImJ1KpHaiGF2ShqYOx5DrZkytbQOxDL+F2xSv10DqIWvbcOuMWARX8NxkR01KcqH/ drfX9zWWmijAmgnchwH0x4xO9QUMiTIBWEv9U= Received: by 10.100.163.8 with SMTP id l8mr6171348ane.127.1230280716810; Fri, 26 Dec 2008 00:38:36 -0800 (PST) Received: from ?10.97.3.41? ([32.154.77.238]) by mx.google.com with ESMTPS id c29sm18750476anc.49.2008.12.26.00.38.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 26 Dec 2008 00:38:35 -0800 (PST) References: <4953720D.8090201@janh.de> <49543502.80505@janh.de> Message-Id: <18AFA677-DE7D-402B-BC42-071818AFA393@gmail.com> From: Garrett Cooper To: Jan Henrik Sylvester In-Reply-To: <49543502.80505@janh.de> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (5F136) Mime-Version: 1.0 (iPhone Mail 5F136) Date: Fri, 26 Dec 2008 00:38:18 -0800 Cc: stable-list freebsd Subject: Re: 7.1-RC2: link_elf: symbol cp_time undefined X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Dec 2008 08:38:38 -0000 On Dec 25, 2008, at 17:36, Jan Henrik Sylvester wrote: > Garrett Cooper wrote: >> On Dec 25, 2008, at 3:44, Jan Henrik Sylvester wrote: >>> During boot I see: link_elf: symbol cp_time undefined >>> >>> I have realized it now with RC2, but looking at my logs, I have >>> had that message during boot since upgrading this machine from 7.0- >>> RELEASE to 7.1-RC1 via freebsd-update a at Dec-8. (I did recompile >>> kernel modules from ports: fusefs-kmod and kqemu-kmod.) >>> >>> What is the easiest way to find out what tried to link to the >>> unknown symbol? The context in which the messages appear is: >>> >>> savecore: no dumps found >>> Initial i386 initialization:. >>> Additional ABI support: linux. >>> Starting local daemons:kldload: can't load ntfs: File exists >>> link_elf: symbol cp_time undefined >>> kldload: can't load linprocfs: No such file or directory >>> link_elf: symbol cp_time undefined >>> mount: linprocfs : Operation not supported by device >>> . >>> Updating motd. >>> Starting fusefs. >>> fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 >>> Mounting late file systems:. >>> >>> In my rc.local, I have >>> kldload ntfs >>> kldload linprocfs >>> mount -t linprocfs linprocfs /usr/compat/linux/proc >>> which used to work (I think). /boot/kernel/linprocfs.ko does exist. >>> >>> Cheers, >>> Jan Henrik >> Did you compile your kernel from scratch? >> -Garrett > > No, it came with freebsd-update (every possible freebsd-update since > the install from the 7.0-BETA4 CD). Outside /etc, the IDS function > of freebsd-update only reports a mismatch for /boot/kernel/ > linker.hints -- can this be the problem? (I will try to replace it > tomorrow.) > > Cheers, > Jan Henrik It shouldn't be the hints file. I would think it's a lack of Linux support built into the updated kernel. I've never used freebsd-upgrade though.. -Garrett From owner-freebsd-stable@FreeBSD.ORG Fri Dec 26 10:34:02 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2CC4106564A for ; Fri, 26 Dec 2008 10:34:02 +0000 (UTC) (envelope-from grafan@gmail.com) Received: from mail-bw0-f19.google.com (mail-bw0-f19.google.com [209.85.218.19]) by mx1.freebsd.org (Postfix) with ESMTP id 6E7598FC0C for ; Fri, 26 Dec 2008 10:34:02 +0000 (UTC) (envelope-from grafan@gmail.com) Received: by bwz12 with SMTP id 12so10218419bwz.19 for ; Fri, 26 Dec 2008 02:34:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=guGi1hWQMjkjS0AC7T4kl7SNiiT/sHsaZ/zPiZ8f2zA=; b=iOm6t8ohytjX0tw9bdbt8Nbx6VMZ/L9tZjef93XQuakwjZzx/v7PkyxAzo+1uMmSjO 4LdecTOVPg/9QFlihxNK79PAHXZrOBAnudtg4sYGewt8bQEXYWswdtvi0eHtt0u8KfYk CMHVliyxrqXXJYFTKr+LEvu3xkYz9sdpmeR6s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=OsnTRaxNAcfGWv1uQd4USomsNvENGKbTvIKN/ra2blV3/papc5URjjcP+MZ3iLES3h lbQCmiZkRf/bB/uIouHqgAxRP8UBi2QNdsDdfE5EvyKGNHKT5g20ZgVaBK1a18OZvZ5J yd1bw/wE8KWb2L2bT31bVVbc0Uzg3pfJwPoxU= Received: by 10.180.255.1 with SMTP id c1mr3923816bki.36.1230285773799; Fri, 26 Dec 2008 02:02:53 -0800 (PST) Received: by 10.181.22.6 with HTTP; Fri, 26 Dec 2008 02:02:53 -0800 (PST) Message-ID: <6eb82e0812260202m1d8816c5mc7b0991514f83853@mail.gmail.com> Date: Fri, 26 Dec 2008 18:02:53 +0800 From: "Rong-en Fan" To: "Lin Jui-Nan Eric" In-Reply-To: <47713ee10812220844r7889d286l3a98f294d780ccc0@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47713ee10812220844r7889d286l3a98f294d780ccc0@mail.gmail.com> Cc: stable@freebsd.org Subject: Re: amd(8) cores dump when load high X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Dec 2008 10:34:03 -0000 On Tue, Dec 23, 2008 at 12:44 AM, Lin Jui-Nan Eric wrote: > Dear listers, > > We currently found that amd frequently cores dump while loading is > high (about 4~5) after we upgrade world & kernel from 7.0-RELEASE to > 7.1-PRERELEASE. > > I have read -stable and svn log of 7-STABLE, but can not found a > report or a solution. Did anyone have the same issue? Thank you very > much. > According to my previous experience, amd 6.1.5 crashes under low memory situations. Not necessary high load. Regards, Rong-En Fan From owner-freebsd-stable@FreeBSD.ORG Fri Dec 26 13:23:05 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6497F1065675 for ; Fri, 26 Dec 2008 13:23:05 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by mx1.freebsd.org (Postfix) with ESMTP id 1E2308FC19 for ; Fri, 26 Dec 2008 13:23:04 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so2015824ywe.13 for ; Fri, 26 Dec 2008 05:23:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=7Nd5jPSn9W5fnR/nUcgPLbqaIFwcqvp7q0iFE6XpY7Q=; b=kSiLJ9EAYJveSIxktS0kRDdJ3uuX9IkgDA7usOBmVHTu8kKYyYoE75aq7/OtjNVUuO vkjl0k07aW0LGcmdt1VnVioeMwbhu5rTwNKP0dVJk1EZRJwWHGLXSMyFJGFRDQQAXfP1 l/Nqc4F9M6iszI3OlU4GnAPB/Ne3HkYnbNcOs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Oj7zTS6To/OZBiwAXYk4tcLlHE0UvF4//23LovhFF1ZkDfJq+ysEY4hy5l2zVzexZj P9XLkKtpQMEhHzEAa3OalkArdVGp23bGqppaZuQI1XVmysBdSucNNmCZNfDVVLI3HAAL f5kFnsxrn7Yfk7aFoa3oq20avW4ds1jV7Mtrs= Received: by 10.90.120.19 with SMTP id s19mr5321076agc.29.1230297784252; Fri, 26 Dec 2008 05:23:04 -0800 (PST) Received: by 10.90.73.9 with HTTP; Fri, 26 Dec 2008 05:23:04 -0800 (PST) Message-ID: Date: Fri, 26 Dec 2008 16:23:04 +0300 From: pluknet To: "FreeBSD Stable Mailing List" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Subject: Re: process stuck in vmopar X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Dec 2008 13:23:05 -0000 Hi again! 2008/12/24 pluknet : > 2008/12/24 pluknet : >> 2008/12/24 pluknet : >>> 2008/12/24 pluknet : >>>> Server version: Apache/2.2.11 (Unix) built from sources. >>>> >>>> After issuing kill -9 process stuck in vmopar state forever. >>>> aaa301 2313 0.0 0.0 0 8 ?? DE 3:10PM 0:00.01 >>>> /home/aaa301/myb vmopar >>>> >>>> System: FreeBSD 6.2 i386. >>>> >>> >>> One important note. >>> Kernel is built with options QUOTA, and this problem triggered >>> only when this user is overquoted (usage > quota and limit). >> >> A bit later various processes begin to stuck in "ufs" state. > > backtrace of process that stucks in vmopar: > > db> bt 1385 > Tracing pid 1385 tid 100181 td 0xc6c19960 > sched_switch(c6c19960,0,1) at sched_switch+0x15b > mi_switch(1,0) at mi_switch+0x270 > sleepq_switch(c2954ec8,c0a3d0a0,0,c094c4eb,211,...) at sleepq_switch+0xc1 > sleepq_wait(c2954ec8,0,c096897c,709,c096897c,...) at sleepq_wait+0x46 > msleep(c2954ec8,c0ab8e80,244,c0968ca9,0,c9030444,0,c0968eb0,200,c2954ec8,82) > at > msleep+0x279 > vm_page_sleep_if_busy(c2954ec8,1,c0968ca9) at vm_page_sleep_if_busy+0x7c > vm_object_page_remove(c9030444,4,0,8000,0,0) at vm_object_page_remove+0xf9 > vnode_pager_setsize(c903c000,4000,0) at vnode_pager_setsize+0xbd > ffs_write(f734a78c) at ffs_write+0x264 > VOP_WRITE_APV(c0a09b00,f734a78c) at VOP_WRITE_APV+0x112 > vnode_pager_generic_putpages(c903c000,f734a8d0,9000,5,f734a860,...) at > vnode_pag > er_generic_putpages+0x1ef > vop_stdputpages(f734a814) at vop_stdputpages+0x1a > VOP_PUTPAGES_APV(c0a09b00,f734a814) at VOP_PUTPAGES_APV+0x8c > vnode_pager_putpages(c9030444,f734a8d0,9,5,f734a860) at > vnode_pager_putpages+0x7 > e > vm_pageout_flush(f734a8d0,9,5,0,0,...) at vm_pageout_flush+0x112 > vm_object_page_collect_flush(c9030444,c29505a8,251,5,4a,...) at > vm_object_page_c > ollect_flush+0x2a0 > vm_object_page_clean(c9030444,0,0,0,0,...) at vm_object_page_clean+0x184 > vm_object_terminate(c9030444) at vm_object_terminate+0x60 > vnode_destroy_vobject(c903c000,c6973500,f734aab8,c6c19960,0,...) at > vnode_destro > y_vobject+0x39 > ufs_reclaim(f734aab8) at ufs_reclaim+0x46 > VOP_RECLAIM_APV(c0a09b00,f734aab8) at VOP_RECLAIM_APV+0x7e > vgonel(c903c000) at vgonel+0x12d > vrecycle(c903c000,c6c19960) at vrecycle+0x38 > ufs_inactive(f734ab40) at ufs_inactive+0x2af > VOP_INACTIVE_APV(c0a09b00,f734ab40) at VOP_INACTIVE_APV+0x7e > vinactive(c903c000,c6c19960) at vinactive+0x72 > vrele(c903c000,c9030444,0,c096897c,1a2,...) at vrele+0x14a > vm_object_vndeallocate(c9030444) at vm_object_vndeallocate+0xc0 > vm_object_deallocate(c9030444,c9030444,0,c0968016,8e7) at > vm_object_deallocate+0 > xb3 > vm_map_entry_delete(c722a000,c7194bf4,f734ac20,c081ca37,c722a000,...) > at vm_map_ > entry_delete+0x130 > vm_map_delete(c722a000,0,bfc00000) at vm_map_delete+0x18f > vmspace_exit(c6c19960,c0a4bde0,0,c09463ea,125,...) at vmspace_exit+0xd5 > exit1(c6c19960,9,2831a4b4,c6c19960,c7234000,...) at exit1+0x496 > sigexit(c6c19960,9,c7234aa8,0,c09499bc,...) at sigexit+0xdf > postsig(9) at postsig+0x160 > ast(f734ad38) at ast+0x35e > doreti_ast() at doreti_ast+0x17 > > db> show alllock > Process 1385 (httpd) thread 0xc6c19960 (100181) > exclusive sx user map r = 0 (0xc722a044) locked @ > /usr/src/sys_uvmem_uip.6.2_RELEASE/vm/vm_map.c:307 > Today I found some interesting details how to reproduce my problem. Stucking apache2.x in "vmopar" with subsequent stuck of other various processes in "ufs" is only triggered with those options enabled in php.ini: extension="xcache.so" xcache.size=64M xcache.count=8 xcache.slot=64K xcache.var_size=64M xcache.var_count=8 xcache.var_slots=64K xcache.mmap_path=/tmp/xcache Perhaps the problem is related to mmap vs threads interaction. Any thoughts? > -- > wbr, > pluknet > From owner-freebsd-stable@FreeBSD.ORG Fri Dec 26 13:54:33 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA92E1065677 for ; Fri, 26 Dec 2008 13:54:33 +0000 (UTC) (envelope-from me@janh.de) Received: from mout-xforward.kundenserver.de (mout-xforward.kundenserver.de [212.227.17.4]) by mx1.freebsd.org (Postfix) with ESMTP id 4EE228FC12 for ; Fri, 26 Dec 2008 13:54:33 +0000 (UTC) (envelope-from me@janh.de) Received: from janh.freebsd (e177245213.adsl.alicedsl.de [85.177.245.213]) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis) id 0ML25U-1LGD940mMs-0000N0; Fri, 26 Dec 2008 14:54:30 +0100 Message-ID: <4954E214.1020002@janh.de> Date: Fri, 26 Dec 2008 14:54:28 +0100 From: Jan Henrik Sylvester User-Agent: Thunderbird 2.0.0.18 (X11/20081125) MIME-Version: 1.0 To: Garrett Cooper References: <4953720D.8090201@janh.de> <49543502.80505@janh.de> <18AFA677-DE7D-402B-BC42-071818AFA393@gmail.com> In-Reply-To: <18AFA677-DE7D-402B-BC42-071818AFA393@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX18Wp/3+coAM7MTsIid8rXD5UhN8qZVv9NaX7WK 2DX+0qq73/0zrjbVdYUw9HbqgHt8J5HErxtMsIMvJLxU3UzjzH +0Uf3qrEH52W7VGXDncgA== Cc: stable-list freebsd Subject: Re: 7.1-RC2: link_elf: symbol cp_time undefined X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Dec 2008 13:54:33 -0000 Garrett Cooper wrote: > On Dec 25, 2008, at 17:36, Jan Henrik Sylvester wrote: > >> Garrett Cooper wrote: >>> On Dec 25, 2008, at 3:44, Jan Henrik Sylvester wrote: >>>> During boot I see: link_elf: symbol cp_time undefined >>>> >>>> I have realized it now with RC2, but looking at my logs, I have had >>>> that message during boot since upgrading this machine from >>>> 7.0-RELEASE to 7.1-RC1 via freebsd-update a at Dec-8. (I did >>>> recompile kernel modules from ports: fusefs-kmod and kqemu-kmod.) >>>> >>>> What is the easiest way to find out what tried to link to the >>>> unknown symbol? The context in which the messages appear is: >>>> >>>> savecore: no dumps found >>>> Initial i386 initialization:. >>>> Additional ABI support: linux. >>>> Starting local daemons:kldload: can't load ntfs: File exists >>>> link_elf: symbol cp_time undefined >>>> kldload: can't load linprocfs: No such file or directory >>>> link_elf: symbol cp_time undefined >>>> mount: linprocfs : Operation not supported by device >>>> . >>>> Updating motd. >>>> Starting fusefs. >>>> fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 >>>> Mounting late file systems:. >>>> >>>> In my rc.local, I have >>>> kldload ntfs >>>> kldload linprocfs >>>> mount -t linprocfs linprocfs /usr/compat/linux/proc >>>> which used to work (I think). /boot/kernel/linprocfs.ko does exist. >>>> >>>> Cheers, >>>> Jan Henrik >>> Did you compile your kernel from scratch? >>> -Garrett >> >> No, it came with freebsd-update (every possible freebsd-update since >> the install from the 7.0-BETA4 CD). Outside /etc, the IDS function of >> freebsd-update only reports a mismatch for /boot/kernel/linker.hints >> -- can this be the problem? (I will try to replace it tomorrow.) >> >> Cheers, >> Jan Henrik > > It shouldn't be the hints file. I would think it's a lack of Linux > support built into the updated kernel. I've never used freebsd-upgrade > though.. > -Garrett Thanks for your answer. The problem is entirely my fault. From 7.0, I still had /boot/ulegeneric in my kern.module_path instead of /boot/kernel -- and /boot/ulegeneric is still there containing a 7.0-p6 kernel with ULE scheduler, of which the modules do not work with the 7.1-RC2 kernel (booted from /boot/kernel). Sorry for the fuss. Cheers, Jan Henrik From owner-freebsd-stable@FreeBSD.ORG Fri Dec 26 15:04:26 2008 Return-Path: Delivered-To: FreeBSD-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7659D106564A for ; Fri, 26 Dec 2008 15:04:26 +0000 (UTC) (envelope-from barbara.xxx1975@libero.it) Received: from cp-out2.libero.it (cp-out2.libero.it [212.52.84.102]) by mx1.freebsd.org (Postfix) with ESMTP id 761158FC22 for ; Fri, 26 Dec 2008 15:04:25 +0000 (UTC) (envelope-from barbara.xxx1975@libero.it) Received: from wmail19 (172.31.0.29) by cp-out2.libero.it (8.5.016.1) id 493F94E1016162E6 for FreeBSD-stable@FreeBSD.org; Fri, 26 Dec 2008 16:04:22 +0100 Message-ID: <4719661.485641230303862495.JavaMail.defaultUser@defaultHost> Date: Fri, 26 Dec 2008 16:04:22 +0100 (CET) From: Barbara To: FreeBSD-stable@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: 7bit X-SenderIP: 87.11.229.158 Cc: Subject: Fatal trap 12: page fault while in kernel mode (swi6: task queue) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Barbara List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Dec 2008 15:04:26 -0000 Can anyone help understanding the reason? # uname -rsm FreeBSD 6.4-STABLE i386 # kgdb kernel.debug /var/crash/vmcore.7 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: acd0: WARNING - PREVENT_ALLOW read data overrun 18>0 kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x104 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0541da5 stack pointer = 0x28:0xe5928c00 frame pointer = 0x28:0xe5928c18 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 17 (swi6: task queue) trap number = 12 panic: page fault cpuid = 0 Uptime: 4h16m22s Physical memory: 2031 MB Dumping 204 MB: 189 173 157 141 125 109 93 77 61 45 29 13 Reading symbols from /boot/kernel/linux.ko...done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/kernel/acpi.ko...done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /boot/kernel/linprocfs.ko...done. Loaded symbols for /boot/kernel/linprocfs.ko Reading symbols from /boot/kernel/logo_saver.ko... done. Loaded symbols for /boot/kernel/logo_saver.ko #0 doadump () at pcpu.h: 165 165 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc054d7d9 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:410 #2 0xc054dba6 in panic (fmt=0xc0736cc9 "% s") at /usr/src/sys/kern/kern_shutdown.c:566 #3 0xc071812c in trap_fatal (frame=0xe5928bc0, eva=0) at /usr/src/sys/i386/i386/trap.c:838 #4 0xc07177e4 in trap (frame= {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -960560384, tf_esi = 4, tf_ebp = -443380712, tf_isp = -443380756, tf_ebx = -942867596, tf_edx = 6, tf_ecx = 4, tf_eax = 1, tf_trapno = 12, tf_err = 0, tf_eip = -1068229211, tf_cs = 32, tf_eflags = 65538, tf_esp = -942867596, tf_ss = 0}) at /usr/src/sys/i386/i386/trap.c:270 #5 0xc06ff98a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #6 0xc0541da5 in _mtx_lock_sleep (m=0xc7ccfb74, tid=3334406912, opts=0, file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:546 #7 0xc054ca79 in _sema_post (sema=0xc7ccfb74, file=0x0, line=0) at /usr/src/sys/kern/kern_sema.c:79 #8 0xc04705e3 in ata_completed (context=0xc7ccfb28, dummy=1) at /usr/src/sys/dev/ata/ata-queue.c:481 #9 0xc057547d in taskqueue_run (queue=0xc6c8a000) at /usr/src/sys/kern/subr_taskqueue.c:257 #10 0xc0575793 in taskqueue_swi_run (dummy=0x0) at /usr/src/sys/kern/subr_taskqueue.c:299 #11 0xc052ff1b in ithread_execute_handlers (p=0xc6bef860, ie=0xc6c44e80) at /usr/src/sys/kern/kern_intr.c:682 #12 0xc0530077 in ithread_loop (arg=0xc6c62510) at /usr/src/sys/kern/kern_intr.c:766 #13 0xc052e800 in fork_exit (callout=0xc0530010 , arg=0x1, frame=0x1) at /usr/src/sys/kern/kern_fork.c:788 #14 0xc06ff9ec in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:208 (kgdb) frame 6 #6 0xc0541da5 in _mtx_lock_sleep (m=0xc7ccfb74, tid=3334406912, opts=0, file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:546 546 owner = (struct thread *)(v & MTX_FLAGMASK); (kgdb) list 541 #if defined(SMP) && !defined (NO_ADAPTIVE_MUTEXES) 542 /* 543 * If the current owner of the lock is executing on another 544 * CPU, spin instead of blocking. 545 */ 546 owner = (struct thread *)(v & MTX_FLAGMASK); 547 #ifdef ADAPTIVE_GIANT 548 if (TD_IS_RUNNING(owner)) { 549 #else 550 if (m != &Giant && TD_IS_RUNNING (owner)) { From owner-freebsd-stable@FreeBSD.ORG Fri Dec 26 17:18:46 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E991C106564A for ; Fri, 26 Dec 2008 17:18:46 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: from mail-bw0-f19.google.com (mail-bw0-f19.google.com [209.85.218.19]) by mx1.freebsd.org (Postfix) with ESMTP id 778798FC08 for ; Fri, 26 Dec 2008 17:18:46 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: by bwz12 with SMTP id 12so10548998bwz.19 for ; Fri, 26 Dec 2008 09:18:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=I6aKKnUjYYJ8aVCCkzEgQTZiLGFXdUXWoBpC/eGBf8M=; b=FVUAQD75U8rx+dWvc2Wno084VRWpNMYSC6Zh81Sk9aPBmxV7TRdkOivEsBHc2QEjvs 5CM4+ENIU3R1Z1OeL4TOURtzhOqxe2V4XMJBPLvz4PrGbzOVN/s8D0s7n3wE137m1jk6 qIxBeNdRGNAwkUiofet4vhWBmScb/IRhuuGmY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=Gt/EMXQimbIs363fRCmPczB4EEt1VgL3SB/w9hvD7qRvk1DZ6luNY5TlyYe2OyVgzd 7MVnuOsUgzMsh3FNv2prL/wzMbj7pl+iOasEQZdAvBzNws45NOt8aaIduBC16aTMqd4Z 4CI3MqcHV0/k1QDy3O22LvpNuLU1Kxn8rhKBw= Received: by 10.223.106.15 with SMTP id v15mr8313869fao.15.1230311925240; Fri, 26 Dec 2008 09:18:45 -0800 (PST) Received: by 10.223.110.142 with HTTP; Fri, 26 Dec 2008 09:18:45 -0800 (PST) Message-ID: <4ad871310812260918h538d82c7s2f72f254bf08c26c@mail.gmail.com> Date: Fri, 26 Dec 2008 12:18:45 -0500 From: "Glen Barber" To: freebsd-stable MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Kernel Trap during installworld caused unrecoverable system X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Dec 2008 17:18:47 -0000 Hi folks. I was unfortunate enough to encounter a kernel trap in single user mode yesterday when upgrading from 7.1-RC1 to -RC2 using the typical build/install world. I'm still not sure what caused the trap, as the system was rebooting when I saw the screen. As one would expect, this led to an irrecoverable system; the system would automatically drop me into single user mode, as it could only mount the root directory; /bin/sh and /bin/csh would not work (had to use /restore/csh for the minimal digging I actually could do). So, now to the question. Given I could not mount anything other than /, would there have been any way for me to gather debugging information on what caused this failure? (FWIW, I am certain it is not a hardware failure.) Regards, -- Glen Barber From owner-freebsd-stable@FreeBSD.ORG Fri Dec 26 17:34:39 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E49CA1065675 for ; Fri, 26 Dec 2008 17:34:39 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from dhcp-172-28-76-39.eur.corp.google.com (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3C14D8FC1B; Fri, 26 Dec 2008 17:34:39 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <495515AE.4050606@FreeBSD.org> Date: Fri, 26 Dec 2008 17:34:38 +0000 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Glen Barber References: <4ad871310812260918h538d82c7s2f72f254bf08c26c@mail.gmail.com> In-Reply-To: <4ad871310812260918h538d82c7s2f72f254bf08c26c@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable Subject: Re: Kernel Trap during installworld caused unrecoverable system X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Dec 2008 17:34:40 -0000 Glen Barber wrote: > Hi folks. > > I was unfortunate enough to encounter a kernel trap in single user > mode yesterday when upgrading from 7.1-RC1 to -RC2 using the typical > build/install world. > > I'm still not sure what caused the trap, as the system was rebooting > when I saw the screen. As one would expect, this led to an > irrecoverable system; the system would automatically drop me into > single user mode, as it could only mount the root directory; /bin/sh > and /bin/csh would not work (had to use /restore/csh for the minimal > digging I actually could do). > > So, now to the question. Given I could not mount anything other than > /, would there have been any way for me to gather debugging > information on what caused this failure? (FWIW, I am certain it is > not a hardware failure.) You can proceed recovering the system using the tools in /rescue, and once you have shared libraries working again, run savecore to save the crashdump (assuming one was made). Kris From owner-freebsd-stable@FreeBSD.ORG Fri Dec 26 17:38:45 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 462221065675 for ; Fri, 26 Dec 2008 17:38:45 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.191]) by mx1.freebsd.org (Postfix) with ESMTP id C9FD08FC12 for ; Fri, 26 Dec 2008 17:38:44 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: by fk-out-0910.google.com with SMTP id k31so2914960fkk.11 for ; Fri, 26 Dec 2008 09:38:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=CGD4ynBT2NiaG44xY7NKMzt5ehFBB1Bp/qfjiMFrK1k=; b=Uz0VeWdkWYog169E9bbesF5K+hap37b7FxHpCl6Aqd3EMzQut24Cqxoacf2/Yr2c2A 7AJJh0ODhNhcH+1K0ur+1TqK0zL0vnLrx01x6jHKHDkVrz8kCwrEUaevLKevNCdVRkb+ vEYZDkR3Lk/JrrlxB0Y+To/tLarRnTjLycwWw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=cEmOh/TdouSwIT6iI0+PKa/dKQ5OSw0snCRpJOKbA+1CMMwANh3PX2wUmTOnhuFmWo o2HbcM1Sofg6LJmcCor9w9JiLRyMB2MRvQEFVmkc1Ef0sCg3+PwBCOrity2rz6gUUacn wVN7mLJf8hYp0OCQJoG3CPEvewrQxbG/8VFHg= Received: by 10.223.115.195 with SMTP id j3mr8283736faq.99.1230313123400; Fri, 26 Dec 2008 09:38:43 -0800 (PST) Received: by 10.223.110.142 with HTTP; Fri, 26 Dec 2008 09:38:43 -0800 (PST) Message-ID: <4ad871310812260938u2fa1ff59n2eee4f3f1f5fc058@mail.gmail.com> Date: Fri, 26 Dec 2008 12:38:43 -0500 From: "Glen Barber" To: "Kris Kennaway" In-Reply-To: <495515AE.4050606@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4ad871310812260918h538d82c7s2f72f254bf08c26c@mail.gmail.com> <495515AE.4050606@FreeBSD.org> Cc: freebsd-stable Subject: Re: Kernel Trap during installworld caused unrecoverable system X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Dec 2008 17:38:45 -0000 On Fri, Dec 26, 2008 at 12:34 PM, Kris Kennaway wrote: > Glen Barber wrote: >> >> Hi folks. >> >> I was unfortunate enough to encounter a kernel trap in single user >> mode yesterday when upgrading from 7.1-RC1 to -RC2 using the typical >> build/install world. >> >> I'm still not sure what caused the trap, as the system was rebooting >> when I saw the screen. As one would expect, this led to an >> irrecoverable system; the system would automatically drop me into >> single user mode, as it could only mount the root directory; /bin/sh >> and /bin/csh would not work (had to use /restore/csh for the minimal >> digging I actually could do). >> >> So, now to the question. Given I could not mount anything other than >> /, would there have been any way for me to gather debugging >> information on what caused this failure? (FWIW, I am certain it is >> not a hardware failure.) > > You can proceed recovering the system using the tools in /rescue, and once > you have shared libraries working again, run savecore to save the crashdump > (assuming one was made). > Hi, Kris. I'll do some digging later today. I appreciate your response. -- Glen Barber From owner-freebsd-stable@FreeBSD.ORG Fri Dec 26 19:17:43 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 509511065670 for ; Fri, 26 Dec 2008 19:17:43 +0000 (UTC) (envelope-from ericlin@tamama.org) Received: from mail-gx0-f19.google.com (mail-gx0-f19.google.com [209.85.217.19]) by mx1.freebsd.org (Postfix) with ESMTP id 11CBC8FC16 for ; Fri, 26 Dec 2008 19:17:42 +0000 (UTC) (envelope-from ericlin@tamama.org) Received: by gxk12 with SMTP id 12so2631114gxk.19 for ; Fri, 26 Dec 2008 11:17:42 -0800 (PST) Received: by 10.150.211.4 with SMTP id j4mr20604342ybg.187.1230319062224; Fri, 26 Dec 2008 11:17:42 -0800 (PST) Received: by 10.151.74.12 with HTTP; Fri, 26 Dec 2008 11:17:42 -0800 (PST) Message-ID: <47713ee10812261117o6f772843o53ec9542bc773141@mail.gmail.com> Date: Sat, 27 Dec 2008 03:17:42 +0800 From: "Lin Jui-Nan Eric" To: "Rong-en Fan" In-Reply-To: <6eb82e0812260202m1d8816c5mc7b0991514f83853@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47713ee10812220844r7889d286l3a98f294d780ccc0@mail.gmail.com> <6eb82e0812260202m1d8816c5mc7b0991514f83853@mail.gmail.com> Cc: stable@freebsd.org Subject: Re: amd(8) cores dump when load high X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Dec 2008 19:17:43 -0000 Yes, we found that it crashes when swap is used. On Fri, Dec 26, 2008 at 6:02 PM, Rong-en Fan wrote: > On Tue, Dec 23, 2008 at 12:44 AM, Lin Jui-Nan Eric wrote: >> Dear listers, >> >> We currently found that amd frequently cores dump while loading is >> high (about 4~5) after we upgrade world & kernel from 7.0-RELEASE to >> 7.1-PRERELEASE. >> >> I have read -stable and svn log of 7-STABLE, but can not found a >> report or a solution. Did anyone have the same issue? Thank you very >> much. >> > > According to my previous experience, amd 6.1.5 crashes > under low memory situations. Not necessary high load. > > Regards, > Rong-En Fan > From owner-freebsd-stable@FreeBSD.ORG Fri Dec 26 20:31:25 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE1C21065674 for ; Fri, 26 Dec 2008 20:31:25 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-gx0-f19.google.com (mail-gx0-f19.google.com [209.85.217.19]) by mx1.freebsd.org (Postfix) with ESMTP id 731478FC12 for ; Fri, 26 Dec 2008 20:31:25 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by gxk12 with SMTP id 12so2649532gxk.19 for ; Fri, 26 Dec 2008 12:31:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=G4zQ5/QMriDAvU8v8v2KnUZLStdrd+MZR2Zy+ShF0vE=; b=eHx5pI1TtZ8WMnC8psv+cjBDIH1dibkRSl0qmg/eaEeeuNANnyPtZNeQh6+Z+iDGU7 wukIldvtm+P31UXDbVnKPH/DZXUbG8e3u2l5+/JlvehkcLqy9LmxAs3lDyNqPckXtSnD G4L3TQ02U2evsallDs4EeIaX5vjUbvDPSUD/0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=IBpcY7PJOf0SfJSqp//M6Wg2FuXVfqCqghzDfWs9LG2UkP0gWqyK6g+63MTdaIDXdY j6US28eRNfbxrRd6eoLx/kaJ7ad2Tf6+A9jWjpqU5QdROcFXZztv99iB9Eew+g8bdxEi HthypTKMy7Jgp3RqcQFk0rBjKyi81FXboRN2k= Received: by 10.90.30.13 with SMTP id d13mr5516387agd.43.1230323484721; Fri, 26 Dec 2008 12:31:24 -0800 (PST) Received: by 10.90.73.9 with HTTP; Fri, 26 Dec 2008 12:31:24 -0800 (PST) Message-ID: Date: Fri, 26 Dec 2008 23:31:24 +0300 From: pluknet To: "FreeBSD Stable Mailing List" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Subject: Re: process stuck in vmopar X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Dec 2008 20:31:26 -0000 2008/12/26 pluknet : > Hi again! > > 2008/12/24 pluknet : >> 2008/12/24 pluknet : >>> 2008/12/24 pluknet : >>>> 2008/12/24 pluknet : >>>>> Server version: Apache/2.2.11 (Unix) built from sources. >>>>> >>>>> After issuing kill -9 process stuck in vmopar state forever. >>>>> aaa301 2313 0.0 0.0 0 8 ?? DE 3:10PM 0:00.01 >>>>> /home/aaa301/myb vmopar >>>>> >>>>> System: FreeBSD 6.2 i386. >>>>> >>>> >>>> One important note. >>>> Kernel is built with options QUOTA, and this problem triggered >>>> only when this user is overquoted (usage > quota and limit). >>> >>> A bit later various processes begin to stuck in "ufs" state. >> >> backtrace of process that stucks in vmopar: >> >> db> bt 1385 >> Tracing pid 1385 tid 100181 td 0xc6c19960 >> sched_switch(c6c19960,0,1) at sched_switch+0x15b >> mi_switch(1,0) at mi_switch+0x270 >> sleepq_switch(c2954ec8,c0a3d0a0,0,c094c4eb,211,...) at sleepq_switch+0xc1 >> sleepq_wait(c2954ec8,0,c096897c,709,c096897c,...) at sleepq_wait+0x46 >> msleep(c2954ec8,c0ab8e80,244,c0968ca9,0,c9030444,0,c0968eb0,200,c2954ec8,82) >> at >> msleep+0x279 >> vm_page_sleep_if_busy(c2954ec8,1,c0968ca9) at vm_page_sleep_if_busy+0x7c >> vm_object_page_remove(c9030444,4,0,8000,0,0) at vm_object_page_remove+0xf9 >> vnode_pager_setsize(c903c000,4000,0) at vnode_pager_setsize+0xbd >> ffs_write(f734a78c) at ffs_write+0x264 >> VOP_WRITE_APV(c0a09b00,f734a78c) at VOP_WRITE_APV+0x112 >> vnode_pager_generic_putpages(c903c000,f734a8d0,9000,5,f734a860,...) at >> vnode_pag >> er_generic_putpages+0x1ef >> vop_stdputpages(f734a814) at vop_stdputpages+0x1a >> VOP_PUTPAGES_APV(c0a09b00,f734a814) at VOP_PUTPAGES_APV+0x8c >> vnode_pager_putpages(c9030444,f734a8d0,9,5,f734a860) at >> vnode_pager_putpages+0x7 >> e >> vm_pageout_flush(f734a8d0,9,5,0,0,...) at vm_pageout_flush+0x112 >> vm_object_page_collect_flush(c9030444,c29505a8,251,5,4a,...) at >> vm_object_page_c >> ollect_flush+0x2a0 >> vm_object_page_clean(c9030444,0,0,0,0,...) at vm_object_page_clean+0x184 >> vm_object_terminate(c9030444) at vm_object_terminate+0x60 >> vnode_destroy_vobject(c903c000,c6973500,f734aab8,c6c19960,0,...) at >> vnode_destro >> y_vobject+0x39 >> ufs_reclaim(f734aab8) at ufs_reclaim+0x46 >> VOP_RECLAIM_APV(c0a09b00,f734aab8) at VOP_RECLAIM_APV+0x7e >> vgonel(c903c000) at vgonel+0x12d >> vrecycle(c903c000,c6c19960) at vrecycle+0x38 >> ufs_inactive(f734ab40) at ufs_inactive+0x2af >> VOP_INACTIVE_APV(c0a09b00,f734ab40) at VOP_INACTIVE_APV+0x7e >> vinactive(c903c000,c6c19960) at vinactive+0x72 >> vrele(c903c000,c9030444,0,c096897c,1a2,...) at vrele+0x14a >> vm_object_vndeallocate(c9030444) at vm_object_vndeallocate+0xc0 >> vm_object_deallocate(c9030444,c9030444,0,c0968016,8e7) at >> vm_object_deallocate+0 >> xb3 >> vm_map_entry_delete(c722a000,c7194bf4,f734ac20,c081ca37,c722a000,...) >> at vm_map_ >> entry_delete+0x130 >> vm_map_delete(c722a000,0,bfc00000) at vm_map_delete+0x18f >> vmspace_exit(c6c19960,c0a4bde0,0,c09463ea,125,...) at vmspace_exit+0xd5 >> exit1(c6c19960,9,2831a4b4,c6c19960,c7234000,...) at exit1+0x496 >> sigexit(c6c19960,9,c7234aa8,0,c09499bc,...) at sigexit+0xdf >> postsig(9) at postsig+0x160 >> ast(f734ad38) at ast+0x35e >> doreti_ast() at doreti_ast+0x17 >> >> db> show alllock >> Process 1385 (httpd) thread 0xc6c19960 (100181) >> exclusive sx user map r = 0 (0xc722a044) locked @ >> /usr/src/sys_uvmem_uip.6.2_RELEASE/vm/vm_map.c:307 >> > > Today I found some interesting details how to reproduce my problem. > > Stucking apache2.x in "vmopar" with subsequent stuck > of other various processes in "ufs" is only triggered with > those options enabled in php.ini: > > extension="xcache.so" > > xcache.size=64M > xcache.count=8 > xcache.slot=64K > xcache.var_size=64M > xcache.var_count=8 > xcache.var_slots=64K > xcache.mmap_path=/tmp/xcache > > Perhaps the problem is related to mmap vs threads interaction. > Any thoughts? > Also seen on 6.3, 6.4 releases. Prepared as PR kern/129956. -- wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Fri Dec 26 23:13:12 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FB1B106564A for ; Fri, 26 Dec 2008 23:13:12 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id C916B8FC0C for ; Fri, 26 Dec 2008 23:13:11 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id mBQNDAIe088722; Fri, 26 Dec 2008 18:13:10 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id mBQNDAdO050469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Dec 2008 18:13:10 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200812262313.mBQNDAdO050469@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 26 Dec 2008 18:13:13 -0500 To: pluknet , "FreeBSD Stable Mailing List" From: Mike Tancsa In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: bsdlist@cogeco.ca Subject: Re: process stuck in vmopar X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Dec 2008 23:13:12 -0000 At 03:31 PM 12/26/2008, pluknet wrote: >Also seen on 6.3, 6.4 releases. > >Prepared as PR kern/129956. I wonder if this is the same or similar issue in where the poster is also seeing processes stuck in UFS state http://lists.freebsd.org/pipermail/freebsd-stable/2008-December/047118.html From owner-freebsd-stable@FreeBSD.ORG Sat Dec 27 01:32:41 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A6A01065675 for ; Sat, 27 Dec 2008 01:32:41 +0000 (UTC) (envelope-from heliocentric@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by mx1.freebsd.org (Postfix) with ESMTP id 7B37A8FC19 for ; Sat, 27 Dec 2008 01:32:40 +0000 (UTC) (envelope-from heliocentric@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so2083042ywe.13 for ; Fri, 26 Dec 2008 17:32:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=7f4Wieb3+BhvhKY+StXOF+nJIgSGAbDeHXBPiMj3M5U=; b=eiphsRp51dPgi2S7vlYy/CdfD3CFHAktMBBfQYt8AoQiNpluGuiWT/T+uhhkCeesZw EA9UvE/GFT+IO/avPKCGbRgCC6/QphbQfWIdZ+Nx7zPLLgvxCJV6xLCE1F7pvk0yNyGu VhBAQV7t6eVlQvRbjMQhu2bsTG1e6JWTuiLYw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=kQL3CC2tGTDY0O9PfOfT+65LIHcsM/mFgITiCiMrkJzbF1LC/dABCaKrJj7wrWU8n2 w3kH5R01+AAezFQOkqZN8s+WQk2U3/r9/Dhx6/wFQP6SYB6v0MN6zeq0Sem+a29dUsFD Sq24NAVLQIdAWeBCMVhFdfh7mLMyNoJQ7rOys= Received: by 10.90.98.13 with SMTP id v13mr5609680agb.28.1230341559761; Fri, 26 Dec 2008 17:32:39 -0800 (PST) Received: by 10.90.100.6 with HTTP; Fri, 26 Dec 2008 17:32:39 -0800 (PST) Message-ID: Date: Fri, 26 Dec 2008 20:32:39 -0500 From: "Dylan Cochran" Sender: heliocentric@gmail.com To: freebsd-stable In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Google-Sender-Auth: a9dbaddd94a0d0e6 Subject: Re: Hard lock on 7.1-RC1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Dec 2008 01:32:41 -0000 On Tue, Dec 23, 2008 at 1:18 AM, Dylan Cochran wrote: > On Sun, Dec 21, 2008 at 3:05 PM, Dylan Cochran wrote: >> I'm hitting a strange lockup on 7.1-RC1, where some socket operations >> seem to stall, as well as basic file operations. The only reproducable >> way I have of triggering it is by doing multiple inserts into >> phpmyadmin on lighttpd+fastcgi php5 + mysql51-server, though this >> isn't the only thing which triggers it, just the only one which is >> semi reliable. I've also reproduced this on another machine, set up >> specifically to rule out any machine specific problems (as they have >> different drive controllers, one uses gjournal, etc). >> >> I inititially built a kernel with SW_WATCHDOG, and attempted to use >> watchdogd and DDB to get an output from show locks, but the watchdogd >> hasn't panicked the machine, so at least devfs is still unlocked; I'm >> not able to get physical access to the machine until monday. >> >> The bug was introduced as far as I can tell, between 7.1-BETA2 and 7.1-RC1. Here's the output of alltrace and show pcpu, as requested on IRC: KDB: debugger backends: ddb KDB: current backend: ddb 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.1-RC2 #2: Tue Dec 23 05:35:44 UTC 2008 root@venti.coppolino.lan:/usr/obj/usr/src/sys/DEBUG Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Celeron(R) CPU 3.06GHz (3095.61-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf41 Stepping = 1 Features=0xbfebfbff Features2=0x441d real memory = 1073676288 (1023 MB) avail memory = 1037094912 (989 MB) ACPI APIC Table: ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: mem 0xfd000000-0xfdffffff,0xf4000000-0xf5ffffff irq 16 at device 0.0 on pci1 uhci0: port 0xcc00-0xcc1f irq 16 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xd000-0xd01f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xd400-0xd41f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xd800-0xd81f irq 16 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xfebffc00-0xfebfffff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered umass0: on uhub4 uhid0: on uhub4 pcib2: at device 30.0 on pci0 pci2: on pcib2 rl0: port 0x9c00-0x9cff mem 0xfeafff00-0xfeafffff irq 18 at device 2.0 on pci2 miibus0: on rl0 rlphy0: PHY 0 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:08:54:e0:78:cb rl0: [ITHREAD] fwohci0: port 0x9800-0x987f mem 0xfeaff000-0xfeaff7ff irq 17 at device 5.0 on pci2 fwohci0: [FILTER] fwohci0: OHCI version 1.0 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 26:2d:48:00:01:00:00:00 fwohci0: Phy 1394a available S400, 3 ports. fwohci0: Link S100, max_rec 2 bytes. fwohci0: max_rec 2 -> 2048 firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 26:2d:48:00:00:00 fwe0: Ethernet address: 26:2d:48:00:00:00 fwip0: on firewire0 fwip0: Firewire address: 26:2d:48:00:01:00:00:00 @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x13c8000 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode rl1: port 0x9400-0x94ff mem 0xfeaffe00-0xfeaffeff irq 23 at device 11.0 on pci2 miibus1: on rl1 rlphy1: PHY 0 on miibus1 rlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl1: Ethernet address: 00:13:d3:ea:00:2c rl1: [ITHREAD] isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xc000-0xc007,0xbc00-0xbc03,0xb800-0xb807,0xb400-0xb403,0xb000-0xb00f irq 18 at device 31.1 on pci0 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] atapci1: port 0xec00-0xec07,0xe800-0xe803,0xe400-0xe407,0xe000-0xe003,0xdc00-0xdc0f irq 18 at device 31.2 on pci0 atapci1: [ITHREAD] ata4: on atapci1 ata4: [ITHREAD] ata5: on atapci1 ata5: [ITHREAD] pci0: at device 31.3 (no driver attached) pci0: at device 31.5 (no driver attached) fdc0: port 0x3f2-0x3f3,0x3f4-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console sio0: [FILTER] cpu0: on acpi0 p4tcc0: on cpu0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc97ff,0xc9800-0xcbfff,0xe0000-0xe0fff pnpid ORM0000 on isa0 ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata0: [ITHREAD] ata1 at port 0x170-0x177,0x376 irq 15 on isa0 ata1: [ITHREAD] atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 ppbus0: [ITHREAD] plip0: on ppbus0 plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" ffirewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) requency 3095605075 Hz quality 800 Timecounters tick every 1.000 msec ad4: 38166MB at ata2-master UDMA100 acd0: CDRW at ata3-master UDMA40 ad8: 381554MB at ata4-master SATA150 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-4 device da0: 40.000MB/s transfers da0: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C) GEOM_LABEL: Label for provider da0s1 is msdosfs/My Book. Trying to mount root from ufs:/dev/ad4s1a WARNING: / was not properly dismounted Loading configuration files. kernel dumps on /dev/ad4s1b Entropy harvesting: interrupts ethernet point_to_point kickstart. swapon: adding /dev/ad4s1b as swap device Starting file system checks: /dev/ad4s1a: INCORRECT BLOCK COUNT I=3184756 (960 should be 416) (CORRECTED) /dev/ad4s1a: UNREF FILE I=3184741 OWNER=mysql MODE=100600 /dev/ad4s1a: SIZE=0 MTIME=Dec 26 23:03 2008 (CLEARED) /dev/ad4s1a: UNREF FILE I=3184742 OWNER=mysql MODE=100600 /dev/ad4s1a: SIZE=0 MTIME=Dec 26 23:03 2008 (CLEARED) /dev/ad4s1a: UNREF FILE I=3184743 OWNER=mysql MODE=100600 /dev/ad4s1a: SIZE=0 MTIME=Dec 26 23:03 2008 (CLEARED) /dev/ad4s1a: UNREF FILE I=3184745 OWNER=mysql MODE=100600 /dev/ad4s1a: SIZE=0 MTIME=Dec 26 23:03 2008 (CLEARED) /dev/ad4s1a: UNREF FILE I=3184748 OWNER=mysql MODE=100600 /dev/ad4s1a: SIZE=0 MTIME=Dec 26 23:03 2008 (CLEARED) /dev/ad4s1a: FREE BLK COUNT(S) WRONG IN SUPERBLK (SALVAGED) /dev/ad4s1a: SUMMARY INFORMATION BAD (SALVAGED) /dev/ad4s1a: BLK(S) MISSING IN BIT MAPS (SALVAGED) /dev/ad4s1a: 301883 files, 2007620 used, 15899682 free (104434 frags, 1974406 blocks, 0.6% fragmentation) /dev/ad8p1: 3 files, 24001394 used, 165206304 free (24 frags, 20650785 blocks, 0.0% fragmentation) Setting hostuuid: 6cc18842-cc89-11dd-a258-000854e078cb. Setting hostid: 0x48a14ae1. Mounting local file systems:. Setting hostname: venti.coppolino.lan. net.inet6.ip6.auto_linklocal: 1 -> 0 rl0: link state changed to DOWN rl0: no link ....rl0: link state changed to UP got link DHCPREQUEST on rl0 to 255.255.255.255 port 67 DHCPACK from 172.17.0.1 bound to 172.17.1.2 -- renewal in 2592000 seconds. rl1: link state changed to DOWN lo0: flags=8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 rl0: flags=8843 metric 0 mtu 1500 options=8 ether 00:08:54:e0:78:cb inet 172.17.1.2 netmask 0xffff0000 broadcast 172.17.255.255 inet 172.17.1.4 netmask 0xffffffff broadcast 172.17.1.4 media: Ethernet autoselect (100baseTX ) status: active Additional routing options:. Starting devd. hw.acpi.cpu.cx_lowest: C1 -> C1 Additional IP options:. Mounting NFS file systems:. ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib a.out ldconfig path: /usr/lib/aorlut /usr/lib/comp1:at/aout link state changed to UP Creating and/or trimming log files:. Checking for core dump on /dev/ad4s1b... savecore: no dumps found Initial i386 initialization:. Additional ABI support:. Setting date via ntp. 27 Dec 00:12:43 ntpdate[837]: step time server 172.17.0.1 offset 0.301237 sec Clearing /tmp (X related). Starting gmond. Starting watchdogd. Starting local daemons:2008/1227 00:12:44 venti: conf...httpd tcp!172.17.1.2!http...init...icache 104,857,600 bytes = 1,638,400 entries; 16 scache sync...2008/1227 00:12:52 err 2: pre-copy sha1 wrong at arena055 248610572: expected=2e62696158543588314ff8e3fe2b22a8bf999ddd got=7333baa941bd97b468859c770552e4146bd24335 announce tcp!*!venti...serving. Loading configuration files. /etc/rc: WARNING: $hostname is not set -- see rc.conf(5). ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/mysql a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout Creating and/or trimming log files:. Clearing /tmp (X related). Starting local daemons:. Updating motd. Starting mysql. Starting lighttpd. Starting sshd. /etc/rc: WARNING: $sendmail_enable is not set properly - see rc.conf(5). /etc/rc: WARNING: $sendmail_enable is not set properly - see rc.conf(5). Local package initialization:. Sat Dec 27 00:13:04 UTC 2008 . Updating motd. Mounting late file systems:. Configuring syscons: blanktime. Starting sshd. Starting cron. Local package initialization:. Starting background file system checks in 60 seconds. Sat Dec 27 00:13:07 UTC 2008 FreeBSD/i386 (venti.coppolino.lan) (ttyd0) Last login: Fri Dec 26 23:03:19 on ttyd0 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 7.1-RC2 (DEBUG) #2: Tue Dec 23 05:35:44 UTC 2008 Welcome to FreeBSD! Before seeking technical support, please use the following resources: o Security advisories and updated errata information for all releases are at http://www.FreeBSD.org/releases/ - always consult the ERRATA section for your release first as it's updated frequently. o The Handbook and FAQ documents are at http://www.FreeBSD.org/ and, along with the mailing lists, can be searched by going to http://www.FreeBSD.org/search/. If the doc distribution has been installed, they're also available formatted in /usr/share/doc. If you still have a question or problem, please take the output of `uname -a', along with any relevant error messages, and email it as a question to the questions@FreeBSD.org mailing list. If you are unfamiliar with FreeBSD's directory layout, please refer to the hier(7) manual page. If you are not familiar with manual pages, type `man man'. You may also use sysinstall(8) to re-enter the installation and configuration utility. Edit /etc/motd to change this login announcement. You have new mail. venti# interrupt total irq4: sio0 620 irq6: fdc0 1 irq17: fwohci0 3 irq18: rl0 uhci2++ 58746 irq23: rl1 ehci0 206 cpu0: timer 431028 Total 490604 KDB: stack backtrace: db_trace_self_wrapper(c0b55b52,e66daae0,c07615e9,c0b50617,77c6c,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0b50617,77c6c,0,e66daae0,c07bf27a,...) at kdb_backtrace+0x29 hardclock(0,c07fedf3,0,0,0,...) at hardclock+0x1f9 lapic_handle_timer(e66dab08) at lapic_handle_timer+0x9c Xtimerint() at Xtimerint+0x1f --- interrupt, eip = 0xc07fedf3, esp = 0xe66dab48, ebp = 0xe66dac34 --- kern_sendfile(c41a7af0,e66dacfc,0,0,0,...) at kern_sendfile+0x463 do_sendfile(e66dad2c,c0aba265,c41a7af0,e66dacfc,20,...) at do_sendfile+0xb1 sendfile(c41a7af0,e66dacfc,20,16,e66dad2c,...) at sendfile+0x13 syscall(e66dad38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (393, FreeBSD ELF32, sendfile), eip = 0x282cb0cb, esp = 0xbfbfc7cc, ebp = 0xbfbfe848 --- KDB: enter: watchdog timeout [thread pid 1288 tid 100058 ] Stopped at kdb_enter_why+0x3a: movl $0,kdb_why db> show lock db> show pcpu cpuid = 0 curthread = 0xc41a7af0: pid 1288 "lighttpd" curpcb = 0xe66dad90 fpcurthread = none idlethread = 0xc3f18af0: pid 11 "idle: cpu0" APIC ID = 0 currentldt = 0x50 db> show all proc pid ppid pgrp uid state wmesg wchan cmd 1516 902 902 0 R watchdogd 1470 1467 1470 0 S+ ttyin 0xc418fc10 csh 1467 1 1467 0 Ss+ wait 0xc4602570 login 1466 1 1466 0 Ss+ ttyin 0xc41ac810 getty 1465 1464 49 0 S+ nanslp 0xc0c7dc44 sleep 1464 1461 49 0 S+ wait 0xc4603570 sh 1462 1 49 0 S+ piperd 0xc439d18c logger 1461 1 49 0 S+ wait 0xc4343828 sh 1427 1 1427 0 Ss nanslp 0xc0c7dc44 cron 1420 1 1420 0 Ss select 0xc0c88eb8 sshd 1417 1301 1301 80 SJ accept 0xc445a1da php-cgi 1416 1301 1301 80 SJ accept 0xc445a1da php-cgi 1415 1301 1301 80 SJ accept 0xc445a1da php-cgi 1414 1301 1301 80 SJ accept 0xc445a1da php-cgi 1413 1301 1301 80 SJ accept 0xc445a1da php-cgi 1412 1301 1301 80 SJ accept 0xc445a1da php-cgi 1411 1301 1301 80 SJ accept 0xc445a1da php-cgi 1410 1301 1301 80 SJ accept 0xc445a1da php-cgi 1409 1292 1292 80 SJ accept 0xc445ab9a php-cgi --More-- 1408 1292 1292 80 SJ accept 0xc445ab9a php-cgi 1407 1292 1292 80 SJ accept 0xc445ab9a php-cgi 1406 1292 1292 80 SJ accept 0xc445ab9a php-cgi 1405 1292 1292 80 SJ accept 0xc445ab9a php-cgi 1404 1292 1292 80 SJ accept 0xc445ab9a php-cgi 1403 1292 1292 80 SJ accept 0xc445ab9a php-cgi 1402 1292 1292 80 SJ accept 0xc445ab9a php-cgi 1401 1292 1292 80 SJ accept 0xc445ab9a php-cgi 1400 1292 1292 80 SJ accept 0xc445ab9a php-cgi 1399 1292 1292 80 SJ accept 0xc445ab9a php-cgi 1398 1292 1292 80 SJ accept 0xc445ab9a php-cgi 1397 1292 1292 80 SJ accept 0xc445ab9a php-cgi 1396 1292 1292 80 SJ accept 0xc445ab9a php-cgi 1395 1292 1292 80 SJ accept 0xc445ab9a php-cgi 1394 1292 1292 80 SJ accept 0xc445ab9a php-cgi 1393 1301 1301 80 SJ accept 0xc445a1da php-cgi 1392 1301 1301 80 SJ accept 0xc445a1da php-cgi 1391 1301 1301 80 SJ accept 0xc445a1da php-cgi 1390 1301 1301 80 SJ accept 0xc445a1da php-cgi 1389 1301 1301 80 SJ accept 0xc445a1da php-cgi --More-- 1388 1301 1301 80 SJ accept 0xc445a1da php-cgi 1387 1301 1301 80 SJ accept 0xc445a1da php-cgi 1386 1301 1301 80 RJ php-cgi 1322 1 1322 25 SsJ pause 0xc4566318 sendmail 1314 1 1314 0 RsJ sendmail 1306 1 1306 0 SsJ select 0xc0c88eb8 sshd 1301 1288 1301 80 SsJ wait 0xc4567000 initial thread 1292 1288 1292 80 SsJ wait 0xc433f2b8 initial thread 1288 1 1287 80 RJ CPU 0 lighttpd 1286 1173 1170 88 R+J (threaded) mysqld 100114 S sigwait 0xe67a2be0 mysqld 100111 S ucond 0xc43583c0 mysqld 100113 RunQ mysqld 100112 RunQ mysqld 100089 S ucond 0xc43576c0 mysqld 100088 S ucond 0xc41b13c0 mysqld 100087 S ucond 0xc43587c0 mysqld 100086 S ucond 0xc4357a80 mysqld 100053 S select 0xc0c88eb8 initial thread 1173 1 1170 88 S+J wait 0xc43be2b8 sh --More-- 920 1 920 0 R+ (threaded) venti 100072 S ucond 0xc4357300 venti 100071 S accept 0xc445b03a venti 100070 S ucond 0xc41b0040 venti 100069 S ucond 0xc4095980 venti 100068 S ucond 0xc4357140 venti 100067 S ucond 0xc41b1e00 venti 100066 S ucond 0xc4357100 venti 100065 S ucond 0xc41a4500 venti 100064 S accept 0xc445a6ba venti 100063 RunQ venti 100051 RunQ venti 902 1 902 0 Ss wait 0xc43bdae0 watchdogd 891 1 891 102 Rs gmond 770 1 770 0 Ss select 0xc0c88eb8 devd 338 1 338 65 Ss select 0xc0c88eb8 dhclient 322 1 49 0 S+ select 0xc0c88eb8 dhclient 48 0 0 0 SL sdflush 0xc0c95228 [softdepflush] 47 0 0 0 SL syncer 0xc0c7da6c [syncer] 46 0 0 0 SL vlruwt 0xc4342000 [vnlru] --More-- 45 0 0 0 SL psleep 0xc0c89324 [bufdaemon] 44 0 0 0 SL pgzero 0xc0c95e00 [pagezero] 43 0 0 0 SL psleep 0xc0c95a18 [vmdaemon] 42 0 0 0 SL psleep 0xc0c959e0 [pagedaemon] 41 0 0 0 SL waiting_ 0xc0c8b0b4 [sctp_iterator] 40 0 0 0 WL [irq7: ppbus0 ppc0] 39 0 0 0 WL [irq1: atkbd0] 38 0 0 0 WL [irq15: ata1] 37 0 0 0 WL [irq14: ata0] 36 0 0 0 WL [swi0: sio] 35 0 0 0 SL - 0xc418d83c [fdc0] 34 0 0 0 SL - 0xc4097000 [fw0_probe] 33 0 0 0 SL - 0xc408c200 [fw0_taskq] 32 0 0 0 SL usbevt 0xc4013210 [usb4] 31 0 0 0 WL [irq23: rl1 ehci0] 30 0 0 0 SL usbevt 0xc407f210 [usb3] 29 0 0 0 SL usbevt 0xc406c210 [usb2] 28 0 0 0 WL [irq18: rl0 uhci2++] 27 0 0 0 SL usbevt 0xc405c210 [usb1] 26 0 0 0 WL [irq19: uhci1] --More-- 25 0 0 0 SL usbtsk 0xc0c7b234 [usbtask-dr] 24 0 0 0 SL usbtsk 0xc0c7b220 [usbtask-hc] 23 0 0 0 SL usbevt 0xc4024210 [usb0] 22 0 0 0 WL [irq16: uhci0 uhci3] 21 0 0 0 WL [irq9: acpi0] 20 0 0 0 WL [swi6: task queue] 19 0 0 0 WL [swi6: Giant taskq] 18 0 0 0 SL - 0xc3fe3700 [thread taskq] 17 0 0 0 WL [swi5: +] 9 0 0 0 SL - 0xc3fe3880 [acpi_task_2] 8 0 0 0 SL - 0xc3fe3880 [acpi_task_1] 7 0 0 0 SL - 0xc3fe3880 [acpi_task_0] 16 0 0 0 WL [swi2: cambio] 6 0 0 0 SL ccb_scan 0xc0c4b054 [xpt_thrd] 5 0 0 0 SL - 0xc3fe3a80 [kqueue taskq] 15 0 0 0 SL - 0xc0c7da74 [yarrow] 4 0 0 0 SL - 0xc0c7b62c [g_down] 3 0 0 0 SL - 0xc0c7b628 [g_up] 2 0 0 0 SL - 0xc0c7b620 [g_event] 14 0 0 0 WL [swi3: vm] --More-- 13 0 0 0 WL [swi4: clock sio] 12 0 0 0 WL [swi1: net] 11 0 0 0 RL [idle: cpu0] 1 0 1 0 SLs wait 0xc3f16ae0 [init] 10 0 0 0 SL audit_wo 0xc0c94c64 [audit] 0 0 0 0 SLs sched 0xc0c7b6e0 [swapper] db> alltrace Tracing command watchdogd pid 1516 tid 100048 td 0xc40748c0 fork_trampoline() at fork_trampoline Tracing command csh pid 1470 tid 100083 td 0xc4571230 sched_switch(c4571230,0,1,e91c6875,b2,...) at sched_switch+0x43b mi_switch(1,0,c4571230,c4565000,e672d924,...) at mi_switch+0x146 sleepq_switch(c4571230,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(1,c4571230,e672d968,c07a8857,c418fc10,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c418fc10,59,c0b54014,d6,0,...) at sleepq_wait_sig+0xd _sleep(c418fc10,0,159,c0b57586,0,...) at _sleep+0x2c7 ttysleep(c418fc00,c418fc10,159,c0b57586,0,...) at ttysleep+0x39 ttread(c418fc00,e672dc60,0,e672dbb4,c0763e39,...) at ttread+0x617 ttyread(c4179500,e672dc60,0,c4213450,e672dbd8,...) at ttyread+0x38 giant_read(c4179500,e672dc60,0,0,1,...) at giant_read+0x89 devfs_read_f(c456b8e8,e672dc60,c4617000,0,c4571230,...) at devfs_read_f+0x7d dofileread(e672dc60,ffffffff,ffffffff,0,c456b8e8,...) at dofileread+0x96 kern_readv(c4571230,10,e672dc60,bfbfe976,1,...) at kern_readv+0x58 read(c4571230,e672dcfc,c,e672dcd8,c07abdd8,...) at read+0x4f syscall(e672dd38) at syscall+0x335 --More-- Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (3, FreeBSD ELF32, read), eip = 0x281f9983, esp = 0xbfbfe92c, ebp = 0xbfbfe948 --- Tracing command login pid 1467 tid 100120 td 0xc45ceaf0 sched_switch(c45ceaf0,0,1,ac163d54,b1,...) at sched_switch+0x43b mi_switch(1,0,c45ceaf0,c4602570,e67b9b90,...) at mi_switch+0x146 sleepq_switch(c45ceaf0,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c45ceaf0,e67b9bd4,c07a8857,c4602570,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c4602570,5c,c0b54014,d6,0,...) at sleepq_wait_sig+0xd _sleep(c4602570,c4602600,15c,c0b53aa3,0,...) at _sleep+0x2c7 kern_wait(c45ceaf0,5be,e67b9c2c,0,0,...) at kern_wait+0xf98 wait4(c45ceaf0,e67b9cfc,10,e67b9d38,e67b9d2c,...) at wait4+0x3b syscall(e67b9d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (7, FreeBSD ELF32, wait4), eip = 0x2810558b, esp = 0xbfbfed9c, ebp = 0xbfbfedb8 --- Tracing command getty pid 1466 tid 100116 td 0xc4610460 sched_switch(c4610460,0,1,7ed1eca5,b1,...) at sched_switch+0x43b mi_switch(1,0,c4610460,c46032b8,e67a9910,...) at mi_switch+0x146 sleepq_switch(c4610460,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb --More-- sleepq_catch_signals(1,c4610460,e67a9954,c07a8857,c41ac810,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c41ac810,59,c0b54014,d6,0,...) at sleepq_wait_sig+0xd _sleep(c41ac810,0,159,c0b57586,0,...) at _sleep+0x2c7 ttysleep(c41ac800,c41ac810,159,c0b57586,0,...) at ttysleep+0x39 ttread(c41ac800,e67a9c60,0,e67a9b8c,c06b149d,...) at ttread+0x617 ttyread(c41ab100,e67a9c60,0,e67a9bb4,c0763e39,...) at ttyread+0x38 scread(c41ab100,e67a9c60,0,c458878c,e67a9bd8,...) at scread+0x2d giant_read(c41ab100,e67a9c60,0,0,1,...) at giant_read+0x89 devfs_read_f(c456bc2c,e67a9c60,c3ee9300,0,c4610460,...) at devfs_read_f+0x7d dofileread(e67a9c60,ffffffff,ffffffff,0,c456bc2c,...) at dofileread+0x96 kern_readv(c4610460,0,e67a9c60,bfbfee4b,1,...) at kern_readv+0x58 read(c4610460,e67a9cfc,c,16,e67a9d2c,...) at read+0x4f syscall(e67a9d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (3, FreeBSD ELF32, read), eip = 0x2816a983, esp = 0xbfbfee2c, ebp = 0xbfbfee58 --- Tracing command sleep pid 1465 tid 100119 td 0xc45ced20 sched_switch(c45ced20,0,1,4d9b73f4,b1,...) at sched_switch+0x43b mi_switch(1,0,c45ced20,c4602828,e67b5bc8,...) at mi_switch+0x146 sleepq_switch(c45ced20,0,c0b5647e,19d,e67b5bb8,...) at sleepq_switch+0xcb --More-- sleepq_catch_signals(0,c45ced20,5c,e67b5c10,c07a8831,...) at sleepq_catch_signals+0x2fc sleepq_timedwait_sig(c0c7dc44,5c,c0b54014,d6,0,...) at sleepq_timedwait_sig+0x19 _sleep(c0c7dc44,0,15c,c0b544e9,ea61,...) at _sleep+0x2a1 kern_nanosleep(c45ced20,e67b5c64,e67b5c6c,3c,0,...) at kern_nanosleep+0xc1 nanosleep(c45ced20,e67b5cfc,8,e67b5cd8,c07abdd8,...) at nanosleep+0x6f syscall(e67b5d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (240, FreeBSD ELF32, nanosleep), eip = 0x2813a36f, esp = 0xbfbfee5c, ebp = 0xbfbfee98 --- Tracing command sh pid 1464 tid 100115 td 0xc4610690 sched_switch(c4610690,0,1,4d6253ae,b1,...) at sched_switch+0x43b mi_switch(1,0,c4610690,c4603570,e67a5b90,...) at mi_switch+0x146 sleepq_switch(c4610690,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c4610690,e67a5bd4,c07a8857,c4603570,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c4603570,5c,c0b54014,d6,0,...) at sleepq_wait_sig+0xd _sleep(c4603570,c4603600,15c,c0b53aa3,0,...) at _sleep+0x2c7 kern_wait(c4610690,ffffffff,e67a5c2c,2,0,...) at kern_wait+0xf98 wait4(c4610690,e67a5cfc,10,e67a5d38,e67a5d2c,...) at wait4+0x3b syscall(e67a5d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --More-- --- syscall (7, FreeBSD ELF32, wait4), eip = 0x2814658b, esp = 0xbfbfd8fc, ebp = 0xbfbfd918 --- Tracing command logger pid 1462 tid 100118 td 0xc4610000 sched_switch(c4610000,0,1,4d38fcac,b1,...) at sched_switch+0x43b mi_switch(1,0,c4610000,c4602ae0,e67b1b74,...) at mi_switch+0x146 sleepq_switch(c4610000,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c4610000,e67b1bb8,c07a8857,c439d18c,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c439d18c,4c,c0b54014,d6,0,...) at sleepq_wait_sig+0xd _sleep(c439d18c,c439d2fc,14c,c0b56a3d,0,...) at _sleep+0x2c7 pipe_read(c456bcc4,e67b1c60,c3ee9300,0,c4610000,...) at pipe_read+0x4a6 dofileread(e67b1c60,ffffffff,ffffffff,0,c456bcc4,...) at dofileread+0x96 kern_readv(c4610000,0,e67b1c60,28206000,1000,...) at kern_readv+0x58 read(c4610000,e67b1cfc,c,e67b1d38,e67b1d2c,...) at read+0x4f syscall(e67b1d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (3, FreeBSD ELF32, read), eip = 0x28159983, esp = 0xbfbfe99c, ebp = 0xbfbfe9b8 --- Tracing command sh pid 1461 tid 100060 td 0xc41a7690 sched_switch(c41a7690,0,1,4ce984d0,b1,...) at sched_switch+0x43b mi_switch(1,0,c41a7690,c4343828,e66e0b90,...) at mi_switch+0x146 --More-- sleepq_switch(c41a7690,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c41a7690,e66e0bd4,c07a8857,c4343828,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c4343828,5c,c0b54014,d6,0,...) at sleepq_wait_sig+0xd _sleep(c4343828,c43438b8,15c,c0b53aa3,0,...) at _sleep+0x2c7 kern_wait(c41a7690,ffffffff,e66e0c2c,2,0,...) at kern_wait+0xf98 wait4(c41a7690,e66e0cfc,10,e66e0d38,e66e0d2c,...) at wait4+0x3b syscall(e66e0d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (7, FreeBSD ELF32, wait4), eip = 0x2814658b, esp = 0xbfbfda9c, ebp = 0xbfbfdab8 --- Tracing command cron pid 1427 tid 100121 td 0xc45ce8c0 sched_switch(c45ce8c0,0,1,42ec0c9b,b1,...) at sched_switch+0x43b mi_switch(1,0,c45ce8c0,c46022b8,e67bdbc8,...) at mi_switch+0x146 sleepq_switch(c45ce8c0,0,c0b5647e,19d,e67bdbb8,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c45ce8c0,5c,e67bdc10,c07a8831,...) at sleepq_catch_signals+0x2fc sleepq_timedwait_sig(c0c7dc44,5c,c0b54014,d6,0,...) at sleepq_timedwait_sig+0x19 _sleep(c0c7dc44,0,15c,c0b544e9,cf09,...) at _sleep+0x2a1 kern_nanosleep(c45ce8c0,e67bdc64,e67bdc6c,35,0,...) at kern_nanosleep+0xc1 nanosleep(c45ce8c0,e67bdcfc,8,e67bdd38,e67bdd2c,...) at nanosleep+0x6f syscall(e67bdd38) at syscall+0x335 --More-- Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (240, FreeBSD ELF32, nanosleep), eip = 0x2815636f, esp = 0xbfbfed0c, ebp = 0xbfbfed38 --- Tracing command sshd pid 1420 tid 100117 td 0xc4610230 sched_switch(c4610230,0,1,303876cf,b1,...) at sched_switch+0x43b mi_switch(1,0,c4610230,c4603000,e67ada84,...) at mi_switch+0x146 sleepq_switch(c4610230,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c4610230,e67adac4,c0762080,c0c88eb8,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c0c88eb8,c0c88ea0,c0b695ef,101,0,...) at sleepq_wait_sig+0xd _cv_wait_sig(c0c88eb8,c0c88ea0,c0b569cc,30a,e67adae8,...) at _cv_wait_sig+0x180 kern_select(c4610230,4,285090ac,0,0,0,c4603000,e67adc98) at kern_select+0x7e7 select(c4610230,e67adcfc,14,e67add38,e67add2c,...) at select+0x5e syscall(e67add38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x28391903, esp = 0xbfbfe6ac, ebp = 0xbfbfee98 --- Tracing command php-cgi pid 1417 tid 100110 td 0xc4612460 sched_switch(c4612460,0,1,8bb08d1c,b0,...) at sched_switch+0x43b mi_switch(1,0,c4612460,c4603828,e6795bc4,...) at mi_switch+0x146 sleepq_switch(c4612460,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb --More-- sleepq_catch_signals(0,c4612460,e6795c08,c07a8857,c445a1da,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c445a1da,58,c0b54014,d6,0,...) at sleepq_wait_sig+0xd _sleep(c445a1da,c0c89198,158,c0b64515,0,...) at _sleep+0x2c7 kern_accept(c4612460,0,e6795c70,e6795c6c,e6795c68,...) at kern_accept+0x168 accept(c4612460,e6795cfc,c,e6795cd8,c07abdd8,...) at accept+0x8f syscall(e6795d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (30, FreeBSD ELF32, accept), eip = 0x2857a66f, esp = 0xbfbecb5c, ebp = 0xbfbfcc38 --- Tracing command php-cgi pid 1416 tid 100109 td 0xc4612690 sched_switch(c4612690,0,1,8ba183aa,b0,...) at sched_switch+0x43b mi_switch(1,0,c4612690,c4603ae0,e6791bc4,...) at mi_switch+0x146 sleepq_switch(c4612690,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c4612690,e6791c08,c07a8857,c445a1da,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c445a1da,58,c0b54014,d6,0,...) at sleepq_wait_sig+0xd _sleep(c445a1da,c0c89198,158,c0b64515,0,...) at _sleep+0x2c7 kern_accept(c4612690,0,e6791c70,e6791c6c,e6791c68,...) at kern_accept+0x168 accept(c4612690,e6791cfc,c,e6791d38,e6791d2c,...) at accept+0x8f syscall(e6791d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --More-- --- syscall (30, FreeBSD ELF32, accept), eip = 0x2857a66f, esp = 0xbfbecb5c, ebp = 0xbfbfcc38 --- Tracing command php-cgi pid 1415 tid 100108 td 0xc46128c0 sched_switch(c46128c0,0,1,8b93707b,b0,...) at sched_switch+0x43b mi_switch(1,0,c46128c0,c4604000,e678dbc4,...) at mi_switch+0x146 sleepq_switch(c46128c0,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c46128c0,e678dc08,c07a8857,c445a1da,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c445a1da,58,c0b54014,d6,0,...) at sleepq_wait_sig+0xd _sleep(c445a1da,c0c89198,158,c0b64515,0,...) at _sleep+0x2c7 kern_accept(c46128c0,0,e678dc70,e678dc6c,e678dc68,...) at kern_accept+0x168 accept(c46128c0,e678dcfc,c,e678dd38,e678dd2c,...) at accept+0x8f syscall(e678dd38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (30, FreeBSD ELF32, accept), eip = 0x2857a66f, esp = 0xbfbecb5c, ebp = 0xbfbfcc38 --- Tracing command php-cgi pid 1414 tid 100107 td 0xc4572230 sched_switch(c4572230,0,1,8b8476ab,b0,...) at sched_switch+0x43b mi_switch(1,0,c4572230,c46042b8,e6789bc4,...) at mi_switch+0x146 sleepq_switch(c4572230,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c4572230,e6789c08,c07a8857,c445a1da,...) at sleepq_catch_signals+0x2fc --More-- sleepq_wait_sig(c445a1da,58,c0b54014,d6,0,...) at sleepq_wait_sig+0xd _sleep(c445a1da,c0c89198,158,c0b64515,0,...) at _sleep+0x2c7 kern_accept(c4572230,0,e6789c70,e6789c6c,e6789c68,...) at kern_accept+0x168 accept(c4572230,e6789cfc,c,e6789d38,e6789d2c,...) at accept+0x8f syscall(e6789d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (30, FreeBSD ELF32, accept), eip = 0x2857a66f, esp = 0xbfbecb5c, ebp = 0xbfbfcc38 --- Tracing command php-cgi pid 1413 tid 100106 td 0xc4572460 sched_switch(c4572460,0,1,8b769822,b0,...) at sched_switch+0x43b mi_switch(1,0,c4572460,c4604570,e6785bc4,...) at mi_switch+0x146 sleepq_switch(c4572460,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c4572460,e6785c08,c07a8857,c445a1da,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c445a1da,58,c0b54014,d6,0,...) at sleepq_wait_sig+0xd _sleep(c445a1da,c0c89198,158,c0b64515,0,...) at _sleep+0x2c7 kern_accept(c4572460,0,e6785c70,e6785c6c,e6785c68,...) at kern_accept+0x168 accept(c4572460,e6785cfc,c,e6785d38,e6785d2c,...) at accept+0x8f syscall(e6785d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (30, FreeBSD ELF32, accept), eip = 0x2857a66f, esp = 0xbfbecb5c, ebp = 0xbfbfcc38 --- --More-- Tracing command php-cgi pid 1412 tid 100105 td 0xc4572690 sched_switch(c4572690,0,1,8bb31441,b0,...) at sched_switch+0x43b mi_switch(1,0,c4572690,c4604828,e6781bc4,...) at mi_switch+0x146 sleepq_switch(c4572690,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c4572690,e6781c08,c07a8857,c445a1da,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c445a1da,58,c0b54014,d6,0,...) at sleepq_wait_sig+0xd _sleep(c445a1da,c0c89198,158,c0b64515,0,...) at _sleep+0x2c7 kern_accept(c4572690,0,e6781c70,e6781c6c,e6781c68,...) at kern_accept+0x168 accept(c4572690,e6781cfc,c,e6781d38,e6781d2c,...) at accept+0x8f syscall(e6781d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (30, FreeBSD ELF32, accept), eip = 0x2857a66f, esp = 0xbfbecb5c, ebp = 0xbfbfcc38 --- Tracing command php-cgi pid 1411 tid 100104 td 0xc45728c0 sched_switch(c45728c0,0,1,8b5da0d4,b0,...) at sched_switch+0x43b mi_switch(1,0,c45728c0,c4604ae0,e677dbc4,...) at mi_switch+0x146 sleepq_switch(c45728c0,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c45728c0,e677dc08,c07a8857,c445a1da,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c445a1da,58,c0b54014,d6,0,...) at sleepq_wait_sig+0xd --More-- _sleep(c445a1da,c0c89198,158,c0b64515,0,...) at _sleep+0x2c7 kern_accept(c45728c0,0,e677dc70,e677dc6c,e677dc68,...) at kern_accept+0x168 accept(c45728c0,e677dcfc,c,e677dd38,e677dd2c,...) at accept+0x8f syscall(e677dd38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (30, FreeBSD ELF32, accept), eip = 0x2857a66f, esp = 0xbfbecb5c, ebp = 0xbfbfcc38 --- Tracing command php-cgi pid 1410 tid 100103 td 0xc4572af0 sched_switch(c4572af0,0,1,8b4f9884,b0,...) at sched_switch+0x43b mi_switch(1,0,c4572af0,c45672b8,e6779bc4,...) at mi_switch+0x146 sleepq_switch(c4572af0,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c4572af0,e6779c08,c07a8857,c445a1da,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c445a1da,58,c0b54014,d6,0,...) at sleepq_wait_sig+0xd _sleep(c445a1da,c0c89198,158,c0b64515,0,...) at _sleep+0x2c7 kern_accept(c4572af0,0,e6779c70,e6779c6c,e6779c68,...) at kern_accept+0x168 accept(c4572af0,e6779cfc,c,e6779d38,e6779d2c,...) at accept+0x8f syscall(e6779d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (30, FreeBSD ELF32, accept), eip = 0x2857a66f, esp = 0xbfbecb5c, ebp = 0xbfbfcc38 --- --More-- Tracing command php-cgi pid 1409 tid 100102 td 0xc4572d20 sched_switch(c4572d20,0,1,8b36b37f,b0,...) at sched_switch+0x43b mi_switch(1,0,c4572d20,c4567570,e6775bc4,...) at mi_switch+0x146 sleepq_switch(c4572d20,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c4572d20,e6775c08,c07a8857,c445ab9a,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c445ab9a,58,c0b54014,d6,0,...) at sleepq_wait_sig+0xd _sleep(c445ab9a,c0c89198,158,c0b64515,0,...) at _sleep+0x2c7 kern_accept(c4572d20,0,e6775c70,e6775c6c,e6775c68,...) at kern_accept+0x168 accept(c4572d20,e6775cfc,c,e6775d38,e6775d2c,...) at accept+0x8f syscall(e6775d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (30, FreeBSD ELF32, accept), eip = 0x2857a66f, esp = 0xbfbecb5c, ebp = 0xbfbfcc38 --- Tracing command php-cgi pid 1408 tid 100101 td 0xc45cc000 sched_switch(c45cc000,0,1,8b285aaf,b0,...) at sched_switch+0x43b mi_switch(1,0,c45cc000,c4567828,e6771bc4,...) at mi_switch+0x146 sleepq_switch(c45cc000,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c45cc000,e6771c08,c07a8857,c445ab9a,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c445ab9a,58,c0b54014,d6,0,...) at sleepq_wait_sig+0xd _sleep(c445ab9a,c0c89198,158,c0b64515,0,...) at _sleep+0x2c7 --More-- kern_accept(c45cc000,0,e6771c70,e6771c6c,e6771c68,...) at kern_accept+0x168 accept(c45cc000,e6771cfc,c,e6771d38,e6771d2c,...) at accept+0x8f syscall(e6771d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (30, FreeBSD ELF32, accept), eip = 0x2857a66f, esp = 0xbfbecb5c, ebp = 0xbfbfcc38 --- Tracing command php-cgi pid 1407 tid 100100 td 0xc45cc230 sched_switch(c45cc230,0,1,8b18ef43,b0,...) at sched_switch+0x43b mi_switch(1,0,c45cc230,c4567ae0,e676dbc4,...) at mi_switch+0x146 sleepq_switch(c45cc230,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c45cc230,e676dc08,c07a8857,c445ab9a,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c445ab9a,58,c0b54014,d6,0,...) at sleepq_wait_sig+0xd _sleep(c445ab9a,c0c89198,158,c0b64515,0,...) at _sleep+0x2c7 kern_accept(c45cc230,0,e676dc70,e676dc6c,e676dc68,...) at kern_accept+0x168 accept(c45cc230,e676dcfc,c,e676dd38,e676dd2c,...) at accept+0x8f syscall(e676dd38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (30, FreeBSD ELF32, accept), eip = 0x2857a66f, esp = 0xbfbecb5c, ebp = 0xbfbfcc38 --- Tracing command php-cgi pid 1406 tid 100099 td 0xc45cc460 --More-- sched_switch(c45cc460,0,1,8b039b0e,b0,...) at sched_switch+0x43b mi_switch(1,0,c45cc460,c45c2000,e6769bc4,...) at mi_switch+0x146 sleepq_switch(c45cc460,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c45cc460,e6769c08,c07a8857,c445ab9a,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c445ab9a,58,c0b54014,d6,0,...) at sleepq_wait_sig+0xd _sleep(c445ab9a,c0c89198,158,c0b64515,0,...) at _sleep+0x2c7 kern_accept(c45cc460,0,e6769c70,e6769c6c,e6769c68,...) at kern_accept+0x168 accept(c45cc460,e6769cfc,c,e6769d38,e6769d2c,...) at accept+0x8f syscall(e6769d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (30, FreeBSD ELF32, accept), eip = 0x2857a66f, esp = 0xbfbecb5c, ebp = 0xbfbfcc38 --- Tracing command php-cgi pid 1405 tid 100098 td 0xc45cc690 sched_switch(c45cc690,0,1,8af5aa25,b0,...) at sched_switch+0x43b mi_switch(1,0,c45cc690,c45c22b8,e6765bc4,...) at mi_switch+0x146 sleepq_switch(c45cc690,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c45cc690,e6765c08,c07a8857,c445ab9a,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c445ab9a,58,c0b54014,d6,0,...) at sleepq_wait_sig+0xd _sleep(c445ab9a,c0c89198,158,c0b64515,0,...) at _sleep+0x2c7 kern_accept(c45cc690,0,e6765c70,e6765c6c,e6765c68,...) at kern_accept+0x168 --More-- accept(c45cc690,e6765cfc,c,e6765d38,e6765d2c,...) at accept+0x8f syscall(e6765d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (30, FreeBSD ELF32, accept), eip = 0x2857a66f, esp = 0xbfbecb5c, ebp = 0xbfbfcc38 --- Tracing command php-cgi pid 1404 tid 100097 td 0xc45cc8c0 sched_switch(c45cc8c0,0,1,8ae7a63c,b0,...) at sched_switch+0x43b mi_switch(1,0,c45cc8c0,c45c2570,e6762bc4,...) at mi_switch+0x146 sleepq_switch(c45cc8c0,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c45cc8c0,e6762c08,c07a8857,c445ab9a,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c445ab9a,58,c0b54014,d6,0,...) at sleepq_wait_sig+0xd _sleep(c445ab9a,c0c89198,158,c0b64515,0,...) at _sleep+0x2c7 kern_accept(c45cc8c0,0,e6762c70,e6762c6c,e6762c68,...) at kern_accept+0x168 accept(c45cc8c0,e6762cfc,c,e6762d38,e6762d2c,...) at accept+0x8f syscall(e6762d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (30, FreeBSD ELF32, accept), eip = 0x2857a66f, esp = 0xbfbecb5c, ebp = 0xbfbfcc38 --- Tracing command php-cgi pid 1403 tid 100096 td 0xc45ccaf0 sched_switch(c45ccaf0,0,1,8ad9d447,b0,...) at sched_switch+0x43b --More-- mi_switch(1,0,c45ccaf0,c45c2828,e675fbc4,...) at mi_switch+0x146 sleepq_switch(c45ccaf0,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c45ccaf0,e675fc08,c07a8857,c445ab9a,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c445ab9a,58,c0b54014,d6,0,...) at sleepq_wait_sig+0xd _sleep(c445ab9a,c0c89198,158,c0b64515,0,...) at _sleep+0x2c7 kern_accept(c45ccaf0,0,e675fc70,e675fc6c,e675fc68,...) at kern_accept+0x168 accept(c45ccaf0,e675fcfc,c,e675fd38,e675fd2c,...) at accept+0x8f syscall(e675fd38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (30, FreeBSD ELF32, accept), eip = 0x2857a66f, esp = 0xbfbecb5c, ebp = 0xbfbfcc38 --- Tracing command php-cgi pid 1402 tid 100095 td 0xc45ccd20 sched_switch(c45ccd20,0,1,88eacfa0,b0,...) at sched_switch+0x43b mi_switch(1,0,c45ccd20,c45c2ae0,e675cbc4,...) at mi_switch+0x146 sleepq_switch(c45ccd20,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c45ccd20,e675cc08,c07a8857,c445ab9a,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c445ab9a,58,c0b54014,d6,0,...) at sleepq_wait_sig+0xd _sleep(c445ab9a,c0c89198,158,c0b64515,0,...) at _sleep+0x2c7 kern_accept(c45ccd20,0,e675cc70,e675cc6c,e675cc68,...) at kern_accept+0x168 accept(c45ccd20,e675ccfc,c,e675cd38,e675cd2c,...) at accept+0x8f --More-- syscall(e675cd38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (30, FreeBSD ELF32, accept), eip = 0x2857a66f, esp = 0xbfbecb5c, ebp = 0xbfbfcc38 --- Tracing command php-cgi pid 1401 tid 100094 td 0xc45ce000 sched_switch(c45ce000,0,1,88dcdf13,b0,...) at sched_switch+0x43b mi_switch(1,0,c45ce000,c45c3000,e6759bc4,...) at mi_switch+0x146 sleepq_switch(c45ce000,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c45ce000,e6759c08,c07a8857,c445ab9a,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c445ab9a,58,c0b54014,d6,0,...) at sleepq_wait_sig+0xd _sleep(c445ab9a,c0c89198,158,c0b64515,0,...) at _sleep+0x2c7 kern_accept(c45ce000,0,e6759c70,e6759c6c,e6759c68,...) at kern_accept+0x168 accept(c45ce000,e6759cfc,c,e6759d38,e6759d2c,...) at accept+0x8f syscall(e6759d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (30, FreeBSD ELF32, accept), eip = 0x2857a66f, esp = 0xbfbecb5c, ebp = 0xbfbfcc38 --- Tracing command php-cgi pid 1400 tid 100093 td 0xc45ce230 sched_switch(c45ce230,0,1,88cf2da4,b0,...) at sched_switch+0x43b mi_switch(1,0,c45ce230,c45c32b8,e6756bc4,...) at mi_switch+0x146 --More-- sleepq_switch(c45ce230,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c45ce230,e6756c08,c07a8857,c445ab9a,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c445ab9a,58,c0b54014,d6,0,...) at sleepq_wait_sig+0xd _sleep(c445ab9a,c0c89198,158,c0b64515,0,...) at _sleep+0x2c7 kern_accept(c45ce230,0,e6756c70,e6756c6c,e6756c68,...) at kern_accept+0x168 accept(c45ce230,e6756cfc,c,e6756d38,e6756d2c,...) at accept+0x8f syscall(e6756d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (30, FreeBSD ELF32, accept), eip = 0x2857a66f, esp = 0xbfbecb5c, ebp = 0xbfbfcc38 --- Tracing command php-cgi pid 1399 tid 100092 td 0xc45ce460 sched_switch(c45ce460,0,1,88c1713f,b0,...) at sched_switch+0x43b mi_switch(1,0,c45ce460,c45c3570,e6753bc4,...) at mi_switch+0x146 sleepq_switch(c45ce460,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c45ce460,e6753c08,c07a8857,c445ab9a,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c445ab9a,58,c0b54014,d6,0,...) at sleepq_wait_sig+0xd _sleep(c445ab9a,c0c89198,158,c0b64515,0,...) at _sleep+0x2c7 kern_accept(c45ce460,0,e6753c70,e6753c6c,e6753c68,...) at kern_accept+0x168 accept(c45ce460,e6753cfc,c,e6753d38,e6753d2c,...) at accept+0x8f syscall(e6753d38) at syscall+0x335 --More-- Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (30, FreeBSD ELF32, accept), eip = 0x2857a66f, esp = 0xbfbecb5c, ebp = 0xbfbfcc38 --- Tracing command php-cgi pid 1398 tid 100091 td 0xc4570000 sched_switch(c4570000,0,1,88b36380,b0,...) at sched_switch+0x43b mi_switch(1,0,c4570000,c45c3828,e6750bc4,...) at mi_switch+0x146 sleepq_switch(c4570000,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c4570000,e6750c08,c07a8857,c445ab9a,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c445ab9a,58,c0b54014,d6,0,...) at sleepq_wait_sig+0xd _sleep(c445ab9a,c0c89198,158,c0b64515,0,...) at _sleep+0x2c7 kern_accept(c4570000,0,e6750c70,e6750c6c,e6750c68,...) at kern_accept+0x168 accept(c4570000,e6750cfc,c,e6750d38,e6750d2c,...) at accept+0x8f syscall(e6750d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (30, FreeBSD ELF32, accept), eip = 0x2857a66f, esp = 0xbfbecb5c, ebp = 0xbfbfcc38 --- Tracing command php-cgi pid 1397 tid 100090 td 0xc4570230 sched_switch(c4570230,0,1,8b0a85e0,b0,...) at sched_switch+0x43b mi_switch(1,0,c4570230,c45c3ae0,e674dbc4,...) at mi_switch+0x146 sleepq_switch(c4570230,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb --More-- sleepq_catch_signals(0,c4570230,e674dc08,c07a8857,c445ab9a,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c445ab9a,58,c0b54014,d6,0,...) at sleepq_wait_sig+0xd _sleep(c445ab9a,c0c89198,158,c0b64515,0,...) at _sleep+0x2c7 kern_accept(c4570230,0,e674dc70,e674dc6c,e674dc68,...) at kern_accept+0x168 accept(c4570230,e674dcfc,c,e674dd38,e674dd2c,...) at accept+0x8f syscall(e674dd38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (30, FreeBSD ELF32, accept), eip = 0x2857a66f, esp = 0xbfbecb5c, ebp = 0xbfbfcc38 --- Tracing command php-cgi pid 1396 tid 100085 td 0xc4570d20 sched_switch(c4570d20,0,1,889d2d05,b0,...) at sched_switch+0x43b mi_switch(1,0,c4570d20,c43be828,e6735bc4,...) at mi_switch+0x146 sleepq_switch(c4570d20,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c4570d20,e6735c08,c07a8857,c445ab9a,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c445ab9a,58,c0b54014,d6,0,...) at sleepq_wait_sig+0xd _sleep(c445ab9a,c0c89198,158,c0b64515,0,...) at _sleep+0x2c7 kern_accept(c4570d20,0,e6735c70,e6735c6c,e6735c68,...) at kern_accept+0x168 accept(c4570d20,e6735cfc,c,e6735d38,e6735d2c,...) at accept+0x8f syscall(e6735d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --More-- --- syscall (30, FreeBSD ELF32, accept), eip = 0x2857a66f, esp = 0xbfbecb5c, ebp = 0xbfbfcc38 --- Tracing command php-cgi pid 1395 tid 100082 td 0xc4571460 sched_switch(c4571460,0,1,888f28b4,b0,...) at sched_switch+0x43b mi_switch(1,0,c4571460,c45652b8,e6729bc4,...) at mi_switch+0x146 sleepq_switch(c4571460,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c4571460,e6729c08,c07a8857,c445ab9a,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c445ab9a,58,c0b54014,d6,0,...) at sleepq_wait_sig+0xd _sleep(c445ab9a,c0c89198,158,c0b64515,0,...) at _sleep+0x2c7 kern_accept(c4571460,0,e6729c70,e6729c6c,e6729c68,...) at kern_accept+0x168 accept(c4571460,e6729cfc,c,e6729d38,e6729d2c,...) at accept+0x8f syscall(e6729d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (30, FreeBSD ELF32, accept), eip = 0x2857a66f, esp = 0xbfbecb5c, ebp = 0xbfbfcc38 --- Tracing command php-cgi pid 1394 tid 100081 td 0xc4571690 sched_switch(c4571690,0,1,88818577,b0,...) at sched_switch+0x43b mi_switch(1,0,c4571690,c4565570,e6725bc4,...) at mi_switch+0x146 sleepq_switch(c4571690,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c4571690,e6725c08,c07a8857,c445ab9a,...) at sleepq_catch_signals+0x2fc --More-- sleepq_wait_sig(c445ab9a,58,c0b54014,d6,0,...) at sleepq_wait_sig+0xd _sleep(c445ab9a,c0c89198,158,c0b64515,0,...) at _sleep+0x2c7 kern_accept(c4571690,0,e6725c70,e6725c6c,e6725c68,...) at kern_accept+0x168 accept(c4571690,e6725cfc,c,e6725d38,e6725d2c,...) at accept+0x8f syscall(e6725d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (30, FreeBSD ELF32, accept), eip = 0x2857a66f, esp = 0xbfbecb5c, ebp = 0xbfbfcc38 --- Tracing command php-cgi pid 1393 tid 100056 td 0xc439f000 sched_switch(c439f000,0,1,89c1bbfb,b0,...) at sched_switch+0x43b mi_switch(1,0,c439f000,c43bd570,e66d4bc4,...) at mi_switch+0x146 sleepq_switch(c439f000,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c439f000,e66d4c08,c07a8857,c445a1da,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c445a1da,58,c0b54014,d6,0,...) at sleepq_wait_sig+0xd _sleep(c445a1da,c0c89198,158,c0b64515,0,...) at _sleep+0x2c7 kern_accept(c439f000,0,e66d4c70,e66d4c6c,e66d4c68,...) at kern_accept+0x168 accept(c439f000,e66d4cfc,c,e66d4d38,e66d4d2c,...) at accept+0x8f syscall(e66d4d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (30, FreeBSD ELF32, accept), eip = 0x2857a66f, esp = 0xbfbecb5c, ebp = 0xbfbfcc38 --- --More-- Tracing command php-cgi pid 1392 tid 100062 td 0xc41a7230 sched_switch(c41a7230,0,1,89b36c55,b0,...) at sched_switch+0x43b mi_switch(1,0,c41a7230,c43432b8,e66e6bc4,...) at mi_switch+0x146 sleepq_switch(c41a7230,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c41a7230,e66e6c08,c07a8857,c445a1da,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c445a1da,58,c0b54014,d6,0,...) at sleepq_wait_sig+0xd _sleep(c445a1da,c0c89198,158,c0b64515,0,...) at _sleep+0x2c7 kern_accept(c41a7230,0,e66e6c70,e66e6c6c,e66e6c68,...) at kern_accept+0x168 accept(c41a7230,e66e6cfc,c,e66e6d38,e66e6d2c,...) at accept+0x8f syscall(e66e6d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (30, FreeBSD ELF32, accept), eip = 0x2857a66f, esp = 0xbfbecb5c, ebp = 0xbfbfcc38 --- Tracing command php-cgi pid 1391 tid 100074 td 0xc44f7460 sched_switch(c44f7460,0,1,8932b788,b0,...) at sched_switch+0x43b mi_switch(1,0,c44f7460,c4566ae0,e670abc4,...) at mi_switch+0x146 sleepq_switch(c44f7460,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c44f7460,e670ac08,c07a8857,c445a1da,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c445a1da,58,c0b54014,d6,0,...) at sleepq_wait_sig+0xd --More-- _sleep(c445a1da,c0c89198,158,c0b64515,0,...) at _sleep+0x2c7 kern_accept(c44f7460,0,e670ac70,e670ac6c,e670ac68,...) at kern_accept+0x168 accept(c44f7460,e670acfc,c,e670ad38,e670ad2c,...) at accept+0x8f syscall(e670ad38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (30, FreeBSD ELF32, accept), eip = 0x2857a66f, esp = 0xbfbecb5c, ebp = 0xbfbfcc38 --- Tracing command php-cgi pid 1390 tid 100061 td 0xc41a7460 sched_switch(c41a7460,0,1,892518bd,b0,...) at sched_switch+0x43b mi_switch(1,0,c41a7460,c4343570,e66e3bc4,...) at mi_switch+0x146 sleepq_switch(c41a7460,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c41a7460,e66e3c08,c07a8857,c445a1da,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c445a1da,58,c0b54014,d6,0,...) at sleepq_wait_sig+0xd _sleep(c445a1da,c0c89198,158,c0b64515,0,...) at _sleep+0x2c7 kern_accept(c41a7460,0,e66e3c70,e66e3c6c,e66e3c68,...) at kern_accept+0x168 accept(c41a7460,e66e3cfc,c,e66e3d38,e66e3d2c,...) at accept+0x8f syscall(e66e3d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (30, FreeBSD ELF32, accept), eip = 0x2857a66f, esp = 0xbfbecb5c, ebp = 0xbfbfcc38 --- --More-- Tracing command php-cgi pid 1389 tid 100076 td 0xc44f7000 sched_switch(c44f7000,0,1,8914eaac,b0,...) at sched_switch+0x43b mi_switch(1,0,c44f7000,c4566570,e6711bc4,...) at mi_switch+0x146 sleepq_switch(c44f7000,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c44f7000,e6711c08,c07a8857,c445a1da,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c445a1da,58,c0b54014,d6,0,...) at sleepq_wait_sig+0xd _sleep(c445a1da,c0c89198,158,c0b64515,0,...) at _sleep+0x2c7 kern_accept(c44f7000,0,e6711c70,e6711c6c,e6711c68,...) at kern_accept+0x168 accept(c44f7000,e6711cfc,c,e6711d38,e6711d2c,...) at accept+0x8f syscall(e6711d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (30, FreeBSD ELF32, accept), eip = 0x2857a66f, esp = 0xbfbecb5c, ebp = 0xbfbfcc38 --- Tracing command php-cgi pid 1388 tid 100075 td 0xc44f7230 sched_switch(c44f7230,0,1,89076543,b0,...) at sched_switch+0x43b mi_switch(1,0,c44f7230,c4566828,e670dbc4,...) at mi_switch+0x146 sleepq_switch(c44f7230,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c44f7230,e670dc08,c07a8857,c445a1da,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c445a1da,58,c0b54014,d6,0,...) at sleepq_wait_sig+0xd _sleep(c445a1da,c0c89198,158,c0b64515,0,...) at _sleep+0x2c7 --More-- kern_accept(c44f7230,0,e670dc70,e670dc6c,e670dc68,...) at kern_accept+0x168 accept(c44f7230,e670dcfc,c,e670dd38,e670dd2c,...) at accept+0x8f syscall(e670dd38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (30, FreeBSD ELF32, accept), eip = 0x2857a66f, esp = 0xbfbecb5c, ebp = 0xbfbfcc38 --- Tracing command php-cgi pid 1387 tid 100079 td 0xc4571af0 sched_switch(c4571af0,0,1,88f9ff91,b0,...) at sched_switch+0x43b mi_switch(1,0,c4571af0,c4565ae0,e671dbc4,...) at mi_switch+0x146 sleepq_switch(c4571af0,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c4571af0,e671dc08,c07a8857,c445a1da,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c445a1da,58,c0b54014,d6,0,...) at sleepq_wait_sig+0xd _sleep(c445a1da,c0c89198,158,c0b64515,0,...) at _sleep+0x2c7 kern_accept(c4571af0,0,e671dc70,e671dc6c,e671dc68,...) at kern_accept+0x168 accept(c4571af0,e671dcfc,c,e671dd38,e671dd2c,...) at accept+0x8f syscall(e671dd38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (30, FreeBSD ELF32, accept), eip = 0x2857a66f, esp = 0xbfbecb5c, ebp = 0xbfbfcc38 --- Tracing command php-cgi pid 1386 tid 100080 td 0xc45718c0 --More-- sched_switch(c45718c0,0,2,74676e16,c1,...) at sched_switch+0x43b mi_switch(2,0,c0b56762,ec,bfbecb60,...) at mi_switch+0x146 ast(e6721d38) at ast+0x2ad doreti_ast() at doreti_ast+0x17 Tracing command sendmail pid 1322 tid 100077 td 0xc4572000 sched_switch(c4572000,0,1,623e3053,af,...) at sched_switch+0x43b mi_switch(1,0,c4572000,c45662b8,e6715bd8,...) at mi_switch+0x146 sleepq_switch(c4572000,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c4572000,e6715c1c,c07a8857,c4566318,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c4566318,68,c0b54014,d6,0,...) at sleepq_wait_sig+0xd _sleep(c4566318,c4566348,168,c0b1883d,0,...) at _sleep+0x2c7 kern_sigsuspend(c4572000,0,0,0,0,...) at kern_sigsuspend+0x107 sigsuspend(c4572000,e6715cfc,4,e6715d38,e6715d2c,...) at sigsuspend+0x4d syscall(e6715d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (341, FreeBSD ELF32, sigsuspend), eip = 0x2830f5cb, esp = 0xbfbfdaac, ebp = 0xbfbfdad8 --- Tracing command sendmail pid 1314 tid 100084 td 0xc4571000 sched_switch(c4571000,0,1,6376cced,c1,...) at sched_switch+0x43b --More-- mi_switch(1,0,c4571000,c43beae0,e6731a80,...) at mi_switch+0x146 sleepq_switch(c4571000,0,c0b5647e,19d,e6731a70,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c4571000,0,e6731ac4,c0761c10,...) at sleepq_catch_signals+0x2fc sleepq_timedwait_sig(c0c88eb8,1389,c0b695ef,101,0,...) at sleepq_timedwait_sig+0x19 _cv_timedwait_sig(c0c88eb8,c0c88ea0,1389,30a,c1472d34,...) at _cv_timedwait_sig+0x190 kern_select(c4571000,4,bfbfd8bc,0,0,e6731c70,5,0) at kern_select+0x7cf select(c4571000,e6731cfc,14,16,e6731d2c,...) at select+0x5e syscall(e6731d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x283a5903, esp = 0xbfbfd02c, ebp = 0xbfbfdac8 --- Tracing command sshd pid 1306 tid 100078 td 0xc4571d20 sched_switch(c4571d20,0,1,b556df22,ae,...) at sched_switch+0x43b mi_switch(1,0,c4571d20,c4566000,e6719a84,...) at mi_switch+0x146 sleepq_switch(c4571d20,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c4571d20,e6719ac4,c0762080,c0c88eb8,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c0c88eb8,c0c88ea0,c0b695ef,101,0,...) at sleepq_wait_sig+0xd _cv_wait_sig(c0c88eb8,c0c88ea0,c0b569cc,30a,e6719ae8,...) at _cv_wait_sig+0x180 kern_select(c4571d20,4,285090ac,0,0,0,c4566000,e6719c98) at kern_select+0x7e7 select(c4571d20,e6719cfc,14,e6719d38,e6719d2c,...) at select+0x5e --More-- syscall(e6719d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x28391903, esp = 0xbfbfe63c, ebp = 0xbfbfee28 --- Tracing command php-cgi pid 1301 tid 100073 td 0xc44f7690 sched_switch(c44f7690,0,1,8ac8ad13,b0,...) at sched_switch+0x43b mi_switch(1,0,c44f7690,c4567000,e6707b90,...) at mi_switch+0x146 sleepq_switch(c44f7690,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c44f7690,e6707bd4,c07a8857,c4567000,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c4567000,5c,c0b54014,d6,0,...) at sleepq_wait_sig+0xd _sleep(c4567000,c4567090,15c,c0b53aa3,0,...) at _sleep+0x2c7 kern_wait(c44f7690,ffffffff,e6707c2c,0,0,...) at kern_wait+0xf98 wait4(c44f7690,e6707cfc,10,e6707d38,e6707d2c,...) at wait4+0x3b syscall(e6707d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (7, FreeBSD ELF32, wait4), eip = 0x2855d58b, esp = 0xbfbfcc1c, ebp = 0xbfbfcc38 --- Tracing command php-cgi pid 1292 tid 100049 td 0xc4074690 sched_switch(c4074690,0,1,8b3f6013,b0,...) at sched_switch+0x43b mi_switch(1,0,c4074690,c433f2b8,e66afb90,...) at mi_switch+0x146 --More-- sleepq_switch(c4074690,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c4074690,e66afbd4,c07a8857,c433f2b8,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c433f2b8,5c,c0b54014,d6,0,...) at sleepq_wait_sig+0xd _sleep(c433f2b8,c433f348,15c,c0b53aa3,0,...) at _sleep+0x2c7 kern_wait(c4074690,ffffffff,e66afc2c,0,0,...) at kern_wait+0xf98 wait4(c4074690,e66afcfc,10,e66afd38,e66afd2c,...) at wait4+0x3b syscall(e66afd38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (7, FreeBSD ELF32, wait4), eip = 0x2855d58b, esp = 0xbfbfcc1c, ebp = 0xbfbfcc38 --- Tracing command lighttpd pid 1288 tid 100058 td 0xc41a7af0 kdb_enter_why(c0b11901,c0b2827a,0,e66daae0,c07bf27a,...) at kdb_enter_why+0x3a hardclock(0,c07fedf3,0,0,0,...) at hardclock+0x20d lapic_handle_timer(e66dab08) at lapic_handle_timer+0x9c Xtimerint() at Xtimerint+0x1f --- interrupt, eip = 0xc07fedf3, esp = 0xe66dab48, ebp = 0xe66dac34 --- kern_sendfile(c41a7af0,e66dacfc,0,0,0,...) at kern_sendfile+0x463 do_sendfile(e66dad2c,c0aba265,c41a7af0,e66dacfc,20,...) at do_sendfile+0xb1 sendfile(c41a7af0,e66dacfc,20,16,e66dad2c,...) at sendfile+0x13 syscall(e66dad38) at syscall+0x335 --More-- Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (393, FreeBSD ELF32, sendfile), eip = 0x282cb0cb, esp = 0xbfbfc7cc, ebp = 0xbfbfe848 --- Tracing command mysqld pid 1286 tid 100114 td 0xc46108c0 sched_switch(c46108c0,0,1,c81a48ed,b0,...) at sched_switch+0x43b mi_switch(1,0,c46108c0,c43be000,e67a2b3c,...) at mi_switch+0x146 sleepq_switch(c46108c0,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c46108c0,e67a2b80,c07a8857,e67a2be0,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(e67a2be0,68,c0b54014,d6,0,...) at sleepq_wait_sig+0xd _sleep(e67a2be0,c43be090,168,c0b51a46,0,...) at _sleep+0x2c7 kern_sigtimedwait(c46108c0,26005,0,0,0,...) at kern_sigtimedwait+0x358 sigwait(c46108c0,e67a2cfc,8,0,0,...) at sigwait+0x77 syscall(e67a2d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (429, FreeBSD ELF32, sigwait), eip = 0x286e8d8b, esp = 0xbf1f6f0c, ebp = 0xbf1f6f38 --- Tracing command mysqld pid 1286 tid 100111 td 0xc4610af0 sched_switch(c4610af0,0,1,5c635c09,b1,...) at sched_switch+0x43b mi_switch(1,0,c4610af0,c43be000,e6799bd0,...) at mi_switch+0x146 sleepq_switch(c4610af0,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb --More-- sleepq_catch_signals(0,c4610af0,e6799c14,c07a8857,c43583c0,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c43583c0,c0c7eaf8,c0b5472e,100,0,...) at sleepq_wait_sig+0xd _sleep(c43583c0,c0c7eaf8,100,c0b5472e,0,...) at _sleep+0x2c7 __umtx_op_cv_wait(c4610af0,e6799cfc,e6799d2c,c0aba265,c4610af0,...) at __umtx_op_cv_wait+0x3c4 _umtx_op(c4610af0,e6799cfc,14,e6799d38,e6799d2c,...) at _umtx_op+0x27 syscall(e6799d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (454, FreeBSD ELF32, _umtx_op), eip = 0x286a0037, esp = 0xbf2f7e8c, ebp = 0xbf2f7ea8 --- Tracing command mysqld pid 1286 tid 100113 td 0xc4610d20 sched_switch(c4610d20,0,1,35985de5,c1,...) at sched_switch+0x43b mi_switch(1,0,c4610d20,c43be000,e679fa80,...) at mi_switch+0x146 sleepq_switch(c4610d20,0,c0b5647e,19d,e679fa70,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c4610d20,0,e679fac4,c0761c10,...) at sleepq_catch_signals+0x2fc sleepq_timedwait_sig(c0c88eb8,3e9,c0b695ef,101,0,...) at sleepq_timedwait_sig+0x19 _cv_timedwait_sig(c0c88eb8,c0c88ea0,3e9,30a,0,...) at _cv_timedwait_sig+0x190 kern_select(c4610d20,0,0,0,0,e679fc70,1,0) at kern_select+0x7cf select(c4610d20,e679fcfc,14,16,e679fd2c,...) at select+0x5e syscall(e679fd38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --More-- --- syscall (93, FreeBSD ELF32, select), eip = 0x2877f903, esp = 0xbf3f8efc, ebp = 0xbf3f8f28 --- Tracing command mysqld pid 1286 tid 100112 td 0xc4612000 sched_switch(c4612000,0,1,358b6bb2,c1,...) at sched_switch+0x43b mi_switch(1,0,c4612000,c43be000,e679ca80,...) at mi_switch+0x146 sleepq_switch(c4612000,0,c0b5647e,19d,e679ca70,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c4612000,0,e679cac4,c0761c10,...) at sleepq_catch_signals+0x2fc sleepq_timedwait_sig(c0c88eb8,3e9,c0b695ef,101,0,...) at sleepq_timedwait_sig+0x19 _cv_timedwait_sig(c0c88eb8,c0c88ea0,3e9,30a,1223d7,...) at _cv_timedwait_sig+0x190 kern_select(c4612000,0,0,0,0,e679cc70,1,0) at kern_select+0x7cf select(c4612000,e679ccfc,14,16,e679cd2c,...) at select+0x5e syscall(e679cd38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x2877f903, esp = 0xbf4f9efc, ebp = 0xbf4f9f28 --- Tracing command mysqld pid 1286 tid 100089 td 0xc4570460 sched_switch(c4570460,0,1,d59abff1,af,...) at sched_switch+0x43b mi_switch(1,0,c4570460,c43be000,e674abd0,...) at mi_switch+0x146 sleepq_switch(c4570460,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c4570460,e674ac14,c07a8857,c43576c0,...) at sleepq_catch_signals+0x2fc --More-- sleepq_wait_sig(c43576c0,c0c7de80,c0b5472e,100,0,...) at sleepq_wait_sig+0xd _sleep(c43576c0,c0c7de80,100,c0b5472e,0,...) at _sleep+0x2c7 __umtx_op_cv_wait(c4570460,e674acfc,e674ad2c,c0aba265,c4570460,...) at __umtx_op_cv_wait+0x3c4 _umtx_op(c4570460,e674acfc,14,62696c2f,7173796d,...) at _umtx_op+0x27 syscall(e674ad38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (454, FreeBSD ELF32, _umtx_op), eip = 0x286a0037, esp = 0xbf6fbcdc, ebp = 0xbf6fbcf8 --- Tracing command mysqld pid 1286 tid 100088 td 0xc4570690 sched_switch(c4570690,0,1,9a3c1adb,b0,...) at sched_switch+0x43b mi_switch(1,0,c4570690,c43be000,e6747bd0,...) at mi_switch+0x146 sleepq_switch(c4570690,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c4570690,e6747c14,c07a8857,c41b13c0,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c41b13c0,c0c7f770,c0b5472e,100,0,...) at sleepq_wait_sig+0xd _sleep(c41b13c0,c0c7f770,100,c0b5472e,0,...) at _sleep+0x2c7 __umtx_op_cv_wait(c4570690,e6747cfc,e6747d2c,c0aba265,c4570690,...) at __umtx_op_cv_wait+0x3c4 _umtx_op(c4570690,e6747cfc,14,e6747d38,e6747d2c,...) at _umtx_op+0x27 syscall(e6747d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (454, FreeBSD ELF32, _umtx_op), eip = 0x286a0037, esp = 0xbf7fccdc, ebp = 0xbf7fccf8 --- --More-- Tracing command mysqld pid 1286 tid 100087 td 0xc45708c0 sched_switch(c45708c0,0,1,9d6bde01,b0,...) at sched_switch+0x43b mi_switch(1,0,c45708c0,c43be000,e6744bd0,...) at mi_switch+0x146 sleepq_switch(c45708c0,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c45708c0,e6744c14,c07a8857,c43587c0,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c43587c0,c0c7f818,c0b5472e,100,0,...) at sleepq_wait_sig+0xd _sleep(c43587c0,c0c7f818,100,c0b5472e,0,...) at _sleep+0x2c7 __umtx_op_cv_wait(c45708c0,e6744cfc,e6744d2c,c0aba265,c45708c0,...) at __umtx_op_cv_wait+0x3c4 _umtx_op(c45708c0,e6744cfc,14,16,e6744d2c,...) at _umtx_op+0x27 syscall(e6744d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (454, FreeBSD ELF32, _umtx_op), eip = 0x286a0037, esp = 0xbf8fdcdc, ebp = 0xbf8fdcf8 --- Tracing command mysqld pid 1286 tid 100086 td 0xc4570af0 sched_switch(c4570af0,0,1,d5985c82,af,...) at sched_switch+0x43b mi_switch(1,0,c4570af0,c43be000,e6741bd0,...) at mi_switch+0x146 sleepq_switch(c4570af0,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c4570af0,e6741c14,c07a8857,c4357a80,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c4357a80,c0c7f508,c0b5472e,100,0,...) at sleepq_wait_sig+0xd --More-- _sleep(c4357a80,c0c7f508,100,c0b5472e,0,...) at _sleep+0x2c7 __umtx_op_cv_wait(c4570af0,e6741cfc,e6741d2c,c0aba265,c4570af0,...) at __umtx_op_cv_wait+0x3c4 _umtx_op(c4570af0,e6741cfc,14,0,0,...) at _umtx_op+0x27 syscall(e6741d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (454, FreeBSD ELF32, _umtx_op), eip = 0x286a0037, esp = 0xbf9fecdc, ebp = 0xbf9fecf8 --- Tracing command mysqld pid 1286 tid 100053 td 0xc439f690 sched_switch(c439f690,0,1,347ac8ca,b1,...) at sched_switch+0x43b mi_switch(1,0,c439f690,c43be000,e66cba84,...) at mi_switch+0x146 sleepq_switch(c439f690,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c439f690,e66cbac4,c0762080,c0c88eb8,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c0c88eb8,c0c88ea0,c0b695ef,101,0,...) at sleepq_wait_sig+0xd _cv_wait_sig(c0c88eb8,c0c88ea0,c0b569cc,30a,e66cbafc,...) at _cv_wait_sig+0x180 kern_select(c439f690,f,bfbfea58,0,0,0,0,0) at kern_select+0x7e7 select(c439f690,e66cbcfc,14,e66cbd38,e66cbd2c,...) at select+0x5e syscall(e66cbd38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x2877f903, esp = 0xbfbfe62c, ebp = 0xbfbfe658 --- --More-- Tracing command sh pid 1173 tid 100052 td 0xc439f8c0 sched_switch(c439f8c0,0,1,2e2cbfba,ad,...) at sched_switch+0x43b mi_switch(1,0,c439f8c0,c43be2b8,e66c8b90,...) at mi_switch+0x146 sleepq_switch(c439f8c0,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c439f8c0,e66c8bd4,c07a8857,c43be2b8,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c43be2b8,5c,c0b54014,d6,0,...) at sleepq_wait_sig+0xd _sleep(c43be2b8,c43be348,15c,c0b53aa3,0,...) at _sleep+0x2c7 kern_wait(c439f8c0,ffffffff,e66c8c2c,2,0,...) at kern_wait+0xf98 wait4(c439f8c0,e66c8cfc,10,e66c8d38,e66c8d2c,...) at wait4+0x3b syscall(e66c8d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (7, FreeBSD ELF32, wait4), eip = 0x2814658b, esp = 0xbfbfe50c, ebp = 0xbfbfe528 --- Tracing command venti pid 920 tid 100072 td 0xc44f78c0 sched_switch(c44f78c0,0,1,de387c47,aa,...) at sched_switch+0x43b mi_switch(1,0,c44f78c0,c43be570,e6704bd0,...) at mi_switch+0x146 sleepq_switch(c44f78c0,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c44f78c0,e6704c14,c07a8857,c4357300,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c4357300,c0c7e0b0,c0b5472e,100,0,...) at sleepq_wait_sig+0xd _sleep(c4357300,c0c7e0b0,100,c0b5472e,0,...) at _sleep+0x2c7 --More-- __umtx_op_cv_wait(c44f78c0,e6704cfc,e6704d2c,c0aba265,c44f78c0,...) at __umtx_op_cv_wait+0x3c4 _umtx_op(c44f78c0,e6704cfc,14,e6704d38,e6704d2c,...) at _umtx_op+0x27 syscall(e6704d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (454, FreeBSD ELF32, _umtx_op), eip = 0x280f1037, esp = 0xbf0f5e9c, ebp = 0xbf0f5eb8 --- Tracing command venti pid 920 tid 100071 td 0xc44f7af0 sched_switch(c44f7af0,0,1,de36989b,aa,...) at sched_switch+0x43b mi_switch(1,0,c44f7af0,c43be570,e6701bc4,...) at mi_switch+0x146 sleepq_switch(c44f7af0,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c44f7af0,e6701c08,c07a8857,c445b03a,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c445b03a,58,c0b54014,d6,0,...) at sleepq_wait_sig+0xd _sleep(c445b03a,c0c89198,158,c0b64515,0,...) at _sleep+0x2c7 kern_accept(c44f7af0,7,0,0,0,...) at kern_accept+0x168 accept(c44f7af0,e6701cfc,c,28159000,0,...) at accept+0x41 syscall(e6701d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (30, FreeBSD ELF32, accept), eip = 0x2816d66f, esp = 0x377d33fc, ebp = 0x377d3418 --- Tracing command venti pid 920 tid 100070 td 0xc44f7d20 --More-- sched_switch(c44f7d20,0,1,de357794,aa,...) at sched_switch+0x43b mi_switch(1,0,c44f7d20,c43be570,e66febd0,...) at mi_switch+0x146 sleepq_switch(c44f7d20,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c44f7d20,e66fec14,c07a8857,c41b0040,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c41b0040,c0c7ddd8,c0b5472e,100,0,...) at sleepq_wait_sig+0xd _sleep(c41b0040,c0c7ddd8,100,c0b5472e,0,...) at _sleep+0x2c7 __umtx_op_cv_wait(c44f7d20,e66fecfc,e66fed2c,c0aba265,c44f7d20,...) at __umtx_op_cv_wait+0x3c4 _umtx_op(c44f7d20,e66fecfc,14,e66fed38,e66fed2c,...) at _umtx_op+0x27 syscall(e66fed38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (454, FreeBSD ELF32, _umtx_op), eip = 0x280f1037, esp = 0xbf2f7e9c, ebp = 0xbf2f7eb8 --- Tracing command venti pid 920 tid 100069 td 0xc44f8000 sched_switch(c44f8000,0,1,7e57a54,a6,...) at sched_switch+0x43b mi_switch(1,0,c44f8000,c43be570,e66fbbd0,...) at mi_switch+0x146 sleepq_switch(c44f8000,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c44f8000,e66fbc14,c07a8857,c4095980,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c4095980,c0c7e708,c0b5472e,100,0,...) at sleepq_wait_sig+0xd _sleep(c4095980,c0c7e708,100,c0b5472e,0,...) at _sleep+0x2c7 __umtx_op_cv_wait(c44f8000,e66fbcfc,e66fbd2c,c0aba265,c44f8000,...) at __umtx_op_cv_wait+0x3c4 --More-- _umtx_op(c44f8000,e66fbcfc,14,0,0,...) at _umtx_op+0x27 syscall(e66fbd38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (454, FreeBSD ELF32, _umtx_op), eip = 0x280f1037, esp = 0xbf3f8e9c, ebp = 0xbf3f8eb8 --- Tracing command venti pid 920 tid 100068 td 0xc44f8230 sched_switch(c44f8230,0,1,de4f59f5,aa,...) at sched_switch+0x43b mi_switch(1,0,c44f8230,c43be570,e66f8bd0,...) at mi_switch+0x146 sleepq_switch(c44f8230,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c44f8230,e66f8c14,c07a8857,c4357140,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c4357140,c0c7f038,c0b5472e,100,0,...) at sleepq_wait_sig+0xd _sleep(c4357140,c0c7f038,100,c0b5472e,0,...) at _sleep+0x2c7 __umtx_op_cv_wait(c44f8230,e66f8cfc,e66f8d2c,c0aba265,c44f8230,...) at __umtx_op_cv_wait+0x3c4 _umtx_op(c44f8230,e66f8cfc,14,2,c07bf92b,...) at _umtx_op+0x27 syscall(e66f8d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (454, FreeBSD ELF32, _umtx_op), eip = 0x280f1037, esp = 0xbf4f9e9c, ebp = 0xbf4f9eb8 --- Tracing command venti pid 920 tid 100067 td 0xc44f8460 sched_switch(c44f8460,0,1,d4d327e3,a5,...) at sched_switch+0x43b --More-- mi_switch(1,0,c44f8460,c43be570,e66f5bd0,...) at mi_switch+0x146 sleepq_switch(c44f8460,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c44f8460,e66f5c14,c07a8857,c41b1e00,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c41b1e00,c0c7f5e8,c0b5472e,100,0,...) at sleepq_wait_sig+0xd _sleep(c41b1e00,c0c7f5e8,100,c0b5472e,0,...) at _sleep+0x2c7 __umtx_op_cv_wait(c44f8460,e66f5cfc,e66f5d2c,c0aba265,c44f8460,...) at __umtx_op_cv_wait+0x3c4 _umtx_op(c44f8460,e66f5cfc,14,246,c44f8460,...) at _umtx_op+0x27 syscall(e66f5d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (454, FreeBSD ELF32, _umtx_op), eip = 0x280f1037, esp = 0xbf5fae9c, ebp = 0xbf5faeb8 --- Tracing command venti pid 920 tid 100066 td 0xc44f8690 sched_switch(c44f8690,0,1,d4d20184,a5,...) at sched_switch+0x43b mi_switch(1,0,c44f8690,c43be570,e66f2bd0,...) at mi_switch+0x146 sleepq_switch(c44f8690,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c44f8690,e66f2c14,c07a8857,c4357100,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c4357100,c0c7e660,c0b5472e,100,0,...) at sleepq_wait_sig+0xd _sleep(c4357100,c0c7e660,100,c0b5472e,0,...) at _sleep+0x2c7 __umtx_op_cv_wait(c44f8690,e66f2cfc,e66f2d2c,c0aba265,c44f8690,...) at __umtx_op_cv_wait+0x3c4 _umtx_op(c44f8690,e66f2cfc,14,e66f2d38,e66f2d2c,...) at _umtx_op+0x27 --More-- syscall(e66f2d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (454, FreeBSD ELF32, _umtx_op), eip = 0x280f1037, esp = 0xbf6fbe9c, ebp = 0xbf6fbeb8 --- Tracing command venti pid 920 tid 100065 td 0xc44f88c0 sched_switch(c44f88c0,0,1,eaa9512e,a5,...) at sched_switch+0x43b mi_switch(1,0,c44f88c0,c43be570,e66efbd0,...) at mi_switch+0x146 sleepq_switch(c44f88c0,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c44f88c0,e66efc14,c07a8857,c41a4500,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c41a4500,c0c7ec80,c0b5472e,100,0,...) at sleepq_wait_sig+0xd _sleep(c41a4500,c0c7ec80,100,c0b5472e,0,...) at _sleep+0x2c7 __umtx_op_cv_wait(c44f88c0,e66efcfc,e66efd2c,c0aba265,c44f88c0,...) at __umtx_op_cv_wait+0x3c4 _umtx_op(c44f88c0,e66efcfc,14,e66efd38,e66efd2c,...) at _umtx_op+0x27 syscall(e66efd38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (454, FreeBSD ELF32, _umtx_op), eip = 0x280f1037, esp = 0xbf7fce9c, ebp = 0xbf7fceb8 --- Tracing command venti pid 920 tid 100064 td 0xc44f8af0 sched_switch(c44f8af0,0,1,9daa439d,a5,...) at sched_switch+0x43b mi_switch(1,0,c44f8af0,c43be570,e66ecbc4,...) at mi_switch+0x146 --More-- sleepq_switch(c44f8af0,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c44f8af0,e66ecc08,c07a8857,c445a6ba,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c445a6ba,58,c0b54014,d6,0,...) at sleepq_wait_sig+0xd _sleep(c445a6ba,c0c89198,158,c0b64515,0,...) at _sleep+0x2c7 kern_accept(c44f8af0,5,0,0,0,...) at kern_accept+0x168 accept(c44f8af0,e66eccfc,c,e66ecd38,e66ecd2c,...) at accept+0x41 syscall(e66ecd38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (30, FreeBSD ELF32, accept), eip = 0x2816d66f, esp = 0x29c413dc, ebp = 0x29c413f8 --- Tracing command venti pid 920 tid 100063 td 0xc44f8d20 sched_switch(c44f8d20,0,1,67e06ec1,c1,...) at sched_switch+0x43b mi_switch(1,0,c44f8d20,c43be570,e66e9a80,...) at mi_switch+0x146 sleepq_switch(c44f8d20,0,c0b5647e,19d,e66e9a70,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c44f8d20,0,e66e9ac4,c0761c10,...) at sleepq_catch_signals+0x2fc sleepq_timedwait_sig(c0c88eb8,3e9,c0b695ef,101,0,...) at sleepq_timedwait_sig+0x19 _cv_timedwait_sig(c0c88eb8,c0c88ea0,3e9,30a,0,...) at _cv_timedwait_sig+0x190 kern_select(c44f8d20,0,0,0,0,e66e9c70,1,0) at kern_select+0x7cf select(c44f8d20,e66e9cfc,14,6,c07bf92b,...) at select+0x5e syscall(e66e9d38) at syscall+0x335 --More-- Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x281d0903, esp = 0x2829741c, ebp = 0x28297448 --- Tracing command venti pid 920 tid 100051 td 0xc439faf0 sched_switch(c439faf0,0,1,3b98272d,c1,...) at sched_switch+0x43b mi_switch(1,0,c439faf0,c43be570,e66c5a80,...) at mi_switch+0x146 sleepq_switch(c439faf0,0,c0b5647e,19d,e66c5a70,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c439faf0,0,e66c5ac4,c0761c10,...) at sleepq_catch_signals+0x2fc sleepq_timedwait_sig(c0c88eb8,3e9,c0b695ef,101,0,...) at sleepq_timedwait_sig+0x19 _cv_timedwait_sig(c0c88eb8,c0c88ea0,3e9,30a,c07bee1c,...) at _cv_timedwait_sig+0x190 kern_select(c439faf0,0,0,0,0,e66c5c70,1,0) at kern_select+0x7cf select(c439faf0,e66c5cfc,14,6,c07bf92b,...) at select+0x5e syscall(e66c5d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x281d0903, esp = 0xbfbfed9c, ebp = 0xbfbfedc8 --- Tracing command watchdogd pid 902 tid 100054 td 0xc439f460 sched_switch(c439f460,0,1,824b7df2,c1,...) at sched_switch+0x43b mi_switch(1,0,c439f460,c43bdae0,e66ceb90,...) at mi_switch+0x146 sleepq_switch(c439f460,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb --More-- sleepq_catch_signals(0,c439f460,e66cebd4,c07a8857,c43bdae0,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c43bdae0,5c,c0b54014,d6,0,...) at sleepq_wait_sig+0xd _sleep(c43bdae0,c43bdb70,15c,c0b53aa3,0,...) at _sleep+0x2c7 kern_wait(c439f460,5ec,e66cec2c,0,0,...) at kern_wait+0xf98 wait4(c439f460,e66cecfc,10,e66ced38,e66ced2c,...) at wait4+0x3b syscall(e66ced38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (7, FreeBSD ELF32, wait4), eip = 0x280fc58b, esp = 0xbfbfed0c, ebp = 0xbfbfedb8 --- Tracing command gmond pid 891 tid 100057 td 0xc41a7d20 sched_switch(c41a7d20,0,1,fd4ff264,c0,...) at sched_switch+0x43b mi_switch(1,0,c41a7d20,c43bd2b8,e66d7ad8,...) at mi_switch+0x146 sleepq_switch(c41a7d20,0,c0b5647e,19d,e66d7ac8,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c41a7d20,c4356b00,e66d7b1c,c0761c10,...) at sleepq_catch_signals+0x2fc sleepq_timedwait_sig(c0c88eb8,3b5d,c0b695ef,101,0,...) at sleepq_timedwait_sig+0x19 _cv_timedwait_sig(c0c88eb8,c0c88ea0,3b5d,3b6,c445a050,...) at _cv_timedwait_sig+0x190 poll(c41a7d20,e66d7cfc,c,e66d7cd8,c07abdd8,...) at poll+0x677 syscall(e66d7d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (209, FreeBSD ELF32, poll), eip = 0x28170bbf, esp = 0xbfbfe1ac, ebp = 0xbfbfe1c8 --- --More-- Tracing command devd pid 770 tid 100055 td 0xc439f230 sched_switch(c439f230,0,1,29db3768,a0,...) at sched_switch+0x43b mi_switch(1,0,c439f230,c43bd828,e66d1a84,...) at mi_switch+0x146 sleepq_switch(c439f230,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c439f230,e66d1ac4,c0762080,c0c88eb8,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c0c88eb8,c0c88ea0,c0b695ef,101,0,...) at sleepq_wait_sig+0xd _cv_wait_sig(c0c88eb8,c0c88ea0,c0b569cc,30a,e66d1ae8,...) at _cv_wait_sig+0x180 kern_select(c439f230,5,bfbfedf8,0,0,0,c43bd828,e66d1c98) at kern_select+0x7e7 select(c439f230,e66d1cfc,14,e66d1d38,e66d1d2c,...) at select+0x5e syscall(e66d1d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (93, FreeBSD ELF32, select), eip = 0x8086b3f, esp = 0xbfbfe9bc, ebp = 0xbfbfee98 --- Tracing command dhclient pid 338 tid 100059 td 0xc41a78c0 sched_switch(c41a78c0,0,1,b268fa62,a0,...) at sched_switch+0x43b mi_switch(1,0,c41a78c0,c4343ae0,e66ddad8,...) at mi_switch+0x146 sleepq_switch(c41a78c0,0,c0b5647e,19d,e66ddac8,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c41a78c0,c44b9700,e66ddb1c,c0761c10,...) at sleepq_catch_signals+0x2fc sleepq_timedwait_sig(c0c88eb8,5265c00,c0b695ef,101,0,...) at sleepq_timedwait_sig+0x19 --More-- _cv_timedwait_sig(c0c88eb8,c0c88ea0,5265c00,3b6,0,...) at _cv_timedwait_sig+0x190 poll(c41a78c0,e66ddcfc,c,e66ddd38,e66ddd2c,...) at poll+0x677 syscall(e66ddd38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (209, FreeBSD ELF32, poll), eip = 0x28113bbf, esp = 0xbfbfee1c, ebp = 0xbfbfee48 --- Tracing command dhclient pid 322 tid 100050 td 0xc439fd20 sched_switch(c439fd20,0,1,9000c40a,9e,...) at sched_switch+0x43b mi_switch(1,0,c439fd20,c433f000,e66b3adc,...) at mi_switch+0x146 sleepq_switch(c439fd20,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c439fd20,e66b3b1c,c0762080,c0c88eb8,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c0c88eb8,c0c88ea0,c0b695ef,101,0,...) at sleepq_wait_sig+0xd _cv_wait_sig(c0c88eb8,c0c88ea0,c0b569cc,3b6,c439db8c,...) at _cv_wait_sig+0x180 poll(c439fd20,e66b3cfc,c,6,c07bf92b,...) at poll+0x68d syscall(e66b3d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (209, FreeBSD ELF32, poll), eip = 0x28113bbf, esp = 0xbfbfee1c, ebp = 0xbfbfee48 --- Tracing command softdepflush pid 48 tid 100047 td 0xc4074af0 sched_switch(c4074af0,0,1,c633a526,cb,...) at sched_switch+0x43b --More-- mi_switch(1,0,c4074af0,c4074af0,e44bcc94,...) at mi_switch+0x146 sleepq_switch(c4074af0,0,c0b5647e,266,0,...) at sleepq_switch+0xcb sleepq_timedwait(c0c95228,3e8,c0b6aca8,0,0,...) at sleepq_timedwait+0x37 _sleep(c0c95228,c0c951e8,44,c0b6aca8,3e8,...) at _sleep+0x2b4 softdep_flush(0,e44bcd38,2816fcca,2816ac81,2816a468,...) at softdep_flush+0x3ce fork_exit(c09ae7f0,0,e44bcd38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe44bcd70, ebp = 0 --- Tracing command syncer pid 47 tid 100046 td 0xc4074d20 sched_switch(c4074d20,0,1,345ca9a,cc,...) at sched_switch+0x43b mi_switch(1,0,c4074d20,c4074d20,e44b9c5c,...) at mi_switch+0x146 sleepq_switch(c4074d20,0,c0b5647e,243,0,...) at sleepq_switch+0xcb sleepq_wait(c0c7da6c,0,c0b5a641,0,0,...) at sleepq_wait+0x36 _sleep(c0c7da6c,c0c89604,68,c0b5a641,0,...) at _sleep+0x2d6 sched_sync(0,e44b9d38,0,0,0,...) at sched_sync+0x920 fork_exit(c0822660,0,e44b9d38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe44b9d70, ebp = 0 --- --More-- Tracing command vnlru pid 46 tid 100045 td 0xc41a6000 sched_switch(c41a6000,0,1,c691a970,cb,...) at sched_switch+0x43b mi_switch(1,0,c41a6000,c41a6000,e44b6c58,...) at mi_switch+0x146 sleepq_switch(c41a6000,0,c0b5647e,266,1,...) at sleepq_switch+0xcb sleepq_timedwait(c4342000,3e8,c0b5a688,0,0,...) at sleepq_timedwait+0x37 _sleep(c4342000,c0c895d8,250,c0b5a688,3e8,...) at _sleep+0x2b4 vnlru_proc(0,e44b6d38,48041b00,dc3e0000,8c0b01,...) at vnlru_proc+0x153 fork_exit(c0823830,0,e44b6d38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe44b6d70, ebp = 0 --- Tracing command bufdaemon pid 45 tid 100044 td 0xc41a6230 sched_switch(c41a6230,0,1,c6337a6e,cb,...) at sched_switch+0x43b mi_switch(1,0,c41a6230,c41a6230,e44b3ca0,...) at mi_switch+0x146 sleepq_switch(c41a6230,0,c0b5647e,266,0,...) at sleepq_switch+0xcb sleepq_timedwait(c0c89324,3e8,c0b58cc1,0,0,...) at sleepq_timedwait+0x37 _sleep(c0c89324,c0c89328,44,c0b58cc1,3e8,...) at _sleep+0x2b4 buf_daemon(0,e44b3d38,0,0,0,...) at buf_daemon+0x2fd fork_exit(c080b8b0,0,e44b3d38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 --More-- --- trap 0, eip = 0, esp = 0xe44b3d70, ebp = 0 --- Tracing command pagezero pid 44 tid 100043 td 0xc41a6460 sched_switch(c41a6460,0,1,2d29fc76,34,...) at sched_switch+0x43b mi_switch(1,0,c41a6460,c41a6460,e44b0ca4,...) at mi_switch+0x146 sleepq_switch(c41a6460,0,c0b5647e,266,0,...) at sleepq_switch+0xcb sleepq_timedwait(c0c95e00,493e0,c0b6e221,0,0,...) at sleepq_timedwait+0x37 _sleep(c0c95e00,c0c959a4,0,c0b6e221,493e0,...) at _sleep+0x2b4 vm_pagezero(0,e44b0d38,0,0,0,...) at vm_pagezero+0xd2 fork_exit(c09ebef0,0,e44b0d38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe44b0d70, ebp = 0 --- Tracing command vmdaemon pid 43 tid 100042 td 0xc41a6690 sched_switch(c41a6690,0,1,2d28d181,34,...) at sched_switch+0x43b mi_switch(1,0,c41a6690,c41a6690,e44adc60,...) at mi_switch+0x146 sleepq_switch(c41a6690,0,c0b5647e,243,0,...) at sleepq_switch+0xcb sleepq_wait(c0c95a18,68,c0b54014,d6,0,...) at sleepq_wait+0x36 _sleep(c0c95a18,c0c95a1c,68,c0b58cc1,0,...) at _sleep+0x2d6 vm_daemon(0,e44add38,0,0,0,...) at vm_daemon+0x78 --More-- fork_exit(c09e7a30,0,e44add38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe44add70, ebp = 0 --- Tracing command pagedaemon pid 42 tid 100041 td 0xc41a68c0 sched_switch(c41a68c0,0,1,c6335bbf,cb,...) at sched_switch+0x43b mi_switch(1,0,c41a68c0,c41a68c0,e44aabf0,...) at mi_switch+0x146 sleepq_switch(c41a68c0,0,c0b5647e,266,0,...) at sleepq_switch+0xcb sleepq_timedwait(c0c959e0,1388,c0b58cc1,0,0,...) at sleepq_timedwait+0x37 _sleep(c0c959e0,c0c959a4,44,c0b58cc1,1388,...) at _sleep+0x2b4 vm_pageout(0,e44aad38,f7b9fe29,ffce73be,eea8f39c,...) at vm_pageout+0x2da fork_exit(c09e8140,0,e44aad38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe44aad70, ebp = 0 --- Tracing command sctp_iterator pid 41 tid 100040 td 0xc41a6af0 sched_switch(c41a6af0,0,1,aa6df4fd,9e,...) at sched_switch+0x43b mi_switch(1,0,c41a6af0,c41a6af0,e44a7ca4,...) at mi_switch+0x146 sleepq_switch(c41a6af0,0,c0b5647e,243,0,...) at sleepq_switch+0xcb sleepq_wait(c0c8b0b4,c0c8afbc,c0b5ff3a,0,0,...) at sleepq_wait+0x36 --More-- _sleep(c0c8b0b4,c0c8afbc,0,c0b5ff3a,0,...) at _sleep+0x2d6 sctp_iterator_thread(0,e44a7d38,762e,d601,764f,...) at sctp_iterator_thread+0x7f fork_exit(c088e9f0,0,e44a7d38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe44a7d70, ebp = 0 --- Tracing command irq7: ppbus0 ppc0 pid 40 tid 100039 td 0xc41a6d20 fork_trampoline() at fork_trampoline Tracing command irq1: atkbd0 pid 39 tid 100038 td 0xc41a7000 fork_trampoline() at fork_trampoline Tracing command irq15: ata1 pid 38 tid 100037 td 0xc402cd20 fork_trampoline() at fork_trampoline Tracing command irq14: ata0 pid 37 tid 100036 td 0xc4073000 fork_trampoline() at fork_trampoline Tracing command swi0: sio pid 36 tid 100035 td 0xc4073230 sched_switch(c4073230,0,1,e91bd185,b2,...) at sched_switch+0x43b --More-- mi_switch(1,0,c0b515a9,4a1,0,...) at mi_switch+0x146 ithread_loop(c418e4c0,e4495d38,0,0,0,...) at ithread_loop+0x308 fork_exit(c077e800,c418e4c0,e4495d38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe4495d70, ebp = 0 --- Tracing command fdc0 pid 35 tid 100034 td 0xc4073460 sched_switch(c4073460,0,1,374ef44,cc,...) at sched_switch+0x43b mi_switch(1,0,c4073460,c4073460,e4492c00,...) at mi_switch+0x146 sleepq_switch(c4073460,0,c0b5647e,266,0,...) at sleepq_switch+0xcb sleepq_timedwait(c418d83c,3e8,c0b4da2d,0,0,...) at sleepq_timedwait+0x37 _sleep(c418d83c,c418d8f0,4c,c0b4da2d,3e8,...) at _sleep+0x2b4 fdc_thread(c418d800,e4492d38,0,0,0,...) at fdc_thread+0x3da fork_exit(c0a798a0,c418d800,e4492d38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe4492d70, ebp = 0 --- Tracing command fw0_probe pid 34 tid 100033 td 0xc4073690 sched_switch(c4073690,0,1,f8d7766e,30,...) at sched_switch+0x43b mi_switch(1,0,c4073690,c408a2b8,e44257f0,...) at mi_switch+0x146 --More-- sleepq_switch(c4073690,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c4073690,e4425834,c07a8857,c4097000,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c4097000,c409b484,c0b4da2d,100,0,...) at sleepq_wait_sig+0xd _sleep(c4097000,c409b484,15c,c0b4da2d,0,...) at _sleep+0x2c7 fw_bus_probe_thread(c4097000,e4425d38,0,c0b41166,c0b3fe7a,...) at fw_bus_probe_thread+0x785 fork_exit(c05bbd20,c4097000,e4425d38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe4425d70, ebp = 0 --- Tracing command fw0_taskq pid 33 tid 100032 td 0xc40738c0 sched_switch(c40738c0,0,1,48d4ce10,cc,...) at sched_switch+0x43b mi_switch(1,0,c40738c0,c408c21c,e4422ca4,...) at mi_switch+0x146 sleepq_switch(c40738c0,0,c0b5647e,243,0,...) at sleepq_switch+0xcb sleepq_wait(c408c200,c408c21c,c0b4da2d,0,0,...) at sleepq_wait+0x36 msleep_spin(c408c200,c408c21c,c0b4da2d,0,e4422cf4,...) at msleep_spin+0x181 taskqueue_thread_loop(c409b49c,e4422d38,40100014,40,2000040,...) at taskqueue_thread_loop+0xdd fork_exit(c07d4070,c409b49c,e4422d38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe4422d70, ebp = 0 --- --More-- Tracing command usb4 pid 32 tid 100031 td 0xc4073af0 sched_switch(c4073af0,0,1,ab89b8a6,b5,...) at sched_switch+0x43b mi_switch(1,0,c4073af0,c4073af0,e4409ca0,...) at mi_switch+0x146 sleepq_switch(c4073af0,0,c0b5647e,266,1,...) at sleepq_switch+0xcb sleepq_timedwait(c4013210,ea60,c0b4ab7f,0,0,...) at sleepq_timedwait+0x37 _sleep(c4013210,0,5c,c0b4ab7f,ea60,...) at _sleep+0x2b4 usb_event_thread(c4087380,e4409d38,0,0,0,...) at usb_event_thread+0xeb fork_exit(c070a720,c4087380,e4409d38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe4409d70, ebp = 0 --- Tracing command irq23: rl1 ehci0 pid 31 tid 100030 td 0xc4073d20 sched_switch(c4073d20,0,1,e9f445d0,9f,...) at sched_switch+0x43b mi_switch(1,0,c0b515a9,4a1,0,...) at mi_switch+0x146 ithread_loop(c4065590,e43f7d38,0,0,0,...) at ithread_loop+0x308 fork_exit(c077e800,c4065590,e43f7d38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe43f7d70, ebp = 0 --- Tracing command usb3 pid 30 tid 100029 td 0xc4074000 --More-- sched_switch(c4074000,0,1,abb994f4,b5,...) at sched_switch+0x43b mi_switch(1,0,c4074000,c4074000,e43f3ca0,...) at mi_switch+0x146 sleepq_switch(c4074000,0,c0b5647e,266,1,...) at sleepq_switch+0xcb sleepq_timedwait(c407f210,ea60,c0b4ab7f,0,0,...) at sleepq_timedwait+0x37 _sleep(c407f210,0,5c,c0b4ab7f,ea60,...) at _sleep+0x2b4 usb_event_thread(c40549c0,e43f3d38,0,0,0,...) at usb_event_thread+0xeb fork_exit(c070a720,c40549c0,e43f3d38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe43f3d70, ebp = 0 --- Tracing command usb2 pid 29 tid 100028 td 0xc4074230 sched_switch(c4074230,0,1,abb97f14,b5,...) at sched_switch+0x43b mi_switch(1,0,c4074230,c4074230,e43efca0,...) at mi_switch+0x146 sleepq_switch(c4074230,0,c0b5647e,266,1,...) at sleepq_switch+0xcb sleepq_timedwait(c406c210,ea60,c0b4ab7f,0,0,...) at sleepq_timedwait+0x37 _sleep(c406c210,0,5c,c0b4ab7f,ea60,...) at _sleep+0x2b4 usb_event_thread(c4066300,e43efd38,0,0,0,...) at usb_event_thread+0xeb fork_exit(c070a720,c4066300,e43efd38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe43efd70, ebp = 0 --- --More-- Tracing command irq18: rl0 uhci2++ pid 28 tid 100027 td 0xc4074460 sched_switch(c4074460,0,1,45e08085,c9,...) at sched_switch+0x43b mi_switch(1,0,c0b515a9,4a1,0,...) at mi_switch+0x146 ithread_loop(c4065860,e43ebd38,0,0,0,...) at ithread_loop+0x308 fork_exit(c077e800,c4065860,e43ebd38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe43ebd70, ebp = 0 --- Tracing command usb1 pid 27 tid 100026 td 0xc3f63690 sched_switch(c3f63690,0,1,abb967c3,b5,...) at sched_switch+0x43b mi_switch(1,0,c3f63690,c3f63690,e43e8ca0,...) at mi_switch+0x146 sleepq_switch(c3f63690,0,c0b5647e,266,1,...) at sleepq_switch+0xcb sleepq_timedwait(c405c210,ea60,c0b4ab7f,0,0,...) at sleepq_timedwait+0x37 _sleep(c405c210,0,5c,c0b4ab7f,ea60,...) at _sleep+0x2b4 usb_event_thread(c4066e80,e43e8d38,0,0,0,...) at usb_event_thread+0xeb fork_exit(c070a720,c4066e80,e43e8d38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe43e8d70, ebp = 0 --- --More-- Tracing command irq19: uhci1 pid 26 tid 100025 td 0xc3f638c0 fork_trampoline() at fork_trampoline Tracing command usbtask-dr pid 25 tid 100024 td 0xc3f63af0 sched_switch(c3f63af0,0,1,b7630020,30,...) at sched_switch+0x43b mi_switch(1,0,c3f63af0,c3f63af0,e43e1ca0,...) at mi_switch+0x146 sleepq_switch(c3f63af0,0,c0b5647e,243,1,...) at sleepq_switch+0xcb sleepq_wait(c0c7b234,5c,c0b54014,d6,0,...) at sleepq_wait+0x36 _sleep(c0c7b234,0,5c,c0b4ab71,0,...) at _sleep+0x2d6 usb_task_thread(c0c7b234,e43e1d38,0,0,0,...) at usb_task_thread+0x7e fork_exit(c070a640,c0c7b234,e43e1d38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe43e1d70, ebp = 0 --- Tracing command usbtask-hc pid 24 tid 100023 td 0xc3f63d20 sched_switch(c3f63d20,0,1,b762eba4,30,...) at sched_switch+0x43b mi_switch(1,0,c3f63d20,c3f63d20,e43deca0,...) at mi_switch+0x146 sleepq_switch(c3f63d20,0,c0b5647e,243,1,...) at sleepq_switch+0xcb sleepq_wait(c0c7b220,5c,c0b54014,d6,0,...) at sleepq_wait+0x36 _sleep(c0c7b220,0,5c,c0b4ab71,0,...) at _sleep+0x2d6 --More-- usb_task_thread(c0c7b220,e43ded38,0,0,0,...) at usb_task_thread+0x7e fork_exit(c070a640,c0c7b220,e43ded38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe43ded70, ebp = 0 --- Tracing command usb0 pid 23 tid 100022 td 0xc402c000 sched_switch(c402c000,0,1,abb94f0e,b5,...) at sched_switch+0x43b mi_switch(1,0,c402c000,c402c000,e43dbca0,...) at mi_switch+0x146 sleepq_switch(c402c000,0,c0b5647e,266,1,...) at sleepq_switch+0xcb sleepq_timedwait(c4024210,ea60,c0b4ab7f,0,0,...) at sleepq_timedwait+0x37 _sleep(c4024210,0,5c,c0b4ab7f,ea60,...) at _sleep+0x2b4 usb_event_thread(c4053280,e43dbd38,0,0,0,...) at usb_event_thread+0xeb fork_exit(c070a720,c4053280,e43dbd38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe43dbd70, ebp = 0 --- Tracing command irq16: uhci0 uhci3 pid 22 tid 100021 td 0xc402c230 fork_trampoline() at fork_trampoline Tracing command irq9: acpi0 pid 21 tid 100020 td 0xc402c460 --More-- fork_trampoline() at fork_trampoline Tracing command swi6: task queue pid 20 tid 100019 td 0xc402c690 sched_switch(c402c690,0,1,261ad3d4,a0,...) at sched_switch+0x43b mi_switch(1,0,c0b515a9,4a1,1,...) at mi_switch+0x146 ithread_loop(c3fcac30,e43bcd38,1110e,1000120,c4025a00,...) at ithread_loop+0x308 fork_exit(c077e800,c3fcac30,e43bcd38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe43bcd70, ebp = 0 --- Tracing command swi6: Giant taskq pid 19 tid 100018 td 0xc402c8c0 fork_trampoline() at fork_trampoline Tracing command thread taskq pid 18 tid 100017 td 0xc402caf0 sched_switch(c402caf0,0,1,55fa8ee0,34,...) at sched_switch+0x43b mi_switch(1,0,c402caf0,c402caf0,e43b6c9c,...) at mi_switch+0x146 sleepq_switch(c402caf0,0,c0b5647e,243,0,...) at sleepq_switch+0xcb sleepq_wait(c3fe3700,c3fe371c,c0b4da2d,0,0,...) at sleepq_wait+0x36 _sleep(c3fe3700,c3fe371c,0,c0b4da2d,0,...) at _sleep+0x2d6 taskqueue_thread_loop(c0c8801c,e43b6d38,100110f,534b4157,0,...) at taskqueue_thread_loop+0x104 --More-- fork_exit(c07d4070,c0c8801c,e43b6d38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe43b6d70, ebp = 0 --- Tracing command swi5: + pid 17 tid 100016 td 0xc3f1a230 fork_trampoline() at fork_trampoline Tracing command acpi_task_2 pid 9 tid 100015 td 0xc3f1a460 sched_switch(c3f1a460,0,1,b76db3bb,30,...) at sched_switch+0x43b mi_switch(1,0,c3f1a460,c3f1a460,e43b0c9c,...) at mi_switch+0x146 sleepq_switch(c3f1a460,0,c0b5647e,243,0,...) at sleepq_switch+0xcb sleepq_wait(c3fe3880,c3fe389c,c0b4da2d,0,0,...) at sleepq_wait+0x36 _sleep(c3fe3880,c3fe389c,0,c0b4da2d,0,...) at _sleep+0x2d6 taskqueue_thread_loop(c0e1bebc,e43b0d38,1008000,80,88000020,...) at taskqueue_thread_loop+0x104 fork_exit(c07d4070,c0e1bebc,e43b0d38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe43b0d70, ebp = 0 --- Tracing command acpi_task_1 pid 8 tid 100014 td 0xc3f1a690 sched_switch(c3f1a690,0,1,b76d9523,30,...) at sched_switch+0x43b --More-- mi_switch(1,0,c3f1a690,c3f1a690,e43adc9c,...) at mi_switch+0x146 sleepq_switch(c3f1a690,0,c0b5647e,243,0,...) at sleepq_switch+0xcb sleepq_wait(c3fe3880,c3fe389c,c0b4da2d,0,0,...) at sleepq_wait+0x36 _sleep(c3fe3880,c3fe389c,0,c0b4da2d,0,...) at _sleep+0x2d6 taskqueue_thread_loop(c0e1bebc,e43add38,0,0,0,...) at taskqueue_thread_loop+0x104 fork_exit(c07d4070,c0e1bebc,e43add38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe43add70, ebp = 0 --- Tracing command acpi_task_0 pid 7 tid 100013 td 0xc3f1a8c0 sched_switch(c3f1a8c0,0,1,b76d7624,30,...) at sched_switch+0x43b mi_switch(1,0,c3f1a8c0,c3f1a8c0,e43aac9c,...) at mi_switch+0x146 sleepq_switch(c3f1a8c0,0,c0b5647e,243,0,...) at sleepq_switch+0xcb sleepq_wait(c3fe3880,c3fe389c,c0b4da2d,0,0,...) at sleepq_wait+0x36 _sleep(c3fe3880,c3fe389c,0,c0b4da2d,0,...) at _sleep+0x2d6 taskqueue_thread_loop(c0e1bebc,e43aad38,0,0,0,...) at taskqueue_thread_loop+0x104 fork_exit(c07d4070,c0e1bebc,e43aad38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe43aad70, ebp = 0 --- --More-- Tracing command swi2: cambio pid 16 tid 100012 td 0xc3f1aaf0 sched_switch(c3f1aaf0,0,1,7f9b39a5,34,...) at sched_switch+0x43b mi_switch(1,0,c0b515a9,4a1,0,...) at mi_switch+0x146 ithread_loop(c3fcac80,e43a7d38,0,0,0,...) at ithread_loop+0x308 fork_exit(c077e800,c3fcac80,e43a7d38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe43a7d70, ebp = 0 --- Tracing command xpt_thrd pid 6 tid 100011 td 0xc3f1ad20 sched_switch(c3f1ad20,0,1,b7629af6,30,...) at sched_switch+0x43b mi_switch(1,0,c3f1ad20,c3f1ad20,e43a4c90,...) at mi_switch+0x146 sleepq_switch(c3f1ad20,0,c0b5647e,243,0,...) at sleepq_switch+0xcb sleepq_wait(c0c4b054,4c,c0b54014,d6,0,...) at sleepq_wait+0x36 _sleep(c0c4b054,c0c4b06c,4c,c0b0ae09,0,...) at _sleep+0x2d6 xpt_scanner_thread(0,e43a4d38,0,0,0,...) at xpt_scanner_thread+0x41 fork_exit(c046f530,0,e43a4d38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe43a4d70, ebp = 0 --- Tracing command kqueue taskq pid 5 tid 100010 td 0xc3f63000 --More-- sched_switch(c3f63000,0,1,b76c4f80,30,...) at sched_switch+0x43b mi_switch(1,0,c3f63000,c3f63000,e43a1c9c,...) at mi_switch+0x146 sleepq_switch(c3f63000,0,c0b5647e,243,0,...) at sleepq_switch+0xcb sleepq_wait(c3fe3a80,c3fe3a9c,c0b4da2d,0,0,...) at sleepq_wait+0x36 _sleep(c3fe3a80,c3fe3a9c,0,c0b4da2d,0,...) at _sleep+0x2d6 taskqueue_thread_loop(c0c7be84,e43a1d38,0,0,0,...) at taskqueue_thread_loop+0x104 fork_exit(c07d4070,c0c7be84,e43a1d38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe43a1d70, ebp = 0 --- Tracing command yarrow pid 15 tid 100009 td 0xc3f63230 sched_switch(c3f63230,0,1,4991b243,cc,...) at sched_switch+0x43b mi_switch(1,0,c3f63230,c3f63230,e439ac74,...) at mi_switch+0x146 sleepq_switch(c3f63230,0,c0b5647e,266,0,...) at sleepq_switch+0xcb sleepq_timedwait(c0c7da74,64,c0b4da2d,2,0,...) at sleepq_timedwait+0x37 _sleep(c0c7da74,0,0,c0b4da2d,64,...) at _sleep+0x2b4 pause(c0b4da2d,64,23330424,48000104,5320254,...) at pause+0x30 random_kthread(0,e439ad38,67badf3f,dcfeb2df,7eaf373f,...) at random_kthread+0x22a fork_exit(c0687350,0,e439ad38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 --More-- --- trap 0, eip = 0, esp = 0xe439ad70, ebp = 0 --- Tracing command g_down pid 4 tid 100008 td 0xc3f63460 sched_switch(c3f63460,0,1,4d13247f,cc,...) at sched_switch+0x43b mi_switch(1,0,c3f63460,c3f63460,e4397c60,...) at mi_switch+0x146 sleepq_switch(c3f63460,0,c0b5647e,266,0,...) at sleepq_switch+0xcb sleepq_timedwait(c0c7b62c,64,c0b4da2d,0,0,...) at sleepq_timedwait+0x37 _sleep(c0c7b62c,c0c7b548,24c,c0b4da2d,64,...) at _sleep+0x2b4 g_io_schedule_down(c3f63460,4c,c0b4e6e7,72,0,...) at g_io_schedule_down+0x6b g_down_procbody(0,e4397d38,7ff73fff,7ff537ff,effffdff,...) at g_down_procbody+0x6e fork_exit(c0746110,0,e4397d38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe4397d70, ebp = 0 --- Tracing command g_up pid 3 tid 100007 td 0xc3f18000 sched_switch(c3f18000,0,1,4da0d2d3,cc,...) at sched_switch+0x43b mi_switch(1,0,c3f18000,c3f18000,e4394c84,...) at mi_switch+0x146 sleepq_switch(c3f18000,0,c0b5647e,266,0,...) at sleepq_switch+0xcb sleepq_timedwait(c0c7b628,64,c0b4da2d,0,0,...) at sleepq_timedwait+0x37 _sleep(c0c7b628,c0c7b588,24c,c0b4da2d,64,...) at _sleep+0x2b4 --More-- g_io_schedule_up(c3f18000,4c,c0b4e6e7,5b,0,...) at g_io_schedule_up+0xd2 g_up_procbody(0,e4394d38,20102016,a20001d1,2000322,...) at g_up_procbody+0x6e fork_exit(c0745ff0,0,e4394d38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe4394d70, ebp = 0 --- Tracing command g_event pid 2 tid 100006 td 0xc3f18230 sched_switch(c3f18230,0,1,4e5dc57c,cc,...) at sched_switch+0x43b mi_switch(1,0,c3f18230,c3f18230,e4391ca0,...) at mi_switch+0x146 sleepq_switch(c3f18230,0,c0b5647e,266,0,...) at sleepq_switch+0xcb sleepq_timedwait(c0c7b620,64,c0b4da2d,0,0,...) at sleepq_timedwait+0x37 _sleep(c0c7b620,0,4c,c0b4da2d,64,...) at _sleep+0x2b4 g_event_procbody(0,e4391d38,0,82b64920,c3f64ce0,...) at g_event_procbody+0xac fork_exit(c0746060,0,e4391d38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe4391d70, ebp = 0 --- Tracing command swi3: vm pid 14 tid 100005 td 0xc3f18460 fork_trampoline() at fork_trampoline --More-- Tracing command swi4: clock sio pid 13 tid 100004 td 0xc3f18690 sched_switch(c3f18690,0,1,5151748d,cc,...) at sched_switch+0x43b mi_switch(1,0,c0b515a9,4a1,6202331,...) at mi_switch+0x146 ithread_loop(c3f15270,e438bd38,2001,dbf5fde3,c3f5fcfd,...) at ithread_loop+0x308 fork_exit(c077e800,c3f15270,e438bd38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe438bd70, ebp = 0 --- Tracing command swi1: net pid 12 tid 100003 td 0xc3f188c0 sched_switch(c3f188c0,0,1,87353bda,bd,...) at sched_switch+0x43b mi_switch(1,0,c0b515a9,4a1,0,...) at mi_switch+0x146 ithread_loop(c3f15280,e4388d38,1000,0,0,...) at ithread_loop+0x308 fork_exit(c077e800,c3f15280,e4388d38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe4388d70, ebp = 0 --- Tracing command idle: cpu0 pid 11 tid 100002 td 0xc3f18af0 sched_switch(c3f18af0,0,6,7438c670,c1,...) at sched_switch+0x43b mi_switch(6,0,c0b54d2c,b6,0,...) at mi_switch+0x146 critical_exit(c3f5a600,0,214,c3f18af0,c3f5a600,...) at critical_exit+0x83 --More-- intr_execute_handlers(c3efbec8,e2984c48,e2984c88,c0aa0224,33,...) at intr_execute_handlers+0x135 lapic_handle_intr(33,e2984c48) at lapic_handle_intr+0x3f Xapic_isr1() at Xapic_isr1+0x34 --- interrupt, eip = 0xc0e0b615, esp = 0xe2984c88, ebp = 0xe2984c88 --- acpi_cpu_c1(c3f18af0,3e8,0,0,c0e04517,...) at acpi_cpu_c1+0x5 acpi_cpu_idle(e2984cf4,c07c0004,c3f2eac0,c3f2e7e8,c1c4a788,...) at acpi_cpu_idle+0x184 cpu_idle(c3f2eac0,c3f2e7e8,c1c4a788,e2a6b000,0,...) at cpu_idle+0x28 sched_idletd(0,e2984d38,c3f18764,c3f1a640,c3f1a448,...) at sched_idletd+0x2c4 fork_exit(c07bfd40,0,e2984d38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe2984d70, ebp = 0 --- Tracing command init pid 1 tid 100001 td 0xc3f18d20 sched_switch(c3f18d20,0,1,71df2080,b1,...) at sched_switch+0x43b mi_switch(1,0,c3f18d20,c3f16ae0,e2980b90,...) at mi_switch+0x146 sleepq_switch(c3f18d20,0,c0b5647e,19d,c0aa9f80,...) at sleepq_switch+0xcb sleepq_catch_signals(0,c3f18d20,e2980bd4,c07a8857,c3f16ae0,...) at sleepq_catch_signals+0x2fc sleepq_wait_sig(c3f16ae0,5c,c0b54014,d6,0,...) at sleepq_wait_sig+0xd _sleep(c3f16ae0,c3f16b70,15c,c0b53aa3,0,...) at _sleep+0x2c7 kern_wait(c3f18d20,ffffffff,e2980c2c,0,0,...) at kern_wait+0xf98 --More-- wait4(c3f18d20,e2980cfc,10,e2980d38,e2980d2c,...) at wait4+0x3b syscall(e2980d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (7, FreeBSD ELF32, wait4), eip = 0x805455f, esp = 0xbfbfe97c, ebp = 0xbfbfe998 --- Tracing command audit pid 10 tid 100000 td 0xc3f1a000 sched_switch(c3f1a000,0,1,b7600188,30,...) at sched_switch+0x43b mi_switch(1,0,c3f1a000,c3f1a000,e297dc7c,...) at mi_switch+0x146 sleepq_switch(c3f1a000,0,c0b5647e,243,0,...) at sleepq_switch+0xcb sleepq_wait(c0c94c64,c0c94c44,c0b690af,1,0,...) at sleepq_wait+0x36 _cv_wait(c0c94c64,c0c94c44,e2984cc0,c0a98c48,e2984cb4,...) at _cv_wait+0x171 audit_worker(0,e297dd38,1000000,4000010,20000000,...) at audit_worker+0x6f fork_exit(c0994530,0,e297dd38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe297dd70, ebp = 0 --- Tracing command swapper pid 0 tid 0 td 0xc0c7b9a0 sched_switch(c0c7b9a0,0,1,c6058838,cb,...) at sched_switch+0x43b mi_switch(1,0,c0c7b9a0,c0c7b9a0,c1020d08,...) at mi_switch+0x146 sleepq_switch(c0c7b9a0,0,c0b5647e,266,0,...) at sleepq_switch+0xcb --More-- sleepq_timedwait(c0c7b6e0,2710,c0b55019,0,0,...) at sleepq_timedwait+0x37 _sleep(c0c7b6e0,0,44,c0b55019,2710,...) at _sleep+0x2b4 scheduler(0,101ec00,101ec00,101e000,1025000,...) at scheduler+0x35d mi_startup() at mi_startup+0x96 begin() at begin+0x2c db> reboot Killed # exit Script done on Fri Dec 26 19:19:35 2008 From owner-freebsd-stable@FreeBSD.ORG Sat Dec 27 03:09:13 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3CB11065673; Sat, 27 Dec 2008 03:09:13 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by mx1.freebsd.org (Postfix) with ESMTP id 8DB298FC16; Sat, 27 Dec 2008 03:09:13 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so5223984rvf.43 for ; Fri, 26 Dec 2008 19:09:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=pX5IGJYlLn3Ce92ACJLFZHPGdNVGVz9308S8wglCIQ8=; b=Ni695b1qfuZWEGwZcUBGYMR7fEvA1ymJUBcVocmb332neI2nBILXYLgCGd3RH8hAV0 u8V0ZXPokwFMnsFmTNQYQzlO3kdOlx/pkZpdYIklGJAPnYy8nOuhwzVjqU+t/Uiq0GuC U6QDB4Uh/XYsPPJ5/4rDL+eMIqhCN9qHe0fME= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=JK6TJ25Xf9mESGZYuP4AXKkn7PSBuJJ4249sk9ctJ+4+Bj/Ny74u+XOJ/D8476QdS0 JuR+Agsd5rpDrxmfY/XOG40R0e8Exfj2swYmYWNr1+kZExqnzzFWTpbslKsJ74cFoOAH rxtvnMwUgZTT3EY2V+aso9cKYQCb4LUN/kDZw= Received: by 10.141.137.3 with SMTP id p3mr5524910rvn.296.1230347353390; Fri, 26 Dec 2008 19:09:13 -0800 (PST) Received: by 10.140.135.2 with HTTP; Fri, 26 Dec 2008 19:09:13 -0800 (PST) Message-ID: <7d6fde3d0812261909x5fafc017ubab2317d8852cb73@mail.gmail.com> Date: Fri, 26 Dec 2008 19:09:13 -0800 From: "Garrett Cooper" To: "Peter Wemm" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7d6fde3d0812222135l753daf54geb37b696c9c1cf8@mail.gmail.com> <20081223173608.068fe9d8@suszko.eu> <8cb6106e0812230955u1bd16932h7ae4ad3fc8c97f28@mail.gmail.com> <20081223183649.GA90840@troutmask.apl.washington.edu> Cc: Josh Carroll , "amd64@freebsd.org" , stable , Maciej Suszko , Steve Kargl Subject: Re: -m32 broken on bi-arch amd64 systems? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Dec 2008 03:09:13 -0000 On Tue, Dec 23, 2008 at 3:54 PM, Peter Wemm wrote: > On Tue, Dec 23, 2008 at 1:07 PM, Garrett Cooper wrote: >> On Dec 23, 2008, at 10:36, Steve Kargl >> wrote: >> >>> On Tue, Dec 23, 2008 at 12:55:04PM -0500, Josh Carroll wrote: >>>>> >>>>> I also noticed that behavior, shouldn't compiler/linker look >>>>> into /usr/lib32 without additional -B switch? >>>>> -- >>>>> regards, Maciej Suszko. >>>>> >>>> >>>> I don't know if it should or should not, but I can confirm that this >>>> behavior was around in 7.0-RELEASE, so it's been that way for quite a >>>> while, at least in the 7 branch. >>>> >>> >>> Sigh. Read the list archives. It's been this way since Peter >>> Wemm first introduce the ability to run i386 binaries on >>> amd64. >>> >>> -- >>> Steve >> >> Ok, let's bury this topic then. >> Thanks for the confirmation and sorry for the noise. >> -Garrett > > A patch can be extraced from > http://people.freebsd.org/~peter/hammer.diff > that makes it "work", but its not right. It doesn't quite do -I > include overrides right when -m32 is specified. > > It's enough to make just about everything else work. I forgot that I > was building valgrind with it for some time now. I'll give that a shot, provide some feedback, and see if I can *maybe* (shrugs) improve upon it. Thanks Peter! -Garrett From owner-freebsd-stable@FreeBSD.ORG Sat Dec 27 08:51:14 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A0C0106564A for ; Sat, 27 Dec 2008 08:51:14 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 0E6258FC08 for ; Sat, 27 Dec 2008 08:51:13 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1LGUt5-000Jpj-2L; Sat, 27 Dec 2008 10:51:11 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: "Lin Jui-Nan Eric" In-reply-to: <47713ee10812261117o6f772843o53ec9542bc773141@mail.gmail.com> References: <47713ee10812220844r7889d286l3a98f294d780ccc0@mail.gmail.com> <6eb82e0812260202m1d8816c5mc7b0991514f83853@mail.gmail.com> <47713ee10812261117o6f772843o53ec9542bc773141@mail.gmail.com> Comments: In-reply-to "Lin Jui-Nan Eric" message dated "Sat, 27 Dec 2008 03:17:42 +0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 27 Dec 2008 10:51:11 +0200 From: Danny Braniss Message-ID: Cc: stable@freebsd.org, Rong-en Fan Subject: Re: amd(8) cores dump when load high X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Dec 2008 08:51:14 -0000 > Yes, we found that it crashes when swap is used. on an amd64 architecture, amd could not plock it's pages in memory, and would, under memory preasure be swapped out, and break. I just run some tests under 7.1-PRERELEASE, and - it seems that plock is working. - amd is not being swapped out. are you running with amd -S ? danny > > > On Fri, Dec 26, 2008 at 6:02 PM, Rong-en Fan wrote: > > On Tue, Dec 23, 2008 at 12:44 AM, Lin Jui-Nan Eric wrote: > >> Dear listers, > >> > >> We currently found that amd frequently cores dump while loading is > >> high (about 4~5) after we upgrade world & kernel from 7.0-RELEASE to > >> 7.1-PRERELEASE. > >> > >> I have read -stable and svn log of 7-STABLE, but can not found a > >> report or a solution. Did anyone have the same issue? Thank you very > >> much. > >> > > > > According to my previous experience, amd 6.1.5 crashes > > under low memory situations. Not necessary high load. > > > > Regards, > > Rong-En Fan > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Sat Dec 27 09:05:16 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BE5A1065674 for ; Sat, 27 Dec 2008 09:05:16 +0000 (UTC) (envelope-from ericlin@tamama.org) Received: from mail-gx0-f19.google.com (mail-gx0-f19.google.com [209.85.217.19]) by mx1.freebsd.org (Postfix) with ESMTP id 61F2D8FC12 for ; Sat, 27 Dec 2008 09:05:14 +0000 (UTC) (envelope-from ericlin@tamama.org) Received: by gxk12 with SMTP id 12so2775669gxk.19 for ; Sat, 27 Dec 2008 01:05:14 -0800 (PST) Received: by 10.151.156.6 with SMTP id i6mr4120973ybo.150.1230368714057; Sat, 27 Dec 2008 01:05:14 -0800 (PST) Received: by 10.151.74.12 with HTTP; Sat, 27 Dec 2008 01:05:14 -0800 (PST) Message-ID: <47713ee10812270105o5866aa27u9998539dc127e549@mail.gmail.com> Date: Sat, 27 Dec 2008 17:05:14 +0800 From: "Lin Jui-Nan Eric" To: "Danny Braniss" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47713ee10812220844r7889d286l3a98f294d780ccc0@mail.gmail.com> <6eb82e0812260202m1d8816c5mc7b0991514f83853@mail.gmail.com> <47713ee10812261117o6f772843o53ec9542bc773141@mail.gmail.com> Cc: stable@freebsd.org, Rong-en Fan Subject: Re: amd(8) cores dump when load high X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Dec 2008 09:05:16 -0000 No, we do not running amd with -S. # ps auxww | grep amd root 706 0.0 0.1 7660 5416 ?? Ss Wed05PM 4:48.12 /usr/sbin/amd -p -k amd64 -x all /net amd.map On Sat, Dec 27, 2008 at 4:51 PM, Danny Braniss wrote: >> Yes, we found that it crashes when swap is used. > > on an amd64 architecture, amd could not plock it's pages in memory, and would, > under memory preasure be swapped out, and break. > I just run some tests under 7.1-PRERELEASE, and > - it seems that plock is working. > - amd is not being swapped out. > are you running with amd -S ? > danny > >> >> >> On Fri, Dec 26, 2008 at 6:02 PM, Rong-en Fan wrote: >> > On Tue, Dec 23, 2008 at 12:44 AM, Lin Jui-Nan Eric wrote: >> >> Dear listers, >> >> >> >> We currently found that amd frequently cores dump while loading is >> >> high (about 4~5) after we upgrade world & kernel from 7.0-RELEASE to >> >> 7.1-PRERELEASE. >> >> >> >> I have read -stable and svn log of 7-STABLE, but can not found a >> >> report or a solution. Did anyone have the same issue? Thank you very >> >> much. >> >> >> > >> > According to my previous experience, amd 6.1.5 crashes >> > under low memory situations. Not necessary high load. >> > >> > Regards, >> > Rong-En Fan >> > >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> > > > From owner-freebsd-stable@FreeBSD.ORG Sat Dec 27 10:11:07 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC40A106564A for ; Sat, 27 Dec 2008 10:11:07 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by mx1.freebsd.org (Postfix) with ESMTP id 8F8108FC17 for ; Sat, 27 Dec 2008 10:11:02 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so2115888ywe.13 for ; Sat, 27 Dec 2008 02:11:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=bWI1xiEM+RnnoDkWyleKw2sejVODCD3os0orOCUt1Zk=; b=m5LZ/fyiUsnNjLPfxGplJAAxG+nbuDNyov84TGDW3GL4vcBz9qeeIZUrK1e0LlHdAD a1CTCaeKGltbhmQB7ip0pgbd4J5r0vbqFUWZaqA2g8ttg7Roeg5Dvdl1piIKoISIzqYT PWOsCMQgfcu4hisNd9HSxAzfdM7L6HyzTDXQA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=KjHpSxMgVhfC6NNRKvfaX3yOW/2Q9kcbj6bR6uNsNAjd1GcYVqB+iuWCW5uISyWwXG ZsnH3uJxtRE9s7133KTyjyLEaxj1m6dN7ofSTUUp6wlbCM1RTUDYRbJv4H7rgzXr77HB 0MmqB298+xV5ULoMNfYg2N+e1XgVoJ5rt55Io= Received: by 10.90.103.13 with SMTP id a13mr5692277agc.68.1230372661771; Sat, 27 Dec 2008 02:11:01 -0800 (PST) Received: by 10.90.73.9 with HTTP; Sat, 27 Dec 2008 02:11:01 -0800 (PST) Message-ID: Date: Sat, 27 Dec 2008 13:11:01 +0300 From: pluknet To: "Mike Tancsa" In-Reply-To: <200812262313.mBQNDAdO050469@lava.sentex.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200812262313.mBQNDAdO050469@lava.sentex.ca> Cc: bsdlist@cogeco.ca, FreeBSD Stable Mailing List Subject: Re: process stuck in vmopar X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Dec 2008 10:11:07 -0000 2008/12/27 Mike Tancsa : > At 03:31 PM 12/26/2008, pluknet wrote: > >> Also seen on 6.3, 6.4 releases. >> >> Prepared as PR kern/129956. > > I wonder if this is the same or similar issue in where the poster is also > seeing processes stuck in UFS state > > http://lists.freebsd.org/pipermail/freebsd-stable/2008-December/047118.html > I doubt. Stucking in ufs state in my case is only triggered by earlier stucking of another process in vmopar state. Also no high load there seen in gstat, as in that mail. -- wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Sat Dec 27 11:03:57 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 232B3106564A for ; Sat, 27 Dec 2008 11:03:57 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id C96058FC16 for ; Sat, 27 Dec 2008 11:03:56 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1LGWxW-000Kuc-AS; Sat, 27 Dec 2008 13:03:54 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: "Lin Jui-Nan Eric" In-reply-to: <47713ee10812270105o5866aa27u9998539dc127e549@mail.gmail.com> References: <47713ee10812220844r7889d286l3a98f294d780ccc0@mail.gmail.com> <6eb82e0812260202m1d8816c5mc7b0991514f83853@mail.gmail.com> <47713ee10812261117o6f772843o53ec9542bc773141@mail.gmail.com> <47713ee10812270105o5866aa27u9998539dc127e549@mail.gmail.com> Comments: In-reply-to "Lin Jui-Nan Eric" message dated "Sat, 27 Dec 2008 17:05:14 +0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 27 Dec 2008 13:03:54 +0200 From: Danny Braniss Message-ID: Cc: stable@freebsd.org, Rong-en Fan Subject: Re: amd(8) cores dump when load high X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Dec 2008 11:03:57 -0000 > No, we do not running amd with -S. > > # ps auxww | grep amd > root 706 0.0 0.1 7660 5416 ?? Ss Wed05PM 4:48.12 > /usr/sbin/amd -p -k amd64 -x all /net amd.map > well, I'm running 7.1-PRERELEASE, what does the amd logs show? Dec 27 10:37:01 sf-02 amd[856]: AM-UTILS VERSION INFORMATION: Dec 27 10:37:01 sf-02 amd[856]: Copyright (c) 1997-2006 Erez Zadok Dec 27 10:37:01 sf-02 amd[856]: Copyright (c) 1990 Jan-Simon Pendry Dec 27 10:37:01 sf-02 amd[856]: Copyright (c) 1990 Imperial College of Science, Technology & Medicine Dec 27 10:37:01 sf-02 amd[856]: Copyright (c) 1990 The Regents of the University of California. Dec 27 10:37:01 sf-02 amd[856]: am-utils version 6.1.5 (build 1). Dec 27 10:37:01 sf-02 amd[856]: Report bugs to https://bugzilla.am-utils.org/ or am-utils@am-utils.org. Dec 27 10:37:01 sf-02 amd[856]: Configured by danny@sunfire on date Sun Jun 29 16:59:06 IDT 2008. Dec 27 10:37:01 sf-02 amd[856]: Built by danny@sunfire on date Sun Jun 29 17:02:07 IDT 2008. Dec 27 10:37:01 sf-02 amd[856]: cpu=x86_64 (little-endian), arch=amd64, karch=amd64. Dec 27 10:37:01 sf-02 amd[856]: full_os=freebsd7.0, os=freebsd7, osver=7.0, vendor=unknown, distro=none. Dec 27 10:37:01 sf-02 amd[856]: domain=unknown.domain, host=sf-02, hostd=sf-02.unknown.domain. Dec 27 10:37:01 sf-02 amd[856]: Map support for: root, passwd, hesiod, union, nis, ndbm, file, exec, error. Dec 27 10:37:01 sf-02 amd[856]: AMFS: nfs, link, nfsx, nfsl, host, linkx, program, union, ufs, cdfs, Dec 27 10:37:01 sf-02 amd[856]: pcfs, auto, direct, toplvl, error, inherit. Dec 27 10:37:01 sf-02 amd[856]: FS: cd9660, nfs, nfs3, nullfs, msdosfs, ufs, unionfs. Dec 27 10:37:01 sf-02 amd[856]: Network: wire="132.65.16.0" (netnumber=132.65.16). Dec 27 10:37:01 sf-02 amd[856]: My ip addr is 127.0.0.1 Dec 27 10:37:01 sf-02 amd[857]: released controlling tty using setsid() Dec 27 10:37:01 sf-02 amd[857]: Locked process pages in memory ****************************** > > On Sat, Dec 27, 2008 at 4:51 PM, Danny Braniss wrote: > >> Yes, we found that it crashes when swap is used. > > > > on an amd64 architecture, amd could not plock it's pages in memory, and would, > > under memory preasure be swapped out, and break. > > I just run some tests under 7.1-PRERELEASE, and > > - it seems that plock is working. > > - amd is not being swapped out. > > are you running with amd -S ? > > danny > > > >> > >> > >> On Fri, Dec 26, 2008 at 6:02 PM, Rong-en Fan wrote: > >> > On Tue, Dec 23, 2008 at 12:44 AM, Lin Jui-Nan Eric wrote: > >> >> Dear listers, > >> >> > >> >> We currently found that amd frequently cores dump while loading is > >> >> high (about 4~5) after we upgrade world & kernel from 7.0-RELEASE to > >> >> 7.1-PRERELEASE. > >> >> > >> >> I have read -stable and svn log of 7-STABLE, but can not found a > >> >> report or a solution. Did anyone have the same issue? Thank you very > >> >> much. > >> >> > >> > > >> > According to my previous experience, amd 6.1.5 crashes > >> > under low memory situations. Not necessary high load. > >> > > >> > Regards, > >> > Rong-En Fan > >> > > >> _______________________________________________ > >> freebsd-stable@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable > >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > >> > > > > > > From owner-freebsd-stable@FreeBSD.ORG Sat Dec 27 13:07:15 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A98C91065670 for ; Sat, 27 Dec 2008 13:07:15 +0000 (UTC) (envelope-from grafan@gmail.com) Received: from mail-bw0-f19.google.com (mail-bw0-f19.google.com [209.85.218.19]) by mx1.freebsd.org (Postfix) with ESMTP id 019D38FC0C for ; Sat, 27 Dec 2008 13:07:14 +0000 (UTC) (envelope-from grafan@gmail.com) Received: by bwz12 with SMTP id 12so11182454bwz.19 for ; Sat, 27 Dec 2008 05:07:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=Wb2w2154rFntBjDS0bilx5P/tkIW6XvcrPSmlaG8nMs=; b=cWEmr0B0JGF+p0kyITv2zUMVZTOe4Jo8SnHjNYmtwmwNMGNcV+2JG6RYRXq1YIxKwq ySi34QVFITUWiKY5wvPWixSEnUAvfNmWFC8yggiwR8D/Eq/ID0jRHM1abJdSLOdLHmSU ubge0XDfFhLEfaEKBUNKKMUskNnQCtnOidURE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=JW9DJbvib3hA19/M7WiDBZsKgiwRSxRQmHgXb08IFhQsJRZFi0wVVR2xF13ENBRmws g9pmqjrPp5f7vCPKRSbWF3mI6FctxwKSa7Pjl6zolYX1y7fDE9cp9sEO+dQeANdQyNOq 7RRTxGlUK3Zw27QDBsaR85c8FlOcItUvPnQKI= Received: by 10.181.31.16 with SMTP id i16mr4385719bkj.129.1230383233615; Sat, 27 Dec 2008 05:07:13 -0800 (PST) Received: by 10.181.22.6 with HTTP; Sat, 27 Dec 2008 05:07:13 -0800 (PST) Message-ID: <6eb82e0812270507x1cca69d0tac0768f9f42044b6@mail.gmail.com> Date: Sat, 27 Dec 2008 21:07:13 +0800 From: "Rong-en Fan" To: "Danny Braniss" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47713ee10812220844r7889d286l3a98f294d780ccc0@mail.gmail.com> <6eb82e0812260202m1d8816c5mc7b0991514f83853@mail.gmail.com> <47713ee10812261117o6f772843o53ec9542bc773141@mail.gmail.com> <47713ee10812270105o5866aa27u9998539dc127e549@mail.gmail.com> Cc: stable@freebsd.org, Lin Jui-Nan Eric Subject: Re: amd(8) cores dump when load high X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Dec 2008 13:07:15 -0000 On Sat, Dec 27, 2008 at 7:03 PM, Danny Braniss wrote: >> No, we do not running amd with -S. >> >> # ps auxww | grep amd >> root 706 0.0 0.1 7660 5416 ?? Ss Wed05PM 4:48.12 >> /usr/sbin/amd -p -k amd64 -x all /net amd.map >> > well, I'm running 7.1-PRERELEASE, what does the amd logs show? > [...] > Dec 27 10:37:01 sf-02 amd[857]: Locked process pages in memory > ****************************** Hmm.. interesting, I got this Dec 26 15:32:11 bsd2 amd[39723]: Couldn't lock process pages in memory using mlo ckall(): Resource temporarily unavailable w/ 7-STABLE around Sep 4. I don't put plock = no in amd.conf, so by default it's plock'ed. Regards, Rong-En Fan From owner-freebsd-stable@FreeBSD.ORG Sat Dec 27 13:30:44 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E179106564A for ; Sat, 27 Dec 2008 13:30:44 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from flat.berklix.org (flat.berklix.org [83.236.223.115]) by mx1.freebsd.org (Postfix) with ESMTP id CC0988FC12 for ; Sat, 27 Dec 2008 13:30:43 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from js.berklix.net (p549A7D90.dip.t-dialin.net [84.154.125.144]) (authenticated bits=0) by flat.berklix.org (8.13.8/8.13.8) with ESMTP id mBRDBsBo021168 for ; Sat, 27 Dec 2008 14:11:56 +0100 (CET) (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by js.berklix.net (8.13.8/8.13.8) with ESMTP id mBRDBisg038227 for ; Sat, 27 Dec 2008 14:11:45 +0100 (CET) (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id mBRDAHIY009547 for ; Sat, 27 Dec 2008 14:10:23 +0100 (CET) (envelope-from jhs@fire.js.berklix.net) Message-Id: <200812271310.mBRDAHIY009547@fire.js.berklix.net> From: "Julian Stacey" Organization: http://berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://berklix.com In-reply-to: Your message "Sat, 27 Dec 2008 14:03:15 +0100." Date: Sat, 27 Dec 2008 14:10:17 +0100 Sender: jhs@berklix.org Cc: stable@freebsd.org Subject: Re: amd.core on 7.1-BETA2 amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Dec 2008 13:30:44 -0000 "Julian Stacey" wrote: > Hi stable@, > I have been seeing some amd core dumps in / running 7.1-BETA2 amd64 PS I see with cd / ; /bin/ls -l | grep host lrwxrwxrwx 1 root wheel 5 Dec 27 12:36 carp -> /host lrwxrwxrwx 1 root wheel 5 Dec 27 13:41 host -> /host (carp is nothing I deliberately set up) host -> /host is obviously wrong, should be a directory, something keeps removing the directory & creating this recursive symbolic link. Cheers, Julian -- Julian Stacey: BSDUnixLinux C Prog Admin SysEng Consult Munich www.berklix.com Mail plain ASCII text. HTML & Base64 text are spam. www.asciiribbon.org From owner-freebsd-stable@FreeBSD.ORG Sat Dec 27 13:30:45 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 555AC1065674 for ; Sat, 27 Dec 2008 13:30:45 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from flat.berklix.org (flat.berklix.org [83.236.223.115]) by mx1.freebsd.org (Postfix) with ESMTP id D3D9D8FC13 for ; Sat, 27 Dec 2008 13:30:44 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from js.berklix.net (p549A7D90.dip.t-dialin.net [84.154.125.144]) (authenticated bits=0) by flat.berklix.org (8.13.8/8.13.8) with ESMTP id mBRD55Rg020447 for ; Sat, 27 Dec 2008 14:05:08 +0100 (CET) (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by js.berklix.net (8.13.8/8.13.8) with ESMTP id mBRD4h6r038127 for ; Sat, 27 Dec 2008 14:04:44 +0100 (CET) (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id mBRD3Fl5085305 for ; Sat, 27 Dec 2008 14:03:21 +0100 (CET) (envelope-from jhs@fire.js.berklix.net) Message-Id: <200812271303.mBRD3Fl5085305@fire.js.berklix.net> To: stable@freebsd.org From: "Julian Stacey" Organization: http://berklix.com BSD Linux Unix Consultancy, Munich Germany. User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://berklix.com/~jhs/cv/ Date: Sat, 27 Dec 2008 14:03:15 +0100 Sender: jhs@berklix.org Cc: Subject: amd.core on 7.1-BETA2 amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Dec 2008 13:30:45 -0000 Hi stable@, I have been seeing some amd core dumps in / running 7.1-BETA2 amd64 with rc.conf amd_flags="-l syslog -n -r -t 3 /host /etc/amd.map" I recall someone else mentioned amd cores recently too. I have reinstalled with /etc/make.conf CFLAGS += -g -static # for gdb debugger For /usr/src/usr.sbin/amd & installed without -s so: file `which amd` /usr/sbin/amd: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), for FreeBSD 7.0 (700112), statically linked, FreeBSD-style, not stripped If I can get it to core again I will provide a backtrace In hope of producing something perhaps interesting for re@ I will cvs -R export -r RELENG_7_1 src # make world Cheers, Julian -- Julian Stacey: BSDUnixLinux C Prog Admin SysEng Consult Munich www.berklix.com Mail plain ASCII text. HTML & Base64 text are spam. www.asciiribbon.org From owner-freebsd-stable@FreeBSD.ORG Sat Dec 27 14:32:36 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB9C2106564A for ; Sat, 27 Dec 2008 14:32:36 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id 975A98FC20 for ; Sat, 27 Dec 2008 14:32:36 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mobileKamikaze.norad (p5DCF339C.dip.t-dialin.net [93.207.51.156]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id 6D49C8A0113; Sat, 27 Dec 2008 15:13:33 +0100 (CET) Message-ID: <49563802.7090801@bsdforen.de> Date: Sat, 27 Dec 2008 15:13:22 +0100 From: Dominic Fandrey User-Agent: Thunderbird 2.0.0.18 (X11/20081123) MIME-Version: 1.0 To: Lin Jui-Nan Eric References: <47713ee10812220844r7889d286l3a98f294d780ccc0@mail.gmail.com> In-Reply-To: <47713ee10812220844r7889d286l3a98f294d780ccc0@mail.gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: amd(8) cores dump when load high X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Dec 2008 14:32:36 -0000 Lin Jui-Nan Eric wrote: > Dear listers, > > We currently found that amd frequently cores dump while loading is > high (about 4~5) after we upgrade world & kernel from 7.0-RELEASE to > 7.1-PRERELEASE. > > I have read -stable and svn log of 7-STABLE, but can not found a > report or a solution. Did anyone have the same issue? Thank you very > much. When I work on large pictures in Gimp (i.e. 8000x6000), not lying on an amd mounted file system amd dies on my systems. From owner-freebsd-stable@FreeBSD.ORG Sat Dec 27 15:22:55 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF50E1065670 for ; Sat, 27 Dec 2008 15:22:55 +0000 (UTC) (envelope-from ericlin@tamama.org) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by mx1.freebsd.org (Postfix) with ESMTP id 721FC8FC1D for ; Sat, 27 Dec 2008 15:22:55 +0000 (UTC) (envelope-from ericlin@tamama.org) Received: by yw-out-2324.google.com with SMTP id 9so2138673ywe.13 for ; Sat, 27 Dec 2008 07:22:54 -0800 (PST) Received: by 10.150.192.4 with SMTP id p4mr22332286ybf.29.1230391373631; Sat, 27 Dec 2008 07:22:53 -0800 (PST) Received: by 10.151.74.12 with HTTP; Sat, 27 Dec 2008 07:22:53 -0800 (PST) Message-ID: <47713ee10812270722j2570de85jcd9b218b5d73dded@mail.gmail.com> Date: Sat, 27 Dec 2008 23:22:53 +0800 From: "Lin Jui-Nan Eric" To: "Rong-en Fan" In-Reply-To: <6eb82e0812270507x1cca69d0tac0768f9f42044b6@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47713ee10812220844r7889d286l3a98f294d780ccc0@mail.gmail.com> <6eb82e0812260202m1d8816c5mc7b0991514f83853@mail.gmail.com> <47713ee10812261117o6f772843o53ec9542bc773141@mail.gmail.com> <47713ee10812270105o5866aa27u9998539dc127e549@mail.gmail.com> <6eb82e0812270507x1cca69d0tac0768f9f42044b6@mail.gmail.com> Cc: stable@freebsd.org Subject: Re: amd(8) cores dump when load high X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Dec 2008 15:22:55 -0000 I got "Couldn't lock process pages in memory using mlockall()" too: Dec 27 23:20:38 worker1 amd[90422]: switched to logfile "syslog" Dec 27 23:20:38 worker1 amd[90422]: AM-UTILS VERSION INFORMATION: Dec 27 23:20:38 worker1 amd[90422]: Copyright (c) 1997-2006 Erez Zadok Dec 27 23:20:38 worker1 amd[90422]: Copyright (c) 1990 Jan-Simon Pendry Dec 27 23:20:38 worker1 amd[90422]: Copyright (c) 1990 Imperial College of Science, Technology & Medicine Dec 27 23:20:38 worker1 amd[90422]: Copyright (c) 1990 The Regents of the University of California. Dec 27 23:20:38 worker1 amd[90422]: am-utils version 6.1.5 (build 701100). Dec 27 23:20:38 worker1 amd[90422]: Report bugs to https://bugzilla.am-utils.org/ or am-utils@am-utils.org. Dec 27 23:20:38 worker1 amd[90422]: Configured by David O'Brien on date 4-December-2007 PST. Dec 27 23:20:38 worker1 amd[90422]: Built by root@worker1 on date Sun Nov 30 00:20:03 CST 2008. Dec 27 23:20:38 worker1 amd[90422]: cpu=amd64 (little-endian), arch=amd64, karch=amd64. Dec 27 23:20:38 worker1 amd[90422]: full_os=freebsd7.1, os=freebsd7, osver=7.1, vendor=undermydesk, distro=The FreeBSD Project. Dec 27 23:20:38 worker1 amd[90422]: domain=unknown.domain, host=worker1, hostd=worker1.unknown.domain. Dec 27 23:20:38 worker1 amd[90422]: Map support for: root, passwd, union, nis, ndbm, file, exec, error. Dec 27 23:20:38 worker1 amd[90422]: AMFS: nfs, link, nfsx, nfsl, host, linkx, program, union, ufs, cdfs, Dec 27 23:20:38 worker1 amd[90422]: pcfs, auto, direct, toplvl, error, inherit. Dec 27 23:20:38 worker1 amd[90422]: FS: cd9660, nfs, nfs3, nullfs, msdosfs, ufs, unionfs. Dec 27 23:20:38 worker1 amd[90422]: Network: wire="10.1.1.0" (netnumber=10.1.1). Dec 27 23:20:38 worker1 amd[90422]: My ip addr is 127.0.0.1 Dec 27 23:20:38 worker1 amd[90423]: released controlling tty using setsid() Dec 27 23:20:38 worker1 amd[90423]: Couldn't lock process pages in memory using mlockall(): Resource temporarily unavailable Dec 27 23:20:38 worker1 amd[90423]: file server localhost, type local, state starts up Dec 27 23:20:38 worker1 amd[90423]: Trying mount of amd.map on /net fstype toplvl mount_type non-autofs Dec 27 23:20:38 worker1 amd[90423]: creating mountpoint directory '/net' Dec 27 23:20:38 worker1 amd[90424]: /net: disabling nfs congestion window Dec 27 23:20:38 worker1 amd[90423]: first time load of map amd.map succeeded Dec 27 23:20:38 worker1 amd[90423]: amd.map mounted fstype toplvl on /net Dec 27 23:20:38 worker1 amd[90423]: /net set to never timeout I don't have a amd.conf: worker1 [/] -jnlin- ls -al /etc/amd.conf ls: /etc/amd.conf: No such file or directory On Sat, Dec 27, 2008 at 9:07 PM, Rong-en Fan wrote: > On Sat, Dec 27, 2008 at 7:03 PM, Danny Braniss wrote: >>> No, we do not running amd with -S. >>> >>> # ps auxww | grep amd >>> root 706 0.0 0.1 7660 5416 ?? Ss Wed05PM 4:48.12 >>> /usr/sbin/amd -p -k amd64 -x all /net amd.map >>> >> well, I'm running 7.1-PRERELEASE, what does the amd logs show? >> > [...] >> Dec 27 10:37:01 sf-02 amd[857]: Locked process pages in memory >> ****************************** > > Hmm.. interesting, I got this > > Dec 26 15:32:11 bsd2 amd[39723]: Couldn't lock process pages in memory using mlo > ckall(): Resource temporarily unavailable > > w/ 7-STABLE around Sep 4. I don't put plock = no in amd.conf, so > by default it's plock'ed. > > Regards, > Rong-En Fan >