Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e
on 23/06/2010 05:58 Mario Sergio Fujikawa Ferreira said the following: Hi, I am getting more than 4 thousand of the following messages a day: WARNING pid 24509 (python2.6): ioctl sign-extension ioctl 8004667e This ioctl is FIONBIO. I believe that I saw another report about it on this list recently (~1 week ago). But it was for a different software. 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. I guess it would be some port. 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. This messages just warns about bad programming, but in this case the ioctl is processed correctly. -- Andriy Gapon ___ 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: network deamons starting before network!
# grep REQUIRE /etc/rc.d/ppp # REQUIRE: netif ldconfig ^ i had to add this ___ 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
Mouse appears on screen but does not move.
Hi again, I am pretty sure that Adam is right about the version mismatch. I used sysinstall to update the ports tree and had to change options from 8.0-RELEASE-p3 to 8.0-RELEASE. Cvsup deleted the ports tree. Don't know if I have to change the RELENG_8 to something else. # $FreeBSD: src/share/examples/cvsup/ports-supfile,v 1.38.10.1.2.1 2009/10/25 01:10:29 kensmith Exp $ # # This file contains all of the CVSup collections that make up the # FreeBSD-current ports collection. # # CVSup (CVS Update Protocol) allows you to download the latest CVS # tree (or any branch of development therefrom) to your system easily # and efficiently (far more so than with sup, which CVSup is aimed # at replacing). If you're running CVSup interactively, and are # currently using an X display server, you should run CVSup as follows # to keep your CVS tree up-to-date: # # cvsup ports-supfile # # If not running X, or invoking cvsup from a non-interactive script, then # run it as follows: # # cvsup -g -L 2 ports-supfile # # You may wish to change some of the settings in this file to better # suit your system: # # host=CHANGE_THIS.FreeBSD.org # This specifies the server host which will supply the # file updates. You must change it to one of the CVSup # mirror sites listed in the FreeBSD Handbook at # http://www.freebsd.org/doc/handbook/mirrors.html. # You can override this setting on the command line # with cvsup's -h host option. # # base=/var/db # This specifies the root where CVSup will store information # about the collections you have transferred to your system. # A setting of /var/db will generate this information in # /var/db/sup. You can override the base setting on the # command line with cvsup's -b base option. This directory # must exist in order to run CVSup. # # prefix=/usr # This specifies where to place the requested files. A # setting of /usr will place all of the files requested # in /usr/ports (e.g., /usr/ports/devel, /usr/ports/lang). # The prefix directory must exist in order to run CVSup. # Defaults that apply to all the collections # # IMPORTANT: Change the next line to use one of the CVSup mirror sites # listed at http://www.freebsd.org/doc/handbook/mirrors.html. *default host=cvsup5.FreeBSD.org *default base=/var/db *default prefix=/usr *default release=cvs tag=RELENG_8 *default delete use-rel-suffix # If you seem to be limited by CPU rather than network or disk bandwidth, try # commenting out the following line. (Normally, today's CPUs are fast enough # that you want to run compression.) *default compress ## Ports Collection. # # The easiest way to get the ports tree is to use the ports-all # mega-collection. It includes all of the individual ports-* # collections, #ports-all # These are the individual collections that make up ports-all. If you # use these, be sure to comment out ports-all above. # # Be sure to ALWAYS cvsup the ports-base collection if you use any of the # other individual collections below. ports-base is a mandatory collection # for the ports collection, and your ports may not build correctly if it # is not kept up to date. #ports-base #ports-accessibility #ports-arabic #ports-archivers #ports-astro #ports-audio #ports-benchmarks #ports-biology #ports-cad ##ports-chinese #ports-comms #ports-converters #ports-databases# #ports-deskutils #ports-devel #ports-dns #ports-editors #ports-emulators #ports-finance #ports-french #ports-ftp #ports-games #ports-german #ports-graphics #ports-hebrew #ports-hungarian #ports-irc #ports-japanese #ports-java #ports-korean #ports-lang #ports-mail #ports-math #ports-mbone #ports-misc #ports-multimedia #ports-net #ports-net-im #ports-net-mgmt #ports-net-p2p #ports-news #ports-palm #ports-polish #ports-ports-mgmt #ports-portuguese #ports-print #ports-russian #ports-science #ports-security #ports-shells #ports-sysutils #ports-textproc #ports-ukrainian #ports-vietnamese #ports-www ports-x11 ports-x11-clocks ports-x11-drivers ports-x11-fm ports-x11-fonts ports-x11-servers ports-x11-themes ports-x11-toolkits ports-x11-wm Will keep trying. I can't download email right now on this program, so I'm not using text from the other emails. I'll keep in mind hal and 'AEI'and 'ADD', Warren. Thanks again, -Nate ___ 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: Mouse appears on screen but does not move.
On Wed, Jun 23, 2010 at 9:46 AM, Nathan Maier maier.nat...@gmail.comwrote: Hi again, I am pretty sure that Adam is right about the version mismatch. I used sysinstall to update the ports tree and had to change options from 8.0-RELEASE-p3 to 8.0-RELEASE. Cvsup deleted the ports tree. Don't know if I have to change the RELENG_8 to something else. Yeah you would want to set *default release=cvs tag=RELENG_8_0 You may also need to set the date if you want to keep only on RELEASE. If you're trying to keep your packages from that date, probably just easier to use pkg_add -r or download directly eg ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-8.0-release/x11-drivers/ Make sure that is your correct ARCH -- Adam Vande More ___ 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
Mouse appears on screen but does not move
Okay, THe mouse is working well enough. I changed my label in ports-supfile to tag=. which I found in documentation as applicable to ports supfiles. Is this different from source supfiles where . means CURRENT release. Anyhow, after portupgrade -a, I tried xdm with 'AllowEmptyInput' 'off' and both mouse and keyboard worked. Then I changed to 'AutoAddDevices' 'off' and the mouse worked as well. 'AutoAddDevices' 'off' : (**) Mouse0: ZAxisMapping: buttons 4, 5, 6 and 7 (**) Mouse0: Buttons: 11 (**) Mouse0: Sensitivity: 1 (II) XINPUT: Adding extended input device Mouse0 (type: MOUSE) (**) Mouse0: (accel) keeping acceleration scheme 1 (**) Mouse0: (accel) acceleration profile 0 (II) Mouse0: SetupAuto: hw.iftype is 4, hw.model is 0 (II) Mouse0: SetupAuto: protocol is SysMouse (**) Option CoreKeyboard (**) Keyboard0: always reports core events (**) Option Protocol standard (**) Keyboard0: Protocol: standard (**) Option XkbRules base (**) Keyboard0: XkbRules: base (**) Option XkbModel pc105 (**) Keyboard0: XkbModel: pc105 (**) Option XkbLayout us (**) Keyboard0: XkbLayout: us (**) Option CustomKeycodes off (**) Keyboard0: CustomKeycodes disabled (II) XINPUT: Adding extended input device Keyboard0 (type: KEYBOARD) (EE) config/hal: couldn't initialise context: unknown error (null) (END) 'AllowEmptyInput' 'off': (**) Option Protocol auto (**) Mouse0: Device: /dev/sysmouse (**) Mouse0: Protocol: auto (**) Option CorePointer (**) Mouse0: always reports core events (**) Option Device /dev/sysmouse (==) Mouse0: Emulate3Buttons, Emulate3Timeout: 50 (**) Option ZAxisMapping 4 5 6 7 (**) Mouse0: ZAxisMapping: buttons 4, 5, 6 and 7 (**) Mouse0: Buttons: 11 (**) Mouse0: Sensitivity: 1 (II) XINPUT: Adding extended input device Mouse0 (type: MOUSE) (**) Mouse0: (accel) keeping acceleration scheme 1 (**) Mouse0: (accel) acceleration profile 0 (II) Mouse0: SetupAuto: hw.iftype is 4, hw.model is 0 (II) Mouse0: SetupAuto: protocol is SysMouse I will be sorting 'hardware access layer' issues for myself soon. Thanks for all your help. The problem was the mismatched version numbers. This, no doubt, has prevented alot of other mismatches from popping up. -Nate Maier ___ 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: Mouse appears on screen but does not move
On Wed, Jun 23, 2010 at 10:54:41AM -0500, Nathan Peet Maier wrote: I changed my label in ports-supfile to tag=. which I found in documentation as applicable to ports supfiles. Is this different from source supfiles where . means CURRENT release. Correct. The tag= line for ports should always be . (period, indicating HEAD), while for src it should be whatever tag/release you want to run (RELENG_8_0 for 8.0-RELEASE, RELENG_8 for -STABLE (soon to be 8.1), or . for -CURRENT/HEAD). If you messed with any of the tag= lines in your supfiles, you should examine the contents of /var/db/sup and ensure what's in there matches what you're actually using. I can't help with your X/mouse issues. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: Mouse appears on screen but does not move.
On Wed, Jun 23, 2010 at 8:21 AM, Adam Vande More amvandem...@gmail.com wrote: On Wed, Jun 23, 2010 at 9:46 AM, Nathan Maier maier.nat...@gmail.comwrote: Hi again, I am pretty sure that Adam is right about the version mismatch. I used sysinstall to update the ports tree and had to change options from 8.0-RELEASE-p3 to 8.0-RELEASE. Cvsup deleted the ports tree. Don't know if I have to change the RELENG_8 to something else. Use portsnap. Don't use sysinstall to update your ports tree. -- randi Yeah you would want to set *default release=cvs tag=RELENG_8_0 You may also need to set the date if you want to keep only on RELEASE. If you're trying to keep your packages from that date, probably just easier to use pkg_add -r or download directly eg ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-8.0-release/x11-drivers/ Make sure that is your correct ARCH -- Adam Vande More ___ 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-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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 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. Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (FreeBSD) iQEcBAEBCAAGBQJMIk58AAoJEATO+BI/yjfBvaAIALLZMVxTN8xMfutobstHHEvc OMVlLcnNM4erbCpL7ThbwsyOBEc5gbNSGtK2jvE3Z82uIhM74NXoe5PwnMeN73Gy r8ShMVdfE5hhJC6HmjGx9sV/zf88dySAQ8n0uHUsIUUL0DnvEOvS7pIEs73Ozm3u Cm9+0k2re604pj3gyFOfaXnJBH8VwSk3VPtOBHGQJnpjNRoHDpT6hw0iRO4+O6UA DoGZHIXpBvM0Qb6unisNogDL1Vsg1A208JCPk96YJegH023HE1oE/jmhgqNwiA/V jZY4VcAJUG+Gpc86VGtZv+w3YIiObMTS4ohO+ktGxfxetPbF2QboIdRUnr28yyU= =Pwmz -END PGP SIGNATURE- ___ 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 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/files/Attic/patch-Modules%3A%3Afcntlmodule.c?rev=1.1;content-type=text%2Fplain 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. FYI... Jung-uk Kim ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 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/files/Attic/patch-Modules%3A%3Afcntlmodule.c?rev=1.1;content-type=text%2Fplain 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. 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... Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (FreeBSD) iQEcBAEBCAAGBQJMIlVyAAoJEATO+BI/yjfBLgcIAKXIekJTGptB51L3XJaJL0q4 I+3nAqDcexDiTIAZ3ExDW47MNeh89fR5Iun2kgYlaOYtEEz8iFdJkrH2dgjkRGpt iBXcjuYw/rVINkvl03tovwIaDNmHjvD3NyvvTSOqmSsRnyR6Z7LACNqQr95nPzrF jJFS+AWT0QeytzhJFSAHXniR9paTsktnHTIN4XEdnYlzNIIhP8BoDgfJ3RqGJRk9 QcvZtait5JWHaGJFhGvN/j30lGsHPabt9zWqNVSHLJ9pSzfwAtW7Ihwso55/blYA JxkRUps2AfK9ZhvQ2B0eArVQLjA61HifVE1UNLrkh1KMeUPth4eIZvBZuWtJ7R8= =ZCD9 -END PGP SIGNATURE- ___ 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 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/files/Att ic/patch-Modules%3A%3Afcntlmodule.c?rev=1.1;content-type=text%2Fpl 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. :-( Jung-uk Kim ___ 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 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/files/A
tt
ic/patch-Modules%3A%3Afcntlmodule.c?rev=1.1;content-type=text%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. :-(
Jung-uk Kim
___
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2010/06/23 12:10, Jung-uk Kim wrote:
It is still a kludge and it won't be fixed. :-(
Another thought - what about just hiding the printf under #ifdef
DIAGNOSTIC... I don't really see any reason why we must print it out if
we truncate it every time...
Cheers,
- --
Xin LI delp...@delphij.nethttp://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.15 (FreeBSD)
iQEcBAEBCAAGBQJMIl2QAAoJEATO+BI/yjfBpz0IAM88YOx5CVoYRCEW8EwCaW+N
5Ugks9hCvbsJgU2yLxeg5hGal0wOHKONLxaq9pXvQFybgRT9SLmna2FJLTJ6XYTu
pjtjeby40mpwRTwU5rZgJ//aYgHW48kK9N/CoE63zKycYQbjLFGnZmXbel9itZzL
Xnpj9kc0zlpqtk6yZd4XA+m90VrIgnMKmxeP0A5OzuWJKUBmvciqSMYEBQ0pkP03
sSiN5QIzW/gRMgYSJEsTGz5+q10ZDf0NOecuhOujLphWLzWxkq6UOqRi3JXvFaqo
ajRDpGEG65r2IDd8qo4y50U0FGeHmysTFUPU3aAOzjb10LbNbmT6zX+3G1rSMFY=
=A2pe
-END PGP SIGNATURE-
Index: sys/kern/sys_generic.c
===
--- sys/kern/sys_generic.c (revision 209472)
+++ sys/kern/sys_generic.c (working copy)
@@ -628,9 +628,11 @@
caddr_t data;
if (uap-com 0x) {
+#ifdef DIAGNOSTIC
printf(
WARNING pid %d (%s): ioctl sign-extension ioctl %lx\n,
td-td_proc-p_pid, td-td_name, uap-com);
+#endif
uap-com = 0x;
}
com = uap-com;
___
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 Wednesday 23 June 2010 03:16 pm, Xin LI wrote: On 2010/06/23 12:10, Jung-uk Kim wrote: It is still a kludge and it won't be fixed. :-( Another thought - what about just hiding the printf under #ifdef DIAGNOSTIC... I don't really see any reason why we must print it out if we truncate it every time... Yes, I agree. Jung-uk Kim ___ 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 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/files
/A tt
ic/patch-Modules%3A%3Afcntlmodule.c?rev=1.1;content-type=text
%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. ;-)
Thanks,
Jung-uk Kim
--- Modules/fcntlmodule.c.orig 2009-05-24 11:41:43.0 -0400
+++ Modules/fcntlmodule.c 2010-06-23 15:27:42.0 -0400
@@ -110,7 +110,12 @@
in their unsigned long ioctl codes this will break and need
special casing based on the platform being built on.
*/
+#if defined(__APPLE__) || defined(__FreeBSD__) || defined(__NetBSD__) || \
+defined(__OpenBSD__)
+ unsigned long code;
+#else
unsigned int code;
+#endif
int arg;
int ret;
char *str;
___
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 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.
Cheers,
Jung-uk Kim
--- Modules/fcntlmodule.c.orig 2009-05-24 11:41:43.0 -0400
+++ Modules/fcntlmodule.c 2010-06-23 16:56:10.0 -0400
@@ -97,6 +97,13 @@
{
#define IOCTL_BUFSZ 1024
int fd;
+#if defined(__APPLE__) || defined(__FreeBSD__) || defined(__NetBSD__) || \
+defined(__OpenBSD__)
+#define IOCTL_ULONG 1
+#endif
+#ifdef IOCTL_ULONG
+ unsigned long code;
+#else
/* 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
@@ -105,12 +112,9 @@
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;
+#endif
int arg;
int ret;
char *str;
@@ -118,7 +122,11 @@
int mutate_arg = 1;
char buf[IOCTL_BUFSZ+1]; /* argument plus NUL byte */
+#ifdef IOCTL_ULONG
+ if (PyArg_ParseTuple(args, Okw#|i:ioctl,
+#else
if (PyArg_ParseTuple(args, OIw#|i:ioctl,
+#endif
conv_descriptor, fd, code,
str, len, mutate_arg)) {
char *arg;
@@ -169,7 +177,11 @@
}
PyErr_Clear();
+#ifdef IOCTL_ULONG
+ if (PyArg_ParseTuple(args, Oks#:ioctl,
+#else
if (PyArg_ParseTuple(args, OIs#:ioctl,
+#endif
conv_descriptor, fd, code, str,
