Re: MMU-less FreeBSD

In message <[EMAIL PROTECTED]> Steve Price writes: : On Thu, Dec 13, 2001 at 06:19:42PM -0700, Warner Losh wrote: : > : > Hard. Lots of stuff relies on mmap, which basiclly requires an MMU or : > other tricks. The other tricks can be somewhat expensive... : : That's sort of what I figured. WR

Re: MMU-less FreeBSD

On Thu, Dec 13, 2001 at 08:35:08PM -0800, Mike Smith wrote: > > Well, eCos is free-as-in-beer. >From a quick glance at the license it looks to be a lot more like the GPL than a BSD license but I'll dig deeper. 'Any Modification which You create or to which You contribute must be made avail

Re: MMU-less FreeBSD

> > If you want an OS, consider eCOS or one of the "real" embedded systems, > > don't make too much work for yourself trying to take a system that's > > entirely unsuited to the task and butchering it... > > In eCOS are you talking about this one? > > http://sources.redhat.com/ecos/ Yes

Re: Performance issue

On Sun, Dec 09, 2001 at 03:23:28PM -0800, Peter Wemm wrote: > Poul-Henning Kamp wrote: > > > > There are many effects that could cause this, for instance if FreeBSD > > manages to align things differently in relation to the CPU cache you > > could get some very interesting waste of time that way.

Re: SSL_connect fails

On Mon, Dec 10, 2001 at 10:45:30AM +0100, KAISER Laszlo wrote: > On Sun, Dec 09, 2001 at 06:41:43PM +0100, KAISER Laszlo wrote: > > I'm doing a port of a little OpenSSL program to FreeBSD from linux, but the > > code which works fine on linux fails on FreeBSD at SSL_connect(). > > This function al

Re: NFS Patch #4 -- survived overnight test. (was Re: Found NFSdata corruption bug... (was Re:...))

At 10:35 AM -0800 12/13/01, Matthew Dillon wrote: > Are there still bugs in NFS? You bet! I'm sure there are bugs > related to multiple clients and/or the server modifying files out > from under a client, and I think the potential issue with nfsiod > ordering that was posted to

Re: MMU-less FreeBSD

On Thu, Dec 13, 2001 at 08:03:51PM -0800, Mike Smith wrote: > > If you want an OS, consider eCOS or one of the "real" embedded systems, > don't make too much work for yourself trying to take a system that's > entirely unsuited to the task and butchering it... In eCOS are you talking about this o

Re: MMU-less FreeBSD

> > Hard. Lots of stuff relies on mmap, which basiclly requires an MMU or > > other tricks. The other tricks can be somewhat expensive... > > That's sort of what I figured. WRS and possible others use BSD > as a basis for their embedded OS on archs without an MMU, right? No. Many embedded op

Re: uiomove (CPU) performance?

> The code is kernel mode so I do not think the memcopy routine uses uiomove > in this case(I could be wrong). Also this code is multiplatform so > that the general code uses memcopy and developers optimize the code to work > on the different platforms they are in. Speed is not my > concern right

Re: MMU-less FreeBSD

On Thu, Dec 13, 2001 at 06:19:42PM -0700, Warner Losh wrote: > > Hard. Lots of stuff relies on mmap, which basiclly requires an MMU or > other tricks. The other tricks can be somewhat expensive... That's sort of what I figured. WRS and possible others use BSD as a basis for their embedded OS

SHCC: National Sales Expansion Positions Comapny For Rapid Growth GAGVGXLR

Title: Investors   Investment Special Tonight's Feature Company ShareCom, Inc. (OTCBB: SHCC)

Adding a new FS to FreeBSD

Since JFS has come up again... Are there any papers that explain how to integrate a new filesystem into FreeBSD? The relevant chapter in the FreeBSD Developers' Handbook (16) is a bit terse :-). Specifically, I'm looking at being able to read/write 2BSD filesystems on my FreeBSD machines. Pete

Re: uiomove (CPU) performance?

The code is kernel mode so I do not think the memcopy routine uses uiomove in this case(I could be wrong). Also this code is multiplatform so that the general code uses memcopy and developers optimize the code to work on the different platforms they are in. Speed is not my concern right now becaus

Re: NFS Patch #4 -- survived overnight test. (was Re: Found NFS data corruption bug... (was Re:...))

Matthew Dillon wrote: > Hmm. Well, my code is definitely broken. My 'adj' calculation is > all wrong. However, my size calculation appears to be correct. > (size - adj) is the size of the block after the base has been adjusted > to the next full chunk. The number of chunks we t

Re: MMU-less FreeBSD

In message <[EMAIL PROTECTED]> Steve Price writes: : As a rough order of magnitude how hard would it be to port : FreeBSD to an architecture (Motorola Coldfire) that doesn't : have an MMU? I see some words on their site that the NetBSD : folks might be working on some archs that require this. Ha

Re: NFS Patch #4 -- survived overnight test. (was Re: Found NFS data corruption bug... (was Re:...))

Terry's interest prompted me to redo my algorithm a bit and write a program to test it with various combinations of base and size. I've included the program below. My fixed algorithm appears to produce the correct results, which is to generate the DEV_BSIZE aligned range tha

Re: NFS Patch #4 -- survived overnight test. (was Re: Found NFS data corruption bug... (was Re:...))

:Matthew Dillon wrote: :[ ... ] :> I would appreciate other VM gurus taking a look at the :> vm_page_set_validclean() changes. :[ ... ] : :Not to appoint myself a guru or anything... : :> +#if 1 :> + if ((base & (DEV_BSIZE - 1)) || (size & (DEV_BSIZE - 1))) { :> + int adj;

Re: uiomove performance?

> Does anyone know if there is a significant performance gain to maintaining > scatter/gather lists with uio rather than writing the s/g routine yourself. > > To be more specific: > I currently have a routine that takes a memory segments and places them in a > contiguous memory buffer. We need to

MMU-less FreeBSD

As a rough order of magnitude how hard would it be to port FreeBSD to an architecture (Motorola Coldfire) that doesn't have an MMU? I see some words on their site that the NetBSD folks might be working on some archs that require this. I got my hands on a board similar to the one in the NetTel eL

Re: uiomove performance?

* Mark Brown <[EMAIL PROTECTED]> [011213 17:35] wrote: > Does anyone know if there is a significant performance gain to maintaining > scatter/gather lists with uio rather than writing the s/g routine yourself. > > To be more specific: > I currently have a routine that takes a memory segments and

uiomove performance?

Does anyone know if there is a significant performance gain to maintaining scatter/gather lists with uio rather than writing the s/g routine yourself. To be more specific: I currently have a routine that takes a memory segments and places them in a contiguous memory buffer. We need to optimize th

Re: Junior Kernel hacker task: Floppy driver mode handling.

Dag-Erling Smorgrav wrote: > Poul-Henning Kamp <[EMAIL PROTECTED]> writes: > > There exists a patch for adding a mode to our floppy driver to > > add DEC RX50 media handling. > > Clearly a job for Jessem, don't you think? :) Kids can be cruel. 8^) 8^). -- Terry To Unsubscribe: send mail to [E

Re: New vhost bugs.FreeBSD.org

On Thu, Dec 13, 2001 at 10:43:31PM +0100, Maxime Henrion wrote: > It would be very useful, IMO, to have a simple URL like this to access the > PR database. > > Opinions ? Gets my vote. -- George C A ReidTel: (08701) 200870 Ext. 26654 FreeBSD Committer/Developer

Re: New vhost bugs.FreeBSD.org

hi, i would like it to... it would save an effort for us, and people from typing lond URLs. Cool Idea! =Hiten =<[EMAIL PROTECTED]> = -Hiten, Thank You, Yours Sincerely, Hiten Pandya, <[EMAIL PROTECTED]> ___

Re: New vhost bugs.FreeBSD.org

On 13-Dec-01 Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Maxime Henrion writes: >> Hello all, >> >>The recently added cvsweb.FreeBSD.org vhost makes me think we could also >>have one pointing to the PR database (/cgi/query-pr-summary.cgi), for >>example, bugs.FreeBSD.org as th

Re: Junior Kernel hacker task: Floppy driver mode handling.

Poul-Henning Kamp <[EMAIL PROTECTED]> writes: > There exists a patch for adding a mode to our floppy driver to > add DEC RX50 media handling. Clearly a job for Jessem, don't you think? :) DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubs

Re: New vhost bugs.FreeBSD.org

Maxime Henrion <[EMAIL PROTECTED]> writes: > The recently added cvsweb.FreeBSD.org vhost makes me think we could also > have one pointing to the PR database (/cgi/query-pr-summary.cgi), for > example, bugs.FreeBSD.org as the subject of this mail suggests. Yes, please. DES (Bugmeister) -- Dag-Er

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

On Thu, Dec 13, 2001 at 01:40:46PM -0800, Matthew Dillon wrote: > > :Matt, > : > :what the hell, this seems to very near by a problem I wanted to > :report since a week: > : > :in a data acquisition I have a write process writing to a file > :backed shared mmapped ringbuffer. There can be several

Re: New vhost bugs.FreeBSD.org

In message <[EMAIL PROTECTED]>, Maxime Henrion writes: > Hello all, > >The recently added cvsweb.FreeBSD.org vhost makes me think we could also >have one pointing to the PR database (/cgi/query-pr-summary.cgi), for >example, bugs.FreeBSD.org as the subject of this mail suggests. > >It would

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

:Matt, : :what the hell, this seems to very near by a problem I wanted to :report since a week: : :in a data acquisition I have a write process writing to a file :backed shared mmapped ringbuffer. There can be several reader :processes on this this ringbuffer. Now once i killed the writer for :re

New vhost bugs.FreeBSD.org

Hello all, The recently added cvsweb.FreeBSD.org vhost makes me think we could also have one pointing to the PR database (/cgi/query-pr-summary.cgi), for example, bugs.FreeBSD.org as the subject of this mail suggests. It would be very useful, IMO, to have a simple URL like this to access

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

: :I can't seem to get a crash dump out of it, but the panic I'm seeing is: : :panic: allocdirect_check: old 30246736 ! = new 30246736 || ibn 4 >= 12 : :For some reason the dump also dies, resettting the ata0 bus over and over :but not writing out to swap. : :- Jordan That's the softupdates

Re: Bus master DMA problems

On Thu, 13 Dec 2001, Justin T. Gibbs wrote: > > > >There are a couple of rules in PCI you must have in mind when > >synchronization between PCI devices is needed. > > > >1) Interrupts are not synchronization events. They just send attention to > > the device driver (acts as SIGIO, for example

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

On Thu, 13 Dec 2001, Jordan Hubbard wrote: > I can't seem to get a crash dump out of it, but the panic I'm seeing is: > > panic: allocdirect_check: old 30246736 ! = new 30246736 || ibn 4 >= 12 > > For some reason the dump also dies, resettting the ata0 bus over and over > but not writing out to

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

On Thu, Dec 13, 2001 at 02:58:28AM -0800, Matthew Dillon wrote: > > @#$@#$ crap. I think I found a dirty-mmap edge case with truncation. > It requires a change to vm_page_set_validclean(), which of course is > one of the core routines in the VM system. > > Basically what happens

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

I can't seem to get a crash dump out of it, but the panic I'm seeing is: panic: allocdirect_check: old 30246736 ! = new 30246736 || ibn 4 >= 12 For some reason the dump also dies, resettting the ata0 bus over and over but not writing out to swap. - Jordan > : > :> I should point out that FSX c

Re: NFS Patch #4 -- survived overnight test. (was Re: Found NFS data corruption bug... (was Re:...))

On Thu, Dec 13, 2001 at 11:03:54AM -0800, Matthew Dillon wrote: > I can hold-off the vm_page_set_validclean() patch for a week but there > is no reason not to 3-day MFC the rest of the bug fixes. I would also be more comfortable if we gave this change a week in -CURRENT. This is great

Re: Bus master DMA problems

> >There are a couple of rules in PCI you must have in mind when >synchronization between PCI devices is needed. > >1) Interrupts are not synchronization events. They just send attention to > the device driver (acts as SIGIO, for example). Some bridge may flush > posted buffers on interrupt, b

Re: Bus master DMA problems

There are a couple of rules in PCI you must have in mind when synchronization between PCI devices is needed. 1) Interrupts are not synchronization events. They just send attention to the device driver (acts as SIGIO, for example). Some bridge may flush posted buffers on interrupt, but sinc

Solution for an IPFIREWALL_FORWARD panic?

Hello everybody, A kernel panic has been observed in both branches under the following conditions: o ipfw is configured with a "fwd" rule for outgoing packets that will match some RIP datagrams o GateD is started with RIP enabled and consequently sends a broadcast UDP datagram that matches th

Re: NFS Patch #4 -- survived overnight test. (was Re: Found NFS data corruption bug... (was Re:...))

:Hmm. I'm OK with a commit to -CURRENT, but would really appreciate it if :you made it a week before MFC to -STABLE. Given your statement just a few :lines earlier about needing more review from VM types, that would allow a :bit more time for necessary review. I agree, given the impending 4.5 :

REMINDER: Request for submissions: FreeBSD Monthly Development Status Report

Reminder: the deadline is tomorrow. I've received only about 8 reports so far, and would appreciate receiving more :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services -- Forwarded message -- Date: S

Re: NFS Patch #4 -- survived overnight test. (was Re: Found NFS data corruption bug... (was Re:...))

Matthew Dillon wrote: [ ... ] > I would appreciate other VM gurus taking a look at the > vm_page_set_validclean() changes. [ ... ] Not to appoint myself a guru or anything... > +#if 1 > + if ((base & (DEV_BSIZE - 1)) || (size & (DEV_BSIZE - 1))) { > + int adj; > + > +

Re: NFS Patch #4 -- survived overnight test. (was Re: Found NFS data corruption bug... (was Re:...))

On Thu, 13 Dec 2001, Matthew Dillon wrote: > Ok, here is the latest patch set. This patch set survived an > overnight run of the nfs torture test that Jordan posted... it > got through 597,000 test calls over NFSv3, 367,000 over NFSv2, and > 1.35 million on a local filesystem.

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

:> And if you hadn't heard, Matt just fixed a couple of bugs in the tcp :> stack which improves NFS greatly. It sounds like after this round of :> NFS fixes, the first answer to NFS questions should be: Upgrade to :> 4.5! : :I don't even bother with TCP mounts; my default amd rule says :proto=ud

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

* void <[EMAIL PROTECTED]> [011213 11:00] wrote: > Has anyone brought this code to the attention of the NetBSD people? > I imagine that they would be interested. If not, I will forward it > along myself, as soon as I determine the appropriate list. (List > recommendations from the dual citizens

NFS Patch #4 -- survived overnight test. (was Re: Found NFS data corruption bug... (was Re:...))

Ok, here is the latest patch set. This patch set survived an overnight run of the nfs torture test that Jordan posted... it got through 597,000 test calls over NFSv3, 367,000 over NFSv2, and 1.35 million on a local filesystem. This patch set is for -stable. It again has the

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

: :Matt didnt feel the fixes were primarily performance related, just bug :fixes. I meant just the last two days worth of NFS stuff are just bug fixes. The TCP fixes from earlier in the month are definitely performance fixes. -Matt To Un

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

On Thu, 13 Dec 2001, Geoff Mohler wrote: > Matt didnt feel the fixes were primarily performance related, just bug > fixes. Right, the fact that they are bug fixes is what seems to be the most powerful reason to recommend upgrading. Mike "Silby" Silbersack To Unsubscribe: send mail to [EMAIL

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

On Thu, 13 Dec 2001, Dan Nelson wrote: > In the last episode (Dec 13), Mike Silbersack said: > > And if you hadn't heard, Matt just fixed a couple of bugs in the tcp > > stack which improves NFS greatly. It sounds like after this round of > > NFS fixes, the first answer to NFS questions should

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

For some people, the overhead is an acceptible tradeoff to redundancy. Ever since Cisco released thier 6500 10/100 blades that to crappy buffering between a Gigabit NFS server (could be anything, just an example) and an 100Mbit client, people have somewhat been adding that overhead to thier CPU a

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

Has anyone brought this code to the attention of the NetBSD people? I imagine that they would be interested. If not, I will forward it along myself, as soon as I determine the appropriate list. (List recommendations from the dual citizens here are welcome.) On Wed, Dec 12, 2001 at 08:23:56AM -0

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

Matt didnt feel the fixes were primarily performance related, just bug fixes. On Thu, 13 Dec 2001, Mike Silbersack wrote: > > On Wed, 12 Dec 2001, Matthew Dillon wrote: > > > :I suppose while were on the topic.. > > : > > :Are there any hidden secrets to eeking out more performance from the BS

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

In the last episode (Dec 13), Mike Silbersack said: > On Wed, 12 Dec 2001, Matthew Dillon wrote: > > Geoff Mohler wrote: > > :Are there any hidden secrets to eeking out more performance from > > :the BSD NFS client (other than version types and the normal fstab > > :tweaks). > > And if you hadn't

ANNOUNCE: FreeBSD Backports site

Hi All, On Dec 11, at 04:23 PM, Michael Lucas wrote: > > > For those that're interested (and have the time), it's at > > http://www.visi.com/~hawkeyd/freebsd-backports.html > > for review/critique. It's only a WIP at this point; please don't do anything > > to publicize it. I'll mail hackers

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

On Wed, 12 Dec 2001, Mike Smith wrote: > Many of the key issues in making OS X NFS work were related to its > interaction with the UBC and the subtly different VFS semantics, > although the same issues probably exist in different form in the > FreeBSD code. I get dragged into some really shocki

Re: 4G phisical memory kernel trap - the solution

On Wed, 5 Dec 2001, Varshavchick Alexander wrote: > Thank you Dan, can you please give a more detailed description as how to > do it? > > > You can run a 4.4 kernel on a 4.2 userland with no problem. On some of > > my production boxes, I'm running a 4.4 kernel on a 4.0 userland :) You > > sho

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

@#$@#$ crap. I think I found a dirty-mmap edge case with truncation. It requires a change to vm_page_set_validclean(), which of course is one of the core routines in the VM system. Basically what happens is that ftruncate() calls vnode_pager_setsize() which eventually calls

Marketing is the LifeBlood of Your Business!

Title: American Mailing

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

On Wed, 12 Dec 2001, Matthew Dillon wrote: >All I can say is... holy shit! Dude, you kick ass. At work I've been dealing with Linux's crappy NFS implementation for years, while FreeBSD has always been pretty damn good by comparison. Linux finally got a decent amount of performance under 2.

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

> Thanks! I'm slowly whacking the bugs. I just fixed another one... That's awesome... I'd hoped this program might help you find a few things, but I never expected you to find so many bugs in NFS so... quickly! I certainly didn't expect you to tickle any local filesystem problems either.

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

: : Very cool. Good job! : :-DG : :David Greenman :Co-founder, The FreeBSD Project - http://www.freebsd.org Thanks! I'm slowly whacking the bugs. I just fixed another one... vtruncbuf() handles the buffers beyond the file EOF but doesn't handle the buffer straddling the truncatio