Marius Bendiksen <[EMAIL PROTECTED]> writes:
> In the following code, from /sys/kern/vfs_bio.c : bread(), it appears to
> me that it is possible for a null pointer to be deferenced?
>
> struct buf *bp;
>
> bp = getblk(vp, blkno, size, 0, 0);
> *bpp = bp;
>
> /* i
Hello,
I just added a MEXTADD() routine to the [now getting bigger] mbuf
re-write patch, as well as fixed and changed a few little things here and
there (once again). Thus, so-called "version 2" of the diff is again
available: http://www.technokratis.com/code/mbuf/
This
Hi Joy,
Current Tigon firmware utilizes a feature provided by the DMA
write engine to update the receive buffer consumer automatically.
If the TG_DMA_STATE_UPDATE_RX_BUF_CONS bit (b19) is
set in the DMA write state register for a DMA operation, the DMA
write engine will update the receive buffer
In the following code, from /sys/kern/vfs_bio.c : bread(), it appears to
me that it is possible for a null pointer to be deferenced?
struct buf *bp;
bp = getblk(vp, blkno, size, 0, 0);
*bpp = bp;
/* if not found in cache, do some I/O */
if ((bp->b_flags &
>
> Someone asked at the USENIX BOF about the status of ieee1394 driver
> for FreeBSD. For those who want to play with DV cameras, a set of
> tools to transmit DV streasms over IP is available from
> http://www.sfc.wide.ad.jp/DVTS/
>
> It includes the ieee1394 driver presented at the last year
hi all,
I have been looking into the Tigon firmware code and i am totalyy
puzzled about this: there is no place in the code where
trp->local_mem_conf.rx_buf_consumer is incremented. (except in
h_mac_rx_comp_nohost() which is not called) The tigon documentation says
that it should be incremented b
On 26 Jun 2000, Chris Shenton wrote:
:I was considering this for a project I developed: web up/download of
:lots of large files. I was using MySQL and some of the folks on that
:list recommended not storing large files in the DB: even though the
:disk consumption is the same, if it's in a DB you
Daniel Eischen wrote:
>
> Oddly, this causes problems with GNAT (Ada is a high level language)
> because it wants/expects 64-bit extended precision. It seems as if
> GNAT for linux-i386 also uses 64-bit extended precision. The only
> other GNAT i386 platform that doesn't use 64-bit precision is
On Tue, 27 Jun 2000, Steve Kargl wrote:
> Daniel Eischen wrote:
> >
> > Oddly, this causes problems with GNAT (Ada is a high level language)
> > because it wants/expects 64-bit extended precision. It seems as if
> > GNAT for linux-i386 also uses 64-bit extended precision. The only
> > other GNA
> is the PCI Specification avaialable on the web? i tried a couple of search
> engines, couldn't find it.
The PCI Specification is published by the PCI Special Interest Group.
The PCI Local Bus Specification Revision 2.0 cost about $20-25 a few
years ago, and I see from the web order page:
On Tue, Jun 27, 2000, Adrian Chadd wrote:
> On Tue, Jun 27, 2000, Cyrille Lefevre wrote:
> > John Polstra wrote:
> > > In article <[EMAIL PROTECTED]>,
> > > Cyrille Lefevre <[EMAIL PROTECTED]> wrote:
> > > >
> > > > the problem I have, is that, when I run "cvs -t update -r RELENG_4",
> > > > I g
I've noticed that we change the default setting for floating point
precision from extended precision (64-bit) to double precision (53-bit).
The comment in npx.h says:
/*
* The hardware default control word for i387's and later coprocessors is
* 0x37F, giving:
*
*round to nearest
hi,
is the PCI Specification avaialable on the web? i tried a couple of search
engines, couldn't find it.
--mohan
Telecom R&D , FAC-D, SAS
ph:- 5281461 x3078
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Someone asked at the USENIX BOF about the status of ieee1394 driver
for FreeBSD. For those who want to play with DV cameras, a set of
tools to transmit DV streasms over IP is available from
http://www.sfc.wide.ad.jp/DVTS/
It includes the ieee1394 driver presented at the last year's freenix.
-
14 matches
Mail list logo