From owner-freebsd-hackers@FreeBSD.ORG Mon May 16 11:11:45 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 84CFD16A4CE for ; Mon, 16 May 2005 11:11:45 +0000 (GMT) Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A30F43D8B for ; Mon, 16 May 2005 11:11:45 +0000 (GMT) (envelope-from juho.vuori@kepa.fi) Received: from 217-140-230-13.adsl-net.finnetcom.net ([217.140.230.13]:54436 "EHLO [217.140.230.13]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228739AbVEPLLn (ORCPT ); Mon, 16 May 2005 14:11:43 +0300 Message-ID: <42887FEE.3000705@kepa.fi> Date: Mon, 16 May 2005 14:11:42 +0300 From: Juho Vuori User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050512) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Bug in devinfo or something wrong with me? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2005 11:11:45 -0000 The below included simple program reliably printfs "error 4\n" on 5.4-RELEASE. Am I understanding something wrong or is this a bug in libdevinfo? To continue on this however, if you put say sleep(5) between devinfo_free() and the second devinfo_init() and manage to change the device configuration during the sleep (tested with pluggin in/out a USB memory), the program terminates with no errors. I've run into other oddities with devinfo as well, but in much more complex situations so they might just as well be variations of this simple example. Juho /* save this as test.c and compile: * cc -o test test.c -ldevinfo */ #include #include int main () { struct devinfo_dev *root; if (devinfo_init()) { printf("error 1\n"); return -1; } if ((root = devinfo_handle_to_device(DEVINFO_ROOT_DEVICE)) == 0) { printf("error 2\n"); return -1; } devinfo_free(); if (devinfo_init()) { printf("error 3\n"); return -1; } if ((root = devinfo_handle_to_device(DEVINFO_ROOT_DEVICE)) == 0) { printf("error 4\n"); return -1; } devinfo_free(); printf("no errors\n"); return 0; } From owner-freebsd-hackers@FreeBSD.ORG Mon May 16 12:51:26 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F133116A4CE for ; Mon, 16 May 2005 12:51:26 +0000 (GMT) Received: from fafoe.narf.at (chello213047085026.6.14.vie.surfer.at [213.47.85.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5346843D45 for ; Mon, 16 May 2005 12:51:26 +0000 (GMT) (envelope-from stefan@fafoe.narf.at) Received: from wombat.fafoe.narf.at (wombat.fafoe.narf.at [192.168.1.42]) by fafoe.narf.at (Postfix) with ESMTP id B075E3FA6; Mon, 16 May 2005 14:51:14 +0200 (CEST) Received: by wombat.fafoe.narf.at (Postfix, from userid 1001) id 1571CDF; Mon, 16 May 2005 14:51:12 +0200 (CEST) Date: Mon, 16 May 2005 14:51:12 +0200 From: Stefan Farfeleder To: Juho Vuori Message-ID: <20050516125109.GF33622@wombat.fafoe.narf.at> Mail-Followup-To: Juho Vuori , freebsd-hackers@freebsd.org References: <42887FEE.3000705@kepa.fi> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="sdtB3X0nJg68CQEu" Content-Disposition: inline In-Reply-To: <42887FEE.3000705@kepa.fi> User-Agent: Mutt/1.5.9i cc: freebsd-hackers@freebsd.org Subject: Re: Bug in devinfo or something wrong with me? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2005 12:51:27 -0000 --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, May 16, 2005 at 02:11:42PM +0300, Juho Vuori wrote: > The below included simple program reliably printfs "error 4\n" on > 5.4-RELEASE. Am I understanding something wrong or is this a bug in > libdevinfo? There is indeed a bug in libdevinfo. > To continue on this however, if you put say sleep(5) between > devinfo_free() and the second devinfo_init() and manage to change the > device configuration during the sleep (tested with pluggin in/out a USB > memory), the program terminates with no errors. I've run into other > oddities with devinfo as well, but in much more complex situations so > they might just as well be variations of this simple example. > if (devinfo_init()) { devinfo_init() initialises the devinfo_dev tailq, devinfo_generation and sets devinfo_initted to 1. > devinfo_free(); devinfo_free() clears devinfo_dev and sets devinfo_initted to 0 but devinfo_generation keeps its value. > if (devinfo_init()) { Now devinfo_dev doesn't get filled because ubus.ub_generation == devinfo_generation. Here is a patch that resets devinfo_generation to 0 in devinfo_free(). The whole file can probably be simplified a bit due to this bug. Stefan --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="devinfo.c.diff" Index: devinfo.c =================================================================== RCS file: /home/ncvs/src/lib/libdevinfo/devinfo.c,v retrieving revision 1.6 diff -I.svn -u -r1.6 devinfo.c --- devinfo.c 1 Mar 2005 20:32:05 -0000 1.6 +++ devinfo.c 16 May 2005 12:40:24 -0000 @@ -367,6 +370,7 @@ free(dr); } devinfo_initted = 0; + devinfo_generation = 0; } /* --sdtB3X0nJg68CQEu-- From owner-freebsd-hackers@FreeBSD.ORG Mon May 16 13:22:18 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6409516A4CE; Mon, 16 May 2005 13:22:18 +0000 (GMT) Received: from multiplay.co.uk (www1.multiplay.co.uk [212.42.16.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 947ED43DE7; Mon, 16 May 2005 13:22:17 +0000 (GMT) (envelope-from killing@multiplay.co.uk) Received: from vader ([212.135.219.179]) by multiplay.co.uk (multiplay.co.uk [212.42.16.7]) (MDaemon.PRO.v8.0.2.R) with ESMTP id md50001413876.msg; Mon, 16 May 2005 14:17:45 +0100 Message-ID: <03e401c55a1a$34d3c330$b3db87d4@multiplay.co.uk> From: "Steven Hartland" To: , Date: Mon, 16 May 2005 14:21:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Processed: multiplay.co.uk, Mon, 16 May 2005 14:17:45 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 212.135.219.179 X-Return-Path: killing@multiplay.co.uk X-MDAV-Processed: multiplay.co.uk, Mon, 16 May 2005 14:17:47 +0100 Subject: amd64 compile of rrdtool ( relocation R_X86_64_32 error ) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2005 13:22:18 -0000 When compiling rrdtool on amd64 I get the follow. Having read around about the message I must say I'm none the wiser. I've tried adding -fPIC to the rrd_private compile but that doesnt seem to have any effect. What am I missing? [log] /bin/sh /usr/local/bin/libtool15 --mode=link cc -O -pipe -I/usr/local/include -L/usr/local/lib -Wall -pedantic -Wshadow -Wpointer-arith -Wcast-align -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Winline -o librrd_private.la -static -fPIC gdpng.lo getopt.lo getopt1.lo gifsize.lo parsetime.lo pngsize.lo rrd_create.lo rrd_diff.lo rrd_dump.lo rrd_info.lo rrd_error.lo rrd_fetch.lo rrd_format.lo rrd_graph.lo rrd_last.lo rrd_open.lo rrd_resize.lo rrd_restore.lo rrd_tune.lo rrd_update.lo rrd_xport.lo ../cgilib-0.4/librrd_cgi.la ../gd1.3/librrd_gd.la ../libpng-1.0.9/librrd_png.la -lz -lm [/log] [error] rm -f blib/arch/auto/RRDs/RRDs.so LD_RUN_PATH="" cc -shared -L/usr/local/lib RRDs.o -L../src/.libs/ -lrrd_private -lz -lm -o blib/arch/auto/RRDs/RRDs.so /usr/bin/ld: ../src/.libs//librrd_private.a(getopt.o): relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC ../src/.libs//librrd_private.a: could not read symbols: Bad value [/error] ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Mon May 16 13:33:08 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A7B1C16A4CE; Mon, 16 May 2005 13:33:08 +0000 (GMT) Received: from multiplay.co.uk (www1.multiplay.co.uk [212.42.16.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id D615E43D9D; Mon, 16 May 2005 13:33:07 +0000 (GMT) (envelope-from killing@multiplay.co.uk) Received: from vader ([212.135.219.179]) by multiplay.co.uk (multiplay.co.uk [212.42.16.7]) (MDaemon.PRO.v8.0.2.R) with ESMTP id md50001413902.msg; Mon, 16 May 2005 14:28:26 +0100 Message-ID: <043501c55a1b$b2f08090$b3db87d4@multiplay.co.uk> From: "Steven Hartland" To: , References: <03e401c55a1a$34d3c330$b3db87d4@multiplay.co.uk> Date: Mon, 16 May 2005 14:32:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Processed: multiplay.co.uk, Mon, 16 May 2005 14:28:26 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 212.135.219.179 X-Return-Path: killing@multiplay.co.uk X-MDAV-Processed: multiplay.co.uk, Mon, 16 May 2005 14:28:28 +0100 Subject: Re: amd64 compile of rrdtool ( relocation R_X86_64_32 error ) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2005 13:33:08 -0000 Ok so I was blind and missed the -static removing this results in a successful compile. I assume this was the correct thing to do. Will do some testing then submit a PR with a patch if its all good. Steve ----- Original Message ----- From: "Steven Hartland" ... > [log] > /bin/sh /usr/local/bin/libtool15 --mode=link > cc -O -pipe -I/usr/local/include -L/usr/local/lib -Wall -pedantic -Wshadow -Wpointer-arith -Wcast-align -Wmissing-prototypes -Wmissing-declarations > -Wnested-externs -Winline -o librrd_private.la -static -fPIC gdpng.lo getopt.lo getopt1.lo gifsize.lo parsetime.lo > pngsize.lo rrd_create.lo rrd_diff.lo rrd_dump.lo rrd_info.lo rrd_error.lo rrd_fetch.lo rrd_format.lo rrd_graph.lo rrd_last.lo > rrd_open.lo rrd_resize.lo rrd_restore.lo rrd_tune.lo rrd_update.lo rrd_xport.lo ../cgilib-0.4/librrd_cgi.la > ../gd1.3/librrd_gd.la ../libpng-1.0.9/librrd_png.la -lz -lm > [/log] ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Mon May 16 13:31:27 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E37216A4CE for ; Mon, 16 May 2005 13:31:27 +0000 (GMT) Received: from alice.et.bocholt.fh-gelsenkirchen.de (alice.et.bocholt.fh-gelsenkirchen.de [193.175.197.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE2AF43DC5 for ; Mon, 16 May 2005 13:31:25 +0000 (GMT) (envelope-from gouders@et.bocholt.fh-gelsenkirchen.de) Received: from musashi.et.bocholt.fh-gelsenkirchen.de (musashi.et.bocholt.fh-gelsenkirchen.de [193.175.197.95]) j4GDVKOr021578 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 16 May 2005 15:31:20 +0200 Received: from karga.hank.home (karga.hank.home [192.168.252.2]) id j4GDV00W008985 for ; Mon, 16 May 2005 15:31:00 +0200 (CEST) (envelope-from hank@karga.hank.home) Received: from localhost (localhost [127.0.0.1]) by karga.hank.home (8.13.3/8.13.3) with ESMTP id j4GDWgpA001139 for ; Mon, 16 May 2005 15:32:43 +0200 (CEST) (envelope-from hank@karga.hank.home) Message-Id: <200505161332.j4GDWgpA001139@karga.hank.home> From: Dirk Gouders To: freebsd-hackers@freebsd.org Date: Mon, 16 May 2005 15:32:42 +0200 Sender: gouders@et.bocholt.fh-ge.de X-Scanned-By: MIMEDefang 2.43 X-Mailman-Approved-At: Mon, 16 May 2005 13:47:52 +0000 Subject: 5.4-RELEASE: 3c905B-TX only works in promicuous mode X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Dirk Gouders List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2005 13:31:27 -0000 Hello, I installed 5.4-RELEASE on one of my machines and have the problem that my 3c905B-TX NIC seems to accept packets only when in promiscuous mode. (I first noticed, that everything works when tcpdump is running and then just used `ifconfig xl0 promisc' to get the NIC working) Sending packets seems to work, because if I try to ping another machine and run tcpdump on the ping-target, I see the ARP requests as well as the ARP replies but the replies don't seem to get accepted/recognized by the ping-source -- until I put the NIC on the ping-source into promiscuous mode. Once the 5.4-machine knows the ping-target's MAC address (after having been in promiscuous mode), I see the echo requests and replies on the ping-target but the replies also don't get accepted/recognized by the ping source. When I use another NIC (RealTek 8139 10/100BaseTX) on the 5.4-machine, everything works fine. Also, the 3c905B-TX NIC worked fine under 4.11-STABLE. As everything works fine when I use another NIC, I thought that there might be a problem with the xl driver and I tried to use the earliest if_xl.c and if_xlreg.h from the RELENG_5 branch but that didn't help. Then, I tried to use the driver files that were used in the 4.11-STABLE version under which the NIC worked well, but that turned out not to be such a trivial task. I would be glad if someone could give me a hint on how I can solve this problem? Dirk Here are some details about my network setup: # ifconfig xl0 xl0: flags=28943 mtu 1500 options=9 inet 192.168.252.9 netmask 0xffffff00 broadcast 192.168.252.255 inet6 fe80::250:daff:fedf:1c4d%xl0 prefixlen 64 scopeid 0x1 ether 00:50:da:df:1c:4d media: Ethernet autoselect (100baseTX ) status: active # netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.252.1 UGS 0 0 xl0 127.0.0.1 127.0.0.1 UH 0 0 lo0 192.168.252 link#1 UC 0 0 xl0 192.168.252.1 link#1 UHLW 1 17 xl0 192.168.252.2 00:50:22:e9:74:37 UHLW 0 89 xl0 430 Internet6: Destination Gateway Flags Netif Expire ::1 ::1 UH lo0 fe80::%xl0/64 link#1 UC xl0 fe80::250:daff:fedf:1c4d%xl0 00:50:da:df:1c:4d UHL lo0 fe80::%lo0/64 fe80::1%lo0 U lo0 fe80::1%lo0 link#2 UHL lo0 ff01::/32 ::1 U lo0 ff02::%xl0/32 link#1 UC xl0 ff02::%lo0/32 ::1 UC lo0 From owner-freebsd-hackers@FreeBSD.ORG Mon May 16 14:17:38 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2CE9F16A4CE for ; Mon, 16 May 2005 14:17:38 +0000 (GMT) Received: from multiplay.co.uk (www1.multiplay.co.uk [212.42.16.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DF6D43D94 for ; Mon, 16 May 2005 14:17:37 +0000 (GMT) (envelope-from killing@multiplay.co.uk) Received: from vader ([212.135.219.179]) by multiplay.co.uk (multiplay.co.uk [212.42.16.7]) (MDaemon.PRO.v8.0.2.R) with ESMTP id md50001414024.msg for ; Mon, 16 May 2005 15:12:46 +0100 Message-ID: <046901c55a21$e3b97550$b3db87d4@multiplay.co.uk> From: "Steven Hartland" To: "Dirk Gouders" , References: <200505161332.j4GDWgpA001139@karga.hank.home> Date: Mon, 16 May 2005 15:16:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Processed: multiplay.co.uk, Mon, 16 May 2005 15:12:46 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 212.135.219.179 X-Return-Path: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-hackers@freebsd.org X-MDAV-Processed: multiplay.co.uk, Mon, 16 May 2005 15:12:46 +0100 Subject: Re: 5.4-RELEASE: 3c905B-TX only works in promicuous mode X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2005 14:17:38 -0000 Have you tried turning off RXCSUM? Steve ----- Original Message ----- From: "Dirk Gouders" > I would be glad if someone could give me a hint on how I can solve > this problem? ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Mon May 16 15:24:04 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9485C16A4CE for ; Mon, 16 May 2005 15:24:04 +0000 (GMT) Received: from alice.et.bocholt.fh-gelsenkirchen.de (alice.et.bocholt.fh-gelsenkirchen.de [193.175.197.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7EB243D4C for ; Mon, 16 May 2005 15:24:02 +0000 (GMT) (envelope-from gouders@et.bocholt.fh-gelsenkirchen.de) Received: from musashi.et.bocholt.fh-gelsenkirchen.de (musashi.et.bocholt.fh-gelsenkirchen.de [193.175.197.95]) j4GFNxOr021953 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 16 May 2005 17:23:59 +0200 Received: from karga.hank.home (karga.hank.home [192.168.252.2]) id j4GFNdhn009324; Mon, 16 May 2005 17:23:39 +0200 (CEST) (envelope-from hank@karga.hank.home) Received: from localhost (localhost [127.0.0.1]) by karga.hank.home (8.13.3/8.13.3) with ESMTP id j4GFPKdl001377; Mon, 16 May 2005 17:25:23 +0200 (CEST) (envelope-from hank@karga.hank.home) Message-Id: <200505161525.j4GFPKdl001377@karga.hank.home> To: "Steven Hartland" In-Reply-To: Message from "Steven Hartland" <046901c55a21$e3b97550$b3db87d4@multiplay.co.uk> Date: Mon, 16 May 2005 17:25:20 +0200 From: Dirk GOUDERS X-Scanned-By: MIMEDefang 2.43 cc: freebsd-hackers@freebsd.org Subject: Re: 5.4-RELEASE: 3c905B-TX only works in promicuous mode X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2005 15:24:04 -0000 > Have you tried turning off RXCSUM? Sorry that I forgot to mention that I also tried to turn off RXCSUM as well as VLAN_MTU. Those changes also did not help. Dirk From owner-freebsd-hackers@FreeBSD.ORG Mon May 16 16:25:04 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A2B2916A4CE for ; Mon, 16 May 2005 16:25:04 +0000 (GMT) Received: from crow.addict.de (raven.addict.de [80.86.187.141]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42DD043D67 for ; Mon, 16 May 2005 16:25:01 +0000 (GMT) (envelope-from j.unger@addict.de) Received: from crow.addict.de (raven.addict.de [80.86.187.141]) by crow.addict.de (8.12.9/8.12.6) with ESMTP id j4GGOu3H063521 for ; Mon, 16 May 2005 18:24:56 +0200 (CEST) (envelope-from j.unger@addict.de) Received: (from unger@localhost) by crow.addict.de (8.12.9/8.12.6/Submit) id j4GGOulN063520 for freebsd-hackers@freebsd.org; Mon, 16 May 2005 18:24:56 +0200 (CEST) X-Authentication-Warning: crow.addict.de: unger set sender to j.unger@addict.de using -f Date: Mon, 16 May 2005 18:24:56 +0200 From: Juergen Unger To: freebsd-hackers@freebsd.org Message-ID: <20050516162456.GC69167@crow.addict.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Subject: jails and output of df/mount [PATCH] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2005 16:25:04 -0000 Hi ! within a jail there are at this time two possibilities of operation for the syscall getfsstat (which is used e.g. for the commands 'df' and 'mount'): security.jail.getfsstatroot_only = 0: getfsstat return all filesystems mounted anywhere at the machine security.jail.getfsstatroot_only = 1: getfsstat returns the filesystem where the jail-root is in and nothing more (mountpoints within the jails fs-tree are not returned) IMHO is this 2nd one not what is really needed: If we have additional filesystems mounted within the jails tree they should be visible too so that they are shown with a simple 'df' or 'mount'. I made a small patch for this which is available at and should work against CURRENT and RELENG_5_4 Any comments ? I am not sure if there is locking needed (mtx_lock, mtx_unlock) around this new piece of code, at this time ot works for me without locking... Any other opinions ? bye, Juergen From owner-freebsd-hackers@FreeBSD.ORG Mon May 16 17:12:07 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2EDB516A4D0 for ; Mon, 16 May 2005 17:12:07 +0000 (GMT) Received: from enterprise4.noxa.de (enterprise.noxa.de [212.60.197.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id F382B43D7D for ; Mon, 16 May 2005 17:12:05 +0000 (GMT) (envelope-from arundel@h3c.de) Received: (qmail 29370 invoked from network); 16 May 2005 19:11:58 +0200 Received: from p508feebd.dip.t-dialin.net (HELO localhost.skatecity) (80.143.238.189) by enterprise.noxa.de with AES256-SHA encrypted SMTP; 16 May 2005 19:11:58 +0200 Received: from localhost.skatecity (nobody@localhost.skatecity [127.0.0.1]) by localhost.skatecity (8.13.3/8.13.3) with ESMTP id j4GHBiZM020077 for ; Mon, 16 May 2005 19:11:55 +0200 (CEST) (envelope-from arundel@localhost.skatecity) Received: (from arundel@localhost) by localhost.skatecity (8.13.3/8.13.3/Submit) id j4GHBiMM020076 for freebsd-hackers@freebsd.org; Mon, 16 May 2005 19:11:44 +0200 (CEST) (envelope-from arundel) From: alexander Date: Mon, 16 May 2005 19:11:44 +0200 To: freebsd-hackers@freebsd.org Message-ID: <20050516171143.GA19979@skatecity> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Console ASCII interpretation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2005 17:12:07 -0000 Hi there. I'm using syscall number 4 write() to output data to stdout using x86 assembly. When I try to output the following DWORD: 0x00003532 I get the following output under Eterm and xterm: "25". Which is exactly what I want. However when I do the very same under the console (using bash or sh. It doesn't matter) I get this output: "25 ". I looked up the ASCII value for 00h and it says NUL. Doesn't that mean that there shouldn't be any output at all? Thx. From owner-freebsd-hackers@FreeBSD.ORG Mon May 16 17:30:38 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1AACB16A4CE for ; Mon, 16 May 2005 17:30:38 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id A24AE43D99 for ; Mon, 16 May 2005 17:30:37 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.3) id j4GHUYiS093121; Mon, 16 May 2005 12:30:34 -0500 (CDT) (envelope-from dan) Date: Mon, 16 May 2005 12:30:34 -0500 From: Dan Nelson To: alexander Message-ID: <20050516173034.GB85914@dan.emsphone.com> References: <20050516171143.GA19979@skatecity> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050516171143.GA19979@skatecity> X-OS: FreeBSD 5.4-STABLE X-message-flag: Outlook Error User-Agent: Mutt/1.5.9i cc: freebsd-hackers@freebsd.org Subject: Re: Console ASCII interpretation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2005 17:30:38 -0000 In the last episode (May 16), alexander said: > I'm using syscall number 4 write() to output data to stdout using x86 > assembly. When I try to output the following DWORD: 0x00003532 I get > the following output under Eterm and xterm: "25". Which is exactly > what I want. > > However when I do the very same under the console (using bash or sh. > It doesn't matter) I get this output: "25 ". > > I looked up the ASCII value for 00h and it says NUL. Doesn't that > mean that there shouldn't be any output at all? Did you maybe forget to push the 3rd argument to write onto the stack before making the syscall? That's the number of bytes to write. If there happened to be a 4 on the stack, then write() would write 4 bytes starting at whatever buffer your 2nd argument points to. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Mon May 16 18:19:09 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 18B9216A4CE for ; Mon, 16 May 2005 18:19:09 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B10B43DAF for ; Mon, 16 May 2005 18:19:08 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j4GIHGTf023768; Mon, 16 May 2005 12:17:16 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 16 May 2005 12:17:16 -0600 (MDT) Message-Id: <20050516.121716.41656814.imp@bsdimp.com> To: arundel@h3c.de From: Warner Losh In-Reply-To: <20050516171143.GA19979@skatecity> References: <20050516171143.GA19979@skatecity> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: Console ASCII interpretation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2005 18:19:09 -0000 From: alexander Subject: Console ASCII interpretation Date: Mon, 16 May 2005 19:11:44 +0200 > Hi there. > > I'm using syscall number 4 write() to output data to stdout using x86 > assembly. When I try to output the following DWORD: 0x00003532 I get > the following output under Eterm and xterm: "25". Which is exactly > what I want. > > However when I do the very same under the console (using bash or sh. > It doesn't matter) I get this output: "25 ". > > I looked up the ASCII value for 00h and it says NUL. Doesn't that mean > that there shouldn't be any output at all? No. It means NUL. When writing with write(2), you are telling the system to output 4 bytes. How different terminal emulation programs react is up to them (since xterm and the console are implemented by different sets of code). Warner From owner-freebsd-hackers@FreeBSD.ORG Mon May 16 19:01:22 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E14A516A4CE for ; Mon, 16 May 2005 19:01:22 +0000 (GMT) Received: from enterprise4.noxa.de (enterprise.noxa.de [212.60.197.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBC5443D82 for ; Mon, 16 May 2005 19:01:21 +0000 (GMT) (envelope-from arundel@h3c.de) Received: (qmail 9083 invoked from network); 16 May 2005 21:01:16 +0200 Received: from p508feebd.dip.t-dialin.net (HELO localhost.skatecity) (80.143.238.189) by enterprise.noxa.de with AES256-SHA encrypted SMTP; 16 May 2005 21:01:16 +0200 Received: from localhost.skatecity (nobody@localhost.skatecity [127.0.0.1]) by localhost.skatecity (8.13.3/8.13.3) with ESMTP id j4GJ1DXj020511 for ; Mon, 16 May 2005 21:01:13 +0200 (CEST) (envelope-from arundel@localhost.skatecity) Received: (from arundel@localhost) by localhost.skatecity (8.13.3/8.13.3/Submit) id j4GJ1Ddu020510 for freebsd-hackers@freebsd.org; Mon, 16 May 2005 21:01:13 +0200 (CEST) (envelope-from arundel) From: alexander Date: Mon, 16 May 2005 21:01:13 +0200 To: freebsd-hackers@freebsd.org Message-ID: <20050516190113.GA20359@skatecity> References: <20050516171143.GA19979@skatecity> <20050516.121716.41656814.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050516.121716.41656814.imp@bsdimp.com> Subject: Re: Console ASCII interpretation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2005 19:01:23 -0000 On Mon May 16 05, Warner Losh wrote: > From: alexander > Subject: Console ASCII interpretation > Date: Mon, 16 May 2005 19:11:44 +0200 > > No. It means NUL. When writing with write(2), you are telling the > system to output 4 bytes. How different terminal emulation programs > react is up to them (since xterm and the console are implemented by > different sets of code). > > Warner Surely the implementation is up to the terminal itself, but what's the use of a STANDARD, if it isn't standarized? I found this little explanation: > 0 -- NUL -- Null character > The NUL character in the ASCII character set was originally ment to > be treated as a NOP, a character to be ignored. This would be useful > on paper tapes where additional information had to be added in between > existing information. However, some printing devices had the NUL implemented > as a wite space instead. Later on, the importance of the null character > increased significantly when it was defined as the string terminator in > the C programming language. It made it possible to define strings of > infinite length in programming languages. Until then most languages like > Pascal defined a string as a length indicator, followed by an array that > contained the characters. Since there already is an ascii code for the white space (SP = 20h) I don't quite understand why 00h is also interpreted as a white space. Because that makes two values for a white space, but not a single value for the NOP operator. If this behaviour of the console is due to historic reasons (old BSD or AT&T Unix) then there should be a way of changing the code. Cheers. From owner-freebsd-hackers@FreeBSD.ORG Mon May 16 19:48:57 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8650C16A4D0 for ; Mon, 16 May 2005 19:48:57 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3B3043D7D for ; Mon, 16 May 2005 19:48:56 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j4GJl4O9024848; Mon, 16 May 2005 13:47:04 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 16 May 2005 13:47:04 -0600 (MDT) Message-Id: <20050516.134704.78731828.imp@bsdimp.com> To: arundel@h3c.de From: Warner Losh In-Reply-To: <20050516190113.GA20359@skatecity> References: <20050516171143.GA19979@skatecity> <20050516.121716.41656814.imp@bsdimp.com> <20050516190113.GA20359@skatecity> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: Console ASCII interpretation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2005 19:48:57 -0000 > Since there already is an ascii code for the white space (SP = 20h) I don't > quite understand why 00h is also interpreted as a white space. Because that > makes two values for a white space, but not a single value for the NOP > operator. If this behaviour of the console is due to historic reasons > (old BSD or AT&T Unix) then there should be a way of changing the code. The ANSI character set standard doesn't talk at all about how characters are rendering. Terminal emulation software renders the characters as they see fit. NIL is *NOT* a NOP. While the ansi standard suggests that, it isn't required to be. It is used for a variety of thing in a variety of places. Some terminals use it as a timing character to give other operations a chance to finish. Some terminals even use it to specify coordinates because their command set is binary in nature. In addtion, many terminal emulators will pass through characters that don't enter a meta mode unmolested. In this pass through, often times the default rendering for a character that is not otherwise present in the font is ' '. Sometimes another character is chosen (like a square box, a 1/2 tone triangle, a cursor outline rectangle, etc). That's just part of the game. You could argue that DEL is used to rubout (delete backwards character) a character, why then would you have BS (back space) do the same thing? (please don't argue, since both are right or wrong depending on the context). The point is that control sequences in ASCII aren't well standardized, and even if the original standards documents appear to say otherwise, time has shown a huge variety of implementations out there. You are running into one right now. You are output 4 bytes, when you should only be outputting 2 and are claiming that the bug is shomehow in the console software. Yet the console software is emulating something older with a high degree of fidelity. Were we to change today's implementation, there's code that's been written over time that depends on the current behavior. Maybe not much code, and one could argue that there are bugs in that code. But maybe a bunch of code... I guess what I'm trying to say is that if you output NUL, then you are telling the terminal emulation to do something. Don't be surprised when it does do something :-). The bottom line is that your code is wrong, and your understanding of NUL in this context is wrong and you need to fix both. Warner From owner-freebsd-hackers@FreeBSD.ORG Mon May 16 20:02:54 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A70A16A510; Mon, 16 May 2005 20:02:51 +0000 (GMT) Received: from blackwater.lemis.com (wantadilla.lemis.com [192.109.197.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6052443D90; Mon, 16 May 2005 20:02:50 +0000 (GMT) (envelope-from grog@lemis.com) Received: from blackwater.lemis.com (wantadilla.lemis.com [192.109.197.135]) by blackwater.lemis.com (Postfix) with ESMTP id 5EA24856AB; Tue, 17 May 2005 05:32:42 +0930 (CST) Received: by blackwater.lemis.com (Postfix, from userid 1004) id 3B5154AC3E; Sun, 15 May 2005 20:15:20 -0400 (EDT) Date: Sun, 15 May 2005 20:15:20 -0400 From: Greg 'groggy' Lehey To: =?iso-8859-1?Q?Se=E1n_C=2E?= Farley Message-ID: <20050516001520.GD893@eucla.lemis.com> References: <428307A9.10901@atempo.com> <20050512134151.O2556@thor.farley.org> <20050512163409.O4283@thor.farley.org> <4284CFB5.7040805@atempo.com> <20050513123403.J11641@thor.farley.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20050513123403.J11641@thor.farley.org> User-Agent: Mutt/1.4.2.1i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 cc: hackers@freebsd.org cc: =?iso-8859-1?Q?Herv=E9?= Kergourlay cc: David Xu Subject: Re: Porting on FreeBSD 53 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2005 20:02:54 -0000 [much irrelevant content removed] On Friday, 13 May 2005 at 12:45:12 -0500, Sen C. Farley wrote: > On Fri, 13 May 2005, Hervé Kergourlay wrote: >> did you have any idea if the problem will be solve by the FreeBSD team >> or not ? > > I updated my bug report and tried to notify David Xu but the e-mail > server rejected the e-mail (too many "Received" headers). I am also > Cc'ing Greg Lehey since he ran into a possibly similar bug[1] in > February. > > 1. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/77537 This doesn't ring a bell. I'm currently travelling (the long way back from BSDCan), and I won't be home for another week. I'll look when I get home. Greg -- See complete headers for address and phone numbers From owner-freebsd-hackers@FreeBSD.ORG Mon May 16 20:20:42 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C3E316A4CE for ; Mon, 16 May 2005 20:20:42 +0000 (GMT) Received: from enterprise4.noxa.de (enterprise.noxa.de [212.60.197.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 130C343D81 for ; Mon, 16 May 2005 20:20:41 +0000 (GMT) (envelope-from arundel@h3c.de) Received: (qmail 30917 invoked from network); 16 May 2005 22:20:34 +0200 Received: from p508feebd.dip.t-dialin.net (HELO localhost.skatecity) (80.143.238.189) by enterprise.noxa.de with AES256-SHA encrypted SMTP; 16 May 2005 22:20:34 +0200 Received: from localhost.skatecity (nobody@localhost.skatecity [127.0.0.1]) by localhost.skatecity (8.13.3/8.13.3) with ESMTP id j4GKKTY9021239 for ; Mon, 16 May 2005 22:20:29 +0200 (CEST) (envelope-from arundel@localhost.skatecity) Received: (from arundel@localhost) by localhost.skatecity (8.13.3/8.13.3/Submit) id j4GKKTv5021238 for freebsd-hackers@freebsd.org; Mon, 16 May 2005 22:20:29 +0200 (CEST) (envelope-from arundel) From: alexander Date: Mon, 16 May 2005 22:20:29 +0200 To: freebsd-hackers@freebsd.org Message-ID: <20050516202029.GA21139@skatecity> References: <20050516171143.GA19979@skatecity> <20050516.121716.41656814.imp@bsdimp.com> <20050516190113.GA20359@skatecity> <20050516.134704.78731828.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050516.134704.78731828.imp@bsdimp.com> Subject: Re: Console ASCII interpretation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2005 20:20:42 -0000 On Mon May 16 05, Warner Losh wrote: > > The ANSI character set standard doesn't talk at all about how > characters are rendering. Terminal emulation software renders the > characters as they see fit. NIL is *NOT* a NOP. OK. You defentately have a point right there. Surely telling write(2) to render 4 bytes, when you only want 2 bytes to be shown is not good programming style. On the other hand: When you're saying that NUL is != NOP then that's OK. But what is == NOP. If there was a value that would do a NOP then I could do that, but there isn't. Frankly...when I enter an ascii value directly (ALT+3-digits) the console behaves differently. Because when I enter ALT+000 it DOES produce a NOP. That seems a bit random to me. > > I guess what I'm trying to say is that if you output NUL, then you are > telling the terminal emulation to do something. Don't be surprised > when it does do something :-). > > The bottom line is that your code is wrong, and your understanding of > NUL in this context is wrong and you need to fix both. > > Warner You're right. The code I'm using is wrong when it is being executed under the console. However the fact that Eterm and xterm do what I want to do with my app show that I'm not the only one who needs a NOP ascii value. Both render the NUL ascii code as NOP. Since both terms are much newer than the console this indicates that they reflect the recent changes in software development much better. Keeping code simply because of historic reasons doesn't seem too obvious to me. There are a lot if ways to let the user decide whether he prefers historic code over new code. Hence all the COMPAT options in the kernel. But it's obvious, that it would be much easier if I change my code to only display that many bytes as I really want to be displayed. Thx for the help. From owner-freebsd-hackers@FreeBSD.ORG Mon May 16 20:32:20 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D77D16A4D1 for ; Mon, 16 May 2005 20:32:20 +0000 (GMT) Received: from tinker.exit.com (tinker.exit.com [206.223.0.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id B03E743D2F for ; Mon, 16 May 2005 20:32:19 +0000 (GMT) (envelope-from frank@exit.com) Received: from realtime.exit.com (realtime [206.223.0.5]) by tinker.exit.com (8.13.3/8.13.3) with ESMTP id j4GKWFSW076969; Mon, 16 May 2005 13:32:17 -0700 (PDT) (envelope-from frank@exit.com) Received: from realtime.exit.com (localhost [127.0.0.1]) by realtime.exit.com (8.13.3/8.13.3) with ESMTP id j4GKWFIp072035; Mon, 16 May 2005 13:32:15 -0700 (PDT) (envelope-from frank@realtime.exit.com) Received: (from frank@localhost) by realtime.exit.com (8.13.3/8.12.9/Submit) id j4GKWFqe072034; Mon, 16 May 2005 13:32:15 -0700 (PDT) (envelope-from frank) From: Frank Mayhar Message-Id: <200505162032.j4GKWFqe072034@realtime.exit.com> In-Reply-To: <20050516202029.GA21139@skatecity> To: alexander Date: Mon, 16 May 2005 13:32:15 -0700 (PDT) X-Copyright0: Copyright 2005 Frank Mayhar. All Rights Reserved. X-Copyright1: Permission granted for electronic reproduction as Usenet News or email only. X-Mailer: ELM [version 2.4ME+ PL119 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII cc: freebsd-hackers@freebsd.org Subject: Re: Console ASCII interpretation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: frank@exit.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2005 20:32:20 -0000 alexander wrote: > You're right. The code I'm using is wrong when it is being executed > under the console. However the fact that Eterm and xterm do what I > want to do with my app show that I'm not the only one who needs a > NOP ascii value. Both render the NUL ascii code as NOP. Since both > terms are much newer than the console this indicates that they > reflect the recent changes in software development much better. I wouldn't bet that the xterm code is newer than the console code. Warner's point, that you apparently keep missing, is that, the ancient docs notwithstanding, there _is_ no hard-and-fast standard regarding how ASCII control codes are rendered. The closest thing to a "standard" there concerns BEL, HT, ESC and _possibly_ BS and NL. Everything else is pretty much up for grabs, and this quite definitely _includes_ NUL. Relying on a particular rendering of any ASCII control character across all output devices is the Wrong Thing To Do. > Keeping code simply because of historic reasons doesn't seem too obvious > to me. There are a lot if ways to let the user decide whether he > prefers historic code over new code. Hence all the COMPAT options > in the kernel. Perhaps, but this doesn't _involve_ code. This has to do with the ASCII character set and the standards, or lack thereof, that govern rendering those characters. > But it's obvious, that it would be much easier if I change my code to > only display that many bytes as I really want to be displayed. Not "much easier." "Correct." The fact that your code wrote three NULs to the console in the first place meant that your code, not the console, was broken. -- Frank Mayhar frank@exit.com http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ From owner-freebsd-hackers@FreeBSD.ORG Mon May 16 20:56:56 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A2B916A4CE for ; Mon, 16 May 2005 20:56:56 +0000 (GMT) Received: from enterprise4.noxa.de (enterprise.noxa.de [212.60.197.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23C4643DAE for ; Mon, 16 May 2005 20:56:55 +0000 (GMT) (envelope-from arundel@h3c.de) Received: (qmail 23461 invoked from network); 16 May 2005 22:56:51 +0200 Received: from p508feebd.dip.t-dialin.net (HELO localhost.skatecity) (80.143.238.189) by enterprise.noxa.de with AES256-SHA encrypted SMTP; 16 May 2005 22:56:51 +0200 Received: from localhost.skatecity (nobody@localhost.skatecity [127.0.0.1]) by localhost.skatecity (8.13.3/8.13.3) with ESMTP id j4GKulx8021534 for ; Mon, 16 May 2005 22:56:47 +0200 (CEST) (envelope-from arundel@localhost.skatecity) Received: (from arundel@localhost) by localhost.skatecity (8.13.3/8.13.3/Submit) id j4GKul3b021533 for freebsd-hackers@freebsd.org; Mon, 16 May 2005 22:56:47 +0200 (CEST) (envelope-from arundel) From: alexander Date: Mon, 16 May 2005 22:56:47 +0200 To: freebsd-hackers@freebsd.org Message-ID: <20050516205647.GA21498@skatecity> References: <20050516202029.GA21139@skatecity> <200505162032.j4GKWFqe072034@realtime.exit.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200505162032.j4GKWFqe072034@realtime.exit.com> Subject: Re: Console ASCII interpretation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2005 20:56:56 -0000 On Mon May 16 05, Frank Mayhar wrote: > > Not "much easier." "Correct." > > The fact that your code wrote three NULs to the console in the first > place meant that your code, not the console, was broken. > -- > Frank Mayhar frank@exit.com http://www.exit.com/ > Exit Consulting http://www.gpsclock.com/ > http://www.exit.com/blog/frank/ OK. Got it. I was just a bit surprised, because the code I'm using is taken from a site called 'The assembly gems page'. The author claims that he tested this code very throroughly. It seems not thoroughly enough. Thx for all the help. ***************************************************************************** Here's the code if anybody is interested. %eax=ulong, %edi=mem_pointer ulong2ascii: ; Credits go to Norbert Juffa and ; John Eckerdal's 'Assembly Gems page' ; at http://www.df.lth.se/~john_e/ mov ecx,eax ; save original argument mov esi,89705f41h ; 1e-9*2^61 rounded mul esi ; divide by 1e9 by mult. with recip. add eax,80000000h ; round division result mov esi,0abcc7712h ; 2^28/1e8 * 2^30 rounded up adc edx,0 ; EDX<31:29> = argument / 1e9 mov eax,ecx ; restore original argument shr edx,29 ; leading decimal digit, 0...4 mov ecx,8 ; produce eight more digits mov ebx,edx ; flags whether non-zero digit seen yet or edx,'0' ; convert digit to ASCII mov [edi],dl ; store out to memory cmp ebx,1 ; first digit nonzero ? CY=0 : CY=1 sbb edi,-1 ; incr. pointer if first digit non-zero imul ebx,1000000000 ; multiply quotient digit by divisor sub eax,ebx ; remainder after first digit mul esi ; convert number < 1e9 shld edx,eax, 2 ; into fraction such inc edx ; that 1.0 = 2^28 mov eax,edx ; save result shr eax,28 ; next digit and edx,0fffffffh ; fraction part or ebx,eax ; any non-zero yet ? or eax,'0' ; convert digit to ASCII cvt_loop: mov [edi],al ; store digit out to memory add edx,edx ; 2*fraction cmp ebx,1 ; any non-zero digit seen ? CY=0 : CY=1 lea edx,[edx*4+edx] ; 10*fraction, new digit EAX<31:28>, ; new fraction EAX<27:0> sbb edi,-1 ; incr. ptr if any non-zero digit seen mov eax,edx ; save result shr eax,28 ; next digit = integer part and edx,0fffffffh ; fraction part or ebx,eax ; any non-zero digit yet ? or eax,'0' ; convert digit to ASCII dec ecx ; one more digit jnz cvt_loop ; until all nine digits done mov [edi],al ; store last digit out to memory mov [edi+1],ah ; place string end marker ret ***************************************************************************** From owner-freebsd-hackers@FreeBSD.ORG Mon May 16 21:01:10 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C750716A4CE for ; Mon, 16 May 2005 21:01:10 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id E209D43D76 for ; Mon, 16 May 2005 21:01:09 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.3) id j4GL16Og051377; Mon, 16 May 2005 16:01:06 -0500 (CDT) (envelope-from dan) Date: Mon, 16 May 2005 16:01:06 -0500 From: Dan Nelson To: alexander Message-ID: <20050516210105.GD85914@dan.emsphone.com> References: <20050516171143.GA19979@skatecity> <20050516.121716.41656814.imp@bsdimp.com> <20050516190113.GA20359@skatecity> <20050516.134704.78731828.imp@bsdimp.com> <20050516202029.GA21139@skatecity> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050516202029.GA21139@skatecity> X-OS: FreeBSD 5.4-STABLE X-message-flag: Outlook Error User-Agent: Mutt/1.5.9i cc: freebsd-hackers@freebsd.org Subject: Re: Console ASCII interpretation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2005 21:01:10 -0000 In the last episode (May 16), alexander said: > On Mon May 16 05, Warner Losh wrote: > > The ANSI character set standard doesn't talk at all about how > > characters are rendering. Terminal emulation software renders the > > characters as they see fit. NIL is *NOT* a NOP. > > OK. You defentately have a point right there. Surely telling write(2) > to render 4 bytes, when you only want 2 bytes to be shown is not good > programming style. > > On the other hand: When you're saying that NUL is != NOP then that's > OK. But what is == NOP. If there was a value that would do a NOP then > I could do that, but there isn't. The padding character for your current terminal type is either NUL or the termcap 'pc' capability, or if the 'NP' capability is set, there are no padding characters. Since NP is set for the cons25 termcap entry, if you send it a NUL, it's going to print a NUL. > Frankly...when I enter an ascii value directly (ALT+3-digits) the > console behaves differently. Because when I enter ALT+000 it DOES > produce a NOP. That seems a bit random to me. Well, that's because the code in the keyboard driver that handles the ALT-nnn key combo sets ks_composed_char to zero at the beginning of a compose sequence, and if it's still zero at the end, it assumes that the user hasn't done anything. I'd say that's a bug, but a low-priority one, since you can input a NUL via Ctrl-2 or Ctrl-Space. This has nothing to do with how the display driver handles NUL. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Mon May 16 21:09:55 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 75DD616A4CE for ; Mon, 16 May 2005 21:09:55 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id D16DE43DAF for ; Mon, 16 May 2005 21:09:54 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j4GL8X9v026304; Mon, 16 May 2005 15:08:33 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 16 May 2005 15:08:33 -0600 (MDT) Message-Id: <20050516.150833.59675991.imp@bsdimp.com> To: arundel@h3c.de From: Warner Losh In-Reply-To: <20050516202029.GA21139@skatecity> References: <20050516190113.GA20359@skatecity> <20050516.134704.78731828.imp@bsdimp.com> <20050516202029.GA21139@skatecity> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: Console ASCII interpretation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2005 21:09:55 -0000 > You're right. The code I'm using is wrong when it is being executed > under the console. However the fact that Eterm and xterm do what I > want to do with my app show that I'm not the only one who needs a > NOP ascii value. Both render the NUL ascii code as NOP. Since both > terms are much newer than the console this indicates that they > reflect the recent changes in software development much better. xterm's code base pre-dates syscons by about 10 years. While it started out life as a clu program back in the early 1980's, but 1986 it had been recast in 'C' with X version 10. syscons wasn't written until about 1994 or so. However, which one is RIGHT and which one is WRONG is the wrong question to ask. xterm implements a vt220 with some other goo. This is a different terminal emulation than syscon's emulation, which is an old SCO console, which is akin to, but different than MSDOS's ANSI.SYS emulation. The point that you have consistantly been missing is that each thing that's being emulated treats NUL characters differently. You are also missing the point that NUL characters are *NOT* nops. Get that notion out of your head. It is false. If nothing else, a NUL character, on a terminal line, takes time to transmit, affecting the timing of subsequent characters. Since both xterm and syscons are emulating some kind of terminal, this point is relevant. So you'd need to show that the syscons behavior is a bug by showing that the SCO terminal emulation did things differently, because that's what it is emulating. xterm is getting it right for vt100/vt220 emulation, because I know for a fact that NUL characters, on that type of terminal, did in fact cause no cursor motions and were used for timing only. > Keeping code simply because of historic reasons doesn't seem too obvious > to me. There are a lot if ways to let the user decide whether he > prefers historic code over new code. Hence all the COMPAT options > in the kernel. There's no COMPAT_* option to control this stuff. While railing against this sort of thing may be a good point, it is irrelevant to this discussion. Warner From owner-freebsd-hackers@FreeBSD.ORG Mon May 16 21:15:03 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 39EAD16A4CE for ; Mon, 16 May 2005 21:15:03 +0000 (GMT) Received: from priv-edtnes27.telusplanet.net (outbound04.telus.net [199.185.220.223]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E8BE43D98 for ; Mon, 16 May 2005 21:15:02 +0000 (GMT) (envelope-from cpressey@catseye.mine.nu) Received: from catseye.biscuit.boo ([154.20.76.195]) by priv-edtnes27.telusplanet.netSMTP <20050516211459.UHPQ29154.priv-edtnes27.telusplanet.net@catseye.biscuit.boo> for ; Mon, 16 May 2005 15:14:59 -0600 Date: Mon, 16 May 2005 14:18:30 -0700 From: Chris Pressey To: freebsd-hackers@freebsd.org Message-Id: <20050516141830.6d0ea55e.cpressey@catseye.mine.nu> In-Reply-To: <20050516171143.GA19979@skatecity> References: <20050516171143.GA19979@skatecity> Organization: Cat's Eye Technologies X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-portbld-freebsd4.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: Console ASCII interpretation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2005 21:15:03 -0000 On Mon, 16 May 2005 19:11:44 +0200 alexander wrote: > Hi there. > > I'm using syscall number 4 write() to output data to stdout using x86 > assembly. When I try to output the following DWORD: 0x00003532 I get > the following output under Eterm and xterm: "25". Which is exactly > what I want. > > However when I do the very same under the console (using bash or sh. > It doesn't matter) I get this output: "25 ". > > I looked up the ASCII value for 00h and it says NUL. Doesn't that mean > that there shouldn't be any output at all? syscons and xterm implement different terminal emulations. xterm attempts to be compatible with a DEC VT102 and/or VT220, which treat NUL as non-printing. syscons doesn't aim to be compatible with anything in particular (so there is no standard to which it can be held to for rendering NUL as a blank space.) See the respective manual pages for more information. -Chris From owner-freebsd-hackers@FreeBSD.ORG Mon May 16 22:01:51 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BDA7016A4CE for ; Mon, 16 May 2005 22:01:51 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 790C443D81 for ; Mon, 16 May 2005 22:01:50 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.1/8.13.1) with ESMTP id j4GM1eTm043731; Mon, 16 May 2005 15:01:44 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200505162201.j4GM1eTm043731@gw.catspoiler.org> Date: Mon, 16 May 2005 15:01:40 -0700 (PDT) From: Don Lewis To: arundel@h3c.de In-Reply-To: <20050516202029.GA21139@skatecity> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-hackers@FreeBSD.org Subject: Re: Console ASCII interpretation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2005 22:01:51 -0000 On 16 May, alexander wrote: > You're right. The code I'm using is wrong when it is being executed > under the console. However the fact that Eterm and xterm do what I > want to do with my app show that I'm not the only one who needs a > NOP ascii value. Both render the NUL ascii code as NOP. Since both > terms are much newer than the console this indicates that they > reflect the recent changes in software development much better. If you find pipe the output of your app through more while running in an xterm window, or redirect the output to a file and view the file in your favorite editor, you'll find another couple of cases where NUL isn't a NOP. From owner-freebsd-hackers@FreeBSD.ORG Mon May 16 22:35:23 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C180B16A4CE; Mon, 16 May 2005 22:35:23 +0000 (GMT) Received: from multiplay.co.uk (www1.multiplay.co.uk [212.42.16.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 82F2F43DBB; Mon, 16 May 2005 22:35:22 +0000 (GMT) (envelope-from killing@multiplay.co.uk) Received: from vader ([212.135.219.179]) by multiplay.co.uk (multiplay.co.uk [212.42.16.7]) (MDaemon.PRO.v8.0.2.R) with ESMTP id md50001415121.msg; Mon, 16 May 2005 23:31:08 +0100 Message-ID: <000301c55a67$8115d470$b3db87d4@multiplay.co.uk> From: "Steven Hartland" To: , Date: Mon, 16 May 2005 23:16:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Processed: multiplay.co.uk, Mon, 16 May 2005 23:31:08 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 212.135.219.179 X-Return-Path: killing@multiplay.co.uk X-MDAV-Processed: multiplay.co.uk, Mon, 16 May 2005 23:31:09 +0100 Subject: Strange make buildworld behaviour with 5.4-RELEASE ( amd64 ) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2005 22:35:23 -0000 Doing a make buildworld from a directory other than /usr/src results in the following: [log] /usr/obj/.usr/amd64/src/lib32/usr/lib32/libl.a -> /usr/obj/.usr/amd64/src/lib32/usr/lib32/libln.a /usr/obj/.usr/amd64/src/lib32/usr/lib32/libfl.a -> /usr/obj/.usr/amd64/src/lib32/usr/lib32/libln.a /usr/obj/.usr/amd64/src/lib32/usr/lib32/libl_p.a -> /usr/obj/.usr/amd64/src/lib32/usr/lib32/libln_p.a /usr/obj/.usr/amd64/src/lib32/usr/lib32/libfl_p.a -> /usr/obj/.usr/amd64/src/lib32/usr/lib32/libln_p.a ===> usr.sbin/pcvt/keycap Warning: Object directory not changed from original /.usr/amd64/src/usr.sbin/pcvt/keycap make: don't know how to make /usr/obj/usr/src/lib32/usr/include/stdio.h. Stop *** Error code 2 Stop in /.usr/amd64/src. *** Error code 1 Stop in /.usr/amd64/src. *** Error code 1 Stop in /.usr/amd64/src. *** Error code 1 Stop in /.usr/amd64/src. [/log] My /usr is a symlink to /.usr/amd64/ which shouldnt cause any issues but buildworld get most upset. I first thought it was bad source set but booting to single user and moving things around so /usr is a real dir with the contents of /.usr/amd64 in works just fine. Anyone got any ideas why and how to fix? Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Mon May 16 22:38:46 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 773AE16A4CE; Mon, 16 May 2005 22:38:46 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.194.102.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id 159E143D9A; Mon, 16 May 2005 22:38:46 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 3E2BD5145C; Mon, 16 May 2005 15:38:41 -0700 (PDT) Date: Mon, 16 May 2005 15:38:41 -0700 From: Kris Kennaway To: Steven Hartland Message-ID: <20050516223841.GA18115@xor.obsecurity.org> References: <000301c55a67$8115d470$b3db87d4@multiplay.co.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="r5Pyd7+fXNt84Ff3" Content-Disposition: inline In-Reply-To: <000301c55a67$8115d470$b3db87d4@multiplay.co.uk> User-Agent: Mutt/1.4.2.1i cc: freebsd-hackers@freebsd.org cc: freebsd-stable@freebsd.org Subject: Re: Strange make buildworld behaviour with 5.4-RELEASE ( amd64 ) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2005 22:38:46 -0000 --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 16, 2005 at 11:16:41PM +0100, Steven Hartland wrote: > Doing a make buildworld from a directory other than /usr/src > results in the following: > [log] > /usr/obj/.usr/amd64/src/lib32/usr/lib32/libl.a ->=20 > /usr/obj/.usr/amd64/src/lib32/usr/lib32/libln.a > /usr/obj/.usr/amd64/src/lib32/usr/lib32/libfl.a ->=20 > /usr/obj/.usr/amd64/src/lib32/usr/lib32/libln.a > /usr/obj/.usr/amd64/src/lib32/usr/lib32/libl_p.a ->=20 > /usr/obj/.usr/amd64/src/lib32/usr/lib32/libln_p.a > /usr/obj/.usr/amd64/src/lib32/usr/lib32/libfl_p.a ->=20 > /usr/obj/.usr/amd64/src/lib32/usr/lib32/libln_p.a > =3D=3D=3D> usr.sbin/pcvt/keycap > Warning: Object directory not changed from original=20 > /.usr/amd64/src/usr.sbin/pcvt/keycap > make: don't know how to make /usr/obj/usr/src/lib32/usr/include/stdio.h.= =20 > Stop > *** Error code 2 >=20 > Stop in /.usr/amd64/src. > *** Error code 1 >=20 > Stop in /.usr/amd64/src. > *** Error code 1 >=20 > Stop in /.usr/amd64/src. > *** Error code 1 >=20 > Stop in /.usr/amd64/src. > [/log] >=20 > My /usr is a symlink to /.usr/amd64/ which shouldnt cause any > issues but buildworld get most upset. I first thought it was bad > source set but booting to single user and moving things around > so /usr is a real dir with the contents of /.usr/amd64 in works > just fine. Anyone got any ideas why and how to fix? You need to make sure you don't have stale object files (the pathnames are recorded), so try removing /usr/obj/ and then running 'make cleandir' from your source tree. Kris --r5Pyd7+fXNt84Ff3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCiSDwWry0BWjoQKURAr2LAKC+juBqq/4vTOFRQPuWG+H0mKqZswCfbh4g HI62yebcFvF+wmacG/053h4= =UfFZ -----END PGP SIGNATURE----- --r5Pyd7+fXNt84Ff3-- From owner-freebsd-hackers@FreeBSD.ORG Mon May 16 23:27:33 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB43516A4CE for ; Mon, 16 May 2005 23:27:33 +0000 (GMT) Received: from mx.nts.ch (mail.nts.ch [212.103.67.20]) by mx1.FreeBSD.org (Postfix) with SMTP id CC2A243DD1 for ; Mon, 16 May 2005 23:27:32 +0000 (GMT) (envelope-from stefan@aeschbacher.ch) Received: (qmail 27372 invoked by uid 7650); 16 May 2005 23:30:34 -0000 Received: from stefan@aeschbacher.ch by bernoulli by uid 64011 with qmail-scanner-1.21 Clear:RC:1(212.103.64.3):. Processed in 0.019679 secs); 16 May 2005 23:30:34 -0000 Received: from localhost ([212.103.64.3]) by mx.nts.ch ([192.168.123.34]) with ESMTP via TCP; 16 May 2005 23:30:34 -0000 Received: from ftp.nts.ch (ftp.nts.ch [212.103.67.6]) by horde.nts.ch (IMP) with HTTP for ; Tue, 17 May 2005 01:27:50 +0200 Message-ID: <1116286070.42892c769f613@horde.nts.ch> Date: Tue, 17 May 2005 01:27:50 +0200 From: stefan@aeschbacher.ch To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.3-cvs X-Originating-IP: 212.103.67.6 Subject: Broadcom 5789 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2005 23:27:34 -0000 Hi I just setup a FreeBSD 5.4 stable on a machine using a Gigabyte GA-8I915P Duo Pro motherboard. Contrary to the documentation, the board I have does not use the Broadcom 5751 chip but the 5789 which is not recognized by the bge(4) driver. The 5788 is already in the list of supported chips by the bge driver. From this I guessed that the driver could alsow work with the 5789. I tried the following patch and at least from my minimal testing (only 100Mbit) it looks as if it works. Could someone with knowledge of the Broadcom ethernet chips and the bge driver check if adding support for the 5789 is really that easy and if yes, initiate the needed steps to get the device id's in the kernel? regards Stefan Aeschbacher The patches I used to get it working: --- if_bge.c Sun May 15 01:03:07 2005 +++ if_bge.c.new Sun May 15 01:04:01 2005 @@ -169,6 +169,8 @@ "Broadcom BCM5782 Gigabit Ethernet" }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5788, "Broadcom BCM5788 Gigabit Ethernet" }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5789, + "Broadcom BCM5789 Gigabit Ethernet" }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5901, "Broadcom BCM5901 Fast Ethernet" }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5901A2, --- if_bgereg.h Sun May 15 01:03:19 2005 +++ if_bgereg.h.new Sun May 15 01:04:01 2005 @@ -1874,6 +1874,7 @@ #define BCOM_DEVICEID_BCM5751M 0x167D #define BCOM_DEVICEID_BCM5782 0x1696 #define BCOM_DEVICEID_BCM5788 0x169C +#define BCOM_DEVICEID_BCM5789 0x169D #define BCOM_DEVICEID_BCM5901 0x170D #define BCOM_DEVICEID_BCM5901A2 0x170E From owner-freebsd-hackers@FreeBSD.ORG Tue May 17 00:29:03 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B312C16A4D0 for ; Tue, 17 May 2005 00:29:03 +0000 (GMT) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by mx1.FreeBSD.org (Postfix) with SMTP id 0C25543D90 for ; Tue, 17 May 2005 00:29:03 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 13354 invoked from network); 17 May 2005 00:28:58 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 17 May 2005 00:28:58 -0000 X-pair-Authenticated: 209.68.2.70 Date: Mon, 16 May 2005 19:28:58 -0500 (CDT) From: Mike Silbersack To: stefan@aeschbacher.ch In-Reply-To: <1116286070.42892c769f613@horde.nts.ch> Message-ID: <20050516192701.B59375@odysseus.silby.com> References: <1116286070.42892c769f613@horde.nts.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-hackers@freebsd.org Subject: Re: Broadcom 5789 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2005 00:29:03 -0000 On Tue, 17 May 2005 stefan@aeschbacher.ch wrote: > Could someone with knowledge of the Broadcom ethernet chips > and the bge driver check if adding support for the 5789 is > really that easy and if yes, initiate the needed steps to get > the device id's in the kernel? Adding support for new chips often is that easy, if you look in the 3com xl and Intel fxp driver histories you'll find tons of changes which are just like the one you made below. I'll commit the change if you can remind me to do so later in the week (Thursday or Friday.) Mike "Silby" Silbersack From owner-freebsd-hackers@FreeBSD.ORG Tue May 17 09:26:55 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D488C16A4CE for ; Tue, 17 May 2005 09:26:55 +0000 (GMT) Received: from mx.nts.ch (mail.nts.ch [212.103.67.20]) by mx1.FreeBSD.org (Postfix) with SMTP id D87E343DB7 for ; Tue, 17 May 2005 09:26:54 +0000 (GMT) (envelope-from stefan@aeschbacher.ch) Received: (qmail 24995 invoked by uid 7650); 17 May 2005 09:29:54 -0000 Received: from stefan@aeschbacher.ch by bernoulli by uid 64011 with qmail-scanner-1.21 Clear:RC:1(212.103.64.3):. Processed in 0.021059 secs); 17 May 2005 09:29:54 -0000 Received: from localhost ([212.103.64.3]) by mx.nts.ch ([192.168.123.34]) with ESMTP via TCP; 17 May 2005 09:29:54 -0000 Received: from ftp.nts.ch (ftp.nts.ch [212.103.67.6]) by horde.nts.ch (IMP) with HTTP for ; Tue, 17 May 2005 11:27:10 +0200 Message-ID: <1116322030.4289b8ee7c10c@horde.nts.ch> Date: Tue, 17 May 2005 11:27:10 +0200 From: stefan@aeschbacher.ch To: Mike Silbersack References: <1116286070.42892c769f613@horde.nts.ch> <20050516192701.B59375@odysseus.silby.com> In-Reply-To: <20050516192701.B59375@odysseus.silby.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.3-cvs X-Originating-IP: 212.103.67.6 cc: freebsd-hackers@freebsd.org Subject: Re: Broadcom 5789 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2005 09:26:55 -0000 Hi thanks for your response. I will send you a reminder on Thursday. Stefan Zitat von Mike Silbersack : > > On Tue, 17 May 2005 stefan@aeschbacher.ch wrote: > > > Could someone with knowledge of the Broadcom ethernet chips > > and the bge driver check if adding support for the 5789 is > > really that easy and if yes, initiate the needed steps to get > > the device id's in the kernel? > > Adding support for new chips often is that easy, if you look in the 3com > > xl and Intel fxp driver histories you'll find tons of changes which are > just like the one you made below. > > I'll commit the change if you can remind me to do so later in the week > (Thursday or Friday.) > > Mike "Silby" Silbersack > From owner-freebsd-hackers@FreeBSD.ORG Tue May 17 09:48:31 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0990516A4CE; Tue, 17 May 2005 09:48:31 +0000 (GMT) Received: from multiplay.co.uk (www1.multiplay.co.uk [212.42.16.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 136C543DA0; Tue, 17 May 2005 09:48:30 +0000 (GMT) (envelope-from killing@multiplay.co.uk) Received: from vader ([212.135.219.179]) by multiplay.co.uk (multiplay.co.uk [212.42.16.7]) (MDaemon.PRO.v8.0.2.R) with ESMTP id md50001415777.msg; Tue, 17 May 2005 10:44:06 +0100 Message-ID: <009e01c55ac5$85aa6100$b3db87d4@multiplay.co.uk> From: "Steven Hartland" To: , Date: Tue, 17 May 2005 10:48:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Processed: multiplay.co.uk, Tue, 17 May 2005 10:44:06 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 212.135.219.179 X-Return-Path: killing@multiplay.co.uk X-MDAV-Processed: multiplay.co.uk, Tue, 17 May 2005 10:44:06 +0100 Subject: Strange make buildworld behaviour with 5.4-RELEASE ( amd64 ) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2005 09:48:31 -0000 Didnt get through the first time so resending :) Doing a make buildworld from a directory other than /usr/src results in the following: [log] /usr/obj/.usr/amd64/src/lib32/usr/lib32/libl.a -> /usr/obj/.usr/amd64/src/lib32/usr/lib32/libln.a /usr/obj/.usr/amd64/src/lib32/usr/lib32/libfl.a -> /usr/obj/.usr/amd64/src/lib32/usr/lib32/libln.a /usr/obj/.usr/amd64/src/lib32/usr/lib32/libl_p.a -> /usr/obj/.usr/amd64/src/lib32/usr/lib32/libln_p.a /usr/obj/.usr/amd64/src/lib32/usr/lib32/libfl_p.a -> /usr/obj/.usr/amd64/src/lib32/usr/lib32/libln_p.a ===> usr.sbin/pcvt/keycap Warning: Object directory not changed from original /.usr/amd64/src/usr.sbin/pcvt/keycap make: don't know how to make /usr/obj/usr/src/lib32/usr/include/stdio.h. Stop *** Error code 2 Stop in /.usr/amd64/src. *** Error code 1 Stop in /.usr/amd64/src. *** Error code 1 Stop in /.usr/amd64/src. *** Error code 1 Stop in /.usr/amd64/src. [/log] My /usr is a symlink to /.usr/amd64/ which shouldnt cause any issues but buildworld get most upset. I first thought it was bad source set but booting to single user and moving things around so /usr is a real dir with the contents of /.usr/amd64 in works just fine. Anyone got any ideas why and how to fix? Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Tue May 17 11:19:31 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 30D0116A4CE; Tue, 17 May 2005 11:19:31 +0000 (GMT) Received: from gwdu60.gwdg.de (gwdu60.gwdg.de [134.76.8.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CD4B43DA2; Tue, 17 May 2005 11:19:30 +0000 (GMT) (envelope-from kheuer2@gwdg.de) Received: from gwdu60.gwdg.de (localhost [127.0.0.1]) by gwdu60.gwdg.de (8.13.1/8.12.8) with ESMTP id j4HBJO6v066495; Tue, 17 May 2005 13:19:24 +0200 (CEST) (envelope-from kheuer2@gwdg.de) Received: from localhost (kheuer2@localhost) by gwdu60.gwdg.de (8.13.1/8.12.8/Submit) with ESMTP id j4HBJOmv066492; Tue, 17 May 2005 13:19:24 +0200 (CEST) X-Authentication-Warning: gwdu60.gwdg.de: kheuer2 owned process doing -bs Date: Tue, 17 May 2005 13:19:23 +0200 (CEST) From: Konrad Heuer To: freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org Message-ID: <20050517130356.C99328@gwdu60.gwdg.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: nfs send error 32 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2005 11:19:31 -0000 Hi all, I've an NFS-mounted filesystem (server runs deadrat linux) on a lot of my FreeBSD systems (4.11R), mount options are "bg,rw,intr,-T,-r32768,-w32768". Using TCP and 32k buffers does enhance performance notably. But I've a couple of error messages in /var/log/messages of my clients each day like: date client /kernel: nfs send error 32 for server deadrat:/fs When looking into /usr/src/sys/nfs/nfsproto.h, I don't find anything about error code 32. Any idea or explanation would be very very welcome! BTW: NFS server has to run deadrat linux, and more nfs file systems have to be mounted in future from the same or similar machines. Thanks Konrad Heuer GWDG, Am Fassberg, 37077 Goettingen, Germany, kheuer2@gwdg.de From owner-freebsd-hackers@FreeBSD.ORG Tue May 17 11:35:45 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E1C016A4CE; Tue, 17 May 2005 11:35:45 +0000 (GMT) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B70643D64; Tue, 17 May 2005 11:35:44 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id j4HBZcjA070718; Tue, 17 May 2005 06:35:38 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <4289D703.1030604@centtech.com> Date: Tue, 17 May 2005 06:35:31 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050504 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Konrad Heuer References: <20050517130356.C99328@gwdu60.gwdg.de> In-Reply-To: <20050517130356.C99328@gwdu60.gwdg.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/882/Tue May 17 01:48:03 2005 on mh1.centtech.com X-Virus-Status: Clean cc: freebsd-hackers@freebsd.org cc: freebsd-questions@freebsd.org Subject: Re: nfs send error 32 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2005 11:35:45 -0000 Konrad Heuer wrote: > Hi all, > > I've an NFS-mounted filesystem (server runs deadrat linux) on a lot of my > FreeBSD systems (4.11R), mount options are > "bg,rw,intr,-T,-r32768,-w32768". Using TCP and 32k buffers does enhance > performance notably. > > But I've a couple of error messages in /var/log/messages of my clients > each day like: > > date client /kernel: nfs send error 32 for server deadrat:/fs > > When looking into /usr/src/sys/nfs/nfsproto.h, I don't find anything about > error code 32. > > Any idea or explanation would be very very welcome! > > BTW: NFS server has to run deadrat linux, and more nfs file systems have > to be mounted in future from the same or similar machines. I think it's a lost TCP connection. From man errno: 32 EPIPE Broken pipe. A write on a pipe, socket or FIFO for which there is no process to read the data. Not sure why the connection is dropping, but there could be a whole slew of reasons for that. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology A lost ounce of gold may be found, a lost moment of time never. ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Tue May 17 00:44:03 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 74B1316A4D0 for ; Tue, 17 May 2005 00:44:03 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id C54B643D6A for ; Tue, 17 May 2005 00:44:01 +0000 (GMT) (envelope-from vaida.bogdan@gmail.com) Received: by rproxy.gmail.com with SMTP id i8so586730rne for ; Mon, 16 May 2005 17:44:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=ivO5U3rbOXMbfvCfMY8BcURTa0n4zU/fW+B3VbduOOgLtxbqbAprJWRyQUS7QXC8/xpcjLTuz3v+yOq9e9TZ4Gt1qtcUc8yAM+VHxCdqKhfQrCEl/agDQ3YDOsjQ7Vx8vouQFj9q/AMmEpB9mA15kjS6TECaAjp921L/1oBtyLQ= Received: by 10.38.97.15 with SMTP id u15mr2555866rnb; Mon, 16 May 2005 17:44:01 -0700 (PDT) Received: by 10.38.208.62 with HTTP; Mon, 16 May 2005 17:44:01 -0700 (PDT) Message-ID: <12848a3b0505161744493e5343@mail.gmail.com> Date: Tue, 17 May 2005 00:44:01 +0000 From: vaida bogdan To: freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailman-Approved-At: Tue, 17 May 2005 12:16:08 +0000 Subject: volume problems with snd_via8233 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: vaida bogdan List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2005 00:44:03 -0000 Hi, I've bought a new computer with an ASRock K7Upgrade-880 motherboard with 5.1 channels AC'97 Audio (quoting from install guide and I have a problem with sound on Freebsd 5.4 with snd_via8233. After I load the module, the sound volume is set to max and even though I can lower the sound bar (xmms) or lower the volume in=20 mplayer or even mixer, the volume doesn't change. I can only change it from my audio boxes. I think it could be a module problem because it works ok in windows. # cat /dev/sndstat FreeBSD Audio Driver (newpcm) Installed devices: pcm0: at io 0xd000 irq 22 kld snd_via8233 (5p/1r/0v channels duplex default) From owner-freebsd-hackers@FreeBSD.ORG Tue May 17 00:45:32 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5153216A4D0 for ; Tue, 17 May 2005 00:45:32 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 91CFC43DBC for ; Tue, 17 May 2005 00:45:31 +0000 (GMT) (envelope-from vaida.bogdan@gmail.com) Received: by rproxy.gmail.com with SMTP id i8so586859rne for ; Mon, 16 May 2005 17:45:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=QVQOgXaQHNMcAixt53XCbyKvo952C1K0Bm4vf6dWytBsJsak6LOU6SPZnBFwpi9SC/KoUudPv8iuxSsBEdhffZLFQ21ktJkcF7oTYUFRzs8CaosDe58178kgHtAiOnQ482hOTCCwrAXDHbvUFNgtY+/rNGiF3h4WDLyl1sFc/Vw= Received: by 10.38.104.24 with SMTP id b24mr2555596rnc; Mon, 16 May 2005 17:45:31 -0700 (PDT) Received: by 10.38.208.62 with HTTP; Mon, 16 May 2005 17:45:31 -0700 (PDT) Message-ID: <12848a3b05051617453b2bf0a@mail.gmail.com> Date: Tue, 17 May 2005 00:45:31 +0000 From: vaida bogdan To: freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailman-Approved-At: Tue, 17 May 2005 12:16:08 +0000 Subject: AVerMedia AVerTV GO 007 FM Plus card not detected X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: vaida bogdan List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2005 00:45:32 -0000 I used the handbook instructions: bktr_load=3D"YES" to loader.conf +/- hw.bt848.tuner=3D6 in sysctl.conf bktr man page tells me my tuner is supported, yet dmesg's output shows only= : bktr_mem: memory holder loaded I also tried compilling it in the kernel (by the manual) with no success. This is the first time I tried using a tvtuner on fbsd so I could have got smthg wrong. Any help would be appreciated. From owner-freebsd-hackers@FreeBSD.ORG Tue May 17 13:00:41 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A947116A4CE for ; Tue, 17 May 2005 13:00:41 +0000 (GMT) Received: from bps.jodocus.org (g157016.upc-g.chello.nl [80.57.157.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id E780643DAF for ; Tue, 17 May 2005 13:00:40 +0000 (GMT) (envelope-from joost@jodocus.org) Received: from jodocus.org (localhost [127.0.0.1]) by bps.jodocus.org (8.13.3/8.13.1) with ESMTP id j4HD0WjB085186 for ; Tue, 17 May 2005 15:00:32 +0200 (CEST) (envelope-from joost@jodocus.org) Received: (from joost@localhost) by jodocus.org (8.13.3/8.13.1/Submit) id j4HD0WhX085185 for freebsd-hackers@freebsd.org; Tue, 17 May 2005 15:00:32 +0200 (CEST) (envelope-from joost) Date: Tue, 17 May 2005 15:00:32 +0200 From: Joost Bekkers To: freebsd-hackers@freebsd.org Message-ID: <20050517130032.GA84495@bps.jodocus.org> Mail-Followup-To: Joost Bekkers , freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: Converting a function* into something Joe Admin understands X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2005 13:00:41 -0000 Hi The answer will probably be 'no', but here goes: Is there a way (in the kernel) to convert a pointer to a function into a char* indicating the module it is associated with? More specificly: I've been playing with changing the order of the pfil hooks @runtime via sysctl. To be able to give the sysadmin something (s)he understands I've added a const char * parameter to the pfil_head_register and pfil_add_hook functions, breaking the API. I'm wondering if there is a way to get meaningful text to the sysadmin without breaking the API. Or is it in this case not a bad thing? Thanks. -- greetz Joost joost@jodocus.org From owner-freebsd-hackers@FreeBSD.ORG Tue May 17 21:43:28 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F9FB16A4CE for ; Tue, 17 May 2005 21:43:28 +0000 (GMT) Received: from postfix4-2.free.fr (postfix4-2.free.fr [213.228.0.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6030343DA9 for ; Tue, 17 May 2005 21:43:27 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix4-2.free.fr (Postfix) with ESMTP id 8373631C608; Tue, 17 May 2005 23:43:22 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id E8C2E4080; Tue, 17 May 2005 23:43:24 +0200 (CEST) Date: Tue, 17 May 2005 23:43:24 +0200 From: Jeremie Le Hen To: Juergen Unger Message-ID: <20050517214324.GA1021@obiwan.tataz.chchile.org> References: <20050516162456.GC69167@crow.addict.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050516162456.GC69167@crow.addict.de> User-Agent: Mutt/1.5.9i cc: freebsd-hackers@freebsd.org Subject: Re: jails and output of df/mount [PATCH] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2005 21:43:28 -0000 Hi Juergen, > within a jail there are at this time two possibilities > of operation for the syscall getfsstat (which is used e.g. > for the commands 'df' and 'mount'): > > security.jail.getfsstatroot_only = 0: > getfsstat return all filesystems mounted anywhere at the machine > > security.jail.getfsstatroot_only = 1: > getfsstat returns the filesystem where the jail-root is in > and nothing more (mountpoints within the jails fs-tree are not > returned) > > IMHO is this 2nd one not what is really needed: If we > have additional filesystems mounted within the jails tree > they should be visible too so that they are shown with > a simple 'df' or 'mount'. > > I made a small patch for this which is available at > > and should work against CURRENT and RELENG_5_4 > > Any comments ? I am not sure if there is locking needed > (mtx_lock, mtx_unlock) around this new piece of code, at this > time ot works for me without locking... > Any other opinions ? This works fine on a recent RELENG_5 UP kernel. Given that this exposes some host configuration inside jail, it might be worth adding a sysctl to disable this. However, I'm not really sure this kind of information could really be an attack vector or ramp. There seems to be one small bug in your patch : once applied, we don't see informations about / any longer inside jails. Thanks for your work. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-hackers@FreeBSD.ORG Tue May 17 22:22:30 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 980FB16A4CE for ; Tue, 17 May 2005 22:22:30 +0000 (GMT) Received: from crow.addict.de (raven.addict.de [80.86.187.141]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F09A43D3F for ; Tue, 17 May 2005 22:22:29 +0000 (GMT) (envelope-from j.unger@addict.de) Received: from crow.addict.de (raven.addict.de [80.86.187.141]) by crow.addict.de (8.12.9/8.12.6) with ESMTP id j4HMMM3H006483; Wed, 18 May 2005 00:22:22 +0200 (CEST) (envelope-from j.unger@addict.de) Received: (from unger@localhost) by crow.addict.de (8.12.9/8.12.6/Submit) id j4HMMLg5006482; Wed, 18 May 2005 00:22:21 +0200 (CEST) X-Authentication-Warning: crow.addict.de: unger set sender to j.unger@addict.de using -f Date: Wed, 18 May 2005 00:22:21 +0200 From: Juergen Unger To: Jeremie Le Hen Message-ID: <20050517222221.GA85134@crow.addict.de> References: <20050516162456.GC69167@crow.addict.de> <20050517214324.GA1021@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050517214324.GA1021@obiwan.tataz.chchile.org> User-Agent: Mutt/1.4i cc: freebsd-hackers@freebsd.org Subject: Re: jails and output of df/mount [PATCH] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2005 22:22:30 -0000 Hi Jeremie ! On Tue, May 17, 2005 at 11:43:24PM +0200, Jeremie Le Hen wrote: [...] > This works fine on a recent RELENG_5 UP kernel. Given that this > exposes some host configuration inside jail, it might be worth > adding a sysctl to disable this. However, I'm not really sure > this kind of information could really be an attack vector or ramp. I don't share your opinion that this exposes information not allready known to the processes withing the jail. For example: with this patch I get on an sample jail here the following output: > jail# df -h > Filesystem Size Used Avail Capacity Mounted on > /dev/md3c 4.8G 148M 4.3G 3% /data1/jail/003 > 195.49.136.4:/po 989M 275M 635M 30% /data1/jail/003/usr/ports > 195.49.136.4:/di 989M 189M 721M 21% /data1/jail/003/distfiles > 195.49.136.4:/pa 989M 83M 828M 9% /data1/jail/003/packages > /dev/md2001c 19G 4.0K 18G 0% /data1/jail/003/var/spool/news > devfs 1.0K 1.0K 0B 100% /data1/jail/003/dev > fdescfs 1.0K 1.0K 0B 100% /data1/jail/003/dev/fd > procfs 4.0K 4.0K 0B 100% /data1/jail/003/proc > jail# the processes within the jail can get the same information without the patch if they call df for each mounted fs seperately: > jail# df -h / > Filesystem Size Used Avail Capacity Mounted on > /dev/md3c 4.8G 148M 4.3G 3% /data1/jail/003 > jail# df -h /usr/ports > Filesystem Size Used Avail Capacity Mounted on > 195.49.136.4:/po 989M 275M 635M 30% /data1/jail/003/usr/ports > jail# df -h /distfiles > Filesystem Size Used Avail Capacity Mounted on > 195.49.136.4:/di 989M 189M 721M 21% /data1/jail/003/distfiles . [...and.so.on...] . that in the output the '/data1/jail/003/' path component ist shown is another point to fix (I will make another patch for it), but this behaviour is not changed from before. Better it would be only output the path at it is known to the jailed processes. > There seems to be one small bug in your patch : once applied, we > don't see informations about / any longer inside jails. hmm, I think I know what you mean. I am very sure this happens only if the jail do not have an own filesystem (so the jails root is not the root of a filesystem). Should be easy to fix. I will make an improved patch until tomorrow. bye, Juergen -- ENOSIG From owner-freebsd-hackers@FreeBSD.ORG Tue May 17 22:45:34 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A71CF16A4CE for ; Tue, 17 May 2005 22:45:34 +0000 (GMT) Received: from crow.addict.de (raven.addict.de [80.86.187.141]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79FC243D79 for ; Tue, 17 May 2005 22:45:33 +0000 (GMT) (envelope-from j.unger@addict.de) Received: from crow.addict.de (raven.addict.de [80.86.187.141]) by crow.addict.de (8.12.9/8.12.6) with ESMTP id j4HMjT3H007051; Wed, 18 May 2005 00:45:29 +0200 (CEST) (envelope-from j.unger@addict.de) Received: (from unger@localhost) by crow.addict.de (8.12.9/8.12.6/Submit) id j4HMjTom007050; Wed, 18 May 2005 00:45:29 +0200 (CEST) X-Authentication-Warning: crow.addict.de: unger set sender to j.unger@addict.de using -f Date: Wed, 18 May 2005 00:45:29 +0200 From: Juergen Unger To: Jeremie Le Hen Message-ID: <20050517224529.GB85134@crow.addict.de> References: <20050516162456.GC69167@crow.addict.de> <20050517214324.GA1021@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050517214324.GA1021@obiwan.tataz.chchile.org> User-Agent: Mutt/1.4i cc: freebsd-hackers@freebsd.org Subject: Re: jails and output of df/mount [PATCH] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2005 22:45:34 -0000 On Tue, May 17, 2005 at 11:43:24PM +0200, Jeremie Le Hen wrote: [...] > There seems to be one small bug in your patch : once applied, we > don't see informations about / any longer inside jails. please try the new one at bye, Juergen -- ENOSIG From owner-freebsd-hackers@FreeBSD.ORG Tue May 17 20:34:30 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A202D16A4CE for ; Tue, 17 May 2005 20:34:30 +0000 (GMT) Received: from post-23.mail.nl.demon.net (post-23.mail.nl.demon.net [194.159.73.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 258DD43DB3 for ; Tue, 17 May 2005 20:34:29 +0000 (GMT) (envelope-from hansot@iae.nl) Received: from beasties.demon.nl ([82.161.3.114]:4654 helo=[192.168.0.2]) by post-23.mail.nl.demon.net with esmtp (Exim 4.43) id 1DY8lk-000CyX-31; Tue, 17 May 2005 20:34:24 +0000 Message-ID: <428A554F.8010203@iae.nl> Date: Tue, 17 May 2005 22:34:23 +0200 From: Hans Ottevanger User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.6) Gecko/20050328 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Amandeep References: <427FA802.90805@chamkila.org> <427FA8CD.8040405@centtech.com> <427FAB5F.6070508@chamkila.org> In-Reply-To: <427FAB5F.6070508@chamkila.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 18 May 2005 12:39:55 +0000 cc: freebsd-hackers@freebsd.org Subject: Re: Low HDD tranfer rate with FreeBSD 5.3-Release X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2005 20:34:30 -0000 Amandeep wrote: [... dmesg snipped ...] > A > Eric Anderson wrote: > >> Amandeep wrote: >> >>> Hi all, >>> >>> I am using Tyan S2098 MB with 160GB Maxtor ATA Drive and the >>> transfer rate is very low. FreeBSD 5.3-Release. >>> Any ideas what is going on here. >>> >>> The transfer rate is about 15MB/s >>> >>> when I run >>> #dd if=/dev/zero of=/usr/junk bs=8192 >>> >>> then do >>> #iostat 1 >> >> >> >> You should probably provide the appropriate information from dmesg >> output, along with what you expect it to be, and the outputs of the >> dd command. >> >> Eric >> >> >> > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" > Hi, I had practically the same problem, i.e. the same very low ATA write speed, with very similar hardware (ASUS P533-E, same chipset and CPU as yours). This occurred with both 5.3-STABLE and 5.4-STABLE. I found that the problem disappears when I disable atapi_dma in the loader (or with 5.4, do not enable it). Alternatively, I can use "atacontrol mode 0 UDMA100" to force the ATA channel for the harddisk to UDMA100. I do not know why this works though, I still need some closer investigation. Something weird in the ATA driver must be going on. Anyhow, my HDD (WD-1200JB) is up-to-speed now, -45Mbytes/s reading AND writing. Kind regards, Hans From owner-freebsd-hackers@FreeBSD.ORG Wed May 18 12:48:36 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A5AB016A4CE for ; Wed, 18 May 2005 12:48:36 +0000 (GMT) Received: from mail.trident-uk.co.uk (mail.trident-uk.co.uk [194.221.74.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32E9C43D64 for ; Wed, 18 May 2005 12:48:36 +0000 (GMT) (envelope-from sparc@mail.trident-uk.co.uk) Received: from localhost (localhost.trident-uk.co.uk [127.0.0.1]) by mail.trident-uk.co.uk (Postfix) with ESMTP id 9ADAA82934; Wed, 18 May 2005 13:48:29 +0100 (BST) Received: from mail.trident-uk.co.uk ([127.0.0.1]) by localhost (cobain.trident-uk.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34662-04; Wed, 18 May 2005 13:48:29 +0100 (BST) Received: from m0ng.noc.trident-uk.co.uk (m0ng.noc.trident-uk.co.uk [192.168.122.20]) by mail.trident-uk.co.uk (Postfix) with ESMTP id E018182931; Wed, 18 May 2005 13:48:28 +0100 (BST) Received: by m0ng.noc.trident-uk.co.uk (Postfix, from userid 1001) id 8A71F6604; Wed, 18 May 2005 13:48:31 +0100 (BST) Date: Wed, 18 May 2005 13:48:31 +0100 From: Jamie Heckford To: Hans Ottevanger Message-ID: <20050518124831.GA11500@nipples.trident-uk.co.uk> References: <427FA802.90805@chamkila.org> <427FA8CD.8040405@centtech.com> <427FAB5F.6070508@chamkila.org> <428A554F.8010203@iae.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <428A554F.8010203@iae.nl> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at trident-uk.co.uk cc: freebsd-hackers@freebsd.org cc: Amandeep Subject: Re: Low HDD tranfer rate with FreeBSD 5.3-Release X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: jamie@tridentmicrosystems.co.uk List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2005 12:48:36 -0000 On Tue, May 17, 2005 at 10:34:23PM +0200, Hans Ottevanger wrote: > Amandeep wrote: > > [... dmesg snipped ...] > > >A > >Eric Anderson wrote: > > > >>Amandeep wrote: > >> > >>>Hi all, > >>> > >>>I am using Tyan S2098 MB with 160GB Maxtor ATA Drive and the > >>>transfer rate is very low. FreeBSD 5.3-Release. > >>>Any ideas what is going on here. > >>> > >>>The transfer rate is about 15MB/s > >>> > >>>when I run > >>>#dd if=/dev/zero of=/usr/junk bs=8192 > >>> > >>>then do > >>>#iostat 1 > >> > > > Hi, > > I had practically the same problem, i.e. the same very low ATA write > speed, with very similar hardware (ASUS P533-E, same chipset and CPU as > yours). This occurred with both 5.3-STABLE and 5.4-STABLE. > > I found that the problem disappears when I disable atapi_dma in the > loader (or with 5.4, do not enable it). Alternatively, I can use > "atacontrol mode 0 UDMA100" to force the ATA channel for the harddisk to > UDMA100. I do not know why this works though, I still need some closer > investigation. Something weird in the ATA driver must be going on. > > Anyhow, my HDD (WD-1200JB) is up-to-speed now, -45Mbytes/s reading AND > writing. > Same here, along with the random crashes around the time periodic runs which was posted the other day. We are getting all these problems with 5.4-R with the ATA mkIII patches applied also. Will test the atacontrol command and see what happens! -- Jamie Heckford Network Manager Trident Microsystems Ltd. t: +44(0)1737-780790 f: +44(0)1737-771908 w: http://www.tridentmicrosystems.co.uk/ From owner-freebsd-hackers@FreeBSD.ORG Wed May 18 12:58:53 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0657A16A4CE for ; Wed, 18 May 2005 12:58:53 +0000 (GMT) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4EEAA43D9E for ; Wed, 18 May 2005 12:58:50 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (localhost [127.0.0.1]) (authenticated bits=0) by cain.gsoft.com.au (8.12.11/8.12.10) with ESMTP id j4ICwefO010247; Wed, 18 May 2005 22:28:41 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-hackers@freebsd.org Date: Wed, 18 May 2005 22:28:29 +0930 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3026544.jCSc6LQu3e"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200505182228.36877.doconnor@gsoft.com.au> X-Spam-Score: -0.4 () PGP_SIGNATURE_2,SPAM_PHRASE_00_01,USER_AGENT X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) Subject: pam_ssh problems X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2005 12:58:53 -0000 --nextPart3026544.jCSc6LQu3e Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I have used pam_ssh before, and I have the following in /etc/pam.d/system :- # auth auth sufficient pam_opie.so no_warn no_fake_pro= mpts auth requisite pam_opieaccess.so no_warn allow_local #auth sufficient pam_krb5.so no_warn try_first_p= ass #auth sufficient pam_ldap.so no_warn try_first_p= ass auth sufficient pam_ssh.so no_warn try_first_p= ass auth required pam_unix.so no_warn try_first_p= ass nullok (ie what the committed version suggests). Just recently (last week or so) I have noticed that pam_ssh will let me=20 login with _any_ password (empty, or just plain wrong)! :( If I get the passphrase wrong I login, but the key is not added to the agent (at least something is right :) It didn't used to do this however.. I just found that I had made a id_rsa file for testing purposes with no=20 passphrase on it. While that was a little dumb it seems very odd that pam_ssh would let me in with any password - I think it would make more sense to reject keys with no passphrase for authenitcation (with say a nullok option). I think I'll work on a patch. Basically this is a heads up for anyone else that uses pam_ssh to be a bit careful :) =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart3026544.jCSc6LQu3e Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCizv85ZPcIHs/zowRAsshAJ4pkN3pLo00AqT3SbQnX0NW9cys1wCgiJQq 7Dwm9EJ0BmKvi7VAsGL+HpU= =cFev -----END PGP SIGNATURE----- --nextPart3026544.jCSc6LQu3e-- From owner-freebsd-hackers@FreeBSD.ORG Wed May 18 13:06:42 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C490316A4CE for ; Wed, 18 May 2005 13:06:42 +0000 (GMT) Received: from 62-15-210-213.inversas.jazztel.es (62-15-210-213.inversas.jazztel.es [62.15.210.213]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D26243D9D for ; Wed, 18 May 2005 13:06:41 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from redesjm.local (orion.redesjm.local [192.168.254.16]) j4ID6Rqg011141; Wed, 18 May 2005 15:06:27 +0200 (CEST) (envelope-from josemi@freebsd.jazztel.es) Received: from localhost (localhost [[UNIX: localhost]]) by redesjm.local (8.13.3/8.13.3/Submit) id j4ID6LAk001221; Wed, 18 May 2005 15:06:21 +0200 (CEST) (envelope-from josemi@freebsd.jazztel.es) X-Authentication-Warning: orion.redesjm.local: josemi set sender to josemi@freebsd.jazztel.es using -f From: Jose M Rodriguez Organization: Redes JM To: freebsd-hackers@freebsd.org Date: Wed, 18 May 2005 15:06:20 +0200 User-Agent: KMail/1.8 References: <200505182228.36877.doconnor@gsoft.com.au> In-Reply-To: <200505182228.36877.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-13" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200505181506.21129.josemi@freebsd.jazztel.es> X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-3; AVE: 6.30.0.12; VDF: 6.30.0.183; host: antares.redesjm.local) Subject: Re: pam_ssh problems X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2005 13:06:42 -0000 El Mi=E9rcoles, 18 de Mayo de 2005 14:58, Daniel O'Connor escribi=F3: > I have used pam_ssh before, and I have the following in > /etc/pam.d/system :- # auth > auth sufficient pam_opie.so no_warn > no_fake_prompts auth requisite pam_opieaccess.so =20 > no_warn allow_local #auth sufficient pam_krb5.so =20 > no_warn try_first_pass #auth sufficient =20 > pam_ldap.so no_warn try_first_pass auth =20 > sufficient pam_ssh.so no_warn try_first_pass auth =20 > required pam_unix.so no_warn > try_first_pass nullok > > (ie what the committed version suggests). > > Just recently (last week or so) I have noticed that pam_ssh will let > me login with _any_ password (empty, or just plain wrong)! :( > > If I get the passphrase wrong I login, but the key is not added to > the agent (at least something is right :) It didn't used to do this > however.. > > I just found that I had made a id_rsa file for testing purposes with > no passphrase on it. While that was a little dumb it seems very odd > that pam_ssh would let me in with any password - I think it would > make more sense to reject keys with no passphrase for authenitcation > (with say a nullok option). > > I think I'll work on a patch. > > Basically this is a heads up for anyone else that uses pam_ssh to be > a bit careful :) I use this, but not for login/auth, only for get the agent running with=20 the keys decripted (same passwd used). =2D- josemi =2D-- /etc/pam.d/login --- # # $FreeBSD: src/etc/pam.d/login,v 1.16 2003/06/14 12:35:05 des Exp $ # # PAM configuration for the "login" service # # auth auth required pam_nologin.so no_warn auth sufficient pam_self.so no_warn auth include system auth optional pam_ssh.so use_first_pass # account account requisite pam_securetty.so account include system # session session include system session optional pam_ssh.so want_agent # password password include system From owner-freebsd-hackers@FreeBSD.ORG Wed May 18 15:03:18 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2247C16A4FB; Wed, 18 May 2005 15:03:18 +0000 (GMT) Received: from mail.trident-uk.co.uk (mail.trident-uk.co.uk [194.221.74.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 332D443D5E; Wed, 18 May 2005 15:03:17 +0000 (GMT) (envelope-from sparc@mail.trident-uk.co.uk) Received: from localhost (localhost.trident-uk.co.uk [127.0.0.1]) by mail.trident-uk.co.uk (Postfix) with ESMTP id 400A98293F; Wed, 18 May 2005 16:03:14 +0100 (BST) Received: from mail.trident-uk.co.uk ([127.0.0.1]) by localhost (cobain.trident-uk.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42317-06; Wed, 18 May 2005 16:03:14 +0100 (BST) Received: from m0ng.noc.trident-uk.co.uk (m0ng.noc.trident-uk.co.uk [192.168.122.20]) by mail.trident-uk.co.uk (Postfix) with ESMTP id 7FA258293B; Wed, 18 May 2005 16:03:13 +0100 (BST) Received: by m0ng.noc.trident-uk.co.uk (Postfix, from userid 1001) id 6B5F66604; Wed, 18 May 2005 16:03:16 +0100 (BST) Date: Wed, 18 May 2005 16:03:16 +0100 From: Jamie Heckford To: Elliot Finley Message-ID: <20050518150316.GA11987@nipples.trident-uk.co.uk> References: <001801c55a14$609720d0$37cba1cd@emerytelcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001801c55a14$609720d0$37cba1cd@emerytelcom.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at trident-uk.co.uk cc: freebsd-hackers@freebsd.org cc: freebsd-stable@freebsd.org cc: sos@freebsd.org Subject: Re: 5.4-RC2 freezing - ATA related? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: jamie@tridentmicrosystems.co.uk List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2005 15:03:18 -0000 On Mon, May 16, 2005 at 06:40:01AM -0600, Elliot Finley wrote: > This has been happening since 5.3-R, I've been tuning different parameters > to no avail. I've taken the disks off of the onboard ICH5 controller and > put them a promise TX4 S150 controller, but still the same thing happens. > > The system freezes, but isn't totally dead. It'll still respond to pings, > the screensaver still functions, but it won't respond to a CAD at the > console. But if I press 'Enter' at the console, it'll give me a 'login:' > prompt, but after entering the username, it never comes back with the > 'password:' prompt. > > After manually resetting the system it boots and says 'Automatic file system > check failed; help!' and drops into single user mode. Running fsck manually > corrects errors on all volumes. Then it'll boot from that point. > > This seems to be triggered by daily periodic as it happens at 3:02-3:03AM > each time. But it doesn't happen *every* morning. > > I suspect a bug in FreeBSD because this mode of failure happens on 3 > different machines, all configured similarly. > > ASUS P4P800 > 2G RAM (though the other affected systems only have 1G) > 80G Seagate Barracuda SATA drives (one system now on Promise TX4 S150 > controller, others on onboard ICH5) > > On my lightly loaded systems, it happens rarely. On my mailserver (fairly > heavy disk load), it happens quite frequently. > > How can I troubleshoot this? Managed to get a dump on our system for a similar prob we are getting: [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". #0 doadump () at pcpu.h:160 160 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:160 #1 0xc05131ae in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:410 #2 0xc0513474 in panic (fmt=0xc06c3da5 "%s") at /usr/src/sys/kern/kern_shutdown.c:566 #3 0xc0691e18 in trap_fatal (frame=0xecb4bb34, eva=532) at /usr/src/sys/i386/i386/trap.c:817 #4 0xc0691b73 in trap_pfault (frame=0xecb4bb34, usermode=0, eva=532) at /usr/src/sys/i386/i386/trap.c:735 #5 0xc0691771 in trap (frame= {tf_fs = -1068433384, tf_es = -989790192, tf_ds = 16, tf_edi = -1066124736, tf_esi = -1066124736, tf_ebp = -323699844, tf_isp = -323699872, tf_ebx = -1007063716, tf_edx = 528, tf_ecx = -1013235680, tf_eax = 307472464, tf_trapno = 12, tf_err = 2, tf_eip = -1067870386, tf_cs = 8, tf_eflags = 66050, tf_esp = -989760240, tf_ss = -1007063716}) at /usr/src/sys/i386/i386/trap.c:425 #6 0xc068168a in calltrap () at /usr/src/sys/i386/i386/exception.s:140 #7 0xc0510018 in crcopy () at /usr/src/sys/kern/kern_prot.c:1810 #8 0xc0598c77 in in_pcbdetach (inp=0xc0743a40) at /usr/src/sys/netinet/in_pcb.c:720 #9 0xc05b21a6 in tcp_close (tp=0x0) at /usr/src/sys/netinet/tcp_subr.c:783 #10 0xc05ae560 in tcp_input (m=0xc3a6a300, off0=20) at /usr/src/sys/netinet/tcp_input.c:2308 #11 0xc05a5aed in ip_input (m=0xc3a6a300) at /usr/src/sys/netinet/ip_input.c:776 #12 0xc0582f13 in netisr_processqueue (ni=0xc0742498) at /usr/src/sys/net/netisr.c:233 #13 0xc058310a in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:346 #14 0xc04ffa79 in ithread_loop (arg=0xc3481600) at /usr/src/sys/kern/kern_intr.c:547 #15 0xc04fed0c in fork_exit (callout=0xc04ff928 , arg=0xc3481600, frame=0xecb4bd38) at /usr/src/sys/kern/kern_fork.c:791 #16 0xc06816ec in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:209 (kgdb) Help? ;) -- Jamie Heckford Network Manager Trident Microsystems Ltd. t: +44(0)1737-780790 f: +44(0)1737-771908 w: http://www.tridentmicrosystems.co.uk/ From owner-freebsd-hackers@FreeBSD.ORG Wed May 18 15:43:38 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 40C8716A4CE; Wed, 18 May 2005 15:43:38 +0000 (GMT) Received: from swip.net (mailfe04.swip.net [212.247.154.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01F4343D45; Wed, 18 May 2005 15:43:37 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: Y1QAsIk9O44SO+J/q9KNyQ== Received: from mp-217-208-180.daxnet.no ([193.217.208.180] verified) by mailfe04.swip.net (CommuniGate Pro SMTP 4.3c5) with ESMTP id 369636873; Wed, 18 May 2005 17:43:31 +0200 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org, jamie@tridentmicrosystems.co.uk Date: Wed, 18 May 2005 17:44:17 +0200 User-Agent: KMail/1.7 References: <001801c55a14$609720d0$37cba1cd@emerytelcom.com> <20050518150316.GA11987@nipples.trident-uk.co.uk> In-Reply-To: <20050518150316.GA11987@nipples.trident-uk.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505181744.19116.hselasky@c2i.net> cc: Elliot Finley cc: freebsd-stable@freebsd.org cc: sos@freebsd.org Subject: Re: 5.4-RC2 freezing - ATA related? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: hselasky@c2i.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2005 15:43:38 -0000 On Wednesday 18 May 2005 17:03, Jamie Heckford wrote: > On Mon, May 16, 2005 at 06:40:01AM -0600, Elliot Finley wrote: > > This has been happening since 5.3-R, I've been tuning different > > parameters to no avail. I've taken the disks off of the onboard ICH5 > > controller and put them a promise TX4 S150 controller, but still the same > > thing happens. > > > > The system freezes, but isn't totally dead. It'll still respond to > > pings, the screensaver still functions, but it won't respond to a CAD at > > the console. But if I press 'Enter' at the console, it'll give me a > > 'login:' prompt, but after entering the username, it never comes back > > with the 'password:' prompt. > > > > After manually resetting the system it boots and says 'Automatic file > > system check failed; help!' and drops into single user mode. Running > > fsck manually corrects errors on all volumes. Then it'll boot from that > > point. > > > > This seems to be triggered by daily periodic as it happens at 3:02-3:03AM > > each time. But it doesn't happen *every* morning. > > > > I suspect a bug in FreeBSD because this mode of failure happens on 3 > > different machines, all configured similarly. > > > > ASUS P4P800 > > 2G RAM (though the other affected systems only have 1G) > > 80G Seagate Barracuda SATA drives (one system now on Promise TX4 S150 > > controller, others on onboard ICH5) > > > > On my lightly loaded systems, it happens rarely. On my mailserver > > (fairly heavy disk load), it happens quite frequently. > > > > How can I troubleshoot this? > > > Help? ;) There is a bug in "machine/bus.h" (was: "machine/bus_at386.h") that might cause random freezes, but I'm not sure if it is related: http://www.freebsd.org/cgi/query-pr.cgi?pr=80980 --HPS From owner-freebsd-hackers@FreeBSD.ORG Wed May 18 19:53:23 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 91EA116A4CE; Wed, 18 May 2005 19:53:23 +0000 (GMT) Received: from mail13.syd.optusnet.com.au (mail13.syd.optusnet.com.au [211.29.132.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id D2A0943DB8; Wed, 18 May 2005 19:53:22 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j4IJrDE8020012 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 19 May 2005 05:53:14 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j4IJrDRx003239; Thu, 19 May 2005 05:53:13 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j4IJrC0E003238; Thu, 19 May 2005 05:53:12 +1000 (EST) (envelope-from pjeremy) Date: Thu, 19 May 2005 05:53:12 +1000 From: Peter Jeremy To: Jamie Heckford Message-ID: <20050518195312.GB2129@cirb503493.alcatel.com.au> References: <001801c55a14$609720d0$37cba1cd@emerytelcom.com> <20050518150316.GA11987@nipples.trident-uk.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050518150316.GA11987@nipples.trident-uk.co.uk> User-Agent: Mutt/1.4.2i cc: freebsd-hackers@freebsd.org cc: freebsd-stable@freebsd.org Subject: Re: 5.4-RC2 freezing - ATA related? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2005 19:53:23 -0000 On Wed, 2005-May-18 16:03:16 +0100, Jamie Heckford wrote: >Managed to get a dump on our system for a similar prob we are getting: That traceback looks like a panic, not a deadlock. What was the panic message? >#2 0xc0513474 in panic (fmt=0xc06c3da5 "%s") at /usr/src/sys/kern/kern_shutdown.c:566 ... >#7 0xc0510018 in crcopy () at /usr/src/sys/kern/kern_prot.c:1810 >#8 0xc0598c77 in in_pcbdetach (inp=0xc0743a40) at /usr/src/sys/netinet/in_pcb.c:720 >#9 0xc05b21a6 in tcp_close (tp=0x0) at /usr/src/sys/netinet/tcp_subr.c:783 There's something wrong here: If tcp_close() is passed NULL it will panic at this point when it tries to dereference tp. >#10 0xc05ae560 in tcp_input (m=0xc3a6a300, off0=20) at /usr/src/sys/netinet/tcp_input.c:2308 >#11 0xc05a5aed in ip_input (m=0xc3a6a300) at /usr/src/sys/netinet/ip_input.c:776 >#12 0xc0582f13 in netisr_processqueue (ni=0xc0742498) at /usr/src/sys/net/netisr.c:233 >#13 0xc058310a in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:346 -- Peter Jeremy From owner-freebsd-hackers@FreeBSD.ORG Wed May 18 22:29:39 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A27F716A4CE; Wed, 18 May 2005 22:29:39 +0000 (GMT) Received: from mail.trident-uk.co.uk (mail.trident-uk.co.uk [194.221.74.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3155043D76; Wed, 18 May 2005 22:29:39 +0000 (GMT) (envelope-from sparc@mail.trident-uk.co.uk) Received: from localhost (localhost.trident-uk.co.uk [127.0.0.1]) by mail.trident-uk.co.uk (Postfix) with ESMTP id B2B1082919; Wed, 18 May 2005 23:29:34 +0100 (BST) Received: from mail.trident-uk.co.uk ([127.0.0.1]) by localhost (cobain.trident-uk.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60754-01; Wed, 18 May 2005 23:29:34 +0100 (BST) Received: from m0ng.noc.trident-uk.co.uk (m0ng.noc.trident-uk.co.uk [192.168.122.20]) by mail.trident-uk.co.uk (Postfix) with ESMTP id 12927828EE; Wed, 18 May 2005 23:29:34 +0100 (BST) Received: by m0ng.noc.trident-uk.co.uk (Postfix, from userid 1001) id DA7EE6604; Wed, 18 May 2005 23:29:37 +0100 (BST) Date: Wed, 18 May 2005 23:29:37 +0100 From: Jamie Heckford To: Peter Jeremy Message-ID: <20050518222937.GA13356@nipples.trident-uk.co.uk> References: <001801c55a14$609720d0$37cba1cd@emerytelcom.com> <20050518150316.GA11987@nipples.trident-uk.co.uk> <20050518195312.GB2129@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050518195312.GB2129@cirb503493.alcatel.com.au> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at trident-uk.co.uk cc: freebsd-hackers@freebsd.org cc: freebsd-stable@freebsd.org cc: Jamie Heckford Subject: Re: 5.4-RC2 freezing - ATA related? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: jamie@tridentmicrosystems.co.uk List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2005 22:29:39 -0000 Hi Peter, On Thu, May 19, 2005 at 05:53:12AM +1000, Peter Jeremy wrote: > On Wed, 2005-May-18 16:03:16 +0100, Jamie Heckford wrote: > >Managed to get a dump on our system for a similar prob we are getting: > > That traceback looks like a panic, not a deadlock. What was the panic > message? Only have remote access to the box im afraid, is there anyway I can obtain the panic message? > > >#2 0xc0513474 in panic (fmt=0xc06c3da5 "%s") at /usr/src/sys/kern/kern_shutdown.c:566 > ... > >#7 0xc0510018 in crcopy () at /usr/src/sys/kern/kern_prot.c:1810 > >#8 0xc0598c77 in in_pcbdetach (inp=0xc0743a40) at /usr/src/sys/netinet/in_pcb.c:720 > >#9 0xc05b21a6 in tcp_close (tp=0x0) at /usr/src/sys/netinet/tcp_subr.c:783 > > There's something wrong here: If tcp_close() is passed NULL it will panic > at this point when it tries to dereference tp. Starting to stretch my knowledge a bit now ;) If I can provide you with further debug output would you be able to give me some pointers? Thanks for your help -- Jamie Heckford Network Manager Trident Microsystems Ltd. t: +44(0)1737-780790 f: +44(0)1737-771908 w: http://www.tridentmicrosystems.co.uk/ From owner-freebsd-hackers@FreeBSD.ORG Wed May 18 23:15:45 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF94B16A4CE; Wed, 18 May 2005 23:15:45 +0000 (GMT) Received: from mail.trident-uk.co.uk (mail.trident-uk.co.uk [194.221.74.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id D42AE43D1D; Wed, 18 May 2005 23:15:44 +0000 (GMT) (envelope-from sparc@mail.trident-uk.co.uk) Received: from localhost (localhost.trident-uk.co.uk [127.0.0.1]) by mail.trident-uk.co.uk (Postfix) with ESMTP id 59ED782923; Thu, 19 May 2005 00:15:41 +0100 (BST) Received: from mail.trident-uk.co.uk ([127.0.0.1]) by localhost (cobain.trident-uk.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62589-05; Thu, 19 May 2005 00:15:41 +0100 (BST) Received: from m0ng.noc.trident-uk.co.uk (m0ng.noc.trident-uk.co.uk [192.168.122.20]) by mail.trident-uk.co.uk (Postfix) with ESMTP id F1B0A82921; Thu, 19 May 2005 00:15:40 +0100 (BST) Received: by m0ng.noc.trident-uk.co.uk (Postfix, from userid 1001) id DB6426604; Thu, 19 May 2005 00:15:44 +0100 (BST) Date: Thu, 19 May 2005 00:15:44 +0100 From: Jamie Heckford To: Doug White Message-ID: <20050518231544.GA13555@nipples.trident-uk.co.uk> References: <001801c55a14$609720d0$37cba1cd@emerytelcom.com> <20050518150316.GA11987@nipples.trident-uk.co.uk> <20050518195312.GB2129@cirb503493.alcatel.com.au> <20050518222937.GA13356@nipples.trident-uk.co.uk> <20050518155452.M87264@carver.gumbysoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050518155452.M87264@carver.gumbysoft.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at trident-uk.co.uk cc: Peter Jeremy cc: freebsd-stable@freebsd.org cc: Jamie Heckford cc: freebsd-hackers@freebsd.org Subject: Re: 5.4-RC2 freezing - ATA related? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: jamie@tridentmicrosystems.co.uk List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2005 23:15:46 -0000 On Wed, May 18, 2005 at 03:54:59PM -0700, Doug White wrote: > On Wed, 18 May 2005, Jamie Heckford wrote: > > > Hi Peter, > > > > On Thu, May 19, 2005 at 05:53:12AM +1000, Peter Jeremy wrote: > > > On Wed, 2005-May-18 16:03:16 +0100, Jamie Heckford wrote: > > > >Managed to get a dump on our system for a similar prob we are getting: > > > > > > That traceback looks like a panic, not a deadlock. What was the panic > > > message? > > > > Only have remote access to the box im afraid, is there anyway I can obtain > > the panic message? > > "print msgbuf" should do it (kgdb) printf "%s", (char *)msgbufp->msg_ptr Fatal trap 12: page fault while in kernel mode fault virtual address = 0x214 fault code = supervisor write, page not present instruction pointer = 0x8:0xc059974e stack pointer = 0x10:0xecb4bb74 frame pointer = 0x10:0xecb4bb7c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 59 (swi1: net) trap number = 12 panic: page fault Uptime: 2h19m27s Dumping 2047 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 624 640 656 672 688 704 720 736 752 768 784 800 816 832 848 864 880 896 912 928 944 960 976 992 1008 1024 1040 1056 1072 1088 1104 1120 1136 1152 1168 1184 1200 1216 1232 1248 1264 1280 1296 1312 1328 1344 1360 1376 1392 1408 1424 1440 1456 1472 1488 1504 1520 1536 1552 1568 1584 1600 1616 1632 1648 1664 1680 1696 1712 1728 1744 1760 1776 1792 1808 1824 1840 1856 1872 1888 1904 1920 1936 1952 1968 1984 2000 2016 2032(kgdb) Thanks :) -- Jamie Heckford Network Manager Trident Microsystems Ltd. t: +44(0)1737-780790 f: +44(0)1737-771908 w: http://www.tridentmicrosystems.co.uk/ From owner-freebsd-hackers@FreeBSD.ORG Thu May 19 00:57:36 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4215E16A4CE for ; Thu, 19 May 2005 00:57:36 +0000 (GMT) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 36BCB43DA8 for ; Thu, 19 May 2005 00:57:35 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (localhost [127.0.0.1]) (authenticated bits=0) by cain.gsoft.com.au (8.12.11/8.12.10) with ESMTP id j4J0vUIb036073 for ; Thu, 19 May 2005 10:27:30 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-hackers@freebsd.org Date: Thu, 19 May 2005 10:27:13 +0930 User-Agent: KMail/1.8 References: <200505182228.36877.doconnor@gsoft.com.au> In-Reply-To: <200505182228.36877.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2402000.QN5AjmmSNy"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200505191027.24802.doconnor@gsoft.com.au> X-Spam-Score: -2.5 () IN_REP_TO,PGP_SIGNATURE_2,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) Subject: Re: pam_ssh problems X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2005 00:57:36 -0000 --nextPart2402000.QN5AjmmSNy Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wed, 18 May 2005 22:28, Daniel O'Connor wrote: > I think I'll work on a patch. > > Basically this is a heads up for anyone else that uses pam_ssh to be > a bit careful :) See bin/81231 for a patch. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart2402000.QN5AjmmSNy Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCi+R05ZPcIHs/zowRAsQWAJwIRU4vrgtx0K5d0+wD8f/c5GgPXwCfaokZ sbfSYR2iBTmO6uPMrN9vJrQ= =oLd8 -----END PGP SIGNATURE----- --nextPart2402000.QN5AjmmSNy-- From owner-freebsd-hackers@FreeBSD.ORG Thu May 19 05:56:57 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E19CA16A4CE for ; Thu, 19 May 2005 05:56:57 +0000 (GMT) Received: from cosmo.yahp.net (cosmo.yahp.net [64.167.104.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A61643DA7 for ; Thu, 19 May 2005 05:56:56 +0000 (GMT) (envelope-from ctodd@chrismiller.com) Received: from [64.167.104.186] (w300.yahp.net [64.167.104.186]) (authenticated bits=0) by cosmo.yahp.net (8.13.4/8.13.1) with ESMTP id j4J5upTX000266 for ; Wed, 18 May 2005 22:56:55 -0700 (PDT) (envelope-from ctodd@chrismiller.com) Message-ID: <428C2A77.9010202@chrismiller.com> Date: Wed, 18 May 2005 22:56:07 -0700 From: Chris Miller User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Sender: user ctodd from 64.167.104.186 X-Scanned-By: milter-sender/0.62.837 (cosmo.yahp.net [64.167.104.189]); Wed, 18 May 2005 22:56:55 -0700 Subject: Changes to reboot routine in 5.4? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2005 05:56:58 -0000 I've had a problem with a pair of ECS motherboards (VIA C3) that won't reboot without hitting the reset button. A "flash" is visible on the console, but it's not enough to cause the motherboard to reset. One system is running 4.11, the other 5.4, and through all the upgrades this has been a problem. That is until I upgraded the one from 5.3 to 5.4, and that one reboots fine. I didn't see anything in the release notes about changes in this area, does anyone have a clue as to what may have changed. If so, it would be great to get this ported into 4.11 if that's possible. CPU: VIA C3 Samuel 2 (801.82-MHz 686-class CPU) Origin = "CentaurHauls" Id = 0x673 Stepping = 3 Features=0x803035 Thanks, Chris From owner-freebsd-hackers@FreeBSD.ORG Thu May 19 06:30:18 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C721716A4CE for ; Thu, 19 May 2005 06:30:18 +0000 (GMT) Received: from mail27.sea5.speakeasy.net (mail27.sea5.speakeasy.net [69.17.117.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id B7FC143D90 for ; Thu, 19 May 2005 06:30:17 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 13221 invoked from network); 19 May 2005 06:30:14 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail27.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 19 May 2005 06:30:14 -0000 Received: from hydrogen.funkthat.com (rahsrq@localhost.funkthat.com [127.0.0.1])j4J6UD2g015964; Wed, 18 May 2005 23:30:13 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id j4J6UCbe015963; Wed, 18 May 2005 23:30:12 -0700 (PDT) Date: Wed, 18 May 2005 23:30:12 -0700 From: John-Mark Gurney To: =?iso-8859-1?Q?Herv=E9?= Kergourlay Message-ID: <20050519063012.GA959@funkthat.com> Mail-Followup-To: =?iso-8859-1?Q?Herv=E9?= Kergourlay , hackers@FreeBSD.org References: <428307A9.10901@atempo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <428307A9.10901@atempo.com> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: hackers@FreeBSD.org Subject: Re: Porting on FreeBSD 53 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2005 06:30:18 -0000 Hervé Kergourlay wrote this message on Thu, May 12, 2005 at 09:37 +0200: > what about files more than 4GB, do I need to use specific APIs as > open64, stat64 or the current open and stat API are managing the big file ? Nope... FreeBSD's off_t has been 64bits since 2.0... Just make sure you use the correct types when handling them... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Thu May 19 06:47:52 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 051B416A4CE for ; Thu, 19 May 2005 06:47:52 +0000 (GMT) Received: from ds9.atempo.com (ds9.atempo.com [212.157.146.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id 111AD43D7D for ; Thu, 19 May 2005 06:47:51 +0000 (GMT) (envelope-from herve.kergourlay@atempo.com) Received: from ds9.atempo.com (localhost.localdomain [127.0.0.1]) by localhost.atempo.com (Postfix) with ESMTP id 5F8112FD09; Thu, 19 May 2005 08:47:47 +0200 (CEST) Received: from atempo.com (unknown [172.16.15.140])by ds9.atempo.com (Postfix) with ESMTP id 523AD2FD06; Thu, 19 May 2005 08:47:47 +0200 (CEST) Received: from [192.168.2.108] (aragorn.vannes.quadratec.fr [192.168.2.108])by atempo.com (Postfix) with ESMTP id 13BB41E3493; Thu, 19 May 2005 08:47:47 +0200 (CEST) Message-ID: <428C3692.2000808@atempo.com> Date: Thu, 19 May 2005 08:47:46 +0200 From: =?ISO-8859-1?Q?Herv=E9_Kergourlay?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: fr, en MIME-Version: 1.0 To: John-Mark Gurney References: <428307A9.10901@atempo.com> <20050519063012.GA959@funkthat.com> In-Reply-To: <20050519063012.GA959@funkthat.com> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary=------------090608010600090801030007 X-imss-version: 2.025 X-imss-result: Passed X-imss-approveListMatch: *@atempo.com X-Content-Filtered-By: Mailman/MimeDel 2.1.1 cc: hackers@FreeBSD.org Subject: Re: Porting on FreeBSD 53 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2005 06:47:52 -0000 This is a multi-part message in MIME format. --------------090608010600090801030007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit John-Mark Gurney a écrit : >Hervé Kergourlay wrote this message on Thu, May 12, 2005 at 09:37 +0200: > > >>what about files more than 4GB, do I need to use specific APIs as >>open64, stat64 or the current open and stat API are managing the big file ? >> >> > >Nope... FreeBSD's off_t has been 64bits since 2.0... Just make sure >you use the correct types when handling them... > > > so the stat, lseek, lock apis are 64 bits ready :-) nice !! I will test it hervé --------------090608010600090801030007-- From owner-freebsd-hackers@FreeBSD.ORG Thu May 19 10:34:43 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B85416A4CF for ; Thu, 19 May 2005 10:34:43 +0000 (GMT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4918543DAA for ; Thu, 19 May 2005 10:34:42 +0000 (GMT) (envelope-from slawek.zak@gmail.com) Received: by zproxy.gmail.com with SMTP id 9so546953nzo for ; Thu, 19 May 2005 03:34:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=q8s6UwcdxA5FfK7r0ct/bhfLDLQHLX8g0P/6p5O2XZCbs0+35pTtjHkTTR5St9+x7yJvvnYA1CQSYwYWAZzA2zkxESWaS4s0eRTpU1bPKwMAhyhficE3Z0YWxss2/IUMP1zcUfLpYCQ1BbPlPRWpdBA+ToKYgbTCKbR8NaEzk6E= Received: by 10.36.34.1 with SMTP id h1mr392396nzh; Thu, 19 May 2005 03:34:38 -0700 (PDT) Received: by 10.36.88.12 with HTTP; Thu, 19 May 2005 03:34:38 -0700 (PDT) Message-ID: <787bbe1c05051903346376988b@mail.gmail.com> Date: Thu, 19 May 2005 12:34:38 +0200 From: =?ISO-8859-2?Q?S=B3awek_=AFak?= To: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: base64 Content-Disposition: inline Subject: Diskless boot problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: =?ISO-8859-2?Q?S=B3awek_=AFak?= List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2005 10:34:43 -0000 SGksCgpJIGhhdmUgYSBwcm9ibGVtIHdpdGggYm9vdGluZyBEZWxsIDI4NTAgb3ZlciBuZXR3b3Jr LiBUaGUgbWFjaGluZQpyZWFkcyBrZXJuZWwgb3ZlciBuZXQsIGJvb3RzIHVwdG8gbW91bnRpbmcg LyBmcm9tIE5GUyBhbmQgdGhlbgpjcmFzaGVzLgoKVGNwZHVtcCBvdXRwdXQ6CgoxMjoxNTo1OC45 MTk2ODMgYXJwIHdoby1oYXMgMTAuMTU4LjE5MC43MyB0ZWxsIDEwLjE1OC4xOTAuNzQKMTI6MTU6 NTguOTE5NzAyIGFycCByZXBseSAxMC4xNTguMTkwLjczIGlzLWF0IDAwOjExOjQzOmQzOjZlOmUx CjEyOjE1OjU4LjkyMDA1OCBJUCAxMC4xNTguMTkwLjc0LjQ3NTIwOTE3NiA+IDEwLjE1OC4xOTAu NzMuMjA0OTogOTIKZ2V0YXR0ciBbfG5mc10KMTI6MTU6NTguOTIwMTM0IElQIDEwLjE1OC4xOTAu NzMuMjA0OSA+IDEwLjE1OC4xOTAuNzQuNDc1MjA5MTc2OiByZXBseQpvayAyOCBnZXRhdHRyIEVS Uk9SOiBTdGFsZSBORlMgZmlsZSBoYW5kbGUKMTI6MTU6NTguOTIwNDMyIGFycCB3aG8taGFzIDEw LjE1OC4xOTAuNzMgdGVsbCAxMC4xNTguMTkwLjc0CjEyOjE1OjU4LjkyMDQ0MiBhcnAgcmVwbHkg MTAuMTU4LjE5MC43MyBpcy1hdCAwMDoxMTo0MzpkMzo2ZTplMQoxMjoxNTo1OC45MjA2ODEgSVAg MTAuMTU4LjE5MC43NC40NzUyMDkxNzcgPiAxMC4xNTguMTkwLjczLjIwNDk6IDEwMApsb29rdXAg W3xuZnNdCjEyOjE1OjU4LjkyMDcwNyBJUCAxMC4xNTguMTkwLjczLjIwNDkgPiAxMC4xNTguMTkw Ljc0LjQ3NTIwOTE3NzogcmVwbHkKb2sgMjggbG9va3VwIEVSUk9SOiBTdGFsZSBORlMgZmlsZSBo YW5kbGUKMTI6MTU6NTguOTIwOTMyIElQIDEwLjE1OC4xOTAuNzQuNDc1MjA5MTc4ID4gMTAuMTU4 LjE5MC43My4yMDQ5OiAxMDAKbG9va3VwIFt8bmZzXQoxMjoxNTo1OC45MjA5NjMgSVAgMTAuMTU4 LjE5MC43My4yMDQ5ID4gMTAuMTU4LjE5MC43NC40NzUyMDkxNzg6IHJlcGx5Cm9rIDI4IGxvb2t1 cCBFUlJPUjogU3RhbGUgTkZTIGZpbGUgaGFuZGxlCjEyOjE1OjU4Ljk1MjE4MCBJUCAxMC4xNTgu MTkwLjc0LjQ3NTIwOTE3OSA+IDEwLjE1OC4xOTAuNzMuMjA0OTogMTAwCmxvb2t1cCBbfG5mc10K MTI6MTU6NTguOTUyMjc3IElQIDEwLjE1OC4xOTAuNzMuMjA0OSA+IDEwLjE1OC4xOTAuNzQuNDc1 MjA5MTc5OiByZXBseQpvayAyOCBsb29rdXAgRVJST1I6IFN0YWxlIE5GUyBmaWxlIGhhbmRsZQox MjoxNTo1OC45ODQ3ODUgSVAgMTAuMTU4LjE5MC43NC40NzUyMDkxODAgPiAxMC4xNTguMTkwLjcz LjIwNDk6IDEwMApsb29rdXAgW3xuZnNdCjEyOjE1OjU4Ljk4NDg2NiBJUCAxMC4xNTguMTkwLjcz LjIwNDkgPiAxMC4xNTguMTkwLjc0LjQ3NTIwOTE4MDogcmVwbHkKb2sgMjggbG9va3VwIEVSUk9S OiBTdGFsZSBORlMgZmlsZSBoYW5kbGUKMTI6MTU6NTkuMDIwNTAwIElQIDEwLjE1OC4xOTAuNzQu NDc1MjA5MTgxID4gMTAuMTU4LjE5MC43My4yMDQ5OiAxMDQKbG9va3VwIFt8bmZzXQoxMjoxNTo1 OS4wMjA1NzMgSVAgMTAuMTU4LjE5MC43My4yMDQ5ID4gMTAuMTU4LjE5MC43NC40NzUyMDkxODE6 IHJlcGx5Cm9rIDI4IGxvb2t1cCBFUlJPUjogU3RhbGUgTkZTIGZpbGUgaGFuZGxlCjEyOjE1OjU5 LjA1NDEzMCBJUCAxMC4xNTguMTkwLjc0LjQ3NTIwOTE4MiA+IDEwLjE1OC4xOTAuNzMuMjA0OTog MTA0Cmxvb2t1cCBbfG5mc10KMTI6MTU6NTkuMDU0MjI0IElQIDEwLjE1OC4xOTAuNzMuMjA0OSA+ IDEwLjE1OC4xOTAuNzQuNDc1MjA5MTgyOiByZXBseQpvayAyOCBsb29rdXAgRVJST1I6IFN0YWxl IE5GUyBmaWxlIGhhbmRsZQoKSSB3b25kZXIgd2hlcmUgdGhlIGBTdGFsZSBORlMgaGFuZGxlJyAg ZXJyb3IgY29tZXMgZnJvbSwgYXMgdGhlIGNsaWVudApkb2Vzbid0IHNlZW0gdG8gaGF2ZSBtb3Vu dGVkIHRoZSBmaWxlc3lzdGVtIG92ZXIgTkZTIGZyb20gd2hhdCBJIGNhbgpzZWUuIE9uIHRoZSBj b25zb2xlIG9mIHRoZSBkaXNrbGVzcyBJIGhhdmUgdGhpczoKCk5GUyBST09UOiAxMC4xNTguMTkw LjczOi92YXIvd3d3L0ZyZWVCU0QtNS40LXg4Ni1QWEUKZW0wOiBMaW5rIGlzIHVwIDEwMCBNYnBz IEhhbGYgRHVwbGV4CmV4ZWMgL3NiaW4vaW5pdDogZXJyb3IgNzAKZXhlYyAvc2Jpbi9vaW5pdDog ZXJyb3IgNzAKZXhlYyAvc2Jpbi9pbml0LmJhazogZXJyb3IgNzAKZXhlYyAvcmVzY3VlL2luaXQ6 IGVycm9yIDcwCmV4ZWMgL3N0YW5kL3N5c2luc3RhbGw6IGVycm9yIDcwCmluaXQ6IG5vdCBmb3Vu ZCBpbiBwYXRoCi9zYmluL2luaXQ6L3NiaW4vb2luaXQ6L3NiaW4vaW5pdC5iYWs6L3Jlc2N1ZS9p bml0Oi9zdGFuZC9zeXNpbnN0YWxsCnBhbmljOiBubyBpbml0ClVwdGltZTogNTVzCkNhbm5vdCBk dW1wLiBObyBkdW1wIGRldmljZSBkZWZpbmVkLgpBdXRvbWF0aWMgcmVib290IGluIDE1IHNlY29u ZHMgLSBwcmVzcyBhIGtleSBvbiB0aGUgY29uc29sZSB0byBhYm9ydAoKVGhlIHNwZWVkIGZvciBl bTAgaXMgb2J2aW91c2x5IHdyb25nLiBTZXR0aW5nIG9uIHRoZSBzd2l0Y2ggaXMgMTAwCmZ1bGwt ZHVwbGV4LiBPdXIgbmV0d29yayB3aXphcmRzIGNhbiBmKioqa3VwIGF1dG9uZWdvdGlhdGlvbiBv biBDaXNjbwpDYXRhbHlzdCwgc28gaXQgbXVzdCBzdGF5IHRoYXQgd2F5LiBJbnRlbCBlbS1zIHRl bmQgdG8gaGFuZyBmb3IgYQpjb3VwbGUgb2Ygc2Vjb25kcyBiZWZvcmUgZ2V0dGluZyBvbiB0aGUg bmV0IHNvIGl0IG1pZ2h0IGJlIHRoZQpwcm9ibGVtLiBPbiB0aGUgb3RoZXIgaGFuZCBrZXJuZWwg bG9hZHMganVzdCBmaW5lIG92ZXIgVEZUUC4KCkFueSB0aG91Z2h0cz8KClRoYW5rcywgL1MKLS0g ClOzYXdlayCvYWsgLyBVTklYIFN5c3RlbXMgQWRtaW5pc3RyYXRvcgo= From owner-freebsd-hackers@FreeBSD.ORG Wed May 18 22:55:01 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 54DB116A4CE; Wed, 18 May 2005 22:55:01 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C55B43DA9; Wed, 18 May 2005 22:55:01 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 57AC372DD4; Wed, 18 May 2005 15:54:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 5251472DCB; Wed, 18 May 2005 15:54:59 -0700 (PDT) Date: Wed, 18 May 2005 15:54:59 -0700 (PDT) From: Doug White To: Jamie Heckford In-Reply-To: <20050518222937.GA13356@nipples.trident-uk.co.uk> Message-ID: <20050518155452.M87264@carver.gumbysoft.com> References: <001801c55a14$609720d0$37cba1cd@emerytelcom.com> <20050518150316.GA11987@nipples.trident-uk.co.uk> <20050518195312.GB2129@cirb503493.alcatel.com.au> <20050518222937.GA13356@nipples.trident-uk.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Thu, 19 May 2005 11:51:07 +0000 cc: Peter Jeremy cc: freebsd-stable@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: 5.4-RC2 freezing - ATA related? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2005 22:55:01 -0000 On Wed, 18 May 2005, Jamie Heckford wrote: > Hi Peter, > > On Thu, May 19, 2005 at 05:53:12AM +1000, Peter Jeremy wrote: > > On Wed, 2005-May-18 16:03:16 +0100, Jamie Heckford wrote: > > >Managed to get a dump on our system for a similar prob we are getting: > > > > That traceback looks like a panic, not a deadlock. What was the panic > > message? > > Only have remote access to the box im afraid, is there anyway I can obtain > the panic message? "print msgbuf" should do it > > > > > >#2 0xc0513474 in panic (fmt=0xc06c3da5 "%s") at /usr/src/sys/kern/kern_shutdown.c:566 > > ... > > >#7 0xc0510018 in crcopy () at /usr/src/sys/kern/kern_prot.c:1810 > > >#8 0xc0598c77 in in_pcbdetach (inp=0xc0743a40) at /usr/src/sys/netinet/in_pcb.c:720 > > >#9 0xc05b21a6 in tcp_close (tp=0x0) at /usr/src/sys/netinet/tcp_subr.c:783 > > > > There's something wrong here: If tcp_close() is passed NULL it will panic > > at this point when it tries to dereference tp. > > Starting to stretch my knowledge a bit now ;) > > If I can provide you with further debug output would you be able to give me some > pointers? > > Thanks for your help > > -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Thu May 19 12:11:46 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 14FBB16A4CE for ; Thu, 19 May 2005 12:11:46 +0000 (GMT) Received: from alice.et.bocholt.fh-gelsenkirchen.de (alice.et.bocholt.fh-gelsenkirchen.de [193.175.197.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id C832F43D9C for ; Thu, 19 May 2005 12:11:44 +0000 (GMT) (envelope-from gouders@et.bocholt.fh-gelsenkirchen.de) Received: from musashi.et.bocholt.fh-gelsenkirchen.de (musashi.et.bocholt.fh-gelsenkirchen.de [193.175.197.95]) j4JCBfOr032700 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 19 May 2005 14:11:42 +0200 Received: from karga.hank.home (karga.hank.home [192.168.252.2]) id j4JCBeph002054 for ; Thu, 19 May 2005 14:11:40 +0200 (CEST) (envelope-from hank@karga.hank.home) Received: from localhost (localhost [127.0.0.1]) by karga.hank.home (8.13.3/8.13.3) with ESMTP id j4JCD7pb000372 for ; Thu, 19 May 2005 14:13:07 +0200 (CEST) (envelope-from hank@karga.hank.home) Message-Id: <200505191213.j4JCD7pb000372@karga.hank.home> From: Dirk Gouders To: freebsd-hackers@freebsd.org Date: Thu, 19 May 2005 14:13:07 +0200 Sender: gouders@et.bocholt.fh-ge.de X-Scanned-By: MIMEDefang 2.43 Subject: page fault in ugenpoll() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Dirk Gouders List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2005 12:11:46 -0000 Hello, on a machine FreeBSD karga.hank.home 4.11-STABLE FreeBSD 4.11-STABLE #2: Thu May 19 12:32:50 CEST 2005 root@karga.hank.home:/usr/src/sys/compile/KARGA i386 I am playing with a Cryptoflex e-gate USB token and get kernel panics when invoking a program openct-control to access it: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x3 fault code = supervisor read, page not present instruction pointer = 0x8:0xc027177b stack pointer = 0x10:0xccde7d40 frame pointer = 0x10:0xccde7d50 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 173 (ifdhandler) interrupt mask = bio trap number = 12 panic: page fault The IP points to the following line in the function ugenpoll (line 1445 in ugen.c): switch (sce->edesc->bmAttributes & UE_XFERTYPE) Examining sce with gdb gives: (kgdb) print sce $1 = (struct ugen_endpoint *) 0x68c060 (kgdb) print sce->edesc Cannot access memory at address 0x68c064. (kgdb) The software that I am trying to use might be erroneous, but I am wondering that it causes kernel panics by accessing /dev/ugen0. Dirk From owner-freebsd-hackers@FreeBSD.ORG Fri May 20 00:27:58 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1D9416A4CE for ; Fri, 20 May 2005 00:27:58 +0000 (GMT) Received: from alice.et.bocholt.fh-gelsenkirchen.de (alice.et.bocholt.fh-gelsenkirchen.de [193.175.197.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2909743DBE for ; Fri, 20 May 2005 00:27:57 +0000 (GMT) (envelope-from gouders@et.bocholt.fh-gelsenkirchen.de) Received: from musashi.et.bocholt.fh-gelsenkirchen.de (musashi.et.bocholt.fh-gelsenkirchen.de [193.175.197.95]) j4K0RsOr002543 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 20 May 2005 02:27:54 +0200 Received: from karga.hank.home (karga.hank.home [192.168.252.2]) id j4K0RrBA003249 for ; Fri, 20 May 2005 02:27:53 +0200 (CEST) (envelope-from hank@karga.hank.home) Received: from localhost (localhost [127.0.0.1]) by karga.hank.home (8.13.3/8.13.3) with ESMTP id j4K0TJNb000312 for ; Fri, 20 May 2005 02:29:20 +0200 (CEST) (envelope-from hank@karga.hank.home) Message-Id: <200505200029.j4K0TJNb000312@karga.hank.home> To: freebsd-hackers@freebsd.org In-Reply-To: Message from Dirk Gouders <200505191213.j4JCD7pb000372@karga.hank.home> Date: Fri, 20 May 2005 02:29:19 +0200 From: Dirk GOUDERS X-Scanned-By: MIMEDefang 2.43 Subject: Re: page fault in ugenpoll() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2005 00:27:58 -0000 Hello, just for completeness, I want to provide a simple program that causes a kernel panic when invoked with the argument /dev/ugen0: #include #include #include #include #include #include int main(int argc, char *argv[]) { int fd; int nfd; char *path = argv[1]; struct pollfd pfd[1]; fd = open(path, O_RDWR); if ( fd < 0 ) { fprintf(stderr, "%s: %s\n", path, strerror(errno)); exit(1); } pfd[0].fd = fd; pfd[0].events = POLLHUP; pfd[0].revents = 0; nfd = poll(pfd, 1, 10); if ( nfd < 0 ) { fprintf(stderr, "poll(2): %s\n", strerror(errno)); exit(1); } printf("nfd = %d\n", nfd); close(fd); exit(0); } > Hello, > > on a machine > > FreeBSD karga.hank.home 4.11-STABLE FreeBSD 4.11-STABLE #2: Thu May 19 12:32 > :50 CEST 2005 root@karga.hank.home:/usr/src/sys/compile/KARGA i386 > > I am playing with a Cryptoflex e-gate USB token and get kernel > panics when invoking a program openct-control to access it: > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x3 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc027177b > stack pointer = 0x10:0xccde7d40 > frame pointer = 0x10:0xccde7d50 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 173 (ifdhandler) > interrupt mask = bio > trap number = 12 > panic: page fault > > The IP points to the following line in the function ugenpoll (line > 1445 in ugen.c): > > switch (sce->edesc->bmAttributes & UE_XFERTYPE) > > Examining sce with gdb gives: > (kgdb) print sce > $1 = (struct ugen_endpoint *) 0x68c060 > (kgdb) print sce->edesc > Cannot access memory at address 0x68c064. > (kgdb) > > The software that I am trying to use might be erroneous, but I am > wondering that it causes kernel panics by accessing /dev/ugen0. > > Dirk > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Fri May 20 03:23:17 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F41316A4CE for ; Fri, 20 May 2005 03:23:17 +0000 (GMT) Received: from smtp1.matrix.com.br (smtp1.matrix.com.br [200.196.28.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3FC943DA5 for ; Fri, 20 May 2005 03:23:15 +0000 (GMT) (envelope-from cargnini@cargnini.trix.net) Received: from portalbl1.matrix.net.br (unknown [200.201.192.31]) by smtp1.matrix.com.br (Postfix) with SMTP id EB2E4379E8 for ; Fri, 20 May 2005 00:23:12 -0300 (BRST) Received: (qmail 32053 invoked from network); 20 May 2005 03:23:12 -0000 Received: from unknown (HELO shark.hopto.org) (cargnini@cargnini.trix.net@[200.175.74.246]) (envelope-sender ) by portalbl1.matrix.net.br (qmail-ldap-1.03) with SMTP for ; 20 May 2005 03:23:12 -0000 From: =?ISO-8859-1?Q?Lu=EDs_Vit=F3rio?= Cargnini To: freebsd-hackers@freebsd.org Content-Type: text/plain Date: Fri, 20 May 2005 00:23:46 -0300 Message-Id: <1116559426.27848.7.camel@shark.hopto.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: PCI Device Driver X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2005 03:23:17 -0000 Hi i need to write a device driver for a PCI board. I read the developers book see the exemples and i'm starting to write the device driver. I'm writeing a device driver for a board with SAA713X TV chipset from Phillips. I did theskeleton example, but whe i catch the example of PCI driver from developers book and tried to compilate i receive the following: (forgive me for the long paste, but i need some answers and i need to give the details) PASTE of ERORS: @/sys/bus.h:455:23: device_if.h: No such file or directory @/sys/bus.h:456:20: bus_if.h: No such file or directory In file included from saa713x.c:23: @/dev/pci/pcivar.h:170:20: pci_if.h: No such file or directory In file included from saa713x.c:23: @/dev/pci/pcivar.h: In function `pci_get_subvendor': @/dev/pci/pcivar.h:203: warning: implicit declaration of function `BUS_READ_IVAR' @/dev/pci/pcivar.h:203: warning: nested extern declaration of `BUS_READ_IVAR' @/dev/pci/pcivar.h: In function `pci_set_subvendor': @/dev/pci/pcivar.h:203: warning: implicit declaration of function `BUS_WRITE_IVAR' @/dev/pci/pcivar.h:203: warning: nested extern declaration of `BUS_WRITE_IVAR' @/dev/pci/pcivar.h: In function `pci_get_subdevice': @/dev/pci/pcivar.h:204: warning: nested extern declaration of `BUS_READ_IVAR' @/dev/pci/pcivar.h:203: warning: redundant redeclaration of 'BUS_READ_IVAR' @/dev/pci/pcivar.h:203: warning: previous implicit declaration of 'BUS_READ_IVAR' was here @/dev/pci/pcivar.h: In function `pci_set_subdevice': @/dev/pci/pcivar.h:204: warning: nested extern declaration of `BUS_WRITE_IVAR' @/dev/pci/pcivar.h:203: warning: redundant redeclaration of 'BUS_WRITE_IVAR' @/dev/pci/pcivar.h:203: warning: previous implicit declaration of 'BUS_WRITE_IVAR' was here @/dev/pci/pcivar.h: In function `pci_get_vendor': @/dev/pci/pcivar.h:205: warning: nested extern declaration of `BUS_READ_IVAR' @/dev/pci/pcivar.h:203: warning: redundant redeclaration of 'BUS_READ_IVAR' @/dev/pci/pcivar.h:203: warning: previous implicit declaration of 'BUS_READ_IVAR' was here @/dev/pci/pcivar.h: In function `pci_set_vendor': @/dev/pci/pcivar.h:205: warning: nested extern declaration of `BUS_WRITE_IVAR' @/dev/pci/pcivar.h:203: warning: redundant redeclaration of 'BUS_WRITE_IVAR' @/dev/pci/pcivar.h:203: warning: previous implicit declaration of 'BUS_WRITE_IVAR' was here @/dev/pci/pcivar.h: In function `pci_get_device': @/dev/pci/pcivar.h:206: warning: nested extern declaration of `BUS_READ_IVAR' @/dev/pci/pcivar.h:203: warning: redundant redeclaration of 'BUS_READ_IVAR' @/dev/pci/pcivar.h:203: warning: previous implicit declaration of 'BUS_READ_IVAR' was here @/dev/pci/pcivar.h: In function `pci_set_device': @/dev/pci/pcivar.h:206: warning: nested extern declaration of `BUS_WRITE_IVAR' @/dev/pci/pcivar.h:203: warning: redundant redeclaration of 'BUS_WRITE_IVAR' @/dev/pci/pcivar.h:203: warning: previous implicit declaration of 'BUS_WRITE_IVAR' was here @/dev/pci/pcivar.h: In function `pci_get_devid': @/dev/pci/pcivar.h:207: warning: nested extern declaration of `BUS_READ_IVAR' @/dev/pci/pcivar.h:203: warning: redundant redeclaration of 'BUS_READ_IVAR' @/dev/pci/pcivar.h:203: warning: previous implicit declaration of 'BUS_READ_IVAR' was here @/dev/pci/pcivar.h: In function `pci_set_devid': @/dev/pci/pcivar.h:207: warning: nested extern declaration of `BUS_WRITE_IVAR' @/dev/pci/pcivar.h:203: warning: redundant redeclaration of 'BUS_WRITE_IVAR' @/dev/pci/pcivar.h:203: warning: previous implicit declaration of 'BUS_WRITE_IVAR' was here @/dev/pci/pcivar.h: In function `pci_get_class': @/dev/pci/pcivar.h:208: warning: nested extern declaration of `BUS_READ_IVAR' @/dev/pci/pcivar.h:203: warning: redundant redeclaration of 'BUS_READ_IVAR' @/dev/pci/pcivar.h:203: warning: previous implicit declaration of 'BUS_READ_IVAR' was here @/dev/pci/pcivar.h: In function `pci_set_class': @/dev/pci/pcivar.h:208: warning: nested extern declaration of `BUS_WRITE_IVAR' @/dev/pci/pcivar.h:203: warning: redundant redeclaration of 'BUS_WRITE_IVAR' @/dev/pci/pcivar.h:203: warning: previous implicit declaration of 'BUS_WRITE_IVAR' was here @/dev/pci/pcivar.h: In function `pci_get_subclass': @/dev/pci/pcivar.h:209: warning: nested extern declaration of `BUS_READ_IVAR' @/dev/pci/pcivar.h:203: warning: redundant redeclaration of 'BUS_READ_IVAR' @/dev/pci/pcivar.h:203: warning: previous implicit declaration of 'BUS_READ_IVAR' was here @/dev/pci/pcivar.h: In function `pci_set_subclass': @/dev/pci/pcivar.h:209: warning: nested extern declaration of `BUS_WRITE_IVAR' @/dev/pci/pcivar.h:203: warning: redundant redeclaration of 'BUS_WRITE_IVAR' @/dev/pci/pcivar.h:203: warning: previous implicit declaration of 'BUS_WRITE_IVAR' was here @/dev/pci/pcivar.h: In function `pci_get_progif': @/dev/pci/pcivar.h:210: warning: nested extern declaration of `BUS_READ_IVAR' @/dev/pci/pcivar.h:203: warning: redundant redeclaration of 'BUS_READ_IVAR' @/dev/pci/pcivar.h:203: warning: previous implicit declaration of 'BUS_READ_IVAR' was here @/dev/pci/pcivar.h: In function `pci_set_progif': @/dev/pci/pcivar.h:210: warning: nested extern declaration of `BUS_WRITE_IVAR' @/dev/pci/pcivar.h:203: warning: redundant redeclaration of 'BUS_WRITE_IVAR' @/dev/pci/pcivar.h:203: warning: previous implicit declaration of 'BUS_WRITE_IVAR' was here @/dev/pci/pcivar.h: In function `pci_get_revid': @/dev/pci/pcivar.h:211: warning: nested extern declaration of `BUS_READ_IVAR' @/dev/pci/pcivar.h:203: warning: redundant redeclaration of 'BUS_READ_IVAR' @/dev/pci/pcivar.h:203: warning: previous implicit declaration of 'BUS_READ_IVAR' was here @/dev/pci/pcivar.h: In function `pci_set_revid': @/dev/pci/pcivar.h:211: warning: nested extern declaration of `BUS_WRITE_IVAR' @/dev/pci/pcivar.h:203: warning: redundant redeclaration of 'BUS_WRITE_IVAR' @/dev/pci/pcivar.h:203: warning: previous implicit declaration of 'BUS_WRITE_IVAR' was here @/dev/pci/pcivar.h: In function `pci_get_intpin': @/dev/pci/pcivar.h:212: warning: nested extern declaration of `BUS_READ_IVAR' @/dev/pci/pcivar.h:203: warning: redundant redeclaration of 'BUS_READ_IVAR' @/dev/pci/pcivar.h:203: warning: previous implicit declaration of 'BUS_READ_IVAR' was here @/dev/pci/pcivar.h: In function `pci_set_intpin': @/dev/pci/pcivar.h:212: warning: nested extern declaration of `BUS_WRITE_IVAR' @/dev/pci/pcivar.h:203: warning: redundant redeclaration of 'BUS_WRITE_IVAR' @/dev/pci/pcivar.h:203: warning: previous implicit declaration of 'BUS_WRITE_IVAR' was here @/dev/pci/pcivar.h: In function `pci_get_irq': @/dev/pci/pcivar.h:213: warning: nested extern declaration of `BUS_READ_IVAR' @/dev/pci/pcivar.h:203: warning: redundant redeclaration of 'BUS_READ_IVAR' @/dev/pci/pcivar.h:203: warning: previous implicit declaration of 'BUS_READ_IVAR' was here @/dev/pci/pcivar.h: In function `pci_set_irq': @/dev/pci/pcivar.h:213: warning: nested extern declaration of `BUS_WRITE_IVAR' @/dev/pci/pcivar.h:203: warning: redundant redeclaration of 'BUS_WRITE_IVAR' @/dev/pci/pcivar.h:203: warning: previous implicit declaration of 'BUS_WRITE_IVAR' was here @/dev/pci/pcivar.h: In function `pci_get_bus': @/dev/pci/pcivar.h:214: warning: nested extern declaration of `BUS_READ_IVAR' @/dev/pci/pcivar.h:203: warning: redundant redeclaration of 'BUS_READ_IVAR' @/dev/pci/pcivar.h:203: warning: previous implicit declaration of 'BUS_READ_IVAR' was here @/dev/pci/pcivar.h: In function `pci_set_bus': @/dev/pci/pcivar.h:214: warning: nested extern declaration of `BUS_WRITE_IVAR' @/dev/pci/pcivar.h:203: warning: redundant redeclaration of 'BUS_WRITE_IVAR' @/dev/pci/pcivar.h:203: warning: previous implicit declaration of 'BUS_WRITE_IVAR' was here @/dev/pci/pcivar.h: In function `pci_get_slot': @/dev/pci/pcivar.h:215: warning: nested extern declaration of `BUS_READ_IVAR' @/dev/pci/pcivar.h:203: warning: redundant redeclaration of 'BUS_READ_IVAR' @/dev/pci/pcivar.h:203: warning: previous implicit declaration of 'BUS_READ_IVAR' was here @/dev/pci/pcivar.h: In function `pci_set_slot': @/dev/pci/pcivar.h:215: warning: nested extern declaration of `BUS_WRITE_IVAR' @/dev/pci/pcivar.h:203: warning: redundant redeclaration of 'BUS_WRITE_IVAR' @/dev/pci/pcivar.h:203: warning: previous implicit declaration of 'BUS_WRITE_IVAR' was here @/dev/pci/pcivar.h: In function `pci_get_function': @/dev/pci/pcivar.h:216: warning: nested extern declaration of `BUS_READ_IVAR' @/dev/pci/pcivar.h:203: warning: redundant redeclaration of 'BUS_READ_IVAR' @/dev/pci/pcivar.h:203: warning: previous implicit declaration of 'BUS_READ_IVAR' was here @/dev/pci/pcivar.h: In function `pci_set_function': @/dev/pci/pcivar.h:216: warning: nested extern declaration of `BUS_WRITE_IVAR' @/dev/pci/pcivar.h:203: warning: redundant redeclaration of 'BUS_WRITE_IVAR' @/dev/pci/pcivar.h:203: warning: previous implicit declaration of 'BUS_WRITE_IVAR' was here @/dev/pci/pcivar.h: In function `pci_get_ether': @/dev/pci/pcivar.h:217: warning: nested extern declaration of `BUS_READ_IVAR' @/dev/pci/pcivar.h:203: warning: redundant redeclaration of 'BUS_READ_IVAR' @/dev/pci/pcivar.h:203: warning: previous implicit declaration of 'BUS_READ_IVAR' was here @/dev/pci/pcivar.h: In function `pci_set_ether': @/dev/pci/pcivar.h:217: warning: nested extern declaration of `BUS_WRITE_IVAR' @/dev/pci/pcivar.h:203: warning: redundant redeclaration of 'BUS_WRITE_IVAR' @/dev/pci/pcivar.h:203: warning: previous implicit declaration of 'BUS_WRITE_IVAR' was here @/dev/pci/pcivar.h: In function `pci_read_config': @/dev/pci/pcivar.h:227: warning: implicit declaration of function `PCI_READ_CONFIG' @/dev/pci/pcivar.h:227: warning: nested extern declaration of `PCI_READ_CONFIG' @/dev/pci/pcivar.h: In function `pci_write_config': @/dev/pci/pcivar.h:233: warning: implicit declaration of function `PCI_WRITE_CONFIG' @/dev/pci/pcivar.h:233: warning: nested extern declaration of `PCI_WRITE_CONFIG' @/dev/pci/pcivar.h: In function `pcib_get_bus': @/dev/pci/pcivar.h:248: warning: nested extern declaration of `BUS_READ_IVAR' @/dev/pci/pcivar.h:203: warning: redundant redeclaration of 'BUS_READ_IVAR' @/dev/pci/pcivar.h:203: warning: previous implicit declaration of 'BUS_READ_IVAR' was here @/dev/pci/pcivar.h: In function `pcib_set_bus': @/dev/pci/pcivar.h:248: warning: nested extern declaration of `BUS_WRITE_IVAR' @/dev/pci/pcivar.h:203: warning: redundant redeclaration of 'BUS_WRITE_IVAR' @/dev/pci/pcivar.h:203: warning: previous implicit declaration of 'BUS_WRITE_IVAR' was here @/dev/pci/pcivar.h: In function `pci_enable_busmaster': @/dev/pci/pcivar.h:269: warning: implicit declaration of function `PCI_ENABLE_BUSMASTER' @/dev/pci/pcivar.h:269: warning: nested extern declaration of `PCI_ENABLE_BUSMASTER' @/dev/pci/pcivar.h: In function `pci_disable_busmaster': @/dev/pci/pcivar.h:275: warning: implicit declaration of function `PCI_DISABLE_BUSMASTER' @/dev/pci/pcivar.h:275: warning: nested extern declaration of `PCI_DISABLE_BUSMASTER' @/dev/pci/pcivar.h: In function `pci_enable_io': @/dev/pci/pcivar.h:281: warning: implicit declaration of function `PCI_ENABLE_IO' @/dev/pci/pcivar.h:281: warning: nested extern declaration of `PCI_ENABLE_IO' @/dev/pci/pcivar.h: In function `pci_disable_io': @/dev/pci/pcivar.h:287: warning: implicit declaration of function `PCI_DISABLE_IO' @/dev/pci/pcivar.h:287: warning: nested extern declaration of `PCI_DISABLE_IO' @/dev/pci/pcivar.h: In function `pci_set_powerstate': @/dev/pci/pcivar.h:314: warning: implicit declaration of function `PCI_SET_POWERSTATE' @/dev/pci/pcivar.h:314: warning: nested extern declaration of `PCI_SET_POWERSTATE' @/dev/pci/pcivar.h: In function `pci_get_powerstate': @/dev/pci/pcivar.h:320: warning: implicit declaration of function `PCI_GET_POWERSTATE' @/dev/pci/pcivar.h:320: warning: nested extern declaration of `PCI_GET_POWERSTATE' saa713x.c: At top level: saa713x.c:50: error: conflicting types for 'saa713x_open' saa713x.c:27: error: previous declaration of 'saa713x_open' was here saa713x.c:50: error: conflicting types for 'saa713x_open' saa713x.c:27: error: previous declaration of 'saa713x_open' was here saa713x.c:59: error: conflicting types for 'saa713x_close' saa713x.c:28: error: previous declaration of 'saa713x_close' was here saa713x.c:59: error: conflicting types for 'saa713x_close' saa713x.c:28: error: previous declaration of 'saa713x_close' was here saa713x.c:68: error: conflicting types for 'saa713x_read' saa713x.c:29: error: previous declaration of 'saa713x_read' was here saa713x.c:68: error: conflicting types for 'saa713x_read' saa713x.c:29: error: previous declaration of 'saa713x_read' was here saa713x.c:77: error: conflicting types for 'saa713x_write' saa713x.c:30: error: previous declaration of 'saa713x_write' was here saa713x.c:77: error: conflicting types for 'saa713x_write' saa713x.c:30: error: previous declaration of 'saa713x_write' was here saa713x.c: In function `saa713x_attach': saa713x.c:111: warning: assignment makes integer from pointer without a cast saa713x.c: At top level: saa713x.c:161: error: `device_probe_desc' undeclared here (not in a function) saa713x.c:161: error: initializer element is not constant saa713x.c:161: error: (near initialization for `saa713x_methods[0].desc') saa713x.c:161: error: initializer element is not constant saa713x.c:161: error: (near initialization for `saa713x_methods[0]') saa713x.c:162: error: `device_attach_desc' undeclared here (not in a function) saa713x.c:162: error: initializer element is not constant saa713x.c:162: error: (near initialization for `saa713x_methods[1].desc') saa713x.c:162: error: initializer element is not constant saa713x.c:162: error: (near initialization for `saa713x_methods[1]') saa713x.c:163: error: `device_detach_desc' undeclared here (not in a function) saa713x.c:163: error: initializer element is not constant saa713x.c:163: error: (near initialization for `saa713x_methods[2].desc') saa713x.c:163: error: initializer element is not constant saa713x.c:163: error: (near initialization for `saa713x_methods[2]') saa713x.c:164: error: `device_shutdown_desc' undeclared here (not in a function) saa713x.c:164: error: initializer element is not constant saa713x.c:164: error: (near initialization for `saa713x_methods[3].desc') saa713x.c:164: error: initializer element is not constant saa713x.c:164: error: (near initialization for `saa713x_methods[3]') saa713x.c:165: error: `device_suspend_desc' undeclared here (not in a function) saa713x.c:165: error: initializer element is not constant saa713x.c:165: error: (near initialization for `saa713x_methods[4].desc') saa713x.c:165: error: initializer element is not constant saa713x.c:165: error: (near initialization for `saa713x_methods[4]') saa713x.c:166: error: `device_resume_desc' undeclared here (not in a function) saa713x.c:166: error: initializer element is not constant saa713x.c:166: error: (near initialization for `saa713x_methods[5].desc') saa713x.c:166: error: initializer element is not constant saa713x.c:166: error: (near initialization for `saa713x_methods[5]') saa713x.c:168: error: initializer element is not constant saa713x.c:168: error: (near initialization for `saa713x_methods[6]') *** Error code 1 Stop in /usr/home/.../projects/FreeBSD/device_drivers/saa713X. The source code is this:START STAGE /* * SAA713X Phillips Chipset * * Murray Stokely */ //#define MIN(a,b) (((a) < (b)) ? (a) : (b)) #include /* defines used in kernel.h */ #include #include #include #include /* types used in module initialization */ #include /* cdevsw struct */ #include /* uio struct */ #include #include /* structs, prototypes for pci bus stuff */ #include #include #include #include /* For get_pci macros! */ #include /* Function prototypes */ d_open_t saa713x_open; d_close_t saa713x_close; d_read_t saa713x_read; d_write_t saa713x_write; /* Character device entry points */ static struct cdevsw saa713x_cdevsw = { .d_open = saa713x_open, .d_close = saa713x_close, .d_read = saa713x_read, .d_write = saa713x_write, .d_name = "saa713x", }; /* vars */ static dev_t sdev; /* We're more interested in probe/attach than with open/close/read/write at this point */ int saa713x_open(dev_t dev, int oflags, int devtype, d_thread_t *td) { int err = 0; printf("Opened device \"saa713x\" successfully.\n"); return (err); } int saa713x_close(dev_t dev, int fflag, int devtype, d_thread_t *td) { int err = 0; printf("Closing device \"saa713x.\"\n"); return (err); } int saa713x_read(dev_t dev, struct uio *uio, int ioflag) { int err = 0; printf("saa713x read!\n"); return (err); } int saa713x_write(dev_t dev, struct uio *uio, int ioflag) { int err = 0; printf("saa713x write!\n"); return (err); } /* PCI Support Functions */ /* * Return identification string if this is device is ours. */ static int saa713x_probe(device_t dev) { device_printf(dev, "Saa713x Probe\nVendor ID : 0x%x\nDevice ID : 0x% x\n", pci_get_vendor(dev), pci_get_device(dev)); if (pci_get_vendor(dev) == 0x11c1) { printf("We've got the Winmodem, probe successful!\n"); return (0); } return (ENXIO); } /* Attach function is only called if the probe is successful */ static int saa713x_attach(device_t dev) { printf("Saa713x Attach for : deviceID : 0x%x \n",pci_get_vendor(dev)); sdev = make_dev(&saa713x_cdevsw, 0, UID_ROOT, GID_WHEEL, 0600, "saa713x"); printf("Saa713x device loaded.\n"); return (ENXIO); } /* Detach device. */ static int saa713x_detach(device_t dev) { printf("Saa713x detach!\n"); return (0); } /* Called during system shutdown after sync. */ static int saa713x_shutdown(device_t dev) { printf("Saa713x shutdown!\n"); return (0); } /* * Device suspend routine. */ static int saa713x_suspend(device_t dev) { printf("Saa713x suspend!\n"); return (0); } /* * Device resume routine. */ static int saa713x_resume(device_t dev) { printf("Saa713x resume!\n"); return (0); } static device_method_t saa713x_methods[] = { /* Device interface */ DEVMETHOD(device_probe, saa713x_probe), DEVMETHOD(device_attach, saa713x_attach), DEVMETHOD(device_detach, saa713x_detach), DEVMETHOD(device_shutdown, saa713x_shutdown), DEVMETHOD(device_suspend, saa713x_suspend), DEVMETHOD(device_resume, saa713x_resume), { 0, 0 } }; static driver_t saa713x_driver = { "saa713x", saa713x_methods, 0, /* sizeof(struct saa713x_softc), */ }; static devclass_t saa713x_devclass; DRIVER_MODULE(saa713x, pci, saa713x_driver, saa713x_devclass, 0, 0); thanks for any help From owner-freebsd-hackers@FreeBSD.ORG Fri May 20 05:28:51 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 53ACD16A4CE for ; Fri, 20 May 2005 05:28:51 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id B569143DA4 for ; Fri, 20 May 2005 05:28:50 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j4K5VtxK098132; Thu, 19 May 2005 23:31:55 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <428D7551.1030702@samsco.org> Date: Thu, 19 May 2005 23:27:45 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Lu=EDs_Vit=F3rio_Cargnini?= References: <1116559426.27848.7.camel@shark.hopto.org> In-Reply-To: <1116559426.27848.7.camel@shark.hopto.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: freebsd-hackers@freebsd.org Subject: Re: PCI Device Driver X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2005 05:28:51 -0000 Luís Vitório Cargnini wrote: > Hi i need to write a device driver for a PCI board. I read the > developers book see the exemples and i'm starting to write the device > driver. I'm writeing a device driver for a board with SAA713X TV chipset > from Phillips. I did theskeleton example, but whe i catch the example of > PCI driver from developers book and tried to compilate i receive the > following: > (forgive me for the long paste, but i need some answers and i need to > give the details) > > > PASTE of ERORS: Yes, the skeleton driver is very out of date. Would anyone object to me updating it and tossing out the ISA code? Scott From owner-freebsd-hackers@FreeBSD.ORG Fri May 20 05:37:58 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 91F5616A4CF for ; Fri, 20 May 2005 05:37:58 +0000 (GMT) Received: from evil.alameda.net (pachell-dsl.pachell.net [64.81.53.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A47D43DB4 for ; Fri, 20 May 2005 05:37:58 +0000 (GMT) (envelope-from ulf@alameda.net) Received: by evil.alameda.net (Postfix, from userid 1000) id 6521933C24; Thu, 19 May 2005 22:37:57 -0700 (PDT) Date: Thu, 19 May 2005 22:37:57 -0700 From: Ulf Zimmermann To: Scott Long Message-ID: <20050520053757.GA7541@evil.alameda.net> References: <1116559426.27848.7.camel@shark.hopto.org> <428D7551.1030702@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <428D7551.1030702@samsco.org> User-Agent: Mutt/1.4.2.1i Organization: Alameda Networks, Inc. X-Operating-System: FreeBSD 5.3-STABLE cc: freebsd-hackers@freebsd.org cc: Lu?s Vit?rio Cargnini Subject: Re: PCI Device Driver X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ulf@Alameda.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2005 05:37:58 -0000 On Thu, May 19, 2005 at 11:27:45PM -0600, Scott Long wrote: > Lu?s Vit?rio Cargnini wrote: > > >Hi i need to write a device driver for a PCI board. I read the > >developers book see the exemples and i'm starting to write the device > >driver. I'm writeing a device driver for a board with SAA713X TV chipset > >from Phillips. I did theskeleton example, but whe i catch the example of > >PCI driver from developers book and tried to compilate i receive the > >following: > >(forgive me for the long paste, but i need some answers and i need to > >give the details) > > > > > >PASTE of ERORS: > > Yes, the skeleton driver is very out of date. Would anyone object > to me updating it and tossing out the ISA code? > > Scott PLEASE! :-) I was starting to look at it myself for a driver to the Digi/Patton 2977 card and got stucked. From owner-freebsd-hackers@FreeBSD.ORG Fri May 20 06:02:25 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0183D16A4CF for ; Fri, 20 May 2005 06:02:25 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3226243DA3 for ; Fri, 20 May 2005 06:02:24 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j4K616Ej081745; Fri, 20 May 2005 00:01:06 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 20 May 2005 00:01:21 -0600 (MDT) Message-Id: <20050520.000121.42772127.imp@bsdimp.com> To: scottl@samsco.org From: "M. Warner Losh" In-Reply-To: <428D7551.1030702@samsco.org> References: <1116559426.27848.7.camel@shark.hopto.org> <428D7551.1030702@samsco.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org cc: cargnini@cargnini.trix.net Subject: Re: PCI Device Driver X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2005 06:02:25 -0000 In message: <428D7551.1030702@samsco.org> Scott Long writes: : Yes, the skeleton driver is very out of date. Would anyone object : to me updating it and tossing out the ISA code? I personally think it should be in dev/skel and in lint build instead of squirreled away who knows where. This would let us also make sure that all the 'supported' busses be in the tree and always available for copying. We should then delete the weird things in /usr/share/examples/drivers. They are too hard to keep up to date. Warner From owner-freebsd-hackers@FreeBSD.ORG Fri May 20 08:28:44 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C42B316A4CE for ; Fri, 20 May 2005 08:28:44 +0000 (GMT) Received: from mail06.syd.optusnet.com.au (mail06.syd.optusnet.com.au [211.29.132.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB27E43D46 for ; Fri, 20 May 2005 08:28:43 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j4K8Scw1017675 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 20 May 2005 18:28:39 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j4K8SbRx005385; Fri, 20 May 2005 18:28:37 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j4K8SbdN005384; Fri, 20 May 2005 18:28:37 +1000 (EST) (envelope-from pjeremy) Date: Fri, 20 May 2005 18:28:37 +1000 From: Peter Jeremy To: =?iso-8859-1?Q?Lu=EDs_Vit=F3rio?= Cargnini Message-ID: <20050520082837.GE2129@cirb503493.alcatel.com.au> References: <1116559426.27848.7.camel@shark.hopto.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1116559426.27848.7.camel@shark.hopto.org> User-Agent: Mutt/1.4.2i cc: freebsd-hackers@freebsd.org Subject: Re: PCI Device Driver X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2005 08:28:44 -0000 On Fri, 2005-May-20 00:23:46 -0300, Luís Vitório Cargnini wrote: >driver. I'm writeing a device driver for a board with SAA713X TV chipset >from Phillips. Before expending too much effort on this, you might like to study http://www.purpe.com/download/ BTW, where did you find programming information for the 713x? -- Peter Jeremy From owner-freebsd-hackers@FreeBSD.ORG Fri May 20 11:41:43 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F6C916A4CE for ; Fri, 20 May 2005 11:41:43 +0000 (GMT) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8512E43D98 for ; Fri, 20 May 2005 11:41:42 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: Y1QAsIk9O44SO+J/q9KNyQ== Received: from mp-217-209-234.daxnet.no ([193.217.209.234] verified) by mailfe07.swip.net (CommuniGate Pro SMTP 4.3c5) with ESMTP id 174416752 for freebsd-hackers@freebsd.org; Fri, 20 May 2005 13:39:47 +0200 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Fri, 20 May 2005 13:40:35 +0200 User-Agent: KMail/1.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505201340.36176.hselasky@c2i.net> Subject: problems with new the "contigmalloc" routine X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: hselasky@c2i.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2005 11:41:43 -0000 Hi, I just hit some problems with the new "contigmalloc()" routine in FreeBSD-6-current, which is used by "bus_dmamem_alloc()". Firstly it locks Giant, which cause locking order reversals when allocating memory from certain contexts. Secondly it sleeps even if flag M_NOWAIT is passed. Thirdly it does not support flag M_ZERO. Can someone explain why these changes have been made? Why doesn't "contigmalloc()" give a warning when an invalid flag is passed? Are these bugs in "contigmalloc()"? Or does the code using "contigmalloc()" have to be changed? kernel: lock order reversal kernel: 1st 0xc175a6c8 ugen lock (ugen lock) @ /usr/src/sys/dev/usb2/_ugen.c:1452 kernel: 2nd 0xc09bdde0 Giant (Giant) @ /usr/src/sys/vm/vm_contig.c:550 kernel: KDB: stack backtrace: kernel: witness_checkorder(c09bdde0,9,c08e34af,226) at witness_checkorder+0x50c kernel: _mtx_lock_flags(c09bdde0,0,c08e34af,226,8) at _mtx_lock_flags+0x40 kernel: contigmalloc(184ec,c0952c60,1,0,ffffffff) at contigmalloc+0x45 kernel: bus_dmamem_alloc(c1aacc00,d4cd7974,5,d4cd7978) at bus_dmamem_alloc+0x61 kernel: usb_alloc_mem(184e0,4,8,8,d4164ae4) at usb_alloc_mem+0x53 ... kernel: malloc(M_WAITOK) of "g_bio", forcing M_NOWAIT with the following non-sleepable locks held: kernel: exclusive sleep mutex ugen lock r = 0 (0xc175a6c8) locked @ /usr/src/sys/dev/usb2/_ugen.c:1452 kernel: KDB: stack backtrace: kernel: witness_warn(5,0,c08e3022,c08c3c87) at witness_warn+0x1a8 kernel: uma_zalloc_arg(c103dc60,0,102) at uma_zalloc_arg+0x4b kernel: g_allotpages(c1af918c,d4cd783c,1,1,d4cd7800) at swap_pager_putpages+0x413 kernel: vm_pageout_flush(d4cd783c,1,1,c1460d88,c1461058) at vm_pageout_flush+0xf5 kernel: vm_contig_launder_page(e269,0,c0a0b8d0,ffffffff,f) at vm_contig_launder_page+0xa8 kernel: vm_page_alloc_contig(19,0,0,ffffffff,10) at vm_page_alloc_contig+0x204 kernel: contigmalloc(184ec,c0952c60,1,0,ffffffff) at contigmalloc+0x337 kernel: bus_dmamem_alloc(c1aacc00,d4cd7974,5,d4cd7978) at bus_dmamem_alloc+0x61 kernel: usb_alloc_mem(184e0,4,8,8,d4164ae4) at usb_alloc_mem+0x53 ... --HPS From owner-freebsd-hackers@FreeBSD.ORG Fri May 20 01:05:13 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A0E816A4CF for ; Fri, 20 May 2005 01:05:13 +0000 (GMT) Received: from smtp.iesy.net (mta001.iesy.net [81.210.131.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7AF9A43D53 for ; Fri, 20 May 2005 01:05:11 +0000 (GMT) (envelope-from walter.pelissero@iesy.net) Received: from zaphod.home.loc (unknown [81.210.131.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.iesy.net (Postfix) with ESMTP id 373CD21F9F for ; Fri, 20 May 2005 03:05:08 +0200 (CEST) Received: from zaphod.home.loc (localhost [127.0.0.1]) by zaphod.home.loc (8.13.3/8.13.3) with ESMTP id j4K157In030177 for ; Fri, 20 May 2005 03:05:07 +0200 (CEST) (envelope-from wcp@zaphod.home.loc) Received: (from wcp@localhost) by zaphod.home.loc (8.13.3/8.13.1/Submit) id j4K156HC030174; Fri, 20 May 2005 03:05:06 +0200 (CEST) (envelope-from wcp) From: "Walter C. Pelissero" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17037.14274.229768.369886@zaphod.home.loc> Date: Fri, 20 May 2005 03:05:06 +0200 To: freebsd-hackers@freebsd.org X-Mailer: VM 7.19 under Emacs 22.0.50.1 X-Attribution: WP X-For-Spammers: blacklistme@pelissero.de X-MArch-Archive-Date: 2005-05-20 03:05:07 X-MArch-Archive-ID: 2281 X-MArch-Processing-Time: 0.29s X-Mailman-Approved-At: Fri, 20 May 2005 12:40:40 +0000 Subject: WRAP.1E and geode.c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: walter@pelissero.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2005 01:05:13 -0000 Reading geode.c it appears (at least to me) that the led devices are created for the WRAP.1C but not for the WRAP.1E. Guessing from the dmesg output $ dmesg Copyright (c) 1992-2004 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-RELEASE #0: Sun Mar 20 17:12:36 CET 2005 root@daemon5.neon1.net:/m0n0wall/kernels/wrap Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Geode(TM) Integrated Processor by National Semi (266.65-MHz 586-class CPU) Origin = "Geode by NSC" Id = 0x540 Stepping = 0 Features=0x808131 real memory = 134217728 (128 MB) avail memory = 109277184 (104 MB) npx0: [FAST] npx0: on motherboard npx0: INT 16 interface pcib0: pcibus 0 on motherboard pci0: on pcib0 sis0: port 0x1000-0x10ff mem 0x80000000-0x80000fff irq 10 at device 14.0 on pci0 sis0: Silicon Revision: DP83816A miibus0: on sis0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis0: Ethernet address: 00:0d:b9:01:12:04 sis1: port 0x1400-0x14ff mem 0x80040000-0x80040fff irq 9 at device 15.0 on pci0 sis1: Silicon Revision: DP83816A miibus1: on sis1 ukphy1: on miibus1 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis1: Ethernet address: 00:0d:b9:01:12:05 sis2: port 0x1800-0x18ff mem 0x80080000-0x80080fff irq 11 at device 16.0 on pci0 sis2: Silicon Revision: DP83816A miibus2: on sis2 ukphy2: on miibus2 ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis2: Ethernet address: 00:0d:b9:01:12:06 Geode GPIO@ = f400 isab0: port 0xf600-0xf63f,0xf400-0xf43f at device 18.0 on pci0 isa0: on isab0 pci0: at device 18.1 (no driver attached) atapci0: port 0xfc00-0xfc0f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 18.2 on pci0 ata0: channel #0 on atapci0 pci0: at device 18.3 (no driver attached) * Geode CBA@ 0x9000 * Geode rev: 06 03 Timecounter "Geode" frequency 27000000 Hz quality 1000 pci0: at device 18.5 (no driver attached) cpu0 on motherboard pmtimer0 on isa0 sio0 at port 0x3f8-0x3ff irq 4 flags 0x30 on isa0 sio0: type 16550A, console sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A Timecounters tick every 1.000 msec Fast IPsec: Initialized Security Association Processing. IP Filter: v3.4.35 initialized. Default = block all, Logging = enabled md0: Preloaded image 16777216 bytes at 0xc0740624 ad0: FAILURE - SETFEATURES ENABLE RCACHE status=51 error=4 ad0: FAILURE - SETFEATURES DISABLE WCACHE status=51 error=4 ad0: 15MB [490/2/32] at ata0-master PIO4 Mounting root from ufs:/dev/md0 ipfw2 initialized, divert disabled, rule-based forwarding enabled, default to accept, logging disabled I'd say the WRAP.1E has a PCI device ID 0x0515100b as it falls in the first if-branch of the following code (from geode.c): static int geode_probe(device_t self) { if (pci_get_devid(self) == 0x0515100b) { if (geode_counter == 0) { /* * The address of the CBA is written to this register * by the bios, see p161 in data sheet. */ cba = pci_read_config(self, 0x64, 4); printf("Geode CBA@ 0x%x\n", cba); geode_counter = cba + 0x08; outl(cba + 0x0d, 2); printf("Geode rev: %02x %02x\n", inb(cba + 0x3c), inb(cba + 0x3d)); tc_init(&geode_timecounter); EVENTHANDLER_REGISTER(watchdog_list, geode_watchdog, NULL, 0); } } else if (pci_get_devid(self) == 0x0510100b) { gpio = pci_read_config(self, PCIR_BAR(0), 4); gpio &= ~0x1f; printf("Geode GPIO@ = %x\n", gpio); if (NULL != bios_string(0xf0000, 0xf0100, "Soekris Engineering", 0)) { printf("Soekris Engineering NET4801 platform\n"); led1b = 20; led1 = led_create(led_func, &led1b, "error"); } else if (NULL != bios_string(0xf9000, 0xf9000, "PC Engines WRAP.1C ", 0)) { printf("PC Engines WRAP.1C platfrom\n"); led1b = -2; led2b = -3; led3b = -18; led1 = led_create(led_func, &led1b, "led1"); led2 = led_create(led_func, &led2b, "led2"); led3 = led_create(led_func, &led3b, "led3"); /* * Turn on first LED so we don't make people think * their box just died. */ led_func(&led1b, 1); } } return (ENXIO); } Reading the PC-Engines documentation it looks to me as WRAP.1C and WRAP1.E were identical when it comes to the LEDs, thus it would be nice to have the same entries in /dev. Anyone with a better understanding of this platform cares to comment on this? -- walter pelissero http://www.pelissero.de From owner-freebsd-hackers@FreeBSD.ORG Fri May 20 13:13:04 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B8F516A4CE for ; Fri, 20 May 2005 13:13:04 +0000 (GMT) Received: from mail.iinet.net.au (mail-08.iinet.net.au [203.59.3.40]) by mx1.FreeBSD.org (Postfix) with SMTP id EE12443D3F for ; Fri, 20 May 2005 13:13:02 +0000 (GMT) (envelope-from julian@elischer.org) Received: (qmail 1706 invoked from network); 20 May 2005 13:13:01 -0000 Received: from unknown (HELO ?10.1.1.200?) (203.59.107.51) by mail.iinet.net.au with SMTP; 20 May 2005 13:13:01 -0000 Message-ID: <428DE257.9050707@elischer.org> Date: Fri, 20 May 2005 06:12:55 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050424 X-Accept-Language: en, hu MIME-Version: 1.0 To: Scott Long References: <1116559426.27848.7.camel@shark.hopto.org> <428D7551.1030702@samsco.org> In-Reply-To: <428D7551.1030702@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit cc: freebsd-hackers@freebsd.org cc: =?ISO-8859-1?Q?Lu=EDs_Vit=F3rio_Cargnini?= Subject: Re: PCI Device Driver X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2005 13:13:04 -0000 Scott Long wrote: > Luís Vitório Cargnini wrote: > >> Hi i need to write a device driver for a PCI board. I read the >> developers book see the exemples and i'm starting to write the device >> driver. I'm writeing a device driver for a board with SAA713X TV chipset >> from Phillips. I did theskeleton example, but whe i catch the example of >> PCI driver from developers book and tried to compilate i receive the >> following: >> (forgive me for the long paste, but i need some answers and i need to >> give the details) >> >> >> PASTE of ERORS: > > > Yes, the skeleton driver is very out of date. Would anyone object > to me updating it and tossing out the ISA code? sure go ahead (this is /usr/share/examples/drivers right? Warner said recently that he was going ot update it after he had finished some changes to the bus code, so check with him too. > > Scott > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Fri May 20 13:16:30 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B336816A4CE for ; Fri, 20 May 2005 13:16:30 +0000 (GMT) Received: from swip.net (mailfe02.swip.net [212.247.154.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id D9EDC43DBC for ; Fri, 20 May 2005 13:16:29 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: tC2uFeET5U2ZgUk1ospYHg== Received: from mp-217-201-83.daxnet.no ([193.217.201.83] verified) by mailfe02.swip.net (CommuniGate Pro SMTP 4.3c5) with ESMTP id 371874514; Fri, 20 May 2005 15:15:54 +0200 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Fri, 20 May 2005 15:16:41 +0200 User-Agent: KMail/1.7 References: <200505200029.j4K0TJNb000312@karga.hank.home> In-Reply-To: <200505200029.j4K0TJNb000312@karga.hank.home> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200505201516.42733.hselasky@c2i.net> cc: Dirk GOUDERS Subject: Re: page fault in ugenpoll() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: hselasky@c2i.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2005 13:16:30 -0000 On Friday 20 May 2005 02:29, Dirk GOUDERS wrote: > Hello, > > just for completeness, I want to provide a simple program that causes > a kernel panic when invoked with the argument /dev/ugen0: The control endpoint /dev/ugen0 does not support polling. But polling /dev/ugen0.X should work, where "X" is a number. "ugenpoll()" in "/sys/dev/usb/ugen.c" should have something like this added: if(control endpoint) return POLLNVAL; /* and not "return EIO;" */ Please file a PR on this issue using: >Category: usb --HPS From owner-freebsd-hackers@FreeBSD.ORG Fri May 20 15:01:43 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A242D16A4CE for ; Fri, 20 May 2005 15:01:43 +0000 (GMT) Received: from alice.et.bocholt.fh-gelsenkirchen.de (alice.et.bocholt.fh-gelsenkirchen.de [193.175.197.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id C9E5343DA3 for ; Fri, 20 May 2005 15:01:42 +0000 (GMT) (envelope-from gouders@et.bocholt.fh-gelsenkirchen.de) Received: from musashi.et.bocholt.fh-gelsenkirchen.de (musashi.et.bocholt.fh-gelsenkirchen.de [193.175.197.95]) j4KF1ZOr004833 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 20 May 2005 17:01:36 +0200 Received: from karga.hank.home (karga.hank.home [192.168.252.2]) id j4KF1ZKY005207 for ; Fri, 20 May 2005 17:01:35 +0200 (CEST) (envelope-from hank@karga.hank.home) Received: from localhost (localhost [127.0.0.1]) by karga.hank.home (8.13.3/8.13.3) with ESMTP id j4KF33sH001416 for ; Fri, 20 May 2005 17:03:03 +0200 (CEST) (envelope-from hank@karga.hank.home) Message-Id: <200505201503.j4KF33sH001416@karga.hank.home> To: freebsd-hackers@freebsd.org In-Reply-To: Message from Hans Petter Selasky <200505201516.42733.hselasky@c2i.net> Date: Fri, 20 May 2005 17:03:03 +0200 From: Dirk GOUDERS X-Scanned-By: MIMEDefang 2.43 Subject: Re: page fault in ugenpoll() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2005 15:01:43 -0000 > The control endpoint /dev/ugen0 does not support polling. But > polling /dev/ugen0.X should work, where "X" is a number. > > "ugenpoll()" in "/sys/dev/usb/ugen.c" should have something like this added: > > if(control endpoint) return POLLNVAL; /* and not "return EIO;" */ > > Please file a PR on this issue using: > > >Category: usb Thank you. I modified ugen.c in the way you suggested and filed a PR. Dirk From owner-freebsd-hackers@FreeBSD.ORG Fri May 20 15:16:21 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 3164E16A4CE; Fri, 20 May 2005 15:16:21 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.3/8.13.1) with ESMTP id j4KFGKoA096849; Fri, 20 May 2005 11:16:20 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.3/8.13.1/Submit) id j4KFGKDV096848; Fri, 20 May 2005 11:16:20 -0400 (EDT) (envelope-from green) Date: Fri, 20 May 2005 11:16:20 -0400 From: Brian Fundakowski Feldman To: Hans Petter Selasky Message-ID: <20050520151620.GF1201@green.homeunix.org> References: <200505201340.36176.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200505201340.36176.hselasky@c2i.net> User-Agent: Mutt/1.5.6i cc: hackers@FreeBSD.org Subject: Re: problems with new the "contigmalloc" routine X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2005 15:16:21 -0000 On Fri, May 20, 2005 at 01:40:35PM +0200, Hans Petter Selasky wrote: > Hi, > > I just hit some problems with the new "contigmalloc()" routine in > FreeBSD-6-current, which is used by "bus_dmamem_alloc()". > > Firstly it locks Giant, which cause locking order reversals when allocating > memory from certain contexts. Secondly it sleeps even if flag M_NOWAIT is > passed. Thirdly it does not support flag M_ZERO. Read the documentation. It supports M_ZERO just fine, and it does _not_ support M_NOWAIT. > Can someone explain why these changes have been made? Changes? > Why doesn't "contigmalloc()" give a warning when an invalid flag is passed? The kernel would be significantly larger and almost certainly slower if it were to double-check that everywhere any bit fields are used that flags that are not defined to have any behavior are unset. > Are these bugs in "contigmalloc()"? No. > Or does the code using "contigmalloc()" have to be changed? Yes. The i386 bus_dmamem_alloc(), for example, calls it with M_NOWAIT which is not a valid flag. The contigmalloc(9) page is not entirely truthful about the fact that it doesn't sleep at all -- it calls those routines which can. They can both be documented to require no locks to be held when being called, except for M_NOWAIT specifically in the one-page-or-less allocation case. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-hackers@FreeBSD.ORG Fri May 20 15:39:08 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 17B3816A4D0 for ; Fri, 20 May 2005 15:39:08 +0000 (GMT) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 23D6243D86 for ; Fri, 20 May 2005 15:39:07 +0000 (GMT) (envelope-from aurelbodenmann@gmx.ch) Received: (qmail 19471 invoked by uid 0); 20 May 2005 15:39:02 -0000 Received: from 80.238.133.37 by www14.gmx.net with HTTP; Fri, 20 May 2005 17:39:02 +0200 (MEST) Date: Fri, 20 May 2005 17:39:02 +0200 (MEST) From: "Aurel Bodenmann" To: freebsd-hackers@freebsd.org MIME-Version: 1.0 X-Priority: 3 (Normal) X-Authenticated: #14536212 Message-ID: <16574.1116603542@www14.gmx.net> X-Mailer: WWW-Mail 1.6 (Global Message Exchange) X-Flags: 0001 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: kgdb doesn't seem to work, says "Cannot read PTD" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2005 15:39:08 -0000 Hello! My FreeBSD box is giving me quite a hard time, it panics from time to time (normally after a few days uptime), I suspect it has something to do with this cheap SATA controller I'm using (Promise SATA150 TX4). Anyway, I wanted to locate the problem and do something about it (aka submit an useful coredump to this list :-) but unfortunately neither gdb nor kgdb seem to work for me. I've tried to make a coredump as described in [1] and have now a kernel.debug file (containing the kernel with debug information) and a vmcore.1 file (whose size is 768MB as it should be). Now, I'm trying to open these two with gdb -k kernel.debug vmcore.1 but it says gdb: unrecognized option `-k' Use `gdb --help' for a complete list of options. so I read the manpage only to find out that -k still exists and that it should work like described in [1]. Ok, so I've tried kgdb but it gives me an error too: root> kgdb kernel.debug vmcore.1 kgdb: cannot read PTD after some googling I found out, that some people are having the same trouble ([2] and [3]) but unfortunately I couldn't find any advice on how-to create an useful coredump without using kgdb or gdb. I would really appreciate if someone could help me, I would like to help on this bug. Thanks, Aurel Bodenmann [1] http://www.onlamp.com/pub/a/bsd/2002/04/04/Big_Scary_Daemons.html [2] http://lists.freebsd.org/mailman/htdig/freebsd-hackers/2005-April/ 011461.html [3] http://lists.freebsd.org/pipermail/freebsd-stable/2005-May/ 014515.html -- 5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail +++ GMX - die erste Adresse für Mail, Message, More +++ From owner-freebsd-hackers@FreeBSD.ORG Fri May 20 16:31:29 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3200D16A4CE for ; Fri, 20 May 2005 16:31:29 +0000 (GMT) Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9546C43D9E for ; Fri, 20 May 2005 16:31:24 +0000 (GMT) (envelope-from des@des.no) Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IGS00F4MX3IUS20@osl1smout1.broadpark.no> for freebsd-hackers@freebsd.org; Fri, 20 May 2005 20:38:06 +0200 (CEST) Received: from dsa.des.no ([80.203.228.37]) by osl1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IGS00JDFRELB730@osl1sminn1.broadpark.no> for freebsd-hackers@freebsd.org; Fri, 20 May 2005 18:35:09 +0200 (CEST) Received: by dsa.des.no (Pony Express, from userid 666) id D26B345165; Fri, 20 May 2005 18:31:22 +0200 (CEST) Received: from xps.des.no (xps.des.no [10.0.0.12]) by dsa.des.no (Pony Express) with ESMTP id D16F745131; Fri, 20 May 2005 18:31:18 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id AAA4A33C1C; Fri, 20 May 2005 18:31:18 +0200 (CEST) Date: Fri, 20 May 2005 18:31:18 +0200 From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) In-reply-to: <16574.1116603542@www14.gmx.net> To: Aurel Bodenmann Message-id: <86ekc1dfl5.fsf@xps.des.no> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on dsa.des.no References: <16574.1116603542@www14.gmx.net> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL autolearn=disabled version=3.0.2 X-Spam-Level: cc: freebsd-hackers@freebsd.org Subject: Re: kgdb doesn't seem to work, says "Cannot read PTD" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2005 16:31:29 -0000 "Aurel Bodenmann" writes: > My FreeBSD box is giving me quite a hard time, it panics from time to > time (normally after a few days uptime), I suspect it has something > to do with this cheap SATA controller I'm using (Promise SATA150 > TX4). The SATA150 TX4 is not cheap, at least not in the "poor quality" sense of the word. > . Anyway, I wanted to locate the problem and do something about > it (aka submit an useful coredump to this list :-) but unfortunately > neither gdb nor kgdb seem to work for me. Well, thank you for trying! In the meantime, could you post the panic message and backtrace, or at least the contents of /var/crash/info.1? DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Fri May 20 16:40:36 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3369B16A4CE; Fri, 20 May 2005 16:40:36 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A5E143D4C; Fri, 20 May 2005 16:40:32 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j4KGhHqq001347; Fri, 20 May 2005 10:43:17 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <428E12B0.9020208@samsco.org> Date: Fri, 20 May 2005 10:39:12 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Fundakowski Feldman References: <200505201340.36176.hselasky@c2i.net> <20050520151620.GF1201@green.homeunix.org> In-Reply-To: <20050520151620.GF1201@green.homeunix.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: hackers@freebsd.org cc: Hans Petter Selasky Subject: Re: problems with new the "contigmalloc" routine X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2005 16:40:36 -0000 Brian Fundakowski Feldman wrote: > On Fri, May 20, 2005 at 01:40:35PM +0200, Hans Petter Selasky wrote: > >>Hi, >> >>I just hit some problems with the new "contigmalloc()" routine in >>FreeBSD-6-current, which is used by "bus_dmamem_alloc()". >> >>Firstly it locks Giant, which cause locking order reversals when allocating >>memory from certain contexts. Secondly it sleeps even if flag M_NOWAIT is >>passed. Thirdly it does not support flag M_ZERO. > > > Read the documentation. It supports M_ZERO just fine, and it does _not_ > support M_NOWAIT. > > >>Can someone explain why these changes have been made? > > > Changes? > > >>Why doesn't "contigmalloc()" give a warning when an invalid flag is passed? > > > The kernel would be significantly larger and almost certainly slower > if it were to double-check that everywhere any bit fields are used > that flags that are not defined to have any behavior are unset. > > >>Are these bugs in "contigmalloc()"? > > > No. > > >>Or does the code using "contigmalloc()" have to be changed? > > > Yes. The i386 bus_dmamem_alloc(), for example, calls it with M_NOWAIT > which is not a valid flag. The contigmalloc(9) page is not entirely > truthful about the fact that it doesn't sleep at all -- it calls those > routines which can. They can both be documented to require no locks > to be held when being called, except for M_NOWAIT specifically in the > one-page-or-less allocation case. > The amount of colateral damage that has been inflicted on bus_dmamem_alloc by your changes to contigmalloc is truly impressive. Since I've spent the better part of 8 months cleaning it up, please let me know what else needs to be done so that there are no more surprises. And no, this is not my happy face. Scott From owner-freebsd-hackers@FreeBSD.ORG Fri May 20 17:32:40 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 1D07C16A4CF; Fri, 20 May 2005 17:32:40 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.3/8.13.1) with ESMTP id j4KHWdSA097541; Fri, 20 May 2005 13:32:39 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.3/8.13.1/Submit) id j4KHWaGa097540; Fri, 20 May 2005 13:32:36 -0400 (EDT) (envelope-from green) Date: Fri, 20 May 2005 13:32:36 -0400 From: Brian Fundakowski Feldman To: Scott Long Message-ID: <20050520173236.GG1201@green.homeunix.org> References: <200505201340.36176.hselasky@c2i.net> <20050520151620.GF1201@green.homeunix.org> <428E12B0.9020208@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <428E12B0.9020208@samsco.org> User-Agent: Mutt/1.5.6i cc: hackers@freebsd.org cc: Hans Petter Selasky Subject: Re: problems with new the "contigmalloc" routine X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2005 17:32:40 -0000 On Fri, May 20, 2005 at 10:39:12AM -0600, Scott Long wrote: > Brian Fundakowski Feldman wrote: > > >On Fri, May 20, 2005 at 01:40:35PM +0200, Hans Petter Selasky wrote: > > > >>Hi, > >> > >>I just hit some problems with the new "contigmalloc()" routine in > >>FreeBSD-6-current, which is used by "bus_dmamem_alloc()". > >> > >>Firstly it locks Giant, which cause locking order reversals when > >>allocating memory from certain contexts. Secondly it sleeps even if flag > >>M_NOWAIT is passed. Thirdly it does not support flag M_ZERO. > > > > > >Read the documentation. It supports M_ZERO just fine, and it does _not_ > >support M_NOWAIT. > > > > > >>Can someone explain why these changes have been made? > > > > > >Changes? > > > > > >>Why doesn't "contigmalloc()" give a warning when an invalid flag is > >>passed? > > > > > >The kernel would be significantly larger and almost certainly slower > >if it were to double-check that everywhere any bit fields are used > >that flags that are not defined to have any behavior are unset. > > > > > >>Are these bugs in "contigmalloc()"? > > > > > >No. > > > > > >>Or does the code using "contigmalloc()" have to be changed? > > > > > >Yes. The i386 bus_dmamem_alloc(), for example, calls it with M_NOWAIT > >which is not a valid flag. The contigmalloc(9) page is not entirely > >truthful about the fact that it doesn't sleep at all -- it calls those > >routines which can. They can both be documented to require no locks > >to be held when being called, except for M_NOWAIT specifically in the > >one-page-or-less allocation case. > > > > The amount of colateral damage that has been inflicted on > bus_dmamem_alloc by your changes to contigmalloc is truly impressive. > Since I've spent the better part of 8 months cleaning it up, please > let me know what else needs to be done so that there are no more > surprises. And no, this is not my happy face. 1. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/vm/vm_contig.c.diff?r1=1.34&r2=1.41&f=h 2. Notice the lack of semantical changes. 3. Notice that M_ZERO does the same thing as ever. 4. Notice that the same goes for M_WAITOK/M_NOWAIT: ignored for anything that needs more than one page. 5. Negative points for Hans for posting corrupt backtraces and making me go through a lot more work than should be necessary. 6. Negative points to Hans for posting backtraces to an obviously- molested tree (src/sys/dev/usb2/_*?!?). 7. Negative points to Scott for attempting to imply that for some reason it's okay to call contigmalloc(9) in contexts that it has never been okay to call it in. 8. http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2003-11/1488.html 9. Negative points to Scott for failure to spend a couple minutes of research and find out these are known bugs. 10. http://lists.freebsd.org/pipermail/freebsd-current/2005-January/045105.html 11. Negative points to Scott for failure to document system semantics when it is obvious they should have been clarified according to Scott's own notes on the matter. 12. Mega positive points to Hans for actually asking the right questions. 13. Go fix or document the brokenness in busdma, or implement the features in contigmalloc(9) that were imagined to exist. Out. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-hackers@FreeBSD.ORG Fri May 20 19:11:33 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A691F16A4CE; Fri, 20 May 2005 19:11:33 +0000 (GMT) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D1DB43D97; Fri, 20 May 2005 19:11:32 +0000 (GMT) (envelope-from sean-freebsd@farley.org) Received: from thor.farley.org (thor.farley.org [IPv6:2001:470:1f01:290:1::5]) by mail.farley.org (8.13.1/8.13.1) with ESMTP id j4KJBUFK037902; Fri, 20 May 2005 14:11:30 -0500 (CDT) (envelope-from sean-freebsd@farley.org) Date: Fri, 20 May 2005 14:11:45 -0500 (CDT) From: =?ISO-8859-1?Q?Se=E1n_C=2E_Farley?= To: freebsd-hackers@freebsd.org Message-ID: <20050520135436.H43006@thor.farley.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-116671042-1116614953=:42991" Content-ID: <20050520140119.A43006@thor.farley.org> cc: davidxu@freebsd.org Subject: sigsuspend() and nanosleep() bugs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2005 19:11:33 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-116671042-1116614953=:42991 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1; FORMAT=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: <20050520135441.D43006@thor.farley.org> I have been having problems finding a bug (gnu/77818[1]) when running gdb with any program from zsh. This is when a variable is set within =2Ezshrc from a back-tick command. In my search to find the actual bug I did run into kern/80130[2] since my source tree was dated one day before the fix. Argh! :) Unfortunately, it was not my bug. Here is my last post to gnu/77818: I am using 5.4-STABLE with sources from May 15th's: FreeBSD thor.farley.org 5.4-STABLE FreeBSD 5.4-STABLE #0: Sun May 15 01:46:56 CDT 2005 root@thor.farley.org:/usr/obj/usr/src/sys/THOR i386 I have a new test program[1] that I think shows the problem. My previous program actually showed another bug that has since been fixed. Actually, it shows two problems. When run within the debugger (SHELL=3D/bin/sh gdb a.out), the parent will be stuck waiting for a signal it will never receive in sigsuspend(). The other problem is that nanosleep() is exiting immediately with a return of zero (no error) although the time to sleep has not passed. To see it do this, remove the BROKEN_NANOSLEEP_WITHIN_GDB definition at the top of the program and recompile. Does anyone else see the same problems from running my test program (parent.c)? I should probably open another PR on the nanosleep(). Thank you for any help. Se=E1n P.S. David, I am unable to send you e-mails directly since there is a filter at your server that complains about having more than 4 "Received" headers in the e-mail. 1. http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dgnu/77818 2. http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/80130 3. http://www.farley.org/freebsd/tmp/parent.c --=20 sean-freebsd@farley.org --0-116671042-1116614953=:42991-- From owner-freebsd-hackers@FreeBSD.ORG Fri May 20 19:50:53 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 76DE716A4CE; Fri, 20 May 2005 19:50:53 +0000 (GMT) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9677C43D39; Fri, 20 May 2005 19:50:50 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: Y1QAsIk9O44SO+J/q9KNyQ== Received: from mp-217-198-20.daxnet.no ([193.217.198.20] verified) by mailfe07.swip.net (CommuniGate Pro SMTP 4.3c5) with ESMTP id 174860987; Fri, 20 May 2005 21:50:48 +0200 From: Hans Petter Selasky To: Brian Fundakowski Feldman Date: Fri, 20 May 2005 21:51:34 +0200 User-Agent: KMail/1.7 References: <200505201340.36176.hselasky@c2i.net> <428E12B0.9020208@samsco.org> <20050520173236.GG1201@green.homeunix.org> In-Reply-To: <20050520173236.GG1201@green.homeunix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505202151.35831.hselasky@c2i.net> cc: Scott Long cc: hackers@freebsd.org Subject: Re: problems with new the "contigmalloc" routine X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: hselasky@c2i.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2005 19:50:53 -0000 On Friday 20 May 2005 19:32, Brian Fundakowski Feldman wrote: > On Fri, May 20, 2005 at 10:39:12AM -0600, Scott Long wrote: > > Brian Fundakowski Feldman wrote: > > >On Fri, May 20, 2005 at 01:40:35PM +0200, Hans Petter Selasky wrote: > > >>Hi, > > >> > > >>I just hit some problems with the new "contigmalloc()" routine in > > >>FreeBSD-6-current, which is used by "bus_dmamem_alloc()". > > >> > > >>Firstly it locks Giant, which cause locking order reversals when > > >>allocating memory from certain contexts. Secondly it sleeps even if > > >> flag M_NOWAIT is passed. Thirdly it does not support flag M_ZERO. > > > > > >Read the documentation. It supports M_ZERO just fine, and it does _not_ > > >support M_NOWAIT. OK, the M_ZERO support has been there for a while. Maybe it was before M_ZERO support was added, but I remember I used "contigmalloc()" to allocate memory and got dirty pages. Mostly the pages were zeroed, but suddently not, and I had to use bzero. How much has the zeroing mechanism been tested? > > > > > >>Can someone explain why these changes have been made? > > > > > >Changes? Maybe a WITNESS_WARN() was added that wasn't there before. At least it didn't complain earlier. > > > > > >>Why doesn't "contigmalloc()" give a warning when an invalid flag is > > >>passed? > > > > > >The kernel would be significantly larger and almost certainly slower > > >if it were to double-check that everywhere any bit fields are used > > >that flags that are not defined to have any behavior are unset. > > > It might be a pitfall when porting software. Suddenly a flag does not work like expected, undermining the logic of the software. Or what if someone passes the wrong enum like "BUS_DMA_ZERO" instead of "M_ZERO". Isn't there any KASSERT_WARN(!(mflags & (~(M_XXX)))) ? > > >>Are these bugs in "contigmalloc()"? > > > > > >No. > > > > > >>Or does the code using "contigmalloc()" have to be changed? > > > > > >Yes. The i386 bus_dmamem_alloc(), for example, calls it with M_NOWAIT > > >which is not a valid flag. The contigmalloc(9) page is not entirely > > >truthful about the fact that it doesn't sleep at all -- it calls those > > >routines which can. They can both be documented to require no locks > > >to be held when being called, except for M_NOWAIT specifically in the > > >one-page-or-less allocation case. > > > > The amount of colateral damage that has been inflicted on > > bus_dmamem_alloc by your changes to contigmalloc is truly impressive. > > Since I've spent the better part of 8 months cleaning it up, please > > let me know what else needs to be done so that there are no more > > surprises. And no, this is not my happy face. > > 1. > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/vm/vm_contig.c.diff?r1=1.34&r >2=1.41&f=h 2. Notice the lack of semantical changes. > 3. Notice that M_ZERO does the same thing as ever. > 4. Notice that the same goes for M_WAITOK/M_NOWAIT: ignored for anything > that needs more than one page. > 5. Negative points for Hans for posting corrupt backtraces and making > me go through a lot more work than should be necessary. > 6. Negative points to Hans for posting backtraces to an obviously- > molested tree (src/sys/dev/usb2/_*?!?). Sorry about that, but I've got my own USB driver located in /sys/dev/usb2, but the top of the backtrace should be right. > 7. Negative points to Scott for attempting to imply that for some > reason it's okay to call contigmalloc(9) in contexts that it has > never been okay to call it in. > 8. > http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2003-11/1488.html > 9. Negative points to Scott for failure to spend a couple minutes of > research and find out these are known bugs. > 10. > http://lists.freebsd.org/pipermail/freebsd-current/2005-January/045105.html > 11. Negative points to Scott for failure to document system semantics when > it is obvious they should have been clarified according to Scott's own > notes on the matter. > 12. Mega positive points to Hans for actually asking the right questions. > 13. Go fix or document the brokenness in busdma, or implement the features > in contigmalloc(9) that were imagined to exist. > Well, the problem with blocking behaviour is that processes sleeping needs to be waited for: some_read(): ============ lock(); in_read = 1; unlock(); data = contigmalloc(...); lock(); if(detaching) { detaching = 0; wakeup(&detaching); goto done; } hw_queue(data); msleep(data); if(detaching) { detaching = 0; wakeup(&detaching); goto done; } unlock(); uiomove(data); lock(); if(detaching) { detaching = 0; wakeup(&detaching); goto done; } done: in_read = 0; unlock(); some_detach(): ============== lock(); if(in_read) { wakeup(data); detaching = 1; msleep(&detaching); } unlock(); It would be very nice if all memory allocation functions and "uiomove()" could support non-blocking mode, for example by passing a flag. If you look at device drivers like (/sys/dev/usb/ugen.c) you will see that the ones that wrote it didn't expect "uiomove" to sleep. And "uiomove" does not warn because it is called from a Giant locked context. I think you will find the same situation with "bus_dmamem_alloc()", where "BUS_DMA_NOWAIT" is passed as an argument because the code does not handle it when the call sleeps. Non-blocking mode has got to be supported. Else you get a nightmare rewriting the code to support blocking mode. Can anyone explain why "uiomove()" has to sleep, and why there is no non-blocking "uiomove()"? Will M_NOWAIT support will be added to "contigmalloc()"? --HPS From owner-freebsd-hackers@FreeBSD.ORG Fri May 20 21:34:44 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C051216A4CE; Fri, 20 May 2005 21:34:44 +0000 (GMT) Received: from mail14.syd.optusnet.com.au (mail14.syd.optusnet.com.au [211.29.132.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8183A43D8A; Fri, 20 May 2005 21:34:43 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j4KLYTXn003395 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 21 May 2005 07:34:30 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j4KLYTRx008997; Sat, 21 May 2005 07:34:29 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j4KLYSCJ008996; Sat, 21 May 2005 07:34:28 +1000 (EST) (envelope-from pjeremy) Date: Sat, 21 May 2005 07:34:27 +1000 From: Peter Jeremy To: Brian Fundakowski Feldman Message-ID: <20050520213427.GH2129@cirb503493.alcatel.com.au> References: <200505201340.36176.hselasky@c2i.net> <20050520151620.GF1201@green.homeunix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050520151620.GF1201@green.homeunix.org> User-Agent: Mutt/1.4.2i cc: hackers@freebsd.org cc: Hans Petter Selasky Subject: Re: problems with new the "contigmalloc" routine X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2005 21:34:45 -0000 On Fri, 2005-May-20 11:16:20 -0400, Brian Fundakowski Feldman wrote: >On Fri, May 20, 2005 at 01:40:35PM +0200, Hans Petter Selasky wrote: >> I just hit some problems with the new "contigmalloc()" routine in >> FreeBSD-6-current, which is used by "bus_dmamem_alloc()". I found the problem in 4.x at the beginning of the year and worked out that it was still present in 6-current at that time: http://lists.freebsd.org/pipermail/freebsd-stable/2005-January/010979.html (which has a followup in -current which you noted later). >> Firstly it locks Giant, which cause locking order reversals when allocating >> memory from certain contexts. Secondly it sleeps even if flag M_NOWAIT is >> passed. Thirdly it does not support flag M_ZERO. > >Read the documentation. It supports M_ZERO just fine, and it does _not_ >support M_NOWAIT. I agree that M_NOWAIT is not documented but which part of the following extract fron contigmalloc(9) allows contigmalloc() to sleep? The contigmalloc() function does not sleep waiting for memory resources to be freed up, but instead scans available physical memory a small num- ber of times for a suitably sized free address range before giving up. >> Why doesn't "contigmalloc()" give a warning when an invalid flag is passed? > >The kernel would be significantly larger and almost certainly slower >if it were to double-check that everywhere any bit fields are used >that flags that are not defined to have any behavior are unset. We have lots of other checks (eg WITNESS) which are very space and time intensive. I think it would make a lot of sense to (optionally) more extensively validate function arguments and return values in assert()-style constructs. These assert()s should be written based on the documentation, not the code. (I can't remember what this programming style is called). Validating semantics (lock X should or should not be held and sleeping is/is not allowed) is more difficult but we have code that does some of this. >> Are these bugs in "contigmalloc()"? > >No. I would dispute this. contigmalloc() does not comply with its documentation and kernel developers should be able to use kernel internal APIs as they are documented. They should not need to audit the functions they are calling to verify that they behave as documented. In this particular case, it appears that contigmalloc() (and its predecessor, vm_page_alloc_contig()) were always able to sleep so this would appear to be a bug in the man page, rather than the code. >> Or does the code using "contigmalloc()" have to be changed? > >Yes. The i386 bus_dmamem_alloc(), for example, calls it with M_NOWAIT >which is not a valid flag. Agreed. > The contigmalloc(9) page is not entirely >truthful about the fact that it doesn't sleep at all -- it calls those >routines which can. If I call a function which states "this function never sleeps", I expect that my execution thread will return from the call without sleeping. I do not think it is reasonable for this statement to be interpreted as "this function doesn't sleep but can call other functions that do". I agree that you did not break contigmalloc() but since you are are working on contigmalloc() and are aware that the documentation is wrong, you might at least fix the documentation. -- Peter Jeremy From owner-freebsd-hackers@FreeBSD.ORG Fri May 20 21:42:11 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4832616A4CE for ; Fri, 20 May 2005 21:42:11 +0000 (GMT) Received: from pun.isi.edu (pun.isi.edu [128.9.160.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC4A443D91 for ; Fri, 20 May 2005 21:42:10 +0000 (GMT) (envelope-from faber@pun.isi.edu) Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.13.3/8.13.1) with ESMTP id j4KLgAHe003207 for ; Fri, 20 May 2005 14:42:10 -0700 (PDT) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.13.3/8.13.1/Submit) id j4KLgARF003206 for freebsd-hackers@freebsd.org; Fri, 20 May 2005 14:42:10 -0700 (PDT) (envelope-from faber) Date: Fri, 20 May 2005 14:42:10 -0700 From: Ted Faber To: freebsd-hackers@freebsd.org Message-ID: <20050520214210.GG1318@pun.isi.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5vjQsMS/9MbKYGLq" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber Subject: -current deadlock w/debugging pics X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2005 21:42:11 -0000 --5vjQsMS/9MbKYGLq Content-Type: multipart/mixed; boundary="3xoW37o/FfUZJwQG" Content-Disposition: inline --3xoW37o/FfUZJwQG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi. I've been experiencing a solid lockup on -current a couple times a day to the point where I can't get a crash dump - even by triggering a panic from the debugger. I think processes are deadlocking and more and more get into the deadlock until the machine is unusable. A common situation is that the screensaver is running but keyboard input is ignored. Sometimes I can get to the debugger, sometimes not. In any case, I really don't know what to look for there and the lockups aren't easily triggered. I've run with WITNESS and INVARIANTS on, but seen no panic or output. (The run below was with the debugger but w/o WITNESS/INVARIANTS) The last lockup I had, did a ps from the debugger and took pictures of the screen. Pics are avaliable from http://www.isi.edu/~faber/tmp/deadlock/DSCN04{75,76,77,78,79,80,81,82}.JPG They're legible, but not beautiful. I've included a kernel config and I can give you a verbose boot on request. Does this help anyone find the problem? What should I take pictures of next time to help? Thanks in advance. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG --3xoW37o/FfUZJwQG Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=PUN # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.420 2004/11/02 20:57:19 andre Exp $ machine i386 cpu I486_CPU cpu I586_CPU cpu I686_CPU ident PUN options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options GEOM_GPT # GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. # Debugging for use in -current options KDB # Enable kernel debugger support. options DDB # Support DDB. options GDB # Support remote GDB. #options INVARIANTS # Enable calls of extra sanity checking #options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS #options WITNESS # Enable checks to detect deadlocks and cycles #options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed # Bus support. Do not remove isa, even if you have no isa slots device isa device eisa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives options ATA_STATIC_ID # Static device numbering # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # Floating point support - do not disable. device npx # Add suspend/resume support for the i8254. device pmtimer # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device ppi # Parallel port interface device # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! #device miibus # MII bus support #device dc # DEC/Intel 21143 and various workalikes # Pseudo devices. device loop # Network loopback device mem # Memory and kernel memory devices device io # I/O device device random # Entropy device device ether # Ethernet support device sl # Kernel SLIP device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device usb # USB Bus (required) device ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer device ums # Mouse --3xoW37o/FfUZJwQG-- --5vjQsMS/9MbKYGLq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCjlmyaUz3f+Zf+XsRAsG6AKD2W0n79EtgE5BaDmYO/UBqK0UWjACffCy1 LqPByZZqlB7Dn6ubMdtJ0fk= =6jyH -----END PGP SIGNATURE----- --5vjQsMS/9MbKYGLq-- From owner-freebsd-hackers@FreeBSD.ORG Fri May 20 22:47:30 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A66DC16A4CF for ; Fri, 20 May 2005 22:47:30 +0000 (GMT) Received: from enterprise4.noxa.de (enterprise.noxa.de [212.60.197.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8BDF943D49 for ; Fri, 20 May 2005 22:47:29 +0000 (GMT) (envelope-from arundel@h3c.de) Received: (qmail 21260 invoked from network); 21 May 2005 00:47:27 +0200 Received: from p508fb9b4.dip.t-dialin.net (HELO localhost.skatecity) (80.143.185.180) by enterprise.noxa.de with AES256-SHA encrypted SMTP; 21 May 2005 00:47:27 +0200 Received: from localhost.skatecity (nobody@localhost.skatecity [127.0.0.1]) by localhost.skatecity (8.13.3/8.13.3) with ESMTP id j4KMlQrB008017 for ; Sat, 21 May 2005 00:47:26 +0200 (CEST) (envelope-from arundel@localhost.skatecity) Received: (from arundel@localhost) by localhost.skatecity (8.13.3/8.13.3/Submit) id j4KMlQJh008016 for freebsd-hackers@freebsd.org; Sat, 21 May 2005 00:47:26 +0200 (CEST) (envelope-from arundel) From: alexander Date: Sat, 21 May 2005 00:47:26 +0200 To: freebsd-hackers@freebsd.org Message-ID: <20050520224726.GA7951@skatecity> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Looking for ANSI/VT100 code replacement. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2005 22:47:30 -0000 I'd like to port an application that was written in x86 assembly for Linux. So far all I had to do is change the Linux calling convention (registers) to Posix style (stack). However at one point this application outputs 5 characters to stdout (using syscall write and fd=1). These 5 characters however are then being deleted and overwritten again. The application uses VT100 codes to do this. First it moves the cursor to the left 5 times then it deletes everything from the end of the line to the current cursor position. However this slows down the whole application. That's why I'd like to replace that code with something faster. I've tried using lseek in combination with the fd=1 (stdout) and a negative byte offset, but that didn't really work. Is there a way to do this by only using syscalls? Under C/C++ I'd use fprintf or ncurses, but I'd like to limit the application to pure assembly language and a few syscalls. Cheers. From owner-freebsd-hackers@FreeBSD.ORG Fri May 20 22:49:45 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D651016A4CE for ; Fri, 20 May 2005 22:49:45 +0000 (GMT) Received: from mail16.syd.optusnet.com.au (mail16.syd.optusnet.com.au [211.29.132.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 141D643D45 for ; Fri, 20 May 2005 22:49:45 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j4KMnTFR022496 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 21 May 2005 08:49:32 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j4KMnTRx009064; Sat, 21 May 2005 08:49:29 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j4KMnTfp009063; Sat, 21 May 2005 08:49:29 +1000 (EST) (envelope-from pjeremy) Date: Sat, 21 May 2005 08:49:28 +1000 From: Peter Jeremy To: Hans Petter Selasky Message-ID: <20050520224928.GI2129@cirb503493.alcatel.com.au> References: <200505201340.36176.hselasky@c2i.net> <428E12B0.9020208@samsco.org> <20050520173236.GG1201@green.homeunix.org> <200505202151.35831.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200505202151.35831.hselasky@c2i.net> User-Agent: Mutt/1.4.2i cc: hackers@freebsd.org Subject: Re: problems with new the "contigmalloc" routine X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2005 22:49:46 -0000 On Fri, 2005-May-20 21:51:34 +0200, Hans Petter Selasky wrote: >Non-blocking mode has got to be supported. Else you get a nightmare rewriting >the code to support blocking mode. Your code either has to block somewhere or fail. contigmalloc() only blocks if it couldn't satisfy the request immediately. If it returns to your code, you still have the problem of needing the memory and not being able to allocate it without blocking. >Can anyone explain why "uiomove()" has to sleep, and why there is no >non-blocking "uiomove()"? As far as I can see, uiomove() only sleeps if it is asked to do a kernel<->userland move that takes more than twice a scheduler quantum. As long as you don't uiomove() ridiculous amounts of data, it should never sleep. >Will M_NOWAIT support will be added to "contigmalloc()"? When someone writes the code to do it. It's non-trivial to do properly because the blocking occurs several levels down from contigmalloc() in routines that themselves don't support M_NOWAIT. If it's that important to you, maybe you need to write the code :-). -- Peter Jeremy From owner-freebsd-hackers@FreeBSD.ORG Fri May 20 22:56:32 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6433D16A4CE for ; Fri, 20 May 2005 22:56:32 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id D493043D6D for ; Fri, 20 May 2005 22:56:31 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.1/8.13.1) with ESMTP id j4KMuFN9055802; Fri, 20 May 2005 15:56:19 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200505202256.j4KMuFN9055802@gw.catspoiler.org> Date: Fri, 20 May 2005 15:56:15 -0700 (PDT) From: Don Lewis To: PeterJeremy@optushome.com.au In-Reply-To: <20050520224928.GI2129@cirb503493.alcatel.com.au> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: hackers@FreeBSD.org cc: hselasky@c2i.net Subject: Re: problems with new the "contigmalloc" routine X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2005 22:56:32 -0000 On 21 May, Peter Jeremy wrote: > On Fri, 2005-May-20 21:51:34 +0200, Hans Petter Selasky wrote: >>Can anyone explain why "uiomove()" has to sleep, and why there is no >>non-blocking "uiomove()"? > > As far as I can see, uiomove() only sleeps if it is asked to do a > kernel<->userland move that takes more than twice a scheduler quantum. > As long as you don't uiomove() ridiculous amounts of data, it should > never sleep. It can also sleep if it stumbles across a userland page that isn't resident. When this happens, it will sleep until the page is retrieved from swap. From owner-freebsd-hackers@FreeBSD.ORG Fri May 20 23:08:46 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F113D16A4CE for ; Fri, 20 May 2005 23:08:46 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B5C343D83 for ; Fri, 20 May 2005 23:08:46 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.3) id j4KN8kJj092688; Fri, 20 May 2005 18:08:46 -0500 (CDT) (envelope-from dan) Date: Fri, 20 May 2005 18:08:45 -0500 From: Dan Nelson To: alexander Message-ID: <20050520230845.GC51092@dan.emsphone.com> References: <20050520224726.GA7951@skatecity> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050520224726.GA7951@skatecity> X-OS: FreeBSD 5.4-STABLE X-message-flag: Outlook Error User-Agent: Mutt/1.5.9i cc: freebsd-hackers@freebsd.org Subject: Re: Looking for ANSI/VT100 code replacement. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2005 23:08:47 -0000 In the last episode (May 21), alexander said: > I'd like to port an application that was written in x86 assembly for > Linux. So far all I had to do is change the Linux calling convention > (registers) to Posix style (stack). > > However at one point this application outputs 5 characters to stdout > (using syscall write and fd=1). These 5 characters however are then > being deleted and overwritten again. The application uses VT100 codes > to do this. > > First it moves the cursor to the left 5 times then it deletes > everything from the end of the line to the current cursor position. > > However this slows down the whole application. That's why I'd like to > replace that code with something faster. How often are you doing this? I wrote a quick microbenchmark and my pIII-900 box can do 80000 writes() per second of "\e[5D\e[Kabcde". I don't think that's your bottleneck. If it is, the usual solution is to not do a write on every iteration. You've got a (maximum) 100hz screen refresh rate anyhow, so doing more than 100 updates per second won't do you any good. Even 10 is probably more than you need. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Sat May 21 01:51:10 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C530416A4CF for ; Sat, 21 May 2005 01:51:10 +0000 (GMT) Received: from enterprise4.noxa.de (enterprise.noxa.de [212.60.197.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3713643D6D for ; Sat, 21 May 2005 01:51:09 +0000 (GMT) (envelope-from arundel@h3c.de) Received: (qmail 9733 invoked from network); 21 May 2005 03:51:07 +0200 Received: from p508fb9b4.dip.t-dialin.net (HELO localhost.skatecity) (80.143.185.180) by enterprise.noxa.de with AES256-SHA encrypted SMTP; 21 May 2005 03:51:07 +0200 Received: from localhost.skatecity (nobody@localhost.skatecity [127.0.0.1]) by localhost.skatecity (8.13.3/8.13.3) with ESMTP id j4L1p54M009234 for ; Sat, 21 May 2005 03:51:05 +0200 (CEST) (envelope-from arundel@localhost.skatecity) Received: (from arundel@localhost) by localhost.skatecity (8.13.3/8.13.3/Submit) id j4L1p5WS009233; Sat, 21 May 2005 03:51:05 +0200 (CEST) (envelope-from arundel) From: alexander Date: Sat, 21 May 2005 03:51:05 +0200 To: freebsd-hackers@freebsd.org, freebsd-hackers@freebsd.org Message-ID: <20050521015105.GA9063@skatecity> References: <20050520224726.GA7951@skatecity> <20050520230845.GC51092@dan.emsphone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050520230845.GC51092@dan.emsphone.com> Subject: Re: Looking for ANSI/VT100 code replacement. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2005 01:51:10 -0000 On Fri May 20 05, Dan Nelson wrote: > > How often are you doing this? I wrote a quick microbenchmark and my > pIII-900 box can do 80000 writes() per second of "\e[5D\e[Kabcde". I > don't think that's your bottleneck. If it is, the usual solution is to > not do a write on every iteration. You've got a (maximum) 100hz screen > refresh rate anyhow, so doing more than 100 updates per second won't do > you any good. Even 10 is probably more than you need. > > -- > Dan Nelson > dnelson@allantgroup.com Ohh...sorry for not telling you this. Yes. The app works alright when executed from the console. But my problem is with xterm or Eterm. They don't handle VT100 very well. I've added a nanosleep after each VT100 output but that didn't solve the issue. In fact Eterm or xterm might not update the value for as long as 5-8 seconds. I tested burncd's code and it uses fprintf to update the bytes it sends. And that works perfectly under Eterm and xterm. The app needs to handle at least 40000h updates in 10 seconds. But as you said I can break that down to ~ 100 updates per second. However I don't think that that's going to do much of a different with the delays I'm experiencing under Eterm/xterm. The app is used to upload data to another device. Under the console the upload time is ~ 11.5 seconds. Under Eterm it is ~ 25 seconds. That's why I really want to get rid of the VT100 stuff. The nanosleep delay I'm using is 0,00050000. I also disabled all the nanosleep syscalls, but Eterm/xterm still lags awfully. Plus the cursor jumps forth and back. Cheers. From owner-freebsd-hackers@FreeBSD.ORG Sat May 21 02:04:21 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A6AC816A4D1 for ; Sat, 21 May 2005 02:04:21 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7831543D9D for ; Sat, 21 May 2005 02:04:20 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.3) id j4L24Kb9047577; Fri, 20 May 2005 21:04:20 -0500 (CDT) (envelope-from dan) Date: Fri, 20 May 2005 21:04:19 -0500 From: Dan Nelson To: alexander Message-ID: <20050521020419.GD51092@dan.emsphone.com> References: <20050520224726.GA7951@skatecity> <20050520230845.GC51092@dan.emsphone.com> <20050521015105.GA9063@skatecity> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050521015105.GA9063@skatecity> X-OS: FreeBSD 5.4-STABLE X-message-flag: Outlook Error User-Agent: Mutt/1.5.9i cc: freebsd-hackers@freebsd.org Subject: Re: Looking for ANSI/VT100 code replacement. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2005 02:04:21 -0000 In the last episode (May 21), alexander said: > Ohh...sorry for not telling you this. Yes. The app works alright when > executed from the console. But my problem is with xterm or Eterm. > They don't handle VT100 very well. I've added a nanosleep after each > VT100 output but that didn't solve the issue. In fact Eterm or xterm > might not update the value for as long as 5-8 seconds. I tested > burncd's code and it uses fprintf to update the bytes it sends. And > that works perfectly under Eterm and xterm. 5 seconds? Do you have heavy packet loss between the server and your xterm? > The app needs to handle at least 40000h updates in 10 seconds. But as > you said I can break that down to ~ 100 updates per second. However I > don't think that that's going to do much of a different with the > delays I'm experiencing under Eterm/xterm. Cut it down to 1 or 2 updates per second, then. If this is a progress indicator, you don't need more than that. If you don't want to spend time getting timestamps, just print your counter every 64k updates. that'll give you a little over 1 update per second. > The app is used to upload data to another device. Under the console > the upload time is ~ 11.5 seconds. Under Eterm it is ~ 25 seconds. > That's why I really want to get rid of the VT100 stuff. > > The nanosleep delay I'm using is 0,00050000. I also disabled all the > nanosleep syscalls, but Eterm/xterm still lags awfully. Plus the > cursor jumps forth and back. If you're worried about running time, adding sleeps is definitely not the right way to speed it up :) -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Sat May 21 03:31:15 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C59516A4CE; Sat, 21 May 2005 03:31:15 +0000 (GMT) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83AFD43D8D; Sat, 21 May 2005 03:31:14 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j4L3V6ZL004859 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 21 May 2005 13:31:07 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j4L3V6Rx009323; Sat, 21 May 2005 13:31:06 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j4L3V6Bu009322; Sat, 21 May 2005 13:31:06 +1000 (EST) (envelope-from pjeremy) Date: Sat, 21 May 2005 13:31:06 +1000 From: Peter Jeremy To: Brian Fundakowski Feldman Message-ID: <20050521033106.GL2129@cirb503493.alcatel.com.au> References: <200505201340.36176.hselasky@c2i.net> <20050520151620.GF1201@green.homeunix.org> <20050520213427.GH2129@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050520213427.GH2129@cirb503493.alcatel.com.au> User-Agent: Mutt/1.4.2i cc: hackers@freebsd.org cc: Hans Petter Selasky Subject: Re: problems with new the "contigmalloc" routine X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2005 03:31:15 -0000 On Sat, 2005-May-21 07:34:27 +1000, I wrote: >I agree that you did not break contigmalloc() but since you are are >working on contigmalloc() and are aware that the documentation is >wrong, you might at least fix the documentation. Having had a closer look at the CVS logs, several people have fiddled with contigmalloc() since Brian last touched it and he does not appear to be actively working on it. I'd therefore like to apologise to Brian for this comment. -- Peter Jeremy From owner-freebsd-hackers@FreeBSD.ORG Sat May 21 03:43:11 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1EDD716A4CE; Sat, 21 May 2005 03:43:11 +0000 (GMT) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 550A843D9D; Sat, 21 May 2005 03:43:10 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j4L3h3l6001683 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 21 May 2005 13:43:04 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j4L3h3Rx009340; Sat, 21 May 2005 13:43:03 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j4L3h3Pd009339; Sat, 21 May 2005 13:43:03 +1000 (EST) (envelope-from pjeremy) Date: Sat, 21 May 2005 13:43:03 +1000 From: Peter Jeremy To: Don Lewis Message-ID: <20050521034303.GM2129@cirb503493.alcatel.com.au> References: <20050520224928.GI2129@cirb503493.alcatel.com.au> <200505202256.j4KMuFN9055802@gw.catspoiler.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200505202256.j4KMuFN9055802@gw.catspoiler.org> User-Agent: Mutt/1.4.2i cc: hackers@freebsd.org cc: hselasky@c2i.net Subject: Re: problems with new the "contigmalloc" routine X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2005 03:43:11 -0000 On Fri, 2005-May-20 15:56:15 -0700, Don Lewis wrote: >On 21 May, Peter Jeremy wrote: >> On Fri, 2005-May-20 21:51:34 +0200, Hans Petter Selasky wrote: > >>>Can anyone explain why "uiomove()" has to sleep, and why there is no >>>non-blocking "uiomove()"? >> >> As far as I can see, uiomove() only sleeps if it is asked to do a >> kernel<->userland move that takes more than twice a scheduler quantum. >> As long as you don't uiomove() ridiculous amounts of data, it should >> never sleep. > >It can also sleep if it stumbles across a userland page that isn't >resident. When this happens, it will sleep until the page is retrieved >from swap. Mea culpa. I thought pcb_onfault was invoked in lieu of paging but it's actually invoked after the pager has tried to bring the page in. -- Peter Jeremy From owner-freebsd-hackers@FreeBSD.ORG Sat May 21 05:21:17 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0FF5E16A4CF for ; Sat, 21 May 2005 05:21:17 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24B7043D69 for ; Sat, 21 May 2005 05:21:16 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j4L5K4dk097584; Fri, 20 May 2005 23:20:04 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 20 May 2005 23:20:19 -0600 (MDT) Message-Id: <20050520.232019.24855681.imp@bsdimp.com> To: arundel@h3c.de From: "M. Warner Losh" In-Reply-To: <20050521015105.GA9063@skatecity> References: <20050520224726.GA7951@skatecity> <20050520230845.GC51092@dan.emsphone.com> <20050521015105.GA9063@skatecity> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: Looking for ANSI/VT100 code replacement. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2005 05:21:17 -0000 In message: <20050521015105.GA9063@skatecity> alexander writes: : On Fri May 20 05, Dan Nelson wrote: : > : > How often are you doing this? I wrote a quick microbenchmark and my : > pIII-900 box can do 80000 writes() per second of "\e[5D\e[Kabcde". I : > don't think that's your bottleneck. If it is, the usual solution is to : > not do a write on every iteration. You've got a (maximum) 100hz screen : > refresh rate anyhow, so doing more than 100 updates per second won't do : > you any good. Even 10 is probably more than you need. : > : > -- : > Dan Nelson : > dnelson@allantgroup.com : : Ohh...sorry for not telling you this. Yes. The app works alright when : executed from the console. But my problem is with xterm or Eterm. They don't : handle VT100 very well. I've added a nanosleep after each VT100 output but : that didn't solve the issue. In fact Eterm or xterm might not update the value : for as long as 5-8 seconds. I tested burncd's code and it uses fprintf to : update the bytes it sends. And that works perfectly under Eterm and xterm. Actually, xterm handles VT100 very well. The console does not. The console implements a variant of ANSI that's different from the variant of ANSI that the vt100 did. so if it works on the console, but acts differently in an X term, that's likely due to the differences between the terminal emulation both provide. Maybe the problem isn't one of performance, but one of emulation? Warner From owner-freebsd-hackers@FreeBSD.ORG Sat May 21 08:07:40 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4686E16A4CF for ; Sat, 21 May 2005 08:07:40 +0000 (GMT) Received: from mail24.syd.optusnet.com.au (mail24.syd.optusnet.com.au [211.29.133.165]) by mx1.FreeBSD.org (Postfix) with ESMTP id A74CA43DA5 for ; Sat, 21 May 2005 08:07:27 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j4L87Ofl005736 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 21 May 2005 18:07:25 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j4L87NRx009624; Sat, 21 May 2005 18:07:24 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j4L87NkW009623; Sat, 21 May 2005 18:07:23 +1000 (EST) (envelope-from pjeremy) Date: Sat, 21 May 2005 18:07:23 +1000 From: Peter Jeremy To: alexander Message-ID: <20050521080723.GN2129@cirb503493.alcatel.com.au> References: <20050520224726.GA7951@skatecity> <20050520230845.GC51092@dan.emsphone.com> <20050521015105.GA9063@skatecity> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050521015105.GA9063@skatecity> User-Agent: Mutt/1.4.2i cc: freebsd-hackers@freebsd.org Subject: Re: Looking for ANSI/VT100 code replacement. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2005 08:07:40 -0000 On Sat, 2005-May-21 03:51:05 +0200, alexander wrote: >Ohh...sorry for not telling you this. Yes. The app works alright when >executed from the console. But my problem is with xterm or Eterm. They don't >handle VT100 very well. By default, xterm is a VT102 superset, and the VT102 is a VT100 superset. Unless you are issuing unusual escape sequences, you shouldn't be able to tell the difference. > In fact Eterm or xterm might not update the value >for as long as 5-8 seconds. Out of interest, is the xterm or Eterm client running on the Xserver or a different host? It is possible that updates are being queued between xterm and the Xserver, though I think 5-8 seconds is excessive. >The app is used to upload data to another device. Under the console the upload >time is ~ 11.5 seconds. Under Eterm it is ~ 25 seconds. That's why I really >want to get rid of the VT100 stuff. xterm/Eterm have much more overhead than the console. If you're running on really slow hardware, this might make a difference. >The nanosleep delay I'm using is 0,00050000. Note that the minimum delay is 1 tick (1/HZ). Shorter delays are rounded up (and there might still be a one-tick additional delay). > Plus the cursor jumps forth and back. I would expect that. The cursor is moving back and forth as you write to the xterm. Since the screen refresh rate is much slower than your update rate, you are seeing the cursor in random locations. The easy solution for xterm is to make the cursor invisible ("\e[?25l" and "\e[?25h" to make it visible again). I think you need to give us more details and preferably some sample code to simulate the problem. What is the hardware you are running on? What version of FreeBSD, X11 and xterm/Eterm. -- Peter Jeremy From owner-freebsd-hackers@FreeBSD.ORG Sat May 21 10:49:39 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6A3A216A4CE for ; Sat, 21 May 2005 10:49:39 +0000 (GMT) Received: from web15509.mail.cnb.yahoo.com (web15509.mail.cnb.yahoo.com [202.165.102.38]) by mx1.FreeBSD.org (Postfix) with SMTP id 4983543D9C for ; Sat, 21 May 2005 10:49:38 +0000 (GMT) (envelope-from shiner_chen@yahoo.com.cn) Message-ID: <20050521104937.70622.qmail@web15509.mail.cnb.yahoo.com> Received: from [61.187.12.146] by web15509.mail.cnb.yahoo.com via HTTP; Sat, 21 May 2005 18:49:36 CST Date: Sat, 21 May 2005 18:49:36 +0800 (CST) From: shiner chen To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: how to get the status of cpu in kernel? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2005 10:49:39 -0000 In order to implement a dispacthing policy I want to get the status of cpu. I have read the code of top command and i find it get the status of cpu by the function : int sysctlbyname(const char *, void *, size_t *, void *, size_t); I search the code of kernel ,then I consider that i can get the status of cpu through the funciton: int kernel_sysctlbyname(struct thread *td, char *name, void *old, size_t *oldlenp, void *new, size_t newlen, size_t *retval); I try to get the status of cpu by that function ,but it does not work! who can tell me the problem? How do i get the status of cpu? How do i use it if the funcion is right? what's the mean of the function's arguments ? thanks ! shiner_chen May 21th 2005 --------------------------------- Do You Yahoo!? ×¢²áÊÀœçÒ»Á÷Æ·ÖʵÄÑÅ»¢Ãâ·ÑµçÓÊ From owner-freebsd-hackers@FreeBSD.ORG Sat May 21 11:46:22 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 744CE16A4CE for ; Sat, 21 May 2005 11:46:22 +0000 (GMT) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77BB443D98 for ; Sat, 21 May 2005 11:46:21 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1DZSQu-000Iph-35; Sat, 21 May 2005 14:46:20 +0300 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: walter@pelissero.de In-reply-to: Your message of Fri, 20 May 2005 03:05:06 +0200 . Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 21 May 2005 14:46:19 +0300 From: Danny Braniss Message-ID: cc: hackers@freebsd.org Subject: Re: WRAP.1E and geode.c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2005 11:46:22 -0000 you'll have to fiddel with src/sys/i386/i386/geode.c look for bios_string(0xf9000, 0xf9000, "PC Engines WRAP.1C " and you will see why. this patch should work: --- 5.3/src/sys/i386/i386/geode.c Sun Nov 21 16:01:04 2004 +++ 5.4/src/sys/i386/i386/geode.c Wed Jun 16 12:47:07 2004 @@ -144,16 +144,9 @@ printf("Soekris Engineering NET4801 platform\n"); led1b = 20; led1 = led_create(led_func, &led1b, "error"); - } - else { - const u_char *p = bios_string(0xf9000, 0xf9010, "PC Engines", 0); - - if (NULL != p) { - int n = strlen(p); - - if(n > 2 && p[n-2] == '\r') - n -= 2; - printf("%.*s\n", n, p); + } else if (NULL != + bios_string(0xf9000, 0xf9000, "PC Engines WRAP.1C ", 0)) { + printf("PC Engines WRAP.1C platfrom\n"); led1b = -2; led2b = -3; led3b = -18; @@ -167,8 +160,6 @@ led_func(&led1b, 1); } } - } - From owner-freebsd-hackers@FreeBSD.ORG Fri May 20 13:51:23 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 213D916A4CE for ; Fri, 20 May 2005 13:51:23 +0000 (GMT) Received: from gta.com (gta-edge-199-20.gta.com [199.120.225.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 8795F43DD2 for ; Fri, 20 May 2005 13:51:22 +0000 (GMT) (envelope-from lab@gta.com) Received: (qmail 75331 invoked by uid 1000); 20 May 2005 13:44:41 -0000 Date: 20 May 2005 13:44:41 -0000 Message-ID: <20050520134441.75330.qmail@gta.com> From: Larry Baird To: freebsd-hackers@freebsd.org In-Reply-To: <17037.14274.229768.369886@zaphod.home.loc> X-Newsgroups: freebsd.hackers User-Agent: tin/1.5.9-20010723 ("Chord of Souls") (UNIX) (FreeBSD/4.10-RELEASE (i386)) X-Mailman-Approved-At: Sat, 21 May 2005 12:07:51 +0000 cc: "\"Walter C. Pelissero\"" Subject: Re: WRAP.1E and geode.c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2005 13:51:23 -0000 In article <17037.14274.229768.369886@zaphod.home.loc> you wrote: > Reading geode.c it appears (at least to me) that the led devices are > created for the WRAP.1C but not for the WRAP.1E. > > Reading the PC-Engines documentation it looks to me as WRAP.1C and > WRAP1.E were identical when it comes to the LEDs, thus it would be > nice to have the same entries in /dev. > > Anyone with a better understanding of this platform cares to comment > on this? The BIOS id string on the wrap board has changed. Following patch for geode.c should fix the problem. Larry --- geode.c.orig Fri May 20 09:41:06 2005 +++ geode.c Fri May 20 09:42:09 2005 @@ -145,7 +145,8 @@ led1b = 20; led1 = led_create(led_func, &led1b, "error"); } else if (NULL != - bios_string(0xf9000, 0xf9000, "PC Engines WRAP.1C ", 0)) { +#define WRAP_BIOS_SIGNATURE "PC Engines WRAP" + bios_string(0xf9000, 0xf9000, WRAP_BIOS_SIGNATURE, sizeof(WRAP_BIOS_SIGNATURE - 1))) { printf("PC Engines WRAP.1C platfrom\n"); led1b = -2; led2b = -3; -- ------------------------------------------------------------------------ Larry Baird | http://www.gta.com Global Technology Associates, Inc. | Orlando, FL Email: lab@gta.com | TEL 407-380-0220, FAX 407-380-6080 From owner-freebsd-hackers@FreeBSD.ORG Fri May 20 14:46:14 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC51116A4CE for ; Fri, 20 May 2005 14:46:14 +0000 (GMT) Received: from smtp.iesy.net (mta002.iesy.net [81.210.131.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F37143D58 for ; Fri, 20 May 2005 14:46:13 +0000 (GMT) (envelope-from walter.pelissero@iesy.net) Received: from zaphod.home.loc (unknown [81.210.131.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.iesy.net (Postfix) with ESMTP id 5AABDB532; Fri, 20 May 2005 16:46:11 +0200 (CEST) Received: from zaphod.home.loc (localhost [127.0.0.1]) by zaphod.home.loc (8.13.3/8.13.3) with ESMTP id j4KEkARc036673; Fri, 20 May 2005 16:46:10 +0200 (CEST) (envelope-from wcp@zaphod.home.loc) Received: (from wcp@localhost) by zaphod.home.loc (8.13.3/8.13.1/Submit) id j4KEk9nG036670; Fri, 20 May 2005 16:46:09 +0200 (CEST) (envelope-from wcp) From: "Walter C. Pelissero" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17037.63537.511280.172143@zaphod.home.loc> Date: Fri, 20 May 2005 16:46:09 +0200 To: Larry Baird In-Reply-To: <20050520134441.75330.qmail@gta.com> References: <17037.14274.229768.369886@zaphod.home.loc> <20050520134441.75330.qmail@gta.com> X-Mailer: VM 7.19 under Emacs 22.0.50.1 X-Attribution: WP X-For-Spammers: blacklistme@pelissero.de X-MArch-Archive-Date: 2005-05-20 16:46:10 X-MArch-Archive-ID: 2300 X-MArch-Processing-Time: 0.24s X-Mailman-Approved-At: Sat, 21 May 2005 12:07:51 +0000 cc: freebsd-hackers@freebsd.org Subject: Re: WRAP.1E and geode.c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: walter@pelissero.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2005 14:46:14 -0000 Larry Baird writes: > In article <17037.14274.229768.369886@zaphod.home.loc> you wrote: > > Reading geode.c it appears (at least to me) that the led devices are > > created for the WRAP.1C but not for the WRAP.1E. > > > > Reading the PC-Engines documentation it looks to me as WRAP.1C and > > WRAP1.E were identical when it comes to the LEDs, thus it would be > > nice to have the same entries in /dev. > > > > Anyone with a better understanding of this platform cares to comment > > on this? > The BIOS id string on the wrap board has changed. Following patch > for geode.c should fix the problem. > > Larry > > --- geode.c.orig Fri May 20 09:41:06 2005 > +++ geode.c Fri May 20 09:42:09 2005 > @@ -145,7 +145,8 @@ > led1b = 20; > led1 = led_create(led_func, &led1b, "error"); > } else if (NULL != > - bios_string(0xf9000, 0xf9000, "PC Engines WRAP.1C ", 0)) { > +#define WRAP_BIOS_SIGNATURE "PC Engines WRAP" > + bios_string(0xf9000, 0xf9000, WRAP_BIOS_SIGNATURE, sizeof(WRAP_BIOS_SIGNATURE - 1))) { > printf("PC Engines WRAP.1C platfrom\n"); > led1b = -2; > led2b = -3; Are you sure about that? Suspecting my original guessing was wrong, I took the time, while my message was put on hold by the moderator, to make some experiments. I changed the aforementioned string into: "PC Engines WRAP" and then "PC Engines" but no luck. So either the string changed address or it's something totally different from the original. -- walter pelissero http://www.pelissero.de From owner-freebsd-hackers@FreeBSD.ORG Fri May 20 16:04:59 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6029016A4CE for ; Fri, 20 May 2005 16:04:59 +0000 (GMT) Received: from smtp.iesy.net (mta001.iesy.net [81.210.131.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2FBE043D54 for ; Fri, 20 May 2005 16:04:52 +0000 (GMT) (envelope-from walter.pelissero@iesy.net) Received: from zaphod.home.loc (unknown [81.210.131.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.iesy.net (Postfix) with ESMTP id E3D4521F9F; Fri, 20 May 2005 18:04:50 +0200 (CEST) Received: from zaphod.home.loc (localhost [127.0.0.1]) by zaphod.home.loc (8.13.3/8.13.3) with ESMTP id j4KG4oU0045302; Fri, 20 May 2005 18:04:50 +0200 (CEST) (envelope-from wcp@zaphod.home.loc) Received: (from wcp@localhost) by zaphod.home.loc (8.13.3/8.13.1/Submit) id j4KG4nSL045299; Fri, 20 May 2005 18:04:49 +0200 (CEST) (envelope-from wcp) From: "Walter C. Pelissero" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17038.2721.616026.745710@zaphod.home.loc> Date: Fri, 20 May 2005 18:04:49 +0200 To: Larry Baird In-Reply-To: <20050520134441.75330.qmail@gta.com> References: <17037.14274.229768.369886@zaphod.home.loc> <20050520134441.75330.qmail@gta.com> X-Mailer: VM 7.19 under Emacs 22.0.50.1 X-Attribution: WP X-For-Spammers: blacklistme@pelissero.de X-MArch-Archive-Date: 2005-05-20 18:04:50 X-MArch-Archive-ID: 2302 X-MArch-Processing-Time: 0.21s X-Mailman-Approved-At: Sat, 21 May 2005 12:07:51 +0000 cc: freebsd-hackers@freebsd.org Subject: Re: WRAP.1E and geode.c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: walter@pelissero.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2005 16:04:59 -0000 Larry Baird writes: > In article <17037.14274.229768.369886@zaphod.home.loc> you wrote: > > Reading geode.c it appears (at least to me) that the led devices are > > created for the WRAP.1C but not for the WRAP.1E. > > > > Reading the PC-Engines documentation it looks to me as WRAP.1C and > > WRAP1.E were identical when it comes to the LEDs, thus it would be > > nice to have the same entries in /dev. > > > > Anyone with a better understanding of this platform cares to comment > > on this? > The BIOS id string on the wrap board has changed. Following patch > for geode.c should fix the problem. Some more good old trial-and-error activity let me come up with the answer to my problem. The BIOS id string has indeed moved. The following patch makes geode.c play nicely with newer versions of the WARP boards: --- geode.c 16 Jun 2004 09:47:07 -0000 1.5 +++ geode.c 20 May 2005 15:42:28 -0000 @@ -145,8 +145,8 @@ led1b = 20; led1 = led_create(led_func, &led1b, "error"); } else if (NULL != - bios_string(0xf9000, 0xf9000, "PC Engines WRAP.1C ", 0)) { - printf("PC Engines WRAP.1C platfrom\n"); + bios_string(0xf9000, 0xf9010, "PC Engines WRAP", 0)) { + printf("PC Engines WRAP platfrom\n"); led1b = -2; led2b = -3; led3b = -18; If no one has objections I'd file a PR. -- walter pelissero http://www.pelissero.de From owner-freebsd-hackers@FreeBSD.ORG Fri May 20 16:52:23 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B9D9316A4CE for ; Fri, 20 May 2005 16:52:23 +0000 (GMT) Received: from gta.com (gta-edge-199-20.gta.com [199.120.225.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 088B843DC2 for ; Fri, 20 May 2005 16:52:23 +0000 (GMT) (envelope-from lab@gta.com) Received: (qmail 33117 invoked by uid 1000); 20 May 2005 16:52:22 -0000 Date: Fri, 20 May 2005 12:52:22 -0400 From: Larry Baird To: "Walter C. Pelissero" Message-ID: <20050520125222.A31121@gta.com> References: <17037.14274.229768.369886@zaphod.home.loc> <20050520134441.75330.qmail@gta.com> <17037.63537.511280.172143@zaphod.home.loc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <17037.63537.511280.172143@zaphod.home.loc>; from walter@pelissero.de on Fri, May 20, 2005 at 04:46:09PM +0200 X-Mailman-Approved-At: Sat, 21 May 2005 12:07:51 +0000 cc: freebsd-hackers@freebsd.org Subject: Re: WRAP.1E and geode.c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2005 16:52:23 -0000 Walter, > Are you sure about that? Yes and no. I am sure that I have working code. I just realized that when I ported my patch to 5.4 I missed one thing. The following patch should work muxh better for you. (-: Larry --- geode.c.orig Fri May 20 09:41:06 2005 +++ geode.c Fri May 20 12:49:52 2005 @@ -145,7 +145,7 @@ led1b = 20; led1 = led_create(led_func, &led1b, "error"); } else if (NULL != - bios_string(0xf9000, 0xf9000, "PC Engines WRAP.1C ", 0)) { + bios_string(0xf9000, 0xf9100, "PC Engines WRAP", 0)) { printf("PC Engines WRAP.1C platfrom\n"); led1b = -2; led2b = -3; -- ------------------------------------------------------------------------ Larry Baird | http://www.gta.com Global Technology Associates, Inc. | Orlando, FL Email: lab@gta.com | TEL 407-380-0220, FAX 407-380-6080 From owner-freebsd-hackers@FreeBSD.ORG Sat May 21 13:17:18 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FF6E16A4D5 for ; Sat, 21 May 2005 13:17:18 +0000 (GMT) Received: from mail.oltrelinux.com (krisma.oltrelinux.com [194.242.226.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E6A943D83 for ; Sat, 21 May 2005 13:17:11 +0000 (GMT) (envelope-from flag@oltrelinux.com) Received: from southcross.homeunix.org (host153-238.pool8256.interbusiness.it [82.56.238.153]) by mail.oltrelinux.com (Postfix) with ESMTP id 6659811AE4A for ; Sat, 21 May 2005 15:17:06 +0200 (CEST) Received: by southcross.homeunix.org (Postfix, from userid 1001) id 9AD09410E; Sat, 21 May 2005 15:17:21 +0200 (CEST) Date: Sat, 21 May 2005 15:17:21 +0200 From: Paolo Pisati To: FreeBSD_Hackers Message-ID: <20050521131721.GA1823@tin.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at krisma.oltrelinux.com Subject: i915 AGP not supported aka PR kern/80396 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2005 13:17:18 -0000 (i already sent an email to Eric some days ago but i didn't receive any ack so i try here...) can anyone take a look at this? as the comments say, agp still doesn't work... anything i can do to help? Eric? verbose boot: FreeBSD 5.4-RELEASE #0: Sun May 8 10:21:06 UTC 2005 root@harlow.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel "/boot/kernel/kernel" at 0xc0a5a000. Preloaded elf module "/boot/kernel/snd_ich.ko" at 0xc0a5a2e4. Preloaded elf module "/boot/kernel/sound.ko" at 0xc0a5a390. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0a5a43c. Calibrating clock(s) ... i8254 clock: 1193189 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1596012945 Hz CPU: Intel(R) Pentium(R) M processor 1.60GHz (1596.01-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6d8 Stepping = 8 Features=0xafe9fbff real memory = 528297984 (503 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c25000 - 0x000000001eec6fff, 506077184 bytes (123554 pages) avail memory = 507289600 (483 MB) Table 'FACP' at 0x1f7d4c00 Table 'APIC' at 0x1f7d5400 MADT: Found table at 0x1f7d5400 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled MADT: Found CPU APIC ID 1 ACPI ID 1: disabled ACPI APIC Table: bios32: Found BIOS32 Service Directory header at 0xc00ffe80 bios32: Entry = 0xffe90 (c00ffe90) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xbaae pnpbios: Found PnP BIOS data at 0xc00fe2d0 pnpbios: Entry = f0000:e2f4 Rev = 1.0 pnpbios: Event flag at 4b4 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 0 MADT: Found IO APIC ID 1, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 1 ioapic0: Routing external 8259A's -> intpin 0 ioapic0: intpin 0 -> ExtINT (edge, high) ioapic0: intpin 1 -> ISA IRQ 1 (edge, high) ioapic0: intpin 2 -> ISA IRQ 2 (edge, high) ioapic0: intpin 3 -> ISA IRQ 3 (edge, high) ioapic0: intpin 4 -> ISA IRQ 4 (edge, high) ioapic0: intpin 5 -> ISA IRQ 5 (edge, high) ioapic0: intpin 6 -> ISA IRQ 6 (edge, high) ioapic0: intpin 7 -> ISA IRQ 7 (edge, high) ioapic0: intpin 8 -> ISA IRQ 8 (edge, high) ioapic0: intpin 9 -> ISA IRQ 9 (edge, high) ioapic0: intpin 10 -> ISA IRQ 10 (edge, high) ioapic0: intpin 11 -> ISA IRQ 11 (edge, high) ioapic0: intpin 12 -> ISA IRQ 12 (edge, high) ioapic0: intpin 13 -> ISA IRQ 13 (edge, high) ioapic0: intpin 14 -> ISA IRQ 14 (edge, high) ioapic0: intpin 15 -> ISA IRQ 15 (edge, high) ioapic0: intpin 16 -> PCI IRQ 16 (level, low) ioapic0: intpin 17 -> PCI IRQ 17 (level, low) ioapic0: intpin 18 -> PCI IRQ 18 (level, low) ioapic0: intpin 19 -> PCI IRQ 19 (level, low) ioapic0: intpin 20 -> PCI IRQ 20 (level, low) ioapic0: intpin 21 -> PCI IRQ 21 (level, low) ioapic0: intpin 22 -> PCI IRQ 22 (level, low) ioapic0: intpin 23 -> PCI IRQ 23 (level, low) MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 ioapic0: intpin 2 trigger: edge ioapic0: intpin 2 polarity: high MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: high lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: active-high MADT: Ignoring local NMI routed to ACPI CPU 1 ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x01000000 DFR: 0x0fffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff wlan: <802.11 Link Layer> random: io: mem: Pentium Pro MTRR support enabled null: npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x80000054 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=25908086) pcibios: BIOS version 2.10 Found $PIR table, 9 entries at 0xc00fb7c0 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded 0 3 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 3 B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 0 3 C 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 0 3 D 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 0 29 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 29 B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 0 29 C 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 0 29 D 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 0 30 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 30 B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 0 30 C 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 0 30 D 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 0 31 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 31 B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 0 31 C 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 0 31 D 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 0 2 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 1 0 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 3 0 A 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 3 1 A 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 3 1 B 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 3 1 C 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 3 3 A 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 3 3 B 0x63 3 4 5 6 7 9 10 11 12 14 15 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 31 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 31 func 0 ACPI timer: 1/1 1/1 1/2 1/1 1/1 1/1 1/1 1/2 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 acpi_throttle0: P_CNT from P_BLK 0x10e0 acpi_acad0: on acpi0 acpi_cmbat0: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 ACPI PCI link initial configuration: pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x8086, dev=0x2590, revid=0x03 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 1, range 32, base dff00000, size 19, enabled map[14]: type 4, range 32, base 0000ec38, size 3, enabled map[18]: type 3, range 32, base c0000000, size 28, enabled map[1c]: type 1, range 32, base dfec0000, size 18, enabled pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x2592, revid=0x03 bus=0, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0003, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=16 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base dff80000, size 19, enabled found-> vendor=0x8086, dev=0x2792, revid=0x03 bus=0, slot=2, func=1 class=03-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000bf80, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x2658, revid=0x03 bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=16 map[20]: type 4, range 32, base 0000bf60, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 17 found-> vendor=0x8086, dev=0x2659, revid=0x03 bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=17 map[20]: type 4, range 32, base 0000bf40, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x265a, revid=0x03 bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=18 map[20]: type 4, range 32, base 0000bf20, size 5, enabled pcib0: matched entry for 0.29.INTD pcib0: slot 29 INTD hardwired to IRQ 19 found-> vendor=0x8086, dev=0x265b, revid=0x03 bus=0, slot=29, func=3 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=19 map[10]: type 1, range 32, base ffa80800, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x265c, revid=0x03 bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=16 powerspec 2 supports D0 D3 current D0 found-> vendor=0x8086, dev=0x2448, revid=0xd3 bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) map[10]: type 4, range 32, base 0000ed00, size 8, enabled map[14]: type 4, range 32, base 0000ec40, size 6, enabled map[18]: type 1, range 32, base dfebfe00, size 9, enabled map[1c]: type 1, range 32, base dfebfd00, size 8, enabled pcib0: matched entry for 0.30.INTA pcib0: slot 30 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x266e, revid=0x03 bus=0, slot=30, func=2 class=04-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=16 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 0000ee00, size 8, enabled map[14]: type 4, range 32, base 0000ec80, size 7, enabled pcib0: matched entry for 0.30.INTB pcib0: slot 30 INTB hardwired to IRQ 17 found-> vendor=0x8086, dev=0x266d, revid=0x03 bus=0, slot=30, func=3 class=07-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=17 powerspec 2 supports D0 D3 current D0 found-> vendor=0x8086, dev=0x2641, revid=0x03 bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0107, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 0000bfa0, size 4, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 17 found-> vendor=0x8086, dev=0x2653, revid=0x03 bus=0, slot=31, func=2 class=01-01-80, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x02b8, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=17 powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 000010c0, size 5, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 17 found-> vendor=0x8086, dev=0x266a, revid=0x03 bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0101, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=17 pci0: at device 2.0 (no driver attached) pci0: at device 2.1 (no driver attached) uhci0: port 0xbf80-0xbf9f irq 16 at device 29.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xbf80 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xbf60-0xbf7f irq 17 at device 29.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xbf60 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xbf40-0xbf5f irq 18 at device 29.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0xbf40 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xbf20-0xbf3f irq 19 at device 29.3 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0xbf20 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered pci0: at device 29.7 (no driver attached) pcib1: at device 30.0 on pci0 pcib1: secondary bus 3 pcib1: subordinate bus 4 pcib1: I/O decode 0xf000-0xfff pcib1: memory decode 0xdfd00000-0xdfdfffff pcib1: prefetched decode 0xfff00000-0xfffff pcib1: Subtractively decoded bridge. ACPI PCI link initial configuration: pci3: on pcib1 pci3: physical bus=3 map[10]: type 1, range 32, base dfdfe000, size 13, enabled pcib1: device (null) requested decoded memory range 0xdfdfe000-0xdfdfffff pcib1: matched entry for 3.0.INTA pcib1: slot 0 INTA hardwired to IRQ 18 found-> vendor=0x14e4, dev=0x170c, revid=0x02 bus=3, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=18 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 00000000, size 12, memory disabled found-> vendor=0x1180, dev=0x0476, revid=0xb3 bus=3, slot=1, func=0 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0000, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x40 (16000 ns), maxlat=0x07 (1750 ns) intpin=a, irq=255 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base dfdfc800, size 11, enabled pcib1: device (null) requested decoded memory range 0xdfdfc800-0xdfdfcfff pcib1: matched entry for 3.1.INTB pcib1: slot 1 INTB hardwired to IRQ 18 found-> vendor=0x1180, dev=0x0552, revid=0x08 bus=3, slot=1, func=1 class=0c-00-10, hdrtype=0x00, mfdev=1 cmdreg=0x0106, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x02 (500 ns), maxlat=0x04 (1000 ns) intpin=b, irq=18 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base dfdfc700, size 8, enabled pcib1: device (null) requested decoded memory range 0xdfdfc700-0xdfdfc7ff pcib1: matched entry for 3.1.INTC pcib1: slot 1 INTC hardwired to IRQ 17 found-> vendor=0x1180, dev=0x0822, revid=0x17 bus=3, slot=1, func=2 class=08-05-01, hdrtype=0x00, mfdev=1 cmdreg=0x0106, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=17 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base dfdfd000, size 12, enabled pcib1: device (null) requested decoded memory range 0xdfdfd000-0xdfdfdfff pcib1: matched entry for 3.3.INTA pcib1: slot 3 INTA hardwired to IRQ 17 found-> vendor=0x8086, dev=0x4220, revid=0x05 bus=3, slot=3, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0116, statreg=0x0290, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x03 (750 ns), maxlat=0x18 (6000 ns) intpin=a, irq=17 powerspec 2 supports D0 D3 current D0 bfe0: mem 0xdfdfe000-0xdfdfffff irq 18 at device 0.0 on pci3 bfe0: Reserved 0x2000 bytes for rid 0x10 type 3 at 0xdfdfe000 miibus0: on bfe0 bmtphy0: on miibus0 bmtphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto bfe0: bpf attached bfe0: Ethernet address: 00:11:43:7b:32:d4 bfe0: [GIANT-LOCKED] cbb0: at device 1.0 on pci3 pcib1: device cbb0 requested decoded memory range 0xdfd00000-0xdfdfffff cbb0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0xdfd00000 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 pcib1: matched entry for 3.1.INTA pcib1: slot 1 INTA hardwired to IRQ 19 cbb0: [MPSAFE] cbb0: PCI Configuration space: 0x00: 0x04761180 0x02100007 0x060700b3 0x00824000 0x10: 0xdfd00000 0x020000dc 0x20040403 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc 0x30: 0x00000000 0xfffffffc 0x00000000 0x07400113 0x40: 0x01881028 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x30a00001 0x00000000 0x04630463 0x00000000 0x90: 0x00000000 0x00000000 0x00000000 0x00000000 0xa0: 0x00000008 0x00000000 0x00000000 0x00000000 0xb0: 0x00000000 0xb2000000 0x00003000 0x00000000 0xc0: 0x01881028 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0xfe0a0001 0xe0: 0x24c04000 0x00000000 0x00000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 fwohci0: mem 0xdfdfc800-0xdfdfcfff irq 18 at device 1.1 on pci3 fwohci0: Reserved 0x800 bytes for rid 0x10 type 3 at 0xdfdfc800 fwohci0: [MPSAFE] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 4a:4f:c0:00:1b:9d:4c:30 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 4a:4f:c0:9d:4c:30 fwe0: bpf attached fwe0: Ethernet address: 4a:4f:c0:9d:4c:30 fwe0: if_start running deferred for Giant sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) pci3: at device 1.2 (no driver attached) pci3: at device 3.0 (no driver attached) pcm0: port 0xec40-0xec7f,0xed00-0xedff mem 0xdfebfd00-0xdfebfdff,0xdfebfe00-0xdfebffff irq 16 at device 30.2 on pci0 pcm0: Reserved 0x200 bytes for rid 0x18 type 3 at 0xdfebfe00 pcm0: Reserved 0x100 bytes for rid 0x1c type 3 at 0xdfebfd00 pcm0: [GIANT-LOCKED] pcm0: pcm0: Codec features headphone, 20 bit DAC, 20 bit ADC, 5 bit master volume, SigmaTel 3D Enhancement pcm0: Primary codec extended features variable rate PCM, AMAP, reserved 5 pcm0: sndbuf_setmap 1ea18000, 4000; 0xd520a000 -> 1ea18000 pcm0: sndbuf_setmap 1ea10000, 4000; 0xd520e000 -> 1ea10000 pci0: at device 30.3 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xbfa0-0xbfaf,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 irq 17 at device 31.2 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xbfa0 ata0: channel #0 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata0-slave: stat=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 ata0: [MPSAFE] ata1: channel #1 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=50 ostat1=00 ata1-master: stat=0x10 err=0x01 lsb=0x14 msb=0xeb ata1-slave: stat=0x00 err=0x01 lsb=0x00 msb=0x00 ata1: reset tp2 stat0=10 stat1=00 devices=0x4 ata1: [MPSAFE] pci0: at device 31.3 (no driver attached) acpi_tz0: on acpi0 psmcpnp0: irq 12 on acpi0 atkbdc0: port 0x66,0x62,0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: current command byte:0065 psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model GlidePoint, device ID 0-00, 2 buttons psm0: config:00000000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 ex_isa_identify() unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it ahc_isa_probe 14: ioport 0xec00 alloc failed isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: at iomem 0xce800-0xcffff,0xc0000-0xce7ff on isa0 pmtimer0 on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0 failed to probe at port 0x3f0-0x3f5 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) pcic0 failed to probe at port 0x3e0 iomem 0xd0000 on isa0 pcic1: not probed (disabled) ppc0: parallel port not found. ppc0: failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0x8201 0x8201 0x8201 0x8201 sio0: probe failed test(s): 0 1 2 4 6 7 9 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0x8201 0x8201 0x8201 0x8201 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 07 80 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff EGA/VGA parameters to be used for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff vt0: not probed (disabled) isa_probe_children: probing PnP devices ugen0: Dell product 0x8103, rev 2.00/16.57, addr 2 umass0: Cypress Semiconductor USB2.0 Storage Device, rev 2.00/0.01, addr 2 umass0: Get Max Lun not supported (STALLED) umass0:1:0:-1: Attached to scbus1 ums0: Logitech Optical USB Mouse, rev 2.00/3.40, addr 3, iclass 3/1 ums0: 3 buttons and Z dir. Device configuration finished. procfs registered Timecounter "TSC" frequency 1596012945 Hz quality 800 Timecounters tick every 10.000 msec lo0: bpf attached acpi_acad0: acline initialization start acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times acpi_cmbat0: battery initialization start acpi_cmbat0: battery initialization done, tried 1 times ata0-master: pio=0x0c wdma=0x22 udma=0x45 cable=80pin ad0: ATA-6 disk at ata0-master ad0: 38154MB (78140160 sectors), 77520 C, 16 H, 63 S, 512 B ad0: 16 secs/int, 1 depth queue, UDMA33 GEOM: new disk ad0 ar: FreeBSD check1 failed ata1-master: pio=0x0c wdma=0x22 udma=0x42 cable=40pin acd0: CDRW drive at ata1 as master acd0: read 689KB/s (4126KB/s) write 4126KB/s (4126KB/s), 2048KB buffer, PIO4 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet acd0: Writes: CDR, CDRW, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc pcm0: measured ac97 link rate at 47998 Hz, will use 48000 Hz [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:58717512 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad0s1, start 32256 length 30063366144 end 30063398399 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 GEOM: Configure ad0s1a, start 0 length 268435456 end 268435455 GEOM: Configure ad0s1b, start 268435456 length 1030324224 end 1298759679 GEOM: Configure ad0s1c, start 0 length 30063366144 end 30063366143 GEOM: Configure ad0s1d, start 1298759680 length 268435456 end 1567195135 GEOM: Configure ad0s1e, start 1567195136 length 268435456 end 1835630591 GEOM: Configure ad0s1f, start 1835630592 length 28227735552 end 30063366143 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 (probe0:sbp0:0:0:0): error 22 (probe0:sbp0:0:0:0): Unretryable Error (probe1:sbp0:0:1:0): error 22 (probe1:sbp0:0:1:0): Unretryable Error (probe2:sbp0:0:2:0): error 22 (probe2:sbp0:0:2:0): Unretryable Error (probe3:sbp0:0:3:0): error 22 (probe3:sbp0:0:3:0): Unretryable Error (probe4:sbp0:0:4:0): error 22 (probe4:sbp0:0:4:0): Unretryable Error (probe5:sbp0:0:5:0): error 22 (probe5:sbp0:0:5:0): Unretryable Error (probe6:sbp0:0:6:0): error 22 (probe6:sbp0:0:6:0): Unretryable Error pass0 at umass-sim0 bus 0 target 0 lun 0 pass0: Fixed Direct Access SCSI-0 device pass0: 1.000MB/s transfers GEOM: new disk da0 ioapic0: routing intpin 1 (ISA IRQ 1) to cluster 0 ioapic0: routing intpin 4 (ISA IRQ 4) to cluster 0 ioapic0: routing intpin 8 (ISA IRQ 8) to cluster 0 ioapic0: routing intpin 9 (ISA IRQ 9) to cluster 0 ioapic0: routing intpin 12 (ISA IRQ 12) to cluster 0 ioapic0: routing intpin 13 (ISA IRQ 13) to cluster 0 ioapic0: routing intpin 14 (ISA IRQ 14) to cluster 0 ioapic0: routing intpin 15 (ISA IRQ 15) to cluster 0 ioapic0: routing intpin 16 (PCI IRQ 16) to cluster 0 ioapic0: routing intpin 17 (PCI IRQ 17) to cluster 0 ioapic0: routing intpin 18 (PCI IRQ 18) to cluster 0 ioapic0: routing intpin 19 (PCI IRQ 19) to cluster 0 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: 157066MB (321672960 512 byte sectors: 255H 63S/T 20023C) [0] f:00 typ:6 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:160826652 [1] f:00 typ:6 s(CHS):1023/255/63 e(CHS):1023/254/63 s:160826715 l:160842780 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure da0s1, start 32256 length 82343245824 end 82343278079 GEOM: Configure da0s2, start 82343278080 length 82351503360 end 164694781439 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 Mounting root from ufs:/dev/ad0s1a start_init: trying /sbin/init Linux ELF exec handler installed linprocfs registered WARNING: driver "vmmon" used unreserved major device number 200 vmmon: Module vmmon: registered with major=200 minor=0 tag=$Name: build-570 (3.2.x mvm) $ vmmon: Module vmmon: initialized vmnet1: bpf attached vmnet1: Ethernet address: 00:bd:28:09:00:01 vmnet1: promiscuous mode enabled pciconf -lv: hostb0@pci0:0:0: class=0x060000 card=0x01881028 chip=0x25908086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI none0@pci0:2:0: class=0x030000 card=0x01881028 chip=0x25928086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' class = display subclass = VGA none1@pci0:2:1: class=0x038000 card=0x01881028 chip=0x27928086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile Graphics Controller' class = display uhci0@pci0:29:0: class=0x0c0300 card=0x01881028 chip=0x26588086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801FB/FR/FW/FRW USB UHCI Controller' class = serial bus subclass = USB uhci1@pci0:29:1: class=0x0c0300 card=0x01881028 chip=0x26598086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801FB/FR/FW/FRW USB UHCI Controller' class = serial bus subclass = USB uhci2@pci0:29:2: class=0x0c0300 card=0x01881028 chip=0x265a8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801FB/FR/FW/FRW USB UHCI Controller' class = serial bus subclass = USB uhci3@pci0:29:3: class=0x0c0300 card=0x01881028 chip=0x265b8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801FB/FR/FW/FRW USB UHCI Controller' class = serial bus subclass = USB ehci0@pci0:29:7: class=0x0c0320 card=0x01881028 chip=0x265c8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801FB/FR/FW/FRW USB 2.0 EHCI Controller' class = serial bus subclass = USB pcib1@pci0:30:0: class=0x060401 card=0x00000050 chip=0x24488086 rev=0xd3 hdr=0x01 vendor = 'Intel Corporation' device = '82801BAM/CAM/DBM (ICH2-M/3-M/4-M) Hub Interface to PCI Bridge' class = bridge subclass = PCI-PCI pcm0@pci0:30:2: class=0x040100 card=0x01881028 chip=0x266e8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801FB/FR/FW/FRW AC '97 Audio Controller' class = multimedia subclass = audio none2@pci0:30:3: class=0x070300 card=0x542314f1 chip=0x266d8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801FB/FR/FW/FRW AC '97 Modem Controller' class = simple comms subclass = generic modem isab0@pci0:31:0: class=0x060100 card=0x01881028 chip=0x26418086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801FBM ICH6M LPC Interface Bridge' class = bridge subclass = PCI-ISA atapci0@pci0:31:2: class=0x010180 card=0x01881028 chip=0x26538086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801FBM ICH6M SATA Controller' class = mass storage subclass = ATA none3@pci0:31:3: class=0x0c0500 card=0x01881028 chip=0x266a8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801FB/FR/FW/FRW SMBus Controller' class = serial bus subclass = SMBus bfe0@pci3:0:0: class=0x020000 card=0x01881028 chip=0x170c14e4 rev=0x02 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM440x 100Base-TX Fast Ethernet' class = network subclass = ethernet none4@pci3:1:0: class=0x060700 card=0x01881028 chip=0x04761180 rev=0xb3 hdr=0x02 vendor = 'Ricoh Co Ltd' device = 'RL5c476 CardBus Controller' class = bridge subclass = PCI-CardBus fwohci0@pci3:1:1: class=0x0c0010 card=0x01881028 chip=0x05521180 rev=0x08 hdr=0x00 vendor = 'Ricoh Co Ltd' device = 'RL5c552 IEEE-1394 Controller' class = serial bus subclass = FireWire none5@pci3:1:2: class=0x080501 card=0x01881028 chip=0x08221180 rev=0x17 hdr=0x00 vendor = 'Ricoh Co Ltd' class = base peripheral none6@pci3:3:0: class=0x028000 card=0x27228086 chip=0x42208086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/Wireless 2200BG Network Connection' class = network -- Paolo From owner-freebsd-hackers@FreeBSD.ORG Sat May 21 13:46:11 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 48E8D16A4CE for ; Sat, 21 May 2005 13:46:11 +0000 (GMT) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93EDC43D78 for ; Sat, 21 May 2005 13:46:10 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: Y1QAsIk9O44SO+J/q9KNyQ== Received: from mp-217-208-217.daxnet.no ([193.217.208.217] verified) by mailfe07.swip.net (CommuniGate Pro SMTP 4.3c5) with ESMTP id 175567134; Sat, 21 May 2005 15:46:09 +0200 From: Hans Petter Selasky To: Peter Jeremy Date: Sat, 21 May 2005 15:46:55 +0200 User-Agent: KMail/1.7 References: <200505201340.36176.hselasky@c2i.net> <200505202151.35831.hselasky@c2i.net> <20050520224928.GI2129@cirb503493.alcatel.com.au> In-Reply-To: <20050520224928.GI2129@cirb503493.alcatel.com.au> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200505211546.56111.hselasky@c2i.net> cc: hackers@freebsd.org Subject: Re: problems with new the "contigmalloc" routine X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: hselasky@c2i.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2005 13:46:11 -0000 On Saturday 21 May 2005 00:49, Peter Jeremy wrote: > On Fri, 2005-May-20 21:51:34 +0200, Hans Petter Selasky wrote: > >Non-blocking mode has got to be supported. Else you get a nightmare > > rewriting the code to support blocking mode. > > Your code either has to block somewhere or fail. contigmalloc() only > blocks if it couldn't satisfy the request immediately. If it returns > to your code, you still have the problem of needing the memory and > not being able to allocate it without blocking. That is not the problem. The problem is that it sleeps, which will exit the Giant lock, which means another thread can change the state of what I am about to setup meanwhile: one_thread: mtx_lock(&Giant); if(sc->gone == 0) { sc->data = contigmalloc(); } mtx_unlock(&Giant); another_thread: mtx_lock(&Giant); if(sc->data) { contigfree(); sc->data = NULL; } sc->gone = 1; mtx_unlock(&Giant); The problem is that the undefined state: "sc->data != NULL" and "sc->gone == 1" can be reached. > > >Can anyone explain why "uiomove()" has to sleep, and why there is no > >non-blocking "uiomove()"? > > As far as I can see, uiomove() only sleeps if it is asked to do a > kernel<->userland move that takes more than twice a scheduler quantum. > As long as you don't uiomove() ridiculous amounts of data, it should > never sleep. > On Saturday 21 May 2005 00:56, Don Lewis wrote: > > It can also sleep if it stumbles across a userland page that isn't > resident. When this happens, it will sleep until the page is retrieved > from swap. The fact that uiomove(), copyout(), copyin(), contigmalloc() and bus_dmamem_alloc() can all sleep, should be documented somewhere, so that people are not surprised. --HPS From owner-freebsd-hackers@FreeBSD.ORG Sat May 21 14:58:11 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8426916A4CE for ; Sat, 21 May 2005 14:58:11 +0000 (GMT) Received: from enterprise4.noxa.de (enterprise.noxa.de [212.60.197.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 60E6743D8A for ; Sat, 21 May 2005 14:58:10 +0000 (GMT) (envelope-from arundel@h3c.de) Received: (qmail 11928 invoked from network); 21 May 2005 16:58:08 +0200 Received: from p508fd4bd.dip.t-dialin.net (HELO localhost.skatecity) (80.143.212.189) by enterprise.noxa.de with AES256-SHA encrypted SMTP; 21 May 2005 16:58:08 +0200 Received: from localhost.skatecity (nobody@localhost.skatecity [127.0.0.1]) by localhost.skatecity (8.13.3/8.13.3) with ESMTP id j4LEw794051379 for ; Sat, 21 May 2005 16:58:07 +0200 (CEST) (envelope-from arundel@localhost.skatecity) Received: (from arundel@localhost) by localhost.skatecity (8.13.3/8.13.3/Submit) id j4LEw7Tg051378; Sat, 21 May 2005 16:58:07 +0200 (CEST) (envelope-from arundel) From: alexander Date: Sat, 21 May 2005 16:58:07 +0200 To: freebsd-hackers@freebsd.org, freebsd-hackers@freebsd.org Message-ID: <20050521145807.GA51141@skatecity> References: <20050520224726.GA7951@skatecity> <20050520230845.GC51092@dan.emsphone.com> <20050521015105.GA9063@skatecity> <20050521080723.GN2129@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050521080723.GN2129@cirb503493.alcatel.com.au> Subject: Re: Looking for ANSI/VT100 code replacement. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2005 14:58:11 -0000 On Sat May 21 05, Peter Jeremy wrote: > > I think you need to give us more details and preferably some sample code > to simulate the problem. What is the hardware you are running on? What > version of FreeBSD, X11 and xterm/Eterm. > > -- > Peter Jeremy Here's the code that is using the VT100 stuff: ############################################################################## %define stdout 1 MainDataSend db 0Ah,"Sending main data..." MaxUnits db 0 dd 0 MainDataSlash db "/" CurrentUnit db "0" dd "0000" lMainDataSend equ $-MainDataSend lCurrentUnit equ $-CurrentUnit updateMainUnit db 27,91,53,68,27,91,75 lupdateMainUnit equ $-updateMainUnit ;... mov [MaxUnits+1], dword ebx mov [MaxUnits], byte bl push dword lMainDataSend push dword MainDataSend push dword stdout mov eax, 4 call _syscall add esp, byte 12 ;THE FOLLOWING CODE IS EMBEDDED INTO A LOOP push dword lupdateMainUnit push dword updateMainUnit push dword stdout mov eax, 4 call _syscall add esp, byte 12 ;... mov [CurrentUnit+1], dword ebx mov [CurrentUnit], byte bl ;... push dword lCurrentUnit push dword CurrentUnit push dword stdout mov eax, 4 call _syscall add esp, byte 12 ############################################################################## The Problem is defenately not the speed of my system: 1.3 Ghz && 512 MB !!! If you want to have a look at the entire sourcecode please visit my blog at http://arundel.blog.de I also took 2 videos with my digicam that show you how stdout behaves under the console and using Eterm. The files are encoded with XVID (no sound): http://520061600655-0001.bei.t-online.de/gbacopy/console.avi http://520061600655-0001.bei.t-online.de/gbacopy/eterm.avi Cheers. From owner-freebsd-hackers@FreeBSD.ORG Sat May 21 16:02:31 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D365316A4CE for ; Sat, 21 May 2005 16:02:31 +0000 (GMT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 4281743D98 for ; Sat, 21 May 2005 16:02:30 +0000 (GMT) (envelope-from aurelbodenmann@gmx.ch) Received: (qmail 348 invoked by uid 0); 21 May 2005 16:02:29 -0000 Received: from 80.238.133.37 by www42.gmx.net with HTTP; Sat, 21 May 2005 18:02:29 +0200 (MEST) Date: Sat, 21 May 2005 18:02:29 +0200 (MEST) From: "Aurel Bodenmann" To: freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <2230BFE1-6802-49E4-AFED-A8ABCF4FBA08@sweety.li> X-Priority: 3 (Normal) X-Authenticated: #14536212 Message-ID: <6032.1116691349@www42.gmx.net> X-Mailer: WWW-Mail 1.6 (Global Message Exchange) X-Flags: 0001 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Subject: Re: kgdb doesn't seem to work, says "Cannot read PTD" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2005 16:02:31 -0000 On May 20, 2005, at 18:31, Dag-Erling Smørgrav wrote: >> . Anyway, I wanted to locate the problem and do something about >> it (aka submit an useful coredump to this list :-) but unfortunately >> neither gdb nor kgdb seem to work for me. >> > > Well, thank you for trying! In the meantime, could you post the panic > message and backtrace, or at least the contents of /var/crash/info.1? Unfortunately I haven't written down the panic message (I thought that I could retrieve it using gdb when the sever crashed), so unfortunately the only thing useful I have right now is /var/crash/info.1: # cat info.1 Dump header from device /dev/ar0s1b Architecture: i386 Architecture Version: 16777216 Dump Length: 804519936B (767 MB) Blocksize: 512 Dumptime: Thu May 19 12:11:37 2005 Hostname: DrSweety-Server.Dr.Sweety.Lan Magic: FreeBSD Kernel Dump Version String: FreeBSD 5.4-RC4 #3: Sat May 7 10:09:11 CEST 2005 root@DrSweety-Server.Dr.Sweety.Lan:/usr/obj/usr/src/sys/DrSweety- Kernel Panic String: from debugger Dump Parity: 458902623 Bounds: 1 Dump Status: good Of course there is also vmcore.1 but this file is huge and I don't really want to post it somewhere available to the public as it might contain sensitive information. In case somebody might be interested in, I've put the output from dmesg, pciconf -l -v and the current Kernelconfig here: htt://drsweety.homeip.net/freebsd_hackers/ Ys, Aurel Bodenmann -- Weitersagen: GMX DSL-Flatrates mit Tempo-Garantie! Ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl From owner-freebsd-hackers@FreeBSD.ORG Sat May 21 17:35:46 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 791F916A4CE for ; Sat, 21 May 2005 17:35:46 +0000 (GMT) Received: from smtp.xbsd.org (xbsd.org [82.233.2.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCB0843D6B for ; Sat, 21 May 2005 17:35:45 +0000 (GMT) (envelope-from flz@xbsd.org) Received: from localhost (localhost.xbsd.org [127.0.0.1]) by smtp.xbsd.org (Postfix) with ESMTP id 72F1B11B46; Sat, 21 May 2005 19:37:26 +0200 (CEST) Received: from smtp.xbsd.org ([127.0.0.1]) by localhost (srv1.xbsd.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92975-06; Sat, 21 May 2005 19:37:20 +0200 (CEST) Received: from cream.xbsd.org (cream.xbsd.org [192.168.42.6]) by smtp.xbsd.org (Postfix) with ESMTP id 6B88511AD1; Sat, 21 May 2005 19:37:20 +0200 (CEST) From: Florent Thoumie To: Larry Baird In-Reply-To: <20050520125222.A31121@gta.com> References: <17037.14274.229768.369886@zaphod.home.loc> <20050520134441.75330.qmail@gta.com><20050520125222.A31121@gta.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-a7O1vUtLRHcWKoUauZLT" Date: Sat, 21 May 2005 19:35:39 +0200 Message-Id: <1116696939.613.1.camel@cream.xbsd.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port X-Virus-Scanned: amavisd-new at xbsd.org cc: freebsd-hackers@freebsd.org cc: "Walter C. Pelissero" Subject: Re: WRAP.1E and geode.c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2005 17:35:46 -0000 --=-a7O1vUtLRHcWKoUauZLT Content-Type: text/plain; charset=iso8859-15 Content-Transfer-Encoding: quoted-printable Le Vendredi 20 mai 2005 =E0 12:52 -0400, Larry Baird a =E9crit : > Walter, >=20 > > Are you sure about that? > Yes and no. I am sure that I have working code. I just realized that > when I ported my patch to 5.4 I missed one thing. The following patch > should work muxh better for you. (-: Not really important but : > printf("PC Engines WRAP.1C platfrom\n"); [...] typo here. --=20 Florent Thoumie flz@xbsd.org --=-a7O1vUtLRHcWKoUauZLT Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBCj3FrMxEkbVFH3PQRAvXBAJ0SBLAjaq/1A9R+S4/+96lmlnoChQCfZmK6 qVa6lelg6jiChQat3TMrSCk= =d6Ml -----END PGP SIGNATURE----- --=-a7O1vUtLRHcWKoUauZLT-- From owner-freebsd-hackers@FreeBSD.ORG Sat May 21 17:44:12 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9AE5B16A4D4 for ; Sat, 21 May 2005 17:44:12 +0000 (GMT) Received: from mail28.sea5.speakeasy.net (mail28.sea5.speakeasy.net [69.17.117.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id D011043D5F for ; Sat, 21 May 2005 17:44:11 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 25682 invoked from network); 21 May 2005 17:44:11 -0000 Received: by simscan 1.1.0 ppid: 25673, pid: 25680, t: 0.1943s scanners: clamav: 0.84/m:31/d:888 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail28.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 21 May 2005 17:44:11 -0000 Received: from hydrogen.funkthat.com (uzmjkt@localhost.funkthat.com [127.0.0.1])j4LHiA2g005669; Sat, 21 May 2005 10:44:10 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id j4LHi8vU005668; Sat, 21 May 2005 10:44:08 -0700 (PDT) Date: Sat, 21 May 2005 10:44:08 -0700 From: John-Mark Gurney To: Hans Petter Selasky Message-ID: <20050521174408.GE959@funkthat.com> Mail-Followup-To: Hans Petter Selasky , Peter Jeremy , hackers@freebsd.org References: <200505201340.36176.hselasky@c2i.net> <200505202151.35831.hselasky@c2i.net> <20050520224928.GI2129@cirb503493.alcatel.com.au> <200505211546.56111.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200505211546.56111.hselasky@c2i.net> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: Peter Jeremy cc: hackers@freebsd.org Subject: Re: problems with new the "contigmalloc" routine X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2005 17:44:13 -0000 Hans Petter Selasky wrote this message on Sat, May 21, 2005 at 15:46 +0200: > On Saturday 21 May 2005 00:49, Peter Jeremy wrote: > > On Fri, 2005-May-20 21:51:34 +0200, Hans Petter Selasky wrote: > > >Non-blocking mode has got to be supported. Else you get a nightmare > > > rewriting the code to support blocking mode. > > > > Your code either has to block somewhere or fail. contigmalloc() only > > blocks if it couldn't satisfy the request immediately. If it returns > > to your code, you still have the problem of needing the memory and > > not being able to allocate it without blocking. > > That is not the problem. The problem is that it sleeps, which will exit the > Giant lock, which means another thread can change the state of what I am > about to setup meanwhile: > > one_thread: > > mtx_lock(&Giant); > > if(sc->gone == 0) > { > sc->data = contigmalloc(); > } > > mtx_unlock(&Giant); > > another_thread: > > mtx_lock(&Giant); > > if(sc->data) > { > contigfree(); > sc->data = NULL; > } > > sc->gone = 1; > > mtx_unlock(&Giant); > > > The problem is that the undefined state: "sc->data != NULL" and > "sc->gone == 1" can be reached. How about rewriting the code to be: one_thread: tmpdata = contigmalloc(); mtx_lock(&Giant); if(sc->gone == 0) { sc->data = tmpdata; } else { contigfree(tmpdata); } mtx_unlock(&Giant); another_thread: mtx_lock(&Giant); if(sc->data) { tmpdata = sc->data; sc->data = NULL; } sc->gone = 1; mtx_unlock(&Giant); contigfree(tmpdata); That should do it.. Though you do need to have your own ref count on sc to prevent the entire sc from going away before the first thread has locked... Anyways, you should be using your own lock that's in sc for this instead of using Giant... Remeber that you can usually do some of the work before obtaining the lock, and then swapping a few variables around... In fact, it's usually better to do this since you don't have to do as much work with the lock locked... I don't think -current should allow new code to use Giant... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Sat May 21 18:06:17 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A162D16A4CE for ; Sat, 21 May 2005 18:06:17 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id B072443D64 for ; Sat, 21 May 2005 18:06:14 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j4LI91cl007758; Sat, 21 May 2005 12:09:01 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <428F784B.6010806@samsco.org> Date: Sat, 21 May 2005 12:04:59 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John-Mark Gurney References: <200505201340.36176.hselasky@c2i.net> <200505202151.35831.hselasky@c2i.net> <20050520224928.GI2129@cirb503493.alcatel.com.au> <200505211546.56111.hselasky@c2i.net> <20050521174408.GE959@funkthat.com> In-Reply-To: <20050521174408.GE959@funkthat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: Peter Jeremy cc: hackers@freebsd.org cc: Hans Petter Selasky Subject: Re: problems with new the "contigmalloc" routine X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2005 18:06:17 -0000 John-Mark Gurney wrote: > Hans Petter Selasky wrote this message on Sat, May 21, 2005 at 15:46 +0200: > >>On Saturday 21 May 2005 00:49, Peter Jeremy wrote: >> >>>On Fri, 2005-May-20 21:51:34 +0200, Hans Petter Selasky wrote: >>> >>>>Non-blocking mode has got to be supported. Else you get a nightmare >>>>rewriting the code to support blocking mode. >>> >>>Your code either has to block somewhere or fail. contigmalloc() only >>>blocks if it couldn't satisfy the request immediately. If it returns >>>to your code, you still have the problem of needing the memory and >>>not being able to allocate it without blocking. >> >>That is not the problem. The problem is that it sleeps, which will exit the >>Giant lock, which means another thread can change the state of what I am >>about to setup meanwhile: >> >>one_thread: >> >> mtx_lock(&Giant); >> >> if(sc->gone == 0) >> { >> sc->data = contigmalloc(); >> } >> >> mtx_unlock(&Giant); >> >>another_thread: >> >> mtx_lock(&Giant); >> >> if(sc->data) >> { >> contigfree(); >> sc->data = NULL; >> } >> >> sc->gone = 1; >> >> mtx_unlock(&Giant); >> >> >>The problem is that the undefined state: "sc->data != NULL" and >>"sc->gone == 1" can be reached. > > > How about rewriting the code to be: > one_thread: > tmpdata = contigmalloc(); > mtx_lock(&Giant); > if(sc->gone == 0) { > sc->data = tmpdata; > } else { > contigfree(tmpdata); > } > mtx_unlock(&Giant); > > another_thread: > > mtx_lock(&Giant); > if(sc->data) { > tmpdata = sc->data; > sc->data = NULL; > } > > sc->gone = 1; > > mtx_unlock(&Giant); > contigfree(tmpdata); > > That should do it.. Though you do need to have your own ref count on sc > to prevent the entire sc from going away before the first thread has > locked... Anyways, you should be using your own lock that's in sc for > this instead of using Giant... > > Remeber that you can usually do some of the work before obtaining the > lock, and then swapping a few variables around... In fact, it's usually > better to do this since you don't have to do as much work with the lock > locked... > > I don't think -current should allow new code to use Giant... > I'd suggest just following a simplier and more deterministic path by either pre-allocating your contiguous buffers in a safe context, or allocating them on the fly before you depend on state being static. Our concept of 'sleep' and 'block' are a bit muddled now that we have liberal uses of sleep locks, and we as programmers need to cope and adjust. It's always good form in embedded and kernel programming to pre-allocate and closely manage resources when you can; this isn't userland where resources are cheap. Scott From owner-freebsd-hackers@FreeBSD.ORG Sat May 21 20:47:25 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3122F16A4CE for ; Sat, 21 May 2005 20:47:25 +0000 (GMT) Received: from mail26.syd.optusnet.com.au (mail26.syd.optusnet.com.au [211.29.133.167]) by mx1.FreeBSD.org (Postfix) with ESMTP id A402D43D48 for ; Sat, 21 May 2005 20:47:24 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j4LKlKMn023595 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 22 May 2005 06:47:22 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j4LKlKRx010582; Sun, 22 May 2005 06:47:20 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j4LKlKe2010581; Sun, 22 May 2005 06:47:20 +1000 (EST) (envelope-from pjeremy) Date: Sun, 22 May 2005 06:47:20 +1000 From: Peter Jeremy To: alexander Message-ID: <20050521204719.GO2129@cirb503493.alcatel.com.au> References: <20050520224726.GA7951@skatecity> <20050520230845.GC51092@dan.emsphone.com> <20050521015105.GA9063@skatecity> <20050521080723.GN2129@cirb503493.alcatel.com.au> <20050521145807.GA51141@skatecity> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050521145807.GA51141@skatecity> User-Agent: Mutt/1.4.2i cc: freebsd-hackers@freebsd.org Subject: Re: Looking for ANSI/VT100 code replacement. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2005 20:47:25 -0000 On Sat, 2005-May-21 16:58:07 +0200, alexander wrote: >On Sat May 21 05, Peter Jeremy wrote: >> >> I think you need to give us more details and preferably some sample code >> to simulate the problem. What is the hardware you are running on? What >> version of FreeBSD, X11 and xterm/Eterm. ... >The Problem is defenately not the speed of my system: 1.3 Ghz && 512 MB !!! Can you please confirm that you also see the problem when you are using xterm (not Eterm). Can you also please advise what versions of FreeBSD, X11 and xterm/Eterm you are using. >If you want to have a look at the entire sourcecode please visit my blog at >http://arundel.blog.de I don't feel like working through a large blob of assembler code that >http://520061600655-0001.bei.t-online.de/gbacopy/console.avi This looks like the output I would expect. >http://520061600655-0001.bei.t-online.de/gbacopy/eterm.avi Intriguing. -- Peter Jeremy From owner-freebsd-hackers@FreeBSD.ORG Sat May 21 22:09:40 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2625F16A4CE for ; Sat, 21 May 2005 22:09:40 +0000 (GMT) Received: from enterprise4.noxa.de (enterprise.noxa.de [212.60.197.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 61B6143D48 for ; Sat, 21 May 2005 22:09:38 +0000 (GMT) (envelope-from arundel@h3c.de) Received: (qmail 9327 invoked from network); 22 May 2005 00:09:37 +0200 Received: from p508fd4bd.dip.t-dialin.net (HELO localhost.skatecity) (80.143.212.189) by enterprise.noxa.de with AES256-SHA encrypted SMTP; 22 May 2005 00:09:37 +0200 Received: from localhost.skatecity (nobody@localhost.skatecity [127.0.0.1]) by localhost.skatecity (8.13.3/8.13.3) with ESMTP id j4LM9Z9O000982 for ; Sun, 22 May 2005 00:09:35 +0200 (CEST) (envelope-from arundel@localhost.skatecity) Received: (from arundel@localhost) by localhost.skatecity (8.13.3/8.13.3/Submit) id j4LM9ZTZ000981 for freebsd-hackers@freebsd.org; Sun, 22 May 2005 00:09:35 +0200 (CEST) (envelope-from arundel) From: alexander Date: Sun, 22 May 2005 00:09:35 +0200 To: freebsd-hackers@freebsd.org Message-ID: <20050521220935.GA884@skatecity> References: <20050520224726.GA7951@skatecity> <20050520230845.GC51092@dan.emsphone.com> <20050521015105.GA9063@skatecity> <20050521080723.GN2129@cirb503493.alcatel.com.au> <20050521145807.GA51141@skatecity> <20050521204719.GO2129@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050521204719.GO2129@cirb503493.alcatel.com.au> Subject: Re: Looking for ANSI/VT100 code replacement. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2005 22:09:40 -0000 On Sun May 22 05, Peter Jeremy wrote: > > Can you please confirm that you also see the problem when you are using > xterm (not Eterm). Can you also please advise what versions of FreeBSD, > X11 and xterm/Eterm you are using. > OK. Seems like you somehow knew what was going on here. The problem has now clearly shifted towards the Eterm code. Xterm display the VT100 codes correctly. It seems Eterm supports VT100 codes, but the code is slow and buggy. Thx a lot for your help. This was bugging me for quite some time now. Version is FreeBSD 5.4-STABLE #0: Wed Apr 27 03:14:27 CEST 2005 btw. However I'm still thinking of replacing the whole VT100 stuff with a set of syscalls. So...is there a way to reposition the cursor inside the sdtout stream just by using syscalls? Can I use lseek() or some other syscall to change the current FD position? I had a look at the 'burncd' code and the code works brilliantly even under Eterm. However burncd being a C app uses fprintf. Can I replace the functionality of fprintf under x86asm by using only syscalls? Cheers. Thx again for your help.