Re: panic "Sleeping thread owns a non-sleepable lock" via cv_timedwait_signal, was "rsync over NFS"
On 10/05/2012 05:40 AM, Konstantin Belousov wrote: > This is the whole difference between stable and HEAD nullfs. > Retest the HEAD then. Can't reproduce it with HEAD (FreeBSD freebsd-tower.goebo.site 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r241218: Fri Oct 5 08:26:17 CEST 2012 l...@freebsd-tower.goebo.site:/usr/obj/usr/src-head/sys/GENERIC-HEAD i386) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: panic "Sleeping thread owns a non-sleepable lock" via cv_timedwait_signal, was "rsync over NFS"
Nop, the patch doesn't seem to work - the machine crashes again. :| Norbert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: panic "Sleeping thread owns a non-sleepable lock" via cv_timedwait_signal, was "rsync over NFS"
On 10/04/2012 01:53 PM, Rick Macklem wrote: > Looks like you missed the change to fs/nfs/nfs_var.h, which changes > the prototypes for nfsv4_strtouid() and nfsv4_strtogid(). I see the problem, but I don't really understand why it failed. I applied the whole patch... However, 9.1-PRERELEASE is compiling at the moment without the numeric-patch and we'll see. > Btw, the numeric uid/gid patch is now in head and I plan on MFC'ing it > to stable/9 to-day [...] That's fine :) --norbert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: panic "Sleeping thread owns a non-sleepable lock" via cv_timedwait_signal, was "rsync over NFS"
On 10/04/2012 12:45 PM, Konstantin Belousov wrote: > But the errors has nothing to do with my nullfs backport. You're right; they stem from Rick's patch (from line 207 in numeric-uidgid.patch on): -nd->nd_repstat = nfsv4_strtogid(cp,j,&gid,p); +nd->nd_repstat = nfsv4_strtogid(nd, cp, j, &gid, + p); I reverted the patch and see what's going to happen... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: panic "Sleeping thread owns a non-sleepable lock" via cv_timedwait_signal, was "rsync over NFS"
Does not compile: http://nopaste.info/2bc2c189eb.html (I also #define-d a constant, but that works) --Norbert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: panic "Sleeping thread owns a non-sleepable lock" via cv_timedwait_signal, was "rsync over NFS"
Hehe, sure, if you assist me :) I'm not very experienced with SVN, I'm actually a git user and I think it's also better if I do /not/ express my opinion on SVN here ;) The only actions I'm currently able to do in SVN are checkout, update, commit and view log and status -- so any help is appreciated :P --Norbert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: panic "Sleeping thread owns a non-sleepable lock" via cv_timedwait_signal, was "rsync over NFS"
On 10/04/2012 08:41 AM, Norbert Aschendorff wrote: > I just applied the numeric-uidgid patch to CURRENT (worked so far) and > compile the kernel with the patch and try it another time, just to > eliminate the possibility of a bug in this patch (the machine never > crashed before using this patch, but I'm not sure if I tested this > consciously before having applied the patch) Sorry, does not compile. But we nevertheless know that it should be fixed in 10.0. --Norbert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: panic "Sleeping thread owns a non-sleepable lock" via cv_timedwait_signal, was "rsync over NFS"
I exported the NFSv4 shares via nullfs, booted the 10.0-CURRENT kernel and the machine does not crash. Running 9.1-PRERELEASE, it still crashes (as it should ;). I just applied the numeric-uidgid patch to CURRENT (worked so far) and compile the kernel with the patch and try it another time, just to eliminate the possibility of a bug in this patch (the machine never crashed before using this patch, but I'm not sure if I tested this consciously before having applied the patch) --Norbert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: panic "Sleeping thread owns a non-sleepable lock" via cv_timedwait_signal, was "rsync over NFS"
On 10/03/2012 07:39 PM, Konstantin Belousov wrote: > Can you try HEAD kernel ? Theoretically, yes. But it's a network machine, so... if something goes wrong, it'd be rather bad :| And I'm afraid of HEAD ;) I'll try it nevertheless... Fortunately, I even have Screen&Keyboard at the machine (if something goes /really/ wrong). --Norbert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: panic "Sleeping thread owns a non-sleepable lock" via cv_timedwait_signal, was "rsync over NFS"
On 10/03/2012 05:54 PM, Konstantin Belousov wrote:
> So do you use nullfs exported mounts ? And stable ?
> Can you try to remove nullfs from the set up ?
Yes, I am using nullfs for the exports (mounting the exported
directories to subdirectories of /srv). In the FreeBSD man pages and the
documentation, the V4 export line in /etc/exports is often set to /, but
as I come from Linux where /etc/exports looks completely different, I
just followed my habits.
As I wrote this, I executed the critical operation. It's finished and
the FreeBSD server still runs *yay* :) So it's quite likely that the
problem stems from the nullfs mount.
I just remember an issue I already wanted to tell: Before the server
crashed, the nfsd process ('nfsd: server') used 100% CPU (one core), but
without progress on client side. Usually, the nfsd uses only up to 10%
cpu time when rsyncing (values taken from htop - 100% = one used CPU).
...aaand I just run it once more, and it worked again :)
--Norbert
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: panic "Sleeping thread owns a non-sleepable lock" via cv_timedwait_signal, was "rsync over NFS"
Another logs - even with a /var/crash crash report :) Please note: The /var/crash files stem from another crash than the big syslog does! The syslog file inside the tarball is about 4.7 MB; it contains everything since the start of the crash. New /var/crash files: http://lbo.spheniscida.de/Files/nfs-rsync-crash-witnessII.tgz New syslog file: http://lbo.spheniscida.de/Files/nfs-rsync-crash-witnessIII-only-messages.tgz (Both < 100 KB) The used kernel is called GENERIC-OWN-WITNESS and has all three WITNESS options enabled and nothing else. But I just get an idea: Should I try it without Rick's NFSv4 numeric-uid-gid patch? Or is that completely unrelated? @Rick: Can you assure that it is impossible that the patch added this bug? --norbert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: panic "Sleeping thread owns a non-sleepable lock" via cv_timedwait_signal, was "rsync over NFS"
On 10/03/2012 09:21 AM, Norbert Aschendorff wrote: > So I just have to compile a kernel including "option WITNESS_WARN" and Well, obviously doesn't work, so only WITNESS_SKIPSPIN... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: panic "Sleeping thread owns a non-sleepable lock" via cv_timedwait_signal, was "rsync over NFS"
On 10/02/2012 11:15 PM, John Baldwin wrote: > You could try adding a different WITNESS check (using WITNESS_WARN) to see > which NFS proc returns with a lock held so you can catch this when it first > occurs rather than much later after the fact. Do you have the start of the > log messages? Yep, I have the start of the log, it was archived and is 72 MB in total (some more crashes before ;). So I just have to compile a kernel including "option WITNESS_WARN" and (as mentioned in some mails before) "option WITNESS_SKIPSPIN" and then examine the whole log? Regards, Norbert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: panic "Sleeping thread owns a non-sleepable lock" via cv_timedwait_signal, was "rsync over NFS"
Well... Here the results for a kernel without WITNESS_SKIPSPIN (I'll compile one including that tomorrow, but until then...) Good news is: The kernel crashed with activated WITNESS. Bad news is: I have to turn power off after the crash with WITNESS. The crash dump is _not_ written to disk :( Good news II is: It wrote something to the syslog. Actually, it wrote very much to the syslog, some megabytes in total. Most of it is the same, here the latest messages logfile: http://lbo.spheniscida.de/Files/nfs-crash.log (94K) It specifies the file, line and zone. Maybe it's useful... Regards, Norbert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: panic "Sleeping thread owns a non-sleepable lock" via cv_timedwait_signal, was "rsync over NFS"
I'll compile a kernel with options WITNESS options WITNESS_KDB ok? Or should I include WITNESS_SKIPSPIN too? Regards, Norbert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: panic "Sleeping thread owns a non-sleepable lock" via cv_timedwait_signal, was "rsync over NFS"
On 10/01/2012 02:07 PM, Rick Macklem wrote: > Is the NFS client using Kerberos or AUTH_SYS for the mount? (And if you > are using Kerberos, have you tried the rsync with an AUTH_SYS mount?) No, it's not using Kerberos. Only network-based access control or however it's called (restricted via client IP address). --Norbert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
rsync over NFSv4
Hi, my FreeBSD-9/stable machine (FreeBSD freebsd-tower.goebo.site 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #2 r241044M: Sat Sep 29 12:52:01 CEST 2012 l...@freebsd-tower.goebo.site:/usr/obj/usr/src/sys/GENERIC i386) crashes reproducibly when rsync-ing files to an NFSv4 share on the FreeBSD machine. The crash makes the system reboot. The crash creates files in /var/crash which may be obtained here: [1]. This problem is not limited to the self-compiled kernel/world (stable/9) but appears also on pre-compiled 9.1-PRERELEASE. I did not test 9.0-RELEASE. If I do not use rsync on this NFS share, everything works completely fine. Workaround: Use rsync over SSH. --Norbert [1] http://lbo.spheniscida.de/Files/nfs-rsync-crash.tgz (25K), vmcore of around 300M (90M gzipped, 64M LZMA'd) not included ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Building FreeBSD-STABLE
On 09/29/2012 04:55 PM, Dimitry Andric wrote: > On 2012-09-29 16:16, Norbert Aschendorff wrote: > ... >> src.conf does not exist here, and make.conf contains this: >> >> # added by use.perl 2012-08-23 17:45:18 >> PERL_VERSION=5.14.2 >> >> CFLAGS=-pipe >> #CC=clang >> #CC=gcc >> CXXFLAGS=-pipe >> #CXX=clang++ >> #CXX=g++ > > There is your problem. Never assign to CFLAGS or CXXFLAGS using the = > operator, always add to them, using the += operator instead. Oh, ok. I thought that the flags in CFLAGS or CXXFLAGS are added to the compiler calls. Thank you for clarifying that. > Also, you don't need to duplicate flags in CXXFLAGS, which are already > in CFLAGS. You should only add C++ specific flags to CXXFLAGS. > > Last but not least, -pipe is completely unnecessary, it is already the > default. Nice to know :) Thanks. --Norbert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Building FreeBSD-STABLE
Seems to help, thank you :) But what exactly messed it up? Do you have an idea? --Norbert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Building FreeBSD-STABLE
On 09/29/2012 04:09 PM, David Wolfskill wrote: > On Sat, Sep 29, 2012 at 12:29:26PM +0200, Norbert Aschendorff wrote: >> > Hey, >> > I downloaded FreeBSD-STABLE source via SVN and I'm now at r241038 from >> > 2012-09-28 22:29:06 +0200 (Fri, 28 Sep 2012). > On which branch? (stable/7, stable/8, and stable/9 are all > possibilities, for example.) stable/9. Sorry, I was implying it. >> > If I want to build world (make buildworld), I get the following errors: >> > http://pastebin.com/raw.php?i=Yrs8JSwg > Hmmm > >> > I've set the CC and CXX variables in make.conf to gcc respectively g++. > Why? (You should not need to do this -- I never did (for years) > ... until I decided to migrate to clang/llvm in stable/9 & head). > What are you trying to accomplish by setting them to these values?) I tried it with some ports and forgot to remove it. Today I saw it again, changed it to explicit other values to test it. >> > If I set CC and CXX to clang/clang++, the same error appears: >> > >> > --- >> > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloat.cpp:15:10: >> > fatal error: 'llvm/ADT/APFloat.h' file not found >> > #include "llvm/ADT/APFloat.h" >> > ^ >> > 1 error generated. >> > --- >> > >> > The error stems obviously from C++ files including files from the wrong >> > place (following code taken from contrib/llvm/lib/Support/APInt.cpp): >> > >> > #include "llvm/ADT/APInt.h" >> > #include "llvm/ADT/FoldingSet.h" >> > #include "llvm/ADT/Hashing.h" >> > #include "llvm/ADT/SmallString.h" >> > #include "llvm/ADT/StringRef.h" >> > #include "llvm/Support/Debug.h" >> > #include "llvm/Support/ErrorHandling.h" >> > #include "llvm/Support/MathExtras.h" >> > #include "llvm/Support/raw_ostream.h" >> > >> > The files included here are actually located at >> > contrib/llvm/include/llvm. As far as I currently see, all files needed >> > by the C++ files are there, so the only action which should be taken is >> > to change/add a C Preprocessor include switch in the correct Makefile, >> > right? >> > >> > Or is the error located between chair and screen and I don't see the >> > solution? >> > ... > Perhaps if you were to provide the precise content of /etc/make.conf and > /etc/src.conf, that might help. Also: Are you certain that your svn > checkout or update completed successfully, so your src working copy is > complete? src.conf does not exist here, and make.conf contains this: # added by use.perl 2012-08-23 17:45:18 PERL_VERSION=5.14.2 CFLAGS=-pipe #CC=clang #CC=gcc CXXFLAGS=-pipe #CXX=clang++ #CXX=g++ > FWIW, in switching to clang/llvm, I left /etc/make.conf alone (as I > wasn't trying to switch to clang/llvm for ports at this time); rather, I > set up /etc/src.conf: > > g1-227(9.1-P)[1] cat /etc/src.conf > PORTS_MODULES=x11/nvidia-driver > CC=clang > CXX=clang++ > CPP=clang-cpp > WITH_LIBCPLUSPLUS=yes > g1-227(9.1-P)[2] > > (That's on my laptop.) > > Peace, > david > -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an > opportunity for education is evil. See > http://www.catwhisker.org/~david/publickey.gpg for my public key. > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Building FreeBSD-STABLE
Hey, I downloaded FreeBSD-STABLE source via SVN and I'm now at r241038 from 2012-09-28 22:29:06 +0200 (Fri, 28 Sep 2012). If I want to build world (make buildworld), I get the following errors: http://pastebin.com/raw.php?i=Yrs8JSwg I've set the CC and CXX variables in make.conf to gcc respectively g++. If I set CC and CXX to clang/clang++, the same error appears: --- /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloat.cpp:15:10: fatal error: 'llvm/ADT/APFloat.h' file not found #include "llvm/ADT/APFloat.h" ^ 1 error generated. --- The error stems obviously from C++ files including files from the wrong place (following code taken from contrib/llvm/lib/Support/APInt.cpp): #include "llvm/ADT/APInt.h" #include "llvm/ADT/FoldingSet.h" #include "llvm/ADT/Hashing.h" #include "llvm/ADT/SmallString.h" #include "llvm/ADT/StringRef.h" #include "llvm/Support/Debug.h" #include "llvm/Support/ErrorHandling.h" #include "llvm/Support/MathExtras.h" #include "llvm/Support/raw_ostream.h" The files included here are actually located at contrib/llvm/include/llvm. As far as I currently see, all files needed by the C++ files are there, so the only action which should be taken is to change/add a C Preprocessor include switch in the correct Makefile, right? Or is the error located between chair and screen and I don't see the solution? --Norbert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: IPv4 vs. IPv6 Ethernet Performance
I tested it using tcpdump: http://nopaste.info/9394068f54_nl.html The length field says for each packet 1408 bytes, so that should be OK. The Wireshark instance on the iperf server says something like "16732 bytes on wire" for the most packets (not always with 16732 bytes, but most packets over 10,000) - could that be reassembled somehow? Norbert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: IPv4 vs. IPv6 Ethernet Performance
So, I got the results using the Live system.
Machine [1] is an older Thinkpad T61 (running the Live system), Machine
[2] the well-known "FreeBSD" machine from the previous benchmark. Both
machines run FreeBSD 9.1-RC1 GENERIC.
{Values in MBit/s}
Configuration IPv6IPv4
---
[1] -> [2] 450 600
[2] -> [1] 401 855
This confirms the FreeBSD IPv6 receive rate measured with Linux as
sender (iperf client).
Norbert
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: IPv4 vs. IPv6 Ethernet Performance
That's a bit difficult because I own only one FreeBSD machine - to provide a result FreeBSD->FreeBSD I'd have to set up a completely new system. On the other side, I could try it using the Live system. I'll try it and tell you when I have results. Norbert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
IPv4 vs. IPv6 Ethernet Performance
Hi, I'm using here a Gigabit Ethernet network and some UN*X machines, among others some Linux-based (Kernel 3.x) and one running FreeBSD 9.1-RC1. Using iperf (in TCP mode), the IPv6 bandwith between two Linux machines (directly attached to the same switch) is about 925 Mbit/s, IPv4 bandwith is about 935 Mbit/s. But now it gets exciting: The IPv6 bandwith between a Linux machine and the FreeBSD machine is around 450 Mbit/s (each direction). But the IPv4 bandwith between the same machines is 700 (Linux -> FreeBSD) to 920 (FreeBSD -> Linux) Mbit/s. Little table (values in Mbit/s): Configuration v6 v4 === Linux -> Linux 925 935 # <= This could be v6's 40B header # vs. v4's 20B Linux -> FreeBSD450 700 FreeBSD -> Linux455 920 === The FreeBSD->Linux value shows that the ethernet chip on the FreeBSD machine (it's Intel stuff on both sides, using the em(4) driver on FreeBSD) is able to send at full 1G speed. But why is IPv6 so slow? Regards, Norbert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
[CLOSED] Re: Problem with Linux >= 3.3 as NFSv4 server
As this is obviously a Linux (kernel(?)) problem, I think I can close this thread. And thank you for your answers, Rick :) Norbert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Problem with Linux >= 3.3 as NFSv4 server
And just another thing: Using the Fedora machine (also kernel 3.5) as server, I see the exactly same behavior. Sending '1000' (numeric UID) instead of actual username. Using Kernel 3.2 on the server, the translation even works when using the same username and different IDs (as it should...). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Problem with Linux >= 3.3 as NFSv4 server
It looks as if the problem is related to this bug which shows the exactly same symptoms (if you look at the package dumps). It's also Kernel 3.3 with which it also begun here. And with kernel 3.1, it works (same here). --> https://bugzilla.novell.com/show_bug.cgi?id=756897 I don't know what's the problem anyway. Maybe changed kernel interfaces? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Problem with Linux >= 3.3 as NFSv4 server
Sorry, I was wrong :|. This time, the packets contain the numeric user and group IDs (in my case, 1000:1000). A pcap file with some NFS requests and responses can be found here: http://lbo.spheniscida.de/Files/nfs.pcap -- sorry for that misinformation in the previous mail :( Norbert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Problem with Linux >= 3.3 as NFSv4 server
I already had a problem with this, but this is fixed: 1. The hostnames are correct 2. in the debian /etc/idmapd.conf, the right domain name is specified 3. The names are transmitted correctly -- tested with Wireshark. If the problem was wrong domain names, I had found it because I always take a look at the traffic if I have a problem with network stuff. And (as mentioned), I already had the name problem and therefore the knowledge how to detect and fix it. Nevertheless, thank you for your answer. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Problem with Linux >= 3.3 as NFSv4 server
Hi all, I recently noticed a problem in my network. I use some desktop machines there, two with Linux kernel (Debian and Fedora, both using Kernel 3.5) and a FreeBSD 9.0 (p4) machine. Some days ago, I updated the Debian machine from Kernel 3.2 to Kernel 3.5 (from the experimental branch, 3.5-trunk-amd64; I hope you aren't bothered by the Linux-specific parts). Running 3.2, the FreeBSD machine was able to mount an NFSv4 share on the Debian/k3.2 system properly, with UIDs etc (using nfsuserd on FreeBSD, rpc.idmapd on GNU/Linux). Since I updated to Kernel 3.5, the FreeBSD machine only shows 32767 as UID/GID for all files. `chown` works (even though without any effect, but without error, so nfsuserd works). This behavior occurred also when using Linux Kernel 3.3 or 3.4 on the Debian (server) machine. With the Fedora 17 machine (also Kernel 3.5, and the same users in /etc/passwd, of course), the same operation works without this errors, showing the UIDs and GIDs I want it to. 1. Am I right on this list, or should I ask first on a Linux-oriented list/forum? 2. Has anyone else noticed this or similar behaviour? 3. Any ideas about fixes, workarounds, known bugs? -- norbert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: linux-f10-flashplugin
On Thu, 29 Sep 2011 22:06:59 +0200 Alexander Leidinger wrote: > On Thu, 29 Sep 2011 12:50:01 -0700 Ted Faber wrote: > > > On Thu, Sep 29, 2011 at 02:41:39PM -0400, Michael Butler wrote: > > > On 09/29/11 13:57, Norbert Augenstein wrote: > > > > On Wed, Sep 28, 2011 at 10:08:25PM +0400, S.N.Grigoriev wrote: > > > >> 28.09.2011, 21:10, "Conrad J. Sabatier": > > > >>> On Wed, 28 Sep 2011 11:50:08 -0500 > > > >>> "Conrad J. Sabatier" wrote: > > > > I see that as well as: > > > > (process:5430): Gtk-WARNING **: Locale not supported by C library. > > Using the fallback 'C' locale. > > > > (npviewer.bin:5430): GLib-WARNING **: getpwuid_r(): failed > > due to unknown user id (2139) > > > > (npviewer.bin:5430): Gtk-WARNING **: cannot open > > display: :0.0 *** NSPlugin Wrapper *** ERROR: failed to initialize > > plugin-side RPC client connection > > NOTE: child process received `Goodbye', closing down > > > > > > I haven't explored the getpwuid_r thing. > > > > Can you all please confirm that you run the most recent FreeBSD > version (of your branch), as in "with the recent security fixes"? > There are reports that one of them may have caused what you see. > > Bye, > Alexander. > Hi list, it seems that http://security.freebsd.org/advisories/FreeBSD-SA-11:05.unix.asc is the culprit. --> auge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: linux-f10-flashplugin
On Wed, Sep 28, 2011 at 10:08:25PM +0400, S.N.Grigoriev wrote: > > > 28.09.2011, 21:10, "Conrad J. Sabatier" : > > On Wed, 28 Sep 2011 11:50:08 -0500 > > "Conrad J. Sabatier" wrote: > > > >> It was a while ago that I did the actual wrapper install, but if I > >> remember right, I simply copied npwrapper.libflashplayer.so > >> from /usr/local/lib/browser_plugins to /home/conrads/.mozilla/plugins. > >> You may want to try doing that and see if firefox/chromium will then > >> recognize it. > >> > >> In theory, the system-wide install > >> under /usr/local/lib/browser_plugins *should* work, but I seem to > >> recall having problems with it, which was why I tried putting it > >> under ~/.mozilla/plugins. Maybe it has something to do with the fact > >> that it's not a native plugin(?). I don't know, really. But this > >> has worked fine for me ever since, even across upgrades. > >> > >> Hope this helps. Let us know how it turns out. > > > > Actually, now that I think of it, I think the way I did it was this: > > > > cd /home/conrads/.mozilla/plugins > > > > /usr/local/lib/nspluginwrapper/x86_64/freebsd/npconfig > > -i /usr/local/lib/npapi/linux-f10-flashplugin/libflashplayer.so > > > > And npwrapper.libflashplayer.so was created > > under /home/conrads/.mozilla/plugins. > > > > Hope this helps. > > I've done it. No results. > ... same problem here, but the last i did yesterday was a 'freebsd-update' to 8.2-RELEASEp3 after 'freebsd-update rollback' flash is working again. can someone look at this? --> auge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD-9.0-BETA1-i386-bootonly
On Wed, Aug 10, 2011 at 06:44:00PM +0400, N V wrote: > Hi. > > Tried to use FreeBSD-9.0-BETA1-i386-bootonly.iso in VirtualBox to test. > Installation stops after trying to fetch files from ftp. Attached screenshot > is informative, I think. Seems to use i386/ twice for some reason. > same here for amd64, but the disc1.iso worked fine ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so
On February 13, 2010, Norbert Papke wrote: > I will repeat the experiment a few more times. After quite a number of trials, I never managed to get any further with the radeon driver. I also tried the radeonhd driver. It seems to behave a little differently. I usually get to an X screen with some incompletely rendered windows before the system hangs. Feb 13 15:51:51 proven kernel: [drm:pid1833:drm_ioctl] pid=1833, cmd=0xc0106403, nr=0x03, dev 0xff00026fb400, auth=1 Feb 13 15:51:51 proven kernel: [drm:pid1833:drm_irq_by_busid] 1:0:0 => IRQ 260 Feb 13 15:51:51 proven kernel: [drm:pid1833:drm_ioctl] pid=1833, cmd=0x80086414, nr=0x14, dev 0xff00026fb400, auth=1 Feb 13 15:51:51 proven kernel: [drm:pid1833:drm_irq_install] irq=260 Feb 13 15:51:51 proven kernel: drm0: [ITHREAD] Feb 13 15:51:51 proven kernel: [drm:pid1833:drm_ioctl] pid=1833, cmd=0x800c6455, nr=0x55, dev 0xff00026fb400, auth=1 Feb 13 15:51:51 proven kernel: [drm:pid1833:drm_ioctl] pid=1833, cmd=0x80106459, nr=0x59, dev 0xff00026fb400, auth=1 Feb 13 15:51:51 proven kernel: [drm:pid1833:drm_ioctl] pid=1833, cmd=0xc0106451, nr=0x51, dev 0xff00026fb400, auth=1 Feb 13 15:51:51 proven kernel: [drm:pid1833:radeon_cp_getparam] pid=1833 Feb 13 15:51:51 proven kernel: [drm:pid1833:drm_ioctl] pid=1833, cmd=0x20006441, nr=0x41, dev 0xff00026fb400, auth=1 Feb 13 15:51:51 proven kernel: [drm:pid1833:radeon_cp_start] Feb 13 15:51:51 proven kernel: [drm:pid1833:r600_do_cp_start] Feb 13 15:51:51 proven kernel: [drm:pid1833:drm_ioctl] pid=1833, cmd=0xc0406429, nr=0x29, dev 0xff00026fb400, auth=1 Feb 13 15:51:51 proven kernel: [drm:pid1833:radeon_freelist_get] done_age = -559038737 Feb 13 15:51:52 proven kernel: [drm:pid1833:drm_ioctl] pid=1833, cmd=0xc0406429, nr=0x29, dev 0xff00026fb400, auth=1 Feb 13 15:51:52 proven kernel: [drm:pid1833:radeon_freelist_get] done_age = -559038737 Feb 13 15:51:52 proven kernel: [drm:pid1833:drm_mmap] called with offset 0602 Feb 13 15:51:52 proven kernel: [drm:pid1833:drm_mmap] called with offset 06021000 Feb 13 15:51:52 proven kernel: [drm:pid1833:drm_mmap] called with offset 06022000 Feb 13 15:51:52 proven kernel: [drm:pid1833:drm_mmap] called with offset 06023000 Feb 13 15:51:52 proven kernel: [drm:pid1833:drm_mmap] called with offset 06028000 Feb 13 15:51:52 proven kernel: [drm:pid1833:drm_ioctl] pid=1833, cmd=0xc010644d, nr=0x4d, dev 0xff00026fb400, auth=1 Feb 13 15:51:52 proven kernel: [drm:pid1833:radeon_cp_indirect] idx=2 s=0 e=14400 d=1 Feb 13 15:51:52 proven kernel: [drm:pid1833:r600_cp_dispatch_indirect] dwords:3600 Feb 13 15:51:52 proven kernel: [drm:pid1833:r600_cp_dispatch_indirect] offset 0xf0222000 I am not sure what to make of this. Cheers, -- Norbert. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so
On February 13, 2010, Robert Noland wrote: > On Sat, 2010-02-13 at 11:37 -0800, Norbert Papke wrote: > > On February 13, 2010, Robert Noland wrote: > > > Ok, I've put up a patch at: > > > > > > http://people.freebsd.org/~rnoland/drm-radeon-test.patch > > http://people.freebsd.org/~rnoland/drm-radeon-8-test.patch > > This one should work on 8... Thanks, the patch applies and builds cleanly. Unfortunately, it does not fix things for me. I am back to completely hanging the system. I getting the sense that there is some randomness or a timing issue. Changes that improved the behavior in one trial do not necessarily help in another trial. One thing I did is enable DRM_DEBUG. I wanted to get sense of how far we got before the hang. Unfortunately, there is no guarantee that log messages will be persisted before the system hangs. In a few attempts, the latest messages I observed were the following: Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] dev->agp_buffer_map->virtual 0xff807a51b000 Feb 13 13:37:58 proven kernel: info: [drm] Setting GART location based on new memory map Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] fb 0xd000 size 536870912 Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] dev_priv->gart_size 33554432 Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] dev_priv->gart_vm_start 0xf000 Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] dev_priv->gart_buffers_offset 0xf0102000 Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] Using gart offset 0x0fff Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_init_cp] Setting phys_pci_gart to 0xff00dfff 0FFF Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_page_table_init] page entry 0: 0xb956c063 Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_page_table_init] page entry 128: 0x82128063 Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_page_table_init] page entry 256: 0x98b8a063 [...] Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_page_table_init] page entry 7936: 0x499df063 Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_page_table_init] page entry 8064: 0x49a21063 Feb 13 13:37:58 proven kernel: info: [drm] Loading RV635 Microcode Feb 13 13:37:58 proven kernel: [drm:pid41750:r600_do_cp_stop] I will repeat the experiment a few more times. Cheers. -- Norbert Papke. npa...@acm.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: freebsd7 (and 8), radeon, xorg-server -> deadlock or so
On February 13, 2010, Robert Noland wrote: > Ok, I've put up a patch at: > > http://people.freebsd.org/~rnoland/drm-radeon-test.patch > > This is sort of a mega patch and includes: > > Re-worked drm mapping code, that ensures that we don't end up > incorrectly mapping certain maps with overlapping offsets. This > generally shows up as the ring buffer not being cleared (contents != 0 > in xorg.log) which leads to corruption and other bad behavior. > > Re-written scatter gather allocation code. This interacts directly with > the VM system, rather than using bus_dma to allow us to grab > non-contiguous pages for the scatter gather backing of the GART. It > also makes it easier to handle the caching mode of the backing pages. > > Disable cache snooping on radeon cards, since we have write combining > set properly now. > > I have at least done a test build on -CURRENT with this patch, but I > haven't had time to do much else without the rest of the code in my > tree. I've been running most all of this code for a month or two now at > least, so it is mostly just a question of whether or not I got all of > the conflicts sorted out properly when I made this patch. > > The re-mapping code has the most widespread impact and has been tested > on radeon r600 amd64, intel g45 i386 and mga amd64. > > robert. I tweaked the patch and applied it to 8-STABLE. It has improved things. I no longer hang when starting X but DRI still does not work. I also intermittently experience the interrupt problem where the screen does not update unless I wiggle the mouse. It is entirely possible that I messed up adapting the patch for 8-STABLE. I did the following: * applied SVN 203287 and 203287 for VIA support * applied your patch * reverted drm_vm.c because it is dependent on r201223 (Update d_mmap() to accept vm_ooffset_t and vm_memattr_t.) * re-enabled snooping in ati_pcigart.c and r600_cp.c I have appended my xorg.0.log file. Perhaps something in there stands out as red flag? Thank you for all the time you put into this. Cheers, -- Norbert Papke. npa...@acm.org X.Org X Server 1.6.5 Release Date: 2009-10-11 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 8.0-STABLE amd64 Current Operating System: FreeBSD proven.lan.provenpath.ca 8.0-STABLE FreeBSD 8.0-STABLE #36 r203841M: Sat Feb 13 10:50:20 PST 2010 npa...@proven.lan.provenpath.ca:/usr/obj/red/usr/public/freebsd/sources/stable8/sys/PROVEN amd64 Build Date: 10 February 2010 06:25:15PM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Sat Feb 13 10:55:30 2010 (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "X.org Configured" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "LG" (**) | |-->Device "Card0" (**) Option "DontZap" "off" (**) Option "BlankTime" "15" (**) Option "StandbyTime" "120" (**) Option "SuspendTime" "150" (**) Option "OffTime" "180" (**) Option "AIGLX" "on" (**) Option "AllowEmptyInput" "false" (==) Automatically adding devices (==) Automatically enabling devices (WW) `fonts.dir' not found (or not valid) in "/usr/local/share/fonts/". Entry deleted from font path. (Run 'mkfontdir' on "/usr/local/share/fonts/"). (WW) `fonts.dir' not found (or not valid) in "/usr/local/share/fonts/cmpsfont". Entry deleted from font path. (Run 'mkfontdir' on "/usr/local/share/fonts/cmpsfont"). (WW) `fonts.dir' not found (or not valid) in "/usr/local/share/fonts/amspsfont". Entry deleted from font path. (Run 'mkfontdir' on "/usr/local/share/fonts/amspsfont"). (**) FontPath set to: /usr/local/lib/X11/fonts/bitstream-vera/, /usr/local/lib/X11/fonts/dejavu/, /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TrueType/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF, /usr/local/lib/X11/fonts/Type1/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/, /usr/local/lib/X11/fonts/webfonts/, /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF, /usr/local/lib/X11/fonts/Type1/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/ (**
Re: ZFS performance degradation over time
On January 17, 2010, Garrett Moore wrote: > I upgraded my system to 8GB of ram to see if that would help. It hasn't > made much of a difference. After having rTorrent running for a while, my > performance again tanked. Around 6.5GB of memory was showing as 'Active' > according to top. 6.5GB of "active" memory seems to imply that a user process is growing or a large number of user processes are being created. I would expect ZFS's cache to increase the size of "wired" memory. Sorry, I have not followed this thread closely. Are you sure that the degradation is ZFS related? Could it be caused by, for instance, a userland memory leak? What happens to active memory when you restart rtorrent? Cheers, -- Norbert Papke. npa...@acm.org http://saveournet.ca Protecting your Internet's level playing field ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.0-RC USB/FS problem
On November 24, 2009, Jeremy Chadwick wrote: > $ host www.daemonfun.com > www.daemonfun.com is an alias for daemonfun.com. > daemonfun.com has address 76.202.192.211 > daemonfun.com mail is handled by 10 mh1.daemonfun.com. > daemonfun.com mail is handled by 20 mh2.daemonfun.com. > > $ fetch http:/www.daemonfun.com/ > fetch: http:/www.daemonfun.com/: No address record > > I haven't examined the code, but my guess is fetch is trying to do a > lookup on the FQDN "http:/www.daemonfun.com/". Who wants to file a PR? As Dan Nelson mentioned, it's just a typo in the url. Try $ fetch http://www.daemonfun.com/ Note the "://" rather than ":/". Cheers. -- Norbert Papke. npa...@acm.org http://saveournet.ca Protecting your Internet's level playing field ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 7.2 Stable Crash - possibly related to if_re
On October 31, 2009, Pyun YongHyeon wrote: > On Fri, Oct 30, 2009 at 06:23:51PM -0700, Norbert Papke wrote: > > On October 30, 2009, Pyun YongHyeon wrote: > > > On Thu, Oct 29, 2009 at 09:56:19PM -0700, Norbert Papke wrote: > > > > This occurred shortly after "scp"ing from a VirtualBox VM to the > > > > host. The file transfer got stuck. The "re" interface stopped > > > > working. Shortly afterwards, the host crashed. The "re" interface > > > > was used by the host, the guest was using a different NIC in bridged > > > > mode. > > > > > > > > > > > > FreeBSD proven.lan 7.2-STABLE FreeBSD 7.2-STABLE #5 r198666: Thu Oct > > > > 29 18:36:57 PDT 2009 > > > > > > > > Fatal trap 12: page fault while in kernel mode > > > > cpuid = 0; apic id = 00 > > > > fault virtual address = 0x18 > > > > > > It looks like a NULL pointer dereference, possibly mbuf related > > > one. > > > > > > > fault code = supervisor write data, page not present > > > > instruction pointer = 0x8:0x80d476ee > > > > stack pointer = 0x10:0xff878ae0 > > > > frame pointer = 0x10:0xff878b40 > > > > code segment= base 0x0, limit 0xf, type 0x1b > > > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > > > processor eflags= interrupt enabled, resume, IOPL = 0 > > > > current process = 18 (swi5: +) > > > By chance, did you stop the re0 interface with ifconfig when you > > > noticed the file transfer got stuck? > > > > It is possible. I had it happen twice. The first time I definitely > > tried to "down" re. I cannot recall what I did the second time. The > > crash dump is from the second time. > > Ok, then would you try attached patch? I have been running with the patch for a couple of days. Although I can still reproduce the lock-up of the network stack, I have not been able to reproduce the panic. The patch does what it is supposed to do. I will continue to try to come up with a better test case for the file transfer problem. However, I no longer suspect "re" as a cause. Thank you very much for your help. Cheers, -- Norbert Papke. npa...@acm.org http://saveournet.ca Protecting your Internet's level playing field ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 7.2 Stable Crash - possibly related to if_re
On October 31, 2009, Pyun YongHyeon wrote: > On Fri, Oct 30, 2009 at 06:23:51PM -0700, Norbert Papke wrote: > > On October 30, 2009, Pyun YongHyeon wrote: > > > On Thu, Oct 29, 2009 at 09:56:19PM -0700, Norbert Papke wrote: > > > > This occurred shortly after "scp"ing from a VirtualBox VM to the > > > > host. The file transfer got stuck. The "re" interface stopped > > > > working. Shortly afterwards, the host crashed. The "re" interface > > > > was used by the host, the guest was using a different NIC in bridged > > > > mode. > > > > > > > > > > > > FreeBSD proven.lan 7.2-STABLE FreeBSD 7.2-STABLE #5 r198666: Thu Oct > > > > 29 18:36:57 PDT 2009 > > > > > > > > Fatal trap 12: page fault while in kernel mode > > > > cpuid = 0; apic id = 00 > > > > fault virtual address = 0x18 > > > > > > It looks like a NULL pointer dereference, possibly mbuf related > > > one. > > > > > > > fault code = supervisor write data, page not present > > > > instruction pointer = 0x8:0x80d476ee > > > > stack pointer = 0x10:0xff878ae0 > > > > frame pointer = 0x10:0xff878b40 > > > > code segment= base 0x0, limit 0xf, type 0x1b > > > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > > > processor eflags= interrupt enabled, resume, IOPL = 0 > > > > current process = 18 (swi5: +) > > > > Physical memory: 8177 MB > > > > > > > By chance, did you stop the re0 interface with ifconfig when you > > > noticed the file transfer got stuck? > > > > It is possible. I had it happen twice. The first time I definitely > > tried to "down" re. I cannot recall what I did the second time. The > > crash dump is from the second time. > > Ok, then would you try attached patch? I have been running with patch for a couple of days now. Although I can still reproduce the problem with the file transfer, I have not been able to reproduce the panic. The patch appears to do what it is supposed to do. I am going to continue to try to come up with a better test case for the original file transfer problem. I no longer suspect "re" as a cause. Thank you very much for your help. Cheers, -- Norbert Papke. npa...@acm.org http://saveournet.ca Protecting your Internet's level playing field ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 7.2 Stable Crash - possibly related to if_re
On October 30, 2009, Pyun YongHyeon wrote: > On Thu, Oct 29, 2009 at 09:56:19PM -0700, Norbert Papke wrote: > > This occurred shortly after "scp"ing from a VirtualBox VM to the host. > > The file transfer got stuck. The "re" interface stopped working. > > Shortly afterwards, the host crashed. The "re" interface was used by the > > host, the guest was using a different NIC in bridged mode. > > > > > > FreeBSD proven.lan 7.2-STABLE FreeBSD 7.2-STABLE #5 r198666: Thu Oct 29 > > 18:36:57 PDT 2009 > > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 0; apic id = 00 > > fault virtual address = 0x18 > > It looks like a NULL pointer dereference, possibly mbuf related > one. > > > fault code = supervisor write data, page not present > > instruction pointer = 0x8:0x80d476ee > > stack pointer = 0x10:0xff878ae0 > > frame pointer = 0x10:0xff878b40 > > code segment= base 0x0, limit 0xf, type 0x1b > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags= interrupt enabled, resume, IOPL = 0 > > current process = 18 (swi5: +) > > Physical memory: 8177 MB > > > > > > #9 0x807e710e in calltrap () > > at /usr/public/freebsd/sources/stable/sys/amd64/amd64/exception.S:218 > > #10 0x80d476ee in re_rxeof () from /boot/kernel/if_re.ko > > Hmm, I think there is a missing information here. Not sure where it > dereferenced a NULL pointer in re_rxeof(). >> #11 0x80d4a481 in re_int_task (arg=Variable "arg" is not available. >> ) >> at /usr/public/freebsd/sources/stable/sys/modules/re/../../dev/re/if_re.c:2191 I am not sure how much I trust frame 10. The instruction at "0x80d476ee" is the one after the "retq" from re_rxeof(). Frame 11 seems OK to me. The "struct rl_softc*", in particular, looks plausible but I don't know enough to say for sure. > Because that this is the > first report for NULL pointer dereference in Rx handler I need more > information how to reproduce it with minimal configuration. Can you > also reproduce the issues without virtual box? I am trying but no luck so far. > By chance, did you stop the re0 interface with ifconfig when you > noticed the file transfer got stuck? It is possible. I had it happen twice. The first time I definitely tried to "down" re. I cannot recall what I did the second time. The crash dump is from the second time. Thanks very much for the response. I'll try to come up with a better test case. If I succeed, I will report back. Cheers, -- Norbert Papke. npa...@acm.org http://saveournet.ca Protecting your Internet's level playing field ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
7.2 Stable Crash - possibly related to if_re
This occurred shortly after "scp"ing from a VirtualBox VM to the host. The file transfer got stuck. The "re" interface stopped working. Shortly afterwards, the host crashed. The "re" interface was used by the host, the guest was using a different NIC in bridged mode. FreeBSD proven.lan 7.2-STABLE FreeBSD 7.2-STABLE #5 r198666: Thu Oct 29 18:36:57 PDT 2009 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x18 fault code = supervisor write data, page not present instruction pointer = 0x8:0x80d476ee stack pointer = 0x10:0xff878ae0 frame pointer = 0x10:0xff878b40 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 18 (swi5: +) Physical memory: 8177 MB (kgdb) bt #0 doadump () at pcpu.h:195 #1 0x801d5faf in db_fncall (dummy1=Variable "dummy1" is not available. ) at /usr/public/freebsd/sources/stable/sys/ddb/db_command.c:516 #2 0x801d64b9 in db_command (last_cmdp=0x80b46ac8, cmd_table=0x0, dopager=1) at /usr/public/freebsd/sources/stable/sys/ddb/db_command.c:413 #3 0x801d66bb in db_command_loop () at /usr/public/freebsd/sources/stable/sys/ddb/db_command.c:466 #4 0x801d8197 in db_trap (type=Variable "type" is not available. ) at /usr/public/freebsd/sources/stable/sys/ddb/db_main.c:228 #5 0x8054ab45 in kdb_trap (type=12, code=0, tf=0xff878a30) at /usr/public/freebsd/sources/stable/sys/kern/subr_kdb.c:524 #6 0x807fcdd3 in trap_fatal (frame=0xff878a30, eva=Variable "eva" is not available. ) at /usr/public/freebsd/sources/stable/sys/amd64/amd64/trap.c:772 #7 0x807fd185 in trap_pfault (frame=0xff878a30, usermode=0) at /usr/public/freebsd/sources/stable/sys/amd64/amd64/trap.c:693 #8 0x807fd9bd in trap (frame=0xff878a30) at /usr/public/freebsd/sources/stable/sys/amd64/amd64/trap.c:464 #9 0x807e710e in calltrap () at /usr/public/freebsd/sources/stable/sys/amd64/amd64/exception.S:218 #10 0x80d476ee in re_rxeof () from /boot/kernel/if_re.ko #11 0x80d4a481 in re_int_task (arg=Variable "arg" is not available. ) at /usr/public/freebsd/sources/stable/sys/modules/re/../../dev/re/if_re.c:2191 #12 0x80554d46 in taskqueue_run (queue=0xff000192f300) at /usr/public/freebsd/sources/stable/sys/kern/subr_taskqueue.c:282 #13 0x804fbc1d in ithread_loop (arg=0xff00019433a0) at /usr/public/freebsd/sources/stable/sys/kern/kern_intr.c:1126 #14 0x804f83c4 in fork_exit (callout=0x804fbaa5 , arg=0xff00019433a0, frame=0xff878c80) at /usr/public/freebsd/sources/stable/sys/kern/kern_fork.c:811 #15 0x807e74ee in fork_trampoline () at /usr/public/freebsd/sources/stable/sys/amd64/amd64/exception.S:554 From dmesg: re0: port 0xd800-0xd8ff mem 0xfeaff000-0xfeaf,0xfdff-0xfdff irq 17 at device 0.0 on pci3 re0: Using 1 MSI messages re0: Chip rev. 0x3c00 re0: MAC rev. 0x0040 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:30:48:b0:6a:1f -- Norbert Papke. npa...@acm.org http://saveournet.ca Protecting your Internet's level playing field ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 7.2-STABLE: Inserting USB device causes Fatal Trap 12
On May 10, 2009, Norbert Papke wrote: > Inserting a USB thumb drive into a running sytem result in a "Fatal trap > 12: page fault while in kernel mode". After repeating the crash a few times with INVARIANTS enabled, it becomes apparent that EHCI transfer queue is getting corrupted. With High Precision Event Timers disabled in the BIOS, the problem goes away. This is an acceptable work-around for me. I am inclined to believe (but unable to prove) that the crash is due to a BIOS bug. Cheers, -- Norbert Papke. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 7.2-STABLE: Inserting USB device causes Fatal Trap 12
I have been trying to understand the failure better:
(kgdb) frame 10
#10 0x80473265 in usb_transfer_complete (xfer=0xff00045cbc00)
at /red/public/freebsd/sources/stable/sys/dev/usb/usbdi.c:949
949 STAILQ_REMOVE_HEAD(&pipe->queue, next);
(kgdb) list
944 #ifdef DIAGNOSTIC
945 xfer->busy_free = XFER_BUSY;
946 #endif
947 KASSERT(STAILQ_FIRST(&pipe->queue) == xfer,
948 ("usb_transfer_complete: bad dequeue"));
949 STAILQ_REMOVE_HEAD(&pipe->queue, next);
950 }
951 DPRINTFN(5,("usb_transfer_complete: repeat=%d new head=%p\n",
952 repeat, STAILQ_FIRST(&pipe->queue)));
For reference:
#define STAILQ_NEXT(elm, field) ((elm)->field.stqe_next)
#define STAILQ_FIRST(head) ((head)->stqh_first)
#define STAILQ_REMOVE_HEAD(head, field) do {\
if ((STAILQ_FIRST((head)) = \
STAILQ_NEXT(STAILQ_FIRST((head)), field)) == NULL) \
(head)->stqh_last = &STAILQ_FIRST((head)); \
} while (0)
Looking at the data:
(kgdb) p *pipe
$15 = {iface = 0x0, device = 0xff009c1e4a00, endpoint =
0xff009c1e4a38, refcnt = 1, running = 0 '\0', aborting = 0 '\0',
queue = {stqh_first = 0x0, stqh_last = 0xff000c8576a0}, next = {le_next
= 0x806b560b4, le_prev = 0x0}, intrxfer = 0x0,
repeat = 0 '\0', interval = -1, methods = 0x80a6e340}
(kgdb) p pipe->queue
$16 = {stqh_first = 0x0, stqh_last = 0xff000c8576a0}
(kgdb) p pipe->queue->stqh_first
$17 = (struct usbd_xfer *) 0x0
And, of course,
(kgdb) p pipe->queue->stqh_first.next
Cannot access memory at address 0x290
If the kernel had been built with INVARIANTS, presumably the prior assertion
would have been triggered. It is not clear to me how the transfer ended up
in this bad state. Could the "USBD_NOMEM" status be a clue?
(kgdb) p *xfer
$6 = {pipe = 0xff000c857680, priv = 0x0, buffer = 0xfffef5b69ff0,
length = 18, actlen = 0, flags = 6, timeout = 5000,
status = USBD_NOMEM, callback = 0, done = 1 '\001', request = {bmRequestType
= 128 '\200', bRequest = 6 '\006',
wValue = "\001\003", wIndex = "\t\004", wLength = "\022"}, frlengths =
0x0, nframes = 0, device = 0xff009c1e4a00, dmamap = {
segs = {{ds_addr = 23408640, ds_len = 16}, {ds_addr = 23355392, ds_len =
2}, {ds_addr = 0, ds_len = 0} },
nsegs = 2, map = 0xff000cbf5e00}, allocbuf = 0x0, rqflags = 1, next =
{stqe_next = 0x0}, hcpriv = 0x0, timeout_handle = {
c_links = {sle = {sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev =
0x0}}, c_time = 0, c_arg = 0x0, c_func = 0,
c_mtx = 0x80b12600, c_flags = 0}}
I am getting out of my depth. I will spend some more time trying to learn
this code but would appreciate pointers.
Cheers,
-- Norbert Papke.
On May 10, 2009, Norbert Papke wrote:
> On May 10, 2009, Norbert Papke wrote:
> > Inserting a USB thumb drive into a running sytem result in a "Fatal trap
> > 12: page fault while in kernel mode".
> >
> > Unfortunately, I was not able to save a core (not entirely sure why, I'll
> > investigate separately). I have manually copied the backtrace:
>
> I now have a kernel dump and backtrace with symbols:
>
> #0 doadump () at pcpu.h:195
> #1 0x801d239c in db_fncall (dummy1=Variable "dummy1" is not
> available.
> ) at /red/public/freebsd/sources/stable/sys/ddb/db_command.c:516
> #2 0x801d28a9 in db_command (last_cmdp=0x80adc648,
> cmd_table=0x0, dopager=1)
> at /red/public/freebsd/sources/stable/sys/ddb/db_command.c:413
> #3 0x801d2aab in db_command_loop ()
> at /red/public/freebsd/sources/stable/sys/ddb/db_command.c:466
> #4 0x801d42f7 in db_trap (type=Variable "type" is not available.
> ) at /red/public/freebsd/sources/stable/sys/ddb/db_main.c:228
> #5 0x805159e5 in kdb_trap (type=12, code=0, tf=0xfffef5b69d10)
> at /red/public/freebsd/sources/stable/sys/kern/subr_kdb.c:524
> #6 0x80798143 in trap_fatal (frame=0xfffef5b69d10,
> eva=Variable "eva" is not available.
> )
> at /red/public/freebsd/sources/stable/sys/amd64/amd64/trap.c:752
> #7 0x80798498 in trap_pfault (frame=0xfffef5b69d10,
> usermode=0) at
> /red/public/freebsd/sources/stable/sys/amd64/amd64/trap.c:673 #8
> 0x80798bcf in trap (frame=0xfffef5b69d10)
> at /red/public/freebsd/sources/stable/sys/amd64/amd64/trap.c:444
> #9 0x8077edae in calltrap ()
> at /red/public/freebsd/sources/stable/sys/amd64/amd64/exce
Re: 7.2-STABLE: Inserting USB device causes Fatal Trap 12
On May 10, 2009, Norbert Papke wrote: > Inserting a USB thumb drive into a running sytem result in a "Fatal trap > 12: page fault while in kernel mode". > > Unfortunately, I was not able to save a core (not entirely sure why, I'll > investigate separately). I have manually copied the backtrace: I now have a kernel dump and backtrace with symbols: #0 doadump () at pcpu.h:195 #1 0x801d239c in db_fncall (dummy1=Variable "dummy1" is not available. ) at /red/public/freebsd/sources/stable/sys/ddb/db_command.c:516 #2 0x801d28a9 in db_command (last_cmdp=0x80adc648, cmd_table=0x0, dopager=1) at /red/public/freebsd/sources/stable/sys/ddb/db_command.c:413 #3 0x801d2aab in db_command_loop () at /red/public/freebsd/sources/stable/sys/ddb/db_command.c:466 #4 0x801d42f7 in db_trap (type=Variable "type" is not available. ) at /red/public/freebsd/sources/stable/sys/ddb/db_main.c:228 #5 0x805159e5 in kdb_trap (type=12, code=0, tf=0xfffef5b69d10) at /red/public/freebsd/sources/stable/sys/kern/subr_kdb.c:524 #6 0x80798143 in trap_fatal (frame=0xfffef5b69d10, eva=Variable "eva" is not available. ) at /red/public/freebsd/sources/stable/sys/amd64/amd64/trap.c:752 #7 0x80798498 in trap_pfault (frame=0xfffef5b69d10, usermode=0) at /red/public/freebsd/sources/stable/sys/amd64/amd64/trap.c:673 #8 0x80798bcf in trap (frame=0xfffef5b69d10) at /red/public/freebsd/sources/stable/sys/amd64/amd64/trap.c:444 #9 0x8077edae in calltrap () at /red/public/freebsd/sources/stable/sys/amd64/amd64/exception.S:209 #10 0x80473265 in usb_transfer_complete (xfer=0xff00045cbc00) at /red/public/freebsd/sources/stable/sys/dev/usb/usbdi.c:949 #11 0x8077af55 in bus_dmamap_load (dmat=0xff0004598580, map=0xff000cbf5e00, buf=0xfffef5b69ff0, buflen=Variable "buflen" is not available. ) at /red/public/freebsd/sources/stable/sys/amd64/amd64/busdma_machdep.c:739 #12 0x80473955 in usbd_transfer (xfer=0xff00045cbc00) at /red/public/freebsd/sources/stable/sys/dev/usb/usbdi.c:312 #13 0x80473b36 in usbd_do_request_flags_pipe (dev=0xff009c1e4a00, pipe=0xff000c857680, req=0xfffef5b69f90, data=0xfffef5b69ff0, flags=Variable "flags" is not available. ) at /red/public/freebsd/sources/stable/sys/dev/usb/usbdi.c:1100 #14 0x80473c60 in usbd_do_request_flags (dev=Variable "dev" is not available. ) at /red/public/freebsd/sources/stable/sys/dev/usb/usbdi.c:1070 #15 0x80471d1a in usbd_get_string_desc (dev=0xff009c1e4a00, sindex=Variable "sindex" is not available. ) at /red/public/freebsd/sources/stable/sys/dev/usb/usb_subr.c:171 #16 0x80472f1d in usbd_get_string (dev=0xff009c1e4a00, si=1, buf=0xfffef5b6a200 "", len=128) ---Type to continue, or q to quit--- at /red/public/freebsd/sources/stable/sys/dev/usb/usbdi.c:1353 #17 0x80470fca in usbd_devinfo_vp (dev=0xff009c1e4a00, v=0xfffef5b6a200 "", p=0xfffef5b6a180 "�z�\200`��\200", usedev=Variable "usedev" is not available. ) at /red/public/freebsd/sources/stable/sys/dev/usb/usb_subr.c:216 #18 0x80471b76 in usbd_devinfo (dev=0xff009c1e4a00, showclass=1, cp=0xff0122986000 "\001") at /red/public/freebsd/sources/stable/sys/dev/usb/usb_subr.c:281 #19 0x8047243e in usbd_new_device (parent=0xff0004591900, bus=0xff000440a000, depth=Variable "depth" is not available. ) at /red/public/freebsd/sources/stable/sys/dev/usb/usb_subr.c:861 #20 0x80467b5b in uhub_explore (dev=0xff0004591400) at /red/public/freebsd/sources/stable/sys/dev/usb/uhub.c:523 #21 0x8046f391 in usb_discover (v=Variable "v" is not available. ) at /red/public/freebsd/sources/stable/sys/dev/usb/usb.c:724 #22 0x8046fc61 in usb_event_thread (arg=Variable "arg" is not available. ) at /red/public/freebsd/sources/stable/sys/dev/usb/usb.c:440 #23 0x804d05bd in fork_exit (callout=0x8046fbe5 , arg=0xff0004598d00, frame=0xfffef5b6ac80) at /red/public/freebsd/sources/stable/sys/kern/kern_fork.c:810 #24 0x8077f16e in fork_trampoline () at /red/public/freebsd/sources/stable/sys/amd64/amd64/exception.S:455 > The problem is repeatable. It only happens when I insert the thumb drive > into a running system. If I boot with the thumb drive present, everything > is fine. > > Any help is greatly appreciated. > > Cheers, > > -- Norbert Papke. > > = > > # uname -a > FreeBSD proven.lan 7.2-STABLE FreeBSD 7.2-STABLE #0 r191841: Tue May 5 > 21:13:21 PDT 2009 > npa...@proven.lan:/usr/obj/red/public/fr
7.2-STABLE: Inserting USB device causes Fatal Trap 12
Inserting a USB thumb drive into a running sytem result in a "Fatal trap 12: page fault while in kernel mode". Unfortunately, I was not able to save a core (not entirely sure why, I'll investigate separately). I have manually copied the backtrace: usb_transfer_complete bus_dmamap_load usbd_transfer usbd_do_request_flags_pipe usbd_do_request_flags usbd_get_string_desc usbd_get_string usbd_devinfo_vp usbd_devinfo usbd_new_device uhub_explore usb_event_thread fork_exit for_trampine The problem is repeatable. It only happens when I insert the thumb drive into a running system. If I boot with the thumb drive present, everything is fine. Any help is greatly appreciated. Cheers, -- Norbert Papke. = # uname -a FreeBSD proven.lan 7.2-STABLE FreeBSD 7.2-STABLE #0 r191841: Tue May 5 21:13:21 PDT 2009 npa...@proven.lan:/usr/obj/red/public/freebsd/sources/stable/sys/PROVEN amd64 = Kernel config: include GENERIC ident PROVEN options KDB # kernel debugger (just in case) options KDB_TRACE options DDB # kernel debugger (just in case) options WITNESS options WITNESS_SKIPSPIN options IPSEC device crypto device stf # for IPv6 tunneling # keep kernel messages from different cpus separate options PRINTF_BUFR_SIZE=64 option SC_HISTORY_SIZE=2000 options SC_NORM_ATTR=(FG_GREEN|BG_BLACK) options SC_NORM_REV_ATTR=(FG_YELLOW|BG_GREEN) options SC_KERNEL_CONS_ATTR=(FG_LIGHTRED|BG_BLACK) options SC_KERNEL_CONS_REV_ATTR=(FG_BLACK|BG_RED) # Alternate Queuing of network packets options ALTQ options ALTQ_CBQ# Class Bases Queuing (CBQ) options ALTQ_RED# Random Early Detection (RED) options ALTQ_RIO# RED In/Out options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC) options ALTQ_PRIQ # Priority Queuing (PRIQ) options ALTQ_NOPCC # Required for SMP build # load as module for debugging nodevicere # RealTek 8139C+/8169/8169S/8110S = Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.2-STABLE #0 r191841: Tue May 5 21:13:21 PDT 2009 npa...@proven.lan:/usr/obj/red/public/freebsd/sources/stable/sys/PROVEN WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU E8500 @ 3.16GHz (3155.59-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x1067a Stepping = 10 Features=0xbfebfbff Features2=0x408e3fd,XSAVE> AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 2 usable memory = 4279189504 (4080 MB) avail memory = 4097724416 (3907 MB) ACPI APIC Table: <100808 APIC1053> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 cryptosoft0: on motherboard acpi0: <100808 XSDT1053> on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of ffc0, 30 (3) failed acpi0: reservation of fee0, 1000 (3) failed acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, bff0 (3) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_hpet0: iomem 0xfed0-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xc000-0xc0ff mem 0xd000-0xdfff,0xfe9f-0xfe9f irq 16 at device 0.0 on pci1 drm0: on vgapci0 info: [drm] MSI enabled 1 message(s) vgapci0: child drm0 requested pci_enable_busmaster info: [drm] Initialized radeon 1.29.0 20080528 hdac0: mem 0xfe9ec000-0xfe9e irq 17 at device 0.1 on pci1 hdac0: HDA Driver Revision: 20090329_0131 hdac0: [ITHREAD] uhci0: port 0xbc00-0xbc1f irq 16 at device 26.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xb880-0xb89f irq 21 at device 26.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xb800-0xb81f irq 19 at device 26.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xfe8fe000-0xfe8fe3ff irq 18 at device 26.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: c
Re: dri + ATI: dramatic performance slowdown
On April 22, 2009, Robert Noland wrote: > On Wed, 2009-04-22 at 17:39 -0700, Norbert Papke wrote: > > 0x0/0x1 BIOS write-back set-by-firmware active > > 0x1/0x4000 BIOS write-back set-by-firmware active > > 0xc000/0x4000 BIOS uncacheable set-by-firmware active > > MTRR is failing in many cases... It seems that your BIOS is doing what > both of my newer machines are doing and setting a global range to > write-back. I'm also guessing that 0xc000 is your framebuffer. Correct. The framebuffer starts at 0xd000, still covered by that last range. > We > aren't allowed to overlap either of these ranges with a write combined > region according to the specs. We would have to handle > splitting/merging regions which we don't currently do. I looked at this > just the other day, but it is reasonably complex to make that work right > and accommodate all of the merging/splitting of regions. > > We are allowed to use PAT on either of these types of regions to enable > write-combining. The drm code already does this for some allocations > that are not mapped to user space. The problem with PAT is that all > mappings of a given region need to have the same type and we don't > currently have any way to specify that for user space mappings. This is > fwiw, the last of Nvidia's feature requests as well. I've started > looking at it, but I have a lot of learning to do on the vm system > still. Thanks for taking the time to explain. Your posts are always very informative. I am learning quite a lot about the complexities involved. There is yet another thing I don't understand. With other graphics cards, including my G45 internal graphics adaptor, the /dev/agpgart device is created. I don't see this device with the Radeon card. Is this expected because it is not needed for PCIe? Cheers, -- Norbert Papke. npa...@acm.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: dri + ATI: dramatic performance slowdown
On April 21, 2009, Robert Noland wrote: > On Tue, 2009-04-21 at 16:04 +0200, Oliver Lehmann wrote: > > 0xd800/0x800 drm write-combine active > > Ok, looks like MTRR is working for you, so that isn't it... > > robert. Hi Robert, Should there be a write-combined range present for all (ATI) cards? I don't see such an entry (please see below). My 2D performance seems reasonable. I have no complaints, just wondering. Cheers, -- Norbert Papke. npa...@acm.org # dmesg | grep drm drm0: on vgapci0 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] Initialized radeon 1.29.0 20080528 info: [drm] Setting GART location based on new memory map info: [drm] Loading RV635 CP Microcode info: [drm] Loading RV635 PFP Microcode info: [drm] Resetting GPU info: [drm] writeback test succeeded in 1 usecs # memcontrol list 0x0/0x1 BIOS write-back fixed-base fixed-length set-by-firmware active 0x1/0x1 BIOS write-back fixed-base fixed-length set-by-firmware active 0x2/0x1 BIOS write-back fixed-base fixed-length set-by-firmware active 0x3/0x1 BIOS write-back fixed-base fixed-length set-by-firmware active 0x4/0x1 BIOS write-back fixed-base fixed-length set-by-firmware active 0x5/0x1 BIOS write-back fixed-base fixed-length set-by-firmware active 0x6/0x1 BIOS write-back fixed-base fixed-length set-by-firmware active 0x7/0x1 BIOS write-back fixed-base fixed-length set-by-firmware active 0x8/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x84000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x88000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x8c000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x9/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x94000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x98000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x9c000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0xa/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xa4000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xa8000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xac000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xb/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xb4000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xb8000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xbc000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xc/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc1000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc2000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc3000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc4000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc5000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc6000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc7000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc8000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc9000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xca000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xcb000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xcc000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xcd000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xce000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xcf000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xd1000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xd2000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xd3000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xd4000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xd5000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xd6000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xd7000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xd8000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xd9000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xda000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xdb000/0x1000 BIOS uncacheable fixed-base fixed-length
Re: powerd broken
On April 4, 2009, Robert Noland wrote: > On Sat, 2009-04-04 at 10:01 -0700, Norbert Papke wrote: > > Hi Robert, > > > > On April 3, 2009, Robert Noland wrote: > > > Use a radeon? ;( > > > > Is there any particular model of Radeon PCIe that you would recommend? > > Most all of them should work ok... You won't have 3d on r600+ just yet, > but... I'm running on an x1650 right now. After a quick check, everything available retail (locally) is r600 or newer. I'll keep an eye open for an older second hand card. Thanks for information and all your hard work. -- Norbert Papke. npa...@acm.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: powerd broken
Hi Robert, On April 3, 2009, Robert Noland wrote: > Use a radeon? ;( Is there any particular model of Radeon PCIe that you would recommend? Cheers, -- Norbert Papke. npa...@acm.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Possible UDP deadlock/panic fix
On September 22, 2008, Robert Watson wrote: > your confirmation as to whether or not this corrects the > specific symptoms you are seeing would be very helpful. 14+ hours under load with the patch and all is well. Thanks! -- Norbert. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Possible UDP related deadlock in 7.1-PRERELEASE
On September 17, 2008, Robert Watson wrote: > On Mon, 15 Sep 2008, Norbert Papke wrote: > > With WITNESS enabled, I now experience panics and could not follow your > > instructions. There is no core dump. The following gets logged to > > /var/log/messages: > > > > shared lock of (rw) udpinp @ /usr/src/sys/netinet/udp_usrreq.c:864 > > while exclusively locked from /usr/src/sys/netinet6/udp6_usrreq.c:940 > > panic: share->excl > > KDB: stack backtrace: > > db_trace_self_wrapper(c06fda7c,f6b96978,c052046a,c06fbb5d,c07695c0,...) > > at db_trace_self_wrapper+0x26 > > kdb_backtrace(c06fbb5d,c07695c0,c06febd1,f6b96984,f6b96984,...) at > > kdb_backtrace+0x29 > > panic(c06febd1,c070c409,3ac,c0709eee,360,...) at panic+0xaa > > witness_checkorder(ccd5209c,1,c0709eee,360,8,...) at > > witness_checkorder+0x17c > > _rw_rlock(ccd5209c,c0709eee,360,c07780e0,cd4652c8,...) at _rw_rlock+0x2a > > udp_send(d3942000,0,c580f400,c68faa00,0,...) at udp_send+0x197 > > udp6_send(d3942000,0,c580f400,c68faa00,0,...) at udp6_send+0x140 > > sosend_generic(d3942000,c68faa00,f6b96be8,0,0,...) at > > sosend_generic+0x50d sosend(d3942000,c68faa00,f6b96be8,0,0,...) at > > sosend+0x3f > > kern_sendit(cd465230,f,f6b96c64,0,0,...) at kern_sendit+0x106 > > sendit(0,871b9fe,0,c68faa00,1c,...) at sendit+0x182 > > sendto(cd465230,f6b96cfc,18,cd465230,c072bab8,...) at sendto+0x4f > > syscall(f6b96d38) at syscall+0x293 > > > > Note that I do not use IPv6, none of my network interfaces is configured > > for it. > To clarify what you're seeing a bit: some applications that are adapted to > use both IPv4 and IPv6 open combined v4/v6 sockets. This is possible > because there is a section of the IPv6 address space that "contains" the v4 > address space. When an application sends to a v4 address using a v6 socket > (wave hands here) the kernel actually calls the v4 UDP code from within the > v6 socket code, and it turns out there's a locking bug in that path. So > likely some application you are running is using this compatibility mode, > and hence triggering this bug. Thank you for this explanation. It helps my peace of mind to understand the context. > I need to think for a bit about the best way to fix it (it's easy to hack > around, but obviously "hacking around" is not the desired solution), and > I'll get back to you later this week with a patch. I am certainly happy to try a patch when it becomes available. > For my reference, it would probably be helpful to know what the application > is, since apparently this didn't arise in our testing. You can type "show > pcpu" at the DDB prompt after this panic to show what thread is currently > running. This may be difficult. I was not entirely clear in my description of the panic. I experience spontaneous reboots when the panic is occurs. DDB is not invoked, nor is a core generated. My suspicion is that "ktorrent", the KDE3 torrent client, is triggering this condition. When I broke into DDB with a non-WITNESS kernel, I observed that one of the "ktorrent" threads was locked on "*udpinp". Additionally, "hald", "ntpd" and the NIC interrupt thread had "*udp" locked. Not sure if this is information is helpful. Cheers, -- Norbert. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Possible UDP related deadlock in 7.1-PRERELEASE
On September 15, 2008, Gavin Atkinson wrote: > On Sun, 2008-09-14 at 12:19 -0700, Norbert Papke wrote: > > Symptoms: > > > > * I can trigger this lockup reliably by starting ktorrent. After a short > > while (one to two minutes), it locks up. Other commands, e.g., netstat, > > also lock up. > > * The console generates "nfe0: watchdog timeout" error messages. > > * The system becomes unusable and must be rebooted. > > > > Attempted Diagnosis: > > > > If I break into DDB, the 'ps' output shows a number of processes that > > seem to be locked related to udp. > > > > [irq18:dc0]L *udp > > ktorrent L *udpinp > > hald L *udp > > ntpd L *udp > > > > Unfortunately, I am rapidly getting out of my depth here. I have no idea > > how to go about further analyzing this problem and would appreciate help. > > Can you add: > options WITNESS > options WITNESS_SKIPSPIN > > to your kernel, recompile and wait for the problem to happen again? > When it does, from the debugger issue "sh alllocks" and make a note of > the output? With WITNESS enabled, I now experience panics and could not follow your instructions. There is no core dump. The following gets logged to /var/log/messages: shared lock of (rw) udpinp @ /usr/src/sys/netinet/udp_usrreq.c:864 while exclusively locked from /usr/src/sys/netinet6/udp6_usrreq.c:940 panic: share->excl KDB: stack backtrace: db_trace_self_wrapper(c06fda7c,f6b96978,c052046a,c06fbb5d,c07695c0,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c06fbb5d,c07695c0,c06febd1,f6b96984,f6b96984,...) at kdb_backtrace+0x29 panic(c06febd1,c070c409,3ac,c0709eee,360,...) at panic+0xaa witness_checkorder(ccd5209c,1,c0709eee,360,8,...) at witness_checkorder+0x17c _rw_rlock(ccd5209c,c0709eee,360,c07780e0,cd4652c8,...) at _rw_rlock+0x2a udp_send(d3942000,0,c580f400,c68faa00,0,...) at udp_send+0x197 udp6_send(d3942000,0,c580f400,c68faa00,0,...) at udp6_send+0x140 sosend_generic(d3942000,c68faa00,f6b96be8,0,0,...) at sosend_generic+0x50d sosend(d3942000,c68faa00,f6b96be8,0,0,...) at sosend+0x3f kern_sendit(cd465230,f,f6b96c64,0,0,...) at kern_sendit+0x106 sendit(0,871b9fe,0,c68faa00,1c,...) at sendit+0x182 sendto(cd465230,f6b96cfc,18,cd465230,c072bab8,...) at sendto+0x4f syscall(f6b96d38) at syscall+0x293 Note that I do not use IPv6, none of my network interfaces is configured for it. Also, since I enabled WITNESS, I get the following logged during system startup: Enabling pf. lock order reversal: 1st 0xc09af92c pf task mtx (pf task mtx) @ /usr/src/sys/modules/pf/../../contri b/pf/net/pf_ioctl.c:1394 2nd 0xc07b4d68 ifnet (ifnet) @ /usr/src/sys/net/if.c:1558 KDB: stack backtrace: db_trace_self_wrapper(c06fda7c,f4914a60,c0552c75,c06fed11,c07b4d68,...) at db_tr ace_self_wrapper+0x26 kdb_backtrace(c06fed11,c07b4d68,c0703ca2,c0703ca2,c0703c73,...) at kdb_backtrace +0x29 witness_checkorder(c07b4d68,9,c0703c73,616,572,...) at witness_checkorder+0x5e5 _mtx_lock_flags(c07b4d68,0,c0703c73,616,c0104414,...) at _mtx_lock_flags+0x34 ifunit(c6ef5c20,0,c09adfb5,572,c0703a71,...) at ifunit+0x2f pfioctl(c566ce00,c0104414,c6ef5c20,3,c60c38c0,...) at pfioctl+0x2b43 devfs_ioctl_f(c588bb94,c0104414,c6ef5c20,c54bb900,c60c38c0,...) at devfs_ioctl_f +0xe6 kern_ioctl(c60c38c0,3,c0104414,c6ef5c20,100,...) at kern_ioctl+0x243 ioctl(c60c38c0,f4914cfc,c,c0718d59,c072b350,...) at ioctl+0x134 syscall(f4914d38) at syscall+0x293 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x281ab6f3, esp = 0xbfbfde3c, ebp = 0xbfbfde68 --- pf enabled I tried to unload 'pf' to see if it was the culprit. However, even without pf loaded, I experience the panic. Is there anything else I can try to provide better insight into what might be going on? Cheers, -- Norbert. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Possible UDP related deadlock in 7.1-PRERELEASE
Environment: * i386, 7.1 Prerelease (updated today) with a custom UP kernel, ULE scheduler * KDE 3.5.10 * NIC does not share interrupts with another device * See below for configuration files Symptoms: * I can trigger this lockup reliably by starting ktorrent. After a short while (one to two minutes), it locks up. Other commands, e.g., netstat, also lock up. * The console generates "nfe0: watchdog timeout" error messages. * The system becomes unusable and must be rebooted. Attempted Work-arounds: * I have replaced the NIC. No change except now the console now generates "dc0: watchdog timeout". * I have tried an SMP kernel. No change. Attempted Diagnosis: If I break into DDB, the 'ps' output shows a number of processes that seem to be locked related to udp. [irq18:dc0]L *udp ktorrent L *udpinp hald L *udp ntpd L *udp Unfortunately, I am rapidly getting out of my depth here. I have no idea how to go about further analyzing this problem and would appreciate help. Cheers, -- Norbert. /boot/loader.conf: loader_logo=beastie verbose_loading="YES" cpufreq_load="YES" geom_gpt_load="YES" hwpmc_load="YES" # File systems cd9660_load="YES" msdosfs_load="YES" # NIC supprt (MII provides common controller code) miibus_load="YES" if_dc_load=YES pflog_load="YES" procfs_load="YES" # USB ugen_load="YES" uhid_load="YES" ukbd_load="YES" umass_load="YES" ums_load="YES" # Linux linprocfs_load="YES" linux_load="YES" nvidia_load="YES" pseudo_load="YES" random_load="YES" snd_hda_load="YES" # SYSV support sysvmsg_load="YES" sysvsem_load="YES" sysvshm_load="YES" # For gamin kern.maxfiles="25000" # For ZFS vm.kmem_size="512M" vm.kmem_size_max="512M" vfs.zfs.arc_max="160M" vfs.zfs.arc_min="100M" vfs.zfs.vdev.cache.size="5M" vfs.zfs.debug=1 vfs.zfs.prefetch_disable="1" Kernel Config: machine i386 cpu I686_CPU ident NGP makeoptions DEBUG=-g# Build kernel with gdb(1) debug symbols options KDB # kernel debugger (just in case) options KDB_TRACE options DDB # kernel debugger (just in case) options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET# InterNETworking options INET6 # IPv6 communications protocols options SCTP# Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL# Enable gjournal-based UFS journaling options MD_ROOT # MD is a potential root device options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options KTRACE # ktrace(1) support options STACK # stack(9) support options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV# install a CDEV entry in /dev options AHC_REG_PRETTY_PRINT# Print register bitfields in debug # output. Adds ~128k to driver. options AHD_REG_PRETTY_PRINT# Print register bitfields in debug # output. Adds ~215k to driver. options ADAPTIVE_GIANT # Giant mutex is adaptive. options STOP_NMI# Stop CPUS using NMI instead of IPI options HWPMC_HOOKS # hwpmc(4) performance measurements support. also needs device or kernel module #option KVA_PAGES=512 # bigger kernel address space (2GB) for ZFS (conflicts with nvidia-driver) # Alternate Queuing of network packets options ALTQ options ALTQ_CBQ# Class Bases Queuing (CBQ) options ALTQ_RED# Random Early Detection (RED) options ALTQ_RIO# RED In/Out options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC) options ALTQ_PRIQ # Priority Queuing (PRIQ) #optionsALTQ_NOPCC # Require
Re: Apache seg faults -- Possible problem with libc? [solved]
On May 17, 2008, Norbert Papke wrote: > Environment: FreeBSD 7.0 Stable (as of Apr 30), apache-2.0.63 > > I am experiencing Apache crashes on a fairly consistent and frequent basis. > The crash occurs in strncmp(). To help with the diagnosis, I have rebuilt > libc with debug symbols. Here is a typical stack dump: > > #0 strncmp () at /usr/src/lib/libc/i386/string/strncmp.S:69 > #1 0x2832558c in getenv (name=0x28338648 "TZ") > at /usr/src/lib/libc/stdlib/getenv.c:144 > #2 0x2830ce3a in tzset_basic (rdlocked=0) > at /usr/src/lib/libc/stdtime/localtime.c:1013 > #3 0x2830d42f in localtime (timep=0xbfbfc1d4) > at /usr/src/lib/libc/stdtime/localtime.c:1158 The problem is not in libc. Instead it is caused by Apache's PHP5 module. Under certain circumstances, the module will allocate memory for an environment variable, pass this variable to putenv(), and then immediately free the memory. putenv(), of course, requires the environment variable to remain valid. The seg fault occurs at a subsequent getenv() invocation. I have contacted the PHP5 maintainer with this information. Best, -- Norbert. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Apache seg faults -- Possible problem with libc?
Environment: FreeBSD 7.0 Stable (as of Apr 30), apache-2.0.63
I am experiencing Apache crashes on a fairly consistent and frequent basis.
The crash occurs in strncmp(). To help with the diagnosis, I have rebuilt
libc with debug symbols. Here is a typical stack dump:
#0 strncmp () at /usr/src/lib/libc/i386/string/strncmp.S:69
#1 0x2832558c in getenv (name=0x28338648 "TZ")
at /usr/src/lib/libc/stdlib/getenv.c:144
#2 0x2830ce3a in tzset_basic (rdlocked=0)
at /usr/src/lib/libc/stdtime/localtime.c:1013
#3 0x2830d42f in localtime (timep=0xbfbfc1d4)
at /usr/src/lib/libc/stdtime/localtime.c:1158
#4 0x28220e6c in explode_time () from /usr/local/lib/apache2/libapr-0.so.9
#5 0x28220f13 in apr_time_exp_lt ()
from /usr/local/lib/apache2/libapr-0.so.9
#6 0x08070227 in cached_explode ()
#7 0x28374519 in log_request_time ()
from /usr/local/libexec/apache2/mod_log_config.so
#8 0x2837358d in config_log_transaction ()
from /usr/local/libexec/apache2/mod_log_config.so
#9 0x28373654 in multi_log_transaction ()
from /usr/local/libexec/apache2/mod_log_config.so
#10 0x08074519 in ap_run_log_transaction ()
#11 0x08063d62 in ap_process_request ()
#12 0x0805e718 in ap_process_http_connection ()
#13 0x08070817 in ap_run_process_connection ()
#14 0x08064fde in child_main ()
#15 0x08065283 in make_child ()
#16 0x08065a51 in ap_mpm_run ()
#17 0x0806bfb8 in main ()
Frames 0 - 4 are present in all crash scenarios. However, similar crashes
occur with different paths into explode_time().
(gdb) frame 0
#0 strncmp () at /usr/src/lib/libc/i386/string/strncmp.S:69
69 movb(%eax),%bl
(gdb) p/x $eax
$70 = 0x883a4bc
(gdb) p/x *$eax
Cannot access memory at address 0x883a4bc
eax contains the first string to be compared. This is an invalid memory
location.
(gdb) frame 1
#1 0x2832558c in getenv (name=0x28338648 "TZ")
at /usr/src/lib/libc/stdlib/getenv.c:144
144 if (strncmp(nameValue, name, nameLen) == 0 &&
nameValue[nameLen] == '=')
Current language: auto; currently c
(gdb) p envVarsTotal
$71 = 57
(gdb) p envVars[56]
$72 = {nameLen = 4294967295, valueSize = 4294967295,
name = 0x883a4bc ,
value = 0x0, active = true, putenv = true}
(gdb) p envVars[55]
$73 = {nameLen = 16, valueSize = 4,
name = 0x8303f20 "KDE_FULL_SESSION=true",
value = 0x8303f31 "true",
active = true, putenv = false}
Because of the inline functions used in getenv(), gdb's location information
is somewhat incomplete. However, I believe that line 144 was called by
__findenv(), The fault occurs when __findenv() tries to access what appears
to be an invalid environment variable. Most likely, envVarsTotal is too big
by one.
For reference, here is the code for __findenv(). The calling line is marked.
static inline char *
__findenv(const char *name, size_t nameLen, int *envNdx, bool onlyActive)
{
int ndx;
/*
* Find environment variable from end of array (more likely to be
* active). A variable created by putenv is always active or it is not
* tracked in the array.
*/
for (ndx = *envNdx; ndx >= 0; ndx--)
if (envVars[ndx].putenv) {
/* ==> */ if (strncmpeq(envVars[ndx].name, name, nameLen)) {
*envNdx = ndx;
return (envVars[ndx].name + nameLen +
sizeof ("=") - 1);
}
} else if ((!onlyActive || envVars[ndx].active) &&
(envVars[ndx].nameLen == nameLen &&
strncmpeq(envVars[ndx].name, name, nameLen))) {
*envNdx = ndx;
return (envVars[ndx].value);
}
return (NULL);
}
which is called by
char *
getenv(const char *name)
{
int envNdx;
size_t nameLen;
/* Check for malformed name. */
if (name == NULL || (nameLen = __strleneq(name)) == 0) {
errno = EINVAL;
return (NULL);
}
/*
* Find environment variable via environ if no changes have been made
* via a *env() call or environ has been replaced by a running program,
* otherwise, use the rebuilt environment.
*/
if (envVars == NULL || environ != intEnviron)
return (__findenv_environ(name, nameLen));
else {
envNdx = envVarsTotal - 1;
/* ==> */ return (__findenv(name, nameLen, &envNdx, true));
}
}
Any suggestions on how I could nail down the cause?
Cheers,
-- Norbert.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.3-RELEASE panic
On January 23, 2008, John Baldwin wrote: > On Monday 21 January 2008 04:51:54 pm Kris Kennaway wrote: > > Petr Holub wrote: > > > Hi, > > > > > > I've just updated the 6.2-RELEASE to 6.3-RELEASE using freebsd-update > > > as described in daemonology blog. > > > > > > While removing the old packages using > > > pkg_delete -af > > > I've tried to stop all the deamons from /usr/local/etc/rc.d and > > > got the following panic (hand transcribed from a photo - I don't have > > > that machine enabled for remote debugging). Panic seems to be > > > deterministic when stopping those scripts (verified by subsequent > > > attempts while pkg_delete was not running). > > > > > > (kgdb) bt > > > #0 0xc06a46a6 in doadump () > > > #1 0xc06a4b76 in boot () > > > #2 0xc06a4e0c in panic () > > > #3 0xc090d1b4 in trap_fatal () > > > #4 0xc090cf1b in trap_pfault () > > > #5 0xc090cb59 in trap () > > > #6 0xc08f9fea in calltrap () > > > #7 0xc073fa6f in in_delmulti () > > > #8 0xc0748e15 in ip_freemoptions () > > > #9 0xc07414cc in in_pcbdetach () > > > #10 0xc075a0ee in udp_detach () > > > #11 0xc06de0b8 in soclose () > > > #12 0xc06cd83b in soo_close () > > > #13 0xc0683ffc in fdrop_locked () > > > #14 0xc0683f25 in fdrop () > > > #15 0xc0682553 in closef () > > > #16 0xc067f8e7 in kern_close () > > > #17 0xc067f6d8 in close () > > > #18 0xc090d4cb in syscall () > > > #19 0xc08fa03f in Xint0x80_syscall () > > > #20 0x0033 in ?? () > > > Previous frame inner to this frame (corrupt stack?) > > > > Can you obtain a trace against the kernel.symbols? > > I've been seeing this panic (and several variations of) for quite a while > on 6.x. It appears that a socket is being double-closed somehow. I > usually see it during exit1() when a process' file descriptor table is > being freed. I've spent a lot of time looking for a fd reference count > leak or some such but haven't found one yet. :( I've also seen panics > with vnodes having a ref cnt underflow in vrele or vput, so I've wondered > if it's a fd-level bug that affects both vnodes and sockets rather than > separate socket and vnode bugs. For comparison, here is the callstack from the panic reported in kern/116077. The PR has symbolic information. #0 doadump () #1 0xc055293e in boot #2 0xc0552c95 in panic #3 0xc06e6232 in trap_fatal #4 0xc06e5f3b in trap_pfault #5 0xc06e5b51 in trap #6 0xc06d0b1a in calltrap () #7 0xc05e3e6f in in_delmulti #8 0xc05ed8e9 in ip_freemoptions #9 0xc05e5d6c in in_pcbdetach #10 0xc05fee96 in udp_detach #11 0xc058e710 in soclose #12 0xc057db3f in soo_close #13 0xc052fd9c in fdrop_locked #14 0xc052fcc5 in fdrop #15 0xc052e263 in closef #16 0xc052d253 in fdfree #17 0xc0536b4b in exit1 #18 0xc05366b0 in sys_exit #19 0xc06e6577 in syscall #20 0xc06d0b6f in Xint0x80_syscall () #21 0x0033 in ?? () It is also triggered when a multi-cast client shuts down. The patch in the PR fixes this issue for me. I have been running with it since November. Cheers. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.3-RELEASE panic
On January 21, 2008, Petr Holub wrote: > Hi, > > I've just updated the 6.2-RELEASE to 6.3-RELEASE using freebsd-update > as described in daemonology blog. > > While removing the old packages using > pkg_delete -af > I've tried to stop all the deamons from /usr/local/etc/rc.d and > got the following panic (hand transcribed from a photo - I don't have that > machine enabled for remote debugging). Panic seems to be deterministic > when stopping those scripts (verified by subsequent attempts while > pkg_delete was not running). > > Stopping mdnsd. Possibly it is related to http://www.freebsd.org/cgi/query-pr.cgi?pr=116077 That particular problem manifests itself under similar circumstances and the callstack looks similar too. Jerry Toung's patch in the PR fixes things for me. Cheers. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
6.2-RC1 /boot/loader | dhclient
Hi list, i just want to note that after updating to RC1 /boot/loader still refuses to boot with Grub. -> endless rebooting chainloading works though, fortunately. dhclient shows a similar behavior to that Steve Franks reported Nov 13 on -CURRENT. After 20 min of inactivity the route gets flushed on my laptop, calling dhclient wi0 from the command line remedies the problem until it gets flushed again. isc-dhclient does not exhibit this behavior, the route never gets flushed. And btw, isc-dhclient seems to be started so early in the boot-process that its pidfile in /var/run gets deleted later during boot. I have not checked if this happens to dhclient as well. regards, --> auge -- 1:15AM up 105 days, 2:19, 0 users, load averages: 0.00, 0.00, 0.00 In my end is my beginning. -- Mary Stuart, Queen of Scots ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Boot FreeBSD from grub
On Thu, Nov 02, 2006 at 12:50:25PM +0800, Sun Zongjun-E5739C wrote: > > Thanks for your kind support. I add root(hd0, 0) but grub reports that can't > find file? > Here is the output of fdisk > > Device boot System > /dev/hda1 *FreeBSD > /dev/hda2Linux > > Hi, i assume you are using Grub on Linux as you installed it after FreeBSD. I don't know if your Grub version supports the UFS2 filesystem but you can always "chainload" FreeBSD. title FreeBSD --> The Power to Serve root (hd0,0,a) chainloader +1 --> auge -- 6:35AM up 87 days, 7:39, 0 users, load averages: 0.00, 0.00, 0.00 An editor is one who separates the wheat from the chaff and prints the chaff. -- Adlai Stevenson ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /boot/loader failed ....
On Mon, Oct 30, 2006 at 01:28:31AM +0100, Norbert Augenstein wrote: > No prblems with the new em code here:) > > regards, > --> auge > Hi all, i have some mailproblem here, sorry:) My update to RELENG_6 yesterday ends in this endless rebooting problem caused by /boot/loader ... again. em is fine here:) --> auge -- 1:10PM up 84 days, 14:14, 0 users, load averages: 0.01, 0.01, 0.00 I do not know whether I was then a man dreaming I was a butterfly, or whether I am now a butterfly dreaming I am a man. -- Chuang-tzu ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
/boot/loader failed ....
No prblems with the new em code here:) regards, --> auge -- 1:20AM up 84 days, 2:24, 0 users, load averages: 0.00, 0.00, 0.00 Life is the urge to ecstasy. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.2-PRE /boot/loader
On Tue, Oct 03, 2006 at 06:55:39PM +0200, Norbert Augenstein wrote: > Hi list, > i have just updated to 6.2-PRERELEASE and GRUB is unable to use > the new /boot/loader. Ending in an endless loop rebooting after > selecting FreeBSD. > As a workaround it was possible to chainload FreeBSD. > Further investigation shows that /boot/loader.old is woking. > > So what can cause the new loader to fail? > I have not set CFLAGS / CPUTYPE in /etc/make.conf > > No other problems , em device is working fine here:) > Hi list, me again after updating my pc (RELENG_6) last night and everything went fine i updated my laptop as well. Unfortunately my laptop ran into this constantly rebooting problem caused by the new /boot/loader. And again, /boot/loader.old works fine on my laptop. Moreover, while booting i get the following message: sysctl: unknown oid 'net.inet6.ip6.auto_linklocal' due to missing inet6 support in my kernel. regards, --> auge -- 5:00PM up 72 days, 17:04, 0 users, load averages: 0.00, 0.00, 0.00 No yak too dirty; no dumpster too hollow. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
6.2-PRE /boot/loader
Hi list, i have just updated to 6.2-PRERELEASE and GRUB is unable to use the new /boot/loader. Ending in an endless loop rebooting after selecting FreeBSD. As a workaround it was possible to chainload FreeBSD. Further investigation shows that /boot/loader.old is woking. So what can cause the new loader to fail? I have not set CFLAGS / CPUTYPE in /etc/make.conf No other problems , em device is working fine here:) regards, --> auge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Too dumb to mount as non privileged user
Jona Joachim wrote: > Make sure the cd9660 kernel module is loaded before you mount a CD as > user. The first time you mount a CD the module is loaded but a user is > not allowed to load a kernel module. You may want to load the module > during boot time by putting a corresponding entry in /boot/loader.conf > > --jona Thanks, that's it! Norbert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Too dumb to mount as non privileged user
Hello, using a 6.2-PRERELEASE I am not able to let a normal user mount a cdrom. I have tried the following: o vfs.usermount=1 to sysctl.conf o added group usermounters o added user to usermounters o own acd0 root:usermounters to devfs.conf o perm acd0 0660 to devfs.conf o created directory with ownership of non privileged user o reboot Trying to mount as user to the users own directory yields 'operation not permitted' error. So I changed the ownerships to 0666 but this didn't help either. I doublechecked sysctl, groups and ownerships. Can please anybody give me a hint? TIA Norbert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
gnutls
Hi all, i have updated gnutls and see libgnutls-extra.so.13 libgnutls-extra.so.13 libgnutls.so.13 before i update all ports denpend on it, shouldn't that read *.so.16 ?? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATAPICAM in RELENG_6 sometimes swaps drives
On Wed, Jun 28, 2006 at 12:06:38AM +0300, Dmitry Pryanishnikov wrote:
>
> Hello!
>
> My machine (running RELENG_6) has 2 ATAPI drives attached to the second
> channel of Intel ICH4 built-in ATA controller ata1 (NEC DVD-RW as a master
> and AOPEN CD-RW as a slave). Of course their ATAPI devices always show up
> in the fixed order:
>
> acd0: DVDR at ata1-master UDMA33
> acd1: CDRW at ata1-slave UDMA33
>
> However, ATAPICAM devices sometimes show in the same order:
>
> cd0 at ata1 bus 0 target 0 lun 0
> cd0: <_NEC DVD_RW ND-3520A 1.04> Removable CD-ROM SCSI-0 device
> cd0: 33.000MB/s transfers
> cd0: Attempt to query device size failed: NOT READY, Medium not present
> cd1 at ata1 bus 0 target 1 lun 0
> cd1: Removable CD-ROM SCSI-0 device
> cd1: 33.000MB/s transfers
> cd1: Attempt to query device size failed: NOT READY, Medium not present
>
> and sometimes get swapped:
>
> cd0 at ata1 bus 0 target 1 lun 0
> cd0: Removable CD-ROM SCSI-0 device
> cd0: 33.000MB/s transfers
> cd0: Attempt to query device size failed: NOT READY, Medium not present
> cd1 at ata1 bus 0 target 0 lun 0
> cd1: <_NEC DVD_RW ND-3520A 1.04> Removable CD-ROM SCSI-0 device
> cd1: 33.000MB/s transfers
> cd1: Attempt to query device size failed: NOT READY, Medium not present
>
> I consider this behaviour as being quite weird and misleading. E.g., it
> doesn't allow to set up correctly a couple of useful links from
> /etc/devfs.conf:
>
> link cd0sdvdrom
> link cd1 scdrom
>
> (sometimes scdrom points not to CD-RW, but to DVD-RW drive). What's the
> reason of this weirdness, can it be fixed?
>
> Sincerely, Dmitry
Hi Dimitry,
similar problem here, as workaround i placed
hint.cd.0.target="0"
to /boot/loader.conf
Regards,
--> auge
Norbert Augenstein
--
12:10AM up 41 mins, 1 user, load averages: 0.00, 0.00, 0.00
WARNING TO ALL PERSONNEL:
Firings will continue until morale improves.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
boot order changed (atapicam)
Hi all, after recent buildworld the boot order of my atapi devices changed for no reason. [EMAIL PROTECTED] ~]% camcontrol devlist at scbus1 target 0 lun 0 (pass1,cd1) at scbus1 target 1 lun 0 (pass0,cd0) Toshiba DVD is on ata1-master and used to be "cd0" regards, --> auge -- 4:35AM up 3 days, 9:55, 0 users, load averages: 0.00, 0.00, 0.00 Boling's postulate: If you're feeling good, don't worry. You'll get over it. ___ 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.1 Release day
On Thu, Apr 06, 2006 at 01:41:23PM +0200, Erik Trulsson wrote: > On Thu, Apr 06, 2006 at 12:20:09PM +0300, SoHo.NET wrote: > > Dear Sir, > > > > Can you notify me with date of FreeBSD 6.1 RELEASE? > > > > It have to be released in 1 or 2 weeks after Announcement 20 march 2006 As > > I can see here http://www.freebsd.org/releases/6.1R/schedule.html > > I don't think the final release date has been decided yet. > As you note it was originally planned to be released on March 20, but the > schedule has slipped quite a bit (just as it did for every previous release > too.) > > Personally I would *guess* that it will be released about 1-2 weeks from now, > but that is only my personal guess and I do not have any special inside > information on this matter. > 6.1 is branched, but i would like to see some ReleaseCandidates first. regards, --> auge -- 2:55PM up 62 days, 6:06, 0 users, load averages: 0.00, 0.00, 0.00 The camel has a single hump; The dromedary two; Or else the other way around. I'm never sure. Are you? -- Ogden Nash ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[SOLVED]Re: GRUB does not boot FreeBSD after installworld ...
On Wed, 2006-03-29 at 14:44 -0800, Kent Stewart wrote: > On Wednesday 29 March 2006 14:07, Norbert Augenstein wrote: > > On Wed, 2006-03-29 at 23:33 +0200, Michel Talon wrote: > > > Maybe you have an old Grub which doesn't grok UFS2? > > > > No, Grub 0.97 works fine with UFS2 > > > > I will cvsup again and rebuild everything, without > > "CPUTYPE=athlon-xp" in make.conf > > I can remember some bootproblems on my laptop with CPUTYPE?=pentium3m > > I had a problem with 6.1-pre not booting. In my case, I had an old > version of boot1 being used by ntldr. When I updated boot1, I didn't > have any problem booting. I commented out #CPUTYPE?=athlon-xp #CFLAGS= -O2 -pipe in make.conf and did a buildworld again, GRUB installs and works fine again. Thanks and sorry for the noise, --> auge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: GRUB does not boot FreeBSD after installworld ...
On Wed, 2006-03-29 at 23:33 +0200, Michel Talon wrote: > Maybe you have an old Grub which doesn't grok UFS2? No, Grub 0.97 works fine with UFS2 I will cvsup again and rebuild everything, without "CPUTYPE=athlon-xp" in make.conf I can remember some bootproblems on my laptop with CPUTYPE?=pentium3m > It is the case on my machine so i use chainloader to boot freebsd, like that: > title FreeBSD > root(hd0,3) > savedefault > makeactive > chainloader +1 > boot > > Linux i can boot directly: > title Debian GNU/Linux, kernel 2.6.8-2-k7 > root(hd0,5) > kernel /boot/vmlinuz-2.6.8-2-k7 root=/dev/hda6 ro acpi=force > initrd /boot/initrd.img-2.6.8-2-k7 > savedefault > boot > > WindowsXP i also chainload. > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: GRUB does not boot FreeBSD after installworld ...
On Wed, 2006-03-29 at 20:07 +0100, [EMAIL PROTECTED] wrote: > > From: Norbert Augenstein <[EMAIL PROTECTED]> > > Subject: GRUB does not boot FreeBSD after installworld ... > > > > HI, > > > > i have updatete to 6.1-PRERELEASE and after the "installworld" step GRUB > > is unable to boot FreeBSD. > > Perhaps it wasn't the installworld step that caused this... > The boot record isn't touched... I did a reboot after "installkernel" so i know the 6.1-PRE kernel was able to boot, and GRUB did not complain too. So whatelse could have changed? > > > After i did the installworld and rebooted the GRUB error was: > > > > 23 : Error while parsing number > > > > I have reinstalled the standard FreeBSD loader for now. > > > > Booting with a GRUB boot-floppy i am able to start either XP or Linux > > but trying to start FreeBSD the system just reboots, no errormessage. > > > > I have already tried to install GRUB to MBR again, but no go, the system > > just reboots if i try to start FreeBSD. > > > > Any ideas? > > How are you installing grub? From floppy? yes, booting from grub-floppy root (hd0,1,a) kernel /boot/loader setup (hd0) no error up to here! but typing "boot" does not boot, it reboots the system without errormessage. Booting XP or Linux works with the grub-floppy by just typing the root and kernel line from menu.lst and "boot" [EMAIL PROTECTED] ~]% cat /boot/grub/menu.lst default 0 timeout 2 title FreeBSD --> The Power to Serve root (hd0,1,a) kernel /boot/loader title Gentoo Linux root (hd0,2) kernel /kernel root=/dev/hda3 title Windoof --> The eXPerience root (hd0,0) chainloader +1 > What are your configuration files? menu.lst what else? Thanks, --> auge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
cannot type in GDM after installworld ...
Hi, additionally to my GRUB problem, GDM does not accept any keystroke at all, nada nothing, after updating to 6.1-PRERELEASE. I am using XDM for now. Any ideas here? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
GRUB does not boot FreeBSD after installworld ...
HI, i have updatete to 6.1-PRERELEASE and after the "installworld" step GRUB is unable to boot FreeBSD. After i did the installworld and rebooted the GRUB error was: 23 : Error while parsing number I have reinstalled the standard FreeBSD loader for now. Booting with a GRUB boot-floppy i am able to start either XP or Linux but trying to start FreeBSD the system just reboots, no errormessage. I have already tried to install GRUB to MBR again, but no go, the system just reboots if i try to start FreeBSD. Any ideas? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: What to do when panic?
> I've never debugged FreeBSD, but now I've decided to help the testing > process of FreeBSD 6. I installed it, and then I had a panic. I got a > debugger prompt, but I don't know what to do with that. I don't know the > debugger commands. Please let me know what should I do when I have an > another panic. What should I type and what kind of information should I > send as a PR. You should also have a look at http://www.lemis.com/grog/Papers/Debug-tutorial/tutorial.pdf. That's Greg Lehey's script of his excellent tutorial on kernel debugging. Norbert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: TinyBSD Call For Testers
Hello, thank you for your posting. Can you explain, how it compares to minibsd [https://neon1.net/misc/minibsd.html]? Norbert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
burncd freeze system
Hallo list, i have tried to burn an iso of 26MB of size, and my system locks up so i have to reboot. The image was created with: mkisofs -l -J -r -o output.iso burndir/ and the burncommand was: burncd -f /dev/acd1 -s 4 data output.iso fixate After reboot i can find in /var/log/messages: Jan 3 23:40:07 seth kernel: acd1: unknown transfer phase Jan 3 23:40:17 seth kernel: acd1: FAILURE - ATAPI_IDENTIFY timed out Jan 3 23:40:17 seth kernel: acd1: timeout sending command=a1 Jan 3 23:40:17 seth kernel: acd1: error issueing ATAPI_IDENTIFY command Jan 3 23:41:27 seth syslogd: kernel boot file is /boot/kernel/kernel The system freezes while fixating the disc, so burncd -t shows no error. As i can burn it in Win, i am out of ideas. --> auge dmesg: Copyright (c) 1992-2004 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.3-RELEASE-p2 #0: Fri Dec 24 02:42:28 CET 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/AUGE Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(TM) XP 2600+ (2083.11-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x681 Stepping = 1 Features=0x383fbff AMD Features=0xc040 real memory = 536854528 (511 MB) avail memory = 511483904 (487 MB) npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 ACPI link \\_SB_.LNKE has invalid initial irq 15, ignoring ACPI link \\_SB_.LNKF has invalid initial irq 9, ignoring pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 nvidia0: mem 0xe780-0xe787,0xe800-0xefff,0xe600-0xe6ff irq 11 at device 0.0 on pci1 nvidia0: [GIANT-LOCKED] bfe0: mem 0xe580-0xe5801fff irq 10 at device 9.0 on pci0 miibus0: on bfe0 bmtphy0: on miibus0 bmtphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto bfe0: Ethernet address: 00:e0:18:c0:c7:28 bfe0: [GIANT-LOCKED] isab0: at device 17.0 on pci0 isa0: on isab0 atapci0: port 0xb800-0xb80f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 17.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 pcm0: port 0xe000-0xe0ff at device 17.5 on pci0 pcm0: [GIANT-LOCKED] pcm0: fdc0: port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model MouseMan+, device ID 0 pmtimer0 on isa0 orm0: at iomem 0xc-0xcefff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounter "TSC" frequency 2083105636 Hz quality 800 Timecounters tick every 10.000 msec ad0: 57241MB [116301/16/63] at ata0-master UDMA100 acd0: DVDROM at ata1-master UDMA33 acd1: CDRW at ata1-slave UDMA33 Mounting root from ufs:/dev/ad0s2a WARNING: / was not properly dismounted WARNING: /tmp was not properly dismounted WARNING: /var was not properly dismounted WARNING: /usr was not properly dismounted WARNING: /home was not properly dismounted -- 11:50PM up 2 days, 2:55, 0 users, load averages: 0.00, 0.00, 0.00 Does the name Pavlov ring a bell? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: make search cannot find anything
Joseph <[EMAIL PROTECTED]> writes: Hi! > * Eugene Grosbein ([EMAIL PROTECTED]) wrote: >> Hi! >> >> Recently I noted that 'cd /usr/ports; make search ...' cannot find anything. > ^name=... > Give that a shot :) > >> Is it just me or that's really broken? I see the same behaviour - with applied name, eg nk@viteno:~ports% make search name=guile nk@viteno:~ports% norbert. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Problems while building the world
Hi! I've upgraded my system from 3.3 to 4.3. Now, I'd like to go stable, but see the following error when trying to build the world. ,--- | [...] | mkdir -p /usr/obj/usr/local/src/i386/usr/include/ss | ln -sf /usr/local/src/sys /usr/obj/usr/local/src/i386 | | ELF binary type "0" not known. | *** Signal 6 `--- Basically, stuck at square one. Any pointers? TIA, norbert. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
