Pyun YongHyeon pisze:
On Wed, Jan 14, 2009 at 03:18:16PM +0100, Bartosz Stec wrote:
Walter Venable pisze:
FreeBSD 7.1 upgrade broke my network access, machine is totally
offline (powered-on and I can play inside it at the terminal, but
absolutely 0 network access):
This happened AFTER
On Mon, Jan 19, 2009 at 09:31:36AM +0100, Bartosz Stec wrote:
Pyun YongHyeon pisze:
On Wed, Jan 14, 2009 at 03:18:16PM +0100, Bartosz Stec wrote:
Walter Venable pisze:
FreeBSD 7.1 upgrade broke my network access, machine is totally
offline (powered-on and I can play inside it at
On Wed, Jan 14, 2009 at 10:57:46PM -0500, Dan Langille wrote:
Marat N.Afanasyev wrote:
Dan Langille wrote:
Hi,
I'm getting this:
kernel: interrupt storm detected on irq22:; throttling interrupt
source
what is your motherboard brand? I have the same issue with interrupt
storms, as
2009/1/18 Brandon Gooch jamesbrandongo...@gmail.com
I have a working driver for the Intel 4965, aka iwn(4), loaded on my
Lenovo X300 running FreeBSD 7.1-RELEASE (amd64).
Wonderfull to say the least !
Seeing that you run successfully 7.1 on a X300 is excellent ! Did you manage
to get
yes, do ps - threads in state L or LL and RUN are especially interesting,
trace of pids 28, 27, and threads wich L on locked chan.
heres the output of alllocks,
http://toybox.twisted.org.uk/~pete/71_show_alllocks.png
here are the pages of PS:
On Mon, Jan 19, 2009 at 11:39:08AM +, Pete French wrote:
yes, do ps - threads in state L or LL and RUN are especially interesting,
trace of pids 28, 27, and threads wich L on locked chan.
heres the output of alllocks,
http://toybox.twisted.org.uk/~pete/71_show_alllocks.png
Probably it is your case, try please.
http://www.freebsd.org/cgi/query-pr.cgi?pr=130652cat=
OK, will give this a try, unless anyone else wants any traces from
this locked machine ? Is there a known way to tickle this bug
when I've rebooted, to make sure it's fixed ?
thanks,
-pete.
Kris writes:
You and anyone else seeing performance problems should try to work
through the advice given here:
[1]http://people.freebsd.org/~kris/scaling/Help_my_system_is_slow.pdf
Well, all the people in this thread have noticed that WITH NO CONFIG CHANGES f
rom configs
that worked
Probably it is your case, try please.
http://www.freebsd.org/cgi/query-pr.cgi?pr=130652cat=
Well, I have been running this for a while now. I still get this:
http://toybox.twisted.org.uk/~pete/71_lor3.png
On the console, but so far the machine has not crashed. Obviously it's
only been
http://www.freebsd.org/cgi/query-pr.cgi?pr=130652cat=
Looks like I spoke too soon - It just locked up again I am afraid.
Sitting there now at the debug prompt. It does, however, look very
different this time: For example here is 'show alllocks':
There are significant changes in UDP locking between 7.0 and 7.1, so it could
be that we're looking at a regression there. If you're able to reproduce this
reliably, it might well be worth doing a little search-and-replace in
udp_usrreq.c along the following lines:
INP_RLOCK_ASSERT -
Pyun YongHyeon wrote:
On Tue, Jan 13, 2009 at 03:53:59PM +0100, Sascha Holzleiter wrote:
Jung-uk Kim wrote:
On Monday 12 January 2009 12:21 pm, Sascha Holzleiter wrote:
Hi,
i see similar problems with a re card:
r...@pci0:4:7:0: class=0x02 card=0x816710ec chip=0x816710ec
Jan Henrik Sylvester wrote:
Torfinn Ingolfsen wrote:
On Sun, 18 Jan 2009 14:17:39 -0600
Brandon Gooch jamesbrandongooch at gmail.com wrote:
I have a working driver for the Intel 4965, aka iwn(4), loaded on my
Lenovo X300 running FreeBSD 7.1-RELEASE (amd64).
FWIW, I am using the latest
Hiho! :-)
Occasionally, especially when uploading a large number of files, the
(brand-new, tested) sata disks in my fileserver spit out some of these
errors:
---
Jan 19 19:51:14 hamstor kernel: ad10: WARNING - WRITE_DMA48 UDMA ICRC
error (retrying request) LBA=882778752
Hiho! :-)
Occasionally, especially when uploading a large number of files, the
(brand-new, tested) sata disks in my fileserver spit out some of these
errors:
---
Jan 19 19:51:14 hamstor kernel: ad10: WARNING - WRITE_DMA48 UDMA ICRC
error (retrying request) LBA=882778752
I upgraded my early-2008 Mac Pro to 7.1-STABLE and Gnome 2.24.3 over
the weekend, it had been tracking -STABLE.
I'd imported the snd_hda driver and had it running with a few tweaks,
which I needed to adjust to get it running under this version of the
driver.
I'm only able to get the rear
On Sun, Jan 18, 2009 at 09:30:05PM -0500, Pete Carah wrote:
I've had some mysterious hangs which I notice that several others have too.
Two of the machines in question are Soekris 4801's running as routers; this
is hard to handle ddb with (though possible for one of them...) I started
Pete Carah wrote:
Kris writes:
You and anyone else seeing performance problems should try to work
through the advice given here:
http://people.freebsd.org/~kris/scaling/Help_my_system_is_slow.pdf
http://people.freebsd.org/%7Ekris/scaling/Help_my_system_is_slow.pdf
Well, all the people
On Sun, Jan 18, 2009 at 2:15 AM, Matthias Schuendehuette m...@snafu.de wrote:
Hello,
I operate two FreeBSD-Servers in a Windows- and HP-UX Environment. One is a
SAMBA-Server as a gateway between the Windows and the Unix world, the other
is NFS-Server for the HP-UX 11i v1 Workstations. Both
On Friday 16 January 2009 11:47 pm, Pyun YongHyeon wrote:
On Tue, Jan 13, 2009 at 03:53:59PM +0100, Sascha Holzleiter wrote:
Jung-uk Kim wrote:
On Monday 12 January 2009 12:21 pm, Sascha Holzleiter wrote:
Hi,
i see similar problems with a re card:
r...@pci0:4:7:0:
Hi Garret,
Am 19.01.2009 um 22:29 schrieb Garrett Cooper:
What OS and what NFS version are the HP-UX servers running?
The OS is HP-UX 11.11 a.k.a HP-UX 11iv1.
NFS-Version is NFSV3 (of course ;-) via TCP
Have
you checked /var/log/messages on the clients and on the server for
helpful
I have done some (lots of) kernel debugging in the past. I have several
points:
1. I shouldn't *have* to kernel debug for a normal usage of an
official release.
2. One of the soekris boxes is 2800 MILES away, in a remote location,
with noone present that is a skilled (or, indeed, any kind of)
I think that if you use eSATA you probably need dedicated eSATA
controller ports. eSATA standard specifies a higher voltage for the
longer cable distances.
Judging from the sporadic problem reports, Promise TX4 is probably not
the best at signal purity to begin with so using it for eSATA
I must have missed the HEADS-UP or something but it seems that the SYSV IPC
options are now mandatory in order to compile an amd64 kernel with
COMPAT_IA32... I get linking errors in kernel.debug because
freebsd32_syscalls.o is referencing the SYSV syscalls...
Am I alone?
--
Ollivier ROBERT -=-
On Mon, Jan 19, 2009 at 04:59:59PM -0500, Pete Carah wrote:
I shouldn't *have* to kernel debug for a normal usage of an
official release.
Agreed, but the problems that people are having do not seem to have
arisen on any of the systems that ran prelease tests for 7.1. Although
I'm sure it does
I've fiddled with the cables, which seemed to help, but I've been
unable to completely eliminate the errors. The disks are two Western
Digital MyBooks Home Edition (1 TB per disk), connected to a Promise TX
4 SATA Controller:
atap...@pci0:1:6:0: class=0x018000 card=0x3d17105a chip=0x3d17105a
On Mon, 19 Jan 2009, Marc UBM wrote:
Hiho! :-)
Occasionally, especially when uploading a large number of files, the
(brand-new, tested) sata disks in my fileserver spit out some of these
errors:
I've found that those kind of errors are very, very controller-dependent.
Case in point - a
On Monday 19 January 2009 04:33 pm, Jung-uk Kim wrote:
I found something interesting. I have another RTL8169SC that works
perfectly fine without the patch. The hardware revision is
0x1800. After reading Linux driver (drivers/net/r8169c), I
realised they use different masks for hardware
Your invitation to join our webinar:
Reducing IT Expenses with Open Source Technology
Thursday, January 22nd
No cost to attendees, but space is limited.
Sign up by visiting:
http://online.intelestream.net/em/link.php?M=425083N=206L=40F=T
Intelestream’s COO Richard Baldwin will discuss how
Sam Leffler wrote:
: OTOH iwn is now out of date and someone needs to update it. There's
: newer firmware that is supposed to fix many of the bugs I hit when I
: worked on the driver (and Intel refused to acknowledge) and obsd has
: added support for newer parts that people want. It'd be
On Mon, Jan 19, 2009 at 06:33:46PM -0500, Jung-uk Kim wrote:
On Monday 19 January 2009 04:33 pm, Jung-uk Kim wrote:
I found something interesting. I have another RTL8169SC that works
perfectly fine without the patch. The hardware revision is
0x1800. After reading Linux driver
On Mon, Jan 19, 2009 at 7:38 PM, Damian Gerow dge...@afflictions.org wrote:
Sam Leffler wrote:
: OTOH iwn is now out of date and someone needs to update it. There's
: newer firmware that is supposed to fix many of the bugs I hit when I
: worked on the driver (and Intel refused to acknowledge)
On Mon, 2009-01-19 at 20:38 -0500, Damian Gerow wrote:
Sam Leffler wrote:
: OTOH iwn is now out of date and someone needs to update it. There's
: newer firmware that is supposed to fix many of the bugs I hit when I
: worked on the driver (and Intel refused to acknowledge) and obsd has
:
On Mon, Jan 19, 2009 at 8:48 PM, Da Rock rock_on_the_...@comcen.com.au wrote:
On Mon, 2009-01-19 at 20:38 -0500, Damian Gerow wrote:
Sam Leffler wrote:
: OTOH iwn is now out of date and someone needs to update it. There's
: newer firmware that is supposed to fix many of the bugs I hit when I
On Mon, 2009-01-19 at 21:24 -0600, Brandon Gooch wrote:
On Mon, Jan 19, 2009 at 8:48 PM, Da Rock rock_on_the_...@comcen.com.au
wrote:
On Mon, 2009-01-19 at 20:38 -0500, Damian Gerow wrote:
Sam Leffler wrote:
: OTOH iwn is now out of date and someone needs to update it. There's
: newer
Well, following up on my own reply earlier, I csup'd releng_7 with a
date of last dec 1; the result works fine
in the laptop. I'll reload the eastern soekris tonight and see how it
does. If the soekris is fine also then this gives a data point for
whenever the bad commit(s) happened.
I had
Marat N.Afanasyev wrote:
Dan Langille wrote:
Marat N.Afanasyev wrote:
Dan Langille wrote:
Dan Langille wrote:
Hi,
I'm getting this:
kernel: interrupt storm detected on irq22:; throttling interrupt
source
what is your motherboard brand? I have the same issue with interrupt
storms, as
On Tue, 20 Jan 2009 09:39:51 +1100
Andrew Snow and...@modulus.org wrote:
I think that if you use eSATA you probably need dedicated eSATA
controller ports. eSATA standard specifies a higher voltage for the
longer cable distances.
Judging from the sporadic problem reports, Promise TX4 is
38 matches
Mail list logo
