On 10/26/05 04:10 John Baldwin said the following:
Yes, and on some archs the sync() operations do have memory barriers in place,
but there isn't any bounce buffering with bus_dmamem_alloc() memory.
and in _bus_dmamap_load() in /usr/src/sys/i386/i386/busdma_machdep.c,
apparently if the
Dear folks,
When we were trying to make a userland FS application we have
encountered Invalid Argument when doing mmap() over an open descriptor
to a disk device. The program goes here:
#includesys/types.h
#includesys/stat.h
#include
On 10/26/05 10:39 Scott Long said the following:
Apparently the original poster sent his question to me in private, then
sent it again to the mailing list right as I was responding in private.
apologies on that, scott. an initial search only turned up your message in
the archives, but
On Wednesday 26 October 2005 04:47 am, Dinesh Nair wrote:
On 10/26/05 10:39 Scott Long said the following:
Apparently the original poster sent his question to me in private, then
sent it again to the mailing list right as I was responding in private.
apologies on that, scott. an initial
John Baldwin wrote:
On Wednesday 26 October 2005 04:47 am, Dinesh Nair wrote:
On 10/26/05 10:39 Scott Long said the following:
Apparently the original poster sent his question to me in private, then
sent it again to the mailing list right as I was responding in private.
apologies on that,
On 10/26/05 23:54 Scott Long said the following:
The value of the map is an implementation detail, which is why it's an
opaque typedef. Portable code should always assume that the map has
valid data. Now, specifically for i386, if you have a device with a
right, so for portability's sake,
Here's one for anyone bored out there :-)
I have a cluster here running FreeBSD and years back I got an old Xyplex
Maxserver 40 1640 terminal server off ebay. Basically it's a box that has a
bunch of serial ports on it and one 10 mbit ethernet port. You assign an IP# to
the ethernet port, then
You'll never get a driver that looks exactly right for one
OS to work with another, even with an emulation layer.
For instance, FreeBSD doesn't have an activate method for
device drivers whereas NetBSD and OpenBSD do.
And there are examples of the reverse. So shared drivers
will have some
At about the time of 10/25/2005 12:50 PM, victor cruceru stated the
following:
Hi Daniel,
Yes, this is the fix. And yes, I think that the bug was reported (at
least on a mailing list...)
BTW: I dare to suggest to fully upgrade your system to the latest
6.0, it is a huge step forward from 5.4.
On Wednesday 26 October 2005 11:54 am, Scott Long wrote:
Perhaps on i386. Each arch implements sync(). Argh, it does look like
the memory barriers needed on e.g., Alpha aren't used with static buffers
because of the map != NULL check in sys/busdma.h. *sigh* I guess archs
that need
On Wednesday 26 October 2005 02:13 am, Dinesh Nair wrote:
On 10/26/05 04:10 John Baldwin said the following:
Yes, and on some archs the sync() operations do have memory barriers in
place, but there isn't any bounce buffering with bus_dmamem_alloc()
memory.
and in _bus_dmamap_load() in
On Wednesday 26 October 2005 01:17 pm, Daniel Rudy wrote:
At about the time of 10/25/2005 12:50 PM, victor cruceru stated the
following:
Hi Daniel,
Yes, this is the fix. And yes, I think that the bug was reported (at
least on a mailing list...)
BTW: I dare to suggest to fully upgrade
On Mon, Oct 24, 2005, nocool wrote:
Can memory management system utilize COW to supply zero-filled page to kernel
or user process.
That is to say:
When processes want zeroed page, we give them a mirror of one already zerod
pages. If they just
read, they can read zero from the back page.
On 10/27/05 01:20 John Baldwin said the following:
On i386, yes. It won't on sparc64 when using an IOMMU for example. The whole
point of using bus_dma is to not use vtophys() since by doing that you are
righto, so for platform portability, we'd still need to use it there though.
Yes,
John Baldwin wrote:
On Wednesday 26 October 2005 02:13 am, Dinesh Nair wrote:
On 10/26/05 04:10 John Baldwin said the following:
Yes, and on some archs the sync() operations do have memory barriers in
place, but there isn't any bounce buffering with bus_dmamem_alloc()
memory.
and in
On Wed, Oct 26, 2005 at 05:08:24AM +,
Chrystian Lopez wrote:
que onda hola estoy inetentando montar my memoria usbcon
usbdevs -v
Ok, es un pendrive supongo.
me aparece con el driver usb0
Sera el dispositivo usb0?, ese es solo el puerto USB, no
el dispositivo umass
At about the time of 10/26/2005 11:25 AM, John Baldwin stated the following:
On Wednesday 26 October 2005 01:17 pm, Daniel Rudy wrote:
At about the time of 10/25/2005 12:50 PM, victor cruceru stated the
following:
Hi Daniel,
Yes, this is the fix. And yes, I think that the bug was reported (at
On 10/27/05 04:16 Scott Long said the following:
an example would be using (BUS_DMASYNC_POSTREAD|BUS_DMASYNC_PREWRITE)
which
would be 0x03 in freebsd 4.x and 0x06 in freebsd 5.x. the gotcha is that
0x03 in freebsd 4.x is BUS_DMASYNC_POSTWRITE. so therefore,
18 matches
Mail list logo
