On Thu, 17 Jan 2008, Daniel O'Connor wrote:
DPMS should work with the VESA driver even, not to discourage you
from the right solution.
The X log file says DPMS is enabled but doing 'xset dpms force off'
doesn't do anything (although when you move the mouse or press a key
the whole display
Does anyone have a G33 chipset system working in 7.x?
I have a 6.3 install here and it isn't working with that so I have been
merging things from HEAD but it still doesn't work.
It would be worth switching to 7.x if it worked there though :)
--
Daniel O'Connor software and network engineer
On Aug 13, 2008, at 5:24 PM, Tom Evans wrote:
On Wed, 2008-08-13 at 16:56 +0200, Borja Marcos wrote:
Personally, I find PHP far too troublesome to run threaded. These
days,
I use an event MPM based front-end apache 2.2, which reverse proxies
to
either a prefork MPM apache 2.2 with
On Sun, 3 Aug 2008, Robert Watson wrote:
This is an advance warning that, late next week, I will be merging a fairly
large set of changes to the IPv4 and IPv6 protocols layered over the
inpcb/inpcbinfo kernel infrastructure. To be specific, this affects TCP,
UDP, and raw sockets on both
On Mon, 18 Aug 2008 17:16:36 +0930
Daniel O'Connor [EMAIL PROTECTED] wrote:
Does anyone have a G33 chipset system working in 7.x?
I have a working Q35 chipset (which is using the same driver)
under latest -STABLE.
FreeBSD 7.0-STABLE #0: Sat Aug 16 17:36:46 BST 2008
I have a 6.3
| By Daniel O'Connor [EMAIL PROTECTED]
| [ 2008-08-18 09:47 +0200 ]
Does anyone have a G33 chipset system working in 7.x?
I have a 6.3 install here and it isn't working with that so I have been
merging things from HEAD but it still doesn't work.
It
On Mon, 18 Aug 2008, Aragon Gouveia wrote:
| By Daniel O'Connor [EMAIL PROTECTED]
| [ 2008-08-18 09:47 +0200 ]
|
Does anyone have a G33 chipset system working in 7.x?
I have a 6.3 install here and it isn't working with that so I have
been merging
On Mon, 2008-08-18 at 09:06 +0100, Oliver Peter wrote:
On Mon, 18 Aug 2008 17:16:36 +0930
Daniel O'Connor [EMAIL PROTECTED] wrote:
Does anyone have a G33 chipset system working in 7.x?
...
Unfortunately, the drm module does not recognize my chipset
(so I don't have DRI support under
On Mon, 18 Aug 2008 10:18:14 +0100
Tom Evans [EMAIL PROTECTED] wrote:
On Mon, 2008-08-18 at 09:06 +0100, Oliver Peter wrote:
[...]
Robert Noland posted last Wednesday on x11@ [1] that he had prepared
an update to FreeBSD's drm kernel modules, which includes support for
the G33 [2].
On Mon, Aug 18, 2008 at 05:16:36PM +0930, Daniel O'Connor wrote:
Does anyone have a G33 chipset system working in 7.x?
I have a 6.3 install here and it isn't working with that so I have been
merging things from HEAD but it still doesn't work.
It would be worth switching to 7.x if it
On Mon, 18 Aug 2008, Tom Evans wrote:
Robert Noland posted last Wednesday on x11@ [1] that he had prepared
an update to FreeBSD's drm kernel modules, which includes support for
the G33 [2].
Ahh excellent, thanks for the pointers!
Something to try tomorrow :)
Cheers
Tom
[1]
On Mon, 18 Aug 2008, Oliver Peter wrote:
On Mon, 18 Aug 2008 17:16:36 +0930
Daniel O'Connor [EMAIL PROTECTED] wrote:
Does anyone have a G33 chipset system working in 7.x?
I have a working Q35 chipset (which is using the same driver)
under latest -STABLE.
FreeBSD 7.0-STABLE #0: Sat
This problem has been reported a couple of times but it is not clear what
change caused it.
I upgraded my RELENG_6/amd64 system yesterday and ran into
this bug.
There's a fix (and an explanation of the bug) now in PR bin/124353.
Koshy
___
At 04:14 AM 8/18/2008, Robert Watson wrote:
On Sun, 3 Aug 2008, Robert Watson wrote:
This is an advance warning that, late next week, I will be merging
a fairly large set of changes to the IPv4 and IPv6 protocols
layered over the inpcb/inpcbinfo kernel infrastructure. To be
specific, this
Joseph Koshy wrote:
This problem has been reported a couple of times but it is not clear what
change caused it.
I upgraded my RELENG_6/amd64 system yesterday and ran into
this bug.
There's a fix (and an explanation of the bug) now in PR bin/124353.
Koshy
Thanks very much for tracking
On Monday 18 August 2008 09:37:51 am Mike Tancsa wrote:
At 04:14 AM 8/18/2008, Robert Watson wrote:
On Sun, 3 Aug 2008, Robert Watson wrote:
This is an advance warning that, late next week, I will be merging
a fairly large set of changes to the IPv4 and IPv6 protocols
layered over the
On Friday 15 August 2008 05:55:23 pm Torfinn Ingolfsen wrote:
Hello,
Do you remember the zip[1] disks? The original 100 Mbyte ones? well
recently, I got a scsi zip drive (internal) with a scsi card (Adaptec
ava-2904) and some zip-100 disks, and a request to try to copy the data
from those
The following happens in 7.0-STABLE built from the source csuped
either yesterday's or this morning:
$ groff -mm -t -Tascii tmp.mm
groff: can't find `DESC' file
groff:fatal error: invalid device `ascii'
$ truss -mm -t -Tascii tmp.mm 21
Oops, scratch (do not see) this piece in my previous message:
,--- I/Alex (Mon, 18 Aug 2008 11:09:10 -0400) *
| $ truss -mm -t -Tascii tmp.mm 21 | grep DESC
| ++ [ ~/doc1/employ/ab-initio ] ++
`-*
Thanks,
-- Alex -- [EMAIL PROTECTED] --
At 10:24 AM 8/18/2008, John Baldwin wrote:
Author: kmacy
Date: Thu Jul 31 22:42:27 2008
New Revision: 181075
URL: http://svn.freebsd.org/changeset/base/181075
Log:
MFC ARP update hooks and change to arpresolve to do arp
resolution without a
pending mbuf to transmit
Modified:
It's not really a problem, as the device and the SATA hard drives and
DVD+RW attached to the bus operate properly, but I'm wondering why the
ICH9 controller (in AHCI mode) on the Asus P5K-E motherboard shows up
as:
atapci1: Intel AHCI controller port
On Mon, Aug 18, 2008 at 11:47:25AM -0400, Josh Carroll wrote:
It's not really a problem, as the device and the SATA hard drives and
DVD+RW attached to the bus operate properly, but I'm wondering why the
ICH9 controller (in AHCI mode) on the Asus P5K-E motherboard shows up
as:
atapci1: Intel
At 10:24 AM 8/18/2008, John Baldwin wrote:
Edit src/sys/conf/files
Add delta 1.1243.2.32 2008.07.30.20.35.41 kmacy
Edit src/sys/netinet/tcp_subr.c
Add delta 1.300.2.4 2008.07.30.20.35.41 kmacy
Edit src/sys/netinet/tcp_syncache.c
Add delta 1.130.2.9 2008.07.30.20.35.41 kmacy
got it
On Mon, Aug 18, 2008 at 9:22 AM, Mike Tancsa [EMAIL PROTECTED] wrote:
At 10:24 AM 8/18/2008, John Baldwin wrote:
Edit src/sys/conf/files
Add delta 1.1243.2.32 2008.07.30.20.35.41 kmacy
Edit src/sys/netinet/tcp_subr.c
Add delta 1.300.2.4 2008.07.30.20.35.41 kmacy
At 12:55 PM 8/18/2008, Kip Macy wrote:
got it
Thanks. The problem manifests itself soon after boot. There is
nothing special about the box, it has 2 em network interfaces doing a
lot of sendmail as well as local recursive DNS for itself and a few
other sendmail boxes and also talks to a
On Mon, 18 Aug 2008 10:33:05 -0400
John Baldwin [EMAIL PROTECTED] wrote:
Can you get the stack trace?
Like this?
[EMAIL PROTECTED] kgdb kernel.debug /var/crash/vmcore.0
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General
Because your motherboard allows for the enabling of AHCI on the ICH9.
This is often a BIOS feature you can turn on/off.
I double checked and it is indeed set properly to AHCI mode (instead
of enhanced or legacy). I also upgrade the BIOS and it still shows
up the same way.
I don't believe it's
I'm trying to build nanobsd. I get the error below. Any ideas?
-
stage 4.2: building libraries
--
cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj/nanobsd.soekris/ MACHINE_ARCH=i386
On Mon, 18 Aug 2008 22:14:04 +0300, Dan Pelleg [EMAIL PROTECTED]
wrote:
I'm trying to build nanobsd. I get the error below. Any ideas?
/usr/src/gnu/lib/libgcc/../../../contrib/gcc/tsystem.h:111:18: error:
time.h: No such file or directory
*** Error code 1
Do you have WITHOUT_TOOLCHAIN set?
Hi Mike,
Could you please check that this doesn't happen on HEAD as well? This
same code has been in 8 since shortly after the branch.
Thanks,
Kip
On Mon, Aug 18, 2008 at 10:14 AM, Mike Tancsa [EMAIL PROTECTED] wrote:
At 12:55 PM 8/18/2008, Kip Macy wrote:
got it
Thanks. The problem
Hi!
Last week I discovered an LOR on 7-STABLE (last build: 2008-Aug-17,
RELENG_7).
I can easily recreate the problem when running a synproxy state rule for
incoming tcp connections and ssh'ing to my box.
W/o using synproxy state (keep'ing state instead), no LOR takes place.
lock order
At 06:32 PM 8/18/2008, Kip Macy wrote:
Hi Mike,
Could you please check that this doesn't happen on HEAD as well? This
same code has been in 8 since shortly after the branch.
Hi,
I dont have any easy way to migrate the box to HEAD and then
back. Can I just boot a kernel from HEAD ?
On Mon, Aug 18, 2008 at 3:42 PM, Mike Tancsa [EMAIL PROTECTED] wrote:
At 06:32 PM 8/18/2008, Kip Macy wrote:
Hi Mike,
Could you please check that this doesn't happen on HEAD as well? This
same code has been in 8 since shortly after the branch.
Hi,
I dont have any easy way to migrate
On Mon, 18 Aug 2008, Mike Tancsa wrote:
At 06:32 PM 8/18/2008, Kip Macy wrote:
Could you please check that this doesn't happen on HEAD as well? This same
code has been in 8 since shortly after the branch.
I dont have any easy way to migrate the box to HEAD and then back.
Can I just
On Mon, 18 Aug 2008 10:38:11 +0100
Oliver Peter [EMAIL PROTECTED] wrote:
On Mon, 18 Aug 2008 10:18:14 +0100
Tom Evans [EMAIL PROTECTED] wrote:
On Mon, 2008-08-18 at 09:06 +0100, Oliver Peter wrote:
[...]
Robert Noland posted last Wednesday on x11@ [1] that he had prepared
an
Josh Carroll wrote:
atapci1: Intel AHCI controller port
0xac00-0xac07,0xa880-0xa883,0xa800-0xa807,0xa480-0xa483,0xa400-0xa41f
mem 0xfbffe800-0xfbffefff irq 22 at device 31.2 on pci0
The chip ID (0x29228086) from pciconf:
[EMAIL PROTECTED]:0:31:2:class=0x010601 card=0x82771043
36 matches
Mail list logo