Bug 71392

Command - Result
shutdown -p now - Crash
shutdown -h now - All good
reboot -p - Crash
reboot - All good

br
db

I've just upgraded my system to 5.3-Beta4 and now a "shutdown -p now" gives 
me:

Uptime: 1m35s
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0xc
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc0572654
stack pointer = 0x10:0xd41e5cbc
frame pointer = 0x10:0xd41e5cdc
code segment = base rx0, limit 0xffff, type 0x1b
             = DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 16 (irq 5: re0)
trap nubmer = 12
panic: page fault
cpuid = 0
Uptime: 1m40s

Upgraded to 5.3-Beta5, problem is still there. This is the last beta, so how 
can a bug like this still be unhandled?

br
db

db <db@traceroute.dk> 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.

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.

 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.

 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.

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.

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.

DES
--=20
Dag-Erling Sm=F8rgrav - des@des.no

On Monday 27 September 2004 15:37, you wrote:
> db <db@traceroute.dk> 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

db <db@traceroute.dk> writes:
> On Monday 27 September 2004 15:37, you wrote:
> >  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.

Sorry, I'll correct the synopsis.

> 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're right, most developers don't care about PRs filed against
-CURRENT.  I assume that you read the freebsd-current mailing list,
and that you reported your problems there?

> > 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

Select "Boot FreeBSD with ACPI disabled" in the boot menu.

> http://www.freebsd.org/cgi/man.cgi?query=3Dacpi&sektion=3D4 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:
> [list of sysctl variables]

man device.hints
man loader.conf

DES
--=20
Dag-Erling Sm=F8rgrav - des@des.no

On Monday 27 September 2004 17:00, you wrote:
> You're right, most developers don't care about PRs filed against
> -CURRENT.  I assume that you read the freebsd-current mailing list,
> and that you reported your problems there?

Nope, normally when you report a bug to a mailling list, they tell you to use 
pr-send.

> > Maybe a stupid question, but how? I found
>
> Select "Boot FreeBSD with ACPI disabled" in the boot menu.

Doh! Hehe, done that and when writing "shutdown -p now" it just says:
The operating system has halted.
Please press any key to reboot.

br
db

Sometimes my computer can't find my (new) Level1 gigabit card (realtek chip, 
so it use the re driver). When my NIC is _not_ found, I can use "shutdown -p 
now" without freebsd crashing.

br
db

Comment 9 Remko Lodder 2005-10-27 16:15:45 UTC

State Changed
From-To: open->closed

I requested feedback from the submitted and he indicates that the problem 
is no longer acurate. So with this; close the PR.