-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/04/2010 23:35:22, Pieter de Goeje wrote:
There is a predefined kernel configuration file for Xen: XEN. You might try
building that.
... unless you're on an amd64 platform, when it's XENHVM.
% find /usr/src/sys -name '*XEN*'
on 08/04/2010 04:29 Akephalos said the following:
Attilio, I csup-dated several hours ago and rebuilt and installed the kernel
(and world, in case it matters).
%uname -a FreeBSD free.bsd369441.org 8.0-STABLE FreeBSD 8.0-STABLE #0: Thu
Apr 8 03:01:13 EEST 2010
2010/4/8 Andriy Gapon a...@icyb.net.ua:
on 08/04/2010 04:29 Akephalos said the following:
Attilio, I csup-dated several hours ago and rebuilt and installed the kernel
(and world, in case it matters).
%uname -a FreeBSD free.bsd369441.org 8.0-STABLE FreeBSD 8.0-STABLE #0: Thu
Apr 8 03:01:13
on 08/04/2010 10:22 Attilio Rao said the following:
2010/4/8 Andriy Gapon a...@icyb.net.ua:
on 08/04/2010 04:29 Akephalos said the following:
Attilio, I csup-dated several hours ago and rebuilt and installed the kernel
(and world, in case it matters).
%uname -a FreeBSD free.bsd369441.org
On Wed, Apr 7, 2010 at 7:36 AM, Ion-Mihai Tetcu ite...@freebsd.org wrote:
On Wed, 7 Apr 2010 07:20:47 -0500
Antonio Olivares olivares14...@gmail.com wrote:
[ .. ]
=== Port directory: /usr/ports/sysutils/fusefs-kmod
=== This port is marked IGNORE
=== requires the userland
On Thu, Apr 08, 2010 at 07:42:06AM -0500, Antonio Olivares wrote:
On Wed, Apr 7, 2010 at 7:36 AM, Ion-Mihai Tetcu ite...@freebsd.org wrote:
On Wed, 7 Apr 2010 07:20:47 -0500
Antonio Olivares olivares14...@gmail.com wrote:
[ .. ]
=== Port directory: /usr/ports/sysutils/fusefs-kmod
Hi Jack,
I looks like the latest MFC to RELENG_8 for the em driver
has caused a regression. The box is not doing much as its a
development server in the lab. This is an Intel MB (DX58SO). dmesg
and pciconf -lvc attached.
Apr 6 14:27:13 ich10 kernel: em0: Watchdog timeout --
On Thu, 08 Apr 2010 10:11:50 +0300
Andriy Gapon a...@icyb.net.ua wrote:
on 08/04/2010 04:29 Akephalos said the following:
Attilio, I csup-dated several hours ago and rebuilt and installed the kernel
(and world, in case it matters).
%uname -a FreeBSD free.bsd369441.org 8.0-STABLE FreeBSD
At 09:12 AM 4/8/2010, Mike Tancsa wrote:
Hi Jack,
I looks like the latest MFC to RELENG_8 for the em driver
has caused a regression. The box is not doing much as its a
development server in the lab. This is an Intel MB (DX58SO). dmesg
and pciconf -lvc attached.
Here are the stats
On 2010-04-08 14:42, Antonio Olivares wrote:
On Wed, Apr 7, 2010 at 7:36 AM, Ion-Mihai Tetcuite...@freebsd.org wrote:
On Wed, 7 Apr 2010 07:20:47 -0500
Antonio Olivaresolivares14...@gmail.com wrote:
[ .. ]
=== Port directory: /usr/ports/sysutils/fusefs-kmod
=== This port is
on 08/04/2010 15:04 Akephalos said the following:
On Thu, 08 Apr 2010 10:11:50 +0300
Andriy Gapon a...@icyb.net.ua wrote:
Interesting, I couldn't see anything obviously wrong about your hardware.
Could you please post a verbose dmesg from a problematic boot somewhere?
Also, output of 'vmstat
On Thu, 08 Apr 2010 16:33:09 +0300
Andriy Gapon a...@icyb.net.ua wrote:
Thank you for the data.
So looks like RTC indeed doesn't generate any interrupts after startup.
Still I would like to get a _verbose_ dmesg :-)
--
Andriy Gapon
Sorry, I missed that, here it is :D.
Mihai
--
Hi,
Let's say i need to run a few php/sql based web sites and I would like
to maintain uptime of about 99,99% per month.
From what You say I need some level of HA system, to maintain the
required uptime.
Okay
(i'm skiping (..) network issues at the moment).
Then you won't succeed.
on 08/04/2010 15:44 Akephalos said the following:
On Thu, 08 Apr 2010 16:33:09 +0300
Andriy Gapon a...@icyb.net.ua wrote:
Thank you for the data.
So looks like RTC indeed doesn't generate any interrupts after startup.
Still I would like to get a _verbose_ dmesg :-)
--
Andriy Gapon
On Thu, 08 Apr 2010 17:11:44 +0300
Andriy Gapon a...@icyb.net.ua wrote:
on 08/04/2010 15:44 Akephalos said the following:
On Thu, 08 Apr 2010 16:33:09 +0300
Andriy Gapon a...@icyb.net.ua wrote:
Thank you for the data.
So looks like RTC indeed doesn't generate any interrupts after
OK, some more data... It seems dhclient is getting upset as well
since the updated driver
Apr 8 10:28:37 ich10 dhclient[1383]: DHCPDISCOVER on em0 to
255.255.255.255 port 67 interval 6
Apr 8 10:28:38 ich10 dhclient[1383]: ip length 328 disagrees with
bytes received 332.
Apr 8 10:28:38
Really shooting in the dark here: are there any BIOS options about HPET and RTC
on
this system? Can you try playing with them?
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To
On Thu, Apr 8, 2010 at 9:46 AM, Mike Tancsa m...@sentex.net wrote:
OK, some more data... It seems dhclient is getting upset as well since the
updated driver
Apr 8 10:28:37 ich10 dhclient[1383]: DHCPDISCOVER on em0 to 255.255.255.255
port 67 interval 6
Apr 8 10:28:38 ich10 dhclient[1383]:
Brandon,
Did the checkin of yesterday afternoon resolve the problem of the win7
systems in
VirtualBox? I will continue to look at this today.
Jack
On Thu, Apr 8, 2010 at 8:29 AM, Brandon Gooch
jamesbrandongo...@gmail.comwrote:
On Thu, Apr 8, 2010 at 9:46 AM, Mike Tancsa m...@sentex.net
On Thu, Apr 8, 2010 at 11:04 AM, Jack Vogel jfvo...@gmail.com wrote:
Brandon,
Did the checkin of yesterday afternoon resolve the problem of the win7
systems in
VirtualBox? I will continue to look at this today.
Jack
Sorry, I was a little unclear on that :(
No, the issue wasn't resolved
On Tuesday 06 April 2010 23:24:52 Peter Jeremy wrote:
On 2010-Apr-06 00:37:51 +0400, Artem Kim artem_...@inbox.ru wrote:
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0x7d4c
This suggests an offset from a NULL pointer.
0x8069ac41 is in
Mike, I noticed this connection is only 100Mb, that isn't accidental? And,
is it possible for
you to check a connection at 1Gb and see if the watchdogs don't happen.
My test engineer is running this code, and we are having trouble repro'ing
the issue, so any
clues might help. Is the kernel 64 or
On Thu, Apr 8, 2010 at 11:52 AM, Jack Vogel jfvo...@gmail.com wrote:
Mike, I noticed this connection is only 100Mb, that isn't accidental? And,
is it possible for
you to check a connection at 1Gb and see if the watchdogs don't happen.
My test engineer is running this code, and we are having
On Thu, Apr 8, 2010 at 10:01 AM, Brandon Gooch
jamesbrandongo...@gmail.comwrote:
On Thu, Apr 8, 2010 at 11:52 AM, Jack Vogel jfvo...@gmail.com wrote:
Mike, I noticed this connection is only 100Mb, that isn't accidental?
And,
is it possible for
you to check a connection at 1Gb and see if
On Sat, Apr 3, 2010 at 6:21 PM, Masoom Shaikh masoom.sha...@gmail.com wrote:
On Sun, Mar 28, 2010 at 5:38 PM, Ivan Voras ivo...@freebsd.org wrote:
On 28 March 2010 16:42, Masoom Shaikh masoom.sha...@gmail.com wrote:
lets assume if this is h/w problem, then how can other OSes overcome
this ?
On Thu, Apr 8, 2010 at 12:06 PM, Jack Vogel jfvo...@gmail.com wrote:
On Thu, Apr 8, 2010 at 10:01 AM, Brandon Gooch jamesbrandongo...@gmail.com
wrote:
On Thu, Apr 8, 2010 at 11:52 AM, Jack Vogel jfvo...@gmail.com wrote:
Mike, I noticed this connection is only 100Mb, that isn't accidental?
On Thu, Apr 8, 2010 at 10:18 AM, Brandon Gooch
jamesbrandongo...@gmail.comwrote:
On Thu, Apr 8, 2010 at 12:06 PM, Jack Vogel jfvo...@gmail.com wrote:
On Thu, Apr 8, 2010 at 10:01 AM, Brandon Gooch
jamesbrandongo...@gmail.com
wrote:
On Thu, Apr 8, 2010 at 11:52 AM, Jack Vogel
At 12:52 PM 4/8/2010, Jack Vogel wrote:
Mike, I noticed this connection is only 100Mb, that isn't
accidental? And, is it possible for
you to check a connection at 1Gb and see if the watchdogs don't happen.
My test engineer is running this code, and we are having trouble
repro'ing the issue,
On Thu, Apr 8, 2010 at 4:45 PM, Anoop Kumar Narayanan
anoop...@gmail.com wrote:
On Sat, Apr 3, 2010 at 6:21 PM, Masoom Shaikh masoom.sha...@gmail.com wrote:
On Sun, Mar 28, 2010 at 5:38 PM, Ivan Voras ivo...@freebsd.org wrote:
On 28 March 2010 16:42, Masoom Shaikh masoom.sha...@gmail.com wrote:
On Thu, Apr 08, 2010 at 10:46:22AM -0400, Mike Tancsa wrote:
OK, some more data... It seems dhclient is getting upset as well
since the updated driver
Apr 8 10:28:37 ich10 dhclient[1383]: DHCPDISCOVER on em0 to
255.255.255.255 port 67 interval 6
Apr 8 10:28:38 ich10 dhclient[1383]: ip
Both of you try something for me:
Assuming you are using the latest code in HEAD, at line 4042 please make
this insert:
/* Strip the CRC */
rctl |= E1000_RCTL_SECRC;
And try things again, I think this will solve at least the DHCP thing. I
hope.
Jack
On Thu,
LOL, what timing :)
On Thu, Apr 8, 2010 at 11:17 AM, Pyun YongHyeon pyu...@gmail.com wrote:
On Thu, Apr 08, 2010 at 10:46:22AM -0400, Mike Tancsa wrote:
OK, some more data... It seems dhclient is getting upset as well
since the updated driver
Apr 8 10:28:37 ich10 dhclient[1383]:
On Thu, Apr 8, 2010 at 11:17 AM, Pyun YongHyeon pyu...@gmail.com wrote:
On Thu, Apr 08, 2010 at 10:46:22AM -0400, Mike Tancsa wrote:
OK, some more data... It seems dhclient is getting upset as well
since the updated driver
Apr 8 10:28:37 ich10 dhclient[1383]: DHCPDISCOVER on em0 to
You know, I'm wondering if the so-called ALTQ fix, which makes the TX
start always queue is causing the problem on that side?
Jack
On Thu, Apr 8, 2010 at 11:22 AM, Jack Vogel jfvo...@gmail.com wrote:
On Thu, Apr 8, 2010 at 11:17 AM, Pyun YongHyeon pyu...@gmail.com wrote:
On Thu, Apr 08,
At 02:17 PM 4/8/2010, Pyun YongHyeon wrote:
Try this patch. It should fix the issue. It seems Jack forgot to
strip CRC bytes as old em(4) didn't strip it, probably to
workaround silicon bug of old em(4) controllers.
Thanks! The attached patch does indeed fix the dhclient issue.
It seems
Bigger question is will it fix Brandon's VirtualBox issue??
Jack
On Thu, Apr 8, 2010 at 11:31 AM, Mike Tancsa m...@sentex.net wrote:
At 02:17 PM 4/8/2010, Pyun YongHyeon wrote:
Try this patch. It should fix the issue. It seems Jack forgot to
strip CRC bytes as old em(4) didn't strip it,
On Thu, Apr 08, 2010 at 11:27:10AM -0700, Jack Vogel wrote:
You know, I'm wondering if the so-called ALTQ fix, which makes the TX
start always queue is causing the problem on that side?
I'm not sure because I didn't configure ALTQ so it might be NOP for
non-ALTQ case.
Jack
On Thu, Apr
Try the code I just checked in, it puts in the CRC stripping, but also
tweaks the
TX code, this may resolve the watchdogs. Let me know.
Cheers,
Jack
On Thu, Apr 8, 2010 at 11:39 AM, Pyun YongHyeon pyu...@gmail.com wrote:
On Thu, Apr 08, 2010 at 11:27:10AM -0700, Jack Vogel wrote:
You know,
On Thu, Apr 8, 2010 at 2:17 PM, Jack Vogel jfvo...@gmail.com wrote:
Try the code I just checked in, it puts in the CRC stripping, but also
tweaks the
TX code, this may resolve the watchdogs. Let me know.
Cheers,
Jack
Yes, this is indeed the fix for both the dhclient and VirtualBox issue
On Thu, Apr 08, 2010 at 02:31:18PM -0400, Mike Tancsa wrote:
At 02:17 PM 4/8/2010, Pyun YongHyeon wrote:
Try this patch. It should fix the issue. It seems Jack forgot to
strip CRC bytes as old em(4) didn't strip it, probably to
workaround silicon bug of old em(4) controllers.
Thanks! The
At 04:56 PM 4/8/2010, Pyun YongHyeon wrote:
On Thu, Apr 08, 2010 at 02:31:18PM -0400, Mike Tancsa wrote:
At 02:17 PM 4/8/2010, Pyun YongHyeon wrote:
Try this patch. It should fix the issue. It seems Jack forgot to
strip CRC bytes as old em(4) didn't strip it, probably to
workaround silicon
Only one device support by em does multiqueue right now, and that is
Hartwell, 82574.
Jack
On Thu, Apr 8, 2010 at 2:05 PM, Mike Tancsa m...@sentex.net wrote:
At 04:56 PM 4/8/2010, Pyun YongHyeon wrote:
On Thu, Apr 08, 2010 at 02:31:18PM -0400, Mike Tancsa wrote:
At 02:17 PM 4/8/2010, Pyun
On Thu, Apr 08, 2010 at 02:06:09PM -0700, Jack Vogel wrote:
Only one device support by em does multiqueue right now, and that is
Hartwell, 82574.
Thanks for the info.
Mike, here is updated patch. Now UDP bulk TX transfer performance
recovered a lot(about 890Mbps) but it still shows bad
Greetings,
the onboard Realtek Ethernet on my Asus M4A89GTD PRO is not functioning.
I use FreeBSD 8.0-STABLE with a generic kernel (amd64). Everything was
updated March 27, 2010.
Is it a bug?
Thanks,
Michael
pcib4: ACPI PCI-PCI bridge at device 21.0 on pci0
pci4: ACPI
note: i apologize for the new thread, but i accidently deleted the
old one.
I emailed a few days back about having issues running 8-STABLE in a
Xen environment. I solved this, sort of.
a) some more info on the environment:
-it's a Xen HVM hosted environment. So, the XEN DomU kernel
Ah, ok, let me play around with it a bit, perhaps I'll make it definable,
of course if there is no positive benefit from using it it would seem silly
to leave it around :)
Will look at your patch changes and that issue tomorrow. Thanks
for your efforts!
Jack
On Thu, Apr 8, 2010 at 4:07 PM,
On Thu, Apr 8, 2010 at 6:50 PM, Michael Beckmann mich...@apfel.de wrote:
re0: RealTek
8168/8168B/8168C/8168CP/8168D/8168DP/8111B/8111C/8111CP/8111DP
PCIe Gigabit Ethernet port 0xe800-0xe8ff mem
0xfdfff000-0xfdff,0xfdff8000-0xfdffbfff irq 16 at device 0.0 on pci4
re0: Using 1 MSI
Hello!
Please check this report
http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/141050
I use quota on the root partitions and without this patch we (my
hosting company) can't use quota on /
Thank you in advance for your time, if this PR is not your area,
please forward my message to commiters
Hello!
Please check this report
http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/141050
I use quota on the root partitions and without this patch we (my
hosting company) can't use quota on /
Thank you in advance for your time, if this PR is not your area,
please forward my message to commiters
49 matches
Mail list logo
