Re: KEvent doesnt return and KEvent sample tr...
Many thanks. I see where I was going wrong now. Dominic Marks _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
how to use netgraph?
Hi there, I have a process in user space, that wants to send a packet direct on the ethernet, not encapsulate the packet in IP. When I read about netgraph, it looks like it possible to do, or? When I hook to a upper or a lower hook, does the kernel create the ethernet header, or do I have to create the ethernet header in the user process myself before sending down? If the kernal is adding the ethernet header, what is actually sent out on the wire? Usaully an ARPLOOKUP is done and maps the IP dst to a MAC dst, but now I do not have the IP header. How to get the MAC dst field filled in? If someone has an example how to write a small program that using the netgragh to sent a packet down via an hook, I would be so happy if you could send that to me:-) Best Regards Gunnar Gunnar Olsson Phone: +46 8 5062 5762 Xelerated Packet Devices AB Fax: +46 8 5455 3211 Regeringsgatan 67 Mobile: +46 73 3279765 SE-10386 Stockholm Web: http://www.xelerated.com Email: mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
RE: inquiry 6700
Title: Take Control Of Your Conference Calls Long Distance ConferencingOnly 18 Cents Per Minute Connects Up To 100 Participants! No setup fees No contracts or monthly fees Call anytime, from anywhere, to anywhere International Dial In 18 cents per minute Simplicity in set up and administration Operator Help available 24/7 Get the best quality, the easiest to use, and lowest rate in the industry. If you like saving money, fill out the form below and one of our consultants will contact you. Required Input Field* Name* Web Address* Company Name* Web Address* Business Phone* Home Phone Email Address* Type of Business This email is to those persons that have contacted Conference Calls for Less regarding available services or product information. If this email is reaching you in error and you feel that you have not contacted us, Click here. We will gladly remove you from our mailing list. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: new syscons screensaver
Very neat. [forgive flippancy] On Wed, 2 May 2001, Andrew Hesford wrote: > The screensaver isn't bad, and it gets pretty trippy when you focus at > infinity and let the 3D-Illusions (TM) effect set in. Argh! I've just gone blind. -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44(0)117 9287163 Fax +44 (0)117 9287112 RFC822 [EMAIL PROTECTED] YKYBPTMRogueW... you try to move diagonally in vi. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [jkh@osd.bsdi.com: ANNOUNCE: Status update on ftp.freebsd.org AKA ftp.freesoftware.com]
Jordan, I don't buy this story for a moment. You should expect SVBUG not to either. This can only be classified as: A) A poor excuse for a coverup (for some unknown reason) B) Major incompetence (in which someone should resign) C) Aliens have landed If as you say, it has been known since the 20th of April, 2001, then the world (and FreeBSD) has plenty of channels for communications. Windriver has a website, it is un-affected by FreeBSD traffic. BSDi has a website, it is un-affected by FreeBSD traffic. Daemonnews has a website Do I need continue? Best Regards, Jessem. > To: [EMAIL PROTECTED] > Subject: ANNOUNCE: Status update on ftp.freebsd.org AKA ftp.freesoftware.com > X-Mailer: Mew version 1.94.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) > Date: Wed, 02 May 2001 20:58:09 -0700 > From: Jordan Hubbard <[EMAIL PROTECTED]> > > Hi folks, > > This is just a short note to discuss the current state of affairs with > our master FTP site, explain what we're doing about it and combat some > of the FUD floating around which has everyone from space aliens to > Wind River Systems (who supply the space aliens with navigational > software, of course) intentionally killing the site off. > > On April 20th, 2001, the day that FreeBSD 4.3 was due to be released, > we lost access to our main FTP site, ftp.freesoftware.com, without any > advance warning. Further investigation revealed that the problem was > due to an unforeseen network outage which caused the hosting ISP to > have to block access to the site. With one of their major links down, > it was overloading the ISPs backup links and denying bandwidth to > their other customers. > > It was also not clear to us, then or now, just how long the outage > would last and whether this was to be a short-term or a long-term > problem. With the release date for 4.3 already well publicized in > advance and many people asking me for it, I decided to use one of our > backup sites, the usw[1-6].freebsd.org cluster, and at least get the > current releases bits up somewhere on an interim basis. > > Unfortunately, I really underestimated both the extent of the demand > and the degree to which our big, fat Gigabit pipe at ftp.freesoftware.com > has made distributing the bits to our mirrors look comparatively easy. > Even with the login limits set *significantly* greater in favor of the > registered mirror sites, and with multiple machines pulling the load, > it quickly overwhelmed the new hosting infrastructure and resulted in > significant bandwidth limiting on FTP traffic being instituted by the > ISP. Even delaying the official announcement by 24 hours had no > measurable effect on the overload since word of mouth and anticipation > had already built demand beyond the saturation point. > > In short, what many of us have suspected for years turned out to be > proven rather abruptly true: The FreeBSD.org services infrastructure > has become overly reliant on resources which constitute single points > of failure and lacks both sufficient tiering and redundancy in the > face of such failure. We lost a key FTP resource and our entire > distribution service essentially collapsed. The same may be true for > CVSup, mail and WWW services and that's something we definitely need > to look at. > > For now, the most critical item is to finish implementing the > discussed-but-not-implemented ftp-master site scheme. A machine to > serve as the project's "master FTP host" has been procured will > shortly be available for FTP access. ONLY mirror sites will be > allowed to connect to it, and it will always be pre-loaded with > release bits, CERT advisories and anything else which requires the > mirrors to have a head-start in advance of any public announcement. > Announcements will only be made after a hand-inspection of the mirror > sites reveals that a significant degree of propagation has taken place > from the master site and not beforehand. > > What people currently regard as "ftp.freebsd.org" will become another > tier of sites, probably served in round-robin DNS fashion, which have > all agreed to meet the minimum requirements for being "full and > complete mirrors" of the bits offered from ftp-master.freebsd.org. > Existing mirror sites which wish to maintain only a subset of the > master bits will become clients of these second-tier sites and subject > to whatever distribution policies they institute. It would be my > expectation that certain 2nd-tier sites will also have mirror access > lists which favor the 3rd-tier sites over end-users, but that's a > detail to be worked out over time. > > It's also not clear what, if anything, needs to be done to make sites > like www.freebsd.org and hub.freebsd.org more reliable in the face of > failure, but people can certainly expect that a good deal of thought > will be going into answering those questions over the next few weeks. > >
RE: [jkh@osd.bsdi.com: ANNOUNCE: Status update on ftp.freebsd.org A KA ftp.freesoftware.com]
Dear Jessem, > > A) A poor excuse for a coverup (for some unknown reason) > Need a reason? See item C. > > B) Major incompetence (in which someone should resign) > Does this mean you're volunteering? In case you don't: I hereby resign from the position of Major Incompetence. I have proudly held this position for the past eigthteen seconds. However, in honest and open talk with General Protection Failure we have come to the conclusion that it's best for me to let the younger generation move up and fill my shoes in this department. I have learned a lot from working with you in this position and it hurts me to make this decision. Still, my life goes on, and so does yours. > > C) Aliens have landed > Ah. All is explained. Kees Jan You are only young once, but you can stay immature all your life. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: [jkh@osd.bsdi.com: ANNOUNCE: Status update on ftp.freebsd.org A KA ftp.freesoftware.com]
Koster, K.J. writes: > Dear Jessem, > > > C) Aliens have landed > > > Ah. All is explained. Note that "jessem" appears to be Jesus Monroy Jr, who about 6 or 7 years ago conducted various experiments on PC hardware. Among other things, he proved that >>> if you turn off DRAM refresh, the PC crashes <<< Ignore him. //Raymond. -- Raymond Wiker [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Q: porting a driver from linux to freebsd.
Hello! I asked this already on freebsd-questions and was suggested to ask on this list, too. I have a linux driver for a video grabber card (dfg/bw1 from 'the imaging source'). This card does not use a well bt848 or similar chip. I would like to transfer this driver to freebsd. I do understand how the driver works under linux and I will explain below. I have also read articles on newbus, some netbsd docs, several freebsd manpages and the sources of meteor.c. I know in principle how to do a driver under freebsd. But I never did it before and wanted to get some expertise on how to do it best. Under Linux the driver is just an empty shell that links into the kernel, then allocates some memory and provides rather general access to the pci-bus and the allocated memory using ioctl and mmap. There is a 'lowlevel' library that translates the ioctl and mmap calls to a struct based API. This API is then used by a binary only library to do all the work. I.e. find the hardware on the pci-bus. Read and write the device memory. Transfer data to main memory. Set grabbing specifics, etc. The reasons for this implementation are not mine to discuss, but in pricipal I do understand the idea, as it separates the OS/hardware specific part from a more general library. And it allows to distribute the library in binary format and evade some copyright problems. A driver as described above would not really be a PCI-device-driver as it would not allocate (attach to) a pci-device during configuration. My feeling is, that this is some kind of PCI-interface, or PCI-bus abstraction, more like an API, not like a real device. I think it is more like a new system call then a real device. My question: If you (as very experienced driver / kernel programmer) would face this task. And if You were not allowed to question /sidestep the task itself. Haw would You implement this under Freebsd? I even do not know enough keywords to ask more specific. I could ask: Would You do a pseudo device? But I do not know if this could be done by a pseudeo device. Etc. ... Sincerely, Robert S. Haw would You implement this under Freebsd? I even do not know enough keywords to ask more specific. I could ask: Would You do a pseudo device? But I do not know if this could be done by a pseudeo device. Etc. ... Sincerely, Robert S. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: NMI during procfs mem reads (#2)
In message <[EMAIL PROTECTED]> Kevin Day writes: : I tried sending this from my work account, but our new exchange server isn't : exactly sending mail correctly... Excuse the duplicate post if you see it. : :) It sounds like the PCI card that you are trying to read from is generating the pci fault cycles to cause the bridge to generate an nmi. Either that, or you have one of those handy nmi switches that you used to break into the debugger. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: NMI during procfs mem reads (#2)
> > In message <[EMAIL PROTECTED]> Kevin Day writes: > : I tried sending this from my work account, but our new exchange server isn't > : exactly sending mail correctly... Excuse the duplicate post if you see it. > : :) > > It sounds like the PCI card that you are trying to read from is > generating the pci fault cycles to cause the bridge to generate an > nmi. Either that, or you have one of those handy nmi switches that > you used to break into the debugger. > > Warner > The PCI target itself isn't doing anything like that, but it's possible that the PCI-PCI bridge we're going through might be. In any case, getting the NMI isn't really all that bad, it's stopping the chipset from getting hung on a infinite retry. My only concern is the NMI handler while in the kernel may be too aggressive in causing a panic. -- Kevin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [jkh@osd.bsdi.com: ANNOUNCE: Status update on ftp.freebsd.orgA KA ftp.freesoftware.com]
Well, given that it's you I'm speaking with, I think we can just settle for the Aliens explanation and leave it at that. In the real world, shit happens and people do their best to deal with it, often with inadequate information and a lack of alternative resources. I suppose I could also ascribe your own failure to ever come up with a QIC tape driver or a floppy driver (despite months of "newsletters" and apparent effort) as a coverup or major incompetence in action, but that would be another case of reading too much into a sitution where simple human frailty was a more than adequate explanation. If you wish to turn SVBUG into your own personal pulpit for conspiracy theories and other wild-ass politicking then you're also free to do so, but SVBUG should not then be surprised if the rest of us avoid it like the plague. I've already made our position plain and this is the last communication we need to have on the matter since I can easily see that we're going squarely down the path of serious non-productivity with this whole exchange. I also don't see where the -hackers mailing list needs to be involved since this has NOTHING to do with FreeBSD hacking. Have a nice day. - Jordan From: [EMAIL PROTECTED] Subject: Re: [[EMAIL PROTECTED]: ANNOUNCE: Status update on ftp.freebsd.org A KA ftp.freesoftware.com] Date: Thu, 3 May 2001 03:14:44 -0700 (PDT) > Jordan, > I don't buy this story for a moment. You should expect > SVBUG not to either. This can only be classified as: > > A) A poor excuse for a coverup (for some unknown reason) > B) Major incompetence (in which someone should resign) > C) Aliens have landed > > If as you say, it has been known since the 20th of > April, 2001, then the world (and FreeBSD) has plenty > of channels for communications. Windriver has a website, > it is un-affected by FreeBSD traffic. BSDi has a website, > it is un-affected by FreeBSD traffic. Daemonnews has > a website Do I need continue? > > Best Regards, > Jessem. > > > > > > To: [EMAIL PROTECTED] > > Subject: ANNOUNCE: Status update on ftp.freebsd.org AKA ftp.freesoftware.com > > X-Mailer: Mew version 1.94.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) > > Date: Wed, 02 May 2001 20:58:09 -0700 > > From: Jordan Hubbard <[EMAIL PROTECTED]> > > > > Hi folks, > > > > This is just a short note to discuss the current state of affairs with > > our master FTP site, explain what we're doing about it and combat some > > of the FUD floating around which has everyone from space aliens to > > Wind River Systems (who supply the space aliens with navigational > > software, of course) intentionally killing the site off. > > > > On April 20th, 2001, the day that FreeBSD 4.3 was due to be released, > > we lost access to our main FTP site, ftp.freesoftware.com, without any > > advance warning. Further investigation revealed that the problem was > > due to an unforeseen network outage which caused the hosting ISP to > > have to block access to the site. With one of their major links down, > > it was overloading the ISPs backup links and denying bandwidth to > > their other customers. > > > > It was also not clear to us, then or now, just how long the outage > > would last and whether this was to be a short-term or a long-term > > problem. With the release date for 4.3 already well publicized in > > advance and many people asking me for it, I decided to use one of our > > backup sites, the usw[1-6].freebsd.org cluster, and at least get the > > current releases bits up somewhere on an interim basis. > > > > Unfortunately, I really underestimated both the extent of the demand > > and the degree to which our big, fat Gigabit pipe at ftp.freesoftware.com > > has made distributing the bits to our mirrors look comparatively easy. > > Even with the login limits set *significantly* greater in favor of the > > registered mirror sites, and with multiple machines pulling the load, > > it quickly overwhelmed the new hosting infrastructure and resulted in > > significant bandwidth limiting on FTP traffic being instituted by the > > ISP. Even delaying the official announcement by 24 hours had no > > measurable effect on the overload since word of mouth and anticipation > > had already built demand beyond the saturation point. > > > > In short, what many of us have suspected for years turned out to be > > proven rather abruptly true: The FreeBSD.org services infrastructure > > has become overly reliant on resources which constitute single points > > of failure and lacks both sufficient tiering and redundancy in the > > face of such failure. We lost a key FTP resource and our entire > > distribution service essentially collapsed. The same may be true for > > CVSup, mail and WWW services and that's something we definitely need > > to look at. > > > > For now, the most critical item is to finish implementing the > > discussed-but-not-implemented ftp-maste
Re: NMI during procfs mem reads (#2)
In message <[EMAIL PROTECTED]> Kevin Day writes: : The PCI target itself isn't doing anything like that, but it's possible that : the PCI-PCI bridge we're going through might be. In any case, getting the : NMI isn't really all that bad, it's stopping the chipset from getting hung : on a infinite retry. My only concern is the NMI handler while in the kernel : may be too aggressive in causing a panic. Yes. The NMI handler is a little too agressive about panicing. Also, current has problems where sometimes it will panic when the nmi happens with GIANT held. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Q: porting a driver from linux to freebsd.
On Thursday 03 May 2001 16:53, Robert Suetterlin wrote: > Hello! > > I asked this already on freebsd-questions and was suggested to ask on this > list, too. > > I have a linux driver for a video grabber card (dfg/bw1 from 'the imaging > source'). This card does not use a well bt848 or similar chip. I would > like to transfer this driver to freebsd. > [snip] > Under Linux the driver is just an empty shell that links into the kernel, > then allocates some memory and provides rather general access to the > pci-bus and the allocated memory using ioctl and mmap. There is a > 'lowlevel' library that translates the ioctl and mmap calls to a struct > based API. This API is then used by a binary only library to do all the > work. I.e. find the hardware on the pci-bus. Read and write the device > memory. Transfer data to main memory. Set grabbing specifics, etc. > [snip] > My question: If you (as very experienced driver / kernel programmer) would > face this task. And if You were not allowed to question /sidestep the task > itself. Haw would You implement this under Freebsd? I even do not know > enough keywords to ask more specific. I could ask: Would You do a pseudo > device? But I do not know if this could be done by a pseudeo device. Etc. > ... I suspect that this thing uses libpci under Linux, which allows one to do all the nasty stuff in userland which is normally done in the probe and attach routines in the kernel. AFAIK libpci is very general und should work under FreeBSD too. However, if libpci does not work (I've never tried to use it with FreeBSD), then there's probably no way around writing a driver which at least does the basic probe/attach stuff to get the card mapped into the kernel. Beyond that you can probably get away with just providing mmap/ioctl support a la Linux. I personally would write a full-fledged driver. I don't think that this is something for which a pseudo-device is appropriate. I see that you're in Garching. I live in Munich and could maybe give you some help. Look me up in the phonebook, my name is unique. -- Gary Jennejohn [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: NMI during procfs mem reads (#2)
On 03-May-01 Warner Losh wrote: > In message <[EMAIL PROTECTED]> Kevin Day writes: >: The PCI target itself isn't doing anything like that, but it's possible that >: the PCI-PCI bridge we're going through might be. In any case, getting the >: NMI isn't really all that bad, it's stopping the chipset from getting hung >: on a infinite retry. My only concern is the NMI handler while in the kernel >: may be too aggressive in causing a panic. > > Yes. The NMI handler is a little too agressive about panicing. Also, > current has problems where sometimes it will panic when the nmi > happens with GIANT held. Correction, with a spin lock held. It may try to acquire Giant (not sure _why_ it acquires Giant) and then it pukes. Getting a traceback would be most helpful. :) Also, the output of 'show locks' from ddb could help, too. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [jkh@osd.bsdi.com: ANNOUNCE: Status update on ftp.freebsd.org A KA ftp.freesoftware.com]
On 3 May, Jordan Hubbard wrote: > Well, given that it's you I'm speaking with, I think we can just > settle for the Aliens explanation and leave it at that. In the real > world, shit happens and people do their best to deal with it, often > with inadequate information and a lack of alternative resources. > > I suppose I could also ascribe your own failure to ever come up with a > QIC tape driver or a floppy driver (despite months of "newsletters" > and apparent effort) as a coverup or major incompetence in action, but > that would be another case of reading too much into a sitution where > simple human frailty was a more than adequate explanation. > > If you wish to turn SVBUG into your own personal pulpit for conspiracy > theories and other wild-ass politicking then you're also free to do > so, but SVBUG should not then be surprised if the rest of us avoid it > like the plague. I've already made our position plain and this is the > last communication we need to have on the matter since I can easily > see that we're going squarely down the path of serious > non-productivity with this whole exchange. I also don't see where the > -hackers mailing list needs to be involved since this has NOTHING to > do with FreeBSD hacking. Have a nice day. > Mr. Hubbard, It's more than apparent I've found the right point at which to discuss this issue. If flame bait had to be labeled, in this case it would be 'aliens'. We both have bitten into that apple now. I hoped you would answer the question. However, given the past nature of your responses, my guess that you would take the 'aliens' route proved correct (at least to me). Conspiracy, that's your label. It has implications, I don't see any that apply; perhaps you do. As for the nature of SVBUG, perhaps you might consider that my 'wild-ass politicking' might be the response of the club as a whole. To which, a bunch of OS-X newbies might be the least of your issues for years to come. Lastly, as an SVBUG club member remarked last might, "perhaps FreeBSD will now become familiar with how the Jolitz felt, when they were accused of coverups." Best Regards, Jessem. > - Jordan > > From: [EMAIL PROTECTED] > Subject: Re: [[EMAIL PROTECTED]: ANNOUNCE: Status update on ftp.freebsd.org A KA >ftp.freesoftware.com] > Date: Thu, 3 May 2001 03:14:44 -0700 (PDT) > >> Jordan, >> I don't buy this story for a moment. You should expect >> SVBUG not to either. This can only be classified as: >> >> A) A poor excuse for a coverup (for some unknown reason) >> B) Major incompetence (in which someone should resign) >> C) Aliens have landed >> >> If as you say, it has been known since the 20th of >> April, 2001, then the world (and FreeBSD) has plenty >> of channels for communications. Windriver has a website, >> it is un-affected by FreeBSD traffic. BSDi has a website, >> it is un-affected by FreeBSD traffic. Daemonnews has >> a website Do I need continue? >> >> Best Regards, >> Jessem. >> >> >> >> >> > To: [EMAIL PROTECTED] >> > Subject: ANNOUNCE: Status update on ftp.freebsd.org AKA ftp.freesoftware.com >> > X-Mailer: Mew version 1.94.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) >> > Date: Wed, 02 May 2001 20:58:09 -0700 >> > From: Jordan Hubbard <[EMAIL PROTECTED]> >> > >> > Hi folks, >> > >> > This is just a short note to discuss the current state of affairs with >> > our master FTP site, explain what we're doing about it and combat some >> > of the FUD floating around which has everyone from space aliens to >> > Wind River Systems (who supply the space aliens with navigational >> > software, of course) intentionally killing the site off. >> > >> > On April 20th, 2001, the day that FreeBSD 4.3 was due to be released, >> > we lost access to our main FTP site, ftp.freesoftware.com, without any >> > advance warning. Further investigation revealed that the problem was >> > due to an unforeseen network outage which caused the hosting ISP to >> > have to block access to the site. With one of their major links down, >> > it was overloading the ISPs backup links and denying bandwidth to >> > their other customers. >> > >> > It was also not clear to us, then or now, just how long the outage >> > would last and whether this was to be a short-term or a long-term >> > problem. With the release date for 4.3 already well publicized in >> > advance and many people asking me for it, I decided to use one of our >> > backup sites, the usw[1-6].freebsd.org cluster, and at least get the >> > current releases bits up somewhere on an interim basis. >> > >> > Unfortunately, I really underestimated both the extent of the demand >> > and the degree to which our big, fat Gigabit pipe at ftp.freesoftware.com >> > has made distributing the bits to our mirrors look comparatively easy. >> > Even with the login limits set *signi
RE: [jkh@osd.bsdi.com: ANNOUNCE: Status update on ftp.freebsd.org A KA ftp.freesoftware.com]
K.J. thanks for your comments. I'll make sure to pass them on to the club. :-) Best Regards, Jessem. On 3 May, Koster, K.J. wrote: > Dear Jessem, > >> >> A) A poor excuse for a coverup (for some unknown reason) >> > Need a reason? See item C. > >> >> B) Major incompetence (in which someone should resign) >> > Does this mean you're volunteering? > > In case you don't: I hereby resign from the position of Major Incompetence. > I have proudly held this position for the past eigthteen seconds. However, > in honest and open talk with General Protection Failure we have come to the > conclusion that it's best for me to let the younger generation move up and > fill my shoes in this department. I have learned a lot from working with you > in this position and it hurts me to make this decision. Still, my life goes > on, and so does yours. > >> >> C) Aliens have landed >> > Ah. All is explained. > > Kees Jan > > > You are only young once, >but you can stay immature all your life. > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [jkh@osd.bsdi.com: ANNOUNCE: Status update on ftp.freebsd.orgA KA ftp.freesoftware.com]
I don't know what part of "this has nothing to do with hacking FreeBSD" you did not understand before, but this list has a very clear and well-stated CHARTER which is posted here: http://www.freebsd.org/doc/en_US.ISO_8859-1/books/handbook/eresources.html#ERESOURCES-MAIL and this discussion clearly does not fall under it. As the charter very explicitly states: "Ongoing irrelevant chatter or flaming only detracts from the value of the mailing list for everyone on it and will not be tolerated" You may therefore consider this your second official warning that you are not in compliance with the charter for this mailing list and need only one more offense to warrant a ban. Since this will also not be the first time you have managed to ban yourself from this list, I suspect that a ban on this occasion may prove permanent, so take heed! I have already communicated the true situation with ftp.freebsd.org as best I could using the appropriate channels and whatever you or SVBUG may choose to say about it is purely your own business, simply keep it off this mailing list. A perfectly good mailing list, [EMAIL PROTECTED], also exists for just this kind of thing and you are more than encouraged to take this "discussion" there. This is your second and final warning and if you choose to reply to this message, either make it personal to me only or cc it to freebsd-chat. I've only cc'd hackers twice myself to show that the issue is being dealt with and to ensure that the warnings are properly on record. Anything further you send to -hackers, unless on a more appropriate topic, will constitute a banning offense. Thank you. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [jkh@osd.bsdi.com: ANNOUNCE: Status update on ftp.freebsd.org A KA ftp.freesoftware.com]
Jordan, As far as I can see the ECHELON is still doing a good job of filtering his messages out, I have seen no traces of this thread anywhere else than on the encrypted monitor VPN. But I guess he is on to our plan, so we really have no choice but to kill him. Is it your turn or my turn to call the squad ? Ohh, btw: great cover story you got going there, I wonder if anybody else will catch the subtle irony of the first space tourist having the same name as a former eastern block dictator, TSGM were all howling from laughter when they heard it, you certainly scored some brownie points with that. And how's your new helicopter ? Black is always beautiful as they say :-) Poul-Henning In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes: >On 3 May, Jordan Hubbard wrote: >> Well, given that it's you I'm speaking with, I think we can just >> settle for the Aliens explanation and leave it at that. In the real >> world, shit happens and people do their best to deal with it, often >> with inadequate information and a lack of alternative resources. >> >> I suppose I could also ascribe your own failure to ever come up with a >> QIC tape driver or a floppy driver (despite months of "newsletters" >> and apparent effort) as a coverup or major incompetence in action, but >> that would be another case of reading too much into a sitution where >> simple human frailty was a more than adequate explanation. >> >> If you wish to turn SVBUG into your own personal pulpit for conspiracy >> theories and other wild-ass politicking then you're also free to do >> so, but SVBUG should not then be surprised if the rest of us avoid it >> like the plague. I've already made our position plain and this is the >> last communication we need to have on the matter since I can easily >> see that we're going squarely down the path of serious >> non-productivity with this whole exchange. I also don't see where the >> -hackers mailing list needs to be involved since this has NOTHING to >> do with FreeBSD hacking. Have a nice day. >> >Mr. Hubbard, >It's more than apparent I've found the right point at which to >discuss this issue. If flame bait had to be labeled, in this case >it would be 'aliens'. We both have bitten into that apple now. > >I hoped you would answer the question. However, given the past >nature of your responses, my guess that you would take the 'aliens' >route proved correct (at least to me). Conspiracy, that's your label. >It has implications, I don't see any that apply; perhaps you do. > >As for the nature of SVBUG, perhaps you might consider >that my 'wild-ass politicking' might be the response of the >club as a whole. To which, a bunch of OS-X newbies might >be the least of your issues for years to come. > >Lastly, as an SVBUG club member remarked last might, "perhaps >FreeBSD will now become familiar with how the Jolitz felt, when >they were accused of coverups." > > Best Regards, > Jessem. > > > > >> - Jordan >> >> From: [EMAIL PROTECTED] >> Subject: Re: [[EMAIL PROTECTED]: ANNOUNCE: Status update on ftp.freebsd.org A KA >ftp.freesoftware.com] >> Date: Thu, 3 May 2001 03:14:44 -0700 (PDT) >> >>> Jordan, >>> I don't buy this story for a moment. You should expect >>> SVBUG not to either. This can only be classified as: >>> >>> A) A poor excuse for a coverup (for some unknown reason) >>> B) Major incompetence (in which someone should resign) >>> C) Aliens have landed >>> >>> If as you say, it has been known since the 20th of >>> April, 2001, then the world (and FreeBSD) has plenty >>> of channels for communications. Windriver has a website, >>> it is un-affected by FreeBSD traffic. BSDi has a website, >>> it is un-affected by FreeBSD traffic. Daemonnews has >>> a website Do I need continue? >>> >>> Best Regards, >>> Jessem. >>> >>> >>> >>> >>> > To: [EMAIL PROTECTED] >>> > Subject: ANNOUNCE: Status update on ftp.freebsd.org AKA ftp.freesoftware.com >>> > X-Mailer: Mew version 1.94.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) >>> > Date: Wed, 02 May 2001 20:58:09 -0700 >>> > From: Jordan Hubbard <[EMAIL PROTECTED]> >>> > >>> > Hi folks, >>> > >>> > This is just a short note to discuss the current state of affairs with >>> > our master FTP site, explain what we're doing about it and combat some >>> > of the FUD floating around which has everyone from space aliens to >>> > Wind River Systems (who supply the space aliens with navigational >>> > software, of course) intentionally killing the site off. >>> > >>> > On April 20th, 2001, the day that FreeBSD 4.3 was due to be released, >>> > we lost access to our main FTP site, ftp.freesoftware.com, without any >>> > advance warning. Further investigation revealed that the problem was >>> > due to an unforeseen network outage which caused the hosting ISP to >>> > have to block access to the si
real time
Does FreeBSD has any related work about it as an real time operating system? Where can i find information about that ?? --- Joao Carlos [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [jkh@osd.bsdi.com: ANNOUNCE: Status update on ftp.freebsd.org A KA ftp.freesoftware.com]
: :And how's your new helicopter ? Black is always beautiful as they say :-) : :Poul-Henning Helicopter? Pah! I know for a fact that Jordan was bribed with a brand spanking new hovermobile by the afformentioned aliens! (which, oddly enough looks somewhat like a DeLorean with a MrCoffee bolted to the back, hrm). -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Web Development
Hi, Hi, I do web development and database work out of Las Vegas. I was wondering if you needed any development done. I have been doing web work for 6 years. I know Cold Fusion, ASP, Oracle, SQL and Flash. Tony Grijalva 702.951.3051 Here's some the sites I've worked on: http://www.crazynickels.com - Complete site. Turned out in 3 days. http://www.woodtrim.com - Complete sites along with www.brushed aluminum.com as a content manager, shopping cart, FAQ, Referral Program. http://www.SchoolCity.com - Pre-IPO Company I did the Complete site. I can send you a complete document about this site. http://www.codernet.com - My own site with a bunch of guys here. I did the graphics. http://www.antennas.com - The graphics were given to me in PhotoShop format. I have to make them web ready and add functions. http://www.momentisgroup.com - Backend Cold Fusion work. http://www.isecinc.com - Their print company in Arizona sent me the project and related functions. I can walk you through a back door process. http://www.reoinc.com - Working on Now. http://www.arraybiopharma.com - Needed the site before they went public... I didn't do the flash but everything else and some cgi. http://www.linworth.com - Got PhotoShop files. Added Cold Fusion functions. Please let me know if you need any help.. Thank You for your time and consideration, Tony Grijalva 702.951.3051 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [jkh@osd.bsdi.com: ANNOUNCE: Status update on ftp.freebsd.org A KA ftp.freesoftware.com]
Thus spake Matt Dillon ([EMAIL PROTECTED]): > Helicopter? Pah! I know for a fact that Jordan was bribed with > a brand spanking new hovermobile by the afformentioned aliens! > (which, oddly enough looks somewhat like a DeLorean with a MrCoffee > bolted to the back, hrm). I always thought sheep drive Vespas. :) Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Kernel Console speed
Dear Mike, Mike Smith wrote on Wed, May 02, 2001 at 04:08:25PM -0700: [..] > You don't want to set CONSPEED in the kernel config, or change the loader > configuration. Just build/install boot1/boot2 with a new > BOOT_COMCONSOLE_SPEED, and ensure that /etc/ttys is correctly set for > your desired console rate. This works. I tried this. Rebuilt the kernel without any CONSPEED option, bootstrap untouched (did already work with 38400), still the same problem. To illustrate it a bit, here cut & paste from the console server, which is permanently set at 38400: [..] Console: serial port BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS drive D: is disk2 BIOS drive E: is disk3 BIOS 639kB/523264kB available memory FreeBSD/i386 bootstrap loader, Revision 0.8 ([EMAIL PROTECTED], Tue Apr 24 09:16:22 CEST 2001) Loading /boot/defaults/loader.conf /kernel text=0x20ec4e data=0x27cd4+0x301a4 syms=[0x4+0x2d3e0+0x4+0x32f1e] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [kernel]... øøàøøÀÀ... [.. from here on, the kernel boot messages should appear starting with: Copyright (c) 1992-2001 The FreeBSD Project. but its not readable on the console-server, because of the wrong speed. This stays until /etc/rc.sysctl resets machdep.conspeed=38400 Then the system startup / rc continues (then readable) until the getty is started (which of course is also running at 38400) ..] øàþøÀøàüüxachdep.conspeed: 9600 -> 38400 Doing initial network setup: hostname. fxp0: flags=8843 mtu 1500 inet 131.159.72.9 netmask 0xfe00 broadcast 131.159.73.255 inet6 fe80::2a0:c9ff:fe99:504e%fxp0 prefixlen 64 tentative scopeid 0x1 inet 131.159.72.28 netmask 0x broadcast 131.159.72.28 ether 00:a0:c9:99:50:4e media: autoselect (100baseTX ) status: active [ remaining startup output omitted ] Additional TCP options:. Thu May 3 21:02:16 CEST 2001 FreeBSD/i386 (atleo1.leo.org) (ttyd0) login: [..] So far... Thanks, Daniel -- IRCnet: Mr-Spock- Eddie would go! - Daniel Lang * [EMAIL PROTECTED] * +49 89 289 25735 * http://www.leo.org/~dl/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to use netgraph?
On Thu, May 03, 2001 at 10:20:45AM +0200, Gunnar Olsson wrote: > I have a process in user space, that wants to send a packet > direct on the ethernet, not encapsulate the packet in IP. > When I read about netgraph, it looks like it possible to do, or? > When I hook to a upper or a lower hook, does the kernel create > the ethernet header, or do I have to create the ethernet header > in the user process myself before sending down? > > If the kernal is adding the ethernet header, > what is actually sent out on the wire? Usaully an ARPLOOKUP > is done and maps the IP dst to a MAC dst, but now I do not > have the IP header. How to get the MAC dst field filled in? It's rather unnecessicary to use netgraph for this purpose. Instead you can use the well hidden feature of the bpf device that it can write as well as read. If you want to send packets with arbitrary sender addresses, you will want to use the BIOCGHDRCMPLT ioctl to enable that (not all cards support this, for instance wireless cards do not.) You might also look at libnet which provides wrappers for this, but I seem to recall that it doesn't support BIOCGHDRCMPLT. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 PGP signature
/etc/rc.network and natd_enable
In 4.2-STABLE, /etc/rc.network has entries to turn on natd. However, natd does not get enabled if you don't specify natd_interface. WHat if you you have setup stored in a configuration file and do not wish to supply an interface flag in /etc/rc.conf? Well, natd does not turn on! Would it make more sense to do something like (psuedo-ish code): if (natd_enable = YES) if (natd_interface defined) natd -n $natd_interface $natd_flags elif (natd_flags defined) natd $natd_flags fi fi It would allow for people to not specify a natd_interface but still be able to run natd out of rc.conf. What does everyone think of this? I guess you pay the penalty if someone doesn't setup the flags properly but I guess you could write that off as a config error anyways. Nick Rogness <[EMAIL PROTECTED]> - Keep on Routing in a Free World... "FreeBSD: The Power to Serve!" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: /etc/rc.network and natd_enable
On Thu, 3 May 2001, Nick Rogness wrote:
> In 4.2-STABLE, /etc/rc.network has entries to turn on natd.
> However, natd does not get enabled if you don't specify
> natd_interface. WHat if you you have setup stored in a
> configuration file and do not wish to supply an interface flag in
> /etc/rc.conf? Well, natd does not turn on!
I've attached a very simple, but untested patch that will DTRT.
Anyone care to commit this if Nick says it works as expected?
Just in case the attachment doesn't make it, here it is inline (be
careful of cut'n'paste tab-to-space conversions).
--- rc.network.orig Thu May 3 17:04:05 2001
+++ rc.network Thu May 3 17:18:52 2001
@@ -269,7 +269,9 @@
else
natd_ifarg="-n
${natd_interface}"
fi
+ fi
+ if [ -n "${natd_interface}" -o -n
+"${natd_flags}" ]; then
echo -n ' natd';
${natd_program:-/sbin/natd} ${natd_flags} ${natd_ifarg}
fi
;;
-- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED]
FreeBSD: The fastest and most stable server OS on the planet.
For IA32 and Alpha architectures. IA64, PPC, and ARM under development.
http://www.freebsd.org
--- rc.network.orig Thu May 3 17:04:05 2001
+++ rc.network Thu May 3 17:18:52 2001
@@ -269,7 +269,9 @@
else
natd_ifarg="-n
${natd_interface}"
fi
+ fi
+ if [ -n "${natd_interface}" -o -n
+"${natd_flags}" ]; then
echo -n ' natd';
${natd_program:-/sbin/natd} ${natd_flags} ${natd_ifarg}
fi
;;
Re: /etc/rc.network and natd_enable
On Thu, May 03, 2001 at 05:17:17PM -0500, Nick Rogness wrote:
>
> In 4.2-STABLE, /etc/rc.network has entries to turn on natd. However, natd
> does not get enabled if you don't specify natd_interface. WHat if you you
> have setup stored in a configuration file and do not wish to supply an
> interface flag in /etc/rc.conf? Well, natd does not turn on!
>
> Would it make more sense to do something like (psuedo-ish code):
>
> if (natd_enable = YES)
>
> if (natd_interface defined)
> natd -n $natd_interface $natd_flags
> elif (natd_flags defined)
> natd $natd_flags
> fi
> fi
>
>
> It would allow for people to not specify a natd_interface but still be
> able to run natd out of rc.conf. What does everyone think of this?
>
> I guess you pay the penalty if someone doesn't setup the flags properly
> but I guess you could write that off as a config error anyways.
>
${natd_interface} is required to set up the ``divert natd'' rule
from /etc/rc.firewall.
Cheers,
--
Ruslan Ermilov Oracle Developer/DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
