Jack Vogel wrote:
The next driver I that I release via Intel channels is going to
merge the code for 6 and 7. I was thinking that I could check that
into the tip and it would make the most current version buildable
on either RELEASE, was wondering if that is looked upon favorably
or not? I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Andrew Reilly wrote:
On Wed, Jul 25, 2007 at 05:24:25AM +1000, Peter Jeremy wrote:
On 2007-Jul-24 16:00:08 +0100, Pete French [EMAIL PROTECTED] wrote:
Yes it does. The major difference is that ntpd will use a source
port of 123 whilst ntpdate
Andrew Reilly wrote:
Peter Jeremy wrote:
The major difference is that ntpd will use a source port
of 123 whilst ntpdate will use a dynamic source port.
Is that behaviour that can be defeated? If it uses a fixed
source port, then multiple ntpd clients behind a nat firewall
will be
Jeremy Chadwick wrote:
* Hard disks are growing in capacity, but are not growing in physical
size. We're pushing 1TB in a 3.5 form factor. And the same applies to
laptop (2.5) drives. The margin of error continues to increase as we
try to cram more and more data in such a small medium.
On 2007-Jul-25 10:30:25 +1000, Andrew Reilly [EMAIL PROTECTED] wrote:
On Wed, Jul 25, 2007 at 05:24:25AM +1000, Peter Jeremy wrote:
On 2007-Jul-24 16:00:08 +0100, Pete French [EMAIL PROTECTED] wrote:
Yes it does. The major difference is that ntpd will use a source
port of 123 whilst ntpdate
You might be better off running ntpd on the firewall and having
the inside hosts sync to it.
That would be nice - except my problem is that the firewal is the only
one on which ntp *doest* run! :-)
Thanks for all the other suggestions - will take a look a them later today
and see if I can
lagg on RELENG_6 is currently broken due to subtle differences that
wernt taken into account when it was MFCd. Can you please test this
patch.
Erp! Do you have any mor einfo on tyhis - what kinds of things does
this break ? Since lagg arrived I have deployed it on all our production
machines.
I assume the security team are already working on this but
cant hurt to ask:
http://www.net-security.org/secworld.php?id=5366
Regards
Steve
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom
At 10:50 AM 7/25/2007, Steven Hartland wrote:
I assume the security team are already working on this but
There was a posting on the security list already about it.
http://lists.freebsd.org/pipermail/freebsd-security/2007-July/004411.html
---Mike
cant hurt to ask:
Steven Hartland wrote:
I assume the security team are already working on this but
cant hurt to ask:
Before you ask questions on a public list it's generally considered
polite to do a little checking yourself, especially in an open source
project. As Mike pointed out, the secteam had already
Scott Long wrote:
Howard Goldstein wrote:
Testbed: Pair of WDC3200AAKS 320gb SATA, freshly newfsd 10gb filesystem
mounted with softupdates, remounted after each test
P4 @ 3ghz on a P4P800 in 6.2-STABLE, single user mode, ICH5R controller
detects these SATA-II drives inexplicably as SATA-I
On Thu, Jul 26, 2007 at 01:02:06AM +0100, Pete French wrote:
All zeros! very interesting - am surprised the switch didn't kick up
a fuss about that. Well, patch applied and rebooting...
...and now all my outgoing packets have the correct MAC address as expected
on them. I alos notice that
Scott Long wrote:
Howard Goldstein wrote:
Scott Long wrote:
Howard Goldstein wrote:
Testbed: Pair of WDC3200AAKS 320gb SATA, freshly newfsd 10gb filesystem
mounted with softupdates, remounted after each test
P4 @ 3ghz on a P4P800 in 6.2-STABLE, single user mode, ICH5R
Howard Goldstein wrote:
Scott Long wrote:
Howard Goldstein wrote:
Testbed: Pair of WDC3200AAKS 320gb SATA, freshly newfsd 10gb filesystem
mounted with softupdates, remounted after each test
P4 @ 3ghz on a P4P800 in 6.2-STABLE, single user mode, ICH5R controller
detects these SATA-II drives
On Wed, Jul 25, 2007 at 10:42:21PM +0400, Alexey Karagodov wrote:
patch did not help ...
ifconfig:
lagg0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
inet 10.0.0.1 netmask 0x broadcast 10.0.255.255
inet 10.0.0.2 netmask 0x broadcast
Howard Goldstein wrote:
Howard Goldstein wrote:
Has anyone done any benchmarks in desktop or server environment
comparing geom with an ICH controller through the ar device in RAID1
service? Teh google, it seems to pick up grammar school math
assignments lots of what may be relevant hits for
Most people didnt see a problem which is why this slipped through.
tcpdump on another host with the -e flag and see what the src mac is.
All zeros! very interesting - am surprised the switch didn't kick up
a fuss about that. Well, patch applied and rebooting...
thanks,
-pete.
All zeros! very interesting - am surprised the switch didn't kick up
a fuss about that. Well, patch applied and rebooting...
...and now all my outgoing packets have the correct MAC address as expected
on them. I alos notice that I am now only seeing packets destined for the
appropriate machine
On Wed, Jul 25, 2007 at 12:54:30PM +0100, Pete French wrote:
lagg on RELENG_6 is currently broken due to subtle differences that
wernt taken into account when it was MFCd. Can you please test this
patch.
Erp! Do you have any mor einfo on tyhis - what kinds of things does
this break ?
patch did not help ...
ifconfig:
# ifconfig
em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
options=1bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING
ether XX:XX:XX:XX:XX:XX
media: Ethernet autoselect (1000baseTX full-duplex)
status: active
lagg: laggdev
Howard Goldstein wrote:
Has anyone done any benchmarks in desktop or server environment
comparing geom with an ICH controller through the ar device in RAID1
service? Teh google, it seems to pick up grammar school math
assignments lots of what may be relevant hits for fortunate speakers of
21 matches
Mail list logo
