date:20151230

[Bug 203352] KDB: stack backtrace: /usr/src/sys/kern/vfs_mount.c:1224

2015-12-30 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203352

--- Comment #1 from Oliver Pinter  ---
And the same LOR at shutdown time on 11-CURRENT:

Dec 30 18:38:32 11-stable syslogd: exiting on signal 15
Waiting (max 60 seconds) for system process `vnlru' to stop...done
Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
Waiting (max 60 seconds) for system process `syncer' to stop...
Syncing disks, vnodes remaining...0 done
All buffers synced.
lock order reversal:
 1st 0xf80003cc1418 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1224
 2nd 0xf80003d9a240 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2473
stack backtrace:
#0 0x80a7f6c0 at witness_debugger+0x70
#1 0x80a7f5c1 at witness_checkorder+0xe71
#2 0x80a02b6b at __lockmgr_args+0xd3b
#3 0x80ac582c at vop_stdlock+0x3c
#4 0x80fc2ef0 at VOP_LOCK1_APV+0x100
#5 0x80ae61ca at _vn_lock+0x9a
#6 0x80ad6bf3 at vget+0x63
#7 0x808f666d at devfs_allocv+0xcd
#8 0x808f6133 at devfs_root+0x43
#9 0x80acf20f at dounmount+0x44f
#10 0x80ad89e4 at vfs_unmountall+0xc4
#11 0x80ab9e99 at bufshutdown+0x3b9
#12 0x80a25689 at kern_reboot+0x189
#13 0x80a254a3 at sys_reboot+0x3e3
#14 0x80e70fdb at amd64_syscall+0x2db
#15 0x80e50feb at Xfast_syscall+0xfb
Uptime: 25m55s
acpi0: Powering system off

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 188833] [suspend/resume] Suspend/resume with Intel GMA HD 4000: AIGLX fails to restart

2015-12-30 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=188833

Graham Perrin  changed:

   What|Removed |Added

 CC||grahamper...@gmail.com

--- Comment #4 from Graham Perrin  ---
https://lists.freebsd.org/pipermail/freebsd-x11/2015-December/017055.html
suggests special attention to this bug. 

I can't comment on Intel GMA HD, 

https://forums.freebsd.org/threads/suspend-resume-problem.13311/#post-307411
describes a workaround that's applicable with PC-BSD 11.0-CURRENT with an Intel
HD Graphics 5500, but the symptom there is blackness (not corruption) on
resume.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 205663] clang++ 3.7.1 gets Bus Errors during compilation on arm that has SCTLR bit[1]==1 (alignment required)

2015-12-30 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205663

--- Comment #4 from Mark Millard  ---
I've added the following new information on llvm's bugzilla report. Basically
alignas use can avoid the alignment problems but there are lots of places that
would need it in order for clang++ to work overall for SCTLR bit[1]==1.


The following change eliminates the specific Bus Error in clang and allows the
11 line program to compile on an rpi2 --but causes include/clang/AST/Type.h to
pollute a namespace via  use:

# svnlite diff /usr/src/contrib/llvm/
Index: /usr/src/contrib/llvm/tools/clang/include/clang/AST/Type.h
===
--- /usr/src/contrib/llvm/tools/clang/include/clang/AST/Type.h  (revision
292858)
+++ /usr/src/contrib/llvm/tools/clang/include/clang/AST/Type.h  (working copy)
@@ -14,6 +14,8 @@
 #ifndef LLVM_CLANG_AST_TYPE_H
 #define LLVM_CLANG_AST_TYPE_H

+#include  // for std::max_align_t
+
 #include "clang/AST/NestedNameSpecifier.h"
 #include "clang/AST/TemplateName.h"
 #include "clang/Basic/AddressSpaces.h"
@@ -4336,7 +4338,7 @@
 /// DependentTemplateSpecializationType - Represents a template
 /// specialization type whose template cannot be resolved, e.g.
 ///   A::template B
-class DependentTemplateSpecializationType :
+class alignas(alignof(std::max_align_t)) DependentTemplateSpecializationType :
   public TypeWithKeyword, public llvm::FoldingSetNode {

   /// \brief The nested name specifier containing the qualifier.

alignof(TemplateArgument) is not used because Types.h is used in contexts where
TemplateArgument is an incomplete type and the notation would be rejected.

The command that built a Type.o that worked was (from the script log of the
build):

--- Type.o ---
/usr/bin/clang++ -target armv6--freebsd11.0-gnueabi -march=armv7a
-mno-unaligned-access -target armv6-gnueabi-freebsd11.0
--sysroot=/usr/obj/clang/arm.armv6/usr/src/tmp -B/usr/local/arm-gnueabi-freebs
d/bin/ --sysroot=/usr/obj/clang/arm.armv6/usr/src/tmp
-B/usr/local/arm-gnueabi-freebsd/bin/  -O -pipe -mfloat-abi=softfp
-I/usr/src/lib/clang/libclangast/../../../contrib/llvm/include -I/usr/src/lib/c
lang/libclangast/../../../contrib/llvm/tools/clang/include
-I/usr/src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST -I.
-I/usr/src/lib/clang/libclangast/../../../contrib/llvm/../../l
ib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS
-D__STDC_CONSTANT_MACROS -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_STATIC_ANALYZER
-fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\
"armv6-gnueabi-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"armv6-unknown-freebsd11.0\"
-DDEFAULT_SYSROOT=\"\" -MD -MP -MF.depend.Type.o -MTType.o -Qunused-arguments 
-std=c++11 -fno-exceptions -fno-rtti -stdli
b=libc++ -Wno-c++11-extensions -c
/usr/src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/Type.cpp
-o Type.o

So it used (in order):

-target armv6--freebsd11.0-gnueabi
-march=armv7a
-mno-unaligned-access
-target armv6-gnueabi-freebsd11.0

(The first -target is what I supplied, the 2nd is from the FreeBSD build
environment.)

STILL FAILS OVERALL HOWEVER. . .

Unfortunately clang++ on the rpi2 with SCTLR bit[1]==1 dies for other c++
syntax when trying to build part of llvm (early in FreeBSD's buildworld):

Program terminated with signal 10, Bus error.
#0  0x00c43d28 in clang::ASTTemplateArgumentListInfo::initializeFrom ()
[New Thread 22a18000 (LWP 100079/)]
(gdb) bt
#0  0x00c43d28 in clang::ASTTemplateArgumentListInfo::initializeFrom ()
#1  0x00c43f10 in clang::ASTTemplateKWAndArgsInfo::initializeFrom ()
#2  0x00cdc788 in
clang::CXXDependentScopeMemberExpr::CXXDependentScopeMemberExpr ()
#3  0x00cdc99c in clang::CXXDependentScopeMemberExpr::Create ()
#4  0x00685384 in clang::Sema::ActOnDependentMemberExpr ()
#5  0x0068abec in clang::Sema::ActOnMemberAccessExpr ()
#6  0x0044a938 in clang::Parser::ParsePostfixExpressionSuffix ()
#7  0x in ?? ()
(gdb) x/i 0x00c43d28
0xc43d28
<_ZN5clang27ASTTemplateArgumentListInfo14initializeFromERKNS_24TemplateArgumentListInfoERbS4_S4_+396>:
vst1.64 {d16-d17}, [r0]!
(gdb) info all-regsisters
Undefined info command: "all-regsisters".  Try "help info".
(gdb) info all-registers
r0 0x234b96dc   592156380
. . .


There are lots of places using "this + 1" and reinterpret_cast that therefore
have the potential for a mis-matched alignment between the two types involved,
just like the one I initially reported (some of the below might not be at risk,
I've not inspected all the details of each):

# grep "reinterpret_cast.*this" lib/*/*
lib/AST/Decl.cpp:  SourceLocation *StoredLocs = reinterpret_cast(this + 1);
lib/AST/Decl.cpp:  *reinterpret_cast(this + 1) = EndLoc;
lib/AST/Decl.cpp:= reinterpret_cast(this + 1);
lib/AST/Decl.cpp:   *reinterpret_cast(this + 1));
lib/AST/DeclCXX.cpp:  VarDecl **MyIndices = reinterpret_cast (this
+ 1);
lib/AST/DeclOpenMP.cpp:  Expr **Vars =

[Bug 205743] null pointer dereference in PF running a vimage jail

2015-12-30 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205743

Bug ID: 205743
   Summary: null pointer dereference in PF running a vimage jail
   Product: Base System
   Version: 11.0-CURRENT
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Many People
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: ing.g...@gmail.com
CC: freebsd-am...@freebsd.org
CC: freebsd-am...@freebsd.org

Running the following jail on -CURRENT:

# cat /etc/jail.conf

allow.raw_sockets = "1";
allow.set_hostname = "0";
allow.sysvipc = "1";

test {
host.hostname = "test.bsdvm";
vnet = "new";
vnet.interface  = "em1", "em2";
devfs_ruleset = 4;
allow.raw_sockets = 1;
allow.mount.devfs = 1;
allow.mount = 1;
allow.sysvipc = 1;
persist;
}

The devfs ruleset is copied for /etc/defaults and modified to expose bp* and
pf* devices.

Then within the jail:

ext_if="em1"
int_if="em2"

# options
set block-policy return
set loginterface $ext_if

set skip on lo

# scrub
scrub in

# nat/rdr
nat on $ext_if inet from !($ext_if) -> ($ext_if:0)
nat-anchor "ftp-proxy/*"
rdr-anchor "ftp-proxy/*"

block in all

pass out

anchor "ftp-proxy/*"
antispoof quick for { lo $int_if }
pass in inet proto icmp all icmp-type $icmp_types
pass quick on $int_if no state


Causes a 100% reproducible panic:

Fatal double fault
rip = 0x80e484a8
rsp = 0xfe0230ea0fd0
rbp = 0xfe0230ea1000
cpuid = 4; apic id = 05
panic: double fault
cpuid = 4
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2c/frame 0xfe0227dd8ce0
kdb_backtrace() at kdb_backtrace+0x53/frame 0xfe0227dd8db0
vpanic() at vpanic+0x249/frame 0xfe0227dd8e80
vpanic() at vpanic/frame 0xfe0227dd8ee0
dblfault_handler() at dblfault_handler+0x10a/frame 0xfe0227dd8f30
Xdblfault() at Xdblfault+0xac/frame 0xfe0227dd8f30
--- trap 0x17, rip = 0x80e484a8, rsp = 0xfe0230ea0fd0, rbp =
0xfe0230ea1000 ---
vtterm_cursor() at vtterm_cursor+0x8/frame 0xfe0230ea1000
termteken_cursor() at termteken_cursor+0x37/frame 0xfe0230ea1030
teken_funcs_cursor() at teken_funcs_cursor+0x3b/frame 0xfe0230ea1050
teken_subr_carriage_return() at teken_subr_carriage_return+0x2c/frame
0xfe0230ea1070
teken_input_char() at teken_input_char+0x166/frame 0xfe0230ea10b0
teken_input_byte() at teken_input_byte+0x50/frame 0xfe0230ea10d0
teken_input() at teken_input+0x52/frame 0xfe0230ea1100
termcn_cnputc() at termcn_cnputc+0x1c8/frame 0xfe0230ea11b0
cnputc() at cnputc+0x90/frame 0xfe0230ea11f0
cnputs() at cnputs+0x154/frame 0xfe0230ea1230
putbuf() at putbuf+0x15f/frame 0xfe0230ea1260
putchar() at putchar+0xb0/frame 0xfe0230ea12a0
kvprintf() at kvprintf+0x15a/frame 0xfe0230ea1790
_vprintf() at _vprintf+0xb9/frame 0xfe0230ea1890
vprintf() at vprintf+0x2d/frame 0xfe0230ea18c0
printf() at printf+0x4b/frame 0xfe0230ea1930
trap_fatal() at trap_fatal+0xf5/frame 0xfe0230ea1a50
trap_pfault() at trap_pfault+0x188/frame 0xfe0230ea1b50
trap() at trap+0x7a9/frame 0xfe0230ea1e90
trap_check() at trap_check+0x4a/frame 0xfe0230ea1eb0
calltrap() at calltrap+0x8/frame 0xfe0230ea1eb0
--- trap 0xc, rip = 0x8168e17f, rsp = 0xfe0230ea1f80, rbp =
0xfe0230ea1fb0 ---
pf_begin_rules() at pf_begin_rules+0x6f/frame 0xfe0230ea1fb0
pfioctl() at pfioctl+0xb35a/frame 0xfe0230ea42e0
devfs_ioctl_f() at devfs_ioctl_f+0x19c/frame 0xfe0230ea4420
fo_ioctl() at fo_ioctl+0x4c/frame 0xfe0230ea4460
kern_ioctl() at kern_ioctl+0x3c3/frame 0xfe0230ea45b0
sys_ioctl() at sys_ioctl+0x2b8/frame 0xfe0230ea4690
syscallenter() at syscallenter+0xcfa/frame 0xfe0230ea4990
amd64_syscall() at amd64_syscall+0x2a/frame 0xfe0230ea4ab0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0230ea4ab0

(kgdb) up 36
#36 0x8168e17f in pf_begin_rules (ticket=0xf801e2162404,
rs_num=0x0, anchor=0xf801e2162004 "")
at /usr/src/sys/netpfil/pf/pf_ioctl.c:745
745 while ((rule = TAILQ_FIRST(rs->rules[rs_num].inactive.ptr)) !=
NULL) {
(kgdb) l
740 if (rs_num < 0 || rs_num >= PF_RULESET_MAX)
741 return (EINVAL);
742 rs = pf_find_or_create_ruleset(anchor);
743 if (rs == NULL)
744 return (EINVAL);
745 while ((rule = TAILQ_FIRST(rs->rules[rs_num].inactive.ptr)) !=
NULL) {
746 pf_unlink_rule(rs->rules[rs_num].inactive.ptr, rule);
747 rs->rules[rs_num].inactive.rcount--;
748 }
749 *ticket = ++rs->rules[rs_num].inactive.ticket;

(kgdb) print rs->rules[0]
$10 = {
  queues = 0xfe0001f8dd28,
  active = {
ptr = 0x0,
ptr_array = 0x0,
rcount = 0x0,
ticket = 0x0,
open = 0x0
  },
  inactive = {

[Bug 205721] usr/src/sys/mips/rt305x/rt305x_spi.c:250: possible missing break ?

2015-12-30 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205721

Bug ID: 205721
   Summary: usr/src/sys/mips/rt305x/rt305x_spi.c:250: possible
missing break ?
   Product: Base System
   Version: 11.0-CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: dcb...@hotmail.com

[usr/src/sys/mips/rt305x/rt305x_spi.c:250] ->
[usr/src/sys/mips/rt305x/rt305x_spi.c:252]: (warning) Variable 'tx_cmd_sz' is
reassigned a value before the old one has been used. 'break;' missing?

case CMD_READ:
cmd->tx_cmd_sz = 4;
case CMD_FAST_READ:
cmd->tx_cmd_sz = 5;
cmd->rx_cmd_sz = cmd->tx_data_sz = 0;
break;

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 205725] Stack backtrace on `zpool export`

2015-12-30 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205725

Bug ID: 205725
   Summary: Stack backtrace on `zpool export`
   Product: Base System
   Version: 11.0-CURRENT
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: florian.ermi...@alumni.tu-berlin.de
CC: freebsd-am...@freebsd.org
CC: freebsd-am...@freebsd.org

Hi *,

since I've upgraded my laptop from 10.2-RELEASE to 11-CURRENT (base r292536, 
now base r292755) I see this stack backtrace when a zpool is exported:

Dec 27 18:44:02 fuchi-cyber220 kernel: lock order reversal:
Dec 27 18:44:02 fuchi-cyber220 kernel: 1st 0xf800c7472418 zfs (zfs) @
/usr/src/sys/kern/vfs_mount.c:1224
Dec 27 18:44:02 fuchi-cyber220 kernel: 2nd 0xf800c73fad50 zfs_gfs (zfs_gfs)
@ /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/gfs.c:494
Dec 27 18:44:02 fuchi-cyber220 kernel: stack backtrace:
Dec 27 18:44:02 fuchi-cyber220 kernel: #0 0x80a7d6f0 at
witness_debugger+0x70
Dec 27 18:44:02 fuchi-cyber220 kernel: #1 0x80a7d5f1 at
witness_checkorder+0xe71
Dec 27 18:44:02 fuchi-cyber220 kernel: #2 0x809fedcb at
__lockmgr_args+0xd3b
Dec 27 18:44:02 fuchi-cyber220 kernel: #3 0x80ac55ec at
vop_stdlock+0x3c
Dec 27 18:44:02 fuchi-cyber220 kernel: #4 0x80fbb220 at
VOP_LOCK1_APV+0x100
Dec 27 18:44:02 fuchi-cyber220 kernel: #5 0x80ae653a at _vn_lock+0x9a
Dec 27 18:44:02 fuchi-cyber220 kernel: #6 0x8209db13 at
gfs_file_create+0x73
Dec 27 18:44:02 fuchi-cyber220 kernel: #7 0x8209dbbd at
gfs_dir_create+0x1d
Dec 27 18:44:02 fuchi-cyber220 kernel: #8 0x821649e7 at
zfsctl_mknode_snapdir+0x47
Dec 27 18:44:02 fuchi-cyber220 kernel: #9 0x8209e135 at
gfs_dir_lookup+0x185
Dec 27 18:44:02 fuchi-cyber220 kernel: #10 0x8209e61d at
gfs_vop_lookup+0x1d
Dec 27 18:44:02 fuchi-cyber220 kernel: #11 0x82163a05 at
zfsctl_root_lookup+0xf5
Dec 27 18:44:02 fuchi-cyber220 kernel: #12 0x821648a3 at
zfsctl_umount_snapshots+0x83
Dec 27 18:44:02 fuchi-cyber220 kernel: #13 0x8217d5ab at
zfs_umount+0x7b
Dec 27 18:44:02 fuchi-cyber220 kernel: #14 0x80acf0b0 at
dounmount+0x530
Dec 27 18:44:02 fuchi-cyber220 kernel: #15 0x80aceaed at
sys_unmount+0x35d
Dec 27 18:44:02 fuchi-cyber220 kernel: #16 0x80e6e13b at
amd64_syscall+0x2db
Dec 27 18:44:02 fuchi-cyber220 kernel: #17 0x80e4dd8b at
Xfast_syscall+0xfb

(From /var/log/messages)

First I've only seen this on the console at shutdown or reboot but later
found I can reproduce it by exporting a zpool.
While the only pools I can trigger this without a shutdown/reboot are 
connected via USB(3) I still see it just before poweroff at shutdown 
after the "All synced." message.

When I try to export a zpool under heavy load (`make -C /use/src -j 4
buildworld`
on a 2 core CPU w/ HT) the system locks up completely. I don't think it's
related
to memory pressure as I haven't seen swap being used during a buildworld (with 
8 gigs of RAM).

PS for cross-referencing: I've posted this issue on the current@ list
yesterday,
see
https://lists.freebsd.org/pipermail/freebsd-current/2015-December/059117.html

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 205725] Stack backtrace on `zpool export`

2015-12-30 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205725

--- Comment #1 from florian.ermi...@alumni.tu-berlin.de ---
Might be related to this issue on 10-STABLE:
https://lists.freebsd.org/pipermail/freebsd-stable/2015-December/083895.html

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 205722] usr/src/lib/libstand/uuid_to_string.c:110: wierd statement ?

2015-12-30 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205722

Andrey V. Elsukov  changed:

   What|Removed |Added

   Assignee|freebsd-bugs@FreeBSD.org|i...@freebsd.org
 CC||a...@freebsd.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 205722] usr/src/lib/libstand/uuid_to_string.c:110: wierd statement ?

2015-12-30 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205722

Bug ID: 205722
   Summary: usr/src/lib/libstand/uuid_to_string.c:110: wierd
statement ?
   Product: Base System
   Version: 11.0-CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: misc
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: dcb...@hotmail.com

[usr/src/lib/libstand/uuid_to_string.c:110]: (warning) Ineffective statement
similar to '*A++;'. Did you intend to write '(*A)++;'?

*w++ - '\0';

Maybe

*w++ = '\0';

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 205725] Stack backtrace on `zpool export`

2015-12-30 Thread bugzilla-noreply

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205725

--- Comment #2 from florian.ermi...@alumni.tu-berlin.de ---
bug #203352 might be related, trace starts at
/usr/src/sys/kern/vfs_mount.c:1224, too.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 203352] KDB: stack backtrace: /usr/src/sys/kern/vfs_mount.c:1224

[Bug 188833] [suspend/resume] Suspend/resume with Intel GMA HD 4000: AIGLX fails to restart

[Bug 205663] clang++ 3.7.1 gets Bus Errors during compilation on arm that has SCTLR bit[1]==1 (alignment required)

[Bug 205743] null pointer dereference in PF running a vimage jail

[Bug 205721] usr/src/sys/mips/rt305x/rt305x_spi.c:250: possible missing break ?

[Bug 205725] Stack backtrace on `zpool export`

[Bug 205725] Stack backtrace on `zpool export`

[Bug 205722] usr/src/lib/libstand/uuid_to_string.c:110: wierd statement ?

[Bug 205722] usr/src/lib/libstand/uuid_to_string.c:110: wierd statement ?

[Bug 205725] Stack backtrace on `zpool export`

10 matches

Site Navigation

Mail list logo

Footer information