Re: FreeBSD 10 Beta2 /etc/rc.d/named script and /etc/defaults/rc.conf
[adding maintainer to Cc] On Mon, Nov 04, 2013 at 01:41:01AM +0200, George Kontostanos wrote: G Am 03.11.2013 um 23:06 schrieb Gleb Smirnoff gleb...@freebsd.org: G G On Sun, Nov 03, 2013 at 10:05:02PM +0200, Özkan KIRIK wrote: G Ö Altough bind removed from FreeBSD 10 distribution, /etc/rc.d/named G script G Ö still exists. G Ö and this script depends on /etc/mtree/BIND.chroot.dist file but G there is G Ö no such file in source tree. G Ö I think this file was forgotten to be removed. G Ö G Ö And also, named_* definitions still exists in /etc/defaults/rc.conf G file. G G Please review attached file that removes named from /etc. G G It would be great if the port would learn to install its own script etc. G in time for that change. (Unless it’s already there, and I’m just too blind G to see it.) G G No you are not blind. Installing bind from ports still relies on the G /etc/rc.d/named script. Erwin, can you please handle that? -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Automated submission of kernel panic reports: sysutils/panicmail
Hi all, After considerable review on freebsd-hackers (thanks dt71 and jilles!) I have now added sysutils/panicmail to the FreeBSD ports tree. If you install this and add panicmail_enable=YES to your /etc/rc.conf, a panic report will be generated and sent to root@ for you to review and submit (via email). You can skip the reviewing step and submit panics automatically by setting panicmail_autosubmit=YES. The panics submitted are encrypted to an RSA key which I hold in order to keep them secure in transit; and I intend to keep the raw panic reports confidential except to the minimum extent necessary for other developers to help me process the incoming reports. If I receive enough panic reports to be useful, I hope to provide developers with aggregate statistics. This may include: * regular email reports listing the top panics, to help guide developers towards the most fertile areas for stability improvements; * email to specific developers alerting them to recurring panics in code they maintain (especially if it becomes clear that the panic has been recently introduced); and * guidance to re@ and secteam@ about how often a particular panic occurs if an errata notice is being considered as well as other yet-to-be-imagined reports of a similarly aggregate and anonymized nature. So please install the sysutils/panicmail port and enable it in rc.conf! This all depends on getting useful data, and I can't do that without your help. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Automated submission of kernel panic reports: sysutils/panicmail
Hi, On 4 Nov 2013, at 10:41, Colin Percival wrote: Hi all, After considerable review on freebsd-hackers (thanks dt71 and jilles!) I have now added sysutils/panicmail to the FreeBSD ports tree. [etc] Nice. Is this applicable to all supported branches? -- Bob Bishop r...@gid.co.uk ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Automated submission of kernel panic reports: sysutils/panicmail
On 11/04/13 02:47, Bob Bishop wrote: On 4 Nov 2013, at 10:41, Colin Percival wrote: After considerable review on freebsd-hackers (thanks dt71 and jilles!) I have now added sysutils/panicmail to the FreeBSD ports tree. [etc] Nice. Is this applicable to all supported branches? Yes... the code should work all the way back to 5.0 (it's an rc.d script), although I doubt ports infrastructure will allow you to install anything from today's ports tree on a system running FreeBSD 5.0. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD 10 Beta2 /etc/rc.d/named script and /etc/defaults/rc.conf
On 04 Nov 2013, at 09:34, Gleb Smirnoff gleb...@freebsd.org wrote: [adding maintainer to Cc] On Mon, Nov 04, 2013 at 01:41:01AM +0200, George Kontostanos wrote: G Am 03.11.2013 um 23:06 schrieb Gleb Smirnoff gleb...@freebsd.org: G G On Sun, Nov 03, 2013 at 10:05:02PM +0200, Özkan KIRIK wrote: G Ö Altough bind removed from FreeBSD 10 distribution, /etc/rc.d/named G script G Ö still exists. G Ö and this script depends on /etc/mtree/BIND.chroot.dist file but G there is G Ö no such file in source tree. G Ö I think this file was forgotten to be removed. G Ö G Ö And also, named_* definitions still exists in /etc/defaults/rc.conf G file. G G Please review attached file that removes named from /etc. G G It would be great if the port would learn to install its own script etc. G in time for that change. (Unless it’s already there, and I’m just too blind G to see it.) G G No you are not blind. Installing bind from ports still relies on the G /etc/rc.d/named script. Erwin, can you please handle that? Things are much worse that this, the ports are completely written under the assumption that there is a Bind in base, which of course would already break with WITHOUT_BIND before Bind was completely removed. It will be hard to fix without breaking the installed base of 8 and 9. Sigh. I'll try to work on it this week, but unfortunately have a full schedule of meetings and travel as well. Erwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 10.0-BETA1 i386 on VirtualBox
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03.11.2013 15:41, Konstantin Belousov wrote: On Sun, Nov 03, 2013 at 05:46:01PM +0400, Gleb Smirnoff wrote: Maciej, Boris, On Sun, Nov 03, 2013 at 04:29:11PM +0400, Boris Bobrov wrote: B I traced this down to r248521: B svn log -r248521 B --- B - r248521 | kib | 2013-03-19 16:08:15 +0100 (Tue, 19 Mar 2013) | 5 B lines B B UFS support of the unmapped i/o for the user data buffers. B B Sponsored by: The FreeBSD Foundation B Tested by: pho, scottl, jhb, bf B B --- B - B B The last working revision is 248520. B B Yes, I confirm that. Thanks for you help! Can you please now try unpatched vanilla 10.0-BETA2 iso file and when it boots set in loader (before kernel): OK set vfs.unmapped_buf_allowed=0 OK boot Show what disk driver is used, also show the output of hw.ncpu, both from the guest. Konstantin, do you need any other/more info from guest host? Other than hw.ncpu=1 Disk is ada0 at ahcich0 bus 0 scbus2 target 0 lun 0 and second test instance is ada0 at ata0 bus 0 scbus0 target 0 lun 0 Is Gleb's loader hint the final right solution for this problem? - -- Pozdrawiam, Maciej Milewski -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJ3hUEACgkQPQ1pa2ELkNl26wCdG0wsFWMxu+iN4Xig/I4lQ5pv i+gAn1OAVEvf0vXAZu4PRmr9+oEkW+jA =9+kM -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Automated submission of kernel panic reports: sysutils/panicmail
On 11/4/13, 2:41 AM, Colin Percival wrote: Hi all, After considerable review on freebsd-hackers (thanks dt71 and jilles!) I have now added sysutils/panicmail to the FreeBSD ports tree. If you install this and add panicmail_enable=YES to your /etc/rc.conf, a panic report will be generated and sent to root@ for you to review and submit (via email). You can skip the reviewing step and submit panics automatically by setting panicmail_autosubmit=YES. The panics submitted are encrypted to an RSA key which I hold in order to keep them secure in transit; and I intend to keep the raw panic reports confidential except to the minimum extent necessary for other developers to help me process the incoming reports. If I receive enough panic reports to be useful, I hope to provide developers with aggregate statistics. This may include: * regular email reports listing the top panics, to help guide developers towards the most fertile areas for stability improvements; * email to specific developers alerting them to recurring panics in code they maintain (especially if it becomes clear that the panic has been recently introduced); and * guidance to re@ and secteam@ about how often a particular panic occurs if an errata notice is being considered as well as other yet-to-be-imagined reports of a similarly aggregate and anonymized nature. So please install the sysutils/panicmail port and enable it in rc.conf! This all depends on getting useful data, and I can't do that without your help. Colin, have you had a few minutes to check out the crash reporting facilities in FreeNAS? The reason I ask is that: 1) we would like to share code. 2) we have this running for a few months now and have a huge corpus of information. 3) we are building a nice UI (screenshots attached) over it, we have a couple of thousands of lines of code we can share for this. Our scripts can be found here: 1) A startup script that sends us the crashes on system start: https://github.com/freenas/freenas/blob/master/nanobsd/Files/etc/rc.d/ix_textdump 2) A script to submit data at boot OR from command line that sends more comprehensive system information ixdiagnose: https://github.com/freenas/freenas/blob/master/nanobsd/Files/usr/local/bin/ixdiagnose 3) A very simple script to upload that report: https://github.com/freenas/freenas/blob/master/nanobsd/Files/usr/local/bin/crashuploader We send a minimal set of information: kernel stack trace, ddb buffer and hardware. Just enough to get some very, very handy stuff. I can share with you offline the crash server code, it's django and relatively straight forward. The screenshots can also be seen at: http://people.freebsd.org/~alfred/crashreporter/ We could modify our framework for FreeBSD to do so by checking for a sentinel file depending on the host type and only auto-sending if we see that. -Alfred ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
(r257598) panic: Assertion tmp-tm_pages_used == 0 failed at /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316
11.0-CURRENT #87 r257598 During a poudriere build. It creates a tmpfs, builds a port in a jail using that tmpfs and then removes the tmpfs and recreate the tmpfs before building the next port. panic: Assertion tmp-tm_pages_used == 0 failed at /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316 cpuid = 9 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe1247ee57a0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe1247ee5850 vpanic() at vpanic+0x126/frame 0xfe1247ee5890 kassert_panic() at kassert_panic+0x136/frame 0xfe1247ee5900 tmpfs_unmount() at tmpfs_unmount+0x163/frame 0xfe1247ee5930 dounmount() at dounmount+0x41f/frame 0xfe1247ee59b0 sys_unmount() at sys_unmount+0x356/frame 0xfe1247ee5ae0 amd64_syscall() at amd64_syscall+0x265/frame 0xfe1247ee5bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe1247ee5bf0 --- syscall (22, FreeBSD ELF64, sys_unmount), rip = 0x8008a02fa, rsp = 0x7fffd198, rbp = 0x7fffd2b0 --- Uptime: 44m40s (kgdb) #0 doadump (textdump=1) at pcpu.h:219 #1 0x808bcf87 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0x808bd495 in vpanic (fmt=value optimized out, ap=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:754 #3 0x808bd326 in kassert_panic (fmt=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:642 #4 0x81e159d3 in tmpfs_unmount (mp=0xf810502cd660, mntflags=value optimized out) at /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316 #5 0x8095e1af in dounmount (mp=0xf810502cd660, flags=134742016, td=0xf8013d57a490) at /usr/src/sys/kern/vfs_mount.c:1324 #6 0x8095dd66 in sys_unmount (td=0xf8013d57a490, uap=0xfe1247ee5b80) at /usr/src/sys/kern/vfs_mount.c:1212 #7 0x80cb7d75 in amd64_syscall (td=0xf8013d57a490, traced=0) at subr_syscall.c:134 #8 0x80c9c90b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:391 #9 0x0008008a02fa in ?? () -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: newcons comming
On 4 November 2013 02:16, Kevin Oberman rkober...@gmail.com wrote: Excellent news. I'm really looking forward to newcons. Guess it's time to move my T520 to 10-Stable (or Beta) I'm running a Newcons kernel on my Thinkpad X220 now and it's working well, with a few minor quirks. This is with the X-related packages rebuilt with WITH_NEW_XORG= and WITH_KMS= in /etc/make.conf. Are you booting directly to X or using startx from the console? In either case, I think that i915kms should auto-load at the start of X, so you should not need to pre-load it. I log in and running startx. i915kms does auto-load. Does newcons require VESA? If not, you should be able to remove it from your kernel to get suspend/resume working from X. It does not use VESA - it's removed from GENERIC on the newcons branch. Suspend and resume generally works on my X220 now, from X or console. There are some outstanding issues, for example the X display sometimes ends up corrupted after resume; stopping and restarting X fixes that. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: (r257598) panic: Assertion tmp-tm_pages_used == 0 failed at /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316
On 2013-11-04 09:35, Bryan Drewery wrote: 11.0-CURRENT #87 r257598 During a poudriere build. It creates a tmpfs, builds a port in a jail using that tmpfs and then removes the tmpfs and recreate the tmpfs before building the next port. panic: Assertion tmp-tm_pages_used == 0 failed at /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316 cpuid = 9 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe1247ee57a0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe1247ee5850 vpanic() at vpanic+0x126/frame 0xfe1247ee5890 kassert_panic() at kassert_panic+0x136/frame 0xfe1247ee5900 tmpfs_unmount() at tmpfs_unmount+0x163/frame 0xfe1247ee5930 dounmount() at dounmount+0x41f/frame 0xfe1247ee59b0 sys_unmount() at sys_unmount+0x356/frame 0xfe1247ee5ae0 amd64_syscall() at amd64_syscall+0x265/frame 0xfe1247ee5bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe1247ee5bf0 --- syscall (22, FreeBSD ELF64, sys_unmount), rip = 0x8008a02fa, rsp = 0x7fffd198, rbp = 0x7fffd2b0 --- Uptime: 44m40s (kgdb) #0 doadump (textdump=1) at pcpu.h:219 #1 0x808bcf87 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0x808bd495 in vpanic (fmt=value optimized out, ap=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:754 #3 0x808bd326 in kassert_panic (fmt=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:642 #4 0x81e159d3 in tmpfs_unmount (mp=0xf810502cd660, mntflags=value optimized out) at /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316 #5 0x8095e1af in dounmount (mp=0xf810502cd660, flags=134742016, td=0xf8013d57a490) at /usr/src/sys/kern/vfs_mount.c:1324 #6 0x8095dd66 in sys_unmount (td=0xf8013d57a490, uap=0xfe1247ee5b80) at /usr/src/sys/kern/vfs_mount.c:1212 #7 0x80cb7d75 in amd64_syscall (td=0xf8013d57a490, traced=0) at subr_syscall.c:134 #8 0x80c9c90b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:391 #9 0x0008008a02fa in ?? () Not sure if it is related, but I had a similar looking panic on a 10.0-BETA1 machine after doing a zfs receive: Fatal trap 12: page fault while in kernel mode cpuid = 5; apic id = 05 fault virtual address = 0x378 fault code= supervisor read data, page not present instruction pointer = 0x20:0x8089bf51 stack pointer = 0x28:0xfe1835d715d0 frame pointer = 0x28:0xfe1835d71650 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 44435 (zfs) trap number = 12 panic: page fault cpuid = 5 KDB: stack backtrace: #0 0x808e7580 at kdb_backtrace+0x60 #1 0x808af065 at panic+0x155 #2 0x80c8e292 at trap_fatal+0x3a2 #3 0x80c8e569 at trap_pfault+0x2c9 #4 0x80c8dcf6 at trap+0x5e6 #5 0x80c75022 at calltrap+0x8 #6 0x8094a32b at vflush+0x48b #7 0x8189e682 at zfs_umount+0x112 #8 0x809434f5 at dounmount+0x4b5 #9 0x80943004 at sys_unmount+0x3d4 #10 0x80c8eb87 at amd64_syscall+0x357 #11 0x80c7530b at Xfast_syscall+0xfb -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: (r257598) panic: Assertion tmp-tm_pages_used == 0 failed at /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316
On Mon, Nov 04, 2013 at 08:35:17AM -0600, Bryan Drewery wrote: 11.0-CURRENT #87 r257598 During a poudriere build. It creates a tmpfs, builds a port in a jail using that tmpfs and then removes the tmpfs and recreate the tmpfs before building the next port. panic: Assertion tmp-tm_pages_used == 0 failed at /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316 cpuid = 9 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe1247ee57a0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe1247ee5850 vpanic() at vpanic+0x126/frame 0xfe1247ee5890 kassert_panic() at kassert_panic+0x136/frame 0xfe1247ee5900 tmpfs_unmount() at tmpfs_unmount+0x163/frame 0xfe1247ee5930 dounmount() at dounmount+0x41f/frame 0xfe1247ee59b0 sys_unmount() at sys_unmount+0x356/frame 0xfe1247ee5ae0 amd64_syscall() at amd64_syscall+0x265/frame 0xfe1247ee5bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe1247ee5bf0 --- syscall (22, FreeBSD ELF64, sys_unmount), rip = 0x8008a02fa, rsp = 0x7fffd198, rbp = 0x7fffd2b0 --- Uptime: 44m40s (kgdb) #0 doadump (textdump=1) at pcpu.h:219 #1 0x808bcf87 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0x808bd495 in vpanic (fmt=value optimized out, ap=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:754 #3 0x808bd326 in kassert_panic (fmt=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:642 #4 0x81e159d3 in tmpfs_unmount (mp=0xf810502cd660, mntflags=value optimized out) at /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316 #5 0x8095e1af in dounmount (mp=0xf810502cd660, flags=134742016, td=0xf8013d57a490) at /usr/src/sys/kern/vfs_mount.c:1324 #6 0x8095dd66 in sys_unmount (td=0xf8013d57a490, uap=0xfe1247ee5b80) at /usr/src/sys/kern/vfs_mount.c:1212 #7 0x80cb7d75 in amd64_syscall (td=0xf8013d57a490, traced=0) at subr_syscall.c:134 #8 0x80c9c90b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:391 #9 0x0008008a02fa in ?? () Do you have core ? I want to see the struct tmpfs_mount content for the tmpfs mount point which caused the panic. pgpXHa9Qv8giA.pgp Description: PGP signature
Re: FreeBSD 10 Beta2 /etc/rc.d/named script and /etc/defaults/rc.conf
On Mon, Nov 04, 2013 at 12:11:02PM +0100, Erwin Lansing wrote: E On Mon, Nov 04, 2013 at 01:41:01AM +0200, George Kontostanos wrote: E G Am 03.11.2013 um 23:06 schrieb Gleb Smirnoff gleb...@freebsd.org: E G E G On Sun, Nov 03, 2013 at 10:05:02PM +0200, Özkan KIRIK wrote: E G Ö Altough bind removed from FreeBSD 10 distribution, /etc/rc.d/named E G script E G Ö still exists. E G Ö and this script depends on /etc/mtree/BIND.chroot.dist file but E G there is E G Ö no such file in source tree. E G Ö I think this file was forgotten to be removed. E G Ö E G Ö And also, named_* definitions still exists in /etc/defaults/rc.conf E G file. E G E G Please review attached file that removes named from /etc. E G E G It would be great if the port would learn to install its own script etc. E G in time for that change. (Unless it’s already there, and I’m just too blind E G to see it.) E G E G No you are not blind. Installing bind from ports still relies on the E G /etc/rc.d/named script. E E Erwin, can you please handle that? E E Things are much worse that this, the ports are completely written under the assumption that there is a Bind in base, which of course would already break with WITHOUT_BIND before Bind was completely removed. It will be hard to fix without breaking the installed base of 8 and 9. Sigh. E E I'll try to work on it this week, but unfortunately have a full schedule of meetings and travel as well. What should we do with src? IMO, we should proceed with removal of remnants of bind in src. In the worst case, if you can't handle it this week, the situation will be the following: 1) 8.x, 9.x users are okay 2) 10+.x users w/o bind are okay 3) 10+.x users with bind have problems If we skip updating src, then situation would be: 1) 8.x, 9.x users are okay 2) 10+.x users w/o bind have problems 3) 10+.x users with bind are okay I think, there are less 10.x users with bind, than 10.x without it. -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 10.0-BETA1 i386 on VirtualBox
On Mon, Nov 04, 2013 at 12:30:09PM +0100, Maciej Milewski wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03.11.2013 15:41, Konstantin Belousov wrote: On Sun, Nov 03, 2013 at 05:46:01PM +0400, Gleb Smirnoff wrote: Maciej, Boris, On Sun, Nov 03, 2013 at 04:29:11PM +0400, Boris Bobrov wrote: B I traced this down to r248521: B svn log -r248521 B --- B - r248521 | kib | 2013-03-19 16:08:15 +0100 (Tue, 19 Mar 2013) | 5 B lines B B UFS support of the unmapped i/o for the user data buffers. B B Sponsored by: The FreeBSD Foundation B Tested by: pho, scottl, jhb, bf B B --- B - B B The last working revision is 248520. B B Yes, I confirm that. Thanks for you help! Can you please now try unpatched vanilla 10.0-BETA2 iso file and when it boots set in loader (before kernel): OK set vfs.unmapped_buf_allowed=0 OK boot Show what disk driver is used, also show the output of hw.ncpu, both from the guest. Konstantin, do you need any other/more info from guest host? Other than hw.ncpu=1 Disk is ada0 at ahcich0 bus 0 scbus2 target 0 lun 0 and second test instance is ada0 at ata0 bus 0 scbus0 target 0 lun 0 So both ahci and ata attached disks show the bug ? Also please show me the CPU features banner from the boot in the VB, like this: CPU: Intel(R) Core(TM) i7-4770S CPU @ 3.10GHz (2993.13-MHz K8-class CPU) Origin = GenuineIntel Id = 0x306c3 Family = 0x6 Model = 0x3c Stepping = 3 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x7ffafbffSSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,b11,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND AMD Features=0x2c100800SYSCALL,NX,Page1GB,RDTSCP,LM AMD Features2=0x21LAHF,ABM Standard Extended Features=0x2fbbGSFSBASE,TSCADJ,BMI1,HLE,AVX2,SMEP,BMI2,ENHMOVSB,INVPCID,RTM TSC: P-state invariant, performance statistics real memory = 34359738368 (32768 MB) Is Gleb's loader hint the final right solution for this problem? Probably not. This smells like a bug in the vbox. It is especially suspicious that only some i/o transfers cause corruption. pgpIHt1IrS9yS.pgp Description: PGP signature
Re: (r257598) panic: Assertion tmp-tm_pages_used == 0 failed at /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316
On 2013-11-04 10:27, Konstantin Belousov wrote:
On Mon, Nov 04, 2013 at 08:35:17AM -0600, Bryan Drewery wrote:
11.0-CURRENT #87 r257598
During a poudriere build.
It creates a tmpfs, builds a port in a jail using that tmpfs and then
removes the tmpfs and recreate the tmpfs before building the next
port.
panic: Assertion tmp-tm_pages_used == 0 failed at
/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316
cpuid = 9
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe1247ee57a0
kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe1247ee5850
vpanic() at vpanic+0x126/frame 0xfe1247ee5890
kassert_panic() at kassert_panic+0x136/frame 0xfe1247ee5900
tmpfs_unmount() at tmpfs_unmount+0x163/frame 0xfe1247ee5930
dounmount() at dounmount+0x41f/frame 0xfe1247ee59b0
sys_unmount() at sys_unmount+0x356/frame 0xfe1247ee5ae0
amd64_syscall() at amd64_syscall+0x265/frame 0xfe1247ee5bf0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe1247ee5bf0
--- syscall (22, FreeBSD ELF64, sys_unmount), rip = 0x8008a02fa, rsp =
0x7fffd198, rbp = 0x7fffd2b0 ---
Uptime: 44m40s
(kgdb) #0 doadump (textdump=1) at pcpu.h:219
#1 0x808bcf87 in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:447
#2 0x808bd495 in vpanic (fmt=value optimized out,
ap=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:754
#3 0x808bd326 in kassert_panic (fmt=value optimized out)
at /usr/src/sys/kern/kern_shutdown.c:642
#4 0x81e159d3 in tmpfs_unmount (mp=0xf810502cd660,
mntflags=value optimized out)
at /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316
#5 0x8095e1af in dounmount (mp=0xf810502cd660, flags=134742016,
td=0xf8013d57a490) at /usr/src/sys/kern/vfs_mount.c:1324
#6 0x8095dd66 in sys_unmount (td=0xf8013d57a490,
uap=0xfe1247ee5b80) at /usr/src/sys/kern/vfs_mount.c:1212
#7 0x80cb7d75 in amd64_syscall (td=0xf8013d57a490, traced=0)
at subr_syscall.c:134
#8 0x80c9c90b in Xfast_syscall ()
at /usr/src/sys/amd64/amd64/exception.S:391
#9 0x0008008a02fa in ?? ()
Do you have core ?
I want to see the struct tmpfs_mount content for the tmpfs mount point
which caused the panic.
Yes.
Hopefully this is what you're asking for:
(kgdb) frame
#4 0x81e159d3 in tmpfs_unmount (mp=0xf810502cd660,
mntflags=value optimized out) at
/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316
316 MPASS(tmp-tm_pages_used == 0);
(kgdb) print *mp
$2 = {mnt_mtx = {lock_object = {lo_name = 0x80f11f09 struct
mount mtx, lo_flags = 16973824, lo_data = 0, lo_witness =
0xfe6d3b00}, mtx_lock = 4}, mnt_gen = 1, mnt_list = {tqe_next =
0xf8116be06660, tqe_prev = 0xf81050257688}, mnt_op =
0x81e1b940, mnt_vfc = 0x81e1ba60, mnt_vnodecovered =
0xf8104fb0c3b0,
mnt_syncer = 0x0, mnt_ref = 1, mnt_nvnodelist = {tqh_first = 0x0,
tqh_last = 0xf810502cd6c0}, mnt_nvnodelistsize = 0,
mnt_activevnodelist = {tqh_first = 0x0, tqh_last = 0xf810502cd6d8},
mnt_activevnodelistsize = 0, mnt_writeopcount = 1, mnt_kern_flag =
16777225, mnt_flag = 4096, mnt_opt = 0xf80014424ae0, mnt_optnew =
0x0, mnt_maxsymlinklen = 0,
mnt_stat = {f_version = 537068824, f_type = 135, f_flags = 4096,
f_bsize = 4096, f_iosize = 4096, f_blocks = 17125058, f_bfree =
17049291, f_bavail = 17049291, f_files = 2147483647, f_ffree =
2147473906, f_syncwrites = 0, f_asyncwrites = 0, f_syncreads = 0,
f_asyncreads = 0, f_spare = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, f_namemax =
255, f_owner = 0, f_fsid = {
val = {-2029977679, 135}}, f_charspare = '\0' repeats 79 times,
f_fstypename = tmpfs\000\000\000\000\000\000\000\000\000\000,
f_mntfromname = tmpfs, '\0' repeats 82 times, f_mntonname =
/poudriere/data/build/exp-91amd64-default-xzibition/08/usr/local, '\0'
repeats 23 times}, mnt_cred = 0xf8001418e100, mnt_data =
0xf80fedf75700,
mnt_time = 0, mnt_iosize_max = 65536, mnt_export = 0x0, mnt_label =
0x0, mnt_hashseed = 4132690418, mnt_lockref = 0, mnt_secondary_writes =
0, mnt_secondary_accwrites = 0, mnt_susp_owner = 0x0, mnt_gjprovider =
0x0, mnt_explock = {lock_object = {lo_name = 0x80f11f1a
explock, lo_flags = 108199936, lo_data = 0, lo_witness =
0xfe6eb280},
lk_lock = 1, lk_exslpfail = 0, lk_timo = 0, lk_pri = 96},
mnt_upper_link = {tqe_next = 0x0, tqe_prev = 0x0}, mnt_uppers =
{tqh_first = 0x0, tqh_last = 0xf810502cd980}}
(kgdb) print *(struct tmpfs_mount *)(mp)-mnt_data
$3 = {tm_pages_max = 18446744073709551615, tm_pages_used =
18446744073709551615, tm_root = 0xf8104ff44828, tm_nodes_max =
2147483647, tm_ino_unr = 0xf8002fd65080, tm_nodes_inuse = 0,
tm_maxfilesize = 9223372036854775807, tm_nodes_used = {lh_first = 0x0},
allnode_lock = {lock_object = {lo_name = 0x81e1aa47 tmpfs
allnode lock,
Re: 10.0-BETA1 i386 on VirtualBox
On Mon, Nov 04, 2013 at 06:38:25PM +0200, Konstantin Belousov wrote: K Also please show me the CPU features banner from the boot in the VB, K like this: I have already collected them all. See attaches. Legend: dmesg.bbpwd_mkdb crashes during install dmesg.milu.png pwd_mkdb crashes during install dmesg.think installation succeeds, but world build crashes instantly dmesg.ruall works dmesg.morannon all works -- Totus tuus, Glebius. Copyright (c) 1992-2013 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 10.0-BETA2 #0 r257166: Sat Oct 26 21:52:30 UTC 2013 r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC i386 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 CPU: Intel(R) Core(TM)2 Duo CPU T6570 @ 2.10GHz (1727.60-MHz 686-class CPU) Origin = GenuineIntel Id = 0x1067a Family = 0x6 Model = 0x17 Stepping = 10 Features=0x783fbbfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2 Features2=0x209SSE3,MON,SSSE3 real memory = 268369920 (255 MB) avail memory = 239337472 (228 MB) kbd1 at kbdmux0 random: Software, Yarrow initialized acpi0: VBOX VBOXXSDT on motherboard acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) attimer0: AT timer port 0x40-0x43,0x50-0x53 on acpi0 Timecounter i8254 frequency 1193182 Hz quality 0 Event timer i8254 frequency 1193182 Hz quality 100 Timecounter ACPI-fast frequency 3579545 Hz quality 900 acpi_timer0: 32-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci_link2: BIOS IRQ 9 for 0.7.INTA does not match previous BIOS IRQ 10 pci0: ACPI PCI bus on pcib0 isab0: PCI-ISA bridge at device 1.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 UDMA33 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xd000-0xd00f at device 1.1 on pci0 ata0: ATA channel at channel 0 on atapci0 ata1: ATA channel at channel 1 on atapci0 vgapci0: VGA-compatible display mem 0xe000-0xe07f irq 11 at device 2.0 on pci0 em0: Intel(R) PRO/1000 Legacy Network Connection 1.0.6 port 0xd010-0xd017 mem 0xf000-0xf001 irq 10 at device 3.0 on pci0 em0: Ethernet address: 08:00:27:e4:ea:db pci0: base peripheral at device 4.0 (no driver attached) pcm0: Intel ICH (82801AA) port 0xd100-0xd1ff,0xd200-0xd23f irq 5 at device 5.0 on pci0 pcm0: SigmaTel STAC9700/83/84 AC97 Codec ohci0: OHCI (generic) USB controller mem 0xf0804000-0xf0804fff irq 11 at device 6.0 on pci0 usbus0 on ohci0 pci0: bridge at device 7.0 (no driver attached) battery0: ACPI Control Method Battery on acpi0 acpi_acad0: AC Adapter on acpi0 atkbdc0: Keyboard controller (i8042) port 0x60,0x64 irq 1 on acpi0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse Explorer, device ID 4 pmtimer0 on isa0 orm0: ISA Option ROMs at iomem 0xc-0xc7fff,0xe2000-0xe7fff pnpid ORM on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 atrtc0: AT realtime clock at port 0x70 irq 8 on isa0 Event timer RTC frequency 32768 Hz quality 0 ppc0: parallel port not found. Timecounters tick every 10.000 msec pcm0: measured ac97 link rate at 27783 Hz usbus0: 12Mbps Full Speed USB v1.0 ugen0.1: Apple at usbus0 uhub0: Apple OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus0 ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: VBOX HARDDISK 1.0 ATA-6 device ada0: Serial Number VB7ab20517-23848df6 ada0: 33.300MB/s transfers (UDMA2, PIO 65536bytes) ada0: 4096MB (8388608 512 byte sectors: 16H 63S/T 8322C) ada0: Previously was known as ad0 cd0 at ata1 bus 0 scbus1 target 0 lun 0 cd0: VBOX CD-ROM 1.0 Removable CD-ROM SCSI-0 device cd0: Serial Number VB2-01700376 cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: cd present [301071 x 2048 byte records] uhub0: 8 ports with 8 removable, self powered random: unblocking device. Timecounter TSC frequency 1727604551 Hz quality 800 Trying to mount root from cd9660:/dev/iso9660/FREEBSD_INSTALL [ro]... pid 901 (less), uid 0: exited on signal 11 pid 957 (less), uid 0: exited on signal 11 Copyright (c) 1992-2013 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 10.0-BETA2 #0 r257166: Sat Oct 26 21:52:30 UTC 2013 r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC i386 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 CPU: Intel(R) Core(TM) i5-3317U CPU @ 1.70GHz (1637.34-MHz 686-class CPU) Origin = GenuineIntel Id = 0x306a9 Family = 0x6 Model = 0x3a
Re: newcons comming
On Sun, Nov 03, 2013 at 11:16:53PM -0800, Kevin Oberman wrote: |On Thu, Oct 31, 2013 at 2:01 PM, Doug Ambrisko ambri...@ambrisko.com |wrote: | | On Fri, Oct 25, 2013 at 03:18:47PM +0300, Aleksandr Rybalko wrote: | | Hello fellow hackers! | | | | I finally reach the point when I can work with newcons instead of | | syscons on my laptop. Yes, I know it still buggy and have a lot of | | style(9) problems. But we really have to get it into HEAD and 10.0 to | | enable shiny new Xorg features, drivers, etc. | | I built the kernel from: | A A A A base/user/ed/newcons/ | and installed it on my new ThinkPad T530 with Intel graphics chip. | In general it works better since now syspend and resume works with | and without X. A However, as with my prior ThinkPads I need to switch | out of X to suspend and resume. A So I have vidcontrol -s 1 in my | /etc/rc.suspend and vidcontrol -s 9 in /etc/rc.resume. A If I don't | the display ends up corrupted but somewhat working. | | I had to kldload i915kms in /etc/rc.local since having it there at | boot via /boot/loader.conf resulted in the system not booting. A I need | i915kms for X so I don't need to use vesa mode. | | The FreeBSD logo on boot is interesting but I'd prefer seeing | FreeBSD boot messages to see what is happening. A I'm not sure if | there is a flag to disable that since I have played with it much. | | However, on a whole it is much improved since with i915kms and | newcons when in X via vesa I couldn't switch to a non-X display | since it was blank. | |Excellent news. I'm really looking forward to newcons. Guess it's time to |move my T520 to 10-Stable (or Beta) |. |Since I'm not running 10, I may simply be clueless. If so, please ignore |the rest of this. Newcons isn't in 10 yet but in its own branch. |Are you booting directly to X or using startx from the console? In either |case, I think that i915kms should auto-load at the start of X, so you |should not need to pre-load it. I use XDM to start X. Auto load might not quite work for me since I run X in a vimage jail. I find it easier to keep my base system a minimal install to start up a bounch of vimage jails. I have two mains that are FreeBSD -current that I leap frog and then have a couple of -stable release (ie. 9.0 and 9.2 now) that I use to build ports. I nulls mount the /var/db/pkg, /usr/local and /usr/ports of that release between those so my ports tend to be fixed in time. I have some patches to jail to allow any sysctls and to set what the OS reports for uname etc. Then pkg_add, ports builds thinks it is running on that version of FreeBSD (ie. 9.2 release). This makes it easier for me to run -current and let me add things without issue later on trying to add something new. I do have to build modules outside so it is in sync. with my base OS. |Does newcons require VESA? If not, you should be able to remove it from |your kernel to get suspend/resume working from X. As soon as I went to newcons the suspend and resume started to work. I don't have vesa kldload or static in the kernel. I auto switch out of X on suspend and switch back to X on resume to ensure that on resume the X display isn't messed up (lines shifted etc.). If I don't do this then the X gets messed up. I can see stuff working on the LCD it's just messed up. Brightness seems messed up, I patched acpi_video to also set the 2nd LCD (SB.PCI0.PEG.VID.LCD0._BCM) so that works since the keys don't work. However when X comes back from resume or dpms then it is full bridgtness. So I need to figure that out. I also run into the N compatibility issue with the iwn 6205 that Sean did so I #ifdef'ed that out like he did. Now the 6205 works fine. My other laptop with a 5300 didn't have this issue. My only real problem right now is that this new laptop came with a defective key so I'm waiting to get that replaced and then I'll switch to it. Thanks, Doug A. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: (r257598) panic: Assertion tmp-tm_pages_used == 0 failed at /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316
On Mon, Nov 04, 2013 at 10:43:06AM -0600, Bryan Drewery wrote:
On 2013-11-04 10:27, Konstantin Belousov wrote:
On Mon, Nov 04, 2013 at 08:35:17AM -0600, Bryan Drewery wrote:
11.0-CURRENT #87 r257598
During a poudriere build.
It creates a tmpfs, builds a port in a jail using that tmpfs and then
removes the tmpfs and recreate the tmpfs before building the next
port.
panic: Assertion tmp-tm_pages_used == 0 failed at
/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316
cpuid = 9
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe1247ee57a0
kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe1247ee5850
vpanic() at vpanic+0x126/frame 0xfe1247ee5890
kassert_panic() at kassert_panic+0x136/frame 0xfe1247ee5900
tmpfs_unmount() at tmpfs_unmount+0x163/frame 0xfe1247ee5930
dounmount() at dounmount+0x41f/frame 0xfe1247ee59b0
sys_unmount() at sys_unmount+0x356/frame 0xfe1247ee5ae0
amd64_syscall() at amd64_syscall+0x265/frame 0xfe1247ee5bf0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe1247ee5bf0
--- syscall (22, FreeBSD ELF64, sys_unmount), rip = 0x8008a02fa, rsp =
0x7fffd198, rbp = 0x7fffd2b0 ---
Uptime: 44m40s
(kgdb) #0 doadump (textdump=1) at pcpu.h:219
#1 0x808bcf87 in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:447
#2 0x808bd495 in vpanic (fmt=value optimized out,
ap=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:754
#3 0x808bd326 in kassert_panic (fmt=value optimized out)
at /usr/src/sys/kern/kern_shutdown.c:642
#4 0x81e159d3 in tmpfs_unmount (mp=0xf810502cd660,
mntflags=value optimized out)
at /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316
#5 0x8095e1af in dounmount (mp=0xf810502cd660,
flags=134742016,
td=0xf8013d57a490) at /usr/src/sys/kern/vfs_mount.c:1324
#6 0x8095dd66 in sys_unmount (td=0xf8013d57a490,
uap=0xfe1247ee5b80) at /usr/src/sys/kern/vfs_mount.c:1212
#7 0x80cb7d75 in amd64_syscall (td=0xf8013d57a490, traced=0)
at subr_syscall.c:134
#8 0x80c9c90b in Xfast_syscall ()
at /usr/src/sys/amd64/amd64/exception.S:391
#9 0x0008008a02fa in ?? ()
Do you have core ?
I want to see the struct tmpfs_mount content for the tmpfs mount point
which caused the panic.
Yes.
Hopefully this is what you're asking for:
(kgdb) frame
#4 0x81e159d3 in tmpfs_unmount (mp=0xf810502cd660,
mntflags=value optimized out) at
/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316
316 MPASS(tmp-tm_pages_used == 0);
(kgdb) print *mp
$2 = {mnt_mtx = {lock_object = {lo_name = 0x80f11f09 struct
mount mtx, lo_flags = 16973824, lo_data = 0, lo_witness =
0xfe6d3b00}, mtx_lock = 4}, mnt_gen = 1, mnt_list = {tqe_next =
0xf8116be06660, tqe_prev = 0xf81050257688}, mnt_op =
0x81e1b940, mnt_vfc = 0x81e1ba60, mnt_vnodecovered =
0xf8104fb0c3b0,
mnt_syncer = 0x0, mnt_ref = 1, mnt_nvnodelist = {tqh_first = 0x0,
tqh_last = 0xf810502cd6c0}, mnt_nvnodelistsize = 0,
mnt_activevnodelist = {tqh_first = 0x0, tqh_last = 0xf810502cd6d8},
mnt_activevnodelistsize = 0, mnt_writeopcount = 1, mnt_kern_flag =
16777225, mnt_flag = 4096, mnt_opt = 0xf80014424ae0, mnt_optnew =
0x0, mnt_maxsymlinklen = 0,
mnt_stat = {f_version = 537068824, f_type = 135, f_flags = 4096,
f_bsize = 4096, f_iosize = 4096, f_blocks = 17125058, f_bfree =
17049291, f_bavail = 17049291, f_files = 2147483647, f_ffree =
2147473906, f_syncwrites = 0, f_asyncwrites = 0, f_syncreads = 0,
f_asyncreads = 0, f_spare = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, f_namemax =
255, f_owner = 0, f_fsid = {
val = {-2029977679, 135}}, f_charspare = '\0' repeats 79 times,
f_fstypename = tmpfs\000\000\000\000\000\000\000\000\000\000,
f_mntfromname = tmpfs, '\0' repeats 82 times, f_mntonname =
/poudriere/data/build/exp-91amd64-default-xzibition/08/usr/local, '\0'
repeats 23 times}, mnt_cred = 0xf8001418e100, mnt_data =
0xf80fedf75700,
mnt_time = 0, mnt_iosize_max = 65536, mnt_export = 0x0, mnt_label =
0x0, mnt_hashseed = 4132690418, mnt_lockref = 0, mnt_secondary_writes =
0, mnt_secondary_accwrites = 0, mnt_susp_owner = 0x0, mnt_gjprovider =
0x0, mnt_explock = {lock_object = {lo_name = 0x80f11f1a
explock, lo_flags = 108199936, lo_data = 0, lo_witness =
0xfe6eb280},
lk_lock = 1, lk_exslpfail = 0, lk_timo = 0, lk_pri = 96},
mnt_upper_link = {tqe_next = 0x0, tqe_prev = 0x0}, mnt_uppers =
{tqh_first = 0x0, tqh_last = 0xf810502cd980}}
(kgdb) print *(struct tmpfs_mount *)(mp)-mnt_data
$3 = {tm_pages_max = 18446744073709551615, tm_pages_used =
18446744073709551615, tm_root = 0xf8104ff44828, tm_nodes_max =
Re: Using a swap file
On Thu, Oct 31, 2013 at 5:05 AM, Hiroki Sato h...@freebsd.org wrote: Rostislav Krasny rosti@gmail.com wrote in CANt7McGTBwintkopk=hevo5d4bvsyifwl_-q9uzna3pwbmm...@mail.gmail.com: ro But I have no 'late' option in my /etc/fstab: ro ro root@saturn:~ # cat /etc/fstab ro # DeviceMountpointFStypeOptionsDumpPass# ro /dev/ada0s2a/ufsrw11 ro mdnoneswapsw,file=/swapfile00 ro ro Then why 'swapon -a' (without -L) doesn't work? It's either buggy or confusing. After r255265 the option file= implies late. It is because a file-backed swap space likely to be on a mounted filesystem after the swap line. I realized that that assumption was odd and confusing as you pointed out. The user should specify a swap line with file= after the mount entry, and there is no problem with it. I will fix it. Hope to see the fix in the upcoming 10.0 release and in the Handbook. Thank you. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Automated submission of kernel panic reports: sysutils/panicmail
Colin Percival wrote, On 11/04/2013 11:41: After considerable review on freebsd-hackers (thanks dt71 and jilles!) I have now added sysutils/panicmail to the FreeBSD ports tree. The pkesh script is probably still in need of a big review (S00N(TM)...). ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Automated submission of kernel panic reports: sysutils/panicmail
On 11/04/13 10:49, d...@gmx.com wrote: Colin Percival wrote, On 11/04/2013 11:41: After considerable review on freebsd-hackers (thanks dt71 and jilles!) I have now added sysutils/panicmail to the FreeBSD ports tree. The pkesh script is probably still in need of a big review (S00N(TM)...). Go for it! It's a very simple script. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Automated submission of kernel panic reports: sysutils/panicmail
On 11/04/13 04:49, Alfred Perlstein wrote: Colin, have you had a few minutes to check out the crash reporting facilities in FreeNAS? Yes. The reason I ask is that: 1) we would like to share code. 2) we have this running for a few months now and have a huge corpus of information. 3) we are building a nice UI (screenshots attached) over it, we have a couple of thousands of lines of code we can share for this. Once I have a useful number of panics collected, I was hoping to take the best pieces from FreeNAS's processing, from the SoC project, and from the processing I've been doing of automatic panic reports from EC2 instances. We send a minimal set of information: kernel stack trace, ddb buffer and hardware. Just enough to get some very, very handy stuff. I'm currently sending the dump header and what I get from kgdb 'bt'. If I find that I'm missing something important, I can always add it to a new version of the panicmail port. ;-) I can share with you offline the crash server code, it's django and relatively straight forward. I'll come back to you about this once I have some data. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] Kernel-Selection Enhancemnt to Boot Menu
On Nov 2, 2013, at 1:45 AM, Sam Fourman Jr. wrote: On Sat, Nov 2, 2013 at 7:09 AM, Teske, Devin Devin.Teske at fisglobal.com wrote: Hi all, Here's a chance to test out the kernel selection menu enhancements to the boot loader menu before they go into HEAD. Discussion welcome, feedback desired. No recompile needed, just drop the new forth files onto a HEAD or stable/9 box and reboot. -- Cheers, Devin where are the forth files in question? D'Oh! Here they are: http://druidbsd.cvs.sf.net/viewvc/druidbsd/forth_zfs/ Supplied as patches to either stable/9 or head. -- Devin Hmmm. I saw no appreciable changes to behavior when I patched all the files in /boot with these versions. This was on a sparc64 host running 10-BETA3 (compile this morning). Notably, the kernel and modules still loaded before presenting me with the option to tell it which kernel to load: Executing last command: boot /pci@1f,0/pci@1/scsi@8/disk@0,0:a Boot device: /pci@1f,0/pci@1/scsi@8/disk@0,0:a File and args: FreeBSD/sparc64 ZFS boot block Boot path: /pci@1f,0/pci@1/scsi@8/disk@0,0:a Consoles: Open Firmware console \ FreeBSD/sparc64 ZFS enabled bootstrap loader, Revision 1.0 (r...@snap.freebsd.org, Sun Oct 27 07:20:42 UTC 2013) bootpath=zfs:sys/ROOT/default: Loading /boot/defaults/loader.conf /boot/kernel/kernel data=0x8d54c0+0x66180 syms=[0x8+0x954f0+0x8+0x8d7ef] /boot/kernel/zfs.ko text=0x223328 data=0xa4e0+0x17fc0 syms=[0x8+0x197b8+0x8+0x143f8] loading required module 'opensolaris' /boot/kernel/opensolaris.ko text=0x3130 data=0x2c8+0x2030 syms=[0x8+0xd98+0x8+0x929] /boot/kernel/geom_mirror.ko text=0x38430 data=0x5b0+0x20 syms=[0x8+0x16b0+0x8+0x119e] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel] in 9 seconds... -Kurt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: (r257598) panic: Assertion tmp-tm_pages_used == 0 failed at /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316
On 2013-11-04 11:27, Konstantin Belousov wrote:
On Mon, Nov 04, 2013 at 10:43:06AM -0600, Bryan Drewery wrote:
On 2013-11-04 10:27, Konstantin Belousov wrote:
On Mon, Nov 04, 2013 at 08:35:17AM -0600, Bryan Drewery wrote:
11.0-CURRENT #87 r257598
During a poudriere build.
It creates a tmpfs, builds a port in a jail using that tmpfs and then
removes the tmpfs and recreate the tmpfs before building the next
port.
panic: Assertion tmp-tm_pages_used == 0 failed at
/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316
cpuid = 9
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe1247ee57a0
kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe1247ee5850
vpanic() at vpanic+0x126/frame 0xfe1247ee5890
kassert_panic() at kassert_panic+0x136/frame 0xfe1247ee5900
tmpfs_unmount() at tmpfs_unmount+0x163/frame 0xfe1247ee5930
dounmount() at dounmount+0x41f/frame 0xfe1247ee59b0
sys_unmount() at sys_unmount+0x356/frame 0xfe1247ee5ae0
amd64_syscall() at amd64_syscall+0x265/frame 0xfe1247ee5bf0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe1247ee5bf0
--- syscall (22, FreeBSD ELF64, sys_unmount), rip = 0x8008a02fa, rsp =
0x7fffd198, rbp = 0x7fffd2b0 ---
Uptime: 44m40s
(kgdb) #0 doadump (textdump=1) at pcpu.h:219
#1 0x808bcf87 in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:447
#2 0x808bd495 in vpanic (fmt=value optimized out,
ap=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:754
#3 0x808bd326 in kassert_panic (fmt=value optimized out)
at /usr/src/sys/kern/kern_shutdown.c:642
#4 0x81e159d3 in tmpfs_unmount (mp=0xf810502cd660,
mntflags=value optimized out)
at /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316
#5 0x8095e1af in dounmount (mp=0xf810502cd660,
flags=134742016,
td=0xf8013d57a490) at /usr/src/sys/kern/vfs_mount.c:1324
#6 0x8095dd66 in sys_unmount (td=0xf8013d57a490,
uap=0xfe1247ee5b80) at /usr/src/sys/kern/vfs_mount.c:1212
#7 0x80cb7d75 in amd64_syscall (td=0xf8013d57a490, traced=0)
at subr_syscall.c:134
#8 0x80c9c90b in Xfast_syscall ()
at /usr/src/sys/amd64/amd64/exception.S:391
#9 0x0008008a02fa in ?? ()
Do you have core ?
I want to see the struct tmpfs_mount content for the tmpfs mount point
which caused the panic.
Yes.
Hopefully this is what you're asking for:
(kgdb) frame
#4 0x81e159d3 in tmpfs_unmount (mp=0xf810502cd660,
mntflags=value optimized out) at
/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316
316 MPASS(tmp-tm_pages_used == 0);
(kgdb) print *mp
$2 = {mnt_mtx = {lock_object = {lo_name = 0x80f11f09 struct
mount mtx, lo_flags = 16973824, lo_data = 0, lo_witness =
0xfe6d3b00}, mtx_lock = 4}, mnt_gen = 1, mnt_list = {tqe_next
=
0xf8116be06660, tqe_prev = 0xf81050257688}, mnt_op =
0x81e1b940, mnt_vfc = 0x81e1ba60, mnt_vnodecovered =
0xf8104fb0c3b0,
mnt_syncer = 0x0, mnt_ref = 1, mnt_nvnodelist = {tqh_first = 0x0,
tqh_last = 0xf810502cd6c0}, mnt_nvnodelistsize = 0,
mnt_activevnodelist = {tqh_first = 0x0, tqh_last =
0xf810502cd6d8},
mnt_activevnodelistsize = 0, mnt_writeopcount = 1, mnt_kern_flag =
16777225, mnt_flag = 4096, mnt_opt = 0xf80014424ae0, mnt_optnew =
0x0, mnt_maxsymlinklen = 0,
mnt_stat = {f_version = 537068824, f_type = 135, f_flags = 4096,
f_bsize = 4096, f_iosize = 4096, f_blocks = 17125058, f_bfree =
17049291, f_bavail = 17049291, f_files = 2147483647, f_ffree =
2147473906, f_syncwrites = 0, f_asyncwrites = 0, f_syncreads = 0,
f_asyncreads = 0, f_spare = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, f_namemax
=
255, f_owner = 0, f_fsid = {
val = {-2029977679, 135}}, f_charspare = '\0' repeats 79
times,
f_fstypename = tmpfs\000\000\000\000\000\000\000\000\000\000,
f_mntfromname = tmpfs, '\0' repeats 82 times, f_mntonname =
/poudriere/data/build/exp-91amd64-default-xzibition/08/usr/local,
'\0'
repeats 23 times}, mnt_cred = 0xf8001418e100, mnt_data =
0xf80fedf75700,
mnt_time = 0, mnt_iosize_max = 65536, mnt_export = 0x0, mnt_label =
0x0, mnt_hashseed = 4132690418, mnt_lockref = 0, mnt_secondary_writes
=
0, mnt_secondary_accwrites = 0, mnt_susp_owner = 0x0, mnt_gjprovider =
0x0, mnt_explock = {lock_object = {lo_name = 0x80f11f1a
explock, lo_flags = 108199936, lo_data = 0, lo_witness =
0xfe6eb280},
lk_lock = 1, lk_exslpfail = 0, lk_timo = 0, lk_pri = 96},
mnt_upper_link = {tqe_next = 0x0, tqe_prev = 0x0}, mnt_uppers =
{tqh_first = 0x0, tqh_last = 0xf810502cd980}}
(kgdb) print *(struct tmpfs_mount *)(mp)-mnt_data
$3 = {tm_pages_max = 18446744073709551615, tm_pages_used =
18446744073709551615, tm_root = 0xf8104ff44828, tm_nodes_max =
2147483647, tm_ino_unr = 0xf8002fd65080, tm_nodes_inuse = 0,
tm_maxfilesize =
Re: newcons comming
On Mon, Nov 04, 2013 at 10:30:39AM -0500, Ed Maste wrote: | On 4 November 2013 02:16, Kevin Oberman rkober...@gmail.com wrote: | Excellent news. I'm really looking forward to newcons. Guess it's time to | move my T520 to 10-Stable (or Beta) | | I'm running a Newcons kernel on my Thinkpad X220 now and it's working | well, with a few minor quirks. This is with the X-related packages | rebuilt with WITH_NEW_XORG= and WITH_KMS= in /etc/make.conf. | | Are you booting directly to X or using startx from the console? In either | case, I think that i915kms should auto-load at the start of X, so you | should not need to pre-load it. | | I log in and running startx. i915kms does auto-load. | | Does newcons require VESA? If not, you should be able to remove it from | your kernel to get suspend/resume working from X. | | It does not use VESA - it's removed from GENERIC on the newcons | branch. Suspend and resume generally works on my X220 now, from X or | console. There are some outstanding issues, for example the X display | sometimes ends up corrupted after resume; stopping and restarting X | fixes that. Adding vidcontrol -s 1 /dev/ttyv0 to /etc/rc.suspend and vidcontrol -s 9 /dev/ttyv0 to /etc/rc.resume fixed that for me. Doug A. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] Kernel-Selection Enhancemnt to Boot Menu
On Nov 4, 2013, at 2:43 PM, Kurt Lidl wrote: On Nov 2, 2013, at 1:45 AM, Sam Fourman Jr. wrote: On Sat, Nov 2, 2013 at 7:09 AM, Teske, Devin Devin.Teske at fisglobal.com wrote: Hi all, Here's a chance to test out the kernel selection menu enhancements to the boot loader menu before they go into HEAD. Discussion welcome, feedback desired. No recompile needed, just drop the new forth files onto a HEAD or stable/9 box and reboot. -- Cheers, Devin where are the forth files in question? D'Oh! Here they are: http://druidbsd.cvs.sf.net/viewvc/druidbsd/forth_zfs/ Supplied as patches to either stable/9 or head. -- Devin Hmmm. I saw no appreciable changes to behavior when I patched all the files in /boot with these versions. This was on a sparc64 host running 10-BETA3 (compile this morning). Excellent! Thank you for testing. NB: That's what *should* happen on sparc64 since that architecture doesn't actually enable the beastie menu (sad, I know... I wish that the beastie menu was active on all platforms by default). Notably, the kernel and modules still loaded before presenting me with the option to tell it which kernel to load: Executing last command: boot /pci@1f,0/pci@1/scsi@8/disk@0,0:a Boot device: /pci@1f,0/pci@1/scsi@8/disk@0,0:a File and args: FreeBSD/sparc64 ZFS boot block Boot path: /pci@1f,0/pci@1/scsi@8/disk@0,0:a Consoles: Open Firmware console \ FreeBSD/sparc64 ZFS enabled bootstrap loader, Revision 1.0 (r...@snap.freebsd.org, Sun Oct 27 07:20:42 UTC 2013) bootpath=zfs:sys/ROOT/default: Loading /boot/defaults/loader.conf /boot/kernel/kernel data=0x8d54c0+0x66180 syms=[0x8+0x954f0+0x8+0x8d7ef] /boot/kernel/zfs.ko text=0x223328 data=0xa4e0+0x17fc0 syms=[0x8+0x197b8+0x8+0x143f8] loading required module 'opensolaris' /boot/kernel/opensolaris.ko text=0x3130 data=0x2c8+0x2030 syms=[0x8+0xd98+0x8+0x929] /boot/kernel/geom_mirror.ko text=0x38430 data=0x5b0+0x20 syms=[0x8+0x16b0+0x8+0x119e] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel] in 9 seconds... You can try enabling the beastie menu on sparc64 by editing /boot/loader.rc: === Change #1 in /boot/loader.rc to enable beastie menu === Find: \ Reads and processes loader.conf variables \ NOTE: Change to `initialize' if you enable the below boot menu start Change start to initialize as shown below: \ Reads and processes loader.conf variables \ NOTE: Change to `initialize' if you enable the below boot menu initialize === Change #2 in [same file] to enable beastie menu === Find: \ Uncomment to enable boot menu \ include /boot/beastie.4th \ beastie-start Uncomment beastie-start as shown below: \ Uncomment to enable boot menu \ include /boot/beastie.4th beastie-start == If you find that making those two trivial changes, that you are able to load the menu... then maybe it's time for us to start thinking about enabling the beastie menu by-default for the sparc64 architecture. Does anybody else have any thoughts on enabling it for sparc64? -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. signature.asc Description: Message signed with OpenPGP using GPGMail
CUURENT kernel build broken - make[2]: exec(aicasm) failed (No such file or directory)
cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/dev/ath -I/usr/src/sys/dev/ath/ath_hal -I/usr/src/sys/contrib/dev/ath/ath_hal -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -I/usr/src/sys/dev/cxgb -I/usr/src/sys/dev/cxgbe -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector /usr/src/sys/amd64/amd64/genassym.c NM='nm' sh /usr/src/sys/kern/genassym.sh genassym.o assym.s awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -p awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -q awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -h awk -f /usr/src/sys/tools/acpi_quirks2h.awk /usr/src/sys/dev/acpica/acpi_quirks aicasm -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/dev/ath -I/usr/src/sys/dev/ath/ath_hal -I/usr/src/sys/contrib/dev/ath/ath_hal -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -I/usr/src/sys/dev/cxgb -I/usr/src/sys/dev/cxgbe -I/usr/src/sys/contrib/libfdt -I/usr/src/sys/cam/scsi -I/usr/src/sys/dev/aic7xxx -o aic7xxx_seq.h -r aic7xxx_reg.h -p aic7xxx_reg_print.c -i /usr/src/sys/dev/aic7xxx/aic7xxx_osm.h /usr/src/sys/dev/aic7xxx/aic7xxx.seq make[2]: exec(aicasm) failed (No such file or directory) *** Error code 1 Stop. make[2]: stopped in /usr/obj/usr/src/sys/GENERIC *** Error code 1 Stop. make[1]: stopped in /usr/src ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CUURENT kernel build broken - make[2]: exec(aicasm) failed (No such file or directory)
On Mon, 2013-11-04 at 19:25 -0500, Outback Dingo wrote: cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/dev/ath -I/usr/src/sys/dev/ath/ath_hal -I/usr/src/sys/contrib/dev/ath/ath_hal -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -I/usr/src/sys/dev/cxgb -I/usr/src/sys/dev/cxgbe -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector /usr/src/sys/amd64/amd64/genassym.c NM='nm' sh /usr/src/sys/kern/genassym.sh genassym.o assym.s awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -p awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -q awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -h awk -f /usr/src/sys/tools/acpi_quirks2h.awk /usr/src/sys/dev/acpica/acpi_quirks aicasm -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/dev/ath -I/usr/src/sys/dev/ath/ath_hal -I/usr/src/sys/contrib/dev/ath/ath_hal -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -I/usr/src/sys/dev/cxgb -I/usr/src/sys/dev/cxgbe -I/usr/src/sys/contrib/libfdt -I/usr/src/sys/cam/scsi -I/usr/src/sys/dev/aic7xxx -o aic7xxx_seq.h -r aic7xxx_reg.h -p aic7xxx_reg_print.c -i /usr/src/sys/dev/aic7xxx/aic7xxx_osm.h /usr/src/sys/dev/aic7xxx/aic7xxx.seq make[2]: exec(aicasm) failed (No such file or directory) *** Error code 1 Stop. make[2]: stopped in /usr/obj/usr/src/sys/GENERIC *** Error code 1 Stop. make[1]: stopped in /usr/src Did you update your source and then make buildkernel without buildworld? If so, a make kernel-toolchain should create the aicasm tool and get you back on track. -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CUURENT kernel build broken - make[2]: exec(aicasm) failed (No such file or directory)
On Mon, Nov 4, 2013 at 7:36 PM, Ian Lepore i...@freebsd.org wrote: On Mon, 2013-11-04 at 19:25 -0500, Outback Dingo wrote: cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/dev/ath -I/usr/src/sys/dev/ath/ath_hal -I/usr/src/sys/contrib/dev/ath/ath_hal -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -I/usr/src/sys/dev/cxgb -I/usr/src/sys/dev/cxgbe -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector /usr/src/sys/amd64/amd64/genassym.c NM='nm' sh /usr/src/sys/kern/genassym.sh genassym.o assym.s awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -p awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -q awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -h awk -f /usr/src/sys/tools/acpi_quirks2h.awk /usr/src/sys/dev/acpica/acpi_quirks aicasm -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/dev/ath -I/usr/src/sys/dev/ath/ath_hal -I/usr/src/sys/contrib/dev/ath/ath_hal -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -I/usr/src/sys/dev/cxgb -I/usr/src/sys/dev/cxgbe -I/usr/src/sys/contrib/libfdt -I/usr/src/sys/cam/scsi -I/usr/src/sys/dev/aic7xxx -o aic7xxx_seq.h -r aic7xxx_reg.h -p aic7xxx_reg_print.c -i /usr/src/sys/dev/aic7xxx/aic7xxx_osm.h /usr/src/sys/dev/aic7xxx/aic7xxx.seq make[2]: exec(aicasm) failed (No such file or directory) *** Error code 1 Stop. make[2]: stopped in /usr/obj/usr/src/sys/GENERIC *** Error code 1 Stop. make[1]: stopped in /usr/src Did you update your source and then make buildkernel without buildworld? If so, a make kernel-toolchain should create the aicasm tool and get you back on track. really odd as i built a kernel this morning no problem, then updated the tree and went to build another kernel and got that. working through it, thanks for the input.. -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Automated submission of kernel panic reports: sysutils/panicmail
Hi all, After considerable review on freebsd-hackers (thanks dt71 and jilles!) I have now added sysutils/panicmail to the FreeBSD ports tree. If you install this and add panicmail_enable=YES to your /etc/rc.conf, a panic report will be generated and sent to root@ for you to review and submit (via email). You can skip the reviewing step and submit panics automatically by setting panicmail_autosubmit=YES. The panics submitted are encrypted to an RSA key which I hold in order to keep them secure in transit; and I intend to keep the raw panic reports confidential except to the minimum extent necessary for other developers to help me process the incoming reports. If I receive enough panic reports to be useful, I hope to provide developers with aggregate statistics. This may include: * regular email reports listing the top panics, to help guide developers towards the most fertile areas for stability improvements; * email to specific developers alerting them to recurring panics in code they maintain (especially if it becomes clear that the panic has been recently introduced); and * guidance to re@ and secteam@ about how often a particular panic occurs if an errata notice is being considered as well as other yet-to-be-imagined reports of a similarly aggregate and anonymized nature. So please install the sysutils/panicmail port and enable it in rc.conf! This all depends on getting useful data, and I can't do that without your help. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid Question that arises is how does the system know where to send the email, and through what SMTP server, especially if panicmail_autosubmit=YES. In the case of a kernel panic, wouldn't the system crash/freeze, and would it then be able to compose an email message? I use mail/mpop and mail/msmtp rather than messing with sendmail or postfix; have multiple email accounts and inboxes. Now come to think of it, I don't think I ever sent an email from FreeBSD as root, only as nonroot. Something like panicmail ought to be ported to NetBSD pkgsrc, considering that NetBSD seems so much more unstable and crash-prone than FreeBSD on my hardware. Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Automated submission of kernel panic reports: sysutils/panicmail
On Mon, Nov 4, 2013, at 20:26, Thomas Mueller wrote: Hi all, After considerable review on freebsd-hackers (thanks dt71 and jilles!) I have now added sysutils/panicmail to the FreeBSD ports tree. If you install this and add panicmail_enable=YES to your /etc/rc.conf, a panic report will be generated and sent to root@ for you to review and submit (via email). You can skip the reviewing step and submit panics automatically by setting panicmail_autosubmit=YES. The panics submitted are encrypted to an RSA key which I hold in order to keep them secure in transit; and I intend to keep the raw panic reports confidential except to the minimum extent necessary for other developers to help me process the incoming reports. If I receive enough panic reports to be useful, I hope to provide developers with aggregate statistics. This may include: * regular email reports listing the top panics, to help guide developers towards the most fertile areas for stability improvements; * email to specific developers alerting them to recurring panics in code they maintain (especially if it becomes clear that the panic has been recently introduced); and * guidance to re@ and secteam@ about how often a particular panic occurs if an errata notice is being considered as well as other yet-to-be-imagined reports of a similarly aggregate and anonymized nature. So please install the sysutils/panicmail port and enable it in rc.conf! This all depends on getting useful data, and I can't do that without your help. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid Question that arises is how does the system know where to send the email, and through what SMTP server, especially if panicmail_autosubmit=YES. Every computer on the planet has the capability of being able to send email directly without an SMTP server. The only question is if the receiving end is willing to accept it, or discard it as spam. In the case of a kernel panic, wouldn't the system crash/freeze, and would it then be able to compose an email message? This is all handled on the next boot after the panic. I use mail/mpop and mail/msmtp rather than messing with sendmail or postfix; have multiple email accounts and inboxes. Does it provide a compatible /usr/sbin/sendmail binary? If so, it will just work^TM. Now come to think of it, I don't think I ever sent an email from FreeBSD as root, only as nonroot. Something like panicmail ought to be ported to NetBSD pkgsrc, considering that NetBSD seems so much more unstable and crash-prone than FreeBSD on my hardware. I hope more projects pick this up too. :-) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Automated submission of kernel panic reports: sysutils/panicmail
On 11/04/13 18:26, Thomas Mueller wrote: Question that arises is how does the system know where to send the email, and through what SMTP server, especially if panicmail_autosubmit=YES. The code assumes that your system knows how to deliver email. An out-of-the-box FreeBSD install has sendmail and can do this. If you don't enable panicmail_autosubmit then it also assumes you're reading or forwarding root's email -- which you should be doing anyway. In the case of a kernel panic, wouldn't the system crash/freeze, and would it then be able to compose an email message? The email is generated from the crashdump when the system next boots. I use mail/mpop and mail/msmtp rather than messing with sendmail or postfix; have multiple email accounts and inboxes. Now come to think of it, I don't think I ever sent an email from FreeBSD as root, only as nonroot. Don't you get daily run output and security run output emails? Something like panicmail ought to be ported to NetBSD pkgsrc, considering that NetBSD seems so much more unstable and crash-prone than FreeBSD on my hardware. Go right ahead. It's a small shell script -- might even work fine without any changes. It's BSD licensed, of course. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on ia64/ia64
TB --- 2013-11-05 03:34:27 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-05 03:34:27 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-05 03:34:27 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-11-05 03:34:27 - cleaning the object tree TB --- 2013-11-05 03:34:27 - /usr/local/bin/svn stat /src TB --- 2013-11-05 03:34:31 - At svn revision 257658 TB --- 2013-11-05 03:34:32 - building world TB --- 2013-11-05 03:34:32 - CROSS_BUILD_TESTING=YES TB --- 2013-11-05 03:34:32 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-05 03:34:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-05 03:34:32 - SRCCONF=/dev/null TB --- 2013-11-05 03:34:32 - TARGET=ia64 TB --- 2013-11-05 03:34:32 - TARGET_ARCH=ia64 TB --- 2013-11-05 03:34:32 - TZ=UTC TB --- 2013-11-05 03:34:32 - __MAKE_CONF=/dev/null TB --- 2013-11-05 03:34:32 - cd /src TB --- 2013-11-05 03:34:32 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Tue Nov 5 03:34:39 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] LC_ALL=C awk -f /src/gnu/lib/libgcc/../../../contrib/gcc/opt-gather.awk /src/gnu/lib/libgcc/../../../contrib/gcc/c.opt /src/gnu/lib/libgcc/../../../contrib/gcc/common.opt /src/gnu/lib/libgcc/../../../contrib/gcc/config/ia64/ia64.opt optionlist LC_ALL=C awk -f /src/gnu/lib/libgcc/../../../contrib/gcc/opt-functions.awk -f /src/gnu/lib/libgcc/../../../contrib/gcc/opth-gen.awk optionlist options.h /obj/src/make.amd64/bmake -f /src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/src/gnu/lib/libgcc/../../../contrib/gcc unwind.h ln -sf /src/gnu/lib/libgcc/../../../contrib/gcc/unwind-generic.h unwind.h /obj/src/make.amd64/bmake -f /src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/src/gnu/lib/libgcc/../../../contrib/gcc gthr-default.h ln -sf /src/gnu/lib/libgcc/../../../contrib/gcc/gthr-posix.h gthr-default.h cc -c -O2 -pipe -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DHAVE_GTHR_DEFAULT -I/src/gnu/lib/libgcc/../../../contrib/gcclibs/include -I/src/gnu/lib/libgcc/../../../contrib/gcc/config -I/src/gnu/lib/libgcc/../../../contrib/gcc -I. -I/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -Wno-static-in-inline -std=gnu99 -fvisibility=hidden -DHIDE_EXPORTS -fPIC -fexceptions -D__GLIBC__=3 -DElfW=__ElfN -o unwind-ia64.o /src/gnu/lib/libgcc/../../../contrib/gcc/config/ia64/unwind-ia64.c cc1: error: unrecognized command line option -Wno-static-in-inline *** Error code 1 Stop. bmake[3]: stopped in /src/gnu/lib/libgcc *** Error code 1 Stop. bmake[2]: stopped in /src *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-05 03:44:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-05 03:44:09 - ERROR: failed to build world TB --- 2013-11-05 03:44:09 - 452.38 user 67.11 system 581.46 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-ia64-ia64.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on mips/mips
TB --- 2013-11-05 03:44:09 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-05 03:44:09 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-05 03:44:09 - starting HEAD tinderbox run for mips/mips TB --- 2013-11-05 03:44:09 - cleaning the object tree TB --- 2013-11-05 03:44:09 - /usr/local/bin/svn stat /src TB --- 2013-11-05 03:44:12 - At svn revision 257658 TB --- 2013-11-05 03:44:13 - building world TB --- 2013-11-05 03:44:13 - CROSS_BUILD_TESTING=YES TB --- 2013-11-05 03:44:13 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-05 03:44:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-05 03:44:13 - SRCCONF=/dev/null TB --- 2013-11-05 03:44:13 - TARGET=mips TB --- 2013-11-05 03:44:13 - TARGET_ARCH=mips TB --- 2013-11-05 03:44:13 - TZ=UTC TB --- 2013-11-05 03:44:13 - __MAKE_CONF=/dev/null TB --- 2013-11-05 03:44:13 - cd /src TB --- 2013-11-05 03:44:13 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Tue Nov 5 03:44:21 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] LC_ALL=C awk -f /src/gnu/lib/libgcc/../../../contrib/gcc/opt-gather.awk /src/gnu/lib/libgcc/../../../contrib/gcc/c.opt /src/gnu/lib/libgcc/../../../contrib/gcc/common.opt /src/gnu/lib/libgcc/../../../contrib/gcc/config/mips/mips.opt optionlist LC_ALL=C awk -f /src/gnu/lib/libgcc/../../../contrib/gcc/opt-functions.awk -f /src/gnu/lib/libgcc/../../../contrib/gcc/opth-gen.awk optionlist options.h /obj/src/make.amd64/bmake -f /src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/src/gnu/lib/libgcc/../../../contrib/gcc unwind.h ln -sf /src/gnu/lib/libgcc/../../../contrib/gcc/unwind-generic.h unwind.h /obj/src/make.amd64/bmake -f /src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/src/gnu/lib/libgcc/../../../contrib/gcc gthr-default.h ln -sf /src/gnu/lib/libgcc/../../../contrib/gcc/gthr-posix.h gthr-default.h cc -c -O -pipe -G0 -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DHAVE_GTHR_DEFAULT -I/src/gnu/lib/libgcc/../../../contrib/gcclibs/include -I/src/gnu/lib/libgcc/../../../contrib/gcc/config -I/src/gnu/lib/libgcc/../../../contrib/gcc -I. -I/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -Wno-static-in-inline -std=gnu99 -fvisibility=hidden -DHIDE_EXPORTS -fPIC -fexceptions -D__GLIBC__=3 -DElfW=__ElfN -o unwind-dw2.o /src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c cc1: error: unrecognized command line option -Wno-static-in-inline *** Error code 1 Stop. bmake[3]: stopped in /src/gnu/lib/libgcc *** Error code 1 Stop. bmake[2]: stopped in /src *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-05 03:53:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-05 03:53:33 - ERROR: failed to build world TB --- 2013-11-05 03:53:33 - 446.05 user 70.59 system 564.05 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips-mips.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on mips64/mips
TB --- 2013-11-05 03:53:33 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-05 03:53:33 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-05 03:53:33 - starting HEAD tinderbox run for mips64/mips TB --- 2013-11-05 03:53:34 - cleaning the object tree TB --- 2013-11-05 03:53:34 - /usr/local/bin/svn stat /src TB --- 2013-11-05 03:53:37 - At svn revision 257658 TB --- 2013-11-05 03:53:38 - building world TB --- 2013-11-05 03:53:38 - CROSS_BUILD_TESTING=YES TB --- 2013-11-05 03:53:38 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-05 03:53:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-05 03:53:38 - SRCCONF=/dev/null TB --- 2013-11-05 03:53:38 - TARGET=mips TB --- 2013-11-05 03:53:38 - TARGET_ARCH=mips64 TB --- 2013-11-05 03:53:38 - TZ=UTC TB --- 2013-11-05 03:53:38 - __MAKE_CONF=/dev/null TB --- 2013-11-05 03:53:38 - cd /src TB --- 2013-11-05 03:53:38 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Tue Nov 5 03:53:45 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] LC_ALL=C awk -f /src/gnu/lib/libgcc/../../../contrib/gcc/opt-gather.awk /src/gnu/lib/libgcc/../../../contrib/gcc/c.opt /src/gnu/lib/libgcc/../../../contrib/gcc/common.opt /src/gnu/lib/libgcc/../../../contrib/gcc/config/mips/mips.opt optionlist LC_ALL=C awk -f /src/gnu/lib/libgcc/../../../contrib/gcc/opt-functions.awk -f /src/gnu/lib/libgcc/../../../contrib/gcc/opth-gen.awk optionlist options.h /obj/src/make.amd64/bmake -f /src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/src/gnu/lib/libgcc/../../../contrib/gcc unwind.h ln -sf /src/gnu/lib/libgcc/../../../contrib/gcc/unwind-generic.h unwind.h /obj/src/make.amd64/bmake -f /src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/src/gnu/lib/libgcc/../../../contrib/gcc gthr-default.h ln -sf /src/gnu/lib/libgcc/../../../contrib/gcc/gthr-posix.h gthr-default.h cc -c -O -pipe -G0 -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DHAVE_GTHR_DEFAULT -I/src/gnu/lib/libgcc/../../../contrib/gcclibs/include -I/src/gnu/lib/libgcc/../../../contrib/gcc/config -I/src/gnu/lib/libgcc/../../../contrib/gcc -I. -I/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -Wno-static-in-inline -std=gnu99 -fvisibility=hidden -DHIDE_EXPORTS -fPIC -fexceptions -D__GLIBC__=3 -DElfW=__ElfN -o unwind-dw2.o /src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c cc1: error: unrecognized command line option -Wno-static-in-inline *** Error code 1 Stop. bmake[3]: stopped in /src/gnu/lib/libgcc *** Error code 1 Stop. bmake[2]: stopped in /src *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-05 04:03:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-05 04:03:08 - ERROR: failed to build world TB --- 2013-11-05 04:03:08 - 447.70 user 85.58 system 574.20 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips64-mips.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on powerpc/powerpc
TB --- 2013-11-05 04:03:08 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-05 04:03:08 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-05 04:03:08 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-11-05 04:03:08 - cleaning the object tree TB --- 2013-11-05 04:03:08 - /usr/local/bin/svn stat /src TB --- 2013-11-05 04:03:11 - At svn revision 257658 TB --- 2013-11-05 04:03:12 - building world TB --- 2013-11-05 04:03:12 - CROSS_BUILD_TESTING=YES TB --- 2013-11-05 04:03:12 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-05 04:03:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-05 04:03:12 - SRCCONF=/dev/null TB --- 2013-11-05 04:03:12 - TARGET=powerpc TB --- 2013-11-05 04:03:12 - TARGET_ARCH=powerpc TB --- 2013-11-05 04:03:12 - TZ=UTC TB --- 2013-11-05 04:03:12 - __MAKE_CONF=/dev/null TB --- 2013-11-05 04:03:12 - cd /src TB --- 2013-11-05 04:03:12 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Tue Nov 5 04:03:19 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] LC_ALL=C awk -f /src/gnu/lib/libgcc/../../../contrib/gcc/opt-gather.awk /src/gnu/lib/libgcc/../../../contrib/gcc/c.opt /src/gnu/lib/libgcc/../../../contrib/gcc/common.opt /src/gnu/lib/libgcc/../../../contrib/gcc/config/rs6000/rs6000.opt /src/gnu/lib/libgcc/../../../contrib/gcc/config/rs6000/sysv4.opt optionlist LC_ALL=C awk -f /src/gnu/lib/libgcc/../../../contrib/gcc/opt-functions.awk -f /src/gnu/lib/libgcc/../../../contrib/gcc/opth-gen.awk optionlist options.h /obj/src/make.amd64/bmake -f /src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/src/gnu/lib/libgcc/../../../contrib/gcc unwind.h ln -sf /src/gnu/lib/libgcc/../../../contrib/gcc/unwind-generic.h unwind.h /obj/src/make.amd64/bmake -f /src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/src/gnu/lib/libgcc/../../../contrib/gcc gthr-default.h ln -sf /src/gnu/lib/libgcc/../../../contrib/gcc/gthr-posix.h gthr-default.h cc -c -O2 -pipe -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DHAVE_GTHR_DEFAULT -I/src/gnu/lib/libgcc/../../../contrib/gcclibs/include -I/src/gnu/lib/libgcc/../../../contrib/gcc/config -I/src/gnu/lib/libgcc/../../../contrib/gcc -I. -I/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -Wno-static-in-inline -std=gnu99 -fvisibility=hidden -DHIDE_EXPORTS -fPIC -fexceptions -D__GLIBC__=3 -DElfW=__ElfN -o unwind-dw2.o /src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c cc1: error: unrecognized command line option -Wno-static-in-inline *** Error code 1 Stop. bmake[3]: stopped in /src/gnu/lib/libgcc *** Error code 1 Stop. bmake[2]: stopped in /src *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-05 04:16:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-05 04:16:20 - ERROR: failed to build world TB --- 2013-11-05 04:16:20 - 644.41 user 88.50 system 792.07 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc-powerpc.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on powerpc64/powerpc
TB --- 2013-11-05 04:16:20 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-05 04:16:20 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-05 04:16:20 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2013-11-05 04:16:20 - cleaning the object tree TB --- 2013-11-05 04:16:20 - /usr/local/bin/svn stat /src TB --- 2013-11-05 04:16:24 - At svn revision 257658 TB --- 2013-11-05 04:16:25 - building world TB --- 2013-11-05 04:16:25 - CROSS_BUILD_TESTING=YES TB --- 2013-11-05 04:16:25 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-05 04:16:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-05 04:16:25 - SRCCONF=/dev/null TB --- 2013-11-05 04:16:25 - TARGET=powerpc TB --- 2013-11-05 04:16:25 - TARGET_ARCH=powerpc64 TB --- 2013-11-05 04:16:25 - TZ=UTC TB --- 2013-11-05 04:16:25 - __MAKE_CONF=/dev/null TB --- 2013-11-05 04:16:25 - cd /src TB --- 2013-11-05 04:16:25 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Tue Nov 5 04:16:32 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] LC_ALL=C awk -f /src/gnu/lib/libgcc/../../../contrib/gcc/opt-gather.awk /src/gnu/lib/libgcc/../../../contrib/gcc/c.opt /src/gnu/lib/libgcc/../../../contrib/gcc/common.opt /src/gnu/lib/libgcc/../../../contrib/gcc/config/rs6000/rs6000.opt /src/gnu/lib/libgcc/../../../contrib/gcc/config/rs6000/sysv4.opt optionlist LC_ALL=C awk -f /src/gnu/lib/libgcc/../../../contrib/gcc/opt-functions.awk -f /src/gnu/lib/libgcc/../../../contrib/gcc/opth-gen.awk optionlist options.h /obj/src/make.amd64/bmake -f /src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/src/gnu/lib/libgcc/../../../contrib/gcc unwind.h ln -sf /src/gnu/lib/libgcc/../../../contrib/gcc/unwind-generic.h unwind.h /obj/src/make.amd64/bmake -f /src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/src/gnu/lib/libgcc/../../../contrib/gcc gthr-default.h ln -sf /src/gnu/lib/libgcc/../../../contrib/gcc/gthr-posix.h gthr-default.h cc -c -O2 -pipe -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DHAVE_GTHR_DEFAULT -I/src/gnu/lib/libgcc/../../../contrib/gcclibs/include -I/src/gnu/lib/libgcc/../../../contrib/gcc/config -I/src/gnu/lib/libgcc/../../../contrib/gcc -I. -I/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -Wno-static-in-inline -std=gnu99 -fvisibility=hidden -DHIDE_EXPORTS -fPIC -fexceptions -D__GLIBC__=3 -DElfW=__ElfN -o unwind-dw2.o /src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c cc1: error: unrecognized command line option -Wno-static-in-inline *** Error code 1 Stop. bmake[3]: stopped in /src/gnu/lib/libgcc *** Error code 1 Stop. bmake[2]: stopped in /src *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-05 04:30:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-05 04:30:28 - ERROR: failed to build world TB --- 2013-11-05 04:30:28 - 656.49 user 132.34 system 847.99 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-powerpc64-powerpc.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on sparc64/sparc64
TB --- 2013-11-05 04:30:28 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-11-05 04:30:28 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-05 04:30:28 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-11-05 04:30:28 - cleaning the object tree TB --- 2013-11-05 04:30:28 - /usr/local/bin/svn stat /src TB --- 2013-11-05 04:30:32 - At svn revision 257658 TB --- 2013-11-05 04:30:33 - building world TB --- 2013-11-05 04:30:33 - CROSS_BUILD_TESTING=YES TB --- 2013-11-05 04:30:33 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-05 04:30:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-05 04:30:33 - SRCCONF=/dev/null TB --- 2013-11-05 04:30:33 - TARGET=sparc64 TB --- 2013-11-05 04:30:33 - TARGET_ARCH=sparc64 TB --- 2013-11-05 04:30:33 - TZ=UTC TB --- 2013-11-05 04:30:33 - __MAKE_CONF=/dev/null TB --- 2013-11-05 04:30:33 - cd /src TB --- 2013-11-05 04:30:33 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Tue Nov 5 04:30:40 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] LC_ALL=C awk -f /src/gnu/lib/libgcc/../../../contrib/gcc/opt-gather.awk /src/gnu/lib/libgcc/../../../contrib/gcc/c.opt /src/gnu/lib/libgcc/../../../contrib/gcc/common.opt /src/gnu/lib/libgcc/../../../contrib/gcc/config/sparc/sparc.opt /src/gnu/lib/libgcc/../../../contrib/gcc/config/sparc/long-double-switch.opt optionlist LC_ALL=C awk -f /src/gnu/lib/libgcc/../../../contrib/gcc/opt-functions.awk -f /src/gnu/lib/libgcc/../../../contrib/gcc/opth-gen.awk optionlist options.h /obj/src/make.amd64/bmake -f /src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/src/gnu/lib/libgcc/../../../contrib/gcc unwind.h ln -sf /src/gnu/lib/libgcc/../../../contrib/gcc/unwind-generic.h unwind.h /obj/src/make.amd64/bmake -f /src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile MFILE=/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/src/gnu/lib/libgcc/../../../contrib/gcc gthr-default.h ln -sf /src/gnu/lib/libgcc/../../../contrib/gcc/gthr-posix.h gthr-default.h cc -c -O2 -pipe -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DHAVE_GTHR_DEFAULT -I/src/gnu/lib/libgcc/../../../contrib/gcclibs/include -I/src/gnu/lib/libgcc/../../../contrib/gcc/config -I/src/gnu/lib/libgcc/../../../contrib/gcc -I. -I/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -Wno-static-in-inline -std=gnu99 -fvisibility=hidden -DHIDE_EXPORTS -fPIC -fexceptions -D__GLIBC__=3 -DElfW=__ElfN -o unwind-dw2.o /src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c cc1: error: unrecognized command line option -Wno-static-in-inline *** Error code 1 Stop. bmake[3]: stopped in /src/gnu/lib/libgcc *** Error code 1 Stop. bmake[2]: stopped in /src *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-11-05 04:40:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-11-05 04:40:09 - ERROR: failed to build world TB --- 2013-11-05 04:40:09 - 410.42 user 96.27 system 580.73 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-sparc64-sparc64.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CUURENT kernel build broken - make[2]: exec(aicasm) failed (No such file or directory)
On Mon, 2013-11-04 at 19:44 -0500, Outback Dingo wrote: On Mon, Nov 4, 2013 at 7:36 PM, Ian Lepore i...@freebsd.org wrote: On Mon, 2013-11-04 at 19:25 -0500, Outback Dingo wrote: cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/dev/ath -I/usr/src/sys/dev/ath/ath_hal -I/usr/src/sys/contrib/dev/ath/ath_hal -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -I/usr/src/sys/dev/cxgb -I/usr/src/sys/dev/cxgbe -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector /usr/src/sys/amd64/amd64/genassym.c NM='nm' sh /usr/src/sys/kern/genassym.sh genassym.o assym.s awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -p awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -q awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -h awk -f /usr/src/sys/tools/acpi_quirks2h.awk /usr/src/sys/dev/acpica/acpi_quirks aicasm -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/dev/ath -I/usr/src/sys/dev/ath/ath_hal -I/usr/src/sys/contrib/dev/ath/ath_hal -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -I/usr/src/sys/dev/cxgb -I/usr/src/sys/dev/cxgbe -I/usr/src/sys/contrib/libfdt -I/usr/src/sys/cam/scsi -I/usr/src/sys/dev/aic7xxx -o aic7xxx_seq.h -r aic7xxx_reg.h -p aic7xxx_reg_print.c -i /usr/src/sys/dev/aic7xxx/aic7xxx_osm.h /usr/src/sys/dev/aic7xxx/aic7xxx.seq make[2]: exec(aicasm) failed (No such file or directory) *** Error code 1 Stop. make[2]: stopped in /usr/obj/usr/src/sys/GENERIC *** Error code 1 Stop. make[1]: stopped in /usr/src Did you update your source and then make buildkernel without buildworld? If so, a make kernel-toolchain should create the aicasm tool and get you back on track. really odd as i built a kernel this morning no problem, then updated the tree and went to build another kernel and got that. working through it, thanks for the input.. You were just unlucky that your updates bracketed my checkin that changed the build process for the aicasm tool so that it gets built as part of the toolchain rather than as part of the kernel now. -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CUURENT kernel build broken - make[2]: exec(aicasm) failed (No such file or directory)
On Mon, Nov 04, 2013 at 10:09:54PM -0700, Ian Lepore wrote: I /usr/src/sys/dev/aic7xxx/aic7xxx.seq Imake[2]: exec(aicasm) failed (No such file or directory) I*** Error code 1 I IStop. Imake[2]: stopped in /usr/obj/usr/src/sys/GENERIC I*** Error code 1 I IStop. Imake[1]: stopped in /usr/src I I Did you update your source and then make buildkernel without I buildworld? If so, a make kernel-toolchain should create the aicasm I tool and get you back on track. I I I really odd as i built a kernel this morning no problem, then updated the I tree and went to build another kernel and got that. I working through it, thanks for the input.. I I I You were just unlucky that your updates bracketed my checkin that I changed the build process for the aicasm tool so that it gets built as I part of the toolchain rather than as part of the kernel now. Before this change, the toolchain was not required for kernel build if you aren't cross building. And now it is. This breaks the kernel build procedure documented in handbook for years, and brings a lot of discomfort to developers. Now to test a trivial change to kernel I need first to compile clang. -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 10.0-BETA1 i386 on VirtualBox
On Mon, Nov 04, 2013 at 08:53:41PM +0400, Gleb Smirnoff wrote: On Mon, Nov 04, 2013 at 06:38:25PM +0200, Konstantin Belousov wrote: K Also please show me the CPU features banner from the boot in the VB, K like this: I have already collected them all. See attaches. Legend: dmesg.bb pwd_mkdb crashes during install dmesg.milu.pngpwd_mkdb crashes during install dmesg.think installation succeeds, but world build crashes instantly dmesg.ru all works dmesg.morannonall works First, all reported instances have ata attachment for the ada0, except of milu (possibly). So this means that kernel does transient remapping, and very different code path is executed comparing with what I thought initially. The path is simpler than the pure unmapped i/o. Second, I use QEMU with the ata0 attachment for the disks regularly, and I do not have an issue. I also did not see a report from the real h/w. Third point is that all reports are i386. Is there anybody with amd64, vbox, ata and the same corruption hiddent by disabling unmapped i/o ? In what way the non-working images were installed ? Is it possible to produce the problematic installs by doing it one way, and non-problematic by another ? pgpqGG70LZE0H.pgp Description: PGP signature
Re: 10.0-BETA1 i386 on VirtualBox
On Tue, Nov 05, 2013 at 09:02:22AM +0200, Konstantin Belousov wrote: K First, all reported instances have ata attachment for the ada0, except K of milu (possibly). So this means that kernel does transient remapping, K and very different code path is executed comparing with what I thought K initially. The path is simpler than the pure unmapped i/o. K K Second, I use QEMU with the ata0 attachment for the disks regularly, and K I do not have an issue. I also did not see a report from the real h/w. K K Third point is that all reports are i386. Is there anybody with amd64, K vbox, ata and the same corruption hiddent by disabling unmapped i/o ? K K In what way the non-working images were installed ? Is it possible to K produce the problematic installs by doing it one way, and non-problematic K by another ? The only known way to get FreeBSD working is to turn off unmapped io in loader. Any tweaking of hardware in VB or changes in the install process do not affect. -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
