Dear ANZ customer
Your ANZ Internet Banking access has been violated. We suspected someone other
than you with IP 178.210.92*** trying to access your information's.
Please verify your banking information with us to
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
On Mon, Jan 10, 2011 at 11:40:37PM -0800, Chris H wrote:
Greetings, and thank you for the heads up.
On Mon, January 10, 2011 2:22 pm, Rick Macklem wrote:
I just commited a patch (r217242) to head. Anyone who is using client
side NFS on FreeBSD8.n should apply this patch. It is also available
Hello Jeremy, and thank you for your reply.
On Tue, January 11, 2011 12:17 am, Jeremy Chadwick wrote:
On Mon, Jan 10, 2011 at 11:40:37PM -0800, Chris H wrote:
Greetings, and thank you for the heads up.
On Mon, January 10, 2011 2:22 pm, Rick Macklem wrote:
I just commited a patch (r217242) to
I just commited a patch (r217242) to head. Anyone who is using client
side NFS on FreeBSD8.n should apply this patch. It is also available at:
http://people.freebsd.org/~rmacklem/krpc.patch
It fixes a problem where the kernel rpc assumes that 4 bytes of data
exists in the first mbuf without
Greetings, and thank you for the heads up.
On Mon, January 10, 2011 2:22 pm, Rick Macklem wrote:
I just commited a patch (r217242) to head. Anyone who is using client
side NFS on FreeBSD8.n should apply this patch. It is also available at:
http://people.freebsd.org/~rmacklem/krpc.patch
It
09.08.08, 18:30, Kurt Jaeger [EMAIL PROTECTED]:
Hi!
So I do not think that problem is with the network mask. Because of even
ping 10.11.16.14
returns network is unreachable!
Now when I upgraded to v7 I see trouble described earlier.
So this is must be counted as BUG of v7
It might
(this time
configured as /32s on other physical interfaces) and again, after a
while the system lost connectivity to its main subnet and forgot how
to ARP for addresses on the interface. An important similarity - the
routing info like yours showed the attached network with the G flag, as
being
# uname -a
FreeBSD gorodok.kes.net.ua 7.0-RELEASE-p3 FreeBSD 7.0-RELEASE-p3 #0: Sun Aug 3
13:18:21 EEST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/KES_KERN_v7 i386
# netstat -nr
Routing tables
Internet:
DestinationGatewayFlags
Usually if there is more than IP in a given subnet on an interface, you
give it a /32 netmask. Only the first IP in a subnet should have the
full netmask.
So your example should look like this:
inet 10.11.16.14 netmask 0xff00 broadcast 10.11.16.255
inet 10.11.16.9 netmask
Andrew Snow wrote:
Usually if there is more than IP in a given subnet on an interface, you
give it a /32 netmask. Only the first IP in a subnet should have the
full netmask.
So your example should look like this:
inet 10.11.16.14 netmask 0xff00 broadcast 10.11.16.255
inet
09.08.08, 16:22, Matthew Seaman [EMAIL PROTECTED]:
Andrew Snow wrote:
Usually if there is more than IP in a given subnet on an interface, you
give it a /32 netmask. Only the first IP in a subnet should have the
full netmask.
So your example should look like this:
the system lost connectivity to its main subnet and forgot how
to ARP for addresses on the interface. An important similarity - the
routing info like yours showed the attached network with the G flag, as
being reachable via the gateway address within the same subnet.
I can't troubleshoot
[1][chase.gif]
Dear Chase customer,
As the Internet and information technology enable us to expand our
services,we are committed to maintaining
the trust customers have placed in us for protecting the privacy and
security of information we have about you.
In order to
User Freebsd wrote this message on Mon, Jul 31, 2006 at 22:44 -0300:
For those that haven't been following the discussion on this, the iir(4)
driver in FreeBSD 6.x appears to have a deadlock issue under medium to
heavy load, where the 'blocked' state just continues to rise until file
On Fri, 4 Aug 2006, John-Mark Gurney wrote:
User Freebsd wrote this message on Mon, Jul 31, 2006 at 22:44 -0300:
For those that haven't been following the discussion on this, the iir(4)
driver in FreeBSD 6.x appears to have a deadlock issue under medium to
heavy load, where the 'blocked' state
A quick follow up on this email ... please note that I have not, in this
email, pointed to anything but the iir(4) driver, and, more specifically,
the GDT controller card ...
I have been using Adaptec products since the early 90's, and, until
upgrading to FreeBSD 6.x, *never* had a
'k, I finally got ahold of someone @ adaptec, and the official word seems
to be:
FreeBSD 6 is not officially supported for the GDT based ICP RAID
controllers. Nevertheless the inbox driver should work.
Great, well, the inbox driver doesn't work with FreeBSD 6.x, and support
doesn't exist
Hi all
It's not important (maybe not event a bug), but I just want to report
I run FreeBSD stable with PAE kernel on SMP (two proc) AMD Opteron on
FreeBSD i386 version.
I've this when I use top
PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND
88552 root1 119
19 matches
Mail list logo
