Date: Tue, 16 Apr 2013 10:56:31 -0700 From: Cy Schubert <Cy.Schubert@komquats.com> To: current@freebsd.org Cc: cschuber@gmail.com Subject: Stack Overflow in GEOM Message-ID: <201304161756.r3GHuVmu003474@slippy.cwsent.com>
next in thread | raw e-mail | index | archive | help
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? ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: <SAMSUNG SP0802N TK100-24> ATA-7 device ada0: 100.000MB/s transfers (UDMA5, PIO 8192bytes) ada0: 76351MB (156368016 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad0 ada1 at ata0 bus 0 scbus0 target 1 lun 0 ada1: <Maxtor 6Y120P0 YAR41BW0> ATA-7 device ada1: 133.000MB/s transfers (UDMA6, PIO 8192bytes) ada1: 117246MB (240121728 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad1 ada2 at ata2 bus 0 scbus2 target 0 lun 0 ada2: <WDC WD5000AAKS-00D2B0 12.01C02> ATA-8 SATA 2.x device ada2: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) ada2: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada2: Previously was known as ad4 ada3 at ata3 bus 0 scbus3 target 0 lun 0 ada3: <WDC WD3200KS-00PFB0 21.00M21> ATA-7 SATA 2.x device ada3: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) ada3: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C) ada3: Previously was known as ad6 SMP: AP CPU #1 Launched! panic: stack overflow detected; backtrace may be corrupted cpuid = 1 KDB: enter: panic [ thread pid 13 tid 100009 ] Stopped at kdb_enter+0x3d: movl $0,kdb_why db> bt Tracing pid 13 tid 100009 td 0x872d6000 kdb_enter(80ca7886,80ca7886,80ca9523,86edcae0,1,...) at kdb_enter+0x3d/frame 0x86edca98 panic(80ca9523,86edcb70,80713dd2,86edcbd8,86edcafc,...) at panic+0x141/frame 0x86edcad4 __stack_chk_init(86edcbd8,86edcafc,86edcaf8,86edcafc,64,...) at __stack_chk_init/frame 0x86edcae0 g_label_disk_ident_taste(87b7dc80,86edcbd8,80,0,0,...) at g_label_disk_ident_taste+0x102/frame 0x86edcb70 g_label_taste(80d26b88,872ff500,0,872ff480,872d6000,...) at g_label_taste+0x3ca/frame 0x86edcc6c g_new_provider_event(872ff500,0,25c,80c9798e,0,...) at g_new_provider_event+0xb1/frame 0x86edcc88 g_run_events(0,86edcd08,222db60d,83725616,b10094f2,...) at g_run_events+0x19f/frame 0x86edccc4 fork_exit(8070d140,0,86edcd08) at fork_exit+0xa3/frame 0x86edccf4 fork_trampoline() at fork_trampoline+0x8/frame 0x86edccf4 --- trap 0, eip = 0, esp = 0x86edcd40, ebp = 0 --- db> I've been poking at this off and on last night. Any ideas? -- Cheers, Cy Schubert <Cy.Schubert@komquats.com> FreeBSD UNIX: <cy@FreeBSD.org> Web: http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201304161756.r3GHuVmu003474>