Re: Panic with chromium and 8.1-STABLE (Thu Sep 16 09:52:17 BRT 2010)
Quoting Kostik Belousov : 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 : > 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 Kim
To: freebsd-stable@FreeBSD.org
Cc: d...@delphij.net, Mario Sergio Fujikawa Ferreira
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_cast(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 c
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
> To: freebsd-stable@FreeBSD.org
> Cc: d...@delphij.net, Mario Sergio Fujikawa Ferreira
> 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]"
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]"
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: mldonkey kqueue patch (replace select/poll)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, My previous email did not have enough information. MLDonkey is a OCAML/GTK client for a number of peer-to-peer networks including edonkey, overnet and kademlia. It can be found on the FreeBSD ports tree under both net/mldonkey and net/mldonkey-devel. I just wrote a patch against ports/net/mldonkey-devel version 2.6.1 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 daemon loads and I am able to connect to the daemon through both the web interface and kmldonkey. However, it seems unable to connect to eDonkey servers. Are there any takers to help me on this one? It should really improve performance under FreeBSD and possibly other *BSD platforms. A sample port with the current patch included can be found at http://people.FreeBSD.org/~lioux/mldonkey-kqueue.tgz It is not meant for general use since MLDonkey will not connect to any servers but it is good enough for someone to have an idea of what I want to do. If you only want the patch, it can be found at http://people.FreeBSD.org/~lioux/mldonkey-kqueue-patch.zip My current hypotheses are: 1) The MLDonkey C stubs used to interface the kqueue code with the ocaml code are not behaving as expected; i.e., MLDonkey is not calling the stubs C at each and every needed place (at every addition, removal and updating of file descriptors which will, in turn, result in similar changes to the kqueue filters). 2) The kqueue code is not correctly written. I think that most people can help with option (2). :) All and any help is appreciated. This discussion can be followed at MLDonkey's patch manager at: http://savannah.nongnu.org/patch/index.php?func=detailitem&item_id=4293 Regards, MSFF ps: Please, include me on CC: replies since I am no longer subscribed to this mailing list. keywords: select, poll, kqueue, kevent, FreeBSD, NetBSD, OpenBSD, epoll -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFC+XMDrxEiaFLzGQwRAqLOAJ91g28fIz95wpmPnd2xp/VcEBlC2ACaArlN f1kspvvVMum/7zYRoNrkIlI= =6BDw -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]"
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
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]"
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
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=19843 mtu 1500 options=4b inet 10.1.1.2 netmask 0xff80 broadcast 10.0.0.127 ether 00:00:00:00:00:00 media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 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=0x383fbff AMD Features=0xc040 real memory = 2146697216 (2047 MB) avail memory = 2095230976 (1998 MB) ACPI APIC Table: MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-23 on motherboard npx0: on motherboard npx0: INT 16 interface acpi0: 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: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xe000-0xefff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 drm0: 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: mem 0xfd9fe000-0xfd9fefff irq 19 at device 7.0 on pci0 smbus0: on bktr0 iicbb0: on bktr0 iicbus0: on iicbb0 master-only iicsmb0: on iicbus0 smbus1: on iicsmb0 bktr0: Hauppauge Model 44001 C110 bktr0: Hauppauge WinCast/TV. pci0: at device 7.1 (no driver attached) fxp0: port 0xb800-0xb83f mem 0xfebc-0xfebd,0xfebfe000-0xfebfefff irq 18 at device 8.0 on pci0 miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:02:b3:2d:b2:de pci0: at device 10.0 (no driver attached) pci0: at device 10.1 (no driver attached) pci0: at device 10.2 (no driver attached) atapci0: 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: 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: port 0xdc00-0xdc1f irq 21 at device 16.0 on pci0 usb0: 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: port 0xe000-0xe01f irq 21 at device 16.1 on pci0 usb1: 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: port 0xe400-0xe41f irq 21 at device 16.2 on pci0 usb2: 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: port 0xe800-0xe81f irq 21 at device 16.3 on pci0 usb3: 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: at device 16.4 (no driver attached) isab0: at device 17.0 on pci0 isa0: on isab0 acpi_button0: on acpi0 acpi_button1: on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model MouseMan+, device ID 0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A fdc0: port 0
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 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=19843 mtu 1500 options=4b 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 ) status: active lo0: flags=8049 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]"
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]"
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: 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=0x383fbff AMD Features=0xc040 real memory = 1072955392 (1023 MB) avail memory = 1040420864 (992 MB) MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-23 on motherboard npx0: on motherboard npx0: INT 16 interface acpi0: 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: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xe000-0xefff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 drm0: 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: at device 7.0 (no driver attached) pci0: at device 7.1 (no driver attached) fxp0: port 0xb800-0xb83f mem 0xfebc-0xfebd,0xfebfe000-0xfebfefff irq 18 at device 8.0 on pci0 miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:02:b3:2d:b2:de pci0: at device 10.0 (no driver attached) pci0: at device 10.1 (no driver attached) pci0: at device 10.2 (no driver attached) atapci0: 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: 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: port 0xdc00-0xdc1f irq 21 at device 16.0 on pci0 usb0: 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: port 0xe000-0xe01f irq 21 at device 16.1 on pci0 usb1: 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: port 0xe400-0xe41f irq 21 at device 16.2 on pci0 usb2: 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: port 0xe800-0xe81f irq 21 at device 16.3 on pci0 usb3: 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: at device 16.4 (no driver attached) isab0: at device 17.0 on pci0 isa0: on isab0 acpi_button0: on acpi0 acpi_button1: on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model MouseMan+, device ID 0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fd0: <1440-KB 3.5" drive> on fdc0 drive 0 orm0: at iomem 0xc8800-0xc9fff,0xc-0xc87ff on isa0 pmtimer0 on isa0 vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 fb0 at vga0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled Timecounter "TSC" frequency 1917807181 Hz quality 800 Timecounters tick every 0.868 msec IP Filter: v3.4.35 initialized. Default = pass all, Logging = disabled ipfw2 initialized, divert disabled, rule-based forwarding disabled, default to accept, logging di
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
mouse problems with XFree86-4 (4.0.1)?
I just updated my XFree from 4.0 to 4.0.1 in order to check PR ports/20360 concerning rxvt and I noticed a strange behavior. If I change to a text console (alt-f[1-9]) while using X; when I do get back, the mouse is unavailable though I can use it in my text ttyv[0-7]. I have to shutdown the X session and restart it to get the mouse back. Everything was fine till I "updated" my X from 4.0 to 4.0.1. That is the only change, last nights for that matter. I am running a 4.1 STABLE as of 01/08/2000 (last tuesday) with X 4.0.1, KDE 1.1.2 and moused with no mouse flags. My "mouse" is a Logitech TrackMan Marble FX. Anyone has seen this too? Regards, Mario Ferreira To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
