Re: irq

[Danny Braniss]

> In message <[EMAIL PROTECTED]> Danny Braniss writes:
> : Q: are all interrupt handlers for the shared irq called, or only the
> :'correct' one?
> 
> You can't tell which card really interrupted.  All of them are called.
> 
> Warner

let me see if i can summarise:
1- irq are shared by definition.
2- all drivers at/in the same irq are called.
3- it's the driver's responsability to do the 'right thing' or in 
   simpler terms, not to screw things up.

I fixed the meteor, so that on interrupt checks if there is anything to do, and
if not just returns, btw, on interrups time very little is done.

my testing was done so:
  host A ran an X application that does the video grabbing.
- with local display, all ok.
- with display on host B, via fast ethernet,
the adaptec complained.
the meteor complained.
after some card shuffling:
the adaptec is ok.
the meteor hardly complains - IMHO it should not, but it's
very low count < .01%.
btw, host A is Pentium III/450MHz. Dell GX1, with 128M memory.

ah, and thanks to all for explaining the darker sides of irq.

danny





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

Re: [SUGGESTION] - JFS for FreeBSD [VOTE]

[Hiten Pandya]

Hi,

as i said also before, my intentions were never to 
cause havoc on the mailing list. :-)

In simple terms, what i am saying is, the people who
would like to port the JFS file system, should put a 
+1 in their next message and -1 if they dont like to
port JFS.

Then, i will count the votes, and if +1 outweighs -1,
then i will try to gether developers who can help me
in this task, and try to finish it by Sept. 2002.

BUT, if -1 outweighs +1, then i will cancel the
project
and live it for my spare time, and will not go around
asking everyone about it...

OR, another way of doing this would be to, just try
and get this JFS porting done by people who would like
to do it (including me), and then put it on the 
FreeBSD site.

AND, then we will see which company/corporate would
like to use the GPL version of a FreeBSD FileSystem.

Suppose, if there are very less, we abandon the
project
and forget about it.

In that way, there would be no hassle. Only people who
would like to port this File System should put a +1
in their next reply or -1 if they do not agree with
porting JFS.

Thanks.
=Hiten
=<[EMAIL PROTECTED]>


=
-Hiten,

Thank You,
Yours Sincerely,
Hiten Pandya,
<[EMAIL PROTECTED]>


__
Do You Yahoo!?
Check out Yahoo! Shopping and Yahoo! Auctions for all of
your unique holiday gifts! Buy at http://shopping.yahoo.com
or bid at http://auctions.yahoo.com

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

Re: irq

[Terry Lambert]

Warner Losh wrote:
> In message <[EMAIL PROTECTED]> Terry Lambert writes:
> : Some cards do not have a hardware "I caused an interrupt" register,
> : and use a differential (e.g. ring head vs. tail inequal after
> : interrupt) to tell if there is work to do.  If these cards were to
> : share interrupts, then they most likely do work every interrupt,
> : and less work per interrupt, then would otherwise be the case (i.e.
> : it would defeat hardware interrupt coelescing thresholds, among
> : other things).
> 
> No such PCI cards can exists.  The PCI spec requires that interrupt
> sharing work.

???

How is setting a local register when an interrupt is triggered
antithetical to such cards working?  I know of several network
cards where I've personally hacked on the driver that have such
a register.

It's not possbile to take a shared interrupt and not run the ISR,
but it's possible for the ISR to check the register and decide on
that basis, rather than on data availability, that it will or will
not do work.

I think that everyone now "gets" that PCI interrupts are like
signals, in that they are persistant conditions, so more than one
card asserting them doesn't change the fact that "an interrupt"
was asserted, and there's no way to tell _from the interrupt_
which cards did or did not assert it in the first place.  But we
are talking about an extra hardware register on the card that the
card sets when it asserts an interrupt, so an ISR can look to ask
the card "did you assert an interrupt?" and decide not to process
if the answer is "no".

The Tigon II interrupt sharing in fact depends on this, or when
you had two Tigon II cards, you migh spend the rest of eternity in
the ISR.

-- Terry

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

Re: irq

[Bernd Walter]

On Wed, Dec 12, 2001 at 03:02:19AM -0800, Terry Lambert wrote:
> How is setting a local register when an interrupt is triggered
> antithetical to such cards working?  I know of several network
> cards where I've personally hacked on the driver that have such
> a register.
> 
> It's not possbile to take a shared interrupt and not run the ISR,
> but it's possible for the ISR to check the register and decide on
> that basis, rather than on data availability, that it will or will
> not do work.
> 
> I think that everyone now "gets" that PCI interrupts are like
> signals, in that they are persistant conditions, so more than one
> card asserting them doesn't change the fact that "an interrupt"
> was asserted, and there's no way to tell _from the interrupt_
> which cards did or did not assert it in the first place.  But we
> are talking about an extra hardware register on the card that the
> card sets when it asserts an interrupt, so an ISR can look to ask
> the card "did you assert an interrupt?" and decide not to process
> if the answer is "no".
> 
> The Tigon II interrupt sharing in fact depends on this, or when
> you had two Tigon II cards, you migh spend the rest of eternity in
> the ISR.

I never understood why the PCI-bus is not a interupt vector design.

-- 
B.Walter  COSMO-Project http://www.cosmo-project.de
[EMAIL PROTECTED] Usergroup   [EMAIL PROTECTED]


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

Re: irq

[Danny Braniss]

> I never understood why the PCI-bus is not a interupt vector design.
> 
probably because it was DEC's idea ...

danny



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

Re: irq

[Wilko Bulte]

On Wed, Dec 12, 2001 at 04:28:25PM +0200, Danny Braniss wrote:
> 
> > I never understood why the PCI-bus is not a interupt vector design.
> > 
> probably because it was DEC's idea ...

I thought it was Intel's idea?

-- 
|   / o / /_  _ email:  [EMAIL PROTECTED]
|/|/ / / /(  (_)  Bulte Arnhem, The Netherlands 

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

NFS: How to make FreeBSD fall on its face in one easy step

[Jordan Hubbard]

It came up in a meeting today at Apple just how fragile the BSD NFS
implementation was before significant work was put in to stabilizing it,
and in that discussion came up a little test tool written originally by
Avie Tevanian and subsequently improved by one of the folks here.

This tool basically tries to do everything it can (legally) to confuse an
NFS server.  It seeks around, does I/O to and truncates/changes the size
of a test file, all while doing everything it can to detect data corruption
or other signs of misbehavior which might result from out-of-order replies
or any other previously-observed NFS pathology.  Very few NFS implementations
apparently survive this test and FreeBSD's is no exception.  The sources are
provided below, courtesy of Avie, for the education and enjoyment(?) of
anyone who's motivated to play with (or even pretends to understand) NFS.

Usage:
cc fsx.c -o fsx
./fsx /some/nfs/mounted/scratchfile
[ ** kaboom! ** ]

I'm also trying to determine which of the fixes Apple has made to NFS might
be adapted to FreeBSD, something which is made more difficult by the fact
that much of the code was taken straight from 4.4 Lite some time back and
both operating systems have diverged significantly since then.  Anyone
really keen on investigating this further themselves on it can also go to
http://www.opensource.apple.com/projects/darwin and register themselves
online (it's easy) to access the Darwin CVS repository, the module in
question being "xnu" (the Darwin kernel).  Thanks.

- Jordan

/*
 *  Copyright (C) 1991, NeXT Computer, Inc.  All Rights Reserverd.
 *
 *  File:   fsx.c
 *  Author: Avadis Tevanian, Jr.
 *
 *  File system exerciser. 
 *
 *  Rewritten 8/98 by Conrad Minshall.
 */

#include 
#include 
#ifdef _UWIN
# include 
# include 
# include 
# include 
# define MAP_FILE 0
#else
# include 
#endif
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#define NUMPRINTCOLUMNS 32  /* # columns of data to print on each line */

/*
 *  A log entry is an operation and a bunch of arguments.
 */

struct log_entry {
int operation;
int args[3];
};

#define LOGSIZE 1000

struct log_entryoplog[LOGSIZE]; /* the log */
int logptr = 0; /* current position in log */
int logcount = 0;   /* total ops */

/*
 *  Define operations
 */

#define OP_READ 1
#define OP_WRITE2
#define OP_TRUNCATE 3
#define OP_CLOSEOPEN4
#define OP_MAPREAD  5
#define OP_MAPWRITE 6
#define OP_SKIPPED  7

#ifndef PAGE_SIZE
#define PAGE_SIZE   4096
#endif
#define PAGE_MASK   (PAGE_SIZE - 1)

char*original_buf;  /* a pointer to the original data */
char*good_buf;  /* a pointer to the correct data */
char*temp_buf;  /* a pointer to the current data */
char*fname; /* name of our test file */
int fd; /* fd for our test file */

off_t   file_size = 0;
off_t   biggest = 0;
charstate[256];
unsigned long   testcalls = 0;  /* calls to function "test" */

unsigned long   simulatedopcount = 0;   /* -b flag */
int closeprob = 0;  /* -c flag */
int debug = 0;  /* -d flag */
unsigned long   debugstart = 0; /* -D flag */
unsigned long   maxfilelen = 256 * 1024;/* -l flag */
int sizechecks = 1; /* -n flag disables them */
int maxoplen = 64 * 1024;   /* -o flag */
int quiet = 0;  /* -q flag */
unsigned long progressinterval = 0; /* -p flag */
int readbdy = 1;/* -r flag */
int style = 0;  /* -s flag */
int truncbdy = 1;   /* -t flag */
int writebdy = 1;   /* -w flag */
longmonitorstart = -1;  /* -m flag */
longmonitorend = -1;/* -m flag */
int lite = 0;   /* -L flag */
longnumops = -1;/* -N flag */
int randomoplen = 1;/* -O flag disables it */
int seed = 1;   /* -S flag */
int mapped_writes = 1;  /* -W flag disables */
int mapped_reads = 1;   /* -R flag disables it */
int fsxgoodfd = 0;
FILE *  fsxlogf = NULL;
int badoff = -1;
int closeopen = 0;


void
prt(char *fmt, ...)
{
va_list args;

va_start(args, fmt);
vfprintf(stdout, fmt, args);
if (fsxlogf)
vfprintf(fsxlogf, fmt, args);
va_end(args);
}

void
prterr(char *prefix)
{
prt("%s%s%s\n", prefix, prefix ? ": " : "", strerror(errno));
}


void
log4(int operation, int arg0, int arg1, int arg2)
{
struct log_entry *le;

le = &oplog[logptr];
le->operation = 

closeing files in detach()

[Brad Huntting]

There's a mention in the FBSD hacking guide that a detach() routine
for a device driver can forcably close all open descriptors for
its device before it unloads.

How does one do this?


brad

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

Re: irq

[Mike Smith]

> I never understood why the PCI-bus is not a interupt vector design.

The way the story goes, it wasn't until the last minute that the initial 
PCI working group realised that they'd forgotten to do something about 
interrupts, and so the gross hack that we're now stuck with was 
implemented.

It might be more realistic to say that PCI tries to discourage the use of 
interrupts, and hardware vendors haven't really gotten the message.

You should look at recent PCI revisions, however, and the MSI 
(message-signalled interrupt) mechanism which, if implemented widely, 
will solve at least some of the major problems with PCI and interrupts.
-- 
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also.  But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view.  [Dr. Fritz Todt]
   V I C T O R Y   N O T   V E N G E A N C E



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

Re: irq

[Warner Losh]

In message <[EMAIL PROTECTED]> Terry Lambert writes:
: How is setting a local register when an interrupt is triggered
: antithetical to such cards working?  I know of several network
: cards where I've personally hacked on the driver that have such
: a register.

...

I was tired and confused when I read your message.  I thought you were
describing the lance chips.  Re-reading it now that I'm less tired
shows I was in error.

Warner

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

Re: irq

[Terry Lambert]

Warner Losh wrote:
> I was tired and confused when I read your message.  I thought you were
> describing the lance chips.

No problem... I've fallen victim to that same thing myself.  As
I'm sure people will attest at great volume... 8^).

-- Terry

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

Re: irq

[Terry Lambert]

Mike Smith wrote:
> It might be more realistic to say that PCI tries to discourage the use of
> interrupts, and hardware vendors haven't really gotten the message.

8^).  That's because there is no more important task for your CPU
to do than to poll devices to see if they need to do I/O; what the
heck are these "program" things, anyway, and what exactly is their
relevence to electrical engineering, again?


> You should look at recent PCI revisions, however, and the MSI
> (message-signalled interrupt) mechanism which, if implemented widely,
> will solve at least some of the major problems with PCI and interrupts.

Thanks for the pointer; I haven't been following PCI standards
recently, except for speed and size extensions.  It looks like
it's time to look at them yet again.  Do you know if this is going
to be mandatory for PCI-X devices?  I don't think it will be very
widely used until it's required.  8^(.

-- Terry

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

help with loadable module & PicoBSD

[Chuck T.]

I'm trying to write an ISA device driver from scratch and I'm also trying to 
make it a kernel loadable to make my debugging life easier. I started with 
/usr/share/examples/kld/cdev and have modified it by adding the following:

static int
xxx_isa_probe(device_t dev)
{
int ret = ENXIO;

device_printf(dev,"xxx_isa_probe() called.\n");

if(device_get_unit(dev) == 0) {
ret = 0;
}
return ret;
}

static int
xxx_isa_attach(device_t dev)
{
device_printf(dev,"xxx_isa_attach() called.\n");
return 0;
}

static int
xxx_isa_detach(device_t dev)
{
device_printf(dev,"xxx_isa_detach() called.\n");
return 0;
}

static struct isa_pnp_id xxx_ids[] = {
{ 0,NULL }
};

static device_method_t xxx_isa_methods[] = {
/* Device interface */
DEVMETHOD(device_probe, xxx_isa_probe),
DEVMETHOD(device_attach,xxx_isa_attach),
DEVMETHOD(device_detach,xxx_isa_detach),

{ 0, 0 }
};

static driver_t xxx_isa_driver = {
driver_name,
xxx_isa_methods,
0
};

static  devclass_t  xxx_devclass;

/* Declare the module to the system */
DRIVER_MODULE(xxx, isa, xxx_isa_driver, xxx_devclass, cdev_load, 0);

When I load the skeletion on my development machine (FreeBSD 4.4) both 
cdev_load() and xxx_isa_probe() are called as expected.  However when I load 
the same binary on my PicoBSD target it only cdev_load() is called, *NOT* 
xxx_isa_probe().  My PicoBSD is built from the same sources as my 
development machine and both are FreeBSD 4.4-release.  Both include the isa 
bus in their configuration files. I'm sure I'm doing something wrong as I 
have been able to load stock Ethernet driver kernel modules on Pico before.

Any suggestions ?  I'm lost.  I tried removing the stripping step in the 
PicoBSD build thinking that was on obvious difference between a Pico build 
and a full build, but that didn't help.

_
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx


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

Re: NFS: How to make FreeBSD fall on its face in one easy step

[Matthew Dillon]

Oooh.  Very cool!  I'll start messing with it (oops, that's going to
make both Paul and Alfred annoyed with me!)

-Matt

:It came up in a meeting today at Apple just how fragile the BSD NFS
:implementation was before significant work was put in to stabilizing it,
:and in that discussion came up a little test tool written originally by
:Avie Tevanian and subsequently improved by one of the folks here.
:
:This tool basically tries to do everything it can (legally) to confuse an
:NFS server.  It seeks around, does I/O to and truncates/changes the size
:of a test file, all while doing everything it can to detect data corruption
:or other signs of misbehavior which might result from out-of-order replies
:or any other previously-observed NFS pathology.  Very few NFS implementations
:apparently survive this test and FreeBSD's is no exception.  The sources are
:provided below, courtesy of Avie, for the education and enjoyment(?) of
:anyone who's motivated to play with (or even pretends to understand) NFS.
:
:Usage:
:   cc fsx.c -o fsx
:   ./fsx /some/nfs/mounted/scratchfile
:   [ ** kaboom! ** ]
:
:I'm also trying to determine which of the fixes Apple has made to NFS might
:be adapted to FreeBSD, something which is made more difficult by the fact
:that much of the code was taken straight from 4.4 Lite some time back and
:both operating systems have diverged significantly since then.  Anyone
:really keen on investigating this further themselves on it can also go to
:http://www.opensource.apple.com/projects/darwin and register themselves
:online (it's easy) to access the Darwin CVS repository, the module in
:question being "xnu" (the Darwin kernel).  Thanks.
:
:- Jordan
:
:...

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

Re: NFS: How to make FreeBSD fall on its face in one easy step

[Warner Losh]

In message <[EMAIL PROTECTED]> Matthew Dillon writes:
: Oooh.  Very cool!  I'll start messing with it (oops, that's going to
: make both Paul and Alfred annoyed with me!)

Well, I can understand you not wanting to upset Paul, but anything
that annoys Alfred can't be all bad, can it :-)

Warner

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

Linus Torvalds it is a lucky thing that I am able to reach you!

[Miss Cleo]

Title: SENSITIVE MESSAGE




   

 
Linus Torvalds, 
  this message is time sensitive. Contact us immediately!
  
   
 
  

 
  We 
know more about
you than you may think!

  
   
 
  
  Linus Torvalds, 
this notice is for your eyes only. Please do not share its contents or 
the reserved phone number…
  
  Linus Torvalds, I have 
a message for you that could have a long-lasting effect on your future. 
Hearing this information will assist you in ways you can’t conceive 
of right now.
  I repeat: this is 
time sensitive. If you’re wondering about your future love life, 
money or your career, call this reserved number at once! Call toll-free, 
1-800-487-1965.
  An important date 
is imminent. You must have the news before this date. You may have very 
little time left, Linus Torvalds.
  Call this FREE number 
immediately: 1-800-487-1965.. Call 24 hours a day, 7 days a week.
  This vital message 
is so important that I’ve reserved this special number for you to 
speak person-to-person with a friend of mine- a gifted Master Psychic! 
Now, you will learn everything you need to know!
  Linus Torvalds, I try 
very hard to help those that need it. And the spirits they come to me, 
you know. They give me messages and secrets about clients and people I’ve 
never even met before… 
  Here 
is what you now need to do right now, Linus Torvalds:
  

  
   
 
  Call 
this reserved number: 
1-800-487-1965.
When you call, give these access
codes we’ve set up for you:
  ID 
# 072 
 PIN # 
55732


  
   
 
  This is a FREE call. 
Linus Torvalds, please don’t hesitate to find out what your future has 
in store for you! Your life is about to change! 
   Make 
a FREE call to 1-800-819-3984 to hear about other special reading offers.

Si usted prefiere su lectura en español, llámenos al 800-543-4051. 
Esta llamada es gratis. 
   
Must be 18+. For entertainment 
purposes only.

  

If you wish to unsubscribe from further emailings, please 
Click Here. 





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

Re: NFS: How to make FreeBSD fall on its face in one easy step

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Jordan Hubbard writ
es:

>Usage:
>   cc fsx.c -o fsx
>   ./fsx /some/nfs/mounted/scratchfile
>   [ ** kaboom! ** ]

The only thing I get is a math exception because "closeprob" is zero
since no -c option was given.

Can you provide some sample parameters please ?

-- 
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: sscanf(..., "%lld", ...) broken?

[Dan Peterson]

Jos Backus <[EMAIL PROTECTED]> wrote:
> Is this PR-worthy? I am seeing this in both -stable and -current. The lftp
> author claims it's our bug, not his.
> 
> > It seems to me that sscanf on FreeBSD does not correctly handle long
> > long type (%lld). There is another similar report, the reporter says
> > that initializing the variable to 0 before sscanf helps. This indicates
> > a bug in the libc library. You can report a bug to FreeBSD team.

I was the other reporter, and initializing the size_ll variable to 0 does
fix it for me (be sure to do it in both the FTP listing code and the FTP
mirroring code, though). Alexander provided this code to verify that it's a
libc problem (it exits 1 for me under -STABLE):

int main()
{
   unsigned long long x=0,x1;
   long long y=0,y1;
   char buf[128];

   x=~x;
   sscanf("0","%llu",&x);
   if(x!=0) return 1;

   y=~y;
   sscanf("0","%lld",&y);
   if(y!=0) return 1;

   x=~x;
   sprintf(buf,"%lld %llu",y,x);
   sscanf (buf,"%lld %llu",&y1,&x1);
   if(x!=x1 || y!=y1)
  return 1;

   return 0;
}

EPLF listing works fine in lftp-2.4.4 and before without patching which
baffles me (the lftp code still uses sscanf).

-- 
Dan Peterson <[EMAIL PROTECTED]> http://danp.net

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

Re: NFS: How to make FreeBSD fall on its face in one easy step

[Jordan Hubbard]

> The only thing I get is a math exception because "closeprob" is zero
> since no -c option was given.
> 
> Can you provide some sample parameters please ?

Hmmm, how strange, now that I look at the code it's obvious that a
divide by zero will occur with a zero closeprob and the docs state the
default to be "infinity", which is obviously not the case.  The
strange part is that I ran this on freebsd.apple.com, which is running
4.4-stable, with one parameter (the filename) exactly as I pasted in
the usage instructions before.  Perhaps all this time spent living
next to the Macintosh in my office has induced that copy of FreeBSD to
be more "friendly" and mask simple math errors. :-)

In any case, -c 1 appears to work just fine.

- Jordan

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

Re: help with loadable module & PicoBSD

[Julian Elischer]

also look at (in current
only!) /usr/share/examples/drivers/make_device_driver.sh

is makes a driver with ISA, and PCI-based interfaces.


On Wed, 12 Dec 2001, Chuck T. wrote:

> I'm trying to write an ISA device driver from scratch and I'm also trying to 
> make it a kernel loadable to make my debugging life easier. I started with 
> /usr/share/examples/kld/cdev and have modified it by adding the following:
> 
> static int
> xxx_isa_probe(device_t dev)
> {
>   int ret = ENXIO;
> 
>   device_printf(dev,"xxx_isa_probe() called.\n");
> 
>   if(device_get_unit(dev) == 0) {
>   ret = 0;
>   }
>   return ret;
> }
> 
> static int
> xxx_isa_attach(device_t dev)
> {
>   device_printf(dev,"xxx_isa_attach() called.\n");
>   return 0;
> }
> 
> static int
> xxx_isa_detach(device_t dev)
> {
>   device_printf(dev,"xxx_isa_detach() called.\n");
>   return 0;
> }
> 
> static struct isa_pnp_id xxx_ids[] = {
>   { 0,NULL }
> };
> 
> static device_method_t xxx_isa_methods[] = {
>   /* Device interface */
>   DEVMETHOD(device_probe, xxx_isa_probe),
>   DEVMETHOD(device_attach,xxx_isa_attach),
>   DEVMETHOD(device_detach,xxx_isa_detach),
> 
>   { 0, 0 }
> };
> 
> static driver_t xxx_isa_driver = {
>   driver_name,
>   xxx_isa_methods,
>   0
> };
> 
> staticdevclass_t  xxx_devclass;
> 
> /* Declare the module to the system */
> DRIVER_MODULE(xxx, isa, xxx_isa_driver, xxx_devclass, cdev_load, 0);
> 
> When I load the skeletion on my development machine (FreeBSD 4.4) both 
> cdev_load() and xxx_isa_probe() are called as expected.  However when I load 
> the same binary on my PicoBSD target it only cdev_load() is called, *NOT* 
> xxx_isa_probe().  My PicoBSD is built from the same sources as my 
> development machine and both are FreeBSD 4.4-release.  Both include the isa 
> bus in their configuration files. I'm sure I'm doing something wrong as I 
> have been able to load stock Ethernet driver kernel modules on Pico before.
> 
> Any suggestions ?  I'm lost.  I tried removing the stripping step in the 
> PicoBSD build thinking that was on obvious difference between a Pico build 
> and a full build, but that didn't help.
> 
> _
> MSN Photos is the easiest way to share and print your photos: 
> http://photos.msn.com/support/worldwide.aspx
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 


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

Re: irq

[Mike Smith]

> 
> > You should look at recent PCI revisions, however, and the MSI
> > (message-signalled interrupt) mechanism which, if implemented widely,
> > will solve at least some of the major problems with PCI and interrupts.
> 
> Thanks for the pointer; I haven't been following PCI standards
> recently, except for speed and size extensions.  It looks like
> it's time to look at them yet again.  Do you know if this is going
> to be mandatory for PCI-X devices?  I don't think it will be very
> widely used until it's required.  8^(.

MSI isn't mandatory; it requires host chipset support.  I've read several
new peripherals claiming to support it, but haven't been looking at host
chipsets to see if it's been picked up there.


What would be *really* nice would be a 'shadow' MSI implementation where 
the host chipset would emulate MSI for non-MSI peripherals.


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

Re: NFS: How to make FreeBSD fall on its face in one easy step

[Mike Smith]

I should point out that FSX can be used against any filesystem, and
that there are reports locally (at Apple) that it's great for killing
FreeBSD machines.  I wasn't able to reproduce this when I tried, but I
may not have let it run long enough.

> Oooh.  Very cool!  I'll start messing with it (oops, that's going to
> make both Paul and Alfred annoyed with me!)

8)

> :I'm also trying to determine which of the fixes Apple has made to NFS might
> :be adapted to FreeBSD, something which is made more difficult by the fact
> :that much of the code was taken straight from 4.4 Lite some time back and
> :both operating systems have diverged significantly since then.

Many of the key issues in making OS X NFS work were related to its
interaction with the UBC and the subtly different VFS semantics,
although the same issues probably exist in different form in the
FreeBSD code.  I get dragged into some really shocking corridor
discussions every now and then. 8)

 = Mike


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

Re: NFS: How to make FreeBSD fall on its face in one easy step

[Matthew Dillon]

:
:
:I should point out that FSX can be used against any filesystem, and
:that there are reports locally (at Apple) that it's great for killing
:FreeBSD machines.  I wasn't able to reproduce this when I tried, but I
:may not have let it run long enough.

Well, I already found and tracked down a softupdates bug revealed
by this code... definite server panic, especially if an NFSv2 mount
is used.

I shot some mail off to Kirk with a proposed fix for that.

With both NFSv2 and NFSv3 I get user-process bus errors with the 
truncate()/mmap() combinations being used.  I'm tracking that down
now.

-Matt


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

Re: NFS: How to make FreeBSD fall on its face in one easy step

[Jordan Hubbard]

> I should point out that FSX can be used against any filesystem, and
> that there are reports locally (at Apple) that it's great for killing
> FreeBSD machines.  I wasn't able to reproduce this when I tried, but I
> may not have let it run long enough.

Oh, it blows freebsd.apple.com right out of the water with a kernel
panic after running for just 3 seconds from an OS X box on the same
LAN segment. :)

- Jordan

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

Re: NFS: How to make FreeBSD fall on its face in one easy step

[Matthew Dillon]

:
:> I should point out that FSX can be used against any filesystem, and
:> that there are reports locally (at Apple) that it's great for killing
:> FreeBSD machines.  I wasn't able to reproduce this when I tried, but I
:> may not have let it run long enough.
:
:Oh, it blows freebsd.apple.com right out of the water with a kernel
:panic after running for just 3 seconds from an OS X box on the same
:LAN segment. :)
:
:- Jordan

What panic are you getting?

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>

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

Re: [SUGGESTION] - JFS for FreeBSD [VOTE]

[Greg Lehey]

On Wednesday, 12 December 2001 at  1:43:10 -0800, Hiten Pandya wrote:
> Hi,
>
> as i said also before, my intentions were never to cause havoc on
> the mailing list. :-)
>
> In simple terms, what i am saying is, the people who would like to
> port the JFS file system, should put a +1 in their next message and
> -1 if they dont like to port JFS.
>
> Then, i will count the votes, and if +1 outweighs -1, then i will
> try to gether developers who can help me in this task, and try to
> finish it by Sept. 2002.
>
> BUT, if -1 outweighs +1, then i will cancel the project and live it
> for my spare time, and will not go around asking everyone about
> it...
>
> OR, another way of doing this would be to, just try and get this JFS
> porting done by people who would like to do it (including me), and
> then put it on the FreeBSD site.

This is the traditional way to do it.  You don't need anybody's
permission :-)  You can also be sure that you won't get many replies
either way, and those you get may not be representative of the project
as a whole.

"Just Do It".

Greg
--
See complete headers for address and phone numbers

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

Re: NFS: How to make FreeBSD fall on its face in one easy step

[Peter Wemm]

Jordan Hubbard wrote:
> > I should point out that FSX can be used against any filesystem, and
> > that there are reports locally (at Apple) that it's great for killing
> > FreeBSD machines.  I wasn't able to reproduce this when I tried, but I
> > may not have let it run long enough.
> 
> Oh, it blows freebsd.apple.com right out of the water with a kernel
> panic after running for just 3 seconds from an OS X box on the same
> LAN segment. :)

To be clear, what exactly are you doing?

It sounds like you're exporting something from freebsd, mounting it on OSX
and running this tool on OSX against the filesystem exported from freebsd ?

If so, What mount options?  NFSv2 or v3?

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5


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

Re: NFS: How to make FreeBSD fall on its face in one easy step

[Matthew Dillon]

I found a second bug... nfs truncation code race.

I've enclosed both patches below.  NFS truncation race first, softupdates
bug second.   The patches are against -stable.

There are still more bugs... the nfstest code is seeing data corruption
on read.  It looks like another truncation bug.  I'm tracking it down.

-Matt

Index: nfs/nfs_vnops.c
===
RCS file: /home/ncvs/src/sys/nfs/Attic/nfs_vnops.c,v
retrieving revision 1.150.2.4
diff -u -r1.150.2.4 nfs_vnops.c
--- nfs/nfs_vnops.c 2001/08/05 00:23:58 1.150.2.4
+++ nfs/nfs_vnops.c 2001/12/13 01:42:15
@@ -710,6 +710,15 @@
 */
if (vp->v_mount->mnt_flag & MNT_RDONLY)
return (EROFS);
+
+   /*
+* We run vnode_pager_setsize() early (why?),
+* we must set np->n_size now to avoid vinvalbuf
+* V_SAVE races that might setsize a lower
+* value.
+*/
+   tsize = np->n_size;
+   np->n_size = vap->va_size;
vnode_pager_setsize(vp, vap->va_size);
if (np->n_flag & NMODIFIED) {
if (vap->va_size == 0)
@@ -719,12 +728,12 @@
error = nfs_vinvalbuf(vp, V_SAVE,
ap->a_cred, ap->a_p, 1);
if (error) {
+   np->n_size = tsize;
vnode_pager_setsize(vp, np->n_size);
return (error);
}
}
-   tsize = np->n_size;
-   np->n_size = np->n_vattr.va_size = vap->va_size;
+   np->n_vattr.va_size = vap->va_size;
};
} else if ((vap->va_mtime.tv_sec != VNOVAL ||
vap->va_atime.tv_sec != VNOVAL) && (np->n_flag & NMODIFIED) &&
Index: ufs/ffs/ffs_inode.c
===
RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_inode.c,v
retrieving revision 1.56.2.3
diff -u -r1.56.2.3 ffs_inode.c
--- ufs/ffs/ffs_inode.c 2001/11/20 20:27:27 1.56.2.3
+++ ufs/ffs/ffs_inode.c 2001/12/12 23:43:36
@@ -244,6 +244,10 @@
if (error) {
return (error);
}
+   if (length > 0 && DOINGSOFTDEP(ovp)) {
+   if ((error = VOP_FSYNC(ovp, cred, MNT_WAIT, p)) != 0)
+   return (error);
+   }
oip->i_size = length;
size = blksize(fs, oip, lbn);
if (ovp->v_type != VDIR)
@@ -359,6 +363,10 @@
if (newspace == 0)
panic("ffs_truncate: newspace");
if (oldspace - newspace > 0) {
+   /*
+* XXX Softupdates, adjust queued directblock
+* in place rather then the second FSYNC above?
+*/
/*
 * Block number of space to be free'd is
 * the old block # plus the number of frags

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

Bus master DMA problems

[Greg Johnson]

Hello,

I am working on a FreeBSD device driver for a custom
PCI bus device developed by my company. The PCI card
has large amounts on memory on it and we are using
bus master DMA to get data in and out of memory.

The proceedure that I am using is as follows:

A.1. The DMA controller on our device is set up
 for the DMA transfer of memory.

A.2. asleep() is called to let the OS know that we
 are about to wait on an event.

A.3. An enable bit is set on the device to start the
 transfer.

A.4. await() is called to get the current process to
 sleep and wait for the event.

A.5. The ISR, upon recipt of an interrupt that indicates
 that the DMA transfer is complete, calls wakeup()
 on the ident for the process sleeping, waiting for the
 DMA transfer.

A.6. await() returns.

In addition, the memory buffers on the PC host side are
initially allocated by a user process, and locked down
(wired) buy the device driver so that they a present
in physical memory.

A bus DMA Tag is created once on driver load that
describes the DMA transfers.

On a call to read or write:

B.1. Memory is locked.

B.2. bus_dmamap_sync() is called (PRE*)

B.3. bus_dmamap_load() is called

B.4. bus_dmamap sync() is called (POST*)

B.5. Memory is unlocked.

Now, the problem I am experiencing is that memory does not
appear to be DMAed correctly. When using the interrupt driver
method above, sometimes there are errors in the data written
to the device, and sometimes in the data read back from the
device.

When using a polling approach and dissabling the DMA interrupts,
starting the transfer and polling for when the transfer is complete,
the system works correctly.

Also, when using the interrupt approach described, if I insert a
large delay of about 100us (50us does not work) in the ISR at the
point when the ISR confirms that the interrupt is the DMA done
interrupt, then everything works correctly.

The problem sounds a lot like out PCI device is not completing
the DMA transfer when the interrupt is raised, but with the polling
process, it only seems to take a few (2-8)us before the DMA done
interrupt is asserted and the call returns, and in this case
everything works.

So if anyong out there in FreeBSD guru land has any ideas as
to what might be wrong, or things I might of missed in seeting
up stuff, I would really appreciate their input.

Our systems are x86 (PIIIs and P4s) running FreeBSD 4.4-stable.

Thanks.

Greg.

--
+--+
| Do you want to know more? www.geocities.com/worfsom/ |
|  ..ooOO Greg Johnson OOoo..  |
| HW/SW Engineer[EMAIL PROTECTED] |
| Canon Information Systems Research Australia (CISRA) |
| 1 Thomas Holt Dr., North Ryde, NSW, 2113,  Australia |
|  "I FLEXed my BISON and it went YACC!" - me. |
+--+


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

Re: NFS: How to make FreeBSD fall on its face in one easy step

[Jordan Hubbard]

> To be clear, what exactly are you doing?
> 
> It sounds like you're exporting something from freebsd, mounting it on OSX
> and running this tool on OSX against the filesystem exported from freebsd ?
> 
> If so, What mount options?  NFSv2 or v3?

That is correct.  As to the NFS options used, I honestly couldn't say
since I'm getting at the filesystem through Netinfo and that's handled
by OS X's automount daemon, that having no relation whatsoever to AMD
and hence no amd.conf file or anything else I can easily look at to
determine how it's being mounted.  Maybe Mike knows more about how to
find this out - he's not in management. :)

- Jordan

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

Hey folks!

[John Soule]

Title: Lighthouse in the Sunset





  

 
 
  Hi There,
My name is John.

I am a simple man living in North Carolina.

I have learned how to make a living on the net.

I am willing to teach you to do the same, in simple easy to understand lessons. 

I will work with you and teach you for FREE!

You don't have to be a computer whiz, or genius to learn to earn on the net!

You just need a dream, and be willing to give some time to learning and implementing the 

things I teach you.

You WILL NOT GET RICH QUICK! However, you will be able to build a good solid income and home 

business with little or no cash investment. 

You CAN become your own boss.

Your income will depend on you and whether or not you are willing to learn.

If you are willing to learn, and want to get to know and work with a real person, then 

contact me. I am real, and I promise to help you all I can. 

You are wondering why would I help you for Free? 

The companies that I am affiliated with, pay me commissions on what I do to promote their 

sites!

If I teach others to do the same, they pay me commissions on how well you do at promoting 

their sites. 

So my goal will be to teach you so well that you are making money and I am making money. I 

like it when the big boys pay me, and not the little guy like me and you.

If you are interested in learning more, 
send me an e-mail. mailto:[EMAIL PROTECTED]?subject=More_Info

Thank you for your Time, John 

This is a one time mailing to you, so you need do nothing to be removed from my list, as 

this list will only be used once.
This message does follow the anti-spam laws.

You received this mail because you or someone using your e-mail address visited a site 

message board, or signed a guest book on a site that has to do with home business, and I 

visited that site and got your address there. 

If you are mad about receiving this offer and really feel a need to tell me off, then you 

may do so by sending me an e-mail. mailto: [EMAIL PROTECTED]?subject=No_More_Mail Other wise 

Just delete this message.
 
  
  

  
  



  







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

Found NFS data corruption bug... (was Re: NFS: How to make FreeBSD fall on its face in one easy step )

[Matthew Dillon]

Ok, here is the latest patch for -stable.  Note that Kirk comitted a
slightly modified version of the softupdates fix to -current already
(the VOP_FSYNC stuff), which I will be MFCing in 3 days.

This still doesn't fix all the problems the nfstest program that Jordan
posted finds, but it sure runs a hellofalot longer now before reporting
an error.  10,000+ tests now before failing (NFSv2 and NFSv3).

Bugs fixed:

* Possible SMP database corruption due to vm_pager_unmap_page()
  not clearing the TLB for the other cpu's.

* When flusing a dirty buffer due to B_CACHE getting cleared,
  we were accidently setting B_CACHE again (that is, bwrite() sets
  B_CACHE), when we really want it to stay clear after the write
  is complete.  This resulted in a corrupt buffer.

* We have to call vtruncbuf() when ftruncate()ing to remove 
  any buffer cache buffers.  This is still tentitive, I may
  be able to remove it due to the second bug fix.

* vnode_pager_setsize() race against nfs_vinvalbuf()... we have
  to set n_size before calling nfs_vinvalbuf or the NFS code
  may recursively vnode_pager_setsize() to the original value
  before the truncate.  This is what was causing the user mmap
  bus faults in the nfs tester program.

* Fix to softupdates (old version)

There are some general comments in there too.  After I do more tests
and cleanups (maybe remove the vtruncbuf()) I will port it all to
-current, test, and commit.  So far the stuff is simple enough that
a 3-day MFC will probably suffice.

All I can say is... holy shit!

-Matt


Index: kern/vfs_bio.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_bio.c,v
retrieving revision 1.242.2.13
diff -u -r1.242.2.13 vfs_bio.c
--- kern/vfs_bio.c  2001/11/18 07:10:59 1.242.2.13
+++ kern/vfs_bio.c  2001/12/13 05:52:55
@@ -2189,9 +2189,22 @@
 * to softupdates re-dirtying the buffer.  In the latter
 * case, B_CACHE is set after the first write completes,
 * preventing further loops.
+*
+* NOTE!  b*write() sets B_CACHE.  If we cleared B_CACHE
+* above while extending the buffer, we cannot allow the
+* buffer to remain with B_CACHE set after the write
+* completes or it will represent a corrupt state.  To
+* deal with this we set B_NOCACHE to scrap the buffer
+* after the write.
+*
+* We might be able to do something fancy, like setting
+* B_CACHE in bwrite() except if B_DELWRI is already set,
+* so the below call doesn't set B_CACHE, but that gets real
+* confusing.  This is much easier.
 */
 
if ((bp->b_flags & (B_CACHE|B_DELWRI)) == B_DELWRI) {
+   bp->b_flags |= B_NOCACHE;
VOP_BWRITE(bp->b_vp, bp);
goto loop;
}
Index: nfs/nfs_bio.c
===
RCS file: /home/ncvs/src/sys/nfs/Attic/nfs_bio.c,v
retrieving revision 1.83.2.1
diff -u -r1.83.2.1 nfs_bio.c
--- nfs/nfs_bio.c   2001/11/18 07:10:59 1.83.2.1
+++ nfs/nfs_bio.c   2001/12/13 05:52:10
@@ -193,8 +193,14 @@
vm_page_set_validclean(m, 0, size - toff);
/* handled by vm_fault now*/
/* vm_page_zero_invalid(m, TRUE); */
+   } else {
+   /*
+* Read operation was short.  If no error occured
+* we may have hit a zero-fill section.   We simply
+* leave valid set to 0.
+*/
+   ;
}
-   
if (i != ap->a_reqpage) {
/*
 * Whether or not to leave the page activated is up in
@@ -896,14 +902,12 @@
else
bcount = np->n_size - (off_t)lbn * biosize;
}
-
-   bp = nfs_getcacheblk(vp, lbn, bcount, p);
-
if (uio->uio_offset + n > np->n_size) {
np->n_size = uio->uio_offset + n;
np->n_flag |= NMODIFIED;
vnode_pager_setsize(vp, np->n_size);
}
+   bp = nfs_getcacheblk(vp, lbn, bcount, p);
}
 
if (!bp) {
@@ -1409,11 +1413,13 @@
io.iov_len = uiop->uio_resid = bp->b_bcount;
io.iov_base = bp->b_data;
uiop

Re: Found NFS data corruption bug... (was Re: NFS: How to makeFreeBSD fall on its face in one easy step )

[Geoff Mohler]

Are any of these client-side performance upgrades as well as bug fixes?

On Wed, 12 Dec 2001, Matthew Dillon wrote:

> Ok, here is the latest patch for -stable.  Note that Kirk comitted a
> slightly modified version of the softupdates fix to -current already
> (the VOP_FSYNC stuff), which I will be MFCing in 3 days.
> 
> This still doesn't fix all the problems the nfstest program that Jordan
> posted finds, but it sure runs a hellofalot longer now before reporting
> an error.  10,000+ tests now before failing (NFSv2 and NFSv3).
> 
> Bugs fixed:
> 
>   * Possible SMP database corruption due to vm_pager_unmap_page()
> not clearing the TLB for the other cpu's.
> 
>   * When flusing a dirty buffer due to B_CACHE getting cleared,
> we were accidently setting B_CACHE again (that is, bwrite() sets
> B_CACHE), when we really want it to stay clear after the write
> is complete.  This resulted in a corrupt buffer.
> 
>   * We have to call vtruncbuf() when ftruncate()ing to remove 
> any buffer cache buffers.  This is still tentitive, I may
> be able to remove it due to the second bug fix.
> 
>   * vnode_pager_setsize() race against nfs_vinvalbuf()... we have
> to set n_size before calling nfs_vinvalbuf or the NFS code
> may recursively vnode_pager_setsize() to the original value
> before the truncate.  This is what was causing the user mmap
> bus faults in the nfs tester program.
> 
>   * Fix to softupdates (old version)
> 
> There are some general comments in there too.  After I do more tests
> and cleanups (maybe remove the vtruncbuf()) I will port it all to
> -current, test, and commit.  So far the stuff is simple enough that
> a 3-day MFC will probably suffice.
> 
> All I can say is... holy shit!
> 
>   -Matt
> 
> 
> Index: kern/vfs_bio.c
> ===
> RCS file: /home/ncvs/src/sys/kern/vfs_bio.c,v
> retrieving revision 1.242.2.13
> diff -u -r1.242.2.13 vfs_bio.c
> --- kern/vfs_bio.c2001/11/18 07:10:59 1.242.2.13
> +++ kern/vfs_bio.c2001/12/13 05:52:55
> @@ -2189,9 +2189,22 @@
>* to softupdates re-dirtying the buffer.  In the latter
>* case, B_CACHE is set after the first write completes,
>* preventing further loops.
> +  *
> +  * NOTE!  b*write() sets B_CACHE.  If we cleared B_CACHE
> +  * above while extending the buffer, we cannot allow the
> +  * buffer to remain with B_CACHE set after the write
> +  * completes or it will represent a corrupt state.  To
> +  * deal with this we set B_NOCACHE to scrap the buffer
> +  * after the write.
> +  *
> +  * We might be able to do something fancy, like setting
> +  * B_CACHE in bwrite() except if B_DELWRI is already set,
> +  * so the below call doesn't set B_CACHE, but that gets real
> +  * confusing.  This is much easier.
>*/
>  
>   if ((bp->b_flags & (B_CACHE|B_DELWRI)) == B_DELWRI) {
> + bp->b_flags |= B_NOCACHE;
>   VOP_BWRITE(bp->b_vp, bp);
>   goto loop;
>   }
> Index: nfs/nfs_bio.c
> ===
> RCS file: /home/ncvs/src/sys/nfs/Attic/nfs_bio.c,v
> retrieving revision 1.83.2.1
> diff -u -r1.83.2.1 nfs_bio.c
> --- nfs/nfs_bio.c 2001/11/18 07:10:59 1.83.2.1
> +++ nfs/nfs_bio.c 2001/12/13 05:52:10
> @@ -193,8 +193,14 @@
>   vm_page_set_validclean(m, 0, size - toff);
>   /* handled by vm_fault now*/
>   /* vm_page_zero_invalid(m, TRUE); */
> + } else {
> + /*
> +  * Read operation was short.  If no error occured
> +  * we may have hit a zero-fill section.   We simply
> +  * leave valid set to 0.
> +  */
> + ;
>   }
> - 
>   if (i != ap->a_reqpage) {
>   /*
>* Whether or not to leave the page activated is up in
> @@ -896,14 +902,12 @@
>   else
>   bcount = np->n_size - (off_t)lbn * biosize;
>   }
> -
> - bp = nfs_getcacheblk(vp, lbn, bcount, p);
> -
>   if (uio->uio_offset + n > np->n_size) {
>   np->n_size = uio->uio_offset + n;
>   np->n_flag |= NMODIFIED;
>   vnode_pager_setsize(vp, np->n_size);
>   }
> + bp = nfs_getcacheblk(vp, lb

Call for Works In Progress talks for BSDCon '02

[George V. Neville-Neil]

Hi Folks,

This is the first call for participation in the Works In Progress
session at BSD Con '02 in San Francisco.  Works In Progress talks
are 5 to 10 minute presentations of the work you're doing with BSD
that would be of interest to other people.

Please send a subject, short abstract (3-4 sentences), and
a contact email to [EMAIL PROTECTED]  Do NOT reply directly
to this email.

General information on the conference can be found at:

http://www.usenix.org/events/bsdcon02/

Thanks,
George V. Neville-Neil (WIPs Coordinator)

PS Apologies if you get this more than once.
-- 
George V. Neville-Neil  [EMAIL PROTECTED]
NIC:GN82 

"Those who would trade liberty for temporary security deserve neither" 
- Benjamin Franklin



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

Re: Found NFS data corruption bug... (was Re: NFS: How to makeFreeBSD fall on its face in one easy step )

[Matthew Dillon]

:
:Are any of these client-side performance upgrades as well as bug fixes?

No, just bug fixes.  The softupdates bug fix is server-side.  All
the other bug fixes are client side (so far).

-Matt

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

Re: Found NFS data corruption bug... (was Re: NFS: How to makeFreeBSD fall on its face in one easy step )

[Mike Silbersack]

On Wed, 12 Dec 2001, Matthew Dillon wrote:

>
> :
> :Are any of these client-side performance upgrades as well as bug fixes?
>
> No, just bug fixes.  The softupdates bug fix is server-side.  All
> the other bug fixes are client side (so far).
>
>   -Matt

Does the softupdates fix affect normal ffs operations as well?

Mike "Silby" Silbersack


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

Re: NFS: How to make FreeBSD fall on its face in one easy step

[Geoff Mohler]

I suppose while were on the topic..

Are there any hidden secrets to eeking out more performance from the BSD
NFS client (other than version types and the normal fstab tweaks).

Im the CS Labs manager at NetApp..and Im always trying to store away a
secret here or there when someone comes to me with a problem in the field.

FreeBSD since v2..rock on!


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

Re: Found NFS data corruption bug... (was Re: NFS: How to makeFreeBSD fall on its face in one easy step )

[Matthew Dillon]

:Does the softupdates fix affect normal ffs operations as well?
:
:Mike "Silby" Silbersack

Yes, we believe so.  It's a bug in ftruncate()'s interaction
with softupdates.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>

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

Re: Found NFS data corruption bug... (was Re: NFS: How to make FreeBSD fall on its face in one easy step )

[David Greenman]

   Very cool. Good job!

-DG

David Greenman
Co-founder, The FreeBSD Project - http://www.freebsd.org
President, TeraSolutions, Inc. - http://www.terasolutions.com
Pave the road of life with opportunities.

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

Re: NFS: How to make FreeBSD fall on its face in one easy step

[Matthew Dillon]

:I suppose while were on the topic..
:
:Are there any hidden secrets to eeking out more performance from the BSD
:NFS client (other than version types and the normal fstab tweaks).
:
:Im the CS Labs manager at NetApp..and Im always trying to store away a
:secret here or there when someone comes to me with a problem in the field.
:
:FreeBSD since v2..rock on!

* Make sure you don't have packet loss in your network (test with larger
  packets, aka ping -s 8192 rather then just ping, and perhaps test with
  a pattern (-p)).

* Run a sufficient number of nfsd's on the server side, depending on
  load.  4 or 8 is typical.

* Run nfsiod's on the client side.  I usually run 4.  This will drastically
  improve read-ahead and, for example, can bump linear read speeds on a
  100BaseTX network from 7 MBytes/sec to 11 MBytes/sec (full saturation).

* Use NFS version 3 when possible (this is the default)

* Sometimes playing around with the various attribute cache timeouts
  (see 'man mount_nfs') helps.  Sometimes it doesn't.

For extreme performance there are some zero-copy patches floating around
which have not been integrated into the main tree.  Generally, though,
your NFS performance is going to be ultimately limited by your server's
disk performance.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


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

Re: NFS: How to make FreeBSD fall on its face in one easy step

[Mike Silbersack]

On Wed, 12 Dec 2001, Matthew Dillon wrote:

> :I suppose while were on the topic..
> :
> :Are there any hidden secrets to eeking out more performance from the BSD
> :NFS client (other than version types and the normal fstab tweaks).
> :
> :Im the CS Labs manager at NetApp..and Im always trying to store away a
> :secret here or there when someone comes to me with a problem in the field.
> :
> :FreeBSD since v2..rock on!
>
> For extreme performance there are some zero-copy patches floating around
> which have not been integrated into the main tree.  Generally, though,
> your NFS performance is going to be ultimately limited by your server's
> disk performance.
>
>   -Matt
>   Matthew Dillon

And if you hadn't heard, Matt just fixed a couple of bugs in the tcp stack
which improves NFS greatly.  It sounds like after this round of NFS fixes,
the first answer to NFS questions should be:  Upgrade to 4.5!

Mike "Silby" Silbersack


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