Porting FreeBSD to a new Architecture?
Hello, I'm looking for documentation that could possibly help me port FreeBSD to a new architecture. I'm mainly interested in how you guys did the xbox and amd64 ports. i.e. x86 instruction set. Thanks! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Changing Console Resolution - Vidcontrol
On 2007-Apr-03 14:27:00 -0300, JoaoBR [EMAIL PROTECTED] wrote: simply consider RH graphical boot in 1024x768 has a very professional look while Freebsd still looks like Gate's MsDos before selling it to IBM I don't understand why displaying a silly graphic whilst hiding the boot messages is professional. If you really need eye-candy to make your FreeBSD box look like it's running MS Windows, see splash(4) -- Peter Jeremy pgpdDT36PjJg7.pgp Description: PGP signature
Re: Porting FreeBSD to a new Architecture?
Hi Nikolas, On Wed, Apr 04, 2007 at 02:23:44AM -0500, Nikolas Britton wrote: I'm looking for documentation that could possibly help me port FreeBSD to a new architecture. I'm mainly interested in how you guys did the xbox and amd64 ports. i.e. x86 instruction set. I can answer the Xbox question for you... basically, what I did was get a good understanding of how the xbox internals worked (i.e. what the exact differences are between an ordinary PC and an Xbox). Based on this understanding, I patched the Xbox boot loader (Cromwell) so it could properly load FreeBSD ELF images. Once that was done, I worked my way up from the first piece of code executed (that is in i386/i386/locore.s). I crafted some assembly code which could control the Xbox LED's, and I used this to determine where the Xbox would crash... Once I got the initial machine-dependant stuff out of the way, I created a console driver so I could see what was going on (which I later on totally rewrote); and worked my way up from here... Expect a lot of painstaking debugging in the progress... Good luck! -- Rink P.W. Springer- http://rink.nu It is such a quiet thing, to fall. But yet a far more terrible thing, to admit it.- Darth Traya ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
NFS == lock reboot
# uname -a FreeBSD host.domain.tld 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan 26 16:27:14 PST 2007 Greetings, Does anyone know when NFS and friends will be working again? I haven't been able to /safely/ use it from 4.8 on. I remember some talk on the list sometime ago and then it seemed to be resolved, as the discussion ended. So I thought it was fixed. Seems not. :( My scenario; mount host off root: mount script exec'd follows... #!/bin/sh - mount -t nfs host.domain.tld:/ /host mount -t nfs host.domain.tld:/var /host/var confirm mount... # ls /host .snapCOPYRIGHTbin ... usrvartmp OK looks good... # cp /path/to/approx/10Mb/file /host/path/to/dest/dir/ Fatal double fault eis 0x0blah eiblah blah0x panic double fault no dump device defined rebooting in 15sec... Hmmm... that's not good. :( I can't remember all the ei* numbers between the Fatal and panic lines, BUT I /can/ reproduce this at will - I simply need to copy a file larger than a few k to a mounted host. Yes, this /does/ happen /every/ time. Any and all help with this will be /GREATLY/ appreciated. Thank you for all your time and consideration in this matter. --Chris -- panic: kernel trap (ignored) - FreeBSD 5.4-RELEASE-p12 (SMP - 900x2) Tue Mar 7 19:37:23 PST 2006 / ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
make buildworld error on am64
hi , sorry to bother you again, i'm trying updating my machine to 6.2STABLE, but during make buildworld the process stop with these error messages: -- stage 4.2: building libraries -- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE=amd64 GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp INSTALL=sh /usr/src/tools/install.sh PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make -f Makefile.inc1 DESTDIR=/usr/obj/usr/src/tmp -DNO_FSCHG -DNO_HTML -DNO_INFO -DNO_LINT -DNO_MAN -DNO_NLS -DNO_PROFILE libraries cd /usr/src; make -f Makefile.inc1 _startup_libs; make -f Makefile.inc1 _prebuild_libs; make -f Makefile.inc1 _generic_libs; === gnu/lib/csu (depend,all,install) make -f /usr/src/gnu/lib/csu/../../usr.bin/cc/cc_tools/Makefile MFILE=/usr/src/gnu/lib/csu/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/usr/src/gnu/lib/csu/../../../contrib/gcc tconfig.h echo '#ifndef GCC_TCONFIG_H' tconfig.h echo '#define GCC_TCONFIG_H' tconfig.h echo '#ifdef IN_GCC' tconfig.h echo '# include ansidecl.h'tconfig.h echo '#endif'tconfig.h echo '#define USED_FOR_TARGET' tconfig.h echo '#endif /* GCC_TCONFIG_H */'tconfig.h make -f /usr/src/gnu/lib/csu/../../usr.bin/cc/cc_tools/Makefile MFILE=/usr/src/gnu/lib/csu/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/usr/src/gnu/lib/csu/../../../contrib/gcc tm.h echo '#ifndef GCC_TM_H' tm.h echo '#define GCC_TM_H' tm.h echo '#ifdef IN_GCC' tm.h echo '#include i386/biarch64.h'tm.h echo '#include i386/i386.h'tm.h echo '#include i386/unix.h'tm.h echo '#include i386/att.h' tm.h echo '#include dbxelf.h' tm.h echo '#include elfos.h'tm.h echo '#include freebsd-native.h' tm.h echo '#include freebsd-spec.h' tm.h echo '#include freebsd.h' tm.h echo '#include i386/freebsd.h' tm.h echo '#include i386/x86-64.h' tm.h echo '#include i386/freebsd64.h' tm.h echo '#include freebsd64-fix.h'tm.h echo '#include defaults.h' tm.h echo '#if !defined GENERATOR_FILE !defined USED_FOR_TARGET' tm.h echo '# include insn-constants.h' tm.h echo '# include insn-flags.h' tm.h echo '#endif'tm.h echo '#endif'tm.h echo '#define EXTRA_MODES_FILE i386/i386-modes.def' tm.h echo '#endif /* GCC_TM_H */' tm.h rm -f .depend mkdep -f .depend -a -DCRT_BEGIN -DIN_GCC -DHAVE_LD_EH_FRAME_HDR -I/usr/src/gnu/lib/csu/../../../contrib/gcc/config -I/usr/src/gnu/lib/csu/../../../contrib/gcc -I. -I/usr/src/gnu/lib/csu/../../usr.bin/cc/cc_tools /usr/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c cc -O -pipe -march=amd64 -DIN_GCC -DHAVE_LD_EH_FRAME_HDR -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-omit-frame-pointer -fno-unit-at-a-time -I/usr/src/gnu/lib/csu/../../../contrib/gcc/config -I/usr/src/gnu/lib/csu/../../../contrib/gcc -I. -I/usr/src/gnu/lib/csu/../../usr.bin/cc/cc_tools -std=gnu89 -g0 -DCRT_BEGIN -c -o crtbegin.o /usr/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c /usr/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c:1: error: bad value (amd64) for -march= switch /usr/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c:1: error: bad value (amd64) for -mtune= switch *** Error code 1 Stop in /usr/src/gnu/lib/csu. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. the box was fresh install from 6.2RELEASE, and was build on am64 arch. it has 4Gigs RAM and amd64 X2 AM2 socket. could you tell me how to resolve this problem? TIA Zen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
sun x2100 gmirror problem
Hi, We're using gmirror on our sun fire x2100 and FreeBSD 6.1-p10. Some days ago I found this in the logs: Apr 1 02:12:05 x2100 kernel: ad6: WARNING - WRITE_DMA48 UDMA ICRC error (retrying request) LBA=612960533 Apr 1 02:12:05 x2100 kernel: ad6: FAILURE - WRITE_DMA48 status=51READY,DSC,ERROR error=10NID_NOT_FOUND LBA=612960533 Apr 1 02:12:05 x2100 kernel: GEOM_MIRROR: Request failed (error=5). ad6[WRITE(offset=313835792896, length=4096)] Apr 1 02:12:05 x2100 kernel: GEOM_MIRROR: Device gm0: provider ad6 disconnected. Normally it looks like a disk error, but I think our half year old disks (WD RE2) shouldn't fail after this short time. Of course they have moving parts so they MAY fail. :( Yesterday I tried to reinit the sata channel and insert the disk back into the mirror. I got this: Apr 3 23:00:32 x2100 kernel: GEOM_MIRROR: Device gm0: provider ad6 detected. Apr 3 23:00:32 x2100 kernel: GEOM_MIRROR: Device gm0: rebuilding provider ad6. Apr 3 23:00:36 x2100 kernel: ad6: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=245760 Apr 3 23:00:38 x2100 kernel: ad6: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=392576 Apr 3 23:00:38 x2100 kernel: ad6: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=392960 Apr 3 23:00:53 x2100 kernel: ad6: FAILURE - device detached After this, the disk disappeared from the sata channel completely. The wierd is that we used the onboard nvidia-raid and the very same error occured, but there was no report in the kernel the machine just don't asked for operating system. Later I found out that the disk was forgotten ~2 weeks before that reboot (data was ~2 week old on it). Otherwise that forgotten/failed disk was also half year old and was fine without a problem. Is there anybody who experienced something similar with SUN X2100 or any other servers running FreeBSD 6 and sata? Regards, Andras ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make buildworld error on am64
Niclas Zeising wrote: On 4/4/07, zen [EMAIL PROTECTED] wrote: hi , sorry to bother you again, i'm trying updating my machine to 6.2STABLE, [snip error log] the box was fresh install from 6.2RELEASE, and was build on am64 arch. it has 4Gigs RAM and amd64 X2 AM2 socket. could you tell me how to resolve this problem? TIA Zen What's in your /etc/make.conf? It seems to me you have set cputype to a faulty value... HTH! //Niclas this is my /etc/make.conf CFLAGS= -O -pipe NOPROFILE= true USA_RESIDENT= yes CPUTYPE=amd64 NO_PROFILE=yes TIA Zen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make buildworld error on am64
On 4/4/07, zen [EMAIL PROTECTED] wrote: Niclas Zeising wrote: On 4/4/07, zen [EMAIL PROTECTED] wrote: hi , sorry to bother you again, i'm trying updating my machine to 6.2STABLE, [snip error log] the box was fresh install from 6.2RELEASE, and was build on am64 arch. it has 4Gigs RAM and amd64 X2 AM2 socket. could you tell me how to resolve this problem? TIA Zen What's in your /etc/make.conf? It seems to me you have set cputype to a faulty value... HTH! //Niclas this is my /etc/make.conf CFLAGS= -O -pipe NOPROFILE= true USA_RESIDENT= yes CPUTYPE=amd64 NO_PROFILE=yes TIA Zen That explains why the build blowes up. Valid options for CPUTYPE are: # AMD64 architecture: opteron, athlon64, nocona, prescott, core2 Depending on your CPU. Also, be aware that it's best to add cputype as CPUTYPE?=, so makefiles can change the cpu-type if need be. Have a look at src/share/examples/etc/make.conf and make.conf(5) for further explanations and options to put in your make.conf. HTH! //Niclas -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make buildworld error on am64
On 4/4/07, zen [EMAIL PROTECTED] wrote: hi , sorry to bother you again, i'm trying updating my machine to 6.2STABLE, [snip error log] the box was fresh install from 6.2RELEASE, and was build on am64 arch. it has 4Gigs RAM and amd64 X2 AM2 socket. could you tell me how to resolve this problem? TIA Zen What's in your /etc/make.conf? It seems to me you have set cputype to a faulty value... HTH! //Niclas ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Debug question
Hi All, Forgive me if this question is off topic, i don't know what other mailing list would be good for this one. Suppose the following: I experience a hang and the system reboots. After this i'll look in /var/crash and find a nice core file. My swap is large enough to cover the whole memory and more so it should be okay. However, gdb kernel vmcore.0 tells me that vmcore.0 is not a core dump :-( Any hints? Regards, Mipam. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Debug question
Hi, On Wed, Apr 04, 2007 at 11:56:00AM +0200, Mipam wrote: My swap is large enough to cover the whole memory and more so it should be okay. However, gdb kernel vmcore.0 tells me that vmcore.0 is not a core dump :-( Try 'kgdb kernel -c vmcore.0'; more information can be found in the handbook, most notabilty: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-gdb.html Regards, -- Rink P.W. Springer- http://rink.nu It is such a quiet thing, to fall. But yet a far more terrible thing, to admit it.- Darth Traya ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Debug question
Thanks, when i do what you suggested i get: kgdb: bad namelist. Is the corefile unusuable? Regards, Mipam. On Wed, 4 Apr 2007, Rink Springer wrote: Hi, On Wed, Apr 04, 2007 at 11:56:00AM +0200, Mipam wrote: My swap is large enough to cover the whole memory and more so it should be okay. However, gdb kernel vmcore.0 tells me that vmcore.0 is not a core dump :-( Try 'kgdb kernel -c vmcore.0'; more information can be found in the handbook, most notabilty: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-gdb.html Regards, -- Rink P.W. Springer- http://rink.nu It is such a quiet thing, to fall. But yet a far more terrible thing, to admit it.- Darth Traya ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[releng_6 tinderbox] failure on i386/pc98
TB --- 2007-04-04 09:22:05 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2007-04-04 09:22:05 - starting RELENG_6 tinderbox run for i386/pc98 TB --- 2007-04-04 09:22:05 - cleaning the object tree TB --- 2007-04-04 09:22:29 - checking out the source tree TB --- 2007-04-04 09:22:29 - cd /tinderbox/RELENG_6/i386/pc98 TB --- 2007-04-04 09:22:29 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_6 src TB --- 2007-04-04 09:31:56 - building world (CFLAGS=-O2 -pipe) TB --- 2007-04-04 09:31:56 - cd /src TB --- 2007-04-04 09:31:56 - /usr/bin/make -B buildworld 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 stage 4.3: make dependencies stage 4.4: building everything TB --- 2007-04-04 10:32:36 - generating LINT kernel config TB --- 2007-04-04 10:32:36 - cd /src/sys/pc98/conf TB --- 2007-04-04 10:32:36 - /usr/bin/make -B LINT TB --- 2007-04-04 10:32:36 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-04-04 10:32:36 - cd /src TB --- 2007-04-04 10:32:36 - /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Wed Apr 4 10:32:36 UTC 2007 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] nexus.o(.text+0x8c0): In function `nexus_remap_msix': : undefined reference to `msix_remap' nexus.o(.text+0x8ed): In function `nexus_release_msix': : undefined reference to `msix_release' nexus.o(.text+0x926): In function `nexus_alloc_msi': : undefined reference to `msi_alloc' nexus.o(.text+0x980): In function `nexus_release_msi': : undefined reference to `msi_release' *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-04-04 10:44:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-04-04 10:44:07 - ERROR: failed to build lint kernel TB --- 2007-04-04 10:44:07 - tinderbox aborted TB --- 0.99 user 2.82 system 4922.59 real http://tinderbox.des.no/tinderbox-releng_6-RELENG_6-i386-pc98.full ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make buildworld error on am64
Ruslan Ermilov wrote: On Wed, Apr 04, 2007 at 05:00:09PM +0700, zen wrote: Niclas Zeising wrote: On 4/4/07, zen [EMAIL PROTECTED] wrote: hi , sorry to bother you again, i'm trying updating my machine to 6.2STABLE, [snip error log] the box was fresh install from 6.2RELEASE, and was build on am64 arch. it has 4Gigs RAM and amd64 X2 AM2 socket. could you tell me how to resolve this problem? TIA Zen What's in your /etc/make.conf? It seems to me you have set cputype to a faulty value... HTH! //Niclas this is my /etc/make.conf CFLAGS= -O -pipe NOPROFILE= true USA_RESIDENT= yes CPUTYPE=amd64 NO_PROFILE=yes amd64 is not a valid CPUTYPE; see /usr/share/examples/etc/make.conf for a list of supported CPU types and pick up any suitable value. Cheers, problem solve, i change the value of CPUTYPE to CPUTYPE?=k8, and hopefully everything will be ok.. Thanks All Regards Zen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make buildworld error on am64
On Wed, Apr 04, 2007 at 05:00:09PM +0700, zen wrote: Niclas Zeising wrote: On 4/4/07, zen [EMAIL PROTECTED] wrote: hi , sorry to bother you again, i'm trying updating my machine to 6.2STABLE, [snip error log] the box was fresh install from 6.2RELEASE, and was build on am64 arch. it has 4Gigs RAM and amd64 X2 AM2 socket. could you tell me how to resolve this problem? TIA Zen What's in your /etc/make.conf? It seems to me you have set cputype to a faulty value... HTH! //Niclas this is my /etc/make.conf CFLAGS= -O -pipe NOPROFILE= true USA_RESIDENT= yes CPUTYPE=amd64 NO_PROFILE=yes amd64 is not a valid CPUTYPE; see /usr/share/examples/etc/make.conf for a list of supported CPU types and pick up any suitable value. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpgQA6igbWuE.pgp Description: PGP signature
Re: NFS == lock reboot
Quoting Ruben van Staveren [EMAIL PROTECTED]: Chris H. wrote: # uname -a FreeBSD host.domain.tld 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan 26 16:27:14 PST 2007 Greetings, Does anyone know when NFS and friends will be working again? I haven't been able to /safely/ use it from 4.8 on. I remember some talk on the list sometime ago and then it seemed to be resolved, as the discussion ended. So I thought it was fixed. Seems not. :( # cp /path/to/approx/10Mb/file /host/path/to/dest/dir/ Fatal double fault eis 0x0blah eiblah blah0x panic double fault no dump device defined rebooting in 15sec... You might want to try to configure a dump device, or as a last resort, take a picture of the crash and put that on your site Greetings, and thank you for your reply. FWIW it was only 4 lines, each beginning with ei followed by their hex values. Like I said originally, I can crash it at will. If the ei lines make the difference, I can crash it and write them down. The values aren't that long. I hate to crash it, but it's crashed so many times while experimenting in an effort to find a way (KLUDGE) to get around it, I've got more salvaged inodes in lost+found than I have files on an entire FreeBSD install. Point being; if it /really/ makes the difference to have the ei values, I'll just crash it and record them to post here. It just seems that this /type/ of output would be an indicator to those in the know as to where I need to go about overcoming this - assuming it's on my end and not in the 6x i386/sys source. Thanks again. Hmmm... that's not good. :( I can't remember all the ei* numbers between the Fatal and panic lines, BUT I /can/ reproduce this at will - I simply need to copy a file larger than a few k to a mounted host. Yes, this /does/ happen /every/ time. Any and all help with this will be /GREATLY/ appreciated. Thank you for all your time and consideration in this matter. --Chris Regards, Ruben -- panic: kernel trap (ignored) - FreeBSD 5.4-RELEASE-p12 (SMP - 900x2) Tue Mar 7 19:37:23 PST 2006 / ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS == lock reboot
Chris H. wrote: # uname -a FreeBSD host.domain.tld 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan 26 16:27:14 PST 2007 Greetings, Does anyone know when NFS and friends will be working again? I haven't been able to /safely/ use it from 4.8 on. I remember some talk on the list sometime ago and then it seemed to be resolved, as the discussion ended. So I thought it was fixed. Seems not. :( # cp /path/to/approx/10Mb/file /host/path/to/dest/dir/ Fatal double fault eis 0x0blah eiblah blah0x panic double fault no dump device defined rebooting in 15sec... You might want to try to configure a dump device, or as a last resort, take a picture of the crash and put that on your site Hmmm... that's not good. :( I can't remember all the ei* numbers between the Fatal and panic lines, BUT I /can/ reproduce this at will - I simply need to copy a file larger than a few k to a mounted host. Yes, this /does/ happen /every/ time. Any and all help with this will be /GREATLY/ appreciated. Thank you for all your time and consideration in this matter. --Chris Regards, Ruben ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS == lock reboot
I have found that if I kill rpc.lockd on the NFS server, most of the NFS issues I have (including a similar lock-up on 6.1-RELEASE) go away. Just wanted to throw that out there. - Dave Rivers - Greetings, Does anyone know when NFS and friends will be working again? I haven't been able to /safely/ use it from 4.8 on. I remember some talk on the list sometime ago and then it seemed to be resolved, as the discussion ended. So I thought it was fixed. Seems not. :( My scenario; mount host off root: mount script exec'd follows... #!/bin/sh - mount -t nfs host.domain.tld:/ /host mount -t nfs host.domain.tld:/var /host/var confirm mount... # ls /host .snapCOPYRIGHTbin ... usrvartmp OK looks good... # cp /path/to/approx/10Mb/file /host/path/to/dest/dir/ Fatal double fault eis 0x0blah eiblah blah0x panic double fault no dump device defined rebooting in 15sec... Hmmm... that's not good. :( I can't remember all the ei* numbers between the Fatal and panic lines, BUT I /can/ reproduce this at will - I simply need to copy a file larger than a few k to a mounted host. Yes, this /does/ happen /every/ time. Any and all help with this will be /GREATLY/ appreciated. Thank you for all your time and consideration in this matter. --Chris -- panic: kernel trap (ignored) - FreeBSD 5.4-RELEASE-p12 (SMP - 900x2) Tue Mar 7 19:37:23 PST 2006 / ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS == lock reboot
Quoting Thomas David Rivers [EMAIL PROTECTED]: I have found that if I kill rpc.lockd on the NFS server, most of the NFS issues I have (including a similar lock-up on 6.1-RELEASE) go away. Ah hah! I wondered about this. Funny you mention it. The interesting thing was that my most problem boxen is this one here, and it is the /only/ one with: rpc_lockd_enable=YES rpc_statd_enable=YES in rc.conf I simply chose these in an effort to keep everything current and accurate. You don't happen to have any experiences keeping rpc.statd running? Thank you for taking the time to reply. --Chris Just wanted to throw that out there. - Dave Rivers - Greetings, Does anyone know when NFS and friends will be working again? I haven't been able to /safely/ use it from 4.8 on. I remember some talk on the list sometime ago and then it seemed to be resolved, as the discussion ended. So I thought it was fixed. Seems not. :( My scenario; mount host off root: mount script exec'd follows... #!/bin/sh - mount -t nfs host.domain.tld:/ /host mount -t nfs host.domain.tld:/var /host/var confirm mount... # ls /host .snapCOPYRIGHTbin ... usrvartmp OK looks good... # cp /path/to/approx/10Mb/file /host/path/to/dest/dir/ Fatal double fault eis 0x0blah eiblah blah0x panic double fault no dump device defined rebooting in 15sec... Hmmm... that's not good. :( I can't remember all the ei* numbers between the Fatal and panic lines, BUT I /can/ reproduce this at will - I simply need to copy a file larger than a few k to a mounted host. Yes, this /does/ happen /every/ time. Any and all help with this will be /GREATLY/ appreciated. Thank you for all your time and consideration in this matter. --Chris -- panic: kernel trap (ignored) - FreeBSD 5.4-RELEASE-p12 (SMP - 900x2) Tue Mar 7 19:37:23 PST 2006 / ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- panic: kernel trap (ignored) - FreeBSD 5.4-RELEASE-p12 (SMP - 900x2) Tue Mar 7 19:37:23 PST 2006 / ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS == lock reboot
Hi Chris, Well - the NFS server is 4.5-RELEASE - a rather old box. Everything worked fine when the shop was all 4.x boxes, but as soon as we put in a 5.x or 6.x box - the NFS clients on those (5.x/6.x) boxes locked up hard if rpc.lockd was running on the 4.5-RELEASE server. On 4.x, rpc.lockd doesn't start automatically - since, as I understand it, rpc.lockd had issues in that timeframe. But, one of the developers here turned it on hoping to get real locking for /var/mail. So - I thought my problem might simply be the old rpc.lockd implementation in 4.x, and I didn't worry about it (since 4.x is out-of-service anyway.) However, this sounded _so_ familiar - I thought I would pop-up and mumble something like a me too. rpc.statd isn't running on the 4.5 NFS server. - Dave Rivers - Quoting Thomas David Rivers [EMAIL PROTECTED]: I have found that if I kill rpc.lockd on the NFS server, most of the NFS issues I have (including a similar lock-up on 6.1-RELEASE) go away. Ah hah! I wondered about this. Funny you mention it. The interesting thing was that my most problem boxen is this one here, and it is the /only/ one with: rpc_lockd_enable=YES rpc_statd_enable=YES in rc.conf I simply chose these in an effort to keep everything current and accurate. You don't happen to have any experiences keeping rpc.statd running? Thank you for taking the time to reply. --Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sun Fire X2100 SATA problem [was - sun x2100 gmirror problem]
[EMAIL PROTECTED] wrote: Hi, We're using gmirror on our sun fire x2100 and FreeBSD 6.1-p10. Some days ago I found this in the logs: Apr 1 02:12:05 x2100 kernel: ad6: WARNING - WRITE_DMA48 UDMA ICRC error (retrying request) LBA=612960533 Apr 1 02:12:05 x2100 kernel: ad6: FAILURE - WRITE_DMA48 status=51READY,DSC,ERROR error=10NID_NOT_FOUND LBA=612960533 Apr 1 02:12:05 x2100 kernel: GEOM_MIRROR: Request failed (error=5). ad6[WRITE(offset=313835792896, length=4096)] Apr 1 02:12:05 x2100 kernel: GEOM_MIRROR: Device gm0: provider ad6 disconnected. Normally it looks like a disk error, but I think our half year old disks (WD RE2) shouldn't fail after this short time. Of course they have moving parts so they MAY fail. :( Yesterday I tried to reinit the sata channel and insert the disk back into the mirror. I got this: Apr 3 23:00:32 x2100 kernel: GEOM_MIRROR: Device gm0: provider ad6 detected. Apr 3 23:00:32 x2100 kernel: GEOM_MIRROR: Device gm0: rebuilding provider ad6. Apr 3 23:00:36 x2100 kernel: ad6: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=245760 Apr 3 23:00:38 x2100 kernel: ad6: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=392576 Apr 3 23:00:38 x2100 kernel: ad6: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=392960 Apr 3 23:00:53 x2100 kernel: ad6: FAILURE - device detached After this, the disk disappeared from the sata channel completely. The wierd is that we used the onboard nvidia-raid and the very same error occured, but there was no report in the kernel the machine just don't asked for operating system. Later I found out that the disk was forgotten ~2 weeks before that reboot (data was ~2 week old on it). Otherwise that forgotten/failed disk was also half year old and was fine without a problem. Is there anybody who experienced something similar with SUN X2100 or any other servers running FreeBSD 6 and sata? Regards, Andras Hi, I can confirm your problem. I have same problem on one X2100 but not on the others. Currenty I have 4 X2100 machines, but only one with this strange problem. The problem is not caused by HDD it self, I tried to replace it with brand new and same error appears after few days. May be there are some problems with cables / connectors or something on mainboard. I am well known by problems with SATA(n) disk drives problems / disappearing on this list and local (czech) mailing list. I had similar problems on ASUS boards with Intel chipsets... so in my point of view - there is something bad with SATA in general. I never had problem like this with old good ATA drives. I have not solution for this problem. Disk is OK after reboot for a few dasy or weeks... if there is somebody which can help with investigating this kind of problem, I'll be happy to cooperate. output of dmesg, smartctl, gmirror etc.: http://www.quip.cz/1/freebsd/sata-hdd-problems/2007-03-07_errors_ad6.txt Miroslav Lachman ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sun Fire X2100 SATA problem [was - sun x2100 gmirror problem]
On Sze, Április 4, 2007 3:21 pm, Miroslav Lachman wrote: [EMAIL PROTECTED] wrote: Hi, We're using gmirror on our sun fire x2100 and FreeBSD 6.1-p10. Some days ago I found this in the logs: Apr 1 02:12:05 x2100 kernel: ad6: WARNING - WRITE_DMA48 UDMA ICRC error (retrying request) LBA=612960533 Apr 1 02:12:05 x2100 kernel: ad6: FAILURE - WRITE_DMA48 status=51READY,DSC,ERROR error=10NID_NOT_FOUND LBA=612960533 Apr 1 02:12:05 x2100 kernel: GEOM_MIRROR: Request failed (error=5). ad6[WRITE(offset=313835792896, length=4096)] Apr 1 02:12:05 x2100 kernel: GEOM_MIRROR: Device gm0: provider ad6 disconnected. Normally it looks like a disk error, but I think our half year old disks (WD RE2) shouldn't fail after this short time. Of course they have moving parts so they MAY fail. :( Yesterday I tried to reinit the sata channel and insert the disk back into the mirror. I got this: Apr 3 23:00:32 x2100 kernel: GEOM_MIRROR: Device gm0: provider ad6 detected. Apr 3 23:00:32 x2100 kernel: GEOM_MIRROR: Device gm0: rebuilding provider ad6. Apr 3 23:00:36 x2100 kernel: ad6: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=245760 Apr 3 23:00:38 x2100 kernel: ad6: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=392576 Apr 3 23:00:38 x2100 kernel: ad6: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=392960 Apr 3 23:00:53 x2100 kernel: ad6: FAILURE - device detached After this, the disk disappeared from the sata channel completely. The wierd is that we used the onboard nvidia-raid and the very same error occured, but there was no report in the kernel the machine just don't asked for operating system. Later I found out that the disk was forgotten ~2 weeks before that reboot (data was ~2 week old on it). Otherwise that forgotten/failed disk was also half year old and was fine without a problem. Is there anybody who experienced something similar with SUN X2100 or any other servers running FreeBSD 6 and sata? Regards, Andras Hi, I can confirm your problem. I have same problem on one X2100 but not on the others. Currenty I have 4 X2100 machines, but only one with this strange problem. The problem is not caused by HDD it self, I tried to replace it with brand new and same error appears after few days. May be there are some problems with cables / connectors or something on mainboard. I am well known by problems with SATA(n) disk drives problems / disappearing on this list and local (czech) mailing list. I had similar problems on ASUS boards with Intel chipsets... so in my point of view - there is something bad with SATA in general. I never had problem like this with old good ATA drives. I have not solution for this problem. Disk is OK after reboot for a few dasy or weeks... if there is somebody which can help with investigating this kind of problem, I'll be happy to cooperate. output of dmesg, smartctl, gmirror etc.: http://www.quip.cz/1/freebsd/sata-hdd-problems/2007-03-07_errors_ad6.txt Miroslav Lachman Hi, May I ask that when did you buy that machine with the problem and the others? We bought ours February 2006. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS == lock reboot
Quoting Thomas David Rivers [EMAIL PROTECTED]: Hi Chris, Well - the NFS server is 4.5-RELEASE - a rather old box. Everything worked fine when the shop was all 4.x boxes, but as soon as we put in a 5.x or 6.x box - the NFS clients on those (5.x/6.x) boxes locked up hard if rpc.lockd was running on the 4.5-RELEASE server. On 4.x, rpc.lockd doesn't start automatically - since, as I understand it, rpc.lockd had issues in that timeframe. But, one of the developers here turned it on hoping to get real locking for /var/mail. So - I thought my problem might simply be the old rpc.lockd implementation in 4.x, and I didn't worry about it (since 4.x is out-of-service anyway.) However, this sounded _so_ familiar - I thought I would pop-up and mumble something like a me too. rpc.statd isn't running on the 4.5 NFS server. - Dave Rivers - Hello Dave, and thanks for responding. Alrighty then. Looks like it's time for a little more experimentation. I'm going to turn off both rpc.lockd and rpc.statd on this (and the others) and see if the NFS service(s) work a little more as intended. If it does, that'll be great. But doesn't cure an /apparently/ ailing NFS. I'll report back on my findings here. FWIW for anyone that might be interested; I am willing to make this boxen a guinie pig/lab rat in an effort to discover what might be wrong in the NFS family of services in FBSD. If interested, let me know what needs to be done. Thanks again for responding. --Chris Quoting Thomas David Rivers [EMAIL PROTECTED]: I have found that if I kill rpc.lockd on the NFS server, most of the NFS issues I have (including a similar lock-up on 6.1-RELEASE) go away. Ah hah! I wondered about this. Funny you mention it. The interesting thing was that my most problem boxen is this one here, and it is the /only/ one with: rpc_lockd_enable=YES rpc_statd_enable=YES in rc.conf I simply chose these in an effort to keep everything current and accurate. You don't happen to have any experiences keeping rpc.statd running? Thank you for taking the time to reply. --Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- panic: kernel trap (ignored) - FreeBSD 5.4-RELEASE-p12 (SMP - 900x2) Tue Mar 7 19:37:23 PST 2006 / ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Panic on reboot with gmirror+gjournal
Hi all, I have a setup on 6-STABLE from today with two identical disks in a gm0 provider and 3 gjournal providers on it: Geom name: gm0 State: COMPLETE Components: 2 Balance: round-robin Slice: 1 Flags: NONE GenID: 0 SyncID: 1 ID: 2763081532 Providers: 1. Name: mirror/gm0 Mediasize: 500107861504 (466G) Sectorsize: 512 Mode: r3w3e4 Consumers: 1. Name: ad5 Mediasize: 500107862016 (466G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: NONE GenID: 0 SyncID: 1 ID: 2315942152 2. Name: ad6 Mediasize: 500107862016 (466G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 1 Flags: NONE GenID: 0 SyncID: 1 ID: 3121293515 Geom name: gjournal 1524581050 ID: 1524581050 Providers: 1. Name: mirror/gm0f.journal Mediasize: 106300440064 (99G) Sectorsize: 512 Mode: r1w1e1 Consumers: 1. Name: mirror/gm0f Mediasize: 107374182400 (100G) Sectorsize: 512 Mode: r1w1e1 Jend: 107374181888 Jstart: 106300440064 Role: Data,Journal Geom name: gjournal 1230399956 ID: 1230399956 Providers: 1. Name: mirror/gm0g.journal Mediasize: 192199785984 (179G) Sectorsize: 512 Mode: r1w1e1 Consumers: 1. Name: mirror/gm0g Mediasize: 193273528320 (180G) Sectorsize: 512 Mode: r1w1e1 Jend: 193273527808 Jstart: 192199785984 Role: Data,Journal Geom name: gjournal 1616155040 ID: 1616155040 Providers: 1. Name: mirror/gm0h.journal Mediasize: 193061356032 (180G) Sectorsize: 512 Mode: r1w1e1 Consumers: 1. Name: mirror/gm0h Mediasize: 194135098368 (181G) Sectorsize: 512 Mode: r1w1e1 Jend: 194135097856 Jstart: 193061356032 Role: Data,Journal Everything works fine until I reboot. At the end of the shutdown I see the 3 journals being shut down, then gm0 being destroyed but then gjournal tries to do something more, which is probably wrong as all the consumers have disappeared: All buffers synced Uptime: 16m27s GEOM_JOURNAL: Shutting down geom gjournal 1616155040. GEOM_JOURNAL: Shutting down geom gjournal 1230399956. GEOM_JOURNAL: Shutting down geom gjournal 1524581050. GEOM_MIRROR: Device gm0: provider mirror/gm0 destroyed. GEOM_MIRROR: Device gm0 destroyed. GEOM_JOURNAL: Fatal trap 12: page fault while in kernel mode ... On manual reset, FS come up clean of course, so there is not much harm, but it would be better if I could fix that. -- bug ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS == lock reboot
Chris H. [EMAIL PROTECTED] wrote: Thomas David Rivers wrote: I have found that if I kill rpc.lockd on the NFS server, most of the NFS issues I have (including a similar lock-up on 6.1-RELEASE) go away. FWIW, I also had problems with running rpc.lockd and rpc.statd (no panics, though). If you don't need them (i.e. you don't need cross-machine locking), then don't use them. Use the -L flag to mount_nfs so at least local locking works. You don't happen to have any experiences keeping rpc.statd running? Basically, it doesn't make much sense to run one without the other. If you disable rpc.lockd, you can also safely disable rpc.statd. However, I don't think that your actual problem (lock-up and panics) is related to rpc.lockd or rpc.statd. It rather sounds like something else is wrong with your machine. NFS works perfectly fine for me, including copying huge files. You wrote that you had a lot of crashes that accumulated many files in lost+found. Well, maybe your filesystem was somehow damaged in the process. It is possible to damage file systems in a way that can lead to panics, and it's not necessarily detected and repaired by fsck. # cp /path/to/approx/10Mb/file /host/path/to/dest/dir/ Fatal double fault eis 0x0blah eiblah blah0x panic double fault no dump device defined You should try to setup a dump device, so you get a kernel crash dump next time. The crash dump can be used to find out where the crash occured -- and I bet it's not in the NFS code. See the Handbook for details on how to setup a dump device. By the way, does the problem also occur when copying the file to/from a memory disk, so no physical disk is involved? That way you would exclude the disk and the disk driver as potential causes. Similarly, try a loopback NFS mount (i.e. mount from 127.0.0.1) in order to exclude the network interface driver as a potential cause. If the problem still exists when copying a 10 MB file from a memory disk to a memory disk (same or other) via a localhost mount on the same machine, then it looks like the NFS code might be at fault. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd C++ is the only current language making COBOL look good. -- Bertrand Meyer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS == lock reboot
Quoting Oliver Fromme [EMAIL PROTECTED]: Chris H. [EMAIL PROTECTED] wrote: Thomas David Rivers wrote: I have found that if I kill rpc.lockd on the NFS server, most of the NFS issues I have (including a similar lock-up on 6.1-RELEASE) go away. FWIW, I also had problems with running rpc.lockd and rpc.statd (no panics, though). If you don't need them (i.e. you don't need cross-machine locking), then don't use them. Use the -L flag to mount_nfs so at least local locking works. You don't happen to have any experiences keeping rpc.statd running? Basically, it doesn't make much sense to run one without the other. If you disable rpc.lockd, you can also safely disable rpc.statd. However, I don't think that your actual problem (lock-up and panics) is related to rpc.lockd or rpc.statd. It rather sounds like something else is wrong with your machine. NFS works perfectly fine for me, including copying huge files. You wrote that you had a lot of crashes that accumulated many files in lost+found. Well, maybe your filesystem was somehow damaged in the process. It is possible to damage file systems in a way that can lead to panics, and it's not necessarily detected and repaired by fsck. Indeed. I /too/ considered this. However, I largely dismissed this as a possibility as most all of them are 0 length in size. The others are fragments of logs. I'm not /completely/ ruling this out though. # cp /path/to/approx/10Mb/file /host/path/to/dest/dir/ Fatal double fault eis 0x0blah eiblah blah0x panic double fault no dump device defined You should try to setup a dump device, so you get a kernel crash dump next time. The crash dump can be used to find out where the crash occured -- and I bet it's not in the NFS code. See the Handbook for details on how to setup a dump device. By the way, does the problem also occur when copying the file to/from a memory disk, so no physical disk is involved? That way you would exclude the disk and the disk driver as potential causes. Similarly, try a loopback NFS mount (i.e. mount from 127.0.0.1) in order to exclude the network interface driver as a potential cause. If the problem still exists when copying a 10 MB file from a memory disk to a memory disk (same or other) via a localhost mount on the same machine, then it looks like the NFS code might be at fault. Best regards Oliver All good advise. I'm going to /initially/ take the easy way out first (remove lockd/statd from rc.conf). As a quick experiment. Then I'll endevour to investigate further using your suggestions. Thank you very much for all your time and thoughtful answer. --Chris -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd C++ is the only current language making COBOL look good. -- Bertrand Meyer -- panic: kernel trap (ignored) - FreeBSD 5.4-RELEASE-p12 (SMP - 900x2) Tue Mar 7 19:37:23 PST 2006 / ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sun Fire X2100 SATA problem
Gót András wrote: On Sze, Április 4, 2007 3:21 pm, Miroslav Lachman wrote: [EMAIL PROTECTED] wrote: Hi, We're using gmirror on our sun fire x2100 and FreeBSD 6.1-p10. Some days ago I found this in the logs: Apr 1 02:12:05 x2100 kernel: ad6: WARNING - WRITE_DMA48 UDMA ICRC error (retrying request) LBA=612960533 Apr 1 02:12:05 x2100 kernel: ad6: FAILURE - WRITE_DMA48 status=51READY,DSC,ERROR error=10NID_NOT_FOUND LBA=612960533 Apr 1 02:12:05 x2100 kernel: GEOM_MIRROR: Request failed (error=5). ad6[WRITE(offset=313835792896, length=4096)] Apr 1 02:12:05 x2100 kernel: GEOM_MIRROR: Device gm0: provider ad6 disconnected. Normally it looks like a disk error, but I think our half year old disks (WD RE2) shouldn't fail after this short time. Of course they have moving parts so they MAY fail. :( Yesterday I tried to reinit the sata channel and insert the disk back into the mirror. I got this: Apr 3 23:00:32 x2100 kernel: GEOM_MIRROR: Device gm0: provider ad6 detected. Apr 3 23:00:32 x2100 kernel: GEOM_MIRROR: Device gm0: rebuilding provider ad6. Apr 3 23:00:36 x2100 kernel: ad6: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=245760 Apr 3 23:00:38 x2100 kernel: ad6: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=392576 Apr 3 23:00:38 x2100 kernel: ad6: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=392960 Apr 3 23:00:53 x2100 kernel: ad6: FAILURE - device detached After this, the disk disappeared from the sata channel completely. The wierd is that we used the onboard nvidia-raid and the very same error occured, but there was no report in the kernel the machine just don't asked for operating system. Later I found out that the disk was forgotten ~2 weeks before that reboot (data was ~2 week old on it). Otherwise that forgotten/failed disk was also half year old and was fine without a problem. Is there anybody who experienced something similar with SUN X2100 or any other servers running FreeBSD 6 and sata? Regards, Andras Hi, I can confirm your problem. I have same problem on one X2100 but not on the others. Currenty I have 4 X2100 machines, but only one with this strange problem. The problem is not caused by HDD it self, I tried to replace it with brand new and same error appears after few days. May be there are some problems with cables / connectors or something on mainboard. I am well known by problems with SATA(n) disk drives problems / disappearing on this list and local (czech) mailing list. I had similar problems on ASUS boards with Intel chipsets... so in my point of view - there is something bad with SATA in general. I never had problem like this with old good ATA drives. I have not solution for this problem. Disk is OK after reboot for a few dasy or weeks... if there is somebody which can help with investigating this kind of problem, I'll be happy to cooperate. output of dmesg, smartctl, gmirror etc.: http://www.quip.cz/1/freebsd/sata-hdd-problems/2007-03-07_errors_ad6.txt Miroslav Lachman Hi, May I ask that when did you buy that machine with the problem and the Machine with problems was bought at December 2006 (made at October 2006), first machine was bought at summer 2006, next to machines leased earlier at 2007 (I don't know when bought / made) Miroslav Lachman ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS == lock reboot
On Wed, Apr 04, 2007 at 09:09:39AM -0400, Thomas David Rivers wrote: Hi Chris, Well - the NFS server is 4.5-RELEASE - a rather old box. Everything worked fine when the shop was all 4.x boxes, but as soon as we put in a 5.x or 6.x box - the NFS clients on those (5.x/6.x) boxes locked up hard if rpc.lockd was running on the 4.5-RELEASE server. On 4.x, rpc.lockd doesn't start automatically - since, as I understand it, rpc.lockd had issues in that timeframe. But, one of the developers here turned it on hoping to get real locking for /var/mail. So - I thought my problem might simply be the old rpc.lockd implementation in 4.x, and I didn't worry about it (since 4.x is out-of-service anyway.) However, this sounded _so_ familiar - I thought I would pop-up and mumble something like a me too. rpc.statd isn't running on the 4.5 NFS server. AFAICR rpc.lockd was fine in 4.x, it just wasn't a real rpc.lockd. The issues are with the rewrite that came in 5.x to add real locking, which sort of works except when it doesn't. Kris pgpyMFkSAUX5H.pgp Description: PGP signature
Re: NFS == lock reboot
On Wed, Apr 04, 2007 at 01:43:46AM -0700, Chris H. wrote: # uname -a FreeBSD host.domain.tld 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan 26 16:27:14 PST 2007 Greetings, Does anyone know when NFS and friends will be working again? It works for the rest of us, so any problems you are seeing should be properly reported (this means you need a core dump + backtrace). However, since you have been having problems for so many years, but only on one machine, I would suspect hardware failure on your end. Kris pgp2DepqCEHvf.pgp Description: PGP signature
single user mode buildwerld failures
i didn't know what was happening when i dropped to single user mode i got all these different prompts and i didn't know how to answer the questions. i have posted information on experts exchange: http://www.experts-exchange.com/OS/Unix/BSD/FreeBSD/Q_22484972.html http://www.experts-exchange.com/OS/Unix/BSD/FreeBSD/Q_22483843.html http://www.experts-exchange.com/Software/System_Utilities/Diagnostics/Q_22470294.html currently, i feel i have found my /etc/passwd and restored it to the proper location, but i still can't log on to my computer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS == lock reboot
Quoting Kris Kennaway [EMAIL PROTECTED]: On Wed, Apr 04, 2007 at 01:43:46AM -0700, Chris H. wrote: # uname -a FreeBSD host.domain.tld 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan 26 16:27:14 PST 2007 Greetings, Does anyone know when NFS and friends will be working again? It works for the rest of us, Yea, except I remembered there being some discussion on the list regarding NFS 'round about the introduction of the 5.x branch. Which is about the same time things started getting strange on my end. I simply waited to upgrade any further until things quieted down on the list and then upgraded (to 6.2). so any problems you are seeing should be properly reported (this means you need a core dump + backtrace). Understood. I'll make the proper preperation(s) and copy a file to an NFS mount. Works every time. However, since you have been having problems for so many years, Only since moving from 4.8 to 5 a few mos. ago. but only on one machine, Actually on most of them. But only violently on the one I mentioned here. I would suspect hardware failure on your end. I wondered the same at first. So I first swaped out the video card for one that was a little slower and less inclined to be touchy. Rebuilt installed anything related... to no avail. So I bought a new MB, RAM, HD, video card. Built everything anew. Again, to no avail (it's now the one I'm mentioning here). I considered the install CD, but the MD5 matched, and my procedure is miminal (smallest possible) install reboot install cvsupwithoutgui cvsup src ports edit kernconf make buildworld make installkernel reboot -s mergemaster -p installworld mergemaster reboot. So I don't think the CD would be a factor. Being new hardware didn't seem to help either. Anyway, thank you for taking the time to respond. --Chris Kris -- panic: kernel trap (ignored) - FreeBSD 5.4-RELEASE-p12 (SMP - 900x2) Tue Mar 7 19:37:23 PST 2006 / ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: single user mode buildwerld failures
i don't know what all the prompts where because i was in single user mode. i need diagnostic advice There should be a backup of your old /etc dir here: /var/tmp/etc Boot in single user mode, do a mount -a and copy the backup passwd file to /etc This should enable you to login again. There is a but... There might have been changes made during the buildworld process, obviously, those are missing in the backup file. Make sure all your programs are running as expected... i found a passwd file in /var/tmp/etc and moved it to what i thought should be the correct place, but i still couldn't log in On Wed, 4 Apr 2007, doug wrote: On Wed, 4 Apr 2007, KAYVEN RIESE wrote: i didn't know what was happening when i dropped to single user mode i got all these different prompts and i didn't know how to answer the questions. i have posted information on experts exchange: http://www.experts-exchange.com/OS/Unix/BSD/FreeBSD/Q_22484972.html http://www.experts-exchange.com/OS/Unix/BSD/FreeBSD/Q_22483843.html http://www.experts-exchange.com/Software/System_Utilities/Diagnostics/Q_22470294.html currently, i feel i have found my /etc/passwd and restored it to the proper location, but i still can't log on to my computer ___ Post what happened here. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: single user mode buildwerld failures
install WORLD failed. usage message.. then cd /usr/src; make installwerld also failed. it said required audit group is missing.. see /usr/src/UPDATING i am going to reboot into single user mode and follow these instructions from /usr/src/UPDATING now: To rebuild everything and install it on the current system. --- # Note: sometimes if you are running current you gotta do more than # is listed here if you are upgrading from a really old current. make sure you have good level 0 dumps make buildworld make kernel KERNCONF=YOUR_KERNEL_HERE [1] reboot in single user [3] mergemaster -p [5] make installworld make delete-old mergemaster [4] reboot that failed. mergemaster -p complained that /var/tmp/temproot was a read only filesystem i tried a couple of options either involving deleting it or using it but nothing werked. i don't know what to do now. You did not fsck and mount in single-user mode. After fsck -p ; mount -a ; su - you will be able to use mergemaster and do installworld. okay i followed the directions better with fsck -p; mount -a; su - they didn't seem to do anything so i wasn't tripping. fsck -p looked like stuff that happened on bootup. On Wed, 4 Apr 2007, doug wrote: On Wed, 4 Apr 2007, KAYVEN RIESE wrote: i didn't know what was happening when i dropped to single user mode i got all these different prompts and i didn't know how to answer the questions. i have posted information on experts exchange: http://www.experts-exchange.com/OS/Unix/BSD/FreeBSD/Q_22484972.html http://www.experts-exchange.com/OS/Unix/BSD/FreeBSD/Q_22483843.html http://www.experts-exchange.com/Software/System_Utilities/Diagnostics/Q_22470294.html currently, i feel i have found my /etc/passwd and restored it to the proper location, but i still can't log on to my computer ___ Post what happened here. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: single user mode buildwerld failures
there were so many steps they didn't seem obvious.. i got halfway thru and realized i was in some prompt for mergemaster -p, or so i thought, so i started over. i had no idea what was happening. i can't log on now. /etc/passwd is gone. i used a freeBSD disk that is certainly old to go to a fixit shell but i didn't know what to do. i can go back to the fixit shell if somebody tells me what to do but i have to *#@ing walk over to kinkos now to get on the internet. On Wed, 4 Apr 2007, KAYVEN RIESE wrote: i don't know what all the prompts where because i was in single user mode. i need diagnostic advice There should be a backup of your old /etc dir here: /var/tmp/etc Boot in single user mode, do a mount -a and copy the backup passwd file to /etc This should enable you to login again. There is a but... There might have been changes made during the buildworld process, obviously, those are missing in the backup file. Make sure all your programs are running as expected... i found a passwd file in /var/tmp/etc and moved it to what i thought should be the correct place, but i still couldn't log in On Wed, 4 Apr 2007, doug wrote: On Wed, 4 Apr 2007, KAYVEN RIESE wrote: i didn't know what was happening when i dropped to single user mode i got all these different prompts and i didn't know how to answer the questions. i have posted information on experts exchange: http://www.experts-exchange.com/OS/Unix/BSD/FreeBSD/Q_22484972.html http://www.experts-exchange.com/OS/Unix/BSD/FreeBSD/Q_22483843.html http://www.experts-exchange.com/Software/System_Utilities/Diagnostics/Q_22470294.html currently, i feel i have found my /etc/passwd and restored it to the proper location, but i still can't log on to my computer ___ Post what happened here. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: single user mode buildwerld failures
On Wed, 4 Apr 2007, KAYVEN RIESE wrote: i didn't know what was happening when i dropped to single user mode i got all these different prompts and i didn't know how to answer the questions. i have posted information on experts exchange: http://www.experts-exchange.com/OS/Unix/BSD/FreeBSD/Q_22484972.html http://www.experts-exchange.com/OS/Unix/BSD/FreeBSD/Q_22483843.html http://www.experts-exchange.com/Software/System_Utilities/Diagnostics/Q_22470294.html currently, i feel i have found my /etc/passwd and restored it to the proper location, but i still can't log on to my computer ___ Post what happened here. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sunfire X2200 ipfw and bge issues
Paulius Bulotas wrote: Now any ideas on why they system reboots every time the ethernet cable is plugged in to the bge0 port? or why the nve ethernet ports are not recognized? I am getting an error the next time it reboots that says something like hyper transport sync flood error and I have to press F1 to get it to reboot. That error is from the BIOS I believe. about bge, try to boot FreeBSD and put these into /boot/loader.conf : hw.pci.enable_msi=0 hw.pci.enable_msix=0 These did seem to help at all. The system still reboots when a cable is plugged into the bge0 port. maybe those will help ;) I used these on x4100 when I had similar problems with em* . and about nve, try kldload nfe , not nve ;) I tried to put the nfe drive in but due to lack of knowledge on my part the kernel didn't recognize it when I tried to make buildkernel. Thanks for the help. LB ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Changing Console Resolution - Vidcontrol
On Wednesday 04 April 2007 00:05, you wrote: Console is not intended for everyday use! You should login to your FreeBSD box with ssh-client of your choise and from the OS of your choise (preferably from graphic mode). please stay on topic the question is not what one should or not but to hook into your talk, if there is a console it can be used as wanted 1024x768 is more than enough for 120x50 virtual terminals. may be for you, for me and lot of other users it is definitly not p.s. Or you just trolling? RH is rather professional, but definitely not because of graphics in console... :-\ don't try to be smart with me nobody said that RH is professional because of it's graphics in console I said that for example RH looks professional with the graphic boot they offer that is very easy to understand, look: A/ fits much more info on one screen B/ line wraps do not complicate orientation on screen both points are very usefull debugging any kind of problem or tailing logs -- João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: single user mode buildwerld failures
On 04/04/07, KAYVEN RIESE [EMAIL PROTECTED] wrote: there were so many steps they didn't seem obvious.. i got halfway thru and realized i was in some prompt for mergemaster -p, or so i thought, so i started over. i had no idea what was happening. i can't log on now. /etc/passwd is gone. i used a freeBSD disk that is certainly old to go to a fixit shell but i didn't know what to do. i can go back to the fixit shell if somebody tells me what to do but i have to *#@ing walk over to kinkos now to get on the internet. So firstly you should probably sit down and take a deep breath. Secondly, it appears that you messed up your system pretty badly, I'm not sure that it can be fixed. On the other hand, it just might be that you missed a few steps. For example, when you're in single user mode the root filesystem is mounted read only, which means that you can't write to it. Anything related to the upgrade process (installworld, mergemaster...) has to fail. Question is (sorry this isn't ment to sound harsch) if you read the manual carefully, because it describes the entire process pretty detailed. That is to say you have to read all the chapters, not only the beginning. For example it appears that you didn't remount the root filesystem read/writeable after you booted to single user mode. Passwords are not stored in /etc/passwd, there is /etc/pwd.db, /etc/master.passwd and /etc/spwd.db, too. All are required for the system to be fully functional. The latter two contain the passwords in encrypted form. You might want to try to restore these files in particular. BTW: Your mailer appears to be broken. Some of your postings are really difficult to read, it seems as if quoted postings aren't marked properly, for example with a . ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: No buffer space available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thiago ... What version of kernel did you end up going back to? - --On Wednesday, April 04, 2007 10:15:48 -0300 Marc G. Fournier [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm seeing the same effect (haven't tried older kernel, mind you) almost like clockwork, every 72 hours after reboot ... at least now I don't feel so crazy, knowing it isn't just me ... - --On Sunday, April 01, 2007 17:07:08 -0300 Thiago Esteves de Oliveira [EMAIL PROTECTED] wrote: I've tried to increase the kern.ipc.nmbclusters value but it worked only when I changed the kernel to an older one. netstat -m (Now it's working with the same values.) - 515/850/1365 mbufs in use (current/cache/total) 512/390/902/65024 mbuf clusters in use (current/cache/total/max) 512/243 mbuf+clusters out of packet secondary zone in use (current/cache) 0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/0 9k jumbo clusters in use (current/cache/total/max) 0/0/0/0 16k jumbo clusters in use (current/cache/total/max) 1152K/992K/2145K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 2759 requests for I/O initiated by sendfile 2982 calls to protocol drain routines Ethernet adapters - em0: Intel(R) PRO/1000 Network Connection Version - 6.0.5 port 0xec80-0xecbf m em 0xfebe-0xfebf irq 10 at device 4.0 on pci7 em0: Ethernet address: 00:04:23:c3:06:78 em0: [FAST] skc0: 3Com 3C940 Gigabit Ethernet port 0xe800-0xe8ff mem 0xfebd8000-0xfebdbfff irq 15 at device 6.0 on pci7 skc0: 3Com Gigabit NIC (3C2000) rev. (0x1) sk0: Marvell Semiconductor, Inc. Yukon on skc0 sk0: Ethernet address: 00:0a:5e:65:ad:c3 miibus0: MII bus on sk0 e1000phy0: Marvell 88E1000 Gigabit PHY on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto P.S.: I am using the FreeBSD/amd64. Brian A. Seklecki wrote: Show us netstat -m on the broken kernel? Show us your dmesg(8) for em(4). TIA, ~BAS On Fri, 2007-03-30 at 11:13 -0300, Thiago Esteves de Oliveira wrote: Hello, I've had a problem with one of my FreeBSD servers, the machine has stopped its network services and then sent these messages: -Mar 27 13:00:03 anubis dhcpd: send_packet: No buffer space available -Mar 27 13:00:26 anubis routed[431]: Send bcast sendto(em0, 146.164.92.255.520): No buffer space available The messages were repeated a lot of times before a temporary solution. I've changed the kernel(FreeBSD 6.2) to an older one(FreeBSD 6.1) and since then it's been working well. What happened? P.S.: I can give more informations if necessary. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFGE6UE4QvfyHIvDvMRAlutAJ0WzVTYq99hmx1km2mdXE7pdUC8IgCgt4O1 eG6kXgqHveumXjkL0t+Q8Q8= =sieE -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFGE/ZC4QvfyHIvDvMRAsWoAJwJpD8nCtG0iv5U6LY8ISyyDKxgegCg1eti SezStun7CLDA9pgfrp8GloM= =UwSU -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS == lock reboot
On Wed, Apr 04, 2007 at 09:46:37AM -0700, Chris H. wrote: Quoting Kris Kennaway [EMAIL PROTECTED]: On Wed, Apr 04, 2007 at 01:43:46AM -0700, Chris H. wrote: # uname -a FreeBSD host.domain.tld 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan 26 16:27:14 PST 2007 Greetings, Does anyone know when NFS and friends will be working again? It works for the rest of us, Yea, except I remembered there being some discussion on the list regarding NFS 'round about the introduction of the 5.x branch. Which is about the same time things started getting strange on my end. I simply waited to upgrade any further until things quieted down on the list and then upgraded (to 6.2). so any problems you are seeing should be properly reported (this means you need a core dump + backtrace). Understood. I'll make the proper preperation(s) and copy a file to an NFS mount. Works every time. OK, I look forward to your bug report. Kris pgpgDANguxeZ5.pgp Description: PGP signature
Re: Porting FreeBSD to a new Architecture?
On 4/4/07, Rink Springer [EMAIL PROTECTED] wrote: Hi Nikolas, On Wed, Apr 04, 2007 at 02:23:44AM -0500, Nikolas Britton wrote: I'm looking for documentation that could possibly help me port FreeBSD to a new architecture. I'm mainly interested in how you guys did the xbox and amd64 ports. i.e. x86 instruction set. I can answer the Xbox question for you... basically, what I did was get a good understanding of how the xbox internals worked (i.e. what the exact differences are between an ordinary PC and an Xbox). Based on this understanding, I patched the Xbox boot loader (Cromwell) so it could properly load FreeBSD ELF images. Once that was done, I worked my way up from the first piece of code executed (that is in i386/i386/locore.s). I crafted some assembly code which could control the Xbox LED's, and I used this to determine where the Xbox would crash... Once I got the initial machine-dependant stuff out of the way, I created a console driver so I could see what was going on (which I later on totally rewrote); and worked my way up from here... Expect a lot of painstaking debugging in the progress... Thanks! Can anyone explain how the /usr/src/sys/conf directory works? I'd like to get a better feel of how everything is laid out in sys but I can't find anything in the developer handbook or man hier. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Installing FreeBSD on AMD64 - system freezes during boot
Hi, all, I am trying to install FreeBSD 6.2 Stable on my machine (AMD X2 AM2 4200 64bits, Asus M2N SLI Deluxe, nVidia 7950GS, 1 HD IDE, 1 HD SATA2, 1 DVDRW), but FreeBSD freezes right after detecting my HDs. I do not see the install screen. Does anyone know how to fix this? Is there a boot option I can use to successfully install FreeBSD? There are Ubuntu and Frugalware in the other partitions running OK. Thanks in advance, Claudio. -- A mind that is stretched by a new experience can never go back to its old dimensions. - Oliver Wendell Holmes ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Installing FreeBSD on AMD64 - system freezes during boot
Cláudio Henrique wrote: Hi, all, I am trying to install FreeBSD 6.2 Stable on my machine (AMD X2 AM2 4200 64bits, Asus M2N SLI Deluxe, nVidia 7950GS, 1 HD IDE, 1 HD SATA2, 1 DVDRW), but FreeBSD freezes right after detecting my HDs. I do not see the install screen. Can you post the last few lines? Any special hardware, such as USB flash / card readers? signature.asc Description: OpenPGP digital signature
Re: Changing Console Resolution - Vidcontrol
On Wednesday 04 April 2007 04:49, Peter Jeremy wrote: On 2007-Apr-03 14:27:00 -0300, JoaoBR [EMAIL PROTECTED] wrote: simply consider RH graphical boot in 1024x768 has a very professional look while Freebsd still looks like Gate's MsDos before selling it to IBM I don't understand why displaying a silly graphic whilst hiding the boot messages is professional. If you really need eye-candy to make your FreeBSD box look like it's running MS Windows, see splash(4) uuuhf man, my example of RH's graphical boot is *not* about a picture and this wasn't at all a comparism to any graphics in picture form, you should pay more attention to the whole thread instead of junking in here this thread is about displaying *text console* in 1024x768 and so I compared RH 8x8 boot text to fbsd's 16x16 mode and it is not about professional looking even if it was one of the points as example, it is extremely useful to get more information on one screen and still more usefull not having linewraps and I do not even get why this is beeing fight because it is natural having bigger screens and smaller letter to see more at once, unless you have disabilities and need the big letters but that is another point of view -- João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Changing Console Resolution - Vidcontrol
On Wednesday 04 April 2007 19:35, [EMAIL PROTECTED] wrote: On 04/04/07, JoaoBR [EMAIL PROTECTED] wrote: don't try to be smart with me nobody said that RH is professional because of it's graphics in console I said that for example RH looks professional with the graphic boot they offer Don't try to play dumb with us. You implied that it was when you wrote: simply consider RH graphical boot in 1024x768 has a very professional look while Freebsd still looks like Gate's MsDos before selling it to IBM yeahh but did you read it really, all??? I guess not, at least it seems you didn't understood the sense, only a word and another and glued it together as you wanted in order to make some noise And both premises are patent nonsense, since they are both predicated on some bollocks notion of professionalism which likely started with the first school to sell MBAs via post. talk to the hand :) -- João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Changing Console Resolution - Vidcontrol
On 04/04/07, JoaoBR [EMAIL PROTECTED] wrote: On Wednesday 04 April 2007 00:05, you wrote: Console is not intended for everyday use! You should login to your FreeBSD box with ssh-client of your choise and from the OS of your choise (preferably from graphic mode). please stay on topic the question is not what one should or not but to hook into your talk, if there is a console it can be used as wanted Ther are always going to be limitations. If you are not writing the code you are not going to have very much control over those limitations. 1024x768 is more than enough for 120x50 virtual terminals. may be for you, for me and lot of other users it is definitly not Well, perhaps you have something wrong if you cannot run 120x50 at 1024x768? p.s. Or you just trolling? RH is rather professional, but definitely not because of graphics in console... :-\ don't try to be smart with me nobody said that RH is professional because of it's graphics in console I said that for example RH looks professional with the graphic boot they offer Don't try to play dumb with us. You implied that it was when you wrote: simply consider RH graphical boot in 1024x768 has a very professional look while Freebsd still looks like Gate's MsDos before selling it to IBM And both premises are patent nonsense, since they are both predicated on some bollocks notion of professionalism which likely started with the first school to sell MBAs via post. -- -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: single user mode buildwerld failures
Quoting [EMAIL PROTECTED]: Quoting Christian Walther [EMAIL PROTECTED]: On 04/04/07, KAYVEN RIESE [EMAIL PROTECTED] wrote: Secondly, it appears that you messed up your system pretty badly, I'm not sure that it can be fixed. On the other hand, it just might be that you missed a few steps. For example, when you're in single user mode the root filesystem is mounted read only, which means that you can't write to it. Anything related to the upgrade process (installworld, mergemaster...) has to fail. point of info.. my bad about not communicating correctly.. you are referring to the steps fsck -p and mount -a are you not? i went into single user mode one time without these steps and i think nothing happened. i was unable to accomplish the task it told me that the disk was not readable. i told this to [EMAIL PROTECTED] and he told me to include the steps. he told me something like maybe you will need mergemaster or something, so what i did was a hybrid between his advice and what it said in /usr/src/UPDATING. i did his make WORLD that seemed to do nothing, and did i believe /usr/src/make buildwerld oops. i just realized. you can't even read the stuff on experts-exchange, can you? i was following this advice: gheist:That's it! Cool! Your system does not yet have csup utility, so we will proceed with usable replacement installation. : cd /usr/ports Your system does not yet have csup utility, so we will proceed with usable replacement installation. : cd /usr/ports/*/cvsup-without-gui : make deinstall distclean ; make install clean : cd ; rehash : cvsup you should see help text of utility Now we should make decision of FreeBSD version to install 6.1-RELEASE - one you have RELENG_6_1 - yours with all security patches RELENG_6_2 - latest release with patched RELENG_6 - latest stable release which will become next release when time comes now create file called supfile with fillowing content: *default tag=RELENG_6 # replace .se. with your closest toplevel domain like .us. *default host=cvsup.se.freebsd.org *default prefix=/usr *default base=/usr/local/etc/cvsup *default release=cvs *default delete *default use-rel-suffix *default compress ports-all tag=. src-all # EndOfFile now create temporary directory for update temporary files: : mkdir -p /usr/local/etc/cvsup and now update! : cvsup supfile there should be output as updating your files commences/it will take long first time, but it will finish/. now that you are finished proceed to installing new kernel: : cd /usr/src/sys/i386/conf : config GENERIC : cd ../compile/GENERIC : make cleandepend ; make depend ; make make install if successful do far - type : shutdown -r now Now that you have rebooted check if all of your essential services are running... And check that uname -a output has changed to 6.2-RELEASE-p1 or similar Now you have good new kernel and can proceed to installing new world cd /usr/src ; make buildworld /this one takes long/ If this one succeeds you should reboot into single-user mode to replace all the files : shutdown -r now print out everything past this line at the boot menu type 4 - boot into single-user mode after kernel messages it asks for shell - default is fine check filesystems(can take long time after unclean shutdown): : fsck -p mount filesystems: : mount -a install default environment: : su - install WORLD: : cd /usr/src ; make installworld you may need to operate mergemaster at this point if install asks for it after successful installworld type: :reboot no need to print after this line that's how far i got. there seemed to be a discrepency with what i read in /usr/src/UPDATING i noted that here: btw.. i noted this: [EMAIL PROTECTED]/usr/ports/net/cvsup-without-gui]#make deinstall distclean; make install clean linking cvpasswd === Installing for cvsup-without-gui-16.1h_2 === cvsup-without-gui-16.1h_2 conflicts with installed package(s): cvsup-16.1h_2 They install files into the same place. Please remove them first with pkg_delete(1). *** Error code 1 Stop in /usr/ports/net/cvsup-without-gui. oh shoot. do i figger this out myself? They install files into the same place. Please remove them first with pkg_delete(1). *** Error code 1 Stop in /usr/ports/net/cvsup-without-gui. [EMAIL PROTECTED]/usr/ports/net/cvsup-without-gui]#pkg_delete cvsup-16.1h_2 and proceeded from that step. btw.. i have a PWD promt that shows where i am: # EndOfFile [EMAIL PROTECTED]/root]#cd /usr/src/sys/i386/conf [EMAIL PROTECTED]/usr/src/sys/i386/conf]#config GENERIC Kernel build directory is ../compile/GENERIC Don't forget to do ``make cleandepend; make depend'' [EMAIL PROTECTED]/usr/src/sys/i386/conf]#make cleandepend; make depend EndOfFile [EMAIL PROTECTED]/root]#cd
Re: single user mode buildwerld failures
Quoting [EMAIL PROTECTED]: Quoting Christian Walther [EMAIL PROTECTED]: On 04/04/07, KAYVEN RIESE [EMAIL PROTECTED] wrote: there were so many steps they didn't seem obvious.. i got halfway thru and realized i was in some prompt for mergemaster -p, or so i thought, so i started over. i had no idea what was happening. i can't log on now. /etc/passwd is gone. i used a freeBSD disk that is certainly old to go to a fixit shell but i didn't know what to do. i can go back to the fixit shell if somebody tells me what to do but i have to *#@ing walk over to kinkos now to get on the internet. So firstly you should probably sit down and take a deep breath. Secondly, it appears that you messed up your system pretty badly, I'm not sure that it can be fixed. On the other hand, it just might be that you missed a few steps. For example, when you're in single user mode the root filesystem is mounted read only, which means that you can't write to it. Anything related to the upgrade process (installworld, mergemaster...) has to fail. i looked at the /usr/src/UPDATING and what to do after the command mergemaster -p was not described. is there a better web page for that somewhere? i was also taking advice from an expert on experts-exchange both sources did not described the bizzare behavior i observed after simply invoking the command mergemaster -p both sources informed me to do that command followed by another command. i saw no advice telling me more details than that. if such a site exists, could i please have a direct relevant link? Question is (sorry this isn't ment to sound harsch) if you read the manual carefully, because it describes the entire process pretty detailed. That is to say you have to read all the chapters, not only the beginning. For example it appears that you didn't remount the root filesystem read/writeable after you booted to single user mode. i followed some instructions but nothing perpared me for the way my acted after the command mergemaster -p i did not get back the same prompt from which i invoked mergemaster -p from. it asked me a question that i fergot what it was. that was bad.. i know.. i could not cut and paste there. i could have maybe done mergemaster -p file.out but i didn't. oops. that was stupid. Passwords are not stored in /etc/passwd, there is /etc/pwd.db, /etc/master.passwd and /etc/spwd.db, too. All are required for the system to be fully functional. The latter two contain the passwords in encrypted form. You might want to try to restore these files in particular. okay.. /etc/passwd was in /var/tmp/etc/passwd, so the others will be similarly so? i can handle this. BTW: Your mailer appears to be broken. Some of your postings are really difficult to read, it seems as if quoted postings aren't marked properly, for example with a . sorry. i use pine. marks recursively who is saying what. i cut and pasted hurredly which i guess is stupid. it sounds like you are giving me good advice that i can easily follow. i will try that and get back to you. it might be more easy to look at the links i gave, but i posted a lot of makesplat that got that guy mad at me. you can scroll all the way to the bottom and see what the latest is maybe you can follow. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: No buffer space available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thiago ... I'm just curious here, but are you by any chance using geom at all? The only machine I have that seems to be affected like this (where netstat -m doesn't seem to indicate a problem with mbufs) is using gmirror ... the rest all use hardware RAID controllers ... Its a long shot, but so far, its the only one I seem to be able to draw :( - --On Sunday, April 01, 2007 17:07:08 -0300 Thiago Esteves de Oliveira [EMAIL PROTECTED] wrote: I've tried to increase the kern.ipc.nmbclusters value but it worked only when I changed the kernel to an older one. netstat -m (Now it's working with the same values.) - 515/850/1365 mbufs in use (current/cache/total) 512/390/902/65024 mbuf clusters in use (current/cache/total/max) 512/243 mbuf+clusters out of packet secondary zone in use (current/cache) 0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/0 9k jumbo clusters in use (current/cache/total/max) 0/0/0/0 16k jumbo clusters in use (current/cache/total/max) 1152K/992K/2145K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 2759 requests for I/O initiated by sendfile 2982 calls to protocol drain routines Ethernet adapters - em0: Intel(R) PRO/1000 Network Connection Version - 6.0.5 port 0xec80-0xecbf m em 0xfebe-0xfebf irq 10 at device 4.0 on pci7 em0: Ethernet address: 00:04:23:c3:06:78 em0: [FAST] skc0: 3Com 3C940 Gigabit Ethernet port 0xe800-0xe8ff mem 0xfebd8000-0xfebdbfff irq 15 at device 6.0 on pci7 skc0: 3Com Gigabit NIC (3C2000) rev. (0x1) sk0: Marvell Semiconductor, Inc. Yukon on skc0 sk0: Ethernet address: 00:0a:5e:65:ad:c3 miibus0: MII bus on sk0 e1000phy0: Marvell 88E1000 Gigabit PHY on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto P.S.: I am using the FreeBSD/amd64. Brian A. Seklecki wrote: Show us netstat -m on the broken kernel? Show us your dmesg(8) for em(4). TIA, ~BAS On Fri, 2007-03-30 at 11:13 -0300, Thiago Esteves de Oliveira wrote: Hello, I've had a problem with one of my FreeBSD servers, the machine has stopped its network services and then sent these messages: -Mar 27 13:00:03 anubis dhcpd: send_packet: No buffer space available -Mar 27 13:00:26 anubis routed[431]: Send bcast sendto(em0, 146.164.92.255.520): No buffer space available The messages were repeated a lot of times before a temporary solution. I've changed the kernel(FreeBSD 6.2) to an older one(FreeBSD 6.1) and since then it's been working well. What happened? P.S.: I can give more informations if necessary. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFGFE/S4QvfyHIvDvMRAvf2AJ94uFbAqplqtvTHeontpNT1FvzE7ACcDqYM 5EVfYDsLw++60NYugCOOwho= =+Wd7 -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpc.lockd brokenness (2)
On Thu, Apr 05, 2007 at 12:16:43PM +0900, Jun Kuriyama wrote: At Wed, 8 Mar 2006 19:57:22 -0500, Kris Kennaway wrote: No, no, you got me wrong. The pidfile is left locked after cron stopped running (with /etc/rc.d/cron stop). This behaviour must be wrong. OK, I misunderstood. The rc.d script will signal cron to kill it, which should be closing the file descriptors and causing rpc.lockd to release the lock. Perhaps this part is broken. OK, I tested this with daemon -p, and it indeed seems to be broken: haessal# daemon -p pid_file sleep 10 haessal# kill -KILL `cat pid_file` haessal# ps -p `cat pid_file` PID TT STAT TIME COMMAND haessal# lockf -t 0 pid_file echo Yay lockf: pid_file: already locked Interesting. I just do little investigation. Our daemon(8) locks a file before fork(2), which makes NFS lock registration with svid(PID) of daemon(8) process. When above sleep(1) killed, this process has another PID than daemon(8)'s, and request NFS unlock call with sleep(1)'s svid(PID). Our rpc.lockd(8) refuses this request because of svid unmatch. Which side should be fixed, daemon(8) and rpc.lockd(8)? You're replying to a year-old mail...but rpc.lockd is the broken thing, it assumes the pid that unlocks a file must be the pid that locks it. But this is false because in UNIX file descriptors may be passed around between processes, as in the above situation. Kris pgpVukq68TwV1.pgp Description: PGP signature
Re: rpc.lockd brokenness (2)
At Wed, 8 Mar 2006 19:57:22 -0500, Kris Kennaway wrote: No, no, you got me wrong. The pidfile is left locked after cron stopped running (with /etc/rc.d/cron stop). This behaviour must be wrong. OK, I misunderstood. The rc.d script will signal cron to kill it, which should be closing the file descriptors and causing rpc.lockd to release the lock. Perhaps this part is broken. OK, I tested this with daemon -p, and it indeed seems to be broken: haessal# daemon -p pid_file sleep 10 haessal# kill -KILL `cat pid_file` haessal# ps -p `cat pid_file` PID TT STAT TIME COMMAND haessal# lockf -t 0 pid_file echo Yay lockf: pid_file: already locked Interesting. I just do little investigation. Our daemon(8) locks a file before fork(2), which makes NFS lock registration with svid(PID) of daemon(8) process. When above sleep(1) killed, this process has another PID than daemon(8)'s, and request NFS unlock call with sleep(1)'s svid(PID). Our rpc.lockd(8) refuses this request because of svid unmatch. Which side should be fixed, daemon(8) and rpc.lockd(8)? -- Jun Kuriyama [EMAIL PROTECTED] // S2 Factory, Inc. [EMAIL PROTECTED] // IMG SRC, Inc. [EMAIL PROTECTED] // FreeBSD Project ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
