XL driver checksum producing corrupted but checksum-correct packets
I tracked down an occassional buildworld failure on DragonFly to my XL driver, which is synchronized to 4.x's XL driver. What was occuring was that NFS would send an access/lookup RPC and the data in the packet would get corrupted by the XL hardware, and the XL hardware would apply a valid checksum to the corrupted packet so the NFS receiver had no idea that the packet contained corrupted data. By tcpdumping on both the client and the server I observed the client believing it had sent a valid access RPC and the server receiving a corrupted access RPC with a valid checksum, then returning an error back to the client e.g. like EPROTONOSUPPORT. The corruption seemed to occur about one out of every million packets or so. In DFly the corruption was especially detectable doing buildworlds with /usr/src mounted via NFSv3/UDP, with /usr/bin/* residented (A DFly feature which replaced the prior prelinking code we had with something much better, which FreeBSD-5.x might want to adopt since 5.x is using dynamic binaries for /bin now). About once every 3 buildworlds, typicaly mkdep failing with weird open() errors returned by the server after it had tried to process the corrupted NFS access/lookup rpc request. I also observed it with /usr/bin/* not residented but at a much lower frequency... once every 10 buildworlds. I'm not sure why there was a difference. Turning off hardware checksums with ifconfig solved the problem, and I made it the default for DFly. I recommend that FreeBSD turn off hardware assisted checksums in the XL driver by default too. Here is the pciconf -l output for the XL PCI card I am using: [EMAIL PROTECTED]:6:0: class=0x02 card=0x764610b7 chip=0x764610b7 rev=0x30 hdr=0x00 -Matt Matthew Dillon <[EMAIL PROTECTED]> ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: read-only compressed fs (call for testers) [UPDATE]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > Thank you by the FreeSBIE team. You can try a FreeSBIE iso with the geom_ugz patch (compressed fs) at: http://www.willystudios.com/freesbie/FreeSBIE-cloop-test.iso.bz2 I haven't exact numbers to explain the perfomance growth, but it's really _very_ fast compared to "normal" version. As filename said, this is a test version, then any feedback is appreciated. Bye, Dario - -- Dario Freni ([EMAIL PROTECTED]) - SaturNero on IRCNet, Azzurra Gruppo Utenti FreeBSD Italia (http://www.gufi.org) GPG Public key at http://www.saturnero.net/saturnero.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQFAEdU3Z1XqWj1OqUERAsONAKDAMP7L/UIJYwC6r+SSuoA+tqt28gCcDstb nrcFjHFrhvQzuvFZguJcUk4= =OCPC -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD 5.2-RELEASE buildworld failure.
I cvsuped today using tag RELENG_5_2 (i'm already using 5.2-RELEASE), i noticed there was only documentation changes, and no real source changes, i was preparing to recompile everything using some different optimizations: " erek# cat /etc/make.conf CFLAGS+= -pipe -march=athlon-xp -mcpu=athlon-xp -mmmx -m3dnow -ffast-math -msse -mfpmath=sse,387 CXXFLAGS+= -pipe -march=athlon-xp -mcpu=athlon-xp -mmmx -m3dnow -ffast-math -msse -mfpmath=sse,387 COPTFLAGS+= -pipe -march=athlon-xp -mcpu=athlon-xp -mmmx -m3dnow -ffast-math -msse -mfpmath=sse,387 " Previously i had unroll-loops in my optimizations and i heard this could actually be slower on modern CPUs, so i removed it. During the buildworld I get this VERY odd error: "mkdep -f .depend -a-DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr/obj/usr/src/i386 /usr\" -I/usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/usr /src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1plus/../../ ../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/conf ig -I/usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp -I. -I/usr/obj/u sr/src/i386/legacy/usr/include parse+%DIKED.c /usr/src/gnu/usr.bin/cc/cc1plus/. ./../../../contrib/gcc/main.c /usr/src/gnu/usr.bin/cc/cc1plus/../../../../contri b/gcc/cp/cp-lang.c /usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/c-opt s.c /usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/call.c /usr/src/g nu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/class.c /usr/src/gnu/usr.bin/cc /cc1plus/../../../../contrib/gcc/cp/cvt.c /usr/src/gnu/usr.bin/cc/cc1plus/../../ ../../contrib/gcc/cp/decl.c /usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/ gcc/cp/decl2.c /usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/error. c /usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/except.c /usr/src/g nu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/expr.c /usr/src/gnu/usr.bin/cc/ cc1plus/../../../../contrib/gcc/cp/friend.c /usr/src/gnu/usr.bin/cc/cc1plus/../. ./../../contrib/gcc/cp/init.c /usr/src/gnu/usr.bin/cc/cc1plus/../../../../contri b/gcc/cp/lex.c /usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/mangle .c /usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/method.c /usr/src/ gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/pt.c /usr/src/gnu/usr.bin/cc/c c1plus/../../../../contrib/gcc/cp/ptree.c /usr/src/gnu/usr.bin/cc/cc1plus/../../ ../../contrib/gcc/cp/repo.c /usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/ gcc/cp/rtti.c /usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/search. c /usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/semantics.c /usr/sr c/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/spew.c /usr/src/gnu/usr.bin/ cc/cc1plus/../../../../contrib/gcc/cp/tree.c /usr/src/gnu/usr.bin/cc/cc1plus/../ ../../../contrib/gcc/cp/typeck.c /usr/src/gnu/usr.bin/cc/cc1plus/../../../../con trib/gcc/cp/typeck2.c /usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp /dump.c /usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/optimize.c In file included from /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc_tools/tcon fig.h:17, from /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc_tools/hcon fig.h:2, from /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc_tools/conf ig.h:1, from /usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp /parse.y:31, from /usr/src/contrib/gcc/cp/lex.c:33: /usr/src/gnu/usr.bin/cc/cc_tools/freebsd-native.h:62:25: attempt to use poisoned "malloc" /usr/src/gnu/usr.bin/cc/cc_tools/freebsd-native.h:63:25: attempt to use poisoned "calloc" /usr/src/gnu/usr.bin/cc/cc_tools/freebsd-native.h:64:25: attempt to use poisoned "realloc" /usr/src/gnu/usr.bin/cc/cc_tools/freebsd-native.h:65:25: attempt to use poisoned "strdup" In file included from /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc_tools/tcon fig.h:17, from /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc_tools/hcon fig.h:2, from /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc_tools/conf ig.h:1, from /usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp /parse.y:31, from /usr/src/contrib/gcc/cp/pt.c:37: /usr/src/gnu/usr.bin/cc/cc_tools/freebsd-native.h:62:25: attempt to use poisoned "malloc" /usr/src/gnu/usr.bin/cc/cc_tools/freebsd-native.h:63:25: attempt to use poisoned "calloc" /usr/src/gnu/usr.bin/cc/cc_tools/freebsd-native.h:64:25: attempt to use poisoned "realloc" /usr/src/gnu/usr.bin/cc/cc_tools/freebsd-native.h:65:25: attempt to use poisoned "strdup" In file included from /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc_tools/tcon fig.h:17, from /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc_tools/hcon fig.h:2, from /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc_tools/conf ig.h:1, from /usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp /parse.
Re: send(2) does not block, send(2) man page wrong?
On 23 Jan, Stuart Pook wrote: >> send() for UDP should block if the socket is filled and the interface >> can't drain the data fast enough. > > It doesn't (at least I cannot make it block) > >> Good question. There is not feedback loop like in tcp, so handling this >> blocking and releasing would be a little bit harder to do for UDP. > > Send(2) indicates that it should do so. > >> > I have written a test program, >> > http://www.infres.enst.fr/~pook/send/server.c, that shows that send does >> > not block on FreeBSD. It does with Linux and Solaris. >> >> Do you know what the behaviour of Net- and/or OpenBSD is? > > NetBSD is the same as FreeBSD. I have not tested OpenBSD. > MacOS X is similiar to FreeBSD in that send doesn't block, howver > the send does not give an error: the packet is just thrown away. Which is the same result as you would get if the bottleneck is just one network hop away instead of at the local NIC. Even if you changed the network stack to block or return an error when it detected that it was tossing packets away, the application has no way of knowing that all, a majority of, or even any of its data was getting though even though it wasn't blocked by send() and didn't receive any error returns. Think about the case of a gigabit LAN connected to the Internet over a modem link. Even with a stack that blocked send() so that no packets were lost in the stack, the application would think it was sending data to a peer on the Internet at gigabit speeds, but in reality most of the traffic would be silently dropped. Even within the LAN, traffic could be dropped if the outgoing switch port was more congested than the link from the sending host to the NIC. If you want to send a lot of data as fast as possible using UDP, then you'll probably need to reinvent the TCP congestion avoidance algorithms in your application so that you don't overly impact the network. The application can't rely on send() blocking or returning errors, since you don't know that the local network interface is the bottleneck. Since the bottleneck could be anywhere, the application code is simpler if it relies on cues that are the same no matter where the bottleneck is located rather than adding extra code just to handle a local bottleneck. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: send(2) does not block, send(2) man page wrong?
On Fri, 23 Jan 2004, Andre Oppermann wrote: > Stuart Pook wrote: > >>send() for UDP should block if the socket is filled and the interface > >>can't drain the data fast enough. > > > > It doesn't (at least I cannot make it block) > > This stuff is rather complex. A send() on a UDP socket processes right > down to the if_output. If that fails because the ifqueue is full, the > packet will be free()d right away. No luck with blocking and retrying. > > >>Good question. There is not feedback loop like in tcp, so handling this > >>blocking and releasing would be a little bit harder to do for UDP. > > > > Send(2) indicates that it should do so. > > True. The only thing I can offer is that when one packet produces an > ENOBUFS, the socket will block on the next one for a couple of milliseconds. > Doing the full program requires significant changes to the current structure > of the BSD network code. > > You could do the same in userland with a call to nanosleep(2) when you get > a ENOBUFS. from memory that is what ping -f does.. > > >>>I have written a test program, > >>>http://www.infres.enst.fr/~pook/send/server.c, that shows that send does > >>>not block on FreeBSD. It does with Linux and Solaris. > >> > >>Do you know what the behaviour of Net- and/or OpenBSD is? > > > > NetBSD is the same as FreeBSD. I have not tested OpenBSD. > > MacOS X is similiar to FreeBSD in that send doesn't block, howver > > the send does not give an error: the packet is just thrown away. > > Browsing through the code I see that none of the BSDs are able to block > on an UDP send. > > -- > Andre > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
VOIP/Asterisk/Zaptel hardware for *BSD
All, I'm posting this here because I think a number of you may be interested in seeing a strong open source VOIP solution for FreeBSD. There's currently $1200 available as a bounty for someone to get Zaptel drivers written/ported to FreeBSD and get Asterisk up and running. For details on this bounty, please see: http://bugs.digium.com/bug_view_page.php?bug_id=847 I think this would be a great win for the FreeBSD community. If anyone on this list knows someone who might be interested in taking this bounty, please forward this along. If you wish to up the bounty, please feel free to post it. -- Troy Settle Pulaski Networks http://www.psknet.com 540.994.4254 ~ 866.477.5638 Pulaski Chamber 2002 Small Business Of The Year ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-isp To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 4.9 kernel panics on a poweredge 2650
On 23 Jan 2004 at 13:50, Bogdan TARU wrote: > > > Hi hackers, > > I am experiencing kernel panics on a poweredge 2650 each day around > 3am (usually the machine comes up at 3:04am). The kernel panics are > reproductable by running: /etc/periodic/security/100.chksetuid (in > fact by runnning find on /usr with -perms). The problem lies > somewhere in /usr/ports. Deleting the /usr/ports tree doesn't solve > it, trying a cvs up of /usr/ports results in a crash again. > Our experience is that repetitive crashes when dealing with large numbers of files (like the ports tree) generally points to hitting some OS resource limit. Some things to check that may or may not apply to this particular problem: sysctl vm.zone Make sure you're not hitting any of those limits. sysctl vm.kvm_size sysctl vm.kvm_free If kvm_free is running low just prior to the crash, you might want to increase your KVA_PAGES (see lint) and rebuild your kernel. Of course, this is all hit and miss guess work until you have a crash dump, so getting a crash dump and a traceback from a kernel identical to your running kernel with debugging symbols would be a logical first step if you want to avoid any guessing. If your tracebacks show failures in random locations, you're probably looking at bad RAM. If you always fail in the same spot with each crash, then it is just a matter of determining why and correcting it. I believe the freebsd developer's handbook has instructions on how to setup a system to do an automatic crash dump for any panic. It is relatively straightforward. Sincerely, Andrew Kinney President and Chief Technology Officer Advantagecom Networks, Inc. http://www.advantagecom.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Pseudo device question
Hi All, If I have a pseudo-device on FreeBSD 5.1 created using the make_dev call does anyone know how to grow this special file? I mean I don't want to write to this file initially but grow this device memory to a somewhat large limit. This is because I need to mmap this pseudo device into a user process memory and then use the mmaped memory...Can I do this by defining an ioctl() on this special file? If so what do I have to do to allocate some memory and to attach the allocated memory to this device? Thanks, Anand ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Patch for MDMFS.C
Having wanted to mount a mfs file system with a specific user and mode I discovered that mdmfs.c doesn't support such an option when called as mount_mfs. So, in a fit of lunacy/desparation I made a quick mod to it to provide such support, by disabling the automatic compat mode if another flag was given (it was either that or create mount_md). I had to use -Z as just about everything else was used, but it means that the following now works: md/var/spool/MIMEDefangmfs rw,async,-Z,-s256m,-p0700,-wmailnull:mailnull2 0 I've attached a patch that supports this for people's thoughts and comments. I'm afraid I didn't patch the man page, primarily because it's been too long and I suspect I'd break things. If my providing a patch for the man page is important then I'll see about doing that too. I don't follow this list I'm afraid, so if you want me to see something you'll need to CC me. TIA -- Rob | What part of "no" was it you didn't understand? _ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fopen() on a pipe blocks multi threated applications.
I use fbsd v4.9 release. On Fri, 23 Jan 2004, rmkml wrote: > Date: Fri, 23 Jan 2004 18:37:55 +0100 (CET) > From: rmkml <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: fopen() on a pipe blocks multi threated applications. > > Hi > > fopen() on a pipe blocks multi threated applications. > > If pipe is not ready for reading, fopen blocks every thread until STREAM > is ready. > > Is there a good reason for this ? > > Regards > > [EMAIL PROTECTED] > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
fopen() on a pipe blocks multi threated applications.
Hi fopen() on a pipe blocks multi threated applications. If pipe is not ready for reading, fopen blocks every thread until STREAM is ready. Is there a good reason for this ? Regards [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: send(2) does not block, send(2) man page wrong?
On Fri, Jan 23, 2004 at 06:09:20PM +0100, Andre Oppermann wrote: ... > >>send() for UDP should block if the socket is filled and the interface > >>can't drain the data fast enough. > > > > It doesn't (at least I cannot make it block) > > This stuff is rather complex. A send() on a UDP socket processes right > down to the if_output. If that fails because the ifqueue is full, the > packet will be free()d right away. No luck with blocking and retrying. and there would be no point in blocking given that the protocol (UDP) is unreliable and designed not to give any guarantee whatsoever. The most you can get is an error code on return from send()/write() and friends. Furthermore, send() and write() block on the socket buffer filling up, not on the interface queue. Because UDP has no output socket buffer, there is no way it can block. Finally, overflows in the interface queue are never handled by send() kernel code, not even for TCP: in this case, it is just TCP congestion control that acts and, either at the next incoming ACK, or upon a timeout, tries a retransmission. > > Send(2) indicates that it should do so. i admit the manpage should definitely be clarified -- it says 'if no message space is available at the socket...', but it does cover the UDP behaviour. Technically, in the UDP case there is always space at the sending socket, because that space is never used - by definition of the UDP protocol - and the packet goes straight to the ip layer and then down to the interface. cheers luigi ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: send(2) does not block, send(2) man page wrong?
Stuart Pook wrote: send() for UDP should block if the socket is filled and the interface can't drain the data fast enough. It doesn't (at least I cannot make it block) This stuff is rather complex. A send() on a UDP socket processes right down to the if_output. If that fails because the ifqueue is full, the packet will be free()d right away. No luck with blocking and retrying. Good question. There is not feedback loop like in tcp, so handling this blocking and releasing would be a little bit harder to do for UDP. Send(2) indicates that it should do so. True. The only thing I can offer is that when one packet produces an ENOBUFS, the socket will block on the next one for a couple of milliseconds. Doing the full program requires significant changes to the current structure of the BSD network code. You could do the same in userland with a call to nanosleep(2) when you get a ENOBUFS. I have written a test program, http://www.infres.enst.fr/~pook/send/server.c, that shows that send does not block on FreeBSD. It does with Linux and Solaris. Do you know what the behaviour of Net- and/or OpenBSD is? NetBSD is the same as FreeBSD. I have not tested OpenBSD. MacOS X is similiar to FreeBSD in that send doesn't block, howver the send does not give an error: the packet is just thrown away. Browsing through the code I see that none of the BSDs are able to block on an UDP send. -- Andre ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: send(2) does not block, send(2) man page wrong?
On Fri, Jan 23, 2004 at 04:25:07PM +0100, Stuart Pook wrote:
> The documentation for send(2) says
>
> If no messages space is available at the socket to hold the message to be
> transmitted, then send() normally blocks, unless the socket has been
> placed in non-blocking I/O mode. The select(2) call may be used to
> determine when it is possible to send more data.
>
> I cannot get send (or sendto which is what really interests me)
> to block on FreeBSD 4.9. When I send as fast as I can to a socket,
> send rapidly fails with ENOBUFS. I am not surprised that the kernel is
> running out of mbufs but I am surprised that send does not block until
> more become available.
>
> Select does not block either. It always says that I can write to the
> socket and then send fails with ENOBUFS.
>
> The udp_output function in /sys/netinet/udp_usrreq.c, seems clear:
>
> /*
> * Calculate data length and get a mbuf
> * for UDP and IP headers.
> */
> M_PREPEND(m, sizeof(struct udpiphdr), M_DONTWAIT);
> if (m == 0) {
> error = ENOBUFS;
> if (addr)
> splx(s);
> goto release;
> }
>
> There is no sign of send blocking waiting for a mbuf or of it returning
> EAGAIN if the socket is non-blocking.
>
> Is the documentation for send(2) wrong or is there some way to make
> send and sendto block?
>
> I have used setsockopt(s, SOL_SOCKET, SO_SNDBUF) to reduce the size
> of the output queue for the socket but send still returns ENOBUFS and
> never blocks or returns EAGAIN.
>
UDP sockets don't use send buffer (like TCP does) for storing data,
only receive buffer, so SO_SNDBUF only affects the maximum size of
one write operation.
Cheers,
--
Ruslan Ermilov
FreeBSD committer
[EMAIL PROTECTED]
pgp0.pgp
Description: PGP signature
Re: 5.2 install cd hangs on boot
> when i try to boot the freebsd install cd on my laptop (Ibm thinkpad > t40) it hangs after: > > cbb1: mem 0x5100-0x51000fff irq 11 at > device 0.1 on pci2 > cardbus1: on cbb1 > pccard1: <16-bit PCCard bus> on cbb1 > cbb1: [MPSAFE] I had similar problems with CardBus on the T40p. You may be interested in: http://www.scode.org/freebsdt40p.html Also freebsd-mobile is probably the better list for questions like these. I never did have trouble with the install CD though; but I ran with all PCMCIA slots empty. If you have any cards inserted, try removing them before booting the installation CD. -- / Peter Schuller, InfiDyne Technologies HB PGP userID: 0xE9758B7D or 'Peter Schuller <[EMAIL PROTECTED]>' Key retrieval: Send an E-Mail to [EMAIL PROTECTED] E-Mail: [EMAIL PROTECTED] Web: http://www.scode.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: send(2) does not block, send(2) man page wrong?
> send() for UDP should block if the socket is filled and the interface > can't drain the data fast enough. It doesn't (at least I cannot make it block) > Good question. There is not feedback loop like in tcp, so handling this > blocking and releasing would be a little bit harder to do for UDP. Send(2) indicates that it should do so. > > I have written a test program, > > http://www.infres.enst.fr/~pook/send/server.c, that shows that send does > > not block on FreeBSD. It does with Linux and Solaris. > > Do you know what the behaviour of Net- and/or OpenBSD is? NetBSD is the same as FreeBSD. I have not tested OpenBSD. MacOS X is similiar to FreeBSD in that send doesn't block, howver the send does not give an error: the packet is just thrown away. Stuart ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 4.9 kernel panics on a poweredge 2650
The box is remote (>300km), so cannot go into single user (have serial to it, but some stupid serial terminal server -- don't ask). Have tried to run fsck on the /usr partition (mounted, though -- so read only), but it didn't find any problems. bogdan On Fri, Jan 23, 2004 at 01:24:07PM -, Steven Hartland wrote: > may be a silly question have ur booted into single user and force checked > the disk may be some sort of fs corruption? > > Steve / K > - Original Message - > From: "Bogdan TARU" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: 23 January 2004 12:50 > Subject: 4.9 kernel panics on a poweredge 2650 > > > > > > > > Hi hackers, > > > > I am experiencing kernel panics on a poweredge 2650 each day around > > 3am (usually the machine comes up at 3:04am). The kernel panics are > > reproductable by running: /etc/periodic/security/100.chksetuid (in > > fact by runnning find on /usr with -perms). The problem lies > > somewhere in /usr/ports. Deleting the /usr/ports tree doesn't solve > > it, trying a cvs up of /usr/ports results in a crash again. > > > > I googled around a lil' bit, and found: > > http://lists.freebsd.org/pipermail/freebsd-hackers/2003-April/000192.html, > > and also Terry's answer, but that addresses freebsd 4.7. But my box > > is running 4.9-release, and the systems was cleanly installed with > > 4.9 from the very beginning, so not upgraded from 4.7 or any other > > previous version. > > > > The dmesg looks like: > > > > Copyright (c) 1992-2003 The FreeBSD Project. > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, > > 1994 > > The Regents of the University of California. All rights > > reserved. > > FreeBSD 4.9-RELEASE #1: Mon Nov 17 23:47:49 CET 2003 > > root@:/usr/src/sys/compile/saturn > > Timecounter "i8254" frequency 1193182 Hz > > Timecounter "TSC" frequency 1790761584 Hz > > CPU: Intel(R) Xeon(TM) CPU 1.80GHz (1790.76-MHz 686-class CPU) > > Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 > > > Features=0xbfebfbff T,TM,PBE> > > Hyperthreading: 2 logical CPUs > > real memory = 2147418112 (2097088K bytes) > > avail memory = 2088136704 (2039196K bytes) > > Preloaded elf kernel "kernel" at 0xc0312000. > > Warning: Pentium 4 CPU: PSE disabled > > Pentium Pro MTRR support enabled > > Using $PIR table, 9 entries at 0xc00fc430 > > npx0: on motherboard > > npx0: INT 16 interface > > pcib0: on motherboard > > pci0: on pcib0 > > pci0: (vendor=0x1028, dev=0x000c) at 4.0 irq 11 > > pci0: (vendor=0x1028, dev=0x0008) at 4.1 irq 10 > > pci0: (vendor=0x1028, dev=0x000d) at 4.2 irq 7 > > pci0: at 14.0 > > atapci0: port > > 0x8b0-0x8bf,0x8d8-0x8db,0x8d0-0x8d7,0x8c8-0x8cb,0x8c0-0x8c7 at device > > 15.1 on pci0 > > ata0: at 0x1f0 irq 14 on atapci0 > > ata1: at 0x170 irq 15 on atapci0 > > pci0: at 15.2 irq 5 > > isab0: at device 15.3 on > > pci0 > > isa0: on isab0 > > pcib1: on motherboard > > pci1: on pcib1 > > pcib2: on motherboard > > pci2: on pcib2 > > pcib3: on motherboard > > pci3: on pcib3 > > bge0: mem > > 0xfcf1-0xfcf1 irq 11 at device 6.0 on pci3 > > bge0: Ethernet address: 00:06:5b:f6:48:38 > > miibus0: on bge0 > > brgphy0: on miibus0 > > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, > > 1000baseTX-FDX, auto > > bge1: mem > > 0xfcf0-0xfcf0 irq 10 at device 8.0 on pci3 > > bge1: Ethernet address: 00:06:5b:f6:48:39 > > miibus1: on bge1 > > brgphy1: on miibus1 > > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, > > 1000baseTX-FDX, auto > > bge1: mem > > 0xfcf0-0xfcf0 irq 10 at device 8.0 on pci3 > > bge1: Ethernet address: 00:06:5b:f6:48:39 > > miibus1: on bge1 > > brgphy1: on miibus1 > > brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, > > 1000baseTX-FDX, auto > > pcib4: on > > motherboard > > pci4: on pcib4 > > pcib8: at device 8.0 on > > pci4 > > pci5: on pcib8 > > pci5: (vendor=0x9005, dev=0x00c5) at 6.0 irq 7 > > pci5: (vendor=0x9005, dev=0x00c5) at 6.1 irq 11 > > aac0: mem 0xf000-0xf7ff irq 7 at device 8.1 > > on pci4 > > aac0: i960RX 100MHz, 118MB cache memory, optional battery present > > aac0: Kernel 2.7-1, Build 3170, S/N 5010d3 > > aac0: Supported > > Options=75c > > pcib5: on > > motherboard > > pci6: on pcib5 > > pcib6: on > > motherboard > > pci7: on pcib6 > > pcib7: on > > motherboard > > pci8: on pcib7 > > orm0: at iomem > > 0xc-0xc7fff,0xc8000-0xcbfff,0xec000-0xe on isa0 > > pmtimer0 on isa0 > > fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on > > isa0 > > fdc0: FIFO enabled, 8 bytes threshold > > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > > atkbdc0: at port 0x60,0x64 on isa0 > > vga0: at port 0x3c0-0x3df iomem 0xa-0xb on > > isa0 > > sc0: at flags 0x100 on isa0 > > sc0: VGA <16 virtual consoles, flags=0x300> > > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > > sio0: type 16550A > > sio1 at port 0x2f8-0x2ff irq 3 on isa0 > > sio1: t
5.2 install cd hangs on boot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 this is my first post to freebsd mailinglists so i hope that im sending it to the right place ;) when i try to boot the freebsd install cd on my laptop (Ibm thinkpad t40) it hangs after: cbb1: mem 0x5100-0x51000fff irq 11 at device 0.1 on pci2 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 cbb1: [MPSAFE] anyone that have experienced this or might know of a solution ? I tried booting without acpi but that didnt help ;( from the info i found at google etc it seems that freebsd is known to have problems with certain laptop models... but i havent found any solutions though ;( // pierre -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3-nr1 (Windows XP) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAEUMYbKmHCtV7OGcRAnMvAKDZNH7z3/00FExYM7zGwKPUwV0yJACg2oyD gmNZZmM3euGkFCAfM3H5plg= =ZrD8 -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: send(2) does not block, send(2) man page wrong?
Stuart Pook wrote:
The documentation for send(2) says
If no messages space is available at the socket to hold the message to be
transmitted, then send() normally blocks, unless the socket has been
placed in non-blocking I/O mode. The select(2) call may be used to
determine when it is possible to send more data.
I cannot get send (or sendto which is what really interests me)
to block on FreeBSD 4.9. When I send as fast as I can to a socket,
send rapidly fails with ENOBUFS. I am not surprised that the kernel is
running out of mbufs but I am surprised that send does not block until
more become available.
Select does not block either. It always says that I can write to the
socket and then send fails with ENOBUFS.
send() for UDP should block if the socket is filled and the interface
can't drain the data fast enough.
The udp_output function in /sys/netinet/udp_usrreq.c, seems clear:
/*
* Calculate data length and get a mbuf
* for UDP and IP headers.
*/
M_PREPEND(m, sizeof(struct udpiphdr), M_DONTWAIT);
if (m == 0) {
error = ENOBUFS;
if (addr)
splx(s);
goto release;
}
There is no sign of send blocking waiting for a mbuf or of it returning
EAGAIN if the socket is non-blocking.
Is the documentation for send(2) wrong or is there some way to make
send and sendto block?
Good question. There is not feedback loop like in tcp, so handling this
blocking and releasing would be a little bit harder to do for UDP.
I have used setsockopt(s, SOL_SOCKET, SO_SNDBUF) to reduce the size
of the output queue for the socket but send still returns ENOBUFS and
never blocks or returns EAGAIN.
I note that send on Linux and Solaris blocks and that on these systems
select can be used to wait until the send will not block.
I have written a test program,
http://www.infres.enst.fr/~pook/send/server.c, that shows that send does
not block on FreeBSD. It does with Linux and Solaris.
Do you know what the behaviour of Net- and/or OpenBSD is?
--
Andre
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
send(2) does not block, send(2) man page wrong?
The documentation for send(2) says
If no messages space is available at the socket to hold the message to be
transmitted, then send() normally blocks, unless the socket has been
placed in non-blocking I/O mode. The select(2) call may be used to
determine when it is possible to send more data.
I cannot get send (or sendto which is what really interests me)
to block on FreeBSD 4.9. When I send as fast as I can to a socket,
send rapidly fails with ENOBUFS. I am not surprised that the kernel is
running out of mbufs but I am surprised that send does not block until
more become available.
Select does not block either. It always says that I can write to the
socket and then send fails with ENOBUFS.
The udp_output function in /sys/netinet/udp_usrreq.c, seems clear:
/*
* Calculate data length and get a mbuf
* for UDP and IP headers.
*/
M_PREPEND(m, sizeof(struct udpiphdr), M_DONTWAIT);
if (m == 0) {
error = ENOBUFS;
if (addr)
splx(s);
goto release;
}
There is no sign of send blocking waiting for a mbuf or of it returning
EAGAIN if the socket is non-blocking.
Is the documentation for send(2) wrong or is there some way to make
send and sendto block?
I have used setsockopt(s, SOL_SOCKET, SO_SNDBUF) to reduce the size
of the output queue for the socket but send still returns ENOBUFS and
never blocks or returns EAGAIN.
I note that send on Linux and Solaris blocks and that on these systems
select can be used to wait until the send will not block.
I have written a test program,
http://www.infres.enst.fr/~pook/send/server.c, that shows that send does
not block on FreeBSD. It does with Linux and Solaris.
thanks for your help
Stuart
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 4.9 kernel panics on a poweredge 2650
may be a silly question have ur booted into single user and force checked the disk may be some sort of fs corruption? Steve / K - Original Message - From: "Bogdan TARU" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: 23 January 2004 12:50 Subject: 4.9 kernel panics on a poweredge 2650 > > > Hi hackers, > > I am experiencing kernel panics on a poweredge 2650 each day around > 3am (usually the machine comes up at 3:04am). The kernel panics are > reproductable by running: /etc/periodic/security/100.chksetuid (in > fact by runnning find on /usr with -perms). The problem lies > somewhere in /usr/ports. Deleting the /usr/ports tree doesn't solve > it, trying a cvs up of /usr/ports results in a crash again. > > I googled around a lil' bit, and found: > http://lists.freebsd.org/pipermail/freebsd-hackers/2003-April/000192.html, > and also Terry's answer, but that addresses freebsd 4.7. But my box > is running 4.9-release, and the systems was cleanly installed with > 4.9 from the very beginning, so not upgraded from 4.7 or any other > previous version. > > The dmesg looks like: > > Copyright (c) 1992-2003 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, > 1994 > The Regents of the University of California. All rights > reserved. > FreeBSD 4.9-RELEASE #1: Mon Nov 17 23:47:49 CET 2003 > root@:/usr/src/sys/compile/saturn > Timecounter "i8254" frequency 1193182 Hz > Timecounter "TSC" frequency 1790761584 Hz > CPU: Intel(R) Xeon(TM) CPU 1.80GHz (1790.76-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 > Features=0xbfebfbff > Hyperthreading: 2 logical CPUs > real memory = 2147418112 (2097088K bytes) > avail memory = 2088136704 (2039196K bytes) > Preloaded elf kernel "kernel" at 0xc0312000. > Warning: Pentium 4 CPU: PSE disabled > Pentium Pro MTRR support enabled > Using $PIR table, 9 entries at 0xc00fc430 > npx0: on motherboard > npx0: INT 16 interface > pcib0: on motherboard > pci0: on pcib0 > pci0: (vendor=0x1028, dev=0x000c) at 4.0 irq 11 > pci0: (vendor=0x1028, dev=0x0008) at 4.1 irq 10 > pci0: (vendor=0x1028, dev=0x000d) at 4.2 irq 7 > pci0: at 14.0 > atapci0: port > 0x8b0-0x8bf,0x8d8-0x8db,0x8d0-0x8d7,0x8c8-0x8cb,0x8c0-0x8c7 at device > 15.1 on pci0 > ata0: at 0x1f0 irq 14 on atapci0 > ata1: at 0x170 irq 15 on atapci0 > pci0: at 15.2 irq 5 > isab0: at device 15.3 on > pci0 > isa0: on isab0 > pcib1: on motherboard > pci1: on pcib1 > pcib2: on motherboard > pci2: on pcib2 > pcib3: on motherboard > pci3: on pcib3 > bge0: mem > 0xfcf1-0xfcf1 irq 11 at device 6.0 on pci3 > bge0: Ethernet address: 00:06:5b:f6:48:38 > miibus0: on bge0 > brgphy0: on miibus0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, > 1000baseTX-FDX, auto > bge1: mem > 0xfcf0-0xfcf0 irq 10 at device 8.0 on pci3 > bge1: Ethernet address: 00:06:5b:f6:48:39 > miibus1: on bge1 > brgphy1: on miibus1 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, > 1000baseTX-FDX, auto > bge1: mem > 0xfcf0-0xfcf0 irq 10 at device 8.0 on pci3 > bge1: Ethernet address: 00:06:5b:f6:48:39 > miibus1: on bge1 > brgphy1: on miibus1 > brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, > 1000baseTX-FDX, auto > pcib4: on > motherboard > pci4: on pcib4 > pcib8: at device 8.0 on > pci4 > pci5: on pcib8 > pci5: (vendor=0x9005, dev=0x00c5) at 6.0 irq 7 > pci5: (vendor=0x9005, dev=0x00c5) at 6.1 irq 11 > aac0: mem 0xf000-0xf7ff irq 7 at device 8.1 > on pci4 > aac0: i960RX 100MHz, 118MB cache memory, optional battery present > aac0: Kernel 2.7-1, Build 3170, S/N 5010d3 > aac0: Supported > Options=75c > pcib5: on > motherboard > pci6: on pcib5 > pcib6: on > motherboard > pci7: on pcib6 > pcib7: on > motherboard > pci8: on pcib7 > orm0: at iomem > 0xc-0xc7fff,0xc8000-0xcbfff,0xec000-0xe on isa0 > pmtimer0 on isa0 > fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on > isa0 > fdc0: FIFO enabled, 8 bytes threshold > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > atkbdc0: at port 0x60,0x64 on isa0 > vga0: at port 0x3c0-0x3df iomem 0xa-0xb on > isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > sio0: type 16550A > sio1 at port 0x2f8-0x2ff irq 3 on isa0 > sio1: type 16550A > IP Filter: v3.4.31 initialized. Default = pass all, Logging = > disabled > ata0-slave: ATAPI identify retries exceeded > acd0: CDROM at ata0-master PIO4 > aacd0: on aac0 > aacd0: 139997MB (286714368 sectors) > > > Any ideas? > > Thank you, > bogdan > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or
4.9 kernel panics on a poweredge 2650
Hi hackers, I am experiencing kernel panics on a poweredge 2650 each day around 3am (usually the machine comes up at 3:04am). The kernel panics are reproductable by running: /etc/periodic/security/100.chksetuid (in fact by runnning find on /usr with -perms). The problem lies somewhere in /usr/ports. Deleting the /usr/ports tree doesn't solve it, trying a cvs up of /usr/ports results in a crash again. I googled around a lil' bit, and found: http://lists.freebsd.org/pipermail/freebsd-hackers/2003-April/000192.html, and also Terry's answer, but that addresses freebsd 4.7. But my box is running 4.9-release, and the systems was cleanly installed with 4.9 from the very beginning, so not upgraded from 4.7 or any other previous version. The dmesg looks like: Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.9-RELEASE #1: Mon Nov 17 23:47:49 CET 2003 root@:/usr/src/sys/compile/saturn Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 1790761584 Hz CPU: Intel(R) Xeon(TM) CPU 1.80GHz (1790.76-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 Features=0xbfebfbff Hyperthreading: 2 logical CPUs real memory = 2147418112 (2097088K bytes) avail memory = 2088136704 (2039196K bytes) Preloaded elf kernel "kernel" at 0xc0312000. Warning: Pentium 4 CPU: PSE disabled Pentium Pro MTRR support enabled Using $PIR table, 9 entries at 0xc00fc430 npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pci0: (vendor=0x1028, dev=0x000c) at 4.0 irq 11 pci0: (vendor=0x1028, dev=0x0008) at 4.1 irq 10 pci0: (vendor=0x1028, dev=0x000d) at 4.2 irq 7 pci0: at 14.0 atapci0: port 0x8b0-0x8bf,0x8d8-0x8db,0x8d0-0x8d7,0x8c8-0x8cb,0x8c0-0x8c7 at device 15.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at 15.2 irq 5 isab0: at device 15.3 on pci0 isa0: on isab0 pcib1: on motherboard pci1: on pcib1 pcib2: on motherboard pci2: on pcib2 pcib3: on motherboard pci3: on pcib3 bge0: mem 0xfcf1-0xfcf1 irq 11 at device 6.0 on pci3 bge0: Ethernet address: 00:06:5b:f6:48:38 miibus0: on bge0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge1: mem 0xfcf0-0xfcf0 irq 10 at device 8.0 on pci3 bge1: Ethernet address: 00:06:5b:f6:48:39 miibus1: on bge1 brgphy1: on miibus1 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge1: mem 0xfcf0-0xfcf0 irq 10 at device 8.0 on pci3 bge1: Ethernet address: 00:06:5b:f6:48:39 miibus1: on bge1 brgphy1: on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto pcib4: on motherboard pci4: on pcib4 pcib8: at device 8.0 on pci4 pci5: on pcib8 pci5: (vendor=0x9005, dev=0x00c5) at 6.0 irq 7 pci5: (vendor=0x9005, dev=0x00c5) at 6.1 irq 11 aac0: mem 0xf000-0xf7ff irq 7 at device 8.1 on pci4 aac0: i960RX 100MHz, 118MB cache memory, optional battery present aac0: Kernel 2.7-1, Build 3170, S/N 5010d3 aac0: Supported Options=75c pcib5: on motherboard pci6: on pcib5 pcib6: on motherboard pci7: on pcib6 pcib7: on motherboard pci8: on pcib7 orm0: at iomem 0xc-0xc7fff,0xc8000-0xcbfff,0xec000-0xe on isa0 pmtimer0 on isa0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: at port 0x60,0x64 on isa0 vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A IP Filter: v3.4.31 initialized. Default = pass all, Logging = disabled ata0-slave: ATAPI identify retries exceeded acd0: CDROM at ata0-master PIO4 aacd0: on aac0 aacd0: 139997MB (286714368 sectors) Any ideas? Thank you, bogdan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: symlink: /home -> /usr/home vs. /home -> usr/home in default installation
Andriy Tkachuk wrote: The idea is this: if you mount your / to another place (for example /mnt on another computer), your /mnt/home will point to correct place (/mnt/usr/home) instead of /usr/home. What do you, falks, think about this? Thanks. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" That idea seems good to me. I don't forsee any issues with it. -- William Michael Grim Student, Southern Illinois University at Edwardsville Unix Network Administrator, SIUE, Computer Science dept. Phone: (217) 341-6552 Email: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
symlink: /home -> /usr/home vs. /home -> usr/home in default installation
The idea is this: if you mount your / to another place (for example /mnt on another computer), your /mnt/home will point to correct place (/mnt/usr/home) instead of /usr/home. What do you, falks, think about this? Thanks. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Ethereal build issues
Hackers-- Just wanted to give you a heads-up on an issue I had. I have a freshly-made 5.2 box and I was installing Ethereal from the ports tree. For whatever reason the file resolv.c in /usr/ports/net/ethereal/work/ethereal-0.9.14/epan could not find the file adns.h, which was in the default location of /usr/local/include. Hard coding the path in resolv.c fixed the issue. --Jeff ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
KTRACE flags
Hi Is there any way how can I see which proceses are ktraced? It would be neat to have this feature... roman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
