linux compatibility question

1999-12-06 Thread Christian Bruno

hello,

just a question on Linux compatibility :
i was told linux binaries that access to the /proc special filesystem won't
work on freebsd ?
is that right for the last release of the linux compatibility package ?
In your opinion, is it possible to trap all these access to /proc ?

the reason why i ask this question is that most of commercial products are
only available on Linux boxes.
I know that Oracle 8.0.5 Linux can run on FreeBSD, and i cant imagine such
an application do not use the /proc

Regards,
Christian
[EMAIL PROTECTED]




 
__
Message envoye depuis iFrance >>  http://www.ifrance.com
Gratuit >> Hebergement (50 Mo)/Vos emails (POP&HTML,20 Mo)
Votre agenda online gratuit >> http://agenda.ifrance.com
NOUVEAU : Faxez gratuitement ! >> http://fax.ifrance.com



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



Re: cdrom speed adjustment ioctl

1999-12-06 Thread Randell Jesup

Egervary Gergely <[EMAIL PROTECTED]> writes:
>> I've just hacked a new ioctl into the ATAPI cdrom driver, which
>> lets the user to specify (pronounce: ``slow down'' :) the speed 
>> of todays' extremely high speed drives.
>
>ok, so i see you like the idea - so the question is: should we implement a
>new ioctl for it, or - as like scsi - should we use a program like
>camcontrol for it?

One solution I used in the past (Amiga) was to implement the
ATA (and ATAPI) support by writing the equivalent of SCSI CAM SIM;
that is a SIM that actually controlled IDE hardware instead of SCSI
hardware.  This is quite easy, in fact, especially since ATAPI is
basically SCSI-over-IDE with a few twists.

-- 
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
[EMAIL PROTECTED]
CDA II has been passed and signed, sigh.  The lawsuit has been filed.  Please
support the organizations fighting it - ACLU, EFF, CDT, etc.



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



RE: Irda support.

1999-12-06 Thread Daniel O'Connor


On 07-Dec-99 Julian Elischer wrote:
>  I'm playing with Irda a bit and an wondering if anyone has also been doing
>  do. The Linux Irda project lookes quite advanced.

I have been doing not much more than thinking about it :-/

I'd be interested in participating in a project to do IrDA for FreeBSD..

---
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum


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



Irda support.

1999-12-06 Thread Julian Elischer


I'm playing with Irda a bit and an wondering if anyone has also been doing
do. The Linux Irda project lookes quite advanced.

Julian



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



Re: HomePNA network cards

1999-12-06 Thread Julian Elischer

On Mon, 6 Dec 1999, Julian Elischer wrote:

> 
> 
> On Tue, 7 Dec 1999, Robert Watson wrote:
> 
> > On Mon, 6 Dec 1999, Wes Peters wrote:
> > 
> > I submitted a pr in June with patches, and it seems to work fairly well.
> > Never checked to see if it was commited though.  I've had problems with
> > dropped packets, however--at certain times of day (?) I can't pass any
> > packets on phone wires that run vertically in my parents home.  Ended up
> > running ethernet between floors of their house, and the homepna stuff
> > inside the floors.
> 
> I looked at the pr database and couldn't see it. can you give more info?

Found it...
it's been committed to -current.. (and was therefore marked 'closed')

> 
> Julian
> 
> 
> 
> 
> 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: HomePNA network cards

1999-12-06 Thread Robert Watson

On Mon, 6 Dec 1999, Julian Elischer wrote:

> On Tue, 7 Dec 1999, Robert Watson wrote:
> 
> > On Mon, 6 Dec 1999, Wes Peters wrote:
> > 
> > I submitted a pr in June with patches, and it seems to work fairly well.
> > Never checked to see if it was commited though.  I've had problems with
> > dropped packets, however--at certain times of day (?) I can't pass any
> > packets on phone wires that run vertically in my parents home.  Ended up
> > running ethernet between floors of their house, and the homepna stuff
> > inside the floors.
> 
> I looked at the pr database and couldn't see it. can you give more info?
> 
> Julian

I believe it was kern/12275.  Think it was even closed, but haven't
checked in a while.  All I know is the cards are working except for the
warnings they give and the weird certain-times-of-day problems that case
the warnings.  It's weird--I guess everyone turns their flourescent lights
on at the same time or something.

  Robert N M Watson 

[EMAIL PROTECTED]  http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services



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



Re: HomePNA network cards

1999-12-06 Thread Julian Elischer



On Tue, 7 Dec 1999, Robert Watson wrote:

> On Mon, 6 Dec 1999, Wes Peters wrote:
> 
> I submitted a pr in June with patches, and it seems to work fairly well.
> Never checked to see if it was commited though.  I've had problems with
> dropped packets, however--at certain times of day (?) I can't pass any
> packets on phone wires that run vertically in my parents home.  Ended up
> running ethernet between floors of their house, and the homepna stuff
> inside the floors.

I looked at the pr database and couldn't see it. can you give more info?

Julian




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



Re: HomePNA network cards

1999-12-06 Thread Robert Watson

On Mon, 6 Dec 1999, Wes Peters wrote:

> Has anyone gotten one of these to work with the lnc driver in current?
> Looking at the chip specs, it is supposed to be software compatible with
> the PCNet PCI parts, but it sports the "home networking" PHY that are
> not supported on other LANCE parts.
> 
> If you've had success with these, please let me know.  A friend wants to 
> setup a network but doesn't have access to the wall spaces in his house.
> Silly boy.

I submitted a pr in June with patches, and it seems to work fairly well.
Never checked to see if it was commited though.  I've had problems with
dropped packets, however--at certain times of day (?) I can't pass any
packets on phone wires that run vertically in my parents home.  Ended up
running ethernet between floors of their house, and the homepna stuff
inside the floors.

  Robert N M Watson 

[EMAIL PROTECTED]  http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services



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



RE: PCI device drivers

1999-12-06 Thread Daniel O'Connor


On 07-Dec-99 Alex wrote:
>  in my device driver, that can returns me device 
>  configuration (pcici_t)? (like in Linux - 
>  pcibios_find_device)
>  Thanks for any help?

Thats not the way its done in FreeBSD..

Your probe routine is called when the system wants to know if a given device
can be handled by your driver.

Read /usr/src/sys/pci/if_fxp.c

Actually all of /usr/src/sys/pci/* is interesting reading :)

---
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum


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



*jmp() renaming in libc

1999-12-06 Thread Jason Evans

I'm porting the most recent released version of LinuxThreads
(glibc-linuxthreads-2.1.2), and ran into a bit of a problem with regard to
longjmp() and siglongjmp().  LinuxThreads wraps these functions so that
they work correctly in the presence of cleanup handlers.  However, this
doesn't appear to be possible with our C library, since there are no other
names by which to access sigsetjmp() and siglongjmp().  I noticed the
following comment in src/lib/libc/i386/gen/sigsetjmp.S:

/*-
 * TODO:
 * Rename sigsetjmp to __sigsetjmp and siglongjmp to __siglongjmp,
 * remove the other *jmp functions and define everything in terms
 * of the renamed functions.  This requires compiler support for
 * the renamed functions (introduced in gcc-2.5.3; previous versions
 * only supported *jmp with 0 or 1 leading underscores).
 *

 [...]

 */

If this were done, I think it would solve my problem.  However, it looks to
be an almost trivially easy change for someone familiar with libc, yet it
hasn't happened for the several years that it has been possible.  Also, for
the alpha platform, sigsetjmp() and siglongjmp() are defined in terms of
setjmp(), _setjmp(), longjmp(), and _longjmp(), which is essentially the
opposite approach of what the TODO comment suggests.  Is there a reason
that this TODO comment hasn't been acted on, other than no one getting
around to it?

Jason


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



About divert socket

1999-12-06 Thread Witthaya Panichprechakorn

Dear Sir,
I use divert socket to captuer packets. I found that when
I capture a set of fragmented packets, there are 2 incoming reassembled
packets. The sin_port of sockaddr_in of the first packet is 0,
and of another packet is the port number, which it bound to.
However, when the packet is not fragmented, there is only one incoming
packet with sin_port of sockaddr_in equals to the port number, which it
bound to, similar to the second captured packet when framentation
occured. What is the actual process when a set of fragmented packets is
arrived? Why the system should divert two incoming packets?

Best Regards,
Withaya Panichpreechakorn




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



Re: PCI DMA lockups in 3.2 (3.3 maybe?)

1999-12-06 Thread Andrew Reilly

On Sun, Dec 05, 1999 at 07:42:21PM -0700, Wes Peters wrote:
> Software
> is created by humans, and humans are fallible, therefore the software
> is also fallible.

No, that doesn't logically follow.  Just because it's possible
for humans to make mistakes doesn't mean that it's impossible to
do or make something (eventually) without mistakes.  Even when
formal proof isn't possible (the usual case) careful design,
backed up by design-based assertions and tests can produce code
that does not have bugs.

FreeBSD is a big and complicated thing, but it's (largely)
composed of subsystems that can be maintained, designed and
tested by individuals.  I think that a goal of "surprise at a
crash of any sort" isn't unreasonable, and highly desirable.

I'll take "right" over "fast", and both over "features" any day.

-- 
Andrew


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



Re: ejecting card with 3.3 causes hang ?

1999-12-06 Thread Nick Hilliard

: I don't maintain -stable's pccard code and to the best of
: my knowledge, no one else does either.  This means there is no one to
: look at them.
: 
: I'll be happy to look at patches for -stable, however.  The times I've
: made this offer in the past I've not gotten patches.

Now that you're volunteering, could you please change CIS_MAXSTR in
usr.sbin/pccard/pccardd/readcis.h from 30 to something large - 254 would do
fine?  There's an open PR about this in GNATS, but it looks like GNATS is
fubar at the moment, so I can't give you the exact number of it.  It's
categorised under bin/, was submitted in Q1 1999, and has a subject
including the text "CIS_MAXSTR", so it shouldn't be too difficult to find.

The change is completely benign and doesn't have any adverse side-effects.

Nick


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



Re: Linking problems w/ pthreads on 3.3

1999-12-06 Thread Kip Macy

I had a similar problem from installing GNU's Portable Threads package.
I fixed it by uninstalling the package.

-Kip

On Mon, 6 Dec 1999, Viren Jain wrote:

> NOTE: Please reply directly to my email address ([EMAIL PROTECTED])
> 
> Platform: x86, FreeBSD 3.3
> 
> While trying to link a threaded application with -pthread using the 
> following command line:
> gcc -I/usr/local/include -L/usr/local/lib/mysql -pthread -o impd daemon.o 
> db.o handlers.o imp_list.o imp_util.o log.o main.o net.o opt.o request.o 
> sig.o statsd.o util.o -lmysqlclient
> 
> I receive the following errors:
> 
> daemon.o(.text+0x10): undefined reference to `__pthread_fork'
> db.o(.text+0x33c): undefined reference to `__pthread_sleep'
> main.o(.text+0xce): undefined reference to `__pthread_detach'
> net.o(.text+0x196): undefined reference to `__pthread_select'
> net.o(.text+0x411): undefined reference to `__pthread_read'
> net.o(.text+0x535): undefined reference to `__pthread_write'
> 
> Threaded libraries appear to be installed in /usr/lib (libc_r.a, libc_r.so, 
> libc_r.so.3, and libc_r_p.a) and thus I am unsure of how to correct this 
> problem. Any help or advice would be appreciated.
> 
>   -- Viren
> 
> 
> 
> 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



PCI device drivers

1999-12-06 Thread Alex

This message was sent from Geocrawler.com by "Alex" <[EMAIL PROTECTED]>
Be sure to reply to that address.

Hello,

I'm writting PCI device drivers (KLD) for FreeBSD 
3.2.
PCI board is probed and attached correclty during 
booting. Is exist any function, which I can use 
in my device driver, that can returns me device 
configuration (pcici_t)? (like in Linux - 
pcibios_find_device)
Thanks for any help?



Geocrawler.com - The Knowledge Archive


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



Re: ELF & putting inode at the front of a file

1999-12-06 Thread Matthew Dillon

:> distribute the inodes all over the cylinder group rather then concentrate
:> all the inodes in one place.
:
:Yes. I have implemented most of the code.  I noticed the "ls -al" is slow
:but "ls" is OK. 

Yes, ls (without any options) is ok because the file type is now being
stuffed in the directory entry, allowing ls (without any options) to 
avoid stat()ing the file.

:> p.s. I was wrong about it breaking mmap() - in fact offseting the file
:> data on-disk will not break mmap().  But it will produce unaligned disk
:> transfers and potentially extra seeking.
:
:Yes. The cp command may use mmap().  I modify the mmap() so that this
:works. But this mmap() is done by the user, I can intercept it at the
:mmap() system call.  As I said in my original email, the kernel uses
:memory map internally to load an ELF object file. I have to let the kernel
:know that there is a disk inode at the beginning of the ELF object file.
:It is hard for me to identify what part of the code is affected and to
:what extent.  I think there should be a way.
:
:-Zhihui

There's another issue that you should look at - generally functionally
different caches work better as separate entities then as a single 
entity.  In this case it is far easier for the system to cache an inode
(or a set of inodes) then it is for the system to cache a data block.  If
you force a system to cache both at the same time when it only needs one
type or the other (because one might already be cached), the result is
that neither cache is able to run optimally.

It might be interesting, as an exercise, to attempt to pre-cache the inode
space in the traditional unmodified system when a directory is
read and leave them as separate entities and see whether that gives you
the same performance boost.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>



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



Re: Is part of user stack always mapped?

1999-12-06 Thread Andrew Gallatin


Luoqi Chen writes:
 > > I was under the impression that this was a no-no & one should use
 > > copyin/copout & friends to access memory on users's stacks.  Although
 > > this appears to work on the i386, if I try this on the alpha I take a
 > > fatal trap when accessing *set.
 > > 
 > > So -- how does this work on the i386?  Is  the user's stack always
 > > mappeped into the kernel's address space?  Should it also work on the
 > > alpha? 
 > > 
 > On i386, under the current implementation, the kernel can directly access
 > curproc's address space (not just the stack, stack is used because we're
 > sure the spare space won't/shouldn't be used by the user application).
 > I don't know if the same is true for alpha, but this should definitely
 > be considered an implementation dependent feature. I wish there were some
 > other ways to bypass copyin/out in ioctls.
 > 
 > -lq

I think the alpha should be capable of doing this too.  From reading
the alpha pmap code, it looks like its marking memory as kernel
readable/writeable whenever it does the same for the userspace access.
I might be reading it wrong, though.

Can anybody tell me why an access to memory allocated w/stackgap_alloc()
would cause a kernel panic on alpha, but works just fine through the
copyin/copyout interface?

Eg:

#0  0xfc391054 in boot (howto=256) at ../../kern/kern_shutdown.c:271
#1  0xfc391810 in panic (fmt=0xfc5a2ca4 "trap")
at ../../kern/kern_shutdown.c:523
#2  0xfc5340a0 in trap (a0=301973216, a1=1, a2=1, entry=2, 
framep=0xfe0010699ce0) at ../../alpha/alpha/trap.c:529
#3  0xfc5262ec in XentMM () at ../../alpha/alpha/exception.s:94
#4  0xfe0001afa440 in osf1_sigsuspend (p=0xfe000ed4ff00, uap=0x0)
at 
/usr/project/ari_scratch2/gallatin/src/sys/modules/osf1/../../alpha/osf1/osf1_signal.c:613
#5  0xfc534304 in syscall (code=111, framep=0xfe0010699ee0)
at ../../alpha/alpha/trap.c:633
#6  0xfc52634c in XentSys () at ../../alpha/alpha/exception.s:127

<...>
(gdb) frame 2
#2  0xfc5340a0 in trap (a0=301973216, a1=1, a2=1, entry=2, 
framep=0xfe0010699ce0) at ../../alpha/alpha/trap.c:529
529 panic("trap");
(gdb) p/x a0
$1 = 0x11ffbee0
(gdb) p/x curproc->p_vmspace->vm_maxsaddr
$2 = 0xfffc000
(gdb) p/x curproc->p_vmspace->vm_minsaddr
$3 = 0x11ffb2c8


For you non-alpha people -- in the above, a0 is the faulting address. 

Thanks,

Drew


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



Re: PCI DMA lockups in 3.2 (3.3 maybe?)

1999-12-06 Thread Gerard Roudier



On Mon, 6 Dec 1999, Parag Patel wrote:
 
[ ... ]

> In the proecss, we discovered a very interesting thing about the
> NCR/Symbios chips, at least the 810 and 825 series.  Turns out that when
> they are executing their scripts, and the scripts access an on-board PCI
> register, that access actually negotiates for the PCI bus and uses it to
> read the register!  That's right - it uses the PCI bus to talk to
> itself - even when it's not DMA-ing anything!

That's true for drivers that uses MEMORY MOVE scripts instructions to
access chip IO registers from SCRIPTS, as does the ncr and most existing
generic SYM53C8XX PCI device drivers. Such a technic is no longer PCI
compliant since PCI specifications 2.2. The sym driver uses LOAD/STORE
instead that donnot involve any self mastering from the chip and so
preserves PCI 2.2 compliance. But this needed to drop support of 810 and
825. Btw, even using the sym driver has been reported to trigger the
problem, so this should not be the cause of the problem. 

> Freaked us out when we saw it, 'cause the CPU wasn't anywhere near any
> code that was accessing the NCR's registers.  Of course it slows down
> script execution but could slow down the PCI bus depending on the
> script.  And this is all without the CPU being involved.  Certainly
> it'll cause more PCI-bus activity that most other chips, and perhaps
> this is why NCR controllers tend to trigger the DMA condition.

I donnot know about the fxp driver, but looking into the code as a newbie,
I didn't get how this driver ensures instruction and memory ordering and
PCI transaction ordering when it is needed (could it be never needed?). It
also seems to write non atomically to some 32 bit quantities in memory
that seem to be accessed by the PCI device. Indeed, I may for sure did
miss lots of things, but this seems strange to me.
Sorry if my remarks are irrelevant. I just was wondering.

> It seems that whoever designed the NCR's script-engine glommed it onto
> the original programmed I/O SCSI core using the PCI bus instead of
> redesigning the chip.  Cheap short-cut.  Dunno if any other NCR chips
> exhibit this behavior, but I wouldn't be surprised.

A well designed PCI device must be capable of having its master part
accessing its target part through the PCI BUS lines without contention. 
This does not imply that using such a feature is recommended since it
wastes PCI bandwidth (and btw is not compliant with PCI-2.2). Using
internal pathes instead is recommended to access internal ressources. The
sym driver does this the right way using LOAD/STORE (at least, it is what
I beleive :), but this could not be achieved for ealiest 810/815/825 due
to the lack of these SCRIPTS instructions for these chips. 

GĂ©rard.



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



Glide source available

1999-12-06 Thread Stephen Hocking-Senior Programmer PGS Perth


Go look at http://linux.3dfx.com/open_source
It's availabe for Voodoo 1, 2, & 3 cards. Register level specs too! I'm
utterly freaked out.


Stephen


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



Re: 3c589d w/ freebsd 3.3 works badly.

1999-12-06 Thread Warner Losh

In message <[EMAIL PROTECTED]> Darren Reed writes:
: Did all of that.  When ejecting the card it says "freeing IRQ 10" (or
: words to that effect), which is the IRQ I used with it under Windows
: and NetBSD.  How much can I specify on the "config" lines in pccard.conf ?
: Can I `wire down' irq's, iomem and iobuf in the "?" part of the line ?

For -stable, no you can't do it that way.  You can do it with
/boot/loader.conf by setting the following.  If you are gunning for
10, then substitute 10 for the '0' below.

machdep.pccard.pcic_irq="0" # Assigns PCCARD controller IRQ (0=polled)

You wire down the memory part in /etc/rc.conf:

pccard_mem="DEFAULT"# If pccard_enable=YES, this is card memory address.

The irq/memory for the card itself is done /etc/pccard.conf, which is
at best an exersize in black magic and at worst a frustration laden
time for one and all.

: p.s. is the not printing of the IRQ being allocated at bootup a bug ?

Yes.  I think so.  We should print which IRQ we're using.  The
pcic/pccard module is a kludgey wort on the side of the kludgy
old-config system...

Warner


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



Re: Is part of user stack always mapped?

1999-12-06 Thread Mike Smith

> > I was under the impression that this was a no-no & one should use
> > copyin/copout & friends to access memory on users's stacks.  Although
> > this appears to work on the i386, if I try this on the alpha I take a
> > fatal trap when accessing *set.
> > 
> > So -- how does this work on the i386?  Is  the user's stack always
> > mappeped into the kernel's address space?  Should it also work on the
> > alpha? 
> > 
> On i386, under the current implementation, the kernel can directly access
> curproc's address space (not just the stack, stack is used because we're
> sure the spare space won't/shouldn't be used by the user application).
> I don't know if the same is true for alpha, but this should definitely
> be considered an implementation dependent feature. I wish there were some
> other ways to bypass copyin/out in ioctls.

The problem wouldn't be a problem if the implementation portion of system 
call code didn't make assumptions about whether data is in user- or 
kernel-space.  This has been an off and on topic of discussion for some 
time now.

The ABI emulators use the stackgap because there are system call 
implementations that expect to be moving their data structures to/from 
user space. 8(

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]




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



Re: 3c589d w/ freebsd 3.3 works badly.

1999-12-06 Thread Darren Reed

In some mail from Warner Losh, sie said:
> 
> In message <[EMAIL PROTECTED]> Darren Reed writes:
> : How reliable should the ep0 driver be with 3c389d pcmcia cards ?
> 
> I had no problems using 3.3 and my 3C589D, but I've only done minor
> stuff with that.  I've done most of my work on -current, however.  The
> most likely problem is that you're using the wrong IRQ for the card.
> You'll want to check /etc/rc.conf to make sure that you are using the
> /etc/pccard.conf file.  Also, you'll want to make sure that the irq
> line is correct.

Did all of that.  When ejecting the card it says "freeing IRQ 10" (or
words to that effect), which is the IRQ I used with it under Windows
and NetBSD.  How much can I specify on the "config" lines in pccard.conf ?
Can I `wire down' irq's, iomem and iobuf in the "?" part of the line ?

Darren

p.s. is the not printing of the IRQ being allocated at bootup a bug ?


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



Re: tty level buffer overflows

1999-12-06 Thread Warner Losh

In message <[EMAIL PROTECTED]> Mike Smith writes:
: Yup. Ignore the "problem in the application" part, as that predicates 
: that the kernel and driver are working properly, which doesn't seem to be 
: the case.  The problem here is that the buffer between the top side of 
: the driver and the application isn't being drained fast enough.  It would 
: be educational to know what the app is sleeping on when these messages 
: are emitted; just dropping to ddb and using 'ps' would probably be 
: enough.  There has to be some reason that the process is either not being 
: woken when data arrives, or is being held up somewhere else for long 
: enough that the clist overflows.  
: 
: Does the problem still manifest with the recent scheduler changes?  
: Perhaps the comms processes are being unfairly scheduled against for some 
: reason?

We're seeing it with our ppp link, which uses the kernel level ppp
code.  Since it doesn't happen for me often, it is hard to diagnose.

Warner


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



Re: ejecting card with 3.3 causes hang ?

1999-12-06 Thread Warner Losh

In message <[EMAIL PROTECTED]> Darren Reed writes:
: ejecting a modem pcmcia card caused 3.3 to do the following:
: /kernel: sio2 unload,gone
: /kernel: Return IRQ=11
: /kernel: Card removed, slot 1
: /kernel: Card inserted, slot 0
: and then it was frozen.
: 
: Will there be a 3.4 with things like this fixed ?

Not likely.  There are no known problems right now in the -stable code
which don't represent a failure to detect pilor error and/or race
conditions that cannot be worked around w/o huge performance
penalties.  I don't maintain -stable's pccard code and to the best of
my knowledge, no one else does either.  This means there is no one to
look at them.

I'll be happy to look at patches for -stable, however.  The times I've
made this offer in the past I've not gotten patches.

Warner



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



Re: 3c589d w/ freebsd 3.3 works badly.

1999-12-06 Thread Warner Losh

In message <[EMAIL PROTECTED]> Darren Reed writes:
: How reliable should the ep0 driver be with 3c389d pcmcia cards ?

I had no problems using 3.3 and my 3C589D, but I've only done minor
stuff with that.  I've done most of my work on -current, however.  The
most likely problem is that you're using the wrong IRQ for the card.
You'll want to check /etc/rc.conf to make sure that you are using the
/etc/pccard.conf file.  Also, you'll want to make sure that the irq
line is correct.

Warner


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



Re: PCI DMA lockups in 3.2 (3.3 maybe?)

1999-12-06 Thread Karl Denninger

On Mon, Dec 06, 1999 at 01:24:36PM -0800, Matthew Dillon wrote:
> :Well, I used to run -CURRENT in a commercial environment :-)
> :
> :And I got bashed here and elsewhere for doing it too.
> :
> :But, with the exception of some really egregious fuck-ups (on both my part
> :and those of people who committed shit that didn't work AT ALL) it was, by
> :far, the better option of those available.
> :
> :For quite some time there were special "hacks" that I had (primarily
> :consisting of grabbing older versions of this module or that) to get
> :around stupidities that were in the process of being resolved, and there
> :were always things that I disabled or just didn't do because I knew they
> :were broken.
> 
> This was an unfortunate consequence which I take partial blame for
> in my little corner of the system -- but only partial blame.  It was
> hard enough getting my stuff into -current with all the extra requirements
> core forced onto me, I didn't want to have to go through the same hell
> to get it MFC'd into -stable as well.  At one point at the beginning,
> before the shit began to fly, I was actually considering only doing it
> for -current but as more and more bugs were found it became clear that
> if the stuff didn't get MFC'd into -stable soon it wouldn't at all.
> By that time the shit was already flying and I just didn't want to
> double it.  Maybe 80% of the bug fixes have been MFC'd -- the ones that
> were easy to fix.  The other 20% can't be MFC'd without the rest of
> the infrastructure in 4.x to support them.
> 
> I hope the same thing will not repeat for 4.x/5.x, even without an
> enforced stabilizing period between 4.0 and 4.1 prior to branching
> off.  However, I think that an enforced stabilizing period where 
> *everyone* is concentrating on 4.1 for a couple of months would be 
> extremely good for the project.
> 
>   -Matt

I don't think you were to blame at all Matt, at least not in my particular
set of circumstances.

I'm the first to admit that when I use an OS I typically have both high
expectations and also tend to have unique requirements.  I stress parts 
of the system that many people do not.  I frequently make performance 
demands on parts of the system that are unique, and they are inherent to
how I design systems and software - I don't believe in throwing iron at
a problem, rather, I expect the iron that is available to work with the
code that is in the OS - and do so properly.

When things don't work that way, its trouble.

The list of vendors I have pissed off over the years because they either (1)
broke something that worked horribly - usually by destroying its performance
to the point that areas of the system I counted on were no longer usable for
the production load I expected out of them, or (2) they flatly didn't bother
supporting certain things that *should* work, is legion in the business in
general.  In some cases (commercialware, where you can have such expectations)
I've found cooking of so-called "published performance levels" to literally 
outrageous levels, at least one commercial vendor has eaten six-digits
worth of equipment over these types of issues, and another (many, many 
years ago) was literally driven from the US marketplace.

I tend to find these situations very rapidly under commercial use
conditions, because I select components and subsystems *precisely* due
to those performance claims.  When they cannot be met, or something is
changed that breaks those claims, well, then the fur flies.

This shouldn't imply that I dislike FreeBSD.  On the contrary.  It's still
what I run on my OWN hardware for my OWN projects - after trying pretty much
literally everything else at least once, and even after getting into some
pretty serious pissing matches over the years with various members of CORE.

Where I'm from that's known as a ringing endorsement.

--
-- 
Karl Denninger ([EMAIL PROTECTED])  Web: http://childrens-justice.org
Isn't it time we started putting KIDS first?  See the above URL for
a plan to do exactly that!


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



Re: PCI DMA lockups in 3.2 (3.3 maybe?)

1999-12-06 Thread Parag Patel


Regarding the PCI DMA problems and corruption, it reminds of me of a
similar PCI and DMA-related problem we had when porting OpenBSD to a
now-defunct NKK MIPS chipset.  It may not be related, but here it is.

The port was up and running but under heavy load, say a compile, apps
(specifically one of the compiler passes) that were running would start
dying with seg-faults and then locking up the system.  We finally had to
get out the logic-analyzer and MIPS probe, and even then we still
couldn't watch everything due to the MIPS on-chip cache.

The support chipset was locking up.  This chip had to handle memory
access from the MIPS CPU, handle DRAM directly, and handle DMA access
from the PCI bus.  It bridged all three (CPU, RAM, PCI) and seemed to us
to be hosing itself in some funky meta-stable condition.  Heavy
simultaneous memory access, typically PCI DMA bursts from different
devices, usually triggered the lockup.

So it's quite possible that the host-to-PCI-to-memory controller chipset
may be the real culprit and not the drivers or specific PCI devices.


In the proecss, we discovered a very interesting thing about the
NCR/Symbios chips, at least the 810 and 825 series.  Turns out that when
they are executing their scripts, and the scripts access an on-board PCI
register, that access actually negotiates for the PCI bus and uses it to
read the register!  That's right - it uses the PCI bus to talk to
itself - even when it's not DMA-ing anything!

Freaked us out when we saw it, 'cause the CPU wasn't anywhere near any
code that was accessing the NCR's registers.  Of course it slows down
script execution but could slow down the PCI bus depending on the
script.  And this is all without the CPU being involved.  Certainly
it'll cause more PCI-bus activity that most other chips, and perhaps
this is why NCR controllers tend to trigger the DMA condition.

It seems that whoever designed the NCR's script-engine glommed it onto
the original programmed I/O SCSI core using the PCI bus instead of
redesigning the chip.  Cheap short-cut.  Dunno if any other NCR chips
exhibit this behavior, but I wouldn't be surprised.


-- Parag Patel


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



Re: HomePNA network cards

1999-12-06 Thread Julian Elischer

I have one here..

(and all the specs)
 the code changes needed to thte lnc driver are:

1/ new PCI ID :-)
2/ BSD equivalent of the following linux code:
 case 0x2626:
chipname = "PCnet/Home 79C978";
fdx = 1;
/*
 * This is based on specs published at www.amd.com.  This section
 * assumes that a card with a 79C978 wants to go into 1Mb HomePNA
 * mode.  The 79C978 can also go into standard ethernet, and there
 * probably should be some sort of module option to select the
 * mode by which the card should operate
 */
/* switch to home wiring mode */
media = a->read_bcr (ioaddr, 49);
if (pcnet32_debug > 2)
printk("pcnet32: pcnet32 media value %#x.\n",  media);
media &= ~3;
media |= 1;
if (pcnet32_debug > 2)
printk("pcnet32: pcnet32 media reset to %#x.\n",  media);
a->write_bcr (ioaddr, 49, media);
break;



I have alrady added the HomePNA media type to the if_media.h list
so all I need is to add this code..
(unless you beat me to it :-)

Julian


On Mon, 6 Dec 1999, Wes Peters wrote:

> Has anyone gotten one of these to work with the lnc driver in current?
> Looking at the chip specs, it is supposed to be software compatible with
> the PCNet PCI parts, but it sports the "home networking" PHY that are
> not supported on other LANCE parts.
> 
> If you've had success with these, please let me know.  A friend wants to 
> setup a network but doesn't have access to the wall spaces in his house.
> Silly boy.
> 
> 



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



Re: ELF & putting inode at the front of a file

1999-12-06 Thread Zhihui Zhang


On Mon, 6 Dec 1999, Ronald G. Minnich wrote:

> On Mon, 6 Dec 1999, Zhihui Zhang wrote:
> > I am doing some research on filesystem.  I guess it may be faster to put
> > the disk inode with its file data together so that both can be read into
> > memory in one I/O. 
> 
> I still don't get it. To get the file, you do a lookup. So the inode is in
> memory. The you call the handler for the executable. But the inode is in
> memory at this point  what am I missing?
> 

When you read the disk inode, the first part of the data of its
corresponding file is brought into the memory at the same time.

-Zhihui



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



HomePNA network cards

1999-12-06 Thread Wes Peters

Has anyone gotten one of these to work with the lnc driver in current?
Looking at the chip specs, it is supposed to be software compatible with
the PCNet PCI parts, but it sports the "home networking" PHY that are
not supported on other LANCE parts.

If you've had success with these, please let me know.  A friend wants to 
setup a network but doesn't have access to the wall spaces in his house.
Silly boy.

-- 
"Where am I, and what am I doing in this handbasket?"

Wes Peters Softweyr LLC
[EMAIL PROTECTED]   http://softweyr.com/


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



Re: ELF & putting inode at the front of a file

1999-12-06 Thread Poul-Henning Kamp

In message <[EMAIL PROTECTED]>, "Ronal
d G. Minnich" writes:
>On Mon, 6 Dec 1999, Zhihui Zhang wrote:
>> I am doing some research on filesystem.  I guess it may be faster to put
>> the disk inode with its file data together so that both can be read into
>> memory in one I/O. 
>
>I still don't get it. To get the file, you do a lookup. So the inode is in
>memory. The you call the handler for the executable. But the inode is in
>memory at this point  what am I missing?

The inode is not likely to be in memory for a news spool or similar.  Only
very recently used inodes are in memory actually.  They die with the vnode
which maybe still die to fast.

Putting the inode with the data saves a little less than one diskaccess
on average per file, which for truly random access filesystems is a good
thing.

--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED]   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


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



Re: ELF & putting inode at the front of a file

1999-12-06 Thread Ronald G. Minnich

On Mon, 6 Dec 1999, Zhihui Zhang wrote:
> I am doing some research on filesystem.  I guess it may be faster to put
> the disk inode with its file data together so that both can be read into
> memory in one I/O. 

I still don't get it. To get the file, you do a lookup. So the inode is in
memory. The you call the handler for the executable. But the inode is in
memory at this point  what am I missing?

ron



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



Re: Is part of user stack always mapped?

1999-12-06 Thread Luoqi Chen

> I was under the impression that this was a no-no & one should use
> copyin/copout & friends to access memory on users's stacks.  Although
> this appears to work on the i386, if I try this on the alpha I take a
> fatal trap when accessing *set.
> 
> So -- how does this work on the i386?  Is  the user's stack always
> mappeped into the kernel's address space?  Should it also work on the
> alpha? 
> 
On i386, under the current implementation, the kernel can directly access
curproc's address space (not just the stack, stack is used because we're
sure the spare space won't/shouldn't be used by the user application).
I don't know if the same is true for alpha, but this should definitely
be considered an implementation dependent feature. I wish there were some
other ways to bypass copyin/out in ioctls.

-lq


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



Re: ELF & putting inode at the front of a file

1999-12-06 Thread Julian Elischer



On Mon, 6 Dec 1999, Matthew Dillon wrote:

> :On Mon, 6 Dec 1999, Ronald G. Minnich wrote:
> :
> :> On Mon, 6 Dec 1999, Zhihui Zhang wrote:
> :> > I have modified FFS filesystem code to put the disk inode at the beginning
> :> > of a file, i.e, the logical block #0 of each file begins with 128 bytes of
> :> > its disk inode and the rest of it are file data. 
> :> 
> :> first question I have is, why?
> :
> :I am doing some research on filesystem.  I guess it may be faster to put
> :the disk inode with its file data together so that both can be read into
> :memory in one I/O. 
> :
> :-Zhihui
> 
> Not really.  The inode tends to wind up being cached by the system
> longer then file data, so placing it with the file data will not 
> help -- since it is already probably cached, the system generally doesn't
> have to read it off the disk more then once anyway, and in a heavily
> loaded system the system caching is sufficiently detached from the file
> data processing that it is actually more beneficial to group inodes 
> together (one disk read is able to cache many inodes all in one go).
> 
> Another problem is that things like 'ls -la' or 'find' have to stat files
> and if you put the inode at the beginning of the file you essentially
> distribute the inodes all over the cylinder group rather then concentrate
> all the inodes in one place.
> 
> p.s. I was wrong about it breaking mmap() - in fact offseting the file
> data on-disk will not break mmap().  But it will produce unaligned disk
> transfers and potentially extra seeking.

At Usenix 98 there was a paper on puting the inode in ht edirectory entry
for files with only one link.
that DID speed a lot of things up..

Puting the inode in "frag -1" is interesting, but the question remains of
how do you find the inode? I presume the directory entry needs to have the
actual disk block  in it..


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



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



Re: ELF & putting inode at the front of a file

1999-12-06 Thread Zhihui Zhang


On Mon, 6 Dec 1999, Julian Elischer wrote:

> how do you find the inode?

There is an inode address map to look up.  Each entry is four bytes.

-Zhihui



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



Re: ELF & putting inode at the front of a file

1999-12-06 Thread Zhihui Zhang


On Mon, 6 Dec 1999, Matthew Dillon wrote:

> :On Mon, 6 Dec 1999, Ronald G. Minnich wrote:
> :
> :> On Mon, 6 Dec 1999, Zhihui Zhang wrote:
> :> > I have modified FFS filesystem code to put the disk inode at the beginning
> :> > of a file, i.e, the logical block #0 of each file begins with 128 bytes of
> :> > its disk inode and the rest of it are file data. 
> :> 
> :> first question I have is, why?
> :
> :I am doing some research on filesystem.  I guess it may be faster to put
> :the disk inode with its file data together so that both can be read into
> :memory in one I/O. 
> :
> :-Zhihui
> 
> Not really.  The inode tends to wind up being cached by the system
> longer then file data, so placing it with the file data will not 
> help -- since it is already probably cached, the system generally doesn't
> have to read it off the disk more then once anyway, and in a heavily
> loaded system the system caching is sufficiently detached from the file
> data processing that it is actually more beneficial to group inodes 
> together (one disk read is able to cache many inodes all in one go).

I have read some papers.  People have put disk inode with its file data. 
For small files, they can be read into memory with one I/O.  In a
distributed filesystem, if a inode block (contains 8192/128 inodes) is
shared by multiple clients, it will hurt performance.

One such paper may be "A 64-bit, shared disk file system for Linux" 
available at http://www.globalfilesystem.org/Pages/gfspapers.html.  They
call it "stuffed dinode".  My understanding could be wrong though. 

 
> Another problem is that things like 'ls -la' or 'find' have to stat files
> and if you put the inode at the beginning of the file you essentially
> distribute the inodes all over the cylinder group rather then concentrate
> all the inodes in one place.

Yes. I have implemented most of the code.  I noticed the "ls -al" is slow
but "ls" is OK. 
 
> p.s. I was wrong about it breaking mmap() - in fact offseting the file
> data on-disk will not break mmap().  But it will produce unaligned disk
> transfers and potentially extra seeking.

Yes. The cp command may use mmap().  I modify the mmap() so that this
works. But this mmap() is done by the user, I can intercept it at the
mmap() system call.  As I said in my original email, the kernel uses
memory map internally to load an ELF object file. I have to let the kernel
know that there is a disk inode at the beginning of the ELF object file.
It is hard for me to identify what part of the code is affected and to
what extent.  I think there should be a way.

-Zhihui





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



Re: ELF & putting inode at the front of a file

1999-12-06 Thread Julian Elischer

how do you find the inode?



On Mon, 6 Dec 1999, Zhihui Zhang wrote:

> 
> On Mon, 6 Dec 1999, Ronald G. Minnich wrote:
> 
> > On Mon, 6 Dec 1999, Zhihui Zhang wrote:
> > > I have modified FFS filesystem code to put the disk inode at the beginning
> > > of a file, i.e, the logical block #0 of each file begins with 128 bytes of
> > > its disk inode and the rest of it are file data. 
> > 
> > first question I have is, why?
> 
> I am doing some research on filesystem.  I guess it may be faster to put
> the disk inode with its file data together so that both can be read into
> memory in one I/O. 
> 
> -Zhihui
> 
> 
> 
> 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: tmpfs .. ?

1999-12-06 Thread Peter Jeremy

On 1999-Dec-07 07:23:49 +1100, David Wolfskill wrote:
>>Date: Mon, 6 Dec 1999 10:13:50 -0800 (PST)
>>From: Matthew Dillon <[EMAIL PROTECTED]>
>
>>The actual problem is sendmail's constant *rescanning* of the directory.

Which I forgot about :-(.

>To the extent that the directory is populated, yes.  (Scanning an empty
>directory isn't an overwhelmingly resource-intensive operation.)

Not quite.  UFS directories only shrink when a new entry is created
and free blocks exist at the end.  This means there can be a large
number of emply blocks that need to be scanned.  (The worst case
is when all the files in a large directory are deleted - the directory
is empty, but hasn't shrunk).

[domain-specific queue directories]
>I submit that having sendmail use the separate queue directories in this
>fashion is rather more beneficial than post-processing the queue.  :-)

It would be interesting to see a comparison of the schemes under
heavy load + failure conditions.  I think Matt's approach has the
advantage of needing less tuning.

Peter


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



Re: PCI DMA lockups in 3.2 (3.3 maybe?)

1999-12-06 Thread Matthew Dillon

:> In otherwords, we should branch with the 4.1 release rather then the
:> 4.0 release.
:
:Sounds a lot like 3.x to me.  We didn't branch at 3.0 either, we
:branched one release afterwards and only after people threatened to
:mutiny if we didn't since the usual pattern up to that point had been
:to branch immmediate at the dot-zero.  It didn't seem to help, as your
:own complaints would indicate.
:
:- Jordan

Wait until 4.2?  I don't know the answer, Jordan, but I am reasonably
confident that an official stabiliziation period of a few months will
help a lot.  The circumstances of the 2.2.x -> 3.0 release (the 18 
months you quoted) were special and should never be repeated, but I
think it is precisely the fact that 2.2.x went on for so long that wound
up causing people to give up and start working on new stuff prior to
3.0.  This made 3.0 especially unstable.

So going to the 12 month schedule is a wonderful idea, but doesn't 
quite get there in my book.  There is no significant feature freeze 
prior to a .0 release which almost guarentees an unstable release.  
That's ok since we tell people that .0 is never stable.  But .1 has
to be stable and the only time we have to do it is between .0 and .1.

If we enforce a stabilizing period between .0 and .1 and branch at .1
rather then at .0, this combined with the 12 month schedule should result
in pretty damn good releases.

If we just do the 12 month schedule, I don't think it will produce as
good a result.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


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



Is part of user stack always mapped?

1999-12-06 Thread Andrew Gallatin



I've been getting the osf1ulator (alpha/osf1 abi ported from NetBSD
over a year ago) on its feet again after this fall's signal changes.
When looking closely at the emulators which are currently in the tree,
I notice that they are they directly dereferencing memory which was
allocated on the user's stack via stackgap_alloc() from within the
kernel.


stackgap_init()
{
#define szsigcode (*(curproc->p_sysent->sv_szsigcode))
return (caddr_t)(((caddr_t)PS_STRINGS) - szsigcode - SPARE_USRSPACE);
}

static __inline void *
stackgap_alloc(sgp, sz)
caddr_t *sgp;
size_t   sz;
{
void*p = (void *) *sgp;
*sgp += ALIGN(sz);
return p;
}

<...>
sigset_t *set;
caddr_t sg;

sg = stackgap_init();
set = stackgap_alloc(&sg, sizeof(sigset_t));
*set = p->p_sigmask;
<..>

I was under the impression that this was a no-no & one should use
copyin/copout & friends to access memory on users's stacks.  Although
this appears to work on the i386, if I try this on the alpha I take a
fatal trap when accessing *set.

So -- how does this work on the i386?  Is  the user's stack always
mappeped into the kernel's address space?  Should it also work on the
alpha? 

Apologies for wasting your time if I'm missing something obvious,

--
Andrew Gallatin, Sr Systems Programmer  http://www.cs.duke.edu/~gallatin
Duke University Email: [EMAIL PROTECTED]
Department of Computer Science  Phone: (919) 660-6590





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



Re: ELF & putting inode at the front of a file

1999-12-06 Thread Matthew Dillon

:On Mon, 6 Dec 1999, Ronald G. Minnich wrote:
:
:> On Mon, 6 Dec 1999, Zhihui Zhang wrote:
:> > I have modified FFS filesystem code to put the disk inode at the beginning
:> > of a file, i.e, the logical block #0 of each file begins with 128 bytes of
:> > its disk inode and the rest of it are file data. 
:> 
:> first question I have is, why?
:
:I am doing some research on filesystem.  I guess it may be faster to put
:the disk inode with its file data together so that both can be read into
:memory in one I/O. 
:
:-Zhihui

Not really.  The inode tends to wind up being cached by the system
longer then file data, so placing it with the file data will not 
help -- since it is already probably cached, the system generally doesn't
have to read it off the disk more then once anyway, and in a heavily
loaded system the system caching is sufficiently detached from the file
data processing that it is actually more beneficial to group inodes 
together (one disk read is able to cache many inodes all in one go).

Another problem is that things like 'ls -la' or 'find' have to stat files
and if you put the inode at the beginning of the file you essentially
distribute the inodes all over the cylinder group rather then concentrate
all the inodes in one place.

p.s. I was wrong about it breaking mmap() - in fact offseting the file
data on-disk will not break mmap().  But it will produce unaligned disk
transfers and potentially extra seeking.

-Matt



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



Re: PCI DMA lockups in 3.2 (3.3 maybe?)

1999-12-06 Thread Mike Smith

> I have some remarks about the issue. I donnot claim it is not a software 
> problem, but ...
> 
> 1) Given the actual differences between the ncr and sym drivers nowadays, 
> I would be surprised if the problem was due to a driver software bug.
> A difference could be that recent drivers may use PCI optimized
> transactions (Memory Write and Invalidate, Memory Read Multiple).

The problem has been seen manifesting under both the 'ncr' and 'sym' 
drivers.  The nature of the situation suggests that it may be a symptom 
of the techniques used to talk to the LSI parts in conjunction with some 
other bus circumstances,

> 2) In order to investigate some hardware problem, we need to know about
> the actual revision of PCI chips used on the system and to have access to
> correspondings errata listings. I can look into the ones I have (basically
> SYMBIOS chips), and into the specifications update of the 440BX that are
> available from Intel site, but I donnot have anything about the network
> board (neither I know of this board).

The symptoms seem to manifest across a range of part revisions; the Intel 
ethernet part involved is the 82558, for which not all data is available.

> 3) I donnot see the reasons that led to think the kernel stack having 
> been clobbered by some part involving the ncr/symbios chips, but may-be 
> a clear diagnosis exists.

This assumption stems from a diagnosis I performed some time back, and 
may have been independantly corroborated.  Analysis of a trap taken in 
the EtherExpress driver showed register contents which were inconsistent 
with the preceeding instruction stream, but consistent with the trap 
itself.  Given the highly repeatable nature of the trap, the only 
conclusions that I could come to were:

 - Something about the instruction sequence was triggering a failure in 
   the CPU causing corruption of the register file.

 - An interrupt was being taken at a particular point as a direct 
   consequence of some interaction between the ethernet and SCSI 
   hardware, and the interrupt handler was damaging the stack such that
   on return the register contents were restored as garbage.

In my original case, there were essentially only two common points of 
failure, both inside the 'fxp' driver, and both showing the same signs of 
register corruption.

> 4) Have all the pathes (PCI, memory,...) parity enabled and do
> corresponding parts parity checking ? 

We were using ECC memory and CPU cache in the case I was working with.  I 
don't _think_ that PCI parity would have helped here (the problem seemed 
too consistent to be a noise-related failure of that kind).

> 5) Did you give a try using normal IO instead of MMIO for the SYMBIOS chip 
> and the Network chip, if code allows ?
> MMIO may confuse drivers that are not aware of posted buffers. For example
> a PCI device driver that writes using MMIO to some IO register to ack
> something and then assumes the chip knows about is just wrong since the
> transaction can be posted (a read, dummy if needed, must be performed
> prior such an assumption). This also acts as barriers for drivers that are
> not clean about actual instruction and memory ordering.

I'm not sure how this sort of error would lead to stack corruption unless 
it resulted in a deferred PCI dma to a stack variable.

At any rate, if you're interested in looking at a kernel core from such a 
failure, I'm sure we can make one available to you.

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]




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



Re: PCI DMA lockups in 3.2 (3.3 maybe?)

1999-12-06 Thread Ed Hall

: you wrote:
: : I wrote:
: :4) Using a different SCSI driver (Peter managed to get a driver from 4.0
: :   hooked up under 3.3, and it survived two days of torture that would
: :   have toasted things within an hour using the stock driver; you'll have
: :   to ask him for details).
: 
: Ed, this is great stuff!
: 
: Are you sure about #4?  Is that the same ncr.c driver or something
: else?  There are only a few differences between the 3.x and 4.x
: /usr/src/sys/pci/ncr.c drivers.  Which Peter, Peter Wemm?

It was Peter Wemm.  I may be misunderstanding just what he did--trying
the 4.0 driver was just one several experiments he proposed and
performed.  And saying that it "worked" is provisional; two days of
testing strongly suggests that it reduced the problem with 3.3 to
acceptible levels for my application.  Is it truly a "fix?" I don't
know.

-Ed






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



Re: PCI DMA lockups in 3.2 (3.3 maybe?)

1999-12-06 Thread Matthew Dillon

:Well, I used to run -CURRENT in a commercial environment :-)
:
:And I got bashed here and elsewhere for doing it too.
:
:But, with the exception of some really egregious fuck-ups (on both my part
:and those of people who committed shit that didn't work AT ALL) it was, by
:far, the better option of those available.
:
:For quite some time there were special "hacks" that I had (primarily
:consisting of grabbing older versions of this module or that) to get
:around stupidities that were in the process of being resolved, and there
:were always things that I disabled or just didn't do because I knew they
:were broken.

This was an unfortunate consequence which I take partial blame for
in my little corner of the system -- but only partial blame.  It was
hard enough getting my stuff into -current with all the extra requirements
core forced onto me, I didn't want to have to go through the same hell
to get it MFC'd into -stable as well.  At one point at the beginning,
before the shit began to fly, I was actually considering only doing it
for -current but as more and more bugs were found it became clear that
if the stuff didn't get MFC'd into -stable soon it wouldn't at all.
By that time the shit was already flying and I just didn't want to
double it.  Maybe 80% of the bug fixes have been MFC'd -- the ones that
were easy to fix.  The other 20% can't be MFC'd without the rest of
the infrastructure in 4.x to support them.

I hope the same thing will not repeat for 4.x/5.x, even without an
enforced stabilizing period between 4.0 and 4.1 prior to branching
off.  However, I think that an enforced stabilizing period where 
*everyone* is concentrating on 4.1 for a couple of months would be 
extremely good for the project.

-Matt



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



Re: PCI DMA lockups in 3.2 (3.3 maybe?)

1999-12-06 Thread Jordan K. Hubbard

> In otherwords, we should branch with the 4.1 release rather then the
> 4.0 release.

Sounds a lot like 3.x to me.  We didn't branch at 3.0 either, we
branched one release afterwards and only after people threatened to
mutiny if we didn't since the usual pattern up to that point had been
to branch immmediate at the dot-zero.  It didn't seem to help, as your
own complaints would indicate.

- Jordan


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



Re: PCI DMA lockups in 3.2 (3.3 maybe?)

1999-12-06 Thread Matthew Dillon

:I tell you, it's just not possible to win, especially when those doing
:the most yelling are always conspicuously absent when crunch time
:comes.  Matt wasn't really fully on board at the time and I'm not
:pointing my finger at him specifically, but it seems like everyone's
:hindsight is 20-20 whereas their immediate vision concerning what
:needs to be fixed in a timely fashion often comes closer to the legal
:definition of blindness.  If you want to make this or any other branch
:a decent release target, the time to start is not 10 days before it
:enters a feature freeze, the time to start is right after it branches!
:It's my hope that people will take this lesson more to heart when 4.0's
:own time to branch comes up.
:
:- Jordan

Perhaps I should rephrase:  The system was branched without any 
significant stabilizing period afterwords.  It was a holy mess.

What I am suggesting is that we have an enforced stabilizing period 
after the 4.0 release BEFORE we branch 5.0 that is long enough to 
actually get feedback and stabilize the system using that feedback.

In otherwords, we should branch with the 4.1 release rather then the
4.0 release.

3 or 4 months seems about right to me.  There are no projects which are
going to get so far along that we can't wait 4 months to commit the
patchsets (here I am talking about SMP and VFS).  It gives everyone
(including me) a chance to relax a bit and work on stabilizing what we 
have for the 4.1 release rather then going off and messing around with 
personal projects.  While it is true that self-discipline can accomplish
the same thing, I think having an official enforcing framework will yield
much better results in an open-source project.

I would also like to point out that doing this reduces the MFCing load
as well,  When 3.0 was released and we branched 4.x, many of us (including
me) had to deal with issues relating to all *THREE* branches for a long
time.  While this doesn't entirely go away, waiting a few months to branch
after a .0 release will allow people to continue to concentrate on the
two existing branches for a little while and get them shipshape prior to
starting work on a new branch.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>



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



Re: PCI DMA lockups in 3.2 (3.3 maybe?)

1999-12-06 Thread Gerard Roudier



I have some remarks about the issue. I donnot claim it is not a software 
problem, but ...

1) Given the actual differences between the ncr and sym drivers nowadays, 
I would be surprised if the problem was due to a driver software bug.
A difference could be that recent drivers may use PCI optimized
transactions (Memory Write and Invalidate, Memory Read Multiple).

2) In order to investigate some hardware problem, we need to know about
the actual revision of PCI chips used on the system and to have access to
correspondings errata listings. I can look into the ones I have (basically
SYMBIOS chips), and into the specifications update of the 440BX that are
available from Intel site, but I donnot have anything about the network
board (neither I know of this board).

3) I donnot see the reasons that led to think the kernel stack having 
been clobbered by some part involving the ncr/symbios chips, but may-be 
a clear diagnosis exists.

4) Have all the pathes (PCI, memory,...) parity enabled and do
corresponding parts parity checking ? 

5) Did you give a try using normal IO instead of MMIO for the SYMBIOS chip 
and the Network chip, if code allows ?
MMIO may confuse drivers that are not aware of posted buffers. For example
a PCI device driver that writes using MMIO to some IO register to ack
something and then assumes the chip knows about is just wrong since the
transaction can be posted (a read, dummy if needed, must be performed
prior such an assumption). This also acts as barriers for drivers that are
not clean about actual instruction and memory ordering.

Just my 0.02 euros.

GĂ©rard.  

On Sun, 5 Dec 1999, Mike Smith wrote:

> > On a recent project I encountered two show-stopping bugs with 3.3-release
> > that did not exist in 2.2.8-release:
> > 
> > 1) Random crashes in FXP interrupt or low-level IP code.  Something is
> >clobbering the kernel stack--possibly the NCR driver, since using an
> >Adaptec made the problem stop, as did a backport of the CAM driver
> >Peter Wemm tried.  This was on an N440BX, which is becoming quite
> >common in server applications.  Other installations are apparantly
> >seeing the same problem on this hardware.
> 
> So far the problem appears to require a combination of the 440BX chipset, 
> an Intel EtherExpress and the 'fxp' driver, and an NCR/Symbios/LSI SCSI 
> adapter and either the 'ncr' or 'sym' driver.  We've tried on a number of 
> occasions to diagnose this problem, but there have been many issues that 
> have prevented it's resolution.  These have included lack of interest on 
> the driver developers' parts, lack of access to or cooperation from 
> people complaining of the bug, and an inability to reproduce it in a 
> useful fashion.  It's been an eye-opening exercise and we're trying to 
> learn what we can from it, as well as actually fix it for good.
> 
> > 2) A hard loop in the pagedaemon.  This was especially egregious, since
> >it meant the system had to be rebooted from the console--and since
> >the application could elicit the problem within a few minutes.
> >Disabling the use of mmap() for file update in the application
> >prevented the problem.  After spending a day trying to cook up a
> >test program that elicited the same behavior that the application
> >did, I gave up for lack of time.  But there have been other reports
> >of late that sound like this problem, mostly in high VM/RAM situations.
> > 
> > That's two serious bugs that exist in 3.3-release but not in 2.2.8-release.
> > Looking back through the archives, I can see that I'm not the only one who
> > has experienced them.  I came away from the experience with the feeling that
> > the FreeBSD project has some serious Q/A problems... and I can assure you,
> > I'm not alone in this feeling.
> 
> Neither are we.  But, since FreeBSD is a volunteer-developed project, and 
> since you admit above that you have contributed to the lack of QA, I'm 
> not entirely sure what your point is.  We need this feedback in a timely 
> fashion in order to do something with it.  3 months after a release is 
> not "timely" by any stretch of the imagination, and without that sort of 
> assistance, I have no idea what you think we can do to improve the 
> situation.
> 
> Yes, we want to improve our QA.  But when customers come up months after 
> the fact and complain about something that we could never possibly have 
> either known or even guessed about during the development process, the 
> best we can do is try to fix the problem then and there.  If you want to 
> improve that situation, you can; in your position you have plenty of 
> opportunities to make a major contribution to the overall quality of 
> FreeBSD releases.  OTOH, if you choose not to do so, it's mere honesty to 
> observe that you need to take a share of the blame for the current 
> situation.
> 
> ps: The N440BX is actually being phased out, however there are very large 
> numbers of them still in

Re: ELF & putting inode at the front of a file

1999-12-06 Thread Matthew Dillon

:On Mon, 6 Dec 1999, Zhihui Zhang wrote:
:> I have modified FFS filesystem code to put the disk inode at the beginning
:> of a file, i.e, the logical block #0 of each file begins with 128 bytes of
:> its disk inode and the rest of it are file data. 
:
:first question I have is, why?
:
:ron

Good god, is he joking?  Offsetting the entire file by 128 bytes will
break mmap() and make I/O extremely inefficient.

Many filesystems over the years have mixed meta-data in the file data
blocks on disk only to remove it later on when it was found to destroy
performance.  A good example of this is the Amiga's filesystem.  The 
Amiga's old filesystem was emminently recoverable because each data
block had a backpointer, but it was so inefficient due to all the copying
required that the updated filesystem removed the metadata so disk blocks
could be DMA'd directory into the buffer.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


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



Re: tty level buffer overflows

1999-12-06 Thread Warner Losh

In message <[EMAIL PROTECTED]> Mike Smith writes:
: Growing the buffer isn't the solution; it should be big enough already.  
: We need to work out why a system that should have no trouble with the 
: data rate in question is croaking so trivially.

Growing the buffer is a solution.  I only get a few of these very
rarely which tells me that the system is keeping up 99.999% of the
time.  Increasing the buffer size will, statistically speaking,
increase that by another .0009%, which is all I'm looking for.
Growing the buffer will allow the amont of latency in the worst case
to expand, which is what I want.  Also, it will work around the
problem until I can get a better solution

At least for my setup.  I have a 486DX2-66 with lots of filter rules.
I suspect that what is happening is lots of tiny packets are coming
in which is causing increased latency in some cases.

Warner



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



Re: tmpfs .. ?

1999-12-06 Thread Matthew Dillon


:>Date: Mon, 6 Dec 1999 10:13:50 -0800 (PST)
:>From: Matthew Dillon <[EMAIL PROTECTED]>
:
:>The actual problem is sendmail's constant *rescanning* of the directory.
:
:To the extent that the directory is populated, yes.  (Scanning an empty
:directory isn't an overwhelmingly resource-intensive operation.)
:...
: (lots of good stuff removed)
:...
:-- 
:David Wolfskill[EMAIL PROTECTED] UNIX System Administrator

It's an O(N^2) failure mode.  If your sendmail gets overloaded then queue 
files build up which in turn make sendmail less efficient.  The
result is a cascade failure - where the mail queue directory gets
so large that it cannot recover even when the load drops back down to
normal.  We had dozens and dozens of such failures at BEST before I
went to the multi-queue method.

This obviously only applies to servers that have a lot of mail volume.
When you are getting four or five emails a second at peak and something
out of your control goes down, the queue can build up very rapidly.

I will also note that the problem is exasperated by FreeBSD's current
use of malloc buffers instead of the VM cache to cache directories.  Once
any given directory gets too large, the machine suddenly starts going to
disk every time you scan it!  In 4.x you can turn on VMIO backing for
directories (sysctl -w vfs.vmiodirenable=1).  It isn't on by default
only due to a bug somewhere in softupdates that causes an occassional
panic, apart from that all the necessary work has been done (by yours
truely, of course :-)).


-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>



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



Re: ELF & putting inode at the front of a file

1999-12-06 Thread Zhihui Zhang


On Mon, 6 Dec 1999, Ronald G. Minnich wrote:

> On Mon, 6 Dec 1999, Zhihui Zhang wrote:
> > I have modified FFS filesystem code to put the disk inode at the beginning
> > of a file, i.e, the logical block #0 of each file begins with 128 bytes of
> > its disk inode and the rest of it are file data. 
> 
> first question I have is, why?

I am doing some research on filesystem.  I guess it may be faster to put
the disk inode with its file data together so that both can be read into
memory in one I/O. 

-Zhihui



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



Re: PCI DMA lockups in 3.2 (3.3 maybe?)

1999-12-06 Thread Karl Denninger

On Mon, Dec 06, 1999 at 12:19:20PM -0800, Matthew Dillon wrote:
> :>:the problem, we can not address it.  please provide this information
> :>:if it is available to you. if it is not, please provide us contact
> :>:information for the commercial entities experiencing the problem.
> :>:
> :>:jmb
> :>
> :>First, the statement was anecdotal -- all of the problems have been
> :>fixed in -current.  
> :
> :THIS is EXACTLY what I was saying. What good does it do anyone in a
> :commercial environment that its fixed in -current? Thats the reason we
> :dumped NetBSD, because everyone was using -current the the releases were
> :always unstable. 
> :
> :Of course moving to -current to fix the problems in 3.x introduce a whole
> :new set of problems, in which case you have an OS that is never going to be
> :stable. When 4.0 is released we'll be told that the problems of 4.0 are
> :fixed in -current. When does it end?
> :
> :DB
> 
> I think the solution here is to change the release mechanism slightly.
> I believe we made a huge mistake splitting of the 4.x tree from 3.x 
> so early.
> 
> This time around I think that we should *not* split the tree for
> four months or so.  That is, have a period of 4 months where there is
> only 4.x, no 5.x.

Well, I used to run -CURRENT in a commercial environment :-)

And I got bashed here and elsewhere for doing it too.

But, with the exception of some really egregious fuck-ups (on both my part
and those of people who committed shit that didn't work AT ALL) it was, by
far, the better option of those available.

For quite some time there were special "hacks" that I had (primarily
consisting of grabbing older versions of this module or that) to get
around stupidities that were in the process of being resolved, and there
were always things that I disabled or just didn't do because I knew they
were broken.

But, by and large, this was a very solid and appropriate path FOR ME.

It *DOES* require TWO machines for testing purposes - one of which has the
code base on it, and a second that can be "sacrificed" and reloaded if you
really get your shorts in a knot.  You also need to keep a known-good
release around "just in case" you need to roll back after you commit
a roll-forward.

But, for me at least, I was happy with this path, despite the few instances
over the years where I got bit in the ass by it.

I truly believe I would have had MORE chunks out of my ass trying to run
STABLE in the same world.

And, today, I STILL live by that credo.  My primary home machine, which is
a production system in every sense of the word, runs CURRENT, although
at this point the kernel is a few months old (I've had no reason to upgrade
it recently, although I do peruse the "sys" commitlogs at least weekly). :-)

--
-- 
Karl Denninger ([EMAIL PROTECTED])  Web: http://childrens-justice.org
Isn't it time we started putting KIDS first?  See the above URL for
a plan to do exactly that!


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



Re: PCI DMA lockups in 3.2 (3.3 maybe?)

1999-12-06 Thread Jordan K. Hubbard

> I've been with BSD a long time--from back when my email address was
> decvax!randvax!edhall.  I want it to succeed, for reasons that are more
> emotional than rational; my nightmare was having to say that my project
> (1) worked on Solaris, (2) worked on Linux, but (3) broke FreeBSD.

And I hope that you'll not hesitate to chime in the next time you run
into a problem and not just wait for it to become the flame topic of
the week. :-)

If you have a hard time getting responses out of our developers, I'm
also happy to offer my own phone numbers (both of which are in my
finger entry at freebsd.org) and email address as a point of contact
if something seems to be stuck and you need it fast-tracked.  This is
no more or less than I'd offer to anyone else in your position and I
hope you realize that some people around here are more than willing to
go the extra mile, with or without what others might consider a
"proper bug report."

- Jordan


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



Re: PCI DMA lockups in 3.2 (3.3 maybe?)

1999-12-06 Thread Matthew Dillon

:I've confirmed that neither problem exists in 4.0.  There are ample
:work-arounds, both hardware and software, including just not using 3.3.
:No fixes, though, just work-arounds...  Workarounds for the NCR/FXP
:issue included:
:
:1) Using 2.2.8 (4.0 isn't a production option).
:2) Using a different NIC (a Tulip worked fine).
:3) Using a different SCSI adapter (Adaptec, as Matt suggested, works fine).
:4) Using a different SCSI driver (Peter managed to get a driver from 4.0
:   hooked up under 3.3, and it survived two days of torture that would
:   have toasted things within an hour using the stock driver; you'll have
:   to ask him for details).

Ed, this is great stuff!

Are you sure about #4?  Is that the same ncr.c driver or something
else?  There are only a few differences between the 3.x and 4.x
/usr/src/sys/pci/ncr.c drivers.  Which Peter, Peter Wemm?

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


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



Re: PCI DMA lockups in 3.2 (3.3 maybe?)

1999-12-06 Thread Jordan K. Hubbard

> I think the solution here is to change the release mechanism slightly.
> I believe we made a huge mistake splitting of the 4.x tree from 3.x 
> so early.

I was going to make a point about this, but thank you for making it
for me. :-)

My point was going to be that it was clearly not possible to please
even a large fraction of the FreeBSD user base with respect to
scheduling and Matt's statement above only underscores that in
flashing neon.  Those who were actually around at the time will
remember that the -current branch had already gone "dot zero" with 3.0
and still we refused to branch 3.x-stable, despite great public
pressure to do so.  More months went by and finally the -current
branch was running on 18 months with no branch, many feeling compelled
to comment that we were supposed to "roll over" every 12 months and
that this extra 6 month delay was unconscionable.

Many arguments about how we were holding up progress and that
volunteers were going to start wandering off to other *BSD projects
were raised, along with more dire predictions, and finally enough was
enough and we set a date by which all the late committers should get
their stuff in so that we could finally branch the sucker.  We did so
and there was much rejoicing, at least up until now when various folks
felt compelled to creatively reinterpret history and turn an
"unconscionable delay" into a "precipitous rush to branch."

I tell you, it's just not possible to win, especially when those doing
the most yelling are always conspicuously absent when crunch time
comes.  Matt wasn't really fully on board at the time and I'm not
pointing my finger at him specifically, but it seems like everyone's
hindsight is 20-20 whereas their immediate vision concerning what
needs to be fixed in a timely fashion often comes closer to the legal
definition of blindness.  If you want to make this or any other branch
a decent release target, the time to start is not 10 days before it
enters a feature freeze, the time to start is right after it branches!
It's my hope that people will take this lesson more to heart when 4.0's
own time to branch comes up.

- Jordan


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



Re: tty level buffer overflows

1999-12-06 Thread Matthew Jacob


> > 
> > > Er, you should read the sio(4) manpage too.  tty-level buffer overflows 
> > > have nothing to do with interrupt latency/execution time.
> > 
> > You mean this:
> > 
> >  sio%d: tty-level buffer overflow.  Problem in the application.  Input has
> >  arrived faster than the given module could process it and some has been
> >  lost.
> 
> Yup. Ignore the "problem in the application" part, as that predicates 
> that the kernel and driver are working properly, which doesn't seem to be 
> the case.  The problem here is that the buffer between the top side of 
> the driver and the application isn't being drained fast enough.  It would 
> be educational to know what the app is sleeping on when these messages 
> are emitted; just dropping to ddb and using 'ps' would probably be 
> enough.  There has to be some reason that the process is either not being 
> woken when data arrives, or is being held up somewhere else for long 
> enough that the clist overflows.

That's tough because it's transitory and hard to notice as I only rlogin
into this machine! Sounds to me a gdb breakpoint is what's needed, but
this is difficult to do for this machine.

> Does the problem still manifest with the recent scheduler changes?  
> Perhaps the comms processes are being unfairly scheduled against for some 
> reason?

The kernel is a November 12 kernel. Maybe it's better now. However, I'm
still staggering under the recent bdev changes - when everything has
settled down and all my other freebsd machines can boot all the way up and
are all up to date, I'll revisit this.





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



Linking problems w/ pthreads on 3.3

1999-12-06 Thread Viren Jain

NOTE: Please reply directly to my email address ([EMAIL PROTECTED])

Platform: x86, FreeBSD 3.3

While trying to link a threaded application with -pthread using the 
following command line:
gcc -I/usr/local/include -L/usr/local/lib/mysql -pthread -o impd daemon.o 
db.o handlers.o imp_list.o imp_util.o log.o main.o net.o opt.o request.o 
sig.o statsd.o util.o -lmysqlclient

I receive the following errors:

daemon.o(.text+0x10): undefined reference to `__pthread_fork'
db.o(.text+0x33c): undefined reference to `__pthread_sleep'
main.o(.text+0xce): undefined reference to `__pthread_detach'
net.o(.text+0x196): undefined reference to `__pthread_select'
net.o(.text+0x411): undefined reference to `__pthread_read'
net.o(.text+0x535): undefined reference to `__pthread_write'

Threaded libraries appear to be installed in /usr/lib (libc_r.a, libc_r.so, 
libc_r.so.3, and libc_r_p.a) and thus I am unsure of how to correct this 
problem. Any help or advice would be appreciated.

  -- Viren



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



Re: PCI DMA lockups in 3.2 (3.3 maybe?)

1999-12-06 Thread Bill Fumerola

On Mon, 6 Dec 1999, Dennis wrote:

> Of course moving to -current to fix the problems in 3.x introduce a whole
> new set of problems, in which case you have an OS that is never going to be
> stable. When 4.0 is released we'll be told that the problems of 4.0 are
> fixed in -current. When does it end?

A rose by any other name

4.0 will soon be 4.0-{RELEASE,STABLE} will it be okay for you to use then?

When does it end? Hopefully never.

-- 
- bill fumerola - [EMAIL PROTECTED] - BF1560 - computer horizons corp -
- ph:(800) 252-2421 - [EMAIL PROTECTED] - [EMAIL PROTECTED]  -






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



Re: Strange SCSI sickness

1999-12-06 Thread Wilko Bulte

As Matthew Jacob wrote ...
> 
> > Another interesting cause for problems is duff powersupplies. As the
> > proverb goes "every machine is as good as it's PSU". E.g. I just struggeled
> > with a DLT tape unit that inexplicable reset itself. After examining the
> > 5Volts rail with a scope I found glitches on it whenever the drive did a 
> > bit of rewinding (dropping out of streaming mode). Had me stumped for a
> > while.

> That's pretty rare these days. It used to happen all the time when
> switching power supplies first appeared (motorboating is what we called
> it), but even recently I had a marginal supply that supplied 4.4VDC-
> *just* enough to function *most* of the time.

This was a DLT4500 5 cartridge changer. I've seen multiple failures 
similar to this one due to degraded electrolytic output caps that made
the feedback circuitry of the switching PSU unhappy. DLT4500 has it's 
PSU stashed away in an ill ventilated spot, the fact that the heatsinks
are close to the output caps does not help either. Heat tends to kill
electr. caps.

Anyway, the topic at hand is more suitable for -hardware (or so) I guess.

Wilko
-- 
Wilko Bulte Arnhem, The Netherlands   - The FreeBSD Project 
WWW : http://www.tcja.nl  http://www.freebsd.org


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



Re: tmpfs .. ?

1999-12-06 Thread Lyndon Nerenberg

> :The main problem is that sendmail
> places all queue files (and there :are several for each
> undelivered message) in one directory

Sendmail 8.10 addresses this by allowing for multiple queue directories.

--lyndon


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



Re: tty level buffer overflows

1999-12-06 Thread Mike Smith

> In message <[EMAIL PROTECTED]> Mike Smith writes:
> : It's documented in the sio(4) manpage, which is always worth reading.
> 
> Even reading the sio manpage is unclear.  All it says is that things
> are too slow.  Steady state I don't get these, just every now and
> again it happens.  No apparent correlation to the time of day, cron
> jobs running, etc.
> 
> What I was wondering is if there is a way to, say, double the buffer
> size.  Also, what is the number of overflows mean?  Is that bytes?
> clists?  16byte chunks?  The overflow seems to happen just once and it
> is always a number less than 1000.  I'd gladly spend an extra 1-2k of
> memory to help my poor ppp machine over the humps.

Growing the buffer isn't the solution; it should be big enough already.  
We need to work out why a system that should have no trouble with the 
data rate in question is croaking so trivially.

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]




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



Re: ELF & putting inode at the front of a file

1999-12-06 Thread Ronald G. Minnich

On Mon, 6 Dec 1999, Zhihui Zhang wrote:
> I have modified FFS filesystem code to put the disk inode at the beginning
> of a file, i.e, the logical block #0 of each file begins with 128 bytes of
> its disk inode and the rest of it are file data. 

first question I have is, why?

ron



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



Re: tmpfs .. ?

1999-12-06 Thread David Wolfskill

>Date: Mon, 6 Dec 1999 10:13:50 -0800 (PST)
>From: Matthew Dillon <[EMAIL PROTECTED]>

>The actual problem is sendmail's constant *rescanning* of the directory.

To the extent that the directory is populated, yes.  (Scanning an empty
directory isn't an overwhelmingly resource-intensive operation.)

>So you don't really need to hack sendmail to fix it though it would be
>nice if sendmail built the feature in.  What you want to do is move the
>queue file to a queue directory based on the number of retries that have
>occured on the queue file.  You then run fewer sendmail -q's on the
>directories representing higher retry counts and more sendmail's on the
>directories representing lower retry counts.  

Actually, for a certain class of intended recipients, some of my
colleagues & I have been working on (and support, in a production
environment) some changes to sendmail to have sendmail (create and) use
domain-specific queue directories.

The class of recipients is that set that is intended to retrieve mail
via the SMTP "ETRN" command.

I submit that having sendmail use the separate queue directories in this
fashion is rather more beneficial than post-processing the queue.  :-)

For those in the SF Bay area, I'll be giving a "short but cool" talk at
the December (16th) BayLISA meeting about what we did.

We were too late to get the code included in sendmail 8.10, but we
expect it will be contributed back to sendmail.org in time to be part of
8.11.

Cheers,
david
-- 
David Wolfskill [EMAIL PROTECTED] UNIX System Administrator
voice: (650) 577-7158   pager: (888) 347-0197   FAX: (650) 372-5915


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



Re: PCI DMA lockups in 3.2 (3.3 maybe?)

1999-12-06 Thread Ed Hall

I've confirmed that neither problem exists in 4.0.  There are ample
work-arounds, both hardware and software, including just not using 3.3.
No fixes, though, just work-arounds...  Workarounds for the NCR/FXP
issue included:

1) Using 2.2.8 (4.0 isn't a production option).
2) Using a different NIC (a Tulip worked fine).
3) Using a different SCSI adapter (Adaptec, as Matt suggested, works fine).
4) Using a different SCSI driver (Peter managed to get a driver from 4.0
   hooked up under 3.3, and it survived two days of torture that would
   have toasted things within an hour using the stock driver; you'll have
   to ask him for details).

Workarounds for the pagedaemon issue included:

1) Using 2.2.8 (4.0, too, but not as a production option)
   (do I see a pattern?)
2) Using read()/write() instead of mmap() for certain file updates in
   our application.  In this case read()/write() performed better anyhow.

So the two issues I described are no longer "active" for the purposes
of my project.  I posted because I feared that what I saw as the main
issue--that 3.3 is regarded in some circles as not being up to FreeBSD
standards--was getting lost in various unseemly side-issues.  It could
be that I was just plain unlucky, but my experiences suggest that there
may be some merit to that view.  You be the judge.

I've been with BSD a long time--from back when my email address was
decvax!randvax!edhall.  I want it to succeed, for reasons that are more
emotional than rational; my nightmare was having to say that my project
(1) worked on Solaris, (2) worked on Linux, but (3) broke FreeBSD.
I'd be a pretty poor engineer to play favorites when the facts point
in another direction.  Fortunately, we were able to discover a more
favorable set of facts.  This time.

-Ed

:  Matthew Dillon <[EMAIL PROTECTED]> wrote:
: :You write:
: ::we can not identify the specific problem from this message.
: :: without sufficient information to indentify and hopefully reproduce
: :: the problem, we can not address it.  please provide this information
: :: if it is available to you. if it is not, please provide us contact
: :: information for the commercial entities experiencing the problem.
: :
: :I work at Yahoo.  My address there is "[EMAIL PROTECTED]".
: :
: :On a recent project I encountered two show-stopping bugs with 3.3-release
: :that did not exist in 2.2.8-release:
: :
: :1) Random crashes in FXP interrupt or low-level IP code.  Something is
: :   clobbering the kernel stack--possibly the NCR driver, since using an
: :   Adaptec made the problem stop, as did a backport of the CAM driver
: :   Peter Wemm tried.  This was on an N440BX, which is becoming quite
: :   common in server applications.  Other installations are apparantly
: :   seeing the same problem on this hardware.
: :
: :2) A hard loop in the pagedaemon.  This was especially egregious, since
: :   it meant the system had to be rebooted from the console--and since
: :   the application could elicit the problem within a few minutes.
: :   Disabling the use of mmap() for file update in the application
: :   prevented the problem.  After spending a day trying to cook up a
: :   test program that elicited the same behavior that the application
: :   did, I gave up for lack of time.  But there have been other reports
: :   of late that sound like this problem, mostly in high VM/RAM situations.
: :
: :That's two serious bugs that exist in 3.3-release but not in 2.2.8-release.
: :Looking back through the archives, I can see that I'm not the only one who
: :has experienced them.  I came away from the experience with the feeling that
: :the FreeBSD project has some serious Q/A problems... and I can assure you,
: :I'm not alone in this feeling.
: :
: : -Ed
: 
: Well, #2 at least should be fixed in -current.  Unfortunately the
: changes to the VM system were too extensive to backport to 3.x.  Or, 
: I should say, that at the time I started working on the VM system core 
: was not interested in allowing me to backport the changes, and then later
: it was simply too late - too many changes had been made.
: 
: #1 has come up a couple of times.  There was a conversation in October
: that closely relates to your problem:
: 
: :From: Joe McGuckin <[EMAIL PROTECTED]>
: :Subject:  fxp related kernel panic
: :
: :I have a 3.3-stable machine that I use as a news router (running diablo). The
: :fxp0 interface averages 10-15 Mbps bandwidth continously.
: :
: :About once a week the machine crashes & reboots. We enabled the debugger this ti
: :me
: :and captured the following debug output:
: :
: :Fatal trap 12: page fault while in kernel mode
: :fault virtual address   = 0x382e4641
: :fault code  = supervisor write, page not present
: :instruction pointer = 0x8:0xc01a372e
: :stack pointer   = 0x10:0xc02523b0
: :frame pointer   = 0x10:0xc02523c0
: :code segment= base 0x0, limit 0xf, type

Re: PCI DMA lockups in 3.2 (3.3 maybe?)

1999-12-06 Thread Matthew Dillon

:>:the problem, we can not address it.  please provide this information
:>:if it is available to you. if it is not, please provide us contact
:>:information for the commercial entities experiencing the problem.
:>:
:>:jmb
:>
:>First, the statement was anecdotal -- all of the problems have been
:>fixed in -current.  
:
:THIS is EXACTLY what I was saying. What good does it do anyone in a
:commercial environment that its fixed in -current? Thats the reason we
:dumped NetBSD, because everyone was using -current the the releases were
:always unstable. 
:
:Of course moving to -current to fix the problems in 3.x introduce a whole
:new set of problems, in which case you have an OS that is never going to be
:stable. When 4.0 is released we'll be told that the problems of 4.0 are
:fixed in -current. When does it end?
:
:DB

I think the solution here is to change the release mechanism slightly.
I believe we made a huge mistake splitting of the 4.x tree from 3.x 
so early.

This time around I think that we should *not* split the tree for
four months or so.  That is, have a period of 4 months where there is
only 4.x, no 5.x.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>



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



Re: PCI DMA lockups in 3.2 (3.3 maybe?)

1999-12-06 Thread Dennis

At 11:05 AM 12/6/99 -0800, you wrote:
>
>:
>:
>:[snip]
>:>   I am a good programmer and can fix things :-).  But I've had to deal
with
>:>   a number of nightmare situations by commercial entities deploying
FreeBSD 
>:>   and at least three (including one very recently) where commercial
entities 
>:>   have refused to upgrade past 2.2.x due to perceived stability problems.
>:[snip]
>:> 
>:> -Matt
>:> Matthew Dillon 
>:
>:  we can not identify the specific problem from this message.
>:without sufficient information to indentify and hopefully reproduce
>:the problem, we can not address it.  please provide this information
>:if it is available to you. if it is not, please provide us contact
>:information for the commercial entities experiencing the problem.
>:
>:jmb
>
>First, the statement was anecdotal -- all of the problems have been
>fixed in -current.  

THIS is EXACTLY what I was saying. What good does it do anyone in a
commercial environment that its fixed in -current? Thats the reason we
dumped NetBSD, because everyone was using -current the the releases were
always unstable. 

Of course moving to -current to fix the problems in 3.x introduce a whole
new set of problems, in which case you have an OS that is never going to be
stable. When 4.0 is released we'll be told that the problems of 4.0 are
fixed in -current. When does it end?

DB


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



Re: fxp, xl driver question .. (routing)(SOLVED)

1999-12-06 Thread kvandel

Mike-

> I should have summarised this by saying:  Correct use of the latency 
> timer will shorten your DMA bursts for you when necessary, giving you the 
> best of both worlds.  When it's safe to run a long burst, you will.  When 
> you need to push a device off the bus, that will happen too.
After re-reading the PCI System Architecture section.. you are correct.

The Text:
If the current master has exhausted its LT, still has its GNT# and has not yet
completed its burst transfer, it may retain ownership of the bus and continue
to burst data until either:
  a. it completes its overall burst transfer
  b. its GNT# is removed by the arbiter

In the latter case, the current master is permitted to complete one or more data
transfer and must then yield the bus.

My misunderstanding:
>From the wording in the text, it is ambiguous as whether the a "data transfer" 
is a frame(one adress cycle + multiple data cycles), or a data cycle.  

> And the obvious extension to the "worst case" calculation is that if you 
> have N master devices each with a latency timer of X, your worst-case 
> timing for CPU access to a device is (N * X) + (N * arb overhead), just 
> in case that wasn't clear.
Much better...

thanks,
kurt
> 
> -- 
> \\ Give a man a fish, and you feed him for a day. \\  Mike Smith
> \\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
> \\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]
-- 

uname -a > Linux wookie.vandelden.com 2.2.13 #1 <


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



Re: natd is jumpy

1999-12-06 Thread Ronald F. Guilmette


In message <[EMAIL PROTECTED]>, 
Nick Rogness <[EMAIL PROTECTED]> wrote:

>On Sun, 5 Dec 1999, Archie Cobbs wrote:
>
>> Brian Dean writes:
>> > No dropped packets, but definitely some occasional long delays before
>> > I get the echo.  However, I must concede, based on other respondants,
>> > that something else must be going on and I cannot necessarily
>> > attribute this to divert/firewall/natd.
>
>
>   I forgot to mention, are you connecting at V.90 speeds?  If so
>   renegotiations/retrains will take place and you will see a speed
>   jump or hesitation.  Disable this in the modem.  There are
>   specific S registers to do this...

Ummm yea!  That comment reminds me about all of the V.90 modem woes
I was experiencing awhile back.

I had an older Zoom 56k modem that seemed to work just fine with my _old_
ISP.  Then I changed ISPs, and I started to see frequent problems.  Some-
times the modem would just seem to take a little nap for about 30 seconds
or so.  (Perhaps it was doing that retraining/renegotiation thing.  I'm
not sure.)  But other times, I would just abruptly lose carrier for no
apparent reason.  (This was an external modem, so I could watch the
various LEDs.)

Of course, at first I blamed my new ISP.  I figured that _they_ were doing
something wrong because the modem had woked just fine with my prior ISP.
So I called them up and started giving their tech support folks a hard
time... in a friendly way of course. :-)

The only idea/theory/suggestion that they came up with was that I must
have a modem with Rockwell 56K chipset in it, and they said that they
had had a number of problems with people using Rockwell-based modems
because (they alleged) the Rockwell chipset was less than perfect, and
because it didn't play well with the Lucent-chipset-based stuff that
they had in their Portmasters.

OK, so I run down to the local computer store and I'm looking for a
_new_ V.90 modem with a *Lucent* chipset.  The only one they had was
a newer version of the same bloody Zoom modem I already have.  Now I
already don't like Zoom, because their tech support sucks, but I buy
one of these new Zoom modems with the Lucent chipset anyway.

Result:  I have _never_ had a single problem since.

The only problem I have now is finding the time to list the old (Rockwell-
based) modem on eBay. :-)

P.S.  Please DO NOT flame me for any of the above.  I most definitely
DO NOT own stock in either Lucent or Rockwell, and I would be the first
one to admit that I have absolutely NO IDEA for sure what exactly was
causing my earlier problems with the Rockwell-based Zoom modem.  For
all I know, it was working fine and I just had it configured wrong.
I'm just telling the story, as it happened.

P.P.S.  More info:

Model # of old modem: Zoom 2849
Model # of new modem: Zoom 2949L



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



ELF & putting inode at the front of a file

1999-12-06 Thread Zhihui Zhang


I have modified FFS filesystem code to put the disk inode at the beginning
of a file, i.e, the logical block #0 of each file begins with 128 bytes of
its disk inode and the rest of it are file data. 

Everything seems to be working.  But I am stuck with an ELF executable
file stored in this layout - I can not run it.  The kernel uses memory map
to read the ELF file and assumes that the file data begins at offset 0. I
have looked at the files kern_exec.c and imgact_elf.c trying to adjust the
header pointers by an offset of 128 bytes to at least let the kernel
recognize that it is an ELF file. But still I got messages like "too few
PT_LOAD segments".  Obviously, I need to modify the kernel files
elsewhere, perhaps those under directory contrib/rtld-elf/*, which I have
never read before. 

My questions are:

(1) What consequences will my file layout affect the load and execution of
an ELF file?  Do I have to adjust the virtual addresses in the ELF object
file as well?

(2) If I modify any files under contrib/rtld-elf, how to make the
modifications take effect.  Is that as simple as "make" and followed by
"make install". 

I am new to these kernel stuff.  Any help or hints are very appreciated. 

-Zhihui



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



Re: Strange SCSI sickness

1999-12-06 Thread Matthew Dillon


:>treatment, in roughly this order:
:> 
:>3a) Complete check of all cables and the seating of connectors.
:> 
:>3b) Examination of the drive(s) in question for any cooling or
:>mounting deficiencies.  Depending on the SCSI errors in question,
:>I might even investigate firmware updates for the drive(s).
:> 
:>3c) Examination of the controller for correct seating and bus slot
:>(in older PCI mobos, this makes a difference) as well as its
:>firmware revision level.
:> 
:
:3d)Any system experiencieng scsi parity errors should have all components
:   power cycled (for self healing termpwr- fuses) and any pluggable
:   termpwr fuses checked (these are exceedingly rare now- but if you
:   had a SparcStation, they'd be the first thing to check- they're next
:   to the ethernet connector on the motherboard). If you're not using
:   an active terminator, you should be. Check for multiple termination-
:   both ends of the bus must have termination enabled, nothing else-
:   check drive and hba. If necessary, derate off of Ultra to Fast to
:   see if this was the source of problems.
:
:[ a parity error indicates trashed signals. a parity error in data phase
:indicates signal reflection, skew, or rise time problems. signal quality
:is greatly affected by: bus length, termination, cable impedance mismatches ]

Only buy terminators with terminator-power LEDs, and only use external
terminators (it makes it easier to maintain the drives).

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


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



Re: PCI DMA lockups in 3.2 (3.3 maybe?)

1999-12-06 Thread Matthew Dillon

:Matthew Dillon wrote:
:> :
:> :All running software has serious problems, that's why it is never considered
:> :done.  Taking the time to enumerate specific problems that are currently
:> :plaguing an installation is the only way anyone can possibly hope to help.
:> :Problems reports of "It don't work" are helpful to absolutely noone.
:> 
:> This simply isn't true.  I have written plenty of software (large
:> projects) that do not have serious problems and, in fact, some do not
:> have any known problems at all.  I have written several operating systems
:> and one of them is least as complex as the FreeBSD core (but not as
:> complex if you count drivers) which are bug-free (that is, there have
:> been no recorded crashes and except for feature updates have never been
:> rebooted).
:
:So you haven't discovered the rest of the bugs in the system.  Software
:is created by humans, and humans are fallible, therefore the software
:is also fallible.  Any claims of divinity on your part will be summarily
:rejected.
:
:-- 
:"Where am I, and what am I doing in this handbasket?"
:
:Wes Peters Softweyr LLC

You are missing the point big time, Wes.  Just because you can make
the statement that "no software is without bugs" does not justify 
having software that has a *LOT* of bugs.  It is possible to write
robust software.  Would you rather have Windows?

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


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



Re: PCI DMA lockups in 3.2 (3.3 maybe?)

1999-12-06 Thread Matthew Dillon


:You write:
::  we can not identify the specific problem from this message.
:: without sufficient information to indentify and hopefully reproduce
:: the problem, we can not address it.  please provide this information
:: if it is available to you. if it is not, please provide us contact
:: information for the commercial entities experiencing the problem.
:
:I work at Yahoo.  My address there is "[EMAIL PROTECTED]".
:
:On a recent project I encountered two show-stopping bugs with 3.3-release
:that did not exist in 2.2.8-release:
:
:1) Random crashes in FXP interrupt or low-level IP code.  Something is
:   clobbering the kernel stack--possibly the NCR driver, since using an
:   Adaptec made the problem stop, as did a backport of the CAM driver
:   Peter Wemm tried.  This was on an N440BX, which is becoming quite
:   common in server applications.  Other installations are apparantly
:   seeing the same problem on this hardware.
:
:2) A hard loop in the pagedaemon.  This was especially egregious, since
:   it meant the system had to be rebooted from the console--and since
:   the application could elicit the problem within a few minutes.
:   Disabling the use of mmap() for file update in the application
:   prevented the problem.  After spending a day trying to cook up a
:   test program that elicited the same behavior that the application
:   did, I gave up for lack of time.  But there have been other reports
:   of late that sound like this problem, mostly in high VM/RAM situations.
:
:That's two serious bugs that exist in 3.3-release but not in 2.2.8-release.
:Looking back through the archives, I can see that I'm not the only one who
:has experienced them.  I came away from the experience with the feeling that
:the FreeBSD project has some serious Q/A problems... and I can assure you,
:I'm not alone in this feeling.
:
:   -Ed

Well, #2 at least should be fixed in -current.  Unfortunately the
changes to the VM system were too extensive to backport to 3.x.  Or, 
I should say, that at the time I started working on the VM system core 
was not interested in allowing me to backport the changes, and then later
it was simply too late - too many changes had been made.

#1 has come up a couple of times.  There was a conversation in October
that closely relates to your problem:

:From: Joe McGuckin <[EMAIL PROTECTED]>
:Subject:  fxp related kernel panic
:
:I have a 3.3-stable machine that I use as a news router (running diablo). The
:fxp0 interface averages 10-15 Mbps bandwidth continously.
:
:About once a week the machine crashes & reboots. We enabled the debugger this ti
:me
:and captured the following debug output:
:
:Fatal trap 12: page fault while in kernel mode
:fault virtual address   = 0x382e4641
:fault code  = supervisor write, page not present
:instruction pointer = 0x8:0xc01a372e
:stack pointer   = 0x10:0xc02523b0
:frame pointer   = 0x10:0xc02523c0
:code segment= base 0x0, limit 0xf, type 0x1b
:= DPL 0, pres 1, def32 1, gran 1
:processor eflags= interrupt enabled, resume, IOPL = 0
:current process = Idle
:interrupt mask  = net
:kernel: type 12 trap, code=0
:Stopped at  fxp_add_rfabuf+0x1de:   movw%ax,0x4(%esi)
:db> 
:
:%uname -a
:FreeBSD feeder.via.net 3.3-STABLE FreeBSD 3.3-STABLE #7: Mon Oct 18 17:14:40 PDT
: 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/DIABLO  i386
:
:%dmesg
:Copyright (c) 1992-1999 FreeBSD Inc.
:Copyright (c) 1982, 1986, 1989, 1991, 1993
:The Regents of the University of California. All rights reserved.
:FreeBSD 3.3-STABLE #7: Mon Oct 18 17:14:40 PDT 1999

To which DG responded:

:From: David Greenman <[EMAIL PROTECTED]>
:Subject:  Re: fxp related kernel panic 
:To:   Joe McGuckin <[EMAIL PROTECTED]>
:Cc:   [EMAIL PROTECTED], [EMAIL PROTECTED]
:Date: Tue, 26 Oct 1999 11:43:02 -0700
:
:
:   Let me guess...your system has an Intel N440BX motherboard, right? If so,
:then it's a known problem with no solution yet.
:
:-DG
:
:David Greenman
:Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org
:Creator of high-performance Internet servers - http://www.terasolutions.com
:Pave the road of life with opportunities.

And he also said:

:From: David Greenman <[EMAIL PROTECTED]>
:Subject:  Re: fxp related kernel panic 
:To:   Lew Payne <[EMAIL PROTECTED]>
:Cc:   [EMAIL PROTECTED], Joe McGuckin <[EMAIL PROTECTED]>
:Date: Tue, 26 Oct 1999 13:19:45 -0700
:
:
:>Hi David -- What if I install a *real* EtherExpress Pro-100B (or
:>whatever it's known as today) in the PCI slot, and use it instead
:>of the on-board (N440BX motherboard) fxp0 interface?
:>
:>Judging that you probably know the nature of the problem, do you
:>think this might circumvent it?
:
:   I think it is caused by the NCR/Symbios controller. It might be a side
:effect of the NCR just using up a lot of PCI bandwidth, wi

Re: tmpfs .. ?

1999-12-06 Thread Matthew Dillon

:On Sat, 04 Dec 1999 15:44:49 -0800, "Ronald F. Guilmette" <[EMAIL PROTECTED]> wrote:
:>Specifically, I'm planning a large mail server... which will use Sendmail...
:>and I'd really like to allocate the Sendmail queue files... which typically
:>have a rather short lifespan... on/in some sort of filesystem (e.g. an
:>mfs or else this VN thing you are talking about) that would tend to give
:>petter performance than just using an ordinary disk-based filesystem.
:
:This doesn't sound like a good application for a temporary filesystem.
:Whilst the files do typically have a short lifetime, and there are lots
:of them, they represent mail items which your server has accepted
:responsibility for delivering.  Also, the queue files can potentially
:exist for several days (the default timeout is 5 days).
:
:I would suggest that UFS with softupdates represents a better performance/
:reliability tradeoff than MFS or a swap-backed vnode.
:
:The main problem is that sendmail places all queue files (and there
:are several for each undelivered message) in one directory - and very
:large directories are not handled particularly efficently by UFS.  The
:simple solutions are:
:1) switch to an alternative MTA that doesn't display this behaviour.
:2) hack sendmail to have multiple subdirectories within the main
:   queue directory - with the subdirectory chosen by hashing the
:   sendmail job id.
:
:Peter

The actual problem is sendmail's constant *rescanning* of the directory.
So you don't really need to hack sendmail to fix it though it would be
nice if sendmail built the feature in.  What you want to do is move the
queue file to a queue directory based on the number of retries that have
occured on the queue file.  You then run fewer sendmail -q's on the
directories representing higher retry counts and more sendmail's on the
directories representing lower retry counts.  

The retry count happens to be a field in the queue control file so it's
relatively easy to write a program to move queue files around baed on it.
You have to be sure you properly lock the queue file while renaming it,
of course, so you cannot (easily) use a script, and you have to test for
duplicate queue id's so you do not rename-over, but that's it.

Running sendmail's on multiple queues is trivial:

sendmail -q1m -OMaxDaemonChildren=50 
sendmail -q1m -OMaxDaemonChildren=20 -OQueueDirectory=
sendmail -q1m -OMaxDaemonChildren=10 -OQueueDirectory=
sendmail -q1m -OMaxDaemonChildren=5 -OQueueDirectory=
sendmail -q1m -OMaxDaemonChildren=5 -OQueueDirectory=
sendmail -q1m -OMaxDaemonChildren=5 -OQueueDirectory=
sendmail -q1m -OMaxDaemonChildren=5 -OQueueDirectory=
...

I used this trick at BEST and it works extremely well.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


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



Re: tmpfs .. ?

1999-12-06 Thread Matthew Dillon


:In message <[EMAIL PROTECTED]>, 
:Matthew Dillon <[EMAIL PROTECTED]> wrote:
:
:>Mail queue files are persistant enough (upwards of 5 days if a destination
:>is down)  that you run a real risk of losing something important if 
:>you crash and wipe.  I would not use MFS at all and I would only use VN
:>with persistant store, but the performance is going to be similar to
:>using a normal filesystem so it may not be worth doing.
:
:Yea, someone else I was talking with about this said the same thing.
:
:I just can't get over the nagging feeling that (for the mail spool
:directory) there ought to be something that is ultra-super-deluxe
:fast that I should be using. :-)
:
:>  Normal 
:>  filesystems with softupdates turned on make pretty good mail spools though
:
:OK, I've seen several mentions now of `softupdates', and I think that I
:have a general (vague?) notion of what `softupdates' is all about, but
:allow me to disaply my ignorance one more time and ask which man page
:(or document) I should be looking at to learn all of the specifics
:regarding `softupdates'.  (I looked at `man tunefs' and I don't see
:nuttin' there, so where exactly is/are `softupdates' documented?)

Softupdates requires a little kernel hacking.

cd /usr/src/sys/ufs/ffs 

read the README.softupdates file in that directory.  Don't worry about
Kirk's license until you actually decide you intend to use it in 
production on a commercial system.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


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



Re: vfs_bio questions/nfs cluster commit

1999-12-06 Thread Matthew Dillon

I haven't finished looking at the whole thing yet, but I see one
immediate (trivial to fix) problem:

+   BUF_LOCK(holdbp, LK_EXCLUSIVE))

I would recommend getting a *NON* blocking lock, and bumping your gap
mechanism if you can't get the lock (and not store the buffer).  Otherwise
you may create a deadlock situation elsewhere. 

-

Alred, in your followup email you said something about the existing
clustering being broken.  It seems to work for me (64KB clustering), could
you give me an example?  NFS clustering is based very heavily only VFS
clustering.  If you aren't seeing NFS clustering for commit messages then
perhaps VFS clustering got broken somehow...

-Matt

:I've been trying to workout mega-clusters for NFS, since afaik the
:vfs_cluster code will only do 64k chunks and we can benifit greatly
:by compacting ranges for commit RPCs.
:...
:
:Index: nfs_bio.c
:===
:RCS file: /home/ncvs/src/sys/nfs/nfs_bio.c,v
:retrieving revision 1.80
:...


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



Re: PCI DMA lockups in 3.2 (3.3 maybe?)

1999-12-06 Thread Matthew Dillon


:
:
:[snip]
:>   I am a good programmer and can fix things :-).  But I've had to deal with
:>   a number of nightmare situations by commercial entities deploying FreeBSD 
:>   and at least three (including one very recently) where commercial entities 
:>   have refused to upgrade past 2.2.x due to perceived stability problems.
:[snip]
:> 
:>  -Matt
:>  Matthew Dillon 
:
:   we can not identify the specific problem from this message.
:without sufficient information to indentify and hopefully reproduce
:the problem, we can not address it.  please provide this information
:if it is available to you. if it is not, please provide us contact
:information for the commercial entities experiencing the problem.
:
:jmb

First, the statement was anecdotal -- all of the problems have been
fixed in -current.  Second, these people posted their questions and 
problems on -hackers or -stable or -current and got not one useful 
response, then came to me privately and asked for help.  For you,
or anyone, to attempt to dismiss the statement by implying help after
the fact is bogus.  This being a freeware development project it is
perfectly ok to say "I can't help" or "I don't have time".  It is NOT
ok to imply help when none would otherwise be forthcoming.

Two commercial entities approached me on helping fix INN bugs.  Those
turned out to be related to a VM/mmap bug (2.x, 3.x, 4.x), which I fixed
in 4.x, and a swap bug (2.x, 3.x) which I couldn't fix in 2.x or 3.x
but which was already fixed in 4.x by the rewrite of the swap code I
had done earlier in the year.  This bug turned out to be a KVM 
fragmentation problem due to the large linear arrays that 2.x and 3.x
allocate for swap metadata.  I had another commercial entity approach
me in regards to dealing with low-memory lockup problems which, again,
I was unable to completely fix in 3.x but was able to fix in 4.x because
of the getnewbuf() rewrite.  I had another commercial entity approach me
in regards to the ps/procfs problem (before Poul went on his procfs
rampage) and I gave that person the workaround I used at BEST, which is
simply to flock() around the procfs code in /bin/ps to force serialization.

That's just the recent stuff, off the top of my head.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


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



Re: cdrom speed adjustment ioctl

1999-12-06 Thread Egervary Gergely

> I've just hacked a new ioctl into the ATAPI cdrom driver, which
> lets the user to specify (pronounce: ``slow down'' :) the speed 
> of todays' extremely high speed drives.

ok, so i see you like the idea - so the question is: should we implement a
new ioctl for it, or - as like scsi - should we use a program like
camcontrol for it?

basically i prefer doing both, as the current atapi implementation
includes the most important atapi commands, it could be more complete,
and i think it's nice to have a user space program for sending packet
commands... :)

-- mauzi



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



Re: 3c589d w/ freebsd 3.3 works badly.

1999-12-06 Thread Darren Reed

In some mail from Matthew N. Dodd, sie said:
> 
> On Mon, 6 Dec 1999, Darren Reed wrote:
> > How reliable should the ep0 driver be with 3c389d pcmcia cards ?  It gets
> > detected by pccardd without any problems and a driver is attached to it,
> > but I'm not getting much in the way of performance from it with "link2"
> > selected for UTP (doesn't work with "media 10baset/utp").  It's being
> > used in conjunction with cardbus on a gateway solo 9100.  I suspect that
> > it isn't getting interrupted properly, although nothing is telling me
> > what IRQ is being given to it.
> 
> I'm still trying to track down a watchdog timeout problem with if_ep.

FWIW, I get 800kb/s transfer rates with NetBSD-current

Darren


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



Re: new Intel 100Mbps card

1999-12-06 Thread David Greenman

>Wes Peters wrote:
>> Wes Peters wrote:
>> > 
>> > This might be the new 82559ER; I'm downloading the datasheet now.  Have
>> > a peek at:
>> > 
>> > http://developer.intel.com/design/network/datashts/index.htm
>> 
>> Nope, that one is apparently device ID 0x1209.  Too bad they don't have
>> a PCI device ID cross-reference on the web site.  Bleh.
>
>if_fxpreg.h presently has:
>
>#define FXP_VENDORID_INTEL  0x8086
>#define FXP_DEVICEID_i82557 0x1229  /* 82557 - 82559 "classic" */
>#define FXP_DEVICEID_i82559 0x1030  /* New 82559 device id.. */

   Oops, I forgot that you had already added this. This should be merged into
3.x for the 3.4 release (with Jordan's permission of course). Are you going
to take care of that, Peter, or would you like me to?

-DG

David Greenman
Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org
Creator of high-performance Internet servers - 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: new Intel 100Mbps card

1999-12-06 Thread Peter Wemm

Wes Peters wrote:
> Wes Peters wrote:
> > 
> > This might be the new 82559ER; I'm downloading the datasheet now.  Have
> > a peek at:
> > 
> > http://developer.intel.com/design/network/datashts/index.htm
> 
> Nope, that one is apparently device ID 0x1209.  Too bad they don't have
> a PCI device ID cross-reference on the web site.  Bleh.

if_fxpreg.h presently has:

#define FXP_VENDORID_INTEL  0x8086
#define FXP_DEVICEID_i82557 0x1229  /* 82557 - 82559 "classic" */
#define FXP_DEVICEID_i82559 0x1030  /* New 82559 device id.. */

And:
if ((pci_get_vendor(dev) == FXP_VENDORID_INTEL) &&  
(pci_get_device(dev) == FXP_DEVICEID_i82557)) {
device_set_desc(dev, "Intel EtherExpress Pro 10/100B Ethernet");
return 0;
}  
if ((pci_get_vendor(dev) == FXP_VENDORID_INTEL) &&
(pci_get_device(dev) == FXP_DEVICEID_i82559)) {
device_set_desc(dev, "Intel InBusiness 10/100 Ethernet");
return 0;
}

I was told that the device ID is programmable in rom, as well as whether
the modem/com/16550 logical device is active and so on.

Does adding the new ID work with if_fxp on the new device?

Cheers,
-Peter



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



Re: natd is jumpy

1999-12-06 Thread Nick Rogness

On Sun, 5 Dec 1999, Archie Cobbs wrote:

> Brian Dean writes:
> > No dropped packets, but definitely some occasional long delays before
> > I get the echo.  However, I must concede, based on other respondants,
> > that something else must be going on and I cannot necessarily
> > attribute this to divert/firewall/natd.


I forgot to mention, are you connecting at V.90 speeds?  If so
renegotiations/retrains will take place and you will see a speed
jump or hesitation.  Disable this in the modem.  There are
specific S registers to do this. Also what type of term/com server
gear are you connecting to?

I would also recommend upgrading your modem BIOS.

> > 
> > However, the above numbers don't really illustrate the long response
> > times that I experience while typing at the shell prompt, or in elm.
> > It's really frustrating.

How often does this happen?  Is it a fixed time period?

[snip]
> 
> Could be you have a noisy line and your modem error correction is
> kicking in.  Try configuring your modem to disable error correction
> and see if it changes things.

uuhhh, don't disable error correction for long.  You might see
massive problems then.  But it might be useful to see if it is
involved in your problem.

Also, get your ISP involved.  Most admins have access to debug or
PPP trace tools to help you.  Good luck.


Nick Rogness   File not found...
System Administrator   Should I fake it (Y/N)?
RapidNet, INC  







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



Re: fxp, xl driver question .. (routing)

1999-12-06 Thread Mike Smith

> > On Sun, 05 Dec 1999, you wrote:
> Conversely, you can achieve the same latency reduction by setting the
> latency timer to 16, without increasing your overheads there. (This isn't
> actually entirely true, as you may run into busmaster ping-pong with more
> than one in the system, but you'll get this with reduced DMA bursts as
> well.)

I should have summarised this by saying:  Correct use of the latency 
timer will shorten your DMA bursts for you when necessary, giving you the 
best of both worlds.  When it's safe to run a long burst, you will.  When 
you need to push a device off the bus, that will happen too.

And the obvious extension to the "worst case" calculation is that if you 
have N master devices each with a latency timer of X, your worst-case 
timing for CPU access to a device is (N * X) + (N * arb overhead), just 
in case that wasn't clear.

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]




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



Re: fxp, xl driver question .. (routing)

1999-12-06 Thread Mike Smith

> On Sun, 05 Dec 1999, you wrote:
> >
> > > The question: Why doesn't this work... it seem so straight forward...
> > 
> > I'm not sure about the code in question, but the basic assumptions you're 
> > making about PCI's behaviour are flawed.  To achieve the goal you're 
> > trying to, you need to reduce the value of the PCI bus latency timer for 
> > the peripheral(s) that you're hoping to interrupt.
> I don't want to interrupt the devices.. which would require the 
> transaction to reoccur... 

Er, as I understand your original requirement this is exactly what you 
want to do - you want to push them off the bus so that the CPU can poll a 
status register on a given card.

> I do agree(from the book PCI System Architecture), 
> the Master Latency Timer should be decreased, but I still need the DMA
> transactions to complete sooner from the time GNT# is removed by the 
> arbiter.

The only case where the device will _not_ release the bus on loss of #GNT 
is when its latency timer has not yet expired.  This is my point; you can 
guarantee an upper bound on the time from #GNT loss to bus release _only_ 
by changing the latency timer.

Dropping the size of all of your DMA transactions increases your losses 
due to arbitration delays, because the device will (normally) _always_ 
give up the bus at the end of a DMA transaction.

> > Also, you don't want the (high) 
> > overhead of forcing a re-arbitration all the time, rather you want to 
> > guarantee the worst-case cycle time involved in polling the peripheral.  
> 
> > Again, to achieve this, you want to look at how the PCI bus latency timer 
> > works and use it instead.
>
> I understand how it is working, but the I still beleive smaller DMA
> transactions, while somewhat inefficient, will shorten the latency to 
> something reasonable.

No, this is basically wrong.  Sure, shortening your DMA transactions 
absurdly will give you some control over burst length, but you'd have to 
reduce them to less than the latency-timer-protected window before you 
noticed any effect, and the overhead-related losses would be painful.

Consider the optimal situation; you have a descriptor set up for a ~1500 
byte DMA, and the latency timer is set to 32 cycles.

The worst-case latency is then a little over 1us (including arbitration).

To do any better than this, you need to reduce your DMA burst size to 
less than 32/4 or 128 bytes.  This increases your arbitration overhead by 
a factor of more than 10.  This is a _constant_ loss factor, and at this 
point you still haven't actually gained anything.  To improve your 
worst-case latency by a factor of 2, you have to increase your 
arbitration loss to twenty times that of the 'optimal' case.

I can assure you that PCI is not very efficient when you are only 
bursting 64 bytes at a time.  8)

Conversely, you can achieve the same latency reduction by setting the
latency timer to 16, without increasing your overheads there. (This isn't
actually entirely true, as you may run into busmaster ping-pong with more
than one in the system, but you'll get this with reduced DMA bursts as
well.)

>  > You will always get the best performance out of PCI by avoiding  
> > _anything_ that involves arbitrating for the bus.  PCI bus transactions  
> > are reasonably expensive to start.  8( > 
> I agree.  If I knew I could avoid handshaking the device, I would skip it...
> It takes 20+% of the forwarding time..

You may want to give up and use another device...

> I have another question:  Is there a way to get the compiler to do a non
> blocking mem read ? load to a hardwired zeroed register? 

I'm not sure what you're talking about here.  "non-blocking" against what?

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]




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