search for: bufers

Hi Duncan, I've modified my backend such that the function isn't called anymore with iPTR. I still think that if iPTR is an invalid input to getValueTypeList() that the function should have at least an assert checking that. Thanks, Javier Hi Javier, > I've observed in some tests that getValueTypeList() is sometimes called > with type MVT::iPTR. I think this is a bug,

Hi Javier, > I’ve modified my backend such that the function isn’t called anymore > with iPTR. I still think that if iPTR is an invalid input to > getValueTypeList() that the function should have at least an assert > checking that. I agree - please post a patch adding one. Ciao, Duncan.

Hello, The attached patch is to add an assert to getValueTypeList() to verify that for simple value types their value is NOT between MAX_ALLOWED_VALUETYPE and LastSimpleValueType (inclusive) as this causes a buffer overrun. Thanks, Javier -----Original Message----- From: Duncan Sands [mailto:baldrick at free.fr] Sent: Tuesday, April 27, 2010 5:07 AM To: Martinez, Javier E Cc: LLVM Developers

Hello, I've observed in some tests that getValueTypeList() is sometimes called with type MVT::iPTR. There is a discrepancy between the size of the array VTs and the use in getTypeValueList(). The array is allocated with space for elements up to LAST_VALUE_TYPE and iPTR is defined after it. The enumerator value of iPTR is between LAST_VALUE_TYPE and LastSimpleValueType. For this reason the

...ite into the buffer. > > It looks like if another call then happens, and that > other call uses a different buffer, virtio rng > will happily return the data written into the > original buf pointer, confusing the caller. > > Is that right? > Yes. hw_random core uses two bufers: - rng_fillbuf that is used with a blocking access and protected by the reading_mutex. I think this cannot be interrupted by a kill because it's in hwrng_fillfn() and it's kthread. - rng_buffer that is used in rng_dev_read() and can be interrupted (it is also protected by reading_mutex)...

...ite into the buffer. > > It looks like if another call then happens, and that > other call uses a different buffer, virtio rng > will happily return the data written into the > original buf pointer, confusing the caller. > > Is that right? > Yes. hw_random core uses two bufers: - rng_fillbuf that is used with a blocking access and protected by the reading_mutex. I think this cannot be interrupted by a kill because it's in hwrng_fillfn() and it's kthread. - rng_buffer that is used in rng_dev_read() and can be interrupted (it is also protected by reading_mutex)...

Hi guys, I have re-implemented /efi/udp.c The new code fixes: 1) The low and decreasing throughput on TFTP transfers. 2) The added delay between consecutive TFTP transfers. 3) The TFTP errors induced by broadcast traffic like ARP. Initial tests on a 50MB transfer showed times going from 3 minutes to ~12 seconds, also tested OK with nested TFTP transfers (include command). This

----- Original Message ---- > From: Pyun YongHyeon <pyunyh@gmail.com> > To: Ian FREISLICH <ianf@clue.co.za> > Cc: FreeBSD Current <freebsd-current@freebsd.org>; Robert Backhaus <robbak@robbak.com> > Sent: Monday, March 17, 2008 8:12:03 AM > Subject: Re: Packet corruption in re0 > > On Fri, Feb 22, 2008 at 10:43:22AM +0200, Ian FREISLICH wrote: >

...nother call then happens, and that > > other call uses a different buffer, virtio rng > > will happily return the data written into the > > original buf pointer, confusing the caller. > > > > Is that right? > > > > Yes. > > hw_random core uses two bufers: > > - rng_fillbuf that is used with a blocking access and protected by the > reading_mutex. I think this cannot be interrupted by a kill because it's > in hwrng_fillfn() and it's kthread. > > - rng_buffer that is used in rng_dev_read() and can be interrupted (it > i...

The variable 'ok' is never used and generates a warning. Remove it. Also ntfssect.c is designed to be compiled in non Unicode mode when using MSVC compilers, so remove all ambiguity about it (LPCTSTR -> LPCSTR, use of 'A' API calls) so that it doesn't break when compiled in Unicode mode, which is what Rufus uses with MSVC. -------------- next part --------------

On 11/08/2020 14:53, Martin Wilck wrote: > On Tue, 2020-08-11 at 14:39 +0200, Laurent Vivier wrote: >> On 11/08/2020 14:22, Martin Wilck wrote: >>> On Tue, 2020-08-11 at 14:02 +0200, Laurent Vivier wrote: >>>>>> drivers/char/hw_random/virtio-rng.c | 14 ++++++++++++++ >>>>>> 1 file changed, 14 insertions(+) >>>>>>

On 11/08/2020 14:53, Martin Wilck wrote: > On Tue, 2020-08-11 at 14:39 +0200, Laurent Vivier wrote: >> On 11/08/2020 14:22, Martin Wilck wrote: >>> On Tue, 2020-08-11 at 14:02 +0200, Laurent Vivier wrote: >>>>>> drivers/char/hw_random/virtio-rng.c | 14 ++++++++++++++ >>>>>> 1 file changed, 14 insertions(+) >>>>>>

Hi, Is somewhere alghorithm description of encoder process implemented in libtheora? May be some drafts? May be frame dataflow throw encoder stages? PLEASE -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/theora/attachments/20110318/c3e8e109/attachment.htm

---------- Forwarded message ---------- From: digital design <developer.fpga at gmail.com> Date: 21 March 2011 13:38 Subject: Re: [theora] alghorithm of working encoder in libtheora To: bens at alum.mit.edu Cc: Reply-All at xiph.org On 18 March 2011 23:15, Benjamin M. Schwartz <bmschwar at fas.harvard.edu>wrote: > On 03/18/2011 01:44 PM, digital design wrote: > > Now i

On Sun, 2018-08-05 at 00:29 -0700, Christoph Hellwig wrote: > On Sun, Aug 05, 2018 at 11:10:15AM +1000, Benjamin Herrenschmidt wrote: > > - One you have rejected, which is to have a way for "no-iommu" virtio > > (which still doesn't use an iommu on the qemu side and doesn't need > > to), to be forced to use some custom DMA ops on the VM side. > > >

On Sun, 2018-08-05 at 00:29 -0700, Christoph Hellwig wrote: > On Sun, Aug 05, 2018 at 11:10:15AM +1000, Benjamin Herrenschmidt wrote: > > - One you have rejected, which is to have a way for "no-iommu" virtio > > (which still doesn't use an iommu on the qemu side and doesn't need > > to), to be forced to use some custom DMA ops on the VM side. > > >

...sentence means that the virtqueue buffer > > > starts with the header. > > > > > > For virtio-net mergable RX buffers the header is only in the first > > > buffer and the length field accounts for the entire fragmented packet > > > (that spans multiple bufers), so I suspected the specification was > > > needed here too. > > > > > > I'm happy to omit it. > > > > > \subsubsection{Device Events}\label{sec:Device Types / Socket Device / Device Operation / Device Events} > > > > > > > &gt...

...sentence means that the virtqueue buffer > > > starts with the header. > > > > > > For virtio-net mergable RX buffers the header is only in the first > > > buffer and the length field accounts for the entire fragmented packet > > > (that spans multiple bufers), so I suspected the specification was > > > needed here too. > > > > > > I'm happy to omit it. > > > > > \subsubsection{Device Events}\label{sec:Device Types / Socket Device / Device Operation / Device Events} > > > > > > > &gt...

...; > > > starts with the header. > > > > > > > > > > For virtio-net mergable RX buffers the header is only in the first > > > > > buffer and the length field accounts for the entire fragmented packet > > > > > (that spans multiple bufers), so I suspected the specification was > > > > > needed here too. > > > > > > > > > > I'm happy to omit it. > > > > > > > \subsubsection{Device Events}\label{sec:Device Types / Socket Device / Device Operation / Device Events}...

Add virtio pstore device to allow kernel log files saved on the host. It will save the log files on the directory given by pstore device option. $ qemu-system-x86_64 -device virtio-pstore,directory=dir-xx ... (guest) # echo c > /proc/sysrq-trigger $ ls dir-xx dmesg-1.enc.z dmesg-2.enc.z The log files are usually compressed using zlib. Users can see the log messages directly on the