Re: Panic with chromium and 8.1-STABLE (Thu Sep 16 09:52:17 BRT 2010)
Quoting Kostik Belousov kostik...@gmail.com: On Sun, Sep 19, 2010 at 07:28:13PM -0300, Mario Sergio Fujikawa Ferreira wrote: Hi, I've just began trying chrome web browser from http://chromium.hybridsource.org/ but it triggered 2 panics on my 8.1-STABLE system. $ uname -a FreeBSD exxodus.fedaykin.here 8.1-STABLE FreeBSD 8.1-STABLE #26: Thu Sep 16 09:52:17 BRT 2010 li...@exxodus:/usr/obj/usr/src/sys/LIOUX amd64 The panic information is: panic: vm_page_unwire: invalid wire count: 0 cpuid = 0 KDB: enter: panic 0xff006ecce000: tag ufs, type VREG usecount 1, writecount 1, refcount 4 mountedhere 0 flags () v_object 0xff0151489870 ref 0 pages 8 lock type ufs: EXCL by thread 0xff00200947c0 (pid 25025) ino 119526591, on dev ufs/fsusr 0xff011107f938: tag ufs, type VREG usecount 0, writecount 0, refcount 4 mountedhere 0 flags (VV_NOSYNC|VI_DOINGINACT) v_object 0xff0151f7f870 ref 0 pages 1284 lock type ufs: EXCL by thread 0xff01882cc7c0 (pid 26689) ino 263, on dev md0 I've made available 2 ddb textdumps at: http://people.freebsd.org/~lioux/panic/2010091900/textdump.tar.0 http://people.freebsd.org/~lioux/panic/2010091900/textdump.tar.1 I was able to use chrome prior to this latest kernel update. Now, I can reproduce a kernel panic even browsing www.google.com Please, let me know if I can provide any further information. Does it panic if you remove ZERO_COPY_SOCKETS option from the kernel config ? Right on the spot. Removing ZERO_COPY_SOCKETS stopped the panics. The panics restart if I add them again. Regards, -- Mario S F Ferreira - DF - Brazil - I guess this is a signature. feature, n: a documented bug | bug, n: an undocumented feature ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Panic with chromium and 8.1-STABLE (Thu Sep 16 09:52:17 BRT 2010)
Hi, I've just began trying chrome web browser from http://chromium.hybridsource.org/ but it triggered 2 panics on my 8.1-STABLE system. $ uname -a FreeBSD exxodus.fedaykin.here 8.1-STABLE FreeBSD 8.1-STABLE #26: Thu Sep 16 09:52:17 BRT 2010 li...@exxodus:/usr/obj/usr/src/sys/LIOUX amd64 The panic information is: panic: vm_page_unwire: invalid wire count: 0 cpuid = 0 KDB: enter: panic 0xff006ecce000: tag ufs, type VREG usecount 1, writecount 1, refcount 4 mountedhere 0 flags () v_object 0xff0151489870 ref 0 pages 8 lock type ufs: EXCL by thread 0xff00200947c0 (pid 25025) ino 119526591, on dev ufs/fsusr 0xff011107f938: tag ufs, type VREG usecount 0, writecount 0, refcount 4 mountedhere 0 flags (VV_NOSYNC|VI_DOINGINACT) v_object 0xff0151f7f870 ref 0 pages 1284 lock type ufs: EXCL by thread 0xff01882cc7c0 (pid 26689) ino 263, on dev md0 I've made available 2 ddb textdumps at: http://people.freebsd.org/~lioux/panic/2010091900/textdump.tar.0 http://people.freebsd.org/~lioux/panic/2010091900/textdump.tar.1 I was able to use chrome prior to this latest kernel update. Now, I can reproduce a kernel panic even browsing www.google.com Please, let me know if I can provide any further information. Regards, -- Mario S F Ferreira - DF - Brazil - I guess this is a signature. feature, n: a documented bug | bug, n: an undocumented feature ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e
Quoting Jung-uk Kim j...@freebsd.org: On Monday 28 June 2010 02:01 pm, Jung-uk Kim wrote: Please drop the attached patch in ports/devel/boost-libs/files, rebuild all dependencies, and try your deluge ports again[1]. Please ignore the previous patch and try this one. Sorry, there was a typo. :-( I updated boost-libs with your patch which fixed the issue. I no longer have the ioctl warning. :) 1) I rebuilt the libtorrent-rasterbar-14 then libtorrent-rasterbar-14-python. 2) Tried deluge, there were warnings still. 3) Then, rebuilt deluge. 4) Tried deluge, warnings were gone. I still have the lang/python26 patches you sent earlier. So I have both the python and boost-libs patches on my system. Do you want to me to do any further testing? Regards, -- Mario S F Ferreira - DF - Brazil - I guess this is a signature. feature, n: a documented bug | bug, n: an undocumented feature ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e
On 25/06/2010 18:58, Jung-uk Kim wrote:
On Friday 25 June 2010 04:54 am, Mario Sergio Fujikawa Ferreira wrote:
On Wed, Jun 23, 2010 at 05:08:38PM -0400, Jung-uk Kim wrote:
Date: Wed, 23 Jun 2010 17:08:38 -0400
From: Jung-uk Kimj...@freebsd.org
To: freebsd-stable@FreeBSD.org
Cc: d...@delphij.net, Mario Sergio Fujikawa Ferreira
li...@freebsd.org Subject: Re: FreeBSD 8.1-PRERELEASE: WARNING
ioctl sign-extension ioctl 8004667e
User-Agent: KMail/1.6.2
On Wednesday 23 June 2010 03:38 pm, Jung-uk Kim wrote:
On Wednesday 23 June 2010 03:10 pm, Jung-uk Kim wrote:
On Wednesday 23 June 2010 03:01 pm, Jung-uk Kim wrote:
On Wednesday 23 June 2010 02:41 pm, Xin LI wrote:
On 2010/06/23 11:37, Jung-uk Kim wrote:
On Wednesday 23 June 2010 02:12 pm, Xin LI wrote:
Hi,
On 2010/06/22 19:58, Mario Sergio Fujikawa Ferreira
wrote:
Hi,
I am getting more than 4 thousand of the following
messages a day:
WARNING pid 24509 (python2.6): ioctl sign-extension
ioctl 8004667e
[...]
I think we may need to check the code and patch it.
Basically this means that python (or some .so modules)
passed an int or unsigned int as parameter 'cmd', we
need to change it to unsigned long.
The warning itself should be harmless to my best of
knowledge, one can probably remove the printf in
kernel source code as a workaround.
By the way it seems to be a POSIX violation and we
didn't seem to really use so wide cmd, but I have not
yet verified everything myself.
Long time ago, I had a similar problem with termios
TIOCGWINSZ and we patched the port like this:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/python
/fil es /A tt
ic/patch-Modules%3A%3Afcntlmodule.c?rev=1.1;content-typ
e=te xt %2 Fpl ain
I believe it was upstream patched at the time but I
won't be surprised if something similar was
reintroduced. It happens when a Python internal
integer type is converted to a native unsigned long.
Well, only *BSD have cmd a long value so it's likely that
it would be reintroduced.
Yes, that's what I mean.
I have checked the 4.4BSD archive and understood that our
ioctl's cmd parameter was made long around 1991 or 1992s
but didn't see what it actually buy us...
Like it or not, it is too late to revert. :-(
From Python 2.6.5:
static PyObject *
fcntl_ioctl(PyObject *self, PyObject *args)
{
#define IOCTL_BUFSZ 1024
int fd;
/* In PyArg_ParseTuple below, we use the unsigned
non-checked 'I' format for the 'code' parameter because
Python turns 0x800 into either a large positive number
(PyLong or PyInt on 64-bit platforms) or a negative number on
others (32-bit PyInt) whereas the system expects it to be a
32bit bit field value regardless of it being passed as an int
or unsigned long on various platforms. See the
termios.TIOCSWINSZ constant across platforms for an example
of thise.
If any of the 64bit platforms ever decide to use more
than 32bits in their unsigned long ioctl codes this will
break and need special casing based on the platform being
built on. */
unsigned int code;
...
It is still a kludge and it won't be fixed. :-(
Please drop the attached patch in ports/lang/python26/files and
test. Note I am not a Python guy, so please don't shoot me. ;-)
I found that Python guys added 'k' format since 2.3, which
converts a Python integer to unsigned long. Please ignore the
previous patch and try the attached patch instead.
Unfortunately it didn't work.
1) Added patch to lang/python26
2) Recompiled lang/python26
3) cd /var/db/ports portupgrade -f python* py26* deluge*
Restarted deluge afterwards. The message is still there:
Jun 25 05:49:38 exxodus kernel: WARNING pid 38635 (python2.6):
ioctl sign-extension ioctl 8004667e
It may be a deeper problen, then. :-(
First of all, I cannot reproduce the problem because deluged dumps
core on my box and I gave it up. Just staring at the code, it seems
they rely on a bundled libtorrent for Python binding and the
libtorrent relies on Boost, in turn. Then, the actual non-blocking
socket implementation is done with Boost ASIO[1]. It is possible
that there are more complicated problems between these and the Python
binding. In fact, I can see a lot of these:
int name() const
{
return FIONBIO;
}
...
if (!ec command.name() == static_castint(FIONBIO))
...
socket_ops::ioctl(impl.socket_, command.name(), ...)
...
They are just assuming it is an int type, I guess.
Sigh, what a mess...
Given that your python patch is a step on the right direction, I would
propose that it be further tested and then committed if possible.
[1] Boost and its Python binding from ports seems to be a newer ASIO
version than the bundled ASIO headers. Probably it is a reason for
the crash but I didn't bother too much.
If you have the time, everything you need to run the latest deluge
1.3.0 RC1 can be found at
http://www.freebsd.org/cgi/query-pr.cgi?pr=144337
Check
Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e
On Wed, Jun 23, 2010 at 05:08:38PM -0400, Jung-uk Kim wrote:
Date: Wed, 23 Jun 2010 17:08:38 -0400
From: Jung-uk Kim j...@freebsd.org
To: freebsd-stable@FreeBSD.org
Cc: d...@delphij.net, Mario Sergio Fujikawa Ferreira li...@freebsd.org
Subject: Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl
8004667e
User-Agent: KMail/1.6.2
On Wednesday 23 June 2010 03:38 pm, Jung-uk Kim wrote:
On Wednesday 23 June 2010 03:10 pm, Jung-uk Kim wrote:
On Wednesday 23 June 2010 03:01 pm, Jung-uk Kim wrote:
On Wednesday 23 June 2010 02:41 pm, Xin LI wrote:
On 2010/06/23 11:37, Jung-uk Kim wrote:
On Wednesday 23 June 2010 02:12 pm, Xin LI wrote:
Hi,
On 2010/06/22 19:58, Mario Sergio Fujikawa Ferreira wrote:
Hi,
I am getting more than 4 thousand of the following
messages a day:
WARNING pid 24509 (python2.6): ioctl sign-extension ioctl
8004667e
[...]
I think we may need to check the code and patch it.
Basically this means that python (or some .so modules)
passed an int or unsigned int as parameter 'cmd', we need
to change it to unsigned long.
The warning itself should be harmless to my best of
knowledge, one can probably remove the printf in kernel
source code as a workaround.
By the way it seems to be a POSIX violation and we didn't
seem to really use so wide cmd, but I have not yet
verified everything myself.
Long time ago, I had a similar problem with termios
TIOCGWINSZ and we patched the port like this:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/python/fil
es /A tt
ic/patch-Modules%3A%3Afcntlmodule.c?rev=1.1;content-type=te
xt %2 Fpl ain
I believe it was upstream patched at the time but I won't
be surprised if something similar was reintroduced. It
happens when a Python internal integer type is converted to
a native unsigned long.
Well, only *BSD have cmd a long value so it's likely that it
would be reintroduced.
Yes, that's what I mean.
I have checked the 4.4BSD archive and understood that our
ioctl's cmd parameter was made long around 1991 or 1992s but
didn't see what it actually buy us...
Like it or not, it is too late to revert. :-(
From Python 2.6.5:
static PyObject *
fcntl_ioctl(PyObject *self, PyObject *args)
{
#define IOCTL_BUFSZ 1024
int fd;
/* In PyArg_ParseTuple below, we use the unsigned non-checked
'I' format for the 'code' parameter because Python turns
0x800 into either a large positive number (PyLong or PyInt on
64-bit platforms) or a negative number on others (32-bit PyInt)
whereas the system expects it to be a 32bit bit field value
regardless of it being passed as an int or unsigned long on
various platforms. See the termios.TIOCSWINSZ constant across
platforms for an example of thise.
If any of the 64bit platforms ever decide to use more than
32bits in their unsigned long ioctl codes this will break and
need special casing based on the platform being built on.
*/
unsigned int code;
...
It is still a kludge and it won't be fixed. :-(
Please drop the attached patch in ports/lang/python26/files and
test. Note I am not a Python guy, so please don't shoot me. ;-)
I found that Python guys added 'k' format since 2.3, which converts a
Python integer to unsigned long. Please ignore the previous patch
and try the attached patch instead.
Unfortunately it didn't work.
1) Added patch to lang/python26
2) Recompiled lang/python26
3) cd /var/db/ports portupgrade -f python* py26* deluge*
Restarted deluge afterwards. The message is still there:
Jun 25 05:49:38 exxodus kernel: WARNING pid 38635 (python2.6): ioctl
sign-extension ioctl 8004667e
Regards,
--
Mario S F Ferreira - DF - Brazil - I guess this is a signature.
feature, n: a documented bug | bug, n: an undocumented feature
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e
Hi, I am getting more than 4 thousand of the following messages a day: WARNING pid 24509 (python2.6): ioctl sign-extension ioctl 8004667e I've already recompiled all my python ports and dependencies. I am running up to date ports (today). $ uname -a FreeBSD exxodus.fedaykin.here 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE #10: Thu Jun 17 12:28:13 BRT 2010 li...@exxodus:/usr/obj/usr/src/sys/LIOUX amd64 These messages began this past week but I am not sure what might be to blame: latest ports or latest -STABLE. The specific python port is deluge 1.3 RC1. It was running fine before this past week of changes. Does anyone have an idea what might be causing this? Do I have to be alarmed by this? The system is reliable despite these messages. Regards, -- Mario S F Ferreira - DF - Brazil - I guess this is a signature. feature, n: a documented bug | bug, n: an undocumented feature ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Possible UDP deadlock/panic fix
Hi, That seems to be working. I've been up and running for 7 hours now with your patch. The machine is a bit slow but I have both WITNESS and INVARIANTS enabled so as to make sure everything is fine. Rergads, Mario Robert Watson wrote: Attached is an MFC candidate for a patch I just merged to 8.x, which corrects the UDP lock recursion issue both of you were running into. If it settles well for a couple of days in HEAD then I'll go ahead and request an MFC from re@, but your confirmation as to whether or not this corrects the specific symptoms you are seeing would be very helpful. I was able to confirm that it eliminated what appeared to be the same problem here when I attempted to reproduce it based on the information you provided, so I'm hopeful.\ Thanks, Robert N M Watson Computer Laboratory University of Cambridge Property changes on: . ___ Modified: svn:mergeinfo Merged /head/sys:r183265 Index: netinet6/udp6_usrreq.c === --- netinet6/udp6_usrreq.c(revision 183265) +++ netinet6/udp6_usrreq.c(working copy) @@ -975,13 +975,23 @@ error = EINVAL; goto out; } + +/* + * XXXRW: We release UDP-layer locks before calling + * udp_send() in order to avoid recursion. However, + * this does mean there is a short window where inp's + * fields are unstable. Could this lead to a + * potential race in which the factors causing us to + * select the UDPv4 output routine are invalidated? + */ +INP_WUNLOCK(inp); +INP_INFO_WUNLOCK(udbinfo); if (sin6) in6_sin6_2_sin_in_sock(addr); pru = inetsw[ip_protox[IPPROTO_UDP]].pr_usrreqs; -error = ((*pru-pru_send)(so, flags, m, addr, control, +/* addr will just be freed in sendit(). */ +return ((*pru-pru_send)(so, flags, m, addr, control, td)); -/* addr will just be freed in sendit(). */ -goto out; } } #endif ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.1-PRERELEASE panic rw_rlock (udpinp)
Hi, That seems to be working. I've been up and running for 2 hours now with your patch. The machine is a bit slow but I have both WITNESS and INVARIANTS enabled to make sure everything is fine. Rergads, Mario Robert Watson wrote: On Sun, 21 Sep 2008, Mario Sergio Fujikawa Ferreira wrote: I've been running FreeBSD 7.0-STABLE from August 1 without problems. I tried updating to the latest -STABLE but I got a system panic. Hi Mario-- This is a known problem, and will hopefully be resolved shortly. In essence, the v4 compatibility path for v6 socket is invoking the v4 code with locks held that upset the v4 code. Robert N M Watson Computer Laboratory University of Cambridge panic: _rw_rlock (udpinp): wlock already held @ /usr/src/sys/netinet/udp_usrreq.c FreeBSD 7.1-PRERELEASE #18: Sat Sep 20 23:38:22 BRT 2008 Regards, Mario Ferreira - Kernel configuration http://people.freebsd.org/~lioux/panic/2008092100/KERNCONF - syslog output http://people.freebsd.org/~lioux/panic/2008092100/all.log http://people.freebsd.org/~lioux/panic/2008092100/messages - dmesg.boot http://people.freebsd.org/~lioux/panic/2008092100/dmesg.boot - kldstat http://people.freebsd.org/~lioux/panic/2008092100/kldstat.txt - /boot/loader.conf http://people.freebsd.org/~lioux/panic/2008092100/loader.conf - 'pciconf -lv' http://people.freebsd.org/~lioux/panic/2008092100/pciconf.txt - 'sysctl -a' http://people.freebsd.org/~lioux/panic/2008092100/sysctl.txt - /etc/sysctl.conf http://people.freebsd.org/~lioux/panic/2008092100/sysctl.conf -- Mario S F Ferreira - DF - Brazil - I guess this is a signature. feature, n: a documented bug | bug, n: an undocumented feature ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD 7.1-PRERELEASE panic rw_rlock (udpinp)
Hi, I've been running FreeBSD 7.0-STABLE from August 1 without problems. I tried updating to the latest -STABLE but I got a system panic. panic: _rw_rlock (udpinp): wlock already held @ /usr/src/sys/netinet/udp_usrreq.c FreeBSD 7.1-PRERELEASE #18: Sat Sep 20 23:38:22 BRT 2008 Regards, Mario Ferreira - Kernel configuration http://people.freebsd.org/~lioux/panic/2008092100/KERNCONF - syslog output http://people.freebsd.org/~lioux/panic/2008092100/all.log http://people.freebsd.org/~lioux/panic/2008092100/messages - dmesg.boot http://people.freebsd.org/~lioux/panic/2008092100/dmesg.boot - kldstat http://people.freebsd.org/~lioux/panic/2008092100/kldstat.txt - /boot/loader.conf http://people.freebsd.org/~lioux/panic/2008092100/loader.conf - 'pciconf -lv' http://people.freebsd.org/~lioux/panic/2008092100/pciconf.txt - 'sysctl -a' http://people.freebsd.org/~lioux/panic/2008092100/sysctl.txt - /etc/sysctl.conf http://people.freebsd.org/~lioux/panic/2008092100/sysctl.conf -- Mario S F Ferreira - DF - Brazil - I guess this is a signature. feature, n: a documented bug | bug, n: an undocumented feature ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.1-PRERELEASE panic rw_rlock (udpinp)
On Sun, Sep 21, 2008 at 11:48:19AM +0100, Kris Kennaway wrote: Mario Sergio Fujikawa Ferreira wrote: Hi, I've been running FreeBSD 7.0-STABLE from August 1 without problems. I tried updating to the latest -STABLE but I got a system panic. panic: _rw_rlock (udpinp): wlock already held @ /usr/src/sys/netinet/udp_usrreq.c FreeBSD 7.1-PRERELEASE #18: Sat Sep 20 23:38:22 BRT 2008 Regards, Mario Ferreira - Kernel configuration http://people.freebsd.org/~lioux/panic/2008092100/KERNCONF - syslog output http://people.freebsd.org/~lioux/panic/2008092100/all.log http://people.freebsd.org/~lioux/panic/2008092100/messages - dmesg.boot http://people.freebsd.org/~lioux/panic/2008092100/dmesg.boot - kldstat http://people.freebsd.org/~lioux/panic/2008092100/kldstat.txt - /boot/loader.conf http://people.freebsd.org/~lioux/panic/2008092100/loader.conf - 'pciconf -lv' http://people.freebsd.org/~lioux/panic/2008092100/pciconf.txt - 'sysctl -a' http://people.freebsd.org/~lioux/panic/2008092100/sysctl.txt - /etc/sysctl.conf http://people.freebsd.org/~lioux/panic/2008092100/sysctl.conf - gdb backtrace? I had a hard lock there. I got the system panic but it locked instead of dumping core. I had to remove the power cord to reboot it. I do not have much experience with kernel traces. How do I force a backtrace? Any unattended ddb scripts? Regards, Mario Ferreira -- Mario S F Ferreira - DF - Brazil - I guess this is a signature. feature, n: a documented bug | bug, n: an undocumented feature ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
mldonkey kqueue patch (replace select/poll)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, mldonkey is a OCAML/GTK client for a number of peer-to-peer networks including edonkey, overnet and kademlia. I just wrote a patch against ports/net/mldonkey-devel version 2.6.0 to support kqueue(2) FreeBSD kernel event notification mechanism. It is meant to replace select/poll inside mldonkey. kqueue scales better than select/poll not to mention that it should be faster. I am having a little bit of trouble with this patch. mldonkey loads and I am able to connect to the daemon through both the web interface and kmldonkey. However, I am unable to connect to servers. I am pretty sure I am assuming something wrong about the interaction of the ml_fd_* C functions and mldonkey ocaml code. Are there any takers to help me on this one? It should really improve performance under FreeBSD and possibly other *BSD platforms. Regards, MSFF ps: Please, include on CC: replies since I am no longer subscribed to this mailing list. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC+CU8rxEiaFLzGQwRAluiAJ90Ncly7vZSeL3sopjpDuZeC0YuBQCeLisH VWwvMSk0pD8ZwZKbTHUD9WA= =8XLv -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Can objcopy(1) handle coff? (was update math/mprime)
Hi, I am having trouble updating the port math/mprime. I need to convert from .obj coff to .o elf32. However, I get a complain Invalid bfd target I have the sample port at http://people.FreeBSD.org/~lioux/mprime.tgz I believe that the problem is related to the fact that we are unable to handle coff files. Am I doing something wrong? Just try building it to see the problem. FreeBSD exxodus.fedaykin.here 5.4-STABLE FreeBSD 5.4-STABLE #3: Sun May 8 10:28:48 BRT 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LIOUX i386 Script started on Mon May 23 22:37:29 2005 === Extracting for mprime-0.0.23.5 = Checksum OK for mprime/source23.zip. = Checksum OK for mprime/prime95-text-2004022600-23.5.tar.bz2. === mprime-0.0.23.5 depends on executable: unzip - found /bin/cp /usr/home/lioux/src/myports/ports/math/mprime/files/makebsd /usr/home/lioux/src/myports/ports/math/mprime/work/linux === Patching for mprime-0.0.23.5 === mprime-0.0.23.5 depends on executable: gmake - found === Configuring for mprime-0.0.23.5 === Building for mprime-0.0.23.5 rm -f mprime sprime prime.o menu.o mult.o mult1.o mult2.o mult2a.o mult3.o mult3a.o mult4.o mult4a.o mult4b.o mult1p.o mult2p.o mult2ap.o mult3p.o mult3ap.o mult3q.o mult3aq.o mult4p.o mult4ap.o mult4bp.o mult4q.o mult4aq.o mult4bq.o mult1aux.o mult2aux.o mult3aux.o mult3auq.o mult4aux.o mult4auq.o xmult1.o xmult1ax.o xmult2.o xmult2a.o xmult2ax.o xmult3.o xmult3a.o xmult3ax.o ecmhelp.o cpuid.o dummy4.o dummy8.o dummy12.o dummy16.o dummy20.o dummy24.o dummy28.o dummyt4.o dummyt8.o dummyt12.o dummyt16.o dummyt20.o dummyt24.o dummyt28.o [ ! -e ../security.h ] touch ../security.h || true [ ! -e ../security.c ] touch ../security.c || true /usr/local/libexec/ccache/cc -O -pipe -pipe -funit-at-a-time -m3dnow -msse -mfpmath=sse,387 -falign-functions -fforce-addr -fforce-mem -foptimize-register-move -foptimize-sibling-calls -fpeel-loops -fprefetch-loop-arrays -freorder-blocks -march=athlon-xp -I.. -malign-double -c prime.c /usr/local/libexec/ccache/cc -O -pipe -pipe -funit-at-a-time -m3dnow -msse -mfpmath=sse,387 -falign-functions -fforce-addr -fforce-mem -foptimize-register-move -foptimize-sibling-calls -fpeel-loops -fprefetch-loop-arrays -freorder-blocks -march=athlon-xp -I.. -malign-double -c menu.c menu.c: In function `options_preferences': menu.c:698: warning: the address of `PRIMENET', will always evaluate as `true' menu.c:700: warning: the address of `PRIMENET', will always evaluate as `true' menu.c:702: warning: the address of `PRIMENET', will always evaluate as `true' objcopy -v --input-target=coff-i386 --output-target=elf32-i386-freebsd ../prime95/mult.obj mult.o objcopy: ../prime95/mult.obj: Invalid bfd target gmake: *** [mult.o] Error 1 *** Error code 2 Stop in /usr/home/lioux/src/myports/ports/math/mprime. Script done on Mon May 23 22:37:32 2005 ps: Please, CC: me because I do not subscribe to this mailing list. -- Mario S F Ferreira - DF - Brazil - I guess this is a signature. feature, n: a documented bug | bug, n: an undocumented feature pgp5K8Pe0QCEm.pgp Description: PGP signature
make buildkernel subdirs do not respect COPTFLAGS
Hi,
I was doing my often world build when something came up.
$ make buildworld
just fine
$ make buildkernel
not so good
$ make buildkernel -V CFLAGS
-Os -pipe -march=athlon-xp -falign-functions -falign-jumps -fno-strict-aliasing
-fomit-frame-pointer -fpeel-loops -freorder-blocks -funit-at-a-time
-funswitch-loops -mfpmath=387 -march=athlon-xp
$ make buildkernel -V COPTFLAGS
-Os -pipe -march=athlon-xp -falign-functions -falign-jumps -fno-strict-aliasing
-fomit-frame-pointer -fpeel-loops -freorder-blocks -funit-at-a-time
-funswitch-loops -mfpmath=387
$ make buildkernel -V LDFLAGS
Those are the compile options I have. As you can see, both
COPTFLAGS and CFLAGS contents are the same whereas LDFLAGS is empty.
I did a CVSup then a buildworld, then proceeded to a buildkernel.
Here is what I've got:
cd /usr/src/sys/modules; MAKEOBJDIRPREFIX=/usr/obj/usr/src/sys/LIOUX/modules
KMODDIR=/boot/kernel MACHINE=i386 KERNBUILDDIR=/usr/obj/usr/src/sys/LIOUX
make all
=== 3dfx
=== aac
=== aac/aac_linux
=== accf_data
=== accf_http
=== acpi
=== acpi/acpi
/usr/local/libexec/ccache/cc -O -pipe -pipe -msse -mfpmath=sse,387
-funit-at-a-time -falign-functions -fforce-addr -fforce-mem
-foptimize-register-move -foptimize-sibling-calls -fpeel-loops
-fprefetch-loop-arrays -freorder-blocks -march=athlon-xp
-I/usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica -D_KERNEL
-DKLD_MODULE -nostdinc -I-
-I/usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica -include
/usr/obj/usr/src/sys/LIOUX/opt_global.h -I. -I@ -I@/contrib/altq -I@/../include
-finline-limit=8000 -fno-common -I/usr/obj/usr/src/sys/LIOUX
-mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow
-mno-sse -mno-sse2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual
-fformat-extensions -std=c99 -Wsystem-headers -Werror -Wall -Wno-format-y2k
-Wno-uninitialized -c
/usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica/dsfield.c
/usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica/dsfield.c:1:
warning: SSE instruction set disabled, using 387 arithmetics
*** Error code 1
As you can see the FLAGS options being used to build the
kernel DO NOT match either CFLAGS or COPTFLAGS for buildkernel. I
can reproduce this just fine. Let me know if you need a full log
'make buildworld buildkernel'
As you can see below my standard CFLAGS is not the same as
of the one for buildkernel.
$ make -V CFLAGS
-O -pipe -pipe -msse -mfpmath=sse,387 -funit-at-a-time -falign-functions
-fforce-addr -fforce-mem -foptimize-register-move -foptimize-sibling-calls
-fpeel-loops -fprefetch-loop-arrays -freorder-blocks -march=athlon-xp
I trick the system to use different build make options
depending on the given situation.
My /etc/make.conf contains the following
COPTFLAGS=-Os -pipe
COPTFLAGS+=-march=athlon-xp
COPTFLAGS+=-falign-functions
COPTFLAGS+=-falign-jumps
COPTFLAGS+=-fno-strict-aliasing
COPTFLAGS+=-fomit-frame-pointer
COPTFLAGS+=-fpeel-loops
COPTFLAGS+=-freorder-blocks
COPTFLAGS+=-funit-at-a-time
COPTFLAGS+=-funswitch-loops
.if make(buildworld) || make(buildkernel)
LDFLAGS_LD_INSTEAD_OF_CC=yes
NO_CFLAGS=yes
CFLAGS=${COPTFLAGS}
.if make(buildworld)
COPTFLAGS+=-msse
COPTFLAGS+=-mfpmath=sse,387
.elif make(buildkernel) # ! make(buildworld)
COPTFLAGS+=-mfpmath=387
.endif # make(buildkernel)
.endif # make(buildworld) || make(buildkernel)
The botton line is, the following line
cd /usr/src/sys/modules; MAKEOBJDIRPREFIX=/usr/obj/usr/src/sys/LIOUX/modules
KMODDIR=/boot/kernel MACHINE=i386 KERNBUILDDIR=/u
sr/obj/usr/src/sys/LIOUX make all
has no idea that it is part of a buildkernel statement. We can fix
that by setting a ENVIRONMENT variable when the kernel is being
built and check that within /usr/src/sys/modules in order to respect
COPTFLAGS over CFLAGS.
What do you guys think? I hope my make.conf code tricks are
useful to some folks out there.
Regards,
ps: Plz, CC: me in your responses since I am no longer subscribed
to this mailing list
--
Mario S F Ferreira - DF - Brazil - I guess this is a signature.
feature, n: a documented bug | bug, n: an undocumented feature
pgpBjh0bEwRjh.pgp
Description: PGP signature
Re: make buildkernel subdirs do not respect COPTFLAGS
Hi, Just a followup, the modules are also not respecting the command line defines. This is what I've got which is totally wrong since -Wl statements are meant for gcc not ld. ld -Wl,-z,combreloc -Wl,--sort-common -Wl,--enable-new-dtags -d -warn-common -r -d -o acpi.kld dsfield.o dsinit.o dsmethod.o dsmthdat.o dsobject.o dsopcode.o dsutils.o dswexec.o dswload.o dswscope.o dswstate.o evevent.o evgpe.o evgpeblk.o evmisc.o evregion.o evrgnini.o evsci.o evxface.o evxfevnt.o evxfregn.o exconfig.o exconvrt.o excreate.o exdump.o exfield.o exfldio.o exmisc.o exmutex.o exnames.o exoparg1.o exoparg2.o exoparg3.o exoparg6.o exprep.o exregion.o exresnte.o exresolv.o exresop.o exstore.o exstoren.o exstorob.o exsystem.o exutils.o hwacpi.o hwgpe.o hwregs.o hwsleep.o hwtimer.o nsaccess.o nsalloc.o nsdump.o nseval.o nsinit.o nsload.o nsnames.o nsobject.o nsparse.o nssearch.o nsutils.o nswalk.o nsxfeval.o nsxfname.o nsxfobj.o psargs.o psopcode.o psparse.o psscope.o pstree.o psutils.o pswalk.o psxface.o rsaddr.o rscalc.o rscreate.o rsdump.o rsio.o rsirq.o rslist.o rsmemory.o rsmisc.o rsutils.o rsxface.o tbconvrt.o tbget.o tbgetall.o tbinstal.o tbrsdt.o tbutils.o tbxface.o tbxfroot.o utalloc.o utclib.o utcopy.o utdebug.o utdelete.o uteval.o utglobal.o utinit.o utmath.o utmisc.o utobject.o utxface.o acpi.o acpi_button.o acpi_isab.o acpi_package.o acpi_pci.o acpi_pcib.o acpi_pcib_acpi.o acpi_pcib_pci.o acpi_powerres.o acpi_quirk.o acpi_resource.o acpi_timer.o acpi_pci_link.o acpi_thermal.o acpi_acad.o acpi_battery.o acpi_cmbat.o acpi_cpu.o acpi_ec.o acpi_lid.o acpi_throttle.o OsdDebug.o OsdHardware.o OsdInterrupt.o OsdMemory.o OsdSchedule.o OsdStream.o OsdSynch.o OsdTable.o OsdEnvironment.o acpi_machdep.o acpi_wakeup.o madt.o I use a protection define LDFLAGS_LD_INSTEAD_OF_CC=yes that TAKES care of that. It is set in the buildkernel statement. That line should have read ld -z combreloc --sort-common --enable-new-dtags -d -warn-common -r -d -o acpi.kld dsfield.o dsinit.o dsmethod.o dsmthdat.o dsobject.o dsopcode.o dsutils.o dswexec.o dswload.o dswscope.o dswstate.o evevent.o evgpe.o evgpeblk.o evmisc.o evregion.o evrgnini.o evsci.o evxface.o evxfevnt.o evxfregn.o exconfig.o exconvrt.o excreate.o exdump.o exfield.o exfldio.o exmisc.o exmutex.o exnames.o exoparg1.o exoparg2.o exoparg3.o exoparg6.o exprep.o exregion.o exresnte.o exresolv.o exresop.o exstore.o exstoren.o exstorob.o exsystem.o exutils.o hwacpi.o hwgpe.o hwregs.o hwsleep.o hwtimer.o nsaccess.o nsalloc.o nsdump.o nseval.o nsinit.o nsload.o nsnames.o nsobject.o nsparse.o nssearch.o nsutils.o nswalk.o nsxfeval.o nsxfname.o nsxfobj.o psargs.o psopcode.o psparse.o psscope.o pstree.o psutils.o pswalk.o psxface.o rsaddr.o rscalc.o rscreate.o rsdump.o rsio.o rsirq.o rslist.o rsmemory.o rsmisc.o rsutils.o rsxface.o tbconvrt.o tbget.o tbgetall.o tbinstal.o tbrsdt.o tbutils.o tbxface.o tbxfroot.o utalloc.o utclib.o utcopy.o utdebug.o utdelete.o uteval.o utglobal.o utinit.o utmath.o utmisc.o utobject.o utxface.o acpi.o acpi_button.o acpi_isab.o acpi_package.o acpi_pci.o acpi_pcib.o acpi_pcib_acpi.o acpi_pcib_pci.o acpi_powerres.o acpi_quirk.o acpi_resource.o acpi_timer.o acpi_pci_link.o acpi_thermal.o acpi_acad.o acpi_battery.o acpi_cmbat.o acpi_cpu.o acpi_ec.o acpi_lid.o acpi_throttle.o OsdDebug.o OsdHardware.o OsdInterrupt.o OsdMemory.o OsdSchedule.o OsdStream.o OsdSynch.o OsdTable.o OsdEnvironment.o acpi_machdep.o acpi_wakeup.o madt.o So, this is yet another thing to consider. ps: Plz, CC: me in your responses since I am no longer subscribed to this mailing list -- Mario S F Ferreira - DF - Brazil - I guess this is a signature. feature, n: a documented bug | bug, n: an undocumented feature ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ping: sendto: No buffer space available
Hi, I have been experiencing this $ ping 10.1.1.1 PING 10.1.1.1 (10.1.1.1): 56 data bytes ping: sendto: No buffer space available ping: sendto: No buffer space available Does anyone have any ideas? Doing # ifconfig fxp0 down # ifconfig fxp0 up fixes it but it won't recover otherwise. I am running a matched world-kernel. $ uname -a FreeBSD exxodus.fedaykin.here 5.4-PRERELEASE FreeBSD 5.4-PRERELEASE #0: Fri Mar 4 01:52:24 BRT 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LIOUX i386 Please let me if more information is required. $ ifconfig -a fxp0: flags=19843UP,BROADCAST,RUNNING,SIMPLEX,LINK0,MULTICAST,POLLING mtu 1500 options=4bRXCSUM,TXCSUM,VLAN_MTU,POLLING inet 10.1.1.2 netmask 0xff80 broadcast 10.0.0.127 ether 00:00:00:00:00:00 media: Ethernet autoselect (100baseTX full-duplex) status: active lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384 inet 127.0.0.1 netmask 0xff00 $ netstat -m 1347 mbufs in use 835/25600 mbuf clusters in use (current/max) 0/38/6656 sfbufs in use (current/peak/max) 2006 KBytes allocated to network 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 2732 calls to protocol drain routines $ cat /var/run/dmesg.boot Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...9 9 9 8 8 2 2 1 1 1 0 0 0 0 done No buffers busy after final sync Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.4-PRERELEASE #0: Fri Mar 4 01:52:24 BRT 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LIOUX Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) XP 2600+ (1917.81-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x6a0 Stepping = 0 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc040AMIE,DSP,3DNow! real memory = 2146697216 (2047 MB) avail memory = 2095230976 (1998 MB) ACPI APIC Table: A M I OEMAPIC MADT: Forcing active-low polarity and level trigger for SCI ioapic0 Version 0.3 irqs 0-23 on motherboard npx0: math processor on motherboard npx0: INT 16 interface acpi0: A M I OEMRSDT on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 cpu0: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: VIA KT880 host to PCI bridge mem 0xe000-0xefff at device 0.0 on pci0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 drm0: Matrox G400/G450 (AGP) mem 0xfe00-0xfe7f,0xfeafc000-0xfeaf,0xfa00-0xfbff irq 16 at device 0.0 on pci1 info: [drm] AGP at 0xe000 256MB info: [drm] Initialized mga 3.1.0 20021029 on minor 0 bktr0: BrookTree 878 mem 0xfd9fe000-0xfd9fefff irq 19 at device 7.0 on pci0 smbus0: System Management Bus on bktr0 iicbb0: I2C bit-banging driver on bktr0 iicbus0: Philips I2C bus on iicbb0 master-only iicsmb0: SMBus over I2C bridge on iicbus0 smbus1: System Management Bus on iicsmb0 bktr0: Hauppauge Model 44001 C110 bktr0: Hauppauge WinCast/TV. pci0: multimedia at device 7.1 (no driver attached) fxp0: Intel 82550 Pro/100 Ethernet port 0xb800-0xb83f mem 0xfebc-0xfebd,0xfebfe000-0xfebfefff irq 18 at device 8.0 on pci0 miibus0: MII bus on fxp0 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:02:b3:2d:b2:de pci0: multimedia, audio at device 10.0 (no driver attached) pci0: input device at device 10.1 (no driver attached) pci0: serial bus, FireWire at device 10.2 (no driver attached) atapci0: VIA 6420 SATA150 controller port 0xc800-0xc80f,0xcc00-0xcc03,0xd000-0xd007,0xd400-0xd403,0xd800-0xd807 irq 20 at device 15.0 on pci0 ata2: channel #0 on atapci0 ata3: channel #1 on atapci0 atapci1: VIA 8237 UDMA133 controller port 0xfc00-0xfc0f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 15.1 on pci0 ata0: channel #0 on atapci1 ata1: channel #1 on atapci1 uhci0: VIA 83C572 USB controller port 0xdc00-0xdc1f irq 21 at device 16.0 on pci0 usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: VIA 83C572 USB controller port 0xe000-0xe01f irq 21 at device 16.1 on pci0 usb1: VIA 83C572 USB controller on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: VIA 83C572 USB controller port 0xe400-0xe41f irq 21 at device 16.2 on pci0 usb2: VIA
FreeBSD 5-STABLE, APIC and SCB timeouts (was Re: FreeBSD 5-STABLE, MSI KT880 , fxp and SCB timeouts)
On Thu, Feb 24, 2005 at 09:52:52AM -0600, Jon Noack wrote: Mario Sergio Fujikawa Ferreira wrote: On Wed, Feb 23, 2005 at 09:33:41PM -0600, Jon Noack wrote: On 02/23/05 21:30, Dan Nelson wrote: In the last episode (Feb 23), Jon Noack said: On 02/23/05 20:06, Mario Sergio Fujikawa Ferreira wrote: My last motherboard burned down to ashes so I got myself a brand (after 2 weeks) new MSI KT880. I am getting some weird results. 1) fxp intel etherxpress 10/100 network cards report SCB timeout as well as achieving ridiculously low transfer rates of 600 Bytes/second. Well, I got 10 KBytes/sec once but that does not count since a side box gets more than 50KB/s ;-) on the same hub. Oh, I've already switched hub ports, rj45 cables and fxp cards. After some research, it seems John Baldwin has found the reason for the SCB timeouts. It is related to APIC being enabled on the motherboard. It is optional for single processor systems but required for multiprocessor systems. The message regarding the patch is contained in the following URL http://lists.freebsd.org/pipermail/freebsd-smp/2005-January/000751.html I have been using the aforementioned patch for the past 24 hours. It is not perfect but I am getting some real speed (over 10KB/s though I should be getting close to 50KB/s). However, I am losing lots of packets when performing ping tests. Does anyone know anything further about it? I am willing to test trial patches as long as I do not lose my HDD data ;-D Regards, -- Mario S F Ferreira - DF - Brazil - I guess this is a signature. feature, n: a documented bug | bug, n: an undocumented feature ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5-STABLE, MSI KT880 , fxp and SCB timeouts
On Wed, Feb 23, 2005 at 09:33:41PM -0600, Jon Noack wrote: On 02/23/05 21:30, Dan Nelson wrote: In the last episode (Feb 23), Jon Noack said: On 02/23/05 20:06, Mario Sergio Fujikawa Ferreira wrote: My last motherboard burned down to ashes so I got myself a brand (after 2 weeks) new MSI KT880. I am getting some weird results. 1) fxp intel etherxpress 10/100 network cards report SCB timeout as well as achieving ridiculously low transfer rates of 600 Bytes/second. Well, I got 10 KBytes/sec once but that does not count since a side box gets more than 50KB/s ;-) on the same hub. Oh, I've already switched hub ports, rj45 cables and fxp cards. Duplex mismatch? You say hub and not switch, so you might need to force the card to half-duplex. Oddly enough, the fxp(4) man page doesn't include half-duplex as a media option. Surely it supports it... Actually, it is a 5 port switch (10/100 TX). Any thoughts? I can provide as much information as necessary. By the way, another computer using exactly a fxp connected to the same switch works nicely. Regards, -- Mario S F Ferreira - DF - Brazil - I guess this is a signature. feature, n: a documented bug | bug, n: an undocumented feature ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5-STABLE, MSI KT880 , fxp and SCB timeouts
On Thu, Feb 24, 2005 at 09:52:52AM -0600, Jon Noack wrote: Mario Sergio Fujikawa Ferreira wrote: On Wed, Feb 23, 2005 at 09:33:41PM -0600, Jon Noack wrote: On 02/23/05 21:30, Dan Nelson wrote: In the last episode (Feb 23), Jon Noack said: On 02/23/05 20:06, Mario Sergio Fujikawa Ferreira wrote: My last motherboard burned down to ashes so I got myself a brand (after 2 weeks) new MSI KT880. I am getting some weird results. 1) fxp intel etherxpress 10/100 network cards report SCB timeout as well as achieving ridiculously low transfer rates of 600 Bytes/second. Well, I got 10 KBytes/sec once but that does not count since a side box gets more than 50KB/s ;-) on the same hub. Oh, I've already switched hub ports, rj45 cables and fxp cards. Duplex mismatch? You say hub and not switch, so you might need to force the card to half-duplex. Oddly enough, the fxp(4) man page doesn't include half-duplex as a media option. Surely it supports it... Actually, it is a 5 port switch (10/100 TX). Any thoughts? I can provide as much information as necessary. By the way, another computer using exactly a fxp connected to the same switch works nicely. Try forcing full-duplex? The output of ifconfig would also be helpful (you can sanitize IP and MAC addresses)? IP/MAC addresses and netmasks sanitized fxp0: flags=19843UP,BROADCAST,RUNNING,SIMPLEX,LINK0,MULTICAST,POLLING mtu 1500 options=4bRXCSUM,TXCSUM,VLAN_MTU,POLLING inet 10.0.0.2 netmask 0xff80 broadcast 10.0.0.127 inet 10.0.0.3 netmask 0x broadcast 10.0.0.3 ether 00:ff:00:ff:00:ff media: Ethernet autoselect (100baseTX full-duplex) status: active lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384 inet 127.0.0.1 netmask 0xff00 -- Mario S F Ferreira - DF - Brazil - I guess this is a signature. feature, n: a documented bug | bug, n: an undocumented feature ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD 5-STABLE, MSI KT880 , fxp and SCB timeouts
Hi, My last motherboard burned down to ashes so I got myself a brand (after 2 weeks) new MSI KT880. I am getting some weird results. 1) fxp intel etherxpress 10/100 network cards report SCB timeout as well as achieving ridiculously low transfer rates of 600 Bytes/second. Well, I got 10 KBytes/sec once but that does not count since a side box gets more than 50KB/s ;-) on the same hub. Oh, I've already switched hub ports, rj45 cables and fxp cards. I have the following PCI devices: - Matrox G450 Dual Head video card - Intel etherxpress 10/100 network card - Soundblaster audigy 2 soundboard - Highpoint ATA 100 raid controller - Brooktree 878 video capture Any ideas on how to fix this? Here is my system information ps: Please include me on CC: when replying because I am not subscribed to this list mailing list $ uname -a FreeBSD exxodus.here.here 5.3-STABLE FreeBSD 5.3-STABLE #0: Wed Feb 23 01:47:05 BRT 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LIOUX i386 $ cat /var/run/dmesg.boot Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.3-STABLE #0: Wed Feb 23 01:47:05 BRT 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LIOUX ACPI APIC Table: A M I OEMAPIC Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) XP 2600+ (1917.81-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x6a0 Stepping = 0 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc040AMIE,DSP,3DNow! real memory = 1072955392 (1023 MB) avail memory = 1040420864 (992 MB) MADT: Forcing active-low polarity and level trigger for SCI ioapic0 Version 0.3 irqs 0-23 on motherboard npx0: math processor on motherboard npx0: INT 16 interface acpi0: A M I OEMRSDT on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 cpu0: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: VIA KT880 host to PCI bridge mem 0xe000-0xefff at device 0.0 on pci0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 drm0: Matrox G400/G450 (AGP) mem 0xfe00-0xfe7f,0xfeafc000-0xfeaf,0xfa00-0xfbff irq 16 at device 0.0 on pci1 info: [drm] AGP at 0xe000 256MB info: [drm] Initialized mga 3.1.0 20021029 on minor 0 pci0: multimedia, video at device 7.0 (no driver attached) pci0: multimedia at device 7.1 (no driver attached) fxp0: Intel 82550 Pro/100 Ethernet port 0xb800-0xb83f mem 0xfebc-0xfebd,0xfebfe000-0xfebfefff irq 18 at device 8.0 on pci0 miibus0: MII bus on fxp0 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:02:b3:2d:b2:de pci0: multimedia, audio at device 10.0 (no driver attached) pci0: input device at device 10.1 (no driver attached) pci0: serial bus, FireWire at device 10.2 (no driver attached) atapci0: VIA 6420 SATA150 controller port 0xc800-0xc80f,0xcc00-0xcc03,0xd000-0xd007,0xd400-0xd403,0xd800-0xd807 irq 20 at device 15.0 on pci0 ata2: channel #0 on atapci0 ata3: channel #1 on atapci0 atapci1: VIA 8237 UDMA133 controller port 0xfc00-0xfc0f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 15.1 on pci0 ata0: channel #0 on atapci1 ata1: channel #1 on atapci1 uhci0: VIA 83C572 USB controller port 0xdc00-0xdc1f irq 21 at device 16.0 on pci0 usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: VIA 83C572 USB controller port 0xe000-0xe01f irq 21 at device 16.1 on pci0 usb1: VIA 83C572 USB controller on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: VIA 83C572 USB controller port 0xe400-0xe41f irq 21 at device 16.2 on pci0 usb2: VIA 83C572 USB controller on uhci2 usb2: USB revision 1.0 uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: VIA 83C572 USB controller port 0xe800-0xe81f irq 21 at device 16.3 on pci0 usb3: VIA 83C572 USB controller on uhci3 usb3: USB revision 1.0 uhub3: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered pci0: serial bus, USB at device 16.4 (no driver attached) isab0: PCI-ISA bridge at device 17.0 on pci0 isa0: ISA bus on isab0 acpi_button0: Power Button on acpi0 acpi_button1: Sleep Button on acpi0 atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model MouseMan+, device ID 0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port
Re: newsyslog.conf error on latest stable?
On Tue, Oct 03, 2000 at 11:49:34PM -0200, Mario Sergio Fujikawa Ferreira wrote: On Wed, Oct 04, 2000 at 01:49:02AM +0100, Brian Somers wrote: This really sounds like you haven't got version 1.25.2.1 of newsyslog.c installed This was when the above format was added and was committed to -stable on May 19. [elided] /var/log/monthly.log^I^I^I640 12*$M1D0 Z$ System message: newsyslog: malformed at: /var/log/monthly.log 640 12*$M1D0 Z Well, Ricardo Bueno da Silva [EMAIL PROTECTED], a fellow brazilian with a similar problem, seems to have identified the source of it. He luckily had 2 similar instalations with just one of them functional. Therefore, doing a cross compare, he found out that the most noticeable difference was /etc/localtime. Just the broken one had undergone light savings (BRST). Unfortunaly, I can verify that, erasing /etc/localtime seems to do the trick. Our timezone is BRT and we are undergoing light savings (BRST). Perhaps, this information might prove useful. Does anyone else can verify that? I can't seem to find anything wrong with the zone files since all other binaries seems to be working. I can try a deeper look but I can't promise anything. I am not a zone expert. -- Mario S. F. Ferreira - UnB - Brazil - "I guess this is a signature." lioux at ( freebsd dot org | linf dot unb dot br ) flames to beloved [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: How to Create a FreeBSD iso image
Hi,
I saw a posting from Mr. Matsushita
regarding the snapshot ftp site on Japan.
He mentioned they have w/ and w/o packages
versions. Does anyone happen to know if they
are using scripts to build selected parts
of the ports tree?
I would be very insterested on being
able to choose some parts of the tree
and build packages to just those. If the
scripts could handle the dependencies
package building too, that would be
just perfect.
Regards,
Mario Ferreira
ps: By the way, regarding the original posting.
If you believe you know what you are doing,
and that cvsuping is not for you. You can
try this patch against /usr/src/release/Makefile
Make sure you know what you are doing.
Do not forget to both use the flag RELEASENOUPDATE=yes
and cvsup src-all, docs and ports to their
expected places previously.
--- MakefileWed Jul 26 09:20:02 2000
+++ /tmp/Makefile Sat Aug 12 15:04:36 2000
@@ -63,7 +63,7 @@
ALLLANG?= yes
DOCPORTS= textproc/docproj
# Set this to wherever the distfiles required by ${DOCPORTS} live.
-DOCDISTFILES?= ${.CURDIR}/../../ports/distfiles
+DOCDISTFILES?= ${.CURDIR}/../../ports/distfiles/
# Set this to 1 if you want -P to be used for automatic keyboard detection
# on the boot floppy. WARNING: Breaks on some Athlon (K7) motherboards.
AUTO_KEYBOARD_DETECT?= 0
@@ -209,7 +209,8 @@
cvs -R -d ${CVSROOT} co -P ${RELEASESRCMODULE}
.else
cd ${CHROOTDIR}/usr rm -rf src \
- cvs -R -d ${CVSROOT} co -P -r ${RELEASETAG} ${RELEASESRCMODULE}
+ tar -cvf - -C /usr src | tar -xvf -
+# cvs -R -d ${CVSROOT} co -P -r ${RELEASETAG} ${RELEASESRCMODULE}
.endif
.if defined(LOCAL_PATCHES) exists(${LOCAL_PATCHES})
cd ${CHROOTDIR}/usr/src patch ${PATCH_FLAGS} ${LOCAL_PATCHES}
@@ -221,14 +222,16 @@
.if defined(AUXRELEASETAG)
cd ${CHROOTDIR}/usr rm -rf ports cvs -R -d ${CVSROOT} co -P -r
${AUXRELEASETAG} ${RELEASEPORTSMODULE} cd ports ${MAKEREADMES}
.else
- cd ${CHROOTDIR}/usr rm -rf ports cvs -R -d ${CVSROOT} co -P
${RELEASEPORTSMODULE} cd ports ${MAKEREADMES}
+# cd ${CHROOTDIR}/usr rm -rf ports cvs -R -d ${CVSROOT} co -P
+${RELEASEPORTSMODULE} cd ports ${MAKEREADMES}
+ cd ${CHROOTDIR}/usr rm -rf ports tar -cvf - -C /usr --exclude distfiles
+ports | tar -xvf - cd ports ${MAKEREADMES}
.endif
.endif
.if !defined(NODOC)
.if defined(AUXRELEASETAG)
cd ${CHROOTDIR}/usr rm -rf doc cvs -R -d ${CVSROOT} co -P -r
${AUXRELEASETAG} ${RELEASEDOCMODULE}
.else
- cd ${CHROOTDIR}/usr rm -rf doc cvs -R -d ${CVSROOT} co -P
${RELEASEDOCMODULE}
+# cd ${CHROOTDIR}/usr rm -rf doc cvs -R -d ${CVSROOT} co -P
+${RELEASEDOCMODULE}
+ cd ${CHROOTDIR}/usr rm -rf doc tar -cvf - -C /usr doc | tar -xvf -
.endif
if [ -d ${DOCDISTFILES}/ ]; then \
cp -rp ${DOCDISTFILES} ${CHROOTDIR}/usr/ports/distfiles; \
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
