From owner-freebsd-i386@FreeBSD.ORG Mon Sep 27 14:40:19 2004 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9674916A4CE for ; Mon, 27 Sep 2004 14:40:19 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7548543D5F for ; Mon, 27 Sep 2004 14:40:19 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.11/8.12.11) with ESMTP id i8REeJkE048857 for ; Mon, 27 Sep 2004 14:40:19 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i8REeJHF048856; Mon, 27 Sep 2004 14:40:19 GMT (envelope-from gnats) Date: Mon, 27 Sep 2004 14:40:19 GMT Message-Id: <200409271440.i8REeJHF048856@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: db Subject: Re: i386/71392: 5.3-Beta2 crash: 'no buffers busy' after final sync X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: db List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2004 14:40:19 -0000 The following reply was made to PR i386/71392; it has been noted by GNATS. From: db To: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= Cc: freebsd-gnats-submit@freebsd.org Subject: Re: i386/71392: 5.3-Beta2 crash: 'no buffers busy' after final sync Date: Mon, 27 Sep 2004 16:32:50 +0200 On Monday 27 September 2004 15:37, you wrote: > db writes: > > Upgraded to 5.3-Beta5, problem is still there. This is the last > > beta, so how can a bug like this still be unhandled? > > Because you didn't volunteer to track it down and fix it. 1. I'm not a C programmer. 2. I'm not a kernel hacker. 3. I spend all my time on school/work/lockdown (1.1.0 o it's way). So the best I can do is report the bug and do that you debuggers tell me to do. > Sniping aside, three points: > > 1) "No buffers busy after final sync" is not a bug. You should get > that message every time you shut down. I didn't write "No buffers busy after final sync", someone at FreeBSD did. > 2) Since the kernel panic you are experiencing occurrs after final > sync on poweroff, and therefore does not cause significant loss of > function or (more importantly) data corruption, it is not a high- > priority issue. Hm ok.......... > 3) You did not follow the documented procedure for reporting a kernel > panic. Section 18 of the FAQ contains instructions for producing > a backtrace, which is the minimum information required. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/65658 http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/65702 What have I learned from the above? Well, most users would think "hm, nobody cares, I gonna stop writing bug reports", but I decided it give it another try. > You can't expect a misfiled and incomplete report of a low-priority > issue to be fast-tracked ahead of the 4,415 other open bug reports in > our database, or even the 3,078 that aren't filed under doc or ports. I don't, but I except/hope a bug like this will be fixed before 5.3 is released. > In closing, the panic you get when trying to power your system off is > mostly likely related to ACPI - either a bug in the ACPI code, or > (more likely) a bug in your system's DSDT. Try booting with ACPI > disabled. Maybe a stupid question, but how? I found http://www.freebsd.org/cgi/man.cgi?query=acpi&sektion=4 and it says: "To disable the acpi driver completely, set the kernel environment variable hint.acpi.0.disabled to 1", but I haven't got that one. I got: debug.acpi.acpi_ca_version: 0x20040527 debug.acpi.semaphore_debug: 0 hw.acpi.supported_sleep_state: S1 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S1 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.reset_video: 1 hw.acpi.cpu.throttle_max: 2 hw.acpi.cpu.throttle_state: 2 hw.acpi.cpu.cx_supported: C1/0 C2/90 hw.acpi.cpu.cx_lowest: C1 hw.acpi.cpu.cx_usage: 100.00% 0.00% machdep.acpi_timer_freq: 3579545 machdep.acpi_root: 1012112 dev.acpi.0.%desc: VIA694 AWRDACPI dev.acpi.0.%driver: acpi dev.acpi.0.%parent: nexus0 dev.acpi_sysresource.0.%desc: System Resource dev.acpi_sysresource.0.%driver: acpi_sysresource dev.acpi_sysresource.0.%location: handle=\_SB_.MEM_ dev.acpi_sysresource.0.%pnpinfo: _HID=PNP0C01 _UID=0 dev.acpi_sysresource.0.%parent: acpi0 dev.acpi_sysresource.1.%desc: System Resource dev.acpi_sysresource.1.%driver: acpi_sysresource dev.acpi_sysresource.1.%location: handle=\_SB_.PCI0.SYSR dev.acpi_sysresource.1.%pnpinfo: _HID=PNP0C02 _UID=1 dev.acpi_sysresource.1.%parent: acpi0 dev.acpi_timer.0.%desc: 24-bit timer at 3.579545MHz dev.acpi_timer.0.%driver: acpi_timer dev.acpi_timer.0.%location: unknown dev.acpi_timer.0.%pnpinfo: unknown dev.acpi_timer.0.%parent: acpi0 dev.cpu.0.%parent: acpi0 dev.acpi_button.0.%desc: Power Button dev.acpi_button.0.%driver: acpi_button dev.acpi_button.0.%location: handle=\_SB_.PWRB dev.acpi_button.0.%pnpinfo: _HID=PNP0C0C _UID=0 dev.acpi_button.0.%parent: acpi0 dev.acpi_button.1.%desc: Sleep Button dev.acpi_button.1.%driver: acpi_button dev.acpi_button.1.%location: handle=\_SB_.SLPB dev.acpi_button.1.%pnpinfo: _HID=PNP0C0E _UID=0 dev.acpi_button.1.%parent: acpi0 dev.acpi_button.1.wake: 1 dev.pcib.0.%parent: acpi0 dev.atpic.0.%parent: acpi0 dev.atdma.0.%parent: acpi0 dev.attimer.0.%parent: acpi0 dev.attimer.1.%parent: acpi0 dev.npxisa.0.%parent: acpi0 dev.fdc.0.%parent: acpi0 dev.sio.0.%parent: acpi0 dev.sio.1.%parent: acpi0 dev.ppc.0.%parent: acpi0 dev.psmcpnp.0.%parent: acpi0 dev.atkbdc.0.%parent: acpi0 br db