Re: ICH7 SATA and em interrupt sharing
Hi! On Tue, Aug 22, 2006 at 10:50:47AM +0900, Pyun YongHyeon wrote: em0: Missing Tx completion interrupt! Thanks for the testing. The above message means the patch really worked. Otherwise you would have seen (false) watchdog errors on your system. I guess the two possible cause of missing Tx completion interrupts comes from a chipset bug or Tx interrupt moderation mechanism. If Tx interrupt moderation mechanism is the cause of false watchdog triggering we should have to fix all device drivers that have Tx interrupt moderation capability. I'll have to check archives for bge(4). I'll commit the em(4) patch soon. What you see in ssh session and lack of response for ICMP echo request indicates other issues. I can't sure but it may not related with network drivers at all(eg. sharing interrupt with other devices). Well, if I disable the em onboard interfaces and use the onboard fxp interface instead, everything runs smoothely. Looks like I will use this workaround for now. Etherexpress 100 cards in bulk quantities are cheap, so I can even insert a second NIC into the system. 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: speedstep / cpu frequency control on 6-stable?
Torfinn Ingolfsen wrote: Hello, What ids the current way to control cpu speed (and power consumption) in FreeBSD 6-stable? Before, est was one way, but all traces of est has disappeared from /etc/defaults/rc.conf and thereabouts. I find something about powerd and power_profile, but they don't seem to work, and I can't seem to find out what variables / configuration items to set. 'man cpufreq' isn't much help in that regard either. In what way does powerd not work for you? ([EMAIL PROTECTED])$grep powerd /etc/defaults/rc.conf powerd_enable=NO # Run powerd to lower our power usage. powerd_flags= # Flags to powerd (if enabled). read man powerd for flags and try powerd -v this should give an indication of what happens, for example I get [EMAIL PROTECTED] -v idle time 90%, decreasing clock speed from 1666 MHz to 1457 MHz idle time 90%, decreasing clock speed from 1457 MHz to 1249 MHz idle time 90%, decreasing clock speed from 1249 MHz to 1041 MHz idle time 90%, decreasing clock speed from 1041 MHz to 833 MHz idle time 90%, decreasing clock speed from 833 MHz to 624 MHz idle time 90%, decreasing clock speed from 624 MHz to 416 MHz idle time 90%, decreasing clock speed from 416 MHz to 208 MHz idle time 65%, increasing clock speed from 208 MHz to 624 MHz idle time 90%, decreasing clock speed from 624 MHz to 416 MHz idle time 90%, decreasing clock speed from 416 MHz to 208 MHz idle time 65%, increasing clock speed from 208 MHz to 624 MHz idle time 90%, decreasing clock speed from 624 MHz to 416 MHz which is a pain if i'm running X on mains so I tend to use -a maximum -b adaptive as my powerd flags as it defaults to adaptive even if your on mains power. Do I need working acpi to use a power control method? Umm not sure as mine works, but probably, since my dmesg says I have acpi_throttle0: ACPI CPU Throttling [EMAIL PROTECTED] | grep -i cpu CPU: Genuine Intel(R) CPU T2300 @ 1.66GHz (1662.51-MHz 686-class CPU) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu0: ACPI CPU on acpi0 acpi_throttle0: ACPI CPU Throttling on cpu0 cpu1: ACPI CPU on acpi0 acpi_throttle1: ACPI CPU Throttling on cpu1 SMP: AP CPU #1 Launched! Vince ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /sys/dev/ata/ata-chipset.c 1.168 MFC?
On Mon, Aug 21, 2006 at 03:23:37PM -0400, David Gilbert wrote: Could someone please MFC at least v 1.168 of ata-chipset.c into RELENG_6? Specifically the Nvidia NFORCE-4 support? Most of the AMD64 motherboards I've gotten lately require this patch. I have been able to apply diff between 1.165 and 1.168 to RELENG-6 and it makes the chipset work. (this also requires 1.65 to 1.68 of ata-pci.h). Any takers? I'll do it in a few days if Soren doesn't do it earlier -- I also have plenty of such motherboards which want to meet 6.x. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpDteDSzmLZB.pgp Description: PGP signature
Re: /sys/dev/ata/ata-chipset.c 1.168 MFC?
I plan to bacport *all* of ATA, as there are so many bugfixes that a resync is needed. ATA from -current fits right into 6-stable so its a nobrainer it just need a little more exposure... -Søren On 8/22/06, Ruslan Ermilov [EMAIL PROTECTED] wrote: On Mon, Aug 21, 2006 at 03:23:37PM -0400, David Gilbert wrote: Could someone please MFC at least v 1.168 of ata-chipset.c into RELENG_6? Specifically the Nvidia NFORCE-4 support? Most of the AMD64 motherboards I've gotten lately require this patch. I have been able to apply diff between 1.165 and 1.168 to RELENG-6 and it makes the chipset work. (this also requires 1.65 to 1.68 of ata-pci.h). Any takers? I'll do it in a few days if Soren doesn't do it earlier -- I also have plenty of such motherboards which want to meet 6.x. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /sys/dev/ata/ata-chipset.c 1.168 MFC?
Hi Soren, On Tue, Aug 22, 2006 at 10:56:19AM +0200, S?ren Schmidt wrote: I plan to bacport *all* of ATA, as there are so many bugfixes that a resync is needed. ATA from -current fits right into 6-stable so its a nobrainer it just need a little more exposure... Do you have any ETA? Yes, I'm currently running HEAD version of sys/dev/ata/ on these motherboards. Thanks! Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpEhZyMYNSLZ.pgp Description: PGP signature
Re: /sys/dev/ata/ata-chipset.c 1.168 MFC?
Give me a few days and I'll get to it if I dont get any serious issues before that... -Søren On 8/22/06, Ruslan Ermilov [EMAIL PROTECTED] wrote: Hi Soren, On Tue, Aug 22, 2006 at 10:56:19AM +0200, S?ren Schmidt wrote: I plan to bacport *all* of ATA, as there are so many bugfixes that a resync is needed. ATA from -current fits right into 6-stable so its a nobrainer it just need a little more exposure... Do you have any ETA? Yes, I'm currently running HEAD version of sys/dev/ata/ on these motherboards. Thanks! Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
if_xl WOL patch against 5.5
Hi, There has been an open PR to enable WOL on HEAD since Jul 2005: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/83807 That included WOL wupport for the if_sis driver. I've used that to create a patch for 5.5 and the if_xl driver, I do not have access to a card that uses the if_sis driver so I did not modify that driver. The patch is available from: http://www.slowthinkers.net/~marcel/diff/22-08-2006.freebsd.wol.diff I've tested it against a card that is detected as: xl0: 3Com 3c905C-TX Fast Etherlink XL port 0xc400-0xc47f mem 0xd800-0xd87f irq 19 at device 9.0 on pci0 What would be the next step to get this commited ? Regards, - marcel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: speedstep / cpu frequency control on 6-stable?
On Tue, 22 Aug 2006 09:32:05 +0100 Vince [EMAIL PROTECTED] wrote: My system is: [EMAIL PROTECTED] uname -a FreeBSD kg-home.kg4.no 6.1-STABLE FreeBSD 6.1-STABLE #2: Mon Aug 21 15:58:01 CEST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/AS5672 i386 [EMAIL PROTECTED] dmesg | grep -i cpu CPU: Genuine Intel(R) CPU T2250 @ 1.73GHz (1733.41-MHz 686-class CPU) cpu0 on motherboard powerd -v I get: [EMAIL PROTECTED] powerd -v powerd: lookup freq: No such file or directory Do I need working acpi to use a power control method? Umm not sure as mine works, but probably, since my dmesg says I have Ok, I just checked, and with acpi enabled, powerd runs. I run this laptop (AcerAspire AS5672) with acpi disabled, as this is currently the only way I can get a network connection working on it. Howeever, it gets very hot, so I would like to control the temperature better. -- Regards Torfinn Ingolfsen, Norway ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: speedstep / cpu frequency control on 6-stable?
On Tue, 22 Aug 2006 08:37:27 +0930 Daniel O'Connor [EMAIL PROTECTED] wrote: Loading cpufreq should give you sysctl's which control CPU frequency. powerd uses these to adjust frequency based on load. I have this in rc.conf powerd_enable=YES powerd_flags=-i 70 -r 30 -a adaptive -b adaptive -n adaptive -p 200 With acpi enabled on this laptop, the above parameters works, and powerd runs. However, then I don't have any network connection to it. Devil's choice :-( With acpi disabled, powerd refuses to run. Anyway, thanks for quick and good answers, both of you. -- Regards, Torfinn Ingolfsen, Norway ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: device carp / freebsd-update
On Mon, 2006-08-21 at 21:19 +0200, Andy Hilker wrote: You (Gavin Atkinson) wrote: [...] I don't suppose there's any chance you know if ucarp works with 6.1-RELEASE and IPv6? This is the one thing stopping me moving my machines to 6.1-RELEASE. If you don't know, then you've given me yet another thing to add to my todo list! No, sorry, I have not tested it. But maybe the kernel carp? No, kernel carp used to work with IPv6 in 6.0-RELEASE, but was broken sometime before 6.1-RELEASE. It's all in kern/98622. I may have to test ucarp though, it would be nice to be able to run a GENERIC kernel, although my gut instinct is that this sort of functionality should be kept in the kernel. Gavin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make buildworld does nothing
Doug Barton [EMAIL PROTECTED] wrote: Oliver Fromme wrote: Doug Barton wrote: Tom Hummel wrote: alright, it was bash :( stupid shell. Um, sorry, let's not blame the shell for the BCK (between chair and keyboard) problem. Lots of us use bash as our everyday shell (for privileged and unprivileged users) without the kinds of problems you described. The first thing I do when I install a new freebsd machine is to change root's shell to /bin/sh, and copy over my customized .profile which either execs bash if it finds it, or sets up sh with my aliases, etc. That's what su -m is good for. There are actually some things in root's environment that I want to be different Me too. That's why I have this in my ~/.zshrc: if [[ $EUID -ne 0 ]]; then ... # settings for non-root only else ... # settings for root only fi When a new machine gets into my hands, all I have to do is copy over my ~/.zshrc. Then I will have my familiar work environment, both as normal user and as root. Another good thing about that approach is the fact that you don't have to change anything outside of your home. In particular, you don't have to change root's login shell or anything inside root's home, so other admins on the machine aren't affected at all, and everyone can use his own favourite shell and profile, without interfering with anybody else. 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. C++ is to C as Lung Cancer is to Lung. -- Thomas Funke ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPFW rules
SigmaX asdf wrote: I'm trying to setup IPFW to block all ports except those I specify. For starters I'm just opening SSH. # ipfw list 00050 divert 8668 ip4 from any to any via rl0 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 00300 deny ip from 127.0.0.0/8 to any 00301 allow log tcp from any to any dst-port 22 00399 deny ip from any to any 65000 allow ip from any to any 65535 deny ip from any to any Traffic is still blocked on port 22 -- I can't login via SSH. What am I doing wrong, and what rule should I be using to allow SSH in and through? TCP connections are always 2-way (i.e. they require both ingoing and outgoing packets). But your rules allow only one way. There are three possibilities: (1) Sdd a rule allow log tcp from any to any src-port 22 (not very efficient, but works). (2) Add setup to the dst-port 22 rule and add a rule that allows established connections. (3) Use keep-state. See the ipfw(8) manual page for details. You should also read a good book on TCP/IP and packet filter configuration. By the way, you probably should also allow name server traffic (port 53, UDP and TCP) and ICMP packets. 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. That's what I love about GUIs: They make simple tasks easier, and complex tasks impossible. -- John William Chambless ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bce0: Error mapping mbuf into TX chain!
On Fri, Aug 11, 2006 at 10:27:09AM -0700, David Christensen wrote: The driver seems to work fine now, that test no longer crashes it. I also did some iperf tests between two machines with these cards ( the other running linux) and I was getting ~950 MBit /sec between them! Thanks for your help! I'll keep beating on these machines for a few days to come, but will be so glad to get them into productions, they're so fast! :-) Glad to hear things are working now. We've also got a Dell 1950, that was exhibiting exactly the same symptoms. I manually patched up the bce driver and rebuilt the kernel, which got me to the point of having a working enough network device to be able to cvsup to -STABLE and rebuild world and kernel. However, now we no longer get the 'Error mapping mbuf into TX chain!' errors, but instead, under quite low network load, we get : Watchdog timeout occurred, resetting! Which it never really entirely recovers from, requiring a reboot to get working networking back again. I'm a bit at a loss as to what to check next. Only thing that seems particularly different to the other systems described above is that we were running the i386 build, rather than the amd64, so I'm installing amd64 stable instead, just in case this makes any difference. I'm happy to provide any debugging output or whatever that might make it easier for anyone else to help diagnose things... Thanks, Sam. -- Fortified with Essential Bitterness and Sarcasm Matt Groening, Binky's Guide to Love. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.5 to 6.1 upgrade
Thanks to all who responded for the collective good advice. On Tue, 22 Aug 2006, Greg Byshenk wrote: On Mon, Aug 21, 2006 at 11:52:02PM +0200, Stefan Bethke wrote: Am 21.08.2006 um 18:19 schrieb Ian Smith: I recently (without drama) upgraded a 5.4-RELEASE system to FreeBSD 5.5-STABLE #1: Tue Aug 1 11:11:20 EST 2006 for 'target practice' at least, on the way to 6.1-STABLE I was preparing to portupgrade everything next, when I wondered: a) should I upgrade from RELENG_5 straight to RELENG_6 or should I be stopping off at 6.1-RELEASE along the way first? and I'd go straight to 6-stable. Make sure you have a good backup, even if you stop over at 6.1. I see no reason not to go directly to 6-stable (if that is what you plan to run); I've done it with multiple machines, and just jump right to the 6-stable version that is active on the machines running 6.x. Though I've had no problems, I second the recommendation to have a good backup. Also, if you don't have a known-good 6-stable build, you might want to upgrade to the GENERIC kernel. Thanks. On reflection, I think I'll go via 6.1 (more target practice), use GENERIC if there's any trouble, then to 6-stable as a smaller step. b) do I need to upgrade all existing ports (way out of date) before the source upgrade, or can I be confident of doing that from 6.1 (-R or -S)? FWIW: a wee Celeron 300, so minimising upgrade build times is desirable. Unless you have business critical apps running (downtime must be minimal), you can wait until you've completed the upgrade to 6- stable, and then run portupgrade -af. If you'd like to run the portupgrade overnight, you might want to define BATCH, and possibly set any port building options in /usr/local/etc/pkgtools.conf, otherwise, the port builds will be frequently interrupted by make config questions. Good reminders; this box won't be critical till it's all working .. It shouldn't be necessary to rebuild ports before the upgrade. If there is something running that is critical, you might want to upgrade it first, just be sure, but it probably isn't necessary. I upgraded a workstation with 200+ ports installed, and saw no problems (I can't for certain that nothing was broken before I upgraded the ports, but I experienced no problems). Good to confirm. I haven't so many ports installed that I couldn't start from scratch if it all fell over, so I can play with ports and packages till I finally learn how to use all the tools effectively. Cheers, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make buildworld does nothing
Oliver Fromme wrote: Me too. That's why I have this in my ~/.zshrc: That's the great thing about Unix, more than one way to do things. :) Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: bce0: Error mapping mbuf into TX chain!
Sam, I've got a PowerEdge 2950 with a DRAC 5 card, and I'm having what appears to be the same set of issues. I'm running 6.1 amd64 RELEASE. I've only gotten the bce0: Error mapping mbuf into TX chain! error a few times now. Although the box isn't in production at the moment, we've been sending quite a bit of data (several GB) across the interface without a hitch (basically remote COPY statements for postgresql). It sounds like your 1950 is/was having the issue more frequently (our 2950 stays up for days at a time). However, the fact that I do get the error every now and then is still a concern, so I plan to rebuild world and kernel when I get the chance. Please keep us posted on your findings, and if it'd be useful to have another box to run tests on, I'd be happy to give it a go. Thanks, Bucky -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sam Eaton Sent: Tuesday, August 22, 2006 11:14 AM To: [EMAIL PROTECTED] Subject: Re: bce0: Error mapping mbuf into TX chain! On Fri, Aug 11, 2006 at 10:27:09AM -0700, David Christensen wrote: The driver seems to work fine now, that test no longer crashes it. I also did some iperf tests between two machines with these cards ( the other running linux) and I was getting ~950 MBit /sec between them! Thanks for your help! I'll keep beating on these machines for a few days to come, but will be so glad to get them into productions, they're so fast! :-) Glad to hear things are working now. We've also got a Dell 1950, that was exhibiting exactly the same symptoms. I manually patched up the bce driver and rebuilt the kernel, which got me to the point of having a working enough network device to be able to cvsup to -STABLE and rebuild world and kernel. However, now we no longer get the 'Error mapping mbuf into TX chain!' errors, but instead, under quite low network load, we get : Watchdog timeout occurred, resetting! Which it never really entirely recovers from, requiring a reboot to get working networking back again. I'm a bit at a loss as to what to check next. Only thing that seems particularly different to the other systems described above is that we were running the i386 build, rather than the amd64, so I'm installing amd64 stable instead, just in case this makes any difference. I'm happy to provide any debugging output or whatever that might make it easier for anyone else to help diagnose things... Thanks, Sam. -- Fortified with Essential Bitterness and Sarcasm Matt Groening, Binky's Guide to Love. ___ 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: 5.5 to 6.1 upgrade
On Aug 22, 2006, at 11:37 AM, Ian Smith wrote: It shouldn't be necessary to rebuild ports before the upgrade. If there is something running that is critical, you might want to upgrade [ ... ] Good to confirm. I haven't so many ports installed that I couldn't start from scratch if it all fell over, so I can play with ports and packages till I finally learn how to use all the tools effectively. you *really* want to rebuild anything that uses shared libs from the ports tree, or anything that is a shared lib in the ports tree. Things that only use base system libs and don't do any dyanamic loading of external object code are safe to leave alone, as long as they don't provide shared objects. don't find this out the hard way :-(
Re: 5.5 to 6.1 upgrade
Vivek Khera написа: On Aug 22, 2006, at 11:37 AM, Ian Smith wrote: It shouldn't be necessary to rebuild ports before the upgrade. If there is something running that is critical, you might want to upgrade [ ... ] Good to confirm. I haven't so many ports installed that I couldn't start from scratch if it all fell over, so I can play with ports and packages till I finally learn how to use all the tools effectively. you *really* want to rebuild anything that uses shared libs from the ports tree, or anything that is a shared lib in the ports tree. Things that only use base system libs and don't do any dyanamic loading of external object code are safe to leave alone, as long as they don't provide shared objects. don't find this out the hard way :-( How to find which is dynamically using libs and which application is not? This is something I was wondering before... Thank you in advance. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.5 to 6.1 upgrade
On Aug 22, 2006, at 11:56 AM, Todorov @ Paladin wrote: [ ... ] How to find which is dynamically using libs and which application is not? You can use ldd. In practice, however, pretty much all software nowadays depends on shared libraries, so it's reasonable to do a pkg_delete -a after upgrading to a new major version of FreeBSD, and then reinstall all of the ports you use once you've finished upgrading. Run pkg_info before the upgrade and keep track of this output to help you remember what ports you've got installed... -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bce0: Error mapping mbuf into TX chain!
On Tue, Aug 22, 2006 at 02:46:04PM -0400, Bucky Jordan wrote: Sam, I've got a PowerEdge 2950 with a DRAC 5 card, and I'm having what appears to be the same set of issues. I'm running 6.1 amd64 RELEASE. I've only gotten the bce0: Error mapping mbuf into TX chain! error a few times now. Although the box isn't in production at the moment, we've been sending quite a bit of data (several GB) across the interface without a hitch (basically remote COPY statements for postgresql). It sounds like your 1950 is/was having the issue more frequently (our 2950 stays up for days at a time). The 'error mapping mbuf' error seems to have been fixed by the latest set of changes to if_bce.c - after upgrading to the latest stable, that problem stopped happening. However, instead of that, under rather higher load, we now get the watchdog timer error instead. This is not good :) I can get it within minutes with something like building something big from ports, during the initial source download. However, the fact that I do get the error every now and then is still a concern, so I plan to rebuild world and kernel when I get the chance. Please keep us posted on your findings, and if it'd be useful to have another box to run tests on, I'd be happy to give it a go. I think moving to stable will fix the mbuf error for you, as that's what others report. You, and all the other reports I've seen have been running amd64, which I haven't been (I didn't build the box originally). I'll know tommorow if amd64 makes much of a difference or not. Oh, other info - I'm running the standard SMP kernel config with no modifications. Sam. -- Fortified with Essential Bitterness and Sarcasm Matt Groening, Binky's Guide to Love. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.5 to 6.1 upgrade
On Aug 22, 2006, at 2:56 PM, Todorov @ Paladin wrote: don't find this out the hard way :-( How to find which is dynamically using libs and which application is not? This is something I was wondering before... Thank you in advance. path of least resistance: upgrade everything. :-) sometimes it is easier to start from scratch with a CD or network install.
Re: 5.5 to 6.1 upgrade
Vivek Khera написа: On Aug 22, 2006, at 2:56 PM, Todorov @ Paladin wrote: don't find this out the hard way :-( How to find which is dynamically using libs and which application is not? This is something I was wondering before... Thank you in advance. path of least resistance: upgrade everything. :-) sometimes it is easier to start from scratch with a CD or network install. Something related to this topic - where are the options we choose for a specific port saved? Also - why portupgrade is not always aware of previously chosen options for a port build? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: bce0: Error mapping mbuf into TX chain!
Sam, I'm also running the stock RELEASE kernel config- haven't had a chance to do a rebuild yet. But, I just noticed something interesting- the box has been running fine for several days with multiple ssh connections, and several large remote data loads (by way of postgres copy on port 5432). However, I just installed webmin, set it up to run HTTPS on port 9090, and as soon as I tried to connect- got the error. It does that every subsequent time too. I will try the latest from 6-stable, but if you're thinking a big src download from ports is high network io, well, lets just say the datasets I'm copying around tend to dwarf the bsd source tree ;) (typically they're several gb per dataset). So if that's still a problem I may be jumping out of the proverbial frying pan and into the fire.. Thanks, Bucky -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sam Eaton Sent: Tuesday, August 22, 2006 3:29 PM To: [EMAIL PROTECTED] Subject: Re: bce0: Error mapping mbuf into TX chain! On Tue, Aug 22, 2006 at 02:46:04PM -0400, Bucky Jordan wrote: Sam, I've got a PowerEdge 2950 with a DRAC 5 card, and I'm having what appears to be the same set of issues. I'm running 6.1 amd64 RELEASE. I've only gotten the bce0: Error mapping mbuf into TX chain! error a few times now. Although the box isn't in production at the moment, we've been sending quite a bit of data (several GB) across the interface without a hitch (basically remote COPY statements for postgresql). It sounds like your 1950 is/was having the issue more frequently (our 2950 stays up for days at a time). The 'error mapping mbuf' error seems to have been fixed by the latest set of changes to if_bce.c - after upgrading to the latest stable, that problem stopped happening. However, instead of that, under rather higher load, we now get the watchdog timer error instead. This is not good :) I can get it within minutes with something like building something big from ports, during the initial source download. However, the fact that I do get the error every now and then is still a concern, so I plan to rebuild world and kernel when I get the chance. Please keep us posted on your findings, and if it'd be useful to have another box to run tests on, I'd be happy to give it a go. I think moving to stable will fix the mbuf error for you, as that's what others report. You, and all the other reports I've seen have been running amd64, which I haven't been (I didn't build the box originally). I'll know tommorow if amd64 makes much of a difference or not. Oh, other info - I'm running the standard SMP kernel config with no modifications. Sam. -- Fortified with Essential Bitterness and Sarcasm Matt Groening, Binky's Guide to Love. ___ 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: 5.5 to 6.1 upgrade
Date: Tue, 22 Aug 2006 23:07:45 +0300 From: Todorov @ Paladin [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Vivek Khera напиÑа: On Aug 22, 2006, at 2:56 PM, Todorov @ Paladin wrote: don't find this out the hard way :-( How to find which is dynamically using libs and which application is not? This is something I was wondering before... Thank you in advance. path of least resistance: upgrade everything. :-) sometimes it is easier to start from scratch with a CD or network install. Something related to this topic - where are the options we choose for a specific port saved? Also - why portupgrade is not always aware of previously chosen options for a port build? This is rather new and not as well publicized as it might have been. As ports are updated, configuration options are stored in /var/ports/PORTNAME/options. If you want to flush this for a port, 'make rmconfig' will do the job. You will be asked for options the next time you make the port, or you can 'make config' on a port to have it ask again. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD boots too fast on Dell PE850
On Aug 19 at 11:50, Paul Koch wrote: The second problem we found was, various NICs would report that they were active after doing auto negotiation, but no rx packets were being passed into to the OS. Not sure if it was a hardware or driver issue, but we discovered that by forcing a packet out the NIC via the bpf interface, it would immediately start doing stuff. It was if the auto negotiation had not really completed fully until a packet was transmitted. This only occurred on certain types of NICs, the newer ones. This was a problem for us because we build something called a remote network appliance (RNA) which is basically FreeBSD on a floppy and runs a statistical lan analyser. The RNA might have many NICs in it, one with an IP, the others just connected to network segments in promiscuous mode. Our apps couldn't monitor any traffic because no packets had be sent out the interfaces. So, early in the boot process we force out a couple of Loopback packets and everything works just fine. Not sure if the second issue would be a problem for normal installations though. I have a feeling this is related to windows; I recently watched a windows server boot with ethereal and it did an arp x.x.x.x is-at a:b:c:d:e:f (or 2 or 3) first thing (it had a static IP)...so of course a nic vendor would never realize there's a problem since they only test with windows*sigh*. Not sure how DHCP would play into that. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Newbie here
Hi all, First let me say I'm a newbie (basicly)- I didn't know wich one of the freebsd mailing lists was better to ask questions on that may(or may not) be better someplace else. Anyway Just playing with freebsd 6 on a testing box. Upgraded l from 6.0 to 6.1 because it looked like popular opinion is that it's got a number of improvements after a few false starts and finally figuring what I did wrong it went basicly ok. Only now when I went to use sysinstall to install a few usefull looking items I run into 6.1.-p3 not found on server! What's kind of puzling is if I do essentially the samething and run pkg_add --f from the command line many times it works. Is this normal? or did I do something wrong, and how do I fix it in either case? -thanks - Get your own web address for just $1.99/1st yr. We'll help. Yahoo! Small Business. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: The need for initialising disks before use?
Antony Mawer wrote: Is it recommended/required to do something like: dd if=/dev/zero of=/dev/ad0 bs=1m before use to ensure the drive's sector remappings are all in place, before then doing a newfs? It seems logical to read the whole device first with conv=noerror to be sure the drive has encountered and noted any correctable or uncorrectable errors present. Only then write the entire drive, allowing it to remap any noted bad sectors. i.e.: # dd if=/dev/ad0 of=/dev/null bs=64k conv=noerror # dd if=/dev/zero of=/dev/ad0 bs=64k The problem is that when dd hits the first bad sector, the whole 64k block containing the sector will be skipped. There could be more bad sectors there... or none... If you hit errors I would re-read the affected area with bs=512 to get down to sector granularity. I seem to recall a utility posted to a freebsd mailing list some time ago that worked like dd(1), but would divide and conquer a block that returned with a read error. Intent being to get the job done fast with large blocks but still copy every sector possible off a failing drive by reducing to sector-sized blocks if necessary Unfortunately I can't find it now. Joe Koberg joe at osoft dot us ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Newbie here
E. Gad wrote: Hi all, First let me say I'm a newbie (basicly)- Welcome! I didn't know wich one of the freebsd mailing lists was better to ask questions on that may(or may not) be better someplace else. It's always best to start on freebsd-questions@, and if your question belongs elsewhere, the people that read that list are generally pretty good about directing you. good luck, Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
