Re: ``make buildkernel'' fails when /usr/obj is empty
On May 31 22:50, Konstantin Belousov wrote: On Thu, May 31, 2018 at 08:19:20PM +0200, Dimitry Andric wrote: On 31 May 2018, at 20:11, Warner Losh wrote: > > On Thu, May 31, 2018 at 11:47 AM, Dimitry Andric wrote: > On 31 May 2018, at 18:04, Benjamin Kaduk wrote: > > On Thu, May 31, 2018 at 09:58:50AM +0200, Gary Jennejohn wrote: > >> On Thu, 31 May 2018 09:52:22 +0200 > >> Gary Jennejohn wrote: ... > > Whatever happened to the "run buildworld or kernel-toolchain before > > buildkernel" requirement? > > That is still a requirement, yes. Otherwise, you might have outdated > toolchain components are in your /usr/obj. > > Usually you can get away without doing that, and now that clang is the toolchain that's rebuilt (and that's not fast) people try to get away with it more and more... Actually clang doesn't get updated *that* often, but there is a minor snag that one of llvm's config files (lib/clang/include/llvm/Config/config.h) includes , so each time __FreeBSD_version is bumped, quite a lot of dependencies get triggered... The version is only used for two checks: #if __FreeBSD_version >= 152 /* Define to 1 if you have the `backtrace' function. */ #define HAVE_BACKTRACE TRUE and: /* Define to 1 if you have the `futimens' function. */ #if __FreeBSD_version >= 1100056 #define HAVE_FUTIMENS 1 #endif Maybe the first check could be dropped, assuming that backtrace() is always available, but I'm not sure about futimens(). Is there any supported version of FreeBSD left that does *not* have it? Or you can manually define the symbols as needed on each branch, eliminating the need for osreldate.h and reusable if some other configuration variable needs to be conditionally set. Are these the kind of things that could get done in current and stable? Currently llvm/clang is rebuilt on pretty much every buildworld cycle that I do because of this which makes using things like WITH_META_MODE pretty pointless. It would be great to get this kind of change in the trees. -- Matt ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Port compilation fails on HEAD. works on 9 and 10 STABLE
On Sep 24 21:52, Kurt Jaeger wrote: Hi! > > Try dropping the attached patch in net/mediatomb/files. I submitted it > > in March, in PR198436: > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198436 > > Eh, now with an actual patch. :) Thanks, helps to build it. Still fails on 9.3a, but I *have* to go to bed now. It's done. This seems to create a run time dependency on GCC. Should it not just be a build time dependency which allows you to uninstall GCC afterwards? -- Matt ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Port compilation fails on HEAD. works on 9 and 10 STABLE
On Sep 25 09:18, Kurt Jaeger wrote: Hi! >> > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198436 This seems to create a run time dependency on GCC. Should it not just be a build time dependency which allows you to uninstall GCC afterwards? Maybe, I have not looked into that. Can you suggest a patch ? Unfortunately not I'm afraid. I'm not familiar enough with the newer intricacies of the ports system these days. I'm just a little OCD about only having ports installed which are needed for runtime and I usually run pkg_clean after every port update run to remove unneeded things. GCC just popped out as being unneeded to run mediatomb. -- Matt ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Port compilation fails on HEAD. works on 9 and 10 STABLE
On Sep 25 01:00, Don Lewis wrote: On 25 Sep, Matt Smith wrote: On Sep 24 21:52, Kurt Jaeger wrote: Hi! > > Try dropping the attached patch in net/mediatomb/files. I submitted it > > in March, in PR198436: > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198436 > > Eh, now with an actual patch. :) Thanks, helps to build it. Still fails on 9.3a, but I *have* to go to bed now. It's done. This seems to create a run time dependency on GCC. Should it not just be a build time dependency which allows you to uninstall GCC afterwards? If the executable(s) link to any of the shared libraries bundled with the gcc port, then gcc needs to be a run time dependency. If you point ldd at one of the executables, what does it say? Good point. I remember now that some things like against libgcc provided with the GCC package. If this is the case then I apologise for the noise and feel free to ignore me! Unfortunately I don't currently have access to the box where I compiled it using GCC last night using the updated port. I only have access to another box where it was compiled using clang (on -STABLE). This shows the below. So I can see that it is linked against libgcc, although in this case the base system version. $ ldd `which mediatomb` /usr/local/bin/mediatomb: libthr.so.3 => /lib/libthr.so.3 (0x80094b000) librt.so.1 => /usr/lib/librt.so.1 (0x800b6f000) libsqlite3.so.0 => /usr/local/lib/libsqlite3.so.0 (0x800d75000) libmagic.so.4 => /usr/lib/libmagic.so.4 (0x801029000) libz.so.6 => /lib/libz.so.6 (0x801248000) libavformat.so.56 => /usr/local/lib/libavformat.so.56 (0x80145e000) libavutil.so.54 => /usr/local/lib/libavutil.so.54 (0x801821000) libffmpegthumbnailer.so.4 => /usr/local/lib/libffmpegthumbnailer.so.4 (0x801a86000) libexpat.so.1 => /usr/local/lib/libexpat.so.1 (0x801c9b000) libc++.so.1 => /usr/lib/libc++.so.1 (0x801ec1000) libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x80218) libm.so.5 => /lib/libm.so.5 (0x80239c000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x8025c5000) libc.so.7 => /lib/libc.so.7 (0x8027d3000) libavcodec.so.56 => /usr/local/lib/libavcodec.so.56 (0x802c0) libssl.so.8 => /usr/local/lib/libssl.so.8 (0x803f0e000) libcrypto.so.8 => /usr/local/lib/libcrypto.so.8 (0x80420) libbz2.so.4 => /usr/lib/libbz2.so.4 (0x804651000) libswscale.so.3 => /usr/local/lib/libswscale.so.3 (0x804863000) libpng16.so.16 => /usr/local/lib/libpng16.so.16 (0x804af5000) libjpeg.so.8 => /usr/local/lib/libjpeg.so.8 (0x804d27000) libswresample.so.1 => /usr/local/lib/libswresample.so.1 (0x804f8) libx264.so.144 => /usr/local/lib/libx264.so.144 (0x80519b000) libmp3lame.so.0 => /usr/local/lib/libmp3lame.so.0 (0x8054fd000) libfdk-aac.so.1 => /usr/local/lib/libfdk-aac.so.1 (0x805776000) liblzma.so.5 => /usr/lib/liblzma.so.5 (0x805a43000) -- Matt ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Fix for 5.2-BETA lockup problems
Andre Oppermann wrote: Hello all, I've found what probably is going wrong in tcp_hostcache. The problem is me cutting corners (what goes around comes around...) in tcp_hc_insert when the bucket limit is reached. I made the #if 0 too big and the bucket was not removed from the tailqueue when we hit the bucket limit. A couple of lines later it is inserted again as head element which leads to an infinite loop either when the next lookup on the same bucket row is done, or when the the tcp_hc_purge function is run to timeout the entries. Please try the attached patch which should fix it. This appears to have succesfully cured my lockup. I now have the original kernel config booted again with full inet6 etc and it's not locked up. Regards, Matt. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS lockup issues xl0 timeouts
Update on xl0 issues and NFS issues: I unfortunatly left my realtek network card in work so I'll do this tomorrow night instead of tonight. But I've now installed the absolute latest world/kernel on both server and client again to see if the hang has gone. I have noticed the NFS transfer hangs at the same point always. If I cp mysql-4.0.16.tar.gz to /usr/src it hangs instantly and always with this filesize: -rw-r--r--1 root wheel 122880 Nov 25 18:30 mysql-4.0.16.tar.gz Is that significant in any way? Another test I just did is swap the roles of the client and server around. So I've ran a server on the client and mounted the directory on the server. Doing this and NFS works perfectly writing to the server but not reading. It hangs whilst reading. Left for 5 minutes so far: -rw-r--r-- 1 root wheel 65536 Nov 25 18:39 mysql-4.0.16.tar.gz This filesize looks significant to me. Like a buffer is full or something. So this suggests I have a problem only in the one direction. And this is also the direction I have the xl0 transfer problems with. I would suggest my problems are totally down to the xl0 card/driver and not NFS related at all. I will find this out once and for all when I test with the realtek card tomorrow night (when I remember to bring it home from work). The affected card is: [EMAIL PROTECTED]:7:0: class=0x02 card=0x100010b7 chip=0x920010b7 rev=0x74 hdr=0x00 vendor = '3COM Corp, Networking Division' device = '3C905C-TX Fast EtherLink for PC Management NIC' class= network subclass = ethernet xl0: 3Com 3c905C-TX Fast Etherlink XL port 0x1000-0x107f mem 0xfc304800-0xfc30487f irq 10 at device 7.0 on pci5 xl0: Ethernet address: 00:04:76:8d:c5:fd miibus0: MII bus on xl0 xlphy0: 3c905C 10/100 internal PHY on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Regards, Matt. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA lockup
Robert Watson wrote: Any chance you could hook up a serial console, set BREAK_TO_DEBUGGER in kernel options, and see if a serial break drops you to DDB over serial? Under some circumstances a serial break can be more effective getting into the debugger than a console break. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories I have tried this and the serial port looks hung as well. I can't get any response at all. A kernel from the 16th works fine though (and drops me into DDB via serial so this works fine). As were in a code freeze there have not been that many commits in the last week so not much could have changed I guess between 16th and now. I am planning to try two things: 1) Try the latest kernel after sam's commits to various tcp/divert code. I run ipfw2 and ipdivert/natd so you never know :) 2) NFS is still not working and I can't backtrack to previous kernels to find the date it broke due to statfs. As I believe it's still only me and soren who are affected by the looks of it and nobody else I assume there is something very very specifically wrong with my system. Maybe an old library left around and something not recompiled properly against a new one etc. I have no idea. Basically though when the final 5.2-RELEASE is actually available I plan on reinstalling both my desktop and server machines from scratch with a full format and then cvsup to HEAD again to get rid of any cruft left around from my exploits with 5.0-RELEASE all the way through to present. I need to recompile all my ports at some point anyway really so I may as well just install them from scratch I figure. It's possible this might fix NFS. Though I've noticed the NFS thing has become added to the showstopper list for 5.2 so I might have to try this with a JPSNAP instead I guess. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: xl0: watchdog timeout
Matt Smith wrote: Matt Smith wrote: Jimmy Selgen wrote: On Fri, 2003-11-21 at 21:29, Kris Kennaway wrote: On Fri, Nov 21, 2003 at 09:22:49PM +0100, Jimmy Selgen wrote: I saw this with some of sam's locking changes that (temporarily) broke DUMMYNET. I see you're using ipfilter - it's possible that this configuration has not been well-tested. Are you passing much traffic through ipfilter on this box? The box in question is my workstation, so I guess i'm not passing that much traffic through ipfilter. Also, when I said that the NIC still worked, I might have mislead you a bit. I had about 5-10 timeouts while scp'ing the dmesg output to my other workstation. Data seems to move from userland to the kernel, then get stuck in buffers there for 10-15 seconds, generating timeouts, before they're shipped off. I assume this is expected behaviour when a NIC isnt behaving correctly. It would be helpful if you can do a binary search to narrow down when the problem started. What would you have me search ? I'm a faily seasoned C programmer (12 years experience, some of them doing RTOS kernel work), but dont know much about FreeBSD kernel development, or the process of checking out different kernel revisions. I've tried a build without IPFILTER, and the problem still exists. I've also tried booting with ACPI disabled, and the problem is still there. I have attached a copy of my kernel config file, in case i'm doing something wrong. snip kernel file I have just noticed that my xl0 card is misbehaving as well. I have a 3c905c in my desktop and noticed that an ftp of a file from another machine on the lan (100 meg switched) was only going at around 70KB/sec. Normally I get around 9MB/sec. A netstat -bi xl0 shows lots of errors: NameMtu Network Address Ipkts Ierrs Ibytes Opkts Oerrs Obytes Coll xl01500 Link#1 00:04:76:8d:c5:fd 3081878 217616 3778632119 2451968 6 368229701 0 I also have this in my messages file: xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 180 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 240 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 300 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 360 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 420 bytes I do not currently have any debugging options compiled into this kernel. FreeBSD fraggle.xtaz.co.uk 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Tue Nov 18 20:05:52 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/FRAGGLE i386 I am actually in the process of building a new world/kernel to update it again as I thought it might be something that's fixed. I unfortunatly can not boot the old kernel to see if it works fine in that because of the statfs changes so it *could* possibly be the NIC has gone funny. I also have a 3c905a and a 3c905b in my router machine and this is showing no issues at all with the same dated kernel. http://xtaz.net/ Matt. I am now running a 5.2-BETA kernel from today and still have the problem with my xl0 card here. I can only get a max throughput of around 110KB/sec through it. And I am getting huge amounts of errors in the interface stats (5 minutes after booting): NameMtu Network Address Ipkts Ierrs Ibytes Opkts Oerrs Obytes Coll xl01500 Link#1 00:04:76:8d:c5:fd 217042 1290 57669634 309460 0 208178476 0 So the question is, is this my network card has died and I need to throw it out or is it related to Jimmy Selgen's email about the watchdog timeouts? It's a shame I can't boot an old kernel to test really. Matt. I have done some testing on this. I've changed the network cable, switch port etc. No affect. I've found though that if I ftp this box and GET a file it goes at around 6MB/sec. But if I PUT a file it goes at 100KB/sec. Previously this has worked at around 9-10MB/sec both ways. I can't place a date on it though because I've not tried to do large file transfers for a long time and only just noticed it this week. So it looks like it is driver related I guess. The buffer scenario Jimmy reported looks likely. Matt. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS lockup issues and xl0 watchdog timeout
I've had a possible idea regarding the NFS issues. I'm wondering if perhaps my NFS issues are related to the other email thread I have going which is the xl0: watchdog timeouts etc. I had not noticed this until last week because it's not often I copy large files from one machine to another but doing an ftp/scp etc from one machine to the other I'm only getting 100KB/sec with a PUT from my nfsclient-nfsserver, and 6MB/sec with a GET. This used to go at 9-10MB/sec both ways. Thinking about it I think this started happening around the same time I started having NFS issues. My NFS issues are also only when writing to the server from the client, never the other way around. So this ties up with the throughput figure difference I get on FTP. Jimmy mentioned a watchdog timeout caused by what looked like a 10-15 second delay in a buffer going from userland to kernel? I guess if this is the case it could kill NFS as well. Tomorrow night I will change my xl0 card in this desktop for a spare realtek card I happen to have and test throughput and NFS. I'll let you know my results. It would be interesting to see if the other person who reported these NFS issues (soren) has a similar experience. Matt. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
5.2-BETA lockup
Hi, Since updating two of my machines to the latest HEAD I am experiencing a total lockup on one of them. After being booted for approx 3 minutes the machine stops responding completely. It doesn't panic or drop into DDB. The numlock key doesn't toggle the keyboard light, and I can't drop it into DDB manually. I have full debugging options compiled in to this kernel as per the usual -CURRENT GENERIC file. It's currently booted with the older kernel from the 16th and this is stable as a rock. Anything else I can do to find the problem out or workaround it considering it just hangs? The machine is a router running two 3com network cards (xl) and IPFW/natd. It also has IPV6 with IP6FW, and a gif tunnel. Matt. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: xl0: watchdog timeout
Matt Smith wrote: Jimmy Selgen wrote: On Fri, 2003-11-21 at 21:29, Kris Kennaway wrote: On Fri, Nov 21, 2003 at 09:22:49PM +0100, Jimmy Selgen wrote: I saw this with some of sam's locking changes that (temporarily) broke DUMMYNET. I see you're using ipfilter - it's possible that this configuration has not been well-tested. Are you passing much traffic through ipfilter on this box? The box in question is my workstation, so I guess i'm not passing that much traffic through ipfilter. Also, when I said that the NIC still worked, I might have mislead you a bit. I had about 5-10 timeouts while scp'ing the dmesg output to my other workstation. Data seems to move from userland to the kernel, then get stuck in buffers there for 10-15 seconds, generating timeouts, before they're shipped off. I assume this is expected behaviour when a NIC isnt behaving correctly. It would be helpful if you can do a binary search to narrow down when the problem started. What would you have me search ? I'm a faily seasoned C programmer (12 years experience, some of them doing RTOS kernel work), but dont know much about FreeBSD kernel development, or the process of checking out different kernel revisions. I've tried a build without IPFILTER, and the problem still exists. I've also tried booting with ACPI disabled, and the problem is still there. I have attached a copy of my kernel config file, in case i'm doing something wrong. snip kernel file I have just noticed that my xl0 card is misbehaving as well. I have a 3c905c in my desktop and noticed that an ftp of a file from another machine on the lan (100 meg switched) was only going at around 70KB/sec. Normally I get around 9MB/sec. A netstat -bi xl0 shows lots of errors: NameMtu Network Address Ipkts Ierrs Ibytes Opkts Oerrs Obytes Coll xl01500 Link#1 00:04:76:8d:c5:fd 3081878 217616 3778632119 2451968 6 368229701 0 I also have this in my messages file: xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 180 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 240 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 300 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 360 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 420 bytes I do not currently have any debugging options compiled into this kernel. FreeBSD fraggle.xtaz.co.uk 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Tue Nov 18 20:05:52 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/FRAGGLE i386 I am actually in the process of building a new world/kernel to update it again as I thought it might be something that's fixed. I unfortunatly can not boot the old kernel to see if it works fine in that because of the statfs changes so it *could* possibly be the NIC has gone funny. I also have a 3c905a and a 3c905b in my router machine and this is showing no issues at all with the same dated kernel. Matt. I am now running a 5.2-BETA kernel from today and still have the problem with my xl0 card here. I can only get a max throughput of around 110KB/sec through it. And I am getting huge amounts of errors in the interface stats (5 minutes after booting): NameMtu Network Address Ipkts Ierrs Ibytes Opkts Oerrs Obytes Coll xl01500 Link#1 00:04:76:8d:c5:fd 217042 1290 57669634 309460 0 208178476 0 So the question is, is this my network card has died and I need to throw it out or is it related to Jimmy Selgen's email about the watchdog timeouts? It's a shame I can't boot an old kernel to test really. Matt. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
What's changed relating to localhost then?
I've just updated to 5.2-BETA today and have noticed that my spamd is now rejecting all connections from spamc because they are not coming from 127.0.0.1 any more. It's now using my public IP address of 82.x.x.x: Nov 22 14:38:30 womble spamd[657]: unauthorized connection from 82-32-25-111.cable.ubr04.azte.blueyonder.co.uk [82.32.25.111] at port 49167 I noticed somebody reported a similar thing earlier. I'm actually in the process of reverting to a -current of 2003.11.14.00.00.00 because my xl0 ethernet card is acting up as mentioned in another thread so I want to see if it works with that kernel. (Can't go further back due to statfs). Also one of my machines running 5.2-BETA just hung dead within 5 minutes of booting. I don't have DDB etc configured though so can't tell why. Matt. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: xl0: watchdog timeout
Jimmy Selgen wrote: On Fri, 2003-11-21 at 21:29, Kris Kennaway wrote: On Fri, Nov 21, 2003 at 09:22:49PM +0100, Jimmy Selgen wrote: I saw this with some of sam's locking changes that (temporarily) broke DUMMYNET. I see you're using ipfilter - it's possible that this configuration has not been well-tested. Are you passing much traffic through ipfilter on this box? The box in question is my workstation, so I guess i'm not passing that much traffic through ipfilter. Also, when I said that the NIC still worked, I might have mislead you a bit. I had about 5-10 timeouts while scp'ing the dmesg output to my other workstation. Data seems to move from userland to the kernel, then get stuck in buffers there for 10-15 seconds, generating timeouts, before they're shipped off. I assume this is expected behaviour when a NIC isnt behaving correctly. It would be helpful if you can do a binary search to narrow down when the problem started. What would you have me search ? I'm a faily seasoned C programmer (12 years experience, some of them doing RTOS kernel work), but dont know much about FreeBSD kernel development, or the process of checking out different kernel revisions. I've tried a build without IPFILTER, and the problem still exists. I've also tried booting with ACPI disabled, and the problem is still there. I have attached a copy of my kernel config file, in case i'm doing something wrong. snip kernel file I have just noticed that my xl0 card is misbehaving as well. I have a 3c905c in my desktop and noticed that an ftp of a file from another machine on the lan (100 meg switched) was only going at around 70KB/sec. Normally I get around 9MB/sec. A netstat -bi xl0 shows lots of errors: NameMtu Network Address Ipkts Ierrs Ibytes Opkts Oerrs Obytes Coll xl01500 Link#1 00:04:76:8d:c5:fd 3081878 217616 3778632119 2451968 6 368229701 0 I also have this in my messages file: xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 180 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 240 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 300 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 360 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 420 bytes I do not currently have any debugging options compiled into this kernel. FreeBSD fraggle.xtaz.co.uk 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Tue Nov 18 20:05:52 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/FRAGGLE i386 I am actually in the process of building a new world/kernel to update it again as I thought it might be something that's fixed. I unfortunatly can not boot the old kernel to see if it works fine in that because of the statfs changes so it *could* possibly be the NIC has gone funny. I also have a 3c905a and a 3c905b in my router machine and this is showing no issues at all with the same dated kernel. Matt. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS-UP new statfs structure
Marco Wertejuk wrote: Just for a short note: cfsd (ports/security/cfs) should be recompiled as well after those statfs changes. And mail/postfix and devel/gnomevfs2 (ones's i've found so far) postfix did this every time it received a mail until I recompiled it: pid 4049 (smtpd), uid 1003: exited on signal 11 And gnomevfs was something I saw in another headsup. There are bound to be others, I'm just keeping an eye on my /var/log/messages to see if anything else sig 11 or 12's! So far so good though. Matt. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS-UP new statfs structure
Bruce Cran wrote: On Fri, Nov 14, 2003 at 08:33:06AM +, Matt Smith wrote: Marco Wertejuk wrote: Just for a short note: cfsd (ports/security/cfs) should be recompiled as well after those statfs changes. And mail/postfix and devel/gnomevfs2 (ones's i've found so far) postfix did this every time it received a mail until I recompiled it: pid 4049 (smtpd), uid 1003: exited on signal 11 And gnomevfs was something I saw in another headsup. There are bound to be others, I'm just keeping an eye on my /var/log/messages to see if anything else sig 11 or 12's! So far so good though. Either the new statfs, or something in a recent change in -CURRENT (since last week), has broken the nvidia driver. I've been using it now for over half a year with no problems at all. I installed the new kernel and world, rebuilt x11/nvidia-driver and X11 hung before it had even switched to graphical mode. After a minute the system rebooted, and unfortunately a couple of lost+found directories were populated by fsck - I must remember to turn off the ata write cache next time! I've now rebuilt *all* of the ports in the hope that it would solve it, but it still crashes. -- Bruce Cran I am using the nvidia driver fine with the latest current: nvidia0: GeForce4 MX 420 mem 0xfc20-0xfc27,0xf800-0xfbff,0xfd00-0xfdff irq 5 at device 0.0 on pci1 FreeBSD fraggle.xtaz.co.uk 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Thu Nov 13 18:34:54 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/FRAGGLE i386 The only thing I've found a problem with so far is postfix as I've mentioned. Matt. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Still getting NFS client locking up
With a current build from november the 9th I am still getting exactly the same NFS lockups. I assume soren is as well. NFS has basically been pretty unusable now for over a month. As only a couple of people have complained about this from what I can see I assume it is something related to something specific such as a network card? From my testing I only get this lockup when writing to the server. Reading from the server works perfectly all the time. So luckily I can still manage an NFS mounted installworld/kernel. I just got the lockup again now whilst it downloaded p5-Net-DNS to portupgrade into /usr/ports/distfiles. This is a very small file but it was enough to trigger it off. So it doesn't look like a size related issue either as I can download around 4% of mysql before it locks up. Obviously we should really try and find the cause of this before 5.2. I am willing to try any patches/debug on my systems. But I just have zero clue about what to look for myself. As a start here is the relevent parts of my dmesg to show the NIC's I'm using. I wonder if this corresponds to sorens? NFS CLIENT (xl1 would be the card it's using to talk to the server): xl0: 3Com 3c905B-TX Fast Etherlink XL port 0xe400-0xe47f mem 0xea00-0xea7f irq 12 at device 15.0 on pci0 xl0: Ethernet address: 00:a0:24:ac:e1:b4 miibus0: MII bus on xl0 xlphy0: 3Com internal media interface on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl1: 3Com 3c905-TX Fast Etherlink XL port 0xe800-0xe83f irq 11 at device 17.0 on pci0 xl1: Ethernet address: 00:60:08:6d:1e:3b miibus1: MII bus on xl1 nsphy0: DP83840 10/100 media interface on miibus1 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto NFS SERVER: xl0: 3Com 3c905C-TX Fast Etherlink XL port 0x1000-0x107f mem 0xfc304800-0xfc30487f irq 10 at device 7.0 on pci5 xl0: Ethernet address: 00:04:76:8d:c5:fd miibus0: MII bus on xl0 xlphy0: 3c905C 10/100 internal PHY on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Both connected to a 100meg full duplex switch. Any ideas? As I have said I'm happy to enable some major debugging etc. But I just need somebody to give me a step by step guide for what to do and look for. In case this thread is too old now and nobody remembers anything about it the previous email regarding it is at http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1183410+0+archive/2003/freebsd-current/20031102.freebsd-current Regards, Matt. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Still getting NFS client locking up
Robert Watson wrote: I'm fairly baffled. I tried for many hours to reproduce the problem in two seperate sets of systems here, and completely failed. I left buildworlds, cvs updates, blah blah blah, running for 96 hours across pools of clients and servers and no hint of the problem. I also use NFS daily on my primary workstation at work, as well as in my normal development setup with diskless crashboxes. So indeed, there must be some very specific piece of the picture that I'm not reproducing, such as a specific network card, or there's a race condition that requires very specific timing, etc. How fast are your systems, speaking of which? I live in the world of 300-500 mhz machines at work, and 300-800 mhz boxes at home. If you're using multi-ghz boxes, that could well be the distinguishing factor between our configurations... snip client is an intel pentium II 300mhz with 256meg ram and 1gig of swap. server is an athlon XP 2200 with 512meg ram and 1gig of swap. I can certainly spend some time trying to get some proper debug based on what you have said in your email. I shall look into setting up a serial console etc. In the meantime another piece of information which might be helpful is this. Looking at the wtmp to see when I rebuilt my world/kernel I can see this: reboot ~ Tue Oct 21 20:44 reboot ~ Wed Oct 15 19:36 (These times are in BST which is +5 hours from east coast US). On the Oct 15th kernel NFS was working perfectly (and before that). From the Oct 21st kernel it has always locked up in this way. So something between those two dates was commited which broke this for us. Another way of me debugging this I guess is to backtrack my world to each date in between systematically and find the exact date it breaks and look at the commits. Matt. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Still gettnig NFS client locking up
Robert Watson wrote: On Tue, 28 Oct 2003, Soren Schmidt wrote: I'm now running a kernel/world of October 26th on both NFS client and server machines. I am still seeing NFS lockups as reported by several people in these threads: Me too!! Hmm. I'm unable to reproduce this so far, and I'm pounding several 5.x NFS clients and servers. I've been checking out using CVS over NFS, performing dd's of big files, etc. There must be something more I'm missing in reproducing this. What network interface cards are you using (client, server)? Are you using DHCP on the client or server? What commands trigger it -- what part of the NFS namespace, etc? Are you running the commands as root, or another user? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories I have 3com cards in both machines. 3c905c's I believe. The xl driver. The client has a static IP address configured from rc.conf and the server uses dhclient to get a hardwired static address based on MAC. I'm running the commands as root. I have noticed that it generally locks up when writing to the mount rather than reading as I can do an installworld from the NFS server to the client without issues (i think!, I've only tried this once). But downloading files into the mount breaks very quickly. I guess it could be a filesize thing though. I shall have to do some more testing. I was planning on cvsuping and buildworlding on saturday again. It started happening approx two weeks ago I think? Roughly when I first reported it, but NFS had always been solid as a rock before then. I can easily reproduce this by doing this: [EMAIL PROTECTED] root]# cd /usr/ports/databases/mysql40-server [EMAIL PROTECTED] mysql40-server]# make fetch mysql-4.0.16.tar.gz doesn't seem to exist in /usr/ports/distfiles/. Attempting to fetch from ftp://planetmirror.com/pub/mysql/Downloads/MySQL-4.0/. Receiving mysql-4.0.16.tar.gz (12830094 bytes): 3% (has now locked up) [EMAIL PROTECTED] root]# ls /usr/src COPYRIGHT READMEcontrib gnu libexec secureusr.bin MAINTAINERS UPDATING cryptoinclude release share usr.sbin Makefile bash.core etc kerberos5 rescuesys Makefile.inc1 bin games lib sbin tools [EMAIL PROTECTED] root]# ls /usr/ports (has also locked up) [EMAIL PROTECTED] matt]$ ps wauxl | grep fetch root70213 0.0 0.3 816 660 p3 S+8:47AM 0:00.39 make fetch 0 63855 0 8 0 wait root70284 0.0 0.5 2604 1212 p3 S+8:47AM 0:00.14 /usr/bin/fetch - 0 70259 0 -8 0 nfsaio [EMAIL PROTECTED] matt]$ ps wauxl | grep ls root70307 0.0 0.2 772 480 p6 D+8:48AM 0:00.01 ls /usr/ports0 70302 0 -1 0 nfsrcv [EMAIL PROTECTED] matt]$ uname -a FreeBSD womble.xtaz.co.uk 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Sun Oct 26 21:14:58 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/WOMBLE i386 [EMAIL PROTECTED] matt]$ cat /etc/fstab | grep nfs 10.0.0.2:/usr/src /usr/srcnfs rw,soft,intr0 0 10.0.0.2:/usr/obj /usr/objnfs rw,soft,intr0 0 10.0.0.2:/usr/ports /usr/ports nfs rw,soft,intr0 0 rc.conf on the client contains: ifconfig_xl1=inet 10.0.0.1 netmask 255.255.255.0 nfs_client_enable=YES rc.conf on the server contains: ifconfig_xl0=DHCP rpcbind_enable=YES nfs_server_enable=YES mountd_enable=YES And this is the uname of the server: [EMAIL PROTECTED] src]# uname -a FreeBSD fraggle.xtaz.co.uk 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Sun Oct 26 21:05:49 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/FRAGGLE i386 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /etc/bluetooth and /usr/share/examples/netgraph/bluetooth(breaks installworld)
Maksim, I have just done a buildworld and installworld after the latest bluetooth commits and installworld borks on: install -o root -g wheel -m 444 /usr/src/share/examples/meteor/yuvpk.c /usr/share/examples/meteor/yuvpk.c install -o root -g wheel -m 444 /usr/src/share/examples/meteor/yuvpl.c /usr/share/examples/meteor/yuvpl.c install -o root -g wheel -m 444 /usr/src/share/examples/netgraph/bluetooth/rc.bluetooth /usr/share/examples/netgraph/bluetooth/rc.bluetooth install: /usr/share/examples/netgraph/bluetooth/rc.bluetooth: No such file or directory *** Error code 71 Stop in /usr/src/share/examples. I have all four files you commited in the last few hours so it looks b0rk3d :) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /etc/bluetooth and/usr/share/examples/netgraph/bluetooth(breaks installworld)
Matt Smith wrote: Maksim, I have just done a buildworld and installworld after the latest bluetooth commits and installworld borks on: install -o root -g wheel -m 444 /usr/src/share/examples/meteor/yuvpk.c /usr/share/examples/meteor/yuvpk.c install -o root -g wheel -m 444 /usr/src/share/examples/meteor/yuvpl.c /usr/share/examples/meteor/yuvpl.c install -o root -g wheel -m 444 /usr/src/share/examples/netgraph/bluetooth/rc.bluetooth /usr/share/examples/netgraph/bluetooth/rc.bluetooth install: /usr/share/examples/netgraph/bluetooth/rc.bluetooth: No such file or directory *** Error code 71 Stop in /usr/src/share/examples. I have all four files you commited in the last few hours so it looks b0rk3d :) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] Doh! I forgot to say it's obviously only because the /usr/share/examples/bluetooth directory does not exist and needs making. The installworld works fine if you make this manually, but it should be part of the installworld process. Matt. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NTLDR missing after 5-RELEASE install
What does your Drive Layout look like? Is your W2k partition FAT32? Has it always been the first partition on the drive, or did you move it, using something like partition magic? Is freeBSD in the extended partition? -Matt On Tue, 2003-02-25 at 11:58, Andrew Boothman wrote: Quoting Lucas Holt [EMAIL PROTECTED]: It probably is. You need to put in the win 2k CD and do a repair on your windows install.. unfortunetely this may screw up your freebsd install. On Tuesday, February 25, 2003, at 05:58 AM, Andrew Boothman wrote: Hi! I've just installed 5-RELEASE, and I asked for the FreeBSD Boot Manager to be installed on both my HDDs. When the machine boots I'm given options for : F1 - DOS F5 - Drive 2 Hitting F5 takes me to a second menu, where I can boot FreeBSD no problem. My problem is that Win2k will no longer boot Hitting F1 displays a message that, NTLDR is missing. I've tried all the repair options on the Win2k setup disc to no avail I think. I'm sorry this isn't directly FreeBSD related, but I really hope my Win2k installation isn't hosed. Thanks for replying! I can't understand how the 5.x boot manager has managed to break my windows boot, i've never had any trouble under 3.x or 4.x, both of which played with windows perfectly nicely. I think i've tried all of the various repair options on the Win2k CD, including getting it to do a fresh installation into a different folder (c:\tempwin), but even that failed with the NTLDR missing message! However you no longer get the booteasy (F1 F2) menu anymore, so Windows must have rewritten something. It still doesn't explain why Win2k still won't boot. I'm running out of ideas and I *really* don't want to have to reformat my windows drive! Other than this (fairly major) problem, my 5.0 installation went really well, even ACPI seems to be working perfectly and I even found a KLD to support my on- board sound card! :) I really want to get windows booting again so I can continue to play with 5.0 without worrying... Any help is much appricated! Thanks! Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message -- Matt Smith [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
