Re: seldom crashes on Dell E6330 with 12-CURRENT
On 2016-Jul-25, at 10:50 PM, Matthias Apitz wrote: > > El día Monday, July 25, 2016 a las 05:00:59PM -0700, Mark Millard escribió: > >> Matthias Apitz guru at unixarea.de wrote on Mon Jul 25 16:10:52 UTC 2016 : >> >>> On Monday, 25 July 2016 17:11:23 CEST, Eric van Gyzen >> FreeBSD.org> wrote: > What file system are you using? >>> UFS; I followed the good instructions about new SSD disk configuration; >>> that's why I now have swap as plain file :-( >> >> Unfortunately see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206048 : >> >> 11.0-CURRENT -r293227 (and others) arm (rpi2/BeagleBone Black) amd64 etc: >> swapfile usage hangs; swap partition works . >> >> As far as I know it still applies for the problems that can occur for >> plain-file based swap files. The list of comments covers more than just >> armv6 as having example failures. >> > > Thanks for the pointer to the bug issue. I remembered, that I created > the swap file as a so called sparse file (dd ... bs=1m seek=8192 count=0) and > this is still visible with du(1): > > # du -sh /usr/swap01 ; ls -lh /usr/swap01 > 95M /usr/swap01 > -rw--- 1 root wheel 8,0G 25 jul. 08:19 /usr/swap01 > > I have now unmounted the swap and re-created it with real blocks: > > # swapoff -a > swapoff: removing /dev/md99 as swap device > > # dd if=/dev/zero of=/usr/swap01 bs=1m count=8192 > 8192+0 records in > 8192+0 records out > 8589934592 bytes transferred in 43.594277 secs (197042712 bytes/sec) > # du -sh /usr/swap01 ; ls -lh /usr/swap01 > 8,0G /usr/swap01 > -rw--- 1 root wheel 8,0G 26 jul. 07:24 /usr/swap01 > > I will first give this a try. If the crash rehappens, I will move it to > a real freebsd-swap partition. FYI: All my uses and testing of swap files used such a dd command to populate the file with blocks. I've never even tried a sparse file for such a thing. My experience indicates that this will not remove the problem if the swap file is in a file system on a partition with other file system activity (at least in the same file system?). The only type of context that I've had a swap file work over lots of use is when I used a whole partition containing just one UFS file system that only had the swap file added after the UFS file system was created. In other words: About the closest thing to being a swap partition that is still file based. I've only done this on TARGET_ARCH=powerpc and TARGET_ARCH=powerpc64. I tried it for them because TRIM was possible in the context: it was a SATA context with SSDs, not a USB context. (I did this during my very first FreeBSD experiments. I only learned later of problems with other variations.) My other, later contexts do not have TRIM as possible (for example, USB) and so I did not do that. It is these that I had troubles with and later switched to using a swap partition instead. [I will not have access to the powerpc's for weeks.] > > While saying 'crash', I now remember that in the two cases which I named > 'hard locked', the system was still alive in the sense of echoing typed > chars, it was only impossible to start new commands or login on another > console. This points too in the direction of a disk access or swap problem. > > Thanks > > matthias === Mark Millard markmi at dsl-only.net ___ 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: seldom crashes on Dell E6330 with 12-CURRENT
El día Monday, July 25, 2016 a las 05:00:59PM -0700, Mark Millard escribió: > Matthias Apitz guru at unixarea.de wrote on Mon Jul 25 16:10:52 UTC 2016 : > > > On Monday, 25 July 2016 17:11:23 CEST, Eric van Gyzen > FreeBSD.org> wrote: > > > > What file system are you using? > > UFS; I followed the good instructions about new SSD disk configuration; > > that's why I now have swap as plain file :-( > > Unfortunately see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206048 : > > 11.0-CURRENT -r293227 (and others) arm (rpi2/BeagleBone Black) amd64 etc: > swapfile usage hangs; swap partition works . > > As far as I know it still applies for the problems that can occur for > plain-file based swap files. The list of comments covers more than just armv6 > as having example failures. > Thanks for the pointer to the bug issue. I remembered, that I created the swap file as a so called sparse file (dd ... bs=1m seek=8192 count=0) and this is still visible with du(1): # du -sh /usr/swap01 ; ls -lh /usr/swap01 95M/usr/swap01 -rw--- 1 root wheel 8,0G 25 jul. 08:19 /usr/swap01 I have now unmounted the swap and re-created it with real blocks: # swapoff -a swapoff: removing /dev/md99 as swap device # dd if=/dev/zero of=/usr/swap01 bs=1m count=8192 8192+0 records in 8192+0 records out 8589934592 bytes transferred in 43.594277 secs (197042712 bytes/sec) # du -sh /usr/swap01 ; ls -lh /usr/swap01 8,0G/usr/swap01 -rw--- 1 root wheel 8,0G 26 jul. 07:24 /usr/swap01 I will first give this a try. If the crash rehappens, I will move it to a real freebsd-swap partition. While saying 'crash', I now remember that in the two cases which I named 'hard locked', the system was still alive in the sense of echoing typed chars, it was only impossible to start new commands or login on another console. This points too in the direction of a disk access or swap problem. Thanks matthias -- Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/ ☎ +49-176-38902045 "Wer übersieht, dass wir uns den anderen weggenommen haben und sie uns wiederhaben wollen, kann von den Kämpfen der letzten Tage keinen verstehen. Und kann natürlich auch keinen dieser Kämpfe bestehen." Hermann Kant in jW 1.10.1989 ___ 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 when loading vboxdrv module
On Mon, Jul 25, 2016 at 07:43:32PM -0400, Jung-uk Kim wrote: > Oops, I meant INVARIANTS. Anyway, it should be fixed in r419083. I > understand you have a panic with aio(4) but that's a separate issue. > > Jung-uk Kim Should I create a new PR for virtualbox and aio, or is this already known? signature.asc Description: PGP signature
Re: seldom crashes on Dell E6330 with 12-CURRENT
Matthias Apitz guru at unixarea.de wrote on Mon Jul 25 16:10:52 UTC 2016 : > On Monday, 25 July 2016 17:11:23 CEST, Eric van Gyzen FreeBSD.org> wrote: > > > What file system are you using? > UFS; I followed the good instructions about new SSD disk configuration; > that's why I now have swap as plain file :-( Unfortunately see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206048 : 11.0-CURRENT -r293227 (and others) arm (rpi2/BeagleBone Black) amd64 etc: swapfile usage hangs; swap partition works . As far as I know it still applies for the problems that can occur for plain-file based swap files. The list of comments covers more than just armv6 as having example failures. === Mark Millard markmi at dsl-only.net ___ 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 when loading vboxdrv module
On Mon, Jul 25, 2016 at 04:09:58PM -0400, Jung-uk Kim wrote: > If you feel adventurous, please drop the attached patch in > *emulators/virtualbox-ose/files* directory, and rebuild > *emulators/virtualbox-ose-kmod*. > > JK > > * Note the patch directory is emulators/virtualbox-ose/files, not > emulators/virtualbox-ose-kmod/files. > --- src/VBox/HostDrivers/Support/SUPDrvInternal.h.orig2016-07-18 > 11:56:19 UTC > +++ src/VBox/HostDrivers/Support/SUPDrvInternal.h > @@ -235,7 +235,7 @@ > # define SUPDRV_WITHOUT_MSR_PROBER > #endif > > -#if 1 > +#if 0 > /** @def SUPDRV_USE_TSC_DELTA_THREAD > * Use a dedicated kernel thread to service TSC-delta measurement requests. > * @todo Test on servers with many CPUs and sockets. */ With the patch, vboxdrv loads successfully. But when I start a VM, I get the following panic (after rebuilding virtualbox-ose as well): > vboxdrv: 82973020 VMMR0.r0 > vboxdrv: 82a92020 VBoxDDR0.r0 > vboxdrv: 82aaf020 VBoxDD2R0.r0 > panic: _mtx_lock_sleep: recursed on non-recursive mutex aiomtx @ > /usr/src/sys/kern/vfs_aio.c:996 > > cpuid = 1 > KBD: stack backtrace: > db_trace_wrapper() at db_trace_wrapper+0x2b > vpanic() at vpanic+0x182 > kassert_panic() at kassert_panic+0x126 > __mtx_lock_sleep() at __mtx_lock_sleep+0x228 > __mtx_lock_flags() at __mtx_lock_flags+0x10d > aio_queue() at aio_queue+0x9d6 > amd64_syscall() at amd64_syscall+0x2db > Xfast_syscall() at Xfast_syscall+0xfb > --- syscall (465, FreeBSD ELF64, sys_aio_fsync), rip = 0x80119fa0a, rsp = > 0x7fffdf2abc98, rbp = 0x7fffdf2abcd0 --- > KDB: enter: panic > [ thread pid 14588 tid 101813 ] > Stopped at kdb_enter+0x3b: movq$0,kdb_why signature.asc Description: PGP signature
Re: Panic when loading vboxdrv module
On 07/25/16 03:13 PM, Randy Westlund wrote: > I'm running 12-CURRENT r303286 and virtualbox-ose-kmod-5.0.26. I just > rebuilt the module, so I know they're in sync. When I boot with > vboxdrv_load="YES" in /etc/loader.conf, I get this panic during boot: > >> panic: mutex Giant owned at /usr/src/sys/kern/kern_sync.c:406 >> cpuid = 0 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b >> vpanic() at vpanic+0x182 >> panic() at panic+0x43 >> __mtx_assert() at __mtx_assert+0xd1 >> mi_switch() at mi_switch+0x7b >> sleepq_switch() at sleepq_switch+0x7e >> sleepq_timedwait() at sleepq_timedwait+0x43 >> rtR0SemEventWait() at rtR0SemEventWait+0x267 >> supdrvGipCreate() at supdrvGipCreate+0x7f6 >> supdrvInitDexExt() at supdrvInitDexExt+0x18f >> VBoxDrvFreeBSDModuleEvent() at VBoxDrvFreeBSDModuleEvent+0x49 >> module_register_init() at module_register_init+0xb0 >> mi_startup() at mi_startup+0x118 >> btext() at btext+0x2c >> KDB: enter: panic >> [ thread pid 0 tid 10 ] >> Stopped at kdb_enter+0x3b: movq$0,kdb_why > > I'm not sure whether this is a problem with the base system or the port, > but this happens every time I boot with the module enabled. emulators/virtualbox-ose-kmod is causing the trouble and this problem is well known. To work around it, remove WITNESS option from kernel configuration for now. Jung-uk Kim signature.asc Description: OpenPGP digital signature
Panic when loading vboxdrv module
I'm running 12-CURRENT r303286 and virtualbox-ose-kmod-5.0.26. I just rebuilt the module, so I know they're in sync. When I boot with vboxdrv_load="YES" in /etc/loader.conf, I get this panic during boot: > panic: mutex Giant owned at /usr/src/sys/kern/kern_sync.c:406 > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b > vpanic() at vpanic+0x182 > panic() at panic+0x43 > __mtx_assert() at __mtx_assert+0xd1 > mi_switch() at mi_switch+0x7b > sleepq_switch() at sleepq_switch+0x7e > sleepq_timedwait() at sleepq_timedwait+0x43 > rtR0SemEventWait() at rtR0SemEventWait+0x267 > supdrvGipCreate() at supdrvGipCreate+0x7f6 > supdrvInitDexExt() at supdrvInitDexExt+0x18f > VBoxDrvFreeBSDModuleEvent() at VBoxDrvFreeBSDModuleEvent+0x49 > module_register_init() at module_register_init+0xb0 > mi_startup() at mi_startup+0x118 > btext() at btext+0x2c > KDB: enter: panic > [ thread pid 0 tid 10 ] > Stopped at kdb_enter+0x3b: movq$0,kdb_why I'm not sure whether this is a problem with the base system or the port, but this happens every time I boot with the module enabled. signature.asc Description: PGP signature
Re: seldom crashes on Dell E6330 with 12-CURRENT
On Monday, 25 July 2016 17:11:23 CEST, Eric van Gyzen wrote: What file system are you using? UFS; I followed the good instructions about new SSD disk configuration; that's why I now have swap as plain file :-( Do a full fsck (or zfs scrub). will do a full fsck; Try moving swap to a raw (freebsd-swap) partition so that you might get a kernel core dump. That will be the essential next step. ok, I will dump /usr to some external disk, shrink the partition, creat swap and re-create /usr Without more details from a core dump or debugger, your best option is to try a release or an older build. If that works, try to find the commit that introduced the behavior. This will be very tedious and time-consuming for your scenario, so definitely try getting a core dump first. the problem is as well: until now no further crashes had occured, i.e. it' difficult to see if it works or not; matthias -- Sent from my Ubuntu phone http://www.unixarea.de/ ___ 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: seldom crashes on Dell E6330 with 12-CURRENT
On 07/23/16 02:21 AM, Matthias Apitz wrote: > > Hello, > > I own since July 15 a new laptop and faced 3 crashes, details see below. > What can I do to gather more information? Thanks > > > notes in general: > - hardware: Dell E6330, amd64, 4 cores i5-3360M, 8 GByte RAM, 250 GByte SSD > w/ TRIM > - WLAN: urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R > - kernel: GENERIC r302904 (July 15) > - poudriere 3.2-pre: compiling ~1800 ports in 4 builders > - swap as plain file in /usr/swap01, 8 GByte > - apart of the crashes below, no crash during buildworld, buildkernel and > ~48 hours of poudriere fetching distfiles and making ~1800 ports > - no errors on 'memtest 1G' > > crashes/observations: > > 16.07.2016 07:12 > - on shutdown swap device (plain file in /usr) could not be detached > - drop to kdb > - nothing in /var/log/messages > > 17.07.2016 19:41 > - hard locked, had to power-off > - last command issued on console (no X11): cp -p * /usr/PKGDIR (around 1700 > files, 2 GByte) > - nothing in /var/log/messages > > 20.07.2016 19:27 > - hard locked, had to power-off > - last command issued in xterm: fgrep mra... ~/* > - nothing in /var/log/messages What file system are you using? Do a full fsck (or zfs scrub). Try moving swap to a raw (freebsd-swap) partition so that you might get a kernel core dump. That will be the essential next step. Without more details from a core dump or debugger, your best option is to try a release or an older build. If that works, try to find the commit that introduced the behavior. This will be very tedious and time-consuming for your scenario, so definitely try getting a core dump first. Eric ___ 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"
