New em driver - still watchdog timeouts
Hello! Our central backup server is still experiencing the same random problems. The timouts occur every other night or so, when the server has got high CPU load (compressing the backups) and transfers large amounts of data at the same time. Nov 2 02:19:34 datatomb kernel: em1: watchdog timeout -- resetting Nov 2 02:19:34 datatomb kernel: em1: link state changed to DOWN Nov 2 02:19:34 datatomb kernel: vlan23: link state changed to DOWN Nov 2 02:19:34 datatomb kernel: vlan22: link state changed to DOWN Nov 2 02:19:36 datatomb kernel: em1: link state changed to UP Nov 2 02:19:36 datatomb kernel: vlan23: link state changed to UP Nov 2 02:19:36 datatomb kernel: vlan22: link state changed to UP Jack, the hardware should be easy for you or someone else at Intel to get your hands on: http://www.intel.com/design/servers/storage/ssr212cc/index.htm Unfortunately I cannot give you root access to _that_ one. Regards, Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Vorholzstr. 25Tel. 0721 9109 -0 Fax: -100 76137 Karlsruhe http://punkt.de ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SAS Raid - mfi driver
Because the card itself will deal with the buffered writes independently of the kernel activity the risk should be less than using softupdates. Words like "screwed" seems to me to be exaggerated in the generic case. I our case specific you would need to understand the nature of what we are doing to be able to make a comment like that. For example data is redundant (exists in many copies), consists of very large sequencial files, we have plenty of backup power, and the greatest risk is fbsd locking up/crashing. Anyway our specific case is not of interest here, I just wanted to share our experiences with the LSI MegaSAS with other fbsd users so they understand why they get a severe performance degradation if they try to use such a card w/o a bbu, and what their options are. The generic case of how great the risk really is of corrupting filesystems completely using caches of any kind on the way to secondary storage still is interesting to me, so if you could elaborate here that would be great! Kind regards, Fredrik Widlund Bob Willcox wrote: > On Wed, Nov 01, 2006 at 12:34:22AM +0100, Fredrik Widlund wrote: > >> Yes, it forces writeback even when the controller has no BBU. Choosing >> WBack itself will default back to WThru. It's dangerous, but I guess it >> should be much less dangerous than using for example softupdates. >> > > I don't see how it could be *less* dangerous than using softupdates. Any > loss of power while writing and it seems to me that you are going to be > screwed w/o a BBU. > > [snip] > > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
gbde breaks buildworld
With a freshly checked-out tree from yesterday I still get the same error when running "make buildworld" on sparc64 6.1-RELEASE-p7. mkdep -f .depend -a-I/usr/src/sbin/gbde/../../sys -DRESCUE /usr/src/sbin/gbde/gbde.c template.c /usr/src/sbin/gbde/../../sys/crypto/rijndael/rijndael-alg-fst.c /usr/src/sbin/gbde/../../sys/crypto/rijndael/rijndael-api-fst.c /usr/src/sbin/gbde/../../sys/crypto/sha2/sha2.c /usr/src/sbin/gbde/../../sys/geom/bde/g_bde_lock.c echo gbde: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/src/tmp/usr/lib/libmd.a /usr/obj/usr/src/tmp/usr/lib/libutil.a /usr/obj/usr/src/tmp/usr/lib/libgeom.a >> .depend cc -O2 -fno-strict-aliasing -pipe -I/usr/src/sbin/gbde/../../sys -DRESCUE -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -c /usr/src/sbin/gbde/gbde.c /usr/src/sbin/gbde/gbde.c: In function `g_read_data': /usr/src/sbin/gbde/gbde.c:164: warning: implicit declaration of function `read' /usr/src/sbin/gbde/gbde.c: In function `setup_passphrase': /usr/src/sbin/gbde/gbde.c:216: warning: implicit declaration of function `close' /usr/src/sbin/gbde/gbde.c: In function `cmd_nuke': /usr/src/sbin/gbde/gbde.c:391: warning: implicit declaration of function `write' /usr/src/sbin/gbde/gbde.c: In function `cmd_init': /usr/src/sbin/gbde/gbde.c:556: warning: implicit declaration of function `unlink' /usr/src/sbin/gbde/gbde.c: In function `main': /usr/src/sbin/gbde/gbde.c:801: warning: implicit declaration of function `getopt' /usr/src/sbin/gbde/gbde.c:804: error: `optarg' undeclared (first use in this function) /usr/src/sbin/gbde/gbde.c:804: error: (Each undeclared identifier is reported only once /usr/src/sbin/gbde/gbde.c:804: error: for each function it appears in.) *** Error code 1 Stop in /usr/src/sbin/gbde. *** Error code 1 Stop in /usr/obj/usr/src/rescue/rescue. *** Error code 1 Stop in /usr/src/rescue/rescue. *** Error code 1 Stop in /usr/src/rescue. *** Error code 1 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FW: Zoneli State / Nttcp client.
-Original Message- From: LI Xin [mailto:[EMAIL PROTECTED] Sent: Thursday, November 02, 2006 6:26 PM To: SIVAKUMAR SUBRAMANI (WT01 - Computing Systems & Storage) Subject: Re: Zoneli State / Nttcp client. Hi, [EMAIL PROTECTED] wrote: > Hi, > > I have a script where we start a nttcp for some 500 nttcp client in > back ground. After some time I could see the nttcp clients are listed > in the TOP command as "Zoneli" state. Can any one please let me know > what is meant by Zoneli state? Would you please also post this to [EMAIL PROTECTED] Thanks in advance! Cheers, -- Xin LI <[EMAIL PROTECTED]> http://www.delphij.net/ FreeBSD - The Power to Serve! The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com signature.asc Description: 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: FW: Zoneli State / Nttcp client.
To quote the original post: Hi, I have a script where we start a nttcp for some 500 nttcp client in back ground. After some time I could see the nttcp clients are listed in the TOP command as "Zoneli" state. Can any one please let me know what is meant by Zoneli state? Test Script: = count=1 while [ $count -le 2000 ] do ifconfig xge1 17.1.1.25 promisc up ./nttcp -t -l65536 -w227 -P120 17.1.1.152 & echo "count is $count" count=`expr $count + 1` done Thanks, ~Siva The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com ast pid: 6790; load averages: 0.00, 0.00, 0.28 up 0+00:56:58 17:57:26 229 processes: 1 starting, 1 running, 227 sleeping CPU states: 0.4% user, 0.0% nice, 0.4% system, 1.1% interrupt, 98.1% idle Mem: 48M Active, 6368K Inact, 138M Wired, 9184K Buf, 804M Free Swap: 487M Total, 487M Free PID USERNAME THR PRI NICE SIZERES STATETIME WCPU COMMAND 6664 root1 60 0K 0K START0:04 0.00% login 6756 root1 960 2700K 1976K select 0:02 0.00% top 642 root1 60 1272K 888K ttywri 0:00 0.00% vmstat 304 root1 960 1292K 852K select 0:00 0.00% syslogd 540 root1 960 3152K 2260K select 0:00 0.00% telnetd 525 root1 -160 3152K 2232K zoneli 0:00 0.00% telnetd 6790 root1 960 2636K 1912K RUN 0:00 0.00% top 6663 root1 -160 3152K 2260K zoneli 0:00 0.00% telnetd 5870 214748361 -160 1332K 1008K zoneli 0:00 0.00% nttcp 6329 214748361 -160 1332K 1008K zoneli 0:00 0.00% nttcp 6221 214748361 -160 1332K 1008K zoneli 0:00 0.00% nttcp 662 214748361 -160 1332K 1008K zoneli 0:00 0.00% nttcp 668 214748361 -160 1332K 1008K zoneli 0:00 0.00% nttcp 512 root1 80 1620K 1324K wait 0:00 0.00% login 1382 214748361 -160 1332K 1008K zoneli 0:00 0.00% nttcp 511 root1 -160 3152K 2232K zoneli 0:00 0.00% telnetd 545 root1 200 3872K 2632K pause0:00 0.00% csh 1433 214748361 -160 1332K 1008K zoneli 0:00 0.00% nttcp 1418 214748361 -160 1332K 1008K zoneli 0:00 0.00% nttcp 1415 214748361 -160 1332K 1008K zoneli 0:00 0.00% nttcp 5747 214748361 -160 1332K 1008K zoneli 0:00 0.00% nttcp 6760 root1 960 3152K 2260K select 0:00 0.00% telnetd 3653 214748361 -160 1332K 1008K zoneli 0:00 0.00% nttcp 1211 214748361 -160 1332K 1008K zoneli 0:00 0.00% nttcp 6765 root1 200 3872K 2636K pause0:00 0.00% csh 516 root1 200 3868K 2600K pause0:00 0.00% csh 530 root1 50 3868K 2600K ttyin0:00 0.00% csh 500 root1 80 1592K 1280K wait 0:00 0.00% login 6632 214748361 -160 1332K 1008K zoneli 0:00 0.00% nttcp 6452 214748361 -160 1332K 1008K zoneli 0:00 0.00% nttcp 1667 214748361 -160 1332K 1008K zoneli 0:00 0.00% nttcp 3578 214748361 -160 1332K 1008K zoneli 0:00 0.00% nttcp 1814 214748361 -160 1332K 1008K zoneli 0:00 0.00% nttcp 6413 214748361 -160 1332K 1008K zoneli 0:00 0.00% nttcp 1562 214748361 -160 1332K 1008K zoneli 0:00 0.00% nttcp Cheers, -- Xin LI <[EMAIL PROTECTED]> http://www.delphij.net/ FreeBSD - The Power to Serve! signature.asc Description: OpenPGP digital signature
Problem with the installer sysinstall.
Hello, today i have installed FreeBSD-6.2 BETA2 amd-64 on a Core 2 Duo machine with an ASUS P5LD2-VM mobo. I have encountered the following bug from the installer: it wrote an fstab file with all the disk entries on ad4, while the disk is on ad8. Hence when i rebooted, after install, root filesystem could not be found. I had to fiddle at the prompt to get the machine to boot, and then hand edit /etc/fstab. Obviously this would have been a "showstopper" for a newbie. By the way another minor problem is that the audio does not work. According to the mobo manual, it is a Realtek ALC882 audio chip. None of the sound modules have recognized the chip. Sound works under Linux. All in one this has been a wonderful experience, except for sound FreeBSD amd-64 works perfectly on the machine, i had no problem with the em chip, and the machine is incredibly fast. I have also booted the last FREESBIE cdrom, the integrated Intel video works no problem with the i810 driver. Even glxgears is not totally ridiculous, it's around 1000. The 2D performance is perfectly crisp and fine. I am joining the dmesg for reference. -- Michel TALON Copyright (c) 1992-2006 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-BETA2 #0: Mon Oct 2 03:47:17 UTC 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 CPU 6700 @ 2.66GHz (2659.96-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 Features=0xbfebfbff Features2=0xe3bd,CX16,,> AMD Features=0x2800 AMD Features2=0x1 Cores per package: 2 real memory = 2138701824 (2039 MB) avail memory = 2053550080 (1958 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 acpi_perf0: on cpu0 acpi_throttle0: on cpu0 cpu1: on acpi0 acpi_throttle1: on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 2.0 (no driver attached) pci0: at device 27.0 (no driver attached) pcib1: irq 16 at device 28.0 on pci0 pci3: on pcib1 pcib2: irq 17 at device 28.1 on pci0 pci2: on pcib2 em0: port 0xd800-0xd81f mem 0xcffe-0xcfff irq 17 at device 0.0 on pci2 em0: Ethernet address: 00:17:31:55:9d:99 em0: [FAST] uhci0: port 0x8000-0x801f irq 20 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x8400-0x841f irq 17 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x8800-0x881f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x9000-0x901f irq 19 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xcfdffc00-0xcfdf irq 20 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered pcib3: at device 30.0 on pci0 pci1: on pcib3 atapci0: port 0xc800-0xc807,0xc400-0xc403,0xc000-0xc007,0xb800-0xb803,0xb400-0xb40f irq 19 at device 4.0 on pci1 ata2: on atapci0 ata3: on atapci0 isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0 ata0: on atapci1 ata1: on atapci1 atapci2: port 0xa800-0xa807,0xa400-0xa403,0xa000-0xa007,0x9800-0x9803,0x9400-0x940f irq 17 at device 31.2 on pci0 ata4: on atapci2 ata5: on atapci2 pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: port 0x378-0x
Re: Problem with the installer sysinstall.
On Thu, 2006-11-02 at 14:49 +0100, Michel Talon wrote: > > By the way another minor problem is that the audio does not > work. According to the mobo manual, it is a Realtek ALC882 audio chip. None > of the sound modules have recognized the chip. Sound works under Linux. HDA sound is only supported (by the snd_hda(4) driver) in CURRENT atm. -- Joel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem with the installer sysinstall.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joel Dahl wrote: > On Thu, 2006-11-02 at 14:49 +0100, Michel Talon wrote: >> By the way another minor problem is that the audio does not >> work. According to the mobo manual, it is a Realtek ALC882 audio chip. None >> of the sound modules have recognized the chip. Sound works under Linux. > > HDA sound is only supported (by the snd_hda(4) driver) in CURRENT atm. > .. or on stable (releng_6) with the mega-patch at http://people.freebsd.org/~ariff/ Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFSfqTQv9rrgRC1JIRAt3cAKCqUqPhIQO3+27mhBkOmAHX8hgEXACgl+GS EyEYI5oxRv4kfVfcV82Usnk= =JfbW -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: bootmgr on pc engines wrap board
On Nov 1, 2006, at 3:48 PM, spoggle wrote: You can prove it by running boot0cfg with the "-o nopacket" option on the CF card. Whee - that worked, thank you! - ask -- http://askask.com/ - http://develooper.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SAS Raid - mfi driver
The battery unit should not be considered optional. It's not about performance on silly 'dd' tests, it's about data safety. Way back when, all enterprise RAID cards were sold with an integrated battery because it was the right thing to do. These days, when you're shopping for RAID cards, you should just add in the cost of the battery as a matter-of-fact and not try to skimp by without one. Scott Fredrik Widlund wrote: Because the card itself will deal with the buffered writes independently of the kernel activity the risk should be less than using softupdates. Words like "screwed" seems to me to be exaggerated in the generic case. I our case specific you would need to understand the nature of what we are doing to be able to make a comment like that. For example data is redundant (exists in many copies), consists of very large sequencial files, we have plenty of backup power, and the greatest risk is fbsd locking up/crashing. Anyway our specific case is not of interest here, I just wanted to share our experiences with the LSI MegaSAS with other fbsd users so they understand why they get a severe performance degradation if they try to use such a card w/o a bbu, and what their options are. The generic case of how great the risk really is of corrupting filesystems completely using caches of any kind on the way to secondary storage still is interesting to me, so if you could elaborate here that would be great! Kind regards, Fredrik Widlund Bob Willcox wrote: On Wed, Nov 01, 2006 at 12:34:22AM +0100, Fredrik Widlund wrote: Yes, it forces writeback even when the controller has no BBU. Choosing WBack itself will default back to WThru. It's dangerous, but I guess it should be much less dangerous than using for example softupdates. I don't see how it could be *less* dangerous than using softupdates. Any loss of power while writing and it seems to me that you are going to be screwed w/o a BBU. [snip] ___ 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: Problem with the installer sysinstall.
On Thu, 2 Nov 2006, Michel Talon wrote: [..] > I am joining the dmesg for reference. Just skimming through, tongue hanging out .. > cpu0: on acpi0 > acpi_perf0: on cpu0 > acpi_throttle0: on cpu0 > cpu1: on acpi0 > acpi_throttle1: on cpu1 > acpi_throttle1: failed to attach P_CNT > device_attach: acpi_throttle1 attach returned 6 .. just checking - is that a harmless or expected warning? Cheers, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
GCC flags for Conroe based CPUs
I am wondering what CPUTYPE and CFLAGS are appropriate when using Intel's Conroe based Xeons, since GCC 3 is not aware of this CPU, afaik. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem with the installer sysinstall.
On Thu, 2006-11-02 at 09:02 -0500, Michael Butler wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Joel Dahl wrote: > > On Thu, 2006-11-02 at 14:49 +0100, Michel Talon wrote: > >> By the way another minor problem is that the audio does not > >> work. According to the mobo manual, it is a Realtek ALC882 audio chip. > None > >> of the sound modules have recognized the chip. Sound works under Linux. > > > > HDA sound is only supported (by the snd_hda(4) driver) in CURRENT atm. > > > .. or on stable (releng_6) with the mega-patch at > http://people.freebsd.org/~ariff/ The RELENG_6 patch also includes a lot of other stuff (some parts not even committed to CURRENT yet), so beware... -- Joel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem with the installer sysinstall.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ian Smith wrote: > On Thu, 2 Nov 2006, Michel Talon wrote: > > [..] > > > I am joining the dmesg for reference. > > Just skimming through, tongue hanging out .. > > > cpu0: on acpi0 > > acpi_perf0: on cpu0 > > acpi_throttle0: on cpu0 > > cpu1: on acpi0 > > acpi_throttle1: on cpu1 > > acpi_throttle1: failed to attach P_CNT > > device_attach: acpi_throttle1 attach returned 6 > > .. just checking - is that a harmless or expected warning? To quote from the Hitch-hiker's Guide to the Galaxy (2nd edition), "mostly harmless". On a Core-2 duo, both cores are throttle-managed by the same "knobs" - what is directed to happen to one core, happens to the other, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFSgX9Qv9rrgRC1JIRArxuAJ4z5/3/96wkfKUSehABZ1o0a4mTVQCeLncI a8vtVLC1+btJIyi4sKRtRo4= =tYER -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: Problem with the installer sysinstall.
On Thu, 2 Nov 2006, Michael Butler wrote: > Ian Smith wrote: > > On Thu, 2 Nov 2006, Michel Talon wrote: > > > > > acpi_throttle0: on cpu0 > > > cpu1: on acpi0 > > > acpi_throttle1: on cpu1 > > > acpi_throttle1: failed to attach P_CNT > > > device_attach: acpi_throttle1 attach returned 6 > > > > .. just checking - is that a harmless or expected warning? > > To quote from the Hitch-hiker's Guide to the Galaxy (2nd edition), > "mostly harmless". On a Core-2 duo, both cores are throttle-managed by > the same "knobs" - what is directed to happen to one core, happens to > the other, Ta. The rest looked pretty encouraging. o&o, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SAS Raid - mfi driver
Please don't direct this to me as I've already pointed out that I'm not asking about this. Fyi. the cards were shipped in a hurry mistakenly without bbus, we have to wait until next week for them to arrive, and until then we will use cache without batteries since the performance degradation using wthru on fbsd gives us no choice. This is not up for debate here so please let that thread end here and now. In general it's not up to you to decide how people evaluate performance/safety/price ratios. In our case, for example, performance is not an option, regardless of safety. With a 20MB/s bottleneck for writing we can throw the system out the window. Our problem was receiving a card that performed 200MB/s (not using cache) on a different platform, but 20MB/s (not using cache) on fbsd with no apparent or logical explanation as to why. If the fbsd mfi-driver's wthru support comes with a severe performance penalty I suggest the man page mentions it, regardless of whether you think "WThru is a bad thing (tm)" or not. Kind regards, Fredrik Widlund Scott Long wrote: > The battery unit should not be considered optional. It's not about > performance on silly 'dd' tests, it's about data safety. Way back when, > all enterprise RAID cards were sold with an integrated battery because > it was the right thing to do. These days, when you're shopping for RAID > cards, you should just add in the cost of the battery as a > matter-of-fact and not try to skimp by without one. > > Scott > > > Fredrik Widlund wrote: >> Because the card itself will deal with the buffered writes independently >> of the kernel activity the risk should be less than using softupdates. >> Words like "screwed" seems to me to be exaggerated in the generic case. >> I our case specific you would need to understand the nature of what we >> are doing to be able to make a comment like that. For example data is >> redundant (exists in many copies), consists of very large sequencial >> files, we have plenty of backup power, and the greatest risk is fbsd >> locking up/crashing. >> >> Anyway our specific case is not of interest here, I just wanted to share >> our experiences with the LSI MegaSAS with other fbsd users so they >> understand why they get a severe performance degradation if they try to >> use such a card w/o a bbu, and what their options are. >> >> The generic case of how great the risk really is of corrupting >> filesystems completely using caches of any kind on the way to secondary >> storage still is interesting to me, so if you could elaborate here that >> would be great! >> >> Kind regards, >> Fredrik Widlund >> >> >> Bob Willcox wrote: >>> On Wed, Nov 01, 2006 at 12:34:22AM +0100, Fredrik Widlund wrote: >>> Yes, it forces writeback even when the controller has no BBU. Choosing WBack itself will default back to WThru. It's dangerous, but I guess it should be much less dangerous than using for example softupdates. >>> I don't see how it could be *less* dangerous than using softupdates. >>> Any >>> loss of power while writing and it seems to me that you are going to be >>> screwed w/o a BBU. >>> >>> [snip] >>> >>> >> >> ___ >> 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: SAS Raid - mfi driver
You seem convinced that this is a driver bug. Did you receive my series of emails 2 days ago that explained why it is not? Scott Fredrik Widlund wrote: Please don't direct this to me as I've already pointed out that I'm not asking about this. Fyi. the cards were shipped in a hurry mistakenly without bbus, we have to wait until next week for them to arrive, and until then we will use cache without batteries since the performance degradation using wthru on fbsd gives us no choice. This is not up for debate here so please let that thread end here and now. In general it's not up to you to decide how people evaluate performance/safety/price ratios. In our case, for example, performance is not an option, regardless of safety. With a 20MB/s bottleneck for writing we can throw the system out the window. Our problem was receiving a card that performed 200MB/s (not using cache) on a different platform, but 20MB/s (not using cache) on fbsd with no apparent or logical explanation as to why. If the fbsd mfi-driver's wthru support comes with a severe performance penalty I suggest the man page mentions it, regardless of whether you think "WThru is a bad thing (tm)" or not. Kind regards, Fredrik Widlund Scott Long wrote: The battery unit should not be considered optional. It's not about performance on silly 'dd' tests, it's about data safety. Way back when, all enterprise RAID cards were sold with an integrated battery because it was the right thing to do. These days, when you're shopping for RAID cards, you should just add in the cost of the battery as a matter-of-fact and not try to skimp by without one. Scott Fredrik Widlund wrote: Because the card itself will deal with the buffered writes independently of the kernel activity the risk should be less than using softupdates. Words like "screwed" seems to me to be exaggerated in the generic case. I our case specific you would need to understand the nature of what we are doing to be able to make a comment like that. For example data is redundant (exists in many copies), consists of very large sequencial files, we have plenty of backup power, and the greatest risk is fbsd locking up/crashing. Anyway our specific case is not of interest here, I just wanted to share our experiences with the LSI MegaSAS with other fbsd users so they understand why they get a severe performance degradation if they try to use such a card w/o a bbu, and what their options are. The generic case of how great the risk really is of corrupting filesystems completely using caches of any kind on the way to secondary storage still is interesting to me, so if you could elaborate here that would be great! Kind regards, Fredrik Widlund Bob Willcox wrote: On Wed, Nov 01, 2006 at 12:34:22AM +0100, Fredrik Widlund wrote: Yes, it forces writeback even when the controller has no BBU. Choosing WBack itself will default back to WThru. It's dangerous, but I guess it should be much less dangerous than using for example softupdates. I don't see how it could be *less* dangerous than using softupdates. Any loss of power while writing and it seems to me that you are going to be screwed w/o a BBU. [snip] ___ 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: ggated not working on 6.2-PRERELEASE
Pawel Jakub Dawidek wrote: > On Sun, Oct 29, 2006 at 06:48:18PM +0100, Christian Laursen wrote: >> Christian Laursen <[EMAIL PROTECTED]> writes: >> >>> Kazuaki ODA <[EMAIL PROTECTED]> writes: >>> I tried to find what broke ggated, and finally found that it works fine when I backout sys/kern/uipc_socket2.c rev. 1.147.2.7. >>> I will try to reproduce that here. >> I can confirm that it works for me too with the above mentioned change >> backed out. > > This was ggate bug. I committed fix to HEAD and will MFC it in one week. > > Thank you! > I've manually merged that fix, and now ggate works fine on my 6.2-PRERELEASE i386 box. Thanks. BTW how about amd64/91799? It seems that there are some people, including me, who cannot use ggate on amd64. I don't know whether the patch attached above PR has some issue or not, but at least for me, that is needed to use ggate on amd64. -- Kazuaki ODA ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SAS Raid - mfi driver
Yes I received it, and no I'm not saying it's a driver bug. However I did assume this would be the driver specific. Do I understand you correctly; you're saying that it's FreeBSD's controller I/O framework in general that cause this performance gap to Windows and Linux, and it's not driver specific? Kind regards, Fredrik Widlund Scott Long wrote: > You seem convinced that this is a driver bug. Did you receive my > series of emails 2 days ago that explained why it is not? > > Scott > > > Fredrik Widlund wrote: >> Please don't direct this to me as I've already pointed out that I'm not >> asking about this. Fyi. the cards were shipped in a hurry mistakenly >> without bbus, we have to wait until next week for them to arrive, and >> until then we will use cache without batteries since the performance >> degradation using wthru on fbsd gives us no choice. This is not up for >> debate here so please let that thread end here and now. >> >> In general it's not up to you to decide how people evaluate >> performance/safety/price ratios. In our case, for example, performance >> is not an option, regardless of safety. With a 20MB/s bottleneck for >> writing we can throw the system out the window. Our problem was >> receiving a card that performed 200MB/s (not using cache) on a different >> platform, but 20MB/s (not using cache) on fbsd with no apparent or >> logical explanation as to why. If the fbsd mfi-driver's wthru support >> comes with a severe performance penalty I suggest the man page mentions >> it, regardless of whether you think "WThru is a bad thing (tm)" or not. >> >> Kind regards, >> Fredrik Widlund >> >> Scott Long wrote: >> >>> The battery unit should not be considered optional. It's not about >>> performance on silly 'dd' tests, it's about data safety. Way back >>> when, >>> all enterprise RAID cards were sold with an integrated battery because >>> it was the right thing to do. These days, when you're shopping for >>> RAID >>> cards, you should just add in the cost of the battery as a >>> matter-of-fact and not try to skimp by without one. >>> >>> Scott >>> >>> >>> Fredrik Widlund wrote: >>> Because the card itself will deal with the buffered writes independently of the kernel activity the risk should be less than using softupdates. Words like "screwed" seems to me to be exaggerated in the generic case. I our case specific you would need to understand the nature of what we are doing to be able to make a comment like that. For example data is redundant (exists in many copies), consists of very large sequencial files, we have plenty of backup power, and the greatest risk is fbsd locking up/crashing. Anyway our specific case is not of interest here, I just wanted to share our experiences with the LSI MegaSAS with other fbsd users so they understand why they get a severe performance degradation if they try to use such a card w/o a bbu, and what their options are. The generic case of how great the risk really is of corrupting filesystems completely using caches of any kind on the way to secondary storage still is interesting to me, so if you could elaborate here that would be great! Kind regards, Fredrik Widlund Bob Willcox wrote: > On Wed, Nov 01, 2006 at 12:34:22AM +0100, Fredrik Widlund wrote: > > >> Yes, it forces writeback even when the controller has no BBU. >> Choosing WBack itself will default back to WThru. It's dangerous, >> but I guess it should be much less dangerous than using for example >> softupdates. >> > > I don't see how it could be *less* dangerous than using softupdates. > Any > loss of power while writing and it seems to me that you are going > to be > screwed w/o a BBU. > > [snip] > > ___ 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]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SAS Raid - mfi driver
Do your performance test on Linux using 32k or 64k i/o blocks, then do it on FreeBSD using the same. You'll seem similar performance between the two. Unless your application is bypassing the filesystem to do raw I/O that is larger than that, you won't see any benefit from the larger i/o sizes that Linux can do. Scott Fredrik Widlund wrote: Yes I received it, and no I'm not saying it's a driver bug. However I did assume this would be the driver specific. Do I understand you correctly; you're saying that it's FreeBSD's controller I/O framework in general that cause this performance gap to Windows and Linux, and it's not driver specific? Kind regards, Fredrik Widlund Scott Long wrote: You seem convinced that this is a driver bug. Did you receive my series of emails 2 days ago that explained why it is not? Scott Fredrik Widlund wrote: Please don't direct this to me as I've already pointed out that I'm not asking about this. Fyi. the cards were shipped in a hurry mistakenly without bbus, we have to wait until next week for them to arrive, and until then we will use cache without batteries since the performance degradation using wthru on fbsd gives us no choice. This is not up for debate here so please let that thread end here and now. In general it's not up to you to decide how people evaluate performance/safety/price ratios. In our case, for example, performance is not an option, regardless of safety. With a 20MB/s bottleneck for writing we can throw the system out the window. Our problem was receiving a card that performed 200MB/s (not using cache) on a different platform, but 20MB/s (not using cache) on fbsd with no apparent or logical explanation as to why. If the fbsd mfi-driver's wthru support comes with a severe performance penalty I suggest the man page mentions it, regardless of whether you think "WThru is a bad thing (tm)" or not. Kind regards, Fredrik Widlund Scott Long wrote: The battery unit should not be considered optional. It's not about performance on silly 'dd' tests, it's about data safety. Way back when, all enterprise RAID cards were sold with an integrated battery because it was the right thing to do. These days, when you're shopping for RAID cards, you should just add in the cost of the battery as a matter-of-fact and not try to skimp by without one. Scott Fredrik Widlund wrote: Because the card itself will deal with the buffered writes independently of the kernel activity the risk should be less than using softupdates. Words like "screwed" seems to me to be exaggerated in the generic case. I our case specific you would need to understand the nature of what we are doing to be able to make a comment like that. For example data is redundant (exists in many copies), consists of very large sequencial files, we have plenty of backup power, and the greatest risk is fbsd locking up/crashing. Anyway our specific case is not of interest here, I just wanted to share our experiences with the LSI MegaSAS with other fbsd users so they understand why they get a severe performance degradation if they try to use such a card w/o a bbu, and what their options are. The generic case of how great the risk really is of corrupting filesystems completely using caches of any kind on the way to secondary storage still is interesting to me, so if you could elaborate here that would be great! Kind regards, Fredrik Widlund Bob Willcox wrote: On Wed, Nov 01, 2006 at 12:34:22AM +0100, Fredrik Widlund wrote: Yes, it forces writeback even when the controller has no BBU. Choosing WBack itself will default back to WThru. It's dangerous, but I guess it should be much less dangerous than using for example softupdates. I don't see how it could be *less* dangerous than using softupdates. Any loss of power while writing and it seems to me that you are going to be screwed w/o a BBU. [snip] ___ 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]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New em driver - still watchdog timeouts
Yes, I know this is still happening. I also have pretty good data now that its a bogus problem, meaning due to scheduling issues the watchdog does not get reset even though the system is just fine as far as transmit descriptors is concerned. I have a patch that detects this and keeps the watchdog from erroneously resetting you, it has been running on my test system for days now without problems. Jack On 11/2/06, Patrick M. Hausen <[EMAIL PROTECTED]> wrote: Hello! Our central backup server is still experiencing the same random problems. The timouts occur every other night or so, when the server has got high CPU load (compressing the backups) and transfers large amounts of data at the same time. Nov 2 02:19:34 datatomb kernel: em1: watchdog timeout -- resetting Nov 2 02:19:34 datatomb kernel: em1: link state changed to DOWN Nov 2 02:19:34 datatomb kernel: vlan23: link state changed to DOWN Nov 2 02:19:34 datatomb kernel: vlan22: link state changed to DOWN Nov 2 02:19:36 datatomb kernel: em1: link state changed to UP Nov 2 02:19:36 datatomb kernel: vlan23: link state changed to UP Nov 2 02:19:36 datatomb kernel: vlan22: link state changed to UP Jack, the hardware should be easy for you or someone else at Intel to get your hands on: http://www.intel.com/design/servers/storage/ssr212cc/index.htm Unfortunately I cannot give you root access to _that_ one. Regards, Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Vorholzstr. 25Tel. 0721 9109 -0 Fax: -100 76137 Karlsruhe http://punkt.de ___ 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: New em driver - still watchdog timeouts
On Thu, Nov 02, 2006 at 09:43:34AM -0800, Jack Vogel wrote: > Yes, I know this is still happening. I also have pretty good data now > that its a bogus problem, meaning due to scheduling issues the > watchdog does not get reset even though the system is just fine > as far as transmit descriptors is concerned. I have a patch that > detects this and keeps the watchdog from erroneously resetting > you, it has been running on my test system for days now without > problems. I don't understand this explanation of the problem. Here's how I read this paragraph: * It's a "bogus problem" (which means there's not a problem) * ...due to "scheduling issues" (which means there IS a problem) * The watchdog does NOT get reset * ...but there's a patch (to fix the "bogus problem"? or what?) * ...which keeps the watchdog from resetting (but you just said...) Maybe you were in a hurry, I don't know. Either way, the paragraph doesn't make sense. I call for clarification! ;-) -- | 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.x from i386 to amd64
Greg Black wrote: > Mark Linimon wrote: > > Greg Black wrote: > > > I found that a very large number of ports that mattered to me were marked > > > i386 only. > > > > In some cases these designations are obsolete. They will require people- > > power to work through them and see if they are overused. > > [...] > > it will take people with amd64 boxes running native willing to test them > > and report back. > [...] > Fair enough. In my defence, I'm fully committed at present and > I have only one amd64 machine which I need for my real work. I > can't afford to run it in amd64 mode, because so much of what I > need is currently broken in a 64-bit world. By the way, you don't necessarily have to have an amd64 machine in order to be able to run FreeBSSD/amd64 and try 64bit software. Qemu supports emulating an amd64 CPU on an i386 system (and vice versa, for that matter). So you can run FreeBSD/amd64 on top of FreeBSD/i386 inside qemu and play with it. Admittedly it will be noticeably slower than running natively, though, because you can't use the qemu accelerator kernel module when emulating a different architecture. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. I suggested holding a "Python Object Oriented Programming Seminar", but the acronym was unpopular. -- Joseph Strout ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.x from i386 to amd64
Peter Jeremy wrote:
> Mark Linimon wrote:
> > - certain ports have i386 binaries (can't be fixed)
> > - certain ports have i386 asm code (can be fixed if there is fallback
> > C code)
>
> A partial solution to this is to get the i386 emulation and cross-
> building into better shape. If I really need a binary-only port
> then I can build/run it in emulation mode. This has bee discussed
> previously.
>
> IMHO, the FreeBSD/amd64 naming conventions make it much cleaner than
> (eg) Solaris and Linux as long as you only want native-mode apps.
> Unfortunately, it makes supporting i386 applications much harder
> (bacause they need to understand they need to look in .../lib32
> ISO .../lib).
Isn't someone working on porting variant symlinks over from
dragonfly? I thought it was a SoC project or something
like that. Using variant symlinks, the problem would be
easy to solve:
drwxr-xr-x ... lib32
drwxr-xr-x ... lib64
lrwxr-xr-x ... lib -> lib${ARCH_BITS}
ARCH_BITS would be set to "64" globally, and it would be
set to "32" for i386 applications. Then every program
would find the correct libs automagically.
Best regards
Oliver
PS: For those who are not familiar with variant symlinks:
http://leaf.dragonflybsd.org/cgi/web-man?command=ln
http://leaf.dragonflybsd.org/cgi/web-man?command=varsym
--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
> Can the denizens of this group enlighten me about what the
> advantages of Python are, versus Perl ?
"python" is more likely to pass unharmed through your spelling
checker than "perl".
-- An unknown poster and Fredrik Lundh
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New em driver - still watchdog timeouts
On 11/2/06, Jeremy Chadwick <[EMAIL PROTECTED]> wrote: On Thu, Nov 02, 2006 at 09:43:34AM -0800, Jack Vogel wrote: > Yes, I know this is still happening. I also have pretty good data now > that its a bogus problem, meaning due to scheduling issues the > watchdog does not get reset even though the system is just fine > as far as transmit descriptors is concerned. I have a patch that > detects this and keeps the watchdog from erroneously resetting > you, it has been running on my test system for days now without > problems. I don't understand this explanation of the problem. Here's how I read this paragraph: * It's a "bogus problem" (which means there's not a problem) * ...due to "scheduling issues" (which means there IS a problem) * The watchdog does NOT get reset * ...but there's a patch (to fix the "bogus problem"? or what?) * ...which keeps the watchdog from resetting (but you just said...) Maybe you were in a hurry, I don't know. Either way, the paragraph doesn't make sense. I call for clarification! ;-) OK OK, so I wasnt at my most lucid :) When I said its bogus what I mean is that the watchdog is designed to detect and correct a certain condition, but what is really happening is NOT THAT condition. The watchdog gets set when there is transmit cleanup work pending, everytime SOME progress is made on cleaning it gets restarted, if you actually clean the WHOLE ring then you turn it off. So the idea is it protects against transmit hangs. So why do I say what we see is bogus... because the watchdog is firing even though we DON'T have tx hangs or descriptor shortages. I have a hack that rechecks the number of free descriptors in the watchdog code and returns without resetting if we have max free. I am still trying to figure out how this can happen in the first place however, I'd rather do something that didnt feel quite as much a hack :) So, is that somewhat clearer? Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New em driver - still watchdog timeouts
Hi, Jack! On Thu, Nov 02, 2006 at 10:39:16AM -0800, Jack Vogel wrote: > So why do I say what we see is bogus... because the watchdog is > firing even though we DON'T have tx hangs or descriptor shortages. > > I have a hack that rechecks the number of free descriptors in the > watchdog code and returns without resetting if we have max free. > > I am still trying to figure out how this can happen in the first place > however, I'd rather do something that didnt feel quite as much a > hack :) This is really good news. I'm confident you will come up with solution. Thanks for all the effort you, Kris and Scott are putting into this. Kind regards, Patrick M. Hausen Leiter Netzwerke und Sicherheit -- punkt.de GmbH Internet - Dienstleistungen - Beratung Vorholzstr. 25Tel. 0721 9109 -0 Fax: -100 76137 Karlsruhe http://punkt.de ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New em driver - still watchdog timeouts
On Thu, Nov 02, 2006 at 10:39:16AM -0800, Jack Vogel wrote: > So, is that somewhat clearer? Very much so! Thank you for the concise answer. This makes much more sense. (The description, I mean -- the actual problem is still a mystery.) -- | 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.x from i386 to amd64
On 10/31/06, Robert Blayzor <[EMAIL PROTECTED]> wrote: Is there a way to upgrade/move an already installed i386 installed 6.1 machine to amd64 without completely reinstalling? Is there a procedure to do so? I spent all of last weekend trying to do this, with no solution determined. I read a couple of methods for doing this without reinstalling, but both indicated that a lot of know-how was needed and that the methods were neither complete nor bullet-proof. They both required access to the server to do magic things in single-user mode, which isn't available to me. For our purposes, I have decided to keep the machines as i386. I have two servers with identical hardware. One has 6.1/amd64, and the other has 6.1/i386. The i386 has a better ubench score. More importantly for us, it's impossible to build a 32-bit perl on the amd64, and we don't need a 64-bit perl. Our apache/mod_perl servers are 3X bigger on the amd64, and that is unsatisfactory. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.x from i386 to amd64
Hi!
> drwxr-xr-x ... lib32
> drwxr-xr-x ... lib64
> lrwxr-xr-x ... lib -> lib${ARCH_BITS}
>
> ARCH_BITS would be set to "64" globally, and it would be
> set to "32" for i386 applications. Then every program
> would find the correct libs automagically.
> PS: For those who are not familiar with variant symlinks:
> http://leaf.dragonflybsd.org/cgi/web-man?command=ln
> http://leaf.dragonflybsd.org/cgi/web-man?command=varsym
Just for the record: Secure Computing's Sidewinder Firewall
running on a BSD/OS with S.C.'s proprietary extensions
uses a similar mimic to reference files depending on
which "burb" (i.e. zone of trust) a process is running in.
Cool to see it in Dragonfly and hopefully FreeBSD. I can
imagine interesting setups for HA systems, for example:
script -> script${AM_I_ACTIVE_OR_PASSIVE}
Regards,
Patrick
--
punkt.de GmbH Internet - Dienstleistungen - Beratung
Vorholzstr. 25Tel. 0721 9109 -0 Fax: -100
76137 Karlsruhe http://punkt.de
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
New em driver breaks jumbo frames
Don't have much time right now, but wanted to report that the new em driver in -STABLE breaks jumbo frame support for me. With it in the kernel and this card: em1: port 0xe8c0-0xe8ff mem 0xfe18-0xfe19 irq 18 at device 12.0 on pci2 I'm unable to send an ethernet frame bigger than 2034 bytes, no matter what the mtu is set to. No errors, no kernel messages, it just doesn't go out. tcpdump on both local and remote side show nothing at all. Reverting to the previous driver fixed it. Craig ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New em driver breaks jumbo frames
Yes, this is the second report I've had, other came to me personally. I'm looking into it. Jack On 11/2/06, Craig Boston <[EMAIL PROTECTED]> wrote: Don't have much time right now, but wanted to report that the new em driver in -STABLE breaks jumbo frame support for me. With it in the kernel and this card: em1: port 0xe8c0-0xe8ff mem 0xfe18-0xfe19 irq 18 at device 12.0 on pci2 I'm unable to send an ethernet frame bigger than 2034 bytes, no matter what the mtu is set to. No errors, no kernel messages, it just doesn't go out. tcpdump on both local and remote side show nothing at all. Reverting to the previous driver fixed it. Craig ___ 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: 6.1-STABLE , cant see SIS 180 SATA / SIS S655-FX SATA Drives
I have updated to 6.2-PRERELEASE, still experiencing the same problem. Dmesg output is as follows : Copyright (c) 1992-2006 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-PRERELEASE #2: Thu Oct 19 20:10:00 EDT 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/C7OFFICE WARNING: debug.mpsafenet forced to 0 as ipsec requires Giant WARNING: MPSAFE network stack disabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 2.00GHz (2000.58-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf24 Stepping = 4 Features=0x3febfbff real memory = 1073414144 (1023 MB) avail memory = 1041276928 (993 MB) ACPI APIC Table: Security auditing service present BSM auditing present ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xf800-0xfbff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) isab0: at device 2.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 2.5 on pci0 ata0: on atapci0 ata1: on atapci0 ohci0: mem 0xfebfc000-0xfebfcfff irq 20 at device 3.0 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1: mem 0xfebfd000-0xfebfdfff irq 21 at device 3.1 on pci0 ohci1: [GIANT-LOCKED] usb1: OHCI version 1.0, legacy support usb1: on ohci1 usb1: USB revision 1.0 uhub1: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 3 ports with 3 removable, self powered ohci2: mem 0xfebfe000-0xfebfefff irq 22 at device 3.2 on pci0 ohci2: [GIANT-LOCKED] usb2: OHCI version 1.0, legacy support usb2: on ohci2 usb2: USB revision 1.0 uhub2: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xfebff000-0xfebf irq 23 at device 3.3 on pci0 ehci0: [GIANT-LOCKED] usb3: EHCI version 1.0 usb3: companion controllers, 3 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: SiS EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub3: 8 ports with 8 removable, self powered sis0: port 0xe800-0xe8ff mem 0xfebfb000-0xfebfbfff irq 19 at device 4.0 on pci0 miibus0: on sis0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis0: Ethernet address: 00:17:31:32:21:25 sis0: [GIANT-LOCKED] atapci1: port 0xeff0-0xeff7,0xefe4-0xefe7,0xefa8-0xefaf,0xefe0-0xefe3,0xef90-0xef9f irq 17 at device 5.0 on pci0 ata2: on atapci1 ata3: on atapci1 rl0: port 0xe400-0xe4ff mem 0xfebfac00-0xfebfacff irq 16 at device 8.0 on pci0 miibus1: on rl0 rlphy1: on miibus1 rlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:50:ba:d4:93:09 rl0: [GIANT-LOCKED] rl1: port 0xe000-0xe0ff mem 0xfebfa800-0xfebfa8ff irq 17 at device 9.0 on pci0 miibus2: on rl1 rlphy2: on miibus2 rlphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl1: Ethernet address: 00:50:ba:42:9e:77 rl1: [GIANT-LOCKED] acpi_button0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A pmtimer0 on isa0 orm0: at iomem 0xca800-0xd27ff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounter "TSC" frequency 2000576888 Hz quality 800 Timecounters tick every 1.000 msec IPsec: Initialized Security Association Processing. ad0: 38166MB at ata0-master UDMA100 acd0: DVDR at ata1-master UDMA66 Trying to mount root from ufs:/dev/ad0s1a rl0: link state changed to UP Gavin Atkinson wrote: On Wed, 2006-10-04 at 11:14 -0400, Kevin Kutzko wrote: Running freebsd 6.1 Stable. I am aware that there was issues with SiS SATA chipsets requiring a patch. Has this issue been resolved with not being able to see SATA drives (at all) in freebsd? The easiest way to find out would probably be to upgrade - 6.2-BETA2 is available at the moment. Obviously,
Watchdog Timeout - bge device - 6.2-PRERELEASE
rwsrv05> dmesg | grep bge bge0: mem 0xe820-0xe820 irq 17 at device 4.0 on pci4 miibus1: on bge0 bge0: Ethernet address: 00:0b:cd:e7:70:19 bge0: link state changed to UP bge0: watchdog timeout -- resetting bge0: link state changed to DOWN bge0: link state changed to UP bge0: watchdog timeout -- resetting bge0: link state changed to DOWN bge0: link state changed to UP bge0: watchdog timeout -- resetting bge0: link state changed to DOWN bge0: link state changed to UP This is happening, on average, once per day. It happens when the bge0 interface is under load. I cannot reproduce it at will. I posted here about a month ago when I was seeing this problem under SCHED_ULE. http://lists.freebsd.org/pipermail/freebsd-stable/2006-October/029079.ht ml Having been duly castigated for using SCHED_ULE, I reverted to SCHED_4BSD and kept quiet. The symptoms are back! (less frequently) under SCHED_4BSD - but the kernel now has lots of extras. In order to help with testing 6.2-PRERELEASE, I've been loading up drivers for bits of the hardware which I don't even use. That has brought to light a shared interrupt which may or may not have some relevance. I'm also now running SMP. I've also compiled in INVARIANTS on the understanding that it's supposed to provide helpful debugging information for this issue (but I don't know how to use it - and I haven't seen any extra clues). Hardware: hp ProLiant ML110 rwsrv05> vmstat -i interrupt total rate irq1: atkbd0 546 0 irq6: fdc0 9 0 irq14: ata0 156756 2 irq15: ata1 47 0 irq17: bge0+18518341309 irq24: fxp078098 1 irq26: mpt0 851102 14 cpu0: timer119569853 2000 cpu1: timer119555276 1999 Total 258730028 4327 rwsrv05> dmesg | grep 'irq 17' bge0: mem 0xe820-0xe820 irq 17 at device 4.0 on pci4 ichsmb0: port 0x1440-0x145f irq 17 at device 31.3 on pci0 rwsrv05> sysctl kern.version kern.sched kern.smp hw.machine hw.model dev.bge kern.version: FreeBSD 6.2-PRERELEASE #0: Tue Oct 31 21:30:38 AEDT 2006 [EMAIL PROTECTED]:/spare/obj/usr/src/sys/RWSRV05 kern.sched.name: 4BSD kern.sched.quantum: 10 kern.sched.ipiwakeup.enabled: 1 kern.sched.ipiwakeup.requested: 2 kern.sched.ipiwakeup.delivered: 2 kern.sched.ipiwakeup.usemask: 1 kern.sched.ipiwakeup.useloop: 0 kern.sched.ipiwakeup.onecpu: 0 kern.sched.ipiwakeup.htt2: 0 kern.sched.followon: 0 kern.sched.pfollowons: 0 kern.sched.kgfollowons: 0 kern.sched.preemption: 1 kern.sched.runq_fuzz: 1 kern.smp.maxcpus: 16 kern.smp.active: 1 kern.smp.disabled: 0 kern.smp.cpus: 2 kern.smp.forward_signal_enabled: 1 kern.smp.forward_roundrobin_enabled: 1 hw.machine: i386 hw.model: Intel(R) Pentium(R) 4 CPU 2.80GHz dev.bge.0.%desc: Broadcom BCM5705 A3, ASIC rev. 0x3003 dev.bge.0.%driver: bge dev.bge.0.%location: slot=4 function=0 dev.bge.0.%pnpinfo: vendor=0x14e4 device=0x1654 subvendor=0x103c subdevice=0x1654 class=0x02 dev.bge.0.%parent: pci4 rwsrv05> Here's what I've added to the kernel config since 4th October... rwsrv05> rcsdiff -u -r1.9 -r1.18 RWSRV05 | grep ^+ === RCS file: RCS/RWSRV05,v retrieving revision 1.9 retrieving revision 1.18 diff -u -r1.9 -r1.18 +++ RWSRV05 2006/10/31 10:24:01 1.18 +# $Id: RWSRV05,v 1.18 2006/10/31 10:24:01 john Exp $ +optionsINVARIANT_SUPPORT +optionsINVARIANTS +optionsSMP # Symmetric MultiProcessor Kernel +#options SCHED_ULE # ULE scheduler +optionsSCHED_4BSD # 4BSD scheduler + +optionsNFSSERVER # Network File System server +optionsNFSCLIENT # Network File System client + +# USB support +device usb # General USB code (mandatory for USB) +device uhci# UHCI controller +device ehci# EHCI controller + +# SMB bus +device smbus # Bus support, required for smb below. +# ichsmb Intel ICH SMBus controller chips (82801AA, 82801AB, 82801BA) +device ichsmb +device smb + +# AGP GART support +device agp + +# Direct Rendering modules for 3D acceleration +device drm # DRM core module required by DRM drivers +device mach64drm # ATI Rage Pro, Rage Mobility P/M, Rage XL + +# ichwd: Intel ICH watchdog timer +device ichwd rwsrv05> I'm not actually using this extra stuff. I just thought it might be helpful (to FreeBSD) to find drivers for all my hardware to see if anything was broken. John Marshall. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/lis
Re: Watchdog Timeout - bge device - 6.2-PRERELEASE
Is it causing stuck connections or other messy problems? Also, is it any worse than 6.1? Scott John Marshall wrote: rwsrv05> dmesg | grep bge bge0: mem 0xe820-0xe820 irq 17 at device 4.0 on pci4 miibus1: on bge0 bge0: Ethernet address: 00:0b:cd:e7:70:19 bge0: link state changed to UP bge0: watchdog timeout -- resetting bge0: link state changed to DOWN bge0: link state changed to UP bge0: watchdog timeout -- resetting bge0: link state changed to DOWN bge0: link state changed to UP bge0: watchdog timeout -- resetting bge0: link state changed to DOWN bge0: link state changed to UP This is happening, on average, once per day. It happens when the bge0 interface is under load. I cannot reproduce it at will. I posted here about a month ago when I was seeing this problem under SCHED_ULE. http://lists.freebsd.org/pipermail/freebsd-stable/2006-October/029079.ht ml Having been duly castigated for using SCHED_ULE, I reverted to SCHED_4BSD and kept quiet. The symptoms are back! (less frequently) under SCHED_4BSD - but the kernel now has lots of extras. In order to help with testing 6.2-PRERELEASE, I've been loading up drivers for bits of the hardware which I don't even use. That has brought to light a shared interrupt which may or may not have some relevance. I'm also now running SMP. I've also compiled in INVARIANTS on the understanding that it's supposed to provide helpful debugging information for this issue (but I don't know how to use it - and I haven't seen any extra clues). Hardware: hp ProLiant ML110 rwsrv05> vmstat -i interrupt total rate irq1: atkbd0 546 0 irq6: fdc0 9 0 irq14: ata0 156756 2 irq15: ata1 47 0 irq17: bge0+18518341309 irq24: fxp078098 1 irq26: mpt0 851102 14 cpu0: timer119569853 2000 cpu1: timer119555276 1999 Total 258730028 4327 rwsrv05> dmesg | grep 'irq 17' bge0: mem 0xe820-0xe820 irq 17 at device 4.0 on pci4 ichsmb0: port 0x1440-0x145f irq 17 at device 31.3 on pci0 rwsrv05> sysctl kern.version kern.sched kern.smp hw.machine hw.model dev.bge kern.version: FreeBSD 6.2-PRERELEASE #0: Tue Oct 31 21:30:38 AEDT 2006 [EMAIL PROTECTED]:/spare/obj/usr/src/sys/RWSRV05 kern.sched.name: 4BSD kern.sched.quantum: 10 kern.sched.ipiwakeup.enabled: 1 kern.sched.ipiwakeup.requested: 2 kern.sched.ipiwakeup.delivered: 2 kern.sched.ipiwakeup.usemask: 1 kern.sched.ipiwakeup.useloop: 0 kern.sched.ipiwakeup.onecpu: 0 kern.sched.ipiwakeup.htt2: 0 kern.sched.followon: 0 kern.sched.pfollowons: 0 kern.sched.kgfollowons: 0 kern.sched.preemption: 1 kern.sched.runq_fuzz: 1 kern.smp.maxcpus: 16 kern.smp.active: 1 kern.smp.disabled: 0 kern.smp.cpus: 2 kern.smp.forward_signal_enabled: 1 kern.smp.forward_roundrobin_enabled: 1 hw.machine: i386 hw.model: Intel(R) Pentium(R) 4 CPU 2.80GHz dev.bge.0.%desc: Broadcom BCM5705 A3, ASIC rev. 0x3003 dev.bge.0.%driver: bge dev.bge.0.%location: slot=4 function=0 dev.bge.0.%pnpinfo: vendor=0x14e4 device=0x1654 subvendor=0x103c subdevice=0x1654 class=0x02 dev.bge.0.%parent: pci4 rwsrv05> Here's what I've added to the kernel config since 4th October... rwsrv05> rcsdiff -u -r1.9 -r1.18 RWSRV05 | grep ^+ === RCS file: RCS/RWSRV05,v retrieving revision 1.9 retrieving revision 1.18 diff -u -r1.9 -r1.18 +++ RWSRV05 2006/10/31 10:24:01 1.18 +# $Id: RWSRV05,v 1.18 2006/10/31 10:24:01 john Exp $ +optionsINVARIANT_SUPPORT +optionsINVARIANTS +optionsSMP # Symmetric MultiProcessor Kernel +#options SCHED_ULE # ULE scheduler +optionsSCHED_4BSD # 4BSD scheduler + +optionsNFSSERVER # Network File System server +optionsNFSCLIENT # Network File System client + +# USB support +device usb # General USB code (mandatory for USB) +device uhci# UHCI controller +device ehci# EHCI controller + +# SMB bus +device smbus # Bus support, required for smb below. +# ichsmb Intel ICH SMBus controller chips (82801AA, 82801AB, 82801BA) +device ichsmb +device smb + +# AGP GART support +device agp + +# Direct Rendering modules for 3D acceleration +device drm # DRM core module required by DRM drivers +device mach64drm # ATI Rage Pro, Rage Mobility P/M, Rage XL + +# ichwd: Intel ICH watchdog timer +device ichwd rwsrv05> I'm not actually using this extra stuff. I just thought it might be helpful (to FreeBSD) to find drivers for all my hardware to see if anything was broken. John Marshall.
RE: Watchdog Timeout - bge device - 6.2-PRERELEASE
> Is it causing stuck connections or other messy problems? Also, is it > any worse than 6.1? No. It's not causing lock-ups or anything else sinister. The network activity resumes happily a couple of seconds after the reset. Nov 3 00:33:07 rwsrv05 kernel: bge0: watchdog timeout -- resetting Nov 3 00:33:07 rwsrv05 kernel: bge0: link state changed to DOWN Nov 3 00:33:08 rwsrv05 kernel: bge0: link state changed to UP Nov 3 01:05:40 rwsrv05 kernel: bge0: watchdog timeout -- resetting Nov 3 01:05:40 rwsrv05 kernel: bge0: link state changed to DOWN Nov 3 01:05:41 rwsrv05 kernel: bge0: link state changed to UP Nov 3 09:44:03 rwsrv05 kernel: bge0: watchdog timeout -- resetting Nov 3 09:44:03 rwsrv05 kernel: bge0: link state changed to DOWN Nov 3 09:44:05 rwsrv05 kernel: bge0: link state changed to UP I don't see this at all on 6.1 unless I use SCHED_ULE. (Although, I haven't compiled all those additional drivers into a 6.1 system, so that might not be a fair comparison.) John Marshall. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New em driver breaks jumbo frames
On Thu, Nov 02, 2006 at 02:09:29PM -0800, Jack Vogel wrote: > Yes, this is the second report I've had, other came to me personally. There is already a PR about it. mcl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New em driver breaks jumbo frames
On Thu, Nov 02, 2006 at 09:27:14PM -0600, Mark Linimon wrote: > On Thu, Nov 02, 2006 at 02:09:29PM -0800, Jack Vogel wrote: > > Yes, this is the second report I've had, other came to me personally. > > There is already a PR about it. Ah, thanks, guess I should have searched there first... Craig ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
