Re: FreeBSD-9.1: machine reboots during snapshot creation, LORs found
On Thu, Jul 04, 2013 at 07:27:00AM +0200, Andre Albsmeier wrote: On Thu, 04-Jul-2013 at 07:24:40 +0200, Konstantin Belousov wrote: On Thu, Jul 04, 2013 at 07:14:09AM +0200, Andre Albsmeier wrote: On Mon, 17-Jun-2013 at 21:30:31 +0200, John Baldwin wrote: On Sunday, June 16, 2013 2:39:42 am Andre Albsmeier wrote: On Fri, 31-May-2013 at 16:51:03 +0200, John Baldwin wrote: On Friday, May 31, 2013 8:26:11 am Andre Albsmeier wrote: Each day at 5:15 we are generating snapshots on various machines. This used to work perfectly under 7-STABLE for years but since we started to use 9.1-STABLE the machine reboots in about 10% of all cases. After rebooting we find a new snapshot file which is a bit smaller than the good ones and with different permissions It does not succeed a fsck. In this example it is the one whose name is beginning with s3: -r--r- 1 root operator snapshot 72802894528 29 May 05:15 s2-2013.05.28-03.15.04 -r 1 root operator snapshot 72802893824 29 May 05:15 s3-2013.05.29-03.15.03 -r--r- 1 root operator snapshot 72802894528 28 May 14:22 s4-2013.05.23-06.38.44 -r--r- 1 root operator snapshot 72802894528 28 May 14:22 s5-2013.05.24-03.15.03 -r--r- 1 root operator snapshot 72802894528 28 May 14:22 s6-2013.05.25-03.15.03 After enabling DIAGNOSTIC, WITNESS and INVARIANTS in the kernel I see the following LORs (mksnap_ffs starts exactly at 5:15): May 29 05:15:00 kern.crit palveli kernel: lock order reversal: May 29 05:15:00 kern.crit palveli kernel: 1st 0xc2371da8 ufs (ufs) @ /src/src-9/sys/kern/vfs_mount.c:1240 May 29 05:15:00 kern.crit palveli kernel: 2nd 0xc2371ec4 devfs (devfs) @ /src/src-9/sys/ufs/ffs/ffs_vfsops.c:1414 May 29 05:15:04 kern.crit palveli kernel: lock order reversal: May 29 05:15:04 kern.crit palveli kernel: 1st 0xc228471c snaplk (snaplk) @ /src/src-9/sys/ufs/ufs/ufs_vnops.c:976 May 29 05:15:04 kern.crit palveli kernel: 2nd 0xc22f25e4 ufs (ufs) @ /src/src-9/sys/ufs/ffs/ffs_snapshot.c:1626 Unfortunatley no corefiles are being generated ;-(. I have checked and even rebuilt the (UFS1) fs in question from scratch. I have also seen this happen on an UFS2 on another machine and on a third one when running dump -L on a root fs. Any hints of how to proceed? Would it be possible to setup a serial console that is logged on this machine to see if it is panic'ing but failing to write out a crashdump? Couldn't attach the serial console yet ;-(. But I had people attach a KVMoverIP switch and enabled the various KDB options in the kernel. Now we can see a bit more (see below) -- no crashdump is being generated though. :( Unfortunately these LORs don't really help with discerning the cause of the reboot. If you have remote power access (and still wanted to test this) one option would be to change KDB to drop into the debugger on a panic. Then you could connect over the KVM and take images of the original panic along with a stack trace. After a few days of no problems, the box decided to crash during mksnap_ffs today ;-(. But now I have a crashdump, see below. Unfortunatley, I cannot upload the dump somewhere but if you ask me check whatever things I'll be happy to help. kgdb /usr/obj/src/src-9/sys/palveli/kernel.debug vmcore.4 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xcfb5e000 fault code = supervisor write, page not present instruction pointer = 0x20:0xc07cb2fe stack pointer = 0x28:0xd83545d0 frame pointer = 0x28:0xd835490c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 12929 (mksnap_ffs) trap number = 12 panic: page fault KDB: stack backtrace: db_trace_self_wrapper(c08207eb,d835441c,c05fdfc9,c081df13,c08a82e0,...) at db_trace_self_wrapper+0x26/frame 0xd83543ec kdb_backtrace(c081df13,c08a82e0,c0801bfa,d8354428,d8354428,...) at kdb_backtrace+0x29/frame
Where's the docs for FreeBSD maintenance with Subversion?
Greetings, I've _finally_ managed to get a break in my work schedule that coincides with a period where pointyhat isn't barfing on my ARCH. So I was able to (cv)sup src ports. Update the kernel successfully, and (after hours of work), managed to upgrade ports. But as (cv)sup was discontinued ~3 months ago, the ports aren't well synced, and I'm now working on a fairly wobbly system. I'm on RELENG_8 (8.4), and would like to sync my src ports via the (now defacto) subversion method. My previous experience is with the client meerly for the sake of obtaining the src, and building -- _not_ maintaining a tree. I've read what little is available in the handbook, and much of the Subversion book. But there are clearly different procedures/nuances where FreeBSD maintenance is concerned, both in the building of Subversion, and it's usage, where FreeBSD is concerned. The biggest questions in this regard, is; 1) what to do with my current INDEX-8 INDEX-8.db files? 2) what of the distfiles directory Do I simply copy them over, and check them in? Surely I'm not the only one that still has questions in this regard. Thank you for all your time, and consideration. --chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Where's the docs for FreeBSD maintenance with Subversion?
In message b8cefc405bcd2f7248f4c260a9148296.authentica...@ultimatedns.net, Chris H (bsd-li...@1command.com) wrote: Greetings, I've _finally_ managed to get a break in my work schedule that coincides with a period where pointyhat isn't barfing on my ARCH. So I was able to (cv)sup src ports. Update the kernel successfully, and (after hours of work), managed to upgrade ports. But as (cv)sup was discontinued ~3 months ago, the ports aren't well synced, and I'm now working on a fairly wobbly system. I'm on RELENG_8 (8.4), and would like to sync my src ports via the (now defacto) subversion method. My previous experience is with the client meerly for the sake of obtaining the src, and building -- _not_ maintaining a tree. I've read what little is available in the handbook, and much of the Subversion book. But there are clearly different procedures/nuances where FreeBSD maintenance is concerned, both in the building of Subversion, and it's usage, where FreeBSD is concerned. The biggest questions in this regard, is; 1) what to do with my current INDEX-8 INDEX-8.db files? 2) what of the distfiles directory Do I simply copy them over, and check them in? When I converted from csup to svn I did the following - which seems to work. :-) 1. mv /usr/ports /usr/ports.old 2. mkdir /usr/ports 3. svn checkout into /usr/ports 4. mv /usr/ports.old/distfiles /usr/ports When I do a svn update it ignores distfiles. I hope this terse reply helps. Cheers, Nick. -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Where's the docs for FreeBSD maintenance with Subversion?
In message b8cefc405bcd2f7248f4c260a9148296.authentica...@ultimatedns.net, Chris H (bsd-li...@1command.com) wrote: Greetings, I've _finally_ managed to get a break in my work schedule that coincides with a period where pointyhat isn't barfing on my ARCH. So I was able to (cv)sup src ports. Update the kernel successfully, and (after hours of work), managed to upgrade ports. But as (cv)sup was discontinued ~3 months ago, the ports aren't well synced, and I'm now working on a fairly wobbly system. I'm on RELENG_8 (8.4), and would like to sync my src ports via the (now defacto) subversion method. My previous experience is with the client meerly for the sake of obtaining the src, and building -- _not_ maintaining a tree. I've read what little is available in the handbook, and much of the Subversion book. But there are clearly different procedures/nuances where FreeBSD maintenance is concerned, both in the building of Subversion, and it's usage, where FreeBSD is concerned. The biggest questions in this regard, is; 1) what to do with my current INDEX-8 INDEX-8.db files? 2) what of the distfiles directory Do I simply copy them over, and check them in? When I converted from csup to svn I did the following - which seems to work. :-) 1. mv /usr/ports /usr/ports.old 2. mkdir /usr/ports 3. svn checkout into /usr/ports 4. mv /usr/ports.old/distfiles /usr/ports When I do a svn update it ignores distfiles. I hope this terse reply helps. Perfect! Thanks. --chris Cheers, Nick. -- ___ svn-src-stabl...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-stable-8 To unsubscribe, send any mail to svn-src-stable-8-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Where's the docs for FreeBSD maintenance with Subversion?
On Thu, 4 Jul 2013, N.J. Mann wrote: In message b8cefc405bcd2f7248f4c260a9148296.authentica...@ultimatedns.net, Chris H (bsd-li...@1command.com) wrote: Greetings, I've _finally_ managed to get a break in my work schedule that coincides with a period where pointyhat isn't barfing on my ARCH. So I was able to (cv)sup src ports. Update the kernel successfully, and (after hours of work), managed to upgrade ports. But as (cv)sup was discontinued ~3 months ago, the ports aren't well synced, and I'm now working on a fairly wobbly system. I'm on RELENG_8 (8.4), and would like to sync my src ports via the (now defacto) subversion method. My previous experience is with the client meerly for the sake of obtaining the src, and building -- _not_ maintaining a tree. I've read what little is available in the handbook, and much of the Subversion book. But there are clearly different procedures/nuances where FreeBSD maintenance is concerned, both in the building of Subversion, and it's usage, where FreeBSD is concerned. The biggest questions in this regard, is; 1) what to do with my current INDEX-8 INDEX-8.db files? 2) what of the distfiles directory Do I simply copy them over, and check them in? When I converted from csup to svn I did the following - which seems to work. :-) 1. mv /usr/ports /usr/ports.old 2. mkdir /usr/ports 3. svn checkout into /usr/ports 4. mv /usr/ports.old/distfiles /usr/ports When I do a svn update it ignores distfiles. The index files, too. They can be (slowly) built with 'make index', or downloaded with 'make fetchindex', or portmaster will fetch it automatically. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Phantom nulls in usbdevs.h during 9-STABLE kernel build
On Jul 4, 2013, at 04:43, J David j.david.li...@gmail.com wrote: We are seeing strange problems building the kernel on 9-STABLE. The problem is intermittent and will go away if we build enough times in a row without making any changes. The problem seems to be that the usbdevs.h file (which appears to be automatically generated) gets random NULL bytes in it. ... On the second failure posted below I took a hex dump of the usbdevs.h file. I don't see any NULLs at the target location, which is an empty line. (Just 0a 0a for the empty line.) In fact there are no nulls anywhere in the file. So the actual file does *not* have any NUL characters in it? What happens if you run e.g. sha1(1) over it a million times? If there are NUL characters, there might be a bug in the awk script that generates usbdevs.h. If there are no NUL characters, and you get a random failure each time, there might be a bug in clang. But did you mean you also saw it with gcc? -Dimitry ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD-9.1: machine reboots during snapshot creation, LORs found
On Thu, 04-Jul-2013 at 08:15:50 +0200, Konstantin Belousov wrote: On Thu, Jul 04, 2013 at 07:27:00AM +0200, Andre Albsmeier wrote: On Thu, 04-Jul-2013 at 07:24:40 +0200, Konstantin Belousov wrote: On Thu, Jul 04, 2013 at 07:14:09AM +0200, Andre Albsmeier wrote: On Mon, 17-Jun-2013 at 21:30:31 +0200, John Baldwin wrote: On Sunday, June 16, 2013 2:39:42 am Andre Albsmeier wrote: On Fri, 31-May-2013 at 16:51:03 +0200, John Baldwin wrote: On Friday, May 31, 2013 8:26:11 am Andre Albsmeier wrote: Each day at 5:15 we are generating snapshots on various machines. This used to work perfectly under 7-STABLE for years but since we started to use 9.1-STABLE the machine reboots in about 10% of all cases. After rebooting we find a new snapshot file which is a bit smaller than the good ones and with different permissions It does not succeed a fsck. In this example it is the one whose name is beginning with s3: -r--r- 1 root operator snapshot 72802894528 29 May 05:15 s2-2013.05.28-03.15.04 -r 1 root operator snapshot 72802893824 29 May 05:15 s3-2013.05.29-03.15.03 -r--r- 1 root operator snapshot 72802894528 28 May 14:22 s4-2013.05.23-06.38.44 -r--r- 1 root operator snapshot 72802894528 28 May 14:22 s5-2013.05.24-03.15.03 -r--r- 1 root operator snapshot 72802894528 28 May 14:22 s6-2013.05.25-03.15.03 After enabling DIAGNOSTIC, WITNESS and INVARIANTS in the kernel I see the following LORs (mksnap_ffs starts exactly at 5:15): May 29 05:15:00 kern.crit palveli kernel: lock order reversal: May 29 05:15:00 kern.crit palveli kernel: 1st 0xc2371da8 ufs (ufs) @ /src/src-9/sys/kern/vfs_mount.c:1240 May 29 05:15:00 kern.crit palveli kernel: 2nd 0xc2371ec4 devfs (devfs) @ /src/src-9/sys/ufs/ffs/ffs_vfsops.c:1414 May 29 05:15:04 kern.crit palveli kernel: lock order reversal: May 29 05:15:04 kern.crit palveli kernel: 1st 0xc228471c snaplk (snaplk) @ /src/src-9/sys/ufs/ufs/ufs_vnops.c:976 May 29 05:15:04 kern.crit palveli kernel: 2nd 0xc22f25e4 ufs (ufs) @ /src/src-9/sys/ufs/ffs/ffs_snapshot.c:1626 Unfortunatley no corefiles are being generated ;-(. I have checked and even rebuilt the (UFS1) fs in question from scratch. I have also seen this happen on an UFS2 on another machine and on a third one when running dump -L on a root fs. Any hints of how to proceed? Would it be possible to setup a serial console that is logged on this machine to see if it is panic'ing but failing to write out a crashdump? Couldn't attach the serial console yet ;-(. But I had people attach a KVMoverIP switch and enabled the various KDB options in the kernel. Now we can see a bit more (see below) -- no crashdump is being generated though. :( Unfortunately these LORs don't really help with discerning the cause of the reboot. If you have remote power access (and still wanted to test this) one option would be to change KDB to drop into the debugger on a panic. Then you could connect over the KVM and take images of the original panic along with a stack trace. After a few days of no problems, the box decided to crash during mksnap_ffs today ;-(. But now I have a crashdump, see below. Unfortunatley, I cannot upload the dump somewhere but if you ask me check whatever things I'll be happy to help. kgdb /usr/obj/src/src-9/sys/palveli/kernel.debug vmcore.4 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xcfb5e000 fault code = supervisor write, page not present instruction pointer = 0x20:0xc07cb2fe stack pointer = 0x28:0xd83545d0 frame pointer = 0x28:0xd835490c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 12929 (mksnap_ffs) trap number = 12 panic: page fault KDB: stack backtrace:
Re: Where's the docs for FreeBSD maintenance with Subversion?
Hello Chris On 04.07.2013 10:00, Chris H wrote: working on a fairly wobbly system. I'm on RELENG_8 (8.4), and would like to sync my src ports via the (now defacto) subversion method. My previous experience is with the client For /usr/src/ I did the following steps: Adjust the variables in /etc/make.conf (remove the old SUP* variables and add): SVN_UPDATE=yes SVN=/usr/local/bin/svn Then do the following steps: Backup your custom kernel config file and anything else you have customized in /usr/src/, or if you have the space, use: mv /usr/src /usr/src-old rm -rf /usr/src # only if you did not 'mv ...' svn checkout svn://svn.freebsd.org/base/releng/8.4 /usr/src Restore your custom kernel config file cd /usr/src make update # should not sync anything, just for testing Everything else is almost identical as before with csup/cvsup. The only drawback with the subversion method is, that when you would like to upgrade to e.g. RELENG_8_5, you need to redo the above steps with removing /usr/src and checkout. This was more easier with the csup/cvsup method with just adjusting the version in the supfile. If there is an easier solution to upgrade an existing svn checkout from e.g. 8.4 to 8.5, please tell me. With the above created svn checkout and then doing the 'make update' you will get the updates from any Security Advisory affecting your current RELEASE, as it was with csup/cvsup. The checkout with subversion uses significant more disk space than it was with csup/cvsup before. With subversion 1.8 I have ~720 MB (was ~770 MB with svn 1.7) in /usr/src/.svn (RELEASE-9.1) and ~670 MB (was ~830 MB with svn 1.7) in /usr/ports/.svn. A fresh install of a FreeBSD system is also an interesting challenge. In the past I did the install without Ports, then fetched a newer ports.tar.gz from the mirror and extracted it into /usr/ports/ and did use csup to get it up-to-date. With subversion this is a little bit more complicated, as subversion is also in the Ports and not in the FreeBSD base. You could install subversion and all the dependencies from packages and then do the svn checkout of /usr/ports/ and then upgrading the installed packages. Or you install the Ports and use portsnap to upgrade, build subversion and dependencies, remove /usr/ports/ again (probably preserve /usr/ports/distfiles/) and do the svn checkout of /usr/ports/. bye Fabian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Where's the docs for FreeBSD maintenance with Subversion?
On Thu, Jul 4, 2013 at 4:31 PM, Fabian Wenk fab...@wenks.ch wrote: If there is an easier solution to upgrade an existing svn checkout from e.g. 8.4 to 8.5, please tell me. cd /usr/src ; svn switch http://svn.freebsd.org/base/releng/8.5 Cheers Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Phantom nulls in usbdevs.h during 9-STABLE kernel build
On Thu, Jul 4, 2013 at 9:08 AM, Dimitry Andric d...@freebsd.org wrote:
So the actual file does *not* have any NUL characters in it? What
happens if you run e.g. sha1(1) over it a million times?
Based on this suggestion, I wrote a script to sha256 usbdevs.h every 0.25
seconds and did another buildworld. (Note: I did a third buildworld last
night, between the two I sent yesterday and this one. It was fine.)
It died with this:
In file included from
/usr/src/sys/modules/usb/quirk/../../../dev/usb/quirk/usb_quirk.c:51:
./usbdevs.h:2487:64: error: null character ignored
[-Werror,-Wnull-character]
#define USB_PRODUCT_LOGITECH_UN53B 0xc032 /* iFeel MouseMan */
^
/usr/src/sys/modules/usb/quirk/../../../dev/usb/quirk/usb_quirk.c:95:2:
error:
expected ')'
USB_QUIRK(LOGITECH, UN53B, 0x, 0x, UQ_NO_STRINGS),
^
/usr/src/sys/modules/usb/quirk/../../../dev/usb/quirk/usb_quirk.c:79:32:
note:
expanded from macro 'USB_QUIRK'
USB_QUIRK_VP(USB_VENDOR_##v, USB_PRODUCT_##v##_##p, l, h, __VA_ARGS__)
^
scratch space:29:1: note: expanded from macro 'USB_PRODUCT_'
USB_PRODUCT_LOGITECH_UN53B
^
./usbdevs.h:2487:65: note: expanded from macro 'USB_PRODUCT_LOGITECH_UN53B'
.../* iFeel MouseMan */U+#define USB_PRODUCT_LOGITECH_WMPAD...
^
/usr/src/sys/modules/usb/quirk/../../../dev/usb/quirk/usb_quirk.c:76:25:
note:
expanded from macro 'USB_QUIRK_VP'
{ .vid = (v), .pid = (p), .lo_rev = (l), .hi_rev = (h), \
^
/usr/src/sys/modules/usb/quirk/../../../dev/usb/quirk/usb_quirk.c:95:2:
note:
to match this '('
USB_QUIRK(LOGITECH, UN53B, 0x, 0x, UQ_NO_STRINGS),
^
/usr/src/sys/modules/usb/quirk/../../../dev/usb/quirk/usb_quirk.c:79:3:
note:
expanded from macro 'USB_QUIRK'
USB_QUIRK_VP(USB_VENDOR_##v, USB_PRODUCT_##v##_##p, l, h, __VA_ARGS__)
^
/usr/src/sys/modules/usb/quirk/../../../dev/usb/quirk/usb_quirk.c:76:24:
note:
expanded from macro 'USB_QUIRK_VP'
{ .vid = (v), .pid = (p), .lo_rev = (l), .hi_rev = (h), \
^
2 errors generated.
*** [usb_quirk.o] Error code 1
My script says usbdevs.h was generated early on in the build process (with
the same SHA256 value as the one that previously worked) and did not report
any subsequent changes during the build and failure.
If there are NUL characters, there might be a bug in the awk script that
generates usbdevs.h. If there are no NUL characters, and you get a
random failure each time, there might be a bug in clang.
As before, I don't see any nulls in the actual file:
0070 6f 75 73 65 20 2a 2f 0a 23 64 65 66 69 6e 65 09 |ouse
*/.#define.|
0080 55 53 42 5f 50 52 4f 44 55 43 54 5f 4c 4f 47 49
|USB_PRODUCT_LOGI|
0090 54 45 43 48 5f 55 4e 35 33 42 09 30 78 63 30 33
|TECH_UN53B.0xc03|
00a0 32 09 09 2f 2a 20 69 46 65 65 6c 20 4d 6f 75 73 |2../* iFeel
Mous|
00b0 65 4d 61 6e 20 2a 2f 0a 23 64 65 66 69 6e 65 09 |eMan
*/.#define.|
00c0 55 53 42 5f 50 52 4f 44 55 43 54 5f 4c 4f 47 49
|USB_PRODUCT_LOGI|
00d0 54 45 43 48 5f 57 4d 50 41 44 09 30 78 63 32 30
|TECH_WMPAD.0xc20|
But did you
mean you also saw it with gcc?
Yes, I am pretty sure we have seen this with gcc as well because one of the
first machines that started doing this doesn't have the CLANG options in
make.conf. I will try to reproduce that to be absolutely sure, but that
may take several hours.
Thanks!
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Phantom nulls in usbdevs.h during 9-STABLE kernel build
On Jul 4, 2013, at 18:02, J David j.david.li...@gmail.com wrote: ... Yes, I am pretty sure we have seen this with gcc as well because one of the first machines that started doing this doesn't have the CLANG options in make.conf. I will try to reproduce that to be absolutely sure, but that may take several hours. One other thing: which type of file system are you using for /usr/obj, or wherever you pointed $MAKEOBJDIRPREFIX? -Dimitry ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Where's the docs for FreeBSD maintenance with Subversion?
Hello Tom On 04.07.2013 17:52, Tom Evans wrote: On Thu, Jul 4, 2013 at 4:31 PM, Fabian Wenk fab...@wenks.ch wrote: If there is an easier solution to upgrade an existing svn checkout from e.g. 8.4 to 8.5, please tell me. cd /usr/src ; svn switch http://svn.freebsd.org/base/releng/8.5 Thank you, this is very helpful. It would probably be a good idea if this could be added to A.5. Using Subversion [1] in the handbook. [1] http://www.freebsd.org/doc/handbook/svn.html bye Fabian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD-9.1: machine reboots during snapshot creation, LORs found
On Thu, Jul 04, 2013 at 04:29:19PM +0200, Andre Albsmeier wrote: OK, patch is applied. I will reboot the machine later and see what happens tomorrow in the morning. However, it might take a few days since the last 2 weeks all was fine. BTW, should this patch be used in general or is it just for debugging? My understanding is that it is something which could stay in the code... Patch is to improve debugging. I probably commit it after the issue is closed. Arguments against the commit is that the change imposes small performance penalty due to save and restore of the %ebp (I doubt that this is measureable by any means). Also, arguably, such change should be done for all functions in support.s, but bcopy() is the hot spot. pgpXiPPGfVxyW.pgp Description: PGP signature
Re: FreeBSD-9.1: machine reboots during snapshot creation, LORs found
On Thu, 04-Jul-2013 at 19:25:28 +0200, Konstantin Belousov wrote: On Thu, Jul 04, 2013 at 04:29:19PM +0200, Andre Albsmeier wrote: OK, patch is applied. I will reboot the machine later and see what happens tomorrow in the morning. However, it might take a few days since the last 2 weeks all was fine. BTW, should this patch be used in general or is it just for debugging? My understanding is that it is something which could stay in the code... Patch is to improve debugging. That's what I suspected. I probably commit it after the issue is closed. Arguments against the commit is that the change imposes small performance penalty due to save and restore of the %ebp (I doubt that this is measureable by any means). Also, arguably, such change should be done for all functions in support.s, but bcopy() is the hot spot. Hmm, maybe it could simply get enabled conditionally through some kernel compile option which is off by default... -Andre ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
XHCI umass support breaks between r248085 and r252560 on 9-STABLE
Three different external hard drives (Seagate, Western Digital and noname USB 3.0 enclosure) refused to be recognized as the umass devices. Reverting /usr/src/sys/dev/bsd/controller to r248085, building and loading just xhci module makes drives appear again. Below are snippets from the log in both cases: Non working: Jul 4 14:35:17 twinhead kernel: xhci0: XHCI (generic) USB 3.0 controller mem 0xfddfe000-0xfddf irq 16 at device 0.0 on pci2 Jul 4 14:35:17 twinhead kernel: xhci0: 64 byte context size. Jul 4 14:35:17 twinhead kernel: usbus0 on xhci0 Jul 4 14:35:17 twinhead kernel: usbus0: 5.0Gbps Super Speed USB v3.0 Jul 4 14:35:17 twinhead kernel: ugen0.1: 0x1912 at usbus0 Jul 4 14:35:17 twinhead kernel: uhub0: 0x1912 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1 on usbus0 Jul 4 14:35:17 twinhead kernel: uhub0: 8 ports with 8 removable, self powered Jul 4 14:35:24 twinhead kernel: ugen0.2: ASMedia at usbus0 Jul 4 14:35:24 twinhead kernel: umass0: ASMedia AS2105, class 0/0, rev 3.00/0.01, addr 1 on usbus0 Jul 4 14:35:29 twinhead kernel: (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 Jul 4 14:35:29 twinhead kernel: (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error Jul 4 14:35:29 twinhead kernel: (probe0:umass-sim0:0:0:0): Retrying command Jul 4 14:35:30 twinhead kernel: (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 Jul 4 14:35:30 twinhead kernel: (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error Jul 4 14:35:30 twinhead kernel: (probe0:umass-sim0:0:0:0): Retrying command Jul 4 14:35:35 twinhead kernel: (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 Jul 4 14:35:35 twinhead kernel: (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error Jul 4 14:35:35 twinhead kernel: (probe0:umass-sim0:0:0:0): Retrying command Jul 4 14:35:36 twinhead kernel: (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 Jul 4 14:35:36 twinhead kernel: (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error Jul 4 14:35:36 twinhead kernel: (probe0:umass-sim0:0:0:0): Retrying command Jul 4 14:35:41 twinhead kernel: (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 Jul 4 14:35:41 twinhead kernel: (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error Jul 4 14:35:41 twinhead kernel: (probe0:umass-sim0:0:0:0): Error 5, Retries exhausted Working: Jul 4 14:40:20 twinhead kernel: ugen0.2: ASMedia at usbus0 (disconnected) Jul 4 14:40:20 twinhead kernel: umass0: at uhub0, port 2, addr 1 (disconnected) Jul 4 14:40:27 twinhead kernel: ugen0.2: vendor 0x174c at usbus0 Jul 4 14:40:27 twinhead kernel: umass0: vendor 0x174c product 0x5106, class 0/0, rev 3.00/0.01, addr 1 on usbus0 Jul 4 14:40:27 twinhead kernel: (probe0:umass-sim0:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00 10 00 00 Jul 4 14:40:27 twinhead kernel: (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error Jul 4 14:40:27 twinhead kernel: (probe0:umass-sim0:0:0:0): SCSI status: Check Condition Jul 4 14:40:27 twinhead kernel: (probe0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid command operation code) Jul 4 14:40:27 twinhead kernel: (probe0:umass-sim0:0:0:0): Error 22, Unretryable error Jul 4 14:40:27 twinhead kernel: da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 Jul 4 14:40:27 twinhead kernel: da0: Hitachi HTS542520K9SA00 BBDO Fixed Direct Access SCSI-5 device Jul 4 14:40:27 twinhead kernel: da0: 400.000MB/s transfers Jul 4 14:40:27 twinhead kernel: da0: 190782MB (390721968 512 byte sectors: 255H 63S/T 24321C) Jul 4 14:40:27 twinhead kernel: da0: quirks=0x2NO_6_BYTE I can provide additional information or try patches as necessary. Alexandre Sunny Kovalenko (Олександр Коваленко) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
UFS Trim wont stay set
Hello, I've just installed a stable snapshot on a new machine with a SSD drive, after installing i booted single user mode and ran # tunefs -t enable /dev/ada0p2 tunefs: issue TRIM to the disk set Great, back to multiuser mode, i check the partition # tunefs -p /dev/ada0p2 tunefs: POSIX.1e ACLs: (-a)disabled tunefs: NFSv4 ACLs: (-N) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) enabled tunefs: soft update journaling: (-j) enabled tunefs: gjournal: (-J) disabled tunefs: trim: (-t) disabled What the heck.. did i miss something? Back to single user mode and # tunefs -t enable /dev/ada0p2 tunefs: issue TRIM to the disk remains unchanged as enabled I check again in multiuser mode and it says disabled, any ideas what is going on here? Thanks. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: UFS Trim wont stay set
On Thu, Jul 04, 2013 at 03:37:28PM -0400, Mike Jakubik wrote: Hello, I've just installed a stable snapshot on a new machine with a SSD drive, after installing i booted single user mode and ran # tunefs -t enable /dev/ada0p2 tunefs: issue TRIM to the disk set Great, back to multiuser mode, i check the partition # tunefs -p /dev/ada0p2 tunefs: POSIX.1e ACLs: (-a)disabled tunefs: NFSv4 ACLs: (-N) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) enabled tunefs: soft update journaling: (-j) enabled tunefs: gjournal: (-J) disabled tunefs: trim: (-t) disabled What the heck.. did i miss something? Back to single user mode and # tunefs -t enable /dev/ada0p2 tunefs: issue TRIM to the disk remains unchanged as enabled I check again in multiuser mode and it says disabled, any ideas what is going on here? Yup, experienced this myself many times over. The reasons are understood (it's not limited to just the TRIM bits, it's related to anything adjusting the superblock -- it gets cached in memory in certain situations and not flushed back to disk). Hint: are you booting into single user and then issuing a mount command before doing your tunefs stuff? If so, this is probably what's causing it (at least it was in my case). Instead just boot into single-user, do not mount anything, and use /sbin/tunefs (if available -- depends on your filesystem setup) or /rescue/tunefs. -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: UFS Trim wont stay set
On 07/04/13 16:33, Jeremy Chadwick wrote: Yup, experienced this myself many times over. The reasons are understood (it's not limited to just the TRIM bits, it's related to anything adjusting the superblock -- it gets cached in memory in certain situations and not flushed back to disk). Hint: are you booting into single user and then issuing a mount command before doing your tunefs stuff? If so, this is probably what's causing it (at least it was in my case). Instead just boot into single-user, do not mount anything, and use /sbin/tunefs (if available -- depends on your filesystem setup) or /rescue/tunefs. I booted in to single user mode and the system mounted the only file system there, which is mounted at /. What i did now however is boot off a Live CD and run tunefs, this did the trick! Thank You! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: UFS Trim wont stay set
On Thu, Jul 04, 2013 at 04:48:38PM -0400, Mike Jakubik wrote: On 07/04/13 16:33, Jeremy Chadwick wrote: Yup, experienced this myself many times over. The reasons are understood (it's not limited to just the TRIM bits, it's related to anything adjusting the superblock -- it gets cached in memory in certain situations and not flushed back to disk). Hint: are you booting into single user and then issuing a mount command before doing your tunefs stuff? If so, this is probably what's causing it (at least it was in my case). Instead just boot into single-user, do not mount anything, and use /sbin/tunefs (if available -- depends on your filesystem setup) or /rescue/tunefs. I booted in to single user mode and the system mounted the only file system there, which is mounted at /. What i did now however is boot off a Live CD and run tunefs, this did the trick! I talked with Andriy Gapon a couple years ago about this, actually. I had to dig up the thread. Here are the relevant parts (read in order): http://lists.freebsd.org/pipermail/freebsd-stable/2011-June/062921.html http://lists.freebsd.org/pipermail/freebsd-stable/2011-June/062922.html http://lists.freebsd.org/pipermail/freebsd-stable/2011-June/062923.html http://lists.freebsd.org/pipermail/freebsd-stable/2011-June/062924.html Make sure you read Andriy's comments (2nd URL) in full. My follow-up (4th URL) confirms that the mount -a (which is what made / read-write since /etc/fstab obviously has / as rw) was causing the issue. He explains the reason. -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FREEBSD_INSTALL failed with error 19 during booting installer
W dniu 2013-06-28 20:26, Jeremy Chadwick pisze: Try using a USB flash drive + memstick image instead of CD-based media. Hi, it worked ;) thanks for help. What's interesting, after upgrading the IPMI software I was even able to Boot CD Image via IPMI virtual DVD and installer worked also. Regards, -- Marek Salwerowicz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Phantom nulls in usbdevs.h during 9-STABLE kernel build
On Thu, Jul 4, 2013 at 12:15 PM, Dimitry Andric d...@freebsd.org wrote: One other thing: which type of file system are you using for /usr/obj, or wherever you pointed $MAKEOBJDIRPREFIX? Also ZFS-over-NFS. The goal is to build on one machine and install on many. I was able to reproduce this with gcc: === usb/u3g (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/NFSN32/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/usr/obj/usr/src/sys/NFSN32 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -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 -c /usr/src/sys/modules/usb/u3g/../../../dev/usb/serial/u3g.c In file included from /usr/src/sys/modules/usb/u3g/../../../dev/usb/serial/u3g.c:57: ./usbdevs.h:1362:1: error: null character(s) ignored *** [u3g.o] Error code 1 Thanks! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Phantom nulls in usbdevs.h during 9-STABLE kernel build
On Thu, Jul 04, 2013 at 07:38:24PM -0400, J David wrote: On Thu, Jul 4, 2013 at 12:15 PM, Dimitry Andric d...@freebsd.org wrote: One other thing: which type of file system are you using for /usr/obj, or wherever you pointed $MAKEOBJDIRPREFIX? Also ZFS-over-NFS. The goal is to build on one machine and install on many. I was able to reproduce this with gcc: === usb/u3g (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/NFSN32/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/usr/obj/usr/src/sys/NFSN32 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -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 -c /usr/src/sys/modules/usb/u3g/../../../dev/usb/serial/u3g.c In file included from /usr/src/sys/modules/usb/u3g/../../../dev/usb/serial/u3g.c:57: ./usbdevs.h:1362:1: error: null character(s) ignored *** [u3g.o] Error code 1 Try to apply r252528 and see if it helps. pgp6HoxMSjYtW.pgp Description: PGP signature
