Re: __fpclassifyd problem
In message: <[EMAIL PROTECTED]> Scott Long <[EMAIL PROTECTED]> writes: : To respond to myself, I got ahold of a 4.8 libm.so and made sure that the : linker used it. No change in the problem, and it still hints that the : native libc is being linked in. You might want to enable debugging of ld.so to confirm. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADSUP: MPSAFE network drivers
In message: <[EMAIL PROTECTED]> Sam Leffler <[EMAIL PROTECTED]> writes: : ath, em, ep, fxp, sn, wi, sis I've been running with ath, fxp, ep, sn and wi w/o problems for a while now... I juat reconfirmed wi, ep, and sn tonight, but didn't do the torture testing I did before the ep and sn locking commits. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem w/ ACPI in -CURRENT: Update
On Thu, 30 Oct 2003, Jeremy Bingham wrote: > On 29/10/03 18:18 -0800, Nate Lawson wrote: > > I looked at a few other ASL copies I have and you have an old version. > > Have you done a BIOS update recently? > > > > Yours: OEMID=DELL, OEM Table ID=CPi R, OEM Revision=0x27d0040b, > > Others: OEMID=DELL, OEM Table ID=CPi R, OEM Revision=0x27d20b07, > > Others: OEMID=DELL, OEM Table ID=CPi R, OEM Revision=0x27d3050f, > > > > Update your BIOS and then do acpidump -t to verify your revision is the > > latest. > > > > -Nate > > Success! I updated my BIOS from A05 to A14, and -CURRENT works > beautifully. I only wish that I had read this email a few hours earlier, > before I got frustrated and decided to give Debian a shot on this > laptop. Linux would probably have had the same problem with your AML since we use the same interpreter. > Happily running FreeBSD again, Glad to hear it. Anyone else having ACPI trouble should please update to their latest BIOS revision before reporting a problem. Thanks, Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: wi problem with message > 7400 bytes
Daniel Eischen wrote: Could you post a tcpdump for each case? I wonder if this is related to a fragmentation issue I've seen in the past. 22:46:43.513038 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52198:[EMAIL PROTECTED]) 22:46:48.522475 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52199:[EMAIL PROTECTED]) 22:46:53.532018 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52200:[EMAIL PROTECTED]) 22:46:58.541178 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52201:[EMAIL PROTECTED]) 22:47:03.553048 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52202:[EMAIL PROTECTED]) 22:47:08.568862 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52203:[EMAIL PROTECTED]) 22:47:13.583328 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52204:[EMAIL PROTECTED]) 22:47:18.578512 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52205:[EMAIL PROTECTED]) 22:47:23.609098 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52206:[EMAIL PROTECTED]) 22:47:28.597680 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52207:[EMAIL PROTECTED]) 22:47:33.607059 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52208:[EMAIL PROTECTED]) It's not what I've seen in the past - but also pretty strange! Only the first fragment seems to be received. Wonder what happened to the other fragments... If you tcpdump on gpz, does the output look the same? Also, you may want to run the tcpdump without a filter (if you don't do this already) to see if the other fragments show up as corrputed frames or something. (As an aside, fragmentation on a lossy link compounds throughput issues, but of course you know that already.) Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Problem w/ ACPI in -CURRENT: Update
On 29/10/03 18:18 -0800, Nate Lawson wrote: > > I looked at a few other ASL copies I have and you have an old version. > Have you done a BIOS update recently? > > Yours: OEMID=DELL, OEM Table ID=CPi R, OEM Revision=0x27d0040b, > Others: OEMID=DELL, OEM Table ID=CPi R, OEM Revision=0x27d20b07, > Others: OEMID=DELL, OEM Table ID=CPi R, OEM Revision=0x27d3050f, > > Update your BIOS and then do acpidump -t to verify your revision is the > latest. > > -Nate Success! I updated my BIOS from A05 to A14, and -CURRENT works beautifully. I only wish that I had read this email a few hours earlier, before I got frustrated and decided to give Debian a shot on this laptop. Happily running FreeBSD again, -j -- /* You are not expected to understand this. */ Captain_Tenille http://www.satanosphere.com/ http://www.kuro5hin.org/ [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: buildworld failed for current ..cvs 12.30 pm. 10-30-2003
On Thu, Oct 30, 2003 at 08:08:08PM -0800, SteAltH FanThoM wrote: > yes it does! > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html > > 21.4.2 Check /etc/make.conf > > Examine the files /etc/defaults/make.conf and /etc/make.conf. The first > contains some default defines - most of which are commented out. To make > use of them when you rebuild your system from source, add them to > /etc/make.conf. Keep in mind that anything you add to /etc/make.conf is > also used every time you run make, so it is a good idea to set them to > something sensible for your system. > > A typical user will probably want to copy the CFLAGS and NOPROFILE lines > found in /etc/defaults/make.conf to /etc/make.conf and uncomment them. > > Examine the other definitions (COPTFLAGS, NOPORTDOCS and so on) and > decide if they are relevant to you. Sure, but.. > > > a good choice. I read the handbook and it advises to add the ... CFLAGS > > > -0 -pipe and NOPROFILE= YES to /etc/make.conf. > > ^^ > > No it doesn't ;-) ..it doesn't say anything about "-0 -pipe", which is a syntax error. Kris pgp0.pgp Description: PGP signature
Re: buildworld failed for current ..cvs 12.30 pm. 10-30-2003
yes it does! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html 21.4.2 Check /etc/make.conf Examine the files /etc/defaults/make.conf and /etc/make.conf. The first contains some default defines - most of which are commented out. To make use of them when you rebuild your system from source, add them to /etc/make.conf. Keep in mind that anything you add to /etc/make.conf is also used every time you run make, so it is a good idea to set them to something sensible for your system. A typical user will probably want to copy the CFLAGS and NOPROFILE lines found in /etc/defaults/make.conf to /etc/make.conf and uncomment them. Examine the other definitions (COPTFLAGS, NOPORTDOCS and so on) and decide if they are relevant to you. On Thu, 30 Oct 2003 19:37:06 -0800, "Kris Kennaway" <[EMAIL PROTECTED]> said: > On Thu, Oct 30, 2003 at 05:03:38PM -0800, SteAltH FanThoM wrote: > > I am running 5-current the last cvs i did " 12.30 pm. today CST " > > failed on buildworld with this. > > > > ===> gnu/usr.bin/cvs/doc > > makeinfo --no-split -I /usr/src/gnu/usr.bin/cvs/doc -I > > /usr/src/gnu/usr.bin/cvs/doc/../../../../contrib/cvs/doc > > /usr/src/gnu/usr.bin/cvs/doc/../../../../contrib/cvs/doc/cvs.texinfo -o > > cvs.info > > makeinfo --no-split -I /usr/src/gnu/usr.bin/cvs/doc -I > > /usr/src/gnu/usr.bin/cvs/doc/../../../../contrib/cvs/doc > > /usr/src/gnu/usr.bin/cvs/doc/../../../../contrib/cvs/doc/cvsclient.texi > > -o cvsclient.info > > gzip -cn cvsclient.info > cvsclient.info.gz > > gzip -cn cvs.info > cvs.info.gz > > 1 error > > *** Error code 2 > > 1 error > > *** Error code 2 > > 1 error > > Do a buildworld without -j so you get the actual error at the end of > the log, not some random non-error output. > > > I was wondering if you guys would help me with make.conf and come up with > > a good choice. I read the handbook and it advises to add the ... CFLAGS > > -0 -pipe and NOPROFILE= YES to /etc/make.conf. > ^^ > No it doesn't ;-) > > kKris -- SteAltH FanThoM [EMAIL PROTECTED] -- http://www.fastmail.fm - And now for something completely different ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: wi problem with message > 7400 bytes
On Thu, 30 Oct 2003, Lars Eggert wrote: > Daniel Eischen wrote: > > > Greetings, > > > > I'm having a problem receiving UDP messages over a wi interface: > > > > wi1: at port 0x180-0x1bf irq 11 function 0 > > config 1 on pccard0 > > wi1: 802.11 address: 00:02:2d:4a:d8:7d > > wi1: using Lucent Technologies, WaveLAN/IEEE > > wi1: Lucent Firmware: Station (6.10.1) > > wi1: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps > > > > (wi0 is also a 'Dell TrueMobile 1150 Series PC Card' in > > a mini-PCI card, but hangs the system when you try and > > configure it -- so it obviously isn't configured in this > > set up.) > > > > I have a small program that does a trivial UDP test: > > > > http://people.freebsd.org/~deischen/udptest.c > > > > My results show that: > > > > o Receiving large (> 7400 bytes) messages does not work. > > > > o Sending large messages works. > > > > o Sending & receiving large messages over a wired > > interface (dc, fxp, etc) works. > > > > Am I suppose to be able to receive UDP messages larger > > than 7400 bytes over the air? > > Could you post a tcpdump for each case? I wonder if this is related to a > fragmentation issue I've seen in the past. 22:46:43.513038 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52198:[EMAIL PROTECTED]) 22:46:48.522475 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52199:[EMAIL PROTECTED]) 22:46:53.532018 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52200:[EMAIL PROTECTED]) 22:46:58.541178 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52201:[EMAIL PROTECTED]) 22:47:03.553048 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52202:[EMAIL PROTECTED]) 22:47:08.568862 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52203:[EMAIL PROTECTED]) 22:47:13.583328 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52204:[EMAIL PROTECTED]) 22:47:18.578512 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52205:[EMAIL PROTECTED]) 22:47:23.609098 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52206:[EMAIL PROTECTED]) 22:47:28.597680 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52207:[EMAIL PROTECTED]) 22:47:33.607059 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52208:[EMAIL PROTECTED]) In this case, I ran: gpz $ udptest -D -c -a 192.168.3.31 -m 7393 vespa $ udptest -D vespa (192.168.3.31) is the affected notebook with wi interface. I ran udptest as the server, so all it is doing is trying to receive a message. The tcpdump was done on vespa. The kernel is current from Monday or Tuesdays sources, and I had the same problem with a kernel from August. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: wi problem with message > 7400 bytes
Daniel Eischen wrote: Greetings, I'm having a problem receiving UDP messages over a wi interface: wi1: at port 0x180-0x1bf irq 11 function 0 config 1 on pccard0 wi1: 802.11 address: 00:02:2d:4a:d8:7d wi1: using Lucent Technologies, WaveLAN/IEEE wi1: Lucent Firmware: Station (6.10.1) wi1: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps (wi0 is also a 'Dell TrueMobile 1150 Series PC Card' in a mini-PCI card, but hangs the system when you try and configure it -- so it obviously isn't configured in this set up.) I have a small program that does a trivial UDP test: http://people.freebsd.org/~deischen/udptest.c My results show that: o Receiving large (> 7400 bytes) messages does not work. o Sending large messages works. o Sending & receiving large messages over a wired interface (dc, fxp, etc) works. Am I suppose to be able to receive UDP messages larger than 7400 bytes over the air? Could you post a tcpdump for each case? I wonder if this is related to a fragmentation issue I've seen in the past. Thanks, Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: buildworld failed for current ..cvs 12.30 pm. 10-30-2003
On Thu, Oct 30, 2003 at 05:03:38PM -0800, SteAltH FanThoM wrote: > I am running 5-current the last cvs i did " 12.30 pm. today CST " > failed on buildworld with this. > > ===> gnu/usr.bin/cvs/doc > makeinfo --no-split -I /usr/src/gnu/usr.bin/cvs/doc -I > /usr/src/gnu/usr.bin/cvs/doc/../../../../contrib/cvs/doc > /usr/src/gnu/usr.bin/cvs/doc/../../../../contrib/cvs/doc/cvs.texinfo -o > cvs.info > makeinfo --no-split -I /usr/src/gnu/usr.bin/cvs/doc -I > /usr/src/gnu/usr.bin/cvs/doc/../../../../contrib/cvs/doc > /usr/src/gnu/usr.bin/cvs/doc/../../../../contrib/cvs/doc/cvsclient.texi > -o cvsclient.info > gzip -cn cvsclient.info > cvsclient.info.gz > gzip -cn cvs.info > cvs.info.gz > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error Do a buildworld without -j so you get the actual error at the end of the log, not some random non-error output. > I was wondering if you guys would help me with make.conf and come up with > a good choice. I read the handbook and it advises to add the ... CFLAGS > -0 -pipe and NOPROFILE= YES to /etc/make.conf. ^^ No it doesn't ;-) kKris pgp0.pgp Description: PGP signature
Re: kernel hangs with SMP/Hyperthreading
Interrupting the normal boot sequence as suggested below has not worked in the past for this problem. Inserting "debug statements" in the source code (as noted in a PR, but I can't remember which one) in the "while (read_intr_count(8) < 6)" loop showed that the count value started at 0 and never changed, thereby initiating an infinite "NOP loop". A later change in 5.1 source magically corrected this, somewhere around August 2003, for one MSI board that encountered this problem. On 28 Oct, Scott Long wrote: > > Hi, > > There is a discussion going on about strange interactions between the boot > menu and SMP that sounds very much like what you describe. FOr a > workaround, at the boot menu, select option 6, then type 'boot' at the > prompt. > > Scott > > On Tue, 28 Oct 2003, Bernhard Valenti wrote: > >> hi, >> >> i built a kernel with APIC_IO and SMP for my p4 with hyperthreading. >> when i try to boot the kernel it hangs during boot at: >> >> APIC_IO: Testing 8254 interrupt delivery >> >> doing >> >> while (read_intr_count(8) < 6) >> ; /* nothing */ >> >> (sys/i386/isa/clock.c:1030) >> >> read_intr_count(8) returns 0 forever... >> >> i dont know how to provide a dmesg as i cant get to a shell. this >> computer is a laptop with sis 645dx chipset. >> >> anyone have a fix for that? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
wi problem with message > 7400 bytes
Greetings, I'm having a problem receiving UDP messages over a wi interface: wi1: at port 0x180-0x1bf irq 11 function 0 config 1 on pccard0 wi1: 802.11 address: 00:02:2d:4a:d8:7d wi1: using Lucent Technologies, WaveLAN/IEEE wi1: Lucent Firmware: Station (6.10.1) wi1: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps (wi0 is also a 'Dell TrueMobile 1150 Series PC Card' in a mini-PCI card, but hangs the system when you try and configure it -- so it obviously isn't configured in this set up.) I have a small program that does a trivial UDP test: http://people.freebsd.org/~deischen/udptest.c My results show that: o Receiving large (> 7400 bytes) messages does not work. o Sending large messages works. o Sending & receiving large messages over a wired interface (dc, fxp, etc) works. Am I suppose to be able to receive UDP messages larger than 7400 bytes over the air? To run the above test: # On one machine, run it as a server (it just echoes # the messages back to the client). # $ udptest -D # On the wireless machine, run it as a client (it # sends a message to the server and waits for the # echoed response). # $ udptest -D -c -a -m If I set message size to 7392 (plus an 8 byte header in my message = 7400), everything works. Anything higher and I never receive the response. Thanks ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Software RAID
On Thu, Oct 30, 2003 at 05:40:40PM -0800, Steve Lee wrote: > So there is no way to mirror the root so if one drive fails, > i can't have the other drive boot up ? > > DAMN Vinum is capable of doing it, but its a little tricky. Take a look: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/vinum-root.html -Ryan T. Dean > On Thu, 30 Oct 2003, Scott Likens wrote: > > > On Thu, 2003-10-30 at 16:22, Steve Lee wrote: > > > Does FreeBSD support Software RAID ? > > > if so, what can it do ? > > > RAID 0, 1, 5 ?? > > > > > > also would it be able to mirror the root parition ? > > > > > > Thanks. > > > > > > any advice would be cool. > > > > http://www.freebsd.org/handbook > > > > There's always good stuff in there about everything, as far as raid, 0, > > 1, 5, I imagine 0+1, 10, prolly the only thing it lacks is JBOD. > > > > But as far as your 'root' partition that I don't think so, mirroring the > > root partition usually isn't worth it anywho. Since the root partition > > is typically 250megs for / > > > > and yeah you can mirror /usr /var, etc with vinum (mdconfig) or you > > could use ccd if you wish. > > > > > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" pgp0.pgp Description: PGP signature
Re: Still gettnig NFS client locking up
On Tue, 28 Oct 2003, Soren Schmidt wrote: > > I'm now running a kernel/world of October 26th on both NFS client and > > server machines. I am still seeing NFS lockups as reported by several > > people in these threads: > > Me too!! Hmm. I'm unable to reproduce this so far, and I'm pounding several 5.x NFS clients and servers. I've been checking out using CVS over NFS, performing dd's of big files, etc. There must be something more I'm missing in reproducing this. What network interface cards are you using (client, server)? Are you using DHCP on the client or server? What commands trigger it -- what part of the NFS namespace, etc? Are you running the commands as root, or another user? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Software RAID
< said: > So there is no way to mirror the root so if one drive fails, > i can't have the other drive boot up ? There are ways to do that, but in order for that to work at all you need to have BIOS support. Some of the ATA ``RAID'' products work like that: they have BIOS support for mirroring/failover, but the operating system has to do all the work once it's booted. FreeBSD supports these controllers reasonably well, and they are quite economical. -GAWollman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Software RAID
So there is no way to mirror the root so if one drive fails, i can't have the other drive boot up ? DAMN On Thu, 30 Oct 2003, Scott Likens wrote: > On Thu, 2003-10-30 at 16:22, Steve Lee wrote: > > Does FreeBSD support Software RAID ? > > if so, what can it do ? > > RAID 0, 1, 5 ?? > > > > also would it be able to mirror the root parition ? > > > > Thanks. > > > > any advice would be cool. > > http://www.freebsd.org/handbook > > There's always good stuff in there about everything, as far as raid, 0, > 1, 5, I imagine 0+1, 10, prolly the only thing it lacks is JBOD. > > But as far as your 'root' partition that I don't think so, mirroring the > root partition usually isn't worth it anywho. Since the root partition > is typically 250megs for / > > and yeah you can mirror /usr /var, etc with vinum (mdconfig) or you > could use ccd if you wish. > > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: exclusive sleep mutex mntvnode r = 0 (0xffffffff80758220) /a/asami/portbuild/amd64/src-client/sys/ufs/ffs/ffs_vfsops.c:1172
On Thu, 30 Oct 2003 10:18:43 -0800
Kris Kennaway <[EMAIL PROTECTED]> wrote:
> One of the amd64 machines died with the following. The kernel is a
> few weeks old, so this might already be fixed.
>
> Kris
>
> malloc() of "64" with the following non-sleepable locks held:
> exclusive sleep mutex mntvnode r = 0 (0x80758220) locked @
> /a/asami/portbuild/amd64/src-client/sys/ufs/ffs/ffs_vfsops.c:1172
> recursed on non-recursive lock (sleep mutex) mntvnode @
> /a/asami/portbuild/amd64/src-client/sys/kern/vfs_subr.c:1054 first
> acquired @
> /a/asami/portbuild/amd64/src-client/sys/ufs/ffs/ffs_vfsops.c:1172
> panic: recurse Debugger("panic")
> Stopped at Debugger+0x4b: xchgl %ebx,0x31599f
> db> where
> Debugger() at Debugger+0x4b
> panic() at panic+0x169
> witness_lock() at witness_lock+0x383
> _mtx_lock_flags() at _mtx_lock_flags+0x9c
> insmntque() at insmntque+0x2a
> vclean() at vclean+0x35b
> vgonel() at vgonel+0x51
> vrecycle() at vrecycle+0x5b
> ufs_inactive() at ufs_inactive+0x22c
> ufs_vnoperate() at ufs_vnoperate+0x14
> vrele() at vrele+0x11a
> ffs_sync() at ffs_sync+0x24f
> sync() at sync+0xdb
> syscall() at syscall+0x320
> Xfast_syscall() at Xfast_syscall+0xa7
> --- syscall (36, FreeBSD ELF64, sync), rip = 0x402084, rsp =
> 0x7648, rbp = 0x3 --- db>
Known and being looked at.
--
Alexander Kabaev
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADSUP: MPSAFE network drivers
On Wed, Oct 29, 2003 at 11:52:48AM -0700, Sam Leffler wrote: > The following drivers are marked MPSAFE: > > ath, em, ep, fxp, sn, wi, sis > > I've got changes coming for bge. Other drivers probably can be marked > MPSAFE but I'm only doing it for those drivers that I can test. Donations@ can certainly collect other cards for you. Send us your shipping address. :-) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Experimental patch to support large MS-DOS filesystems
If you're feeling adventurous and have access to a relatively large MS-DOS formatted disk that gives a "disk too big, sorry" error when you try to mount it, please try out this patch and let me know how it goes: http://people.freebsd.org/~tjr/fileno32.diff (http://perforce.freebsd.org/chv.cgi?CH=40907) I don't have access to disks big enough to cause the error message, so don't be surprised if it doesn't work. Although there is very little chance of it causing data loss, it'd be best to try it on a read-only filesystem first, and to make sure that you have backups. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Software RAID
On Thu, 2003-10-30 at 16:22, Steve Lee wrote: > Does FreeBSD support Software RAID ? > if so, what can it do ? > RAID 0, 1, 5 ?? > > also would it be able to mirror the root parition ? > > Thanks. > > any advice would be cool. http://www.freebsd.org/handbook There's always good stuff in there about everything, as far as raid, 0, 1, 5, I imagine 0+1, 10, prolly the only thing it lacks is JBOD. But as far as your 'root' partition that I don't think so, mirroring the root partition usually isn't worth it anywho. Since the root partition is typically 250megs for / and yeah you can mirror /usr /var, etc with vinum (mdconfig) or you could use ccd if you wish. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: lots of "exclusive sleep mutex"
On 2003/10/30 00:16:47, Clive Lin wrote:
> On Sat, Oct 04, 2003 at 02:00:33AM +0800, Clive Lin wrote:
> > Hi,
> >
> > I've seen lots of messages on rescent -CURRENT
> >
> > malloc() of "16" with the following non-sleepable locks held:
> > exclusive sleep mutex g_xdown r = 0 (0xe044eca8) locked @
> > /usr/src/sys/geom/geom_io.c:351
> > malloc() of "16" with the following non-sleepable locks held:
> > exclusive sleep mutex g_xdown r = 0 (0xe044eca8) locked @
> > /usr/src/sys/geom/geom_io.c:351
>
> Many of above are still seen on the latest current.
> malloc() of "16" with the following non-sleepable locks held:
> exclusive sleep mutex g_xdown r = 0 (0xe044eca8) locked @
> /usr/src/sys/geom/geom_io.c:355
> malloc() of "16" with the following non-sleepable locks held:
> exclusive sleep mutex g_xdown r = 0 (0xe044eca8) locked @
> /usr/src/sys/geom/geom_io.c:355
>
> Perhaps it's a ServeRAID specific glitch?
> > dmesg|grep ips
> ips0: mem 0xf000-0xf3ff irq 16 at device 1.0 on pci4
> ips0: logical drives: 1
> ipsd0: on ips0
> GEOM: create disk ipsd0 dp=0xc6b25310
> ipsd0: Logical Drive (69430MB)
Does this fix?
Index: ips.c
===
RCS file: /home/cvs/freebsd/src/sys/dev/ips/ips.c,v
retrieving revision 1.5
diff -u -6 -r1.5 ips.c
--- ips.c 24 Aug 2003 17:49:13 - 1.5
+++ ips.c 30 Oct 2003 08:45:32 -
@@ -147,12 +147,13 @@
waiter = malloc(sizeof(ips_wait_list_t), M_DEVBUF, memflags);
if(!waiter)
return ENOMEM;
mask = splbio();
if(sc->state & IPS_OFFLINE){
splx(mask);
+ free(waiter, M_DEVBUF);
return EIO;
}
command = SLIST_FIRST(&sc->free_cmd_list);
if(command && !(sc->state & IPS_TIMEOUT)){
SLIST_REMOVE_HEAD(&sc->free_cmd_list, next);
(sc->used_commands)++;
By the way, does this panic your machine?
$ exec sh
$ mkdir foo
$ i=0; while :; do echo $i > foo/$i; i=$(($i+1)); done
Regards.
--
YONETANI Tomokazu / Ergo-Brains Inc.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
buildworld failed for current ..cvs 12.30 pm. 10-30-2003
I am running 5-current the last cvs i did " 12.30 pm. today CST " failed on buildworld with this. ===> gnu/usr.bin/cvs/doc makeinfo --no-split -I /usr/src/gnu/usr.bin/cvs/doc -I /usr/src/gnu/usr.bin/cvs/doc/../../../../contrib/cvs/doc /usr/src/gnu/usr.bin/cvs/doc/../../../../contrib/cvs/doc/cvs.texinfo -o cvs.info makeinfo --no-split -I /usr/src/gnu/usr.bin/cvs/doc -I /usr/src/gnu/usr.bin/cvs/doc/../../../../contrib/cvs/doc /usr/src/gnu/usr.bin/cvs/doc/../../../../contrib/cvs/doc/cvsclient.texi -o cvsclient.info gzip -cn cvsclient.info > cvsclient.info.gz gzip -cn cvs.info > cvs.info.gz 1 error *** Error code 2 1 error *** Error code 2 1 error I was wondering if you guys would help me with make.conf and come up with a good choice. I read the handbook and it advises to add the ... CFLAGS -0 -pipe and NOPROFILE= YES to /etc/make.conf. First question, is either of the above necessary if not why is it recommended and what are the benefits of each? Also in conjunction with the latter, if its probably best to have the above in make.conf why is it not in there by default, i installed freebsd-5 current via. a snapshot and the original /etc/make.conf does not have this option. Anyways i added this to the one that was there and was wondering if this caused the error above on buildworld? I am attaching my make.conf, i ommited them out for now and am trying again but thought i would ask. if anything else needs to be in there or deleted please advise. what is profiled libraries, should i build without them, NOPROFILE=YES? I was just wondering what the pros/cons where and if its recommended by the experts. If any of you guys dont mind sharing your make.conf i would appreciate it. I am trying to come up with a advisable, sound make.conf file. I am in the usa, timezone CST system: amd-athlon-xp 1800 ram- ddr-2100 hd- ide Thanks in advance here is make.conf just in-case the attachment is filtered as i know some mailing list do. less /etc/make.conf # -- use.perl generated deltas -- # # Created: Mon Oct 27 12:47:25 2003 # Setting to use base perl from ports: PERL_VER=5.6.1 PERL_VERSION=5.6.1 PERL_ARCH=mach NOPERL=yo NO_PERL=yo NO_PERL_WRAPPER=yo #CFLAGS= -O -pipe #NOPROFILE= true# Avoid compiling profiled libraries -- SteAltH FanThoM [EMAIL PROTECTED] -- http://www.fastmail.fm - Or how I learned to stop worrying and love email again ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Software RAID
Does FreeBSD support Software RAID ? if so, what can it do ? RAID 0, 1, 5 ?? also would it be able to mirror the root parition ? Thanks. any advice would be cool. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[current tinderbox] failure on ia64/ia64
TB --- 2003-10-30 22:42:22 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-10-30 22:42:22 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2003-10-30 22:42:22 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-10-30 22:44:29 - building world TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: populating >>> /home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/include >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything.. TB --- 2003-10-30 23:49:17 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Oct 30 23:49:17 GMT 2003 >>> Kernel build for GENERIC completed on Fri Oct 31 00:05:22 GMT 2003 TB --- 2003-10-31 00:05:22 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src/sys/ia64/conf TB --- /usr/bin/make -B LINT TB --- 2003-10-31 00:05:22 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Oct 31 00:05:22 GMT 2003 [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/firewire/if_fwe.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/firewire/sbp.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/fxp/if_fxp.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia
Re: Still gettnig NFS client locking up
On Tue, Oct 28, 2003 at 12:07:09PM +0100, Soren Schmidt wrote: > It seems Matt wrote: > > I'm now running a kernel/world of October 26th on both NFS client and > > server machines. I am still seeing NFS lockups as reported by several > > people in these threads: > > > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1296172+0+archive/2003/freebsd-current/20031026.freebsd-current > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1333116+0+archive/2003/freebsd-current/20031026.freebsd-current > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1477462+0+archive/2003/freebsd-current/20031026.freebsd-current > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1469939+0+archive/2003/freebsd-current/20031026.freebsd-current > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1467159+0+archive/2003/freebsd-current/20031026.freebsd-current > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1314547+0+archive/2003/freebsd-current/20031026.freebsd-current > > > > I just tried port upgrading bind9 and it got 10% through downloading and > > locked up. I tried an ls /usr/ports and there was no response. I had to > > umount -f /usr/ports to get the processes to exit. > > > > Poul-Henning's patch did not have any effect because it appears to be > > the client at fault not the server as Marc Olzheim mentioned that he has > > the same issue with a 4.x NFS server machine using a 5.1-current client. > > Me too!! I've reported NFS corruption on certain p4 machines running 5.x, which may or may not be related. No lockups though. Kris pgp0.pgp Description: PGP signature
Re: ATAng regression: cdcontrol close not working
Soren Schmidt wrote:
Anyhow if you loose the test for error in atapi-cd.c::acd_tray in the
close case, does it work then ?
If you mean as below, no, that didn't help:
Index: atapi-cd.c
===
RCS file: /home/ncvs/src/sys/dev/ata/atapi-cd.c,v
retrieving revision 1.149
diff -u -r1.149 atapi-cd.c
--- atapi-cd.c 18 Oct 2003 17:24:51 - 1.149
+++ atapi-cd.c 30 Oct 2003 21:31:23 -
@@ -1884,11 +1884,10 @@
if (cdp->cap.mechanism & MST_EJECT) {
if (close) {
- if (!(error = acd_start_stop(cdp, 3))) {
- acd_read_toc(cdp);
- acd_prevent_allow(cdp, 1);
- cdp->flags |= F_LOCKED;
- }
+error = acd_start_stop(cdp, 3);
+ acd_read_toc(cdp);
+ acd_prevent_allow(cdp, 1);
+ cdp->flags |= F_LOCKED;
}
else {
acd_start_stop(cdp, 0);
Lars
--
Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute
smime.p7s
Description: S/MIME Cryptographic Signature
Re: ATAng regression: cdcontrol close not working
V čt, 30. 10. 2003 v 20:43, Lars Eggert píše: > >>FYI, the issue is still present with yesterday's -current. Will Pav > >>Lucistnik's patch be committed soon? > > > > I've already committed a solution that works on all the drives I > > could test on (some of which failed before), if this still > > fails for you I'd like a more detailed description of what > > exactly goes wrong... > > I must have missed that commit message, sorry. This is the drive I am > having the issues with: > > acd0: CDRW at ata1-master UDMA33 > > I also have atapicam in the kernel: > > cd0: Removable CD-ROM SCSI-0 device > > I have the same issue as the original poster: > > "cdcontrol -f /dev/acd0 eject" -> ejects tray > "cdcontrol -f /dev/acd0 close" -> does nothing Works for me (with 1.148 revision of atapi-cd.c). You're in it alone now, Lars. -- Pav Lucistnik <[EMAIL PROTECTED]> What do we know about love? Love is like a pear. Pear is sweet and have a specific shape. Try to exactly define the shape of a pear. -- Marigold: 50 Years Of Poetry -- Pav Lucistnik <[EMAIL PROTECTED]> Co vime o lasce? Laska je jako hruska. Hruska je sladka a ma urcity tvar. Zkuste presne definovat tvar hrusky. -- Marigold: Pul stoleti poezie signature.asc Description: Toto je =?iso-8859-2?Q?digit=E1ln=EC?= =?ISO-8859-1?Q?_podepsan=E1?= =?iso-8859-2?Q?_=E8=E1st?= =?ISO-8859-1?Q?_zpr=E1vy?=
Re: ATAng regression: cdcontrol close not working
It seems Lars Eggert wrote: > > I've already committed a solution that works on all the drives I > > could test on (some of which failed before), if this still > > fails for you I'd like a more detailed description of what > > exactly goes wrong... > > I must have missed that commit message, sorry. This is the drive I am > having the issues with: > > acd0: CDRW at ata1-master UDMA33 > > Sending CDIOCCLOSE from a short C snippet shows that the ioctl yields EBUSY. Hmm, now that a real stupid return code from the drive IMNHO... Anyhow if you loose the test for error in atapi-cd.c::acd_tray in the close case, does it work then ? Problem is that the call to read toc might fail early, but its worth a shot.. -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: LOR route.c:182
On Thursday 30 October 2003 10:30 am, othermark wrote: > I'll me too this one.. > > Another backtrace with a different call sequence (via ipv6), exact same LOR > > lock order reversal > 1st 0xc2177c90 rtentry (rtentry) @ /usr/src/sys/net/route.c:182 > 2nd 0xc206537c radix node head (radix node head) @ /usr/src/sys/net > route.c:544 > Stack backtrace: > backtrace(c0841847,c206537c,c08472ff,c08472ff,c0847355) at backtrace+0x17 > witness_lock(c206537c,8,c0847355,220,c0926300) at witness_lock+0x672 > _mtx_lock_flags(c206537c,0,c0847355,220,c8f45868) at _mtx_lock_flags+0xba > rtrequest1(1,c8f45874,c8f458c8,0,c24376b0) at rtrequest1+0x59 > rtrequest(1,c24376b0,c24376b0,c8f458cc,405) at rtrequest+0x4a > in6_ifloop_request(1,c2437600,0,c2437600,40) at in6_ifloop_request+0x76 > in6_ifaddloop(c2437600,0,c2437600,0,c8f45a84) at in6_ifaddloop+0x50 > in6_ifinit(c200,c2437600,c8f45a2c,1,1be) at in6_ifinit+0x147 > in6_update_ifa(c200,c8f45a1c,0,0,20080fe) at in6_update_ifa+0x500 > in6_ifadd(c8f45b34,0,40,0,0) at in6_ifadd+0x22a I've got fixes for almost all the outstanding LOR's and recursive lock problems. I'm doing more testing before I committing them. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATAng regression: cdcontrol close not working
On 30-Oct-2003 Lars Eggert wrote: > Soren Schmidt wrote: >> It seems Lars Eggert wrote: >> >>>FYI, the issue is still present with yesterday's -current. Will Pav >>>Lucistnik's patch be committed soon? >> >> I've already committed a solution that works on all the drives I >> could test on (some of which failed before), if this still >> fails for you I'd like a more detailed description of what >> exactly goes wrong... > > I must have missed that commit message, sorry. This is the drive I am > having the issues with: > > acd0: CDRW at ata1-master UDMA33 > > I also have atapicam in the kernel: > > cd0: Removable CD-ROM SCSI-0 device > > I have the same issue as the original poster: > > "cdcontrol -f /dev/acd0 eject" -> ejects tray > "cdcontrol -f /dev/acd0 close" -> does nothing > > "cdcontrol -f /dev/cd0 eject" -> ejects tray > "cdcontrol -f /dev/cd0 close" -> retracts tray > > cdcontrol does not show any messages, even with -v. > > Sending CDIOCCLOSE from a short C snippet shows that the ioctl yields EBUSY. > > (I also tried to get a ktrace, but that just shows "Events dropped" > where the trace becomes interesting. Issue with -current?) You ran out of ktrace objects (check your dmesg). You can resize the pool via the kern.ktrace.request_pool sysctl. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: jumbograms (& em) & nfs a no go
Michal Mertl writes: | On Thu, 30 Oct 2003, Sam Leffler wrote: | | > On Thursday 30 October 2003 04:46 am, Michal Mertl wrote: | > > I wanted to test gigabit network performance and found out that current | > > (from 5.0 to up to date -current) doesn't fully work with jumbograms (MTU | > > set to 6000), Intel adapters and nfs (both UDP and TCP). | > > | > > I checked that the same thing works with 4.9. | > > | > > I then left one computer at 4.9 and upgraded the other to 5.0. When I | > > mount a partition from 5.0 machine I found out, that copying reliably | > > works only from 5.0 to 4.9. The other way around I see messages 'em0: | > > discard oversize frame (ether type 800 flags 3 len 67582 > max 6014)' on | > > 5.0 and the copying stalls. On 4.9 machine I later see 'nfs server | > > 10.0.0.2:/usr: not responding'. The interface is stuck for some time - can | > > be revived by changing mtu back to 1500 and down/up sequence. | > | > I've ran many jumbogram tests of machines connected with a cross-over cable | > and em devices at each end. If you've got a swtch in the middle make sure it | > does the right thing. | | I also used exclusively crossover cable. The same configuration worked | with 4.9. The problem appears only with NFS. You might want to try this patch: Index: if_em.c === RCS file: /cvs/src/sys/dev/em/if_em.c,v retrieving revision 1.32 diff -c -r1.32 if_em.c *** if_em.c 15 Oct 2003 05:34:41 - 1.32 --- if_em.c 30 Oct 2003 19:39:49 - *** *** 2454,2460 BUS_SPACE_MAXADDR, /* highaddr */ NULL, NULL, /* filter, filterarg */ MCLBYTES,/* maxsize */ !1, /* nsegments */ MCLBYTES,/* maxsegsize */ BUS_DMA_ALLOCNOW,/* flags */ NULL,/* lockfunc */ --- 2454,2460 BUS_SPACE_MAXADDR, /* highaddr */ NULL, NULL, /* filter, filterarg */ MCLBYTES,/* maxsize */ !2, /* nsegments */ MCLBYTES,/* maxsegsize */ BUS_DMA_ALLOCNOW,/* flags */ NULL,/* lockfunc */ There was a few bugs in the system before in that there was insufficient error check in the bus_dma stuff. The issue was that HW was writing more then was the allocated due to (nsegments=1). This isn't the right fix but might help point to the issue. I don't have access to the HW to test it out anymore. Doug A. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATAng regression: cdcontrol close not working
Soren Schmidt wrote: It seems Lars Eggert wrote: FYI, the issue is still present with yesterday's -current. Will Pav Lucistnik's patch be committed soon? I've already committed a solution that works on all the drives I could test on (some of which failed before), if this still fails for you I'd like a more detailed description of what exactly goes wrong... I must have missed that commit message, sorry. This is the drive I am having the issues with: acd0: CDRW at ata1-master UDMA33 I also have atapicam in the kernel: cd0: Removable CD-ROM SCSI-0 device I have the same issue as the original poster: "cdcontrol -f /dev/acd0 eject" -> ejects tray "cdcontrol -f /dev/acd0 close" -> does nothing "cdcontrol -f /dev/cd0 eject" -> ejects tray "cdcontrol -f /dev/cd0 close" -> retracts tray cdcontrol does not show any messages, even with -v. Sending CDIOCCLOSE from a short C snippet shows that the ioctl yields EBUSY. (I also tried to get a ktrace, but that just shows "Events dropped" where the trace becomes interesting. Issue with -current?) Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: ATAng regression: cdcontrol close not working
It seems Lars Eggert wrote: > FYI, the issue is still present with yesterday's -current. Will Pav > Lucistnik's patch be committed soon? I've already committed a solution that works on all the drives I could test on (some of which failed before), if this still fails for you I'd like a more detailed description of what exactly goes wrong... revision 1.148 date: 2003/10/12 13:11:57; author: sos; state: Exp; lines: +21 -22 Redo the code that handles eject/close. -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATAng regression: cdcontrol close not working
Soren Schmidt wrote: It seems Pav Lucistnik wrote: This patch works for me. Any chance to get it committed? I'll look at it... FYI, the issue is still present with yesterday's -current. Will Pav Lucistnik's patch be committed soon? Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: LOR route.c:182
I'll me too this one.. Another backtrace with a different call sequence (via ipv6), exact same LOR lock order reversal 1st 0xc2177c90 rtentry (rtentry) @ /usr/src/sys/net/route.c:182 2nd 0xc206537c radix node head (radix node head) @ /usr/src/sys/net route.c:544 Stack backtrace: backtrace(c0841847,c206537c,c08472ff,c08472ff,c0847355) at backtrace+0x17 witness_lock(c206537c,8,c0847355,220,c0926300) at witness_lock+0x672 _mtx_lock_flags(c206537c,0,c0847355,220,c8f45868) at _mtx_lock_flags+0xba rtrequest1(1,c8f45874,c8f458c8,0,c24376b0) at rtrequest1+0x59 rtrequest(1,c24376b0,c24376b0,c8f458cc,405) at rtrequest+0x4a in6_ifloop_request(1,c2437600,0,c2437600,40) at in6_ifloop_request+0x76 in6_ifaddloop(c2437600,0,c2437600,0,c8f45a84) at in6_ifaddloop+0x50 in6_ifinit(c200,c2437600,c8f45a2c,1,1be) at in6_ifinit+0x147 in6_update_ifa(c200,c8f45a1c,0,0,20080fe) at in6_update_ifa+0x500 in6_ifadd(c8f45b34,0,40,0,0) at in6_ifadd+0x22a prelist_update(c8f45b34,c2425740,c1390700,246,c0894d8c) at prelist_updat +0x3f7 nd6_ra_input(c1390700,28,38,4,1) at nd6_ra_input+0x4ec icmp6_input(c8f45cac,c8f45c8c,3a,c0629780,38) at icmp6_input+0x9b5 ip6_input(c139f400,0,c084706a,89,0) at ip6_input+0xb97 netisr_processqueue(c0927378,0,c084706a,e5,c1f4d040) at netisr_processqueu +0x8e swi_net(0,0,c083c53a,21b,c137e5ac) at swi_net+0x98 ithread_loop(c137cb80,c8f45d48,c083c3ac,311,0) at ithread_loop+0x192 fork_exit(c061f2f0,c137cb80,c8f45d48) at fork_exit+0xb4 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xc8f45d7c, ebp = 0 --- Jiri Mikulas wrote: > lock order reversal > 1st 0xc220b690 rtentry (rtentry) @ /usr/src/sys/net/route.c:182 > 2nd 0xc204807c radix node head (radix node head) @ > /usr/src/sys/net/route.c:133 > Stack backtrace: > backtrace(c087588d,c204807c,c087b88a,c087b88a,c087b8e0) at backtrace+0x17 > witness_lock(c204807c,8,c087b8e0,85,c087b8e0) at witness_lock+0x672 > _mtx_lock_flags(c204807c,0,c087b8e0,85,0) at _mtx_lock_flags+0xba > rtalloc1(c08d657c,1,1,3d8,c8f44b30) at rtalloc1+0x79 > rt_setgate(c220b600,c2255a40,c08d657c,1,0) at rt_setgate+0x268 > rtredirect(c08d656c,c08d657c,0,6,c08d658c) at rtredirect+0x1bf > icmp_input(c1397c00,14,c0666d13,c093af88,c093b280) at icmp_input+0x4ff > ip_input(c1397c00,0,c087b5f5,89,0) at ip_input+0xae8 > netisr_processqueue(c0961b10,0,c087b5f5,e5,c1f491c0) at > netisr_processqueue+0x8e > swi_net(0,0,c0870582,21b,c137e974) at swi_net+0x98 > ithread_loop(c137cd00,c8f44d48,c08703f4,311,0) at ithread_loop+0x192 > fork_exit(c062bbe0,c137cd00,c8f44d48) at fork_exit+0xb4 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xc8f44d7c, ebp = 0 --- > > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- othermark atkin901 at nospam dot yahoo dot com (!wired)?(coffee++):(wired); ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
exclusive sleep mutex mntvnode r = 0 (0xffffffff80758220) locked @ /a/asami/portbuild/amd64/src-client/sys/ufs/ffs/ffs_vfsops.c:1172
One of the amd64 machines died with the following. The kernel is a
few weeks old, so this might already be fixed.
Kris
malloc() of "64" with the following non-sleepable locks held:
exclusive sleep mutex mntvnode r = 0 (0x80758220) locked @
/a/asami/portbuild/amd64/src-client/sys/ufs/ffs/ffs_vfsops.c:1172
recursed on non-recursive lock (sleep mutex) mntvnode @
/a/asami/portbuild/amd64/src-client/sys/kern/vfs_subr.c:1054
first acquired @ /a/asami/portbuild/amd64/src-client/sys/ufs/ffs/ffs_vfsops.c:1172
panic: recurse
Debugger("panic")
Stopped at Debugger+0x4b: xchgl %ebx,0x31599f
db> where
Debugger() at Debugger+0x4b
panic() at panic+0x169
witness_lock() at witness_lock+0x383
_mtx_lock_flags() at _mtx_lock_flags+0x9c
insmntque() at insmntque+0x2a
vclean() at vclean+0x35b
vgonel() at vgonel+0x51
vrecycle() at vrecycle+0x5b
ufs_inactive() at ufs_inactive+0x22c
ufs_vnoperate() at ufs_vnoperate+0x14
vrele() at vrele+0x11a
ffs_sync() at ffs_sync+0x24f
sync() at sync+0xdb
syscall() at syscall+0x320
Xfast_syscall() at Xfast_syscall+0xa7
--- syscall (36, FreeBSD ELF64, sync), rip = 0x402084, rsp = 0x7648, rbp = 0x3
---
db>
pgp0.pgp
Description: PGP signature
Glitch with make cleandir
I was going to live life dangerously on the bleeding edge for a while,
but it seems I have a problem making it all the way to the edge. ...
Turns out I did not have enough room in /usr, so I got a filesystem
full during make buildkernel. I thought I'd just clean up, then move
/usr/src to another filesystem and try again.
# chflags -R noschg /usr/obj/usr
# rm -fr /usr/obj/usr
# make cleandir
"Makefile.inc1", line 744: warning: String comparison operator should be either == or
!=
"Makefile.inc1", line 744: Malformed conditional ((!defined(NO_RESCUE) ||
defined(RELEASEDIR)) && (${TARGET_ARCH} != ${MACHINE_ARCH} || ${BOOTSTRAPPING} <
501101))
"Makefile.inc1", line 744: Missing dependency operator
"Makefile.inc1", line 746: if-less endif
"Makefile.inc1", line 746: Need an operator
make: fatal errors encountered -- cannot continue
*** Error code 1
Stop in /usr/src.
The following patch, which as far as I can tell is definitely wrong,
lets me get past this point. Before I tried that, I turned on various
debugging flags for make, and can see that indeed BOOTSTRAPPING=0, so
using the < comparison operator ought to be all right.
--- Makefile.inc1-SAVE Sat Oct 4 20:53:38 2003
+++ Makefile.inc1 Thu Oct 30 18:53:07 2003
@@ -741,7 +741,7 @@
.if (!defined(NO_RESCUE) || \
defined(RELEASEDIR)) && \
-(${TARGET_ARCH} != ${MACHINE_ARCH} || ${BOOTSTRAPPING} < 501101)
+(${TARGET_ARCH} != ${MACHINE_ARCH} || ${BOOTSTRAPPING} != 501101)
_crunchide=usr.sbin/crunch/crunchide
.endif
I find this kind of odd. Is there perhaps a bug in the make program I
am using? This is on 5.1-RELEASE.
- Harald
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: jumbograms (& em) & nfs a no go
On Thu, Oct 30, 2003 at 12:48:32PM -0500, Garrett Wollman wrote: > > As I recall, when I used a crossover cable, I could not get the > > adapters to go to 1000, only 100. That might have been the cable, > > or not. > > That's at least conceivable; I don't know enough about the wire > protocol to tell whether that's supposed to happen or not. I asked Prafulla some time ago and he told me it was part of the GigE spec. David. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: jumbograms (& em) & nfs a no go
< said: > Just a minor note: GigE should not require a crossover cable. It's > supposed to work to connect two GigE adapters with a straight-thru > cable. I verified this with two Intel em NICs, quite a while ago. This should hardly be surprising, since 1000BASE-TX transmits and receives bidirectionally on all four pairs simultaneously. > As I recall, when I used a crossover cable, I could not get the > adapters to go to 1000, only 100. That might have been the cable, > or not. That's at least conceivable; I don't know enough about the wire protocol to tell whether that's supposed to happen or not. -GAWollman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: jumbograms (& em) & nfs a no go
On Thu, Oct 30, 2003 at 08:04:58AM -0800, Sam Leffler wrote: > > I've ran many jumbogram tests of machines connected with a cross-over cable > and em devices at each end. If you've got a swtch in the middle make sure it > does the right thing. Just a minor note: GigE should not require a crossover cable. It's supposed to work to connect two GigE adapters with a straight-thru cable. I verified this with two Intel em NICs, quite a while ago. As I recall, when I used a crossover cable, I could not get the adapters to go to 1000, only 100. That might have been the cable, or not. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Anyone object to the following change in libc?
< said: > "The c89 utility (which specified a compiler for the C Language specified > by the 108 ISO/IEC 9899: 1990 standard) has been replaced by a c99 utility > (which specifies a compiler for 109 the C Language specified by the > ISO/IEC 9899: 1999 standard)." More specifically: IEEE Std. 1003.1-2001 is aligned to ISO/IEC 9899:1999 in all respects. C99 alignment was one of the principal reasons for bringing out a whole new standard in the first place, rather than continuing the amendment process. (This is also why POSIX now requires eight-bit bytes.) -GAWollman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: jumbograms (& em) & nfs a no go
On Thu, 30 Oct 2003, Sam Leffler wrote: > On Thursday 30 October 2003 04:46 am, Michal Mertl wrote: > > I wanted to test gigabit network performance and found out that current > > (from 5.0 to up to date -current) doesn't fully work with jumbograms (MTU > > set to 6000), Intel adapters and nfs (both UDP and TCP). > > > > I checked that the same thing works with 4.9. > > > > I then left one computer at 4.9 and upgraded the other to 5.0. When I > > mount a partition from 5.0 machine I found out, that copying reliably > > works only from 5.0 to 4.9. The other way around I see messages 'em0: > > discard oversize frame (ether type 800 flags 3 len 67582 > max 6014)' on > > 5.0 and the copying stalls. On 4.9 machine I later see 'nfs server > > 10.0.0.2:/usr: not responding'. The interface is stuck for some time - can > > be revived by changing mtu back to 1500 and down/up sequence. > > I've ran many jumbogram tests of machines connected with a cross-over cable > and em devices at each end. If you've got a swtch in the middle make sure it > does the right thing. I also used exclusively crossover cable. The same configuration worked with 4.9. The problem appears only with NFS. I can repeat the whole test once again to make sure I didn't overlooked anything. It will take some time because I had to put one of the servers into production. -- Michal Mertl ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: jumbograms (& em) & nfs a no go
On Thursday 30 October 2003 04:46 am, Michal Mertl wrote: > I wanted to test gigabit network performance and found out that current > (from 5.0 to up to date -current) doesn't fully work with jumbograms (MTU > set to 6000), Intel adapters and nfs (both UDP and TCP). > > I checked that the same thing works with 4.9. > > I then left one computer at 4.9 and upgraded the other to 5.0. When I > mount a partition from 5.0 machine I found out, that copying reliably > works only from 5.0 to 4.9. The other way around I see messages 'em0: > discard oversize frame (ether type 800 flags 3 len 67582 > max 6014)' on > 5.0 and the copying stalls. On 4.9 machine I later see 'nfs server > 10.0.0.2:/usr: not responding'. The interface is stuck for some time - can > be revived by changing mtu back to 1500 and down/up sequence. I've ran many jumbogram tests of machines connected with a cross-over cable and em devices at each end. If you've got a swtch in the middle make sure it does the right thing. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Panic on ICMP Redirect
On Thursday 30 October 2003 07:33 am, Daniel C. Sobral wrote: > I could have stuck a LONG time on this one if I wasn't testing something > that results in the very thing that causes the panic. I don't have the > exact details, but what I did is the following: > > ifconfig fxp0 10.0.2.6/16 (well, that's configured during boot) > route add 10.0.14.247 10.0.2.7 > ping 10.0.14.247 > > This results in an ICMP Redirect being returned by 10.0.2.7. Upon it's > receival, the machine panics. I'm using a current from yesterday (29th). > Here are a couple of backtraces: I'll deal with it. The icmp_redirect LOR was next on my list... Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADSUP: MPSAFE network drivers
On Thursday 30 October 2003 01:22 am, Pawel Jakub Dawidek wrote: > On Wed, Oct 29, 2003 at 11:52:48AM -0700, Sam Leffler wrote: > +> I'm committing changes to mark various network drivers' interrupt > handlers +> MPSAFE. To insure folks have a way to backout if they hit > problems I've also +> added a tunable that lets you disable this w/o > rebuilding your kernel. By +> default all network drivers that register an > interrupt handler INTR_MPSAFE +> are setup to run their ISR w/o Giant. If > you want to defeat this w/o +> changing the code you can set > +> > +> debug.mpsafenet=0 > +> > +> from the loader when booting and the MPSAFE bit will automatically be > removed. +> I plan to use this to also control forthcoming changes for > registering MPSAFE +> netisrs. > +> > +> The following drivers are marked MPSAFE: > +> > +> ath, em, ep, fxp, sn, wi, sis > +> > +> I've got changes coming for bge. Other drivers probably can be marked > MPSAFE +> but I'm only doing it for those drivers that I can test. > > Because there is so many drivers, maybe you could prepare some regression > tests designed to check changed things. This will allow people to test your > changes - it is not very easy now if we don't know what we're looking for > exactly PLUS those drivers aren't marked MPSAFE by default. Unfortunately there is no easy way to decide if the locking in a driver is correct; otherwise I'd simply test them and not provide a fallback as a I did. Before I commit any driver I run with it for at least a few weeks (in some cases months) on a variety of machines (workstation, server, laptop, firewall). If there are no problems then I commit the change. The driver changes I committed yesterday I've been running for >4 months. Likewise, the next round of locking changes to push Giant up have been running for ~2 months. Otherwise the main safeguard I use are numerous assertions to validate assumptions. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
'/etc/rc.d/pccard restart' starts a second one
Hi all, I wonder what is the deeper meaning of the 'stop_cmd=":"' in -CURRENT's /etc/rc.d/pccard. The only consequence I experience is that '/etc/rc.d/pccard restart' only starts another pccardd. I would like to settle this before I bother you further with my PCMCIA problems :-) Thanks Jan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Panic on ICMP Redirect
I could have stuck a LONG time on this one if I wasn't testing something
that results in the very thing that causes the panic. I don't have the
exact details, but what I did is the following:
ifconfig fxp0 10.0.2.6/16 (well, that's configured during boot)
route add 10.0.14.247 10.0.2.7
ping 10.0.14.247
This results in an ICMP Redirect being returned by 10.0.2.7. Upon it's
receival, the machine panics. I'm using a current from yesterday (29th).
Here are a couple of backtraces:
[0] [EMAIL PROTECTED]:/dos/crash$ gdb -k kernel.18 vmcore.18
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-undermydesk-freebsd"...
panic: recurse
panic messages:
---
panic: recurse
syncing disks, buffers remaining... 2228 2228 2228 2228 2228 2228 2228
2228 2228 2228 2228 2228 2228 2228 2228 2228 2228 2228 2228 2228 ad0:
WARNING - WRITE_DMA recovered from missing interrupt
giving up on 1090 buffers
Uptime: 19h10m15s
Dumping 255 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240
---
Reading symbols from /boot/kernel/snd_cmi.ko...done.
Loaded symbols for /boot/kernel/snd_cmi.ko
Reading symbols from /boot/kernel/snd_pcm.ko...done.
Loaded symbols for /boot/kernel/snd_pcm.ko
Reading symbols from
/usr/obj/usr/src/sys/DCS/modules/usr/src/sys/modules/mac_biba/mac_biba.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/DCS/modules/usr/src/sys/modules/mac_biba/mac_biba.ko.debug
Reading symbols from
/usr/obj/usr/src/sys/DCS/modules/usr/src/sys/modules/mac_mls/mac_mls.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/DCS/modules/usr/src/sys/modules/mac_mls/mac_mls.ko.debug
Reading symbols from
/usr/obj/usr/src/sys/DCS/modules/usr/src/sys/modules/acpi/acpi.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/DCS/modules/usr/src/sys/modules/acpi/acpi.ko.debug
Reading symbols from /boot/kernel/green_saver.ko...done.
Loaded symbols for /boot/kernel/green_saver.ko
Reading symbols from
/usr/obj/usr/src/sys/DCS/modules/usr/src/sys/modules/linux/linux.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/DCS/modules/usr/src/sys/modules/linux/linux.ko.debug
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) bt full
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
No locals.
#1 0xc04e48d1 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:372
No locals.
#2 0xc04e4c67 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
td = (struct thread *) 0xc12c5be0
bootopt = 256
newpanic = 1
ap = 0xcdb1aa0c "\032\fd˦"
buf = "recurse", '\0'
#3 0xc050a853 in witness_lock (lock=0xc47ec090, flags=8,
file=0xc0640c1a "/usr/src/sys/net/route.c", line=565)
at /usr/src/sys/kern/subr_witness.c:722
lock_list = (struct lock_list_entry **) 0xc12c5c4c
lle = (struct lock_list_entry *) 0xc0663eac
lock1 = (struct lock_instance *) 0xc06b77a4
lock2 = (struct lock_instance *) 0x0
class = (struct lock_class *) 0xc0663eac
w = (struct witness *) 0xc0693eb0
w1 = (struct witness *) 0xc0693eb0
td = (struct thread *) 0xc06b77a4
i = -1
j = 0
go_into_ddb = 0
#4 0xc04dac8a in _mtx_lock_flags (m=0xc06b77a4, opts=0, file=0xc0663eac
"{idÀ\t", line=-998326128)
at /usr/src/sys/kern/kern_mutex.c:336
No locals.
#5 0xc055871e in rtrequest1 (req=2, info=0xcdb1aac8, ret_nrt=0x0) at
/usr/src/sys/net/route.c:565
error = 0
rt = (struct rtentry *) 0xc47ec000
rn = (struct radix_node *) 0xc06b77a4
rnh = (struct radix_node_head *) 0xc29e6400
ifa = (struct ifaddr *) 0x1
ndst = (struct sockaddr *) 0xc47ec090
#6 0xc05584fa in rtrequest (req=0, dst=0x0, gateway=0x0, netmask=0x0,
flags=0, ret_nrt=0x0)
at /usr/src/sys/net/route.c:477
info = {rti_addrs = 0, rti_info = {0xc3951ea0, 0xc3951eb0, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0},
---Type to continue, or q to quit---
rti_flags = 2087, rti_ifa = 0x0, rti_ifp = 0x0}
#7 0xc0559131 in rt_setgate (rt=0xc47ec000, dst=0xc3951ea0,
gate=0xc066d75c) at /usr/src/sys/net/route.c:938
rnh = (struct radix_node_head *) 0xc29e6400
new = 0xcdb1aac8 ""
old = 0xc06b84c0 "¬>fÀ\"\005dÀ\"\005dÀ"
dlen = 16
glen = 16
#8 0xc05582df in rtredirect (dst=0xc066d74c, gateway=0xc066d75c,
netmask=0x0, flags=38, src=0xc066d76c)
at /usr/src/sys/net/route.c:369
rt = (struct rtentry *) 0xc47ec000
error = 0
stat = (short int *) 0xc06b8894
info = {rti_addrs = 582, rti_info = {0xc0663eac, 0x0,
0xc06931a0, 0x3f1, 0xc063a81f, 0xcdb1ab98,
0xc04d, 0xc06931a0}, rti_flags = 1, rti_ifa = 0xc0637b5e,
rti_ifp =
Re: problems with sysinstall
Sergey Matveychuk wrote:
> Richard Nyberg wrote:
> >Doug White wrote:
> > > yes, this is a change to -current. It is for your own safety.
> >
> > I think this change in current is for the worse. I don't see why
> > I can't manage slices and partitions from my regular OS, but have
> > to boot up a CD to do the job. It's not even safer; I am perfectly
> > capable of destroying my disk layout from the CD too.
>
> Agree. Why I can't change active slice? Or add a partition? Or repair my
> master boot record?
> It's absolutely safe.
Its a major PITA and POLA violation IMHO.
The super-user should be able to foot-shoot whatever she wants to.
For example, you setup a production box with a 60 gig disk. You allocate
40 gig initially, leaving 20 gig as "reserve". Time passes. You now need
that extra 20 gig but can not down the server. You are stuffed.
--
:{ [EMAIL PROTECTED]
Andy Farkas
System Administrator
Speednet Communications
http://www.speednet.com.au/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
jumbograms (& em) & nfs a no go
I wanted to test gigabit network performance and found out that current (from 5.0 to up to date -current) doesn't fully work with jumbograms (MTU set to 6000), Intel adapters and nfs (both UDP and TCP). I checked that the same thing works with 4.9. I then left one computer at 4.9 and upgraded the other to 5.0. When I mount a partition from 5.0 machine I found out, that copying reliably works only from 5.0 to 4.9. The other way around I see messages 'em0: discard oversize frame (ether type 800 flags 3 len 67582 > max 6014)' on 5.0 and the copying stalls. On 4.9 machine I later see 'nfs server 10.0.0.2:/usr: not responding'. The interface is stuck for some time - can be revived by changing mtu back to 1500 and down/up sequence. -- Michal Mertl ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Postfix locks 5.1-servers?
Hi Terry, first thanks for your answer. > It's very common, for shell prompts which include the host name, or > for some shells that are too stupid to realize that the prompt string > does not require the host name, to do a DNS query in order to get the > name of the machine they are running on. I have had this case once a time (nameserver was down). After a timeout (i think it was a reverse lookup from sshd), shell works. I am using zsh. This is no explanation for a crash (one apache is dead, ftp logins does not work, logins on local console does not work: after typing user and hitting enter nothing happened). > If the session is already established, and you aren't using "bash" > as your shell, then typing "^C" might get you a default prompt and > drop you to a shell. No, that doesnt work. Even "ctr-alt-del" does not have an effect. > Alternately, you can run a split horizon DNS and/or a local caching > DNS server with a preloaded cache for all local machines to avoid a > real DNS lookup. Maybe an entry in /etc/hosts ? I will try this, because it is a good idea regarding to "stupid shells" ;) Andy -- Andy Hilker -- mailto:[EMAIL PROTECTED] http://www.cryptobank.de -- PGP Key: https://ca.crypta.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Anyone object to the following change in libc?
On Thu, 30 Oct 2003, Terry Lambert wrote:
TL>Harti Brandt wrote:
TL>> TL>Paragraph 6 of:
TL>> TL>
TL>> TL> http://www.opengroup.org/onlinepubs/007904975/functions/sscanf.html
TL>> TL>
TL>> TL>Implies that the lack of characters in the string following the
TL>> TL>conversion, due to failure in assignment, should result in an
TL>> TL>"Input failure". Note also that stdio.h defines EOF as -1.
TL>>
TL>> I fail to locate this paragraph. This interpretation would also imply
TL>> that scanf() always needs to return -1 whenever it cannot match a format
TL>> specifier.
TL>
TL> The fscanf() functions shall execute each directive of the
TL> format in turn. If a directive fails, as detailed below, the
TL> function shall return. Failures are described as input
TL> failures (due to the unavailability of input bytes) or
TL> matching failures (due to inappropriate input).
TL>
TL>It comes down to how you interpret the NUL byte at the end of the
TL>sscanf() input string. Is it an EOF? Or is it an unavailability of
TL>input bytes? The answer to the question picks which return value
TL>is correct.
Section 7.19.6.7 of N843 states:
"Reaching the end of the string is equivalent to encountering end-of-file
for the fscanf function."
Unfortunately this is missing in POSIX, but obviously implied by their
reference to ISO.
The next paragraph states:
"The sscanf function returns the value of the macro EOF if an input
failure occurs before any conversion."
Again: do we have a conversion? We have! Should we return EOF? No.
TL>
TL>
TL>> TL>I think it can be interpreted either way, still.
TL>>
TL>> You miss the section about RETURN VALUE: EOF is return on a read error.
TL>> This is not an input error.
TL>
TL>How do I distinguish a "return value is -1 as an error result" from
TL>"return value is -1 as an EOF result"?
Well, I suppose that's the intention of having scanf() setting errno
when it returns -1 in POSIX. Unfortunately POSIX fails to describe
the error codes. This is possibly fodder for the aardvark.
TL>
TL>
TL>> You should also read the very 1st paragraph. This clearly states, that
TL>> ISO is the primary source of information and the ISO text is a lot
TL>> cleaner.
TL>
TL>No, that's not what it actually states; here's the paragraph:
TL>
TL> The functionality described on this reference page is
TL> aligned with the ISO C standard. Any conflict between
TL> the requirements described here and the ISO C standard
TL> is unintentional. This volume of IEEE Std 1003.1-2001
TL> defers to the ISO C standard.
TL>
TL>It says that any conflicts are unintentional, and their intent was
TL>to use different language for no good reason, rather than just
TL>copying it verbatim and removing any doubt. It does *NOT* say
TL>that no conflicts exist.
Yes. But I take the last sentence to mean that ISO-C takes over in the
case a conflict exists.
TL>
TL>Also: In this context, which is IEEE 1003.1-2001, Issue 6, "the
TL>ISO C standard" refers to "c89", which is the version of the C
TL>standard that was in effect at the time that SVID IV was defined.
Line 107 of Austin TC-1:
"The c89 utility (which specified a compiler for the C Language specified
by the 108 ISO/IEC 9899: 1990 standard) has been replaced by a c99 utility
(which specifies a compiler for 109 the C Language specified by the
ISO/IEC 9899: 1999 standard)."
TL>If you need clarification on this issue, you should download the
TL>currently available version of the NIST/PCTS, which specifically
TL>requires you to compile with a c89 compiler, not one more recent.
TL>The same is true of The Open Group test suites which are available
TL>on the Internet.
TL>
TL>The version of the ISO C standard you are quoting from is *NOT*
TL>the c89 version.
Our sscanf() claims conformance to C99. So if we change the behaviour
we have to remove this claim.
TL>This makes interpretation ambiguous, since the test you are
TL>specifically referencing to get the 0 result is text that was
TL>added to the next version of the standard to clarify it.
TL>
TL>
TL>> I think it makes no sense to classify
TL>>
TL>> sscanf("123", "%*d%d", ...
TL>>
TL>> as an error, but
TL>>
TL>> sscanf("123", "%d%d", ...
TL>>
TL>> not, does it? Also at least Solaris 9 return -1 but fails to set
TL>> errno. Which is simply a bug.
TL>
TL>It makes no sense to do conversions without assignment in the
TL>first place (IMO).
[... Stuff about sense removed (I was talking about what return
code makes sense, not whether calling sscanf makes sense) ...]
TL>In any case, we are practically guaranteed that returning -1, as
TL>all other UNIX-like OS's currently do, would result in less source
TL>code breaking.
No coder in his right mind should have written code that depends
on this behaviour given the moot formulations in the classical books,
man pages and pre-C99 standards. Also note, that the reason for
this change request was that configuration scripts break, not applications.
If applications bre
Re: Postfix locks 5.1-servers?
Andy Hilker wrote: > i am using current. Similar problems *without* postfix. Login via ssh > results in print motd, but nothing more. > Login on local console results in nothing after pressing enter on > username. I think you have a different problem than the one that started this thread. It's very common, for shell prompts which include the host name, or for some shells that are too stupid to realize that the prompt string does not require the host name, to do a DNS query in order to get the name of the machine they are running on. The normal result for this when the DNS server is unavailable (or is accidently firewalled) is to lock up, either temporarily, or permananently, depending on how badly the shell wants the information. If the session is already established, and you aren't using "bash" as your shell, then typing "^C" might get you a default prompt and drop you to a shell. Note that a number of these shells are incredibly stupid, and will attempt to get the host name (and canonize it) on each prompt display. It's often useful to install the real "sh" (ash) or the real csh (not zsh, not tcsh, not bash, etc.) from ports, so that the stupid shell doesn't cause this sort of problem. Alternately, you can run a split horizon DNS and/or a local caching DNS server with a preloaded cache for all local machines to avoid a real DNS lookup. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: problems with sysinstall
Doug White wrote: > I don't know how WinXP's bootblocks are set up, but I have this setup on > Win2k and it works as expected with boot0. They are set up to boot directly from NTFS. An NTFS without a small FAT/FAT16/FAT32 partition for initial load will prevent the boot selector code from booting Windows XP. FWIW, I use a small FAT32 partition in conjuction with BootMagic (from the PartitionMagic folks) with my dual boot XP systems (I have two of them). -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sysinstall's fdisk/disklabel should be improved
Ulrich Spoerlein wrote: > On Tue, 28.10.2003 at 23:29:03 -0800, David O'Brien wrote: > > It is NOT useless. Why do you think it is? Perhaps you don't relize > > that some BIOS's wont boot from a hard disk that isn't partitioned to > > agree with the specifications of the PeeCee. If you want to treat your > > PC as a Sun, don't -- buy a Sun, FreeBSD runs on that too. > > What exactly do you mean by "PC Specification"? I'm not trying to make a > "dangerously dedicated" disk. I just don't need a spare 63 sectors for > DOS-compatibility. And leaving the first 63 sectors untouched is a > DOS-ism, not a PC-ism. Ironically, the best reference for FDISK-style layout of partition tables, use of the fields in the FDISK partition table structure, and general reference on checksums, 0xAA55, and the rest that I have ever found is the PReP specification, chapter 6. That's Power PC Reference Platform Specification, in case you were wondering; it's a Motorolla document intended for use on Motorolla hardware. Some DEC (Compaq? Hewlett-Compaqard?) Alpha firmware has the same requirement that PReP has in this regard. So do most OSs that run on x86 hardware, even when they are run on non-x86 hardware (Solaris, et. al.). I agree that the code could be cleaned up, but the layout on the disk is pretty intentional. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Anyone object to the following change in libc?
Harti Brandt wrote:
> TL>Paragraph 6 of:
> TL>
> TL> http://www.opengroup.org/onlinepubs/007904975/functions/sscanf.html
> TL>
> TL>Implies that the lack of characters in the string following the
> TL>conversion, due to failure in assignment, should result in an
> TL>"Input failure". Note also that stdio.h defines EOF as -1.
>
> I fail to locate this paragraph. This interpretation would also imply
> that scanf() always needs to return -1 whenever it cannot match a format
> specifier.
The fscanf() functions shall execute each directive of the
format in turn. If a directive fails, as detailed below, the
function shall return. Failures are described as input
failures (due to the unavailability of input bytes) or
matching failures (due to inappropriate input).
It comes down to how you interpret the NUL byte at the end of the
sscanf() input string. Is it an EOF? Or is it an unavailability of
input bytes? The answer to the question picks which return value
is correct.
> TL>I think it can be interpreted either way, still.
>
> You miss the section about RETURN VALUE: EOF is return on a read error.
> This is not an input error.
How do I distinguish a "return value is -1 as an error result" from
"return value is -1 as an EOF result"?
> You should also read the very 1st paragraph. This clearly states, that
> ISO is the primary source of information and the ISO text is a lot
> cleaner.
No, that's not what it actually states; here's the paragraph:
The functionality described on this reference page is
aligned with the ISO C standard. Any conflict between
the requirements described here and the ISO C standard
is unintentional. This volume of IEEE Std 1003.1-2001
defers to the ISO C standard.
It says that any conflicts are unintentional, and their intent was
to use different language for no good reason, rather than just
copying it verbatim and removing any doubt. It does *NOT* say
that no conflicts exist.
Also: In this context, which is IEEE 1003.1-2001, Issue 6, "the
ISO C standard" refers to "c89", which is the version of the C
standard that was in effect at the time that SVID IV was defined.
If you need clarification on this issue, you should download the
currently available version of the NIST/PCTS, which specifically
requires you to compile with a c89 compiler, not one more recent.
The same is true of The Open Group test suites which are available
on the Internet.
The version of the ISO C standard you are quoting from is *NOT*
the c89 version.
This makes interpretation ambiguous, since the test you are
specifically referencing to get the 0 result is text that was
added to the next version of the standard to clarify it.
> I think it makes no sense to classify
>
> sscanf("123", "%*d%d", ...
>
> as an error, but
>
> sscanf("123", "%d%d", ...
>
> not, does it? Also at least Solaris 9 return -1 but fails to set
> errno. Which is simply a bug.
It makes no sense to do conversions without assignment in the
first place (IMO).
Also, it makes no sense to call sscanf() with a string with too few
arguments, considering that you are providing the arguments to it in
the first place. You are effectively using sscanf() to validate an
ambiguous set of data as part of its operation.
I'm not sure that this is reasonable to do. Specifically, none of
the referenced standards expects this to happen with sscanf(), since
they do not define, specifically, how the end of the input string
should be interpreted: EOF vs. unavailability of input bytes. One
could argue that an unavailability of matching input bytes results
only from the separator character(s) between format strings not
being matched properly. At that point, "%d%d" (or "%*d%d") is a
non-sensical format specifier entirely, since any characters that
would be valid for input to the second specifier would also be valid
for input to the first: and the matching is, by definition, greedy.
Really, this is a problem which has occurred because you are not
using fscanf() or scanf() on the input stream, instead of doing
some conversion into an internal buffer, presumably to avoid a
buffer overflow and/or bitch about the standards being specified
inadequately in comp.lang.c, or on [EMAIL PROTECTED]
In other words, overly anal buffer overflow checking, rather than
specifying the buffer length in the format string.
In terms of standards conformance, I'd like to see the output of a
conformance test suite for ISO C (any version) complaining about the
-1 return. I think IEEE 1003.1-2001 conformance is probably more
important, if we have to pick one or the other on the basis of what
sscanf() is going to return in this manufactured problem case.
I'd also like to point out that the compiler we are using permits
the standards conformance version to be chosen at compile time, but
routines like sscanf(), unless they are inlined in header files,
are not conditionally selectable based on
Re: problems with sysinstall
Richard Nyberg wrote: >Doug White wrote: > > yes, this is a change to -current. It is for your own safety. > I think this change in current is for the worse. I don't see why I can't manage slices and partitions from my regular OS, but have to boot up a CD to do the job. It's not even safer; I am perfectly capable of destroying my disk layout from the CD too. Agree. Why I can't change active slice? Or add a partition? Or repair my master boot record? It's absolutely safe. Sem. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Palm and USB: 5-CURRENT, 4-CURRENT, or 4.9-RELEASE?
Jason Barnes wrote: I am trying to get my Palm Tungsten-E to sync with my FreeBSD Hi Jason, I had the interesting task of getting my Tungsten-W to sync the other week, which I succeeded with, after a few tweaks. I'm running 5.1-REL, with a couple of patches, see PRs: kern/58366 and kern/46488 You'll have to obtain the Tungsten-E product ID by doing a "usbdevs -v" after you've pressed the hotsync button. Then simply modify the patches in kern/58366 to reflect the E rather than the W. Apply patches and rebuild. I have the following added to my /etc/usbd.conf, above the "USB device" entry: # PPP for Palm Tungsten W device "Palm Tungsten W" devname "ucom[0-9]" vendor 0x0830 product 0x0031 attach "/usr/sbin/ppp -auto palm; /usr/local/bin/pi-csd -H sarah -a 192.168.2.3 -n 255.255.255.0&" detach "killall ppp; killall pi-csd" In this case "sarah" is the local hostname, and 192.168.2.3 is the local IP of the system. You will have to adjust the product ID here too. Oh, and be careful with the "killall ppp", you might want to change that to something a bit more sophisticated :) For the /etc/ppp/ppp.conf, I have the following section: palm: set device /dev/ucom0 set cd off set dial set speed 57600 set timeout 300 set redial 5 0 set reconnect 3 5 set ctsrts on set ifaddr 192.168.2.3 192.168.2.253 enable dns open Again, 192.168.2.3 is the local IP, 192.168.2.253 is the IP assigned to the Palm. In the kernel config, I have device ucom device uvisor (or you could load it as modules I suppose) Finally, for the serial port setting in jpilot (or pilot-xfer), use the portname "net:any". Unfortunately my Palm is away on repair at the moment, so I can't give you the exact details of the PPP setup of it, sorry. Follow what was outlined in the workaround, and you should get it to work (that's what I did). The important thing is that once you have set it up for LAN sync over PPP over Cradle/cable, you'll have to actually go into the HotSync app and tap the sync button there. Pressing the sync button on the cradle forces it to do a local cradle/cable sync, unfortunately. I think that includes everything I did... took me a few hours to get it all working! Now, I don't know if the Tungsten-E is running PalmOS 4 or 5. If it's 5, then there might be additional issues with the syncing, as I hear rumors saying that the hotsync protocol changed in PalmOS 5. Hope that helps... /Johny -- Johny Mattsson - System Designer ,-. ,-. ,-. There is no truth. http://www.earthmagic.org _.' `-' `-' There is only perception. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: problems with sysinstall
At Wed, 29 Oct 2003 17:32:29 -0800 (PST), Doug White wrote: > Sergey Matveychuk wrote: > > Doug White wrote: > > > This is normal and for your protection. you can't edit the disk you're > > > running off of. If you are running off of ad1, make sure 1) you're root > > > when you run sysinstall and b) you aren't mounting any filesystems from > > > ad0. > > > > Well, I understand it for slices. But why I can't create new partition > > in exist slice and newfs it? It was OK in -stable. I fail to understand either. > yes, this is a change to -current. It is for your own safety. I think this change in current is for the worse. I don't see why I can't manage slices and partitions from my regular OS, but have to boot up a CD to do the job. It's not even safer; I am perfectly capable of destroying my disk layout from the CD too. -Richard ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADSUP: MPSAFE network drivers
On Wed, Oct 29, 2003 at 11:52:48AM -0700, Sam Leffler wrote: +> I'm committing changes to mark various network drivers' interrupt handlers +> MPSAFE. To insure folks have a way to backout if they hit problems I've also +> added a tunable that lets you disable this w/o rebuilding your kernel. By +> default all network drivers that register an interrupt handler INTR_MPSAFE +> are setup to run their ISR w/o Giant. If you want to defeat this w/o +> changing the code you can set +> +> debug.mpsafenet=0 +> +> from the loader when booting and the MPSAFE bit will automatically be removed. +> I plan to use this to also control forthcoming changes for registering MPSAFE +> netisrs. +> +> The following drivers are marked MPSAFE: +> +> ath, em, ep, fxp, sn, wi, sis +> +> I've got changes coming for bge. Other drivers probably can be marked MPSAFE +> but I'm only doing it for those drivers that I can test. Because there is so many drivers, maybe you could prepare some regression tests designed to check changed things. This will allow people to test your changes - it is not very easy now if we don't know what we're looking for exactly PLUS those drivers aren't marked MPSAFE by default. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
[pecquetj@jpe45305.homeunix.org: kern/58581: System call hang 5.x triggered by gnunetd]
Is anyone else able to reproduce this? - Forwarded message from pecquetj <[EMAIL PROTECTED]> - >Number: 58581 >Category: kern >Synopsis: System call hang 5.x triggered by gnunetd >Confidential: no >Severity: serious >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Oct 26 14:40:17 PST 2003 >Closed-Date: >Last-Modified: >Originator: pecquetj >Release:FreeBSD 5.1 CURRENT i386 >Organization: >Environment: System: FreeBSD gnunet.woh.rr.com 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Sun Oct 26 11:49:08 EST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/GNUNET i386 The system is an STB1030 (mediagx) running 5.1-CURRENT downloaded including libs and buildworled from cvs >Description: When running GNUnet after some random time it stops responding. TOP indicates 100% system time utilization (0% user). ktrace stops outputting at this point. The last part of the ktrace dump is: 5863 gnunetd RET read 1116/0x45c 5863 gnunetd CALL gettimeofday(0xbfad64a8,0xbfad64b0) 5863 gnunetd RET gettimeofday 0 5863 gnunetd CALL break(0xd24c000) 5863 gnunetd RET break 0 5863 gnunetd PSIG SIGPROF caught handler=0x281e0ac0 mask=0x0 code=0x0 5863 gnunetd CALL gettimeofday(0x281f1b18,0) 5863 gnunetd RET gettimeofday 0 No further ktrace information is logged once this happens. Compiling with INVARIENTS and WITNESS did not change this behavior or result in any logged errors. gnunetd appears to be unable to respond to any signals except -9 at this point. I attempted multiple updates of 5.1, starting from RELEASE through three updates of CURRENT with no change in behaviour. If the system uses the TSC for the clock, the clock will stop when the above event occurs (i.e. the time in the upper right corner of top does not change, and date returns the same time over and over.) Using i8254 for the clock seems to avoid this side effect, as the clock seems to be unaffected. Attempting truss on gnunetd gives large numbers of WITNESS warnings that do not appear to be directly related to the problem: Oct 26 10:00:02 gnunet kernel: Sleeping on "stopevent" with the following non-sleepable locks held: Oct 26 10:00:02 gnunet kernel: exclusive sleep mutex sigacts r = 0 (0xc2c5faa8) locked @ /usr/src/sys/kern/subr_trap.c:260 Oct 26 10:00:02 gnunet kernel: Sleeping on "stopevent" with the following non-sleepable locks held: Oct 26 10:00:02 gnunet kernel: exclusive sleep mutex sigacts r = 0 (0xc2c5faa8) locked @ /usr/src/sys/kern/subr_trap.c:260 Oct 26 10:00:02 gnunet kernel: Sleeping on "stopevent" with the following non-sleepable locks held: Oct 26 10:00:02 gnunet kernel: exclusive sleep mutex sigacts r = 0 (0xc2c5faa8) locked @ /usr/src/sys/kern/subr_trap.c:260 Oct 26 10:00:02 gnunet kernel: Sleeping on "stopevent" with the following non-sleepable locks held: Oct 26 10:00:02 gnunet kernel: exclusive sleep mutex sigacts r = 0 (0xc2c5faa8) locked @ /usr/src/sys/kern/subr_trap.c:260 >How-To-Repeat: install /usr/ports/net/gnunet create user for running gnunetd (say: gnucli) su - gnucli mkdir .gnunet cp /usr/ports/net/gnunet/work/GNUnet-0.6.0/contrib/gnunet.conf ~/.gnunet run gnunetd use truss or ktrace if you feel like it wait a while it _always_ hangs as described above. it sometimes hangs faster if you attempt to insert into the node: gnunet-insert filename >Fix: >Release-Note: >Audit-Trail: >Unformatted: ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "[EMAIL PROTECTED]" - End forwarded message - ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
LOR route.c:182
lock order reversal 1st 0xc220b690 rtentry (rtentry) @ /usr/src/sys/net/route.c:182 2nd 0xc204807c radix node head (radix node head) @ /usr/src/sys/net/route.c:133 Stack backtrace: backtrace(c087588d,c204807c,c087b88a,c087b88a,c087b8e0) at backtrace+0x17 witness_lock(c204807c,8,c087b8e0,85,c087b8e0) at witness_lock+0x672 _mtx_lock_flags(c204807c,0,c087b8e0,85,0) at _mtx_lock_flags+0xba rtalloc1(c08d657c,1,1,3d8,c8f44b30) at rtalloc1+0x79 rt_setgate(c220b600,c2255a40,c08d657c,1,0) at rt_setgate+0x268 rtredirect(c08d656c,c08d657c,0,6,c08d658c) at rtredirect+0x1bf icmp_input(c1397c00,14,c0666d13,c093af88,c093b280) at icmp_input+0x4ff ip_input(c1397c00,0,c087b5f5,89,0) at ip_input+0xae8 netisr_processqueue(c0961b10,0,c087b5f5,e5,c1f491c0) at netisr_processqueue+0x8e swi_net(0,0,c0870582,21b,c137e974) at swi_net+0x98 ithread_loop(c137cd00,c8f44d48,c08703f4,311,0) at ithread_loop+0x192 fork_exit(c062bbe0,c137cd00,c8f44d48) at fork_exit+0xb4 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xc8f44d7c, ebp = 0 --- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
