Re: VirtualBox-ose kernel module crashes 10-stable

2017-04-04 Thread Hiroyuki Une
On Fri, 31 Mar 2017 13:56:54 +0200 (CEST)
Trond Endrestøl <trond.endres...@fagskolen.gjovik.no> wrote:

> On Fri, 31 Mar 2017 20:07+0900, Hiroyuki Une wrote:
> 
> > Kernel Panic was caused on My 10.3-STABLE r316132 
> > by VirtualBox-ose created by poudriere(8) on my box with DEBUG option.  
> > However, when I was using 10.3-STABLE r315187, 
> > VirtualBox-ose worked without any problem.  
> > 
> > Here is the output by kgdb:
> > 
> > -- start here (output by kgdb)
> > GNU gdb 6.1.1 [FreeBSD]
> > Copyright 2004 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public License, and you are
> > welcome to change it and/or distribute copies of it under certain 
> > conditions.
> > Type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB.  Type "show warranty" for details.
> > This GDB was configured as "amd64-marcel-freebsd"...
> > 
> > Unread portion of the kernel message buffer:
> > 
> > !!Assertion Failed!!
> > Expression: RTThreadPreemptIsEnabled(NIL_RTTHREAD)
> > Location  : 
> > /wrkdirs/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-5.1.18/out/freebsd.amd64/debug/bin/src/vboxdrv/r0drv/freebsd/spinlock-r0drv-freebsd.c(78)
> >  int RTSpinlockCreate(PRTSPINLOCK, uint32_t, const char *)
> > 
> > 
> > Fatal trap 3: breakpoint instruction fault while in kernel mode
> > cpuid = 3; apic id = 06
> > instruction pointer = 0x20:0x81dbb3de
> > stack pointer   = 0x28:0xfe0464bfd490
> > frame pointer   = 0x28:0xfe0464bfd4c0
> > code segment= base 0x0, limit 0xf, type 0x1b
> > = DPL 0, pres 1, long 1, def32 0, gran 1
> > processor eflags= interrupt enabled, IOPL = 0
> > current process = 46465 (VBoxSVC)
> > trap number = 3
> > panic: breakpoint instruction fault
> > cpuid = 3
> > KDB: stack backtrace:
> > #0 0x809bb360 at kdb_backtrace+0x60
> > #1 0x8097c1e6 at vpanic+0x126
> > #2 0x8097c0b3 at panic+0x43
> > #3 0x80d9ce2d at trap_fatal+0x35d
> > #4 0x80d9caaf at trap+0x79f
> > #5 0x80d81d4c at calltrap+0x8
> > #6 0x81d7d591 at supdrvCreateSession+0x91
> > #7 0x81d9355b at vboxdrvFreeBSDOpenCommon+0x2b
> > #8 0x80855a32 at devfs_open+0x122
> > #9 0x80ed8671 at VOP_OPEN_APV+0xa1
> > #10 0x80a3bc34 at vn_open_vnode+0x234
> > #11 0x80a3b803 at vn_open_cred+0x373
> > #12 0x80a348cf at kern_openat+0x26f
> > #13 0x80d9d862 at amd64_syscall+0x452
> > #14 0x80d8203b at Xfast_syscall+0xfb
> > Uptime: 16h16m43s
> > Dumping 3881 out of 16259 
> > MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
> > #0  doadump (textdump=) at pcpu.h:219
> > 219 pcpu.h: No such file or directory.
> > in pcpu.h
> > (kgdb) bt

(snip)

> > As shown in the above, kernel panic was caused by 
> > assertion RTThreadPreemptIsEnabled(NIL_RTTHREAD) 
> > which tests the following expressions:
> > 
> >   1. curthread->td_critnest is equal to 0, and
> >   2. IF (interrupt flag) on eflag (or rflag ?) is equal to 1.  
> > 
> > This assertion will be successful only if both of above are true.  
> > 
> > As I read the source of VirtualBox, RTThreadPreemptIsEnabled is 
> > a part of test for preemtiveness which is used to create a spinlock.  
> > However, I'm not sure why assertion RTThreadPreemptIsEnabled is required, 
> > and this was failed on 10.3-STABLE r316132.  
> > 
> > I would appreciate any information.  Thanks.  
> 
> emulators/virtualbox-ose needs access to the kernel sources during 
> build. Maybe you should rebuild emulators/virtualbox-ose to match your 
> current source tree.

Thank you for your advise.  I create a new jail for poudriere with 
the most recent 10.3-STABLE source tree, and then rebuild VirtualBox 
and its kernel module by it.  These worked fine.  

However, this shows that there seems to be following problems 
to maintain packages by pkg(8):

(a) STABLE users (both of 10 and 11) can't use kernel modules 
if pkg.FreeBSD.org provides packages which were built with RELEASE 
source tree, or

(b) RELEASE users can't use kernel can't use kernel modules 
if pkg.FreeBSD.org provides packages which were built with recent 
STABLE source tree.   

At least, nvidia-driver caused kernel panic by almost same reason [1].  

[1] https://lists.freebsd.org/pipermail/freebsd-stable/2017-March/087015.html

---
Hiroyuki Une: Hiroshima Kokusai Gakuin University
u...@hkg.ac.jp / harr...@seiryu.id.hkg.ac.jp
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

VirtualBox-ose kernel module crashes 10-stable

2017-03-31 Thread Hiroyuki Une
f80d9ce2d in trap_fatal (frame=,
eva=) at /usr/src/sys/amd64/amd64/trap.c:858
#5  0x80d9caaf in trap (frame=)
at /usr/src/sys/amd64/amd64/trap.c:203
#6  0x80d81d4c in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:238
#7  0x81dbb3de in RTSpinlockCreate (pSpinlock=0xf80233354860,
fFlags=4, pszName=0xfe0464bfd310 "")
at 
/wrkdirs/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-5.1.18/out/freebsd.amd64/debug/bin/src/vboxdrv/r0drv/freebsd/spinlock-r0drv-freebsd.c:78
#8  0x81d7d591 in supdrvCreateSession (pDevExt=0x81ddc510,
fUser=true, fUnrestricted=false, ppSession=0xfe0464bfd518)
at SUPDrv.c:772
#9  0x81d9355b in vboxdrvFreeBSDOpenCommon ()
at 
/wrkdirs/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-5.1.18/out/freebsd.amd64/debug/bin/src/vboxdrv/freebsd/SUPDrv-freebsd.c:250
#10 0x80855a32 in devfs_open (ap=)
at /usr/src/sys/fs/devfs/devfs_vnops.c:1116
#11 0x80ed8671 in VOP_OPEN_APV (vop=,
a=) at vnode_if.c:469
---Type  to continue, or q  to quit---
#12 0x80a3bc34 in vn_open_vnode (vp=0xf802d807b3b0, fmode=3,
cred=0xf8031f06f100, td=0xf802aad3b4c0, fp=0xf80020b39320)
at vnode_if.h:196
#13 0x80a3b803 in vn_open_cred (ndp=0xfe0464bfd870,
flagp=0xfe0464bfd94c, cmode=,
vn_open_flags=, cred=0xfe0464bfd310,
fp=0xf80020b39320) at /usr/src/sys/kern/vfs_vnops.c:268
#14 0x80a348cf in kern_openat (td=0xf802aad3b4c0, fd=-100,
path=0x80182c1ec ,
pathseg=UIO_USERSPACE, flags=3, mode=)
at /usr/src/sys/kern/vfs_syscalls.c:1067
#15 0x80d9d862 in amd64_syscall (td=0xf802aad3b4c0, traced=0)
at subr_syscall.c:141
#16 0x80d8203b in Xfast_syscall ()
at /usr/src/sys/amd64/amd64/exception.S:398
#17 0x000802cdf8fa in ?? ()
Previous frame inner to this frame (corrupt stack?)
Current language:  auto; currently minimal

-- end here (output by kgdb)

As shown in the above, kernel panic was caused by 
assertion RTThreadPreemptIsEnabled(NIL_RTTHREAD) 
which tests the following expressions:

  1. curthread->td_critnest is equal to 0, and
  2. IF (interrupt flag) on eflag (or rflag ?) is equal to 1.  

This assertion will be successful only if both of above are true.  

As I read the source of VirtualBox, RTThreadPreemptIsEnabled is 
a part of test for preemtiveness which is used to create a spinlock.  
However, I'm not sure why assertion RTThreadPreemptIsEnabled is required, 
and this was failed on 10.3-STABLE r316132.  

I would appreciate any information.  Thanks.  

-- 
Hiroyuki Une: Hiroshima Kokusai Gakuin University
u...@hkg.ac.jp / harr...@seiryu.id.hkg.ac.jp
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: G965 patch for 6.3-Beta

2007-12-11 Thread Hiroyuki Une
On Mon, 10 Dec 2007 09:53:13 -0800
Hiroshi Nishida [EMAIL PROTECTED] wrote:

 I've attached the patch.
 Please apply it at /sys/pci.

Unfortunately, your patch didn't work correctly.

I obtained source of RELENG_6 by csup at 11 Dec 2007 22:25:56 JST(+0900),
applied your patch, and buildworld/buildkernel.
This kernel got the information about onboard VGA chip,
however, made X server frozen.
Furthermore, my box(Intel Core 2 Duo + Intel DQ965GF)
made no response from terminal/network,
and no core/kernel dumps are obtained.

I attached result of dmesg(8) and loading i915.ko by kldload(8).
What can I do to solve this problem?

Thank you.

-- 
Hiroyuki Une: Hiroshima Kokusai Gakuin University
[EMAIL PROTECTED] / [EMAIL PROTECTED]


dmesg.log
Description: Binary data


i915.log
Description: Binary data
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: G965 patch for 6.3-Beta

2007-12-11 Thread Hiroyuki Une
On Tue, 11 Dec 2007 09:32:05 -0800
Hiroshi Nishida [EMAIL PROTECTED] wrote:

Hi.

 Can you post your xorg.conf?

Sorry, I'll send this.
Should I also send kernel configuration file?
I used SMP in source files obtained by csup(8).

 And also /var/log/Xorg.0.log will have some clues.

Ah, my box froze and Xorg.0.log wasn't created.

 And,,, you may not need to kldload i915.ko because it seems to be loaded 
 automatically by agp.

I see.

---
Hiroyuki Une: Hiroshima Kokusai Gakuin University
[EMAIL PROTECTED] / [EMAIL PROTECTED]


xorg.conf.new
Description: Binary data
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: G965 patch for 6.3-Beta

2007-12-09 Thread Hiroyuki Une
On Fri, 07 Dec 2007 11:41:39 -0800
Hiroshi Nishida [EMAIL PROTECTED] wrote:

 Does anybody need an Intel G965 patch for 6.3-Beta AGP i810?
 I posted to Japanese freebsd-users-jp ML, but there has been no response.

At least, I need.  Your patch will fix the problem that xorg fails to detect 
memory 
assinged as the VRAM occationally.

Thank you.

---
Hiroyuki Une: Hiroshima Kokusai Gakuin University
[EMAIL PROTECTED] / [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]