Can't build boot blocks after new GPT attributes added
The below commit has broken the ability to build system boot blocks (including pxeldr) the historic way[1]: http://freshbsd.org/2010/10/17/20/10/00 The breakage on RELENG_8 (dated as of a few minutes ago): # rm -fr /usr/obj/* # cd /sys/boot # make clean [...] # make [...] cc -DBOOTPROG=\gptboot\ -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time -mno-align-long-strings -mrtd -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -DGPT -DUFS1_AND_UFS2 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 -I/usr/src/sys/boot/i386/gptboot/../../common -I/usr/src/sys/boot/i386/gptboot/../common -I/usr/src/sys/boot/i386/gptboot/../btx/lib -I. -I/usr/src/sys/boot/i386/gptboot/../boot2 -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline --param max-inline-insns-single=100 -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -m32 -march=i386 -std=gnu99 -c /usr/src/sys/boot/i386/gptboot/../../common/gpt.c /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptfind': /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: 'GPT_ENT_ATTR_BOOTME' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: (Each undeclared identifier is reported only once /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: for each function it appears in.) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:130: error: 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptbootfailed': /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:217: error: 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:222: error: 'GPT_ENT_ATTR_BOOTFAILED' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptbootconv': /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:249: error: 'GPT_ENT_ATTR_BOOTME' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:250: error: 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:251: error: 'GPT_ENT_ATTR_BOOTFAILED' undeclared (first use in this function) *** Error code 1 Stop in /usr/src/sys/boot/i386/gptboot. *** Error code 1 Stop in /usr/src/sys/boot/i386. *** Error code 1 Stop in /usr/src/sys/boot. Please advise. If there is a new/correct method, then I'd like to know what it is, in addition to the Handbook needing to be updated. [1]: http://www.freebsd.org/doc/handbook/serialconsole-setup.html (See Section 26.6.5.2) -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | 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: Can't build boot blocks after new GPT attributes added
On Wed, Oct 27, 2010 at 12:44:02AM -0700, Jeremy Chadwick wrote: The below commit has broken the ability to build system boot blocks (including pxeldr) the historic way[1]: http://freshbsd.org/2010/10/17/20/10/00 The breakage on RELENG_8 (dated as of a few minutes ago): # rm -fr /usr/obj/* # cd /sys/boot # make clean [...] # make [...] cc -DBOOTPROG=\gptboot\ -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time -mno-align-long-strings -mrtd -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -DGPT -DUFS1_AND_UFS2 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 -I/usr/src/sys/boot/i386/gptboot/../../common -I/usr/src/sys/boot/i386/gptboot/../common -I/usr/src/sys/boot/i386/gptboot/../btx/lib -I. -I/usr/src/sys/boot/i386/gptboot/../boot2 -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline --param max-inline-insns-single=100 -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -m32 -march=i386 -std=gnu99 -c /usr/src/sys/boot/i386/gptboot/../../common/gpt.c /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptfind': /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: 'GPT_ENT_ATTR_BOOTME' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: (Each undeclared identifier is reported only once /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: for each function it appears in.) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:130: error: 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptbootfailed': /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:217: error: 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:222: error: 'GPT_ENT_ATTR_BOOTFAILED' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptbootconv': /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:249: error: 'GPT_ENT_ATTR_BOOTME' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:250: error: 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:251: error: 'GPT_ENT_ATTR_BOOTFAILED' undeclared (first use in this function) *** Error code 1 Stop in /usr/src/sys/boot/i386/gptboot. *** Error code 1 Stop in /usr/src/sys/boot/i386. *** Error code 1 Stop in /usr/src/sys/boot. Please advise. If there is a new/correct method, then I'd like to know what it is, in addition to the Handbook needing to be updated. [1]: http://www.freebsd.org/doc/handbook/serialconsole-setup.html (See Section 26.6.5.2) Well, your problem is that gptboot.c is including gpt.h not from your source tree, but from /usr/include/sys/, which has an old version of this header file. This can be easly fixed by extending CFLAGS in one of the Makefiles (which is already done in HEAD), but I'm afraid this procedure is incorrect (and never was correct). Apart from including wrong files it also links to wrong libraries, etc. The proper way is to: # cd /usr/src # make buildenv # cd sys/boot # make clean make make install -- Pawel Jakub Dawidek http://www.wheelsystems.com p...@freebsd.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpGuoEb8uCVg.pgp Description: PGP signature
Re: Can't build boot blocks after new GPT attributes added
On Wed, Oct 27, 2010 at 10:08:17AM +0200, Pawel Jakub Dawidek wrote: On Wed, Oct 27, 2010 at 12:44:02AM -0700, Jeremy Chadwick wrote: The below commit has broken the ability to build system boot blocks (including pxeldr) the historic way[1]: http://freshbsd.org/2010/10/17/20/10/00 The breakage on RELENG_8 (dated as of a few minutes ago): # rm -fr /usr/obj/* # cd /sys/boot # make clean [...] # make [...] cc -DBOOTPROG=\gptboot\ -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time -mno-align-long-strings -mrtd -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -DGPT -DUFS1_AND_UFS2 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 -I/usr/src/sys/boot/i386/gptboot/../../common -I/usr/src/sys/boot/i386/gptboot/../common -I/usr/src/sys/boot/i386/gptboot/../btx/lib -I. -I/usr/src/sys/boot/i386/gptboot/../boot2 -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline --param max-inline-insns-single=100 -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -m32 -march=i386 -std=gnu99 -c /usr/src/sys/boot/i386/gptboot/../../common/gpt.c /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptfind': /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: 'GPT_ENT_ATTR_BOOTME' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: (Each undeclared identifier is reported only once /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: for each function it appears in.) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:130: error: 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptbootfailed': /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:217: error: 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:222: error: 'GPT_ENT_ATTR_BOOTFAILED' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptbootconv': /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:249: error: 'GPT_ENT_ATTR_BOOTME' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:250: error: 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:251: error: 'GPT_ENT_ATTR_BOOTFAILED' undeclared (first use in this function) *** Error code 1 Stop in /usr/src/sys/boot/i386/gptboot. *** Error code 1 Stop in /usr/src/sys/boot/i386. *** Error code 1 Stop in /usr/src/sys/boot. Please advise. If there is a new/correct method, then I'd like to know what it is, in addition to the Handbook needing to be updated. [1]: http://www.freebsd.org/doc/handbook/serialconsole-setup.html (See Section 26.6.5.2) Well, your problem is that gptboot.c is including gpt.h not from your source tree, but from /usr/include/sys/, which has an old version of this header file. This can be easly fixed by extending CFLAGS in one of the Makefiles (which is already done in HEAD), but I'm afraid this procedure is incorrect (and never was correct). Apart from including wrong files it also links to wrong libraries, etc. The proper way is to: # cd /usr/src # make buildenv # cd sys/boot # make clean make make install Thanks for the tip -- the CFLAGS change in a Makefile sounds like the solution, since the latter (re: proper way) didn't work (exact same problem). The Makefile adjustment you mention for HEAD is here: http://freshbsd.org/2010/10/08/10/27/52 But there's no mention of an MFC date in the commit message. Can this be MFC'd? For now, make buildworld works as a workaround (pull the bootstrap binaries needed out of /usr/obj). -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | 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: Can't build boot blocks after new GPT attributes added
on 27/10/2010 12:17 Jeremy Chadwick said the following: On Wed, Oct 27, 2010 at 10:08:17AM +0200, Pawel Jakub Dawidek wrote: The proper way is to: # cd /usr/src # make buildenv # cd sys/boot # make clean make make install Thanks for the tip -- the CFLAGS change in a Makefile sounds like the solution, since the latter (re: proper way) didn't work (exact same problem). The above will work if you already have the toolchain built - that's the only way to ensure that you don't depend on anything in the currently installed world. See build(7). -- Andriy Gapon ___ 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: Can't build boot blocks after new GPT attributes added
On Wednesday, October 27, 2010 3:44:02 am Jeremy Chadwick wrote: The below commit has broken the ability to build system boot blocks (including pxeldr) the historic way[1]: http://freshbsd.org/2010/10/17/20/10/00 The breakage on RELENG_8 (dated as of a few minutes ago): # rm -fr /usr/obj/* # cd /sys/boot # make clean This only works if your source tree is in sync with your installed world. Adding a hack to the Makefile is wrong. The buildenv approach pjd@ suggested will work for the case that your source tree does not match your installed world. Maybe you could add text to the handbook to say this, but it is already implicitly assumed in the handbook section you are referring to since it assumes you can safely compile a new kernel, etc. The handbook section is meant as more of a tutorial on how to enable a serial console on a fresh box. Once you are experienced enough to start using buildworld, etc. I don't think it is unreasonable to require users to understand that having a source tree different from the installed world requires extra steps. If we were to document those every time it would clutter documentation making it harder for someone who is new to FreeBSD to simply setup a serial console on a box that they just installed. -- John Baldwin ___ 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: Can't build boot blocks after new GPT attributes added
On Wed, Oct 27, 2010 at 09:27:03AM -0400, John Baldwin wrote: On Wednesday, October 27, 2010 3:44:02 am Jeremy Chadwick wrote: The below commit has broken the ability to build system boot blocks (including pxeldr) the historic way[1]: http://freshbsd.org/2010/10/17/20/10/00 The breakage on RELENG_8 (dated as of a few minutes ago): # rm -fr /usr/obj/* # cd /sys/boot # make clean This only works if your source tree is in sync with your installed world. Adding a hack to the Makefile is wrong. The buildenv approach pjd@ suggested will work for the case that your source tree does not match your installed world. But this doesn't appear to be the case here: $ uname -a FreeBSD icarus.home.lan 8.1-STABLE FreeBSD 8.1-STABLE #0: Sat Oct 16 07:10:54 PDT 2010 r...@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64 amd64 $ sudo -i icarus# rm -fr /usr/obj/* rm: No match. icarus# cd /usr/src icarus# make buildenv Entering world for amd64:amd64 # make clean make [...] cc -DBOOTPROG=\gptboot\ -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time -mno-align-long-strings -mrtd -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -DGPT -DUFS1_AND_UFS2 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 -I/usr/src/sys/boot/i386/gptboot/../../common -I/usr/src/sys/boot/i386/gptboot/../common -I/usr/src/sys/boot/i386/gptboot/../btx/lib -I. -I/usr/src/sys/boot/i386/gptboot/../boot2 -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline --param max-inline-insns-single=100 -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -m32 -march=i386 -std=gnu99 -c /usr/src/sys/boot/i386/gptboot/../../common/gpt.c /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptfind': /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: 'GPT_ENT_ATTR_BOOTME' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: (Each undeclared identifier is reported only once /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: for each function it appears in.) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:130: error: 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptbootfailed': /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:217: error: 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:222: error: 'GPT_ENT_ATTR_BOOTFAILED' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptbootconv': /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:249: error: 'GPT_ENT_ATTR_BOOTME' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:250: error: 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function) /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:251: error: 'GPT_ENT_ATTR_BOOTFAILED' undeclared (first use in this function) *** Error code 1 Stop in /usr/src/sys/boot/i386/gptboot. *** Error code 1 Stop in /usr/src/sys/boot/i386. *** Error code 1 Stop in /usr/src/sys/boot. # ls -l /usr/src/sys/boot/i386/gptboot/../../common/gpt.c -rw-r--r-- 1 root wheel 10927 Oct 17 13:10 /usr/src/sys/boot/i386/gptboot/../../common/gpt.c Any ideas? Maybe you could add text to the handbook to say this, but it is already implicitly assumed in the handbook section you are referring to since it assumes you can safely compile a new kernel, etc. The handbook section is meant as more of a tutorial on how to enable a serial console on a fresh box. Once you are experienced enough to start using buildworld, etc. I don't think it is unreasonable to require users to understand that having a source tree different from the installed world requires extra steps. I don't think it's unreasonable either, it's just not well-documented or well-established. For example, this is the first time I've heard of buildenv, not to mention the other pieces mentioned in build(7). That doesn't mean FreeBSD is at fault, it just means there's been changes to things which are hard to keep up to date on. If we were to document those every time it would clutter documentation making it harder for someone who is new to FreeBSD to simply setup a serial console on a box that they just installed. Understood. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org
Re: Can't build boot blocks after new GPT attributes added
On Wed, Oct 27, 2010 at 06:48:58AM -0700, Jeremy Chadwick wrote: On Wed, Oct 27, 2010 at 09:27:03AM -0400, John Baldwin wrote: On Wednesday, October 27, 2010 3:44:02 am Jeremy Chadwick wrote: The below commit has broken the ability to build system boot blocks (including pxeldr) the historic way[1]: http://freshbsd.org/2010/10/17/20/10/00 The breakage on RELENG_8 (dated as of a few minutes ago): # rm -fr /usr/obj/* # cd /sys/boot # make clean This only works if your source tree is in sync with your installed world. Adding a hack to the Makefile is wrong. The buildenv approach pjd@ suggested will work for the case that your source tree does not match your installed world. But this doesn't appear to be the case here: [...] Because you don't have toolchain built. Once you buildworld you can do that. All in all, the safest and most recommended way is to just use buildworld/buildkernel. -- Pawel Jakub Dawidek http://www.wheelsystems.com p...@freebsd.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgppZbOHEKVga.pgp Description: PGP signature
Re: Can't build boot blocks after new GPT attributes added
Jeremy Chadwick free...@jdc.parodius.com writes: $ uname -a FreeBSD icarus.home.lan 8.1-STABLE FreeBSD 8.1-STABLE #0: Sat Oct 16 07:10:54 PDT 2010 r...@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64 amd64 $ sudo -i icarus# rm -fr /usr/obj/* rm: No match. icarus# cd /usr/src icarus# make toolchain icarus# make buildenv Entering world for amd64:amd64 # make clean make [...] FTFY. HTH, HAND! DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: hast vs ggate+gmirror sychrnoisation speed
On Tue, 26 Oct 2010 17:01:01 +0100 Pete French wrote:
PF Actually, I just llooked I dmesg on the secondary - it is full
PF of messages thus:
PF Oct 26 15:44:59 serpentine-passive hastd[10394]: [serp0] (secondary)
Unable to receive request header: RPC version wrong.
PF Oct 26 15:45:00 serpentine-passive hastd[782]: [serp0] (secondary) Worker
process exited ungracefully (pid=10394, exitcode=75).
PF Oct 26 15:46:59 serpentine-passive hastd[10421]: [serp0] (secondary)
Unable to receive request header: RPC version wrong.
PF Oct 26 15:47:04 serpentine-passive hastd[782]: [serp0] (secondary) Worker
process exited ungracefully (pid=10421, exitcode=75).
I saw this too but only sporadic messages so I forgot and did not investigate
then this :-).
Now running synchronization I see them too (but again only sporadic). Setting
the assertion and looking at the received header:
(gdb) list
309 goto fail;
310
311 if (hdr.version != HAST_PROTO_VERSION) {
312 assert(0);
313 errno = ERPCMISMATCH;
314 goto fail;
315 }
316
317 hdr.size = le32toh(hdr.size);
318
(gdb) p/x hdr
$2 = {version = 0x9, size = 0x65657266}
So it looks like garbage.
In hast_proto_send() we send header and then data. Couldn't it be that
remote_send and sync threads interfere and their packets are mixed? May be some
synchronization is needed here?
I set sleep(1) in hast_proto_send() between proto_send(header) and
proto_send(data). The error started to occur frequently.
--
Mikolaj Golub
___
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
beastiality
on the serial console, i am seeing twirlies doubled, as in
//
and the beastie is very tortured
+-++¿Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä|Ä-Ä
||³
||³ ||³ ,, ,,
||³,, ||³/()` //((
||³Welcome to FreeBSD!oo FFrr|BSSDD!! \ \___ / | \\
\\___||³ // || ||³/- _ `-/ '
//-- __ ||³``--//'' ||³ (/\/ \ \
/\((//\\// \||³1. Boot FreeBSD [default]BSSDD [[ddeef|aauulltt]] / / | `
\/ // ||³2. Boot FreeBSD with ACPI enabledwiitth| AACCPPII eennaab) /
|/|||³3. Boot FreeBSD in Safe ModeDD iinn S|a`-^--'`
'`--^^'||³4. Boot FreeBSD in single user moden s|i (_.) _ )
/ddee))_||³5. Boot FreeBSD with verbose loggingtth| `.___/`
/ /||³6. Escape to loader promptllooaaddeerr |p `-'
/ ``-||³7. Rebootebbtt || . __ / __
\ // _||³ \\ || |O)))==) \)
/|))))||³\\)) //|| || '`--'
`.__,' \`'' ``.||³__,,'' \\ || |
| || ||³|| ||
\ / /\ ||³Select option, [Enter] for defaultEnntt|e
__( (_ / \__/_(( ||³or [Space] to pause timer H--11 ussee|
,' ,-' | ,,-+-++
`--{__) -Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä_))
Copyright (c) 1992-2010 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 8.1-STABLE #1: Sun Sep 5 12:04:21 GMT 2010
r...@test.psg.com:/usr/obj/usr/src/sys/SPARE i386
Timecounter i8254 frequency 1193182 Hz quality 0
CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2798.67-MHz 686-class CPU)
Origin = GenuineIntel Id = 0xf27 Family = f Model = 2 Stepping = 7
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,C
spare.psg.com:/root# cat /boot/loader.rc
\ Loader.rc
\ $FreeBSD: src/sys/boot/i386/loader/loader.rc,v 1.4 2005/10/30 05:41:42 scottl
Exp $
\
\ Includes additional commands
include /boot/loader.4th
\ Reads and processes loader.conf variables
start
\ Tests for password -- executes autoboot first if a password was defined
check-password
\ Load in the boot menu
include /boot/beastie.4th
\ Start the boot menu
beastie-start
spare.psg.com:/root# cat /boot/loader.conf.local
loader_logo=beastie
#
console=comconsole vidconsole
comconsole_speed=9600
#
ipfw_load=YES
#
___
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: beastiality
On Thu, Oct 28, 2010 at 04:47:00AM +0900, Randy Bush wrote:
on the serial console, i am seeing twirlies doubled, as in
//
and the beastie is very tortured
+-++¿Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä|Ä-Ä
||³
||³ ||³ ,, ,,
||³,, ||³/()`
//(( ||³Welcome to FreeBSD!oo FFrr|BSSDD!! \ \___ /
| \\ \\___||³ // || ||³/- _
`-/ ' //-- __ ||³``--//'' ||³ (/\/
\ \ /\((//\\// \||³1. Boot FreeBSD [default]BSSDD [[ddeef|aauulltt]] /
/ | `\/ // ||³2. Boot FreeBSD with ACPI enabledwiitth| AACCPPII
eennaab) /|/|||³3. Boot FreeBSD in Safe ModeDD iinn S|a
`-^--'` '`--^^'||³4. Boot FreeBSD in single user moden s|i
(_.) _ ) /ddee))_||³5. Boot FreeBSD with verbose loggingtth|
`.___/`/ /||³6. Escape to loader promptllooaaddeerr |p
`-' / ``-||³7. Rebootebbtt ||
. __ / __ \ // _||³ \\
|| |O)))==) \) /|))))||³\\)) //||
|| '`--' `.__,' \`'' ``.||³__,,'' \\
|| || || ||³||
|| \ / /\ ||³Select option, [Enter] for
defaultEnntt|e __( (_ / \__/_(( ||³or [Space] to pause
timer H--11 ussee| ,' ,-' |
,,-+-++
`--{__) -Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä_))
[...]
spare.psg.com:/root# cat /boot/loader.conf.local
loader_logo=beastie
#
console=comconsole vidconsole
comconsole_speed=9600
#
ipfw_load=YES
This is often caused by a combination of two things being enabled
simultaneously: BIOS-level serial console redirection after POST, and
FreeBSD's serial console support. Effectively, the system BIOS is
redirecting VGA output to the serial port, while simultaneously
FreeBSD is doing serial console.
But I've seen different behaviour on different hardware over the years
when the first option is enabled.
- Doubling of characters like the above (but sometimes not doubled)
- System hard locking (reset/power cycle required) the instant the boot
loader tries to do serial (some of my Yahoo! colleagues can confirm
this one, even when using RedHat)
- System boots/runs fine but no serial output is visible past loader
I have some older Supermicro systems which do even weirder things when
the option is enabled, like lock up after loader. I've also see
different behaviour on RELENG_7 than I do RELENG_8.
Back to Supermicro systems -- the aforementioned feature is usually
labelled as Continue C.R. After POST (C.R. stands for Console
Redirection). This is not the same thing as disabling BIOS-level serial
console entirely, just that the Agent (some sort of interrupt tie-in)
isn't retained after POST.
If your system offers the BIOS option, you can try turning it off and
see if things improve. Be aware that you will lose the ability to
access things like Option ROMs (SCSI BIOSes, Intel NIC PXE boot
information, etc.).
If your system doesn't offer that BIOS option, then possibly just
leaving console as its default will suffice.
--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| 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: beastiality
This is often caused by a combination of two things being enabled simultaneously: BIOS-level serial console redirection after POST, and FreeBSD's serial console support. bingo! thanks randy ___ 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
ZFS write speed
Hi list, I've got very low write speed using ZFS on a SATA disk. My HDD configuration is: ad4: 70911MB WDC WD740BLFS-01YBU0 04.04V01 at ata2-master UDMA100 SATA 3Gb/s ad6: 78532MB Hitachi HDS728080PLA380 PF2OA60A at ata3-master UDMA100 SATA 1.5Gb/s ad8: 1430799MB WDC WD15EARS-00MVWB0 51.0AB51 at ata4-master UDMA100 SATA 3Gb/s ad4 and ad6 are single-slice disks (UFS2 with soft updates) ZFS configuration is following: zpool create Z ad8 zfs create Z/music zfs create Z/video All ZFS parameters are default. kern.maxvnodes = 100 To test my configuration I recursively copied from ad6 to ad8 two directories. The first one contains MP3 files (average size = 10MB). The second one contains AVI files (average size = 1GB). To compare performance I repeated above tests with ad8 using UFS2 with soft updates. 18GB of MP3 files required 10m35s to copy to UFS2 and 21m40s to copy to ZFS. 30GB of AVI files required 16m6s to copy to UFS2 and 1h2m39s to copy to ZFS. I used for tests FreeBSD 8.1R amd64. Amount of RAM on my machine is 6GB. Any tips? -- Regards, Serguey. ___ 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: cdrtools /devel and wodim broken
Sean C. Farley-2 wrote: For me, the solution appeared to be setting the grace time to three seconds to avoid the slowdown of the drive: gracetime=3 At least, the disc worked on subsequent burns this way. Jakub, you may try to see if this setting helps. No, gracetime doesn't help. Maybe Alexander Motin could shed some light on (ahci?) problem? thanks for assistance, Jakub Lach -- View this message in context: http://old.nabble.com/cdrtools--devel-and-wodim-broken-tp29978939p30071221.html Sent from the freebsd-stable mailing list archive at Nabble.com. ___ 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: ZFS write speed
Am 27.10.2010 um 22:51 schrieb S.N.Grigoriev: Hi list, I've got very low write speed using ZFS on a SATA disk. My HDD configuration is: ad4: 70911MB WDC WD740BLFS-01YBU0 04.04V01 at ata2-master UDMA100 SATA 3Gb/s ad6: 78532MB Hitachi HDS728080PLA380 PF2OA60A at ata3-master UDMA100 SATA 1.5Gb/s ad8: 1430799MB WDC WD15EARS-00MVWB0 51.0AB51 at ata4-master UDMA100 SATA 3Gb/s The EARS has 4k sectors, if I'm not mistaken. I don't recall the eventual outcome, but there was a long thread on stable or hackers on how to ensure proper alignment and (minimun) 4k-sized writes to make sure the disk doesn't have to do a read-modify-write cycle, so try and search the archives. ad4 and ad6 are single-slice disks (UFS2 with soft updates) ZFS configuration is following: zpool create Z ad8 zfs create Z/music zfs create Z/video All ZFS parameters are default. kern.maxvnodes = 100 To test my configuration I recursively copied from ad6 to ad8 two directories. The first one contains MP3 files (average size = 10MB). The second one contains AVI files (average size = 1GB). To compare performance I repeated above tests with ad8 using UFS2 with soft updates. 18GB of MP3 files required 10m35s to copy to UFS2 and 21m40s to copy to ZFS. 30GB of AVI files required 16m6s to copy to UFS2 and 1h2m39s to copy to ZFS. I used for tests FreeBSD 8.1R amd64. Amount of RAM on my machine is 6GB. Any tips? -- Regards, Serguey. ___ 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 -- Stefan Bethke s...@lassitu.de Fon +49 151 14070811 ___ 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: Degraded zpool cannot detach old/bad drive
No ideas whatsoever? On Tue, Oct 26, 2010 at 1:04 PM, Rumen Telbizov telbi...@gmail.com wrote: Hello everyone, After a few days of struggle with my degraded zpool on a backup server I decided to ask for help here or at least get some clues as to what might be wrong with it. Here's the current state of the zpool: # zpool status pool: tank state: DEGRADED status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://www.sun.com/msg/ZFS-8000-8A scrub: none requested config: NAME STATE READ WRITE CKSUM tank DEGRADED 0 0 0 raidz1 DEGRADED 0 0 0 spare DEGRADED 0 0 0 replacing DEGRADED 0 0 0 17307041822177798519 UNAVAIL 0 299 0 was /dev/gpt/disk-e1:s2 gpt/newdisk-e1:s2 ONLINE 0 0 0 gpt/disk-e2:s10 ONLINE 0 0 0 gpt/disk-e1:s3ONLINE 30 0 0 gpt/disk-e1:s4ONLINE 0 0 0 gpt/disk-e1:s5ONLINE 0 0 0 raidz1 ONLINE 0 0 0 gpt/disk-e1:s6ONLINE 0 0 0 gpt/disk-e1:s7ONLINE 0 0 0 gpt/disk-e1:s8ONLINE 0 0 0 gpt/disk-e1:s9ONLINE 0 0 0 raidz1 ONLINE 0 0 0 gpt/disk-e1:s10 ONLINE 0 0 0 gpt/disk-e1:s11 ONLINE 0 0 0 gpt/disk-e1:s12 ONLINE 0 0 0 gpt/disk-e1:s13 ONLINE 0 0 0 raidz1 DEGRADED 0 0 0 gpt/disk-e1:s14 ONLINE 0 0 0 gpt/disk-e1:s15 ONLINE 0 0 0 gpt/disk-e1:s16 ONLINE 0 0 0 spare DEGRADED 0 0 0 replacing DEGRADED 0 0 0 15258738282880603331 UNAVAIL 048 0 was /dev/gpt/disk-e1:s17 gpt/newdisk-e1:s17ONLINE 0 0 0 gpt/disk-e2:s11 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 gpt/disk-e1:s18 ONLINE 0 0 0 gpt/disk-e1:s19 ONLINE 0 0 0 gpt/disk-e1:s20 ONLINE 0 0 0 gpt/disk-e1:s21 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 gpt/disk-e1:s22 ONLINE 0 0 0 gpt/disk-e1:s23 ONLINE 0 0 0 gpt/disk-e2:s0ONLINE 0 0 0 gpt/disk-e2:s1ONLINE 0 0 0 raidz1 ONLINE 0 0 0 gpt/disk-e2:s2ONLINE 0 0 0 gpt/disk-e2:s3ONLINE 0 0 0 gpt/disk-e2:s4ONLINE 0 0 0 gpt/disk-e2:s5ONLINE 0 0 0 raidz1 ONLINE 0 0 0 gpt/disk-e2:s6ONLINE 0 0 0 gpt/disk-e2:s7ONLINE 0 0 0 gpt/disk-e2:s8ONLINE 0 0 0 gpt/disk-e2:s9ONLINE 0 0 0 spares gpt/disk-e2:s10 INUSE currently in use gpt/disk-e2:s11 INUSE currently in use gpt/disk-e1:s2 UNAVAIL cannot open gpt/newdisk-e1:s17 INUSE currently in use errors: 4 data errors, use '-v' for a list The problem is: after replacing the bad drives and resilvering the old/bad drives cannot be detached. The replace command didn't remove it automatically and manual detach fails. Here are some examples: # zpool detach tank 15258738282880603331 cannot detach 15258738282880603331: no valid replicas # zpool detach tank gpt/disk-e2:s11 cannot detach gpt/disk-e2:s11: no valid replicas # zpool detach tank gpt/newdisk-e1:s17 cannot detach gpt/newdisk-e1:s17: no valid replicas # zpool detach tank gpt/disk-e1:s17 cannot detach gpt/disk-e1:s17: no valid replicas Here's more information and history of events. This is a 36 disk
Re: Degraded zpool cannot detach old/bad drive
Are you interested in what's wrong or in how to fix it? If fixing is the priority, I'd boot from OpenSolaris live CD and would try importing the array there. Just make sure you don't upgrade ZFS to a version that is newer than the one FreeBSD supports. Opensolaris may be able to fix the array. Once it's done, export it, boot back to FreeBSD and re-import it. --Artem On Wed, Oct 27, 2010 at 4:22 PM, Rumen Telbizov telbi...@gmail.com wrote: No ideas whatsoever? On Tue, Oct 26, 2010 at 1:04 PM, Rumen Telbizov telbi...@gmail.com wrote: Hello everyone, After a few days of struggle with my degraded zpool on a backup server I decided to ask for help here or at least get some clues as to what might be wrong with it. Here's the current state of the zpool: # zpool status pool: tank state: DEGRADED status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://www.sun.com/msg/ZFS-8000-8A scrub: none requested config: NAME STATE READ WRITE CKSUM tank DEGRADED 0 0 0 raidz1 DEGRADED 0 0 0 spare DEGRADED 0 0 0 replacing DEGRADED 0 0 0 17307041822177798519 UNAVAIL 0 299 0 was /dev/gpt/disk-e1:s2 gpt/newdisk-e1:s2 ONLINE 0 0 0 gpt/disk-e2:s10 ONLINE 0 0 0 gpt/disk-e1:s3 ONLINE 30 0 0 gpt/disk-e1:s4 ONLINE 0 0 0 gpt/disk-e1:s5 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 gpt/disk-e1:s6 ONLINE 0 0 0 gpt/disk-e1:s7 ONLINE 0 0 0 gpt/disk-e1:s8 ONLINE 0 0 0 gpt/disk-e1:s9 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 gpt/disk-e1:s10 ONLINE 0 0 0 gpt/disk-e1:s11 ONLINE 0 0 0 gpt/disk-e1:s12 ONLINE 0 0 0 gpt/disk-e1:s13 ONLINE 0 0 0 raidz1 DEGRADED 0 0 0 gpt/disk-e1:s14 ONLINE 0 0 0 gpt/disk-e1:s15 ONLINE 0 0 0 gpt/disk-e1:s16 ONLINE 0 0 0 spare DEGRADED 0 0 0 replacing DEGRADED 0 0 0 15258738282880603331 UNAVAIL 0 48 0 was /dev/gpt/disk-e1:s17 gpt/newdisk-e1:s17 ONLINE 0 0 0 gpt/disk-e2:s11 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 gpt/disk-e1:s18 ONLINE 0 0 0 gpt/disk-e1:s19 ONLINE 0 0 0 gpt/disk-e1:s20 ONLINE 0 0 0 gpt/disk-e1:s21 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 gpt/disk-e1:s22 ONLINE 0 0 0 gpt/disk-e1:s23 ONLINE 0 0 0 gpt/disk-e2:s0 ONLINE 0 0 0 gpt/disk-e2:s1 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 gpt/disk-e2:s2 ONLINE 0 0 0 gpt/disk-e2:s3 ONLINE 0 0 0 gpt/disk-e2:s4 ONLINE 0 0 0 gpt/disk-e2:s5 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 gpt/disk-e2:s6 ONLINE 0 0 0 gpt/disk-e2:s7 ONLINE 0 0 0 gpt/disk-e2:s8 ONLINE 0 0 0 gpt/disk-e2:s9 ONLINE 0 0 0 spares gpt/disk-e2:s10 INUSE currently in use gpt/disk-e2:s11 INUSE currently in use gpt/disk-e1:s2 UNAVAIL cannot open gpt/newdisk-e1:s17 INUSE currently in use errors: 4 data errors, use '-v' for a list The problem is: after replacing the bad drives and resilvering the old/bad drives cannot be detached. The replace command didn't remove it automatically and manual detach fails. Here are
Re: Degraded zpool cannot detach old/bad drive
Thanks Artem, I am mainly concerned about fixing this immediate problem first and then if I can provide more information for the developers so that they look into this problem I'd be happy to. I'll try OpenSolaris live CD and see how it goes. Either way I'll report back here. Cheers, Rumen Telbizov On Wed, Oct 27, 2010 at 5:22 PM, Artem Belevich fbsdl...@src.cx wrote: Are you interested in what's wrong or in how to fix it? If fixing is the priority, I'd boot from OpenSolaris live CD and would try importing the array there. Just make sure you don't upgrade ZFS to a version that is newer than the one FreeBSD supports. Opensolaris may be able to fix the array. Once it's done, export it, boot back to FreeBSD and re-import it. --Artem On Wed, Oct 27, 2010 at 4:22 PM, Rumen Telbizov telbi...@gmail.com wrote: No ideas whatsoever? On Tue, Oct 26, 2010 at 1:04 PM, Rumen Telbizov telbi...@gmail.com wrote: Hello everyone, After a few days of struggle with my degraded zpool on a backup server I decided to ask for help here or at least get some clues as to what might be wrong with it. Here's the current state of the zpool: # zpool status pool: tank state: DEGRADED status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://www.sun.com/msg/ZFS-8000-8A scrub: none requested config: NAME STATE READ WRITE CKSUM tank DEGRADED 0 0 0 raidz1 DEGRADED 0 0 0 spare DEGRADED 0 0 0 replacing DEGRADED 0 0 0 17307041822177798519 UNAVAIL 0 299 0 was /dev/gpt/disk-e1:s2 gpt/newdisk-e1:s2 ONLINE 0 0 0 gpt/disk-e2:s10 ONLINE 0 0 0 gpt/disk-e1:s3ONLINE 30 0 0 gpt/disk-e1:s4ONLINE 0 0 0 gpt/disk-e1:s5ONLINE 0 0 0 raidz1 ONLINE 0 0 0 gpt/disk-e1:s6ONLINE 0 0 0 gpt/disk-e1:s7ONLINE 0 0 0 gpt/disk-e1:s8ONLINE 0 0 0 gpt/disk-e1:s9ONLINE 0 0 0 raidz1 ONLINE 0 0 0 gpt/disk-e1:s10 ONLINE 0 0 0 gpt/disk-e1:s11 ONLINE 0 0 0 gpt/disk-e1:s12 ONLINE 0 0 0 gpt/disk-e1:s13 ONLINE 0 0 0 raidz1 DEGRADED 0 0 0 gpt/disk-e1:s14 ONLINE 0 0 0 gpt/disk-e1:s15 ONLINE 0 0 0 gpt/disk-e1:s16 ONLINE 0 0 0 spare DEGRADED 0 0 0 replacing DEGRADED 0 0 0 15258738282880603331 UNAVAIL 048 0 was /dev/gpt/disk-e1:s17 gpt/newdisk-e1:s17ONLINE 0 0 0 gpt/disk-e2:s11 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 gpt/disk-e1:s18 ONLINE 0 0 0 gpt/disk-e1:s19 ONLINE 0 0 0 gpt/disk-e1:s20 ONLINE 0 0 0 gpt/disk-e1:s21 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 gpt/disk-e1:s22 ONLINE 0 0 0 gpt/disk-e1:s23 ONLINE 0 0 0 gpt/disk-e2:s0ONLINE 0 0 0 gpt/disk-e2:s1ONLINE 0 0 0 raidz1 ONLINE 0 0 0 gpt/disk-e2:s2ONLINE 0 0 0 gpt/disk-e2:s3ONLINE 0 0 0 gpt/disk-e2:s4ONLINE 0 0 0 gpt/disk-e2:s5ONLINE 0 0 0 raidz1 ONLINE 0 0 0 gpt/disk-e2:s6ONLINE 0 0 0 gpt/disk-e2:s7ONLINE 0 0 0 gpt/disk-e2:s8ONLINE 0 0 0 gpt/disk-e2:s9ONLINE 0 0 0 spares gpt/disk-e2:s10
