Re: sparc64 traps during probe (r293243)

[Marius Strobl]

On Fri, Jan 08, 2016 at 10:42:33AM -0500, Kurt Lidl wrote:
> I recently updated a sparc64 V120 from r291993
> to r293243, and it now traps during the
> autoconfiguration phase of the kernel boot:
> 

<...>

> -- data access exception sfar=0xfcf821ca0218 sfsr=0x41029 
> %o7=0xc06165e8 --

What code line does 0xc06165e8 translate to?

Marius

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: sparc64 traps during probe (r293243)

[Mark Cave-Ayland]

On 08/01/16 15:42, Kurt Lidl wrote:

> I recently updated a sparc64 V120 from r291993
> to r293243, and it now traps during the
> autoconfiguration phase of the kernel boot:
> 
> Hit [Enter] to boot immediately, or any other key for command prompt.
> Booting [/boot/kernel/kernel]...
> jumping to kernel entry at 0xc00b.
> GDB: no debug ports present
> KDB: debugger backends: ddb
> KDB: current backend: ddb
> Copyright (c) 1992-2016 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
> The Regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 11.0-CURRENT #4 r293243M: Thu Jan  7 13:50:04 EST 2016
> l...@ton.pix.net:/usr/obj/usr/src/sys/GENERIC sparc64
> gcc version 4.2.1 20070831 patched [FreeBSD]
> WARNING: WITNESS option enabled, expect reduced performance.
> VT: init without driver.
> real memory  = 2147483648 (2048 MB)
> avail memory = 2063785984 (1968 MB)
> cpu0: Sun Microsystems UltraSparc-IIe Processor (648.00 MHz CPU)
> 
> [...]
> 
> da0 at sym0 bus 0 scbus2 target 0 lun 0
> da0:  Fixed Direct Access SCSI-3 device
> da0: Serial Number UPL3P310365J
> da0: 80.000MB/s transfers (40.000MHz, offset 31, 16bit)
> da0: Command Queueing enabled
> da0: 34732MB (71132959 512 byte sectors)
> cd0 at ata2 bus 0 scbus0 target 0 lun 0
> cd0:  Removable CD-ROM SCSI device
> cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes)
> cd0: 393MB (201600 2048 byte sectors)
> da1 at sym0 bus 0 scbus2 target 1 lun 0
> da1:  Fixed Direct Access SCSI-3 device
> da1: Serial Number UPL3P3506STC
> da1: 80.000MB/s transfers (40.000MHz, offset 31, 16bit)
> da1: Command Queueing enabled
> da1: 34732MB (71132959 512 byte sectors)
> WARNING: WITNESS option enabled, expect reduced performance.
> Trying to mount root from zfs:sys/ROOT/default []...
> GEOM_MIRROR: Device mirror/gswap launched (2/2).
> [ thread pid 1 tid 12 ]
> Stopped at  tl0_utrap+0x20: ldx [%l0 + %l1], %l0
> db> bt
> Tracing pid 1 tid 12 td 0xf800016164d0
> KDB: reentering
> KDB: stack backtrace:
> kdb_reenter() at kdb_reenter+0x5c
> trap() at trap+0x2fc
> -- data access exception sfar=0xfcf821ca0218 sfsr=0x41029
> %o7=0xc06165e8 --
> sched_clock() at sched_clock+0x94
> statclock_cnt() at statclock_cnt+0x1c0
> handleevents() at handleevents+0x138
> timercb() at timercb+0x410
> tick_intr() at tick_intr+0x220
> -- interrupt level=0xe pil=0 %o7=0xc09c6c20 --
> -- kernel stack fault %o7=0xc00b1288 --
> db_read_bytes() at db_read_bytes+0x44
> KDB: reentering
> KDB: stack backtrace:
> kdb_reenter() at kdb_reenter+0x5c
> trap() at trap+0x2fc
> -- kernel stack fault %o7=0xc011f8f0 --
> db_read_bytes() at db_read_bytes+0x44
> KDB: reentering
> KDB: stack backtrace:
> kdb_reenter() at kdb_reenter+0x5c
> trap() at trap+0x2fc
> 
> And then the stack backtrace just keeps repeating.

This looks amazingly similar to what I get trying to boot FreeBSD under
QEMU, i.e. pointing at sched_clock():


Booting [/boot/kernel/kernel]...
jumping to kernel entry at 0xc00b.
GDB: no debug ports present
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2015 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.0-CURRENT #0 1eb7424(master): Thu Sep 24 06:41:18 BST 2015

mca@freebsd:/usr/home/mca/obj/sparc64.sparc64/usr/home/mca/src/sys/GENERIC
sparc64
gcc version 4.2.1 20070831 patched [FreeBSD]
WARNING: WITNESS option enabled, expect reduced performance.
VT: init without driver.
real memory  = 134217728 (128 MB)
avail memory = 98312192 (93 MB)
cpu0: Sun Microsystems UltraSparc-IIi Processor (100.00 MHz CPU)
random: entropy device external interface
kbd0 at kbdmux0
nexus0: 
nexus0: : incomplete
pcib0:  mem 0x1fe-0x1fe01ff irq
2032,2030,2031,2021 on nexus0
pcib0: Sabre, impl 0, version 0, IGN 0x1f, bus A, 33MHz
pcib0: DVMA map: 0xc000 to 0xc3ff 8192 entries
pcib0: [GIANT-LOCKED]
pci0:  on pcib0
pcib1:  at device 1.0 on pci0
pci1:  on pcib1
pcib2:  at device 1.1 on pci0
pci2:  on pcib2
ebus0:  port 0x4000-0x7fff mem 0x300-0x3ff at
device 3.0 on pci0
vgapci0:  mem
0x100-0x1ff,0x200-0x2000fff at device 2.0 on pci0
vgapci0: Boot video device
eeprom0:  addr 0x142000-0x143fff on ebus0
eeprom0: model mk48t59
ebus0:  addr 0 (no driver attached)
uart0: <16550 or compatible> addr 0x1403f8-0x1403ff irq 43 on ebus0
uart0: console (9600,n,8,1)
ebus0:  addr 0x140060-0x140067 (no driver attached)
pci0:  at device 4.0 (no driver attached)
atapci0:  port
0x8100-0x8107,0x8180-0x8183,0x8200-0x8207,0x8280-0x8283,0x8300-0x830f at
device 5.0 on pci0
ata2:  at channel 0 on atapci0
ata3:  at channel 1 on atapci0
cryptosoft0:  on nexus0
nexus0:  type unknown 

Re: panic: sbappendstream 1 [head/amd64 @r293419]

[Jonathan T. Looney]

On 1/8/16, 9:05 AM, "David Wolfskill"  wrote:

>After the first panic, I rebuilt the kernel without -DNO_CLEAN; the
>crash dump & other diagnostic info is from the clean build.
>
>January  8, 2016 at 05:57:27 AM PST
>
>FreeBSD freebeast.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1954
>r293419M/293420:1100093: Fri Jan  8 05:09:57 PST 2016
>r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64
>
>panic: sbappendstream 1
>
>...
>Unread portion of the kernel message buffer:
>panic: sbappendstream 1
>cpuid = 7
>KDB: stack backtrace:
>db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
>0xfe085e0595b0
>vpanic() at vpanic+0x182/frame 0xfe085e059630
>kassert_panic() at kassert_panic+0x126/frame 0xfe085e0596a0
>sbappendstream_locked() at sbappendstream_locked+0xa5/frame
>0xfe085e0596d0
>uipc_send() at uipc_send+0x942/frame 0xfe085e059780
>sosend_generic() at sosend_generic+0x42f/frame 0xfe085e059840
>kern_sendit() at kern_sendit+0x21b/frame 0xfe085e0598f0
>sendit() at sendit+0x126/frame 0xfe085e059940
>sys_sendmsg() at sys_sendmsg+0x61/frame 0xfe085e0599a0
>amd64_syscall() at amd64_syscall+0x2db/frame 0xfe085e059ab0
>Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe085e059ab0


The likely suspect here looks like r293405, which changed uipc_send() to
use sbappendstream_locked() instead of sbappend_locked().

However, I can't explain *why* that change is causing this problem without
further investigation.

Can you try reverting the change to see if that solves the problem you are
seeing?

Thanks!

Jonathan


>--- syscall (28, FreeBSD ELF64, sys_sendmsg), rip = 0x801270dfa, rsp =
>0x7fffa098, rbp = 0x7fffa0d0 ---
>KDB: enter: panic
>...
>Loaded symbols for /boot/kernel/autofs.ko
>#0  doadump (textdump=0) at pcpu.h:221
>221 pcpu.h: No such file or directory.
>in pcpu.h
>(kgdb) #0  doadump (textdump=0) at pcpu.h:221
>#1  0x8038205b in db_dump (dummy=,
>dummy2=false, 
>dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_command.c:533
>#2  0x80381e4e in db_command (cmd_table=0x0)
>at /usr/src/sys/ddb/db_command.c:440
>#3  0x80381be4 in db_command_loop ()
>at /usr/src/sys/ddb/db_command.c:493
>#4  0x8038467b in db_trap (type=, code=0)
>at /usr/src/sys/ddb/db_main.c:251
>#5  0x80a5cfe3 in kdb_trap (type=3, code=0, tf=out>)
>at /usr/src/sys/kern/subr_kdb.c:654
>#6  0x80e6a2a8 in trap (frame=0xfe085e0594e0)
>at /usr/src/sys/amd64/amd64/trap.c:549
>#7  0x80e4a317 in calltrap ()
>at /usr/src/sys/amd64/amd64/exception.S:234
>#8  0x80a5c6cb in kdb_enter (why=0x8137af3c "panic",
>msg=0x80 ) at cpufunc.h:63
>#9  0x80a1fb8f in vpanic (fmt=,
>ap=) at /usr/src/sys/kern/kern_shutdown.c:750
>#10 0x80a1f9e6 in kassert_panic (fmt=)
>at /usr/src/sys/kern/kern_shutdown.c:647
>#11 0x80aa3375 in sbappendstream_locked (sb=0xf80044212378,
>m=0xf800108c7200, flags=0) at /usr/src/sys/kern/uipc_sockbuf.c:642
>#12 0x80ab1a42 in uipc_send (so=0xf80044212000, flags=0,
>m=, nam=0x0, control=,
>td=0xf8001078e9a0) at /usr/src/sys/kern/uipc_usrreq.c:984
>#13 0x80aa5f5f in sosend_generic (so=0xf80044212000,
>addr=0x0, 
>uio=0xfe085e059890, top=,
>control=, flags=,
>td=0xfe085e059880) at /usr/src/sys/kern/uipc_socket.c:1349
>#14 0x80aac36b in kern_sendit (td=0xf8001078e9a0, s=6,
>mp=, flags=0, control=0x0, segflg=UIO_USERSPACE)
>at /usr/src/sys/kern/uipc_syscalls.c:906
>#15 0x80aac666 in sendit (td=0xf8001078e9a0,
>s=, mp=0xfe085e059958, flags=0)
>at /usr/src/sys/kern/uipc_syscalls.c:833
>#16 0x80aac6f1 in sys_sendmsg (td=0xf8001078e9a0,
>uap=0xfe085e059a40) at /usr/src/sys/kern/uipc_syscalls.c:1035
>#17 0x80e6b13b in amd64_syscall (td=0xf8001078e9a0, traced=0)
>at subr_syscall.c:135
>#18 0x80e4a5fb in Xfast_syscall ()
>at /usr/src/sys/amd64/amd64/exception.S:394
>#19 0x000801270dfa in ?? ()
>Previous frame inner to this frame (corrupt stack?)
>Current language:  auto; currently minimal
>(kgdb) 
>.
>
>As indicated above, this is with a GENERIC kernel.  My laptop (running
>a kernel built with the same sources, but a slightly customized kernel
>config) gets to the point of allowing me to login (via xdm), but when I
>fire off a command that creates xterms & tries to run tmux(1) in them,
>locks up (as far as I can tell), and a power-cycle is needed to recover.
>
>I can poke at the crash dump (given hints), make the dump and core.txt
>file
>available.
>
>Peace,
>david
>-- 
>David H. Wolfskill da...@catwhisker.org
>Those who would murder in the name of God or prophet are blasphemous
>cowards.
>
>See http://www.catwhisker.org/~david/publickey.gpg for my public key.

Re: panic: sbappendstream 1 [head/amd64 @r293419]

[Gleb Smirnoff]

On Fri, Jan 08, 2016 at 09:34:23AM -0500, Jonathan T. Looney wrote:
J> The likely suspect here looks like r293405, which changed uipc_send() to
J> use sbappendstream_locked() instead of sbappend_locked().
J> 
J> However, I can't explain *why* that change is causing this problem without
J> further investigation.

That is because sbappendstream() has invariant that socket buffer doesn't
have any records in it. But, if control data is sent, which is possible
for AF_UNIX, a record is made. Thus, we can't used optimized version for
AF_UNIX, only for AF_INET.

-- 
Totus tuus, Glebius.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: sparc64 traps during probe (r293243)

[Kurt Lidl]

On 1/8/16 1:58 PM, Marius Strobl wrote:

On Fri, Jan 08, 2016 at 10:42:33AM -0500, Kurt Lidl wrote:

I recently updated a sparc64 V120 from r291993
to r293243, and it now traps during the
autoconfiguration phase of the kernel boot:



<...>


-- data access exception sfar=0xfcf821ca0218 sfsr=0x41029
%o7=0xc06165e8 --


What code line does 0xc06165e8 translate to?

Marius


Unfortunately, I cannot tell you.  I managed to destroy the
/usr/lib/debug/boot/kernel directory for the kernel that didn't
work properly.

As noted in a different reply, a cross-built r293425 kernel
did boot, and I'm now re-building a native r293425 world on
the sparc64 host.

If it the native build doesn't work, I'll get the information
you wanted from that build.

Thanks.

-Kurt


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CURRENT: net/igb broken

[Eric Joyner]

Does your i210 now work with the reverted version of igb? I didn't get a
chance to follow up on this earlier.

Also, can you give us the device ID for the device? There are a couple
versions of the i210 hardware.

- Eric

On Sun, Oct 4, 2015 at 10:23 PM O. Hartmann 
wrote:

> On Fri, 2 Oct 2015 08:52:57 -0700
> Sean Bruno  wrote:
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >
> >
> >
> > On 10/02/15 00:47, O. Hartmann wrote:
> > > On Thu, 01 Oct 2015 15:39:11 + Eric Joyner 
> > > wrote:
> > >
> > >> Oliver,
> > >>
> > >> did you try Sean's suggestion?
> > >>
> > >> - Eric
> > >>
> > >> On Tue, Sep 22, 2015 at 1:10 PM Sean Bruno 
> > >> wrote:
> > >>
> > >
> > >
> > > On 09/21/15 23:23, O. Hartmann wrote:
> > > On Mon, 21 Sep 2015 21:13:18 + Eric Joyner
> > >  wrote:
> > >
> > >> If you do a diff between r288057 and r287761, there are
> > >> no differences between the sys/dev/e1000, sys/modules/em,
> > >> and sys/modules/igb directories. Are you sure r287761
> > >> actually works?
> > >
> > > I'm quite sure r287761 works (and r287762 doesn't), double
> > > checked this this morning again. I also checked r288093 and
> > > it is still not working.
> > >
> > > The ensure that I'm not the culprit and stupid here:
> > >
> > > I use a NanoBSD environment and the only thing that gets
> > > exchanged, is the underlying OS/OS revision. The
> > > configuration always stays the same. The base system for
> > > all of my tests is built from a clean source - (deleted
> > > obj/ dir, clean, fresh build into obj/ for every test I
> > > ran).
> > >
> > > I realised a funny thing. Playing around with
> > > enabling/disabling TSO (I have been told that could be the
> > > culprit in an earlier Email from this list) with the
> > > commend sequence:
> > >
> > > ifconfig igb1 down ifconfig igb1 -tso ifconfig igb1 up
> > > ifconfig igb1 down ifconfig igb1 tso ifconfig igb1 up . .
> > > .
> > >
> > > while a ping is pinging in the background a remote host
> > > connected to that specific interface, the ping does work
> > > for a while and dies then after a round trip of roughly 10
> > > - 20. I can reproduce this.
> > >
> > > is that observation of any help?
> > >
> > > Regards,
> > >
> > > oh
> > >
> > >>
> > >> On Mon, Sep 21, 2015 at 1:58 AM O. Hartmann
> > >>  wrote:
> > >>
> > >>> On Sat, 19 Sep 2015 11:23:44 -0700 Sean Bruno
> > >>>  wrote:
> > >>>
> > >
> > >
> > > On 09/18/15 10:20, Eric Joyner wrote:
> > >> He has an i210 -- he would want to revert
> > >> e1000_i210.[ch], too.
> > >>
> > >> Sorry for the thrash Sean -- it sounds like it
> > >> would be a good idea for you should revert this
> > >> patch, and Jeff and I can go look at trying these
> > >> shared code updates and igb changes internally
> > >> again. We at Intel really could've done a better
> > >> job of making sure these changes worked across a
> > >> wider variety of devices.
> > >>
> > >> - Eric
> > >
> > > I've reverted the changes to head.  I'll reopen the reviews
> > > and we can proceed from there.
> > >
> > > sean
> > >
> > >
> > >>
> > >> On Fri, Sep 18, 2015 at 9:50 AM Sean Bruno
> > >> >
> > >> wrote:
> > >>
> > >>
> > >>>
> > >>> r287762 broke the system
> > >>
> > >>
> > >> Before I revert this changeset *again* can you
> > >> test revert r287762 from if_igb.c, e1000_82575.c
> > >> and e1000_82575.h *only*
> > >>
> > >> That narrows down the change quite a bit.
> > >>
> > >> sean
>
> [...]
>
> > >>>
> > >>
> > I'm now on r288057 on that specific machine, supposedly
> > >>> reverted changes that seemingly has been identified as
> > >>> the culprit. Still NO change in behaviour!
> > >>>
> > >>> r287761 works with the same configuration on igb
> > >>> (i210), any further does not. Not ping/connect from the
> > >>> outside, no ping/connect from the inside. Tried
> > >>> different protocols (SAMBA, ssh, LDAP, DNS). Affected
> > >>> is/are only boxes with the igb driver and i210 chipset
> > >>> (we do not have other chips covered by igb).
> > >>>
> > >>> Regards, Oliver
>
> [...]
>
> > >
> > > For my entertainment (and HPS's), can you run HEAD and revert
> > > r287775?
> > >
> > > sean
>
> [...]
>
> > > I did as suggested:
> > >
> > > checking out the most recent HEAD of CURRENT this morning, which
> > > is/was for me 

Re: sparc64 traps during probe (r293243)

[Kurt Lidl]

On 1/8/16 11:57 AM, Mark Cave-Ayland wrote:

On 08/01/16 15:42, Kurt Lidl wrote:


I recently updated a sparc64 V120 from r291993
to r293243, and it now traps during the
autoconfiguration phase of the kernel boot:

Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
jumping to kernel entry at 0xc00b.
GDB: no debug ports present
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2016 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
 The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.0-CURRENT #4 r293243M: Thu Jan  7 13:50:04 EST 2016
 l...@ton.pix.net:/usr/obj/usr/src/sys/GENERIC sparc64
gcc version 4.2.1 20070831 patched [FreeBSD]
WARNING: WITNESS option enabled, expect reduced performance.
VT: init without driver.
real memory  = 2147483648 (2048 MB)
avail memory = 2063785984 (1968 MB)
cpu0: Sun Microsystems UltraSparc-IIe Processor (648.00 MHz CPU)

[...]

da0 at sym0 bus 0 scbus2 target 0 lun 0
da0:  Fixed Direct Access SCSI-3 device
da0: Serial Number UPL3P310365J
da0: 80.000MB/s transfers (40.000MHz, offset 31, 16bit)
da0: Command Queueing enabled
da0: 34732MB (71132959 512 byte sectors)
cd0 at ata2 bus 0 scbus0 target 0 lun 0
cd0:  Removable CD-ROM SCSI device
cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes)
cd0: 393MB (201600 2048 byte sectors)
da1 at sym0 bus 0 scbus2 target 1 lun 0
da1:  Fixed Direct Access SCSI-3 device
da1: Serial Number UPL3P3506STC
da1: 80.000MB/s transfers (40.000MHz, offset 31, 16bit)
da1: Command Queueing enabled
da1: 34732MB (71132959 512 byte sectors)
WARNING: WITNESS option enabled, expect reduced performance.
Trying to mount root from zfs:sys/ROOT/default []...
GEOM_MIRROR: Device mirror/gswap launched (2/2).
[ thread pid 1 tid 12 ]
Stopped at  tl0_utrap+0x20: ldx [%l0 + %l1], %l0
db> bt
Tracing pid 1 tid 12 td 0xf800016164d0
KDB: reentering
KDB: stack backtrace:
kdb_reenter() at kdb_reenter+0x5c
trap() at trap+0x2fc
-- data access exception sfar=0xfcf821ca0218 sfsr=0x41029
%o7=0xc06165e8 --
sched_clock() at sched_clock+0x94
statclock_cnt() at statclock_cnt+0x1c0
handleevents() at handleevents+0x138
timercb() at timercb+0x410
tick_intr() at tick_intr+0x220
-- interrupt level=0xe pil=0 %o7=0xc09c6c20 --
-- kernel stack fault %o7=0xc00b1288 --
db_read_bytes() at db_read_bytes+0x44
KDB: reentering
KDB: stack backtrace:
kdb_reenter() at kdb_reenter+0x5c
trap() at trap+0x2fc
-- kernel stack fault %o7=0xc011f8f0 --
db_read_bytes() at db_read_bytes+0x44
KDB: reentering
KDB: stack backtrace:
kdb_reenter() at kdb_reenter+0x5c
trap() at trap+0x2fc

And then the stack backtrace just keeps repeating.


This looks amazingly similar to what I get trying to boot FreeBSD under
QEMU, i.e. pointing at sched_clock():


Booting [/boot/kernel/kernel]...
jumping to kernel entry at 0xc00b.
GDB: no debug ports present
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2015 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
 The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.0-CURRENT #0 1eb7424(master): Thu Sep 24 06:41:18 BST 2015

mca@freebsd:/usr/home/mca/obj/sparc64.sparc64/usr/home/mca/src/sys/GENERIC
sparc64
gcc version 4.2.1 20070831 patched [FreeBSD]
WARNING: WITNESS option enabled, expect reduced performance.
VT: init without driver.
real memory  = 134217728 (128 MB)
avail memory = 98312192 (93 MB)
cpu0: Sun Microsystems UltraSparc-IIi Processor (100.00 MHz CPU)
random: entropy device external interface
kbd0 at kbdmux0
nexus0: 
nexus0: : incomplete
pcib0:  mem 0x1fe-0x1fe01ff irq
2032,2030,2031,2021 on nexus0
pcib0: Sabre, impl 0, version 0, IGN 0x1f, bus A, 33MHz
pcib0: DVMA map: 0xc000 to 0xc3ff 8192 entries
pcib0: [GIANT-LOCKED]
pci0:  on pcib0
pcib1:  at device 1.0 on pci0
pci1:  on pcib1
pcib2:  at device 1.1 on pci0
pci2:  on pcib2
ebus0:  port 0x4000-0x7fff mem 0x300-0x3ff at
device 3.0 on pci0
vgapci0:  mem
0x100-0x1ff,0x200-0x2000fff at device 2.0 on pci0
vgapci0: Boot video device
eeprom0:  addr 0x142000-0x143fff on ebus0
eeprom0: model mk48t59
ebus0:  addr 0 (no driver attached)
uart0: <16550 or compatible> addr 0x1403f8-0x1403ff irq 43 on ebus0
uart0: console (9600,n,8,1)
ebus0:  addr 0x140060-0x140067 (no driver attached)
pci0:  at device 4.0 (no driver attached)
atapci0:  port
0x8100-0x8107,0x8180-0x8183,0x8200-0x8207,0x8280-0x8283,0x8300-0x830f at
device 5.0 on pci0
ata2:  at channel 0 on atapci0
ata3:  at channel 1 on atapci0
cryptosoft0:  on nexus0
nexus0:  type unknown (no driver attached)
Timecounter "tick" frequency 1 Hz quality 1000
Event timer "tick" 

Re: sparc64 traps during probe (r293243)

[Marius Strobl]

On Fri, Jan 08, 2016 at 04:57:58PM +, Mark Cave-Ayland wrote:
> On 08/01/16 15:42, Kurt Lidl wrote:
> 
> This looks amazingly similar to what I get trying to boot FreeBSD under
> QEMU, i.e. pointing at sched_clock():
> 

<...>

> -- kernel stack fault %o7=0xc011a050 --
> panic: longjmp botch
> cpuid = -1012475520
> KDB: stack backtrace:
> Uptime: 3s
> 
> Note also the "longjmp botch" error right at the end. This is with the
> sun4u timer fix patch developed with help from Marius which has recently
> been applied to QEMU git master. So maybe this is a kernel bug after all?

No, that still is a completely trashed kernel stack as previously
seen when running under QEMU so the whole backtrace is questionable.
Apart from that, sched_clock() is called rather frequently so it is
not unlikely to show up in a kernel back trace but neither of the
two back traces in question suggest it's the culprit (assuming that
the one seen with QEMU actually is sane).

Marius


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Panic from vesa_configure()

[Adrian Chadd]

It shouldn't have changed though; you're just requesting memory to use
for x86bios calls.

+jhb - any ideas?


-a


On 8 January 2016 at 20:53, Cy Schubert  wrote:
> Cy Schubert writes:
>> In message <201601080107.u0817kdw078...@slippy.cwsent.com>, Cy Schubert
>> writes:
>> > In message > c
>> > om>
>> > , Adrian Chadd writes:
>> > > Ok,
>> > >
>> > > So try adding this check:
>> > >
>> > > vmbuf = x86bios_alloc(, sizeof(*buf), M_WAITOK);
>> > > if (vmbuf == NULL) {
>> > > printf("%s: x86bios_alloc failed!\n", __func__);
>> > > goto fail;
>> > > }
>> > >
>> > > ... that call shouldn't be failing, but if it's truely failing on the
>> > > bcopy(), the only reason is because vmbuf is NULL.
>> >
>> > Thanks. I'll try this.
>> >
>> > vesa.c hasn't changed for a while so I suspect the root cuase may be
>> > somewhere else (we're probably treating the symptom here). Nice thing about
>>
>> > using the same mobo and cpu combination on all my machines (except
>> > laptops), failures are completely reproducible. Might be a good idea to put
>>
>> > in a dtrace probe too.
>>
>> Hi Adrian,
>>
>> Your patch fixed the issue. I've included a dtrace probe. I suspect the
>> error may be BIOS specific and the dtrace probe should help in tracking it
>> down. Does this look good to commit?
>
> A bit of multitasking going on here. I should have included the patch. :~
>
>
>
>
> Cheers,
> Cy Schubert  or 
> FreeBSD UNIX:     Web:  http://www.FreeBSD.org
>
> The need of the many outweighs the greed of the few.
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Panic from vesa_configure()

[Cy Schubert]

In message <201601080107.u0817kdw078...@slippy.cwsent.com>, Cy Schubert 
writes:
> In message  om>
> , Adrian Chadd writes:
> > Ok,
> > 
> > So try adding this check:
> > 
> > vmbuf = x86bios_alloc(, sizeof(*buf), M_WAITOK);
> > if (vmbuf == NULL) {
> > printf("%s: x86bios_alloc failed!\n", __func__);
> > goto fail;
> > }
> > 
> > ... that call shouldn't be failing, but if it's truely failing on the
> > bcopy(), the only reason is because vmbuf is NULL.
> 
> Thanks. I'll try this.
> 
> vesa.c hasn't changed for a while so I suspect the root cuase may be 
> somewhere else (we're probably treating the symptom here). Nice thing about 
> using the same mobo and cpu combination on all my machines (except 
> laptops), failures are completely reproducible. Might be a good idea to put 
> in a dtrace probe too.

Hi Adrian,

Your patch fixed the issue. I've included a dtrace probe. I suspect the 
error may be BIOS specific and the dtrace probe should help in tracking it 
down. Does this look good to commit?


-- 
Cheers,
Cy Schubert  or 
FreeBSD UNIX:     Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Panic from vesa_configure()

[Cy Schubert]

Cy Schubert writes:
> In message <201601080107.u0817kdw078...@slippy.cwsent.com>, Cy Schubert 
> writes:
> > In message  c
> > om>
> > , Adrian Chadd writes:
> > > Ok,
> > > 
> > > So try adding this check:
> > > 
> > > vmbuf = x86bios_alloc(, sizeof(*buf), M_WAITOK);
> > > if (vmbuf == NULL) {
> > > printf("%s: x86bios_alloc failed!\n", __func__);
> > > goto fail;
> > > }
> > > 
> > > ... that call shouldn't be failing, but if it's truely failing on the
> > > bcopy(), the only reason is because vmbuf is NULL.
> > 
> > Thanks. I'll try this.
> > 
> > vesa.c hasn't changed for a while so I suspect the root cuase may be 
> > somewhere else (we're probably treating the symptom here). Nice thing about
>  
> > using the same mobo and cpu combination on all my machines (except 
> > laptops), failures are completely reproducible. Might be a good idea to put
>  
> > in a dtrace probe too.
> 
> Hi Adrian,
> 
> Your patch fixed the issue. I've included a dtrace probe. I suspect the 
> error may be BIOS specific and the dtrace probe should help in tracking it 
> down. Does this look good to commit?

A bit of multitasking going on here. I should have included the patch. :~



Index: vesa.c
===
--- vesa.c  (revision 293386)
+++ vesa.c  (working copy)
@@ -819,6 +819,11 @@
regs.R_AX = 0x4f00;
 
vmbuf = x86bios_alloc(, sizeof(*buf), M_WAITOK);
+   if (vmbuf == NULL) {
+   printf("%s: x86bios_alloc failed!\n", __func__);
+   DTRACE_PROBE1(x86bios_alloc_failed, int, vmbuf);
+   goto fail;
+   }
 
regs.R_ES = X86BIOS_PHYSTOSEG(offs);
regs.R_DI = X86BIOS_PHYSTOOFF(offs);
Cheers,
Cy Schubert  or 
FreeBSD UNIX:     Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

panic: sbappendstream 1 [head/amd64 @r293419]

[David Wolfskill]

After the first panic, I rebuilt the kernel without -DNO_CLEAN; the
crash dump & other diagnostic info is from the clean build.

January  8, 2016 at 05:57:27 AM PST

FreeBSD freebeast.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1954  
r293419M/293420:1100093: Fri Jan  8 05:09:57 PST 2016 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64

panic: sbappendstream 1

...
Unread portion of the kernel message buffer:
panic: sbappendstream 1
cpuid = 7
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe085e0595b0
vpanic() at vpanic+0x182/frame 0xfe085e059630
kassert_panic() at kassert_panic+0x126/frame 0xfe085e0596a0
sbappendstream_locked() at sbappendstream_locked+0xa5/frame 0xfe085e0596d0
uipc_send() at uipc_send+0x942/frame 0xfe085e059780
sosend_generic() at sosend_generic+0x42f/frame 0xfe085e059840
kern_sendit() at kern_sendit+0x21b/frame 0xfe085e0598f0
sendit() at sendit+0x126/frame 0xfe085e059940
sys_sendmsg() at sys_sendmsg+0x61/frame 0xfe085e0599a0
amd64_syscall() at amd64_syscall+0x2db/frame 0xfe085e059ab0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe085e059ab0
--- syscall (28, FreeBSD ELF64, sys_sendmsg), rip = 0x801270dfa, rsp = 
0x7fffa098, rbp = 0x7fffa0d0 ---
KDB: enter: panic
...
Loaded symbols for /boot/kernel/autofs.ko
#0  doadump (textdump=0) at pcpu.h:221
221 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) #0  doadump (textdump=0) at pcpu.h:221
#1  0x8038205b in db_dump (dummy=, dummy2=false, 
dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_command.c:533
#2  0x80381e4e in db_command (cmd_table=0x0)
at /usr/src/sys/ddb/db_command.c:440
#3  0x80381be4 in db_command_loop ()
at /usr/src/sys/ddb/db_command.c:493
#4  0x8038467b in db_trap (type=, code=0)
at /usr/src/sys/ddb/db_main.c:251
#5  0x80a5cfe3 in kdb_trap (type=3, code=0, tf=)
at /usr/src/sys/kern/subr_kdb.c:654
#6  0x80e6a2a8 in trap (frame=0xfe085e0594e0)
at /usr/src/sys/amd64/amd64/trap.c:549
#7  0x80e4a317 in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:234
#8  0x80a5c6cb in kdb_enter (why=0x8137af3c "panic", 
msg=0x80 ) at cpufunc.h:63
#9  0x80a1fb8f in vpanic (fmt=, 
ap=) at /usr/src/sys/kern/kern_shutdown.c:750
#10 0x80a1f9e6 in kassert_panic (fmt=)
at /usr/src/sys/kern/kern_shutdown.c:647
#11 0x80aa3375 in sbappendstream_locked (sb=0xf80044212378, 
m=0xf800108c7200, flags=0) at /usr/src/sys/kern/uipc_sockbuf.c:642
#12 0x80ab1a42 in uipc_send (so=0xf80044212000, flags=0, 
m=, nam=0x0, control=, 
td=0xf8001078e9a0) at /usr/src/sys/kern/uipc_usrreq.c:984
#13 0x80aa5f5f in sosend_generic (so=0xf80044212000, addr=0x0, 
uio=0xfe085e059890, top=, 
control=, flags=, 
td=0xfe085e059880) at /usr/src/sys/kern/uipc_socket.c:1349
#14 0x80aac36b in kern_sendit (td=0xf8001078e9a0, s=6, 
mp=, flags=0, control=0x0, segflg=UIO_USERSPACE)
at /usr/src/sys/kern/uipc_syscalls.c:906
#15 0x80aac666 in sendit (td=0xf8001078e9a0, 
s=, mp=0xfe085e059958, flags=0)
at /usr/src/sys/kern/uipc_syscalls.c:833
#16 0x80aac6f1 in sys_sendmsg (td=0xf8001078e9a0, 
uap=0xfe085e059a40) at /usr/src/sys/kern/uipc_syscalls.c:1035
#17 0x80e6b13b in amd64_syscall (td=0xf8001078e9a0, traced=0)
at subr_syscall.c:135
#18 0x80e4a5fb in Xfast_syscall ()
at /usr/src/sys/amd64/amd64/exception.S:394
#19 0x000801270dfa in ?? ()
Previous frame inner to this frame (corrupt stack?)
Current language:  auto; currently minimal
(kgdb) 
.

As indicated above, this is with a GENERIC kernel.  My laptop (running
a kernel built with the same sources, but a slightly customized kernel
config) gets to the point of allowing me to login (via xdm), but when I
fire off a command that creates xterms & tries to run tmux(1) in them,
locks up (as far as I can tell), and a power-cycle is needed to recover.

I can poke at the crash dump (given hints), make the dump and core.txt file
available.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: panic: sbappendstream 1 [head/amd64 @r293419]

[David Wolfskill]

On Fri, Jan 08, 2016 at 06:05:18AM -0800, David Wolfskill wrote:
> After the first panic, I rebuilt the kernel without -DNO_CLEAN; the
> crash dump & other diagnostic info is from the clean build.
> 
> January  8, 2016 at 05:57:27 AM PST
> 
> FreeBSD freebeast.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1954  
> r293419M/293420:1100093: Fri Jan  8 05:09:57 PST 2016 
> r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64
> 
> panic: sbappendstream 1
> 

flo@ suggested reverting r293405; after doing that & rebuilding the
kernel, the build machine boots to multi-user mode and I'm able to
login:

FreeBSD freebeast.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1955  
r293419M/293420:1100093: Fri Jan  8 06:26:38 PST 2016 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64

I'll try that for my laptop, as well.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: panic: sbappendstream 1 [head/amd64 @r293419]

[David Wolfskill]

On Fri, Jan 08, 2016 at 06:33:40AM -0800, David Wolfskill wrote:
> ...
> > panic: sbappendstream 1
> > 
> 
> flo@ suggested reverting r293405; after doing that & rebuilding the
> kernel, the build machine boots to multi-user mode and I'm able to
> login:
> 
> FreeBSD freebeast.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1955  
> r293419M/293420:1100093: Fri Jan  8 06:26:38 PST 2016 
> r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64
> 
> I'll try that for my laptop, as well.

That seems to have worked for thhe laptop, as well:

FreeBSD g1-252.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #299  
r293419M/293420:1100093: Fri Jan  8 06:44:01 PST 2016 
r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: panic: sbappendstream 1 [head/amd64 @r293419]

[Gleb Smirnoff]

  David,

  problem confirmed. Will either fix today, or revert the change
by the end of the day.

On Fri, Jan 08, 2016 at 06:05:18AM -0800, David Wolfskill wrote:
D> After the first panic, I rebuilt the kernel without -DNO_CLEAN; the
D> crash dump & other diagnostic info is from the clean build.
D> 
D> January  8, 2016 at 05:57:27 AM PST
D> 
D> FreeBSD freebeast.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1954  
r293419M/293420:1100093: Fri Jan  8 05:09:57 PST 2016 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64
D> 
D> panic: sbappendstream 1
D> 
D> ...
D> Unread portion of the kernel message buffer:
D> panic: sbappendstream 1
D> cpuid = 7
D> KDB: stack backtrace:
D> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
0xfe085e0595b0
D> vpanic() at vpanic+0x182/frame 0xfe085e059630
D> kassert_panic() at kassert_panic+0x126/frame 0xfe085e0596a0
D> sbappendstream_locked() at sbappendstream_locked+0xa5/frame 
0xfe085e0596d0
D> uipc_send() at uipc_send+0x942/frame 0xfe085e059780
D> sosend_generic() at sosend_generic+0x42f/frame 0xfe085e059840
D> kern_sendit() at kern_sendit+0x21b/frame 0xfe085e0598f0
D> sendit() at sendit+0x126/frame 0xfe085e059940
D> sys_sendmsg() at sys_sendmsg+0x61/frame 0xfe085e0599a0
D> amd64_syscall() at amd64_syscall+0x2db/frame 0xfe085e059ab0
D> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe085e059ab0
D> --- syscall (28, FreeBSD ELF64, sys_sendmsg), rip = 0x801270dfa, rsp = 
0x7fffa098, rbp = 0x7fffa0d0 ---
D> KDB: enter: panic
D> ...
D> Loaded symbols for /boot/kernel/autofs.ko
D> #0  doadump (textdump=0) at pcpu.h:221
D> 221 pcpu.h: No such file or directory.
D> in pcpu.h
D> (kgdb) #0  doadump (textdump=0) at pcpu.h:221
D> #1  0x8038205b in db_dump (dummy=, 
dummy2=false, 
D> dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_command.c:533
D> #2  0x80381e4e in db_command (cmd_table=0x0)
D> at /usr/src/sys/ddb/db_command.c:440
D> #3  0x80381be4 in db_command_loop ()
D> at /usr/src/sys/ddb/db_command.c:493
D> #4  0x8038467b in db_trap (type=, code=0)
D> at /usr/src/sys/ddb/db_main.c:251
D> #5  0x80a5cfe3 in kdb_trap (type=3, code=0, tf=)
D> at /usr/src/sys/kern/subr_kdb.c:654
D> #6  0x80e6a2a8 in trap (frame=0xfe085e0594e0)
D> at /usr/src/sys/amd64/amd64/trap.c:549
D> #7  0x80e4a317 in calltrap ()
D> at /usr/src/sys/amd64/amd64/exception.S:234
D> #8  0x80a5c6cb in kdb_enter (why=0x8137af3c "panic", 
D> msg=0x80 ) at cpufunc.h:63
D> #9  0x80a1fb8f in vpanic (fmt=, 
D> ap=) at /usr/src/sys/kern/kern_shutdown.c:750
D> #10 0x80a1f9e6 in kassert_panic (fmt=)
D> at /usr/src/sys/kern/kern_shutdown.c:647
D> #11 0x80aa3375 in sbappendstream_locked (sb=0xf80044212378, 
D> m=0xf800108c7200, flags=0) at /usr/src/sys/kern/uipc_sockbuf.c:642
D> #12 0x80ab1a42 in uipc_send (so=0xf80044212000, flags=0, 
D> m=, nam=0x0, control=, 
D> td=0xf8001078e9a0) at /usr/src/sys/kern/uipc_usrreq.c:984
D> #13 0x80aa5f5f in sosend_generic (so=0xf80044212000, addr=0x0, 
D> uio=0xfe085e059890, top=, 
D> control=, flags=, 
D> td=0xfe085e059880) at /usr/src/sys/kern/uipc_socket.c:1349
D> #14 0x80aac36b in kern_sendit (td=0xf8001078e9a0, s=6, 
D> mp=, flags=0, control=0x0, segflg=UIO_USERSPACE)
D> at /usr/src/sys/kern/uipc_syscalls.c:906
D> #15 0x80aac666 in sendit (td=0xf8001078e9a0, 
D> s=, mp=0xfe085e059958, flags=0)
D> at /usr/src/sys/kern/uipc_syscalls.c:833
D> #16 0x80aac6f1 in sys_sendmsg (td=0xf8001078e9a0, 
D> uap=0xfe085e059a40) at /usr/src/sys/kern/uipc_syscalls.c:1035
D> #17 0x80e6b13b in amd64_syscall (td=0xf8001078e9a0, traced=0)
D> at subr_syscall.c:135
D> #18 0x80e4a5fb in Xfast_syscall ()
D> at /usr/src/sys/amd64/amd64/exception.S:394
D> #19 0x000801270dfa in ?? ()
D> Previous frame inner to this frame (corrupt stack?)
D> Current language:  auto; currently minimal
D> (kgdb) 
D> .
D> 
D> As indicated above, this is with a GENERIC kernel.  My laptop (running
D> a kernel built with the same sources, but a slightly customized kernel
D> config) gets to the point of allowing me to login (via xdm), but when I
D> fire off a command that creates xterms & tries to run tmux(1) in them,
D> locks up (as far as I can tell), and a power-cycle is needed to recover.
D> 
D> I can poke at the crash dump (given hints), make the dump and core.txt file
D> available.
D> 
D> Peace,
D> david
D> -- 
D> David H. Wolfskill   da...@catwhisker.org
D> Those who would murder in the name of God or prophet are blasphemous cowards.
D> 
D> See http://www.catwhisker.org/~david/publickey.gpg for my public key.



-- 
Totus tuus, Glebius.
___
freebsd-current@freebsd.org 

sparc64 traps during probe (r293243)

[Kurt Lidl]

I recently updated a sparc64 V120 from r291993
to r293243, and it now traps during the
autoconfiguration phase of the kernel boot:

Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
jumping to kernel entry at 0xc00b.
GDB: no debug ports present
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2016 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.0-CURRENT #4 r293243M: Thu Jan  7 13:50:04 EST 2016
l...@ton.pix.net:/usr/obj/usr/src/sys/GENERIC sparc64
gcc version 4.2.1 20070831 patched [FreeBSD]
WARNING: WITNESS option enabled, expect reduced performance.
VT: init without driver.
real memory  = 2147483648 (2048 MB)
avail memory = 2063785984 (1968 MB)
cpu0: Sun Microsystems UltraSparc-IIe Processor (648.00 MHz CPU)

[...]

da0 at sym0 bus 0 scbus2 target 0 lun 0
da0:  Fixed Direct Access SCSI-3 device
da0: Serial Number UPL3P310365J
da0: 80.000MB/s transfers (40.000MHz, offset 31, 16bit)
da0: Command Queueing enabled
da0: 34732MB (71132959 512 byte sectors)
cd0 at ata2 bus 0 scbus0 target 0 lun 0
cd0:  Removable CD-ROM SCSI device
cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes)
cd0: 393MB (201600 2048 byte sectors)
da1 at sym0 bus 0 scbus2 target 1 lun 0
da1:  Fixed Direct Access SCSI-3 device
da1: Serial Number UPL3P3506STC
da1: 80.000MB/s transfers (40.000MHz, offset 31, 16bit)
da1: Command Queueing enabled
da1: 34732MB (71132959 512 byte sectors)
WARNING: WITNESS option enabled, expect reduced performance.
Trying to mount root from zfs:sys/ROOT/default []...
GEOM_MIRROR: Device mirror/gswap launched (2/2).
[ thread pid 1 tid 12 ]
Stopped at  tl0_utrap+0x20: ldx [%l0 + %l1], %l0
db> bt
Tracing pid 1 tid 12 td 0xf800016164d0
KDB: reentering
KDB: stack backtrace:
kdb_reenter() at kdb_reenter+0x5c
trap() at trap+0x2fc
-- data access exception sfar=0xfcf821ca0218 sfsr=0x41029 
%o7=0xc06165e8 --

sched_clock() at sched_clock+0x94
statclock_cnt() at statclock_cnt+0x1c0
handleevents() at handleevents+0x138
timercb() at timercb+0x410
tick_intr() at tick_intr+0x220
-- interrupt level=0xe pil=0 %o7=0xc09c6c20 --
-- kernel stack fault %o7=0xc00b1288 --
db_read_bytes() at db_read_bytes+0x44
KDB: reentering
KDB: stack backtrace:
kdb_reenter() at kdb_reenter+0x5c
trap() at trap+0x2fc
-- kernel stack fault %o7=0xc011f8f0 --
db_read_bytes() at db_read_bytes+0x44
KDB: reentering
KDB: stack backtrace:
kdb_reenter() at kdb_reenter+0x5c
trap() at trap+0x2fc

And then the stack backtrace just keeps repeating.

-Kurt
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: kernel panic by enabling net.inet.ip.random_id

[Gleb Smirnoff]

On Wed, Jan 06, 2016 at 01:24:53PM -0500, Shawn Webb wrote:
S> That's what gets toggled via the sysctl. I think I figured out that I
S> need to call ip_initid() in the SYSINIT. Compiling and testing now.

Right, that's the problem. You actually want VNET_SYSINIT().

Please next time you report a panic, don't say "I'm on latest HEAD on
amd64 in bhyve" when you are actually running a modified version. It
took me about 10 minutes pondering into your backtrace in initial
post and into ip_id.c. Then I went on reading thread further and
discovered that I was reading wrong ip_id.c

-- 
Totus tuus, Glebius.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"