Moving this to -current and -stable and following up... Something is broken with coredumps on stable/8 amd64. I tried a vanilla 8.2-RC3 and yesterday's csup of stable/8; neither can dump a core with 'sysctl debug.kdb.panic=1'. For the 8.2-RC3 / amd64 / GENERIC install, I used the memstick image, installed on ad7 (a 250GB SATA drive), used the default partition map, and set dumpdev to AUTO. I added enough tracing to show that the second panic is due to the syncer process flushing buffers to the other filesystems in parallel with the dump. I've seen this panic and a similar one 'buffer not locked' coming from ffs_write(). One time out of about 30 the core ran to completion, but slowly (~1MB/sec). Other times the dump just locks up completely with no other output. Does anyone know what might have changed to expose this problem? I don't ever see it under 7.1. Thanks, Andrew On Feb 3, 2011, at 12:11 AM, Eugene Grosbein wrote:> On 02.02.2011 00:50, Gleb Smirnoff wrote: > >> E> Uptime: 8h3m51s >> E> Dumping 4087 MB (3 chunks) >> E> chunk 0: 1MB (150 pages) ... ok >> E> chunk 1: 3575MB (915088 pages) 3559 3543panic: bufwrite: buffer is not busy??? >> E> cpuid = 3 >> E> Uptime: 8h3m52s >> E> Automatic reboot in 15 seconds - press a key on the console to abort >> Can you add KDB_TRACE option to kernel? Your boxes for some reason can't >> dump core, but with this option we will have at least trace. > > I see Mike Tancsa's box has "bufwrite: buffer is not busy???" problem too. > Has anyone a thought how to fix generation of crashdumps? > > Eugene Grosbein > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"-------------------------------------------------- Andrew Boyer aboyer@averesystems.com
On week -current I have same problem, my box paniced every 2-15 min. I resolve problem by next steps - unplug network connectors from 2 intel em (82574L) cards. I think last time that mpd5 related panic, but mpd5 work with another re interface interated on MB. I think it may be em related panic, or em+mpd5. Wed, 16 Feb 2011 12:08:30 -0500 ?????? ?? Andrew Boyer <aboyer@averesystems.com>:> Moving this to -current and -stable and following up... > > Something is broken with coredumps on stable/8 amd64. I tried a vanilla > 8.2-RC3 and yesterday's csup of stable/8; neither can dump a core with 'sysctl > debug.kdb.panic=1'. > > For the 8.2-RC3 / amd64 / GENERIC install, I used the memstick image, > installed on ad7 (a 250GB SATA drive), used the default partition map, and set > dumpdev to AUTO. > > I added enough tracing to show that the second panic is due to the syncer > process flushing buffers to the other filesystems in parallel with the dump. > I've seen this panic and a similar one 'buffer not locked' coming from > ffs_write(). One time out of about 30 the core ran to completion, but slowly > (~1MB/sec). Other times the dump just locks up completely with no other > output. > > Does anyone know what might have changed to expose this problem? > > I don't ever see it under 7.1. > > Thanks, > Andrew > > On Feb 3, 2011, at 12:11 AM, Eugene Grosbein wrote: > > > On 02.02.2011 00:50, Gleb Smirnoff wrote: > > > >> E> Uptime: 8h3m51s > >> E> Dumping 4087 MB (3 chunks) > >> E> chunk 0: 1MB (150 pages) ... ok > >> E> chunk 1: 3575MB (915088 pages) 3559 3543panic: bufwrite: buffer is not > busy??? > >> E> cpuid = 3 > >> E> Uptime: 8h3m52s > >> E> Automatic reboot in 15 seconds - press a key on the console to abort > >> Can you add KDB_TRACE option to kernel? Your boxes for some reason can't > >> dump core, but with this option we will have at least trace. > > > > I see Mike Tancsa's box has "bufwrite: buffer is not busy???" problem too. > > Has anyone a thought how to fix generation of crashdumps? > > > > Eugene Grosbein > > > > > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > -------------------------------------------------- > Andrew Boyer aboyer@averesystems.com > > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Not sure if the CC: line needs to be trimmed, leaving it as is for now. On Sun, Feb 20, 2011 at 7:46 AM, Jeremy Chadwick <freebsd@jdc.parodius.com> wrote:> On Sun, Feb 20, 2011 at 10:30:52AM -0500, Mike Tancsa wrote: >> On 2/20/2011 9:33 AM, Andrey Smagin wrote: >> > On week -current I have same problem, my box paniced every 2-15 min. I resolve problem by next steps - unplug network connectors from 2 intel em (82574L) cards. I think last time that mpd5 related panic, but mpd5 work with another re interface interated on MB. I think it may be em related panic, or em+mpd5. >> >> The latest panic I saw didnt have anything to do with em. ?Are you sure >> your crashes are because of the nic drive ? > > Not to mention, the error string the OP provided (see Subject) is only > contained in one file: sys/ufs/ffs/ffs_vfsops.c, function > ffs_bufwrite(). ?So, that would be some kind of weird filesystem-related > issue, not NIC-specific. ?I have no idea how to debug said problem.I can semi-reliably reproduce this panic message on a 9-CURRENT box, with sources from March 7. On this box, it happens every other time I start hastd. hastd creates the 12 GEOM providers used to create a ZFS pool. A simple "service hastd onestart" will generate the panic. Is there any extra info that needed to help track this down? -- Freddie Cash fjwcash@gmail.com