If one tries to write a datagram to a bpf device, and the datagram is
longer than the MTU on the physical interface, the write fails as it
should, but an mbuf is allocated and thrown away. Proposed solution:
--- bpf.c.orig Mon Dec 27 10:43:06 2004
+++ bpf.c Mon Dec 27 10:44:16 2004
@@
You appear to be running out of kernel memory. Since you're
capturing the output of vmstat -m, you should check that for any
bins that are growing at a high rate of speed.
Seems possible that its in pf :)
I've checked the numbers from just before the freeze (it's
within 15
PLEASE REPLY TO [EMAIL PROTECTED]
upgraded from 4.6 = 4.10 rel
network programs are craching the new system: netstat, ping, the qmail tcp
server all of them...
sshd is running but when accessing from outside it panics too... what is it?
can i turn something off in the kernel?!
--
PLEASE REPLY TO [EMAIL PROTECTED]
upgraded from 4.6 = 4.10 rel
network programs are craching the new system: netstat, ping, the qmail tcp
server all of them...
sshd is running but when accessing from outside it panics too... what is
it?
can i turn something off in the kernel?!
kalin mintchev [EMAIL PROTECTED] wrote:
PLEASE REPLY TO [EMAIL PROTECTED]
upgraded from 4.6 = 4.10 rel
network programs are craching the new system: netstat, ping, the qmail tcp
server all of them...
sshd is running but when accessing from outside it panics too... what is it?
can
PLEASE REPLY TO [EMAIL PROTECTED]
thank you Bill for rplying...
well i did it a few times with the same success. it's not the first time
i'm doing it. it's the first time with the 4.x..
i followed the handbook step by step - rebuild devs too.. and then
cleaned up obj.. to make it all again -
PLEASE REPLY TO [EMAIL PROTECTED]
On Mon, Dec 27, 2004 at 02:40:34PM +0100, Andreas Wider?e Andersen
typed:
At 09:35 27.12.2004, you wrote:
PLEASE REPLY TO [EMAIL PROTECTED]
upgraded from 4.6 = 4.10 rel
network programs are craching the new system: netstat, ping, the
qmail
tcp
On Wed, Nov 24, 2004 at 09:25:28PM -0600, Vulpes Velox wrote:
+ Just hit a odd problem... here is what I am doing... I have a dvd+rw
+ drive that I am trying to export using ggated... of which some thing
+ is going wrong... any one have any idea what is happening?
+
+ I think I provided all the
On Mon, Dec 13, 2004 at 08:20:30PM +0100, Samuel Tardieu wrote:
+ Hi.
+
+ I just added two disks (ad4 ad6, SATA 160Go) to my FreeBSD box. I want to
+ use them in the following configuration:
+
+ - ad4s1 ad6s1: geom mirror of 80Go containing all my precious data (/,
+ /usr, /var, /home)
+
On Mon, Dec 27, 2004 at 12:24:49PM +, Johnny Eriksson wrote:
+ If one tries to write a datagram to a bpf device, and the datagram is
+ longer than the MTU on the physical interface, the write fails as it
+ should, but an mbuf is allocated and thrown away. Proposed solution:
Committed to
Sorry, I was out for Xmas. Longer dmesg here:
http://www.del.ufrj.br/~fico/FreeBSD/debug/dmesg03
Apparently, my Notebook works well (acpi doesn't).
I did not have these error messages before
last big acpi update.
Before that update dmesg pointed out acpi was doing something
(I was debugging USB,
I'm getting a few errors since I used tried to upgrade gtk2 and librsvg,
namely:
Fatal error 'Spinlock called when not threaded.' at line 83 in file
/usr/src/lib/libpthread/thread/thr_spinlock.c (errno = 0)
gmake[3]: *** [install-data-hook] Error 134
gmake[3]: Leaving directory
On Mon, Dec 27, 2004 at 06:48:36PM +, Yann Golanski wrote:
I'm getting a few errors since I used tried to upgrade gtk2 and librsvg,
namely:
Fatal error 'Spinlock called when not threaded.' at line 83 in file
/usr/src/lib/libpthread/thread/thr_spinlock.c (errno = 0)
gmake[3]: ***
And it doesn't dump its core to its dump swap space, too, so I can't run
savecore after reboot to get debugging info. I have the swap space in
fstab commented out so it won't come up at boot to be able to manually
harvest the core, as it gives savecore: no dumps found. (it doesn't
happen
On Mon, Dec 27, 2004 at 02:52:45PM -0700, Troy Bowman wrote:
And it doesn't dump its core to its dump swap space, too, so I can't run
savecore after reboot to get debugging info. I have the swap space in
fstab commented out so it won't come up at boot to be able to manually
harvest the core,
On Sun, 2004-Dec-26 08:14:49 +0100, Benjamin Lutz wrote:
The freeze just happened again. I managed to get into the debugger and get
some info.
The info you dumped shows that there's a filesystem deadlock on
ad4s1f. This is consistent with the behaviour you reported - the
system is running
Hello Peter,
The info you dumped shows that there's a filesystem deadlock on
ad4s1f.
In case you haven't guessed, that'd be my /usr.
Unfortunately, it's not clear (to me) where to go next. Printing the
locked vnodes might help but that's not easy to do without gdb.
You mean that's the
Zsolt Kúti wrote:
My system produces these messages that I already know well from this
list (as well ;):
ad4: TIMEOUT - WRITE_DMA retrying (2 retries left) LBA=213249674
Like many people I was confronted with TIMEOUT - READ_DMA
and TIMEOUT - WRITE_DMA errors on my drives. I was frustrated.
But I
On Tue, Dec 28, 2004 at 12:38:44PM +1100, Peter Jeremy wrote:
On Sun, 2004-Dec-26 08:14:49 +0100, Benjamin Lutz wrote:
The freeze just happened again. I managed to get into the debugger and get
some info.
The info you dumped shows that there's a filesystem deadlock on
ad4s1f. This is
- Original Message -
From: Joe Koberg [EMAIL PROTECTED]
To: Zsolt Kúti [EMAIL PROTECTED]
Cc: freebsd-current@freebsd.org; freebsd-stable@freebsd.org
Sent: Monday, December 27, 2004 6:29 PM
Subject: Re: TIMEOUT - WRITE_DMA - A possible FIX! turn off ACPI
Zsolt Kúti wrote:
My system
Does xmms try to run with rtprio or idprio? Those are still broken,
and can lead to deadlocks, afaik.
No, none all PIDs are listed as normal by idprio and rtprio, except the
[pagezero] process, which is listed as idle priority 31 by both
programs, and I suppose that's intentional.
Greetings
On Tue, Dec 28, 2004 at 03:52:50AM +0100, Benjamin Lutz wrote:
Does xmms try to run with rtprio or idprio? Those are still broken,
and can lead to deadlocks, afaik.
No, none all PIDs are listed as normal by idprio and rtprio, except the
[pagezero] process, which is listed as idle
22 matches
Mail list logo