Displaying options for current NFS mounts

[Gerald Pfeifer]

I tried to get some responses to this on -questions a couple of months
ago, but failed:

What I'd like to see is `mount -v' printing

  mail:/var/mail on /var/mail (nfs: v3, udp)
  vexpert:/files7 on /system (nfs: v3, tcp)
  vexpert:/files5 on /.amd_mnt/vexpert/files5 (nfs: v3, udp)
   
instead of

  mail:/var/mail on /var/mail (nfs)
  vexpert:/files7 on /system (nfs)
  vexpert:/files5 on /.amd_mnt/vexpert/files5 (nfs)
   ^^^

This kind of information is incredibly useful for debugging, yet I
haven't found ANY way to obtain it, let alone such a natural one.

Gerald


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Intel driver doc's Take 2.

[Peter Wemm]

Mike Smith wrote:
> > On Fri, 23 Mar 2001, Daniel C. Sobral wrote:
> > 
> > > Let me just pipe in a bit. Compromise seems just like the kind of thing
> > > marketing or legal would want to do. The problem is that _we_ cannot
> > > compromise because one cannot write a "half-way there" driver. It's a
> > > technical impossibility.
> > 
> > I agree 100%. I don't think this will fly either. I am just making the
> > effort to work with Intel to get what we need. It's not going to happen
> > overnight. Period. They are not going to change their NDA policy. In the
> > future maybe. Actually I will forward the email she sent me this last time
> > after I got off the phone with her an hour ago. I mentioned the problems
> > Jonathan had with the GigE card. That's why she refers to him. Anyway I
> > will forward it in a sec to the list.
> 
> [Speaking here from some experience with this set of issues.]
> 
> The compromise that you want to strike, and really the *only* compromise 
> that is going to work, is that the *documents* will remain undisclosed, 
> but information from the documents that is necessary to produce a 
> functional, high-performance driver may be disclosed, but *only* through
> the source code of the driver.
> 
> Thus one or a small group of people sign the NDA, and keep the
> documentation.  The driver is then developed and maintained by this team, 
> who also have the opportunity to interact with Intel's engineering 
> people.  The source code resulting from this effort is then released 
> publically.  Intel should probably retain the right to veto code that you 
> might want to put in the driver if they feel that it risks disclosure 
> they don't want, but you don't have to suggest this to them unless you 
> feel you need it as a bargaining chip.
> 
> This would put them in the same situation as they are already in with 
> their source-available Linux driver; it should not present any more 
> intellectual property risks than they already face, and as a bonus, it 
> gets us a better-supported driver.

Yes, but for goodness's sake, make sure there are time limits on it!

Try this:
1 - Give a select group of people the docs under NDA
2 - If there are any specific features Intel wants avoided, get them to
identify
them up front.
3 - Let them write a driver that uses whatever features that are useful, with
header files that define the register bits etc that are reasonably related
to the features used.
4 - Hand over the driver to intel for "final veto" with a pre-agreement in
place so that if they do not respond in 30 days we can release it as-is.
5 - If they have specific features or register bit definitions that they want
removed, then do so as long as it isn't going to hopelessly cripple the
driver.  If they want something removed that wasn't covered in the list at
the start and is going to cause severe performance problems (say a 10%
performance or efficiency drop), too bad.
6 - Repeat the loop for 'final veto' but with a week timeout instead of 30
days.

Regarding step 5; if the information is already "out there" (other open
source drivers, leaked onto the internet, etc) then it is fair game and we
can use it.

With somebody like Intel, it is pretty important to get this in some form of
writing.  They have a horrible habbit of "forgetting" things that are "too
hard" (eg: sweeping your driver for unused information).

The reason Intel keep a tight lid on this stuff is that they are very
afraid of losing their "competitive advantage" of having functional fxp
drivers in the Windows installation, while most of the other ethernet cards
do not. If somebody can clone the 8255x series such that it is "close
enough" from publically available documentation that it will work with the
windoze CD drivers, then Intel loses the upper hand.  *That* is what they
are afraid of.  If some taiwanese manufacturer makes a clone and intel goes
after them, and they can point to the freebsd fxpreg.h file that
thoughtfully defines every single bit and register in the NDA manuals, you
can bet that Intel wont be happy.  On the other hand, if it meant that they
would have had to pull the drivers apart (illegal under DMCA in the US),
Intel would be able to sue them to death if they ever tried to sell it in
the US.  And then there's always the 'trade secrets' lawsuits of death.
(remember Intel vs VIA over the "Apollo" BX chipset workalike).

The 'yellow manual' describes the chips, steppings, quirks, workarounds,
etc in painful detail... In enough detail that one could do a legal 'clean
room' implementation if the manual were freely available.

However, there are lots of things that would never go into a FreeBSD driver.
Things like the microcode interfaces for the wake-on-lan sequencer/filter,
etc.  There are a bunch of stuff that is totally irrelevant to us.  There
are a bunch of things on the chips that are so badly broken that they are
not useful to us at all (eg: the checksum assist

so where is our press-release about MacOS X ?

[Poul-Henning Kamp]

Shouldn't the FreeBSD project issue a press release welcoming
Apple's MacOS X ?

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: GCC Upgrade?

[David O'Brien]

On Wed, Mar 21, 2001 at 01:35:30PM -0500, Alexander N. Kabaev wrote:
> This patch will work. According to Berndt Schimidt, there are some problems
> with it on HP/UX and that was the main reason why it was backed out. I never saw
> any ill effects on i386 with this patch though, while good efects include:
> 
> a) working sjlj exceptions
> b) ability to compile QT2 with exceptions enabled and with -O2 flag without
> consuming ~400M memory for abnormal call egdes in GCC flow optimization pass.

It has been committed now and will be MFC'ed to stable after tax day.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: question about BPF programming

[Archie Cobbs]

Andrey Simonenko writes:
> I read bpf(4) man page and have one question about BPF.
> Suppose I open one of free BPF devices /dev/bpf??. I can dup(2)
> descriptor of opened BPF device and get so called shared interface.
> 
> Can I setup different filters on each descriptor for opened BPF device?

Nope. Quoting dup(2):

The object referenced by the descriptor does not distinguish between oldd
and newd in any way.  Thus if newd and oldd are duplicate references to
an open file, read(2),  write(2) and lseek(2) calls all move a single
pointer into the file, and append mode, non-blocking I/O and asynchronous
I/O options are shared between the references.

-Archie

__
Archie Cobbs * Packet Design * http://www.packetdesign.com

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: kern/23620: Fore PCA200E driver

[Richard Hodges]

I hate to follow up on my own post, but I have not heard a
word of comment, positive or negative... 

-Richard

On Fri, 2 Mar 2001, Richard Hodges wrote:

> Hi, all!
> 
> A couple months ago, I submitted PR kern/23620 describing a problem
> with the Fore PCA200E driver for HARP.  It includes a description
> of the problems and a patch.
> 
> Could someone commit this to STABLE so that it has a chance of
> making it into 4.3 RELEASE?

---
   Richard Hodges   | Matriplex, inc.
   Product Manager  | 769 Basque Way
  [EMAIL PROTECTED]  | Carson City, NV 89706
775-886-6477| www.matriplex.com 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Intel driver doc's Take 2.

[Olibert Obdachlos]

> > restricted by the NDA, does your driver support the newer Intel
> > Pro/1000 F cards, which had been mentioned here a couple months

> I'm admittedly not familiar with Intels marketing nomenclature.  But
> if by "1000 F", you mean the 82543/Livingood chip, then yes, this
> driver should work on that board.

Thanks!  That's exactly what I was hoping to know before getting
too deep over my head.

Consider yourself lucky -- I spent a while navigating the Intel
website to see if much had changed.  I did dig up the old message
I had sent which isn't worth reposting, but may contain pointers
to marketroid data and the like.  It's from 19.Jan in -hardware,
Message-ID: <[EMAIL PROTECTED]>
or news:[EMAIL PROTECTED]
but it's probably not worth digging out of the archive now.


>   In fact, the driver was designed
> around the 82543, and then backported to 82542 (wiseman).

I haven't had my sweaty hands over one of these cards, but I'll
assume the 82543GC discussed in these messages is equivalent.
I'll also try to get a close look at a card to know what is in
use.


> > the impossible.  Or consider this a possible problem report on the
> > driver with the Pro 1000 F...
> 
> Hmm.  Send me details, the more information, the better.

I'll wait a second before passing on details I don't have at hand,
because I can't say I trust the test machine it was placed in,
which spontaneously rebooted on me at reboot time, and then wedged
up at a following reboot.  I think it needs a high-speed lesson
through the machine room to meet Mister Floor.  Also, I don't trust
the configuration that dmesg reveals at boot -- I got stellar
performance from a similar machine when it assigned IRQs like 20
and 21 to the fxp ethernet card, while on a different HP machine,
I had hell trying to get both an ethernet card and a pile of sound
cards to work, when IRQs were given similar to what this test
machine wants to give, and I needed to do some juggling of cards to
get anything to happen.  Everything worked great when I got the high
IRQs though.  So it's quite possible that this machine needs to have
the gigabit ethernet card swapped around -- it came up at irq5.
This card is also installed in another machine currently doing
production service and was given irq21 or something, so there is
definitely some weird BIOS difference between the two machines.
I hate PC hardware.

This will probably wait til monday, and I'll also ask our techie
who posted some details last time if he's seeing exactly the same
thing now.  I made some tests I didn't try last time, but before
I make any claims, I want to eliminate the possibility of flaky
hardware at this end and gather relevant details.


Thanks, I'll get back to you about this...
barry bouwsma, resident TDC internet netmangler


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: PPPD!

[Roman V. Palagin]

On Mar 23, at 8:20pm +0200, petro wrote:

> Does anybody know about support pppunit in the ppp conf files, or may be
> can advice me where I can read about pppunit.
> Thank you very much.

pppunit is for pppd. Check out ftp://room101.wuppy.net.ru/pppd.

 - Roman
---
Any opinions in this posting are my own and not those of my present
or previous employers.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Problems with new RPC

[Gordon Tetlow]

If you haven't, please please please, send-pr(1) this so the right people
get a look at this. Last thing we need is a broken ypbind (not that I use
it). More down below.

On Fri, 23 Mar 2001, Harti Brandt wrote:

> the recent update to RPC causes ypbind to break. The problem is, that
> /usr/src/usr.sbin/ypbind/yp_ping.c mirrors some code from the RPC library,
> including the internal structure used for the CLIENT structure. The
> version in libc uses a struct sockaddr_storage (128 bytes) whereas yp_ping
> has a struct sockaddr_in (something lesser). The libc version also
> includes a member just at the end of the structure (struct pollfd) that
> the ypbind version does not have.
> Because the XDR buffers are allocate directly behind struct CLIENT, this
> makes the pointers into the buffer wrong. This causes the ypbind child to
> dump core, which in turn causes the parent to create a new child, which
> dumps core, causing the parent to create a new child, which dumps core ...
>
> A simple fix (rather a workaround is):
>
> Index: yp_ping.c
> ===
> RCS file: /usr/ncvs/src/usr.sbin/ypbind/yp_ping.c,v
> retrieving revision 1.8
> diff -u -r1.8 yp_ping.c
> --- yp_ping.c 2001/03/19 12:50:12 1.8
> +++ yp_ping.c 2001/03/20 13:46:24
> @@ -93,6 +93,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include "yp_ping.h"
>
> @@ -126,7 +127,7 @@
>  struct cu_data {
>   intcu_sock;
>   bool_t cu_closeit;
> - struct sockaddr_in cu_raddr;
> + struct sockaddr_storage cu_raddr;
>   intcu_rlen;
>   struct timeval cu_wait;
>   struct timeval cu_total;
> @@ -136,6 +137,7 @@
>   u_int  cu_sendsz;
>   char   *cu_outbuf;
>   u_int  cu_recvsz;
> + struct pollfd   cu_pollfd;
>   char   cu_inbuf[1];
>  };
>
> Another problem which started at the day the RPC stuff was committed are
> error messages of the form
>
> yp_match: clnt_call: RPC: Program unavailable
>
> spit out from various programs, among them pine, tcpdump, tcptrace.
> How can I fix this (or at least find out, what's the problem)?

If I had to take a wild stab, if ypbind isn't working right, I suspect
that tcpdump is doing RPC lookups on traffic going by. The rest? ah who
knows.

-gordon


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: tuning a VERY heavily (30.0) loaded s cerver

[Adrian Chadd]

On Fri, Mar 23, 2001, Robert Watson wrote:
> 
> On Fri, 23 Mar 2001, Alexey V. Neyman wrote:
> 
> > On Thu, 22 Mar 2001, Michael C . Wu wrote:
> > 
> > >(Why is vfs.vmiodirenable=1 not enabled by default?)
> > By the way, is there any all-in-one-place description of sysctl tuneables?
> > Looking all the man pages and collecting notices about MIB variables seems
> > rather tiresome and, I think, pointless. I doubt if they are all
> > documented in man pages.
> 
> sysctl(3) describes a number of the constant-named sysctl variables, and a
> number of sysctl's are described in the man pages associated with the
> features tweaked by the sysctl's.  For example, the jail(8) man page
> describes the jail.* namespace.  However, you're right that there are vast
> hoards of under-documented sysctl's.  That said, probably only the
> "tweakable" (writable) sysctl's need to be documented in the general case,
> since many are used for the sole purpose of exporting kernel data for
> supported interfaces, whereas the sysctl's are subject to change.  For
> example, a large number of read-only sysctl's were introduced to support
> the non-setgid-kmem operation of top, systat, and various other *stat's
> recently.  Also, many sysctl's are "self-documenting", in that the
> declaration of the sysctl macros in-kernel include a description field.  I
> don't think sysctl(8) currently knows how to read that field, but if you
> look at the SYSCTL definitions in the kernel source, they're probably a
> decent starting point.  A magic script to extract the sysctl names, types,
> and descriptions might be useful..

A while back I started running through the undocumented sysctls and
documenting them. I didn't get through all of them, and the main reason
I stopped was because there wasn't a nifty way to extract the sysctls
short of writing a script to extract them from /usr/src.

Someone did point out that you could stuff the sysctl's into an elf
segment and only load it when needed, but I don't know much about elf.
If someone would like to do this, I'm sure a small group of us
(Asmodai? :-P) could walk the sysctl tree again and figure out what
the undocumented sysctls are. :-)




adrian

-- 
Adrian Chadd"Programming is like sex:
<[EMAIL PROTECTED]>   One mistake and you have to support for
a lifetime." -- rec.humor.funny


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: The "right" way to build a new world WAS: 4.3-BETA world crashin g 4.2-RELEASE kernel ?

[Warner Losh]

In message <[EMAIL PROTECTED]> Robert 
Watson writes:
: On Fri, 23 Mar 2001, Warner Losh wrote:
: 
: > You'll also get better milage out of make -j N (say 3 or 4) and doing
: > things sequentially.  It is safer and runs just as fast. 
: 
: Dunno if it was a temporary compile problem, but I've actually found that:
: 
:   make -j 3 buildkernel
: 
: hasn't worked properly for me.  Either it was a temporary thing and may be
: fixed now, or it's a property of the buildkernel dependencies, and should
: probably be fixed (my kernel build is substantially faster with just a bit
: of parallelism to keep the CPU busy).

I think that it works.  I know that the "old way" works with -j values
up to 20 (haven't tried anything higher).  There were issues with -j
for a while, but those have been fixed.  They were inadvertantly
introduced when we went to building modules.

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: PPPD!

[Brian Somers]

> Hi!
> Does anybody know about support pppunit in the ppp conf files, or may be
> can advice me where I can read about pppunit.
> Thank you very much.

I'm afraid I can't really help, but I believe ppp(8) can do the same 
thing with the -unit command line switch.
-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

PPPD!

[petro]

Hi!
Does anybody know about support pppunit in the ppp conf files, or may be
can advice me where I can read about pppunit.
Thank you very much.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: The "right" way to build a new world WAS: 4.3-BETA world crashin g 4.2-RELEASE kernel ?

[Robert Watson]

On Fri, 23 Mar 2001, Warner Losh wrote:

> You'll also get better milage out of make -j N (say 3 or 4) and doing
> things sequentially.  It is safer and runs just as fast. 

Dunno if it was a temporary compile problem, but I've actually found that:

  make -j 3 buildkernel

hasn't worked properly for me.  Either it was a temporary thing and may be
fixed now, or it's a property of the buildkernel dependencies, and should
probably be fixed (my kernel build is substantially faster with just a bit
of parallelism to keep the CPU busy).

Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED]  NAI Labs, Safeport Network Services



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: The "right" way to build a new world WAS: 4.3-BETA world crashin g 4.2-RELEASE kernel ?

[Warner Losh]

In message <8D18712B2604D411A6BB009027F6449801B4B544@0SEA01EXSRV1> "Matt Simerson" 
writes:
: I have found that there IS a variety of reasons NOT to do it that way. The
: most obvious is that you might not have console access, thus making it
: pretty hard to access the machine while it's in single user mode. I can also
: think of a couple instances where this method could cause pain. 

The most obvious reason to do it is that it works.  Updating a system
can cause pain.  Get used to it.  There are often times that many of
the binaries that are running in multiuser mode can crash your system, 
so you can't get up into multi user.  On major upgrades, you can't
even get through the installworld with the old kernel.

Having said that, I have often done things not in single user when the 
jumps were small.  I usually get away with it, but have at times
really hozed my system.  Once or twice to the point I had to take the
disk out of the machine and over to a working machine for touch ups.

: The first is changing of any of the files used at boot time. I don't allow
: telnet access to any of my machines so SSH is often as close as I can get to
: console. If anything changes enough that we don't cleanly make it through rc
: and friends, processing stops, sshd won't be running and I can't get in. The
: one time this happened the machine didn't make it multi user. Fortunately
: that machine was in my basement so I walked down, looked at the errors on
: the console and finished the upgrade.

mountd is a big one why we wouldn't get through rc.  I've had it crash 
the new kernel due to weaknesses in the kernel/user api that it uses.

: IPFW changes. This one isn't quite obvious but if you don't compile your
: kernel with IPFW_DEFAULT_TO_ACCEPT and changes are made to the kernel or
: userland portions and not the other (as will happen in the above scenario)
: then upon reboot, if your ruleset doesn't get applied, you won't be able to
: access your machine via the network. Ouch. I always compile in the
: DEFAULT_TO_ACCEPT for this reason and then add a default deny rule to the
: IFPW ruleset. Even so, I find it's best to get my kernel, world, and config
: files synced before rebooting.

This introduces other problems.  In the interrum between ifconfig and
ipfw you are wide open to the world.  Many attacks only need a few
packets to gain root.

:cd /usr/src
:make buildworld
:make kernel KERNCONF=
:make installworld
:mergemaster
:reboot
:cd /usr/src
:make installkernel KERNEL=

Why install the kernel twice?  make kernel installs the kernel.

: One can also often get away with making a new kernel without first building
: world but do so at your own peril (as I often do). :-)  I often issue the
: buildkernel and buildworld at the same time and then leave for the day. My
: reasons for doing this are: laziness, impatience, and wanting to have the
: entire compilation done when I return. Doing so can be risky but in my
: experience, works just fine with the -stable tree. Others have been quick to
: point out the possible hazards of doing so but they mostly apply when
: playing with -current.

You can also run into problems with -stable.  I've run into those
problems.  It is espeically accute when updating 4.0 machines to 4.3,
for example.  You are dodging a minefield in doing things this way.

You'll also get better milage out of make -j N (say 3 or 4) and doing
things sequentially.  It is safer and runs just as fast.

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Intel driver doc's Take 2.

[Jonathan Lemon]

On Fri, Mar 23, 2001 at 04:08:39PM +0100, Olibert Obdachlos wrote:
> If I may ask, this binary driver, which cards does it support and
> which cards does it *not* support?  Or if releasing that info is
> restricted by the NDA, does your driver support the newer Intel
> Pro/1000 F cards, which had been mentioned here a couple months
> back (Livengood, if I remember, and which decidedly did not work
> with the driver by Matthew Jacob)?

I'm admittedly not familiar with Intels marketing nomenclature.  But
if by "1000 F", you mean the 82543/Livingood chip, then yes, this
driver should work on that board.  In fact, the driver was designed
around the 82543, and then backported to 82542 (wiseman).

It won't work with the 1000 T (twisted pair) just yet, since I haven't
written the PHY support for that card.  (I only have the fiber versions
of the card here).  But it should work with all the fiber mode cards.


> I did experiment with the driver and the card ealier today for an
> hour or so without complete success, like no network functionality
> at all, but I'm not going to rule out pilot error, though it seemed
> to exhibit similar lack of functionality to the wx driver.  If it
> should work, I'll think about giving it another shot, but if it
> only works with the 1000 cards (not the F or T) then I won't try
> the impossible.  Or consider this a possible problem report on the
> driver with the Pro 1000 F...

Hmm.  Send me details, the more information, the better.
--
Jonathan

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Intel driver doc's Take 2.

[Olibert Obdachlos]

:: Hah, me neither.  In fact, if you want to try out a binary of my
:: Intel GigE driver, it is at http://www.flugsvamp.com/~jlemon/fbsd/drivers
:: Jonathan

Wow, what I coincidence.  I just did a search a couple days ago for
any recent developments, and earlier today spent a bit of time with
this very driver, with absolutely no idea this conversation had
just taken place...

A quick background -- some months ago I asked about a Gig ethernet
driver when the wx driver didn't seem to work, and I had no e-mail
address and was planning to be somewhere else.  Well, I still have
no e-mail address and I haven't escaped yet, but again, the reply
address will reach the people who are in charge of the machinery,
and I peek in on the lists now and then.  Like now.

If I may ask, this binary driver, which cards does it support and
which cards does it *not* support?  Or if releasing that info is
restricted by the NDA, does your driver support the newer Intel
Pro/1000 F cards, which had been mentioned here a couple months
back (Livengood, if I remember, and which decidedly did not work
with the driver by Matthew Jacob)?

I did experiment with the driver and the card ealier today for an
hour or so without complete success, like no network functionality
at all, but I'm not going to rule out pilot error, though it seemed
to exhibit similar lack of functionality to the wx driver.  If it
should work, I'll think about giving it another shot, but if it
only works with the 1000 cards (not the F or T) then I won't try
the impossible.  Or consider this a possible problem report on the
driver with the Pro 1000 F...


Thanks!
barry bouwsma, still stuck at cold snowy TDC internet


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: driver: probe not called when smbus child

[Nicolas Souchu]

On Tue, Mar 20, 2001 at 04:50:09PM +0100, Willem van Engen wrote:
> I'm trying to write a module which should be a child of the smbus.
> When I make the driver a child of the isa bus, identify, probe, 
> and attach functions are properly called. I use the following
> code to do that:
>   DRIVER_MODULE(my, isa, my_driver, my_devclass, 0, 0);
> But when I put it on the smbus using
>   DRIVER_MODULE(my, smbus, my_driver, my_devclass, 0, 0);
> only identify is called. The identify function is as follows:
> 
>   static void
>   my_identify(driver_t *driver, device_t parent)
>   {
>   devclass_t dc;
>   device_t child;
> 
>   printf("my: my_identify called\n");
>   dc = devclass_find("my");
>   if (devclass_get_device(dc, 0)==NULL) {
>   child = BUS_ADD_CHILD(parent, 0, "my", -1);
>   }
>   }
> 
> The driver only uses smbus calls, so I think the best parent
> would be smbus.

I'm currently working on this.

> And when I do a smbus_request_bus, the call waits forever as
> it seems. That seems sensible to me, because it asks the
> parent for the bus and the isa bus can't grant requests for
> the smbus. So I think the driver has to be a child of the smbus.

requesting the smbus is needed when the smbus controller potentially
share resources on another bus (like lpbb(4) does on ppbus).

> Looking in the kernel sources, I see that the only smbus child
> I can find, smb, (if there are others, I'm certainly interested)
> is attached in the smbus code itself. So the next question rises:
> Is it possible to have an smbus child in a dynamically loadable
> module (I can't find smbus.ko in /modules, so loading the child
> first and then smbus isn't an option I guess) ?

Currently, smb is the only smbus child. This is due to the fact that
most people prefer programming their SMB chips from user space.

I have a patch and a complete modules/i2c tree for compiling smbus and
smb as modules. You must be interested... But I have to fix some issues
like identification and driver dynamic addition.

-- 
[EMAIL PROTECTED]
Alcôve - Open Source Software Engineer - http://www.alcove.com

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Problems with new RPC

[Harti Brandt]

Hi,

I described the problem a couple of days on -current, but either I'm
doing something dumb or nobody is using ypbind -- I got no answer up to
now. So here is it again:

the recent update to RPC causes ypbind to break. The problem is, that
/usr/src/usr.sbin/ypbind/yp_ping.c mirrors some code from the RPC library,
including the internal structure used for the CLIENT structure. The
version in libc uses a struct sockaddr_storage (128 bytes) whereas yp_ping
has a struct sockaddr_in (something lesser). The libc version also
includes a member just at the end of the structure (struct pollfd) that
the ypbind version does not have.
Because the XDR buffers are allocate directly behind struct CLIENT, this
makes the pointers into the buffer wrong. This causes the ypbind child to
dump core, which in turn causes the parent to create a new child, which
dumps core, causing the parent to create a new child, which dumps core ...

A simple fix (rather a workaround is):

Index: yp_ping.c
===
RCS file: /usr/ncvs/src/usr.sbin/ypbind/yp_ping.c,v
retrieving revision 1.8
diff -u -r1.8 yp_ping.c
--- yp_ping.c   2001/03/19 12:50:12 1.8
+++ yp_ping.c   2001/03/20 13:46:24
@@ -93,6 +93,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "yp_ping.h"

@@ -126,7 +127,7 @@
 struct cu_data {
intcu_sock;
bool_t cu_closeit;
-   struct sockaddr_in cu_raddr;
+   struct sockaddr_storage cu_raddr;
intcu_rlen;
struct timeval cu_wait;
struct timeval cu_total;
@@ -136,6 +137,7 @@
u_int  cu_sendsz;
char   *cu_outbuf;
u_int  cu_recvsz;
+   struct pollfd   cu_pollfd;
char   cu_inbuf[1];
 };

Another problem which started at the day the RPC stuff was committed are
error messages of the form

yp_match: clnt_call: RPC: Program unavailable

spit out from various programs, among them pine, tcpdump, tcptrace.
How can I fix this (or at least find out, what's the problem)?

harti
-- 
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
  [EMAIL PROTECTED], [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

RE: Kernel compilation error.

[Dmitry Dicky]

On 23-Mar-01 Mark Sergeant wrote:
> pci0:  (vendor=0x8086, dev=0x7195) at 0.1 irq 5
> pci0:  (vendor=0x8086, dev=0x7196) at 0.2 irq 5
> 

Mark,
this is Intel 440 MX sound.

I sent the driver code to Cameron Grant a while ago. So, it should appear
in the CVS tree soon.

Dmitry.


*
   ("`-''-/").___..--''"`-._ (\   Dimmy the Wild  UA1ACZ
`6_ 6  )   `-.  ( ).`-.__.`)  Enterprise Information Sys 
(_Y_.)'  ._   )  `._ `. ``-..-'   Nevsky prospekt,   20 / 44
  _..`--'_..-_/  /--'_.' ,'   Saint Petersburg,   Russia
 (il),-''  (li),'  ((!.-' +7 (812) 3148860,  5585314
*

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Kernel compilation error.

[Mark Sergeant]

I am trying to compile into my custom kernel sound support for my css audio
chip. I have had no luck though using the suggested lint setting of...

device css0at isa? port 0x534 irq 5 drq 1 flags 0x08

And this fails when it gets to compiling the css options. If I remove this I
can compile fine.

 uname -a output is...

FreeBSD xyzzy.intranet.snsonline.net 4.3-RC FreeBSD 4.3-RC #19: Fri Mar 23
23:14:19 EST 2001

And the relevant (I think) dmesg listing for the sound device is...

pci0:  (vendor=0x8086, dev=0x7195) at 0.1 irq 5
pci0:  (vendor=0x8086, dev=0x7196) at 0.2 irq 5

I know this says pci but using pcm / csa doesn't work either. I am running this
on a sharp PC AX 20 notebook.

cheers,

Mark

-- 
The rule on staying alive as a forcaster is to give 'em a number or
give 'em a date, but never give 'em both at once.
-- Jane Bryant Quinn



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: tuning a VERY heavily (30.0) loaded s cerver

[Robert Watson]

On Fri, 23 Mar 2001, Alexey V. Neyman wrote:

> On Thu, 22 Mar 2001, Michael C . Wu wrote:
> 
> >(Why is vfs.vmiodirenable=1 not enabled by default?)
> By the way, is there any all-in-one-place description of sysctl tuneables?
> Looking all the man pages and collecting notices about MIB variables seems
> rather tiresome and, I think, pointless. I doubt if they are all
> documented in man pages.

sysctl(3) describes a number of the constant-named sysctl variables, and a
number of sysctl's are described in the man pages associated with the
features tweaked by the sysctl's.  For example, the jail(8) man page
describes the jail.* namespace.  However, you're right that there are vast
hoards of under-documented sysctl's.  That said, probably only the
"tweakable" (writable) sysctl's need to be documented in the general case,
since many are used for the sole purpose of exporting kernel data for
supported interfaces, whereas the sysctl's are subject to change.  For
example, a large number of read-only sysctl's were introduced to support
the non-setgid-kmem operation of top, systat, and various other *stat's
recently.  Also, many sysctl's are "self-documenting", in that the
declaration of the sysctl macros in-kernel include a description field.  I
don't think sysctl(8) currently knows how to read that field, but if you
look at the SYSCTL definitions in the kernel source, they're probably a
decent starting point.  A magic script to extract the sysctl names, types,
and descriptions might be useful..

Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED]  NAI Labs, Safeport Network Services



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Fingerprint authentication?

[David McNett]

On 23-Mar-2001, Michael Aronsen wrote:
> Has anyone been working on or know of any work being done on getting any
> fingerprint gadgets working in FreeBSD?

This is mostly off-topic, but I wanted to take the opportunity to point
out an excellent treatment of the downsides of biometrics (fingerprint
gadgets being the most popular such device these days) and concerns that
you should be aware of if you're considering adopting biometrics for
authentication in your environment.

Inside Risks 110, Communications of the ACM, vol 42, n 8, Aug 1999
"Biometrics: Uses and Abuses" by Bruce Schneier

http://www.counterpane.com/insiderisks1.html

-- 
 
|David McNett  |To ensure privacy and data integrity this message has|
|[EMAIL PROTECTED]|been encrypted using dual rounds of ROT-13 encryption|
|Austin, TX USA|Please encrypt all important correspondence with PGP!|

 PGP signature

Re: The "right" way to build a new world WAS: 4.3-BETA world crashin g 4.2-RELEASE kernel ?

[Peter Pentchev]

On Thu, Mar 22, 2001 at 06:01:16PM -0700, Matt Simerson wrote:
> OK, let's approach this from a little different angle:
> 
> Below is the appropriate entries from /usr/src/UPDATING on a FreeBSD
> 4-stable machine. As of 2/2/2001, the most correct and safest method for
> updating your FreeBSD machine is as follows:
> 
>cd /usr/src
>make buildworld
>make kernel KERNCONF=
>reboot (single user)
>make installworld
>mergemaster
>reboot
> 
> I have found that there IS a variety of reasons NOT to do it that way. The
> most obvious is that you might not have console access, thus making it
> pretty hard to access the machine while it's in single user mode. I can also
> think of a couple instances where this method could cause pain. 

OK, some of your reasons stated below are valid, some are not quite so;
in particular, the procedure you are following - running the buildworld
and buildkernel at the same time - is not only not-quite-right, but also
potentially dangerous - AFAIK, the buildkernel process uses compiler bits
from /usr/obj, which might get changed during the compile, leaving you with
largely incompatible object/executable files, and no error messages.

I understand your reason for wanting both to complete when you get back
to work; are you aware that make(1) can process more than one target
on the command line, and only build the second target if the first one
finishes successfully?  What I do is, usually at the end of the day:

mergemaster

# mergemaster is interactive, yes, but it doesn't
# take too much time ;)
# and it is sometimes SORELY needed if e.g. mtree files
# have changed, potentially breaking the subsequent builds

make buildworld buildkernel installkernel installworld
# (and I have a KERNCONF?=whatever in my /etc/make.conf)

..thus having the best of both worlds :)

G'luck,
Peter

-- 
This would easier understand fewer had omitted.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

NFS: "got bad cookie" error (again?)

[j . schripsema]

Hello,

Running bonnie++ on a NFS mounted files system doesn't work. Bonnie exits
with a fatal error caused by an attempt to remove a non-empty directory.
Bonnie tries to remove all files in a directory by calling 'readdir' an
'unlink' in a loop. This works fine on a local filesystem (UFS) but not on a
NFS mounted filesystem (also UFS on the server).

I'm running FreeBSD 4.2-RELEASE on both the nfs-server and nfs-client. I
have used several NFS configs (v2/v3).

I have seen references to this problem in old archives (1997, FBSD 2.2.5/6),
but it seems the problem has never been fixed. Is this correct? I even read
the manual :-( but could not find a solution.

Below you will find a small program that reveals the problem, including a
fix., which I do not like, because it requires a change in user programs.

Regards,

Jakob Schripsema
[EMAIL PROTECTED]

---


#include 
#include 
#include 
#include 


#define BASEDIR "/FS/testdir"   /* NFS mounted  */
#define NFILES  1024

main()
{
create_files();
delete_files();
}

create_files()
{
int i,fd;
char buf[2048];

for(i = 0 ; i < NFILES ; i++) {
snprintf(buf,2048,"%s/%04d",BASEDIR,i);
if ((fd = open(buf,O_CREAT | O_TRUNC | O_WRONLY, 0644)) < 0)
{
perror(buf);
return(-1);
}
close(fd);
}
}

delete_files()
{
DIR *dirp;
struct dirent *dp;
char buf[2048];

if ((dirp = opendir(BASEDIR)) == NULL) {
perror("opendir");
return (-1);
}
while ((dp = readdir(dirp)) != NULL) {
if (dp->d_name[0] == '.')
continue;
snprintf(buf,2048,"%s/%s",BASEDIR,dp->d_name);
fprintf(stderr,"%s\n",buf);
if (unlink(buf) < 0) {
perror(buf);
return (-1);
}
/* This fixes the problem */
rewinddir(dirp);
/* End fix */
}
}

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

toner supplies

[toner1]

PLEASE FORWARD TO THE PERSON
RESPONSIBLE FOR PURCHASING
YOUR LASER PRINTER SUPPLIES





 VORTEX  SUPPLIES 



-SPECIALS OF THE DAY ON LASER TONER SUPPLIES AT DISCOUNT PRICES--


 
LASER PRINTER TONER CARTRIDGES

COPIER AND FAX CARTRIDGES



WE ARE -->THE<-- PLACE TO BUY YOUR TONER CARTRIDGES BECAUSE YOU

SAVE UP TO 30% FROM OFFICE DEPOT'S, QUILL'S OR OFFICE MAX'S EVERY DAY

LOW PRICES



ORDER BY PHONE:1-888-288-9043

ORDER BY FAX: 1-888-977-1577

CUSTOMER SERVICE: 1-888-248-2015
E-MAIL REMOVAL LINE: 1-888-248-4930 



UNIVERSITY AND/OR SCHOOL PURCHASE ORDERS WELCOME. (NO CREDIT APPROVAL REQUIRED)

ALL OTHER PURCHASE ORDER REQUESTS REQUIRE CREDIT APPROVAL.



PAY BY CHECK (C.O.D), CREDIT CARD OR PURCHASE ORDER (NET 30 DAYS).





IF YOUR ORDER IS BY CREDIT CARD PLEASE LEAVE YOUR CREDIT CARD # PLUS EXPIRATION DATE. 

IF YOUR ORDER IS BY PURCHASE ORDER LEAVE YOUR SHIPPING/BILLING ADDRESSES AND YOUR P.O. 
NUMBER

NO SHIPPING CHARGES FOR ORDERS $49 OR OVER

ADD $4.75 FOR ORDERS UNDER $49.

C.O.D. ORDERS ADD $4.5 TO SHIPPING CHARGES.

FOR THOSE OF YOU WHO REQUIRE MORE INFORMATION ABOUT OUR COMPANY
INCUDING FEDERAL TAX ID NUMBER, CLOSEST SHIPPING OR CORPORATE ADDRESS IN THE
CONTINENTAL U.S.  OR  FOR CATALOG  REQUESTS PLEASE CALL OUR CUSTOMER
SERVICE LINE  1-888-248-2015 
 


OUR NEW , LASER PRINTER TONER CARTRIDGE, PRICES ARE  AS FOLLOWS: 



(PLEASE ORDER BY PAGE NUMBER AND/OR ITEM NUMBER)

 

HEWLETT PACKARD: (ON PAGE 2)

   

ITEM #1  LASERJET SERIES  4L,4P (74A)$44

ITEM #2  LASERJET SERIES  1100 (92A)-$44

ITEM #3  LASERJET SERIES  2 (95A)---$39

ITEM #4  LASERJET SERIES  2P (75A)-$54 

ITEM #5  LASERJET SERIES  5P,6P,5MP, 6MP (3903A)--$44

ITEM #6  LASERJET SERIES  5SI, 5000 (29A)--$95

ITEM #7  LASERJET SERIES  2100 (96A)-$74

ITEM #8  LASERJET SERIES  8100 (82X)---$145

ITEM #9  LASERJET SERIES  5L/6L (3906A0--$35

ITEM #10 LASERJET SERIES  4V-$95

ITEM #11 LASERJET SERIES 4000 (27X)-$72

ITEM #12 LASERJET SERIES 3SI/4SI (91A)$54

ITEM #13 LASERJET SERIES 4, 4M, 5,5M---$49



HEWLETT PACKARD FAX (ON PAGE 2)



ITEM #14 LASERFAX 500, 700 (FX1)--$49

ITEM #15  LASERFAX 5000,7000 (FX2)--$54

ITEM #16  LASERFAX (FX3)$59

ITEM #17  LASERFAX (FX4)$54



LEXMARK/IBM (ON PAGE 3)



OPTRA 4019, 4029 HIGH YIELD---$89

OPTRA R, 4039, 4049 HIGH YIELD-$105

OPTRA E$59

OPTRA N--$115

OPTRA S--$165

-

EPSON (ON PAGE 4)



ACTION LASER 7000,7500,8000,9000---$105

ACTION LASER 1000,1500-$105



CANON PRINTERS (ON PAGE 5)



 PLEASE CALL FOR MODELS AND UPDATED PRICES

 FOR CANON PRINTER CARTRIDGES



PANASONIC (0N PAGE 7)



NEC SERIES 2 MODELS 90 AND 95--$105



APPLE (0N PAGE 8)



LASER WRITER PRO 600 or 16/600$49 

LASER WRITER SELECT 300,320,360-$74

LASER WRITER 300 AND 320--$54

LASER WRITER NT, 2NT--$54

LASER WRITER 12/640$79







CANON FAX (ON PAGE 9)



LASERCLASS 4000 (FX3)---$59

LASERCLASS 5000,6000,7000 (FX2)-$54

LASERFAX 5000,7000 (FX2)--$54

LASERFAX 8500,9000 (FX4)--$54





CANON COPIERS (PAGE 10)



PC 3, 6RE, 7 AND 11 (A30)-$69

PC 300,320,700,720 and 760 (E-40)$89



IF YOUR CARTRIDGE IS NOT LISTED CALL CUSTOMER SERVICE AT 1-888-248-2015 



90 DAY UNLIMITED WARRANTY INCLUDED ON ALL PRODUCTS.



ALL TRADEMARKS AND BRAND NAMES LISTED ABOVE ARE PROPERTY OF THE 

RESPECTIVE HOLDERS AND USED FOR DESCRIPTIVE PURPOSES ONLY.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

toner supplies

[toner1]

PLEASE FORWARD TO THE PERSON
RESPONSIBLE FOR PURCHASING
YOUR LASER PRINTER SUPPLIES





 VORTEX  SUPPLIES 



-SPECIALS OF THE DAY ON LASER TONER SUPPLIES AT DISCOUNT PRICES--


 
LASER PRINTER TONER CARTRIDGES

COPIER AND FAX CARTRIDGES



WE ARE -->THE<-- PLACE TO BUY YOUR TONER CARTRIDGES BECAUSE YOU

SAVE UP TO 30% FROM OFFICE DEPOT'S, QUILL'S OR OFFICE MAX'S EVERY DAY

LOW PRICES



ORDER BY PHONE:1-888-288-9043

ORDER BY FAX: 1-888-977-1577

CUSTOMER SERVICE: 1-888-248-2015
E-MAIL REMOVAL LINE: 1-888-248-4930 



UNIVERSITY AND/OR SCHOOL PURCHASE ORDERS WELCOME. (NO CREDIT APPROVAL REQUIRED)

ALL OTHER PURCHASE ORDER REQUESTS REQUIRE CREDIT APPROVAL.



PAY BY CHECK (C.O.D), CREDIT CARD OR PURCHASE ORDER (NET 30 DAYS).





IF YOUR ORDER IS BY CREDIT CARD PLEASE LEAVE YOUR CREDIT CARD # PLUS EXPIRATION DATE. 

IF YOUR ORDER IS BY PURCHASE ORDER LEAVE YOUR SHIPPING/BILLING ADDRESSES AND YOUR P.O. 
NUMBER

NO SHIPPING CHARGES FOR ORDERS $49 OR OVER

ADD $4.75 FOR ORDERS UNDER $49.

C.O.D. ORDERS ADD $4.5 TO SHIPPING CHARGES.

FOR THOSE OF YOU WHO REQUIRE MORE INFORMATION ABOUT OUR COMPANY
INCUDING FEDERAL TAX ID NUMBER, CLOSEST SHIPPING OR CORPORATE ADDRESS IN THE
CONTINENTAL U.S.  OR  FOR CATALOG  REQUESTS PLEASE CALL OUR CUSTOMER
SERVICE LINE  1-888-248-2015 
 


OUR NEW , LASER PRINTER TONER CARTRIDGE, PRICES ARE  AS FOLLOWS: 



(PLEASE ORDER BY PAGE NUMBER AND/OR ITEM NUMBER)

 

HEWLETT PACKARD: (ON PAGE 2)

   

ITEM #1  LASERJET SERIES  4L,4P (74A)$44

ITEM #2  LASERJET SERIES  1100 (92A)-$44

ITEM #3  LASERJET SERIES  2 (95A)---$39

ITEM #4  LASERJET SERIES  2P (75A)-$54 

ITEM #5  LASERJET SERIES  5P,6P,5MP, 6MP (3903A)--$44

ITEM #6  LASERJET SERIES  5SI, 5000 (29A)--$95

ITEM #7  LASERJET SERIES  2100 (96A)-$74

ITEM #8  LASERJET SERIES  8100 (82X)---$145

ITEM #9  LASERJET SERIES  5L/6L (3906A0--$35

ITEM #10 LASERJET SERIES  4V-$95

ITEM #11 LASERJET SERIES 4000 (27X)-$72

ITEM #12 LASERJET SERIES 3SI/4SI (91A)$54

ITEM #13 LASERJET SERIES 4, 4M, 5,5M---$49



HEWLETT PACKARD FAX (ON PAGE 2)



ITEM #14 LASERFAX 500, 700 (FX1)--$49

ITEM #15  LASERFAX 5000,7000 (FX2)--$54

ITEM #16  LASERFAX (FX3)$59

ITEM #17  LASERFAX (FX4)$54



LEXMARK/IBM (ON PAGE 3)



OPTRA 4019, 4029 HIGH YIELD---$89

OPTRA R, 4039, 4049 HIGH YIELD-$105

OPTRA E$59

OPTRA N--$115

OPTRA S--$165

-

EPSON (ON PAGE 4)



ACTION LASER 7000,7500,8000,9000---$105

ACTION LASER 1000,1500-$105



CANON PRINTERS (ON PAGE 5)



 PLEASE CALL FOR MODELS AND UPDATED PRICES

 FOR CANON PRINTER CARTRIDGES



PANASONIC (0N PAGE 7)



NEC SERIES 2 MODELS 90 AND 95--$105



APPLE (0N PAGE 8)



LASER WRITER PRO 600 or 16/600$49 

LASER WRITER SELECT 300,320,360-$74

LASER WRITER 300 AND 320--$54

LASER WRITER NT, 2NT--$54

LASER WRITER 12/640$79







CANON FAX (ON PAGE 9)



LASERCLASS 4000 (FX3)---$59

LASERCLASS 5000,6000,7000 (FX2)-$54

LASERFAX 5000,7000 (FX2)--$54

LASERFAX 8500,9000 (FX4)--$54





CANON COPIERS (PAGE 10)



PC 3, 6RE, 7 AND 11 (A30)-$69

PC 300,320,700,720 and 760 (E-40)$89



IF YOUR CARTRIDGE IS NOT LISTED CALL CUSTOMER SERVICE AT 1-888-248-2015 



90 DAY UNLIMITED WARRANTY INCLUDED ON ALL PRODUCTS.



ALL TRADEMARKS AND BRAND NAMES LISTED ABOVE ARE PROPERTY OF THE 

RESPECTIVE HOLDERS AND USED FOR DESCRIPTIVE PURPOSES ONLY.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Fingerprint authentication?

[Michael Aronsen]

Hello,

Dont quite know where to throw this question but i thought maybe
[EMAIL PROTECTED] might be the right place.

Has anyone been working on or know of any work being done on getting any
fingerprint gadgets working in FreeBSD?

Michael Aronsen

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message