Re: Still have BCE driver issues (dell pe 1950) and NFS
Hi, Will a fix/this fix be part of the 6.2 Release? We will be relying heavily on fbsd6.2 and pe1950 and are worried about the BCE stability? Kind regards, Fredrik Widlund Scott Long wrote: Olivier Mueller wrote: Le 7 nov. 06 à 01:15, Scott Long a écrit : Olivier Mueller wrote: NFS Server: dell poweredge 1950, with the 1.2.2.6 version of if_bce.c: bce0: Broadcom NetXtreme II BCM5708 1000Base-T (B1), v0.9.6 mem - Start a directory listing on it: immediate (network) crash of the NFS server. (reproduced 3 times) Do the following, then retry your test: ifconfig bce0 -txcsum Oh, this way it looks much better, thanks. Directory listing was fine, and copying files during 2-3 minutes over NFS worked as well. More tests will follow tomorrow. Next step? :-) Should I put that command somewhere in my init scripts, or even directly in rc.conf, or wait for a new if_bce0.c version? I am available for any other PE1950-related tests if this may help. Regards, Olivier Change /sys/dev/bce/if_bcereg.h so that BCE_IF_HWASSIST is defined to 0. Then recompile. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Still have BCE driver issues (dell pe 1950) and NFS
On Tuesday 07 November 2006 03:30, Fredrik Widlund wrote: Hi, Will a fix/this fix be part of the 6.2 Release? We will be relying heavily on fbsd6.2 and pe1950 and are worried about the BCE stability? Kind regards, Fredrik Widlund Scott Long wrote: Olivier Mueller wrote: Le 7 nov. 06 à 01:15, Scott Long a écrit : Olivier Mueller wrote: NFS Server: dell poweredge 1950, with the 1.2.2.6 version of if_bce.c: bce0: Broadcom NetXtreme II BCM5708 1000Base-T (B1), v0.9.6 mem - Start a directory listing on it: immediate (network) crash of the NFS server. (reproduced 3 times) Do the following, then retry your test: ifconfig bce0 -txcsum Oh, this way it looks much better, thanks. Directory listing was fine, and copying files during 2-3 minutes over NFS worked as well. More tests will follow tomorrow. Next step? :-) Should I put that command somewhere in my init scripts, or even directly in rc.conf, or wait for a new if_bce0.c version? I am available for any other PE1950-related tests if this may help. Regards, Olivier Change /sys/dev/bce/if_bcereg.h so that BCE_IF_HWASSIST is defined to 0. Then recompile. Scott I know I've brought this up before, but I have a PE1950 with a pair of bce nics that get pounded on 24/7. I've been using 6.1-R with the 0.9.6 version of the bce driver for a couple of months now. The driver is available here: http://yogurt.org/FreeBSD/if_bce.c I've emailed the author of the driver and I've at least mentioned it to Scott once but I really can't understand why we don't just import this driver into the tree. -- Thanks, Josh Paetzel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Still have BCE driver issues (dell pe 1950) and NFS
Josh Paetzel wrote: On Tuesday 07 November 2006 03:30, Fredrik Widlund wrote: Hi, Will a fix/this fix be part of the 6.2 Release? We will be relying heavily on fbsd6.2 and pe1950 and are worried about the BCE stability? Kind regards, Fredrik Widlund Scott Long wrote: Olivier Mueller wrote: Le 7 nov. 06 à 01:15, Scott Long a écrit : Olivier Mueller wrote: NFS Server: dell poweredge 1950, with the 1.2.2.6 version of if_bce.c: bce0: Broadcom NetXtreme II BCM5708 1000Base-T (B1), v0.9.6 mem - Start a directory listing on it: immediate (network) crash of the NFS server. (reproduced 3 times) Do the following, then retry your test: ifconfig bce0 -txcsum Oh, this way it looks much better, thanks. Directory listing was fine, and copying files during 2-3 minutes over NFS worked as well. More tests will follow tomorrow. Next step? :-) Should I put that command somewhere in my init scripts, or even directly in rc.conf, or wait for a new if_bce0.c version? I am available for any other PE1950-related tests if this may help. Regards, Olivier Change /sys/dev/bce/if_bcereg.h so that BCE_IF_HWASSIST is defined to 0. Then recompile. Scott I know I've brought this up before, but I have a PE1950 with a pair of bce nics that get pounded on 24/7. I've been using 6.1-R with the 0.9.6 version of the bce driver for a couple of months now. The driver is available here: http://yogurt.org/FreeBSD/if_bce.c I've emailed the author of the driver and I've at least mentioned it to Scott once but I really can't understand why we don't just import this driver into the tree. What you just posted is exactly what committed to CVS for 7-CURRENT and 6-STABLE, and what was proven to break down under moderate to heavy UDP traffic. I don't doubt that your servers have a load that doesn't trigger the problem, but if you're curious I can send you a couple of very simple test cases that will cause your driver to panic and your network interface to wedge. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Regarding Jumbo frame implementation in bge
[EMAIL PROTECTED] wrote: Hi, In bge driver, we have BGE_JUMBO_FRAMELEN defined to 9018. if_bgereg.h:#define BGE_JUMBO_FRAMELEN 9018 This macro is used to allocate the memory for jumbo buffer. If I have a MTU size of 2000, still bge will allocate the jumbo buffer of size BGE_JUMBO_FRAMELEN. Instead can we make the size to be depend on the MTU. I mean instead of using BGE_JUMBO_FRAMELEN macro we can use MTU + IP header + CRC for Jumbo buffer size. Any reason for allocating a hard coded 9018 size all Jumbo MTU frame (whether it is 9000 / 2000)? Thanks, ~Siva Sivakumar: Allocations are done via the zone managers.. and thus setup at kernel boot. A value like the MTU is set dynamically... So doing something like this would be questionable IMO.. I am sure it could be done.. but I don't see the value. In theory you have a waste for just a short time.. before its m_free'd R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 or 803-317-4952 (cell) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD 6.1 IPsec Path MTU Discovery
Hi, I am seeing some problems with some problems with IPsec encrypted gif tunnels and path mtu discovery. It seems that the router with the IPsec tunnel sends an ICMP need to frag packet with the next hop mtu set to 0. This causes ssh to retransmit a the same packet without reducing the size of the data payload. Is this a know problem? If so are there any know work arounds? Tom Network Layout: Box 1 --(lan)-- Router 1 --(lan)-- Router 2 --(Ipsec tunnel)-- Router 3 --(lan) --- Box 2 Box 1: FreeBSD 5.4 Router [123]: FreeBSD 6.1 Box 2: Linux 2.6 PING Test from box 1 to box 2 with do not fragment set and a packet larger than the path MTU: box1# ping -s 1280 -D box2 PING box2 (10.0.0.79): 1280 data bytes 36 bytes from router1 (172.17.3.5): Redirect Host(New addr: 172.17.3.6) Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 051c b454 0 40 01 c9fc 172.17.1.48 10.0.0.79 36 bytes from router2 (172.17.3.6): frag needed and DF set (MTU 0) Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 1c05 b454 0 3f 01 cafc 172.17.1.48 10.0.0.79 36 bytes from router1 (172.17.3.5): Redirect Host(New addr: 172.17.3.6) Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 051c b45f 0 40 01 c9f1 172.17.1.48 10.0.0.79 36 bytes from router2 (172.17.3.6): frag needed and DF set (MTU 0) Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 1c05 b45f 0 3f 01 caf1 172.17.1.48 10.0.0.79 ^C --- box2 ping statistics --- 2 packets transmitted, 0 packets received, 100% packet loss PING Test from box 1 to box 2 with do not fragment set and a packet smaller than the path MTU: box1# ping -s 1200 -D box2 PING box2 (10.0.0.79): 1200 data bytes 36 bytes from router1 (172.17.3.5): Redirect Host(New addr: 172.17.3.6) Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 04cc b472 0 40 01 ca2e 172.17.1.48 10.0.0.79 1208 bytes from 10.0.0.79: icmp_seq=0 ttl=61 time=111.017 ms 36 bytes from router1 (172.17.3.5): Redirect Host(New addr: 172.17.3.6) Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 04cc b479 0 40 01 ca27 172.17.1.48 10.0.0.79 1208 bytes from 10.0.0.79: icmp_seq=1 ttl=61 time=110.419 ms ^C --- box2 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 110.419/110.718/111.017/0.299 ms box1# Relevent interface configuration on box1 (from ifconfig): em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=bRXCSUM,TXCSUM,VLAN_MTU inet 172.17.1.48 netmask 0x broadcast 172.17.255.255 ether 00:0f:1f:fa:d1:b5 media: Ethernet autoselect (1000baseTX full-duplex) status: active Relevent interface configuration on router2 (from ifconfig): em0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500 options=bRXCSUM,TXCSUM,VLAN_MTU inet 172.17.3.6 netmask 0x broadcast 172.17.255.255 ether 00:c0:9f:12:13:1b media: Ethernet autoselect (1000baseTX full-duplex) status: active gif0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST mtu 1280 tunnel inet 63.174.175.252 -- 82.195.173.206 inet 192.168.174.10 -- 192.168.174.9 netmask 0xfffc ___ 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 Fri, Nov 03, 2006 at 01:31:28AM +1100, 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: ACPI CPU on acpi0 acpi_perf0: ACPI CPU Frequency Control on cpu0 acpi_throttle0: ACPI CPU Throttling on cpu0 cpu1: ACPI CPU on acpi0 acpi_throttle1: ACPI CPU Throttling 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? Anyway the OP should enable eist and p4tcc (by loading cpufreq on boot) and both acpi_perf and acpi_throttle will be gone. -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
problems compiling stable
hail hail all i had recently problems on compiling the -STABLE in my personal machine. it always stops in usr.bin/vi: [EMAIL PROTECTED] /usr/src/usr.bin/vi]# make No closing parenthesis in archive specification .depend, line 4524: Error in source archive spec /usrÌ= make: fatal errors encountered -- cannot continue [EMAIL PROTECTED] /usr/src/usr.bin/vi]# regardless of the command, this happens. i've tried make clean, make buildclean (dont existe here, someone elsewhere suggested), make buildworld (as it does a make clean ...). i'd also csup'ed several times and different days, i ereased all /usr/src, and as found when googling, tried to install the make from fresh downloaded source (cd /usr/src/usr.bin/make make install clean), but nothing worlks :( the system is a clean 6.1-R from install cd on i386. if someone could help, or light my way i'd really be thankfull .. :) matheus -- We will call you cygnus, The God of balance you shall be ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: problems compiling stable
On 11/7/06, Matthew Herzog [EMAIL PROTECTED] wrote: My attempts always end in gbde. I have posted the error before. I should be giving up by now. It's prolly been 12 attempts. i must confess i'm not too far from this ... :( as far as i cant see i'll have to way till 6.2-R comes ... matheus -- We will call you cygnus, The God of balance you shall be ___ 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 Bruno Ducrot wrote: cpu0: ACPI CPU on acpi0 acpi_perf0: ACPI CPU Frequency Control on cpu0 acpi_throttle0: ACPI CPU Throttling on cpu0 cpu1: ACPI CPU on acpi0 acpi_throttle1: ACPI CPU Throttling on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 Anyway the OP should enable eist and p4tcc (by loading cpufreq on boot) and both acpi_perf and acpi_throttle will be gone. Adding 'device cpufreq' results in dmesg looking like .. acpi0: TOSINV Capell00 on motherboard acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi0: Power Button (fixed) acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.PCIB.DOCK._STA] (Node 0xc64090e0), AE_NOT_EXIST ACPI-0239: *** Error: Method execution failed [\\_SB_.PCI0.PCIB.DOCK._STA] (Node 0xc64090e0), AE_NOT_EXIST ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.PCIB.DOCK._STA] (Node 0xc64090e0), AE_NOT_EXIST ACPI-0239: *** Error: Method execution failed [\\_SB_.PCI0.PCIB.DOCK._STA] (Node 0xc64090e0), AE_NOT_EXIST Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 acpi_ec0: Embedded Controller: GPE 0x16 port 0x62,0x66 on acpi0 cpu0: ACPI CPU on acpi0 est0: Enhanced SpeedStep Frequency Control on cpu0 p4tcc0: CPU Frequency Thermal Control on cpu0 cpu1: ACPI CPU on acpi0 est1: Enhanced SpeedStep Frequency Control on cpu1 p4tcc1: CPU Frequency Thermal Control on cpu1 acpi_lid0: Control Method Lid Switch on acpi0 battery0: ACPI Control Method Battery on acpi0 acpi_acad0: AC Adapter on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: Intel 82945GM (945GM GMCH) SVGA controller port 0x1800-0x1807 mem 0xdc10-0xdc17,0xc000-0xcfff,0xdc20-0xdc23 irq 16 at device 2.0 on pci0 agp0: detected 7932k stolen memory agp0: aperture size is 256M drmsub0: Intel i945GM: (child of agp_i810.c) on agp0 info: [drm] AGP at 0xdc10 0MB info: [drm] Initialized i915 1.4.0 20060119 pci0: display at device 2.1 (no driver attached) pcm0: Intel 82801G High Definition Audio Controller mem 0xdc24-0xdc243fff irq 22 at device 27.0 on pci0 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFUNUEQv9rrgRC1JIRAnolAJwPDqa1scbzwa/zLHU3SQeenV68XgCdEyad gGPXRIJKkx2Hc6ZWyi/tX1g= =fkpm -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: problems compiling stable
On 11/7/06, Matthew Herzog [EMAIL PROTECTED] wrote: I should add that I am using a Sun Ultrasparc machine for FreeBSD. It takes at least 8 hours to get to the point of breakage. On 11/7/06, Nenhum _de_Nos [EMAIL PROTECTED] wrote: On 11/7/06, Matthew Herzog [EMAIL PROTECTED] wrote: My attempts always end in gbde. I have posted the error before. I should be giving up by now. It's prolly been 12 attempts. i must confess i'm not too far from this ... :( as far as i cant see i'll have to way till 6.2-R comes ... matheus well, the make buildkernel this time passed ! not such good luck for buildworld :( matheus -- We will call you cygnus, The God of balance you shall be ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Missing parameter validation for syscall(57)
While stress testing GENERIC RELENG_6 from Nov 2 18:46 UTC on a NFS loopback mounted filesystem I came across this problem: http://people.freebsd.org/~pho/stress/log/cons220.html -- Peter Holm ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: problems compiling stable
Nenhum _de_Nos wrote: On 11/7/06, Matthew Herzog [EMAIL PROTECTED] wrote: I should add that I am using a Sun Ultrasparc machine for FreeBSD. It takes at least 8 hours to get to the point of breakage. On 11/7/06, Nenhum _de_Nos [EMAIL PROTECTED] wrote: On 11/7/06, Matthew Herzog [EMAIL PROTECTED] wrote: My attempts always end in gbde. I have posted the error before. I should be giving up by now. It's prolly been 12 attempts. i must confess i'm not too far from this ... :( as far as i cant see i'll have to way till 6.2-R comes ... matheus well, the make buildkernel this time passed ! not such good luck for buildworld :( matheus Have you tried cd /usr/obj/usr/src/usr.bin/vi rm -rf * rm .depend (make clean doesnt delete .depend and rm -rf * doesnt either.) then try cd /usr/src/usr.bin make just in case you have something stale lying around ? Vince PS try installing ccache to speed up your compiles. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: problems compiling stable
On Tue, Nov 07, 2006 at 03:12:18PM -0300, Nenhum _de_Nos wrote: [EMAIL PROTECTED] /usr/src/usr.bin/vi]# make No closing parenthesis in archive specification .depend, line 4524: Error in source archive spec /usrÌ= ^^ ^ ^ ^ Could this character be causing the problem? -- | 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: em driver testing
On Mon, Nov 06, 2006 at 04:14:40PM -0800, Jack Vogel wrote: Well, so run 6.2 BETA3 plus the patch I posted as Patrick mentioned and then report on that. You've got a lot of potential problem areas here, I have no experience with samba on FreeBSD. And that motherboard only has PCI as I recall, yes? Still, it should get rid of the watchdogs unless you have real hardware issues. As a point of information, I don't think that samba specifically has anything to do with the problem. I am running samba on FreeBSD, and have two servers that are rather heavily used (one is the filestore for a CFD cluster, and the other for a Maya/Muster rendering cluster), each having two em interfaces and SMP -- and have not seen any watchdog issues (they are currently running FreeBSD 6.2-PRERELEASE as of Oct 7 -- but no problems with any earlier 6.1-STABLE versions either). -- greg byshenk - [EMAIL PROTECTED] - Leiden, NL ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Important Information Regarding Your Banking Account
[1][chase.gif] Dear Chase customer, As the Internet and information technology enable us to expand our services,we are committed to maintaining the trust customers have placed in us for protecting the privacy and security of information we have about you. In order to protect your information against unauthorized access, identity theft and account fraud we earnestly ask you to update your profile. WARNING: PLEASE REMEMBER YOU NEED TO CONFIRM ALL FIELDS OF THE FORM TO AVOID ACCOUNT BLOCK To resubmit your information, please click the link below: [2]Click here to update your profile If you received this notice and you are not the authorized account holder, please be aware that it is in violation of our policy to represent oneself as another Chase user. Such action may also be in violation of local, national, and/or international law. Chase is committed to assist law enforcement with any inquiries related to attempts to misappropriate personal information with the intent to commit fraud or theft. Information will be provided at the request of law enforcement agencies to ensure that perpetrators are prosecuted to the fullest extent of the law. Thank you for your time! © 2006 JPMorgan Chase Co. _ References 1. file://localhost/tmp/tmpe54pZp.html 2. http://alphainfo.be/online.banking.account// ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em driver testing
Hi Jack I patched the driver and re-compiled the kernel and userland. All appears well with the em driver now. No more errors on it. I am getting watchdog timeouts on the xl driver now though. It was happenning before at the same time as the em ones. Now I've passed a lot of traffic on the em interface but the xl interface gets watchdog errors. The em interface still works fine but the xl one is no usable after this. The motherboard has 2 onboard xl's and I am using the one for a live IP and the other one is doing nothing. It is a server motherboard with an AMD762 north bridge. It has 64bit pci 66MHz slots which I have the em card in. The em card is a 32bit pcs 33MHz card though. Here's what the xl card is with pciconf -lhv [EMAIL PROTECTED]:15:0: class=0x02 card=0x246210f1 chip=0x980010b7 rev=0x78 hdr=0x00 vendor = '3COM Corp, Networking Division' device = '3C980-TX Fast EtherLink XL Server Adapter2' The em card is such: [EMAIL PROTECTED]:9:0: class=0x02 card=0x13768086 chip=0x107c8086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/1000 GT' Any help would be greatly appreciated. Clay - Original Message - From: Jack Vogel [EMAIL PROTECTED] To: Clayton Milos [EMAIL PROTECTED] Cc: freebsd-stable@freebsd.org; ke han [EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 2:14 AM Subject: Re: em driver testing Well, so run 6.2 BETA3 plus the patch I posted as Patrick mentioned and then report on that. You've got a lot of potential problem areas here, I have no experience with samba on FreeBSD. And that motherboard only has PCI as I recall, yes? Still, it should get rid of the watchdogs unless you have real hardware issues. Good luck, Jack On 11/6/06, Clayton Milos [EMAIL PROTECTED] wrote: Hi there I am having similar issues. Running 6.1-RELEASE. I'm using the box as a samba server with pure-ftpd on it too with 2.5T of raid storage in it. the box is running the generic MP kernel on a Tyan Thunder K7 with the latest bios v2.14 and dual AthlonMP's. ECC Reg ram that passed all tests with memtest. When I pull a few concurrent files over samba or if i pull a big file (say 2-3G) over ftp to my laptop it runs at 30MB/sec but usually locks up the box with watchdog timeout on the em interface. Usually it pops up with timeouts on the xl interface at the same time and after a few seconds on the ahc (onboard adaptec scsi) interfce and I have to hard boot the box to get it back to life. I''ve tried the same box with a 3com 3C996B-T NIC which has a Broadcom BCM5701TKHB chipset on it. It crashes within minutes with no traffic on the interface. In fact the interface will accept an IP address but times out pinging anything on the LAN. If a kernel developer would like access to the box to chek it out please mail me. Regards Clay Hello! On Tue, Nov 07, 2006 at 04:55:50AM +0800, ke han wrote: I have a Sun X4100 which uses Intel ethernet. I would like to install amd64 6.2beta3 on this server and put it through some tests. But I have no idea what tests to run or how to run them. Can someone provide some pointers? I am happy to post my findings. Put some CPU load on the machine, e.g. by running cd /usr/src sh while true do make -j4 buildworld done mk.log on one terminal and then transfer some data to the system, e.g. by fetch(1)ing via FTP from another box connected to the same LAN. On all systems I have, there is no need to saturate the Gbit-Link. 100 Mbit/s local connection will trigger the problem, too. If the problem exists on your system, you will see emN - watchdog timeout messages on the console and in /var/log/messages, followed by a reset of the interface and a short and recoverable, but complete, loss of connectivity. A couple of seconds, maybe. This is enough to frustrate people, who e.g. run large backup jobs over a single TCP connection that takes a couple of hours to complete - the interface reset aborts the backup :-/ I must say that it seems to me, these guys are putting a hell of a lot of effort into this problem and we are making progress. Things look quite good to me for 6.2-RELEASE. HTH, 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] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Still have BCE driver issues (dell pe 1950) and NFS
On Tuesday 07 November 2006 10:10, Scott Long wrote: Josh Paetzel wrote: On Tuesday 07 November 2006 03:30, Fredrik Widlund wrote: Hi, Will a fix/this fix be part of the 6.2 Release? We will be relying heavily on fbsd6.2 and pe1950 and are worried about the BCE stability? Kind regards, Fredrik Widlund Scott Long wrote: Olivier Mueller wrote: Le 7 nov. 06 à 01:15, Scott Long a écrit : Olivier Mueller wrote: NFS Server: dell poweredge 1950, with the 1.2.2.6 version of if_bce.c: bce0: Broadcom NetXtreme II BCM5708 1000Base-T (B1), v0.9.6 mem - Start a directory listing on it: immediate (network) crash of the NFS server. (reproduced 3 times) Do the following, then retry your test: ifconfig bce0 -txcsum Oh, this way it looks much better, thanks. Directory listing was fine, and copying files during 2-3 minutes over NFS worked as well. More tests will follow tomorrow. Next step? :-) Should I put that command somewhere in my init scripts, or even directly in rc.conf, or wait for a new if_bce0.c version? I am available for any other PE1950-related tests if this may help. Regards, Olivier Change /sys/dev/bce/if_bcereg.h so that BCE_IF_HWASSIST is defined to 0. Then recompile. Scott I know I've brought this up before, but I have a PE1950 with a pair of bce nics that get pounded on 24/7. I've been using 6.1-R with the 0.9.6 version of the bce driver for a couple of months now. The driver is available here: http://yogurt.org/FreeBSD/if_bce.c I've emailed the author of the driver and I've at least mentioned it to Scott once but I really can't understand why we don't just import this driver into the tree. What you just posted is exactly what committed to CVS for 7-CURRENT and 6-STABLE, and what was proven to break down under moderate to heavy UDP traffic. I don't doubt that your servers have a load that doesn't trigger the problem, but if you're curious I can send you a couple of very simple test cases that will cause your driver to panic and your network interface to wedge. Scott My bad. Thanks for clearing this up. (In my case pretty much all of the traffic is TCP which I guess would explain why it's working for me) -- Thanks, Josh Paetzel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em driver testing
On 11/7/06, Clayton Milos [EMAIL PROTECTED] wrote: Hi Jack I patched the driver and re-compiled the kernel and userland. All appears well with the em driver now. No more errors on it. I am getting watchdog timeouts on the xl driver now though. It was happenning before at the same time as the em ones. Now I've passed a lot of traffic on the em interface but the xl interface gets watchdog errors. The em interface still works fine but the xl one is no usable after this. I'm not sure what it is, but the fact that a variety of nic drivers are having this same problem indicates that something changed in the if_timer and its caller, someone knowing that subsystem would be better qualified to say what. The other drivers should do the same thing that em did, and stop using the net layer timer :) Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.2/AMD64: missing driver for SB Audigy SE / CA0106-DAT
The driver (OSS v4.0-rc-172) works, but need a push: startscript in /etc/rc.d/oss does not have the right access privileges set so oss_enable=YES fails at start. The execution permissin is not set. Bugs/features(?): Why is the whole stuff installing in /usr, /etc and not, as expected, /usr/local/? This should be changed. On my board (ASUS A8N32-SLI Deluxe AC97 Codec is disabled - but the OSS driver does still install also a ich.ko kernel module. Why? I want this AC97 crap go away. Regards, Oliver Dear Sirs. My FreeBSD 6.2-PRE/AMD64 box has been equipted with a PCI Soundblaster Audigy SE soundcard. This soundcard unfortunately does utilize a chip called CA0106-DAT as pciconf -lv reported. I tried several snd_xxx driver found in most recent FreeBSD 6.2-PRE/AMD64 stuff, but even snd_em10k1 doesn't work. So I googled around and found ports/em10kx and tried this one - also with no success. As I could then read in the README, my obtained soundcard especially with the utilized chip isn't supported (yet?). So I tried OSS, but this driver is a commercial third party driver and therefore a bit suspicious in my opinion. By the way, the driver only produces a ear-killing noise - no sound, nothing. Well, as I could see in many other forums around the net, the SoundBlaster Audigy SE is a quite common soundcard and I would wonder if it isn't supported by FreeBSD. Are there any efforts pointing to this issue? I should have better read the exclusions on supported hardware, too late I realized that the soundcard of my box has not an emu em10k1 chipset. Any comments are highly appreciated. Thanks in advance, Oliver P.S. Please send eMail direcectly or in CC to my address as I'm not on this list, thank you very much. Hi Folks, OSS v3.99.4c and OSS v4.0rc2-172 have the Audigy SE problems fixed. Go to http://www.opensound.com/test for the v4.0 drivers. commercial third party driver and therefore a bit suspicious in my opinion. So Nvidia closed source driver is not suspicious but 4Front's OSS is?. FYI, we've been in business since 1996 and not 1 complaint about our software being malicious has ever been filed! best regards Dev Mazumdar 4Front Technologies --- 4Front Technologies 4035 Lafayette Place, Unit F, Culver City, CA 90232, USA. Tel: (310) 202 8530 URL: www.opensound.com Fax: (310) 202 0496 Email: [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: em driver testing
We've basically identified problems with the way that watchdogs are handled. It is very fragile and sensitive to timing, so it's not surprising that adjusting the the timing in one driver will affect another driver. The solution is to push the timieout/watchdog logic entirely into the NIC drivers, like we did for if_em. That will take some time, and I doubt that xl specifically will get fixed for 6.2. Scott Clayton Milos wrote: Hi Jack I patched the driver and re-compiled the kernel and userland. All appears well with the em driver now. No more errors on it. I am getting watchdog timeouts on the xl driver now though. It was happenning before at the same time as the em ones. Now I've passed a lot of traffic on the em interface but the xl interface gets watchdog errors. The em interface still works fine but the xl one is no usable after this. The motherboard has 2 onboard xl's and I am using the one for a live IP and the other one is doing nothing. It is a server motherboard with an AMD762 north bridge. It has 64bit pci 66MHz slots which I have the em card in. The em card is a 32bit pcs 33MHz card though. Here's what the xl card is with pciconf -lhv [EMAIL PROTECTED]:15:0: class=0x02 card=0x246210f1 chip=0x980010b7 rev=0x78 hdr=0x00 vendor = '3COM Corp, Networking Division' device = '3C980-TX Fast EtherLink XL Server Adapter2' The em card is such: [EMAIL PROTECTED]:9:0: class=0x02 card=0x13768086 chip=0x107c8086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/1000 GT' Any help would be greatly appreciated. Clay - Original Message - From: Jack Vogel [EMAIL PROTECTED] To: Clayton Milos [EMAIL PROTECTED] Cc: freebsd-stable@freebsd.org; ke han [EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 2:14 AM Subject: Re: em driver testing Well, so run 6.2 BETA3 plus the patch I posted as Patrick mentioned and then report on that. You've got a lot of potential problem areas here, I have no experience with samba on FreeBSD. And that motherboard only has PCI as I recall, yes? Still, it should get rid of the watchdogs unless you have real hardware issues. Good luck, Jack On 11/6/06, Clayton Milos [EMAIL PROTECTED] wrote: Hi there I am having similar issues. Running 6.1-RELEASE. I'm using the box as a samba server with pure-ftpd on it too with 2.5T of raid storage in it. the box is running the generic MP kernel on a Tyan Thunder K7 with the latest bios v2.14 and dual AthlonMP's. ECC Reg ram that passed all tests with memtest. When I pull a few concurrent files over samba or if i pull a big file (say 2-3G) over ftp to my laptop it runs at 30MB/sec but usually locks up the box with watchdog timeout on the em interface. Usually it pops up with timeouts on the xl interface at the same time and after a few seconds on the ahc (onboard adaptec scsi) interfce and I have to hard boot the box to get it back to life. I''ve tried the same box with a 3com 3C996B-T NIC which has a Broadcom BCM5701TKHB chipset on it. It crashes within minutes with no traffic on the interface. In fact the interface will accept an IP address but times out pinging anything on the LAN. If a kernel developer would like access to the box to chek it out please mail me. Regards Clay Hello! On Tue, Nov 07, 2006 at 04:55:50AM +0800, ke han wrote: I have a Sun X4100 which uses Intel ethernet. I would like to install amd64 6.2beta3 on this server and put it through some tests. But I have no idea what tests to run or how to run them. Can someone provide some pointers? I am happy to post my findings. Put some CPU load on the machine, e.g. by running cd /usr/src sh while true do make -j4 buildworld done mk.log on one terminal and then transfer some data to the system, e.g. by fetch(1)ing via FTP from another box connected to the same LAN. On all systems I have, there is no need to saturate the Gbit-Link. 100 Mbit/s local connection will trigger the problem, too. If the problem exists on your system, you will see emN - watchdog timeout messages on the console and in /var/log/messages, followed by a reset of the interface and a short and recoverable, but complete, loss of connectivity. A couple of seconds, maybe. This is enough to frustrate people, who e.g. run large backup jobs over a single TCP connection that takes a couple of hours to complete - the interface reset aborts the backup :-/ I must say that it seems to me, these guys are putting a hell of a lot of effort into this problem and we are making progress. Things look quite good to me for 6.2-RELEASE. HTH, 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
Re: em driver testing
Clayton Milos wrote: Hi Jack I patched the driver and re-compiled the kernel and userland. All appears well with the em driver now. No more errors on it. I am getting watchdog timeouts on the xl driver now though. It was happenning before at the same time as the em ones. Now I've passed a lot of traffic on the em interface but the xl interface gets watchdog errors. The em interface still works fine but the xl one is no usable after this. Has it not been established by someone that the problem is in freebsd (scheduler iirc) and not the drivers themselves? This along with the bge/bce wtachdog timeouts seems to confirm that. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em driver testing
On 11/7/06, Mike Jakubik [EMAIL PROTECTED] wrote: Clayton Milos wrote: Hi Jack I patched the driver and re-compiled the kernel and userland. All appears well with the em driver now. No more errors on it. I am getting watchdog timeouts on the xl driver now though. It was happenning before at the same time as the em ones. Now I've passed a lot of traffic on the em interface but the xl interface gets watchdog errors. The em interface still works fine but the xl one is no usable after this. Has it not been established by someone that the problem is in freebsd (scheduler iirc) and not the drivers themselves? This along with the bge/bce wtachdog timeouts seems to confirm that. Yes, I think its pretty likely to be in the timer/clock code, something must have changed. However, I like the design change we made to em better anyway, the net/if timer is UP design, and has ALWAYS been vulnerable to races, its best to do what we did (its in patch yet and not checked in btw). Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em driver testing
Jack Vogel wrote: On 11/7/06, Clayton Milos [EMAIL PROTECTED] wrote: Hi Jack I patched the driver and re-compiled the kernel and userland. All appears well with the em driver now. No more errors on it. I am getting watchdog timeouts on the xl driver now though. It was happenning before at the same time as the em ones. Now I've passed a lot of traffic on the em interface but the xl interface gets watchdog errors. The em interface still works fine but the xl one is no usable after this. I'm not sure what it is, but the fact that a variety of nic drivers are having this same problem indicates that something changed in the if_timer and its caller, someone knowing that subsystem would be better qualified to say what. The other drivers should do the same thing that em did, and stop using the net layer timer :) Jack I think it's more that the if_em driver watchdog was insulating the if_xl driver. Once the if_em component was removed, the if_xl driver was the next in line to be a victim. So yes, like you say, all of the drivers need to be fixed. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: problems compiling stable
On 2006-11-07, Vince Hoffman wrote: PS try installing ccache to speed up your compiles. Definitely do not do this, especially if you're having problems with building something. There are all kinds of subtle things that break with ccache. Although it can be a great speed boost when things go well, it needs to be the first thing you get rid of when there are problems. And that adds up to a recommendation not to use it at all. Greg ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em driver testing
Mike Jakubik wrote: Clayton Milos wrote: Hi Jack I patched the driver and re-compiled the kernel and userland. All appears well with the em driver now. No more errors on it. I am getting watchdog timeouts on the xl driver now though. It was happenning before at the same time as the em ones. Now I've passed a lot of traffic on the em interface but the xl interface gets watchdog errors. The em interface still works fine but the xl one is no usable after this. Has it not been established by someone that the problem is in freebsd (scheduler iirc) and not the drivers themselves? This along with the bge/bce wtachdog timeouts seems to confirm that. Mike, If you have insight into the bce driver, I would highly appreciate if you would share it. Scott (the guy who fixed bce) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em driver testing
Scott Long wrote: Mike, If you have insight into the bce driver, I would highly appreciate if you would share it. Scott (the guy who fixed bce) I don't have any bce hardware myself, I'm just using the information from the list. I have some em and fxp hardware however that i can use to do tests. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em driver testing
Mike Jakubik wrote: Scott Long wrote: Mike, If you have insight into the bce driver, I would highly appreciate if you would share it. Scott (the guy who fixed bce) I don't have any bce hardware myself, I'm just using the information from the list. I have some em and fxp hardware however that i can use to do tests. It's just unclear to me how you're associating bce problems with checksum offloading and IP fragmentation to em problems with design issues in the watchdog code. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em driver testing
At 04:52 PM 11/7/2006, Scott Long wrote: I think it's more that the if_em driver watchdog was insulating the if_xl driver. Once the if_em component was removed, the if_xl driver was the next in line to be a victim. So yes, like you say, all of the drivers need to be fixed. I wonder if thats what the issue I was seeing on the rl interface. While trying to stress test an em based machine, I saw Nov 6 17:33:05 releng6-865 kernel: rl0: watchdog timeout while blasting out UDP traffic via netrate from the rl based box to the em based box. ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em driver testing
Jack, I have done some tests, here are my results. On 6.2-BETA3 i was able to get a timeout while compiling the kernel and ftping a large file from another server with the same card. On 6.2-STABLE cvsuped today i was not able to produce a timeout, i then applied your patch and the results were the same. [EMAIL PROTECTED]:10:0: class=0x02 card=0x11768086 chip=0x10768086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82547EI Gigabit Ethernet Controller' ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: problems compiling stable
Have you tried cd /usr/obj/usr/src/usr.bin/vi rm -rf * rm .depend (make clean doesnt delete .depend and rm -rf * doesnt either.) then try cd /usr/src/usr.bin make just in case you have something stale lying around ? Vince PS try installing ccache to speed up your compiles. jackpot ! there was a .depend there and then i rm -rf all /usr/obj/usr and the system is compiling ok now ;) thank you very much ! :) matheus - We will call you cygnus, The God of balance you shall be ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
