-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/27/12 10:53, Łukasz Wąsikowski wrote:
> W dniu 2012-02-22 23:31, Bjoern A. Zeeb pisze:
>
>> You cannot ship that on by default for non-tecnical reasons in a
>> kernel. Please do not commit a kernel config that can be booted
>> (no LINT cannot b
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/29/12 13:17, K. Macy wrote:
> .
>>
>> I tried it, on both FreeBSD routers, web systems, and database
>> servers; all on 8.2+. It still causes massive instability.
>> Disabling the sysctl, and/or removing it from the kernel solved
>> the problem
On 03/10/12 08:56, Adam Strohl wrote:
> On 3/10/2012 17:10, Bjoern A. Zeeb wrote:
>> On 10. Mar 2012, at 08:07 , Adam Strohl wrote:
>>
>>> I've now seen this on two different VMs on two different ESXi servers
>>> (Xeon based hosts but different hardware otherwise and at different
>>> facilities):
>
Hi,
I've found an reproducable panic in unionfs on 7.1-R.
/usr/src/sys/fs/unionfs/union_subr.c is:
$FreeBSD: src/sys/fs/unionfs/union_subr.c,v 1.92.2.7.2.2
2008/12/15 03:58:55 daichi Exp $
kgdb output is below.
kgdb /boot/kernel/kernel.symbols /var/crash/vmcore.0
GNU gdb 6.1.1 [FreeBSD
Hi,
I upgraded my 7.1-RELEASE system to RELENG_7 yesterday and after
booting, re0 works for only a short time, then gives "re0: PHY read
failed" over and over. Does anyone have a suggestion on how to debug?
Thanks,
Steve
___
freebsd-stable@freebsd
Hi,
I just moved my cfservd (a part of sysutils/cfengine) from a 6.2
server to a 7.0 server. Ever since, cfservd crashes regularly. The
backtrace is below, although obviously it is missing a lot. If anyone
has clues or suggestions, I'd really appreciate it.
# gdb /usr/local/sbin/cfservd c
I have a box running 9.0-RELEASE where I'm seeing a panic happen every
5-7 days. For the record, it's moving about 80-100 mbit/s of network
traffic and has several gre tunnels setup. The box has panic'd many
times, but due to unrelated (serial port) issues, I've only been able to
get a complete pan
On Feb 25, 2009, at 7:38 PM, Pyun YongHyeon wrote:
I need more information for your hardware revision.
Would you show me dmesg output and revision number of if_re.c?
I assume you only need the re0 related output. If you need the full
dmesg, let me know.
re0: Gigabit Ethernet> port 0x7e00-0x
On Feb 25, 2009, at 11:10 PM, Pyun YongHyeon wrote:
I get 3 link state DOWN/UP notices when DHCP client starts. It works
That's normal(Technically this is not correct behavior but it's the
way how it was implemented in driver).
Ok. Not a huge deal, but would be nice to fix, of course.
for e
On Feb 25, 2009, at 11:27 PM, Pyun YongHyeon wrote:
On Wed, Feb 25, 2009 at 11:15:38PM -0500, Steve Wills wrote:
[...]
I guess re(4) thinks it lost established link. How about unplug and
then replug UTP cable? Would you show me "devinfo -rv | grep phy"?
rgephy0 pnpinfo oui=0x732
Hi,
Sorry for the late reply.
On Mar 3, 2009, at 7:07 AM, Pyun YongHyeon wrote:
Ok, when you plug UTP cable can you see "re0: link state changed to
UP" in dmesg output? Or if you unplug the cable, you should see
"re0: link state changed to DOWN"(With "tail -f /var/log/message",
you can easily c
Hi,
On Feb 25, 2009, at 7:38 PM, Pyun YongHyeon wrote:
On Tue, Feb 24, 2009 at 08:12:18PM -0500, Steve Wills wrote:
Hi,
I upgraded my 7.1-RELEASE system to RELENG_7 yesterday and after
booting, re0 works for only a short time, then gives "re0: PHY read
failed" over and over. Does a
I thought I'd try out the new audit support in 6.2-PRE and discovered
that having quota enabled causes:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x0
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc0695278
stack pointe
On Nov 14, 2006, at 4:31 AM, Robert Watson wrote:
A backtrace would be helpful.
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x0
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc06a1728
stack pointer = 0x28:0x
On Nov 14, 2006, at 12:41 PM, Kostik Belousov wrote:
I'm wondering how many people are tripped over this feature of
vn_open.
Please, try the patch:
That fixes it, thanks.
Steve
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.o
Testing out 5.4 BETA1 tonight, I encountered a hang with ACPI enabled
and a fatal trap 9 with it disabled. The hang was after detecting ACPI.
I've tried changing settings in the BIOS, but without success. Any
suggestions would be welcome. I can gather debugging info if desired.
Please reply in
Following up to myself for the archives, this problem was solved with a
BIOS upgrade. This is on an Asus P4P800-E Deluxe (865PE). Old BIOS rev
was 1002, new is 1004.
Sorry for the noise.
Steve
___
freebsd-stable@freebsd.org mailing list
http://lists.fr
17 matches
Mail list logo