Re: 36 hours of freedom.
what the hell... Austin wrote: Now you can improve your sexual life! http://standards.mustajek.info/?balletxtvuytrigramszvpability Mathematics is the language with which God has written the universe. What's the difference between a boyfriend and a husband? About 30 pounds. Eternity is very long, especially towards the end. I have hardly ever known a mathematician who was capable of reasoning. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Kind regards, Jayton Garnett email: [EMAIL PROTECTED] Main : www.uberhacker.co.uk Test server: jayton.plus.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
howto set inet6 routes?
hello list, i try to setup a small ipv6 test network. however, it seems like i am too dump to setup my routes. when i bring up the interface for the first time, all is well and ping6 works just nicely: $ ifconfig rl1 rl1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=8VLAN_MTU inet6 3ffe:feed:face:cafe:0:2:2e39:f9 prefixlen 64 ether 00:02:2e:39:00:f9 media: Ethernet autoselect (10baseT/UTP) status: active $ netstat -rn -finet6 SNIP 3ffe:feed:face:cafe::/64 link#2 UC rl1 /SNAP so far, so good :) however, when i delete the route to the network 3ffe:feed:face:cafe::/64, (which is reachable via rl1 directly), i am not able to recreate it. the commands $ route add -inet6 -net 3ffe:feed:face:cafe::/64 -iface rl1 and $ route add -inet6 -net 3ffe:feed:face:cafe::/64 -interface rl1 yield only the following: $ netstat -rn -finet6 SNIP 3ffe:feed:face:cafe::/64 00:02:2e:39:00:f9 ULS rl1 /SNAP with which ping6 doesnt work, no packets are written onto the ether at all. so i guess my question is: what is the exact parameter syntax to route(8) which yields a netstat -rn -finet6 output with a link#NN target?? cheers/ thnx, /folkert /* _ _ * _|| _ * || [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: AMD64 + Nvidia Display Card
On Wednesday 13 July 2005 22:43, Brett Wildermoth wrote: On Thu, 14 Jul 2005 04:18 am, [EMAIL PROTECTED] wrote: On Wednesday 13 July 2005 10:26 am, Kenneth Culver wrote: Quoting Brett Wildermoth [EMAIL PROTECTED]: To all my fellow FreeBSD users, I assume I am not the only one who is in this predicament. I have just bought seven AMD 64s with NVIDIA PCI-X graphics. With 5.4 I can get everything bar the network and X to work, with 6.0 I can get the network to work also. However no matter what I do I can't get X to work. Why doesn't NVIDIA make a graphics driver for FreeBSD AMD64. They make one for Linux x86-64 and one for FreeBSD-x86. Perhaps would could all post a message on nvforum. I see some people already have. Perhaps NVIDIA think FreeBSD is just a hobby OS.. Last I heard, nvidia had no plans to make a FreeBSD amd64 driver. Just post that you're pissed about it like the rest of us are... maybe they'll reconsider. Not true. FreeBSD's kernel doesn't provide some things needed for an amd64 driver to be feasible. Like what what are these features? and if they are really important why aren't they on the cards to be included into FreeBSD.. There are a few missing VM features that any high-performance graphics card driver would require for decent performance with PCI Express. John is working on adding those features - have patience. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: tcp troughput weirdness
In the last episode (Jul 12), Danny Braniss said: [...] You might want to apply the patch at the bottom of http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/75122 ; without it, new connections get a random initial bandwidth. how far 'bottom' should i go? Search for Final patch follows. ok, did the patches (by hand, since the patch is a bit outdated), but it didn't help. the speed up is only realized when increasing the recvspace AND disabling inflight. danny ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: AMD64 + Nvidia Display Card
Brett Wildermoth wrote: On Thu, 14 Jul 2005 04:18 am, [EMAIL PROTECTED] wrote: On Wednesday 13 July 2005 10:26 am, Kenneth Culver wrote: Quoting Brett Wildermoth [EMAIL PROTECTED]: To all my fellow FreeBSD users, I assume I am not the only one who is in this predicament. I have just bought seven AMD 64s with NVIDIA PCI-X graphics. With 5.4 I can get everything bar the network and X to work, with 6.0 I can get the network to work also. However no matter what I do I can't get X to work. Why doesn't NVIDIA make a graphics driver for FreeBSD AMD64. They make one for Linux x86-64 and one for FreeBSD-x86. Perhaps would could all post a message on nvforum. I see some people already have. Perhaps NVIDIA think FreeBSD is just a hobby OS.. Last I heard, nvidia had no plans to make a FreeBSD amd64 driver. Just post that you're pissed about it like the rest of us are... maybe they'll reconsider. Not true. FreeBSD's kernel doesn't provide some things needed for an amd64 driver to be feasible. Like what what are these features? and if they are really important why aren't they on the cards to be included into FreeBSD.. I think this has come up before (multiple times...almost a FAQ-candidate IMO). AFAICR, the changes are not in CURRENT, yet, but there are plans to integrate them in the future. Can't you just run those AMD-boxes in i386-mode, for the time being? BTW: wouldn't it be good to note things like these in the errata-section in the handbook? The port itself is marked as ONLY_FOR_ARCHS= i386. But usually, by the time one reaches that stage, the hardware has already been bought ;-) Do all other Xorg-drivers work on AMD64? cheers, Rainer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: AMD64 + Nvidia Display Card
On Thu, 14 Jul 2005 07:17 pm, Rainer Duffner wrote: Brett Wildermoth wrote: On Thu, 14 Jul 2005 04:18 am, [EMAIL PROTECTED] wrote: On Wednesday 13 July 2005 10:26 am, Kenneth Culver wrote: Quoting Brett Wildermoth [EMAIL PROTECTED]: To all my fellow FreeBSD users, I assume I am not the only one who is in this predicament. I have just bought seven AMD 64s with NVIDIA PCI-X graphics. With 5.4 I can get everything bar the network and X to work, with 6.0 I can get the network to work also. However no matter what I do I can't get X to work. Why doesn't NVIDIA make a graphics driver for FreeBSD AMD64. They make one for Linux x86-64 and one for FreeBSD-x86. Perhaps would could all post a message on nvforum. I see some people already have. Perhaps NVIDIA think FreeBSD is just a hobby OS.. Last I heard, nvidia had no plans to make a FreeBSD amd64 driver. Just post that you're pissed about it like the rest of us are... maybe they'll reconsider. Not true. FreeBSD's kernel doesn't provide some things needed for an amd64 driver to be feasible. Like what what are these features? and if they are really important why aren't they on the cards to be included into FreeBSD.. I think this has come up before (multiple times...almost a FAQ-candidate IMO). AFAICR, the changes are not in CURRENT, yet, but there are plans to integrate them in the future. Can't you just run those AMD-boxes in i386-mode, for the time being? BTW: wouldn't it be good to note things like these in the errata-section in the handbook? The port itself is marked as ONLY_FOR_ARCHS= i386. But usually, by the time one reaches that stage, the hardware has already been bought ;-) Do all other Xorg-drivers work on AMD64? cheers, Rainer The card is too new to be supported by the nv 2D driver supplied in Xorg. Any card supported by the standard Xorg under FreeBSD x86 is also supported under FreeBSD x86-64 with the same capabilities. Brett -- --- Brett Wildermoth BEng(ME) MPhil Lecturer / PhD Student School of Microelectronic Engineering Faculty of Engineering and Info. Tech. Ph. +61 7 3875 5063, Fax. +61 7 3875 5384 Email. [EMAIL PROTECTED] --- pgpiR1czrE46P.pgp Description: PGP signature
Re: AMD64 + Nvidia Display Card
On Thu, 14 Jul 2005 07:07 pm, [EMAIL PROTECTED] wrote: On Wednesday 13 July 2005 22:43, Brett Wildermoth wrote: On Thu, 14 Jul 2005 04:18 am, [EMAIL PROTECTED] wrote: On Wednesday 13 July 2005 10:26 am, Kenneth Culver wrote: Quoting Brett Wildermoth [EMAIL PROTECTED]: To all my fellow FreeBSD users, I assume I am not the only one who is in this predicament. I have just bought seven AMD 64s with NVIDIA PCI-X graphics. With 5.4 I can get everything bar the network and X to work, with 6.0 I can get the network to work also. However no matter what I do I can't get X to work. Why doesn't NVIDIA make a graphics driver for FreeBSD AMD64. They make one for Linux x86-64 and one for FreeBSD-x86. Perhaps would could all post a message on nvforum. I see some people already have. Perhaps NVIDIA think FreeBSD is just a hobby OS.. Last I heard, nvidia had no plans to make a FreeBSD amd64 driver. Just post that you're pissed about it like the rest of us are... maybe they'll reconsider. Not true. FreeBSD's kernel doesn't provide some things needed for an amd64 driver to be feasible. Like what what are these features? and if they are really important why aren't they on the cards to be included into FreeBSD.. There are a few missing VM features that any high-performance graphics card driver would require for decent performance with PCI Express. John is working on adding those features - have patience. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] I guess these feature are provided in FreeBSD x86, as a NVIDIA graphics driver is available for FreeBSD x86. Is FreeBSD x86-64 VM subsystem different to FreeBSD x86. Is the VM subsystem that low-level? (Pardon my ignorance, have quite got around to reading the FreeBSD kernel book the publisher comped me yet) -- --- Brett Wildermoth BEng(ME) MPhil Lecturer / PhD Student School of Microelectronic Engineering Faculty of Engineering and Info. Tech. Ph. +61 7 3875 5063, Fax. +61 7 3875 5384 Email. [EMAIL PROTECTED] --- pgpvFb4ge9EJv.pgp Description: PGP signature
Re: howto set inet6 routes?
On Thu, Jul 14, 2005 at 09:07:54AM +0200, Folkert Saathoff wrote: $ ifconfig rl1 rl1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=8VLAN_MTU inet6 3ffe:feed:face:cafe:0:2:2e39:f9 prefixlen 64 ether 00:02:2e:39:00:f9 media: Ethernet autoselect (10baseT/UTP) status: active You don't seem to have a link local address on this interface (that's one starting fe80:). One should be automatically assigned to the interface when you bring it up. If you want your 6bone address to work, you'll also need a link-local address. David. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: AMD64 + Nvidia Display Card
On 14 Jul 2005, at 11:06, Brett Wildermoth wrote: On Thu, 14 Jul 2005 07:07 pm, [EMAIL PROTECTED] wrote: On Wednesday 13 July 2005 22:43, Brett Wildermoth wrote: On Thu, 14 Jul 2005 04:18 am, [EMAIL PROTECTED] wrote: On Wednesday 13 July 2005 10:26 am, Kenneth Culver wrote: Quoting Brett Wildermoth [EMAIL PROTECTED]: To all my fellow FreeBSD users, I assume I am not the only one who is in this predicament. I have just bought seven AMD 64s with NVIDIA PCI-X graphics. With 5.4 I can get everything bar the network and X to work, with 6.0 I can get the network to work also. However no matter what I do I can't get X to work. Why doesn't NVIDIA make a graphics driver for FreeBSD AMD64. They make one for Linux x86-64 and one for FreeBSD-x86. Perhaps would could all post a message on nvforum. I see some people already have. Perhaps NVIDIA think FreeBSD is just a hobby OS.. Last I heard, nvidia had no plans to make a FreeBSD amd64 driver. Just post that you're pissed about it like the rest of us are... maybe they'll reconsider. Not true. FreeBSD's kernel doesn't provide some things needed for an amd64 driver to be feasible. Like what what are these features? and if they are really important why aren't they on the cards to be included into FreeBSD.. There are a few missing VM features that any high-performance graphics card driver would require for decent performance with PCI Express. John is working on adding those features - have patience. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current- [EMAIL PROTECTED] I guess these feature are provided in FreeBSD x86, as a NVIDIA graphics driver is available for FreeBSD x86. Is FreeBSD x86-64 VM subsystem different to FreeBSD x86. Is the VM subsystem that low-level? (Pardon my ignorance, have quite got around to reading the FreeBSD kernel book the publisher comped me yet) Actually I think that the feature we are talking about (PAT) is relevant to both amd64 and i386. Proper support for PAT is required for decent PCI Express performance, as I understand it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
burncd: Device busy error.
I am trying to burn to my CD drive and I keep getting the same error, namely only wrote -1 of 37632 bytes: Device busy. I've been able to write to that dive from FreeBSD in the past but now, nada. The CD drive is definitely not in use. Any idea what is going on?... # dmesg | grep -i cd acd0: DVDR PIONEER DVD-RW DVR-107D/1.16 at ata1-master UDMA33 # uname -a FreeBSD gridlinked.neverness.org 5.4-STABLE FreeBSD 5.4-STABLE #1: Thu Jul 14 11:39:27 BST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MYKERNEL i386 # burncd -f /dev/acd0 audio test.wav fixate next writeable LBA 4720 writing from file test.wav size 84006 KB written this track 735 KB (0%) total 735 KB only wrote -1 of 37632 bytes: Device busy fixating CD, please wait.. [...hangs...] -- [EMAIL PROTECTED] -=*=- www.kierun.org PGP: 009D 7287 C4A7 FD4F 1680 06E4 F751 7006 9DE2 6318 pgp4Hf467QzUB.pgp Description: PGP signature
Re: burncd: Device busy error.
On 7/14/05, Yann Golanski [EMAIL PROTECTED] wrote: I am trying to burn to my CD drive and I keep getting the same error, namely only wrote -1 of 37632 bytes: Device busy. I've been able to write to that dive from FreeBSD in the past but now, nada. # burncd -f /dev/acd0 audio test.wav fixate next writeable LBA 4720 writing from file test.wav size 84006 KB written this track 735 KB (0%) total 735 KB only wrote -1 of 37632 bytes: Device busy fixating CD, please wait.. [...hangs...] This is well reported. Burncd has become rather dated, and is not keeping up with newer drives. DVD recorders poorly supported. Enable atapicam, and switch to cdrecord. It will work flawlessly. I use it myself with a Pioneer DVD, possibly the same model. I had the same problems with burncd. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GEOM_STRIPE Problems on Reboot
Drew Tomlinson wrote: GEOM_STRIPE: Device data created (id=896603271). GEOM_STRIPE: Disk da0d attached to data. GEOM_STRIPE: Disk da1d attached to data. GEOM_STRIPE: Device data activated. GEOM_STRIPE: Cannot add disk da0s1d to data (error=17). GEOM_STRIPE: Cannot add disk da1s1d to data (error=17). Mounting root from ufs:/dev/da0s1a Then the machine comes up in single user mode. At this point if I unload and reload geom_stripe, then the volume is created just fine and I can boot the system in full production mode. Any ideas on why I'm seeing this behavior? How can I fix it so that my machine reboots without incident? It looks like it's trying to add both disks again. I'd try to clean the metadata (gstripe clear from a fixit cdrom) and recreate it but I might be wrong. -- Giovanni P. Tirloni / [EMAIL PROTECTED] / PGP: 0xD0315C26 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Today's RELENG_5_4 and 'lock cmpxchgl'
On Wed, Jul 13, 2005 at 02:41:18PM -0400, Kris Kennaway wrote: Make sure you recompile any modules when activating INVARIANTS, or you'll get panics. Of course... make buildkernel and make installkernel do that for me... ;) Not if you are using third party port modules. Well, I'm not. ;-) It seems that 5.4-RELEASE-p* is safe btw. PR is http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/83375 You need to obtain the debugging traceback for the panic and include it in the PR. Added two crash traces, one for the open() variant, one for the close() variant. The -CURRENT traces are very different from these, but I don't have comconsole on the -CURRENT machine. Anyway, if people are having problems reproducing this, I'd like to know. I don't have a single RELENG_5 or 6 machine that withstands the 'screen-test'... Marc pgp6GCGmvXMLl.pgp Description: PGP signature
Re: GEOM_STRIPE Problems on Reboot
On 7/14/2005 5:30 AM Giovanni P. Tirloni wrote: Drew Tomlinson wrote: GEOM_STRIPE: Device data created (id=896603271). GEOM_STRIPE: Disk da0d attached to data. GEOM_STRIPE: Disk da1d attached to data. GEOM_STRIPE: Device data activated. GEOM_STRIPE: Cannot add disk da0s1d to data (error=17). GEOM_STRIPE: Cannot add disk da1s1d to data (error=17). Mounting root from ufs:/dev/da0s1a Then the machine comes up in single user mode. At this point if I unload and reload geom_stripe, then the volume is created just fine and I can boot the system in full production mode. Any ideas on why I'm seeing this behavior? How can I fix it so that my machine reboots without incident? It looks like it's trying to add both disks again. I'd try to clean the metadata (gstripe clear from a fixit cdrom) and recreate it but I might be wrong. Thanks for your reply. Yes, now I see that it *DOES* look like it's trying to add it twice. I haven't tried cleaning the metadata as you suggest because I don't want to lose data on the drive if I can avoid it. Would your suggestion wipe the drive? Also, I wonder if the metadata is really bad? It works just fine if I kldunload and kldload the module. I ask because I would think that if the metadata were bad, I would get this error every time I created the stripe. So where in the boot sequence is GEOM_STRIPE loaded? I'm starting to suspect it's being loaded twice. I have it in /boot/loader.conf which is where I thought it should be. Is there anywhere else to check? Thanks, Drew -- Visit The Alchemist's Warehouse Magic Tricks, DVDs, Videos, Books, More! http://www.alchemistswarehouse.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[SOLVED] Re: burncd: Device busy error.
Just in case anyone else has the same problem and wants a solution. 1- Recompile and install your kernel with the following options: device atapicam device ata device scbus device cd device pass 2- Go to your MP3 dir. 3- Converts spaces to underscores. for i in *.mp3; do mv $i `echo $i | tr ' ' '_'`; done 4- Converts .mp3 to .wav for i in *.mp3; do lame --decode $i `basename $i .mp3`.wav; done 5- Burn to CD... cdrecord -v dev=1,0,0 -dao -pad -useinfo *.wav This appears to work fine for me. If anyone has a better idea or can improve the process, please let me know. -- [EMAIL PROTECTED] -=*=- www.kierun.org PGP: 009D 7287 C4A7 FD4F 1680 06E4 F751 7006 9DE2 6318 pgp9YHXfqUfnT.pgp Description: PGP signature
Re: AMD64 + Nvidia Display Card [nv-driver]
The card is too new to be supported by the nv 2D driver supplied in Xorg. Any card supported by the standard Xorg under FreeBSD x86 is also supported under FreeBSD x86-64 with the same capabilities. Brett Hi, I actually had success using the nv-driver on my 64bit system with X.org for my ASUS GeForce 6600 (non-gt/pci-e), purchased a couple of weeks ago. There was actually a problem with xorg and pci-express cards, and that has been fixed now. Since it looks like nvidia dosn't really wan't to support amd64 (which pisses me off, but hey what can I do..?), I was forced to put this system onto gentoo-linux to get everything up on x86_64. My playground machine on linux, I can live with untill nvidia understands the real need for such a driver. Keep sending driver-requests to the nvidia forum, hopefully they will make the driver to stop us nag'ing on about it :P (Like stated in the forum, the people requesting it is probably below 1% of the users in need of this driver (or who will be)) Have a nice summer folks! Daniel Bond ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [SOLVED] Re: burncd: Device busy error.
On Thu, 14 Jul 2005 15:50:43 +0200, Yann Golanski [EMAIL PROTECTED] wrote: Just in case anyone else has the same problem and wants a solution. 1- Recompile and install your kernel with the following options: device atapicam device ata device scbus device cd device pass 2- Go to your MP3 dir. 3- Converts spaces to underscores. for i in *.mp3; do mv $i `echo $i | tr ' ' '_'`; done 4- Converts .mp3 to .wav for i in *.mp3; do lame --decode $i `basename $i .mp3`.wav; done 5- Burn to CD... cdrecord -v dev=1,0,0 -dao -pad -useinfo *.wav This appears to work fine for me. If anyone has a better idea or can improve the process, please let me know. Hello, With something like this script you can skip the step of replacing spaces to underscores. It is untested, so it might need some editing. #! /bin/sh find . -name *.mp3 | ( while read f do WAV=`basename $f .mp3`.wav lame --decode $f $WAV done ) -- Ronald Klop Amsterdam, The Netherlands ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
IBM xSeries 335 and FreeBSD 5 STABLE. SMP problem
Hello! I've got IBM xseries 335 with FreeBSD 5.4 installed, which hangs during boot without panic. If I boot it with hint.apic.0.disabled=1 - everything is ok, except the fact, that only one CPU is detected (from two ones). I tried kernels with SMP and without SMP - nothing changed, booting with apic kills OS. Please look at boot log below. It seems like mounting / from LSILogic 1030 Ultra4 Adapter (da0 over mpt0) results in hang. Cvsuping to STABLE gave no effect :-( If any information or tests are required, I'd be glad to provide it. Best Regards, Alexander Jul 14 11:24:02 ibm335 syslogd: kernel boot file is /boot/kernel/kernel Jul 14 11:24:02 ibm335 kernel: Copyright (c) 1992-2005 The FreeBSD Project. Jul 14 11:24:02 ibm335 kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jul 14 11:24:02 ibm335 kernel: The Regents of the University of California. All rights reserved. Jul 14 11:24:02 ibm335 kernel: FreeBSD 5.4-STABLE #1: Thu Jul 14 10:47:59 MSD 2005 Jul 14 11:24:02 ibm335 kernel: [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP_CUSTOM Jul 14 11:24:02 ibm335 kernel: MPTable: IBM ENSW TURQUIOSESMP Jul 14 11:24:02 ibm335 kernel: Timecounter i8254 frequency 1193182 Hz quality 0 Jul 14 11:24:02 ibm335 kernel: CPU: Intel(R) XEON(TM) CPU 2.40GHz (2392.25-MHz 686-class CPU) Jul 14 11:24:02 ibm335 kernel: Origin = GenuineIntel Id = 0xf24 Stepping = 4 Jul 14 11:24:02 ibm335 kernel: Features=0x3febfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM Jul 14 11:24:02 ibm335 kernel: Hyperthreading: 2 logical CPUs Jul 14 11:24:02 ibm335 kernel: real memory = 536850432 (511 MB) Jul 14 11:24:02 ibm335 kernel: avail memory = 519864320 (495 MB) Jul 14 11:24:02 ibm335 kernel: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs Jul 14 11:24:02 ibm335 kernel: cpu0 (BSP): APIC ID: 0 Jul 14 11:24:02 ibm335 kernel: cpu1 (AP): APIC ID: 6 Jul 14 11:24:02 ibm335 kernel: ioapic0: Assuming intbase of 0 Jul 14 11:24:02 ibm335 kernel: ioapic1: Assuming intbase of 16 Jul 14 11:24:02 ibm335 kernel: ioapic2: Assuming intbase of 32 Jul 14 11:24:02 ibm335 kernel: ioapic2 Version 1.1 irqs 32-47 on motherboard Jul 14 11:24:02 ibm335 kernel: ioapic1 Version 1.1 irqs 16-31 on motherboard Jul 14 11:24:02 ibm335 kernel: ioapic0 Version 1.1 irqs 0-15 on motherboard Jul 14 11:24:02 ibm335 kernel: npx0: math processor on motherboard Jul 14 11:24:02 ibm335 kernel: npx0: INT 16 interface Jul 14 11:24:02 ibm335 kernel: cpu0 on motherboard Jul 14 11:24:02 ibm335 kernel: cpu1 on motherboard Jul 14 11:24:02 ibm335 kernel: pcib0: MPTable Host-PCI bridge pcibus 0 on motherboard Jul 14 11:24:02 ibm335 kernel: pci0: PCI bus on pcib0 Jul 14 11:24:02 ibm335 kernel: pci0: display, VGA at device 1.0 (no driver attached) Jul 14 11:24:02 ibm335 kernel: atapci0: ServerWorks CSB5 UDMA100 controller port 0x700-0x70f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 15.1 on pci0 Jul 14 11:24:02 ibm335 kernel: ata0: channel #0 on atapci0 Jul 14 11:24:02 ibm335 kernel: ata1: channel #1 on atapci0 Jul 14 11:24:02 ibm335 kernel: ohci0: OHCI (generic) USB controller mem 0xfebfe000-0xfebfefff irq 11 at device 15.2 on pci0 Jul 14 11:24:02 ibm335 kernel: usb0: OHCI version 1.0, legacy support Jul 14 11:24:02 ibm335 kernel: usb0: OHCI (generic) USB controller on ohci0 Jul 14 11:24:02 ibm335 kernel: usb0: USB revision 1.0 Jul 14 11:24:02 ibm335 kernel: uhub0: (0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Jul 14 11:24:02 ibm335 kernel: uhub0: 4 ports with 4 removable, self powered Jul 14 11:24:02 ibm335 kernel: isab0: PCI-ISA bridge at device 15.3 on pci0 Jul 14 11:24:02 ibm335 kernel: isa0: ISA bus on isab0 Jul 14 11:24:02 ibm335 kernel: pcib3: ServerWorks host to PCI bridge pcibus 3 on motherboard Jul 14 11:24:02 ibm335 kernel: pci3: PCI bus on pcib3 Jul 14 11:24:02 ibm335 kernel: pcib1: MPTable Host-PCI bridge pcibus 1 on motherboard Jul 14 11:24:02 ibm335 kernel: pci1: PCI bus on pcib1 Jul 14 11:24:02 ibm335 kernel: mpt0: LSILogic 1030 Ultra4 Adapter port 0x2300-0x23ff mem 0xfbfe-0xfbfe,0xfbff-0xfbff irq 22 at device 1.0 on pci1 Jul 14 11:24:02 ibm335 kernel: pcib2: MPTable Host-PCI bridge pcibus 2 on motherboard Jul 14 11:24:02 ibm335 kernel: pci2: PCI bus on pcib2 Jul 14 11:24:02 ibm335 kernel: bge0: Broadcom BCM5703 Gigabit Ethernet, ASIC rev. 0x1002 mem 0xf9ff-0xf9ff irq 24 at device 1.0 on pci2 Jul 14 11:24:02 ibm335 kernel: miibus0: MII bus on bge0 Jul 14 11:24:02 ibm335 kernel: brgphy0: BCM5703 10/100/1000baseTX PHY on miibus0 Jul 14 11:24:02 ibm335 kernel: brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto Jul 14 11:24:02 ibm335 kernel: bge0: Ethernet address: 00:02:55:67:1e:58 Jul 14 11:24:02 ibm335 kernel: bge1: Broadcom BCM5703 Gigabit Ethernet, ASIC rev. 0x1002 mem 0xf9fe-0xf9fe irq 25 at device 2.0 on pci2 Jul 14 11:24:02 ibm335 kernel: miibus1: MII bus on
Re: GEOM_STRIPE Problems on Reboot
Drew Tomlinson wrote: So where in the boot sequence is GEOM_STRIPE loaded? I'm starting to suspect it's being loaded twice. I have it in /boot/loader.conf which is where I thought it should be. Is there anywhere else to check? If you have GEOM_STRIPE in kernel do you have to load it from loader.conf? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IBM xSeries 335 and FreeBSD 5 STABLE. SMP problem
On 7/14/05, Alexander Markov [EMAIL PROTECTED] wrote: Hello! I've got IBM xseries 335 with FreeBSD 5.4 installed, which hangs during boot without panic. If I boot it with hint.apic.0.disabled=1 - everything is ok, except the fact, that only one CPU is detected (from two ones). I tried kernels with SMP and without SMP - nothing changed, booting with apic kills OS. Please look at boot log below. It seems like mounting / from LSILogic 1030 Ultra4 Adapter (da0 over mpt0) results in hang. Cvsuping to STABLE gave no effect :-( If any information or tests are required, I'd be glad to provide it. Hello, If you unload kernel and load it again at boot manually, can 335 boot? I have one 336 with 5.4 that must use this trick to boot, otherwise it hangs after ipfw2 initialized. On the other hand, I have 3 335 installed with 5.4 running SMP smoothly. Regards, Rong-En Fan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GEOM_STRIPE Problems on Reboot
On 7/14/2005 7:57 AM Pertti Kosunen wrote: Drew Tomlinson wrote: So where in the boot sequence is GEOM_STRIPE loaded? I'm starting to suspect it's being loaded twice. I have it in /boot/loader.conf which is where I thought it should be. Is there anywhere else to check? If you have GEOM_STRIPE in kernel do you have to load it from loader.conf? No. I have tried it both ways. Compiled in kernel and *NOT* in loader.conf. And *NOT* in kernel and load geom_stripe.ko from loader.conf. Same error either way. The only exception is that when GEOM_STRIPE is compiled in kernel, I can't (obviously) use the kldunload/kldload workaround to make the stripe accessible.. I have also tried removing the line that loads the module from loader.conf and *NOT* having GEOM_STRIPE compiled in the kernel. I wanted to see if GEOM_STRIPE still got loaded to test Giovanni Tirloni's theory that the module was being loaded twice. GEOM_STRIPE was not loaded when removed from loader.conf (as expected). So I'm still stuck. Any other ideas? Thanks for your help. I'll try anything at this point. :) Drew -- Visit The Alchemist's Warehouse Magic Tricks, DVDs, Videos, Books, More! http://www.alchemistswarehouse.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Today's RELENG_5_4 and 'lock cmpxchgl'
On Thu, Jul 14, 2005 at 03:05:20PM +0200, Marc Olzheim wrote: You need to obtain the debugging traceback for the panic and include it in the PR. Added two crash traces, one for the open() variant, one for the close() variant. The -CURRENT traces are very different from these, but I don't have comconsole on the -CURRENT machine. Thanks. Anyway, if people are having problems reproducing this, I'd like to know. I don't have a single RELENG_5 or 6 machine that withstands the 'screen-test'... This will hopefully be very useful in investigating and developing a fix for the problem, at least on 6.0 (others have speculated that the problem may be too difficult to fix in the 5.x branch). Kris pgputvNEkZdcV.pgp Description: PGP signature
Q: Looking for a recommendation for hardware RAID cards and FreeBSD
Greetings, I am looking at purchasing a 3ware SATA 8006-2LP RAID (SATA) controllers for a servers running FreeBSD 5.4-stable. Is anyone out there using a SATA 3ware RAID controller card on FreeBSD and would be willing share their experiences, good, bad, or otherwise? 3ware has done well by me with my Linux boxes, but I am willing to consider other vendors if they have a better product. Thanks, John H. Nyhuis Sr. Computer Specialist Dept. of Pediatrics HS RR349B, Box 356320 University of Washington Desk: (206)-685-3884 [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
dangerous situation with shutdown process
Hello, everybody! I have found unusual and dangerous situation with shutdown process: I did a copy of 200 GB data on the 870 GB partition (softupdates is enabled) by cp command. It took a lot of time when I did umount for this partition exactly after cp, but procedure finished correctly. In case, if I did “shutdown –h(r)”, also exactly after cp, the shutdown procedure waited for “sync” (umounting of the file system) but sync process was terminated by timeout, and fsck checked and did correction of the file system after boot. System 5.4-stable, RAM 4GB, processor P-IV 3GHz. How can I fix it on my system? -- Anatoliy Dmytriyev [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: dangerous situation with shutdown process
Date: Thu, 14 Jul 2005 20:38:15 +0200 From: Anatoliy Dmytriyev [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Hello, everybody! I have found unusual and dangerous situation with shutdown process: I did a copy of 200 GB data on the 870 GB partition (softupdates is enabled) by cp command. It took a lot of time when I did umount for this partition exactly after cp, but procedure finished correctly. In case, if I did âshutdown âh(r)â, also exactly after cp, the shutdown procedure waited for âsyncâ (umounting of the file system) but sync process was terminated by timeout, and fsck checked and did correction of the file system after boot. System 5.4-stable, RAM 4GB, processor P-IV 3GHz. How can I fix it on my system? SCSI or ATA? If it's ATA, turn off write cache with (atacontrol(8) or the sysctl. The problem is that disks lie about whether they have actually written data. If the power goes off before the data is in cache, it's lost. I am not sure if write-cache can be turned off on SCSI, but SCSI drives seem less likely to lie about when the data is actually flushed to the drive. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
On Thu, Jul 14, 2005 at 12:14:49PM -0700, Kevin Oberman wrote.. Date: Thu, 14 Jul 2005 20:38:15 +0200 From: Anatoliy Dmytriyev [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Hello, everybody! I have found unusual and dangerous situation with shutdown process: I did a copy of 200 GB data on the 870 GB partition (softupdates is enabled) by cp command. It took a lot of time when I did umount for this partition exactly after cp, but procedure finished correctly. In case, if I did âshutdown âh(r)â, also exactly after cp, the shutdown procedure waited for âsyncâ (umounting of the file system) but sync process was terminated by timeout, and fsck checked and did correction of the file system after boot. System 5.4-stable, RAM 4GB, processor P-IV 3GHz. How can I fix it on my system? SCSI or ATA? If it's ATA, turn off write cache with (atacontrol(8) or the sysctl. The problem is that disks lie about whether they have actually written data. If the power goes off before the data is in cache, it's lost. I am not sure if write-cache can be turned off on SCSI, but SCSI drives seem less likely to lie about when the data is actually flushed to the drive. At least you can set FUA if you want to force the data onto the platter. -- Wilko Bulte [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: dangerous situation with shutdown process
Kevin Oberman wrote: SCSI or ATA? If it's ATA, turn off write cache with (atacontrol(8) or the sysctl. The problem is that disks lie about whether they have actually written data. If the power goes off before the data is in cache, it's lost. I am not sure if write-cache can be turned off on SCSI, but SCSI drives seem less likely to lie about when the data is actually flushed to the drive. SCSI, Adaptec 2110S -- Anatoliy Dmytriyev [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: dangerous situation with shutdown process
Kevin Oberman wrote: How can I fix it on my system? SCSI or ATA? If it's ATA, turn off write cache with (atacontrol(8) or the sysctl. You do NOT want to do that. Not only will performance drop brutally (example: drop to 1/5th of normal write speed for sequential writes, probably worse for random writes) but it will also significantly reduce the lifetime of your disk. Modern disks are designed to be used with the write-back cache enabled, so don't turn it off. The problem is that disks lie about whether they have actually written data. If the power goes off before the data is in cache, it's lost. No, the problem is that FreeBSD doesn't implement request barriers and that softupdates is flawed by design and seemingly could not make use of them, even if they were available (because, as I understand it, it relies on a total ordering of all writes, unlike the partial ordering necessary for a journalled fs). Until a journalled fs that uses write request barriers is available for FreeBSD, you better had a reliable UPS. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
On Thu, Jul 14, 2005 at 09:52:53PM +0200, Matthias Buelow wrote: Kevin Oberman wrote: The problem is that disks lie about whether they have actually written data. If the power goes off before the data is in cache, it's lost. No, the problem is that FreeBSD doesn't implement request barriers and that softupdates is flawed by design and seemingly could not make use of them, even if they were available (because, as I understand it, it relies on a total ordering of all writes, unlike the partial ordering necessary for a journalled fs). Until a journalled fs that uses write request barriers is available for FreeBSD, you better had a reliable UPS. How do OS-level request barriers help if the disk reorders pending writes in its cache? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
softupdates is perfectly safe with SCSI. its well known that ide and sata w/wo ncq fails to provide suitable semantics for softupdates however, journaling fairs no better, and request barriers do nothing to solve the problem. Request Barriers under linux exist to prevent the low level kernel block device layer from reordering write operations from the upper file system layers. Request Barriers consist of nothing more than tagging internal queues within the Linux kernel itself. They do nothing to resolve the underlying failures of the hardware to provide proper semantics to the block device layer. but, Request Barriers are ultimately useless. They can't resolve the underlying problems with ide/sata and there are already exposed semantics for scsi. if you absolutely must use sata and have reliable writes, make use of sata with battery-backed raid controller. On Thu, 14 Jul 2005, Matthias Buelow wrote: Kevin Oberman wrote: How can I fix it on my system? SCSI or ATA? If it's ATA, turn off write cache with (atacontrol(8) or the sysctl. You do NOT want to do that. Not only will performance drop brutally (example: drop to 1/5th of normal write speed for sequential writes, probably worse for random writes) but it will also significantly reduce the lifetime of your disk. Modern disks are designed to be used with the write-back cache enabled, so don't turn it off. The problem is that disks lie about whether they have actually written data. If the power goes off before the data is in cache, it's lost. No, the problem is that FreeBSD doesn't implement request barriers and that softupdates is flawed by design and seemingly could not make use of them, even if they were available (because, as I understand it, it relies on a total ordering of all writes, unlike the partial ordering necessary for a journalled fs). Until a journalled fs that uses write request barriers is available for FreeBSD, you better had a reliable UPS. mkb. ___ 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: dangerous situation with shutdown process
At 15:19 7/14/2005, Wilko Bulte wrote: On Thu, Jul 14, 2005 at 12:14:49PM -0700, Kevin Oberman wrote.. Date: Thu, 14 Jul 2005 20:38:15 +0200 From: Anatoliy Dmytriyev [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Hello, everybody! I have found unusual and dangerous situation with shutdown process: I did a copy of 200 GB data on the 870 GB partition (softupdates is enabled) by cp command. It took a lot of time when I did umount for this partition exactly after cp, but procedure finished correctly. In case, if I did âshutdown âh(r)â, also exactly after cp, the shutdown procedure waited for âsyncâ (umounting of the file system) but sync process was terminated by timeout, and fsck checked and did correction of the file system after boot. System 5.4-stable, RAM 4GB, processor P-IV 3GHz. How can I fix it on my system? The funny thing about all the replies here.. is that this guy is not saying that sync doesn't work. He's saying that the timeout built into shutdown causes it to *terminate* the sync forcibly before it's done, and then reboot. All finger pointing about IDE, SCSI, softupdates, and journals aside.. I think all he wants/needs is a way to increase that timer. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
David Sze wrote: Until a journalled fs that uses write request barriers is available for FreeBSD, you better had a reliable UPS. How do OS-level request barriers help if the disk reorders pending writes in its cache? By separating journal updates from the corresponding metadata (and/or data) actions, and by guaranteeing (by flushing the cache, or a singular disabling/enabling of the wb cache at the barrier) that the journal is updated on disk before the actions take place. This imposes an ordering on the journal vs. action requests, which is what a journalled fs needs for filesystem integrity. It doesn't really matter if the disk reorders writes within those two blocks, the only thing that really matters is that the journal update is completed before metadata (or data) updates take place. With softupdates, as far as I understand, that doesn't work, because there is no journal. All requests must be in the order that softupdates decrees. You'd have to issue a barrier request after every write request, which would be equivalent to disabling the wb cache. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
Jon Dama wrote: Request Barriers under linux exist to prevent the low level kernel block device layer from reordering write operations from the upper file system layers. Request Barriers consist of nothing more than tagging internal queues within the Linux kernel itself. They do nothing to resolve the underlying failures of the hardware to provide proper semantics to the block device layer. but, Request Barriers are ultimately useless. They can't resolve the underlying problems with ide/sata and there are already exposed semantics for scsi. If you flush the cache at barriers, on-disk integrity of the journal vs. metadata updates is guaranteed. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gmirror, sparc and SCSI problems
Am Montag, 11. Juli 2005 15:49 CEST schrieb Chris Hodgins: On 7/10/05, Johannes Verwijnen [EMAIL PROTECTED] wrote: On Jul 9, 2005, at 19:36, Chris Hodgins wrote: It seems that gmirror does not give us any partitions. A listing of the mirror directory shows only the gm0 node even though da0 is partitioned. When mounting the mirror it seems that /dev/mirror/gm0 only represents the root partition. How can we get the mirror to recognise the other partitions? I remember (vaguely)) this kind of problem, where when trying to mirror a whole disk, you'd only get the first slice. Have you tried mirroring the slices (da0s1 etc) separately? -- duvin Firstly thanks for all the suggestions. We managed to build the mirrors by using the suggestion above mirroring the slices separately. Unfortunetly, although the mirrors were created properly the filesystems are constantly suffering from inconsistencies and fsck actually appears to be segfaulting. I can't help you with the fsck segfault, nor can I tell too much about SPARC but I saw that you use a gmirror for swap. Do you also have the problems when you use shutdown -r now instead of reeboot?. If I remember correctly 5.4 shouldn't need swapoff=YES to be set in /etc/rc.conf but maybe the reboot issue still exists. -Harry We have decided not to pursue this any further for the moment, however we are prepared to allow access to the machine should anyone wish to try and sort out this incompatibility with gmirror and sparc. Included below is a brief logfile of a reboot after fsck'ing all of the mirrored partitions. # reboot Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...0 0 done No buffers busy after final sync Uptime: 5m23s GEOM_MIRROR: Device gm0e: provider mirror/gm0e destroyed. GEOM_MIRROR: Device gm0e destroyed. GEOM_MIRROR: Device gm0d: provider mirror/gm0d destroyed. GEOM_MIRROR: Device gm0d destroyed. GEOM_MIRROR: Device gm0b: provider mirror/gm0b destroyed. GEOM_MIRROR: Device gm0b destroyed. GEOM_MIRROR: Device gm0a: provider mirror/gm0a destroyed. GEOM_MIRROR: Device gm0a destroyed. Rebooting... Resetti LOM event: +38d+3h37m11s host reset ng ... \u Processor Speed = 648 MHz Baud rate is 9600 8 Data bits, 1 stop bits, no parity (configured from lom) Firmware CORE Sun Microsystems, Inc. @(#) core 1.0.12 2002/01/08 13:00 Software Power ON Verifying NVRAM...Done Bootmode is 0 [New I2C DIMM address] MCR0 = 57b2ce06 MCR1 = 80008000 MCR2 = cf3000ff MCR3 = a0cf Ecache Size = 512 KB Clearing E$ Tags Done Clearing I/D TLBs Done Probing memory Done MEMBASE=0x4000 MEMSIZE=0x2000 Clearing memory...Done Turning ON MMUs Done Copy ROM to RAM (170040 bytes) Done Orig PC=0x1fff0007e44 New PC=0xf0f07e9c Processor Speed=648MHz Looking for Dropin FVM ... found Decompressing Client Done Transferring control to Client... ttya initialized Reset Control: BXIR:0 BPOR:0 SXIR:0 SPOR:1 POR:0 Probing upa at 1f,0 pci pci pci Probing upa at 0,0 SUNW,UltraSPARC-IIe SUNW,UltraSPARC-IIe (512 Kb) Loading Support Packages: kbd-translator Loading onboard drivers: ebus flashprom eeprom idprom SUNW,lomh Probing /[EMAIL PROTECTED],1 Device 3 pmu i2c temperature dimm dimm i2c-nvram idprom motherboard-fru fan-control lomp Sun Fire V120 (UltraSPARC-IIe 648MHz), No Keyboard OpenBoot 4.0, 1024 MB memory installed, Serial #53833010. Ethernet address 0:3:ba:35:6d:32, Host ID: 83356d32. Executing last command: boot /[EMAIL PROTECTED],0/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED],0:a Boot device: /[EMAIL PROTECTED],0/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED],0:a File and args: FreeBSD/sparc64 boot block Boot path: /[EMAIL PROTECTED],0/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED],0:a Boot loader: /boot/loader Console: Open Firmware console FreeBSD/sparc64 bootstrap loader, Revision 1.0 ([EMAIL PROTECTED], Sun May 8 07:16:15 UTC 2005) bootpath=/[EMAIL PROTECTED],0/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED],0:a Loading /boot/defaults/loader.conf /boot/kernel/kernel data=0x3d8908+0x47c78 syms=[0x8+0x50b80+0x8+0x45260] /boot/kernel/geom_mirror.ko text=0x21558 data=0x5b0+0x18 syms=[0x8+0x1638+0x8+0x10da] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... nothing to autoload yet. jumping to kernel entry at 0xc004. Copyright (c) 1992-2005 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 5.4-RELEASE #0: Sun May 8 22:21:34 UTC 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC Timecounter tick frequency 64800 Hz quality
Re: Q: Looking for a recommendation for hardware RAID cards and FreeBSD
On July 14, 2005 11:33 am, J. Nyhuis wrote: I am looking at purchasing a 3ware SATA 8006-2LP RAID (SATA) controllers for a servers running FreeBSD 5.4-stable. Is anyone out there using a SATA 3ware RAID controller card on FreeBSD and would be willing share their experiences, good, bad, or otherwise? 3ware has done well by me with my Linux boxes, but I am willing to consider other vendors if they have a better product. I've heard great things about the 9000-series from 3Ware on the -current and -stable mailing lists. There's even vendor support (FreeBSD drivers, CLI management, web management, etc) from 3Ware, as well as the 3dm ports and native drivers. We're using a handful of Escalade 7506 cards with great success. We were going to use 9000-series cards in our new servers, but the local vendors have an 8-week backorder on them. So we're using LSI MegaRAID 6-port SATA cards instead. -- Freddie Cash [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: Q: Looking for a recommendation for hardware RAID cards and FreeBSD
On Thursday 14 July 2005 22.43, Freddie Cash wrote: On July 14, 2005 11:33 am, J. Nyhuis wrote: I am looking at purchasing a 3ware SATA 8006-2LP RAID (SATA) controllers for a servers running FreeBSD 5.4-stable. Is anyone out there using a SATA 3ware RAID controller card on FreeBSD and would be willing share their experiences, good, bad, or otherwise? 3ware has done well by me with my Linux boxes, but I am willing to consider other vendors if they have a better product. I've heard great things about the 9000-series from 3Ware on the -current and -stable mailing lists. There's even vendor support (FreeBSD drivers, CLI management, web management, etc) from 3Ware, as well as the 3dm ports and native drivers. we use both the 8000 and the 9000 they are really nice and fast, I would stay away from the PATA 7000 though it is not very fun to work with and very particular about what fw it has loaded. Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
if the FUA bit in the sata command header is properly respected. if the flush cache command on an ata device is properly respected. if the flush cache command on an ata device is implemented (it's optional) if the flush cache command exists when the ata device was made (it isn't in the earlier versions of the ata spec). anyways, your comments about softupdates needing total ordering versus journals needing partial ordering are wrong. softupdates only requires that you do not call 'biodone(x)' until 'x' has been committed to disk. this is 100% compatiable with the specification feature set, IF those semantics are actually present in the hardware. please see the thread beginning with the following commit message for an extensive discussion of these topics: http://lists.freebsd.org/pipermail/cvs-src/2003-April/001002.html -Jon On Thu, 14 Jul 2005, Matthias Buelow wrote: Jon Dama wrote: Request Barriers under linux exist to prevent the low level kernel block device layer from reordering write operations from the upper file system layers. Request Barriers consist of nothing more than tagging internal queues within the Linux kernel itself. They do nothing to resolve the underlying failures of the hardware to provide proper semantics to the block device layer. but, Request Barriers are ultimately useless. They can't resolve the underlying problems with ide/sata and there are already exposed semantics for scsi. If you flush the cache at barriers, on-disk integrity of the journal vs. metadata updates is guaranteed. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
Jon Dama [EMAIL PROTECTED] writes: if the FUA bit in the sata command header is properly respected. if the flush cache command on an ata device is properly respected. if the flush cache command on an ata device is implemented (it's optional) if the flush cache command exists when the ata device was made (it isn't in the earlier versions of the ata spec). or if the write-back cache can be disabled and re-enabled. anyways, your comments about softupdates needing total ordering versus journals needing partial ordering are wrong. softupdates only requires that you do not call 'biodone(x)' until 'x' has been committed to disk. Well. Can it group writes in such a way that flushing would be required only at larger intervals, or can't it? this is 100% compatiable with the specification feature set, IF those semantics are actually present in the hardware. Apparently it is not compatible with the real-world feature set and it should've been clear to the designer(s) of softupdates that write-back caches signal completion while the data is still in the cache. That's the whole purpose of these mechanisms (so they can delay and reorder the writes and write out whole tracks). You should only assume that, in that case, a seperate flush command (or a workaround that amounts to a flush) exists. Any different design assumes an oversimplified black box notion of a drive that does not correspond with reality. please see the thread beginning with the following commit message for an extensive discussion of these topics: http://lists.freebsd.org/pipermail/cvs-src/2003-April/001002.html I've seen nothing that contradicts what I've said. The point is, that the request barrier design with flushing at barriers as used in M$ Windows (and also completed in recent Linux kernels) allows safe use of disks with write-back cache enabled, while FreeBSD with softupdates apparently doesn't. I don't really care how it's implemented, or if journalling is used, or softupdates, or a quantum-tachyon-reverser mounted on the front antenna. I just want to have the same level of data safety on my hardware with FreeBSD that I would get with other systems. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
Jon Dama [EMAIL PROTECTED] writes: softupdates is perfectly safe with SCSI. its well known that ide and sata w/wo ncq fails to provide suitable semantics for softupdates however, journaling fairs no better, and request barriers do nothing to solve the problem. I had assumed that the sequence of operations in a journal would be idempotent. Is that a reasonable design criterion? [If it is, then it would make up for the fact that you can't build a reliable transaction gate. That is, you would just have to go back far enough that you *know* all of the needed journal is within the range you will replay. But even then, the journal would need to be on a separate medium, one that doesn't have the lying to you about transaction completion problem.] On Thu, 14 Jul 2005, Matthias Buelow wrote: Kevin Oberman wrote: SCSI or ATA? If it's ATA, turn off write cache with (atacontrol(8) or the sysctl. You do NOT want to do that. Not only will performance drop brutally (example: drop to 1/5th of normal write speed for sequential writes, probably worse for random writes) but it will also significantly reduce the lifetime of your disk. Modern disks are designed to be used with the write-back cache enabled, so don't turn it off. I have no idea what designed to be used with the write-back cache enabled could affect the operating life of the disk. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
: dangerous situation with shutdown process
Well, maybe it is in't implemented properly--I can't exactly say--but the blame should not fall on the method of data integrity used by softupdates. Nor do I think softupdates would require per se more flushes. Again, the blame would have to be on whoever is not taking the measures necessary to ensure biodone() is called after the data is properly committed. The Request Barrier design only works if the answer to the IFs I asked are yes. RB cannot solve an underlying failure of the hardware semantics. There is an idea floating around that the question to those IFs is usually no. If you feel that's wrong, please try to convince people here of that fact. Because if the answers are no these issues are moot and noone can or will do anything about it. 1a) If the ata driver is not flushing then there is a integrity problem in FreeBSD. 1b) If drives aren't respecting the flush there is no point in solving 1a. 2a) If the ata driver is flushing but doing so with every request, there is a potential performance problem. 2b) If the drives aren't respecting the flush there is no point solving 2a. There are of course other reasons to dislike the requirements softupdate imposes on other aspects of the system. I've CCed people who hopefully know more about the actual implementation below softupdates than I do. -Jon Jon Dama [EMAIL PROTECTED] writes: if the FUA bit in the sata command header is properly respected. if the flush cache command on an ata device is properly respected. if the flush cache command on an ata device is implemented (it's optional) if the flush cache command exists when the ata device was made (it isn't in the earlier versions of the ata spec). or if the write-back cache can be disabled and re-enabled. anyways, your comments about softupdates needing total ordering versus journals needing partial ordering are wrong. softupdates only requires that you do not call 'biodone(x)' until 'x' has been committed to disk. Well. Can it group writes in such a way that flushing would be required only at larger intervals, or can't it? this is 100% compatiable with the specification feature set, IF those semantics are actually present in the hardware. Apparently it is not compatible with the real-world feature set and it should've been clear to the designer(s) of softupdates that write-back caches signal completion while the data is still in the cache. That's the whole purpose of these mechanisms (so they can delay and reorder the writes and write out whole tracks). You should only assume that, in that case, a seperate flush command (or a workaround that amounts to a flush) exists. Any different design assumes an oversimplified black box notion of a drive that does not correspond with reality. please see the thread beginning with the following commit message for an extensive discussion of these topics: http://lists.freebsd.org/pipermail/cvs-src/2003-April/001002.html I've seen nothing that contradicts what I've said. The point is, that the request barrier design with flushing at barriers as used in M$ Windows (and also completed in recent Linux kernels) allows safe use of disks with write-back cache enabled, while FreeBSD with softupdates apparently doesn't. I don't really care how it's implemented, or if journalling is used, or softupdates, or a quantum-tachyon-reverser mounted on the front antenna. I just want to have the same level of data safety on my hardware with FreeBSD that I would get with other systems. mkb. empty Description: Binary data ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dangerous situation with shutdown process
Lowell Gilbert [EMAIL PROTECTED] writes: Jon Dama [EMAIL PROTECTED] writes: however, journaling fairs no better, and request barriers do nothing to solve the problem. I had assumed that the sequence of operations in a journal would be idempotent. Is that a reasonable design criterion? [If it is, then it would make up for the fact that you can't build a reliable transaction gate. That is, you would just have to go back far enough that you *know* all of the needed journal is within the range you will replay. But even then, the journal would need to be on a separate medium, one that doesn't have the lying to you about transaction completion problem.] No, it needn't. It is sufficient that the journal entries for a block of updates that are to follow are on disk before the updates are made. That's all. This can be achieved by inserting a write barrier request in between the journal writes and the actual data/metadata writes. The block driver will, when it sees the barrier, a) write out all requests in its queue that it got before the barrier, and b) flush the cache so that they will not get intermixed by the drive with the following data writes. What could happen now when the power goes away at an inopportune moment? [Note that I'm only talking about filesystem integrity, not general data loss.] * If power goes away before the journal is written, nothing happens. * If the journal is partially written, and power goes away, it will be partially replayed at boot but the filesystem will be consistent. * If power goes away, when the journal is fully written, but no metadata updates have been performed, they will be performed at boot and everything is as if the full request has completed before power went out. * If power goes away when the journal is fully written, and parts of the metadata updates have been written, those updates will be performed twice (once more at reboot) but that won't matter since these operations are idempotent. The remaining metadata updates are then performed once, at reboot. So where is the need for the journal to be on a seperate medium? The only thing that matters is that no metadata updates will be written before the journal has been written, and flushing the disk cache at a barrier will ensure this. Note that the disk doesn't even have to flush the cache when it receives that command, it only has to ensure that it'll perform all requests before the flush in front of those that come afterwards. I have no idea what designed to be used with the write-back cache enabled could affect the operating life of the disk. If you disable the write cache, you get a much higher weartear due to much more seeking. If I observe a 5x performance degradation when the cache is disabled, for sequential writes (i.e., no cache overwriting effects), I would think that I also have a factor 1 of increased seeking operations in the drive, otherwise the performance degradation cannot be explained. [Besides, the disk gets really loud when the cache is disabled.] mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
VIRUS DETECTED IN YOUR MAIL
There was a virus in your E-Mail to: [EMAIL PROTECTED] For more Info, Call EuroIntegra support with reference to 1121388075.952603 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FYI - RELENG_6 branch has been created.
BTW, Going from RELENG5 to RELENG6 requires an rm -rf /usr/obj This isn't too surprising, but its worth a note if anyone is making a migration document. Thanks, Jon On Mon, 11 Jul 2005, Scott Long wrote: Mike Tancsa wrote: At 05:04 PM 11/07/2005, Robert Watson wrote: As a further FYI, a variety of debugging features are still enabled by default in RELENG_6, including INVARINTS, WITNESS, and user space malloc debugging. These will remain enabled through the first snapshot from the Apart from the kernel settings, what other debug settings need to be turned off ? i.e. How do I turn off malloc debugging ? ---Mike ln -s aj /etc/malloc.conf Scott ___ 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: FYI - RELENG_6 branch has been created.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Jul 14, 2005 at 09:49:01PM -0700, Jon Dama wrote: BTW, Going from RELENG5 to RELENG6 requires an rm -rf /usr/obj This isn't too surprising, but its worth a note if anyone is making a migration document. Thanks, Jon Shouldn't make cleanworld take care of that? When I upgraded, that was all I did and I had no problems. Speaking of notes, the make cleanworld hasn't made it into UPDATING, which it probably should. (I remember one late night install on a test box, where rather than CD'ing into /usr/obj, I'd cd'd into /usr, and was using a prompt that didn't automatically give me my working directory. I was a bit upset when I then typed cd /usr/src and got the response that there was no such file or directory, then typed pwd to see that I was in /usr. Oops. :) While on the subject, I wonder if it would be worth adding to UPDATING, the ln -s aj /etc/malloc.conf to turn off malloc debugging. Thanks - -- Scott Robbins PGP keyID EB3467D6 ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 Buffy: Now, we can do this the hard way or... well, actually, there's just the hard way. Darla: That's fine with me. Buffy: Are you sure? Now this is not gonna be pretty. We're talking violence, strong language, adult content. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC10ZI+lTVdes0Z9YRAuR/AJ9FeND/Zf+duMvr0qTJkYxwAWvc5gCgj9Lv 9T5ikqcfYIGWlN0202mlrnM= =vmIG -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: dangerous situation with shutdown process
On Thu, Jul 14, 2005 at 04:17:06PM -0400, asym wrote: At 15:19 7/14/2005, Wilko Bulte wrote: On Thu, Jul 14, 2005 at 12:14:49PM -0700, Kevin Oberman wrote.. Date: Thu, 14 Jul 2005 20:38:15 +0200 From: Anatoliy Dmytriyev [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Hello, everybody! I have found unusual and dangerous situation with shutdown process: I did a copy of 200 GB data on the 870 GB partition (softupdates is enabled) by cp command. It took a lot of time when I did umount for this partition exactly after cp, but procedure finished correctly. In case, if I did ???shutdown ???h(r)???, also exactly after cp, the shutdown procedure waited for ???sync??? (umounting of the file system) but sync process was terminated by timeout, and fsck checked and did correction of the file system after boot. System 5.4-stable, RAM 4GB, processor P-IV 3GHz. How can I fix it on my system? The funny thing about all the replies here.. is that this guy is not saying that sync doesn't work. He's saying that the timeout built into shutdown causes it to *terminate* the sync forcibly before it's done, and then reboot. All finger pointing about IDE, SCSI, softupdates, and journals aside.. I think all he wants/needs is a way to increase that timer. If you can't increase shutdown timeout, decrease softupdates timers. # tail -3 /etc/sysctl.conf kern.metadelay=14 kern.dirdelay=15 kern.filedelay=17 That was my solution for shutdown wait timeout. Serg N. Voronkov, Sibitex JSC, Tyumen, Russia. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
