similar to: latest cvsup to stable kernel build fall down, go boom

TB --- 2003-10-02 04:00:01 - starting RELENG_4 tinderbox run for alpha/alpha TB --- 2003-10-02 04:00:01 - checking out the source tree TB --- cd /home/des/tinderbox/RELENG_4/alpha/alpha TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_4 src TB --- 2003-10-02 04:07:38 - building world TB --- cd /home/des/tinderbox/RELENG_4/alpha/alpha/src TB --- /usr/bin/make -B buildworld >>>

TB --- 2003-10-02 04:44:07 - starting RELENG_4 tinderbox run for i386/i386 TB --- 2003-10-02 04:44:07 - checking out the source tree TB --- cd /home/des/tinderbox/RELENG_4/i386/i386 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_4 src TB --- 2003-10-02 04:49:12 - building world TB --- cd /home/des/tinderbox/RELENG_4/i386/i386/src TB --- /usr/bin/make -B buildworld >>>

I've spent the past four days or so updating machines here to 4.8/9-stable via cvsup, and have done a complete make buildworld/kernel on each machine (some SMP, some single processor). It seems something is broken with the latest fxp driver, on each machine (different mobos and hardware configs) heavy network traffic with fxp NICs causes timeouts and random kernel panics. First machine to

I've spent the past four days or so updating machines here to 4.8/9-stable via cvsup, and have done a complete make buildworld/kernel on each machine (some SMP, some single processor). It seems something is broken with the latest fxp driver, on each machine (different mobos and hardware configs) heavy network traffic with fxp NICs causes timeouts and random kernel panics. First machine to

Did cvsup on a machine that does just mail processing (well, a lot of spam scanning) and it crashed not too much later. This kernel does not include MFC src/sys/kern/sys_process.c revisions 1.111 and 1.112: Use kmem_alloc_nofault() rather than kmem_alloc_pageable() in procfs_rwmem(). Use vm_page_hold() in place of vm_page_wire() since the page can be freed. Don't hold extra

Commit 69c4938249fb ("drm/nouveau/instmem/gk20a: use direct CPU access") tried to be smart while using the DMA-API by managing the CPU mappings of buffers allocated with the DMA-API by itself. In doing so, it relied on dma_to_phys() which is an architecture-private function not available everywhere. This broke the build on several architectures. Since there is no reliable and portable

Hi, after updating my freebsd amd64 box from 9.1 (r250841) to 9.2-RC (r254276) virtualbox crashes the machine. Seconds after starting VBOX the screen freezes and then reboots (probably a trap, cannot see it, as screen is in graphics mode). The kernel modules of vbox have been recompiled. Going back to 9.1 kernel and matching vbox modules works. In both cases VBOX 4.2.16 is used. cheers, Thomas

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-04:11.msync Security Advisory The FreeBSD Project Topic: buffer cache invalidation implementation issues Category: core Module: sys Announced:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-04:11.msync Security Advisory The FreeBSD Project Topic: buffer cache invalidation implementation issues Category: core Module: sys Announced:

Hello, FYI: A FreeBSD user suggested that this issue requires a security advisory. The issue has been public for some time, but currently, FreeBSD does not issue advisories for local denial-of-service issues. It is expected that this bug will soon be fixed in FreeBSD 4.x (it is already fixed in FreeBSD 5.x, as you can see below). Cheers, -- Jacques Vidrine <nectar@freebsd.org> -----

Hello, There it is, all my computers on FreeBSD 9.1-RELEASE had panic. I can just say there is a problem in the 9.1-RELEASE because I had no panic before. What afraid me is that my production server also panic'ed a few days ago, fortunately it does not appears so often. This is a panic that happened on my desktop computer, with a graphic card. The crash usually appears when X starts. GNU

Good Day, Please cc me ( eperrin@cseven.ca ) on responses to this, I am not on either mailing list anymore. I cvsup'ed on the STABLE branch today (September 9th) at around 2:30PM EDT. No problems with buildworld or kernel build, but I am getting failures during installworld Error and output from uname -a are below. vm/pmap.h -> vm/pmap.ph vm/swap_pager.h -> vm/swap_pager.ph vm/vm.h

On 11/11/2015 06:07 PM, Alexandre Courbot wrote: > Commit 69c4938249fb ("drm/nouveau/instmem/gk20a: use direct CPU access") > tried to be smart while using the DMA-API by managing the CPU mappings of > buffers allocated with the DMA-API by itself. In doing so, it relied > on dma_to_phys() which is an architecture-private function not > available everywhere. This broke the

I'm running 9.2-RC4 on a handful of desktop and server machines (both i386 and amd64). I have seen three panics (all vm_page_unwire) on one of those systems only (amd64 server) during the past week. The first two panics were triggered when shutting down the ntpd daemon (a recent development snapshot version of ntpd: 4.2.7p387). Exiting a later release (p388) has not triggered the panic.

Dear list, A few days ago one of my machines were attacked by a DDoS-attack using UDP on random ports.. When I later on analyzed the logs, I found this in my dmesg: xl0: initialization of the rx ring failed (55) xl0: initialization of the rx ring failed (55) xl0: initialization of the rx ring failed (55) I tried to find out on google what it ment, but without any luck. What does that mean and

Hello! My attempt to build openoffice.org-3 seems to be hanging. Pressing Ctrl-T produces: load: 0.11 cmd: tcsh 79759 [sleeping without queue] 0.00u 0.00s 0% 0k (tcsh is used by OOo's build-script). What is this "sleeping without queue" state, and why is process in it for so long? This is an 4-CPU amd64 system with 4Gb of RAM. Only 16% of the swap is currently in use and

Hi, folks @ freebsd-security. First, I am not sure if this is apropriate topic for that list, so sorry, if it is not. Some time ago I have read rfc1948 (protection from blind TCP spoofing) and became interested in the way how it is implemented in FreeBSD. After some googling (BTW if you like Google you might be interested in this: http://register.spectator.ru/img/bart.gif ), I found this:

In http://docs.freebsd.org/cgi/mid.cgi?200402260743.IAA18903 it seems RELENG_4 is vulnerable. Is there any work around to a system that has to have ports open ? Version: 1 2/18/2004@03:47:29 GMT >Initial report > <<https://ialert.idefense.com/KODetails.jhtml?irId=207650>https://ialert.idefense.com/KODetails.jhtml?irId=207650; >ID#207650: >FreeBSD Memory Buffer

This patch replaces the vmap/vunmap's use of raw pointers in GEM object functions with instances of struct dma_buf_map. GEM backends are converted as well. For most of them, this simply changes the returned type. TTM-based drivers now return information about the location of the memory, either system or I/O memory. GEM VRAM helpers and qxl now use ttm_bo_vmap() et al. Amdgpu, nouveau and

Forwarded message: > From full-disclosure-admin@lists.netsys.com Wed Apr 21 11:49:12 2004 > To: full-disclosure@lists.netsys.com > From: Darren Bounds <dbounds@intrusense.com> > Subject: [Full-Disclosure] IETF Draft - Fix for TCP vulnerability > Date: Tue, 20 Apr 2004 18:19:58 -0400 > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > >