sorry about the vinum comment.
I would like to apologise for the missleading comment I made about vinum and using 4 18 gig drives with vinum. In teaching myself the software I have been using 4 18 gig drives in serveral configurations including striping, striping/mirroring and raid 5. in each situation I had to wait a long time to init the volumes and newfs because of their great size. I also took drives out of the vinum volume to simulate failures so that I could learn how to restore from failure. I have had no problems with vinum using mirroring or striping. In fact I am impressed with the speed. the only problems I have had were with raid 5 and doccumented on the vinum web site. Again I did not mean to imply there was a problem with vinum or using 18 gig drives with it. Richard Puga [EMAIL PROTECTED] (missleading comment) > > PS; anyone thinking of playing with vinum I suggest you dont start out > > with 4 18 gig drives ..:) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
more softpower/apm..
Hi Does anyone know if its possible for FreeBSD to execute a halt from the powerswitch? >From reading the apmd doco, this is what apmd is suppose to do, handle events from the APM bios and execute according to apmd.conf If an ATX powersupply/motherboard is setup to suspend on power button, (i.e hold down for 5 seconds to turn off) can FreeBSD pick up this button press and do clean shutdown? I tried running apmd -dv, but I cant seem to see any events from the power button pressing. Thanks Bry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
gdb and ELF shared libraries
It appears to me that the gdb 4.18 port on FreeBSD 3.3 doesn't provide support for ELF shared libraries. Am I correct about that, or did I just snag myself on some obscure gdb bug that was masquerading as ELF shared library non-support? Anyway, assuming that my supposition is correct, and that gdb 4.18 on FreeBSD does not yet support debugging of ELF shared libraries, I'd like to maybe take a whack at making it do that. (I've worked on gdb and gcc before, and have pretty good knowledge of ELF, so I think that I could actually make a useful contribution here.) But I have a first-order problem to overcome first. I can't even get the gnu gdb 4.18 source tree to build on FreeBSD 3.3. It craps out while trying to compile the file solib.c. (And looking at DejaNews, I see that I am not the only person who has run into this problem, so I know that it's not just me.) So will somebody please tell me the trick to get past these compile-time problems with solib.c? Obviously, *somebody* knows how to get past them, because FreeBSD 3.3 ships with a binary of gdb 4.18 and that *does* kinda sorta work. So how was that built, and who built it? Where are the patches that were used to make it build? P.S. I already wrote to David Greenman <[EMAIL PROTECTED]> and asked him who is the current maintainer of the FreeBSD port for gdb, but he didn't respond. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: fcntl(0,F_SETFL,O_ASYNC) & signal(SIGIO,rkbd); don't work in3.X !!!!
Great
Thanx...
> i'm not sure why the change happened, but here's a fix:
>
> --- sigio.old.c Tue Nov 23 19:18:01 1999
> +++ sigio.c Tue Nov 23 19:19:21 1999
> @@ -36,7 +36,14 @@
> int
> main(int argc,char **argv)
> {
> + int arg;
> +
> + arg = getpid();
> +
> +
> if(fcntl(0,F_SETFL,O_ASYNC)==-1)
> +err(errno,NULL);
> +if(fcntl(0,F_SETOWN,arg)==-1)
> err(errno,NULL);
> signal(SIGIO,rkbd);
> for(;;){
>
> unless this is strictly a test program you should be using
> the constants "STDIN_FILENO" afaik.
>
> -Alfred
S/MIME Cryptographic Signature
Re: fcntl(0,F_SETFL,O_ASYNC) & signal(SIGIO,rkbd); don't work in3.X !!!!
On Wed, 24 Nov 1999, Seva Semenov wrote:
> Why my little proggy can't get SIGIO in FreeBSD 3.3-RELEASE,
> when i type my keyboard?
>
> In 2.2.6-RELEASE it works right.
>
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> void
> rkbd(int sig)
> {
> int i,j;
> u_char b[1024],*c;
>
> syslog(LOG_DEBUG,"* ");
>
> i=read(0,b,1024);
> if(i<0)
>syslog(LOG_DEBUG,"read failed due to %s",strerror(errno));
>
> else
>if(!i)
> syslog(LOG_DEBUG,"read null bites");
>else{
> b[i]='\0';
> puts("\n**");
> fputs(b,stdout);
> puts("**\n");
> fflush(stdout);
>}
> }
>
> int
> main(int argc,char **argv)
> {
> if(fcntl(0,F_SETFL,O_ASYNC)==-1)
> err(errno,NULL);
> signal(SIGIO,rkbd);
> for(;;){
> sleep(10);
> }
> }
i'm not sure why the change happened, but here's a fix:
--- sigio.old.c Tue Nov 23 19:18:01 1999
+++ sigio.c Tue Nov 23 19:19:21 1999
@@ -36,7 +36,14 @@
int
main(int argc,char **argv)
{
+ int arg;
+
+ arg = getpid();
+
+
if(fcntl(0,F_SETFL,O_ASYNC)==-1)
+err(errno,NULL);
+if(fcntl(0,F_SETOWN,arg)==-1)
err(errno,NULL);
signal(SIGIO,rkbd);
for(;;){
unless this is strictly a test program you should be using
the constants "STDIN_FILENO" afaik.
-Alfred
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
fcntl(0,F_SETFL,O_ASYNC) & signal(SIGIO,rkbd); don't work in 3.X !!!!
Why my little proggy can't get SIGIO in FreeBSD 3.3-RELEASE,
when i type my keyboard?
In 2.2.6-RELEASE it works right.
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
void
rkbd(int sig)
{
int i,j;
u_char b[1024],*c;
syslog(LOG_DEBUG,"* ");
i=read(0,b,1024);
if(i<0)
syslog(LOG_DEBUG,"read failed due to %s",strerror(errno));
else
if(!i)
syslog(LOG_DEBUG,"read null bites");
else{
b[i]='\0';
puts("\n**");
fputs(b,stdout);
puts("**\n");
fflush(stdout);
}
}
int
main(int argc,char **argv)
{
if(fcntl(0,F_SETFL,O_ASYNC)==-1)
err(errno,NULL);
signal(SIGIO,rkbd);
for(;;){
sleep(10);
}
}
S/MIME Cryptographic Signature
Re: arpresolve: can't allocate llinfo for 127.0.0.1rt [PLAIN TEXT]
See PR bin/12136. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
arpresolve: can't allocate llinfo for 127.0.0.1rt [PLAIN TEXT]
Ok... my apologies to all those whose email clients are not capable of parsing html emails... my settings indicated that my email was to be sent plain text... this was apparently not the case as someone was kind enough to point out... thanks! Aaron Sonntag -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Aaron Sonntag Sent: Monday, November 22, 1999 10:08 AM To: zshack; [EMAIL PROTECTED] Subject: RE: slight problem I HAVE THIS PROBLEM TOO... I am not sure what causes it... but if you do a netstat -rn I am sure you will see that the route to your nic interface address is pointing to 127.0.0.1 instead of a mac address (as show below under [BEFORE]). Do a 'route delete [interface address]'... for instance in the example below... I type 'route delete 216.140.184.45'. Then ping the interface and run netstat -rn again and you will see (as shown below under [AFTER]) that the mac addy will appear and the machine will be happy. Temporarily L [BEFORE] Internet: DestinationGatewayFlags Refs Use Netif Expire default216.140.184.33 UGSc 11 2528899 rl0 10.0.1/24 link#3 UC 00 mx1 127.0.0.1 127.0.0.1 UH 2 80 lo0 216.140.184.32/27 link#1 UC 00 rl0 216.140.184.45 127.0.0.1 UGHS0 232 rl0 [AFTER] Internet: DestinationGatewayFlags Refs Use Netif Expire default216.140.184.33 UGSc 11 2528999 rl0 10.0.1/24 link#3 UC 00 mx1 127.0.0.1 127.0.0.1 UH 1 80 lo0 216.140.184.32/27 link#1 UC 00 rl0 216.140.184.45 0:4f:4e:1:1a:88UHLW02 lo0 A friend/coworker of mine helped me with this temporary fix (THANKS DAVID!). But he seemed to think it was a larger issue with the dhclient script. I have had this problem on three different 3.3 machines on three COMPLETELY different networks and the one similarity between them was dhclient. Two of them were nat boxes on RR and one is a workstation. To reinforce this theory... on the nat boxes that have the problem... its only the interfaces that are getting dhcp via dhclient that have the problem. My point is... the above is a temporary solution. The following message will completely flood my dmesg buffer until the machine stops responding... arplookup 127.0.0.1 failed: could not allocate llinfo arpresolve: can't allocate llinfo for 127.0.0.1rt anybody have any permanent solutions?? Thanks Aaron Sonntag -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of zshack Sent: Monday, November 22, 1999 9:40 AM To: [EMAIL PROTECTED] Subject: slight problem I just installed freebsd 3.3 stable and i keep getting this message: /kernet: arplookup 127.0.0.1 failed: can't allocate llinfo /kernet arpresolve can't allocate llinfo for 127.0.0.1 any idea what is causing this and how i can fix it? Thanks zshack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ip checksum
Hey,
I am sort of confused with the parameters for IPsumReplaceShort function,
I understand that I will pass the &ip-ip_sum for the cksump parameter.
but I am not able to understand wht oldvap & newvalp stand for..
Xavier.
On Mon, 22 Nov 1999, Julian Elischer wrote:
> How many bytes have you changed?
>
> is it possible that some of the values have already been ntohs()'d
> or something similar?
>
> rather than recalculate the whole packet, just update the exisitng
> value.
>
> there is an rfc for this but it took me a while to get
> the code right in C on a 386. The trick is getting the 1s complement
> arithmetic right.
>
>
>
> #define FIXSUM16(c, op, np) \
> do {\
> (c) -= (u_int16_t) ~*((u_int16_t *) (op));\
> if ((c) < 0) {\
> (c) += 0x; \
> } \
> (c) -= (u_int16_t) *((u_int16_t *) (np));\
> if ((c) < 0) {\
> (c) += 0x; \
> } \
> } while (0)
>
>
> /*
> * IpsumReplaceShort()
> *
> * Replace a 16 bit aligned (relative to the checksum) 16 bit value
> * in a packet and change the IP/TCP/UDP checksum at the same time.
> *
> * Works with both big and little endian machines(!)
> *
> * If for some wierd reason you want to replace a nonaligned value,
> * you need to byteswap it and the old value before doing the
> * subtractions.
> */
>
> void
> IpsumReplaceShort(u_int16_t *cksump, u_int16_t *oldvalp, u_int16_t newval)
> {
> register int cksum;
>
> cksum = *cksump;
> FIXSUM16(cksum, oldvalp, &newval);
> *cksump = cksum;
> *oldvalp = newval;
> }
>
>
> On Tue, 23 Nov 1999, Parthasarathy M. Aji wrote:
>
> > Hey,
> >
> > I am trying to recompute the checksum of an IP packet. I use
> > netinet/in_chksum.c to do this. The values returned are not correct. I've
> > reset the ip_sum field to 0 before doing the sum. Is there something
> > missing?
> >
> > thanks
> >
> >
> >
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-hackers" in the body of the message
> >
>
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: ip checksum
On Tue, 23 Nov 1999, Clinton Xavier Berni wrote:
> Hey,
> I am sort of confused with the parameters for IPsumReplaceShort function,
> I understand that I will pass the &ip-ip_sum for the cksump parameter.
>
> but I am not able to understand wht oldvap & newvalp stand for..
cksump points to the existing checksum IN THE PACKET
oldvalp points to the old value that will be replaecd IN THE PACKET
newval is the value that will replace the old value.
The function will replace the old value with the new value, and
update the checksum accordigly.
julian
>
> Xavier.
>
>
>
> On Mon, 22 Nov 1999, Julian Elischer wrote:
>
> > How many bytes have you changed?
> >
> > is it possible that some of the values have already been ntohs()'d
> > or something similar?
> >
> > rather than recalculate the whole packet, just update the exisitng
> > value.
> >
> > there is an rfc for this but it took me a while to get
> > the code right in C on a 386. The trick is getting the 1s complement
> > arithmetic right.
> >
> >
> >
> > #define FIXSUM16(c, op, np) \
> > do {\
> > (c) -= (u_int16_t) ~*((u_int16_t *) (op));\
> > if ((c) < 0) {\
> > (c) += 0x; \
> > } \
> > (c) -= (u_int16_t) *((u_int16_t *) (np));\
> > if ((c) < 0) {\
> > (c) += 0x; \
> > } \
> > } while (0)
> >
> >
> > /*
> > * IpsumReplaceShort()
> > *
> > * Replace a 16 bit aligned (relative to the checksum) 16 bit value
> > * in a packet and change the IP/TCP/UDP checksum at the same time.
> > *
> > * Works with both big and little endian machines(!)
> > *
> > * If for some wierd reason you want to replace a nonaligned value,
> > * you need to byteswap it and the old value before doing the
> > * subtractions.
> > */
> >
> > void
> > IpsumReplaceShort(u_int16_t *cksump, u_int16_t *oldvalp, u_int16_t newval)
> > {
> > register int cksum;
> >
> > cksum = *cksump;
> > FIXSUM16(cksum, oldvalp, &newval);
> > *cksump = cksum;
> > *oldvalp = newval;
> > }
> >
> >
> > On Tue, 23 Nov 1999, Parthasarathy M. Aji wrote:
> >
> > > Hey,
> > >
> > > I am trying to recompute the checksum of an IP packet. I use
> > > netinet/in_chksum.c to do this. The values returned are not correct. I've
> > > reset the ip_sum field to 0 before doing the sum. Is there something
> > > missing?
> > >
> > > thanks
> > >
> > >
> > >
> > > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > > with "unsubscribe freebsd-hackers" in the body of the message
> > >
> >
> >
>
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
NFS hangs/locks CPU
Hi, I'm running FreeBSD 2.2.8. We have used 2.2.8 to build a telecom application and have had great success deploying other telecom applications on 2.2.8 until now. We are using NFS to distribute binaries and config files to others machines so that we can achieve availability. Here's our problem: I have two machines one acting as a server and the other as a client. The processes are started as follows NFS Server (king-n1) mountd nfsd -u -t 10 rpc.statd NFS Client (king-c1) mount_nfs -T -w 1024 king-n1:/u /u Both machines are Pentium II 450 mhz with 512 megs of ram and 1024 megs of swap. We use an Intel Ethernet Express Pro 100 cards with the fxp0 driver. I turned on debug for the fxp0 driver and see nothing out of the ordinary. Please note that king-n1 is a dual homed. That is why we use the -T option. Otherwise, we can not use NFS to the virtual ip address without installing the NFS_Security_Cookie workaround. Since the nfs_security_cookie workaround has not been tested on 2.2.8, we chose to use the -T option (odd but it allows us to mount a directory from a virtual ip address instead of the real ip address). It is interesting to note that this hang still occurs whether or not we use the real ip address or a virtual ip address. The problem is that under heavy load, we see that the client does a lot of Getattr and Access (nfsstat -w 1). We were able to compile the DDB option into the kernel and when the machine hung,we entered into the debugger and saw that we were stuck in a _write call. The following is what we saw when we did a trace. _boidone(f418d200,f418d200,f22bf000,f22dc600,3) at _boidone 0x2e6 _nfs_doio(f418d200,f22df000,f22dc600,1,f418d200) at _nfs_doio 0x4c5 _nfs_strategy(efbffddc) at _nfs_strategy 0x68 _nfs_writebp(f418d200,1,efbffec4,f0163000,efbffe50) at _nfs_writebp 0x125 _nfs_bwrite(efbff50) at _nfs_bwrite 0x10 _nfs_write(efbffee08,f02564e0,1,efbff94,2) at _nfs_write 0x648 _vn_write(f25d6f80,efbfff34,f22bf000,f02564e0,f22c600) at _vn_write 0x93 _write(f220c600,efbff94,efbff84,0,5167) at _write 0x97 _syscall I am not sure what to do from here. We can only run traffic for about 4 hours before our machine hangs. I suspect that this might be related to a GETATTR or ACCESS nfs problem or a possible tcp/ip bug under heavy load. Can anyone help or point me in the right direction. Moving to 3.x is not possible because we are using a product that we purchased from Sweden. The Swedish product is the base of all our telecom products here at AGCS and it only runs on 2.2.8. Any help is appreciated. Thanks. Regards, -- Juan Lorenzana AG Communication Systems Phoenix, AZ 602-582-7442 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: H323/Ldap support in natd/libalias
You might take a look at http://www.willamowius.de/openh323gk.html I haven't looked at it in a couple of months but they are basically working on a H323 stack and proxy. It's not exactly what your talking about but close enough that it might be a good starting place. Brian Haskin [EMAIL PROTECTED] Home page: http://www.geocities.com/ResearchTriangle/4333/ Always remember, money is simply a level of indirection. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Christian Bruno > Sent: Tuesday, November 23, 1999 12:54 PM > To: [EMAIL PROTECTED] > Subject: H323/Ldap support in natd/libalias > > > Hello, > > i am trying to add an H323/LDAP support to NATD in FreeBSD to enable full > video/audio functionnalities of video-conference clients in a private > network. > > i posted some messages in newsgroups, but the only answer i got > was to buy a > commercial product like "phonepatch" (which does not work on my > freebsd box) > > could you tell me if someone is working on this problem ? > it could be interesting to exchange ideas (and maybe solutions ?) > > any comments or ideas are welcome > > Best Regards, > Christian Bruno ( [EMAIL PROTECTED] ) > > ps : sorry, my english is a beta-test version > > > > __ > Message envoye depuis iFrance >> http://www.ifrance.com > Gratuit >> Hebergement (50 Mo)/Vos emails (POP&HTML,20 Mo) > Votre agenda online gratuit >> http://agenda.ifrance.com > NOUVEAU : Faxez gratuitement ! >> http://fax.ifrance.com > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
H323/Ldap support in natd/libalias
Hello, i am trying to add an H323/LDAP support to NATD in FreeBSD to enable full video/audio functionnalities of video-conference clients in a private network. i posted some messages in newsgroups, but the only answer i got was to buy a commercial product like "phonepatch" (which does not work on my freebsd box) could you tell me if someone is working on this problem ? it could be interesting to exchange ideas (and maybe solutions ?) any comments or ideas are welcome Best Regards, Christian Bruno ( [EMAIL PROTECTED] ) ps : sorry, my english is a beta-test version __ Message envoye depuis iFrance >> http://www.ifrance.com Gratuit >> Hebergement (50 Mo)/Vos emails (POP&HTML,20 Mo) Votre agenda online gratuit >> http://agenda.ifrance.com NOUVEAU : Faxez gratuitement ! >> http://fax.ifrance.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: wacky rpc.lockd idea...
On Tue, 23 Nov 1999, Ronald G. Minnich wrote: :On Mon, 22 Nov 1999, David E. Cross wrote: :> I've noticed about 99% of the panics on our machines are the result of NFS, :> more often than not it is the result of a backing store file being blown :> away underneath the client. ie. person editing a file on one machine, :> compiling and running on a second, then removing the binary on the first :> machine. If we had a working lock manager could we not have the kernel open :> a shared lock on anything it had in backing store, would that not assure that :> files didn't go poof in the night? : :I think you're really proposing to add state to NFS, but add it via a :'back door', the lockd. I think this is not as good an idea as getting :coda or intermezzo working -- for the latter, www.inter-mezzo.org : :nfs is just plain broken for this sort of thing, and has been forever. I'm :not sure you want to start grafting on fixes of this sort. How would this be different that what Sun has done? They designed NFS stateless (do to stupid utopian visions of 0 latency infinite bandwidth networks), and then added state via rpc.lockd to try and fix their silly design flaw. Sure, locking still has problems due to race conditions and deadlocks, but it beats what you have without it. Jamie Bowden -- If we've got to fight over grep, sign me up. But boggle can go. -Ted Faber (on Hasbro's request for removal of /usr/games/boggle) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Ok, that's it, enough is enough! (rpc.lockd)
> : Ok... I have *had* it with the meta, but not really, lockd. Are there any > : kernel issues with correctly implimenting rpc.lockd?How can I take a > : filehandle and map it into a filename, with path, so I may open it and lock > : it on the server? Are there any protocol specs? I downloaded the RFC for > : version 4 nlm (which we do not supoprt at *all*), but it only lists diffs to > : the version 3 spec, which I cannot find, and the source is not a whole lot > : of help on this issue. > > One area that Solbourne had lots and lots of problems with years ago > when it tried to implenent rpc.lockd was that Sun, at the time, has 5! > incompatible versions that had to be interoperated with. Don't know > if things have changed in the ensuing years or not... Not really, no. Insofar as I know, the only distributed open source lock manager that might ever have a chance of being usable is the one the GFS guys are working on now, and naturally that will be tied to GFS, etc... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Ok, that's it, enough is enough! (rpc.lockd)
In message <[EMAIL PROTECTED]> "David E. Cross" writes: : Ok... I have *had* it with the meta, but not really, lockd. Are there any : kernel issues with correctly implimenting rpc.lockd?How can I take a : filehandle and map it into a filename, with path, so I may open it and lock : it on the server? Are there any protocol specs? I downloaded the RFC for : version 4 nlm (which we do not supoprt at *all*), but it only lists diffs to : the version 3 spec, which I cannot find, and the source is not a whole lot : of help on this issue. One area that Solbourne had lots and lots of problems with years ago when it tried to implenent rpc.lockd was that Sun, at the time, has 5! incompatible versions that had to be interoperated with. Don't know if things have changed in the ensuing years or not... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
arpresolve: can't allocate llinfo for 127.0.0.1rt
This one fell through the cracks on the questions list… probably cause its not a simple question… or at least I would like to think so ;-) It is regarding an error occurring in the route table on various machines under various configurations. The one similarity is dhclient. Read below… I was fairly detailed with the description of the problem… thanks! Aaron Sonntag -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Aaron Sonntag Sent: Monday, November 22, 1999 10:08 AM To: zshack; [EMAIL PROTECTED] Subject: RE: slight problem I HAVE THIS PROBLEM TOO… I am not sure what causes it… but if you do a netstat –rn I am sure you will see that the route to your nic interface address is pointing to 127.0.0.1 instead of a mac address (as show below under [BEFORE]). Do a ‘route delete [interface address]’… for instance in the example below… I type ‘route delete 216.140.184.45’. Then ping the interface and run netstat –rn again and you will see (as shown below under [AFTER]) that the mac addy will appear and the machine will be happy. Temporarily L [BEFORE] Internet: Destination Gateway Flags Refs Use Netif Expire default 216.140.184.33 UGSc 11 2528899 rl0 10.0.1/24 link#3 UC 0 0 mx1 127.0.0.1 127.0.0.1 UH 2 80 lo0 216.140.184.32/27 link#1 UC 0 0 rl0 216.140.184.45 127.0.0.1 UGHS 0 232 rl0 [AFTER] Internet: Destination Gateway Flags Refs Use Netif Expire default 216.140.184.33 UGSc 11 2528999 rl0 10.0.1/24 link#3 UC 0 0 mx1 127.0.0.1 127.0.0.1 UH 1 80 lo0 216.140.184.32/27 link#1 UC 0 0 rl0 216.140.184.45 0:4f:4e:1:1a:88 UHLW 0 2 lo0 A friend/coworker of mine helped me with this temporary fix (THANKS DAVID!). But he seemed to think it was a larger issue with the dhclient script. I have had this problem on three different 3.3 machines on three COMPLETELY different networks and the one similarity between them was dhclient. Two of them were nat boxes on RR and one is a workstation. To reinforce this theory… on the nat boxes that have the problem… its only the interfaces that are getting dhcp via dhclient that have the problem. My point is… the above is a temporary solution. The following message will completely flood my dmesg buffer until the machine stops responding… arplookup 127.0.0.1 failed: could not allocate llinfo arpresolve: can't allocate llinfo for 127.0.0.1rt anybody have any permanent solutions?? Thanks Aaron Sonntag -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of zshack Sent: Monday, November 22, 1999 9:40 AM To: [EMAIL PROTECTED] Subject: slight problem I just installed freebsd 3.3 stable and i keep getting this message: /kernet: arplookup 127.0.0.1 failed: can't allocate llinfo /kernet arpresolve can't allocate llinfo for 127.0.0.1 any idea what is causing this and how i can fix it? Thanks zshack
Re: wacky rpc.lockd idea...
On Mon, 22 Nov 1999, David E. Cross wrote: > I've noticed about 99% of the panics on our machines are the result of NFS, > more often than not it is the result of a backing store file being blown > away underneath the client. ie. person editing a file on one machine, > compiling and running on a second, then removing the binary on the first > machine. If we had a working lock manager could we not have the kernel open > a shared lock on anything it had in backing store, would that not assure that > files didn't go poof in the night? I think you're really proposing to add state to NFS, but add it via a 'back door', the lockd. I think this is not as good an idea as getting coda or intermezzo working -- for the latter, www.inter-mezzo.org nfs is just plain broken for this sort of thing, and has been forever. I'm not sure you want to start grafting on fixes of this sort. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: whats up with vinum?
On Sunday, 21 November 1999 at 4:40:54 -1000, Richard Puga wrote: > I am fooling around with vinum which I have set up in a raid 5 > configuration under FreeBSD 3.3-RELEASE. > > The trouble is that my machine keeps locking up under heavy use. If I > try and "make world" it dies about 15-60 seconds into it whit a page > fault as well as trying to ftp over large files and somtimems while > trying to build kernels. If you have problems with Vinum, please read what it says at the end of vinum(4) in the section DEBUGGING PROBLEMS WITH VINUM. You can also read it at and http://www.lemis.com/vinum/how-to-debug.html, and you should normally check known bugs at http://www.lemis.com/vinum/bugs.html. > After several page faults and fsck's on reboot I will loose an entire > drvie. It is marked as "stale"m by vinum and more than once has lost its > disklabel. > > I am now using ccd level 0 but would like to use vinum raid 5 if > possable. With the information you supply, it's difficult to tell. It could be a known problem: we do have one outstanding problem with RAID-5. To quote the man page: 4. The RAID-5 functionality is new in FreeBSD 3.3. Some problems have been reported with vinum in combination with soft updates, but these are not reproducible on all systems. If you are planning to use vinum in a production environment, please test carefully. > PS; anyone thinking of playing with vinum I suggest you dont start out > with 4 18 gig drives ..:) If you make these suggestions, you should say why. I don't know of any problems. What have you had? Maybe they are related to your panics. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Non-standard FFS parameters
On Tue, 23 Nov 1999, Joe Greco wrote: > > On Fri, 8 Oct 1999, Matthew Dillon wrote: > > > > > :> > > > :> Adjusting the bytes-per-inode (-i) specification in newfs should not > > > :> pose a problem. > > > : > > > :IOW now you say it's ok to use very high values of -i... ;-) > > > : > > > :Andrzej Bialecki > > > > > > No, I didn't say that. My recommended maximum is still 262144. Fsck > > > should be reasonably fast with that number and the filesystem should > > > still be able to maintain reasonable efficiency. > > > > Ok, I can live with that, I guess. Thanks a lot for your help! > > What's the recommended way to reduce the number of cylinder groups a bit? ...except manually changing the calculations in newfs/mkfs.c ? What values are reasonable for large filesystems? Andrzej Bialecki // <[EMAIL PROTECTED]> WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
VB
Title: VideBula-991118 VideBula "Não importa o que tiraram de você, o que importa é o que você vai fazer com o que sobrou." "Você não pode estar só se gostar da pessoa com quem fica quando esta sozinho." RECEBER NÃORECEBER PUBLICAR CRÍTICAS, DÚVIDAS & SUGESTÕES
Serial console oddity
So, I've been doing serial consoles for a while and every so often, the following pops up. Seems to happen on SMP machines. Don't recall if it happens on non-SMP machines. This has happened for a _very_long_time_ (like since pre-3.0). BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS drive D: is disk2 BIOS drive E: is disk3 BIOS drive F: is disk4 BIOS drive G: is disk5 BIOS drive H: is disk6 BIOS drive I: is disk7 BIOS drive J: is disk8 FreeBSD/i386 bootstrap loader, Revision 0.7 640/65472kB ([EMAIL PROTECTED], Thu Sep 16 22:16:41 GMT 1999) |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/Loading | /boot/defaults/loader.conf -\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/kernel text=0x10a418 /-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-data=0x17b48+0x1a97c \|/-\|/-\|/-syms=[0x4+0x1ee30\|/-\|/-\|/-\|/-+0x4+0x206b3\|/-\|/-\|/-\|/-] \|/-\|/ Hit [Enter] to boot immediately, or any other key for command prompt. Type '?' for a list of commands, 'help' for more detailed help. boot: spool0-nwblwi.newsops.execpc.com > m boot -s Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.3-RELEASE #0: Mon Nov 22 13:38:07 CST 1999 root@host:/usr/src/sys/compile/DEMO Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Xeon/Celeron (686-class CPU) Origin = "GenuineIntel" Id = 0x652 Stepping = 2 Features=0x183fbff real memory = 536870912 (524288K bytes) avail memory = 519716864 (507536K bytes) Programming 24 pins in IOAPIC #0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Preloaded elf kernel "kernel" at 0xc027e000. Pentium Pro MTRR support enabled Probing for devices on PCI bus 0: chip0: rev 0x03 on pci0.0.0 chip1: rev 0x03 on pci0.1.0 chip2: rev 0x02 on pci0.4.0 chip3: rev 0x02 on pci0.4.3 ahc0: rev 0x00 int a irq 19 on pci0.6.0 ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs hfa0: rev 0x00 int a irq 19 on pci0.9.0 chip4: rev 0x03 on pci0.10.0 ahc1: rev 0x00 int a irq 17 on pci0.11.0 ahc1: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc2: rev 0x00 int a irq 16 on pci0.12.0 ahc2: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs Probing for devices on PCI bus 1: Probing for devices on PCI bus 2: de0: rev 0x22 int a irq 18 on pci2.4.0 de0: SMC 9332BDT 21140A [10-100Mb/s] pass 2.2 de0: address 00:e0:29:3c:fb:84 de1: rev 0x22 int a irq 19 on pci2.5.0 de1: SMC 9332BDT 21140A [10-100Mb/s] pass 2.2 de1: address 00:e0:29:3c:fb:85 Probing for PnP devices: Probing for devices on the ISA bus: sc0 on isa sc0: VGA color <16 virtual consoles, flags=0x0> atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa psm0 not found sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A, console sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A sio2: configured irq 5 not in bitmap of probed irqs 0 sio2 not found at 0x3e8 sio3: configured irq 9 not in bitmap of probed irqs 0 sio3 not found at 0x2e8 fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in vga0 at 0x3b0-0x3df maddr 0xa msize 131072 on isa npx0 on motherboard npx0: INT 16 interface we0 at 0x2e8 on isa we0: kernel is keeping watchdog alive APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via pin 2 IP packet filtering initialized, divert disabled, rule-based forwarding disabled, logging limited to 100 packets/entry by default ccd0-15: Concatenated disk drivers Waiting 2 seconds for SCSI devices to settle SMP: AP CPU #1 Launched! de0: enabling 100baseTX port de1: enabling 100baseTX port cda1 at ahc1 bus 0 target 0 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da1: 17366MB (35566480 512 byte sectors: 255H 63S/T 2213C) da4 at ahc1 bus 0 target 3 lun 0 da4: Fixed Direct Access SCSI-2 device da4: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da4: 17366MB (35566480 512 byte sectors: 255H 63S/T 2213C) da7 at ahc1 bus 0 target 6 lun 0 da7: Fixed Direct Access SCSI-2 device da7: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da7: 17366MB (35566480 512 byte sectors: 255H 63S/T 2213C) da10 at ahc2 bus 0 target 0 lun 0 da10: Fixed Direct Access SCSI-2 device da10: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da10: 17366MB (35566480 512 byte sectors: 64H 32S/T 17366C) da6 at ahc1 bus 0 target 5 lun 0
Help: SoundBlaster PCI 16, 64, 128, 64V, 128V revisions
Hi, I'm trying to list the full range of SoundBlaster PCI models. >From my research I have found the following Creative Labs models. CT4700 SB PCI 128 - (12 months ago) ES1370. 2 line outs for 4 speakers. Retail Box CT SB PCI 64V - unknown chip. 64 Value edition. 1 line out. OEM Market. CT4750 SB PCI 128V - unknown chip. 128 Value edition. 1 line out. OEM market. CT4740 SB PCI 16 - ES1373. 2 line outs for 4 speakers. Retail Box. 12 months ago, Creatives UK web site promoted the SB PCI 128 and the SB Live models. Today, they only promote the SB PCI 16 and SB Live models. Can those of you with SoundBlaster PCI cards help me fill out this table Thanks Roger -- Roger Hardiman Strathclyde Uni Telepresence Research Group, Glasgow, Scotland. http://www.telepresence.strath.ac.uk 0141 548 2897 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
