linux compatibility question
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
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.
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.
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
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
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
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
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
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
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
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?)
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 ?
: 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
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
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
:> 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?
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?)
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
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.
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?
> > 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.
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
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 ?
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.
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?)
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?)
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
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
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
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
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
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?
> 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
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
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
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
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 .. ?
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?)
:> 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?
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
: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?)
> 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?)
: 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?)
: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?)
> 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?)
: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?)
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
: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
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 .. ?
:>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
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?)
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?)
> 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?)
: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?)
> 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
> > > > > 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
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?)
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
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 .. ?
> :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
> 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
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 .. ?
>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?)
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?)
:>: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?)
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)
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
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
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
:>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?)
: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?)
: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 .. ?
: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 .. ?
: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
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?)
: : :[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
> 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.
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
>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
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
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)
> > 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)
> 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
