Re: portdowngrade/portupgrade question
On Wed, 17 Jan 2007 06:24:23 +0100 Par Leijonhufvud <[EMAIL PROTECTED]> wrote: > How do I tell portupgrade that I *know*, just go ahead anyway? Is it 'portupgrade -f ' you want? HTH -- Regards, Torfinn Ingolfsen, Norway ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Nexcom 1086 - Marvell Chipsets - Nics show in dmesg but do not show up in ifconfig
On Tue, Jan 16, 2007 at 05:22:49PM -0500, Scott Ullrich wrote: > Nevermind, I found > http://lists.freebsd.org/pipermail/freebsd-net/2006-January/009543.html > > Now the nics are working. Thanks anyways! > CURRENT has msk(4) for your NIC. If you have a chance to run CURRENT on your box, please report any strange things to me. Thanks. > Scott > > > On 1/16/07, Scott Ullrich <[EMAIL PROTECTED]> wrote: > >Hello, > > > >I am currently working with a Nexcom 1086 that features 2 Marvell > >chipsets with 8 total nics. This device is slated to become a > >FreeBSD/pfSense router. > > > >During probing, all nics show up okay sk0-sk3 and skc-0-3 but the skc > >nics do not show up in ifconfig. > > > >Is there something that I am overlooking to enable the nics? > > > >DMESG -a is located here: > >http://www.pfsense.com/~sullrich/nexcom_1086_dmesg.txt > > > >Thanks in advance! > > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
portdowngrade/portupgrade question
I'm trying to find out where something stopped working, and as part of that I need to do a portdowgrade. Worked fine. Only, when I tried to actually install the downgraded port I got bounced by the "=> Please update your ports tree and try again." message How do I tell portupgrade that I *know*, just go ahead anyway? /Par -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fetchmail problem
On Wed, Jan 17, 2007 at 05:13:16AM +0100, Par Leijonhufvud wrote: > I have a FreeBSD box (running ancient 4.8) that used to collect email > fine with fetchmail. Then after te latest portupgrade of fetchmail it > stopped working. When trying to run it manual I see the error shown > below. > > Anyone with suggestions as to (a) just what is going wrong, and (b) how > to fix it? Another machine running 5.3 have no problems. Maybe the configuration options changed. Anyway, this kind of question should be asked on the fetchmail support mailing lists since it is not a problem with FreeBSD-stable itself. Kris pgpfcteGy3MN5.pgp Description: PGP signature
Fetchmail problem
I have a FreeBSD box (running ancient 4.8) that used to collect email fine with fetchmail. Then after te latest portupgrade of fetchmail it stopped working. When trying to run it manual I see the error shown below. Anyone with suggestions as to (a) just what is going wrong, and (b) how to fix it? Another machine running 5.3 have no problems. /Par == % fetchmail -v -v -p pop3 -u tuschin.blackcatnetworks.co.uk fetchmail: removing stale lockfile Enter password for @tuschin.blackcatnetworks.co.uk: fetchmail: 6.3.6 querying tuschin.blackcatnetworks.co.uk (protocol POP3) at Wed Jan 17 05:09:02 2007: poll started Trying to connect to 2001:1b40:0:20::34/110...connection failed. fetchmail: connection to tuschin.blackcatnetworks.co.uk:pop3 [2001:1b40:0:20::34/110] failed: No route to host. Trying to connect to 193.201.200.34/110...connected. fetchmail: POP3< +OK Hello there. fetchmail: POP3> CAPA fetchmail: POP3< +OK Here's what I can do: fetchmail: POP3< STLS fetchmail: POP3< TOP fetchmail: POP3< USER fetchmail: POP3< LOGIN-DELAY 10 fetchmail: POP3< PIPELINING fetchmail: POP3< UIDL fetchmail: POP3< IMPLEMENTATION Courier Mail Server fetchmail: POP3< . fetchmail: POP3> STLS fetchmail: POP3< +OK Begin SSL/TLS negotiation now. fetchmail: Issuer Organization: Equifax Secure Inc. fetchmail: Issuer CommonName: Equifax Secure Global eBusiness CA-1 fetchmail: Server CommonName: tuschin.blackcatnetworks.co.uk fetchmail: tuschin.blackcatnetworks.co.uk key fingerprint: 82:24:50:19:D3:9D:36:12:EC:49:99:7C:E1:C3:A9:F2 fetchmail: Server certificate verification error: unable to get local issuer certificate fetchmail: Server certificate verification error: certificate not trusted fetchmail: Server certificate verification error: unable to verify the first certificate Segmentation fault (core dumped) absaroka 114 ~ % == ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: can we resurrect linux-firefox-1.5 ?
On Wednesday, 17 January 2007 at 3:16:44 +0100, Roland Smith wrote: > On Wed, Jan 17, 2007 at 11:37:53AM +1030, Greg 'groggy' Lehey wrote: >> >> I can't agree. It has hijacked some keys used by Wikipedia (alt-S, >> alt-P), and so far I've found it impossible to disable tabs, something >> that was barely possible under 1.5. Tell me how to fix that and I'll >> be marginally happy; presumably they'll gradually fix the stability >> problems. > > You could set browser.tabs.forceHide to true in about:config. That > should get rid of the tabbar. Set browser.link.open_external and > browser.link.open_newwindow to 2 to open new pages in a new window. Thank you! I had done some of these changes, but not all. Now it works. > Personally I like tabbed browsing a lot, but different strokes for > different folks. It probably depends on your window manager. Tabs are a reasonable workaround for window managers that make it difficult to manage many windows. Greg -- See complete headers for address and phone numbers. pgp9AEtAX9etx.pgp Description: PGP signature
Re: 6.2-RELEASE em0 watchdog timeouts -- sometimes (w/ partial workaround)
On 1/16/07, Jeremy Chadwick <[EMAIL PROTECTED]> wrote: On Tue, Jan 16, 2007 at 10:53:04AM -0800, Jack Vogel wrote: > There are some management related issues with this NIC, first if you > have not done so make a DOS bootable device, and run this app I > am enclosing, it fixes the prom setting that is wrong on some devices. > It will do no harm, and it may solve things. Jack, Can you expand on what this application changes in the PROM? I have an Intel motherboard which suffers from similar to what the OP has reported (em0 watchdog timeouts), and was curious what the utility does before firing up the board and trying it. Others may be curious to know, too. Hmmm, I'm rusty on this, its now been a year or more since I was first involved in the details, so I may need to amend this later :) But from memory, the issue is the value programmed into the MANC register by the PROM, I don't remember what bit it was, but one bit is mistakenly set, it causes the hardware to incorrectly intercept some packets. I was snowbound today, but I'll doublecheck on the detail tomorrow and amend if needed. Everyone note that this ONLY effects an 82573 NIC, so make sure of that before anything else. Cheers, Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
odd interrupt issues with nvidia and X
I have a odd situation where the according to top 50% of the processor is going towards interupt handling. vmstat -ai shows the nvidia device generating lots of interrupts. The interrupt issue goes away as soon as I kill X or switch to a terminal. X also slowly starts using up more and more CPU time. the schedule is 4BSD with preemption... none of the sysctl stuff for it has been changed... Any ideas? signature.asc Description: PGP signature
Re: 6.2-RELEASE em0 watchdog timeouts -- sometimes (w/ partial workaround)
On Tue, Jan 16, 2007 at 10:53:04AM -0800, Jack Vogel wrote: > There are some management related issues with this NIC, first if you > have not done so make a DOS bootable device, and run this app I > am enclosing, it fixes the prom setting that is wrong on some devices. > It will do no harm, and it may solve things. Jack, Can you expand on what this application changes in the PROM? I have an Intel motherboard which suffers from similar to what the OP has reported (em0 watchdog timeouts), and was curious what the utility does before firing up the board and trying it. Others may be curious to know, too. Thanks, as always. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.2-RELEASE em0 watchdog timeouts -- sometimes (w/ partial workaround)
Jack Vogel wrote: On 1/16/07, Mike Andrews <[EMAIL PROTECTED]> wrote: I have a strange issue with em0 watchdog timeouts that I think is not the same as the ones everyone was having during the 6.2 beta cycle... I have six systems, each with two Intel GigE ports onboard: Systems A and B: Supermicro PDSMi+ Systems C and D: Supermicro PDSMi (without the plus) [snip] Several times a day, em0 will go down, give a watchdog timeout error on the console, then come right back up on its own a few seconds later. But here's the weird twist: it ONLY happens on systems A and B, and ONLY when running at gigabit speed. If I knock the two switch ports down to 100 meg, the problem goes away. [snip] There are some management related issues with this NIC, first if you have not done so make a DOS bootable device, and run this app I am enclosing, it fixes the prom setting that is wrong on some devices. It will do no harm, and it may solve things. Let me know if it does fix it please. So far it seems like it DID fix it, but give me another day or two to watch it to be sure. Thanks! FYI, it only changed the PROM on the first NIC on each PDSMi+ box; it said the second NIC was fine. (But since the first NIC was the one I was having trouble with...) I ran it on the older PDSMi boxes and it said it changed both NICs on those, even though they were (and still are) working fine. -- Mike Andrews * [EMAIL PROTECTED] * http://www.bit0.com It's not news, it's Fark.com. Carpe cavy! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: can we resurrect linux-firefox-1.5 ?
On Wed, Jan 17, 2007 at 11:37:53AM +1030, Greg 'groggy' Lehey wrote: > > I can't agree. It has hijacked some keys used by Wikipedia (alt-S, > alt-P), and so far I've found it impossible to disable tabs, something > that was barely possible under 1.5. Tell me how to fix that and I'll > be marginally happy; presumably they'll gradually fix the stability > problems. You could set browser.tabs.forceHide to true in about:config. That should get rid of the tabbar. Set browser.link.open_external and browser.link.open_newwindow to 2 to open new pages in a new window. Personally I like tabbed browsing a lot, but different strokes for different folks. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpCw3eyiC3pF.pgp Description: PGP signature
Re: can we resurrect linux-firefox-1.5 ?
On Wednesday, 17 January 2007 at 9:56:51 +1000, Greg Black wrote: > On 2007-01-16, Luigi Rizzo wrote: > >> The 1.5.x version _is_ working for me. It is 2.0.x that >> exhibits severe problems. > > I was surprised and annoyed when I found that the reasonably reliable > 1.5.x version had been replaced by 2.0, partly because I expected it to > be less reliable and partly because some of the extensions I used no > longer worked and partly because the user interface had some changes I > didn't like. Same here. > However, it has been my experience in the 6+ weeks I've been using > it that 2.0 is better in every way than 1.5 and it is certainly more > stable and works better with the flash plugin (something I hate but > just have to use). I can't agree. It has hijacked some keys used by Wikipedia (alt-S, alt-P), and so far I've found it impossible to disable tabs, something that was barely possible under 1.5. Tell me how to fix that and I'll be marginally happy; presumably they'll gradually fix the stability problems. Greg -- See complete headers for address and phone numbers. pgpidbjw7wL6p.pgp Description: PGP signature
ftp2 no iso
ftp://ftp2.freebsd.org does not seem to have the actual isos ncftp ...SD/ISO-IMAGES-i386/6.2 > pwd ftp://ftp2.freebsd.org/pub/FreeBSD/ISO-IMAGES-i386/6.2/ This URL is also valid on this server: ftp://ftp2.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/6.2/ ncftp ...SD/ISO-IMAGES-i386/6.2 > ls -l -rw-r--r-- 1 65532 65532 258 Dec 26 15:49 CHECKSUM.MD5 -rw-r--r-- 1 65532 65532 398 Dec 26 15:50 CHECKSUM.SHA256 randy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.2 & nvidia x11 driver: weird 16bpp/24bpp colorspace damage
* Dmitry Marakasov ([EMAIL PROTECTED]) wrote: Well, I've temporary solved a problem. I've downgraded to 6.1, but then I discovered that nvidia 9631 gives artifacts on 6.1 as well. So I've also downgraded driver to 8776 and voila - now everything works (so I was mistaken - I've used 8776, not 9631 before system upgrade). But the problem is still there - 8776 doesn't work under 6.2 (NVRM: agp_find_device failed, chipset unsupported?). -- Best regards, Dmitry Marakasov mailto:[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: can we resurrect linux-firefox-1.5 ?
On 2007-01-16, Luigi Rizzo wrote: > The 1.5.x version _is_ working for me. It is 2.0.x that > exhibits severe problems. I was surprised and annoyed when I found that the reasonably reliable 1.5.x version had been replaced by 2.0, partly because I expected it to be less reliable and partly because some of the extensions I used no longer worked and partly because the user interface had some changes I didn't like. However, it has been my experience in the 6+ weeks I've been using it that 2.0 is better in every way than 1.5 and it is certainly more stable and works better with the flash plugin (something I hate but just have to use). I know that's not going to fix your problem, but I'd be interested to see if you could get to a working setup with 2.0 by running it with a limited set of extensions. Initially, I was cross about some issues with my once-favourite extension (session-manager or some similar name), but now that I've used the builtin session recovery capability, I no longer need that extension. The only extensions I have in my 2.0 setup now are Adblock Plus, NoScript and Smart Middle Click and it has been exemplary in its behaviour -- i.e., it has crashed twice in 6 weeks and it is running 24 hours a day with at least 5 windows and 50 or more tabs open at all times. And it recovered all the open tabs fine after the two crashes. Cheers, Greg ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: charset conversion support in amd(8)
Marat N.Afanasyev wrote:
Nick Gustas wrote:
Marat N.Afanasyev wrote:
Hello!
I found that automount daemon configured to use cdrom device doesn't
support -C option to convert filenames to local charset. Is there
any ways to make it work?
my amd.map is as follows:
# $FreeBSD: src/etc/amd.map,v 1.9 2002/05/15 22:24:29 obrien Exp $
#
/defaults type:=host;fs:=${autodir}/${rhost}/host;rhost:=${key}
* opts:=rw,grpid,resvport,vers=3,proto=udp,nosuid,nodev
cdrom fs:=${autodir}/cdrom;type:=cdfs;opts:=ro;dev:=/dev/cd2
adding Ckoi8-r to opts doesn't solve the problem. I suppose one
should add charset conversion ability to amd itself. Am I right?
I have an old amd.map from 1999 or so that we use for a freebsd cd
server here at work, it uses a mount "type" of program. I don't see
this format documented in the current amd man pages, but it still
works on 6-stable.
You should be able to change the mount commands to mount_cd9660 and
add the -C option.
amd.map:
cdrom0 type:=program;\
fs:=/realmounts/cdrom0;\
mount:="/sbin/mount mount /realmounts/cdrom0";\
unmount:="/sbin/umount umount /realmounts/cdrom0"
cdrom1 type:=program;\
fs:=/realmounts/cdrom1;\
mount:="/sbin/mount mount /realmounts/cdrom1";\
unmount:="/sbin/umount umount /realmounts/cdrom1"
cdrom2 type:=program;\
fs:=/realmounts/cdrom2;\
mount:="/sbin/mount mount /realmounts/cdrom2";\
unmount:="/sbin/umount umount /realmounts/cdrom2"
cdrom3 type:=program;\
fs:=/realmounts/cdrom3;\
mount:="/sbin/mount mount /realmounts/cdrom3";\
unmount:="/sbin/umount umount /realmounts/cdrom3"
cdrom4 type:=program;\
fs:=/realmounts/cdrom4;\
mount:="/sbin/mount mount /realmounts/cdrom4";\
unmount:="/sbin/umount umount /realmounts/cdrom4"
cdrom5 type:=program;\
fs:=/realmounts/cdrom5;\
mount:="/sbin/mount mount /realmounts/cdrom5";\
unmount:="/sbin/umount umount /realmounts/cdrom5"
cdrom6 type:=program;\
fs:=/realmounts/cdrom6;\
mount:="/sbin/mount mount /realmounts/cdrom6";\
unmount:="/sbin/umount umount /realmounts/cdrom6"
fstab:
/dev/cd0 /realmounts/cdrom0 cd9660
ro,noauto 0 0
/dev/cd1 /realmounts/cdrom1 cd9660
ro,noauto 0 0
/dev/cd2 /realmounts/cdrom2 cd9660
ro,noauto 0 0
/dev/cd3 /realmounts/cdrom3 cd9660
ro,noauto 0 0
/dev/cd4 /realmounts/cdrom4 cd9660
ro,noauto 0 0
/dev/cd5 /realmounts/cdrom5 cd9660
ro,noauto 0 0
/dev/cd6 /realmounts/cdrom6 cd9660
ro,noauto 0 0
amd command line:
/usr/sbin/amd -p -a /cdrom -w 5 -c 10 /cdrom /etc/amd.map /cdrom
/etc/amd.map
directories to create:
mkdir -p /realmounts/cdrom0
mkdir -p /realmounts/cdrom1
mkdir -p /realmounts/cdrom2
mkdir -p /realmounts/cdrom3
mkdir -p /realmounts/cdrom4
mkdir -p /realmounts/cdrom5
mkdir -p /realmounts/cdrom6
mkdir /cdrom
It certainly looks hacky compared to your config, but it's worked
from freebsd 3.1 through now so I never changed it.
thanks, I made my config similar to yours and it works ;)
Glad it works for you! I was rather surprised at the lack of info in the
man pages about this setup.. I even rechecked the FreeBSD 3.3
amd/amd.conf man pages just now and they didn't list this option either,
maybe I'm missing it. Not sure where I found the original config, must
have been online at some point.
I suppose this quote from the amd(8) man page applies:
"A weird imagination is most useful to gain full advantage of all the
features."
-Nick
(inadvertent top posting fixed)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Nexcom 1086 - Marvell Chipsets - Nics show in dmesg but do not show up in ifconfig
Nevermind, I found http://lists.freebsd.org/pipermail/freebsd-net/2006-January/009543.html Now the nics are working. Thanks anyways! Scott On 1/16/07, Scott Ullrich <[EMAIL PROTECTED]> wrote: Hello, I am currently working with a Nexcom 1086 that features 2 Marvell chipsets with 8 total nics. This device is slated to become a FreeBSD/pfSense router. During probing, all nics show up okay sk0-sk3 and skc-0-3 but the skc nics do not show up in ifconfig. Is there something that I am overlooking to enable the nics? DMESG -a is located here: http://www.pfsense.com/~sullrich/nexcom_1086_dmesg.txt Thanks in advance! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: can we resurrect linux-firefox-1.5 ?
On Tue, Jan 16, 2007 at 10:07:39PM +, Pete French wrote: > > If you had any idea how many RFC's IE violates and and how many bugs there > > are in it you would never have made a statement like that. > > I don't think here ever said that IE was *better*, just that it was > necessary for certain sites (which is undeniably true) and that if > all you have available is Firefox then you at least want to have a working > stable Firefox. exactly. cheers luigi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: can we resurrect linux-firefox-1.5 ?
On Tue, Jan 16, 2007 at 11:41:22PM +0100, Pietro Cerutti wrote: > On 1/16/07, Luigi Rizzo <[EMAIL PROTECTED]> wrote: > > > > So i am just advocating to keep the "stable" version around while > > the "current" one becomes stable enough. > > You can get that port back to a specific date (e.g. with > sysutils/portdowngrade) and reinstall the version which better applies > your needs. which is what i did - but it is an annoyance and not something that the average user wants/knows how to do. That is the reason why we have -stable and -current after all. luigi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: can we resurrect linux-firefox-1.5 ?
Hello, linux-firefox-2.0.0.1 works fine for me. Cheers, -vlado vlado.srv# uname -a FreeBSD srv.g1.netng.org 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #1: Fri Nov 3 20:20:33 CET 2006 [EMAIL PROTECTED]:/usr/obj/usrmnt/src/sys/SRV i386 vlado.srv# ll /var/db/pkg/ | grep firefox drwxr-xr-x 2 root wheel 512 9 led 20:06 firefox-2.0.0.1,1 drwxr-xr-x 2 root wheel 512 8 led 08:18 linux-firefox-2.0.0.1 vlado.srv# ll /var/db/pkg/ | grep flash drwxr-xr-x 2 root wheel 512 7 led 13:21 libflash-0.4.13_1 drwxr-xr-x 2 root wheel 512 7 led 13:03 linux-flashplugin-7.0r69 Pete French píše v út 16. 01. 2007 v 22:07 +: > > If you had any idea how many RFC's IE violates and and how many bugs there > > are in it you would never have made a statement like that. > > I don't think here ever said that IE was *better*, just that it was > necessary for certain sites (which is undeniably true) and that if > all you have available is Firefox then you at least want to have a working > stable Firefox. > > It does seem to boil down the the flash issue though - for me native > Firefox is stable, until I try and add flash. So I live without flash, > but that measn there are a number of things I just can't do, as well as > the IE only sites (which are becomming rare). In the end I bundle any such > jobs > up and do them at home where I keep an x64-XP box for such things. If the > most stable flash enabled player on FreeBSD is linux-firefox 1.5 then it > would be nice to have it in ports. > > -pete. > ___ > 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: charset conversion support in amd(8)
Nick Gustas wrote:
I have an old amd.map from 1999 or so that we use for a freebsd cd
server here at work, it uses a mount "type" of program. I don't see
this format documented in the current amd man pages, but it still works
on 6-stable.
You should be able to change the mount commands to mount_cd9660 and add
the -C option.
amd.map:
cdrom0 type:=program;\
fs:=/realmounts/cdrom0;\
mount:="/sbin/mount mount /realmounts/cdrom0";\
unmount:="/sbin/umount umount /realmounts/cdrom0"
cdrom1 type:=program;\
fs:=/realmounts/cdrom1;\
mount:="/sbin/mount mount /realmounts/cdrom1";\
unmount:="/sbin/umount umount /realmounts/cdrom1"
cdrom2 type:=program;\
fs:=/realmounts/cdrom2;\
mount:="/sbin/mount mount /realmounts/cdrom2";\
unmount:="/sbin/umount umount /realmounts/cdrom2"
cdrom3 type:=program;\
fs:=/realmounts/cdrom3;\
mount:="/sbin/mount mount /realmounts/cdrom3";\
unmount:="/sbin/umount umount /realmounts/cdrom3"
cdrom4 type:=program;\
fs:=/realmounts/cdrom4;\
mount:="/sbin/mount mount /realmounts/cdrom4";\
unmount:="/sbin/umount umount /realmounts/cdrom4"
cdrom5 type:=program;\
fs:=/realmounts/cdrom5;\
mount:="/sbin/mount mount /realmounts/cdrom5";\
unmount:="/sbin/umount umount /realmounts/cdrom5"
cdrom6 type:=program;\
fs:=/realmounts/cdrom6;\
mount:="/sbin/mount mount /realmounts/cdrom6";\
unmount:="/sbin/umount umount /realmounts/cdrom6"
fstab:
/dev/cd0 /realmounts/cdrom0 cd9660
ro,noauto 0 0
/dev/cd1 /realmounts/cdrom1 cd9660
ro,noauto 0 0
/dev/cd2 /realmounts/cdrom2 cd9660
ro,noauto 0 0
/dev/cd3 /realmounts/cdrom3 cd9660
ro,noauto 0 0
/dev/cd4 /realmounts/cdrom4 cd9660
ro,noauto 0 0
/dev/cd5 /realmounts/cdrom5 cd9660
ro,noauto 0 0
/dev/cd6 /realmounts/cdrom6 cd9660
ro,noauto 0 0
amd command line:
/usr/sbin/amd -p -a /cdrom -w 5 -c 10 /cdrom /etc/amd.map /cdrom
/etc/amd.map
directories to create:
mkdir -p /realmounts/cdrom0
mkdir -p /realmounts/cdrom1
mkdir -p /realmounts/cdrom2
mkdir -p /realmounts/cdrom3
mkdir -p /realmounts/cdrom4
mkdir -p /realmounts/cdrom5
mkdir -p /realmounts/cdrom6
mkdir /cdrom
It certainly looks hacky compared to your config, but it's worked from
freebsd 3.1 through now so I never changed it.
Marat N.Afanasyev wrote:
Hello!
I found that automount daemon configured to use cdrom device doesn't
support -C option to convert filenames to local charset. Is there any
ways to make it work?
my amd.map is as follows:
# $FreeBSD: src/etc/amd.map,v 1.9 2002/05/15 22:24:29 obrien Exp $
#
/defaults type:=host;fs:=${autodir}/${rhost}/host;rhost:=${key}
* opts:=rw,grpid,resvport,vers=3,proto=udp,nosuid,nodev
cdrom fs:=${autodir}/cdrom;type:=cdfs;opts:=ro;dev:=/dev/cd2
adding Ckoi8-r to opts doesn't solve the problem. I suppose one should
add charset conversion ability to amd itself. Am I right?
thanks, I made my config similar to yours and it works ;)
--
SY, Marat
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: can we resurrect linux-firefox-1.5 ?
On 1/16/07, Luigi Rizzo <[EMAIL PROTECTED]> wrote: So i am just advocating to keep the "stable" version around while the "current" one becomes stable enough. You can get that port back to a specific date (e.g. with sysutils/portdowngrade) and reinstall the version which better applies your needs. cheers luigi Ciao -- Pietro Cerutti ICQ: 117293691 PGP: 0x9571F78E - ASCII Ribbon Campaign - against HTML e-mail and proprietary attachments www.asciiribbon.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: can we resurrect linux-firefox-1.5 ?
> If you had any idea how many RFC's IE violates and and how many bugs there > are in it you would never have made a statement like that. I don't think here ever said that IE was *better*, just that it was necessary for certain sites (which is undeniably true) and that if all you have available is Firefox then you at least want to have a working stable Firefox. It does seem to boil down the the flash issue though - for me native Firefox is stable, until I try and add flash. So I live without flash, but that measn there are a number of things I just can't do, as well as the IE only sites (which are becomming rare). In the end I bundle any such jobs up and do them at home where I keep an x64-XP box for such things. If the most stable flash enabled player on FreeBSD is linux-firefox 1.5 then it would be nice to have it in ports. -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Nexcom 1086 - Marvell Chipsets - Nics show in dmesg but do not show up in ifconfig
Hello, I am currently working with a Nexcom 1086 that features 2 Marvell chipsets with 8 total nics. This device is slated to become a FreeBSD/pfSense router. During probing, all nics show up okay sk0-sk3 and skc-0-3 but the skc nics do not show up in ifconfig. Is there something that I am overlooking to enable the nics? DMESG -a is located here: http://www.pfsense.com/~sullrich/nexcom_1086_dmesg.txt Thanks in advance! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: can we resurrect linux-firefox-1.5 ?
On Tue, Jan 16, 2007 at 10:14:41PM +0100, Torfinn Ingolfsen wrote: ... > If linux-firefox isn't working for youhere, I really don't have any The 1.5.x version _is_ working for me. It is 2.0.x that exhibits severe problems. My complaint (to get back on the topic) is that 1.5 disappeared from the ports replaced by a less stable version. Sure, we might not know when the port was upgraded, but if experience teaches something, release N+1.0 of something is usually buggier than release N.X of the same software. So i am just advocating to keep the "stable" version around while the "current" one becomes stable enough. After all, in ports we have six versions of openoffice.org, four versions of staroffice, six versions of emacs/xemacs, etc. (not counting language-specific or other versions with minor variations) I understand that having multiple versions of the same thing is less than ideal, but for binary-only things where we have no chance to fix issues with with local patches, it makes a lot of sense. cheers luigi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: lirc serial FreeBSD
It depends on what type of receiver you have. comms/lirc in ports works adequately for me with a serial IRman. Craig On Tue, Jan 16, 2007 at 08:18:49PM +0530, krishnamurthy holla wrote: > Dear All, > i have a serial IR receiver and i am looking for lirc support for serial ir > device in freebsd > is there solutions already made ? or any other alternatives? > > > Thanks & Regards > Krishna > ___ > 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: running mksnap_ffs
Kris Kennaway writes: | Thanks for clarifying. Hopefully you and Tor can get something | committed soon! I'm not sure about that. I have to see what has changed since then. That was ... uhm a year ago when I dropped the ball. It's probably a good task for me to look at in the context of -current again. I should have disks to build a 1.5T file system to play with. Doug A. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: running mksnap_ffs
On Tue, Jan 16, 2007 at 09:55:00PM +0100, Willem Jan Withagen wrote: > Kris Kennaway wrote: > .. > > >>>The file-system would come to a stop, processes stuck on bio, snap-shots > >>>not finishing etc. This was caused by the system running out of usable > >>>buffers. The change forces them to be flushed every so often. This is > >>>independant of locking. 10 might be to aggresive. Some scaling of > >>>nbuf would probably be better. > >>When I run mksnap_ffs it runs to the point where ANY access to the > >>filesystem gives that process a lockup. > > > >Yes, that is expected. Actually it begins when something accesses the > >directory in which the snapshot is being made, since that causes the > >parent directory to be locked...then something tries to access the > >parent directory, which eventually cascades back to the root. > > > >>Getting the file system back is only thru "hard reboot". Trying to do it > >>the gentle way locks the whole system. > > > >Or waiting until the snapshot operation finishes. You (still) haven't > >determined that it's actually hanging as opposed to just waiting for > >the snapshot operation to finish. > > True, and that is what I was refering to. > > * I've let it run for 12 hours on 1,5T (that's why I asked for other > experiences) > * I looked at diskstats with gstat: > that turned out that everything was idle for > 5 minutes > > Then I concluded that it was locked. OK, that does sound like it's deadlocked. You could try Doug's patch, or it might be another (unknown) condition. If so, you'll need to do some additional debugging with a serial console to figure out what is wrong. Kris pgpZLz9YTBAVB.pgp Description: PGP signature
Re: running mksnap_ffs
On Tue, Jan 16, 2007 at 01:17:33PM -0800, Doug Ambrisko wrote: > Kris Kennaway writes: > | On Tue, Jan 16, 2007 at 09:26:47PM +0100, Willem Jan Withagen wrote: > | > Doug Ambrisko wrote: > | > >| > or things can get wedged. We have some other patches as well that > | > >might > | > >| > be required. As a hack on a local server we have been using snap > shots > | > >| > to do a "hot" back-up of a data base each morning. This is based on > | > >| > 6.x. > | > >| > | > >| What do you mean by "get wedged"? Are you seeing a deadlock, and if > | > >| so then what are the details? When you say 6.x, do you mean > | > >| up-to-date RELENG_6? There were various snapshot deadlock fixes > | > >| committed over the past year including some in the past few months. > | > > > | > >The file-system would come to a stop, processes stuck on bio, snap-shots > | > >not finishing etc. This was caused by the system running out of usable > | > >buffers. The change forces them to be flushed every so often. This is > | > >independant of locking. 10 might be to aggresive. Some scaling of > | > >nbuf would probably be better. > | > > | > When I run mksnap_ffs it runs to the point where ANY access to the > | > filesystem gives that process a lockup. > | > | Yes, that is expected. Actually it begins when something accesses the > | directory in which the snapshot is being made, since that causes the > | parent directory to be locked...then something tries to access the > | parent directory, which eventually cascades back to the root. > | > | > Getting the file system back is only thru "hard reboot". Trying to do it > | > the gentle way locks the whole system. > | > | Or waiting until the snapshot operation finishes. You (still) haven't > | determined that it's actually hanging as opposed to just waiting for > | the snapshot operation to finish. > > In my case is was easy to see that all the buffers were exhausted and > the system was churning waiting for some to become available. Since they > were all used up it never recovered. By sync'ing the buffers they got > cleaned up and then the system never ran out. The snap shot was then > able to finish. Via the debugger you can see this happen. I traced > this problem in the debugger. There are other issues with the buffer > deamon as well. We hit these since we run with a relatively low > nbuf. The buffers can be get frag'ed so bad that it can't flush > things since it can't get a full-size buffer. Another problem is that > it can end up waiting on itself since the current code can't use > it's emergency space to flush stuff. You can see this via ps etc. > It's not a good thing if the buffer daemon is waiting on itself :-( > > We have patches to this as well but they need some more work. I was > working with Tor, on this but then I got swamped at work with our 4.X -> 6.X > and platform transition. All I can say is that we don't suffer from > these problems now :-) I have printf's the log this stuff when some of > these bugs are hit. Now the system survives those lock-up points. Thanks for clarifying. Hopefully you and Tor can get something committed soon! Kris pgpHADe7e0Fpa.pgp Description: PGP signature
Re: running mksnap_ffs
Kris Kennaway writes: | On Tue, Jan 16, 2007 at 09:26:47PM +0100, Willem Jan Withagen wrote: | > Doug Ambrisko wrote: | > >| > or things can get wedged. We have some other patches as well that | > >might | > >| > be required. As a hack on a local server we have been using snap shots | > >| > to do a "hot" back-up of a data base each morning. This is based on | > >| > 6.x. | > >| | > >| What do you mean by "get wedged"? Are you seeing a deadlock, and if | > >| so then what are the details? When you say 6.x, do you mean | > >| up-to-date RELENG_6? There were various snapshot deadlock fixes | > >| committed over the past year including some in the past few months. | > > | > >The file-system would come to a stop, processes stuck on bio, snap-shots | > >not finishing etc. This was caused by the system running out of usable | > >buffers. The change forces them to be flushed every so often. This is | > >independant of locking. 10 might be to aggresive. Some scaling of | > >nbuf would probably be better. | > | > When I run mksnap_ffs it runs to the point where ANY access to the | > filesystem gives that process a lockup. | | Yes, that is expected. Actually it begins when something accesses the | directory in which the snapshot is being made, since that causes the | parent directory to be locked...then something tries to access the | parent directory, which eventually cascades back to the root. | | > Getting the file system back is only thru "hard reboot". Trying to do it | > the gentle way locks the whole system. | | Or waiting until the snapshot operation finishes. You (still) haven't | determined that it's actually hanging as opposed to just waiting for | the snapshot operation to finish. In my case is was easy to see that all the buffers were exhausted and the system was churning waiting for some to become available. Since they were all used up it never recovered. By sync'ing the buffers they got cleaned up and then the system never ran out. The snap shot was then able to finish. Via the debugger you can see this happen. I traced this problem in the debugger. There are other issues with the buffer deamon as well. We hit these since we run with a relatively low nbuf. The buffers can be get frag'ed so bad that it can't flush things since it can't get a full-size buffer. Another problem is that it can end up waiting on itself since the current code can't use it's emergency space to flush stuff. You can see this via ps etc. It's not a good thing if the buffer daemon is waiting on itself :-( We have patches to this as well but they need some more work. I was working with Tor, on this but then I got swamped at work with our 4.X -> 6.X and platform transition. All I can say is that we don't suffer from these problems now :-) I have printf's the log this stuff when some of these bugs are hit. Now the system survives those lock-up points. Doug A. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: can we resurrect linux-firefox-1.5 ?
On Tue, 16 Jan 2007 11:09:35 -0800 Luigi Rizzo <[EMAIL PROTECTED]> wrote: > the many times i tried (up to a few months ago and with 1.0.5 or > 1.0.7) it crashed randomly while browsing, within a few hours of use, > and this was enough for me to give up. First: I find that running native firefox _without_ the flash plugin improves the stability a lot. I don't really *need* flash, so I can live with that. YMMV. Second; firefox crashes happens a lot rarer now that they useed to do. This is from my main workstation: [EMAIL PROTECTED] uname -a FreeBSD kg-work.kg4.no 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #1: Sat Nov 18 13:59:20 CET 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SS51G i386 [EMAIL PROTECTED] uptime 10:03PM up 29 days, 21:23, 15 users, load averages: 0.14, 0.42, 0.53 [EMAIL PROTECTED] ls -l /var/log/mess* -rw-r--r-- 1 root wheel 7873 Jan 14 23:55 /var/log/messages -rw-r--r-- 1 root wheel 11134 Jan 1 23:00 /var/log/messages.0.bz2 -rw-r--r-- 1 root wheel 6887 Nov 14 21:00 /var/log/messages.1.bz2 -rw-r--r-- 1 root wheel 4194 Nov 1 01:00 /var/log/messages.2.bz2 -rw-r--r-- 1 root wheel 8962 Oct 23 18:00 /var/log/messages.3.bz2 [EMAIL PROTECTED] bzgrep firefox /var/log/mess* /var/log/messages.0.bz2:Nov 18 11:43:26 kg-work kernel: pid 2180 (firefox-bin), uid 1001: exited on signal 10 (core dumped) /var/log/messages.0.bz2:Dec 8 19:31:58 kg-work kernel: pid 22038 (firefox-bin), uid 1001: exited on signal 10 (core dumped) Third, some time ago (perhaps with version 2.0.0?) firefox gained the "restore session" capability, which also helps. > Additionally, i could not find a way to make the flash plugin > work, which is a major annoyance given the amount of flash content > that one finds in the services i use daily (some work related too). If linux-firefox isn't working for youhere, I really don't have any good suggestions. I would prefer that a stable, working flash plugin for native firefox, which would install with a simple portinstall. A man can dream, can't he? > firefox is not one of the most reliable applications around, > but these days using a browser is a necessary evil for just too many > things (including 'paperwork' that you have to do for your job, bank, > bills and so on). There was an informal survey in a norwegian newgroup last week; it seems that most (but not all) Norwegian internet-banking (web banking) solutions work fine with Firefox, Opera and other browsers. -- Regards, Torfinn Ingolfsen, Norway ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: running mksnap_ffs
Doug Ambrisko wrote: | > or things can get wedged. We have some other patches as well that might | > be required. As a hack on a local server we have been using snap shots | > to do a "hot" back-up of a data base each morning. This is based on | > 6.x. | | What do you mean by "get wedged"? Are you seeing a deadlock, and if | so then what are the details? When you say 6.x, do you mean | up-to-date RELENG_6? There were various snapshot deadlock fixes | committed over the past year including some in the past few months. The file-system would come to a stop, processes stuck on bio, snap-shots not finishing etc. This was caused by the system running out of usable buffers. The change forces them to be flushed every so often. This is independant of locking. 10 might be to aggresive. Some scaling of nbuf would probably be better. When I run mksnap_ffs it runs to the point where ANY access to the filesystem gives that process a lockup. Getting the file system back is only thru "hard reboot". Trying to do it the gentle way locks the whole system. I'm refering further testing and trying until I have more time to upgrade to 6.2-RELEASE and put some of the debug options in the kernel. On the otherhand is this my main fileserver. So testing too much is sort of dangerous, and running a fsck on 1.5T is very tedious. --WjW ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: running mksnap_ffs
Kris Kennaway wrote: .. The file-system would come to a stop, processes stuck on bio, snap-shots not finishing etc. This was caused by the system running out of usable buffers. The change forces them to be flushed every so often. This is independant of locking. 10 might be to aggresive. Some scaling of nbuf would probably be better. When I run mksnap_ffs it runs to the point where ANY access to the filesystem gives that process a lockup. Yes, that is expected. Actually it begins when something accesses the directory in which the snapshot is being made, since that causes the parent directory to be locked...then something tries to access the parent directory, which eventually cascades back to the root. Getting the file system back is only thru "hard reboot". Trying to do it the gentle way locks the whole system. Or waiting until the snapshot operation finishes. You (still) haven't determined that it's actually hanging as opposed to just waiting for the snapshot operation to finish. True, and that is what I was refering to. * I've let it run for 12 hours on 1,5T (that's why I asked for other experiences) * I looked at diskstats with gstat: that turned out that everything was idle for > 5 minutes Then I concluded that it was locked. IF you can give me a fair estimate of time < 1 day I'll be willing to let it sit for so long. But I'm not going to wait forever. :) --WjW ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: running mksnap_ffs
On Tue, Jan 16, 2007 at 09:26:47PM +0100, Willem Jan Withagen wrote: > Doug Ambrisko wrote: > >| > or things can get wedged. We have some other patches as well that > >might > >| > be required. As a hack on a local server we have been using snap shots > >| > to do a "hot" back-up of a data base each morning. This is based on > >| > 6.x. > >| > >| What do you mean by "get wedged"? Are you seeing a deadlock, and if > >| so then what are the details? When you say 6.x, do you mean > >| up-to-date RELENG_6? There were various snapshot deadlock fixes > >| committed over the past year including some in the past few months. > > > >The file-system would come to a stop, processes stuck on bio, snap-shots > >not finishing etc. This was caused by the system running out of usable > >buffers. The change forces them to be flushed every so often. This is > >independant of locking. 10 might be to aggresive. Some scaling of > >nbuf would probably be better. > > When I run mksnap_ffs it runs to the point where ANY access to the > filesystem gives that process a lockup. Yes, that is expected. Actually it begins when something accesses the directory in which the snapshot is being made, since that causes the parent directory to be locked...then something tries to access the parent directory, which eventually cascades back to the root. > Getting the file system back is only thru "hard reboot". Trying to do it > the gentle way locks the whole system. Or waiting until the snapshot operation finishes. You (still) haven't determined that it's actually hanging as opposed to just waiting for the snapshot operation to finish. Kris pgpKqk209RvS8.pgp Description: PGP signature
Re: freebsd-stable Digest, Vol 189, Issue 4
On 1/16/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Message: 13 Date: Tue, 16 Jan 2007 01:06:45 -0800 From: Luigi Rizzo <[EMAIL PROTECTED]> Subject: can we resurrect linux-firefox-1.5 ? To: [EMAIL PROTECTED] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=us-ascii [sorry if i don't post this to -ports, but i feel that this is really a -stable issue as it affects one widely used port] I am not sure if i am the only one, but on RELENG_6, linux-firefox 2 is basically unusable (see details below), while linux-firefox 1.5 is at least usable (even though it has some memory leak so after a while its size grows well above 3-400MB). Would it be possible to resurrect the linux-firefox 1.5 port (under a separate name) so at least people have a choice on which set of bugs they prefer ? The problems with linux firefox 2.0 are that after a little bit of browsing (let's say 50-100 pages) some of its threads seem to lock up, functions on the gui stop working (e.g. clicking on the tabs does not work anymore) and in the end you have to kill it hard. I have submitted a PR with more details. http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/107219 cheers luigi Install 6.2 from cd and don't update the ports. The 1.5 port is there. Only after I updated the ports it installed the new 2.0.0.1 port. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Dell hardware raid 0 (sas5ir) or gmirror?
Joe Koberg writes: | Josef Karthauser wrote: | > On Mon, Jan 15, 2007 at 11:21:06AM +, Josef Karthauser wrote: | >> I'm purchasing a new server, and was wondering what anyone thought | >> about whether to pay extra for the SAS5IR card so I can RAID0 the | >> two drives, or whether to just rely on gmirror. My worry about the | >> former is that I can't seem to find management tools for | >> controlling the hardware controller. What if one of the drives | >> fails? How would I know? | > | > Of course I mean RAID1! | | I just bought two Dell PE-1950's to use as routers. They have LSI Logic | PERC/5i's attached to 80GB SATA drives. I am pretty sure this is the | same card used for SAS. | | One thing is for sure, the mfi(4) card and driver aren't shy! See below | for examples of the kernel messages I get regularly. I am sure drive | failure would be well noted. FYI, you can silence it to your level of comfort via: hw.mfi.event_class in /boot/loader.conf. The values being: MFI_EVT_CLASS_DEBUG = -2, MFI_EVT_CLASS_PROGRESS =-1, MFI_EVT_CLASS_INFO =0, MFI_EVT_CLASS_WARNING = 1, MFI_EVT_CLASS_CRITICAL =2, MFI_EVT_CLASS_FATAL = 3, MFI_EVT_CLASS_DEAD =4 The new default is info. so it's a little quieter. I'd suggest some care in going over info since a drive that failed will come through but when it is now okay will not. So if you are waiting for that you won't know. Here, we like the debug and progress stuff put into /var/log/messages. It makes support a lot easier. Doug A. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: can we resurrect linux-firefox-1.5 ?
Mate If you had any idea how many RFC's IE violates and and how many bugs there are in it you would never have made a statement like that. Using firefox in windows even will save you from a lot of malware and other bugs that are floating around online. -Clay - Original Message - From: "Luigi Rizzo" <[EMAIL PROTECTED]> To: "Torfinn Ingolfsen" <[EMAIL PROTECTED]> Cc: Sent: Tuesday, January 16, 2007 8:09 PM Subject: Re: can we resurrect linux-firefox-1.5 ? On Tue, Jan 16, 2007 at 07:37:22PM +0100, Torfinn Ingolfsen wrote: On Tue, 16 Jan 2007 01:06:45 -0800 Luigi Rizzo <[EMAIL PROTECTED]> wrote: > Would it be possible to resurrect the linux-firefox 1.5 > port (under a separate name) so at least people have a choice > on which set of bugs they prefer ? What makes native firefox unsuitable for you? Have not tried recently, i admit, but the many times i tried (up to a few months ago and with 1.0.5 or 1.0.7) it crashed randomly while browsing, within a few hours of use, and this was enough for me to give up. Additionally, i could not find a way to make the flash plugin work, which is a major annoyance given the amount of flash content that one finds in the services i use daily (some work related too). firefox is not one of the most reliable applications around, but these days using a browser is a necessary evil for just too many things (including 'paperwork' that you have to do for your job, bank, bills and so on). It is already enough of a pain to do this as a non-Explorer user; i don't want also the impairment of a crippled firefox! cheers luigi ___ 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: can we resurrect linux-firefox-1.5 ?
On Tue, Jan 16, 2007 at 07:37:22PM +0100, Torfinn Ingolfsen wrote: > On Tue, 16 Jan 2007 01:06:45 -0800 > Luigi Rizzo <[EMAIL PROTECTED]> wrote: > > > Would it be possible to resurrect the linux-firefox 1.5 > > port (under a separate name) so at least people have a choice > > on which set of bugs they prefer ? > > What makes native firefox unsuitable for you? Have not tried recently, i admit, but the many times i tried (up to a few months ago and with 1.0.5 or 1.0.7) it crashed randomly while browsing, within a few hours of use, and this was enough for me to give up. Additionally, i could not find a way to make the flash plugin work, which is a major annoyance given the amount of flash content that one finds in the services i use daily (some work related too). firefox is not one of the most reliable applications around, but these days using a browser is a necessary evil for just too many things (including 'paperwork' that you have to do for your job, bank, bills and so on). It is already enough of a pain to do this as a non-Explorer user; i don't want also the impairment of a crippled firefox! cheers luigi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: running mksnap_ffs
Kris Kennaway writes: | On Tue, Jan 16, 2007 at 10:13:57AM -0800, Doug Ambrisko wrote: | | > FWIW, with this patch I find making snap-shots a lot more reliable: | > | > --- sys/ufs/ffs/ffs_snapshot.c.orig Wed Mar 22 09:42:31 2006 | > +++ sys/ufs/ffs/ffs_snapshot.c Mon Nov 20 14:59:13 2006 | > @@ -282,6 +282,8 @@ restart: | > if (error) | > goto out; | > bawrite(nbp); | > + if (cg % 10 == 0) | > + ffs_syncvnode(vp, MNT_WAIT); | > } | > /* | > * Copy all the cylinder group maps. Although the | > @@ -303,6 +305,8 @@ restart: | > goto out; | > error = cgaccount(cg, vp, nbp, 1); | > bawrite(nbp); | > + if (cg % 10 == 0) | > + ffs_syncvnode(vp, MNT_WAIT); | > if (error) | > goto out; | > } | > | > or things can get wedged. We have some other patches as well that might | > be required. As a hack on a local server we have been using snap shots | > to do a "hot" back-up of a data base each morning. This is based on | > 6.x. | | What do you mean by "get wedged"? Are you seeing a deadlock, and if | so then what are the details? When you say 6.x, do you mean | up-to-date RELENG_6? There were various snapshot deadlock fixes | committed over the past year including some in the past few months. The file-system would come to a stop, processes stuck on bio, snap-shots not finishing etc. This was caused by the system running out of usable buffers. The change forces them to be flushed every so often. This is independant of locking. 10 might be to aggresive. Some scaling of nbuf would probably be better. Doug A. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Dell 1955 Blade - Broadcom NIC not detected (BCM5708S)
*** Click here to view our e-mail legal notice: http://www.mxit.co.za/pdfs/mxit_legal.pdf or call: +27 21 888 5000 *** If you have an alpha or beta version of the bce driver that supports serdes, please let me know and I'll start testing right away! Regards Conrad -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Morten A. Middelthon Sent: 16 January 2007 08:56 AM To: David Christensen Cc: freebsd-stable@freebsd.org; Roar Pettersen Subject: Re: Dell 1955 Blade - Broadcom NIC not detected (BCM5708S) On Mon, Jan 15, 2007 at 09:16:16AM -0800, David Christensen wrote: > > Hello Dave ! > > > > >Wed Nov 1 18:54:19 UTC 2006 > > > > > >Yes, the Linux bnx2 driver does support SerDes. I don't have the > > >bandwidth to tackle this feature until after the first of the year, > > >though a few other people have also considered looking into adding > > >the support. > > > > > > Any news or status report regarding support for this new > > network interface > > in FreeBSD ? > > I've copied Doug White who is working to add SerDes support to bce. I'm _really_ looking forward to getting SerDes support in the bce-driver :) -- Morten A. Middelthon Remember: Silly is a state of Mind, Stupid is a way of Life. -- Dave Butler ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: running mksnap_ffs
On Tue, Jan 16, 2007 at 10:13:57AM -0800, Doug Ambrisko wrote: > FWIW, with this patch I find making snap-shots a lot more reliable: > > --- sys/ufs/ffs/ffs_snapshot.c.orig Wed Mar 22 09:42:31 2006 > +++ sys/ufs/ffs/ffs_snapshot.cMon Nov 20 14:59:13 2006 > @@ -282,6 +282,8 @@ restart: > if (error) > goto out; > bawrite(nbp); > + if (cg % 10 == 0) > + ffs_syncvnode(vp, MNT_WAIT); > } > /* >* Copy all the cylinder group maps. Although the > @@ -303,6 +305,8 @@ restart: > goto out; > error = cgaccount(cg, vp, nbp, 1); > bawrite(nbp); > + if (cg % 10 == 0) > + ffs_syncvnode(vp, MNT_WAIT); > if (error) > goto out; > } > > or things can get wedged. We have some other patches as well that might > be required. As a hack on a local server we have been using snap shots > to do a "hot" back-up of a data base each morning. This is based on > 6.x. What do you mean by "get wedged"? Are you seeing a deadlock, and if so then what are the details? When you say 6.x, do you mean up-to-date RELENG_6? There were various snapshot deadlock fixes committed over the past year including some in the past few months. Kris pgpFAdfdGDyph.pgp Description: PGP signature
Re: running mksnap_ffs
Scott Oertel writes: | Kris Kennaway wrote: | > On Tue, Jan 02, 2007 at 09:06:24PM +0100, Willem Jan Withagen wrote: | > | >> Hi, | >> | >> I got the following Filesystem: | >> FilesystemSizeUsed Avail Capacity iused ifree %iused | >> /dev/da0a 1.3T422G823G34% 565952 1828334700% | >> | >> Running of a 3ware 9550, on a dual core Opteron 242 with 1Gb. | >> The system is used as SMB/NFS server for my other systems here. | >> | >> I would like to make weekly snapshots, but manually running mksnap_ffs | >> freezes access to the disk (I sort of expected that) but the process | >> never terminates. So I let is sit overnight, but looking a gstat did not | >> reveil any activity what so ever... | >> The disk was not released, mksnap_ffs could not be terminated. | >> And things resulted in me rebooting the system. | >> | >> So: | >> - How long should I expect making a snapshot to take: | >>5, 15, 30min, 1, 2 hour or even more??? | > | > Yes :) Snapshots were not designed for use in this way (they were | > designed to support background fsck and allow faster system recovery | > after power failure), so they don't scale as well as you might like on | > large filesystems. | | If snapshots were designed to support background fsck, then why did they | not make it more scalable? If you can't create a snapshot without the | system locking up, that means fsck won't be able to either, making | background fsck worthless for systems with large storage. FWIW, with this patch I find making snap-shots a lot more reliable: --- sys/ufs/ffs/ffs_snapshot.c.orig Wed Mar 22 09:42:31 2006 +++ sys/ufs/ffs/ffs_snapshot.c Mon Nov 20 14:59:13 2006 @@ -282,6 +282,8 @@ restart: if (error) goto out; bawrite(nbp); + if (cg % 10 == 0) + ffs_syncvnode(vp, MNT_WAIT); } /* * Copy all the cylinder group maps. Although the @@ -303,6 +305,8 @@ restart: goto out; error = cgaccount(cg, vp, nbp, 1); bawrite(nbp); + if (cg % 10 == 0) + ffs_syncvnode(vp, MNT_WAIT); if (error) goto out; } or things can get wedged. We have some other patches as well that might be required. As a hack on a local server we have been using snap shots to do a "hot" back-up of a data base each morning. This is based on 6.x. Doug A. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: can we resurrect linux-firefox-1.5 ?
On Tue, 16 Jan 2007 01:06:45 -0800 Luigi Rizzo <[EMAIL PROTECTED]> wrote: > Would it be possible to resurrect the linux-firefox 1.5 > port (under a separate name) so at least people have a choice > on which set of bugs they prefer ? What makes native firefox unsuitable for you? -- Regards, Torfinn Ingolfsen, Norway ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
6.2-RELEASE em0 watchdog timeouts -- sometimes (w/ partial workaround)
I have a strange issue with em0 watchdog timeouts that I think is not the same as the ones everyone was having during the 6.2 beta cycle... I have six systems, each with two Intel GigE ports onboard: Systems A and B: Supermicro PDSMi+ Systems C and D: Supermicro PDSMi (without the plus) System E: Tyan S2730U3GN System F: Supermicro X5DPA-GG On each system: em0 is connected to a Cisco Catalyst 2960G layer 2 gigabit ethernet switch. em1 is connected to a Foundry Serveriron XL layer 4-7 fast ethernet switch. All six run FreeBSD 6.2-RELEASE i386, even though the first four are capable of running amd64. They all have 2 GB of memory, except E which has 4 GB. The kernel configs are all identical, and are not that far from GENERIC + SMP. Several times a day, em0 will go down, give a watchdog timeout error on the console, then come right back up on its own a few seconds later. But here's the weird twist: it ONLY happens on systems A and B, and ONLY when running at gigabit speed. If I knock the two switch ports down to 100 meg, the problem goes away. The other four systems C thru F never have watchdog timeout issues; they always work perfectly even at gigabit speed. So I'm trying to figure out if there are any other obvious hardware differences between the plus and non-plus version of the PDSMi that would be causing issues on the plus version. Fortunately, at the moment we are not (yet) pushing anywhere near even 100 meg worth of traffic through these ports, so it's a tolerable workaround... just kinda annoying. :) The chipset is a bit different: the PDSMi is the Intel E7230 chipset for Pentium D servers, where the PDSMi+ is the E3000 that adds Core 2 Duo support. But apparently the NIC chips are identical: 82573V for em0 and 82573L for em1. The BIOS is identical too, so the chipsets must be pretty similar. Nothing shares an IRQ with the NICs. (USB is disabled in the BIOS.) They do have different disk systems; A and B are SATA gmirror setups, while C and D use LSI Megaraid SCSI cards for their mirrors. I have tried the obvious switching the cables out. No difference at all. I have NOT yet tried a different gigabit switch. Hopefully that's enough detail to start; I can get into more specifics as needed. (Kernel configs, dmesg output, IRQ details, disk details, IPMI, running apps, serial console access if needed...) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.2 & nvidia x11 driver: weird 16bpp/24bpp colorspace damage
On Monday 15 January 2007 19:42, Daniel O'Connor wrote: > On Tuesday 16 January 2007 09:03, Patrick Reich wrote: > > Wishful thinking: Too bad there isn't an nvidia-driver-legacy port. > > It wouldn't be too much work to split the current port into 3 separate ones > for this purpose. > > Then you could send-pr and someone could commit it :) There's already a PR open (and assigned to danfe@) that recommends this approach (ports/107717) but doesn't include any patches. Actually doing the work would go a long way toward getting it committed. JN ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
lirc serial FreeBSD
Dear All, i have a serial IR receiver and i am looking for lirc support for serial ir device in freebsd is there solutions already made ? or any other alternatives? Thanks & Regards Krishna ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
make release on RELENG_6 broken with russian handbook build error
Hi, list
More them half year I'm using same script for generating my own
releases and all time it's works fine.
Today I tried to make release with
RELEASE="RELENG_6"
DATE="01/16/2007 00:00:00 UTC"
and get error:
---
===> ru_RU.KOI8-R/books/handbook (all)
/bin/mkdir -p /usr/doc/ru_RU.KOI8-R/share/sgml
env SGML_CATALOG_FILES=
XML_CATALOG_FILES="file:///usr/doc/ru_RU.KOI8-R/books/handbook/catalog-cwd.xml
file:///usr/doc/ru_RU.KOI8-R/share/sgml/catalog.xml file:///usr/
doc/ru_RU.KOI8-R/share/sgml/catalog.xml file:///usr/doc/share/sgml/catalog.xml
file:///usr/doc/share/sgml/catalog-common.xml
file:///usr/www/./share/sgml/catalog.xml
file:///usr/www/share/sgml/catalog.xml
file:///usr/www/share/sgml/catalog-common.xml
file:///usr/local/share/xml/catalog" /usr/local/bin/xsltproc --nonet --param
'tr
anstable.xml' "'/usr/doc/ru_RU.KOI8-R/share/sgml/transtable.xml'" --param
'transtable-target-element' "'country'" --param 'transtable-word-group'
"'country'" --param
'transtable-mode' "'sortkey'"
/usr/doc/ru_RU.KOI8-R/share/sgml/transtable-local.xsl
/usr/doc/share/sgml/mirrors.xml | env -i LANG="ru_RU.KOI8-R" /usr/bin/sort -f
> /us
r/doc/ru_RU.KOI8-R/share/sgml/mirrors.xml.sort.tmp
env -i /usr/bin/grep "^
/usr/doc/ru_RU.KOI8-R/share/sgml/mirrors.xml.sort
echo "" >> /usr/doc/ru_RU.KOI8-R/share/sgml/mirrors.xml.sort
env -i /usr/bin/awk '/@sortkey@/ {sub(/@sortkey@/, ++line); print;}' <
/usr/doc/ru_RU.KOI8-R/share/sgml/mirrors.xml.sort.tmp >>
/usr/doc/ru_RU.KOI8-R/share/sgml/mirrors.
xml.sort
echo '' >> /usr/doc/ru_RU.KOI8-R/share/sgml/mirrors.xml.sort
env SGML_CATALOG_FILES=
XML_CATALOG_FILES="file:///usr/doc/ru_RU.KOI8-R/books/handbook/catalog-cwd.xml
file:///usr/doc/ru_RU.KOI8-R/share/sgml/catalog.xml file:///usr/
doc/ru_RU.KOI8-R/share/sgml/catalog.xml file:///usr/doc/share/sgml/catalog.xml
file:///usr/doc/share/sgml/catalog-common.xml
file:///usr/www/./share/sgml/catalog.xml
file:///usr/www/share/sgml/catalog.xml
file:///usr/www/share/sgml/catalog-common.xml
file:///usr/local/share/xml/catalog" /usr/local/bin/xsltproc --nonet -o
/usr/doc/
ru_RU.KOI8-R/share/sgml/mirrors.xml --param 'transtable.xml'
"'/usr/doc/ru_RU.KOI8-R/share/sgml/transtable.xml'" --param
'transtable-target-element' "'country'" --par
am 'transtable-word-group' "'country'" --param 'transtable-sortkey.xml'
"'/usr/doc/ru_RU.KOI8-R/share/sgml/mirrors.xml.sort'"
/usr/doc/ru_RU.KOI8-R/share/sgml/transtab
le-local.xsl /usr/doc/share/sgml/mirrors.xml
/bin/rm -f /usr/doc/ru_RU.KOI8-R/share/sgml/mirrors.xml.sort
/usr/doc/ru_RU.KOI8-R/share/sgml/mirrors.xml.sort.tmp
echo '' >
/usr/doc/ru_RU.KOI8-R/books/handbook/autogen.ent
env SGML_CATALOG_FILES=
XML_CATALOG_FILES="file:///usr/doc/ru_RU.KOI8-R/books/handbook/catalog-cwd.xml
file:///usr/doc/ru_RU.KOI8-R/share/sgml/catalog.xml file:///usr/
doc/ru_RU.KOI8-R/share/sgml/catalog.xml file:///usr/doc/share/sgml/catalog.xml
file:///usr/doc/share/sgml/catalog-common.xml
file:///usr/www/./share/sgml/catalog.xml
file:///usr/www/share/sgml/catalog.xml
file:///usr/www/share/sgml/catalog-common.xml
file:///usr/local/share/xml/catalog" /usr/local/bin/xsltproc --nonet -o
mirrors.
sgml.ftp.inc.tmp --param 'type' "'ftp'" --param 'proto' "'ftp'" --param
'target' "'handbook/mirrors/chapter.sgml'" --param transtable.xml
"'/usr/doc/ru_RU.KOI8-R/shar
e/sgml/transtable.xml'" /usr/doc/ru_RU.KOI8-R/share/sgml/mirrors-local.xsl
/usr/doc/ru_RU.KOI8-R/share/sgml/mirrors.xml
runtime error: file /usr/doc/share/sgml/mirrors-master.xsl line 97 element
choose
Variable 'mirrors-docbook-country-index-without-period' has not been declared.
*** Error code 10
Stop in /usr/doc/ru_RU.KOI8-R/books/handbook.
*** Error code 1
Stop in /usr/doc/ru_RU.KOI8-R/books.
*** Error code 1
Stop in /usr/doc/ru_RU.KOI8-R.
*** Error code 1
Stop in /usr/doc.
*** Error code 1
Stop in /usr/src/release.
+ umount /dev
*** Error code 1
Stop in /usr/src/release.
---
Part of script:
---
cd release && make release BUILDNAME=${RELEASE} \
CHROOTDIR=/usr/release \
CVSROOT=/home/ncvs \
EXTSRCDIR=/usr/src \
KERNELS=OILSPACE1 \
MAKE_ISOS=yes \
NOPORTS=yes \
RELEASETAG=${RELEASE} \
WORLD_FLAGS="-j4" \
KERNEL_FLAGS=""
---
Something changes in make release procedure or real bug in russian handbook?
WBR
Dmitriy
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.2 release and atausb
On 1/15/07, Boris Kovalenko <[EMAIL PROTECTED]> wrote: Hello! I also getting strange errors like Jan 15 12:20:58 boris kernel: afd0: FAILURE - PREVENT_ALLOW ILLEGAL REQUEST asc=0x24 ascq=0x00 P.S. How You get 12Mb/s? With my flash Jan 15 12:20:58 boris kernel: da0: Removable Direct Acce ss SCSI-0 device Jan 15 12:20:58 boris kernel: da0: 3.300MB/s transfers I can only reach about 800-900Kbytes/s. On WinXP 2Mbytes/s is the primary speed. May be I've configured something wrong? Please don't top-post ;) I get 12 MBytes/s (sorry for the capitalization confusion) because I'm using a ATA100 drive in an external USB2.0 casing capable of 480Mbit/s. I actually reached just over 50MBytes/s under Windows. Same setup gives 24 MBytes/s under FreeBSD/i386 and 12 under amd64. atausb does not make a difference... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: (audit?) Panic in 6.2-PRERELEASE
On Fri, Jan 05, 2007 at 11:19:55AM +, Ceri Davies wrote: > > For the last two mornings, my system decided to panic() in the exact > same place. I have dumps from both but they almost exactly the same. > Any pointers on where to go next are welcomed. For the record, this turned out to be a thermal issue. Thanks again to Robert for the time he wasted on this. Ceri -- That must be wonderful! I don't understand it at all. -- Moliere pgp9tpYEi9MdH.pgp Description: PGP signature
Re: Dell hardware raid 0 (sas5ir) or gmirror?
On 1/16/07, Stefan Lambrev <[EMAIL PROTECTED]> wrote: Andrew Pantyukhin wrote: > On 1/15/07, Josef Karthauser <[EMAIL PROTECTED]> wrote: >> I'm purchasing a new server, and was wondering what anyone thought about >> whether to pay extra for the SAS5IR card so I can RAID0 the two drives, >> or whether to just rely on gmirror. My worry about the former is that I >> can't seem to find management tools for controlling the hardware >> controller. What if one of the drives fails? How would I know? > > By all means I would go the gmirror way, and I always do > even when a hardware raid controller is already present. I really do not understand this. :) When you say something like this it will be good to explain why you think so. I have few servers with good hw raid controllers and I'm very happy with them, I also use gmirror on my desktop pc, but it is not as good as hw raid on servers for sure. Also it is harder to support it (during OS updates and etc). Also it (gmirror) will put some load on the CPU and hw raid have it's own CPU/memory for this. LSI have a nice tool to monitor/config RAID arrays that just works under fbsd in my case so I'm happy with it. There are a lot of reasons to use hw raids on mission critical servers... As a matter of fact Jonathan was also surprised by my answer. Here's a part of my response to him: = raid3, raid5 and other computation-hungry configu- rations are a cpu hog, that's why people prefer hardware controllers for that. I'm quite sure at some point FreeBSD will gain an ability to use crypto/XOR hardware for the benefit of software raid performance and maybe then software raid5 will become a popular solution. As for raid0/raid1 - there's no cpu penalty at all. gmirror/gstripe in FreeBSD might need further tweaks and optimizations, but benchmarks show that with 2-4 drives performance almost equals the theoretical limits. Reliability of OS-integrated software raid is expected to be even higher than that of hardware one, because there's no hardware to fail and software bugs might be found in all solutions. What I really like about software raid is very high flexibility and manageability. There's no issue of having the right driver or the right userland tool, it just works. And it's a snap to setup. And you are free to experiment with virtual (file-based, for one) file systems before you implement a solution. As always, there are more than one correct opinions. I just expressed my own and I hope my explanation answers some of your interest. = What I would add to answer some of your claims, Stefan, is that there's no single correct solution here. I would argue that money spent on main CPU/RAM are a better investment compared to a hardware raid 0/1 solution, OS buffers are there anyway, so why not make them larger/faster if you need that. As for CPU load, I'd argue it's negligible, at least in 2 SATA HDD situations (which are popular in all markets). For larger configurations, consisting of 5 drives and more I would advise against raid 0/1 and therefore against software raid. If you do continue to use gmirror/gstripe, I would expect some tweaks to be needed, but in general such systems should scale very well, especially on SMP systems, as FreeBSD 6.x brought mpsafe file system access to the table. All in all there are reasons to use hw raids and there are some not to use them. For some reasons I hold our homegrown (FreeBSD) solutions closer to my heart and choose them in favor of 3d-party ones. Cheers! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Dell hardware raid 0 (sas5ir) or gmirror?
Andrew Pantyukhin wrote: On 1/15/07, Josef Karthauser <[EMAIL PROTECTED]> wrote: I'm purchasing a new server, and was wondering what anyone thought about whether to pay extra for the SAS5IR card so I can RAID0 the two drives, or whether to just rely on gmirror. My worry about the former is that I can't seem to find management tools for controlling the hardware controller. What if one of the drives fails? How would I know? By all means I would go the gmirror way, and I always do even when a hardware raid controller is already present. I really do not understand this. :) When you say something like this it will be good to explain why you think so. I have few servers with good hw raid controllers and I'm very happy with them, I also use gmirror on my desktop pc, but it is not as good as hw raid on servers for sure. Also it is harder to support it (during OS updates and etc). Also it (gmirror) will put some load on the CPU and hw raid have it's own CPU/memory for this. LSI have a nice tool to monitor/config RAID arrays that just works under fbsd in my case so I'm happy with it. There are a lot of reasons to use hw raids on mission critical servers... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
can we resurrect linux-firefox-1.5 ?
[sorry if i don't post this to -ports, but i feel that this is really a -stable issue as it affects one widely used port] I am not sure if i am the only one, but on RELENG_6, linux-firefox 2 is basically unusable (see details below), while linux-firefox 1.5 is at least usable (even though it has some memory leak so after a while its size grows well above 3-400MB). Would it be possible to resurrect the linux-firefox 1.5 port (under a separate name) so at least people have a choice on which set of bugs they prefer ? The problems with linux firefox 2.0 are that after a little bit of browsing (let's say 50-100 pages) some of its threads seem to lock up, functions on the gui stop working (e.g. clicking on the tabs does not work anymore) and in the end you have to kill it hard. I have submitted a PR with more details. http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/107219 cheers luigi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
