Bug 155421

Summary: [hang] System can't dump corefile [regression]
Product: Base System Reporter: Andrew Boyer <aboyer>
Component: kernAssignee: Andriy Gapon <avg>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: Unspecified   
Hardware: Any   
OS: Any   

Description Andrew Boyer 2011-03-09 20:30:12 UTC
Release 8.2 (and 8.2-RC3 before it, at least) do not appear to be able
to dump core.  This works reliably in previous releases.

node1 is an 8-core system with 72GB of RAM and a 250GB drive plugged
into an onboard ICH10R SATA port.

node2 is an 8-core system with 64GB of RAM and a 250GB drive plugged
into an onboard ESB2 SATA port.

8.2 was installed from a USB drive.  All space was allocated to the
first slice and the default partition scheme was used.  swap is set
to 4GB.

dumpdev="AUTO" is set in /etc/rc.conf, and /dev/dumpdev exists.

Initiating a core with 'sysctl debug.kdb.panic=1' results in one of
several hangs:

 - no progress at all
 - very, very slow progress
 - a secondary panic on 'bufwrite: buffer is not busy'
 - other secondary panics

Examples:
=== node1 ===
# sysctl debug.kdb.panic=1
debug.kdb.panic: 0panic: kdb_sysctl_panic
cpuid = 4
KDB: stack backtrace:
...
Uptime: 20m50s
Physical memory: 73706 MB
Dumping 2780 MB:

=== node2 ===
# sysctl debug.kdb.panic=1
debug.kdb.panic: 0panic: kdb_sysctl_panic
cpuid = 4
KDB: stack backtrace:
...
Uptime: 5m50s
Physical memory: 65521 MB
Dumping 2437 MB:

Other things I have tried with the same results:
- Explicitly specifying the dump device e.g. 'dumpon -v /dev/ad0s1b'
- Increasing swap from 4GB to 32GB
- Changing the SATA controller mode to Compatible, Enhanced, and AHCI
- Booting from a SAS HDD connected to a SAS1068e

Fix: 

The issue may be that the syncer is still doing filesystem updates in
parallel with the attempt to dump core.  I added enough debugging output
to follow the dumper's progress through the first few steps of the dump.
It doesn't seem right that other things are running in parallel with a
panic/coredump.
How-To-Repeat: 1. Set dumpdev to 'AUTO' in /etc/rc.conf
2. Run '/etc/rc.d/dumpon restart', or just reboot
3. Run 'sysctl debug.kdb.panic=1'
Comment 1 Domagoj Smolčić 2012-02-08 16:17:48 UTC
I can confirm existance of this problem.

However, it doesn't occur on ALL machines(8.2), so it's also not
reproducible on ALL machines(8.2).

I have 3 machines running R8.2.  On first (i386) and second (amd64)
dump works.  On third (amd64 - my laptop) dump hangs as OP described

omagoj Smol=E8i=E6
Comment 2 Andriy Gapon freebsd_committer freebsd_triage 2012-03-14 20:23:35 UTC
Responsible Changed
From-To: freebsd-bugs->avg

Take as a possible duplicate of PR 139614.
Comment 3 Andriy Gapon freebsd_committer freebsd_triage 2012-06-07 09:12:04 UTC
State Changed
From-To: open->patched

Update to the state of of PR 139614
Comment 4 Andriy Gapon freebsd_committer freebsd_triage 2012-07-16 12:14:06 UTC
State Changed
From-To: patched->closed

See PR 139614.