Re: Stack Overflow in GEOM

On Tue, Apr 16, 2013 at 11:13 AM, David Wolfskill <david_at_catwhisker.org>wrote:

> On Tue, Apr 16, 2013 at 10:56:31AM -0700, Cy Schubert wrote:
> > Has anyone see this before? Just updated my CURRENT partitions on my
> > testbed and laptop. The laptop just boots but I've managed to capture
> this
> > on my testbed (attached to a serial port on another system).
> >
> > This is HEAD from yesterday (Apr 15) morning (PDT). The partition being
> > booted is ada0s1d. On my laptop it's ada0s3a. KSTACK_PAGES is 4. Is
> there a
> > way to quickly display that kern.kstack_pages from DDB?
> > ...
> > panic: stack overflow detected; backtrace may be corrupted
> > cpuid = 1
> > KDB: enter: panic
> > [ thread pid 13 tid 100009 ]
> > ....
>
> I'm seeing this, but my situation is ... reversed: my build machine came
> up OK:
>
> FreeBSD freebeast.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #1134
> r249538M/249542:1000030: Tue Apr 16 09:15:49 PDT 2013
> root_at_freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC  i386
>
> but my laptop exhibits symptoms that I *believe* resemble those you
> cited.  (I was unable to get a crash dump, and the machine rebooted too
> quickly after I typed "panic" at the ddb prompt.  I don't have a serial
> console on the laptop.)
>
> I had thought that it might be nvidia-driver-related (again), but I also
> note that the laptop has a single SATA drive, while the build machine
> has SCSI (possibly SAS -- machine is powered off for the day, since its
> work is done) drives.  Laptop also has 2x the memory the build machine
> does.  (They are each i386.)
>
> My last successful smoke-test for head on the laptop was yesterday:
>
> FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #869
>  r249502M/249503:1000030: Mon Apr 15 05:23:38 PDT 2013
> root_at_g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY  i386
>
> I had built head _at_r249538 this morning, and that's the build where
> my smoke-test failed.
>
>
This stack trace corruption was noted on svn-src-head_at_ as well, and appears
to be fixed with r249564.

-Jim